From mpetach at netflight.com  Fri Nov  1 00:24:11 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 31 Oct 2013 17:24:11 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CALFTrnOcO0JvgMBG9JFcibc_BqvgKxoH6MDF84JVdXc5GSO6UA@mail.gmail.com>
References: <20131030123034.F3EFF631@m0005310.ppops.net>
 <CALFTrnOcO0JvgMBG9JFcibc_BqvgKxoH6MDF84JVdXc5GSO6UA@mail.gmail.com>
Message-ID: <CAEmG1=qwgwPwUmmuD+kzraVU8bS6gLg8zB2_07pPhx4aeSPY6w@mail.gmail.com>

On Thu, Oct 31, 2013 at 7:02 AM, Ray Soucy <rps at maine.edu> wrote:

> Was the unplanned L3 DF maintenance that took place on Tuesday a frantic
> removal of taps? :-)
>

No need for intrusive techniques such as direct taps:

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=1494884

"Of all the techniques, the bent fiber tap is the most easily deployed with
minimal
risk of damage or detection. The paper quantifies the bend loss required to
tap a
signal propagating in a single mode fiber"

Matt



>
> On Wed, Oct 30, 2013 at 3:30 PM, Scott Weeks <surfer at mauigateway.com>
> wrote:
>
> > On Wed, Oct 30, 2013 at 1:46 PM, Jacque O'Lantern <
> > jacque.olantern at yandex.com> wrote:
> >
> > >
> >
> http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html
> >
> >
> > --- brandon.galbraith at gmail.com wrote:
> > From: Brandon Galbraith <brandon.galbraith at gmail.com>
> >
> > Google is speeding up its initiative to encrypt all DC to DC traffic, as
> > this was suspected a short time ago.
> >
> >
> http://www.informationweek.com/security/government/nsa-fallout-google-speeds-data-encryptio/240161070
> > ---------------------------------------------------------
> >
> >
> > This goes back to our conversation last June:
> >
> > http://mailman.nanog.org/pipermail/nanog/2013-June/thread.html#59352
> >
> > now $189K may not seem as 'big'!  ;-)
> >
> > (http://mailman.nanog.org/pipermail/nanog/2013-June/059371.html)
> >
> >
> > scott
> >
> >
>
>
> --
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
>
> T: 207-561-3526
> F: 207-561-3531
>
> MaineREN, Maine's Research and Education Network
> www.maineren.net
>
>

From mysidia at gmail.com  Fri Nov  1 00:53:05 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 31 Oct 2013 19:53:05 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAEmG1=qwgwPwUmmuD+kzraVU8bS6gLg8zB2_07pPhx4aeSPY6w@mail.gmail.com>
References: <20131030123034.F3EFF631@m0005310.ppops.net>
 <CALFTrnOcO0JvgMBG9JFcibc_BqvgKxoH6MDF84JVdXc5GSO6UA@mail.gmail.com>
 <CAEmG1=qwgwPwUmmuD+kzraVU8bS6gLg8zB2_07pPhx4aeSPY6w@mail.gmail.com>
Message-ID: <CAAAwwbVgiOTcUh00ZHAM4--Ag45jWBL1gKXfUE-zPXGBZxUPOA@mail.gmail.com>

On Thu, Oct 31, 2013 at 7:24 PM, Matthew Petach <mpetach at netflight.com>wrote:

> On Thu, Oct 31, 2013 at 7:02 AM, Ray Soucy <rps at maine.edu> wrote:
> > Was the unplanned L3 DF maintenance that took place on Tuesday a frantic
> > removal of taps? :-)
>
No need for intrusive techniques such as direct taps:
>
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=1494884
>

For shame.... you've  sent in a link to some article behind a paywall, with
some insane download fee.
Which is an equivalent of hand-waving.

They must be hiding their content,  for fear that flaws be pointed out.


"Of all the techniques, the bent fiber tap is the most easily deployed with
> minimal risk of damage or detection. The paper quantifies the bend loss
> required to
> tap a signal propagating in a single mode fiber"
>

There will be some wavelengths of light, that may be on the cable, that
bending won't get a useful signal from.

Bending the cable sufficiently to  break  the total internal reflection
 property,  and allow light to leak --  will generate power losses in the
cable,  that can be identified  on an OTDR.



> Matt
>
--
-JH

From mpetach at netflight.com  Fri Nov  1 01:26:46 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 31 Oct 2013 18:26:46 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAAAwwbVgiOTcUh00ZHAM4--Ag45jWBL1gKXfUE-zPXGBZxUPOA@mail.gmail.com>
References: <20131030123034.F3EFF631@m0005310.ppops.net>
 <CALFTrnOcO0JvgMBG9JFcibc_BqvgKxoH6MDF84JVdXc5GSO6UA@mail.gmail.com>
 <CAEmG1=qwgwPwUmmuD+kzraVU8bS6gLg8zB2_07pPhx4aeSPY6w@mail.gmail.com>
 <CAAAwwbVgiOTcUh00ZHAM4--Ag45jWBL1gKXfUE-zPXGBZxUPOA@mail.gmail.com>
Message-ID: <CAEmG1=q0uOXk1_OTXkc4qmntw-SsBfc_8sVWEsQquFpo8=Bs8Q@mail.gmail.com>

On Thu, Oct 31, 2013 at 5:53 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Thu, Oct 31, 2013 at 7:24 PM, Matthew Petach <mpetach at netflight.com>wrote:
>
>> On Thu, Oct 31, 2013 at 7:02 AM, Ray Soucy <rps at maine.edu> wrote:
>> > Was the unplanned L3 DF maintenance that took place on Tuesday a frantic
>> > removal of taps? :-)
>>
> No need for intrusive techniques such as direct taps:
>>
>> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=1494884
>>
>
> For shame.... you've  sent in a link to some article behind a paywall,
> with some insane download fee.
> Which is an equivalent of hand-waving.
>
> They must be hiding their content,  for fear that flaws be pointed out.
>

Oy...OK, let me find a document that spells it out
a bit more clearly for you.


>
>
> "Of all the techniques, the bent fiber tap is the most easily deployed with
>> minimal risk of damage or detection. The paper quantifies the bend loss
>> required to
>> tap a signal propagating in a single mode fiber"
>>
>
> There will be some wavelengths of light, that may be on the cable, that
> bending won't get a useful signal from.
>
> Bending the cable sufficiently to  break  the total internal reflection
>  property,  and allow light to leak --  will generate power losses in the
> cable,  that can be identified  on an OTDR.
>

This patent covers a technique developed to do
non-intrusive optical tapping with a 0.5" microbend,
with only 0.5dB signal loss:

http://www.google.com/patents/CA2576969C

Most people aren't going to be able to tell a
0.5dB loss from a microbend tap from a splice
job.

Matt



>
>
>
>> Matt
>>
> --
> -JH
>

From explanoit.nanog at explanoit.com  Fri Nov  1 02:48:45 2013
From: explanoit.nanog at explanoit.com (explanoit)
Date: Thu, 31 Oct 2013 21:48:45 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <17761383158810@web2j.yandex.ru>
References: <17761383158810@web2j.yandex.ru>
Message-ID: <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>

As a top-posting IT generalist pleb, can someone explain why 
Google/Yahoo did not already encrypt their data between DCs?
Why is my data encrypted over the internet from my computer to theirs, 
but they don't encrypt the data when it goes outside their building and 
all the fancy access controls they like to talk about?

Thank you for your feedback,
explanoit

On 2013-10-30 13:46, Jacque O'Lantern wrote:
> http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html


From mikal at stillhq.com  Fri Nov  1 04:26:58 2013
From: mikal at stillhq.com (Michael Still)
Date: Fri, 1 Nov 2013 15:26:58 +1100
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
Message-ID: <CAEd1pt41P8_Ny6sxjob3roMubwpowqgUoN4f=sVjuk6pL6iGFQ@mail.gmail.com>

On Fri, Nov 1, 2013 at 1:48 PM, explanoit <explanoit.nanog at explanoit.com> wrote:
> As a top-posting IT generalist pleb, can someone explain why Google/Yahoo
> did not already encrypt their data between DCs?
> Why is my data encrypted over the internet from my computer to theirs, but
> they don't encrypt the data when it goes outside their building and all the
> fancy access controls they like to talk about?

Its about the CPU cost of the crypto. I was once told the number of
CPUs required to do SSL on web search (which I have now forgotten) and
it was a bigger number than you'd expect -- certainly hundreds.

So, crypto costs money at scale basically.

Cheers,
Michael


From mohta at necom830.hpcl.titech.ac.jp  Fri Nov  1 07:03:56 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Fri, 01 Nov 2013 16:03:56 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131031235110.D505696611F@rock.dv.isc.org>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
Message-ID: <5273525C.5060908@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

> That said it is possible to completely automate the secure assignment
> of PTR records.  It is also possible to completely automate the
> secure delegation of the reverse name space.  See
> http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00

It is a lot simpler and a lot more practical just to
use shared secret between a CPE and a ISP's name server
for TSIG generation.

As the secret can be directly shared end to end, it is more
secure than DNSSEC involving untrustworthy third parties.

						Masataka Ohta



From mysidia at gmail.com  Fri Nov  1 08:13:11 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 1 Nov 2013 03:13:11 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAEd1pt41P8_Ny6sxjob3roMubwpowqgUoN4f=sVjuk6pL6iGFQ@mail.gmail.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAEd1pt41P8_Ny6sxjob3roMubwpowqgUoN4f=sVjuk6pL6iGFQ@mail.gmail.com>
Message-ID: <CAAAwwbUHBZ-nr3xgq-dGifAj5DL4910qj=6kWnrVotS3PCLChA@mail.gmail.com>

On Thu, Oct 31, 2013 at 11:26 PM, Michael Still <mikal at stillhq.com> wrote:

> [snip]
>


> Its about the CPU cost of the crypto. I was once told the number of
> CPUs required to do SSL on web search (which I have now forgotten) and
> it was a bigger number than you'd expect -- certainly hundreds.
>
So, crypto costs money at scale basically.
>

SSL Cryptography for web search is a different problem than, say
 Site-to-Site VPN encryption.

Every time a new browser connects, you have a new SSL session setup.
New SSL session setup requires  public cryptography operations which impose
a significant delay, and the public key operations have an enormous CPU
cost.

So much so,  that the key generation and signing operations involved in CPU
session setup are a big bottleneck, and therefore, a potential DoS risk.

For encryption of traffic between datacenters;    There should be very
little session setup and teardown  (very few public key operations);
 almost all the crypto load would be symmetric cryptography.


No doubt, there still  must be some cost in terms of crypto processors
required to achieve encryption of all the traffic on 100-gigabit links
 between datacenters;  it's always something, after all.






>
> Cheers,
> Michael
>
>


-- 
-JH

From lorell at hathcock.org  Fri Nov  1 12:48:28 2013
From: lorell at hathcock.org (Lorell Hathcock)
Date: Fri, 1 Nov 2013 07:48:28 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAEmG1=q0uOXk1_OTXkc4qmntw-SsBfc_8sVWEsQquFpo8=Bs8Q@mail.gmail.com>
References: <20131030123034.F3EFF631@m0005310.ppops.net>
 <CALFTrnOcO0JvgMBG9JFcibc_BqvgKxoH6MDF84JVdXc5GSO6UA@mail.gmail.com>
 <CAEmG1=qwgwPwUmmuD+kzraVU8bS6gLg8zB2_07pPhx4aeSPY6w@mail.gmail.com>
 <CAAAwwbVgiOTcUh00ZHAM4--Ag45jWBL1gKXfUE-zPXGBZxUPOA@mail.gmail.com>
 <CAEmG1=q0uOXk1_OTXkc4qmntw-SsBfc_8sVWEsQquFpo8=Bs8Q@mail.gmail.com>
Message-ID: <02f001ced700$aa1ef350$fe5cd9f0$@hathcock.org>

Until you've heard an ex-NSA guy explain to you how this is done, with a
device the size of a brief-case, it can seem a little unbelievable.  I had
that conversation in the late '90s.

-----Original Message-----
From: Matthew Petach [mailto:mpetach at netflight.com] 
Sent: Thursday, October 31, 2013 8:27 PM
To: Jimmy Hess
Cc: NANOG
Subject: Re: latest Snowden docs show NSA intercepts all Google and Yahoo
DC-to-DC traffic

On Thu, Oct 31, 2013 at 5:53 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Thu, Oct 31, 2013 at 7:24 PM, Matthew Petach
<mpetach at netflight.com>wrote:
>
>> On Thu, Oct 31, 2013 at 7:02 AM, Ray Soucy <rps at maine.edu> wrote:
>> > Was the unplanned L3 DF maintenance that took place on Tuesday a 
>> > frantic removal of taps? :-)
>>
> No need for intrusive techniques such as direct taps:
>>
>> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumbe
>> r=1494884
>>
>
> For shame.... you've  sent in a link to some article behind a paywall, 
> with some insane download fee.
> Which is an equivalent of hand-waving.
>
> They must be hiding their content,  for fear that flaws be pointed out.
>

Oy...OK, let me find a document that spells it out a bit more clearly for
you.


>
>
> "Of all the techniques, the bent fiber tap is the most easily deployed 
> with
>> minimal risk of damage or detection. The paper quantifies the bend 
>> loss required to tap a signal propagating in a single mode fiber"
>>
>
> There will be some wavelengths of light, that may be on the cable, that
> bending won't get a useful signal from.
>
> Bending the cable sufficiently to  break  the total internal reflection
>  property,  and allow light to leak --  will generate power losses in the
> cable,  that can be identified  on an OTDR.
>

This patent covers a technique developed to do
non-intrusive optical tapping with a 0.5" microbend,
with only 0.5dB signal loss:

http://www.google.com/patents/CA2576969C

Most people aren't going to be able to tell a
0.5dB loss from a microbend tap from a splice
job.

Matt



>
>
>
>> Matt
>>
> --
> -JH
>



From jschauma at netmeister.org  Fri Nov  1 13:38:38 2013
From: jschauma at netmeister.org (Jan Schaumann)
Date: Fri, 1 Nov 2013 09:38:38 -0400
Subject: large scale ipsec
Message-ID: <20131101133838.GV21002@netmeister.org>

Hello,

Who here on this list has deployed IPSec or other comparable lower layer
encryption in a large scale environment, or attempted to do so?

I've repeatedly heard claims that doing so is not feasible (either
operationally or financially), but I have not seen any specific studies,
reports, numbers or anything else to support this.  Of course I haven't
seen anything proving the opposite, either, which is why I'm reaching
out here on this list.

What was your experience, and what alternatives have you considered?  If
your findings were made longer than, say, 5 years ago, what might have
changed to change the results?

-Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 478 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131101/7a27ee43/attachment.bin>

From Valdis.Kletnieks at vt.edu  Fri Nov  1 14:15:26 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 01 Nov 2013 10:15:26 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Fri, 01 Nov 2013 16:03:56 +0900."
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
Message-ID: <79182.1383315326@turing-police.cc.vt.edu>

On Fri, 01 Nov 2013 16:03:56 +0900, Masataka Ohta said:
> It is a lot simpler and a lot more practical just to
> use shared secret between a CPE and a ISP's name server
> for TSIG generation.

Hmm.. Shared secret between a CPE you don't necessarily control
and your own DNS server?  This *will* get you a dartboard with
your picture on it at the ISP's help desk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131101/df053a1d/attachment.bin>

From paul at paulstewart.org  Fri Nov  1 14:31:52 2013
From: paul at paulstewart.org (Paul Stewart)
Date: Fri, 01 Nov 2013 10:31:52 -0400
Subject: large scale ipsec
In-Reply-To: <20131101133838.GV21002@netmeister.org>
Message-ID: <CE993365.E5BA2%pstewart726@gmail.com>

Can you give us an idea of ?large scale? in your mind?  Also, site to site
deployments or remote access or both?

Paul


On 11/1/2013, 9:38 AM, "Jan Schaumann" <jschauma at netmeister.org> wrote:

>Hello,
>
>Who here on this list has deployed IPSec or other comparable lower layer
>encryption in a large scale environment, or attempted to do so?
>
>I've repeatedly heard claims that doing so is not feasible (either
>operationally or financially), but I have not seen any specific studies,
>reports, numbers or anything else to support this.  Of course I haven't
>seen anything proving the opposite, either, which is why I'm reaching
>out here on this list.
>
>What was your experience, and what alternatives have you considered?  If
>your findings were made longer than, say, 5 years ago, what might have
>changed to change the results?
>
>-Jan




From thegameiam at yahoo.com  Fri Nov  1 14:30:22 2013
From: thegameiam at yahoo.com (David Barak)
Date: Fri, 1 Nov 2013 07:30:22 -0700 (PDT)
Subject: large scale ipsec
In-Reply-To: <20131101133838.GV21002@netmeister.org>
Message-ID: <1383316222.57868.YahooMailMobile@web142806.mail.bf1.yahoo.com>

Hi Jan,

Please define &quot;large scale&quot;.  Is that by number of endpoints, throughput, or some other metric?  How big is big?

David Barak

From morrowc.lists at gmail.com  Fri Nov  1 15:07:47 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 1 Nov 2013 11:07:47 -0400
Subject: large scale ipsec
In-Reply-To: <1383316222.57868.YahooMailMobile@web142806.mail.bf1.yahoo.com>
References: <20131101133838.GV21002@netmeister.org>
 <1383316222.57868.YahooMailMobile@web142806.mail.bf1.yahoo.com>
Message-ID: <CAL9jLaZ4ySpk9NaWTHhXpwSsMZcHz5bh8J=BBd+-HA5qJH_k1g@mail.gmail.com>

On Fri, Nov 1, 2013 at 10:30 AM, David Barak <thegameiam at yahoo.com> wrote:
> Hi Jan,
>
> Please define "large scale".  Is that by number of endpoints, throughput, or some other metric?  How big is big?
>

it's fair to believe that there are 'lots' of ipsec deployments where
there are ~1000 or so endpoints (network endpoints) connected in a
'vpn'. There are also certainly large volume ipsec deployments (I
recall an ipsec vpn problem at a former company for a single 400mbps
'flow' between endpoints, maybe david remembers this as well).

One might look at MS's documentation about deploying end-to-end ipsec
in their enterprise for one example of peer-to-peer ubiquitous ipsec.

it'd sure be helpful to have some dimensions to the OP's question though.

-chris


From anthonyrjunk at gmail.com  Fri Nov  1 04:43:58 2013
From: anthonyrjunk at gmail.com (Anthony Junk)
Date: Fri, 1 Nov 2013 00:43:58 -0400
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
Message-ID: <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>

Hey expanoit,

There was a small part that jumped out at me when I read the article
earlier:

"In recent years, both of them are said to have bought
or leased thousands of miles of fiber-optic cables for their own exclusive
use. They had reason to think, insiders said, that their private, internal
networks were safe from prying eyes."

It seems as if both Yahoo and Google assumed that since they were private
circuits that they didn't have to encrypt. This would've added cost in
engineering, hardware, and in the end, overall throughput; I would assume
they saw it as a low possibility that anyone would (a) have knowledge of
the their traffic inter-site and (b) would have the ability to not only
accomplish the task but not get caught as well.

This is just my take on the situation and I'm sure there are others more
experienced that could offer a more detailed perspective with much less
speculation. Thanks.


Sincerely,

Anthony R Junk
Network Engineer
(410) 929-1838
anthonyrjunk at gmail.com



On Thu, Oct 31, 2013 at 10:48 PM, explanoit
<explanoit.nanog at explanoit.com>wrote:

> As a top-posting IT generalist pleb, can someone explain why Google/Yahoo
> did not already encrypt their data between DCs?
> Why is my data encrypted over the internet from my computer to theirs, but
> they don't encrypt the data when it goes outside their building and all the
> fancy access controls they like to talk about?
>
> Thank you for your feedback,
> explanoit
>
> On 2013-10-30 13:46, Jacque O'Lantern wrote:
>
>> http://www.washingtonpost.com/**world/national-security/nsa-**
>> infiltrates-links-to-yahoo-**google-data-centers-worldwide-**
>> snowden-documents-say/2013/10/**30/e51d661e-4166-11e3-8b74-**
>> d89d714ca4dd_story.html<http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html>
>>
>
>

From randy at psg.com  Fri Nov  1 16:25:06 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 01 Nov 2013 09:25:06 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAAAwwbVgiOTcUh00ZHAM4--Ag45jWBL1gKXfUE-zPXGBZxUPOA@mail.gmail.com>
References: <20131030123034.F3EFF631@m0005310.ppops.net>
 <CALFTrnOcO0JvgMBG9JFcibc_BqvgKxoH6MDF84JVdXc5GSO6UA@mail.gmail.com>
 <CAEmG1=qwgwPwUmmuD+kzraVU8bS6gLg8zB2_07pPhx4aeSPY6w@mail.gmail.com>
 <CAAAwwbVgiOTcUh00ZHAM4--Ag45jWBL1gKXfUE-zPXGBZxUPOA@mail.gmail.com>
Message-ID: <m2ob64ks2l.wl%randy@psg.com>

>> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=1494884
> They must be hiding their content,  for fear that flaws be pointed
> out.

it's the ieee.  what they're hiding is a last century business model.

randy


From randy at psg.com  Fri Nov  1 16:26:16 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 01 Nov 2013 09:26:16 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAAAwwbUHBZ-nr3xgq-dGifAj5DL4910qj=6kWnrVotS3PCLChA@mail.gmail.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAEd1pt41P8_Ny6sxjob3roMubwpowqgUoN4f=sVjuk6pL6iGFQ@mail.gmail.com>
 <CAAAwwbUHBZ-nr3xgq-dGifAj5DL4910qj=6kWnrVotS3PCLChA@mail.gmail.com>
Message-ID: <m2mwloks0n.wl%randy@psg.com>

> For encryption of traffic between datacenters;    There should be very
> little session setup and teardown  (very few public key operations);
> almost all the crypto load would be symmetric cryptography.

trivial at 9600 baud between google datacenters


From bill at herrin.us  Fri Nov  1 16:40:42 2013
From: bill at herrin.us (William Herrin)
Date: Fri, 1 Nov 2013 12:40:42 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <5273525C.5060908@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
Message-ID: <CAP-guGXOW4ywz-j7kcCOqGchWtRY1mcONdsRWP49EyQrGFjdag@mail.gmail.com>

On Fri, Nov 1, 2013 at 3:03 AM, Masataka Ohta
<mohta at necom830.hpcl.titech.ac.jp> wrote:
> Mark Andrews wrote:
>> That said it is possible to completely automate the secure assignment
>> of PTR records.  It is also possible to completely automate the
>> secure delegation of the reverse name space.  See
>> http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
>
> It is a lot simpler and a lot more practical just to
> use shared secret between a CPE and a ISP's name server
> for TSIG generation.

Howdy,

I hope you don't mean to suggest that a user should be able to use his
normal ISP username and password to set those DNS records which the
ISP has determined that he's allowed to set. That's just crazy talk!

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jschauma at netmeister.org  Fri Nov  1 17:06:44 2013
From: jschauma at netmeister.org (Jan Schaumann)
Date: Fri, 1 Nov 2013 13:06:44 -0400
Subject: large scale ipsec
In-Reply-To: <CAL9jLaZ4ySpk9NaWTHhXpwSsMZcHz5bh8J=BBd+-HA5qJH_k1g@mail.gmail.com>
References: <20131101133838.GV21002@netmeister.org>
 <1383316222.57868.YahooMailMobile@web142806.mail.bf1.yahoo.com>
 <CAL9jLaZ4ySpk9NaWTHhXpwSsMZcHz5bh8J=BBd+-HA5qJH_k1g@mail.gmail.com>
Message-ID: <20131101170644.GA17350@netmeister.org>

Christopher Morrow <morrowc.lists at gmail.com> wrote:
 
> One might look at MS's documentation about deploying end-to-end ipsec
> in their enterprise for one example of peer-to-peer ubiquitous ipsec.

This is interesting and kind of what I'm looking for.  Do you have a
pointer to this documentation?

My apologies for not having defined "large scale" in my original mail.
What I had in mind was, basically, environments ranging with multiple
datacenters (possibly across the globe) pushing tens of gb/s or more.

Though I suppose I'd also be interested in any other scale, both larger
and smaller.  I'd be glad to collect any information you may want to
send me off-list and report back with a summary, if that's preferred.

-Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 478 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131101/227450be/attachment.bin>

From gary.buhrmaster at gmail.com  Fri Nov  1 17:08:59 2013
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 1 Nov 2013 17:08:59 +0000
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
Message-ID: <CAMfXtQxCmzm+zn+ncn_LfCxwuWyB6pePF-Xd+Q50P7Cg4=Adxg@mail.gmail.com>

On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk <anthonyrjunk at gmail.com> wrote:
...
> It seems as if both Yahoo and Google assumed that since they were private
> circuits that they didn't have to encrypt.

I actually cannot see them assuming that.  Google
and Yahoo engineers are smart, and taping fibres
has been well known for, well, "forever".  I can
see them making a business decision that the
costs would be excessive to mitigate against
taping(*) that would be allowed under the laws
in any event.

Gary

(*) "A" mitigation  was run the fibre through your
own pressured pipe which you monitored for loss
of pressure, so that even a "hot tap" on the pipe
itself would possibly be detected (and there are
countermeasures to countermeasures
to countermeasures of the various methods).
And even then, you had to have a someone walk
the path from time to time to verify its integrity.
And I am pretty sure there is even an NSA/DOD
doc on the requirements/implementation to do
those mitigations.


From dmiller at tiggee.com  Fri Nov  1 17:44:18 2013
From: dmiller at tiggee.com (David Miller)
Date: Fri, 01 Nov 2013 13:44:18 -0400
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAMfXtQxCmzm+zn+ncn_LfCxwuWyB6pePF-Xd+Q50P7Cg4=Adxg@mail.gmail.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <CAMfXtQxCmzm+zn+ncn_LfCxwuWyB6pePF-Xd+Q50P7Cg4=Adxg@mail.gmail.com>
Message-ID: <5273E872.4050302@tiggee.com>

On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:
> On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk <anthonyrjunk at gmail.com> wrote:
> ...
>> It seems as if both Yahoo and Google assumed that since they were private
>> circuits that they didn't have to encrypt.
> 
> I actually cannot see them assuming that.  Google
> and Yahoo engineers are smart, and taping fibres
> has been well known for, well, "forever".  I can
> see them making a business decision that the
> costs would be excessive to mitigate against
> taping(*) that would be allowed under the laws
> in any event.
> 
> Gary
> 
> (*) "A" mitigation  was run the fibre through your
> own pressured pipe which you monitored for loss
> of pressure, so that even a "hot tap" on the pipe
> itself would possibly be detected (and there are
> countermeasures to countermeasures
> to countermeasures of the various methods).
> And even then, you had to have a someone walk
> the path from time to time to verify its integrity.
> And I am pretty sure there is even an NSA/DOD
> doc on the requirements/implementation to do
> those mitigations.
> 

Given what we now know about the breadth of the NSA operations, and the
likelihood that this is still only the tip of the iceberg - would anyone
still point to NSA guidance on avoiding monitoring with any sort of
confidence?

There has always been cognitive dissonance in the dual roles of the NSA:
1. The NSA monitors.
2. The NSA provides guidance on how to avoid being monitored.

Conflict?

-DMM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131101/718d90fd/attachment.bin>

From cscora at apnic.net  Fri Nov  1 18:07:05 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 2 Nov 2013 04:07:05 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201311011807.rA1I75Q0017292@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, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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

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

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

Routing Table Report   04:00 +10GMT Sat 02 Nov, 2013

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

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

BGP routing table entries examined:                              470880
    Prefixes after maximum aggregation:                          189231
    Deaggregation factor:                                          2.49
    Unique aggregates announced to Internet:                     233598
Total ASes present in the Internet Routing Table:                 45368
    Prefixes per ASN:                                             10.38
Origin-only ASes present in the Internet Routing Table:           35324
Origin ASes announcing only one prefix:                           16267
Transit ASes present in the Internet Routing Table:                5954
Transit-only ASes present in the Internet Routing Table:            161
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      35
    Max AS path prepend of ASN ( 55644)                              31
Prefixes from unregistered ASNs in the Routing Table:               720
    Unregistered ASNs in the Routing Table:                         194
Number of 32-bit ASNs allocated by the RIRs:                       5284
Number of 32-bit ASNs visible in the Routing Table:                4090
Prefixes from 32-bit ASNs in the Routing Table:                   12675
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            889
Number of addresses announced to Internet:                   2653744084
    Equivalent to 158 /8s, 44 /16s and 235 /24s
    Percentage of available address space announced:               71.7
    Percentage of allocated address space announced:               71.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               95.1
Total number of prefixes smaller than registry allocations:      164648

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

Prefixes being announced by APNIC Region ASes:                   111522
    Total APNIC prefixes after maximum aggregation:               33881
    APNIC Deaggregation factor:                                    3.29
Prefixes being announced from the APNIC address blocks:          113638
    Unique aggregates announced from the APNIC address blocks:    47281
APNIC Region origin ASes present in the Internet Routing Table:    4884
    APNIC Prefixes per ASN:                                       23.27
APNIC Region origin ASes announcing only one prefix:               1214
APNIC Region transit ASes present in the Internet Routing Table:    836
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         35
Number of APNIC region 32-bit ASNs visible in the Routing Table:    721
Number of APNIC addresses announced to Internet:              729894080
    Equivalent to 43 /8s, 129 /16s and 76 /24s
    Percentage of available APNIC address space announced:         85.3

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-63999, 131072-133631
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:                    162649
    Total ARIN prefixes after maximum aggregation:                81501
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           163562
    Unique aggregates announced from the ARIN address blocks:     75922
ARIN Region origin ASes present in the Internet Routing Table:    15916
    ARIN Prefixes per ASN:                                        10.28
ARIN Region origin ASes announcing only one prefix:                6011
ARIN Region transit ASes present in the Internet Routing Table:    1668
Average ARIN Region AS path length visible:                         4.1
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:      32
Number of ARIN addresses announced to Internet:              1073461888
    Equivalent to 63 /8s, 251 /16s and 186 /24s
    Percentage of available ARIN address space announced:          56.8

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8,
                       205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8,
                       216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    119308
    Total RIPE prefixes after maximum aggregation:                61150
    RIPE Deaggregation factor:                                     1.95
Prefixes being announced from the RIPE address blocks:           122943
    Unique aggregates announced from the RIPE address blocks:     78932
RIPE Region origin ASes present in the Internet Routing Table:    17520
    RIPE Prefixes per ASN:                                         7.02
RIPE Region origin ASes announcing only one prefix:                8296
RIPE Region transit ASes present in the Internet Routing Table:    2844
Average RIPE Region AS path length visible:                         5.1
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:    2453
Number of RIPE addresses announced to Internet:               656599396
    Equivalent to 39 /8s, 34 /16s and 233 /24s
    Percentage of available RIPE address space announced:          95.5

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-200191
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:                   52561
    Total LACNIC prefixes after maximum aggregation:               9998
    LACNIC Deaggregation factor:                                   5.26
Prefixes being announced from the LACNIC address blocks:          57608
    Unique aggregates announced from the LACNIC address blocks:   26745
LACNIC Region origin ASes present in the Internet Routing Table:   2032
    LACNIC Prefixes per ASN:                                      28.35
LACNIC Region origin ASes announcing only one prefix:               548
LACNIC Region transit ASes present in the Internet Routing Table:   388
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        35
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   878
Number of LACNIC addresses announced to Internet:             142306864
    Equivalent to 8 /8s, 123 /16s and 110 /24s
    Percentage of available LACNIC address space announced:        84.8

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 262144-263679 plus 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:                  11584
    Total AfriNIC prefixes after maximum aggregation:              2566
    AfriNIC Deaggregation factor:                                  4.51
Prefixes being announced from the AfriNIC address blocks:         12240
    Unique aggregates announced from the AfriNIC address blocks:   3973
AfriNIC Region origin ASes present in the Internet Routing Table:   672
    AfriNIC Prefixes per ASN:                                     18.21
AfriNIC Region origin ASes announcing only one prefix:              198
AfriNIC Region transit ASes present in the Internet Routing Table:  137
Average AfriNIC Region AS path length visible:                      4.7
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    6
Number of AfriNIC addresses announced to Internet:             48064000
    Equivalent to 2 /8s, 221 /16s and 102 /24s
    Percentage of available AfriNIC address space announced:       47.7

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2937      11558         943   Korea Telecom (KIX)
17974     2711        903          89   PT TELEKOMUNIKASI INDONESIA
 7545     2101        319         111   TPG Internet Pty Ltd
 4755     1787        391         188   TATA Communications formerly 
 9829     1539       1242          48   BSNL National Internet Backbo
 9498     1210        309          74   BHARTI Airtel Ltd.
 9583     1187         90         513   Sify Limited
 4808     1158       2128         342   CNCGROUP IP network: China169
 7552     1158       1080          13   Vietel Corporation
24560     1092        380         165   Bharti Airtel Ltd., Telemedia

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
 6389     3056       3688          56   BellSouth.net Inc.
22773     2188       2939         138   Cox Communications, Inc.
18566     2058        379         179   MegaPath Corporation
 1785     2036        684         130   PaeTec Communications, Inc.
20115     1679       1653         610   Charter Communications 
 4323     1627       1102         420   Time Warner Telecom
  701     1507      11145         782   MCI Communications Services, 
30036     1382        312         580   Mediacom Communications Corp 
 7018     1333      17779         869   AT&T WorldNet Services
 6983     1293        755         578   ITC^Deltacom 

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
 8402     1835        544          17   OJSC "Vimpelcom"
34984     1363        244         223   TELLCOM ILETISIM HIZMETLERI A
20940     1113        406         847   Akamai Technologies European 
31148     1005         44          18   FreeNet ISP
13188      888         99          49   TOV "Bank-Inform"
 6849      861        356          30   JSC UKRTELECOM,
 6830      771       2327         423   UPC Distribution Services
 8551      759        370          41   Bezeq International
12479      675        798          55   Uni2 Autonomous System
35228      542        246          16   Avatar Broadband Limited

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
28573     3436       1783          83   NET Servicos de Comunicao S.A
10620     2640        428         242   TVCABLE BOGOTA 
 7303     1722       1144         233   Telecom Argentina Stet-France
18881     1538        844          20   Global Village Telecom 
 8151     1348       2840         416   UniNet S.A. de C.V. 
11830      866        364          15   Instituto Costarricense de El
27947      846         93          92   Telconet S.A
 6147      792        373          27   Telefonica Del Peru 
 6503      788        434          61   AVANTEL, S.A. 
 7738      780       1498          36   Telecomunicacoes da Bahia S.A

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
36998     1854        112           5   Sudanese Mobile Telephone (ZA
24863      884        338          30   LINKdotNET AS number
 6713      554        633          26   Itissalat Al-MAGHRIB
 8452      386        956           9   TEDATA
24835      294        144           9   RAYA Telecom - Egypt
 3741      259        921         216   The Internet Solution 
36992      227        501          29   Etisalat MISR
29571      224         17          12   Ci Telecom Autonomous system 
15706      219         32           6   Sudatel Internet Exchange Aut
29975      192        668          21   Vodacom

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
28573     3436       1783          83   NET Servicos de Comunicao S.A
 6389     3056       3688          56   BellSouth.net Inc.
 4766     2937      11558         943   Korea Telecom (KIX)
17974     2711        903          89   PT TELEKOMUNIKASI INDONESIA
10620     2640        428         242   TVCABLE BOGOTA 
22773     2188       2939         138   Cox Communications, Inc.
 7545     2101        319         111   TPG Internet Pty Ltd
18566     2058        379         179   MegaPath Corporation
 1785     2036        684         130   PaeTec Communications, Inc.
36998     1854        112           5   Sudanese Mobile Telephone (ZA

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

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

  ASN   No of nets  Net Savings Description
 6389      3056        3000      BellSouth.net Inc.
17974      2711        2622      PT TELEKOMUNIKASI INDONESIA
10620      2640        2398      TVCABLE BOGOTA 
22773      2188        2050      Cox Communications, Inc.
 4766      2937        1994      Korea Telecom (KIX)
 7545      2101        1990      TPG Internet Pty Ltd
 1785      2036        1906      PaeTec Communications, Inc.
18566      2058        1879      MegaPath Corporation
36998      1854        1849      Sudanese Mobile Telephone (ZA
 8402      1835        1818      OJSC "Vimpelcom"

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

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

Bad AS  Designation  Network              Transit AS  Description
62734   UNALLOCATED  8.31.128.0/24         6939       Hurricane Electric 
62773   UNALLOCATED  8.35.180.0/22         3356       Level 3 Communicatio
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
62719   UNALLOCATED  12.27.130.0/24        4323       Time Warner Telecom
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24         209       Qwest Communications
17300   UNALLOCATED  12.45.110.0/24         701       MCI Communications S
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
14764   UNALLOCATED  12.108.237.0/24       7018       AT&T WorldNet Servic

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

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.100.0.0/24        4847     China Networks Inter-Exchange

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

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

Network            Origin AS  Description
23.90.128.0/18       27418     OUTOFWALL INC.
23.90.192.0/18       36086     Broad Communications Technolo
23.91.0.0/19         40676     Psychz Networks 
23.91.14.0/24        40676     Psychz Networks 
23.91.32.0/19        36315     Servpac Inc. 
23.91.80.0/20        21560     Capital Technology Services G
23.91.96.0/20        40676     Psychz Networks 
23.91.112.0/21       32475     MidPhase Inc. 
23.91.160.0/19       36493     3757277 Canada Inc. (oa 295.c
23.91.160.0/22       36493     3757277 Canada Inc. (oa 295.c

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:11      /10:31      /11:92      /12:254     
/13:474     /14:920     /15:1628    /16:12847   /17:6742    /18:11318   
/19:22981   /20:32664   /21:35483   /22:50123   /23:43756   /24:249089  
/25:832     /26:988     /27:467     /28:50      /29:79      /30:21      
/31:0       /32:14      

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

  ASN   No of nets  Total ann.   Description
18566     2012          2058      MegaPath Corporation
36998     1819          1854      Sudanese Mobile Telephone (ZA
 6389     1709          3056      BellSouth.net Inc.
 8402     1533          1835      OJSC "Vimpelcom"
22773     1454          2188      Cox Communications, Inc.
30036     1230          1382      Mediacom Communications Corp 
11492     1200          1241      Cable One 
 1785     1086          2036      PaeTec Communications, Inc.
 6983     1034          1293      ITC^Deltacom 
22561      968          1245      Digital Teleport, Inc 

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

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

   1:878       2:829       3:3         4:17        5:1007      6:21     
   8:615      12:1893     13:3        14:891      15:11       16:3      
  17:18       18:19       20:21       23:510      24:1741     27:1608   
  31:1488     32:45       33:2        34:5        36:81       37:1886   
  38:921      39:4        40:181      41:3186     42:246      44:14     
  46:2029     47:10       49:682      50:844      52:12       54:42     
  55:4        56:2        57:26       58:1154     59:576      60:373    
  61:1468     62:1209     63:1985     64:4371     65:2345     66:4137   
  67:2100     68:1103     69:3299     70:873      71:489      72:2036   
  74:2561     75:328      76:306      77:1166     78:1069     79:644    
  80:1294     81:1017     82:673      83:632      84:587      85:1252   
  86:420      87:1008     88:562      89:1598     90:150      91:5647   
  92:611      93:1599     94:2015     95:1593     96:509      97:342    
  98:1045     99:42      100:31      101:621     103:3520    105:528    
 106:142     107:214     108:535     109:1914    110:958     111:1103   
 112:595     113:810     114:752     115:1057    116:998     117:836    
 118:1160    119:1286    120:365     121:751     122:1874    123:1255   
 124:1353    125:1432    128:649     129:229     130:333     131:666    
 132:359     133:157     134:553     135:67      136:279     137:269    
 138:350     139:177     140:193     141:336     142:540     143:398    
 144:496     145:87      146:513     147:397     148:771     149:367    
 150:158     151:587     152:413     153:205     154:51      155:491    
 156:285     157:424     158:282     159:771     160:359     161:459    
 162:817     163:225     164:630     165:583     166:258     167:632    
 168:1047    169:127     170:1131    171:182     172:25      173:1605   
 174:687     175:517     176:1275    177:2359    178:1939    179:195    
 180:1587    181:791     182:1345    183:455     184:664     185:987    
 186:2643    187:1481    188:1845    189:1267    190:7238    192:7088   
 193:5413    194:4035    195:3350    196:1322    197:1014    198:4750   
 199:5480    200:6093    201:2532    202:8963    203:8921    204:4527   
 205:2641    206:2843    207:2831    208:4006    209:3618    210:3010   
 211:1569    212:2123    213:1983    214:897     215:92      216:5389   
 217:1685    218:626     219:321     220:1280    221:567     222:327    
 223:509    

End of report


From jmamodio at gmail.com  Fri Nov  1 18:10:05 2013
From: jmamodio at gmail.com (Jorge Amodio)
Date: Fri, 1 Nov 2013 13:10:05 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <m2mwloks0n.wl%randy@psg.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAEd1pt41P8_Ny6sxjob3roMubwpowqgUoN4f=sVjuk6pL6iGFQ@mail.gmail.com>
 <CAAAwwbUHBZ-nr3xgq-dGifAj5DL4910qj=6kWnrVotS3PCLChA@mail.gmail.com>
 <m2mwloks0n.wl%randy@psg.com>
Message-ID: <CAMzo+1as=hbSBSosCp6QNMKoopUuzL0MsA9_iuS3CO6gj+X+kw@mail.gmail.com>

I still have some one time pads if you are good writing fast ...

-J


On Fri, Nov 1, 2013 at 11:26 AM, Randy Bush <randy at psg.com> wrote:

> > For encryption of traffic between datacenters;    There should be very
> > little session setup and teardown  (very few public key operations);
> > almost all the crypto load would be symmetric cryptography.
>
> trivial at 9600 baud between google datacenters
>
>

From morrowc.lists at gmail.com  Fri Nov  1 18:11:54 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 1 Nov 2013 14:11:54 -0400
Subject: large scale ipsec
In-Reply-To: <20131101170644.GA17350@netmeister.org>
References: <20131101133838.GV21002@netmeister.org>
 <1383316222.57868.YahooMailMobile@web142806.mail.bf1.yahoo.com>
 <CAL9jLaZ4ySpk9NaWTHhXpwSsMZcHz5bh8J=BBd+-HA5qJH_k1g@mail.gmail.com>
 <20131101170644.GA17350@netmeister.org>
Message-ID: <CAL9jLaYZ=BP9yRsPa3fJ5tFwTMz3-GF3MMCc553Swmgg0B+_EA@mail.gmail.com>

On Fri, Nov 1, 2013 at 1:06 PM, Jan Schaumann <jschauma at netmeister.org> wrote:
> Christopher Morrow <morrowc.lists at gmail.com> wrote:
>
>> One might look at MS's documentation about deploying end-to-end ipsec
>> in their enterprise for one example of peer-to-peer ubiquitous ipsec.
>
> This is interesting and kind of what I'm looking for.  Do you have a
> pointer to this documentation?

sadly I can't find what I once read :( damned webcrawler search!!!

> My apologies for not having defined "large scale" in my original mail.
> What I had in mind was, basically, environments ranging with multiple
> datacenters (possibly across the globe) pushing tens of gb/s or more.

that's probably a different problem to solve, unless you wanted to
push the crypto down to the server/workstation level, which seems like
a more reasonable answer, for a number of reasons, provided you can do
key management and fault isolation.

One good reason to not do link encryption is: "the problem is that
whackadoodle box you put outside the router!" :( most often those
boxes can't do light-level monitoring, loopbacks, etc... all the stuff
your NOC wants to do when 'link flapped,doh!' happens.

-chris


From surfer at mauigateway.com  Fri Nov  1 18:30:55 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 1 Nov 2013 11:30:55 -0700
Subject: large scale ipsec
Message-ID: <20131101113055.F3E36CCA@resin03.mta.everyone.net>



--- morrowc.lists at gmail.com wrote:
From: Christopher Morrow <morrowc.lists at gmail.com>

One good reason to not do link encryption is: "the problem is that
whackadoodle box you put outside the router!" :( most often those
boxes can't do light-level monitoring, loopbacks, etc... all the stuff
your NOC wants to do when 'link flapped,doh!' happens.
-----------------------------------------------------


Yes!  It is really hard to work with those things for the reasons
you mention and they tend to be the culprit quite often.  Also,
a lot of times it adds more finger pointing as there tends to be
a different group taking care of just the bulk encryptors.  Last,
I have seen some strange behaviors, such as not passing BPDUs.
That makes VLANing *phun*.  Not!

scott


From berry at gadsdenst.org  Fri Nov  1 18:35:12 2013
From: berry at gadsdenst.org (berry at gadsdenst.org)
Date: Fri, 1 Nov 2013 14:35:12 -0400
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo 
 DC-to-DC traffic
In-Reply-To: <5273E872.4050302@tiggee.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <CAMfXtQxCmzm+zn+ncn_LfCxwuWyB6pePF-Xd+Q50P7Cg4=Adxg@mail.gmail.com>
 <5273E872.4050302@tiggee.com>
Message-ID: <cd5e57c5dfdffb3301fb1db76d6c7d0b.squirrel@email.powweb.com>

> On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:

[...]

>
> Given what we now know about the breadth of the NSA operations, and the
> likelihood that this is still only the tip of the iceberg - would anyone
> still point to NSA guidance on avoiding monitoring with any sort of
> confidence?
>
> There has always been cognitive dissonance in the dual roles of the NSA:
> 1. The NSA monitors.
> 2. The NSA provides guidance on how to avoid being monitored.
>
> Conflict?
>
> -DMM
>
As a local 'barbecue baron' said about his brother's competing
restaurants: "I taught him everything he knows about barbecue. I just
didn't teach him everything _I_ know about barbecue."




From blakjak at blakjak.net  Fri Nov  1 18:44:07 2013
From: blakjak at blakjak.net (Mark Foster)
Date: Sat, 2 Nov 2013 07:44:07 +1300
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <5273E872.4050302@tiggee.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <CAMfXtQxCmzm+zn+ncn_LfCxwuWyB6pePF-Xd+Q50P7Cg4=Adxg@mail.gmail.com>
 <5273E872.4050302@tiggee.com>
Message-ID: <5056d3329b1f58ef46bd0d1cd96ef8f4.squirrel@secure.blakjak.net>

On Sat, November 2, 2013 6:44 am, David Miller wrote:
> On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:
>> On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk <anthonyrjunk at gmail.com>
>> wrote:
>> ...
>>> It seems as if both Yahoo and Google assumed that since they were
>>> private
>>> circuits that they didn't have to encrypt.
>>
>> I actually cannot see them assuming that.  Google
>> and Yahoo engineers are smart, and taping fibres
>> has been well known for, well, "forever".  I can
>> see them making a business decision that the
>> costs would be excessive to mitigate against
>> taping(*) that would be allowed under the laws
>> in any event.
>>
>> Gary
>>
>> (*) "A" mitigation  was run the fibre through your
>> own pressured pipe which you monitored for loss
>> of pressure, so that even a "hot tap" on the pipe
>> itself would possibly be detected (and there are
>> countermeasures to countermeasures
>> to countermeasures of the various methods).
>> And even then, you had to have a someone walk
>> the path from time to time to verify its integrity.
>> And I am pretty sure there is even an NSA/DOD
>> doc on the requirements/implementation to do
>> those mitigations.
>>
>
> Given what we now know about the breadth of the NSA operations, and the
> likelihood that this is still only the tip of the iceberg - would anyone
> still point to NSA guidance on avoiding monitoring with any sort of
> confidence?
>
> There has always been cognitive dissonance in the dual roles of the NSA:
> 1. The NSA monitors.
> 2. The NSA provides guidance on how to avoid being monitored.
>
> Conflict?
>

I don't think so. The folks who actually do it, are the ones who are going
to best know how to avoid it.  Plenty of TV shows bear this out. :-)

I think that failure to encrypt inter-DC traffic that is on dark fibre is
simply on the presumption that corporations are seeking to protect their
links from the actions of 'unauthorised' people.  The telco theyre
contracting presumably have some sort of privacy agreement with them. 
No-one else is supposed to be able to get on the wire.  A risk assessment
pre-Snowdon probably didn't make the performance hits, costs, etc of
high-speed rateable encryption, worthwhile - but the paradigm has shifted.
The government is using 'authorisation' to get access to that dark fibre
link (presumably) and that authority is at the heart of the problem.

When reviewing your risk assessment around the presence (or not) of
encryption on your inter-site links, also consider whether the methods of
encryption available to the private sector havn't also been cracked by the
NSA etc. They had the 'golden standard' for crypto, but one has to wonder
whether that standard includes an undocumented backdoor...

Mark.



From bedard.phil at gmail.com  Fri Nov  1 18:55:39 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Fri, 01 Nov 2013 14:55:39 -0400
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAMfXtQxCmzm+zn+ncn_LfCxwuWyB6pePF-Xd+Q50P7Cg4=Adxg@mail.gmail.com>
Message-ID: <CE996F2C.7C880%bedard.phil@gmail.com>


On 11/1/13, 1:08 PM, "Gary Buhrmaster" <gary.buhrmaster at gmail.com> wrote:

>On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk <anthonyrjunk at gmail.com>
>wrote:
>...
>> It seems as if both Yahoo and Google assumed that since they were
>>private
>> circuits that they didn't have to encrypt.
>
>I actually cannot see them assuming that.  Google
>and Yahoo engineers are smart, and taping fibres
>has been well known for, well, "forever".  I can
>see them making a business decision that the
>costs would be excessive to mitigate against
>taping(*) that would be allowed under the laws
>in any event.
>
>Gary

While smart, most providers make an assumption at least with a piece of
dark fiber the only people with access to it are themselves and any
providers of the fiber.  I don't think that's an unrealistic
expectation... Providers who have trenched their own fiber certainly do
not encrypt traffic across the network, but their fiber is probably no
less susceptible to tapping at certain locations.  There have been a
number of articles in recent years about how vulnerable the fiber
infrastructure is to attacks, tapping, etc.  Vaults, manhole locations,
etc. are pretty much wide open.


Phil 




From recourse at gmail.com  Fri Nov  1 19:21:10 2013
From: recourse at gmail.com (Joseph Jackson)
Date: Fri, 1 Nov 2013 14:21:10 -0500
Subject: Integra Telecom BGP contact
Message-ID: <CAFd0Q371kWtdj=gzJkK0EArOWuZLzQCL0eD+gkHqqSHb1vVJdQ@mail.gmail.com>

Anyone from Integra Telecom who knows their BGP routing on list?  I
have an open ticket but can't get past the noc techs and the issue is
a weird one.

Thanks!


From kmcintyr at gmail.com  Fri Nov  1 19:42:00 2013
From: kmcintyr at gmail.com (Ken McIntyre)
Date: Fri, 1 Nov 2013 12:42:00 -0700
Subject: Integra Telecom BGP contact
In-Reply-To: <CAFd0Q371kWtdj=gzJkK0EArOWuZLzQCL0eD+gkHqqSHb1vVJdQ@mail.gmail.com>
References: <CAFd0Q371kWtdj=gzJkK0EArOWuZLzQCL0eD+gkHqqSHb1vVJdQ@mail.gmail.com>
Message-ID: <C8103A97-7EAC-4EA5-8258-1AD9929D17BA@gmail.com>

Sent you an email off list.
Ken-

On Nov 1, 2013, at 12:21 PM, Joseph Jackson <recourse at gmail.com> wrote:

> Anyone from Integra Telecom who knows their BGP routing on list?  I
> have an open ticket but can't get past the noc techs and the issue is
> a weird one.
> 
> Thanks!
> 



From marka at isc.org  Fri Nov  1 21:54:23 2013
From: marka at isc.org (Mark Andrews)
Date: Sat, 02 Nov 2013 08:54:23 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Fri, 01 Nov 2013 16:03:56 +0900."
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
Message-ID: <20131101215423.32B5896C2C5@rock.dv.isc.org>


In message <5273525C.5060908 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> > That said it is possible to completely automate the secure assignment
> > of PTR records.  It is also possible to completely automate the
> > secure delegation of the reverse name space.  See
> > http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
> 
> It is a lot simpler and a lot more practical just to
> use shared secret between a CPE and a ISP's name server
> for TSIG generation.

No it isn't.  It requires a human to transfer the secret to the CPE
device or to register the secret with the ISP.

I'm talking about just building this into CPE devices and having it
just work with no human involvement.

> As the secret can be directly shared end to end, it is more
> secure than DNSSEC involving untrustworthy third parties.
> 
> 						Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From cidr-report at potaroo.net  Fri Nov  1 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 1 Nov 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201311012200.rA1M00ED034352@wattle.apnic.net>

This report has been generated at Fri Nov  1 21:13:38 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        25-10-13    481005      273685
        26-10-13    480922      272864
        27-10-13    480241      273108
        28-10-13    480622      271494
        29-10-13    480919      271909
        30-10-13    481209      272234
        31-10-13    481352      272350
        01-11-13    481734      272532


AS Summary
         45515  Number of ASes in routing system
         18684  Number of ASes announcing only one prefix
          4185  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      118856704  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 01Nov13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     481879   272481   209398    43.5%   All ASes

AS6389      3056       59     2997    98.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS28573     3432      461     2971    86.6%   NET Servi?os de Comunica??o
                                               S.A.
AS17974     2710      135     2575    95.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS7029      4185     1872     2313    55.3%   WINDSTREAM - Windstream
                                               Communications Inc
AS22773     2191      147     2044    93.3%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4766      2937      951     1986    67.6%   KIXS-AS-KR Korea Telecom
AS10620     2641     1051     1590    60.2%   Telmex Colombia S.A.
AS18566     2057      567     1490    72.4%   MEGAPATH5-US - MegaPath
                                               Corporation
AS4323      2960     1538     1422    48.0%   TWTC - tw telecom holdings,
                                               inc.
AS18881     1523      105     1418    93.1%   Global Village Telecom
AS36998     1854      457     1397    75.4%   SDN-MOBITEL
AS7303      1724      466     1258    73.0%   Telecom Argentina S.A.
AS1785      2036      818     1218    59.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1787      583     1204    67.4%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1191      138     1053    88.4%   VIETEL-AS-AP Vietel
                                               Corporation
AS22561     1245      219     1026    82.4%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS35908      911       89      822    90.2%   VPLSNET - Krypt Technologies
AS7545      2102     1282      820    39.0%   TPG-INTERNET-AP TPG Telecom
                                               Limited
AS18101      980      180      800    81.6%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4808      1158      404      754    65.1%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS24560     1092      367      725    66.4%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS701       1508      785      723    47.9%   UUNET - MCI Communications
                                               Services, Inc. d/b/a Verizon
                                               Business
AS8151      1355      637      718    53.0%   Uninet S.A. de C.V.
AS6983      1293      584      709    54.8%   ITCDELTA - ITC^Deltacom
AS13977      852      143      709    83.2%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS6147       792      108      684    86.4%   Telefonica del Peru S.A.A.
AS4788       844      171      673    79.7%   TMNET-AS-AP TM Net, Internet
                                               Service Provider
AS855        726       55      671    92.4%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS4780      1000      335      665    66.5%   SEEDNET Digital United Inc.
AS7738       780      137      643    82.4%   Telemar Norte Leste S.A.

Total      52922    14844    38078    72.0%   Top 30 total


Possible Bogus Routes

        23.92.224.0/23       AS55048 VMWARE - VMware, Inc.
        23.92.226.0/23       AS55048 VMWARE - VMware, Inc.
        23.92.228.0/23       AS55048 VMWARE - VMware, Inc.
        23.92.230.0/23       AS55048 VMWARE - VMware, Inc.
        23.92.232.0/23       AS55048 VMWARE - VMware, Inc.
        27.54.116.0/22       AS55452 
        27.54.116.0/24       AS55452 
        27.54.119.0/24       AS55452 
        27.100.7.0/24        AS56096 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.25.16.0/23        AS19535 
        64.25.20.0/24        AS19535 
        64.25.21.0/24        AS19535 
        64.25.22.0/24        AS19535 
        64.25.27.0/24        AS7046  RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business
        64.57.192.0/22       AS33321 BALTICORE - Balticore, LLC
        64.57.196.0/22       AS40927 AS-SWWG-LLC - SWWG, LLC
        64.57.200.0/21       AS40927 AS-SWWG-LLC - SWWG, LLC
        64.111.0.0/20        AS8039  CCC-ASN-1 - Cinergy Communications
        64.185.224.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.225.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.226.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.227.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.228.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.229.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.230.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.231.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.232.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.233.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.234.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.235.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.236.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.237.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.238.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.239.0/24      AS27431 JTLNET - JTL Networks Inc.
        65.37.240.0/20       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        65.37.243.0/24       AS2685  ASATTCA AT&T Global Network Services - CA
        65.37.247.0/24       AS2685  ASATTCA AT&T Global Network Services - CA
        65.37.250.0/24       AS11133 
        65.37.251.0/24       AS11133 
        65.37.252.0/24       AS11133 
        65.37.253.0/24       AS11133 
        65.37.254.0/24       AS11133 
        65.37.255.0/24       AS11133 
        65.61.48.0/20        AS33005 
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global
        66.11.112.0/20       AS14572 
        66.55.96.0/23        AS17203 
        66.55.98.0/24        AS17203 
        66.55.99.0/24        AS17203 
        66.55.100.0/22       AS17203 
        66.55.102.0/23       AS17203 
        66.55.104.0/21       AS17203 
        66.96.16.0/20        AS30528 
        66.96.22.0/24        AS32517 DOTINC-NET - Dot Internet Solutions Inc.
        66.180.64.0/21       AS32558 ZEUTER - Zeuter Development Corporation
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.187.240.0/20      AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        66.212.48.0/20       AS40927 AS-SWWG-LLC - SWWG, LLC
        66.212.56.0/21       AS40927 AS-SWWG-LLC - SWWG, LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.254.160.0/20      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.176.0/21      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.184.0/22      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.188.0/22      AS35916 MULTA-ASN1 - MULTACOM CORPORATION
        67.21.144.0/22       AS174   COGENT Cogent/PSI
        67.21.148.0/22       AS174   COGENT Cogent/PSI
        67.206.160.0/19      AS33005 
        67.206.190.0/24      AS33005 
        67.206.191.0/24      AS33005 
        68.69.96.0/21        AS32986 
        68.69.96.0/24        AS32986 
        68.69.104.0/21       AS32986 
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.0.64.0/20         AS30528 
        72.0.78.0/23         AS18446 KIHEW-TECHNOLOGIES-INC - Kihew Technologies Inc.
        72.19.0.0/19         AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        72.35.224.0/22       AS30097 NUWAVE - NuWave
        72.35.229.0/24       AS30188 TELEVERGENCE - Televergence Solutions Inc.
        72.35.232.0/21       AS6246  AVALONTEL - AvalonTel
        72.44.16.0/20        AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC
        74.112.100.0/22      AS16764 
        74.112.200.0/21      AS11288 
        74.112.205.0/24      AS11288 
        74.114.52.0/22       AS40818 
        74.114.140.0/22      AS32757 
        74.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        91.193.60.0/22       AS3356  LEVEL3 Level 3 Communications
        91.195.66.0/23       AS3356  LEVEL3 Level 3 Communications
        91.197.36.0/22       AS43359 
        91.199.90.0/24       AS44330 
        91.200.188.0/22      AS44016 
        91.207.152.0/24      AS64100 
        91.207.153.0/24      AS64100 
        91.209.115.0/24      AS31103 KEYWEB-AS Keyweb AG
        91.209.163.0/24      AS48445 
        91.212.54.0/24       AS21409 IKOULA Ikoula Net SAS
        93.190.8.0/24        AS47254 
        93.190.9.0/24        AS47254 
        93.190.10.0/24       AS47254 
        100.100.0.0/24       AS4847  CNIX-AP China Networks Inter-Exchange
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. 
        103.13.184.0/23      AS58674 
        115.166.130.0/23     AS45423 
        115.166.132.0/24     AS45423 
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        124.64.0.0/10        AS4847  CNIX-AP China Networks Inter-Exchange
        164.40.184.0/24      AS19821 
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.116.0.0/24       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        174.136.192.0/18     AS14572 
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA LTDA
        190.15.72.0/21       AS15146 CABLEBAHAMAS - Cable Bahamas
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        192.166.32.0/20      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        193.9.59.0/24        AS1257  TELE2
        193.22.224.0/20      AS3322  
        193.22.238.0/23      AS6824  HERMES-NETWORK Hermes Telecom International Ltd
        193.33.66.0/23       AS39874 
        193.33.112.0/23      AS8586  OBSL-AS TalkTalk Communications Limited
        193.109.15.0/24      AS12690 MKSNET-AS MKS Autonomous System
        193.109.224.0/24     AS47427 
        193.111.30.0/23      AS24734 
        193.164.152.0/24     AS3356  LEVEL3 Level 3 Communications
        193.178.217.0/24     AS20737 
        193.188.252.0/24     AS8697  JTC-AS8697 Jordan Telecommunications Company
        193.202.8.0/21       AS3322  
        193.254.218.0/23     AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC
        194.50.82.0/24       AS16276 OVH OVH Systems
        194.63.152.0/22      AS3356  LEVEL3 Level 3 Communications
        194.79.48.0/22       AS39117 
        194.113.27.0/24      AS12518 SHLINK SHLINK Internet Service
        194.126.219.0/24     AS34545 
        195.114.4.0/23       AS41158 
        195.128.240.0/23     AS21202 DCSNET-AS Bredband2 AB
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA
        195.234.156.0/24     AS25028 
        195.248.240.0/23     AS34169 MEDIA-COM-TYCHY Media-Com Sp. z o.o.
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.58.0.0/18        AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.2.0/24        AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.3.0/24        AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.4.0/24        AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.5.0/24        AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.6.0/24        AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.8.0/24        AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.9.0/24        AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.12.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.13.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.31.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.34.0/24       AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.35.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.39.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.40.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.41.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.42.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.43.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.44.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.45.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.46.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.47.0/24       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        200.58.52.0/24       AS16814 NSS S.A.
        200.58.53.0/24       AS16814 NSS S.A.
        200.58.54.0/24       AS16814 NSS S.A.
        200.58.55.0/24       AS16814 NSS S.A.
        200.58.248.0/21      AS27849 
        201.71.16.0/20       AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.49.33.0/24       AS7657  VODAFONE-NZ-NGN-AS Vodafone NZ Ltd.
        202.58.113.0/24      AS19161 
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.142.219.0/24     AS45149 
        203.191.48.0/20      AS24175 VINAREN-AS-AP VietNam Research and Education Network
        203.191.56.0/21      AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service
        204.9.32.0/24        AS25617 
        204.9.33.0/24        AS25617 
        204.9.34.0/24        AS25617 
        204.9.35.0/24        AS25617 
        204.9.116.0/22       AS30097 NUWAVE - NuWave
        204.10.88.0/21       AS3356  LEVEL3 Level 3 Communications
        204.10.92.0/23       AS30097 NUWAVE - NuWave
        204.10.94.0/23       AS30097 NUWAVE - NuWave
        204.15.208.0/22      AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC
        204.69.144.0/24      AS27283 RJF-INTERNET - Raymond James Financial, Inc.
        204.106.16.0/24      AS4323  TWTC - tw telecom holdings, inc.
        204.115.250.0/24     AS32880 SMOOTHSTONE-IP-COMMUNICATIONS-CORP - Smoothstone IP Communications Corporation
        204.115.251.0/24     AS32880 SMOOTHSTONE-IP-COMMUNICATIONS-CORP - Smoothstone IP Communications Corporation
        204.115.252.0/23     AS32880 SMOOTHSTONE-IP-COMMUNICATIONS-CORP - Smoothstone IP Communications Corporation
        204.187.11.0/24      AS51113 ELEKTA-AS Elekta
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network
        206.81.112.0/20      AS32618 ADKNO-KC - Adknowledge, Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        206.221.176.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.177.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.178.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.179.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.180.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.181.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.182.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.183.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.184.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.185.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.186.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.187.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.188.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.189.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.190.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.191.0/24     AS27431 JTLNET - JTL Networks Inc.
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        207.254.128.0/21     AS30689 FLOW-NET - FLOW
        207.254.128.0/24     AS30689 FLOW-NET - FLOW
        207.254.136.0/21     AS30689 FLOW-NET - FLOW
        208.66.120.0/22      AS32757 
        208.66.225.0/24      AS3549  GBLX Global Crossing Ltd.
        208.66.227.0/24      AS3549  GBLX Global Crossing Ltd.
        208.74.224.0/22      AS174   COGENT Cogent/PSI
        208.75.152.0/21      AS32146 
        208.76.20.0/24       AS31812 
        208.76.21.0/24       AS31812 
        208.77.164.0/24      AS22659 
        208.77.165.0/24      AS22659 
        208.77.166.0/24      AS22659 
        208.77.167.0/24      AS22659 
        208.78.128.0/24      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        208.78.129.0/24      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        208.78.130.0/24      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        208.78.132.0/24      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        208.78.133.0/24      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        208.78.134.0/24      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.85.116.0/23      AS25956 ALPHEUS - Alpheus Data Services, L.L.C.
        208.85.212.0/22      AS32618 ADKNO-KC - Adknowledge, Inc.
        208.89.32.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.33.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.34.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.35.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.90.64.0/22       AS16415 PRCNET-DOM - Precision Response Corporation
        208.91.72.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.73.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.76.0/23       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        208.92.224.0/22      AS32757 
        208.117.128.0/18     AS36859 
        209.87.144.0/21      AS21919 
        209.87.152.0/22      AS21919 
        209.87.156.0/24      AS21919 
        209.87.157.0/24      AS21919 
        209.87.158.0/24      AS21919 
        209.87.159.0/24      AS21919 
        209.161.96.0/20      AS8039  CCC-ASN-1 - Cinergy Communications
        209.169.224.0/19     AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        209.169.228.0/24     AS11133 
        209.169.233.0/24     AS11133 
        209.169.236.0/24     AS11133 
        209.169.242.0/24     AS11133 
        209.169.243.0/24     AS11133 
        209.169.244.0/24     AS11133 
        209.169.245.0/24     AS2685  ASATTCA AT&T Global Network Services - CA
        209.169.246.0/24     AS2685  ASATTCA AT&T Global Network Services - CA
        209.169.247.0/24     AS2685  ASATTCA AT&T Global Network Services - CA
        209.169.248.0/24     AS2685  ASATTCA AT&T Global Network Services - CA
        209.169.249.0/24     AS2685  ASATTCA AT&T Global Network Services - CA
        209.169.250.0/24     AS4323  TWTC - tw telecom holdings, inc.
        209.169.251.0/24     AS2685  ASATTCA AT&T Global Network Services - CA
        209.169.252.0/24     AS11133 
        209.169.253.0/24     AS11133 
        209.169.254.0/24     AS11133 
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.193.112.0/20     AS209   ASN-QWEST-US NOVARTIS-DMZ-US
        209.209.51.0/24      AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.
        209.209.64.0/20      AS46851 IPARADIGMS - iParadigms, LLC
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc
        209.213.0.0/20       AS33005 
        209.234.112.0/23     AS32252 
        209.234.114.0/23     AS32252 
        209.234.116.0/24     AS32252 
        209.234.117.0/24     AS32252 
        209.234.118.0/24     AS32252 
        209.234.119.0/24     AS32252 
        209.234.120.0/24     AS32252 
        209.234.121.0/24     AS32252 
        209.234.122.0/24     AS32252 
        212.119.32.0/19      AS12550 
        213.184.64.0/24      AS13071 
        213.184.65.0/24      AS13071 
        213.184.66.0/24      AS13071 
        213.184.67.0/24      AS13071 
        213.184.68.0/24      AS13071 
        213.184.69.0/24      AS13071 
        213.184.70.0/24      AS13071 
        213.184.71.0/24      AS13071 
        213.184.72.0/24      AS13071 
        213.184.73.0/24      AS13071 
        213.184.74.0/24      AS13071 
        213.184.75.0/24      AS13071 
        213.184.76.0/24      AS13071 
        213.184.77.0/24      AS13071 
        213.184.78.0/24      AS13071 
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.14.64.0/20       AS14728 
        216.99.64.0/24       AS1678  DOW - The Dow Chemical Company
        216.99.65.0/24       AS1678  DOW - The Dow Chemical Company
        216.99.68.0/24       AS1678  DOW - The Dow Chemical Company
        216.99.82.0/24       AS1678  DOW - The Dow Chemical Company
        216.99.83.0/24       AS1678  DOW - The Dow Chemical Company
        216.99.85.0/24       AS1678  DOW - The Dow Chemical Company
        216.99.87.0/24       AS1678  DOW - The Dow Chemical Company
        216.146.0.0/19       AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.170.96.0/24      AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.101.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.104.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.105.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.234.128.0/22     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.139.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Nov  1 22:00:02 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 1 Nov 2013 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201311012200.rA1M02Rg034377@wattle.apnic.net>

BGP Update Report
Interval: 24-Oct-13 -to- 31-Oct-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS30693          118832  4.7%     242.0 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 2 - AS6407            53437  2.1%    1113.3 -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
 3 - AS9829            42413  1.7%      30.7 -- BSNL-NIB National Internet Backbone
 4 - AS8402            31837  1.3%      18.8 -- CORBINA-AS OJSC "Vimpelcom"
 5 - AS28573           31108  1.2%       8.6 -- NET Servi?os de Comunica??o S.A.
 6 - AS6057            23257  0.9%      57.4 -- Administracion Nacional de Telecomunicaciones
 7 - AS36998           22882  0.9%      12.3 -- SDN-MOBITEL
 8 - AS10620           21791  0.9%       8.3 -- Telmex Colombia S.A.
 9 - AS13118           21652  0.9%     470.7 -- ASN-YARTELECOM OJSC Rostelecom
10 - AS29990           21546  0.9%    1134.0 -- ASN-APPNEXUS - AppNexus, Inc
11 - AS7552            20464  0.8%      17.2 -- VIETEL-AS-AP Vietel Corporation
12 - AS35873           19784  0.8%    1798.5 -- MOVE-NETWORKS - Move Networks, inc.
13 - AS6849            17484  0.7%      19.6 -- UKRTELNET JSC UKRTELECOM,
14 - AS42334           17101  0.7%    1005.9 -- BBP-AS Broadband Plus s.a.l.
15 - AS4775            16743  0.7%     128.8 -- GLOBE-TELECOM-AS Globe Telecoms
16 - AS18403           14353  0.6%      24.9 -- FPT-AS-AP The Corporation for Financing & Promoting Technology
17 - AS8151            12915  0.5%      10.7 -- Uninet S.A. de C.V.
18 - AS9299            11499  0.5%      23.3 -- IPG-AS-AP Philippine Long Distance Telephone Company
19 - AS35819           11426  0.5%      22.2 -- MOBILY-AS Etihad Etisalat Company (Mobily)
20 - AS29049           11263  0.5%      33.4 -- DELTA-TELECOM-AS Delta Telecom LTD.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS6174             6731  0.3%    3365.5 -- SPRINTLINK8 - Sprint
 2 - AS56131            4957  0.2%    2478.5 -- UXCCONNECT-AS-AP UXC Connect Pty Ltd
 3 - AS54465            8794  0.3%    2198.5 -- QPM-AS-1 - QuickPlay Media Inc.
 4 - AS35873           19784  0.8%    1798.5 -- MOVE-NETWORKS - Move Networks, inc.
 5 - AS37367            1569  0.1%    1569.0 -- CALLKEY
 6 - AS6629             9342  0.4%    1557.0 -- NOAA-AS - NOAA
 7 - AS28493            1549  0.1%    1549.0 -- Universidad Pedagogica Nacional
 8 - AS5323             1326  0.1%    1326.0 -- DNIC-ASBLK-05120-05376 - DoD Network Information Center
 9 - AS7202             8884  0.3%    1269.1 -- FAMU - Florida A & M University
10 - AS29990           21546  0.9%    1134.0 -- ASN-APPNEXUS - AppNexus, Inc
11 - AS6407            53437  2.1%    1113.3 -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
12 - AS22592            5150  0.2%    1030.0 -- HBP - HBP, Inc.
13 - AS42334           17101  0.7%    1005.9 -- BBP-AS Broadband Plus s.a.l.
14 - AS50337            1912  0.1%     956.0 -- TETTAS-AS TETTAS SRL
15 - AS57130            1858  0.1%     929.0 -- SECPRAL-AS Secpral COM SRL
16 - AS51973            2656  0.1%     885.3 -- KOLT-AS Koltushsky Internet Ltd
17 - AS45808             882  0.0%     882.0 -- UTP-MY Bandar Seri Iskandar
18 - AS6775             5205  0.2%     867.5 -- BACKBONE_EHF_EUROPE Backbone ehf
19 - AS5487             4880  0.2%     697.1 -- Elisa Oyj
20 - AS62431             680  0.0%     680.0 -- NCSC-IE-AS National Cyber Security Centre


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 109.161.64.0/20   21588  0.8%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 103.243.220.0/22  21525  0.8%   AS29990 -- ASN-APPNEXUS - AppNexus, Inc
 3 - 23.90.5.0/24      21020  0.8%   AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 4 - 23.90.6.0/24      21013  0.8%   AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 5 - 8.20.2.0/24       19774  0.8%   AS35873 -- MOVE-NETWORKS - Move Networks, inc.
 6 - 62.84.76.0/24     17081  0.7%   AS42334 -- BBP-AS Broadband Plus s.a.l.
 7 - 23.90.21.0/24     13254  0.5%   AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 8 - 192.58.232.0/24    9337  0.3%   AS6629  -- NOAA-AS - NOAA
 9 - 206.152.15.0/24    8791  0.3%   AS54465 -- QPM-AS-1 - QuickPlay Media Inc.
10 - 202.154.17.0/24    8682  0.3%   AS4434  -- ERX-RADNET1-AS PT Rahajasa Media Internet
11 - 120.28.62.0/24     8278  0.3%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
12 - 222.127.0.0/24     8028  0.3%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
13 - 121.52.144.0/24    7887  0.3%   AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
                                     AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan
14 - 67.210.190.0/23    5851  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
15 - 67.210.188.0/23    5210  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
16 - 79.134.225.0/24    5200  0.2%   AS6775  -- BACKBONE_EHF_EUROPE Backbone ehf
17 - 208.91.124.0/22    5146  0.2%   AS22592 -- HBP - HBP, Inc.
18 - 134.211.16.0/22    4955  0.2%   AS56131 -- UXCCONNECT-AS-AP UXC Connect Pty Ltd
20 - 216.181.203.0/24   4763  0.2%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From mohta at necom830.hpcl.titech.ac.jp  Fri Nov  1 22:12:20 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 02 Nov 2013 07:12:20 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <79182.1383315326@turing-police.cc.vt.edu>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <79182.1383315326@turing-police.cc.vt.edu>
Message-ID: <52742744.2040000@necom830.hpcl.titech.ac.jp>

 Valdis.Kletnieks at vt.edu wrote:

>> It is a lot simpler and a lot more practical just to
>> use shared secret between a CPE and a ISP's name server
>> for TSIG generation.
> 
> Hmm.. Shared secret between a CPE you don't necessarily control
> and your own DNS server?

Of course. That is the very basic requirement for any security
between two parties.

						Masataka Ohta



From niels=nanog at bakker.net  Fri Nov  1 22:26:26 2013
From: niels=nanog at bakker.net (Niels Bakker)
Date: Fri, 1 Nov 2013 23:26:26 +0100
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAEd1pt41P8_Ny6sxjob3roMubwpowqgUoN4f=sVjuk6pL6iGFQ@mail.gmail.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAEd1pt41P8_Ny6sxjob3roMubwpowqgUoN4f=sVjuk6pL6iGFQ@mail.gmail.com>
Message-ID: <20131101222626.GO3108@burnout.tpb.net>

* mikal at stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>Its about the CPU cost of the crypto. I was once told the number of 
>CPUs required to do SSL on web search (which I have now forgotten) 
>and it was a bigger number than you'd expect -- certainly hundreds.

False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

"On our production frontend machines, SSL/TLS accounts for less than 
1% of the CPU load, less than 10KB of memory per connection and less 
than 2% of network overhead. Many people believe that SSL takes a lot 
of CPU time and we hope the above numbers (public for the first time) 
will help to dispel that."


	-- Niels.


From george.herbert at gmail.com  Fri Nov  1 22:36:25 2013
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 1 Nov 2013 15:36:25 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <20131101222626.GO3108@burnout.tpb.net>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAEd1pt41P8_Ny6sxjob3roMubwpowqgUoN4f=sVjuk6pL6iGFQ@mail.gmail.com>
 <20131101222626.GO3108@burnout.tpb.net>
Message-ID: <CAK__Kzv0i4s6Yy9OVGKFPNzvzZm112nTy15ghr4_-UM28QjAJQ@mail.gmail.com>

On Fri, Nov 1, 2013 at 3:26 PM, Niels Bakker <niels=nanog at bakker.net> wrote:

> * mikal at stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>
>  Its about the CPU cost of the crypto. I was once told the number of CPUs
>> required to do SSL on web search (which I have now forgotten) and it was a
>> bigger number than you'd expect -- certainly hundreds.
>>
>
> False: https://www.imperialviolet.**org/2010/06/25/overclocking-**ssl.html<https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html>
>
> "On our production frontend machines, SSL/TLS accounts for less than 1% of
> the CPU load, less than 10KB of memory per connection and less than 2% of
> network overhead. Many people believe that SSL takes a lot of CPU time and
> we hope the above numbers (public for the first time) will help to dispel
> that."


That was *front end* SSL/TLS - not internal / back end SSL/TLS.

One could assert that the per-activity SSL/TLS overhead might be the same
for internal services accessed to answer a front-end request, but that's
not necessarily true.  The code/request ratios and external/internal
SSL/TLS startup costs are going to vary wildly from service to service.


-- 
-george william herbert
george.herbert at gmail.com

From mohta at necom830.hpcl.titech.ac.jp  Fri Nov  1 22:50:15 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 02 Nov 2013 07:50:15 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131101215423.32B5896C2C5@rock.dv.isc.org>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
Message-ID: <52743027.7050203@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

>> It is a lot simpler and a lot more practical just to
>> use shared secret between a CPE and a ISP's name server
>> for TSIG generation.
> 
> No it isn't.  It requires a human to transfer the secret to the CPE
> device or to register the secret with the ISP.

Not necessarily. When the CPE is configured through DHCP (or
PPP?), the ISP can send the secret.

> I'm talking about just building this into CPE devices and having it
> just work with no human involvement.

See above.

Involving DNSSEC here is overkill and unnecessarily introduce
vulnerabilities.

						Masataka Ohta


From mohta at necom830.hpcl.titech.ac.jp  Fri Nov  1 23:01:42 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 02 Nov 2013 08:01:42 +0900
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
Message-ID: <527432D6.10903@necom830.hpcl.titech.ac.jp>

Anthony Junk wrote:

> It seems as if both Yahoo and Google assumed that since they were
> private circuits that they didn't have to encrypt.

According to Snowden, there are government agents at key
positions for managing security.

When they declare the private circuits are secure, no one
else in the companies can argue against.

Unless they are fired and all the backdoors installed by
them are removed, neither Yahoo and Google are secure.

						Masataka Ohta


From george.herbert at gmail.com  Fri Nov  1 23:29:58 2013
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 1 Nov 2013 16:29:58 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <527432D6.10903@necom830.hpcl.titech.ac.jp>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
Message-ID: <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>

On Fri, Nov 1, 2013 at 4:01 PM, Masataka Ohta <
mohta at necom830.hpcl.titech.ac.jp> wrote:

> Anthony Junk wrote:
>
> > It seems as if both Yahoo and Google assumed that since they were
> > private circuits that they didn't have to encrypt.
>
> According to Snowden, there are government agents at key
> positions for managing security.
>
> When they declare the private circuits are secure, no one
> else in the companies can argue against.
>
> Unless they are fired and all the backdoors installed by
> them are removed, neither Yahoo and Google are secure.
>

This is probably not entirely true, however...

There is certainly enough in the Snowden docs to render this a valid
question, and there is enough to assume some truth to the statement.

Anyone familiar with secure organizations will realize this as the internal
witch hunt problem.  You now have serious reason to believe that you have
been compromised.  If security needs to be absolute, then the degree of
response needed to succeed at attaining that will require very serious
vetting of all the staff, of the nature of what national security
organizations do (background checks, polygraphs, detailed personal
histories, intrusive random monitoring of employee actions in and outside
the office, etc).

Most of "us" will not put up with that.  However, most of "us" also desire
reasonably secure services (both those of us who work for those services,
and those of us who use them).

The prior default setting was to assume there was nobody trying hard enough
to penetrate those services that the internal witch hunt degree of internal
security was necessary.  It was "reasonable" to hope that someone with
nation-state / superpower level resources was not actively Trying To Get
In.  Now that's not a safe assumption.

The NSA has just put the entire profession in a horrible bind.  By going
beyond the foggy-but-legally-documented FISA warrant activities into active
hostile actions against US providers we have to wonder about what degree of
paranoia is necessary.

Do we now just stick our heads back in the sand?  Identify key security
groups with override authority within our organizations, vet them and
monitor them like the CIA and NSA vet and monitor their employees?  Try to
establish that level of review of all our staffs?

Bruce Schneier has tiptoed around this some, but the thread from his blog
last week of "How do we know we can trust Bruce" is terrifying when we have
to consider applying that question to everyone on this list (and who should
be on this list).


-- 
-george william herbert
george.herbert at gmail.com

From randy at psg.com  Fri Nov  1 23:37:12 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 01 Nov 2013 16:37:12 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
Message-ID: <m21u2zk82f.wl%randy@psg.com>

> Anyone familiar with secure organizations

there are such things?

we should be more cautious with absolutes, usually :)


From george.herbert at gmail.com  Fri Nov  1 23:39:12 2013
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 1 Nov 2013 16:39:12 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <m21u2zk82f.wl%randy@psg.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
 <m21u2zk82f.wl%randy@psg.com>
Message-ID: <CAK__Kzs754CvOx0t4HpbMbT+8i8pkpeLs1Pcb-Ot17ribAsU3A@mail.gmail.com>

On Fri, Nov 1, 2013 at 4:37 PM, Randy Bush <randy at psg.com> wrote:

> > Anyone familiar with secure organizations
>
> there are such things?
>
> we should be more cautious with absolutes, usually :)
>


Nothing is absolute, but there are certainly "white" organizations which
have no attempt to be secure, and much greyer ones where it's a big deal in
organizational process and ethos.

A Snowden once a decade or so is not a bad record.  Unfortunately, we ...
hoped ... they were the good guys, not the bad guys.


-- 
-george william herbert
george.herbert at gmail.com

From jason at biel-tech.com  Fri Nov  1 23:41:01 2013
From: jason at biel-tech.com (Jason Biel)
Date: Fri, 1 Nov 2013 18:41:01 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <m21u2zk82f.wl%randy@psg.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
 <m21u2zk82f.wl%randy@psg.com>
Message-ID: <CAGpNY1GFhFp5yJ0Bdvb0u1RYmYYKf66JVrwFsEwqt-yrZL5-ZQ@mail.gmail.com>

--------------------------
According to Snowden, there are government agents at key
positions for managing security.
-------------------------

And zero documented proof.  I'll just go ahead and put my tinfoil hat on
for the remainder of this thread.


On Fri, Nov 1, 2013 at 6:37 PM, Randy Bush <randy at psg.com> wrote:

> > Anyone familiar with secure organizations
>
> there are such things?
>
> we should be more cautious with absolutes, usually :)
>
>


-- 
Jason

From randy at psg.com  Fri Nov  1 23:48:08 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 01 Nov 2013 16:48:08 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAGpNY1GFhFp5yJ0Bdvb0u1RYmYYKf66JVrwFsEwqt-yrZL5-ZQ@mail.gmail.com>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
 <m21u2zk82f.wl%randy@psg.com>
 <CAGpNY1GFhFp5yJ0Bdvb0u1RYmYYKf66JVrwFsEwqt-yrZL5-ZQ@mail.gmail.com>
Message-ID: <m2y557iszr.wl%randy@psg.com>

> And zero documented proof.  I'll just go ahead and put my tinfoil hat on
> for the remainder of this thread.

http://www.antipope.org/charlie/blog-static/2013/10/spook-century.html


From marka at isc.org  Sat Nov  2 00:20:35 2013
From: marka at isc.org (Mark Andrews)
Date: Sat, 02 Nov 2013 11:20:35 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Sat, 02 Nov 2013 07:50:15 +0900."
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
Message-ID: <20131102002035.963BA96D853@rock.dv.isc.org>


In message <52743027.7050203 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> >> It is a lot simpler and a lot more practical just to
> >> use shared secret between a CPE and a ISP's name server
> >> for TSIG generation.
> > 
> > No it isn't.  It requires a human to transfer the secret to the CPE
> > device or to register the secret with the ISP.
> 
> Not necessarily. When the CPE is configured through DHCP (or
> PPP?), the ISP can send the secret.

Which can be seen, in many cases, by other parties which is why I
discounted plain TSIG key exchanges over DHCP years ago regardless
of which side send the key material.

> > I'm talking about just building this into CPE devices and having it
> > just work with no human involvement.
> 
> See above.
> 
> Involving DNSSEC here is overkill and unnecessarily introduce
> vulnerabilities.

You do realise that you can use KEY records without DNSSEC.  The
KEY record is in the zone to be updated so it is implictly trusted.

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


From marka at isc.org  Sat Nov  2 00:44:09 2013
From: marka at isc.org (Mark Andrews)
Date: Sat, 02 Nov 2013 11:44:09 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Sat, 02 Nov 2013 11:20:35 +1100."
 <20131102002035.963BA96D853@rock.dv.isc.org>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
Message-ID: <20131102004409.C16A496DA33@rock.dv.isc.org>


In message <20131102002035.963BA96D853 at rock.dv.isc.org>, Mark Andrews writes:
> 
> In message <52743027.7050203 at necom830.hpcl.titech.ac.jp>, Masataka Ohta write
> s:
> > Mark Andrews wrote:
> > 
> > >> It is a lot simpler and a lot more practical just to
> > >> use shared secret between a CPE and a ISP's name server
> > >> for TSIG generation.
> > > 
> > > No it isn't.  It requires a human to transfer the secret to the CPE
> > > device or to register the secret with the ISP.
> > 
> > Not necessarily. When the CPE is configured through DHCP (or
> > PPP?), the ISP can send the secret.
> 
> Which can be seen, in many cases, by other parties which is why I
> discounted plain TSIG key exchanges over DHCP years ago regardless
> of which side send the key material.

Now you could do a DH key exchange over DHCP then do a encrypted
TSIG key exchange.  This however also requires a encrypted key
exchange of the TSIG with the nameserver.  The DHCP server could
do this with TKEY.

Note a full DH key exhange is not strictly required.  The CPE could
just send a public key and the DHCP server could encrypt the TSIG
secret using it when replying.

> > > I'm talking about just building this into CPE devices and having it
> > > just work with no human involvement.
> > 
> > See above.
> > 
> > Involving DNSSEC here is overkill and unnecessarily introduce
> > vulnerabilities.
> 
> You do realise that you can use KEY records without DNSSEC.  The
> KEY record is in the zone to be updated so it is implictly trusted.
> 
> > 						Masataka Ohta
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From mohta at necom830.hpcl.titech.ac.jp  Sat Nov  2 01:47:48 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 02 Nov 2013 10:47:48 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131102002035.963BA96D853@rock.dv.isc.org>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
Message-ID: <527459C4.5000308@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

>>>> It is a lot simpler and a lot more practical just to
>>>> use shared secret between a CPE and a ISP's name server
>>>> for TSIG generation.
>>>
>>> No it isn't.  It requires a human to transfer the secret to the CPE
>>> device or to register the secret with the ISP.
>>
>> Not necessarily. When the CPE is configured through DHCP (or
>> PPP?), the ISP can send the secret.
> 
> Which can be seen, in many cases, by other parties

Who can see the packets sent from the local ISP to the CPE
directly connected to the ISP?

If you mind wire tapping, you have other things to worry
about, which needs your access line encrypted (by a manually
configured password), which makes DHCP packets invisible.

					Masataka Ohta


From alex at corp.nac.net  Sat Nov  2 01:48:50 2013
From: alex at corp.nac.net (Alex Rubenstein)
Date: Fri, 1 Nov 2013 21:48:50 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <527459C4.5000308@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB82DD7B600E6@EXCHMBX.hq.nac.net>

> >> Not necessarily. When the CPE is configured through DHCP (or PPP?),
> >> the ISP can send the secret.
> >
> > Which can be seen, in many cases, by other parties
> 
> Who can see the packets sent from the local ISP to the CPE directly
> connected to the ISP?

The NSA, FBI, CIA, DHS. Or, the ISP, the ISP's employees, contractors, sub-contractors. Or the phone company handling the PPPOE, L2TP, or whatever else. Or the WiFi sniffer on the street outside.





From hhoffman at ip-solutions.net  Sat Nov  2 02:06:56 2013
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Fri, 01 Nov 2013 22:06:56 -0400
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
Message-ID: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>

That's with a recommendation of using RC4.
Head on over to the Wikipedia page for SSL/TLS and then decide if you want rc4 to be your preference when trying to defend against a adversary with the resources of a nation-state.

Cheers,
Harry

Niels Bakker <niels=nanog at bakker.net> wrote:

>* mikal at stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>Its about the CPU cost of the crypto. I was once told the number of 
>>CPUs required to do SSL on web search (which I have now forgotten) 
>>and it was a bigger number than you'd expect -- certainly hundreds.
>
>False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>
>"On our production frontend machines, SSL/TLS accounts for less than 
>1% of the CPU load, less than 10KB of memory per connection and less 
>than 2% of network overhead. Many people believe that SSL takes a lot 
>of CPU time and we hope the above numbers (public for the first time) 
>will help to dispel that."
>
>
>	-- Niels.
>

From ongbh at ispworkshop.com  Sat Nov  2 02:13:50 2013
From: ongbh at ispworkshop.com (Beng Hui Ong)
Date: Sat, 02 Nov 2013 10:13:50 +0800
Subject: Reverse DNS RFCs and Recommendations
Message-ID: <jcn5vuk5ioh4i8fx79b14y34.1383358430838@email.android.com>

we cannot assume that the connection between isp and cpe is a single entity. 

a typical example will be the guy who run the dslam and the guy who run the bras belong to two different companies in market which mandate open access.

Alex Rubenstein <alex at corp.nac.net> wrote:

>> >> Not necessarily. When the CPE is configured through DHCP (or PPP?),
>> >> the ISP can send the secret.
>> >
>> > Which can be seen, in many cases, by other parties
>> 
>> Who can see the packets sent from the local ISP to the CPE directly
>> connected to the ISP?
>
>The NSA, FBI, CIA, DHS. Or, the ISP, the ISP's employees, contractors, sub-contractors. Or the phone company handling the PPPOE, L2TP, or whatever else. Or the WiFi sniffer on the street outside.
>
>
>
>

From mohta at necom830.hpcl.titech.ac.jp  Sat Nov  2 02:17:34 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 02 Nov 2013 11:17:34 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB82DD7B600E6@EXCHMBX.hq.nac.net>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <2D0AF14BA6FB334988BC1F5D4FC38CB82DD7B600E6@EXCHMBX.hq.nac.net>
Message-ID: <527460BE.5060004@necom830.hpcl.titech.ac.jp>

(2013/11/02 10:48), Alex Rubenstein wrote:
>>>> Not necessarily. When the CPE is configured through DHCP (or PPP?),
>>>> the ISP can send the secret.
>>>
>>> Which can be seen, in many cases, by other parties
>>
>> Who can see the packets sent from the local ISP to the CPE directly
>> connected to the ISP?
> 
> The NSA, FBI, CIA, DHS.

>> If you mind wire tapping, you have other things to worry
>> about, which needs your access line encrypted (by a manually
>> configured password), which makes DHCP packets invisible.

> Or, the ISP, the ISP's employees, contractors, sub-contractors.

If you can't trust the ISP, you can't make rDNS operated
by the ISP secure.

> Or the phone company handling the PPPOE, L2TP, or whatever else.

>> If you mind wire tapping, you have other things to worry
>> about, which needs your access line encrypted (by a manually
>> configured password), which makes DHCP packets invisible.

> Or the WiFi sniffer on the street outside.

Does your CPE retransmit a received DHCP reply to Wifi?

						Masataka Ohta



From mike.lyon at gmail.com  Sat Nov  2 02:18:59 2013
From: mike.lyon at gmail.com (Mike Lyon)
Date: Fri, 1 Nov 2013 19:18:59 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
References: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
Message-ID: <-7027351400541268817@unknownmsgid>

So even if Goog or Yahoo encrypt their data between DCs, what stops
the NSA from decrypting that data? Or would it be done simply to make
their lives a bit more of a PiTA to get the data they want?

-Mike



> On Nov 1, 2013, at 19:08, Harry Hoffman <hhoffman at ip-solutions.net> wrote:
>
> That's with a recommendation of using RC4.
> Head on over to the Wikipedia page for SSL/TLS and then decide if you want rc4 to be your preference when trying to defend against a adversary with the resources of a nation-state.
>
> Cheers,
> Harry
>
> Niels Bakker <niels=nanog at bakker.net> wrote:
>
>> * mikal at stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>> Its about the CPU cost of the crypto. I was once told the number of
>>> CPUs required to do SSL on web search (which I have now forgotten)
>>> and it was a bigger number than you'd expect -- certainly hundreds.
>>
>> False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>
>> "On our production frontend machines, SSL/TLS accounts for less than
>> 1% of the CPU load, less than 10KB of memory per connection and less
>> than 2% of network overhead. Many people believe that SSL takes a lot
>> of CPU time and we hope the above numbers (public for the first time)
>> will help to dispel that."
>>
>>
>>    -- Niels.
>>


From alex at corp.nac.net  Sat Nov  2 02:19:52 2013
From: alex at corp.nac.net (Alex Rubenstein)
Date: Fri, 1 Nov 2013 22:19:52 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <jcn5vuk5ioh4i8fx79b14y34.1383358430838@email.android.com>
References: <jcn5vuk5ioh4i8fx79b14y34.1383358430838@email.android.com>
Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB82DD7B600E9@EXCHMBX.hq.nac.net>

> we cannot assume that the connection between isp and cpe is a single entity.
> 
> a typical example will be the guy who run the dslam and the guy who run the
> bras belong to two different companies in market which mandate open
> access.

... which is very, very common.



From mohta at necom830.hpcl.titech.ac.jp  Sat Nov  2 02:30:57 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 02 Nov 2013 11:30:57 +0900
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
References: <17761383158810@web2j.yandex.ru>	<83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>	<CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>	<527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
Message-ID: <527463E1.1080201@necom830.hpcl.titech.ac.jp>

George Herbert wrote:

> Anyone familiar with secure organizations will realize this as the
> internal witch hunt problem.

No hunting necessary to fire those agents who are hired at the
request of NSA/CIA.

It is also reasonable to fire those who are hired by the agents,
recursively.

					Masataka Ohta


From hhoffman at ip-solutions.net  Sat Nov  2 02:32:45 2013
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Fri, 01 Nov 2013 22:32:45 -0400
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
Message-ID: <343r7gx04ytwcbscqbx9luey.1383359565953@email.android.com>

So, I'm not sure if I'm being too simple-minded in my response. Please let me know if I am.
The purpose of encrypting data is so others can't read your secrets.
If you use a simple substitution cipher it's pretty easy to derive the set of substitution rules used.
Stronger encryption algorithms employ more "difficult" math. Figuring out how to get from the ciphertext to the plaintext becomes a, computationally, difficult task.
If your encryption algorithms are "good" *and* your source of random data is really random then the amount of time it takes to decrypt the data is so far out that it makes the data useless.

Cheers,
Harry

Mike Lyon <mike.lyon at gmail.com> wrote:

>So even if Goog or Yahoo encrypt their data between DCs, what stops
>the NSA from decrypting that data? Or would it be done simply to make
>their lives a bit more of a PiTA to get the data they want?
>
>-Mike
>
>
>
>> On Nov 1, 2013, at 19:08, Harry Hoffman <hhoffman at ip-solutions.net> wrote:
>>
>> That's with a recommendation of using RC4.
>> Head on over to the Wikipedia page for SSL/TLS and then decide if you want rc4 to be your preference when trying to defend against a adversary with the resources of a nation-state.
>>
>> Cheers,
>> Harry
>>
>> Niels Bakker <niels=nanog at bakker.net> wrote:
>>
>>> * mikal at stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>>> Its about the CPU cost of the crypto. I was once told the number of
>>>> CPUs required to do SSL on web search (which I have now forgotten)
>>>> and it was a bigger number than you'd expect -- certainly hundreds.
>>>
>>> False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>>
>>> "On our production frontend machines, SSL/TLS accounts for less than
>>> 1% of the CPU load, less than 10KB of memory per connection and less
>>> than 2% of network overhead. Many people believe that SSL takes a lot
>>> of CPU time and we hope the above numbers (public for the first time)
>>> will help to dispel that."
>>>
>>>
>>>    -- Niels.
>>>

From mike.lyon at gmail.com  Sat Nov  2 02:35:22 2013
From: mike.lyon at gmail.com (Mike Lyon)
Date: Fri, 1 Nov 2013 19:35:22 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <343r7gx04ytwcbscqbx9luey.1383359565953@email.android.com>
References: <343r7gx04ytwcbscqbx9luey.1383359565953@email.android.com>
Message-ID: <2636225785171166238@unknownmsgid>

So the latter, PITA, reason then...

-Mike



> On Nov 1, 2013, at 19:32, Harry Hoffman <hhoffman at ip-solutions.net> wrote:
>
> So, I'm not sure if I'm being too simple-minded in my response. Please let me know if I am.
> The purpose of encrypting data is so others can't read your secrets.
> If you use a simple substitution cipher it's pretty easy to derive the set of substitution rules used.
> Stronger encryption algorithms employ more "difficult" math. Figuring out how to get from the ciphertext to the plaintext becomes a, computationally, difficult task.
> If your encryption algorithms are "good" *and* your source of random data is really random then the amount of time it takes to decrypt the data is so far out that it makes the data useless.
>
> Cheers,
> Harry
>
> Mike Lyon <mike.lyon at gmail.com> wrote:
>
>> So even if Goog or Yahoo encrypt their data between DCs, what stops
>> the NSA from decrypting that data? Or would it be done simply to make
>> their lives a bit more of a PiTA to get the data they want?
>>
>> -Mike
>>
>>
>>
>>> On Nov 1, 2013, at 19:08, Harry Hoffman <hhoffman at ip-solutions.net> wrote:
>>>
>>> That's with a recommendation of using RC4.
>>> Head on over to the Wikipedia page for SSL/TLS and then decide if you want rc4 to be your preference when trying to defend against a adversary with the resources of a nation-state.
>>>
>>> Cheers,
>>> Harry
>>>
>>> Niels Bakker <niels=nanog at bakker.net> wrote:
>>>
>>>> * mikal at stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>>>> Its about the CPU cost of the crypto. I was once told the number of
>>>>> CPUs required to do SSL on web search (which I have now forgotten)
>>>>> and it was a bigger number than you'd expect -- certainly hundreds.
>>>>
>>>> False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>>>
>>>> "On our production frontend machines, SSL/TLS accounts for less than
>>>> 1% of the CPU load, less than 10KB of memory per connection and less
>>>> than 2% of network overhead. Many people believe that SSL takes a lot
>>>> of CPU time and we hope the above numbers (public for the first time)
>>>> will help to dispel that."
>>>>
>>>>
>>>>   -- Niels.
>>>>


From lyndon at orthanc.ca  Sat Nov  2 02:35:40 2013
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Fri, 1 Nov 2013 19:35:40 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <-7027351400541268817@unknownmsgid>
References: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
 <-7027351400541268817@unknownmsgid>
Message-ID: <D57D3614-5A7A-4777-A985-84EA2670A0BF@orthanc.ca>


On Nov 1, 2013, at 7:18 PM, Mike Lyon <mike.lyon at gmail.com> wrote:

> So even if Goog or Yahoo encrypt their data between DCs, what stops
> the NSA from decrypting that data? Or would it be done simply to make
> their lives a bit more of a PiTA to get the data they want?

Markhov chain text generators are cheap.  Rather than amping up the crypto, why not bury them under heaping piles of steaming bullshit?

After all, it would be the patriotic thing to do.  Not only would you be helping employ your fellow network engineers (someone has to increase the size of the effluent pipes), you would be boosting manufacturing (disks for storage, high-end network gear for capture, mainframes and asics for filtering and analysis) and helping the much-maligned coal industry ensure its future prospects (that gear isn't built from electron sipping Atom CPUs, you know!).

--lyndon



From randy_94108 at yahoo.com  Sat Nov  2 03:29:22 2013
From: randy_94108 at yahoo.com (Randy)
Date: Fri, 1 Nov 2013 20:29:22 -0700 (PDT)
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <343r7gx04ytwcbscqbx9luey.1383359565953@email.android.com>
References: <343r7gx04ytwcbscqbx9luey.1383359565953@email.android.com>
Message-ID: <1383362962.67631.YahooMailNeo@web184703.mail.ne1.yahoo.com>

Big Brother is always watching and Big Brother has way more resources than network-operators in this list!
(good discussion all the same)

a) politics is the last-resort for scoundrels
b) power corrupts and absolute-power(FBI, CIA, NSA, DHS..etc,) corrupts-absolutely.

I speak from this-side-of-the-pond and I have no doubt that this thread is being monitored as well by (b) and no; I don't have my tinfoil-hat on.

To answer your question:

Not Much.
./Randy







----- Original Message -----
> From: Harry Hoffman <hhoffman at ip-solutions.net>
> To: Mike Lyon <mike.lyon at gmail.com>
> Cc: Niels Bakker <niels=nanog at bakker.net>; nanog at nanog.org
> Sent: Friday, November 1, 2013 7:32 PM
> Subject: Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
> 
> So, I'm not sure if I'm being too simple-minded in my response. Please 
> let me know if I am.
> The purpose of encrypting data is so others can't read your secrets.
> If you use a simple substitution cipher it's pretty easy to derive the set 
> of substitution rules used.
> Stronger encryption algorithms employ more "difficult" math. Figuring 
> out how to get from the ciphertext to the plaintext becomes a, computationally, 
> difficult task.
> If your encryption algorithms are "good" *and* your source of random 
> data is really random then the amount of time it takes to decrypt the data is so 
> far out that it makes the data useless.
> 
> Cheers,
> Harry
> 
> Mike Lyon <mike.lyon at gmail.com> wrote:
> 
>> So even if Goog or Yahoo encrypt their data between DCs, what stops
>> the NSA from decrypting that data? Or would it be done simply to make
>> their lives a bit more of a PiTA to get the data they want?
>> 
>> -Mike
>> 
>> 
>> 
>>>  On Nov 1, 2013, at 19:08, Harry Hoffman 
> <hhoffman at ip-solutions.net> wrote:
>>> 
>>>  That's with a recommendation of using RC4.
>>>  Head on over to the Wikipedia page for SSL/TLS and then decide if you 
> want rc4 to be your preference when trying to defend against a adversary with 
> the resources of a nation-state.
>>> 
>>>  Cheers,
>>>  Harry
>>> 
>>>  Niels Bakker <niels=nanog at bakker.net> wrote:
>>> 
>>>>  * mikal at stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>>>>  Its about the CPU cost of the crypto. I was once told the 
> number of
>>>>>  CPUs required to do SSL on web search (which I have now 
> forgotten)
>>>>>  and it was a bigger number than you'd expect -- certainly 
> hundreds.
>>>> 
>>>>  False: 
> https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>>> 
>>>>  "On our production frontend machines, SSL/TLS accounts for 
> less than
>>>>  1% of the CPU load, less than 10KB of memory per connection and 
> less
>>>>  than 2% of network overhead. Many people believe that SSL takes a 
> lot
>>>>  of CPU time and we hope the above numbers (public for the first 
> time)
>>>>  will help to dispel that."
>>>> 
>>>> 
>>>> ? ? -- Niels.
>>>> 
> 


From joelja at bogus.com  Sat Nov  2 03:40:24 2013
From: joelja at bogus.com (joel jaeggli)
Date: Fri, 1 Nov 2013 20:40:24 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
References: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
Message-ID: <A9ED2DAE-9093-4948-95CA-4CA3B31571D5@bogus.com>


On Nov 1, 2013, at 7:06 PM, Harry Hoffman <hhoffman at ip-solutions.net> wrote:

> That's with a recommendation of using RC4.

it?s also with 1024 bit keys in the key exchange.

> Head on over to the Wikipedia page for SSL/TLS and then decide if you want rc4 to be your preference when trying to defend against a adversary with the resources of a nation-state.
> 
> Cheers,
> Harry
> 
> Niels Bakker <niels=nanog at bakker.net> wrote:
> 
>> * mikal at stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>> Its about the CPU cost of the crypto. I was once told the number of 
>>> CPUs required to do SSL on web search (which I have now forgotten) 
>>> and it was a bigger number than you'd expect -- certainly hundreds.
>> 
>> False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>> 
>> "On our production frontend machines, SSL/TLS accounts for less than 
>> 1% of the CPU load, less than 10KB of memory per connection and less 
>> than 2% of network overhead. Many people believe that SSL takes a lot 
>> of CPU time and we hope the above numbers (public for the first time) 
>> will help to dispel that."
>> 
>> 
>> 	-- Niels.
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131101/d97aeacc/attachment.bin>

From johns at sstar.com  Sat Nov  2 04:00:11 2013
From: johns at sstar.com (John Souvestre)
Date: Fri, 1 Nov 2013 23:00:11 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <-7027351400541268817@unknownmsgid>
References: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
 <-7027351400541268817@unknownmsgid>
Message-ID: <070c01ced780$0d07e510$2717af30$@sstar.com>

Money.  The better the encryption the more it costs to crack.  With forward
security you can even protect against your private key leaking.

In short, you can raise the stakes and make it economically unfeasible for
even the NSA.

John

??? John Souvestre - New Orleans LA - (504) 454-0899


-----Original Message-----
From: Mike Lyon [mailto:mike.lyon at gmail.com] 
Sent: Fri, November 01, 2013 9:19 pm
To: Harry Hoffman
Cc: Niels Bakker; nanog at nanog.org
Subject: Re: latest Snowden docs show NSA intercepts all Google and Yahoo
DC-to-DC traffic

So even if Goog or Yahoo encrypt their data between DCs, what stops the NSA
from decrypting that data? Or would it be done simply to make their lives a
bit more of a PiTA to get the data they want?

-Mike



> On Nov 1, 2013, at 19:08, Harry Hoffman <hhoffman at ip-solutions.net> wrote:
>
> That's with a recommendation of using RC4.
> Head on over to the Wikipedia page for SSL/TLS and then decide if you want
rc4 to be your preference when trying to defend against a adversary with the
resources of a nation-state.
>
> Cheers,
> Harry
>
> Niels Bakker <niels=nanog at bakker.net> wrote:
>
>> * mikal at stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>> Its about the CPU cost of the crypto. I was once told the number of 
>>> CPUs required to do SSL on web search (which I have now forgotten) 
>>> and it was a bigger number than you'd expect -- certainly hundreds.
>>
>> False: 
>> https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>
>> "On our production frontend machines, SSL/TLS accounts for less than 
>> 1% of the CPU load, less than 10KB of memory per connection and less 
>> than 2% of network overhead. Many people believe that SSL takes a lot 
>> of CPU time and we hope the above numbers (public for the first time) 
>> will help to dispel that."
>>
>>
>>    -- Niels.
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6298 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131101/7491e1da/attachment-0001.bin>

From mysidia at gmail.com  Sat Nov  2 04:05:30 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 1 Nov 2013 23:05:30 -0500
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB82DD7B600E9@EXCHMBX.hq.nac.net>
References: <jcn5vuk5ioh4i8fx79b14y34.1383358430838@email.android.com>
 <2D0AF14BA6FB334988BC1F5D4FC38CB82DD7B600E9@EXCHMBX.hq.nac.net>
Message-ID: <CAAAwwbV2zgqNeQ=t8mpW-xh7ZqBqqktTjYaM7DQue7sSGobZEA@mail.gmail.com>

On Fri, Nov 1, 2013 at 9:19 PM, Alex Rubenstein <alex at corp.nac.net> wrote:

> > a typical example will be the guy who run the dslam and the guy who run
> the
> > bras belong to two different companies in market which mandate open
> > access.
> ... which is very, very common.
>

It's also a troublesome situation for the ISP;  it may be  "open access" on
paper,  but  DSLAMs and  bras  break,  and then the ISP is potentially at
the mercy of  bureaucratic support walls and the  DSLAM operator,   who
would love to create as many weeks delay in repair as possible and pay lip
service to getting issues addressed;  for the end user to get frustrated,
blame the ISP, and switch service  to their own.


But yeah....  sniffing/tapping can target    the underlying link provider.

Or it can even involve  agents  tapping into  copper wires  with alligator
clips,  unbeknownst to even the DSLAM operator.....


The trouble with end-to-end encryption as a solution;    is the
difficulty/impossibility  of   establishing   ipsec SAs  with   arbitrary
hosts on the internet;  without manual pre-configuration  of every pair of
hosts.


-- 
-JH

From marka at isc.org  Sat Nov  2 04:13:02 2013
From: marka at isc.org (Mark Andrews)
Date: Sat, 02 Nov 2013 15:13:02 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Sat, 02 Nov 2013 10:47:48 +0900."
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
Message-ID: <20131102041302.41D5396E981@rock.dv.isc.org>


In message <527459C4.5000308 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> >>>> It is a lot simpler and a lot more practical just to
> >>>> use shared secret between a CPE and a ISP's name server
> >>>> for TSIG generation.
> >>>
> >>> No it isn't.  It requires a human to transfer the secret to the CPE
> >>> device or to register the secret with the ISP.
> >>
> >> Not necessarily. When the CPE is configured through DHCP (or
> >> PPP?), the ISP can send the secret.
> > 
> > Which can be seen, in many cases, by other parties
> 
> Who can see the packets sent from the local ISP to the CPE
> directly connected to the ISP?

The dhcpd traffic coming in over the cable modem and you want to
send secrets in the clear over a channel like this.

bsdi# tcpdump -n -i sis0 port bootpc
tcpdump: listening on sis0
15:05:15.637252 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc58c07ae flags:0x8000 Y:122.106.168.231 G:10.72.0.1 ether 0:1d:9:81:64:ba [|bootp]
15:05:15.650590 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc58c07ae flags:0x8000 Y:122.106.168.231 G:10.72.0.1 ether 0:1d:9:81:64:ba [|bootp]
15:05:34.942619 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x122cf3bb flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 0:17:ee:4c:f3:74 [|bootp]
15:05:36.975213 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x122cf3bb secs:2 flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 0:17:ee:4c:f3:74 [|bootp]
15:05:36.992714 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x122cf3bb secs:2 flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 0:17:ee:4c:f3:74 [|bootp]
15:05:55.931705 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x732 flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp]
15:05:57.951400 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x732 secs:2 flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp]
15:05:57.964049 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x732 secs:2 flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp]
15:05:58.930921 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc7dba2af flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp]
15:06:00.054322 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc7dba2b0 flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp]
15:06:00.068061 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc7dba2b0 flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp]
15:06:08.933232 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x111fb9c2 flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 0:1a:de:6f:99:e6 [|bootp]
15:06:10.941233 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x111fb9c2 secs:2 flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 0:1a:de:6f:99:e6 [|bootp]
15:06:10.959519 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x111fb9c2 secs:2 flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 0:1a:de:6f:99:e6 [|bootp]
^C
10638 packets received by filter
0 packets dropped by kernel
bsdi# 

> If you mind wire tapping, you have other things to worry
> about, which needs your access line encrypted (by a manually
> configured password), which makes DHCP packets invisible.
> 
> 					Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From randy at psg.com  Sat Nov  2 04:58:42 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 01 Nov 2013 21:58:42 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
References: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
Message-ID: <m2fvrfiem5.wl%randy@psg.com>

> Head on over to the Wikipedia page for SSL/TLS and then decide if you
> want rc4 to be your preference when trying to defend against a
> adversary with the resources of a nation-state.

i got hit with the clue bat on this one.

we have kinda settled on allowing rc4 for smtp as the least preferred.
if we did not it would fall back to cleartext.

otoh, for web, all browsers can do better, so we don't allow rc4

ykmv

randy


From mohta at necom830.hpcl.titech.ac.jp  Sat Nov  2 07:17:48 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 02 Nov 2013 16:17:48 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <CAAAwwbV2zgqNeQ=t8mpW-xh7ZqBqqktTjYaM7DQue7sSGobZEA@mail.gmail.com>
References: <jcn5vuk5ioh4i8fx79b14y34.1383358430838@email.android.com>
 <2D0AF14BA6FB334988BC1F5D4FC38CB82DD7B600E9@EXCHMBX.hq.nac.net>
 <CAAAwwbV2zgqNeQ=t8mpW-xh7ZqBqqktTjYaM7DQue7sSGobZEA@mail.gmail.com>
Message-ID: <5274A71C.8030807@necom830.hpcl.titech.ac.jp>

Jimmy Hess wrote:

> The trouble with end-to-end encryption as a solution;    is the
> difficulty/impossibility  of   establishing   ipsec SAs  with   arbitrary
> hosts on the internet;  without manual pre-configuration  of every pair of
> hosts.

In this case, the ISP and the CPE are physically and directly
connected with modest security, which makes automation possible.

						Masataka Ohta


From mohta at necom830.hpcl.titech.ac.jp  Sat Nov  2 07:19:22 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 02 Nov 2013 16:19:22 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131102041302.41D5396E981@rock.dv.isc.org>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
Message-ID: <5274A77A.8090403@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

>> Who can see the packets sent from the local ISP to the CPE
>> directly connected to the ISP?
> 
> The dhcpd traffic coming in over the cable modem and you want to
> send secrets in the clear over a channel like this.

Over the cable modem?

The cable modem is the CPE, which accept the DHCP packet to it.

						Masataka Ohta


From mpetach at netflight.com  Sat Nov  2 07:21:55 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 2 Nov 2013 00:21:55 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <-7027351400541268817@unknownmsgid>
References: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
 <-7027351400541268817@unknownmsgid>
Message-ID: <CAEmG1=raMa5pDp4Q3_Aq+iB74q3yQgNRJbtaXJPgQdm-R72Y4Q@mail.gmail.com>

On Fri, Nov 1, 2013 at 7:18 PM, Mike Lyon <mike.lyon at gmail.com> wrote:

> So even if Goog or Yahoo encrypt their data between DCs, what stops
> the NSA from decrypting that data? Or would it be done simply to make
> their lives a bit more of a PiTA to get the data they want?
>
> -Mike
>


I'm just gonna toss this URL out here...


http://www.gdc4s.com/Documents/Products/SecureVoiceData/NetworkEncryption/KG-530_Price_2-1-2012.pdf

and note the terms and conditions for purchase:

General Terms & Conditions
?
Delivery dates for all products will be established by General Dynamics
at the time of order acceptance.
?
All specifications, products and pricing are subject to change or
discontinuance at anytime without notice.
?
Prior written approval from the National Security Agency (General Dynamics
will submit request) and a current
COMSEC account is required for all purchases


I'll leave it as an exercise for the reader to
think about what it means to put encryption
technology into the network that requires
written approval from the NSA to purchase...

Matt





>
>
> > On Nov 1, 2013, at 19:08, Harry Hoffman <hhoffman at ip-solutions.net>
> wrote:
> >
> > That's with a recommendation of using RC4.
> > Head on over to the Wikipedia page for SSL/TLS and then decide if you
> want rc4 to be your preference when trying to defend against a adversary
> with the resources of a nation-state.
> >
> > Cheers,
> > Harry
> >
> > Niels Bakker <niels=nanog at bakker.net> wrote:
> >
> >> * mikal at stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
> >>> Its about the CPU cost of the crypto. I was once told the number of
> >>> CPUs required to do SSL on web search (which I have now forgotten)
> >>> and it was a bigger number than you'd expect -- certainly hundreds.
> >>
> >> False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
> >>
> >> "On our production frontend machines, SSL/TLS accounts for less than
> >> 1% of the CPU load, less than 10KB of memory per connection and less
> >> than 2% of network overhead. Many people believe that SSL takes a lot
> >> of CPU time and we hope the above numbers (public for the first time)
> >> will help to dispel that."
> >>
> >>
> >>    -- Niels.
> >>
>
>

From marka at isc.org  Sat Nov  2 10:51:33 2013
From: marka at isc.org (Mark Andrews)
Date: Sat, 02 Nov 2013 21:51:33 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Sat, 02 Nov 2013 16:19:22 +0900."
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
Message-ID: <20131102105133.96AB496F732@rock.dv.isc.org>


In message <5274A77A.8090403 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> >> Who can see the packets sent from the local ISP to the CPE
> >> directly connected to the ISP?
> > 
> > The dhcpd traffic coming in over the cable modem and you want to
> > send secrets in the clear over a channel like this.
> 
> Over the cable modem?

Yes.
 
> The cable modem is the CPE, which accept the DHCP packet to it.

A cable modem both accepts DHCP packets (for management of the
modem) and passes DHCP packets through to the customer device.

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


From mohta at necom830.hpcl.titech.ac.jp  Sat Nov  2 11:16:09 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 02 Nov 2013 20:16:09 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131102105133.96AB496F732@rock.dv.isc.org>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
Message-ID: <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

>> Over the cable modem?
> 
> Yes.

OK.

>> The cable modem is the CPE, which accept the DHCP packet to it.
> 
> A cable modem both accepts DHCP packets (for management of the
> modem) and passes DHCP packets through to the customer device.

Even if the CPE does so, which means there is no NAT, the key
to update rDNS must, naturally, be contained only in DHCP reply
to the CPE.

And, I'm afraid your draft assumes that the CPE behaves as a
DHCP server for local hosts, which means the CPE is responsible
for rDNS registration.

						Masataka Ohta


From sander at steffann.nl  Sat Nov  2 11:27:55 2013
From: sander at steffann.nl (Sander Steffann)
Date: Sat, 2 Nov 2013 12:27:55 +0100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
Message-ID: <AAC2BED5-AE55-4AAB-9212-B14CC8CF1FD5@steffann.nl>

Hi,

Op 2 nov. 2013, om 12:16 heeft Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp> het volgende geschreven:

> Mark Andrews wrote:
> 
>> A cable modem both accepts DHCP packets (for management of the
>> modem) and passes DHCP packets through to the customer device.
> 
> Even if the CPE does so, which means there is no NAT, the key
> to update rDNS must, naturally, be contained only in DHCP reply
> to the CPE.

You are misunderstanding the technology. Many cable operators offer a cable modem in bridged mode so that the customer can attach his own home-router behind it. Sending keys over a medium shared between multiple customers is not safe.

Cheers,
Sander



From marka at isc.org  Sat Nov  2 11:38:12 2013
From: marka at isc.org (Mark Andrews)
Date: Sat, 02 Nov 2013 22:38:12 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Sat, 02 Nov 2013 20:16:09 +0900."
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
Message-ID: <20131102113812.AE3F896F959@rock.dv.isc.org>


In message <5274DEF9.3040405 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> >> Over the cable modem?
> > 
> > Yes.
> 
> OK.
> 
> >> The cable modem is the CPE, which accept the DHCP packet to it.
> > 
> > A cable modem both accepts DHCP packets (for management of the
> > modem) and passes DHCP packets through to the customer device.
> 
> Even if the CPE does so, which means there is no NAT, the key
> to update rDNS must, naturally, be contained only in DHCP reply
> to the CPE.

A cable modem is a media converter.  That can be managed and that
management interface also uses DHCP is irrelevent.

> And, I'm afraid your draft assumes that the CPE behaves as a
> DHCP server for local hosts, which means the CPE is responsible
> for rDNS registration.

My draft assumes the CPE device is a PD client.  It may or may not
be a DHCP server for the internal network.  Again that is irrelevent.

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


From mohta at necom830.hpcl.titech.ac.jp  Sat Nov  2 12:39:41 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 02 Nov 2013 21:39:41 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <AAC2BED5-AE55-4AAB-9212-B14CC8CF1FD5@steffann.nl>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
 <AAC2BED5-AE55-4AAB-9212-B14CC8CF1FD5@steffann.nl>
Message-ID: <5274F28D.7080400@necom830.hpcl.titech.ac.jp>

Sander Steffann wrote:

> Hi,

Hi,

>> Even if the CPE does so, which means there is no NAT, the key to
>> update rDNS must, naturally, be contained only in DHCP reply to the
>> CPE.
> 
> You are misunderstanding the technology. Many cable operators offer a
> cable modem in bridged mode so that the customer can attach his own
> home-router behind it.

The situation is no different from:

>> If you mind wire tapping, you have other things to worry
>> about, which needs your access line encrypted (by a manually
>> configured password), which makes DHCP packets invisible.

Though some ISPs do not operate their network very securely,
you can't have better security than that offered by your local
ISP.

Also remember that this thread is on secure rDNS by the ISP,
which means you can't expect the ISP operate rDNS very securely
even though the ISP operate rest of networking not very securely.

					Masataka Ohta


From mike at mtcc.com  Sat Nov  2 13:35:04 2013
From: mike at mtcc.com (Michael Thomas)
Date: Sat, 02 Nov 2013 06:35:04 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <-7027351400541268817@unknownmsgid>
References: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
 <-7027351400541268817@unknownmsgid>
Message-ID: <5274FF88.4070309@mtcc.com>

On 11/01/2013 07:18 PM, Mike Lyon wrote:
> So even if Goog or Yahoo encrypt their data between DCs, what stops
> the NSA from decrypting that data? Or would it be done simply to make
> their lives a bit more of a PiTA to get the data they want?
>
>

My bet is that when the said the were "partially" capable of 
intercepting things,
that means that they haven't broken any of the usual suspects in a 
spectacular
way, but instead are using anything they can think of to do what they 
want to
do. So all of the known crypto vulnerabilities, backdoors, breakins, 
etc, etc are
added to the "partial" bucket. And it wouldn't surprise me that that 
"partial" is
an impressive amount, because so much of internet security is a big old 
maginot
line.

Mike


From sander at steffann.nl  Sat Nov  2 14:44:28 2013
From: sander at steffann.nl (Sander Steffann)
Date: Sat, 2 Nov 2013 15:44:28 +0100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <5274F28D.7080400@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
 <AAC2BED5-AE55-4AAB-9212-B14CC8CF1FD5@steffann.nl>
 <5274F28D.7080400@necom830.hpcl.titech.ac.jp>
Message-ID: <81B1C5A3-AF5C-4DBF-87A4-C62FB8C2A8D0@steffann.nl>

Hi,

> Also remember that this thread is on secure rDNS by the ISP,
> which means you can't expect the ISP operate rDNS very securely
> even though the ISP operate rest of networking not very securely.

You're linking things together that are completely orthogonal...
Sander



From jra at baylink.com  Sat Nov  2 17:12:54 2013
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 02 Nov 2013 13:12:54 -0400
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
Message-ID: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>

The balkanizing of the Net?

http://www.washingtonpost.com/blogs/worldviews/wp/2013/11/01/how-anti-nsa-backlash-could-fracture-the-internet-along-national-borders/

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

From mysidia at gmail.com  Sat Nov  2 18:42:04 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 2 Nov 2013 13:42:04 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <A9ED2DAE-9093-4948-95CA-4CA3B31571D5@bogus.com>
References: <ipw7acuqm87i0hwdiek14wll.1383358016384@email.android.com>
 <A9ED2DAE-9093-4948-95CA-4CA3B31571D5@bogus.com>
Message-ID: <CAAAwwbUnoua1wMonjfb2DWEYWbTjxmXX1ypAnUMB6e2BXAhOQA@mail.gmail.com>

On Fri, Nov 1, 2013 at 10:40 PM, joel jaeggli <joelja at bogus.com> wrote:

>  On Nov 1, 2013, at 7:06 PM, Harry Hoffman <hhoffman at ip-solutions.net>
> wrote:
> > That's with a recommendation of using RC4.
> it?s also with 1024 bit keys in the key exchange.
>

Better leverage quantum encryption tech to exchange those symmetric keys
securely;  I wouldn't be surprised if the NSA  has  DH,  DSA, and RSA  key
exchange schemes defeated or backdoored.

RC4 while not a particularly strong cipher may be strong enough
cryptography to dissaude the NSA,  until the matter comes up to budgeting,
and they get a few hundred billion extra in taxpayer money allocated in
order to get their truckload of ASICs live for rapidly brute-forcing RC4
keys, or AES keys, or  $cipher_of_the_day_keys.

With near certainty,  there would be more invasive methods of attack
available that do not require beating the actual cipher algorithm, and they
would exploit any available options --- figure out which devices are
responsible for doing the encryption, and  compromise the security of those
instead.

oh RC4 may be strong enough otherwise, but the cryptosystem or library that
actually implements the AES RC4 or whatever key/cipher scheme, weak.   It's
also entirely possible, the implementation you get of RC4, AES, RSA,
 etc... will contain subtle backdoors in the library, that reduce the
cipher strength to a level far less.


--
-JH

From johnl at iecc.com  Sat Nov  2 19:06:29 2013
From: johnl at iecc.com (John Levine)
Date: 2 Nov 2013 19:06:29 -0000
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
Message-ID: <20131102190629.99625.qmail@joyce.lan>

In article <ee045d19-797d-4346-8793-b854e528f813 at email.android.com> you write:
>The balkanizing of the Net?
>
>http://www.washingtonpost.com/blogs/worldviews/wp/2013/11/01/how-anti-nsa-backlash-could-fracture-the-internet-along-national-borders/

I expect we'll hear lots of pontification, quietly fading away when
someone explains to the pontificators just how expensive it would be
to do what they want, and ask where the money is coming from.

It would be swell if Brazil routed its Internet traffic somewhere
other than Miami, for purely technical reasons of resilience and
shorter routes.  But that would require a cable to other places
(Africa and Europe.)  They can do that any time, so long as they pay
for it.

See http://jl.ly/ICANN/zimmerman.html


From jimpop at gmail.com  Sat Nov  2 19:13:51 2013
From: jimpop at gmail.com (Jim Popovitch)
Date: Sat, 2 Nov 2013 15:13:51 -0400
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <20131102190629.99625.qmail@joyce.lan>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
 <20131102190629.99625.qmail@joyce.lan>
Message-ID: <CAGfsgR0YadG59LrmCv3eE0GtnC9e-DFX+j35vJiUA+mxbRmTQQ@mail.gmail.com>

On Sat, Nov 2, 2013 at 3:06 PM, John Levine <johnl at iecc.com> wrote:
> In article <ee045d19-797d-4346-8793-b854e528f813 at email.android.com> you write:
>>The balkanizing of the Net?
>>
>>http://www.washingtonpost.com/blogs/worldviews/wp/2013/11/01/how-anti-nsa-backlash-could-fracture-the-internet-along-national-borders/
>
> I expect we'll hear lots of pontification, quietly fading away when
> someone explains to the pontificators just how expensive it would be
> to do what they want, and ask where the money is coming from.
>
> It would be swell if Brazil routed its Internet traffic somewhere
> other than Miami, for purely technical reasons of resilience and
> shorter routes.  But that would require a cable to other places
> (Africa and Europe.)  They can do that any time, so long as they pay
> for it.

I can't be the only one to have been following this 12.8TB of neat-o-ness:

http://www.bricscable.com/


-Jim P.


From mpetach at netflight.com  Sat Nov  2 19:42:35 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 2 Nov 2013 12:42:35 -0700
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <CAGfsgR0YadG59LrmCv3eE0GtnC9e-DFX+j35vJiUA+mxbRmTQQ@mail.gmail.com>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
 <20131102190629.99625.qmail@joyce.lan>
 <CAGfsgR0YadG59LrmCv3eE0GtnC9e-DFX+j35vJiUA+mxbRmTQQ@mail.gmail.com>
Message-ID: <CAEmG1=r=bBE8Yd4OMm=8xNh9A5_j4=u-W+Whx8su3Rbn8Q+G-g@mail.gmail.com>

On Sat, Nov 2, 2013 at 12:13 PM, Jim Popovitch <jimpop at gmail.com> wrote:

> On Sat, Nov 2, 2013 at 3:06 PM, John Levine <johnl at iecc.com> wrote:
> > In article <ee045d19-797d-4346-8793-b854e528f813 at email.android.com> you
> write:
> >>The balkanizing of the Net?
> >>
> >>
> http://www.washingtonpost.com/blogs/worldviews/wp/2013/11/01/how-anti-nsa-backlash-could-fracture-the-internet-along-national-borders/
> >
> > I expect we'll hear lots of pontification, quietly fading away when
> > someone explains to the pontificators just how expensive it would be
> > to do what they want, and ask where the money is coming from.
> >
> > It would be swell if Brazil routed its Internet traffic somewhere
> > other than Miami, for purely technical reasons of resilience and
> > shorter routes.  But that would require a cable to other places
> > (Africa and Europe.)  They can do that any time, so long as they pay
> > for it.
>
> I can't be the only one to have been following this 12.8TB of neat-o-ness:
>
> http://www.bricscable.com/
>
>
> -Jim P.
>
>
I wince for the copy-editor that missed the typo
in this headline:

http://www.bricscable.com/blog/brics-scale-black-plan-to-challenge-west/

Matt

From jimpop at gmail.com  Sat Nov  2 19:44:00 2013
From: jimpop at gmail.com (Jim Popovitch)
Date: Sat, 2 Nov 2013 15:44:00 -0400
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <CAEmG1=r=bBE8Yd4OMm=8xNh9A5_j4=u-W+Whx8su3Rbn8Q+G-g@mail.gmail.com>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
 <20131102190629.99625.qmail@joyce.lan>
 <CAGfsgR0YadG59LrmCv3eE0GtnC9e-DFX+j35vJiUA+mxbRmTQQ@mail.gmail.com>
 <CAEmG1=r=bBE8Yd4OMm=8xNh9A5_j4=u-W+Whx8su3Rbn8Q+G-g@mail.gmail.com>
Message-ID: <CAGfsgR0G6-FTY3izVHLkEMHJYU6ZT2vFwFED7f8Ea9FVgC5iPA@mail.gmail.com>

On Sat, Nov 2, 2013 at 3:42 PM, Matthew Petach <mpetach at netflight.com> wrote:
>
>
>
> On Sat, Nov 2, 2013 at 12:13 PM, Jim Popovitch <jimpop at gmail.com> wrote:
>>
>> On Sat, Nov 2, 2013 at 3:06 PM, John Levine <johnl at iecc.com> wrote:
>> > In article <ee045d19-797d-4346-8793-b854e528f813 at email.android.com> you
>> > write:
>> >>The balkanizing of the Net?
>> >>
>>
>> >> >>http://www.washingtonpost.com/blogs/worldviews/wp/2013/11/01/how-anti-nsa-backlash-could-fracture-the-internet-along-national-borders/
>> >
>> > I expect we'll hear lots of pontification, quietly fading away when
>> > someone explains to the pontificators just how expensive it would be
>> > to do what they want, and ask where the money is coming from.
>> >
>> > It would be swell if Brazil routed its Internet traffic somewhere
>> > other than Miami, for purely technical reasons of resilience and
>> > shorter routes.  But that would require a cable to other places
>> > (Africa and Europe.)  They can do that any time, so long as they pay
>> > for it.
>>
>> I can't be the only one to have been following this 12.8TB of neat-o-ness:
>>
>> http://www.bricscable.com/
>>
>>
>> -Jim P.
>>
>
> I wince for the copy-editor that missed the typo
> in this headline:
>
> http://www.bricscable.com/blog/brics-scale-black-plan-to-challenge-west/
>

Yeah. I reported that to them over the Summer... hopefully their cable
laying crew is more attentive to detail. ;-)

-Jim P.


From jmamodio at gmail.com  Sat Nov  2 23:22:34 2013
From: jmamodio at gmail.com (Jorge Amodio)
Date: Sat, 2 Nov 2013 18:22:34 -0500
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
Message-ID: <58358E83-58D0-43B2-85B4-5788BB646B83@gmail.com>


Saying that advocating for an open and global Internet is a nog part of USG's cyber-espionage efforts is completely preposterous.

-Jorge

> On Nov 2, 2013, at 12:12 PM, Jay Ashworth <jra at baylink.com> wrote:
> 
> The balkanizing of the Net?
> 
> http://www.washingtonpost.com/blogs/worldviews/wp/2013/11/01/how-anti-nsa-backlash-could-fracture-the-internet-along-national-borders/
> 
> Cheers,
> - jra
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.


From jra at baylink.com  Sat Nov  2 23:30:08 2013
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 02 Nov 2013 19:30:08 -0400
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <58358E83-58D0-43B2-85B4-5788BB646B83@gmail.com>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
 <58358E83-58D0-43B2-85B4-5788BB646B83@gmail.com>
Message-ID: <7a64890f-e338-4484-b9d5-de617a133be5@email.android.com>

I'm afraid I can't glark 'nog' in that sentence from context...

Jorge Amodio <jmamodio at gmail.com> wrote:
>
>Saying that advocating for an open and global Internet is a nog part of
>USG's cyber-espionage efforts is completely preposterous.
>
>-Jorge
>
>> On Nov 2, 2013, at 12:12 PM, Jay Ashworth <jra at baylink.com> wrote:
>> 
>> The balkanizing of the Net?
>> 
>>
>http://www.washingtonpost.com/blogs/worldviews/wp/2013/11/01/how-anti-nsa-backlash-could-fracture-the-internet-along-national-borders/
>> 
>> Cheers,
>> - jra
>> -- 
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

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

From jmamodio at gmail.com  Sun Nov  3 01:03:30 2013
From: jmamodio at gmail.com (Jorge Amodio)
Date: Sat, 2 Nov 2013 20:03:30 -0500
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <7a64890f-e338-4484-b9d5-de617a133be5@email.android.com>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
 <58358E83-58D0-43B2-85B4-5788BB646B83@gmail.com>
 <7a64890f-e338-4484-b9d5-de617a133be5@email.android.com>
Message-ID: <CAMzo+1YSwLWRpA+B8-4YVgyRhpma8u9fiLB=ezgF6SnYb_R2uQ@mail.gmail.com>

LOL, I was typing on an iPad and didn't notice, s/nog/big/

Thanks for the catch.

-J



On Sat, Nov 2, 2013 at 6:30 PM, Jay Ashworth <jra at baylink.com> wrote:

> I'm afraid I can't glark 'nog' in that sentence from context...
>
>
> Jorge Amodio <jmamodio at gmail.com> wrote:
>>
>>
>> Saying that advocating for an open and global Internet is a nog part of USG's cyber-espionage efforts is completely preposterous.
>>
>> -Jorge
>>
>> On Nov 2, 2013, at 12:12 PM, Jay Ashworth <jra at baylink.com> wrote:
>>>
>>> The balkanizing of the Net?
>>>
>>> http://www.washingtonpost.com/blogs/worldviews/wp/2013/11/01/how-anti-nsa-backlash-could-fracture-the-internet-along-national-borders/
>>>
>>> Cheers,
>>> - jra
>>> --
>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>>
>>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>

From bortzmeyer at nic.fr  Sun Nov  3 02:07:04 2013
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Sat, 2 Nov 2013 19:07:04 -0700
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
Message-ID: <20131103020704.GA32665@laperouse.bortzmeyer.org>

On Sat, Nov 02, 2013 at 01:12:54PM -0400,
 Jay Ashworth <jra at baylink.com> wrote 
 a message of 8 lines which said:

> The balkanizing of the Net?
> 
> http://www.washingtonpost.com/blogs/worldviews/wp/2013/11/01/how-anti-nsa-backlash-could-fracture-the-internet-along-national-borders/

So, to host your content in the servers of NSA providers is freedom
and hosting it anywhere else is balkanizing the Internet? 



From jmamodio at gmail.com  Sun Nov  3 02:30:36 2013
From: jmamodio at gmail.com (Jorge Amodio)
Date: Sat, 2 Nov 2013 21:30:36 -0500
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <20131103020704.GA32665@laperouse.bortzmeyer.org>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
 <20131103020704.GA32665@laperouse.bortzmeyer.org>
Message-ID: <6151F268-41E7-4D6C-B073-70998C7E3E57@gmail.com>


I've never seen a byte claiming any nationality, Internet network topology is not geopolitical (at least a vast percentage of it) and routing policy != politics. When now in a "cloud" world your data may get replicated anywhere, trying to create "islands" (which btw are not immune to eavesdropping) only limits the access and level of service to end users.

The NSA issue (which is not just the NSA or the USG) is a political problem, given the mandate and the funds, any agency in the world will try to sniff data wherever it is located, and sometimes it does not require too much technology or investment, often the weakest link is a badly paid technician or corrupt enough government official, anywhere.

My .02 

-Jorge

> On Nov 2, 2013, at 9:07 PM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> 
> On Sat, Nov 02, 2013 at 01:12:54PM -0400,
> Jay Ashworth <jra at baylink.com> wrote 
> a message of 8 lines which said:
> 
>> The balkanizing of the Net?
>> 
>> http://www.washingtonpost.com/blogs/worldviews/wp/2013/11/01/how-anti-nsa-backlash-could-fracture-the-internet-along-national-borders/
> 
> So, to host your content in the servers of NSA providers is freedom
> and hosting it anywhere else is balkanizing the Internet? 
> 
> 


From bryan at serverstack.com  Sun Nov  3 02:59:19 2013
From: bryan at serverstack.com (Bryan Socha)
Date: Sat, 2 Nov 2013 22:59:19 -0400
Subject: Changing Google Geodatabase information
Message-ID: <CAAYzVeF4qXJtUXi9KRAOobjeSuYckUtkKuQfAPncc906zjfQzg@mail.gmail.com>

I've been searching for a way to submit updates to google for
incorrect geodatabase information on our ip address assignments.
does anyone have a contact or know how to do this?

Thanks,

Bryan Socha


From pmsac.nanog at gmail.com  Sun Nov  3 03:15:03 2013
From: pmsac.nanog at gmail.com (Pedro Cavaca)
Date: Sun, 3 Nov 2013 03:15:03 +0000
Subject: Changing Google Geodatabase information
In-Reply-To: <CAAYzVeF4qXJtUXi9KRAOobjeSuYckUtkKuQfAPncc906zjfQzg@mail.gmail.com>
References: <CAAYzVeF4qXJtUXi9KRAOobjeSuYckUtkKuQfAPncc906zjfQzg@mail.gmail.com>
Message-ID: <CAE42oJpJM463Hq+rtYp+rwLZZsEv7yTLQYnofWzDVD4QQMXLJQ@mail.gmail.com>

On 3 November 2013 02:59, Bryan Socha <bryan at serverstack.com> wrote:

> I've been searching for a way to submit updates to google for
> incorrect geodatabase information on our ip address assignments.
> does anyone have a contact or know how to do this?
>
>
You might want to look at:

https://support.google.com/websearch/contact/ip

http://tools.ietf.org/html/draft-google-self-published-geofeeds-02

And then email noc at google.com.

HTH.


> Thanks,
>
> Bryan Socha
>
>

From morrowc.lists at gmail.com  Sun Nov  3 04:12:38 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 3 Nov 2013 00:12:38 -0400
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <CAGfsgR0YadG59LrmCv3eE0GtnC9e-DFX+j35vJiUA+mxbRmTQQ@mail.gmail.com>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
 <20131102190629.99625.qmail@joyce.lan>
 <CAGfsgR0YadG59LrmCv3eE0GtnC9e-DFX+j35vJiUA+mxbRmTQQ@mail.gmail.com>
Message-ID: <CAL9jLaZs18duia8kHGtBFwScS9RM-agRv5MadUUXOH3XV-t2wA@mail.gmail.com>

On Sat, Nov 2, 2013 at 3:13 PM, Jim Popovitch <jimpop at gmail.com> wrote:
>
> I can't be the only one to have been following this 12.8TB of neat-o-ness:
>
> http://www.bricscable.com/

" 34 000 km, 2 fibre pair, 12.8 Tbit/s"

so.... you can get 80 waves on a single pair, 80 100g waves? that's 8tbps
where's the missing 6 in the above? Did the other pair only get 40g
waves? that seems short sighted :(


From rsk at gsp.org  Sun Nov  3 15:01:52 2013
From: rsk at gsp.org (Rich Kulawiec)
Date: Sun, 3 Nov 2013 10:01:52 -0500
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <5462970299074460243@unknownmsgid>
References: <5462970299074460243@unknownmsgid>
Message-ID: <20131103150152.GA7029@gsp.org>


On further reflection:

It occurs to me that if a lone researcher conducted such an intrusion
against the security and privacy of email (and its contents) (and
its users), possible outcomes might include a raid by heavily-armed
authorities, confiscation of anything that even looks like an electronic
device, and/or very aggressive federal prosecution.

I'm not saying that's the correct result, because I don't necessarily
think it is.  I'm just saying that recent history suggests it's possible.
And I wonder if we collectively find this present action more acceptable
because it comes with a slick press release touting its "features".

---rsk


From rwebb at ropeguru.com  Sun Nov  3 16:39:25 2013
From: rwebb at ropeguru.com (rwebb at ropeguru.com)
Date: Sun, 03 Nov 2013 12:39:25 -0400
Subject: Email Server and DNS
Message-ID: <web-90567@mail.saroza-webb.local>

So I figured a little break from the NSA was in order.

I am looking for some info on current practice for an email server and 
SMTP delivery. It has been a while since I have had to setup an email 
server and I have been tasked with setting up a small one for a 
friend. My question centers around the server sending outgoing email 
and the current practices requirements for other servers to accept 
email Things like rDNS, SPF records, etc...

I am pretty much set on the issue of incoming spam and virus. Probably 
overkill but it is checked at the Sophos UTM firewall and at the email 
server itself.

Thanks,

Robert


From rsk at gsp.org  Sun Nov  3 17:08:59 2013
From: rsk at gsp.org (Rich Kulawiec)
Date: Sun, 3 Nov 2013 12:08:59 -0500
Subject: Email Server and DNS
In-Reply-To: <web-90567@mail.saroza-webb.local>
References: <web-90567@mail.saroza-webb.local>
Message-ID: <20131103170859.GA9212@gsp.org>

On Sun, Nov 03, 2013 at 12:39:25PM -0400, rwebb at ropeguru.com wrote:
> I am looking for some info on current practice for an email server
> and SMTP delivery. It has been a while since I have had to setup an
> email server and I have been tasked with setting up a small one for
> a friend. My question centers around the server sending outgoing
> email and the current practices requirements for other servers to
> accept email Things like rDNS, SPF records, etc...

If you want to minimize your hassles: make sure you have matching
non-generic DNS/rDNS.  ("non-generic" meaning something that looks
like a host that should sending and receiving email.  In other
words, mailgw.example.net looks real.  ip-137-12-16-164.example.com
looks like a random host that's probably part of a botnet.)
Make sure that you HELO/EHLO as the same host -- unless there's
some good reason not to.  There probably isn't.

SPF is worthless crap: don't bother.  Use a real MTA, e.g., postfix
or sendmail or exim or courier.  Consider adjusting the settings to
make them as conservative as you can while still leaving you with a
functional setup.  (e.g., if your MTA supports connection rate throttling,
use it.)  Read your logs.  Use the Spamhaus DROP and EDROP lists, and
use them bidirectionally.  If your MTA supports "greetpause" or similar
mechanisms, use it.  Graylisting is still reasonably effective as well.
Don't use a quarantine, it's a horrible idea.  (Ask RSA how that worked
out for them.)  Make sure you don't backscatter.  Make sure you don't
use SMTP "callouts", which are just as abusive as spam.  Make sure you
have working "postmaster" and "abuse" addresses.  Make sure your MTA
doesn't emit or respond to return-receipts.  Read your logs (again).

---rsk


From nobody at snovc.com  Sun Nov  3 16:49:32 2013
From: nobody at snovc.com (Private Sender)
Date: Sun, 03 Nov 2013 08:49:32 -0800
Subject: Email Server and DNS
In-Reply-To: <web-90567@mail.saroza-webb.local>
References: <web-90567@mail.saroza-webb.local>
Message-ID: <52767E9C.8010805@snovc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/3/2013 8:39 AM, rwebb at ropeguru.com wrote:
> So I figured a little break from the NSA was in order.
> 
> I am looking for some info on current practice for an email server 
> and SMTP delivery. It has been a while since I have had to setup an
> email server and I have been tasked with setting up a small one for
> a friend. My question centers around the server sending outgoing
> email and the current practices requirements for other servers to
> accept email Things like rDNS, SPF records, etc...
> 
> I am pretty much set on the issue of incoming spam and virus. 
> Probably overkill but it is checked at the Sophos UTM firewall and 
> at the email server itself.
> 
> Thanks,
> 
> Robert
> 

MX, PTR, and SPF are really all you need. I would recommend you go a
step further and use DKIM, ADSP, and DMARC. It will help keep asshat
spammers from flaming your domain all over the internet.

I use http://www.unlocktheinbox.com/ to verify my configuration.

- -- 
- -Bret Taylor
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSdn6aAAoJEFL3ObmpFQy/GG8H/1WnDVLF/53rE+JjxscUOTBj
JLppOrSGGHnOB3HtljJt6g7T0ehA2ZNGjVUG7q22G8fJ76br6Ih3eRGLaYDycgkb
FPB/lhs2C9yWBlwSjZ6zE8ufATPj1gIU9QIx2Tq+9ndcXMUtVjiLHfpUd1PNVORE
jL7PSD2alSSoa29e3BXx1/reCtRPTH3FgAu7WDTwV0LL15hTx5n7gpBae7WtUcWq
Yt9nwTGp2XAbZ7pJKDAuoqOQKACwBo2WdVDJwDj7Tn8W4XzY+pTWoQzquqTrR8At
jhyGI9L1JIanHnYuGzZUX12JCmkOmu9f2QuqZygJ7ieZ8KvnYQPeFsXM/vVcsVQ=
=ADhR
-----END PGP SIGNATURE-----


From mysidia at gmail.com  Sun Nov  3 18:00:23 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 3 Nov 2013 12:00:23 -0600
Subject: Email Server and DNS
In-Reply-To: <20131103170859.GA9212@gsp.org>
References: <web-90567@mail.saroza-webb.local> <20131103170859.GA9212@gsp.org>
Message-ID: <CAAAwwbWC4iFg_Lp6rWhfBXjQryg-v4MoghFnE5k=nDOMJVf6BQ@mail.gmail.com>

On Sun, Nov 3, 2013 at 11:08 AM, Rich Kulawiec <rsk at gsp.org> wrote:

> non-generic DNS/rDNS.  ("non-generic" meaning something that looks
> like a host that should sending and receiving email.  In other
> words, mailgw.example.net looks real.  ip-137-12-16-164.example.com
> looks like a random host that's probably part of a botnet.)
>

This is a good idea, but you can use a generic hostname if you want.  It's
not a consensus that you need a non-generic hostname.

There can be negative consequences for mail delivered to some recipients,
because SpamAssassin and some other reasonably popular spamfilters, will
use a regular expression based on a sending mail server's rDNS name to
decide that "ip-137-12-16-14.example.com" is not a bonafide mail server,
based on the hostname alone;   this can increase the probability that
legitimate mail you send will be miscategorized as spam,  if  you do choose
to use a generic hostname for a mail server.


http://svn.apache.org/repos/asf/spamassassin/branches/jm_bug_3852_two_level_configs/rules/20_dynrdns.cf

There are many ad-hoc rules  that spam filters will  subject messages and
sending mail servers to, that are not part of the formal requirements for
sending MTAs.

Make sure that you HELO/EHLO as the same host -- unless there's
> some good reason not to.  There probably isn't.
>

The RFC contains a MUST NOT  in regards to verifying the  HELO name matches.
So, the HELO can use any hostname ---  as long as the hostname forward
resolves to something;  it should resolve to the IP address of one of your
mail servers.    Some mail servers provide service for many domains, and
have many DNS names that could be placed in a HELO.


The general rule here is:   Look at what is common, what is the simplest
and most likely  way for mail server operators to present themselves.

You don't want your mail server to look any different  to the outside
world, either in operation, naming, or forward and reverse DNS
configuration, HELO messages, etc,  from a majority of other legitimate
mail servers.




> SPF is worthless crap: don't bother.  Use a real MTA, e.g., postfix
>

I do not believe that is the consensus of the community -- or the working
groups behind the SPF-related RFCs.   There are many mail servers and spam
filters that will enforce SPF policies;  there are also a number that will
synthesize an "implicit"  policy  of  Soft (or hard) Fail  for any sending
IP, except the MX or base A name IP, if you do not publish  explicit SPF
records.


I have a spam filter that penalizes messages from domains with no SPF
published, or not matching a high-granularity allow condition by scoring
them as more likely to be spam;  greylisting may be caused by a soft fail,
 and of course, messages will be rejected on a hard fail.

If you are serious about running an outgoing mail server;  I do not believe
you have the luxury of completely ignoring SPF,  DKIM / domainkeys /
sender-id, and other established or emerging community standards.


After all, they can be used as a tool to help reject some spam.
e.g.  spoofed  @usps.com messages



> Don't use a quarantine, it's a horrible idea.  (Ask RSA how that worked
>

Message quarantines are great;  they are helpful  for mitigating the false
positives of overly-agressive filters.
A combination of  quarantine and reject policies can be useful,  for border
cases.

Especially, if there are some users that "want"  spammy messages,  which
are actually HTML bulk-sent newsletters of some sort or another.


out for them.)  Make sure you don't backscatter.  Make sure you don't
> use SMTP "callouts", which are just as abusive as spam.  Make sure you
>

Implemented appropriately;  an SMTP callout (or "SMTP connect"
verification) to the connecting IP is a great way to help resolve the
suspiciousness level of the sending mail server.

SMTP connect verification is a good thing to be using,  when the sending
server is using an  envelope From domain, that has not yet bothered to
publish the proper SPF records  to verify them.

There are bad broken SMTP callout implementations that should be avoided,
and there are rather useful ones.


> have working "postmaster" and "abuse" addresses.  Make sure your MTA
> doesn't emit or respond to return-receipts.  Read your logs (again).
>

Of course, read receipt requests should be suppressed when dealing with
internet hosts.
Having a working postmaster address is a requirement.

Using the name abuse@  for the abuse contact  is not required,  and it is
likely to be targetted by spammers.

Working abuse and technical contacts should be published  in the IP address
and domain name WHOIS databases for  the mail server's  primary domain,
 and all envelope from domains  that  can be originated on that mail server.


---rsk
>
--
-JH

From tshaw at oitc.com  Sun Nov  3 18:10:33 2013
From: tshaw at oitc.com (TR Shaw)
Date: Sun, 3 Nov 2013 13:10:33 -0500
Subject: Email Server and DNS
In-Reply-To: <52767E9C.8010805@snovc.com>
References: <web-90567@mail.saroza-webb.local> <52767E9C.8010805@snovc.com>
Message-ID: <FF4D15E7-8248-48F4-A7A4-1CB2CE084ADA@oitc.com>

In addition to all the other reco's below, 

1) only allow sending by your users from the submit port and only with authentication. There should be no client sending through the SMTP port.

2) Implement SSL on POP & IMAP if at all possible Otherwise enforce CRAM-MD5

3) Review logs esp pop and imap login failures. 

4) Turn off VRFY. 

On Nov 3, 2013, at 11:49 AM, Private Sender wrote:

> Signed PGP part
> On 11/3/2013 8:39 AM, rwebb at ropeguru.com wrote:
> > So I figured a little break from the NSA was in order.
> > 
> > I am looking for some info on current practice for an email server 
> > and SMTP delivery. It has been a while since I have had to setup an
> > email server and I have been tasked with setting up a small one for
> > a friend. My question centers around the server sending outgoing
> > email and the current practices requirements for other servers to
> > accept email Things like rDNS, SPF records, etc...
> > 
> > I am pretty much set on the issue of incoming spam and virus. 
> > Probably overkill but it is checked at the Sophos UTM firewall and 
> > at the email server itself.
> > 
> > Thanks,
> > 
> > Robert
> > 
> 
> MX, PTR, and SPF are really all you need. I would recommend you go a
> step further and use DKIM, ADSP, and DMARC. It will help keep asshat
> spammers from flaming your domain all over the internet.
> 
> I use http://www.unlocktheinbox.com/ to verify my configuration.
> 
> - -- 
> - -Bret Taylor
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131103/d583bf84/attachment.bin>

From clinton at scripty.com  Sun Nov  3 18:30:05 2013
From: clinton at scripty.com (Clinton Work)
Date: Sun, 03 Nov 2013 11:30:05 -0700
Subject: Cogent IPV6 connectivity to fireball.acr.fi
Message-ID: <1383503405.21152.42367653.2CB87041@webmail.messagingengine.com>

IPV6 connectivity to fireball.acr.fi is failing inside Cogent AS174.  I
have already contacted the Cogent NOC, but I haven't heard anything back
yet. I'm wondering if somebody else with Cogent IPV6 connectivity can
run some tests.   IPV4 connectivity is working fine.  

-- 
Clinton Work


From gparent at gparent.org  Sun Nov  3 18:43:04 2013
From: gparent at gparent.org (Guillaume Parent)
Date: Sun, 3 Nov 2013 18:43:04 +0000
Subject: Email Server and Dm.
Message-ID: <CACT83akTLbhY0aticKVV1AbBA58nMbAVFTvQ6OkOcvQxLka1xQ@mail.gmail.com>

     KNow
On Nov 3, 2013 1:10 PM, "TR Shaw" <tshaw at oitc.com> wrote:

> In addition to all the other reco's below,
>
> 1) only allow sending by your users from the submit port and only with
> authentication. There should be no client sending through the SMTP port.
>
> 2) Implement SSL on POP & IMAP if at all possible Otherwise enforce
> CRAM-MD5
>
> 3) Review logs esp pop and imap login failures.
>
> 4) Turn off VRFY.
>
> On Nov 3, 2013, at 11:49 AM, Private Sender wrote:
>
> > Signed PGP part
> > On 11/3/2013 8:39 AM, rwebb at ropeguru.com wrote:
> > > So I figured a little break from the NSA was in order.
> > >
> > > I am looking for some info on current practice for an email server
> > > and SMTP delivery. It has been a while since I have had to setup an
> > > email server and I have been tasked with setting up a small one for
> > > a friend. My question centers around the server sending outgoing
> > > email and the current practices requirements for other servers to
> > > accept email Things like rDNS, SPF records, etc...
> > >
> > > I am pretty much set on the issue of incoming spam and virus.
> > > Probably overkill but it is checked at the Sophos UTM firewall and
> > > at the email server itself.
> > >
> > > Thanks,
> > >
> > > Robert
> > >
> >
> > MX, PTR, and SPF are really all you need. I would recommend you go a
> > step further and use DKIM, ADSP, and DMARC. It will help keep asshat
> > spammers from flaming your domain all over the internet.
> >
> > I use http://www.unlocktheinbox.com/ to verify my configuration.
> >
> > - --
> > - -Bret Taylor
> >
> >
>
>

From jimpop at gmail.com  Sun Nov  3 19:09:53 2013
From: jimpop at gmail.com (Jim Popovitch)
Date: Sun, 3 Nov 2013 14:09:53 -0500
Subject: Email Server and DNS
In-Reply-To: <52767E9C.8010805@snovc.com>
References: <web-90567@mail.saroza-webb.local>
	<52767E9C.8010805@snovc.com>
Message-ID: <CAGfsgR3wrF4w=gdPjL=NEj3Gkb=8K=CaHTnSHF1pHiLo2Wqx-Q@mail.gmail.com>

On Sun, Nov 3, 2013 at 11:49 AM, Private Sender <nobody at snovc.com> wrote:
> I would recommend you go a step further and use DKIM, ADSP, and DMARC.

Don't do DMARC if you expect to have end-users forward emails, or
subscribe to mailinglists. Despite the removal from the current DMARC
spec, the original guidelines called for DMARC to be used for
auto-generated transactional email, and expressly not for end-user
generated content.

-Jim P.


From jako.andras at eik.bme.hu  Sun Nov  3 19:16:39 2013
From: jako.andras at eik.bme.hu (=?utf-8?B?SsOBS8OTIEFuZHLDoXM=?=)
Date: Sun, 3 Nov 2013 20:16:39 +0100
Subject: Cogent IPV6 connectivity to fireball.acr.fi
In-Reply-To: <1383503405.21152.42367653.2CB87041@webmail.messagingengine.com>
References: <1383503405.21152.42367653.2CB87041@webmail.messagingengine.com>
Message-ID: <20131103191639.GE486@eik.bme.hu>

> IPV6 connectivity to fireball.acr.fi is failing inside Cogent AS174.  I
> have already contacted the Cogent NOC, but I haven't heard anything back
> yet. I'm wondering if somebody else with Cogent IPV6 connectivity can
> run some tests.   IPV4 connectivity is working fine.  

It works from AS2547 through Cogent:

PING6(56=40+8+8 bytes) 2001:738:2001:2001::c --> 2001:1bc8:100d::2
16 bytes from 2001:1bc8:100d::2, icmp_seq=0 hlim=52 time=57.356 ms
16 bytes from 2001:1bc8:100d::2, icmp_seq=1 hlim=52 time=57.499 ms
16 bytes from 2001:1bc8:100d::2, icmp_seq=2 hlim=52 time=57.889 ms
^C
--- fireball.acr.fi ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 57.356/57.581/57.889/0.225 ms


traceroute6 to fireball.acr.fi (2001:1bc8:100d::2) from
2001:738:2001:2001::c, 64 hops max, 12 byte packets
 1  vl100.taz.net.bme.hu  0.730 ms  0.389 ms  0.369 ms
 2  tg0-1-0-1.rtr.bme.hbone.hu  1.116 ms  0.839 ms  0.590 ms
 3  * * *
 4  2001:978:2:27::7:1  1.227 ms  0.979 ms  0.942 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * 2001:978:2:3f::6  46.962 ms
12  2001:1bc8:1:7:0:d:0:1  47.060 ms *  47.309 ms
13  2001:1bc8:100:100:5::2  55.083 ms !N  54.830 ms !N  62.167 ms !N


$ telnet -6 fireball.acr.fi 80
Trying 2001:1bc8:100d::2...
Won't send login name and/or authentication information.
Connected to fireball.acr.fi.
Escape character is '^]'.
GET
<!DOCTYPE HTML public "-//W30//DTD W3 HTML 3.0//EN">
<HTML>
<HEAD>
<TITLE>The Home Page of Tero Kivinen</TITLE>
<LINK REL=Up HREF="http://www.iki.fi/">
<LINK REL=Home HREF="index.html">
<LINK REV="made" HREF="mailto:kivinen at iki.fi">
</HEAD>


Andr?s


From andrew.fried at gmail.com  Sun Nov  3 20:38:07 2013
From: andrew.fried at gmail.com (Andrew Fried)
Date: Sun, 03 Nov 2013 15:38:07 -0500
Subject: Cogent IPV6 connectivity to fireball.acr.fi
In-Reply-To: <1383503405.21152.42367653.2CB87041@webmail.messagingengine.com>
References: <1383503405.21152.42367653.2CB87041@webmail.messagingengine.com>
Message-ID: <5276B42F.8050903@gmail.com>

>From AS54054 in Ashburn, VA I can ping your address but traceroute's
aren't making it through.

Andrew

Andrew Fried
andrew.fried at gmail.com

On 11/3/13, 1:30 PM, Clinton Work wrote:
> IPV6 connectivity to fireball.acr.fi is failing inside Cogent AS174.  I
> have already contacted the Cogent NOC, but I haven't heard anything back
> yet. I'm wondering if somebody else with Cogent IPV6 connectivity can
> run some tests.   IPV4 connectivity is working fine.  
> 


From robertg at garlic.com  Sun Nov  3 21:35:25 2013
From: robertg at garlic.com (Robert Glover)
Date: Sun, 03 Nov 2013 13:35:25 -0800
Subject: Cogent IPV6 connectivity to fireball.acr.fi
In-Reply-To: <1383503405.21152.42367653.2CB87041@webmail.messagingengine.com>
References: <1383503405.21152.42367653.2CB87041@webmail.messagingengine.com>
Message-ID: <5276C19D.505@garlic.com>

All good from AS4307 via Cogent:

Sending 20, 100-byte ICMP Echos to 2001:1BC8:100D::2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 200/203/204 ms

Traceroutes fail altogether.


On 11/3/2013 10:30 AM, Clinton Work wrote:
> IPV6 connectivity to fireball.acr.fi is failing inside Cogent AS174.  I
> have already contacted the Cogent NOC, but I haven't heard anything back
> yet. I'm wondering if somebody else with Cogent IPV6 connectivity can
> run some tests.   IPV4 connectivity is working fine.  
>



From Valdis.Kletnieks at vt.edu  Sun Nov  3 23:11:46 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 03 Nov 2013 18:11:46 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: Your message of "Sat, 02 Nov 2013 11:30:57 +0900."
 <527463E1.1080201@necom830.hpcl.titech.ac.jp>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
 <527463E1.1080201@necom830.hpcl.titech.ac.jp>
Message-ID: <254808.1383520306@turing-police.cc.vt.edu>

On Sat, 02 Nov 2013 11:30:57 +0900, Masataka Ohta said:
> George Herbert wrote:
>
> > Anyone familiar with secure organizations will realize this as the
> > internal witch hunt problem.
>
> No hunting necessary to fire those agents who are hired at the
> request of NSA/CIA.

Do you *really* think that HR has an entry on the employee's file that
says "NSA suggested hire"? How do you intend to *find* the agents
who were hired at a government agency's under-the-table request that
never had a written record that the company had access to?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131103/3dddbf41/attachment.bin>

From jimpop at gmail.com  Sun Nov  3 23:35:08 2013
From: jimpop at gmail.com (Jim Popovitch)
Date: Sun, 3 Nov 2013 18:35:08 -0500
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <CAL9jLaZs18duia8kHGtBFwScS9RM-agRv5MadUUXOH3XV-t2wA@mail.gmail.com>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
 <20131102190629.99625.qmail@joyce.lan>
 <CAGfsgR0YadG59LrmCv3eE0GtnC9e-DFX+j35vJiUA+mxbRmTQQ@mail.gmail.com>
 <CAL9jLaZs18duia8kHGtBFwScS9RM-agRv5MadUUXOH3XV-t2wA@mail.gmail.com>
Message-ID: <CAGfsgR0AhkJdsHUOR_yBR9UnAmsKoirDuJPgqUgnNPuA+eEFjQ@mail.gmail.com>

On Sun, Nov 3, 2013 at 12:12 AM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Sat, Nov 2, 2013 at 3:13 PM, Jim Popovitch <jimpop at gmail.com> wrote:
>>
>> I can't be the only one to have been following this 12.8TB of neat-o-ness:
>>
>> http://www.bricscable.com/
>
> " 34 000 km, 2 fibre pair, 12.8 Tbit/s"
>
> so.... you can get 80 waves on a single pair, 80 100g waves? that's 8tbps
> where's the missing 6 in the above? Did the other pair only get 40g
> waves? that seems short sighted :(

The remaining bandwidth is obviously for network management polling.  lol :-)

-Jim P.


From clinton at scripty.com  Sun Nov  3 21:22:37 2013
From: clinton at scripty.com (Clinton Work)
Date: Sun, 03 Nov 2013 14:22:37 -0700
Subject: Cogent IPV6 connectivity to fireball.acr.fi
In-Reply-To: <5276B42F.8050903@gmail.com>
References: <1383503405.21152.42367653.2CB87041@webmail.messagingengine.com>
 <5276B42F.8050903@gmail.com>
Message-ID: <1383513757.6384.42414557.011C21EF@webmail.messagingengine.com>

I can reach fireball.acr.fi on TCP port 80 so it looks like Cogent is
just filtering or dropping IPV6 traceroute packets.  

Thanks for checking connectivity from other locations.  

-- 
Clinton Work
Calgary, AB

On Sun, Nov 3, 2013, at 01:38 PM, Andrew Fried wrote:
> From AS54054 in Ashburn, VA I can ping your address but traceroute's
> aren't making it through.
> 
> Andrew
> 
> Andrew Fried
> andrew.fried at gmail.com


From mohta at necom830.hpcl.titech.ac.jp  Mon Nov  4 00:14:40 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 04 Nov 2013 09:14:40 +0900
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <254808.1383520306@turing-police.cc.vt.edu>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
 <527463E1.1080201@necom830.hpcl.titech.ac.jp>
 <254808.1383520306@turing-police.cc.vt.edu>
Message-ID: <5276E6F0.60204@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

> How do you intend to *find* the agents
> who were hired at a government agency's under-the-table request that
> never had a written record that the company had access to?

By memories of those who are at the table.

						Masataka Ohta




From Valdis.Kletnieks at vt.edu  Mon Nov  4 01:04:55 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 03 Nov 2013 20:04:55 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: Your message of "Mon, 04 Nov 2013 09:14:40 +0900."
 <5276E6F0.60204@necom830.hpcl.titech.ac.jp>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
 <527463E1.1080201@necom830.hpcl.titech.ac.jp>
 <254808.1383520306@turing-police.cc.vt.edu>
 <5276E6F0.60204@necom830.hpcl.titech.ac.jp>
Message-ID: <260897.1383527095@turing-police.cc.vt.edu>

On Mon, 04 Nov 2013 09:14:40 +0900, Masataka Ohta said:
> Valdis.Kletnieks at vt.edu wrote:
>
> > How do you intend to *find* the agents
> > who were hired at a government agency's under-the-table request that
> > never had a written record that the company had access to?
>
> By memories of those who are at the table.

So one of the two people at the table you don't have a name for because
they're not an employee, and the other is either an NSA plant lying about
never being at a table, or you just gave your top network troubleshooter
a damned good reason to update their resume.

Hint:  This isn't a children's game of hide and seek, and if there *is*
an NSA plant they're not going to just smile and say "Oh, you found me".

Good job at flushing out those NSA guys.  Now who are you going to
hire to replace them, and your top troubleshooter?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131103/6df863bf/attachment.bin>

From adrian at creative.net.au  Mon Nov  4 00:52:13 2013
From: adrian at creative.net.au (Adrian Chadd)
Date: Sun, 3 Nov 2013 16:52:13 -0800
Subject: abha ahuja
In-Reply-To: <m2sivwvqg2.wl%randy@psg.com>
References: <m2sivwvqg2.wl%randy@psg.com>
Message-ID: <CAJ-Vmom5J5qQp6mUPo8mL3t=JH2-PGXxZGPYkQ4UquTEXV0f0g@mail.gmail.com>

[resurrecting this thread, as it's been a while since I read nanog-ml,
and this is surprisingly important to me...]

On 19 October 2013 15:36, Randy Bush <randy at psg.com> wrote:
> abha ahuja, researcher and operator, died this day in 2001 at a
> tragically early age.  if you did not know her, search a bit.
> she did a lot, and with an open mind and heart.

I met Abha whilst working in Amsterdam (on Squid, doing (consentual!)
transparent reverse proxying for customer websites at a transit
provider. Yes, I know, evil.) I was a bit star struck - I had been
using GateD for three or four years at various ISPs before Europe, and
then one day she casually strolls into the office.

I remember one of our excursions into the city centre (likely to a
RIPE meeting day) and she wondered why the heck anyone would want to
teach a web proxy about AS numbers. She was always energetic and
passionate about whatever we talked about. It was inspiring.

I had just turned 21 shortly before this happened. I had just moved
back to Australia and we had been keeping in touch. Then, this. It was
very sobering.

Sigh.



-adrian
(hi all!)


From johnl at iecc.com  Mon Nov  4 04:11:09 2013
From: johnl at iecc.com (John Levine)
Date: 4 Nov 2013 04:11:09 -0000
Subject: Email Server and DNS
In-Reply-To: <52767E9C.8010805@snovc.com>
Message-ID: <20131104041109.2905.qmail@joyce.lan>

>MX, PTR, and SPF are really all you need.

So far so good, noting that a host name that doesn't look generic is
better than one that does.

> I would recommend you go a
>step further and use DKIM, ADSP, and DMARC.

Using DKIM is a good idea.  Do *not* use ADSP.  It is a failed
experiment which will provide no benefit and considerable pain.
(Check the author list on RFC 5617 before arguing, please.)

If you believe that your domain is heavily forged (which if you are
not Paypal, Facebook, or a large bank or ISP, it almost certainly is
not), you can set up a DMARC record to collect some statistics about
what mail other people are getting that appears to be from you.  Do
not try to use DMARC to tell people to quarantine or reject your mail
until you are really sure you understand the statistics you're
getting.

R's,
John



From jabley at hopcount.ca  Mon Nov  4 04:47:21 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Sun, 3 Nov 2013 20:47:21 -0800
Subject: Cogent IPV6 connectivity to fireball.acr.fi
In-Reply-To: <1383513757.6384.42414557.011C21EF@webmail.messagingengine.com>
References: <1383503405.21152.42367653.2CB87041@webmail.messagingengine.com>
 <5276B42F.8050903@gmail.com>
 <1383513757.6384.42414557.011C21EF@webmail.messagingengine.com>
Message-ID: <-8241591075349665864@unknownmsgid>

> On Nov 3, 2013, at 15:38, Clinton Work <clinton at scripty.com> wrote:
>
> I can reach fireball.acr.fi on TCP port 80 so it looks like Cogent is
> just filtering or dropping IPV6 traceroute packets.

"Traceroute packets" is extremely vague. As a general rule, if you
want to discover a complete path between endpoints that are expected
to communicate using 80/tcp, trace the route using 80/tcp.

(Not that it's ever expected to see protocol-specific drops in a core
or across a transit or peering edge.)


Joe


From bmanning at vacation.karoshi.com  Mon Nov  4 05:38:11 2013
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 4 Nov 2013 05:38:11 +0000
Subject: Email Server and DNS
In-Reply-To: <52767E9C.8010805@snovc.com>
References: <web-90567@mail.saroza-webb.local> <52767E9C.8010805@snovc.com>
Message-ID: <20131104053811.GA11666@vacation.karoshi.com.>

On Sun, Nov 03, 2013 at 08:49:32AM -0800, Private Sender wrote:
> On 11/3/2013 8:39 AM, rwebb at ropeguru.com wrote:
> > 
> > I am looking for some info on current practice for an email server 
> > and SMTP delivery. It has been a while since I have had to setup an
> > email server and I have been tasked with setting up a small one for
> > a friend. My question centers around the server sending outgoing
> > email and the current practices requirements for other servers to
> > accept email Things like rDNS, SPF records, etc...
> > 
> > I am pretty much set on the issue of incoming spam and virus. 
> > Probably overkill but it is checked at the Sophos UTM firewall and 
> > at the email server itself.
> > 
> > Thanks,
> > 
> > Robert
> > 
> 
> MX, PTR, and SPF are really all you need. I would recommend you go a
> step further and use DKIM, ADSP, and DMARC. It will help keep asshat
> spammers from flaming your domain all over the internet.
> 
> I use http://www.unlocktheinbox.com/ to verify my configuration.
> 
> - -- 
> - -Bret Taylor


	small - so you likely want to avoid the problems of SMTP with thyroid problems.
	simple is good. practically, you don't need DKIM, ADSP, DMARC or really any 
	quasi reputation systems in play.  For that matter you don't need SPF either...
	PTR's are good to have and an MX can be more useful than not - BUT - none of 
	them are required for a host to received and process SMTP.  

/bill


From cite+nanog at incertum.net  Mon Nov  4 07:40:27 2013
From: cite+nanog at incertum.net (Stefan Foerster)
Date: Mon, 4 Nov 2013 08:40:27 +0100
Subject: Email Server and DNS
In-Reply-To: <52767E9C.8010805@snovc.com>
References: <web-90567@mail.saroza-webb.local>
 <52767E9C.8010805@snovc.com>
Message-ID: <20131104074027.GB3429@mail.incertum.net>

* Private Sender <nobody at snovc.com>:
> On 11/3/2013 8:39 AM, rwebb at ropeguru.com wrote:
> > I am looking for some info on current practice for an email server 
> > and SMTP delivery. It has been a while since I have had to setup an
> > email server and I have been tasked with setting up a small one for
> > a friend. My question centers around the server sending outgoing
> > email and the current practices requirements for other servers to
> > accept email Things like rDNS, SPF records, etc...
[...]
> MX, PTR, and SPF are really all you need. I would recommend you go a
> step further and use DKIM, ADSP, and DMARC. It will help keep asshat
> spammers from flaming your domain all over the internet.

And while you are at it - why not implement DNSSEC for the domain in
question and publish some DANE TLSA records?


Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131104/ff64abce/attachment.bin>

From mohta at necom830.hpcl.titech.ac.jp  Mon Nov  4 10:48:03 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 04 Nov 2013 19:48:03 +0900
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <20131102190629.99625.qmail@joyce.lan>
References: <20131102190629.99625.qmail@joyce.lan>
Message-ID: <52777B63.6070009@necom830.hpcl.titech.ac.jp>

John Levine wrote:

> I expect we'll hear lots of pontification, quietly fading away when
> someone explains to the pontificators just how expensive it would be
> to do what they want, and ask where the money is coming from.

For countries other than US, mandating domestic servers prevents
money going away to US through US based companies.

It is expensive only for those having foreign servers, which
nullifies advantages of global service companies over domestic
ones.

						Masataka Ohta


From jmamodio at gmail.com  Mon Nov  4 11:37:41 2013
From: jmamodio at gmail.com (Jorge Amodio)
Date: Mon, 4 Nov 2013 05:37:41 -0600
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <52777B63.6070009@necom830.hpcl.titech.ac.jp>
References: <20131102190629.99625.qmail@joyce.lan>
 <52777B63.6070009@necom830.hpcl.titech.ac.jp>
Message-ID: <CAMzo+1ZhVqsMxH+YAYdF5GYgihp5Q+gT-iYDUPyvC1WrOMMCBA@mail.gmail.com>

This is not 100% true, the economics of hosting and providing layer 7
services are not longer strictly defined by geographic boundaries, also
some local companies (global or not) provide services locally regardless of
the location (or multiple locations) of the servers.

There is no field on the IP packet header to indicate to which political
mandate the packet belongs.

-Jorge



On Mon, Nov 4, 2013 at 4:48 AM, Masataka Ohta <
mohta at necom830.hpcl.titech.ac.jp> wrote:

> John Levine wrote:
>
> > I expect we'll hear lots of pontification, quietly fading away when
> > someone explains to the pontificators just how expensive it would be
> > to do what they want, and ask where the money is coming from.
>
> For countries other than US, mandating domestic servers prevents
> money going away to US through US based companies.
>
> It is expensive only for those having foreign servers, which
> nullifies advantages of global service companies over domestic
> ones.
>
>                                                 Masataka Ohta
>
>

From bjorn at mork.no  Mon Nov  4 12:45:58 2013
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 04 Nov 2013 13:45:58 +0100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131031235110.D505696611F@rock.dv.isc.org> (Mark Andrews's
 message of "Fri, 01 Nov 2013 10:51:10 +1100")
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net>
 <20131031235110.D505696611F@rock.dv.isc.org>
Message-ID: <87iow8tjw9.fsf@nemi.mork.no>

Mark Andrews <marka at isc.org> writes:

> That said it is possible to completely automate the secure assignment
> of PTR records.  It is also possible to completely automate the
> secure delegation of the reverse name space.  See
> http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00

I like that.  I'd really like to see CPE vendors implementing it.

AFAICT, it is perfectly possible to apply that on top of the idea you
had about letting TCP clients update their own key. CPEs supporting the
DHCPv6 option will use that, while the others still have the ability to
add a KEY record from a TCP client in the deletated prefix.  As long as
you let TSIG signed updates trump anything and do not allow unsigned
updates if there is a KEY, then these should work just fine together.

But I believe the draft could use a couple of clarifications to avoid
interpretation bugs:

   CPE generates DHCPv6 Prefix Delegation [RFC3633] request which
   includes a KEY-RDATA option (code point TBA) which contains a the
   rdata of a DNS KEY record containing a RSASHA256 key using the public
   components of the previously generated RSA key pair.

Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a
"top level" option?  I.e. will it be possible to set different keys for
(the theoretical) multi-prefix requests?

We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so
it is important to explicitly state where such options, which may be
considered local to part of the DHCPv6 message, belong.  I do know that
RFC3315 is clear on the default:

   Unless otherwise noted, each option may appear only in the options
   area of a DHCP message and may appear only once.  

But experience with OPTION_DNS_SERVERS has shown that this is not
enough.  Pleace be explicit about where in the packet any new DHCPv6
options belong.


   CPE device generates DNS UPDATE [RFC2136] which delegates the reverse
   name space to itself and others if they have been configured.  The
   CPE uses SIG(0) [RFC2931] to sign the request with owner name
   matching the reverse of the delegated prefix.

This could use a few examples and clarifications wrt the owner name.  I
interpret it as:

 IA_PD = 2001:db8:1::/48 => owner name = 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

But what about for example IA_PD = 2001:db8:2:4::/62 ?  Are you going to
add multiple owner names, or should there be some rule here allowing
multiple delegations with a single owner name for PD on non-nibble
boundaries?  For example

 IA_PD = 2001:db8:2:4::/62 
           => owner name = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
              allowed to update:
                         4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
                         5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
                         6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
                         7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa


(not that I would ever consider delegating prefixes on anything but
nibble boundaries, but someone else might - and the draft should
consider this possibility)



Bj?rn


From mohta at necom830.hpcl.titech.ac.jp  Mon Nov  4 13:17:20 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 04 Nov 2013 22:17:20 +0900
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <CAMzo+1ZhVqsMxH+YAYdF5GYgihp5Q+gT-iYDUPyvC1WrOMMCBA@mail.gmail.com>
References: <20131102190629.99625.qmail@joyce.lan>	<52777B63.6070009@necom830.hpcl.titech.ac.jp>
 <CAMzo+1ZhVqsMxH+YAYdF5GYgihp5Q+gT-iYDUPyvC1WrOMMCBA@mail.gmail.com>
Message-ID: <52779E60.9070805@necom830.hpcl.titech.ac.jp>

Jorge Amodio wrote:

> There is no field on the IP packet header to indicate to which
> political mandate the packet belongs.

If a service provider violates some local regulation, the
provider will be punished, which is the political
mandate.

That is, the service provider should better observe related
local regulations as long as they want to have business
at the locale.

						Masataka Ohta


From jmamodio at gmail.com  Mon Nov  4 13:36:36 2013
From: jmamodio at gmail.com (Jorge Amodio)
Date: Mon, 4 Nov 2013 07:36:36 -0600
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <52779E60.9070805@necom830.hpcl.titech.ac.jp>
References: <20131102190629.99625.qmail@joyce.lan>
 <52777B63.6070009@necom830.hpcl.titech.ac.jp>
 <CAMzo+1ZhVqsMxH+YAYdF5GYgihp5Q+gT-iYDUPyvC1WrOMMCBA@mail.gmail.com>
 <52779E60.9070805@necom830.hpcl.titech.ac.jp>
Message-ID: <A73F23C3-243D-4A65-AF3D-5BC5F652024D@gmail.com>

That is correct (not everywhere) but it has no direct relationship with the economics plus violating local or international laws is way above layer 7

Also there is no uniform and universal standard that defines what is or is not a violation.

-Jorge

> On Nov 4, 2013, at 7:17 AM, Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp> wrote:
> 
> Jorge Amodio wrote:
> 
>> There is no field on the IP packet header to indicate to which
>> political mandate the packet belongs.
> 
> If a service provider violates some local regulation, the
> provider will be punished, which is the political
> mandate.
> 
> That is, the service provider should better observe related
> local regulations as long as they want to have business
> at the locale.
> 
>                       Masataka Ohta


From eric-list at truenet.com  Mon Nov  4 14:30:15 2013
From: eric-list at truenet.com (Eric Tykwinski)
Date: Mon, 4 Nov 2013 09:30:15 -0500
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <A73F23C3-243D-4A65-AF3D-5BC5F652024D@gmail.com>
References: <20131102190629.99625.qmail@joyce.lan>
 <52777B63.6070009@necom830.hpcl.titech.ac.jp>
 <CAMzo+1ZhVqsMxH+YAYdF5GYgihp5Q+gT-iYDUPyvC1WrOMMCBA@mail.gmail.com>
 <52779E60.9070805@necom830.hpcl.titech.ac.jp>
 <A73F23C3-243D-4A65-AF3D-5BC5F652024D@gmail.com>
Message-ID: <028401ced96a$609ce9a0$21d6bce0$@truenet.com>

Just wanted to add something to the discussion:
http://www.renesys.com/2013/10/google-dns-departs-brazil-ahead-new-law/

Basically, they are claiming possible new laws in Brazil have left Google to
shut down DNS services locally.

-----Original Message-----
From: Jorge Amodio [mailto:jmamodio at gmail.com] 
Sent: Monday, November 04, 2013 8:37 AM
To: Masataka Ohta
Cc: NANOG
Subject: Re: How anti-NSA backlash could fracture the Internet along
national borders - The Washington Post

That is correct (not everywhere) but it has no direct relationship with the
economics plus violating local or international laws is way above layer 7

Also there is no uniform and universal standard that defines what is or is
not a violation.

-Jorge

> On Nov 4, 2013, at 7:17 AM, Masataka Ohta
<mohta at necom830.hpcl.titech.ac.jp> wrote:
> 
> Jorge Amodio wrote:
> 
>> There is no field on the IP packet header to indicate to which 
>> political mandate the packet belongs.
> 
> If a service provider violates some local regulation, the provider 
> will be punished, which is the political mandate.
> 
> That is, the service provider should better observe related local 
> regulations as long as they want to have business at the locale.
> 
>                       Masataka Ohta





From dhc2 at dcrocker.net  Mon Nov  4 15:21:30 2013
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Mon, 04 Nov 2013 07:21:30 -0800
Subject: Email Server and DNS
In-Reply-To: <20131104041109.2905.qmail@joyce.lan>
References: <20131104041109.2905.qmail@joyce.lan>
Message-ID: <5277BB7A.40709@dcrocker.net>

On 11/3/2013 8:11 PM, John Levine wrote:
>> I would recommend you go a
>> step further and use DKIM, ADSP, and DMARC.
>
> Using DKIM is a good idea.  Do *not* use ADSP.  It is a failed
> experiment which will provide no benefit and considerable pain.

+1


> If you believe that your domain is heavily forged (which if you are
> not Paypal, Facebook, or a large bank or ISP, it almost certainly is
> not), you can set up a DMARC record to collect some statistics about
> what mail other people are getting that appears to be from you.  Do
> not try to use DMARC to tell people to quarantine or reject your mail
> until you are really sure you understand the statistics you're
> getting.

+1

The 'reporting' function in DMARC appears to have wide applicability and 
substantial benefit.  The handling (rejection, etc.) function has very 
narrow benefit.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From jimpop at gmail.com  Mon Nov  4 15:26:47 2013
From: jimpop at gmail.com (Jim Popovitch)
Date: Mon, 4 Nov 2013 10:26:47 -0500
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <028401ced96a$609ce9a0$21d6bce0$@truenet.com>
References: <20131102190629.99625.qmail@joyce.lan>
 <52777B63.6070009@necom830.hpcl.titech.ac.jp>
 <CAMzo+1ZhVqsMxH+YAYdF5GYgihp5Q+gT-iYDUPyvC1WrOMMCBA@mail.gmail.com>
 <52779E60.9070805@necom830.hpcl.titech.ac.jp>
 <A73F23C3-243D-4A65-AF3D-5BC5F652024D@gmail.com>
 <028401ced96a$609ce9a0$21d6bce0$@truenet.com>
Message-ID: <CAGfsgR28bxbotD9dibH0JgS9d+_g8BmH-qKmYpi12DWye6LK-w@mail.gmail.com>

On Mon, Nov 4, 2013 at 9:30 AM, Eric Tykwinski <eric-list at truenet.com> wrote:
> Just wanted to add something to the discussion:
> http://www.renesys.com/2013/10/google-dns-departs-brazil-ahead-new-law/
>
> Basically, they are claiming possible new laws in Brazil have left Google to
> shut down DNS services locally.

Dramatic Theater?   Google is doing the same thing in Australia
(servers in Sydney, results returned from Taipei).   Their actions,
and the timing thereof, in Brazil are fodder for those that believe
Google and the USG are locked together at the hip.

-Jim P.


From clinton at scripty.com  Mon Nov  4 15:41:28 2013
From: clinton at scripty.com (Clinton Work)
Date: Mon, 04 Nov 2013 08:41:28 -0700
Subject: Cogent IPV6 connectivity to fireball.acr.fi
In-Reply-To: <-8241591075349665864@unknownmsgid>
References: <1383503405.21152.42367653.2CB87041@webmail.messagingengine.com>
 <5276B42F.8050903@gmail.com>
 <1383513757.6384.42414557.011C21EF@webmail.messagingengine.com>
 <-8241591075349665864@unknownmsgid>
Message-ID: <1383579688.16177.42745409.48B42EF6@webmail.messagingengine.com>

I should have stated that I tried icmpv6, UDP, and TCP traceroute with
the same results.  Looks like Cogent is not returning TTL expired IPV6
packets within their core.  I can only guess that this is a result of
using 6PE and propagating the IPV6 TTL into MPLS.  

Clinton 

On Sun, Nov 3, 2013, at 09:47 PM, Joe Abley wrote:
> "Traceroute packets" is extremely vague. As a general rule, if you
> want to discover a complete path between endpoints that are expected
> to communicate using 80/tcp, trace the route using 80/tcp.
> 
> (Not that it's ever expected to see protocol-specific drops in a core
> or across a transit or peering edge.)



From fmartin at linkedin.com  Mon Nov  4 16:41:21 2013
From: fmartin at linkedin.com (Franck Martin)
Date: Mon, 4 Nov 2013 16:41:21 +0000
Subject: Email Server and DNS
In-Reply-To: <5277BB7A.40709@dcrocker.net>
References: <20131104041109.2905.qmail@joyce.lan> <5277BB7A.40709@dcrocker.net>
Message-ID: <77426B543150464AA3F30DF1A91365DE6ABE1F69@ESV4-MBX02.linkedin.biz>

www.maawg.org has published a sender BCP, please read it

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131104/276fbd0d/attachment.bin>

From drc at virtualized.org  Mon Nov  4 17:13:00 2013
From: drc at virtualized.org (David Conrad)
Date: Mon, 4 Nov 2013 09:13:00 -0800
Subject: Email Server and DNS
In-Reply-To: <77426B543150464AA3F30DF1A91365DE6ABE1F69@ESV4-MBX02.linkedin.biz>
References: <20131104041109.2905.qmail@joyce.lan> <5277BB7A.40709@dcrocker.net>
 <77426B543150464AA3F30DF1A91365DE6ABE1F69@ESV4-MBX02.linkedin.biz>
Message-ID: <20B96EF3-BB4C-481C-8DB1-09AE84384709@virtualized.org>

On Nov 4, 2013, at 8:41 AM, Franck Martin <fmartin at linkedin.com> wrote:
> www.maawg.org has published a sender BCP, please read it

You mean http://www.maawg.org/sites/maawg/files/news/MAAWG_Senders_BCP_Ver2a-updated.pdf?

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131104/1a23ec7c/attachment.bin>

From rajiva at cisco.com  Mon Nov  4 17:31:02 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 4 Nov 2013 17:31:02 +0000
Subject: BGP failure analysis and recommendations
In-Reply-To: <CAB0xJrNQu+tZ8eAs29bcA5Y3gnk5coRdYmsDvZB-wj5G0Nf3pQ@mail.gmail.com>
Message-ID: <CE977EB9.101F62%rajiva@cisco.com>


The below problem was the motivation for this BGP improvement :

http://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria


 
-----Original Message-----
From: Pete Lumbis <alumbis at gmail.com>
Date: Friday, October 25, 2013 2:01 PM
To: JRC NOC <nospam-nanog at jensenresearch.com>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: BGP failure analysis and recommendations

>As a member of the support team for a vendor, I'll say this problem isn't
>entirely unheard of. The CPU is in charge of local traffic and the BGP
>session and some sort of hardware chip or ASIC is in charge of moving
>packets through the device. If the hardware is misprogrammed it won't
>properly forward traffic while BGP thinks it's doing it's job. This is not
>to be confused with a hardware failure. This is purely a software problem.
>The software is responsible for telling the hardware what to do, and
>sometimes there are bugs there, like there are bugs in all code.
>
>The easiest way to test this kind of issue is to have some other control
>plane that is tied to the data plane. That is, the only way to make sure
>that the peer is forwarding traffic is to make it forward traffic and
>react
>when it fails. You could do something like set up IP SLA (i.e., ping) to
>something in that SP network. If the ping fails then it sounds like your
>peer may have a forwarding issue and you can apply a policy to remove or
>at
>least not prefer that peer (in case it's a false positive).
>
>-Pete
>
>
>On Wed, Oct 23, 2013 at 10:40 PM, JRC NOC
><nospam-nanog at jensenresearch.com>wrote:
>
>> Hello Nanog -
>>
>> On Saturday, October 19th at about 13:00 UTC we experienced an IP
>>failure
>> at one of our sites in the New York area.
>> It was apparently a widespread outage on the East coast, but I haven't
>> seen it discussed here.
>>
>> We are multihomed, using EBGP to three (diverse) upstream providers. One
>> provider experienced a hardware failure in a core component at one POP.
>> Regrettably, during the outage our BGP session remained active and we
>> continued receiving full routes from the affected AS.  And our prefixes
>> continued to be advertised at their border. However basically none of
>>the
>> traffic between those prefixes over that provider was delivered. The
>>bogus
>> routes stayed up for hours. We shutdown the BGP peering session when the
>> nature of the problem became clear. This was effective. I believe that
>>all
>> customer BGP routes were similarly affected, including those belonging
>>to
>> some large regional networks and corporations. I have raised the
>>questions
>> below with the provider but haven't received any information or advice.
>>
>> My question is why did our BGP configuration fail?  I'm guessing the
>>basic
>> answer is that the IGP and route reflectors within that provider were
>>still
>> connected, but the forwarding paths were unavailable.  My BGP session
>> basically acted like a bunch of static routes, with no awareness of the
>> failure(s) and no dynamic reconfiguration of the RIB.
>>
>> Is this just an unavoidable issue with scaling large networks?
>> Is it perhaps a known side effect of MPLS?
>> Have we/they lost something important in the changeover to converged
>> mutiprotocol networks?
>> Is there a better way for us edge networks to achieve IP resiliency in
>>the
>> current environment?
>>
>> This is an operational issue. Thanks in advance for any hints about what
>> happened or better practices to reduce the impact of a routine hardware
>> fault in an upstream network.
>>
>> - Eric Jensen
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  Date: Wed, 23 Oct 2013 21:26:43 -0400
>>> To: cj at chrisjensen.org
>>> From: JRC NetOps <noc at jensenresearch.com>
>>> Subject: Fwd: BGP failure analysis and recommendations
>>>
>>>
>>>  Date: Mon, 21 Oct 2013 23:19:28 -0400
>>>> To: christopher.smith at level3.com
>>>> From: Eric Jensen <ejensen at jensenresearch.com>
>>>> Subject: BGP failure analysis and recommendations
>>>> Cc: "Joe Budelis Fast-E.com" <Joe at Fast-E.com>
>>>> Bcc: noc at jensenresearch.com
>>>>
>>>> Hello Christopher Smith -
>>>>
>>>> I left you a voicemail message today. The Customer Service folks also
>>>> gave me your email address.
>>>>
>>>> We have a small, but high-value multi-homed corporate network.
>>>> We operate using our AS number 17103.
>>>>
>>>> We have BGP transit circuits with Level 3, Lightpath, and at our colo
>>>> center (AS8001)
>>>> The Level 3 circuit ID is BBPM9946
>>>>
>>>> On Saturday, October 19 2013 we had a large IP outage. I tracked it
>>>>back
>>>> to our Level 3 circuit and opened a ticket (7126634).
>>>> I have copied (below) an email I sent our channel salesman with more
>>>> details about our BGP problems during your outage.
>>>> Briefly, I am very concerned that Level 3 presented routes to us that
>>>> were not actually reachable through your network, and even worse
>>>>Level 3
>>>> kept advertising our prefixes even though your network couldn't
>>>>deliver the
>>>> traffic to us for those prefixes.
>>>>
>>>> I believe that the BGP NLRI data should follow the same IP path as the
>>>> forwarded data itself. Apparently this isn't the case at Level 3.
>>>> I also believe that your MPLS backbone should have recovered
>>>> automatically from the forwarding failure, but this didn't happen
>>>>either.
>>>> My only fix was to manually shutdown the BGP peering session with
>>>>Level
>>>> 3.
>>>>
>>>> Can you explain to me how Level 3 black-holed my routes?
>>>> Can you suggest some change to our or your BGP configuration to
>>>> eliminate this BGP failure mode?
>>>>
>>>> Just to be clear, I don't expect our circuit, or your network, to be
>>>>up
>>>> all the time. But I do expect that the routes you advertise to us and
>>>>to
>>>> your BGP peers actually be reachable through your network. On
>>>>Saturday this
>>>> didn't happen. The routes stayed up while the data transport was down.
>>>>
>>>> Our IPv4 BGP peering session with Level 3 remains down in the interim.
>>>> Please get back to me as soon as possible.
>>>>
>>>> - Eric Jensen
>>>> AS17103
>>>> 201-741-9509
>>>>
>>>>
>>>>
>>>>  Date: Mon, 21 Oct 2013 22:55:35 -0400
>>>>> To: "Joe Budelis Fast-E.com" <Joe at Fast-E.com>
>>>>> From: Eric Jensen <ejensen at jensenresearch.com>
>>>>> Subject: Re:  Fwd: Level3 Interim Response
>>>>> Bcc: noc at jensenresearch.com
>>>>>
>>>>> Hi Joe-
>>>>>
>>>>> Thanks for making the new inquiry.
>>>>> This was a big outage. Apparently Time Warner Cable and  Cablevision
>>>>> were affected greatly. Plus many large corporate networks. And of
>>>>>course
>>>>> all the single-homed Level 3 customers worldwide. My little network
>>>>>was
>>>>> just one more casualty.
>>>>>
>>>>> See:
>>>>>
>>>>> 
>>>>>http://www.dslreports.com/**forum/r28749556-Internet-**Level3-Outage-<
>>>>>http://www.dslreports.com/forum/r28749556-Internet-Level3-Outage->
>>>>>
>>>>> 
>>>>>http://online.wsj.com/news/**articles/**SB1000142405270230486450457914
>>>>>*
>>>>> 
>>>>>*5813698584246<http://online.wsj.com/news/articles/SB10001424052702304
>>>>>864504579145813698584246>
>>>>>
>>>>> For our site, the massive outage started at about 9:00 am Saturday
>>>>>and
>>>>> lasted until after 2:00PM. I opened a ticket about 9:30 am but only
>>>>> realized the routing issues and took down our BGP session about
>>>>>12:00 to
>>>>> try to minimize the problems for our traffic caused by their
>>>>>misconfigured
>>>>> BGP.
>>>>>
>>>>> There can always be equipment failures and fiber cuts. That's not the
>>>>> problem.
>>>>> From my point of view the problem was/is that Level 3 kept
>>>>> "advertising" our prefix but couldn't deliver the packets to us.
>>>>>They did
>>>>> this for all their customer's prefixes, thereby sucking in about
>>>>>half the
>>>>> NYC area internet traffic and dumping into the Hudson River, for a
>>>>>huge
>>>>> period of time.
>>>>> They also kept advertising all their BGP routes to me, thereby
>>>>>fooling
>>>>> my routers into sending outbound traffic to Level 3 where they again
>>>>>dumped
>>>>> my traffic into the Hudson.
>>>>>
>>>>> I called Level 3 customer service today and have the name of a
>>>>>network
>>>>> engineer to discuss options for fixing the BGP failure.
>>>>> If you get any response with an engineering contact please let me
>>>>>know.
>>>>>
>>>>> I shouldn't have to manually intervene to route around problems. Even
>>>>> sadder is the response from Level 3 explaining that they spent hours
>>>>>trying
>>>>> to find the problem and had to manually reconfigure their network,
>>>>>leading
>>>>> to saturated links and more problems. Their network only healed when
>>>>>the
>>>>> faulty line card was replaced.
>>>>>
>>>>> I had reactivated the BGP session later that night, but after
>>>>>reviewing
>>>>> the actual damage that we incurred, and the widespread nature of the
>>>>> failure, I have decided to leave our Level 3 BGP session down, at
>>>>>least
>>>>> until the engineering situation improves.
>>>>> There may not be any good way to use a Level 3 BGP session without
>>>>> risking the same "black hole" problem going forward. It's that type
>>>>>of
>>>>> failure that BGP is specifically designed to deal with, but it was
>>>>> developed in the days of point-to-point circuits carrying IP traffic.
>>>>>
>>>>> Nowadays some networks have a new layer between the wires and IP,
>>>>> namely MPLS, and this allowed BGP to stay up but deprived the
>>>>>routers of
>>>>> functioning IP next-hops, which they (both the Level 3 IP routers
>>>>>and the
>>>>> Level 3 personnel) were unaware of. Apparently the Level 3 IP-based
>>>>>BGP
>>>>> routers all believed they had working circuits edge-to-edge, but in
>>>>>fact
>>>>> their network was partitioned.
>>>>>
>>>>> MPLS must have some redundancy features, but they obviously weren't
>>>>> working on Saturday. This is a huge engineering failure. No large
>>>>>ISP could
>>>>> function this way for long.
>>>>>
>>>>> I can wait the 72 hours for their response. I expect it will be full
>>>>>of
>>>>> mealy-mouth platitudes about how no system is foolproof and it will
>>>>>all be
>>>>> fine now.
>>>>>
>>>>> It would be more interesting to me to be in the meeting room where
>>>>>some
>>>>> engineer has to explain how they could lose so much traffic and not
>>>>>be able
>>>>> to operate  a functioning, if degraded, network after a single line
>>>>>card
>>>>> failure.  It wouldn't be the head of network design, because that
>>>>>person
>>>>> would already have been fired.
>>>>>
>>>>> Let me know if your hear anything. I will do the same.
>>>>>
>>>>> - Eric Jensen
>>>>> AS17103
>>>>> 201-741-9509
>>>>>
>>>>>
>>>>>
>>>>>



From oscar.vives at gmail.com  Mon Nov  4 18:44:57 2013
From: oscar.vives at gmail.com (Tei)
Date: Mon, 4 Nov 2013 10:44:57 -0800
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <CAGfsgR28bxbotD9dibH0JgS9d+_g8BmH-qKmYpi12DWye6LK-w@mail.gmail.com>
References: <20131102190629.99625.qmail@joyce.lan>
 <52777B63.6070009@necom830.hpcl.titech.ac.jp>
 <CAMzo+1ZhVqsMxH+YAYdF5GYgihp5Q+gT-iYDUPyvC1WrOMMCBA@mail.gmail.com>
 <52779E60.9070805@necom830.hpcl.titech.ac.jp>
 <A73F23C3-243D-4A65-AF3D-5BC5F652024D@gmail.com>
 <028401ced96a$609ce9a0$21d6bce0$@truenet.com>
 <CAGfsgR28bxbotD9dibH0JgS9d+_g8BmH-qKmYpi12DWye6LK-w@mail.gmail.com>
Message-ID: <CACg3zYHmJLV_ma9rEvo-yPZxhjh5GWQi_Cc4BUzLSz9xphVC3A@mail.gmail.com>

Casual comment:

This scheme, have a problem.

USA is friend of country A,and country B.  A is spying on B, and share the
results with USA.  B is spying on A and share the results with USA.
A and B can make a network, but will be all but private.

-- 
--
?in del ?ensaje.

From joly at punkcast.com  Mon Nov  4 09:14:23 2013
From: joly at punkcast.com (Joly MacFie)
Date: Mon, 4 Nov 2013 04:14:23 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <260897.1383527095@turing-police.cc.vt.edu>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
 <527463E1.1080201@necom830.hpcl.titech.ac.jp>
 <254808.1383520306@turing-police.cc.vt.edu>
 <5276E6F0.60204@necom830.hpcl.titech.ac.jp>
 <260897.1383527095@turing-police.cc.vt.edu>
Message-ID: <CAM9VJk1XtyWNxV0YT2fiU2O0ZGHW9rwmQgBUEjjbHDzBCLZ7sA@mail.gmail.com>

Judging from this NSA ad, keep an eye out minority disabled females..
 [image: Inline image 1]


On Sun, Nov 3, 2013 at 8:04 PM, <Valdis.Kletnieks at vt.edu> wrote:

> On Mon, 04 Nov 2013 09:14:40 +0900, Masataka Ohta said:
> > Valdis.Kletnieks at vt.edu wrote:
> >
> > > How do you intend to *find* the agents
> > > who were hired at a government agency's under-the-table request that
> > > never had a written record that the company had access to?
> >
> > By memories of those who are at the table.
>
> So one of the two people at the table you don't have a name for because
> they're not an employee, and the other is either an NSA plant lying about
> never being at a table, or you just gave your top network troubleshooter
> a damned good reason to update their resume.
>
> Hint:  This isn't a children's game of hide and seek, and if there *is*
> an NSA plant they're not going to just smile and say "Oh, you found me".
>
> Good job at flushing out those NSA guys.  Now who are you going to
> hire to replace them, and your top troubleshooter?
>
>


-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-

From marka at isc.org  Mon Nov  4 20:16:22 2013
From: marka at isc.org (Mark Andrews)
Date: Tue, 05 Nov 2013 07:16:22 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Mon, 04 Nov 2013 13:45:58 +0100."
 <87iow8tjw9.fsf@nemi.mork.no>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <87iow8tjw9.fsf@nemi.mork.no>
Message-ID: <20131104201622.B7B599828D2@rock.dv.isc.org>


In message <87iow8tjw9.fsf at nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> Mark Andrews <marka at isc.org> writes:
>
> > That said it is possible to completely automate the secure assignment
> > of PTR records.  It is also possible to completely automate the
> > secure delegation of the reverse name space.  See
> > http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
>
> I like that.  I'd really like to see CPE vendors implementing it.
>
> AFAICT, it is perfectly possible to apply that on top of the idea you
> had about letting TCP clients update their own key. CPEs supporting the
> DHCPv6 option will use that, while the others still have the ability to
> add a KEY record from a TCP client in the deletated prefix.  As long as
> you let TSIG signed updates trump anything and do not allow unsigned
> updates if there is a KEY, then these should work just fine together.
>
> But I believe the draft could use a couple of clarifications to avoid
> interpretation bugs:
>
>    CPE generates DHCPv6 Prefix Delegation [RFC3633] request which
>    includes a KEY-RDATA option (code point TBA) which contains a the
>    rdata of a DNS KEY record containing a RSASHA256 key using the public
>    components of the previously generated RSA key pair.
>
> Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a
> "top level" option?  I.e. will it be possible to set different keys for
> (the theoretical) multi-prefix requests?

As far as I cans see there is no point in using different key RDATA.
All it does is introduce key management problems.  I expect a CPE
to only use a single public key for all prefixes that are delegated
to it.  That said we should look at rolling the key.  CPE replacement
etc.

> We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so
> it is important to explicitly state where such options, which may be
> considered local to part of the DHCPv6 message, belong.  I do know that
> RFC3315 is clear on the default:
>
>    Unless otherwise noted, each option may appear only in the options
>    area of a DHCP message and may appear only once.
>
> But experience with OPTION_DNS_SERVERS has shown that this is not
> enough.  Pleace be explicit about where in the packet any new DHCPv6
> options belong.
>
>
>    CPE device generates DNS UPDATE [RFC2136] which delegates the reverse
>    name space to itself and others if they have been configured.  The
>    CPE uses SIG(0) [RFC2931] to sign the request with owner name
>    matching the reverse of the delegated prefix.
>
> This could use a few examples and clarifications wrt the owner name.  I
> interpret it as:
>
>  IA_PD = 2001:db8:1::/48 => owner name = 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
>
> But what about for example IA_PD = 2001:db8:2:4::/62 ?  Are you going to
> add multiple owner names, or should there be some rule here allowing
> multiple delegations with a single owner name for PD on non-nibble
> boundaries?  For example
>
>  IA_PD = 2001:db8:2:4::/62
>            => owner name = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
>               allowed to update:
>                          4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
>                          5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
>                          6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
>                          7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

The DHCP server would add multiple KEY records each with the same
RDATA.  This would still be a single DNS UPDATE transaction. A non
nibble aligned PD results in multiple delegations in the DNS.

The CPE would perform multiple DNS UPDATE requests, one for each
delegation.

Doing it the other way would require telling the nameserver the
nameserver that key A is allowed to update B, C and D as well.

With multiple keys each one is self describing about what it can
update.  In terms of named's update policy you would just add this
grant clause to the zone configuration on the master to allow the
CPE to add/update the delegation.

		update-policy {
			grant * self *;
		};

> (not that I would ever consider delegating prefixes on anything but
> nibble boundaries, but someone else might - and the draft should
> consider this possibility)
> 
> 
> 
> Bj=C3=B8rn
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From fernando at gont.com.ar  Tue Nov  5 00:02:57 2013
From: fernando at gont.com.ar (Fernando Gont)
Date: Mon, 04 Nov 2013 16:02:57 -0800
Subject: Fwd: Re: Some stats on IPv6 fragments and EH filtering on the Internet
In-Reply-To: <EMEW3|dedd4c8528278c035fade0cbf2a8cb74pA3NRi03tjc|ecs.soton.ac.uk|AA811674-7409-437A-B181-B226F81C381A@ecs.soton.ac.uk>
References: <EMEW3|dedd4c8528278c035fade0cbf2a8cb74pA3NRi03tjc|ecs.soton.ac.uk|AA811674-7409-437A-B181-B226F81C381A@ecs.soton.ac.uk>
Message-ID: <527835B1.3010304@gont.com.ar>

Folks,

FYI. Thought this might be of interest.

P.S.: Input/comments welcome

Thanks!

Cheers,
Fernando




-------- Original Message --------
Subject: Some stats on IPv6 fragments and EH filtering on the Internet
Date: Mon, 04 Nov 2013 15:01:48 -0800
From: Fernando Gont <fernando at gont.com.ar>
To: 6man at ietf.org <6man at ietf.org>, IPv6 Operations <v6ops at ietf.org>

Folks,

I did a presentation on the topic at the IEPG meeting earlier this week.
It provides some concrete data regarding IPv6 fragmentation and
Extension Header filtering on the Internet.

The slideware is available at:
<http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>

Certainly there's *much* more work to be done in this area, but I
thought that this could be good food sfor some of the discussions that
we were having on the topic.

Thanks,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1


-------- Original Message --------
Subject: Re: Some stats on IPv6 fragments and EH filtering on the Internet
Date: Mon, 4 Nov 2013 23:27:12 +0000
From: Tim Chown <tjc at ecs.soton.ac.uk>
To: 6man at ietf.org <6man at ietf.org>, IPv6 Operations <v6ops at ietf.org>

Hi,

Also as per the IEPG discussion, the results I had in conjunction with a
summer MSc project student can be summarised as follows.

The headline is that he saw a 37.7% failure rate for the Fragmentation
Header (alone), a bit better than Fernando?s results, but still not good.

He tested the top 1,000 IPv6-enabled Alexa sites.
He used the scapy toolkit which supports the four main extension header
types (routing, fragmentation, destination and hop-by-hop)
He tested
a) valid combinations of those 4 extension headers as per RFC 2460
b) other non-valid combinations
c) duplicated extension headers
d) fragmentation header
Primarily TCP tests, doing HTTP GET requests.

For single extension headers, acceptance was
Routing header 63.9%
Frag header 62.3%
Hop by hop header 60%
Destination option header 15.8%
When using no extension headers, success rate was 100%
When using multiple headers, the rates fall markedly, not dissimilar
with Fernando?s numbers for longer headers.

About 120 sites accept all four types of extension headers.

A small number of sites accepted illegal combinations/ordering of
extension headers.

A more detailed set of results is being pushed to a conference paper.

I now have another student taking this further, and validating the above
results, so feel free to contact me off-list if you?re interested.

Tim

On 4 Nov 2013, at 23:01, Fernando Gont <fernando at gont.com.ar> wrote:

> Folks,
> 
> I did a presentation on the topic at the IEPG meeting earlier this week.
> It provides some concrete data regarding IPv6 fragmentation and
> Extension Header filtering on the Internet.
> 
> The slideware is available at:
> <http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>
> 
> Certainly there's *much* more work to be done in this area, but I
> thought that this could be good food sfor some of the discussions that
> we were having on the topic.
> 
> Thanks,
> -- 
> Fernando Gont
> e-mail: fernando at gont.com.ar || fgont at si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------




-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From Lee at asgard.org  Tue Nov  5 05:31:25 2013
From: Lee at asgard.org (Lee Howard)
Date: Tue, 05 Nov 2013 07:31:25 +0200
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131104201622.B7B599828D2@rock.dv.isc.org>
Message-ID: <CE9E4E3C.367C3%Lee@asgard.org>

http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00


It would be great to have this conversation in the IETF Homenet WG, as
well as DNSops.
This would solve the gaps I identified.  Not sure why I, as an ISP, would
spend money on this.

Lee




From mark.tinka at seacom.mu  Tue Nov  5 09:54:38 2013
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 5 Nov 2013 11:54:38 +0200
Subject: Fwd: [apops] APRICOT 2014 call for papers is now open
Message-ID: <201311051154.39172.mark.tinka@seacom.mu>

FYI.

Cheers,

Mark.
-------------- next part --------------
An embedded message was scrubbed...
From: Philip Smith <pfsinoz at gmail.com>
Subject: [apops] APRICOT 2014 call for papers is now open
Date: Tue, 5 Nov 2013 19:36:29 +1000
Size: 6231
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131105/54d5a048/attachment.mht>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131105/54d5a048/attachment.bin>

From bmanning at vacation.karoshi.com  Tue Nov  5 15:30:57 2013
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 5 Nov 2013 15:30:57 +0000
Subject: [pfsinoz@gmail.com: [APRICOT-INFO] APRICOT 2014 call for papers]
Message-ID: <20131105153057.GA18033@vacation.karoshi.com.>


of possible interest.

/bill

----- Forwarded message from Philip Smith <pfsinoz at gmail.com> -----

X-Mailman-Approved-At: Tue, 05 Nov 2013 19:37:41 +1000
Subject: [APRICOT-INFO] APRICOT 2014 call for papers

Hi everyone,

We have just released the call for presentations for APRICOT 2014.
Please consider presenting at APRICOT, or encourage a colleague or
friend to do so.

Also we'd really appreciate it if you would help inform members of your
local operations community about this CfP.

Many thanks!

Philip, Mark, Dean
APRICOT PC Chairs
--


Asia Pacific Regional Internet Conference on Operational Technologies
(APRICOT)
18 - 28 February 2014, Bangkok, Thailand
https://2014.apricot.net

CALL FOR PAPERS
===============

The APRICOT 2014 Programme Committee is now seeking contributions for
Presentations and Tutorials for APRICOT 2014.

We are looking for presenters who would:

- Offer a technical tutorial on an appropriate topic;
- Participate in the technical conference sessions as a speaker;
- Convene and chair panel sessions of relevant topics.

Please submit on-line at:

	http://papers.apricot.net/user/login.php?event=6

CONFERENCE MILESTONES
---------------------

Call for Papers Opens:             1 November 2013
First Draft Programme Published:   6 December 2013
Final Deadline for Submissions:    7 February 2014
Final Programme Published:        14 February 2014
Final Slides Received:            21 February 2014

PROGRAMME MATERIAL
------------------

The APRICOT Programme is organised in three parts, including
workshops, tutorials and the conference.

Topics for tutorials and the conference must be relevant to Internet
Operations and Technologies:

- IPv4 / IPv6 Routing and operations
- IPv6 deployment and transition technologies
- Internet backbone operations
- ISP and Carrier services
- IXPs and Peering
- Research on Internet Operations and Deployment
- Thai Internet
- Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware)
- DNS / DNSSEC
- Internet policy (Security, Regulation, Content Management,
  Addressing, etc)
- Access and Transport Technologies, including Cable/DSL, 3G/LTE,
  wireless, metro ethernet, fibre, MPLS
- Content & Service Delivery (Multicast, Voice, Video, "telepresence",
  Gaming) and Cloud Computing


CfP SUBMISSION
--------------

Draft slides for both tutorials and conference sessions MUST be
provided with CfP submissions otherwise the Programme Committee will
be unable to review the submission. For work in progress, the most
current information available at time of submission is acceptable.

All draft and complete slides must be submitted in PDF format
only.

Final slides are to be provided by the specified deadline for
publication on the APRICOT website.

Prospective presenters should note that the majority of speaking slots
will be filled well before the final submission deadline.  The PC will
retain a limited number of slots up to the final submission deadline
for presentations that are exceptionally timely, important, or of
critical operational importance.

Please submit on-line at:

	http://papers.apricot.net/user/login.php?event=6

Any questions or concerns should be addressed to the Programme
Committee by e-mail at:

        pc-chairs at apricot.net

We look forward to receiving your presentation proposals.

Dean Pemberton, Mark Tinka & Philip Smith
Co-Chairs, APRICOT Programme Committee
pc-chairs at apricot.net

--
_______________________________________________
Apricot-info mailing list
Apricot-info at apricot.net
http://mailman.apnic.net/mailman/listinfo/apricot-info

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


From marka at isc.org  Tue Nov  5 19:24:41 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 06 Nov 2013 06:24:41 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Tue, 05 Nov 2013 07:31:25 +0200."
 <CE9E4E3C.367C3%Lee@asgard.org>
References: <CE9E4E3C.367C3%Lee@asgard.org>
Message-ID: <20131105192442.6FFEC9926E3@rock.dv.isc.org>


In message <CE9E4E3C.367C3%Lee at asgard.org>, Lee Howard writes:
> http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
> 
> 
> It would be great to have this conversation in the IETF Homenet WG, as
> well as DNSops.

I did send the announcement to homenet as well with reply-to sent
to dnsop.  While I am in homenet I would prefer the conversation
in one place in the IETF.  I do realise that it also needs to be
here and potentially other places.

> This would solve the gaps I identified.  Not sure why I, as an ISP, would
> spend money on this.

What money do they need to spend once the DHCP server supports it?

It's a little bit of disk, a little bit of memory, a little bit
less DNS traffic to their servers (as the referral will push
queries to the customer's DNS servers) which is will come in at
cents per customer per annum.  Enterprises effectively do the
equivalent amount of work today registering PTR records in the DNS
using TSIG requests from the DHCP server.

Mark

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


From anarcat at koumbit.org  Tue Nov  5 19:31:41 2013
From: anarcat at koumbit.org (Antoine =?utf-8?Q?Beaupr=C3=A9?=)
Date: Tue, 05 Nov 2013 14:31:41 -0500
Subject: advice on BGP + CARP setup on FreeBSD
Message-ID: <87d2med4rm.fsf@marcos.anarc.at>

Hi fellow operators,

We are slowly and carefully joining the fray of autonomous systems and
started announcing our own netblock, a first test that started last
week. So far, things are going well, but before going further along this
setup, I would be curious to hear experience from other operators about
the plan we are thinking of deploying.

Our requirements:

 * free software, as much as possible
 * inexpensive
 * using existing operating system expertise (FreeBSD or Debian)

So far, we have:

 * our own ASN
 * a /21 assigned by ARIN
 * two uplinks deployed (Netelligent and Cogent)
 * Netelligent announces 3 /24 netblocks for us
 * we announce the last /24 through a BGP link with cogent

We have some horrible diagrams describing the setup here:

https://wiki.koumbit.net/RoutingService/RoadMap

As you can see, the uplinks are connected directly into a switch, in two
separate VLANs. The reason for this is we want to be able to hotswap the
routers in case of a hardware failure, but we have understood from
Cogent's documentation that this is not a good practice because the
links appears up even if the router goes down. What is your opinion on
this?

Also, we currently testing OpenBGPd for the announcements, and we are
very pleased with it. The syntax is clear and it just works, with
minimal memory usage:

https://wiki.koumbit.net/OpenBgpdMaintenance#Checking_memory_usage

However, this seems to be a fairly exotic platform, most people running
BGP with Cisco, Juniper or, in some cases Quagga or Bird for Linux
machines. Are there recmomendations on using OpenBGP in production? Good
/ bad experiences? How many people are running Linux routers vs
dedicated Cisco/Juniper/etc routers?

Finally, we are likely to complete this setup with a CARP (the free
equivalent of VRRP) on the inside of the network. FreeBSD can apparently
group interfaces and communicate with OpenBGPd - did anyone deploy such
a thing here? What are your experiences or advice?

Thanks for any advice,

A.

-- 
Sous un gouvernement qui emprisonne injustement, la place de l?homme
juste est aussi en prison.
- La d?sob?issance civile, Henry David Thoreau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131105/eabd7322/attachment.bin>

From ewilliams at connectria.com  Tue Nov  5 19:48:55 2013
From: ewilliams at connectria.com (Eric Williams)
Date: Tue, 5 Nov 2013 13:48:55 -0600
Subject: Level3 and AT&T Latency
Message-ID: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>

Is anybody else seeing or having major latency between Level 3 and AT&T 
today?  We are multi-homed with Level 3 being one of our ISP's and had to 
divert traffic after seeing these issues. 

http://www.internetpulse.net/ 

Eric


From jason at thebaughers.com  Tue Nov  5 20:04:21 2013
From: jason at thebaughers.com (Jason Baugher)
Date: Tue, 5 Nov 2013 14:04:21 -0600
Subject: Level3 and AT&T Latency
In-Reply-To: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
References: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
Message-ID: <CAGbD49q5MWyn8+aC7DZhP1+0QvAj2puZ4JnvLEQq0Aoo5JCCpQ@mail.gmail.com>

Yes, we are seeing the same issues, centering around Chicago. I have a
ticket open with Level3, but I'm assuming they're going to tell me it's
AT&T's issue.




On Tue, Nov 5, 2013 at 1:48 PM, Eric Williams <ewilliams at connectria.com>wrote:

> Is anybody else seeing or having major latency between Level 3 and AT&T
> today?  We are multi-homed with Level 3 being one of our ISP's and had to
> divert traffic after seeing these issues.
>
> http://www.internetpulse.net/
>
> Eric
>
>

From wbailey at satelliteintelligencegroup.com  Tue Nov  5 20:38:44 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 5 Nov 2013 20:38:44 +0000
Subject: DNS and nxdomain hijacking
Message-ID: <CE9E9753.D7BC%wbailey@satelliteintelligencegroup.com>

All,

I've noticed a lot more nxdomain redirects on providers (cox, uverse, tmo, etc.) networks lately. How is this being done?? Is it a magic box or some kind of subscription service?

Are any of you doing it?

//warren

From nick at foobar.org  Tue Nov  5 22:50:24 2013
From: nick at foobar.org (Nick Hilliard)
Date: Tue, 05 Nov 2013 22:50:24 +0000
Subject: advice on BGP + CARP setup on FreeBSD
In-Reply-To: <87d2med4rm.fsf@marcos.anarc.at>
References: <87d2med4rm.fsf@marcos.anarc.at>
Message-ID: <52797630.8020300@foobar.org>

On 05/11/2013 19:31, Antoine Beaupr? wrote:
> Our requirements:
> 
>  * free software, as much as possible
>  * inexpensive
>  * using existing operating system expertise (FreeBSD or Debian)

You need to make a decision on how to spend your money: on commodity router
hardware where you can easily get support if there's a problem, or on more
FOSS operating systems with a routing layer (e.g. openbgpd / bird / quagga
/ etc).

> As you can see, the uplinks are connected directly into a switch, in two
> separate VLANs. The reason for this is we want to be able to hotswap the
> routers in case of a hardware failure, but we have understood from
> Cogent's documentation that this is not a good practice because the
> links appears up even if the router goes down. What is your opinion on
> this?

Cogent is correct and their reasoning is correct.

> However, this seems to be a fairly exotic platform, most people running
> BGP with Cisco, Juniper or, in some cases Quagga or Bird for Linux
> machines. Are there recmomendations on using OpenBGP in production? Good
> / bad experiences? How many people are running Linux routers vs
> dedicated Cisco/Juniper/etc routers?

I run lots of different routing systems for a lot of different situations
(am currently using quagga, bird, openbgpd, cisco ios, cisco xr, junos and
brocade ironware for bgp stuff).  For small setups, it really doesn't make
a whole lot of difference so long as you run with a configuration which
supports both ibgp and an interior routing protocol like ospf or isis.
It's not going to make a whole lot of difference to you whether you use
quagga, openbgpd or bird because you're not going to stress the RIB engine
with only two providers.

Usually, it's better to run COTS routers (e.g. juniper / cisco / etc).  If
you don't want to do this, you will probably end up spending roughly the
same in terms of manpower, so don't be tempted to think that you're going
to save a whole lot with a free unix based system.

If you want a FOSS system and you have no preconceptions about routing, I'd
suggest using linux/freebsd + bird because bird is a truly wonderful RIB
engine.  If you are already familiar with cisco syntax, linux/freebsd +
quagga will do the job just fine.  If you have decided that you like
openbgpd and want all the features of openbgpd (including md5 passwords),
then you need openbsd + opengpd + openospfd, all of which I have found to
be frankly a pain to operate and maintain, although I think openbsd has
improved since the last time I used it in anger which was 3-4 years ago.

> Finally, we are likely to complete this setup with a CARP (the free
> equivalent of VRRP) on the inside of the network. FreeBSD can apparently
> group interfaces and communicate with OpenBGPd - did anyone deploy such
> a thing here? What are your experiences or advice?

linux carp is hopeless and I would strongly advise not to use linux if you
want to implement vrrp / carp.  Incidentally if anyone feels this is
unfair, they need to take a long hard look at the linux vmac implementation
and if they don't run screaming, I'll take my hat off.

The FreeBSD CARP implementation (which is borrow directly from openbsd)
usually works fine, but i've seen more than my fair share of kernel panics
on relatively recent freebsd relating to carp.

Srsly, get a cisco / juniper router.  Unless you're doing some incredibly
specialised large scale router implementation and you really know what
you're doing and why you're doing it, using a FOSS system will end up being
more expensive in terms of your time.

Nick



From mohta at necom830.hpcl.titech.ac.jp  Tue Nov  5 23:50:06 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Wed, 06 Nov 2013 08:50:06 +0900
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <260897.1383527095@turing-police.cc.vt.edu>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
 <527463E1.1080201@necom830.hpcl.titech.ac.jp>
 <254808.1383520306@turing-police.cc.vt.edu>
 <5276E6F0.60204@necom830.hpcl.titech.ac.jp>
 <260897.1383527095@turing-police.cc.vt.edu>
Message-ID: <5279842E.2080405@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

>>> How do you intend to *find* the agents
>>> who were hired at a government agency's under-the-table request that
>>> never had a written record that the company had access to?
>>
>> By memories of those who are at the table.
> 
> So one of the two people at the table you don't have a name for because
> they're not an employee, and the other is either an NSA plant lying about
> never being at a table, or you just gave your top network troubleshooter
> a damned good reason to update their resume.
> 
> Hint:  This isn't a children's game of hide and seek, and if there *is*
> an NSA plant they're not going to just smile and say "Oh, you found me".

Hint: I'm not talking about a way to have perfect security. I'm talking
about possible/good/recommended approach to improve the security without
witch hunting.

> Good job at flushing out those NSA guys.  Now who are you going to
> hire to replace them, and your top troubleshooter?

Feel free to hunt witches if you think it necessary.

						Masataka Ohta



From David at crmls.org  Wed Nov  6 00:00:17 2013
From: David at crmls.org (David Siegrist)
Date: Wed, 6 Nov 2013 00:00:17 +0000
Subject: Level3 and AT&T Latency
In-Reply-To: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
References: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
Message-ID: <BBE50A62287C6C45AEDD6879E14F22CC511AE472@MrMAILp02.MRODD.MRMLS>

I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today.

They just got it spliced back up.  Not sure if it is related to your latency.

David 

-----Original Message-----
From: Eric Williams [mailto:ewilliams at connectria.com] 
Sent: Tuesday, November 05, 2013 11:49 AM
To: nanog at nanog.org
Subject: Level3 and AT&T Latency

Is anybody else seeing or having major latency between Level 3 and AT&T today?  We are multi-homed with Level 3 being one of our ISP's and had to divert traffic after seeing these issues. 

http://www.internetpulse.net/ 

Eric



From mohta at necom830.hpcl.titech.ac.jp  Wed Nov  6 00:00:34 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Wed, 06 Nov 2013 09:00:34 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <81B1C5A3-AF5C-4DBF-87A4-C62FB8C2A8D0@steffann.nl>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
 <AAC2BED5-AE55-4AAB-9212-B14CC8CF1FD5@steffann.nl>
 <5274F28D.7080400@necom830.hpcl.titech.ac.jp>
 <81B1C5A3-AF5C-4DBF-87A4-C62FB8C2A8D0@steffann.nl>
Message-ID: <527986A2.6010806@necom830.hpcl.titech.ac.jp>

Sander Steffann wrote:

>> Also remember that this thread is on secure rDNS by the ISP,
>> which means you can't expect the ISP operate rDNS very securely
>> even though the ISP operate rest of networking not very securely.
> 
> You're linking things together that are completely orthogonal...

You misunderstand very basic points on why forward and reverse
DNS checking is useful.

If an attacker can snoop DHCP reply packet to a victim's CPE, the
attacker can snoop any packet to a victim's server, which is
already bad.

Worse, the attacker can override a connection to the server by
forging reply packets as if they are returned by the legitimate
server with correct TCP sequence numbers etc, which is especially
effective if combined with DOS attack to the legitimate server.

Thus, there is no point to make forward and reverse DNS secure.

That is, Mark's security model is broken only to introduce
obscurity with worse security.

						Masataka Ohta

PS

If the server and its clients share some secret for mutual
authentication as protection against snooping, there is no
point to make forward and reverse DNS secure.


From mysidia at gmail.com  Wed Nov  6 00:25:37 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 5 Nov 2013 18:25:37 -0600
Subject: DNS and nxdomain hijacking
In-Reply-To: <CE9E9753.D7BC%wbailey@satelliteintelligencegroup.com>
References: <CE9E9753.D7BC%wbailey@satelliteintelligencegroup.com>
Message-ID: <CAAAwwbUvN4WB5awfV=v3MZ0K+YxONCvqB=7Gq7iWwbiGUyK8Bw@mail.gmail.com>

On Tue, Nov 5, 2013 at 2:38 PM, Warren Bailey <
wbailey at satelliteintelligencegroup.com> wrote:


> I've noticed a lot more nxdomain redirects on providers (cox, uverse, tmo,


I believe these ISPs have been servicing a mucked up recursive DNS like
this for quite a while.

Yes, this traffic hijacking and modification of DNS server replies is very
uncool for users.    Yes, they do it anyways, on their own recursive DNS
servers; which they can do of course, on their own DNS servers.



> etc.) networks lately. How is this being done?? Is it a magic box or some
> kind of subscription service?
>

Both.   There are multiple providers specializing in ISP DNS traffic
monetization, that are well-known, with multiple articles about them;  you
redirect DNS traffic, or  insert a sniffer box between recursive DNS
servers and users,   the hijacking provider monetizes the NXDOMAIN traffic,
  the ISP gets a small share.



I  won't be surprised if they have  50 salesmen  monitoring this list,
 trampling each other to be the first to respond to your 'solicitation' now
 <G>

Are any of you doing it?
>

I only know of very large residential providers doing it.

This is believed to not be something Enterprise IT  or business clients
 will tolerate, of their ISP.

For one thing,  NXDOMAIN response tampering breaks  DNS-based  spam
filtering / hostname verification features.



> //warren
>
--
-JH

From mysidia at gmail.com  Wed Nov  6 00:47:33 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 5 Nov 2013 18:47:33 -0600
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <527986A2.6010806@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net>
 <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
 <AAC2BED5-AE55-4AAB-9212-B14CC8CF1FD5@steffann.nl>
 <5274F28D.7080400@necom830.hpcl.titech.ac.jp>
 <81B1C5A3-AF5C-4DBF-87A4-C62FB8C2A8D0@steffann.nl>
 <527986A2.6010806@necom830.hpcl.titech.ac.jp>
Message-ID: <CAAAwwbV-wWeARjzC67YjJsRnZ1cG294BAfs18WZeFtufiyF_ig@mail.gmail.com>

On Tue, Nov 5, 2013 at 6:00 PM, Masataka Ohta <
mohta at necom830.hpcl.titech.ac.jp> wrote:

> Sander Steffann wrote:
> >>...
>
> You're linking things together that are completely orthogonal...
>
> You misunderstand very basic points on why forward and reverse
> DNS checking is useful.
>

Just to note... the main reason checking reverse DNS stays useful:  is
because that it is so hard to change in many cases.

Specifically:  if a server at some IP address X is under the control of a
spammer;   and rDNS is not setup,  or  rDNS  points to some
 dynamic-looking hostname,

It will be difficult or not possible for the spammer to modify the RDNS of
the IP address, in many cases;  the RDNS is  most often managed by the ISP.

Or it may be in a DNS infrastructure running on separate networks, with
separate access credentials.


If RDNS were easy to change;  e.g. if you just needed to guess a password
to the server,  and get signing key information from a DHCP transaction;
 the spammer would just change it.


Delegating  "Secure RDNS update"   with prefix delegation  may in fact,
 make RDNS information so easy to publish,     that the spammers of the
world can do it,  after  compromising a router or  host on the victim
network,  and just  "Registering the better hostname in the DNS".



The update process may be "secure",  but there are new attack vectors.


The value of  even looking at RDNS,  let alone worrying about
Forward+Reverse DNS  agreement/confirmation   may not translate well to
IPv6.


--
-JH

From bedard.phil at gmail.com  Wed Nov  6 00:57:59 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Tue, 05 Nov 2013 19:57:59 -0500
Subject: DNS and nxdomain hijacking
In-Reply-To: <CAAAwwbUvN4WB5awfV=v3MZ0K+YxONCvqB=7Gq7iWwbiGUyK8Bw@mail.gmail.com>
Message-ID: <CE9EFB1C.7CDD8%bedard.phil@gmail.com>



On 11/5/13, 7:25 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:

>On Tue, Nov 5, 2013 at 2:38 PM, Warren Bailey <
>wbailey at satelliteintelligencegroup.com> wrote:
>
>
>> I've noticed a lot more nxdomain redirects on providers (cox, uverse,
>>tmo,
>
>
>I believe these ISPs have been servicing a mucked up recursive DNS like
>this for quite a while.

I think every major residential ISP in the US has been doing this for 5+
years now.  I worked at one provider who made a pretty decent chunk of
change off the monthly ad revenue and that was 6 years ago.  People typo a
lot of URLs.  

Charter (my current ISP) does let you disable it via the web.

Phil 




From eric-list at truenet.com  Wed Nov  6 01:19:01 2013
From: eric-list at truenet.com (Eric Tykwinski)
Date: Tue, 5 Nov 2013 20:19:01 -0500
Subject: DNS and nxdomain hijacking
In-Reply-To: <CE9EFB1C.7CDD8%bedard.phil@gmail.com>
References: <CE9EFB1C.7CDD8%bedard.phil@gmail.com>
Message-ID: <0F8818E8-8E74-493E-8F72-390C5F47DDE8@truenet.com>

Just as a side note, I don't think MS supports NXDOMAIN redirections yet, which is rather surprising.
Given I highly doubt anyone is using this external resolvers, which redirection is usually for.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300
F: 610-429-3222

On Nov 5, 2013, at 7:57 PM, Phil Bedard <bedard.phil at gmail.com> wrote:

> 
> 
> On 11/5/13, 7:25 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
> 
>> On Tue, Nov 5, 2013 at 2:38 PM, Warren Bailey <
>> wbailey at satelliteintelligencegroup.com> wrote:
>> 
>> 
>>> I've noticed a lot more nxdomain redirects on providers (cox, uverse,
>>> tmo,
>> 
>> 
>> I believe these ISPs have been servicing a mucked up recursive DNS like
>> this for quite a while.
> 
> I think every major residential ISP in the US has been doing this for 5+
> years now.  I worked at one provider who made a pretty decent chunk of
> change off the monthly ad revenue and that was 6 years ago.  People typo a
> lot of URLs.  
> 
> Charter (my current ISP) does let you disable it via the web.
> 
> Phil 
> 
> 
> 




From marka at isc.org  Wed Nov  6 01:37:21 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 06 Nov 2013 12:37:21 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Wed, 06 Nov 2013 09:00:34 +0900."
 <527986A2.6010806@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
 <AAC2BED5-AE55-4AAB-9212-B14CC8CF1FD5@steffann.nl>
 <5274F28D.7080400@necom830.hpcl.titech.ac.jp>
 <81B1C5A3-AF5C-4DBF-87A4-C62FB8C2A8D0@steffann.nl>
 <527986A2.6010806@necom830.hpcl.titech.ac.jp>
Message-ID: <20131106013721.983D799806E@rock.dv.isc.org>


In message <527986A2.6010806 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Sander Steffann wrote:
> 
> >> Also remember that this thread is on secure rDNS by the ISP,
> >> which means you can't expect the ISP operate rDNS very securely
> >> even though the ISP operate rest of networking not very securely.
> > 
> > You're linking things together that are completely orthogonal...
> 
> You misunderstand very basic points on why forward and reverse
> DNS checking is useful.
> 
> If an attacker can snoop DHCP reply packet to a victim's CPE, the
> attacker can snoop any packet to a victim's server, which is
> already bad.

The DHCP reply packet is special as is is broadcasted.  The
unicast traffic isn't seen.

> Worse, the attacker can override a connection to the server by
> forging reply packets as if they are returned by the legitimate
> server with correct TCP sequence numbers etc, which is especially
> effective if combined with DOS attack to the legitimate server.
>
> 
> Thus, there is no point to make forward and reverse DNS secure.
> 
> That is, Mark's security model is broken only to introduce
> obscurity with worse security.

This is a about adding a delegation into the DNS securely so only
the machine that the prefix is delegated to and the ISP can update
it.  There are a number of reasons to want to do this securely from
both the ISP side and the customer side regardless of whether you
secure the DNS responses themselves.

> 						Masataka Ohta
> 
> PS
> 
> If the server and its clients share some secret for mutual
> authentication as protection against snooping, there is no
> point to make forward and reverse DNS secure.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From asullivan at dyn.com  Wed Nov  6 03:30:05 2013
From: asullivan at dyn.com (Andrew Sullivan)
Date: Tue, 5 Nov 2013 22:30:05 -0500
Subject: DNS and nxdomain hijacking
In-Reply-To: <CE9EFB1C.7CDD8%bedard.phil@gmail.com>
References: <CAAAwwbUvN4WB5awfV=v3MZ0K+YxONCvqB=7Gq7iWwbiGUyK8Bw@mail.gmail.com>
 <CE9EFB1C.7CDD8%bedard.phil@gmail.com>
Message-ID: <20131106033003.GB6728@dyn.com>

On Tue, Nov 05, 2013 at 07:57:59PM -0500, Phil Bedard wrote:
> 
> I think every major residential ISP in the US has been doing this for 5+
> years now.

Comcast doesn't, because it breaks DNSSEC.

A

-- 
Andrew Sullivan
Dyn, Inc.
asullivan at dyn.com
v: +1 603 663 0448


From rps at maine.edu  Wed Nov  6 03:39:15 2013
From: rps at maine.edu (Ray Soucy)
Date: Tue, 5 Nov 2013 22:39:15 -0500
Subject: DNS and nxdomain hijacking
In-Reply-To: <20131106033003.GB6728@dyn.com>
References: <CAAAwwbUvN4WB5awfV=v3MZ0K+YxONCvqB=7Gq7iWwbiGUyK8Bw@mail.gmail.com>
 <CE9EFB1C.7CDD8%bedard.phil@gmail.com>
 <20131106033003.GB6728@dyn.com>
Message-ID: <CALFTrnN16hxQ4LFuSFHddDVWy7hsPFD7SkG35pnw5Aw0KyNjjg@mail.gmail.com>

http://en.wikipedia.org/wiki/Response_policy_zone

RPZ functionality has been widely adopted in the past few years.  Also
known as "DNS Firewall".


On Tue, Nov 5, 2013 at 10:30 PM, Andrew Sullivan <asullivan at dyn.com> wrote:

> On Tue, Nov 05, 2013 at 07:57:59PM -0500, Phil Bedard wrote:
> >
> > I think every major residential ISP in the US has been doing this for 5+
> > years now.
>
> Comcast doesn't, because it breaks DNSSEC.
>
> A
>
> --
> Andrew Sullivan
> Dyn, Inc.
> asullivan at dyn.com
> v: +1 603 663 0448
>
>


-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

From fohdeesha at gmail.com  Wed Nov  6 03:47:04 2013
From: fohdeesha at gmail.com (Jon Sands)
Date: Tue, 05 Nov 2013 22:47:04 -0500
Subject: How anti-NSA backlash could fracture the Internet along national
 borders - The Washington Post
In-Reply-To: <CAGfsgR0G6-FTY3izVHLkEMHJYU6ZT2vFwFED7f8Ea9FVgC5iPA@mail.gmail.com>
References: <ee045d19-797d-4346-8793-b854e528f813@email.android.com>
 <20131102190629.99625.qmail@joyce.lan>
 <CAGfsgR0YadG59LrmCv3eE0GtnC9e-DFX+j35vJiUA+mxbRmTQQ@mail.gmail.com>
 <CAEmG1=r=bBE8Yd4OMm=8xNh9A5_j4=u-W+Whx8su3Rbn8Q+G-g@mail.gmail.com>
 <CAGfsgR0G6-FTY3izVHLkEMHJYU6ZT2vFwFED7f8Ea9FVgC5iPA@mail.gmail.com>
Message-ID: <5279BBB8.60702@gmail.com>

My favorite is "12.8tbps Capacityz" on the second slide.


On 11/2/2013 3:44 PM, Jim Popovitch wrote:
> Yeah. I reported that to them over the Summer... hopefully their cable 
> laying crew is more attentive to detail. ;-) -Jim P. 


-- 
Jon Sands



From marka at isc.org  Wed Nov  6 04:01:00 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 06 Nov 2013 15:01:00 +1100
Subject: DNS and nxdomain hijacking
In-Reply-To: Your message of "Tue, 05 Nov 2013 22:30:05 -0500."
 <20131106033003.GB6728@dyn.com>
References: <CAAAwwbUvN4WB5awfV=v3MZ0K+YxONCvqB=7Gq7iWwbiGUyK8Bw@mail.gmail.com>
 <CE9EFB1C.7CDD8%bedard.phil@gmail.com> <20131106033003.GB6728@dyn.com>
Message-ID: <20131106040100.4C7E599919A@rock.dv.isc.org>


In message <20131106033003.GB6728 at dyn.com>, Andrew Sullivan writes:
> On Tue, Nov 05, 2013 at 07:57:59PM -0500, Phil Bedard wrote:
> > 
> > I think every major residential ISP in the US has been doing this for 5+
> > years now.
> 
> Comcast doesn't, because it breaks DNSSEC.

Only if you are validating.

BIND suppports DNSSEC aware NXDOMAIN redirection.  If the NXDOMAIN
response is verifiable and you set DO=1 on the query the redirection
will not occur.

Similar logic is implemented in DNS64 support.

> A
> 
> -- 
> Andrew Sullivan
> Dyn, Inc.
> asullivan at dyn.com
> v: +1 603 663 0448
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From jason at thebaughers.com  Wed Nov  6 04:46:44 2013
From: jason at thebaughers.com (Jason Baugher)
Date: Tue, 5 Nov 2013 22:46:44 -0600
Subject: Level3 and AT&T Latency
In-Reply-To: <BBE50A62287C6C45AEDD6879E14F22CC511AE472@MrMAILp02.MRODD.MRMLS>
References: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
 <BBE50A62287C6C45AEDD6879E14F22CC511AE472@MrMAILp02.MRODD.MRMLS>
Message-ID: <CAGbD49rAhh8b+m6zUaGpFV8-ufbmXoujoB7heFTA=L+HrVPtPA@mail.gmail.com>

For what it's worth, Level3 finally told us they had a peering issue with
AT&T. They ended up re-routing traffic for the time being until they
identify the issue.

Of course, for some reason a peering issue doesn't warrant a Network Event
on their portal...


On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist <David at crmls.org> wrote:

> I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today.
>
> They just got it spliced back up.  Not sure if it is related to your
> latency.
>
> David
>
> -----Original Message-----
> From: Eric Williams [mailto:ewilliams at connectria.com]
> Sent: Tuesday, November 05, 2013 11:49 AM
> To: nanog at nanog.org
> Subject: Level3 and AT&T Latency
>
> Is anybody else seeing or having major latency between Level 3 and AT&T
> today?  We are multi-homed with Level 3 being one of our ISP's and had to
> divert traffic after seeing these issues.
>
> http://www.internetpulse.net/
>
> Eric
>
>
>

From achatz at forthnet.gr  Wed Nov  6 06:54:26 2013
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Wed, 06 Nov 2013 08:54:26 +0200
Subject: Level3 and AT&T Latency
In-Reply-To: <CAGbD49rAhh8b+m6zUaGpFV8-ufbmXoujoB7heFTA=L+HrVPtPA@mail.gmail.com>
References: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
 <BBE50A62287C6C45AEDD6879E14F22CC511AE472@MrMAILp02.MRODD.MRMLS>
 <CAGbD49rAhh8b+m6zUaGpFV8-ufbmXoujoB7heFTA=L+HrVPtPA@mail.gmail.com>
Message-ID: <5279E7A2.5080809@forthnet.gr>

Unfortunately, many issues don't appear (deliberately?) as network events on their portal.

--
Tassos

Jason Baugher wrote on 6/11/2013 06:46:
> For what it's worth, Level3 finally told us they had a peering issue with
> AT&T. They ended up re-routing traffic for the time being until they
> identify the issue.
>
> Of course, for some reason a peering issue doesn't warrant a Network Event
> on their portal...
>
>
> On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist <David at crmls.org> wrote:
>
>> I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today.
>>
>> They just got it spliced back up.  Not sure if it is related to your
>> latency.
>>
>> David
>>
>> -----Original Message-----
>> From: Eric Williams [mailto:ewilliams at connectria.com]
>> Sent: Tuesday, November 05, 2013 11:49 AM
>> To: nanog at nanog.org
>> Subject: Level3 and AT&T Latency
>>
>> Is anybody else seeing or having major latency between Level 3 and AT&T
>> today?  We are multi-homed with Level 3 being one of our ISP's and had to
>> divert traffic after seeing these issues.
>>
>> http://www.internetpulse.net/
>>
>> Eric
>>
>>
>>



From mohta at necom830.hpcl.titech.ac.jp  Wed Nov  6 07:55:13 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Wed, 06 Nov 2013 16:55:13 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131106013721.983D799806E@rock.dv.isc.org>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
 <AAC2BED5-AE55-4AAB-9212-B14CC8CF1FD5@steffann.nl>
 <5274F28D.7080400@necom830.hpcl.titech.ac.jp>
 <81B1C5A3-AF5C-4DBF-87A4-C62FB8C2A8D0@steffann.nl>
 <527986A2.6010806@necom830.hpcl.titech.ac.jp>
 <20131106013721.983D799806E@rock.dv.isc.org>
Message-ID: <5279F5E1.9030104@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

>> You misunderstand very basic points on why forward and reverse
>> DNS checking is useful.
>>
>> If an attacker can snoop DHCP reply packet to a victim's CPE, the
>> attacker can snoop any packet to a victim's server, which is
>> already bad.
> 
> The DHCP reply packet is special as is is broadcasted.

What?

Rfc3315 is explicit on it:

   18.2.8. Transmission of Reply Messages

   The Reply message MUST be unicast
   through the interface on which the original message was received.

>> That is, Mark's security model is broken only to introduce
>> obscurity with worse security.
> 
> This is a about adding a delegation into the DNS securely so only
> the machine that the prefix is delegated to and the ISP can update
> it.  There are a number of reasons to want to do this securely from
> both the ISP side and the customer side regardless of whether you
> secure the DNS responses themselves.

And carrying TSIG key in DHCP reply is just secure from the both sides.

						Masataka Ohta



From marka at isc.org  Wed Nov  6 08:30:38 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 06 Nov 2013 19:30:38 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Wed, 06 Nov 2013 16:55:13 +0900."
 <5279F5E1.9030104@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
 <AAC2BED5-AE55-4AAB-9212-B14CC8CF1FD5@steffann.nl>
 <5274F28D.7080400@necom830.hpcl.titech.ac.jp>
 <81B1C5A3-AF5C-4DBF-87A4-C62FB8C2A8D0@steffann.nl>
 <527986A2.6010806@necom830.hpcl.titech.ac.jp>
 <20131106013721.983D799806E@rock.dv.isc.org>
 <5279F5E1.9030104@necom830.hpcl.titech.ac.jp>
Message-ID: <20131106083038.5934B99BFDC@rock.dv.isc.org>


In message <5279F5E1.9030104 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> >> You misunderstand very basic points on why forward and reverse
> >> DNS checking is useful.
> >>
> >> If an attacker can snoop DHCP reply packet to a victim's CPE, the
> >> attacker can snoop any packet to a victim's server, which is
> >> already bad.
> > 
> > The DHCP reply packet is special as is is broadcasted.
> 
> What?
> 
> Rfc3315 is explicit on it:
> 
>    18.2.8. Transmission of Reply Messages
> 
>    The Reply message MUST be unicast
>    through the interface on which the original message was received.

While IPv6 is unicast, IPv4 isn't and having a scheme that will work
for IPv4 as well as IPv6 is useful.  Also there is NO GUARANTEE that
the response can't be seen so you design the protocol to work when
it can be seen.

> >> That is, Mark's security model is broken only to introduce
> >> obscurity with worse security.
> > 
> > This is a about adding a delegation into the DNS securely so only
> > the machine that the prefix is delegated to and the ISP can update
> > it.  There are a number of reasons to want to do this securely from
> > both the ISP side and the customer side regardless of whether you
> > secure the DNS responses themselves.
> 
> And carrying TSIG key in DHCP reply is just secure from the both sides.

Not in the clear it isn't.
 
> 						Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From mohta at necom830.hpcl.titech.ac.jp  Wed Nov  6 10:25:43 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Wed, 06 Nov 2013 19:25:43 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131106083038.5934B99BFDC@rock.dv.isc.org>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net> <20131031235110.D505696611F@rock.dv.isc.org>
 <5273525C.5060908@necom830.hpcl.titech.ac.jp>
 <20131101215423.32B5896C2C5@rock.dv.isc.org>
 <52743027.7050203@necom830.hpcl.titech.ac.jp>
 <20131102002035.963BA96D853@rock.dv.isc.org>
 <527459C4.5000308@necom830.hpcl.titech.ac.jp>
 <20131102041302.41D5396E981@rock.dv.isc.org>
 <5274A77A.8090403@necom830.hpcl.titech.ac.jp>
 <20131102105133.96AB496F732@rock.dv.isc.org>
 <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>
 <AAC2BED5-AE55-4AAB-9212-B14CC8CF1FD5@steffann.nl>
 <5274F28D.7080400@necom830.hpcl.titech.ac.jp>
 <81B1C5A3-AF5C-4DBF-87A4-C62FB8C2A8D0@steffann.nl>
 <527986A2.6010806@necom830.hpcl.titech.ac.jp>
 <20131106013721.983D799806E@rock.dv.isc.org>
 <5279F5E1.9030104@necom830.hpcl.titech.ac.jp>
 <20131106083038.5934B99BFDC@rock.dv.isc.org>
Message-ID: <527A1927.5070303@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

>>> The DHCP reply packet is special as is is broadcasted.
>>
>> What?
>>
>> Rfc3315 is explicit on it:
>>
>>     18.2.8. Transmission of Reply Messages
>>
>>     The Reply message MUST be unicast
>>     through the interface on which the original message was received.
> 
> While IPv6 is unicast, IPv4 isn't and having a scheme that will work
> for IPv4 as well as IPv6 is useful.

In your draft, you wrote:

   CPE generates DHCPv6 Prefix Delegation [RFC3633] request which

Moreover, even for IPv4, the scheme can (and should) mandate unicast
DHCP reply.

> Also there is NO GUARANTEE that
> the response can't be seen so you design the protocol to work when
> it can be seen.

Your misunderstanding on DHCPv6 is OK, because you also
misunderstand that it were more secure?

Then, as there is NO GUARANTEE that CAs of DNSSEC can't be
compromised, you MUST design the protocol to work when they
can be compromised.

>> And carrying TSIG key in DHCP reply is just secure from the both
>> sides.
>
> Not in the clear it isn't.

Clear text in DHCP reply is just secure when required security
level allows to use DHCP.

					Masataka Ohta



From Jason_Livingood at cable.comcast.com  Wed Nov  6 13:54:51 2013
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Wed, 6 Nov 2013 13:54:51 +0000
Subject: DNS and nxdomain hijacking
In-Reply-To: <CE9E9753.D7BC%wbailey@satelliteintelligencegroup.com>
Message-ID: <10229F86C86EB444898E629583FD4171EAA20D66@PACDCEXMB06.cable.comcast.com>

You can find a fairly good overview at http://tools.ietf.org/html/draft-livingood-dns-redirect-03

Comcast does not do this, see http://corporate.comcast.com/comcast-voices/comcast-domain-helper-shuts-down

Jason Livingood (Comcast)


On 11/5/13, 3:38 PM, "Warren Bailey" <wbailey at satelliteintelligencegroup.com<mailto:wbailey at satelliteintelligencegroup.com>> wrote:

All,

I've noticed a lot more nxdomain redirects on providers (cox, uverse, tmo, etc.) networks lately. How is this being done?? Is it a magic box or some kind of subscription service?

Are any of you doing it?

//warren


From Jason_Livingood at cable.comcast.com  Wed Nov  6 13:55:37 2013
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Wed, 6 Nov 2013 13:55:37 +0000
Subject: DNS and nxdomain hijacking
In-Reply-To: <CE9EFB1C.7CDD8%bedard.phil@gmail.com>
Message-ID: <10229F86C86EB444898E629583FD4171EAA20D9A@PACDCEXMB06.cable.comcast.com>

On 11/5/13, 7:57 PM, "Phil Bedard" <bedard.phil at gmail.com> wrote:

>I think every major residential ISP in the US has been doing this for 5+
>years now.  I worked at one provider who made a pretty decent chunk of
>change off the monthly ad revenue and that was 6 years ago.  People typo a
>lot of URLs.  

There?s less money in it that you?d think and the monetization rates are
declining.

Jason



From Jason_Livingood at cable.comcast.com  Wed Nov  6 13:57:33 2013
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Wed, 6 Nov 2013 13:57:33 +0000
Subject: DNS and nxdomain hijacking
In-Reply-To: <20131106040100.4C7E599919A@rock.dv.isc.org>
Message-ID: <10229F86C86EB444898E629583FD4171EAA20DEB@PACDCEXMB06.cable.comcast.com>

On 11/5/13, 11:01 PM, "Mark Andrews" <marka at isc.org> wrote:

>In message <20131106033003.GB6728 at dyn.com>, Andrew Sullivan writes:
>> On Tue, Nov 05, 2013 at 07:57:59PM -0500, Phil Bedard wrote:
>> > 
>> > I think every major residential ISP in the US has been doing this for
>>5+
>> > years now.
>> 
>> Comcast doesn't, because it breaks DNSSEC.
>
>Only if you are validating.

Exactly. And this was one of the central arguments that helped defeat the
DNS redirection portions of SOPA/PIPA/ProtectIP/COICA.

Jason



From Jason_Livingood at cable.comcast.com  Wed Nov  6 14:02:49 2013
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Wed, 6 Nov 2013 14:02:49 +0000
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <CE9E4E3C.367C3%Lee@asgard.org>
Message-ID: <10229F86C86EB444898E629583FD4171EAA20EBF@PACDCEXMB06.cable.comcast.com>

Reverse DNS for (typical) residential customer IPv6 addresses is dead,
people just haven?t come to grips with it just yet? ;-)


When publicly-reachable services in home networks are created that may be
a different matter of course. But it is hard to imagine an ISP
automatically or dynamically generating reverse records for all the IPv6
addresses handed out to your average residential users.

Jason


On 11/5/13, 12:31 AM, "Lee Howard" <Lee at asgard.org> wrote:

>http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
>
>
>It would be great to have this conversation in the IETF Homenet WG, as
>well as DNSops.
>This would solve the gaps I identified.  Not sure why I, as an ISP, would
>spend money on this.
>
>Lee
>
>
>



From james.cutler at consultant.com  Wed Nov  6 14:34:56 2013
From: james.cutler at consultant.com (Cutler James R)
Date: Wed, 6 Nov 2013 09:34:56 -0500
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <10229F86C86EB444898E629583FD4171EAA20EBF@PACDCEXMB06.cable.comcast.com>
References: <10229F86C86EB444898E629583FD4171EAA20EBF@PACDCEXMB06.cable.comcast.com>
Message-ID: <5964ADA4-8FCF-4FCE-9E64-7474CCAE57F2@consultant.com>

On Nov 6, 2013, at 9:02 AM, Livingood, Jason <Jason_Livingood at cable.comcast.com> wrote:

> Reverse DNS for (typical) residential customer IPv6 addresses is dead,
> people just haven?t come to grips with it just yet? ;-)
> 
> 
> When publicly-reachable services in home networks are created that may be
> a different matter of course. But it is hard to imagine an ISP
> automatically or dynamically generating reverse records for all the IPv6
> addresses handed out to your average residential users.
> 
> Jason
> 
> 
> On 11/5/13, 12:31 AM, "Lee Howard" <Lee at asgard.org> wrote:
> 
>> http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
>> 
>> 
>> It would be great to have this conversation in the IETF Homenet WG, as
>> well as DNSops.
>> This would solve the gaps I identified.  Not sure why I, as an ISP, would
>> spend money on this.
>> 
>> Lee
>> 
>> 
>> 
> 
> 

Dynamic DNS providers will undoubtably endeavor to make money from AAAA and SRV entries for publicly-reachable services in SOHO and home networks. Dynamic DNS providers are normally not delegated authority to provide PTR records for ISP managed addresses, making provision of complementary AAAA and PTR records highly unlikely.  

Because of the cost of scaling and delegation issues I agree with Jason and see no compelling business case for rDNS services for SOHO or residential users. 

It?s dead,
	Jim 

James R. Cutler
james.cutler at consultant.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 243 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131106/c98f8967/attachment.bin>

From David.Siegel at Level3.com  Wed Nov  6 15:10:43 2013
From: David.Siegel at Level3.com (Siegel, David)
Date: Wed, 6 Nov 2013 15:10:43 +0000
Subject: Level3 and AT&T Latency
In-Reply-To: <5279E7A2.5080809@forthnet.gr>
References: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
 <BBE50A62287C6C45AEDD6879E14F22CC511AE472@MrMAILp02.MRODD.MRMLS>
 <CAGbD49rAhh8b+m6zUaGpFV8-ufbmXoujoB7heFTA=L+HrVPtPA@mail.gmail.com>
 <5279E7A2.5080809@forthnet.gr>
Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC05BFFA77A@USIDCWVEMBX10.corp.global.level3.com>

As a matter of pure competitive intelligence gathering (i.e. I do not mean this as a rhetorical question), which providers list peering issues on their portal?  Particularly when they might be a bit more of an ongoing nature vs. a concrete outage?


Dave


-----Original Message-----
From: Tassos Chatzithomaoglou [mailto:achatz at forthnet.gr] 
Sent: Tuesday, November 05, 2013 11:54 PM
To: nanog at nanog.org
Subject: Re: Level3 and AT&T Latency

Unfortunately, many issues don't appear (deliberately?) as network events on their portal.

--
Tassos

Jason Baugher wrote on 6/11/2013 06:46:
> For what it's worth, Level3 finally told us they had a peering issue 
> with AT&T. They ended up re-routing traffic for the time being until 
> they identify the issue.
>
> Of course, for some reason a peering issue doesn't warrant a Network 
> Event on their portal...
>
>
> On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist <David at crmls.org> wrote:
>
>> I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today.
>>
>> They just got it spliced back up.  Not sure if it is related to your 
>> latency.
>>
>> David
>>
>> -----Original Message-----
>> From: Eric Williams [mailto:ewilliams at connectria.com]
>> Sent: Tuesday, November 05, 2013 11:49 AM
>> To: nanog at nanog.org
>> Subject: Level3 and AT&T Latency
>>
>> Is anybody else seeing or having major latency between Level 3 and 
>> AT&T today?  We are multi-homed with Level 3 being one of our ISP's 
>> and had to divert traffic after seeing these issues.
>>
>> http://www.internetpulse.net/
>>
>> Eric
>>
>>
>>



From Valdis.Kletnieks at vt.edu  Wed Nov  6 15:55:24 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 06 Nov 2013 10:55:24 -0500
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: Your message of "Wed, 06 Nov 2013 08:50:06 +0900."
 <5279842E.2080405@necom830.hpcl.titech.ac.jp>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
 <527463E1.1080201@necom830.hpcl.titech.ac.jp>
 <254808.1383520306@turing-police.cc.vt.edu>
 <5276E6F0.60204@necom830.hpcl.titech.ac.jp>
 <260897.1383527095@turing-police.cc.vt.edu>
 <5279842E.2080405@necom830.hpcl.titech.ac.jp>
Message-ID: <4230.1383753324@turing-police.cc.vt.edu>

On Wed, 06 Nov 2013 08:50:06 +0900, Masataka Ohta said:
> Valdis.Kletnieks at vt.edu wrote:
>
> >>> How do you intend to *find* the agents
> >>> who were hired at a government agency's under-the-table request that
> >>> never had a written record that the company had access to?
> >>
> >> By memories of those who are at the table.

> Hint: I'm not talking about a way to have perfect security. I'm talking
> about possible/good/recommended approach to improve the security without
> witch hunting.

You still haven't explained how "the memories of those who are at the table"
help, when the NSA plant has very good reasons to say they're not an NSA
plant, and you haven't explained how you can show they *are* a plant.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131106/ba07e57c/attachment.bin>

From landonstewart at gmail.com  Wed Nov  6 18:30:20 2013
From: landonstewart at gmail.com (Landon)
Date: Wed, 6 Nov 2013 10:30:20 -0800
Subject: Do you obfuscate email headers when reporting spam issues to clients?
Message-ID: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>

Hello,

We (iWeb AS32613) are currently making great strides in getting out from
under the volume of reports received and getting on top of things.

How much trouble does your abuse department go to in order to obfuscate
headers when providing evidence of spamming activity regardless of if it?s
intentional/professional spammer activity or some kind of malware infection
allowing a third party to spam.  Especially for the pro spammers, we don?t
want them list washing anything or worse yet becoming privy to spamtrap
data if the reporting party wasn?t smart enough to obfuscate their own data
before sending in the report.

So basically in order to be able to provide some evidence to clients they
can use in the case of an infection of some type but not give away too much
information to professional spammers we need to find a balance.  I?m not
sure if it?s worthwhile going to too much trouble on this since basically
regardless of the data they get sent they are going to be nuked if they are
actual spammers anyway.

-- 
Landon Stewart <LandonStewart at Gmail.com>

From me at anuragbhatia.com  Wed Nov  6 21:11:50 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Wed, 6 Nov 2013 22:11:50 +0100
Subject: Recovery mode on Juniper M7i
Message-ID: <CAJ0+aXZKQ8L0P9sf1ikv9suDCipaJv3NFr7jLYSNXDLs0JP37w@mail.gmail.com>

Hello everyone!


Greetings of the day.


I am kind of (badly) stuck with multiple routers and not able to recover
the root password. It's Juniper M7i. I have followed the Juniper support
page as given here -
http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
strange enough that it worked with one of routers I have but failed on
rest all.


I am getting stuck on Step #12. As I give "boot -s" to get into single user
mode of BSD, system next asks me for root password and hence I am out of
luck to get into "recovery mode". I tried pressing enter on that prompt as
well but no luck. I am connecting to router via console and do have
physical access to router(s).


Was wondering if someone has seen similar issues and could guide on what I
am doing wrong? Most of other help pages I have seen on net have same exact
steps as given on that page.




Thanks.
-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From bill at herrin.us  Wed Nov  6 21:24:26 2013
From: bill at herrin.us (William Herrin)
Date: Wed, 6 Nov 2013 16:24:26 -0500
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
References: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
Message-ID: <CAP-guGU7mVwyacwOMkdKO2wJJ4AwJ5X3XR059_mBSrhGmzuL6w@mail.gmail.com>

On Wed, Nov 6, 2013 at 1:30 PM, Landon <landonstewart at gmail.com> wrote:
> How much trouble does your abuse department go to in order to obfuscate
> headers when providing evidence of spamming activity regardless of if it?s
> intentional/professional spammer activity or some kind of malware infection
> allowing a third party to spam.  Especially for the pro spammers, we don?t
> want them list washing anything or worse yet becoming privy to spamtrap
> data if the reporting party wasn?t smart enough to obfuscate their own data
> before sending in the report.

Howdy,

It depends on the exact situation, but the general-purpose answer is:
none. zero. zip.

The customer usually can't act on your information unless he can line
it up with an entry in his own logs. He needs lots of details in the
headers to figure out which computer or which of his users the message
came from. And he needs that information to determine whether the
message really came from his system -- headers get forged, you know.

If he can line it up with an entry in his logs then, if he's a
spammer, he knows what address the message was sent to rendering your
obfuscation pointless. And by now spammers are very good at list
scrubbing from the slightest bit of uniquely identifiable information
they can get back. Assuming they bother, which many don't.

It does depend on the situation though. You shouldn't be forwarding
the customer 200 spam complaints. After a small sample of messages he
either has enough information to track the source of the problem or he
is the problem.

Also, when I bounce spam, I scrub my antispam engine's report from the
bounce. No point telling the spammer how he failed to reach me.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From marka at isc.org  Wed Nov  6 21:26:26 2013
From: marka at isc.org (Mark Andrews)
Date: Thu, 07 Nov 2013 08:26:26 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Wed, 06 Nov 2013 09:34:56 -0500."
 <5964ADA4-8FCF-4FCE-9E64-7474CCAE57F2@consultant.com>
References: <10229F86C86EB444898E629583FD4171EAA20EBF@PACDCEXMB06.cable.comcast.com>
 <5964ADA4-8FCF-4FCE-9E64-7474CCAE57F2@consultant.com>
Message-ID: <20131106212627.4CBDF99EFC7@rock.dv.isc.org>



In message <5964ADA4-8FCF-4FCE-9E64-7474CCAE57F2 at consultant.com>, Cutler James R writes:
> On Nov 6, 2013, at 9:02 AM, Livingood, Jason
> <Jason_Livingood at cable.comcast.com> wrote:
>
> > Reverse DNS for (typical) residential customer IPv6 addresses is dead,
> > people just haven't come to grips with it just yet.;-)
> >
> >
> > When publicly-reachable services in home networks are created that may
> > be a different matter of course. But it is hard to imagine an ISP
> > automatically or dynamically generating reverse records for all the IPv6
> > addresses handed out to your average residential users.
> >
> > Jason

This discussion is currently NOT about ISP's generating PTR records
for IPv6 reverse.

It is about the automatic delegation of the DNS reverse namespace
to to servers under customer control when the CPE device requests
it as part of the Prefix Delegation request.  This is about a adding
KEY, DS and NS records at the delegation point in a secure manner.

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


From mehmet at akcin.net  Wed Nov  6 21:26:47 2013
From: mehmet at akcin.net (Mehmet Akcin)
Date: Wed, 6 Nov 2013 13:26:47 -0800
Subject: Recovery mode on Juniper M7i
In-Reply-To: <CAJ0+aXZKQ8L0P9sf1ikv9suDCipaJv3NFr7jLYSNXDLs0JP37w@mail.gmail.com>
References: <CAJ0+aXZKQ8L0P9sf1ikv9suDCipaJv3NFr7jLYSNXDLs0JP37w@mail.gmail.com>
Message-ID: <4636E57C-5D60-4967-8FDB-A68AD568D42D@akcin.net>


On Nov 6, 2013, at 1:11 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Hello everyone!
> 
> 
> Greetings of the day.
> 
> 
> I am kind of (badly) stuck with multiple routers and not able to recover
> the root password. It's Juniper M7i. I have followed the Juniper support
> page as given here -
> http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
> strange enough that it worked with one of routers I have but failed on
> rest all.
> 

what's your junos version?

From pmsac.nanog at gmail.com  Wed Nov  6 21:28:43 2013
From: pmsac.nanog at gmail.com (Pedro Cavaca)
Date: Wed, 6 Nov 2013 21:28:43 +0000
Subject: Recovery mode on Juniper M7i
In-Reply-To: <CAJ0+aXZKQ8L0P9sf1ikv9suDCipaJv3NFr7jLYSNXDLs0JP37w@mail.gmail.com>
References: <CAJ0+aXZKQ8L0P9sf1ikv9suDCipaJv3NFr7jLYSNXDLs0JP37w@mail.gmail.com>
Message-ID: <CAE42oJqoF3+n0OXLE=LopupxQA07baKvXpPPW990ciMN6OPQKQ@mail.gmail.com>

Maybe you're not doing anything wrong and someone tweaked the routers and
marked the console as insecure, a previous owner maybe?

http://superuser.com/questions/85536/securing-freebsd-in-single-user-mode

http://www.freebsd.org/cgi/man.cgi?query=boot&sektion=8

HTH.


On 6 November 2013 21:11, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Hello everyone!
>
>
> Greetings of the day.
>
>
> I am kind of (badly) stuck with multiple routers and not able to recover
> the root password. It's Juniper M7i. I have followed the Juniper support
> page as given here -
>
> http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
> strange enough that it worked with one of routers I have but failed on
> rest all.
>
>
> I am getting stuck on Step #12. As I give "boot -s" to get into single user
> mode of BSD, system next asks me for root password and hence I am out of
> luck to get into "recovery mode". I tried pressing enter on that prompt as
> well but no luck. I am connecting to router via console and do have
> physical access to router(s).
>
>
> Was wondering if someone has seen similar issues and could guide on what I
> am doing wrong? Most of other help pages I have seen on net have same exact
> steps as given on that page.
>
>
>
>
> Thanks.
> --
>
>
> Anurag Bhatia
> anuragbhatia.com
>
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
> Twitter<https://twitter.com/anurag_bhatia>
> Skype: anuragbhatia.com
>

From bill at herrin.us  Wed Nov  6 21:45:31 2013
From: bill at herrin.us (William Herrin)
Date: Wed, 6 Nov 2013 16:45:31 -0500
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
References: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
Message-ID: <CAP-guGWwf=hVUWatmn14v-7Ssor29WQ8tJpoyJJZ+S5Gcf3j+w@mail.gmail.com>

On Wed, Nov 6, 2013 at 1:30 PM, Landon <landonstewart at gmail.com> wrote:
> We (iWeb AS32613) are currently making great strides in getting out from
> under the volume of reports received and getting on top of things.

Incidentally, I'd suggest that an ounce of prevention is worth a pound
of cure. Simply block outbound tcp port 25 for new hosting customers
on a "tell me if you want it open" basis. Don't make 'em jump through
hoops: if they want it open, open it. But for everybody who doesn't
tell you they want it open, keep it closed. Then analyze your data
traffic for a month or two and close the port on any old customers
that haven't sent any email.

By doing so, you restrict the potential source of the problem to just
those customers who intentionally generate email from their hosted
service. Non-email using customers who get hit with worms and spambots
will bounce off your shield. Also, you force spammers to bring
themselves to your notice before they can send any mail -- something
they're disinclined to do.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From raaki.88 at gmail.com  Wed Nov  6 21:33:12 2013
From: raaki.88 at gmail.com (Rakesh M)
Date: Thu, 7 Nov 2013 03:03:12 +0530
Subject: Recovery mode on Juniper M7i
In-Reply-To: <CAJ0+aXZKQ8L0P9sf1ikv9suDCipaJv3NFr7jLYSNXDLs0JP37w@mail.gmail.com>
References: <CAJ0+aXZKQ8L0P9sf1ikv9suDCipaJv3NFr7jLYSNXDLs0JP37w@mail.gmail.com>
Message-ID: <CAC2aK2p00QynK5LmxmPnOe4d7JS=e2fB7GLZJRLeC2bEUb2x-Q@mail.gmail.com>

Can you paste in the output after  'boot -s' , I came across several issues
while recovering Root Password, But never faced this :)


On Thu, Nov 7, 2013 at 2:41 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Hello everyone!
>
>
> Greetings of the day.
>
>
> I am kind of (badly) stuck with multiple routers and not able to recover
> the root password. It's Juniper M7i. I have followed the Juniper support
> page as given here -
>
> http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
> strange enough that it worked with one of routers I have but failed on
> rest all.
>
>
> I am getting stuck on Step #12. As I give "boot -s" to get into single user
> mode of BSD, system next asks me for root password and hence I am out of
> luck to get into "recovery mode". I tried pressing enter on that prompt as
> well but no luck. I am connecting to router via console and do have
> physical access to router(s).
>
>
> Was wondering if someone has seen similar issues and could guide on what I
> am doing wrong? Most of other help pages I have seen on net have same exact
> steps as given on that page.
>
>
>
>
> Thanks.
> --
>
>
> Anurag Bhatia
> anuragbhatia.com
>
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
> Twitter<https://twitter.com/anurag_bhatia>
> Skype: anuragbhatia.com
>

From me at anuragbhatia.com  Wed Nov  6 21:39:07 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Wed, 6 Nov 2013 22:39:07 +0100
Subject: Recovery mode on Juniper M7i
In-Reply-To: <CAC2aK2p00QynK5LmxmPnOe4d7JS=e2fB7GLZJRLeC2bEUb2x-Q@mail.gmail.com>
References: <CAJ0+aXZKQ8L0P9sf1ikv9suDCipaJv3NFr7jLYSNXDLs0JP37w@mail.gmail.com>
 <CAC2aK2p00QynK5LmxmPnOe4d7JS=e2fB7GLZJRLeC2bEUb2x-Q@mail.gmail.com>
Message-ID: <CAJ0+aXZ+cT6TtHsxNZoPt=xT-1i31Otywktz707-zD3qLZBv=A@mail.gmail.com>

Hi sure


Please find screenshot...


@Mehmet - I checked that in daytime and didn't found anything specific
about that version. Sorry don't have it handy with me right now but will
check exact version again in morning and will update you.


On Wed, Nov 6, 2013 at 10:33 PM, Rakesh M <raaki.88 at gmail.com> wrote:

> Can you paste in the output after  'boot -s' , I came across several
> issues while recovering Root Password, But never faced this :)
>
>
> On Thu, Nov 7, 2013 at 2:41 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:
>
>> Hello everyone!
>>
>>
>> Greetings of the day.
>>
>>
>> I am kind of (badly) stuck with multiple routers and not able to recover
>> the root password. It's Juniper M7i. I have followed the Juniper support
>> page as given here -
>>
>> http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
>> strange enough that it worked with one of routers I have but failed on
>> rest all.
>>
>>
>> I am getting stuck on Step #12. As I give "boot -s" to get into single
>> user
>> mode of BSD, system next asks me for root password and hence I am out of
>> luck to get into "recovery mode". I tried pressing enter on that prompt as
>> well but no luck. I am connecting to router via console and do have
>> physical access to router(s).
>>
>>
>> Was wondering if someone has seen similar issues and could guide on what I
>> am doing wrong? Most of other help pages I have seen on net have same
>> exact
>> steps as given on that page.
>>
>>
>>
>>
>> Thanks.
>> --
>>
>>
>> Anurag Bhatia
>> anuragbhatia.com
>>
>> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
>> Twitter<https://twitter.com/anurag_bhatia>
>> Skype: anuragbhatia.com
>>
>
>


-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From jlsorrels at kanren.net  Wed Nov  6 21:59:27 2013
From: jlsorrels at kanren.net (Jeff Sorrels)
Date: Wed, 06 Nov 2013 15:59:27 -0600
Subject: Recovery mode on Juniper M7i
In-Reply-To: <CAE42oJqoF3+n0OXLE=LopupxQA07baKvXpPPW990ciMN6OPQKQ@mail.gmail.com>
References: <CAJ0+aXZKQ8L0P9sf1ikv9suDCipaJv3NFr7jLYSNXDLs0JP37w@mail.gmail.com>
 <CAE42oJqoF3+n0OXLE=LopupxQA07baKvXpPPW990ciMN6OPQKQ@mail.gmail.com>
Message-ID: <527ABBBF.5090501@kanren.net>

Direct access to the bootstrap loader should bypass any access 
restrictions configured on the box.  However, it sounds like the device 
is not dropping into single-user mode.

I would suggest removing and wiping the CF card.  Then boot from 
alternative media (USB) and snapshot on to the blank card.

Cheers,
Jeff




On 11/6/2013 3:28 PM, Pedro Cavaca wrote:
> Maybe you're not doing anything wrong and someone tweaked the routers and
> marked the console as insecure, a previous owner maybe?
>
> http://superuser.com/questions/85536/securing-freebsd-in-single-user-mode
>
> http://www.freebsd.org/cgi/man.cgi?query=boot&sektion=8
>
> HTH.
>
>
> On 6 November 2013 21:11, Anurag Bhatia <me at anuragbhatia.com> wrote:
>
>> Hello everyone!
>>
>>
>> Greetings of the day.
>>
>>
>> I am kind of (badly) stuck with multiple routers and not able to recover
>> the root password. It's Juniper M7i. I have followed the Juniper support
>> page as given here -
>>
>> http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
>> strange enough that it worked with one of routers I have but failed on
>> rest all.
>>
>>
>> I am getting stuck on Step #12. As I give "boot -s" to get into single user
>> mode of BSD, system next asks me for root password and hence I am out of
>> luck to get into "recovery mode". I tried pressing enter on that prompt as
>> well but no luck. I am connecting to router via console and do have
>> physical access to router(s).
>>
>>
>> Was wondering if someone has seen similar issues and could guide on what I
>> am doing wrong? Most of other help pages I have seen on net have same exact
>> steps as given on that page.
>>
>>
>>
>>
>> Thanks.
>> --
>>
>>
>> Anurag Bhatia
>> anuragbhatia.com
>>
>> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
>> Twitter<https://twitter.com/anurag_bhatia>
>> Skype: anuragbhatia.com
>>

-- 
Jeff Sorrels
Network Administrator
KanREN, Inc
jlsorrels at kanren.net
785-856-9820, #2



From dclements at gmail.com  Wed Nov  6 22:09:19 2013
From: dclements at gmail.com (Doug Clements)
Date: Wed, 6 Nov 2013 17:09:19 -0500
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CAP-guGWwf=hVUWatmn14v-7Ssor29WQ8tJpoyJJZ+S5Gcf3j+w@mail.gmail.com>
References: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
 <CAP-guGWwf=hVUWatmn14v-7Ssor29WQ8tJpoyJJZ+S5Gcf3j+w@mail.gmail.com>
Message-ID: <CADVNyRYKHtJSybiFu5Y8aOZCAJYtiBEpZp4s=NRv2J77HQ+h3A@mail.gmail.com>

On Wed, Nov 6, 2013 at 4:45 PM, William Herrin <bill at herrin.us> wrote:

> Incidentally, I'd suggest that an ounce of prevention is worth a pound
> of cure. Simply block outbound tcp port 25 for new hosting customers
> on a "tell me if you want it open" basis.
>
>
Or to thwart those clever spammers, block inbound SYN/ACK packets with a
source port of 25. This catches the ones who send SYNs out other providers
with your network's source addresses which bypasses most simple ACLs.

--Doug

From amitchell at isipp.com  Wed Nov  6 22:16:55 2013
From: amitchell at isipp.com (Anne P. Mitchell, Esq.)
Date: Wed, 6 Nov 2013 15:16:55 -0700
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <mailman.1274.1383775233.40664.nanog@nanog.org>
References: <mailman.1274.1383775233.40664.nanog@nanog.org>
Message-ID: <F7D4C3BC-E6D1-4E8D-BE4C-2C0BA81914A7@isipp.com>




> On Wed, Nov 6, 2013 at 1:30 PM, Landon <landonstewart at gmail.com> wrote:
>> How much trouble does your abuse department go to in order to obfuscate
>> headers when providing evidence of spamming activity regardless of if it?s
>> intentional/professional spammer activity or some kind of malware infection
>> allowing a third party to spam.  Especially for the pro spammers, we don?t
>> want them list washing anything or worse yet becoming privy to spamtrap
>> data if the reporting party wasn?t smart enough to obfuscate their own data
>> before sending in the report.
> 
> Howdy,
> 
> It depends on the exact situation, but the general-purpose answer is:
> none. zero. zip.
> 
> The customer usually can't act on your information unless he can line
> it up with an entry in his own logs. He needs lots of details in the
> headers to figure out which computer or which of his users the message
> came from. And he needs that information to determine whether the
> message really came from his system -- headers get forged, you know.

Because this is an issue inherent primarily with bulk mail, we remove all identifying information *except* the unsub link, which *should* have a unique identifying token embedded within, from which the sender *should* be able to determine the complainant's email address.  And, if there is no such link, we use that as an opportunity to educate them as to *why* they need to include such a link (mind you, in order to be accredited with us the sender has to have already demonstrated that they comply with including an unsub link, but because many of our accreditation customers are ESPs, their customers may sometimes not be modelling 100% of best practices).

Regardless of unsub link, or anything else, if we get a spam complaint against one of our customers, we hold their feet to the fire, and require them to explain exactly how the particular list was built, how the address was acquired, etc..  Failure to do so can (and usually does) result in termination of their accreditation - in the case of an ESP, they have to take corrective measures against their spamming customer or the ESP will lose their accreditation.

Anne

Anne P. Mitchell, Esq.
Author: Section 6 of the CAN-SPAM Act of 2003
CEO/President
Institute for Social Internet Public Policy
http://www.ISIPP.com 
Member, Cal. Bar Cyberspace Law Committee

How do you get to the inbox instead of the spam filter?  SuretyMail!
Helping businesses keep their email out of the junk folder since 1998
http://www.isipp.com/SuretyMail




From marka at isc.org  Wed Nov  6 22:29:03 2013
From: marka at isc.org (Mark Andrews)
Date: Thu, 07 Nov 2013 09:29:03 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Wed, 06 Nov 2013 09:34:56 -0500."
 <5964ADA4-8FCF-4FCE-9E64-7474CCAE57F2@consultant.com>
References: <10229F86C86EB444898E629583FD4171EAA20EBF@PACDCEXMB06.cable.comcast.com>
 <5964ADA4-8FCF-4FCE-9E64-7474CCAE57F2@consultant.com>
Message-ID: <20131106222903.53B4799F8D3@rock.dv.isc.org>


In message <5964ADA4-8FCF-4FCE-9E64-7474CCAE57F2 at consultant.com>, Cutler James R writes:
> Dynamic DNS providers will undoubtably endeavor to make money from AAAA
> and SRV entries for publicly-reachable services in SOHO and home
> networks. Dynamic DNS providers are normally not delegated authority to
> provide PTR records for ISP managed addresses, making provision of
> complementary AAAA and PTR records highly unlikely.
>
> Because of the cost of scaling and delegation issues I agree with Jason
> and see no compelling business case for rDNS services for SOHO or
> residential users.

Did you BOTHER TO READ the draft before commenting as the comments
imply that you haven't.  Nothing in the draft is more difficult
than is what is already being done inside enterprises networks today
every single minute of the day.

Enterprise DHCP servers construct DNS PTR records and add them to
the DNS using TSIG signed UPDATE requests.  They do it at one per
machine.

This is DHCP servers constucting a DNS KEY record and adding it to
the DNS using TSIG signed UPDATE requests.  The amount is ONE per
customer.  ISP's already support a PTR record per customer so your
scale arguement is blown out of the water.  This is draft addresses
the delegation issue by automating it so that any CPE device from
any manufacture can perform the delegation without humans being
involved.

Mark

> It's dead,
> 	Jim
>
> James R. Cutler
> james.cutler at consultant.com

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


From bill at herrin.us  Wed Nov  6 22:40:49 2013
From: bill at herrin.us (William Herrin)
Date: Wed, 6 Nov 2013 17:40:49 -0500
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <F7D4C3BC-E6D1-4E8D-BE4C-2C0BA81914A7@isipp.com>
References: <mailman.1274.1383775233.40664.nanog@nanog.org>
 <F7D4C3BC-E6D1-4E8D-BE4C-2C0BA81914A7@isipp.com>
Message-ID: <CAP-guGVfTF_-qg9VgmwqjzhXx7W4kxmXc=S-Zag7jM6zLMqUvQ@mail.gmail.com>

On Wed, Nov 6, 2013 at 5:16 PM, Anne P. Mitchell, Esq.
<amitchell at isipp.com> wrote:
> Because this is an issue inherent primarily with bulk mail,
> we remove all identifying information *except* the unsub link,
> which *should* have a unique identifying token embedded
> within, from which the sender *should* be able to determine
> the complainant's email address.

Hi Anne,

Judging from Landon's web page a vanishingly small percentage of his
customers are in the opt-in mailing list business. He's in the generic
hosting business, so aside from the abusers his customers will tend to
be heavy on single-recipient administrative emails rather than mailing
lists.

If you send him a complaint scrubbed in the manner you describe, he
won't have enough information to act. You'd basically be wasting both
his time and yours.


> Failure to do so can (and usually does)
> result in termination of their accreditation

Accreditation of what?

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From amitchell at isipp.com  Wed Nov  6 22:46:52 2013
From: amitchell at isipp.com (Anne P. Mitchell, Esq.)
Date: Wed, 6 Nov 2013 15:46:52 -0700
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CAP-guGVfTF_-qg9VgmwqjzhXx7W4kxmXc=S-Zag7jM6zLMqUvQ@mail.gmail.com>
References: <mailman.1274.1383775233.40664.nanog@nanog.org>
 <F7D4C3BC-E6D1-4E8D-BE4C-2C0BA81914A7@isipp.com>
 <CAP-guGVfTF_-qg9VgmwqjzhXx7W4kxmXc=S-Zag7jM6zLMqUvQ@mail.gmail.com>
Message-ID: <BECC684D-840A-4271-BF96-701151D365A2@isipp.com>



> so aside from the abusers his customers will tend to
> be heavy on single-recipient administrative emails rather than mailing
> lists.

Then, if they are truly one-to-one administrative emails, that's rather odd if they are generating a disproportionate number of spam complaints, dontcha think?  Unless they are inserting too much marketing into to them (always dicey).

>> Failure to do so can (and usually does)
>> result in termination of their accreditation
> 
> Accreditation of what?

I'll respond more fully to this offlist, as it's OT, but the short answer is that we accredit email senders who are adhering to best practices (not unlike ReturnPath, only we're the other white meat).

Anne

Anne P. Mitchell, Esq.
Author: Section 6 of the CAN-SPAM Act of 2003
CEO/President
Institute for Social Internet Public Policy
http://www.ISIPP.com 
Member, Cal. Bar Cyberspace Law Committee

How do you get to the inbox instead of the spam filter?  SuretyMail!
Helping businesses keep their email out of the junk folder since 1998
http://www.isipp.com/SuretyMail



From JMcKenna at intelletrace.com  Wed Nov  6 22:51:08 2013
From: JMcKenna at intelletrace.com (J.J. Mc Kenna)
Date: Wed, 6 Nov 2013 22:51:08 +0000
Subject: Level3 and AT&T Latency
In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC05BFFA77A@USIDCWVEMBX10.corp.global.level3.com>
References: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
 <BBE50A62287C6C45AEDD6879E14F22CC511AE472@MrMAILp02.MRODD.MRMLS>
 <CAGbD49rAhh8b+m6zUaGpFV8-ufbmXoujoB7heFTA=L+HrVPtPA@mail.gmail.com>
 <5279E7A2.5080809@forthnet.gr>,
 <970945E55BFD8C4EA4CAD74B647A9DC05BFFA77A@USIDCWVEMBX10.corp.global.level3.com>
Message-ID: <7b28f1c044c343118dd37b5113e0175f@CO1PR07MB142.namprd07.prod.outlook.com>

Comcast to XO due to Comcast's TATA peering issue.

Ongoing.

J.J. 

________________________________________
From: Siegel, David <David.Siegel at Level3.com>
Sent: Wednesday, November 06, 2013 7:10 AM
To: Tassos Chatzithomaoglou; nanog at nanog.org
Subject: [GRAYMAIL] RE: Level3 and AT&T Latency

As a matter of pure competitive intelligence gathering (i.e. I do not mean this as a rhetorical question), which providers list peering issues on their portal?  Particularly when they might be a bit more of an ongoing nature vs. a concrete outage?


Dave


-----Original Message-----
From: Tassos Chatzithomaoglou [mailto:achatz at forthnet.gr]
Sent: Tuesday, November 05, 2013 11:54 PM
To: nanog at nanog.org
Subject: Re: Level3 and AT&T Latency

Unfortunately, many issues don't appear (deliberately?) as network events on their portal.

--
Tassos

Jason Baugher wrote on 6/11/2013 06:46:
> For what it's worth, Level3 finally told us they had a peering issue
> with AT&T. They ended up re-routing traffic for the time being until
> they identify the issue.
>
> Of course, for some reason a peering issue doesn't warrant a Network
> Event on their portal...
>
>
> On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist <David at crmls.org> wrote:
>
>> I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today.
>>
>> They just got it spliced back up.  Not sure if it is related to your
>> latency.
>>
>> David
>>
>> -----Original Message-----
>> From: Eric Williams [mailto:ewilliams at connectria.com]
>> Sent: Tuesday, November 05, 2013 11:49 AM
>> To: nanog at nanog.org
>> Subject: Level3 and AT&T Latency
>>
>> Is anybody else seeing or having major latency between Level 3 and
>> AT&T today?  We are multi-homed with Level 3 being one of our ISP's
>> and had to divert traffic after seeing these issues.
>>
>> http://www.internetpulse.net/
>>
>> Eric
>>
>>
>>





From job.snijders at hibernianetworks.com  Wed Nov  6 23:08:53 2013
From: job.snijders at hibernianetworks.com (Job Snijders)
Date: Thu, 7 Nov 2013 00:08:53 +0100
Subject: Level3 and AT&T Latency
In-Reply-To: <7b28f1c044c343118dd37b5113e0175f@CO1PR07MB142.namprd07.prod.outlook.com>
References: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
 <BBE50A62287C6C45AEDD6879E14F22CC511AE472@MrMAILp02.MRODD.MRMLS>
 <CAGbD49rAhh8b+m6zUaGpFV8-ufbmXoujoB7heFTA=L+HrVPtPA@mail.gmail.com>
 <5279E7A2.5080809@forthnet.gr>
 <970945E55BFD8C4EA4CAD74B647A9DC05BFFA77A@USIDCWVEMBX10.corp.global.level3.com>
 <7b28f1c044c343118dd37b5113e0175f@CO1PR07MB142.namprd07.prod.outlook.com>
Message-ID: <20131106230853.GB62936@Eleanor.local>

On Wed, Nov 06, 2013 at 10:51:08PM +0000, J.J. Mc Kenna wrote:
> Comcast to XO due to Comcast's TATA peering issue.
> 
> Ongoing.

I'd love to see verifiable public data to back up that claim. 

Kind regards,

Job

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 873 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131107/c108f60c/attachment.bin>

From mysidia at gmail.com  Thu Nov  7 00:11:27 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 6 Nov 2013 18:11:27 -0600
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
References: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
Message-ID: <CAAAwwbVOFxx26uSFBDF6Ju1LvtiioxBM4S_H0_9rX0usps=k_Q@mail.gmail.com>

On Wed, Nov 6, 2013 at 12:30 PM, Landon <landonstewart at gmail.com> wrote:

> Hello,
>
 How much trouble does your abuse department go to in order to obfuscate

> headers when providing evidence of spamming activity regardless of if it?s
> intentional/professional spammer activity or some kind of malware infection
> allowing a third party to spam.
>

I suggest using separate spam traps for reporting,  from spam traps used to
develop filters and blacklists, seeded/published  at similar places.

Don't report spam hitting secret spamtraps;  just use what is received at
secret spam traps to develop the spam corpus, blacklists, or filtering
rules.



There are exceptions,  but  when reporting spam:  the recipient needs
actionable information.     Not just  someone claiming that there is spam
from them.  If they are the upstream IP network abuse contact
or operator of a large mail server, they should see who it came from,  who
it went to,   the timestamps, message ids, and full headers.

The stuff you could remove to make "list washing"  hard or disguise a spam
trap,  is the same stuff  the receiver of your report needs, to efficiently
and effectively help identify their outbreak,  and put a stop to the spam,
   so you're also making  it hard
for legitimate contacts   to   find the appropriate log entry, and match
the e-mail message to the account it came from.


--
-JH

From alif.terranson at gmail.com  Thu Nov  7 00:27:35 2013
From: alif.terranson at gmail.com (Nonaht Leyte)
Date: Wed, 6 Nov 2013 18:27:35 -0600
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CAP-guGVfTF_-qg9VgmwqjzhXx7W4kxmXc=S-Zag7jM6zLMqUvQ@mail.gmail.com>
References: <mailman.1274.1383775233.40664.nanog@nanog.org>
 <F7D4C3BC-E6D1-4E8D-BE4C-2C0BA81914A7@isipp.com>
 <CAP-guGVfTF_-qg9VgmwqjzhXx7W4kxmXc=S-Zag7jM6zLMqUvQ@mail.gmail.com>
Message-ID: <CANF7DYeukmo5Mu6fNr20f1BmoEV2y4+BF0fnPt5SNTrMqMJdXg@mail.gmail.com>

> If you send him a complaint scrubbed in the manner you describe, he
> won't have enough information to act. You'd basically be wasting both
> his time and yours.

As many here know, I spent 4 years on the receiving end of the
abuse at savvisbox: when I was hired it was for multiple roles, but the
abuse at was a primary.  Savvis had a significant spam problem when I
arrived, and
until just a few months before I left, had literally none.

First of all, *every* abuse email should be seriously investigated,
regardless of header obfuscation. Secondly, header obfuscation is NOT a
waste of time for abuse@ - in fact, it is only marginally less useful than
a "fully loaded" complaint. The reason is that even the smallest (or,
conversely, the most expertly organized) spammer will leave a complaint
trail.  The complaints grow in importance as they grow in number: ten
complaints in the morning abuse email tells me that there is a serious
problem with the sender, even if every single header and other identifying
information is removed from the complaints.  Ten complaints may not
indicate malice (although it usually does), but it does tell abuse@ to
start their resolution clock.

Any abuse department which outright rejects (or claims they are unable to
process) an obfuscated ("munged") complaint is not to be trusted - period.
The abuse department that wont respond to munging is deliberately closing
their eyes to abuse on their network.  Any abuse@ that fails to immediately
act on reports of third-party beneficiaries (for example, drop boxes or
ordering websites) on their network is doing the same thing.

As a complainant, rather than the abuse@ recipient, I will always scrub my
reports *thoroughly*, by removing the significant digits of time stamps,
any unique identifiers I can find (from message-ID to unsubscribe links),
and anything else I think can possibly be used to listwash.  The only
exception to this is if I am reporting to someone I know and explicitly
trust (and there are damn few of those left).

As the abuse@ guy, I would strongly encourage scrubbed reports, even
reports which prove nothing other than an email went out that was unwanted
(as opposed to unsolicited - it's not uncommon for people to make "spam
complaints" rather than unsubscribe from mailings they legitimately
subscribed to).  There are a multitude of internal [& proprietary] tools at
most ISPs that can lead to the appropriate determination as to what is or
isn't spamming, but for the tools to be used, there needs to be a starting
complaint(s).

//Alif




On Wed, Nov 6, 2013 at 4:40 PM, William Herrin <bill at herrin.us> wrote:

> On Wed, Nov 6, 2013 at 5:16 PM, Anne P. Mitchell, Esq.
> <amitchell at isipp.com> wrote:
> > Because this is an issue inherent primarily with bulk mail,
> > we remove all identifying information *except* the unsub link,
> > which *should* have a unique identifying token embedded
> > within, from which the sender *should* be able to determine
> > the complainant's email address.
>
> Hi Anne,
>
> Judging from Landon's web page a vanishingly small percentage of his
> customers are in the opt-in mailing list business. He's in the generic
> hosting business, so aside from the abusers his customers will tend to
> be heavy on single-recipient administrative emails rather than mailing
> lists.
>
> If you send him a complaint scrubbed in the manner you describe, he
> won't have enough information to act. You'd basically be wasting both
> his time and yours.
>
>
> > Failure to do so can (and usually does)
> > result in termination of their accreditation
>
> Accreditation of what?
>
> Regards,
> Bill Herrin
>
>
>
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>
>

From jlewis at lewis.org  Thu Nov  7 00:31:54 2013
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 6 Nov 2013 19:31:54 -0500 (EST)
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
References: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.1311061927280.17328@soloth.lewis.org>

On Wed, 6 Nov 2013, Landon wrote:

> Hello,
>
> We (iWeb AS32613) are currently making great strides in getting out from
> under the volume of reports received and getting on top of things.
>
> How much trouble does your abuse department go to in order to obfuscate
> headers when providing evidence of spamming activity regardless of if its
> intentional/professional spammer activity or some kind of malware infection
> allowing a third party to spam.  Especially for the pro spammers, we dont
> want them list washing anything or worse yet becoming privy to spamtrap
> data if the reporting party wasnt smart enough to obfuscate their own data
> before sending in the report.

If you know you have pro spammers on your network, the question isn't how 
much to obfuscate spam complaints you receive...it's why haven't you 
terminated the customer(s)?

As for the rest, if the reporter wants obfuscation, it's on them to do it.

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


From mysidia at gmail.com  Thu Nov  7 01:02:00 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 6 Nov 2013 19:02:00 -0600
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CANF7DYeukmo5Mu6fNr20f1BmoEV2y4+BF0fnPt5SNTrMqMJdXg@mail.gmail.com>
References: <mailman.1274.1383775233.40664.nanog@nanog.org>
 <F7D4C3BC-E6D1-4E8D-BE4C-2C0BA81914A7@isipp.com>
 <CAP-guGVfTF_-qg9VgmwqjzhXx7W4kxmXc=S-Zag7jM6zLMqUvQ@mail.gmail.com>
 <CANF7DYeukmo5Mu6fNr20f1BmoEV2y4+BF0fnPt5SNTrMqMJdXg@mail.gmail.com>
Message-ID: <CAAAwwbV8Q3t-qM0sLm0UhteobZ1M97BGdqj--LYFqdFY7aYOPA@mail.gmail.com>

On Wed, Nov 6, 2013 at 6:27 PM, Nonaht Leyte <alif.terranson at gmail.com>wrote:

Any abuse department which outright rejects (or claims they are unable to
> process) an obfuscated ("munged") complaint is not to be trusted - period.
>

This is very credible from someone admitting to scrubbing reports, of
information required by some abuse teams to appropriately process
complaints,  *NOT*.  You say scrub....  Many would say:  munging  evidence,
 so that it  is no longer admissible,  or usable as supporting
documentation to suspend or terminate a subscriber's service.

There are abuse departments that would ignore such reports, or reply,
requesting information before proceeding, and they have that right;
especially,   if  the scrubbed reports  don't offer  sufficient evidence,
for their  particular investigation workflow to function.



> As a complainant, rather than the abuse@ recipient, I will always scrub my
> reports *thoroughly*, by removing the significant digits of time stamps,
> any unique identifiers I can find (from message-ID to unsubscribe links),
>



regardless of header obfuscation. Secondly, header obfuscation is NOT a
> waste of time for abuse@ - in fact, it is only marginally less useful than
> a "fully loaded" complaint. The reason is that even the smallest (or,


This is an assumption, that is only true in some cases.


> conversely, the most expertly organized) spammer will leave a complaint
> trail.  The complaints grow in importance as they grow in number: ten
>

Often the spammer will not leave a complaint trail;  they may very well
have sent 1000 messages,  that are logged with various different From:
addresses.

However,  non-spammers will also often leave a "complaint trail";   to give
an example: very often, non-spammers will even forward  their own mail to
another mailbox provider,  e.g. Yahoo/AOL,   and report duly forwarded spam
that arrives in their forwarding destination inbox,  as spam originating
from the forwarding provider.

Without the recipient address; the provider doing the mail forwarding has
no idea if it is the forwarded mail,  or  ordinarily sent mail  that is
being filed as spam.


--
-JH

From mohta at necom830.hpcl.titech.ac.jp  Thu Nov  7 01:37:31 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 07 Nov 2013 10:37:31 +0900
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <4230.1383753324@turing-police.cc.vt.edu>
References: <17761383158810@web2j.yandex.ru>
 <83fdcc19e3a16ef9d7b527918606b4e3@explanoit.com>
 <CAL2Ut99z3YBB6i559zeWPY7=XXBPYaKN+MrqERP+KJHfci5u8g@mail.gmail.com>
 <527432D6.10903@necom830.hpcl.titech.ac.jp>
 <CAK__KzuE_j-x50m2J88p9RQDs8OJOBq-h3SM_a57-VAGqviQBg@mail.gmail.com>
 <527463E1.1080201@necom830.hpcl.titech.ac.jp>
 <254808.1383520306@turing-police.cc.vt.edu>
 <5276E6F0.60204@necom830.hpcl.titech.ac.jp>
 <260897.1383527095@turing-police.cc.vt.edu>
 <5279842E.2080405@necom830.hpcl.titech.ac.jp>
 <4230.1383753324@turing-police.cc.vt.edu>
Message-ID: <527AEEDB.1010605@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

> You still haven't explained how "the memories of those who are at the table"
> help, when the NSA plant has very good reasons to say they're not an NSA
> plant, and you haven't explained how you can show they *are* a plant.

That is a problem between NSA, which recommended a person, and the
person recommended by NSA.

						Masataka Ohta



From bill at herrin.us  Thu Nov  7 02:26:22 2013
From: bill at herrin.us (William Herrin)
Date: Wed, 6 Nov 2013 21:26:22 -0500
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <BECC684D-840A-4271-BF96-701151D365A2@isipp.com>
References: <mailman.1274.1383775233.40664.nanog@nanog.org>
 <F7D4C3BC-E6D1-4E8D-BE4C-2C0BA81914A7@isipp.com>
 <CAP-guGVfTF_-qg9VgmwqjzhXx7W4kxmXc=S-Zag7jM6zLMqUvQ@mail.gmail.com>
 <BECC684D-840A-4271-BF96-701151D365A2@isipp.com>
Message-ID: <CAP-guGXeV99idK6C9Bwk1k-jGpovzKZen=v4eeBbG4z2TTm54w@mail.gmail.com>

On Wed, Nov 6, 2013 at 5:46 PM, Anne P. Mitchell, Esq.
<amitchell at isipp.com> wrote:
>> so aside from the abusers his customers will tend to
>> be heavy on single-recipient administrative emails rather than mailing
>> lists.
>
> Then, if they are truly one-to-one administrative emails, that's
> rather odd if they are generating a disproportionate number of
> spam complaints, dontcha think?  Unless they are inserting too
> much marketing into to them (always dicey).

Hi Anne,

In any given above-board hosting operation there are a whole lot of
things going on:

There's the small ad-hoc lists where an address is typoed and the mail
meant for Uncle George now goes to a random stranger.

There's the emails to formerly dead addresses now resurrected by new owners.

There's the folks who signed up for something and decided to
unsubscribe by reporting it as spam.

There the folks playing pranks on a friend by putting his address in a
bunch of "please contact me" web pages, causing the target to be
one-on-one solicited by a bunch of individual salesmen.

There are the server owners whose security was breached and their
happy web app is now being used to relay lots of spam.

And there's the spammer owned servers spewing out spam.

In each of these situations save the final one, obfuscating
information in the reported spam email only serves to make it
difficult or impossible to identify and stop the problem.

If you start with the assumption that the origin is a spammer until
proven otherwise it becomes a self-fulfilling prophecy -- because when
you report the obfuscated message, they can't track it down and fix
it!

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bill at herrin.us  Thu Nov  7 02:40:57 2013
From: bill at herrin.us (William Herrin)
Date: Wed, 6 Nov 2013 21:40:57 -0500
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CANF7DYeukmo5Mu6fNr20f1BmoEV2y4+BF0fnPt5SNTrMqMJdXg@mail.gmail.com>
References: <mailman.1274.1383775233.40664.nanog@nanog.org>
 <F7D4C3BC-E6D1-4E8D-BE4C-2C0BA81914A7@isipp.com>
 <CAP-guGVfTF_-qg9VgmwqjzhXx7W4kxmXc=S-Zag7jM6zLMqUvQ@mail.gmail.com>
 <CANF7DYeukmo5Mu6fNr20f1BmoEV2y4+BF0fnPt5SNTrMqMJdXg@mail.gmail.com>
Message-ID: <CAP-guGW0RLu69VteULWWWJSTb6ctDy2UQDGyX9aizR9nLdafbw@mail.gmail.com>

On Wed, Nov 6, 2013 at 7:27 PM, Nonaht Leyte <alif.terranson at gmail.com> wrote:
> As many here know, I spent 4 years on the receiving end of the
> abuse at savvisbox: when I was hired it was for multiple roles, but the
> abuse at was a primary.  Savvis had a significant spam problem when I
> arrived, and
> until just a few months before I left, had literally none.

Howdy,

Out of curiosity, what changed a few months before you left?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From crogers at inerail.net  Thu Nov  7 03:54:13 2013
From: crogers at inerail.net (Chris Rogers)
Date: Wed, 6 Nov 2013 22:54:13 -0500
Subject: Level3 and AT&T Latency
In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC05BFFA77A@USIDCWVEMBX10.corp.global.level3.com>
References: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
 <BBE50A62287C6C45AEDD6879E14F22CC511AE472@MrMAILp02.MRODD.MRMLS>
 <CAGbD49rAhh8b+m6zUaGpFV8-ufbmXoujoB7heFTA=L+HrVPtPA@mail.gmail.com>
 <5279E7A2.5080809@forthnet.gr>
 <970945E55BFD8C4EA4CAD74B647A9DC05BFFA77A@USIDCWVEMBX10.corp.global.level3.com>
Message-ID: <CAAzL0oGn9fwUf+OZ851C7w6PMu8=MNkNTNrzqERYa5D-CKvcNw@mail.gmail.com>

AS13030 -> http://www.init7.net/en/status/

-Chris

On Wed, Nov 6, 2013 at 10:10 AM, Siegel, David <David.Siegel at level3.com>wrote:

> As a matter of pure competitive intelligence gathering (i.e. I do not mean
> this as a rhetorical question), which providers list peering issues on
> their portal?  Particularly when they might be a bit more of an ongoing
> nature vs. a concrete outage?
>
>
> Dave
>
>
> -----Original Message-----
> From: Tassos Chatzithomaoglou [mailto:achatz at forthnet.gr]
> Sent: Tuesday, November 05, 2013 11:54 PM
> To: nanog at nanog.org
> Subject: Re: Level3 and AT&T Latency
>
> Unfortunately, many issues don't appear (deliberately?) as network events
> on their portal.
>
> --
> Tassos
>
> Jason Baugher wrote on 6/11/2013 06:46:
> > For what it's worth, Level3 finally told us they had a peering issue
> > with AT&T. They ended up re-routing traffic for the time being until
> > they identify the issue.
> >
> > Of course, for some reason a peering issue doesn't warrant a Network
> > Event on their portal...
> >
> >
> > On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist <David at crmls.org> wrote:
> >
> >> I know we have been dealing with a Level 3, OC192 Fiber cut in PHX
> today.
> >>
> >> They just got it spliced back up.  Not sure if it is related to your
> >> latency.
> >>
> >> David
> >>
> >> -----Original Message-----
> >> From: Eric Williams [mailto:ewilliams at connectria.com]
> >> Sent: Tuesday, November 05, 2013 11:49 AM
> >> To: nanog at nanog.org
> >> Subject: Level3 and AT&T Latency
> >>
> >> Is anybody else seeing or having major latency between Level 3 and
> >> AT&T today?  We are multi-homed with Level 3 being one of our ISP's
> >> and had to divert traffic after seeing these issues.
> >>
> >> http://www.internetpulse.net/
> >>
> >> Eric
> >>
> >>
> >>
>
>
>

From mshaw at fairpoint.com  Thu Nov  7 14:05:07 2013
From: mshaw at fairpoint.com (Shaw, Matthew)
Date: Thu, 7 Nov 2013 14:05:07 +0000
Subject: M40e "AER" and MG9k's
Message-ID: <457F9455036417428963A59E3B388741202B50A4@0NH1C2P10.fairpoint.com>

Good morning all,

This is a bit of a longshot, but by any chance is there anyone watching this list who is currently or was formerly with VZ that's familiar with a configuration involving M40e's aggregating a number of customer facing MG9k's over ATM?

We're having a heck of a time with them if you could reach out off list with any background or experiences with them from elsewhere I'd really appreciate it.

Matt

_______________________________________________________________________


This e-mail message and its attachments are for the sole use of the intended recipients.  They may contain confidential information, legally privileged information or other information subject to legal restrictions.  If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media.

From David.Siegel at Level3.com  Thu Nov  7 15:00:24 2013
From: David.Siegel at Level3.com (Siegel, David)
Date: Thu, 7 Nov 2013 15:00:24 +0000
Subject: Level3 and AT&T Latency
In-Reply-To: <7b28f1c044c343118dd37b5113e0175f@CO1PR07MB142.namprd07.prod.outlook.com>
References: <OF029DB047.1AD3C5C7-ON86257C1A.006CB048-86257C1A.006CD0DA@home.connectria.com>
 <BBE50A62287C6C45AEDD6879E14F22CC511AE472@MrMAILp02.MRODD.MRMLS>
 <CAGbD49rAhh8b+m6zUaGpFV8-ufbmXoujoB7heFTA=L+HrVPtPA@mail.gmail.com>
 <5279E7A2.5080809@forthnet.gr>,
 <970945E55BFD8C4EA4CAD74B647A9DC05BFFA77A@USIDCWVEMBX10.corp.global.level3.com>
 <7b28f1c044c343118dd37b5113e0175f@CO1PR07MB142.namprd07.prod.outlook.com>
Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC05BFFEDED@USIDCWVEMBX10.corp.global.level3.com>

And that is listed on which providers portals, XO's, Comcast's or Tata's?

-----Original Message-----
From: J.J. Mc Kenna [mailto:JMcKenna at intelletrace.com] 
Sent: Wednesday, November 06, 2013 3:51 PM
To: nanog at nanog.org
Subject: RE: Level3 and AT&T Latency

Comcast to XO due to Comcast's TATA peering issue.

Ongoing.

J.J. 

________________________________________
From: Siegel, David <David.Siegel at Level3.com>
Sent: Wednesday, November 06, 2013 7:10 AM
To: Tassos Chatzithomaoglou; nanog at nanog.org
Subject: [GRAYMAIL] RE: Level3 and AT&T Latency

As a matter of pure competitive intelligence gathering (i.e. I do not mean this as a rhetorical question), which providers list peering issues on their portal?  Particularly when they might be a bit more of an ongoing nature vs. a concrete outage?


Dave


-----Original Message-----
From: Tassos Chatzithomaoglou [mailto:achatz at forthnet.gr]
Sent: Tuesday, November 05, 2013 11:54 PM
To: nanog at nanog.org
Subject: Re: Level3 and AT&T Latency

Unfortunately, many issues don't appear (deliberately?) as network events on their portal.

--
Tassos

Jason Baugher wrote on 6/11/2013 06:46:
> For what it's worth, Level3 finally told us they had a peering issue 
> with AT&T. They ended up re-routing traffic for the time being until 
> they identify the issue.
>
> Of course, for some reason a peering issue doesn't warrant a Network 
> Event on their portal...
>
>
> On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist <David at crmls.org> wrote:
>
>> I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today.
>>
>> They just got it spliced back up.  Not sure if it is related to your 
>> latency.
>>
>> David
>>
>> -----Original Message-----
>> From: Eric Williams [mailto:ewilliams at connectria.com]
>> Sent: Tuesday, November 05, 2013 11:49 AM
>> To: nanog at nanog.org
>> Subject: Level3 and AT&T Latency
>>
>> Is anybody else seeing or having major latency between Level 3 and 
>> AT&T today?  We are multi-homed with Level 3 being one of our ISP's 
>> and had to divert traffic after seeing these issues.
>>
>> http://www.internetpulse.net/
>>
>> Eric
>>
>>
>>






From me at anuragbhatia.com  Thu Nov  7 15:54:16 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 7 Nov 2013 16:54:16 +0100
Subject: www.akamai.net giving NXDOMAIN
Message-ID: <CAJ0+aXZhofNgbwh3z_Wz3Qu-KOqBwXou3G0H8Ak04GahCtXYsg@mail.gmail.com>

Anurags-MacBook-Pro:~ anurag$ dig @8.8.8.8 www.akamai.net.

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.akamai.net.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: *NXDOMAIN*, id: 2274
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.akamai.net. IN A

;; AUTHORITY SECTION:
akamai.net. 167 IN SOA internal.akamaitech.net. hostmaster.akamai.com.
1383839413 90000 90000 90000 180

;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov  7 16:50:27 2013
;; MSG SIZE  rcvd: 109

Anurags-MacBook-Pro:~ anurag$


That's weird!

Missing "akamai.net" entry from the authoritative DNS nodes? I am in
Austria right now and so likely my nearby node giving bad replies.


-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From me at anuragbhatia.com  Thu Nov  7 15:57:15 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 7 Nov 2013 16:57:15 +0100
Subject: www.akamai.net giving NXDOMAIN
In-Reply-To: <CAJ0+aXZhofNgbwh3z_Wz3Qu-KOqBwXou3G0H8Ak04GahCtXYsg@mail.gmail.com>
References: <CAJ0+aXZhofNgbwh3z_Wz3Qu-KOqBwXou3G0H8Ak04GahCtXYsg@mail.gmail.com>
Message-ID: <CAJ0+aXYqKznhc_DUTgeD1FPTkGGXNG7Z5+G8SqJ60_ErQNcm9w@mail.gmail.com>

OK - seems like www.akamai.NET was working earlier but now they just prefer
using www.akamai.COM and may be removed .net recently.


On Thu, Nov 7, 2013 at 4:54 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Anurags-MacBook-Pro:~ anurag$ dig @8.8.8.8 www.akamai.net.
>
> ; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.akamai.net.
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: *NXDOMAIN*, id: 2274
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;www.akamai.net. IN A
>
> ;; AUTHORITY SECTION:
> akamai.net. 167 IN SOA internal.akamaitech.net. hostmaster.akamai.com.
> 1383839413 90000 90000 90000 180
>
> ;; Query time: 26 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Thu Nov  7 16:50:27 2013
> ;; MSG SIZE  rcvd: 109
>
> Anurags-MacBook-Pro:~ anurag$
>
>
> That's weird!
>
> Missing "akamai.net" entry from the authoritative DNS nodes? I am in
> Austria right now and so likely my nearby node giving bad replies.
>
>
> --
>
>
> Anurag Bhatia
> anuragbhatia.com
>
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia>
> Skype: anuragbhatia.com
>



-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From anarcat at koumbit.org  Thu Nov  7 16:26:30 2013
From: anarcat at koumbit.org (Antoine =?utf-8?Q?Beaupr=C3=A9?=)
Date: Thu, 07 Nov 2013 11:26:30 -0500
Subject: advice on BGP + CARP setup on FreeBSD
In-Reply-To: <52797630.8020300@foobar.org>
References: <87d2med4rm.fsf@marcos.anarc.at> <52797630.8020300@foobar.org>
Message-ID: <8761s4jhzd.fsf@marcos.anarc.at>

First, my warm thanks to everyone to responded on and off list, an
amazing response that truly speaks for the opennness and incredible
skill of this community.

We are likely to change the setup to make sure the switch fabric sits
behind the edge routers, and thanks to my new understanding of iBGP,
will simply associate different upstream with the different edge routers
and run BGP between them.

The downside of this setup is that if a router falls over, we loose an
uplink, but that's a minor problem considering how it makes the whole
setup much simpler, and completely removes the single point of failure
of the switch. And anyways since the uplinks are directly in the router,
the downtime should be negligible in such a (rare) occurence.

We will keep on experimenting with OpenBGPd, but at the first sign of
trouble we will switch to what seems to be the more widely accepted
alternative in the *BSD world, Bird, which also allows for a clean
transition to GNU/Linux if we ever make the jump.

CARP will come later, but will still be in the picture. Both routers
will be in production at all time, and we'll use CARP to elect the
gateway for the internal network. We prefer CARP to VRRP because it
seems well supported in *BSD world and because VRRP is
patent-encumbered. I am worried, however, of rumours of kernel panics
associated with CARP, but I am confident that the very responsive
FreeBSD community will be able to help with that.

Thanks again for all your feedback, you guys rock.

Cheers,

A.

-- 
A ballot is like a bullet. You don't throw your ballots until you see
a target, and if that target is not within your reach, keep your
ballot in your pocket.
                         - Malcom X
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131107/3357f81a/attachment.bin>

From scott at doc.net.au  Thu Nov  7 17:50:09 2013
From: scott at doc.net.au (Scott Howard)
Date: Thu, 7 Nov 2013 09:50:09 -0800
Subject: www.akamai.net giving NXDOMAIN
In-Reply-To: <CAJ0+aXZhofNgbwh3z_Wz3Qu-KOqBwXou3G0H8Ak04GahCtXYsg@mail.gmail.com>
References: <CAJ0+aXZhofNgbwh3z_Wz3Qu-KOqBwXou3G0H8Ak04GahCtXYsg@mail.gmail.com>
Message-ID: <CACnPsNUeW_FAvCmgCrR3hC=5mTgTi87-dn45+3aRnZBryMYbAQ@mail.gmail.com>

On Thu, Nov 7, 2013 at 7:54 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:

> That's weird!
>
> Missing "akamai.net" entry from the authoritative DNS nodes? I am in
> Austria right now and so likely my nearby node giving bad replies.
>

akamai.net isn't missing from anywhere.  www might be, but other hosts are
working so I suspect this is by design.

$ dig whoami.akamai.net +short
38.104.99.142


  Scott

From rsk at gsp.org  Thu Nov  7 18:43:00 2013
From: rsk at gsp.org (Rich Kulawiec)
Date: Thu, 7 Nov 2013 13:43:00 -0500
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <Pine.LNX.4.61.1311061927280.17328@soloth.lewis.org>
References: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
 <Pine.LNX.4.61.1311061927280.17328@soloth.lewis.org>
Message-ID: <20131107184300.GA24905@gsp.org>

On Wed, Nov 06, 2013 at 07:31:54PM -0500, Jon Lewis wrote:
> If you know you have pro spammers on your network, the question
> isn't how much to obfuscate spam complaints you receive...it's why
> haven't you terminated the customer(s)?

Another question is "why are you relying on third parties to tell you
that abuse is outbound from your operation?  Why don't you already know?"

Alright, two questions.  But my point is that all competent operations
have their own set of diverse spamtraps AND they not only passively
monitor them, but they actively seed them in order to detect spammers.
This not only gives them a chance to pro-actively terminate spammers
before they have the opportunity to abuse third parties, but it also
enables independent, controlled corroboration of reports received --
whether obfuscated or not.  (Anything received at those spamtraps other
than an attempt to confirm a subscription via a proper COI process
is clearly spam or a typo.  The incidence rate of the latter can be
decreased at will with minimal effort.)

---rsk


From ikiris at gmail.com  Thu Nov  7 19:00:40 2013
From: ikiris at gmail.com (Blake Dunlap)
Date: Thu, 7 Nov 2013 13:00:40 -0600
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <20131107184300.GA24905@gsp.org>
References: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
 <Pine.LNX.4.61.1311061927280.17328@soloth.lewis.org>
 <20131107184300.GA24905@gsp.org>
Message-ID: <CAJvB4t=KE4HdfrfJB28LCrOGOsfcdGySSJYKboMzHesyd9MMmg@mail.gmail.com>

Pretty much this. It's your business model to have your email be
deliverable, while it is not my business model that your mail is received.
If I get spam outside of obvious cases of receiver issues, I just block.
I'm not going to bother to jump through hoops to report issues you should
be dealing with yourself. Don't expect others to do your work for you,
otherwise don't be surprised when your deliverability is impacted, instead
of your abuse desk.

-Blake


On Thu, Nov 7, 2013 at 12:43 PM, Rich Kulawiec <rsk at gsp.org> wrote:

> On Wed, Nov 06, 2013 at 07:31:54PM -0500, Jon Lewis wrote:
> > If you know you have pro spammers on your network, the question
> > isn't how much to obfuscate spam complaints you receive...it's why
> > haven't you terminated the customer(s)?
>
> Another question is "why are you relying on third parties to tell you
> that abuse is outbound from your operation?  Why don't you already know?"
>
> Alright, two questions.  But my point is that all competent operations
> have their own set of diverse spamtraps AND they not only passively
> monitor them, but they actively seed them in order to detect spammers.
> This not only gives them a chance to pro-actively terminate spammers
> before they have the opportunity to abuse third parties, but it also
> enables independent, controlled corroboration of reports received --
> whether obfuscated or not.  (Anything received at those spamtraps other
> than an attempt to confirm a subscription via a proper COI process
> is clearly spam or a typo.  The incidence rate of the latter can be
> decreased at will with minimal effort.)
>
> ---rsk
>
>

From bill at herrin.us  Thu Nov  7 19:20:24 2013
From: bill at herrin.us (William Herrin)
Date: Thu, 7 Nov 2013 14:20:24 -0500
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <20131107184300.GA24905@gsp.org>
References: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
 <Pine.LNX.4.61.1311061927280.17328@soloth.lewis.org>
 <20131107184300.GA24905@gsp.org>
Message-ID: <CAP-guGXTP9KhXbiZhnRe1WwMyT9C2dRcWyGCc=kKL5DOKHKj0Q@mail.gmail.com>

On Thu, Nov 7, 2013 at 1:43 PM, Rich Kulawiec <rsk at gsp.org> wrote:
> On Wed, Nov 06, 2013 at 07:31:54PM -0500, Jon Lewis wrote:
>> If you know you have pro spammers on your network, the question
>> isn't how much to obfuscate spam complaints you receive...it's why
>> haven't you terminated the customer(s)?
>
> Another question is "why are you relying on third parties to tell you
> that abuse is outbound from your operation?  Why don't you already know?"

Because the folks watching packets from Internet customers do have
three letters but the three letters are NSA not ISP.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From nick at foobar.org  Thu Nov  7 19:34:13 2013
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 07 Nov 2013 19:34:13 +0000
Subject: advice on BGP + CARP setup on FreeBSD
In-Reply-To: <8761s4jhzd.fsf@marcos.anarc.at>
References: <87d2med4rm.fsf@marcos.anarc.at> <52797630.8020300@foobar.org>
 <8761s4jhzd.fsf@marcos.anarc.at>
Message-ID: <527BEB35.4070004@foobar.org>

On 07/11/2013 16:26, Antoine Beaupr? wrote:
> and because VRRP is patent-encumbered

CARP is probably patent encumbered too.  I don't understand why people
claim that using CARP as a default gateway isn't patent encumbered because
it uses pretty much exactly the same process that the VRRP patent covers.
To be honest, I wouldn't get too upset about it as the patent expires early
next year, so this is not important.

Also bear in mind that if you decide to migrate to VRRP later on and for
some reason use the same VRRP group as CARP vhid, you will trash your
network connectivity.  The OpenBSD people specifically designed CARP so
that it would break VRRP on the same network if they use the same
parameters, but sadly they refuse to document this.  It's documented
elsewhere on the web though, so bear it in mind if you ever implement CARP
and then move to VRRP.

> I am worried, however, of rumours of kernel panics associated with CARP,
> but I am confident that the very responsive FreeBSD community will be
> able to help with that.

I hope so. There have been some long-standing problems, but hopefully the
work done on fixing carp in freebsd 10 will finally see the end of these
issues.

Nick



From alif.terranson at gmail.com  Thu Nov  7 20:06:13 2013
From: alif.terranson at gmail.com (Nonaht Leyte)
Date: Thu, 7 Nov 2013 14:06:13 -0600
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CAJvB4t=KE4HdfrfJB28LCrOGOsfcdGySSJYKboMzHesyd9MMmg@mail.gmail.com>
References: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
 <Pine.LNX.4.61.1311061927280.17328@soloth.lewis.org>
 <20131107184300.GA24905@gsp.org>
 <CAJvB4t=KE4HdfrfJB28LCrOGOsfcdGySSJYKboMzHesyd9MMmg@mail.gmail.com>
Message-ID: <CANF7DYe3Pedm6QfWv3YWxL8=fRd=aSNdSyBqp3pctFsuP-ehOg@mail.gmail.com>

>> Savvis had a significant spam problem when I
>> arrived, and until just a few months before I left, had literally none.

> Howdy,
>
> Out of curiosity, what changed a few months before you left?

Without retelling the *entire* [very public] story: we acquired another
large carrier with several hundered known spammers paying *incredible*
premiums for their connectivity.  Savvis decided that 2 million $/mo in MRR
was just too good to passs up, and made an effort at hiding behind *my*
reputation (I was supposed to make noise about how hard I was "working on
it" for "as long as possible".  At any point where a particular baddie
became politically "hot" they would "rebrand" [read: rename, re-ip, etc]
and repeat.  I wasn't willing to go along, and took extraordinary steps to
stop it (first arguing the value of [then] good name, and then finally
going public as loudly as possible.


> Another question is "why are you relying on third parties to tell you
> that abuse is outbound from your operation?  Why don't you already know?"

The pro spammers were usually know before they got turned up: there's a
really great [if informal] intelligence network set up for this: I have
turned off [literally] dozens of pro spammers before the contracts made it
to circuit-ordering.  The pros aren't the problem, it's the little spammers
who only send from a few thousand to a few million emails per month.

Having POPs in 148 countries, and 7800 routers to deal with [Svvs actually
exploded OSPF several years before my arrival, moving to hybrid routing
schemes [BGP+ISIS+limited OSPF] makes proactive detection difficult for
these little guys: so email complaints can be extremely valuable.

Several other made excellent points: a few of those points I'm choosing not
to respond to so as not to reveal any hint of trade secrets developed, some
are just argumentative and/or not applicable at scale, or so obvious and
correct that no further mention needs be made (sorry, I won't separate them
out: the systems we put up are still in use AFAIK).

As was pointed out earlier, this topic is at best on the very edge of OT
here, so any further questions can be made off list :-)

//Alif




On Thu, Nov 7, 2013 at 1:00 PM, Blake Dunlap <ikiris at gmail.com> wrote:

> Pretty much this. It's your business model to have your email be
> deliverable, while it is not my business model that your mail is received.
> If I get spam outside of obvious cases of receiver issues, I just block.
> I'm not going to bother to jump through hoops to report issues you should
> be dealing with yourself. Don't expect others to do your work for you,
> otherwise don't be surprised when your deliverability is impacted, instead
> of your abuse desk.
>
> -Blake
>
>
> On Thu, Nov 7, 2013 at 12:43 PM, Rich Kulawiec <rsk at gsp.org> wrote:
>
> > On Wed, Nov 06, 2013 at 07:31:54PM -0500, Jon Lewis wrote:
> > > If you know you have pro spammers on your network, the question
> > > isn't how much to obfuscate spam complaints you receive...it's why
> > > haven't you terminated the customer(s)?
> >
> > Another question is "why are you relying on third parties to tell you
> > that abuse is outbound from your operation?  Why don't you already know?"
> >
> > Alright, two questions.  But my point is that all competent operations
> > have their own set of diverse spamtraps AND they not only passively
> > monitor them, but they actively seed them in order to detect spammers.
> > This not only gives them a chance to pro-actively terminate spammers
> > before they have the opportunity to abuse third parties, but it also
> > enables independent, controlled corroboration of reports received --
> > whether obfuscated or not.  (Anything received at those spamtraps other
> > than an attempt to confirm a subscription via a proper COI process
> > is clearly spam or a typo.  The incidence rate of the latter can be
> > decreased at will with minimal effort.)
> >
> > ---rsk
> >
> >
>

From nick at flhsi.com  Thu Nov  7 20:13:49 2013
From: nick at flhsi.com (Nick Olsen)
Date: Thu, 7 Nov 2013 15:13:49 -0500
Subject: Bright House Networks Voice Contact
Message-ID: <253a752c$8eb1ffc$1ff6a536$@flhsi.com>

Is anyone from the voice side of Bright House Networks Central Florida 
Division around? I seem to be hitting a CNAM cache on their network and was 
hoping to get it dumped. Thanks!

Nick Olsen
Network Operations (855) FLSPEED  x106



From brandon.galbraith at gmail.com  Thu Nov  7 20:48:17 2013
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Thu, 7 Nov 2013 14:48:17 -0600
Subject: Upstream / Handoff UPS?
In-Reply-To: <CE97EA2F.6A7CF%lists@mtin.net>
References: <CAFnKnOd1QzkMASyusgCt4dj=SudsuATy+2ZvV=wFOQ4yG48ZzA@mail.gmail.com>
 <CE97EA2F.6A7CF%lists@mtin.net>
Message-ID: <CADE4tYU_JmpG9DHJkgATeqj6Faw9e0F9Xd7XAqV0cue7Q8vxBQ@mail.gmail.com>

Working with Comcast and their ethernet product, they don't battery
back the on-site gear (fiber/ethernet switch), but I do get a phone
call within minutes of them noticing the switch they provided is down.
They care enough to call me, but battery backup is my/our
responsibility.

Brandon

On Thu, Oct 31, 2013 at 10:07 AM, Justin Wilson <lists at mtin.net> wrote:
>         I have several clients who have cisco Metro Ethernet switches on Fiber
> circuits.  The provider just provided the switch and expects the client to
> deal with the power.  The rational is if the switch is not up it's not our
> fault.
>
>         Justin
>
> --
> Justin Wilson <j2sw at mtin.net>
> MTCNA ? CCNA ? MTCRE ? MTCWE - COMTRAIN
> Aol & Yahoo IM: j2sw
> http://www.mtin.net/blog ? xISP News
> http://www.zigwireless.com ? High Speed Internet Options
> http://www.thebrotherswisp.com ? The Brothers Wisp
>
>
>
>
>
> -----Original Message-----
> From: Kenny Kant <akennykant at gmail.com>
> Date: Thursday, October 31, 2013 1:34 AM
> To: <nanog at nanog.org>
> Subject: Upstream / Handoff UPS?
>
>>We have tons of circuits with various providers.  Often times the demarc /
>>handoff switch from the provider is not running on battery backup.
>> Sometimes if the demarc device is located in the same room as our
>>equipment we mitigate this and plug the device into our backup systems.
>>
>>Am I wrong to think that the demarc from the provider is a sacred thing
>>that should only be touched by said provider.  Thus they should provide
>>their own battery system?  Is it normal for this equipment not to be
>>battery protected?  We are not dealing with any crazy SLA's however I
>>think
>>it would be standard build practice to put UPS's on your gear.  Even if
>>its
>>small handoff switch sitting right next to my switch.
>>
>>:)
>>
>>Kenny
>>
>
>
>


From shortdudey123 at gmail.com  Fri Nov  8 00:58:21 2013
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Thu, 7 Nov 2013 16:58:21 -0800
Subject: Any issues in asia-pac due to typhoon
Message-ID: <CAPiURgXdweG15z=MXtd2oFqYKg5ZNoo3ZiD2X8Vk0OwqOV2PDw@mail.gmail.com>

Hi Everyone,

I am curious to see if anyone has been any issues or outages due to the
typhoon in the area of the Philippines.

Satellite: http://www.pagasa.dost.gov.ph/wb/sat_images/satpic.jpg
http://www.usatoday.com/story/news/world/2013/11/07/philippines-typhoon/3465779/


-Grant

P.S. - Also sent this to outages list earlier

From frnkblk at iname.com  Fri Nov  8 01:41:26 2013
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 7 Nov 2013 19:41:26 -0600
Subject: Bright House Networks Voice Contact
In-Reply-To: <253a752c$8eb1ffc$1ff6a536$@flhsi.com>
References: <253a752c$8eb1ffc$1ff6a536$@flhsi.com>
Message-ID: <003801cedc23$a3db08d0$eb911a70$@iname.com>

Try this:
813-387-3699
or
support at bhnis.com

-----Original Message-----
From: Nick Olsen [mailto:nick at flhsi.com] 
Sent: Thursday, November 07, 2013 2:14 PM
To: nanog at nanog.org
Subject: Bright House Networks Voice Contact

Is anyone from the voice side of Bright House Networks Central Florida 
Division around? I seem to be hitting a CNAM cache on their network and was 
hoping to get it dumped. Thanks!

Nick Olsen
Network Operations (855) FLSPEED  x106






From rsk at gsp.org  Fri Nov  8 12:37:40 2013
From: rsk at gsp.org (Rich Kulawiec)
Date: Fri, 8 Nov 2013 07:37:40 -0500
Subject: Email Server and DNS
In-Reply-To: <CAAAwwbWC4iFg_Lp6rWhfBXjQryg-v4MoghFnE5k=nDOMJVf6BQ@mail.gmail.com>
References: <web-90567@mail.saroza-webb.local> <20131103170859.GA9212@gsp.org>
 <CAAAwwbWC4iFg_Lp6rWhfBXjQryg-v4MoghFnE5k=nDOMJVf6BQ@mail.gmail.com>
Message-ID: <20131108123740.GA19333@gsp.org>

I suggest moving this to mailop, where it arguably belongs.  But I'm
going to follow up on a few points, anyway.

First, I forgot to mention two other highly effective mail system
defense methods: geoblocking and passive OS fingerprinting.

Geoblocking: A mail server for a local construction business in Arizona
is unlikely to require mail from Poland, Peru or Pakistan.  So there's
no reason to go with a default-permit model: use default-deny and
only allow mail from places where legitimate mail might originate.
(In this case, perhaps: the US, Mexico, and Canada.)  Use the ranges
from ipdeny.com.  This will stop an astonishing amount of spam (and
other SMTP-borne abuse) cold.  And it can be done at the MTA or in
the firewall: which is better depends on circumstances.

Obviously this doesn't work for everyone.  Obviously this (like
everything else) runs the risk of false positives -- but it's easy
to mitigate that.  Obviously it does require understanding the
patterns in your mail traffic, but any competent mail system admin
has long since performed detailed statistical analysis and has a
pretty good idea what the characteristics of their incoming mail
stream look like.

Passive OS fingerprinting: regard anything originating from an OS
that fingerprints as Windows as dubious, at best.  Possible actions
vary: graylisting (more precisely, graylisting regardless of previous
traffic) is one good option.  Utilizing this in concert with geoblocking
(above) works beautifully, e.g., "I'm in Arizona and something in Portugal
that fingerprints as Windows is trying to send me SMTP traffic: the
probability approaches unity that this is spam".  When combined with
rDNS information, this becomes a highly efficient mechanism with a FP
rate that's ridiculously low.  (In other words, if that same system
has rDNS that looks like 123-45-67-8.example.com then it either really
is a bot or it's a mail system run by someone with no clue.)

A few short points and one long one in response:

On Sun, Nov 03, 2013 at 12:00:23PM -0600, Jimmy Hess wrote:
> The RFC contains a MUST NOT  in regards to verifying the  HELO name matches.
> So, the HELO can use any hostname ---  as long as the hostname forward
> resolves to something;  it should resolve to the IP address of one of your
> mail servers.    Some mail servers provide service for many domains, and
> have many DNS names that could be placed in a HELO.

All true.  But none of this argues against using the canonical hostname
in the HELO.  It's the simplest, easiest option (and quite often the
one that software will pick by default).

> > SPF is worthless crap: don't bother.  Use a real MTA, e.g., postfix
> >
> 
> I do not believe that is the consensus of the community -- or the working
> groups behind the SPF-related RFCs.

I'm well aware it's not the consensus.  It's my opinion.

Clue #1 that SPF is crap should have been its grandiose self-promoting
announcement ("Spam as a technical problem is solved by SPF").  Clue #2
should have been the observation that -- by far -- the most prolific
early adopters were spammers.  When your enemy latches on to your
new weapon much faster than you do, that should be a tipoff that maybe it's
not what you hope it is.  Clue #3 is available to anyone who deploys a
sufficiently large and diverse set of spamtraps for several years and
analyzes the data that arrives: SPF presence/absence or contents have
no statistically useful anti-spam value in a properly-designed mail
defense architecture.  

Don't believe me?  Okay.  Fine.  Set up a few thousand spamtraps, gather
data for 3-5 years, see for yourself.

So yes, it's standardized; so what?  So is (sort of) DNS forgery, see
http://tools.ietf.org/html/draft-livingood-dns-redirect-03 for example.
That's also crap, it just happens to be well-documented crap.

So: if you feel you must use something, use DKIM, which I think shows
vastly more promise.  Just don't expect it to be a panacea, because
the current miserable state of security at *all* levels undercuts it
badly.  Not DKIM's fault, really, but it does impact its usefulness
in the real world.

> Message quarantines are great;  they are helpful  for mitigating the false
> positives of overly-agressive filters.

This one I'll spend more time on.  Quarantines are a worst practice 
in mail systems engineering.  Here are some assorted reasons why, briefly:

- One of the fundamental principles of mail system defense is that you
should make your mistakes early, consistently, and loudly.  (And you
WILL make mistakes.   Everyone does.)  The point of doing this is that
it enables all concerned, including you, to have a decent chance of
noticing them, figuring out that they're mistakes, and correcting them.
Quarantines hide, defer, and silence your mistakes, making it much more
difficult to run your system properly.  They're a lazy admin's coverup,
not a fix.

- Quarantines present deadlock problems.  Mail from user A to user B
which is quarantined and causes B to eventually send a message to user A
enquiring about the missing missive stands a decent chance of ending up
in B's quarantine.  The end result is that human time (which is a scarce
and expensive commodity) is needlessly wasted figuring out the problem
and then trying to evade it, usually by trying to tapdance a way past
the filters on both sides.  Contrast with a hard, immediate rejection,
which -- coupled with an appropriate resolution mechanism -- facilitates
quick, easy diagnosis and repair.

- Some people use quarantines because they're unduly concerned about
their false positive rate.  But slapping the ill-advised band-aid of a
quarantine on an underlying problem like a high FP rate solves nothing.
It merely obscures the mistake.  The correct solution is to figure out why
the FP rate is high, and fix that, because that's where the problem is.

- Users have spent the past two decades or so conclusively proving, beyond
any possible argument, that they are utterly incapable of distinguishing
spam from non-spam, phish from non-phish.  (Consider carefully: if they
could, en masse and accurately, would we have the scope and scale of the
problem set we currently face?  No.  We would not.)  "Educating users" is
a complete failure as a strategy; see point #5 here:

	The Six Dumbest Ideas in Computer Security
	http://www.ranum.com/security/computer_security/editorials/dumb/

Even personnel who *work in security* can't solve this classification
problem correctly (which is why I said "ask RSA how that's working
out for them").  Your users are no better.  They're probably worse.
So punting the task of correctly classifying incoming mail to them is
reckless and irresponsible.  With precious few and rare exceptions, they
WILL fail.  Freuqently.  And sometimes (again: see RSA) the consequences
of even a single failure can be catastrophic.

More bluntly, allowing users anywhere near the machinery of security,
when they've proven for decades that they're absolutely unqualified to
handle even its simplest aspects, is clearly unprofessional and highly
negligent.  Yes, this is somewhat a fascist, uncompromising, condescending,
etc. attitude.  It's also the only one that's been demonstrated to work in
the real world.  It's a shame, really, but this is not the 'net of 1983.
You can be nice and flexible and accomodating or you can be (modestly)
secure.  Pick one.

- Disposition of quarantined mail is problematic -- unless of course
the intention is to let it accumulate indefinitely, which is a dubious
idea at best.  Eventually, *something* has to be done.  Delivering it
to the user is probably unwise, which you should already know, otherwise
you would have delivered it in the first place.  Simply deleting it means
that you lied to the delivering MTA back when you first accepted it --
and that's very poor operational practice.  Not to mention quite rude.
So what, *exactly*, do you plan to do with it?  When?  How?

- Informing users of quarantined mail is another problem.  Anyone with
any familiarity with user behavior knows that they'll click on anything
and everything in a heartbeat without performing any kind of due diligence.
So that well-crafted spear phish that you should have rejected outright
but quarantined because it scored well enough on your content-screening
system?  Your user is going to pull that right back and open it as soon
as they glance over the "Subject" line quickly in Monday morning's
quarantine report, and you will be 0wned by lunchtime.  Game over, man.

- On top of all of this, there's an even more fundamental strategic problem.
Spam is (among many other things) an attack on the time and attention
of recipients.  Mail system operators who deploy quarantines are
aiding and abetting that attack, because they're chewing up the same
scarce and expensive resources: time and attention.  One of the goals
of a mail defense system is to reduce that time and attention to zero.
Of course, under real-world conditions, that's never possible -- still,
one should always strive to asymptotically approach it.  But quarantines
are clearly a massive step in the wrong direction, for what I trust
are abundantly obvious reasons.

> Implemented appropriately;  an SMTP callout (or "SMTP connect"
> verification) to the connecting IP is a great way to help resolve the
> suspiciousness level of the sending mail server.

No, it's always abusive.  As analysis carried out by the late Bruce
Gingery, myself, and others on spam-l years ago (when Verizon was doing
this) demonstrates, allowing others to cause your operation to generate
outbound SMTP traffic to third parties of *their* choosing is a serious
tactical error.  It furnishes a free, scalable DDoS support service --
which, unfortunately, is not a hypothetical issue.  It also facilitates
third-party bypass of others' security mechanisms, which, depending on
your legal jurisdiction, may be an issue: I would recommend consulting
your attorneys before deploying it, and asking them what exposure you
incur by doing so.  And on top of all that, it has no anti-spam value
whatsoever.  (Note: self-directed callouts, to one's own internal mail
infrastructure, are not abusive.  They're inefficient, and much better
methods nearly always exist for providing the same functionality, but
they're not abusive.)

> Using the name abuse@  for the abuse contact  is not required,  and it is
> likely to be targetted by spammers.

Of course it will be.  So will "postmaster".   So will every other
role and non-role address.  Any reasonably competent operation should
have no problem dealing with that.  IMHO, anyone who cannot manage the
rudimentary task of managing their "abuse" mailbox is wholly unqualified
to run a mail system.  (Or a web server, or a network, or anything else
exposed to the public Internet.)

---rsk



From rwebb at ropeguru.com  Fri Nov  8 12:48:08 2013
From: rwebb at ropeguru.com (rwebb at ropeguru.com)
Date: Fri, 08 Nov 2013 07:48:08 -0500
Subject: Email Server and DNS
In-Reply-To: <20131108123740.GA19333@gsp.org>
References: <web-90567@mail.saroza-webb.local> <20131103170859.GA9212@gsp.org>
 <CAAAwwbWC4iFg_Lp6rWhfBXjQryg-v4MoghFnE5k=nDOMJVf6BQ@mail.gmail.com>
 <20131108123740.GA19333@gsp.org>
Message-ID: <web-100125@mail.saroza-webb.local>

Thanks to everyone for all the tips and info. I think I have compiled 
plenty of info to get this done. I will probably start with some of 
the basics and see how things go. THen as needed start putting in some 
additional features as I see how things progress.

Robert


On Fri, 8 Nov 2013 07:37:40 -0500
  Rich Kulawiec <rsk at gsp.org> wrote:
> I suggest moving this to mailop, where it arguably belongs.  But I'm
> going to follow up on a few points, anyway.
> 
>First, I forgot to mention two other highly effective mail system
> defense methods: geoblocking and passive OS fingerprinting.
> 
> Geoblocking: A mail server for a local construction business in 
>Arizona
> is unlikely to require mail from Poland, Peru or Pakistan.  So 
>there's
> no reason to go with a default-permit model: use default-deny and
> only allow mail from places where legitimate mail might originate.
> (In this case, perhaps: the US, Mexico, and Canada.)  Use the ranges
> from ipdeny.com.  This will stop an astonishing amount of spam (and
> other SMTP-borne abuse) cold.  And it can be done at the MTA or in
> the firewall: which is better depends on circumstances.
> 
> Obviously this doesn't work for everyone.  Obviously this (like
> everything else) runs the risk of false positives -- but it's easy
> to mitigate that.  Obviously it does require understanding the
> patterns in your mail traffic, but any competent mail system admin
> has long since performed detailed statistical analysis and has a
> pretty good idea what the characteristics of their incoming mail
> stream look like.
> 
> Passive OS fingerprinting: regard anything originating from an OS
> that fingerprints as Windows as dubious, at best.  Possible actions
> vary: graylisting (more precisely, graylisting regardless of 
>previous
> traffic) is one good option.  Utilizing this in concert with 
>geoblocking
> (above) works beautifully, e.g., "I'm in Arizona and something in 
>Portugal
> that fingerprints as Windows is trying to send me SMTP traffic: the
> probability approaches unity that this is spam".  When combined with
> rDNS information, this becomes a highly efficient mechanism with a 
>FP
> rate that's ridiculously low.  (In other words, if that same system
> has rDNS that looks like 123-45-67-8.example.com then it either 
>really
> is a bot or it's a mail system run by someone with no clue.)
> 
> A few short points and one long one in response:
> 
> On Sun, Nov 03, 2013 at 12:00:23PM -0600, Jimmy Hess wrote:
>> The RFC contains a MUST NOT  in regards to verifying the  HELO name 
>>matches.
>> So, the HELO can use any hostname ---  as long as the hostname 
>>forward
>> resolves to something;  it should resolve to the IP address of one 
>>of your
>> mail servers.    Some mail servers provide service for many domains, 
>>and
>> have many DNS names that could be placed in a HELO.
> 
> All true.  But none of this argues against using the canonical 
>hostname
> in the HELO.  It's the simplest, easiest option (and quite often the
> one that software will pick by default).
> 
>> > SPF is worthless crap: don't bother.  Use a real MTA, e.g., 
>>postfix
>> >
>> 
>> I do not believe that is the consensus of the community -- or the 
>>working
>> groups behind the SPF-related RFCs.
> 
> I'm well aware it's not the consensus.  It's my opinion.
> 
> Clue #1 that SPF is crap should have been its grandiose 
>self-promoting
> announcement ("Spam as a technical problem is solved by SPF").  Clue 
>#2
> should have been the observation that -- by far -- the most prolific
> early adopters were spammers.  When your enemy latches on to your
> new weapon much faster than you do, that should be a tipoff that 
>maybe it's
> not what you hope it is.  Clue #3 is available to anyone who deploys 
>a
> sufficiently large and diverse set of spamtraps for several years 
>and
> analyzes the data that arrives: SPF presence/absence or contents 
>have
> no statistically useful anti-spam value in a properly-designed mail
> defense architecture.  
> 
> Don't believe me?  Okay.  Fine.  Set up a few thousand spamtraps, 
>gather
> data for 3-5 years, see for yourself.
> 
> So yes, it's standardized; so what?  So is (sort of) DNS forgery, 
>see
> http://tools.ietf.org/html/draft-livingood-dns-redirect-03 for 
>example.
> That's also crap, it just happens to be well-documented crap.
> 
> So: if you feel you must use something, use DKIM, which I think 
>shows
> vastly more promise.  Just don't expect it to be a panacea, because
> the current miserable state of security at *all* levels undercuts it
> badly.  Not DKIM's fault, really, but it does impact its usefulness
> in the real world.
> 
>> Message quarantines are great;  they are helpful  for mitigating the 
>>false
>> positives of overly-agressive filters.
> 
> This one I'll spend more time on.  Quarantines are a worst practice 
> in mail systems engineering.  Here are some assorted reasons why, 
>briefly:
> 
> - One of the fundamental principles of mail system defense is that 
>you
> should make your mistakes early, consistently, and loudly.  (And you
> WILL make mistakes.   Everyone does.)  The point of doing this is 
>that
> it enables all concerned, including you, to have a decent chance of
> noticing them, figuring out that they're mistakes, and correcting 
>them.
> Quarantines hide, defer, and silence your mistakes, making it much 
>more
> difficult to run your system properly.  They're a lazy admin's 
>coverup,
> not a fix.
> 
> - Quarantines present deadlock problems.  Mail from user A to user B
> which is quarantined and causes B to eventually send a message to 
>user A
> enquiring about the missing missive stands a decent chance of ending 
>up
> in B's quarantine.  The end result is that human time (which is a 
>scarce
> and expensive commodity) is needlessly wasted figuring out the 
>problem
> and then trying to evade it, usually by trying to tapdance a way 
>past
> the filters on both sides.  Contrast with a hard, immediate 
>rejection,
> which -- coupled with an appropriate resolution mechanism -- 
>facilitates
> quick, easy diagnosis and repair.
> 
> - Some people use quarantines because they're unduly concerned about
> their false positive rate.  But slapping the ill-advised band-aid of 
>a
> quarantine on an underlying problem like a high FP rate solves 
>nothing.
> It merely obscures the mistake.  The correct solution is to figure 
>out why
> the FP rate is high, and fix that, because that's where the problem 
>is.
> 
> - Users have spent the past two decades or so conclusively proving, 
>beyond
> any possible argument, that they are utterly incapable of 
>distinguishing
> spam from non-spam, phish from non-phish.  (Consider carefully: if 
>they
> could, en masse and accurately, would we have the scope and scale of 
>the
> problem set we currently face?  No.  We would not.)  "Educating 
>users" is
> a complete failure as a strategy; see point #5 here:
> 
> 	The Six Dumbest Ideas in Computer Security
> 	http://www.ranum.com/security/computer_security/editorials/dumb/
> 
> Even personnel who *work in security* can't solve this 
>classification
> problem correctly (which is why I said "ask RSA how that's working
> out for them").  Your users are no better.  They're probably worse.
> So punting the task of correctly classifying incoming mail to them 
>is
> reckless and irresponsible.  With precious few and rare exceptions, 
>they
> WILL fail.  Freuqently.  And sometimes (again: see RSA) the 
>consequences
> of even a single failure can be catastrophic.
> 
> More bluntly, allowing users anywhere near the machinery of 
>security,
> when they've proven for decades that they're absolutely unqualified 
>to
> handle even its simplest aspects, is clearly unprofessional and 
>highly
> negligent.  Yes, this is somewhat a fascist, uncompromising, 
>condescending,
> etc. attitude.  It's also the only one that's been demonstrated to 
>work in
> the real world.  It's a shame, really, but this is not the 'net of 
>1983.
> You can be nice and flexible and accomodating or you can be 
>(modestly)
> secure.  Pick one.
> 
> - Disposition of quarantined mail is problematic -- unless of course
> the intention is to let it accumulate indefinitely, which is a 
>dubious
> idea at best.  Eventually, *something* has to be done.  Delivering 
>it
> to the user is probably unwise, which you should already know, 
>otherwise
> you would have delivered it in the first place.  Simply deleting it 
>means
> that you lied to the delivering MTA back when you first accepted it 
>--
> and that's very poor operational practice.  Not to mention quite 
>rude.
> So what, *exactly*, do you plan to do with it?  When?  How?
> 
> - Informing users of quarantined mail is another problem.  Anyone 
>with
> any familiarity with user behavior knows that they'll click on 
>anything
> and everything in a heartbeat without performing any kind of due 
>diligence.
> So that well-crafted spear phish that you should have rejected 
>outright
> but quarantined because it scored well enough on your 
>content-screening
> system?  Your user is going to pull that right back and open it as 
>soon
> as they glance over the "Subject" line quickly in Monday morning's
> quarantine report, and you will be 0wned by lunchtime.  Game over, 
>man.
> 
> - On top of all of this, there's an even more fundamental strategic 
>problem.
> Spam is (among many other things) an attack on the time and 
>attention
> of recipients.  Mail system operators who deploy quarantines are
> aiding and abetting that attack, because they're chewing up the same
> scarce and expensive resources: time and attention.  One of the 
>goals
> of a mail defense system is to reduce that time and attention to 
>zero.
> Of course, under real-world conditions, that's never possible -- 
>still,
> one should always strive to asymptotically approach it.  But 
>quarantines
> are clearly a massive step in the wrong direction, for what I trust
> are abundantly obvious reasons.
> 
>> Implemented appropriately;  an SMTP callout (or "SMTP connect"
>> verification) to the connecting IP is a great way to help resolve 
>>the
>> suspiciousness level of the sending mail server.
> 
> No, it's always abusive.  As analysis carried out by the late Bruce
> Gingery, myself, and others on spam-l years ago (when Verizon was 
>doing
> this) demonstrates, allowing others to cause your operation to 
>generate
> outbound SMTP traffic to third parties of *their* choosing is a 
>serious
> tactical error.  It furnishes a free, scalable DDoS support service 
>--
> which, unfortunately, is not a hypothetical issue.  It also 
>facilitates
> third-party bypass of others' security mechanisms, which, depending 
>on
> your legal jurisdiction, may be an issue: I would recommend 
>consulting
> your attorneys before deploying it, and asking them what exposure 
>you
> incur by doing so.  And on top of all that, it has no anti-spam 
>value
> whatsoever.  (Note: self-directed callouts, to one's own internal 
>mail
> infrastructure, are not abusive.  They're inefficient, and much 
>better
> methods nearly always exist for providing the same functionality, 
>but
> they're not abusive.)
> 
>> Using the name abuse@  for the abuse contact  is not required,  and 
>>it is
>> likely to be targetted by spammers.
> 
> Of course it will be.  So will "postmaster".   So will every other
> role and non-role address.  Any reasonably competent operation 
>should
> have no problem dealing with that.  IMHO, anyone who cannot manage 
>the
> rudimentary task of managing their "abuse" mailbox is wholly 
>unqualified
> to run a mail system.  (Or a web server, or a network, or anything 
>else
> exposed to the public Internet.)
> 
> ---rsk
> 
> 



From bill at herrin.us  Fri Nov  8 13:37:32 2013
From: bill at herrin.us (William Herrin)
Date: Fri, 8 Nov 2013 08:37:32 -0500
Subject: Email Server and DNS
In-Reply-To: <web-90567@mail.saroza-webb.local>
References: <web-90567@mail.saroza-webb.local>
Message-ID: <CAP-guGWuSxzr8YxUoYzRUcu1yWtX29EyXc6YWxSiRG6KnB=EvQ@mail.gmail.com>

On Sun, Nov 3, 2013 at 11:39 AM,  <rwebb at ropeguru.com> wrote:
> I am looking for some info on current practice for an email server and SMTP
> delivery. It has been a while since I have had to setup an email server and
> I have been tasked with setting up a small one for a friend. My question
> centers around the server sending outgoing email and the current practices
> requirements for other servers to accept email Things like rDNS, SPF
> records, etc...

Hi Robert,

Current best practices are: don't run your own email server unless
you're willing to spend the ongoing time and effort it takes to keep
up with the current solutions to the spam, hacking and abuse problems.
Corollary: when you get bored of doing so for a tiny mail server, stop
running it and buy a service.


Other than that, the _changes_ of note in the last decade are:

1. The blacklist aggregators and IP reputation services have changed
so you have to find the new ones,
2. There are email whitelist services now, some free others for a
nominal cost. Use them.
3. Phishing and spear phishing are relatively sophisticated now, so
your spam solution has to deal reasonably with it.
4. Relay from and to an external address without changing the envelope
sender no longer functions reliably due to things like SPF enforcement
and no mail servers I've noticed have such a translator built in.


Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From emile.aben at ripe.net  Fri Nov  8 14:56:06 2013
From: emile.aben at ripe.net (Emile Aben)
Date: Fri, 08 Nov 2013 15:56:06 +0100
Subject: Any issues in asia-pac due to typhoon
In-Reply-To: <CAPiURgXdweG15z=MXtd2oFqYKg5ZNoo3ZiD2X8Vk0OwqOV2PDw@mail.gmail.com>
References: <CAPiURgXdweG15z=MXtd2oFqYKg5ZNoo3ZiD2X8Vk0OwqOV2PDw@mail.gmail.com>
Message-ID: <527CFB86.5050701@ripe.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/11/2013 01:58, Grant Ridder wrote:

> I am curious to see if anyone has been any issues or outages due to
> the typhoon in the area of the Philippines.

We've found very little in RIPEstat and RIPE Atlas data we collect:
https://labs.ripe.net/Members/emileaben/typhoon-haiyan-what-we-see-in-ripestat-and-ripe-atlas

We will keep an eye out on it.

best regards,
Emile Aben
RIPE NCC


> Satellite: http://www.pagasa.dost.gov.ph/wb/sat_images/satpic.jpg 
> http://www.usatoday.com/story/news/world/2013/11/07/philippines-typhoon/3465779/
>
> 
> 
> -Grant
> 
> P.S. - Also sent this to outages list earlier
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlJ8+4YACgkQj05ACITZaqpxBgD/Ryf87NNty0vkCngqn6qz6iD4
2fQ+m7mwVqXMn603sSkBAIPbVJaF9uvzEz1pf5XXxYLgVNd0PQOg4bvEdDM7mFyL
=qicN
-----END PGP SIGNATURE-----


From bmanning at vacation.karoshi.com  Fri Nov  8 17:02:21 2013
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 8 Nov 2013 17:02:21 +0000
Subject: Email Server and DNS
In-Reply-To: <CAP-guGWuSxzr8YxUoYzRUcu1yWtX29EyXc6YWxSiRG6KnB=EvQ@mail.gmail.com>
References: <web-90567@mail.saroza-webb.local>
 <CAP-guGWuSxzr8YxUoYzRUcu1yWtX29EyXc6YWxSiRG6KnB=EvQ@mail.gmail.com>
Message-ID: <20131108170221.GB3824@vacation.karoshi.com.>

On Fri, Nov 08, 2013 at 08:37:32AM -0500, William Herrin wrote:
> On Sun, Nov 3, 2013 at 11:39 AM,  <rwebb at ropeguru.com> wrote:
> > I am looking for some info on current practice for an email server and SMTP
> > delivery. It has been a while since I have had to setup an email server and
> > I have been tasked with setting up a small one for a friend. My question
> > centers around the server sending outgoing email and the current practices
> > requirements for other servers to accept email Things like rDNS, SPF
> > records, etc...
> 
> Hi Robert,
> 
> Current best practices are: don't run your own email server unless
> you're willing to spend the ongoing time and effort it takes to keep
> up with the current solutions to the spam, hacking and abuse problems.
> Corollary: when you get bored of doing so for a tiny mail server, stop
> running it and buy a service.

	and yet, at the IETF this week, in the technical plenary, a call to
	diffuse the target space by running your own services.  much harder
	to have your mail scrapped from your servers than from your providers.

/bill


> 
> 
> Other than that, the _changes_ of note in the last decade are:
> 
> 1. The blacklist aggregators and IP reputation services have changed
> so you have to find the new ones,
> 2. There are email whitelist services now, some free others for a
> nominal cost. Use them.
> 3. Phishing and spear phishing are relatively sophisticated now, so
> your spam solution has to deal reasonably with it.
> 4. Relay from and to an external address without changing the envelope
> sender no longer functions reliably due to things like SPF enforcement
> and no mail servers I've noticed have such a translator built in.
> 
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004


From robertg at garlic.com  Fri Nov  8 17:30:27 2013
From: robertg at garlic.com (Robert Glover)
Date: Fri, 08 Nov 2013 09:30:27 -0800
Subject: Cogent packet loss to Verizon in San Jose
Message-ID: <527D1FB3.6000801@garlic.com>

Anyone from Cogent around?  Normal support channels aren't getting me
anywhere.

We have been seeing consistent packet loss to Verizon over Cogent in San
Jose for several days:

HOST: noc-auth1.garlic.com                           Loss%   Snt  
Last   Avg  Best  Wrst StDev
  1. router.garlic.com                               0.0%    10    0.4  
0.3   0.2   0.4   0.0
  2. vl203.mag03.sfo01.atlas.cogentco.com            0.0%    10    2.2  
2.3   2.1   2.4   0.1
  3. te0-2-0-1.mpd21.sfo01.atlas.cogentco.com        0.0%    10    2.6  
2.6   2.4   2.8   0.1
  4. be2166.ccr21.sjc01.atlas.cogentco.com           0.0%    10    3.9  
3.9   3.7   4.2   0.1
  5. be2000.ccr21.sjc03.atlas.cogentco.com           0.0%    10    4.7  
4.4   4.3   4.7   0.1
  6. verizon.sjc03.atlas.cogentco.com               40.0%    10   80.0 
80.8  79.9  81.8   0.7
  7. so-1-0-0-0.SJC01-CORE-RTR1.verizon-gni.net      30.0%    10   82.2 
87.9  81.1 114.6  11.3
  8. A8-0-1710.SNFCCA-DSL-01.verizon-gni.net        30.0%    10   83.2 
83.8  82.1  85.9   1.3
  9. static-71-116-125-210.snfcca.dsl-w.verizon.net 20.0%    10  108.1
107.2 105.7 108.7   1.1


We have had to route some customer's traffic out through our alternate
provider (AS20115), as their VPN's were borked by the packet loss.

Thanks,
-Bobby


From mhuff at ox.com  Fri Nov  8 17:48:30 2013
From: mhuff at ox.com (Matthew Huff)
Date: Fri, 8 Nov 2013 12:48:30 -0500
Subject: Cogent packet loss to Verizon in San Jose
In-Reply-To: <527D1FB3.6000801@garlic.com>
References: <527D1FB3.6000801@garlic.com>
Message-ID: <483E6B0272B0284BA86D7596C40D29F9021179170F25@PUR-EXCH07.ox.com>

This has been going on nationwide between Cogent and other peering partners since early 2013 (and in some cases before), but especially between Cogent and Verizon. It's not a technical problem, but a political one. 

We resolved our issue by working with our upsteam providers to reconfigure our routing and advertisements to avoid cogent, otherwise, I don't think there is any solution coming within a reasonable timeframe


----
Matthew Huff?            | 1 Manhattanville Rd
Director of Operations???| Purchase, NY 10577
OTA Management LLC       | Phone: 914-460-4039

> -----Original Message-----
> From: Robert Glover [mailto:robertg at garlic.com]
> Sent: Friday, November 08, 2013 12:30 PM
> To: NANOG Mailing List
> Subject: Cogent packet loss to Verizon in San Jose
> 
> Anyone from Cogent around?  Normal support channels aren't getting me
> anywhere.
> 
> We have been seeing consistent packet loss to Verizon over Cogent in San
> Jose for several days:
> 
> HOST: noc-auth1.garlic.com                           Loss%   Snt
> Last   Avg  Best  Wrst StDev
>   1. router.garlic.com                               0.0%    10    0.4
> 0.3   0.2   0.4   0.0
>   2. vl203.mag03.sfo01.atlas.cogentco.com            0.0%    10    2.2
> 2.3   2.1   2.4   0.1
>   3. te0-2-0-1.mpd21.sfo01.atlas.cogentco.com        0.0%    10    2.6
> 2.6   2.4   2.8   0.1
>   4. be2166.ccr21.sjc01.atlas.cogentco.com           0.0%    10    3.9
> 3.9   3.7   4.2   0.1
>   5. be2000.ccr21.sjc03.atlas.cogentco.com           0.0%    10    4.7
> 4.4   4.3   4.7   0.1
>   6. verizon.sjc03.atlas.cogentco.com               40.0%    10   80.0
> 80.8  79.9  81.8   0.7
>   7. so-1-0-0-0.SJC01-CORE-RTR1.verizon-gni.net      30.0%    10   82.2
> 87.9  81.1 114.6  11.3
>   8. A8-0-1710.SNFCCA-DSL-01.verizon-gni.net        30.0%    10   83.2
> 83.8  82.1  85.9   1.3
>   9. static-71-116-125-210.snfcca.dsl-w.verizon.net 20.0%    10  108.1
> 107.2 105.7 108.7   1.1
> 
> 
> We have had to route some customer's traffic out through our alternate
> provider (AS20115), as their VPN's were borked by the packet loss.
> 
> Thanks,
> -Bobby



From cscora at apnic.net  Fri Nov  8 18:06:48 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 9 Nov 2013 04:06:48 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201311081806.rA8I6mjV007980@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, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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

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

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

Routing Table Report   04:00 +10GMT Sat 09 Nov, 2013

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

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

BGP routing table entries examined:                              471623
    Prefixes after maximum aggregation:                          189286
    Deaggregation factor:                                          2.49
    Unique aggregates announced to Internet:                     234004
Total ASes present in the Internet Routing Table:                 45399
    Prefixes per ASN:                                             10.39
Origin-only ASes present in the Internet Routing Table:           35335
Origin ASes announcing only one prefix:                           16258
Transit ASes present in the Internet Routing Table:                5944
Transit-only ASes present in the Internet Routing Table:            161
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      35
    Max AS path prepend of ASN ( 55644)                              31
Prefixes from unregistered ASNs in the Routing Table:               733
    Unregistered ASNs in the Routing Table:                         200
Number of 32-bit ASNs allocated by the RIRs:                       5316
Number of 32-bit ASNs visible in the Routing Table:                4120
Prefixes from 32-bit ASNs in the Routing Table:                   12912
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            991
Number of addresses announced to Internet:                   2655011864
    Equivalent to 158 /8s, 64 /16s and 68 /24s
    Percentage of available address space announced:               71.7
    Percentage of allocated address space announced:               71.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               95.1
Total number of prefixes smaller than registry allocations:      164478

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

Prefixes being announced by APNIC Region ASes:                   111655
    Total APNIC prefixes after maximum aggregation:               33910
    APNIC Deaggregation factor:                                    3.29
Prefixes being announced from the APNIC address blocks:          113823
    Unique aggregates announced from the APNIC address blocks:    47461
APNIC Region origin ASes present in the Internet Routing Table:    4871
    APNIC Prefixes per ASN:                                       23.37
APNIC Region origin ASes announcing only one prefix:               1215
APNIC Region transit ASes present in the Internet Routing Table:    831
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         35
Number of APNIC region 32-bit ASNs visible in the Routing Table:    726
Number of APNIC addresses announced to Internet:              730128832
    Equivalent to 43 /8s, 132 /16s and 225 /24s
    Percentage of available APNIC address space announced:         85.3

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-63999, 131072-133631
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:                    162974
    Total ARIN prefixes after maximum aggregation:                81671
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           163805
    Unique aggregates announced from the ARIN address blocks:     75998
ARIN Region origin ASes present in the Internet Routing Table:    15923
    ARIN Prefixes per ASN:                                        10.29
ARIN Region origin ASes announcing only one prefix:                6002
ARIN Region transit ASes present in the Internet Routing Table:    1667
Average ARIN Region AS path length visible:                         4.1
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:      34
Number of ARIN addresses announced to Internet:              1073766528
    Equivalent to 64 /8s, 0 /16s and 96 /24s
    Percentage of available ARIN address space announced:          56.8

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8,
                       205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8,
                       216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    119126
    Total RIPE prefixes after maximum aggregation:                60986
    RIPE Deaggregation factor:                                     1.95
Prefixes being announced from the RIPE address blocks:           122772
    Unique aggregates announced from the RIPE address blocks:     78781
RIPE Region origin ASes present in the Internet Routing Table:    17512
    RIPE Prefixes per ASN:                                         7.01
RIPE Region origin ASes announcing only one prefix:                8292
RIPE Region transit ASes present in the Internet Routing Table:    2834
Average RIPE Region AS path length visible:                         5.1
    Max RIPE Region AS path length visible:                          31
Number of RIPE region 32-bit ASNs visible in the Routing Table:    2464
Number of RIPE addresses announced to Internet:               656685924
    Equivalent to 39 /8s, 36 /16s and 59 /24s
    Percentage of available RIPE address space announced:          95.5

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-200191
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:                   52590
    Total LACNIC prefixes after maximum aggregation:               9987
    LACNIC Deaggregation factor:                                   5.27
Prefixes being announced from the LACNIC address blocks:          57800
    Unique aggregates announced from the LACNIC address blocks:   26931
LACNIC Region origin ASes present in the Internet Routing Table:   2037
    LACNIC Prefixes per ASN:                                      28.38
LACNIC Region origin ASes announcing only one prefix:               550
LACNIC Region transit ASes present in the Internet Routing Table:   394
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        35
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   890
Number of LACNIC addresses announced to Internet:             142751604
    Equivalent to 8 /8s, 130 /16s and 55 /24s
    Percentage of available LACNIC address space announced:        85.1

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 262144-263679 plus 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:                  11774
    Total AfriNIC prefixes after maximum aggregation:              2590
    AfriNIC Deaggregation factor:                                  4.55
Prefixes being announced from the AfriNIC address blocks:         12432
    Unique aggregates announced from the AfriNIC address blocks:   4033
AfriNIC Region origin ASes present in the Internet Routing Table:   677
    AfriNIC Prefixes per ASN:                                     18.36
AfriNIC Region origin ASes announcing only one prefix:              199
AfriNIC Region transit ASes present in the Internet Routing Table:  135
Average AfriNIC Region AS path length visible:                      4.7
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    6
Number of AfriNIC addresses announced to Internet:             48104192
    Equivalent to 2 /8s, 222 /16s and 3 /24s
    Percentage of available AfriNIC address space announced:       47.8

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2934      11557         943   Korea Telecom (KIX)
17974     2711        903          89   PT TELEKOMUNIKASI INDONESIA
 7545     2112        319         111   TPG Internet Pty Ltd
 4755     1788        391         188   TATA Communications formerly 
 9829     1543       1240          41   BSNL National Internet Backbo
 9498     1210        309          73   BHARTI Airtel Ltd.
 9583     1190         91         513   Sify Limited
 7552     1158       1080          13   Vietel Corporation
 4808     1150       2124         339   CNCGROUP IP network: China169
24560     1094        380         163   Bharti Airtel Ltd., Telemedia

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
 6389     3054       3688          56   BellSouth.net Inc.
22773     2192       2939         138   Cox Communications, Inc.
18566     2057        379         178   MegaPath Corporation
 1785     2038        684         131   PaeTec Communications, Inc.
20115     1683       1654         608   Charter Communications 
 4323     1630       1102         421   Time Warner Telecom
  701     1506      11146         782   MCI Communications Services, 
30036     1385        313         576   Mediacom Communications Corp 
 7018     1340      17795         873   AT&T WorldNet Services
 6983     1293        755         578   ITC^Deltacom 

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
 8402     1969        544          17   OJSC "Vimpelcom"
34984     1362        244         223   TELLCOM ILETISIM HIZMETLERI A
20940     1120        409         849   Akamai Technologies European 
31148     1005         44          18   FreeNet ISP
13188      887         99          48   TOV "Bank-Inform"
 6849      862        356          30   JSC UKRTELECOM,
 8551      783        370          41   Bezeq International
 6830      770       2327         422   UPC Distribution Services
12479      677        798          55   Uni2 Autonomous System
35228      544        246          16   Avatar Broadband Limited

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
28573     3433       1788          85   NET Servicos de Comunicao S.A
10620     2648        429         233   TVCABLE BOGOTA 
 7303     1727       1146         232   Telecom Argentina Stet-France
18881     1548        908          20   Global Village Telecom 
 8151     1364       2853         414   UniNet S.A. de C.V. 
11830      866        364          15   Instituto Costarricense de El
27947      846         93          90   Telconet S.A
 6503      790        434          61   AVANTEL, S.A. 
 7738      780       1498          36   Telecomunicacoes da Bahia S.A
 3816      744        301         121   Empresa Nacional de Telecomun

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
36998     1864        112           5   Sudanese Mobile Telephone (ZA
24863      892        338          30   LINKdotNET AS number
 6713      554        633          26   Itissalat Al-MAGHRIB
 8452      412        956           9   TEDATA
24835      295        144           9   RAYA Telecom - Egypt
 3741      256        921         214   The Internet Solution 
36992      229        501          29   Etisalat MISR
29571      224         17          12   Ci Telecom Autonomous system 
15706      221         32           6   Sudatel Internet Exchange Aut
29975      192        668          21   Vodacom

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
28573     3433       1788          85   NET Servicos de Comunicao S.A
 6389     3054       3688          56   BellSouth.net Inc.
 4766     2934      11557         943   Korea Telecom (KIX)
17974     2711        903          89   PT TELEKOMUNIKASI INDONESIA
10620     2648        429         233   TVCABLE BOGOTA 
22773     2192       2939         138   Cox Communications, Inc.
 7545     2112        319         111   TPG Internet Pty Ltd
18566     2057        379         178   MegaPath Corporation
 1785     2038        684         131   PaeTec Communications, Inc.
 8402     1969        544          17   OJSC "Vimpelcom"

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

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

  ASN   No of nets  Net Savings Description
 6389      3054        2998      BellSouth.net Inc.
17974      2711        2622      PT TELEKOMUNIKASI INDONESIA
10620      2648        2415      TVCABLE BOGOTA 
22773      2192        2054      Cox Communications, Inc.
 7545      2112        2001      TPG Internet Pty Ltd
 4766      2934        1991      Korea Telecom (KIX)
 8402      1969        1952      OJSC "Vimpelcom"
 1785      2038        1907      PaeTec Communications, Inc.
18566      2057        1879      MegaPath Corporation
36998      1864        1859      Sudanese Mobile Telephone (ZA

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

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

Bad AS  Designation  Network              Transit AS  Description
62828   UNALLOCATED  8.21.130.0/24         3356       Level 3 Communicatio
62734   UNALLOCATED  8.31.128.0/24         6939       Hurricane Electric 
62773   UNALLOCATED  8.35.180.0/22         3356       Level 3 Communicatio
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
62719   UNALLOCATED  12.27.130.0/24        4323       Time Warner Telecom
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24         209       Qwest Communications
17300   UNALLOCATED  12.45.110.0/24         701       MCI Communications S
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic

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

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.100.0.0/24        4847     China Networks Inter-Exchange

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

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

Network            Origin AS  Description
23.90.128.0/18       27418     OUTOFWALL INC.
23.90.192.0/18       36086     Broad Communications Technolo
23.91.0.0/19         40676     Psychz Networks 
23.91.4.0/24         40676     Psychz Networks 
23.91.14.0/24        40676     Psychz Networks 
23.91.32.0/19        36315     Servpac Inc. 
23.91.80.0/20        21560     Capital Technology Services G
23.91.112.0/21       32475     MidPhase Inc. 
23.91.160.0/19       36493     3757277 Canada Inc. (oa 295.c
23.91.160.0/22       36493     3757277 Canada Inc. (oa 295.c

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:11      /10:31      /11:92      /12:254     
/13:474     /14:923     /15:1628    /16:12844   /17:6759    /18:11343   
/19:23128   /20:32795   /21:35564   /22:49817   /23:43790   /24:249692  
/25:833     /26:989     /27:474     /28:50      /29:80      /30:22      
/31:0       /32:14      

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

  ASN   No of nets  Total ann.   Description
18566     2011          2057      MegaPath Corporation
36998     1829          1864      Sudanese Mobile Telephone (ZA
 6389     1707          3054      BellSouth.net Inc.
 8402     1635          1969      OJSC "Vimpelcom"
22773     1455          2192      Cox Communications, Inc.
30036     1231          1385      Mediacom Communications Corp 
11492     1192          1232      Cable One 
 1785     1086          2038      PaeTec Communications, Inc.
 6983     1034          1293      ITC^Deltacom 
22561      972          1249      Digital Teleport, Inc 

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

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

   1:896       2:869       3:3         4:17        5:1024      6:21     
   8:617      12:1900     13:3        14:898      15:11       16:3      
  17:18       18:19       20:21       23:527      24:1742     27:1628   
  31:1498     32:45       33:2        34:5        36:82       37:1911   
  38:917      39:4        40:181      41:3249     42:263      44:14     
  46:2024     47:9        49:688      50:847      52:12       54:42     
  55:5        56:4        57:26       58:1161     59:576      60:375    
  61:1466     62:1231     63:1982     64:4356     65:2345     66:4148   
  67:2110     68:1107     69:3302     70:874      71:490      72:2040   
  74:2563     75:328      76:307      77:1165     78:1062     79:664    
  80:1299     81:1035     82:650      83:630      84:588      85:1253   
  86:381      87:1013     88:563      89:1558     90:149      91:5652   
  92:619      93:1606     94:2033     95:1608     96:512      97:345    
  98:1050     99:40      100:31      101:629     103:3547    105:527    
 106:142     107:215     108:536     109:1935    110:967     111:1115   
 112:593     113:810     114:752     115:1049    116:1001    117:828    
 118:1168    119:1278    120:364     121:750     122:1870    123:1261   
 124:1364    125:1438    128:675     129:229     130:331     131:665    
 132:365     133:157     134:556     135:72      136:279     137:269    
 138:350     139:177     140:198     141:332     142:542     143:398    
 144:491     145:88      146:529     147:410     148:778     149:368    
 150:138     151:587     152:409     153:206     154:51      155:458    
 156:289     157:420     158:278     159:776     160:360     161:459    
 162:838     163:226     164:634     165:586     166:259     167:634    
 168:1047    169:125     170:1120    171:182     172:27      173:1588   
 174:687     175:515     176:1310    177:2442    178:1958    179:206    
 180:1585    181:823     182:1340    183:466     184:668     185:1006   
 186:2654    187:1481    188:1869    189:1248    190:7115    192:7117   
 193:5426    194:4049    195:3365    196:1340    197:1062    198:4759   
 199:5503    200:6080    201:2464    202:8947    203:8875    204:4538   
 205:2651    206:2843    207:2831    208:3978    209:3654    210:3002   
 211:1568    212:2146    213:1990    214:895     215:91      216:5421   
 217:1688    218:627     219:323     220:1280    221:569     222:327    
 223:503    

End of report


From edwardroels at gmail.com  Fri Nov  8 02:41:45 2013
From: edwardroels at gmail.com (Edward Roels)
Date: Thu, 7 Nov 2013 21:41:45 -0500
Subject: 100G wave pricing in Pennsylvania
Message-ID: <CAPpGzHHo_2ysp6LiOx3_ZeBbEGYJ2gFSboin4+aMoTsKeqwj1w@mail.gmail.com>

I'm looking for rough pricing or even carriers that can provide a 100G wave
in Pennsylvania.

If you have some insight into how pricing scales between 10G and 100G
offerings (e.g. 100G is usually 5-6x the cost of a 10G),  I'm also
interested.

Off-list replies are welcome.


Thanks,

Ed

From w3yni1 at gmail.com  Fri Nov  8 18:21:11 2013
From: w3yni1 at gmail.com (Charles Mills)
Date: Fri, 8 Nov 2013 13:21:11 -0500
Subject: 100G wave pricing in Pennsylvania
In-Reply-To: <CAPpGzHHo_2ysp6LiOx3_ZeBbEGYJ2gFSboin4+aMoTsKeqwj1w@mail.gmail.com>
References: <CAPpGzHHo_2ysp6LiOx3_ZeBbEGYJ2gFSboin4+aMoTsKeqwj1w@mail.gmail.com>
Message-ID: <CAOF0KO-eWQgAY7gcBKXCnSqR-5HAj8qBiDJQOP-jJTqP60oz5A@mail.gmail.com>

It's a big state.  Which part?  Pittsburgh, Philadelphia or some point in
between?


On Thu, Nov 7, 2013 at 9:41 PM, Edward Roels <edwardroels at gmail.com> wrote:

> I'm looking for rough pricing or even carriers that can provide a 100G wave
> in Pennsylvania.
>
> If you have some insight into how pricing scales between 10G and 100G
> offerings (e.g. 100G is usually 5-6x the cost of a 10G),  I'm also
> interested.
>
> Off-list replies are welcome.
>
>
> Thanks,
>
> Ed
>

From edwardroels at gmail.com  Fri Nov  8 18:28:04 2013
From: edwardroels at gmail.com (Edward Roels)
Date: Fri, 8 Nov 2013 13:28:04 -0500
Subject: 100G wave pricing in Pennsylvania
In-Reply-To: <CAOF0KO-eWQgAY7gcBKXCnSqR-5HAj8qBiDJQOP-jJTqP60oz5A@mail.gmail.com>
References: <CAPpGzHHo_2ysp6LiOx3_ZeBbEGYJ2gFSboin4+aMoTsKeqwj1w@mail.gmail.com>
 <CAOF0KO-eWQgAY7gcBKXCnSqR-5HAj8qBiDJQOP-jJTqP60oz5A@mail.gmail.com>
Message-ID: <CAPpGzHGms=SOT+Wbr_evij6kAwb2wvJJdDX2hcPq0hbFGrWAng@mail.gmail.com>

Roughly between State College and Harrisburg.


On Fri, Nov 8, 2013 at 1:21 PM, Charles Mills <w3yni1 at gmail.com> wrote:

> It's a big state.  Which part?  Pittsburgh, Philadelphia or some point in
> between?
>
>
> On Thu, Nov 7, 2013 at 9:41 PM, Edward Roels <edwardroels at gmail.com>wrote:
>
>> I'm looking for rough pricing or even carriers that can provide a 100G
>> wave
>> in Pennsylvania.
>>
>> If you have some insight into how pricing scales between 10G and 100G
>> offerings (e.g. 100G is usually 5-6x the cost of a 10G),  I'm also
>> interested.
>>
>> Off-list replies are welcome.
>>
>>
>> Thanks,
>>
>> Ed
>>
>
>

From mshaw at fairpoint.com  Fri Nov  8 19:06:13 2013
From: mshaw at fairpoint.com (Shaw, Matthew)
Date: Fri, 8 Nov 2013 19:06:13 +0000
Subject: Cogent packet loss to Verizon in San Jose
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9021179170F25@PUR-EXCH07.ox.com>
References: <527D1FB3.6000801@garlic.com>
 <483E6B0272B0284BA86D7596C40D29F9021179170F25@PUR-EXCH07.ox.com>
Message-ID: <457F9455036417428963A59E3B388741202B6B27@0NH1C2P10.fairpoint.com>

Issues in NYC today too. We confirmed traffic coming in from VZW as well as Comcast through Cogent to us both seeing drops at that same point.

Matthew Shaw - Sr. Network Administrator 
FairPoint Communications | mshaw at fairpoint.com 

-----Original Message-----
From: Matthew Huff [mailto:mhuff at ox.com] 
Sent: Friday, November 08, 2013 12:49 PM
To: Robert Glover; NANOG Mailing List
Subject: RE: Cogent packet loss to Verizon in San Jose

This has been going on nationwide between Cogent and other peering partners since early 2013 (and in some cases before), but especially between Cogent and Verizon. It's not a technical problem, but a political one. 

We resolved our issue by working with our upsteam providers to reconfigure our routing and advertisements to avoid cogent, otherwise, I don't think there is any solution coming within a reasonable timeframe


----
Matthew Huff?            | 1 Manhattanville Rd
Director of Operations???| Purchase, NY 10577
OTA Management LLC       | Phone: 914-460-4039

> -----Original Message-----
> From: Robert Glover [mailto:robertg at garlic.com]
> Sent: Friday, November 08, 2013 12:30 PM
> To: NANOG Mailing List
> Subject: Cogent packet loss to Verizon in San Jose
> 
> Anyone from Cogent around?  Normal support channels aren't getting me 
> anywhere.
> 
> We have been seeing consistent packet loss to Verizon over Cogent in 
> San Jose for several days:
> 
> HOST: noc-auth1.garlic.com                           Loss%   Snt
> Last   Avg  Best  Wrst StDev
>   1. router.garlic.com                               0.0%    10    0.4
> 0.3   0.2   0.4   0.0
>   2. vl203.mag03.sfo01.atlas.cogentco.com            0.0%    10    2.2
> 2.3   2.1   2.4   0.1
>   3. te0-2-0-1.mpd21.sfo01.atlas.cogentco.com        0.0%    10    2.6
> 2.6   2.4   2.8   0.1
>   4. be2166.ccr21.sjc01.atlas.cogentco.com           0.0%    10    3.9
> 3.9   3.7   4.2   0.1
>   5. be2000.ccr21.sjc03.atlas.cogentco.com           0.0%    10    4.7
> 4.4   4.3   4.7   0.1
>   6. verizon.sjc03.atlas.cogentco.com               40.0%    10   80.0
> 80.8  79.9  81.8   0.7
>   7. so-1-0-0-0.SJC01-CORE-RTR1.verizon-gni.net      30.0%    10   82.2
> 87.9  81.1 114.6  11.3
>   8. A8-0-1710.SNFCCA-DSL-01.verizon-gni.net        30.0%    10   83.2
> 83.8  82.1  85.9   1.3
>   9. static-71-116-125-210.snfcca.dsl-w.verizon.net 20.0%    10  108.1
> 107.2 105.7 108.7   1.1
> 
> 
> We have had to route some customer's traffic out through our alternate 
> provider (AS20115), as their VPN's were borked by the packet loss.
> 
> Thanks,
> -Bobby



_______________________________________________________________________


This e-mail message and its attachments are for the sole use of the intended recipients.  They may contain confidential information, legally privileged information or other information subject to legal restrictions.  If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media.
-------------- next part --------------
An embedded message was scrubbed...
From: "Shaw, Matthew" <mshaw at fairpoint.com>
Subject: [outages]  Packetloss in Cogent at JFK
Date: Fri, 8 Nov 2013 16:24:56 +0000
Size: 5525
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131108/a6dcc3db/attachment.mht>

From sam at themerritts.org  Fri Nov  8 21:48:26 2013
From: sam at themerritts.org (Sam Hayes Merritt, III)
Date: Fri, 8 Nov 2013 15:48:26 -0600 (CST)
Subject: DNS and nxdomain hijacking
In-Reply-To: <CE9E9753.D7BC%wbailey@satelliteintelligencegroup.com>
References: <CE9E9753.D7BC%wbailey@satelliteintelligencegroup.com>
Message-ID: <alpine.DEB.2.02.1311081547130.22803@sam>


> Are any of you doing it?

At one time we did.

The money just wasn't worth the hassle.  I kept a close eye on our reports 
and the dollar amounts just kept falling. And IIRC, Google would not team 
with you to do it, you had to redirect to Yahoo or Bing.


sam


From cidr-report at potaroo.net  Fri Nov  8 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 8 Nov 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201311082200.rA8M00kA096852@wattle.apnic.net>

This report has been generated at Fri Nov  8 21:14:17 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        01-11-13    481734      272520
        02-11-13    481872      272864
        03-11-13    482183      272900
        04-11-13    482274      272490
        05-11-13    481743      272481
        06-11-13    481856      272607
        07-11-13    482236      272408
        08-11-13    482564      272297


AS Summary
         45540  Number of ASes in routing system
         18679  Number of ASes announcing only one prefix
          4204  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      118901504  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 08Nov13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     482675   272297   210378    43.6%   All ASes

AS28573     3445       86     3359    97.5%   NET Servi?os de Comunica??o
                                               S.A.
AS6389      3054       59     2995    98.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS17974     2710      162     2548    94.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS7029      4204     1727     2477    58.9%   WINDSTREAM - Windstream
                                               Communications Inc
AS22773     2195      152     2043    93.1%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4766      2934      951     1983    67.6%   KIXS-AS-KR Korea Telecom
AS10620     2648     1050     1598    60.3%   Telmex Colombia S.A.
AS18566     2056      566     1490    72.5%   MEGAPATH5-US - MegaPath
                                               Corporation
AS36998     1864      375     1489    79.9%   SDN-MOBITEL
AS18881     1548      100     1448    93.5%   Global Village Telecom
AS4323      2959     1537     1422    48.1%   TWTC - tw telecom holdings,
                                               inc.
AS7303      1727      468     1259    72.9%   Telecom Argentina S.A.
AS1785      2038      819     1219    59.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1788      577     1211    67.7%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1191      138     1053    88.4%   VIETEL-AS-AP Vietel
                                               Corporation
AS22561     1249      221     1028    82.3%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS7545      2114     1289      825    39.0%   TPG-INTERNET-AP TPG Telecom
                                               Limited
AS35908      912       92      820    89.9%   VPLSNET - Krypt Technologies
AS18101      982      180      802    81.7%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4788       848       67      781    92.1%   TMNET-AS-AP TM Net, Internet
                                               Service Provider
AS4808      1151      402      749    65.1%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS24560     1094      365      729    66.6%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS701       1507      785      722    47.9%   UUNET - MCI Communications
                                               Services, Inc. d/b/a Verizon
                                               Business
AS6983      1293      578      715    55.3%   ITCDELTA - ITC^Deltacom
AS8151      1367      654      713    52.2%   Uninet S.A. de C.V.
AS13977      852      143      709    83.2%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS8402      1912     1241      671    35.1%   CORBINA-AS OJSC "Vimpelcom"
AS855        724       55      669    92.4%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS4780      1000      332      668    66.8%   SEEDNET Digital United Inc.
AS26615      750       88      662    88.3%   Tim Celular S.A.

Total      54116    15259    38857    71.8%   Top 30 total


Possible Bogus Routes

        23.92.224.0/23       AS55048 VMWARE - VMware, Inc.
        23.92.226.0/23       AS55048 VMWARE - VMware, Inc.
        23.92.228.0/23       AS55048 VMWARE - VMware, Inc.
        23.92.230.0/23       AS55048 VMWARE - VMware, Inc.
        23.92.232.0/23       AS55048 VMWARE - VMware, Inc.
        27.54.116.0/22       AS55452 
        27.54.116.0/24       AS55452 
        27.54.119.0/24       AS55452 
        27.100.7.0/24        AS56096 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        63.247.0.0/19        AS226   LOS-NETTOS-AS - Los Nettos
        63.247.0.0/24        AS27609 
        63.247.1.0/24        AS27609 
        63.247.2.0/24        AS27609 
        63.247.3.0/24        AS27609 
        63.247.4.0/24        AS27609 
        63.247.5.0/24        AS27609 
        63.247.6.0/24        AS27609 
        63.247.7.0/24        AS27609 
        63.247.8.0/24        AS27609 
        63.247.9.0/24        AS27609 
        63.247.10.0/24       AS27609 
        63.247.11.0/24       AS27609 
        63.247.12.0/24       AS27609 
        63.247.13.0/24       AS27609 
        63.247.14.0/24       AS27609 
        63.247.15.0/24       AS27609 
        63.247.16.0/24       AS27609 
        63.247.17.0/24       AS27609 
        63.247.18.0/24       AS27609 
        63.247.19.0/24       AS27609 
        63.247.20.0/24       AS27609 
        63.247.21.0/24       AS27609 
        63.247.22.0/24       AS27609 
        63.247.23.0/24       AS27609 
        63.247.24.0/24       AS27609 
        63.247.25.0/24       AS27609 
        63.247.26.0/24       AS27609 
        63.247.27.0/24       AS27609 
        63.247.28.0/24       AS27609 
        63.247.29.0/24       AS27609 
        64.25.16.0/23        AS19535 
        64.25.20.0/24        AS19535 
        64.25.21.0/24        AS19535 
        64.25.22.0/24        AS19535 
        64.25.27.0/24        AS7046  RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business
        64.111.0.0/20        AS8039  CCC-ASN-1 - Cinergy Communications
        64.111.160.0/20      AS40551 
        64.111.160.0/24      AS40551 
        64.111.161.0/24      AS40551 
        64.111.162.0/24      AS40551 
        64.111.167.0/24      AS40551 
        64.111.169.0/24      AS40551 
        64.111.170.0/24      AS40551 
        64.111.171.0/24      AS40551 
        64.111.172.0/24      AS40551 
        64.111.173.0/24      AS40551 
        64.111.174.0/24      AS40551 
        64.111.175.0/24      AS40551 
        64.142.128.0/17      AS16415 
        64.142.236.0/24      AS18452 ALORICA - ALORICA INC
        64.142.239.0/24      AS18452 ALORICA - ALORICA INC
        64.185.224.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.225.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.226.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.227.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.228.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.229.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.230.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.231.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.232.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.233.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.234.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.235.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.236.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.237.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.238.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.239.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.202.48.0/22       AS23380 
        64.202.52.0/23       AS23380 
        64.202.54.0/24       AS23380 
        64.202.55.0/24       AS23380 
        64.202.56.0/22       AS23380 
        64.202.60.0/24       AS23380 
        64.202.61.0/24       AS23380 
        64.202.62.0/24       AS23380 
        64.202.63.0/24       AS23380 
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global
        66.11.112.0/20       AS14572 
        66.55.96.0/23        AS17203 
        66.55.98.0/24        AS17203 
        66.55.99.0/24        AS17203 
        66.55.100.0/22       AS17203 
        66.55.102.0/23       AS17203 
        66.55.104.0/21       AS17203 
        66.180.64.0/21       AS32558 ZEUTER - Zeuter Development Corporation
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.187.240.0/20      AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        66.206.208.0/22      AS23380 
        66.206.211.0/24      AS14288 MPINET - MPInet
        66.206.212.0/24      AS23380 
        66.206.213.0/24      AS14288 MPINET - MPInet
        66.206.214.0/24      AS23380 
        66.206.215.0/24      AS23380 
        66.206.216.0/23      AS14288 MPINET - MPInet
        66.206.218.0/23      AS23380 
        66.206.220.0/22      AS23380 
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.254.160.0/20      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.176.0/21      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.184.0/22      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.188.0/22      AS35916 MULTA-ASN1 - MULTACOM CORPORATION
        67.21.144.0/22       AS174   COGENT Cogent/PSI
        67.21.148.0/22       AS174   COGENT Cogent/PSI
        68.69.96.0/21        AS32986 
        68.69.96.0/24        AS32986 
        68.69.104.0/21       AS32986 
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.19.0.0/19         AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        72.35.224.0/22       AS30097 NUWAVE - NuWave
        72.35.229.0/24       AS30188 TELEVERGENCE - Televergence Solutions Inc.
        72.35.232.0/21       AS6246  AVALONTEL - AvalonTel
        72.44.16.0/20        AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC
        74.112.100.0/22      AS16764 
        74.113.200.0/23      AS46939 
        74.114.52.0/22       AS40818 
        74.114.140.0/22      AS32757 
        74.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        74.118.132.0/22      AS5117  
        91.193.60.0/22       AS3356  LEVEL3 Level 3 Communications
        91.195.66.0/23       AS3356  LEVEL3 Level 3 Communications
        91.197.36.0/22       AS43359 
        91.199.90.0/24       AS44330 
        91.200.188.0/22      AS44016 
        91.207.152.0/24      AS64100 
        91.207.153.0/24      AS64100 
        91.209.115.0/24      AS31103 KEYWEB-AS Keyweb AG
        91.212.54.0/24       AS21409 IKOULA Ikoula Net SAS
        93.190.8.0/24        AS47254 
        93.190.9.0/24        AS47254 
        93.190.10.0/24       AS47254 
        100.100.0.0/24       AS4847  CNIX-AP China Networks Inter-Exchange
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. 
        103.11.1.0/24        AS9822  AMNET-AU-AP Amnet IT Services Pty Ltd
        103.13.184.0/23      AS58674 
        115.166.130.0/23     AS45423 
        115.166.132.0/24     AS45423 
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        124.64.0.0/10        AS4847  CNIX-AP China Networks Inter-Exchange
        164.40.184.0/24      AS19821 
        164.138.96.0/23      AS58101 
        164.138.96.0/24      AS58101 
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.116.0.0/24       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        174.136.192.0/18     AS14572 
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA LTDA
        190.15.72.0/21       AS15146 CABLEBAHAMAS - Cable Bahamas
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        192.166.32.0/20      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        193.9.59.0/24        AS1257  TELE2
        193.22.224.0/20      AS3322  
        193.22.238.0/23      AS6824  HERMES-NETWORK Hermes Telecom International Ltd
        193.33.66.0/23       AS39874 
        193.109.15.0/24      AS12690 MKSNET-AS MKS Autonomous System
        193.164.152.0/24     AS3356  LEVEL3 Level 3 Communications
        193.178.217.0/24     AS20737 
        193.188.252.0/24     AS8697  JTC-AS8697 Jordan Telecommunications Company
        193.202.8.0/21       AS3322  
        193.254.218.0/23     AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC
        194.50.82.0/24       AS16276 OVH OVH Systems
        194.63.152.0/22      AS3356  LEVEL3 Level 3 Communications
        194.79.48.0/22       AS39117 
        194.113.27.0/24      AS12518 SHLINK SHLINK Internet Service
        194.126.219.0/24     AS34545 
        195.114.4.0/23       AS41158 
        195.128.240.0/23     AS21202 DCSNET-AS Bredband2 AB
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA
        195.234.156.0/24     AS25028 
        195.248.240.0/23     AS34169 MEDIA-COM-TYCHY Media-Com Sp. z o.o.
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.58.248.0/21      AS27849 
        201.71.16.0/20       AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.49.33.0/24       AS7657  VODAFONE-NZ-NGN-AS Vodafone NZ Ltd.
        202.58.113.0/24      AS19161 
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.86.216.0/23      AS38212 
        202.86.220.0/24      AS38212 
        202.86.222.0/24      AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.142.219.0/24     AS45149 
        203.191.48.0/20      AS24175 VINAREN-AS-AP VietNam Research and Education Network
        203.191.56.0/21      AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service
        204.9.32.0/24        AS25617 
        204.9.33.0/24        AS25617 
        204.9.34.0/24        AS25617 
        204.9.35.0/24        AS25617 
        204.9.116.0/22       AS30097 NUWAVE - NuWave
        204.10.88.0/21       AS3356  LEVEL3 Level 3 Communications
        204.10.92.0/23       AS30097 NUWAVE - NuWave
        204.10.94.0/23       AS30097 NUWAVE - NuWave
        204.15.208.0/22      AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC
        204.69.144.0/24      AS27283 RJF-INTERNET - Raymond James Financial, Inc.
        204.106.16.0/24      AS4323  TWTC - tw telecom holdings, inc.
        204.115.14.0/23      AS35910 
        204.115.101.0/24     AS35954 
        204.115.110.0/23     AS53709 
        204.115.250.0/24     AS32880 SMOOTHSTONE-IP-COMMUNICATIONS-CORP - Smoothstone IP Communications Corporation
        204.115.251.0/24     AS32880 SMOOTHSTONE-IP-COMMUNICATIONS-CORP - Smoothstone IP Communications Corporation
        204.115.252.0/23     AS32880 SMOOTHSTONE-IP-COMMUNICATIONS-CORP - Smoothstone IP Communications Corporation
        204.187.11.0/24      AS51113 ELEKTA-AS Elekta
        204.225.173.0/24     AS6407  PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
        205.159.44.0/24      AS40157 ADESA-CORP-AS - ADESA Corp
        205.207.66.0/24      AS15290 ALLST-15290 - Allstream Corp.
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network
        205.236.71.0/24      AS852   ASN852 - TELUS Communications Inc.
        206.81.112.0/20      AS32618 ADKNO-KC - Adknowledge, Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        206.221.176.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.177.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.178.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.179.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.180.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.181.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.182.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.183.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.184.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.185.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.186.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.187.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.188.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.189.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.190.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.191.0/24     AS27431 JTLNET - JTL Networks Inc.
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        207.254.128.0/21     AS30689 FLOW-NET - FLOW
        207.254.128.0/24     AS30689 FLOW-NET - FLOW
        207.254.136.0/21     AS30689 FLOW-NET - FLOW
        208.64.168.0/21      AS8121  TCH - TCH Network Services
        208.66.120.0/22      AS32757 
        208.66.225.0/24      AS3549  GBLX Global Crossing Ltd.
        208.66.227.0/24      AS3549  GBLX Global Crossing Ltd.
        208.68.180.0/22      AS4323  TWTC - tw telecom holdings, inc.
        208.69.24.0/23       AS4277  
        208.69.26.0/23       AS4277  
        208.74.224.0/22      AS174   COGENT Cogent/PSI
        208.75.152.0/21      AS32146 
        208.76.20.0/24       AS31812 
        208.76.21.0/24       AS31812 
        208.77.132.0/24      AS40273 
        208.77.164.0/24      AS22659 
        208.77.165.0/24      AS22659 
        208.77.166.0/24      AS22659 
        208.77.167.0/24      AS22659 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.84.232.0/24      AS33131 
        208.84.234.0/24      AS33131 
        208.84.237.0/24      AS33131 
        208.84.238.0/24      AS33131 
        208.85.116.0/23      AS25956 ALPHEUS - Alpheus Data Services, L.L.C.
        208.85.212.0/22      AS32618 ADKNO-KC - Adknowledge, Inc.
        208.89.32.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.33.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.34.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.35.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.80.0/23       AS23485 
        208.89.82.0/23       AS40569 YGOMI-AS - Ygomi LLC
        208.90.64.0/22       AS16415 
        208.91.72.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.73.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.76.0/23       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        208.91.164.0/22      AS46099 
        208.92.224.0/22      AS32757 
        208.117.128.0/18     AS36859 
        209.87.144.0/21      AS21919 
        209.87.152.0/22      AS21919 
        209.87.156.0/24      AS21919 
        209.87.157.0/24      AS21919 
        209.87.158.0/24      AS21919 
        209.87.159.0/24      AS21919 
        209.161.96.0/20      AS8039  CCC-ASN-1 - Cinergy Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.193.112.0/20     AS209   ASN-QWEST-US NOVARTIS-DMZ-US
        209.209.51.0/24      AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.
        209.209.64.0/20      AS46851 IPARADIGMS - iParadigms, LLC
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.234.112.0/23     AS32252 
        209.234.114.0/23     AS32252 
        209.234.116.0/24     AS32252 
        209.234.117.0/24     AS32252 
        209.234.118.0/24     AS32252 
        209.234.119.0/24     AS32252 
        209.234.120.0/24     AS32252 
        209.234.121.0/24     AS32252 
        209.234.122.0/24     AS32252 
        212.119.32.0/19      AS12550 
        213.184.64.0/24      AS13071 
        213.184.65.0/24      AS13071 
        213.184.66.0/24      AS13071 
        213.184.67.0/24      AS13071 
        213.184.68.0/24      AS13071 
        213.184.69.0/24      AS13071 
        213.184.70.0/24      AS13071 
        213.184.71.0/24      AS13071 
        213.184.72.0/24      AS13071 
        213.184.73.0/24      AS13071 
        213.184.74.0/24      AS13071 
        213.184.75.0/24      AS13071 
        213.184.76.0/24      AS13071 
        213.184.77.0/24      AS13071 
        213.184.78.0/24      AS13071 
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.14.64.0/20       AS14728 
        216.146.0.0/19       AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.170.96.0/24      AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.101.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.104.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.105.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.234.128.0/22     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.139.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Nov  8 22:00:02 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 8 Nov 2013 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201311082200.rA8M02oR096868@wattle.apnic.net>

BGP Update Report
Interval: 31-Oct-13 -to- 07-Nov-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS6407           178473  8.4%    6610.1 -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
 2 - AS30693           85995  4.1%     236.2 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 3 - AS9829            38135  1.8%      40.2 -- BSNL-NIB National Internet Backbone
 4 - AS8402            37309  1.8%      35.9 -- CORBINA-AS OJSC "Vimpelcom"
 5 - AS7303            27140  1.3%      17.1 -- Telecom Argentina S.A.
 6 - AS38457           26960  1.3%     359.5 -- HNS-AS-AP Honesty Net Solution (I) Pvt Ltd
 7 - AS29990           21261  1.0%    1518.6 -- ASN-APPNEXUS - AppNexus, Inc
 8 - AS13118           21067  1.0%    2340.8 -- ASN-YARTELECOM OJSC Rostelecom
 9 - AS35873           20191  0.9%   20191.0 -- MOVE-NETWORKS - Move Networks, inc.
10 - AS4775            16388  0.8%     268.7 -- GLOBE-TELECOM-AS Globe Telecoms
11 - AS29049           15528  0.7%      46.4 -- DELTA-TELECOM-AS Delta Telecom LTD.
12 - AS7029            13597  0.6%       9.3 -- WINDSTREAM - Windstream Communications Inc
13 - AS28573           13588  0.6%      11.7 -- NET Servi?os de Comunica??o S.A.
14 - AS57130           11915  0.6%    3971.7 -- SECPRAL-AS Secpral COM SRL
15 - AS7552            11227  0.5%       9.4 -- VIETEL-AS-AP Vietel Corporation
16 - AS4538            10899  0.5%      20.9 -- ERX-CERNET-BKB China Education and Research Network Center
17 - AS11976           10850  0.5%     339.1 -- FIDN - Fidelity Communication International Inc.
18 - AS3475             9727  0.5%     100.3 -- DNIC-AS-03475 - Navy Network Information Center (NNIC)
19 - AS14754            9397  0.4%      39.5 -- Telgua
20 - AS24863            9096  0.4%      20.0 -- LINKdotNET-AS


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS35873           20191  0.9%   20191.0 -- MOVE-NETWORKS - Move Networks, inc.
 2 - AS6629             8991  0.4%    8991.0 -- NOAA-AS - NOAA
 3 - AS6407           178473  8.4%    6610.1 -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
 4 - AS7202             8777  0.4%    4388.5 -- FAMU - Florida A & M University
 5 - AS57130           11915  0.6%    3971.7 -- SECPRAL-AS Secpral COM SRL
 6 - AS6174             6415  0.3%    3207.5 -- SPRINTLINK8 - Sprint
 7 - AS54465            8623  0.4%    2874.3 -- QPM-AS-1 - QuickPlay Media Inc.
 8 - AS13118           21067  1.0%    2340.8 -- ASN-YARTELECOM OJSC Rostelecom
 9 - AS32244            6936  0.3%    2312.0 -- LIQUID-WEB-INC - Liquid Web, Inc.
10 - AS62431            2091  0.1%    2091.0 -- NCSC-IE-AS National Cyber Security Centre
11 - AS1778             1840  0.1%    1840.0 -- DNIC-AS-01778 - DoD Network Information Center
12 - AS57109            1828  0.1%    1828.0 -- ASPROREVIZOR Pro-Revizor LLC.
13 - AS22592            3522  0.2%    1761.0 -- HBP - HBP, Inc.
14 - AS37367            1724  0.1%    1724.0 -- CALLKEY
15 - AS29990           21261  1.0%    1518.6 -- ASN-APPNEXUS - AppNexus, Inc
16 - AS23304            2808  0.1%    1404.0 -- DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
17 - AS144              6880  0.3%    1376.0 -- ATT-INTERNET - Lucent Technologies/Bell Laboratories
18 - AS6775             5881  0.3%    1176.2 -- BACKBONE_EHF_EUROPE Backbone ehf
19 - AS45808            1164  0.1%    1164.0 -- UTP-MY Bandar Seri Iskandar
20 - AS32528            2740  0.1%     913.3 -- ABBOTT Abbot Labs


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 103.243.220.0/22  21220  0.9%   AS29990 -- ASN-APPNEXUS - AppNexus, Inc
 2 - 109.161.64.0/20   21052  0.9%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 3 - 8.20.2.0/24       20191  0.9%   AS35873 -- MOVE-NETWORKS - Move Networks, inc.
 4 - 216.181.203.0/24  16752  0.8%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
 5 - 216.181.202.0/24  16752  0.8%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
 6 - 216.181.196.0/22  16752  0.8%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
 7 - 216.181.200.0/24  16752  0.8%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
 8 - 216.181.201.0/24  16752  0.8%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
 9 - 216.181.200.0/23  15779  0.7%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
10 - 216.181.202.0/23  15779  0.7%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
11 - 216.181.197.0/24  15779  0.7%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
12 - 216.181.198.0/24  15778  0.7%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
13 - 216.181.199.0/24  15778  0.7%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
14 - 216.181.196.0/24  15777  0.7%   AS6407  -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
15 - 23.90.5.0/24      13364  0.6%   AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
16 - 194.9.23.0/24     11911  0.5%   AS57130 -- SECPRAL-AS Secpral COM SRL
17 - 23.90.21.0/24     10773  0.5%   AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
18 - 192.58.232.0/24    8991  0.4%   AS6629  -- NOAA-AS - NOAA
19 - 206.152.15.0/24    8619  0.4%   AS54465 -- QPM-AS-1 - QuickPlay Media Inc.
20 - 120.28.62.0/24     8034  0.4%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From scline at riotgames.com  Sun Nov 10 02:41:13 2013
From: scline at riotgames.com (Sean Cline)
Date: Sun, 10 Nov 2013 02:41:13 +0000
Subject: Any issues with Verizon FIOS?
Message-ID: <3AFD19A37B32E2478AFFB0F6D811CCCA6FCA9C5E@EX10LAXMB05.riotgames.com>

Good evening everyone, for the past two days our customers using Verizon FIOS (residential) have been complaining about high latency or intermittent packetloss to several of our datacenters throughout the US.

We have been trying to get in contact with Verizon but since we don't directly peer with Verizon they have no obligation to answer us, we are not getting very far with them directly.

Here is a sample traceroutes, any information if you guys/girls are aware of would be super helpful :)

  1    <1 ms    <1 ms    <1 ms  Wireless_Broadband_Router.home [192.168.1.1]
  2     5 ms     5 ms     4 ms  96.243.154.1
  3     9 ms    11 ms    11 ms  G0-9-1-6.TAMPFL-LCR-22.verizon-gni.net [130.81.140.64]
  4    34 ms    10 ms     9 ms  so-4-0-0-0.TPA01-BB-RTR2.verizon-gni.net [130.81.199.28]
  5    96 ms    96 ms    78 ms  0.ae2.XL4.LAX15.ALTER.NET [140.222.227.21]
  6    63 ms    64 ms    64 ms  POS7-0-0.GW3.LAX15.ALTER.NET [152.63.112.109]
  7    77 ms    78 ms    78 ms  internapGIGE-gw.customer.alter.net [157.130.236.110]
  8    77 ms    77 ms    77 ms  border1.po2-20g-bbnet2.lax010.pnap.net [216.52.255.103]

  1     1 ms    <1 ms     1 ms  Wireless_Broadband_Router.home [192.168.1.1]
  2     5 ms     5 ms     5 ms  L100.NYCMNY-VFTTP-32.verizon-gni.net [71.125.61.1]
  3     8 ms     7 ms     7 ms  G1-15-2-5.NYCMNY-LCR-22.verizon-gni.net [130.81.218.58]
  4     7 ms     6 ms     6 ms  ae4-0.NY5030-BB-RTR1.verizon-gni.net [130.81.163.224]
  5    92 ms    91 ms    70 ms  0.xe-6-1-0.XL3.LAX15.ALTER.NET [152.63.112.146]
  6    71 ms    69 ms    71 ms  POS6-0-0.GW3.LAX15.ALTER.NET [152.63.112.105]
  7    81 ms    83 ms    83 ms  internapGIGE-gw.customer.alter.net [157.130.236.110]
  8    81 ms    81 ms    84 ms  border1.po2-20g-bbnet2.lax010.pnap.net [216.52.255.103]

From morrowc.lists at gmail.com  Sun Nov 10 03:39:04 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 9 Nov 2013 22:39:04 -0500
Subject: Any issues with Verizon FIOS?
In-Reply-To: <3AFD19A37B32E2478AFFB0F6D811CCCA6FCA9C5E@EX10LAXMB05.riotgames.com>
References: <3AFD19A37B32E2478AFFB0F6D811CCCA6FCA9C5E@EX10LAXMB05.riotgames.com>
Message-ID: <CAL9jLaZ+qviXteUBtjdQFGjybEORE3p7dAMM0TZb-4AZuS4eww@mail.gmail.com>

traceroute to where?
those two seem reasonable for x-country latencies
what protocol(s) and port(s) are a problem, had you tried hping3 to
test connectivity?

On Sat, Nov 9, 2013 at 9:41 PM, Sean Cline <scline at riotgames.com> wrote:
> Good evening everyone, for the past two days our customers using Verizon FIOS (residential) have been complaining about high latency or intermittent packetloss to several of our datacenters throughout the US.
>
> We have been trying to get in contact with Verizon but since we don't directly peer with Verizon they have no obligation to answer us, we are not getting very far with them directly.
>
> Here is a sample traceroutes, any information if you guys/girls are aware of would be super helpful :)
>
>   1    <1 ms    <1 ms    <1 ms  Wireless_Broadband_Router.home [192.168.1.1]
>   2     5 ms     5 ms     4 ms  96.243.154.1
>   3     9 ms    11 ms    11 ms  G0-9-1-6.TAMPFL-LCR-22.verizon-gni.net [130.81.140.64]
>   4    34 ms    10 ms     9 ms  so-4-0-0-0.TPA01-BB-RTR2.verizon-gni.net [130.81.199.28]
>   5    96 ms    96 ms    78 ms  0.ae2.XL4.LAX15.ALTER.NET [140.222.227.21]
>   6    63 ms    64 ms    64 ms  POS7-0-0.GW3.LAX15.ALTER.NET [152.63.112.109]
>   7    77 ms    78 ms    78 ms  internapGIGE-gw.customer.alter.net [157.130.236.110]
>   8    77 ms    77 ms    77 ms  border1.po2-20g-bbnet2.lax010.pnap.net [216.52.255.103]
>
>   1     1 ms    <1 ms     1 ms  Wireless_Broadband_Router.home [192.168.1.1]
>   2     5 ms     5 ms     5 ms  L100.NYCMNY-VFTTP-32.verizon-gni.net [71.125.61.1]
>   3     8 ms     7 ms     7 ms  G1-15-2-5.NYCMNY-LCR-22.verizon-gni.net [130.81.218.58]
>   4     7 ms     6 ms     6 ms  ae4-0.NY5030-BB-RTR1.verizon-gni.net [130.81.163.224]
>   5    92 ms    91 ms    70 ms  0.xe-6-1-0.XL3.LAX15.ALTER.NET [152.63.112.146]
>   6    71 ms    69 ms    71 ms  POS6-0-0.GW3.LAX15.ALTER.NET [152.63.112.105]
>   7    81 ms    83 ms    83 ms  internapGIGE-gw.customer.alter.net [157.130.236.110]
>   8    81 ms    81 ms    84 ms  border1.po2-20g-bbnet2.lax010.pnap.net [216.52.255.103]


From mike-nanog at tiedyenetworks.com  Tue Nov 12 05:56:47 2013
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Mon, 11 Nov 2013 21:56:47 -0800
Subject: CPE  dns hijacking malware
Message-ID: <5281C31F.5080503@tiedyenetworks.com>

Hi,

It appears that some of my subscribers DSL modems (which are acting as 
nat routers) have had their dns settings hijacked and presumably for 
serving ads or some such nonsense. The dns server addresses are 
statically programmed in and of the onces I have seen, they are not 
currently responsive, leading to slow page loads or 404 errors and hence 
tech support calls to my support desk. I have set up a resolver that 
will answer dns queries and have done some routing magic to re-direct 
queries sent from my customer CPE's to these hijacked dns addresses. 
This is working for the time being and affected clients don't know about 
the problem (yet).

I realise it's highly likely there are more than just the 2 addresses I 
have identified so far in the realm of dns hijackers, and so I am
I am wondering if anyone has a line on dns server addresses that have 
been used or are currently in use for dns redirecting malware. I would 
like to maybe script something so that addresses on such a list would 
automatically get dropped into a routing table pointing at my special 
dns resolver. In the future I would also likely set up some sort of web 
redirect so that any client that queries the special resolver would get 
a web page explaining they have been hijacked and how to handle it. For 
now however I just want to stem the tide and make sure clients continue 
to work and to catch as many of these as I can. Anyone ?

Mike-


From rdobbins at arbor.net  Tue Nov 12 06:12:13 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 12 Nov 2013 06:12:13 +0000
Subject: CPE  dns hijacking malware
In-Reply-To: <5281C31F.5080503@tiedyenetworks.com>
References: <5281C31F.5080503@tiedyenetworks.com>
Message-ID: <E8875728-F9AE-464A-A828-8C331CA38886@arbor.net>


On Nov 12, 2013, at 12:56 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:

> It appears that some of my subscribers DSL modems (which are acting as nat routers) have had their dns settings hijacked and presumably for serving ads or some such nonsense. 

How do you think this was accomplished?  Via some kind of Web exploit customized for those devices and targeting your user population via email or social media, which tricked users into clicking on something that accessed the Web admin interface via default admin credentials or somsesuch; or via some direct attack on the CPE devices themselves; or via some other method?

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From jeff-kell at utc.edu  Tue Nov 12 06:17:51 2013
From: jeff-kell at utc.edu (Jeff Kell)
Date: Tue, 12 Nov 2013 01:17:51 -0500
Subject: CPE  dns hijacking malware
In-Reply-To: <E8875728-F9AE-464A-A828-8C331CA38886@arbor.net>
References: <5281C31F.5080503@tiedyenetworks.com>
 <E8875728-F9AE-464A-A828-8C331CA38886@arbor.net>
Message-ID: <5281C80F.1070908@utc.edu>

On 11/12/2013 1:12 AM, Dobbins, Roland wrote:
> On Nov 12, 2013, at 12:56 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
>
>> It appears that some of my subscribers DSL modems (which are acting as nat routers) have had their dns settings hijacked and presumably for serving ads or some such nonsense. 
> How do you think this was accomplished?  Via some kind of Web exploit customized for those devices and targeting your user population via email or social media, which tricked users into clicking on something that accessed the Web admin interface via default admin credentials or somsesuch; or via some direct attack on the CPE devices themselves; or via some other method?

Basically two cases...  (1) XSS attack on the router using default (or
dictionary) credentials to set the DNS server on the router, or (2) DHCP
hijacking daemon installed on the client, supplying the hijacker's DNS
servers on a DHCP renewal.  Have seen both, the latter being more
common, and the latter will expand across the entire home subnet in time
(based on your lease interval)

Jeff



From rdobbins at arbor.net  Tue Nov 12 06:35:51 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 12 Nov 2013 06:35:51 +0000
Subject: CPE  dns hijacking malware
In-Reply-To: <5281C80F.1070908@utc.edu>
References: <5281C31F.5080503@tiedyenetworks.com>
 <E8875728-F9AE-464A-A828-8C331CA38886@arbor.net> <5281C80F.1070908@utc.edu>
Message-ID: <8A641596-C43E-497C-B736-C794C3250930@arbor.net>


On Nov 12, 2013, at 1:17 PM, Jeff Kell <jeff-kell at utc.edu> wrote:

> (2) DHCP hijacking daemon installed on the client, supplying the hijacker's DNS servers on a DHCP renewal.  Have seen both, the latter being more
> common, and the latter will expand across the entire home subnet in time (based on your lease interval)

I'd (perhaps wrongly) assumed that this probably wasn't the case, as the OP referred to the CPE devices themselves as being malconfigured; it would be helpful to know if the OP can supply more information, and whether or not he'd a chance to examine the affected CPE/end-customer setups.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From mgalgoci at redhat.com  Tue Nov 12 15:57:20 2013
From: mgalgoci at redhat.com (Matthew Galgoci)
Date: Tue, 12 Nov 2013 15:57:20 +0000 (UTC)
Subject: CPE  dns hijacking malware
In-Reply-To: <8A641596-C43E-497C-B736-C794C3250930@arbor.net>
References: <5281C31F.5080503@tiedyenetworks.com>
 <E8875728-F9AE-464A-A828-8C331CA38886@arbor.net> <5281C80F.1070908@utc.edu>
 <8A641596-C43E-497C-B736-C794C3250930@arbor.net>
Message-ID: <alpine.LRH.2.03.1311121551210.16092@erqung.pbz>

> Date: Tue, 12 Nov 2013 06:35:51 +0000
> From: "Dobbins, Roland" <rdobbins at arbor.net>
> To: NANOG list <nanog at nanog.org>
> Subject: Re: CPE  dns hijacking malware
>
>
> On Nov 12, 2013, at 1:17 PM, Jeff Kell <jeff-kell at utc.edu> wrote:
>
> > (2) DHCP hijacking daemon installed on the client, supplying the hijacker's DNS servers on a DHCP renewal.  Have seen both, the latter being more
> > common, and the latter will expand across the entire home subnet in time (based on your lease interval)
>
> I'd (perhaps wrongly) assumed that this probably wasn't the case, as the OP referred to the CPE devices themselves as being malconfigured; it would be helpful to know if the OP can supply more information, and whether or not he'd a chance to examine the affected CPE/end-customer setups.
>

I have encountered a family members provider supplied CPE that had the
web server exposed on the public interface with default credentials still
in place. It's probably more common than one would expect.

-- 
Matthew Galgoci
Network Operations
Red Hat, Inc
919.754.3700 x44155
------------------------------
"It's not whether you get knocked down, it's whether you get up." - Vince Lombardi


From rdobbins at arbor.net  Tue Nov 12 16:40:02 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 12 Nov 2013 16:40:02 +0000
Subject: CPE  dns hijacking malware
In-Reply-To: <alpine.LRH.2.03.1311121551210.16092@erqung.pbz>
References: <5281C31F.5080503@tiedyenetworks.com>
 <E8875728-F9AE-464A-A828-8C331CA38886@arbor.net> <5281C80F.1070908@utc.edu>
 <8A641596-C43E-497C-B736-C794C3250930@arbor.net>
 <alpine.LRH.2.03.1311121551210.16092@erqung.pbz>
Message-ID: <6BA074E1-B578-4486-AC28-117AB9DC05FF@arbor.net>


On Nov 12, 2013, at 10:57 PM, Matthew Galgoci <mgalgoci at redhat.com> wrote:

> It's probably more common than one would expect.

Concur 100%.

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

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From blueneon at gmail.com  Tue Nov 12 17:58:46 2013
From: blueneon at gmail.com (Tom Morris)
Date: Tue, 12 Nov 2013 12:58:46 -0500
Subject: CPE dns hijacking malware
In-Reply-To: <alpine.LRH.2.03.1311121551210.16092@erqung.pbz>
References: <5281C31F.5080503@tiedyenetworks.com>
 <E8875728-F9AE-464A-A828-8C331CA38886@arbor.net>
 <5281C80F.1070908@utc.edu> <8A641596-C43E-497C-B736-C794C3250930@arbor.net>
 <alpine.LRH.2.03.1311121551210.16092@erqung.pbz>
Message-ID: <CAEZ7Lt2a0-JR13NHe3JOxeDr860LcyfA-6uNfpnAcJ24=2dKTA@mail.gmail.com>

EXTREMELY common. Almost all Comcast Cable CPE has this same login,
cusadmin / highspeed
At least on AT&T U-Verse gear, there's a sticker on the modem with the
password which is a hash of the serial number or something equally unique.

Almost all home routers also tend to have the default credentials.

I'm actually surprised it was this long before XSS exploits and similar
garbage started hitting them.

Personally I have fond memories of going into my neighbor's router,
flashing it with dd-wrt which allowed manual channel setting, and moving it
off of the same wifi channel mine was on.... That was probably not a great
idea, but you do what you have to sometimes.


On Tue, Nov 12, 2013 at 10:57 AM, Matthew Galgoci <mgalgoci at redhat.com>wrote:

> > Date: Tue, 12 Nov 2013 06:35:51 +0000
> > From: "Dobbins, Roland" <rdobbins at arbor.net>
> > To: NANOG list <nanog at nanog.org>
> > Subject: Re: CPE  dns hijacking malware
> >
> >
> > On Nov 12, 2013, at 1:17 PM, Jeff Kell <jeff-kell at utc.edu> wrote:
> >
> > > (2) DHCP hijacking daemon installed on the client, supplying the
> hijacker's DNS servers on a DHCP renewal.  Have seen both, the latter being
> more
> > > common, and the latter will expand across the entire home subnet in
> time (based on your lease interval)
> >
> > I'd (perhaps wrongly) assumed that this probably wasn't the case, as the
> OP referred to the CPE devices themselves as being malconfigured; it would
> be helpful to know if the OP can supply more information, and whether or
> not he'd a chance to examine the affected CPE/end-customer setups.
> >
>
> I have encountered a family members provider supplied CPE that had the
> web server exposed on the public interface with default credentials still
> in place. It's probably more common than one would expect.
>
> --
> Matthew Galgoci
> Network Operations
> Red Hat, Inc
> 919.754.3700 x44155
> ------------------------------
> "It's not whether you get knocked down, it's whether you get up." - Vince
> Lombardi
>
>


-- 
--
Tom Morris, KG4CYX
Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz!
786-228-7087
151.820 Megacycles

From landonstewart at gmail.com  Tue Nov 12 19:21:00 2013
From: landonstewart at gmail.com (Landon)
Date: Tue, 12 Nov 2013 11:21:00 -0800
Subject: Do you obfuscate email headers when reporting spam issues to
 clients?
In-Reply-To: <CANF7DYe3Pedm6QfWv3YWxL8=fRd=aSNdSyBqp3pctFsuP-ehOg@mail.gmail.com>
References: <CABgOHgvOjdyk8Wg6zh7D6m2JrBa1ErQhqMHQX3=2XuY9HE_zGg@mail.gmail.com>
 <Pine.LNX.4.61.1311061927280.17328@soloth.lewis.org>
 <20131107184300.GA24905@gsp.org>
 <CAJvB4t=KE4HdfrfJB28LCrOGOsfcdGySSJYKboMzHesyd9MMmg@mail.gmail.com>
 <CANF7DYe3Pedm6QfWv3YWxL8=fRd=aSNdSyBqp3pctFsuP-ehOg@mail.gmail.com>
Message-ID: <CABgOHgvTNaQ-U1D7gQXp98Jra6jCZaDxo4rJ_W_RwjrZ06PSZw@mail.gmail.com>

Hello NANOG,

Just a quick note thanking those that responded to me on and off list.  I
appreciate the input!

-- 
Landon Stewart <LandonStewart at Gmail.com>

From james.sink at freedomvoice.com  Tue Nov 12 21:18:10 2013
From: james.sink at freedomvoice.com (James Sink)
Date: Tue, 12 Nov 2013 21:18:10 +0000
Subject: CPE dns hijacking malware
In-Reply-To: <CAEZ7Lt2a0-JR13NHe3JOxeDr860LcyfA-6uNfpnAcJ24=2dKTA@mail.gmail.com>
References: <5281C31F.5080503@tiedyenetworks.com>
 <E8875728-F9AE-464A-A828-8C331CA38886@arbor.net> <5281C80F.1070908@utc.edu>
 <8A641596-C43E-497C-B736-C794C3250930@arbor.net>
 <alpine.LRH.2.03.1311121551210.16092@erqung.pbz>
 <CAEZ7Lt2a0-JR13NHe3JOxeDr860LcyfA-6uNfpnAcJ24=2dKTA@mail.gmail.com>
Message-ID: <2ea639605b93460eb947ed24f8ae7d9f@BL2PR08MB148.namprd08.prod.outlook.com>

"Personally I have fond memories of going into my neighbor's router, flashing it with dd-wrt which allowed manual channel setting, and moving it off of the same wifi channel mine was on.... That was probably not a great idea, but you do what you have to sometimes."

Props on that, but wouldn't it have been easier to simply change your channel setting?
-James

-----Original Message-----
From: Tom Morris [mailto:blueneon at gmail.com] 
Sent: Tuesday, November 12, 2013 9:59 AM
Cc: NANOG list
Subject: Re: CPE dns hijacking malware

EXTREMELY common. Almost all Comcast Cable CPE has this same login, cusadmin / highspeed At least on AT&T U-Verse gear, there's a sticker on the modem with the password which is a hash of the serial number or something equally unique.

Almost all home routers also tend to have the default credentials.

I'm actually surprised it was this long before XSS exploits and similar garbage started hitting them.

Personally I have fond memories of going into my neighbor's router, flashing it with dd-wrt which allowed manual channel setting, and moving it off of the same wifi channel mine was on.... That was probably not a great idea, but you do what you have to sometimes.


On Tue, Nov 12, 2013 at 10:57 AM, Matthew Galgoci <mgalgoci at redhat.com>wrote:

> > Date: Tue, 12 Nov 2013 06:35:51 +0000
> > From: "Dobbins, Roland" <rdobbins at arbor.net>
> > To: NANOG list <nanog at nanog.org>
> > Subject: Re: CPE  dns hijacking malware
> >
> >
> > On Nov 12, 2013, at 1:17 PM, Jeff Kell <jeff-kell at utc.edu> wrote:
> >
> > > (2) DHCP hijacking daemon installed on the client, supplying the
> hijacker's DNS servers on a DHCP renewal.  Have seen both, the latter 
> being more
> > > common, and the latter will expand across the entire home subnet 
> > > in
> time (based on your lease interval)
> >
> > I'd (perhaps wrongly) assumed that this probably wasn't the case, as 
> > the
> OP referred to the CPE devices themselves as being malconfigured; it 
> would be helpful to know if the OP can supply more information, and 
> whether or not he'd a chance to examine the affected CPE/end-customer setups.
> >
>
> I have encountered a family members provider supplied CPE that had the 
> web server exposed on the public interface with default credentials 
> still in place. It's probably more common than one would expect.
>
> --
> Matthew Galgoci
> Network Operations
> Red Hat, Inc
> 919.754.3700 x44155
> ------------------------------
> "It's not whether you get knocked down, it's whether you get up." - 
> Vince Lombardi
>
>


--
--
Tom Morris, KG4CYX
Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz!
786-228-7087
151.820 Megacycles


From jonas at bjorklund.cn  Tue Nov 12 21:58:52 2013
From: jonas at bjorklund.cn (=?ISO-8859-1?Q?Jonas_Bj=F6rklund?=)
Date: Tue, 12 Nov 2013 22:58:52 +0100 (CET)
Subject: Automatic abuse reports
Message-ID: <Pine.LNX.4.64.1311122255060.7242@crisp>

Hello,

We got often abuse reports on hosts that has been involved in DDOS attacks.
We contact the owner of the host help them fix the problem.

I also would like to start send these abuse report to the ISP of the source.

Are there any avaliable tools for this? Is there any plugin for nfsen?

Do I need to write my own scripts for this?

/Jonas


From sam at circlenet.us  Tue Nov 12 21:52:05 2013
From: sam at circlenet.us (Sam Moats)
Date: Tue, 12 Nov 2013 16:52:05 -0500
Subject: Automatic abuse reports
In-Reply-To: <Pine.LNX.4.64.1311122255060.7242@crisp>
References: <Pine.LNX.4.64.1311122255060.7242@crisp>
Message-ID: <8e46e18f60fef97dae75f61b4698fcf3@www.circlenet.us>

We used to use a small perl script called tattle that would parse out 
the /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, 
lookup the proper abuse contacts and report them. I haven't seen 
anything similar in years but it would be interesting to do more than 
null route IPs.

The problem we had with the automated reporting was dealing with 
spoofed sources, we see lots of traffic that is obviously hostile but 
unless it becomes serious enough to impact performance we rarely report 
it. An automated system didn't seem to fit anymore due to false 
positives.

A number of providers who aren't exactly interested in the overall good 
health of the net do a poor job of network ingress filtering that unless 
I closely examine the traffic and it's origins. Without being able to 
trust the source address information in the DDOS traffic I run the risk 
of crying wolf to a provider who is just as much a victim as I am. 
(Think of my ACK packets piling in his network in response to the bogus 
SYN packets I'm getting). So we reserve complaints for when there is an 
actual impact and try to keep the signal to noise ratio in our reports 
decent.

I'm not really happy with this approach and I'm open to ideas!

Thanks
Sam Moats

On 2013-11-12 16:58, Jonas Bj?rklund wrote:
> Hello,
>
> We got often abuse reports on hosts that has been involved in DDOS 
> attacks.
> We contact the owner of the host help them fix the problem.
>
> I also would like to start send these abuse report to the ISP of the 
> source.
>
> Are there any avaliable tools for this? Is there any plugin for 
> nfsen?
>
> Do I need to write my own scripts for this?
>
> /Jonas


From LarrySheldon at cox.net  Tue Nov 12 21:54:19 2013
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Tue, 12 Nov 2013 15:54:19 -0600
Subject: CPE  dns hijacking malware
In-Reply-To: <52829C8D.7000805@cox.net>
References: <5281C31F.5080503@tiedyenetworks.com> <oWD81m00L1Una3W01WD99T>
 <52829C8D.7000805@cox.net>
Message-ID: <5282A38B.3060107@cox.net>

On 11/12/2013 3:24 PM, Larry Sheldon wrote:
> On 11/12/2013 12:12 AM, Dobbins, Roland wrote:
>>
>> On Nov 12, 2013, at 12:56 PM, Mike <mike-nanog at tiedyenetworks.com>
>> wrote:
>>
>>> It appears that some of my subscribers DSL modems (which are acting
>>> as nat routers) have had their dns settings hijacked and presumably
>>> for serving ads or some such nonsense.
>>
>> How do you think this was accomplished?  Via some kind of Web exploit
>> customized for those devices and targeting your user population via
>> email or social media, which tricked users into clicking on something
>> that accessed the Web admin interface via default admin credentials
>> or somsesuch; or via some direct attack on the CPE devices
>> themselves; or via some other method?
>
> I am less well informed here than in a lot of other things, so please be
> gentle.
>
> As a user of such equipment, I don't see or know of anything in the I/F
> that I have access-to that mentions DNSish stuff except the servers I am
> to use.
>
> But interestingly enough, when I tried to look at it to verify my
> belief's just no I got a certificate error that it won't let me past.
>
> That seems odd.
>

Meant to send this to the list.

The on-line chat to Linksys was subsatisfying, but for want of something 
to do I dropped the "s" IN "https" and go on the router just fine. 
Makes you wonder if I understand "certificates".

But I do not see anything that looks like I can affect DNS beyond which 
servers I use.
-- 
Requiescas in pace o email           Two identifying characteristics
                                         of System Administrators:
Ex turpi causa non oritur actio      Infallibility, and the ability to
                                         learn from their mistakes.
                                           (Adapted from Stephen Pinker)


From LarrySheldon at cox.net  Tue Nov 12 21:59:58 2013
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Tue, 12 Nov 2013 15:59:58 -0600
Subject: CPE  dns hijacking malware
In-Reply-To: <olxv1m00J1Una3W01lxwxX>
References: <5281C31F.5080503@tiedyenetworks.com> <oWD81m00L1Una3W01WD99T>
 <52829C8D.7000805@cox.net> <olxv1m00J1Una3W01lxwxX>
Message-ID: <5282A4DE.60205@cox.net>

On 11/12/2013 3:54 PM, Larry Sheldon wrote:
> On 11/12/2013 3:24 PM, Larry Sheldon wrote:
>> On 11/12/2013 12:12 AM, Dobbins, Roland wrote:
>>>
>>> On Nov 12, 2013, at 12:56 PM, Mike <mike-nanog at tiedyenetworks.com>
>>> wrote:
>>>
>>>> It appears that some of my subscribers DSL modems (which are acting
>>>> as nat routers) have had their dns settings hijacked and presumably
>>>> for serving ads or some such nonsense.
>>>
>>> How do you think this was accomplished?  Via some kind of Web exploit
>>> customized for those devices and targeting your user population via
>>> email or social media, which tricked users into clicking on something
>>> that accessed the Web admin interface via default admin credentials
>>> or somsesuch; or via some direct attack on the CPE devices
>>> themselves; or via some other method?
>>
>> I am less well informed here than in a lot of other things, so please be
>> gentle.
>>
>> As a user of such equipment, I don't see or know of anything in the I/F
>> that I have access-to that mentions DNSish stuff except the servers I am
>> to use.
>>
>> But interestingly enough, when I tried to look at it to verify my
>> belief's just no I got a certificate error that it won't let me past.
>>
>> That seems odd.
>>
>
> Meant to send this to the list.
>
> The on-line chat to Linksys was subsatisfying, but for want of something
> to do I dropped the "s" IN "https" and go on the router just fine. Makes
> you wonder if I understand "certificates".
>
> But I do not see anything that looks like I can affect DNS beyond which
> servers I use.

And I don't know a way to get on Cox's "cable modem" at all.



-- 
Requiescas in pace o email           Two identifying characteristics
                                         of System Administrators:
Ex turpi causa non oritur actio      Infallibility, and the ability to
                                         learn from their mistakes.
                                           (Adapted from Stephen Pinker)


From jeroen at massar.ch  Tue Nov 12 22:01:23 2013
From: jeroen at massar.ch (Jeroen Massar)
Date: Tue, 12 Nov 2013 17:01:23 -0500
Subject: Automatic abuse reports
In-Reply-To: <Pine.LNX.4.64.1311122255060.7242@crisp>
References: <Pine.LNX.4.64.1311122255060.7242@crisp>
Message-ID: <5282A533.9060407@massar.ch>

On 2013-11-12 16:58, Jonas Bj?rklund wrote:
> Hello,
> 
> We got often abuse reports on hosts that has been involved in DDOS attacks.
> We contact the owner of the host help them fix the problem.
> 
> I also would like to start send these abuse report to the ISP of the
> source.
> 
> Are there any avaliable tools for this? Is there any plugin for nfsen?

Look at anything related to IODEF, specifically the CIF implementation:
 https://code.google.com/p/collective-intelligence-framework/

Greets,
 Jeroen



From blueneon at gmail.com  Tue Nov 12 22:54:20 2013
From: blueneon at gmail.com (Tom Morris)
Date: Tue, 12 Nov 2013 17:54:20 -0500
Subject: CPE dns hijacking malware
In-Reply-To: <2ea639605b93460eb947ed24f8ae7d9f@BL2PR08MB148.namprd08.prod.outlook.com>
References: <5281C31F.5080503@tiedyenetworks.com>
 <E8875728-F9AE-464A-A828-8C331CA38886@arbor.net>
 <5281C80F.1070908@utc.edu> <8A641596-C43E-497C-B736-C794C3250930@arbor.net>
 <alpine.LRH.2.03.1311121551210.16092@erqung.pbz>
 <CAEZ7Lt2a0-JR13NHe3JOxeDr860LcyfA-6uNfpnAcJ24=2dKTA@mail.gmail.com>
 <2ea639605b93460eb947ed24f8ae7d9f@BL2PR08MB148.namprd08.prod.outlook.com>
Message-ID: <CAEZ7Lt22DFcf=LoNzsiOae4b+maztd22FQgSqxHx6gSVa+3AYw@mail.gmail.com>

As I recall, the unit in question had a severely flawed "auto" channel
selection algorithm that always, without fail, landed on the first OCCUPIED
channel. It was pretty terrible.


On Tue, Nov 12, 2013 at 4:18 PM, James Sink <james.sink at freedomvoice.com>wrote:

> "Personally I have fond memories of going into my neighbor's router,
> flashing it with dd-wrt which allowed manual channel setting, and moving it
> off of the same wifi channel mine was on.... That was probably not a great
> idea, but you do what you have to sometimes."
>
> Props on that, but wouldn't it have been easier to simply change your
> channel setting?
> -James
>
> -----Original Message-----
> From: Tom Morris [mailto:blueneon at gmail.com]
> Sent: Tuesday, November 12, 2013 9:59 AM
> Cc: NANOG list
> Subject: Re: CPE dns hijacking malware
>
> EXTREMELY common. Almost all Comcast Cable CPE has this same login,
> cusadmin / highspeed At least on AT&T U-Verse gear, there's a sticker on
> the modem with the password which is a hash of the serial number or
> something equally unique.
>
> Almost all home routers also tend to have the default credentials.
>
> I'm actually surprised it was this long before XSS exploits and similar
> garbage started hitting them.
>
> Personally I have fond memories of going into my neighbor's router,
> flashing it with dd-wrt which allowed manual channel setting, and moving it
> off of the same wifi channel mine was on.... That was probably not a great
> idea, but you do what you have to sometimes.
>
>
> On Tue, Nov 12, 2013 at 10:57 AM, Matthew Galgoci <mgalgoci at redhat.com
> >wrote:
>
> > > Date: Tue, 12 Nov 2013 06:35:51 +0000
> > > From: "Dobbins, Roland" <rdobbins at arbor.net>
> > > To: NANOG list <nanog at nanog.org>
> > > Subject: Re: CPE  dns hijacking malware
> > >
> > >
> > > On Nov 12, 2013, at 1:17 PM, Jeff Kell <jeff-kell at utc.edu> wrote:
> > >
> > > > (2) DHCP hijacking daemon installed on the client, supplying the
> > hijacker's DNS servers on a DHCP renewal.  Have seen both, the latter
> > being more
> > > > common, and the latter will expand across the entire home subnet
> > > > in
> > time (based on your lease interval)
> > >
> > > I'd (perhaps wrongly) assumed that this probably wasn't the case, as
> > > the
> > OP referred to the CPE devices themselves as being malconfigured; it
> > would be helpful to know if the OP can supply more information, and
> > whether or not he'd a chance to examine the affected CPE/end-customer
> setups.
> > >
> >
> > I have encountered a family members provider supplied CPE that had the
> > web server exposed on the public interface with default credentials
> > still in place. It's probably more common than one would expect.
> >
> > --
> > Matthew Galgoci
> > Network Operations
> > Red Hat, Inc
> > 919.754.3700 x44155
> > ------------------------------
> > "It's not whether you get knocked down, it's whether you get up." -
> > Vince Lombardi
> >
> >
>
>
> --
> --
> Tom Morris, KG4CYX
> Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz!
> 786-228-7087
> 151.820 Megacycles
>
>


-- 
--
Tom Morris, KG4CYX
Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz!
786-228-7087
151.820 Megacycles

From jared at puck.nether.net  Tue Nov 12 23:11:04 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 12 Nov 2013 16:11:04 -0700
Subject: CPE dns hijacking malware
In-Reply-To: <2ea639605b93460eb947ed24f8ae7d9f@BL2PR08MB148.namprd08.prod.outlook.com>
References: <5281C31F.5080503@tiedyenetworks.com>
 <E8875728-F9AE-464A-A828-8C331CA38886@arbor.net> <5281C80F.1070908@utc.edu>
 <8A641596-C43E-497C-B736-C794C3250930@arbor.net>
 <alpine.LRH.2.03.1311121551210.16092@erqung.pbz>
 <CAEZ7Lt2a0-JR13NHe3JOxeDr860LcyfA-6uNfpnAcJ24=2dKTA@mail.gmail.com>
 <2ea639605b93460eb947ed24f8ae7d9f@BL2PR08MB148.namprd08.prod.outlook.com>
Message-ID: <199E921C-50CB-441B-A2F3-29C88CE7988E@puck.nether.net>

Someone has to move. The defaults are really bad in dense deployments of 1,6,11. Always fun when we went to Japan in the early days and our equipment could not see channel 13 :-)

Most need more fhss than single channel stuff. 

Jared Mauch

> On Nov 12, 2013, at 2:18 PM, James Sink <james.sink at freedomvoice.com> wrote:
> 
> Props on that, but wouldn't it have been easier to simply change your channel setting?


From daniel.crompton at gmail.com  Wed Nov 13 00:15:13 2013
From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=)
Date: Wed, 13 Nov 2013 01:15:13 +0100
Subject: Automatic abuse reports
In-Reply-To: <8e46e18f60fef97dae75f61b4698fcf3@www.circlenet.us>
References: <Pine.LNX.4.64.1311122255060.7242@crisp>
 <8e46e18f60fef97dae75f61b4698fcf3@www.circlenet.us>
Message-ID: <CALKmEuBSTqZ590XD3tEThjWp_JkywFmCRQ_9TgRKTqVoCKGX=A@mail.gmail.com>

On 12 November 2013 22:52, Sam Moats <sam at circlenet.us> wrote:

> We used to use a small perl script called tattle that would parse out the
> /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, lookup
> the proper abuse contacts and report them. I haven't seen anything similar
> in years but it would be interesting to do more than null route IPs.


We also used to have a script which did something similar but for more than
just inbound ssh, for the most part this was ineffective.

D.


blaze your trail

-- 
Dani?l W. Crompton <daniel.crompton at gmail.com>

<http://specialbrands.net/>

<http://specialbrands.net/>
http://specialbrands.net/

       <http://twitter.com/webhat>
<http://www.facebook.com/webhat><http://plancast.com/webhat><http://www.linkedin.com/in/redhat>

From randy at psg.com  Wed Nov 13 00:48:15 2013
From: randy at psg.com (Randy Bush)
Date: Wed, 13 Nov 2013 09:48:15 +0900
Subject: Automatic abuse reports
In-Reply-To: <Pine.LNX.4.64.1311122255060.7242@crisp>
References: <Pine.LNX.4.64.1311122255060.7242@crisp>
Message-ID: <m2siv1t9dc.wl%randy@psg.com>

> I also would like to start send these abuse report to the ISP of the
> source.

good idea.  we all need more entries in our .procmailrcs

randy


From bill at herrin.us  Wed Nov 13 01:43:28 2013
From: bill at herrin.us (William Herrin)
Date: Tue, 12 Nov 2013 20:43:28 -0500
Subject: Automatic abuse reports
In-Reply-To: <8e46e18f60fef97dae75f61b4698fcf3@www.circlenet.us>
References: <Pine.LNX.4.64.1311122255060.7242@crisp>
 <8e46e18f60fef97dae75f61b4698fcf3@www.circlenet.us>
Message-ID: <CAP-guGW+pB4XtdaY7pzaOGj-i7rvtg8Ntox0n5UfCdF15GAdbA@mail.gmail.com>

On Tue, Nov 12, 2013 at 4:52 PM, Sam Moats <sam at circlenet.us> wrote:
> We used to use a small perl script called tattle that would parse out the
> /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, lookup
> the proper abuse contacts and report them. I haven't seen anything similar
> in years but it would be interesting to do more than null route IPs.
>
> The problem we had with the automated reporting was dealing with spoofed
> sources, we see lots of traffic that is obviously hostile but unless it
> becomes serious enough to impact performance we rarely report it. An
> automated system didn't seem to fit anymore due to false positives.

Hi Sam,

Out of curiosity -- how does one get a false positive on an ssh
exploit attempt? Does the origin IP not have to complete a 3-way
handshake before it can attempt an exploit?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From sam at circlenet.us  Wed Nov 13 02:07:59 2013
From: sam at circlenet.us (Sam Moats)
Date: Tue, 12 Nov 2013 21:07:59 -0500
Subject: Automatic abuse reports
In-Reply-To: <CAP-guGW+pB4XtdaY7pzaOGj-i7rvtg8Ntox0n5UfCdF15GAdbA@mail.gmail.com>
References: <Pine.LNX.4.64.1311122255060.7242@crisp>
 <8e46e18f60fef97dae75f61b4698fcf3@www.circlenet.us>
 <CAP-guGW+pB4XtdaY7pzaOGj-i7rvtg8Ntox0n5UfCdF15GAdbA@mail.gmail.com>
Message-ID: <3f84cdf1787be33a323b060bdfcdedef@www.circlenet.us>

Your right they wouldn't get all of the way through. The three way 
handshake is great against blind spoofing attacks. That said the 
original poster was focused on a DOS event,to do that you really don't 
need the full handshake.

I'm not sure if the end goal of whomever we were dealing with was to 
DOS us or if was some screwed up half open syn scans, or my personnel 
guess it was to generate enough bogus log traffic to hide which 
connections were legitimate threats. Either way enough inbound SYN 
connections on port 22 would tip over the servers, this was LONG ago 
circa 97~99, so the traffic we saw was an effective DOS.

We had inetd calling ssh and also telnet (Change comes slowly and 
cyrpto was painful to implement for us at the time). In our setup inetd 
decided to log the sessions both ssh and telnet as soon as the daemon 
was called. So even if we didn't do the full session setup the machine 
would still log an event for each tcp session.

In hindsight we could have cleaned it up so that it wouldn't log before 
completing the handshake or tweaked the perl script to filter them out 
but I was a newbie at that point and placing ACLs in my border router to 
drop inbound ssh traffic that didn't come from netblocks I expected and 
moving off of the default port were the easiest solutions at the time.

Now it would be trivial to setup syslog and sshd to give only the 
sessions that complete the handshake, however I'm also not sure how 
responsive some of the abuse contacts may be. I'll keep my restrictive 
network settings for the time being.

Sam Moats


On 2013-11-12 20:43, William Herrin wrote:
> On Tue, Nov 12, 2013 at 4:52 PM, Sam Moats <sam at circlenet.us> wrote:
>> We used to use a small perl script called tattle that would parse 
>> out the
>> /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, 
>> lookup
>> the proper abuse contacts and report them. I haven't seen anything 
>> similar
>> in years but it would be interesting to do more than null route IPs.
>>
>> The problem we had with the automated reporting was dealing with 
>> spoofed
>> sources, we see lots of traffic that is obviously hostile but unless 
>> it
>> becomes serious enough to impact performance we rarely report it. An
>> automated system didn't seem to fit anymore due to false positives.
>
> Hi Sam,
>
> Out of curiosity -- how does one get a false positive on an ssh
> exploit attempt? Does the origin IP not have to complete a 3-way
> handshake before it can attempt an exploit?
>
> Regards,
> Bill Herrin


From bill at herrin.us  Wed Nov 13 04:03:31 2013
From: bill at herrin.us (William Herrin)
Date: Tue, 12 Nov 2013 23:03:31 -0500
Subject: Automatic abuse reports
In-Reply-To: <3f84cdf1787be33a323b060bdfcdedef@www.circlenet.us>
References: <Pine.LNX.4.64.1311122255060.7242@crisp>
 <8e46e18f60fef97dae75f61b4698fcf3@www.circlenet.us>
 <CAP-guGW+pB4XtdaY7pzaOGj-i7rvtg8Ntox0n5UfCdF15GAdbA@mail.gmail.com>
 <3f84cdf1787be33a323b060bdfcdedef@www.circlenet.us>
Message-ID: <CAP-guGVjXrOqTgCKgwoHgMmuc+tussaMw4mWhNqO=Zx_URDasw@mail.gmail.com>

On Tue, Nov 12, 2013 at 9:07 PM, Sam Moats <sam at circlenet.us> wrote:
> That said the original poster was
> focused on a DOS event,to do that you really don't need the full handshake.

Point. Though not all DDOSes are created equal. The simple packet
flood is, as likely as not, from forged addresses. But I've also seen
DDOSes which make repeated HTTP GET requests. That's tough to do
without control of the source address.


> Now it would be trivial to setup syslog and sshd to give only the sessions
> that complete the handshake, however I'm also not sure how responsive some
> of the abuse contacts may be. I'll keep my restrictive network settings for
> the time being.

That's the main problem: you can generate the report but if it's about
some doofus in Dubai what are the odds of it doing any good?

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From brandon.galbraith at gmail.com  Wed Nov 13 05:16:14 2013
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Tue, 12 Nov 2013 23:16:14 -0600
Subject: Automatic abuse reports
In-Reply-To: <CAP-guGVjXrOqTgCKgwoHgMmuc+tussaMw4mWhNqO=Zx_URDasw@mail.gmail.com>
References: <Pine.LNX.4.64.1311122255060.7242@crisp>
 <8e46e18f60fef97dae75f61b4698fcf3@www.circlenet.us>
 <CAP-guGW+pB4XtdaY7pzaOGj-i7rvtg8Ntox0n5UfCdF15GAdbA@mail.gmail.com>
 <3f84cdf1787be33a323b060bdfcdedef@www.circlenet.us>
 <CAP-guGVjXrOqTgCKgwoHgMmuc+tussaMw4mWhNqO=Zx_URDasw@mail.gmail.com>
Message-ID: <CADE4tYUsXyfCcKxtCjnWJPbUURqvYt=SnfO0ovkuayQdyew4Tg@mail.gmail.com>

On Tue, Nov 12, 2013 at 10:03 PM, William Herrin <bill at herrin.us> wrote:
>> Now it would be trivial to setup syslog and sshd to give only the sessions
>> that complete the handshake, however I'm also not sure how responsive some
>> of the abuse contacts may be. I'll keep my restrictive network settings for
>> the time being.
>
> That's the main problem: you can generate the report but if it's about
> some doofus in Dubai what are the odds of it doing any good?

And then we're right back to sending the offending packets to a black
hole. *sigh*


From joelja at bogus.com  Wed Nov 13 05:22:21 2013
From: joelja at bogus.com (joel jaeggli)
Date: Tue, 12 Nov 2013 21:22:21 -0800
Subject: Automatic abuse reports
In-Reply-To: <CADE4tYUsXyfCcKxtCjnWJPbUURqvYt=SnfO0ovkuayQdyew4Tg@mail.gmail.com>
References: <Pine.LNX.4.64.1311122255060.7242@crisp>
 <8e46e18f60fef97dae75f61b4698fcf3@www.circlenet.us>
 <CAP-guGW+pB4XtdaY7pzaOGj-i7rvtg8Ntox0n5UfCdF15GAdbA@mail.gmail.com>
 <3f84cdf1787be33a323b060bdfcdedef@www.circlenet.us>
 <CAP-guGVjXrOqTgCKgwoHgMmuc+tussaMw4mWhNqO=Zx_URDasw@mail.gmail.com>
 <CADE4tYUsXyfCcKxtCjnWJPbUURqvYt=SnfO0ovkuayQdyew4Tg@mail.gmail.com>
Message-ID: <C4E3D194-41C1-4C73-9AFE-5A1C9AC72717@bogus.com>


On Nov 12, 2013, at 9:16 PM, Brandon Galbraith <brandon.galbraith at gmail.com> wrote:

> On Tue, Nov 12, 2013 at 10:03 PM, William Herrin <bill at herrin.us> wrote:
>>> Now it would be trivial to setup syslog and sshd to give only the sessions
>>> that complete the handshake, however I'm also not sure how responsive some
>>> of the abuse contacts may be. I'll keep my restrictive network settings for
>>> the time being.
>> 
>> That's the main problem: you can generate the report but if it's about
>> some doofus in Dubai what are the odds of it doing any good?
> 
> And then we're right back to sending the offending packets to a black
> hole. *sigh*
> 

a packet that you can drop quickly is a packet you don?t have to think about.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131112/0be4e1db/attachment-0001.bin>

From hmurray at megapathdsl.net  Wed Nov 13 05:57:17 2013
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 12 Nov 2013 21:57:17 -0800
Subject: Automatic abuse reports
Message-ID: <20131113055717.61C06406062@ip-64-139-1-69.sjc.megapath.net>

William Herrin <bill at herrin.us> said:
> That's the main problem: you can generate the report but if it's about
> some doofus in Dubai what are the odds of it doing any good?

It's much worse than that.

Several 500 pound gorillas expect you to jump through various hoops to report 
abuse.  Have you tried reporting a drop box to Yahoo or Google lately?

On top of that, many outfits big enough to own a CIDR block are outsourcing 
their mail to Google.  Google has a good spam filter.  It's good enough to 
reject spam reports to abuse@<hosted-by-google>

I wonder what would happen if RIRs required working abuse mailboxes.  There 
are two levels of "working".  The first is doesn't bounce or get rejected 
with a sensible reason.  The second is actually gets acted upon.

If you were magically appointed big-shot in charge of everything, how long 
would you let an ISP host a spammer's web site or DNS server or ...?  What 
about retail ISPs with zillions of zombied systems?


-- 
These are my opinions.  I hate spam.





From sam at circlenet.us  Wed Nov 13 09:46:31 2013
From: sam at circlenet.us (Sam Moats)
Date: Wed, 13 Nov 2013 04:46:31 -0500
Subject: Automatic abuse reports
In-Reply-To: <20131113055717.61C06406062@ip-64-139-1-69.sjc.megapath.net>
References: <20131113055717.61C06406062@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <abd31348f6877528592c441a73acc7f6@www.circlenet.us>

I expect this from the doofus in $pain_in_the_butt_county but I am 
surprised when I see this behavior
from large companies and I really don't understand it. Having a working 
abuse/response system is beneficial
to us all including the gorillas. There is a cost to us if we're 
spending expensive engineering time,
and network resources to deal with the traffic. Also there is an 
intangible affect on our customers opinion
of our service.

The only thing I can think of is that they are making the decisions 
about how important their abuse desk
is based solely on the cost of running that desk. They are seeing it as 
a cost center and not thinking
about it's long term benefit to the entire network. I can't think of a 
way to remove the incentive for this
short term thinking.

If I were the big cheese of the internet?
1. Transit providers would properly implement RFC 2827 filtering facing 
their downstream single homed customers.
If you only connect to me and I send you x.x.x.0/24 down your T1 I 
shouldn't be getting y.y.y.0 traffic from you.
This is easy to do.

2. Tier 1 backbone providers should be willing to de-peer non 
responsive global networks. I've lost faith in
regulations to actually curb the flow but the tier 1 providers may have 
the leverage to encourage good behavior.
For example if $pain_in_the_butt telco in $pain_in_the_butt country has 
to start paying for transit to get to
$big_tier_1 then maybe they would clean up their act. The problem with 
this is I can't think of a financial way
to get buy in to for idea from the business types in these companies.

3. There needs to be more responsible network citizenship among the 
providers large enough to have an AS number.
It's harder to do ingress filtering if your customers are running BGP, 
I can see reasonable cases where a
customer might throw traffic at me from source addresses that I didn't 
expect. At this point you should require your customers to
police their internal network and be willing to give up on their 
revenue if they refuse to do so.
Perhaps requiring a 24 hour human response to abuse@ emails as a 
condition of having an AS from an RIR or as a
requirement for turning up a BGP connection? We expect a good NOC for a 
peer but care less about a customer in most
cases.

4. Large eyeball networks would see the value in protecting their own 
people and would implement RFC2827 as close
to their customers as possible. As soon as you can drop that packet on 
the floor the better. The giant zombie
bot armies are a pain to them to.

Thats all I can think of at 4am, I bet you can see why nobody would 
ever appoint me big cheese of the internet.

Sam Moats


On 2013-11-13 00:57, Hal Murray wrote:
> William Herrin <bill at herrin.us> said:
>> That's the main problem: you can generate the report but if it's 
>> about
>> some doofus in Dubai what are the odds of it doing any good?
>
> It's much worse than that.
>
> Several 500 pound gorillas expect you to jump through various hoops
> to report
> abuse.  Have you tried reporting a drop box to Yahoo or Google 
> lately?
>
> On top of that, many outfits big enough to own a CIDR block are 
> outsourcing
> their mail to Google.  Google has a good spam filter.  It's good 
> enough to
> reject spam reports to abuse@<hosted-by-google>
>
> I wonder what would happen if RIRs required working abuse mailboxes.  
> There
> are two levels of "working".  The first is doesn't bounce or get 
> rejected
> with a sensible reason.  The second is actually gets acted upon.
>
> If you were magically appointed big-shot in charge of everything, how 
> long
> would you let an ISP host a spammer's web site or DNS server or ...?  
> What
> about retail ISPs with zillions of zombied systems?


From paul.w.bennett at gmail.com  Wed Nov 13 10:48:26 2013
From: paul.w.bennett at gmail.com (Paul Bennett)
Date: Wed, 13 Nov 2013 05:48:26 -0500
Subject: Automatic abuse reports
In-Reply-To: <abd31348f6877528592c441a73acc7f6@www.circlenet.us>
References: <20131113055717.61C06406062@ip-64-139-1-69.sjc.megapath.net>
 <abd31348f6877528592c441a73acc7f6@www.circlenet.us>
Message-ID: <CANZ_Bxp7xwMsEC9ddn-4NcdsyWeod1Nqiepbb7vyCJTDWmkk9Q@mail.gmail.com>

I can't speak directly for them, as I'm not an official company
spokesperson, but this conversation has got my dander up enough that I
can't keep my big mouth shut.

I know of at least one 500 pound gorilla (with zillions of retail
customers, and their share of 500 pound gorillas as customers (and
everything in between)) that has a working and effective abuse@
address, one that can and does aggregate and pass on abuse complaints,
and that can and does suspend service over failure to fix. On
occasion, I understand even significant customers have been not just
suspended but terminated over failure to follow the ToS/AUP.

The company in question accepts abuse complaints in ARF, MARF, X-ARF
and IODEF format, among others, and (I cannot emphasize this enough)
does act on them.

Anyone who suggests roundfiling abuse@ complaints is (IMNSHO) actively
working to make the problem worse, not better. Anyone who thinks that
all networks do roundfile abuse@ complaints would seem to be making an
over-generalization.

Note, once again, that these are my opinions, and not my employers',
so much so that I can't even tell you directly who my employer is. Not
that it's hard to find out, but I'm so very much not speaking in an
official capacity here.


--
Paul


From sam at circlenet.us  Wed Nov 13 10:51:12 2013
From: sam at circlenet.us (Sam Moats)
Date: Wed, 13 Nov 2013 05:51:12 -0500
Subject: Automatic abuse reports
In-Reply-To: <CANZ_Bxp7xwMsEC9ddn-4NcdsyWeod1Nqiepbb7vyCJTDWmkk9Q@mail.gmail.com>
References: <20131113055717.61C06406062@ip-64-139-1-69.sjc.megapath.net>
 <abd31348f6877528592c441a73acc7f6@www.circlenet.us>
 <CANZ_Bxp7xwMsEC9ddn-4NcdsyWeod1Nqiepbb7vyCJTDWmkk9Q@mail.gmail.com>
Message-ID: <b479d92e6019bfa5eda6f5d39bbae024@www.circlenet.us>

There are good guys out there :-), and some are gorilla sized thats why 
I
obfuscated the names in my response. No offense intended to the goood 
ones.
Sam Moats

On 2013-11-13 05:48, Paul Bennett wrote:
> I can't speak directly for them, as I'm not an official company
> spokesperson, but this conversation has got my dander up enough that 
> I
> can't keep my big mouth shut.
>
> I know of at least one 500 pound gorilla (with zillions of retail
> customers, and their share of 500 pound gorillas as customers (and
> everything in between)) that has a working and effective abuse@
> address, one that can and does aggregate and pass on abuse 
> complaints,
> and that can and does suspend service over failure to fix. On
> occasion, I understand even significant customers have been not just
> suspended but terminated over failure to follow the ToS/AUP.
>
> The company in question accepts abuse complaints in ARF, MARF, X-ARF
> and IODEF format, among others, and (I cannot emphasize this enough)
> does act on them.
>
> Anyone who suggests roundfiling abuse@ complaints is (IMNSHO) 
> actively
> working to make the problem worse, not better. Anyone who thinks that
> all networks do roundfile abuse@ complaints would seem to be making 
> an
> over-generalization.
>
> Note, once again, that these are my opinions, and not my employers',
> so much so that I can't even tell you directly who my employer is. 
> Not
> that it's hard to find out, but I'm so very much not speaking in an
> official capacity here.
>
>
> --
> Paul



From Bruce.Curtis at ndsu.edu  Wed Nov 13 16:56:07 2013
From: Bruce.Curtis at ndsu.edu (Curtis, Bruce)
Date: Wed, 13 Nov 2013 16:56:07 +0000
Subject: Automatic abuse reports
In-Reply-To: <Pine.LNX.4.64.1311122255060.7242@crisp>
References: <Pine.LNX.4.64.1311122255060.7242@crisp>
Message-ID: <3C239F8A-6FCD-4ADC-8F44-58DD1F68C6DD@ndsu.edu>


On Nov 12, 2013, at 3:58 PM, Jonas Bj?rklund <jonas at bjorklund.cn> wrote:

> Hello,
> 
> We got often abuse reports on hosts that has been involved in DDOS attacks.
> We contact the owner of the host help them fix the problem.
> 
> I also would like to start send these abuse report to the ISP of the source.
> 
> Are there any avaliable tools for this? Is there any plugin for nfsen?
> 
> Do I need to write my own scripts for this?
> 
> /Jonas

  You could send the info to DSHIELD.  Then they might notify the ISP if you enabled ?Fightback?.

http://dshield.org/howto.html

http://dshield.org/fightback.html

---
Bruce Curtis                         bruce.curtis at ndsu.edu
Certified NetAnalyst II                701-231-8527
North Dakota State University        



From amekkaoui at mektel.ca  Wed Nov 13 04:25:06 2013
From: amekkaoui at mektel.ca (A Mekkaoui)
Date: Tue, 12 Nov 2013 23:25:06 -0500
Subject: IP transit providers @ 625 RL
Message-ID: <000d01cee028$55b286c0$01179440$@ca>

Hi, anyone knows about carrier companies which provides IP transit service
and has are located in Cologix data center at 625 Rene Levesque, Montreal,
Canada. Thanks in advance for your help.

 

Karim

 


From royboy at umich.edu  Wed Nov 13 20:31:33 2013
From: royboy at umich.edu (Roy hockett)
Date: Wed, 13 Nov 2013 15:31:33 -0500
Subject: OT: Below grade fiber interconnect points
Message-ID: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>

Has anyone ever used a below grade vault for housing fiber cross connects?

We have to move a fiber interconnect facility due to the current building being demolished.
If you have I would be interested in talking to you.  If there are more appropriate lists, I would appreciate any suggestions.

Thanks,
-Roy Hockett

Network Architect,
ITS Communication Systems
University of Michigan
Tel: (734) 763-7325
Fax: (734) 615-1727
email: royboy at umich.edu

From kemp at network-services.uoregon.edu  Wed Nov 13 21:44:16 2013
From: kemp at network-services.uoregon.edu (John Kemp)
Date: Wed, 13 Nov 2013 13:44:16 -0800
Subject: new collector: route-views.soxrs.routeviews.org
Message-ID: <5283F2B0.9040901@network-services.uoregon.edu>


Not much there yet, but we are operational
and would love to get a few more peers.

Serbian Open eXchange
http://www.routeviews.org/soxrs.html

Thanks,
-- 
John Kemp (kemp at routeviews.org)
RouteViews Engineer
NOC: noc at routeviews.org
MAIL: help at routeviews.org
WWW: http://www.routeviews.org


From streiner at cluebyfour.org  Wed Nov 13 20:05:58 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 13 Nov 2013 15:05:58 -0500 (EST)
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
Message-ID: <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>

On Wed, 13 Nov 2013, Roy hockett wrote:

> Has anyone ever used a below grade vault for housing fiber cross connects?
>
> We have to move a fiber interconnect facility due to the current 
> building being demolished.  If you have I would be interested in talking 
> to you.  If there are more appropriate lists, I would appreciate any 
> suggestions.

When you say "below grade vault", do you mean something that's only 
accessible through a manhole?

I haven't done this specifically, however if the vault does not have a 
controlled environment, you could be dealing with massive headaches 
related to dust/dirt contamination, moisture penetration, etc.  I work in 
a large-campus .edu environment, so I'm some of the headaches you're 
probably trying to avoid.  Also, be aware that access to the vault could 
be an issue.  There are OSHA regs related to what sort of training and 
safety equipment someone who will be working in an underground vault must 
have.

I'm assuming that the fiber will be cross-connected to a new location 
prior to the building being demolished.

Not knowing your outside plant or circumstances, would it be feasible to 
fusion-splice a new tail onto the fiber that was going to the building 
that's being demolished, or (ideally) pulling a new piece of fiber to the 
new building, so you don't have to deal with potentially dodgy splices?

jms


From gravestl at swbell.net  Thu Nov 14 00:53:28 2013
From: gravestl at swbell.net (Thomas)
Date: Wed, 13 Nov 2013 18:53:28 -0600
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
 <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
Message-ID: <33902702-EABC-4C97-8907-A273CD7BDD92@swbell.net>

Usually it would spliced outside at the manhole where the fiber meet to go in the building.  Depends on the way you want to connect them etc.

Thomas L Graves
Sent from my IPhone 


> On Nov 13, 2013, at 2:05 PM, "Justin M. Streiner" <streiner at cluebyfour.org> wrote:
> 
>> On Wed, 13 Nov 2013, Roy hockett wrote:
>> 
>> Has anyone ever used a below grade vault for housing fiber cross connects?
>> 
>> We have to move a fiber interconnect facility due to the current building being demolished.  If you have I would be interested in talking to you.  If there are more appropriate lists, I would appreciate any suggestions.
> 
> When you say "below grade vault", do you mean something that's only accessible through a manhole?
> 
> I haven't done this specifically, however if the vault does not have a controlled environment, you could be dealing with massive headaches related to dust/dirt contamination, moisture penetration, etc.  I work in a large-campus .edu environment, so I'm some of the headaches you're probably trying to avoid.  Also, be aware that access to the vault could be an issue.  There are OSHA regs related to what sort of training and safety equipment someone who will be working in an underground vault must have.
> 
> I'm assuming that the fiber will be cross-connected to a new location prior to the building being demolished.
> 
> Not knowing your outside plant or circumstances, would it be feasible to fusion-splice a new tail onto the fiber that was going to the building that's being demolished, or (ideally) pulling a new piece of fiber to the new building, so you don't have to deal with potentially dodgy splices?
> 
> jms
> 


From me at anuragbhatia.com  Thu Nov 14 01:31:20 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 14 Nov 2013 02:31:20 +0100
Subject: Recovery mode on Juniper M7i
In-Reply-To: <527ABBBF.5090501@kanren.net>
References: <CAJ0+aXZKQ8L0P9sf1ikv9suDCipaJv3NFr7jLYSNXDLs0JP37w@mail.gmail.com>
 <CAE42oJqoF3+n0OXLE=LopupxQA07baKvXpPPW990ciMN6OPQKQ@mail.gmail.com>
 <527ABBBF.5090501@kanren.net>
Message-ID: <CAJ0+aXZEPynjUgqM5XKf-DjS_=cZXp86ROHNnn09PnJmxTSM+w@mail.gmail.com>

I was able to access routers by flashing 1st router's image on remaining.

Issue with other three as to best extent I can guess was that someone
enabled root password in single user mode and so there was no way around to
get to recovery console.



Thanks everyone for useful replies.


On Wed, Nov 6, 2013 at 10:59 PM, Jeff Sorrels <jlsorrels at kanren.net> wrote:

> Direct access to the bootstrap loader should bypass any access
> restrictions configured on the box.  However, it sounds like the device is
> not dropping into single-user mode.
>
> I would suggest removing and wiping the CF card.  Then boot from
> alternative media (USB) and snapshot on to the blank card.
>
> Cheers,
> Jeff
>
>
>
>
>
> On 11/6/2013 3:28 PM, Pedro Cavaca wrote:
>
>> Maybe you're not doing anything wrong and someone tweaked the routers and
>> marked the console as insecure, a previous owner maybe?
>>
>> http://superuser.com/questions/85536/securing-freebsd-in-single-user-mode
>>
>> http://www.freebsd.org/cgi/man.cgi?query=boot&sektion=8
>>
>> HTH.
>>
>>
>> On 6 November 2013 21:11, Anurag Bhatia <me at anuragbhatia.com> wrote:
>>
>>  Hello everyone!
>>>
>>>
>>> Greetings of the day.
>>>
>>>
>>> I am kind of (badly) stuck with multiple routers and not able to recover
>>> the root password. It's Juniper M7i. I have followed the Juniper support
>>> page as given here -
>>>
>>> http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/
>>> authentication-root-password-recovering.htmland
>>> strange enough that it worked with one of routers I have but failed on
>>> rest all.
>>>
>>>
>>> I am getting stuck on Step #12. As I give "boot -s" to get into single
>>> user
>>> mode of BSD, system next asks me for root password and hence I am out of
>>> luck to get into "recovery mode". I tried pressing enter on that prompt
>>> as
>>> well but no luck. I am connecting to router via console and do have
>>> physical access to router(s).
>>>
>>>
>>> Was wondering if someone has seen similar issues and could guide on what
>>> I
>>> am doing wrong? Most of other help pages I have seen on net have same
>>> exact
>>> steps as given on that page.
>>>
>>>
>>>
>>>
>>> Thanks.
>>> --
>>>
>>>
>>> Anurag Bhatia
>>> anuragbhatia.com
>>>
>>> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
>>> Twitter<https://twitter.com/anurag_bhatia>
>>> Skype: anuragbhatia.com
>>>
>>>
> --
> Jeff Sorrels
> Network Administrator
> KanREN, Inc
> jlsorrels at kanren.net
> 785-856-9820, #2
>
>


-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From jeff-kell at utc.edu  Thu Nov 14 01:32:45 2013
From: jeff-kell at utc.edu (Jeff Kell)
Date: Wed, 13 Nov 2013 20:32:45 -0500
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <33902702-EABC-4C97-8907-A273CD7BDD92@swbell.net>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
 <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
 <33902702-EABC-4C97-8907-A273CD7BDD92@swbell.net>
Message-ID: <5284283D.3060307@utc.edu>

You can stick a "splice" in a manhole.  You don't want a "patch panel"
or cross-connect in that sort of environment, keep that housed inside,
somewhere.

Jeff

On 11/13/2013 7:53 PM, Thomas wrote:
> Usually it would spliced outside at the manhole where the fiber meet to go in the building.  Depends on the way you want to connect them etc.
>
> Thomas L Graves
> Sent from my IPhone 
>
>
>> On Nov 13, 2013, at 2:05 PM, "Justin M. Streiner" <streiner at cluebyfour.org> wrote:
>>
>>> On Wed, 13 Nov 2013, Roy hockett wrote:
>>>
>>> Has anyone ever used a below grade vault for housing fiber cross connects?
>>>
>>> We have to move a fiber interconnect facility due to the current building being demolished.  If you have I would be interested in talking to you.  If there are more appropriate lists, I would appreciate any suggestions.
>> When you say "below grade vault", do you mean something that's only accessible through a manhole?
>>
>> I haven't done this specifically, however if the vault does not have a controlled environment, you could be dealing with massive headaches related to dust/dirt contamination, moisture penetration, etc.  I work in a large-campus .edu environment, so I'm some of the headaches you're probably trying to avoid.  Also, be aware that access to the vault could be an issue.  There are OSHA regs related to what sort of training and safety equipment someone who will be working in an underground vault must have.
>>
>> I'm assuming that the fiber will be cross-connected to a new location prior to the building being demolished.
>>
>> Not knowing your outside plant or circumstances, would it be feasible to fusion-splice a new tail onto the fiber that was going to the building that's being demolished, or (ideally) pulling a new piece of fiber to the new building, so you don't have to deal with potentially dodgy splices?
>>
>> jms
>>
>




From mysidia at gmail.com  Thu Nov 14 02:33:20 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 13 Nov 2013 20:33:20 -0600
Subject: Automatic abuse reports
In-Reply-To: <abd31348f6877528592c441a73acc7f6@www.circlenet.us>
References: <20131113055717.61C06406062@ip-64-139-1-69.sjc.megapath.net>
 <abd31348f6877528592c441a73acc7f6@www.circlenet.us>
Message-ID: <CAAAwwbVkiH1eiaEQZJaNEC6Q2PPcEoG8bz=5UYg4xWC3H9j-7Q@mail.gmail.com>

On Wed, Nov 13, 2013 at 3:46 AM, Sam Moats <sam at circlenet.us> wrote:


> about it's long term benefit to the entire network. I can't think of a way
> to remove the incentive for this
> short term thinking.
>

The end users can,  by inquiring  about the abuse desk, before agreeing to
sign up for service.

In this manner  "Not having a good abuse"  desk becomes a cost center, in
the form of suppressed opportunities for future revenue.


Federal entities, etc,  when soliciting for proposals from ISPs and service
providers....    in addition to the  "Must have IPv6 support",

could add a line  "Must have a highly-responsive abuse desk/abuse contact;
 with 4  professional references from email or network operators in the
industry who have worked with the abuse desk";

must  aggregate and report  matters of potential abuse or complaints
 regarding subscriber's  outgoing mail or IP traffic within  3 hours on
average, during business hours.... and within  5 hours  24x7 ... etc...


--
-JH

From sam at circlenet.us  Thu Nov 14 02:33:29 2013
From: sam at circlenet.us (Sam Moats)
Date: Wed, 13 Nov 2013 21:33:29 -0500
Subject: Automatic abuse reports
In-Reply-To: <CAAAwwbVkiH1eiaEQZJaNEC6Q2PPcEoG8bz=5UYg4xWC3H9j-7Q@mail.gmail.com>
References: <20131113055717.61C06406062@ip-64-139-1-69.sjc.megapath.net>
 <abd31348f6877528592c441a73acc7f6@www.circlenet.us>
 <CAAAwwbVkiH1eiaEQZJaNEC6Q2PPcEoG8bz=5UYg4xWC3H9j-7Q@mail.gmail.com>
Message-ID: <c99d93364a574a0029be59981a058fb3@www.circlenet.us>

Don't have access to a normal PC right now but I agreed with this 
approach so much that I'm typing a response on a 10 button pad.
Sam

On 2013-11-13 21:33, Jimmy Hess wrote:
> On Wed, Nov 13, 2013 at 3:46 AM, Sam Moats <sam at circlenet.us [1]>
> wrote:
>
>  ?
>
>> about its long term benefit to the entire network. I cant think of a
>> way to remove the incentive for this
>> short term thinking.
>
> The end users can, ?by inquiring ?about the abuse desk, before
> agreeing to sign up for service.
>
> In this manner ?"Not having a good abuse" ?desk becomes a cost
> center, in the form of suppressed opportunities for future revenue.
>
> Federal entities, etc, ?when soliciting for proposals from ISPs and
> service providers.... ? ?in addition to the ?"Must have IPv6
> support",
>
> could add a line ?"Must have a highly-responsive abuse desk/abuse
> contact; ?with 4 ?professional references from email or network
> operators in the industry who have worked with the abuse desk";
>
> must ?aggregate and report ?matters of potential abuse or complaints
> ?regarding subscribers ?outgoing mail or IP traffic within ?3 hours
> on average, during business hours.... and within ?5 hours ?24x7 ...
> etc...
>
> --
> -JH?
>
> Links:
> ------
> [1] mailto:sam at circlenet.us



From goemon at anime.net  Thu Nov 14 03:50:23 2013
From: goemon at anime.net (goemon at anime.net)
Date: Wed, 13 Nov 2013 19:50:23 -0800 (PST)
Subject: Automatic abuse reports
In-Reply-To: <abd31348f6877528592c441a73acc7f6@www.circlenet.us>
References: <20131113055717.61C06406062@ip-64-139-1-69.sjc.megapath.net>
 <abd31348f6877528592c441a73acc7f6@www.circlenet.us>
Message-ID: <Pine.LNX.4.64.1311131949340.25534@sasami.anime.net>

On Wed, 13 Nov 2013, Sam Moats wrote:
> The only thing I can think of is that they are making the decisions about how 
> important their abuse desk
> is based solely on the cost of running that desk. They are seeing it as a 
> cost center and not thinking
> about it's long term benefit to the entire network. I can't think of a way to 
> remove the incentive for this
> short term thinking.

Spam needs to become a financial liability rather than a lucrative revenue 
stream. That's the only way this is going to change.

-Dan


From royboy at umich.edu  Thu Nov 14 04:51:57 2013
From: royboy at umich.edu (Roy Hockett)
Date: Wed, 13 Nov 2013 23:51:57 -0500
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <5284283D.3060307@utc.edu>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
 <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
 <33902702-EABC-4C97-8907-A273CD7BDD92@swbell.net> <5284283D.3060307@utc.edu>
Message-ID: <B3A3F3E3-FA2E-4C55-8A1F-D94ABB1A329F@umich.edu>

Thank you for comments. Let me clarify the situation.  We have a building that has been fiber cross connect
location and is being demolished.  This location has about 20 fiber cable entering where we patch between
fiber paths.  If we relocated these cross connect field to another building and that build is demolished we have
to do this all over again, so the desire was to have an independent facility for the fiber cross connect field, but
I am guessing due to esthetics the below ground vault was selected, we just learned of this selection and thus
my query to this group to find other that have dealt with similar situations and if so, experience base recommendations, 
and things to be aware of.

Thanks,
-Roy Hockett

Network Architect,
ITS Communications Systems and Data Centers
University of Michigan
Tel: (734) 763-7325
Fax: (734) 615-1727
email: royboy at umich.edu

On Nov 13, 2013, at 8:32 PM, Jeff Kell <jeff-kell at utc.edu> wrote:

> You can stick a "splice" in a manhole.  You don't want a "patch panel"
> or cross-connect in that sort of environment, keep that housed inside,
> somewhere.
> 
> Jeff
> 
> On 11/13/2013 7:53 PM, Thomas wrote:
>> Usually it would spliced outside at the manhole where the fiber meet to go in the building.  Depends on the way you want to connect them etc.
>> 
>> Thomas L Graves
>> Sent from my IPhone 
>> 
>> 
>>> On Nov 13, 2013, at 2:05 PM, "Justin M. Streiner" <streiner at cluebyfour.org> wrote:
>>> 
>>>> On Wed, 13 Nov 2013, Roy hockett wrote:
>>>> 
>>>> Has anyone ever used a below grade vault for housing fiber cross connects?
>>>> 
>>>> We have to move a fiber interconnect facility due to the current building being demolished.  If you have I would be interested in talking to you.  If there are more appropriate lists, I would appreciate any suggestions.
>>> When you say "below grade vault", do you mean something that's only accessible through a manhole?
>>> 
>>> I haven't done this specifically, however if the vault does not have a controlled environment, you could be dealing with massive headaches related to dust/dirt contamination, moisture penetration, etc.  I work in a large-campus .edu environment, so I'm some of the headaches you're probably trying to avoid.  Also, be aware that access to the vault could be an issue.  There are OSHA regs related to what sort of training and safety equipment someone who will be working in an underground vault must have.
>>> 
>>> I'm assuming that the fiber will be cross-connected to a new location prior to the building being demolished.
>>> 
>>> Not knowing your outside plant or circumstances, would it be feasible to fusion-splice a new tail onto the fiber that was going to the building that's being demolished, or (ideally) pulling a new piece of fiber to the new building, so you don't have to deal with potentially dodgy splices?
>>> 
>>> jms
>>> 
>> 
> 
> 
> 



From streiner at cluebyfour.org  Thu Nov 14 02:04:40 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 13 Nov 2013 21:04:40 -0500 (EST)
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <B3A3F3E3-FA2E-4C55-8A1F-D94ABB1A329F@umich.edu>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
 <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
 <33902702-EABC-4C97-8907-A273CD7BDD92@swbell.net> <5284283D.3060307@utc.edu>
 <B3A3F3E3-FA2E-4C55-8A1F-D94ABB1A329F@umich.edu>
Message-ID: <Pine.LNX.4.64.1311132047370.12253@whammy.cluebyfour.org>

On Wed, 13 Nov 2013, Roy Hockett wrote:

> Thank you for comments. Let me clarify the situation.  We have a building that has been fiber cross connect
> location and is being demolished.  This location has about 20 fiber cable entering where we patch between
> fiber paths.  If we relocated these cross connect field to another building and that build is demolished we have
> to do this all over again, so the desire was to have an independent facility for the fiber cross connect field, but
> I am guessing due to esthetics the below ground vault was selected, we just learned of this selection and thus
> my query to this group to find other that have dealt with similar situations and if so, experience base recommendations,
> and things to be aware of.

If the vault has a controlled environment and access, similar to what you 
would find inside of a comms room, that's one thing.  If it's more like a 
typical manhole (damp, dirty, dark, possible temperature extremes, other 
utilities/hazards), then the only thing that should be in there is a 
water-tight splice case.  Fiber patches need to be in a clean environment.

Did this project provide any funds for relocation or replacement of the 
communications facilities that would be lost due to the demolition?  We've 
gone through this many times on our campus.

jms


From gravestl at swbell.net  Thu Nov 14 14:16:35 2013
From: gravestl at swbell.net (Thomas)
Date: Thu, 14 Nov 2013 08:16:35 -0600
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <Pine.LNX.4.64.1311132047370.12253@whammy.cluebyfour.org>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
 <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
 <33902702-EABC-4C97-8907-A273CD7BDD92@swbell.net> <5284283D.3060307@utc.edu>
 <B3A3F3E3-FA2E-4C55-8A1F-D94ABB1A329F@umich.edu>
 <Pine.LNX.4.64.1311132047370.12253@whammy.cluebyfour.org>
Message-ID: <70D7AF81-0FB6-4F07-9365-A3F773F46FE6@swbell.net>

Another option is an above ground  cabinet.  Many telecoms use them.

Thomas L Graves
Sent from my IPhone 


> On Nov 13, 2013, at 8:04 PM, "Justin M. Streiner" <streiner at cluebyfour.org> wrote:
> 
>> On Wed, 13 Nov 2013, Roy Hockett wrote:
>> 
>> Thank you for comments. Let me clarify the situation.  We have a building that has been fiber cross connect
>> location and is being demolished.  This location has about 20 fiber cable entering where we patch between
>> fiber paths.  If we relocated these cross connect field to another building and that build is demolished we have
>> to do this all over again, so the desire was to have an independent facility for the fiber cross connect field, but
>> I am guessing due to esthetics the below ground vault was selected, we just learned of this selection and thus
>> my query to this group to find other that have dealt with similar situations and if so, experience base recommendations,
>> and things to be aware of.
> 
> If the vault has a controlled environment and access, similar to what you would find inside of a comms room, that's one thing.  If it's more like a typical manhole (damp, dirty, dark, possible temperature extremes, other utilities/hazards), then the only thing that should be in there is a water-tight splice case.  Fiber patches need to be in a clean environment.
> 
> Did this project provide any funds for relocation or replacement of the communications facilities that would be lost due to the demolition?  We've gone through this many times on our campus.
> 
> jms
> 


From jmcleod at musfiber.net  Thu Nov 14 13:28:11 2013
From: jmcleod at musfiber.net (Joe McLeod)
Date: Thu, 14 Nov 2013 13:28:11 +0000
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <Pine.LNX.4.64.1311132047370.12253@whammy.cluebyfour.org>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
 <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
 <33902702-EABC-4C97-8907-A273CD7BDD92@swbell.net> <5284283D.3060307@utc.edu>
 <B3A3F3E3-FA2E-4C55-8A1F-D94ABB1A329F@umich.edu>
 <Pine.LNX.4.64.1311132047370.12253@whammy.cluebyfour.org>
Message-ID: <C1229D755E689B4FAC9D53A76C409B81012C308E@MAIL-2K8R2.mus.local>

Your only other real option would be to deploy a "road-side" cabinet which has environmental controls...

https://www.google.com/search?q=roadside+cabinets&tbm=isch&tbo=u&source=univ&sa=X&ei=f8-EUqHNOdPqkQe32IHABw&ved=0CEsQsAQ&biw=1620&bih=735


Thanks,

Joe

-----Original Message-----
From: Justin M. Streiner [mailto:streiner at cluebyfour.org] 
Sent: Wednesday, November 13, 2013 9:05 PM
To: nanog at nanog.org
Subject: Re: OT: Below grade fiber interconnect points

On Wed, 13 Nov 2013, Roy Hockett wrote:

> Thank you for comments. Let me clarify the situation.  We have a 
> building that has been fiber cross connect location and is being 
> demolished.  This location has about 20 fiber cable entering where we 
> patch between fiber paths.  If we relocated these cross connect field 
> to another building and that build is demolished we have to do this 
> all over again, so the desire was to have an independent facility for 
> the fiber cross connect field, but I am guessing due to esthetics the below ground vault was selected, we just learned of this selection and thus my query to this group to find other that have dealt with similar situations and if so, experience base recommendations, and things to be aware of.

If the vault has a controlled environment and access, similar to what you would find inside of a comms room, that's one thing.  If it's more like a typical manhole (damp, dirty, dark, possible temperature extremes, other utilities/hazards), then the only thing that should be in there is a water-tight splice case.  Fiber patches need to be in a clean environment.

Did this project provide any funds for relocation or replacement of the communications facilities that would be lost due to the demolition?  We've gone through this many times on our campus.

jms



--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




From shawnl at up.net  Thu Nov 14 14:01:07 2013
From: shawnl at up.net (Shawn L)
Date: Thu, 14 Nov 2013 09:01:07 -0500
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <Pine.LNX.4.64.1311132047370.12253@whammy.cluebyfour.org>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
 <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
 <33902702-EABC-4C97-8907-A273CD7BDD92@swbell.net>
 <5284283D.3060307@utc.edu>
 <B3A3F3E3-FA2E-4C55-8A1F-D94ABB1A329F@umich.edu>
 <Pine.LNX.4.64.1311132047370.12253@whammy.cluebyfour.org>
Message-ID: <CACTmXQUCs+OAHPBwVGVtab1ZhwqObrpK_-2zx3Oe_Z7xxvzahA@mail.gmail.com>

There are a couple of ways to do this.  If you're going to keep everything
below grade in a man hole or cable vault of some type, you definitely need
to have it in a sealed splicing enclosure.  That means instead of using a
patch panel, everything has to be fusion spliced.  You'll get less loss
because it's a direct splice, but changing things later becomes a pain.

The other option is to use an outdoor fiber patch cabinet / pedestal.
There are multiple outdoor rated above ground fiber cross connect cabinets
available that you could probably find an unobtrusive place to install.
Or, there are several manufacturers (3M, etc.) that make fiber cross
connects that fit in a plastic version of a standard telco pedestal which
you could pretty much place anywhere.




On Wed, Nov 13, 2013 at 9:04 PM, Justin M. Streiner <streiner at cluebyfour.org
> wrote:

> On Wed, 13 Nov 2013, Roy Hockett wrote:
>
>  Thank you for comments. Let me clarify the situation.  We have a building
>> that has been fiber cross connect
>> location and is being demolished.  This location has about 20 fiber cable
>> entering where we patch between
>> fiber paths.  If we relocated these cross connect field to another
>> building and that build is demolished we have
>> to do this all over again, so the desire was to have an independent
>> facility for the fiber cross connect field, but
>> I am guessing due to esthetics the below ground vault was selected, we
>> just learned of this selection and thus
>> my query to this group to find other that have dealt with similar
>> situations and if so, experience base recommendations,
>> and things to be aware of.
>>
>
> If the vault has a controlled environment and access, similar to what you
> would find inside of a comms room, that's one thing.  If it's more like a
> typical manhole (damp, dirty, dark, possible temperature extremes, other
> utilities/hazards), then the only thing that should be in there is a
> water-tight splice case.  Fiber patches need to be in a clean environment.
>
> Did this project provide any funds for relocation or replacement of the
> communications facilities that would be lost due to the demolition?  We've
> gone through this many times on our campus.
>
> jms
>
>

From sroche at lakelandnetworks.com  Thu Nov 14 20:22:10 2013
From: sroche at lakelandnetworks.com (Sam Roche)
Date: Thu, 14 Nov 2013 15:22:10 -0500
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <70D7AF81-0FB6-4F07-9365-A3F773F46FE6@swbell.net>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
 <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
 <33902702-EABC-4C97-8907-A273CD7BDD92@swbell.net> <5284283D.3060307@utc.edu>
 <B3A3F3E3-FA2E-4C55-8A1F-D94ABB1A329F@umich.edu>
 <Pine.LNX.4.64.1311132047370.12253@whammy.cluebyfour.org>
 <70D7AF81-0FB6-4F07-9365-A3F773F46FE6@swbell.net>
Message-ID: <50DE6F70588444499E383C5102155B890179A5AD@energyops.lakelandenergy.local>

Here is a link to a Raycom Fosc that has pigtails and bulkheads in it that I'm guessing would suit your needs. We use them underground in vaults a various points where a pedestal doesn't make sense. You need to make sure there is proper drainage in the vault though....

Without knowing more about the physical facility, it's hard to know for sure what you need.

http://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&ved=0CGsQFjAJ&url=http%3A%2F%2Fwww.raycom.cz%2Fdl2%3Fid_download%3D164&ei=KS-FUpm3M-PayAGMkIDQDw&usg=AFQjCNGrdt4iDKOmh6CNXG4YtwxZocBJTw&bvm=bv.56343320,d.aWc&cad=rja 


Sam Roche - Supervisor of Network Operations - Lakeland Networks
sroche at lakelandnetworks.com| Office:? 705-640-0086? | Cell: 705-706-2606| www.lakelandnetworks.com



IT SOLUTIONS for BUSINESS
Fiber Optics, Wireless, DSL Network Provider; I.T. Support; Telephony Hardware and Cabling; SIP Trunks, VoIP; Server Hosting; Disaster Recovery Systems


"The information contained in this message is directed in confidence solely to the person(s) named above and may not be otherwise distributed, copied or disclosed.? The message may contain information that is privileged,?proprietary and/or confidential and exempt from disclosure under applicable law.? If you have received this message in error, please notify the sender immediately advising of the error and delete the message without making a copy."


-----Original Message-----
From: Thomas [mailto:gravestl at swbell.net] 
Sent: November-14-13 9:17 AM
To: Justin M. Streiner
Cc: nanog at nanog.org
Subject: Re: OT: Below grade fiber interconnect points

Another option is an above ground  cabinet.  Many telecoms use them.

Thomas L Graves
Sent from my IPhone 


> On Nov 13, 2013, at 8:04 PM, "Justin M. Streiner" <streiner at cluebyfour.org> wrote:
> 
>> On Wed, 13 Nov 2013, Roy Hockett wrote:
>> 
>> Thank you for comments. Let me clarify the situation.  We have a 
>> building that has been fiber cross connect location and is being 
>> demolished.  This location has about 20 fiber cable entering where we 
>> patch between fiber paths.  If we relocated these cross connect field 
>> to another building and that build is demolished we have to do this 
>> all over again, so the desire was to have an independent facility for 
>> the fiber cross connect field, but I am guessing due to esthetics the below ground vault was selected, we just learned of this selection and thus my query to this group to find other that have dealt with similar situations and if so, experience base recommendations, and things to be aware of.
> 
> If the vault has a controlled environment and access, similar to what you would find inside of a comms room, that's one thing.  If it's more like a typical manhole (damp, dirty, dark, possible temperature extremes, other utilities/hazards), then the only thing that should be in there is a water-tight splice case.  Fiber patches need to be in a clean environment.
> 
> Did this project provide any funds for relocation or replacement of the communications facilities that would be lost due to the demolition?  We've gone through this many times on our campus.
> 
> jms
> 



From william.allen.simpson at gmail.com  Thu Nov 14 21:03:01 2013
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Thu, 14 Nov 2013 16:03:01 -0500
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <B3A3F3E3-FA2E-4C55-8A1F-D94ABB1A329F@umich.edu>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
 <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
 <33902702-EABC-4C97-8907-A273CD7BDD92@swbell.net> <5284283D.3060307@utc.edu>
 <B3A3F3E3-FA2E-4C55-8A1F-D94ABB1A329F@umich.edu>
Message-ID: <52853A85.3070205@gmail.com>

On 11/13/13 11:51 PM, Roy Hockett wrote:
> I am guessing due to esthetics the below ground vault was selected, we just learned of this selection and thus
> my query to this group to find other that have dealt with similar situations and if so, experience base recommendations,
> and things to be aware of.
>
> Thanks,
> -Roy Hockett
>
> Network Architect,
> ITS Communications Systems and Data Centers
> University of Michigan
> Tel: (734) 763-7325
> Fax: (734) 615-1727
> email: royboy at umich.edu
>
I remember seeing a below grade vault here in Michigan once.  It was
purpose built (years ago for MCI IIRC), but I don't know by whom.
Heavy steel plate door on top, looked like those on major water pipe
vaults.  Likely built to similar civil engineering standards.  But
this was fairly early in the history of laying fiber, so there are
probably newer standards.

Off the top of my head, it had a lot of things concerned with water and
humidity -- dual redundant sump pumps, dual heaters mounted 6' off the
floor, an environmental monitoring panel, an exterior antennae pole for
out-of-band reporting from the monitoring panel.  I didn't have the
opportunity to open the fairly beefy looking power panel, so I don't
know whether there was a dual feed -- but it wouldn't surprise me.

As to cleanliness, it wasn't particularly clean, but not really dirty.
(Much like any exterior shopping center access demark, assuming you've
seen those.)

I also saw a Bell South below grade fiber vault once, but wouldn't
recommend it, as it was full of water at the time....  To be fair, I'm
not sure they had a cross-connect panel in there.



From kamtha at ak-labs.net  Thu Nov 14 22:02:00 2013
From: kamtha at ak-labs.net (Carlos Kamtha)
Date: Thu, 14 Nov 2013 17:02:00 -0500
Subject: List of CDNs?
Message-ID: <20131114220200.GA67966@ak-labs.net>

Hi,

I was wondering if anyone knows where I could find a compiled list of Content Delivery Networks as well
as thier DC nodes? if any..

Please respond offlist.

Cheers,
Carlos


From patrick at ianai.net  Thu Nov 14 22:11:59 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Thu, 14 Nov 2013 22:11:59 +0000
Subject: List of CDNs?
In-Reply-To: <20131114220200.GA67966@ak-labs.net>
References: <20131114220200.GA67966@ak-labs.net>
Message-ID: <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net>

List of CDNs would be difficult, but not impossible. Although they do different things, so a simple list is unlikely to be as useful as it looks. 

A lost of CDN "DC nodes" is not possible. Why do you care about such a thing anyway?

-- 
TTFN,
patrick

Composed on a virtual keyboard, please forgive typos. 


> On Nov 14, 2013, at 22:02, Carlos Kamtha <kamtha at ak-labs.net> wrote:
> 
> Hi,
> 
> I was wondering if anyone knows where I could find a compiled list of Content Delivery Networks as well
> as thier DC nodes? if any..
> 
> Please respond offlist.
> 
> Cheers,
> Carlos
> 


From andrew.fried at gmail.com  Thu Nov 14 22:19:48 2013
From: andrew.fried at gmail.com (Andrew Fried)
Date: Thu, 14 Nov 2013 17:19:48 -0500
Subject: List of CDNs?
In-Reply-To: <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net>
References: <20131114220200.GA67966@ak-labs.net>
 <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net>
Message-ID: <52854C84.6000204@gmail.com>

Actually, a list of CDNs would be very handy.  I harvest botnets and
fast flux hosts out of passive dns, and some of the heuristics used to
identify them are similar to what CDNs look like.

Having a decent list of CDN effective top level domains alone would be
useful for redacting those hosts.

Andy


Andrew Fried
andrew.fried at gmail.com

On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote:
> List of CDNs would be difficult, but not impossible. Although they do different things, so a simple list is unlikely to be as useful as it looks. 
> 
> A lost of CDN "DC nodes" is not possible. Why do you care about such a thing anyway?
> 


From kamtha at ak-labs.net  Thu Nov 14 22:25:49 2013
From: kamtha at ak-labs.net (Carlos Kamtha)
Date: Thu, 14 Nov 2013 17:25:49 -0500
Subject: List of CDNs?
In-Reply-To: <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net>
References: <20131114220200.GA67966@ak-labs.net>
 <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net>
Message-ID: <20131114222549.GB67966@ak-labs.net>


The goal is to find a solution to optimize the path for DNS queries that traverse via CDNs within certain regions 
without the luxury of a network layer. 

For instance, some clients in singapore are getting answers from the UK instead of something more local. 

Knowing where the CDNs are may allow us to direct them to a more optimal path. 

Cheers, 
Carlos. 

On Thu, Nov 14, 2013 at 10:11:59PM +0000, Patrick W. Gilmore wrote:
> List of CDNs would be difficult, but not impossible. Although they do different things, so a simple list is unlikely to be as useful as it looks. 
> 
> A lost of CDN "DC nodes" is not possible. Why do you care about such a thing anyway?
> 
> -- 
> TTFN,
> patrick
> 
> Composed on a virtual keyboard, please forgive typos. 
> 
> 
> > On Nov 14, 2013, at 22:02, Carlos Kamtha <kamtha at ak-labs.net> wrote:
> > 
> > Hi,
> > 
> > I was wondering if anyone knows where I could find a compiled list of Content Delivery Networks as well
> > as thier DC nodes? if any..
> > 
> > Please respond offlist.
> > 
> > Cheers,
> > Carlos
> > 


From simon at darkmere.gen.nz  Thu Nov 14 22:58:16 2013
From: simon at darkmere.gen.nz (Simon Lyall)
Date: Fri, 15 Nov 2013 11:58:16 +1300 (NZDT)
Subject: List of CDNs?
In-Reply-To: <20131114222549.GB67966@ak-labs.net>
References: <20131114220200.GA67966@ak-labs.net>
 <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net>
 <20131114222549.GB67966@ak-labs.net>
Message-ID: <alpine.DEB.2.02.1311151153120.22307@gold>


This guy has been maintaining a list for a few years:

http://www.cdnlist.com

although he doesn't seem to have done an update in about 12 months :(

How about:

http://www.cdnplanet.com/cdns/

Seriouslyy, these are 2 of the first 3 ghits for "CDN list"....

-- 
Simon Lyall  |  Very Busy  |  Web: http://www.darkmere.gen.nz/
"To stay awake all night adds a day to your life" - Stilgar | eMT.



From mcollins at aleae.com  Fri Nov 15 15:06:24 2013
From: mcollins at aleae.com (Michael Collins, Aleae)
Date: Fri, 15 Nov 2013 10:06:24 -0500
Subject: List of CDNs?
In-Reply-To: <52854C84.6000204@gmail.com>
References: <20131114220200.GA67966@ak-labs.net>
 <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net> <52854C84.6000204@gmail.com>
Message-ID: <52863870.5020607@aleae.com>

I'll second that; CDNs are a constant pain for me when I'm doing address
lookups.  A list of them would make life a lot easier for a bunch of
different investigative processes. 

If there isn't one right now, I think I could get off my tuchas and
start maintaining one if anyone's interested in pitching in.


On 11/14/13 5:19 PM, Andrew Fried wrote:
> Actually, a list of CDNs would be very handy.  I harvest botnets and
> fast flux hosts out of passive dns, and some of the heuristics used to
> identify them are similar to what CDNs look like.
>
> Having a decent list of CDN effective top level domains alone would be
> useful for redacting those hosts.
>
> Andy
>
>
> Andrew Fried
> andrew.fried at gmail.com
>
> On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote:
>> List of CDNs would be difficult, but not impossible. Although they do different things, so a simple list is unlikely to be as useful as it looks. 
>>
>> A lost of CDN "DC nodes" is not possible. Why do you care about such a thing anyway?
>>



From cscora at apnic.net  Fri Nov 15 18:10:43 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 16 Nov 2013 04:10:43 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201311151810.rAFIAhQJ031291@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, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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

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

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

Routing Table Report   04:00 +10GMT Sat 16 Nov, 2013

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

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

BGP routing table entries examined:                              472903
    Prefixes after maximum aggregation:                          189382
    Deaggregation factor:                                          2.50
    Unique aggregates announced to Internet:                     234611
Total ASes present in the Internet Routing Table:                 45459
    Prefixes per ASN:                                             10.40
Origin-only ASes present in the Internet Routing Table:           35351
Origin ASes announcing only one prefix:                           16281
Transit ASes present in the Internet Routing Table:                5951
Transit-only ASes present in the Internet Routing Table:            164
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      35
    Max AS path prepend of ASN ( 55644)                              31
Prefixes from unregistered ASNs in the Routing Table:              2046
    Unregistered ASNs in the Routing Table:                         428
Number of 32-bit ASNs allocated by the RIRs:                       5358
Number of 32-bit ASNs visible in the Routing Table:                4157
Prefixes from 32-bit ASNs in the Routing Table:                   13071
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:           1082
Number of addresses announced to Internet:                   2655478552
    Equivalent to 158 /8s, 71 /16s and 99 /24s
    Percentage of available address space announced:               71.7
    Percentage of allocated address space announced:               71.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               95.2
Total number of prefixes smaller than registry allocations:      165126

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

Prefixes being announced by APNIC Region ASes:                   111822
    Total APNIC prefixes after maximum aggregation:               33900
    APNIC Deaggregation factor:                                    3.30
Prefixes being announced from the APNIC address blocks:          114037
    Unique aggregates announced from the APNIC address blocks:    47694
APNIC Region origin ASes present in the Internet Routing Table:    4878
    APNIC Prefixes per ASN:                                       23.38
APNIC Region origin ASes announcing only one prefix:               1220
APNIC Region transit ASes present in the Internet Routing Table:    833
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         35
Number of APNIC region 32-bit ASNs visible in the Routing Table:    742
Number of APNIC addresses announced to Internet:              730096320
    Equivalent to 43 /8s, 132 /16s and 98 /24s
    Percentage of available APNIC address space announced:         85.3

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-63999, 131072-133631
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:                    163112
    Total ARIN prefixes after maximum aggregation:                81716
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           163887
    Unique aggregates announced from the ARIN address blocks:     76079
ARIN Region origin ASes present in the Internet Routing Table:    15916
    ARIN Prefixes per ASN:                                        10.30
ARIN Region origin ASes announcing only one prefix:                6004
ARIN Region transit ASes present in the Internet Routing Table:    1662
Average ARIN Region AS path length visible:                         4.1
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:      35
Number of ARIN addresses announced to Internet:              1073593728
    Equivalent to 63 /8s, 253 /16s and 189 /24s
    Percentage of available ARIN address space announced:          56.8

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8,
                       205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8,
                       216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    119356
    Total RIPE prefixes after maximum aggregation:                61017
    RIPE Deaggregation factor:                                     1.96
Prefixes being announced from the RIPE address blocks:           123088
    Unique aggregates announced from the RIPE address blocks:     78871
RIPE Region origin ASes present in the Internet Routing Table:    17517
    RIPE Prefixes per ASN:                                         7.03
RIPE Region origin ASes announcing only one prefix:                8304
RIPE Region transit ASes present in the Internet Routing Table:    2836
Average RIPE Region AS path length visible:                         5.1
    Max RIPE Region AS path length visible:                          31
Number of RIPE region 32-bit ASNs visible in the Routing Table:    2480
Number of RIPE addresses announced to Internet:               656752868
    Equivalent to 39 /8s, 37 /16s and 64 /24s
    Percentage of available RIPE address space announced:          95.5

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-200191
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:                   53151
    Total LACNIC prefixes after maximum aggregation:               9998
    LACNIC Deaggregation factor:                                   5.32
Prefixes being announced from the LACNIC address blocks:          58393
    Unique aggregates announced from the LACNIC address blocks:   27055
LACNIC Region origin ASes present in the Internet Routing Table:   2040
    LACNIC Prefixes per ASN:                                      28.62
LACNIC Region origin ASes announcing only one prefix:               551
LACNIC Region transit ASes present in the Internet Routing Table:   396
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        35
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   894
Number of LACNIC addresses announced to Internet:             143157748
    Equivalent to 8 /8s, 136 /16s and 105 /24s
    Percentage of available LACNIC address space announced:        85.3

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 262144-263679 plus 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:                  11783
    Total AfriNIC prefixes after maximum aggregation:              2598
    AfriNIC Deaggregation factor:                                  4.54
Prefixes being announced from the AfriNIC address blocks:         12416
    Unique aggregates announced from the AfriNIC address blocks:   4043
AfriNIC Region origin ASes present in the Internet Routing Table:   682
    AfriNIC Prefixes per ASN:                                     18.21
AfriNIC Region origin ASes announcing only one prefix:              202
AfriNIC Region transit ASes present in the Internet Routing Table:  138
Average AfriNIC Region AS path length visible:                      4.7
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    6
Number of AfriNIC addresses announced to Internet:             48082176
    Equivalent to 2 /8s, 221 /16s and 173 /24s
    Percentage of available AfriNIC address space announced:       47.8

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2931      11557         943   Korea Telecom (KIX)
17974     2713        902          88   PT TELEKOMUNIKASI INDONESIA
 7545     2108        319         110   TPG Internet Pty Ltd
 4755     1789        392         190   TATA Communications formerly 
 9829     1543       1245          45   BSNL National Internet Backbo
 9583     1242         94         508   Sify Limited
 9498     1215        309          74   BHARTI Airtel Ltd.
 7552     1165       1080          13   Vietel Corporation
 4808     1146       2124         339   CNCGROUP IP network: China169
24560     1096        380         163   Bharti Airtel Ltd., Telemedia

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
 6389     3051       3688          55   BellSouth.net Inc.
22773     2198       2939         138   Cox Communications, Inc.
18566     2057        379         178   MegaPath Corporation
 1785     2039        685         130   PaeTec Communications, Inc.
20115     1682       1654         607   Charter Communications 
 4323     1636       1098         417   Time Warner Telecom
  701     1507      11146         783   MCI Communications Services, 
30036     1382        311         583   Mediacom Communications Corp 
 7018     1332      17778         871   AT&T WorldNet Services
 6983     1293        755         578   ITC^Deltacom 

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
 8402     1959        544          17   OJSC "Vimpelcom"
34984     1363        244         223   TELLCOM ILETISIM HIZMETLERI A
20940     1125        417         854   Akamai Technologies European 
31148     1005         45          19   FreeNet ISP
13188      895         99          48   TOV "Bank-Inform"
 6849      861        356          30   JSC UKRTELECOM,
 8551      787        370          41   Bezeq International
 6830      774       2328         426   UPC Distribution Services
12479      680        798          55   Uni2 Autonomous System
35228      547        246          16   Avatar Broadband Limited

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
28573     3423       1793          87   NET Servicos de Comunicao S.A
10620     2666        432         219   Telmex Colombia S.A.
 7303     1728       1150         231   Telecom Argentina Stet-France
18881     1621        908          20   Global Village Telecom 
 8151     1362       2853         414   UniNet S.A. de C.V. 
11830      866        364          15   Instituto Costarricense de El
27947      846         93          90   Telconet S.A
 6147      813        373          27   Telefonica Del Peru 
 6503      793        434          62   AVANTEL, S.A. 
 7738      780       1498          36   Telecomunicacoes da Bahia S.A

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
36998     1864        112           5   Sudanese Mobile Telephone (ZA
24863      887        338          26   LINKdotNET AS number
 6713      554        633          26   Itissalat Al-MAGHRIB
 8452      418        956           9   TEDATA
24835      297        144           9   RAYA Telecom - Egypt
 3741      256        921         214   The Internet Solution 
36992      229        501          29   Etisalat MISR
29571      224         17          12   Ci Telecom Autonomous system 
15706      221         32           6   Sudatel Internet Exchange Aut
29975      192        668          21   Vodacom

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
28573     3423       1793          87   NET Servicos de Comunicao S.A
 6389     3051       3688          55   BellSouth.net Inc.
 4766     2931      11557         943   Korea Telecom (KIX)
17974     2713        902          88   PT TELEKOMUNIKASI INDONESIA
10620     2666        432         219   Telmex Colombia S.A.
22773     2198       2939         138   Cox Communications, Inc.
 7545     2108        319         110   TPG Internet Pty Ltd
18566     2057        379         178   MegaPath Corporation
 1785     2039        685         130   PaeTec Communications, Inc.
 8402     1959        544          17   OJSC "Vimpelcom"

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

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

  ASN   No of nets  Net Savings Description
 6389      3051        2996      BellSouth.net Inc.
17974      2713        2625      PT TELEKOMUNIKASI INDONESIA
10620      2666        2447      Telmex Colombia S.A.
22773      2198        2060      Cox Communications, Inc.
 7545      2108        1998      TPG Internet Pty Ltd
 4766      2931        1988      Korea Telecom (KIX)
 8402      1959        1942      OJSC "Vimpelcom"
 1785      2039        1909      PaeTec Communications, Inc.
18566      2057        1879      MegaPath Corporation
36998      1864        1859      Sudanese Mobile Telephone (ZA

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

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

Bad AS  Designation  Network              Transit AS  Description
62828   UNALLOCATED  8.21.130.0/24         4323       Time Warner Telecom
62850   UNALLOCATED  8.25.147.0/24         3356       Level 3 Communicatio
62734   UNALLOCATED  8.31.128.0/24         6939       Hurricane Electric 
62773   UNALLOCATED  8.35.180.0/22         3356       Level 3 Communicatio
65160   PRIVATE      12.1.58.0/24         17361       Sungard Trading Syst
65160   PRIVATE      12.1.59.0/24         17361       Sungard Trading Syst
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
62719   UNALLOCATED  12.27.130.0/24        4323       Time Warner Telecom
62861   UNALLOCATED  12.37.197.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic

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

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.100.0.0/24        4847     China Networks Inter-Exchange

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

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

Network            Origin AS  Description
23.90.128.0/18       27418     OUTOFWALL INC.
23.91.0.0/19         40676     Psychz Networks 
23.91.4.0/24         40676     Psychz Networks 
23.91.14.0/24        40676     Psychz Networks 
23.91.32.0/19        36315     Servpac Inc. 
23.91.80.0/20        21560     Capital Technology Services G
23.91.96.0/20        37958     ChinaCache Networks ASN
23.91.112.0/21       32475     MidPhase Inc. 
23.91.160.0/19       36493     3757277 Canada Inc. (oa 295.c
23.91.160.0/22       36493     3757277 Canada Inc. (oa 295.c

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:11      /10:31      /11:92      /12:254     
/13:474     /14:922     /15:1628    /16:12833   /17:6760    /18:11334   
/19:23102   /20:32903   /21:35605   /22:50000   /23:43850   /24:250577  
/25:875     /26:997     /27:472     /28:51      /29:81      /30:21      
/31:0       /32:14      

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

  ASN   No of nets  Total ann.   Description
18566     2011          2057      MegaPath Corporation
36998     1829          1864      Sudanese Mobile Telephone (ZA
 6389     1705          3051      BellSouth.net Inc.
 8402     1622          1959      OJSC "Vimpelcom"
22773     1457          2198      Cox Communications, Inc.
30036     1228          1382      Mediacom Communications Corp 
11492     1193          1231      Cable One 
 1785     1086          2039      PaeTec Communications, Inc.
 6983     1034          1293      ITC^Deltacom 
22561      965          1242      Digital Teleport, Inc 

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

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

   1:899       2:842       3:3         4:17        5:1025      6:21     
   8:620      12:1883     13:3        14:891      15:11       16:3      
  17:17       18:19       20:21       23:560      24:1746     27:1643   
  31:1445     32:44       33:2        34:5        36:86       37:1923   
  38:919      39:5        40:182      41:3265     42:274      44:14     
  46:2032     47:10       49:689      50:846      52:12       54:43     
  55:7        56:4        57:26       58:1166     59:574      60:378    
  61:1468     62:1242     63:1979     64:4330     65:2344     66:4148   
  67:2118     68:1109     69:3299     70:875      71:489      72:2043   
  74:2563     75:326      76:307      77:1156     78:1077     79:673    
  80:1300     81:1039     82:646      83:660      84:591      85:1257   
  86:383      87:1027     88:557      89:1557     90:150      91:5657   
  92:622      93:1610     94:2066     95:1631     96:512      97:350    
  98:1039     99:41      100:32      101:643     103:3616    105:527    
 106:140     107:217     108:536     109:1948    110:972     111:1114   
 112:595     113:808     114:748     115:1052    116:1013    117:823    
 118:1179    119:1279    120:336     121:751     122:1859    123:1265   
 124:1398    125:1429    128:680     129:229     130:332     131:660    
 132:365     133:158     134:558     135:72      136:283     137:249    
 138:351     139:176     140:198     141:331     142:545     143:416    
 144:502     145:90      146:530     147:409     148:782     149:368    
 150:139     151:653     152:411     153:205     154:53      155:497    
 156:294     157:421     158:280     159:782     160:361     161:458    
 162:857     163:223     164:636     165:588     166:260     167:634    
 168:1044    169:125     170:1119    171:185     172:27      173:1589   
 174:696     175:526     176:1309    177:2476    178:1975    179:302    
 180:1591    181:865     182:1376    183:466     184:658     185:1024   
 186:2610    187:1467    188:1877    189:1265    190:7307    192:7055   
 193:5426    194:4037    195:3363    196:1342    197:1039    198:4760   
 199:5489    200:6070    201:2521    202:8982    203:8884    204:4534   
 205:2651    206:2837    207:2830    208:4002    209:3653    210:3038   
 211:1568    212:2159    213:1976    214:906     215:91      216:5421   
 217:1693    218:627     219:323     220:1278    221:578     222:326    
 223:507    

End of report


From rejchrt at ics.muni.cz  Fri Nov 15 15:02:47 2013
From: rejchrt at ics.muni.cz (Jan Rejchrt)
Date: Fri, 15 Nov 2013 16:02:47 +0100
Subject: Network anomaly research - survey
Message-ID: <52863797.2010700@ics.muni.cz>

Dear network experts,

We would like to kindly ask you to devote a few minutes of your time to
filling out our short survey.

Your professional opinion will help to develop better anomaly detection tools. We are trying to learn how the term "network anomaly" is understood by experts and network administrators. Our findings will then be made available to the network monitoring community and posted to this mailing list.


The survey is available via the following link till end of this year.
 https://security.ics.muni.cz/anomaly_survey/

Thank you for your time and best regards,

Jan Rejchrt
On behalf of CSIRT-MU

-- 
Mgr. Jan Rejchrt                                   rejchrt at ics.muni.cz
Security Department, CSIRT-MU group                http://csirt.muni.cz
Institute of Computer Science, Masaryk University, Brno, Czech Republic
PGP Key ID: 0x9B5724C8


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131115/bb7c6422/attachment-0001.bin>

From michael at rancid.berkeley.edu  Fri Nov 15 19:31:52 2013
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Fri, 15 Nov 2013 11:31:52 -0800
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
References: <2D031E2F-96CC-4BE4-B742-686DAD1D9CC5@umich.edu>
 <Pine.LNX.4.64.1311131454580.10084@whammy.cluebyfour.org>
Message-ID: <528676A8.2040800@rancid.berkeley.edu>

Hi Justin and Roy:

On 11/13/13 12:05, Justin M. Streiner wrote:
> On Wed, 13 Nov 2013, Roy hockett wrote:
> 
>> Has anyone ever used a below grade vault for housing fiber cross
>> connects?
>>
>> We have to move a fiber interconnect facility due to the current
>> building being demolished.  If you have I would be interested in
>> talking to you.  If there are more appropriate lists, I would
>> appreciate any suggestions.
> 
> When you say "below grade vault", do you mean something that's only
> accessible through a manhole?

In the case of CEVs, it's actually a "doghouse," an access-controlled
(cyber-lock or similar cylinder plus alarm system) entrance which also
houses the HVAC machinery.  See below.

> 
> I haven't done this specifically, however if the vault does not have a
> controlled environment, you could be dealing with massive headaches
> related to dust/dirt contamination, moisture penetration, etc.

UC Berkeley installed 3 CEVs (Controlled Environment Vaults) below
ground on campus about 10-15 years ago.  One of them houses one of the
two main fiber penetrations to campus, including DWDM gear,
patch-panels, border routers, even packetshapers (back when those were
relevant in a large EDU environment), servers, WiFi portals, etc.  This
stuff has all been in place for at least 10 years and has worked really
well, modulo the caveats below.  Two of the vaults have 6-7 19" telco
racks, and one (the one with the big fiber entrance) also has a 23" rack
in addition to the others.

Caveats:

o It's hard to physically get equipment into the vault.  You'll often
need a hand-crane/winch for smaller items (servers, switches, small
routers), and a powered crane (one of those small ones that goes in the
back of a pickup truck) for larger items.  We've managed to put things
as big as a Juniper M120 in the CEV, and we have probably gotten bigger
stuff down there.  But it's not just as trivial as loading it onto a
hand-cart and wheeling it in.

o HVAC issues happen everywhere, but we've had to completely overhaul
the HVAC on one of the CEVs about 2-3 years ago (right around the time I
left UCB).  They were throwing more heat at the HVAC than was specified,
and there were a lot of custom parts for the doghouse enclosure that
weren't available anymore.  So you may find that you need to allocate
more budget to maintenance for HVAC (as well as sump pumps, CO sniffers,
etc.).

o The larger of the three CEVs had an encounter with the Highway 24
Freeway overcrossing over Telegraph Avenue and had to be repaired before
installation.  (The CEVs are divided horizontally, so that there is a
top piece and a bottom piece that get installed in the ground in
sequence and then are sealed up.  In this case the top
piece--specifically the doghouse assembly--got crashed into the bridge.)
 It was repaired and has been fine, but you may have to deal with issues
like that.

o Do not wear a skirt, dress, or kilt when entering the CEV.  The
updraft of ventilation will cause issues as you climb down.  (Sounds
silly, but I have actually had to advise folks to wear long pants based
on the experiences of a manager who was touring the CEV one day.)

> I work
> in a large-campus .edu environment, so I'm some of the headaches you're
> probably trying to avoid.  Also, be aware that access to the vault could
> be an issue.  There are OSHA regs related to what sort of training and
> safety equipment someone who will be working in an underground vault
> must have.

Yes.  We have all had to go through the required OSHA training for
confined spaces and ladder safety.  The CEV system must also have a CO
sniffer, sump pump, etc.  We had a very lightweight lock-out-tag-out
system that basically involved calling the NOC when entering and exiting
the vault and also logging that information in a logbook physically at
the vault.

> I'm assuming that the fiber will be cross-connected to a new location
> prior to the building being demolished.

Been there, done that as well.  UCB had a big fiber re-splicing about 4
years ago, back when I still worked there.  In this particular case, it
went into a regular building, but the setup was similar to that of the
CEVs (it was the redundant entrance to the campus for one of the CEVs).

> Not knowing your outside plant or circumstances, would it be feasible to
> fusion-splice a new tail onto the fiber that was going to the building
> that's being demolished, or (ideally) pulling a new piece of fiber to
> the new building, so you don't have to deal with potentially dodgy splices?

So, if it's like what was done at UCB, the fiber was disconnected
(starting at 5pm, since an entire building would be down for _each_
bundle of fiber that was done) from the panel in the old building and
back-pulled to the nearest CV (not controlled environment).  It was
re-spliced in that CV and routed to the new building, reterminated and
reconnected to a new switch to bring the building back up.  (Some
bundles didn't need to be spliced, since it was a shorter path to the
new building.)  This is all doable within a CEV environment as well, and
it requires pretty much the same level of coordination and project
management.

michael



From jra at baylink.com  Fri Nov 15 20:29:42 2013
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 15 Nov 2013 15:29:42 -0500 (EST)
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <528676A8.2040800@rancid.berkeley.edu>
Message-ID: <19740419.1690.1384547382510.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Michael Sinatra" <michael at rancid.berkeley.edu>

> UC Berkeley installed 3 CEVs (Controlled Environment Vaults) below
> ground on campus about 10-15 years ago. One of them houses one of the
> two main fiber penetrations to campus, including DWDM gear,
> patch-panels, border routers, even packetshapers (back when those were
> relevant in a large EDU environment), servers, WiFi portals, etc. This
> stuff has all been in place for at least 10 years and has worked really
> well, modulo the caveats below. Two of the vaults have 6-7 19" telco
> racks, and one (the one with the big fiber entrance) also has a 23"
> rack in addition to the others.
> 
> Caveats:

[ 17 pages of caveats elided ]

So, the elephant in the room at this stage of the thing is this:

Why don't you just *put this stuff in a building*, and, y'know, never
demolish it?

Yes, you'll probably have to build it to CO grade standards, but that 
isn't exactly rocket surgery, and it seems to me that you peel
3 or 4 layers of crap off the top doing it that way.

Unless you're in, say, the Philippines, I can't see the advantage of
burying all that stuff underground on a campus-scale deployment.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From michael at rancid.berkeley.edu  Fri Nov 15 20:58:57 2013
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Fri, 15 Nov 2013 12:58:57 -0800
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <19740419.1690.1384547382510.JavaMail.root@benjamin.baylink.com>
References: <19740419.1690.1384547382510.JavaMail.root@benjamin.baylink.com>
Message-ID: <52868B11.7030004@rancid.berkeley.edu>

On 11/15/13 12:29, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Michael Sinatra" <michael at rancid.berkeley.edu>
> 
>> UC Berkeley installed 3 CEVs (Controlled Environment Vaults) below
>> ground on campus about 10-15 years ago. One of them houses one of the
>> two main fiber penetrations to campus, including DWDM gear,
>> patch-panels, border routers, even packetshapers (back when those were
>> relevant in a large EDU environment), servers, WiFi portals, etc. This
>> stuff has all been in place for at least 10 years and has worked really
>> well, modulo the caveats below. Two of the vaults have 6-7 19" telco
>> racks, and one (the one with the big fiber entrance) also has a 23"
>> rack in addition to the others.
>>
>> Caveats:
> 
> [ 17 pages of caveats elided ]

I realize I am wordy, but four bullet points (one of which involves
apparel) != "17 pages of caveats".  Nice try.  The rest of the email was
inline replies to Justin's points.

> So, the elephant in the room at this stage of the thing is this:
> 
> Why don't you just *put this stuff in a building*, and, y'know, never
> demolish it?

Have you ever been involved in University space wars?  Especially in a
new building?  The 9-layer OSI model gets pretty top-heavy when you
factor that in.  If anything, the caveats helped to keep others from
wanting to use the space.

But I will say that the general difficulty of getting equipment in and
out of the CEVs generally discouraged UCB from doing more CEVs beyond
the 3 originals.  That _one_ caveat weighed pretty heavily.

michael



From dave at temk.in  Fri Nov 15 21:16:51 2013
From: dave at temk.in (David Temkin)
Date: Fri, 15 Nov 2013 16:16:51 -0500
Subject: Data Center and IX Standards Published by Open-IX - Certification
 begins soon!
Message-ID: <CAFJiuFqRxjKgbQcBch_J6L_XoCst2mDXBXz5WT5ewR2M0kQ-og@mail.gmail.com>

I am proud to announce that the final versions of the Data Center and IXP
standards have been completed by their respective working groups and have
been published.

Data Center: http://goo.gl/s4cGBp

IXP: http://goo.gl/O5I1my

Martin Hannigan will follow up shortly with scheduled dates for accepting
applications to become Open-IX Certified.  We intend on accepting
applications for Northern Virginia first, immediately followed by NYC and
other markets.

Regards,
-Dave Temkin
Chair, Open-IX Association

From jra at baylink.com  Fri Nov 15 21:25:42 2013
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 15 Nov 2013 16:25:42 -0500 (EST)
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <52868B11.7030004@rancid.berkeley.edu>
Message-ID: <9857094.1810.1384550742145.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Michael Sinatra" <michael at rancid.berkeley.edu>

> >> Caveats:
> >
> > [ 17 pages of caveats elided ]
> 
> I realize I am wordy, but four bullet points (one of which involves
> apparel) != "17 pages of caveats". Nice try. The rest of the email was
> inline replies to Justin's points.

We're not supposed to use emoticons on NANOG; it's unprofessional or
something.  :-)

> > So, the elephant in the room at this stage of the thing is this:
> >
> > Why don't you just *put this stuff in a building*, and, y'know,
> > never demolish it?
> 
> Have you ever been involved in University space wars? Especially in a
> new building? The 9-layer OSI model gets pretty top-heavy when you
> factor that in. If anything, the caveats helped to keep others from
> wanting to use the space.

Nope.  But this isn't "space".  It's "equipment".  I assume they're
not moving their 1.5MW gensets around every year either?

> But I will say that the general difficulty of getting equipment in and
> out of the CEVs generally discouraged UCB from doing more CEVs beyond
> the 3 originals. That _one_ caveat weighed pretty heavily.

Yeah; cranes are a bitch.  :-)

You seem to be taking this awfully personally, though, Mike; did you
*set* the policies and procedures I'm scoffing at? 

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From gary.buhrmaster at gmail.com  Fri Nov 15 21:45:07 2013
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 15 Nov 2013 21:45:07 +0000
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <9857094.1810.1384550742145.JavaMail.root@benjamin.baylink.com>
References: <52868B11.7030004@rancid.berkeley.edu>
 <9857094.1810.1384550742145.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAMfXtQzPzDMuGEfOjo3_pS0YXd5iffJw7SBfBWJ5AM0iBjQqZw@mail.gmail.com>

On Fri, Nov 15, 2013 at 9:25 PM, Jay Ashworth <jra at baylink.com> wrote:
...
> Yeah; cranes are a bitch.  :-)

No, it is arranging for a rigging crew and the
safety plan reviews for the lift (at least in any
major company/institution which wants to
stay on the happy side of OSHA; and has
consul that suggests that the risks of not
following the process is likely a CEE).

Gary


From cidr-report at potaroo.net  Fri Nov 15 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 15 Nov 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201311152200.rAFM004a026846@wattle.apnic.net>

This report has been generated at Fri Nov 15 21:13:34 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        08-11-13    482564      272254
        09-11-13    482563      271900
        10-11-13    482880      273274
        11-11-13    482972      273298
        12-11-13    483067      273564
        13-11-13    483213      273544
        14-11-13    485555      273300
        15-11-13    485585      273226


AS Summary
         45610  Number of ASes in routing system
         18728  Number of ASes announcing only one prefix
          4208  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      118835968  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 15Nov13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     484140   273313   210827    43.5%   All ASes

AS28573     3423       88     3335    97.4%   NET Servi?os de Comunica??o
                                               S.A.
AS6389      3050       58     2992    98.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS17974     2712      169     2543    93.8%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS7029      4208     1734     2474    58.8%   WINDSTREAM - Windstream
                                               Communications Inc
AS4766      2931      952     1979    67.5%   KIXS-AS-KR Korea Telecom
AS10620     2666     1056     1610    60.4%   Telmex Colombia S.A.
AS18881     1621       82     1539    94.9%   Global Village Telecom
AS18566     2056      566     1490    72.5%   MEGAPATH5-US - MegaPath
                                               Corporation
AS36998     1864      375     1489    79.9%   SDN-MOBITEL
AS4323      2956     1525     1431    48.4%   TWTC - tw telecom holdings,
                                               inc.
AS7303      1728      469     1259    72.9%   Telecom Argentina S.A.
AS1785      2039      820     1219    59.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1789      586     1203    67.2%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1198      139     1059    88.4%   VIETEL-AS-AP Vietel
                                               Corporation
AS22561     1242      221     1021    82.2%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS22773     2200     1266      934    42.5%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS9829      1544      631      913    59.1%   BSNL-NIB National Internet
                                               Backbone
AS35908      911       90      821    90.1%   VPLSNET - Krypt Technologies
AS7545      2109     1299      810    38.4%   TPG-INTERNET-AP TPG Telecom
                                               Limited
AS18101      982      180      802    81.7%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4788       868       68      800    92.2%   TMNET-AS-AP TM Net, Internet
                                               Service Provider
AS4808      1146      401      745    65.0%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS24560     1096      365      731    66.7%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS701       1507      785      722    47.9%   UUNET - MCI Communications
                                               Services, Inc. d/b/a Verizon
                                               Business
AS6983      1294      579      715    55.3%   ITCDELTA - ITC^Deltacom
AS8151      1368      655      713    52.1%   Uninet S.A. de C.V.
AS13977      853      144      709    83.1%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS6147       813      108      705    86.7%   Telefonica del Peru S.A.A.
AS4780      1002      307      695    69.4%   SEEDNET Digital United Inc.
AS8402      1922     1240      682    35.5%   CORBINA-AS OJSC "Vimpelcom"

Total      55098    16958    38140    69.2%   Top 30 total


Possible Bogus Routes

        23.255.0.0/17        AS11878 TZULO - tzulo, inc.
        27.54.116.0/22       AS55452 
        27.54.116.0/24       AS55452 
        27.54.119.0/24       AS55452 
        27.100.7.0/24        AS56096 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        63.247.0.0/19        AS226   LOS-NETTOS-AS - Los Nettos
        63.247.0.0/24        AS27609 
        63.247.1.0/24        AS27609 
        63.247.2.0/24        AS27609 
        63.247.3.0/24        AS27609 
        63.247.4.0/24        AS27609 
        63.247.5.0/24        AS27609 
        63.247.6.0/24        AS27609 
        63.247.7.0/24        AS27609 
        63.247.8.0/24        AS27609 
        63.247.9.0/24        AS27609 
        63.247.10.0/24       AS27609 
        63.247.11.0/24       AS27609 
        63.247.12.0/24       AS27609 
        63.247.13.0/24       AS27609 
        63.247.14.0/24       AS27609 
        63.247.15.0/24       AS27609 
        63.247.16.0/24       AS27609 
        63.247.17.0/24       AS27609 
        63.247.18.0/24       AS27609 
        63.247.19.0/24       AS27609 
        63.247.20.0/24       AS27609 
        63.247.21.0/24       AS27609 
        63.247.22.0/24       AS27609 
        63.247.23.0/24       AS27609 
        63.247.24.0/24       AS27609 
        63.247.25.0/24       AS27609 
        63.247.26.0/24       AS27609 
        63.247.27.0/24       AS27609 
        63.247.28.0/24       AS27609 
        63.247.29.0/24       AS27609 
        64.25.16.0/23        AS19535 
        64.25.20.0/24        AS19535 
        64.25.21.0/24        AS19535 
        64.25.22.0/24        AS19535 
        64.25.27.0/24        AS7046  RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business
        64.111.0.0/20        AS8039  CCC-ASN-1 - Cinergy Communications
        64.111.160.0/20      AS40551 
        64.111.160.0/24      AS40551 
        64.111.161.0/24      AS40551 
        64.111.162.0/24      AS40551 
        64.111.167.0/24      AS40551 
        64.111.169.0/24      AS40551 
        64.111.170.0/24      AS40551 
        64.111.171.0/24      AS40551 
        64.111.172.0/24      AS40551 
        64.111.173.0/24      AS40551 
        64.111.174.0/24      AS40551 
        64.111.175.0/24      AS40551 
        64.185.224.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.225.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.226.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.227.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.228.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.229.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.230.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.231.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.232.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.233.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.234.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.235.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.236.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.237.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.238.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.239.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.202.48.0/22       AS23380 
        64.202.52.0/23       AS23380 
        64.202.54.0/24       AS23380 
        64.202.55.0/24       AS23380 
        64.202.56.0/22       AS23380 
        64.202.60.0/24       AS23380 
        64.202.61.0/24       AS23380 
        64.202.62.0/24       AS23380 
        64.202.63.0/24       AS23380 
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global
        66.11.112.0/20       AS14572 
        66.55.96.0/23        AS17203 
        66.55.98.0/24        AS17203 
        66.55.99.0/24        AS17203 
        66.55.100.0/22       AS17203 
        66.55.102.0/23       AS17203 
        66.55.104.0/21       AS17203 
        66.180.64.0/21       AS32558 ZEUTER - Zeuter Development Corporation
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.187.240.0/20      AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        66.206.208.0/22      AS23380 
        66.206.211.0/24      AS14288 MPINET - MPInet
        66.206.212.0/24      AS23380 
        66.206.213.0/24      AS14288 MPINET - MPInet
        66.206.214.0/24      AS23380 
        66.206.215.0/24      AS23380 
        66.206.216.0/23      AS14288 MPINET - MPInet
        66.206.218.0/23      AS23380 
        66.206.220.0/22      AS23380 
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.254.160.0/20      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.176.0/21      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.184.0/22      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.188.0/22      AS35916 MULTA-ASN1 - MULTACOM CORPORATION
        67.21.144.0/22       AS174   COGENT Cogent/PSI
        67.21.148.0/22       AS174   COGENT Cogent/PSI
        68.69.96.0/21        AS32986 
        68.69.96.0/24        AS32986 
        68.69.104.0/21       AS32986 
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.19.0.0/19         AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        72.35.224.0/22       AS30097 NUWAVE - NuWave
        72.35.229.0/24       AS30188 TELEVERGENCE - Televergence Solutions Inc.
        72.35.232.0/21       AS6246  AVALONTEL - AvalonTel
        72.44.16.0/20        AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC
        74.112.100.0/22      AS16764 
        74.113.200.0/23      AS46939 
        74.114.52.0/22       AS40818 
        74.114.140.0/22      AS32757 
        74.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        74.118.132.0/22      AS5117  
        91.193.60.0/22       AS3356  LEVEL3 Level 3 Communications
        91.195.66.0/23       AS3356  LEVEL3 Level 3 Communications
        91.197.36.0/22       AS43359 
        91.199.90.0/24       AS44330 
        91.200.188.0/22      AS44016 
        91.207.152.0/24      AS64100 
        91.207.153.0/24      AS64100 
        91.209.115.0/24      AS31103 KEYWEB-AS Keyweb AG
        91.212.54.0/24       AS21409 IKOULA Ikoula Net SAS
        93.190.8.0/24        AS47254 
        93.190.9.0/24        AS47254 
        93.190.10.0/24       AS47254 
        100.100.0.0/24       AS4847  CNIX-AP China Networks Inter-Exchange
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. 
        103.11.1.0/24        AS9822  AMNET-AU-AP Amnet IT Services Pty Ltd
        103.13.184.0/23      AS58674 
        115.166.130.0/23     AS45423 
        115.166.132.0/24     AS45423 
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        124.64.0.0/10        AS4847  CNIX-AP China Networks Inter-Exchange
        164.40.184.0/24      AS19821 
        164.138.96.0/23      AS58101 
        164.138.96.0/24      AS58101 
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.116.0.0/24       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        174.136.192.0/18     AS14572 
        185.40.148.0/22      AS42493 TELELORCA-AS Lorca TV Sol S.L
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA LTDA
        190.15.72.0/21       AS15146 CABLEBAHAMAS - Cable Bahamas
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        192.166.32.0/20      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        193.9.59.0/24        AS1257  TELE2
        193.22.224.0/20      AS3322  
        193.22.238.0/23      AS6824  HERMES-NETWORK Hermes Telecom International Ltd
        193.33.66.0/23       AS39874 
        193.109.15.0/24      AS12690 MKSNET-AS MKS Autonomous System
        193.164.152.0/24     AS3356  LEVEL3 Level 3 Communications
        193.178.217.0/24     AS20737 
        193.188.252.0/24     AS8697  JTC-AS8697 Jordan Telecommunications Company
        193.202.8.0/21       AS3322  
        193.254.218.0/23     AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC
        194.50.82.0/24       AS16276 OVH OVH Systems
        194.63.152.0/22      AS3356  LEVEL3 Level 3 Communications
        194.79.48.0/22       AS39117 
        194.113.27.0/24      AS12518 SHLINK SHLINK Internet Service
        194.126.219.0/24     AS34545 
        195.85.239.0/24      AS29324 
        195.114.4.0/23       AS41158 
        195.128.240.0/23     AS21202 DCSNET-AS Bredband2 AB
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA
        195.234.156.0/24     AS25028 
        195.248.240.0/23     AS34169 MEDIA-COM-TYCHY Media-Com Sp. z o.o.
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.58.248.0/21      AS27849 
        201.71.16.0/20       AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.49.33.0/24       AS7657  VODAFONE-NZ-NGN-AS Vodafone NZ Ltd.
        202.58.113.0/24      AS19161 
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.86.216.0/23      AS38212 
        202.86.220.0/24      AS38212 
        202.86.222.0/24      AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.94.81.0/24       AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.142.219.0/24     AS45149 
        203.191.48.0/20      AS24175 VINAREN-AS-AP VietNam Research and Education Network
        203.191.56.0/21      AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service
        204.9.32.0/24        AS25617 
        204.9.33.0/24        AS25617 
        204.9.34.0/24        AS25617 
        204.9.35.0/24        AS25617 
        204.9.116.0/22       AS30097 NUWAVE - NuWave
        204.10.88.0/21       AS3356  LEVEL3 Level 3 Communications
        204.10.92.0/23       AS30097 NUWAVE - NuWave
        204.10.94.0/23       AS30097 NUWAVE - NuWave
        204.15.208.0/22      AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC
        204.69.144.0/24      AS27283 RJF-INTERNET - Raymond James Financial, Inc.
        204.106.16.0/24      AS4323  TWTC - tw telecom holdings, inc.
        204.115.110.0/23     AS53709 
        204.115.250.0/24     AS32880 SMOOTHSTONE-IP-COMMUNICATIONS-CORP - Smoothstone IP Communications Corporation
        204.115.251.0/24     AS32880 SMOOTHSTONE-IP-COMMUNICATIONS-CORP - Smoothstone IP Communications Corporation
        204.115.252.0/23     AS32880 SMOOTHSTONE-IP-COMMUNICATIONS-CORP - Smoothstone IP Communications Corporation
        204.187.11.0/24      AS51113 ELEKTA-AS Elekta
        204.225.173.0/24     AS6407  PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
        205.159.44.0/24      AS40157 ADESA-CORP-AS - ADESA Corp
        205.207.66.0/24      AS15290 ALLST-15290 - Allstream Corp.
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network
        205.236.71.0/24      AS852   ASN852 - TELUS Communications Inc.
        206.81.112.0/20      AS32618 ADKNO-KC - Adknowledge, Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        206.221.176.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.177.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.178.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.179.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.180.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.181.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.182.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.183.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.184.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.185.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.186.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.187.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.188.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.189.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.190.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.191.0/24     AS27431 JTLNET - JTL Networks Inc.
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        207.254.128.0/21     AS30689 FLOW-NET - FLOW
        207.254.128.0/24     AS30689 FLOW-NET - FLOW
        207.254.136.0/21     AS30689 FLOW-NET - FLOW
        208.66.120.0/22      AS32757 
        208.68.180.0/22      AS4323  TWTC - tw telecom holdings, inc.
        208.74.224.0/22      AS174   COGENT Cogent/PSI
        208.75.152.0/21      AS32146 
        208.76.20.0/24       AS31812 
        208.76.21.0/24       AS31812 
        208.77.164.0/24      AS22659 
        208.77.165.0/24      AS22659 
        208.77.166.0/24      AS22659 
        208.77.167.0/24      AS22659 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.84.232.0/24      AS33131 
        208.84.234.0/24      AS33131 
        208.84.237.0/24      AS33131 
        208.84.238.0/24      AS33131 
        208.85.116.0/23      AS25956 ALPHEUS - Alpheus Data Services, L.L.C.
        208.85.212.0/22      AS32618 ADKNO-KC - Adknowledge, Inc.
        208.89.32.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.33.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.34.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.35.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.90.64.0/22       AS16415 PRCNET-DOM - Precision Response Corporation
        208.91.72.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.73.0/24       AS65160 -Private Use AS-
        208.91.76.0/23       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        208.91.164.0/22      AS46099 
        208.92.224.0/22      AS32757 
        208.92.226.0/24      AS32757 
        209.161.96.0/20      AS8039  CCC-ASN-1 - Cinergy Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.193.112.0/20     AS209   ASN-QWEST-US NOVARTIS-DMZ-US
        209.209.51.0/24      AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.
        209.209.64.0/20      AS46851 IPARADIGMS - iParadigms, LLC
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.234.112.0/23     AS32252 
        209.234.114.0/23     AS32252 
        209.234.116.0/24     AS32252 
        209.234.117.0/24     AS32252 
        209.234.118.0/24     AS32252 
        209.234.119.0/24     AS32252 
        209.234.120.0/24     AS32252 
        209.234.121.0/24     AS32252 
        209.234.122.0/24     AS32252 
        212.119.32.0/19      AS12550 
        213.184.64.0/24      AS13071 
        213.184.65.0/24      AS13071 
        213.184.66.0/24      AS13071 
        213.184.67.0/24      AS13071 
        213.184.68.0/24      AS13071 
        213.184.69.0/24      AS13071 
        213.184.70.0/24      AS13071 
        213.184.71.0/24      AS13071 
        213.184.72.0/24      AS13071 
        213.184.73.0/24      AS13071 
        213.184.74.0/24      AS13071 
        213.184.75.0/24      AS13071 
        213.184.76.0/24      AS13071 
        213.184.77.0/24      AS13071 
        213.184.78.0/24      AS13071 
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.14.64.0/20       AS14728 
        216.146.0.0/19       AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.170.96.0/24      AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.101.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.104.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.105.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.234.128.0/22     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.139.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Nov 15 22:00:02 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 15 Nov 2013 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201311152200.rAFM02sS026867@wattle.apnic.net>

BGP Update Report
Interval: 07-Nov-13 -to- 14-Nov-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            47293  2.1%      38.9 -- BSNL-NIB National Internet Backbone
 2 - AS30693           42347  1.9%     411.1 -- SERVERHUB - Eonix Corporation
 3 - AS18809           41433  1.8%     812.4 -- Cable Onda
 4 - AS6407            40720  1.8%     768.3 -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
 5 - AS8402            33557  1.5%      40.4 -- CORBINA-AS OJSC "Vimpelcom"
 6 - AS38457           31250  1.4%     367.6 -- HNS-AS-AP Honesty Net Solution (I) Pvt Ltd
 7 - AS7545            28859  1.3%      29.6 -- TPG-INTERNET-AP TPG Telecom Limited
 8 - AS24863           24868  1.1%      45.9 -- LINKdotNET-AS
 9 - AS29990           21868  1.0%    3124.0 -- ASN-APPNEXUS - AppNexus, Inc
10 - AS13118           21208  0.9%     482.0 -- ASN-YARTELECOM OJSC Rostelecom
11 - AS35873           20413  0.9%    4082.6 -- MOVE-NETWORKS - Move Networks, inc.
12 - AS28573           20384  0.9%       8.3 -- NET Servi?os de Comunica??o S.A.
13 - AS13188           18726  0.8%      52.5 -- BANKINFORM-AS TOV "Bank-Inform"
14 - AS29049           18476  0.8%      54.2 -- DELTA-TELECOM-AS Delta Telecom LTD.
15 - AS7552            16766  0.7%      15.4 -- VIETEL-AS-AP Vietel Corporation
16 - AS4775            16486  0.7%    1099.1 -- GLOBE-TELECOM-AS Globe Telecoms
17 - AS4538            15993  0.7%      29.2 -- ERX-CERNET-BKB China Education and Research Network Center
18 - AS4847            13696  0.6%      28.9 -- CNIX-AP China Networks Inter-Exchange
19 - AS11976           13313  0.6%     242.1 -- FIDN - Fidelity Communication International Inc.
20 - AS7303            13247  0.6%       8.2 -- Telecom Argentina S.A.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS57130           12788  0.6%    6394.0 -- SECPRAL-AS Secpral COM SRL
 2 - AS35873           20413  0.9%    4082.6 -- MOVE-NETWORKS - Move Networks, inc.
 3 - AS6174             6595  0.3%    3297.5 -- SPRINTLINK8 - Sprint
 4 - AS29990           21868  1.0%    3124.0 -- ASN-APPNEXUS - AppNexus, Inc
 5 - AS57109            2732  0.1%    2732.0 -- ASPROREVIZOR Pro-Revizor LLC.
 6 - AS32244            6966  0.3%    2322.0 -- LIQUID-WEB-INC - Liquid Web, Inc.
 7 - AS62431            1887  0.1%    1887.0 -- NCSC-IE-AS National Cyber Security Centre
 8 - AS36753            3678  0.2%    1839.0 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc.
 9 - AS7202             8578  0.4%    1715.6 -- FAMU - Florida A & M University
10 - AS3                1569  0.1%    2513.0 -- RAFFEL-INTERNET Raffel Internet B.V.
11 - AS37367            1511  0.1%    1511.0 -- CALLKEY
12 - AS54465            6993  0.3%    1398.6 -- QPM-AS-1 - QuickPlay Media Inc.
13 - AS144              6415  0.3%    1283.0 -- ATT-INTERNET - Lucent Technologies/Bell Laboratories
14 - AS6421             1226  0.1%    1226.0 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
15 - AS4775            16486  0.7%    1099.1 -- GLOBE-TELECOM-AS Globe Telecoms
16 - AS6775             5598  0.2%     933.0 -- BACKBONE_EHF_EUROPE Backbone ehf
17 - AS22688             906  0.0%     906.0 -- DOLGENCORP - Dollar General Corporation
18 - AS45554             842  0.0%     842.0 -- VNNICANYCASTDNS-AS-VN Vietnam Internet network information center (VNNIC)
19 - AS18809           41433  1.8%     812.4 -- Cable Onda
20 - AS6407            40720  1.8%     768.3 -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc.


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 103.243.220.0/22  21848  0.9%   AS29990 -- ASN-APPNEXUS - AppNexus, Inc
 2 - 109.161.64.0/20   21038  0.9%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 3 - 8.20.2.0/24       20407  0.8%   AS35873 -- MOVE-NETWORKS - Move Networks, inc.
 4 - 194.9.23.0/24     12786  0.5%   AS57130 -- SECPRAL-AS Secpral COM SRL
 5 - 192.58.232.0/24    8629  0.4%   AS6629  -- NOAA-AS - NOAA
 6 - 222.127.0.0/24     8170  0.3%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
 7 - 120.28.62.0/24     8139  0.3%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
 8 - 115.170.128.0/17   7145  0.3%   AS4847  -- CNIX-AP China Networks Inter-Exchange
 9 - 206.152.15.0/24    6862  0.3%   AS54465 -- QPM-AS-1 - QuickPlay Media Inc.
10 - 67.210.190.0/23    6614  0.3%   AS11976 -- FIDN - Fidelity Communication International Inc.
11 - 67.210.188.0/23    6361  0.3%   AS11976 -- FIDN - Fidelity Communication International Inc.
12 - 79.134.225.0/24    5585  0.2%   AS6775  -- BACKBONE_EHF_EUROPE Backbone ehf
14 - 69.38.178.0/24     4339  0.2%   AS19406 -- TWRS-MA - Towerstream I, Inc.
15 - 168.223.206.0/23   4315  0.2%   AS7202  -- FAMU - Florida A & M University
16 - 168.223.200.0/22   4245  0.2%   AS7202  -- FAMU - Florida A & M University
17 - 220.244.84.0/22    4019  0.2%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited
18 - 121.52.144.0/24    3983  0.2%   AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
                                     AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan
19 - 2.93.235.0/24      3970  0.2%   AS8402  -- CORBINA-AS OJSC "Vimpelcom"
20 - 220.244.88.0/22    3949  0.2%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From michael at rancid.berkeley.edu  Fri Nov 15 22:15:12 2013
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Fri, 15 Nov 2013 14:15:12 -0800
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <9857094.1810.1384550742145.JavaMail.root@benjamin.baylink.com>
References: <9857094.1810.1384550742145.JavaMail.root@benjamin.baylink.com>
Message-ID: <52869CF0.4030807@rancid.berkeley.edu>

On 11/15/13 13:25, Jay Ashworth wrote:

> You seem to be taking this awfully personally, though, Mike; did you
> *set* the policies and procedures I'm scoffing at? 

I am NOT TAKING IT PERSONALLY DAMMIT!!!

Okay, now being serious (note clever way of avoiding using emoticons
while pointing out that I _wasn't_ being serious above), I wasn't
involved in the decision process and didn't have much say in why things
were done.  If it looked like I was taking it personally, that was only
because of the bald-faced, yet hidden accusation of my being wordy,
which I categorically resemble.

Okay, now I will really be serious.  For the stuff that they did, and
still do, the CEVs _did_ (and do) work.  The user interface is a bit
more challenging that a regular building.  My understanding is that this
got us out of a lot of political battles, but I was not privy to those
conversations.  I think, however, that it may have something to do with
what Roy is going through at UM, especially as he noted that the
decision appeared to have been made at higher levels.  In this case,
management did something that's not totally wrong, IMO.

michael



From jra at baylink.com  Fri Nov 15 22:26:04 2013
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 15 Nov 2013 17:26:04 -0500 (EST)
Subject: OT: Below grade fiber interconnect points
In-Reply-To: <52869CF0.4030807@rancid.berkeley.edu>
Message-ID: <19846363.1852.1384554364909.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Michael Sinatra" <michael at rancid.berkeley.edu>

> On 11/15/13 13:25, Jay Ashworth wrote:
> > You seem to be taking this awfully personally, though, Mike; did you
> > *set* the policies and procedures I'm scoffing at?
> 
> I am NOT TAKING IT PERSONALLY DAMMIT!!!


Well, jeez, Loueeze... :-)

> Okay, now being serious (note clever way of avoiding using emoticons
> while pointing out that I _wasn't_ being serious above), I wasn't
> involved in the decision process and didn't have much say in why things
> were done. If it looked like I was taking it personally, that was only
> because of the bald-faced, yet hidden accusation of my being wordy,
> which I categorically resemble.

Which category?

> Okay, now I will really be serious. For the stuff that they did, and
> still do, the CEVs _did_ (and do) work. The user interface is a bit
> more challenging that a regular building. My understanding is that this
> got us out of a lot of political battles, but I was not privy to those
> conversations. I think, however, that it may have something to do with
> what Roy is going through at UM, especially as he noted that the
> decision appeared to have been made at higher levels. In this case,
> management did something that's not totally wrong, IMO.

Yeah; I get what you're saying; layers 9 and 10 often overrule layer 8 
(that's money, lawyers, and people, respectively :-).  I just can't help
but think that the CBA is *really* lopsided against CEVs in nearly every
circumstance; the "wink wink nudge nudge" approach to keeping departments
out of your damn rack room seems the largest weighted item on the list.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From kemp at network-services.uoregon.edu  Fri Nov 15 22:41:29 2013
From: kemp at network-services.uoregon.edu (John Kemp)
Date: Fri, 15 Nov 2013 14:41:29 -0800
Subject: Network topology [Solved]
In-Reply-To: <B4BBC561-B7DA-4E67-9271-95BE3511B678@wisc.edu>
References: <48F61A6C.5050201@karnaugh.za.net>	<48F637F5.9020303@karnaugh.za.net>
 <B4BBC561-B7DA-4E67-9271-95BE3511B678@wisc.edu>
Message-ID: <5286A319.9030006@network-services.uoregon.edu>


I know Carlos did a bunch of work to build this
into Netdot, i.e. discover L2, draw usable graphs.

Here's a link to the last NANOG presentation:

http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Vicente-netdot-presentation-nanog49.pdf

John Kemp

On 10/15/08 7:18 PM, Dale W. Carder wrote:
> 
> On Oct 15, 2008, at 1:35 PM, Colin Alston wrote:
> 
>> On 2008/10/15 06:29 PM Colin Alston wrote:
>>> Is there any kind of cunning trick to detect standard layer2 switches
>>> along a path without stuff like STP?
>>
>> Apparently there isn't. Lots of people mentioned other tools, the
>> problem there is they have one thing in common which is polling SNMP.
>> I think it scales badly in general.
> 
> What is your reasoning behind this claim?  I would claim
> quite the opposite compared to CLI or TL1.
> 
>> Maybe there should be something (I mean like, someone should come up
>> with a standard :P) to trace switches in a path
> 
> I've written a cruddy script that given a seed bridge, scrapes
> L2 information obtained via CDP (I guess it could do LLDP, too)
> and does a breadth-first search through a network.  Then I just
> dump that into gnuplot format.  Getting the data is easy compared
> to visualization.
> 
> A coworker of mine has written script to ask Rapid-STP speaking
> switches about their current topology and builds a graph again
> in gnuplot format.
> 
> A more challenging approach would be to scrape the mac forwarding
> tables and stitch things together.  This would have to be done
> per-vlan.  I think this approach (or similar) might be done by
> Openview's L2 featureset.
> 
> Dale
> 
> -- 
> Dale W. Carder - Network Engineer
> University of Wisconsin / WiscNet
> http://net.doit.wisc.edu/~dwcarder
> 
> 


From kemp at network-services.uoregon.edu  Fri Nov 15 22:42:36 2013
From: kemp at network-services.uoregon.edu (John Kemp)
Date: Fri, 15 Nov 2013 14:42:36 -0800
Subject: Network topology [Solved]
In-Reply-To: <5286A319.9030006@network-services.uoregon.edu>
References: <48F61A6C.5050201@karnaugh.za.net>	<48F637F5.9020303@karnaugh.za.net>
 <B4BBC561-B7DA-4E67-9271-95BE3511B678@wisc.edu>
 <5286A319.9030006@network-services.uoregon.edu>
Message-ID: <5286A35C.7020509@network-services.uoregon.edu>


Ah, sorry.  Resurrected an old one there...
;-/

/jgk

On 11/15/13 2:41 PM, John Kemp wrote:
> 
> I know Carlos did a bunch of work to build this
> into Netdot, i.e. discover L2, draw usable graphs.
> 
> Here's a link to the last NANOG presentation:
> 
> http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Vicente-netdot-presentation-nanog49.pdf
> 
> John Kemp
> 
> On 10/15/08 7:18 PM, Dale W. Carder wrote:
>>
>> On Oct 15, 2008, at 1:35 PM, Colin Alston wrote:
>>
>>> On 2008/10/15 06:29 PM Colin Alston wrote:
>>>> Is there any kind of cunning trick to detect standard layer2 switches
>>>> along a path without stuff like STP?
>>>
>>> Apparently there isn't. Lots of people mentioned other tools, the
>>> problem there is they have one thing in common which is polling SNMP.
>>> I think it scales badly in general.
>>
>> What is your reasoning behind this claim?  I would claim
>> quite the opposite compared to CLI or TL1.
>>
>>> Maybe there should be something (I mean like, someone should come up
>>> with a standard :P) to trace switches in a path
>>
>> I've written a cruddy script that given a seed bridge, scrapes
>> L2 information obtained via CDP (I guess it could do LLDP, too)
>> and does a breadth-first search through a network.  Then I just
>> dump that into gnuplot format.  Getting the data is easy compared
>> to visualization.
>>
>> A coworker of mine has written script to ask Rapid-STP speaking
>> switches about their current topology and builds a graph again
>> in gnuplot format.
>>
>> A more challenging approach would be to scrape the mac forwarding
>> tables and stitch things together.  This would have to be done
>> per-vlan.  I think this approach (or similar) might be done by
>> Openview's L2 featureset.
>>
>> Dale
>>
>> -- 
>> Dale W. Carder - Network Engineer
>> University of Wisconsin / WiscNet
>> http://net.doit.wisc.edu/~dwcarder
>>
>>
> 


From pde at eff.org  Fri Nov 15 23:29:12 2013
From: pde at eff.org (Peter Eckersley)
Date: Fri, 15 Nov 2013 15:29:12 -0800
Subject: A new forum for discussing large scale TLS/SSL and other crypto
 deployment issues
Message-ID: <20131115232911.GA555@mail2.eff.org>

Dear network operators,

Some you may be interested in a project that EFF is launching at the
moment, which is intended to be a forum for knowledge sharing amongst
people trying to figure out how to deploy TLS and other forms of crypto
securely and at large scales.  ("What kind of load balancers will
terminate 100,000 TLS connections/sec?" "How do I audit our properties
for mixed content?" "What resources will it take to enable perfect
forward secrecy for a large userbase?" "What kind of certs should I
deploy for a large and complicated set of services?  Is there a way to
use SNI?" etc, etc).  The mailing list is intended primarily for people
who have complex scalability hurdles to overcome for deploying crypto.
It will operate under Chatham House rules.

https://lists.eff.org/mailman/admin/crypto-ops

Hopefully this will be followed shortly by a wiki to publicly document
knoweldge coming out of this conversation.

-- 
Peter Eckersley                            pde at eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993


From fergdawgster at mykolab.com  Fri Nov 15 23:36:06 2013
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Fri, 15 Nov 2013 15:36:06 -0800
Subject: A new forum for discussing large scale TLS/SSL and other crypto
 deployment issues
In-Reply-To: <20131115232911.GA555@mail2.eff.org>
References: <20131115232911.GA555@mail2.eff.org>
Message-ID: <5286AFE6.7040002@mykolab.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think the correct URL is:

https://lists.eff.org/mailman/listinfo/crypto-ops

- - ferg


On 11/15/2013 3:29 PM, Peter Eckersley wrote:

 > Dear network operators,
 >
 > Some you may be interested in a project that EFF is launching at the
 > moment, which is intended to be a forum for knowledge sharing amongst
 > people trying to figure out how to deploy TLS and other forms of crypto
 > securely and at large scales.  ("What kind of load balancers will
 > terminate 100,000 TLS connections/sec?" "How do I audit our properties
 > for mixed content?" "What resources will it take to enable perfect
 > forward secrecy for a large userbase?" "What kind of certs should I
 > deploy for a large and complicated set of services?  Is there a way to
 > use SNI?" etc, etc).  The mailing list is intended primarily for people
 > who have complex scalability hurdles to overcome for deploying crypto.
 > It will operate under Chatham House rules.
 >
 > https://lists.eff.org/mailman/admin/crypto-ops
 >
 > Hopefully this will be followed shortly by a wiki to publicly document
 > knoweldge coming out of this conversation.
 >


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 10.2.0 (Build 2317)
Charset: utf-8

wj8DBQFShq/fq1pz9mNUZTMRArY9AJ4xUozLVnzPsMUPTuYPpFpjm0mZswCfcT/r
H/jH8L1Hk1Ra4/CYkRF3KRc=
=kPz+
-----END PGP SIGNATURE-----

-- 
Paul Ferguson
Vice President, Threat Intelligence
IID, Tacoma, Washington  USA
PGP Public Key ID: 0x63546533
IID --> "Connect and Collaborate" --> www.internetidentity.com


From pde at eff.org  Fri Nov 15 23:36:29 2013
From: pde at eff.org (Peter Eckersley)
Date: Fri, 15 Nov 2013 15:36:29 -0800
Subject: A new forum for discussing large scale TLS/SSL and other crypto
 deployment issues
In-Reply-To: <20131115232911.GA555@mail2.eff.org>
References: <20131115232911.GA555@mail2.eff.org>
Message-ID: <20131115233629.GB555@mail2.eff.org>

On Fri, Nov 15, 2013 at 03:29:11PM -0800, Peter Eckersley wrote:
> Dear network operators,
> 
> Some you may be interested in a project that EFF is launching at the
> moment, which is intended to be a forum for knowledge sharing amongst
> people trying to figure out how to deploy TLS and other forms of crypto
> securely and at large scales.  ("What kind of load balancers will
> terminate 100,000 TLS connections/sec?" "How do I audit our properties
> for mixed content?" "What resources will it take to enable perfect
> forward secrecy for a large userbase?" "What kind of certs should I
> deploy for a large and complicated set of services?  Is there a way to
> use SNI?" etc, etc).  The mailing list is intended primarily for people
> who have complex scalability hurdles to overcome for deploying crypto.
> It will operate under Chatham House rules.
> 
> https://lists.eff.org/mailman/admin/crypto-ops

Sorry, the above URL is obviously not very useful to most of you :).  Try:

https://lists.eff.org/mailman/listinfo/crypto-ops

-- 
Peter Eckersley                            pde at eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993


From symack at gmail.com  Sat Nov 16 01:49:28 2013
From: symack at gmail.com (Nick Cameo)
Date: Fri, 15 Nov 2013 20:49:28 -0500
Subject: Best band for your buck router and switch (gigabit)
Message-ID: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>

Hello Everyone,

We are in the market for a used integrated service router and switch to manage
our network. A 24 port gigabit switch should suffice accompanied with
an industry
grade router. We like buying used (still under warranty) equipment as
long as there
is good feedback. Which make and models are you gents and ladies liking these
days?

Some Requirements for the router:

IPSEC and VPN Enabled
Transcoding capabilities using PVDM2 and NM-HDV2

We were considering:

Cisco 3845
Cisco WS-C2960G-24TC-L

But I thought I would get some insight on value, pricing, and
scalability before making
a recommendation.

Kind Regards,

Nick.


From symack at gmail.com  Sat Nov 16 02:51:00 2013
From: symack at gmail.com (Nick Cameo)
Date: Fri, 15 Nov 2013 21:51:00 -0500
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <20F6F033-3B1D-49EF-9A85-A62CA6AFB934@truenet.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <20F6F033-3B1D-49EF-9A85-A62CA6AFB934@truenet.com>
Message-ID: <CAGWRaZYUKVUt=Bhq5+SB9X=PyaAqFghEd9wjdvxP+U4889ypwQ@mail.gmail.com>

On 11/15/13, Eric Tykwinski <eric-list at truenet.com> wrote:
> Nick,
>
> It really depends on your deployment.  If you are looking at Cisco and doing
> BGP, I wouldn't go with a 3800 series.
> Memory constraints will kill you, especially in dual stack.
>
> If I was looking for an all in one on the cisco side of things, I'd look at
> a Catalyst 6500 series.  Battle tested with redundant power, supps, etc...
>
> If you are looking for cheap and don't mind learning a new OS.  MikroTik:
> http://www.mikrotik.com/
> Well used in SE Asia, and while I wouldn't use them for mission critical
> mainly due to lack of a good service contract, they do hold their own.
>
> Sincerely,
>
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
> F: 610-429-3222
>

Hello Eric,

Thank you so much for your response. The 6500 is what I was trained on
however, for this case we cannot afford the rackspace. We're building
highly efficient networks using mainly virtual machines and
fiberchannel backbone. I did however overlook the 1Gig limit of the
38/3900s....

So basically build our own linux router using a stripped down version of gentoo?

N.


From ops.lists at gmail.com  Sat Nov 16 02:57:34 2013
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Sat, 16 Nov 2013 08:27:34 +0530
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <CAGWRaZYUKVUt=Bhq5+SB9X=PyaAqFghEd9wjdvxP+U4889ypwQ@mail.gmail.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <20F6F033-3B1D-49EF-9A85-A62CA6AFB934@truenet.com>
 <CAGWRaZYUKVUt=Bhq5+SB9X=PyaAqFghEd9wjdvxP+U4889ypwQ@mail.gmail.com>
Message-ID: <CAArzuotYTMJ7j94cPbJtoL=qtHzP0MC-M_AsXQ9fP5uQntMQfA@mail.gmail.com>

For that sort of use case one of the new SDN offerings might work for you?

If not, mikrotik has any roll your own based on gentoo router beat

--srs

On Saturday, November 16, 2013, Nick Cameo wrote:

> Thank you so much for your response. The 6500 is what I was trained on
> however, for this case we cannot afford the rackspace. We're building
> highly efficient networks using mainly virtual machines and
> fiberchannel backbone. I did however overlook the 1Gig limit of the
> 38/3900s....
>
> So basically build our own linux router using a stripped down version of
> gentoo?
>
>

-- 
--srs (iPad)

From mksmith at mac.com  Sat Nov 16 03:14:55 2013
From: mksmith at mac.com (Michael Smith)
Date: Fri, 15 Nov 2013 19:14:55 -0800
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
Message-ID: <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>

Not sure what your budge is but you might consider the ASR1k.  Or the Juniper MX104. 

Mike

On Nov 15, 2013, at 5:49 PM, Nick Cameo <symack at gmail.com> wrote:

> Hello Everyone,
> 
> We are in the market for a used integrated service router and switch to manage
> our network. A 24 port gigabit switch should suffice accompanied with
> an industry
> grade router. We like buying used (still under warranty) equipment as
> long as there
> is good feedback. Which make and models are you gents and ladies liking these
> days?
> 
> Some Requirements for the router:
> 
> IPSEC and VPN Enabled
> Transcoding capabilities using PVDM2 and NM-HDV2
> 
> We were considering:
> 
> Cisco 3845
> Cisco WS-C2960G-24TC-L
> 
> But I thought I would get some insight on value, pricing, and
> scalability before making
> a recommendation.
> 
> Kind Regards,
> 
> Nick.
> 



From raaki.88 at gmail.com  Sat Nov 16 09:45:50 2013
From: raaki.88 at gmail.com (Rakesh M)
Date: Sat, 16 Nov 2013 15:15:50 +0530
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>
Message-ID: <CAC2aK2pjV8hFBFnFMWhrdac83qyYgygJ9+vzZu_7QHeYF5dddQ@mail.gmail.com>

Mx80 Might work if you are looking at Expansion options for future it comes
with Modular Cards or Tested Cisco 760x series might suffice as well. Other
Options like Mikrotik as above stated  might work but i myself never tested
that brand though



Rakesh


On Sat, Nov 16, 2013 at 8:44 AM, Michael Smith <mksmith at mac.com> wrote:

> Not sure what your budge is but you might consider the ASR1k.  Or the
> Juniper MX104.
>
> Mike
>
> On Nov 15, 2013, at 5:49 PM, Nick Cameo <symack at gmail.com> wrote:
>
> > Hello Everyone,
> >
> > We are in the market for a used integrated service router and switch to
> manage
> > our network. A 24 port gigabit switch should suffice accompanied with
> > an industry
> > grade router. We like buying used (still under warranty) equipment as
> > long as there
> > is good feedback. Which make and models are you gents and ladies liking
> these
> > days?
> >
> > Some Requirements for the router:
> >
> > IPSEC and VPN Enabled
> > Transcoding capabilities using PVDM2 and NM-HDV2
> >
> > We were considering:
> >
> > Cisco 3845
> > Cisco WS-C2960G-24TC-L
> >
> > But I thought I would get some insight on value, pricing, and
> > scalability before making
> > a recommendation.
> >
> > Kind Regards,
> >
> > Nick.
> >
>
>
>

From jason at jasonantman.com  Sat Nov 16 17:15:20 2013
From: jason at jasonantman.com (Jason Antman)
Date: Sat, 16 Nov 2013 12:15:20 -0500
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <CAC2aK2pjV8hFBFnFMWhrdac83qyYgygJ9+vzZu_7QHeYF5dddQ@mail.gmail.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>
 <CAC2aK2pjV8hFBFnFMWhrdac83qyYgygJ9+vzZu_7QHeYF5dddQ@mail.gmail.com>
Message-ID: <5287A828.1090707@jasonantman.com>

If you're going to consider Mikrotik, I'd also highly recommend that you
look into Vyatta (www.vyatta.com). They offer (well, or did last time I
looked, they seem to be increasingly commercial every time I visit their
site) fully supported software as well as software-on-vendor-hardware
solutions, plus an open source "core" offering. I've never done BGP on
them, but I've used them as edge routers/firewalls for smallish internal
networks as well as IPSEC endpoints, and their performance on modern
server-grade hardware (i.e. the type of stuff lying around in many
shops) is mind-boggling.

Post Script: I just went to vyatta.com, and apparently they've been
acquired by Brocade. The former content of their web site is gone, and
as far as I can tell from the Brocade site
(http://www.brocade.com/products/all/network-functions-virtualization/index.page)
they *seem* to be calling the software solution the "Brocade Vyatta 5400
vRouter". I assume this means their range of supported hardware devices
may be done for. Luckily I kept an archive of all of their wonderful
anti-cisco ads...


-Jason

On 11/16/2013 04:45 AM, Rakesh M wrote:
> Mx80 Might work if you are looking at Expansion options for future it comes
> with Modular Cards or Tested Cisco 760x series might suffice as well. Other
> Options like Mikrotik as above stated  might work but i myself never tested
> that brand though
>
>
>
> Rakesh
>
>
> On Sat, Nov 16, 2013 at 8:44 AM, Michael Smith <mksmith at mac.com> wrote:
>
>> Not sure what your budge is but you might consider the ASR1k.  Or the
>> Juniper MX104.
>>
>> Mike
>>
>> On Nov 15, 2013, at 5:49 PM, Nick Cameo <symack at gmail.com> wrote:
>>
>>> Hello Everyone,
>>>
>>> We are in the market for a used integrated service router and switch to
>> manage
>>> our network. A 24 port gigabit switch should suffice accompanied with
>>> an industry
>>> grade router. We like buying used (still under warranty) equipment as
>>> long as there
>>> is good feedback. Which make and models are you gents and ladies liking
>> these
>>> days?
>>>
>>> Some Requirements for the router:
>>>
>>> IPSEC and VPN Enabled
>>> Transcoding capabilities using PVDM2 and NM-HDV2
>>>
>>> We were considering:
>>>
>>> Cisco 3845
>>> Cisco WS-C2960G-24TC-L
>>>
>>> But I thought I would get some insight on value, pricing, and
>>> scalability before making
>>> a recommendation.
>>>
>>> Kind Regards,
>>>
>>> Nick.
>>>
>>
>>



From sethm at rollernet.us  Sat Nov 16 19:46:47 2013
From: sethm at rollernet.us (Seth Mattinen)
Date: Sat, 16 Nov 2013 11:46:47 -0800
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <5287A828.1090707@jasonantman.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>
 <CAC2aK2pjV8hFBFnFMWhrdac83qyYgygJ9+vzZu_7QHeYF5dddQ@mail.gmail.com>
 <5287A828.1090707@jasonantman.com>
Message-ID: <5287CBA7.5050805@rollernet.us>

On 11/16/13, 9:15, Jason Antman wrote:

> Post Script: I just went to vyatta.com, and apparently they've been
> acquired by Brocade. The former content of their web site is gone, and
> as far as I can tell from the Brocade site
> (http://www.brocade.com/products/all/network-functions-virtualization/index.page)
> they *seem* to be calling the software solution the "Brocade Vyatta 5400
> vRouter". I assume this means their range of supported hardware devices
> may be done for. Luckily I kept an archive of all of their wonderful
> anti-cisco ads...
>


vyatta.org is still around.

~Seth


From me at anuragbhatia.com  Sat Nov 16 19:49:09 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Sun, 17 Nov 2013 01:19:09 +0530
Subject: Question on routing of Tata AS6453 with their other network AS4755
Message-ID: <CAJ0+aXZ1E9zvVP7PgLrMOELdRa3fYcPM7pbgZtJNofcEZMP3wA@mail.gmail.com>

Hello everyone


I was looking around and noticed a pretty bad route from DTAG to Tata
AS6453 (basically destination was Tata Comm's Indian network on AS4755). I
am not able to understand cause for inefficient routing but I am sure I am
failing to understand something which is crazy in their IGP. The result is
that route from Europe to India is via Europe > US > Singapore > India
rather then direct India.

There seem to be quite a few prefixes with these problem, but for this mail
question, I am picking two prefixes - one which seems to be having good
routing.

202.54.82.0/24 has pretty bad routing while 93.183.28.0/24. I see both
prefixes have valid route objects and are originated by VSNL AS4755 to Tata
AS6453 in India. Now if we compare trace from Tata's own core router say in
Paris from their looking glass, I get:


Router: gin-pye-core1
Site: FR, Paris, PYE
Command: traceroute ip 202.54.82.1

Tracing the route to RAS55.1.ppppun.vsnl.net.in (202.54.82.1)

  1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label
525297 Exp 0] 300 msec
    if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label
525297 Exp 0] 260 msec
    if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label
525297 Exp 0] 260 msec
  2 if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604
Exp 0] 264 msec
    if-3-6.tcore1.L78-London.as6453.net (80.231.130.85) [MPLS: Label 523604
Exp 0] 256 msec
    if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604
Exp 0] 264 msec
  3 if-2-2.tcore2.L78-London.as6453.net (80.231.131.1) [MPLS: Label 728466
Exp 0] 264 msec
  *  if-1-2.tcore2.L78-London.as6453.net
<http://if-1-2.tcore2.L78-London.as6453.net> (80.231.130.122) [MPLS: Label
728466 Exp 0] 264 msec 268 msec*
*  4 if-20-2.tcore2.NYY-NewYork.as6453.net
<http://if-20-2.tcore2.NYY-NewYork.as6453.net> (216.6.99.13) [MPLS: Label
354225 Exp 0] 276 msec 260 msec 260 msec*
  5  *
    if-12-6.tcore1.CT8-Chicago.as6453.net (216.6.99.46) [MPLS: Label 365409
Exp 0] 304 msec
    if-11-2.tcore1.NYY-NewYork.as6453.net (216.6.99.2) [MPLS: Label 782881
Exp 0] 256 msec
  6 if-22-2.tcore2.CT8-Chicago.as6453.net (64.86.79.1) [MPLS: Label 361921
Exp 0] 264 msec 264 msec
    if-1-2.tcore1.PDI-PaloAlto.as6453.net (66.198.127.5) [MPLS: Label
670352 Exp 0] 256 msec
  7 if-11-3.tcore2.PDI-PaloAlto.as6453.net (66.198.144.57) [MPLS: Label
321233 Exp 0] 256 msec
    if-2-2.tcore2.PDI-PaloAlto.as6453.net (66.198.127.2) [MPLS: Label
321233 Exp 0] 260 msec *
  8 if-9-2.tcore1.TV2-Tokyo.as6453.net (180.87.180.18) 280 msec 260 msec
260 msec
  9 if-2-2.tcore2.TV2-Tokyo.as6453.net (180.87.180.2) [MPLS: Label 581761
Exp 0] 252 msec 252 msec 252 msec
 10 if-6-2.tcore1.SVW-Singapore.as6453.net (180.87.12.109) [MPLS: Label
710034 Exp 0] 248 msec 244 msec 248 msec
 11 if-5-2.tcore1.CXR-Chennai.as6453.net (180.87.12.54) 244 msec 272 msec
252 msec
 12 180.87.36.10 272 msec 256 msec 272 msec
 13 172.31.19.94 272 msec 252 msec 256 msec
 14  *  *
    172.25.83.142 288 msec
 15 172.25.83.134 !H  *  *


while for other prefix, route is:

Router: gin-pye-core1
Site: FR, Paris, PYE
Command: traceroute ip 93.183.28.1

Tracing the route to 93.183.28.1

  1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label
519713 Exp 0] 12 msec
    if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label
519713 Exp 0] 12 msec
    if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label
519713 Exp 0] 12 msec
  2 if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label
302880 Exp 0] 12 msec
    if-14-2.tcore1.WYN-Marseille.as6453.net (80.231.154.170) [MPLS: Label
302880 Exp 0] 36 msec
    if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label
302880 Exp 0] 12 msec
  *3 if-2-2.tcore2.WYN-Marseille.as6453.net
<http://if-2-2.tcore2.WYN-Marseille.as6453.net> (80.231.217.2) 12 msec 12
msec 12 msec*
  4 80.231.200.26 140 msec 116 msec 116 msec
  5 172.31.16.193 148 msec 140 msec 144 msec
 * 6 115.114.71.133.static-chennai.vsnl.net.in
<http://115.114.71.133.static-chennai.vsnl.net.in> (115.114.71.133) [AS
4755] 140 msec 148 msec 140 msec*
  7 172.29.209.82 [MPLS: Labels 301664/7167 Exp 1] 148 msec 144 msec 148
msec
  8 172.31.35.138 [MPLS: Labels 4831/7167 Exp 1] 152 msec 152 msec 148 msec
  9 121.242.126.205.static-chennai.vsnl.net.in (121.242.126.205) [AS 4755]
[MPLS: Label 7167 Exp 1] 148 msec *  140 msec
 10 121.242.126.206.static-chennai.vsnl.net.in (121.242.126.206) [AS 4755]
140 msec 148 msec 140 msec
 11  *  *  *
 12  *  *  *



Now if I focus on best route entry in router for both prefixes, I see
following:

Bad Prefix:
4755
    tv2-tcore1. (metric 16148) from *hk2-core3.* (hk2-core3.)
      Origin IGP, valid, internal, best
      Community:
      Originator: 66.110.10.113


Good Prefix:
4755
    wyn-tcore2. (metric 10050) *from wyn-tcore2.* (66.110.10.109)
      Origin IGP, valid, internal, best
      Community:




Now as I understand Paris router is getting bad prefix from TV2 which is
their Tokyo router while for other prefix with good routing, route is via
their other router on cable landing station in France.

Can someone explain me what exactly is happening here? Are they missing
some iBGP sessions?  It's not perfect mesh & missing route reflectors?

Probably both prefixes are originated inside India by different routers but
as I understand all prefixes get transit from AS6453 and so is it like
AS6453 missing some routes (which seem to be direct) to technically
downstream AS4755?


Curious to hear your thoughts.


Note: I am not worried about issue - it's not really impacting me. Just
trying to learn what is wrong in the backbone design here.




Thanks.
-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From ebais at a2b-internet.com  Sat Nov 16 20:24:55 2013
From: ebais at a2b-internet.com (Erik Bais)
Date: Sat, 16 Nov 2013 21:24:55 +0100
Subject: Question on routing of Tata AS6453 with their other network AS4755
In-Reply-To: <CAJ0+aXZ1E9zvVP7PgLrMOELdRa3fYcPM7pbgZtJNofcEZMP3wA@mail.gmail.com>
References: <CAJ0+aXZ1E9zvVP7PgLrMOELdRa3fYcPM7pbgZtJNofcEZMP3wA@mail.gmail.com>
Message-ID: <04CCB153-7E4F-4DDD-8422-773F940A7454@a2b-internet.com>

We have a ticket open with Tata currently on a similar issue. 

Traffic from our AS (51088) via Tata to DTAG goes from Amsterdam, NL, to Tata Frankfurth, Germany, to Tata Paris, France, to DTAG In Paris, back to Germany ?? With packetloss... 

Our Tinet (GT-T) routes go from Amsterdam to DTAG ( Amsterdam) to Germany .. 

No reply on the ticket yet where the packetloss comes from or why they are routing via Paris which adds about 30 ms ...

Check out our Smokeping page for it .. 

http://smokeping.a2b-internet.com/smokeping/smokeping.cgi?target=LatencyCheckList.Tata_Paris

We are currently pref'ing the traffic to DTAG via Tinet/ GT-T. 

Erik Bais
A2B Internet 

Verstuurd vanaf mijn iPad

Op 16 nov. 2013 om 20:49 heeft Anurag Bhatia <me at anuragbhatia.com> het volgende geschreven:

> Hello everyone
> 
> 
> I was looking around and noticed a pretty bad route from DTAG to Tata
> AS6453 (basically destination was Tata Comm's Indian network on AS4755). I
> am not able to understand cause for inefficient routing but I am sure I am
> failing to understand something which is crazy in their IGP. The result is
> that route from Europe to India is via Europe > US > Singapore > India
> rather then direct India.
> 
> There seem to be quite a few prefixes with these problem, but for this mail
> question, I am picking two prefixes - one which seems to be having good
> routing.
> 
> 202.54.82.0/24 has pretty bad routing while 93.183.28.0/24. I see both
> prefixes have valid route objects and are originated by VSNL AS4755 to Tata
> AS6453 in India. Now if we compare trace from Tata's own core router say in
> Paris from their looking glass, I get:
> 
> 
> Router: gin-pye-core1
> Site: FR, Paris, PYE
> Command: traceroute ip 202.54.82.1
> 
> Tracing the route to RAS55.1.ppppun.vsnl.net.in (202.54.82.1)
> 
>  1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label
> 525297 Exp 0] 300 msec
>    if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label
> 525297 Exp 0] 260 msec
>    if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label
> 525297 Exp 0] 260 msec
>  2 if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604
> Exp 0] 264 msec
>    if-3-6.tcore1.L78-London.as6453.net (80.231.130.85) [MPLS: Label 523604
> Exp 0] 256 msec
>    if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604
> Exp 0] 264 msec
>  3 if-2-2.tcore2.L78-London.as6453.net (80.231.131.1) [MPLS: Label 728466
> Exp 0] 264 msec
>  *  if-1-2.tcore2.L78-London.as6453.net
> <http://if-1-2.tcore2.L78-London.as6453.net> (80.231.130.122) [MPLS: Label
> 728466 Exp 0] 264 msec 268 msec*
> *  4 if-20-2.tcore2.NYY-NewYork.as6453.net
> <http://if-20-2.tcore2.NYY-NewYork.as6453.net> (216.6.99.13) [MPLS: Label
> 354225 Exp 0] 276 msec 260 msec 260 msec*
>  5  *
>    if-12-6.tcore1.CT8-Chicago.as6453.net (216.6.99.46) [MPLS: Label 365409
> Exp 0] 304 msec
>    if-11-2.tcore1.NYY-NewYork.as6453.net (216.6.99.2) [MPLS: Label 782881
> Exp 0] 256 msec
>  6 if-22-2.tcore2.CT8-Chicago.as6453.net (64.86.79.1) [MPLS: Label 361921
> Exp 0] 264 msec 264 msec
>    if-1-2.tcore1.PDI-PaloAlto.as6453.net (66.198.127.5) [MPLS: Label
> 670352 Exp 0] 256 msec
>  7 if-11-3.tcore2.PDI-PaloAlto.as6453.net (66.198.144.57) [MPLS: Label
> 321233 Exp 0] 256 msec
>    if-2-2.tcore2.PDI-PaloAlto.as6453.net (66.198.127.2) [MPLS: Label
> 321233 Exp 0] 260 msec *
>  8 if-9-2.tcore1.TV2-Tokyo.as6453.net (180.87.180.18) 280 msec 260 msec
> 260 msec
>  9 if-2-2.tcore2.TV2-Tokyo.as6453.net (180.87.180.2) [MPLS: Label 581761
> Exp 0] 252 msec 252 msec 252 msec
> 10 if-6-2.tcore1.SVW-Singapore.as6453.net (180.87.12.109) [MPLS: Label
> 710034 Exp 0] 248 msec 244 msec 248 msec
> 11 if-5-2.tcore1.CXR-Chennai.as6453.net (180.87.12.54) 244 msec 272 msec
> 252 msec
> 12 180.87.36.10 272 msec 256 msec 272 msec
> 13 172.31.19.94 272 msec 252 msec 256 msec
> 14  *  *
>    172.25.83.142 288 msec
> 15 172.25.83.134 !H  *  *
> 
> 
> while for other prefix, route is:
> 
> Router: gin-pye-core1
> Site: FR, Paris, PYE
> Command: traceroute ip 93.183.28.1
> 
> Tracing the route to 93.183.28.1
> 
>  1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label
> 519713 Exp 0] 12 msec
>    if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label
> 519713 Exp 0] 12 msec
>    if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label
> 519713 Exp 0] 12 msec
>  2 if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label
> 302880 Exp 0] 12 msec
>    if-14-2.tcore1.WYN-Marseille.as6453.net (80.231.154.170) [MPLS: Label
> 302880 Exp 0] 36 msec
>    if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label
> 302880 Exp 0] 12 msec
>  *3 if-2-2.tcore2.WYN-Marseille.as6453.net
> <http://if-2-2.tcore2.WYN-Marseille.as6453.net> (80.231.217.2) 12 msec 12
> msec 12 msec*
>  4 80.231.200.26 140 msec 116 msec 116 msec
>  5 172.31.16.193 148 msec 140 msec 144 msec
> * 6 115.114.71.133.static-chennai.vsnl.net.in
> <http://115.114.71.133.static-chennai.vsnl.net.in> (115.114.71.133) [AS
> 4755] 140 msec 148 msec 140 msec*
>  7 172.29.209.82 [MPLS: Labels 301664/7167 Exp 1] 148 msec 144 msec 148
> msec
>  8 172.31.35.138 [MPLS: Labels 4831/7167 Exp 1] 152 msec 152 msec 148 msec
>  9 121.242.126.205.static-chennai.vsnl.net.in (121.242.126.205) [AS 4755]
> [MPLS: Label 7167 Exp 1] 148 msec *  140 msec
> 10 121.242.126.206.static-chennai.vsnl.net.in (121.242.126.206) [AS 4755]
> 140 msec 148 msec 140 msec
> 11  *  *  *
> 12  *  *  *
> 
> 
> 
> Now if I focus on best route entry in router for both prefixes, I see
> following:
> 
> Bad Prefix:
> 4755
>    tv2-tcore1. (metric 16148) from *hk2-core3.* (hk2-core3.)
>      Origin IGP, valid, internal, best
>      Community:
>      Originator: 66.110.10.113
> 
> 
> Good Prefix:
> 4755
>    wyn-tcore2. (metric 10050) *from wyn-tcore2.* (66.110.10.109)
>      Origin IGP, valid, internal, best
>      Community:
> 
> 
> 
> 
> Now as I understand Paris router is getting bad prefix from TV2 which is
> their Tokyo router while for other prefix with good routing, route is via
> their other router on cable landing station in France.
> 
> Can someone explain me what exactly is happening here? Are they missing
> some iBGP sessions?  It's not perfect mesh & missing route reflectors?
> 
> Probably both prefixes are originated inside India by different routers but
> as I understand all prefixes get transit from AS6453 and so is it like
> AS6453 missing some routes (which seem to be direct) to technically
> downstream AS4755?
> 
> 
> Curious to hear your thoughts.
> 
> 
> Note: I am not worried about issue - it's not really impacting me. Just
> trying to learn what is wrong in the backbone design here.
> 
> 
> 
> 
> Thanks.
> -- 
> 
> 
> Anurag Bhatia
> anuragbhatia.com
> 
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
> Twitter<https://twitter.com/anurag_bhatia>
> Skype: anuragbhatia.com


From patrick at ianai.net  Sat Nov 16 22:25:18 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sat, 16 Nov 2013 17:25:18 -0500
Subject: List of CDNs?
In-Reply-To: <20131114222549.GB67966@ak-labs.net>
References: <20131114220200.GA67966@ak-labs.net>
 <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net>
 <20131114222549.GB67966@ak-labs.net>
Message-ID: <836632B8-6206-4BBE-8632-27D1FF10275D@ianai.net>

On Nov 14, 2013, at 17:25 , Carlos Kamtha <kamtha at ak-labs.net> wrote:

> The goal is to find a solution to optimize the path for DNS queries that traverse via CDNs within certain regions 
> without the luxury of a network layer. 
> 
> For instance, some clients in singapore are getting answers from the UK instead of something more local. 
> 
> Knowing where the CDNs are may allow us to direct them to a more optimal path. 

Depends on the CDN. Using Akamai as an example (since they are essentially as big as all other CDNs combined, and 'cause I know them best), the location of an Akamai web server is not useful since everything is based on name servers. Also, the location of Akamai's name server and the topological path used to reach it is irrelevant to the web server returned. So getting a list of nodes and somehow modifying your network based on that will likely have minimal to zero impact.

Other CDNs use different methods of mapping end users to web servers. Some use anycast, either at the DNS level or even at the HTTP level. In those cases, this information may be of use.

If you have a problem with Akamai mapping, you can always email NetSupport-tix at akamai.com and ask them for help. My guess is other CDNs have something similar. Probably much more useful to go directly to the CDN with the problem than look at a 3rd party list of nodes and try to fix issues yourself with methods that may have no effect.

Or not. :) Your network, your decision, I'm just making suggestions.

-- 
TTFN,
patrick


> On Thu, Nov 14, 2013 at 10:11:59PM +0000, Patrick W. Gilmore wrote:
>> List of CDNs would be difficult, but not impossible. Although they do different things, so a simple list is unlikely to be as useful as it looks. 
>> 
>> A lost of CDN "DC nodes" is not possible. Why do you care about such a thing anyway?
>> 
>> -- 
>> TTFN,
>> patrick
>> 
>> Composed on a virtual keyboard, please forgive typos. 
>> 
>> 
>>> On Nov 14, 2013, at 22:02, Carlos Kamtha <kamtha at ak-labs.net> wrote:
>>> 
>>> Hi,
>>> 
>>> I was wondering if anyone knows where I could find a compiled list of Content Delivery Networks as well
>>> as thier DC nodes? if any..
>>> 
>>> Please respond offlist.
>>> 
>>> Cheers,
>>> Carlos
>>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131116/7ec895bd/attachment.bin>

From patrick at ianai.net  Sat Nov 16 22:28:39 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sat, 16 Nov 2013 17:28:39 -0500
Subject: List of CDNs?
In-Reply-To: <52863870.5020607@aleae.com>
References: <20131114220200.GA67966@ak-labs.net>
 <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net> <52854C84.6000204@gmail.com>
 <52863870.5020607@aleae.com>
Message-ID: <1E8DDE94-8595-4C50-B3F2-AF78E0E627F6@ianai.net>

First, the location of CDN nodes is not relevant to passive DNS monitoring. If Andrew would like a list of domains with CDN hostnames in them, that might be findable.

Second, a list of CDN nodes is likely impossible to gather & maintain without the help of the CDNs themselves. There are literally thousands of them, most do not serve the entire Internet, and they change frequently. And before you ask, I know at least Akamai will _not_ give you their list, so don't even try to ask them.

Sorry this makes your life more difficult. Perhaps if you explained why you were doing address lookups, the collective body could help you come up with a better solution?

-- 
TTFN,
patrick


On Nov 15, 2013, at 10:06 , Michael Collins, Aleae <mcollins at aleae.com> wrote:

> I'll second that; CDNs are a constant pain for me when I'm doing address
> lookups.  A list of them would make life a lot easier for a bunch of
> different investigative processes. 
> 
> If there isn't one right now, I think I could get off my tuchas and
> start maintaining one if anyone's interested in pitching in.
> 
> 
> On 11/14/13 5:19 PM, Andrew Fried wrote:
>> Actually, a list of CDNs would be very handy.  I harvest botnets and
>> fast flux hosts out of passive dns, and some of the heuristics used to
>> identify them are similar to what CDNs look like.
>> 
>> Having a decent list of CDN effective top level domains alone would be
>> useful for redacting those hosts.
>> 
>> Andy
>> 
>> 
>> Andrew Fried
>> andrew.fried at gmail.com
>> 
>> On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote:
>>> List of CDNs would be difficult, but not impossible. Although they do different things, so a simple list is unlikely to be as useful as it looks. 
>>> 
>>> A lost of CDN "DC nodes" is not possible. Why do you care about such a thing anyway?
>>> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131116/3ae640f2/attachment-0001.bin>

From symack at gmail.com  Sat Nov 16 23:17:47 2013
From: symack at gmail.com (Nick Cameo)
Date: Sat, 16 Nov 2013 18:17:47 -0500
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <5287A828.1090707@jasonantman.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>
 <CAC2aK2pjV8hFBFnFMWhrdac83qyYgygJ9+vzZu_7QHeYF5dddQ@mail.gmail.com>
 <5287A828.1090707@jasonantman.com>
Message-ID: <CAGWRaZaJLVaA=G_xoY1yFtVzqR3_DS-xO7QSeAC8Ofs-=zKRsw@mail.gmail.com>

> Post Script: I just went to vyatta.com, and apparently they've been
> acquired by Brocade. The former content of their web site is gone, and
> as far as I can tell from the Brocade site
> (http://www.brocade.com/products/all/network-functions-virtualization/index.page)
> they *seem* to be calling the software solution the "Brocade Vyatta 5400
> vRouter". I assume this means their range of supported hardware devices
> may be done for. Luckily I kept an archive of all of their wonderful
> anti-cisco ads...
>

Too funny. This reminds me of an old experience I had when companies
where acquired and we were left out in the cold..... I think on
Monday, I will make the recommendation to purchase an IBM xServer 3250
M5 (comes 1 PCIe V3 x4 and x8), throw Quagga on there and call it a
day. It will have everything we need except for transcoding? Oh wait!
We can buy hardware transcoder line cards as well. The problem is
there are only two slots, and one I bet is reserved for some raid
controller or something like that...

As for the switch, is the 2960G have a proven track record?

Thanks for everyone's help :)

Nick from Toronto.


From symack at gmail.com  Sat Nov 16 23:18:36 2013
From: symack at gmail.com (Nick Cameo)
Date: Sat, 16 Nov 2013 18:18:36 -0500
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <CAGWRaZaJLVaA=G_xoY1yFtVzqR3_DS-xO7QSeAC8Ofs-=zKRsw@mail.gmail.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>
 <CAC2aK2pjV8hFBFnFMWhrdac83qyYgygJ9+vzZu_7QHeYF5dddQ@mail.gmail.com>
 <5287A828.1090707@jasonantman.com>
 <CAGWRaZaJLVaA=G_xoY1yFtVzqR3_DS-xO7QSeAC8Ofs-=zKRsw@mail.gmail.com>
Message-ID: <CAGWRaZYZ25mHxr2p6qPpgvbMUBfWJmqQHZTLJ0+3Ly7nxrxUzQ@mail.gmail.com>

Your feedback is greatly appreciated.

N.


From eyeronic.design at gmail.com  Sat Nov 16 23:27:20 2013
From: eyeronic.design at gmail.com (Mike Hale)
Date: Sat, 16 Nov 2013 15:27:20 -0800
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <CAGWRaZYZ25mHxr2p6qPpgvbMUBfWJmqQHZTLJ0+3Ly7nxrxUzQ@mail.gmail.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>
 <CAC2aK2pjV8hFBFnFMWhrdac83qyYgygJ9+vzZu_7QHeYF5dddQ@mail.gmail.com>
 <5287A828.1090707@jasonantman.com>
 <CAGWRaZaJLVaA=G_xoY1yFtVzqR3_DS-xO7QSeAC8Ofs-=zKRsw@mail.gmail.com>
 <CAGWRaZYZ25mHxr2p6qPpgvbMUBfWJmqQHZTLJ0+3Ly7nxrxUzQ@mail.gmail.com>
Message-ID: <CAN3um4wj_Nxu7LmVcPZRJtq-LOKFJf-h56uHY-sELaUGLNg4Aw@mail.gmail.com>

"As for the switch, is the 2960G have a proven track record?"

We've deployed a lot of these in normal access-switch roles and
they've worked flawlessly.  You should be able to pick some up for
relatively cheap from resellers.  They'd be even cheaper if you get
them from ebay.

On Sat, Nov 16, 2013 at 3:18 PM, Nick Cameo <symack at gmail.com> wrote:
> Your feedback is greatly appreciated.
>
> N.
>



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


From symack at gmail.com  Sat Nov 16 23:35:03 2013
From: symack at gmail.com (Nick Cameo)
Date: Sat, 16 Nov 2013 18:35:03 -0500
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <CAN3um4wj_Nxu7LmVcPZRJtq-LOKFJf-h56uHY-sELaUGLNg4Aw@mail.gmail.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>
 <CAC2aK2pjV8hFBFnFMWhrdac83qyYgygJ9+vzZu_7QHeYF5dddQ@mail.gmail.com>
 <5287A828.1090707@jasonantman.com>
 <CAGWRaZaJLVaA=G_xoY1yFtVzqR3_DS-xO7QSeAC8Ofs-=zKRsw@mail.gmail.com>
 <CAGWRaZYZ25mHxr2p6qPpgvbMUBfWJmqQHZTLJ0+3Ly7nxrxUzQ@mail.gmail.com>
 <CAN3um4wj_Nxu7LmVcPZRJtq-LOKFJf-h56uHY-sELaUGLNg4Aw@mail.gmail.com>
Message-ID: <CAGWRaZYOHr_x+F0aQk6zNw32N9p=9bJiMEiDgS-n0e6KjWAdrg@mail.gmail.com>

If anyone has one for sale that has not had it's ports beat to hell
please let us know.
We would be interested.


From eyeronic.design at gmail.com  Sat Nov 16 23:50:48 2013
From: eyeronic.design at gmail.com (Mike Hale)
Date: Sat, 16 Nov 2013 15:50:48 -0800
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <CAGWRaZYOHr_x+F0aQk6zNw32N9p=9bJiMEiDgS-n0e6KjWAdrg@mail.gmail.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>
 <CAC2aK2pjV8hFBFnFMWhrdac83qyYgygJ9+vzZu_7QHeYF5dddQ@mail.gmail.com>
 <5287A828.1090707@jasonantman.com>
 <CAGWRaZaJLVaA=G_xoY1yFtVzqR3_DS-xO7QSeAC8Ofs-=zKRsw@mail.gmail.com>
 <CAGWRaZYZ25mHxr2p6qPpgvbMUBfWJmqQHZTLJ0+3Ly7nxrxUzQ@mail.gmail.com>
 <CAN3um4wj_Nxu7LmVcPZRJtq-LOKFJf-h56uHY-sELaUGLNg4Aw@mail.gmail.com>
 <CAGWRaZYOHr_x+F0aQk6zNw32N9p=9bJiMEiDgS-n0e6KjWAdrg@mail.gmail.com>
Message-ID: <CAN3um4x3haNHj7pvE1dAJexn3U7zW_md2piuNBarxm0pbziqjA@mail.gmail.com>

We get ours from Network Hardware Resellers.  It's
Smartnet-contractable, which is important for us, and was pretty
cheap.

Shoot me a message offlist if you want our sales rep's info.  He might
be able to help you out.

On Sat, Nov 16, 2013 at 3:35 PM, Nick Cameo <symack at gmail.com> wrote:
> If anyone has one for sale that has not had it's ports beat to hell
> please let us know.
> We would be interested.



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


From mcollins at aleae.com  Sun Nov 17 00:30:48 2013
From: mcollins at aleae.com (Michael Collins)
Date: Sat, 16 Nov 2013 19:30:48 -0500
Subject: List of CDNs?
In-Reply-To: <1E8DDE94-8595-4C50-B3F2-AF78E0E627F6@ianai.net>
References: <20131114220200.GA67966@ak-labs.net>
 <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net> <52854C84.6000204@gmail.com>
 <52863870.5020607@aleae.com> <1E8DDE94-8595-4C50-B3F2-AF78E0E627F6@ianai.net>
Message-ID: <FBBB76C4-1347-4CFF-8811-D4789C4BC49D@aleae.com>

Patrick,

It's Yet Another False Positive in anomaly detection and traffic analysis software that I fiddle with.  In the case of CDNs, I mostly want to throw them out the window -- whenever I see one, I know that the reverse lookup information is going to be useless and it's time to toss that address out of the bucket and look at the next weird one on the list. 

On Nov 16, 2013, at 5:28 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:

> First, the location of CDN nodes is not relevant to passive DNS monitoring. If Andrew would like a list of domains with CDN hostnames in them, that might be findable.
> 
> Second, a list of CDN nodes is likely impossible to gather & maintain without the help of the CDNs themselves. There are literally thousands of them, most do not serve the entire Internet, and they change frequently. And before you ask, I know at least Akamai will _not_ give you their list, so don't even try to ask them.
> 
> Sorry this makes your life more difficult. Perhaps if you explained why you were doing address lookups, the collective body could help you come up with a better solution?
> 
> -- 
> TTFN,
> patrick
> 
> 
> On Nov 15, 2013, at 10:06 , Michael Collins, Aleae <mcollins at aleae.com> wrote:
> 
>> I'll second that; CDNs are a constant pain for me when I'm doing address
>> lookups.  A list of them would make life a lot easier for a bunch of
>> different investigative processes. 
>> 
>> If there isn't one right now, I think I could get off my tuchas and
>> start maintaining one if anyone's interested in pitching in.
>> 
>> 
>> On 11/14/13 5:19 PM, Andrew Fried wrote:
>>> Actually, a list of CDNs would be very handy.  I harvest botnets and
>>> fast flux hosts out of passive dns, and some of the heuristics used to
>>> identify them are similar to what CDNs look like.
>>> 
>>> Having a decent list of CDN effective top level domains alone would be
>>> useful for redacting those hosts.
>>> 
>>> Andy
>>> 
>>> 
>>> Andrew Fried
>>> andrew.fried at gmail.com
>>> 
>>> On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote:
>>>> List of CDNs would be difficult, but not impossible. Although they do different things, so a simple list is unlikely to be as useful as it looks. 
>>>> 
>>>> A lost of CDN "DC nodes" is not possible. Why do you care about such a thing anyway?
>>>> 
>> 
>> 
> 



From jra at baylink.com  Sun Nov 17 00:36:40 2013
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 16 Nov 2013 19:36:40 -0500 (EST)
Subject: CDN node locations
In-Reply-To: <1E8DDE94-8595-4C50-B3F2-AF78E0E627F6@ianai.net>
Message-ID: <20110405.1978.1384648600292.JavaMail.root@benjamin.baylink.com>

> Second, a list of CDN nodes is likely impossible to gather & maintain
> without the help of the CDNs themselves. There are literally thousands
> of them, most do not serve the entire Internet, and they change
> frequently. And before you ask, I know at least Akamai will _not_ give
> you their list, so don't even try to ask them.

I find myself unsurprised.

I was led to a very interesting failure case involving CDN's a couple weeks
ago, that I thought you might find amusing.

I have a Samsung Galaxy S4, with Sprint.  On a semi-regular basis, the 
networking gets flaky around 1-2am ish local time, but 3 weekends ago, 
the symptom I saw was DNS lookups failed -- and it wasn't clear to me
whether it was "just some lookups failed", or that Big Sites were cached 
at the provider, and *all* outgoing 53 traffic to the greater internet
wasn't being forwarded by Sprint's customer resolvers.

I know that it was their resolvers, though, as I grabbed a copy of Set DNS, 
and pointed my phone to 8.8.8.8, and 4.2.2.1, and OpenDNS, and like that, 
and everything worked ok.

Except media.

(Patrick is starting to nod and chuckle, now :-)

Both YouTube and The Daily Show's apps worked ok, but refused to play
video clips for me.  If I reset the DNS to normal, I went back to "not
all sites are reachable, but media plays fine".

My diagnosis was that those sites were CDNed, and the DNS names to *which*
they were CDNs were only visible inside Sprint's event horizon, so when I 
was on alternate DNS resolution, I couldn't get to them.

But that took me over a day to figure out.  Don't get old.  :-)

Patrick?  Is that how (at least some) customers do it? 

Cheers,
-- jra
-- 
Make Election Day a federal holiday: http://wh.gov/lBm94  100k sigs by 12/14

Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From patrick at ianai.net  Sun Nov 17 00:44:19 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sat, 16 Nov 2013 19:44:19 -0500
Subject: List of CDNs?
In-Reply-To: <FBBB76C4-1347-4CFF-8811-D4789C4BC49D@aleae.com>
References: <20131114220200.GA67966@ak-labs.net>
 <6663AFEC-6F15-4523-970F-B2AAD9580C47@ianai.net> <52854C84.6000204@gmail.com>
 <52863870.5020607@aleae.com> <1E8DDE94-8595-4C50-B3F2-AF78E0E627F6@ianai.net>
 <FBBB76C4-1347-4CFF-8811-D4789C4BC49D@aleae.com>
Message-ID: <7BCB1832-0C0C-412C-9F9C-6A48C17C9CCC@ianai.net>

On Nov 16, 2013, at 19:30 , Michael Collins <mcollins at aleae.com> wrote:

> It's Yet Another False Positive in anomaly detection and traffic analysis software that I fiddle with.  In the case of CDNs, I mostly want to throw them out the window -- whenever I see one, I know that the reverse lookup information is going to be useless and it's time to toss that address out of the bucket and look at the next weird one on the list. 

Not sure why in-addr on CDN would be any different than .. well, anything.

Perhaps I do not understand your use case well enough?

-- 
TTFN,
patrick


> On Nov 16, 2013, at 5:28 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> 
>> First, the location of CDN nodes is not relevant to passive DNS monitoring. If Andrew would like a list of domains with CDN hostnames in them, that might be findable.
>> 
>> Second, a list of CDN nodes is likely impossible to gather & maintain without the help of the CDNs themselves. There are literally thousands of them, most do not serve the entire Internet, and they change frequently. And before you ask, I know at least Akamai will _not_ give you their list, so don't even try to ask them.
>> 
>> Sorry this makes your life more difficult. Perhaps if you explained why you were doing address lookups, the collective body could help you come up with a better solution?
>> 
>> -- 
>> TTFN,
>> patrick
>> 
>> 
>> On Nov 15, 2013, at 10:06 , Michael Collins, Aleae <mcollins at aleae.com> wrote:
>> 
>>> I'll second that; CDNs are a constant pain for me when I'm doing address
>>> lookups.  A list of them would make life a lot easier for a bunch of
>>> different investigative processes. 
>>> 
>>> If there isn't one right now, I think I could get off my tuchas and
>>> start maintaining one if anyone's interested in pitching in.
>>> 
>>> 
>>> On 11/14/13 5:19 PM, Andrew Fried wrote:
>>>> Actually, a list of CDNs would be very handy.  I harvest botnets and
>>>> fast flux hosts out of passive dns, and some of the heuristics used to
>>>> identify them are similar to what CDNs look like.
>>>> 
>>>> Having a decent list of CDN effective top level domains alone would be
>>>> useful for redacting those hosts.
>>>> 
>>>> Andy
>>>> 
>>>> 
>>>> Andrew Fried
>>>> andrew.fried at gmail.com
>>>> 
>>>> On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote:
>>>>> List of CDNs would be difficult, but not impossible. Although they do different things, so a simple list is unlikely to be as useful as it looks. 
>>>>> 
>>>>> A lost of CDN "DC nodes" is not possible. Why do you care about such a thing anyway?
>>>>> 
>>> 
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131116/92eed511/attachment.bin>

From patrick at ianai.net  Sun Nov 17 01:07:42 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sat, 16 Nov 2013 20:07:42 -0500
Subject: CDN node locations
In-Reply-To: <20110405.1978.1384648600292.JavaMail.root@benjamin.baylink.com>
References: <20110405.1978.1384648600292.JavaMail.root@benjamin.baylink.com>
Message-ID: <EDAE775D-0689-47F1-84BE-66383A810883@ianai.net>

On Nov 16, 2013, at 19:36 , Jay Ashworth <jra at baylink.com> wrote:

>> Second, a list of CDN nodes is likely impossible to gather & maintain
>> without the help of the CDNs themselves. There are literally thousands
>> of them, most do not serve the entire Internet, and they change
>> frequently. And before you ask, I know at least Akamai will _not_ give
>> you their list, so don't even try to ask them.
> 
> I find myself unsurprised.
> 
> I was led to a very interesting failure case involving CDN's a couple weeks
> ago, that I thought you might find amusing.
> 
> I have a Samsung Galaxy S4, with Sprint.  On a semi-regular basis, the 
> networking gets flaky around 1-2am ish local time, but 3 weekends ago, 
> the symptom I saw was DNS lookups failed -- and it wasn't clear to me
> whether it was "just some lookups failed", or that Big Sites were cached 
> at the provider, and *all* outgoing 53 traffic to the greater internet
> wasn't being forwarded by Sprint's customer resolvers.
> 
> I know that it was their resolvers, though, as I grabbed a copy of Set DNS, 
> and pointed my phone to 8.8.8.8, and 4.2.2.1, and OpenDNS, and like that, 
> and everything worked ok.
> 
> Except media.
> 
> (Patrick is starting to nod and chuckle, now :-)
> 
> Both YouTube and The Daily Show's apps worked ok, but refused to play
> video clips for me.  If I reset the DNS to normal, I went back to "not
> all sites are reachable, but media plays fine".
> 
> My diagnosis was that those sites were CDNed, and the DNS names to *which*
> they were CDNs were only visible inside Sprint's event horizon, so when I 
> was on alternate DNS resolution, I couldn't get to them.
> 
> But that took me over a day to figure out.  Don't get old.  :-)
> 
> Patrick?  Is that how (at least some) customers do it? 

#1: I could not possibly comment on customers. But since I've only worked at Markley Group for 3 weeks, I don't know all the customers, so I couldn't tell you even if they were customers at all, more or less how they do things. Besides, Markley Group ain't a CDN.

#2: Assuming you are assuming I still work at Akamai (I don't), and are asking me if that's how Akamai does things, I couldn't possibly comment on customers at a previous position. Everything I've said up to now was either public knowledge or something I was more than happy to give out publicly if asked while I was at Akamai. The query above, specifically "is XXX how customer YYY does things", is neither of those.

But in the more general sense, your hypothesis does not really fit the circumstances completely. DNS is orthogonal to serving bits. If Sprint's DNS is f00bar'ed, then you can't resolve anything, CDN-ififed or not. It is true some CDNs put some name servers inside other networks, but that is still a race condition, because (for instance) Akamai's DNS TTL is 20 seconds. You have to go back 'outside' eventually to get stuff, which means relying on Sprint's recursive NSes.

Plus the two sites you list (YouTube & DailyShow) are not on the same infrastructure. Google hosts its own videos, DailyShow is not hosted on Google (AFAIK), therefore they must be two different companies using two different pieces of equipment and two different name server algorithms / topologies. It would be weird that Sprint's failure mode worked fine for those two and nothing else.

Sorry.

-- 
TTFN,
patrick

P.S. I wasn't chuckling. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131116/a96fba93/attachment-0001.bin>

From bedard.phil at gmail.com  Sun Nov 17 01:25:58 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Sat, 16 Nov 2013 20:25:58 -0500
Subject: CDN node locations
In-Reply-To: <20110405.1978.1384648600292.JavaMail.root@benjamin.baylink.com>
Message-ID: <CEAD842E.7DEB8%bedard.phil@gmail.com>

On 11/16/13, 7:36 PM, "Jay Ashworth" <jra at baylink.com> wrote:


>> Second, a list of CDN nodes is likely impossible to gather & maintain
>> without the help of the CDNs themselves. There are literally thousands
>> of them, most do not serve the entire Internet, and they change
>> frequently. And before you ask, I know at least Akamai will _not_ give
>> you their list, so don't even try to ask them.
>
>I find myself unsurprised.
>
>I was led to a very interesting failure case involving CDN's a couple
>weeks
>ago, that I thought you might find amusing.
>
>I have a Samsung Galaxy S4, with Sprint.  On a semi-regular basis, the
>networking gets flaky around 1-2am ish local time, but 3 weekends ago,
>the symptom I saw was DNS lookups failed -- and it wasn't clear to me
>whether it was "just some lookups failed", or that Big Sites were cached
>at the provider, and *all* outgoing 53 traffic to the greater internet
>wasn't being forwarded by Sprint's customer resolvers.
>
>I know that it was their resolvers, though, as I grabbed a copy of Set
>DNS, 
>and pointed my phone to 8.8.8.8, and 4.2.2.1, and OpenDNS, and like that,
>and everything worked ok.
>
>Except media.
>
>(Patrick is starting to nod and chuckle, now :-)
>
>Both YouTube and The Daily Show's apps worked ok, but refused to play
>video clips for me.  If I reset the DNS to normal, I went back to "not
>all sites are reachable, but media plays fine".
>
>My diagnosis was that those sites were CDNed, and the DNS names to *which*
>they were CDNs were only visible inside Sprint's event horizon, so when I
>was on alternate DNS resolution, I couldn't get to them.
>
>But that took me over a day to figure out.  Don't get old.  :-)
>
>Patrick?  Is that how (at least some) customers do it?


It seems more likely the Sprint resolvers you were using were having
difficulty reaching external authoratative servers but the devices they
proxy all the media content through wasn't...  All major media content
these days is CDN'd but I don't think that had anything to do with it.

Phil 




From jra at baylink.com  Sun Nov 17 01:56:15 2013
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 16 Nov 2013 20:56:15 -0500
Subject: CDN node locations
In-Reply-To: <CEAD842E.7DEB8%bedard.phil@gmail.com>
References: <CEAD842E.7DEB8%bedard.phil@gmail.com>
Message-ID: <7c4abff3-4bf6-4ff6-8954-5cefa0e9aca8@email.android.com>

Maybe, but I don't use their proxies, I've overriden them for speed.  

Phil Bedard <bedard.phil at gmail.com> wrote:
>On 11/16/13, 7:36 PM, "Jay Ashworth" <jra at baylink.com> wrote:
>
>
>>> Second, a list of CDN nodes is likely impossible to gather &
>maintain
>>> without the help of the CDNs themselves. There are literally
>thousands
>>> of them, most do not serve the entire Internet, and they change
>>> frequently. And before you ask, I know at least Akamai will _not_
>give
>>> you their list, so don't even try to ask them.
>>
>>I find myself unsurprised.
>>
>>I was led to a very interesting failure case involving CDN's a couple
>>weeks
>>ago, that I thought you might find amusing.
>>
>>I have a Samsung Galaxy S4, with Sprint.  On a semi-regular basis, the
>>networking gets flaky around 1-2am ish local time, but 3 weekends ago,
>>the symptom I saw was DNS lookups failed -- and it wasn't clear to me
>>whether it was "just some lookups failed", or that Big Sites were
>cached
>>at the provider, and *all* outgoing 53 traffic to the greater internet
>>wasn't being forwarded by Sprint's customer resolvers.
>>
>>I know that it was their resolvers, though, as I grabbed a copy of Set
>>DNS, 
>>and pointed my phone to 8.8.8.8, and 4.2.2.1, and OpenDNS, and like
>that,
>>and everything worked ok.
>>
>>Except media.
>>
>>(Patrick is starting to nod and chuckle, now :-)
>>
>>Both YouTube and The Daily Show's apps worked ok, but refused to play
>>video clips for me.  If I reset the DNS to normal, I went back to "not
>>all sites are reachable, but media plays fine".
>>
>>My diagnosis was that those sites were CDNed, and the DNS names to
>*which*
>>they were CDNs were only visible inside Sprint's event horizon, so
>when I
>>was on alternate DNS resolution, I couldn't get to them.
>>
>>But that took me over a day to figure out.  Don't get old.  :-)
>>
>>Patrick?  Is that how (at least some) customers do it?
>
>
>It seems more likely the Sprint resolvers you were using were having
>difficulty reaching external authoratative servers but the devices they
>proxy all the media content through wasn't...  All major media content
>these days is CDN'd but I don't think that had anything to do with it.
>
>Phil 

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

From bedard.phil at gmail.com  Sun Nov 17 02:08:06 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Sat, 16 Nov 2013 21:08:06 -0500
Subject: CDN node locations
In-Reply-To: <7c4abff3-4bf6-4ff6-8954-5cefa0e9aca8@email.android.com>
Message-ID: <CEAD8D8A.7DEC5%bedard.phil@gmail.com>

http://www.sprint.com/legal/open_internet_information.html

Maybe "proxy" was the wrong word, and "transparent video optimization" are
better words.  :)  I'm not speaking with any internal knowledge of Sprint
Wireless's network but I wouldn't be surprised if you had no choice in the
matter.  

Phil 

From:  Jay Ashworth <jra at baylink.com>
Date:  Saturday, November 16, 2013 at 8:56 PM
To:  Phil Bedard <bedard.phil at gmail.com>, NANOG <nanog at nanog.org>
Subject:  Re: CDN node locations

Maybe, but I don't use their proxies, I've overriden them for speed.

Phil Bedard <bedard.phil at gmail.com> wrote:
> On 11/16/13, 7:36 PM, "Jay Ashworth" <jra at baylink.com> wrote:
> 
> 
>>> Second, a list of CDN nodes is likely impossible to gather & maintain
>>> without the help of the CDNs themselves. There are literally thousands
>>> of them, most do not serve the entire Internet, and they change
>>> frequently. And before you ask, I know at least Akamai will _not_ give
>>> you their list, so don't even try to ask them.
>> 
>> I find myself unsurprised.
>> 
>> I was led to a very interesting failure case involving CDN's a couple
>> weeks
>> ago, that I thought you might find amusing.
>> 
>> I have a Samsung Galaxy S4, with Sprint.  On a semi-regular basis, the
>> networking gets flaky around
>>  1-2am
>> ish local time, but 3 weekends ago,
>> the symptom I saw was DNS lookups failed -- and it wasn't clear to me
>> whether it was "just some lookups failed", or that Big Sites were cached
>> at the provider, and *all* outgoing 53 traffic to the greater internet
>> wasn't being forwarded by Sprint's customer resolvers.
>> 
>> I know that it was their resolvers, though, as I grabbed a copy of Set
>> DNS, 
>> and pointed my phone to 8.8.8.8 <http://8.8.8.8> , and 4.2.2.1
>> <http://4.2.2.1> , and OpenDNS, and like that,
>> and everything worked ok.
>> 
>> Except media.
>> 
>> (Patrick is starting to nod and chuckle, now :-)
>> 
>> Both YouTube and The Daily Show's apps worked ok, but refused to play
>> video clips for me.  If I reset the DNS to normal, I went back to "not
>> all sites are reachable, but media plays fine".
>> 
>> My diagnosis was that those sites were CDNed, and the DNS names to *which*
>> they were CDNs wer
>>  e only
>> visible inside Sprint's event horizon, so when I
>> was on alternate DNS resolution, I couldn't get to them.
>> 
>> But that took me over a day to figure out.  Don't get old.  :-)
>> 
>> Patrick?  Is that how (at least some) customers do it?
> 
> 
> It seems more likely the Sprint resolvers you were using were having
> difficulty reaching external authoratative servers but the devices they
> proxy all the media content through wasn't...  All major media content
> these days is CDN'd but I don't think that had anything to do with it.
> 
> Phil 
> 
> 

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



From wbailey at satelliteintelligencegroup.com  Sun Nov 17 06:21:52 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Sun, 17 Nov 2013 06:21:52 +0000
Subject: CDN node locations
In-Reply-To: <EDAE775D-0689-47F1-84BE-66383A810883@ianai.net>
References: <20110405.1978.1384648600292.JavaMail.root@benjamin.baylink.com>,
 <EDAE775D-0689-47F1-84BE-66383A810883@ianai.net>
Message-ID: <0kcsojxgllkepqwb5f3iuqmq.1384669306176@email.android.com>

Uhhhh.. So who gets to field the Akamai questions now? ;)


Sent from my Mobile Device.


-------- Original message --------
From: "Patrick W. Gilmore" <patrick at ianai.net>
Date: 11/16/2013 4:10 PM (GMT-09:00)
To: NANOG list <nanog at nanog.org>
Subject: Re: CDN node locations


On Nov 16, 2013, at 19:36 , Jay Ashworth <jra at baylink.com> wrote:

>> Second, a list of CDN nodes is likely impossible to gather & maintain
>> without the help of the CDNs themselves. There are literally thousands
>> of them, most do not serve the entire Internet, and they change
>> frequently. And before you ask, I know at least Akamai will _not_ give
>> you their list, so don't even try to ask them.
>
> I find myself unsurprised.
>
> I was led to a very interesting failure case involving CDN's a couple weeks
> ago, that I thought you might find amusing.
>
> I have a Samsung Galaxy S4, with Sprint.  On a semi-regular basis, the
> networking gets flaky around 1-2am ish local time, but 3 weekends ago,
> the symptom I saw was DNS lookups failed -- and it wasn't clear to me
> whether it was "just some lookups failed", or that Big Sites were cached
> at the provider, and *all* outgoing 53 traffic to the greater internet
> wasn't being forwarded by Sprint's customer resolvers.
>
> I know that it was their resolvers, though, as I grabbed a copy of Set DNS,
> and pointed my phone to 8.8.8.8, and 4.2.2.1, and OpenDNS, and like that,
> and everything worked ok.
>
> Except media.
>
> (Patrick is starting to nod and chuckle, now :-)
>
> Both YouTube and The Daily Show's apps worked ok, but refused to play
> video clips for me.  If I reset the DNS to normal, I went back to "not
> all sites are reachable, but media plays fine".
>
> My diagnosis was that those sites were CDNed, and the DNS names to *which*
> they were CDNs were only visible inside Sprint's event horizon, so when I
> was on alternate DNS resolution, I couldn't get to them.
>
> But that took me over a day to figure out.  Don't get old.  :-)
>
> Patrick?  Is that how (at least some) customers do it?

#1: I could not possibly comment on customers. But since I've only worked at Markley Group for 3 weeks, I don't know all the customers, so I couldn't tell you even if they were customers at all, more or less how they do things. Besides, Markley Group ain't a CDN.

#2: Assuming you are assuming I still work at Akamai (I don't), and are asking me if that's how Akamai does things, I couldn't possibly comment on customers at a previous position. Everything I've said up to now was either public knowledge or something I was more than happy to give out publicly if asked while I was at Akamai. The query above, specifically "is XXX how customer YYY does things", is neither of those.

But in the more general sense, your hypothesis does not really fit the circumstances completely. DNS is orthogonal to serving bits. If Sprint's DNS is f00bar'ed, then you can't resolve anything, CDN-ififed or not. It is true some CDNs put some name servers inside other networks, but that is still a race condition, because (for instance) Akamai's DNS TTL is 20 seconds. You have to go back 'outside' eventually to get stuff, which means relying on Sprint's recursive NSes.

Plus the two sites you list (YouTube & DailyShow) are not on the same infrastructure. Google hosts its own videos, DailyShow is not hosted on Google (AFAIK), therefore they must be two different companies using two different pieces of equipment and two different name server algorithms / topologies. It would be weird that Sprint's failure mode worked fine for those two and nothing else.

Sorry.

--
TTFN,
patrick

P.S. I wasn't chuckling. :)


From mksmith at mac.com  Sun Nov 17 17:46:20 2013
From: mksmith at mac.com (Michael Smith)
Date: Sun, 17 Nov 2013 09:46:20 -0800
Subject: Question on routing of Tata AS6453 with their other network AS4755
In-Reply-To: <CAJ0+aXZ1E9zvVP7PgLrMOELdRa3fYcPM7pbgZtJNofcEZMP3wA@mail.gmail.com>
References: <CAJ0+aXZ1E9zvVP7PgLrMOELdRa3fYcPM7pbgZtJNofcEZMP3wA@mail.gmail.com>
Message-ID: <1AC8302C-304F-48BE-BB39-5F2309409954@mac.com>


On Nov 16, 2013, at 11:49 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Hello everyone
> 
> 
> I was looking around and noticed a pretty bad route from DTAG to Tata
> AS6453 (basically destination was Tata Comm's Indian network on AS4755). I
> am not able to understand cause for inefficient routing but I am sure I am
> failing to understand something which is crazy in their IGP. The result is
> that route from Europe to India is via Europe > US > Singapore > India
> rather then direct India.
> 
<snip>

I think you'll find that these decisions are intentional and driven by the cost of routes headed direct over land from EU to India.  Ask Tata for a price quote for transit internet services in the EU and, separately, for transit internet in the EU that go direct from EU to India.  They are not the same price.

Regards,

Mike

From courtneysmith at comcast.net  Sun Nov 17 18:09:00 2013
From: courtneysmith at comcast.net (Courtney Smith)
Date: Sun, 17 Nov 2013 13:09:00 -0500
Subject: Cisco announces it will no longer publishing The Internet Protocol
 Journal
Message-ID: <AF6DC6BC-80EF-48C6-BCEB-D5CDDD9565B7@comcast.net>

Another one bites the dust.   Received the below this AM.  Hopefully, something similar finds it's way into an electronic format.


TO OUR READERS

At this time, Cisco Systems, Inc. has decided not to continue publishing The Internet Protocol Journal (IPJ) effective immediately.

Cisco wishes to thank Ole Jacobsen, the Editor and Publisher of IPJ for his tireless and professional efforts to inform the community of the Internet, its varied protocols, and its impact upon the world through this publication. Cisco also wishes to thank the authors of the published articles, and all those who submitted articles. A special note of thanks goes to the IPJ Editorial Advisory Board and the article reviewers who have helped to maintain the very high standards of journalistic and technical quality of IPJ.

The online version of the Internet Protocol Journal will remain available for reference, including all back issues in PDF and HTML format as well as the index files. The IPJ website remains at:http://www.cisco.com/ipj



Courtney Smith
courtneysmith at comcast.net

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments





From Jason_Livingood at cable.comcast.com  Sun Nov 17 18:19:21 2013
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Sun, 17 Nov 2013 18:19:21 +0000
Subject: Cisco announces it will no longer publishing The Internet
 Protocol Journal
In-Reply-To: <AF6DC6BC-80EF-48C6-BCEB-D5CDDD9565B7@comcast.net>
Message-ID: <10229F86C86EB444898E629583FD4171EDE0DC94@PACDCEXMB06.cable.comcast.com>

While Cisco won?t solely publish it, I?d call it too soon to say it is
dead. ;-) Ole (copied) is a pretty resourceful guy and is working on ways
to keep it going. Ping him 1:1 if you would like more info or like to help.


Jason

On 11/17/13, 1:09 PM, "Courtney Smith" <courtneysmith at comcast.net> wrote:

>Another one bites the dust.   Received the below this AM.  Hopefully,
>something similar finds it's way into an electronic format.
>
>
>TO OUR READERS
>
>At this time, Cisco Systems, Inc. has decided not to continue publishing
>The Internet Protocol Journal (IPJ) effective immediately.
>
>Cisco wishes to thank Ole Jacobsen, the Editor and Publisher of IPJ for
>his tireless and professional efforts to inform the community of the
>Internet, its varied protocols, and its impact upon the world through
>this publication. Cisco also wishes to thank the authors of the published
>articles, and all those who submitted articles. A special note of thanks
>goes to the IPJ Editorial Advisory Board and the article reviewers who
>have helped to maintain the very high standards of journalistic and
>technical quality of IPJ.
>
>The online version of the Internet Protocol Journal will remain available
>for reference, including all back issues in PDF and HTML format as well
>as the index files. The IPJ website remains at:http://www.cisco.com/ipj
>
>
>
>Courtney Smith
>courtneysmith at comcast.net
>
>()  ascii ribbon campaign - against html e-mail
>/\  www.asciiribbon.org   - against proprietary attachments
>
>
>
>



From jeff.tantsura at ericsson.com  Sun Nov 17 19:11:14 2013
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Sun, 17 Nov 2013 19:11:14 +0000
Subject: Cisco announces it will no longer publishing The Internet
 Protocol Journal
In-Reply-To: <AF6DC6BC-80EF-48C6-BCEB-D5CDDD9565B7@comcast.net>
References: <AF6DC6BC-80EF-48C6-BCEB-D5CDDD9565B7@comcast.net>
Message-ID: <689ADD7B-6B9F-473A-AB96-8640E3A5F39C@ericsson.com>

Ole is not with Cisco anymore.

Regards,
Jeff

> On Nov 17, 2013, at 10:11, "Courtney Smith" <courtneysmith at comcast.net> wrote:
> 
> Another one bites the dust.   Received the below this AM.  Hopefully, something similar finds it's way into an electronic format.
> 
> 
> TO OUR READERS
> 
> At this time, Cisco Systems, Inc. has decided not to continue publishing The Internet Protocol Journal (IPJ) effective immediately.
> 
> Cisco wishes to thank Ole Jacobsen, the Editor and Publisher of IPJ for his tireless and professional efforts to inform the community of the Internet, its varied protocols, and its impact upon the world through this publication. Cisco also wishes to thank the authors of the published articles, and all those who submitted articles. A special note of thanks goes to the IPJ Editorial Advisory Board and the article reviewers who have helped to maintain the very high standards of journalistic and technical quality of IPJ.
> 
> The online version of the Internet Protocol Journal will remain available for reference, including all back issues in PDF and HTML format as well as the index files. The IPJ website remains at:http://www.cisco.com/ipj
> 
> 
> 
> Courtney Smith
> courtneysmith at comcast.net
> 
> ()  ascii ribbon campaign - against html e-mail 
> /\  www.asciiribbon.org   - against proprietary attachments
> 
> 
> 
> 


From plucena at coopergeneral.com  Sun Nov 17 13:23:46 2013
From: plucena at coopergeneral.com (Pablo Lucena)
Date: Sun, 17 Nov 2013 08:23:46 -0500
Subject: Best band for your buck router and switch (gigabit)
In-Reply-To: <CAN3um4x3haNHj7pvE1dAJexn3U7zW_md2piuNBarxm0pbziqjA@mail.gmail.com>
References: <CAGWRaZZ3i6r4=J8ptNfeorLFx_f8U8NSs4A+D=tLzakF+ZH6Wg@mail.gmail.com>
 <7072670D-B02D-46D5-99B7-9D23AFEACCA3@mac.com>
 <CAC2aK2pjV8hFBFnFMWhrdac83qyYgygJ9+vzZu_7QHeYF5dddQ@mail.gmail.com>
 <5287A828.1090707@jasonantman.com>
 <CAGWRaZaJLVaA=G_xoY1yFtVzqR3_DS-xO7QSeAC8Ofs-=zKRsw@mail.gmail.com>
 <CAGWRaZYZ25mHxr2p6qPpgvbMUBfWJmqQHZTLJ0+3Ly7nxrxUzQ@mail.gmail.com>
 <CAN3um4wj_Nxu7LmVcPZRJtq-LOKFJf-h56uHY-sELaUGLNg4Aw@mail.gmail.com>
 <CAGWRaZYOHr_x+F0aQk6zNw32N9p=9bJiMEiDgS-n0e6KjWAdrg@mail.gmail.com>
 <CAN3um4x3haNHj7pvE1dAJexn3U7zW_md2piuNBarxm0pbziqjA@mail.gmail.com>
Message-ID: <CAH+2GVJVgB7zk39F4c2Wcpiw5Xz64fyCLE4KFiS11d46Op=ftw@mail.gmail.com>

What about a Cisco cloud services router? These devices scale quite nicely.
You can even use them for 60 days on a trial license.


On Sat, Nov 16, 2013 at 6:50 PM, Mike Hale <eyeronic.design at gmail.com>wrote:

> We get ours from Network Hardware Resellers.  It's
> Smartnet-contractable, which is important for us, and was pretty
> cheap.
>
> Shoot me a message offlist if you want our sales rep's info.  He might
> be able to help you out.
>
> On Sat, Nov 16, 2013 at 3:35 PM, Nick Cameo <symack at gmail.com> wrote:
> > If anyone has one for sale that has not had it's ports beat to hell
> > please let us know.
> > We would be interested.
>
>
>
> --
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>
>


-- 

*Pablo Lucena*

*Cooper General Global Services*

*Network Administrator*

*Office: 305-418-4440 ext. 130*

*plucena at coopergeneral.com <plucena at coopergeneral.com>*

From hannigan at gmail.com  Sun Nov 17 20:32:06 2013
From: hannigan at gmail.com (Martin Hannigan)
Date: Sun, 17 Nov 2013 18:32:06 -0200
Subject: CDN node locations
In-Reply-To: <0kcsojxgllkepqwb5f3iuqmq.1384669306176@email.android.com>
References: <20110405.1978.1384648600292.JavaMail.root@benjamin.baylink.com>
 <EDAE775D-0689-47F1-84BE-66383A810883@ianai.net>
 <0kcsojxgllkepqwb5f3iuqmq.1384669306176@email.android.com>
Message-ID: <CAMDXq5NiW+Eg-Qx3u9OQASfbd+oCaqr=LiW-ZNVk7EQXQrD8Zg@mail.gmail.com>

There are a number of us here.

Best,

-M<




On Sun, Nov 17, 2013 at 3:21 AM, Warren Bailey <
wbailey at satelliteintelligencegroup.com> wrote:

> Uhhhh.. So who gets to field the Akamai questions now? ;)
>
>
> Sent from my Mobile Device.
>
>
> -------- Original message --------
> From: "Patrick W. Gilmore" <patrick at ianai.net>
> Date: 11/16/2013 4:10 PM (GMT-09:00)
> To: NANOG list <nanog at nanog.org>
> Subject: Re: CDN node locations
>
>
> On Nov 16, 2013, at 19:36 , Jay Ashworth <jra at baylink.com> wrote:
>
> >> Second, a list of CDN nodes is likely impossible to gather & maintain
> >> without the help of the CDNs themselves. There are literally thousands
> >> of them, most do not serve the entire Internet, and they change
> >> frequently. And before you ask, I know at least Akamai will _not_ give
> >> you their list, so don't even try to ask them.
> >
> > I find myself unsurprised.
> >
> > I was led to a very interesting failure case involving CDN's a couple
> weeks
> > ago, that I thought you might find amusing.
> >
> > I have a Samsung Galaxy S4, with Sprint.  On a semi-regular basis, the
> > networking gets flaky around 1-2am ish local time, but 3 weekends ago,
> > the symptom I saw was DNS lookups failed -- and it wasn't clear to me
> > whether it was "just some lookups failed", or that Big Sites were cached
> > at the provider, and *all* outgoing 53 traffic to the greater internet
> > wasn't being forwarded by Sprint's customer resolvers.
> >
> > I know that it was their resolvers, though, as I grabbed a copy of Set
> DNS,
> > and pointed my phone to 8.8.8.8, and 4.2.2.1, and OpenDNS, and like that,
> > and everything worked ok.
> >
> > Except media.
> >
> > (Patrick is starting to nod and chuckle, now :-)
> >
> > Both YouTube and The Daily Show's apps worked ok, but refused to play
> > video clips for me.  If I reset the DNS to normal, I went back to "not
> > all sites are reachable, but media plays fine".
> >
> > My diagnosis was that those sites were CDNed, and the DNS names to
> *which*
> > they were CDNs were only visible inside Sprint's event horizon, so when I
> > was on alternate DNS resolution, I couldn't get to them.
> >
> > But that took me over a day to figure out.  Don't get old.  :-)
> >
> > Patrick?  Is that how (at least some) customers do it?
>
> #1: I could not possibly comment on customers. But since I've only worked
> at Markley Group for 3 weeks, I don't know all the customers, so I couldn't
> tell you even if they were customers at all, more or less how they do
> things. Besides, Markley Group ain't a CDN.
>
> #2: Assuming you are assuming I still work at Akamai (I don't), and are
> asking me if that's how Akamai does things, I couldn't possibly comment on
> customers at a previous position. Everything I've said up to now was either
> public knowledge or something I was more than happy to give out publicly if
> asked while I was at Akamai. The query above, specifically "is XXX how
> customer YYY does things", is neither of those.
>
> But in the more general sense, your hypothesis does not really fit the
> circumstances completely. DNS is orthogonal to serving bits. If Sprint's
> DNS is f00bar'ed, then you can't resolve anything, CDN-ififed or not. It is
> true some CDNs put some name servers inside other networks, but that is
> still a race condition, because (for instance) Akamai's DNS TTL is 20
> seconds. You have to go back 'outside' eventually to get stuff, which means
> relying on Sprint's recursive NSes.
>
> Plus the two sites you list (YouTube & DailyShow) are not on the same
> infrastructure. Google hosts its own videos, DailyShow is not hosted on
> Google (AFAIK), therefore they must be two different companies using two
> different pieces of equipment and two different name server algorithms /
> topologies. It would be weird that Sprint's failure mode worked fine for
> those two and nothing else.
>
> Sorry.
>
> --
> TTFN,
> patrick
>
> P.S. I wasn't chuckling. :)
>
>

From me at anuragbhatia.com  Mon Nov 18 08:01:46 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Mon, 18 Nov 2013 13:31:46 +0530
Subject: Question on routing of Tata AS6453 with their other network AS4755
In-Reply-To: <1AC8302C-304F-48BE-BB39-5F2309409954@mac.com>
References: <CAJ0+aXZ1E9zvVP7PgLrMOELdRa3fYcPM7pbgZtJNofcEZMP3wA@mail.gmail.com>
 <1AC8302C-304F-48BE-BB39-5F2309409954@mac.com>
Message-ID: <CAJ0+aXZFxWza0TaZKom2F8WVVb4JsgjHPm-Co4GkDAm3sBq+gA@mail.gmail.com>

Heu Michael


But this time AS4755 wasn't their customer. It's their own network in
India!


I think probably it will be hard for us and in general for technical
community to comment on business side of it but I am just curious on
technical side on what it is like that? Is it missing iBGP sessions or just
intentional filtering of a group of prefixes via a peer group or based on
some community tag?



Thanks.


On Sun, Nov 17, 2013 at 11:16 PM, Michael Smith <mksmith at mac.com> wrote:

>
> On Nov 16, 2013, at 11:49 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:
>
> > Hello everyone
> >
> >
> > I was looking around and noticed a pretty bad route from DTAG to Tata
> > AS6453 (basically destination was Tata Comm's Indian network on AS4755).
> I
> > am not able to understand cause for inefficient routing but I am sure I
> am
> > failing to understand something which is crazy in their IGP. The result
> is
> > that route from Europe to India is via Europe > US > Singapore > India
> > rather then direct India.
> >
> <snip>
>
> I think you'll find that these decisions are intentional and driven by the
> cost of routes headed direct over land from EU to India.  Ask Tata for a
> price quote for transit internet services in the EU and, separately, for
> transit internet in the EU that go direct from EU to India.  They are not
> the same price.
>
> Regards,
>
> Mike




-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From robachevsky at isoc.org  Mon Nov 18 13:34:48 2013
From: robachevsky at isoc.org (Andrei Robachevsky)
Date: Mon, 18 Nov 2013 14:34:48 +0100
Subject: Routing Resilience Survey (a project coordinated by ISOC)
Message-ID: <528A1778.8070101@isoc.org>

Hello everyone,

I'd like to draw your attention to an effort coordinated by the Internet
Society aimed at a better understanding of Internet-wide routing
security issues. This effort is based on the collection of incident data
related to routing resiliency to provide a statistically representative
picture of these incidents and their impacts, as a basis for risk
assessment and global trend analysis.

We would like to invite network operators to join this effort. You can
find more information about this project here:

https://www.internetsociety.org/rrs/

For participating network operators the project will help answering
questions like:
- What happens with my prefixes elsewhere in the global Internet?
- What impact routing misconfigurations can have on my network?
- How "safe" the global routing system is?

One important thing I'd like to mention here is related to
confidentiality. We understand the sensitivity of some of the data
involved in this effort. Therefore, the Internet Society is committed to
ensuring participant-specific information remains confidential. All data
collected will be stored on Internet Society servers. Any public
information or analyses will be fully anonymized.

This is a 6-month effort. After the project is successfully completed we
will publish a report presenting the findings, statistical data and
trends. We'll also be happy to present the results at one of NANOG meetings.

We hope you will join this effort.

Thanks,

Andrei Robachevsky
Internet Society




From jared at puck.nether.net  Mon Nov 18 18:17:07 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 18 Nov 2013 13:17:07 -0500
Subject: Question on routing of Tata AS6453 with their other network AS4755
In-Reply-To: <CAJ0+aXZFxWza0TaZKom2F8WVVb4JsgjHPm-Co4GkDAm3sBq+gA@mail.gmail.com>
References: <CAJ0+aXZ1E9zvVP7PgLrMOELdRa3fYcPM7pbgZtJNofcEZMP3wA@mail.gmail.com>
 <1AC8302C-304F-48BE-BB39-5F2309409954@mac.com>
 <CAJ0+aXZFxWza0TaZKom2F8WVVb4JsgjHPm-Co4GkDAm3sBq+gA@mail.gmail.com>
Message-ID: <4BF89637-6717-4D32-B784-B84357A03BAC@puck.nether.net>


On Nov 18, 2013, at 3:01 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Heu Michael
> 
> 
> But this time AS4755 wasn't their customer. It's their own network in
> India!
> 
> 
> I think probably it will be hard for us and in general for technical
> community to comment on business side of it but I am just curious on
> technical side on what it is like that? Is it missing iBGP sessions or just
> intentional filtering of a group of prefixes via a peer group or based on
> some community tag?

It's hard to tell what the right answer is without the prefix and diagnosing the problem from multiple locations.  Collecting data from various looking glasses in multiple cities and regions is always helpful to triangulate what is going on.

- Jared

From streiner at cluebyfour.org  Mon Nov 18 20:06:52 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Mon, 18 Nov 2013 15:06:52 -0500 (EST)
Subject: NAT64 and matching identities
Message-ID: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>

It's looking more and more like NAT64 will be in our future.  One of the 
valid concerns for NAT64 - much like NAT44 - is being able to determine 
the identity of a given user through the NAT at a given point in time.
How feasible this is depends on how robust/scalable $XYZ's translation 
logging capabilities are, and possibly how easily that data can be matched 
against a source of identify information, such as RADIUS accounting logs, 
DHCP lease logs, etc.

Other IPv6 transition mechanisms appear to be no less thorny than NAT64 
for a variety of reasons.

I'm curious to see how others are planning to tackle (or already have 
tacked) this issue.  Discussing vendor-specific solutions is fine, but I 
think keeping things as platform/vendor agnostic as possible for the time 
being would allow this thread to be more beneficial to a wider audience.

The floor is open...

jms


From tom.taylor.stds at gmail.com  Tue Nov 19 01:03:13 2013
From: tom.taylor.stds at gmail.com (Tom Taylor)
Date: Mon, 18 Nov 2013 20:03:13 -0500
Subject: NAT64 and matching identities
In-Reply-To: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
References: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
Message-ID: <528AB8D1.4070107@gmail.com>


On 18/11/2013 3:06 PM, Justin M. Streiner wrote:
> It's looking more and more like NAT64 will be in our future.  One of the
> valid concerns for NAT64 - much like NAT44 - is being able to determine
> the identity of a given user through the NAT at a given point in time.
> How feasible this is depends on how robust/scalable $XYZ's translation
> logging capabilities are, and possibly how easily that data can be
> matched against a source of identify information, such as RADIUS
> accounting logs, DHCP lease logs, etc.
>
> Other IPv6 transition mechanisms appear to be no less thorny than NAT64
> for a variety of reasons.
>
> I'm curious to see how others are planning to tackle (or already have
> tacked) this issue.  Discussing vendor-specific solutions is fine, but I
> think keeping things as platform/vendor agnostic as possible for the
> time being would allow this thread to be more beneficial to a wider
> audience.
>
> The floor is open...
>
> jms
>

For logging, the following IETF Behave WG drafts are nearly complete. 
The IPFIX version will be updated soon (I hope) to more closely match 
the SYSLOG based one. They both will match the new NAT MIB document, 
also listed below:

http://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/

http://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging/

http://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib/

There is also work being done on reducing log volumes by bulk allocation 
of ports. The following drafts will be combined to meet a Sunset WG 
milestone:

http://datatracker.ietf.org/doc/draft-chen-sunset4-cgn-port-allocation/

http://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-reduction/

http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn/

Tom Taylor



From pauldotwall at gmail.com  Tue Nov 19 02:22:20 2013
From: pauldotwall at gmail.com (Paul WALL)
Date: Mon, 18 Nov 2013 21:22:20 -0500
Subject: NAT64 and matching identities
In-Reply-To: <528AB8D1.4070107@gmail.com>
References: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
 <528AB8D1.4070107@gmail.com>
Message-ID: <CAHnQ7e+WRDbJmOBzp5wuBd9sam9piJ8CEEeiQ4NBLJiiE7u7mw@mail.gmail.com>

MSOs logging subscriber flows, what could possibly go wrong?

Drive slow, like a Sandvine under load,
Paul Wall


On Mon, Nov 18, 2013 at 8:03 PM, Tom Taylor <tom.taylor.stds at gmail.com>wrote:

>
> On 18/11/2013 3:06 PM, Justin M. Streiner wrote:
>
>> It's looking more and more like NAT64 will be in our future.  One of the
>> valid concerns for NAT64 - much like NAT44 - is being able to determine
>> the identity of a given user through the NAT at a given point in time.
>> How feasible this is depends on how robust/scalable $XYZ's translation
>> logging capabilities are, and possibly how easily that data can be
>> matched against a source of identify information, such as RADIUS
>> accounting logs, DHCP lease logs, etc.
>>
>> Other IPv6 transition mechanisms appear to be no less thorny than NAT64
>> for a variety of reasons.
>>
>> I'm curious to see how others are planning to tackle (or already have
>> tacked) this issue.  Discussing vendor-specific solutions is fine, but I
>> think keeping things as platform/vendor agnostic as possible for the
>> time being would allow this thread to be more beneficial to a wider
>> audience.
>>
>> The floor is open...
>>
>> jms
>>
>>
> For logging, the following IETF Behave WG drafts are nearly complete. The
> IPFIX version will be updated soon (I hope) to more closely match the
> SYSLOG based one. They both will match the new NAT MIB document, also
> listed below:
>
> http://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/
>
> http://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging/
>
> http://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib/
>
> There is also work being done on reducing log volumes by bulk allocation
> of ports. The following drafts will be combined to meet a Sunset WG
> milestone:
>
> http://datatracker.ietf.org/doc/draft-chen-sunset4-cgn-port-allocation/
>
> http://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-reduction/
>
> http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn/
>
> Tom Taylor
>
>
>

From Lee at asgard.org  Tue Nov 19 14:46:31 2013
From: Lee at asgard.org (Lee Howard)
Date: Tue, 19 Nov 2013 09:46:31 -0500
Subject: NAT64 and matching identities
In-Reply-To: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
Message-ID: <CEB0E2D2.39480%Lee@asgard.org>



On 11/18/13 3:06 PM, "Justin M. Streiner" <streiner at cluebyfour.org> wrote:

>It's looking more and more like NAT64 will be in our future.  One of the
>valid concerns for NAT64 - much like NAT44 - is being able to determine
>the identity of a given user through the NAT at a given point in time.

Bulk port allocation. Your NAT logs then approximate your DHCP (or
whatever) logs in size and scope.

Unless you mean to use it to front a web service.  Then just use
x-forwarded-for, and make sure your logs and log parsers can handle it.
Might want to write a correlation script.


>How feasible this is depends on how robust/scalable $XYZ's translation
>logging capabilities are, and possibly how easily that data can be
>matched 
>against a source of identify information, such as RADIUS accounting logs,
>DHCP lease logs, etc.

Ask the vendors; it took them a while, but they all have techniques for
reducing logs.

>
>Other IPv6 transition mechanisms appear to be no less thorny than NAT64
>for a variety of reasons.

Yes; see rfc7021.

Once you've deployed it, an experience report at a NANOG meeting would be
welcome.

Lee




From asullivan at dyn.com  Tue Nov 19 16:36:50 2013
From: asullivan at dyn.com (Andrew Sullivan)
Date: Tue, 19 Nov 2013 11:36:50 -0500
Subject: NAT64 and matching identities
In-Reply-To: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
References: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
Message-ID: <20131119163649.GC5265@dyn.com>

On Mon, Nov 18, 2013 at 03:06:52PM -0500, Justin M. Streiner wrote:
> Other IPv6 transition mechanisms appear to be no less thorny than
> NAT64 for a variety of reasons.

Some of us who worked on the NAT64/DNS64 combination were content that
it was a long way from the perfect solution.  The idea I at least had
was to get something that mostly worked most of the time, and was
simple enough that anyone could basically understand it.
Nevertheless, I have to admit that it's a pig.

That piggishness was not something I wanted to get rid of.  I thought
(and still think) that if the transition mechanisms are awful enough,
it will encourage moving things to v6 for real so that we can get rid
of the kludges.  Perhaps this is wishful thinking, however.  

In any case, I'm sorry to have contributed in some little way to this
headache of yours.

Best,

A

-- 
Andrew Sullivan
Dyn, Inc.
asullivan at dyn.com
v: +1 603 663 0448


From don at sandvine.com  Tue Nov 19 16:48:29 2013
From: don at sandvine.com (Don Bowman)
Date: Tue, 19 Nov 2013 16:48:29 +0000
Subject: NAT64 and matching identities
In-Reply-To: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
References: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
Message-ID: <C7579F0BB38EC444912308442F7E195A19113EBF@wtl-exchp-2.sandvine.com>

From: Justin M. Streiner [mailto:streiner at cluebyfour.org] 

>It's looking more and more like NAT64 will be in our future.  
>One of the valid concerns for NAT64 - much like NAT44 - is being
>able to determine the identity of a given user through the NAT 
>at a given point in time.
>How feasible this is depends on how robust/scalable $XYZ's 
>translation logging capabilities are, and possibly how easily that 
>data can be matched against a source of identify information, 
>such as RADIUS accounting logs, DHCP lease logs, etc.

 ... snip ...

We implemented a product around this. What we found in doing
so was that a) you need to use port-block allocation to make it feasible
(cannot do unbounded NATP where every flow gets its own port),
That AAA works well when the NAT is a gateway device, and that
Otherwise DHCP works ok, and syslog is the fallback. All devices
Supported one of those three.

We also found there was a need for IPV6 identification (e.g. some
customers used DNS reverse lookup in ipv4 to find the ID of a user
for e.g. single-sign-on type solutions, and this no longer worked
in a NAT44/NAT64/IPv6 environment.

We found there was a need for both real-time (e.g. query 
who is this right now, e.g. sign-on), and after the fact (who
had this @ this time).

The general purpose coordinates we called 'session qualifiers', and
we found that sometimes it included VLAN or MPLS or other
tunnels.

Let me know if u want more info and I can follow up offline.



From gourmetcisco at hotmail.com  Tue Nov 19 17:25:50 2013
From: gourmetcisco at hotmail.com (Hank Disuko)
Date: Tue, 19 Nov 2013 12:25:50 -0500
Subject: Meraki
Message-ID: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>

Hi folks, 
 
I've traditionally been a Cisco Catalyst shop for my switching gear.
 
I am doing a significant hardware refresh in one of my offices, which will entail replacing about 20 access switches and a couple core devices.  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I have 1G fibre/copper and 10G fibre.  My core switch of choice will likely be the Cat 4500 series.
 
I'm considering Cisco's Meraki platform for my access layer and I'm looking for deployment stories of folks that have deployed Meraki in the past...good/bad/ugly kinda stuff.
 
I know Meraki hardcores were upset when Cisco acquired them, but not exactly sure why.
 
Anyway, any thoughts would be useful.  Thanks!
 
-Hank
 		 	   		  

From j at 2600hz.com  Tue Nov 19 17:30:24 2013
From: j at 2600hz.com (Joshua Goldbard)
Date: Tue, 19 Nov 2013 17:30:24 +0000
Subject: Meraki
In-Reply-To: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
Message-ID: <01DEC1DA-4CFB-4852-9194-1A2AC378B526@2600hz.com>

I've used them on a bunch of field deployments. Love'em. When clients have them it makes documenting any part of the experience a technician level task.

Need a pcap? Built into the GUI. Want the switch to SMS you when ports get knocked out? Built into the GUI. Do you like visuals that actually make some goddamn sense? Meraki has it.

I never had to go into the command line for any reason, at least not so far.

I can say they had some issues detecting the ubiquiti access points at a client site but I think that had more to do with faulty internal wiring than anything else.

Anyways, I like'em.

Cheers,
Joshua

Sent from my iPhone

On Nov 19, 2013, at 9:26 AM, "Hank Disuko" <gourmetcisco at hotmail.com> wrote:

> Hi folks, 
> 
> I've traditionally been a Cisco Catalyst shop for my switching gear.
> 
> I am doing a significant hardware refresh in one of my offices, which will entail replacing about 20 access switches and a couple core devices.  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I have 1G fibre/copper and 10G fibre.  My core switch of choice will likely be the Cat 4500 series.
> 
> I'm considering Cisco's Meraki platform for my access layer and I'm looking for deployment stories of folks that have deployed Meraki in the past...good/bad/ugly kinda stuff.
> 
> I know Meraki hardcores were upset when Cisco acquired them, but not exactly sure why.
> 
> Anyway, any thoughts would be useful.  Thanks!
> 
> -Hank
>                         


From brandon.galbraith at gmail.com  Tue Nov 19 17:56:56 2013
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Tue, 19 Nov 2013 11:56:56 -0600
Subject: Meraki
In-Reply-To: <01DEC1DA-4CFB-4852-9194-1A2AC378B526@2600hz.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <01DEC1DA-4CFB-4852-9194-1A2AC378B526@2600hz.com>
Message-ID: <CADE4tYXpfeCLcJ6157jhC-oC3u9GLoTmtxiwgAOOmXz=TQrQKg@mail.gmail.com>

+1 for Joshua's comments. Used them in a small rollout (~20k sqft of
office space across two buildings), was extremely pleased.
Authentication can tie into OAuth (Google Apps) or LDAP/AD. Email or
SMS alerts for *everything*.

Would highly recommend them.

Brandon

On Tue, Nov 19, 2013 at 11:30 AM, Joshua Goldbard <j at 2600hz.com> wrote:
> I've used them on a bunch of field deployments. Love'em. When clients have them it makes documenting any part of the experience a technician level task.
>
> Need a pcap? Built into the GUI. Want the switch to SMS you when ports get knocked out? Built into the GUI. Do you like visuals that actually make some goddamn sense? Meraki has it.
>
> I never had to go into the command line for any reason, at least not so far.
>
> I can say they had some issues detecting the ubiquiti access points at a client site but I think that had more to do with faulty internal wiring than anything else.
>
> Anyways, I like'em.
>
> Cheers,
> Joshua
>
> Sent from my iPhone
>
> On Nov 19, 2013, at 9:26 AM, "Hank Disuko" <gourmetcisco at hotmail.com> wrote:
>
>> Hi folks,
>>
>> I've traditionally been a Cisco Catalyst shop for my switching gear.
>>
>> I am doing a significant hardware refresh in one of my offices, which will entail replacing about 20 access switches and a couple core devices.  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I have 1G fibre/copper and 10G fibre.  My core switch of choice will likely be the Cat 4500 series.
>>
>> I'm considering Cisco's Meraki platform for my access layer and I'm looking for deployment stories of folks that have deployed Meraki in the past...good/bad/ugly kinda stuff.
>>
>> I know Meraki hardcores were upset when Cisco acquired them, but not exactly sure why.
>>
>> Anyway, any thoughts would be useful.  Thanks!
>>
>> -Hank
>>
>


From koalafil at gmail.com  Tue Nov 19 18:04:34 2013
From: koalafil at gmail.com (Filiz Yilmaz)
Date: Tue, 19 Nov 2013 15:04:34 -0300
Subject: Call for Presentations RIPE 68
Message-ID: <266D14B7-7D9B-433E-9805-D53CCE92D756@gmail.com>


Dear colleagues,

Please find the CFP for RIPE 68 below or at https://ripe68.ripe.net/submit-topic/cfp/.

The deadline for submissions is 2 March 2014.
Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings.

Kind regards

Filiz Yilmaz
RIPE PC Chair
http://www.ripe.net/ripe/meetings/ripe-meetings/pc


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

Call for Presentations

A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field.

RIPE 68 will take place from 12 ? 16 May 2014 in Warsaw, Poland.

The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 68. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to:

	? IPv6 deployment
	? Managing IPv4 scarcity in operations
	? Commercial transactions of IPv4 addresses
	? Data centre technologies
	? Network and DNS operations
	? Internet governance and regulatory practices
	? Network and routing security
	? Content delivery
	? Internet peering and mobile data exchange

Submissions

RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on  the underlying technology and not attempt a product demonstration.

The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at 
https://ripe68.ripe.net/submit-topic/presentation-formats/

Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator.

In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for ?lightning talks?, which are selected immediately before or during the conference.

The following general requirements apply:

- Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 2 March 2014, using the meeting submission system at https://ripe68.ripe.net/submit-topic/guidelines/. Proposals submitted after this date will be considered on a space-available basis.

-  Lightning talks should also be submitted using the meeting submission system (https://ripe68.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice ? in some cases on the same day but often one day prior to the relevant session.

- Presenters should indicate how much time they will require. 
See more information on time slot allocations per presentation format at https://ripe68.ripe.net/submit-topic/presentation-formats/

- Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators.

- Due to potential technical issues, it is expected that most, if not all, presenters/panelists will be physically present at the RIPE Meeting.

If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net.

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



From seth.mos at dds.nl  Tue Nov 19 18:57:47 2013
From: seth.mos at dds.nl (Seth Mos)
Date: Tue, 19 Nov 2013 19:57:47 +0100
Subject: Meraki
In-Reply-To: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
Message-ID: <D6F32509-7BF9-4A3E-A8FB-B2E862AA7A32@dds.nl>


Op 19 nov 2013, om 18:25 heeft Hank Disuko het volgende geschreven:

> Hi folks, 
> 
> I've traditionally been a Cisco Catalyst shop for my switching gear.
> 
> I am doing a significant hardware refresh in one of my offices, which will entail replacing about 20 access switches and a couple core devices.  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I have 1G fibre/copper and 10G fibre.  My core switch of choice will likely be the Cat 4500 series.
> 
> I'm considering Cisco's Meraki platform for my access layer and I'm looking for deployment stories of folks that have deployed Meraki in the past...good/bad/ugly kinda stuff.
> 
> I know Meraki hardcores were upset when Cisco acquired them, but not exactly sure why.
> 
> Anyway, any thoughts would be useful.  Thanks!

We used to use the 3Com wireless kit before it became H3C, and then HP, which worked ok but the engrish in the UI was horrid.

We've since purchased 25 Ubiquity wireless access points, specifically the 300N Pro access points, they work really well, pricing is competitive priced and the management is nice.

I've setup a Debian VM, installed their management software from their APT repo and just go from there. The version 3 software also supports multi-site which is really nice.

It's a huge upgrade over our previous wireless though.

Cheers,
Seth

From dhubbard at dino.hostasaurus.com  Tue Nov 19 20:04:59 2013
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Tue, 19 Nov 2013 15:04:59 -0500
Subject: Opinions on Fortinet?
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17305A15E56@dino.ad.hostasaurus.com>

Anyone used Fortinet hardware, ideally in both a dual stack and
clustered/HA setup, want to share their opinions/experiences with me off
list?  Looking at some of their stuff.

Thanks,

David


From Sean.Pedersen at usairways.com  Tue Nov 19 20:58:27 2013
From: Sean.Pedersen at usairways.com (Pedersen, Sean)
Date: Tue, 19 Nov 2013 13:58:27 -0700
Subject: Meraki
In-Reply-To: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
Message-ID: <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>

I started to look into them for personal and limited small business use, but stopped short when I realized their cloud management platform is subscription-based. Unless I've missed something, you cannot deploy your own internal management platform. It's all licensed through Meraki/Cisco, which means if you lose your Internet connection, you lose management access to your gear. That could be a deal-killer in certain environments. Maybe someone with more experience on the platform could correct me there.

-----Original Message-----
From: Hank Disuko [mailto:gourmetcisco at hotmail.com] 
Sent: Tuesday, November 19, 2013 10:26 AM
To: NANOG
Subject: Meraki

Hi folks, 
 
I've traditionally been a Cisco Catalyst shop for my switching gear.
 
I am doing a significant hardware refresh in one of my offices, which will entail replacing about 20 access switches and a couple core devices.  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I have 1G fibre/copper and 10G fibre.  My core switch of choice will likely be the Cat 4500 series.
 
I'm considering Cisco's Meraki platform for my access layer and I'm looking for deployment stories of folks that have deployed Meraki in the past...good/bad/ugly kinda stuff.
 
I know Meraki hardcores were upset when Cisco acquired them, but not exactly sure why.
 
Anyway, any thoughts would be useful.  Thanks!
 
-Hank
 		 	   		  


From wbailey at satelliteintelligencegroup.com  Tue Nov 19 21:34:47 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 19 Nov 2013 21:34:47 +0000
Subject: Meraki
In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>,
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
Message-ID: <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>

They give you a free ap for listening to their pitch.. We love them. Expensive.. But responsive and responsible.. Which is pretty hard to find in Wi-Fi land. Pretty interface and lots of little bells and whistles.. They have my vote from what we evaluated (ubnt, Blahblahblah).


Sent from my Mobile Device.


-------- Original message --------
From: "Pedersen, Sean" <Sean.Pedersen at usairways.com>
Date: 11/19/2013 12:00 PM (GMT-09:00)
To: NANOG <nanog at nanog.org>
Subject: RE: Meraki


I started to look into them for personal and limited small business use, but stopped short when I realized their cloud management platform is subscription-based. Unless I've missed something, you cannot deploy your own internal management platform. It's all licensed through Meraki/Cisco, which means if you lose your Internet connection, you lose management access to your gear. That could be a deal-killer in certain environments. Maybe someone with more experience on the platform could correct me there.

-----Original Message-----
From: Hank Disuko [mailto:gourmetcisco at hotmail.com]
Sent: Tuesday, November 19, 2013 10:26 AM
To: NANOG
Subject: Meraki

Hi folks,

I've traditionally been a Cisco Catalyst shop for my switching gear.

I am doing a significant hardware refresh in one of my offices, which will entail replacing about 20 access switches and a couple core devices.  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I have 1G fibre/copper and 10G fibre.  My core switch of choice will likely be the Cat 4500 series.

I'm considering Cisco's Meraki platform for my access layer and I'm looking for deployment stories of folks that have deployed Meraki in the past...good/bad/ugly kinda stuff.

I know Meraki hardcores were upset when Cisco acquired them, but not exactly sure why.

Anyway, any thoughts would be useful.  Thanks!

-Hank



From morrowc.lists at gmail.com  Tue Nov 19 21:36:42 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 19 Nov 2013 16:36:42 -0500
Subject: Meraki
In-Reply-To: <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
Message-ID: <CAL9jLaa3QxDB1X5ornoHqwrzGMP8LL++zy=u7kgYpHSokyYvKw@mail.gmail.com>

On Tue, Nov 19, 2013 at 4:34 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> They give you a free ap for listening to their pitch.. We love them. Expensive.. But

so you just decide: "How many may we have to deploy?"
then schedule that many pitch meetings with them? :)


From shawnl at up.net  Tue Nov 19 21:37:54 2013
From: shawnl at up.net (Shawn L)
Date: Tue, 19 Nov 2013 16:37:54 -0500
Subject: Meraki
In-Reply-To: <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
Message-ID: <CACTmXQVSp5Rmj-t9seO_2gSBw8QuYh64co=eWWaFSw3sx1pHvw@mail.gmail.com>

If you have one of their routers, etc. you cannot lock yourself out of the
device.  You can always web to the 'inside' interface and make basic
configuration changes.  It's not going to let you do policy stuff, etc. but
will let you do enough to establish / re-establish network connectivity.


On Tue, Nov 19, 2013 at 4:34 PM, Warren Bailey <
wbailey at satelliteintelligencegroup.com> wrote:

> They give you a free ap for listening to their pitch.. We love them.
> Expensive.. But responsive and responsible.. Which is pretty hard to find
> in Wi-Fi land. Pretty interface and lots of little bells and whistles..
> They have my vote from what we evaluated (ubnt, Blahblahblah).
>
>
> Sent from my Mobile Device.
>
>
> -------- Original message --------
> From: "Pedersen, Sean" <Sean.Pedersen at usairways.com>
> Date: 11/19/2013 12:00 PM (GMT-09:00)
> To: NANOG <nanog at nanog.org>
> Subject: RE: Meraki
>
>
> I started to look into them for personal and limited small business use,
> but stopped short when I realized their cloud management platform is
> subscription-based. Unless I've missed something, you cannot deploy your
> own internal management platform. It's all licensed through Meraki/Cisco,
> which means if you lose your Internet connection, you lose management
> access to your gear. That could be a deal-killer in certain environments.
> Maybe someone with more experience on the platform could correct me there.
>
> -----Original Message-----
> From: Hank Disuko [mailto:gourmetcisco at hotmail.com]
> Sent: Tuesday, November 19, 2013 10:26 AM
> To: NANOG
> Subject: Meraki
>
> Hi folks,
>
> I've traditionally been a Cisco Catalyst shop for my switching gear.
>
> I am doing a significant hardware refresh in one of my offices, which will
> entail replacing about 20 access switches and a couple core devices.
>  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I
> have 1G fibre/copper and 10G fibre.  My core switch of choice will likely
> be the Cat 4500 series.
>
> I'm considering Cisco's Meraki platform for my access layer and I'm
> looking for deployment stories of folks that have deployed Meraki in the
> past...good/bad/ugly kinda stuff.
>
> I know Meraki hardcores were upset when Cisco acquired them, but not
> exactly sure why.
>
> Anyway, any thoughts would be useful.  Thanks!
>
> -Hank
>
>
>

From techravingmad at gmail.com  Tue Nov 19 22:12:24 2013
From: techravingmad at gmail.com (Glenn Robuck)
Date: Tue, 19 Nov 2013 16:12:24 -0600
Subject: Meraki
In-Reply-To: <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
Message-ID: <CADi_t2y_uDYJHqaca2TVnScoKYazj_zC7A8rANXRr7+o0z9UkQ@mail.gmail.com>

I'm curious if any of you guys have compared Meraki and Xirrus?  We are
currently in the process of picking new WAPs and have narrowed it down to
these too.  We are leaning towards Xirrus due to it's modular structure.
 It also has a great user interface.

Anyone else evaluate Xirrus?


On Tue, Nov 19, 2013 at 3:34 PM, Warren Bailey <
wbailey at satelliteintelligencegroup.com> wrote:

> They give you a free ap for listening to their pitch.. We love them.
> Expensive.. But responsive and responsible.. Which is pretty hard to find
> in Wi-Fi land. Pretty interface and lots of little bells and whistles..
> They have my vote from what we evaluated (ubnt, Blahblahblah).
>
>
> Sent from my Mobile Device.
>
>
> -------- Original message --------
> From: "Pedersen, Sean" <Sean.Pedersen at usairways.com>
> Date: 11/19/2013 12:00 PM (GMT-09:00)
> To: NANOG <nanog at nanog.org>
> Subject: RE: Meraki
>
>
> I started to look into them for personal and limited small business use,
> but stopped short when I realized their cloud management platform is
> subscription-based. Unless I've missed something, you cannot deploy your
> own internal management platform. It's all licensed through Meraki/Cisco,
> which means if you lose your Internet connection, you lose management
> access to your gear. That could be a deal-killer in certain environments.
> Maybe someone with more experience on the platform could correct me there.
>
> -----Original Message-----
> From: Hank Disuko [mailto:gourmetcisco at hotmail.com]
> Sent: Tuesday, November 19, 2013 10:26 AM
> To: NANOG
> Subject: Meraki
>
> Hi folks,
>
> I've traditionally been a Cisco Catalyst shop for my switching gear.
>
> I am doing a significant hardware refresh in one of my offices, which will
> entail replacing about 20 access switches and a couple core devices.
>  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I
> have 1G fibre/copper and 10G fibre.  My core switch of choice will likely
> be the Cat 4500 series.
>
> I'm considering Cisco's Meraki platform for my access layer and I'm
> looking for deployment stories of folks that have deployed Meraki in the
> past...good/bad/ugly kinda stuff.
>
> I know Meraki hardcores were upset when Cisco acquired them, but not
> exactly sure why.
>
> Anyway, any thoughts would be useful.  Thanks!
>
> -Hank
>
>
>

From mike.lyon at gmail.com  Tue Nov 19 22:16:13 2013
From: mike.lyon at gmail.com (Mike Lyon)
Date: Tue, 19 Nov 2013 14:16:13 -0800
Subject: Meraki
In-Reply-To: <CADi_t2y_uDYJHqaca2TVnScoKYazj_zC7A8rANXRr7+o0z9UkQ@mail.gmail.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
 <CADi_t2y_uDYJHqaca2TVnScoKYazj_zC7A8rANXRr7+o0z9UkQ@mail.gmail.com>
Message-ID: <1681163061847040023@unknownmsgid>

Did you check out ubiquiti's UniFi?

-Mike



> On Nov 19, 2013, at 14:13, Glenn Robuck <techravingmad at gmail.com> wrote:
>
> I'm curious if any of you guys have compared Meraki and Xirrus?  We are
> currently in the process of picking new WAPs and have narrowed it down to
> these too.  We are leaning towards Xirrus due to it's modular structure.
> It also has a great user interface.
>
> Anyone else evaluate Xirrus?
>
>
> On Tue, Nov 19, 2013 at 3:34 PM, Warren Bailey <
> wbailey at satelliteintelligencegroup.com> wrote:
>
>> They give you a free ap for listening to their pitch.. We love them.
>> Expensive.. But responsive and responsible.. Which is pretty hard to find
>> in Wi-Fi land. Pretty interface and lots of little bells and whistles..
>> They have my vote from what we evaluated (ubnt, Blahblahblah).
>>
>>
>> Sent from my Mobile Device.
>>
>>
>> -------- Original message --------
>> From: "Pedersen, Sean" <Sean.Pedersen at usairways.com>
>> Date: 11/19/2013 12:00 PM (GMT-09:00)
>> To: NANOG <nanog at nanog.org>
>> Subject: RE: Meraki
>>
>>
>> I started to look into them for personal and limited small business use,
>> but stopped short when I realized their cloud management platform is
>> subscription-based. Unless I've missed something, you cannot deploy your
>> own internal management platform. It's all licensed through Meraki/Cisco,
>> which means if you lose your Internet connection, you lose management
>> access to your gear. That could be a deal-killer in certain environments.
>> Maybe someone with more experience on the platform could correct me there.
>>
>> -----Original Message-----
>> From: Hank Disuko [mailto:gourmetcisco at hotmail.com]
>> Sent: Tuesday, November 19, 2013 10:26 AM
>> To: NANOG
>> Subject: Meraki
>>
>> Hi folks,
>>
>> I've traditionally been a Cisco Catalyst shop for my switching gear.
>>
>> I am doing a significant hardware refresh in one of my offices, which will
>> entail replacing about 20 access switches and a couple core devices.
>> Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I
>> have 1G fibre/copper and 10G fibre.  My core switch of choice will likely
>> be the Cat 4500 series.
>>
>> I'm considering Cisco's Meraki platform for my access layer and I'm
>> looking for deployment stories of folks that have deployed Meraki in the
>> past...good/bad/ugly kinda stuff.
>>
>> I know Meraki hardcores were upset when Cisco acquired them, but not
>> exactly sure why.
>>
>> Anyway, any thoughts would be useful.  Thanks!
>>
>> -Hank
>>
>>
>>


From wbailey at satelliteintelligencegroup.com  Tue Nov 19 22:26:21 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 19 Nov 2013 22:26:21 +0000
Subject: Meraki
In-Reply-To: <1681163061847040023@unknownmsgid>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
 <CADi_t2y_uDYJHqaca2TVnScoKYazj_zC7A8rANXRr7+o0z9UkQ@mail.gmail.com>,
 <1681163061847040023@unknownmsgid>
Message-ID: <gpwgkv959beobcrgcphp717t.1384899975774@email.android.com>

Check out their forums first.. Look for my name.. ;)

Ubnt has a cool price point.


Sent from my Mobile Device.


-------- Original message --------
From: Mike Lyon <mike.lyon at gmail.com>
Date: 11/19/2013 1:18 PM (GMT-09:00)
To: Glenn Robuck <techravingmad at gmail.com>
Cc: NANOG <nanog at nanog.org>
Subject: Re: Meraki


Did you check out ubiquiti's UniFi?

-Mike



> On Nov 19, 2013, at 14:13, Glenn Robuck <techravingmad at gmail.com> wrote:
>
> I'm curious if any of you guys have compared Meraki and Xirrus?  We are
> currently in the process of picking new WAPs and have narrowed it down to
> these too.  We are leaning towards Xirrus due to it's modular structure.
> It also has a great user interface.
>
> Anyone else evaluate Xirrus?
>
>
> On Tue, Nov 19, 2013 at 3:34 PM, Warren Bailey <
> wbailey at satelliteintelligencegroup.com> wrote:
>
>> They give you a free ap for listening to their pitch.. We love them.
>> Expensive.. But responsive and responsible.. Which is pretty hard to find
>> in Wi-Fi land. Pretty interface and lots of little bells and whistles..
>> They have my vote from what we evaluated (ubnt, Blahblahblah).
>>
>>
>> Sent from my Mobile Device.
>>
>>
>> -------- Original message --------
>> From: "Pedersen, Sean" <Sean.Pedersen at usairways.com>
>> Date: 11/19/2013 12:00 PM (GMT-09:00)
>> To: NANOG <nanog at nanog.org>
>> Subject: RE: Meraki
>>
>>
>> I started to look into them for personal and limited small business use,
>> but stopped short when I realized their cloud management platform is
>> subscription-based. Unless I've missed something, you cannot deploy your
>> own internal management platform. It's all licensed through Meraki/Cisco,
>> which means if you lose your Internet connection, you lose management
>> access to your gear. That could be a deal-killer in certain environments.
>> Maybe someone with more experience on the platform could correct me there.
>>
>> -----Original Message-----
>> From: Hank Disuko [mailto:gourmetcisco at hotmail.com]
>> Sent: Tuesday, November 19, 2013 10:26 AM
>> To: NANOG
>> Subject: Meraki
>>
>> Hi folks,
>>
>> I've traditionally been a Cisco Catalyst shop for my switching gear.
>>
>> I am doing a significant hardware refresh in one of my offices, which will
>> entail replacing about 20 access switches and a couple core devices.
>> Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I
>> have 1G fibre/copper and 10G fibre.  My core switch of choice will likely
>> be the Cat 4500 series.
>>
>> I'm considering Cisco's Meraki platform for my access layer and I'm
>> looking for deployment stories of folks that have deployed Meraki in the
>> past...good/bad/ugly kinda stuff.
>>
>> I know Meraki hardcores were upset when Cisco acquired them, but not
>> exactly sure why.
>>
>> Anyway, any thoughts would be useful.  Thanks!
>>
>> -Hank
>>
>>
>>


From wbailey at satelliteintelligencegroup.com  Tue Nov 19 22:26:47 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 19 Nov 2013 22:26:47 +0000
Subject: Meraki
In-Reply-To: <CAL9jLaa3QxDB1X5ornoHqwrzGMP8LL++zy=u7kgYpHSokyYvKw@mail.gmail.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>,
 <CAL9jLaa3QxDB1X5ornoHqwrzGMP8LL++zy=u7kgYpHSokyYvKw@mail.gmail.com>
Message-ID: <51eusm0x0a0i5syfmo3li0t5.1384900002557@email.android.com>

Haha! Don't give up the secrets!!


Sent from my Mobile Device.


-------- Original message --------
From: Christopher Morrow <morrowc.lists at gmail.com>
Date: 11/19/2013 12:36 PM (GMT-09:00)
To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
Cc: "Pedersen, Sean" <Sean.Pedersen at usairways.com>,NANOG <nanog at nanog.org>
Subject: Re: Meraki


On Tue, Nov 19, 2013 at 4:34 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> They give you a free ap for listening to their pitch.. We love them. Expensive.. But

so you just decide: "How many may we have to deploy?"
then schedule that many pitch meetings with them? :)

From fred at cisco.com  Tue Nov 19 22:56:32 2013
From: fred at cisco.com (Fred Baker (fred))
Date: Tue, 19 Nov 2013 22:56:32 +0000
Subject: NAT64 and matching identities
In-Reply-To: <20131119163649.GC5265@dyn.com>
References: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
 <20131119163649.GC5265@dyn.com>
Message-ID: <A297F42E-9487-465C-9B16-79C44DDC4C54@cisco.com>


On Nov 19, 2013, at 8:36 AM, Andrew Sullivan <asullivan at dyn.com> wrote:

> On Mon, Nov 18, 2013 at 03:06:52PM -0500, Justin M. Streiner wrote:
>> Other IPv6 transition mechanisms appear to be no less thorny than
>> NAT64 for a variety of reasons.
> 
> Some of us who worked on the NAT64/DNS64 combination were content that
> it was a long way from the perfect solution.  The idea I at least had
> was to get something that mostly worked most of the time, and was
> simple enough that anyone could basically understand it.
> Nevertheless, I have to admit that it's a pig.
> 
> That piggishness was not something I wanted to get rid of.  I thought
> (and still think) that if the transition mechanisms are awful enough,
> it will encourage moving things to v6 for real so that we can get rid
> of the kludges.  Perhaps this is wishful thinking, however.  
> 
> In any case, I'm sorry to have contributed in some little way to this
> headache of yours.

Speaking as one of the co-authors of RFC 6052, 6144, and 6145...

I'm actually not sorry. The predecessor to RFCs 6052/6144/6145/6146/6147 was NAT-PT, which didn't work very well in part due to a nasty coupling (see RFC 4966). It's pretty straightforward to insert an IPv4 address into a specified IPv6 prefix (RFC 6052), and use that to statelessly translate between a IPv4 address and an RFC 6052 address (RFC 6145), or to statefully translate a random IPv6 address into an IPv4 space much in the way IPv4/IPv4 translation works (RFC 6146). What is hard is statefully translating from IPv4 to a generic IPv6 address - its hard to compress 128 bits of information into 32 bits. NAT-PT does it by having the DNS lookup temporarily assign an IPv4 address to the IPv6 device and inform the translator of the translation. http://tools.ietf.org/html/draft-anderson-siit-dc (which Tore didn't, to my knowledge, try to get turned into an RFC, although I'd be willing to discuss that with v6ops) does it by pre-assigning address pairs, enabling an IPv6-only domain to be accessed from an IPv4-only domain by a defined translation between the two for a small set of servers.

I'm all for helping people to transition. Where I get a little crazy is when the so-called transition tool makes them comfortable enough that they think they don't need to. What I expect to see in the IETF over the coming few years - and which I see in detail coming from several <nationality> competitors and their <nationality> network customers now - is a series of ideas of the form "but people with ancient IPv4-only hosts are having trouble with the IPv6 network; let's do this *temporary* patch to ease their pain". I submit that the best way to ease their pain is to upgrade their hosts. They will have to deal with it at some point.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131119/b70700d3/attachment.bin>

From bortzmeyer at nic.fr  Tue Nov 19 23:35:33 2013
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed, 20 Nov 2013 00:35:33 +0100
Subject: [renesys] The New Threat: Targeted Internet Traffic Misdirection
Message-ID: <20131119233533.GA31522@sources.org>

Interesting study of what seems to be real BGP shunts:

http://www.renesys.com/2013/11/mitm-internet-hijacking/


From I.Smith at F5.com  Tue Nov 19 23:53:30 2013
From: I.Smith at F5.com (Ian Smith)
Date: Tue, 19 Nov 2013 23:53:30 +0000
Subject: NAT64 and matching identities
In-Reply-To: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
References: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
Message-ID: <419417C345CA5F48BF45F0A23955A0634A72597E@SEAEMBX02.olympus.F5Net.com>

It depends on what direction your are translating to:

IPv6-only host to IPv4 Internet:  This isn't a problem if you are dual-stack at the host, but if you really do have ip6 only hosts, you aren't looking at any requirement that is different than LSN44 or providing a IPv6 tunnel broker service (like he.net).  Since NAT64 is necessarily predicated by a DNS64 operation and you know who you gave an IP address to because they logged in (in some fashion) so you could bill them, you can log {subID,src_ip6,xlat_ip4:port,dst_ip4:port,fqdn} using syslog or ipfix (in as little as one message, depending on the AAA and IPAM architecture) and invest in log servers.    Port block allocation and deterministic schemes are possible here as well, but really, the only way to know you aren't going to be surprised by a lost or inaccurate data set under subpoena is to just log everything and write it off as a statutory expense. 

There is obviously a long tail of ip4 destinations, but nearly all of 500 of the Alexa global 500 have ip6 listeners, so the majority of your connections from ip6 only hosts should be leaving your network without NAT and if they aren't, you should figure out why as part of reassessing the problem.


IPv6 Internet to IPv4-only host:  Just do LB64 with an IP proxy.  Most commercial SLB/ADC vendors do this today and offer varying degrees of ALG to fix-up protocols that have multiple channels.  Your server doesn't need to know that there is a IPv6 portion of the connection unless they are doing something absurd like trying to initiate connections to IPv6 only hosts, and the ADC will help you deal with it as well.  Conveying the xlat information is protocol specific - HTTP and SIP are super easy, since that same ADC will do header inserts with the original client ip, others might not be, but by not having dual-stack applications, you are committing yourself to the tedium of protocol by protocol fix-ups.  You can help out that particular headache by using name lookups instead of address lookups (getaddrinfo instead of gethostbyaddr on POSIX systems)


________________________________________
From: Justin M. Streiner [streiner at cluebyfour.org]
Sent: Monday, November 18, 2013 3:06 PM
To: nanog at nanog.org
Subject: NAT64 and matching identities

It's looking more and more like NAT64 will be in our future.  One of the
valid concerns for NAT64 - much like NAT44 - is being able to determine
the identity of a given user through the NAT at a given point in time.
How feasible this is depends on how robust/scalable $XYZ's translation
logging capabilities are, and possibly how easily that data can be matched
against a source of identify information, such as RADIUS accounting logs,
DHCP lease logs, etc.

Other IPv6 transition mechanisms appear to be no less thorny than NAT64
for a variety of reasons.

I'm curious to see how others are planning to tackle (or already have
tacked) this issue.  Discussing vendor-specific solutions is fine, but I
think keeping things as platform/vendor agnostic as possible for the time
being would allow this thread to be more beneficial to a wider audience.

The floor is open...

jms



From streiner at cluebyfour.org  Tue Nov 19 23:23:21 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 19 Nov 2013 18:23:21 -0500 (EST)
Subject: NAT64 and matching identities
In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A72597E@SEAEMBX02.olympus.F5Net.com>
References: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
 <419417C345CA5F48BF45F0A23955A0634A72597E@SEAEMBX02.olympus.F5Net.com>
Message-ID: <Pine.LNX.4.64.1311191559220.3593@whammy.cluebyfour.org>

On Tue, 19 Nov 2013, Ian Smith wrote:

> It depends on what direction your are translating to:
>
> IPv6-only host to IPv4 Internet:  This isn't a problem if you are 
> dual-stack at the host, but if you really do have ip6 only hosts, you 
> aren't looking at any requirement that is different than LSN44 or 
> providing a IPv6 tunnel broker service (like he.net).  Since NAT64 is 
> necessarily predicated by a DNS64 operation and you know who you gave an 
> IP address to because they logged in (in some fashion) so you could bill 
> them, you can log {subID,src_ip6,xlat_ip4:port,dst_ip4:port,fqdn} using 
> syslog or ipfix (in as little as one message, depending on the AAA and 
> IPAM architecture) and invest in log servers.    Port block allocation 
> and deterministic schemes are possible here as well, but really, the 
> only way to know you aren't going to be surprised by a lost or inaccurate 
> data set under subpoena is to just log everything and write it off as a 
> statutory expense.

Much of our initial deployment will be dual-stack, however I also want to 
plan for situations where we won't have enough v4 addresses to dual-stack 
(or we reach a point where we need to hold some of our routable v4 space 
in reserve for transition mechanisms), plus dual-stack on its own provides 
no incentive for users to migrate completely to v6.

That said, I need to plan for the eventuality of v6-only hosts being able 
to reach the v4 Internet.  While many of the Alexa global 500 sites have 
some sort of v6 capability today and the percentage of global Internet 
traffic that is v6 is increasing every day, the need for reachability to 
what remains of the v4 Internet will not go away any time soon.

jms


From dylan.ebner at crlmed.com  Wed Nov 20 15:26:49 2013
From: dylan.ebner at crlmed.com (Dylan Ebner)
Date: Wed, 20 Nov 2013 15:26:49 +0000
Subject: Looking for a Charter Backbone Engineer
Message-ID: <26CDB41135AFE3459A8BBEF6C64657CF057A24@S1P5DAG5D.EXCHPROD.USA.NET>

If there is a Charter backbone engineer on the list could you email me off list. I am having a peculiar issue with a charter connection and support can't seem to figure it out.

Thanks

Dylan Ebner, Network Engineer
Consulting Radiologists, Ltd.
1221 Nicollet Mall, Minneapolis, MN 55403
ph. 612.573.2236     fax. 612.573.2250
dylan.ebner at crlmed.com<mailto:dylan.ebner at crlmed.com>
www.consultingradiologists.com<http://www.consultingradiologists.com/>


From dustin at rseng.net  Wed Nov 20 15:51:04 2013
From: dustin at rseng.net (Dustin Jurman)
Date: Wed, 20 Nov 2013 10:51:04 -0500
Subject: Meraki
In-Reply-To: <CADi_t2y_uDYJHqaca2TVnScoKYazj_zC7A8rANXRr7+o0z9UkQ@mail.gmail.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
 <CADi_t2y_uDYJHqaca2TVnScoKYazj_zC7A8rANXRr7+o0z9UkQ@mail.gmail.com>
Message-ID: <6B01C29BEA65E347A560D0306A33D63B04F5CE1D86E5@RSSBS08.rseng.net>

Just finished a project doing an entire convention center with Xirrus.  Awesome results and many more options than Meraki.  I would say that it was one of those signature projects that had to happen in a very short schedule and we had to provide support for the event.  Onsite engineers stated that it was the most boring support event they ever went too.  In the four days that we provided turn-up support there wasn't a single issue and only alcolades from the event center and attendees.  

We have previously deployed Meraki in large environments as well the Xirrus.  The Xirrus product is superior in so many ways.  I am not a big fan of cloud based network management,  I think as network providers in rapidly changing environments there are times when equipment is decommissioned and put on a shelf for a rainy day or emergency project,  I don't see that really happening with the Meraki model unless you want to keep dumping money into them.  

DSJ

  
Dustin Jurman
CEO
Rapid Systems Corporation 
1211 N. West Shore Blvd. Suite 711
Tampa, FL 33607
Ph: 813-232-4887 
Cell:813-892-7006
http://www.rapidsys.com
"Building Better Infrastructure"? 







     

-----Original Message-----
From: Glenn Robuck [mailto:techravingmad at gmail.com] 
Sent: Tuesday, November 19, 2013 5:12 PM
To: NANOG
Subject: Re: Meraki

I'm curious if any of you guys have compared Meraki and Xirrus?  We are currently in the process of picking new WAPs and have narrowed it down to these too.  We are leaning towards Xirrus due to it's modular structure.
 It also has a great user interface.

Anyone else evaluate Xirrus?


On Tue, Nov 19, 2013 at 3:34 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote:

> They give you a free ap for listening to their pitch.. We love them.
> Expensive.. But responsive and responsible.. Which is pretty hard to 
> find in Wi-Fi land. Pretty interface and lots of little bells and whistles..
> They have my vote from what we evaluated (ubnt, Blahblahblah).
>
>
> Sent from my Mobile Device.
>
>
> -------- Original message --------
> From: "Pedersen, Sean" <Sean.Pedersen at usairways.com>
> Date: 11/19/2013 12:00 PM (GMT-09:00)
> To: NANOG <nanog at nanog.org>
> Subject: RE: Meraki
>
>
> I started to look into them for personal and limited small business 
> use, but stopped short when I realized their cloud management platform 
> is subscription-based. Unless I've missed something, you cannot deploy 
> your own internal management platform. It's all licensed through 
> Meraki/Cisco, which means if you lose your Internet connection, you 
> lose management access to your gear. That could be a deal-killer in certain environments.
> Maybe someone with more experience on the platform could correct me there.
>
> -----Original Message-----
> From: Hank Disuko [mailto:gourmetcisco at hotmail.com]
> Sent: Tuesday, November 19, 2013 10:26 AM
> To: NANOG
> Subject: Meraki
>
> Hi folks,
>
> I've traditionally been a Cisco Catalyst shop for my switching gear.
>
> I am doing a significant hardware refresh in one of my offices, which 
> will entail replacing about 20 access switches and a couple core devices.
>  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end 
> I have 1G fibre/copper and 10G fibre.  My core switch of choice will 
> likely be the Cat 4500 series.
>
> I'm considering Cisco's Meraki platform for my access layer and I'm 
> looking for deployment stories of folks that have deployed Meraki in 
> the past...good/bad/ugly kinda stuff.
>
> I know Meraki hardcores were upset when Cisco acquired them, but not 
> exactly sure why.
>
> Anyway, any thoughts would be useful.  Thanks!
>
> -Hank
>
>
>



From knife at toaster.net  Wed Nov 20 16:26:43 2013
From: knife at toaster.net (Sean Lazar)
Date: Wed, 20 Nov 2013 08:26:43 -0800
Subject: Meraki
In-Reply-To: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
Message-ID: <528CE2C3.1010107@toaster.net>

Meraki did not work for me in a high density office environment, with
heavy wireless usage. Kept dropping clients at peak times. We went with
Aruba.

On 11/19/13 9:25 AM, Hank Disuko wrote:
> Hi folks, 
>  
> I've traditionally been a Cisco Catalyst shop for my switching gear.
>  
> I am doing a significant hardware refresh in one of my offices, which will entail replacing about 20 access switches and a couple core devices.  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I have 1G fibre/copper and 10G fibre.  My core switch of choice will likely be the Cat 4500 series.
>  
> I'm considering Cisco's Meraki platform for my access layer and I'm looking for deployment stories of folks that have deployed Meraki in the past...good/bad/ugly kinda stuff.
>  
> I know Meraki hardcores were upset when Cisco acquired them, but not exactly sure why.
>  
> Anyway, any thoughts would be useful.  Thanks!
>  
> -Hank
>  		 	   		  
>
>



From morrowc.lists at gmail.com  Wed Nov 20 18:54:00 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 20 Nov 2013 13:54:00 -0500
Subject: [renesys] The New Threat: Targeted Internet Traffic Misdirection
In-Reply-To: <20131119233533.GA31522@sources.org>
References: <20131119233533.GA31522@sources.org>
Message-ID: <CAL9jLaaC=Y-HK4Ki8G71UPC1P1RzqpJUKQVPAVx-8iTCp9HNPA@mail.gmail.com>

someone has already parsed out all route announcements from
ris/routeviews for the 2 specific incidents in question in the
article? and posted the contents somewhere for review? I didn't see
Renesys do that :( So, they've got some unsupported conclusions that
are tough to get behind absent that data.

On Tue, Nov 19, 2013 at 6:35 PM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> Interesting study of what seems to be real BGP shunts:
>
> http://www.renesys.com/2013/11/mitm-internet-hijacking/
>


From rps at maine.edu  Wed Nov 20 19:08:53 2013
From: rps at maine.edu (Ray Soucy)
Date: Wed, 20 Nov 2013 14:08:53 -0500
Subject: Meraki
In-Reply-To: <D6F32509-7BF9-4A3E-A8FB-B2E862AA7A32@dds.nl>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <D6F32509-7BF9-4A3E-A8FB-B2E862AA7A32@dds.nl>
Message-ID: <CALFTrnM7+KFJ-dXOaAeOL-V+=B+Y=doGw26rQhEjFA9tHOTbbQ@mail.gmail.com>

I'm very interested in other user experiences with Ubiquity for smaller
deployments vs. traditional Cisco APs and WLC.  Especially for a collection
of rural areas.  The price point and software controller are very
attractive.

Anyone running a centralized controller for a lot of remote sites?


On Tue, Nov 19, 2013 at 1:57 PM, Seth Mos <seth.mos at dds.nl> wrote:

>
> Op 19 nov 2013, om 18:25 heeft Hank Disuko het volgende geschreven:
>
> > Hi folks,
> >
> > I've traditionally been a Cisco Catalyst shop for my switching gear.
> >
> > I am doing a significant hardware refresh in one of my offices, which
> will entail replacing about 20 access switches and a couple core devices.
>  Pretty simple L3 VLAN environment with VRRP/HSRP, on the physical end I
> have 1G fibre/copper and 10G fibre.  My core switch of choice will likely
> be the Cat 4500 series.
> >
> > I'm considering Cisco's Meraki platform for my access layer and I'm
> looking for deployment stories of folks that have deployed Meraki in the
> past...good/bad/ugly kinda stuff.
> >
> > I know Meraki hardcores were upset when Cisco acquired them, but not
> exactly sure why.
> >
> > Anyway, any thoughts would be useful.  Thanks!
>
> We used to use the 3Com wireless kit before it became H3C, and then HP,
> which worked ok but the engrish in the UI was horrid.
>
> We've since purchased 25 Ubiquity wireless access points, specifically the
> 300N Pro access points, they work really well, pricing is competitive
> priced and the management is nice.
>
> I've setup a Debian VM, installed their management software from their APT
> repo and just go from there. The version 3 software also supports
> multi-site which is really nice.
>
> It's a huge upgrade over our previous wireless though.
>
> Cheers,
> Seth
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

From elouie at yahoo.com  Wed Nov 20 19:53:54 2013
From: elouie at yahoo.com (Eric A Louie)
Date: Wed, 20 Nov 2013 11:53:54 -0800 (PST)
Subject: BGP neighbor/configuration testing
Message-ID: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>

Scenario: a regional ISP preparing to cutover to a new upstream BGP provider at one of my POPs.? Want minimal or no network disruption, and want to ensure everything is ready to go prior to the cutover.

?I'm planning to use the following order of operations:
1. Establish IP connectivity to the new ISP (already done)
2. Configure my BGP router and shutdown the new neighbor (ISP says their side is already configured and ready)
3. During the maintenance window for this change, activate the new BGP connection (remove neighbor shutdown)
4. Do the appropriate tests (sh bgp nei, login to my upstream's route server and check route advertisements, sign in to looking glass and/or route servers from other providers to see if my routes from the new ISP are being advertised, and I'm open to any other tests)
5. Turn down the old connection (neighbor shutdown)
6. Watch the old connection get removed from route servers/looking glasses from step 4

A. Does that order make sense or does it need some tweaking, additions, or "other"?

B. I'd like to test the new upstream BGP configuration without passing traffic to and through it.? What can I do (if anything) on my configuration end to put up the BGP configuration, establish a neighbor connection, and NOT actually pass any traffic through it?? After putting my configuration up, I'd like to do a show bgp nei 1.1.1.1 advertised-routes to ensure my routes are going out, and then shut the neighbor down until the cutover.



thanks for your input
Eric

From jabley at hopcount.ca  Wed Nov 20 20:01:33 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 20 Nov 2013 15:01:33 -0500
Subject: BGP neighbor/configuration testing
In-Reply-To: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
Message-ID: <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>


On 2013-11-20, at 14:53, Eric A Louie <elouie at yahoo.com> wrote:

> Scenario: a regional ISP preparing to cutover to a new upstream BGP provider at one of my POPs.  Want minimal or no network disruption, and want to ensure everything is ready to go prior to the cutover.
> 
>  I'm planning to use the following order of operations:
> 1. Establish IP connectivity to the new ISP (already done)
> 2. Configure my BGP router and shutdown the new neighbor (ISP says their side is already configured and ready)

Leave the adjacency up, and just deny all inbound and outbound on the corresponding route filter. You never want a maintenance's success to depend on "no neigh x.x.x.x shut" working smoothly; much better to be able to confirm that the session is up before you start and just change the import/export policy.

> 3. During the maintenance window for this change, activate the new BGP connection (remove neighbor shutdown)
> 4. Do the appropriate tests (sh bgp nei, login to my upstream's route server and check route advertisements, sign in to looking glass and/or route servers from other providers to see if my routes from the new ISP are being advertised, and I'm open to any other tests)

You could insert "wait N days" here, with a rollback plan (e.g. in case of customer-enraging congestion or packet loss) that restores the original configuration by shutting down the new adjacency.

> 5. Turn down the old connection (neighbor shutdown)
> 6. Watch the old connection get removed from route servers/looking glasses from step 4
> 
> A. Does that order make sense or does it need some tweaking, additions, or "other"?
> 
> B. I'd like to test the new upstream BGP configuration without passing traffic to and through it.  What can I do (if anything) on my configuration end to put up the BGP configuration, establish a neighbor connection, and NOT actually pass any traffic through it?  After putting my configuration up, I'd like to do a show bgp nei 1.1.1.1 advertised-routes to ensure my routes are going out, and then shut the neighbor down until the cutover.

Bring the session up with deny all in both directions, and use the appropriate show commands (show neigh ... received-routes since you're talking cisco) to show what routes were received upstream of the filter. You are presumably already testing your export policy on your live session; if the configuration on the new session is the same, then you're really just talking about making sure that the internal route set visible on the router with the new session is right.


Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131120/f2f6765a/attachment.bin>

From joelja at bogus.com  Wed Nov 20 20:07:00 2013
From: joelja at bogus.com (joel jaeggli)
Date: Wed, 20 Nov 2013 12:07:00 -0800
Subject: BGP neighbor/configuration testing
In-Reply-To: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
Message-ID: <528D1664.8040907@bogus.com>

On 11/20/13, 11:53 AM, Eric A Louie wrote:
> Scenario: a regional ISP preparing to cutover to a new upstream BGP provider at one of my POPs.  Want minimal or no network disruption, and want to ensure everything is ready to go prior to the cutover.
> 
>  I'm planning to use the following order of operations:
> 1. Establish IP connectivity to the new ISP (already done)
> 2. Configure my BGP router and shutdown the new neighbor (ISP says their side is already configured and ready)

normally you just bring up the session with restrictive import/export
e.g. reject all and see what they send you. that was you can verify
what's copacetic before you employ it.

> 3. During the maintenance window for this change, activate the new BGP connection (remove neighbor shutdown)
> 4. Do the appropriate tests (sh bgp nei, login to my upstream's route server and check route advertisements, sign in to looking glass and/or route servers from other providers to see if my routes from the new ISP are being advertised, and I'm open to any other tests)

Apply the export policy associated with sending your prefix to them.
assume they're using rpf and they'll blackhole any traffic from you
until they receive a prefix that it's coming from and install it in
their fib

If they're sending you a full table (and you also have a full table from
your other provider), then alter the import policy to accept routes from
them.

> 5. Turn down the old connection (neighbor shutdown)

once the above has been stable for a while...

apply new import export policy (e.g. reject all) and clear soft in out
the session.

once there's no  traffic on it and everything else hasn't caught fire
shut down the bgp session

> 6. Watch the old connection get removed from route servers/looking glasses from step 4



> A. Does that order make sense or does it need some tweaking, additions, or "other"?
> 
> B. I'd like to test the new upstream BGP configuration without passing traffic to and through it.  What can I do (if anything) on my configuration end to put up the BGP configuration, establish a neighbor connection, and NOT actually pass any traffic through it?  After putting my configuration up, I'd like to do a show bgp nei 1.1.1.1 advertised-routes to ensure my routes are going out, and then shut the neighbor down until the cutover.
> 
> 
> 
> thanks for your input
> Eric
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131120/acb26c1d/attachment-0001.bin>

From wwaites at tardis.ed.ac.uk  Wed Nov 20 20:08:32 2013
From: wwaites at tardis.ed.ac.uk (William Waites)
Date: Wed, 20 Nov 2013 20:08:32 +0000 (GMT)
Subject: Meraki
In-Reply-To: <CALFTrnM7+KFJ-dXOaAeOL-V+=B+Y=doGw26rQhEjFA9tHOTbbQ@mail.gmail.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <D6F32509-7BF9-4A3E-A8FB-B2E862AA7A32@dds.nl>
 <CALFTrnM7+KFJ-dXOaAeOL-V+=B+Y=doGw26rQhEjFA9tHOTbbQ@mail.gmail.com>
Message-ID: <20131120.200832.175893208.wwaites@tardis.ed.ac.uk>

On Wed, 20 Nov 2013 14:08:53 -0500, Ray Soucy <rps at maine.edu> said:

    > I'm very interested in other user experiences with Ubiquity for
    > smaller deployments vs. traditional Cisco APs and WLC.
    > Especially for a collection of rural areas.  The price point and
    > software controller are very attractive.

I've never used the software controller but we use a lot of Ubiquiti
kit in rural Scotland. We use it mostly in transparent bridge mode
with more capable routers speaking ethernet - FreeBSD on Soekris boards
and Mikrotik mostly. In general the RF part is great, but the software
part is buggy. We have been extensively bitten by transparent bridge
not being transparent enough and eating multicast packets which of
course completely hoses OSPF. Using NBMA and being very careful about
which firmware version mostly works. Don't try to make them do
anything sophisticated.

-w
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From jfbeam at gmail.com  Wed Nov 20 20:30:24 2013
From: jfbeam at gmail.com (Ricky Beam)
Date: Wed, 20 Nov 2013 15:30:24 -0500
Subject: Meraki
In-Reply-To: <CAL9jLaa3QxDB1X5ornoHqwrzGMP8LL++zy=u7kgYpHSokyYvKw@mail.gmail.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
 <CAL9jLaa3QxDB1X5ornoHqwrzGMP8LL++zy=u7kgYpHSokyYvKw@mail.gmail.com>
Message-ID: <op.w6u68ypdtfhldh@rbeam.xactional.com>

On Tue, 19 Nov 2013 16:36:42 -0500, Christopher Morrow  
<morrowc.lists at gmail.com> wrote:
> so you just decide: "How many may we have to deploy?"
> then schedule that many pitch meetings with them? :)

Heh. No.  It's not supposed to work like that.  They want a verifiable  
company for the free (cheapest, most basic) AP. And you (and the  
associated company) get one, and only one, freebee.

(As it's the basic 2.4Ghz model, I've been less motivated to get my  
schwag.)


From Lee at asgard.org  Wed Nov 20 21:14:47 2013
From: Lee at asgard.org (Lee Howard)
Date: Wed, 20 Nov 2013 16:14:47 -0500
Subject: NAT64 and matching identities
In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A72597E@SEAEMBX02.olympus.F5Net.com>
Message-ID: <CEB28FB1.39AA4%Lee@asgard.org>

Leaving out stuff . . .

On 11/19/13 6:53 PM, "Ian Smith" <I.Smith at F5.com> wrote:

>
>There is obviously a long tail of ip4 destinations, but nearly all of 500
>of the Alexa global 500 have ip6 listeners,

Do you have a data source for that?  I see no indication of IPv6 listeners
on 85% of the top sites.

Lee




From cliff.bowles at apollogrp.edu  Wed Nov 20 21:21:45 2013
From: cliff.bowles at apollogrp.edu (Cliff Bowles)
Date: Wed, 20 Nov 2013 14:21:45 -0700
Subject: Dynamic routing through firewall
Message-ID: <1A5C3257AD8D4946A4B497A6FAF501743C457A2A11@EXCH07-01.apollogrp.edu>

Request for feedback...

We have a need for an external partner to dynamically advertise their network to us in two separate data centers. The hitch is that, touching external partners, our edge routers for B2B partners reside in DMZs.

Now, to ensure failover from one data center to another when there is a link/device problem, we need to pass dynamic routing updates through each DMZ firewall to core routing at each data center. (yes, the data centers are in sync via backbone routing)

We have multiple B2B peers, so we have multiple VRFs on the edge routers that all need to talk to our core routing, but not necessarily with each other... so we are on the hook for both the routing of these tenants as well as the security inspection.

The 4 common options we've considered:

1.       Routing through the firewall across a tunnel: Pro - relatively simple, Con - occasional MTU issues and the firewalls may not be able to disassemble/reassemble the tunnel packets for policy inpsection.

2.       Transparent firewalling: Pro - extremely easy, Con - some vendors cannot support stateful failover in HA pairs, some won't do stateful at all, so you need to open up rules bidirectional (i.e. reply ports GT 1024), plus all the whizbang IDS/IPS goes out the window along with NAT and other stuff, so it will be a very point solution

3.       BGP on the firewall: Pro - moderately easy unless the policies get very sophisticated, and firewalls automatically learn where prefixes are automatically; Con - it's BGP on the firewall... neither the network or the security teams are thrilled about it, support calls tend to loop in both teams, a security guy can cause a lot of problems with human error, we've seen some firewalls with memory leak vulnerabilities and experienced issues in the past

4.       BGP through the firewall (multihop): Pro - easy to configure, doesn't require routing on the firewall; Con - for every prefix our upstream edge router advertises to our core, we will need statics in the firewall to make sure that it knows where to forward. We can do a default pointing to the edge router with some large summaries pointing back inside (or wherever), but you get the point - the more prefixes that aren't covered by the default, the less scalable it becomes

5.       Firewall on a stick: This is untested, but the idea was floated that we could peer the edge router with our core router, but have Policy-routes on every customer VRF setting the next-hop as the firewall. The firewall will apply policy, and (like option 4) use statics to forward to the core. Reverse path traffic would pretty much do the same from Core-to firewall-to edge. It sounds ugly, and we haven't tested it, but we didn't want to toss it.

A lot of you work in multi-tenant environments, and some of you are responsible for the security between tenants. I'd like to hear alternatives, if you know of any.
And if you use one of the options I mentioned, please say why you chose it and how it works.
Finally, if you tried one of the options and it was terrible, please explain.

Thanks in advance!

CWB



________________________________
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.


From gem at rellim.com  Wed Nov 20 21:30:33 2013
From: gem at rellim.com (Gary E. Miller)
Date: Wed, 20 Nov 2013 13:30:33 -0800
Subject: NAT64 and matching identities
In-Reply-To: <CEB28FB1.39AA4%Lee@asgard.org>
References: <419417C345CA5F48BF45F0A23955A0634A72597E@SEAEMBX02.olympus.F5Net.com>
 <CEB28FB1.39AA4%Lee@asgard.org>
Message-ID: <20131120133033.3c84120f.gem@rellim.com>

Yo Lee!

On Wed, 20 Nov 2013 16:14:47 -0500
Lee Howard <Lee at asgard.org> wrote:

> >There is obviously a long tail of ip4 destinations, but nearly all
> >of 500 of the Alexa global 500 have ip6 listeners,
> 
> Do you have a data source for that?  I see no indication of IPv6
> listeners on 85% of the top sites.

A slightly different metric, 44% of USA content available on IPv6:

http://6lab.cisco.com/stats/

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
	gem at rellim.com  Tel:+1(541)382-8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131120/9e1687fe/attachment.bin>

From Lee at asgard.org  Wed Nov 20 21:38:23 2013
From: Lee at asgard.org (Lee Howard)
Date: Wed, 20 Nov 2013 16:38:23 -0500
Subject: NAT64 and matching identities
In-Reply-To: <20131120133033.3c84120f.gem@rellim.com>
Message-ID: <CEB29567.39B09%Lee@asgard.org>



On 11/20/13 4:30 PM, "Gary E. Miller" <gem at rellim.com> wrote:

>Yo Lee!
>
>On Wed, 20 Nov 2013 16:14:47 -0500
>Lee Howard <Lee at asgard.org> wrote:
>
>> >There is obviously a long tail of ip4 destinations, but nearly all
>> >of 500 of the Alexa global 500 have ip6 listeners,
>> 
>> Do you have a data source for that?  I see no indication of IPv6
>> listeners on 85% of the top sites.
>
>A slightly different metric, 44% of USA content available on IPv6:
>
>http://6lab.cisco.com/stats/

Right, weighted by DNS queries.
Compare to http://www.vyncke.org/ipv6status/detailed.php?country=us
and http://www.employees.org/~dwing/aaaa-stats/

Not equivalent to "nearly all of Alexa 500."


Lee




From rdobbins at arbor.net  Thu Nov 21 00:44:13 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Thu, 21 Nov 2013 00:44:13 +0000
Subject: Dynamic routing through firewall
In-Reply-To: <1A5C3257AD8D4946A4B497A6FAF501743C457A2A11@EXCH07-01.apollogrp.edu>
References: <1A5C3257AD8D4946A4B497A6FAF501743C457A2A11@EXCH07-01.apollogrp.edu>
Message-ID: <0FDDE00F-9221-47B4-A95C-6C2E9C83BBD9@arbor.net>


On Nov 21, 2013, at 4:21 AM, Cliff Bowles <cliff.bowles at apollogrp.edu> wrote:

> Finally, if you tried one of the options and it was terrible, please explain.

They're all terrible, heh.

Get the firewalls out of the picture:

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

Stateful firewalls should not be placed in front of servers, and should not be interposed between eBGP peers.  Whatever access policies are necessary should be expressed in stateless ACLs, as there's no point in putting a stateful inspection device in front of a server which receives unsolicited communications, and many reasons for not doing so.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From wbailey at satelliteintelligencegroup.com  Thu Nov 21 04:33:46 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Thu, 21 Nov 2013 04:33:46 +0000
Subject: Meraki
In-Reply-To: <op.w6u68ypdtfhldh@rbeam.xactional.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
 <CAL9jLaa3QxDB1X5ornoHqwrzGMP8LL++zy=u7kgYpHSokyYvKw@mail.gmail.com>,
 <op.w6u68ypdtfhldh@rbeam.xactional.com>
Message-ID: <cppbvkm0sfhji8m5tchs27le.1385008408830@email.android.com>

If we had cheerios.. You just urinated in them. :(

Sometimes a joke should be a joke to laugh at.. Not discredit. Next time we will beat Morrow for not being funny enough.. ;)


Sent from my Mobile Device.


-------- Original message --------
From: Ricky Beam <jfbeam at gmail.com>
Date: 11/20/2013 11:32 AM (GMT-09:00)
To: nanog at nanog.org
Subject: Re: Meraki


On Tue, 19 Nov 2013 16:36:42 -0500, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> so you just decide: "How many may we have to deploy?"
> then schedule that many pitch meetings with them? :)

Heh. No.  It's not supposed to work like that.  They want a verifiable
company for the free (cheapest, most basic) AP. And you (and the
associated company) get one, and only one, freebee.

(As it's the basic 2.4Ghz model, I've been less motivated to get my
schwag.)


From morrowc.lists at gmail.com  Thu Nov 21 04:50:40 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 20 Nov 2013 23:50:40 -0500
Subject: Meraki
In-Reply-To: <cppbvkm0sfhji8m5tchs27le.1385008408830@email.android.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
 <CAL9jLaa3QxDB1X5ornoHqwrzGMP8LL++zy=u7kgYpHSokyYvKw@mail.gmail.com>
 <op.w6u68ypdtfhldh@rbeam.xactional.com>
 <cppbvkm0sfhji8m5tchs27le.1385008408830@email.android.com>
Message-ID: <CAL9jLaa9k_yUir7u5pwiP7=_9FROnm7zQKauk6hMc=5mMEw2Cg@mail.gmail.com>

On Wed, Nov 20, 2013 at 11:33 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> If we had cheerios.. You just urinated in them. :(
>
> Sometimes a joke should be a joke to laugh at.. Not discredit. Next time we will beat Morrow for not being funny enough.. ;)

you CAN spin up a new LLC for less than their cheapy AP... so it might
actually work out to do that for each of your employees :)

> -------- Original message --------
> From: Ricky Beam <jfbeam at gmail.com>
> Date: 11/20/2013 11:32 AM (GMT-09:00)
> To: nanog at nanog.org
> Subject: Re: Meraki
>
>
> On Tue, 19 Nov 2013 16:36:42 -0500, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
>> so you just decide: "How many may we have to deploy?"
>> then schedule that many pitch meetings with them? :)
>
> Heh. No.  It's not supposed to work like that.  They want a verifiable
> company for the free (cheapest, most basic) AP. And you (and the
> associated company) get one, and only one, freebee.
>
> (As it's the basic 2.4Ghz model, I've been less motivated to get my
> schwag.)
>


From wbailey at satelliteintelligencegroup.com  Thu Nov 21 04:57:06 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Thu, 21 Nov 2013 04:57:06 +0000
Subject: Meraki
In-Reply-To: <CAL9jLaa9k_yUir7u5pwiP7=_9FROnm7zQKauk6hMc=5mMEw2Cg@mail.gmail.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
 <CAL9jLaa3QxDB1X5ornoHqwrzGMP8LL++zy=u7kgYpHSokyYvKw@mail.gmail.com>
 <op.w6u68ypdtfhldh@rbeam.xactional.com>
 <cppbvkm0sfhji8m5tchs27le.1385008408830@email.android.com>,
 <CAL9jLaa9k_yUir7u5pwiP7=_9FROnm7zQKauk6hMc=5mMEw2Cg@mail.gmail.com>
Message-ID: <pi5b4bm11amip9731mxa2s21.1385009816132@email.android.com>

Okay.. Get me my stick.. Morrow is in for it.

;)


Sent from my Mobile Device.


-------- Original message --------
From: Christopher Morrow <morrowc.lists at gmail.com>
Date: 11/20/2013 7:50 PM (GMT-09:00)
To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
Cc: Ricky Beam <jfbeam at gmail.com>,nanog at nanog.org
Subject: Re: Meraki


On Wed, Nov 20, 2013 at 11:33 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> If we had cheerios.. You just urinated in them. :(
>
> Sometimes a joke should be a joke to laugh at.. Not discredit. Next time we will beat Morrow for not being funny enough.. ;)

you CAN spin up a new LLC for less than their cheapy AP... so it might
actually work out to do that for each of your employees :)

> -------- Original message --------
> From: Ricky Beam <jfbeam at gmail.com>
> Date: 11/20/2013 11:32 AM (GMT-09:00)
> To: nanog at nanog.org
> Subject: Re: Meraki
>
>
> On Tue, 19 Nov 2013 16:36:42 -0500, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
>> so you just decide: "How many may we have to deploy?"
>> then schedule that many pitch meetings with them? :)
>
> Heh. No.  It's not supposed to work like that.  They want a verifiable
> company for the free (cheapest, most basic) AP. And you (and the
> associated company) get one, and only one, freebee.
>
> (As it's the basic 2.4Ghz model, I've been less motivated to get my
> schwag.)
>

From j at 2600hz.com  Thu Nov 21 08:22:33 2013
From: j at 2600hz.com (Joshua Goldbard)
Date: Thu, 21 Nov 2013 08:22:33 +0000
Subject: Meraki
In-Reply-To: <20131120.200832.175893208.wwaites@tardis.ed.ac.uk>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <D6F32509-7BF9-4A3E-A8FB-B2E862AA7A32@dds.nl>
 <CALFTrnM7+KFJ-dXOaAeOL-V+=B+Y=doGw26rQhEjFA9tHOTbbQ@mail.gmail.com>,
 <20131120.200832.175893208.wwaites@tardis.ed.ac.uk>
Message-ID: <FC19A07B-A985-4EFF-A8FF-DEF7E88B0AFD@2600hz.com>

For what it's worth...

We did a conference, KazooCon, with Meraki Gear and Ubiquiti Access Points. I am not a wizard but I set the whole network up except the access points which failed to detect at first. I think it took about an hour to setup in total; really easy even with the stutter. The network gear was:

2x Meraki Firewall
2x Meraki 48 port switch
4x Ubiquiti APN

Comcast dropped two cable modems in for us, 200Mbps for 2 days of bliss. The conference network was ridiculous, but all parts held up well. The wifi was fast and the LAN for the SIP phones was perfect. It was kind of overkill, but can you ever really have too much bandwidth?

Cheers,
Joshua

Sent from my iPhone

On Nov 20, 2013, at 12:12 PM, "William Waites" <wwaites at tardis.ed.ac.uk> wrote:

> On Wed, 20 Nov 2013 14:08:53 -0500, Ray Soucy <rps at maine.edu> said:
> 
>> I'm very interested in other user experiences with Ubiquity for
>> smaller deployments vs. traditional Cisco APs and WLC.
>> Especially for a collection of rural areas.  The price point and
>> software controller are very attractive.
> 
> I've never used the software controller but we use a lot of Ubiquiti
> kit in rural Scotland. We use it mostly in transparent bridge mode
> with more capable routers speaking ethernet - FreeBSD on Soekris boards
> and Mikrotik mostly. In general the RF part is great, but the software
> part is buggy. We have been extensively bitten by transparent bridge
> not being transparent enough and eating multicast packets which of
> course completely hoses OSPF. Using NBMA and being very careful about
> which firmware version mostly works. Don't try to make them do
> anything sophisticated.
> 
> -w
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 


From bmeshier at amherst.com  Thu Nov 21 17:30:07 2013
From: bmeshier at amherst.com (Meshier, Brent)
Date: Thu, 21 Nov 2013 17:30:07 +0000
Subject: Meraki
In-Reply-To: <pi5b4bm11amip9731mxa2s21.1385009816132@email.android.com>
References: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
 <7EF4A8B03B0A3A44858C8B42E0DB236A01232F9FBCC0@PHX-52N-EXM04A.lcc.usairways.com>
 <oiwnqdh7haw46m0e6555flx5.1384896882266@email.android.com>
 <CAL9jLaa3QxDB1X5ornoHqwrzGMP8LL++zy=u7kgYpHSokyYvKw@mail.gmail.com>
 <op.w6u68ypdtfhldh@rbeam.xactional.com>
 <cppbvkm0sfhji8m5tchs27le.1385008408830@email.android.com>,
 <CAL9jLaa9k_yUir7u5pwiP7=_9FROnm7zQKauk6hMc=5mMEw2Cg@mail.gmail.com>
 <pi5b4bm11amip9731mxa2s21.1385009816132@email.android.com>
Message-ID: <68C2CBC977F3E04799DF9C76E938E70908244A5A@DFEXCH1.asglp.com>

Meraki does not handle high density environments well, will drop clients.  I also hate the idea of subscription based hardware, we should be moving away from the nickel and dime model.  We deployed Ruckus and couldn't be happier, running 50+ clients per AP.

Brent Meshier | Amherst Holdings, LLC | 5001 Plaza on the Lake, Suite 200, Austin, TX 78746 | T: 512-342-3010

--- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication.



From mpetach at netflight.com  Thu Nov 21 19:08:05 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 21 Nov 2013 11:08:05 -0800
Subject: NAT64 and matching identities
In-Reply-To: <20131120133033.3c84120f.gem@rellim.com>
References: <419417C345CA5F48BF45F0A23955A0634A72597E@SEAEMBX02.olympus.F5Net.com>
 <CEB28FB1.39AA4%Lee@asgard.org>
 <20131120133033.3c84120f.gem@rellim.com>
Message-ID: <CAEmG1=rK8E05AvkLH+2i-QVJBJCcTWTnFen-_Z55Y9Kx9ZxU+A@mail.gmail.com>

On Wed, Nov 20, 2013 at 1:30 PM, Gary E. Miller <gem at rellim.com> wrote:

> Yo Lee!
>
> On Wed, 20 Nov 2013 16:14:47 -0500
> Lee Howard <Lee at asgard.org> wrote:
>
> > >There is obviously a long tail of ip4 destinations, but nearly all
> > >of 500 of the Alexa global 500 have ip6 listeners,
> >
> > Do you have a data source for that?  I see no indication of IPv6
> > listeners on 85% of the top sites.
>
> A slightly different metric, 44% of USA content available on IPv6:
>
> http://6lab.cisco.com/stats/
>


I'm puzzled; I have native v6 connectivity
to 6lab.cisco.com according to traceroute6
output, and  yet the page says I'm connecting
to it via IPv4.  :(
So, I did some poking; it seems 6lab.cisco.com
doesn't have working IPv6 for their stats system,
which makes me wonder how accurate the data
from it is likely to be:

mpetach at mintyHP:~> telnet -6 6lab.cisco.com 80
Trying 2001:420:4420:101:0:c:15c0:4664...
Connected to 6lab.cisco.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 302 Found
Date: Thu, 21 Nov 2013 19:03:29 GMT
Server: Apache/2.2.16 (Debian)
Location: http://6lab-stats.com/index.php
Cache-Control: max-age=1
Expires: Thu, 21 Nov 2013 19:03:30 GMT
Vary: Accept-Encoding
Content-Length: 295
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://6lab-stats.com/index.php
">here</a>.</p>
<hr>
<address>Apache/2.2.16 (Debian) Server at 6lab-stats.com Port 80</address>
</body></html>
Connection closed by foreign host.
mpetach at mintyHP:~> telnet -6 6lab-stats.com 80
Trying 2001:420:81:101:0:c:15c0:4664...
telnet: Unable to connect to remote host: Connection timed out
mpetach at mintyHP:~>
mpetach at mintyHP:~> ping6 6lab-stats.com
PING 6lab-stats.com(2001:420:81:101:0:c:15c0:4664) 56 data bytes
^C
--- 6lab-stats.com ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9071ms

mpetach at mintyHP:~>





> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
>         gem at rellim.com  Tel:+1(541)382-8588
>

From brokenflea at gmail.com  Thu Nov 21 19:40:52 2013
From: brokenflea at gmail.com (Khurram Khan)
Date: Thu, 21 Nov 2013 12:40:52 -0700
Subject: Issues with Multiple T1's - southwest US
Message-ID: <E063A850-CFCA-4054-9F6D-6F3FEE57C9C5@gmail.com>

Hi All,

Does anyone know if there are any carrier issues up in Colorado (West Colorado) and New Mexico that would cause a bunch of T1's to go down. We've got a lot of T1's through Level3 and Cenutrylink in that particular area that are impacted. Trying to get a ticket opened through our NOC but the response is slow at the moment.

If someone is experiencing a similar issue any input would be appreciated.

thank you in advance,

khurram
-------------- 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/20131121/09e18878/attachment.bin>

From ayourtch at gmail.com  Thu Nov 21 19:44:14 2013
From: ayourtch at gmail.com (Andrew Yourtchenko)
Date: Thu, 21 Nov 2013 20:44:14 +0100
Subject: NAT64 and matching identities
In-Reply-To: <CAEmG1=rK8E05AvkLH+2i-QVJBJCcTWTnFen-_Z55Y9Kx9ZxU+A@mail.gmail.com>
References: <419417C345CA5F48BF45F0A23955A0634A72597E@SEAEMBX02.olympus.F5Net.com>
 <CEB28FB1.39AA4%Lee@asgard.org>
 <20131120133033.3c84120f.gem@rellim.com>
 <CAEmG1=rK8E05AvkLH+2i-QVJBJCcTWTnFen-_Z55Y9Kx9ZxU+A@mail.gmail.com>
Message-ID: <CAPi140Nf1+DO=pHEHbhUD3=AqXzfSZq4Yb0_Lqg+hsDqzB71gg@mail.gmail.com>

It was a stale DNS entry. Now fixed (modulo TTLs and such), thanks.

That said, your  troubleshooting was troubleshooting a different
problem, not your browser's inability to retrieve the page. The way
the browser sends the request is something like this (note the HTTP
version and the host header):

ayourtch at mcmini:~$ telnet -6 6lab.cisco.com 80
Trying 2001:420:4420:101:0:c:15c0:4664...
Connected to 6lab.cisco.com.
Escape character is '^]'.
GET / HTTP/1.1
Host: 6lab.cisco.com

HTTP/1.1 302 Found
Date: Thu, 21 Nov 2013 19:38:31 GMT
Server: Apache/2.2.16 (Debian)
X-Frame-Options: SAMEORIGIN
Location: http://6lab.cisco.com/index.php
Cache-Control: max-age=1
Expires: Thu, 21 Nov 2013 19:38:32 GMT
Vary: Accept-Encoding
Content-Length: 295
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a
href="http://6lab.cisco.com/index.php">here</a>.</p>
<hr>
<address>Apache/2.2.16 (Debian) Server at 6lab.cisco.com Port 80</address>
</body></html>


Anyway, the fact that you were still able to retrieve the original
reply with a redirect, makes me think that there could be a PMTUD
problem somewhere inbetween 6lab and yourself for retrieving the
larger content ...

If you tell your client address I will be able to test this theory. Or
you can quickly tweak your local interface value to 1280 and if that
works, then tell me your client address so i could debug from the
other side.

--a

On 11/21/13, Matthew Petach <mpetach at netflight.com> wrote:
> On Wed, Nov 20, 2013 at 1:30 PM, Gary E. Miller <gem at rellim.com> wrote:
>
>> Yo Lee!
>>
>> On Wed, 20 Nov 2013 16:14:47 -0500
>> Lee Howard <Lee at asgard.org> wrote:
>>
>> > >There is obviously a long tail of ip4 destinations, but nearly all
>> > >of 500 of the Alexa global 500 have ip6 listeners,
>> >
>> > Do you have a data source for that?  I see no indication of IPv6
>> > listeners on 85% of the top sites.
>>
>> A slightly different metric, 44% of USA content available on IPv6:
>>
>> http://6lab.cisco.com/stats/
>>
>
>
> I'm puzzled; I have native v6 connectivity
> to 6lab.cisco.com according to traceroute6
> output, and  yet the page says I'm connecting
> to it via IPv4.  :(
> So, I did some poking; it seems 6lab.cisco.com
> doesn't have working IPv6 for their stats system,
> which makes me wonder how accurate the data
> from it is likely to be:
>
> mpetach at mintyHP:~> telnet -6 6lab.cisco.com 80
> Trying 2001:420:4420:101:0:c:15c0:4664...
> Connected to 6lab.cisco.com.
> Escape character is '^]'.
> GET / HTTP/1.0
>
> HTTP/1.1 302 Found
> Date: Thu, 21 Nov 2013 19:03:29 GMT
> Server: Apache/2.2.16 (Debian)
> Location: http://6lab-stats.com/index.php
> Cache-Control: max-age=1
> Expires: Thu, 21 Nov 2013 19:03:30 GMT
> Vary: Accept-Encoding
> Content-Length: 295
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>302 Found</title>
> </head><body>
> <h1>Found</h1>
> <p>The document has moved <a href="http://6lab-stats.com/index.php
> ">here</a>.</p>
> <hr>
> <address>Apache/2.2.16 (Debian) Server at 6lab-stats.com Port 80</address>
> </body></html>
> Connection closed by foreign host.
> mpetach at mintyHP:~> telnet -6 6lab-stats.com 80
> Trying 2001:420:81:101:0:c:15c0:4664...
> telnet: Unable to connect to remote host: Connection timed out
> mpetach at mintyHP:~>
> mpetach at mintyHP:~> ping6 6lab-stats.com
> PING 6lab-stats.com(2001:420:81:101:0:c:15c0:4664) 56 data bytes
> ^C
> --- 6lab-stats.com ping statistics ---
> 10 packets transmitted, 0 received, 100% packet loss, time 9071ms
>
> mpetach at mintyHP:~>
>
>
>
>
>
>> RGDS
>> GARY
>> ---------------------------------------------------------------------------
>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
>>         gem at rellim.com  Tel:+1(541)382-8588
>>
>


From dmburgess at linktechs.net  Thu Nov 21 20:17:49 2013
From: dmburgess at linktechs.net (Dennis Burgess)
Date: Thu, 21 Nov 2013 14:17:49 -0600
Subject: rogers.ca contact
Message-ID: <50710E9A7E64454C974049FC998EB655015F0D85@03-exchange.lti.local>

Got an issue where rogers SWIPed blocks to my customer in prep for BGP
peering and advertising, but at the last minute (right before we are to
set it up) rogers is saying that we can't advertise it, as they
advertise a larger block and that if we advertised it out our other
provider it would be considered route hijacking and they would turn OFF
the IPs though their network?

 

Off-list is fine !  

 

 

Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS-
Second Edition <http://www.wlan1.com/product_p/mikrotik%20book-2.htm> "

 Link Technologies, Inc -- Mikrotik & WISP Support Services

 Office: 314-735-0270 <tel:314-735-0270>  Website:
http://www.linktechs.net <http://www.linktechs.net/>  - Skype: linktechs
<skype:linktechs?call>

 -- Create Wireless Coverage's with www.towercoverage.com
<http://www.towercoverage.com/>  - 900Mhz - LTE - 3G - 3.65 - TV
Whitespace  

 


From syn at theintertubes.ca  Thu Nov 21 20:17:03 2013
From: syn at theintertubes.ca (Chris Watts)
Date: Thu, 21 Nov 2013 15:17:03 -0500
Subject: ATT Network Security/Mail Admin Team
Message-ID: <CAGELRFc8SmM4J_E_3+mjTk9bowLy239LOhqMTyUHP0WzsLBENQ@mail.gmail.com>

Hello NANOG,

Sorry for the spam, trying to resolve a large issue with AT&T blacklisting
my employer (We are a large, well known web security company). Attempts to
resolve via the normal channels have failed for the last couple hours and
this issue is impacting thousands of AT&T customers and thousands of our
own. Emails to my account reps, noc at att.com, netsec at att.com and tickets go
un-responded too. MIS Helpdesk states they have no way to contact the admin
team in charge of listings.

Would appreciate a off-list contact.

Thanks!
-Chris

From jra at baylink.com  Fri Nov 22 05:37:40 2013
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 22 Nov 2013 00:37:40 -0500 (EST)
Subject: Meraki
In-Reply-To: <BLU180-W90FEB28A006AFDA2ABE4C2C9E70@phx.gbl>
Message-ID: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Hank Disuko" <gourmetcisco at hotmail.com>

> I'm considering Cisco's Meraki platform for my access layer and I'm
> looking for deployment stories of folks that have deployed Meraki in
> the past...good/bad/ugly kinda stuff.
> 
> I know Meraki hardcores were upset when Cisco acquired them, but not
> exactly sure why.

Anecdote:

My local IHOP finally managed to get Wifi internet access in the restaurant.

For reasons unknown to me, it's a Meraki box, backhauled *over T-mobile*.

That's just as unpleasant as you'd think it would be, And More!

Both the wifi and 3G (yes, 3G) boxes lock up on a fairly regular basis, 
requiring a power cycle, which, generally, they'll only do because I've
been eating there for 20 years, and they trust me when I ask them to.

I can't say whether this provides any illumination on the rest of their
product line, but...

Cheers,
-- jra
-- 
Make Election Day a federal holiday: http://wh.gov/lBm94  100k sigs by 12/14

Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From seth.mos at dds.nl  Fri Nov 22 06:34:33 2013
From: seth.mos at dds.nl (Seth Mos)
Date: Fri, 22 Nov 2013 07:34:33 +0100
Subject: Meraki
In-Reply-To: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>
References: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>
Message-ID: <4FFF777C-07B6-49FD-A87F-52156C9069FC@dds.nl>


Op 22 nov 2013, om 06:37 heeft Jay Ashworth het volgende geschreven:

> ----- Original Message -----
> Anecdote:
> 
> My local IHOP finally managed to get Wifi internet access in the restaurant.
> 
> For reasons unknown to me, it's a Meraki box, backhauled *over T-mobile*.
> 
> That's just as unpleasant as you'd think it would be, And More!
> 
> Both the wifi and 3G (yes, 3G) boxes lock up on a fairly regular basis, 
> requiring a power cycle, which, generally, they'll only do because I've
> been eating there for 20 years, and they trust me when I ask them to.
> 
> I can't say whether this provides any illumination on the rest of their
> product line, but...

To compound matters, i'd go as far as to say that any wireless solution on 2.4Ghz isn't really a wireless solution. It's just not feasible anymore in 2013, there is just *so much* interference from everything using the unlicensed 2.4Ghz band that it's own success is it's greatest downfall.

Reliable wireless isn't (to use the famous war quote "friendly fire isn't")

For whatever reasons, whomever I talk to they all tell me that <ISP here> sucks, and if I ask further if they are using the wireless thingamabob that the ISP shipped them, they says yes. So, that's about right then.

I've been using a PCengines.ch Alix router for years now (AMD Geode, x86, 256MB ram, CF) with a cable modem in bridge mode with seperate dual band access points in the places where I need them (living room, attic office) and I can't say that my experiences with the <ISP here> mesh with theirs.

Anyhow, if you are going to deploy wireless, make sure to use dual band, and name the 2.4Ghz SSID "internet" and the 5Ghz SSID "faster-internet". You'll see people having a heck of a better time. Social engineering works :)

When we chose the Ubiquity wireless kit we could deploy twice as many APs for the same price of one of the other APs. This effectively means we have a very dense wireless network that covers the entire building, and lot's of kit that can actually see and use the 5Ghz band.

Setup was super easy, I added a unifi DNS name that points to my unifi controller host and I get a email that a new AP is ready to be put into service. Having a local management host instead of some cloud was a hard requirement. I also like that I can just "apt-get update; apt-get upgrade" the software. By using DNS remote deployment was super easy too, send the unit off and let them plug it in, it then comes onto the network and registers itself.

I believe every current Apple iDevice currently supports the 5Ghz band, and all the Dell gear we purchase also comes ordered with it. Heck, even my 2011 Sony Xperia T has 5Ghz wireless now, as do the current Samsung Galaxy S3, S4

Best regards,

Seth

From eugen at leitl.org  Fri Nov 22 11:39:11 2013
From: eugen at leitl.org (Eugen Leitl)
Date: Fri, 22 Nov 2013 12:39:11 +0100
Subject: Super Computer 13: GPUs would make terrific network monitors
Message-ID: <20131122113911.GN5661@leitl.org>


http://www.networkworld.com/news/2013/112113-sc13-gpus-would-make-terrific-276246.html

Super Computer 13: GPUs would make terrific network monitors

An off-the-shelf Nvidia GPU is able to easily capture all the traffic of a
10Gbps network, Fermilab research finds

By Joab Jackson, IDG News Service November 21, 2013 02:50 PM ET

Sponsored by: IDG News Service - A network researcher at the U.S. Department
of Energy's Fermi National Accelerator Laboratory has found a potential new
use for graphics processing units -- capturing data about network traffic in
real time.

GPU-based network monitors could be uniquely qualified to keep pace with all
the traffic flowing through networks running at 10Gbps (gigabits per second)
or more, said Fermilab's Wenji Wu.

Wenji presented his work as part of a poster series of new research at the SC
2013 supercomputing conference this week in Denver.

Network analysis tools face an extreme challenge in keeping up with all of
the traffic of today's larger networks, he said. Adding to the strain,
network administrators increasingly expect to inspect operational data in
real-time, as it is happening.

For processing, today's commercial monitoring appliances typically rely on
either standard x86 processors or customer ASICs (application specific
integrated circuits).

Both architectures have their limitations, Wenji noted. CPUs don't have the
memory bandwidth or the compute power to keep pace with the largest networks
in real time. As a result, they can drop packets.

ASICs can have sufficient memory bandwidth and compute power for the task,
but their custom architecture is difficult, and expensive, to program. Nor do
they offer the ability to split processing duties into parallel tasks, which
is becoming increasingly necessary for watching high-speed networks.

GPUs can offer all of these capabilities, Wenji said. They have "a great
parallel execution model," he said, noting that they offer high memory
bandwidth, easy programmability, and can split the packet capturing process
across multiple cores.

As their name implies, GPUs were originally designed to render graphics on
computer screens. Their architectures, consisting of many processor cores
working in tandem, also make them useful as general coprocessors good at
inherently parallelizable tasks.

In the latest Top500 ranking of the world's most powerful supercomputers, 38
machines used Nvidia GPUs to boost their output.

The task of monitoring networks requires reading all the data packets as they
cross the network, which "requires a lot of data parallelism," Wenji said.

Wenji has built a prototype at Fermilab to demonstrate the feasibility of a
GPU-based network monitor, using a Nvidia M2070 GPU and an off-the-shelf NIC
(network interface card) to capture network traffic. The system could easily
be expanded with additional GPUs, he said.

In this setup, Wenji found that packet processing could be considerably
accelerated through GPUs. Compared to a single core CPU-based network
monitor, the GPU-based system was able to speed performance by as much as 17
times. Compared to a six core CPU, the speed up from using a GPU was
threefold.

Makers of commercial network appliances could use GPUs to boost their
devices' line rates, as well as cut development costs by using pre-existing
GPU programming models such as the Nvidia CUDA (Compute Unified Device
Architecture) framework, Wenji said.

Joab Jackson covers enterprise software and general technology breaking news
for The IDG News Service. Follow Joab on Twitter at @Joab_Jackson. Joab's
e-mail address is Joab_Jackson at idg.com

The IDG News Service is a Network World affiliate.


From geier at geier.ne.tz  Fri Nov 22 11:55:54 2013
From: geier at geier.ne.tz (Frank Habicht)
Date: Fri, 22 Nov 2013 14:55:54 +0300
Subject: prefix filtering per IRR - practices
Message-ID: <528F464A.5010907@geier.ne.tz>

Hi,

I have a question regarding what's the most common practice [1]
for transit ASs to filter prefixes from their BGP customers
when using IRR data. (which of course everyone does...)

Would many/most/all/none :
a) accept only the prefixes listed in route objects
or
b) accept these and anything "upto /24" (or "le 24")

I was hoping / assuming the latter but I start getting a different impression.
Yep, and apart from the current status, the tendency would be of interest.

Thanks,
Frank

[1] after "my network, my rules"


From rps at maine.edu  Fri Nov 22 12:35:06 2013
From: rps at maine.edu (Ray Soucy)
Date: Fri, 22 Nov 2013 07:35:06 -0500
Subject: Meraki
In-Reply-To: <4FFF777C-07B6-49FD-A87F-52156C9069FC@dds.nl>
References: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>
 <4FFF777C-07B6-49FD-A87F-52156C9069FC@dds.nl>
Message-ID: <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com>

FWIW, I picked up a UniFi 3-pack of APs and built up a controller VM using
Ubuntu Server LTS and the beta multi-site controller code over the past
week.

I'm very impressed so far, it doesn't have all the bells and whistles of
Cisco setup, sure, but I'm pretty shocked at the level of functionality
here and the ease of having APs use an off-site controller (they all phone
home over TCP so no VPN or port forwarding is required).

I'm interested in UniFi mainly for remote Libraries that don't have any IT
staff but need a little more than a router from Best Buy.

Also of interest is the EdgeMAX line.  I also got the EdgeRouter LITE for
testing this past week after finding out it runs a fork of Vyatta (EdgeOS)
and is developed by former Vyatta employees.  For a sub- $100 device ...
very impressive.

Pricing just popped up for the new EdgeRouter PRO last night and I was
pretty blown away:

$360

For a device with 2 SFP ports, and 2M PPS.  That is music to my ears since
we do a lot of dark fiber around the state even for smaller locations.  I'm
pretty excited to get one of these and see how they perform.

I wish I would have bothered looking at Ubiquiti sooner, really.  I'm a
little embarrassed to admit I initially wrote them off because the prices
were so low, but the more I look into these guys the more I like them.

I feel like I'm at the risk for becoming a UBNT fanboy.  Does anyone have
any qualified horror stories about EdgeMAX or UniFi?  Everything I've been
able to find has been for nonsense configurations like complaining about
trying to to OSPF over WiFi ... Who does that?






On Fri, Nov 22, 2013 at 1:34 AM, Seth Mos <seth.mos at dds.nl> wrote:

>
> Op 22 nov 2013, om 06:37 heeft Jay Ashworth het volgende geschreven:
>
> > ----- Original Message -----
> > Anecdote:
> >
> > My local IHOP finally managed to get Wifi internet access in the
> restaurant.
> >
> > For reasons unknown to me, it's a Meraki box, backhauled *over T-mobile*.
> >
> > That's just as unpleasant as you'd think it would be, And More!
> >
> > Both the wifi and 3G (yes, 3G) boxes lock up on a fairly regular basis,
> > requiring a power cycle, which, generally, they'll only do because I've
> > been eating there for 20 years, and they trust me when I ask them to.
> >
> > I can't say whether this provides any illumination on the rest of their
> > product line, but...
>
> To compound matters, i'd go as far as to say that any wireless solution on
> 2.4Ghz isn't really a wireless solution. It's just not feasible anymore in
> 2013, there is just *so much* interference from everything using the
> unlicensed 2.4Ghz band that it's own success is it's greatest downfall.
>
> Reliable wireless isn't (to use the famous war quote "friendly fire isn't")
>
> For whatever reasons, whomever I talk to they all tell me that <ISP here>
> sucks, and if I ask further if they are using the wireless thingamabob that
> the ISP shipped them, they says yes. So, that's about right then.
>
> I've been using a PCengines.ch Alix router for years now (AMD Geode, x86,
> 256MB ram, CF) with a cable modem in bridge mode with seperate dual band
> access points in the places where I need them (living room, attic office)
> and I can't say that my experiences with the <ISP here> mesh with theirs.
>
> Anyhow, if you are going to deploy wireless, make sure to use dual band,
> and name the 2.4Ghz SSID "internet" and the 5Ghz SSID "faster-internet".
> You'll see people having a heck of a better time. Social engineering works
> :)
>
> When we chose the Ubiquity wireless kit we could deploy twice as many APs
> for the same price of one of the other APs. This effectively means we have
> a very dense wireless network that covers the entire building, and lot's of
> kit that can actually see and use the 5Ghz band.
>
> Setup was super easy, I added a unifi DNS name that points to my unifi
> controller host and I get a email that a new AP is ready to be put into
> service. Having a local management host instead of some cloud was a hard
> requirement. I also like that I can just "apt-get update; apt-get upgrade"
> the software. By using DNS remote deployment was super easy too, send the
> unit off and let them plug it in, it then comes onto the network and
> registers itself.
>
> I believe every current Apple iDevice currently supports the 5Ghz band,
> and all the Dell gear we purchase also comes ordered with it. Heck, even my
> 2011 Sony Xperia T has 5Ghz wireless now, as do the current Samsung Galaxy
> S3, S4
>
> Best regards,
>
> Seth
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

From crogers at inerail.net  Fri Nov 22 16:57:04 2013
From: crogers at inerail.net (Chris Rogers)
Date: Fri, 22 Nov 2013 11:57:04 -0500
Subject: prefix filtering per IRR - practices
In-Reply-To: <528F464A.5010907@geier.ne.tz>
References: <528F464A.5010907@geier.ne.tz>
Message-ID: <CAAzL0oH1Ngk6x6JENVAMBGRzRk_XA8DY6JiJeJRGaA-KYqH+Vw@mail.gmail.com>

>From my experience, networks that are capable of filtering from IRR objects
generally filter for exact routes, meaning no "le 24". While I've always
found networks to be set in their ways, I know some people that have
managed to get their filters changed to allow longer prefixes without
needing additional objects.

But ultimately, it does help prevent the leaking of internal routes.

-Chris

On Fri, Nov 22, 2013 at 6:55 AM, Frank Habicht <geier at geier.ne.tz> wrote:

> Hi,
>
> I have a question regarding what's the most common practice [1]
> for transit ASs to filter prefixes from their BGP customers
> when using IRR data. (which of course everyone does...)
>
> Would many/most/all/none :
> a) accept only the prefixes listed in route objects
> or
> b) accept these and anything "upto /24" (or "le 24")
>
> I was hoping / assuming the latter but I start getting a different
> impression.
> Yep, and apart from the current status, the tendency would be of interest.
>
> Thanks,
> Frank
>
> [1] after "my network, my rules"
>
>

From m.hallgren at free.fr  Fri Nov 22 17:37:21 2013
From: m.hallgren at free.fr (Michael Hallgren)
Date: Fri, 22 Nov 2013 18:37:21 +0100
Subject: prefix filtering per IRR - practices
In-Reply-To: <CAAzL0oH1Ngk6x6JENVAMBGRzRk_XA8DY6JiJeJRGaA-KYqH+Vw@mail.gmail.com>
References: <528F464A.5010907@geier.ne.tz>
 <CAAzL0oH1Ngk6x6JENVAMBGRzRk_XA8DY6JiJeJRGaA-KYqH+Vw@mail.gmail.com>
Message-ID: <528F9651.3050704@free.fr>

Le 22/11/2013 17:57, Chris Rogers a ?crit :
> From my experience, networks that are capable of filtering from IRR objects
> generally filter for exact routes, meaning no "le 24". 

Hi,

Are you sure? My experience is, with a small number of exceptions,
that "le 24" ('route' or 'route-set,' sometimes in relation with "is in
AS-set of peer") is an often used policy. Maybe it depends on what
kind of networks one's looking at? 

Cheers,
mh

> While I've always
> found networks to be set in their ways, I know some people that have
> managed to get their filters changed to allow longer prefixes without
> needing additional objects.
>
> But ultimately, it does help prevent the leaking of internal routes.
>
> -Chris
>
> On Fri, Nov 22, 2013 at 6:55 AM, Frank Habicht <geier at geier.ne.tz> wrote:
>
>> Hi,
>>
>> I have a question regarding what's the most common practice [1]
>> for transit ASs to filter prefixes from their BGP customers
>> when using IRR data. (which of course everyone does...)
>>
>> Would many/most/all/none :
>> a) accept only the prefixes listed in route objects
>> or
>> b) accept these and anything "upto /24" (or "le 24")
>>
>> I was hoping / assuming the latter but I start getting a different
>> impression.
>> Yep, and apart from the current status, the tendency would be of interest.
>>
>> Thanks,
>> Frank
>>
>> [1] after "my network, my rules"
>>
>>



From wbailey at satelliteintelligencegroup.com  Fri Nov 22 17:51:34 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Fri, 22 Nov 2013 17:51:34 +0000
Subject: Meraki
In-Reply-To: <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com>
References: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>
 <4FFF777C-07B6-49FD-A87F-52156C9069FC@dds.nl>,
 <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com>
Message-ID: <g0tfgygcqe8lqna5xfhga0p0.1385142629389@email.android.com>

Read the unifi forums (I was pretty active there when I was testing unifi controller beta).

If that doesn't cure your fanboy feelings, you are doomed.


Sent from my Mobile Device.


-------- Original message --------
From: Ray Soucy <rps at maine.edu>
Date: 11/22/2013 3:37 AM (GMT-09:00)
To: Seth Mos <seth.mos at dds.nl>
Cc: NANOG <nanog at nanog.org>
Subject: Re: Meraki


FWIW, I picked up a UniFi 3-pack of APs and built up a controller VM using
Ubuntu Server LTS and the beta multi-site controller code over the past
week.

I'm very impressed so far, it doesn't have all the bells and whistles of
Cisco setup, sure, but I'm pretty shocked at the level of functionality
here and the ease of having APs use an off-site controller (they all phone
home over TCP so no VPN or port forwarding is required).

I'm interested in UniFi mainly for remote Libraries that don't have any IT
staff but need a little more than a router from Best Buy.

Also of interest is the EdgeMAX line.  I also got the EdgeRouter LITE for
testing this past week after finding out it runs a fork of Vyatta (EdgeOS)
and is developed by former Vyatta employees.  For a sub- $100 device ...
very impressive.

Pricing just popped up for the new EdgeRouter PRO last night and I was
pretty blown away:

$360

For a device with 2 SFP ports, and 2M PPS.  That is music to my ears since
we do a lot of dark fiber around the state even for smaller locations.  I'm
pretty excited to get one of these and see how they perform.

I wish I would have bothered looking at Ubiquiti sooner, really.  I'm a
little embarrassed to admit I initially wrote them off because the prices
were so low, but the more I look into these guys the more I like them.

I feel like I'm at the risk for becoming a UBNT fanboy.  Does anyone have
any qualified horror stories about EdgeMAX or UniFi?  Everything I've been
able to find has been for nonsense configurations like complaining about
trying to to OSPF over WiFi ... Who does that?






On Fri, Nov 22, 2013 at 1:34 AM, Seth Mos <seth.mos at dds.nl> wrote:

>
> Op 22 nov 2013, om 06:37 heeft Jay Ashworth het volgende geschreven:
>
> > ----- Original Message -----
> > Anecdote:
> >
> > My local IHOP finally managed to get Wifi internet access in the
> restaurant.
> >
> > For reasons unknown to me, it's a Meraki box, backhauled *over T-mobile*.
> >
> > That's just as unpleasant as you'd think it would be, And More!
> >
> > Both the wifi and 3G (yes, 3G) boxes lock up on a fairly regular basis,
> > requiring a power cycle, which, generally, they'll only do because I've
> > been eating there for 20 years, and they trust me when I ask them to.
> >
> > I can't say whether this provides any illumination on the rest of their
> > product line, but...
>
> To compound matters, i'd go as far as to say that any wireless solution on
> 2.4Ghz isn't really a wireless solution. It's just not feasible anymore in
> 2013, there is just *so much* interference from everything using the
> unlicensed 2.4Ghz band that it's own success is it's greatest downfall.
>
> Reliable wireless isn't (to use the famous war quote "friendly fire isn't")
>
> For whatever reasons, whomever I talk to they all tell me that <ISP here>
> sucks, and if I ask further if they are using the wireless thingamabob that
> the ISP shipped them, they says yes. So, that's about right then.
>
> I've been using a PCengines.ch Alix router for years now (AMD Geode, x86,
> 256MB ram, CF) with a cable modem in bridge mode with seperate dual band
> access points in the places where I need them (living room, attic office)
> and I can't say that my experiences with the <ISP here> mesh with theirs.
>
> Anyhow, if you are going to deploy wireless, make sure to use dual band,
> and name the 2.4Ghz SSID "internet" and the 5Ghz SSID "faster-internet".
> You'll see people having a heck of a better time. Social engineering works
> :)
>
> When we chose the Ubiquity wireless kit we could deploy twice as many APs
> for the same price of one of the other APs. This effectively means we have
> a very dense wireless network that covers the entire building, and lot's of
> kit that can actually see and use the 5Ghz band.
>
> Setup was super easy, I added a unifi DNS name that points to my unifi
> controller host and I get a email that a new AP is ready to be put into
> service. Having a local management host instead of some cloud was a hard
> requirement. I also like that I can just "apt-get update; apt-get upgrade"
> the software. By using DNS remote deployment was super easy too, send the
> unit off and let them plug it in, it then comes onto the network and
> registers itself.
>
> I believe every current Apple iDevice currently supports the 5Ghz band,
> and all the Dell gear we purchase also comes ordered with it. Heck, even my
> 2011 Sony Xperia T has 5Ghz wireless now, as do the current Samsung Galaxy
> S3, S4
>
> Best regards,
>
> Seth
>



--
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net<http://www.maineren.net>

From alh-ietf at tndh.net  Fri Nov 22 18:18:27 2013
From: alh-ietf at tndh.net (Tony Hain)
Date: Fri, 22 Nov 2013 10:18:27 -0800
Subject: NAT64 and matching identities
In-Reply-To: <CEB29567.39B09%Lee@asgard.org>
References: <20131120133033.3c84120f.gem@rellim.com>
 <CEB29567.39B09%Lee@asgard.org>
Message-ID: <000f01cee7af$3d8da870$b8a8f950$@tndh.net>

Lee Howard wrote:
...
> >> >There is obviously a long tail of ip4 destinations, but nearly all
> >> >of 500 of the Alexa global 500 have ip6 listeners,
> >>
> >> Do you have a data source for that?  I see no indication of IPv6
> >> listeners on 85% of the top sites.
> >
> >A slightly different metric, 44% of USA content available on IPv6:
> >
> >http://6lab.cisco.com/stats/
> 
> Right, weighted by DNS queries.
> Compare to http://www.vyncke.org/ipv6status/detailed.php?country=us
> and http://www.employees.org/~dwing/aaaa-stats/
> 
> Not equivalent to "nearly all of Alexa 500."

Using a derivative of Dan Wings code from a couple of years back I get:

The top 5 websites: AAAA records and IPv6 connectivity
           count with A:        5   (100.000%)
        count with AAAA:        4   ( 80.000%)
Of the 4 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:        4   (100.000%)

The top 10 websites: AAAA records and IPv6 connectivity
           count with A:       10   (100.000%)
        count with AAAA:        6   ( 60.000%)
Of the 6 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:        6   (100.000%)

The top 25 websites: AAAA records and IPv6 connectivity
           count with A:       25   (100.000%)
        count with AAAA:       10   ( 40.000%)
Of the 10 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:       10   (100.000%)

The top 50 websites: AAAA records and IPv6 connectivity
           count with A:       50   (100.000%)
        count with AAAA:       21   ( 42.000%)
Of the 21 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:       21   (100.000%)

The top 100 websites: AAAA records and IPv6 connectivity
           count with A:       98   ( 98.000%)
        count with AAAA:       30   ( 30.000%)
Of the 30 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:       30   (100.000%)

The top 250 websites: AAAA records and IPv6 connectivity
           count with A:      248   ( 99.200%)
        count with AAAA:       56   ( 22.400%)
Of the 56 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:       56   (100.000%)

The top 500 websites: AAAA records and IPv6 connectivity
           count with A:      494   ( 98.800%)
        count with AAAA:       91   ( 18.200%)
Of the 91 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:       91   (100.000%)

The top 1000 websites: AAAA records and IPv6 connectivity
           count with A:      990   ( 99.000%)
        count with AAAA:      132   ( 13.200%)
Of the 132 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:      132   (100.000%)

The top 2500 websites: AAAA records and IPv6 connectivity
           count with A:     2479   ( 99.160%)
        count with AAAA:      216   (  8.640%)
Of the 216 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:      214   ( 99.074%)

The top 5000 websites: AAAA records and IPv6 connectivity
           count with A:     4959   ( 99.220%)
        count with AAAA:      354   (  7.083%)
Of the 354 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:      347   ( 98.023%)

The top 10000 websites: AAAA records and IPv6 connectivity
           count with A:     9918   ( 99.230%)
        count with AAAA:      600   (  6.003%)
Of the 600 hosts with AAAA records, testing connectivity to TCP/80:
     count with IPv6 ok:      575   ( 95.833%)

Original code developed by dwing at employees.org.
manual run by tony on arabian.tndh.net using ./IPv6-check .
on Fri Nov 22 09:48:17 PST 2013  (elapsed: 00:08:33, t: 15).
Top 10000 websites based on Alexa top-1m.csv.




From cscora at apnic.net  Fri Nov 22 18:33:12 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 23 Nov 2013 04:33:12 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201311221833.rAMIXCoW023639@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, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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

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

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

Routing Table Report   04:00 +10GMT Sat 23 Nov, 2013

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


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


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


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


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


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


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


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


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


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


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



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


End of report


From owen at delong.com  Fri Nov 22 19:57:22 2013
From: owen at delong.com (Owen DeLong)
Date: Fri, 22 Nov 2013 11:57:22 -0800
Subject: NAT64 and matching identities
In-Reply-To: <000f01cee7af$3d8da870$b8a8f950$@tndh.net>
References: <20131120133033.3c84120f.gem@rellim.com>
 <CEB29567.39B09%Lee@asgard.org> <000f01cee7af$3d8da870$b8a8f950$@tndh.net>
Message-ID: <5FC31B89-6546-4C51-B40C-1714B221097D@delong.com>

I question how one can have a top 100 website without an A record.

I am inclined to believe there is a bug in there somewhere.

Owen

On Nov 22, 2013, at 10:18 AM, Tony Hain <alh-ietf at tndh.net> wrote:

> Lee Howard wrote:
> ...
>>>>> There is obviously a long tail of ip4 destinations, but nearly all
>>>>> of 500 of the Alexa global 500 have ip6 listeners,
>>>> 
>>>> Do you have a data source for that?  I see no indication of IPv6
>>>> listeners on 85% of the top sites.
>>> 
>>> A slightly different metric, 44% of USA content available on IPv6:
>>> 
>>> http://6lab.cisco.com/stats/
>> 
>> Right, weighted by DNS queries.
>> Compare to http://www.vyncke.org/ipv6status/detailed.php?country=us
>> and http://www.employees.org/~dwing/aaaa-stats/
>> 
>> Not equivalent to "nearly all of Alexa 500."
> 
> Using a derivative of Dan Wings code from a couple of years back I get:
> 
> The top 5 websites: AAAA records and IPv6 connectivity
>           count with A:        5   (100.000%)
>        count with AAAA:        4   ( 80.000%)
> Of the 4 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:        4   (100.000%)
> 
> The top 10 websites: AAAA records and IPv6 connectivity
>           count with A:       10   (100.000%)
>        count with AAAA:        6   ( 60.000%)
> Of the 6 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:        6   (100.000%)
> 
> The top 25 websites: AAAA records and IPv6 connectivity
>           count with A:       25   (100.000%)
>        count with AAAA:       10   ( 40.000%)
> Of the 10 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:       10   (100.000%)
> 
> The top 50 websites: AAAA records and IPv6 connectivity
>           count with A:       50   (100.000%)
>        count with AAAA:       21   ( 42.000%)
> Of the 21 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:       21   (100.000%)
> 
> The top 100 websites: AAAA records and IPv6 connectivity
>           count with A:       98   ( 98.000%)
>        count with AAAA:       30   ( 30.000%)
> Of the 30 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:       30   (100.000%)
> 
> The top 250 websites: AAAA records and IPv6 connectivity
>           count with A:      248   ( 99.200%)
>        count with AAAA:       56   ( 22.400%)
> Of the 56 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:       56   (100.000%)
> 
> The top 500 websites: AAAA records and IPv6 connectivity
>           count with A:      494   ( 98.800%)
>        count with AAAA:       91   ( 18.200%)
> Of the 91 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:       91   (100.000%)
> 
> The top 1000 websites: AAAA records and IPv6 connectivity
>           count with A:      990   ( 99.000%)
>        count with AAAA:      132   ( 13.200%)
> Of the 132 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:      132   (100.000%)
> 
> The top 2500 websites: AAAA records and IPv6 connectivity
>           count with A:     2479   ( 99.160%)
>        count with AAAA:      216   (  8.640%)
> Of the 216 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:      214   ( 99.074%)
> 
> The top 5000 websites: AAAA records and IPv6 connectivity
>           count with A:     4959   ( 99.220%)
>        count with AAAA:      354   (  7.083%)
> Of the 354 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:      347   ( 98.023%)
> 
> The top 10000 websites: AAAA records and IPv6 connectivity
>           count with A:     9918   ( 99.230%)
>        count with AAAA:      600   (  6.003%)
> Of the 600 hosts with AAAA records, testing connectivity to TCP/80:
>     count with IPv6 ok:      575   ( 95.833%)
> 
> Original code developed by dwing at employees.org.
> manual run by tony on arabian.tndh.net using ./IPv6-check .
> on Fri Nov 22 09:48:17 PST 2013  (elapsed: 00:08:33, t: 15).
> Top 10000 websites based on Alexa top-1m.csv.
> 
> 



From Valdis.Kletnieks at vt.edu  Fri Nov 22 20:01:23 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 22 Nov 2013 15:01:23 -0500
Subject: NAT64 and matching identities
In-Reply-To: Your message of "Fri, 22 Nov 2013 10:18:27 -0800."
 <000f01cee7af$3d8da870$b8a8f950$@tndh.net>
References: <20131120133033.3c84120f.gem@rellim.com>
 <CEB29567.39B09%Lee@asgard.org>
 <000f01cee7af$3d8da870$b8a8f950$@tndh.net>
Message-ID: <100205.1385150483@turing-police.cc.vt.edu>

On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:

> The top 100 websites: AAAA records and IPv6 connectivity
>            count with A:       98   ( 98.000%)
>         count with AAAA:       30   ( 30.000%)
> Of the 30 hosts with AAAA records, testing connectivity to TCP/80:
>      count with IPv6 ok:       30   (100.000%)

Statistics whoopsie, or are there actually 2 sites in the top100
that are IPv6-only?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131122/89a9d2d0/attachment.bin>

From joelja at bogus.com  Fri Nov 22 20:12:42 2013
From: joelja at bogus.com (joel jaeggli)
Date: Fri, 22 Nov 2013 12:12:42 -0800
Subject: NAT64 and matching identities
In-Reply-To: <100205.1385150483@turing-police.cc.vt.edu>
References: <20131120133033.3c84120f.gem@rellim.com>
 <CEB29567.39B09%Lee@asgard.org> <000f01cee7af$3d8da870$b8a8f950$@tndh.net>
 <100205.1385150483@turing-police.cc.vt.edu>
Message-ID: <528FBABA.2050401@bogus.com>

On 11/22/13, 12:01 PM, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
> 
>> The top 100 websites: AAAA records and IPv6 connectivity
>>            count with A:       98   ( 98.000%)
>>         count with AAAA:       30   ( 30.000%)
>> Of the 30 hosts with AAAA records, testing connectivity to TCP/80:
>>      count with IPv6 ok:       30   (100.000%)
> 
> Statistics whoopsie, or are there actually 2 sites in the top100
> that are IPv6-only?

IN CNAME ? or is that being accounted for.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131122/ca481895/attachment.bin>

From owen at delong.com  Fri Nov 22 20:16:11 2013
From: owen at delong.com (Owen DeLong)
Date: Fri, 22 Nov 2013 12:16:11 -0800
Subject: NAT64 and matching identities
In-Reply-To: <528FBABA.2050401@bogus.com>
References: <20131120133033.3c84120f.gem@rellim.com>
 <CEB29567.39B09%Lee@asgard.org> <000f01cee7af$3d8da870$b8a8f950$@tndh.net>
 <100205.1385150483@turing-police.cc.vt.edu> <528FBABA.2050401@bogus.com>
Message-ID: <092C0ECE-9114-4BB7-8C50-E273583F8E78@delong.com>

It would be way more than 2 if it were CNAME, methinks.

Owen

On Nov 22, 2013, at 12:12 PM, joel jaeggli <joelja at bogus.com> wrote:

> On 11/22/13, 12:01 PM, Valdis.Kletnieks at vt.edu wrote:
>> On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
>> 
>>> The top 100 websites: AAAA records and IPv6 connectivity
>>>           count with A:       98   ( 98.000%)
>>>        count with AAAA:       30   ( 30.000%)
>>> Of the 30 hosts with AAAA records, testing connectivity to TCP/80:
>>>     count with IPv6 ok:       30   (100.000%)
>> 
>> Statistics whoopsie, or are there actually 2 sites in the top100
>> that are IPv6-only?
> 
> IN CNAME ? or is that being accounted for.
> 
> 
> 



From alh-ietf at tndh.net  Fri Nov 22 21:28:47 2013
From: alh-ietf at tndh.net (Tony Hain)
Date: Fri, 22 Nov 2013 13:28:47 -0800
Subject: NAT64 and matching identities
In-Reply-To: <092C0ECE-9114-4BB7-8C50-E273583F8E78@delong.com>
References: <20131120133033.3c84120f.gem@rellim.com>
 <CEB29567.39B09%Lee@asgard.org> <000f01cee7af$3d8da870$b8a8f950$@tndh.net>
 <100205.1385150483@turing-police.cc.vt.edu> <528FBABA.2050401@bogus.com>
 <092C0ECE-9114-4BB7-8C50-E273583F8E78@delong.com>
Message-ID: <002b01cee7c9$d46bcb40$7d4361c0$@tndh.net>

The only thing it explicitly strips out are dotted-quads, which don't occur
until # 4255. The code makes five passes at getaddrinfo() for IPv4 before
giving up, and then it checks for a leading www and if that exists it strips
it off and does the 5 tries loop again, then later the same process for
IPv6. For the top 100 run:
akamaihd.net                    no IPv4   no IPv6
bp.blogspot.com                 no IPv4   no IPv6

FWIW :::
Dotted-quad's in the top 10,000
4255,92.242.195.24
4665,1.1.1.1
5079,92.242.195.231
6130,1.254.254.254
9518,208.98.30.70

> whois 92.242.195.24
...
netname:        Respina
descr:          BroadBand IP Pool
country:        IR
...
route:          92.242.195.0/24

Respina BroadBand IP Pool in the top 100,000
4255,92.242.195.24
5079,92.242.195.231
10059,92.242.195.233
23912,92.242.195.30
31520,92.242.195.111
35867,92.242.195.235
95233,92.242.195.129


> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Friday, November 22, 2013 12:16 PM
> To: joel jaeggli
> Cc: Valdis.Kletnieks at vt.edu; Tony Hain; NANOG List
> Subject: Re: NAT64 and matching identities
> 
> It would be way more than 2 if it were CNAME, methinks.
> 
> Owen
> 
> On Nov 22, 2013, at 12:12 PM, joel jaeggli <joelja at bogus.com> wrote:
> 
> > On 11/22/13, 12:01 PM, Valdis.Kletnieks at vt.edu wrote:
> >> On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
> >>
> >>> The top 100 websites: AAAA records and IPv6 connectivity
> >>>           count with A:       98   ( 98.000%)
> >>>        count with AAAA:       30   ( 30.000%)
> >>> Of the 30 hosts with AAAA records, testing connectivity to TCP/80:
> >>>     count with IPv6 ok:       30   (100.000%)
> >>
> >> Statistics whoopsie, or are there actually 2 sites in the top100 that
> >> are IPv6-only?
> >
> > IN CNAME ? or is that being accounted for.
> >
> >
> >



From owen at delong.com  Fri Nov 22 21:48:17 2013
From: owen at delong.com (Owen DeLong)
Date: Fri, 22 Nov 2013 13:48:17 -0800
Subject: NAT64 and matching identities
In-Reply-To: <002b01cee7c9$d46bcb40$7d4361c0$@tndh.net>
References: <20131120133033.3c84120f.gem@rellim.com>
 <CEB29567.39B09%Lee@asgard.org> <000f01cee7af$3d8da870$b8a8f950$@tndh.net>
 <100205.1385150483@turing-police.cc.vt.edu> <528FBABA.2050401@bogus.com>
 <092C0ECE-9114-4BB7-8C50-E273583F8E78@delong.com>
 <002b01cee7c9$d46bcb40$7d4361c0$@tndh.net>
Message-ID: <8D53DBA3-A0BC-4944-ACFC-43953B7F2078@delong.com>

So one has to wonder how those names made it into the top 100 list if it?s supposed to be a top 100 web sites, since they are obviously not web sites.
(at least in the case of the two in the top 100)

Owen

On Nov 22, 2013, at 1:28 PM, Tony Hain <alh-ietf at tndh.net> wrote:

> The only thing it explicitly strips out are dotted-quads, which don't occur
> until # 4255. The code makes five passes at getaddrinfo() for IPv4 before
> giving up, and then it checks for a leading www and if that exists it strips
> it off and does the 5 tries loop again, then later the same process for
> IPv6. For the top 100 run:
> akamaihd.net                    no IPv4   no IPv6
> bp.blogspot.com                 no IPv4   no IPv6
> 
> FWIW :::
> Dotted-quad's in the top 10,000
> 4255,92.242.195.24
> 4665,1.1.1.1
> 5079,92.242.195.231
> 6130,1.254.254.254
> 9518,208.98.30.70
> 
>> whois 92.242.195.24
> ...
> netname:        Respina
> descr:          BroadBand IP Pool
> country:        IR
> ...
> route:          92.242.195.0/24
> 
> Respina BroadBand IP Pool in the top 100,000
> 4255,92.242.195.24
> 5079,92.242.195.231
> 10059,92.242.195.233
> 23912,92.242.195.30
> 31520,92.242.195.111
> 35867,92.242.195.235
> 95233,92.242.195.129
> 
> 
>> -----Original Message-----
>> From: Owen DeLong [mailto:owen at delong.com]
>> Sent: Friday, November 22, 2013 12:16 PM
>> To: joel jaeggli
>> Cc: Valdis.Kletnieks at vt.edu; Tony Hain; NANOG List
>> Subject: Re: NAT64 and matching identities
>> 
>> It would be way more than 2 if it were CNAME, methinks.
>> 
>> Owen
>> 
>> On Nov 22, 2013, at 12:12 PM, joel jaeggli <joelja at bogus.com> wrote:
>> 
>>> On 11/22/13, 12:01 PM, Valdis.Kletnieks at vt.edu wrote:
>>>> On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
>>>> 
>>>>> The top 100 websites: AAAA records and IPv6 connectivity
>>>>>          count with A:       98   ( 98.000%)
>>>>>       count with AAAA:       30   ( 30.000%)
>>>>> Of the 30 hosts with AAAA records, testing connectivity to TCP/80:
>>>>>    count with IPv6 ok:       30   (100.000%)
>>>> 
>>>> Statistics whoopsie, or are there actually 2 sites in the top100 that
>>>> are IPv6-only?
>>> 
>>> IN CNAME ? or is that being accounted for.
>>> 
>>> 
>>> 



From cidr-report at potaroo.net  Fri Nov 22 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 22 Nov 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201311222200.rAMM0075000613@wattle.apnic.net>

This report has been generated at Fri Nov 22 21:13:32 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        15-11-13    485585      273250
        16-11-13    484011      273668
        17-11-13    483814      273917
        18-11-13    484111      272263
        19-11-13    484362      272400
        20-11-13    484547      272722
        21-11-13    484317      272975
        22-11-13    483927      273289


AS Summary
         45683  Number of ASes in routing system
         18756  Number of ASes announcing only one prefix
          4209  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      118835968  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 22Nov13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     484535   273295   211240    43.6%   All ASes

AS28573     3392       89     3303    97.4%   NET Servi?os de Comunica??o
                                               S.A.
AS6389      3042       56     2986    98.2%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS17974     2713      173     2540    93.6%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS7029      4209     1739     2470    58.7%   WINDSTREAM - Windstream
                                               Communications Inc
AS22773     2211      158     2053    92.9%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4766      2931      949     1982    67.6%   KIXS-AS-KR Korea Telecom
AS18881     1647       31     1616    98.1%   Global Village Telecom
AS36998     1864      375     1489    79.9%   SDN-MOBITEL
AS18566     2054      566     1488    72.4%   MEGAPATH5-US - MegaPath
                                               Corporation
AS4323      2960     1527     1433    48.4%   TWTC - tw telecom holdings,
                                               inc.
AS7303      1729      470     1259    72.8%   Telecom Argentina S.A.
AS1785      2058      836     1222    59.4%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1792      582     1210    67.5%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS10620     2671     1469     1202    45.0%   Telmex Colombia S.A.
AS7552      1194      139     1055    88.4%   VIETEL-AS-AP Vietel
                                               Corporation
AS22561     1241      221     1020    82.2%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS9829      1544      659      885    57.3%   BSNL-NIB National Internet
                                               Backbone
AS35908      913       91      822    90.0%   VPLSNET - Krypt Technologies
AS7545      2113     1304      809    38.3%   TPG-INTERNET-AP TPG Telecom
                                               Limited
AS18101      982      180      802    81.7%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4808      1144      400      744    65.0%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS8151      1365      637      728    53.3%   Uninet S.A. de C.V.
AS24560     1095      368      727    66.4%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS701       1509      786      723    47.9%   UUNET - MCI Communications
                                               Services, Inc. d/b/a Verizon
                                               Business
AS6983      1295      580      715    55.2%   ITCDELTA - ITC^Deltacom
AS13977      853      144      709    83.1%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS6147       790      108      682    86.3%   Telefonica del Peru S.A.A.
AS4780      1018      348      670    65.8%   SEEDNET Digital United Inc.
AS855        725       56      669    92.3%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS26615      755       87      668    88.5%   Tim Celular S.A.

Total      53809    15128    38681    71.9%   Top 30 total


Possible Bogus Routes

        27.54.116.0/22       AS55452 
        27.54.116.0/24       AS55452 
        27.54.119.0/24       AS55452 
        27.100.7.0/24        AS56096 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        63.247.0.0/19        AS226   LOS-NETTOS-AS - Los Nettos
        63.247.0.0/24        AS27609 
        63.247.1.0/24        AS27609 
        63.247.2.0/24        AS27609 
        63.247.3.0/24        AS27609 
        63.247.4.0/24        AS27609 
        63.247.5.0/24        AS27609 
        63.247.6.0/24        AS27609 
        63.247.7.0/24        AS27609 
        63.247.8.0/24        AS27609 
        63.247.9.0/24        AS27609 
        63.247.10.0/24       AS27609 
        63.247.11.0/24       AS27609 
        63.247.13.0/24       AS27609 
        63.247.14.0/24       AS27609 
        63.247.15.0/24       AS27609 
        63.247.16.0/24       AS27609 
        63.247.17.0/24       AS27609 
        63.247.18.0/24       AS27609 
        63.247.19.0/24       AS27609 
        63.247.20.0/24       AS27609 
        63.247.21.0/24       AS27609 
        63.247.22.0/24       AS27609 
        63.247.23.0/24       AS27609 
        63.247.24.0/24       AS27609 
        63.247.25.0/24       AS27609 
        63.247.26.0/24       AS27609 
        63.247.27.0/24       AS27609 
        63.247.28.0/24       AS27609 
        63.247.29.0/24       AS27609 
        64.25.16.0/23        AS19535 
        64.25.20.0/24        AS19535 
        64.25.21.0/24        AS19535 
        64.25.22.0/24        AS19535 
        64.25.27.0/24        AS7046  RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business
        64.111.0.0/20        AS8039  CCC-ASN-1 - Cinergy Communications
        64.111.160.0/20      AS40551 
        64.111.160.0/24      AS40551 
        64.111.161.0/24      AS40551 
        64.111.162.0/24      AS40551 
        64.111.167.0/24      AS40551 
        64.111.169.0/24      AS40551 
        64.111.170.0/24      AS40551 
        64.111.171.0/24      AS40551 
        64.111.172.0/24      AS40551 
        64.111.173.0/24      AS40551 
        64.111.174.0/24      AS40551 
        64.111.175.0/24      AS40551 
        64.185.224.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.225.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.226.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.227.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.228.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.229.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.230.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.231.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.232.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.233.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.234.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.235.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.236.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.237.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.238.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.239.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.202.48.0/22       AS23380 
        64.202.52.0/23       AS23380 
        64.202.54.0/24       AS23380 
        64.202.55.0/24       AS23380 
        64.202.56.0/22       AS23380 
        64.202.60.0/24       AS23380 
        64.202.61.0/24       AS23380 
        64.202.62.0/24       AS23380 
        64.202.63.0/24       AS23380 
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global
        66.11.112.0/20       AS14572 
        66.55.96.0/23        AS17203 
        66.55.98.0/24        AS17203 
        66.55.99.0/24        AS17203 
        66.55.100.0/22       AS17203 
        66.55.102.0/23       AS17203 
        66.55.104.0/21       AS17203 
        66.180.64.0/21       AS32558 ZEUTER - Zeuter Development Corporation
        66.180.239.0/24      AS35888 
        66.187.240.0/20      AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        66.206.208.0/22      AS23380 
        66.206.211.0/24      AS14288 MPINET - MPInet
        66.206.212.0/24      AS23380 
        66.206.213.0/24      AS14288 MPINET - MPInet
        66.206.214.0/24      AS23380 
        66.206.215.0/24      AS23380 
        66.206.216.0/23      AS14288 MPINET - MPInet
        66.206.218.0/23      AS23380 
        66.206.220.0/22      AS23380 
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.254.160.0/20      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.176.0/21      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.184.0/22      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.188.0/22      AS35916 MULTA-ASN1 - MULTACOM CORPORATION
        67.21.144.0/22       AS174   COGENT Cogent/PSI
        67.21.148.0/22       AS174   COGENT Cogent/PSI
        68.69.96.0/21        AS32986 
        68.69.96.0/24        AS32986 
        68.69.104.0/21       AS32986 
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.19.0.0/19         AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        72.35.224.0/22       AS30097 NUWAVE - NuWave
        72.35.229.0/24       AS30188 TELEVERGENCE - Televergence Solutions Inc.
        72.35.232.0/21       AS6246  AVALONTEL - AvalonTel
        72.44.16.0/20        AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC
        74.112.100.0/22      AS16764 
        74.113.200.0/23      AS46939 
        74.114.52.0/22       AS40818 
        74.114.52.0/23       AS40818 
        74.114.52.0/24       AS40818 
        74.114.53.0/24       AS40818 
        74.114.54.0/23       AS40818 
        74.114.54.0/24       AS40818 
        74.114.55.0/24       AS40818 
        74.114.140.0/22      AS32757 
        74.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        74.118.132.0/22      AS5117  
        91.193.60.0/22       AS3356  LEVEL3 Level 3 Communications
        91.195.66.0/23       AS3356  LEVEL3 Level 3 Communications
        91.197.36.0/22       AS43359 
        91.199.90.0/24       AS44330 
        91.200.188.0/22      AS44016 
        91.207.152.0/24      AS64100 
        91.207.153.0/24      AS64100 
        91.209.115.0/24      AS31103 KEYWEB-AS Keyweb AG
        91.212.54.0/24       AS21409 IKOULA Ikoula Net SAS
        93.190.8.0/24        AS47254 
        93.190.9.0/24        AS47254 
        93.190.10.0/24       AS47254 
        94.158.16.0/22       AS3257  TINET-BACKBONE Tinet SpA
        94.158.20.0/22       AS3257  TINET-BACKBONE Tinet SpA
        94.158.24.0/22       AS3257  TINET-BACKBONE Tinet SpA
        94.158.28.0/22       AS3257  TINET-BACKBONE Tinet SpA
        100.100.0.0/24       AS4847  CNIX-AP China Networks Inter-Exchange
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. 
        103.11.1.0/24        AS9822  AMNET-AU-AP Amnet IT Services Pty Ltd
        103.13.184.0/23      AS58674 
        115.166.130.0/23     AS45423 
        115.166.132.0/24     AS45423 
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        124.64.0.0/10        AS4847  CNIX-AP China Networks Inter-Exchange
        164.40.184.0/24      AS19821 
        164.138.96.0/23      AS58101 
        164.138.96.0/24      AS58101 
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.116.0.0/24       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        174.136.192.0/18     AS14572 
        178.218.240.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.241.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.242.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.243.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.244.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.245.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.246.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.247.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.248.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.249.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.250.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.251.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.252.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.253.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.254.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.255.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA SAS
        190.15.72.0/21       AS15146 CABLEBAHAMAS - Cable Bahamas
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        192.166.32.0/20      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        193.9.59.0/24        AS1257  TELE2
        193.16.106.0/24      AS31539 
        193.22.224.0/20      AS3322  
        193.22.238.0/23      AS6824  HERMES-NETWORK Hermes Telecom International Ltd
        193.33.66.0/23       AS39874 
        193.109.15.0/24      AS12690 MKSNET-AS MKS Autonomous System
        193.164.152.0/24     AS3356  LEVEL3 Level 3 Communications
        193.178.217.0/24     AS20737 
        193.188.252.0/24     AS8697  JTC-AS8697 Jordan Telecommunications Company
        193.202.8.0/21       AS3322  
        193.254.218.0/23     AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC
        194.50.82.0/24       AS16276 OVH OVH Systems
        194.63.152.0/22      AS3356  LEVEL3 Level 3 Communications
        194.79.48.0/22       AS39117 
        194.113.27.0/24      AS12518 SHLINK SHLINK Internet Service
        194.126.219.0/24     AS34545 
        195.85.239.0/24      AS29324 
        195.114.4.0/23       AS41158 
        195.128.240.0/23     AS21202 DCSNET-AS Bredband2 AB
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA
        195.234.156.0/24     AS25028 
        195.248.240.0/23     AS34169 MEDIA-COM-TYCHY Media-Com Sp. z o.o.
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.58.248.0/21      AS27849 
        201.71.16.0/20       AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.49.33.0/24       AS7657  VODAFONE-NZ-NGN-AS Vodafone NZ Ltd.
        202.58.113.0/24      AS19161 
        202.59.240.0/24      AS17477 MCT-SYDNEY Macquarie Telecom
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.142.219.0/24     AS45149 
        203.191.56.0/21      AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service
        204.9.32.0/24        AS25617 
        204.9.33.0/24        AS25617 
        204.9.34.0/24        AS25617 
        204.9.35.0/24        AS25617 
        204.9.116.0/22       AS30097 NUWAVE - NuWave
        204.10.88.0/21       AS3356  LEVEL3 Level 3 Communications
        204.10.92.0/23       AS30097 NUWAVE - NuWave
        204.10.94.0/23       AS30097 NUWAVE - NuWave
        204.15.208.0/22      AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC
        204.69.144.0/24      AS27283 RJF-INTERNET - Raymond James Financial, Inc.
        204.106.16.0/24      AS4323  TWTC - tw telecom holdings, inc.
        204.115.110.0/23     AS53709 
        204.187.11.0/24      AS51113 ELEKTA-AS Elekta
        204.225.173.0/24     AS6407  PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
        205.159.44.0/24      AS40157 ADESA-CORP-AS - ADESA Corp
        205.207.66.0/24      AS15290 ALLST-15290 - Allstream Corp.
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network
        205.236.71.0/24      AS852   ASN852 - TELUS Communications Inc.
        206.81.112.0/20      AS32618 ADKNO-KC - Adknowledge, Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        206.221.176.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.177.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.178.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.179.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.180.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.181.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.182.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.183.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.184.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.185.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.186.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.187.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.188.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.189.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.190.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.191.0/24     AS27431 JTLNET - JTL Networks Inc.
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        207.254.128.0/21     AS30689 FLOW-NET - FLOW
        207.254.128.0/24     AS30689 FLOW-NET - FLOW
        207.254.136.0/21     AS30689 FLOW-NET - FLOW
        208.66.120.0/22      AS32757 
        208.68.180.0/22      AS4323  TWTC - tw telecom holdings, inc.
        208.74.224.0/22      AS174   COGENT Cogent/PSI
        208.75.152.0/21      AS32146 
        208.76.20.0/24       AS31812 
        208.76.21.0/24       AS31812 
        208.77.164.0/24      AS22659 
        208.77.165.0/24      AS22659 
        208.77.166.0/24      AS22659 
        208.77.167.0/24      AS22659 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.84.232.0/24      AS33131 
        208.84.234.0/24      AS33131 
        208.84.237.0/24      AS33131 
        208.84.238.0/24      AS33131 
        208.85.116.0/23      AS25956 ALPHEUS - Alpheus Data Services, L.L.C.
        208.85.212.0/22      AS32618 ADKNO-KC - Adknowledge, Inc.
        208.89.32.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.33.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.34.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.35.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.90.64.0/22       AS16415 PRCNET-DOM - Precision Response Corporation
        208.91.72.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.73.0/24       AS65160 -Private Use AS-
        208.91.76.0/23       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        208.91.164.0/22      AS46099 
        208.92.224.0/22      AS32757 
        209.161.96.0/20      AS8039  CCC-ASN-1 - Cinergy Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.193.112.0/20     AS209   ASN-QWEST-US NOVARTIS-DMZ-US
        209.209.51.0/24      AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.
        209.209.64.0/20      AS46851 IPARADIGMS - iParadigms, LLC
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.234.112.0/23     AS32252 
        209.234.114.0/23     AS32252 
        209.234.116.0/24     AS32252 
        209.234.117.0/24     AS32252 
        209.234.118.0/24     AS32252 
        209.234.119.0/24     AS32252 
        209.234.120.0/24     AS32252 
        209.234.121.0/24     AS32252 
        209.234.122.0/24     AS32252 
        212.119.32.0/19      AS12550 
        213.184.64.0/24      AS13071 
        213.184.65.0/24      AS13071 
        213.184.66.0/24      AS13071 
        213.184.67.0/24      AS13071 
        213.184.68.0/24      AS13071 
        213.184.69.0/24      AS13071 
        213.184.70.0/24      AS13071 
        213.184.71.0/24      AS13071 
        213.184.72.0/24      AS13071 
        213.184.73.0/24      AS13071 
        213.184.74.0/24      AS13071 
        213.184.75.0/24      AS13071 
        213.184.76.0/24      AS13071 
        213.184.77.0/24      AS13071 
        213.184.78.0/24      AS13071 
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.14.64.0/20       AS14728 
        216.146.0.0/19       AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.170.96.0/24      AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.101.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.104.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.105.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.234.128.0/22     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.139.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Nov 22 22:00:02 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 22 Nov 2013 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201311222200.rAMM02IR000624@wattle.apnic.net>

BGP Update Report
Interval: 14-Nov-13 -to- 21-Nov-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS7545            79543  2.7%      37.5 -- TPG-INTERNET-AP TPG Telecom Limited
 2 - AS30693           49031  1.7%      91.1 -- SERVERHUB-PHOENIX - Eonix Corporation
 3 - AS8402            40599  1.4%      19.4 -- CORBINA-AS OJSC "Vimpelcom"
 4 - AS9829            39167  1.3%      25.4 -- BSNL-NIB National Internet Backbone
 5 - AS4538            32376  1.1%      59.1 -- ERX-CERNET-BKB China Education and Research Network Center
 6 - AS7029            30570  1.0%       7.2 -- WINDSTREAM - Windstream Communications Inc
 7 - AS28573           24608  0.8%       7.1 -- NET Servi?os de Comunica??o S.A.
 8 - AS13118           23281  0.8%     529.1 -- ASN-YARTELECOM OJSC Rostelecom
 9 - AS29990           22641  0.8%     754.7 -- ASN-APPNEXUS - AppNexus, Inc
10 - AS38457           21312  0.7%     234.2 -- HNS-AS-AP Honesty Net Solution (I) Pvt Ltd
11 - AS36753           19597  0.7%    6532.3 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc.
12 - AS15003           19508  0.7%      22.6 -- NOBIS-TECH - Nobis Technology Group, LLC
13 - AS35873           18792  0.6%    1708.4 -- MOVE-NETWORKS - Move Networks, inc.
14 - AS17974           18608  0.6%       6.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
15 - AS4775            18460  0.6%     142.0 -- GLOBE-TELECOM-AS Globe Telecoms
16 - AS27738           18250  0.6%      31.7 -- Ecuadortelecom S.A.
17 - AS11976           15374  0.5%      75.4 -- FIDN - Fidelity Communication International Inc.
18 - AS4323            15282  0.5%       5.1 -- TWTC - tw telecom holdings, inc.
19 - AS36998           14333  0.5%       7.7 -- SDN-MOBITEL
20 - AS3               14294  0.5%    3394.0 -- RAFFEL-INTERNET Raffel Internet B.V.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS36753           19597  0.7%    6532.3 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc.
 2 - AS57130           11844  0.4%    3948.0 -- SECPRAL-AS Secpral COM SRL
 3 - AS62431            2000  0.1%    2000.0 -- NCSC-IE-AS National Cyber Security Centre
 4 - AS35873           18792  0.6%    1708.4 -- MOVE-NETWORKS - Move Networks, inc.
 5 - AS54465            7528  0.2%    1505.6 -- QPM-AS-1 - QuickPlay Media Inc.
 6 - AS3                1269  0.0%    3453.0 -- RAFFEL-INTERNET Raffel Internet B.V.
 7 - AS6775             7181  0.2%    1196.8 -- BACKBONE_EHF_EUROPE Backbone ehf
 8 - AS7202             8622  0.3%     862.2 -- FAMU - Florida A & M University
 9 - AS49742             827  0.0%     827.0 -- IWT-NETWORK LLC "Iwt" Company
10 - AS57851             771  0.0%     771.0 -- GENESIS-HOUSING-ASSOCIATION-LIMITED Genesis Housing Association Limited
11 - AS29990           22641  0.8%     754.7 -- ASN-APPNEXUS - AppNexus, Inc
12 - AS52355            1343  0.1%     671.5 -- Jalasoft Corp.
13 - AS37367             667  0.0%     667.0 -- CALLKEY
14 - AS11947            3186  0.1%     637.2 -- Cablenett Limited
15 - AS57201             578  0.0%     578.0 -- EDF-AS Estonian Defence Forces
16 - AS13118           23281  0.8%     529.1 -- ASN-YARTELECOM OJSC Rostelecom
17 - AS37453            7206  0.2%     514.7 -- VODACOM-CONGO
18 - AS3               14294  0.5%    3394.0 -- RAFFEL-INTERNET Raffel Internet B.V.
19 - AS22688             855  0.0%     427.5 -- DOLGENCORP - Dollar General Corporation
20 - AS50337            1230  0.0%     410.0 -- TETTAS-AS TETTAS SRL


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 109.161.64.0/20   23044  0.7%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 103.243.220.0/22  22568  0.7%   AS29990 -- ASN-APPNEXUS - AppNexus, Inc
 3 - 8.20.2.0/24       18763  0.6%   AS35873 -- MOVE-NETWORKS - Move Networks, inc.
 4 - 194.9.23.0/24     11835  0.4%   AS57130 -- SECPRAL-AS Secpral COM SRL
 5 - 12.68.46.0/24      9850  0.3%   AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc.
 6 - 64.240.174.0/24    9745  0.3%   AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc.
 9 - 14.202.160.0/22    8351  0.3%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited
10 - 67.210.190.0/23    7834  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
11 - 206.152.15.0/24    7522  0.2%   AS54465 -- QPM-AS-1 - QuickPlay Media Inc.
12 - 192.58.232.0/24    7476  0.2%   AS6629  -- NOAA-AS - NOAA
13 - 79.134.225.0/24    7093  0.2%   AS6775  -- BACKBONE_EHF_EUROPE Backbone ehf
14 - 38.87.227.0/24     6937  0.2%   AS37453 -- VODACOM-CONGO
15 - 220.244.72.0/21    6858  0.2%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited
16 - 67.210.188.0/23    6746  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
17 - 110.175.88.0/22    5507  0.2%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited
18 - 220.244.0.0/22     5445  0.2%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited
19 - 37.0.16.0/22       4828  0.1%   AS35467 -- DCF-AS DataCenter Fryslan AS
20 - 37.0.20.0/22       4818  0.1%   AS35467 -- DCF-AS DataCenter Fryslan AS

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From alh-ietf at tndh.net  Fri Nov 22 23:50:00 2013
From: alh-ietf at tndh.net (Tony Hain)
Date: Fri, 22 Nov 2013 15:50:00 -0800
Subject: NAT64 and matching identities
In-Reply-To: <8D53DBA3-A0BC-4944-ACFC-43953B7F2078@delong.com>
References: <20131120133033.3c84120f.gem@rellim.com>
 <CEB29567.39B09%Lee@asgard.org> <000f01cee7af$3d8da870$b8a8f950$@tndh.net>
 <100205.1385150483@turing-police.cc.vt.edu> <528FBABA.2050401@bogus.com>
 <092C0ECE-9114-4BB7-8C50-E273583F8E78@delong.com>
 <002b01cee7c9$d46bcb40$7d4361c0$@tndh.net>
 <8D53DBA3-A0BC-4944-ACFC-43953B7F2078@delong.com>
Message-ID: <003801cee7dd$8ee20990$aca61cb0$@tndh.net>

Someone from Alexa really needs to answer how that list is created because
their web site discussion is way too hand-wavy, but given that neither of
those appear to be currently valid names, and 1.1.1.1 is on the list at all,
there must be some measure of cross link and redirection occurrences. For
the entire top-1m, I show today's file has 2815 as dotted-quad. In the top
50,000 there are 1790 with "no IPv4   no IPv6".  Clearly they don't bother
to prune the list for validity. ~4% of the next 25,000 names are dead
(50,000-75,000), and one can only guess that as you get further down the
list the percentage of dead names will continue to go up. I have a full 1M
run in process, but would not count on it completing before Monday.

Just to add a level of 'extra effort' to the process, I increased the number
of attempts to 10, and the time between attempts to 10 seconds. With that,
dead names in the top 1000:
akamaihd.net                    no IPv4   no IPv6
bp.blogspot.com                 no IPv4   no IPv6
delta-search.com                no IPv4   no IPv6
bannersdontwork.com             no IPv4   no IPv6
cloudfront.net                  no IPv4   no IPv6
doorblog.jp                     no IPv4   no IPv6
uimserv.net                     no IPv4   no IPv6
linksynergy.com                 no IPv4   no IPv6
lipixeltrack.com                no IPv4   no IPv6
australianbrewingcompany.com    no IPv4   no IPv6
searchfun.in                    no IPv4   no IPv6
greatappsdownload.com           no IPv4   no IPv6
klikbca.com                     no IPv4   no IPv6
jobfindgold.info                no IPv4   no IPv6
adnxs.com                       no IPv4   no IPv6
rakuten.ne.jp                   no IPv4   no IPv6
sweetpacks-search.com           no IPv4   no IPv6
yomiuri.co.jp                   no IPv4   no IPv6
incredibar-search.com           no IPv4   no IPv6
searchgol.com                   no IPv4   no IPv6
livedoor.biz                    no IPv4   no IPv6
workercn.cn                     no IPv4   no IPv6

FWIW: in the top 50,000, I show 1525 "has IPv4  has IPv6" &  0  "no IPv4
has IPv6". In other words, there are more dead names than there are AAAA
records, and there are not any IPv6-only sites in that group.

Tony


> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Friday, November 22, 2013 1:48 PM
> To: Tony Hain
> Cc: joel jaeggli; Valdis.Kletnieks at vt.edu; NANOG List
> Subject: Re: NAT64 and matching identities
> 
> So one has to wonder how those names made it into the top 100 list if it's
> supposed to be a top 100 web sites, since they are obviously not web
sites.
> (at least in the case of the two in the top 100)
> 
> Owen
> 
> On Nov 22, 2013, at 1:28 PM, Tony Hain <alh-ietf at tndh.net> wrote:
> 
> > The only thing it explicitly strips out are dotted-quads, which don't
> > occur until # 4255. The code makes five passes at getaddrinfo() for
> > IPv4 before giving up, and then it checks for a leading www and if
> > that exists it strips it off and does the 5 tries loop again, then
> > later the same process for IPv6. For the top 100 run:
> > akamaihd.net                    no IPv4   no IPv6
> > bp.blogspot.com                 no IPv4   no IPv6
> >
> > FWIW :::
> > Dotted-quad's in the top 10,000
> > 4255,92.242.195.24
> > 4665,1.1.1.1
> > 5079,92.242.195.231
> > 6130,1.254.254.254
> > 9518,208.98.30.70
> >
> >> whois 92.242.195.24
> > ...
> > netname:        Respina
> > descr:          BroadBand IP Pool
> > country:        IR
> > ...
> > route:          92.242.195.0/24
> >
> > Respina BroadBand IP Pool in the top 100,000
> > 4255,92.242.195.24
> > 5079,92.242.195.231
> > 10059,92.242.195.233
> > 23912,92.242.195.30
> > 31520,92.242.195.111
> > 35867,92.242.195.235
> > 95233,92.242.195.129
> >
> >
> >> -----Original Message-----
> >> From: Owen DeLong [mailto:owen at delong.com]
> >> Sent: Friday, November 22, 2013 12:16 PM
> >> To: joel jaeggli
> >> Cc: Valdis.Kletnieks at vt.edu; Tony Hain; NANOG List
> >> Subject: Re: NAT64 and matching identities
> >>
> >> It would be way more than 2 if it were CNAME, methinks.
> >>
> >> Owen
> >>
> >> On Nov 22, 2013, at 12:12 PM, joel jaeggli <joelja at bogus.com> wrote:
> >>
> >>> On 11/22/13, 12:01 PM, Valdis.Kletnieks at vt.edu wrote:
> >>>> On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
> >>>>
> >>>>> The top 100 websites: AAAA records and IPv6 connectivity
> >>>>>          count with A:       98   ( 98.000%)
> >>>>>       count with AAAA:       30   ( 30.000%)
> >>>>> Of the 30 hosts with AAAA records, testing connectivity to TCP/80:
> >>>>>    count with IPv6 ok:       30   (100.000%)
> >>>>
> >>>> Statistics whoopsie, or are there actually 2 sites in the top100
> >>>> that are IPv6-only?
> >>>
> >>> IN CNAME ? or is that being accounted for.
> >>>
> >>>
> >>>



From trelane at trelane.net  Sat Nov 23 06:22:02 2013
From: trelane at trelane.net (Andrew D Kirch)
Date: Sat, 23 Nov 2013 01:22:02 -0500
Subject: AT&T UVERSE Native IPv6, a HOWTO
Message-ID: <5290498A.6040405@trelane.net>

Special thanks to Alexander from AT&T's "Tier-2" dept, though my 
suspicion is that that is not where he works, as he seems exceptionally 
clueful.
Additional thanks to Owen DeLong who finally got me off my ass to 
actually do this, I'll see you in the sky!

Ok, is this core routing? not really, but it's nice to see a major clue 
injection over at AT&T Uverse.  I'm using this to document the MASSIVE 
bureaucratic PITA which is getting native IPv6 on uverse.  You'll start 
from the default service on a 2wire "modem" (for values of modem that 
equate to profanity).  If you have the Motorola NVG589, count yourself 
lucky and skip most of these steps.

  Abandon all hope ye who enter here....

Step 1: contact AT&T Uverse support and complain that you need IPv6 
(because we all need it, I in fact do for work).
Step 2: general confusion as the level 1 droid doesn't know what IPv6 
is, politely request to be transferred to tier 2
step 3: you will be told that tier 2 is a paid service, invoke the 
almighty FCC and ask to speak with a supervisor, expect a long hold here.
step 4: you arrive at tier 2, mention that IPv6 won't work on your 2wire 
and that AT&T has broken your protocol 41 tunnel with <insert tunnel 
broker here, usually HE>
step 5: you'll need to get your 2wire replaced with a Motorola NVG589.  
Again you will be threatened with a cost to upgrade, mine was waived due 
to the work requirement.  I'd guess some additional complaining and 
escalation will get this fee waived.  My recollection was it was $100.  
The new modem is good news for quite a few reasons, the 2wire sucks, the 
Motorola sucks significantly less, and has a built in battery backup, 
but mine lacked the battery.
step 6: you'll receive the motorola by mail, or have a tech install it, 
they actually had a tech in my area and I had an AT&T tech at my door in 
less than 20 minutes from when I got off the phone with tier-2 (I about 
died from the shock).
step 7: configure the motorola (192.168.1.254) for passthrough, 
DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna, 
wireless, etc.
Step 8: reboot to push the public IP to your real router.
step 9: head over to the Motorola's home network tab, and in the status 
window you'll see:


    IPv6

Status 	Available
Global IPv6 Address 	2602:306:cddd:xxxx::1/64
Link-local IPv6 Address 	fe80::923e:abff:xxxx:7e40
Router Advertisement Prefix 	2602:306:cddd:xxxx::/64
IPV6 Delegated LAN Prefix 	2602:306:cddd:xxxx::
2602:306:cddd:xxxx::


In reality additional poking leads me to believe AT&T gives you a rather 
generous /60, but how to use it?
step 10: set up dhcpv6, example for mikrotik follows (but should be 
easily convertible to nearly any router):

/ipv6> export
# dec/31/2001 20:26:03 by RouterOS 6.6
# software id = 5F2Y-X73L
#
/ipv6 address
add address=2602:306:cddd:xxxx::1 from-pool=AT&T interface=bridge1
/ipv6 dhcp-client
add add-default-route=yes interface=ether10 pool-name=AT&T

I hope that this is of help to someone.

Andrew


From mehmet at akcin.net  Sat Nov 23 06:25:14 2013
From: mehmet at akcin.net (Mehmet Akcin)
Date: Fri, 22 Nov 2013 22:25:14 -0800
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <5290498A.6040405@trelane.net>
References: <5290498A.6040405@trelane.net>
Message-ID: <5BC3117F-F4E8-42BD-95F6-DB442EE59C80@akcin.net>

Yay! Thank you very much. 

You should write up something to their support forums!

Mehmet

> On Nov 22, 2013, at 22:22, Andrew D Kirch <trelane at trelane.net> wrote:
> 
> Special thanks to Alexander from AT&T's "Tier-2" dept, though my suspicion is that that is not where he works, as he seems exceptionally clueful.
> Additional thanks to Owen DeLong who finally got me off my ass to actually do this, I'll see you in the sky!
> 
> Ok, is this core routing? not really, but it's nice to see a major clue injection over at AT&T Uverse.  I'm using this to document the MASSIVE bureaucratic PITA which is getting native IPv6 on uverse.  You'll start from the default service on a 2wire "modem" (for values of modem that equate to profanity).  If you have the Motorola NVG589, count yourself lucky and skip most of these steps.
> 
> Abandon all hope ye who enter here....
> 
> Step 1: contact AT&T Uverse support and complain that you need IPv6 (because we all need it, I in fact do for work).
> Step 2: general confusion as the level 1 droid doesn't know what IPv6 is, politely request to be transferred to tier 2
> step 3: you will be told that tier 2 is a paid service, invoke the almighty FCC and ask to speak with a supervisor, expect a long hold here.
> step 4: you arrive at tier 2, mention that IPv6 won't work on your 2wire and that AT&T has broken your protocol 41 tunnel with <insert tunnel broker here, usually HE>
> step 5: you'll need to get your 2wire replaced with a Motorola NVG589.  Again you will be threatened with a cost to upgrade, mine was waived due to the work requirement.  I'd guess some additional complaining and escalation will get this fee waived.  My recollection was it was $100.  The new modem is good news for quite a few reasons, the 2wire sucks, the Motorola sucks significantly less, and has a built in battery backup, but mine lacked the battery.
> step 6: you'll receive the motorola by mail, or have a tech install it, they actually had a tech in my area and I had an AT&T tech at my door in less than 20 minutes from when I got off the phone with tier-2 (I about died from the shock).
> step 7: configure the motorola (192.168.1.254) for passthrough, DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna, wireless, etc.
> Step 8: reboot to push the public IP to your real router.
> step 9: head over to the Motorola's home network tab, and in the status window you'll see:
> 
> 
>   IPv6
> 
> Status    Available
> Global IPv6 Address    2602:306:cddd:xxxx::1/64
> Link-local IPv6 Address    fe80::923e:abff:xxxx:7e40
> Router Advertisement Prefix    2602:306:cddd:xxxx::/64
> IPV6 Delegated LAN Prefix    2602:306:cddd:xxxx::
> 2602:306:cddd:xxxx::
> 
> 
> In reality additional poking leads me to believe AT&T gives you a rather generous /60, but how to use it?
> step 10: set up dhcpv6, example for mikrotik follows (but should be easily convertible to nearly any router):
> 
> /ipv6> export
> # dec/31/2001 20:26:03 by RouterOS 6.6
> # software id = 5F2Y-X73L
> #
> /ipv6 address
> add address=2602:306:cddd:xxxx::1 from-pool=AT&T interface=bridge1
> /ipv6 dhcp-client
> add add-default-route=yes interface=ether10 pool-name=AT&T
> 
> I hope that this is of help to someone.
> 
> Andrew
> 


From marine64 at gmail.com  Sat Nov 23 06:57:20 2013
From: marine64 at gmail.com (Brian Henson)
Date: Sat, 23 Nov 2013 01:57:20 -0500
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <5BC3117F-F4E8-42BD-95F6-DB442EE59C80@akcin.net>
References: <5290498A.6040405@trelane.net>
 <5BC3117F-F4E8-42BD-95F6-DB442EE59C80@akcin.net>
Message-ID: <CAE_vMvePu8_G2rkXgOXvRJY_6ui1g_k6XSO03zw_KJ73=xWg4w@mail.gmail.com>

Now if Time Warner Cable would get their act together in Ohio (looks at
them :) )


On Sat, Nov 23, 2013 at 1:25 AM, Mehmet Akcin <mehmet at akcin.net> wrote:

> Yay! Thank you very much.
>
> You should write up something to their support forums!
>
> Mehmet
>
> > On Nov 22, 2013, at 22:22, Andrew D Kirch <trelane at trelane.net> wrote:
> >
> > Special thanks to Alexander from AT&T's "Tier-2" dept, though my
> suspicion is that that is not where he works, as he seems exceptionally
> clueful.
> > Additional thanks to Owen DeLong who finally got me off my ass to
> actually do this, I'll see you in the sky!
> >
> > Ok, is this core routing? not really, but it's nice to see a major clue
> injection over at AT&T Uverse.  I'm using this to document the MASSIVE
> bureaucratic PITA which is getting native IPv6 on uverse.  You'll start
> from the default service on a 2wire "modem" (for values of modem that
> equate to profanity).  If you have the Motorola NVG589, count yourself
> lucky and skip most of these steps.
> >
> > Abandon all hope ye who enter here....
> >
> > Step 1: contact AT&T Uverse support and complain that you need IPv6
> (because we all need it, I in fact do for work).
> > Step 2: general confusion as the level 1 droid doesn't know what IPv6
> is, politely request to be transferred to tier 2
> > step 3: you will be told that tier 2 is a paid service, invoke the
> almighty FCC and ask to speak with a supervisor, expect a long hold here.
> > step 4: you arrive at tier 2, mention that IPv6 won't work on your 2wire
> and that AT&T has broken your protocol 41 tunnel with <insert tunnel broker
> here, usually HE>
> > step 5: you'll need to get your 2wire replaced with a Motorola NVG589.
>  Again you will be threatened with a cost to upgrade, mine was waived due
> to the work requirement.  I'd guess some additional complaining and
> escalation will get this fee waived.  My recollection was it was $100.  The
> new modem is good news for quite a few reasons, the 2wire sucks, the
> Motorola sucks significantly less, and has a built in battery backup, but
> mine lacked the battery.
> > step 6: you'll receive the motorola by mail, or have a tech install it,
> they actually had a tech in my area and I had an AT&T tech at my door in
> less than 20 minutes from when I got off the phone with tier-2 (I about
> died from the shock).
> > step 7: configure the motorola (192.168.1.254) for passthrough,
> DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna,
> wireless, etc.
> > Step 8: reboot to push the public IP to your real router.
> > step 9: head over to the Motorola's home network tab, and in the status
> window you'll see:
> >
> >
> >   IPv6
> >
> > Status    Available
> > Global IPv6 Address    2602:306:cddd:xxxx::1/64
> > Link-local IPv6 Address    fe80::923e:abff:xxxx:7e40
> > Router Advertisement Prefix    2602:306:cddd:xxxx::/64
> > IPV6 Delegated LAN Prefix    2602:306:cddd:xxxx::
> > 2602:306:cddd:xxxx::
> >
> >
> > In reality additional poking leads me to believe AT&T gives you a rather
> generous /60, but how to use it?
> > step 10: set up dhcpv6, example for mikrotik follows (but should be
> easily convertible to nearly any router):
> >
> > /ipv6> export
> > # dec/31/2001 20:26:03 by RouterOS 6.6
> > # software id = 5F2Y-X73L
> > #
> > /ipv6 address
> > add address=2602:306:cddd:xxxx::1 from-pool=AT&T interface=bridge1
> > /ipv6 dhcp-client
> > add add-default-route=yes interface=ether10 pool-name=AT&T
> >
> > I hope that this is of help to someone.
> >
> > Andrew
> >
>
>

From mureninc at gmail.com  Sat Nov 23 06:58:59 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Fri, 22 Nov 2013 22:58:59 -0800
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <5290498A.6040405@trelane.net>
References: <5290498A.6040405@trelane.net>
Message-ID: <CAPKkNb4a4CX4kmhn0H_9BH=Lw6p4-GquYiTo4Hbr1mrtVM1Enw@mail.gmail.com>

On 22 November 2013 22:22, Andrew D Kirch <trelane at trelane.net> wrote:
> Status  Available
> Global IPv6 Address     2602:306:cddd:xxxx::1/64
> Link-local IPv6 Address         fe80::923e:abff:xxxx:7e40
> Router Advertisement Prefix     2602:306:cddd:xxxx::/64
> IPV6 Delegated LAN Prefix       2602:306:cddd:xxxx::
> 2602:306:cddd:xxxx::

I don't believe this is native IPv6; it's probably still their 6rd,
which has, in fact, been live since at least February 2012, i.e. for
close to two years at this point.

http://tu.cnst.su/post/16958139578/at-t-u-verse-6rd-in-santa-clara-county
http://www.tunnelbroker.net/forums/index.php?topic=2293.0

And, yes, AT&T is probably still keeping this whole thing a secret.

C.


From ml at kenweb.org  Sat Nov 23 07:13:20 2013
From: ml at kenweb.org (ML)
Date: Sat, 23 Nov 2013 02:13:20 -0500
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <5290498A.6040405@trelane.net>
References: <5290498A.6040405@trelane.net>
Message-ID: <52905590.5090505@kenweb.org>

On 11/23/2013 1:22 AM, Andrew D Kirch wrote:
> Special thanks to Alexander from AT&T's "Tier-2" dept, though my
> suspicion is that that is not where he works, as he seems
> exceptionally clueful.
> Additional thanks to Owen DeLong who finally got me off my ass to
> actually do this, I'll see you in the sky!
>
> Ok, is this core routing? not really, but it's nice to see a major
> clue injection over at AT&T Uverse.  I'm using this to document the
> MASSIVE bureaucratic PITA which is getting native IPv6 on uverse. 
> You'll start from the default service on a 2wire "modem" (for values
> of modem that equate to profanity).  If you have the Motorola NVG589,
> count yourself lucky and skip most of these steps.
>
>  Abandon all hope ye who enter here....
>
> Step 1: contact AT&T Uverse support and complain that you need IPv6
> (because we all need it, I in fact do for work).
> Step 2: general confusion as the level 1 droid doesn't know what IPv6
> is, politely request to be transferred to tier 2
> step 3: you will be told that tier 2 is a paid service, invoke the
> almighty FCC and ask to speak with a supervisor, expect a long hold here.
> step 4: you arrive at tier 2, mention that IPv6 won't work on your
> 2wire and that AT&T has broken your protocol 41 tunnel with <insert
> tunnel broker here, usually HE>
> step 5: you'll need to get your 2wire replaced with a Motorola
> NVG589.  Again you will be threatened with a cost to upgrade, mine was
> waived due to the work requirement.  I'd guess some additional
> complaining and escalation will get this fee waived.  My recollection
> was it was $100.  The new modem is good news for quite a few reasons,
> the 2wire sucks, the Motorola sucks significantly less, and has a
> built in battery backup, but mine lacked the battery.
> step 6: you'll receive the motorola by mail, or have a tech install
> it, they actually had a tech in my area and I had an AT&T tech at my
> door in less than 20 minutes from when I got off the phone with tier-2
> (I about died from the shock).
> step 7: configure the motorola (192.168.1.254) for passthrough,
> DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna,
> wireless, etc.
> Step 8: reboot to push the public IP to your real router.
> step 9: head over to the Motorola's home network tab, and in the
> status window you'll see:
>
>
>    IPv6
>
> Status     Available
> Global IPv6 Address     2602:306:cddd:xxxx::1/64
> Link-local IPv6 Address     fe80::923e:abff:xxxx:7e40
> Router Advertisement Prefix     2602:306:cddd:xxxx::/64
> IPV6 Delegated LAN Prefix     2602:306:cddd:xxxx::
> 2602:306:cddd:xxxx::
>
>
> In reality additional poking leads me to believe AT&T gives you a
> rather generous /60, but how to use it?
> step 10: set up dhcpv6, example for mikrotik follows (but should be
> easily convertible to nearly any router):
>
> /ipv6> export
> # dec/31/2001 20:26:03 by RouterOS 6.6
> # software id = 5F2Y-X73L
> #
> /ipv6 address
> add address=2602:306:cddd:xxxx::1 from-pool=AT&T interface=bridge1
> /ipv6 dhcp-client
> add add-default-route=yes interface=ether10 pool-name=AT&T
>
> I hope that this is of help to someone.
>
> Andrew
>


Are you actually getting a /60 in your IPv6 pool in routerOS?

I haven't seen it work and Comcast claims a /60 via DHCP-PD is available
everywhere now.

# nov/23/2013 07:09:08 by RouterOS 6.6
/ipv6 address
add address=2601:b:beXX:XXX::1 from-pool=comcastv6-pd
interface=ether2-master-local
/ipv6 dhcp-client
add add-default-route=yes interface=ether1-wan pool-name=comcastv6-pd
use-peer-dns=no
/ipv6 nd
set [ find default=yes ] disabled=yes
add hop-limit=64 interface=ether2-master-local reachable-time=5m
[admin at MikroTik] /ipv6> pool print
Flags: D - dynamic
 #   NAME                                                        
PREFIX                                      PREFIX-LENGTH
EXPIRES-AFTER      
 0 D comcastv6-pd                                                
2601:b:beXX:XXX::/64                                   64 3d23h54m48s





From jared at puck.nether.net  Sat Nov 23 10:40:59 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 23 Nov 2013 05:40:59 -0500
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <5290498A.6040405@trelane.net>
References: <5290498A.6040405@trelane.net>
Message-ID: <898B1EC0-8E24-4A1E-8FBB-493683EBA87D@puck.nether.net>

I wonder if we can use this to get around their broken SIP-ALG...

Jared Mauch

> On Nov 23, 2013, at 1:22 AM, Andrew D Kirch <trelane at trelane.net> wrote:
> 
> Special thanks to Alexander from AT&T's "Tier-2" dept, though my suspicion is that that is not where he works, as he seems exceptionally clueful.
> Additional thanks to Owen DeLong who finally got me off my ass to actually do this, I'll see you in the sky!
> 
> Ok, is this core routing? not really, but it's nice to see a major clue injection over at AT&T Uverse.  I'm using this to document the MASSIVE bureaucratic PITA which is getting native IPv6 on uverse.  You'll start from the default service on a 2wire "modem" (for values of modem that equate to profanity).  If you have the Motorola NVG589, count yourself lucky and skip most of these steps.
> 
> Abandon all hope ye who enter here....
> 
> Step 1: contact AT&T Uverse support and complain that you need IPv6 (because we all need it, I in fact do for work).
> Step 2: general confusion as the level 1 droid doesn't know what IPv6 is, politely request to be transferred to tier 2
> step 3: you will be told that tier 2 is a paid service, invoke the almighty FCC and ask to speak with a supervisor, expect a long hold here.
> step 4: you arrive at tier 2, mention that IPv6 won't work on your 2wire and that AT&T has broken your protocol 41 tunnel with <insert tunnel broker here, usually HE>
> step 5: you'll need to get your 2wire replaced with a Motorola NVG589.  Again you will be threatened with a cost to upgrade, mine was waived due to the work requirement.  I'd guess some additional complaining and escalation will get this fee waived.  My recollection was it was $100.  The new modem is good news for quite a few reasons, the 2wire sucks, the Motorola sucks significantly less, and has a built in battery backup, but mine lacked the battery.
> step 6: you'll receive the motorola by mail, or have a tech install it, they actually had a tech in my area and I had an AT&T tech at my door in less than 20 minutes from when I got off the phone with tier-2 (I about died from the shock).
> step 7: configure the motorola (192.168.1.254) for passthrough, DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna, wireless, etc.
> Step 8: reboot to push the public IP to your real router.
> step 9: head over to the Motorola's home network tab, and in the status window you'll see:
> 
> 
>   IPv6
> 
> Status    Available
> Global IPv6 Address    2602:306:cddd:xxxx::1/64
> Link-local IPv6 Address    fe80::923e:abff:xxxx:7e40
> Router Advertisement Prefix    2602:306:cddd:xxxx::/64
> IPV6 Delegated LAN Prefix    2602:306:cddd:xxxx::
> 2602:306:cddd:xxxx::
> 
> 
> In reality additional poking leads me to believe AT&T gives you a rather generous /60, but how to use it?
> step 10: set up dhcpv6, example for mikrotik follows (but should be easily convertible to nearly any router):
> 
> /ipv6> export
> # dec/31/2001 20:26:03 by RouterOS 6.6
> # software id = 5F2Y-X73L
> #
> /ipv6 address
> add address=2602:306:cddd:xxxx::1 from-pool=AT&T interface=bridge1
> /ipv6 dhcp-client
> add add-default-route=yes interface=ether10 pool-name=AT&T
> 
> I hope that this is of help to someone.
> 
> Andrew


From jared at puck.nether.net  Sat Nov 23 10:42:50 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 23 Nov 2013 05:42:50 -0500
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <52905590.5090505@kenweb.org>
References: <5290498A.6040405@trelane.net> <52905590.5090505@kenweb.org>
Message-ID: <9D6C3D95-E4BF-454F-859C-36D3D542D949@puck.nether.net>

With comcast you can check on everything at comcast6.net. It will tell you if your CMTS is enabled. 

Jared Mauch

> On Nov 23, 2013, at 2:13 AM, ML <ml at kenweb.org> wrote:
> 
> Comcast claims a /60 via DHCP-PD is available
> everywhere now.


From jmamodio at gmail.com  Sat Nov 23 13:30:30 2013
From: jmamodio at gmail.com (Jorge Amodio)
Date: Sat, 23 Nov 2013 07:30:30 -0600
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <CAE_vMvePu8_G2rkXgOXvRJY_6ui1g_k6XSO03zw_KJ73=xWg4w@mail.gmail.com>
References: <5290498A.6040405@trelane.net>
 <5BC3117F-F4E8-42BD-95F6-DB442EE59C80@akcin.net>
 <CAE_vMvePu8_G2rkXgOXvRJY_6ui1g_k6XSO03zw_KJ73=xWg4w@mail.gmail.com>
Message-ID: <CAMzo+1aJHtrGtmtN=S_Dm_W1EcgXx2Uxfd0B-xxW9iFxm5Ycjg@mail.gmail.com>

I've it working with TWC with a Motorola  SB6141 and a RB450G router
board running MikroTik RouterOS

I had to replace the old modem which didn't have DOCSIS 3 and upgrade
the RouterOS 6.3.

So far from both Windoze and Linux machines have now full IPv6 connectivity.

One gizmo app that became very handy is the ipvfoo extension or the
chrome browser that adds an icon on the status bar showing it the
contents for the page arrived via IPv6/4 or both. I believe there is
now a port for firefox.

I'm getting a /64 from TWC, seems to work reliably well.

-Jorge

> On Nov 23, 2013, at 12:57 AM, Brian Henson <marine64 at gmail.com> wrote:
>
> Now if Time Warner Cable would get their act together in Ohio (looks at
> them :) )
>
>


From trelane at trelane.net  Sat Nov 23 17:49:33 2013
From: trelane at trelane.net (Andrew D Kirch)
Date: Sat, 23 Nov 2013 12:49:33 -0500
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <CAPKkNb4a4CX4kmhn0H_9BH=Lw6p4-GquYiTo4Hbr1mrtVM1Enw@mail.gmail.com>
References: <5290498A.6040405@trelane.net>
 <CAPKkNb4a4CX4kmhn0H_9BH=Lw6p4-GquYiTo4Hbr1mrtVM1Enw@mail.gmail.com>
Message-ID: <5290EAAD.3030702@trelane.net>

I'm going to answer two posts here. First you're correct this appears to 
be a 6rd, and it is a /60


    IPv6

Status 	Available
Global Unicast IPv6 Address 	2602:306:cddd:1c50::/60
Border Relay IPv4 Address 	12.83.49.81




On 11/23/2013 1:58 AM, Constantine A. Murenin wrote:
> On 22 November 2013 22:22, Andrew D Kirch <trelane at trelane.net> wrote:
>> Status  Available
>> Global IPv6 Address     2602:306:cddd:xxxx::1/64
>> Link-local IPv6 Address         fe80::923e:abff:xxxx:7e40
>> Router Advertisement Prefix     2602:306:cddd:xxxx::/64
>> IPV6 Delegated LAN Prefix       2602:306:cddd:xxxx::
>> 2602:306:cddd:xxxx::
> I don't believe this is native IPv6; it's probably still their 6rd,
> which has, in fact, been live since at least February 2012, i.e. for
> close to two years at this point.
>
> http://tu.cnst.su/post/16958139578/at-t-u-verse-6rd-in-santa-clara-county
> http://www.tunnelbroker.net/forums/index.php?topic=2293.0
>
> And, yes, AT&T is probably still keeping this whole thing a secret.
>
> C.


From alh-ietf at tndh.net  Sat Nov 23 19:22:10 2013
From: alh-ietf at tndh.net (Tony Hain)
Date: Sat, 23 Nov 2013 11:22:10 -0800
Subject: NAT64 and matching identities
In-Reply-To: <003801cee7dd$8ee20990$aca61cb0$@tndh.net>
References: <20131120133033.3c84120f.gem@rellim.com>
 <CEB29567.39B09%Lee@asgard.org> <000f01cee7af$3d8da870$b8a8f950$@tndh.net>
 <100205.1385150483@turing-police.cc.vt.edu> <528FBABA.2050401@bogus.com>
 <092C0ECE-9114-4BB7-8C50-E273583F8E78@delong.com>
 <002b01cee7c9$d46bcb40$7d4361c0$@tndh.net>
 <8D53DBA3-A0BC-4944-ACFC-43953B7F2078@delong.com>
 <003801cee7dd$8ee20990$aca61cb0$@tndh.net>
Message-ID: <005801cee881$4ead2b80$ec078280$@tndh.net>

So it turns out that in many cases a missing www is causing the "no IPv4"
response, and someone from Alexa does need to explain what is going on. For
the entire top-1m.csv file, 35,554 entries returned "no IPv4". For each
entry in the csv file;
some return NXDOMAIN:
discart.ru  -->  NXDOMAIN
     www.discart.ru resolves, but Alexa file missing www.
     Alexa position:            4721,discart.ru

some return without any answer:
bp.blogspot.com  --> No Answer
     www.bp.blogspot.com resolves, but Alexa file missing www.
     Alexa position:            87,bp.blogspot.com

while others point to MX-only entries:
akamaihd.net  -->  MX-only
     www.akamaihd.net resolves, but Alexa file missing www.
     Alexa position:            74,akamaihd.net

The version of the code I have been using strips the www. and tries again,
but obviously it also needs to add the www. and retry. In any case, the
Alexa file points to names that do not serve web content, so the entire 'top
1M' list is suspect.

Tony


> -----Original Message-----
> From: Tony Hain [mailto:alh-ietf at tndh.net]
> Sent: Friday, November 22, 2013 3:50 PM
> To: 'Owen DeLong'
> Cc: Sherfesee at amazon.com; 'NANOG List'
> Subject: RE: NAT64 and matching identities
> 
> Someone from Alexa really needs to answer how that list is created because
> their web site discussion is way too hand-wavy, but given that neither of
> those appear to be currently valid names, and 1.1.1.1 is on the list at
all, there
> must be some measure of cross link and redirection occurrences. For the
> entire top-1m, I show today's file has 2815 as dotted-quad. In the top
> 50,000 there are 1790 with "no IPv4   no IPv6".  Clearly they don't bother
> to prune the list for validity. ~4% of the next 25,000 names are dead
(50,000-
> 75,000), and one can only guess that as you get further down the list the
> percentage of dead names will continue to go up. I have a full 1M run in
> process, but would not count on it completing before Monday.
> 
> Just to add a level of 'extra effort' to the process, I increased the
number of
> attempts to 10, and the time between attempts to 10 seconds. With that,
> dead names in the top 1000:
> akamaihd.net                    no IPv4   no IPv6
> bp.blogspot.com                 no IPv4   no IPv6
> delta-search.com                no IPv4   no IPv6
> bannersdontwork.com             no IPv4   no IPv6
> cloudfront.net                  no IPv4   no IPv6
> doorblog.jp                     no IPv4   no IPv6
> uimserv.net                     no IPv4   no IPv6
> linksynergy.com                 no IPv4   no IPv6
> lipixeltrack.com                no IPv4   no IPv6
> australianbrewingcompany.com    no IPv4   no IPv6
> searchfun.in                    no IPv4   no IPv6
> greatappsdownload.com           no IPv4   no IPv6
> klikbca.com                     no IPv4   no IPv6
> jobfindgold.info                no IPv4   no IPv6
> adnxs.com                       no IPv4   no IPv6
> rakuten.ne.jp                   no IPv4   no IPv6
> sweetpacks-search.com           no IPv4   no IPv6
> yomiuri.co.jp                   no IPv4   no IPv6
> incredibar-search.com           no IPv4   no IPv6
> searchgol.com                   no IPv4   no IPv6
> livedoor.biz                    no IPv4   no IPv6
> workercn.cn                     no IPv4   no IPv6
> 
> FWIW: in the top 50,000, I show 1525 "has IPv4  has IPv6" &  0  "no IPv4
has
> IPv6". In other words, there are more dead names than there are AAAA
> records, and there are not any IPv6-only sites in that group.
> 
> Tony
> 
> 
> > -----Original Message-----
> > From: Owen DeLong [mailto:owen at delong.com]
> > Sent: Friday, November 22, 2013 1:48 PM
> > To: Tony Hain
> > Cc: joel jaeggli; Valdis.Kletnieks at vt.edu; NANOG List
> > Subject: Re: NAT64 and matching identities
> >
> > So one has to wonder how those names made it into the top 100 list if
> > it's supposed to be a top 100 web sites, since they are obviously not
> > web
> sites.
> > (at least in the case of the two in the top 100)
> >
> > Owen
> >
> > On Nov 22, 2013, at 1:28 PM, Tony Hain <alh-ietf at tndh.net> wrote:
> >
> > > The only thing it explicitly strips out are dotted-quads, which
> > > don't occur until # 4255. The code makes five passes at
> > > getaddrinfo() for
> > > IPv4 before giving up, and then it checks for a leading www and if
> > > that exists it strips it off and does the 5 tries loop again, then
> > > later the same process for IPv6. For the top 100 run:
> > > akamaihd.net                    no IPv4   no IPv6
> > > bp.blogspot.com                 no IPv4   no IPv6
> > >
> > > FWIW :::
> > > Dotted-quad's in the top 10,000
> > > 4255,92.242.195.24
> > > 4665,1.1.1.1
> > > 5079,92.242.195.231
> > > 6130,1.254.254.254
> > > 9518,208.98.30.70
> > >
> > >> whois 92.242.195.24
> > > ...
> > > netname:        Respina
> > > descr:          BroadBand IP Pool
> > > country:        IR
> > > ...
> > > route:          92.242.195.0/24
> > >
> > > Respina BroadBand IP Pool in the top 100,000
> > > 4255,92.242.195.24
> > > 5079,92.242.195.231
> > > 10059,92.242.195.233
> > > 23912,92.242.195.30
> > > 31520,92.242.195.111
> > > 35867,92.242.195.235
> > > 95233,92.242.195.129
> > >
> > >
> > >> -----Original Message-----
> > >> From: Owen DeLong [mailto:owen at delong.com]
> > >> Sent: Friday, November 22, 2013 12:16 PM
> > >> To: joel jaeggli
> > >> Cc: Valdis.Kletnieks at vt.edu; Tony Hain; NANOG List
> > >> Subject: Re: NAT64 and matching identities
> > >>
> > >> It would be way more than 2 if it were CNAME, methinks.
> > >>
> > >> Owen
> > >>
> > >> On Nov 22, 2013, at 12:12 PM, joel jaeggli <joelja at bogus.com> wrote:
> > >>
> > >>> On 11/22/13, 12:01 PM, Valdis.Kletnieks at vt.edu wrote:
> > >>>> On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
> > >>>>
> > >>>>> The top 100 websites: AAAA records and IPv6 connectivity
> > >>>>>          count with A:       98   ( 98.000%)
> > >>>>>       count with AAAA:       30   ( 30.000%)
> > >>>>> Of the 30 hosts with AAAA records, testing connectivity to TCP/80:
> > >>>>>    count with IPv6 ok:       30   (100.000%)
> > >>>>
> > >>>> Statistics whoopsie, or are there actually 2 sites in the top100
> > >>>> that are IPv6-only?
> > >>>
> > >>> IN CNAME ? or is that being accounted for.
> > >>>
> > >>>
> > >>>
> 




From eric at ericheather.com  Sun Nov 24 02:47:00 2013
From: eric at ericheather.com (Eric C. Miller)
Date: Sun, 24 Nov 2013 02:47:00 +0000
Subject: Meraki
In-Reply-To: <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com>
References: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>
 <4FFF777C-07B6-49FD-A87F-52156C9069FC@dds.nl>
 <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com>
Message-ID: <DC85D08B84BB854086E9524DAB67D18715EF7C67@Teriwood.miller.local>

I'm using an EdgeRouter lite in a deployment for a WISP, and it's holding up very nice. It's only passing 40-50Mbps of basic OSPF routing, but no complaints thus far for the performance. I've heard that once you start adding in the services and rules, you really start to see the PPS drop, but I haven't RFC 2544 or EtherSam tested it yet.

Right now, I'm waiting for the GUI to get more development before we move further with them. Being Vyatta under the hood, you can do just about anything, but the helpdesk techs don't understand CLI. Kudos on the IPv6 GUI support out of the box.



Eric Miller, CCNP
Network Engineering Consultant
(407) 257-5115



-----Original Message-----
From: Ray Soucy [mailto:rps at maine.edu] 
Sent: Friday, November 22, 2013 7:35 AM
To: Seth Mos
Cc: NANOG
Subject: Re: Meraki

FWIW, I picked up a UniFi 3-pack of APs and built up a controller VM using Ubuntu Server LTS and the beta multi-site controller code over the past week.

I'm very impressed so far, it doesn't have all the bells and whistles of Cisco setup, sure, but I'm pretty shocked at the level of functionality here and the ease of having APs use an off-site controller (they all phone home over TCP so no VPN or port forwarding is required).

I'm interested in UniFi mainly for remote Libraries that don't have any IT staff but need a little more than a router from Best Buy.

Also of interest is the EdgeMAX line.  I also got the EdgeRouter LITE for testing this past week after finding out it runs a fork of Vyatta (EdgeOS) and is developed by former Vyatta employees.  For a sub- $100 device ...
very impressive.

Pricing just popped up for the new EdgeRouter PRO last night and I was pretty blown away:

$360

For a device with 2 SFP ports, and 2M PPS.  That is music to my ears since we do a lot of dark fiber around the state even for smaller locations.  I'm pretty excited to get one of these and see how they perform.

I wish I would have bothered looking at Ubiquiti sooner, really.  I'm a little embarrassed to admit I initially wrote them off because the prices were so low, but the more I look into these guys the more I like them.

I feel like I'm at the risk for becoming a UBNT fanboy.  Does anyone have any qualified horror stories about EdgeMAX or UniFi?  Everything I've been able to find has been for nonsense configurations like complaining about trying to to OSPF over WiFi ... Who does that?






On Fri, Nov 22, 2013 at 1:34 AM, Seth Mos <seth.mos at dds.nl> wrote:

>
> Op 22 nov 2013, om 06:37 heeft Jay Ashworth het volgende geschreven:
>
> > ----- Original Message -----
> > Anecdote:
> >
> > My local IHOP finally managed to get Wifi internet access in the
> restaurant.
> >
> > For reasons unknown to me, it's a Meraki box, backhauled *over T-mobile*.
> >
> > That's just as unpleasant as you'd think it would be, And More!
> >
> > Both the wifi and 3G (yes, 3G) boxes lock up on a fairly regular 
> > basis, requiring a power cycle, which, generally, they'll only do 
> > because I've been eating there for 20 years, and they trust me when I ask them to.
> >
> > I can't say whether this provides any illumination on the rest of 
> > their product line, but...
>
> To compound matters, i'd go as far as to say that any wireless 
> solution on 2.4Ghz isn't really a wireless solution. It's just not 
> feasible anymore in 2013, there is just *so much* interference from 
> everything using the unlicensed 2.4Ghz band that it's own success is it's greatest downfall.
>
> Reliable wireless isn't (to use the famous war quote "friendly fire 
> isn't")
>
> For whatever reasons, whomever I talk to they all tell me that <ISP 
> here> sucks, and if I ask further if they are using the wireless 
> thingamabob that the ISP shipped them, they says yes. So, that's about right then.
>
> I've been using a PCengines.ch Alix router for years now (AMD Geode, 
> x86, 256MB ram, CF) with a cable modem in bridge mode with seperate 
> dual band access points in the places where I need them (living room, 
> attic office) and I can't say that my experiences with the <ISP here> mesh with theirs.
>
> Anyhow, if you are going to deploy wireless, make sure to use dual 
> band, and name the 2.4Ghz SSID "internet" and the 5Ghz SSID "faster-internet".
> You'll see people having a heck of a better time. Social engineering 
> works
> :)
>
> When we chose the Ubiquity wireless kit we could deploy twice as many 
> APs for the same price of one of the other APs. This effectively means 
> we have a very dense wireless network that covers the entire building, 
> and lot's of kit that can actually see and use the 5Ghz band.
>
> Setup was super easy, I added a unifi DNS name that points to my unifi 
> controller host and I get a email that a new AP is ready to be put 
> into service. Having a local management host instead of some cloud was 
> a hard requirement. I also like that I can just "apt-get update; apt-get upgrade"
> the software. By using DNS remote deployment was super easy too, send 
> the unit off and let them plug it in, it then comes onto the network 
> and registers itself.
>
> I believe every current Apple iDevice currently supports the 5Ghz 
> band, and all the Dell gear we purchase also comes ordered with it. 
> Heck, even my
> 2011 Sony Xperia T has 5Ghz wireless now, as do the current Samsung 
> Galaxy S3, S4
>
> Best regards,
>
> Seth
>



--
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network www.maineren.net


From ispbuilder at gmail.com  Sun Nov 24 14:43:15 2013
From: ispbuilder at gmail.com (Mike)
Date: Sun, 24 Nov 2013 10:43:15 -0400
Subject: Meraki
In-Reply-To: <DC85D08B84BB854086E9524DAB67D18715EF7C67@Teriwood.miller.local>
References: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>
 <4FFF777C-07B6-49FD-A87F-52156C9069FC@dds.nl>
 <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com>
 <DC85D08B84BB854086E9524DAB67D18715EF7C67@Teriwood.miller.local>
Message-ID: <52921083.9080504@gmail.com>

On 13-11-23 10:47 PM, Eric C. Miller wrote:
> I'm using an EdgeRouter lite in a deployment for a WISP, and it's holding up very nice. It's only passing 40-50Mbps of basic OSPF routing, but no complaints thus far for the performance. I've heard that once you start adding in the services and rules, you really start to see the PPS drop, but I haven't RFC 2544 or EtherSam tested it yet.
>
> Right now, I'm waiting for the GUI to get more development before we move further with them. Being Vyatta under the hood, you can do just about anything, but the helpdesk techs don't understand CLI. Kudos on the IPv6 GUI support out of the box.
+1 on the EdgeRouter.  I haven't regularly pushed one past 100M, but
over the past 9 months all they have done is act boring, which is
exactly what I want network equipment to do.

PPS will be affected more by packet filtering rules than by services.

> From: Ray Soucy [mailto:rps at maine.edu] 
>
> I'm very impressed so far, it doesn't have all the bells and whistles of Cisco setup, sure, but I'm pretty shocked at the level of functionality here and the ease of having APs use an off-site controller (they all phone home over TCP so no VPN or port forwarding is required).
The UniFi units are awesome. What they lack in terms of bells and
whistles they make up for with price and ease of setup. the 2.4GHz-only
units aren't great for areas with a high noise floor, but then again not
many 2.4GHz devices are.

> I feel like I'm at the risk for becoming a UBNT fanboy.  Does anyone have any qualified horror stories about EdgeMAX or UniFi?  Everything I've been able to find has been for nonsense configurations like complaining about trying to to OSPF over WiFi ... Who does that?
>
Biggest downside I can find is the use of non-standard PoE injectors for
the 2.4GHz-only units. At <$250 for a 3-pack, it's pretty easy to
overlook that. The dual band 802.11ac units (Broadcom based, most of the
other gear is Atheros based) don't feel as reliable as the other gear.
Gut feeling, not anything I can measure.


-- 
Looking for (employment|contract) work in the
Internet industry, preferably working remotely. 
Building / Supporting the net since 2400 baud was
the hot thing. Ask for a resume! ispbuilder at gmail.com



From rs at seastrom.com  Mon Nov 25 01:33:50 2013
From: rs at seastrom.com (Rob Seastrom)
Date: Sun, 24 Nov 2013 20:33:50 -0500
Subject: Meraki
In-Reply-To: <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com> (Ray
 Soucy's message of "Fri, 22 Nov 2013 07:35:06 -0500")
References: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>
 <4FFF777C-07B6-49FD-A87F-52156C9069FC@dds.nl>
 <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com>
Message-ID: <86wqjxi7sx.fsf@valhalla.seastrom.com>


Ray Soucy <rps at maine.edu> writes:

> Pricing just popped up for the new EdgeRouter PRO last night and I was
> pretty blown away:
>
> $360
>
> For a device with 2 SFP ports, and 2M PPS.  That is music to my ears since
> we do a lot of dark fiber around the state even for smaller locations.  I'm
> pretty excited to get one of these and see how they perform.

Me too...  Will probably pony up for one as soon as I can.

I haven't tried out their software in a more than trivial
configuration, and haven't gotten IPv4 policy routing working (though
I understand it's in there now).  An ER-Lite tunnels IPv6 fine,
haven't tried it with PD...

> I feel like I'm at the risk for becoming a UBNT fanboy.  Does anyone have
> any qualified horror stories about EdgeMAX or UniFi?  Everything I've been
> able to find has been for nonsense configurations like complaining about
> trying to to OSPF over WiFi ... Who does that?

They are an unmitigated disaster at hitting dates and calibrating
expectations.  The EdgeRouter Pro has been on their web site for well
over a year.  The EdgeRouter Carrier (with 10ge SFP+) has disappeared
from their web site altogether.

I'm concerned about the Vyatta CLI docs and their continuing
availability.  Someone from Brocade should make some public statements
to set our collective minds at ease.

That said I've been reasonably happy with the UBNT stuff (mostly older
outdoor gear) that I've bought over the past several years.  It's held
up well.  Just don't count on the availability of anything that you
can't order up from your favorite VAR and have it show up in the
FedEx.

-r



From bruns at 2mbit.com  Mon Nov 25 02:39:42 2013
From: bruns at 2mbit.com (Brielle Bruns)
Date: Sun, 24 Nov 2013 19:39:42 -0700
Subject: Meraki
In-Reply-To: <52921083.9080504@gmail.com>
References: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>
 <4FFF777C-07B6-49FD-A87F-52156C9069FC@dds.nl>
 <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com>
 <DC85D08B84BB854086E9524DAB67D18715EF7C67@Teriwood.miller.local>
 <52921083.9080504@gmail.com>
Message-ID: <5292B86E.30008@2mbit.com>

On 11/24/13, 7:43 AM, Mike wrote:
> On 13-11-23 10:47 PM, Eric C. Miller wrote:
>>> I'm using an EdgeRouter lite in a deployment for a WISP, and it's
>>> holding up very nice. It's only passing 40-50Mbps of basic OSPF
>>> routing, but no complaints thus far for the performance. I've
>>> heard that once you start adding in the services and rules, you
>>> really start to see the PPS drop, but I haven't RFC 2544 or
>>> EtherSam tested it yet.
>>>
>>> Right now, I'm waiting for the GUI to get more development before
>>> we move further with them. Being Vyatta under the hood, you can
>>> do just about anything, but the helpdesk techs don't understand
>>> CLI. Kudos on the IPv6 GUI support out of the box.
> +1 on the EdgeRouter.  I haven't regularly pushed one past 100M, but
> over the past 9 months all they have done is act boring, which is
> exactly what I want network equipment to do.
>
> PPS will be affected more by packet filtering rules than by
> services.
>


As the product software has matured, the ER Lite has gained quite a few 
performance improvements - just keep it updated  as new versions come 
out.  Recent example is the HW VLAN acceleration stuff.

I have two, one in service the other as a spare.  For the price, hard to 
go wrong.

-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org


From eugen at imacandi.net  Mon Nov 25 06:36:16 2013
From: eugen at imacandi.net (Eugeniu Patrascu)
Date: Mon, 25 Nov 2013 08:36:16 +0200
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
References: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
Message-ID: <CALgc3C6sgyOOb6wUgHpmxnUGzPXrSLFFkSbwR1AwxJ8QUiuzUA@mail.gmail.com>

On Fri, Oct 11, 2013 at 8:27 PM, William Waites <wwaites at tardis.ed.ac.uk>wrote:

> I'm having a discussion with a small network in a part of the world
> where bandwidth is scarce and multiple DSL lines are often used for
> upstream links. The topic is policy-based routing, which is being
> described as "load balancing" where end-user traffic is assigned to a
> line according to source address.
>
> In my opinion the main problems with this are:
>
>   - It's brittle, when a line fails, traffic doesn't re-route
>

You can always know what IPs are on the other end of the link, add static
routes for them to make sure they're reachable and based on ping results
use the link or not. It works fairly well if 1-2 minutes of downtime is not
an issue. I've done this using Linux and a bash script and it worked to
balance traffic across two links with up/down detection. iproute2 does
wonders.


>   - None of the usual debugging tools work properly
>

As long as you don't have asymmetric routing in place, debugging will be
the same. Even so, you can (at least on Linux) do a "tcpdump -i any" and
see what goes in/out of your box :)


>   - Adding a new user is complicated because it has to be done in (at
>     least) two places
>
>
I agree it's not scaleable, but for when all you have are DSL lines or low
capacity lines over which you cannot run an IGP, you'll have make it work
with what you have :)


> But I'm having a distinct lack of success locating rants and diatribes
> or even well-reasoned articles supporting this opinion.
>
>
I would go for the "right tools for the right job" idea and say that PBR in
the case you're mentioning of a valid use and probably the most effective
way of doing business for them.

Also take into consideration that in many parts of the world, the effort of
configuring and maintaining a setup like this fall in the the day to day
job of one or several network admins. Also, most of the time is cheaper to
hire more people than go and buy let's say professional networking
equipment.

Regards,
Eugeniu

From mksmith at mac.com  Mon Nov 25 07:43:54 2013
From: mksmith at mac.com (Michael Smith)
Date: Sun, 24 Nov 2013 23:43:54 -0800
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <CALgc3C6sgyOOb6wUgHpmxnUGzPXrSLFFkSbwR1AwxJ8QUiuzUA@mail.gmail.com>
References: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
 <CALgc3C6sgyOOb6wUgHpmxnUGzPXrSLFFkSbwR1AwxJ8QUiuzUA@mail.gmail.com>
Message-ID: <EC8C5FE4-4883-4FD6-B0E2-ADC28964BA2B@mac.com>


On Nov 24, 2013, at 10:36 PM, Eugeniu Patrascu <eugen at imacandi.net> wrote:

> On Fri, Oct 11, 2013 at 8:27 PM, William Waites <wwaites at tardis.ed.ac.uk>wrote:
> 
>> I'm having a discussion with a small network in a part of the world
>> where bandwidth is scarce and multiple DSL lines are often used for
>> upstream links. The topic is policy-based routing, which is being
>> described as "load balancing" where end-user traffic is assigned to a
>> line according to source address.
>> 
>> In my opinion the main problems with this are:
>> 
>>  - It's brittle, when a line fails, traffic doesn't re-route
>> 
> 
> You can always know what IPs are on the other end of the link, add static
> routes for them to make sure they're reachable and based on ping results
> use the link or not. It works fairly well if 1-2 minutes of downtime is not
> an issue. I've done this using Linux and a bash script and it worked to
> balance traffic across two links with up/down detection. iproute2 does
> wonders.
> 
Or you could run FreeBSD with PF and ifstated and it would be an almost instantaneous failover.

> 
>>  - None of the usual debugging tools work properly
>> 
> 
> As long as you don't have asymmetric routing in place, debugging will be
> the same. Even so, you can (at least on Linux) do a "tcpdump -i any" and
> see what goes in/out of your box :)
> 
> 
Asymmetric routing is a fact of life and is fairly common.

>>  - Adding a new user is complicated because it has to be done in (at
>>    least) two places
>> 
>> 
> I agree it's not scaleable, but for when all you have are DSL lines or low
> capacity lines over which you cannot run an IGP, you'll have make it work
> with what you have :)
> 
> 
>> But I'm having a distinct lack of success locating rants and diatribes
>> or even well-reasoned articles supporting this opinion.
>> 
>> 
> I would go for the "right tools for the right job" idea and say that PBR in
> the case you're mentioning of a valid use and probably the most effective
> way of doing business for them.
> 
> Also take into consideration that in many parts of the world, the effort of
> configuring and maintaining a setup like this fall in the the day to day
> job of one or several network admins. Also, most of the time is cheaper to
> hire more people than go and buy let's say professional networking
> equipment.

Hmm, really?  The professional networking equipment required for this type of thing would be in the ~10k new and significantly cheaper used.  That's not a lot of salary.

Mike

From eugen at imacandi.net  Mon Nov 25 11:06:10 2013
From: eugen at imacandi.net (Eugeniu Patrascu)
Date: Mon, 25 Nov 2013 13:06:10 +0200
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <EC8C5FE4-4883-4FD6-B0E2-ADC28964BA2B@mac.com>
References: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
 <CALgc3C6sgyOOb6wUgHpmxnUGzPXrSLFFkSbwR1AwxJ8QUiuzUA@mail.gmail.com>
 <EC8C5FE4-4883-4FD6-B0E2-ADC28964BA2B@mac.com>
Message-ID: <CALgc3C5E9Env3i4N-WR83gdFL_d5D7pv1bUeyojkS=TT=89Zyw@mail.gmail.com>

On Mon, Nov 25, 2013 at 9:43 AM, Michael Smith <mksmith at mac.com> wrote:

>
> On Nov 24, 2013, at 10:36 PM, Eugeniu Patrascu <eugen at imacandi.net> wrote:
>
> On Fri, Oct 11, 2013 at 8:27 PM, William Waites <wwaites at tardis.ed.ac.uk
> >wrote:
>
> I'm having a discussion with a small network in a part of the world
> where bandwidth is scarce and multiple DSL lines are often used for
> upstream links. The topic is policy-based routing, which is being
> described as "load balancing" where end-user traffic is assigned to a
> line according to source address.
>
> In my opinion the main problems with this are:
>
>  - It's brittle, when a line fails, traffic doesn't re-route
>
>
> You can always know what IPs are on the other end of the link, add static
> routes for them to make sure they're reachable and based on ping results
> use the link or not. It works fairly well if 1-2 minutes of downtime is not
> an issue. I've done this using Linux and a bash script and it worked to
> balance traffic across two links with up/down detection. iproute2 does
> wonders.
>
> Or you could run FreeBSD with PF and ifstated and it would be an almost
> instantaneous failover.
>
>
 Cool toy for scripting. I had no ideea as I'm not very familiar with *BSD.

>
>  - None of the usual debugging tools work properly
>
>
> As long as you don't have asymmetric routing in place, debugging will be
> the same. Even so, you can (at least on Linux) do a "tcpdump -i any" and
> see what goes in/out of your box :)
>
>
> Asymmetric routing is a fact of life and is fairly common.
>

If you have asymmetric routing, you may run into other issues, but still
you can get stuff working. Just saying that with a little care you can get
away without it.


>
>  - Adding a new user is complicated because it has to be done in (at
>    least) two places
>
>
> I agree it's not scaleable, but for when all you have are DSL lines or low
> capacity lines over which you cannot run an IGP, you'll have make it work
> with what you have :)
>
>
> But I'm having a distinct lack of success locating rants and diatribes
> or even well-reasoned articles supporting this opinion.
>
>
> I would go for the "right tools for the right job" idea and say that PBR in
> the case you're mentioning of a valid use and probably the most effective
> way of doing business for them.
>
> Also take into consideration that in many parts of the world, the effort of
> configuring and maintaining a setup like this fall in the the day to day
> job of one or several network admins. Also, most of the time is cheaper to
> hire more people than go and buy let's say professional networking
> equipment.
>
>
> Hmm, really?  The professional networking equipment required for this type
> of thing would be in the ~10k new and significantly cheaper used.  That's
> not a lot of salary.
>
>
I'm pretty sure there are places that even 6K can be one man's salary for a
year or more, so yeah, really it's cheaper to have some one do manual stuff
than buy something professional. But I'm veering a bit off-topic with this
one.


> Mike
>

Eugeniu

From John_Brzozowski at Cable.Comcast.com  Mon Nov 25 13:52:26 2013
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Mon, 25 Nov 2013 13:52:26 +0000
Subject: AT&T UVERSE Native IPv6, a HOWTO 
Message-ID: <BD87928F6BFAEF4EBEB883E1C4F587725A3D4613@PACDCEXMB01.cable.comcast.com>

Andrew,

Question is this native or 6rd?  According to my ARIN WHOIS query it looks
like 6rd.

Definitely great news that you were able to acquire IPv6.

John

Date: Sat, 23 Nov 2013 01:22:02 -0500
From: Andrew D Kirch <trelane at trelane.net>
To: nanog at nanog.org
Subject: AT&T UVERSE Native IPv6, a HOWTO
Message-ID: <5290498A.6040405 at trelane.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Special thanks to Alexander from AT&T's "Tier-2" dept, though my
suspicion is that that is not where he works, as he seems exceptionally
clueful.
Additional thanks to Owen DeLong who finally got me off my ass to
actually do this, I'll see you in the sky!

Ok, is this core routing? not really, but it's nice to see a major clue
injection over at AT&T Uverse.  I'm using this to document the MASSIVE
bureaucratic PITA which is getting native IPv6 on uverse.  You'll start
from the default service on a 2wire "modem" (for values of modem that
equate to profanity).  If you have the Motorola NVG589, count yourself
lucky and skip most of these steps.

  Abandon all hope ye who enter here....

Step 1: contact AT&T Uverse support and complain that you need IPv6
(because we all need it, I in fact do for work).
Step 2: general confusion as the level 1 droid doesn't know what IPv6
is, politely request to be transferred to tier 2
step 3: you will be told that tier 2 is a paid service, invoke the
almighty FCC and ask to speak with a supervisor, expect a long hold here.
step 4: you arrive at tier 2, mention that IPv6 won't work on your 2wire
and that AT&T has broken your protocol 41 tunnel with <insert tunnel
broker here, usually HE>
step 5: you'll need to get your 2wire replaced with a Motorola NVG589.
Again you will be threatened with a cost to upgrade, mine was waived due
to the work requirement.  I'd guess some additional complaining and
escalation will get this fee waived.  My recollection was it was $100.
The new modem is good news for quite a few reasons, the 2wire sucks, the
Motorola sucks significantly less, and has a built in battery backup,
but mine lacked the battery.
step 6: you'll receive the motorola by mail, or have a tech install it,
they actually had a tech in my area and I had an AT&T tech at my door in
less than 20 minutes from when I got off the phone with tier-2 (I about
died from the shock).
step 7: configure the motorola (192.168.1.254) for passthrough,
DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna,
wireless, etc.
Step 8: reboot to push the public IP to your real router.
step 9: head over to the Motorola's home network tab, and in the status
window you'll see:


    IPv6

Status 	Available
Global IPv6 Address 	2602:306:cddd:xxxx::1/64
Link-local IPv6 Address 	fe80::923e:abff:xxxx:7e40
Router Advertisement Prefix 	2602:306:cddd:xxxx::/64
IPV6 Delegated LAN Prefix 	2602:306:cddd:xxxx::
2602:306:cddd:xxxx::


In reality additional poking leads me to believe AT&T gives you a rather
generous /60, but how to use it?
step 10: set up dhcpv6, example for mikrotik follows (but should be
easily convertible to nearly any router):

/ipv6> export
# dec/31/2001 20:26:03 by RouterOS 6.6
# software id = 5F2Y-X73L
#
/ipv6 address
add address=2602:306:cddd:xxxx::1 from-pool=AT&T interface=bridge1
/ipv6 dhcp-client
add add-default-route=yes interface=ether10 pool-name=AT&T

I hope that this is of help to someone.

Andrew


=========================================
John Jason Brzozowski
Comcast Cable
m) 609-377-6594
o) 484-962-0060
w) www.comcast6.net
e) john_brzozowski at cable.comcast.com
=========================================





From david at imgix.com  Mon Nov 25 02:47:09 2013
From: david at imgix.com (David Birdsong)
Date: Sun, 24 Nov 2013 18:47:09 -0800
Subject: telnet into a netgear switch?
Message-ID: <CAOMvUQfeM_Wnc=eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ@mail.gmail.com>

Hey all, last night while at the datacenter I was in a pinch to extend a
rack's LAN. I compromised and ran out to the local Fry's to buy whatever
switch I could find so as to allow some configuration to happen while
we wait for the real network gear to show up.

I left before confirming I could access the switch remotely; it was very
late and I was pretty groggy and hey, any network gear has to be
telnet'table this day and age. Of course I was mostly wrong.

The switch expects some signed payload before allowing a telnet through. I
found this: https://code.google.com/p/netgear-telnetenable/...but I'm
having a hell of a time getting anything to respond.

The most confounding part is the switch doesn't respond to a single SYN
packet on low ports. I'm scanning all the ports now, but if nothing shows
up, I'm not sure what a payload is good for if the switch doesn't ACK a
single SYN.

I'm curious if anybody's got any tips besides not using Netgear in the
datacenter.

I have the MAC, I've IP'd it via DHCP, and the model number: JGS524E and I
can power cycle the switch as much as needed.


P.S. long time listener, first time caller. i'm more of a sysadmin
dangerously standing in for a proper network person.

From rps at maine.edu  Mon Nov 25 14:32:10 2013
From: rps at maine.edu (Ray Soucy)
Date: Mon, 25 Nov 2013 09:32:10 -0500
Subject: Meraki
In-Reply-To: <86wqjxi7sx.fsf@valhalla.seastrom.com>
References: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>
 <4FFF777C-07B6-49FD-A87F-52156C9069FC@dds.nl>
 <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com>
 <86wqjxi7sx.fsf@valhalla.seastrom.com>
Message-ID: <CALFTrnPpBQLHRRDkMnt1nz8Wi0k3B6KEmt9tbgNS-wfRHqSnqQ@mail.gmail.com>

It looks like Brocade has swapped out Quagga with IP Infusion's non-free
version, ZebOS.  They also decided to abandon the FOSS Vyatta Core project.

It's really unfortunate, as the FOSS project is the only reason I was
interested in paying the licensing.  It was attractive to have Vyatta Core
as a no-cost option for small things, and the subscription edition for
higher visibility devices.  Now that they've moved away from having any
FOSS project, I'm not really inclined to invest in the product, I'm sure
there are others who feel the same way.

There is a group of people who were active in the Vyatta community trying
to get a fork of it going under the name VyOS, http://www.vyos.net/

As far as Ubiquiti, it looks like about 2 years ago they actually hired a
few people from Vyatta, Inc. to work on EdgeOS.  So development of EdgeOS
has continued [and likely will continue] independently, though it looks
like at least a few people from UBNT are interested in seeing VyOS happen
and participating on their own time.  I know one of the early goals for
VyOS is to get the documentation up on their Wiki and have a release of the
current Vyatta Core with the name swapped out as a starting point.

I really hope the VyOS project can get off the ground.  If any developers
familiar with maintaining Debian-based distributions are on-list, I know
the project is looking for people to help.






On Sun, Nov 24, 2013 at 8:33 PM, Rob Seastrom <rs at seastrom.com> wrote:

>
> Ray Soucy <rps at maine.edu> writes:
>
> > Pricing just popped up for the new EdgeRouter PRO last night and I was
> > pretty blown away:
> >
> > $360
> >
> > For a device with 2 SFP ports, and 2M PPS.  That is music to my ears
> since
> > we do a lot of dark fiber around the state even for smaller locations.
>  I'm
> > pretty excited to get one of these and see how they perform.
>
> Me too...  Will probably pony up for one as soon as I can.
>
> I haven't tried out their software in a more than trivial
> configuration, and haven't gotten IPv4 policy routing working (though
> I understand it's in there now).  An ER-Lite tunnels IPv6 fine,
> haven't tried it with PD...
>
> > I feel like I'm at the risk for becoming a UBNT fanboy.  Does anyone have
> > any qualified horror stories about EdgeMAX or UniFi?  Everything I've
> been
> > able to find has been for nonsense configurations like complaining about
> > trying to to OSPF over WiFi ... Who does that?
>
> They are an unmitigated disaster at hitting dates and calibrating
> expectations.  The EdgeRouter Pro has been on their web site for well
> over a year.  The EdgeRouter Carrier (with 10ge SFP+) has disappeared
> from their web site altogether.
>
> I'm concerned about the Vyatta CLI docs and their continuing
> availability.  Someone from Brocade should make some public statements
> to set our collective minds at ease.
>
> That said I've been reasonably happy with the UBNT stuff (mostly older
> outdoor gear) that I've bought over the past several years.  It's held
> up well.  Just don't count on the availability of anything that you
> can't order up from your favorite VAR and have it show up in the
> FedEx.
>
> -r
>
>


-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

From morrowc.lists at gmail.com  Mon Nov 25 14:47:45 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 25 Nov 2013 09:47:45 -0500
Subject: telnet into a netgear switch?
In-Reply-To: <CAOMvUQfeM_Wnc=eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ@mail.gmail.com>
References: <CAOMvUQfeM_Wnc=eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ@mail.gmail.com>
Message-ID: <CAL9jLabMH1hBECUKNAjum5Ef2P8AmdsZjysN6AKiL3CAhaROdw@mail.gmail.com>

On Sun, Nov 24, 2013 at 9:47 PM, David Birdsong <david at imgix.com> wrote:
> JGS524E


kinda thinking that:
"NETGEAR 24 Port Gigabit Unmanged Plus Business-Class Rackmount Switch
- Lifetime Warranty (JGS524E)"

coupled with:
"Network Management Type Unmanaged"

on:
<http://www.newegg.com/Product/Product.aspx?Item=N82E16833122404>

means you are boned.


From garrett at skjelstad.org  Mon Nov 25 15:00:46 2013
From: garrett at skjelstad.org (Garrett Skjelstad)
Date: Mon, 25 Nov 2013 07:00:46 -0800
Subject: telnet into a netgear switch?
In-Reply-To: <CAOMvUQfeM_Wnc=eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ@mail.gmail.com>
References: <CAOMvUQfeM_Wnc=eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ@mail.gmail.com>
Message-ID: <62199D9D-B29E-4AD4-80F6-26048349A911@skjelstad.org>

That netgear link you submitted is primarily for routers, not switches.

Sent from my (old) iPhone5

On Nov 24, 2013, at 18:47, David Birdsong <david at imgix.com> wrote:

> Hey all, last night while at the datacenter I was in a pinch to extend a
> rack's LAN. I compromised and ran out to the local Fry's to buy whatever
> switch I could find so as to allow some configuration to happen while
> we wait for the real network gear to show up.
> 
> I left before confirming I could access the switch remotely; it was very
> late and I was pretty groggy and hey, any network gear has to be
> telnet'table this day and age. Of course I was mostly wrong.
> 
> The switch expects some signed payload before allowing a telnet through. I
> found this: https://code.google.com/p/netgear-telnetenable/...but I'm
> having a hell of a time getting anything to respond.
> 
> The most confounding part is the switch doesn't respond to a single SYN
> packet on low ports. I'm scanning all the ports now, but if nothing shows
> up, I'm not sure what a payload is good for if the switch doesn't ACK a
> single SYN.
> 
> I'm curious if anybody's got any tips besides not using Netgear in the
> datacenter.
> 
> I have the MAC, I've IP'd it via DHCP, and the model number: JGS524E and I
> can power cycle the switch as much as needed.
> 
> 
> P.S. long time listener, first time caller. i'm more of a sysadmin
> dangerously standing in for a proper network person.


From david at imgix.com  Mon Nov 25 18:38:35 2013
From: david at imgix.com (David Birdsong)
Date: Mon, 25 Nov 2013 10:38:35 -0800
Subject: telnet into a netgear switch?
In-Reply-To: <CAL9jLabMH1hBECUKNAjum5Ef2P8AmdsZjysN6AKiL3CAhaROdw@mail.gmail.com>
References: <CAOMvUQfeM_Wnc=eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ@mail.gmail.com>
 <CAL9jLabMH1hBECUKNAjum5Ef2P8AmdsZjysN6AKiL3CAhaROdw@mail.gmail.com>
Message-ID: <CAOMvUQdndQEEeuH=RqPMVEgHxbOqrNOcyJ0Z1v108R4X233RtA@mail.gmail.com>

On Nov 25, 2013 6:47 AM, "Christopher Morrow" <morrowc.lists at gmail.com>
wrote:
>
> On Sun, Nov 24, 2013 at 9:47 PM, David Birdsong <david at imgix.com> wrote:
> > JGS524E
>
>
> kinda thinking that:
> "NETGEAR 24 Port Gigabit Unmanged Plus Business-Class Rackmount Switch
> - Lifetime Warranty (JGS524E)"
>
> coupled with:
> "Network Management Type Unmanaged"
>
> on:
> <http://www.newegg.com/Product/Product.aspx?Item=N82E16833122404>
>
> means you are boned.

Good catch. I ripped it out of the box, racked and cabled it, tossed the
trash and went home fully expecting to sort it out w/ nmap, tcpdump, tftp
etc...

I guess I am sorted out now.

From elouie at yahoo.com  Mon Nov 25 18:48:15 2013
From: elouie at yahoo.com (Eric A Louie)
Date: Mon, 25 Nov 2013 10:48:15 -0800 (PST)
Subject: BGP neighbor/configuration testing
In-Reply-To: <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
Message-ID: <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>

The turn-up was unsuccessful.? The provider and I could not get an Established BGP session.? Here's the log results from my router:

Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor xxx.118.92.149 2/5 (authentication failure) 0 bytes
Nov 25 06:29:09.690 pacific: %BGP-5-ADJCHANGE: neighbor xxx.118.92.149 Up
Nov 25 06:29:10.562 pacific: %BGP-3-NOTIFICATION: received from neighbor xxx.118.92.149 6/1 (cease) 7 bytes 00010100 000320
Nov 25 06:29:10.562 pacific: %BGP-5-ADJCHANGE: neighbor xxx.118.92.149 Down BGP Notification received

My interface is at xxx.118.92.150.? They scrubbed their (Juniper) configuration and said all looks good.? I scrubbed my (Cisco) configuration - all I had was "neighbor xxx.118.92.149 remote-as xx9" and couldn't get the neighbor established.

Pings to xxx.118.92.149 are successful.? I have the output of "sh tcp brief all" and "sh tcp" - we are not getting the TCP connection to stay up.

Has anyone seen this series of messages on a Cisco/Juniper BGP session?? Any resolution?






>________________________________
> From: Joe Abley <jabley at hopcount.ca>
>To: Eric A Louie <elouie at yahoo.com> 
>Cc: "nanog at nanog.org" <nanog at nanog.org> 
>Sent: Wednesday, November 20, 2013 12:01 PM
>Subject: Re: BGP neighbor/configuration testing
> 
>
>
>On 2013-11-20, at 14:53, Eric A Louie <elouie at yahoo.com> wrote:
>
>> Scenario: a regional ISP preparing to cutover to a new upstream BGP provider at one of my POPs.? Want minimal or no network disruption, and want to ensure everything is ready to go prior to the cutover.
>> 
>>? I'm planning to use the following order of operations:
>> 1. Establish IP connectivity to the new ISP (already done)
>> 2. Configure my BGP router and shutdown the new neighbor (ISP says their side is already configured and ready)
>
>Leave the adjacency up, and just deny all inbound and outbound on the corresponding route filter. You never want a maintenance's success to depend on "no neigh x.x.x.x shut" working smoothly; much better to be able to confirm that the session is up before you start and just change the import/export policy.
>
>> 3. During the maintenance window for this change, activate the new BGP connection (remove neighbor shutdown)
>> 4. Do the appropriate tests (sh bgp nei, login to my upstream's route server and check route advertisements, sign in to looking glass and/or route servers from other providers to see if my routes from the new ISP are being advertised, and I'm open to any other tests)
>
>You could insert "wait N days" here, with a rollback plan (e.g. in case of customer-enraging congestion or packet loss) that restores the original configuration by shutting down the new adjacency.
>
>> 5. Turn down the old connection (neighbor shutdown)
>> 6. Watch the old connection get removed from route servers/looking glasses from step 4
>> 
>> A. Does that order make sense or does it need some tweaking, additions, or "other"?
>> 
>> B. I'd like to test the new upstream BGP configuration without passing traffic to and through it.? What can I do (if anything) on my configuration end to put up the BGP configuration, establish a neighbor connection, and NOT actually pass any traffic through it?? After putting my configuration up, I'd like to do a show bgp nei 1.1.1.1 advertised-routes to ensure my routes are going out, and then shut the neighbor down until the cutover.
>
>Bring the session up with deny all in both directions, and use the appropriate show commands (show neigh ... received-routes since you're talking cisco) to show what routes were received upstream of the filter. You are presumably already testing your export policy on your live session; if the configuration on the new session is the same, then you're really just talking about making sure that the internal route set visible on the router with the new session is right.
>
>
>Joe
>
>
>

From drohan at gmail.com  Mon Nov 25 18:55:40 2013
From: drohan at gmail.com (Daniel Rohan)
Date: Mon, 25 Nov 2013 10:55:40 -0800
Subject: BGP neighbor/configuration testing
In-Reply-To: <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
 <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>
Message-ID: <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>

Seems like:


> Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor
> xxx.118.92.149 2/5 (authentication failure) 0 bytes
>

should be a good starting place. I'm assuming you've already discussed auth
keys with your provider and if everyone is putting that in correctly, I'd
suggest turning on debugging to see what exactly that message is all about.

Dan

From jstuppi at cisco.com  Mon Nov 25 19:00:53 2013
From: jstuppi at cisco.com (John Stuppi (jstuppi))
Date: Mon, 25 Nov 2013 19:00:53 +0000
Subject: BGP neighbor/configuration testing
In-Reply-To: <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
 <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>
Message-ID: <3FA32E339980EB4BBB4935C00A6A8F2921898BEE@xmb-aln-x09.cisco.com>

Here are a couple of examples of syslog messages that could be seen depending on the configuration of the MD5 passwords on each side:

Troubleshooting Examples

If BGP neighbor authentication is incorrectly configured (for example, it is either configured on only one peer or the MD5 shared secret (password) does not match on both peers), the following types of syslog messages will be generated:

No Password Set on Remote Peer

    Dec 3 15:01:52: %TCP-6-BADAUTH: 
    No MD5 digest from 192.0.2.2(179) to 192.0.2.1(51954)

Incorrect Password Set on Remote Peer

    Dec 3 15:01:57: %TCP-6-BADAUTH: 
    Invalid MD5 digest from 192.0.2.2(22285) to 192.0.2.1(179)


Thanks,
John

"We can't help everyone, but everyone can help someone."

 


John Stuppi, CISSP
Technical Leader
Strategic Security Research
jstuppi at cisco.com
Phone: +1 732 516 5994
Mobile: 732 319 3886

CCIE, Security - 11154
Cisco Systems
Mail Stop INJ01/2/ 
111 Wood Avenue South 
Iselin, New Jersey 08830
United States
Cisco.com



Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html





-----Original Message-----
From: Daniel Rohan [mailto:drohan at gmail.com] 
Sent: Monday, November 25, 2013 1:56 PM
To: Eric A Louie
Cc: nanog at nanog.org
Subject: Re: BGP neighbor/configuration testing

Seems like:


> Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from 
> neighbor
> xxx.118.92.149 2/5 (authentication failure) 0 bytes
>

should be a good starting place. I'm assuming you've already discussed auth keys with your provider and if everyone is putting that in correctly, I'd suggest turning on debugging to see what exactly that message is all about.

Dan


From elouie at yahoo.com  Mon Nov 25 19:06:33 2013
From: elouie at yahoo.com (Eric A Louie)
Date: Mon, 25 Nov 2013 11:06:33 -0800 (PST)
Subject: BGP neighbor/configuration testing
In-Reply-To: <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
 <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>
Message-ID: <1385406393.14461.YahooMailNeo@web181606.mail.ne1.yahoo.com>

That's a natural first impression but there are no passwords configured on the BGP session on either router.? I know it looks like an authentication error but it's a "misnomer" (at least from the searches I did on the error message).? From the sequence of messages, we get Established and 2 seconds later the session Closes.? The reason for the Close may lead us to the solution.

I'm reluctant to turn on debug bgp because this is a live production router, and if I hose it, there will be a lot of 'splainin to do [1]

[1]?http://www.quotecounterquote.com/2011/05/lucy-you-got-some-splainin-to-do.html





>________________________________
> From: Daniel Rohan <drohan at gmail.com>
>To: Eric A Louie <elouie at yahoo.com> 
>Cc: Joe Abley <jabley at hopcount.ca>; "nanog at nanog.org" <nanog at nanog.org> 
>Sent: Monday, November 25, 2013 10:55 AM
>Subject: Re: BGP neighbor/configuration testing
> 
>
>
>Seems like:
>?
>Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor xxx.118.92.149 2/5 (authentication failure) 0 bytes
>>
>should be a good starting place. I'm assuming you've already discussed auth keys with your provider and if everyone is putting that in correctly, I'd suggest turning on debugging to see what exactly that message is all about.?
>
>
>Dan?
>
>

From cra at WPI.EDU  Mon Nov 25 19:10:52 2013
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 25 Nov 2013 14:10:52 -0500
Subject: BGP neighbor/configuration testing
In-Reply-To: <1385406393.14461.YahooMailNeo@web181606.mail.ne1.yahoo.com>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
 <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>
 <1385406393.14461.YahooMailNeo@web181606.mail.ne1.yahoo.com>
Message-ID: <20131125191052.GH16082@angus.ind.WPI.EDU>

Authentication failure might mean (without knowing for sure which on
Cisco):

- mismatch AS numbers
- mismatch neighbor IP addresses
- multihop/TTL issues
- MTU issues

On Mon, Nov 25, 2013 at 11:06:33AM -0800, Eric A Louie wrote:
> That's a natural first impression but there are no passwords configured on the BGP session on either router.? I know it looks like an authentication error but it's a "misnomer" (at least from the searches I did on the error message).? From the sequence of messages, we get Established and 2 seconds later the session Closes.? The reason for the Close may lead us to the solution.
> 
> I'm reluctant to turn on debug bgp because this is a live production router, and if I hose it, there will be a lot of 'splainin to do [1]
> 
> [1]?http://www.quotecounterquote.com/2011/05/lucy-you-got-some-splainin-to-do.html
> 
> 
> 
> 
> 
> >________________________________
> > From: Daniel Rohan <drohan at gmail.com>
> >To: Eric A Louie <elouie at yahoo.com> 
> >Cc: Joe Abley <jabley at hopcount.ca>; "nanog at nanog.org" <nanog at nanog.org> 
> >Sent: Monday, November 25, 2013 10:55 AM
> >Subject: Re: BGP neighbor/configuration testing
> > 
> >
> >
> >Seems like:
> >?
> >Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor xxx.118.92.149 2/5 (authentication failure) 0 bytes
> >>
> >should be a good starting place. I'm assuming you've already discussed auth keys with your provider and if everyone is putting that in correctly, I'd suggest turning on debugging to see what exactly that message is all about.?
> >
> >
> >Dan?


From boards188 at gmail.com  Mon Nov 25 19:49:07 2013
From: boards188 at gmail.com (Jason Pope)
Date: Mon, 25 Nov 2013 13:49:07 -0600
Subject: telnet into a netgear switch?
Message-ID: <CAEqUV_hT7oq_L72M1YCzqdhKvux+Y=Y1ow1wo5T3AeuUXKVD0g@mail.gmail.com>

------------------------------
Message: 2
Date: Sun, 24 Nov 2013 18:47:09 -0800
From: David Birdsong <david at imgix.com>
To: nanog at nanog.org
Subject: telnet into a netgear switch?
Message-ID:
        <CAOMvUQfeM_Wnc=eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hey all, last night while at the datacenter I was in a pinch to extend a
rack's LAN. I compromised and ran out to the local Fry's to buy whatever
switch I could find so as to allow some configuration to happen while
we wait for the real network gear to show up.

I left before confirming I could access the switch remotely; it was very
late and I was pretty groggy and hey, any network gear has to be
telnet'table this day and age. Of course I was mostly wrong.

The switch expects some signed payload before allowing a telnet through. I
found this: https://code.google.com/p/netgear-telnetenable/...but I'm
having a hell of a time getting anything to respond.

The most confounding part is the switch doesn't respond to a single SYN
packet on low ports. I'm scanning all the ports now, but if nothing shows
up, I'm not sure what a payload is good for if the switch doesn't ACK a
single SYN.

I'm curious if anybody's got any tips besides not using Netgear in the
datacenter.

I have the MAC, I've IP'd it via DHCP, and the model number: JGS524E and I
can power cycle the switch as much as needed.


P.S. long time listener, first time caller. i'm more of a sysadmin
dangerously standing in for a proper network person.
------------------------------

Seems to me that you need to use their "Switch Configuration Utility" to
manage the switch.  I didn't read all the documentation, but that is what
jumps out at me after a brief look.  Maybe it will allow you to enable
telnet or ssh from there.  See the following link:

http://downloadcenter.netgear.com/en/product/JGS524E

Jason

From elouie at yahoo.com  Mon Nov 25 23:07:28 2013
From: elouie at yahoo.com (Eric A Louie)
Date: Mon, 25 Nov 2013 15:07:28 -0800 (PST)
Subject: BGP neighbor/configuration testing
In-Reply-To: <20131125191052.GH16082@angus.ind.WPI.EDU>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
 <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>
 <1385406393.14461.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <20131125191052.GH16082@angus.ind.WPI.EDU>
Message-ID: <1385420848.94661.YahooMailNeo@web181604.mail.ne1.yahoo.com>

All Cisco/Cisco, I don't have a Juniper here to test with

mismatch AS
*Apr? 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39

mismatch neighbor IP address
no logged error

MTU mismatch
no logged error, session remained up

Subnet mask mismatch
session remained up, no logged error

I haven't created the multihop scenario to see the error messages.


None of these issues caused the (authentication failure).





>________________________________
> From: Chuck Anderson <cra at WPI.EDU>
>To: nanog at nanog.org 
>Sent: Monday, November 25, 2013 11:10 AM
>Subject: Re: BGP neighbor/configuration testing
> 
>
>Authentication failure might mean (without knowing for sure which on
>Cisco):
>
>- mismatch AS numbers
>- mismatch neighbor IP addresses
>- multihop/TTL issues
>- MTU issues
>
>On Mon, Nov 25, 2013 at 11:06:33AM -0800, Eric A Louie wrote:
>> That's a natural first impression but there are no passwords configured on the BGP session on either router.? I know it looks like an authentication error but it's a "misnomer" (at least from the searches I did on the error message).? From the sequence of messages, we get Established and 2 seconds later the session Closes.? The reason for the Close may lead us to the solution.
>> 
>> I'm reluctant to turn on debug bgp because this is a live production router, and if I hose it, there will be a lot of 'splainin to do [1]
>> 
>> [1]?http://www.quotecounterquote.com/2011/05/lucy-you-got-some-splainin-to-do.html
>> 
>> 
>> 
>> 
>> 
>> >________________________________
>> > From: Daniel Rohan <drohan at gmail.com>
>> >To: Eric A Louie <elouie at yahoo.com> 
>> >Cc: Joe Abley <jabley at hopcount.ca>; "nanog at nanog.org" <nanog at nanog.org> 
>> >Sent: Monday, November 25, 2013 10:55 AM
>> >Subject: Re: BGP neighbor/configuration testing
>> > 
>> >
>> >
>> >Seems like:
>> >?
>> >Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor xxx.118.92.149 2/5 (authentication failure) 0 bytes
>> >>
>> >should be a good starting place. I'm assuming you've already discussed auth keys with your provider and if everyone is putting that in correctly, I'd suggest turning on debugging to see what exactly that message is all about.?
>> >
>> >
>> >Dan?
>
>
>
>

From pmsac.nanog at gmail.com  Mon Nov 25 23:26:41 2013
From: pmsac.nanog at gmail.com (Pedro Cavaca)
Date: Mon, 25 Nov 2013 23:26:41 +0000
Subject: BGP neighbor/configuration testing
In-Reply-To: <1385420848.94661.YahooMailNeo@web181604.mail.ne1.yahoo.com>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
 <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>
 <1385406393.14461.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <20131125191052.GH16082@angus.ind.WPI.EDU>
 <1385420848.94661.YahooMailNeo@web181604.mail.ne1.yahoo.com>
Message-ID: <CAE42oJpqA=S4uBZVh7EmbTN-cUCsqGJFuy_o-8tO4E8F40cQjA@mail.gmail.com>

The auth error was transient, forget about it.

Now you're getting 6/1 - maximum number of prefixes reached.

http://tools.ietf.org/html/rfc4486
(or
http://backupsalmanaja.blogspot.ie/2009/12/bgp-cease-notification-messages.htmlif
you prefer).

HTH



On 25 November 2013 23:07, Eric A Louie <elouie at yahoo.com> wrote:

> All Cisco/Cisco, I don't have a Juniper here to test with
>
> mismatch AS
> *Apr  9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor
> 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39
>
> mismatch neighbor IP address
> no logged error
>
> MTU mismatch
> no logged error, session remained up
>
> Subnet mask mismatch
> session remained up, no logged error
>
> I haven't created the multihop scenario to see the error messages.
>
>
> None of these issues caused the (authentication failure).
>
>
>
>
>
> >________________________________
> > From: Chuck Anderson <cra at WPI.EDU>
> >To: nanog at nanog.org
> >Sent: Monday, November 25, 2013 11:10 AM
> >Subject: Re: BGP neighbor/configuration testing
> >
> >
> >Authentication failure might mean (without knowing for sure which on
> >Cisco):
> >
> >- mismatch AS numbers
> >- mismatch neighbor IP addresses
> >- multihop/TTL issues
> >- MTU issues
> >
> >On Mon, Nov 25, 2013 at 11:06:33AM -0800, Eric A Louie wrote:
> >> That's a natural first impression but there are no passwords configured
> on the BGP session on either router.  I know it looks like an
> authentication error but it's a "misnomer" (at least from the searches I
> did on the error message).  From the sequence of messages, we get
> Established and 2 seconds later the session Closes.  The reason for the
> Close may lead us to the solution.
> >>
> >> I'm reluctant to turn on debug bgp because this is a live production
> router, and if I hose it, there will be a lot of 'splainin to do [1]
> >>
> >> [1]
> http://www.quotecounterquote.com/2011/05/lucy-you-got-some-splainin-to-do.html
> >>
> >>
> >>
> >>
> >>
> >> >________________________________
> >> > From: Daniel Rohan <drohan at gmail.com>
> >> >To: Eric A Louie <elouie at yahoo.com>
> >> >Cc: Joe Abley <jabley at hopcount.ca>; "nanog at nanog.org" <nanog at nanog.org
> >
> >> >Sent: Monday, November 25, 2013 10:55 AM
> >> >Subject: Re: BGP neighbor/configuration testing
> >> >
> >> >
> >> >
> >> >Seems like:
> >> >
> >> >Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from
> neighbor xxx.118.92.149 2/5 (authentication failure) 0 bytes
> >> >>
> >> >should be a good starting place. I'm assuming you've already discussed
> auth keys with your provider and if everyone is putting that in correctly,
> I'd suggest turning on debugging to see what exactly that message is all
> about.
> >> >
> >> >
> >> >Dan
> >
> >
> >
> >
>

From cra at WPI.EDU  Mon Nov 25 23:37:49 2013
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 25 Nov 2013 18:37:49 -0500
Subject: BGP neighbor/configuration testing
In-Reply-To: <1385420848.94661.YahooMailNeo@web181604.mail.ne1.yahoo.com>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
 <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>
 <1385406393.14461.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <20131125191052.GH16082@angus.ind.WPI.EDU>
 <1385420848.94661.YahooMailNeo@web181604.mail.ne1.yahoo.com>
Message-ID: <20131125233748.GL16082@angus.ind.WPI.EDU>

When you say "no logged error" with mismatched neighbor IP address,
what do you mean?  Did the session just not establish at all?  How
long did you wait for it to attempt to establish?

On Juniper, if it sees a BGP connection come from an IP address that
doesn't match a local "neighbor" statement, it will send a BGP
Notification, code 2 (Open Message Error), subcode 5 (authentication
failure), which is exactly what you are seeing.

If one side is using a loopback IP instead of a physical IP for the
local-address, that would cause both a multihop/TTL issue and a
neighbor IP mismatch.

Another possibility is if you have exceeded the max prefix limit for
the session.  One side will get stuck in Idle state which may cause
the other side to send the same "authentication failure" notification.

On Mon, Nov 25, 2013 at 03:07:28PM -0800, Eric A Louie wrote:
> All Cisco/Cisco, I don't have a Juniper here to test with
> 
> mismatch AS
> *Apr? 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39
> 
> mismatch neighbor IP address
> no logged error
> 
> MTU mismatch
> no logged error, session remained up
> 
> Subnet mask mismatch
> session remained up, no logged error
> 
> I haven't created the multihop scenario to see the error messages.
> 
> 
> None of these issues caused the (authentication failure).
> 
> 
> 
> 
> 
> >________________________________
> > From: Chuck Anderson <cra at WPI.EDU>
> >To: nanog at nanog.org 
> >Sent: Monday, November 25, 2013 11:10 AM
> >Subject: Re: BGP neighbor/configuration testing
> > 
> >
> >Authentication failure might mean (without knowing for sure which on
> >Cisco):
> >
> >- mismatch AS numbers
> >- mismatch neighbor IP addresses
> >- multihop/TTL issues
> >- MTU issues


From david at imgix.com  Mon Nov 25 23:42:21 2013
From: david at imgix.com (David Birdsong)
Date: Mon, 25 Nov 2013 15:42:21 -0800
Subject: telnet into a netgear switch?
In-Reply-To: <CAEqUV_hT7oq_L72M1YCzqdhKvux+Y=Y1ow1wo5T3AeuUXKVD0g@mail.gmail.com>
References: <CAEqUV_hT7oq_L72M1YCzqdhKvux+Y=Y1ow1wo5T3AeuUXKVD0g@mail.gmail.com>
Message-ID: <CAOMvUQdS9JZ0kD9du+nVF6D4h3CJgE+gOLsBrNfBp6Hw+XVv0g@mail.gmail.com>

On Nov 25, 2013 1:51 PM, "Jason Pope" <boards188 at gmail.com> wrote:
>
> ------------------------------
> Message: 2
> Date: Sun, 24 Nov 2013 18:47:09 -0800
> From: David Birdsong <david at imgix.com>
> To: nanog at nanog.org
> Subject: telnet into a netgear switch?
> Message-ID:
>         <CAOMvUQfeM_Wnc=
eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hey all, last night while at the datacenter I was in a pinch to extend a
> rack's LAN. I compromised and ran out to the local Fry's to buy whatever
> switch I could find so as to allow some configuration to happen while
> we wait for the real network gear to show up.
>
> I left before confirming I could access the switch remotely; it was very
> late and I was pretty groggy and hey, any network gear has to be
> telnet'table this day and age. Of course I was mostly wrong.
>
> The switch expects some signed payload before allowing a telnet through. I
> found this: https://code.google.com/p/netgear-telnetenable/...but I'm
> having a hell of a time getting anything to respond.
>
> The most confounding part is the switch doesn't respond to a single SYN
> packet on low ports. I'm scanning all the ports now, but if nothing shows
> up, I'm not sure what a payload is good for if the switch doesn't ACK a
> single SYN.
>
> I'm curious if anybody's got any tips besides not using Netgear in the
> datacenter.
>
> I have the MAC, I've IP'd it via DHCP, and the model number: JGS524E and I
> can power cycle the switch as much as needed.
>
>
> P.S. long time listener, first time caller. i'm more of a sysadmin
> dangerously standing in for a proper network person.
> ------------------------------
>
> Seems to me that you need to use their "Switch Configuration Utility" to
> manage the switch.  I didn't read all the documentation, but that is what
> jumps out at me after a brief look.  Maybe it will allow you to enable
> telnet or ssh from there.  See the following link:
>

No windows box handy, nor the desire for that hoop.

...but what magic is a windows app going to perform to wake up an
unresponsive TCP stack?

> http://downloadcenter.netgear.com/en/product/JGS524E
>
> Jason

From silvertip257 at gmail.com  Mon Nov 25 23:47:05 2013
From: silvertip257 at gmail.com (SilverTip257)
Date: Mon, 25 Nov 2013 18:47:05 -0500
Subject: Meraki
Message-ID: <CA+W-zopQpRzpOCXfBjyC1o9i0r_mEHujah94Q4LQenoBv9YWew@mail.gmail.com>

>
> Date: Mon, 25 Nov 2013 09:32:10 -0500
> From: Ray Soucy <rps at maine.edu>
> To: Rob Seastrom <rs at seastrom.com>
> Cc: NANOG <nanog at nanog.org>
> Subject: Re: Meraki
> Message-ID:
>         <
> CALFTrnPpBQLHRRDkMnt1nz8Wi0k3B6KEmt9tbgNS-wfRHqSnqQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> It looks like Brocade has swapped out Quagga with IP Infusion's non-free
> version, ZebOS.  They also decided to abandon the FOSS Vyatta Core project.
>

A number of years back it was interesting to see Vyatta switch from XORP
[0] to Quagga.  I found out quite a while after they made the move.

Bummer.
This move by Brocade is unfortunate.


>
> It's really unfortunate, as the FOSS project is the only reason I was
> interested in paying the licensing.  It was attractive to have Vyatta Core
> as a no-cost option for small things, and the subscription edition for
> higher visibility devices.  Now that they've moved away from having any
> FOSS project, I'm not really inclined to invest in the product, I'm sure
> there are others who feel the same way.


> There is a group of people who were active in the Vyatta community trying
> to get a fork of it going under the name VyOS, http://www.vyos.net/


Thanks for pointing out VyOS.


>
>
> As far as Ubiquiti, it looks like about 2 years ago they actually hired a
> few people from Vyatta, Inc. to work on EdgeOS.  So development of EdgeOS
> has continued [and likely will continue] independently, though it looks
> like at least a few people from UBNT are interested in seeing VyOS happen
> and participating on their own time.  I know one of the early goals for
> VyOS is to get the documentation up on their Wiki and have a release of the
> current Vyatta Core with the name swapped out as a starting point.
>

For those of you that purchased EdgeRouter Lite (ERLite-3) [2] units
recently, do they come in plastic enclosure or the steel enclosure like the
EdgeRouter PoE (ERPoe-5) [3] units?  We got a few of each in at the office
at different times (first ERL and later ERPoe).  Just curious.

I guess I'm spoiled ... I like the metal case much better than the plastic
ones.  Once I saw the case of the PoE model and saw the new pictures [4]
for the ERL on Ubiquiti's site I've been holding out purchasing an ERL for
my home.  I should bug our distributor, but I doubt they'd know since they
aren't opening the boxes prior to shipment.

Although a commercial alternative, Mikrotik hardware (ex: RB750GL [1]) and
OS is attractive.  It appears all Mikrotik "integrated solutions" include
some sort of enclosure (see www.routerboard.com).  The CLI takes some
getting used to, but the syntax makes sense after a while. ;)  There's also
a webui called webfig and a Windows client called Winbox.


>
> I really hope the VyOS project can get off the ground.  If any developers
> familiar with maintaining Debian-based distributions are on-list, I know
> the project is looking for people to help.
>
>
+1
I hope VyOS project succeeds.


[0] http://en.wikipedia.org/wiki/XORP
[1] http://routerboard.com/RB750GL
[2]
http://www.ubnt.com/media/product/edgemax/hardware-overview/edgerouter-lite-1.jpg
[3]
http://www.ubnt.com/media/product/edgemax/hardware-overview/edgerouter-poe-1.jpg
[4] http://www.ubnt.com/edgemax#EdgeMAXhardware

-- 
---~~.~~---
Mike
//  SilverTip257  //

From pmsac.nanog at gmail.com  Tue Nov 26 01:18:25 2013
From: pmsac.nanog at gmail.com (Pedro Cavaca)
Date: Tue, 26 Nov 2013 01:18:25 +0000
Subject: telnet into a netgear switch?
In-Reply-To: <CAOMvUQdS9JZ0kD9du+nVF6D4h3CJgE+gOLsBrNfBp6Hw+XVv0g@mail.gmail.com>
References: <CAEqUV_hT7oq_L72M1YCzqdhKvux+Y=Y1ow1wo5T3AeuUXKVD0g@mail.gmail.com>
 <CAOMvUQdS9JZ0kD9du+nVF6D4h3CJgE+gOLsBrNfBp6Hw+XVv0g@mail.gmail.com>
Message-ID: <CAE42oJowLwCA+=F4ATuDMruTfA5b2nguTg1h_S0MHps=UHa=oQ@mail.gmail.com>

On 25 November 2013 23:42, David Birdsong <david at imgix.com> wrote:

> On Nov 25, 2013 1:51 PM, "Jason Pope" <boards188 at gmail.com> wrote:
> >
> > ------------------------------
> > Message: 2
> > Date: Sun, 24 Nov 2013 18:47:09 -0800
> > From: David Birdsong <david at imgix.com>
> > To: nanog at nanog.org
> > Subject: telnet into a netgear switch?
> > Message-ID:
> >         <CAOMvUQfeM_Wnc=
> eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hey all, last night while at the datacenter I was in a pinch to extend a
> > rack's LAN. I compromised and ran out to the local Fry's to buy whatever
> > switch I could find so as to allow some configuration to happen while
> > we wait for the real network gear to show up.
> >
> > I left before confirming I could access the switch remotely; it was very
> > late and I was pretty groggy and hey, any network gear has to be
> > telnet'table this day and age. Of course I was mostly wrong.
> >
> > The switch expects some signed payload before allowing a telnet through.
> I
> > found this: https://code.google.com/p/netgear-telnetenable/...but I'm
> > having a hell of a time getting anything to respond.
> >
> > The most confounding part is the switch doesn't respond to a single SYN
> > packet on low ports. I'm scanning all the ports now, but if nothing shows
> > up, I'm not sure what a payload is good for if the switch doesn't ACK a
> > single SYN.
> >
> > I'm curious if anybody's got any tips besides not using Netgear in the
> > datacenter.
> >
> > I have the MAC, I've IP'd it via DHCP, and the model number: JGS524E and
> I
> > can power cycle the switch as much as needed.
> >
> >
> > P.S. long time listener, first time caller. i'm more of a sysadmin
> > dangerously standing in for a proper network person.
> > ------------------------------
> >
> > Seems to me that you need to use their "Switch Configuration Utility" to
> > manage the switch.  I didn't read all the documentation, but that is what
> > jumps out at me after a brief look.  Maybe it will allow you to enable
> > telnet or ssh from there.  See the following link:
> >
>
> No windows box handy, nor the desire for that hoop.
>
> ...but what magic is a windows app going to perform to wake up an
> unresponsive TCP stack?
>

In view that the application needs to be run directly on the LAN, I'm not
sure why you'd expect any TCP/IP like protocol - I asked a friend for a
packet capture and it seems that the configuration utility is using RRCP (
http://en.wikipedia.org/wiki/Realtek_Remote_Control_Protocol).

HTH


> > http://downloadcenter.netgear.com/en/product/JGS524E
> >
> > Jason
>

From geraint at koding.com  Mon Nov 25 23:50:01 2013
From: geraint at koding.com (Geraint Jones)
Date: Tue, 26 Nov 2013 12:50:01 +1300
Subject: telnet into a netgear switch?
In-Reply-To: <CAOMvUQdS9JZ0kD9du+nVF6D4h3CJgE+gOLsBrNfBp6Hw+XVv0g@mail.gmail.com>
Message-ID: <CEBA4923.168A5%geraint@koding.com>

It could be any number of things, APC for example need a vendor option set
in DHCP or a ?Magic? ping. It could be that the app just talks to it on L2
like Microtik?s. I suspect the windows app will be your only option.
-- 
Geraint Jones






On 26/11/13 12:42 pm, "David Birdsong" <david at imgix.com> wrote:

>On Nov 25, 2013 1:51 PM, "Jason Pope" <boards188 at gmail.com> wrote:
>>
>> ------------------------------
>> Message: 2
>> Date: Sun, 24 Nov 2013 18:47:09 -0800
>> From: David Birdsong <david at imgix.com>
>> To: nanog at nanog.org
>> Subject: telnet into a netgear switch?
>> Message-ID:
>>         <CAOMvUQfeM_Wnc=
>eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hey all, last night while at the datacenter I was in a pinch to extend a
>> rack's LAN. I compromised and ran out to the local Fry's to buy whatever
>> switch I could find so as to allow some configuration to happen while
>> we wait for the real network gear to show up.
>>
>> I left before confirming I could access the switch remotely; it was very
>> late and I was pretty groggy and hey, any network gear has to be
>> telnet'table this day and age. Of course I was mostly wrong.
>>
>> The switch expects some signed payload before allowing a telnet
>>through. I
>> found this: https://code.google.com/p/netgear-telnetenable/...but I'm
>> having a hell of a time getting anything to respond.
>>
>> The most confounding part is the switch doesn't respond to a single SYN
>> packet on low ports. I'm scanning all the ports now, but if nothing
>>shows
>> up, I'm not sure what a payload is good for if the switch doesn't ACK a
>> single SYN.
>>
>> I'm curious if anybody's got any tips besides not using Netgear in the
>> datacenter.
>>
>> I have the MAC, I've IP'd it via DHCP, and the model number: JGS524E
>>and I
>> can power cycle the switch as much as needed.
>>
>>
>> P.S. long time listener, first time caller. i'm more of a sysadmin
>> dangerously standing in for a proper network person.
>> ------------------------------
>>
>> Seems to me that you need to use their "Switch Configuration Utility" to
>> manage the switch.  I didn't read all the documentation, but that is
>>what
>> jumps out at me after a brief look.  Maybe it will allow you to enable
>> telnet or ssh from there.  See the following link:
>>
>
>No windows box handy, nor the desire for that hoop.
>
>...but what magic is a windows app going to perform to wake up an
>unresponsive TCP stack?
>
>> http://downloadcenter.netgear.com/en/product/JGS524E
>>
>> Jason




From elouie at yahoo.com  Tue Nov 26 01:21:26 2013
From: elouie at yahoo.com (Eric A Louie)
Date: Mon, 25 Nov 2013 17:21:26 -0800 (PST)
Subject: BGP neighbor/configuration testing
In-Reply-To: <20131125233748.GL16082@angus.ind.WPI.EDU>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
 <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>
 <1385406393.14461.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <20131125191052.GH16082@angus.ind.WPI.EDU>
 <1385420848.94661.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <20131125233748.GL16082@angus.ind.WPI.EDU>
Message-ID: <1385428886.54024.YahooMailNeo@web181603.mail.ne1.yahoo.com>

No logged error with mismatched neighbor IP address - neither router had an entry.? Session did not establish nor go active, I could wait forever and neither would happen.? Point is, an error message is not generated on the downstream router so it's probably not the cause for the error message.

I asked my upstream to check if the "local interface" command was being used (that would cause the multihop, but I did put in 2 or 3 as the ebgp-multihop value and still didn't get the session up.

Your last comment about max-prefix is probably the problem and the solution.? Right now, the entire configuration is in the router with a "neighbor shutdown".? When we bring it up tomorrow, the filters will all be there so that only 13 of my prefixes are advertised, hopefully keeping the BGP session up and closing this saga.? (the router already has another upstream connected, so when I turned up the neighbor without a filter, I flooded the upstream's router with routes, but it took us this long to figure that out.) 




On a Cisco to Cisco when the max-prefixes is exceeded and there's a restart specified, the error (on the offender) is not quite the same as the error I'm seeing:
*Apr? 9 02:41:39.827: %BGP-3-NOTIFICATION: received from neighbor 10.250.254.253 3/1 (update malformed) 0 bytes
*Apr? 9 02:41:39.827: %BGP-5-ADJCHANGE: neighbor 10.250.254.253 Down BGP Notification received

On the upstream (where the max-prefix was configured), 

*Nov 26 04:10:02.108: %BGP-4-MAXPFX: No. of prefix received from 10.250.254.254 (afi 0) reaches 2, max 2
*Nov 26 04:10:02.108: %BGP-3-MAXPFXEXCEED: No. of prefix received from 10.250.254.254 (afi 0): 3 exceed limit 2
*Nov 26 04:10:02.108: %BGP-5-ADJCHANGE: neighbor 10.250.254.254 Down BGP Notification sent
*Nov 26 04:10:02.108: %BGP-3-NOTIFICATION: sent to neighbor 10.250.254.254 3/1 (update malformed) 0 bytes? FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0032 0200 0000 1940 0101 0040 0204 0201 6A39 4003 040A FAFE FE80 0404 0000 0000 0802





>________________________________
> From: Chuck Anderson <cra at WPI.EDU>
>To: nanog at nanog.org 
>Sent: Monday, November 25, 2013 3:37 PM
>Subject: Re: BGP neighbor/configuration testing
> 
>
>When you say "no logged error" with mismatched neighbor IP address,
>what do you mean?? Did the session just not establish at all?? How
>long did you wait for it to attempt to establish?
>
>On Juniper, if it sees a BGP connection come from an IP address that
>doesn't match a local "neighbor" statement, it will send a BGP
>Notification, code 2 (Open Message Error), subcode 5 (authentication
>failure), which is exactly what you are seeing.
>
>If one side is using a loopback IP instead of a physical IP for the
>local-address, that would cause both a multihop/TTL issue and a
>neighbor IP mismatch.
>
>Another possibility is if you have exceeded the max prefix limit for
>the session.? One side will get stuck in Idle state which may cause
>the other side to send the same "authentication failure" notification.
>
>On Mon, Nov 25, 2013 at 03:07:28PM -0800, Eric A Louie wrote:
>> All Cisco/Cisco, I don't have a Juniper here to test with
>> 
>> mismatch AS
>> *Apr? 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39
>> 
>> mismatch neighbor IP address
>> no logged error
>> 
>> MTU mismatch
>> no logged error, session remained up
>> 
>> Subnet mask mismatch
>> session remained up, no logged error
>> 
>> I haven't created the multihop scenario to see the error messages.
>> 
>> 
>> None of these issues caused the (authentication failure).
>> 
>> 
>> 
>> 
>> 
>> >________________________________
>> > From: Chuck Anderson <cra at WPI.EDU>
>> >To: nanog at nanog.org 
>> >Sent: Monday, November 25, 2013 11:10 AM
>> >Subject: Re: BGP neighbor/configuration testing
>> > 
>> >
>> >Authentication failure might mean (without knowing for sure which on
>> >Cisco):
>> >
>> >- mismatch AS numbers
>> >- mismatch neighbor IP addresses
>> >- multihop/TTL issues
>> >- MTU issues
>
>
>
>

From ryan at deadfrog.net  Tue Nov 26 01:50:34 2013
From: ryan at deadfrog.net (Ryan Wilkins)
Date: Mon, 25 Nov 2013 20:50:34 -0500
Subject: Meraki
In-Reply-To: <CALFTrnPpBQLHRRDkMnt1nz8Wi0k3B6KEmt9tbgNS-wfRHqSnqQ@mail.gmail.com>
References: <32243798.2716.1385098660289.JavaMail.root@benjamin.baylink.com>
 <4FFF777C-07B6-49FD-A87F-52156C9069FC@dds.nl>
 <CALFTrnNt9y3Gc8Lti_Ti8qqcFeQD7drhgqEUYqe4HuR2TTJY3g@mail.gmail.com>
 <86wqjxi7sx.fsf@valhalla.seastrom.com>
 <CALFTrnPpBQLHRRDkMnt1nz8Wi0k3B6KEmt9tbgNS-wfRHqSnqQ@mail.gmail.com>
Message-ID: <456E8426-C7BD-4E2B-8B1A-6BEEB71A1C9F@deadfrog.net>


On Nov 25, 2013, at 9:32 AM, Ray Soucy <rps at maine.edu> wrote:

> It looks like Brocade has swapped out Quagga with IP Infusion's non-free
> version, ZebOS.  They also decided to abandon the FOSS Vyatta Core project.
> 
> It's really unfortunate, as the FOSS project is the only reason I was
> interested in paying the licensing.  It was attractive to have Vyatta Core
> as a no-cost option for small things, and the subscription edition for
> higher visibility devices.  Now that they've moved away from having any
> FOSS project, I'm not really inclined to invest in the product, I'm sure
> there are others who feel the same way.
> 
> There is a group of people who were active in the Vyatta community trying
> to get a fork of it going under the name VyOS, http://www.vyos.net/
> 
> As far as Ubiquiti, it looks like about 2 years ago they actually hired a
> few people from Vyatta, Inc. to work on EdgeOS.  So development of EdgeOS
> has continued [and likely will continue] independently, though it looks
> like at least a few people from UBNT are interested in seeing VyOS happen
> and participating on their own time.  I know one of the early goals for
> VyOS is to get the documentation up on their Wiki and have a release of the
> current Vyatta Core with the name swapped out as a starting point.
> 
> I really hope the VyOS project can get off the ground.  If any developers
> familiar with maintaining Debian-based distributions are on-list, I know
> the project is looking for people to help.
> 

Interesting to read.  I have two Vyatta SE routers running on a small ISP network which have been performing flawless right up until I upgraded to 6.6 and then one of the routers started randomly dropping some BGP sessions once every few days or a week and then the entire BGP process hangs after a couple weeks.  The other router, with identical hardware and software, has had nary an issue.  It just keeps chugging along (It'll probably go down in a big show of smoke and flames tonight right about the time I fall asleep).  Vyatta support hasn't been able to make heads or tails of this as of yet.  The affected box had no issue prior to the upgrade.  Only a reboot has been able to get the router to function properly again.  I've also since upgraded the affected router to 6.6R3 at the advice of Vyatta TAC.  So far it shows a similar result.  Other services stay running, such as OSPF and OSPFv3, and it still routes packets.  It seems to otherwise work fine.  Has anyone else had strange issues with Vyatta 6.6?

Ryan Wilkins



From boards188 at gmail.com  Tue Nov 26 04:17:33 2013
From: boards188 at gmail.com (Jason Pope)
Date: Mon, 25 Nov 2013 22:17:33 -0600
Subject: telnet into a netgear switch?
In-Reply-To: <CAOMvUQdS9JZ0kD9du+nVF6D4h3CJgE+gOLsBrNfBp6Hw+XVv0g@mail.gmail.com>
References: <CAEqUV_hT7oq_L72M1YCzqdhKvux+Y=Y1ow1wo5T3AeuUXKVD0g@mail.gmail.com>
 <CAOMvUQdS9JZ0kD9du+nVF6D4h3CJgE+gOLsBrNfBp6Hw+XVv0g@mail.gmail.com>
Message-ID: <CAEqUV_j8xAGS=ZHyOKuycp5VNobmtuwOD4BjzZaEBR3ksvcmNQ@mail.gmail.com>

On Mon, Nov 25, 2013 at 5:42 PM, David Birdsong <david at imgix.com> wrote:

>
> On Nov 25, 2013 1:51 PM, "Jason Pope" <boards188 at gmail.com> wrote:
> >
> > ------------------------------
> > Message: 2
> > Date: Sun, 24 Nov 2013 18:47:09 -0800
> > From: David Birdsong <david at imgix.com>
> > To: nanog at nanog.org
> > Subject: telnet into a netgear switch?
> > Message-ID:
> >         <CAOMvUQfeM_Wnc=
> eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hey all, last night while at the datacenter I was in a pinch to extend a
> > rack's LAN. I compromised and ran out to the local Fry's to buy whatever
> > switch I could find so as to allow some configuration to happen while
> > we wait for the real network gear to show up.
> >
> > I left before confirming I could access the switch remotely; it was very
> > late and I was pretty groggy and hey, any network gear has to be
> > telnet'table this day and age. Of course I was mostly wrong.
> >
> > The switch expects some signed payload before allowing a telnet through.
> I
> > found this: https://code.google.com/p/netgear-telnetenable/...but I'm
> > having a hell of a time getting anything to respond.
> >
> > The most confounding part is the switch doesn't respond to a single SYN
> > packet on low ports. I'm scanning all the ports now, but if nothing shows
> > up, I'm not sure what a payload is good for if the switch doesn't ACK a
> > single SYN.
> >
> > I'm curious if anybody's got any tips besides not using Netgear in the
> > datacenter.
> >
> > I have the MAC, I've IP'd it via DHCP, and the model number: JGS524E and
> I
> > can power cycle the switch as much as needed.
> >
> >
> > P.S. long time listener, first time caller. i'm more of a sysadmin
> > dangerously standing in for a proper network person.
> > ------------------------------
> >
> > Seems to me that you need to use their "Switch Configuration Utility" to
> > manage the switch.  I didn't read all the documentation, but that is what
> > jumps out at me after a brief look.  Maybe it will allow you to enable
> > telnet or ssh from there.  See the following link:
> >
>
> No windows box handy, nor the desire for that hoop.
>
> ...but what magic is a windows app going to perform to wake up an
> unresponsive TCP stack?
>
> > http://downloadcenter.netgear.com/en/product/JGS524E
> >
> > Jason
>

Ahh; I don't use windows either, but I keep a VM handy just in case I need
it.

jp

From david at imgix.com  Tue Nov 26 04:51:29 2013
From: david at imgix.com (David Birdsong)
Date: Mon, 25 Nov 2013 20:51:29 -0800
Subject: telnet into a netgear switch?
In-Reply-To: <CAE42oJowLwCA+=F4ATuDMruTfA5b2nguTg1h_S0MHps=UHa=oQ@mail.gmail.com>
References: <CAEqUV_hT7oq_L72M1YCzqdhKvux+Y=Y1ow1wo5T3AeuUXKVD0g@mail.gmail.com>
 <CAOMvUQdS9JZ0kD9du+nVF6D4h3CJgE+gOLsBrNfBp6Hw+XVv0g@mail.gmail.com>
 <CAE42oJowLwCA+=F4ATuDMruTfA5b2nguTg1h_S0MHps=UHa=oQ@mail.gmail.com>
Message-ID: <CAOMvUQfEg1Zu72ezt_GiOJZk+7MVKoC2i9J3JZ83P2i+sH3P8w@mail.gmail.com>

On Mon, Nov 25, 2013 at 5:18 PM, Pedro Cavaca <pmsac.nanog at gmail.com> wrote:

>
>
>
> On 25 November 2013 23:42, David Birdsong <david at imgix.com> wrote:
>
>> On Nov 25, 2013 1:51 PM, "Jason Pope" <boards188 at gmail.com> wrote:
>> >
>> > ------------------------------
>> > Message: 2
>> > Date: Sun, 24 Nov 2013 18:47:09 -0800
>> > From: David Birdsong <david at imgix.com>
>> > To: nanog at nanog.org
>> > Subject: telnet into a netgear switch?
>> > Message-ID:
>> >         <CAOMvUQfeM_Wnc=
>> eS1vz0Gh_pp-vZ+sPRk9Td-1U0A34c3A6jdQ at mail.gmail.com>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > Hey all, last night while at the datacenter I was in a pinch to extend a
>> > rack's LAN. I compromised and ran out to the local Fry's to buy whatever
>> > switch I could find so as to allow some configuration to happen while
>> > we wait for the real network gear to show up.
>> >
>> > I left before confirming I could access the switch remotely; it was very
>> > late and I was pretty groggy and hey, any network gear has to be
>> > telnet'table this day and age. Of course I was mostly wrong.
>> >
>> > The switch expects some signed payload before allowing a telnet
>> through. I
>> > found this: https://code.google.com/p/netgear-telnetenable/...but I'm
>> > having a hell of a time getting anything to respond.
>> >
>> > The most confounding part is the switch doesn't respond to a single SYN
>> > packet on low ports. I'm scanning all the ports now, but if nothing
>> shows
>> > up, I'm not sure what a payload is good for if the switch doesn't ACK a
>> > single SYN.
>> >
>> > I'm curious if anybody's got any tips besides not using Netgear in the
>> > datacenter.
>> >
>> > I have the MAC, I've IP'd it via DHCP, and the model number: JGS524E
>> and I
>> > can power cycle the switch as much as needed.
>> >
>> >
>> > P.S. long time listener, first time caller. i'm more of a sysadmin
>> > dangerously standing in for a proper network person.
>> > ------------------------------
>> >
>> > Seems to me that you need to use their "Switch Configuration Utility" to
>> > manage the switch.  I didn't read all the documentation, but that is
>> what
>> > jumps out at me after a brief look.  Maybe it will allow you to enable
>> > telnet or ssh from there.  See the following link:
>> >
>>
>> No windows box handy, nor the desire for that hoop.
>>
>> ...but what magic is a windows app going to perform to wake up an
>> unresponsive TCP stack?
>>
>
> In view that the application needs to be run directly on the LAN, I'm not
> sure why you'd expect any TCP/IP like protocol - I asked a friend for a
> packet capture and it seems that the configuration utility is using RRCP (
> http://en.wikipedia.org/wiki/Realtek_Remote_Control_Protocol).
>
>
t'was finding this that made reassured me towards TCP/IP:
https://code.google.com/p/netgear-telnetenable/

 but yes, i'd completely forgotten about other protocols.

HTH
>
>
>> > http://downloadcenter.netgear.com/en/product/JGS524E
>> >
>> > Jason
>>
>
>

From jb at forethought.net  Tue Nov 26 04:26:43 2013
From: jb at forethought.net (Jawaid Desktop)
Date: Mon, 25 Nov 2013 21:26:43 -0700
Subject: CenturyLink IP NOC Contact for BGP Changes
Message-ID: <52942303.9080103@forethought.net>

Hello NANOGers,

We're a regional CLEC and I've had a BGP filter change request in to 
CenturyLink for 3 days. I've had no luck trying to get this processed.

I tried calling in tonight because, you know, my expectation these days 
is that every serious internet backbone company staffs a 24/7/365 NOC 
capable of dealing with IP and BGP routing issues / changes. I managed 
to escalate to a "TAC supervisor" who assures me that they in fact have 
nobody staffed after-hours who can do this kind of work. *boggles*

I had no trouble getting the exact same request processed by XO, Cogent, 
Level3, Comcast, Cogent, and TWTelecom in anywhere from minutes to a few 
hours, many of them at night (you know, when it's kind of like better to 
do such changes anyway).

So does anyone have the contact for a real, honest-to-god IP NOC 
engineer at CenturyLink?

Or did I make a mistake assuming CenturyLink is a serious, carrier-class 
player?

Thanks for any help.

Jawaid


From cma at cmadams.net  Tue Nov 26 05:46:26 2013
From: cma at cmadams.net (Chris Adams)
Date: Mon, 25 Nov 2013 23:46:26 -0600
Subject: CenturyLink IP NOC Contact for BGP Changes
In-Reply-To: <52942303.9080103@forethought.net>
References: <52942303.9080103@forethought.net>
Message-ID: <20131126054626.GE19273@cmadams.net>

Once upon a time, Jawaid Desktop <jb at forethought.net> said:
> We're a regional CLEC and I've had a BGP filter change request in to
> CenturyLink for 3 days. I've had no luck trying to get this
> processed.

It might help if you specify which part of CenturyLink (for example,
which AS).  CL is made up of a bunch of different, purchased, companies,
and AFAIK it is not all integrated.

For example, I worked for ISP that was connected to the old Qwest
network (AS 209) at one point, and later the old KMC network (AS 23126).
With the formerly-Qwest link, I had a login to a portal that was used to
make all change requests, and they typically went through pretty
quickly.  If there was a problem, I could open a ticket through the
portal and get a call-back in a reasonable amount of time.

The formerly-KMC link was pretty much a business hours only, send it by
email, CC your sales rep on all changes, and pester them until they do
it.  Outside of those hours, we could open tickets through the circuit
trouble line, but they didn't know what to do with the Internet (so it
just took repeated calls, nagging them until they escalated it to
somebody who at least had heard of a router before).

-- 
Chris Adams <cma at cmadams.net>


From joelja at bogus.com  Tue Nov 26 06:12:07 2013
From: joelja at bogus.com (joel jaeggli)
Date: Mon, 25 Nov 2013 22:12:07 -0800
Subject: CenturyLink IP NOC Contact for BGP Changes
In-Reply-To: <52942303.9080103@forethought.net>
References: <52942303.9080103@forethought.net>
Message-ID: <52943BB7.1000403@bogus.com>

On 11/25/13, 8:26 PM, Jawaid Desktop wrote:
> Hello NANOGers,
> 
> We're a regional CLEC and I've had a BGP filter change request in to
> CenturyLink for 3 days. I've had no luck trying to get this processed.
> 
> I tried calling in tonight because, you know, my expectation these days
> is that every serious internet backbone company staffs a 24/7/365 NOC
> capable of dealing with IP and BGP routing issues / changes. I managed
> to escalate to a "TAC supervisor" who assures me that they in fact have
> nobody staffed after-hours who can do this kind of work. *boggles*
> 
> I had no trouble getting the exact same request processed by XO, Cogent,
> Level3, Comcast, Cogent, and TWTelecom in anywhere from minutes to a few
> hours, many of them at night (you know, when it's kind of like better to
> do such changes anyway).
> 
> So does anyone have the contact for a real, honest-to-god IP NOC
> engineer at CenturyLink?

by centurylink do you mean legacy qwest (as209)

http://www.centurylinkservices.net/ipsupport/bgp-update.php

They do support routing policy objects, so you are imho better off if
you have your sessions converted to RADB generated filters, and then do
it that way.

> Or did I make a mistake assuming CenturyLink is a serious, carrier-class
> player?
> 
> Thanks for any help.
> 
> Jawaid
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131125/e5b275d0/attachment.bin>

From elouie at yahoo.com  Tue Nov 26 13:05:05 2013
From: elouie at yahoo.com (Eric A Louie)
Date: Tue, 26 Nov 2013 05:05:05 -0800 (PST)
Subject: BGP neighbor/configuration testing
In-Reply-To: <1385428886.54024.YahooMailNeo@web181603.mail.ne1.yahoo.com>
References: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
 <1385405295.42067.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <CAJXc8RJOb7a26rGqbTNnMTQfHqU=Ajobo6SLi=w2GFGr7aXfAg@mail.gmail.com>
 <1385406393.14461.YahooMailNeo@web181606.mail.ne1.yahoo.com>
 <20131125191052.GH16082@angus.ind.WPI.EDU>
 <1385420848.94661.YahooMailNeo@web181604.mail.ne1.yahoo.com>
 <20131125233748.GL16082@angus.ind.WPI.EDU>
 <1385428886.54024.YahooMailNeo@web181603.mail.ne1.yahoo.com>
Message-ID: <1385471105.55209.YahooMailNeo@web181601.mail.ne1.yahoo.com>

Update.? Turned up session with provider.? They had to increase max-prefixes when I "no shutdown" my BGP session in order to Establish it, then decreased it to their standard customer value.? Why it didn't come right up out of "no shutdown" and required the increase in max-prefix is still unknown.? Subsequent resets of the BGP session brought the session down and back up.

Shutdown/no shutdown will be tested tomorrow.


It has been an excellent lesson in establishing a 2nd upstream provider on the same router.? Something I'll be doing 2 more times next month.




>________________________________
> From: Eric A Louie <elouie at yahoo.com>
>To: "nanog at nanog.org" <nanog at nanog.org> 
>Sent: Monday, November 25, 2013 5:21 PM
>Subject: Re: BGP neighbor/configuration testing
> 
>
>No logged error with mismatched neighbor IP address - neither router had an entry.? Session did not establish nor go active, I could wait forever and neither would happen.? Point is, an error message is not generated on the downstream router so it's probably not the cause for the error message.
>
>I asked my upstream to check if the "local interface" command was being used (that would cause the multihop, but I did put in 2 or 3 as the ebgp-multihop value and still didn't get the session up.
>
>Your last comment about max-prefix is probably the problem and the solution.? Right now, the entire configuration is in the router with a "neighbor shutdown".? When we bring it up tomorrow, the filters will all be there so that only 13 of my prefixes are advertised, hopefully keeping the BGP session up and closing this saga.? (the router already has another upstream connected, so when I turned up the neighbor without a filter, I flooded the upstream's router with routes, but it took us this long to figure that out.) 
>
>
>
>
>On a Cisco to Cisco when the max-prefixes is exceeded and there's a restart specified, the error (on the offender) is not quite the same as the error I'm seeing:
>*Apr? 9 02:41:39.827: %BGP-3-NOTIFICATION: received from neighbor 10.250.254.253 3/1 (update malformed) 0 bytes
>*Apr? 9 02:41:39.827: %BGP-5-ADJCHANGE: neighbor 10.250.254.253 Down BGP Notification received
>
>On the upstream (where the max-prefix was configured), 
>
>*Nov 26 04:10:02.108: %BGP-4-MAXPFX: No. of prefix received from 10.250.254.254 (afi 0) reaches 2, max 2
>*Nov 26 04:10:02.108: %BGP-3-MAXPFXEXCEED: No. of prefix received from 10.250.254.254 (afi 0): 3 exceed limit 2
>*Nov 26 04:10:02.108: %BGP-5-ADJCHANGE: neighbor 10.250.254.254 Down BGP Notification sent
>*Nov 26 04:10:02.108: %BGP-3-NOTIFICATION: sent to neighbor 10.250.254.254 3/1 (update malformed) 0 bytes? FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0032 0200 0000 1940 0101 0040 0204 0201 6A39 4003 040A FAFE FE80 0404 0000 0000 0802
>
>
>
>
>
>>________________________________
>> From: Chuck Anderson <cra at WPI.EDU>
>>To: nanog at nanog.org 
>>Sent: Monday, November 25, 2013 3:37 PM
>>Subject: Re: BGP neighbor/configuration testing
>> 
>>
>>When you say "no logged error" with mismatched neighbor IP address,
>>what do you mean?? Did the session just not establish at all?? How
>>long did you wait for it to attempt to establish?
>>
>>On Juniper, if it sees a BGP connection come from an IP address that
>>doesn't match a local "neighbor" statement, it will send a BGP
>>Notification, code 2 (Open Message Error), subcode 5 (authentication
>>failure), which is exactly what you are seeing.
>>
>>If one side is using a loopback IP instead of a physical IP for the
>>local-address, that would cause both a multihop/TTL issue and a
>>neighbor IP mismatch.
>>
>>Another possibility is if you have exceeded the max prefix limit for
>>the session.? One side will get stuck in Idle state which may cause
>>the other side to send the same "authentication failure" notification.
>>
>>On Mon, Nov 25, 2013 at 03:07:28PM -0800, Eric A Louie wrote:
>>> All Cisco/Cisco, I don't have a Juniper here to test with
>>> 
>>> mismatch AS
>>> *Apr? 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39
>>> 
>>> mismatch neighbor IP address
>>> no logged error
>>> 
>>> MTU mismatch
>>> no logged error, session remained up
>>> 
>>> Subnet mask mismatch
>>> session remained up, no logged error
>>> 
>>> I haven't created the multihop scenario to see the error messages.
>>> 
>>> 
>>> None of these issues caused the (authentication failure).
>>> 
>>> 
>>> 
>>> 
>>> 
>>> >________________________________
>>> > From: Chuck Anderson <cra at WPI.EDU>
>>> >To: nanog at nanog.org 
>>> >Sent: Monday, November 25, 2013 11:10 AM
>>> >Subject: Re: BGP neighbor/configuration testing
>>> > 
>>> >
>>> >Authentication failure might mean (without knowing for sure which on
>>> >Cisco):
>>> >
>>> >- mismatch AS numbers
>>> >- mismatch neighbor IP addresses
>>> >- multihop/TTL issues
>>> >- MTU issues
>>
>>
>>
>>
>
>
>

From rps at maine.edu  Tue Nov 26 13:44:14 2013
From: rps at maine.edu (Ray Soucy)
Date: Tue, 26 Nov 2013 08:44:14 -0500
Subject: Meraki
In-Reply-To: <CA+W-zopQpRzpOCXfBjyC1o9i0r_mEHujah94Q4LQenoBv9YWew@mail.gmail.com>
References: <CA+W-zopQpRzpOCXfBjyC1o9i0r_mEHujah94Q4LQenoBv9YWew@mail.gmail.com>
Message-ID: <CALFTrnOa3N3pkVFoo4M+3ihzGQV=-BFqkGaTG_hKn9KjT583Hg@mail.gmail.com>

Can confirm the current ER Lite is a plastic enclosure.
But for $ 100 I can definitely look past that.

Also, most of the UBNT distributers seem to be very knowledgeable about the
product line, so I'm sure they would know if you asked them :-)

We've been running XORP internally for about 100+ CPE devices (actually the
ones we were looking at Vyatta as a replacement for).  In the end I think
that moving to Quagga was a good thing for Vyatta as XORP doesn't have a
very active developer community. XORP releases since 1.6 have been a forked
code base that eventually became XORP 1.8.  It's very touchy, and requires
quite a bit of operational experience to know what will cause it to crash
and what won't.  The big thing you get with XORP that you don't with Quagga
is multicast routing, and a more active community.  I've been really
interested in BIRD [0] as well, but haven't had a chance to try it out.

Back to UBNT, though.  The ER makes use of a lot of non-free code (not so
great), but it's to facilitate hardware acceleration (very nice).  A lot of
functionality for IPv4 and IPv6 are both implemented in hardware, including
not just forwarding and NAT, but also regex matching for DPI.  It's how
they can get so much PPS for such a modest piece of hardware.  I believe
the chips they use are from Cavium [1], but I could be mistaken.

[0]. http://bird.network.cz/
[1]. http://www.cavium.com/


On Mon, Nov 25, 2013 at 6:47 PM, SilverTip257 <silvertip257 at gmail.com>wrote:

> Date: Mon, 25 Nov 2013 09:32:10 -0500
>> From: Ray Soucy <rps at maine.edu>
>> To: Rob Seastrom <rs at seastrom.com>
>>
>> Cc: NANOG <nanog at nanog.org>
>> Subject: Re: Meraki
>> Message-ID:
>>         <
>> CALFTrnPpBQLHRRDkMnt1nz8Wi0k3B6KEmt9tbgNS-wfRHqSnqQ at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>
>> It looks like Brocade has swapped out Quagga with IP Infusion's non-free
>> version, ZebOS.  They also decided to abandon the FOSS Vyatta Core
>> project.
>>
>
> A number of years back it was interesting to see Vyatta switch from XORP
> [0] to Quagga.  I found out quite a while after they made the move.
>
> Bummer.
> This move by Brocade is unfortunate.
>
>
>>
>> It's really unfortunate, as the FOSS project is the only reason I was
>> interested in paying the licensing.  It was attractive to have Vyatta Core
>> as a no-cost option for small things, and the subscription edition for
>> higher visibility devices.  Now that they've moved away from having any
>> FOSS project, I'm not really inclined to invest in the product, I'm sure
>> there are others who feel the same way.
>
>
>> There is a group of people who were active in the Vyatta community trying
>> to get a fork of it going under the name VyOS, http://www.vyos.net/
>
>
> Thanks for pointing out VyOS.
>
>
>>
>>
>> As far as Ubiquiti, it looks like about 2 years ago they actually hired a
>> few people from Vyatta, Inc. to work on EdgeOS.  So development of EdgeOS
>> has continued [and likely will continue] independently, though it looks
>> like at least a few people from UBNT are interested in seeing VyOS happen
>> and participating on their own time.  I know one of the early goals for
>> VyOS is to get the documentation up on their Wiki and have a release of
>> the
>> current Vyatta Core with the name swapped out as a starting point.
>>
>
> For those of you that purchased EdgeRouter Lite (ERLite-3) [2] units
> recently, do they come in plastic enclosure or the steel enclosure like the
> EdgeRouter PoE (ERPoe-5) [3] units?  We got a few of each in at the office
> at different times (first ERL and later ERPoe).  Just curious.
>
> I guess I'm spoiled ... I like the metal case much better than the plastic
> ones.  Once I saw the case of the PoE model and saw the new pictures [4]
> for the ERL on Ubiquiti's site I've been holding out purchasing an ERL for
> my home.  I should bug our distributor, but I doubt they'd know since they
> aren't opening the boxes prior to shipment.
>
> Although a commercial alternative, Mikrotik hardware (ex: RB750GL [1]) and
> OS is attractive.  It appears all Mikrotik "integrated solutions" include
> some sort of enclosure (see www.routerboard.com).  The CLI takes some
> getting used to, but the syntax makes sense after a while. ;)  There's also
> a webui called webfig and a Windows client called Winbox.
>
>
>>
>> I really hope the VyOS project can get off the ground.  If any developers
>> familiar with maintaining Debian-based distributions are on-list, I know
>> the project is looking for people to help.
>>
>>
> +1
> I hope VyOS project succeeds.
>
>
> [0] http://en.wikipedia.org/wiki/XORP
> [1] http://routerboard.com/RB750GL
> [2]
> http://www.ubnt.com/media/product/edgemax/hardware-overview/edgerouter-lite-1.jpg
> [3]
> http://www.ubnt.com/media/product/edgemax/hardware-overview/edgerouter-poe-1.jpg
> [4] http://www.ubnt.com/edgemax#EdgeMAXhardware
>
> --
> ---~~.~~---
> Mike
> //  SilverTip257  //
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

From cscora at apnic.net  Tue Nov 26 15:11:18 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Wed, 27 Nov 2013 01:11:18 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201311261511.rAQFBI1W014715@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, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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

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

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

Routing Table Report   0400 +10GMT Sat 23 Nov, 2013

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

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

BGP routing table entries examined:                              472996
    Prefixes after maximum aggregation:                          189628
    Deaggregation factor:                                          2.49
    Unique aggregates announced to Internet:                     234531
Total ASes present in the Internet Routing Table:                 41350
    Prefixes per ASN:                                             11.44
Origin-only ASes present in the Internet Routing Table:           35408
Origin ASes announcing only one prefix:                           16278
Transit ASes present in the Internet Routing Table:                5942
Transit-only ASes present in the Internet Routing Table:            166
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                     103
    Max AS path prepend of ASN ( 50404)                             101
Prefixes from unregistered ASNs in the Routing Table:               985
    Unregistered ASNs in the Routing Table:                         282
Number of 32-bit ASNs allocated by the RIRs:                       5399
Number of 32-bit ASNs visible in the Routing Table:                   0
Prefixes from 32-bit ASNs in the Routing Table:                   13142
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:           1166
Number of addresses announced to Internet:                   2654800220
    Equivalent to 158 /8s, 61 /16s and 9 /24s
    Percentage of available address space announced:               71.7
    Percentage of allocated address space announced:               71.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               95.3
Total number of prefixes smaller than registry allocations:      165017

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

Prefixes being announced by APNIC Region ASes:                   111990
    Total APNIC prefixes after maximum aggregation:               34022
    APNIC Deaggregation factor:                                    3.29
Prefixes being announced from the APNIC address blocks:          114240
    Unique aggregates announced from the APNIC address blocks:    47745
APNIC Region origin ASes present in the Internet Routing Table:    4875
    APNIC Prefixes per ASN:                                       23.43
APNIC Region origin ASes announcing only one prefix:               1219
APNIC Region transit ASes present in the Internet Routing Table:    835
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         35
Number of APNIC region 32-bit ASNs visible in the Routing Table:      0
Number of APNIC addresses announced to Internet:              728686528
    Equivalent to 43 /8s, 110 /16s and 223 /24s
    Percentage of available APNIC address space announced:         85.2

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-63999, 131072-133631
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:                    162923
    Total ARIN prefixes after maximum aggregation:                81714
    ARIN Deaggregation factor:                                     1.99
Prefixes being announced from the ARIN address blocks:           163759
    Unique aggregates announced from the ARIN address blocks:     75912
ARIN Region origin ASes present in the Internet Routing Table:    15939
    ARIN Prefixes per ASN:                                        10.27
ARIN Region origin ASes announcing only one prefix:                6003
ARIN Region transit ASes present in the Internet Routing Table:    1658
Average ARIN Region AS path length visible:                         4.1
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:       0
Number of ARIN addresses announced to Internet:              1073967232
    Equivalent to 64 /8s, 3 /16s and 112 /24s
    Percentage of available ARIN address space announced:          56.8

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8,
                       205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8,
                       216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    119427
    Total RIPE prefixes after maximum aggregation:                61061
    RIPE Deaggregation factor:                                     1.96
Prefixes being announced from the RIPE address blocks:           123136
    Unique aggregates announced from the RIPE address blocks:     78812
RIPE Region origin ASes present in the Internet Routing Table:    17527
    RIPE Prefixes per ASN:                                         7.03
RIPE Region origin ASes announcing only one prefix:                8293
RIPE Region transit ASes present in the Internet Routing Table:    2826
Average RIPE Region AS path length visible:                         5.1
    Max RIPE Region AS path length visible:                         103
Number of RIPE region 32-bit ASNs visible in the Routing Table:       0
Number of RIPE addresses announced to Internet:               656226532
    Equivalent to 39 /8s, 29 /16s and 56 /24s
    Percentage of available RIPE address space announced:          95.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-200191
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:                   53080
    Total LACNIC prefixes after maximum aggregation:              10038
    LACNIC Deaggregation factor:                                   5.29
Prefixes being announced from the LACNIC address blocks:          58307
    Unique aggregates announced from the LACNIC address blocks:   27085
LACNIC Region origin ASes present in the Internet Routing Table:   2040
    LACNIC Prefixes per ASN:                                      28.58
LACNIC Region origin ASes announcing only one prefix:               553
LACNIC Region transit ASes present in the Internet Routing Table:   390
Average LACNIC Region AS path length visible:                       4.9
    Max LACNIC Region AS path length visible:                        35
Number of LACNIC region 32-bit ASNs visible in the Routing Table:     0
Number of LACNIC addresses announced to Internet:             143625784
    Equivalent to 8 /8s, 143 /16s and 142 /24s
    Percentage of available LACNIC address space announced:        85.6

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 262144-263679 plus 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:                  11750
    Total AfriNIC prefixes after maximum aggregation:              2600
    AfriNIC Deaggregation factor:                                  4.52
Prefixes being announced from the AfriNIC address blocks:         12388
    Unique aggregates announced from the AfriNIC address blocks:   4039
AfriNIC Region origin ASes present in the Internet Routing Table:   689
    AfriNIC Prefixes per ASN:                                     17.98
AfriNIC Region origin ASes announcing only one prefix:              210
AfriNIC Region transit ASes present in the Internet Routing Table:  139
Average AfriNIC Region AS path length visible:                      4.7
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    0
Number of AfriNIC addresses announced to Internet:             48324352
    Equivalent to 2 /8s, 225 /16s and 95 /24s
    Percentage of available AfriNIC address space announced:       48.0

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2931      11557         940   Korea Telecom (KIX)
17974     2714        902          88   PT TELEKOMUNIKASI INDONESIA
 7545     2111        319         111   TPG Internet Pty Ltd
 4755     1792        392         190   TATA Communications formerly 
 9829     1543       1245          45   BSNL National Internet Backbo
 9583     1246         95         509   Sify Limited
 9498     1210        309          73   BHARTI Airtel Ltd.
 7552     1165       1080          13   Vietel Corporation
 4808     1144       2119         337   CNCGROUP IP network: China169
24560     1095        380         166   Bharti Airtel Ltd., Telemedia

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
 6389     3042       3688          53   BellSouth.net Inc.
22773     2208       2941         141   Cox Communications, Inc.
 1785     2058        686         145   PaeTec Communications, Inc.
18566     2055        379         178   MegaPath Corporation
20115     1681       1655         598   Charter Communications 
 4323     1641       1098         419   Time Warner Telecom
  701     1509      11162         784   MCI Communications Services, 
30036     1388        313         578   Mediacom Communications Corp 
 7018     1331      17778         870   AT&T WorldNet Services
 6983     1294        756         580   ITC^Deltacom 

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
 8402     1923        544          16   OJSC "Vimpelcom"
34984     1367        244         223   TELLCOM ILETISIM HIZMETLERI A
20940     1164        437         871   Akamai Technologies European 
31148     1009         45          19   FreeNet ISP
13188      895         99          48   TOV "Bank-Inform"
 6849      869        363          39   JSC UKRTELECOM,
 8551      787        370          41   Bezeq International
 6830      773       2327         425   UPC Distribution Services
12479      679        797          57   Uni2 Autonomous System
35228      548        246          16   Avatar Broadband Limited

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
28573     3306       1781         123   NET Servicos de Comunicao S.A
10620     2670        433         213   Telmex Colombia S.A.
 7303     1729       1151         232   Telecom Argentina Stet-France
18881     1647        908          20   Global Village Telecom 
 8151     1358       2850         419   UniNet S.A. de C.V. 
11830      866        364          15   Instituto Costarricense de El
27947      819         94          92   Telconet S.A
 6503      793        434          62   AVANTEL, S.A. 
 6147      790        373          27   Telefonica Del Peru 
 7738      780       1498          36   Telecomunicacoes da Bahia S.A

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
36998     1864        112           5   Sudanese Mobile Telephone (ZA
24863      888        338          26   LINKdotNET AS number
 6713      554        633          26   Itissalat Al-MAGHRIB
 8452      411        956           9   TEDATA
24835      297        144           9   RAYA Telecom - Egypt
 3741      256        921         214   The Internet Solution 
29571      226         17          13   Ci Telecom Autonomous system 
15706      221         32           6   Sudatel Internet Exchange Aut
36992      219        501          29   Etisalat MISR
29975      192        668          21   Vodacom

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
28573     3306       1781         123   NET Servicos de Comunicao S.A
 6389     3042       3688          53   BellSouth.net Inc.
 4766     2931      11557         940   Korea Telecom (KIX)
17974     2714        902          88   PT TELEKOMUNIKASI INDONESIA
10620     2670        433         213   Telmex Colombia S.A.
22773     2208       2941         141   Cox Communications, Inc.
 7545     2111        319         111   TPG Internet Pty Ltd
 1785     2058        686         145   PaeTec Communications, Inc.
18566     2055        379         178   MegaPath Corporation
 8402     1923        544          16   OJSC "Vimpelcom"

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

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

  ASN   No of nets  Net Savings Description
 6389      3042        2989      BellSouth.net Inc.
17974      2714        2626      PT TELEKOMUNIKASI INDONESIA
10620      2670        2457      Telmex Colombia S.A.
22773      2208        2067      Cox Communications, Inc.
 7545      2111        2000      TPG Internet Pty Ltd
 4766      2931        1991      Korea Telecom (KIX)
 1785      2058        1913      PaeTec Communications, Inc.
 8402      1923        1907      OJSC "Vimpelcom"
18566      2055        1877      MegaPath Corporation
36998      1864        1859      Sudanese Mobile Telephone (ZA

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

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

Bad AS  Designation  Network              Transit AS  Description
62828   UNALLOCATED  8.21.130.0/24         4323       Time Warner Telecom
62850   UNALLOCATED  8.25.147.0/24         3356       Level 3 Communicatio
62734   UNALLOCATED  8.31.128.0/24         6939       Hurricane Electric 
62773   UNALLOCATED  8.35.180.0/22         3356       Level 3 Communicatio
65160   PRIVATE      12.1.58.0/24         17361       Sungard Trading Syst
65160   PRIVATE      12.1.59.0/24         17361       Sungard Trading Syst
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
62719   UNALLOCATED  12.27.130.0/24        4323       Time Warner Telecom
62861   UNALLOCATED  12.37.197.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic

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

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.100.0.0/24        4847     China Networks Inter-Exchange

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

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

Network            Origin AS  Description
23.90.128.0/18       27418     OUTOFWALL INC.
23.91.0.0/19         40676     Psychz Networks
23.91.4.0/24         40676     Psychz Networks
23.91.14.0/24        40676     Psychz Networks
23.91.21.0/24        40676     Psychz Networks
23.91.32.0/19        36315     Servpac Inc. 
23.91.80.0/20        21560     Capital Technology Services G
23.91.96.0/20        37958     ChinaCache Networks ASN
23.91.112.0/21       32475     MidPhase Inc. 
23.91.160.0/22       36493     3757277 Canada Inc. (oa 295.c

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:11      /10:31      /11:92      /12:253     
/13:474     /14:924     /15:1625    /16:12820   /17:6775    /18:11309   
/19:23082   /20:32928   /21:35636   /22:49999   /23:43870   /24:250678  
/25:871     /26:993     /27:467     /28:42      /29:69      /30:17      
/31:0       /32:14      

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

  ASN   No of nets  Total ann.   Description
18566     2009          2055      MegaPath Corporation
36998     1829          1864      Sudanese Mobile Telephone (ZA
 6389     1700          3042      BellSouth.net Inc.
 8402     1594          1923      OJSC "Vimpelcom"
22773     1463          2208      Cox Communications, Inc.
30036     1232          1388      Mediacom Communications Corp 
11492     1195          1233      Cable One 
 1785     1095          2058      PaeTec Communications, Inc.
 6983     1035          1294      ITC^Deltacom 
22561      964          1241      Digital Teleport, Inc 

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

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

   1:899       2:825       3:3         4:17        5:1027      6:21     
   8:624      12:1880     13:3        14:900      15:11       16:3      
  17:18       18:19       20:21       23:585      24:1757     27:1625   
  31:1506     32:45       33:2        34:5        36:86       37:1936   
  38:916      39:5        40:182      41:3235     42:290      44:14     
  46:2034     47:10       49:695      50:861      52:12       54:44     
  55:5        56:4        57:26       58:1165     59:575      60:368    
  61:1476     62:1247     63:1987     64:4325     65:2348     66:4160   
  67:2114     68:1093     69:3301     70:889      71:488      72:2012   
  74:2577     75:325      76:303      77:1158     78:1073     79:662    
  80:1272     81:1049     82:648      83:682      84:588      85:1260   
  86:375      87:1021     88:557      89:1562     90:152      91:5690   
  92:615      93:1611     94:2075     95:1554     96:515      97:348    
  98:1041     99:41      100:32      101:653     103:3675    105:527    
 106:141     107:218     108:536     109:1981    110:979     111:1119   
 112:597     113:812     114:753     115:1062    116:990     117:822    
 118:1184    119:1281    120:338     121:754     122:1872    123:1266   
 124:1397    125:1437    128:674     129:229     130:353     131:665    
 132:361     133:158     134:303     135:72      136:284     137:250    
 138:352     139:298     140:201     141:331     142:547     143:400    
 144:495     145:90      146:532     147:412     148:775     149:361    
 150:153     151:665     152:412     153:205     154:54      155:500    
 156:295     157:421     158:284     159:783     160:361     161:458    
 162:867     163:225     164:622     165:592     166:263     167:634    
 168:1043    169:125     170:1126    171:185     172:27      173:1591   
 174:694     175:526     176:1321    177:2472    178:1864    179:297    
 180:1597    181:859     182:1379    183:468     184:630     185:1057   
 186:2642    187:1484    188:1875    189:1265    190:7310    192:7078   
 193:5434    194:4026    195:3366    196:1340    197:1041    198:4766   
 199:5491    200:6055    201:2524    202:8976    203:8897    204:4546   
 205:2649    206:2833    207:2837    208:3985    209:3653    210:3047   
 211:1577    212:2151    213:1998    214:898     215:91      216:5423   
 217:1694    218:627     219:323     220:1277    221:585     222:328    
 223:509    

End of report


From rs at seastrom.com  Tue Nov 26 15:40:29 2013
From: rs at seastrom.com (Rob Seastrom)
Date: Tue, 26 Nov 2013 10:40:29 -0500
Subject: Meraki
In-Reply-To: <CALFTrnOa3N3pkVFoo4M+3ihzGQV=-BFqkGaTG_hKn9KjT583Hg@mail.gmail.com> (Ray
 Soucy's message of "Tue, 26 Nov 2013 08:44:14 -0500")
References: <CA+W-zopQpRzpOCXfBjyC1o9i0r_mEHujah94Q4LQenoBv9YWew@mail.gmail.com>
 <CALFTrnOa3N3pkVFoo4M+3ihzGQV=-BFqkGaTG_hKn9KjT583Hg@mail.gmail.com>
Message-ID: <86a9grxjbm.fsf@valhalla.seastrom.com>


Ray Soucy <rps at maine.edu> writes:

> Can confirm the current ER Lite is a plastic enclosure.

I got mine almost a year ago, and mine is plastic too.

> But for $ 100 I can definitely look past that.

Likewise.

> I believe the chips they use are from Cavium [1], but I could be mistaken.

The bootloader output agrees with you :)

-r



From bpasdar at batblue.com  Tue Nov 26 19:02:56 2013
From: bpasdar at batblue.com (Babak Pasdar)
Date: Tue, 26 Nov 2013 14:02:56 -0500
Subject: TW Telecom Latency
Message-ID: <9B5FA496-8119-4FD9-A521-EDE29E236619@batblue.com>

Can someone from TW Telecom IP services connect with us to work through an issue.  We are seeing ~90ms latency between LA and New Mexico with the most notable time being from San Jose to Albuquerque within the TW Telecom network.  

 1  74.123.203.137 (74.123.203.137)  4.661 ms  4.602 ms  4.570 ms
 2  xe-8-3-1.er1.lax112.us.above.net (209.66.118.225)  15.129 ms  15.143 ms  15.150 ms
 3  xe-1-1-0.cr1.lax112.us.above.net (64.125.30.246)  0.936 ms  0.930 ms  0.920 ms
 4  xe-0-2-0.cr1.sjc2.us.above.net (64.125.26.26)  9.219 ms  9.186 ms  9.212 ms
 5  ae1.mpr3.sjc7.us.above.net (64.125.24.2)  9.208 ms  12.212 ms  12.274 ms
 6  snjs.equinix.twtelecom.net (206.223.116.36)  12.036 ms  11.132 ms  11.112 ms
 7  abq1-ar4-ge-1-0-0-0.us.twtelecom.net (66.192.249.58)  81.883 ms  81.889 ms  81.868 ms
 8  10.208.169.222 (10.208.169.222)  87.492 ms  87.037 ms  87.456 ms
 9  speedy.bbbnm.org (207.201.250.86)  89.671 ms  90.753 ms  90.740 ms

Thanks,

Babak
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2447 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131126/bb157f52/attachment.bin>

From bortzmeyer at nic.fr  Tue Nov 26 21:09:24 2013
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 26 Nov 2013 22:09:24 +0100
Subject: [renesys] The New Threat: Targeted Internet Traffic Misdirection
In-Reply-To: <CAL9jLaaC=Y-HK4Ki8G71UPC1P1RzqpJUKQVPAVx-8iTCp9HNPA@mail.gmail.com>
References: <20131119233533.GA31522@sources.org>
 <CAL9jLaaC=Y-HK4Ki8G71UPC1P1RzqpJUKQVPAVx-8iTCp9HNPA@mail.gmail.com>
Message-ID: <20131126210924.GA13200@sources.org>

On Wed, Nov 20, 2013 at 01:54:00PM -0500,
 Christopher Morrow <morrowc.lists at gmail.com> wrote 
 a message of 11 lines which said:

> someone has already parsed out all route announcements from
> ris/routeviews for the 2 specific incidents in question in the
> article? and posted the contents somewhere for review? I didn't see
> Renesys do that :(

Indeed. But the data is public. Let's use RouteViews. Renesys gave us
the exact time (0736 UTC) and the origin AS. From the time, let's find
the relevant RouteViews file, whose URL is made of date and time:

ftp://archive.routeviews.org/route-views.linx/bgpdata/2013.07/UPDATES/updates.20130731.0730.bz2

Download, bunzip2, bgpdump to translate the MRT to text, then
Control-S in emacs to find announces by AS 48685. And here it is:

TIME: 07/31/13 07:36:46
TYPE: BGP4MP/MESSAGE/Update
FROM: 195.66.236.35 AS6067
TO: 195.66.237.222 AS6447
ORIGIN: IGP
ASPATH: 6067 6677 48685
NEXT_HOP: 195.66.236.35
ANNOUNCE
  64.81.96.0/24
  64.81.97.0/24
  64.81.101.0/24
  64.81.103.0/24
  64.81.110.0/24
  64.81.112.0/24
  64.81.113.0/24
  64.81.115.0/24
  64.81.116.0/24
  64.81.122.0/24
  64.81.125.0/24
  64.81.127.0/24
  64.81.161.0/24
  64.81.162.0/24
  64.81.163.0/24
  64.81.164.0/24
  64.81.166.0/24
  64.81.167.0/24
  64.81.169.0/24
  64.81.170.0/24
  64.81.171.0/24
  64.81.172.0/24
  64.81.177.0/24
  64.81.192.0/19
  64.81.199.0/24
  64.81.203.0/24
  64.81.204.0/24
  64.81.205.0/24
  64.81.208.0/24
  64.81.209.0/24
  64.81.212.0/24
  64.81.214.0/24
  64.105.6.0/23
  64.105.14.0/23
  64.105.20.0/23
  64.105.24.0/21
  64.105.32.0/21
  64.105.52.0/23
  64.105.54.0/23
  64.105.56.0/23
  64.105.58.0/23
  64.105.60.0/23
  64.105.62.0/23
  64.105.66.0/23
  64.105.70.0/23
  64.105.72.0/21
  64.105.82.0/23
  64.105.88.0/21
  64.105.114.0/23
  64.105.128.0/21
  64.105.144.0/21
  64.105.160.0/23
  64.105.162.0/23
  64.105.176.0/23
  64.105.180.0/22
  64.105.192.0/23
  64.105.194.0/23
  64.105.202.0/23
  64.105.210.0/23
  64.105.212.0/23
  64.105.218.0/23
  64.105.220.0/23
  64.105.226.0/23
  64.105.230.0/23
  64.105.240.0/23
  64.105.242.0/23
  64.105.244.0/22
  64.105.252.0/23
  66.92.20.0/24
  66.92.22.0/24
  66.92.46.0/24
  66.92.52.0/22
  66.92.64.0/19
  66.92.99.0/24
  66.92.100.0/24
  66.92.106.0/24
  66.92.144.0/24
  66.92.145.0/24
  66.92.147.0/24
  66.92.149.0/24
  66.92.152.0/24
  66.92.159.0/24
  66.92.160.0/24
  66.92.161.0/24
  66.92.162.0/24
  66.92.176.0/23
  66.92.213.0/24
  66.92.215.0/24
  66.92.224.0/20
  66.92.240.0/23
  66.92.241.0/24
  66.93.24.0/24
  66.93.25.0/24
  66.93.38.0/24
  66.93.39.0/24
  66.93.40.0/24
  66.93.49.0/24
  66.93.56.0/24
  66.93.59.0/24
  66.93.62.0/24
  66.93.74.0/24
  66.93.81.0/24
  66.93.82.0/24
  66.93.83.0/24
  66.93.84.0/23
  66.93.88.0/22
  66.93.99.0/24
  66.93.100.0/24
  66.93.103.0/24
  66.93.106.0/24
  66.93.107.0/24
  66.93.115.0/24
  66.93.168.0/23
  66.93.174.0/24
  66.93.176.0/23
  66.93.214.0/24
  66.93.216.0/24
  66.93.216.0/21
  66.93.224.0/24
  66.93.224.0/22
  66.93.228.0/24
  66.93.232.0/22
  66.93.240.0/24
  66.93.241.0/24
  66.93.242.0/24
  66.93.243.0/24
  66.93.244.0/24
  66.93.246.0/24
  66.93.248.0/24
  66.93.251.0/24
  66.93.252.0/23
  66.134.2.0/23
  66.134.18.0/23
  66.134.36.0/23
  66.134.38.0/23
  66.134.40.0/21
  66.134.48.0/21
  66.134.58.0/23
  66.134.60.0/23
  66.134.64.0/21
  66.134.76.0/23
  66.134.78.0/23
  66.134.98.0/23
  66.134.106.0/23
  66.134.116.0/23
  66.134.118.0/23
  66.134.136.0/21
  66.134.150.0/23
  66.134.152.0/21
  66.134.168.0/21
  66.134.176.0/23
  66.134.178.0/23
  66.134.182.0/23
  66.134.184.0/21
  66.134.208.0/21
  66.134.216.0/23
  66.134.220.0/23
  66.134.224.0/21
  66.134.232.0/21
  66.134.240.0/21
  66.166.10.0/23
  66.166.46.0/23
  66.166.64.0/21
  66.166.94.0/23
  66.166.112.0/23
  66.166.114.0/23
  66.166.136.0/23
  66.166.138.0/23
  66.166.144.0/21
  66.166.160.0/23
  66.166.162.0/23
  66.166.176.0/23
  66.166.180.0/23
  66.166.184.0/23
  66.166.200.0/21
  66.166.216.0/21
  66.166.244.0/23
  66.166.246.0/23
  66.166.248.0/23
  66.166.254.0/23
  66.167.0.0/21
  66.167.10.0/23
  66.167.26.0/23
  66.167.32.0/21
  66.167.50.0/23
  66.167.60.0/23
  66.167.62.0/23
  66.167.64.0/21
  66.167.72.0/21
  66.167.80.0/21
  66.167.96.0/21
  66.167.104.0/21
  66.167.118.0/23
  66.167.136.0/22
  66.167.152.0/21
  66.167.170.0/23
  66.167.176.0/21
  66.167.196.0/23
  66.167.208.0/23
  66.167.216.0/21
  66.167.224.0/21
  66.167.252.0/23
  66.167.254.0/23
  66.253.10.0/24
  66.253.20.0/24
  66.253.21.0/24
  66.253.22.0/24
  66.253.28.0/22
  66.253.40.0/22
  66.253.44.0/24
  66.253.45.0/24
  66.253.46.0/24
  66.253.47.0/24
  66.253.52.0/22
  66.253.56.0/24
  66.253.81.0/24
  66.253.82.0/24
  66.253.83.0/24
  66.253.84.0/24
  66.253.92.0/24
  66.253.93.0/24
  66.253.118.0/24
  67.100.0.0/23
  67.100.4.0/23
  67.100.48.0/21
  67.100.56.0/21
  67.100.72.0/21
  67.100.80.0/21
  67.100.96.0/21
  67.100.104.0/21
  67.100.112.0/21
  67.100.124.0/22
  67.100.128.0/23
  67.100.136.0/23
  67.100.138.0/23
  67.100.144.0/21
  67.100.168.0/21
  67.100.184.0/21
  67.100.192.0/21
  67.100.220.0/23
  67.101.14.0/23
  67.101.16.0/21
  67.101.72.0/21
  67.101.92.0/23
  67.101.94.0/23
  67.101.124.0/22
  67.101.128.0/21
  67.101.140.0/23
  67.101.142.0/23
  67.101.152.0/21
  67.101.176.0/21
  67.101.192.0/21
  67.101.200.0/21
  67.101.224.0/23
  67.101.230.0/23
  67.101.240.0/21
  67.101.248.0/21
  67.102.0.0/21
  67.102.8.0/23
  67.102.32.0/21
  67.102.40.0/21
  67.102.48.0/21
  67.102.60.0/23
  67.102.96.0/21
  67.102.112.0/21
  67.102.120.0/23
  67.102.124.0/23
  67.102.144.0/21
  67.102.152.0/21
  67.102.166.0/23
  67.102.168.0/21
  67.102.176.0/21
  67.102.200.0/21
  67.102.234.0/23
  67.102.240.0/21
  67.102.248.0/21
  67.103.0.0/21
  67.103.8.0/21
  67.103.24.0/21
  67.103.64.0/21
  67.103.102.0/23
  67.103.110.0/23
  67.103.112.0/21
  67.103.160.0/23
  67.103.162.0/23
  67.103.192.0/21
  67.103.200.0/23
  67.103.202.0/23
  67.103.226.0/23
  67.103.250.0/23
  67.103.252.0/23
  67.103.254.0/23
  68.164.24.0/21
  68.164.32.0/21
  68.164.44.0/23
  68.164.78.0/23
  68.164.80.0/20
  68.164.96.0/21
  68.164.126.0/23
  68.164.160.0/21
  68.164.192.0/21
  68.164.208.0/23

These addresses have no relationship with Iceland so we can say it's a
hijacking. But do note there is no AS prepending in the announce (the
trick described by Kapela & PIlosov to create a clean return path).

Finding the other announces in RouteViews is left as an exercice
(hint: use a RouteViews collector close from the announce, here in
England, because the hijacking announce did not propagate everywhere).


From morrowc.lists at gmail.com  Tue Nov 26 21:31:04 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 26 Nov 2013 16:31:04 -0500
Subject: [renesys] The New Threat: Targeted Internet Traffic Misdirection
In-Reply-To: <20131126210924.GA13200@sources.org>
References: <20131119233533.GA31522@sources.org>
 <CAL9jLaaC=Y-HK4Ki8G71UPC1P1RzqpJUKQVPAVx-8iTCp9HNPA@mail.gmail.com>
 <20131126210924.GA13200@sources.org>
Message-ID: <CAL9jLabUQK6ssoOXop9Rik6kcThA6hvzoAbzprQFQE6FYjtNaQ@mail.gmail.com>

first, awesome, thanks...

On Tue, Nov 26, 2013 at 4:09 PM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
<snip>
>   68.164.80.0/20
>   68.164.96.0/21
>   68.164.126.0/23
>   68.164.160.0/21
>   68.164.192.0/21
>   68.164.208.0/23
>
> These addresses have no relationship with Iceland so we can say it's a
> hijacking. But do note there is no AS prepending in the announce (the
> trick described by Kapela & PIlosov to create a clean return path).

yea.. so this smells, to me, like a leak from a 'route optomization'
box (netvmg or whatever they eventually became). These are all pretty
small prefixes and there are covering routes for these as well: (for
one: 68.164.24.0/21  - from the RV data)

18566   | 68.164.0.0/14       | MEGAPATH5-US - MegaPath Corporation
18566   | 68.164.24.0/21      | MEGAPATH5-US - MegaPath Corporation


so... err... potentially:
  1) route-optomization-box sends routes into iBGP with local origin-as
  2) routes aren't properly managed (community/etc) from local ISP ->
transits/peers
  3) peers/transits didn't filter (some of them did apparently)
  4) routes make it into the larger DFZ (or parts of the dfz at least, clearly)

Traffic comes to 68.164.24.1 along a 'false path' in the dfz, in to
the icelandic ISP and follows the iBGP learned path exiting
(fortunately) out the isp that filtered...

I'm sure you could construct lots of other pathological cases, but
this seems plausible enough to me...
>
> Finding the other announces in RouteViews is left as an exercice
> (hint: use a RouteViews collector close from the announce, here in
> England, because the hijacking announce did not propagate everywhere).


From randy at psg.com  Tue Nov 26 23:44:00 2013
From: randy at psg.com (Randy Bush)
Date: Wed, 27 Nov 2013 08:44:00 +0900
Subject: wikimedia dns issue
References: <MWWFFQY7@zendesk.com>
 <MWWFFQY7_5293c6b3443c2_77073fb7c16c67b41834479a_sprut@zendesk.com>
 <m2vbzgkk4e.wl%randy@psg.com>
Message-ID: <m2vbzeiv9b.wl%randy@psg.com>

leslie, you out there?

ryuu.psg.com:/Users/randy> host links.email.donate.wikimedia.org.
links.email.donate.wikimedia.org is an alias for recp.mkt41.net.
recp.mkt41.net has address 74.121.50.40

   $ dscacheutil -flushcache

does not clear it

this is all in tokyo.  so i ssh into a server in seattle westin.

    psg.com:/usr/home/randy> host links.email.donate.wikimedia.org.
    links.email.donate.wikimedia.org is an alias for recp.mkt41.net.
    recp.mkt41.net has address 74.121.50.40

the real or unreal CNAME RR is pretty prevalent

pretoria

    root at afnog:~ # host links.email.donate.wikimedia.org.
    links.email.donate.wikimedia.org is an alias for recp.mkt41.net.
    recp.mkt41.net has address 74.121.50.40

london starts to scare me

    drinx.linx.net:/root# host links.email.donate.wikimedia.org.
    ;; connection timed out; no servers could be reached
    drinx.linx.net:/root# host links.email.donate.wikimedia.org.
    ;; connection timed out; no servers could be reached

so i look at the nearest zone i can find

    ryuu.psg.com:/Users/randy> doc -p -w donate.wikimedia.org.
    Doc-2.2.3: doc -p -w donate.wikimedia.org.
    Doc-2.2.3: Starting test of donate.wikimedia.org.   parent is wikimedia.org.
    Doc-2.2.3: Test date - Tue Nov 26 10:46:48 JST 2013
    SYSerr: No servers for donate.wikimedia.org. returned SOAs ...
    Summary:
       YIKES: doc aborted while testing donate.wikimedia.org.  parent wikimedia.org.
       Incomplete test for donate.wikimedia.org. (1)
    Done testing donate.wikimedia.org.  Tue Nov 26 10:46:49 JST 2013

at least the parent is ok

    ryuu.psg.com:/Users/randy> doc -p -w wikimedia.org.
    Doc-2.2.3: doc -p -w wikimedia.org.
    Doc-2.2.3: Starting test of wikimedia.org.   parent is org.
    Doc-2.2.3: Test date - Tue Nov 26 10:47:45 JST 2013
    Summary:
       No errors or warnings issued for wikimedia.org.
    Done testing wikimedia.org.  Tue Nov 26 10:47:48 JST 2013

aha!

    ryuu.psg.com:/Users/randy> ns donate.wikimedia.org.
    donate-lb.eqiad.wikimedia.org.

i suspect a load balancer

yes, i reported this to wikimedia two days ago.  a response, then black
hole.  problem persists.

randy


From randy at psg.com  Wed Nov 27 00:42:07 2013
From: randy at psg.com (Randy Bush)
Date: Wed, 27 Nov 2013 09:42:07 +0900
Subject: wikimedia dns issue
In-Reply-To: <CAG-QXM_8JfCN98BmiXunKpd4R16tNtH=f4fTw7t_bwf909EXGQ@mail.gmail.com>
References: <MWWFFQY7@zendesk.com>
 <MWWFFQY7_5293c6b3443c2_77073fb7c16c67b41834479a_sprut@zendesk.com>
 <m2vbzgkk4e.wl%randy@psg.com> <m2vbzeiv9b.wl%randy@psg.com>
 <CAG-QXM_8JfCN98BmiXunKpd4R16tNtH=f4fTw7t_bwf909EXGQ@mail.gmail.com>
Message-ID: <90492033-415a-4f23-82a3-7b171d59457c@email.android.com>

I got there because of a FireFox cert reject. You are losing money. 
-- 
Phones are not computers and suck for email

Matthew Walker <mwalker at wikimedia.org> wrote:
>Randy,
>
>Thanks for the concern -- if I understand your email correct the issue
>is
>not that you cannot resolve donate.wikimedia.org; but it's that one of
>our
>subdomains resolves to something that's not a WMF server?
>
>If so; the behavior you're seeing, that
>links.email.donate.wikimedia.org goes
>to ?.mkt41.net is correct. What we're doing is year is using an
>external
>bulk mailer to try and ensure deliverability of fundraising mail (it
>turns
>out that we get about $1 per email so getting good deliverability is
>pretty
>important.) The bulk mailer, Silverpop, does link rewriting in the body
>of
>the email for use statistical things (we A/B test our emails and use
>their
>dashboards to do so).
>
>For what its worth our donor rights policy [1] applies to this type of
>data.
>
>[1] http://wikimediafoundation.org/wiki/Donor_policy
>
>~Matt Walker
>Wikimedia Foundation
>Fundraising Technology Team
>
>
>On Tue, Nov 26, 2013 at 3:44 PM, Randy Bush <randy at psg.com> wrote:
>
>> leslie, you out there?
>>
>> ryuu.psg.com:/Users/randy> host links.email.donate.wikimedia.org.
>> links.email.donate.wikimedia.org is an alias for recp.mkt41.net.
>> recp.mkt41.net has address 74.121.50.40
>>
>>    $ dscacheutil -flushcache
>>
>> does not clear it
>>
>> this is all in tokyo.  so i ssh into a server in seattle westin.
>>
>>     psg.com:/usr/home/randy> host links.email.donate.wikimedia.org.
>>     links.email.donate.wikimedia.org is an alias for recp.mkt41.net.
>>     recp.mkt41.net has address 74.121.50.40
>>
>> the real or unreal CNAME RR is pretty prevalent
>>
>> pretoria
>>
>>     root at afnog:~ # host links.email.donate.wikimedia.org.
>>     links.email.donate.wikimedia.org is an alias for recp.mkt41.net.
>>     recp.mkt41.net has address 74.121.50.40
>>
>> london starts to scare me
>>
>>     drinx.linx.net:/root# host links.email.donate.wikimedia.org.
>>     ;; connection timed out; no servers could be reached
>>     drinx.linx.net:/root# host links.email.donate.wikimedia.org.
>>     ;; connection timed out; no servers could be reached
>>
>> so i look at the nearest zone i can find
>>
>>     ryuu.psg.com:/Users/randy> doc -p -w donate.wikimedia.org.
>>     Doc-2.2.3: doc -p -w donate.wikimedia.org.
>>     Doc-2.2.3: Starting test of donate.wikimedia.org.   parent is
>> wikimedia.org.
>>     Doc-2.2.3: Test date - Tue Nov 26 10:46:48 JST 2013
>>     SYSerr: No servers for donate.wikimedia.org. returned SOAs ...
>>     Summary:
>>        YIKES: doc aborted while testing donate.wikimedia.org.  parent
>> wikimedia.org.
>>        Incomplete test for donate.wikimedia.org. (1)
>>     Done testing donate.wikimedia.org.  Tue Nov 26 10:46:49 JST 2013
>>
>> at least the parent is ok
>>
>>     ryuu.psg.com:/Users/randy> doc -p -w wikimedia.org.
>>     Doc-2.2.3: doc -p -w wikimedia.org.
>>     Doc-2.2.3: Starting test of wikimedia.org.   parent is org.
>>     Doc-2.2.3: Test date - Tue Nov 26 10:47:45 JST 2013
>>     Summary:
>>        No errors or warnings issued for wikimedia.org.
>>     Done testing wikimedia.org.  Tue Nov 26 10:47:48 JST 2013
>>
>> aha!
>>
>>     ryuu.psg.com:/Users/randy> ns donate.wikimedia.org.
>>     donate-lb.eqiad.wikimedia.org.
>>
>> i suspect a load balancer
>>
>> yes, i reported this to wikimedia two days ago.  a response, then
>black
>> hole.  problem persists.
>>
>> randy
>>
>>

From pfsinoz at gmail.com  Wed Nov 27 01:53:06 2013
From: pfsinoz at gmail.com (Philip Smith)
Date: Wed, 27 Nov 2013 11:53:06 +1000
Subject: Long AS-PATH / Blank Routing Report last weekend - update
Message-ID: <52955082.2000700@gmail.com>

Hi everyone,

Apologies for the blank Routing Report last weekend. Unfortunately my
script was tripped up by a very long AS-PATH.

This one:

*>i193.105.15.0     202.249.2.110            0    120      0 2516 3257
50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404
50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404
50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404
50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404
50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404
50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404
50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404
50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404
50404 50404 50404 50404 50404 i

It's been around since the 19th and is still there today; but I only see
it at DIX-IE in Japan (in the BGP views I analyse).

philip
--


From eric at ericheather.com  Wed Nov 27 03:47:37 2013
From: eric at ericheather.com (Eric C. Miller)
Date: Wed, 27 Nov 2013 03:47:37 +0000
Subject: ZyXEL Gear
Message-ID: <DC85D08B84BB854086E9524DAB67D18715EF8C74@Teriwood.miller.local>

I'm looking at some non-Cisco price options to deliver more than 4 SFP slots into a structure and was wondering if anyone had any experience with ZyXEL's offerings in the service provider market. Specifically MGS-3712F or GS-4012F

Thank you for your comments!

Eric Miller, CCNP
Network Engineering Consultant
(407) 257-5115




From joshbaird at gmail.com  Wed Nov 27 03:51:08 2013
From: joshbaird at gmail.com (Josh Baird)
Date: Tue, 26 Nov 2013 22:51:08 -0500
Subject: ZyXEL Gear
In-Reply-To: <DC85D08B84BB854086E9524DAB67D18715EF8C74@Teriwood.miller.local>
References: <DC85D08B84BB854086E9524DAB67D18715EF8C74@Teriwood.miller.local>
Message-ID: <CABmW_PcY7G2tW+_Jsxe5sLFCJnDvLtF-frQx+izUrAntOGKeFw@mail.gmail.com>

I don't, but you may want to take a look at Planet:

http://www.planet.com.tw/

Thanks,

Josh


On Tue, Nov 26, 2013 at 10:47 PM, Eric C. Miller <eric at ericheather.com>wrote:

> I'm looking at some non-Cisco price options to deliver more than 4 SFP
> slots into a structure and was wondering if anyone had any experience with
> ZyXEL's offerings in the service provider market. Specifically MGS-3712F or
> GS-4012F
>
> Thank you for your comments!
>
> Eric Miller, CCNP
> Network Engineering Consultant
> (407) 257-5115
>
>
>
>

From morrowc.lists at gmail.com  Wed Nov 27 04:03:37 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 26 Nov 2013 23:03:37 -0500
Subject: [renesys] The New Threat: Targeted Internet Traffic Misdirection
In-Reply-To: <CAL9jLabUQK6ssoOXop9Rik6kcThA6hvzoAbzprQFQE6FYjtNaQ@mail.gmail.com>
References: <20131119233533.GA31522@sources.org>
 <CAL9jLaaC=Y-HK4Ki8G71UPC1P1RzqpJUKQVPAVx-8iTCp9HNPA@mail.gmail.com>
 <20131126210924.GA13200@sources.org>
 <CAL9jLabUQK6ssoOXop9Rik6kcThA6hvzoAbzprQFQE6FYjtNaQ@mail.gmail.com>
Message-ID: <CAL9jLaYAGT=pMj=ZhaTO4UjnBG5m7A_HhYAh=n_uftTFtRNcvw@mail.gmail.com>

On Tue, Nov 26, 2013 at 4:31 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> first, awesome, thanks...
>
> On Tue, Nov 26, 2013 at 4:09 PM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> <snip>
>>   68.164.80.0/20
>>   68.164.96.0/21
>>   68.164.126.0/23
>>   68.164.160.0/21
>>   68.164.192.0/21
>>   68.164.208.0/23
>>
>> These addresses have no relationship with Iceland so we can say it's a
>> hijacking. But do note there is no AS prepending in the announce (the
>> trick described by Kapela & PIlosov to create a clean return path).
>
> yea.. so this smells, to me, like a leak from a 'route optomization'
> box (netvmg or whatever they eventually became). These are all pretty

So, I was thinking over dinner that there's a simpler explanation
(that fails if this was a more full-table-ish leak) that the Icelandic
provider could have done something like putting external-bgp data into
their IGP then pulling back out to bgp ... which is a lot more like
AS7007-like problems than netvmg-like problems.

I would expect that ospf/isis would barf with ~400k paths though, so
i'm still betting on netvmg-ish issues.

> small prefixes and there are covering routes for these as well: (for
> one: 68.164.24.0/21  - from the RV data)
>
> 18566   | 68.164.0.0/14       | MEGAPATH5-US - MegaPath Corporation
> 18566   | 68.164.24.0/21      | MEGAPATH5-US - MegaPath Corporation
>
>
> so... err... potentially:
>   1) route-optomization-box sends routes into iBGP with local origin-as
>   2) routes aren't properly managed (community/etc) from local ISP ->
> transits/peers
>   3) peers/transits didn't filter (some of them did apparently)
>   4) routes make it into the larger DFZ (or parts of the dfz at least, clearly)
>
> Traffic comes to 68.164.24.1 along a 'false path' in the dfz, in to
> the icelandic ISP and follows the iBGP learned path exiting
> (fortunately) out the isp that filtered...
>
> I'm sure you could construct lots of other pathological cases, but
> this seems plausible enough to me...
>>
>> Finding the other announces in RouteViews is left as an exercice
>> (hint: use a RouteViews collector close from the announce, here in
>> England, because the hijacking announce did not propagate everywhere).


From eric at ericheather.com  Wed Nov 27 04:08:39 2013
From: eric at ericheather.com (Eric C. Miller)
Date: Wed, 27 Nov 2013 04:08:39 +0000
Subject: ZyXEL Gear
In-Reply-To: <CABmW_PcY7G2tW+_Jsxe5sLFCJnDvLtF-frQx+izUrAntOGKeFw@mail.gmail.com>
References: <DC85D08B84BB854086E9524DAB67D18715EF8C74@Teriwood.miller.local>
 <CABmW_PcY7G2tW+_Jsxe5sLFCJnDvLtF-frQx+izUrAntOGKeFw@mail.gmail.com>
Message-ID: <DC85D08B84BB854086E9524DAB67D18715EF8CB3@Teriwood.miller.local>

Thanks, Josh!



From: Josh Baird [mailto:joshbaird at gmail.com]
Sent: Tuesday, November 26, 2013 10:51 PM
To: Eric C. Miller
Cc: NANOG (nanog at nanog.org)
Subject: Re: ZyXEL Gear

I don't, but you may want to take a look at Planet:

http://www.planet.com.tw/

Thanks,

Josh

On Tue, Nov 26, 2013 at 10:47 PM, Eric C. Miller <eric at ericheather.com<mailto:eric at ericheather.com>> wrote:
I'm looking at some non-Cisco price options to deliver more than 4 SFP slots into a structure and was wondering if anyone had any experience with ZyXEL's offerings in the service provider market. Specifically MGS-3712F or GS-4012F

Thank you for your comments!

Eric Miller, CCNP
Network Engineering Consultant
(407) 257-5115<tel:%28407%29%20257-5115>




From mwise at aol.com  Wed Nov 27 05:05:51 2013
From: mwise at aol.com (Michael Wise)
Date: Wed, 27 Nov 2013 00:05:51 -0500 (EST)
Subject: FW:My goodness, long time no speak1
Message-ID: <8D0B9457A2EAB93-1F18-833B3@webmail-d131.sysops.aol.com>



http://www.onlinecatholicnetwork.com/libraries/joomla/cache/ykhti.php








On, November 27/11/2013 05:05:53, Michael Wise &lt; mwise at aol.com &gt;
--------   --------   --------   --------   --------   --------   --------   --------   --------   --------   
alanis morissette jagged little pill lyric

From joly at punkcast.com  Wed Nov 27 06:11:42 2013
From: joly at punkcast.com (Joly MacFie)
Date: Wed, 27 Nov 2013 01:11:42 -0500
Subject: FW:My goodness, long time no speak1
In-Reply-To: <8D0B9457A2EAB93-1F18-833B3@webmail-d131.sysops.aol.com>
References: <8D0B9457A2EAB93-1F18-833B3@webmail-d131.sysops.aol.com>
Message-ID: <CAM9VJk3_h+pSxAL=Zh202TJzDsuQmbJYEQZq-LVSop+JhdeyKQ@mail.gmail.com>

I thought the new pope had banned malware.




On Wed, Nov 27, 2013 at 12:05 AM, Michael Wise <mwise at aol.com> wrote:

>
>
> http://www.onlinecatholicnetwork.com/libraries/joomla/cache/ykhti.php
>
>
>
>
>
>
>
>
> On, November 27/11/2013 05:05:53, Michael Wise &lt; mwise at aol.com &gt;
> --------   --------   --------   --------   --------   --------   --------
>   --------   --------   --------
> alanis morissette jagged little pill lyric
>



-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-

From jra at baylink.com  Wed Nov 27 07:10:33 2013
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 27 Nov 2013 02:10:33 -0500
Subject: Renesys, Ars document wholesale BGP hijacking
Message-ID: <52791f22-ee57-4409-aed6-bfc8e03434b1@email.android.com>

To Belarus, Iceland.

Um, oops.

http://catless.ncl.ac.uk/go/risks/27/62/2
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From bortzmeyer at nic.fr  Wed Nov 27 08:06:12 2013
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed, 27 Nov 2013 09:06:12 +0100
Subject: Renesys, Ars document wholesale BGP hijacking
In-Reply-To: <52791f22-ee57-4409-aed6-bfc8e03434b1@email.android.com>
References: <52791f22-ee57-4409-aed6-bfc8e03434b1@email.android.com>
Message-ID: <20131127080612.GA16668@nic.fr>

On Wed, Nov 27, 2013 at 02:10:33AM -0500,
 Jay Ashworth <jra at baylink.com> wrote 
 a message of 7 lines which said:

> To Belarus, Iceland.

Old news, more than a week.
 
> Um, oops.
> 
> http://catless.ncl.ac.uk/go/risks/27/62/2

The real URL is
<http://arstechnica.com/security/2013/11/repeated-attacks-hijack-huge-chunks-of-internet-traffic-researchers-warn/>


From mwalker at wikimedia.org  Wed Nov 27 00:17:00 2013
From: mwalker at wikimedia.org (Matthew Walker)
Date: Tue, 26 Nov 2013 16:17:00 -0800
Subject: wikimedia dns issue
In-Reply-To: <m2vbzeiv9b.wl%randy@psg.com>
References: <MWWFFQY7@zendesk.com>
 <MWWFFQY7_5293c6b3443c2_77073fb7c16c67b41834479a_sprut@zendesk.com>
 <m2vbzgkk4e.wl%randy@psg.com> <m2vbzeiv9b.wl%randy@psg.com>
Message-ID: <CAG-QXM_8JfCN98BmiXunKpd4R16tNtH=f4fTw7t_bwf909EXGQ@mail.gmail.com>

Randy,

Thanks for the concern -- if I understand your email correct the issue is
not that you cannot resolve donate.wikimedia.org; but it's that one of our
subdomains resolves to something that's not a WMF server?

If so; the behavior you're seeing, that links.email.donate.wikimedia.org goes
to ?.mkt41.net is correct. What we're doing is year is using an external
bulk mailer to try and ensure deliverability of fundraising mail (it turns
out that we get about $1 per email so getting good deliverability is pretty
important.) The bulk mailer, Silverpop, does link rewriting in the body of
the email for use statistical things (we A/B test our emails and use their
dashboards to do so).

For what its worth our donor rights policy [1] applies to this type of data.

[1] http://wikimediafoundation.org/wiki/Donor_policy

~Matt Walker
Wikimedia Foundation
Fundraising Technology Team


On Tue, Nov 26, 2013 at 3:44 PM, Randy Bush <randy at psg.com> wrote:

> leslie, you out there?
>
> ryuu.psg.com:/Users/randy> host links.email.donate.wikimedia.org.
> links.email.donate.wikimedia.org is an alias for recp.mkt41.net.
> recp.mkt41.net has address 74.121.50.40
>
>    $ dscacheutil -flushcache
>
> does not clear it
>
> this is all in tokyo.  so i ssh into a server in seattle westin.
>
>     psg.com:/usr/home/randy> host links.email.donate.wikimedia.org.
>     links.email.donate.wikimedia.org is an alias for recp.mkt41.net.
>     recp.mkt41.net has address 74.121.50.40
>
> the real or unreal CNAME RR is pretty prevalent
>
> pretoria
>
>     root at afnog:~ # host links.email.donate.wikimedia.org.
>     links.email.donate.wikimedia.org is an alias for recp.mkt41.net.
>     recp.mkt41.net has address 74.121.50.40
>
> london starts to scare me
>
>     drinx.linx.net:/root# host links.email.donate.wikimedia.org.
>     ;; connection timed out; no servers could be reached
>     drinx.linx.net:/root# host links.email.donate.wikimedia.org.
>     ;; connection timed out; no servers could be reached
>
> so i look at the nearest zone i can find
>
>     ryuu.psg.com:/Users/randy> doc -p -w donate.wikimedia.org.
>     Doc-2.2.3: doc -p -w donate.wikimedia.org.
>     Doc-2.2.3: Starting test of donate.wikimedia.org.   parent is
> wikimedia.org.
>     Doc-2.2.3: Test date - Tue Nov 26 10:46:48 JST 2013
>     SYSerr: No servers for donate.wikimedia.org. returned SOAs ...
>     Summary:
>        YIKES: doc aborted while testing donate.wikimedia.org.  parent
> wikimedia.org.
>        Incomplete test for donate.wikimedia.org. (1)
>     Done testing donate.wikimedia.org.  Tue Nov 26 10:46:49 JST 2013
>
> at least the parent is ok
>
>     ryuu.psg.com:/Users/randy> doc -p -w wikimedia.org.
>     Doc-2.2.3: doc -p -w wikimedia.org.
>     Doc-2.2.3: Starting test of wikimedia.org.   parent is org.
>     Doc-2.2.3: Test date - Tue Nov 26 10:47:45 JST 2013
>     Summary:
>        No errors or warnings issued for wikimedia.org.
>     Done testing wikimedia.org.  Tue Nov 26 10:47:48 JST 2013
>
> aha!
>
>     ryuu.psg.com:/Users/randy> ns donate.wikimedia.org.
>     donate-lb.eqiad.wikimedia.org.
>
> i suspect a load balancer
>
> yes, i reported this to wikimedia two days ago.  a response, then black
> hole.  problem persists.
>
> randy
>
>

From karn at philkarn.net  Wed Nov 27 08:58:04 2013
From: karn at philkarn.net (Phil Karn)
Date: Wed, 27 Nov 2013 00:58:04 -0800
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <5290498A.6040405@trelane.net>
References: <5290498A.6040405@trelane.net>
Message-ID: <5295B41C.4010005@philkarn.net>

On 11/22/2013 10:22 PM, Andrew D Kirch wrote:

> Ok, is this core routing? not really, but it's nice to see a major clue 
> injection over at AT&T Uverse.  I'm using this to document the MASSIVE 
> bureaucratic PITA which is getting native IPv6 on uverse.  You'll start 
> from the default service on a 2wire "modem" (for values of modem that 
> equate to profanity).  If you have the Motorola NVG589, count yourself 
> lucky and skip most of these steps.

Does it still work? Are you *SURE*? Better go check...

IPv6 on Uverse was working for me until this evening. Now it's broken again.

I almost gave up on Uverse in disgust last month when AT&T pushed down
that software update to the 2WIRE/Pace 3801 that broke all IPv6 tunnels.

Then I read on the forums about the new "Power" service tier that
requires pair bonding and the NVG589, so I signed up more to get the 589
than for the higher speed.

Sure enough, the NVG589 is a *V A S T* improvement over the 3801. It
even provides native IPv6! (Well, "native" in that the box emits IPv6
router advertisements on my LAN; I know it's still implemented with 6rd.)

Until tonight.

Now my NVG589 won't even respond to pings to its own local IPv6 address.
Attempts to ping6 machines on my LAN from the 589's diagnostic page gave
"unreachable network" errors even though the 589 was still emitting IPv6
router advertisements for my /64 subnet.

Restarting the box didn't help. Now its status page says that IPv6 is
"unavailable". At least it's no longer emitting router advertisements
for a service it can't provide.

I had also been able to use AT&T's 6rd gateway with one of my static
IPv4 addresses, but that's also broken now.

I think it's time to dump Uverse and switch to cable. The only drawback
is that AT&T gives me a /29 IPv4 address block for $15/mo while Time
Warner makes static IP addressing available only with their "business
class" service costing several hundred/month.

But Hurricane Electric's IPv6 tunnels work so well that I'm not sure
static IPv4 even matters anymore. I only use them to reach my systems
myself from the outside, I'm not running any public services that really
need them.

--Phil




From trelane at trelane.net  Wed Nov 27 16:32:35 2013
From: trelane at trelane.net (Andrew D Kirch)
Date: Wed, 27 Nov 2013 11:32:35 -0500
Subject: ZyXEL Gear
In-Reply-To: <DC85D08B84BB854086E9524DAB67D18715EF8C74@Teriwood.miller.local>
References: <DC85D08B84BB854086E9524DAB67D18715EF8C74@Teriwood.miller.local>
Message-ID: <52961EA3.9010103@trelane.net>

Eric,

I'll note as a followup to the Ipv6 thread, I'm a _HUGE_ mikrotik fan.  
One of the CCR models has 4 SFP's.

Andrew

On 11/26/2013 10:47 PM, Eric C. Miller wrote:
> I'm looking at some non-Cisco price options to deliver more than 4 SFP slots into a structure and was wondering if anyone had any experience with ZyXEL's offerings in the service provider market. Specifically MGS-3712F or GS-4012F
>
> Thank you for your comments!
>
> Eric Miller, CCNP
> Network Engineering Consultant
> (407) 257-5115
>
>
>



From eric at flanery.us  Wed Nov 27 17:20:34 2013
From: eric at flanery.us (Eric Flanery (eric))
Date: Wed, 27 Nov 2013 09:20:34 -0800
Subject: ZyXEL Gear
In-Reply-To: <52961EA3.9010103@trelane.net>
References: <DC85D08B84BB854086E9524DAB67D18715EF8C74@Teriwood.miller.local>
 <52961EA3.9010103@trelane.net>
Message-ID: <CAMEJQXi2X36e9v-duZYTnENfhKoVmOyPJ51ReLP6DXFSs7g9sQ@mail.gmail.com>

I'll add that if you are comfortable with MikroTik, and can wait a few
months, they have announced a device with 12 SFP slots, and one SFP+ slot.

It's the CCR1016-12S-1S+, and I expect it to come in well under $1k.

--Eric (not OP)


On Wed, Nov 27, 2013 at 8:32 AM, Andrew D Kirch <trelane at trelane.net> wrote:

> Eric,
>
> I'll note as a followup to the Ipv6 thread, I'm a _HUGE_ mikrotik fan.
>  One of the CCR models has 4 SFP's.
>
> Andrew
>
>
> On 11/26/2013 10:47 PM, Eric C. Miller wrote:
>
>> I'm looking at some non-Cisco price options to deliver more than 4 SFP
>> slots into a structure and was wondering if anyone had any experience with
>> ZyXEL's offerings in the service provider market. Specifically MGS-3712F or
>> GS-4012F
>>
>> Thank you for your comments!
>>
>> Eric Miller, CCNP
>> Network Engineering Consultant
>> (407) 257-5115
>>
>>
>>
>>
>
>

From kamtha at ak-labs.net  Wed Nov 27 17:56:00 2013
From: kamtha at ak-labs.net (Carlos Kamtha)
Date: Wed, 27 Nov 2013 12:56:00 -0500
Subject: 3rd party transit for anycast services?
Message-ID: <20131127175600.GA28397@ak-labs.net>

Hi, 

We have an anycast provider (internap) that cannot give us direct service in the AU region. 

I'm wondering if there are providers, not specifically internap,  that will allow another local ISP to 
'transit' anycast IP services thier behalf? 

Would a local AU provider want to do this?

I'm thinking that this not common practice and probably not desired.

Any feedback is greatly appreciated. 

Cheers. 

Carlos. 


From ml at kenweb.org  Wed Nov 27 17:59:45 2013
From: ml at kenweb.org (ML)
Date: Wed, 27 Nov 2013 12:59:45 -0500
Subject: Blocking private AS
In-Reply-To: <FA2E47FFA50291418803D2E7C1DF07F30A449870@SDEXCL01.Proflowers.com>
References: <FA2E47FFA50291418803D2E7C1DF07F30A449870@SDEXCL01.Proflowers.com>
Message-ID: <52963311.8090901@kenweb.org>

On 2/18/2010 2:27 PM, Thomas Magill wrote:
> I am thinking about implementing a filter to block all traffic with
> private AS numbers in the path.  I see quite a few in my table though so
> I am concerned I might block some legitimate traffic.  In some cases,
> these are just prefixes with the private appended to the end but a few
> have the private as a transit.  Is this a good idea or would I likely be
> blocking too much legitimate traffic?  The filter I am using currently
> shows the following:
>
>

I am also curious about blocking legitimate traffic.  I just implemented
a filter to remove routes with a private-AS anywhere in the path. Over
200 routes were filtered. 

I spot checked a few prefixes:

A few had a covering prefix
A few prefixes were originated by a non-private AS and a private AS and
would have otherwise been accepted if Cogent (In my case) had that route
as a best path
And a few prefixes just won't be reachable by my customers.

If anyone wants to see what I filtered out:http://pastebin.com/AFyYrfZk
<http://pastebin.com/AFyYrfZk>





From woody at pch.net  Wed Nov 27 18:01:30 2013
From: woody at pch.net (Bill Woodcock)
Date: Wed, 27 Nov 2013 10:01:30 -0800
Subject: 3rd party transit for anycast services?
In-Reply-To: <20131127175600.GA28397@ak-labs.net>
References: <20131127175600.GA28397@ak-labs.net>
Message-ID: <9CBD0ABC-4EF4-4466-9C7C-BAC32BD9D53E@pch.net>


On Nov 27, 2013, at 9:56 AM, Carlos Kamtha <kamtha at ak-labs.net> wrote:

> Hi, 
> 
> We have an anycast provider (internap) that cannot give us direct service in the AU region. 
> 
> I'm wondering if there are providers, not specifically internap,  that will allow another local ISP to 
> 'transit' anycast IP services thier behalf? 

Why not just originate the services from a prefix (or multiple prefixes) of your own?  Then you can pick and choose who you use where.  You still have to be careful that people don't "helpfully" backhaul stuff to places you don't want, but at least the policy lever is in your hands.

Short answer is yes, we do this for people all the time, and I'm sure many of the other large anycast providers do as well.

Renesys could probably tell you which ones, specifically.

                                -Bill




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131127/1faa9a4d/attachment.bin>

From kamtha at ak-labs.net  Wed Nov 27 18:23:10 2013
From: kamtha at ak-labs.net (Carlos Kamtha)
Date: Wed, 27 Nov 2013 13:23:10 -0500
Subject: 3rd party transit for anycast services?
In-Reply-To: <9CBD0ABC-4EF4-4466-9C7C-BAC32BD9D53E@pch.net>
References: <20131127175600.GA28397@ak-labs.net>
 <9CBD0ABC-4EF4-4466-9C7C-BAC32BD9D53E@pch.net>
Message-ID: <20131127182310.GC28397@ak-labs.net>

On Wed, Nov 27, 2013 at 10:01:30AM -0800, Bill Woodcock wrote:
> 
> On Nov 27, 2013, at 9:56 AM, Carlos Kamtha <kamtha at ak-labs.net> wrote:
> 
> > Hi, 
> > 
> > We have an anycast provider (internap) that cannot give us direct service in the AU region. 
> > 
> > I'm wondering if there are providers, not specifically internap,  that will allow another local ISP to 
> > 'transit' anycast IP services thier behalf? 
> 
> Why not just originate the services from a prefix (or multiple prefixes) of your own?  Then you can pick and choose who you use where.  You still have to be careful that people don't "helpfully" backhaul stuff to places you don't want, but at least the policy lever is in your hands.

Not an option atm. we do not have control over layer 3 and we do not currently own a CIDR block and, our BGP sessions are done with reserved 655xx ASN to our provider. 

> 
> Short answer is yes, we do this for people all the time, and I'm sure many of the other large anycast providers do as well.
> 
> Renesys could probably tell you which ones, specifically.

Noted. thanks! 

> 
>                                 -Bill
> 
> 
> 
> 




From silvertip257 at gmail.com  Wed Nov 27 23:13:03 2013
From: silvertip257 at gmail.com (SilverTip257)
Date: Wed, 27 Nov 2013 18:13:03 -0500
Subject: Meraki
In-Reply-To: <CALFTrnOa3N3pkVFoo4M+3ihzGQV=-BFqkGaTG_hKn9KjT583Hg@mail.gmail.com>
References: <CA+W-zopQpRzpOCXfBjyC1o9i0r_mEHujah94Q4LQenoBv9YWew@mail.gmail.com>
 <CALFTrnOa3N3pkVFoo4M+3ihzGQV=-BFqkGaTG_hKn9KjT583Hg@mail.gmail.com>
Message-ID: <CA+W-zopF45jJhHt6ttt8b_5FpiL=52+MJs=2p09gd0g+54+RfA@mail.gmail.com>

On Tue, Nov 26, 2013 at 8:44 AM, Ray Soucy <rps at maine.edu> wrote:

> Can confirm the current ER Lite is a plastic enclosure.
> But for $ 100 I can definitely look past that.
>

At that price point I'm not complaining.
However I do have a preference. ;)
And I do think that the metal cases are a better design - sturdier and
likely better heat dissipation.


>
> Also, most of the UBNT distributers seem to be very knowledgeable about
> the product line, so I'm sure they would know if you asked them :-)
>

Our rep had to do some digging...

He managed to tell me that the ERLite now has a metal case.  He did not
tell me whether they have any with metal enclosures.  But that's probably
hard for them to say though.


>
> We've been running XORP internally for about 100+ CPE devices (actually
> the ones we were looking at Vyatta as a replacement for).  In the end I
> think that moving to Quagga was a good thing for Vyatta as XORP doesn't
> have a very active developer community. XORP releases since 1.6 have been a
> forked code base that eventually became XORP 1.8.  It's very touchy, and
> requires quite a bit of operational experience to know what will cause it
> to crash and what won't.  The big thing you get with XORP that you don't
> with Quagga is multicast routing, and a more active community.  I've been
> really interested in BIRD [0] as well, but haven't had a chance to try it
> out.
>
>
BIRD is on my list too.


> Back to UBNT, though.  The ER makes use of a lot of non-free code (not so
> great), but it's to facilitate hardware acceleration (very nice).  A lot of
> functionality for IPv4 and IPv6 are both implemented in hardware, including
> not just forwarding and NAT, but also regex matching for DPI.  It's how
> they can get so much PPS for such a modest piece of hardware.  I believe
> the chips they use are from Cavium [1], but I could be mistaken.
>
> [0]. http://bird.network.cz/
> [1]. http://www.cavium.com/
>
>
Thanks for the informative discussion, Ray!   And others :)

-- 
---~~.~~---
Mike
//  SilverTip257  //

From morrowc.lists at gmail.com  Thu Nov 28 04:14:10 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 27 Nov 2013 23:14:10 -0500
Subject: 3rd party transit for anycast services?
In-Reply-To: <20131127182310.GC28397@ak-labs.net>
References: <20131127175600.GA28397@ak-labs.net>
 <9CBD0ABC-4EF4-4466-9C7C-BAC32BD9D53E@pch.net>
 <20131127182310.GC28397@ak-labs.net>
Message-ID: <CAL9jLaYkLBPAydMTb_EbhKbJgnasJz6RX-nk0wKccwxsMp8C1Q@mail.gmail.com>

On Wed, Nov 27, 2013 at 1:23 PM, Carlos Kamtha <kamtha at ak-labs.net> wrote:
> On Wed, Nov 27, 2013 at 10:01:30AM -0800, Bill Woodcock wrote:
>>
>> On Nov 27, 2013, at 9:56 AM, Carlos Kamtha <kamtha at ak-labs.net> wrote:
>>
>> > Hi,
>> >
>> > We have an anycast provider (internap) that cannot give us direct service in the AU region.
>> >
>> > I'm wondering if there are providers, not specifically internap,  that will allow another local ISP to
>> > 'transit' anycast IP services thier behalf?
>>
>> Why not just originate the services from a prefix (or multiple prefixes) of your own?  Then you can pick and choose who you use where.  You still have to be careful that people don't "helpfully" backhaul stuff to places you don't want, but at least the policy lever is in your hands.
>
> Not an option atm. we do not have control over layer 3 and we do not currently own a CIDR block and, our BGP sessions are done with reserved 655xx ASN to our provider.

isn't that sort of fixable with a simple request to your local RIR?

>
>>
>> Short answer is yes, we do this for people all the time, and I'm sure many of the other large anycast providers do as well.
>>
>> Renesys could probably tell you which ones, specifically.
>
> Noted. thanks!
>
>>
>>                                 -Bill
>>
>>
>>
>>
>
>
>


From kamtha at ak-labs.net  Thu Nov 28 04:18:59 2013
From: kamtha at ak-labs.net (Carlos Kamtha)
Date: Wed, 27 Nov 2013 23:18:59 -0500
Subject: 3rd party transit for anycast services?
In-Reply-To: <CAL9jLaYkLBPAydMTb_EbhKbJgnasJz6RX-nk0wKccwxsMp8C1Q@mail.gmail.com>
References: <20131127175600.GA28397@ak-labs.net>
 <9CBD0ABC-4EF4-4466-9C7C-BAC32BD9D53E@pch.net>
 <20131127182310.GC28397@ak-labs.net>
 <CAL9jLaYkLBPAydMTb_EbhKbJgnasJz6RX-nk0wKccwxsMp8C1Q@mail.gmail.com>
Message-ID: <20131128041859.GJ28397@ak-labs.net>

On Wed, Nov 27, 2013 at 11:14:10PM -0500, Christopher Morrow wrote:
> > Not an option atm. we do not have control over layer 3 and we do not currently own a CIDR block and, our BGP sessions are done with reserved 655xx ASN to our provider.
> 
> isn't that sort of fixable with a simple request to your local RIR?
> 

it is.. request in progress..

Carlos. 


From morrowc.lists at gmail.com  Thu Nov 28 04:19:45 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 27 Nov 2013 23:19:45 -0500
Subject: 3rd party transit for anycast services?
In-Reply-To: <20131128041859.GJ28397@ak-labs.net>
References: <20131127175600.GA28397@ak-labs.net>
 <9CBD0ABC-4EF4-4466-9C7C-BAC32BD9D53E@pch.net>
 <20131127182310.GC28397@ak-labs.net>
 <CAL9jLaYkLBPAydMTb_EbhKbJgnasJz6RX-nk0wKccwxsMp8C1Q@mail.gmail.com>
 <20131128041859.GJ28397@ak-labs.net>
Message-ID: <CAL9jLaaNPJgnxWfUwdt6cSAxdNX-mUdd2f=AhZTEfR5Uvy4yzw@mail.gmail.com>

On Wed, Nov 27, 2013 at 11:18 PM, Carlos Kamtha <kamtha at ak-labs.net> wrote:
> On Wed, Nov 27, 2013 at 11:14:10PM -0500, Christopher Morrow wrote:
>> > Not an option atm. we do not have control over layer 3 and we do not currently own a CIDR block and, our BGP sessions are done with reserved 655xx ASN to our provider.
>>
>> isn't that sort of fixable with a simple request to your local RIR?
>>
>
> it is.. request in progress..


great, then... you'll be able to turn up services whenever/whereever
you want shortly.

congrats!


From leo.vegoda at icann.org  Thu Nov 28 21:07:11 2013
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Thu, 28 Nov 2013 13:07:11 -0800
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <5290498A.6040405@trelane.net>
References: <5290498A.6040405@trelane.net>
Message-ID: <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>

Andrew D Kirch wrote:

Was I the only one who thought that everything about this was great
apart from this comment:

> In reality additional poking leads me to believe AT&T gives you a
rather 
> generous /60

Is a /60 what is considered generous these days? I thought a /48 was
considered normal and a /56 was considered a bit tight. What prefix
lengths are residential access providers handing out by default these
days? 

Regards,

Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5475 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131128/23aae728/attachment.bin>

From mureninc at gmail.com  Thu Nov 28 22:37:52 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Thu, 28 Nov 2013 14:37:52 -0800
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
Message-ID: <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>

On 28 November 2013 13:07, Leo Vegoda <leo.vegoda at icann.org> wrote:
> Andrew D Kirch wrote:
>
> Was I the only one who thought that everything about this was great
> apart from this comment:
>
>> In reality additional poking leads me to believe AT&T gives you a
> rather
>> generous /60
>
> Is a /60 what is considered generous these days? I thought a /48 was
> considered normal and a /56 was considered a bit tight. What prefix
> lengths are residential access providers handing out by default these
> days?

Remember, this is just 6rd.  With 6rd, a /60 does sound quite generous indeed.

And it's a /60 for each IPv4 you have, e.g. if you have a static IP
allocation with AT&T U-verse, say, a /27, then you're effectively
getting a /55 (plus also an additional /60 for the DHCP address in a
shared subnet to which your /27 is routed to).

That said, I wholeheartedly agree with your comment otherwise.

C.


From marka at isc.org  Thu Nov 28 22:56:38 2013
From: marka at isc.org (Mark Andrews)
Date: Fri, 29 Nov 2013 09:56:38 +1100
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: Your message of "Thu, 28 Nov 2013 14:37:52 -0800."
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
Message-ID: <20131128225638.74413AF290C@rock.dv.isc.org>


In message <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA at mail.gmail.com>
, "Constantine A. Murenin" writes:
> On 28 November 2013 13:07, Leo Vegoda <leo.vegoda at icann.org> wrote:
> > Andrew D Kirch wrote:
> >
> > Was I the only one who thought that everything about this was great
> > apart from this comment:
> >
> >> In reality additional poking leads me to believe AT&T gives you a
> > rather
> >> generous /60
> >
> > Is a /60 what is considered generous these days? I thought a /48 was
> > considered normal and a /56 was considered a bit tight. What prefix
> > lengths are residential access providers handing out by default these
> > days?
> 
> Remember, this is just 6rd.  With 6rd, a /60 does sound quite generous indeed
> .

You can hand out /48 as easily with 6rd as you can natively.

It's only when the ISP is lazy and encodes the entire IPv4 address
space into 6rd thereby wasting most of the IPv6 address space being
used for 6rd that a /60 appears to be generous.

You can do a 6rd domain per IPv4 allocation.  This is a one time
operation that doesn't need to be updated as you move IPv4 address
space around.

> And it's a /60 for each IPv4 you have, e.g. if you have a static IP
> allocation with AT&T U-verse, say, a /27, then you're effectively
> getting a /55 (plus also an additional /60 for the DHCP address in a
> shared subnet to which your /27 is routed to).
> 
> That said, I wholeheartedly agree with your comment otherwise.
> 
> C.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From mureninc at gmail.com  Thu Nov 28 23:40:11 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Thu, 28 Nov 2013 15:40:11 -0800
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <20131128225638.74413AF290C@rock.dv.isc.org>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
 <20131128225638.74413AF290C@rock.dv.isc.org>
Message-ID: <CAPKkNb6nCnP3Xk4xrLhvoiYBivw7pj3ggU3-bonxoTCBUYpUGA@mail.gmail.com>

On 28 November 2013 14:56, Mark Andrews <marka at isc.org> wrote:
>
> In message <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA at mail.gmail.com>
> , "Constantine A. Murenin" writes:
>> On 28 November 2013 13:07, Leo Vegoda <leo.vegoda at icann.org> wrote:
>> > Andrew D Kirch wrote:
>> >
>> > Was I the only one who thought that everything about this was great
>> > apart from this comment:
>> >
>> >> In reality additional poking leads me to believe AT&T gives you a
>> > rather
>> >> generous /60
>> >
>> > Is a /60 what is considered generous these days? I thought a /48 was
>> > considered normal and a /56 was considered a bit tight. What prefix
>> > lengths are residential access providers handing out by default these
>> > days?
>>
>> Remember, this is just 6rd.  With 6rd, a /60 does sound quite generous indeed
>> .
>
> You can hand out /48 as easily with 6rd as you can natively.
>
> It's only when the ISP is lazy and encodes the entire IPv4 address
> space into 6rd thereby wasting most of the IPv6 address space being
> used for 6rd that a /60 appears to be generous.
>
> You can do a 6rd domain per IPv4 allocation.  This is a one time
> operation that doesn't need to be updated as you move IPv4 address
> space around.

This might be true with smaller ISPs, but someone like AT&T probably
already has too many distinct IPv4 allocations for such an encoding to
be practically manageable.

Free, who has pioneered 6rd, and is a major ISP in France, seems to
have gone with a similar 6rd allocation policy, giving out /60 through
6rd for each IPv4, out of a /28 IPv6.  Seems quite reasonable.

    http://ripe58.ripe.net/content/presentations/ipv6-free.pdf

(So, AT&T simply copied the French here, it would appear.)

C.

>
>> And it's a /60 for each IPv4 you have, e.g. if you have a static IP
>> allocation with AT&T U-verse, say, a /27, then you're effectively
>> getting a /55 (plus also an additional /60 for the DHCP address in a
>> shared subnet to which your /27 is routed to).
>>
>> That said, I wholeheartedly agree with your comment otherwise.
>>
>> C.
>>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From marka at isc.org  Fri Nov 29 01:04:51 2013
From: marka at isc.org (Mark Andrews)
Date: Fri, 29 Nov 2013 12:04:51 +1100
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: Your message of "Thu, 28 Nov 2013 15:40:11 -0800."
 <CAPKkNb6nCnP3Xk4xrLhvoiYBivw7pj3ggU3-bonxoTCBUYpUGA@mail.gmail.com>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
 <20131128225638.74413AF290C@rock.dv.isc.org>
 <CAPKkNb6nCnP3Xk4xrLhvoiYBivw7pj3ggU3-bonxoTCBUYpUGA@mail.gmail.com>
Message-ID: <20131129010452.68AF0AF36E4@rock.dv.isc.org>


In message <CAPKkNb6nCnP3Xk4xrLhvoiYBivw7pj3ggU3-bonxoTCBUYpUGA at mail.gmail.com>, "Constantine A. Murenin" writes:
> On 28 November 2013 14:56, Mark Andrews <marka at isc.org> wrote:
> >
> > In message <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA at mail.gmail.com>
> > , "Constantine A. Murenin" writes:
> >> On 28 November 2013 13:07, Leo Vegoda <leo.vegoda at icann.org> wrote:
> >> > Andrew D Kirch wrote:
> >> >
> >> > Was I the only one who thought that everything about this was great
> >> > apart from this comment:
> >> >
> >> >> In reality additional poking leads me to believe AT&T gives you a
> >> > rather
> >> >> generous /60
> >> >
> >> > Is a /60 what is considered generous these days? I thought a /48 was
> >> > considered normal and a /56 was considered a bit tight. What prefix
> >> > lengths are residential access providers handing out by default these
> >> > days?
> >>
> >> Remember, this is just 6rd.  With 6rd, a /60 does sound quite generous indeed
> >> .
> >
> > You can hand out /48 as easily with 6rd as you can natively.
> >
> > It's only when the ISP is lazy and encodes the entire IPv4 address
> > space into 6rd thereby wasting most of the IPv6 address space being
> > used for 6rd that a /60 appears to be generous.
> >
> > You can do a 6rd domain per IPv4 allocation.  This is a one time
> > operation that doesn't need to be updated as you move IPv4 address
> > space around.
> 
> This might be true with smaller ISPs, but someone like AT&T probably
> already has too many distinct IPv4 allocations for such an encoding to
> be practically manageable.

Garbage.

If you are going with /48's

For each IPv4 /8 they have been allocated they carve out a IPv6 /24 for it.
For each IPv4 /22 they have been allocated they carve out a IPv6 /38 for it.

If you are going with /56's

For each IPv4 /8 they have been allocated they carve out a IPv6 /32 for it.
For each IPv4 /22 they have been allocated they carve out a IPv6 /46 for it.

Carving out smaller blocks from bigger blocks is what ISP's do all
the time when allocating space for customers and unlike customers
this doesn't have to be done over and over again.  It is a once off
when they receive the address block regardless of how they later
split up and move around the IPv4 address block.

> Free, who has pioneered 6rd, and is a major ISP in France, seems to
> have gone with a similar 6rd allocation policy, giving out /60 through
> 6rd for each IPv4, out of a /28 IPv6.  Seems quite reasonable.
> 
>     http://ripe58.ripe.net/content/presentations/ipv6-free.pdf
> 
> (So, AT&T simply copied the French here, it would appear.)
> 
> C.

Just because someone does one way it doesn't make them right or
correct.  It just means they did it that way.  This is saying "my
customers will *never* have more that 16 subnets" which is possible
true in the short term for home users but not for companies.  Think
how many vlans companies use today.  Each of those vlans should be
getting a /64.

It is short sighted decisions like this which force companies into
using NATs whether they want to or not.

Mark

> >> And it's a /60 for each IPv4 you have, e.g. if you have a static IP
> >> allocation with AT&T U-verse, say, a /27, then you're effectively
> >> getting a /55 (plus also an additional /60 for the DHCP address in a
> >> shared subnet to which your /27 is routed to).
> >>
> >> That said, I wholeheartedly agree with your comment otherwise.
> >>
> >> C.
> >>
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From swmike at swm.pp.se  Fri Nov 29 05:25:21 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 29 Nov 2013 06:25:21 +0100 (CET)
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <20131128225638.74413AF290C@rock.dv.isc.org>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
 <20131128225638.74413AF290C@rock.dv.isc.org>
Message-ID: <alpine.DEB.2.02.1311290622170.1157@uplift.swm.pp.se>

On Fri, 29 Nov 2013, Mark Andrews wrote:

> You can hand out /48 as easily with 6rd as you can natively.
>
> It's only when the ISP is lazy and encodes the entire IPv4 address
> space into 6rd thereby wasting most of the IPv6 address space being
> used for 6rd that a /60 appears to be generous.

You're contradicting yourself here. Yes, you're right about the technical 
solution, but it's not as easy (you need backend systems). Also, not all 
products support the variability of subnet lengths that the standard 
allows.

So if you're not mapping the entire space (actually some products only 
allow /32 IPv6 space) 1-1 you're making the whole solution harder due to 
complexity in your backend system plus you're limiting the amount of 
customer gear that will support the solution.

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


From jb at forethought.net  Fri Nov 29 05:37:00 2013
From: jb at forethought.net (Jawaid Desktop)
Date: Thu, 28 Nov 2013 22:37:00 -0700
Subject: What routers do folks use these days?
Message-ID: <529827FC.8040603@forethought.net>

We're a service provider, and we have a network full of Cat6509's. We 
are finding that we are outgrowing them from the standpoint of their 
ability to handle lots of large routing tables. Obviously their 
switching capability is still superb but one of them with 20 peers is 
starting to groan a bit and RAM is going to be an issue soon.

What do people use these days? Our backbone needs in the next 2-3 years 
are going to be sub-100Gbps.


Jawaid



From mehmet at akcin.net  Fri Nov 29 05:59:51 2013
From: mehmet at akcin.net (Mehmet Akcin)
Date: Thu, 28 Nov 2013 21:59:51 -0800
Subject: What routers do folks use these days?
In-Reply-To: <529827FC.8040603@forethought.net>
References: <529827FC.8040603@forethought.net>
Message-ID: <B22639B1-3E2E-4643-B48E-DDE36FB8A419@akcin.net>

Look at Juniper, MX Series.

mehmet

On Nov 28, 2013, at 9:37 PM, Jawaid Desktop <jb at forethought.net> wrote:

> We're a service provider, and we have a network full of Cat6509's. We are finding that we are outgrowing them from the standpoint of their ability to handle lots of large routing tables. Obviously their switching capability is still superb but one of them with 20 peers is starting to groan a bit and RAM is going to be an issue soon.
> 
> What do people use these days? Our backbone needs in the next 2-3 years are going to be sub-100Gbps.
> 
> 
> Jawaid
> 
> 



From swmike at swm.pp.se  Fri Nov 29 06:02:52 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 29 Nov 2013 07:02:52 +0100 (CET)
Subject: What routers do folks use these days?
In-Reply-To: <529827FC.8040603@forethought.net>
References: <529827FC.8040603@forethought.net>
Message-ID: <alpine.DEB.2.02.1311290700210.1157@uplift.swm.pp.se>

On Thu, 28 Nov 2013, Jawaid Desktop wrote:

> What do people use these days? Our backbone needs in the next 2-3 years 
> are going to be sub-100Gbps.

Cisco ASR 9000, Juniper MX, Huawei NE40E, Alcatel-Lucent 7750, those kinds 
of routers are the ones I hear people using. Some go for the new Sup2T for 
the 6500, but I don't know how much more CPU it has compared to your 
SUP/RSP720, perhaps someone else knows?

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


From rdobbins at arbor.net  Fri Nov 29 06:26:07 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Fri, 29 Nov 2013 06:26:07 +0000
Subject: What routers do folks use these days?
In-Reply-To: <529827FC.8040603@forethought.net>
References: <529827FC.8040603@forethought.net>
Message-ID: <EE2DF7F2-0F10-4E3C-931A-9227D7CB1B57@arbor.net>


On Nov 29, 2013, at 12:37 PM, Jawaid Desktop <jb at forethought.net> wrote:

> Our backbone needs in the next 2-3 years are going to be sub-100Gbps.

Make sure you get something that, unlike the pre-Sup2T 6500/7600, has operationally useful NetFlow, ACLs, and uRPF.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From sander at steffann.nl  Fri Nov 29 06:37:13 2013
From: sander at steffann.nl (Sander Steffann)
Date: Fri, 29 Nov 2013 07:37:13 +0100
Subject: What routers do folks use these days?
In-Reply-To: <alpine.DEB.2.02.1311290700210.1157@uplift.swm.pp.se>
References: <529827FC.8040603@forethought.net>
 <alpine.DEB.2.02.1311290700210.1157@uplift.swm.pp.se>
Message-ID: <C020C5FF-2135-44C7-B1EF-BFB0A116FD97@steffann.nl>

Hi Mikael,

> Some go for the new Sup2T for the 6500, but I don't know how much more CPU it has compared to your SUP/RSP720, perhaps someone else knows?

The Sup2T I worked on has:

 CPU: MPC8572_E, Version: 2.2, (0x80E80022)
 CORE: E500, Version: 3.0, (0x80210030)
 CPU:1500MHz, CCB:600MHz, DDR:600MHz

Compared to a Sup720:

 SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache

Needless to say, working on the Sup2T is wonderful compared to the Sup720 :-)

Cheers,
Sander



From marka at isc.org  Fri Nov 29 07:28:01 2013
From: marka at isc.org (Mark Andrews)
Date: Fri, 29 Nov 2013 18:28:01 +1100
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: Your message of "Fri, 29 Nov 2013 06:25:21 +0100."
 <alpine.DEB.2.02.1311290622170.1157@uplift.swm.pp.se>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
 <20131128225638.74413AF290C@rock.dv.isc.org>
 <alpine.DEB.2.02.1311290622170.1157@uplift.swm.pp.se>
Message-ID: <20131129072801.E26D2AF62CE@rock.dv.isc.org>


In message <alpine.DEB.2.02.1311290622170.1157 at uplift.swm.pp.se>, Mikael Abrahamsson writes:
> On Fri, 29 Nov 2013, Mark Andrews wrote:
> 
> > You can hand out /48 as easily with 6rd as you can natively.
> >
> > It's only when the ISP is lazy and encodes the entire IPv4 address
> > space into 6rd thereby wasting most of the IPv6 address space being
> > used for 6rd that a /60 appears to be generous.
> 
> You're contradicting yourself here.

What contradiction?  You need to break up the IPv6 address allocation
for both PD and 6rd.  I would say PD is slightly more complicated
than 6rd as you also want to optimise routing more with PD.  With
6rd you do the optimisation using the IPv4 addresses.

> Yes, you're right about the technical 
> solution, but it's not as easy (you need backend systems). Also, not all 
> products support the variability of subnet lengths that the standard 
> allows.

So who is shipping cr*p that claims to support RFC 5969 yet doesn't
all arbitary size 6rd domains?

The point of have a standard is so equipement from different
manufactures can work together.  A CPE device that can't accept all
legal values should be thrown in the bin.

> So if you're not mapping the entire space (actually some products only 
> allow /32 IPv6 space) 1-1 you're making the whole solution harder due to 
> complexity in your backend system plus you're limiting the amount of 
> customer gear that will support the solution.

I claim bovine excrement on customer gear.  Show me where the
6rdPrefixLen is defined to be 32?  Even with RFC 5569 it was up to
32 and the IPv4MaskLen is 0.

> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From swmike at swm.pp.se  Fri Nov 29 07:35:10 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 29 Nov 2013 08:35:10 +0100 (CET)
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <20131129072801.E26D2AF62CE@rock.dv.isc.org>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
 <20131128225638.74413AF290C@rock.dv.isc.org>
 <alpine.DEB.2.02.1311290622170.1157@uplift.swm.pp.se>
 <20131129072801.E26D2AF62CE@rock.dv.isc.org>
Message-ID: <alpine.DEB.2.02.1311290832350.1157@uplift.swm.pp.se>

On Fri, 29 Nov 2013, Mark Andrews wrote:

>
> In message <alpine.DEB.2.02.1311290622170.1157 at uplift.swm.pp.se>, Mikael Abrahamsson writes:
>> On Fri, 29 Nov 2013, Mark Andrews wrote:
>>
>>> You can hand out /48 as easily with 6rd as you can natively.
>>>
>> You're contradicting yourself here.
>
> What contradiction?

"As easily". It's easier to either hand out /64 by means of 1:1 mapping 
IPv4 and IPv6, or (if ability exists) hand out /48 or /56 using PD, than 
to get into the whole backend mess of having multiple 6RD domains with 
multiple configs per IPv4 subnet etc.

I agree with you theoretically, but in practice I disagree.

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


From kuenzler at init7.net  Fri Nov 29 08:19:33 2013
From: kuenzler at init7.net (Fredy Kuenzler)
Date: Fri, 29 Nov 2013 09:19:33 +0100
Subject: What routers do folks use these days?
In-Reply-To: <529827FC.8040603@forethought.net>
References: <529827FC.8040603@forethought.net>
Message-ID: <52984E15.3070307@init7.net>

Am 29.11.2013 06:37, schrieb Jawaid Desktop:
> We're a service provider, and we have a network full of Cat6509's.
> We are finding that we are outgrowing them from the standpoint of
> their ability to handle lots of large routing tables. Obviously
> their switching capability is still superb but one of them with 20
> peers is starting to groan a bit and RAM is going to be an issue
> soon.
> 
> What do people use these days? Our backbone needs in the next 2-3
> years are going to be sub-100Gbps.

Check the Brocade MLXe series. We (Init7 / AS13030) are using them and
the previous XMR series for years and are happy with it. CLI is
Cisco-look-and-feel, the software tree has a clear structure (unlike
Cisco with hundreds of versions) and the TAC is willing to ssh into your
gear to assist.

-- 
Fredy Kuenzler

Init7 (Switzerland) Ltd.
AS13030
St. Georgen-Strasse 70
CH-8400 Winterthur
Twitter: @init7 / @kuenzler
http://www.init7.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131129/47609113/attachment.bin>

From owen at delong.com  Fri Nov 29 09:41:10 2013
From: owen at delong.com (Owen DeLong)
Date: Fri, 29 Nov 2013 01:41:10 -0800
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
Message-ID: <DF2B23A8-7EB9-4547-8BE3-8C396F8E6CF8@delong.com>


On Nov 28, 2013, at 1:07 PM, Leo Vegoda <leo.vegoda at icann.org> wrote:

> Andrew D Kirch wrote:
> 
> Was I the only one who thought that everything about this was great
> apart from this comment:
> 
>> In reality additional poking leads me to believe AT&T gives you a
> rather 
>> generous /60
> 
> Is a /60 what is considered generous these days? I thought a /48 was
> considered normal and a /56 was considered a bit tight. What prefix
> lengths are residential access providers handing out by default these
> days? 
> 
> Regards,
> 
> Leo

Agreed? Unforutnately, the big guys (Comcast, AT&T) in America seem to like victimizing their customers with undersized assignments, limiting choice of proper prefix sizes to only their business class customers. I?m not sure why they are doing this. I know when I?ve had conversations with them, they haven?t exactly given a reason so much as just said that they thought a /48 was ridiculous.

Of course, if AT&T is blocking protocol 41, that?s even worse, because at least so long as that isn?t blocked, you can still get an HE tunnel and get a /48 if you need it anyway.

Owen



From rs at seastrom.com  Fri Nov 29 13:39:59 2013
From: rs at seastrom.com (Rob Seastrom)
Date: Fri, 29 Nov 2013 08:39:59 -0500
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <20131129010452.68AF0AF36E4@rock.dv.isc.org> (Mark Andrews's
 message of "Fri, 29 Nov 2013 12:04:51 +1100")
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
 <20131128225638.74413AF290C@rock.dv.isc.org>
 <CAPKkNb6nCnP3Xk4xrLhvoiYBivw7pj3ggU3-bonxoTCBUYpUGA@mail.gmail.com>
 <20131129010452.68AF0AF36E4@rock.dv.isc.org>
Message-ID: <86haav72ds.fsf@valhalla.seastrom.com>


I'd like to call everyone's attention to ARIN's policy on IPv6
transition space https://www.arin.net/policy/nrpm.html#six531 which
was created specifically in response to the standardization of 6rd.

The discussion at the time that this policy was under consideration
was that encoding the [m,n] in a non-overlapping fashion when one has
a bajillion allocations due to slow start was a pain in the butt and
that, in practice, everyone would just encode 32 bits of IPv4 into 6rd.

Note that it's possible to get a /24 of IPv6 space (huge!).  Yes, it's
from space that is "tainted" as being marked as transition space.
Yes, you have to recertify that you're using it for the intended
purpose every three years.

Of course, 24 + 32 = 56.  This is not an accident.  It was our sense
at the time that /56 was bad enough and that there was no reason to
codify giving people an even more parsimonious slice of IPv6 space.

So there really is no excuse on AT&T's part for the /60s on uverse 6rd...

-r



From Jean-Francois.TremblayING at videotron.com  Fri Nov 29 13:47:38 2013
From: Jean-Francois.TremblayING at videotron.com (Jean-Francois.TremblayING at videotron.com)
Date: Fri, 29 Nov 2013 08:47:38 -0500
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <alpine.DEB.2.02.1311290832350.1157@uplift.swm.pp.se>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
 <20131128225638.74413AF290C@rock.dv.isc.org>
 <alpine.DEB.2.02.1311290622170.1157@uplift.swm.pp.se>
 <20131129072801.E26D2AF62CE@rock.dv.isc.org>
 <alpine.DEB.2.02.1311290832350.1157@uplift.swm.pp.se>
Message-ID: <OF471BD0B7.98B51D3F-ON85257C32.0049563F-85257C32.004BC65F@videotron.com>

> De : Mikael Abrahamsson <swmike at swm.pp.se>
> A : Mark Andrews <marka at isc.org>, 
> >>> You can hand out /48 as easily with 6rd as you can natively.
> 
> "As easily". It's easier to either hand out /64 by means of 1:1 mapping 
> IPv4 and IPv6, or (if ability exists) hand out /48 or /56 using PD, than 

> to get into the whole backend mess of having multiple 6RD domains with 
> multiple configs per IPv4 subnet etc.
> 
> I agree with you theoretically, but in practice I disagree.

Some hard data points here, coming from one of the rare operator
who actually deployed 6RD sub-domains to all its customers (to my 
knowledge). 

In practice, most 6RD implementations that support option 212 do 
support IPv4MaskLen properly these days.  It wasn't the case 3 years ago, 
but we worked a lot with vendors to make it right. Seems ok now, 
we mostly have a 6RD population of D-Link and Cisco/Linksys. 

On the backend side, it's really not that bad. A one-page TCL 
handles around 15-16 sub-domains for us without noticeable impact 
on the DHCP servers CPU. Configuring the relays with all the 
tunnels can be a bit of fun playing with hex maths, but it's 
not too bad either. 

So I agree with Mark, it's not that complex. I can't agree with
him on the prefix size though. We hand out /60s because we feel
it's enough from a transition point of view (these are short-lived
anyway) and offering a bigger size would really use too much space. 

Offering /48s out of a single /16 block, to take a simple example, 
would use a whole /32. This space wouldn't be used much anyway, 
given that most 6RD routers use only one /64, sometimes two. 
I argue that a /60 is actually the best compromise here, from 
a space and usage point of view. 

/JF
Videotron, AS5769


From symack at gmail.com  Fri Nov 29 13:54:48 2013
From: symack at gmail.com (Nick Cameo)
Date: Fri, 29 Nov 2013 08:54:48 -0500
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <OF471BD0B7.98B51D3F-ON85257C32.0049563F-85257C32.004BC65F@videotron.com>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
 <20131128225638.74413AF290C@rock.dv.isc.org>
 <alpine.DEB.2.02.1311290622170.1157@uplift.swm.pp.se>
 <20131129072801.E26D2AF62CE@rock.dv.isc.org>
 <alpine.DEB.2.02.1311290832350.1157@uplift.swm.pp.se>
 <OF471BD0B7.98B51D3F-ON85257C32.0049563F-85257C32.004BC65F@videotron.com>
Message-ID: <CAGWRaZYnmwycb5AHH5NiKrywNniJzC+gQK2NrW1ud6R-1Q5JiA@mail.gmail.com>

They are all the same, ATT, Bell Canada, Cogeco......

On 11/29/13, Jean-Francois.TremblayING at videotron.com
<Jean-Francois.TremblayING at videotron.com> wrote:
>> De : Mikael Abrahamsson <swmike at swm.pp.se>
>> A : Mark Andrews <marka at isc.org>,
>> >>> You can hand out /48 as easily with 6rd as you can natively.
>>
>> "As easily". It's easier to either hand out /64 by means of 1:1 mapping
>> IPv4 and IPv6, or (if ability exists) hand out /48 or /56 using PD, than
>
>> to get into the whole backend mess of having multiple 6RD domains with
>> multiple configs per IPv4 subnet etc.
>>
>> I agree with you theoretically, but in practice I disagree.
>
> Some hard data points here, coming from one of the rare operator
> who actually deployed 6RD sub-domains to all its customers (to my
> knowledge).
>
> In practice, most 6RD implementations that support option 212 do
> support IPv4MaskLen properly these days.  It wasn't the case 3 years ago,
> but we worked a lot with vendors to make it right. Seems ok now,
> we mostly have a 6RD population of D-Link and Cisco/Linksys.
>
> On the backend side, it's really not that bad. A one-page TCL
> handles around 15-16 sub-domains for us without noticeable impact
> on the DHCP servers CPU. Configuring the relays with all the
> tunnels can be a bit of fun playing with hex maths, but it's
> not too bad either.
>
> So I agree with Mark, it's not that complex. I can't agree with
> him on the prefix size though. We hand out /60s because we feel
> it's enough from a transition point of view (these are short-lived
> anyway) and offering a bigger size would really use too much space.
>
> Offering /48s out of a single /16 block, to take a simple example,
> would use a whole /32. This space wouldn't be used much anyway,
> given that most 6RD routers use only one /64, sometimes two.
> I argue that a /60 is actually the best compromise here, from
> a space and usage point of view.
>
> /JF
> Videotron, AS5769
>
>


From sigasecure at gmail.com  Fri Nov 29 14:32:33 2013
From: sigasecure at gmail.com (mr. s)
Date: Fri, 29 Nov 2013 09:32:33 -0500
Subject: DOCSIS 3.0 and Multicast
Message-ID: <CAJ7STkCmJ+hECX254QRnpq6BLT9mrB+yF7cJs9-rTV0ZCsWhTg@mail.gmail.com>

To Those Who Do DOCSIS3.0,

I can't seem to find a simple answer to this, possibly because it is self
evident to those actually using Multicast over DOCSIS. Which we are not
currently.

Multicast over DOCSIS 3.0, to 3.0 CM, can the CM share the same media
stream on their node?

In example, 2 Cable Modems in the same node (no splitting, same US/DS
channels/ports, CMTS..), each have a customer watching ESPN.

Is there one or two media streams worth of content on the plant, channels,
node?

We now how this operates in other worlds, GPON, xDSL and AE. Just haven't
seen it specifically mentioned out right in DOCSIS literature.

Thanks for any direction you have.

From khelms at zcorum.com  Fri Nov 29 14:58:30 2013
From: khelms at zcorum.com (Scott Helms)
Date: Fri, 29 Nov 2013 09:58:30 -0500
Subject: DOCSIS 3.0 and Multicast
In-Reply-To: <CAJ7STkCmJ+hECX254QRnpq6BLT9mrB+yF7cJs9-rTV0ZCsWhTg@mail.gmail.com>
References: <CAJ7STkCmJ+hECX254QRnpq6BLT9mrB+yF7cJs9-rTV0ZCsWhTg@mail.gmail.com>
Message-ID: <CAMrdfRzg2iun6W_YHE91QpQFXC7-bCqmSngfidzLAKXLvK3m1g@mail.gmail.com>

Keep in mind that in the cable world the node itself is a layer 1 device,
basically it converts between fiber and coax signaling, and so it doesn't
take part in any IP transactions.  Now, if your CMTS supports multicast and
the modems on the same node are on the same downstream AND multicast is
enabled on the CMTS then the devices behind the modem (which is a bridge)
can use the same stream.  A device behind the modem could actually be an
embedded device on the modem, but in the DOCSIS world the modem itself
(usually) has its own MAC address and each integrated device will have its
own so a home gateway product (video, MOCA, voice, router, and WIFI) will
often have 5+ MAC addresses, one for each of the devices and often each one
has its own configuration.

This tutorial may help some:

http://www.nanog.org/meetings/nanog48/presentations/Sunday/Riddel_VDOC_N48.pdf


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------


On Fri, Nov 29, 2013 at 9:32 AM, mr. s <sigasecure at gmail.com> wrote:

> To Those Who Do DOCSIS3.0,
>
> I can't seem to find a simple answer to this, possibly because it is self
> evident to those actually using Multicast over DOCSIS. Which we are not
> currently.
>
> Multicast over DOCSIS 3.0, to 3.0 CM, can the CM share the same media
> stream on their node?
>
> In example, 2 Cable Modems in the same node (no splitting, same US/DS
> channels/ports, CMTS..), each have a customer watching ESPN.
>
> Is there one or two media streams worth of content on the plant, channels,
> node?
>
> We now how this operates in other worlds, GPON, xDSL and AE. Just haven't
> seen it specifically mentioned out right in DOCSIS literature.
>
> Thanks for any direction you have.
>

From bedard.phil at gmail.com  Fri Nov 29 15:34:29 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Fri, 29 Nov 2013 10:34:29 -0500
Subject: DOCSIS 3.0 and Multicast
In-Reply-To: <CAJ7STkCmJ+hECX254QRnpq6BLT9mrB+yF7cJs9-rTV0ZCsWhTg@mail.gmail.com>
Message-ID: <CEBE1BDD.7F5FB%bedard.phil@gmail.com>

I would take a look at the presentation in the other post, there are
multitude of ways it can be accomplished and some of those are spelled out
in the DOCSIS 3.0 specs.

Like the other poster said, HFC architectures are very centralized and
controlled at the head-end and the components in the field such as the
fiber node and even the CM are not active in making decisions about where
traffic goes, they just receive what has been sent to them and pass it
along.  Ultimately any multicast streams will go to a set-top box (or some
other video device) and in the case of dynamic multicast it would be the
STB generating the IGMP joins.

But to answer your question, the answer is yes, the same stream can be
sent to two different receivers in the same service group.  By the time it
gets to the fiber node, it's just RF and if the CM is tuned to the right
frequencies, either a specific one for video, or a shared one, it can be
used.  

Most providers aren't doing IP video over DOCSIS, they are still using QAM
based delivery via dedicated video spectrum.


Phil 


On 11/29/13, 9:32 AM, "mr. s" <sigasecure at gmail.com> wrote:

>To Those Who Do DOCSIS3.0,
>
>I can't seem to find a simple answer to this, possibly because it is self
>evident to those actually using Multicast over DOCSIS. Which we are not
>currently.
>
>Multicast over DOCSIS 3.0, to 3.0 CM, can the CM share the same media
>stream on their node?
>
>In example, 2 Cable Modems in the same node (no splitting, same US/DS
>channels/ports, CMTS..), each have a customer watching ESPN.
>
>Is there one or two media streams worth of content on the plant, channels,
>node?
>
>We now how this operates in other worlds, GPON, xDSL and AE. Just haven't
>seen it specifically mentioned out right in DOCSIS literature.
>
>Thanks for any direction you have.




From tvarriale at comcast.net  Fri Nov 29 16:05:48 2013
From: tvarriale at comcast.net (Tony Varriale)
Date: Fri, 29 Nov 2013 10:05:48 -0600
Subject: What routers do folks use these days?
In-Reply-To: <529827FC.8040603@forethought.net>
References: <529827FC.8040603@forethought.net>
Message-ID: <5298BB5C.60604@comcast.net>

On 11/28/2013 11:37 PM, Jawaid Desktop wrote:
> We're a service provider, and we have a network full of Cat6509's. We 
> are finding that we are outgrowing them from the standpoint of their 
> ability to handle lots of large routing tables. Obviously their 
> switching capability is still superb but one of them with 20 peers is 
> starting to groan a bit and RAM is going to be an issue soon.
>
> What do people use these days? Our backbone needs in the next 2-3 
> years are going to be sub-100Gbps.
>
>
> Jawaid
>
>
>
If you are looking to stay with Cisco, and depending on features you 
want, you'll be interested in the ASR1ks and ASR9ks.

tv


From darrenoc at outlook.com  Fri Nov 29 16:18:37 2013
From: darrenoc at outlook.com (Darren O'Connor)
Date: Fri, 29 Nov 2013 16:18:37 +0000
Subject: What routers do folks use these days?
In-Reply-To: <52984E15.3070307@init7.net>
References: <529827FC.8040603@forethought.net>,<52984E15.3070307@init7.net>
Message-ID: <DUB121-W400C074C91997EB11945F1DEE90@phx.gbl>

We are using Juniper MX and Brocade XMRs for our P and PE routers.



Thanks
Darren
http://www.mellowd.co.uk/ccie



> Date: Fri, 29 Nov 2013 09:19:33 +0100
> From: kuenzler at init7.net
> To: nanog at nanog.org
> Subject: Re: What routers do folks use these days?
> 
> Am 29.11.2013 06:37, schrieb Jawaid Desktop:
> > We're a service provider, and we have a network full of Cat6509's.
> > We are finding that we are outgrowing them from the standpoint of
> > their ability to handle lots of large routing tables. Obviously
> > their switching capability is still superb but one of them with 20
> > peers is starting to groan a bit and RAM is going to be an issue
> > soon.
> > 
> > What do people use these days? Our backbone needs in the next 2-3
> > years are going to be sub-100Gbps.
> 
> Check the Brocade MLXe series. We (Init7 / AS13030) are using them and
> the previous XMR series for years and are happy with it. CLI is
> Cisco-look-and-feel, the software tree has a clear structure (unlike
> Cisco with hundreds of versions) and the TAC is willing to ssh into your
> gear to assist.
> 
> -- 
> Fredy Kuenzler
> 
> Init7 (Switzerland) Ltd.
> AS13030
> St. Georgen-Strasse 70
> CH-8400 Winterthur
> Twitter: @init7 / @kuenzler
> http://www.init7.net/
> 
 		 	   		  

From paul at paulstewart.org  Fri Nov 29 16:35:46 2013
From: paul at paulstewart.org (Paul Stewart)
Date: Fri, 29 Nov 2013 11:35:46 -0500
Subject: What routers do folks use these days?
In-Reply-To: <DUB121-W400C074C91997EB11945F1DEE90@phx.gbl>
References: <529827FC.8040603@forethought.net>, <52984E15.3070307@init7.net>
 <DUB121-W400C074C91997EB11945F1DEE90@phx.gbl>
Message-ID: <A4F1847A-5DB1-435A-AF5D-1526B2E4255D@paulstewart.org>

Juniper throughout on our side now ? former Cisco shop.  Overall, quite happy ?. MX,M,E,EX,SRX etc?

Paul


On Nov 29, 2013, at 11:18 AM, Darren O'Connor <darrenoc at outlook.com> wrote:

> We are using Juniper MX and Brocade XMRs for our P and PE routers.
> 
> 
> 
> Thanks
> Darren
> http://www.mellowd.co.uk/ccie
> 
> 
> 
>> Date: Fri, 29 Nov 2013 09:19:33 +0100
>> From: kuenzler at init7.net
>> To: nanog at nanog.org
>> Subject: Re: What routers do folks use these days?
>> 
>> Am 29.11.2013 06:37, schrieb Jawaid Desktop:
>>> We're a service provider, and we have a network full of Cat6509's.
>>> We are finding that we are outgrowing them from the standpoint of
>>> their ability to handle lots of large routing tables. Obviously
>>> their switching capability is still superb but one of them with 20
>>> peers is starting to groan a bit and RAM is going to be an issue
>>> soon.
>>> 
>>> What do people use these days? Our backbone needs in the next 2-3
>>> years are going to be sub-100Gbps.
>> 
>> Check the Brocade MLXe series. We (Init7 / AS13030) are using them and
>> the previous XMR series for years and are happy with it. CLI is
>> Cisco-look-and-feel, the software tree has a clear structure (unlike
>> Cisco with hundreds of versions) and the TAC is willing to ssh into your
>> gear to assist.
>> 
>> -- 
>> Fredy Kuenzler
>> 
>> Init7 (Switzerland) Ltd.
>> AS13030
>> St. Georgen-Strasse 70
>> CH-8400 Winterthur
>> Twitter: @init7 / @kuenzler
>> http://www.init7.net/
>> 
> 		 	   		  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4889 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131129/6586f7e1/attachment-0001.bin>

From bedard.phil at gmail.com  Fri Nov 29 17:00:02 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Fri, 29 Nov 2013 12:00:02 -0500
Subject: What routers do folks use these days?
In-Reply-To: <529827FC.8040603@forethought.net>
References: <529827FC.8040603@forethought.net>
Message-ID: <CAJKFXQ+AK6wZxsFNmrviPeiFr4JOW8HfyA2+2Dm66mwyDJj3pg@mail.gmail.com>

We use Juniper, Cisco, and ALU in different roles.  All of them have their
quirks and bugs but none have been a big enough issue to seriously look at
moving away from them.  We use the MX, PTX, EX, SRX on the Junipers and
mainly 7600/ASR9K/Nexus for Cisco and 7750 for ALU.

What are you doing on your network today with regards to routing protocols
and services?  Chances are the 9K/MX/7750 could work in your network fine.
The 7750 doesn't easily support the notion of a SVI if you make extensive
use of those.  The 9K didn't at FCS but does now.   The OS is completely
different for all three so there is some learning curve.

The MX and 9K both have new generations that just came out with the
MX2010/2020 and ASR99xx boxes, but for your needs the older chassis would
work fine.

Phil
 On Nov 29, 2013 12:38 AM, "Jawaid Desktop" <jb at forethought.net> wrote:

> We're a service provider, and we have a network full of Cat6509's. We are
> finding that we are outgrowing them from the standpoint of their ability to
> handle lots of large routing tables. Obviously their switching capability
> is still superb but one of them with 20 peers is starting to groan a bit
> and RAM is going to be an issue soon.
>
> What do people use these days? Our backbone needs in the next 2-3 years
> are going to be sub-100Gbps.
>
>
> Jawaid
>
>
>

From karn at philkarn.net  Fri Nov 29 17:09:42 2013
From: karn at philkarn.net (Phil Karn)
Date: Fri, 29 Nov 2013 09:09:42 -0800
Subject: DOCSIS 3.0 and Multicast
In-Reply-To: <CEBE1BDD.7F5FB%bedard.phil@gmail.com>
References: <CEBE1BDD.7F5FB%bedard.phil@gmail.com>
Message-ID: <5298CA56.8070703@philkarn.net>

Do any cable companies actually use the hardware multicast capability in
DOCSIS cable modems?

I can think of some potentially neat uses, but it seems highly unlikely
that the cable companies would enable their use to compete against their
own TV programming services.




From frnkblk at iname.com  Fri Nov 29 18:03:59 2013
From: frnkblk at iname.com (Frank Bulk)
Date: Fri, 29 Nov 2013 12:03:59 -0600
Subject: DOCSIS 3.0 and Multicast
In-Reply-To: <5298CA56.8070703@philkarn.net>
References: <CEBE1BDD.7F5FB%bedard.phil@gmail.com>
 <5298CA56.8070703@philkarn.net>
Message-ID: <001501ceed2d$6103bff0$230b3fd0$@iname.com>

It's been tried in Iowa (Butler-Bremmer Communications) and elsewhere, but
last I heard, there were bugs in the multicast implementation of the CMs and
the middleware vendor didn't have a very large marketshare.  GoBackTV was
more focused on the LATAM market and the company is now owned by Aurora.
They used Asian STBs, not the Motorola/Scientific Atlanta/Amino/Entone STBs
that you may be familiar with.  So the end-product looks somewhat cobbled
together.

It looks like Cisco is doing something in the IP Video over DOCSIS area, and
so if you're serious about this, you could reach out to them.

Regards,

Frank

-----Original Message-----
From: Phil Karn [mailto:karn at philkarn.net] 
Sent: Friday, November 29, 2013 11:10 AM
To: nanog at nanog.org
Subject: Re: DOCSIS 3.0 and Multicast

Do any cable companies actually use the hardware multicast capability in
DOCSIS cable modems?

I can think of some potentially neat uses, but it seems highly unlikely
that the cable companies would enable their use to compete against their
own TV programming services.







From cscora at apnic.net  Fri Nov 29 18:07:34 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 30 Nov 2013 04:07:34 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201311291807.rATI7YPN031288@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, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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

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

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

Routing Table Report   04:00 +10GMT Sat 30 Nov, 2013

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

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

BGP routing table entries examined:                              475032
    Prefixes after maximum aggregation:                          189765
    Deaggregation factor:                                          2.50
    Unique aggregates announced to Internet:                     234882
Total ASes present in the Internet Routing Table:                 45606
    Prefixes per ASN:                                             10.42
Origin-only ASes present in the Internet Routing Table:           35425
Origin ASes announcing only one prefix:                           16285
Transit ASes present in the Internet Routing Table:                5965
Transit-only ASes present in the Internet Routing Table:            172
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                     103
    Max AS path prepend of ASN ( 50404)                             101
Prefixes from unregistered ASNs in the Routing Table:              1026
    Unregistered ASNs in the Routing Table:                         289
Number of 32-bit ASNs allocated by the RIRs:                       5418
Number of 32-bit ASNs visible in the Routing Table:                4216
Prefixes from 32-bit ASNs in the Routing Table:                   13406
Number of bogon 32-bit ASNs visible in the Routing Table:             2
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:           1239
Number of addresses announced to Internet:                   2657605980
    Equivalent to 158 /8s, 103 /16s and 217 /24s
    Percentage of available address space announced:               71.8
    Percentage of allocated address space announced:               71.8
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               95.3
Total number of prefixes smaller than registry allocations:      166229

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

Prefixes being announced by APNIC Region ASes:                   112516
    Total APNIC prefixes after maximum aggregation:               34078
    APNIC Deaggregation factor:                                    3.30
Prefixes being announced from the APNIC address blocks:          114817
    Unique aggregates announced from the APNIC address blocks:    47954
APNIC Region origin ASes present in the Internet Routing Table:    4871
    APNIC Prefixes per ASN:                                       23.57
APNIC Region origin ASes announcing only one prefix:               1214
APNIC Region transit ASes present in the Internet Routing Table:    837
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         35
Number of APNIC region 32-bit ASNs visible in the Routing Table:    763
Number of APNIC addresses announced to Internet:              729050048
    Equivalent to 43 /8s, 116 /16s and 107 /24s
    Percentage of available APNIC address space announced:         85.2

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-63999, 131072-133631
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:                    163913
    Total ARIN prefixes after maximum aggregation:                81702
    ARIN Deaggregation factor:                                     2.01
Prefixes being announced from the ARIN address blocks:           164722
    Unique aggregates announced from the ARIN address blocks:     75893
ARIN Region origin ASes present in the Internet Routing Table:    15939
    ARIN Prefixes per ASN:                                        10.33
ARIN Region origin ASes announcing only one prefix:                6009
ARIN Region transit ASes present in the Internet Routing Table:    1660
Average ARIN Region AS path length visible:                         4.1
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:      40
Number of ARIN addresses announced to Internet:              1073898880
    Equivalent to 64 /8s, 2 /16s and 101 /24s
    Percentage of available ARIN address space announced:          56.8

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8,
                       205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8,
                       216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    119613
    Total RIPE prefixes after maximum aggregation:                61150
    RIPE Deaggregation factor:                                     1.96
Prefixes being announced from the RIPE address blocks:           123355
    Unique aggregates announced from the RIPE address blocks:     78716
RIPE Region origin ASes present in the Internet Routing Table:    17548
    RIPE Prefixes per ASN:                                         7.03
RIPE Region origin ASes announcing only one prefix:                8302
RIPE Region transit ASes present in the Internet Routing Table:    2831
Average RIPE Region AS path length visible:                         5.1
    Max RIPE Region AS path length visible:                         103
Number of RIPE region 32-bit ASNs visible in the Routing Table:    2497
Number of RIPE addresses announced to Internet:               656262372
    Equivalent to 39 /8s, 29 /16s and 196 /24s
    Percentage of available RIPE address space announced:          95.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-200191
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:                   53124
    Total LACNIC prefixes after maximum aggregation:              10039
    LACNIC Deaggregation factor:                                   5.29
Prefixes being announced from the LACNIC address blocks:          58489
    Unique aggregates announced from the LACNIC address blocks:   27297
LACNIC Region origin ASes present in the Internet Routing Table:   2047
    LACNIC Prefixes per ASN:                                      28.57
LACNIC Region origin ASes announcing only one prefix:               551
LACNIC Region transit ASes present in the Internet Routing Table:   401
Average LACNIC Region AS path length visible:                       4.9
    Max LACNIC Region AS path length visible:                        35
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   908
Number of LACNIC addresses announced to Internet:             145688376
    Equivalent to 8 /8s, 175 /16s and 7 /24s
    Percentage of available LACNIC address space announced:        86.8

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 262144-263679 plus 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:                  11728
    Total AfriNIC prefixes after maximum aggregation:              2587
    AfriNIC Deaggregation factor:                                  4.53
Prefixes being announced from the AfriNIC address blocks:         12410
    Unique aggregates announced from the AfriNIC address blocks:   4024
AfriNIC Region origin ASes present in the Internet Routing Table:   689
    AfriNIC Prefixes per ASN:                                     18.01
AfriNIC Region origin ASes announcing only one prefix:              209
AfriNIC Region transit ASes present in the Internet Routing Table:  142
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    8
Number of AfriNIC addresses announced to Internet:             48532736
    Equivalent to 2 /8s, 228 /16s and 141 /24s
    Percentage of available AfriNIC address space announced:       48.2

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2930      11557         940   Korea Telecom (KIX)
17974     2718        902          90   PT TELEKOMUNIKASI INDONESIA
 7545     2113        319         111   TPG Internet Pty Ltd
 4755     1792        392         190   TATA Communications formerly 
 9829     1544       1245          45   BSNL National Internet Backbo
 9583     1251         95         510   Sify Limited
 9498     1216        309          73   BHARTI Airtel Ltd.
 7552     1165       1080          13   Vietel Corporation
 4808     1145       2119         336   CNCGROUP IP network: China169
24560     1102        382         166   Bharti Airtel Ltd., Telemedia

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
 6389     3042       3688          53   BellSouth.net Inc.
22773     2208       2939         136   Cox Communications, Inc.
18566     2053        379         178   MegaPath Corporation
 1785     2044        685         132   PaeTec Communications, Inc.
20115     1682       1653         602   Charter Communications 
 4323     1642       1090         419   Time Warner Telecom
  701     1507      11144         781   MCI Communications Services, 
 7029     1468       1241         163   Windstream Communications Inc
30036     1390        313         582   Mediacom Communications Corp 
 7018     1332      17779         872   AT&T WorldNet Services

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
 8402     1932        544          16   OJSC "Vimpelcom"
34984     1367        244         224   TELLCOM ILETISIM HIZMETLERI A
20940     1191        453         889   Akamai Technologies European 
31148     1010         45          20   FreeNet ISP
13188      896         99          48   TOV "Bank-Inform"
 6849      856        363          39   JSC UKRTELECOM,
 8551      787        370          41   Bezeq International
 6830      772       2327         424   UPC Distribution Services
12479      680        798          53   Uni2 Autonomous System
35228      549        246          16   Avatar Broadband Limited

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
28573     3405       1807          90   NET Servicos de Comunicao S.A
10620     2671        433         213   Telmex Colombia S.A.
 7303     1726       1151         230   Telecom Argentina Stet-France
18881     1706        908          20   Global Village Telecom 
 8151     1360       2852         420   UniNet S.A. de C.V. 
11830      868        364          15   Instituto Costarricense de El
27947      847         93          90   Telconet S.A
 6147      792        373          27   Telefonica Del Peru 
 7738      780       1498          36   Telecomunicacoes da Bahia S.A
 6503      775        434          60   AVANTEL, S.A. 

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
36998     1864        112           5   Sudanese Mobile Telephone (ZA
24863      868        338          26   LINKdotNET AS number
 6713      554        633          26   Itissalat Al-MAGHRIB
 8452      412        956           9   TEDATA
24835      297        144           9   RAYA Telecom - Egypt
 3741      251        921         209   The Internet Solution 
36992      234        471          25   Etisalat MISR
29571      227         17          14   Ci Telecom Autonomous system 
15706      221         32           6   Sudatel Internet Exchange Aut
29975      192        668          21   Vodacom

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
28573     3405       1807          90   NET Servicos de Comunicao S.A
 6389     3042       3688          53   BellSouth.net Inc.
 4766     2930      11557         940   Korea Telecom (KIX)
17974     2718        902          90   PT TELEKOMUNIKASI INDONESIA
10620     2671        433         213   Telmex Colombia S.A.
22773     2208       2939         136   Cox Communications, Inc.
 7545     2113        319         111   TPG Internet Pty Ltd
18566     2053        379         178   MegaPath Corporation
 1785     2044        685         132   PaeTec Communications, Inc.
 8402     1932        544          16   OJSC "Vimpelcom"

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

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

  ASN   No of nets  Net Savings Description
 6389      3042        2989      BellSouth.net Inc.
17974      2718        2628      PT TELEKOMUNIKASI INDONESIA
10620      2671        2458      Telmex Colombia S.A.
22773      2208        2072      Cox Communications, Inc.
 7545      2113        2002      TPG Internet Pty Ltd
 4766      2930        1990      Korea Telecom (KIX)
 8402      1932        1916      OJSC "Vimpelcom"
 1785      2044        1912      PaeTec Communications, Inc.
18566      2053        1875      MegaPath Corporation
36998      1864        1859      Sudanese Mobile Telephone (ZA

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

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

Bad AS  Designation  Network              Transit AS  Description
62828   UNALLOCATED  8.21.130.0/24         4323       Time Warner Telecom
62850   UNALLOCATED  8.25.147.0/24        46887       Lightower Fiber Netw
62734   UNALLOCATED  8.31.128.0/24         6939       Hurricane Electric 
62773   UNALLOCATED  8.35.180.0/22         3356       Level 3 Communicatio
65160   PRIVATE      12.1.58.0/24         17361       Sungard Trading Syst
65160   PRIVATE      12.1.59.0/24         17361       Sungard Trading Syst
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
62719   UNALLOCATED  12.27.130.0/24        4323       Time Warner Telecom
62861   UNALLOCATED  12.37.197.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic

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

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.100.0.0/24        4847     China Networks Inter-Exchange

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

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

Network            Origin AS  Description
23.90.128.0/18       27418     OUTOFWALL INC.
23.91.0.0/19         40676     Psychz Networks
23.91.4.0/24         40676     Psychz Networks
23.91.14.0/24        40676     Psychz Networks
23.91.32.0/19        36315     Servpac Inc. 
23.91.80.0/20        21560     Capital Technology Services G
23.91.96.0/20        37958     ChinaCache Networks ASN
23.91.112.0/21       32475     MidPhase Inc. 
23.91.120.0/21       36351     SoftLayer Technologies Inc. 
23.91.160.0/19       36493     3757277 Canada Inc. (oa 295.c

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:11      /10:31      /11:92      /12:253     
/13:476     /14:932     /15:1640    /16:12850   /17:6793    /18:11348   
/19:23177   /20:33029   /21:35687   /22:50161   /23:44117   /24:251913  
/25:876     /26:997     /27:469     /28:50      /29:81      /30:20      
/31:0       /32:13      

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

  ASN   No of nets  Total ann.   Description
18566     2008          2053      MegaPath Corporation
36998     1829          1864      Sudanese Mobile Telephone (ZA
 6389     1700          3042      BellSouth.net Inc.
 8402     1616          1932      OJSC "Vimpelcom"
22773     1462          2208      Cox Communications, Inc.
30036     1232          1390      Mediacom Communications Corp 
11492     1195          1233      Cable One 
 1785     1088          2044      PaeTec Communications, Inc.
 7029     1046          1468      Windstream Communications Inc
 6983     1035          1293      ITC^Deltacom 

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

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

   1:909       2:859       3:3         4:17        5:1024      6:21     
   8:610      12:1874     13:3        14:901      15:11       16:3      
  17:18       18:19       20:25       23:606      24:1760     27:1699   
  31:1520     32:45       33:2        34:5        36:95       37:1941   
  38:917      39:5        40:185      41:3265     42:323      44:14     
  46:2043     47:10       49:696      50:856      52:12       54:44     
  55:5        56:4        57:26       58:1171     59:580      60:368    
  61:1493     62:1250     63:1977     64:4401     65:2356     66:4250   
  67:2102     68:1103     69:3312     70:949      71:515      72:2024   
  74:2635     75:394      76:304      77:1216     78:1081     79:666    
  80:1275     81:1053     82:629      83:690      84:592      85:1257   
  86:382      87:1023     88:552      89:1551     90:154      91:5692   
  92:613      93:1611     94:2086     95:1511     96:515      97:347    
  98:1085     99:41      100:31      101:659     103:3731    105:530    
 106:143     107:218     108:537     109:2001    110:982     111:1123   
 112:595     113:803     114:767     115:1058    116:1009    117:834    
 118:1206    119:1292    120:342     121:761     122:1875    123:1270   
 124:1423    125:1433    128:658     129:232     130:353     131:669    
 132:352     133:158     134:302     135:72      136:276     137:251    
 138:350     139:181     140:200     141:337     142:547     143:395    
 144:497     145:90      146:551     147:419     148:776     149:370    
 150:153     151:664     152:412     153:207     154:53      155:506    
 156:306     157:420     158:284     159:783     160:361     161:458    
 162:915     163:227     164:622     165:587     166:283     167:637    
 168:1043    169:125     170:1106    171:185     172:12      173:1671   
 174:721     175:538     176:1333    177:2574    178:1878    179:302    
 180:1595    181:874     182:1411    183:473     184:640     185:1074   
 186:2646    187:1456    188:1862    189:1253    190:7298    192:7087   
 193:5441    194:4028    195:3357    196:1338    197:1034    198:4752   
 199:5509    200:6061    201:2526    202:9007    203:8898    204:4532   
 205:2652    206:2852    207:2810    208:3966    209:3672    210:3069   
 211:1592    212:2151    213:2005    214:891     215:86      216:5437   
 217:1705    218:631     219:323     220:1274    221:585     222:332    
 223:522    

End of report


From rs at seastrom.com  Fri Nov 29 18:31:08 2013
From: rs at seastrom.com (Rob Seastrom)
Date: Fri, 29 Nov 2013 13:31:08 -0500
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <OF471BD0B7.98B51D3F-ON85257C32.0049563F-85257C32.004BC65F@videotron.com>
 (Jean-Francois TremblayING's message of "Fri, 29 Nov 2013 08:47:38 -0500")
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
 <CAPKkNb6Nhr-bcvkTwTjf+rFovhYjv0+xyCPM6D4CndvZn3FqeA@mail.gmail.com>
 <20131128225638.74413AF290C@rock.dv.isc.org>
 <alpine.DEB.2.02.1311290622170.1157@uplift.swm.pp.se>
 <20131129072801.E26D2AF62CE@rock.dv.isc.org>
 <alpine.DEB.2.02.1311290832350.1157@uplift.swm.pp.se>
 <OF471BD0B7.98B51D3F-ON85257C32.0049563F-85257C32.004BC65F@videotron.com>
Message-ID: <86li07ukk3.fsf@valhalla.seastrom.com>


Jean-Francois.TremblayING at videotron.com writes:

> Offering /48s out of a single /16 block, to take a simple example, 
> would use a whole /32.

Sounds as if your organization can justify more than the /32
"minimum/default" allocation of IPv6 then (I'd imagine you have more
than a minimum-assignment /22 of IPv4 space based on my interactions
with Videotron back circa 2004 too).  Have you tried asking for more
IPv6 space, backed up with your network architecture documents?

> This space wouldn't be used much anyway, 
> given that most 6RD routers use only one /64, sometimes two. 
> I argue that a /60 is actually the best compromise here, from 
> a space and usage point of view. 

IPv4-thinking.  In the fullness of time this line of reasoning will be
greeted with the same wry grin and eyeroll that the NANOG community
today reserves for academics who teach their students "classful
networking".

-r



From gary.buhrmaster at gmail.com  Fri Nov 29 18:43:50 2013
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 29 Nov 2013 18:43:50 +0000
Subject: AT&T UVERSE Native IPv6, a HOWTO
In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
References: <5290498A.6040405@trelane.net>
 <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>
Message-ID: <CAMfXtQwWAc5uUEe8sRPwKKcvMWBmHN0UgX6ogSaWWS+dAasdcQ@mail.gmail.com>

On Thu, Nov 28, 2013 at 9:07 PM, Leo Vegoda <leo.vegoda at icann.org> wrote:
....
> Is a /60 what is considered generous these days?

I do not think so.  I think that is more minimal than generous.

> I thought a /48 was
> considered normal and a /56 was considered a bit tight. What prefix
> lengths are residential access providers handing out by default these
> days?

A /60 appears (by reports from AT&T and Comcast customers)
seems to be the current behavior for some residential access
providers.  I am sure one can find counter examples.

And while I can rationalize the thinking (I suspect few
home users currently use more than 16 internal networks),
with solutions that will eventually depend on further prefix
sub-delegation downstream (aka HIPNet), /60 feels a bit tight.
I would certainly feel more comfortable seeing the providers
start offering at least a /56, if not a /48, if requested by the
customer.

It is conceivable that the residential providers intend to offer
more than a /60 at additional costs (as they offer more than
one IPv4 address today), or to offer more than a /60 only to
those that request it (to minimize some perceived "waste"
of IPv6 numbers).  I would expect that "Business" customers
will almost certainly see different offerings (/48s?).  It is also
conceivable that the residential providers have not (yet)
thought it all through.

Gary


From karn at philkarn.net  Fri Nov 29 18:47:55 2013
From: karn at philkarn.net (Phil Karn)
Date: Fri, 29 Nov 2013 10:47:55 -0800
Subject: DOCSIS 3.0 and Multicast
In-Reply-To: <001501ceed2d$6103bff0$230b3fd0$@iname.com>
References: <CEBE1BDD.7F5FB%bedard.phil@gmail.com>
 <5298CA56.8070703@philkarn.net> <001501ceed2d$6103bff0$230b3fd0$@iname.com>
Message-ID: <5298E15B.7070101@philkarn.net>

On 11/29/2013 10:03 AM, Frank Bulk wrote:

> It looks like Cisco is doing something in the IP Video over DOCSIS area, and
> so if you're serious about this, you could reach out to them.

It's not video over IP multicast that interests me so much as the
opportunity to thwart NSA-style bulk traffic analysis by multicasting
unicast messages with encrypted destination addresses so an eavesdropper
can't tell who it's for.




From khelms at zcorum.com  Fri Nov 29 19:38:34 2013
From: khelms at zcorum.com (Scott Helms)
Date: Fri, 29 Nov 2013 14:38:34 -0500
Subject: DOCSIS 3.0 and Multicast
In-Reply-To: <5298E15B.7070101@philkarn.net>
References: <CEBE1BDD.7F5FB%bedard.phil@gmail.com>
 <5298CA56.8070703@philkarn.net>
 <001501ceed2d$6103bff0$230b3fd0$@iname.com>
 <5298E15B.7070101@philkarn.net>
Message-ID: <CAMrdfRzFOO9nd1ATS7uHh6-rqB+ZAXfgBZ8VS73wT8Y34CABJA@mail.gmail.com>

Phil,

Arbitrarily turning uni-cast traffic into multi-cast won't do much in that
regard.  If the end points that didn't orginally ask for the data NAK the
incoming stream then they'll get kicked out of the IGMP group, further the
requesting end point will be confused by the fact that the traffic is
coming in as multi-cast.  You could put up some fake hosts that will take
any multi-cast data, but they'd be pretty easy to spot over time and making
all of your home gateways accept multi-cast traffic they didn't ask for
would be a bad thing (think trivial DDoS of your system).




Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------


On Fri, Nov 29, 2013 at 1:47 PM, Phil Karn <karn at philkarn.net> wrote:

> On 11/29/2013 10:03 AM, Frank Bulk wrote:
>
> > It looks like Cisco is doing something in the IP Video over DOCSIS area,
> and
> > so if you're serious about this, you could reach out to them.
>
> It's not video over IP multicast that interests me so much as the
> opportunity to thwart NSA-style bulk traffic analysis by multicasting
> unicast messages with encrypted destination addresses so an eavesdropper
> can't tell who it's for.
>
>
>
>

From karn at philkarn.net  Fri Nov 29 20:35:28 2013
From: karn at philkarn.net (Phil Karn)
Date: Fri, 29 Nov 2013 12:35:28 -0800
Subject: DOCSIS 3.0 and Multicast
In-Reply-To: <CAMrdfRzFOO9nd1ATS7uHh6-rqB+ZAXfgBZ8VS73wT8Y34CABJA@mail.gmail.com>
References: <CEBE1BDD.7F5FB%bedard.phil@gmail.com>
 <5298CA56.8070703@philkarn.net> <001501ceed2d$6103bff0$230b3fd0$@iname.com>
 <5298E15B.7070101@philkarn.net>
 <CAMrdfRzFOO9nd1ATS7uHh6-rqB+ZAXfgBZ8VS73wT8Y34CABJA@mail.gmail.com>
Message-ID: <5298FA90.7040605@philkarn.net>

On 11/29/2013 11:38 AM, Scott Helms wrote:
> Phil,
> 
> Arbitrarily turning uni-cast traffic into multi-cast won't do much in
> that regard.  If the end points that didn't orginally ask for the data
> NAK the incoming stream then they'll get kicked out of the IGMP group,
> further the requesting end point will be confused by the fact that the
> traffic is coming in as multi-cast.  You could put up some fake hosts
> that will take any multi-cast data, but they'd be pretty easy to spot
> over time and making all of your home gateways accept multi-cast traffic
> they didn't ask for would be a bad thing (think trivial DDoS of your
> system).

Oh, sorry, I meant to explain that this would be part of a new system
with user software explicitly written to join a multicast group,
passively listen to all incoming traffic, decrypt whatever's addressed
to it and ignore the rest.

If the destination addresses are hashed or encrypted so that only the
recipient can recognize them, then passive eavesdropping would not
reveal to whom they were being sent and the system would be no less
efficient than an existing cable modem network with the same set of users.

I've been trying to think of ways to thwart large scale traffic
analysis, and in a unicast network it's really not easy without a lot of
extra traffic (think TOR).



From jra at baylink.com  Fri Nov 29 21:11:41 2013
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 29 Nov 2013 16:11:41 -0500 (EST)
Subject: DOCSIS 3.0 and Multicast
In-Reply-To: <5298FA90.7040605@philkarn.net>
Message-ID: <18649202.3526.1385759501036.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Phil Karn" <karn at philkarn.net>

> I've been trying to think of ways to thwart large scale traffic
> analysis, and in a unicast network it's really not easy without a lot
> of extra traffic (think TOR).

Well, in a story in MIT Tech Review this week, it's mentioned that IETF is
considering baking TOR into the base level of the Internet, so if (like me)
you think that's a pretty unmanageable, inefficient approach, you might want
to chime in now...

Cheers,
-- jra

-- 
Make Election Day a federal holiday: http://wh.gov/lBm94  100k sigs by 12/14

Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From karn at philkarn.net  Fri Nov 29 21:49:43 2013
From: karn at philkarn.net (Phil Karn)
Date: Fri, 29 Nov 2013 13:49:43 -0800
Subject: DOCSIS 3.0 and Multicast
In-Reply-To: <18649202.3526.1385759501036.JavaMail.root@benjamin.baylink.com>
References: <18649202.3526.1385759501036.JavaMail.root@benjamin.baylink.com>
Message-ID: <52990BF7.1050208@philkarn.net>

On 11/29/2013 01:11 PM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Phil Karn" <karn at philkarn.net>
> 
>> I've been trying to think of ways to thwart large scale traffic
>> analysis, and in a unicast network it's really not easy without a lot
>> of extra traffic (think TOR).
> 
> Well, in a story in MIT Tech Review this week, it's mentioned that IETF is
> considering baking TOR into the base level of the Internet, so if (like me)
> you think that's a pretty unmanageable, inefficient approach, you might want
> to chime in now...
> 

Well, it's inefficient compared to direct unicasting but I can't think
of a much better way to do it. And if you really want security against
dragnet surveillance, and I think we do, we'll find a way to manage it.

Hey, it's not like fiber bandwidth and CPU cycles are hard to find these
days.






From victor at jvknet.com  Fri Nov 29 21:59:32 2013
From: victor at jvknet.com (Victor Kuarsingh)
Date: Fri, 29 Nov 2013 16:59:32 -0500
Subject: DOCSIS 3.0 and Multicast
In-Reply-To: <5298E15B.7070101@philkarn.net>
References: <CEBE1BDD.7F5FB%bedard.phil@gmail.com>
 <5298CA56.8070703@philkarn.net>
 <001501ceed2d$6103bff0$230b3fd0$@iname.com>
 <5298E15B.7070101@philkarn.net>
Message-ID: <CAJc3aaM=u+B35X8W7yt-SU0zBNV+82D-k9DurmiwikySurXKVA@mail.gmail.com>

Phil,

Been watching this conversation and had a few comments.

First, one of the concerns is exposure to wire monitoring on the HFC
(Hybrid-Fiber Coax) plant while using DOCSIS, then I think folks should be
aware that there is encryption applied to the traffic between the CMTS and
Cable Modem (CM).  This was traditionally BPI (Baseline Privacy Inspection)
and DOCSIS 3.0 supports SEC (which then allows use of AES).  I may have
missed the point along this email train, but folks may not be aware that
putting an RF capturing device on the plant, or sitting behind a CM on the
does not gain you gratuitous access to neighbouring people's data.  So if
application/network flows are also encrypted, you would not necessarily be
able to know who it's for as all payload traffic should already be
encrypted on the [DOCSIS] wire.  This however does not change eavesdropping
on the outside of the DOCSIS plan (after CM, or before CMTS).

If one did come up with a way of sending normal traffic over a DOCSIS
Multicast pipe, then there are a number of resource issues which need to be
considered (as they have operator and vendor impact).  Multicast is managed
very differently (signalling and payload) in DOCSIS vs. Unicast traffic,
and therefore resources will be an issue (i.e. IDs used to direct traffic
for Unicast are not the same as those used for Multicast).  To add, forcing
a bunch of (or all) traffic down a Multicast pipe would impact an
operator's ability to managed QoS for customers (which is already complex
enough in the DOCSIS world) and may impact CM operation (which will be
keeping track what multicast groups/packets will be forwarded for a given
service endpoint).

regards,

Victor K



On Fri, Nov 29, 2013 at 1:47 PM, Phil Karn <karn at philkarn.net> wrote:

> On 11/29/2013 10:03 AM, Frank Bulk wrote:
>
> > It looks like Cisco is doing something in the IP Video over DOCSIS area,
> and
> > so if you're serious about this, you could reach out to them.
>
> It's not video over IP multicast that interests me so much as the
> opportunity to thwart NSA-style bulk traffic analysis by multicasting
> unicast messages with encrypted destination addresses so an eavesdropper
> can't tell who it's for.
>
>
>
>

From cidr-report at potaroo.net  Fri Nov 29 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 29 Nov 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201311292200.rATM00wC082855@wattle.apnic.net>

This report has been generated at Fri Nov 29 21:13:33 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        22-11-13    483927      273267
        23-11-13    484394      273042
        24-11-13    483904      273160
        25-11-13    484114      273204
        26-11-13    484358      273519
        27-11-13    484806      273511
        28-11-13    484564      273716
        29-11-13    485190      274270


AS Summary
         45765  Number of ASes in routing system
         18790  Number of ASes announcing only one prefix
          4530  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      118901504  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 29Nov13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     485792   274250   211542    43.5%   All ASes

AS28573     3406       91     3315    97.3%   NET Servi?os de Comunica??o
                                               S.A.
AS6389      3042       56     2986    98.2%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS17974     2717      188     2529    93.1%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS7029      4530     2027     2503    55.3%   WINDSTREAM - Windstream
                                               Communications Inc
AS22773     2211      161     2050    92.7%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4766      2930      949     1981    67.6%   KIXS-AS-KR Korea Telecom
AS18881     1706       31     1675    98.2%   Global Village Telecom
AS36998     1864      375     1489    79.9%   SDN-MOBITEL
AS18566     2052      566     1486    72.4%   MEGAPATH5-US - MegaPath
                                               Corporation
AS4323      2961     1524     1437    48.5%   TWTC - tw telecom holdings,
                                               inc.
AS7303      1729      470     1259    72.8%   Telecom Argentina S.A.
AS1785      2044      823     1221    59.7%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1793      579     1214    67.7%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS10620     2673     1468     1205    45.1%   Telmex Colombia S.A.
AS7552      1198      139     1059    88.4%   VIETEL-AS-AP Vietel
                                               Corporation
AS22561     1240      221     1019    82.2%   AS22561 - CenturyTel Internet
                                               Holdings, Inc.
AS9829      1540      660      880    57.1%   BSNL-NIB National Internet
                                               Backbone
AS35908      919       96      823    89.6%   VPLSNET - Krypt Technologies
AS7545      2114     1300      814    38.5%   TPG-INTERNET-AP TPG Telecom
                                               Limited
AS18101      981      180      801    81.7%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS24560     1102      354      748    67.9%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS4808      1146      399      747    65.2%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS8151      1369      642      727    53.1%   Uninet S.A. de C.V.
AS701       1507      783      724    48.0%   UUNET - MCI Communications
                                               Services, Inc. d/b/a Verizon
                                               Business
AS6983      1293      578      715    55.3%   ITCDELTA - ITC^Deltacom
AS13977      855      143      712    83.3%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS6147       792      108      684    86.4%   Telefonica del Peru S.A.A.
AS855        730       58      672    92.1%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS4780      1019      352      667    65.5%   SEEDNET Digital United Inc.
AS4788       874      212      662    75.7%   TMNET-AS-AP TM Net, Internet
                                               Service Provider

Total      54337    15533    38804    71.4%   Top 30 total


Possible Bogus Routes

        27.54.116.0/22       AS55452 
        27.54.116.0/24       AS55452 
        27.54.119.0/24       AS55452 
        27.100.7.0/24        AS56096 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.122.216.0/22      AS48727 
        63.247.0.0/19        AS226   LOS-NETTOS-AS - Los Nettos
        63.247.0.0/24        AS27609 
        63.247.1.0/24        AS27609 
        63.247.2.0/24        AS27609 
        63.247.3.0/24        AS27609 
        63.247.4.0/24        AS27609 
        63.247.5.0/24        AS27609 
        63.247.6.0/24        AS27609 
        63.247.7.0/24        AS27609 
        63.247.8.0/24        AS27609 
        63.247.9.0/24        AS27609 
        63.247.10.0/24       AS27609 
        63.247.11.0/24       AS27609 
        63.247.13.0/24       AS27609 
        63.247.14.0/24       AS27609 
        63.247.15.0/24       AS27609 
        63.247.16.0/24       AS27609 
        63.247.17.0/24       AS27609 
        63.247.18.0/24       AS27609 
        63.247.19.0/24       AS27609 
        63.247.20.0/24       AS27609 
        63.247.21.0/24       AS27609 
        63.247.22.0/24       AS27609 
        63.247.23.0/24       AS27609 
        63.247.24.0/24       AS27609 
        63.247.25.0/24       AS27609 
        63.247.26.0/24       AS27609 
        63.247.27.0/24       AS27609 
        63.247.28.0/24       AS27609 
        63.247.29.0/24       AS27609 
        64.25.16.0/23        AS19535 
        64.25.20.0/24        AS19535 
        64.25.21.0/24        AS19535 
        64.25.22.0/24        AS19535 
        64.25.27.0/24        AS7046  RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business
        64.111.0.0/20        AS8039  CCC-ASN-1 - Cinergy Communications
        64.111.160.0/20      AS40551 
        64.111.160.0/24      AS40551 
        64.111.161.0/24      AS40551 
        64.111.162.0/24      AS40551 
        64.111.167.0/24      AS40551 
        64.111.169.0/24      AS40551 
        64.111.170.0/24      AS40551 
        64.111.171.0/24      AS40551 
        64.111.172.0/24      AS40551 
        64.111.173.0/24      AS40551 
        64.111.174.0/24      AS40551 
        64.111.175.0/24      AS40551 
        64.185.224.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.225.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.226.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.227.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.228.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.229.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.230.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.231.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.232.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.233.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.234.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.235.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.236.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.237.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.238.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.239.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.202.48.0/22       AS23380 
        64.202.52.0/23       AS23380 
        64.202.54.0/24       AS23380 
        64.202.55.0/24       AS23380 
        64.202.56.0/22       AS23380 
        64.202.60.0/24       AS23380 
        64.202.61.0/24       AS23380 
        64.202.62.0/24       AS23380 
        64.202.63.0/24       AS23380 
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global
        66.11.112.0/20       AS14572 
        66.55.96.0/23        AS17203 
        66.55.98.0/24        AS17203 
        66.55.99.0/24        AS17203 
        66.55.100.0/22       AS17203 
        66.55.102.0/23       AS17203 
        66.55.104.0/21       AS17203 
        66.180.64.0/21       AS32558 ZEUTER - Zeuter Development Corporation
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.187.240.0/20      AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        66.206.208.0/22      AS23380 
        66.206.211.0/24      AS14288 MPINET - MPInet
        66.206.212.0/24      AS23380 
        66.206.213.0/24      AS14288 MPINET - MPInet
        66.206.214.0/24      AS23380 
        66.206.215.0/24      AS23380 
        66.206.216.0/23      AS14288 MPINET - MPInet
        66.206.218.0/23      AS23380 
        66.206.220.0/22      AS23380 
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.254.160.0/20      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.176.0/21      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.184.0/22      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.188.0/22      AS35916 MULTA-ASN1 - MULTACOM CORPORATION
        67.21.144.0/22       AS174   COGENT Cogent/PSI
        67.21.148.0/22       AS174   COGENT Cogent/PSI
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.19.0.0/19         AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        72.35.224.0/22       AS30097 NUWAVE - NuWave
        72.35.232.0/21       AS6246  AVALONTEL - AvalonTel
        72.44.16.0/20        AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC
        74.112.100.0/22      AS16764 
        74.113.200.0/23      AS46939 
        74.114.52.0/22       AS40818 
        74.114.52.0/23       AS40818 
        74.114.52.0/24       AS40818 
        74.114.53.0/24       AS40818 
        74.114.54.0/23       AS40818 
        74.114.54.0/24       AS40818 
        74.114.55.0/24       AS40818 
        74.114.140.0/22      AS32757 
        74.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        74.118.132.0/22      AS5117  
        91.193.60.0/22       AS3356  LEVEL3 Level 3 Communications
        91.195.66.0/23       AS3356  LEVEL3 Level 3 Communications
        91.197.36.0/22       AS43359 
        91.199.90.0/24       AS44330 
        91.207.152.0/24      AS64100 
        91.207.153.0/24      AS64100 
        91.209.115.0/24      AS31103 KEYWEB-AS Keyweb AG
        91.212.54.0/24       AS21409 IKOULA Ikoula Net SAS
        93.190.8.0/24        AS47254 
        93.190.9.0/24        AS47254 
        93.190.10.0/24       AS47254 
        94.158.16.0/22       AS3257  TINET-BACKBONE Tinet SpA
        94.158.20.0/22       AS3257  TINET-BACKBONE Tinet SpA
        94.158.24.0/22       AS3257  TINET-BACKBONE Tinet SpA
        94.158.28.0/22       AS3257  TINET-BACKBONE Tinet SpA
        100.100.0.0/24       AS4847  CNIX-AP China Networks Inter-Exchange
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. 
        103.11.1.0/24        AS9822  AMNET-AU-AP Amnet IT Services Pty Ltd
        103.13.184.0/23      AS58674 
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        124.64.0.0/10        AS4847  CNIX-AP China Networks Inter-Exchange
        164.40.184.0/24      AS19821 
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.116.0.0/24       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        174.136.192.0/18     AS14572 
        178.218.240.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.241.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.242.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.243.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.244.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.245.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.246.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.247.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.248.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.249.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.250.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.251.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.252.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.253.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.254.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.255.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA SAS
        190.15.72.0/21       AS15146 CABLEBAHAMAS - Cable Bahamas
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        192.166.32.0/20      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        193.9.59.0/24        AS1257  TELE2
        193.16.106.0/24      AS31539 
        193.22.224.0/20      AS3322  
        193.22.238.0/23      AS6824  HERMES-NETWORK Hermes Telecom International Ltd
        193.33.66.0/23       AS39874 
        193.109.15.0/24      AS12690 MKSNET-AS MKS Autonomous System
        193.164.152.0/24     AS3356  LEVEL3 Level 3 Communications
        193.178.217.0/24     AS20737 
        193.188.252.0/24     AS8697  JTC-AS8697 Jordan Telecommunications Company
        193.202.8.0/21       AS3322  
        193.254.218.0/23     AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC
        194.34.56.0/24       AS3549  GBLX Global Crossing Ltd.
        194.34.56.0/25       AS3549  GBLX Global Crossing Ltd.
        194.34.56.128/26     AS3549  GBLX Global Crossing Ltd.
        194.50.82.0/24       AS16276 OVH OVH Systems
        194.63.152.0/22      AS3356  LEVEL3 Level 3 Communications
        194.79.48.0/22       AS39117 
        194.113.27.0/24      AS12518 SHLINK SHLINK Internet Service
        194.126.219.0/24     AS34545 
        195.28.168.0/23      AS8655  
        195.114.4.0/23       AS41158 
        195.128.240.0/23     AS21202 DCSNET-AS Bredband2 AB
        195.130.208.0/24     AS16265 LEASEWEB LeaseWeb B.V.
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA
        195.234.156.0/24     AS25028 
        195.248.240.0/23     AS34169 MEDIA-COM-TYCHY Media-Com Sp. z o.o.
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.18.112.0/20      AS1916  Associa??o Rede Nacional de Ensino e Pesquisa
        200.58.248.0/21      AS27849 
        201.71.16.0/20       AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.49.33.0/24       AS7657  VODAFONE-NZ-NGN-AS Vodafone NZ Ltd.
        202.58.113.0/24      AS19161 
        202.59.240.0/24      AS17477 MCT-SYDNEY Macquarie Telecom
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.158.251.0/24     AS9255  CONNECTPLUS-AS Singapore Telecom
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.142.219.0/24     AS45149 
        203.191.56.0/21      AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service
        204.9.32.0/24        AS25617 
        204.9.33.0/24        AS25617 
        204.9.34.0/24        AS25617 
        204.9.35.0/24        AS25617 
        204.9.116.0/22       AS30097 NUWAVE - NuWave
        204.10.88.0/21       AS3356  LEVEL3 Level 3 Communications
        204.10.92.0/23       AS30097 NUWAVE - NuWave
        204.10.94.0/23       AS30097 NUWAVE - NuWave
        204.15.208.0/22      AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC
        204.69.144.0/24      AS27283 RJF-INTERNET - Raymond James Financial, Inc.
        204.106.16.0/24      AS4323  TWTC - tw telecom holdings, inc.
        204.115.110.0/23     AS53709 
        204.187.11.0/24      AS51113 ELEKTA-AS Elekta
        204.225.173.0/24     AS6407  PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
        205.159.44.0/24      AS40157 ADESA-CORP-AS - ADESA Corp
        205.207.66.0/24      AS15290 ALLST-15290 - Allstream Corp.
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network
        205.236.71.0/24      AS852   ASN852 - TELUS Communications Inc.
        206.81.112.0/20      AS32618 ADKNO-KC - Adknowledge, Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        206.221.176.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.177.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.178.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.179.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.180.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.181.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.182.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.183.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.184.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.185.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.186.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.187.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.188.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.189.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.190.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.191.0/24     AS27431 JTLNET - JTL Networks Inc.
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        207.254.128.0/21     AS30689 FLOW-NET - FLOW
        207.254.128.0/24     AS30689 FLOW-NET - FLOW
        207.254.136.0/21     AS30689 FLOW-NET - FLOW
        208.66.120.0/22      AS32757 
        208.68.180.0/22      AS4323  TWTC - tw telecom holdings, inc.
        208.74.224.0/22      AS174   COGENT Cogent/PSI
        208.75.152.0/21      AS32146 
        208.76.20.0/24       AS31812 
        208.76.21.0/24       AS31812 
        208.77.164.0/24      AS22659 
        208.77.165.0/24      AS22659 
        208.77.166.0/24      AS22659 
        208.77.167.0/24      AS22659 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.84.232.0/24      AS33131 
        208.84.234.0/24      AS33131 
        208.84.237.0/24      AS33131 
        208.84.238.0/24      AS33131 
        208.85.116.0/23      AS25956 ALPHEUS - Alpheus Data Services, L.L.C.
        208.85.212.0/22      AS32618 ADKNO-KC - Adknowledge, Inc.
        208.89.32.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.33.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.34.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.35.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.91.72.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.73.0/24       AS65160 -Private Use AS-
        208.91.76.0/23       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        208.91.164.0/22      AS46099 
        208.92.224.0/22      AS32757 
        208.92.226.0/24      AS32757 
        209.161.96.0/20      AS8039  CCC-ASN-1 - Cinergy Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.193.112.0/20     AS209   ASN-QWEST-US NOVARTIS-DMZ-US
        209.209.51.0/24      AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.
        209.209.64.0/20      AS46851 IPARADIGMS - iParadigms, LLC
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.234.112.0/23     AS32252 
        209.234.114.0/23     AS32252 
        209.234.116.0/24     AS32252 
        209.234.117.0/24     AS32252 
        209.234.118.0/24     AS32252 
        209.234.119.0/24     AS32252 
        209.234.120.0/24     AS32252 
        209.234.121.0/24     AS32252 
        209.234.122.0/24     AS32252 
        212.119.32.0/19      AS12550 
        213.184.64.0/24      AS13071 
        213.184.65.0/24      AS13071 
        213.184.66.0/24      AS13071 
        213.184.67.0/24      AS13071 
        213.184.68.0/24      AS13071 
        213.184.69.0/24      AS13071 
        213.184.70.0/24      AS13071 
        213.184.71.0/24      AS13071 
        213.184.72.0/24      AS13071 
        213.184.73.0/24      AS13071 
        213.184.74.0/24      AS13071 
        213.184.75.0/24      AS13071 
        213.184.76.0/24      AS13071 
        213.184.77.0/24      AS13071 
        213.184.78.0/24      AS13071 
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.14.64.0/20       AS14728 
        216.146.0.0/19       AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.170.96.0/24      AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.101.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.104.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.105.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.234.128.0/22     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.139.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Nov 29 22:00:01 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 29 Nov 2013 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201311292200.rATM01g8082863@wattle.apnic.net>

BGP Update Report
Interval: 21-Nov-13 -to- 28-Nov-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS7545            63977  2.6%      90.4 -- TPG-INTERNET-AP TPG Telecom Limited
 2 - AS8402            39337  1.6%      29.2 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS30693           38382  1.6%      69.8 -- SERVERHUB-PHOENIX - Eonix Corporation
 4 - AS9829            35428  1.4%      45.0 -- BSNL-NIB National Internet Backbone
 5 - AS4538            29814  1.2%      53.3 -- ERX-CERNET-BKB China Education and Research Network Center
 6 - AS7552            28006  1.1%      23.4 -- VIETEL-AS-AP Vietel Corporation
 7 - AS36753           25914  1.1%   12957.0 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc.
 8 - AS13118           23664  1.0%     537.8 -- ASN-YARTELECOM OJSC Rostelecom
 9 - AS29990           22000  0.9%   11000.0 -- ASN-APPNEXUS - AppNexus, Inc
10 - AS17974           21340  0.9%       7.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
11 - AS7029            20967  0.8%       4.8 -- WINDSTREAM - Windstream Communications Inc
12 - AS28573           20284  0.8%       9.2 -- NET Servi?os de Comunica??o S.A.
13 - AS4775            19241  0.8%     305.4 -- GLOBE-TELECOM-AS Globe Telecoms
14 - AS14287           17367  0.7%     321.6 -- TRIAD-TELECOM - Triad Telecom, Inc.
15 - AS37004           15207  0.6%     608.3 -- SUBURBAN-AS
16 - AS27738           15045  0.6%      26.1 -- Ecuadortelecom S.A.
17 - AS31549           14842  0.6%      86.3 -- RASANA Aria Shatel Company Ltd
18 - AS31148           14602  0.6%      14.5 -- FREENET-AS Freenet Ltd.
19 - AS50710           13903  0.6%      61.5 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services
20 - AS37453           13746  0.6%    1963.7 -- VODACOM-CONGO


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS36753           25914  1.1%   12957.0 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc.
 2 - AS29990           22000  0.9%   11000.0 -- ASN-APPNEXUS - AppNexus, Inc
 3 - AS6629             7235  0.3%    7235.0 -- NOAA-AS - NOAA
 4 - AS54465            7003  0.3%    7003.0 -- QPM-AS-1 - QuickPlay Media Inc.
 5 - AS52640            5352  0.2%    5352.0 -- ULTRANET SCM - COMUNICACAO MULTIMIDIA LTDA.
 6 - AS37367            4171  0.2%    4171.0 -- CALLKEY
 7 - AS22592            2421  0.1%    2421.0 -- HBP - HBP, Inc.
 8 - AS21271            4491  0.2%    2245.5 -- SOTELMABGP
 9 - AS62431            2052  0.1%    2052.0 -- NCSC-IE-AS National Cyber Security Centre
10 - AS37453           13746  0.6%    1963.7 -- VODACOM-CONGO
11 - AS55318            5406  0.2%    1802.0 -- ACB-AS-VN Asia Commercial Bank
12 - AS7202             8787  0.3%    1757.4 -- FAMU - Florida A & M University
13 - AS38249            1638  0.1%    1638.0 -- EPS-AS-VN Empower Securities Corporation
14 - AS55321            1598  0.1%    1598.0 -- STSC-AS-VN Saigontourist securities corporation
15 - AS5388             1310  0.1%    1310.0 -- ENERGIS-AS Energis UK
16 - AS52661            3839  0.1%    1279.7 -- Oliveira e Andrade Inform?tica LTDA
17 - AS6775             6245  0.2%    1249.0 -- BACKBONE_EHF_EUROPE Backbone ehf
18 - AS45556            1015  0.0%    1015.0 -- SCANCOM-AS-VN Scancom Vietnam Ltd
19 - AS8011              988  0.0%     988.0 -- AS8011 - CoreComm Internet Services Inc
20 - AS35467            3784  0.1%     946.0 -- DCF-AS DataCenter Fryslan AS


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 109.161.64.0/20   23442  0.9%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 103.243.220.0/22  21986  0.8%   AS29990 -- ASN-APPNEXUS - AppNexus, Inc
 3 - 38.87.227.0/24    13621  0.5%   AS37453 -- VODACOM-CONGO
 4 - 12.68.46.0/24     13476  0.5%   AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc.
 5 - 64.240.174.0/24   12438  0.5%   AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc.
 6 - 120.28.62.0/24     9640  0.4%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
 7 - 222.127.0.0/24     9348  0.3%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
 8 - 192.58.232.0/24    7235  0.3%   AS6629  -- NOAA-AS - NOAA
 9 - 14.202.160.0/22    7229  0.3%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited
10 - 206.152.15.0/24    7003  0.3%   AS54465 -- QPM-AS-1 - QuickPlay Media Inc.
11 - 220.244.72.0/21    6954  0.3%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited
12 - 67.210.190.0/23    6390  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
13 - 79.134.225.0/24    6237  0.2%   AS6775  -- BACKBONE_EHF_EUROPE Backbone ehf
14 - 67.210.188.0/23    5581  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
15 - 220.244.0.0/22     5577  0.2%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited
16 - 179.96.208.0/21    5352  0.2%   AS52640 -- ULTRANET SCM - COMUNICACAO MULTIMIDIA LTDA.
17 - 68.143.17.0/24     5274  0.2%   AS7029  -- WINDSTREAM - Windstream Communications Inc
18 - 110.175.88.0/22    5220  0.2%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited
19 - 115.170.128.0/17   5043  0.2%   AS4847  -- CNIX-AP China Networks Inter-Exchange
20 - 203.219.148.0/22   4507  0.2%   AS7545  -- TPG-INTERNET-AP TPG Telecom Limited

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From bs7799 at gmail.com  Sat Nov 30 00:03:47 2013
From: bs7799 at gmail.com (John Conner)
Date: Sat, 30 Nov 2013 08:03:47 +0800
Subject: bgp traceroute tool?
Message-ID: <CA+PshHRkZ0UPw-xYfGaANzG=jOYv-FevptxqTdmiXzJkL48ytA@mail.gmail.com>

Hi there, is there any tools available under linux which can do bgp
traceroute? (print bgp AS numbers for each traceroute hop ) , i googled and
found nothing.

thanks

John

From mksmith at mac.com  Sat Nov 30 00:11:11 2013
From: mksmith at mac.com (Michael Smith)
Date: Fri, 29 Nov 2013 16:11:11 -0800
Subject: bgp traceroute tool?
In-Reply-To: <CA+PshHRkZ0UPw-xYfGaANzG=jOYv-FevptxqTdmiXzJkL48ytA@mail.gmail.com>
References: <CA+PshHRkZ0UPw-xYfGaANzG=jOYv-FevptxqTdmiXzJkL48ytA@mail.gmail.com>
Message-ID: <6D6CE904-D46C-40DA-9182-CEE46D631782@mac.com>

LFT should do.

http://pwhois.org/lft/

Mike

On Nov 29, 2013, at 4:03 PM, John Conner <bs7799 at gmail.com> wrote:

> Hi there, is there any tools available under linux which can do bgp
> traceroute? (print bgp AS numbers for each traceroute hop ) , i googled and
> found nothing.
> 
> thanks
> 
> John



From bs7799 at gmail.com  Sat Nov 30 00:18:43 2013
From: bs7799 at gmail.com (John Conner)
Date: Sat, 30 Nov 2013 08:18:43 +0800
Subject: bgp traceroute tool?
In-Reply-To: <6D6CE904-D46C-40DA-9182-CEE46D631782@mac.com>
References: <CA+PshHRkZ0UPw-xYfGaANzG=jOYv-FevptxqTdmiXzJkL48ytA@mail.gmail.com>
 <6D6CE904-D46C-40DA-9182-CEE46D631782@mac.com>
Message-ID: <CA+PshHSkUgSaDFh2DnE_zmvPsihk7GtbaestK9xoMy7Ks3tZww@mail.gmail.com>

beyond awesome!


On Sat, Nov 30, 2013 at 8:11 AM, Michael Smith <mksmith at mac.com> wrote:

> LFT should do.
>
> http://pwhois.org/lft/
>
> Mike
>
> On Nov 29, 2013, at 4:03 PM, John Conner <bs7799 at gmail.com> wrote:
>
> > Hi there, is there any tools available under linux which can do bgp
> > traceroute? (print bgp AS numbers for each traceroute hop ) , i googled
> and
> > found nothing.
> >
> > thanks
> >
> > John
>
>

From bs7799 at gmail.com  Sat Nov 30 00:34:00 2013
From: bs7799 at gmail.com (John Conner)
Date: Sat, 30 Nov 2013 08:34:00 +0800
Subject: list all the domains under a specific nameserver?
Message-ID: <CA+PshHQaUcF-NU4=DNQE3Seup=B5BTGqZO3CapF98io44Uzovg@mail.gmail.com>

Just curious, is there any way for someone to pull all the domains being
registered under a given domain register? I have seen websites like
http://www.dailychanges.com which does this type of thing and would like to
know if that is something easily doable, thanks

Regards

John

From rayw at rayw.net  Sat Nov 30 00:41:13 2013
From: rayw at rayw.net (Ray Wong)
Date: Fri, 29 Nov 2013 16:41:13 -0800
Subject: bgp traceroute tool?
In-Reply-To: <CA+PshHSkUgSaDFh2DnE_zmvPsihk7GtbaestK9xoMy7Ks3tZww@mail.gmail.com>
References: <CA+PshHRkZ0UPw-xYfGaANzG=jOYv-FevptxqTdmiXzJkL48ytA@mail.gmail.com>
 <6D6CE904-D46C-40DA-9182-CEE46D631782@mac.com>
 <CA+PshHSkUgSaDFh2DnE_zmvPsihk7GtbaestK9xoMy7Ks3tZww@mail.gmail.com>
Message-ID: <CAM8Fm=5aykEG=x+aADSoPUDWw=6gESQd=fgkNKR=HQqqwrHNaA@mail.gmail.com>

even the basic traceroute util with show AS with the -A flag. I actually
can't remember any of the tracing tools which don't support it, offhand.


On Fri, Nov 29, 2013 at 4:18 PM, John Conner <bs7799 at gmail.com> wrote:

> beyond awesome!
>
>
> On Sat, Nov 30, 2013 at 8:11 AM, Michael Smith <mksmith at mac.com> wrote:
>
> > LFT should do.
> >
> > http://pwhois.org/lft/
> >
> > Mike
> >
> > On Nov 29, 2013, at 4:03 PM, John Conner <bs7799 at gmail.com> wrote:
> >
> > > Hi there, is there any tools available under linux which can do bgp
> > > traceroute? (print bgp AS numbers for each traceroute hop ) , i googled
> > and
> > > found nothing.
> > >
> > > thanks
> > >
> > > John
> >
> >
>

From bs7799 at gmail.com  Sat Nov 30 00:58:18 2013
From: bs7799 at gmail.com (John Conner)
Date: Sat, 30 Nov 2013 08:58:18 +0800
Subject: list all the domains under a specific nameserver?
In-Reply-To: <20131130005547.GA31355@vacation.karoshi.com>
References: <CA+PshHQaUcF-NU4=DNQE3Seup=B5BTGqZO3CapF98io44Uzovg@mail.gmail.com>
 <20131130005547.GA31355@vacation.karoshi.com>
Message-ID: <CA+PshHQZ5+rHjUpm5A2nUBEkQT_i9JmUS2GzUoyLOj42sLD1oA@mail.gmail.com>

The only thing comes to my mind is the passive dns method, which collects
all the dns requests and replies and then a database can be created to
track the changes.

But I am hoping there are other better answers.

Thanks

John


On Sat, Nov 30, 2013 at 8:55 AM, <bmanning at vacation.karoshi.com> wrote:

> there is no good way to pull all the domains hosted by a nameserver unless
> the config file is open to transfer.  equally, there is no good way to pull
> all the domains under a given register. _IF_ zone transfers are enabled,
> you
> might be able to pull all the children under a given zone delegation.
>
> as usual, ymmv
>
> bill
>
>
> On Sat, Nov 30, 2013 at 08:34:00AM +0800, John Conner wrote:
> > Just curious, is there any way for someone to pull all the domains being
> > registered under a given domain register? I have seen websites like
> > http://www.dailychanges.com which does this type of thing and would
> like to
> > know if that is something easily doable, thanks
> >
> > Regards
> >
> > John
>

From mehmet at akcin.net  Sat Nov 30 01:02:24 2013
From: mehmet at akcin.net (Mehmet Akcin)
Date: Fri, 29 Nov 2013 20:02:24 -0500
Subject: bgp traceroute tool?
In-Reply-To: <CAM8Fm=5aykEG=x+aADSoPUDWw=6gESQd=fgkNKR=HQqqwrHNaA@mail.gmail.com>
References: <CA+PshHRkZ0UPw-xYfGaANzG=jOYv-FevptxqTdmiXzJkL48ytA@mail.gmail.com>
 <6D6CE904-D46C-40DA-9182-CEE46D631782@mac.com>
 <CA+PshHSkUgSaDFh2DnE_zmvPsihk7GtbaestK9xoMy7Ks3tZww@mail.gmail.com>
 <CAM8Fm=5aykEG=x+aADSoPUDWw=6gESQd=fgkNKR=HQqqwrHNaA@mail.gmail.com>
Message-ID: <F6564BA2-8607-4412-A7E8-763AABDA6D2F@akcin.net>

Yep.

Tracepath is a nice tool as well

Sent from my iPad

> On Nov 29, 2013, at 7:41 PM, Ray Wong <rayw at rayw.net> wrote:
> 
> even the basic traceroute util with show AS with the -A flag. I actually
> can't remember any of the tracing tools which don't support it, offhand.
> 
> 
>> On Fri, Nov 29, 2013 at 4:18 PM, John Conner <bs7799 at gmail.com> wrote:
>> 
>> beyond awesome!
>> 
>> 
>>> On Sat, Nov 30, 2013 at 8:11 AM, Michael Smith <mksmith at mac.com> wrote:
>>> 
>>> LFT should do.
>>> 
>>> http://pwhois.org/lft/
>>> 
>>> Mike
>>> 
>>>> On Nov 29, 2013, at 4:03 PM, John Conner <bs7799 at gmail.com> wrote:
>>>> 
>>>> Hi there, is there any tools available under linux which can do bgp
>>>> traceroute? (print bgp AS numbers for each traceroute hop ) , i googled
>>> and
>>>> found nothing.
>>>> 
>>>> thanks
>>>> 
>>>> John
>> 


From tony at lavanauts.org  Sat Nov 30 02:20:16 2013
From: tony at lavanauts.org (Antonio Querubin)
Date: Fri, 29 Nov 2013 16:20:16 -1000 (HST)
Subject: bgp traceroute tool?
In-Reply-To: <CAM8Fm=5aykEG=x+aADSoPUDWw=6gESQd=fgkNKR=HQqqwrHNaA@mail.gmail.com>
References: <CA+PshHRkZ0UPw-xYfGaANzG=jOYv-FevptxqTdmiXzJkL48ytA@mail.gmail.com>
 <6D6CE904-D46C-40DA-9182-CEE46D631782@mac.com>
 <CA+PshHSkUgSaDFh2DnE_zmvPsihk7GtbaestK9xoMy7Ks3tZww@mail.gmail.com>
 <CAM8Fm=5aykEG=x+aADSoPUDWw=6gESQd=fgkNKR=HQqqwrHNaA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1311291613220.12672@sol>

On Fri, 29 Nov 2013, Ray Wong wrote:

> even the basic traceroute util with show AS with the -A flag. I actually
> can't remember any of the tracing tools which don't support it, offhand.

Indeed - while lft is not IPv6 enabled.

Antonio Querubin
e-mail:  tony at lavanauts.org
xmpp:  antonioquerubin at gmail.com


From alexwr at gmail.com  Fri Nov 29 06:00:08 2013
From: alexwr at gmail.com (Alex White-Robinson)
Date: Fri, 29 Nov 2013 19:00:08 +1300
Subject: What routers do folks use these days?
In-Reply-To: <529827FC.8040603@forethought.net>
References: <529827FC.8040603@forethought.net>
Message-ID: <CAFhRO6SsJZw9A1jZJnj_b4TqvBoZBJZ7q4iENxQ93xZ7cR-pWQ@mail.gmail.com>

If you're staying Cisco, probably the ASR1000 series, or the ASR9K,
depending on needs.

You probably don't need CSR routers if you're not going to 100Gbps.


On Fri, Nov 29, 2013 at 6:37 PM, Jawaid Desktop <jb at forethought.net> wrote:

> We're a service provider, and we have a network full of Cat6509's. We are
> finding that we are outgrowing them from the standpoint of their ability to
> handle lots of large routing tables. Obviously their switching capability
> is still superb but one of them with 20 peers is starting to groan a bit
> and RAM is going to be an issue soon.
>
> What do people use these days? Our backbone needs in the next 2-3 years
> are going to be sub-100Gbps.
>
>
> Jawaid
>
>
>

From lijun at cs.uoregon.edu  Fri Nov 29 07:20:18 2013
From: lijun at cs.uoregon.edu (Jun Li)
Date: Thu, 28 Nov 2013 23:20:18 -0800
Subject: CFP: 17th IEEE Global Internet Symposium (GI 2014)
References: <C9C4A10D-E5F4-4E27-B6B4-FC38BBA9F4F0@cs.uoregon.edu>
Message-ID: <258F171F-512F-4F58-B62D-361BB0BBB0C2@cs.uoregon.edu>

Call for Papers
17th IEEE Global Internet Symposium (GI 2014)
In conjunction with IEEE INFOCOM 2014
Toronto, Canada
April 27--May 2, 2014
http://www.ieee-infocom.org/2014/Workshops_GI.html


The 17th IEEE Global Internet Symposium will be co-located with IEEE Infocom 2014. All relevant dates, location, and travel information are available from the IEEE Infocom 2014 conference site: http://www.ieee-infocom.org/2014/.

The IEEE Global Internet Symposium aims to provide a top forum for researchers and practitioners to present and discuss advances in Internet-related technologies. The focus of the symposium is on experimental systems and emerging future Internet technologies, and especially on scaling such systems to a global scale.  Research on understanding Internet protocols, services, and applications at global scale is also encouraged. The Program Committee also welcomes position papers (which should be clearly marked as such).

The topics of interest include, but are not limited to the following:
* Routing, switching, and addressing
* Resource management and quality of service
* Software defined networks and network programming
* Content delivery and management
* Energy awareness
* Next-generation network architectures
* Distributed Internet applications including games, VoIP, and video conferencing
* Online social networking
* Peer-to-peer networks
* Novel applications and new paradigms
* Internet measurement, modeling, and visualization
* Large-scale network operation and performance monitoring
* Privacy and/or security issues on the Internet
* Anomaly, intrusion and attack detection
* Interface among networking, communications and information theory
* Applications of network science in communication networks
* Economic aspects of the Internet

Important Dates
* Paper submission: 15th December 2013, 11:59 PM PST.
* Notification of acceptance: 7th February 2014
* Final manuscripts due: TBA
* Symposium: TBA

Submission Instructions

Submitted manuscripts must be formatted in standard IEEE camera-ready format (double-column, 10-pt font) and must be submitted via EDAS as PDF files: http://edas.info/newPaper.php?c=16281. The manuscripts must be no longer than 6 pages. The Program Committee reserves the right to not review papers that violate these formatting rules. Submitted papers must not have been previously published, or be under consideration for publication elsewhere. All submitted papers will be reviewed and judged on originality, technical correctness, relevance, and quality of presentation. All accepted papers must be presented at the symposium by one of the authors.

Steering Committee
* Xiaoming Fu,  Chair (University of Goettingen, DE)
* Marcelo Bagnulo Braun (UC3M, Spain)
* Tilman Wolf (UMass, USA)
* Jorg Ott (Aalto U., Finland)
* Colin Perkins (U. Glasgow, UK)

Program Committee Chairs
* Jun Li (University of Oregon, USA)
* Rade Stanojevic (Telefonica Research, Spain)

Technical Program Committee
* Fred Baker (Cisco)
* Fabian Bustamante (Northwestern University)
* Kevin Butler (University of Oregon)
* Luca Cittadini (Roma Tre University)
* Ruben Cuevas (UC3M)
* Wu-chang Feng (Portland State University)
* Polly Huang (National Taiwan University)
* Olaf Maennel (Loughborough University)
* David Malone (Hamilton Institute)
* Joerg Ott (Aalto University)
* Colin Perkins (University of Glasgow)
* Radia Perlman (Intel)
* Chen Qian (University of Kentucky)
* Peter Reiher (UCLA)
* Reza Rejaie (University of Oregon)
* Michael Sirivianos (Cyprus University of Technology)
* Arun Vishwanath (University of Melbourne)
* Dan Wang (The Hong Kong Polytechnic University)
* Mei Wang (Cisco)
* Lenx Tao Wei (UC Berkeley and Peking University)
* Tilman Wolf (U Mass Amherst)


The Global Internet (GI) Symposium is the flagship event established and organized by the Internet Technical Committee (ITC), a joint committee of the IEEE Communications Society (ComSoc) and the Internet Society (ISOC).


=======================================================================
Jun Li, Ph.D.
Associate Professor, Computer and Information Science, University of Oregon
Director, Network & Security Research Laboratory, University of Oregon
Email: lijun at cs.uoregon.edu
http://www.cs.uoregon.edu/~lijun





From Lee.Clark2 at TELUS.COM  Sat Nov 30 00:18:54 2013
From: Lee.Clark2 at TELUS.COM (Lee Clark)
Date: Fri, 29 Nov 2013 17:18:54 -0700
Subject: bgp traceroute tool?
In-Reply-To: <CA+PshHRkZ0UPw-xYfGaANzG=jOYv-FevptxqTdmiXzJkL48ytA@mail.gmail.com>
References: <CA+PshHRkZ0UPw-xYfGaANzG=jOYv-FevptxqTdmiXzJkL48ytA@mail.gmail.com>
Message-ID: <AFCC8D71FF6F2B4EA21F5C87868BFFC00DBF3278C4@WP40044.corp.ads>

The traceroute variant included with CentOS 6.4 & Mint 13 has an -A flag which does ASN lookups. ntraceroute on FreeBSD supports it as well. I believe the Linux port is traceroute-nanog.

Lee

[user at box ~]# traceroute -V
Modern traceroute for Linux, version 2.0.14, Nov 11 2010
Copyright (c) 2008  Dmitry Butskoy,   License: GPL v2 or any later

[user at box ~]# traceroute -A www.google.ca
traceroute to www.google.ca (74.125.226.127), 30 hops max, 60 byte packets
<snip>
 6  72.14.197.33 (72.14.197.33) [AS15169]  73.927 ms  69.254 ms  69.305 ms
 7  209.85.254.130 (209.85.254.130) [AS15169]  69.436 ms 209.85.254.122 (209.85.254.122) [AS15169]  79.554 ms  64.269 ms
 8  72.14.237.130 (72.14.237.130) [AS15169]  64.979 ms  65.975 ms 209.85.254.238 (209.85.254.238) [AS15169]  66.700 ms
 9  216.239.46.161 (216.239.46.161) [AS15169]  71.293 ms  72.251 ms  73.521 ms
10  209.85.250.207 (209.85.250.207) [AS15169]  74.454 ms  74.920 ms  75.889 ms
11  yyz08s13-in-f31.1e100.net (74.125.226.127) [AS15169]  76.628 ms  77.105 ms  70.928 ms


-----Original Message-----
From: John Conner [mailto:bs7799 at gmail.com] 
Sent: Friday, November 29, 2013 5:04 PM
To: nanog at nanog.org
Subject: bgp traceroute tool?

Hi there, is there any tools available under linux which can do bgp traceroute? (print bgp AS numbers for each traceroute hop ) , i googled and found nothing.

thanks

John


From mysidia at gmail.com  Sat Nov 30 05:09:40 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 29 Nov 2013 23:09:40 -0600
Subject: list all the domains under a specific nameserver?
In-Reply-To: <CA+PshHQaUcF-NU4=DNQE3Seup=B5BTGqZO3CapF98io44Uzovg@mail.gmail.com>
References: <CA+PshHQaUcF-NU4=DNQE3Seup=B5BTGqZO3CapF98io44Uzovg@mail.gmail.com>
Message-ID: <CAAAwwbXAyp7NgfFfCymzfM4eGiqqz=93K4tkvAt2JWc=bKR-FQ@mail.gmail.com>

On Fri, Nov 29, 2013 at 6:34 PM, John Conner <bs7799 at gmail.com> wrote:

> Just curious, is there any way for someone to pull all the domains being
> registered under a given domain register? I have seen websites like
> http://www.dailychanges.com which does this type of thing and would like
> to
> know if that is something easily doable, thanks
>

Commercial services such as domaintools name server monitor come to mind.

Otherwise;  the person to ask the question needs  to have  the "zone file
information".  nameserver list data feeds from the  TLD registry operators,
 of every TLD they want to gather nameserver information for.

For certain TLDs;  this may be available -- for example,  Verisign  .com
and .net  "TLD Zone file access program".

These data feeds are likely at  substantially high application, approval,
and paperwork requirements for acceptance, for each TLD, and substantially
high cost for each TLD   -----  therefore,   not   generally an option,
so  dailychanges or other commercial services  will be your best option..


There is certainly no WHOIS or DNS query that will provide you this;
which is essentially a search for database entries based on the  IP
addresses that  NS record right-hand side values  resolve to.






> Regards
> John
>
--
-JH

From mureninc at gmail.com  Sat Nov 30 07:30:39 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Fri, 29 Nov 2013 23:30:39 -0800
Subject: Europe-to-US congestion and packet loss on he.net network, and their
 NOC@ won't even respond
Message-ID: <5299941F.7050507@gmail.com>

Dear NANOG@,

I'm not exactly sure how else I can get he.net's attention, because I've 
been experiencing congestion issues between my dedi and Indiana for a 
couple of months now, all due to he.net's poor transit, as it turns out. 
  The issue was complicated by the fact that the routes are asymmetric, 
and it appears as if the traffic loss is going on somewhere where there 
is none at all.

I will just provide the data, and people can make their own conclusions, 
any insights are welcome.

During all of this, since some late September 2013, all 4 networks 
involved have been contacted -- hetzner, init7, he.net, indiana; all 
except for he.net have responded and did troubleshooting.

After pressing the lack of any kind of response from he.net, all they 
did was ask for a customer number, and that was back in September.  I 
have not heard from their NOC@ ever since, with requests left 
unanswered, sans the "we have received your request" autoreply.

Interestingly enough, only some of their Europe-to-US routes are 
blatantly congested and have very obvious packet loss (often making ssh 
unusable), whereas others appear to be doing just fine (at least, not 
losing packets and not experiencing jitter, and the increased latency). 
  E.g. IPv6 routes don't appear affected, for example.  IPv4 addresses 
in North America that are announced directly from AS6939 (e.g. Linode in 
Fremont) don't appear affected, either.  But the multi-homed indiana.edu 
and wiscnet.net are affected.  The single-homed ntp1.yycix.ca is 
affected, too.  Probably other customers are affected as well.

Where's the end to this?

Or is the ongoing 0.5+% traffic loss, and the 140+ms avg latency on a 
114ms route, with random spikes and jitter in certain hours of the day 
(generally around midnight ET), every day for several weeks or even 
months, an acceptable practice?



 From hetzner.de through he.net:


Cns# date ; mtr --report{,-wide,-cycles=600} --interval 0.1 --order "SRL 
BGAWV" -4 ????c????????.indiana.edu ; date
Fri Nov 29 21:06:17 PST 2013
HOST: Cns???????                                   Snt   Rcv Loss% 
Best Gmean   Avg  Wrst StDev
   1.|-- static.??.???.4.46.clients.your-server.de    600   600  0.0% 
  0.5   1.0   1.3   4.9   1.1
   2.|-- hos-tr1.juniper1.rz13.hetzner.de             600   600  0.0% 
  0.1   0.2   1.9  66.0   7.6
   3.|-- core21.hetzner.de                            600   600  0.0% 
  0.2   0.2   0.2   5.8   0.4
   4.|-- core22.hetzner.de                            600   600  0.0% 
  0.2   0.2   0.2  19.4   1.2
   5.|-- core1.hetzner.de                             600   600  0.0% 
  4.8   4.8   4.8  13.2   0.7
   6.|-- juniper1.ffm.hetzner.de                      600   600  0.0% 
  4.8   4.8   4.8  27.4   1.4
   7.|-- 30gigabitethernet1-3.core1.ams1.he.net       600   600  0.0% 
11.2  14.0  14.6  48.7   4.5
   8.|-- 10gigabitethernet1-4.core1.lon1.he.net       600   600  0.0% 
18.2  19.6  19.9  53.9   4.1
   9.|-- 10gigabitethernet10-4.core1.nyc4.he.net      600   599  0.2% 
87.0 116.1 116.7 145.7  12.4
  10.|-- 100gigabitethernet7-2.core1.chi1.he.net      600   597  0.5% 
106.6 135.4 136.1 192.0  13.3
  11.|-- ???                                          600     0 100.0 
  0.0   0.0   0.0   0.0   0.0
  12.|-- et-11-0-0.945.rtr.ictc.indiana.gigapop.net   600   594  1.0% 
113.3 139.3 139.7 166.1  11.4
  13.|-- xe-0-3-0.11.br2.ictc.net.uits.iu.edu         600   596  0.7% 
113.2 139.8 140.3 177.3  12.0
  14.|-- ae-0.0.br2.bldc.net.uits.iu.edu              600   595  0.8% 
114.2 140.1 140.6 183.2  11.8
  15.|-- ae-10.0.cr3.bldc.net.uits.iu.edu             600   597  0.5% 
114.3 140.3 140.8 165.0  11.5
  16.|-- ????c????????.indiana.edu                    600   597  0.5% 
114.7 140.7 141.1 161.6  11.4
Fri Nov 29 21:08:52 PST 2013


Cns# unbuffer hping --icmp-ts ????c????????.indiana.edu | \
perl -ne 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \
if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, 
$3);} \
if (/tsrtt=(\d+)/) { \
print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, "\n"; }'
0       143.5   144 = 87 + 57
1       125.5   126 = 69 + 57
2       143.6   144 = 87 + 57
3       157.9   158 = 102 + 56
4       122.0   122 = 66 + 56
5       141.6   142 = 85 + 57
6       132.2   133 = 76 + 57
7       146.2   146 = 89 + 57
8       145.1   145 = 88 + 57
9       119.9   119 = 63 + 56
10      132.7   132 = 75 + 57
11      140.1   140 = 83 + 57
12      151.0   151 = 94 + 57
13      152.6   152 = 96 + 56
14      129.1   129 = 72 + 57
15      128.5   128 = 71 + 57
^C



Single-homed at he.net:


Cns# date ; mtr --report{,-cycles=600} --interval 0.1 --order "SRL 
BGAWV" -4 ntp1.yycix.ca ; date
Fri Nov 29 21:16:14 PST 2013
HOST: Cns???????                    Snt   Rcv Loss%   Best Gmean   Avg 
Wrst StDev
   1.|-- static.??.???.4.46.client   600   600  0.0%    0.5   1.0   1.3 
  10.2   1.2
   2.|-- hos-tr4.juniper2.rz13.het   600   600  0.0%    0.1   0.2   2.0 
153.9   9.8
   3.|-- core22.hetzner.de           600   600  0.0%    0.2   0.2   0.2 
  10.6   0.6
   4.|-- core1.hetzner.de            600   600  0.0%    4.8   4.8   4.8 
  16.4   0.9
   5.|-- juniper1.ffm.hetzner.de     600   600  0.0%    4.8   4.8   4.8 
  36.4   1.5
   6.|-- 30gigabitethernet1-3.core   600   600  0.0%   11.2  13.5  14.0 
  36.6   4.3
   7.|-- 10gigabitethernet1-4.core   600   600  0.0%   18.0  21.5  21.8 
  43.1   4.0
   8.|-- 10gigabitethernet10-4.cor   600   597  0.5%   93.2 128.0 128.3 
157.5   8.9
   9.|-- 10gigabitethernet1-2.core   600   596  0.7%  103.1 139.4 139.6 
157.5   8.2
  10.|-- 10gigabitethernet3-1.core   600   597  0.5%  128.2 164.9 165.1 
181.9   8.2
  11.|-- 10gigabitethernet1-1.core   600   593  1.2%  138.7 175.9 176.1 
192.6   7.8
  12.|-- sebo-systems-inc.gigabite   600   597  0.5%  139.0 176.4 176.5 
187.5   6.9
  13.|-- ???                         600     0 100.0    0.0   0.0   0.0 
   0.0   0.0
  14.|-- ntp1.yycix.ca               600   597  0.5%  141.0 176.9 177.0 
186.9   6.9
Fri Nov 29 21:18:32 PST 2013
Cns# traceroute -A ntp1.yycix.ca
traceroute to ntp1.yycix.ca (192.75.191.6), 64 hops max, 40 byte packets
  1  static.??.???.4.46.clients.your-server.de (46.4.???.??) [AS24940] 
0.664 ms  0.648 ms  0.453 ms
  2  hos-tr1.juniper1.rz13.hetzner.de (213.239.224.1) [AS24940]  23.985 
ms hos-tr2.juniper1.rz13.hetzner.de (213.239.224.33) [AS24940]  0.234 ms 
hos-tr3.juniper2.rz13.hetzner.de (213.239.224.65) [AS24940]  0.238 ms
  3  core22.hetzner.de (213.239.245.121) [AS24940]  0.238 ms 
core21.hetzner.de (213.239.245.81) [AS24940]  0.234 ms  0.236 ms
  4  core1.hetzner.de (213.239.245.177) [AS24940]  4.811 ms  4.809 ms 
core22.hetzner.de (213.239.245.162) [AS24940]  0.248 ms
  5  core1.hetzner.de (213.239.245.177) [AS24940]  4.831 ms 
juniper1.ffm.hetzner.de (213.239.245.5) [AS24940]  4.842 ms  4.826 ms
  6  juniper1.ffm.hetzner.de (213.239.245.5) [AS24940]  4.857 ms  4.864 
ms 30gigabitethernet1-3.core1.ams1.he.net (195.69.145.150) [AS1200] 
11.233 ms
  7  10gigabitethernet1-4.core1.lon1.he.net (72.52.92.81) [AS6939, 
AS6939]  19.869 ms 30gigabitethernet1-3.core1.ams1.he.net 
(195.69.145.150) [AS1200]  18.420 ms  11.255 ms
  8  10gigabitethernet10-4.core1.nyc4.he.net (72.52.92.241) [AS6939, 
AS6939]  115.845 ms  101.875 ms 10gigabitethernet1-4.core1.lon1.he.net 
(72.52.92.81) [AS6939, AS6939]  17.249 ms
  9  10gigabitethernet10-4.core1.nyc4.he.net (72.52.92.241) [AS6939, 
AS6939]  138.302 ms 10gigabitethernet1-2.core1.tor1.he.net 
(184.105.222.18) [AS6939]  120.449 ms  139.730 ms
10  10gigabitethernet1-2.core1.tor1.he.net (184.105.222.18) [AS6939] 
134.755 ms  104.661 ms 10gigabitethernet3-1.core1.ywg1.he.net 
(184.105.223.221) [AS6939]  167.282 ms
11  10gigabitethernet1-1.core1.yyc1.he.net (184.105.223.214) [AS6939] 
139.310 ms 10gigabitethernet3-1.core1.ywg1.he.net (184.105.223.221) 
[AS6939]  155.983 ms  155.910 ms
12  sebo-systems-inc.gigabitethernet2-23.core1.yyc1.he.net 
(216.218.214.250) [AS6939]  138.703 ms  178.530 ms 
10gigabitethernet1-1.core1.yyc1.he.net (184.105.223.214) [AS6939] 
172.423 ms
13  sebo-systems-inc.gigabitethernet2-23.core1.yyc1.he.net 
(216.218.214.250) [AS6939]  158 ms * *
14  * * ntp1.yycix.ca (192.75.191.6) [AS53339]  181.433 ms
Cns#
Cns#
Cns#
Cns# unbuffer hping --icmp-ts ntp1.yycix.ca | perl -ne \
'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \
if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, 
$3);} \
if (/tsrtt=(\d+)/) { \
print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, "\n"; }'
0       165.0   165 = 95 + 70
1       156.2   156 = 86 + 70
2       178.9   179 = 109 + 70
3       181.0   181 = 111 + 70
4       178.3   179 = 108 + 71
5       163.8   164 = 94 + 70
6       175.7   176 = 106 + 70
7       173.9   174 = 104 + 70
8       172.6   173 = 103 + 70
9       163.5   164 = 94 + 70
10      181.8   182 = 112 + 70
11      161.9   162 = 92 + 70
12      183.1   184 = 113 + 71
13      174.5   174 = 104 + 70
14      181.8   181 = 111 + 70
15      181.7   181 = 111 + 70
^C
Cns#




 From indiana.edu to hetzner.de; notice that the mtr by itself gives a 
false impression of a traffic loss at init7, whereas in reality, it's 
the reverse path through he.net that's causing the loss, as hping confirms:


m: {5134} date ; sudo mtr --report{,-cycles=600} --interval 0.1 --order 
"SRL BGAWV" -4 ?????? ; date
Sat Nov 30 00:36:27 EST 2013
HOST: ????c????????.indiana.edu     Snt   Rcv Loss%   Best Gmean   Avg 
Wrst StDev
   1.|-- 129.79.???.?                600   600  0.0%    0.4   0.7   0.9 
  24.7   1.5
   2.|-- ae-13.0.br2.bldc.net.uits   600   600  0.0%    0.5   0.7   0.9 
  22.6   1.8
   3.|-- ae-0.0.br2.ictc.net.uits.   600   600  0.0%    1.4   1.7   1.8 
  20.2   1.6
   4.|-- xe-0-1-0.11.rtr.ictc.indi   600   600  0.0%    1.4   2.1   3.8 
  66.5   8.1
   5.|-- 64.57.21.13                 600   600  0.0%    6.0   7.2   8.4 
  72.9   8.0
   6.|-- xe-2-2-0.0.ny0.tr-cps.int   600   600  0.0%   32.3  33.9  34.4 
  81.0   6.9
   7.|-- paix-nyc.init7.net          600   600  0.0%   32.5  35.3  35.5 
  44.7   3.8
   8.|-- r1lon1.core.init7.net       600   599  0.2%  100.1 104.7 104.9 
146.5   7.5
   9.|-- r1nue1.core.init7.net       600   599  0.2%  114.6 115.7 115.7 
125.4   2.2
  10.|-- gw-hetzner.init7.net        600   594  1.0%  112.4 141.3 142.4 
241.9  18.2
  11.|-- core12.hetzner.de           600   468 22.0%  112.2 142.7 144.0 
203.4  20.3
  12.|-- core21.hetzner.de           600   202 66.3%  114.4 143.7 145.0 
204.1  20.1
  13.|-- juniper1.rz13.hetzner.de    600   594  1.0%  114.7 141.4 142.1 
212.2  14.3
  14.|-- hos-tr2.ex3k11.rz13.hetzn   600   599  0.2%  113.8 123.9 125.5 
218.2  21.8
  15.|-- static.88-198-??-??.clien   599   592  1.2%  114.6 137.2 137.9 
167.6  13.2
0.244u 1.766s 1:05.52 3.0%      0+0k 0+1io 0pf+0w
Sat Nov 30 00:37:32 EST 2013

m: {5137} sudo script -q /dev/null hping3 --icmp-ts 88.198.??.?? | perl 
-ne 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \
if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, 
$3);} \
if (/tsrtt=(\d+)/) { \
print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, 
"\r\n"; }'
0       131.3   131 = 57 + 74
1       122.4   122 = 56 + 66
2       122.6   123 = 56 + 67
3       127.6   128 = 57 + 71
4       146.5   147 = 57 + 90
5       139.8   140 = 56 + 84
6       131.0   131 = 57 + 74
7       134.6   135 = 57 + 78
8       137.7   138 = 57 + 81
9       148.1   148 = 57 + 91
10      141.2   142 = 57 + 85
11      146.4   146 = 56 + 90
12      153.6   154 = 57 + 97
13      149.4   150 = 57 + 93
14      120.2   121 = 57 + 64
15      120.6   120 = 56 + 64
16      130.7   131 = 57 + 74
17      126.4   126 = 56 + 70
18      117.9   118 = 57 + 61
19      116.9   117 = 57 + 60
20      119.8   119 = 56 + 63
21      132.0   132 = 56 + 76
22      134.2   134 = 56 + 78
23      138.8   139 = 57 + 82



Note the ICMP timestamp data from hping above.  From this ICMP 
timestamping data, it is obvious that the congestion is only happening 
on one path -- the one over he.net, and init7 is in the clear.

Any further insights are welcome.  But finding out about the ICMP 
timestamp feature has so far been the most useful thing in 
troubleshooting this issue; I'm surprised it's a rather unknown method 
to get to the bottom of these problems.

However, even after finding out about the cause and the party 
responsible, the problem is yet to be exhausted.  Any help appreciated.

Best regards,
Constantine.


From jaap at NLnetLabs.nl  Sat Nov 30 09:21:39 2013
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Sat, 30 Nov 2013 10:21:39 +0100
Subject: list all the domains under a specific nameserver?
In-Reply-To: <CAAAwwbXAyp7NgfFfCymzfM4eGiqqz=93K4tkvAt2JWc=bKR-FQ@mail.gmail.com>
References: <CA+PshHQaUcF-NU4=DNQE3Seup=B5BTGqZO3CapF98io44Uzovg@mail.gmail.com>
 <CAAAwwbXAyp7NgfFfCymzfM4eGiqqz=93K4tkvAt2JWc=bKR-FQ@mail.gmail.com>
Message-ID: <201311300921.rAU9LdZ5032017@bela.nlnetlabs.nl>


    On Fri, Nov 29, 2013 at 6:34 PM, John Conner <bs7799 at gmail.com> wrote:
    
    > Just curious, is there any way for someone to pull all the domains being
    > registered under a given domain register? I have seen websites like
    > http://www.dailychanges.com which does this type of thing and would like
    > to
    > know if that is something easily doable, thanks
    >
    
    Commercial services such as domaintools name server monitor come to mind.
    
Apart from these, also ICANN's Cetralized Zone Data Service:
<https://czds.icann.org/en/help>

	jaap

    Otherwise;  the person to ask the question needs  to have  the "zone file
    information".  nameserver list data feeds from the  TLD registry operators,
     of every TLD they want to gather nameserver information for.
    
    For certain TLDs;  this may be available -- for example,  Verisign  .com
    and .net  "TLD Zone file access program".
    
    These data feeds are likely at  substantially high application, approval,
    and paperwork requirements for acceptance, for each TLD, and substantially
    high cost for each TLD   -----  therefore,   not   generally an option,
    so  dailychanges or other commercial services  will be your best option..
    
    
    There is certainly no WHOIS or DNS query that will provide you this;
    which is essentially a search for database entries based on the  IP
    addresses that  NS record right-hand side values  resolve to.
    
    
    
    
    
    
    > Regards
    > John
    >
    --
    -JH


From kuenzler at init7.net  Sat Nov 30 15:10:13 2013
From: kuenzler at init7.net (Fredy Kuenzler)
Date: Sat, 30 Nov 2013 16:10:13 +0100
Subject: Europe-to-US congestion and packet loss on he.net network,
 and their NOC@ won't even respond
In-Reply-To: <5299941F.7050507@gmail.com>
References: <5299941F.7050507@gmail.com>
Message-ID: <9DD5EFCC-3D71-49DB-A486-8AB3CF9C2B51@init7.net>

Constantine,

Please mail me offlist if Init7 can be of any help to resolve the case.

--
Fredy Kuenzler
Init7 (Switzerland) Ltd.
St.-Georgen-Strasse 70
CH-8400 Winterthur
Switzerland

http://www.init7.net/


> Am 30.11.2013 um 08:30 schrieb "Constantine A. Murenin" <mureninc at gmail.com>:
> 
> Dear NANOG@,
> 
> I'm not exactly sure how else I can get he.net's attention, because I've been experiencing congestion issues between my dedi and Indiana for a couple of months now, all due to he.net's poor transit, as it turns out.  The issue was complicated by the fact that the routes are asymmetric, and it appears as if the traffic loss is going on somewhere where there is none at all.
> 
> I will just provide the data, and people can make their own conclusions, any insights are welcome.
> 
> During all of this, since some late September 2013, all 4 networks involved have been contacted -- hetzner, init7, he.net, indiana; all except for he.net have responded and did troubleshooting.
> 
> After pressing the lack of any kind of response from he.net, all they did was ask for a customer number, and that was back in September.  I have not heard from their NOC@ ever since, with requests left unanswered, sans the "we have received your request" autoreply.
> 
> Interestingly enough, only some of their Europe-to-US routes are blatantly congested and have very obvious packet loss (often making ssh unusable), whereas others appear to be doing just fine (at least, not losing packets and not experiencing jitter, and the increased latency).  E.g. IPv6 routes don't appear affected, for example.  IPv4 addresses in North America that are announced directly from AS6939 (e.g. Linode in Fremont) don't appear affected, either.  But the multi-homed indiana.edu and wiscnet.net are affected.  The single-homed ntp1.yycix.ca is affected, too.  Probably other customers are affected as well.
> 
> Where's the end to this?
> 
> Or is the ongoing 0.5+% traffic loss, and the 140+ms avg latency on a 114ms route, with random spikes and jitter in certain hours of the day (generally around midnight ET), every day for several weeks or even months, an acceptable practice?
> 
> 
> 
> From hetzner.de through he.net:
> 
> 
> Cns# date ; mtr --report{,-wide,-cycles=600} --interval 0.1 --order "SRL BGAWV" -4 ????c????????.indiana.edu ; date
> Fri Nov 29 21:06:17 PST 2013
> HOST: Cns???????                                   Snt   Rcv Loss% Best Gmean   Avg  Wrst StDev
>  1.|-- static.??.???.4.46.clients.your-server.de    600   600  0.0%  0.5   1.0   1.3   4.9   1.1
>  2.|-- hos-tr1.juniper1.rz13.hetzner.de             600   600  0.0%  0.1   0.2   1.9  66.0   7.6
>  3.|-- core21.hetzner.de                            600   600  0.0%  0.2   0.2   0.2   5.8   0.4
>  4.|-- core22.hetzner.de                            600   600  0.0%  0.2   0.2   0.2  19.4   1.2
>  5.|-- core1.hetzner.de                             600   600  0.0%  4.8   4.8   4.8  13.2   0.7
>  6.|-- juniper1.ffm.hetzner.de                      600   600  0.0%  4.8   4.8   4.8  27.4   1.4
>  7.|-- 30gigabitethernet1-3.core1.ams1.he.net       600   600  0.0% 11.2  14.0  14.6  48.7   4.5
>  8.|-- 10gigabitethernet1-4.core1.lon1.he.net       600   600  0.0% 18.2  19.6  19.9  53.9   4.1
>  9.|-- 10gigabitethernet10-4.core1.nyc4.he.net      600   599  0.2% 87.0 116.1 116.7 145.7  12.4
> 10.|-- 100gigabitethernet7-2.core1.chi1.he.net      600   597  0.5% 106.6 135.4 136.1 192.0  13.3
> 11.|-- ???                                          600     0 100.0  0.0   0.0   0.0   0.0   0.0
> 12.|-- et-11-0-0.945.rtr.ictc.indiana.gigapop.net   600   594  1.0% 113.3 139.3 139.7 166.1  11.4
> 13.|-- xe-0-3-0.11.br2.ictc.net.uits.iu.edu         600   596  0.7% 113.2 139.8 140.3 177.3  12.0
> 14.|-- ae-0.0.br2.bldc.net.uits.iu.edu              600   595  0.8% 114.2 140.1 140.6 183.2  11.8
> 15.|-- ae-10.0.cr3.bldc.net.uits.iu.edu             600   597  0.5% 114.3 140.3 140.8 165.0  11.5
> 16.|-- ????c????????.indiana.edu                    600   597  0.5% 114.7 140.7 141.1 161.6  11.4
> Fri Nov 29 21:08:52 PST 2013
> 
> 
> Cns# unbuffer hping --icmp-ts ????c????????.indiana.edu | \
> perl -ne 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \
> if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, $3);} \
> if (/tsrtt=(\d+)/) { \
> print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, "\n"; }'
> 0       143.5   144 = 87 + 57
> 1       125.5   126 = 69 + 57
> 2       143.6   144 = 87 + 57
> 3       157.9   158 = 102 + 56
> 4       122.0   122 = 66 + 56
> 5       141.6   142 = 85 + 57
> 6       132.2   133 = 76 + 57
> 7       146.2   146 = 89 + 57
> 8       145.1   145 = 88 + 57
> 9       119.9   119 = 63 + 56
> 10      132.7   132 = 75 + 57
> 11      140.1   140 = 83 + 57
> 12      151.0   151 = 94 + 57
> 13      152.6   152 = 96 + 56
> 14      129.1   129 = 72 + 57
> 15      128.5   128 = 71 + 57
> ^C
> 
> 
> 
> Single-homed at he.net:
> 
> 
> Cns# date ; mtr --report{,-cycles=600} --interval 0.1 --order "SRL BGAWV" -4 ntp1.yycix.ca ; date
> Fri Nov 29 21:16:14 PST 2013
> HOST: Cns???????                    Snt   Rcv Loss%   Best Gmean   Avg Wrst StDev
>  1.|-- static.??.???.4.46.client   600   600  0.0%    0.5   1.0   1.3  10.2   1.2
>  2.|-- hos-tr4.juniper2.rz13.het   600   600  0.0%    0.1   0.2   2.0 153.9   9.8
>  3.|-- core22.hetzner.de           600   600  0.0%    0.2   0.2   0.2  10.6   0.6
>  4.|-- core1.hetzner.de            600   600  0.0%    4.8   4.8   4.8  16.4   0.9
>  5.|-- juniper1.ffm.hetzner.de     600   600  0.0%    4.8   4.8   4.8  36.4   1.5
>  6.|-- 30gigabitethernet1-3.core   600   600  0.0%   11.2  13.5  14.0  36.6   4.3
>  7.|-- 10gigabitethernet1-4.core   600   600  0.0%   18.0  21.5  21.8  43.1   4.0
>  8.|-- 10gigabitethernet10-4.cor   600   597  0.5%   93.2 128.0 128.3 157.5   8.9
>  9.|-- 10gigabitethernet1-2.core   600   596  0.7%  103.1 139.4 139.6 157.5   8.2
> 10.|-- 10gigabitethernet3-1.core   600   597  0.5%  128.2 164.9 165.1 181.9   8.2
> 11.|-- 10gigabitethernet1-1.core   600   593  1.2%  138.7 175.9 176.1 192.6   7.8
> 12.|-- sebo-systems-inc.gigabite   600   597  0.5%  139.0 176.4 176.5 187.5   6.9
> 13.|-- ???                         600     0 100.0    0.0   0.0   0.0   0.0   0.0
> 14.|-- ntp1.yycix.ca               600   597  0.5%  141.0 176.9 177.0 186.9   6.9
> Fri Nov 29 21:18:32 PST 2013
> Cns# traceroute -A ntp1.yycix.ca
> traceroute to ntp1.yycix.ca (192.75.191.6), 64 hops max, 40 byte packets
> 1  static.??.???.4.46.clients.your-server.de (46.4.???.??) [AS24940] 0.664 ms  0.648 ms  0.453 ms
> 2  hos-tr1.juniper1.rz13.hetzner.de (213.239.224.1) [AS24940]  23.985 ms hos-tr2.juniper1.rz13.hetzner.de (213.239.224.33) [AS24940]  0.234 ms hos-tr3.juniper2.rz13.hetzner.de (213.239.224.65) [AS24940]  0.238 ms
> 3  core22.hetzner.de (213.239.245.121) [AS24940]  0.238 ms core21.hetzner.de (213.239.245.81) [AS24940]  0.234 ms  0.236 ms
> 4  core1.hetzner.de (213.239.245.177) [AS24940]  4.811 ms  4.809 ms core22.hetzner.de (213.239.245.162) [AS24940]  0.248 ms
> 5  core1.hetzner.de (213.239.245.177) [AS24940]  4.831 ms juniper1.ffm.hetzner.de (213.239.245.5) [AS24940]  4.842 ms  4.826 ms
> 6  juniper1.ffm.hetzner.de (213.239.245.5) [AS24940]  4.857 ms  4.864 ms 30gigabitethernet1-3.core1.ams1.he.net (195.69.145.150) [AS1200] 11.233 ms
> 7  10gigabitethernet1-4.core1.lon1.he.net (72.52.92.81) [AS6939, AS6939]  19.869 ms 30gigabitethernet1-3.core1.ams1.he.net (195.69.145.150) [AS1200]  18.420 ms  11.255 ms
> 8  10gigabitethernet10-4.core1.nyc4.he.net (72.52.92.241) [AS6939, AS6939]  115.845 ms  101.875 ms 10gigabitethernet1-4.core1.lon1.he.net (72.52.92.81) [AS6939, AS6939]  17.249 ms
> 9  10gigabitethernet10-4.core1.nyc4.he.net (72.52.92.241) [AS6939, AS6939]  138.302 ms 10gigabitethernet1-2.core1.tor1.he.net (184.105.222.18) [AS6939]  120.449 ms  139.730 ms
> 10  10gigabitethernet1-2.core1.tor1.he.net (184.105.222.18) [AS6939] 134.755 ms  104.661 ms 10gigabitethernet3-1.core1.ywg1.he.net (184.105.223.221) [AS6939]  167.282 ms
> 11  10gigabitethernet1-1.core1.yyc1.he.net (184.105.223.214) [AS6939] 139.310 ms 10gigabitethernet3-1.core1.ywg1.he.net (184.105.223.221) [AS6939]  155.983 ms  155.910 ms
> 12  sebo-systems-inc.gigabitethernet2-23.core1.yyc1.he.net (216.218.214.250) [AS6939]  138.703 ms  178.530 ms 10gigabitethernet1-1.core1.yyc1.he.net (184.105.223.214) [AS6939] 172.423 ms
> 13  sebo-systems-inc.gigabitethernet2-23.core1.yyc1.he.net (216.218.214.250) [AS6939]  158 ms * *
> 14  * * ntp1.yycix.ca (192.75.191.6) [AS53339]  181.433 ms
> Cns#
> Cns#
> Cns#
> Cns# unbuffer hping --icmp-ts ntp1.yycix.ca | perl -ne \
> 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \
> if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, $3);} \
> if (/tsrtt=(\d+)/) { \
> print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, "\n"; }'
> 0       165.0   165 = 95 + 70
> 1       156.2   156 = 86 + 70
> 2       178.9   179 = 109 + 70
> 3       181.0   181 = 111 + 70
> 4       178.3   179 = 108 + 71
> 5       163.8   164 = 94 + 70
> 6       175.7   176 = 106 + 70
> 7       173.9   174 = 104 + 70
> 8       172.6   173 = 103 + 70
> 9       163.5   164 = 94 + 70
> 10      181.8   182 = 112 + 70
> 11      161.9   162 = 92 + 70
> 12      183.1   184 = 113 + 71
> 13      174.5   174 = 104 + 70
> 14      181.8   181 = 111 + 70
> 15      181.7   181 = 111 + 70
> ^C
> Cns#
> 
> 
> 
> 
> From indiana.edu to hetzner.de; notice that the mtr by itself gives a false impression of a traffic loss at init7, whereas in reality, it's the reverse path through he.net that's causing the loss, as hping confirms:
> 
> 
> m: {5134} date ; sudo mtr --report{,-cycles=600} --interval 0.1 --order "SRL BGAWV" -4 ?????? ; date
> Sat Nov 30 00:36:27 EST 2013
> HOST: ????c????????.indiana.edu     Snt   Rcv Loss%   Best Gmean   Avg Wrst StDev
>  1.|-- 129.79.???.?                600   600  0.0%    0.4   0.7   0.9  24.7   1.5
>  2.|-- ae-13.0.br2.bldc.net.uits   600   600  0.0%    0.5   0.7   0.9  22.6   1.8
>  3.|-- ae-0.0.br2.ictc.net.uits.   600   600  0.0%    1.4   1.7   1.8  20.2   1.6
>  4.|-- xe-0-1-0.11.rtr.ictc.indi   600   600  0.0%    1.4   2.1   3.8  66.5   8.1
>  5.|-- 64.57.21.13                 600   600  0.0%    6.0   7.2   8.4  72.9   8.0
>  6.|-- xe-2-2-0.0.ny0.tr-cps.int   600   600  0.0%   32.3  33.9  34.4  81.0   6.9
>  7.|-- paix-nyc.init7.net          600   600  0.0%   32.5  35.3  35.5  44.7   3.8
>  8.|-- r1lon1.core.init7.net       600   599  0.2%  100.1 104.7 104.9 146.5   7.5
>  9.|-- r1nue1.core.init7.net       600   599  0.2%  114.6 115.7 115.7 125.4   2.2
> 10.|-- gw-hetzner.init7.net        600   594  1.0%  112.4 141.3 142.4 241.9  18.2
> 11.|-- core12.hetzner.de           600   468 22.0%  112.2 142.7 144.0 203.4  20.3
> 12.|-- core21.hetzner.de           600   202 66.3%  114.4 143.7 145.0 204.1  20.1
> 13.|-- juniper1.rz13.hetzner.de    600   594  1.0%  114.7 141.4 142.1 212.2  14.3
> 14.|-- hos-tr2.ex3k11.rz13.hetzn   600   599  0.2%  113.8 123.9 125.5 218.2  21.8
> 15.|-- static.88-198-??-??.clien   599   592  1.2%  114.6 137.2 137.9 167.6  13.2
> 0.244u 1.766s 1:05.52 3.0%      0+0k 0+1io 0pf+0w
> Sat Nov 30 00:37:32 EST 2013
> 
> m: {5137} sudo script -q /dev/null hping3 --icmp-ts 88.198.??.?? | perl -ne 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \
> if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, $3);} \
> if (/tsrtt=(\d+)/) { \
> print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, "\r\n"; }'
> 0       131.3   131 = 57 + 74
> 1       122.4   122 = 56 + 66
> 2       122.6   123 = 56 + 67
> 3       127.6   128 = 57 + 71
> 4       146.5   147 = 57 + 90
> 5       139.8   140 = 56 + 84
> 6       131.0   131 = 57 + 74
> 7       134.6   135 = 57 + 78
> 8       137.7   138 = 57 + 81
> 9       148.1   148 = 57 + 91
> 10      141.2   142 = 57 + 85
> 11      146.4   146 = 56 + 90
> 12      153.6   154 = 57 + 97
> 13      149.4   150 = 57 + 93
> 14      120.2   121 = 57 + 64
> 15      120.6   120 = 56 + 64
> 16      130.7   131 = 57 + 74
> 17      126.4   126 = 56 + 70
> 18      117.9   118 = 57 + 61
> 19      116.9   117 = 57 + 60
> 20      119.8   119 = 56 + 63
> 21      132.0   132 = 56 + 76
> 22      134.2   134 = 56 + 78
> 23      138.8   139 = 57 + 82
> 
> 
> 
> Note the ICMP timestamp data from hping above.  From this ICMP timestamping data, it is obvious that the congestion is only happening on one path -- the one over he.net, and init7 is in the clear.
> 
> Any further insights are welcome.  But finding out about the ICMP timestamp feature has so far been the most useful thing in troubleshooting this issue; I'm surprised it's a rather unknown method to get to the bottom of these problems.
> 
> However, even after finding out about the cause and the party responsible, the problem is yet to be exhausted.  Any help appreciated.
> 
> Best regards,
> Constantine.
>