From LarrySheldon at cox.net  Tue Oct  1 00:37:47 2013
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Mon, 30 Sep 2013 19:37:47 -0500
Subject: minimum IPv6 announcement size
In-Reply-To: <W8671m01z1Una3W01869kK>
References: <5241986D.60902@stluke.com.ph> <m2k3i6nlpv.wl%randy@psg.com>
 <BD888C3C-9F36-42BA-A47A-1973AA07785A@delong.com>
 <CAAYzVeH-Vf9nie5Qtj9gEbFA6UH3C+Mez8aF12kmLmgsMKU10w@mail.gmail.com>
 <5242543C.8020709@stluke.com.ph>
 <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com>
 <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org>
 <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com>
 <524496AA.5070705@bitfreak.org>
 <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com>
 <W8671m01z1Una3W01869kK>
Message-ID: <524A195B.3070805@cox.net>

On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
> I don't respond to many of these threads but I have to say I've
> contested this one too only to have to beaten into my head that a /64
> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
> other protocols depend on the blocks to now be a /64..
>
> It's a waste, even if we're "planning for the future", no one house
> needs a /64 sitting on their lan.. or at least none I can sensibly
> think of o_O.


Are you accounting for connections to your refrigerator, water heater, 
razor, vibrator, and on down to list so the gubermint can tell they when 
you can use power for them?

-- 
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 rs at seastrom.com  Tue Oct  1 16:04:31 2013
From: rs at seastrom.com (Rob Seastrom)
Date: Tue, 01 Oct 2013 12:04:31 -0400
Subject: minimum IPv6 announcement size
In-Reply-To: <CAP-guGVfgTJER_fVMiyaR58mVS7yUTbGiV3fYJFoSOWUwb3hSA@mail.gmail.com> (William
 Herrin's message of "Mon, 30 Sep 2013 10:32:51 -0400")
References: <5241986D.60902@stluke.com.ph> <m2k3i6nlpv.wl%randy@psg.com>
 <BD888C3C-9F36-42BA-A47A-1973AA07785A@delong.com>
 <CAAYzVeH-Vf9nie5Qtj9gEbFA6UH3C+Mez8aF12kmLmgsMKU10w@mail.gmail.com>
 <5242543C.8020709@stluke.com.ph>
 <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com>
 <52448B0D.8030505@bitfreak.org> <m2eh8biadm.wl%randy@psg.com>
 <CAP-guGVfgTJER_fVMiyaR58mVS7yUTbGiV3fYJFoSOWUwb3hSA@mail.gmail.com>
Message-ID: <86zjqtvuy8.fsf@valhalla.seastrom.com>


William Herrin <bill at herrin.us> writes:

> IPv4 jumped from 8 bits to 32 bits. Which when you think about it is
> the same ratio as jumping from 32 bits to 128 bits.

Sorry for the late reply, Bill, but you were snoozing when they taught
logarithms in high school weren't you?

Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be
jumping from 32 bits to 48 bits (also, 1:16mm).

Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which
is not even remotely the same ratio.

-r




From bill at herrin.us  Tue Oct  1 18:11:23 2013
From: bill at herrin.us (William Herrin)
Date: Tue, 1 Oct 2013 14:11:23 -0400
Subject: minimum IPv6 announcement size
In-Reply-To: <86zjqtvuy8.fsf@valhalla.seastrom.com>
References: <5241986D.60902@stluke.com.ph> <m2k3i6nlpv.wl%randy@psg.com>
 <BD888C3C-9F36-42BA-A47A-1973AA07785A@delong.com>
 <CAAYzVeH-Vf9nie5Qtj9gEbFA6UH3C+Mez8aF12kmLmgsMKU10w@mail.gmail.com>
 <5242543C.8020709@stluke.com.ph>
 <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com>
 <52448B0D.8030505@bitfreak.org> <m2eh8biadm.wl%randy@psg.com>
 <CAP-guGVfgTJER_fVMiyaR58mVS7yUTbGiV3fYJFoSOWUwb3hSA@mail.gmail.com>
 <86zjqtvuy8.fsf@valhalla.seastrom.com>
Message-ID: <CAP-guGUQw4N+WU3SEHVP7PWC2X6HM23Ycd=qB8VjiqYM8NMHSQ@mail.gmail.com>

On Tue, Oct 1, 2013 at 12:04 PM, Rob Seastrom <rs at seastrom.com> wrote:
> William Herrin <bill at herrin.us> writes:
>> IPv4 jumped from 8 bits to 32 bits. Which when you think about it is
>> the same ratio as jumping from 32 bits to 128 bits.
>
> Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be
> jumping from 32 bits to 48 bits (also, 1:16mm).

Hi Rob,

And yet we're allocating /19's where previously we allocated space
that added up to /7's and /48's where previously we allocated /24's.
My math may be flawed but the pattern is there all the same.


> Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which
> is not even remotely the same ratio.

You know enough about IPv6 to realize that we didn't go from 32 bits
to 128 bits, we went from either 24ish bits to 48 or 28ish bits to 64,
depending on how you look at it. While IPv6 is capable of working the
same as IPv4, that's not how we're actually using it.

More, growth has not been linear since IPv4's advent and is not (by
anyone reasonable) projected to be linear or sub-linear in IPv6.
Computing a linear ratio as if that were representative of the
expected lifetime of the new address space does not paint an honest
picture.


> Sorry for the late reply, Bill, but you were snoozing when they taught
> logarithms in high school weren't you?

While I did in fact snooze my way through a significant part of
school, I was wide awake for the word problems where we were asked to
build an appropriate equation. You remember: the trick questions where
a couple of irrelevant bits of data were thrown in and critical
factors were implied without being stated. And despite the
distractions you were asked to grasp the essential problem from the
English language description. Those were fun.

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 owen at delong.com  Tue Oct  1 18:33:44 2013
From: owen at delong.com (Owen DeLong)
Date: Tue, 1 Oct 2013 11:33:44 -0700
Subject: minimum IPv6 announcement size
In-Reply-To: <CAP-guGUQw4N+WU3SEHVP7PWC2X6HM23Ycd=qB8VjiqYM8NMHSQ@mail.gmail.com>
References: <5241986D.60902@stluke.com.ph> <m2k3i6nlpv.wl%randy@psg.com>
 <BD888C3C-9F36-42BA-A47A-1973AA07785A@delong.com>
 <CAAYzVeH-Vf9nie5Qtj9gEbFA6UH3C+Mez8aF12kmLmgsMKU10w@mail.gmail.com>
 <5242543C.8020709@stluke.com.ph>
 <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com>
 <52448B0D.8030505@bitfreak.org> <m2eh8biadm.wl%randy@psg.com>
 <CAP-guGVfgTJER_fVMiyaR58mVS7yUTbGiV3fYJFoSOWUwb3hSA@mail.gmail.com>
 <86zjqtvuy8.fsf@valhalla.seastrom.com>
 <CAP-guGUQw4N+WU3SEHVP7PWC2X6HM23Ycd=qB8VjiqYM8NMHSQ@mail.gmail.com>
Message-ID: <7A036F61-1646-4086-8A0C-5F843E5CD544@delong.com>


On Oct 1, 2013, at 11:11 , William Herrin <bill at herrin.us> wrote:

> On Tue, Oct 1, 2013 at 12:04 PM, Rob Seastrom <rs at seastrom.com> wrote:
>> William Herrin <bill at herrin.us> writes:
>>> IPv4 jumped from 8 bits to 32 bits. Which when you think about it is
>>> the same ratio as jumping from 32 bits to 128 bits.
>> 
>> Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be
>> jumping from 32 bits to 48 bits (also, 1:16mm).
> 
> Hi Rob,
> 
> And yet we're allocating /19's where previously we allocated space
> that added up to /7's and /48's where previously we allocated /24's.
> My math may be flawed but the pattern is there all the same.

Not exactly...

We're allocating /16s and/or /20s where previously we allocated space
that added up to /7's, but, the holders of the /7s were coming back for more
and more on a regular basis. I don't believe anyone holding a /16 or /20
of IPv6 has come back for another allocation at all and I would be surprised
if such an organization were to do so in the next 5 years or so.

We're allocating /48s where previously we allocated roughly /16-/24.

Any effort at making direct comparisons between IPv4 and IPv6 number utilization
is flawed because there is, by definition, nothing approximating a simple ratio
between the two.

> 
> 
>> Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which
>> is not even remotely the same ratio.
> 
> You know enough about IPv6 to realize that we didn't go from 32 bits
> to 128 bits, we went from either 24ish bits to 48 or 28ish bits to 64,
> depending on how you look at it. While IPv6 is capable of working the
> same as IPv4, that's not how we're actually using it.

Both of those estimates are also flawed.

> More, growth has not been linear since IPv4's advent and is not (by
> anyone reasonable) projected to be linear or sub-linear in IPv6.
> Computing a linear ratio as if that were representative of the
> expected lifetime of the new address space does not paint an honest
> picture.

Nor does any effort to apply a simple ratio between IPv4 and IPv6.

There are sufficient differences in the allocation algorithms and counting
methods between the two that an apples to apples comparison of allocation
policies simply isn't possible.

Owen



From leo.vegoda at icann.org  Tue Oct  1 18:53:13 2013
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Tue, 1 Oct 2013 11:53:13 -0700
Subject: minimum IPv6 announcement size
In-Reply-To: <CAP-guGUQw4N+WU3SEHVP7PWC2X6HM23Ycd=qB8VjiqYM8NMHSQ@mail.gmail.com>
References: <5241986D.60902@stluke.com.ph> <m2k3i6nlpv.wl%randy@psg.com>
 <BD888C3C-9F36-42BA-A47A-1973AA07785A@delong.com>
 <CAAYzVeH-Vf9nie5Qtj9gEbFA6UH3C+Mez8aF12kmLmgsMKU10w@mail.gmail.com>
 <5242543C.8020709@stluke.com.ph>
 <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com>
 <52448B0D.8030505@bitfreak.org> <m2eh8biadm.wl%randy@psg.com>
 <CAP-guGVfgTJER_fVMiyaR58mVS7yUTbGiV3fYJFoSOWUwb3hSA@mail.gmail.com>
 <86zjqtvuy8.fsf@valhalla.seastrom.com>
 <CAP-guGUQw4N+WU3SEHVP7PWC2X6HM23Ycd=qB8VjiqYM8NMHSQ@mail.gmail.com>
Message-ID: <5648A8908CCB564EBF46E2BC904A75B19680B6C58A@EXVPMBX100-1.exc.icann.org>

William Herrin wrote:

[...]

> And yet we're allocating /19's 

If the stats published at
http://www.nro.net/pub/stats/nro/delegated-extended are to be believed
then the only two /19s were allocated in 2005 when the HD-ratio value in
the policy was lower. Looking at all the RIRs together another nine /20s
have been allocated and seven /21s.  There are just 51 allocations of
/22 of shorter prefixes.

Given that almost 17,000 IPv6 blocks have been issued, those 51 blocks
are really just a fraction of a percent and seem to represent the
exception and not the norm.

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/20131001/8336eb5a/attachment.bin>

From tdurack at gmail.com  Tue Oct  1 19:09:56 2013
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 1 Oct 2013 15:09:56 -0400
Subject: TWC / MTC broadband
Message-ID: <CAE_ug15xS+5bcybfuTmwQ46Qa-oM1FkztwwmxcKjpTgvC4iJEA@mail.gmail.com>

Anyone alive at TWC and/or MTC broadband?

Looks like AS36100 (MTC Broadband) is incorrectly announcing 72.43.125.0/24.
This is causing problems for TWC users who are in 72.43.125.0/24

-- 
Tim:>

From rmcintosh at nitemare.net  Tue Oct  1 19:11:39 2013
From: rmcintosh at nitemare.net (Ryan McIntosh)
Date: Tue, 1 Oct 2013 15:11:39 -0400
Subject: minimum IPv6 announcement size
In-Reply-To: <524A195B.3070805@cox.net>
References: <5241986D.60902@stluke.com.ph> <m2k3i6nlpv.wl%randy@psg.com>
 <BD888C3C-9F36-42BA-A47A-1973AA07785A@delong.com>
 <CAAYzVeH-Vf9nie5Qtj9gEbFA6UH3C+Mez8aF12kmLmgsMKU10w@mail.gmail.com>
 <5242543C.8020709@stluke.com.ph>
 <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com>
 <20130926085250.GA8058@vacation.karoshi.com.>
 <52448B0D.8030505@bitfreak.org>
 <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com>
 <524496AA.5070705@bitfreak.org>
 <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com>
 <524A195B.3070805@cox.net>
Message-ID: <CAEoCk-OXdhLunjg6RHmQYwHN9AqPxVUzjCYUYy_6spbqRmj9XQ@mail.gmail.com>

I'd love to be able to turn the microwave and oven on with my phone..
maybe ten years from now lol..

In all seriousness though (and after skimming some of the other
responses), I absolutely understand the ideals and needs amongst
conserving memory on our routers for the sake of the future of bgp and
internal routing. The problem I described has nothing to do with that
however, I was mearly pointing out the fact that the basis of the
larger allocations are based upon the fact we're handing over /64's to
each vlan/point to point/lan/etc that we're turning up. In practice, I
understand, a /64 means that 64 bits can handle a unique ip for every
host without having to worry about numbering them, but how many hosts
do we truly think will be sitting on one network? Surely not a /64's
worth, that alone would cause havoc on a neighbor table's maximum
memory limit. Maybe I'm missing the connection here, but I still don't
see how a /64 is justified for each individual user/host/server/etc
sitting on the edge of the internet that's getting ip's from an
upstream provider (not arin/ripe/etc).

It's those smaller blocks that justify handing over larger ones, which
I do understand there's plenty of, but how long are we going to patch
the same problem and not try to fix it right?

Ryan

On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <LarrySheldon at cox.net> wrote:
> On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
>>
>> I don't respond to many of these threads but I have to say I've
>> contested this one too only to have to beaten into my head that a /64
>> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
>> other protocols depend on the blocks to now be a /64..
>>
>> It's a waste, even if we're "planning for the future", no one house
>> needs a /64 sitting on their lan.. or at least none I can sensibly
>> think of o_O.
>
>
>
> Are you accounting for connections to your refrigerator, water heater,
> razor, vibrator, and on down to list so the gubermint can tell they when you
> can use power for them?
>
> --
> 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 johnl at iecc.com  Tue Oct  1 19:29:28 2013
From: johnl at iecc.com (John Levine)
Date: 1 Oct 2013 19:29:28 -0000
Subject: semi-ot: network monitoring tools
Message-ID: <20131001192928.68489.qmail@joyce.lan>

I was talking to a bunch of people who run ISPs and other networks in
LDCs (yes, including Nigeria) and someone asked about monitoring tools
to watch traffic on his network so he can get advance warning of dodgy
customers and prevent complaints and blacklisting.

These people are plenty smart, but don't have a lot of money.
Suggestions welcome.

R's,
John


From bmanning at vacation.karoshi.com  Tue Oct  1 19:58:34 2013
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 1 Oct 2013 19:58:34 +0000
Subject: minimum IPv6 announcement size
In-Reply-To: <CAEoCk-OXdhLunjg6RHmQYwHN9AqPxVUzjCYUYy_6spbqRmj9XQ@mail.gmail.com>
References: <CAAYzVeH-Vf9nie5Qtj9gEbFA6UH3C+Mez8aF12kmLmgsMKU10w@mail.gmail.com>
 <5242543C.8020709@stluke.com.ph>
 <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com>
 <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org>
 <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com>
 <524496AA.5070705@bitfreak.org>
 <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com>
 <524A195B.3070805@cox.net>
 <CAEoCk-OXdhLunjg6RHmQYwHN9AqPxVUzjCYUYy_6spbqRmj9XQ@mail.gmail.com>
Message-ID: <20131001195834.GA10106@vacation.karoshi.com.>


back in the good o'l days when we would hand out 24 bits for the 
number of hosts in a network.   It was too many bits then and is 
too many bits now....  a /64 is just overkill.

/bill



On Tue, Oct 01, 2013 at 03:11:39PM -0400, Ryan McIntosh wrote:
> I'd love to be able to turn the microwave and oven on with my phone..
> maybe ten years from now lol..
> 
> In all seriousness though (and after skimming some of the other
> responses), I absolutely understand the ideals and needs amongst
> conserving memory on our routers for the sake of the future of bgp and
> internal routing. The problem I described has nothing to do with that
> however, I was mearly pointing out the fact that the basis of the
> larger allocations are based upon the fact we're handing over /64's to
> each vlan/point to point/lan/etc that we're turning up. In practice, I
> understand, a /64 means that 64 bits can handle a unique ip for every
> host without having to worry about numbering them, but how many hosts
> do we truly think will be sitting on one network? Surely not a /64's
> worth, that alone would cause havoc on a neighbor table's maximum
> memory limit. Maybe I'm missing the connection here, but I still don't
> see how a /64 is justified for each individual user/host/server/etc
> sitting on the edge of the internet that's getting ip's from an
> upstream provider (not arin/ripe/etc).
> 
> It's those smaller blocks that justify handing over larger ones, which
> I do understand there's plenty of, but how long are we going to patch
> the same problem and not try to fix it right?
> 
> Ryan
> 
> On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <LarrySheldon at cox.net> wrote:
> > On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
> >>
> >> I don't respond to many of these threads but I have to say I've
> >> contested this one too only to have to beaten into my head that a /64
> >> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
> >> other protocols depend on the blocks to now be a /64..
> >>
> >> It's a waste, even if we're "planning for the future", no one house
> >> needs a /64 sitting on their lan.. or at least none I can sensibly
> >> think of o_O.
> >
> >
> >
> > Are you accounting for connections to your refrigerator, water heater,
> > razor, vibrator, and on down to list so the gubermint can tell they when you
> > can use power for them?
> >
> > --
> > 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 owen at delong.com  Tue Oct  1 20:20:36 2013
From: owen at delong.com (Owen DeLong)
Date: Tue, 1 Oct 2013 13:20:36 -0700
Subject: minimum IPv6 announcement size
In-Reply-To: <CAEoCk-OXdhLunjg6RHmQYwHN9AqPxVUzjCYUYy_6spbqRmj9XQ@mail.gmail.com>
References: <5241986D.60902@stluke.com.ph> <m2k3i6nlpv.wl%randy@psg.com>
 <BD888C3C-9F36-42BA-A47A-1973AA07785A@delong.com>
 <CAAYzVeH-Vf9nie5Qtj9gEbFA6UH3C+Mez8aF12kmLmgsMKU10w@mail.gmail.com>
 <5242543C.8020709@stluke.com.ph>
 <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com>
 <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org>
 <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com>
 <524496AA.5070705@bitfreak.org>
 <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com>
 <524A195B.3070805@cox.net>
 <CAEoCk-OXdhLunjg6RHmQYwHN9AqPxVUzjCYUYy_6spbqRmj9XQ@mail.gmail.com>
Message-ID: <7DE298C0-996D-4081-AF25-6498DDA7F141@delong.com>

The original plan was to go from 32 to 64 bits total. The additional 64 bits were added purely for the sake of EUI-64 based addressing, and really, 64 bits of network number is way more than enough. 

The /64 a are not what justify the larger blocks. That's IPv4 think. 

In IPv6, it is far better to think about the number of sinners without regard to counting hosts. The /48 per site is justified because it is almost inconceivable that a single site would ever need more than 65536 subnets. 

The /32 is a minimum reasonable allocation for an ISP to balance the tradeoff between routing table entries and consumption. 

Most estimates say that the vast majority of significant providers will end up using a /28 with some outliers on both sides. Many smaller providers will end up with /32 and a few medium to large ones will get /24 or even /20. A minute (probably less than 20 world wide) number might get /16s. 

Absent some novel (and IMHO I'll-advised) approach to semantic overloading, we will have plenty of address space to number the internet for many many years. 

Owen


> On Oct 1, 2013, at 12:11, Ryan McIntosh <rmcintosh at nitemare.net> wrote:
> 
> I'd love to be able to turn the microwave and oven on with my phone..
> maybe ten years from now lol..
> 
> In all seriousness though (and after skimming some of the other
> responses), I absolutely understand the ideals and needs amongst
> conserving memory on our routers for the sake of the future of bgp and
> internal routing. The problem I described has nothing to do with that
> however, I was mearly pointing out the fact that the basis of the
> larger allocations are based upon the fact we're handing over /64's to
> each vlan/point to point/lan/etc that we're turning up. In practice, I
> understand, a /64 means that 64 bits can handle a unique ip for every
> host without having to worry about numbering them, but how many hosts
> do we truly think will be sitting on one network? Surely not a /64's
> worth, that alone would cause havoc on a neighbor table's maximum
> memory limit. Maybe I'm missing the connection here, but I still don't
> see how a /64 is justified for each individual user/host/server/etc
> sitting on the edge of the internet that's getting ip's from an
> upstream provider (not arin/ripe/etc).
> 
> It's those smaller blocks that justify handing over larger ones, which
> I do understand there's plenty of, but how long are we going to patch
> the same problem and not try to fix it right?
> 
> Ryan
> 
>> On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <LarrySheldon at cox.net> wrote:
>>> On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
>>> 
>>> I don't respond to many of these threads but I have to say I've
>>> contested this one too only to have to beaten into my head that a /64
>>> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
>>> other protocols depend on the blocks to now be a /64..
>>> 
>>> It's a waste, even if we're "planning for the future", no one house
>>> needs a /64 sitting on their lan.. or at least none I can sensibly
>>> think of o_O.
>> 
>> 
>> 
>> Are you accounting for connections to your refrigerator, water heater,
>> razor, vibrator, and on down to list so the gubermint can tell they when you
>> can use power for them?
>> 
>> --
>> 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 surfer at mauigateway.com  Tue Oct  1 20:42:51 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 1 Oct 2013 13:42:51 -0700
Subject: minimum IPv6 announcement size
Message-ID: <20131001134251.348229F1@resin11.mta.everyone.net>



--- owen at delong.com wrote:
From: Owen DeLong <owen at delong.com>
 
we will have plenty of address space to number the internet 
for many many years. 
----------------------------------------------


You can't know the future and what addressing requirements
it'll bring:

"I have to say that in 1981, making those decisions, I felt 
like I was providing enough freedom for 10 years. That is, 
a move from 64k to 640k felt like something that would last 
a great deal of time. Well, it didn't - it took about only 
6 years before people started to see that as a real problem."


scott


From james.cutler at consultant.com  Tue Oct  1 20:45:09 2013
From: james.cutler at consultant.com (Cutler James R)
Date: Tue, 1 Oct 2013 16:45:09 -0400
Subject: minimum IPv6 announcement size
In-Reply-To: <7DE298C0-996D-4081-AF25-6498DDA7F141@delong.com>
References: <5241986D.60902@stluke.com.ph> <m2k3i6nlpv.wl%randy@psg.com>
 <BD888C3C-9F36-42BA-A47A-1973AA07785A@delong.com>
 <CAAYzVeH-Vf9nie5Qtj9gEbFA6UH3C+Mez8aF12kmLmgsMKU10w@mail.gmail.com>
 <5242543C.8020709@stluke.com.ph>
 <9F19CF54-994A-4F3C-847D-EE086A4E9C39@delong.com>
 <20130926085250.GA8058@vacation.karoshi.com.> <52448B0D.8030505@bitfreak.org>
 <970DA900-CD7E-4938-A9CB-ABE7C309B045@bogus.com>
 <524496AA.5070705@bitfreak.org>
 <52451123.e600ec0a.5b01.ffffe28eSMTPIN_ADDED_BROKEN@mx.google.com>
 <524A195B.3070805@cox.net>
 <CAEoCk-OXdhLunjg6RHmQYwHN9AqPxVUzjCYUYy_6spbqRmj9XQ@mail.gmail.com>
 <7DE298C0-996D-4081-AF25-6498DDA7F141@delong.com>
Message-ID: <B3E4D1BD-6E40-4EA0-98BC-C9F26AAF5B88@consultant.com>

I try not to think about sinners too much when planning networks. Subnets are more interesting.

Maybe many of you like spending time maintaining NAT configurations and creatively masking as determined by today's end system count on each subnet. This all, of course, in the interest of maximum address assignment efficiency, a term of only the most nebulous definition.

Hogwash, I say.  The days of counting end systems in order to determine addressing is GONE. And I, for one, am much pleased.

Let's optimize the person instead of micro-optimizing bits.  Count the subnets you really think you need, shift one or two bits left, and ask for /whatever as described by Owen.  "many many years" is probably multiples of the two decades or so of IPv4 we have experienced.

Continuing arguments on NANOG and elsewhere about /64 - Good or Bad - check one, are just wasting your time and mine. Get yourself into action and just get IPv6 deployed.  

Owen has the right of it.

	Cutler


On Oct 1, 2013, at 4:20 PM, Owen DeLong <owen at delong.com> wrote:

> The original plan was to go from 32 to 64 bits total. The additional 64 bits were added purely for the sake of EUI-64 based addressing, and really, 64 bits of network number is way more than enough. 
> 
> The /64 a are not what justify the larger blocks. That's IPv4 think. 
> 
> In IPv6, it is far better to think about the number of sinners without regard to counting hosts. The /48 per site is justified because it is almost inconceivable that a single site would ever need more than 65536 subnets. 
> 
> The /32 is a minimum reasonable allocation for an ISP to balance the tradeoff between routing table entries and consumption. 
> 
> Most estimates say that the vast majority of significant providers will end up using a /28 with some outliers on both sides. Many smaller providers will end up with /32 and a few medium to large ones will get /24 or even /20. A minute (probably less than 20 world wide) number might get /16s. 
> 
> Absent some novel (and IMHO I'll-advised) approach to semantic overloading, we will have plenty of address space to number the internet for many many years. 
> 
> Owen
> 
> 
>> On Oct 1, 2013, at 12:11, Ryan McIntosh <rmcintosh at nitemare.net> wrote:
>> 
>> I'd love to be able to turn the microwave and oven on with my phone..
>> maybe ten years from now lol..
>> 
>> In all seriousness though (and after skimming some of the other
>> responses), I absolutely understand the ideals and needs amongst
>> conserving memory on our routers for the sake of the future of bgp and
>> internal routing. The problem I described has nothing to do with that
>> however, I was mearly pointing out the fact that the basis of the
>> larger allocations are based upon the fact we're handing over /64's to
>> each vlan/point to point/lan/etc that we're turning up. In practice, I
>> understand, a /64 means that 64 bits can handle a unique ip for every
>> host without having to worry about numbering them, but how many hosts
>> do we truly think will be sitting on one network? Surely not a /64's
>> worth, that alone would cause havoc on a neighbor table's maximum
>> memory limit. Maybe I'm missing the connection here, but I still don't
>> see how a /64 is justified for each individual user/host/server/etc
>> sitting on the edge of the internet that's getting ip's from an
>> upstream provider (not arin/ripe/etc).
>> 
>> It's those smaller blocks that justify handing over larger ones, which
>> I do understand there's plenty of, but how long are we going to patch
>> the same problem and not try to fix it right?
>> 
>> Ryan
>> 
>>> On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <LarrySheldon at cox.net> wrote:
>>>> On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
>>>> 
>>>> I don't respond to many of these threads but I have to say I've
>>>> contested this one too only to have to beaten into my head that a /64
>>>> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
>>>> other protocols depend on the blocks to now be a /64..
>>>> 
>>>> It's a waste, even if we're "planning for the future", no one house
>>>> needs a /64 sitting on their lan.. or at least none I can sensibly
>>>> think of o_O.
>>> 
>>> 
>>> 
>>> Are you accounting for connections to your refrigerator, water heater,
>>> razor, vibrator, and on down to list so the gubermint can tell they when you
>>> can use power for them?
>>> 
>>> --
>>> 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 michael at pbandjelly.org  Tue Oct  1 21:03:25 2013
From: michael at pbandjelly.org (Michael Shuler)
Date: Tue, 01 Oct 2013 16:03:25 -0500
Subject: semi-ot: network monitoring tools
In-Reply-To: <20131001192928.68489.qmail@joyce.lan>
References: <20131001192928.68489.qmail@joyce.lan>
Message-ID: <524B389D.80202@pbandjelly.org>

On 10/01/2013 02:29 PM, John Levine wrote:
> I was talking to a bunch of people who run ISPs and other networks in
> LDCs (yes, including Nigeria) and someone asked about monitoring tools
> to watch traffic on his network so he can get advance warning of dodgy
> customers and prevent complaints and blacklisting.
> 
> These people are plenty smart, but don't have a lot of money.
> Suggestions welcome.

I'd say it's on topic.  OpenNMS has good community support, as well as
reasonably priced commercial support - http://www.opennms.org/

I've used OpenNMS for years and it keeps getting better.

-- 
Kind regards,
Michael


From dsmhood at gmail.com  Tue Oct  1 23:22:51 2013
From: dsmhood at gmail.com (Daniel Hood)
Date: Tue, 1 Oct 2013 13:22:51 -1000
Subject: Facebook NOC Contact
Message-ID: <CAOdwzjAJur7Fkirnb6P9nSowJ1_M7L2sbOJ9rSzadPf8+Qy5JQ@mail.gmail.com>

Hi,

Having some issues with traffic to Facebook.

Is there anyone here from Facebook lurking on the list? Or does anyone have
a better contact then their help form?

Regards,

Daniel

From streiner at cluebyfour.org  Tue Oct  1 20:50:32 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 1 Oct 2013 16:50:32 -0400 (EDT)
Subject: Facebook NOC Contact
In-Reply-To: <CAOdwzjAJur7Fkirnb6P9nSowJ1_M7L2sbOJ9rSzadPf8+Qy5JQ@mail.gmail.com>
References: <CAOdwzjAJur7Fkirnb6P9nSowJ1_M7L2sbOJ9rSzadPf8+Qy5JQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1310011649480.24937@whammy.cluebyfour.org>

On Tue, 1 Oct 2013, Daniel Hood wrote:

> Having some issues with traffic to Facebook.
>
> Is there anyone here from Facebook lurking on the list? Or does anyone have
> a better contact then their help form?

Try ops at facebook.com

jms


From rdobbins at arbor.net  Wed Oct  2 03:55:29 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 2 Oct 2013 03:55:29 +0000
Subject: semi-ot: network monitoring tools
In-Reply-To: <20131001192928.68489.qmail@joyce.lan>
References: <20131001192928.68489.qmail@joyce.lan>
Message-ID: <CA7FE717-8A40-458B-9AC5-F7E970504EC1@arbor.net>


On Oct 2, 2013, at 2:29 AM, John Levine wrote:

> These people are plenty smart, but don't have a lot of money.

Enable NetFlow, and use some open-source NetFlow collection/analysis system like nfdump/nfsen, etc.

dnstop and the like for DNS can be pretty revealing, as well.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From ryan.dooley at lookout.com  Wed Oct  2 05:57:16 2013
From: ryan.dooley at lookout.com (Ryan Dooley)
Date: Tue, 1 Oct 2013 22:57:16 -0700
Subject: semi-ot: network monitoring tools
In-Reply-To: <CA7FE717-8A40-458B-9AC5-F7E970504EC1@arbor.net>
References: <20131001192928.68489.qmail@joyce.lan>
 <CA7FE717-8A40-458B-9AC5-F7E970504EC1@arbor.net>
Message-ID: <CALsDVfqpgDL8SxGyiY_Bw8sWQTJ2gUQ2D5dFBVu_=5zg9b6wXw@mail.gmail.com>

Coworkers of mine introduced me to Observium:
http://www.observium.org/wiki/Main_Page

Cheers,
Ryan


On Tue, Oct 1, 2013 at 8:55 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:

>
> On Oct 2, 2013, at 2:29 AM, John Levine wrote:
>
> > These people are plenty smart, but don't have a lot of money.
>
> Enable NetFlow, and use some open-source NetFlow collection/analysis
> system like nfdump/nfsen, etc.
>
> dnstop and the like for DNS can be pretty revealing, as well.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>           Luck is the residue of opportunity and design.
>
>                        -- John Milton
>
>
>

From rdobbins at arbor.net  Wed Oct  2 06:07:46 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 2 Oct 2013 06:07:46 +0000
Subject: semi-ot: network monitoring tools
In-Reply-To: <CALsDVfqpgDL8SxGyiY_Bw8sWQTJ2gUQ2D5dFBVu_=5zg9b6wXw@mail.gmail.com>
References: <20131001192928.68489.qmail@joyce.lan>
 <CA7FE717-8A40-458B-9AC5-F7E970504EC1@arbor.net>
 <CALsDVfqpgDL8SxGyiY_Bw8sWQTJ2gUQ2D5dFBVu_=5zg9b6wXw@mail.gmail.com>
Message-ID: <B87751F5-685F-41AB-85EA-2BA2B973F3A4@arbor.net>


On Oct 2, 2013, at 12:57 PM, Ryan Dooley wrote:

> Coworkers of mine introduced me to Observium:
> http://www.observium.org/wiki/Main_Page

Does it utilize flow telemetry?  On the main page, they talk about SNMP, making it sound a lot like Nagios . . .

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From shopik at inblock.ru  Wed Oct  2 06:34:01 2013
From: shopik at inblock.ru (Nikolay Shopik)
Date: Wed, 2 Oct 2013 09:34:01 +0300
Subject: semi-ot: network monitoring tools
In-Reply-To: <B87751F5-685F-41AB-85EA-2BA2B973F3A4@arbor.net>
References: <20131001192928.68489.qmail@joyce.lan>
 <CA7FE717-8A40-458B-9AC5-F7E970504EC1@arbor.net>
 <CALsDVfqpgDL8SxGyiY_Bw8sWQTJ2gUQ2D5dFBVu_=5zg9b6wXw@mail.gmail.com>
 <B87751F5-685F-41AB-85EA-2BA2B973F3A4@arbor.net>
Message-ID: <F38A8D5B-D478-4ABF-A15C-65A42912419B@inblock.ru>

No all stats are snmp based

> On 02 ???. 2013 ?., at 9:07, "Dobbins, Roland" <rdobbins at arbor.net> wrote:
> 
> 
>> On Oct 2, 2013, at 12:57 PM, Ryan Dooley wrote:
>> 
>> Coworkers of mine introduced me to Observium:
>> http://www.observium.org/wiki/Main_Page
> 
> Does it utilize flow telemetry?  On the main page, they talk about SNMP, making it sound a lot like Nagios . . .
> 
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
> 
>      Luck is the residue of opportunity and design.
> 
>               -- John Milton
> 
> 


From hhoffman at ip-solutions.net  Wed Oct  2 13:06:27 2013
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Wed, 02 Oct 2013 09:06:27 -0400
Subject: semi-ot: network monitoring tools
In-Reply-To: <F38A8D5B-D478-4ABF-A15C-65A42912419B@inblock.ru>
References: <20131001192928.68489.qmail@joyce.lan>
 <CA7FE717-8A40-458B-9AC5-F7E970504EC1@arbor.net>
 <CALsDVfqpgDL8SxGyiY_Bw8sWQTJ2gUQ2D5dFBVu_=5zg9b6wXw@mail.gmail.com>
 <B87751F5-685F-41AB-85EA-2BA2B973F3A4@arbor.net>
 <F38A8D5B-D478-4ABF-A15C-65A42912419B@inblock.ru>
Message-ID: <524C1A53.5010709@ip-solutions.net>

Have them check out the various services from Team Cymru:

https://www.team-cymru.org/Services/

Specifically the TC Console

Cheers,
Harry

On 10/02/2013 02:34 AM, Nikolay Shopik wrote:
> No all stats are snmp based
> 
>> On 02 ???. 2013 ?., at 9:07, "Dobbins, Roland" <rdobbins at arbor.net> wrote:
>>
>>
>>> On Oct 2, 2013, at 12:57 PM, Ryan Dooley wrote:
>>>
>>> Coworkers of mine introduced me to Observium:
>>> http://www.observium.org/wiki/Main_Page
>>
>> Does it utilize flow telemetry?  On the main page, they talk about SNMP, making it sound a lot like Nagios . . .
>>
>> -----------------------------------------------------------------------
>> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>>
>>      Luck is the residue of opportunity and design.
>>
>>               -- John Milton
>>
>>
> 


From carlosm3011 at gmail.com  Wed Oct  2 15:54:29 2013
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Wed, 2 Oct 2013 12:54:29 -0300
Subject: Someone from PCCW NOC here ?
Message-ID: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>

Hi all,

We'd appreciate having someone from PCCW, particularly from their operation
in Panama, having contact us. Private is fine.

A downstream customer from them in Panama has been observed hijacking some
prefixes.

regards

~Carlos

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
h <http://cagnazzo.name>ttp://cagnazzo.me
=========================

From pf at tippete.net  Wed Oct  2 16:02:26 2013
From: pf at tippete.net (Pierfrancesco Caci)
Date: Wed, 02 Oct 2013 18:02:26 +0200
Subject: Someone from PCCW NOC here ?
In-Reply-To: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>
 (Carlos Martinez-Cagnazzo's message of "Wed, 2 Oct 2013 12:54:29 -0300")
References: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>
Message-ID: <87eh834q5p.fsf@snoopy.tippete.net>

>>>>> "Carlos" == Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> writes:


    Carlos> Hi all,
    Carlos> We'd appreciate having someone from PCCW, particularly from their operation
    Carlos> in Panama, having contact us. Private is fine.

    Carlos> A downstream customer from them in Panama has been observed hijacking some
    Carlos> prefixes.

    Carlos> regards

Please report to our noc (usnoc at pccwglobal.com) with details. 


Pf


From dave at temk.in  Wed Oct  2 16:20:00 2013
From: dave at temk.in (David Temkin)
Date: Wed, 2 Oct 2013 09:20:00 -0700
Subject: Final Agenda Published - NANOG 59
Message-ID: <CAFJiuFrx9Gsq3G=Nu0YY6CGhyHcuhwgAG+5svnvSbJTWd1OzvA@mail.gmail.com>

All,

The final agenda for our meeting next week has been published at
http://www.nanog.org/meetings/nanog59/agenda

Please note that the program begins at 10AM on Monday and the tutorials can
now be found on Tuesday morning.  I hope you all share the excitement that
I do for this great program.

For newcomers, we'll host a welcome lunch on Monday at noon.  Even if
you're an old timer, we'd love to have you at this lunch to help introduce
this potentially record-breaking crowd (we sit at 594 registered attendees
at this moment) to NANOG and help them get the most of their time at the
meeting.

We'll provide you with more information on-site, and as always, feel free
to seek out a member of any of the committees - Program, Development,
Communications, and of course, the Board of Directors, if you have any
questions.  I promise we're a friendly bunch!

Best Regards,
-Dave Temkin
Chair, NANOG Program Committee

From morrowc.lists at gmail.com  Wed Oct  2 17:43:46 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 2 Oct 2013 13:43:46 -0400
Subject: Someone from PCCW NOC here ?
In-Reply-To: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>
References: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>
Message-ID: <CAL9jLaaHTo00m0aRoRKvaG8PMhScQoge_qRV=sVuXxEMkMAMSg@mail.gmail.com>

I am shocked that a pccw customer isn't being prefix-filtered.

On Wed, Oct 2, 2013 at 11:54 AM, Carlos Martinez-Cagnazzo
<carlosm3011 at gmail.com> wrote:
> Hi all,
>
> We'd appreciate having someone from PCCW, particularly from their operation
> in Panama, having contact us. Private is fine.
>
> A downstream customer from them in Panama has been observed hijacking some
> prefixes.
>
> regards
>
> ~Carlos
>
> --
> --
> =========================
> Carlos M. Martinez-Cagnazzo
> h <http://cagnazzo.name>ttp://cagnazzo.me
> =========================


From m.hallgren at free.fr  Wed Oct  2 20:41:01 2013
From: m.hallgren at free.fr (Michael Hallgren)
Date: Wed, 02 Oct 2013 22:41:01 +0200
Subject: Someone from PCCW NOC here ?
In-Reply-To: <CAL9jLaaHTo00m0aRoRKvaG8PMhScQoge_qRV=sVuXxEMkMAMSg@mail.gmail.com>
References: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>
 <CAL9jLaaHTo00m0aRoRKvaG8PMhScQoge_qRV=sVuXxEMkMAMSg@mail.gmail.com>
Message-ID: <524C84DD.5090505@free.fr>

Le 02/10/2013 19:43, Christopher Morrow a ?crit :
> I am shocked that a pccw customer isn't being prefix-filtered.

Ohhh, they're rare bird?

(
I'd hope so, rare bird; and I do strongly agree that (at least) these birds
-- customer-routes -- should live in a transparent community... IRR
(well...),
(or for those who believe) RPKI :-)
)

Thoughts?

Cheers,
mh
>
> On Wed, Oct 2, 2013 at 11:54 AM, Carlos Martinez-Cagnazzo
> <carlosm3011 at gmail.com> wrote:
>> Hi all,
>>
>> We'd appreciate having someone from PCCW, particularly from their operation
>> in Panama, having contact us. Private is fine.
>>
>> A downstream customer from them in Panama has been observed hijacking some
>> prefixes.
>>
>> regards
>>
>> ~Carlos
>>
>> --
>> --
>> =========================
>> Carlos M. Martinez-Cagnazzo
>> h <http://cagnazzo.name>ttp://cagnazzo.me
>> =========================



From randy at psg.com  Wed Oct  2 23:28:15 2013
From: randy at psg.com (Randy Bush)
Date: Thu, 03 Oct 2013 08:28:15 +0900
Subject: Someone from PCCW NOC here ?
In-Reply-To: <CAL9jLaaHTo00m0aRoRKvaG8PMhScQoge_qRV=sVuXxEMkMAMSg@mail.gmail.com>
References: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>
 <CAL9jLaaHTo00m0aRoRKvaG8PMhScQoge_qRV=sVuXxEMkMAMSg@mail.gmail.com>
Message-ID: <m2vc1fuub4.wl%randy@psg.com>

> I am shocked that a pccw customer isn't being prefix-filtered.

never happened before, right?


From morrowc.lists at gmail.com  Wed Oct  2 23:33:01 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 2 Oct 2013 19:33:01 -0400
Subject: Someone from PCCW NOC here ?
In-Reply-To: <m2vc1fuub4.wl%randy@psg.com>
References: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>
 <CAL9jLaaHTo00m0aRoRKvaG8PMhScQoge_qRV=sVuXxEMkMAMSg@mail.gmail.com>
 <m2vc1fuub4.wl%randy@psg.com>
Message-ID: <CAL9jLaahbCmV33uG5GaqhcBCJ1c_9pf9P9+ZkOT_rtROuuOP4A@mail.gmail.com>

On Wed, Oct 2, 2013 at 7:28 PM, Randy Bush <randy at psg.com> wrote:
>> I am shocked that a pccw customer isn't being prefix-filtered.
>
> never happened before, right?

wait... let me think... nope, never.


From randy at psg.com  Wed Oct  2 23:44:11 2013
From: randy at psg.com (Randy Bush)
Date: Thu, 03 Oct 2013 08:44:11 +0900
Subject: Someone from PCCW NOC here ?
In-Reply-To: <CAL9jLaahbCmV33uG5GaqhcBCJ1c_9pf9P9+ZkOT_rtROuuOP4A@mail.gmail.com>
References: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>
 <CAL9jLaaHTo00m0aRoRKvaG8PMhScQoge_qRV=sVuXxEMkMAMSg@mail.gmail.com>
 <m2vc1fuub4.wl%randy@psg.com>
 <CAL9jLaahbCmV33uG5GaqhcBCJ1c_9pf9P9+ZkOT_rtROuuOP4A@mail.gmail.com>
Message-ID: <m2r4c3utkk.wl%randy@psg.com>

>>> I am shocked that a pccw customer isn't being prefix-filtered.
>> never happened before, right?
> wait... let me think... nope, never.

if they do it again, someone should make a youtube of it

randy


From morrowc.lists at gmail.com  Wed Oct  2 23:45:15 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 2 Oct 2013 19:45:15 -0400
Subject: Someone from PCCW NOC here ?
In-Reply-To: <m2r4c3utkk.wl%randy@psg.com>
References: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>
 <CAL9jLaaHTo00m0aRoRKvaG8PMhScQoge_qRV=sVuXxEMkMAMSg@mail.gmail.com>
 <m2vc1fuub4.wl%randy@psg.com>
 <CAL9jLaahbCmV33uG5GaqhcBCJ1c_9pf9P9+ZkOT_rtROuuOP4A@mail.gmail.com>
 <m2r4c3utkk.wl%randy@psg.com>
Message-ID: <CAL9jLaY5LEk-LuL_ATC9dSzuAgD0qZnZt+pi_xb2B87PbiDeLw@mail.gmail.com>

On Wed, Oct 2, 2013 at 7:44 PM, Randy Bush <randy at psg.com> wrote:
>>>> I am shocked that a pccw customer isn't being prefix-filtered.
>>> never happened before, right?
>> wait... let me think... nope, never.
>
> if they do it again, someone should make a youtube of it

untold dozens of views I suspect that would get!


From wbailey at satelliteintelligencegroup.com  Wed Oct  2 23:50:43 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Wed, 2 Oct 2013 23:50:43 +0000
Subject: Someone from PCCW NOC here ?
In-Reply-To: <CAL9jLaY5LEk-LuL_ATC9dSzuAgD0qZnZt+pi_xb2B87PbiDeLw@mail.gmail.com>
References: <CA+z-_EWxNJgrprUj=akbzVZJ3OKFrGFE=nyj1rFf7cW2F8YNOQ@mail.gmail.com>
 <CAL9jLaaHTo00m0aRoRKvaG8PMhScQoge_qRV=sVuXxEMkMAMSg@mail.gmail.com>
 <m2vc1fuub4.wl%randy@psg.com>
 <CAL9jLaahbCmV33uG5GaqhcBCJ1c_9pf9P9+ZkOT_rtROuuOP4A@mail.gmail.com>
 <m2r4c3utkk.wl%randy@psg.com>,
 <CAL9jLaY5LEk-LuL_ATC9dSzuAgD0qZnZt+pi_xb2B87PbiDeLw@mail.gmail.com>
Message-ID: <4unj29fxng6ihi5s87tokjeq.1380757840257@email.android.com>

Add their hold music as the background track. I'm surprised you guys are surprised. ;)


Sent from my Mobile Device.


-------- Original message --------
From: Christopher Morrow <morrowc.lists at gmail.com>
Date: 10/03/2013 7:49 AM (GMT+08:00)
To: Randy Bush <randy at psg.com>
Cc: NANOG <nanog at nanog.org>,Carlos Martinez <carlos at lacnic.net>
Subject: Re: Someone from PCCW NOC here ?


On Wed, Oct 2, 2013 at 7:44 PM, Randy Bush <randy at psg.com> wrote:
>>>> I am shocked that a pccw customer isn't being prefix-filtered.
>>> never happened before, right?
>> wait... let me think... nope, never.
>
> if they do it again, someone should make a youtube of it

untold dozens of views I suspect that would get!


From emile.aben at ripe.net  Thu Oct  3 04:58:53 2013
From: emile.aben at ripe.net (Emile Aben)
Date: Thu, 03 Oct 2013 06:58:53 +0200
Subject: IP Fragmentation - Not reliable over the Internet?
In-Reply-To: <m2eh9ai0bl.wl%randy@psg.com>
References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com>
 <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net>
 <20130827112436.GA29165@pob.ytti.fi>
 <DCBA21B8-BEB5-445D-8E9E-8BD8C2B09627@ufp.org>
 <521F0530.2000105@NLnetLabs.nl> <m2ob8fjspp.wl%randy@psg.com>
 <5220ADF7.6030204@NLnetLabs.nl> <5221B135.9010707@ripe.net>
 <m2eh9ai0bl.wl%randy@psg.com>
Message-ID: <524CF98D.5000809@ripe.net>

On 31/08/2013 13:09, Randy Bush wrote:
>>>> i wonder if this is correlated with the high number of probes being
>>>> behind nats.
>>
>> Maybe this provides a bit of insight:
>> From a test last week from all RIPE Atlas probes to a single "known
>> good" MTU 1500 host I compared probes where I had both a ping test with
>> ipv4.len 1020 and ipv4.len 1502.
>> behind NAT probes: 12%  1020 bytes ping worked while 1502 failed
>> non-NATted probes:  6%    ""
> 
> this needs publication on your adventure game of a web site, please.  it
> will seriously 'inform' some discussion going back and forth on ietf
> lists.

This is now published on RIPE Labs. For the adventurous:
https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters

regards,
Emile Aben
RIPE NCC



From randy at psg.com  Thu Oct  3 05:51:40 2013
From: randy at psg.com (Randy Bush)
Date: Thu, 03 Oct 2013 14:51:40 +0900
Subject: IP Fragmentation - Not reliable over the Internet?
In-Reply-To: <524CF98D.5000809@ripe.net>
References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com>
 <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net>
 <20130827112436.GA29165@pob.ytti.fi>
 <DCBA21B8-BEB5-445D-8E9E-8BD8C2B09627@ufp.org>
 <521F0530.2000105@NLnetLabs.nl> <m2ob8fjspp.wl%randy@psg.com>
 <5220ADF7.6030204@NLnetLabs.nl> <5221B135.9010707@ripe.net>
 <m2eh9ai0bl.wl%randy@psg.com> <524CF98D.5000809@ripe.net>
Message-ID: <m2mwmquck3.wl%randy@psg.com>

>> this needs publication on your adventure game of a web site, please.  it
>> will seriously 'inform' some discussion going back and forth on ietf
>> lists.
> 
> This is now published on RIPE Labs. For the adventurous:
> https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters

some hours back, i posted the url to the ietf list arguing frag

thanks a million

randy


From joquendo at e-fensive.net  Thu Oct  3 15:55:32 2013
From: joquendo at e-fensive.net (J. Oquendo)
Date: Thu, 3 Oct 2013 10:55:32 -0500
Subject: CBL Abuse
Message-ID: <20131003155532.GA93142@e-fensive.net>


Does someone know of a direct contact with someone at
cbl.abuse.org have a quick question/comment/concern I would
like to address that WILL get lost in "forms" method of
"contact us."


-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

42B0 5A53 6505 6638 44BB  3943 2BF7 D83F 210A 95AF
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF


From fergdawgster at mykolab.com  Thu Oct  3 16:37:32 2013
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Thu, 03 Oct 2013 09:37:32 -0700
Subject: CBL Abuse
In-Reply-To: <20131003155532.GA93142@e-fensive.net>
References: <20131003155532.GA93142@e-fensive.net>
Message-ID: <524D9D4C.7070502@mykolab.com>

On 10/3/2013 8:55 AM, J. Oquendo wrote:

>
> Does someone know of a direct contact with someone at
> cbl.abuse.org have a quick question/comment/concern I would
> like to address that WILL get lost in "forms" method of
> "contact us."
>
>

Answering off-list.

- ferg


-- 
Paul Ferguson
Vice President, Threat Intelligence
Internet Identity, Tacoma, Washington  USA
IID --> "Connect and Collaborate" --> www.internetidentity.com


From cook at cookreport.com  Fri Oct  4 16:09:54 2013
From: cook at cookreport.com (Gordon Cook)
Date: Fri, 4 Oct 2013 12:09:54 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
Message-ID: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>


Dear NANOG

The Ecuadoran government has via the FLOK society hired Michel Bauwens of the P2p foundation to lead a two year long efforts to revision the ecudoran economy along the lines of a commons oriented collaborative society.  I am very interested in the program yet i have NEVER been able to connect to their web site.   At the end of two hours of trouble shooting with apple i was advised to call verizon.  I am a FiOS customer on a two year contact.  The traceroute below confirmed that the fault is in verizons network.  The verizon tech agreed otherwise i never would have gotten the trouble ticket

my verizon trouble ticket is NJ DQ04PWR9.

Can someone tell me what number to call to pursue resolution of this trouble ticket?

as of 12:04 eastern time i still cannot connect

24 hours was the promise
14 of the 24 have elapsed

> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte packets
>  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms  17.508 ms  7.316 ms
>  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms !N *
>  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101 ms !N
>  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms !N *
>  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms !N *  8.846 ms !N
> 
> 
> 
> Traceroute has started?
> 
> traceroute to 200.10.150.169 (200.10.150.169), 64 hops max, 72 byte packets
>  1  192.168.1.1 (192.168.1.1)  0.622 ms  0.305 ms  0.361 ms
>  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  6.633 ms  4.892 ms  4.809 ms
>  3  * * *
>  4  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  10.441 ms !N * *
>  5  * * *
>  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.932 ms !N * *
>  7  * * *
>  8  * * *
>  9  * * *
> 10  * * *
> 11  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.765 ms !N * *
> 12  * * *
> 13  * * *=


Lookup has started?

Trying "floksociety.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13700
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;floksociety.org.                      IN        ANY

;; ANSWER SECTION:
floksociety.org.           600      IN        A         200.10.150.169
floksociety.org.           3600    IN        MX      10 mail.floksociety.org.
floksociety.org.           3600    IN        NS       ns57.domaincontrol.com.
floksociety.org.           3600    IN        NS       ns58.domaincontrol.com.
floksociety.org.           3600    IN        SOA    ns57.domaincontrol.com. dns.jomax.net. 2013092400 28800 7200 604800 600

Received 174 bytes from 8.8.8.8#53 in 139 ms
=============================================================
The COOK Report on Internet Protocol, (PSTN) 609 882-2572 
Back Issues: http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61  
 Cook's Collaborative Edge Blog 
 http://www.cookreport.com/wp/
  Subscription info: http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
=============================================================











From mhuff at ox.com  Fri Oct  4 16:17:51 2013
From: mhuff at ox.com (Matthew Huff)
Date: Fri, 4 Oct 2013 12:17:51 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
Message-ID: <483E6B0272B0284BA86D7596C40D29F9021177E87D94@PUR-EXCH07.ox.com>

My traceroute goes through, but we don't go through Verizon. However, the web server is returning an error that it is unavailable. It's possible that the destination web server has a geo location plug in that stops access from foreign locations, or that their server is down. 



[root at lancaster ~]# traceroute -I 200.10.150.169   
traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte packets
 1  129.77.108.252 (129.77.108.252)  0.345 ms  0.384 ms  0.442 ms
 2  switch-user1.ox.com (129.77.154.253)  0.408 ms  0.523 ms  0.585 ms
 3  rtr-inet2.ox.com (129.77.1.252)  3.394 ms  3.437 ms  3.464 ms
 4  129.77.3.254 (129.77.3.254)  0.515 ms  0.517 ms  0.541 ms
 5  189d20f9.cst.lightpath.net (24.157.32.249)  4.909 ms  4.923 ms  4.922 ms
 6  18267502.cst.lightpath.net (24.38.117.2)  7.318 ms  9.900 ms  9.889 ms
 7   (69.74.203.201)  9.877 ms  9.444 ms  9.434 ms
 8  * * *
 9  adsl-065-015-003-181.sip.mia.bellsouth.net (65.15.3.181)  9.455 ms * *
10  * * *
11  xe-9-1-2.edge2.Newark1.Level3.net (4.31.45.173)  8.378 ms  14.395 ms  14.244 ms
12  ae-32-52.ebr2.Newark1.Level3.net (4.69.156.62)  39.992 ms  42.318 ms  42.303 ms
13  ae-4-4.ebr2.Washington1.Level3.net (4.69.132.101)  42.283 ms  42.284 ms  42.280 ms
14  ae-62-62.csw1.Washington1.Level3.net (4.69.134.146)  50.599 ms  50.594 ms  50.586 ms
15  ae-61-61.ebr1.washington1.level3.net (4.69.134.129)  40.769 ms  43.276 ms *
16  ae-2-2.ebr3.atlanta2.level3.net (4.69.132.85)  43.293 ms  39.230 ms  38.957 ms
17  ae-73-73.ebr2.Atlanta2.Level3.net (4.69.148.254)  38.942 ms  38.942 ms  38.501 ms
18  ae-2-2.ebr2.miami1.level3.net (4.69.140.141)  39.404 ms  37.772 ms  37.487 ms
19  ae-2-52.edge1.Miami2.Level3.net (4.69.138.107)  50.685 ms  50.674 ms  50.568 ms
20  telefonica.edge1.miami2.level3.net (4.71.212.118)  62.446 ms  60.038 ms  59.416 ms
21  176.52.251.189 (176.52.251.189)  57.850 ms  58.637 ms  58.541 ms
22  176.52.252.66 (176.52.252.66)  94.381 ms  97.548 ms  99.258 ms
23  * * *
24  * * *
25  * * *
26  host-186-5-116-193.telconet.net (186.5.116.193)  118.811 ms  118.803 ms  118.808 ms
27  host-186-101-89-42.telconet.net (186.101.89.42)  98.612 ms  98.589 ms  98.605 ms
28  200.10.150.169 (200.10.150.169)  98.534 ms  98.564 ms  98.505 ms

<root at newton> dig +short www.floksociety.org.
200.10.150.169

<root at newton> telnet 200.10.150.169 80
Trying 200.10.150.169...
Connected to 200.10.150.169.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 503 Service Unavailable
Server: Varnish
Content-Type: text/html; charset=utf-8
Retry-After: 5
Content-Length: 418
Accept-Ranges: bytes
Date: Fri, 04 Oct 2013 16:12:33 GMT
Connection: close


<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <title>503 Service Unavailable</title>
  </head>
  <body>
    <h1>Error 503 Service Unavailable</h1>
    <p>Service Unavailable</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 477990820</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>
Connection to 200.10.150.169 closed by foreign host.

> -----Original Message-----
> From: Gordon Cook [mailto:cook at cookreport.com]
> Sent: Friday, October 04, 2013 12:10 PM
> To: nanog at nanog.org list
> Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by
> accident or on purpose?
> 
> 
> Dear NANOG
> 
> The Ecuadoran government has via the FLOK society hired Michel Bauwens of the P2p
> foundation to lead a two year long efforts to revision the ecudoran economy along the
> lines of a commons oriented collaborative society.  I am very interested in the program
> yet i have NEVER been able to connect to their web site.   At the end of two hours of
> trouble shooting with apple i was advised to call verizon.  I am a FiOS customer on a two
> year contact.  The traceroute below confirmed that the fault is in verizons network.  The
> verizon tech agreed otherwise i never would have gotten the trouble ticket
> 
> my verizon trouble ticket is NJ DQ04PWR9.
> 
> Can someone tell me what number to call to pursue resolution of this trouble ticket?
> 
> as of 12:04 eastern time i still cannot connect
> 
> 24 hours was the promise
> 14 of the 24 have elapsed
> 
> > traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte packets
> >  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
> >  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms  17.508 ms  7.316 ms
> >  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms !N *
> >  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101 ms !N
> >  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms !N *
> >  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms !N *  8.846 ms !N
> >
> >
> >
> > Traceroute has started...
> >
> > traceroute to 200.10.150.169 (200.10.150.169), 64 hops max, 72 byte packets
> >  1  192.168.1.1 (192.168.1.1)  0.622 ms  0.305 ms  0.361 ms
> >  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  6.633 ms  4.892 ms  4.809 ms
> >  3  * * *
> >  4  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  10.441 ms !N * *
> >  5  * * *
> >  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.932 ms !N * *
> >  7  * * *
> >  8  * * *
> >  9  * * *
> > 10  * * *
> > 11  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.765 ms !N * *
> > 12  * * *
> > 13  * * *=
> 
> 
> Lookup has started...
> 
> Trying "floksociety.org"
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13700
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;floksociety.org.                      IN        ANY
> 
> ;; ANSWER SECTION:
> floksociety.org.           600      IN        A         200.10.150.169
> floksociety.org.           3600    IN        MX      10 mail.floksociety.org.
> floksociety.org.           3600    IN        NS       ns57.domaincontrol.com.
> floksociety.org.           3600    IN        NS       ns58.domaincontrol.com.
> floksociety.org.           3600    IN        SOA    ns57.domaincontrol.com. dns.jomax.net.
> 2013092400 28800 7200 604800 600
> 
> Received 174 bytes from 8.8.8.8#53 in 139 ms
> =============================================================
> The COOK Report on Internet Protocol, (PSTN) 609 882-2572
> Back Issues:
> http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61
>  Cook's Collaborative Edge Blog
>  http://www.cookreport.com/wp/
>   Subscription info:
> http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
> =============================================================
> 
> 
> 
> 
> 
> 
> 
> 
> 



From brandon.galbraith at gmail.com  Fri Oct  4 16:28:03 2013
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Fri, 4 Oct 2013 11:28:03 -0500
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9021177E87D94@PUR-EXCH07.ox.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <483E6B0272B0284BA86D7596C40D29F9021177E87D94@PUR-EXCH07.ox.com>
Message-ID: <CADE4tYUmFay==00SEdRBeiGSkfTAHeNxX4aGHgv0uQDD8zo85w@mail.gmail.com>

Site appears up and available, over Comcast Business fiber and Cogent from
Chicago (using Chrome 28).


On Fri, Oct 4, 2013 at 11:17 AM, Matthew Huff <mhuff at ox.com> wrote:

> My traceroute goes through, but we don't go through Verizon. However, the
> web server is returning an error that it is unavailable. It's possible that
> the destination web server has a geo location plug in that stops access
> from foreign locations, or that their server is down.
>
>
>
> [root at lancaster ~]# traceroute -I 200.10.150.169
> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte packets
>  1  129.77.108.252 (129.77.108.252)  0.345 ms  0.384 ms  0.442 ms
>  2  switch-user1.ox.com (129.77.154.253)  0.408 ms  0.523 ms  0.585 ms
>  3  rtr-inet2.ox.com (129.77.1.252)  3.394 ms  3.437 ms  3.464 ms
>  4  129.77.3.254 (129.77.3.254)  0.515 ms  0.517 ms  0.541 ms
>  5  189d20f9.cst.lightpath.net (24.157.32.249)  4.909 ms  4.923 ms  4.922
> ms
>  6  18267502.cst.lightpath.net (24.38.117.2)  7.318 ms  9.900 ms  9.889 ms
>  7   (69.74.203.201)  9.877 ms  9.444 ms  9.434 ms
>  8  * * *
>  9  adsl-065-015-003-181.sip.mia.bellsouth.net (65.15.3.181)  9.455 ms * *
> 10  * * *
> 11  xe-9-1-2.edge2.Newark1.Level3.net (4.31.45.173)  8.378 ms  14.395 ms
>  14.244 ms
> 12  ae-32-52.ebr2.Newark1.Level3.net (4.69.156.62)  39.992 ms  42.318 ms
>  42.303 ms
> 13  ae-4-4.ebr2.Washington1.Level3.net (4.69.132.101)  42.283 ms  42.284
> ms  42.280 ms
> 14  ae-62-62.csw1.Washington1.Level3.net (4.69.134.146)  50.599 ms
>  50.594 ms  50.586 ms
> 15  ae-61-61.ebr1.washington1.level3.net (4.69.134.129)  40.769 ms
>  43.276 ms *
> 16  ae-2-2.ebr3.atlanta2.level3.net (4.69.132.85)  43.293 ms  39.230 ms
>  38.957 ms
> 17  ae-73-73.ebr2.Atlanta2.Level3.net (4.69.148.254)  38.942 ms  38.942
> ms  38.501 ms
> 18  ae-2-2.ebr2.miami1.level3.net (4.69.140.141)  39.404 ms  37.772 ms
>  37.487 ms
> 19  ae-2-52.edge1.Miami2.Level3.net (4.69.138.107)  50.685 ms  50.674 ms
>  50.568 ms
> 20  telefonica.edge1.miami2.level3.net (4.71.212.118)  62.446 ms  60.038
> ms  59.416 ms
> 21  176.52.251.189 (176.52.251.189)  57.850 ms  58.637 ms  58.541 ms
> 22  176.52.252.66 (176.52.252.66)  94.381 ms  97.548 ms  99.258 ms
> 23  * * *
> 24  * * *
> 25  * * *
> 26  host-186-5-116-193.telconet.net (186.5.116.193)  118.811 ms  118.803
> ms  118.808 ms
> 27  host-186-101-89-42.telconet.net (186.101.89.42)  98.612 ms  98.589 ms
>  98.605 ms
> 28  200.10.150.169 (200.10.150.169)  98.534 ms  98.564 ms  98.505 ms
>
> <root at newton> dig +short www.floksociety.org.
> 200.10.150.169
>
> <root at newton> telnet 200.10.150.169 80
> Trying 200.10.150.169...
> Connected to 200.10.150.169.
> Escape character is '^]'.
> GET / HTTP/1.0
>
> HTTP/1.1 503 Service Unavailable
> Server: Varnish
> Content-Type: text/html; charset=utf-8
> Retry-After: 5
> Content-Length: 418
> Accept-Ranges: bytes
> Date: Fri, 04 Oct 2013 16:12:33 GMT
> Connection: close
>
>
> <?xml version="1.0" encoding="utf-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html>
>   <head>
>     <title>503 Service Unavailable</title>
>   </head>
>   <body>
>     <h1>Error 503 Service Unavailable</h1>
>     <p>Service Unavailable</p>
>     <h3>Guru Meditation:</h3>
>     <p>XID: 477990820</p>
>     <hr>
>     <p>Varnish cache server</p>
>   </body>
> </html>
> Connection to 200.10.150.169 closed by foreign host.
>
> > -----Original Message-----
> > From: Gordon Cook [mailto:cook at cookreport.com]
> > Sent: Friday, October 04, 2013 12:10 PM
> > To: nanog at nanog.org list
> > Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
> FLOKsociety.org by
> > accident or on purpose?
> >
> >
> > Dear NANOG
> >
> > The Ecuadoran government has via the FLOK society hired Michel Bauwens
> of the P2p
> > foundation to lead a two year long efforts to revision the ecudoran
> economy along the
> > lines of a commons oriented collaborative society.  I am very interested
> in the program
> > yet i have NEVER been able to connect to their web site.   At the end of
> two hours of
> > trouble shooting with apple i was advised to call verizon.  I am a FiOS
> customer on a two
> > year contact.  The traceroute below confirmed that the fault is in
> verizons network.  The
> > verizon tech agreed otherwise i never would have gotten the trouble
> ticket
> >
> > my verizon trouble ticket is NJ DQ04PWR9.
> >
> > Can someone tell me what number to call to pursue resolution of this
> trouble ticket?
> >
> > as of 12:04 eastern time i still cannot connect
> >
> > 24 hours was the promise
> > 14 of the 24 have elapsed
> >
> > > traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte
> packets
> > >  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
> > >  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
>  17.508 ms  7.316 ms
> > >  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482
> ms !N *
> > >  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)
>  7.101 ms !N
> > >  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239
> ms !N *
> > >  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms
> !N *  8.846 ms !N
> > >
> > >
> > >
> > > Traceroute has started...
> > >
> > > traceroute to 200.10.150.169 (200.10.150.169), 64 hops max, 72 byte
> packets
> > >  1  192.168.1.1 (192.168.1.1)  0.622 ms  0.305 ms  0.361 ms
> > >  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  6.633 ms
>  4.892 ms  4.809 ms
> > >  3  * * *
> > >  4  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  10.441
> ms !N * *
> > >  5  * * *
> > >  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.932 ms
> !N * *
> > >  7  * * *
> > >  8  * * *
> > >  9  * * *
> > > 10  * * *
> > > 11  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.765 ms
> !N * *
> > > 12  * * *
> > > 13  * * *=
> >
> >
> > Lookup has started...
> >
> > Trying "floksociety.org"
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13700
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;floksociety.org.                      IN        ANY
> >
> > ;; ANSWER SECTION:
> > floksociety.org.           600      IN        A         200.10.150.169
> > floksociety.org.           3600    IN        MX      10
> mail.floksociety.org.
> > floksociety.org.           3600    IN        NS
> ns57.domaincontrol.com.
> > floksociety.org.           3600    IN        NS
> ns58.domaincontrol.com.
> > floksociety.org.           3600    IN        SOA
> ns57.domaincontrol.com. dns.jomax.net.
> > 2013092400 28800 7200 604800 600
> >
> > Received 174 bytes from 8.8.8.8#53 in 139 ms
> > =============================================================
> > The COOK Report on Internet Protocol, (PSTN) 609 882-2572
> > Back Issues:
> >
> http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61
> >  Cook's Collaborative Edge Blog
> >  http://www.cookreport.com/wp/
> >   Subscription info:
> >
> http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
> > =============================================================
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>

From bill at herrin.us  Fri Oct  4 16:30:01 2013
From: bill at herrin.us (William Herrin)
Date: Fri, 4 Oct 2013 12:30:01 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
Message-ID: <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>

On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:
>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte packets
>>  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms  17.508 ms  7.316 ms
>>  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms !N *
>>  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101 ms !N
>>  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms !N *
>>  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms !N *  8.846 ms !N

Inaccessible via FIOS Washington DC too:

traceroute -T -p 80 200.10.150.169
traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte packets
 1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
1.595 ms  1.562 ms
 2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N * *

Correctly accessible via Cox, Qwest, Sprint and others, but the
network path is really slow and really long.

The border is consistently with telefonica-wholesale.net and then
telconet.net. Beyond the border there are badly behaving routers,
including ones configured with RFC 1918 addresses. The addressable
routers are reachable via Verizon, just not the last hop.

traceroute -T -p 80 200.10.150.169
traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte packets
 1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
 2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
 3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  9.424 ms
 4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms  9.140 ms
 5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
ms  8.929 ms
 6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
 7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
 8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
52.415 ms  52.421 ms
 9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
60.397 ms  60.378 ms
10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms  58.407
ms  58.392 ms
11  * * *
12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms  47.435 ms
13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
(94.142.119.38)  60.181 ms
Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
125.888 ms
14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net (94.142.119.233)
 67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
(213.140.37.77)  63.435 ms
Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
141.873 ms
15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
(176.52.249.241)  64.668 ms
16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms  117.934 ms
17  * * *
18  * * *
19  * * *
20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
120.967 ms  115.040 ms
21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
125.164 ms  119.520 ms
22  * * *
23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms  244.845 ms





-- 
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 chris at marget.com  Fri Oct  4 16:35:37 2013
From: chris at marget.com (Chris Marget)
Date: Fri, 4 Oct 2013 12:35:37 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CADE4tYUmFay==00SEdRBeiGSkfTAHeNxX4aGHgv0uQDD8zo85w@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <483E6B0272B0284BA86D7596C40D29F9021177E87D94@PUR-EXCH07.ox.com>
 <CADE4tYUmFay==00SEdRBeiGSkfTAHeNxX4aGHgv0uQDD8zo85w@mail.gmail.com>
Message-ID: <CAAG5dDDxedkUkeVHb0uT0ogB0Q61ibtyiKiQ1fr1wxdSGobPDA@mail.gmail.com>

200.10.150.169 is reachable from AS2828 and from AS20115, but not from
AS22394 (Verizon Wireless)


On Fri, Oct 4, 2013 at 12:28 PM, Brandon Galbraith <
brandon.galbraith at gmail.com> wrote:

> Site appears up and available, over Comcast Business fiber and Cogent from
> Chicago (using Chrome 28).
>
>
> On Fri, Oct 4, 2013 at 11:17 AM, Matthew Huff <mhuff at ox.com> wrote:
>
> > My traceroute goes through, but we don't go through Verizon. However, the
> > web server is returning an error that it is unavailable. It's possible
> that
> > the destination web server has a geo location plug in that stops access
> > from foreign locations, or that their server is down.
> >
> >
> >
> > [root at lancaster ~]# traceroute -I 200.10.150.169
> > traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte
> packets
> >  1  129.77.108.252 (129.77.108.252)  0.345 ms  0.384 ms  0.442 ms
> >  2  switch-user1.ox.com (129.77.154.253)  0.408 ms  0.523 ms  0.585 ms
> >  3  rtr-inet2.ox.com (129.77.1.252)  3.394 ms  3.437 ms  3.464 ms
> >  4  129.77.3.254 (129.77.3.254)  0.515 ms  0.517 ms  0.541 ms
> >  5  189d20f9.cst.lightpath.net (24.157.32.249)  4.909 ms  4.923 ms
>  4.922
> > ms
> >  6  18267502.cst.lightpath.net (24.38.117.2)  7.318 ms  9.900 ms  9.889
> ms
> >  7   (69.74.203.201)  9.877 ms  9.444 ms  9.434 ms
> >  8  * * *
> >  9  adsl-065-015-003-181.sip.mia.bellsouth.net (65.15.3.181)  9.455 ms
> * *
> > 10  * * *
> > 11  xe-9-1-2.edge2.Newark1.Level3.net (4.31.45.173)  8.378 ms  14.395 ms
> >  14.244 ms
> > 12  ae-32-52.ebr2.Newark1.Level3.net (4.69.156.62)  39.992 ms  42.318 ms
> >  42.303 ms
> > 13  ae-4-4.ebr2.Washington1.Level3.net (4.69.132.101)  42.283 ms  42.284
> > ms  42.280 ms
> > 14  ae-62-62.csw1.Washington1.Level3.net (4.69.134.146)  50.599 ms
> >  50.594 ms  50.586 ms
> > 15  ae-61-61.ebr1.washington1.level3.net (4.69.134.129)  40.769 ms
> >  43.276 ms *
> > 16  ae-2-2.ebr3.atlanta2.level3.net (4.69.132.85)  43.293 ms  39.230 ms
> >  38.957 ms
> > 17  ae-73-73.ebr2.Atlanta2.Level3.net (4.69.148.254)  38.942 ms  38.942
> > ms  38.501 ms
> > 18  ae-2-2.ebr2.miami1.level3.net (4.69.140.141)  39.404 ms  37.772 ms
> >  37.487 ms
> > 19  ae-2-52.edge1.Miami2.Level3.net (4.69.138.107)  50.685 ms  50.674 ms
> >  50.568 ms
> > 20  telefonica.edge1.miami2.level3.net (4.71.212.118)  62.446 ms  60.038
> > ms  59.416 ms
> > 21  176.52.251.189 (176.52.251.189)  57.850 ms  58.637 ms  58.541 ms
> > 22  176.52.252.66 (176.52.252.66)  94.381 ms  97.548 ms  99.258 ms
> > 23  * * *
> > 24  * * *
> > 25  * * *
> > 26  host-186-5-116-193.telconet.net (186.5.116.193)  118.811 ms  118.803
> > ms  118.808 ms
> > 27  host-186-101-89-42.telconet.net (186.101.89.42)  98.612 ms  98.589
> ms
> >  98.605 ms
> > 28  200.10.150.169 (200.10.150.169)  98.534 ms  98.564 ms  98.505 ms
> >
> > <root at newton> dig +short www.floksociety.org.
> > 200.10.150.169
> >
> > <root at newton> telnet 200.10.150.169 80
> > Trying 200.10.150.169...
> > Connected to 200.10.150.169.
> > Escape character is '^]'.
> > GET / HTTP/1.0
> >
> > HTTP/1.1 503 Service Unavailable
> > Server: Varnish
> > Content-Type: text/html; charset=utf-8
> > Retry-After: 5
> > Content-Length: 418
> > Accept-Ranges: bytes
> > Date: Fri, 04 Oct 2013 16:12:33 GMT
> > Connection: close
> >
> >
> > <?xml version="1.0" encoding="utf-8"?>
> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> >  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> > <html>
> >   <head>
> >     <title>503 Service Unavailable</title>
> >   </head>
> >   <body>
> >     <h1>Error 503 Service Unavailable</h1>
> >     <p>Service Unavailable</p>
> >     <h3>Guru Meditation:</h3>
> >     <p>XID: 477990820</p>
> >     <hr>
> >     <p>Varnish cache server</p>
> >   </body>
> > </html>
> > Connection to 200.10.150.169 closed by foreign host.
> >
> > > -----Original Message-----
> > > From: Gordon Cook [mailto:cook at cookreport.com]
> > > Sent: Friday, October 04, 2013 12:10 PM
> > > To: nanog at nanog.org list
> > > Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
> > FLOKsociety.org by
> > > accident or on purpose?
> > >
> > >
> > > Dear NANOG
> > >
> > > The Ecuadoran government has via the FLOK society hired Michel Bauwens
> > of the P2p
> > > foundation to lead a two year long efforts to revision the ecudoran
> > economy along the
> > > lines of a commons oriented collaborative society.  I am very
> interested
> > in the program
> > > yet i have NEVER been able to connect to their web site.   At the end
> of
> > two hours of
> > > trouble shooting with apple i was advised to call verizon.  I am a FiOS
> > customer on a two
> > > year contact.  The traceroute below confirmed that the fault is in
> > verizons network.  The
> > > verizon tech agreed otherwise i never would have gotten the trouble
> > ticket
> > >
> > > my verizon trouble ticket is NJ DQ04PWR9.
> > >
> > > Can someone tell me what number to call to pursue resolution of this
> > trouble ticket?
> > >
> > > as of 12:04 eastern time i still cannot connect
> > >
> > > 24 hours was the promise
> > > 14 of the 24 have elapsed
> > >
> > > > traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte
> > packets
> > > >  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
> > > >  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
> >  17.508 ms  7.316 ms
> > > >  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482
> > ms !N *
> > > >  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)
> >  7.101 ms !N
> > > >  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239
> > ms !N *
> > > >  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823
> ms
> > !N *  8.846 ms !N
> > > >
> > > >
> > > >
> > > > Traceroute has started...
> > > >
> > > > traceroute to 200.10.150.169 (200.10.150.169), 64 hops max, 72 byte
> > packets
> > > >  1  192.168.1.1 (192.168.1.1)  0.622 ms  0.305 ms  0.361 ms
> > > >  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  6.633 ms
> >  4.892 ms  4.809 ms
> > > >  3  * * *
> > > >  4  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  10.441
> > ms !N * *
> > > >  5  * * *
> > > >  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.932
> ms
> > !N * *
> > > >  7  * * *
> > > >  8  * * *
> > > >  9  * * *
> > > > 10  * * *
> > > > 11  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.765
> ms
> > !N * *
> > > > 12  * * *
> > > > 13  * * *=
> > >
> > >
> > > Lookup has started...
> > >
> > > Trying "floksociety.org"
> > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13700
> > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
> > >
> > > ;; QUESTION SECTION:
> > > ;floksociety.org.                      IN        ANY
> > >
> > > ;; ANSWER SECTION:
> > > floksociety.org.           600      IN        A         200.10.150.169
> > > floksociety.org.           3600    IN        MX      10
> > mail.floksociety.org.
> > > floksociety.org.           3600    IN        NS
> > ns57.domaincontrol.com.
> > > floksociety.org.           3600    IN        NS
> > ns58.domaincontrol.com.
> > > floksociety.org.           3600    IN        SOA
> > ns57.domaincontrol.com. dns.jomax.net.
> > > 2013092400 28800 7200 604800 600
> > >
> > > Received 174 bytes from 8.8.8.8#53 in 139 ms
> > > =============================================================
> > > The COOK Report on Internet Protocol, (PSTN) 609 882-2572
> > > Back Issues:
> > >
> >
> http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61
> > >  Cook's Collaborative Edge Blog
> > >  http://www.cookreport.com/wp/
> > >   Subscription info:
> > >
> >
> http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
> > > =============================================================
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>

From cook at cookreport.com  Fri Oct  4 16:40:54 2013
From: cook at cookreport.com (Gordon Cook)
Date: Fri, 4 Oct 2013 12:40:54 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
Message-ID: <AD6AC0A9-42BD-4228-B9EF-C6A0486702E4@cookreport.com>

Thank you Bill

extremely helpful

if via FiOS from DC you cannot get through does his look like an intentional move by verizobn to black hole this site????

how to determine that?

would like to be sure before i start raising hell elsewhere


I have tried to connect all week long never once succeeded.

advise??

any verizon people here willing to help?
=============================================================
The COOK Report on Internet Protocol, (PSTN) 609 882-2572 
Back Issues: http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61  
 Cook's Collaborative Edge Blog 
 http://www.cookreport.com/wp/
  Subscription info: http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
=============================================================










On Oct 4, 2013, at 12:30 PM, William Herrin <bill at herrin.us> wrote:

> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:
>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte packets
>>> 1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>> 2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms  17.508 ms  7.316 ms
>>> 3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms !N *
>>> 4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101 ms !N
>>> 5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms !N *
>>> 6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms !N *  8.846 ms !N
> 
> Inaccessible via FIOS Washington DC too:
> 
> traceroute -T -p 80 200.10.150.169
> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte packets
> 1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
> 1.595 ms  1.562 ms
> 2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N * *
> 
> Correctly accessible via Cox, Qwest, Sprint and others, but the
> network path is really slow and really long.
> 
> The border is consistently with telefonica-wholesale.net and then
> telconet.net. Beyond the border there are badly behaving routers,
> including ones configured with RFC 1918 addresses. The addressable
> routers are reachable via Verizon, just not the last hop.
> 
> traceroute -T -p 80 200.10.150.169
> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte packets
> 1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
> 2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
> 3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  9.424 ms
> 4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms  9.140 ms
> 5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
> ms  8.929 ms
> 6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
> 7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
> 8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
> 52.415 ms  52.421 ms
> 9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
> 60.397 ms  60.378 ms
> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms  58.407
> ms  58.392 ms
> 11  * * *
> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms  47.435 ms
> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
> (94.142.119.38)  60.181 ms
> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
> 125.888 ms
> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net (94.142.119.233)
> 67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
> (213.140.37.77)  63.435 ms
> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
> 141.873 ms
> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
> (176.52.249.241)  64.668 ms
> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms  117.934 ms
> 17  * * *
> 18  * * *
> 19  * * *
> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
> 120.967 ms  115.040 ms
> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
> 125.164 ms  119.520 ms
> 22  * * *
> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms  244.845 ms
> 
> 
> 
> 
> 
> -- 
> 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 mfidelman at meetinghouse.net  Fri Oct  4 16:42:00 2013
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Fri, 04 Oct 2013 12:42:00 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
Message-ID: <524EEFD8.102@meetinghouse.net>

Also inaccessible from FIOS Boston:
new-host-2:~ mfidelman$ traceroute floksociety.org
traceroute to floksociety.org (200.10.150.169), 64 hops max, 52 byte packets
  1  wireless_broadband_router (192.168.1.1)  1.534 ms  0.853 ms 0.724 ms
  2  l100.bstnma-vfttp-84.verizon-gni.net (96.252.37.1)  7.619 ms 6.855 
ms  7.304 ms
  3  200.10.150.169 (200.10.150.169)  10.482 ms !N *^C

But just fine from our datacenter via xo.net.  And the web server is up 
- at least to a text browser (Lynx).

Also via Verizion cell network (Boston area).

Some kind of routing table glitch or peering issue, perhaps?


William Herrin wrote:
> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:
>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte packets
>>>   1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>>   2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms  17.508 ms  7.316 ms
>>>   3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms !N *
>>>   4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101 ms !N
>>>   5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms !N *
>>>   6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms !N *  8.846 ms !N
> Inaccessible via FIOS Washington DC too:
>
> traceroute -T -p 80 200.10.150.169
> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte packets
>   1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
> 1.595 ms  1.562 ms
>   2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N * *
>
> Correctly accessible via Cox, Qwest, Sprint and others, but the
> network path is really slow and really long.
>
> The border is consistently with telefonica-wholesale.net and then
> telconet.net. Beyond the border there are badly behaving routers,
> including ones configured with RFC 1918 addresses. The addressable
> routers are reachable via Verizon, just not the last hop.
>
> traceroute -T -p 80 200.10.150.169
> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte packets
>   1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
>   2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
>   3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  9.424 ms
>   4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms  9.140 ms
>   5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
> ms  8.929 ms
>   6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
>   7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
>   8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
> 52.415 ms  52.421 ms
>   9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
> 60.397 ms  60.378 ms
> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms  58.407
> ms  58.392 ms
> 11  * * *
> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms  47.435 ms
> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
> (94.142.119.38)  60.181 ms
> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
> 125.888 ms
> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net (94.142.119.233)
>   67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
> (213.140.37.77)  63.435 ms
> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
> 141.873 ms
> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
> (176.52.249.241)  64.668 ms
> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms  117.934 ms
> 17  * * *
> 18  * * *
> 19  * * *
> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
> 120.967 ms  115.040 ms
> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
> 125.164 ms  119.520 ms
> 22  * * *
> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms  244.845 ms
>
>
>
>
>


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra



From mfidelman at meetinghouse.net  Fri Oct  4 16:52:02 2013
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Fri, 04 Oct 2013 12:52:02 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <524EEFD8.102@meetinghouse.net>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <524EEFD8.102@meetinghouse.net>
Message-ID: <524EF232.5030105@meetinghouse.net>

My mistake - cell network is also blocked.  Stupid autocorrect changed 
floksociety to folksociety. Sigh....  Other info is correct.

Miles Fidelman wrote:
> Also inaccessible from FIOS Boston:
> new-host-2:~ mfidelman$ traceroute floksociety.org
> traceroute to floksociety.org (200.10.150.169), 64 hops max, 52 byte 
> packets
>  1  wireless_broadband_router (192.168.1.1)  1.534 ms  0.853 ms 0.724 ms
>  2  l100.bstnma-vfttp-84.verizon-gni.net (96.252.37.1)  7.619 ms 6.855 
> ms  7.304 ms
>  3  200.10.150.169 (200.10.150.169)  10.482 ms !N *^C
>
> But just fine from our datacenter via xo.net.  And the web server is 
> up - at least to a text browser (Lynx).
>
> Also via Verizion cell network (Boston area).
>
> Some kind of routing table glitch or peering issue, perhaps?
>
>
> William Herrin wrote:
>> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> 
>> wrote:
>>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 
>>>> byte packets
>>>>   1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>>>   2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1) 36.778 ms  
>>>> 17.508 ms  7.316 ms
>>>>   3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  
>>>> 6.482 ms !N *
>>>>   4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  
>>>> 7.101 ms !N
>>>>   5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  
>>>> 9.239 ms !N *
>>>>   6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 
>>>> ms !N *  8.846 ms !N
>> Inaccessible via FIOS Washington DC too:
>>
>> traceroute -T -p 80 200.10.150.169
>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte 
>> packets
>>   1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
>> 1.595 ms  1.562 ms
>>   2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250) 5.321 ms 
>> !N * *
>>
>> Correctly accessible via Cox, Qwest, Sprint and others, but the
>> network path is really slow and really long.
>>
>> The border is consistently with telefonica-wholesale.net and then
>> telconet.net. Beyond the border there are badly behaving routers,
>> including ones configured with RFC 1918 addresses. The addressable
>> routers are reachable via Verizon, just not the last hop.
>>
>> traceroute -T -p 80 200.10.150.169
>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte 
>> packets
>>   1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms 0.569 ms
>>   2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
>>   3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  
>> 9.424 ms
>>   4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms 9.226 ms  
>> 9.140 ms
>>   5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms 9.019
>> ms  8.929 ms
>>   6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
>>   7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
>>   8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66) 58.454 ms
>> 52.415 ms  52.421 ms
>>   9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
>> 60.397 ms  60.378 ms
>> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms 58.407
>> ms  58.392 ms
>> 11  * * *
>> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms 49.080 ms  
>> 47.435 ms
>> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
>> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
>> (94.142.119.38)  60.181 ms
>> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
>> 125.888 ms
>> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net (94.142.119.233)
>>   67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
>> (213.140.37.77)  63.435 ms
>> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
>> 141.873 ms
>> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
>> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
>> (176.52.249.241)  64.668 ms
>> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms 117.934 ms
>> 17  * * *
>> 18  * * *
>> 19  * * *
>> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
>> 120.967 ms  115.040 ms
>> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
>> 125.164 ms  119.520 ms
>> 22  * * *
>> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms 244.845 ms
>>
>>
>>
>>
>>
>
>


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra



From morrowc.lists at gmail.com  Fri Oct  4 16:54:33 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 4 Oct 2013 12:54:33 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <524EEFD8.102@meetinghouse.net>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <524EEFD8.102@meetinghouse.net>
Message-ID: <CAL9jLaYy7vJS77A-7ou5teE=mQ+nuj7YiJ1OPx+i-AaNwfzc_w@mail.gmail.com>

err.. nothing in the /24 is reachable from 701's perspective (so it
seems)... so I'd suspect that there's a routing problem with the /24,
in fact the surrounding /24's also seem to be having the same problem.

On Fri, Oct 4, 2013 at 12:42 PM, Miles Fidelman
<mfidelman at meetinghouse.net> wrote:
> Also inaccessible from FIOS Boston:
> new-host-2:~ mfidelman$ traceroute floksociety.org
> traceroute to floksociety.org (200.10.150.169), 64 hops max, 52 byte packets
>  1  wireless_broadband_router (192.168.1.1)  1.534 ms  0.853 ms 0.724 ms
>  2  l100.bstnma-vfttp-84.verizon-gni.net (96.252.37.1)  7.619 ms 6.855 ms
> 7.304 ms
>  3  200.10.150.169 (200.10.150.169)  10.482 ms !N *^C
>
> But just fine from our datacenter via xo.net.  And the web server is up - at
> least to a text browser (Lynx).
>
> Also via Verizion cell network (Boston area).
>
> Some kind of routing table glitch or peering issue, perhaps?
>
>
>
> William Herrin wrote:
>>
>> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:
>>>>
>>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte
>>>> packets
>>>>   1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>>>   2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
>>>> 17.508 ms  7.316 ms
>>>>   3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms
>>>> !N *
>>>>   4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101
>>>> ms !N
>>>>   5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms
>>>> !N *
>>>>   6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms
>>>> !N *  8.846 ms !N
>>
>> Inaccessible via FIOS Washington DC too:
>>
>> traceroute -T -p 80 200.10.150.169
>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte
>> packets
>>   1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
>> 1.595 ms  1.562 ms
>>   2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N
>> * *
>>
>> Correctly accessible via Cox, Qwest, Sprint and others, but the
>> network path is really slow and really long.
>>
>> The border is consistently with telefonica-wholesale.net and then
>> telconet.net. Beyond the border there are badly behaving routers,
>> including ones configured with RFC 1918 addresses. The addressable
>> routers are reachable via Verizon, just not the last hop.
>>
>> traceroute -T -p 80 200.10.150.169
>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte
>> packets
>>   1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
>>   2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
>>   3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  9.424
>> ms
>>   4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms
>> 9.140 ms
>>   5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
>> ms  8.929 ms
>>   6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
>>   7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
>>   8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
>> 52.415 ms  52.421 ms
>>   9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
>> 60.397 ms  60.378 ms
>> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms  58.407
>> ms  58.392 ms
>> 11  * * *
>> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms
>> 47.435 ms
>> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
>> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
>> (94.142.119.38)  60.181 ms
>> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
>> 125.888 ms
>> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net (94.142.119.233)
>>   67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
>> (213.140.37.77)  63.435 ms
>> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
>> 141.873 ms
>> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
>> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
>> (176.52.249.241)  64.668 ms
>> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms  117.934 ms
>> 17  * * *
>> 18  * * *
>> 19  * * *
>> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
>> 120.967 ms  115.040 ms
>> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
>> 125.164 ms  119.520 ms
>> 22  * * *
>> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms  244.845 ms
>>
>>
>>
>>
>>
>
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   .... Yogi Berra
>
>


From morrowc.lists at gmail.com  Fri Oct  4 17:02:51 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 4 Oct 2013 13:02:51 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CAL9jLaYy7vJS77A-7ou5teE=mQ+nuj7YiJ1OPx+i-AaNwfzc_w@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <524EEFD8.102@meetinghouse.net>
 <CAL9jLaYy7vJS77A-7ou5teE=mQ+nuj7YiJ1OPx+i-AaNwfzc_w@mail.gmail.com>
Message-ID: <CAL9jLaY6n3UMP8S9T6uvzfM_giGeamAPP_G1_bL+Ornk3Zk45w@mail.gmail.com>

esceula seems to announce a slew of /24's...

28027   | 200.10.149.0/24     | Escuela Superior Politecnica del Litoral
28027   | 200.10.150.0/24     | Escuela Superior Politecnica del Litoral
28027   | 200.10.151.0/24     | Escuela Superior Politecnica del Litoral

but not the covering /22:
200.10.148/22

looking at routeviews (who has a 701 peer):
route-views>sho ip bgp summ | in 157.130
157.130.10.233  4        701 12266262 1198223 968904820    0    0 3w2d
      458803
route-views>

route-views>sho ip bgp neighbors 157.130.10.233 paths  | in 28027
0x511FB188       11      0 701 12956 12956 12956 12956 12956 12956
12956 19169 27947 28027 i
0x47A5A4C0        2      0 701 3257 3257 19169 27947 28027 i


seems that not all of  28027's routes are heard by 701...
route-views>sho ip bgp neighbors 157.130.10.233 routes | in 28027
*  190.15.129.0/24  157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
*  192.188.59.0     157.130.10.233                         0 701 3257
3257 19169 27947 28027 i
*  200.9.176.0      157.130.10.233                         0 701 3257
3257 19169 27947 28027 i
*  200.126.0.0/20   157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
*  200.126.16.0/22  157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
*  200.126.20.0/23  157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
*  200.126.22.0     157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
*  200.126.23.0     157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
*  200.126.24.0/22  157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
*  200.126.28.0     157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
*  200.126.29.0     157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
*  200.126.30.0     157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
*  200.126.31.0     157.130.10.233                         0 701 12956
12956 12956 12956 12956 12956 12956 19169 27947 28027 i
route-views>

this doesn't include the 200.10.148.0/22 networks at all though. I'd
look suspiciously at:
  aut-num:        as12956
as-name:        Telefonica
descr:          Telefonica Backbone Autonomous System
descr:          Telefonica Wholesale Network
remarks:        ===========================================================
remarks:        http://www.telefonica-wholesale.com
remarks:        =========================

who seems to be prepending like crazy...

On Fri, Oct 4, 2013 at 12:54 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> err.. nothing in the /24 is reachable from 701's perspective (so it
> seems)... so I'd suspect that there's a routing problem with the /24,
> in fact the surrounding /24's also seem to be having the same problem.
>
> On Fri, Oct 4, 2013 at 12:42 PM, Miles Fidelman
> <mfidelman at meetinghouse.net> wrote:
>> Also inaccessible from FIOS Boston:
>> new-host-2:~ mfidelman$ traceroute floksociety.org
>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 52 byte packets
>>  1  wireless_broadband_router (192.168.1.1)  1.534 ms  0.853 ms 0.724 ms
>>  2  l100.bstnma-vfttp-84.verizon-gni.net (96.252.37.1)  7.619 ms 6.855 ms
>> 7.304 ms
>>  3  200.10.150.169 (200.10.150.169)  10.482 ms !N *^C
>>
>> But just fine from our datacenter via xo.net.  And the web server is up - at
>> least to a text browser (Lynx).
>>
>> Also via Verizion cell network (Boston area).
>>
>> Some kind of routing table glitch or peering issue, perhaps?
>>
>>
>>
>> William Herrin wrote:
>>>
>>> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:
>>>>>
>>>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte
>>>>> packets
>>>>>   1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>>>>   2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
>>>>> 17.508 ms  7.316 ms
>>>>>   3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms
>>>>> !N *
>>>>>   4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101
>>>>> ms !N
>>>>>   5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms
>>>>> !N *
>>>>>   6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms
>>>>> !N *  8.846 ms !N
>>>
>>> Inaccessible via FIOS Washington DC too:
>>>
>>> traceroute -T -p 80 200.10.150.169
>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte
>>> packets
>>>   1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
>>> 1.595 ms  1.562 ms
>>>   2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N
>>> * *
>>>
>>> Correctly accessible via Cox, Qwest, Sprint and others, but the
>>> network path is really slow and really long.
>>>
>>> The border is consistently with telefonica-wholesale.net and then
>>> telconet.net. Beyond the border there are badly behaving routers,
>>> including ones configured with RFC 1918 addresses. The addressable
>>> routers are reachable via Verizon, just not the last hop.
>>>
>>> traceroute -T -p 80 200.10.150.169
>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte
>>> packets
>>>   1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
>>>   2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
>>>   3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  9.424
>>> ms
>>>   4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms
>>> 9.140 ms
>>>   5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
>>> ms  8.929 ms
>>>   6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
>>>   7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
>>>   8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
>>> 52.415 ms  52.421 ms
>>>   9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
>>> 60.397 ms  60.378 ms
>>> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms  58.407
>>> ms  58.392 ms
>>> 11  * * *
>>> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms
>>> 47.435 ms
>>> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
>>> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
>>> (94.142.119.38)  60.181 ms
>>> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
>>> 125.888 ms
>>> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net (94.142.119.233)
>>>   67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
>>> (213.140.37.77)  63.435 ms
>>> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
>>> 141.873 ms
>>> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
>>> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
>>> (176.52.249.241)  64.668 ms
>>> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms  117.934 ms
>>> 17  * * *
>>> 18  * * *
>>> 19  * * *
>>> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
>>> 120.967 ms  115.040 ms
>>> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
>>> 125.164 ms  119.520 ms
>>> 22  * * *
>>> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms  244.845 ms
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> In theory, there is no difference between theory and practice.
>> In practice, there is.   .... Yogi Berra
>>
>>


From cook at cookreport.com  Fri Oct  4 17:15:15 2013
From: cook at cookreport.com (Gordon Cook)
Date: Fri, 4 Oct 2013 13:15:15 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CAL9jLaYy7vJS77A-7ou5teE=mQ+nuj7YiJ1OPx+i-AaNwfzc_w@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <524EEFD8.102@meetinghouse.net>
 <CAL9jLaYy7vJS77A-7ou5teE=mQ+nuj7YiJ1OPx+i-AaNwfzc_w@mail.gmail.com>
Message-ID: <ABC6270E-E1A8-456F-A14C-2B35E449E2EF@cookreport.com>

Hi chris

really appreciate the help from ALL you guys

does what you just said mean that non reachability for version customer  may mean a config problem for a small bloc and not something intentional??
=============================================================
The COOK Report on Internet Protocol, (PSTN) 609 882-2572 
Back Issues: http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61  
 Cook's Collaborative Edge Blog 
 http://www.cookreport.com/wp/
  Subscription info: http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
=============================================================










On Oct 4, 2013, at 12:54 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote:

> err.. nothing in the /24 is reachable from 701's perspective (so it
> seems)... so I'd suspect that there's a routing problem with the /24,
> in fact the surrounding /24's also seem to be having the same problem.
> 
> On Fri, Oct 4, 2013 at 12:42 PM, Miles Fidelman
> <mfidelman at meetinghouse.net> wrote:
>> Also inaccessible from FIOS Boston:
>> new-host-2:~ mfidelman$ traceroute floksociety.org
>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 52 byte packets
>> 1  wireless_broadband_router (192.168.1.1)  1.534 ms  0.853 ms 0.724 ms
>> 2  l100.bstnma-vfttp-84.verizon-gni.net (96.252.37.1)  7.619 ms 6.855 ms
>> 7.304 ms
>> 3  200.10.150.169 (200.10.150.169)  10.482 ms !N *^C
>> 
>> But just fine from our datacenter via xo.net.  And the web server is up - at
>> least to a text browser (Lynx).
>> 
>> Also via Verizion cell network (Boston area).
>> 
>> Some kind of routing table glitch or peering issue, perhaps?
>> 
>> 
>> 
>> William Herrin wrote:
>>> 
>>> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:
>>>>> 
>>>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte
>>>>> packets
>>>>>  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>>>>  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
>>>>> 17.508 ms  7.316 ms
>>>>>  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms
>>>>> !N *
>>>>>  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101
>>>>> ms !N
>>>>>  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms
>>>>> !N *
>>>>>  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms
>>>>> !N *  8.846 ms !N
>>> 
>>> Inaccessible via FIOS Washington DC too:
>>> 
>>> traceroute -T -p 80 200.10.150.169
>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte
>>> packets
>>>  1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
>>> 1.595 ms  1.562 ms
>>>  2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N
>>> * *
>>> 
>>> Correctly accessible via Cox, Qwest, Sprint and others, but the
>>> network path is really slow and really long.
>>> 
>>> The border is consistently with telefonica-wholesale.net and then
>>> telconet.net. Beyond the border there are badly behaving routers,
>>> including ones configured with RFC 1918 addresses. The addressable
>>> routers are reachable via Verizon, just not the last hop.
>>> 
>>> traceroute -T -p 80 200.10.150.169
>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte
>>> packets
>>>  1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
>>>  2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
>>>  3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  9.424
>>> ms
>>>  4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms
>>> 9.140 ms
>>>  5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
>>> ms  8.929 ms
>>>  6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
>>>  7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
>>>  8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
>>> 52.415 ms  52.421 ms
>>>  9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
>>> 60.397 ms  60.378 ms
>>> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms  58.407
>>> ms  58.392 ms
>>> 11  * * *
>>> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms
>>> 47.435 ms
>>> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
>>> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
>>> (94.142.119.38)  60.181 ms
>>> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
>>> 125.888 ms
>>> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net (94.142.119.233)
>>>  67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
>>> (213.140.37.77)  63.435 ms
>>> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
>>> 141.873 ms
>>> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
>>> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
>>> (176.52.249.241)  64.668 ms
>>> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms  117.934 ms
>>> 17  * * *
>>> 18  * * *
>>> 19  * * *
>>> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
>>> 120.967 ms  115.040 ms
>>> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
>>> 125.164 ms  119.520 ms
>>> 22  * * *
>>> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms  244.845 ms
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> In theory, there is no difference between theory and practice.
>> In practice, there is.   .... Yogi Berra
>> 
>> 
> 



From bill at herrin.us  Fri Oct  4 17:15:46 2013
From: bill at herrin.us (William Herrin)
Date: Fri, 4 Oct 2013 13:15:46 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <AD6AC0A9-42BD-4228-B9EF-C6A0486702E4@cookreport.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <AD6AC0A9-42BD-4228-B9EF-C6A0486702E4@cookreport.com>
Message-ID: <CAP-guGV1B19uQgXBaP5w7XyQAKXTC7NXYpUBRp-KoqV4FjY=tg@mail.gmail.com>

On Fri, Oct 4, 2013 at 12:40 PM, Gordon Cook <cook at cookreport.com> wrote:
> if via FiOS from DC you cannot get through does his look like an intentional move by verizobn to black hole this site????
> how to determine that?
> would like to be sure before i start raising hell elsewhere

I would expect that they're just not receiving the BGP advertisement
for 200.10.150.0/24 from telefonica-wholesale.net. No way to know from
the endpoints whether that's because Telefonica isn't sending or
because Verizon is rejecting.

Either way, it doesn't seem to be black holed. Black holed is when you
advertise a route to a destination and then dump the packets.

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 morrowc.lists at gmail.com  Fri Oct  4 17:22:54 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 4 Oct 2013 13:22:54 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <ABC6270E-E1A8-456F-A14C-2B35E449E2EF@cookreport.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <524EEFD8.102@meetinghouse.net>
 <CAL9jLaYy7vJS77A-7ou5teE=mQ+nuj7YiJ1OPx+i-AaNwfzc_w@mail.gmail.com>
 <ABC6270E-E1A8-456F-A14C-2B35E449E2EF@cookreport.com>
Message-ID: <CAL9jLab7ML46NVZSAFU-uvDLeNiNmCv=Ek858KSV=R7S4787Dg@mail.gmail.com>

On Fri, Oct 4, 2013 at 1:15 PM, Gordon Cook <cook at cookreport.com> wrote:
> Hi chris
>
> really appreciate the help from ALL you guys

sure thing.

> does what you just said mean that non reachability for version customer  may mean a config problem for a small bloc and not something intentional??

that's probably hard to say... I do know that:

 5  0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30)  6.457 ms  6.821 ms
0.xe-11-2-1.GW9.IAD8.ALTER.NET (152.63.42.2)  5.932 ms
 6  telefonica-gw.customer.alter.net (152.179.50.114)  7.182 ms  5.433
ms  5.431 ms
 7  Xe4-1-6-0-grtmiana2.red.telefonica-wholesale.net (94.142.123.145)
47.271 ms  48.381 ms Te0-7-0-5-grtmiana4.red.telefonica-wholesale.net
(94.142.126.182)  50.290 ms


telefonica is a 'customer' not a 'peer' of 701, based on their
connectivity. This means that telefonica has to tell 701: "Yo, I need
you to accept routes for x, y, z, ktnxbi!'

knowing the normal (well, 5yrs ago) config for customers of 701, I
don't expect there'd be special handling of this prefix either... so I
suspect either no one told 701 to accept this, or telefonica pouched
it at the handoff :(

If they didn't do that, these routes wouldn't be accepted.
If telefonica botched some filter on their side (see the comment about
prepending).

It's fairly sure though that the prefix isn't 'blackholed'... since
it's everything in the /22 not just the local /32 or /24. Bill
Herrin's on target as well, it's really hard to say from here :)

-chris

>
> On Oct 4, 2013, at 12:54 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
>
>> err.. nothing in the /24 is reachable from 701's perspective (so it
>> seems)... so I'd suspect that there's a routing problem with the /24,
>> in fact the surrounding /24's also seem to be having the same problem.
>>
>> On Fri, Oct 4, 2013 at 12:42 PM, Miles Fidelman
>> <mfidelman at meetinghouse.net> wrote:
>>> Also inaccessible from FIOS Boston:
>>> new-host-2:~ mfidelman$ traceroute floksociety.org
>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 52 byte packets
>>> 1  wireless_broadband_router (192.168.1.1)  1.534 ms  0.853 ms 0.724 ms
>>> 2  l100.bstnma-vfttp-84.verizon-gni.net (96.252.37.1)  7.619 ms 6.855 ms
>>> 7.304 ms
>>> 3  200.10.150.169 (200.10.150.169)  10.482 ms !N *^C
>>>
>>> But just fine from our datacenter via xo.net.  And the web server is up - at
>>> least to a text browser (Lynx).
>>>
>>> Also via Verizion cell network (Boston area).
>>>
>>> Some kind of routing table glitch or peering issue, perhaps?
>>>
>>>
>>>
>>> William Herrin wrote:
>>>>
>>>> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:
>>>>>>
>>>>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte
>>>>>> packets
>>>>>>  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>>>>>  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
>>>>>> 17.508 ms  7.316 ms
>>>>>>  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms
>>>>>> !N *
>>>>>>  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101
>>>>>> ms !N
>>>>>>  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms
>>>>>> !N *
>>>>>>  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms
>>>>>> !N *  8.846 ms !N
>>>>
>>>> Inaccessible via FIOS Washington DC too:
>>>>
>>>> traceroute -T -p 80 200.10.150.169
>>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte
>>>> packets
>>>>  1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
>>>> 1.595 ms  1.562 ms
>>>>  2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N
>>>> * *
>>>>
>>>> Correctly accessible via Cox, Qwest, Sprint and others, but the
>>>> network path is really slow and really long.
>>>>
>>>> The border is consistently with telefonica-wholesale.net and then
>>>> telconet.net. Beyond the border there are badly behaving routers,
>>>> including ones configured with RFC 1918 addresses. The addressable
>>>> routers are reachable via Verizon, just not the last hop.
>>>>
>>>> traceroute -T -p 80 200.10.150.169
>>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte
>>>> packets
>>>>  1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
>>>>  2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
>>>>  3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  9.424
>>>> ms
>>>>  4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms
>>>> 9.140 ms
>>>>  5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
>>>> ms  8.929 ms
>>>>  6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
>>>>  7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
>>>>  8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
>>>> 52.415 ms  52.421 ms
>>>>  9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
>>>> 60.397 ms  60.378 ms
>>>> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms  58.407
>>>> ms  58.392 ms
>>>> 11  * * *
>>>> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms
>>>> 47.435 ms
>>>> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
>>>> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
>>>> (94.142.119.38)  60.181 ms
>>>> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
>>>> 125.888 ms
>>>> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net (94.142.119.233)
>>>>  67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
>>>> (213.140.37.77)  63.435 ms
>>>> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
>>>> 141.873 ms
>>>> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
>>>> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
>>>> (176.52.249.241)  64.668 ms
>>>> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms  117.934 ms
>>>> 17  * * *
>>>> 18  * * *
>>>> 19  * * *
>>>> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
>>>> 120.967 ms  115.040 ms
>>>> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
>>>> 125.164 ms  119.520 ms
>>>> 22  * * *
>>>> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms  244.845 ms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> In theory, there is no difference between theory and practice.
>>> In practice, there is.   .... Yogi Berra
>>>
>>>
>>
>


From contact at nullivex.com  Fri Oct  4 17:35:11 2013
From: contact at nullivex.com (Bryan Tong)
Date: Fri, 4 Oct 2013 11:35:11 -0600
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CAL9jLab7ML46NVZSAFU-uvDLeNiNmCv=Ek858KSV=R7S4787Dg@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <524EEFD8.102@meetinghouse.net>
 <CAL9jLaYy7vJS77A-7ou5teE=mQ+nuj7YiJ1OPx+i-AaNwfzc_w@mail.gmail.com>
 <ABC6270E-E1A8-456F-A14C-2B35E449E2EF@cookreport.com>
 <CAL9jLab7ML46NVZSAFU-uvDLeNiNmCv=Ek858KSV=R7S4787Dg@mail.gmail.com>
Message-ID: <CAAARkvJDWYNE4e2UdConmHCsAFCeUW2ADsS_mEn6qnWNbG1VLw@mail.gmail.com>

Working here on Bresnan (charter)

root at hq:~# traceroute floksociety.org
traceroute to floksociety.org (200.10.150.169), 30 hops max, 60 byte packets
 1  * * *
 2  cacco002dr9-GE-1-0-0-U0.int.bresnan.net (69.146.239.57)  38.721 ms
 39.799 ms  39.899 m           s
 3  host-72-175-111-198.bln-mt.client.bresnan.net (72.175.111.198)  26.722
ms  27.671 ms  2           7.771 ms
 4  chywyaT1cr5-XE-5-2-0-U0.int.bresnan.net (72.175.110.135)  27.791 ms
 27.818 ms  27.820            ms
 5  seawafh2cr5-XE-5-1-0-U0.int.bresnan.net (72.175.111.166)  67.666 ms
 68.616 ms  68.641            ms
 6  seawafh1tr5-XE-2-0-0-U0.int.bresnan.net (72.175.110.68)  51.856 ms
 61.108 ms  61.768 m           s
 7  12.90.77.21 (12.90.77.21)  65.384 ms  66.327 ms  66.448 ms
 8  cr2.st6wa.ip.att.net (12.123.46.130)  122.440 ms  112.765 ms  111.808 ms
 9  cr2.dvmco.ip.att.net (12.122.1.77)  111.733 ms  102.272 ms  98.744 ms
10  cr2.dlstx.ip.att.net (12.122.31.89)  105.493 ms  106.421 ms  105.106 ms
11  dlstx02jt.ip.att.net (12.122.214.249)  104.780 ms  101.914 ms  106.405
ms
12  213.140.53.61 (213.140.53.61)  103.208 ms 192.205.35.250
(192.205.35.250)  100.279 ms 2           13.140.53.61 (213.140.53.61)
 121.303 ms
13  Te0-5-0-6-grtmiabr5.red.telefonica-wholesale.net (94.142.125.58)
 144.127 ms Xe8-0-2-0-
grtmiabr4.red.telefonica-wholesale.net(94.142.119.38)  159.790 ms
Xe3-1-2-0-grtmiabr4.red.
telefonica-wholesale.net (94.142.126.134)  139.640 ms
14  Te0-2-0-4-grtmiana4.red.telefonica-wholesale.net (94.142.123.5)
 138.665 ms Te0-1-0-0-g
rtmiana4.red.telefonica-wholesale.net(213.140.37.77)  139.681 ms
Xe7-1-6-0-grtmiana2.red.t
elefonica-wholesale.net (94.142.125.154)  145.648 ms
15  176.52.249.245 (176.52.249.245)  163.222 ms 176.52.251.201
(176.52.251.201)  143.164 ms            176.52.249.241 (176.52.249.241)
 140.896 ms
16  176.52.252.66 (176.52.252.66)  184.038 ms  188.723 ms  181.953 ms
17  * * *
18  * * *
19  * * *
20  host-186-5-116-193.telconet.net (186.5.116.193)  189.490 ms  188.537 ms
 188.500 ms
21  host-186-101-89-42.telconet.net (186.101.89.42)  190.366 ms  188.294 ms
 192.845 ms
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *


Traceroute black holes but the site works.

Site works on VZW in Colorado.

Cheers


On Fri, Oct 4, 2013 at 11:22 AM, Christopher Morrow <morrowc.lists at gmail.com
> wrote:

> On Fri, Oct 4, 2013 at 1:15 PM, Gordon Cook <cook at cookreport.com> wrote:
> > Hi chris
> >
> > really appreciate the help from ALL you guys
>
> sure thing.
>
> > does what you just said mean that non reachability for version customer
>  may mean a config problem for a small bloc and not something intentional??
>
> that's probably hard to say... I do know that:
>
>  5  0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30)  6.457 ms  6.821 ms
> 0.xe-11-2-1.GW9.IAD8.ALTER.NET (152.63.42.2)  5.932 ms
>  6  telefonica-gw.customer.alter.net (152.179.50.114)  7.182 ms  5.433
> ms  5.431 ms
>  7  Xe4-1-6-0-grtmiana2.red.telefonica-wholesale.net (94.142.123.145)
> 47.271 ms  48.381 ms Te0-7-0-5-grtmiana4.red.telefonica-wholesale.net
> (94.142.126.182)  50.290 ms
>
>
> telefonica is a 'customer' not a 'peer' of 701, based on their
> connectivity. This means that telefonica has to tell 701: "Yo, I need
> you to accept routes for x, y, z, ktnxbi!'
>
> knowing the normal (well, 5yrs ago) config for customers of 701, I
> don't expect there'd be special handling of this prefix either... so I
> suspect either no one told 701 to accept this, or telefonica pouched
> it at the handoff :(
>
> If they didn't do that, these routes wouldn't be accepted.
> If telefonica botched some filter on their side (see the comment about
> prepending).
>
> It's fairly sure though that the prefix isn't 'blackholed'... since
> it's everything in the /22 not just the local /32 or /24. Bill
> Herrin's on target as well, it's really hard to say from here :)
>
> -chris
>
> >
> > On Oct 4, 2013, at 12:54 PM, Christopher Morrow <morrowc.lists at gmail.com>
> wrote:
> >
> >> err.. nothing in the /24 is reachable from 701's perspective (so it
> >> seems)... so I'd suspect that there's a routing problem with the /24,
> >> in fact the surrounding /24's also seem to be having the same problem.
> >>
> >> On Fri, Oct 4, 2013 at 12:42 PM, Miles Fidelman
> >> <mfidelman at meetinghouse.net> wrote:
> >>> Also inaccessible from FIOS Boston:
> >>> new-host-2:~ mfidelman$ traceroute floksociety.org
> >>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 52 byte
> packets
> >>> 1  wireless_broadband_router (192.168.1.1)  1.534 ms  0.853 ms 0.724 ms
> >>> 2  l100.bstnma-vfttp-84.verizon-gni.net (96.252.37.1)  7.619 ms 6.855
> ms
> >>> 7.304 ms
> >>> 3  200.10.150.169 (200.10.150.169)  10.482 ms !N *^C
> >>>
> >>> But just fine from our datacenter via xo.net.  And the web server is
> up - at
> >>> least to a text browser (Lynx).
> >>>
> >>> Also via Verizion cell network (Boston area).
> >>>
> >>> Some kind of routing table glitch or peering issue, perhaps?
> >>>
> >>>
> >>>
> >>> William Herrin wrote:
> >>>>
> >>>> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com>
> wrote:
> >>>>>>
> >>>>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72
> byte
> >>>>>> packets
> >>>>>>  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
> >>>>>>  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
> >>>>>> 17.508 ms  7.316 ms
> >>>>>>  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)
>  6.482 ms
> >>>>>> !N *
> >>>>>>  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)
>  7.101
> >>>>>> ms !N
> >>>>>>  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)
>  9.239 ms
> >>>>>> !N *
> >>>>>>  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823
> ms
> >>>>>> !N *  8.846 ms !N
> >>>>
> >>>> Inaccessible via FIOS Washington DC too:
> >>>>
> >>>> traceroute -T -p 80 200.10.150.169
> >>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte
> >>>> packets
> >>>>  1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
> >>>> 1.595 ms  1.562 ms
> >>>>  2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321
> ms !N
> >>>> * *
> >>>>
> >>>> Correctly accessible via Cox, Qwest, Sprint and others, but the
> >>>> network path is really slow and really long.
> >>>>
> >>>> The border is consistently with telefonica-wholesale.net and then
> >>>> telconet.net. Beyond the border there are badly behaving routers,
> >>>> including ones configured with RFC 1918 addresses. The addressable
> >>>> routers are reachable via Verizon, just not the last hop.
> >>>>
> >>>> traceroute -T -p 80 200.10.150.169
> >>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte
> >>>> packets
> >>>>  1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
> >>>>  2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
> >>>>  3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms
>  9.424
> >>>> ms
> >>>>  4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms
> >>>> 9.140 ms
> >>>>  5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
> >>>> ms  8.929 ms
> >>>>  6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
> >>>>  7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
> >>>>  8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
> >>>> 52.415 ms  52.421 ms
> >>>>  9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
> >>>> 60.397 ms  60.378 ms
> >>>> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms
>  58.407
> >>>> ms  58.392 ms
> >>>> 11  * * *
> >>>> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms
> >>>> 47.435 ms
> >>>> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
> >>>> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
> >>>> (94.142.119.38)  60.181 ms
> >>>> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
> >>>> 125.888 ms
> >>>> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net(94.142.119.233)
> >>>>  67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
> >>>> (213.140.37.77)  63.435 ms
> >>>> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
> >>>> 141.873 ms
> >>>> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
> >>>> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
> >>>> (176.52.249.241)  64.668 ms
> >>>> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms  117.934 ms
> >>>> 17  * * *
> >>>> 18  * * *
> >>>> 19  * * *
> >>>> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
> >>>> 120.967 ms  115.040 ms
> >>>> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
> >>>> 125.164 ms  119.520 ms
> >>>> 22  * * *
> >>>> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms  244.845
> ms
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> In theory, there is no difference between theory and practice.
> >>> In practice, there is.   .... Yogi Berra
> >>>
> >>>
> >>
> >
>
>


-- 
eSited LLC
(701) 390-9638

From morrowc.lists at gmail.com  Fri Oct  4 17:38:07 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 4 Oct 2013 13:38:07 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CAAARkvJDWYNE4e2UdConmHCsAFCeUW2ADsS_mEn6qnWNbG1VLw@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <524EEFD8.102@meetinghouse.net>
 <CAL9jLaYy7vJS77A-7ou5teE=mQ+nuj7YiJ1OPx+i-AaNwfzc_w@mail.gmail.com>
 <ABC6270E-E1A8-456F-A14C-2B35E449E2EF@cookreport.com>
 <CAL9jLab7ML46NVZSAFU-uvDLeNiNmCv=Ek858KSV=R7S4787Dg@mail.gmail.com>
 <CAAARkvJDWYNE4e2UdConmHCsAFCeUW2ADsS_mEn6qnWNbG1VLw@mail.gmail.com>
Message-ID: <CAL9jLaaFm1juq-Z9ZF6r+mGOUtCbm6aFmTHoKNdM4B5Z_E7WDw@mail.gmail.com>

On Fri, Oct 4, 2013 at 1:35 PM, Bryan Tong <contact at nullivex.com> wrote:

> Site works on VZW in Colorado.

vzw gets transit from places OTHER than 701 in a bunch of places...


From joly at punkcast.com  Fri Oct  4 18:16:27 2013
From: joly at punkcast.com (Joly MacFie)
Date: Fri, 4 Oct 2013 14:16:27 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CAL9jLaaFm1juq-Z9ZF6r+mGOUtCbm6aFmTHoKNdM4B5Z_E7WDw@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <524EEFD8.102@meetinghouse.net>
 <CAL9jLaYy7vJS77A-7ou5teE=mQ+nuj7YiJ1OPx+i-AaNwfzc_w@mail.gmail.com>
 <ABC6270E-E1A8-456F-A14C-2B35E449E2EF@cookreport.com>
 <CAL9jLab7ML46NVZSAFU-uvDLeNiNmCv=Ek858KSV=R7S4787Dg@mail.gmail.com>
 <CAAARkvJDWYNE4e2UdConmHCsAFCeUW2ADsS_mEn6qnWNbG1VLw@mail.gmail.com>
 <CAL9jLaaFm1juq-Z9ZF6r+mGOUtCbm6aFmTHoKNdM4B5Z_E7WDw@mail.gmail.com>
Message-ID: <CAM9VJk3N8dwjb40-fQ66AtAo0rimmiD-vY1UL=QCoo6LOpnPVA@mail.gmail.com>

http://www.downforeveryoneorjustme.com/floksociety.org says it's up. My VZ
dsl says no.




On Fri, Oct 4, 2013 at 1:38 PM, Christopher Morrow
<morrowc.lists at gmail.com>wrote:

> On Fri, Oct 4, 2013 at 1:35 PM, Bryan Tong <contact at nullivex.com> wrote:
>
> > Site works on VZW in Colorado.
>
> vzw gets transit from places OTHER than 701 in a bunch of places...
>
>


-- 
---------------------------------------------------------------
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 streiner at cluebyfour.org  Fri Oct  4 14:37:43 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 4 Oct 2013 10:37:43 -0400 (EDT)
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CAM9VJk3N8dwjb40-fQ66AtAo0rimmiD-vY1UL=QCoo6LOpnPVA@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <524EEFD8.102@meetinghouse.net>
 <CAL9jLaYy7vJS77A-7ou5teE=mQ+nuj7YiJ1OPx+i-AaNwfzc_w@mail.gmail.com>
 <ABC6270E-E1A8-456F-A14C-2B35E449E2EF@cookreport.com>
 <CAL9jLab7ML46NVZSAFU-uvDLeNiNmCv=Ek858KSV=R7S4787Dg@mail.gmail.com>
 <CAAARkvJDWYNE4e2UdConmHCsAFCeUW2ADsS_mEn6qnWNbG1VLw@mail.gmail.com>
 <CAL9jLaaFm1juq-Z9ZF6r+mGOUtCbm6aFmTHoKNdM4B5Z_E7WDw@mail.gmail.com>
 <CAM9VJk3N8dwjb40-fQ66AtAo0rimmiD-vY1UL=QCoo6LOpnPVA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1310041035420.5887@whammy.cluebyfour.org>

On Fri, 4 Oct 2013, Joly MacFie wrote:

> http://www.downforeveryoneorjustme.com/floksociety.org says it's up. My VZ
> dsl says no.

I'm guessing either VZ is not carrying a default inside their network, or 
they are propagating whatever blackhole might exist.

>From my FIOS connection at home, I never reach anything that looks like a 
router that I would expect to have a complete view of the Internet routing 
table.

streiner at whammy ~ $ traceroute www.floksociety.org
traceroute to www.floksociety.org (200.10.150.169), 30 hops max, 60 byte 
packets
  1  192.168.1.1 (192.168.1.1)  0.815 ms  0.800 ms  0.789 ms
  2  L300.PITBPA-VFTTP-29.verizon-gni.net (173.75.39.1)  4.095 ms  4.094 ms 
4.720 ms
  3  * * *
  4  * * *
  5  * * *
  6  * * *
  7  * * *
  8  * * *
  9  * * *
10  * * *
11  * * G0-6-0-6.PITBPA-LCR-22.verizon-gni.net (130.81.168.90)  11.303 ms 
!N



From cscora at apnic.net  Fri Oct  4 18:36:07 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 5 Oct 2013 04:36:07 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201310041836.r94Ia8dh022658@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 05 Oct, 2013

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

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

BGP routing table entries examined:                              468683
    Prefixes after maximum aggregation:                          189054
    Deaggregation factor:                                          2.48
    Unique aggregates announced to Internet:                     232434
Total ASes present in the Internet Routing Table:                 45122
    Prefixes per ASN:                                             10.39
Origin-only ASes present in the Internet Routing Table:           35242
Origin ASes announcing only one prefix:                           16252
Transit ASes present in the Internet Routing Table:                5902
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:                                      30
    Max AS path prepend of ASN ( 36992)                              22
Prefixes from unregistered ASNs in the Routing Table:               338
    Unregistered ASNs in the Routing Table:                         189
Number of 32-bit ASNs allocated by the RIRs:                       5144
Number of 32-bit ASNs visible in the Routing Table:                3978
Prefixes from 32-bit ASNs in the Routing Table:                   12238
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            665
Number of addresses announced to Internet:                   2647718900
    Equivalent to 157 /8s, 208 /16s and 251 /24s
    Percentage of available address space announced:               71.5
    Percentage of allocated address space announced:               71.5
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               95.0
Total number of prefixes smaller than registry allocations:      164010

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

Prefixes being announced by APNIC Region ASes:                   111126
    Total APNIC prefixes after maximum aggregation:               33829
    APNIC Deaggregation factor:                                    3.28
Prefixes being announced from the APNIC address blocks:          113153
    Unique aggregates announced from the APNIC address blocks:    46794
APNIC Region origin ASes present in the Internet Routing Table:    4872
    APNIC Prefixes per ASN:                                       23.23
APNIC Region origin ASes announcing only one prefix:               1218
APNIC Region transit ASes present in the Internet Routing Table:    821
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         21
Number of APNIC region 32-bit ASNs visible in the Routing Table:    692
Number of APNIC addresses announced to Internet:              728412160
    Equivalent to 43 /8s, 106 /16s and 176 /24s
    Percentage of available APNIC address space announced:         85.1

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:                    162812
    Total ARIN prefixes after maximum aggregation:                81536
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           163305
    Unique aggregates announced from the ARIN address blocks:     75874
ARIN Region origin ASes present in the Internet Routing Table:    15904
    ARIN Prefixes per ASN:                                        10.27
ARIN Region origin ASes announcing only one prefix:                6017
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:      22
Number of ARIN addresses announced to Internet:              1072976640
    Equivalent to 63 /8s, 244 /16s and 83 /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:                    118832
    Total RIPE prefixes after maximum aggregation:                61246
    RIPE Deaggregation factor:                                     1.94
Prefixes being announced from the RIPE address blocks:           122391
    Unique aggregates announced from the RIPE address blocks:     78886
RIPE Region origin ASes present in the Internet Routing Table:    17455
    RIPE Prefixes per ASN:                                         7.01
RIPE Region origin ASes announcing only one prefix:                8261
RIPE Region transit ASes present in the Internet Routing Table:    2814
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:    2406
Number of RIPE addresses announced to Internet:               656682980
    Equivalent to 39 /8s, 36 /16s and 47 /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:                   51953
    Total LACNIC prefixes after maximum aggregation:               9822
    LACNIC Deaggregation factor:                                   5.29
Prefixes being announced from the LACNIC address blocks:          56961
    Unique aggregates announced from the LACNIC address blocks:   26309
LACNIC Region origin ASes present in the Internet Routing Table:   2030
    LACNIC Prefixes per ASN:                                      28.06
LACNIC Region origin ASes announcing only one prefix:               563
LACNIC Region transit ASes present in the Internet Routing Table:   385
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        29
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   852
Number of LACNIC addresses announced to Internet:             140082192
    Equivalent to 8 /8s, 89 /16s and 124 /24s
    Percentage of available LACNIC address space announced:        83.5

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:                  11572
    Total AfriNIC prefixes after maximum aggregation:              2533
    AfriNIC Deaggregation factor:                                  4.57
Prefixes being announced from the AfriNIC address blocks:         12208
    Unique aggregates announced from the AfriNIC address blocks:   3999
AfriNIC Region origin ASes present in the Internet Routing Table:   653
    AfriNIC Prefixes per ASN:                                     18.70
AfriNIC Region origin ASes announcing only one prefix:              193
AfriNIC Region transit ASes present in the Internet Routing Table:  137
Average AfriNIC Region AS path length visible:                      4.8
    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:             47751424
    Equivalent to 2 /8s, 216 /16s and 161 /24s
    Percentage of available AfriNIC address space announced:       47.4

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2947      11563         946   Korea Telecom (KIX)
17974     2698        903          90   PT TELEKOMUNIKASI INDONESIA
 7545     2084        321         112   TPG Internet Pty Ltd
 4755     1769        391         187   TATA Communications formerly 
 9829     1548       1236          41   BSNL National Internet Backbo
 9583     1237         93         507   Sify Limited
 9498     1196        309          72   BHARTI Airtel Ltd.
 4808     1191       2131         347   CNCGROUP IP network: China169
 7552     1164       1080          13   Vietel Corporation
24560     1091        380         164   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     3061       3689          59   BellSouth.net Inc.
18566     2066        382         184   Covad Communications 
22773     2055       2943         140   Cox Communications, Inc.
 1785     2019        679         125   PaeTec Communications, Inc.
20115     1682       1651         619   Charter Communications 
 4323     1625       1104         419   Time Warner Telecom
  701     1516      11148         789   UUNET Technologies, Inc. 
30036     1337        301         638   Mediacom Communications Corp 
 7018     1331      17499         857   AT&T WorldNet Services
 6983     1294        772         579   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     1851        544          17   OJSC "Vimpelcom"
34984     1364        244         221   TELLCOM ILETISIM HIZMETLERI A
20940     1040        383         801   Akamai Technologies European 
31148      992         44          19   FreeNet ISP
 6830      891       2365         425   UPC Distribution Services
13188      849         99          67   TOV "Bank-Inform"
 8551      750        370          41   Bezeq International
12479      680        799          49   Uni2 Autonomous System
35228      528        246          16   Avatar Broadband Limited
 3320      514       8418         406   Deutsche Telekom AG

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     3362       1734          88   NET Servicos de Comunicao S.A
10620     2599        423         245   TVCABLE BOGOTA 
 7303     1724       1135         233   Telecom Argentina Stet-France
18881     1462        844          20   Global Village Telecom 
 8151     1340       2805         413   UniNet S.A. de C.V. 
11830      865        364          15   Instituto Costarricense de El
 6503      851        434          63   AVANTEL, S.A. 
27947      837         93          91   Telconet S.A
 6147      799        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      882        306          30   LINKdotNET AS number
 6713      554        633          26   Itissalat Al-MAGHRIB
 8452      421        956           9   TEDATA
24835      292         80           8   RAYA Telecom - Egypt
 3741      258        921         216   The Internet Solution 
29571      223         17          12   Ci Telecom Autonomous system 
36992      222        501          28   Etisalat MISR
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     3362       1734          88   NET Servicos de Comunicao S.A
 6389     3061       3689          59   BellSouth.net Inc.
 4766     2947      11563         946   Korea Telecom (KIX)
17974     2698        903          90   PT TELEKOMUNIKASI INDONESIA
10620     2599        423         245   TVCABLE BOGOTA 
 7545     2084        321         112   TPG Internet Pty Ltd
18566     2066        382         184   Covad Communications 
22773     2055       2943         140   Cox Communications, Inc.
 1785     2019        679         125   PaeTec Communications, Inc.
36998     1864        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      3061        3002      BellSouth.net Inc.
17974      2698        2608      PT TELEKOMUNIKASI INDONESIA
10620      2599        2354      TVCABLE BOGOTA 
 4766      2947        2001      Korea Telecom (KIX)
 7545      2084        1972      TPG Internet Pty Ltd
22773      2055        1915      Cox Communications, Inc.
 1785      2019        1894      PaeTec Communications, Inc.
18566      2066        1882      Covad Communications 
36998      1864        1859      Sudanese Mobile Telephone (ZA
 8402      1851        1834      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
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
30031   UNALLOCATED  12.27.122.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 
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
14764   UNALLOCATED  12.108.237.0/24       7018       AT&T WorldNet Servic
33649   UNALLOCATED  12.111.112.0/24      19029       New Edge Networks 

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.32.0/19        36315     Servpac Inc. 
23.91.96.0/20        40676     Psychz Networks 
23.91.112.0/21       32475     MidPhase Inc. 
23.91.160.0/22       36493     3757277 Canada Inc. (oa 295.c
23.91.160.0/19       36493     3757277 Canada Inc. (oa 295.c
23.91.164.0/22       36493     3757277 Canada Inc. (oa 295.c
23.91.168.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:251     
/13:481     /14:913     /15:1625    /16:12818   /17:6700    /18:11231   
/19:22971   /20:32614   /21:35281   /22:49729   /23:43015   /24:248381  
/25:895     /26:994     /27:475     /28:49      /29:78      /30:18      
/31:0       /32:14      

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

  ASN   No of nets  Total ann.   Description
18566     2017          2066      Covad Communications 
36998     1829          1864      Sudanese Mobile Telephone (ZA
 6389     1710          3061      BellSouth.net Inc.
 8402     1572          1851      OJSC "Vimpelcom"
22773     1327          2055      Cox Communications, Inc.
11492     1194          1235      Cable One 
30036     1194          1337      Mediacom Communications Corp 
 1785     1085          2019      PaeTec Communications, Inc.
 6983     1034          1294      ITC^Deltacom 
22561      962          1237      Digital Teleport, Inc 

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

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

   1:833       2:860       3:3         4:17        5:993       6:19     
   8:612      12:1896     13:3        14:872      15:11       16:3      
  17:14       18:19       20:21       23:451      24:1719     27:1597   
  31:1476     32:45       33:2        34:5        36:81       37:1822   
  38:907      39:2        40:179      41:3253     42:249      44:14     
  46:2022     47:6        49:678      50:840      52:12       54:39     
  55:3        57:26       58:1164     59:611      60:351      61:1425   
  62:1185     63:1978     64:4544     65:2346     66:4179     67:2073   
  68:1089     69:3325     70:859      71:496      72:1994     74:2561   
  75:326      76:306      77:1166     78:1058     79:648      80:1328   
  81:1021     82:625      83:587      84:594      85:1256     86:456    
  87:1015     88:555      89:1723     90:157      91:5640     92:612    
  93:1624     94:1981     95:1628     96:511      97:343      98:1035   
  99:43      100:31      101:611     103:3351    105:520     106:143    
 107:212     108:509     109:1875    110:963     111:1127    112:582    
 113:787     114:730     115:1013    116:984     117:829     118:1167   
 119:1299    120:370     121:735     122:1884    123:1222    124:1359   
 125:1424    128:619     129:325     130:323     131:646     132:349    
 133:162     134:548     135:67      136:275     137:269     138:350    
 139:180     140:181     141:324     142:548     143:417     144:499    
 145:103     146:517     147:403     148:702     149:351     150:157    
 151:598     152:412     153:200     154:47      155:488     156:281    
 157:422     158:285     159:758     160:348     161:448     162:735    
 163:227     164:633     165:572     166:258     167:621     168:1044   
 169:126     170:1081    171:200     172:25      173:1618    174:664    
 175:506     176:1247    177:2332    178:1917    179:160     180:1555   
 181:744     182:1331    183:480     184:657     185:908     186:2606   
 187:1462    188:1872    189:1336    190:7178    192:7001    193:5616   
 194:4062    195:3335    196:1314    197:992     198:4682    199:5475   
 200:6061    201:2530    202:8974    203:8924    204:4504    205:2617   
 206:2848    207:2892    208:4006    209:3619    210:2948    211:1575   
 212:2262    213:2012    214:901     215:99      216:5405    217:1669   
 218:622     219:315     220:1279    221:566     222:326     223:504    


End of report


From mike at routed.ca  Fri Oct  4 19:07:51 2013
From: mike at routed.ca (Mike Jackson)
Date: Fri, 4 Oct 2013 15:07:51 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
Message-ID: <CAH5HGtA=gnjXhCPwR1rNdNSfRxW24-E5LBsnkX=AJrE8fvTR1Q@mail.gmail.com>

The below information is taken from an "internal" router directly connected
to 701
==========================================================

CORE-R1#show ip bgp 200.10.150.169
BGP routing table entry for 200.10.150.0/24, version 46722748
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  701 12956 12956 12956 12956 12956 12956 12956 19169 27947 28027
    x.x.x.x from x.x.x.x (y.y.y.y)
      Origin IGP, localpref 100, valid, external, best


Tracing the route to 200.10.150.169
VRF info: (vrf in name/id, vrf out name/id)
  1 ......
  2 0.ge-11-1-0.XT4.TOR2.ALTER.NET (152.63.4.250) [AS 701] 0 msec 0 msec 0
msec
  3 0.xe-9-1-0.XL2.IAD8.ALTER.NET (152.63.35.14) [AS 701] 20 msec 20 msec
20 msec
  4 0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30) [AS 701] 20 msec
    0.xe-9-0-0.GW9.IAD8.ALTER.NET (152.63.36.18) [AS 701] 20 msec
    0.xe-11-0-0.GW9.IAD8.ALTER.NET (152.63.33.165) [AS 701] 20 msec
  5 telefonica-gw.customer.alter.net (152.179.50.114) [AS 701] 20 msec 20
msec 20 msec
  6 Te0-7-0-5-grtmiana4.red.telefonica-wholesale.net (94.142.126.182) [AS
12956] 60 msec
    Xe4-1-6-0-grtmiana2.red.telefonica-wholesale.net (94.142.123.145) [AS
12956] 64 msec 60 msec
  7 176.52.249.245 60 msec
    176.52.251.193 64 msec
    Xe8-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.185) [AS
12956] 60 msec
  8 176.52.252.66 104 msec 104 msec 104 msec
  9  *  *  *
 10  *  *  *
 11  *  *  *
 12 host-186-5-116-193.telconet.net (186.5.116.193) [AS 27947] [MPLS: Label
5539 Exp 0] 104 msec 104 msec 104 msec
 13 host-186-101-89-42.telconet.net (186.101.89.42) [AS 27947] 108 msec 104
msec 108 msec
 14  *  *  *
 15  *  *  *
 16  *  *  *
 17  *  *  *
 18  *  *  *
 19  *  *  *
 20  *  *  *
 21  *  *  *
 22  *  *  *
 23  *  *  *
 24  *  *  *
 25  *  *  *
 26  *  *  *
 27  *  *  *
 28  *  *  *
 29  *  *  *
 30  *  *  *



On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:

>
> Dear NANOG
>
> The Ecuadoran government has via the FLOK society hired Michel Bauwens of
> the P2p foundation to lead a two year long efforts to revision the ecudoran
> economy along the lines of a commons oriented collaborative society.  I am
> very interested in the program yet i have NEVER been able to connect to
> their web site.   At the end of two hours of trouble shooting with apple i
> was advised to call verizon.  I am a FiOS customer on a two year contact.
>  The traceroute below confirmed that the fault is in verizons network.  The
> verizon tech agreed otherwise i never would have gotten the trouble ticket
>
> my verizon trouble ticket is NJ DQ04PWR9.
>
> Can someone tell me what number to call to pursue resolution of this
> trouble ticket?
>
> as of 12:04 eastern time i still cannot connect
>
> 24 hours was the promise
> 14 of the 24 have elapsed
>
> > traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte
> packets
> >  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
> >  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
>  17.508 ms  7.316 ms
> >  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms
> !N *
> >  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101
> ms !N
> >  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms
> !N *
> >  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms
> !N *  8.846 ms !N
> >
> >
> >
> > Traceroute has started?
> >
> > traceroute to 200.10.150.169 (200.10.150.169), 64 hops max, 72 byte
> packets
> >  1  192.168.1.1 (192.168.1.1)  0.622 ms  0.305 ms  0.361 ms
> >  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  6.633 ms  4.892
> ms  4.809 ms
> >  3  * * *
> >  4  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  10.441 ms
> !N * *
> >  5  * * *
> >  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.932 ms
> !N * *
> >  7  * * *
> >  8  * * *
> >  9  * * *
> > 10  * * *
> > 11  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.765 ms
> !N * *
> > 12  * * *
> > 13  * * *=
>
>
> Lookup has started?
>
> Trying "floksociety.org"
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13700
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;floksociety.org.                      IN        ANY
>
> ;; ANSWER SECTION:
> floksociety.org.           600      IN        A         200.10.150.169
> floksociety.org.           3600    IN        MX      10
> mail.floksociety.org.
> floksociety.org.           3600    IN        NS
> ns57.domaincontrol.com.
> floksociety.org.           3600    IN        NS
> ns58.domaincontrol.com.
> floksociety.org.           3600    IN        SOA    ns57.domaincontrol.com.
> dns.jomax.net. 2013092400 28800 7200 604800 600
>
> Received 174 bytes from 8.8.8.8#53 in 139 ms
> =============================================================
> The COOK Report on Internet Protocol, (PSTN) 609 882-2572
> Back Issues:
> http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61
>  Cook's Collaborative Edge Blog
>  http://www.cookreport.com/wp/
>   Subscription info:
> http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
> =============================================================
>
>
>
>
>
>
>
>
>
>
>

From henry at AegisInfoSys.com  Fri Oct  4 19:18:58 2013
From: henry at AegisInfoSys.com (Henry Yen)
Date: Fri, 4 Oct 2013 15:18:58 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
Message-ID: <20131004191857.GK31269@nntp.AegisInfoSys.com>

On Fri, Oct 04, 2013 at 12:30:01PM -0400, William Herrin wrote:
> Inaccessible via FIOS Washington DC too:
> 
> traceroute -T -p 80 200.10.150.169
> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte packets
>  1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
> 1.595 ms  1.562 ms
>  2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N * *

A little earlier, both FiOS and a uunet/701 connection yielded '!N', but
as of this writing both paths are reaching that website.

-- 
Henry Yen <Henry.Yen at Aegis00.com>               Aegis Information Systems, Inc.
Senior Systems Programmer                       Hicksville, New York
(800) AEGIS-00 x949                             1-800-AEGIS-00 (800-234-4700)



From afurman at amf.net  Fri Oct  4 21:20:25 2013
From: afurman at amf.net (Adam Furman)
Date: Fri, 4 Oct 2013 21:20:25 +0000
Subject: Level3 -> AS3549 US IPv6 Routing
Message-ID: <CE74A956.1BBB8%afurman@amf.net>

I have noticed for the last couple of weeks that Level3 is routing IPV6
traffic to Global Crossing AS via Seattle.  Seeing it from multiple
connection's we have in the US plus Level3 Looking Glass also shows the
routes learned in Seattle from DC. I can't see them only peering in
Seattle from US location's, Europe is different seems to be routing
correctly from what I see on the looking glass.

Route results for 2001:450::/32 from Washington, DC

BGP routing table entry for 2001:450::/32
Paths: (2 available, best #1)
  3549, (aggregated by 3549 err41.sea1.gblx.mgmt)
  AS-path translation: { GBLX }
    2001:1900::3:91 (metric 7502)
      Origin IGP, localpref 100, valid, internal, atomic-aggregate, best
      Community: 3549:5001 3549:30840
      Originator: edge1.Seattle3
  3549, (aggregated by 3549 err41.sea1.gblx.mgmt)
  AS-path translation: { GBLX }
    2001:1900::3:91 (metric 7502)
      Origin IGP, localpref 100, valid, internal, atomic-aggregate
      Community: 3549:5001 3549:30840
      Originator: edge1.Seattle3

Route results for 2001:450::/32 from Frankfurt, Germany
BGP routing table entry for 2001:450::/32
Paths: (2 available, best #1)
  3549, (aggregated by 3549 err41.fra4.gblx.mgmt)
  AS-path translation: { GBLX }
    2001:1900:2::3:8 (metric 40)
      Origin IGP, metric 100000, localpref 86, valid, internal,
atomic-aggregate, best
      Community: Europe  Lclprf_86 Germany IPv6-valid Level3_Peer
Community_ERROR Frankfurt
      Originator: edge4.Frankfurt1
  3549, (aggregated by 3549 err41.fra4.gblx.mgmt)
  AS-path translation: { GBLX }
    2001:1900:2::3:8 (metric 40)
      Origin IGP, metric 100000, localpref 86, valid, internal,
atomic-aggregate
      Community: Europe  Lclprf_86 Germany IPv6-valid Level3_Peer
Community_ERROR Frankfurt
      Originator: edge4.Frankfurt1



Traceroute from one of my connections in DC.  Doesn't matter what I source
the route from.  I have also seen this to customers behind AS3549 too.

 4. vl-4081.edge2.washington1.level3  0.0%     7    1.6   1.6   1.6   1.6
 0.0
 5. vl-4061.car1.newyork2.level3.net  0.0%     7    6.9   7.5   6.9  10.6
 1.4
 6. vl-4081.car2.newyork2.level3.net  0.0%     7    7.0  41.0   7.0 158.2
61.0
 7. vl-4061.car1.chicago1.level3.net  0.0%     7   27.7  27.5  27.4  27.7
 0.1
 8. vl-4040.edge1.chicago2.level3.ne  0.0%     7   27.7  30.0  27.6  44.3
 6.3
 9. vl-4042.edge6.denver1.level3.net  0.0%     7   51.9  51.9  51.8  52.0
 0.1
10. vl-4060.car2.seattle1.level3.net  0.0%     6  186.2 119.0  78.5 186.2
51.6
11. 2001:1900:1b:1::9                 0.0%     6   78.4  78.4  78.3  78.6
 0.1
12. 2001:450:2008:100::135            0.0%     6   86.4  87.2  86.4  90.0
 1.4
13. 2001:450:2002:288::2              0.0%     6   85.2  85.3  85.1  85.5
 0.1


If I route this traffic via Telia it goes direct to Global Crossing's with
a much lower latency.  Has anyone else seen this issue with Level3?

Thanks,
Adam



From cook at cookreport.com  Fri Oct  4 20:48:46 2013
From: cook at cookreport.com (Gordon Cook)
Date: Fri, 04 Oct 2013 16:48:46 -0400
Subject: It worked! Huge Thanks Re: verizon trouble ticket NJ DQ04PWR9 -- is
 verizon blocking FLOKsociety.org by accident or on purpose?
In-Reply-To: <20131004195042.5632144.95858.2585@one.verizon.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <ABC6270E-E1A8-456F-A14C-2B35E449E2EF@cookreport.com>
 <CAL9jLab7ML46NVZSAFU-uvDLeNiNmCv=Ek858KSV=R7S4787Dg@mail.gmail.com>
 <2B205E4F-2DAF-4C51-A4AD-71EDF8396167@cookreport.com>
 <CAL9jLaZvMvzHcFjdUzNP4vHyRbdtYGawqH1=-0towXa2TaH2gg@mail.gmail.com>
 <32F55A3BFAD47C498618CF27C919EAA1CB72B246@FHDP1LUMXC7V41.us.one.verizon.com>
 <9DBC49E99185504DAFACFE86E2191F96011FB62CD9@FHDP1LUMXC7V31.us.one.verizon.com>
 <CAL9jLaa0s3wc_ro4f3deAKBjWRpw9LPF7HzHRbQHJwQ=A07cPQ@mail.gmail.com>
 <CAL9jLabSM=FeTRJiPRE9N8fcED0K+XiPDhq6r6ztxvkAe1jdbg@mail.gmail.com>
 <9DBC49E99185504DAFACFE86E2191F96011FB62D08@FHDP1LUMXC7V31.us.one.verizon.com>
 <20131004195042.5632144.95858.2585@one.verizon.com>
Message-ID: <C15AC77D-8A54-45C8-B678-F163E89B1426@cookreport.com>

Really glad i posted  take a boqand thank you again!
=============================================================
The COOK Report on Internet Protocol, (PSTN) 609 882-2572 
Back Issues: http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61  
 Cook's Collaborative Edge Blog 
 http://www.cookreport.com/wp/
  Subscription info: http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
=============================================================










On Oct 4, 2013, at 3:50 PM, "Moore, Matthew S" <mscott.moore at verizon.com> wrote:

> Thanks eric...scott
> 
> From: Sieg, Eric W
> Sent: Friday, October 4, 2013 3:14 PM
> To: Christopher Morrow
> Cc: Moore, Matthew S; Gordon Cook; Young, David E
> Subject: RE: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by accident or on purpose?
> 
> Everything is complete, all associated prefix-lists for this customer have been updated. 
>  
> Thank you for choosing Verizon,
>  
> Eric Sieg
> IP Non Managed Operations Support | IP/DNS/DNE Administration
> Tel: 248 728 5294 | Vnet: 443-5294
>  
> <image001.gif>
> <image002.jpg>  <image003.jpg>  <image004.jpg>  <image005.jpg>
>  
> From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow
> Sent: Friday, October 04, 2013 3:01 PM
> To: Sieg, Eric W
> Cc: Moore, Matthew S; Gordon Cook; Young, David E
> Subject: Re: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by accident or on purpose?
>  
>  
>  
> 
> On Fri, Oct 4, 2013 at 2:59 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
>  
>  
> 
> On Fri, Oct 4, 2013 at 2:54 PM, Sieg, Eric W <eric.sieg at verizon.com> wrote:
> I?ll get it added to their other sites and follow up with them to let them know.  Give me about 20.
>  
>  
> sweet, thanks!
>  
> forgot, from a fios customer perspective:
>  2  G0-9-4-6.WASHDC-LCR-22.verizon-gni.net (130.81.183.118)  10.434 ms  6.308 ms  3.699 ms
>  3  ae6-0.RES-BB-RTR1.verizon-gni.net (130.81.199.146)  5.45 ms ae5-0.RES-BB-RTR1.verizon-gni.net (130.81.209.222)  3.375 ms ae2-0.RES-BB-RTR1.verizon-gni.net (130.81.199.138)  4.592 ms
>  4  0.ae4.XL2.IAD8.ALTER.NET (152.63.8.125)  8.32 ms  3.457 ms  5.700 ms
>  5  0.xe-9-3-0.GW9.IAD8.ALTER.NET (152.63.36.34)  5.820 ms 0.xe-9-0-0.GW9.IAD8.ALTER.NET (152.63.36.18)  7.311 ms 0.xe-11-2-1.GW9.IAD8.ALTER.NET (152.63.42.2)  6.568 ms
>  6  telefonica-gw.customer.alter.net (152.179.50.114)  3.767 ms  4.74 ms  5.569 ms
>  7  Te0-7-0-5-grtmiana4.red.telefonica-wholesale.net (94.142.126.182)  48.345 ms  46.997 ms Xe4-1-6-0-grtmiana2.red.telefonica-wholesale.net(94.142.123.145)  46.154 ms
>  8  176.52.251.197 (176.52.251.197)  44.747 ms 176.52.251.189 (176.52.251.189)  74.746 ms 176.52.249.241 (176.52.249.241)  49.805 ms
>  9  176.52.252.66 (176.52.252.66)  99.787 ms  98.471 ms  97.103 ms
> ^C
>  
> looks like it works now.
>  
>  
> Thank you for choosing Verizon,
>  
> Eric Sieg
> IP Non Managed Operations Support | IP/DNS/DNE Administration
> Tel: 248 728 5294 | Vnet: 443-5294
>  
> <image001.gif>
> <image002.jpg>  <image003.jpg>  <image004.jpg>  <image005.jpg>
>  
> From: Moore, Matthew S 
> Sent: Friday, October 04, 2013 2:43 PM
> To: Christopher Morrow; Gordon Cook
> Cc: Young, David E; Sieg, Eric W
> Subject: RE: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by accident or on purpose?
>  
> Hi Chris,
> 
>  
> 
> Uncloaking..... ;-)
> 
>  
> 
> It does look as though it's a matter of an un-updated prefix-filter for telefonica.  The existing filter allows a bunch of /24's
> 
> close to the address in question but 200.10.150.0/24 is not among them, whereas telefonica is announcing it to us. (shown, hidden, below)
> 
>  
> 
> scottm at GW9.IAD8> show route receive-protocol bgp 152.179.50.114 hidden | match 200.10.150
> 
>   200.10.150.0/24         152.179.50.114       0                  12956 12956 12956 12956 12956 12956 12956 19169 27947 28027 I
> 
>  
> 
> I added the filter, and I'm cc'ng Eric in Customer Support to let him know.  It will make sense to update it across all 12956 sessions, as I only did this one? no longer hidden? 
>  
> 
>  
> 
> scottm at GW9.IAD8> show route receive-protocol bgp 152.179.50.114 | match 200.10.150
> 
> * 200.10.150.0/24         152.179.50.114       0                  12956 12956 12956 12956 12956 12956 12956 19169 27947 28027 I
> 
>  
> 
>  
> 
> Regards...Scott
> 
>  
> 
> -----Original Message-----
> From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow
> Sent: Friday, October 04, 2013 1:39 PM
> To: Gordon Cook
> Cc: Young, David E
> Subject: Re: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by accident or on purpose?
> 
>  
> 
> I always go with my standby: scott moore ... he can uncloak from bcc land if he's able/willing/etc to help in this case.
> 
>  
> 
> -chris
> 
>  
> 
> On Fri, Oct 4, 2013 at 1:37 PM, Gordon Cook <cook at cookreport.com> wrote:
> 
> > again thank you very very much.  I have to leave routes huit for  root canal but i do expect to be back  can anyone nominate someone at verizon who would do to checking with telefonca?
> 
> > 
> 
> > david young is the only guy i know.
> 
> > 
> 
> > But question now is how to rattle a cage at verizon and possible
> 
> > telefonica - I will also send word of this trouble shooting to the
> 
> > folk in ecuador
> 
> > =============================================================
> 
> > The COOK Report on Internet Protocol, (PSTN) 609 882-2572 Back Issues:
> 
> > http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gi
> 
> > d=37&Itemid=61
> 
> >  Cook's Collaborative Edge Blog
> 
> >  http://www.cookreport.com/wp/
> 
> >   Subscription info:
> 
> > http://www.cookreport.com/index.php?option=com_content&view=article&id
> 
> > =54&Itemid=65
> 
> > =============================================================
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > On Oct 4, 2013, at 1:22 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
> 
> > 
> 
> >> On Fri, Oct 4, 2013 at 1:15 PM, Gordon Cook <cook at cookreport.com> wrote:
> 
> >>> Hi chris
> 
> >>> 
> 
> >>> really appreciate the help from ALL you guys
> 
> >> 
> 
> >> sure thing.
> 
> >> 
> 
> >>> does what you just said mean that non reachability for version customer  may mean a config problem for a small bloc and not something intentional??
> 
> >> 
> 
> >> that's probably hard to say... I do know that:
> 
> >> 
> 
> >> 5  0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30)  6.457 ms  6.821 ms
> 
> >> 0.xe-11-2-1.GW9.IAD8.ALTER.NET (152.63.42.2)  5.932 ms
> 
> >> 6  telefonica-gw.customer.alter.net (152.179.50.114)  7.182 ms  5.433
> 
> >> ms  5.431 ms
> 
> >> 7  Xe4-1-6-0-grtmiana2.red.telefonica-wholesale.net (94.142.123.145)
> 
> >> 47.271 ms  48.381 ms Te0-7-0-5-grtmiana4.red.telefonica-wholesale.net
> 
> >> (94.142.126.182)  50.290 ms
> 
> >> 
> 
> >> 
> 
> >> telefonica is a 'customer' not a 'peer' of 701, based on their
> 
> >> connectivity. This means that telefonica has to tell 701: "Yo, I need
> 
> >> you to accept routes for x, y, z, ktnxbi!'
> 
> >> 
> 
> >> knowing the normal (well, 5yrs ago) config for customers of 701, I
> 
> >> don't expect there'd be special handling of this prefix either... so
> 
> >> I suspect either no one told 701 to accept this, or telefonica
> 
> >> pouched it at the handoff :(
> 
> >> 
> 
> >> If they didn't do that, these routes wouldn't be accepted.
> 
> >> If telefonica botched some filter on their side (see the comment
> 
> >> about prepending).
> 
> >> 
> 
> >> It's fairly sure though that the prefix isn't 'blackholed'... since
> 
> >> it's everything in the /22 not just the local /32 or /24. Bill
> 
> >> Herrin's on target as well, it's really hard to say from here :)
> 
> >> 
> 
> >> -chris
> 
> >> 
> 
> >>> 
> 
> >>> On Oct 4, 2013, at 12:54 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
> 
> >>> 
> 
> >>>> err.. nothing in the /24 is reachable from 701's perspective (so it
> 
> >>>> seems)... so I'd suspect that there's a routing problem with the
> 
> >>>> /24, in fact the surrounding /24's also seem to be having the same problem.
> 
> >>>> 
> 
> >>>> On Fri, Oct 4, 2013 at 12:42 PM, Miles Fidelman
> 
> >>>> <mfidelman at meetinghouse.net> wrote:
> 
> >>>>> Also inaccessible from FIOS Boston:
> 
> >>>>> new-host-2:~ mfidelman$ traceroute floksociety.org traceroute to
> 
> >>>>> floksociety.org (200.10.150.169), 64 hops max, 52 byte packets
> 
> >>>>> 1  wireless_broadband_router (192.168.1.1)  1.534 ms  0.853 ms
> 
> >>>>> 0.724 ms
> 
> >>>>> 2  l100.bstnma-vfttp-84.verizon-gni.net (96.252.37.1)  7.619 ms
> 
> >>>>> 6.855 ms
> 
> >>>>> 7.304 ms
> 
> >>>>> 3  200.10.150.169 (200.10.150.169)  10.482 ms !N *^C
> 
> >>>>> 
> 
> >>>>> But just fine from our datacenter via xo.net.  And the web server
> 
> >>>>> is up - at least to a text browser (Lynx).
> 
> >>>>> 
> 
> >>>>> Also via Verizion cell network (Boston area).
> 
> >>>>> 
> 
> >>>>> Some kind of routing table glitch or peering issue, perhaps?
> 
> >>>>> 
> 
> >>>>> 
> 
> >>>>> 
> 
> >>>>> William Herrin wrote:
> 
> >>>>>> 
> 
> >>>>>> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:
> 
> >>>>>>>> 
> 
> >>>>>>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72
> 
> >>>>>>>> byte packets
> 
> >>>>>>>> 1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
> 
> >>>>>>>> 2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778
> 
> >>>>>>>> ms
> 
> >>>>>>>> 17.508 ms  7.316 ms
> 
> >>>>>>>> 3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119) 
> 
> >>>>>>>> 6.482 ms !N *
> 
> >>>>>>>> 4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119) 
> 
> >>>>>>>> 7.101 ms !N
> 
> >>>>>>>> 5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119) 
> 
> >>>>>>>> 9.239 ms !N *
> 
> >>>>>>>> 6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119) 
> 
> >>>>>>>> 6.823 ms !N *  8.846 ms !N
> 
> >>>>>> 
> 
> >>>>>> Inaccessible via FIOS Washington DC too:
> 
> >>>>>> 
> 
> >>>>>> traceroute -T -p 80 200.10.150.169 traceroute to 200.10.150.169
> 
> >>>>>> (200.10.150.169), 30 hops max, 40 byte packets
> 
> >>>>>> 1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
> 
> >>>>>> 1.595 ms  1.562 ms
> 
> >>>>>> 2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321
> 
> >>>>>> ms !N
> 
> >>>>>> * *
> 
> >>>>>> 
> 
> >>>>>> Correctly accessible via Cox, Qwest, Sprint and others, but the
> 
> >>>>>> network path is really slow and really long.
> 
> >>>>>> 
> 
> >>>>>> The border is consistently with telefonica-wholesale.net and then
> 
> >>>>>> telconet.net. Beyond the border there are badly behaving routers,
> 
> >>>>>> including ones configured with RFC 1918 addresses. The
> 
> >>>>>> addressable routers are reachable via Verizon, just not the last hop.
> 
> >>>>>> 
> 
> >>>>>> traceroute -T -p 80 200.10.150.169 traceroute to 200.10.150.169
> 
> >>>>>> (200.10.150.169), 30 hops max, 60 byte packets
> 
> >>>>>> 1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569
> 
> >>>>>> ms
> 
> >>>>>> 2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
> 
> >>>>>> 3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms 
> 
> >>>>>> 9.424 ms
> 
> >>>>>> 4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226
> 
> >>>>>> ms
> 
> >>>>>> 9.140 ms
> 
> >>>>>> 5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms 
> 
> >>>>>> 9.019 ms  8.929 ms
> 
> >>>>>> 6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
> 
> >>>>>> 7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
> 
> >>>>>> 8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454
> 
> >>>>>> ms
> 
> >>>>>> 52.415 ms  52.421 ms
> 
> >>>>>> 9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
> 
> >>>>>> 60.397 ms  60.378 ms
> 
> >>>>>> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms 
> 
> >>>>>> 58.407 ms  58.392 ms
> 
> >>>>>> 11  * * *
> 
> >>>>>> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms 
> 
> >>>>>> 49.080 ms
> 
> >>>>>> 47.435 ms
> 
> >>>>>> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net
> 
> >>>>>> (94.142.125.54)
> 
> >>>>>> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
> 
> >>>>>> (94.142.119.38)  60.181 ms
> 
> >>>>>> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net
> 
> >>>>>> (213.140.43.109)
> 
> >>>>>> 125.888 ms
> 
> >>>>>> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net
> 
> >>>>>> (94.142.119.233)
> 
> >>>>>> 67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
> 
> >>>>>> (213.140.37.77)  63.435 ms
> 
> >>>>>> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
> 
> >>>>>> 141.873 ms
> 
> >>>>>> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net
> 
> >>>>>> (94.142.126.197)
> 
> >>>>>> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms
> 
> >>>>>> 176.52.249.241
> 
> >>>>>> (176.52.249.241)  64.668 ms
> 
> >>>>>> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms 
> 
> >>>>>> 117.934 ms
> 
> >>>>>> 17  * * *
> 
> >>>>>> 18  * * *
> 
> >>>>>> 19  * * *
> 
> >>>>>> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
> 
> >>>>>> 120.967 ms  115.040 ms
> 
> >>>>>> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
> 
> >>>>>> 125.164 ms  119.520 ms
> 
> >>>>>> 22  * * *
> 
> >>>>>> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms 
> 
> >>>>>> 244.845 ms
> 
> >>>>>> 
> 
> >>>>>> 
> 
> >>>>>> 
> 
> >>>>>> 
> 
> >>>>>> 
> 
> >>>>> 
> 
> >>>>> 
> 
> >>>>> --
> 
> >>>>> In theory, there is no difference between theory and practice.
> 
> >>>>> In practice, there is.   .... Yogi Berra
> 
> >>>>> 
> 
> >>>>> 
> 
> >>>> 
> 
> >>> 
> 
> > 
> 
>  
>  


From randy at psg.com  Fri Oct  4 21:48:08 2013
From: randy at psg.com (Randy Bush)
Date: Sat, 05 Oct 2013 06:48:08 +0900
Subject: web site bug report
Message-ID: <m2fvsg4siv.wl%randy@psg.com>

as i get bounces from action at nanog.org and all other similar contacts,
here we go

   https://www.nanog.org/archives/presentations?k=0&s=Douglas%20Maughan&m=0&a=search

gives me clickables to the 56 agenda.  but those clickables lead me to

    https://www.nanog.org/meetings/56/agenda

which gives me

    Page not found
    The requested page "/meetings/56/agenda" could not be found.

sigh

randhy


From betty at newnog.org  Fri Oct  4 21:54:56 2013
From: betty at newnog.org (Betty Burke <betty@nanog.org>)
Date: Fri, 4 Oct 2013 17:54:56 -0400
Subject: web site bug report
In-Reply-To: <m2fvsg4siv.wl%randy@psg.com>
References: <m2fvsg4siv.wl%randy@psg.com>
Message-ID: <CABhExixHK+bcm9fMjOQ8=sxC5o7CcY2Pns=Xm_QhX7fcnUqyiw@mail.gmail.com>

Hi Randy:

We look into the situation now..  Very sorry for the error.

All best.
Betty



On Fri, Oct 4, 2013 at 5:48 PM, Randy Bush <randy at psg.com> wrote:

> as i get bounces from action at nanog.org and all other similar contacts,
> here we go
>
>
> https://www.nanog.org/archives/presentations?k=0&s=Douglas%20Maughan&m=0&a=search
>
> gives me clickables to the 56 agenda.  but those clickables lead me to
>
>     https://www.nanog.org/meetings/56/agenda
>
> which gives me
>
>     Page not found
>     The requested page "/meetings/56/agenda" could not be found.
>
> sigh
>
> randhy
>
>


-- 
Betty Burke
NANOG Executive Director
48377 Fremont Boulevard, Suite 117
Fremont, CA 94538
Tel: +1 510 492 4030

From randy at psg.com  Fri Oct  4 21:56:21 2013
From: randy at psg.com (Randy Bush)
Date: Sat, 05 Oct 2013 06:56:21 +0900
Subject: web site bug report
In-Reply-To: <CABhExixHK+bcm9fMjOQ8=sxC5o7CcY2Pns=Xm_QhX7fcnUqyiw@mail.gmail.com>
References: <m2fvsg4siv.wl%randy@psg.com>
 <CABhExixHK+bcm9fMjOQ8=sxC5o7CcY2Pns=Xm_QhX7fcnUqyiw@mail.gmail.com>
Message-ID: <m2bo344s56.wl%randy@psg.com>

> We look into the situation now..  Very sorry for the error.

i demand a full refund!  :)


From cidr-report at potaroo.net  Fri Oct  4 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 4 Oct 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201310042200.r94M00QP028117@wattle.apnic.net>

This report has been generated at Fri Oct  4 21:13:31 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
        27-09-13    480420      271008
        28-09-13    480526      271503
        29-09-13    480781      271509
        30-09-13    480357      271325
        01-10-13    479734      271628
        02-10-13    480438      271524
        03-10-13    480524      271615
        04-10-13    479970      272934


AS Summary
         45275  Number of ASes in routing system
         18585  Number of ASes announcing only one prefix
          4174  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      118190016  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').

 --- 04Oct13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     480818   273005   207813    43.2%   All ASes

AS6389      3060       62     2998    98.0%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS17974     2697      120     2577    95.6%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS28573     3361      867     2494    74.2%   NET Servi?os de Comunica??o
                                               S.A.
AS7029      4174     1867     2307    55.3%   WINDSTREAM - Windstream
                                               Communications Inc
AS4766      2945      954     1991    67.6%   KIXS-AS-KR Korea Telecom
AS10620     2598     1030     1568    60.4%   Telmex Colombia S.A.
AS18566     2066      572     1494    72.3%   COVAD - Covad Communications
                                               Co.
AS36998     1864      375     1489    79.9%   SDN-MOBITEL
AS4323      2961     1538     1423    48.1%   TWTC - tw telecom holdings,
                                               inc.
AS7303      1724      466     1258    73.0%   Telecom Argentina S.A.
AS1785      2019      810     1209    59.9%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1769      585     1184    66.9%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1195      145     1050    87.9%   VIETEL-AS-AP Vietel
                                               Corporation
AS18881     1463      438     1025    70.1%   Global Village Telecom
AS22561     1237      216     1021    82.5%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS7545      2085     1222      863    41.4%   TPG-INTERNET-AP TPG Telecom
                                               Limited
AS22773     2058     1241      817    39.7%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS18101      979      178      801    81.8%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4808      1191      403      788    66.2%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS8402      1816     1040      776    42.7%   CORBINA-AS OJSC "Vimpelcom"
AS11830      866      118      748    86.4%   Instituto Costarricense de
                                               Electricidad y Telecom.
AS701       1517      793      724    47.7%   UUNET - MCI Communications
                                               Services, Inc. d/b/a Verizon
                                               Business
AS24560     1091      373      718    65.8%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS8151      1345      633      712    52.9%   Uninet S.A. de C.V.
AS6983      1294      585      709    54.8%   ITCDELTA - ITC^Deltacom
AS13977      851      146      705    82.8%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS6147       799      108      691    86.5%   Telefonica del Peru S.A.A.
AS855        737       55      682    92.5%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS7738       780      138      642    82.3%   Telemar Norte Leste S.A.
AS17676      767      140      627    81.7%   GIGAINFRA Softbank BB Corp.

Total      53309    17218    36091    67.7%   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.232.0/23       AS55048 VMWARE - VMware, Inc.
        23.235.96.0/20       AS7782  ALSK-7782 - Alaska Communications Systems Group, Inc.
        27.54.116.0/22       AS55452 
        27.54.116.0/24       AS55452 
        27.54.119.0/24       AS55452 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.182.96.0/23       AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED
        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.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.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.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.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
        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.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        82.103.0.0/18        AS30901 
        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.205.188.0/22      AS47983 
        91.207.178.0/23      AS48274 
        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.212.0/24      AS17819 ASN-EQUINIX-AP Equinix Asia Pacific
        103.13.213.0/24      AS17819 ASN-EQUINIX-AP Equinix Asia Pacific
        103.13.214.0/24      AS17819 ASN-EQUINIX-AP Equinix Asia Pacific
        103.13.215.0/24      AS17819 ASN-EQUINIX-AP Equinix Asia Pacific
        103.14.100.0/24      AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited
        103.14.101.0/24      AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited
        103.14.102.0/24      AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited
        103.14.103.0/24      AS38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited
        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
        120.136.17.0/24      AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika
        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
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        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.
        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.
        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.111.125.0/24     AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget
        193.111.155.0/24     AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget
        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
        193.254.250.0/23     AS25349 
        193.254.250.0/24     AS25349 
        193.254.251.0/24     AS25349 
        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 
        194.169.237.0/24     AS12968 CDP Netia SA
        195.114.4.0/23       AS41158 
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA
        195.234.156.0/24     AS25028 
        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.52.47.0/24       AS55560 
        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.84.16.0/24       AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.84.17.0/24       AS17781 XINHUA Xinhua News Agency
        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.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.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.225.0/24      AS3549  GBLX Global Crossing Ltd.
        208.66.227.0/24      AS3549  GBLX Global Crossing Ltd.
        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.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
        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.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        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 
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.146.0.0/19       AS1915  SEQUOIA-AS - National Science Foundation
        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 Oct  4 22:00:01 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 4 Oct 2013 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201310042200.r94M01Px028131@wattle.apnic.net>

BGP Update Report
Interval: 26-Sep-13 -to- 03-Oct-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS18881           69543  2.7%      47.6 -- Global Village Telecom
 2 - AS8163            68857  2.7%     177.5 -- METROTEL REDES S.A.
 3 - AS36998           47541  1.9%      25.5 -- SDN-MOBITEL
 4 - AS4538            47379  1.9%      18.9 -- ERX-CERNET-BKB China Education and Research Network Center
 5 - AS8402            45065  1.8%      22.5 -- CORBINA-AS OJSC "Vimpelcom"
 6 - AS9829            38289  1.5%      36.0 -- BSNL-NIB National Internet Backbone
 7 - AS10620           29732  1.2%      14.5 -- Telmex Colombia S.A.
 8 - AS3816            28564  1.1%      47.4 -- COLOMBIA TELECOMUNICACIONES S.A. ESP
 9 - AS28573           23905  0.9%       8.1 -- NET Servi?os de Comunica??o S.A.
10 - AS13118           22526  0.9%     479.3 -- ASN-YARTELECOM OJSC Rostelecom
11 - AS31148           22155  0.9%      22.4 -- FREENET-AS Freenet Ltd.
12 - AS27738           18931  0.7%      32.8 -- Ecuadortelecom S.A.
13 - AS19886           17274  0.7%    2879.0 -- BOFABROKERDEALERSVCS - Bank of America
14 - AS20473           16646  0.7%     110.2 -- AS-CHOOPA - Choopa, LLC
15 - AS8151            16096  0.6%      14.1 -- Uninet S.A. de C.V.
16 - AS4775            15943  0.6%     613.2 -- GLOBE-TELECOM-AS Globe Telecoms
17 - AS28509           15244  0.6%      73.6 -- Cablemas Telecomunicaciones SA de CV
18 - AS31252           13271  0.5%      53.9 -- STARNET-AS StarNet Moldova
19 - AS17974           11386  0.5%       4.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
20 - AS11976           11291  0.4%     171.1 -- FIDN - Fidelity Communication International Inc.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS6629             8937  0.3%    8937.0 -- NOAA-AS - NOAA
 2 - AS6174             7057  0.3%    3528.5 -- SPRINTLINK8 - Sprint
 3 - AS32445            3006  0.1%    3006.0 -- XHOP - XHOP LLC
 4 - AS37367            2990  0.1%    2990.0 -- CALLKEY
 5 - AS19886           17274  0.7%    2879.0 -- BOFABROKERDEALERSVCS - Bank of America
 6 - AS16608            5186  0.2%    2593.0 -- KENTEC - Kentec Communications, Inc.
 7 - AS7202             8508  0.3%    1701.6 -- FAMU - Florida A & M University
 8 - AS19779            2629  0.1%    1314.5 -- 
 9 - AS33540            1071  0.0%    1071.0 -- ALZHEI-ASN - Alzheimers Assoc.
10 - AS45808            1066  0.0%    1066.0 -- UTP-MY Bandar Seri Iskandar
11 - AS22688             989  0.0%     989.0 -- DOLGENCORP - Dollar General Corporation
12 - AS23295             735  0.0%     735.0 -- EA-01 - Extend America
13 - AS32528            5861  0.2%     732.6 -- ABBOTT Abbot Labs
14 - AS48612            9554  0.4%     682.4 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
15 - AS4775            15943  0.6%     613.2 -- GLOBE-TELECOM-AS Globe Telecoms
16 - AS32244            7321  0.3%     610.1 -- LIQUID-WEB-INC - Liquid Web, Inc.
17 - AS58452            1194  0.1%     597.0 -- ANTAMEDIAKOM-ID PT. Anta Mediakom
18 - AS2                2124  0.1%     657.0 -- CONTROLVM-MY ControlVM Technology
19 - AS55897            4680  0.2%     520.0 -- NIPPON-RAD Nippon RAD Inc.
20 - AS29052             506  0.0%     506.0 -- LYCOS-AS INFORM P. LYKOS A.E


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 109.161.64.0/20   21880  0.8%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 108.61.128.0/18   16207  0.6%   AS20473 -- AS-CHOOPA - Choopa, LLC
 3 - 92.246.207.0/24    9404  0.3%   AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
 4 - 192.58.232.0/24    8937  0.3%   AS6629  -- NOAA-AS - NOAA
 5 - 120.28.62.0/24     7831  0.3%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
 7 - 67.210.190.0/23    5896  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
 8 - 115.170.128.0/17   5612  0.2%   AS4847  -- CNIX-AP China Networks Inter-Exchange
 9 - 67.210.188.0/23    4994  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
10 - 69.38.178.0/24     4342  0.2%   AS19406 -- TWRS-MA - Towerstream I, Inc.
11 - 171.181.112.0/22   4318  0.2%   AS19886 -- BOFABROKERDEALERSVCS - Bank of America
12 - 171.181.116.0/23   4318  0.2%   AS19886 -- BOFABROKERDEALERSVCS - Bank of America
13 - 171.181.118.0/24   4318  0.2%   AS19886 -- BOFABROKERDEALERSVCS - Bank of America
14 - 171.181.120.0/24   4296  0.2%   AS19886 -- BOFABROKERDEALERSVCS - Bank of America
15 - 168.223.200.0/22   4251  0.2%   AS7202  -- FAMU - Florida A & M University
16 - 168.223.206.0/23   4245  0.2%   AS7202  -- FAMU - Florida A & M University
17 - 62.84.76.0/24      4215  0.2%   AS42334 -- BBP-AS Broadband Plus s.a.l.
18 - 2.93.235.0/24      3970  0.1%   AS8402  -- CORBINA-AS OJSC "Vimpelcom"
19 - 201.33.145.0/24    3561  0.1%   AS11993 -- BANCO DO BRASIL S.A.
20 - 206.105.75.0/24    3529  0.1%   AS6174  -- SPRINTLINK8 - Sprint

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


From randy at psg.com  Sat Oct  5 00:15:03 2013
From: randy at psg.com (Randy Bush)
Date: Sat, 05 Oct 2013 09:15:03 +0900
Subject: web site bug report
In-Reply-To: <524F58E1.5060405@BroAndSis.com>
References: <m2fvsg4siv.wl%randy@psg.com>
 <CABhExixHK+bcm9fMjOQ8=sxC5o7CcY2Pns=Xm_QhX7fcnUqyiw@mail.gmail.com>
 <m2bo344s56.wl%randy@psg.com> <524F58E1.5060405@BroAndSis.com>
Message-ID: <m2siwg375k.wl%randy@psg.com>

> Thanks very much for alerting us to this issue, and apologies for the 
> inconvenience.
> When search was done by name it was throwing an error on the agenda path 
> omitting 'nanog' from the path, hence the 404 page.
> This is now fixed. Kindly let us know if you run into any more issues 
> with this.

no biggie.  bugs happen.  of course, i never have any :)

randy


From mfidelman at meetinghouse.net  Sat Oct  5 01:22:17 2013
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Fri, 04 Oct 2013 21:22:17 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <20131004191857.GK31269@nntp.AegisInfoSys.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <20131004191857.GK31269@nntp.AegisInfoSys.com>
Message-ID: <524F69C9.5040507@meetinghouse.net>

Seems to be working now from Verizon FIOS in Boston area.

Henry Yen wrote:
> On Fri, Oct 04, 2013 at 12:30:01PM -0400, William Herrin wrote:
>> Inaccessible via FIOS Washington DC too:
>>
>> traceroute -T -p 80 200.10.150.169
>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte packets
>>   1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
>> 1.595 ms  1.562 ms
>>   2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N * *
> A little earlier, both FiOS and a uunet/701 connection yielded '!N', but
> as of this writing both paths are reaching that website.
>


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra



From joly at punkcast.com  Sat Oct  5 08:28:35 2013
From: joly at punkcast.com (Joly MacFie)
Date: Sat, 5 Oct 2013 04:28:35 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <524F69C9.5040507@meetinghouse.net>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAP-guGVL64Oenthu=+Q+BXs_6xqiXOpaa6NoGixSt_ZQJ8z1BQ@mail.gmail.com>
 <20131004191857.GK31269@nntp.AegisInfoSys.com>
 <524F69C9.5040507@meetinghouse.net>
Message-ID: <CAM9VJk1_idey5d3477atjU6bAwueAPdNBqPKEEhVTb7fxqSaew@mail.gmail.com>

Yes, working on VZ DSL now.


On Fri, Oct 4, 2013 at 9:22 PM, Miles Fidelman
<mfidelman at meetinghouse.net>wrote:

> Seems to be working now from Verizon FIOS in Boston area.
>
>
> Henry Yen wrote:
>
>> On Fri, Oct 04, 2013 at 12:30:01PM -0400, William Herrin wrote:
>>
>>> Inaccessible via FIOS Washington DC too:
>>>
>>> traceroute -T -p 80 200.10.150.169
>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte
>>> packets
>>>   1  L300.WASHDC-VFTTP-91.verizon-**gni.net<http://L300.WASHDC-VFTTP-91.verizon-gni.net>(173.73.47.1)  1.804 ms
>>> 1.595 ms  1.562 ms
>>>   2  G0-6-4-7.WASHDC-LCR-22.**verizon-gni.net<http://G0-6-4-7.WASHDC-LCR-22.verizon-gni.net>(130.81.216.250)  5.321 ms !N * *
>>>
>> A little earlier, both FiOS and a uunet/701 connection yielded '!N', but
>> as of this writing both paths are reaching that website.
>>
>>
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   .... Yogi Berra
>
>
>


-- 
---------------------------------------------------------------
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 randy at psg.com  Sat Oct  5 11:18:24 2013
From: randy at psg.com (Randy Bush)
Date: Sat, 05 Oct 2013 20:18:24 +0900
Subject: apt-mirror near ashburn
Message-ID: <m2bo342cfz.wl%randy@psg.com>

anyone have a stable ubuntu 12.04 apt-mirror near (sprint/ntt) ashburn i
can abuse lightly?

randy


From me at anuragbhatia.com  Sat Oct  5 16:19:37 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Sat, 5 Oct 2013 21:49:37 +0530
Subject: Regarding source based outbound routing (with redundancy)
Message-ID: <CAJ0+aXZFWaXRMZBrZ+E3DDW6ZikLpYnV2-pR2oWrdLGU-CPVKw@mail.gmail.com>

Hello there!


I am trying to do a source based outbound routing between multiple
upstreams. Usually I picked outbound via localpref but here I wish to use
Provider 1 for say 10.10.10.0/24 while provider 2 for small chunk of it say
10.10.10.0/28. I wish to keep failover support and thus so if provider 2
fails, I wish to push traffic again via Provider 1.

Is this is possible only with VRF or I can push for some specific match
rule in route maps?



Thanks.

-- 



Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From morrowc.lists at gmail.com  Sat Oct  5 16:24:40 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 5 Oct 2013 12:24:40 -0400
Subject: apt-mirror near ashburn
In-Reply-To: <m2bo342cfz.wl%randy@psg.com>
References: <m2bo342cfz.wl%randy@psg.com>
Message-ID: <CAL9jLaZX8Qh==grYQ2bd-ZJwdDngUA4_NpegrE9cCwyuc2wpLw@mail.gmail.com>

i think the mirror i used to run is still there...

ftp://mirrors.supsec.org/pub/linux/ubuntu/dists/precise

possibly also:
http://ubuntu.supsec.org/dists/precise (this seems to wrok fine for me as well)

-chris

On Sat, Oct 5, 2013 at 7:18 AM, Randy Bush <randy at psg.com> wrote:
> anyone have a stable ubuntu 12.04 apt-mirror near (sprint/ntt) ashburn i
> can abuse lightly?
>
> randy
>


From morrowc.lists at gmail.com  Sat Oct  5 16:25:55 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 5 Oct 2013 12:25:55 -0400
Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking
 FLOKsociety.org by accident or on purpose?
In-Reply-To: <CAH5HGtA=gnjXhCPwR1rNdNSfRxW24-E5LBsnkX=AJrE8fvTR1Q@mail.gmail.com>
References: <11E42C1E-31F3-472F-91AB-4E68B464EF18@cookreport.com>
 <CAH5HGtA=gnjXhCPwR1rNdNSfRxW24-E5LBsnkX=AJrE8fvTR1Q@mail.gmail.com>
Message-ID: <CAL9jLabvjS2FMtdh-QRH6LwH-HYL0XTgy4wE4AmNokZ-Nk3smg@mail.gmail.com>

yup, the verizon elves did their magic :)
thanks to eric and scott.

On Fri, Oct 4, 2013 at 3:07 PM, Mike Jackson <mike at routed.ca> wrote:
> The below information is taken from an "internal" router directly connected
> to 701
> ==========================================================
>
> CORE-R1#show ip bgp 200.10.150.169
> BGP routing table entry for 200.10.150.0/24, version 46722748
> Paths: (1 available, best #1, table default)
>   Not advertised to any peer
>   701 12956 12956 12956 12956 12956 12956 12956 19169 27947 28027
>     x.x.x.x from x.x.x.x (y.y.y.y)
>       Origin IGP, localpref 100, valid, external, best
>
>
> Tracing the route to 200.10.150.169
> VRF info: (vrf in name/id, vrf out name/id)
>   1 ......
>   2 0.ge-11-1-0.XT4.TOR2.ALTER.NET (152.63.4.250) [AS 701] 0 msec 0 msec 0
> msec
>   3 0.xe-9-1-0.XL2.IAD8.ALTER.NET (152.63.35.14) [AS 701] 20 msec 20 msec
> 20 msec
>   4 0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30) [AS 701] 20 msec
>     0.xe-9-0-0.GW9.IAD8.ALTER.NET (152.63.36.18) [AS 701] 20 msec
>     0.xe-11-0-0.GW9.IAD8.ALTER.NET (152.63.33.165) [AS 701] 20 msec
>   5 telefonica-gw.customer.alter.net (152.179.50.114) [AS 701] 20 msec 20
> msec 20 msec
>   6 Te0-7-0-5-grtmiana4.red.telefonica-wholesale.net (94.142.126.182) [AS
> 12956] 60 msec
>     Xe4-1-6-0-grtmiana2.red.telefonica-wholesale.net (94.142.123.145) [AS
> 12956] 64 msec 60 msec
>   7 176.52.249.245 60 msec
>     176.52.251.193 64 msec
>     Xe8-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.185) [AS
> 12956] 60 msec
>   8 176.52.252.66 104 msec 104 msec 104 msec
>   9  *  *  *
>  10  *  *  *
>  11  *  *  *
>  12 host-186-5-116-193.telconet.net (186.5.116.193) [AS 27947] [MPLS: Label
> 5539 Exp 0] 104 msec 104 msec 104 msec
>  13 host-186-101-89-42.telconet.net (186.101.89.42) [AS 27947] 108 msec 104
> msec 108 msec
>  14  *  *  *
>  15  *  *  *
>  16  *  *  *
>  17  *  *  *
>  18  *  *  *
>  19  *  *  *
>  20  *  *  *
>  21  *  *  *
>  22  *  *  *
>  23  *  *  *
>  24  *  *  *
>  25  *  *  *
>  26  *  *  *
>  27  *  *  *
>  28  *  *  *
>  29  *  *  *
>  30  *  *  *
>
>
>
> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:
>
>>
>> Dear NANOG
>>
>> The Ecuadoran government has via the FLOK society hired Michel Bauwens of
>> the P2p foundation to lead a two year long efforts to revision the ecudoran
>> economy along the lines of a commons oriented collaborative society.  I am
>> very interested in the program yet i have NEVER been able to connect to
>> their web site.   At the end of two hours of trouble shooting with apple i
>> was advised to call verizon.  I am a FiOS customer on a two year contact.
>>  The traceroute below confirmed that the fault is in verizons network.  The
>> verizon tech agreed otherwise i never would have gotten the trouble ticket
>>
>> my verizon trouble ticket is NJ DQ04PWR9.
>>
>> Can someone tell me what number to call to pursue resolution of this
>> trouble ticket?
>>
>> as of 12:04 eastern time i still cannot connect
>>
>> 24 hours was the promise
>> 14 of the 24 have elapsed
>>
>> > traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte
>> packets
>> >  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>> >  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
>>  17.508 ms  7.316 ms
>> >  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms
>> !N *
>> >  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101
>> ms !N
>> >  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms
>> !N *
>> >  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms
>> !N *  8.846 ms !N
>> >
>> >
>> >
>> > Traceroute has started?
>> >
>> > traceroute to 200.10.150.169 (200.10.150.169), 64 hops max, 72 byte
>> packets
>> >  1  192.168.1.1 (192.168.1.1)  0.622 ms  0.305 ms  0.361 ms
>> >  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  6.633 ms  4.892
>> ms  4.809 ms
>> >  3  * * *
>> >  4  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  10.441 ms
>> !N * *
>> >  5  * * *
>> >  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.932 ms
>> !N * *
>> >  7  * * *
>> >  8  * * *
>> >  9  * * *
>> > 10  * * *
>> > 11  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.765 ms
>> !N * *
>> > 12  * * *
>> > 13  * * *=
>>
>>
>> Lookup has started?
>>
>> Trying "floksociety.org"
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13700
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
>>
>> ;; QUESTION SECTION:
>> ;floksociety.org.                      IN        ANY
>>
>> ;; ANSWER SECTION:
>> floksociety.org.           600      IN        A         200.10.150.169
>> floksociety.org.           3600    IN        MX      10
>> mail.floksociety.org.
>> floksociety.org.           3600    IN        NS
>> ns57.domaincontrol.com.
>> floksociety.org.           3600    IN        NS
>> ns58.domaincontrol.com.
>> floksociety.org.           3600    IN        SOA    ns57.domaincontrol.com.
>> dns.jomax.net. 2013092400 28800 7200 604800 600
>>
>> Received 174 bytes from 8.8.8.8#53 in 139 ms
>> =============================================================
>> The COOK Report on Internet Protocol, (PSTN) 609 882-2572
>> Back Issues:
>> http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61
>>  Cook's Collaborative Edge Blog
>>  http://www.cookreport.com/wp/
>>   Subscription info:
>> http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
>> =============================================================
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>


From morrowc.lists at gmail.com  Sat Oct  5 16:45:12 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 5 Oct 2013 12:45:12 -0400
Subject: Regarding source based outbound routing (with redundancy)
In-Reply-To: <CAJ0+aXZFWaXRMZBrZ+E3DDW6ZikLpYnV2-pR2oWrdLGU-CPVKw@mail.gmail.com>
References: <CAJ0+aXZFWaXRMZBrZ+E3DDW6ZikLpYnV2-pR2oWrdLGU-CPVKw@mail.gmail.com>
Message-ID: <CAL9jLabfQuQnj+RLTMgCcgEb=s=g-vvLA7-A8MVUXja43Dj0kg@mail.gmail.com>

you really don't want to do policy routing :(

On Sat, Oct 5, 2013 at 12:19 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:
> Hello there!
>
>
> I am trying to do a source based outbound routing between multiple
> upstreams. Usually I picked outbound via localpref but here I wish to use
> Provider 1 for say 10.10.10.0/24 while provider 2 for small chunk of it say
> 10.10.10.0/28. I wish to keep failover support and thus so if provider 2
> fails, I wish to push traffic again via Provider 1.
>
> Is this is possible only with VRF or I can push for some specific match
> rule in route maps?
>
>
>
> Thanks.
>
> --
>
>
>
> Anurag Bhatia
> anuragbhatia.com
>
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
> Twitter<https://twitter.com/anurag_bhatia>
> Skype: anuragbhatia.com


From joelja at bogus.com  Sat Oct  5 18:08:24 2013
From: joelja at bogus.com (joel jaeggli)
Date: Sat, 5 Oct 2013 11:08:24 -0700
Subject: Regarding source based outbound routing (with redundancy)
In-Reply-To: <CAL9jLabfQuQnj+RLTMgCcgEb=s=g-vvLA7-A8MVUXja43Dj0kg@mail.gmail.com>
References: <CAJ0+aXZFWaXRMZBrZ+E3DDW6ZikLpYnV2-pR2oWrdLGU-CPVKw@mail.gmail.com>
 <CAL9jLabfQuQnj+RLTMgCcgEb=s=g-vvLA7-A8MVUXja43Dj0kg@mail.gmail.com>
Message-ID: <7B89FED8-D9BD-4283-B21F-C0697D57DDC8@bogus.com>


On Oct 5, 2013, at 9:45 AM, Christopher Morrow <morrowc.lists at gmail.com> wrote:

> you really don't want to do policy routing :(
> 

PBR has this tendency to be brittle in the face of topology changes.

There are much better way to outbound load-balance between providers offering same or similar quality routes to the same destination.

multi-AS multipath will do that if the peers are on the same router. BGPaddpath can do it for you if the peers are spread across routers.

joel

> On Sat, Oct 5, 2013 at 12:19 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:
>> Hello there!
>> 
>> 
>> I am trying to do a source based outbound routing between multiple
>> upstreams. Usually I picked outbound via localpref but here I wish to use
>> Provider 1 for say 10.10.10.0/24 while provider 2 for small chunk of it say
>> 10.10.10.0/28. I wish to keep failover support and thus so if provider 2
>> fails, I wish to push traffic again via Provider 1.
>> 
>> Is this is possible only with VRF or I can push for some specific match
>> rule in route maps?
>> 
>> 
>> 
>> Thanks.
>> 
>> --
>> 
>> 
>> 
>> Anurag Bhatia
>> anuragbhatia.com
>> 
>> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
>> Twitter<https://twitter.com/anurag_bhatia>
>> Skype: anuragbhatia.com
> 

-------------- 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/20131005/a46cd384/attachment.bin>

From morrowc.lists at gmail.com  Sat Oct  5 18:43:47 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 5 Oct 2013 14:43:47 -0400
Subject: Regarding source based outbound routing (with redundancy)
In-Reply-To: <7B89FED8-D9BD-4283-B21F-C0697D57DDC8@bogus.com>
References: <CAJ0+aXZFWaXRMZBrZ+E3DDW6ZikLpYnV2-pR2oWrdLGU-CPVKw@mail.gmail.com>
 <CAL9jLabfQuQnj+RLTMgCcgEb=s=g-vvLA7-A8MVUXja43Dj0kg@mail.gmail.com>
 <7B89FED8-D9BD-4283-B21F-C0697D57DDC8@bogus.com>
Message-ID: <CAL9jLaYNTt1Gqb61AvtLLezLuSdAWt8DHTs62vYAcTv9_8oxew@mail.gmail.com>

On Sat, Oct 5, 2013 at 2:08 PM, joel jaeggli <joelja at bogus.com> wrote:
>
> On Oct 5, 2013, at 9:45 AM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
>
>> you really don't want to do policy routing :(
>>
>
> PBR has this tendency to be brittle in the face of topology changes.

yup, exactly my point :(

> There are much better way to outbound load-balance between providers offering same or similar quality routes to the same destination.
>
> multi-AS multipath will do that if the peers are on the same router. BGPaddpath
> can do it for you if the peers are spread across routers.

these both will require seeing the longer prefix from the right peer
though, right? and selecting that would just be like natural selection
anyway...

yikes, I suppose you could:
  1) generate the longer prefix internally
  2) set it's next-hop to something reachable out both (all) peers
  3) metric the preferred peer's next-hop appropriately
  4) profit

but that sounds also kind of messy and prone to odd failures when
changes are made :(
you'd be adding complexity that you'd have to track through the life
of your network :( (and explain to anyone 'not you' working on the
network)

-chris

> joel
>
>> On Sat, Oct 5, 2013 at 12:19 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:
>>> Hello there!
>>>
>>>
>>> I am trying to do a source based outbound routing between multiple
>>> upstreams. Usually I picked outbound via localpref but here I wish to use
>>> Provider 1 for say 10.10.10.0/24 while provider 2 for small chunk of it say
>>> 10.10.10.0/28. I wish to keep failover support and thus so if provider 2
>>> fails, I wish to push traffic again via Provider 1.
>>>
>>> Is this is possible only with VRF or I can push for some specific match
>>> rule in route maps?
>>>
>>>
>>>
>>> Thanks.
>>>
>>> --
>>>
>>>
>>>
>>> Anurag Bhatia
>>> anuragbhatia.com
>>>
>>> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
>>> Twitter<https://twitter.com/anurag_bhatia>
>>> Skype: anuragbhatia.com
>>
>


From joelja at bogus.com  Sat Oct  5 18:55:09 2013
From: joelja at bogus.com (joel jaeggli)
Date: Sat, 5 Oct 2013 11:55:09 -0700
Subject: Regarding source based outbound routing (with redundancy)
In-Reply-To: <CAL9jLaYNTt1Gqb61AvtLLezLuSdAWt8DHTs62vYAcTv9_8oxew@mail.gmail.com>
References: <CAJ0+aXZFWaXRMZBrZ+E3DDW6ZikLpYnV2-pR2oWrdLGU-CPVKw@mail.gmail.com>
 <CAL9jLabfQuQnj+RLTMgCcgEb=s=g-vvLA7-A8MVUXja43Dj0kg@mail.gmail.com>
 <7B89FED8-D9BD-4283-B21F-C0697D57DDC8@bogus.com>
 <CAL9jLaYNTt1Gqb61AvtLLezLuSdAWt8DHTs62vYAcTv9_8oxew@mail.gmail.com>
Message-ID: <ED4D5CA3-BE85-4173-956A-B99D6AF01ADE@bogus.com>


On Oct 5, 2013, at 11:43 AM, Christopher Morrow <morrowc.lists at gmail.com> wrote:

> On Sat, Oct 5, 2013 at 2:08 PM, joel jaeggli <joelja at bogus.com> wrote:
>> 
>> On Oct 5, 2013, at 9:45 AM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
>> 
>>> you really don't want to do policy routing :(
>>> 
>> 
>> PBR has this tendency to be brittle in the face of topology changes.
> 
> yup, exactly my point :(
> 
>> There are much better way to outbound load-balance between providers offering same or similar quality routes to the same destination.
>> 
>> multi-AS multipath will do that if the peers are on the same router. BGPaddpath
>> can do it for you if the peers are spread across routers.
> 
> these both will require seeing the longer prefix from the right peer
> though, right? and selecting that would just be like natural selection
> anyway?

so at this level if I can install two best paths in the fib then great I'll just hash flows between them? this does nothing for source based path selection but it does a lot for load-balancing between peers especially if there's substantial overlap of equidistant paths. If you have say 2914/3356 and you look at the amount of traffic that you can load-balance between them instead of simply tie-breaking on router-id or however far do your path algorythm you get, it's significant enough to matter.

> yikes, I suppose you could:
>  1) generate the longer prefix internally
>  2) set it's next-hop to something reachable out both (all) peers
>  3) metric the preferred peer's next-hop appropriately
>  4) profit
> 
> but that sounds also kind of messy and prone to odd failures when
> changes are made :(

I go for the low hanging fruit, which is better usage of the information I already have.

> you'd be adding complexity that you'd have to track through the life
> of your network :( (and explain to anyone 'not you' working on the
> network)
> 
> -chris
> 
>> joel
>> 
>>> On Sat, Oct 5, 2013 at 12:19 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:
>>>> Hello there!
>>>> 
>>>> 
>>>> I am trying to do a source based outbound routing between multiple
>>>> upstreams. Usually I picked outbound via localpref but here I wish to use
>>>> Provider 1 for say 10.10.10.0/24 while provider 2 for small chunk of it say
>>>> 10.10.10.0/28. I wish to keep failover support and thus so if provider 2
>>>> fails, I wish to push traffic again via Provider 1.
>>>> 
>>>> Is this is possible only with VRF or I can push for some specific match
>>>> rule in route maps?
>>>> 
>>>> 
>>>> 
>>>> Thanks.
>>>> 
>>>> --
>>>> 
>>>> 
>>>> 
>>>> Anurag Bhatia
>>>> anuragbhatia.com
>>>> 
>>>> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
>>>> Twitter<https://twitter.com/anurag_bhatia>
>>>> Skype: anuragbhatia.com
>>> 
>> 
> 

-------------- 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/20131005/4f121913/attachment-0001.bin>

From freimer at freimer.org  Sat Oct  5 18:56:25 2013
From: freimer at freimer.org (Fred Reimer)
Date: Sat, 5 Oct 2013 18:56:25 +0000
Subject: Regarding source based outbound routing (with redundancy)
In-Reply-To: <CAL9jLaYNTt1Gqb61AvtLLezLuSdAWt8DHTs62vYAcTv9_8oxew@mail.gmail.com>
Message-ID: <CE75D803.2EF3C%freimer@freimer.org>

I would need to lab it up, but assuming a MPLS core, can't you do a TE
tunnel from the source to the desired egress router?

On 10/5/13 2:43 PM, "Christopher Morrow" <morrowc.lists at gmail.com> wrote:

>On Sat, Oct 5, 2013 at 2:08 PM, joel jaeggli <joelja at bogus.com> wrote:
>>
>> On Oct 5, 2013, at 9:45 AM, Christopher Morrow
>><morrowc.lists at gmail.com> wrote:
>>
>>> you really don't want to do policy routing :(
>>>
>>
>> PBR has this tendency to be brittle in the face of topology changes.
>
>yup, exactly my point :(
>
>> There are much better way to outbound load-balance between providers
>>offering same or similar quality routes to the same destination.
>>
>> multi-AS multipath will do that if the peers are on the same router.
>>BGPaddpath
>> can do it for you if the peers are spread across routers.
>
>these both will require seeing the longer prefix from the right peer
>though, right? and selecting that would just be like natural selection
>anyway...
>
>yikes, I suppose you could:
>  1) generate the longer prefix internally
>  2) set it's next-hop to something reachable out both (all) peers
>  3) metric the preferred peer's next-hop appropriately
>  4) profit
>
>but that sounds also kind of messy and prone to odd failures when
>changes are made :(
>you'd be adding complexity that you'd have to track through the life
>of your network :( (and explain to anyone 'not you' working on the
>network)
>
>-chris
>
>> joel
>>
>>> On Sat, Oct 5, 2013 at 12:19 PM, Anurag Bhatia <me at anuragbhatia.com>
>>>wrote:
>>>> Hello there!
>>>>
>>>>
>>>> I am trying to do a source based outbound routing between multiple
>>>> upstreams. Usually I picked outbound via localpref but here I wish to
>>>>use
>>>> Provider 1 for say 10.10.10.0/24 while provider 2 for small chunk of
>>>>it say
>>>> 10.10.10.0/28. I wish to keep failover support and thus so if
>>>>provider 2
>>>> fails, I wish to push traffic again via Provider 1.
>>>>
>>>> Is this is possible only with VRF or I can push for some specific
>>>>match
>>>> rule in route maps?
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>> Anurag Bhatia
>>>> anuragbhatia.com
>>>>
>>>> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
>>>> Twitter<https://twitter.com/anurag_bhatia>
>>>> Skype: anuragbhatia.com
>>>
>>
>



From ccariffe at gmail.com  Sun Oct  6 02:19:44 2013
From: ccariffe at gmail.com (Chris Cariffe)
Date: Sat, 5 Oct 2013 19:19:44 -0700
Subject: Phoenix - Single Mode SFP GBIC
Message-ID: <CALYAOvZ9CMCZBP=c46TL8GEYR2K37icrXGsKBtq24rt8OvjGDg@mail.gmail.com>

Any chance someone can help me out with one in the Phoenix area?  Tried
Fry's, MMF only...
CDW won't get one here till Tuesday.
thanks

-chris

From randy at psg.com  Sun Oct  6 03:06:06 2013
From: randy at psg.com (Randy Bush)
Date: Sun, 06 Oct 2013 12:06:06 +0900
Subject: apt-mirror near ashburn
In-Reply-To: <CAL9jLaZX8Qh==grYQ2bd-ZJwdDngUA4_NpegrE9cCwyuc2wpLw@mail.gmail.com>
References: <m2bo342cfz.wl%randy@psg.com>
 <CAL9jLaZX8Qh==grYQ2bd-ZJwdDngUA4_NpegrE9cCwyuc2wpLw@mail.gmail.com>
Message-ID: <m2hacvgktd.wl%randy@psg.com>

{{{
$apt-get install libsm6
...
After this operation, 717 kB of additional disk space will be used.
Do you want to continue [Y/n]? 
WARNING: The following packages cannot be authenticated!
  x11-common libice6 libsm6
Install these packages without verification [y/N]? 
}}}

hmmmmm.  ft meade can't even hack the checksums?

randy


From morrowc.lists at gmail.com  Sun Oct  6 03:11:58 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 5 Oct 2013 23:11:58 -0400
Subject: apt-mirror near ashburn
In-Reply-To: <m2hacvgktd.wl%randy@psg.com>
References: <m2bo342cfz.wl%randy@psg.com>
 <CAL9jLaZX8Qh==grYQ2bd-ZJwdDngUA4_NpegrE9cCwyuc2wpLw@mail.gmail.com>
 <m2hacvgktd.wl%randy@psg.com>
Message-ID: <CAL9jLab3D0XjUzRtZHtftC_nr98j_hdEvbUoFt0if_4Pvs4PfQ@mail.gmail.com>

On Sat, Oct 5, 2013 at 11:06 PM, Randy Bush <randy at psg.com> wrote:
> {{{
> $apt-get install libsm6
> ...
> After this operation, 717 kB of additional disk space will be used.
> Do you want to continue [Y/n]?
> WARNING: The following packages cannot be authenticated!
>   x11-common libice6 libsm6
> Install these packages without verification [y/N]?
> }}}
>
> hmmmmm.  ft meade can't even hack the checksums?

possibly the mirror is just misbehaving :( it's been a while since i
ran it, so I'm honestly not sure what's going on with it these days.

-chris


From infolacnog at lacnog.org  Mon Oct  7 14:14:08 2013
From: infolacnog at lacnog.org (LACNOG 2013)
Date: Mon, 7 Oct 2013 12:14:08 -0200
Subject: =?ISO-8859-1?Q?LACNOG_2013_=2D_Cura=E7ao_=2D_October_28?=
Message-ID: <CAKfZcEtmC2uwVNmmoCs0QP-dADhxUyOG_f2v2ab4XjaZzzC9zg@mail.gmail.com>

The Lacnog 2013 and Lacnic 20 meetings will take place in three weeks
(October 28) in Cura?ao.

Please register asap if you're planning to attend. The main hotel is full,
but a neighboring hotel, closer to the convention center has available
rooms.

A peering forum is scheduled for Tuesday 29 and Wednesday 30. Please
contact infolacnog at lacnog.org if you want to take part.

Look forward to seeing you there,

The Lacnog Program Committee

From sroche at lakelandnetworks.com  Mon Oct  7 13:45:50 2013
From: sroche at lakelandnetworks.com (Sam Roche)
Date: Mon, 7 Oct 2013 09:45:50 -0400
Subject: Phoenix - Single Mode SFP GBIC
In-Reply-To: <CALYAOvZ9CMCZBP=c46TL8GEYR2K37icrXGsKBtq24rt8OvjGDg@mail.gmail.com>
References: <CALYAOvZ9CMCZBP=c46TL8GEYR2K37icrXGsKBtq24rt8OvjGDg@mail.gmail.com>
Message-ID: <50DE6F70588444499E383C5102155B89016A0194@energyops.lakelandenergy.local>

Try sfpplus, compufox or fiberstore.com


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: Chris Cariffe [mailto:ccariffe at gmail.com] 
Sent: October 5, 2013 10:20 PM
To: NANOG
Subject: Phoenix - Single Mode SFP GBIC

Any chance someone can help me out with one in the Phoenix area?  Tried Fry's, MMF only...
CDW won't get one here till Tuesday.
thanks

-chris


From rdrake at direcpath.com  Mon Oct  7 14:47:13 2013
From: rdrake at direcpath.com (Robert Drake)
Date: Mon, 07 Oct 2013 10:47:13 -0400
Subject: apt-mirror near ashburn
In-Reply-To: <CAL9jLab3D0XjUzRtZHtftC_nr98j_hdEvbUoFt0if_4Pvs4PfQ@mail.gmail.com>
References: <m2bo342cfz.wl%randy@psg.com>
 <CAL9jLaZX8Qh==grYQ2bd-ZJwdDngUA4_NpegrE9cCwyuc2wpLw@mail.gmail.com>
 <m2hacvgktd.wl%randy@psg.com>
 <CAL9jLab3D0XjUzRtZHtftC_nr98j_hdEvbUoFt0if_4Pvs4PfQ@mail.gmail.com>
Message-ID: <5252C971.4030604@direcpath.com>

My suggestion is to use http://http.debian.net/debian as your source.  
It uses geo thingie to figure out the closest mirror to you.


Code is on github if you're interested in how it works.
https://github.com/rgeissert/http-redirector


On 10/5/2013 11:11 PM, Christopher Morrow wrote:
> On Sat, Oct 5, 2013 at 11:06 PM, Randy Bush <randy at psg.com> wrote:
>> {{{
>> $apt-get install libsm6
>> ...
>> After this operation, 717 kB of additional disk space will be used.
>> Do you want to continue [Y/n]?
>> WARNING: The following packages cannot be authenticated!
>>    x11-common libice6 libsm6
>> Install these packages without verification [y/N]?
>> }}}
>>
>> hmmmmm.  ft meade can't even hack the checksums?
> possibly the mirror is just misbehaving :( it's been a while since i
> ran it, so I'm honestly not sure what's going on with it these days.
>
> -chris
>


From elouie at yahoo.com  Mon Oct  7 14:54:07 2013
From: elouie at yahoo.com (Eric A Louie)
Date: Mon, 7 Oct 2013 07:54:07 -0700 (PDT)
Subject: Phoenix - Single Mode SFP GBIC
In-Reply-To: <CALYAOvZ9CMCZBP=c46TL8GEYR2K37icrXGsKBtq24rt8OvjGDg@mail.gmail.com>
References: <CALYAOvZ9CMCZBP=c46TL8GEYR2K37icrXGsKBtq24rt8OvjGDg@mail.gmail.com>
Message-ID: <1381157647.71291.YahooMailNeo@web181601.mail.ne1.yahoo.com>

try calling the local datacenters and see if one of them will "loan" you one for a day or two.





>________________________________
> From: Chris Cariffe <ccariffe at gmail.com>
>To: NANOG <nanog at nanog.org> 
>Sent: Saturday, October 5, 2013 7:19 PM
>Subject: Phoenix - Single Mode SFP GBIC
> 
>
>Any chance someone can help me out with one in the Phoenix area?? Tried
>Fry's, MMF only...
>CDW won't get one here till Tuesday.
>thanks
>
>-chris
>
>
>

From michael at pbandjelly.org  Mon Oct  7 15:16:25 2013
From: michael at pbandjelly.org (Michael Shuler)
Date: Mon, 07 Oct 2013 10:16:25 -0500
Subject: apt-mirror near ashburn
In-Reply-To: <5252C971.4030604@direcpath.com>
References: <m2bo342cfz.wl%randy@psg.com>
 <CAL9jLaZX8Qh==grYQ2bd-ZJwdDngUA4_NpegrE9cCwyuc2wpLw@mail.gmail.com>
 <m2hacvgktd.wl%randy@psg.com>
 <CAL9jLab3D0XjUzRtZHtftC_nr98j_hdEvbUoFt0if_4Pvs4PfQ@mail.gmail.com>
 <5252C971.4030604@direcpath.com>
Message-ID: <5252D049.107@pbandjelly.org>

On 10/07/2013 09:47 AM, Robert Drake wrote:
> My suggestion is to use http://http.debian.net/debian

Ubuntu != Debian

-- 
Kind regards,
Michael



From jared at puck.nether.net  Mon Oct  7 15:21:42 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 7 Oct 2013 10:21:42 -0500
Subject: Att mobility LTE contact
Message-ID: <DBEB0182-668D-45B5-B27E-70D58430F527@puck.nether.net>

Anyone from mobility around? You have turned on some new towers around me with the wrong time zone. (Lansing, Chelsea, dexter all in Michigan). 

Only seems to be wrong on the LTE and not the 3G/4G side. 

Thanks!

Jared Mauch

From rdrake at direcpath.com  Mon Oct  7 16:12:33 2013
From: rdrake at direcpath.com (Robert Drake)
Date: Mon, 07 Oct 2013 12:12:33 -0400
Subject: apt-mirror near ashburn
In-Reply-To: <5252D049.107@pbandjelly.org>
References: <m2bo342cfz.wl%randy@psg.com>
 <CAL9jLaZX8Qh==grYQ2bd-ZJwdDngUA4_NpegrE9cCwyuc2wpLw@mail.gmail.com>
 <m2hacvgktd.wl%randy@psg.com>
 <CAL9jLab3D0XjUzRtZHtftC_nr98j_hdEvbUoFt0if_4Pvs4PfQ@mail.gmail.com>
 <5252C971.4030604@direcpath.com> <5252D049.107@pbandjelly.org>
Message-ID: <5252DD71.80501@direcpath.com>


On 10/7/2013 11:16 AM, Michael Shuler wrote:
> Ubuntu != Debian 
http://askubuntu.com/questions/157840/why-does-apt-get-fail-to-resolve-the-mirror

Apparently mirrors.ubuntu.com picks a mirror based on geographical 
location using lines like this:

|deb mirror://mirrors.ubuntu.com/mirrors.txt precise main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt precise-updates main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt precise-backports main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt precise-security main restricted universe multiverse

I'm not sure how good it is at picking a mirror though.  ubuntu seems to make a mess of the sources.list
file and makes it scary to change.  I always leave it with the mirror I chose during install.

This:
https://help.ubuntu.com/community/SourcesList

Says you can pick "Select Best Server" from a menu.  That would probably work okay if it's not a headless box.
|


From ak47 at gawul.net  Mon Oct  7 16:56:58 2013
From: ak47 at gawul.net (Andrew Koch)
Date: Mon, 7 Oct 2013 09:56:58 -0700
Subject: nanog.org website
Message-ID: <F86FF527-06D7-4297-8931-389F3D058B8E@gawul.net>

We are aware of trouble with the NANOG website. The NANOG geeks have been dispatched to work on the trouble. Please be patient if you are trying to view the site. 

Andrew Koch
on behalf of the NANOG Communications Committee



From morrowc.lists at gmail.com  Mon Oct  7 17:51:31 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 7 Oct 2013 13:51:31 -0400
Subject: apt-mirror near ashburn
In-Reply-To: <5252DD71.80501@direcpath.com>
References: <m2bo342cfz.wl%randy@psg.com>
 <CAL9jLaZX8Qh==grYQ2bd-ZJwdDngUA4_NpegrE9cCwyuc2wpLw@mail.gmail.com>
 <m2hacvgktd.wl%randy@psg.com>
 <CAL9jLab3D0XjUzRtZHtftC_nr98j_hdEvbUoFt0if_4Pvs4PfQ@mail.gmail.com>
 <5252C971.4030604@direcpath.com> <5252D049.107@pbandjelly.org>
 <5252DD71.80501@direcpath.com>
Message-ID: <CAL9jLaaB+=FPyrsCcBhZ3W8OUw7tnuOf5uZ+K6ukB-wXK5-W1Q@mail.gmail.com>

there's also the unfortunate case of: "My traffic to the selected
mirror is over the 'expensive' transit port, why can't I use my SFP's
mirror over there on the left?"

setting the mirror to a specific one means some fragility, but
determinism is nice.

On Mon, Oct 7, 2013 at 12:12 PM, Robert Drake <rdrake at direcpath.com> wrote:
>
> On 10/7/2013 11:16 AM, Michael Shuler wrote:
>>
>> Ubuntu != Debian
>
> http://askubuntu.com/questions/157840/why-does-apt-get-fail-to-resolve-the-mirror
>
> Apparently mirrors.ubuntu.com picks a mirror based on geographical location
> using lines like this:
>
> |deb mirror://mirrors.ubuntu.com/mirrors.txt precise main restricted
> universe multiverse
> deb mirror://mirrors.ubuntu.com/mirrors.txt precise-updates main restricted
> universe multiverse
> deb mirror://mirrors.ubuntu.com/mirrors.txt precise-backports main
> restricted universe multiverse
> deb mirror://mirrors.ubuntu.com/mirrors.txt precise-security main restricted
> universe multiverse
>
> I'm not sure how good it is at picking a mirror though.  ubuntu seems to
> make a mess of the sources.list
> file and makes it scary to change.  I always leave it with the mirror I
> chose during install.
>
> This:
> https://help.ubuntu.com/community/SourcesList
>
> Says you can pick "Select Best Server" from a menu.  That would probably
> work okay if it's not a headless box.
> |
>


From seitz at bsd-unix.net  Mon Oct  7 18:10:31 2013
From: seitz at bsd-unix.net (Bryan Seitz)
Date: Mon, 7 Oct 2013 14:10:31 -0400
Subject: apt-mirror near ashburn
In-Reply-To: <CAL9jLaaB+=FPyrsCcBhZ3W8OUw7tnuOf5uZ+K6ukB-wXK5-W1Q@mail.gmail.com>
References: <m2bo342cfz.wl%randy@psg.com>
 <CAL9jLaZX8Qh==grYQ2bd-ZJwdDngUA4_NpegrE9cCwyuc2wpLw@mail.gmail.com>
 <m2hacvgktd.wl%randy@psg.com>
 <CAL9jLab3D0XjUzRtZHtftC_nr98j_hdEvbUoFt0if_4Pvs4PfQ@mail.gmail.com>
 <5252C971.4030604@direcpath.com> <5252D049.107@pbandjelly.org>
 <5252DD71.80501@direcpath.com>
 <CAL9jLaaB+=FPyrsCcBhZ3W8OUw7tnuOf5uZ+K6ukB-wXK5-W1Q@mail.gmail.com>
Message-ID: <20131007181031.GA83772@bsd-unix.net>

mirror.symnds.com has debian/ubuntu and is in Ashburn on Above.net FYI.

On Mon, Oct 07, 2013 at 01:51:31PM -0400, Christopher Morrow wrote:
> there's also the unfortunate case of: "My traffic to the selected
> mirror is over the 'expensive' transit port, why can't I use my SFP's
> mirror over there on the left?"
> 
> setting the mirror to a specific one means some fragility, but
> determinism is nice.
> 
> On Mon, Oct 7, 2013 at 12:12 PM, Robert Drake <rdrake at direcpath.com> wrote:
> >
> > On 10/7/2013 11:16 AM, Michael Shuler wrote:
> >>
> >> Ubuntu != Debian
> >
> > http://askubuntu.com/questions/157840/why-does-apt-get-fail-to-resolve-the-mirror
> >
> > Apparently mirrors.ubuntu.com picks a mirror based on geographical location
> > using lines like this:
> >
> > |deb mirror://mirrors.ubuntu.com/mirrors.txt precise main restricted
> > universe multiverse
> > deb mirror://mirrors.ubuntu.com/mirrors.txt precise-updates main restricted
> > universe multiverse
> > deb mirror://mirrors.ubuntu.com/mirrors.txt precise-backports main
> > restricted universe multiverse
> > deb mirror://mirrors.ubuntu.com/mirrors.txt precise-security main restricted
> > universe multiverse
> >
> > I'm not sure how good it is at picking a mirror though.  ubuntu seems to
> > make a mess of the sources.list
> > file and makes it scary to change.  I always leave it with the mirror I
> > chose during install.
> >
> > This:
> > https://help.ubuntu.com/community/SourcesList
> >
> > Says you can pick "Select Best Server" from a menu.  That would probably
> > work okay if it's not a headless box.
> > |
> >

-- 
             
Bryan G. Seitz


From ak47 at gawul.net  Mon Oct  7 19:13:13 2013
From: ak47 at gawul.net (Andrew Koch)
Date: Mon, 7 Oct 2013 12:13:13 -0700
Subject: nanog.org website
In-Reply-To: <F86FF527-06D7-4297-8931-389F3D058B8E@gawul.net>
References: <F86FF527-06D7-4297-8931-389F3D058B8E@gawul.net>
Message-ID: <1E6929DF-0D61-4E20-BF9D-BE3759EEB039@gawul.net>

The NANOG web site will be offline starting at 12:15 Pacific time for
hardware maintenance.  We expect the outage to last at least 10 minutes
but no longer than 45 minutes.  We apologize for the inconvenience. 

> On Oct 7, 2013, at 9:56, Andrew Koch <ak47 at gawul.net> wrote:
> 
> We are aware of trouble with the NANOG website. The NANOG geeks have been dispatched to work on the trouble. Please be patient if you are trying to view the site. 
> 
> Andrew Koch
> on behalf of the NANOG Communications Committee
> 

From jason at unlimitednet.us  Mon Oct  7 20:33:30 2013
From: jason at unlimitednet.us (Jason Canady)
Date: Mon, 07 Oct 2013 16:33:30 -0400
Subject: Removal of Stale Level 3 IRR Object
Message-ID: <52531A9A.4070001@unlimitednet.us>

Would someone from Level 3 please contact me off-list regarding removal 
of stale IRR removal?  Our ASN was previously used by another 
organization and they had an IRR listed with Level 3.

AS11990

Thank you!

-- 

Jason Canady
Unlimited Net, LLC
Responsive, Reliable, Secure

www.unlimitednet.us
jason at unlimitednet.us
twitter: @unlimitednet



From randy at psg.com  Mon Oct  7 22:00:08 2013
From: randy at psg.com (Randy Bush)
Date: Tue, 08 Oct 2013 07:00:08 +0900
Subject: apt-mirror near ashburn
In-Reply-To: <m2bo342cfz.wl%randy@psg.com>
References: <m2bo342cfz.wl%randy@psg.com>
Message-ID: <m2d2ngbv2v.wl%randy@psg.com>

i gave up and put up my own freeping ubuntu apt-mirror

randy


From ak47 at gawul.net  Mon Oct  7 22:14:08 2013
From: ak47 at gawul.net (Andrew Koch)
Date: Mon, 7 Oct 2013 17:14:08 -0500
Subject: nanog.org website
In-Reply-To: <1E6929DF-0D61-4E20-BF9D-BE3759EEB039@gawul.net>
References: <F86FF527-06D7-4297-8931-389F3D058B8E@gawul.net>
 <1E6929DF-0D61-4E20-BF9D-BE3759EEB039@gawul.net>
Message-ID: <20131007221408.GA28495@bucket.gawul.net>

A second maintenance will be happening at 15:30 PDT to work on the
existing server problems. The website will be restored as quickly as
possible.  Thanks for your understanding..



> On Oct 7, 2013, at 9:56, Andrew Koch <ak47 at gawul.net> wrote:
> 
>    We are aware of trouble with the NANOG website. The NANOG geeks have
>    been dispatched to work on the trouble. Please be patient if you are
>    trying to view the site.
>    Andrew Koch
>    on behalf of the NANOG Communications Committee
> 


From ak47 at gawul.net  Mon Oct  7 23:24:52 2013
From: ak47 at gawul.net (Andrew Koch)
Date: Mon, 7 Oct 2013 18:24:52 -0500
Subject: nanog.org website - restored
In-Reply-To: <20131007221408.GA28495@bucket.gawul.net>
References: <F86FF527-06D7-4297-8931-389F3D058B8E@gawul.net>
 <1E6929DF-0D61-4E20-BF9D-BE3759EEB039@gawul.net>
 <20131007221408.GA28495@bucket.gawul.net>
Message-ID: <20131007232452.GB28495@bucket.gawul.net>

We believe the server is now at a stable point and all functions of the
NANOG website and mailing list are restored.

For those interested, we would like to share some details of this event.
It was noticed a couple weeks ago that a lack of memory conditon was
present on the NANOG servers in Chicago.  Temporary measures were taken
to clear processes and restart the server, but this only temporarialy
restored the server.

Working with onsite personel to upgrade the server with additional
memory failed during the first announced maintenance.  Compatible memory
was located and tested leading to the second maintenance when it was
successfully installed.

At this time we have increased the memory on the server and are at a
stable point.

NANOG is making plans to move the NANOG web and mail services off this
platform to an environment that is more capable.  We will inform the
community of any maintenance plans as we move forward.

Thank you for your understanding.

Andrew Koch
on behalf of the NANOG Communications Committee


From mike at mtcc.com  Mon Oct  7 23:54:08 2013
From: mike at mtcc.com (Michael Thomas)
Date: Mon, 07 Oct 2013 16:54:08 -0700
Subject: nanog.org website - restored
In-Reply-To: <20131007232452.GB28495@bucket.gawul.net>
References: <F86FF527-06D7-4297-8931-389F3D058B8E@gawul.net>
 <1E6929DF-0D61-4E20-BF9D-BE3759EEB039@gawul.net>
 <20131007221408.GA28495@bucket.gawul.net>
 <20131007232452.GB28495@bucket.gawul.net>
Message-ID: <525349A0.2090805@mtcc.com>

On 10/7/13 4:24 PM, Andrew Koch wrote:
> Working with onsite personel to upgrade the server with additional
> memory failed during the first announced maintenance.  Compatible memory
> was located and tested leading to the second maintenance when it was
> successfully installed.
>
> At this time we have increased the memory on the server and are at a
> stable point.
>

How primative. When i want more memory I just log into the provider's
web console and tell it I want more geebees.

Mike


From garrett at skjelstad.org  Tue Oct  8 00:16:36 2013
From: garrett at skjelstad.org (Garrett Skjelstad)
Date: Mon, 7 Oct 2013 17:16:36 -0700
Subject: nanog.org website - restored
In-Reply-To: <525349A0.2090805@mtcc.com>
References: <F86FF527-06D7-4297-8931-389F3D058B8E@gawul.net>
 <1E6929DF-0D61-4E20-BF9D-BE3759EEB039@gawul.net>
 <20131007221408.GA28495@bucket.gawul.net>
 <20131007232452.GB28495@bucket.gawul.net> <525349A0.2090805@mtcc.com>
Message-ID: <6BC934DE-3958-4E1C-BF44-418ED3613458@skjelstad.org>

Perhaps you'd like to donate geebees to a nonprofit?

Sent from my (old) iPhone5

On Oct 7, 2013, at 16:54, Michael Thomas <mike at mtcc.com> wrote:

> On 10/7/13 4:24 PM, Andrew Koch wrote:
>> Working with onsite personel to upgrade the server with additional
>> memory failed during the first announced maintenance.  Compatible memory
>> was located and tested leading to the second maintenance when it was
>> successfully installed.
>> 
>> At this time we have increased the memory on the server and are at a
>> stable point.
> 
> How primative. When i want more memory I just log into the provider's
> web console and tell it I want more geebees.
> 
> Mike
> 


From rubensk at gmail.com  Tue Oct  8 00:20:32 2013
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 7 Oct 2013 21:20:32 -0300
Subject: nanog.org website - restored
In-Reply-To: <20131007232452.GB28495@bucket.gawul.net>
References: <F86FF527-06D7-4297-8931-389F3D058B8E@gawul.net>
 <1E6929DF-0D61-4E20-BF9D-BE3759EEB039@gawul.net>
 <20131007221408.GA28495@bucket.gawul.net>
 <20131007232452.GB28495@bucket.gawul.net>
Message-ID: <CAGFn2k0fve4agFFjZKen21jSePmSE_2miZ1PHnCOE7Ox47KqnA@mail.gmail.com>

For those interested, we would like to share some details of this event.

> It was noticed a couple weeks ago that a lack of memory conditon was
> present on the NANOG servers in Chicago.  Temporary measures were taken
> to clear processes and restart the server, but this only temporarialy
> restored the server.
>
> Working with onsite personel to upgrade the server with additional
> memory failed during the first announced maintenance.  Compatible memory
> was located and tested leading to the second maintenance when it was
> successfully installed.
>
> At this time we have increased the memory on the server and are at a
> stable point.
>

If the file from the presentation about NSA spying is removed from the
server, it's possible it suddenly starts to be stable again.


Rubens

From bedard.phil at gmail.com  Tue Oct  8 00:49:56 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Mon, 7 Oct 2013 17:49:56 -0700
Subject: nanog.org website - restored
Message-ID: <724878429644238924@unknownmsgid>

Yeah isn't there some cloud provider like Amazon, Rackspace, or MS
willing to donate some BW and CPU cycles? Would be a drop in the bucket.

Phil From: Michael Thomas
Sent: 10/7/2013 19:57
To: nanog at nanog.org
Subject: Re: nanog.org website - restored
On 10/7/13 4:24 PM, Andrew Koch wrote:
> Working with onsite personel to upgrade the server with additional
> memory failed during the first announced maintenance.  Compatible memory
> was located and tested leading to the second maintenance when it was
> successfully installed.
>
> At this time we have increased the memory on the server and are at a
> stable point.
>

How primative. When i want more memory I just log into the provider's
web console and tell it I want more geebees.

Mike


From wbailey at satelliteintelligencegroup.com  Tue Oct  8 01:00:06 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 8 Oct 2013 01:00:06 +0000
Subject: nanog.org website - restored
In-Reply-To: <724878429644238924@unknownmsgid>
References: <724878429644238924@unknownmsgid>
Message-ID: <d8pwdu42wog4kcd0pl35g2l0.1381193998540@email.android.com>

Or throw one less gathering a year?


Sent from my Mobile Device.


-------- Original message --------
From: Phil Bedard <bedard.phil at gmail.com>
Date: 10/07/2013 5:53 PM (GMT-08:00)
To: Michael Thomas <mike at mtcc.com>,nanog at nanog.org
Subject: RE: nanog.org website - restored


Yeah isn't there some cloud provider like Amazon, Rackspace, or MS
willing to donate some BW and CPU cycles? Would be a drop in the bucket.

Phil From: Michael Thomas
Sent: 10/7/2013 19:57
To: nanog at nanog.org
Subject: Re: nanog.org website - restored
On 10/7/13 4:24 PM, Andrew Koch wrote:
> Working with onsite personel to upgrade the server with additional
> memory failed during the first announced maintenance.  Compatible memory
> was located and tested leading to the second maintenance when it was
> successfully installed.
>
> At this time we have increased the memory on the server and are at a
> stable point.
>

How primative. When i want more memory I just log into the provider's
web console and tell it I want more geebees.

Mike


From alex at corp.nac.net  Tue Oct  8 01:24:25 2013
From: alex at corp.nac.net (Alex Rubenstein)
Date: Mon, 7 Oct 2013 21:24:25 -0400
Subject: nanog.org website - restored
In-Reply-To: <724878429644238924@unknownmsgid>
References: <724878429644238924@unknownmsgid>
Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB82C74E0C812@EXCHMBX.hq.nac.net>

I have, and would.


> -----Original Message-----
> From: Phil Bedard [mailto:bedard.phil at gmail.com]
> Sent: Monday, October 07, 2013 8:50 PM
> To: Michael Thomas; nanog at nanog.org
> Subject: RE: nanog.org website - restored
> 
> Yeah isn't there some cloud provider like Amazon, Rackspace, or MS willing to
> donate some BW and CPU cycles? Would be a drop in the bucket.
> 
> Phil From: Michael Thomas
> Sent: 10/7/2013 19:57
> To: nanog at nanog.org
> Subject: Re: nanog.org website - restored On 10/7/13 4:24 PM, Andrew Koch
> wrote:
> > Working with onsite personel to upgrade the server with additional
> > memory failed during the first announced maintenance.  Compatible
> > memory was located and tested leading to the second maintenance when
> > it was successfully installed.
> >
> > At this time we have increased the memory on the server and are at a
> > stable point.
> >
> 
> How primative. When i want more memory I just log into the provider's web
> console and tell it I want more geebees.
> 
> Mike


From j at arpa.com  Tue Oct  8 04:36:07 2013
From: j at arpa.com (jamie rishaw)
Date: Mon, 7 Oct 2013 23:36:07 -0500
Subject: nanog.org website - restored
In-Reply-To: <20131007232452.GB28495@bucket.gawul.net>
References: <F86FF527-06D7-4297-8931-389F3D058B8E@gawul.net>
 <1E6929DF-0D61-4E20-BF9D-BE3759EEB039@gawul.net>
 <20131007221408.GA28495@bucket.gawul.net>
 <20131007232452.GB28495@bucket.gawul.net>
Message-ID: <CAJ-M0Yn=nw1FngTy8DppVoJGaRoT2_CEM6YP_VfKwCu_CvdLaQ@mail.gmail.com>

Translated:


On Mon, Oct 7, 2013 at 6:24 PM, Andrew Koch <ak47 at gawul.net> wrote:

> We believe the server is now at a stable point and all functions of the
>

"We hope that the"


> NANOG website and mailing list are restored.
>
> For those interested, we would like to share some details of this event.
> It was noticed a couple weeks ago that a lack of memory conditon[sic] was
> present on the NANOG servers in Chicago.  Temporary measures were taken
> to clear processes and restart the server, but this only temporarialy
> restored the server.
>

"Server swapped itself to death. We power cycled that bad boy"


> Working with onsite personel[sic] to upgrade the server with additional
> memory failed during the first announced maintenance.  Compatible memory
> was located and tested leading to the second maintenance when it was
> successfully installed.
>

"Added more ramz but only after remote hands wikipedia'd the right ram for
our vps"

>
> At this time we have increased the memory on the server and are at a
> stable point.
>

"Seems to work now we think"


NANOG is making plans to move the NANOG web and mail services off this
> platform to an environment that is more capable.  We will inform the
> community of any maintenance plans as we move forward.
>


"$1/mo hosting aint cutting it anymore; NANOG fees now +$99/attendee/event"



> Thank you for your understanding.
>

"closing ticket"


>
> Andrew Koch
> on behalf of the NANOG Communications Committee
>

"Got the short straw"

What happened to MERIT, A2 and the big tens rocking the mic fantastic?


j
-- 
"sharp, dry wit and brash in his dealings with contestants." - Forbes
If voting didn't matter, the GOP wouldn't make it more difficult than
buying a gun.
/*     - teh jamie. ;     uri -> http://about.me/jgr     */

From adam at mozilla.com  Tue Oct  8 01:43:19 2013
From: adam at mozilla.com (Adam  Newman)
Date: Mon, 7 Oct 2013 18:43:19 -0700 (PDT)
Subject: nanog.org website - restored
Message-ID: <416l7a2a8bgme2ltboaedna4.1381196589730@email.android.com>

I would be happy to donate a VM or two on my personal stack. Contact me if interested.?

-Adam

-------- Original message --------
From: Phil Bedard <bedard.phil at gmail.com> 
Date: 10/07/2013  5:51 PM  (GMT-08:00) 
To: Michael Thomas <mike at mtcc.com>,nanog at nanog.org 
Subject: RE: nanog.org website - restored 
 
Yeah isn't there some cloud provider like Amazon, Rackspace, or MS
willing to donate some BW and CPU cycles? Would be a drop in the bucket.

Phil From: Michael Thomas
Sent: 10/7/2013 19:57
To: nanog at nanog.org
Subject: Re: nanog.org website - restored
On 10/7/13 4:24 PM, Andrew Koch wrote:
> Working with onsite personel to upgrade the server with additional
> memory failed during the first announced maintenance.? Compatible memory
> was located and tested leading to the second maintenance when it was
> successfully installed.
>
> At this time we have increased the memory on the server and are at a
> stable point.
>

How primative. When i want more memory I just log into the provider's
web console and tell it I want more geebees.

Mike


From randy at psg.com  Tue Oct  8 06:37:29 2013
From: randy at psg.com (Randy Bush)
Date: Tue, 08 Oct 2013 15:37:29 +0900
Subject: nanog.org website - restored
In-Reply-To: <20131007232452.GB28495@bucket.gawul.net>
References: <F86FF527-06D7-4297-8931-389F3D058B8E@gawul.net>
 <1E6929DF-0D61-4E20-BF9D-BE3759EEB039@gawul.net>
 <20131007221408.GA28495@bucket.gawul.net>
 <20131007232452.GB28495@bucket.gawul.net>
Message-ID: <m261t89sk6.wl%randy@psg.com>

> For those interested, we would like to share some details of this event.
> It was noticed a couple weeks ago that a lack of memory conditon was
> present on the NANOG servers in Chicago.  Temporary measures were taken
> to clear processes and restart the server, but this only temporarialy
> restored the server.
> 
> Working with onsite personel to upgrade the server with additional
> memory failed during the first announced maintenance.  Compatible memory
> was located and tested leading to the second maintenance when it was
> successfully installed.
> 
> At this time we have increased the memory on the server and are at a
> stable point.

thank you for a simple, clear, and prompt post mortem.  my only
remaining curiosity is what was the original ram size and what is it
now.

randy


From mpetach at netflight.com  Tue Oct  8 07:19:55 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Tue, 8 Oct 2013 00:19:55 -0700
Subject: 2013.10.07 NANOG59 notes posted
Message-ID: <CAEmG1=r+cUpoyWfNUs53obxTr3cbc4SkLyHShGM8A_AqvHXP_g@mail.gmail.com>

sorry, my calendar's been a bit full
today; notes from the morning, afternoon,
community meeting, and datacenter BoF
track have been posted to

http://nanog.cluepon.net/index.php/NANOG59

I'll try to get them up a bit faster tomorrow,
sorry about the delay, it's been a really
busy day today.

Matt

From paradox at nac.net  Tue Oct  8 15:10:46 2013
From: paradox at nac.net (Ryan Pavely)
Date: Tue, 08 Oct 2013 11:10:46 -0400
Subject: nanog.org website - restored
In-Reply-To: <416l7a2a8bgme2ltboaedna4.1381196589730@email.android.com>
References: <416l7a2a8bgme2ltboaedna4.1381196589730@email.android.com>
Message-ID: <52542076.50204@nac.net>

I vote we go with Alex Rubenstein's offer to host..

   Ryan Pavely
    Net Access Corporation
    http://www.nac.net/

On 10/7/2013 9:43 PM, Adam Newman wrote:
> I would be happy to donate a VM or two on my personal stack. Contact me if interested.
>
> -Adam
>
> -------- Original message --------
> From: Phil Bedard <bedard.phil at gmail.com>
> Date: 10/07/2013  5:51 PM  (GMT-08:00)
> To: Michael Thomas <mike at mtcc.com>,nanog at nanog.org
> Subject: RE: nanog.org website - restored
>   
> Yeah isn't there some cloud provider like Amazon, Rackspace, or MS
> willing to donate some BW and CPU cycles? Would be a drop in the bucket.
>
> Phil From: Michael Thomas
> Sent: 10/7/2013 19:57
> To: nanog at nanog.org
> Subject: Re: nanog.org website - restored
> On 10/7/13 4:24 PM, Andrew Koch wrote:
>> Working with onsite personel to upgrade the server with additional
>> memory failed during the first announced maintenance.  Compatible memory
>> was located and tested leading to the second maintenance when it was
>> successfully installed.
>>
>> At this time we have increased the memory on the server and are at a
>> stable point.
>>
> How primative. When i want more memory I just log into the provider's
> web console and tell it I want more geebees.
>
> Mike
>



From mark at viviotech.net  Tue Oct  8 15:38:55 2013
From: mark at viviotech.net (Mark Keymer)
Date: Tue, 08 Oct 2013 08:38:55 -0700
Subject: nanog.org website - restored
In-Reply-To: <52542076.50204@nac.net>
References: <416l7a2a8bgme2ltboaedna4.1381196589730@email.android.com>
 <52542076.50204@nac.net>
Message-ID: <5254270F.3070207@viviotech.net>

I donno, I am thinking only if we get Super Cool "Extra Special" 
lighting around the Nanog server! ;)

Hehehe,

Sincerely,

Mark

On 10/8/2013 8:10 AM, Ryan Pavely wrote:
> I vote we go with Alex Rubenstein's offer to host..
>
>   Ryan Pavely
>    Net Access Corporation
>    http://www.nac.net/
>
> On 10/7/2013 9:43 PM, Adam Newman wrote:
>> I would be happy to donate a VM or two on my personal stack. Contact 
>> me if interested.
>>
>> -Adam
>>
>> -------- Original message --------
>> From: Phil Bedard <bedard.phil at gmail.com>
>> Date: 10/07/2013  5:51 PM  (GMT-08:00)
>> To: Michael Thomas <mike at mtcc.com>,nanog at nanog.org
>> Subject: RE: nanog.org website - restored
>>   Yeah isn't there some cloud provider like Amazon, Rackspace, or MS
>> willing to donate some BW and CPU cycles? Would be a drop in the bucket.
>>
>> Phil From: Michael Thomas
>> Sent: 10/7/2013 19:57
>> To: nanog at nanog.org
>> Subject: Re: nanog.org website - restored
>> On 10/7/13 4:24 PM, Andrew Koch wrote:
>>> Working with onsite personel to upgrade the server with additional
>>> memory failed during the first announced maintenance. Compatible memory
>>> was located and tested leading to the second maintenance when it was
>>> successfully installed.
>>>
>>> At this time we have increased the memory on the server and are at a
>>> stable point.
>>>
>> How primative. When i want more memory I just log into the provider's
>> web console and tell it I want more geebees.
>>
>> Mike
>>
>
>



From morrowc.lists at gmail.com  Tue Oct  8 15:40:35 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Oct 2013 11:40:35 -0400
Subject: nanog.org website - restored
In-Reply-To: <52542076.50204@nac.net>
References: <416l7a2a8bgme2ltboaedna4.1381196589730@email.android.com>
 <52542076.50204@nac.net>
Message-ID: <CAL9jLaYFOHeUfBiVf8Qg_UuZaSvrjJpn8L4+FtuAez--aqS92Q@mail.gmail.com>

On Tue, Oct 8, 2013 at 11:10 AM, Ryan Pavely <paradox at nac.net> wrote:
> I vote we go with Alex Rubenstein's offer to host..
>

no fair voting inside the camel's tent.

also, bikeshedding.

>   Ryan Pavely
>    Net Access Corporation
>    http://www.nac.net/
>
>
> On 10/7/2013 9:43 PM, Adam Newman wrote:
>>
>> I would be happy to donate a VM or two on my personal stack. Contact me if
>> interested.
>>
>> -Adam
>>
>> -------- Original message --------
>> From: Phil Bedard <bedard.phil at gmail.com>
>> Date: 10/07/2013  5:51 PM  (GMT-08:00)
>> To: Michael Thomas <mike at mtcc.com>,nanog at nanog.org
>> Subject: RE: nanog.org website - restored
>>   Yeah isn't there some cloud provider like Amazon, Rackspace, or MS
>> willing to donate some BW and CPU cycles? Would be a drop in the bucket.
>>
>> Phil From: Michael Thomas
>> Sent: 10/7/2013 19:57
>> To: nanog at nanog.org
>> Subject: Re: nanog.org website - restored
>> On 10/7/13 4:24 PM, Andrew Koch wrote:
>>>
>>> Working with onsite personel to upgrade the server with additional
>>> memory failed during the first announced maintenance.  Compatible memory
>>> was located and tested leading to the second maintenance when it was
>>> successfully installed.
>>>
>>> At this time we have increased the memory on the server and are at a
>>> stable point.
>>>
>> How primative. When i want more memory I just log into the provider's
>> web console and tell it I want more geebees.
>>
>> Mike
>>
>
>


From jcurran at arin.net  Tue Oct  8 15:42:41 2013
From: jcurran at arin.net (John Curran)
Date: Tue, 8 Oct 2013 15:42:41 +0000
Subject: ARIN Public Policy Consultation - 9:30 AM Today
Message-ID: <6A138812-92EE-4869-8865-4D273768BD5B@corp.arin.net>

NANOG Folks - 
 
    The ARIN Public Policy Consultation (PPC) at NANOG 59 will take place today 
    at 9:30 AM in Akimel Ballroom 3 & 4.  If you are registered to attend NANOG, 
    then you are registered to attend the PPC.

    There are three policy discussions taking place - 
	? Recommended Draft Policy ARIN-2013-4: RIR Principles
	? Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors
	? Draft Policy ARIN-2013-7: Merge IPv4 ISP and End-User Requirements

    Please take the time to participate in these discussions so that your views
    may be considered.  

    More information is available here - 
    https://www.arin.net/participate/meetings/ppc_nanog59/index.html

Thanks!
/John

John Curran
President and CEO
ARIN



From dave at temk.in  Tue Oct  8 21:41:04 2013
From: dave at temk.in (David Temkin)
Date: Tue, 8 Oct 2013 14:41:04 -0700
Subject: NANOG 59 - Monday presentations on YouTube
Message-ID: <CAFJiuFrtjK=dw0mT1xsH94K5ipM0Ey5A98TwbDGEjogBnc1o9g@mail.gmail.com>

All,

We're proud to announce that all of the recorded presentations from Monday
at NANOG 59 in Phoenix have now been posted to Youtube.  You may visit the
NANOG 59 page at
http://www.youtube.com/playlist?list=PLO8DR5ZGla8j7_jnNYY3d8JB0HfdXe85X

We will also embed links to the individual talks into the agenda at
http://www.nanog.org/meetings/nanog59/agenda within the next day

This is part of our continuous commitment to improving the NANOG program
for our members.

Regards,
-Dave Temkin
Chair, NANOG Program Committee

From ml at kenweb.org  Tue Oct  8 21:57:09 2013
From: ml at kenweb.org (ML)
Date: Tue, 08 Oct 2013 17:57:09 -0400
Subject: NANOG 59 - Monday presentations on YouTube
In-Reply-To: <CAFJiuFrtjK=dw0mT1xsH94K5ipM0Ey5A98TwbDGEjogBnc1o9g@mail.gmail.com>
References: <CAFJiuFrtjK=dw0mT1xsH94K5ipM0Ey5A98TwbDGEjogBnc1o9g@mail.gmail.com>
Message-ID: <52547FB5.5020102@kenweb.org>

On 10/8/2013 5:41 PM, David Temkin wrote:
> All,
>
> We're proud to announce that all of the recorded presentations from Monday
> at NANOG 59 in Phoenix have now been posted to Youtube.  You may visit the
> NANOG 59 page at
> http://www.youtube.com/playlist?list=PLO8DR5ZGla8j7_jnNYY3d8JB0HfdXe85X
>
> We will also embed links to the individual talks into the agenda at
> http://www.nanog.org/meetings/nanog59/agenda within the next day
>
> This is part of our continuous commitment to improving the NANOG program
> for our members.
>
> Regards,
> -Dave Temkin
> Chair, NANOG Program Committee

 Kudos to whomever made this happen so quickly.



From jjones at danrj.com  Tue Oct  8 22:00:22 2013
From: jjones at danrj.com (Jerry Jones)
Date: Tue, 8 Oct 2013 17:00:22 -0500
Subject: NANOG 59 - Monday presentations on YouTube
In-Reply-To: <CAFJiuFrtjK=dw0mT1xsH94K5ipM0Ey5A98TwbDGEjogBnc1o9g@mail.gmail.com>
References: <CAFJiuFrtjK=dw0mT1xsH94K5ipM0Ey5A98TwbDGEjogBnc1o9g@mail.gmail.com>
Message-ID: <B11E5DC6-937C-43F1-B13E-4C00825FC17D@danrj.com>

Would appear the video for #10 Community Meeting is also appearing for #11 BCOP



On Oct 8, 2013, at 4:41 PM, David Temkin <dave at temk.in> wrote:

All,

We're proud to announce that all of the recorded presentations from Monday
at NANOG 59 in Phoenix have now been posted to Youtube.  You may visit the
NANOG 59 page at
http://www.youtube.com/playlist?list=PLO8DR5ZGla8j7_jnNYY3d8JB0HfdXe85X

We will also embed links to the individual talks into the agenda at
http://www.nanog.org/meetings/nanog59/agenda within the next day

This is part of our continuous commitment to improving the NANOG program
for our members.

Regards,
-Dave Temkin
Chair, NANOG Program Committee



From ilissa at imillerpr.com  Tue Oct  8 22:58:25 2013
From: ilissa at imillerpr.com (Ilissa Miller)
Date: Tue, 8 Oct 2013 18:58:25 -0400
Subject: NANOG Elections Reminder
Message-ID: <0BA2E89E-60B1-4401-BCD1-C611DA779740@imillerpr.com>

Dear Colleagues -

Nominations for NANOG Committee Members will close in one-hour (5pm PT).  Please send your nominations to elections at nanog.org.

Thank you,
Ilissa






From jcurran at arin.net  Wed Oct  9 03:50:45 2013
From: jcurran at arin.net (John Curran)
Date: Wed, 9 Oct 2013 03:50:45 +0000
Subject: =?Windows-1252?Q?ARIN_Meetings_=96_Weigh_In_on_Future_Format?=
References: <52542541.5060408@arin.net>
Message-ID: <D0C0B49A-AE81-4C3F-B74F-759311921114@corp.arin.net>

NANOG Folks -

   ARIN is seeking input on the desired frequency and location of ARIN meetings;
   please take a moment to complete the attached survey if you are interested in
   providing input on the ARIN meeting schedule, particularly given that we now
   holding Public Policy Consultations at each NANOG.

Thanks!
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

From: ARIN <info at arin.net<mailto:info at arin.net>>
Subject: [arin-announce] ARIN Meetings ? Weigh In on Future Format
Date: October 8, 2013 8:31:13 AM MST
To: <arin-announce at arin.net<mailto:arin-announce at arin.net>>

The ARIN Board of Trustees is discussing the appropriate frequency and
format of ARIN?s Public Policy and Members Meetings. Traditionally and
through 2014 ARIN is scheduled to hold two per year, one conjoined with
NANOG in Q3 of the year.

Please take a few minutes to respond to the short meeting survey and let
us know your opinion?.what is the correct mix that would encourage your
new or increased participation? This survey is open to the ARIN and NANOG
communities, and also to those who are not currently active in either
organization.

https://www.surveymonkey.com/s/future_meetings

The survey will remain open until Friday 25 October.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

From me at anuragbhatia.com  Wed Oct  9 06:04:22 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Wed, 9 Oct 2013 11:34:22 +0530
Subject: Regarding source based outbound routing (with redundancy)
In-Reply-To: <CE75D803.2EF3C%freimer@freimer.org>
References: <CAL9jLaYNTt1Gqb61AvtLLezLuSdAWt8DHTs62vYAcTv9_8oxew@mail.gmail.com>
 <CE75D803.2EF3C%freimer@freimer.org>
Message-ID: <CAJ0+aXbbp95CZ8z5Xd_JRm3opGq4vJY=6h9C_-VpnoFsBRxodA@mail.gmail.com>

Thanks for responses on this everyone.


I went ahead with VRF.


On Sun, Oct 6, 2013 at 12:26 AM, Fred Reimer <freimer at freimer.org> wrote:

> I would need to lab it up, but assuming a MPLS core, can't you do a TE
> tunnel from the source to the desired egress router?
>
> On 10/5/13 2:43 PM, "Christopher Morrow" <morrowc.lists at gmail.com> wrote:
>
> >On Sat, Oct 5, 2013 at 2:08 PM, joel jaeggli <joelja at bogus.com> wrote:
> >>
> >> On Oct 5, 2013, at 9:45 AM, Christopher Morrow
> >><morrowc.lists at gmail.com> wrote:
> >>
> >>> you really don't want to do policy routing :(
> >>>
> >>
> >> PBR has this tendency to be brittle in the face of topology changes.
> >
> >yup, exactly my point :(
> >
> >> There are much better way to outbound load-balance between providers
> >>offering same or similar quality routes to the same destination.
> >>
> >> multi-AS multipath will do that if the peers are on the same router.
> >>BGPaddpath
> >> can do it for you if the peers are spread across routers.
> >
> >these both will require seeing the longer prefix from the right peer
> >though, right? and selecting that would just be like natural selection
> >anyway...
> >
> >yikes, I suppose you could:
> >  1) generate the longer prefix internally
> >  2) set it's next-hop to something reachable out both (all) peers
> >  3) metric the preferred peer's next-hop appropriately
> >  4) profit
> >
> >but that sounds also kind of messy and prone to odd failures when
> >changes are made :(
> >you'd be adding complexity that you'd have to track through the life
> >of your network :( (and explain to anyone 'not you' working on the
> >network)
> >
> >-chris
> >
> >> joel
> >>
> >>> On Sat, Oct 5, 2013 at 12:19 PM, Anurag Bhatia <me at anuragbhatia.com>
> >>>wrote:
> >>>> Hello there!
> >>>>
> >>>>
> >>>> I am trying to do a source based outbound routing between multiple
> >>>> upstreams. Usually I picked outbound via localpref but here I wish to
> >>>>use
> >>>> Provider 1 for say 10.10.10.0/24 while provider 2 for small chunk of
> >>>>it say
> >>>> 10.10.10.0/28. I wish to keep failover support and thus so if
> >>>>provider 2
> >>>> fails, I wish to push traffic again via Provider 1.
> >>>>
> >>>> Is this is possible only with VRF or I can push for some specific
> >>>>match
> >>>> rule in route maps?
> >>>>
> >>>>
> >>>>
> >>>> 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 richard.hesse at weebly.com  Wed Oct  9 06:30:34 2013
From: richard.hesse at weebly.com (Richard Hesse)
Date: Tue, 8 Oct 2013 23:30:34 -0700
Subject: NANOG 59 - Monday presentations on YouTube
In-Reply-To: <52547FB5.5020102@kenweb.org>
References: <CAFJiuFrtjK=dw0mT1xsH94K5ipM0Ey5A98TwbDGEjogBnc1o9g@mail.gmail.com>
 <52547FB5.5020102@kenweb.org>
Message-ID: <CAJj1h3FN+TEaVRJ7tWy5qy1JY1XSKZ0yB31eFbRaAe24ZxBqdA@mail.gmail.com>

On Tue, Oct 8, 2013 at 2:57 PM, ML <ml at kenweb.org> wrote:

>  Kudos to whomever made this happen so quickly


+1 on that. Great stuff in here. Though the Better Than Best
Practices...DNS Amplification Attacks video isn't working for me. It says
the video is still processing and has been for a few hours now. Any chance
we could get this video fixed? TIA.

http://www.youtube.com/watch?v=Bqz4InD1YqY&list=PLO8DR5ZGla8j7_jnNYY3d8JB0HfdXe85X&index=8

-richard

From blair.trosper at gmail.com  Wed Oct  9 16:00:25 2013
From: blair.trosper at gmail.com (Blair Trosper)
Date: Wed, 9 Oct 2013 11:00:25 -0500
Subject: google / massive problems
Message-ID: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>

Can someone from Google Drive or Gmail contact me off-list?

The sign in services and applications are outright down trying to use them
in Chrome.  Trying to contact enterprise support via several numbers just
results in an immediate disconnect.

The App Status page shows no problem, but Twitter and Facebook are blowing
up with trouble reports, and I have tons of technical status codes to
share, but no one with whom to share them.

Thanks,
Blair

From fergdawgster at mykolab.com  Wed Oct  9 16:14:18 2013
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Wed, 09 Oct 2013 09:14:18 -0700
Subject: google / massive problems
In-Reply-To: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>
References: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>
Message-ID: <525580DA.7040304@mykolab.com>

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

On 10/9/2013 9:00 AM, Blair Trosper wrote:

 > Can someone from Google Drive or Gmail contact me off-list?
 >
 > The sign in services and applications are outright down trying to use
 > them in Chrome.  Trying to contact enterprise support via several numbers
 > just results in an immediate disconnect.

I can't speak to enterprise services, but I just logged in to my own
personal GMail account -- with 2 FA -- with no problems, from the Seattle
metro area.

- - ferg

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 10.2.0 (Build 2317)
Charset: utf-8

wj8DBQFSVYDTq1pz9mNUZTMRArDeAJ44GjAt1uzY4++dKDmrPWhBfm3a2wCcCqGB
w6FrRdogRvpTomaMdcqO9hU=
=OMUq
-----END PGP SIGNATURE-----


-- 
Paul Ferguson
Vice President, Threat Intelligence
Internet Identity, Tacoma, Washington  USA
IID --> "Connect and Collaborate" --> www.internetidentity.com


From alby.williams at verizon.com  Wed Oct  9 16:17:27 2013
From: alby.williams at verizon.com (Anthony Williams)
Date: Wed, 09 Oct 2013 12:17:27 -0400
Subject: google / massive problems
In-Reply-To: <525580DA.7040304@mykolab.com>
References: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>
 <525580DA.7040304@mykolab.com>
Message-ID: <52558197.5040107@one.verizon.com>



 Same. Works for me (WashDC/NoVA Area).

-Alby






On 10/9/2013 12:14 PM, Paul Ferguson wrote:
> On 10/9/2013 9:00 AM, Blair Trosper wrote:
> 
>  > Can someone from Google Drive or Gmail contact me off-list?
> 
>  > The sign in services and applications are outright down trying to use
>  > them in Chrome.  Trying to contact enterprise support via several numbers
>  > just results in an immediate disconnect.
> 
> I can't speak to enterprise services, but I just logged in to my own
> personal GMail account -- with 2 FA -- with no problems, from the Seattle
> metro area.
> 
> - ferg
> 
> 
> 



From sam at circlenet.us  Wed Oct  9 16:19:21 2013
From: sam at circlenet.us (Sam Moats)
Date: Wed, 09 Oct 2013 12:19:21 -0400
Subject: google / massive problems
In-Reply-To: <52558197.5040107@one.verizon.com>
References: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>
 <525580DA.7040304@mykolab.com> <52558197.5040107@one.verizon.com>
Message-ID: <17e3df96d21461cf58cc54cb29c57ea6@www.circlenet.us>

Works for me from Nova, Level3 and Cogent.
Sam Moats

On 2013-10-09 12:17, Anthony Williams wrote:
> Same. Works for me (WashDC/NoVA Area).
>
> -Alby
>
>
>
>
>
>
> On 10/9/2013 12:14 PM, Paul Ferguson wrote:
>> On 10/9/2013 9:00 AM, Blair Trosper wrote:
>>
>>  > Can someone from Google Drive or Gmail contact me off-list?
>>
>>  > The sign in services and applications are outright down trying to 
>> use
>>  > them in Chrome.  Trying to contact enterprise support via several 
>> numbers
>>  > just results in an immediate disconnect.
>>
>> I can't speak to enterprise services, but I just logged in to my own
>> personal GMail account -- with 2 FA -- with no problems, from the 
>> Seattle
>> metro area.
>>
>> - ferg
>>
>>
>>



From izumi at nic.ad.jp  Wed Oct  9 15:55:45 2013
From: izumi at nic.ad.jp (Izumi Okutani)
Date: Thu, 10 Oct 2013 00:55:45 +0900
Subject: JANOG 33 Call for Papers
Message-ID: <52557C81.6050300@nic.ad.jp>

Hello,


JANOG is making a call for presentation until 24th Oct.

It is a networks operators group in Japan with 400+ participants at
meetings, and + 6,000 mailing list subscribers as of June 2013.

Our Meetings are in Japanese but we have had several non-Japanese
speakers presenting at JANOG.

We are looking forward to your proposals for presentations.


Cheers,
Shinichi Yamamoto, Chin Sze (James) Yih, Izumi Okutani
JANOG Internationalization team for JANOG 33


-----
JANOG 33 Call for Papers
-----------
The JApan Network Operators' Group (JANOG) will hold its 33th meeting in
Beppu, Japan on January 23-24, 2014. Yahoo Japan will host JANOG 33.
We invite presentations highlighting issues relating to technology
already deployed or soon-to-be deployed in the Internet.

Submissions are welcome via the e-mail at:"meeting-33[at]janog.gr.jp".

ABOUT JANOG
-----------
A JANOG Web Page in English can be found at: http://www.janog.gr.jp/en/

THE KEY DATE FOR JANOG 33 SUBMISSIONS
-------------------------------------
CFP Deadline : October 24 23:59 JST

The Program Committee will notify applicants after 8th Nov on their
decision about the submissions.

HOW TO PRESENT
--------------
If you are interested to give a presentation but do not have someone to
help you with the language, try consulting us at:
"meeting-33[at]janog.gr.jp".

Although we cannot guarantee, we may be able to help you on volunteer
basis.

The detail of presentation guidelines can be found under JANOG 33 Web
Page in English.
http://www.janog.gr.jp/en/index.php?JANOG33%20Programs

Let us know if you have any questions
meeting-33[at]janog.gr.jp

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


From jake at nobistech.net  Wed Oct  9 16:25:52 2013
From: jake at nobistech.net (Jake Mertel)
Date: Wed, 9 Oct 2013 09:25:52 -0700
Subject: google / massive problems
In-Reply-To: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>
References: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>
Message-ID: <CAOhg=RwLeB-6zD-=2SGBa47_6+2LZb79G1FZh+cmbVkVq6npNg@mail.gmail.com>

No issues from my site routing over AboveNet and using Google Apps for
Business -- Drive and Gmail working as expected.

On Wednesday, October 9, 2013, Blair Trosper wrote:

> Can someone from Google Drive or Gmail contact me off-list?
>
> The sign in services and applications are outright down trying to use them
> in Chrome.  Trying to contact enterprise support via several numbers just
> results in an immediate disconnect.
>
> The App Status page shows no problem, but Twitter and Facebook are blowing
> up with trouble reports, and I have tons of technical status codes to
> share, but no one with whom to share them.
>
> Thanks,
> Blair
>


-- 


--
Regards,

Jake Mertel
Nobis Technology Group, LLC




*Web: *http://www.nobistech.net
*Phone: *1-480-212-1710
*Mail:* 6930 East Chauncey Lane, Suite 150, Phoenix, AZ 85054

From blair.trosper at gmail.com  Wed Oct  9 16:29:48 2013
From: blair.trosper at gmail.com (Blair Trosper)
Date: Wed, 9 Oct 2013 11:29:48 -0500
Subject: google / massive problems
In-Reply-To: <CAOhg=RwLeB-6zD-=2SGBa47_6+2LZb79G1FZh+cmbVkVq6npNg@mail.gmail.com>
References: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>
 <CAOhg=RwLeB-6zD-=2SGBa47_6+2LZb79G1FZh+cmbVkVq6npNg@mail.gmail.com>
Message-ID: <CAA5Ek4fST71zeoo3iLqHw+xtx2b6tdEjrR4ZGDg85=u+wd5TXg@mail.gmail.com>

This is the delight I'm faced with, but seems to be affecting the latest
version of Chrome, both on Win7 and MacBook Pro (OS X 10.8.5)...again,
confined to Chrome (image attached).


Emails won't sent, drafts won't save, and no apps will load without an
error.  Sign-in also fails with numeric code 5.

I'm in Dallas, but I've also tried over VPN from endpoints in Atlanta, New
York, Los Angeles, Seattle, Amsterdam, Singapore, and London with no change.


On Wed, Oct 9, 2013 at 11:25 AM, Jake Mertel <jake at nobistech.net> wrote:

> No issues from my site routing over AboveNet and using Google Apps for
> Business -- Drive and Gmail working as expected.
>
>
> On Wednesday, October 9, 2013, Blair Trosper wrote:
>
>> Can someone from Google Drive or Gmail contact me off-list?
>>
>> The sign in services and applications are outright down trying to use them
>> in Chrome.  Trying to contact enterprise support via several numbers just
>> results in an immediate disconnect.
>>
>> The App Status page shows no problem, but Twitter and Facebook are blowing
>> up with trouble reports, and I have tons of technical status codes to
>> share, but no one with whom to share them.
>>
>> Thanks,
>> Blair
>>
>
>
> --
>
>
> --
> Regards,
>
> Jake Mertel
> Nobis Technology Group, LLC
>
>
>
>
> *Web: *http://www.nobistech.net
> *Phone: *1-480-212-1710
> *Mail:* 6930 East Chauncey Lane, Suite 150, Phoenix, AZ 85054
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdrive_chrome_win7.png
Type: image/png
Size: 33250 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131009/46738fd7/attachment-0001.png>

From blair.trosper at gmail.com  Wed Oct  9 16:35:16 2013
From: blair.trosper at gmail.com (Blair Trosper)
Date: Wed, 9 Oct 2013 11:35:16 -0500
Subject: comcast ipv6 PTR
Message-ID: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>

Does anyone know why (or can someone from Comcast explain why) there is no
PTR on their residential/business IPv6 addresses?

From cma at cmadams.net  Wed Oct  9 16:41:50 2013
From: cma at cmadams.net (Chris Adams)
Date: Wed, 9 Oct 2013 11:41:50 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
Message-ID: <20131009164150.GG1193@cmadams.net>

Once upon a time, Blair Trosper <blair.trosper at gmail.com> said:
> Does anyone know why (or can someone from Comcast explain why) there is no
> PTR on their residential/business IPv6 addresses?

I believe business customers (with a static assignment) can request
reverse DNS entries.  Residential customers are not guaranteed a static
assignment, so they can't get reverse set.

-- 
Chris Adams <cma at cmadams.net>


From rwebb at ropeguru.com  Wed Oct  9 16:47:16 2013
From: rwebb at ropeguru.com (Robert Webb)
Date: Wed, 09 Oct 2013 12:47:16 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <20131009164150.GG1193@cmadams.net>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net>
Message-ID: <web-63958@mail.saroza-webb.local>

On Wed, 9 Oct 2013 11:41:50 -0500
  Chris Adams <cma at cmadams.net> wrote:
> Once upon a time, Blair Trosper <blair.trosper at gmail.com> said:
>> Does anyone know why (or can someone from Comcast explain why) there 
>>is no
>> PTR on their residential/business IPv6 addresses?
> 
> I believe business customers (with a static assignment) can request
> reverse DNS entries.  Residential customers are not guaranteed a 
>static
> assignment, so they can't get reverse set.
> 
> -- 
> Chris Adams <cma at cmadams.net>
> 

But how would thet differ from the IPv4 address space which has PTR 
records for all their IP's? Just the shear number they would have to 
deal with in the IPv6 space?

Robert


From cma at cmadams.net  Wed Oct  9 16:49:47 2013
From: cma at cmadams.net (Chris Adams)
Date: Wed, 9 Oct 2013 11:49:47 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <web-63958@mail.saroza-webb.local>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net>
 <web-63958@mail.saroza-webb.local>
Message-ID: <20131009164947.GI1193@cmadams.net>

Once upon a time, Robert Webb <rwebb at ropeguru.com> said:
> But how would thet differ from the IPv4 address space which has PTR
> records for all their IP's? Just the shear number they would have to
> deal with in the IPv6 space?

Oh, are you looking for auto-generated reverse for every address?
That's not going to happen for IPv6 (and it turns out that it wasn't
really a good idea for IPv4).  There's no reason to have reverse DNS
unless it has meaning, and "12-34-56-78.rev.domain.net" isn't really all
that useful.

-- 
Chris Adams <cma at cmadams.net>


From blair.trosper at gmail.com  Wed Oct  9 16:52:48 2013
From: blair.trosper at gmail.com (Blair Trosper)
Date: Wed, 9 Oct 2013 11:52:48 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <web-63958@mail.saroza-webb.local>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net>
 <web-63958@mail.saroza-webb.local>
Message-ID: <CAA5Ek4fjKrvrK4P6tARmJMnVEWukPioi3Fho-ZkjQwBrpn_Aiw@mail.gmail.com>

That's essentially what I'm getting at.  If the v6 addresses/blocks are
allocated in a similar fashion to IPv4, where the octets are clearly named
by state and "hsd1", then I don't see why they should lack PTR.

However, even if they're not assigned or delegated in that way, it'd be
helpful to have SOME form of PTR on there.

Otherwise, they'd be a lot like Google, leaving the traceroute and
end-point PTR left up to our imagination (even though it's available
internally to Google employees).  I understand why Google lacks PTR to some
extent with anycast and the mobility of their v4 addresses, but I suspect
that Comcast isn't doing anything that sophisticated.


On Wed, Oct 9, 2013 at 11:47 AM, Robert Webb <rwebb at ropeguru.com> wrote:

> On Wed, 9 Oct 2013 11:41:50 -0500
>  Chris Adams <cma at cmadams.net> wrote:
>
>> Once upon a time, Blair Trosper <blair.trosper at gmail.com> said:
>>
>>> Does anyone know why (or can someone from Comcast explain why) there is
>>> no
>>> PTR on their residential/business IPv6 addresses?
>>>
>>
>> I believe business customers (with a static assignment) can request
>> reverse DNS entries.  Residential customers are not guaranteed a static
>> assignment, so they can't get reverse set.
>>
>> --
>> Chris Adams <cma at cmadams.net>
>>
>>
> But how would thet differ from the IPv4 address space which has PTR
> records for all their IP's? Just the shear number they would have to deal
> with in the IPv6 space?
>
> Robert
>
>

From asullivan at dyn.com  Wed Oct  9 16:58:45 2013
From: asullivan at dyn.com (Andrew Sullivan)
Date: Wed, 9 Oct 2013 12:58:45 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
Message-ID: <20131009165842.GJ47673@mx1.yitter.info>

On Wed, Oct 09, 2013 at 11:35:16AM -0500, Blair Trosper wrote:
> Does anyone know why (or can someone from Comcast explain why) there is no
> PTR on their residential/business IPv6 addresses?

Probably because of the considerations in
http://tools.ietf.org/html/draft-howard-isp-ip6rdns-06.  I seem to
remember someone showing up in DNSOP one time to argue for a draft
that the reverse mapping should just be optional under IPv6, but I
can't lay my hands on the draft.  The last time DNSOP tried to come up
with recommendations about the reverse tree, the resulting document
was
http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06.
It says, roughly, "Well, some peple use the reverse tree and some
don't.  You might want to think about that, or not."  Despite
asserting a version of "A or not-A", we were unable to achieve
consensus, so I think the hope of consistency in the reverse tree is
not supported by operational evidence.

Best,

A

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



From fergdawgster at mykolab.com  Wed Oct  9 16:59:59 2013
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Wed, 09 Oct 2013 09:59:59 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <20131009164947.GI1193@cmadams.net>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net> <web-63958@mail.saroza-webb.local>
 <20131009164947.GI1193@cmadams.net>
Message-ID: <52558B8F.7030508@mykolab.com>

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

On 10/9/2013 9:49 AM, Chris Adams wrote:

 > Once upon a time, Robert Webb <rwebb at ropeguru.com> said:
 >> But how would thet differ from the IPv4 address space which has PTR
 >> records for all their IP's? Just the shear number they would have to
 >> deal with in the IPv6 space?
 >
 > Oh, are you looking for auto-generated reverse for every address?
 > That's not going to happen for IPv6 (and it turns out that it wasn't
 > really a good idea for IPv4).  There's no reason to have reverse DNS
 > unless it has meaning, and "12-34-56-78.rev.domain.net" isn't really all
 > that useful.
 >

That's not necessarily true -- some (very large) organizations using DMARC
will reject mail from hosts without a PTR record.

- - ferg

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 10.2.0 (Build 2317)
Charset: utf-8

wj8DBQFSVYuKq1pz9mNUZTMRAo5dAKCCuFYjseatheC9upjRRgkzcFJ5LwCfUhhd
Krgz0IA6e5dbllo8NgXbzV0=
=mehI
-----END PGP SIGNATURE-----


-- 
Paul Ferguson
Vice President, Threat Intelligence
Internet Identity, Tacoma, Washington  USA
IID --> "Connect and Collaborate" --> www.internetidentity.com


From blair.trosper at gmail.com  Wed Oct  9 17:00:36 2013
From: blair.trosper at gmail.com (Blair Trosper)
Date: Wed, 9 Oct 2013 12:00:36 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <20131009164947.GI1193@cmadams.net>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net>
 <web-63958@mail.saroza-webb.local>
 <20131009164947.GI1193@cmadams.net>
Message-ID: <CAA5Ek4eZPyAm6CGugKfbYjgs0xjDUVD3ykh65L6_WFjjT2sp5g@mail.gmail.com>

True, but the location information, at least the state, is quasi-helpful.

You may be right about PTR being a mistake, but I guess my mind approaches
it from a practical, quasi-GeoIP approach.

IPv6 seems to be somewhat chaotic in that realm.  Plus, with web
applications and services, accurate GeoIP has implications for security.


On Wed, Oct 9, 2013 at 11:49 AM, Chris Adams <cma at cmadams.net> wrote:

> Once upon a time, Robert Webb <rwebb at ropeguru.com> said:
> > But how would thet differ from the IPv4 address space which has PTR
> > records for all their IP's? Just the shear number they would have to
> > deal with in the IPv6 space?
>
> Oh, are you looking for auto-generated reverse for every address?
> That's not going to happen for IPv6 (and it turns out that it wasn't
> really a good idea for IPv4).  There's no reason to have reverse DNS
> unless it has meaning, and "12-34-56-78.rev.domain.net" isn't really all
> that useful.
>
> --
> Chris Adams <cma at cmadams.net>
>
>

From james at jamesstewartsmith.com  Wed Oct  9 17:01:12 2013
From: james at jamesstewartsmith.com (james at jamesstewartsmith.com)
Date: Wed, 9 Oct 2013 17:01:12 +0000
Subject: google / massive problems
Message-ID: <551145590-1381338076-cardhu_decombobulator_blackberry.rim.net-2008499346-@b12.c12.bise6.blackberry>

Logging into gmail works, but Google Apps was having difficulties in Canada. It's working now...maybe just a hiccup?

------Original Message------
From: Sam Moats
To: nanog at nanog.org
ReplyTo: sam at circlenet.us
Subject: Re: google / massive problems
Sent: Oct 9, 2013 12:19 PM

Works for me from Nova, Level3 and Cogent.
Sam Moats

On 2013-10-09 12:17, Anthony Williams wrote:
> Same. Works for me (WashDC/NoVA Area).
>
> -Alby
>
>
>
>
>
>
> On 10/9/2013 12:14 PM, Paul Ferguson wrote:
>> On 10/9/2013 9:00 AM, Blair Trosper wrote:
>>
>>  > Can someone from Google Drive or Gmail contact me off-list?
>>
>>  > The sign in services and applications are outright down trying to 
>> use
>>  > them in Chrome.  Trying to contact enterprise support via several 
>> numbers
>>  > just results in an immediate disconnect.
>>
>> I can't speak to enterprise services, but I just logged in to my own
>> personal GMail account -- with 2 FA -- with no problems, from the 
>> Seattle
>> metro area.
>>
>> - ferg
>>
>>
>>



James

From morrowc.lists at gmail.com  Wed Oct  9 17:09:46 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 9 Oct 2013 13:09:46 -0400
Subject: google / massive problems
In-Reply-To: <CAA5Ek4fST71zeoo3iLqHw+xtx2b6tdEjrR4ZGDg85=u+wd5TXg@mail.gmail.com>
References: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>
 <CAOhg=RwLeB-6zD-=2SGBa47_6+2LZb79G1FZh+cmbVkVq6npNg@mail.gmail.com>
 <CAA5Ek4fST71zeoo3iLqHw+xtx2b6tdEjrR4ZGDg85=u+wd5TXg@mail.gmail.com>
Message-ID: <CAL9jLaZBDqaSqY2jbo0muENYok4mpDsjK6gAGjaOz0t1n1T9iw@mail.gmail.com>

piling on a tad: (for consumer gmail/drive)
 1) existing session cookies work fine
 2) new sessions work fine, + 2-step auth

from nova/701 connected me.

for an apps-for-your-domains account, same src location:
  1) new login works fine

err... maybe you have a bad chrome extension or profile problem if
it's only affecting chrome?

you could test with a new chrome profile:
  google-chrome --user-data-dir=$(mktemp -d)

and see how things go?


On Wed, Oct 9, 2013 at 12:29 PM, Blair Trosper <blair.trosper at gmail.com> wrote:
> This is the delight I'm faced with, but seems to be affecting the latest
> version of Chrome, both on Win7 and MacBook Pro (OS X 10.8.5)...again,
> confined to Chrome (image attached).
>
>
> Emails won't sent, drafts won't save, and no apps will load without an
> error.  Sign-in also fails with numeric code 5.
>
> I'm in Dallas, but I've also tried over VPN from endpoints in Atlanta, New
> York, Los Angeles, Seattle, Amsterdam, Singapore, and London with no change.
>
>
> On Wed, Oct 9, 2013 at 11:25 AM, Jake Mertel <jake at nobistech.net> wrote:
>
>> No issues from my site routing over AboveNet and using Google Apps for
>> Business -- Drive and Gmail working as expected.
>>
>>
>> On Wednesday, October 9, 2013, Blair Trosper wrote:
>>
>>> Can someone from Google Drive or Gmail contact me off-list?
>>>
>>> The sign in services and applications are outright down trying to use them
>>> in Chrome.  Trying to contact enterprise support via several numbers just
>>> results in an immediate disconnect.
>>>
>>> The App Status page shows no problem, but Twitter and Facebook are blowing
>>> up with trouble reports, and I have tons of technical status codes to
>>> share, but no one with whom to share them.
>>>
>>> Thanks,
>>> Blair
>>>
>>
>>
>> --
>>
>>
>> --
>> Regards,
>>
>> Jake Mertel
>> Nobis Technology Group, LLC
>>
>>
>>
>>
>> *Web: *http://www.nobistech.net
>> *Phone: *1-480-212-1710
>> *Mail:* 6930 East Chauncey Lane, Suite 150, Phoenix, AZ 85054
>>
>>
>>
>>


From cma at cmadams.net  Wed Oct  9 17:10:16 2013
From: cma at cmadams.net (Chris Adams)
Date: Wed, 9 Oct 2013 12:10:16 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <CAA5Ek4eZPyAm6CGugKfbYjgs0xjDUVD3ykh65L6_WFjjT2sp5g@mail.gmail.com>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net>
 <web-63958@mail.saroza-webb.local>
 <20131009164947.GI1193@cmadams.net>
 <CAA5Ek4eZPyAm6CGugKfbYjgs0xjDUVD3ykh65L6_WFjjT2sp5g@mail.gmail.com>
Message-ID: <20131009171016.GB3079@cmadams.net>

Once upon a time, Blair Trosper <blair.trosper at gmail.com> said:
> True, but the location information, at least the state, is quasi-helpful.

That's another good reason to have reverse records for defined router
interfaces.  Auto-generated reverse for eveything doesn't give any
useful info though.

-- 
Chris Adams <cma at cmadams.net>


From cma at cmadams.net  Wed Oct  9 17:08:48 2013
From: cma at cmadams.net (Chris Adams)
Date: Wed, 9 Oct 2013 12:08:48 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <52558B8F.7030508@mykolab.com>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net>
 <web-63958@mail.saroza-webb.local>
 <20131009164947.GI1193@cmadams.net> <52558B8F.7030508@mykolab.com>
Message-ID: <20131009170848.GA3079@cmadams.net>

Once upon a time, Paul Ferguson <fergdawgster at mykolab.com> said:
> That's not necessarily true -- some (very large) organizations using DMARC
> will reject mail from hosts without a PTR record.

And that's a good reason to have reverse records for you mail servers.
Auto-generated reverse really shouldn't be trusted for anything.
-- 
Chris Adams <cma at cmadams.net>


From jabley at hopcount.ca  Wed Oct  9 17:29:46 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 9 Oct 2013 10:29:46 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <20131009171016.GB3079@cmadams.net>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net> <web-63958@mail.saroza-webb.local>
 <20131009164947.GI1193@cmadams.net>
 <CAA5Ek4eZPyAm6CGugKfbYjgs0xjDUVD3ykh65L6_WFjjT2sp5g@mail.gmail.com>
 <20131009171016.GB3079@cmadams.net>
Message-ID: <93D9A8E3-A7D0-40EE-AAA9-3207A5D14E90@hopcount.ca>


On 2013-10-09, at 10:10, Chris Adams <cma at cmadams.net> wrote:

> Once upon a time, Blair Trosper <blair.trosper at gmail.com> said:
>> True, but the location information, at least the state, is quasi-helpful.
> 
> That's another good reason to have reverse records for defined router
> interfaces.  Auto-generated reverse for eveything doesn't give any
> useful info though.

If people really want to use generic reverse names and have realised that the v6 address space is much too big for $GENERATE, one approach is to delegate the appropriate zones to a custom nameserver that can auto-generate PTRs on demand. There are scaling problems here, but probably nothing that can't be fixed with high TTLs and multiple nameservers.

If I was doing that, my instinct would be to code against Ray Bellis' evldns (see <http://code.google.com/p/evldns/>).

Note that I'm not suggesting that auto-generated v6 PTRs (or v4 PTRs) are a good idea. But I'm aware that a lack of reverse DNS on either protocol can make the helpdesk phone ring, so there is certainly a pragmatic argument in favour of it.


Joe

From mureninc at gmail.com  Wed Oct  9 17:30:46 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Wed, 9 Oct 2013 10:30:46 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <20131009165842.GJ47673@mx1.yitter.info>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009165842.GJ47673@mx1.yitter.info>
Message-ID: <CAPKkNb5f4mMmDn6vXSQjwwJU0ee4TByTYoV2DK4My8UjcoGk3A@mail.gmail.com>

On 9 October 2013 09:58, Andrew Sullivan <asullivan at dyn.com> wrote:
> On Wed, Oct 09, 2013 at 11:35:16AM -0500, Blair Trosper wrote:
>> Does anyone know why (or can someone from Comcast explain why) there is no
>> PTR on their residential/business IPv6 addresses?
>
> Probably because of the considerations in
> http://tools.ietf.org/html/draft-howard-isp-ip6rdns-06.  I seem to
> remember someone showing up in DNSOP one time to argue for a draft
> that the reverse mapping should just be optional under IPv6, but I
> can't lay my hands on the draft.  The last time DNSOP tried to come up
> with recommendations about the reverse tree, the resulting document
> was
> http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06.
> It says, roughly, "Well, some peple use the reverse tree and some
> don't.  You might want to think about that, or not."  Despite
> asserting a version of "A or not-A", we were unable to achieve
> consensus, so I think the hope of consistency in the reverse tree is
> not supported by operational evidence.

Yet, apparently, Google has very recently completely stopped accepting
email with no PTR records.

On my Linode over the summer, it seems like this was the first mention
of IPv6 in my errorlog:


Aug 17 03:16:07 (none) dma[7de9.b8dd8ca8]: remote delivery to
gmail-smtp-in.l.google.com [2607:f8b0:400e:c01::1b] failed after final
DATA: 550-5.7.1 [2600:3c01:XXXX::      16] The sender does not meet
basic ipv6 sending#015#012550-5.7.1 guidelines of authentication and
rdns resolution of sending ip.#015#012550-5.7.1 Please
review#015#012550 5.7.1
https://support.google.com/mail/answer/81126for more information.
zo6si1884856pac.170 - gsmtp


Prior to 2013-08-17, most messages were delivered nightly without much
problems (although these cron jobs did often end up in the Spam
folder, and had to be rescued manually); after 2013-08-17, there was
only one nightly message that got through, on 2013-08-26, and
completely nothing since then:


Sep  6 03:15:50 (none) dma[7f00.b9012ca8]: remote delivery to
gmail-smtp-in.l.google.com [2a00:1450:4008:c01::1a] failed after final
DATA: 550-5.7.1 [2600:3c01:XXXX::      16] Our system has detected
that this message#015#012550-5.7.1 does not meet IPv6 sending
guidelines regarding PTR records and#015#012550-5.7.1 authentication.
Please review#015#012550 5.7.1
https://support.google.com/mail/answer/81126 for more information.
qk9si240507bkb.323 - gsmtp

Oct  9 03:15:48 (none) dma[966a.b8dc0ca8]: remote delivery to
gmail-smtp-in.l.google.com [2607:f8b0:400e:c01::1b] failed after final
DATA: 550-5.7.1 [2600:3c01:XXXX::      16] Our system has detected
that this message#015#012550-5.7.1 does not meet IPv6 sending
guidelines regarding PTR records and#015#012550-5.7.1 authentication.
Please review#015#012550-5.7.1
https://support.google.com/mail/?p=ipv6_authentication_error for
more#015#012550 5.7.1 information. vs7si29857999pbc.145 - gsmtp


C.


From fergdawgster at mykolab.com  Wed Oct  9 17:36:31 2013
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Wed, 09 Oct 2013 10:36:31 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <525593D7.2030701@people.ops-trust.net>
References: <525593D7.2030701@people.ops-trust.net>
Message-ID: <5255941F.7060103@mykolab.com>

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

On 10/9/2013 10:08 AM, Chris Adams wrote:

> Once upon a time, Paul Ferguson<fergdawgster at mykolab.com>  said:
>> >That's not necessarily true -- some (very large) organizations using
>> >DMARC will reject mail from hosts without a PTR record.

> And that's a good reason to have reverse records for you mail servers.

Indeed. :-)

> Auto-generated reverse really shouldn't be trusted for anything.

True. :-)

- - ferg

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 10.2.0 (Build 2317)
Charset: utf-8

wj8DBQFSVZPSq1pz9mNUZTMRAmVHAKCbyB6whUKbQ5Sl73+TMSE0TRcS5gCdEcZx
yXmgvG3kRpJIMRWhNNjUwag=
=CvKl
-----END PGP SIGNATURE-----

-- 
Paul Ferguson
Vice President, Threat Intelligence
Internet Identity, Tacoma, Washington  USA
IID --> "Connect and Collaborate" --> www.internetidentity.com


From bross at pobox.com  Wed Oct  9 17:52:20 2013
From: bross at pobox.com (Brandon Ross)
Date: Wed, 9 Oct 2013 13:52:20 -0400 (EDT)
Subject: google / massive problems
In-Reply-To: <CAL9jLaZBDqaSqY2jbo0muENYok4mpDsjK6gAGjaOz0t1n1T9iw@mail.gmail.com>
References: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>
 <CAOhg=RwLeB-6zD-=2SGBa47_6+2LZb79G1FZh+cmbVkVq6npNg@mail.gmail.com>
 <CAA5Ek4fST71zeoo3iLqHw+xtx2b6tdEjrR4ZGDg85=u+wd5TXg@mail.gmail.com>
 <CAL9jLaZBDqaSqY2jbo0muENYok4mpDsjK6gAGjaOz0t1n1T9iw@mail.gmail.com>
Message-ID: <alpine.OSX.2.02.1310091350470.14527@dhcp-220-153.meetings.nanog.org>

On Wed, 9 Oct 2013, Christopher Morrow wrote:

> piling on a tad: (for consumer gmail/drive)
> 1) existing session cookies work fine
> 2) new sessions work fine, + 2-step auth

Yea, I'll pile on too.  I have 5 entities that I have gmail accounts setup 
for, plus my personal @gmail account.  I regularly keep several of them 
open at the same time, but for at lest 3 or 4 days I've been unable to 
stay logged into more than 1 at a time.  I've only used Chrome, and I'm in 
PHX at NANOG.  It's super annoying.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
Schedule a meeting:  https://doodle.com/bross            Skype:  brandonross


From Jason_Livingood at cable.comcast.com  Wed Oct  9 17:54:52 2013
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Wed, 9 Oct 2013 17:54:52 +0000
Subject: comcast ipv6 PTR
In-Reply-To: <CAA5Ek4fjKrvrK4P6tARmJMnVEWukPioi3Fho-ZkjQwBrpn_Aiw@mail.gmail.com>
Message-ID: <10229F86C86EB444898E629583FD4171E11515B6@PACDCEXMB06.cable.comcast.com>

On 10/9/13 12:52 PM, "Blair Trosper" <blair.trosper at gmail.com> wrote:


>That's essentially what I'm getting at.  If the v6 addresses/blocks are
>allocated in a similar fashion to IPv4, where the octets are clearly named
>by state and "hsd1", then I don't see why they should lack PTR.

With the small # of IPv4 addresses, generating PTRs was not a big deal.
That is not the case for IPv6 and I believe most large scale network
operators would agree with that.

>However, even if they're not assigned or delegated in that way, it'd be
>helpful to have SOME form of PTR on there.

Helpful for what, precisely?

Jason



From Jason_Livingood at cable.comcast.com  Wed Oct  9 17:56:08 2013
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Wed, 9 Oct 2013 17:56:08 +0000
Subject: comcast ipv6 PTR
In-Reply-To: <52558B8F.7030508@mykolab.com>
Message-ID: <10229F86C86EB444898E629583FD4171E11515D4@PACDCEXMB06.cable.comcast.com>

On 10/9/13 12:59 PM, "Paul Ferguson" <fergdawgster at mykolab.com> wrote:

>That's not necessarily true -- some (very large) organizations using
>DMARC will reject mail from hosts without a PTR record.

True, but a residential customer with a cable modem bootfile that blocks
port 25 wouldn't find that an issue.

Jason



From j at arpa.com  Wed Oct  9 18:07:00 2013
From: j at arpa.com (jamie rishaw)
Date: Wed, 9 Oct 2013 13:07:00 -0500
Subject: google / massive problems
In-Reply-To: <alpine.OSX.2.02.1310091350470.14527@dhcp-220-153.meetings.nanog.org>
References: <CAA5Ek4cQS4JURF-DtuUno6y468nQzez-0JFmre2jVVPRa=d8bg@mail.gmail.com>
 <CAOhg=RwLeB-6zD-=2SGBa47_6+2LZb79G1FZh+cmbVkVq6npNg@mail.gmail.com>
 <CAA5Ek4fST71zeoo3iLqHw+xtx2b6tdEjrR4ZGDg85=u+wd5TXg@mail.gmail.com>
 <CAL9jLaZBDqaSqY2jbo0muENYok4mpDsjK6gAGjaOz0t1n1T9iw@mail.gmail.com>
 <alpine.OSX.2.02.1310091350470.14527@dhcp-220-153.meetings.nanog.org>
Message-ID: <CABL6YZQ9R57QsUe5tLmgjv+5vamwX4VzV0_C-o7qAPJe4mnLaQ@mail.gmail.com>

How do I configure my router for this?


On Wed, Oct 9, 2013 at 12:52 PM, Brandon Ross <bross at pobox.com> wrote:

> On Wed, 9 Oct 2013, Christopher Morrow wrote:
>
>  piling on a tad: (for consumer gmail/drive)
>> 1) existing session cookies work fine
>> 2) new sessions work fine, + 2-step auth
>>
>
> Yea, I'll pile on too.  I have 5 entities that I have gmail accounts setup
> for, plus my personal @gmail account.  I regularly keep several of them
> open at the same time, but for at lest 3 or 4 days I've been unable to stay
> logged into more than 1 at a time.  I've only used Chrome, and I'm in PHX
> at NANOG.  It's super annoying.
>
> --
> Brandon Ross                                      Yahoo & AIM:
>  BrandonNRoss
> +1-404-635-6667                                                ICQ:
>  2269442
> Schedule a meeting:  https://doodle.com/bross            Skype:
>  brandonross
>
>


-- 
jamie rishaw // .com.arpa at j <- reverse it. ish.

*"Reality defeats prejudice."* - *Rep. Barney Frank*

From cma at cmadams.net  Wed Oct  9 18:07:15 2013
From: cma at cmadams.net (Chris Adams)
Date: Wed, 9 Oct 2013 13:07:15 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <CAPKkNb5f4mMmDn6vXSQjwwJU0ee4TByTYoV2DK4My8UjcoGk3A@mail.gmail.com>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009165842.GJ47673@mx1.yitter.info>
 <CAPKkNb5f4mMmDn6vXSQjwwJU0ee4TByTYoV2DK4My8UjcoGk3A@mail.gmail.com>
Message-ID: <20131009180715.GJ1193@cmadams.net>

Once upon a time, Constantine A. Murenin <mureninc at gmail.com> said:
> On my Linode over the summer, it seems like this was the first mention
> of IPv6 in my errorlog:

I didn't see a problem, but my OCD-ness kicked in immediately when I got
my Linode IPv6 - I've always had valid reverse DNS on IPv6 and IPv4
there.
-- 
Chris Adams <cma at cmadams.net>


From james.cutler at consultant.com  Wed Oct  9 18:08:32 2013
From: james.cutler at consultant.com (Cutler James R)
Date: Wed, 9 Oct 2013 14:08:32 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
Message-ID: <456FCEBC-A51F-4D50-80E2-38A9C37CA862@consultant.com>


On Oct 9, 2013, at 12:35 PM, Blair Trosper <blair.trosper at gmail.com> wrote:

> Does anyone know why (or can someone from Comcast explain why) there is no
> PTR on their residential/business IPv6 addresses?

Which IPv6 addresses:
  
1 delegated WAN address?

2 end systems on delegated LAN prefix or with static assignments?

In my experience with Comcast Business Internet:
 
1 the delegated WAN address does have an (almost useless) PTR record which is essentially the AAAA spelled backward.

2 PTR records for automatically configured end systems on a local LAN are a local responsibility. Static IP assignments may come with PTR entries, depending on business arrangements.

Since neither Comcast or any other DNS provider has any direct knowledge of your local network configuration, you cannot expect to see any PTR DNS records for local systems unless you make some business (and technical) arrangements with a DNS provider.

If you really need PTR record for your local SMTP servers, arrange for them with your DNS provider, even if that provider is you.

James R. Cutler
james.cutler at consultant.com





From dave at temk.in  Wed Oct  9 18:56:44 2013
From: dave at temk.in (David Temkin)
Date: Wed, 9 Oct 2013 11:56:44 -0700
Subject: NANOG 59 Tuesday talks now on YouTube
Message-ID: <CAFJiuFr_mOsRar9=y=nwpe8RuD2_k0LgJPL7ynF7q7ftqjxEMA@mail.gmail.com>

Please see
http://www.youtube.com/playlist?list=PLO8DR5ZGla8j7_jnNYY3d8JB0HfdXe85X for
the video list and http://www.nanog.org/meetings/nanog59/agenda for a link
to the slides for each talk.


Regards,
-Dave Temkin
Chair, NANOG Program Committee

From cblecker at gmail.com  Wed Oct  9 19:05:27 2013
From: cblecker at gmail.com (Christoph Blecker)
Date: Wed, 9 Oct 2013 12:05:27 -0700
Subject: NANOG 59 Tuesday talks now on YouTube
In-Reply-To: <CAFJiuFr_mOsRar9=y=nwpe8RuD2_k0LgJPL7ynF7q7ftqjxEMA@mail.gmail.com>
References: <CAFJiuFr_mOsRar9=y=nwpe8RuD2_k0LgJPL7ynF7q7ftqjxEMA@mail.gmail.com>
Message-ID: <CADx2oGFKmDHvpNTxoVyuiWEp2J7zSgpzLrRjBT860PdTxWL4QQ@mail.gmail.com>

Hi Dave,
There are a number of videos in that playlist that are showing as
"deleted". Were some sessions not able to be made available?

Cheers,
Christoph


On Wed, Oct 9, 2013 at 11:56 AM, David Temkin <dave at temk.in> wrote:

> Please see
> http://www.youtube.com/playlist?list=PLO8DR5ZGla8j7_jnNYY3d8JB0HfdXe85Xfor
> the video list and http://www.nanog.org/meetings/nanog59/agenda for a link
> to the slides for each talk.
>
>
> Regards,
> -Dave Temkin
> Chair, NANOG Program Committee
>

From John_Brzozowski at Cable.Comcast.com  Wed Oct  9 21:07:12 2013
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Wed, 9 Oct 2013 21:07:12 +0000
Subject: comcast ipv6 PTR
Message-ID: <BD87928F6BFAEF4EBEB883E1C4F587725279261D@PACDCEXMB01.cable.comcast.com>

The below is largely accurate.  Comcast will support the creation of IPv6
PTR for static commercial IPv6 customers when we launch the same.  We are
currently in trial for dynamic commercial and are expanding our dynamic
trials.  Static IPv6 trials will be starting soon, hopefully November.

John

Date: Wed, 9 Oct 2013 11:41:50 -0500
From: Chris Adams <cma at cmadams.net>
To: nanog at nanog.org
Subject: Re: comcast ipv6 PTR
Message-ID: <20131009164150.GG1193 at cmadams.net>
Content-Type: text/plain; charset=us-ascii

Once upon a time, Blair Trosper <blair.trosper at gmail.com> said:
>Does anyone know why (or can someone from Comcast explain why) there is no
>PTR on their residential/business IPv6 addresses?

I believe business customers (with a static assignment) can request
reverse DNS entries.  Residential customers are not guaranteed a static
assignment, so they can't get reverse set.

--
Chris Adams <cma at cmadams.net>



From niels=nanog at bakker.net  Wed Oct  9 21:10:11 2013
From: niels=nanog at bakker.net (Niels Bakker)
Date: Wed, 9 Oct 2013 23:10:11 +0200
Subject: NANOG 59 - Monday presentations on YouTube
In-Reply-To: <CAFJiuFrtjK=dw0mT1xsH94K5ipM0Ey5A98TwbDGEjogBnc1o9g@mail.gmail.com>
References: <CAFJiuFrtjK=dw0mT1xsH94K5ipM0Ey5A98TwbDGEjogBnc1o9g@mail.gmail.com>
Message-ID: <20131009211010.GN3108@burnout.tpb.net>

* dave at temk.in (David Temkin) [Tue 08 Oct 2013, 23:43 CEST]:
>We're proud to announce that all of the recorded presentations from 
>Monday at NANOG 59 in Phoenix have now been posted to Youtube.

This is really neat.


	-- Niels.


From daniel at net2ez.com  Wed Oct  9 21:26:16 2013
From: daniel at net2ez.com (Daniel Faubel)
Date: Wed, 9 Oct 2013 14:26:16 -0700
Subject: bcop.nanog.org issues
Message-ID: <7A4DDCD7113C2E46ACCC8FB9F6742CAD2F6DA3A3E4@EZ-LAX4-M07.ezdom.net2ez.com>

Anyone able to confirm issues with bcop.nanog.org?



Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0
Warning: require(): Unable to allocate memory for pool. in /usr/local/www/mediawiki/index.php on line 54
Warning: Cannot modify header information - headers already sent in /usr/local/www/mediawiki/includes/WebStart.php on line 63
Warning: require_once(): Unable to allocate memory for pool. in /usr/local/www/mediawiki/includes/WebStart.php on line 94
Warning: require_once(): Unable to allocate memory for pool. in /usr/local/www/mediawiki/includes/WebStart.php on line 97
Warning: require_once(): Unable to allocate memory for pool. in /usr/local/www/mediawiki/includes/WebStart.php on line 100
Warning: require_once(): Unable to allocate memory for pool. in /usr/local/www/mediawiki/includes/WebStart.php on line 103
Warning: require_once(): Unable to allocate memory for pool. in /usr/local/www/mediawiki/includes/Defines.php on line 187
Warning: require_once(): Unable to allocate memory for pool. in /usr/local/www/mediawiki/includes/WebStart.php on line 115


-Daniel

From hannigan at gmail.com  Wed Oct  9 22:03:09 2013
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 10 Oct 2013 00:03:09 +0200
Subject: NANOG 59 - Monday presentations on YouTube
Message-ID: <CAMDXq5P7HVMs_F2SqbYopRQo+iHFqz_+-Ex0JBJRFpM9va_LPQ@mail.gmail.com>

Yes, very awesome!

Wanted to take a quick moment to thank Sylvie, Betty and rest of the
outgoing (past included) Board members for a job well done. So far has
NANOG come and in such a short time. Great work everyone.

Best,

-M<





On Wed, Oct 9, 2013 at 11:10 PM, Niels Bakker <niels=nanog at bakker.net>wrote:

> * dave at temk.in (David Temkin) [Tue 08 Oct 2013, 23:43 CEST]:
>
>  We're proud to announce that all of the recorded presentations from
>> Monday at NANOG 59 in Phoenix have now been posted to Youtube.
>>
>
> This is really neat.
>
>
>         -- Niels.
>
>

From ml-nanog090304q at elcsplace.com  Thu Oct 10 00:07:32 2013
From: ml-nanog090304q at elcsplace.com (Ted Cooper)
Date: Thu, 10 Oct 2013 10:07:32 +1000
Subject: comcast ipv6 PTR
In-Reply-To: <CAPKkNb5f4mMmDn6vXSQjwwJU0ee4TByTYoV2DK4My8UjcoGk3A@mail.gmail.com>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009165842.GJ47673@mx1.yitter.info>
 <CAPKkNb5f4mMmDn6vXSQjwwJU0ee4TByTYoV2DK4My8UjcoGk3A@mail.gmail.com>
Message-ID: <5255EFC4.8060602@elcsplace.com>

On 10/10/13 03:30, Constantine A. Murenin wrote:
> Yet, apparently, Google has very recently completely stopped accepting
> email with no PTR records.

They also don't try very hard to get the PTR record. If the packet is
lost, has a routing issue, or a DDoS prevents reliable access to the
name servers, you will also get emails hard rejected until it resolves
again. I'd always had correct rDNS so it took quite some head scratching
to figure out the hiccup.




From mehmet at akcin.net  Thu Oct 10 01:04:49 2013
From: mehmet at akcin.net (Mehmet Akcin)
Date: Wed, 9 Oct 2013 18:04:49 -0700
Subject: NANOG 59 - Monday presentations on YouTube
In-Reply-To: <CAMDXq5P7HVMs_F2SqbYopRQo+iHFqz_+-Ex0JBJRFpM9va_LPQ@mail.gmail.com>
References: <CAMDXq5P7HVMs_F2SqbYopRQo+iHFqz_+-Ex0JBJRFpM9va_LPQ@mail.gmail.com>
Message-ID: <F4BD131D-A1DA-4AFC-8BEB-278147F86FDD@akcin.net>


On Oct 9, 2013, at 3:03 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> Yes, very awesome!
> 
> Wanted to take a quick moment to thank Sylvie, Betty and rest of the
> outgoing (past included) Board members for a job well done. So far has
> NANOG come and in such a short time. Great work everyone.
> 
> Best,
> 
> -M<

+1 excellent job.

mehmet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2322 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131009/c905bd5b/attachment.bin>

From bzs at world.std.com  Thu Oct 10 01:11:43 2013
From: bzs at world.std.com (Barry Shein)
Date: Wed, 9 Oct 2013 21:11:43 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <20131009164947.GI1193@cmadams.net>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net>
 <web-63958@mail.saroza-webb.local>
 <20131009164947.GI1193@cmadams.net>
Message-ID: <21077.65231.279689.263778@world.std.com>


On October 9, 2013 at 11:49 cma at cmadams.net (Chris Adams) wrote:
 > Once upon a time, Robert Webb <rwebb at ropeguru.com> said:
 > > But how would thet differ from the IPv4 address space which has PTR
 > > records for all their IP's? Just the shear number they would have to
 > > deal with in the IPv6 space?
 > 
 > Oh, are you looking for auto-generated reverse for every address?
 > That's not going to happen for IPv6 (and it turns out that it wasn't
 > really a good idea for IPv4).  There's no reason to have reverse DNS
 > unless it has meaning, and "12-34-56-78.rev.domain.net" isn't really all
 > that useful.

It's very useful for blocking spammers and other miscreants -- no
reason at all to accept SMTP connections from troublesome
*.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN
is.

Perhaps not their problem, but it is useful!

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From jabley at hopcount.ca  Thu Oct 10 01:14:28 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 9 Oct 2013 18:14:28 -0700
Subject: NANOG 59 - Monday presentations on YouTube
In-Reply-To: <F4BD131D-A1DA-4AFC-8BEB-278147F86FDD@akcin.net>
References: <CAMDXq5P7HVMs_F2SqbYopRQo+iHFqz_+-Ex0JBJRFpM9va_LPQ@mail.gmail.com>
 <F4BD131D-A1DA-4AFC-8BEB-278147F86FDD@akcin.net>
Message-ID: <74568F31-FFC8-47DD-A0D2-F724DB4A2F6C@hopcount.ca>


On 2013-10-09, at 18:04, Mehmet Akcin <mehmet at akcin.net> wrote:

> On Oct 9, 2013, at 3:03 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> 
>> Yes, very awesome!
>> 
>> Wanted to take a quick moment to thank Sylvie, Betty and rest of the
>> outgoing (past included) Board members for a job well done. So far has
>> NANOG come and in such a short time. Great work everyone.
>> 
>> Best,
>> 
>> -M<
> 
> +1 excellent job.

I'd also like to thank the members for voting in much greater numbers than are normally seen, and for having the good sense to elect three new board members that I'm sure will do a better job than I would have done!

This all adds up to a good result for NANOG. I like it.


Joe

From cma at cmadams.net  Thu Oct 10 01:18:17 2013
From: cma at cmadams.net (Chris Adams)
Date: Wed, 9 Oct 2013 20:18:17 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <21077.65231.279689.263778@world.std.com>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net>
 <web-63958@mail.saroza-webb.local>
 <20131009164947.GI1193@cmadams.net>
 <21077.65231.279689.263778@world.std.com>
Message-ID: <20131010011817.GD4950@cmadams.net>

Once upon a time, Barry Shein <bzs at world.std.com> said:
> It's very useful for blocking spammers and other miscreants -- no
> reason at all to accept SMTP connections from troublesome
> *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN
> is.

If you are going to block like that, just block anybody without valid
reverse DNS.  If you don't trust provider foo.net to police their users,
why trust them to put valid and consistent xx-xx-xx-xx.dyn.foo.net
reverse?

I only see a use for reverse DNS for router interfaces (for useful
traceroute info) and servers (and only really SMTP servers).  Most of
the rest is fluff, often out-of-date, uselessly auto-generated, etc.

-- 
Chris Adams <cma at cmadams.net>


From shrdlu at deaddrop.org  Thu Oct 10 01:35:37 2013
From: shrdlu at deaddrop.org (Shrdlu)
Date: Wed, 09 Oct 2013 18:35:37 -0700
Subject: NANOG 59 - Monday presentations on YouTube
In-Reply-To: <74568F31-FFC8-47DD-A0D2-F724DB4A2F6C@hopcount.ca>
References: <CAMDXq5P7HVMs_F2SqbYopRQo+iHFqz_+-Ex0JBJRFpM9va_LPQ@mail.gmail.com>
 <F4BD131D-A1DA-4AFC-8BEB-278147F86FDD@akcin.net>
 <74568F31-FFC8-47DD-A0D2-F724DB4A2F6C@hopcount.ca>
Message-ID: <52560469.8090302@deaddrop.org>

On 10/9/2013 6:14 PM, Joe Abley wrote:

> I'd also like to thank the members for voting in much greater
> numbers than are normally seen, and for having the good sense to
> elect three new board members that I'm sure will do a better job than
> I would have done!

*I* voted for you. Maybe I should have voted more than once?

I'm hoping that the pages will be updated soon with the results:

http://www.nanog.org/elections/2013/results

It really seems that NANOG is well on the way to becoming a going
concern. I may actually make the trek to Bellevue (which has the
virtue of being closer to home).

-- 
Life may not be the party we hoped for, but while we are here,
we might as well dance.



From marka at isc.org  Thu Oct 10 01:35:52 2013
From: marka at isc.org (Mark Andrews)
Date: Thu, 10 Oct 2013 12:35:52 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Wed, 09 Oct 2013 21:11:43 -0400."
 <21077.65231.279689.263778@world.std.com>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net> <web-63958@mail.saroza-webb.local>
 <20131009164947.GI1193@cmadams.net> <21077.65231.279689.263778@world.std.com>
Message-ID: <20131010013552.EA3808078C1@rock.dv.isc.org>


In message <21077.65231.279689.263778 at world.std.com>, Barry Shein writes:
> 
> On October 9, 2013 at 11:49 cma at cmadams.net (Chris Adams) wrote:
>  > Once upon a time, Robert Webb <rwebb at ropeguru.com> said:
>  > > But how would thet differ from the IPv4 address space which has PTR
>  > > records for all their IP's? Just the shear number they would have to
>  > > deal with in the IPv6 space?
>  > 
>  > Oh, are you looking for auto-generated reverse for every address?
>  > That's not going to happen for IPv6 (and it turns out that it wasn't
>  > really a good idea for IPv4).  There's no reason to have reverse DNS
>  > unless it has meaning, and "12-34-56-78.rev.domain.net" isn't really all
>  > that useful.
> 
> It's very useful for blocking spammers and other miscreants -- no
> reason at all to accept SMTP connections from troublesome
> *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN
> is.
> 
> Perhaps not their problem, but it is useful!

And not accepting SMTP from everybody leaves your customers exposed
to NSA and others snooping the wires or ISP being subject to
warrentless requests to send all the email delivered to their
submission and other servers to various government agencies under
the idiotic notion that email is always sent in the clear so it
doesn't need a warrant.

Direct to MX reduces the risk of snooping to the two end points and
end point MITM can be detected with the use of tls.

If we want secure email, and we should want secure email, then we
should be pushing for direct to MX with every customer hosting their
own MX server and start tls on by default.

Yes that comes with the risk of additional spam but get over it and
run proper abuse desks.

Mark

> -- 
>         -Barry Shein
> 
> The World              | bzs at TheWorld.com           | http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
> Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From jabley at hopcount.ca  Thu Oct 10 01:40:36 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 9 Oct 2013 18:40:36 -0700
Subject: NANOG 59 - Monday presentations on YouTube
In-Reply-To: <52560469.8090302@deaddrop.org>
References: <CAMDXq5P7HVMs_F2SqbYopRQo+iHFqz_+-Ex0JBJRFpM9va_LPQ@mail.gmail.com>
 <F4BD131D-A1DA-4AFC-8BEB-278147F86FDD@akcin.net>
 <74568F31-FFC8-47DD-A0D2-F724DB4A2F6C@hopcount.ca>
 <52560469.8090302@deaddrop.org>
Message-ID: <0F518BB3-A389-4F67-80CE-A58545E4D043@hopcount.ca>


On 2013-10-09, at 18:35, Shrdlu <shrdlu at deaddrop.org> wrote:

> On 10/9/2013 6:14 PM, Joe Abley wrote:
> 
>> I'd also like to thank the members for voting in much greater
>> numbers than are normally seen, and for having the good sense to
>> elect three new board members that I'm sure will do a better job than
>> I would have done!
> 
> *I* voted for you. Maybe I should have voted more than once?
> 
> I'm hoping that the pages will be updated soon with the results:
> 
> http://www.nanog.org/elections/2013/results
> 
> It really seems that NANOG is well on the way to becoming a going
> concern. I may actually make the trek to Bellevue (which has the
> virtue of being closer to home).

This probably belongs on the members list, but yes, the progress made by the organisation to date is very impressive. Costs are down, attendance is up, sponsorship is up, venues and dates have been locked in for the next two years, and the strategic plan looks entirely sane.

(the programme here in Phoenix was great too, in my opinion, big thumbs up to the PC)


Joe

From johnl at iecc.com  Thu Oct 10 02:01:27 2013
From: johnl at iecc.com (John Levine)
Date: 10 Oct 2013 02:01:27 -0000
Subject: comcast ipv6 PTR
In-Reply-To: <93D9A8E3-A7D0-40EE-AAA9-3207A5D14E90@hopcount.ca>
Message-ID: <20131010020127.3668.qmail@joyce.lan>

>If people really want to use generic reverse names and have realised
>that the v6 address space is much too big for $GENERATE, one approach is
>to delegate the appropriate zones to a custom nameserver that can
>auto-generate PTRs on demand. There are scaling problems here, but
>probably nothing that can't be fixed with high TTLs and multiple
>nameservers.

In my discussions with people at some big ISPs, I got the impression
that they could do that, but it wouldn't provide any more useful
information than no rDNS at all, so they don't.  I'm on T-W cable,
and there's no way for me to set rDNS.  It'd be more trouble than
it's worth, since my /64 changes every time the modem reboots
which seems to be about once a month.

Real servers on static addresses are different, of course.  My servers
are on an HE tunnel, and all have matching forward and reverse DNS.

R's,
John


From tritran at cox.net  Thu Oct 10 02:37:02 2013
From: tritran at cox.net (Tri Tran)
Date: Thu, 10 Oct 2013 02:37:02 +0000
Subject: Cabling contractor in Miami
Message-ID: <1419902411-1381372619-cardhu_decombobulator_blackberry.rim.net-705657830-@b12.c19.bise6.blackberry>

If anyone can recommend a commercial cabling contractor in the Miami area I would appreciate it. Thanks in advance.
Tri Tran


From bzs at world.std.com  Thu Oct 10 05:09:39 2013
From: bzs at world.std.com (Barry Shein)
Date: Thu, 10 Oct 2013 01:09:39 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <20131010011817.GD4950@cmadams.net>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net>
 <web-63958@mail.saroza-webb.local>
 <20131009164947.GI1193@cmadams.net>
 <21077.65231.279689.263778@world.std.com>
 <20131010011817.GD4950@cmadams.net>
Message-ID: <21078.13971.505553.140013@world.std.com>


On October 9, 2013 at 20:18 cma at cmadams.net (Chris Adams) wrote:
 > Once upon a time, Barry Shein <bzs at world.std.com> said:
 > > It's very useful for blocking spammers and other miscreants -- no
 > > reason at all to accept SMTP connections from troublesome
 > > *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN
 > > is.
 > 
 > If you are going to block like that, just block anybody without valid
 > reverse DNS.  If you don't trust provider foo.net to police their users,
 > why trust them to put valid and consistent xx-xx-xx-xx.dyn.foo.net
 > reverse?

Because they do, they just do. This isn't a math proof, it's mostly
social engineering. The providers aren't trying to fool anyone, in
general, it's just that clients and websites get botted.

 > I only see a use for reverse DNS for router interfaces (for useful
 > traceroute info) and servers (and only really SMTP servers).  Most of
 > the rest is fluff, often out-of-date, uselessly auto-generated, etc.

It's pretty amazing how much spam comes from hosts with names a lot
like ns1.example.com, their name servers. Not sure why they're so
easily abused but maybe it doesn't occur to them to lock down MTAs on
their name servers.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From bzs at world.std.com  Thu Oct 10 05:16:28 2013
From: bzs at world.std.com (Barry Shein)
Date: Thu, 10 Oct 2013 01:16:28 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <20131010013552.EA3808078C1@rock.dv.isc.org>
References: <CAA5Ek4fVhjzjLTAFovc4gopOqPuSO8twc-dVwPf7WXZzAgvrmg@mail.gmail.com>
 <20131009164150.GG1193@cmadams.net>
 <web-63958@mail.saroza-webb.local>
 <20131009164947.GI1193@cmadams.net>
 <21077.65231.279689.263778@world.std.com>
 <20131010013552.EA3808078C1@rock.dv.isc.org>
Message-ID: <21078.14380.469259.587172@world.std.com>


On October 10, 2013 at 12:35 marka at isc.org (Mark Andrews) wrote:
 > 
 > Yes that comes with the risk of additional spam but get over it and
 > run proper abuse desks.

With all due respect I don't think you have an inkling of the
magnitude of the spam problem if you can say something like this. And
what does it have to do with recipient ISP abuse desks?

Your basic point is well taken, it would be better if everyone could
do end to end TLS etc. Not so much to evade the NSA (probably hopeless
for most people) but the more run of the mill snooper.

It's all just an arms race.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From swmike at swm.pp.se  Thu Oct 10 06:59:48 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 10 Oct 2013 08:59:48 +0200 (CEST)
Subject: NANOG 59 - Monday presentations on YouTube
In-Reply-To: <20131009211010.GN3108@burnout.tpb.net>
References: <CAFJiuFrtjK=dw0mT1xsH94K5ipM0Ey5A98TwbDGEjogBnc1o9g@mail.gmail.com>
 <20131009211010.GN3108@burnout.tpb.net>
Message-ID: <alpine.DEB.2.02.1310100859080.20065@uplift.swm.pp.se>

On Wed, 9 Oct 2013, Niels Bakker wrote:

> * dave at temk.in (David Temkin) [Tue 08 Oct 2013, 23:43 CEST]:
>> We're proud to announce that all of the recorded presentations from Monday 
>> at NANOG 59 in Phoenix have now been posted to Youtube.
>
> This is really neat.

I agree, it's great! My only nit with it is that the aspect ratio seems to 
be wrong.

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


From dave at temk.in  Thu Oct 10 12:20:43 2013
From: dave at temk.in (David Temkin)
Date: Thu, 10 Oct 2013 05:20:43 -0700
Subject: NANOG 59 - Wednesday presentations on YouTube
Message-ID: <CAFJiuFq2xwrDpLWjzh56ERGtohJCiPALguzUYwXSX_vYJo3PkQ@mail.gmail.com>

NANOG,

All of the recorded presentations from Wednesday at NANOG 59 in Phoenix
including the Q&A with Ladar Levison of Lavabit have now been posted to
YouTube.  You may visit the NANOG 59 YouTube page at http://goo.gl/c4k5zG


Regards,
-Dave Temkin
Chair, NANOG Program Committee

From ahebert at pubnix.net  Thu Oct 10 16:06:52 2013
From: ahebert at pubnix.net (Alain Hebert)
Date: Thu, 10 Oct 2013 12:06:52 -0400
Subject: Need offlist contact for relay.globetrotter.net
Message-ID: <5256D09C.3090208@pubnix.net>

    Well,

    If anyone has any postmaster/abused contacts for

    relay.globetrotter.net
    142.169.1.45
    (Telus Quebec?)

    For the past few days, we're getting some customers complaint about
cryptic "452 4.1.0 ... temporary failure" message from them.

    And the usual channel as dead as usual.

    Have fun.

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



From elouie at yahoo.com  Thu Oct 10 18:02:02 2013
From: elouie at yahoo.com (Eric A Louie)
Date: Thu, 10 Oct 2013 11:02:02 -0700 (PDT)
Subject: Need offlist contact for relay.globetrotter.net
In-Reply-To: <5256D09C.3090208@pubnix.net>
References: <5256D09C.3090208@pubnix.net>
Message-ID: <1381428122.17985.YahooMailNeo@web181602.mail.ne1.yahoo.com>

Have you tried the (possible stale) info from ARIN? 

http://whois.arin.net/rest/poc/DS538-ARIN.html





>________________________________
> From: Alain Hebert <ahebert at pubnix.net>
>To: 'NANOG list' <nanog at nanog.org> 
>Sent: Thursday, October 10, 2013 9:06 AM
>Subject: Need offlist contact for relay.globetrotter.net
> 
>
>? ? Well,
>
>? ? If anyone has any postmaster/abused contacts for
>
>? ? relay.globetrotter.net
>? ? 142.169.1.45
>? ? (Telus Quebec?)
>
>? ? For the past few days, we're getting some customers complaint about
>cryptic "452 4.1.0 ... temporary failure" message from them.
>
>? ? And the usual channel as dead as usual.
>
>? ? Have fun.
>
>-- 
>-----
>Alain Hebert? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ahebert at pubnix.net? 
>PubNIX Inc.? ? ? ? 
>50 boul. St-Charles
>P.O. Box 26770? ?  Beaconsfield, Quebec? ?  H9W 6G7
>Tel: 514-990-5911? http://www.pubnix.net? ? Fax: 514-990-9443
>
>
>
>
>

From cgrundemann at gmail.com  Thu Oct 10 18:06:02 2013
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 10 Oct 2013 12:06:02 -0600
Subject: Lavabit / Ladar Levison Info
Message-ID: <CAC1-dtkLnNLD2fdGUzkxb2Y2v7_1VKBsTmD29-oFmcxSyWqvYg@mail.gmail.com>

Hail NANOG!

I have received multiple off-line and in person requests for information on
the Lavabit Legal Defense Fund, so I'm going to just take a shotgun
approach here:

The Lavabit website:
http://lavabit.com/

PayPal link to donate to the Fund:
https://www.paypal.com/us/cgi-bin/webscr?cmd=_flow&SESSION=nQ99ER2hX3k0ZCBcI6h6Sh-4hL3enESRD5dSCS10pTkprxm8kjh_MkI9REC&dispatch=5885d80a13c0db1f8e263663d3faee8d0038486cd0d9a2f3f8e698d26650388a

Also, direct link to the Q&A with Ladar yesterday:
http://www.youtube.com/watch?v=uo9-0So2A_g&feature=share&list=PLO8DR5ZGla8j7_jnNYY3d8JB0HfdXe85X

Cheers,
~Chris


-- 
@ChrisGrundemann
http://chrisgrundemann.com

From gparent at gparent.org  Thu Oct 10 18:46:25 2013
From: gparent at gparent.org (Guillaume Parent)
Date: Thu, 10 Oct 2013 14:46:25 -0400
Subject: Contact for free-mobile.fr
Message-ID: <CACT83a=YA_bkn+2XNFkWeYe0qDNXADzP+xfkPQmCQr2HcbUMQw@mail.gmail.com>

Hi,

I am getting unsolicited mail from what appears to be the mobile division
of Free. postmaster is sleeping at his post even after a few different
attempts. I normally wouldn't make a big deal of this except I am receiving
potentially sensitive information of other customers straight into my inbox.

If anyone could put me in touch with anything resembling a human being at
Free, it'd be great. I can speak french so that's not an issue.

Thanks,
-gp

From cciehelps at gmail.com  Fri Oct 11 05:31:22 2013
From: cciehelps at gmail.com (ku po)
Date: Fri, 11 Oct 2013 13:31:22 +0800
Subject: To CCIEs and JNCIEs
Message-ID: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>

Hi,

Please relay to your CCIE/JNCIE friends, I am giving out name at theccie.comand
name at jncie.com email accounts, anyone interested can contact me.

From cciehelps at gmail.com  Fri Oct 11 05:33:23 2013
From: cciehelps at gmail.com (ku po)
Date: Fri, 11 Oct 2013 13:33:23 +0800
Subject: To CCIEs and JNCIEs
In-Reply-To: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
Message-ID: <CAAtfGYgnrzBo+jwT1MwxiyCrpwrH3pWj9WiNWNy91c-aBBtjQw@mail.gmail.com>

I made a typo, name at theccie.com and name at thejncie.com email accounts,
cheers.


On Fri, Oct 11, 2013 at 1:31 PM, ku po <cciehelps at gmail.com> wrote:

> Hi,
>
> Please relay to your CCIE/JNCIE friends, I am giving out name at theccie.comand
> name at jncie.com email accounts, anyone interested can contact me.
>

From randy at psg.com  Fri Oct 11 07:28:04 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 11 Oct 2013 16:28:04 +0900
Subject: To CCIEs and JNCIEs
In-Reply-To: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
Message-ID: <m2hacoxo57.wl%randy@psg.com>

> Please relay to your CCIE/JNCIE friends, I am giving out
> name at theccie.comand name at jncie.com email accounts, anyone interested
> can contact me.

but who would want to deal with such slime?


From mpetach at netflight.com  Fri Oct 11 08:43:44 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 11 Oct 2013 01:43:44 -0700
Subject: 2013.10.09 NANOG59 notes posted
Message-ID: <CAEmG1=oUAxwH35FuQKsss-wh5kuyYC9pWeTQ3Tmwmqux=WrRfw@mail.gmail.com>

Sorry, ARIN's been keeping me busy
since the NANOG wrap-up, but finally
took some time after the social tonight
to finish posting all the rest of my notes,
minus the IP Reputation notes, to
http://nanog.cluepon.net/index.php/NANOG59
Another awesome NANOG, one of the
best ones in a while; thanks again to everyone
who helped make it a kick-ass conference!

Matt

From LudendorffR at rferl.org  Fri Oct 11 11:16:32 2013
From: LudendorffR at rferl.org (Ray Ludendorff)
Date: Fri, 11 Oct 2013 13:16:32 +0200
Subject: Baghdad internet access
Message-ID: <OF6DFA9E6D.FCFA9122-ONC1257C01.003DC9FA-C1257C01.003DF2E0@rferl.org>

Access to Baghdad(Iraq) via internet is not possible.  Anyone seeing the 
same thing ?

Regards
-Ray L.
 

From sfouant at shortestpathfirst.net  Fri Oct 11 12:48:51 2013
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Fri, 11 Oct 2013 08:48:51 -0400
Subject: To CCIEs and JNCIEs
In-Reply-To: <m2hacoxo57.wl%randy@psg.com>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
 <m2hacoxo57.wl%randy@psg.com>
Message-ID: <C645B14A-2A0B-4C47-9460-82217C29B133@shortestpathfirst.net>

Seriously... Those cert monkeys think they know everything ;)

Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI
m (703) 625-6243

On Oct 11, 2013, at 3:28 AM, Randy Bush <randy at psg.com> wrote:

>> Please relay to your CCIE/JNCIE friends, I am giving out
>> name at theccie.comand name at jncie.com email accounts, anyone interested
>> can contact me.
> 
> but who would want to deal with such slime?
> 

From gparent at gparent.org  Fri Oct 11 17:24:11 2013
From: gparent at gparent.org (Guillaume Parent)
Date: Fri, 11 Oct 2013 13:24:11 -0400
Subject: Contact for free-mobile.fr
In-Reply-To: <20131011191120.3ff1705e@riri.DEF.witbe.net>
References: <CACT83a=YA_bkn+2XNFkWeYe0qDNXADzP+xfkPQmCQr2HcbUMQw@mail.gmail.com>
 <20131011191120.3ff1705e@riri.DEF.witbe.net>
Message-ID: <CACT83a=NMK8Qou685KG-Rhv7UQHVDuEP_DZQ08bPMqVR0HRnSg@mail.gmail.com>

Hi,

They did, unfortunately I've been having one busy week. I should get around
to pinging the person who replied to me today, and thank you if that person
reads this email and to you as well. It's much appreciated.

Thanks,


On Fri, Oct 11, 2013 at 1:11 PM, Paul Rolland <rol at witbe.net> wrote:

> Hello Guillaume,
>
> Did you try to ping someone on FrNog ? People from Free are generally not
> showing up a lot, but considering what you describe, they'd most probably
> at least contact you privately...
>
> Paul
>
> On Thu, 10 Oct 2013 14:46:25 -0400
> Guillaume Parent <gparent at gparent.org> wrote:
>
> > Hi,
> >
> > I am getting unsolicited mail from what appears to be the mobile division
> > of Free. postmaster is sleeping at his post even after a few different
> > attempts. I normally wouldn't make a big deal of this except I am
> > receiving potentially sensitive information of other customers straight
> > into my inbox.
> >
> > If anyone could put me in touch with anything resembling a human being at
> > Free, it'd be great. I can speak french so that's not an issue.
> >
> > Thanks,
> > -gp
> >
>
>
> --
> TelcoTV Awards 2011 - Witbe winner in "Innovation in Test & Measurement"
>
> Paul Rolland                                E-Mail : rol(at)witbe.net
> CTO - Witbe.net SA                          Tel. +33 (0)1 47 67 77 77
> Les Collines de l'Arche                     Fax. +33 (0)1 47 67 77 99
> F-92057 Paris La Defense                    RIPE : PR12-RIPE
>
> LinkedIn : http://www.linkedin.com/in/paulrolland
> Skype    : rollandpaul
>
> "I worry about my child and the Internet all the time, even though she's
> too young to have logged on yet. Here's what I worry about. I worry that 10
> or 15 years from now, she will come to me and say 'Daddy, where were you
> when they took freedom of the press away from the Internet?'"
> --Mike Godwin, Electronic Frontier Foundation
>
>
>

From wwaites at tardis.ed.ac.uk  Fri Oct 11 17:27:00 2013
From: wwaites at tardis.ed.ac.uk (William Waites)
Date: Fri, 11 Oct 2013 18:27:00 +0100 (BST)
Subject: Policy-based routing is evil? Discuss.
Message-ID: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>

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
  - None of the usual debugging tools work properly
  - Adding a new user is complicated because it has to be done in (at
    least) two places

But I'm having a distinct lack of success locating rants and diatribes
or even well-reasoned articles supporting this opinion.

Am I out to lunch?

-w
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131011/81b31a32/attachment.bin>

From jared at puck.nether.net  Fri Oct 11 17:35:02 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 11 Oct 2013 13:35:02 -0400
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: <8602FB8D-212C-4218-91E2-7BDAB2F62C9C@puck.nether.net>


On Oct 11, 2013, at 1: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
>  - None of the usual debugging tools work properly

I think this all depends on how it's configured, and if you can monitor/detect failures.

I've seen folks do things like this with a Linux box with "multiple routing tables".  If you have something validate the link is working, you can easily have it "fail over".  This is all depending on the admin to do it right.

>  - Adding a new user is complicated because it has to be done in (at
>    least) two places

This all depends on the tool set in use/available.

> But I'm having a distinct lack of success locating rants and diatribes
> or even well-reasoned articles supporting this opinion.
> 
> Am I out to lunch?

No, but most people I've seen either

a) set it up, it works (or seems to) and cross their fingers and move to the next fire
b) try to over-engineer the crap out of it so it's got what they feel is "100% availability" but isn't sustainable or maintainable by someone other than themselves.

The simple answer is: rfc1925 7.a & 8 apply

- Jared



From rdobbins at arbor.net  Fri Oct 11 17:37:37 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Fri, 11 Oct 2013 17:37:37 +0000
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: <7F4CB6D9-A94E-41DF-8D51-6DBD3AEF8F37@arbor.net>


On Oct 12, 2013, at 12:27 AM, William Waites <wwaites at tardis.ed.ac.uk> wrote:

> But I'm having a distinct lack of success locating rants and diatribes or even well-reasoned articles supporting this opinion.

Possibly because it's so commonly known that PBR is generally a Very Bad Idea for the reasons you cite, and more, that nobody has felt the need to re-state the obvious?

;>

> Am I out to lunch?

Not with regards to PBR, at least, IMHO.

;>

It's to be avoided if at all possible.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton

-------------- 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/20131011/9a08e26f/attachment.bin>

From joelja at bogus.com  Fri Oct 11 17:41:46 2013
From: joelja at bogus.com (joel jaeggli)
Date: Fri, 11 Oct 2013 10:41:46 -0700
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: <EF0576F1-FAB9-4634-AE64-8AC3FDCC2DD4@bogus.com>


On Oct 11, 2013, at 10:27 AM, 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

it's brittle

>  - None of the usual debugging tools work properly
>  - Adding a new user is complicated because it has to be done in (at
>    least) two places
> 

you take all the useful information that an IGP could be (or is) providing you, and then you ignore it and do something else.

> But I'm having a distinct lack of success locating rants and diatribes
> or even well-reasoned articles supporting this opinion.
> 
> Am I out to lunch?

evil is not a synonym for ugly patch placed over a problem that could be handled better. If it's being used as an alternative to VRF, it isn't.

> 
> -w
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.

-------------- 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/20131011/d1d4bfd3/attachment.bin>

From m.hallgren at free.fr  Fri Oct 11 18:05:42 2013
From: m.hallgren at free.fr (Michael Hallgren)
Date: Fri, 11 Oct 2013 20:05:42 +0200
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <EF0576F1-FAB9-4634-AE64-8AC3FDCC2DD4@bogus.com>
References: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
 <EF0576F1-FAB9-4634-AE64-8AC3FDCC2DD4@bogus.com>
Message-ID: <52583DF6.2020505@free.fr>


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

Le 11/10/2013 19:41, joel jaeggli a ?crit :
>
> On Oct 11, 2013, at 10:27 AM, 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
>
> it's brittle
>
>>  - None of the usual debugging tools work properly
>>  - Adding a new user is complicated because it has to be done in (at
>>    least) two places
>>
>
> you take all the useful information that an IGP could be (or is)
providing you, and then you ignore it and do something else.

I like that phrase. ;-)

mh
>
>
>> But I'm having a distinct lack of success locating rants and diatribes
>> or even well-reasoned articles supporting this opinion.
>>
>> Am I out to lunch?
>
> evil is not a synonym for ugly patch placed over a problem that could
be handled better. If it's being used as an alternative to VRF, it isn't.
>
>>
>> -w
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJYPfUACgkQZNZ/rrgsqad+uQCgmQlT3kz8F6QrsYZe8SJmlrvJ
k4MAn2CwQIOJF8vm1yXTsJh0vZR/cOVi
=L+tx
-----END PGP SIGNATURE-----



From jtk at cymru.com  Fri Oct 11 18:13:04 2013
From: jtk at cymru.com (John Kristoff)
Date: Fri, 11 Oct 2013 13:13:04 -0500
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: <20131011131304.750c1f0e@localhost>

On Fri, 11 Oct 2013 18:27:00 +0100 (BST)
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.

BGP is nothing if not policy-based routing, but I think I see your
concern with an approach that essentially statically locks in a
particular set of paths to links.

Not knowing what if any routing is configured between the end points,
perhaps just point out there are alternative means to achieve load
balancing.  Perhaps using LOCAL_PREF for some set of ASNs over one path
or the other, or alternatively doing some sort of flow-based load
balancing might be sufficient.

John


From wwaites at tardis.ed.ac.uk  Fri Oct 11 18:13:57 2013
From: wwaites at tardis.ed.ac.uk (William Waites)
Date: Fri, 11 Oct 2013 19:13:57 +0100 (BST)
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <EF0576F1-FAB9-4634-AE64-8AC3FDCC2DD4@bogus.com>
References: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
 <EF0576F1-FAB9-4634-AE64-8AC3FDCC2DD4@bogus.com>
Message-ID: <20131011.191357.239591912.wwaites@tardis.ed.ac.uk>

On Fri, 11 Oct 2013 10:41:46 -0700, joel jaeggli <joelja at bogus.com> said:

    > you take all the useful information that an IGP could be (or is)
    > providing you, and then you ignore it and do something else.

Yes, that's another part of the conversation, encouraging the use of
an IGP, which has been a source of trouble for them because of broken
wireless bridges from a very commonly used vendor that randomly eat
multicast packets, so it's not as straightforward as it should be.

    > evil is not a synonym for ugly patch placed over a problem that
    > could be handled better.

Ok, fair enough. My first experience with PBR was as a summer intern in
the mid-1990s who inherited management of a large ATM network that had
a big VPN-esque thing built entirely that way and with no
documentation. It certainly felt evil at the time. ;)

-w

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131011/c4f9c169/attachment-0001.bin>

From jlewis at lewis.org  Fri Oct 11 18:19:36 2013
From: jlewis at lewis.org (Jon Lewis)
Date: Fri, 11 Oct 2013 14:19:36 -0400 (EDT)
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <8602FB8D-212C-4218-91E2-7BDAB2F62C9C@puck.nether.net>
References: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
 <8602FB8D-212C-4218-91E2-7BDAB2F62C9C@puck.nether.net>
Message-ID: <Pine.LNX.4.61.1310111412410.17328@soloth.lewis.org>

On Fri, 11 Oct 2013, Jared Mauch wrote:

> I think this all depends on how it's configured, and if you can monitor/detect failures.
>
> I've seen folks do things like this with a Linux box with "multiple 
> routing tables".  If you have something validate the link is working, 
> you can easily have it "fail over".  This is all depending on the admin 
> to do it right.

I've done exactly this with Linux routers doing SNAT and multiple upstream 
connections (ip route and ip rule are the commands used to setup the 
"multiple tables" and rules to determine routing policy).  Depending on 
the level of segregation needed, adding a new "user" can be as simple as 
plugging them into the appropriate network.

Is it ideal?  No.  But when $ is the deciding factor between a real router 
with real upstream connections supporting BGP and a Linux router with DSL 
and cable and no routing protocol, policy routing with some intelligence 
to fail-over if a link fails (and go back when it recovers) can work 
acceptably.

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


From freimer at freimer.org  Fri Oct 11 18:26:11 2013
From: freimer at freimer.org (Fred Reimer)
Date: Fri, 11 Oct 2013 18:26:11 +0000
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <20131011.191357.239591912.wwaites@tardis.ed.ac.uk>
Message-ID: <CE7DBADD.2FBE9%freimer@freimer.org>

Most if not all IGPs can be configured to work without multicast.  Now if
you're talking IPv6 you may have some issues?


On 10/11/13 2:13 PM, "William Waites" <wwaites at tardis.ed.ac.uk> wrote:

>On Fri, 11 Oct 2013 10:41:46 -0700, joel jaeggli <joelja at bogus.com> said:
>
>    > you take all the useful information that an IGP could be (or is)
>    > providing you, and then you ignore it and do something else.
>
>Yes, that's another part of the conversation, encouraging the use of
>an IGP, which has been a source of trouble for them because of broken
>wireless bridges from a very commonly used vendor that randomly eat
>multicast packets, so it's not as straightforward as it should be.
>
>    > evil is not a synonym for ugly patch placed over a problem that
>    > could be handled better.
>
>Ok, fair enough. My first experience with PBR was as a summer intern in
>the mid-1990s who inherited management of a large ATM network that had
>a big VPN-esque thing built entirely that way and with no
>documentation. It certainly felt evil at the time. ;)
>
>-w
>
>--
>The University of Edinburgh is a charitable body, registered in
>Scotland, with registration number SC005336.



From jra at baylink.com  Fri Oct 11 18:33:14 2013
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 11 Oct 2013 14:33:14 -0400 (EDT)
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <EF0576F1-FAB9-4634-AE64-8AC3FDCC2DD4@bogus.com>
Message-ID: <11147102.1237.1381516394361.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "joel jaeggli" <joelja at bogus.com>
> you take all the useful information that an IGP could be (or is)
> providing you, and then you ignore it and do something else.

Well, I tell you what. 

My perception of where this was a good idea is the use case a recent 
client might have for it:

Two consumer-grade uplinks (FiOS 150 and RR 100, specifically); primary
application is callcenter, VoIP to a service provider Elsewhere.

I would set it up so that all the VoIP and callcenter web traffic went over
FiOS *until it failed*, and everything else went Road Runner *unless it
failed*. 

This keeps the general traffic out of the hair of the latency/PPS sensitive
traffic whenever possible.

Is that not policy-based routing?

Why is it bad?

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 morrowc.lists at gmail.com  Fri Oct 11 18:35:21 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 11 Oct 2013 14:35:21 -0400
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <20131011.191357.239591912.wwaites@tardis.ed.ac.uk>
References: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
 <EF0576F1-FAB9-4634-AE64-8AC3FDCC2DD4@bogus.com>
 <20131011.191357.239591912.wwaites@tardis.ed.ac.uk>
Message-ID: <CAL9jLaaxyshzQ61Yg-CD5ca3AHsC60C8T6w0004i78nrmRntQg@mail.gmail.com>

On Fri, Oct 11, 2013 at 2:13 PM, William Waites <wwaites at tardis.ed.ac.uk> wrote:
> On Fri, 11 Oct 2013 10:41:46 -0700, joel jaeggli <joelja at bogus.com> said:
>     > evil is not a synonym for ugly patch placed over a problem that
>     > could be handled better.
>
> Ok, fair enough. My first experience with PBR was as a summer intern in
> the mid-1990s who inherited management of a large ATM network that had
> a big VPN-esque thing built entirely that way and with no
> documentation. It certainly felt evil at the time. ;)

I think really PBR violates this:
  <http://en.wikipedia.org/wiki/Principle_of_least_astonishment>

I see ISP folks MOSTLY avoid PBR, because it does weird things that
NOC/ops folks just plain don't expect. I see Enterprise network folks
fall back to PBR often, for reasons that they seem happy with... but
man it makes things confusing :)

-chris


From cscora at apnic.net  Fri Oct 11 18:38:02 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 12 Oct 2013 04:38:02 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201310111838.r9BIc2od021127@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 12 Oct, 2013

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

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

BGP routing table entries examined:                              469227
    Prefixes after maximum aggregation:                          189103
    Deaggregation factor:                                          2.48
    Unique aggregates announced to Internet:                     232899
Total ASes present in the Internet Routing Table:                 45163
    Prefixes per ASN:                                             10.39
Origin-only ASes present in the Internet Routing Table:           35242
Origin ASes announcing only one prefix:                           16260
Transit ASes present in the Internet Routing Table:                5915
Transit-only ASes present in the Internet Routing Table:            160
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      35
    Max AS path prepend of ASN ( 59482)                              25
Prefixes from unregistered ASNs in the Routing Table:               303
    Unregistered ASNs in the Routing Table:                         171
Number of 32-bit ASNs allocated by the RIRs:                       5177
Number of 32-bit ASNs visible in the Routing Table:                4006
Prefixes from 32-bit ASNs in the Routing Table:                   12413
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            714
Number of addresses announced to Internet:                   2648115732
    Equivalent to 157 /8s, 215 /16s and 10 /24s
    Percentage of available address space announced:               71.5
    Percentage of allocated address space announced:               71.5
    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:      164200

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

Prefixes being announced by APNIC Region ASes:                   111390
    Total APNIC prefixes after maximum aggregation:               33839
    APNIC Deaggregation factor:                                    3.29
Prefixes being announced from the APNIC address blocks:          113461
    Unique aggregates announced from the APNIC address blocks:    46844
APNIC Region origin ASes present in the Internet Routing Table:    4875
    APNIC Prefixes per ASN:                                       23.27
APNIC Region origin ASes announcing only one prefix:               1222
APNIC Region transit ASes present in the Internet Routing Table:    830
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         28
Number of APNIC region 32-bit ASNs visible in the Routing Table:    710
Number of APNIC addresses announced to Internet:              728465152
    Equivalent to 43 /8s, 107 /16s and 127 /24s
    Percentage of available APNIC address space announced:         85.1

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:                    163008
    Total ARIN prefixes after maximum aggregation:                81421
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           163510
    Unique aggregates announced from the ARIN address blocks:     76000
ARIN Region origin ASes present in the Internet Routing Table:    15898
    ARIN Prefixes per ASN:                                        10.28
ARIN Region origin ASes announcing only one prefix:                6018
ARIN Region transit ASes present in the Internet Routing Table:    1657
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:      25
Number of ARIN addresses announced to Internet:              1072988416
    Equivalent to 63 /8s, 244 /16s and 129 /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:                    118750
    Total RIPE prefixes after maximum aggregation:                61299
    RIPE Deaggregation factor:                                     1.94
Prefixes being announced from the RIPE address blocks:           122330
    Unique aggregates announced from the RIPE address blocks:     78977
RIPE Region origin ASes present in the Internet Routing Table:    17464
    RIPE Prefixes per ASN:                                         7.00
RIPE Region origin ASes announcing only one prefix:                8262
RIPE Region transit ASes present in the Internet Routing Table:    2819
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:    2410
Number of RIPE addresses announced to Internet:               656522980
    Equivalent to 39 /8s, 33 /16s and 190 /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:                   51889
    Total LACNIC prefixes after maximum aggregation:               9928
    LACNIC Deaggregation factor:                                   5.23
Prefixes being announced from the LACNIC address blocks:          56947
    Unique aggregates announced from the LACNIC address blocks:   26506
LACNIC Region origin ASes present in the Internet Routing Table:   2037
    LACNIC Prefixes per ASN:                                      27.96
LACNIC Region origin ASes announcing only one prefix:               569
LACNIC Region transit ASes present in the Internet Routing Table:   384
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:   855
Number of LACNIC addresses announced to Internet:             140359472
    Equivalent to 8 /8s, 93 /16s and 183 /24s
    Percentage of available LACNIC address space announced:        83.7

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:                  11617
    Total AfriNIC prefixes after maximum aggregation:              2519
    AfriNIC Deaggregation factor:                                  4.61
Prefixes being announced from the AfriNIC address blocks:         12265
    Unique aggregates announced from the AfriNIC address blocks:   3972
AfriNIC Region origin ASes present in the Internet Routing Table:   650
    AfriNIC Prefixes per ASN:                                     18.87
AfriNIC Region origin ASes announcing only one prefix:              189
AfriNIC Region transit ASes present in the Internet Routing Table:  133
Average AfriNIC Region AS path length visible:                      4.8
    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:             47752704
    Equivalent to 2 /8s, 216 /16s and 166 /24s
    Percentage of available AfriNIC address space announced:       47.4

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2944      11563         946   Korea Telecom (KIX)
17974     2714        903          90   PT TELEKOMUNIKASI INDONESIA
 7545     2089        321         112   TPG Internet Pty Ltd
 4755     1779        391         187   TATA Communications formerly 
 9829     1556       1241          43   BSNL National Internet Backbo
 9583     1238         93         508   Sify Limited
 9498     1202        309          74   BHARTI Airtel Ltd.
 4808     1191       2131         347   CNCGROUP IP network: China169
 7552     1160       1080          13   Vietel Corporation
24560     1091        380         164   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     3060       3689          59   BellSouth.net Inc.
22773     2168       2943         140   Cox Communications, Inc.
18566     2066        382         184   Covad Communications 
 1785     2020        679         126   PaeTec Communications, Inc.
20115     1678       1651         615   Charter Communications 
 4323     1623       1104         422   Time Warner Telecom
  701     1517      11148         790   UUNET Technologies, Inc. 
30036     1383        310         574   Mediacom Communications Corp 
 7018     1332      17514         858   AT&T WorldNet Services
 6983     1294        771         579   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     1841        544          17   OJSC "Vimpelcom"
34984     1363        244         220   TELLCOM ILETISIM HIZMETLERI A
20940     1056        389         812   Akamai Technologies European 
31148      991         44          19   FreeNet ISP
 6830      895       2366         428   UPC Distribution Services
13188      874         99          62   TOV "Bank-Inform"
 8551      754        370          41   Bezeq International
12479      688        799          49   Uni2 Autonomous System
35228      541        246          16   Avatar Broadband Limited
34744      516        157          53   SC GVM SISTEM 2003 SRL

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       1752          90   NET Servicos de Comunicao S.A
10620     2602        423         249   TVCABLE BOGOTA 
 7303     1724       1135         233   Telecom Argentina Stet-France
18881     1462        844          20   Global Village Telecom 
 8151     1342       2815         415   UniNet S.A. de C.V. 
11830      865        364          15   Instituto Costarricense de El
27947      837         93          90   Telconet S.A
 6147      801        373          27   Telefonica Del Peru 
 6503      796        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      881        274          29   LINKdotNET AS number
 6713      554        633          26   Itissalat Al-MAGHRIB
 8452      426        956           9   TEDATA
24835      292         80           8   RAYA Telecom - Egypt
 3741      258        921         216   The Internet Solution 
29571      223         17          11   Ci Telecom Autonomous system 
36992      222        501          28   Etisalat MISR
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       1752          90   NET Servicos de Comunicao S.A
 6389     3060       3689          59   BellSouth.net Inc.
 4766     2944      11563         946   Korea Telecom (KIX)
17974     2714        903          90   PT TELEKOMUNIKASI INDONESIA
10620     2602        423         249   TVCABLE BOGOTA 
22773     2168       2943         140   Cox Communications, Inc.
 7545     2089        321         112   TPG Internet Pty Ltd
18566     2066        382         184   Covad Communications 
 1785     2020        679         126   PaeTec Communications, Inc.
36998     1864        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      3060        3001      BellSouth.net Inc.
17974      2714        2624      PT TELEKOMUNIKASI INDONESIA
10620      2602        2353      TVCABLE BOGOTA 
22773      2168        2028      Cox Communications, Inc.
 4766      2944        1998      Korea Telecom (KIX)
 7545      2089        1977      TPG Internet Pty Ltd
 1785      2020        1894      PaeTec Communications, Inc.
18566      2066        1882      Covad Communications 
36998      1864        1859      Sudanese Mobile Telephone (ZA
 8402      1841        1824      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 
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
30031   UNALLOCATED  12.27.122.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 
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
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.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/22       36493     3757277 Canada Inc. (oa 295.c
23.91.160.0/19       36493     3757277 Canada Inc. (oa 295.c
23.91.164.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:251     
/13:481     /14:916     /15:1627    /16:12822   /17:6702    /18:11233   
/19:22994   /20:32626   /21:35338   /22:49901   /23:43037   /24:248599  
/25:899     /26:995     /27:497     /28:48      /29:78      /30:19      
/31:0       /32:14      

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

  ASN   No of nets  Total ann.   Description
18566     2017          2066      Covad Communications 
36998     1829          1864      Sudanese Mobile Telephone (ZA
 6389     1709          3060      BellSouth.net Inc.
 8402     1534          1841      OJSC "Vimpelcom"
22773     1439          2168      Cox Communications, Inc.
30036     1239          1383      Mediacom Communications Corp 
11492     1192          1233      Cable One 
 1785     1084          2020      PaeTec Communications, Inc.
 6983     1034          1294      ITC^Deltacom 
22561      966          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:841       2:814       3:3         4:17        5:992       6:19     
   8:614      12:1893     13:3        14:876      15:11       16:3      
  17:16       18:19       20:21       23:465      24:1720     27:1602   
  31:1466     32:45       33:2        34:5        36:81       37:1816   
  38:911      39:3        40:181      41:3224     42:249      44:14     
  46:2024     47:6        49:686      50:835      52:12       54:39     
  55:3        56:2        57:26       58:1166     59:606      60:358    
  61:1430     62:1187     63:1980     64:4554     65:2349     66:4174   
  67:2117     68:1099     69:3294     70:872      71:497      72:2025   
  74:2568     75:326      76:307      77:1166     78:1090     79:650    
  80:1329     81:1020     82:625      83:588      84:597      85:1195   
  86:453      87:1023     88:555      89:1736     90:155      91:5634   
  92:607      93:1608     94:2035     95:1627     96:518      97:342    
  98:1047     99:43      100:31      101:613     103:3400    105:522    
 106:143     107:211     108:511     109:1900    110:971     111:1132   
 112:581     113:793     114:741     115:1014    116:993     117:827    
 118:1172    119:1293    120:382     121:747     122:1880    123:1224   
 124:1380    125:1426    128:646     129:236     130:324     131:670    
 132:348     133:158     134:547     135:67      136:276     137:240    
 138:348     139:180     140:196     141:313     142:545     143:409    
 144:499     145:96      146:516     147:402     148:708     149:352    
 150:156     151:614     152:407     153:201     154:47      155:486    
 156:284     157:423     158:284     159:773     160:350     161:455    
 162:769     163:227     164:634     165:570     166:258     167:622    
 168:1047    169:127     170:1088    171:202     172:25      173:1624   
 174:672     175:509     176:1235    177:2351    178:1921    179:191    
 180:1567    181:754     182:1352    183:482     184:653     185:933    
 186:2586    187:1471    188:1888    189:1311    190:7177    192:7060   
 193:5421    194:4031    195:3320    196:1323    197:1002    198:4728   
 199:5470    200:6091    201:2522    202:8971    203:8899    204:4518   
 205:2624    206:2847    207:2918    208:4005    209:3636    210:2948   
 211:1572    212:2202    213:2018    214:906     215:99      216:5366   
 217:1687    218:621     219:315     220:1280    221:566     222:326    
 223:507    

End of report


From freimer at freimer.org  Fri Oct 11 18:41:20 2013
From: freimer at freimer.org (Fred Reimer)
Date: Fri, 11 Oct 2013 18:41:20 +0000
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <11147102.1237.1381516394361.JavaMail.root@benjamin.baylink.com>
Message-ID: <CE7DBDF7.2FBEF%freimer@freimer.org>

I think they are referring to something like Cisco PBR, where you
configure routing policy statically on each hop.  Yes, it can be
configured to fail over, etc, but inherently it is a management nightmare
if you are configuring PBR on each device in your network.  May as well
move back to static routing on everything?

Used sparingly, I'd agree that it does have its uses.  One use I can think
of is to use PBR to direct traffic for testing a new circuit or path while
not cutting everything over.  That is, until it is sufficiently tested,
and then everything would be cut over and the PBR removed?


On 10/11/13 2:33 PM, "Jay Ashworth" <jra at baylink.com> wrote:

>----- Original Message -----
>> From: "joel jaeggli" <joelja at bogus.com>
>> you take all the useful information that an IGP could be (or is)
>> providing you, and then you ignore it and do something else.
>
>Well, I tell you what.
>
>My perception of where this was a good idea is the use case a recent
>client might have for it:
>
>Two consumer-grade uplinks (FiOS 150 and RR 100, specifically); primary
>application is callcenter, VoIP to a service provider Elsewhere.
>
>I would set it up so that all the VoIP and callcenter web traffic went
>over
>FiOS *until it failed*, and everything else went Road Runner *unless it
>failed*. 
>
>This keeps the general traffic out of the hair of the latency/PPS
>sensitive
>traffic whenever possible.
>
>Is that not policy-based routing?
>
>Why is it bad?
>
>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 vyto at fnal.gov  Fri Oct 11 18:47:08 2013
From: vyto at fnal.gov (Vytautas V Grigaliunas)
Date: Fri, 11 Oct 2013 18:47:08 +0000
Subject: NANOG Digest, Vol 69, Issue 28
In-Reply-To: <mailman.920.1381515248.1246.nanog@nanog.org>
References: <mailman.920.1381515248.1246.nanog@nanog.org>
Message-ID: <ED6DC2C1A6D8774D8CB616278360334C03688D0A@MAIL01.fnal.gov>

What is SDN at its essence ?



> Message: 9
> Date: Fri, 11 Oct 2013 19:13:57 +0100 (BST)
> From: William Waites <wwaites at tardis.ed.ac.uk>
> To: joelja at bogus.com
> Cc: nanog at nanog.org
> Subject: Re: Policy-based routing is evil? Discuss.
> Message-ID: <20131011.191357.239591912.wwaites at tardis.ed.ac.uk>
> Content-Type: text/plain; charset="us-ascii"
> 
> On Fri, 11 Oct 2013 10:41:46 -0700, joel jaeggli <joelja at bogus.com> said:
> 
>     > you take all the useful information that an IGP could be (or is)
>     > providing you, and then you ignore it and do something else.
> 
> Yes, that's another part of the conversation, encouraging the use of an IGP,
> which has been a source of trouble for them because of broken wireless bridges
> from a very commonly used vendor that randomly eat multicast packets, so it's
> not as straightforward as it should be.
> 
>     > evil is not a synonym for ugly patch placed over a problem that
>     > could be handled better.
> 
> Ok, fair enough. My first experience with PBR was as a summer intern in the
> mid-1990s who inherited management of a large ATM network that had a big
> VPN-esque thing built entirely that way and with no documentation. It certainly
> felt evil at the time. ;)
> 
> -w
> 
> --
> The University of Edinburgh is a charitable body, registered in Scotland, with
> registration number SC005336.


From freimer at freimer.org  Fri Oct 11 18:55:01 2013
From: freimer at freimer.org (Fred Reimer)
Date: Fri, 11 Oct 2013 18:55:01 +0000
Subject: NANOG Digest, Vol 69, Issue 28
In-Reply-To: <ED6DC2C1A6D8774D8CB616278360334C03688D0A@MAIL01.fnal.gov>
Message-ID: <CE7DC198.2FC0A%freimer@freimer.org>

Centralized management / control plane.  Kind of the reverse of widely
dispersed per-node policy based routing.


On 10/11/13 2:47 PM, "Vytautas V Grigaliunas" <vyto at fnal.gov> wrote:

>What is SDN at its essence ?
>
>
>
>> Message: 9
>> Date: Fri, 11 Oct 2013 19:13:57 +0100 (BST)
>> From: William Waites <wwaites at tardis.ed.ac.uk>
>> To: joelja at bogus.com
>> Cc: nanog at nanog.org
>> Subject: Re: Policy-based routing is evil? Discuss.
>> Message-ID: <20131011.191357.239591912.wwaites at tardis.ed.ac.uk>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> On Fri, 11 Oct 2013 10:41:46 -0700, joel jaeggli <joelja at bogus.com>
>>said:
>> 
>>     > you take all the useful information that an IGP could be (or is)
>>     > providing you, and then you ignore it and do something else.
>> 
>> Yes, that's another part of the conversation, encouraging the use of an
>>IGP,
>> which has been a source of trouble for them because of broken wireless
>>bridges
>> from a very commonly used vendor that randomly eat multicast packets,
>>so it's
>> not as straightforward as it should be.
>> 
>>     > evil is not a synonym for ugly patch placed over a problem that
>>     > could be handled better.
>> 
>> Ok, fair enough. My first experience with PBR was as a summer intern in
>>the
>> mid-1990s who inherited management of a large ATM network that had a big
>> VPN-esque thing built entirely that way and with no documentation. It
>>certainly
>> felt evil at the time. ;)
>> 
>> -w
>> 
>> --
>> The University of Edinburgh is a charitable body, registered in
>>Scotland, with
>> registration number SC005336.
>



From scott at doc.net.au  Fri Oct 11 19:45:20 2013
From: scott at doc.net.au (Scott Howard)
Date: Fri, 11 Oct 2013 12:45:20 -0700
Subject: To CCIEs and JNCIEs
In-Reply-To: <m2hacoxo57.wl%randy@psg.com>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
 <m2hacoxo57.wl%randy@psg.com>
Message-ID: <CACnPsNUcQ3tQF50GZ-_B9skUSPypjKyvw9kBnHvmXTbn=wYeiQ@mail.gmail.com>

On Fri, Oct 11, 2013 at 12:28 AM, Randy Bush <randy at psg.com> wrote:

> but who would want to deal with such slime?
>

I dunno, it looks pretty legit to me!!

Domain Name.......... theccie.com
  Creation Date........ 2013-09-28
  Registration Date.... 2013-09-28
  Expiry Date.......... 2014-09-28

  Organisation Name.... the ccie
  Organisation Address. later
  Organisation Address.
  Organisation Address.
  Organisation Address. singapore
  Organisation Address. 100850
  Organisation Address. singapore
  Organisation Address. SINGAPORE


  Scott

From gparent at gparent.org  Fri Oct 11 20:04:12 2013
From: gparent at gparent.org (Guillaume Parent)
Date: Fri, 11 Oct 2013 16:04:12 -0400
Subject: To CCIEs and JNCIEs
In-Reply-To: <CACT83am7Mg+jEYs_T=NBVqwjSvrhGZ5yqCSr6urfyL_7MbMzcQ@mail.gmail.com>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
 <m2hacoxo57.wl%randy@psg.com>
 <CACnPsNUcQ3tQF50GZ-_B9skUSPypjKyvw9kBnHvmXTbn=wYeiQ@mail.gmail.com>
 <CACT83am7Mg+jEYs_T=NBVqwjSvrhGZ5yqCSr6urfyL_7MbMzcQ@mail.gmail.com>
Message-ID: <CACT83a=CFEqZ5YWiQ=NaAtaX1unqb7mBFfsvpNrJcnG9+vwP5w@mail.gmail.com>

Hey,

No offense but this could potentially look like a phishing expedition to
some people. I'm saying this regardless of whether you are legit or not, I
did not do much research and am only giving you my honest impression.

Just saying, anyone could purchase a domain name and say they want to
provide email as a gift, then scan through that email all day.

Perhaps you're not trying to target people with certifications who may
receive corporate email while they are in a high level position in official
capacity, for everyone's sake.

But really, I don't have a CCIE ;) If you ever purchase
CCNAAndStillGotAGreatJob.com, let me know. Make my username
ThrewAwayMyMoneyOnly.


On Fri, Oct 11, 2013 at 4:03 PM, Guillaume Parent <gparent at gparent.org>wrote:

> Hey,
>
> No offense but this could potentially look like a phishing expedition to
> some people. I'm saying this regardless of whether you are legit or not, I
> did not do much research and am only giving you my honest impression.
>
> Just saying, anyone could purchase a domain name and say they want to
> provide email as a gift, then scan through that email all day.
>
> Perhaps you're not trying to target people with certifications who may
> receive corporate email while they are in a high level position in official
> capacity, for everyone's sake.
>
> But really, I don't have a CCIE ;) If you ever purchase
> CCNAAndStillGotAGreatJob.com, let me know. Make my username
> ThrewAwayMyMoneyOnly.
>
> -Guillaume
>
>
> On Fri, Oct 11, 2013 at 3:45 PM, Scott Howard <scott at doc.net.au> wrote:
>
>> On Fri, Oct 11, 2013 at 12:28 AM, Randy Bush <randy at psg.com> wrote:
>>
>> > but who would want to deal with such slime?
>> >
>>
>> I dunno, it looks pretty legit to me!!
>>
>> Domain Name.......... theccie.com
>>   Creation Date........ 2013-09-28
>>   Registration Date.... 2013-09-28
>>   Expiry Date.......... 2014-09-28
>>
>>   Organisation Name.... the ccie
>>   Organisation Address. later
>>   Organisation Address.
>>   Organisation Address.
>>   Organisation Address. singapore
>>   Organisation Address. 100850
>>   Organisation Address. singapore
>>   Organisation Address. SINGAPORE
>>
>>
>>   Scott
>>
>
>

From bicknell at ufp.org  Fri Oct 11 20:27:58 2013
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 11 Oct 2013 15:27:58 -0500
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: <705FCAD4-0317-49A7-A9B7-A5DD151A3B41@ufp.org>


On Oct 11, 2013, at 12: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.

Doing this with actual routing, in a way that doesn't become fragile is
hard.  It is not impossible as Jared points out, but is non-trivial.

However there is a variant which is much less brittle, but is more
annoying to configure with most tools.  The idea is that the gateway
box is a NAT, with an outbound IP on each of the two uplinks.  The 
box can then make intelligent decisions about which provider to use
based on layer 8+9 information.

I've seen this done multiple times where for instance there is high
bandwidth satellite, and low bandwidth terrestrial services.  Latency
sensitive traffic (dns, ssh, etc) are send over the low bandwidth
terrestrial, while bulk downloads go over satellite.  It's quite
robust and useful in these situations.

Making open source boxes do this is possible, but quite annoying
in my experience.  I don't think it's possible to make a Cisco or
Juniper do this sort of thing in any reasonable way.  A number of
manufacturers have developed custom solutions around this idea.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/





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

From rgolodner at infratection.com  Fri Oct 11 20:51:41 2013
From: rgolodner at infratection.com (Richard Golodner)
Date: Fri, 11 Oct 2013 15:51:41 -0500
Subject: To CCIEs and JNCIEs
In-Reply-To: <CACnPsNUcQ3tQF50GZ-_B9skUSPypjKyvw9kBnHvmXTbn=wYeiQ@mail.gmail.com>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
 <m2hacoxo57.wl%randy@psg.com>
 <CACnPsNUcQ3tQF50GZ-_B9skUSPypjKyvw9kBnHvmXTbn=wYeiQ@mail.gmail.com>
Message-ID: <1381524701.2150.12.camel@Andromeda>

On Fri, 2013-10-11 at 12:45 -0700, Scott Howard wrote:
> I dunno, it looks pretty legit to me!!
> 
> Domain Name.......... theccie.com
>   Creation Date........ 2013-09-28
>   Registration Date.... 2013-09-28
>   Expiry Date.......... 2014-09-28
> 
>   Organisation Name.... the ccie
>   Organisation Address. later
>   Organisation Address.
>   Organisation Address.
>   Organisation Address. singapore
>   Organisation Address. 100850
>   Organisation Address. singapore
>   Organisation Address. SINGAPORE 

	With a business address of "later" and no other traceable info I would
be wary.
	Like in Scarface, perhaps I am just paranoid. 
	My paranoia has worked for me though.
	Richard




From stu at actusa.net  Fri Oct 11 18:45:10 2013
From: stu at actusa.net (Stuart Sheldon)
Date: Fri, 11 Oct 2013 11:45:10 -0700
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <CAL9jLaaxyshzQ61Yg-CD5ca3AHsC60C8T6w0004i78nrmRntQg@mail.gmail.com>
References: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
 <EF0576F1-FAB9-4634-AE64-8AC3FDCC2DD4@bogus.com>
 <20131011.191357.239591912.wwaites@tardis.ed.ac.uk>
 <CAL9jLaaxyshzQ61Yg-CD5ca3AHsC60C8T6w0004i78nrmRntQg@mail.gmail.com>
Message-ID: <52584736.5030900@actusa.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

We use Linux for our edge routers which have multiple interfaces to
different BGP peers. Policy based routing allows us to insure that
traffic originating from a particular external IP address on the router,
goes out the matching network.

We have also used in on client systems to force particular protocols out
particular providers.

It's not that easy to do on Linux, as you need to make sure you have all
the proper link routes on place and positioned properly in the rule
chain, or you can really break things.

Stu


On 10/11/2013 11:35 AM, Christopher Morrow wrote:
> On Fri, Oct 11, 2013 at 2:13 PM, William Waites <wwaites at tardis.ed.ac.uk> wrote:
>> On Fri, 11 Oct 2013 10:41:46 -0700, joel jaeggli <joelja at bogus.com> said:
>>     > evil is not a synonym for ugly patch placed over a problem that
>>     > could be handled better.
>>
>> Ok, fair enough. My first experience with PBR was as a summer intern in
>> the mid-1990s who inherited management of a large ATM network that had
>> a big VPN-esque thing built entirely that way and with no
>> documentation. It certainly felt evil at the time. ;)
> 
> I think really PBR violates this:
>   <http://en.wikipedia.org/wiki/Principle_of_least_astonishment>
> 
> I see ISP folks MOSTLY avoid PBR, because it does weird things that
> NOC/ops folks just plain don't expect. I see Enterprise network folks
> fall back to PBR often, for reasons that they seem happy with... but
> man it makes things confusing :)
> 
> -chris
> 

- -- 
"Sometimes I lie awake at night and I ask, "Is life a multiple choice test
or is it a true or false test?" ...Then a voice comes to me out of the
dark and says, "We hate to tell you this but life is a thousand word essay."
              -- Charles M. Schulz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJSWEc2AAoJEFKVLITDJSGSDSAP/iW6s1nM56cwAyQAq8djsn3x
OlD40O698iluf9r1ZmDABZqO3dWI/JxGktANmhC34b/ux9qMKx27RBEVS+L5Kp9p
f5YJxG0vr0lkqhVGngr9pOKTmOLdnLWwDiL0yUyxXngYm7ZG9E5aQ5mbLSz0DxBB
+JGoc4DXzI1lNXMSfklxooAZoRP6dbwxhzC8r/TIbExFyRuf/OgsR9bYB3wjpRvQ
7uXdHiLmLIO68pvRmGIIYQUNQ/aUSI9wod2jdleupK6yoO7fAktrndhj1+lD0TCS
kZA5/b2u5O+PJ61ocbK20s/mKVt/joVSfEG5IBQxqxKqpcc9N1x7Kr7XzoQuUFo/
M3szoDZnwIq5zgXWDvvt11+AzG5qraZCxfwaTpwHbuRAC9bZMIZkrpd4LLXTGwvG
bxuJmWqcY2ktX5XiyLRgvcYzw+Pkz6uNU+PpS9UYI7x9qSwkYGPomoj5iHbaTrs4
nKBQZgAUUcEkr7+kRfXIhq6ZZKsaoaFGCX8u5WeXBQj78GlEiOMxAthFPYr8iU8X
Kai4nCBx+c204hjoYdI5K2aFNztqh8Xj2qW3DyxrqwsKld46ZFut/zKs4qcJLvPP
jrs2ihtdsIHDn2QLVoRqHJWdpMn2l/TETbygqnRyO9hYUkqub7Zo/fVJwXCGNZDz
quDOESz/QwPH5IrOPiub
=ww8J
-----END PGP SIGNATURE-----


From cidr-report at potaroo.net  Fri Oct 11 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 11 Oct 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201310112200.r9BM002f056144@wattle.apnic.net>

This report has been generated at Fri Oct 11 21:15:04 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
        04-10-13    479970      272927
        05-10-13    480730      273310
        06-10-13    480899      273239
        07-10-13    480964      272845
        08-10-13    480570      273225
        09-10-13    481248      273313
        10-10-13    481423      273608
        11-10-13    481980      273866


AS Summary
         45317  Number of ASes in routing system
         18603  Number of ASes announcing only one prefix
          4182  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      118190016  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').

 --- 11Oct13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     481513   273799   207714    43.1%   All ASes

AS6389      3060       62     2998    98.0%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS17974     2713      106     2607    96.1%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS28573     3395      939     2456    72.3%   NET Servi?os de Comunica??o
                                               S.A.
AS7029      4182     1860     2322    55.5%   WINDSTREAM - Windstream
                                               Communications Inc
AS4766      2944      954     1990    67.6%   KIXS-AS-KR Korea Telecom
AS18566     2066      572     1494    72.3%   MEGAPATH5-US - MegaPath
                                               Corporation
AS36998     1864      375     1489    79.9%   SDN-MOBITEL
AS4323      2966     1548     1418    47.8%   TWTC - tw telecom holdings,
                                               inc.
AS7303      1724      466     1258    73.0%   Telecom Argentina S.A.
AS1785      2020      811     1209    59.9%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1779      580     1199    67.4%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS10620     2602     1413     1189    45.7%   Telmex Colombia S.A.
AS7552      1193      140     1053    88.3%   VIETEL-AS-AP Vietel
                                               Corporation
AS22561     1241      216     1025    82.6%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS18881     1462      481      981    67.1%   Global Village Telecom
AS22773     2172     1304      868    40.0%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS7545      2091     1238      853    40.8%   TPG-INTERNET-AP TPG Telecom
                                               Limited
AS35908      904       87      817    90.4%   VPLSNET - Krypt Technologies
AS18101      981      180      801    81.7%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4808      1191      403      788    66.2%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS11830      866      118      748    86.4%   Instituto Costarricense de
                                               Electricidad y Telecom.
AS8402      1808     1073      735    40.7%   CORBINA-AS OJSC "Vimpelcom"
AS701       1518      794      724    47.7%   UUNET - MCI Communications
                                               Services, Inc. d/b/a Verizon
                                               Business
AS24560     1091      375      716    65.6%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS6983      1294      585      709    54.8%   ITCDELTA - ITC^Deltacom
AS8151      1344      636      708    52.7%   Uninet S.A. de C.V.
AS13977      852      145      707    83.0%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS6147       801      108      693    86.5%   Telefonica del Peru S.A.A.
AS855        733       55      678    92.5%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS7738       780      139      641    82.2%   Telemar Norte Leste S.A.

Total      53637    17763    35874    66.9%   Top 30 total


Possible Bogus Routes

        23.92.128.0/17       AS42981 RES-PL RES.PL ISP S.C.
        23.92.224.0/23       AS55048 VMWARE - VMware, Inc.
        23.92.226.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 
        31.13.184.0/21       AS42981 RES-PL RES.PL ISP S.C.
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.182.96.0/23       AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED
        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.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.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.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.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
        69.12.0.0/17         AS23504 MEGAPATH9-US - MegaPath Corporation
        69.12.0.0/19         AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        69.12.44.0/24        AS18566 MEGAPATH5-US - MegaPath Corporation
        69.12.48.0/21        AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        69.12.64.0/20        AS18566 MEGAPATH5-US - MegaPath Corporation
        69.12.80.0/20        AS18566 MEGAPATH5-US - MegaPath Corporation
        69.12.96.0/22        AS18566 MEGAPATH5-US - MegaPath Corporation
        69.12.104.0/22       AS23504 MEGAPATH9-US - MegaPath Corporation
        69.12.108.0/24       AS18566 MEGAPATH5-US - MegaPath Corporation
        69.12.109.0/24       AS18566 MEGAPATH5-US - MegaPath Corporation
        69.12.110.0/23       AS18566 MEGAPATH5-US - MegaPath Corporation
        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.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        82.103.0.0/18        AS30901 
        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.199.250.0/24      AS5617  TPNET Telekomunikacja Polska S.A.
        91.200.188.0/22      AS44016 
        91.205.188.0/22      AS47983 
        91.207.152.0/24      AS64100 
        91.207.153.0/24      AS64100 
        91.207.178.0/23      AS48274 
        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. 
        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
        120.136.17.0/24      AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika
        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
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        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.
        185.37.136.0/22      AS49220 AIRIT-AS AirIT Services AG
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA LTDA
        190.15.72.0/21       AS15146 CABLEBAHAMAS - Cable Bahamas
        190.120.224.0/20     AS26272 FT-ASN-1001 - FortaTrust USA Corporation
        190.120.224.0/23     AS26272 FT-ASN-1001 - FortaTrust USA Corporation
        190.120.226.0/23     AS26272 FT-ASN-1001 - FortaTrust USA Corporation
        190.120.228.0/22     AS26272 FT-ASN-1001 - FortaTrust USA Corporation
        190.120.232.0/21     AS26272 FT-ASN-1001 - FortaTrust USA Corporation
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        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.111.125.0/24     AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget
        193.111.155.0/24     AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget
        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 
        194.169.237.0/24     AS12968 CDP Netia SA
        195.114.4.0/23       AS41158 
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA
        195.234.156.0/24     AS25028 
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.10.235.0/24      AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich
        200.10.239.0/24      AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich
        200.35.144.0/21      AS26272 FT-ASN-1001 - FortaTrust USA Corporation
        200.35.144.0/24      AS26272 FT-ASN-1001 - FortaTrust USA Corporation
        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.52.47.0/24       AS55560 
        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.84.16.0/24       AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.84.17.0/24       AS17781 XINHUA Xinhua News Agency
        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.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.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.225.0/24      AS3549  GBLX Global Crossing Ltd.
        208.66.227.0/24      AS3549  GBLX Global Crossing Ltd.
        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.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
        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.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        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 
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.146.0.0/19       AS1915  SEQUOIA-AS - National Science Foundation
        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 Oct 11 22:00:01 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 11 Oct 2013 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201310112200.r9BM01nU056161@wattle.apnic.net>

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

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS36998           62516  3.0%      48.1 -- SDN-MOBITEL
 2 - AS9829            40360  1.9%      23.7 -- BSNL-NIB National Internet Backbone
 3 - AS8402            37741  1.8%      52.3 -- CORBINA-AS OJSC "Vimpelcom"
 4 - AS13118           23815  1.1%     506.7 -- ASN-YARTELECOM OJSC Rostelecom
 5 - AS10620           22477  1.1%      12.3 -- Telmex Colombia S.A.
 6 - AS38547           21735  1.0%      58.4 -- WITRIBE-AS-AP WITRIBE PAKISTAN LIMITED
 7 - AS7552            20213  1.0%      16.9 -- VIETEL-AS-AP Vietel Corporation
 8 - AS8163            18688  0.9%      48.2 -- METROTEL REDES S.A.
 9 - AS23966           16397  0.8%      48.8 -- LDN-AS-PK LINKdotNET Telecom Limited
10 - AS4775            16320  0.8%     206.6 -- GLOBE-TELECOM-AS Globe Telecoms
11 - AS55714           14203  0.7%      55.1 -- APNIC-FIBERLINK-PK Fiberlink Pvt.Ltd
12 - AS17974           14092  0.7%       6.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
13 - AS28573           13804  0.7%       8.1 -- NET Servi?os de Comunica??o S.A.
14 - AS3816            12763  0.6%      31.8 -- COLOMBIA TELECOMUNICACIONES S.A. ESP
15 - AS11976           11800  0.6%    5900.0 -- FIDN - Fidelity Communication International Inc.
16 - AS9583            11504  0.6%       9.4 -- SIFY-AS-IN Sify Limited
17 - AS19886           11503  0.6%    1437.9 -- BOFABROKERDEALERSVCS - Bank of America
18 - AS27831           10248  0.5%      57.3 -- Colombia M?vil
19 - AS48612            9627  0.5%     687.6 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
20 - AS20473            9556  0.5%     183.8 -- AS-CHOOPA - Choopa, LLC


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS11976           11800  0.6%    5900.0 -- FIDN - Fidelity Communication International Inc.
 2 - AS19406            4528  0.2%    4528.0 -- TWRS-MA - Towerstream I, Inc.
 3 - AS6174             6865  0.3%    3432.5 -- SPRINTLINK8 - Sprint
 4 - AS37367            3313  0.2%    3313.0 -- CALLKEY
 5 - AS16608            4998  0.2%    2499.0 -- KENTEC - Kentec Communications, Inc.
 6 - AS32528            7184  0.3%    2394.7 -- ABBOTT Abbot Labs
 7 - AS32244            7042  0.3%    1760.5 -- LIQUID-WEB-INC - Liquid Web, Inc.
 8 - AS6                1714  0.1%      25.0 -- HOSTING-SOLUTION - Hosting Solution Ltd.
 9 - AS6629             9182  0.4%    1530.3 -- NOAA-AS - NOAA
10 - AS19886           11503  0.6%    1437.9 -- BOFABROKERDEALERSVCS - Bank of America
11 - AS22592            1117  0.1%    1117.0 -- HBP - HBP, Inc.
12 - AS29052            1061  0.1%    1061.0 -- LYCOS-AS INFORM P. LYKOS A.E
13 - AS22688            1001  0.1%    1001.0 -- DOLGENCORP - Dollar General Corporation
14 - AS32445            1880  0.1%     940.0 -- XHOP - XHOP LLC
15 - AS45808             766  0.0%     766.0 -- UTP-MY Bandar Seri Iskandar
16 - AS23295             703  0.0%     703.0 -- EA-01 - Extend America
17 - AS7202             8414  0.4%     701.2 -- FAMU - Florida A & M University
18 - AS48612            9627  0.5%     687.6 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
19 - AS58761            1166  0.1%     583.0 -- RECHARGEITNOW-AS-IN Online Recharge Services Pvt Ltd
20 - AS47089            1163  0.1%     581.5 -- ROUTEMORE - Route More Solutions, LLC


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 109.161.64.0/20   23323  1.1%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 92.246.207.0/24    9539  0.4%   AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
 3 - 108.61.128.0/18    9177  0.4%   AS20473 -- AS-CHOOPA - Choopa, LLC
 4 - 192.58.232.0/24    9172  0.4%   AS6629  -- NOAA-AS - NOAA
 6 - 120.28.62.0/24     7982  0.4%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
 7 - 67.210.190.0/23    6294  0.3%   AS11976 -- FIDN - Fidelity Communication International Inc.
 8 - 67.210.188.0/23    5506  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
 9 - 202.141.62.0/24    4985  0.2%   AS2697  -- ERX-ERNET-AS Education and Research Network
10 - 202.154.17.0/24    4852  0.2%   AS4434  -- ERX-RADNET1-AS PT Rahajasa Media Internet
11 - 69.38.178.0/24     4528  0.2%   AS19406 -- TWRS-MA - Towerstream I, Inc.
12 - 2.93.235.0/24      4456  0.2%   AS8402  -- CORBINA-AS OJSC "Vimpelcom"
13 - 168.223.200.0/22   4231  0.2%   AS7202  -- FAMU - Florida A & M University
14 - 62.84.76.0/24      4147  0.2%   AS42334 -- BBP-AS Broadband Plus s.a.l.
15 - 168.223.206.0/23   4146  0.2%   AS7202  -- FAMU - Florida A & M University
16 - 115.170.128.0/17   4062  0.2%   AS4847  -- CNIX-AP China Networks Inter-Exchange
17 - 206.105.75.0/24    3435  0.1%   AS6174  -- SPRINTLINK8 - Sprint
18 - 208.16.110.0/24    3430  0.1%   AS6174  -- SPRINTLINK8 - Sprint
19 - 41.75.40.0/21      3313  0.1%   AS37367 -- CALLKEY
20 - 130.36.34.0/24     3082  0.1%   AS32528 -- ABBOTT Abbot Labs

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 mysidia at gmail.com  Fri Oct 11 22:22:54 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 11 Oct 2013 17:22:54 -0500
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: <CAAAwwbUHBoRJUn+qiuy8Pbxu5y+NJzBEMK4d8Yh0GZmxRq-ovw@mail.gmail.com>

On Fri, Oct 11, 2013 at 12:27 PM, William Waites <wwaites at tardis.ed.ac.uk>wrote:

> In my opinion the main problems with this are:
>   - It's brittle, when a line fails, traffic doesn't re-route
>

Yes, but this is no worse than if you just had one single DSL link.
Manual failover is a perfectly valid solution for very small networks where
a    less-than-enterprise-grade solution such as DSL is suitable.

I'd be more concerned about the question of  /have you implemented a proper
firewall solution/ ?

  - None of the usual debugging tools work properly
>   - Adding a new user is complicated because it has to be done in (at
>     least) two places
>

Not necessarily.

You might pick a  /20  rfc1918 network,  and then assign a  /24 of source
addresses out of the subnet to each link.   Then you won't need to adjust
two places,  every time a device is added;  just  IP it appropriately,  or
set the appropriate DHCP reservation, or  Best:   subnet the local network
based on choice of outgoing WAN link,  and select the client's VLAN based
on desired WAN link...

Another alternative to PBR is to  have an  extra router for each DSL link,
 providing a default gateway;


> But I'm having a distinct lack of success locating rants and diatribes
> or even well-reasoned articles supporting this opinion.
>

There are plenty of downsides to PBR in various scenarios,  but the PBR
functionality on these devices doesn't exist just at the whim of the device
manufacturer ---   operators look for  the functionality.


It is perfectly valid and very good to use PBR,  as long as you understand
any limitations and drawbacks that apply to your specific situation.

The main drawback is ease-of-maintenance challenges.


-w

--
-JH

From bedard.phil at gmail.com  Fri Oct 11 22:54:24 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Fri, 11 Oct 2013 15:54:24 -0700
Subject: Policy-based routing is evil? Discuss.
Message-ID: <-3753201734474531624@unknownmsgid>

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
  - None of the usual debugging tools work properly
  - Adding a new user is complicated because it has to be done in (at
    least) two places

But I'm having a distinct lack of success locating rants and diatribes
or even well-reasoned articles supporting this opinion.

Am I out to lunch?

-w
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 853 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131011/4b17fe9d/attachment.bin>

From bep at whack.org  Fri Oct 11 22:59:22 2013
From: bep at whack.org (Bruce Pinsky)
Date: Fri, 11 Oct 2013 15:59:22 -0700
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <-3753201734474531624@unknownmsgid>
References: <-3753201734474531624@unknownmsgid>
Message-ID: <525882CA.3010405@whack.org>

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

Phil Bedard 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
>   - None of the usual debugging tools work properly
>   - Adding a new user is complicated because it has to be done in (at
>     least) two places
> 
> But I'm having a distinct lack of success locating rants and diatribes
> or even well-reasoned articles supporting this opinion.
> 
> Am I out to lunch?
> 

No, but what better solution do we have to offer them?  There are dynamic
load distribution features and products (think Cisco PfR, for example), but
those are routinely lambasted as well.


- -- 
=========
bep

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

iEYEARECAAYFAlJYgsoACgkQE1XcgMgrtyaHOgCfaS58WFFKaXfY87FddXZu4SGb
b60AoPMY73ZtENIW4akBZbUMN0H9euY2
=XSi6
-----END PGP SIGNATURE-----


From gary at baribault.net  Fri Oct 11 23:07:29 2013
From: gary at baribault.net (Gary Baribault)
Date: Fri, 11 Oct 2013 19:07:29 -0400
Subject: To CCIEs and JNCIEs
In-Reply-To: <1381524701.2150.12.camel@Andromeda>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
 <m2hacoxo57.wl%randy@psg.com>
 <CACnPsNUcQ3tQF50GZ-_B9skUSPypjKyvw9kBnHvmXTbn=wYeiQ@mail.gmail.com>
 <1381524701.2150.12.camel@Andromeda>
Message-ID: <525884B1.6070909@baribault.net>

Hey, I'm a security guy, I'm paid to be paranoid, the only question is
whether I'm paranoid enough .. I don't need another EMail addy

Gary Baribault
Courriel: gary at baribault.net
GPG Key: 0x685430d1
Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1

On 10/11/2013 04:51 PM, Richard Golodner wrote:
> On Fri, 2013-10-11 at 12:45 -0700, Scott Howard wrote:
>> I dunno, it looks pretty legit to me!!
>>
>> Domain Name.......... theccie.com
>>   Creation Date........ 2013-09-28
>>   Registration Date.... 2013-09-28
>>   Expiry Date.......... 2014-09-28
>>
>>   Organisation Name.... the ccie
>>   Organisation Address. later
>>   Organisation Address.
>>   Organisation Address.
>>   Organisation Address. singapore
>>   Organisation Address. 100850
>>   Organisation Address. singapore
>>   Organisation Address. SINGAPORE 
> 	With a business address of "later" and no other traceable info I would
> be wary.
> 	Like in Scarface, perhaps I am just paranoid. 
> 	My paranoia has worked for me though.
> 	Richard
>
>
>
>



From wbailey at satelliteintelligencegroup.com  Fri Oct 11 23:10:40 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Fri, 11 Oct 2013 23:10:40 +0000
Subject: To CCIEs and JNCIEs
In-Reply-To: <525884B1.6070909@baribault.net>
Message-ID: <CE7DD360.B567%wbailey@satelliteintelligencegroup.com>

I'd hope that an IE would get this email for a vanity address on some
blog.. I would hope..

On 10/11/13 4:07 PM, "Gary Baribault" <gary at baribault.net> wrote:

>Hey, I'm a security guy, I'm paid to be paranoid, the only question is
>whether I'm paranoid enough .. I don't need another EMail addy
>
>Gary Baribault
>Courriel: gary at baribault.net
>GPG Key: 0x685430d1
>Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1
>
>On 10/11/2013 04:51 PM, Richard Golodner wrote:
>> On Fri, 2013-10-11 at 12:45 -0700, Scott Howard wrote:
>>> I dunno, it looks pretty legit to me!!
>>>
>>> Domain Name.......... theccie.com
>>>   Creation Date........ 2013-09-28
>>>   Registration Date.... 2013-09-28
>>>   Expiry Date.......... 2014-09-28
>>>
>>>   Organisation Name.... the ccie
>>>   Organisation Address. later
>>>   Organisation Address.
>>>   Organisation Address.
>>>   Organisation Address. singapore
>>>   Organisation Address. 100850
>>>   Organisation Address. singapore
>>>   Organisation Address. SINGAPORE
>> 	With a business address of "later" and no other traceable info I would
>> be wary.
>> 	Like in Scarface, perhaps I am just paranoid.
>> 	My paranoia has worked for me though.
>> 	Richard
>>
>>
>>
>>
>
>



From jason at biel-tech.com  Fri Oct 11 23:11:35 2013
From: jason at biel-tech.com (Jason Biel)
Date: Fri, 11 Oct 2013 18:11:35 -0500
Subject: To CCIEs and JNCIEs
In-Reply-To: <525884B1.6070909@baribault.net>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
 <m2hacoxo57.wl%randy@psg.com>
 <CACnPsNUcQ3tQF50GZ-_B9skUSPypjKyvw9kBnHvmXTbn=wYeiQ@mail.gmail.com>
 <1381524701.2150.12.camel@Andromeda> <525884B1.6070909@baribault.net>
Message-ID: <-4302282573473237332@unknownmsgid>

I think I'll look to one up him and register "theccar.com"

> On Oct 11, 2013, at 18:09, Gary Baribault <gary at baribault.net> wrote:
>
> Hey, I'm a security guy, I'm paid to be paranoid, the only question is
> whether I'm paranoid enough .. I don't need another EMail addy
>
> Gary Baribault
> Courriel: gary at baribault.net
> GPG Key: 0x685430d1
> Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1
>
>> On 10/11/2013 04:51 PM, Richard Golodner wrote:
>>> On Fri, 2013-10-11 at 12:45 -0700, Scott Howard wrote:
>>> I dunno, it looks pretty legit to me!!
>>>
>>> Domain Name.......... theccie.com
>>>  Creation Date........ 2013-09-28
>>>  Registration Date.... 2013-09-28
>>>  Expiry Date.......... 2014-09-28
>>>
>>>  Organisation Name.... the ccie
>>>  Organisation Address. later
>>>  Organisation Address.
>>>  Organisation Address.
>>>  Organisation Address. singapore
>>>  Organisation Address. 100850
>>>  Organisation Address. singapore
>>>  Organisation Address. SINGAPORE
>>    With a business address of "later" and no other traceable info I would
>> be wary.
>>    Like in Scarface, perhaps I am just paranoid.
>>    My paranoia has worked for me though.
>>    Richard
>
>


From ml at kenweb.org  Fri Oct 11 23:26:37 2013
From: ml at kenweb.org (ML)
Date: Fri, 11 Oct 2013 19:26:37 -0400
Subject: To CCIEs and JNCIEs
In-Reply-To: <525884B1.6070909@baribault.net>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
 <m2hacoxo57.wl%randy@psg.com>
 <CACnPsNUcQ3tQF50GZ-_B9skUSPypjKyvw9kBnHvmXTbn=wYeiQ@mail.gmail.com>
 <1381524701.2150.12.camel@Andromeda> <525884B1.6070909@baribault.net>
Message-ID: <5258892D.9070802@kenweb.org>

On 10/11/2013 7:07 PM, Gary Baribault wrote:
> Hey, I'm a security guy, I'm paid to be paranoid, the only question is
> whether I'm paranoid enough .. I don't need another EMail addy
>
> Gary Baribault
> Courriel: gary at baribault.net
> GPG Key: 0x685430d1
> Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1

While your email contains a reference to a GPG key your email was not
signed with it.
Are you the real Gary Baribault?  :)


From cciehelps at gmail.com  Sat Oct 12 00:16:16 2013
From: cciehelps at gmail.com (ku po)
Date: Sat, 12 Oct 2013 08:16:16 +0800
Subject: To CCIEs and JNCIEs
In-Reply-To: <5258892D.9070802@kenweb.org>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
 <m2hacoxo57.wl%randy@psg.com>
 <CACnPsNUcQ3tQF50GZ-_B9skUSPypjKyvw9kBnHvmXTbn=wYeiQ@mail.gmail.com>
 <1381524701.2150.12.camel@Andromeda>
 <525884B1.6070909@baribault.net> <5258892D.9070802@kenweb.org>
Message-ID: <CAAtfGYjU39H0UE_35ga3ZU3BFsHLsSggY7QZCgaSgPaUvpMnUA@mail.gmail.com>

Well in case you wondering how much the domain costs me, it costs me 1.99
for 1 year :-)

On Sat, Oct 12, 2013 at 7:26 AM, ML <ml at kenweb.org> wrote:

> On 10/11/2013 7:07 PM, Gary Baribault wrote:
> > Hey, I'm a security guy, I'm paid to be paranoid, the only question is
> > whether I'm paranoid enough .. I don't need another EMail addy
> >
> > Gary Baribault
> > Courriel: gary at baribault.net
> > GPG Key: 0x685430d1
> > Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1
>
> While your email contains a reference to a GPG key your email was not
> signed with it.
> Are you the real Gary Baribault?  :)
>
>

From philfagan at gmail.com  Sat Oct 12 00:22:05 2013
From: philfagan at gmail.com (Phil Fagan)
Date: Fri, 11 Oct 2013 18:22:05 -0600
Subject: NANOG 59 - Monday presentations on YouTube
In-Reply-To: <alpine.DEB.2.02.1310100859080.20065@uplift.swm.pp.se>
References: <CAFJiuFrtjK=dw0mT1xsH94K5ipM0Ey5A98TwbDGEjogBnc1o9g@mail.gmail.com>
 <20131009211010.GN3108@burnout.tpb.net>
 <alpine.DEB.2.02.1310100859080.20065@uplift.swm.pp.se>
Message-ID: <CAPhg-wT1kR3OWUmAPXmNSiD4fas+eKpAg6rV+kbjPJcBFA1EtQ@mail.gmail.com>

Really appreciated this video! Tracking amplification on Comcast as we
speak!


On Thu, Oct 10, 2013 at 12:59 AM, Mikael Abrahamsson <swmike at swm.pp.se>wrote:

> On Wed, 9 Oct 2013, Niels Bakker wrote:
>
>  * dave at temk.in (David Temkin) [Tue 08 Oct 2013, 23:43 CEST]:
>>
>>> We're proud to announce that all of the recorded presentations from
>>> Monday at NANOG 59 in Phoenix have now been posted to Youtube.
>>>
>>
>> This is really neat.
>>
>
> I agree, it's great! My only nit with it is that the aspect ratio seems to
> be wrong.
>
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se
>
>


-- 
Phil Fagan
Denver, CO
970-480-7618

From jeff-kell at utc.edu  Sat Oct 12 03:31:41 2013
From: jeff-kell at utc.edu (Jeff Kell)
Date: Fri, 11 Oct 2013 23:31:41 -0400
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <525882CA.3010405@whack.org>
References: <-3753201734474531624@unknownmsgid> <525882CA.3010405@whack.org>
Message-ID: <5258C29D.5030000@utc.edu>

As others have pointed out, PBR ...

* Is a fragile configuration.  You're typically forcing next-hop without
a [direct] failover option,
* Often incurs a penalty (hardware cycles, conflicting feature sets, or
outright punting to software),
* Doesn't naturally load-balance (you pick the source ranges you route
where)

However, there are few alternatives in some cases...

* If you are using some provider-owned IP space you often must route to
that provider,
* There may be policies restricting what traffic (sources) can transit a
given provider

There are few alternatives for the latter cases, unless you split the
border across VRFs and assign routing policy on the VRF, which is a
global decision across the VRF, and avoids PBR.

We're doing a little of both, so I clearly don't take sides :)

Jeff


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131011/9e296215/attachment-0001.bin>

From cciehelps at gmail.com  Sat Oct 12 06:46:08 2013
From: cciehelps at gmail.com (ku po)
Date: Sat, 12 Oct 2013 14:46:08 +0800
Subject: To CCIEs and JNCIEs
In-Reply-To: <CAAtfGYjU39H0UE_35ga3ZU3BFsHLsSggY7QZCgaSgPaUvpMnUA@mail.gmail.com>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
 <m2hacoxo57.wl%randy@psg.com>
 <CACnPsNUcQ3tQF50GZ-_B9skUSPypjKyvw9kBnHvmXTbn=wYeiQ@mail.gmail.com>
 <1381524701.2150.12.camel@Andromeda>
 <525884B1.6070909@baribault.net> <5258892D.9070802@kenweb.org>
 <CAAtfGYjU39H0UE_35ga3ZU3BFsHLsSggY7QZCgaSgPaUvpMnUA@mail.gmail.com>
Message-ID: <CAAtfGYjP13XRpejzZywcEFhusiAFE5mLoXJyT1uk83qqUBn_Xw@mail.gmail.com>

The email accounts are hosted at Microsoft, I have setup auto-responder so
if you email root at theccie.com, you can see for yourself if the reply comes
from live.com/hotmail.com. Microsoft takes care all the authentication in
case you wonder.



On Sat, Oct 12, 2013 at 8:16 AM, ku po <cciehelps at gmail.com> wrote:

>
> Well in case you wondering how much the domain costs me, it costs me 1.99
> for 1 year :-)
>
> On Sat, Oct 12, 2013 at 7:26 AM, ML <ml at kenweb.org> wrote:
>
>> On 10/11/2013 7:07 PM, Gary Baribault wrote:
>> > Hey, I'm a security guy, I'm paid to be paranoid, the only question is
>> > whether I'm paranoid enough .. I don't need another EMail addy
>> >
>> > Gary Baribault
>> > Courriel: gary at baribault.net
>> > GPG Key: 0x685430d1
>> > Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1
>>
>> While your email contains a reference to a GPG key your email was not
>> signed with it.
>> Are you the real Gary Baribault?  :)
>>
>>
>

From jacques at siberia.co.za  Sat Oct 12 14:32:04 2013
From: jacques at siberia.co.za (Jacques Marneweck)
Date: Sat, 12 Oct 2013 16:32:04 +0200
Subject: Trend Micro Contact
Message-ID: <52595D64.7080804@siberia.co.za>

Hi Guys,

I am looking for a contact at Trend Micro -- the email address they
which they send notifications from appears to go to /dev/null as well as
their web form appears to also go to /dev/null.  If you can contact me
off list it would be great.

Regards
--jm


From alvarezp at alvarezp.ods.org  Sat Oct 12 17:48:03 2013
From: alvarezp at alvarezp.ods.org (Octavio Alvarez)
Date: Sat, 12 Oct 2013 10:48:03 -0700
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: <52598B53.3030502@alvarezp.ods.org>

On 10/11/2013 10:27 AM, William Waites 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.

I wouldn't say "evil", I have found it really useful in some cases. You
just need a different approach to the network design.

I'd just say it's not the easiest way and yeah, I try to generally avoid it.

>   - It's brittle, when a line fails, traffic doesn't re-route

This depends on how flexible the PBR implementation on your router is.
If your router can have conditionals like this:

* match: source address A && link P available --> send it to link P
* match: source address A --> unconditionally send it to fallback link F

Then your users will converge quite nicely. Also, make sure you prepare
for router redundancy.

Configuration can get pretty complex, though, and link addition can
require redesign of the whole policy.

>   - None of the usual debugging tools work properly

No, but then, they can't expect usual debugging tools with unusual
scenario. You may need to develop some new tools and teach them how to
use them.

>   - Adding a new user is complicated because it has to be done in (at
>     least) two places

With a good design this burden can be significantly lowered to the point
of being not 100% but 80 or 90% effective, so to speak. Consider a good
topology and a good addressing plan.




From mysidia at gmail.com  Sat Oct 12 17:58:30 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 12 Oct 2013 12:58:30 -0500
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <52598B53.3030502@alvarezp.ods.org>
References: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
 <52598B53.3030502@alvarezp.ods.org>
Message-ID: <CAAAwwbUvwJNGZk7BEEYZPvwEoPA_vNNoTdLQOdTNd3bgAQag1w@mail.gmail.com>

On Sat, Oct 12, 2013 at 12:48 PM, Octavio Alvarez <alvarezp at alvarezp.ods.org
> wrote:

> This depends on how flexible the PBR implementation on your router is.
> If your router can have conditionals like this:
>
> * match: source address A && link P available --> send it to link P
> * match: source address A --> unconditionally send it to fallback link F
>

It doesn't necessarily have to be that complex OR brittle.

I would suggest the use of  recursive  next-hop  with PBR  to the loopback
/32  of a peer router   that is not associated with a directly connected
network.

If  that /32  route happens to be down,   then the  recursive  lookup of
the next-hop   results in a lookup of the default route.

-- 
-JH

From josmon at rigozsaurus.com  Sun Oct 13 05:55:54 2013
From: josmon at rigozsaurus.com (John Osmon)
Date: Sat, 12 Oct 2013 23:55:54 -0600
Subject: Policy-based routing is evil? Discuss.
In-Reply-To: <52598B53.3030502@alvarezp.ods.org>
References: <20131011.182700.484727119.wwaites@tardis.ed.ac.uk>
 <52598B53.3030502@alvarezp.ods.org>
Message-ID: <20131013055554.GA21103@jeeves.rigozsaurus.com>

On Sat, Oct 12, 2013 at 10:48:03AM -0700, Octavio Alvarez wrote:
> On 10/11/2013 10:27 AM, William Waites 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.
> 
> I wouldn't say "evil", I have found it really useful in some cases. You
> just need a different approach to the network design.

Yeah.

Just do it in private and wash your hands afterwards.

(Sorry, but a Lazarus Long quote seemed appropriate.)




From jmamodio at gmail.com  Sun Oct 13 12:30:02 2013
From: jmamodio at gmail.com (Jorge Amodio)
Date: Sun, 13 Oct 2013 07:30:02 -0500
Subject: To CCIEs and JNCIEs
In-Reply-To: <CAAtfGYjP13XRpejzZywcEFhusiAFE5mLoXJyT1uk83qqUBn_Xw@mail.gmail.com>
References: <CAAtfGYiqW0t=H9HdvAO1vMzgugf=2AVCweF=Y2JXORxiDa6OJw@mail.gmail.com>
 <m2hacoxo57.wl%randy@psg.com>
 <CACnPsNUcQ3tQF50GZ-_B9skUSPypjKyvw9kBnHvmXTbn=wYeiQ@mail.gmail.com>
 <1381524701.2150.12.camel@Andromeda>
 <525884B1.6070909@baribault.net> <5258892D.9070802@kenweb.org>
 <CAAtfGYjU39H0UE_35ga3ZU3BFsHLsSggY7QZCgaSgPaUvpMnUA@mail.gmail.com>
 <CAAtfGYjP13XRpejzZywcEFhusiAFE5mLoXJyT1uk83qqUBn_Xw@mail.gmail.com>
Message-ID: <CAMzo+1ZOu1dHtDti2+xGY1Yp4gDmUfAOvvJD_Dy2u47ASvs76w@mail.gmail.com>

And you are ?

Perhaps Singapore became the equivalent of a fiscal paradise for IP packets
away from the prying eyes of the NSA ...

-J

From jason.sherron at microsoft.com  Mon Oct 14 19:36:17 2013
From: jason.sherron at microsoft.com (Jason Sherron)
Date: Mon, 14 Oct 2013 19:36:17 +0000
Subject: looking for Verizon Biz (UUNET) DNS contact
Message-ID: <762a111e0c0c4c3db048d3b0239f4825@DFM-DB3MBX15-07.exchange.corp.microsoft.com>

Would you mind contacting me off-list, please? I would like to ask a couple questions on the behaviors of the DNS resolvers present in DigWebInterface:

195.129.12.122 (UUNET (CH)):
192.76.144.66 (UUNET (DE)):
158.43.240.3 (UUNET (UK)):
198.6.100.25 (UUNET (US)):


From tritran at cox.net  Mon Oct 14 19:57:44 2013
From: tritran at cox.net (Tri Tran)
Date: Mon, 14 Oct 2013 19:57:44 +0000
Subject: Cogent 100M DIA in Denver
Message-ID: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>

They're lit in the bulding and have a much faster installation interval. How reliable are they? 
Tri Tran


From contact at nullivex.com  Mon Oct 14 20:00:05 2013
From: contact at nullivex.com (Bryan Tong)
Date: Mon, 14 Oct 2013 14:00:05 -0600
Subject: Cogent 100M DIA in Denver
In-Reply-To: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
Message-ID: <CAAARkvKRKg3vJHriKuMDiseqYDyRrBUUhsZAASu2zkF4o03SVw@mail.gmail.com>

We've had them direct for transit in LA for about a year. And a year before
that in Denver.

Never had any issues aside from some missing BGP when New York was under
water. Great for US domestic traffic. Not very good for international
traffic.


On Mon, Oct 14, 2013 at 1:57 PM, Tri Tran <tritran at cox.net> wrote:

> They're lit in the bulding and have a much faster installation interval.
> How reliable are they?
> Tri Tran
>
>

From contact at nullivex.com  Mon Oct 14 20:00:55 2013
From: contact at nullivex.com (Bryan Tong)
Date: Mon, 14 Oct 2013 14:00:55 -0600
Subject: Cogent 100M DIA in Denver
In-Reply-To: <CAAARkvKRKg3vJHriKuMDiseqYDyRrBUUhsZAASu2zkF4o03SVw@mail.gmail.com>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
 <CAAARkvKRKg3vJHriKuMDiseqYDyRrBUUhsZAASu2zkF4o03SVw@mail.gmail.com>
Message-ID: <CAAARkv+5xOu_hHkvG8XkyFaLS0W-bGKbCimvPAYQ23LXZ3BHBA@mail.gmail.com>

Let me correct that.

Not very good for pacific international traffic. Atlantic bound is fine.


On Mon, Oct 14, 2013 at 2:00 PM, Bryan Tong <contact at nullivex.com> wrote:

> We've had them direct for transit in LA for about a year. And a year
> before that in Denver.
>
> Never had any issues aside from some missing BGP when New York was under
> water. Great for US domestic traffic. Not very good for international
> traffic.
>
>
> On Mon, Oct 14, 2013 at 1:57 PM, Tri Tran <tritran at cox.net> wrote:
>
>> They're lit in the bulding and have a much faster installation interval.
>> How reliable are they?
>> Tri Tran
>>
>>
>
>
>

From brent at brentrjones.com  Mon Oct 14 20:16:43 2013
From: brent at brentrjones.com (Brent Jones)
Date: Mon, 14 Oct 2013 13:16:43 -0700
Subject: Cogent 100M DIA in Denver
In-Reply-To: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
Message-ID: <CAOC=LuV1V-Cr0Vk-Zfj0RjJU2zc8K19bdnhK2YMBqHXTBTYfnQ@mail.gmail.com>

We have several 100Mb Cogent DIA lines in various places, NYC, Boston,
Portland OR, and it works fine.
It isn't the highest quality, but it works well enough for any office/small
hosting needs.


On Mon, Oct 14, 2013 at 12:57 PM, Tri Tran <tritran at cox.net> wrote:

> They're lit in the bulding and have a much faster installation interval.
> How reliable are they?
> Tri Tran
>
>


-- 
Brent Jones
brent at brentrjones.com

From robertg at garlic.com  Mon Oct 14 20:36:11 2013
From: robertg at garlic.com (Robert Glover)
Date: Mon, 14 Oct 2013 13:36:11 -0700
Subject: Cogent 100M DIA in Denver
In-Reply-To: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
Message-ID: <525C55BB.9020500@garlic.com>

We've had them since May 2008.  Recently upgraded from 100Mb to 250Mb. 
Had minor issues here and there (no outages to speak of).

I've had some IPv6 issues since moving the link to dual-stack a few
months back, but we are not deploying IPv6 to end-users yet, so I'll let
them slide on that.

On 10/14/2013 12:57 PM, Tri Tran wrote:
> They're lit in the bulding and have a much faster installation interval. How reliable are they? 
> Tri Tran
>



From mureninc at gmail.com  Mon Oct 14 20:41:48 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Mon, 14 Oct 2013 13:41:48 -0700
Subject: Cogent 100M DIA in Denver
In-Reply-To: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
Message-ID: <CAPKkNb6CVEM10eK8GM7EABUFk-nUs9+7f6aCUF=msZFr19GETw@mail.gmail.com>

On 14 October 2013 12:57, Tri Tran <tritran at cox.net> wrote:
> They're lit in the bulding and have a much faster installation interval. How reliable are they?
> Tri Tran

It's worth pointing out that many IPv6 networks are unavailable from
Cogent; so, effectively, in 2013, you still can't get IPv6
connectivity from Cogent.

C.


From web at typo.org  Mon Oct 14 21:18:16 2013
From: web at typo.org (Wayne E Bouchard)
Date: Mon, 14 Oct 2013 14:18:16 -0700
Subject: Cogent 100M DIA in Denver
In-Reply-To: <CAPKkNb6CVEM10eK8GM7EABUFk-nUs9+7f6aCUF=msZFr19GETw@mail.gmail.com>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
 <CAPKkNb6CVEM10eK8GM7EABUFk-nUs9+7f6aCUF=msZFr19GETw@mail.gmail.com>
Message-ID: <20131014211816.GA17122@wakko.typo.org>

It's worth pointing out that many IPv6 networks are unavailable from
<insert provider here>.

Hardly something to hold against them until the rest of us can all get
our own houses in order...

On Mon, Oct 14, 2013 at 01:41:48PM -0700, Constantine A. Murenin wrote:
> On 14 October 2013 12:57, Tri Tran <tritran at cox.net> wrote:
> > They're lit in the bulding and have a much faster installation interval. How reliable are they?
> > Tri Tran
> 
> It's worth pointing out that many IPv6 networks are unavailable from
> Cogent; so, effectively, in 2013, you still can't get IPv6
> connectivity from Cogent.
> 
> C.

---
Wayne Bouchard
web at typo.org
Network Dude
http://www.typo.org/~web/


From ikiris at gmail.com  Mon Oct 14 21:57:15 2013
From: ikiris at gmail.com (Blake Dunlap)
Date: Mon, 14 Oct 2013 16:57:15 -0500
Subject: Cogent 100M DIA in Denver
In-Reply-To: <20131014211816.GA17122@wakko.typo.org>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
 <CAPKkNb6CVEM10eK8GM7EABUFk-nUs9+7f6aCUF=msZFr19GETw@mail.gmail.com>
 <20131014211816.GA17122@wakko.typo.org>
Message-ID: <CAJvB4tn6bC5cmWNHs5jV-WjpLgX9Ag7dbbxGvAqZWCnP1ZBc0w@mail.gmail.com>

Cogent is great if you treat them as a path. I wouldn't use Cogent in place
of single homing a service provider though due to how they run their
network and the subsequent peering disputes that arise. Don't get me wrong,
I like Cogent, they definitely have a good use case, just be cognizant of
how they run their business model / network.

-Blake


On Mon, Oct 14, 2013 at 4:18 PM, Wayne E Bouchard <web at typo.org> wrote:

> It's worth pointing out that many IPv6 networks are unavailable from
> <insert provider here>.
>
> Hardly something to hold against them until the rest of us can all get
> our own houses in order...
>
> On Mon, Oct 14, 2013 at 01:41:48PM -0700, Constantine A. Murenin wrote:
> > On 14 October 2013 12:57, Tri Tran <tritran at cox.net> wrote:
> > > They're lit in the bulding and have a much faster installation
> interval. How reliable are they?
> > > Tri Tran
> >
> > It's worth pointing out that many IPv6 networks are unavailable from
> > Cogent; so, effectively, in 2013, you still can't get IPv6
> > connectivity from Cogent.
> >
> > C.
>
> ---
> Wayne Bouchard
> web at typo.org
> Network Dude
> http://www.typo.org/~web/
>
>

From mureninc at gmail.com  Mon Oct 14 22:00:19 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Mon, 14 Oct 2013 15:00:19 -0700
Subject: Cogent 100M DIA in Denver
In-Reply-To: <20131014211816.GA17122@wakko.typo.org>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
 <CAPKkNb6CVEM10eK8GM7EABUFk-nUs9+7f6aCUF=msZFr19GETw@mail.gmail.com>
 <20131014211816.GA17122@wakko.typo.org>
Message-ID: <CAPKkNb5wTM--u24WAiW190DRGXVXiP19+o6Yx1u2k0xR215VjQ@mail.gmail.com>

On 14 October 2013 14:18, Wayne E Bouchard <web at typo.org> wrote:
> It's worth pointing out that many IPv6 networks are unavailable from
> <insert provider here>.
>
> Hardly something to hold against them until the rest of us can all get
> our own houses in order...

Which other provider?  Please name at least one.

Other providers either offer IPv6, or don't.  When those other
providers do, good or bad, you can connect to any other IPv6 network
(well, except maybe for Cogent's AS174).

When Cogent offers IPv6, a lot of IPv6 networks are unreachable.  No
other provider comes close.

I mean, even their web-site doesn't work from many IPv6-connected
hosts, because there's no route for their network:

li163-XXX:~# telnet cogentco.com http
Trying 2001:550:1::cc01...
^C
li163-XXX:~#

C.

> On Mon, Oct 14, 2013 at 01:41:48PM -0700, Constantine A. Murenin wrote:
>> On 14 October 2013 12:57, Tri Tran <tritran at cox.net> wrote:
>> > They're lit in the bulding and have a much faster installation interval. How reliable are they?
>> > Tri Tran
>>
>> It's worth pointing out that many IPv6 networks are unavailable from
>> Cogent; so, effectively, in 2013, you still can't get IPv6
>> connectivity from Cogent.
>>
>> C.


From me at staticsafe.ca  Mon Oct 14 22:30:16 2013
From: me at staticsafe.ca (staticsafe)
Date: Mon, 14 Oct 2013 18:30:16 -0400
Subject: Cogent 100M DIA in Denver
In-Reply-To: <CAPKkNb5wTM--u24WAiW190DRGXVXiP19+o6Yx1u2k0xR215VjQ@mail.gmail.com>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
 <CAPKkNb6CVEM10eK8GM7EABUFk-nUs9+7f6aCUF=msZFr19GETw@mail.gmail.com>
 <20131014211816.GA17122@wakko.typo.org>
 <CAPKkNb5wTM--u24WAiW190DRGXVXiP19+o6Yx1u2k0xR215VjQ@mail.gmail.com>
Message-ID: <525C7078.6060404@staticsafe.ca>

On 10/14/2013 18:00, Constantine A. Murenin wrote:
> Which other provider?  Please name at least one.
>
> Other providers either offer IPv6, or don't.  When those other
> providers do, good or bad, you can connect to any other IPv6 network
> (well, except maybe for Cogent's AS174).
>
> When Cogent offers IPv6, a lot of IPv6 networks are unreachable.  No
> other provider comes close.
>
> I mean, even their web-site doesn't work from many IPv6-connected
> hosts, because there's no route for their network:
>
> li163-XXX:~# telnet cogentco.com http
> Trying 2001:550:1::cc01...
> ^C
> li163-XXX:~#
>
> C.

Fremont Linode? I see it is unreachable from my ARP Networks VPS (HE v6 
transit) and also from behind my HE tunnel at home.

-- 
staticsafe
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post. It is not logical.
Please don't CC me! I'm subscribed to whatever list I just posted on.


From jra at baylink.com  Mon Oct 14 23:01:20 2013
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 14 Oct 2013 19:01:20 -0400 (EDT)
Subject: Cogent 100M DIA in Denver
In-Reply-To: <CAPKkNb6CVEM10eK8GM7EABUFk-nUs9+7f6aCUF=msZFr19GETw@mail.gmail.com>
Message-ID: <1880094.1573.1381791680625.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Constantine A. Murenin" <mureninc at gmail.com>

> On 14 October 2013 12:57, Tri Tran <tritran at cox.net> wrote:
> > They're lit in the bulding and have a much faster installation
> > interval. How reliable are they?
> > Tri Tran
> 
> It's worth pointing out that many IPv6 networks are unavailable from
> Cogent; so, effectively, in 2013, you still can't get IPv6
> connectivity from Cogent.

And, presumably, IPv4 either, depending on whom they're having a peering
war with that particular month.

For a client connection, such is probably safe; I don't think I'd run
servers on it.

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 Lee at asgard.org  Mon Oct 14 23:28:16 2013
From: Lee at asgard.org (Lee Howard)
Date: Tue, 15 Oct 2013 02:28:16 +0300
Subject: comcast ipv6 PTR
In-Reply-To: <21078.13971.505553.140013@world.std.com>
Message-ID: <CE82582B.3312E%Lee@asgard.org>



On 10/10/13 1:09 AM, "Barry Shein" <bzs at world.std.com> wrote:

>
>On October 9, 2013 at 20:18 cma at cmadams.net (Chris Adams) wrote:
> > Once upon a time, Barry Shein <bzs at world.std.com> said:
> > > It's very useful for blocking spammers and other miscreants -- no
> > > reason at all to accept SMTP connections from troublesome
> > > *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN
> > > is.
> > 
> > If you are going to block like that, just block anybody without valid
> > reverse DNS.  If you don't trust provider foo.net to police their
>users,
> > why trust them to put valid and consistent xx-xx-xx-xx.dyn.foo.net
> > reverse?
>
>Because they do, they just do. This isn't a math proof, it's mostly
>social engineering. The providers aren't trying to fool anyone, in
>general, it's just that clients and websites get botted.

Except the point of this thread is that they don't.

Is it easier to block inbound mail from hosts with certain high-level
domain
names in their PTRs than to block ranges of IP(v6) addresses?  Easier for
whom?

Lee




From sethm at rollernet.us  Mon Oct 14 23:48:33 2013
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 14 Oct 2013 16:48:33 -0700
Subject: Cogent 100M DIA in Denver
In-Reply-To: <525C7078.6060404@staticsafe.ca>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
 <CAPKkNb6CVEM10eK8GM7EABUFk-nUs9+7f6aCUF=msZFr19GETw@mail.gmail.com>
 <20131014211816.GA17122@wakko.typo.org>
 <CAPKkNb5wTM--u24WAiW190DRGXVXiP19+o6Yx1u2k0xR215VjQ@mail.gmail.com>
 <525C7078.6060404@staticsafe.ca>
Message-ID: <525C82D1.7060803@rollernet.us>

On 10/14/13 3:30 PM, staticsafe wrote:
> On 10/14/2013 18:00, Constantine A. Murenin wrote:
>> Which other provider?  Please name at least one.
>>
>> Other providers either offer IPv6, or don't.  When those other
>> providers do, good or bad, you can connect to any other IPv6 network
>> (well, except maybe for Cogent's AS174).
>>
>> When Cogent offers IPv6, a lot of IPv6 networks are unreachable.  No
>> other provider comes close.
>>
>> I mean, even their web-site doesn't work from many IPv6-connected
>> hosts, because there's no route for their network:
>>
>> li163-XXX:~# telnet cogentco.com http
>> Trying 2001:550:1::cc01...
>> ^C
>> li163-XXX:~#
>>
>> C.
>
> Fremont Linode? I see it is unreachable from my ARP Networks VPS (HE v6
> transit) and also from behind my HE tunnel at home.
>


HE and Cogen't don't peer, even after the cake.

~Seth


From bzs at world.std.com  Tue Oct 15 00:40:03 2013
From: bzs at world.std.com (Barry Shein)
Date: Mon, 14 Oct 2013 20:40:03 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <CE82582B.3312E%Lee@asgard.org>
References: <21078.13971.505553.140013@world.std.com>
 <CE82582B.3312E%Lee@asgard.org>
Message-ID: <21084.36579.320535.17928@world.std.com>


On October 15, 2013 at 02:28 Lee at asgard.org (Lee Howard) wrote:
 > 
 > 
 > On 10/10/13 1:09 AM, "Barry Shein" <bzs at world.std.com> wrote:
 > 
 > >
 > >On October 9, 2013 at 20:18 cma at cmadams.net (Chris Adams) wrote:
 > > > Once upon a time, Barry Shein <bzs at world.std.com> said:
 > > > > It's very useful for blocking spammers and other miscreants -- no
 > > > > reason at all to accept SMTP connections from troublesome
 > > > > *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN
 > > > > is.
 > > > 
 > > > If you are going to block like that, just block anybody without valid
 > > > reverse DNS.  If you don't trust provider foo.net to police their
 > >users,
 > > > why trust them to put valid and consistent xx-xx-xx-xx.dyn.foo.net
 > > > reverse?
 > >
 > >Because they do, they just do. This isn't a math proof, it's mostly
 > >social engineering. The providers aren't trying to fool anyone, in
 > >general, it's just that clients and websites get botted.
 > 
 > Except the point of this thread is that they don't.

I think the point of this thread was they don't for IPv6 and whether
they should or not (BCP)?

I was pointing out that reverse IP names, particularly where they
follow a simple pattern, can be useful in spam blocking.

That may or may not be an attractive reason to a site, but I didn't
particularly claim it to be. It's just an observation.

 > Is it easier to block inbound mail from hosts with certain high-level
 > domain
 > names in their PTRs than to block ranges of IP(v6) addresses?  Easier for
 > whom?

Of course it's easier, how do I as the SMTP client know how some site
manages their IPv6 blocks?

But it's a pretty good guess that if I'm getting 100 msgs/second from
various hosts with reverse ip names matching
ip-192-168.1.*.rev.example.com I can probably block that.

Most likely their SMTP server won't have a name like that.

As I said (and no doubt someone will jump on) none of this is an exact
science, blocking spam is not an exact science, none of the tools have
mathematical, infallible accuracy.

You do what you can.

For whom? I'm not sure what you're asking, the SMTP client side.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From fmartin at linkedin.com  Tue Oct 15 01:23:09 2013
From: fmartin at linkedin.com (Franck Martin)
Date: Tue, 15 Oct 2013 01:23:09 +0000
Subject: comcast ipv6 PTR
In-Reply-To: <21084.36579.320535.17928@world.std.com>
References: <21078.13971.505553.140013@world.std.com>
 <CE82582B.3312E%Lee@asgard.org> <21084.36579.320535.17928@world.std.com>
Message-ID: <77426B543150464AA3F30DF1A91365DE6AB22CFF@ESV4-MBX02.linkedin.biz>

If you want to block spam on IPv6, then you can start by rejecting connections to SMTP from any IPv6 that do not have a PTR. No need to analyze the format of the PTR.

It is in several recommendations that a sending email IP must have a PTR.

That ISPs will not do a PTR on all IPv6 but only on static IPv6, improves the spam blocking feature above. No need to maintain list of dynamic IP space...

-------------- 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/20131015/fdf03548/attachment.bin>

From fergdawgster at mykolab.com  Tue Oct 15 01:36:53 2013
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Mon, 14 Oct 2013 18:36:53 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <77426B543150464AA3F30DF1A91365DE6AB22CFF@ESV4-MBX02.linkedin.biz>
References: <21078.13971.505553.140013@world.std.com>
 <CE82582B.3312E%Lee@asgard.org> <21084.36579.320535.17928@world.std.com>
 <77426B543150464AA3F30DF1A91365DE6AB22CFF@ESV4-MBX02.linkedin.biz>
Message-ID: <525C9C35.4040208@mykolab.com>

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

On 10/14/2013 6:23 PM, Franck Martin wrote:

 > If you want to block spam on IPv6, then you can start by rejecting
 > connections to SMTP from any IPv6 that do not have a PTR. No need to
 > analyze the format of the PTR.
 >
 > It is in several recommendations that a sending email IP must have a PTR.
 >
 > That ISPs will not do a PTR on all IPv6 but only on static IPv6, improves
 > the spam blocking feature above. No need to maintain list of dynamic IP
 > space...
 >

...and Franck would know -- he rejects all mail from MTAs which do not. :-)

- - ferg


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 10.2.0 (Build 2317)
Charset: utf-8

wj8DBQFSXJwqq1pz9mNUZTMRAkJKAKCGLnO9qEGXv5LIKxCBiZhwf7HwHQCggksf
Fn3GhVzeKyHG5cSc7y5GXJw=
=Gtw1
-----END PGP SIGNATURE-----

-- 
Paul Ferguson
Vice President, Threat Intelligence
Internet Identity, Tacoma, Washington  USA
IID --> "Connect and Collaborate" --> www.internetidentity.com


From bzs at world.std.com  Tue Oct 15 02:15:21 2013
From: bzs at world.std.com (Barry Shein)
Date: Mon, 14 Oct 2013 22:15:21 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <77426B543150464AA3F30DF1A91365DE6AB22CFF@ESV4-MBX02.linkedin.biz>
References: <21078.13971.505553.140013@world.std.com>
 <CE82582B.3312E%Lee@asgard.org>
 <21084.36579.320535.17928@world.std.com>
 <77426B543150464AA3F30DF1A91365DE6AB22CFF@ESV4-MBX02.linkedin.biz>
Message-ID: <21084.42297.500255.50772@world.std.com>


On October 15, 2013 at 01:23 fmartin at linkedin.com (Franck Martin) wrote:
 > If you want to block spam on IPv6, then you can start by rejecting connections to SMTP from any IPv6 that do not have a PTR. No need to analyze the format of the PTR.
 > 
 > It is in several recommendations that a sending email IP must have a PTR.
 > 
 > That ISPs will not do a PTR on all IPv6 but only on static IPv6, improves the spam blocking feature above. No need to maintain list of dynamic IP space...

Well yes we don't accept email delivery from any host w/o reverse dns.

At any rate I was pointing out that PTR records with easily id'd
patterns, where sites choose to use them, can be useful for spam
blocking. It's a weak defense but any survey of spam blocking would
conclude that everything other than special case (e.g., tight
whitelisting) is a weak defense.

But if no one uses RDNS for hosts which they believe should not be
sending email directly -- a policy decision, and the most likely
effect, rendering them unable to send email to many though not all
sites -- then yes, that would have the same effect on email MTAs which
first reject hosts lacking RDNS and then look for various patterns in
the RDNS response.

It's really two different, if related, cases.

Is there any reason other than email where clients might demand RDNS?

For example, web sites that may not talk to a host w/o RDNS? I don't
know any off hand though it sounds plausible.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From johnl at iecc.com  Tue Oct 15 02:47:11 2013
From: johnl at iecc.com (John Levine)
Date: 15 Oct 2013 02:47:11 -0000
Subject: comcast ipv6 PTR
In-Reply-To: <21084.42297.500255.50772@world.std.com>
Message-ID: <20131015024711.55297.qmail@joyce.lan>

>Is there any reason other than email where clients might demand RDNS?

There's a few other protocols that want rDNS on the servers.  IRC maybe.

Doing rDNS on random hosts in IPv6 would be very hard.  Servers are
configured with static addresses which you can put in the DNS and
rDNS, but normal user machines do SLAAC where the low 64 bits of the
address are quasi-random.  To get any sort of DNS you'd need for the
routers to watch when new hosts come on line and somehow tell the
relevant DNS servers what hosts need names.

This would be a lot of work, so nobody does it.

R's,
John


From blair.trosper at gmail.com  Tue Oct 15 02:58:22 2013
From: blair.trosper at gmail.com (Blair Trosper)
Date: Mon, 14 Oct 2013 21:58:22 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <20131015024711.55297.qmail@joyce.lan>
References: <21084.42297.500255.50772@world.std.com>
 <20131015024711.55297.qmail@joyce.lan>
Message-ID: <CAA5Ek4eQy8VE-mM9ZKUZghr5Rc9F1Jaw01RE4Lr0d=x5FPt9LQ@mail.gmail.com>

That gets to the core of the original question.  I figured there must be a
reason for the conscious omission.  However, I've noticed also that Comcast
hasn't bothered to give PTR to their routers, either.

I think that's a horse of a different color.  Leaving out PTR on the last
hop for the residential customer?  Sure.

Leaving out v6 PTR on your core/backbone/edge routers?  Surely that's not
acceptable...


On Mon, Oct 14, 2013 at 9:47 PM, John Levine <johnl at iecc.com> wrote:

> >Is there any reason other than email where clients might demand RDNS?
>
> There's a few other protocols that want rDNS on the servers.  IRC maybe.
>
> Doing rDNS on random hosts in IPv6 would be very hard.  Servers are
> configured with static addresses which you can put in the DNS and
> rDNS, but normal user machines do SLAAC where the low 64 bits of the
> address are quasi-random.  To get any sort of DNS you'd need for the
> routers to watch when new hosts come on line and somehow tell the
> relevant DNS servers what hosts need names.
>
> This would be a lot of work, so nobody does it.
>
> R's,
> John
>
>

From bzs at world.std.com  Tue Oct 15 03:01:23 2013
From: bzs at world.std.com (Barry Shein)
Date: Mon, 14 Oct 2013 23:01:23 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <20131015024711.55297.qmail@joyce.lan>
References: <21084.42297.500255.50772@world.std.com>
 <20131015024711.55297.qmail@joyce.lan>
Message-ID: <21084.45059.73694.712636@world.std.com>


>This would be a lot of work, so nobody does it.

If someone asks for the rdns for:

   2001:0db8:85a3:0042:1000:8a2e:0370:7334

it's a lot of work for example.com to return something like:

   2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com

?

What it means, exactly, is a different discussion. But when asked the
question that would be an answer and it could more or less be
generated with a single printf().

    -b


From mysidia at gmail.com  Tue Oct 15 03:18:15 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 14 Oct 2013 22:18:15 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <21084.45059.73694.712636@world.std.com>
References: <21084.42297.500255.50772@world.std.com>
 <20131015024711.55297.qmail@joyce.lan>
 <21084.45059.73694.712636@world.std.com>
Message-ID: <CAAAwwbW5ZFTzEJskXcGmRpPZuT0y=jA02cwOX1wkUzJa2+mUoQ@mail.gmail.com>

On Mon, Oct 14, 2013 at 10:01 PM, Barry Shein <bzs at world.std.com> wrote:


> >This would be a lot of work, so nobody does it.
> >If someone asks for the rdns for:
>   >  2001:0db8:85a3:0042:1000:8a2e:0370:7334
> >it's a lot of work for example.com to return something like:
> >   2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com
> >?
>
>
No... it's not a lot of work;   the problem is,  it's maybe worth  even
less than the amount of work involved though.

What piece of information is being expressed there that would not be
 expressed by a NXDOMAIN response?

Assuming the user is residential  ".example.com"   pertains to the ISP,
 not the hostname at that IP address. The ISP's info    is accessible via
services such as WHOIS-RWS


How about some  wildcard PTR record ?

*.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa     PTR     unnamedhost.example.com.

 It's equally useless; and conveys equally limited information about the
host.

However, at least it doesn't generate spurious records  that are just  (IP
repeated).(domain)

-- 
-JH

From johnl at iecc.com  Tue Oct 15 03:31:43 2013
From: johnl at iecc.com (John Levine)
Date: 15 Oct 2013 03:31:43 -0000
Subject: comcast ipv6 PTR
In-Reply-To: <21084.45059.73694.712636@world.std.com>
Message-ID: <20131015033143.11379.qmail@joyce.lan>

>it's a lot of work for example.com to return something like:
>
>   2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com

Add some NSEC3 records and, yeah, it's a lot of work.  And for what?



From bmanning at vacation.karoshi.com  Tue Oct 15 03:45:05 2013
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 15 Oct 2013 03:45:05 +0000
Subject: comcast ipv6 PTR - DNSSEC
In-Reply-To: <CAAAwwbW5ZFTzEJskXcGmRpPZuT0y=jA02cwOX1wkUzJa2+mUoQ@mail.gmail.com>
References: <21084.42297.500255.50772@world.std.com>
 <20131015024711.55297.qmail@joyce.lan>
 <21084.45059.73694.712636@world.std.com>
 <CAAAwwbW5ZFTzEJskXcGmRpPZuT0y=jA02cwOX1wkUzJa2+mUoQ@mail.gmail.com>
Message-ID: <20131015034505.GB26360@vacation.karoshi.com.>

On Mon, Oct 14, 2013 at 10:18:15PM -0500, Jimmy Hess wrote:
> On Mon, Oct 14, 2013 at 10:01 PM, Barry Shein <bzs at world.std.com> wrote:
> 
> 
> > >This would be a lot of work, so nobody does it.
> > >If someone asks for the rdns for:
> >   >  2001:0db8:85a3:0042:1000:8a2e:0370:7334
> > >it's a lot of work for example.com to return something like:
> > >   2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com
> > >?
> >
> >
> No... it's not a lot of work;   the problem is,  it's maybe worth  even
> less than the amount of work involved though.
> 
> What piece of information is being expressed there that would not be
>  expressed by a NXDOMAIN response?
> 
> Assuming the user is residential  ".example.com"   pertains to the ISP,
>  not the hostname at that IP address. The ISP's info    is accessible via
> services such as WHOIS-RWS
> 
> 
> How about some  wildcard PTR record ?
> 
> *.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa     PTR     unnamedhost.example.com.
> 
>  It's equally useless; and conveys equally limited information about the
> host.
> 
> However, at least it doesn't generate spurious records  that are just  (IP
> repeated).(domain)
> 
> -- 
> -JH


	Forward domains and Reverse domains are often managed by different 
	organizations - so if you were a paranoid validator, wanting to check 
	that the name was from the correct place, you'd want to do DNSSEC 
	validation on both the name and the address.

	Not going to weigh in on the value proposition.


/bill


From marka at isc.org  Tue Oct 15 04:54:40 2013
From: marka at isc.org (Mark Andrews)
Date: Tue, 15 Oct 2013 15:54:40 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "15 Oct 2013 02:47:11 -0000."
 <20131015024711.55297.qmail@joyce.lan>
References: <20131015024711.55297.qmail@joyce.lan>
Message-ID: <20131015045441.5C356832A5E@rock.dv.isc.org>


In message <20131015024711.55297.qmail at joyce.lan>, "John Levine" writes:
> >Is there any reason other than email where clients might demand RDNS?
> 
> There's a few other protocols that want rDNS on the servers.  IRC maybe.
> 
> Doing rDNS on random hosts in IPv6 would be very hard.  Servers are
> configured with static addresses which you can put in the DNS and
> rDNS, but normal user machines do SLAAC where the low 64 bits of the
> address are quasi-random.  To get any sort of DNS you'd need for the
> routers to watch when new hosts come on line and somehow tell the
> relevant DNS servers what hosts need names.
> 
> This would be a lot of work, so nobody does it.

Actually you just need to *let* the hosts update their own ptr
records using UPDATE.

People keep saying the PTR records don't mean anything yet still
demand really strong authentication for updates of PTR records.
TCP is more than a strong enough authenticator to support update
from self.

You can even delegate the reverse zone when doing or just after a PD.

* Accept NS/DNAME updates for the reverse prefix from any address
  in the delegated address range over TCP.  This avoids having a
  temporatially lame delegation.  named already has code to do this
  for /48's as I coded it to to support 6to4.

* Extend DHCPv6 to support delegations (NS or DNAME) relayed via
  the DHCP server as part of the PD.  NS records would result in a
  temporarially lame delegation until the zone is configured in the
  nameserver.

Either of these moves the UPDATE traffic from the ISP's server to the
customers servers.

Mark

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


From dougb at dougbarton.us  Tue Oct 15 06:57:51 2013
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 14 Oct 2013 23:57:51 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <20131015024711.55297.qmail@joyce.lan>
References: <20131015024711.55297.qmail@joyce.lan>
Message-ID: <525CE76F.9010101@dougbarton.us>

On 10/14/2013 07:47 PM, John Levine wrote:
> Doing rDNS on random hosts in IPv6 would be very hard.

*	PTR	generic.reverse.record.isp.net.

can we move on now?


From Lee at asgard.org  Tue Oct 15 08:32:02 2013
From: Lee at asgard.org (Lee Howard)
Date: Tue, 15 Oct 2013 09:32:02 +0100
Subject: comcast ipv6 PTR
In-Reply-To: <20131015045441.5C356832A5E@rock.dv.isc.org>
Message-ID: <CE82B9DD.331C2%Lee@asgard.org>



On 10/15/13 7:54 AM, "Mark Andrews" <marka at isc.org> wrote:

>
>In message <20131015024711.55297.qmail at joyce.lan>, "John Levine" writes:
>> >Is there any reason other than email where clients might demand RDNS?
>> 
>> There's a few other protocols that want rDNS on the servers.  IRC maybe.
>> 
>> Doing rDNS on random hosts in IPv6 would be very hard.  Servers are
>> configured with static addresses which you can put in the DNS and
>> rDNS, but normal user machines do SLAAC where the low 64 bits of the
>> address are quasi-random.  To get any sort of DNS you'd need for the
>> routers to watch when new hosts come on line and somehow tell the
>> relevant DNS servers what hosts need names.
>> 
>> This would be a lot of work, so nobody does it.
>
>Actually you just need to *let* the hosts update their own ptr
>records using UPDATE.

Cool. How do I tell a residential device what name server they should send
updates to?
Remember that the ISP uses DHCPv6 or PPPoE or TR-069 to send configuration
information to the CPE, which sends DHCPv6 or RA to hosts.  "Hosts" may be
computers, tablets, game consoles, phones, TVs, or other.

>
>People keep saying the PTR records don't mean anything yet still
>demand really strong authentication for updates of PTR records.
>TCP is more than a strong enough authenticator to support update
>from self.

Dynamic DNS uses TCP?  I didn't realize that.

>
>You can even delegate the reverse zone when doing or just after a PD.

To a home router?  How do you tell the home router that it is now
authoritative for the reverse zone?

>
>* Extend DHCPv6 to support delegations (NS or DNAME) relayed via
>  the DHCP server as part of the PD.  NS records would result in a
>  temporarially lame delegation until the zone is configured in the
>  nameserver.

Let me know when you need me to express support for your draft being
adopted by dhc WG.
Until that feature is implemented, it is of limited operational utility.


>
>Mark

Lee




From jabley at hopcount.ca  Tue Oct 15 11:08:28 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Tue, 15 Oct 2013 07:08:28 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <CE82B9DD.331C2%Lee@asgard.org>
References: <CE82B9DD.331C2%Lee@asgard.org>
Message-ID: <54B1C067-1DD1-4618-AC0E-89EE5AB3E154@hopcount.ca>

Hi Lee,

I can tell it has been a long weekend here; I find myself agreeing with Mark Andrews.

On 2013-10-15, at 04:32, Lee Howard <Lee at asgard.org> wrote:

> On 10/15/13 7:54 AM, "Mark Andrews" <marka at isc.org> wrote:
> 
>> Actually you just need to *let* the hosts update their own ptr
>> records using UPDATE.
> 
> Cool. How do I tell a residential device what name server they should send
> updates to?

The device can discover the lowest zone cut for a particular owner name, and extract the MAME from the corresponding SOA.

> Remember that the ISP uses DHCPv6 or PPPoE or TR-069 to send configuration
> information to the CPE, which sends DHCPv6 or RA to hosts.  "Hosts" may be
> computers, tablets, game consoles, phones, TVs, or other.

Yes.

>> People keep saying the PTR records don't mean anything yet still
>> demand really strong authentication for updates of PTR records.
>> TCP is more than a strong enough authenticator to support update
>> from self.
> 
> Dynamic DNS uses TCP?  I didn't realize that.

DNS can use TCP. DNS UPDATE can use TCP.

>> You can even delegate the reverse zone when doing or just after a PD.
> 
> To a home router?  How do you tell the home router that it is now
> authoritative for the reverse zone?

The device can discover that itself by looking for a delegation to itself, knowing the owner name.

>> * Extend DHCPv6 to support delegations (NS or DNAME) relayed via
>> the DHCP server as part of the PD.  NS records would result in a
>> temporarially lame delegation until the zone is configured in the
>> nameserver.
> 
> Let me know when you need me to express support for your draft being
> adopted by dhc WG.
> Until that feature is implemented, it is of limited operational utility.

There's no protocol work required for any of this in the IETF. All that is required is agreement between access providers and home gateway vendors. Home gateways already need an overhaul to stop them spraying DNS responses received on the WAN port all over the Internet, so might as well take care of this at the same time.

(If I've woken up to a world where the presence or absence of an IETF BCP makes a difference to anybody in this context, then let's ditch this topic and move straight to BCP38. We can talk after that.)


Joe

From cma at cmadams.net  Tue Oct 15 13:20:01 2013
From: cma at cmadams.net (Chris Adams)
Date: Tue, 15 Oct 2013 08:20:01 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <CAA5Ek4eQy8VE-mM9ZKUZghr5Rc9F1Jaw01RE4Lr0d=x5FPt9LQ@mail.gmail.com>
References: <21084.42297.500255.50772@world.std.com>
 <20131015024711.55297.qmail@joyce.lan>
 <CAA5Ek4eQy8VE-mM9ZKUZghr5Rc9F1Jaw01RE4Lr0d=x5FPt9LQ@mail.gmail.com>
Message-ID: <20131015132001.GA15703@cmadams.net>

Once upon a time, Blair Trosper <blair.trosper at gmail.com> said:
> That gets to the core of the original question.  I figured there must be a
> reason for the conscious omission.  However, I've noticed also that Comcast
> hasn't bothered to give PTR to their routers, either.

I have a Comcast residential circuit with IPv6, and I see reverse DNS
for router hops past the first device.
-- 
Chris Adams <cma at cmadams.net>


From johnl at iecc.com  Tue Oct 15 14:26:14 2013
From: johnl at iecc.com (John R. Levine)
Date: Tue, 15 Oct 2013 10:26:14 -0400 (EDT)
Subject: comcast ipv6 PTR
In-Reply-To: <20131015045441.5C356832A5E@rock.dv.isc.org>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
Message-ID: <alpine.BSF.2.00.1310151010530.89737@joyce.lan>

> Actually you just need to *let* the hosts update their own ptr
> records using UPDATE.

Um, Mark, forward records too.

And I have to say the idea of delegating rDNS for 50 million consumers to 
50 million consumer something or others is simultaneously pretty amusing 
and pretty horrifying.

My cable company assigns me a different prefix every time the modem 
reboots, about once a month, and I think that's pretty typical.

R's,
John


From johnl at iecc.com  Tue Oct 15 14:35:54 2013
From: johnl at iecc.com (John R. Levine)
Date: Tue, 15 Oct 2013 10:35:54 -0400 (EDT)
Subject: comcast ipv6 PTR
In-Reply-To: <54B1C067-1DD1-4618-AC0E-89EE5AB3E154@hopcount.ca>
References: <CE82B9DD.331C2%Lee@asgard.org>
 <54B1C067-1DD1-4618-AC0E-89EE5AB3E154@hopcount.ca>
Message-ID: <alpine.BSF.2.00.1310151035270.89737@joyce.lan>

> I can tell it has been a long weekend here; I find myself agreeing with Mark Andrews.

Where do the forward records for these random devices come from?

Signed,
Confused


From jabley at hopcount.ca  Tue Oct 15 14:40:22 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Tue, 15 Oct 2013 10:40:22 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <alpine.BSF.2.00.1310151035270.89737@joyce.lan>
References: <CE82B9DD.331C2%Lee@asgard.org>
 <54B1C067-1DD1-4618-AC0E-89EE5AB3E154@hopcount.ca>
 <alpine.BSF.2.00.1310151035270.89737@joyce.lan>
Message-ID: <80F4110F-2302-4552-8B49-68B2763DEF4E@hopcount.ca>


On 2013-10-15, at 10:35, "John R. Levine" <johnl at iecc.com> wrote:

>> I can tell it has been a long weekend here; I find myself agreeing with Mark Andrews.
> 
> Where do the forward records for these random devices come from?

From a domain name typed into a configuration panel on the home gateway, updated in the same manner (find the zone cut, find the MNAME, send a DNS UPDATE)?

Presumably if a domain name is not specified, no DNS UPDATEs occur.

I'm not commenting on the need or proper desire to have matching PTR/AAAA records for the addresses at the provider edge, I'm just saying that the mechanism Mark described seems plausible.


Joe

From johnl at iecc.com  Tue Oct 15 14:44:31 2013
From: johnl at iecc.com (John R. Levine)
Date: Tue, 15 Oct 2013 10:44:31 -0400 (EDT)
Subject: comcast ipv6 PTR
In-Reply-To: <80F4110F-2302-4552-8B49-68B2763DEF4E@hopcount.ca>
References: <CE82B9DD.331C2%Lee@asgard.org>
 <54B1C067-1DD1-4618-AC0E-89EE5AB3E154@hopcount.ca>
 <alpine.BSF.2.00.1310151035270.89737@joyce.lan>
 <80F4110F-2302-4552-8B49-68B2763DEF4E@hopcount.ca>
Message-ID: <alpine.BSF.2.00.1310151044070.91804@joyce.lan>

>> Where do the forward records for these random devices come from?
>
> From a domain name typed into a configuration panel on the home gateway, updated in the same manner (find the zone cut, find the MNAME, send a DNS UPDATE)?

Hmmn.  Seems like a security disaster waiting to happen, but I see how the 
pices could work.  Tnx.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From bruns at 2mbit.com  Tue Oct 15 14:51:12 2013
From: bruns at 2mbit.com (Brielle Bruns)
Date: Tue, 15 Oct 2013 08:51:12 -0600
Subject: comcast ipv6 PTR
In-Reply-To: <20131015132001.GA15703@cmadams.net>
References: <21084.42297.500255.50772@world.std.com>
 <20131015024711.55297.qmail@joyce.lan>
 <CAA5Ek4eQy8VE-mM9ZKUZghr5Rc9F1Jaw01RE4Lr0d=x5FPt9LQ@mail.gmail.com>
 <20131015132001.GA15703@cmadams.net>
Message-ID: <E1074CBC-0E97-4C7D-8AEE-1A672F019F9D@2mbit.com>

Sent from my iPhone so be gentle about formatting errors.

On Oct 15, 2013, at 7:20 AM, Chris Adams <cma at cmadams.net> wrote:

> Once upon a time, Blair Trosper <blair.trosper at gmail.com> said:
>> That gets to the core of the original question.  I figured there must be a
>> reason for the conscious omission.  However, I've noticed also that Comcast
>> hasn't bothered to give PTR to their routers, either.
> 
> I have a Comcast residential circuit with IPv6, and I see reverse DNS
> for router hops past the first device.
> -- 

CenturyLink offers 6rd to both residential customers and business, but no way to set RDNS on the individual /64 or /48s assigned to each static ipv4 address the customer has.  Rather huge omission, IMHO.

I got bit by this bad when !$@& google started outright rejecting email from ipv6 addresses with no RDNS.

Yay exim for allowing me to tag broken remote smtp servers to only use ipv4.

Brielle

From tim at pelican.org  Tue Oct 15 14:55:27 2013
From: tim at pelican.org (Tim Franklin)
Date: Tue, 15 Oct 2013 15:55:27 +0100 (BST)
Subject: comcast ipv6 PTR
In-Reply-To: <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
Message-ID: <1779948625.4431.1381848927217.JavaMail.zimbra@pelican.org>

> My cable company assigns me a different prefix every time the modem
> reboots, about once a month, and I think that's pretty typical.

Seems pretty dismal to me.  Wasn't a big win of IPv6 supposed to be that we could do things over without making all the same stupid mistakes we made in IPv4?  Dynamic IPv4 assignment was always a hang-over from dial-up days when $ADDRESS_POOL_SIZE == $MODEM_POOL_SIZE < $SUBSCRIBER_BASE, coupled eventually with a restricted supply of addresses.  We insisted on dragging it into the broadband world where the number of active connections is pretty much 1:1 with the number of paying subscribers; must we really drag the same old baggage into the IPv6 future?

Regards,
Tim.
 


From bjorn at mork.no  Tue Oct 15 14:57:04 2013
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 15 Oct 2013 16:57:04 +0200
Subject: comcast ipv6 PTR
In-Reply-To: <20131015045441.5C356832A5E@rock.dv.isc.org> (Mark Andrews's
 message of "Tue, 15 Oct 2013 15:54:40 +1100")
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
Message-ID: <8738o2poov.fsf@nemi.mork.no>

Mark Andrews <marka at isc.org> writes:

> Actually you just need to *let* the hosts update their own ptr
> records using UPDATE.
>
> People keep saying the PTR records don't mean anything yet still
> demand really strong authentication for updates of PTR records.
> TCP is more than a strong enough authenticator to support update
> from self.
>
> You can even delegate the reverse zone when doing or just after a PD.
>
> * Accept NS/DNAME updates for the reverse prefix from any address
>   in the delegated address range over TCP.  This avoids having a
>   temporatially lame delegation.  named already has code to do this
>   for /48's as I coded it to to support 6to4.

This sounded like an excellent idea at first, but then I started
thinking:  As a home user, would I really want to give anyone with
access to my network the right to change my reverse delegation?

I don't think so.  I am not even sure I would want them all to be able
to update the PTR record for the addresses they use.



Bj?rn


From bjorn at mork.no  Tue Oct 15 14:59:34 2013
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 15 Oct 2013 16:59:34 +0200
Subject: comcast ipv6 PTR
In-Reply-To: <525CE76F.9010101@dougbarton.us> (Doug Barton's message of "Mon, 
 14 Oct 2013 23:57:51 -0700")
References: <20131015024711.55297.qmail@joyce.lan>
 <525CE76F.9010101@dougbarton.us>
Message-ID: <87y55uoa09.fsf@nemi.mork.no>

Doug Barton <dougb at dougbarton.us> writes:
> On 10/14/2013 07:47 PM, John Levine wrote:
>> Doing rDNS on random hosts in IPv6 would be very hard.
>
> *	PTR	generic.reverse.record.isp.net.
>
> can we move on now?

Sure. If you can explain how that is going to resolve forward.


Bj?rn


From bruns at 2mbit.com  Tue Oct 15 15:06:06 2013
From: bruns at 2mbit.com (Brielle Bruns)
Date: Tue, 15 Oct 2013 09:06:06 -0600
Subject: comcast ipv6 PTR
In-Reply-To: <87y55uoa09.fsf@nemi.mork.no>
References: <20131015024711.55297.qmail@joyce.lan>
 <525CE76F.9010101@dougbarton.us> <87y55uoa09.fsf@nemi.mork.no>
Message-ID: <FE277981-F6A6-4589-AEF7-8454CC34A5E1@2mbit.com>

Sent from my iPhone

On Oct 15, 2013, at 8:59 AM, Bj?rn Mork <bjorn at mork.no> wrote:

> Doug Barton <dougb at dougbarton.us> writes:
>> On 10/14/2013 07:47 PM, John Levine wrote:
>>> Doing rDNS on random hosts in IPv6 would be very hard.
>> 
>> *    PTR    generic.reverse.record.isp.net.
>> 
>> can we move on now?
> 
> Sure. If you can explain how that is going to resolve forward.

Wildcard A records like have been done forever (even if not exactly recommended)?

From bruns at 2mbit.com  Tue Oct 15 15:11:38 2013
From: bruns at 2mbit.com (Brielle Bruns)
Date: Tue, 15 Oct 2013 09:11:38 -0600
Subject: comcast ipv6 PTR
In-Reply-To: <FE277981-F6A6-4589-AEF7-8454CC34A5E1@2mbit.com>
References: <20131015024711.55297.qmail@joyce.lan>
 <525CE76F.9010101@dougbarton.us> <87y55uoa09.fsf@nemi.mork.no>
 <FE277981-F6A6-4589-AEF7-8454CC34A5E1@2mbit.com>
Message-ID: <BF616320-EC71-4551-8AE4-B21FECC907F1@2mbit.com>

Er, right as I sent that I realized I'm getting a E_NOCOFFEE error and that only works on the name side of it, not on the address side.

In theory, you could do a *.rdns.isp.com and use something like the powerdns pipe backend to provide proper A record from 1.0.0.127.rdns.isp.com.

Sent from my iPhone

On Oct 15, 2013, at 9:06 AM, Brielle Bruns <bruns at 2mbit.com> wrote:

> Sent from my iPhone
> 
> On Oct 15, 2013, at 8:59 AM, Bj?rn Mork <bjorn at mork.no> wrote:
> 
>> Doug Barton <dougb at dougbarton.us> writes:
>>> On 10/14/2013 07:47 PM, John Levine wrote:
>>>> Doing rDNS on random hosts in IPv6 would be very hard.
>>> 
>>> *    PTR    generic.reverse.record.isp.net.
>>> 
>>> can we move on now?
>> 
>> Sure. If you can explain how that is going to resolve forward.
> 
> Wildcard A records like have been done forever (even if not exactly recommended)?


From jabley at hopcount.ca  Tue Oct 15 15:13:10 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Tue, 15 Oct 2013 11:13:10 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <8738o2poov.fsf@nemi.mork.no>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org> <8738o2poov.fsf@nemi.mork.no>
Message-ID: <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>


On 2013-10-15, at 10:57, Bj?rn Mork <bjorn at mork.no> wrote:

> Mark Andrews <marka at isc.org> writes:
> 
>> People keep saying the PTR records don't mean anything yet still
>> demand really strong authentication for updates of PTR records.
>> TCP is more than a strong enough authenticator to support update
>> from self.
> 
> This sounded like an excellent idea at first, but then I started
> thinking:  As a home user, would I really want to give anyone with
> access to my network the right to change my reverse delegation?

I think what you'd be doing is giving anybody you have assigned an IPv6 address to the ability to update the PTR (or a delegation, since Mark suggested that too) for that particular address.

So, it's not "my reverse delegation", it's "my 2^80 or fewer reverse delegations" (if you've been assigned a /48).


Joe



From asullivan at dyn.com  Tue Oct 15 15:14:09 2013
From: asullivan at dyn.com (Andrew Sullivan)
Date: Tue, 15 Oct 2013 11:14:09 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <CAA5Ek4eQy8VE-mM9ZKUZghr5Rc9F1Jaw01RE4Lr0d=x5FPt9LQ@mail.gmail.com>
References: <21084.42297.500255.50772@world.std.com>
 <20131015024711.55297.qmail@joyce.lan>
 <CAA5Ek4eQy8VE-mM9ZKUZghr5Rc9F1Jaw01RE4Lr0d=x5FPt9LQ@mail.gmail.com>
Message-ID: <20131015151408.GD60227@dyn.com>

On Mon, Oct 14, 2013 at 09:58:22PM -0500, Blair Trosper wrote:

> Leaving out v6 PTR on your core/backbone/edge routers?  Surely that's not
> acceptable...

As I think I said somewhere up-thread, there's really no consensus on
what is "acceptable" in reverse mapping.  The last time we tried to
get consensus, we couldn't even get it on the blandest draft possible.

Best,

A

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


From bjorn at mork.no  Tue Oct 15 15:18:11 2013
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 15 Oct 2013 17:18:11 +0200
Subject: comcast ipv6 PTR
In-Reply-To: <FE277981-F6A6-4589-AEF7-8454CC34A5E1@2mbit.com> (Brielle Bruns's
 message of "Tue, 15 Oct 2013 09:06:06 -0600")
References: <20131015024711.55297.qmail@joyce.lan>
 <525CE76F.9010101@dougbarton.us> <87y55uoa09.fsf@nemi.mork.no>
 <FE277981-F6A6-4589-AEF7-8454CC34A5E1@2mbit.com>
Message-ID: <87txgio958.fsf@nemi.mork.no>

Brielle Bruns <bruns at 2mbit.com> writes:

> Sent from my iPhone
>
> On Oct 15, 2013, at 8:59 AM, Bj?rn Mork <bjorn at mork.no> wrote:
>
>> Doug Barton <dougb at dougbarton.us> writes:
>>> On 10/14/2013 07:47 PM, John Levine wrote:
>>>> Doing rDNS on random hosts in IPv6 would be very hard.
>>> 
>>> *    PTR    generic.reverse.record.isp.net.
>>> 
>>> can we move on now?
>> 
>> Sure. If you can explain how that is going to resolve forward.
>
> Wildcard A records like have been done forever (even if not exactly recommended)?

Maybe.  Personally I put a lot more trust into an IPv6 address with no
PTR than an IPv6 address with a PTR not resolving back to the same
address.


Bj?rn


From trejrco at gmail.com  Tue Oct 15 15:35:49 2013
From: trejrco at gmail.com (TJ)
Date: Tue, 15 Oct 2013 11:35:49 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
Message-ID: <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>

>
>
> My cable company assigns me a different prefix every time the modem
> reboots, about once a month, and I think that's pretty typical.
>

Really?
I think my IPv6 address form Comcast has changed (maybe) twice in the last
18 months, and I think it was only once.


/TJ

From mike at mtcc.com  Tue Oct 15 15:52:23 2013
From: mike at mtcc.com (Michael Thomas)
Date: Tue, 15 Oct 2013 08:52:23 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
 <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>
Message-ID: <525D64B7.6080204@mtcc.com>

On 10/15/2013 08:35 AM, TJ wrote:
>>
>> My cable company assigns me a different prefix every time the modem
>> reboots, about once a month, and I think that's pretty typical.
>>
> Really?
> I think my IPv6 address form Comcast has changed (maybe) twice in the last
> 18 months, and I think it was only once.
>

There's an entire universe within ietf who thinks that seamless 
renumbering is
a Big Deal. We're obviously not completely there -- especially within 
residential --
but any path forward should not count on the stability of prefixes. 
Anywhere.

Mike


From bjorn at mork.no  Tue Oct 15 16:20:40 2013
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 15 Oct 2013 18:20:40 +0200
Subject: comcast ipv6 PTR
In-Reply-To: <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca> (Joe Abley's
 message of "Tue, 15 Oct 2013 11:13:10 -0400")
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <8738o2poov.fsf@nemi.mork.no>
 <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>
Message-ID: <87mwmao693.fsf@nemi.mork.no>

Joe Abley <jabley at hopcount.ca> writes:
> On 2013-10-15, at 10:57, Bj?rn Mork <bjorn at mork.no> wrote:
>> Mark Andrews <marka at isc.org> writes:
>> 
>>> People keep saying the PTR records don't mean anything yet still
>>> demand really strong authentication for updates of PTR records.
>>> TCP is more than a strong enough authenticator to support update
>>> from self.
>> 
>> This sounded like an excellent idea at first, but then I started
>> thinking:  As a home user, would I really want to give anyone with
>> access to my network the right to change my reverse delegation?
>
> I think what you'd be doing is giving anybody you have assigned an
> IPv6 address to the ability to update the PTR (or a delegation, since
> Mark suggested that too) for that particular address.
>
> So, it's not "my reverse delegation", it's "my 2^80 or fewer reverse
> delegations" (if you've been assigned a /48).

Ah, right.  I understood the proposal as "any address within then /48
can update the delegation for the /48 reverse".

But if that would be 2^80 distinct delegations or PTRs, then I am
worrying about luser stupidiy and the ability to DoS the name server.  I
guess this can be combined with some sort of limit, making it fly?
Still don't see the advantage of being able to delegate if it's only
single address delegations.  But allowing a limited number of PTR
updates based on TCP sounds like a nice idea.  Going to consider that.

For the full /48 delegation I don't see any other option than making it
part of a self service portal.  But the marketing/product droids usually
don't want that sort of "complex" techical stuff  for retail users.
Probably for good reasons...

In any case: All of you should expect legitimate, technical brilliant
users attempting to connect to your SMTP servers from IPv6 addresses
with no PTR records. This is not going to go away.  You are of course
free to refuse those connections, but personally I find a that rather
arrogant and pretty stupid decision.  The existence of a PTR record is
one of many factors to consider for your spam filter.  There never has
been any reason to make it an absolute requirement, and I am pretty sure
the score needs to be lowered with IPv6.


Bj?rn (yes, my mail server has a proper IPv6 reverse record, but that's
only because I am in a position to create the reverse delegation....)


From bruns at 2mbit.com  Tue Oct 15 16:37:32 2013
From: bruns at 2mbit.com (Brielle Bruns)
Date: Tue, 15 Oct 2013 10:37:32 -0600
Subject: comcast ipv6 PTR
In-Reply-To: <87mwmao693.fsf@nemi.mork.no>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org> <8738o2poov.fsf@nemi.mork.no>
 <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>
 <87mwmao693.fsf@nemi.mork.no>
Message-ID: <525D6F4C.3010605@2mbit.com>

On 10/15/13 10:20 AM, Bj?rn Mork wrote:
> In any case: All of you should expect legitimate, technical brilliant
> users attempting to connect to your SMTP servers from IPv6 addresses
> with no PTR records. This is not going to go away.  You are of course
> free to refuse those connections, but personally I find a that rather
> arrogant and pretty stupid decision.  The existence of a PTR record is
> one of many factors to consider for your spam filter.  There never has
> been any reason to make it an absolute requirement, and I am pretty sure
> the score needs to be lowered with IPv6.

Or, as an alternative, actually use the SPF records that multiple big 
companies keep telling people to make sure they have.

I have my SPF records set to allow my IPv6 and IPv4 senders, why are 
they ignoring that and going just for an outright reject on inbound ipv6 
mail?

At least, if its a defer, it has the chance to bounce over to one of my 
backup mail servers that doesn't have IPv6 (or in one case, has a mail 
server out of my directly assigned from ARIN /48 with working rdns).


-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org


From joelja at bogus.com  Tue Oct 15 16:46:32 2013
From: joelja at bogus.com (joel jaeggli)
Date: Tue, 15 Oct 2013 09:46:32 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
Message-ID: <574B5044-E7C5-4EF0-AC67-BE1F3E5EE105@bogus.com>


On Oct 15, 2013, at 7:26 AM, John R. Levine <johnl at iecc.com> wrote:

>> Actually you just need to *let* the hosts update their own ptr
>> records using UPDATE.
> 

I don't think that any host out there should be updating the PTR record associated with the privacy address it's using for outgoing connections. if the provider the prefix is delgated to respond with a genric RR well fine. but I doubt very much that there would be any circumstances where you'd want hosts doing PTR updates for addresses they're only using because their slaac address is a form of information leakage.

> Um, Mark, forward records too.
> 
> And I have to say the idea of delegating rDNS for 50 million consumers to 50 million consumer something or others is simultaneously pretty amusing and pretty horrifying.
> 
> My cable company assigns me a different prefix every time the modem reboots, about once a month, and I think that's pretty typical.
> 
> R's,
> John
> 

-------------- 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/20131015/7c333830/attachment.bin>

From bjorn at mork.no  Tue Oct 15 16:48:32 2013
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 15 Oct 2013 18:48:32 +0200
Subject: comcast ipv6 PTR
In-Reply-To: <525D64B7.6080204@mtcc.com> (Michael Thomas's message of "Tue, 15
 Oct 2013 08:52:23 -0700")
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
 <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>
 <525D64B7.6080204@mtcc.com>
Message-ID: <87iowyo4yn.fsf@nemi.mork.no>

Michael Thomas <mike at mtcc.com> writes:
> On 10/15/2013 08:35 AM, TJ wrote:
>>>
>>> My cable company assigns me a different prefix every time the modem
>>> reboots, about once a month, and I think that's pretty typical.
>>>
>> Really?
>> I think my IPv6 address form Comcast has changed (maybe) twice in the last
>> 18 months, and I think it was only once.
>>
>
> There's an entire universe within ietf who thinks that seamless
> renumbering is
> a Big Deal. We're obviously not completely there -- especially within
> residential --
> but any path forward should not count on the stability of
> prefixes. Anywhere.

Agreed.

We will allocate semi-static prefixes, but have decided to do strict
aggregation of retail subscriber prefixes on the BNGs. This means that
the allocations will be perceived as static by most users, but there are
no guarantees. We will renumber if the users move between BNGs,
regardless of reason.  Including moving DSLAMs/OLTs.

Having said that: Renumbering is not going to be seemless, even for
simple home networks.  The last time I changed my home prefix, I
completely forgot that I had put the old one into a cups access list.
Took me a while to figure out why I couldn't make the printer work a
month or so later...

Typical static entries being added over time are:
 - DNS glue
 - access lists, both in your network and in other networks
 - interface config on devices where you don't want SLAAC or DHCPv6
 - server application configuration (you do want your mail server to use
   a specific source address and not just choose one, right?)
 + everything I forgot

No, renumbering is not going to be seemless.  Yes, a smarter person
could automate everything I list above, but we all know that's not going
to happen.


Bj?rn


From Jean-Francois.TremblayING at videotron.com  Tue Oct 15 17:40:39 2013
From: Jean-Francois.TremblayING at videotron.com (Jean-Francois.TremblayING at videotron.com)
Date: Tue, 15 Oct 2013 13:40:39 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
 <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>
Message-ID: <OFFA7CE405.B49135E4-ON85257C05.005FB76D-85257C05.00611B80@videotron.com>

> > My cable company assigns me a different prefix every time the modem
> > reboots, about once a month, and I think that's pretty typical.
>
> Really?
> I think my IPv6 address form Comcast has changed (maybe) twice in the 
last
> 18 months, and I think it was only once.

Could it be a non-persistent DUID on the CPE maybe? It tends to get more 
rare as home router implementors get their IPv6 right, but we still see 
some in the wild. (it makes an interesting attack vector also...) 

/JF


From bzs at world.std.com  Tue Oct 15 18:31:12 2013
From: bzs at world.std.com (Barry Shein)
Date: Tue, 15 Oct 2013 14:31:12 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <20131015033143.11379.qmail@joyce.lan>
References: <21084.45059.73694.712636@world.std.com>
 <20131015033143.11379.qmail@joyce.lan>
Message-ID: <21085.35312.817571.962150@world.std.com>


On October 15, 2013 at 03:31 johnl at iecc.com (John Levine) wrote:
 > >it's a lot of work for example.com to return something like:
 > >
 > >   2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com
 > 
 > Add some NSEC3 records and, yeah, it's a lot of work.  And for what?

Many mail servers require it as a minimum standard for speaking to
their MTA.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From bzs at world.std.com  Tue Oct 15 18:32:48 2013
From: bzs at world.std.com (Barry Shein)
Date: Tue, 15 Oct 2013 14:32:48 -0400
Subject: comcast ipv6 PTR - DNSSEC
In-Reply-To: <20131015034505.GB26360@vacation.karoshi.com.>
References: <21084.42297.500255.50772@world.std.com>
 <20131015024711.55297.qmail@joyce.lan>
 <21084.45059.73694.712636@world.std.com>
 <CAAAwwbW5ZFTzEJskXcGmRpPZuT0y=jA02cwOX1wkUzJa2+mUoQ@mail.gmail.com>
 <20131015034505.GB26360@vacation.karoshi.com.>
Message-ID: <21085.35408.908777.452626@world.std.com>


On October 15, 2013 at 03:45 bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) wrote:
 > 
 > 	Forward domains and Reverse domains are often managed by different 
 > 	organizations - so if you were a paranoid validator, wanting to check 
 > 	that the name was from the correct place, you'd want to do DNSSEC 
 > 	validation on both the name and the address.
 > 
 > 	Not going to weigh in on the value proposition.

Unless, as is frequently the case, the only test is: NXDOMAIN? Reject,
Anything but NXDOMAIN? Accept.


-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From bzs at world.std.com  Tue Oct 15 18:30:03 2013
From: bzs at world.std.com (Barry Shein)
Date: Tue, 15 Oct 2013 14:30:03 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <CAAAwwbW5ZFTzEJskXcGmRpPZuT0y=jA02cwOX1wkUzJa2+mUoQ@mail.gmail.com>
References: <21084.42297.500255.50772@world.std.com>
 <20131015024711.55297.qmail@joyce.lan>
 <21084.45059.73694.712636@world.std.com>
 <CAAAwwbW5ZFTzEJskXcGmRpPZuT0y=jA02cwOX1wkUzJa2+mUoQ@mail.gmail.com>
Message-ID: <21085.35243.958248.452552@world.std.com>


On October 14, 2013 at 22:18 mysidia at gmail.com (Jimmy Hess) wrote:
 > On Mon, Oct 14, 2013 at 10:01 PM, Barry Shein <bzs at world.std.com> wrote:
 > 
 > 
 > > >   2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com
 > > >?
 > >
 > >
 > No... it's not a lot of work;   the problem is,  it's maybe worth  even
 > less than the amount of work involved though.
 > 
 > What piece of information is being expressed there that would not be
 >  expressed by a NXDOMAIN response?

That your host won't be rejected, typically by email servers, in an
RDNS check.

It's a little strange in a way, the very existence of an RDNS response
has become a policy trigger, no matter what it is.

 > Assuming the user is residential  ".example.com"   pertains to the ISP,
 >  not the hostname at that IP address. The ISP's info    is accessible via
 > services such as WHOIS-RWS
 > 
 > 
 > How about some  wildcard PTR record ?
 > 
 > *.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa     PTR     unnamedhost.example.com.
 > 
 >  It's equally useless; and conveys equally limited information about the
 > host.

That really depends on what you believe is useless (or useful.)

If it lets the client send email to AOL (as one example) that might be
useful.

The information it conveys is that this IP address merits an RDNS
response for some reason, and policy is determined on that fact.

 > However, at least it doesn't generate spurious records  that are just  (IP
 > repeated).(domain)

Well, as I said, you're setting a different standard, that the host
name returned in an RDNS query be of some meaning to a human or
possibly a program.

Its mere existence is considered very meaningful on the net, whatever
it is.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From bzs at world.std.com  Tue Oct 15 18:40:22 2013
From: bzs at world.std.com (Barry Shein)
Date: Tue, 15 Oct 2013 14:40:22 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <20131015045441.5C356832A5E@rock.dv.isc.org>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
Message-ID: <21085.35862.604004.561849@world.std.com>


On October 15, 2013 at 15:54 marka at isc.org (Mark Andrews) wrote:
 > 
 > Actually you just need to *let* the hosts update their own ptr
 > records using UPDATE.

Well, that's an interesting proposal and worthwhile considering.

I proposed something vaguely similar vis a vis WHOIS recently (it's
not entirely original with me), just put it a URL (or similar) in an
RR which when queried will return whatever WHOIS info the owner of the
domain wants to return, including nothing. Something like:

      IN RRR  http://www.example.com/whois

where RRR is TBD. Could even be a mailto, for example, or anything,
the info in place even if it's brief.

Someone back I think in 2001 proposed using the SRV RR for this, it's
maybe a little awkward in format but same idea basically.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From cma at cmadams.net  Tue Oct 15 18:55:50 2013
From: cma at cmadams.net (Chris Adams)
Date: Tue, 15 Oct 2013 13:55:50 -0500
Subject: comcast ipv6 PTR
In-Reply-To: <21085.35312.817571.962150@world.std.com>
References: <21084.45059.73694.712636@world.std.com>
 <20131015033143.11379.qmail@joyce.lan>
 <21085.35312.817571.962150@world.std.com>
Message-ID: <20131015185550.GF15703@cmadams.net>

Once upon a time, Barry Shein <bzs at world.std.com> said:
> 
> On October 15, 2013 at 03:31 johnl at iecc.com (John Levine) wrote:
>  > >it's a lot of work for example.com to return something like:
>  > >
>  > >   2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com
>  > 
>  > Add some NSEC3 records and, yeah, it's a lot of work.  And for what?
> 
> Many mail servers require it as a minimum standard for speaking to
> their MTA.

Random end users shouldn't be talking to MTAs.  They should be using
MSAs instead.
-- 
Chris Adams <cma at cmadams.net>


From mike at mtcc.com  Tue Oct 15 19:01:38 2013
From: mike at mtcc.com (Michael Thomas)
Date: Tue, 15 Oct 2013 12:01:38 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <87iowyo4yn.fsf@nemi.mork.no>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
 <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>
 <525D64B7.6080204@mtcc.com> <87iowyo4yn.fsf@nemi.mork.no>
Message-ID: <525D9112.2000107@mtcc.com>

On 10/15/13 9:48 AM, Bj?rn Mork wrote:
> Michael Thomas <mike at mtcc.com> writes:
>
> Typical static entries being added over time are:
>   - DNS glue
>   - access lists, both in your network and in other networks
>   - interface config on devices where you don't want SLAAC or DHCPv6
>   - server application configuration (you do want your mail server to use
>     a specific source address and not just choose one, right?)
>   + everything I forgot
>
> No, renumbering is not going to be seemless.  Yes, a smarter person
> could automate everything I list above, but we all know that's not going
> to happen.
>
I've always been something of a skeptic how seams "seamless" will actually have :)
But there has been a tremendous amount of effort in the v6 world to make renumbering
a first class citizen. In the mean time, if we do nothing else be keep track of where all
of those pesky ip address bearing files are, we can at least keep throwing them over the
wall to the ietf as to what they expect us to do with them.

Mike


From eugen at leitl.org  Tue Oct 15 19:09:57 2013
From: eugen at leitl.org (Eugen Leitl)
Date: Tue, 15 Oct 2013 21:09:57 +0200
Subject: comcast ipv6 PTR
In-Reply-To: <20131015185550.GF15703@cmadams.net>
References: <21084.45059.73694.712636@world.std.com>
 <20131015033143.11379.qmail@joyce.lan>
 <21085.35312.817571.962150@world.std.com>
 <20131015185550.GF15703@cmadams.net>
Message-ID: <20131015190957.GT10405@leitl.org>

On Tue, Oct 15, 2013 at 01:55:50PM -0500, Chris Adams wrote:

> > Many mail servers require it as a minimum standard for speaking to
> > their MTA.
> 
> Random end users shouldn't be talking to MTAs.  They should be using
> MSAs instead.

Given what TLAs have been caught doing lately, end users should be 
*encouraged* to run their own MTAs.


From bzs at world.std.com  Tue Oct 15 19:48:09 2013
From: bzs at world.std.com (Barry Shein)
Date: Tue, 15 Oct 2013 15:48:09 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <20131015185550.GF15703@cmadams.net>
References: <21084.45059.73694.712636@world.std.com>
 <20131015033143.11379.qmail@joyce.lan>
 <21085.35312.817571.962150@world.std.com>
 <20131015185550.GF15703@cmadams.net>
Message-ID: <21085.39929.583898.593889@world.std.com>


On October 15, 2013 at 13:55 cma at cmadams.net (Chris Adams) wrote:
 > 
 > Random end users shouldn't be talking to MTAs.  They should be using
 > MSAs instead.

That's a policy decision, some allow this, some resist it.

It's too bad that we've created this exclusive club of the anointed
who may speak to MTAs just because of some bad actors. It's not like
the basic idea is particularly a bad one.

An ideal I'd prefer is get rid of the botnets and similar through
other means, improving client technology and increasing the likelihood
of arrest of those who exploit them for example.

What's occurring is that the same factors which led to the mass
spammers is now, more and more, drawing in what might be termed
"legitimate" businesses. And we're tending to use our sense of social
class to distinguish which is which, not (IMHO) a good trend.

But what business can resist the siren call of postage-free (i.e.,
nearly free) marcom with their customers?

Particularly where there are millions of customers. Talk to them every
day, twice a day, ten times a day! Whatever it takes, apply for this
credit card, donate to this worthy cause, lowest prices on vacations
in Maui, new book available...

The result?

I think people just ignore most email and tend towards very exclusive
whitelisting one way or another (human or scripted.) But what the
heck, it's free! Keep that bilge pump running.

MarCom too cheap to meter!

Now there's a policy issue.

It's gotten so you can barely hear the spam over the roar of the
("legitimate") marcom.


-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From quantumfoam at gmail.com  Tue Oct 15 19:56:33 2013
From: quantumfoam at gmail.com (Jonathan Rogers)
Date: Tue, 15 Oct 2013 15:56:33 -0400
Subject: Yahoo reporting "No MX or A Records" and bouncing emails
Message-ID: <CAC47Z9k9oLqbK2D-1uZ5vHP+uV8tNmKfSRFN1zAO5ofZ0LQxgA@mail.gmail.com>

Greetings Programs,

Yahoo is bouncing email that is being sent to a customer of mine with the
error that no MX or A records were found for the domain. There is nothing
wrong with the domain at all, which I have verified from multiple sources.

Does anyone have any suggestions about who I can reach out to at Yahoo to
get this matter resolved?

Many Thanks,

Jonathan Rogers
PCM, Inc

From rubensk at gmail.com  Tue Oct 15 20:00:35 2013
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 15 Oct 2013 17:00:35 -0300
Subject: Yahoo reporting "No MX or A Records" and bouncing emails
In-Reply-To: <CAC47Z9k9oLqbK2D-1uZ5vHP+uV8tNmKfSRFN1zAO5ofZ0LQxgA@mail.gmail.com>
References: <CAC47Z9k9oLqbK2D-1uZ5vHP+uV8tNmKfSRFN1zAO5ofZ0LQxgA@mail.gmail.com>
Message-ID: <CAGFn2k0iQ+BbiqvNrV_bcWmGrUwHD8LC=yJBSa2OV-c7ZadoTg@mail.gmail.com>

On Tue, Oct 15, 2013 at 4:56 PM, Jonathan Rogers <quantumfoam at gmail.com>wrote:

> Greetings Programs,
>
> Yahoo is bouncing email that is being sent to a customer of mine with the
> error that no MX or A records were found for the domain. There is nothing
> wrong with the domain at all, which I have verified from multiple sources.
>
> Does anyone have any suggestions about who I can reach out to at Yahoo to
> get this matter resolved?
>

Multiple sources including DNSSEC-aware ones like dnsviz.net ? If the
domain is failing DNSSEC, it would appear normal to conventional DNS tests.

Rubens

From quantumfoam at gmail.com  Tue Oct 15 20:05:09 2013
From: quantumfoam at gmail.com (Jonathan Rogers)
Date: Tue, 15 Oct 2013 16:05:09 -0400
Subject: Yahoo reporting "No MX or A Records" and bouncing emails
In-Reply-To: <CAGFn2k0iQ+BbiqvNrV_bcWmGrUwHD8LC=yJBSa2OV-c7ZadoTg@mail.gmail.com>
References: <CAC47Z9k9oLqbK2D-1uZ5vHP+uV8tNmKfSRFN1zAO5ofZ0LQxgA@mail.gmail.com>
 <CAGFn2k0iQ+BbiqvNrV_bcWmGrUwHD8LC=yJBSa2OV-c7ZadoTg@mail.gmail.com>
Message-ID: <CAC47Z9=wEs1K+VcwZ2bKDqSNe3AWLCHhTqXTNPt1_LynwcL1sg@mail.gmail.com>

Rubens,

Excellent point. I'm running an analysis on the domain in question now...

Thanks,

Jonathan Rogers
PCM, Inc


On Tue, Oct 15, 2013 at 4:00 PM, Rubens Kuhl <rubensk at gmail.com> wrote:

>
>
>
> On Tue, Oct 15, 2013 at 4:56 PM, Jonathan Rogers <quantumfoam at gmail.com>wrote:
>
>> Greetings Programs,
>>
>> Yahoo is bouncing email that is being sent to a customer of mine with the
>> error that no MX or A records were found for the domain. There is nothing
>> wrong with the domain at all, which I have verified from multiple sources.
>>
>> Does anyone have any suggestions about who I can reach out to at Yahoo to
>> get this matter resolved?
>>
>
> Multiple sources including DNSSEC-aware ones like dnsviz.net ? If the
> domain is failing DNSSEC, it would appear normal to conventional DNS tests.
>
> Rubens
>
>

From quantumfoam at gmail.com  Tue Oct 15 20:18:55 2013
From: quantumfoam at gmail.com (Jonathan Rogers)
Date: Tue, 15 Oct 2013 16:18:55 -0400
Subject: Yahoo reporting "No MX or A Records" and bouncing emails
In-Reply-To: <CAC47Z9=wEs1K+VcwZ2bKDqSNe3AWLCHhTqXTNPt1_LynwcL1sg@mail.gmail.com>
References: <CAC47Z9k9oLqbK2D-1uZ5vHP+uV8tNmKfSRFN1zAO5ofZ0LQxgA@mail.gmail.com>
 <CAGFn2k0iQ+BbiqvNrV_bcWmGrUwHD8LC=yJBSa2OV-c7ZadoTg@mail.gmail.com>
 <CAC47Z9=wEs1K+VcwZ2bKDqSNe3AWLCHhTqXTNPt1_LynwcL1sg@mail.gmail.com>
Message-ID: <CAC47Z9k=WrXXFahPxq5Z9SbUXCBK1y1z9XMbmUXTJOF_EsBL=w@mail.gmail.com>

DNSSEC does not appear to be set up on our name servers (which is where
their DNS is), but this has never been an issue before. In searching the
web about this specific message all I am finding is people saying:

1. Yahoo refuses to acknowledge or fix this, and it is happening to a lot
of random people
2. Get email other than Yahoo (which isn't really helpful and I can't
exactly tell my client that)

How do I get a real person at Yahoo?

Thanks,

Jonathan Rogers
PCM, Inc


On Tue, Oct 15, 2013 at 4:05 PM, Jonathan Rogers <quantumfoam at gmail.com>wrote:

> Rubens,
>
> Excellent point. I'm running an analysis on the domain in question now...
>
> Thanks,
>
> Jonathan Rogers
> PCM, Inc
>
>
> On Tue, Oct 15, 2013 at 4:00 PM, Rubens Kuhl <rubensk at gmail.com> wrote:
>
>>
>>
>>
>> On Tue, Oct 15, 2013 at 4:56 PM, Jonathan Rogers <quantumfoam at gmail.com>wrote:
>>
>>> Greetings Programs,
>>>
>>> Yahoo is bouncing email that is being sent to a customer of mine with the
>>> error that no MX or A records were found for the domain. There is nothing
>>> wrong with the domain at all, which I have verified from multiple
>>> sources.
>>>
>>> Does anyone have any suggestions about who I can reach out to at Yahoo to
>>> get this matter resolved?
>>>
>>
>> Multiple sources including DNSSEC-aware ones like dnsviz.net ? If the
>> domain is failing DNSSEC, it would appear normal to conventional DNS tests.
>>
>> Rubens
>>
>>
>
>

From james.cutler at consultant.com  Tue Oct 15 20:25:01 2013
From: james.cutler at consultant.com (Cutler James R)
Date: Tue, 15 Oct 2013 16:25:01 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <20131015185550.GF15703@cmadams.net>
References: <21084.45059.73694.712636@world.std.com>
 <20131015033143.11379.qmail@joyce.lan>
 <21085.35312.817571.962150@world.std.com>
 <20131015185550.GF15703@cmadams.net>
Message-ID: <6F0931E7-79E0-40E8-8AFE-8565C0B8B53D@consultant.com>

On Oct 15, 2013, at 2:55 PM, Chris Adams <cma at cmadams.net> wrote:

> Once upon a time, Barry Shein <bzs at world.std.com> said:
>> 
>> On October 15, 2013 at 03:31 johnl at iecc.com (John Levine) wrote:
>>>> it's a lot of work for example.com to return something like:
>>>> 
>>>>  2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com
>>> 
>>> Add some NSEC3 records and, yeah, it's a lot of work.  And for what?
>> 
>> Many mail servers require it as a minimum standard for speaking to
>> their MTA.
> 
> Random end users shouldn't be talking to MTAs.  They should be using
> MSAs instead.
> -- 
> Chris Adams <cma at cmadams.net>
> 

Semantically confusing --

From wooledge.org:

Mail Submission Agent (MSA): a relatively new term in the e-mail field. 

This is the component of an MTA which accepts new mail messages from an MUA, using SMTP.
            ====================

From blake at ispn.net  Tue Oct 15 20:26:45 2013
From: blake at ispn.net (Blake Hudson)
Date: Tue, 15 Oct 2013 15:26:45 -0500
Subject: Yahoo reporting "No MX or A Records" and bouncing emails
In-Reply-To: <CAC47Z9k=WrXXFahPxq5Z9SbUXCBK1y1z9XMbmUXTJOF_EsBL=w@mail.gmail.com>
References: <CAC47Z9k9oLqbK2D-1uZ5vHP+uV8tNmKfSRFN1zAO5ofZ0LQxgA@mail.gmail.com>
 <CAGFn2k0iQ+BbiqvNrV_bcWmGrUwHD8LC=yJBSa2OV-c7ZadoTg@mail.gmail.com>
 <CAC47Z9=wEs1K+VcwZ2bKDqSNe3AWLCHhTqXTNPt1_LynwcL1sg@mail.gmail.com>
 <CAC47Z9k=WrXXFahPxq5Z9SbUXCBK1y1z9XMbmUXTJOF_EsBL=w@mail.gmail.com>
Message-ID: <525DA505.3090709@ispn.net>

FYI, I had a client report the same Yahoo error over the weekend when 
attempting to send to a working domain. Our determination was that it 
was a sender side (yahoo) issue. It did not appear that yahoo queued or 
retried the message and instead instantly (or very quickly) gave up. 
This seems atypical MTA behavior upon what could be (and likely was) a 
temporary DNS resolution error.

--Blake

Jonathan Rogers wrote the following on 10/15/2013 3:18 PM:
> DNSSEC does not appear to be set up on our name servers (which is where
> their DNS is), but this has never been an issue before. In searching the
> web about this specific message all I am finding is people saying:
>
> 1. Yahoo refuses to acknowledge or fix this, and it is happening to a lot
> of random people
> 2. Get email other than Yahoo (which isn't really helpful and I can't
> exactly tell my client that)
>
> How do I get a real person at Yahoo?
>
> Thanks,
>
> Jonathan Rogers
> PCM, Inc
>
>
> On Tue, Oct 15, 2013 at 4:05 PM, Jonathan Rogers <quantumfoam at gmail.com>wrote:
>
>> Rubens,
>>
>> Excellent point. I'm running an analysis on the domain in question now...
>>
>> Thanks,
>>
>> Jonathan Rogers
>> PCM, Inc
>>
>>
>> On Tue, Oct 15, 2013 at 4:00 PM, Rubens Kuhl <rubensk at gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Oct 15, 2013 at 4:56 PM, Jonathan Rogers <quantumfoam at gmail.com>wrote:
>>>
>>>> Greetings Programs,
>>>>
>>>> Yahoo is bouncing email that is being sent to a customer of mine with the
>>>> error that no MX or A records were found for the domain. There is nothing
>>>> wrong with the domain at all, which I have verified from multiple
>>>> sources.
>>>>
>>>> Does anyone have any suggestions about who I can reach out to at Yahoo to
>>>> get this matter resolved?
>>>>
>>> Multiple sources including DNSSEC-aware ones like dnsviz.net ? If the
>>> domain is failing DNSSEC, it would appear normal to conventional DNS tests.
>>>
>>> Rubens
>>>
>>>
>>



From jra at baylink.com  Tue Oct 15 20:33:52 2013
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 15 Oct 2013 16:33:52 -0400 (EDT)
Subject: Yahoo reporting "No MX or A Records" and bouncing emails
In-Reply-To: <CAGFn2k0iQ+BbiqvNrV_bcWmGrUwHD8LC=yJBSa2OV-c7ZadoTg@mail.gmail.com>
Message-ID: <9467234.1677.1381869232115.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Rubens Kuhl" <rubensk at gmail.com>

> Multiple sources including DNSSEC-aware ones like dnsviz.net ? If the
> domain is failing DNSSEC, it would appear normal to conventional DNS
> tests.

If that's the problem, then Yahoo's error message is factually incorrect,
and needs to be clarified.

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 marka at isc.org  Tue Oct 15 20:34:08 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Oct 2013 07:34:08 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Tue, 15 Oct 2013 10:35:54 -0400."
 <alpine.BSF.2.00.1310151035270.89737@joyce.lan>
References: <CE82B9DD.331C2%Lee@asgard.org>
 <54B1C067-1DD1-4618-AC0E-89EE5AB3E154@hopcount.ca>
 <alpine.BSF.2.00.1310151035270.89737@joyce.lan>
Message-ID: <20131015203408.63ECB837186@rock.dv.isc.org>


In message <alpine.BSF.2.00.1310151035270.89737 at joyce.lan>, "John R. Levine" wr
ites:
> > I can tell it has been a long weekend here; I find myself agreeing with Mar
> k Andrews.
> 
> Where do the forward records for these random devices come from?
> 
> Signed,
> Confused
 
They get configured though front panels, touch screens, usb
connections, over the network using mDNS for initial discovery,
usinge a games connector and the TV screen, etc.  There are lots
of way to do this.  This is a solved problem as people have been
providing devices with names for about as long as the devices have
existed.

The only difference is that they give the device a fully qualified
name instead of a unqualified name.

They use TSIG to authenticate the UPDATES to the forward zone which
is probably what your DHCP server is using today to authenticate
the updates it sends and one of the methods DynDNS supports to
update the zones it serves.

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


From johnl at iecc.com  Tue Oct 15 20:39:06 2013
From: johnl at iecc.com (John R. Levine)
Date: Tue, 15 Oct 2013 16:39:06 -0400 (EDT)
Subject: comcast ipv6 PTR
In-Reply-To: <21085.35312.817571.962150@world.std.com>
References: <21084.45059.73694.712636@world.std.com>
 <20131015033143.11379.qmail@joyce.lan>
 <21085.35312.817571.962150@world.std.com>
Message-ID: <alpine.BSF.2.00.1310151637070.92633@joyce.lan>

> Many mail servers require it as a minimum standard for speaking to
> their MTA.

In case it's not clear, we're talking about DNS and rDNS for random 
devices that pop up on consumer and other lightly managed networks.

Mail servers, like the ones that sent this message to and from nanog, have 
static IPs, with DNS configured the same way it is for static IPv4.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From marka at isc.org  Tue Oct 15 21:24:10 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Oct 2013 08:24:10 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Tue, 15 Oct 2013 16:57:04 +0200."
 <8738o2poov.fsf@nemi.mork.no>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org> <8738o2poov.fsf@nemi.mork.no>
Message-ID: <20131015212410.C3842837698@rock.dv.isc.org>


In message <8738o2poov.fsf at nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> Mark Andrews <marka at isc.org> writes:
> 
> > Actually you just need to *let* the hosts update their own ptr
> > records using UPDATE.
> >
> > People keep saying the PTR records don't mean anything yet still
> > demand really strong authentication for updates of PTR records.
> > TCP is more than a strong enough authenticator to support update
> > from self.
> >
> > You can even delegate the reverse zone when doing or just after a PD.
> >
> > * Accept NS/DNAME updates for the reverse prefix from any address
> >   in the delegated address range over TCP.  This avoids having a
> >   temporatially lame delegation.  named already has code to do this
> >   for /48's as I coded it to to support 6to4.
> 
> This sounded like an excellent idea at first, but then I started
> thinking:  As a home user, would I really want to give anyone with
> access to my network the right to change my reverse delegation?

Yet this is essentially what 6to4 has been doing for years.  See
RFC 5158.  Sometimes good enough is all that is needed.

One could add a KEY record at the same time as you add the NS/DNAME
records and use SIG(0) to authenticate subsequent updates to the
delegation based on that key.

The DHCP server would clear delegations on new PD presumably using
a TSIG signed UPDATE request.

	if no sig0 then allow update tcp-6to4
	if self-signed the allow update
	if this tsig then allow update

Named already has the concepts of "this tsig", "self-signed",
"tcp-6to4".  It doesn't have the concept of "no sig0" but adding
this sort of thing is relatively straight forward.

A third method would be for the CPE could send a KEY record rdata
in the DHCP PD request that the DHCP server which would add to the
zone with a owner name based on the allocated prefix.  SIG(0) would
then be used to authenticate further update requests at or below
this name.

This is just bolting together existing technologies in more useful
ways.

Mark

> I don't think so.  I am not even sure I would want them all to be able
> to update the PTR record for the addresses they use.

> 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 marka at isc.org  Tue Oct 15 21:42:09 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Oct 2013 08:42:09 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Tue, 15 Oct 2013 09:46:32 -0700."
 <574B5044-E7C5-4EF0-AC67-BE1F3E5EE105@bogus.com>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
 <574B5044-E7C5-4EF0-AC67-BE1F3E5EE105@bogus.com>
Message-ID: <20131015214209.E00D5837956@rock.dv.isc.org>


In message <574B5044-E7C5-4EF0-AC67-BE1F3E5EE105 at bogus.com>, joel jaeggli write
s:
>
> On Oct 15, 2013, at 7:26 AM, John R. Levine <johnl at iecc.com> wrote:
>
> >> Actually you just need to *let* the hosts update their own ptr
> >> records using UPDATE.
> >
>
> I don't think that any host out there should be updating the PTR record
> associated with the privacy address it's using for outgoing connections.
> if the provider the prefix is delgated to respond with a genric RR well
> fine. but I doubt very much that there would be any circumstances where
> you'd want hosts doing PTR updates for addresses they're only using
> because their slaac address is a form of information leakage.

Why don't you let the USER decide whether privacy addresses get PTR
records or not.  This is a policy decision for the USER not IETF,
NANOG or any other body including the manufacturer.  It might default
off but that should be the end of it.

This is about ALLOWING them to do it.  Not REQUIRING them to do it. 


Mark

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


From mpetach at netflight.com  Tue Oct 15 22:07:59 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Tue, 15 Oct 2013 15:07:59 -0700
Subject: Yahoo reporting "No MX or A Records" and bouncing emails
In-Reply-To: <CAC47Z9k=WrXXFahPxq5Z9SbUXCBK1y1z9XMbmUXTJOF_EsBL=w@mail.gmail.com>
References: <CAC47Z9k9oLqbK2D-1uZ5vHP+uV8tNmKfSRFN1zAO5ofZ0LQxgA@mail.gmail.com>
 <CAGFn2k0iQ+BbiqvNrV_bcWmGrUwHD8LC=yJBSa2OV-c7ZadoTg@mail.gmail.com>
 <CAC47Z9=wEs1K+VcwZ2bKDqSNe3AWLCHhTqXTNPt1_LynwcL1sg@mail.gmail.com>
 <CAC47Z9k=WrXXFahPxq5Z9SbUXCBK1y1z9XMbmUXTJOF_EsBL=w@mail.gmail.com>
Message-ID: <CAEmG1=qOweNry6bXD7qsxdb+K+BV=YPK3LV9strHG7L=3bM+oA@mail.gmail.com>

A really good first step is to indicate what domain is
having problems, so people can double-check to
make sure there's nothing unusual or broken
seen from other parts of the network, and if
necessary, escalate the issues with private
contacts.

I'm assuming it's not for the domain you're
sending your email from, in this case; but
if that's a bad assumption, please let
me know.

Thanks!

Matt


On Tue, Oct 15, 2013 at 1:18 PM, Jonathan Rogers <quantumfoam at gmail.com>wrote:

> DNSSEC does not appear to be set up on our name servers (which is where
> their DNS is), but this has never been an issue before. In searching the
> web about this specific message all I am finding is people saying:
>
> 1. Yahoo refuses to acknowledge or fix this, and it is happening to a lot
> of random people
> 2. Get email other than Yahoo (which isn't really helpful and I can't
> exactly tell my client that)
>
> How do I get a real person at Yahoo?
>
> Thanks,
>
> Jonathan Rogers
> PCM, Inc
>
>
> On Tue, Oct 15, 2013 at 4:05 PM, Jonathan Rogers <quantumfoam at gmail.com
> >wrote:
>
> > Rubens,
> >
> > Excellent point. I'm running an analysis on the domain in question now...
> >
> > Thanks,
> >
> > Jonathan Rogers
> > PCM, Inc
> >
> >
> > On Tue, Oct 15, 2013 at 4:00 PM, Rubens Kuhl <rubensk at gmail.com> wrote:
> >
> >>
> >>
> >>
> >> On Tue, Oct 15, 2013 at 4:56 PM, Jonathan Rogers <quantumfoam at gmail.com
> >wrote:
> >>
> >>> Greetings Programs,
> >>>
> >>> Yahoo is bouncing email that is being sent to a customer of mine with
> the
> >>> error that no MX or A records were found for the domain. There is
> nothing
> >>> wrong with the domain at all, which I have verified from multiple
> >>> sources.
> >>>
> >>> Does anyone have any suggestions about who I can reach out to at Yahoo
> to
> >>> get this matter resolved?
> >>>
> >>
> >> Multiple sources including DNSSEC-aware ones like dnsviz.net ? If the
> >> domain is failing DNSSEC, it would appear normal to conventional DNS
> tests.
> >>
> >> Rubens
> >>
> >>
> >
> >
>
>

From jra at baylink.com  Tue Oct 15 22:17:32 2013
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 15 Oct 2013 18:17:32 -0400 (EDT)
Subject: REMINDER: Error messages should include parameters
Message-ID: <18571323.1695.1381875452378.JavaMail.root@benjamin.baylink.com>

Off the Yahoo MX discussion, just a reminder for those who write code:

*Always* include the parameters in the error message; pronouns and
implicit references are Evil, Bad and Wrong.  The 30 seconds you take to
add the actual name of what you can't find/talk to could save some sysadmin
*weeks* (I am not making that up; something once took me weeks).

We now return you to your normal router configuration conversations.

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 contact at nullivex.com  Tue Oct 15 22:23:08 2013
From: contact at nullivex.com (Bryan Tong)
Date: Tue, 15 Oct 2013 16:23:08 -0600
Subject: REMINDER: Error messages should include parameters
In-Reply-To: <18571323.1695.1381875452378.JavaMail.root@benjamin.baylink.com>
References: <18571323.1695.1381875452378.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAAARkvK+Jes_2F4rTtDiXYZeh2yvsJ9dNMsw8t6464njZ_Gh1g@mail.gmail.com>

However it is simple to expose huge security holes when using global error
handlers that don't inspect the content of the error messages and can
accidentally show user names passwords or sensitive exploit information.

This is the reason that most production code does not and will not show you
more in-depth information. Especially on a public service.


On Tue, Oct 15, 2013 at 4:17 PM, Jay Ashworth <jra at baylink.com> wrote:

> Off the Yahoo MX discussion, just a reminder for those who write code:
>
> *Always* include the parameters in the error message; pronouns and
> implicit references are Evil, Bad and Wrong.  The 30 seconds you take to
> add the actual name of what you can't find/talk to could save some sysadmin
> *weeks* (I am not making that up; something once took me weeks).
>
> We now return you to your normal router configuration conversations.
>
> 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
>
>


-- 
eSited LLC
(701) 390-9638

From larrysheldon at cox.net  Tue Oct 15 22:23:01 2013
From: larrysheldon at cox.net (Laurence F. Sheldon, Jr.)
Date: Tue, 15 Oct 2013 17:23:01 -0500
Subject: REMINDER: Error messages should include parameters
In-Reply-To: <daJF1m0011Una3W01aJGiu>
References: <daJF1m0011Una3W01aJGiu>
Message-ID: <525DC045.50500@cox.net>

On 10/15/2013 17:17, Jay Ashworth wrote:
> Off the Yahoo MX discussion, just a reminder for those who write code:
>
> *Always* include the parameters in the error message; pronouns and
> implicit references are Evil, Bad and Wrong.  The 30 seconds you take to
> add the actual name of what you can't find/talk to could save some sysadmin
> *weeks* (I am not making that up; something once took me weeks).
>
> We now return you to your normal router configuration conversations.

Back in the day we only had room for about 4 digits--but there was a 
your-longevity-here-is-dependent-on-it binder for every run-unit that 
listed every error code in numerical order that gave a narrative 
description of what had failed AND WHAT TO DO ABOUT IT.

Seems like the massive stores we have available now days that we could 
do at least as well.




From feldman at nanog.org  Tue Oct 15 23:44:26 2013
From: feldman at nanog.org (Steven Feldman)
Date: Tue, 15 Oct 2013 16:44:26 -0700
Subject: [NANOG-announce] 2013 NANOG Committee Selections
Message-ID: <CAHo4sWUOCJSpOGWxwLi+sX3zhH7E8Xh49Ao0p+b-hGt26qakmA@mail.gmail.com>

NANOG Colleagues,

The Board has completed the committee selection process for this year.

For the Program Committee, we are pleased to announce the
reappointments of Greg Hankins, Manish Karir, Michael Sinatra, and
Tony Tauber, and the new appointments of Peter Hoose, Randy Neals,
Matthew Petach, and Steven Schecter for two-year terms.  In addition,
Paul Ebersman and Sean Kennedy have been appointed to one-year terms
to fill the positions vacated by Dave Temkin and Ryan Donnelly on
their election to the Board.

For the Communications Committee, we are pleased to announce the
appointment of Randy Epstein and Brad Raymo for two-year terms.

And for the Development Committee, we are pleased to announce the
two-year term appointment of Judy DeDois, Tim Parker, Michael Rascoe,
and Valerie Wittkop to two-year terms, and Fearghas McKay to a
one-year term to fill the position vacated by Jezzibell Gilmore on her
election to the Board.

We also want to thank and recognize the contribution of Jim Cowie,
Ryan Donnelly, Igor Gashinsky, Mohit Lad, Dave Temkin, and Dani
Roisman for their service on the Program Committee, Valerie Wittkop
and Webster Olson for their service on the Communications Committee,
and Paul Ebersman and Jezzibell Gilmore for their service on the
Development Committee.

And finally, we want to thank everyone who volunteered as candidates
for these committees for considering this important service to our
community, and encourage them to try for the next selection cycle or
to volunteer in another role.

On behalf of the Board,

        Steve Feldman, vice-chair

_______________________________________________
NANOG-announce mailing list
NANOG-announce at mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce


From marka at isc.org  Tue Oct 15 23:50:30 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Oct 2013 10:50:30 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Tue, 15 Oct 2013 18:48:32 +0200."
 <87iowyo4yn.fsf@nemi.mork.no>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
 <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>
 <525D64B7.6080204@mtcc.com> <87iowyo4yn.fsf@nemi.mork.no>
Message-ID: <20131015235030.769D483A76A@rock.dv.isc.org>


In message <87iowyo4yn.fsf at nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> Michael Thomas <mike at mtcc.com> writes:
> > On 10/15/2013 08:35 AM, TJ wrote:
> >>>
> >>> My cable company assigns me a different prefix every time the modem
> >>> reboots, about once a month, and I think that's pretty typical.
> >>>
> >> Really?
> >> I think my IPv6 address form Comcast has changed (maybe) twice in the la=
> st
> >> 18 months, and I think it was only once.
> >>
> >
> > There's an entire universe within ietf who thinks that seamless
> > renumbering is
> > a Big Deal. We're obviously not completely there -- especially within
> > residential --
> > but any path forward should not count on the stability of
> > prefixes. Anywhere.
> 
> Agreed.
> 
> We will allocate semi-static prefixes, but have decided to do strict
> aggregation of retail subscriber prefixes on the BNGs. This means that
> the allocations will be perceived as static by most users, but there are
> no guarantees. We will renumber if the users move between BNGs,
> regardless of reason.  Including moving DSLAMs/OLTs.
> 
> Having said that: Renumbering is not going to be seemless, even for
> simple home networks.  The last time I changed my home prefix, I
> completely forgot that I had put the old one into a cups access list.
> Took me a while to figure out why I couldn't make the printer work a
> month or so later...
> 
> Typical static entries being added over time are:
>  - DNS glue

Well this is solvable using UPDATE + TSIG to update the glue held
in the parent zones.  People have used stored user names and passwords
to update things automatically for decades.  TSIG is just a user
name and a password.

For RRR managed zones see draft-andrews-dnsop-updating-parent-zones.

>  - access lists, both in your network and in other networks

Complain to your equipment vendor if they don't support dynamic
updating of these lists.

>  - interface config on devices where you don't want SLAAC or DHCPv6

Well if you refuse to use methods that are designed to make renumbering
events less painful you only have yourself to blame.

>  - server application configuration (you do want your mail server to use
>    a specific source address and not just choose one, right?)

Why do you care about the address other than it has a PTR record
associated with it.  You can tell IP stacks to NOT use privacy
addresses when selecting the source address to use for outgoing
connections.

>  + everything I forgot
>
> No, renumbering is not going to be seemless.  Yes, a smarter person
> could automate everything I list above, but we all know that's not going
> to happen.

No, we don't know it won't happen.

You just tackle one problem at a time and very soon you have a
machine that can be renumbered automatically.  It's about configuring
the machine in the first place.

Mark

> 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 iamzam at gmail.com  Wed Oct 16 01:25:44 2013
From: iamzam at gmail.com (DV)
Date: Tue, 15 Oct 2013 21:25:44 -0400
Subject: invalid SOA record? or just unusual
Message-ID: <CAEiuvJAWWR=47rq14x1cGpQUCHhmjGoD4QqCHrv_a+auhHpL6w@mail.gmail.com>

Hello nanog,

Hopefully someone will have some input here on this DNS problem and
why it is happening.
I have just uncovered what seems to be a misconfiguration in an SOA
record. This causes the domain to be unable to be resolved via a few
of my DNS servers.
It seems to work everywhere else I check it just fine, except for
these two DNS servers.

One of these DNS servers is Win 2003 and the other is the standard
latest RHEL6 bind 9.8.2.blah-blah so I don't think it would be a bug
that affects both.
They are both behind a NAT Firewall gateway which could also be
causing problems by inspecting DNS traffic...

Below is the SOA record in question for the site that cannot be
resolved by our name servers.
Particluarly the "." in place of the authoritative server which seems
to be a mis-config and I am not sure the reason for it.

# dig soa rapportive.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> @172.20.20.254
soarapportive.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33703
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;rapportive.com.            IN    SOA

;; ANSWER SECTION:rapportive.com.        3600    IN    SOA    .
hostmaster.rapportive.com.
2013041614 3600 3600 3600 3600

;; Query time: 54 msec
;; SERVER: 172.20.20.254#53(172.20.20.254)
;; WHEN: Tue Oct 15 16:49:57 2013
;; MSG SIZE  rcvd: 78


Thanks for any help, I would be grateful for any suggestions at all...
 Perhaps someone does the same thing with their SOA records?

DV

From johnl at iecc.com  Wed Oct 16 03:13:22 2013
From: johnl at iecc.com (John R. Levine)
Date: Tue, 15 Oct 2013 23:13:22 -0400 (EDT)
Subject: comcast ipv6 PTR
In-Reply-To: <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
 <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1310152313010.94070@joyce.lan>

>> My cable company assigns me a different prefix every time the modem
>> reboots, about once a month, and I think that's pretty typical.
>>
> Really?

Yes, it's T-W and I believe it's deliberate.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From rjoffe at centergate.com  Wed Oct 16 04:13:59 2013
From: rjoffe at centergate.com (Rodney Joffe)
Date: Wed, 16 Oct 2013 00:13:59 -0400
Subject: =?utf-8?Q?15_Years_ago_today=E2=80=A6.?=
In-Reply-To: <4DF7DC2753C30C419FFB7C0024155BFD0B748F04@stntexmb11.cis.neustar.com>
References: <4DF7DC2753C30C419FFB7C0024155BFD0B746253@stntexmb11.cis.neustar.com>
 <2BD6FE78-7354-465A-8D1C-0D8316612F5D@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B74634A@stntexmb11.cis.neustar.com>
 <3E930AD6-EDC5-43D2-90AA-F2F09D7196F1@neustar.biz>
 <9926C84F-2224-45D4-9FC6-D82D5523A1BC@neustar.biz>
 <825F45E1-EF94-4396-98D2-60BCD1F25550@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B748F04@stntexmb11.cis.neustar.com>
Message-ID: <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>

... we lost Jon.

http://www.ietf.org/rfc/rfc2468.txt

<sigh>

Given the number of young people in the community who, last year, said "Who?", maybe its time to stop the reminders.

This world is *so* different to the way it was. Getting old sucks.

From wbailey at satelliteintelligencegroup.com  Wed Oct 16 04:16:31 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Wed, 16 Oct 2013 04:16:31 +0000
Subject: =?Windows-1252?Q?Re:_15_Years_ago_today=8A.?=
In-Reply-To: <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
Message-ID: <CE8360F1.B6A4%wbailey@satelliteintelligencegroup.com>

I'm 30, and have been at this for as long as I can remember. Remembering a
fallen friend is a perfectly acceptable thing to do.. Shout it from the
rooftops, it's nice to see a posting that won't be technically pissed on
(hopefully) within 45 seconds of receipt.

Keep on keepin' on.

On 10/15/13 9:13 PM, "Rodney Joffe" <rjoffe at centergate.com> wrote:

>... we lost Jon.
>
>http://www.ietf.org/rfc/rfc2468.txt
>
><sigh>
>
>Given the number of young people in the community who, last year, said
>"Who?", maybe its time to stop the reminders.
>
>This world is *so* different to the way it was. Getting old sucks.



From joelja at bogus.com  Wed Oct 16 04:20:46 2013
From: joelja at bogus.com (joel jaeggli)
Date: Tue, 15 Oct 2013 21:20:46 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <alpine.BSF.2.00.1310152313010.94070@joyce.lan>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <alpine.BSF.2.00.1310151010530.89737@joyce.lan>
 <CALOgxGbUf8YabqfDCA8+OmFFDmMQ1Zdsk-sLa7JMETEiWcJWzQ@mail.gmail.com>
 <alpine.BSF.2.00.1310152313010.94070@joyce.lan>
Message-ID: <8DE4777D-D31B-4CFC-ADF2-98F90A2DB570@bogus.com>


On Oct 15, 2013, at 8:13 PM, John R. Levine <johnl at iecc.com> wrote:

>>> My cable company assigns me a different prefix every time the modem
>>> reboots, about once a month, and I think that's pretty typical.
>>> 
>> Really?
> 
> Yes, it's T-W and I believe it's deliberate.

http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-08

> 
> Regards,
> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. http://jl.ly
> 

-------------- 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/20131015/d56f7331/attachment-0001.bin>

From pdonner at cisco.com  Wed Oct 16 04:22:14 2013
From: pdonner at cisco.com (Paul Donner (pdonner))
Date: Wed, 16 Oct 2013 04:22:14 +0000
Subject: =?windows-1256?Q?RE:_15_Years_ago_today=85.?=
In-Reply-To: <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
References: <4DF7DC2753C30C419FFB7C0024155BFD0B746253@stntexmb11.cis.neustar.com>
 <2BD6FE78-7354-465A-8D1C-0D8316612F5D@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B74634A@stntexmb11.cis.neustar.com>
 <3E930AD6-EDC5-43D2-90AA-F2F09D7196F1@neustar.biz>
 <9926C84F-2224-45D4-9FC6-D82D5523A1BC@neustar.biz>
 <825F45E1-EF94-4396-98D2-60BCD1F25550@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B748F04@stntexmb11.cis.neustar.com>,
 <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
Message-ID: <79B23DB4F91C474E8B9D8CAB5C4738830E6227DD@xmb-aln-x01.cisco.com>

That truly was a long time ago but seems like yesterday.  Keep having to remind ourselves that time moves quickly for us mere humans...

/wp
________________________________
From: Rodney Joffe<mailto:rjoffe at centergate.com>
Sent: ?10/?15/?2013 10:17 PM
To: NANOG<mailto:nanog at nanog.org>
Subject: 15 Years ago today?.

... we lost Jon.

http://www.ietf.org/rfc/rfc2468.txt

<sigh>

Given the number of young people in the community who, last year, said "Who?", maybe its time to stop the reminders.

This world is *so* different to the way it was. Getting old sucks.

From randy at psg.com  Wed Oct 16 04:25:57 2013
From: randy at psg.com (Randy Bush)
Date: Wed, 16 Oct 2013 07:25:57 +0300
Subject: 15 Years ago =?UTF-8?B?dG9kYXnigKYu?=
In-Reply-To: <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
References: <4DF7DC2753C30C419FFB7C0024155BFD0B746253@stntexmb11.cis.neustar.com>
 <2BD6FE78-7354-465A-8D1C-0D8316612F5D@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B74634A@stntexmb11.cis.neustar.com>
 <3E930AD6-EDC5-43D2-90AA-F2F09D7196F1@neustar.biz>
 <9926C84F-2224-45D4-9FC6-D82D5523A1BC@neustar.biz>
 <825F45E1-EF94-4396-98D2-60BCD1F25550@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B748F04@stntexmb11.cis.neustar.com>
 <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
Message-ID: <m2hachon8q.wl%randy@psg.com>

october is my least favorite month.  jon, abha, itojun.  i look forward
to november and hope everybody makes it.

randy


From larrysheldon at cox.net  Wed Oct 16 04:56:24 2013
From: larrysheldon at cox.net (Laurence F. Sheldon, Jr.)
Date: Tue, 15 Oct 2013 23:56:24 -0500
Subject: 15 Years ago =?windows-1252?Q?today=85=2E?=
In-Reply-To: <dgHk1m0171Una3W01gHmrk>
References: <4DF7DC2753C30C419FFB7C0024155BFD0B746253@stntexmb11.cis.neustar.com>
 <2BD6FE78-7354-465A-8D1C-0D8316612F5D@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B74634A@stntexmb11.cis.neustar.com>
 <3E930AD6-EDC5-43D2-90AA-F2F09D7196F1@neustar.biz>
 <9926C84F-2224-45D4-9FC6-D82D5523A1BC@neustar.biz>
 <825F45E1-EF94-4396-98D2-60BCD1F25550@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B748F04@stntexmb11.cis.neustar.com>
 <dgHk1m0171Una3W01gHmrk>
Message-ID: <525E1C78.7010703@cox.net>

On 10/15/2013 23:13, Rodney Joffe wrote:
> ... we lost Jon.
>
> http://www.ietf.org/rfc/rfc2468.txt
>
> <sigh>
>
> Given the number of young people in the community who, last year, said "Who?", maybe its time to stop the reminders.

NO.  We have developed a fetish for forgetting things we should 
remember--RESIST.  Please.

> This world is *so* different to the way it was. Getting old sucks.

BoyHowdy, you've got that right.

I'd like to post this to Facebook.





From larrysheldon at cox.net  Wed Oct 16 05:16:31 2013
From: larrysheldon at cox.net (Laurence F. Sheldon, Jr.)
Date: Wed, 16 Oct 2013 00:16:31 -0500
Subject: 15 Years ago =?windows-1252?Q?today=85=2E?=
In-Reply-To: <di1C1m00M1Una3W01i1DQN>
References: <4DF7DC2753C30C419FFB7C0024155BFD0B746253@stntexmb11.cis.neustar.com>
 <2BD6FE78-7354-465A-8D1C-0D8316612F5D@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B74634A@stntexmb11.cis.neustar.com>
 <3E930AD6-EDC5-43D2-90AA-F2F09D7196F1@neustar.biz>
 <9926C84F-2224-45D4-9FC6-D82D5523A1BC@neustar.biz>
 <825F45E1-EF94-4396-98D2-60BCD1F25550@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B748F04@stntexmb11.cis.neustar.com>
 <dgHk1m0171Una3W01gHmrk> <di1C1m00M1Una3W01i1DQN>
Message-ID: <525E212F.3070303@cox.net>

On 10/15/2013 23:56, Laurence F. Sheldon, Jr. wrote:
> On 10/15/2013 23:13, Rodney Joffe wrote:
>> ... we lost Jon.
>>
>> http://www.ietf.org/rfc/rfc2468.txt

> I'd like to post this to Facebook.

I commented on FB, far less eloquently.

Interesting, isn't it--how many (r)evolutionary cycles we have been 
through, and what a different world we are in now, with nary a 
Teletype--not even a glass one--to be found.

And yet MOST of the people that did the early work are still alive.

Sadly, some are not.





From marka at isc.org  Wed Oct 16 05:35:49 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Oct 2013 16:35:49 +1100
Subject: invalid SOA record? or just unusual
In-Reply-To: Your message of "Tue, 15 Oct 2013 21:25:44 -0400."
 <CAEiuvJAWWR=47rq14x1cGpQUCHhmjGoD4QqCHrv_a+auhHpL6w@mail.gmail.com>
References: <CAEiuvJAWWR=47rq14x1cGpQUCHhmjGoD4QqCHrv_a+auhHpL6w@mail.gmail.com>
Message-ID: <20131016053549.DBE1483C09C@rock.dv.isc.org>


In message <CAEiuvJAWWR=47rq14x1cGpQUCHhmjGoD4QqCHrv_a+auhHpL6w at mail.gmail.com>
, DV writes:
> Hello nanog,
> 
> Hopefully someone will have some input here on this DNS problem and
> why it is happening.
> I have just uncovered what seems to be a misconfiguration in an SOA
> record. This causes the domain to be unable to be resolved via a few
> of my DNS servers.
> It seems to work everywhere else I check it just fine, except for
> these two DNS servers.
> 
> One of these DNS servers is Win 2003 and the other is the standard
> latest RHEL6 bind 9.8.2.blah-blah so I don't think it would be a bug
> that affects both.
> They are both behind a NAT Firewall gateway which could also be
> causing problems by inspecting DNS traffic...

It's the NAT.  named doesn't care about the MNAME.

Mark
 
> Below is the SOA record in question for the site that cannot be
> resolved by our name servers.
> Particluarly the "." in place of the authoritative server which seems
> to be a mis-config and I am not sure the reason for it.
> 
> # dig soa rapportive.com
> 
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> @172.20.20.254
> soarapportive.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33703
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;rapportive.com.            IN    SOA
> 
> ;; ANSWER SECTION:rapportive.com.        3600    IN    SOA    .
> hostmaster.rapportive.com.
> 2013041614 3600 3600 3600 3600
> 
> ;; Query time: 54 msec
> ;; SERVER: 172.20.20.254#53(172.20.20.254)
> ;; WHEN: Tue Oct 15 16:49:57 2013
> ;; MSG SIZE  rcvd: 78
> 
> 
> Thanks for any help, I would be grateful for any suggestions at all...
>  Perhaps someone does the same thing with their SOA records?
> 
> DV
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From deleskie at gmail.com  Wed Oct 16 05:43:59 2013
From: deleskie at gmail.com (deleskie at gmail.com)
Date: Wed, 16 Oct 2013 02:43:59 -0300
Subject: =?utf-8?q?Re=3A_15_Years_ago_today=E2=80=A6=2E?=
In-Reply-To: <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
References: <4DF7DC2753C30C419FFB7C0024155BFD0B746253@stntexmb11.cis.neustar.com>
 <2BD6FE78-7354-465A-8D1C-0D8316612F5D@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B74634A@stntexmb11.cis.neustar.com>
 <3E930AD6-EDC5-43D2-90AA-F2F09D7196F1@neustar.biz>
 <9926C84F-2224-45D4-9FC6-D82D5523A1BC@neustar.biz>
 <825F45E1-EF94-4396-98D2-60BCD1F25550@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B748F04@stntexmb11.cis.neustar.com>
 <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
Message-ID: <20131016054359.5017743.75664.3991@gmail.com>


From celestea at usc.edu  Wed Oct 16 07:32:53 2013
From: celestea at usc.edu (Celeste Anderson)
Date: Wed, 16 Oct 2013 07:32:53 +0000
Subject: =?Windows-1252?Q?RE:_15_Years_ago_today=85.?=
In-Reply-To: <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
References: <4DF7DC2753C30C419FFB7C0024155BFD0B746253@stntexmb11.cis.neustar.com>
 <2BD6FE78-7354-465A-8D1C-0D8316612F5D@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B74634A@stntexmb11.cis.neustar.com>
 <3E930AD6-EDC5-43D2-90AA-F2F09D7196F1@neustar.biz>
 <9926C84F-2224-45D4-9FC6-D82D5523A1BC@neustar.biz>
 <825F45E1-EF94-4396-98D2-60BCD1F25550@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B748F04@stntexmb11.cis.neustar.com>,
 <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
Message-ID: <D0E2B9E245F287479153934106DC152824C3EB8D@CH1PRD0710MB393.namprd07.prod.outlook.com>

Rodney, et al.,

Am glad to be an old person who does remember Jon.  If anyone has special remembrances of Jon and his contributions to networking, please send to me offline.  We are preparing some material to be presented at a tribute later this month.

Celeste Anderson
Director, Los Nettos
USC-ITS
celestea at usc.edu
________________________________________
From: Rodney Joffe [rjoffe at centergate.com]
Sent: Tuesday, October 15, 2013 9:13 PM
To: NANOG
Subject: 15 Years ago today?.

... we lost Jon.

http://www.ietf.org/rfc/rfc2468.txt

<sigh>

Given the number of young people in the community who, last year, said "Who?", maybe its time to stop the reminders.

This world is *so* different to the way it was. Getting old sucks.




From marka at isc.org  Wed Oct 16 07:50:29 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Oct 2013 18:50:29 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Tue, 15 Oct 2013 18:20:40 +0200."
 <87mwmao693.fsf@nemi.mork.no>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org> <8738o2poov.fsf@nemi.mork.no>
 <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>
 <87mwmao693.fsf@nemi.mork.no>
Message-ID: <20131016075029.E6C0F83ED85@rock.dv.isc.org>


In message <87mwmao693.fsf at nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> Joe Abley <jabley at hopcount.ca> writes:
> > On 2013-10-15, at 10:57, Bj=C3=B8rn Mork <bjorn at mork.no> wrote:
> >> Mark Andrews <marka at isc.org> writes:
> >>=20
> >>> People keep saying the PTR records don't mean anything yet still
> >>> demand really strong authentication for updates of PTR records.
> >>> TCP is more than a strong enough authenticator to support update
> >>> from self.
> >>=20
> >> This sounded like an excellent idea at first, but then I started
> >> thinking:  As a home user, would I really want to give anyone with
> >> access to my network the right to change my reverse delegation?
> >
> > I think what you'd be doing is giving anybody you have assigned an
> > IPv6 address to the ability to update the PTR (or a delegation, since
> > Mark suggested that too) for that particular address.
> >
> > So, it's not "my reverse delegation", it's "my 2^80 or fewer reverse
> > delegations" (if you've been assigned a /48).
> 
> Ah, right.  I understood the proposal as "any address within then /48
> can update the delegation for the /48 reverse".
> 
> But if that would be 2^80 distinct delegations or PTRs, then I am
> worrying about luser stupidiy and the ability to DoS the name server.  I
> guess this can be combined with some sort of limit, making it fly?
> Still don't see the advantage of being able to delegate if it's only
> single address delegations.  But allowing a limited number of PTR
> updates based on TCP sounds like a nice idea.  Going to consider that.

No that would be 1 delegation.  e.g.  x.x.x.x.8.b.d.0.1.0.0.2.ip6.arpa
 
> For the full /48 delegation I don't see any other option than making it
> part of a self service portal.  But the marketing/product droids usually
> don't want that sort of "complex" techical stuff  for retail users.
> Probably for good reasons...

I can see this being done completely automatically by the CPE device.
It is trivial to code.  It just required ISP's to *allow* it to happen.

* CPE generates a RSA key pair.  Stores this in non-volatile memory.
  [needs to be coded, no protocol work required]

* CPE generates DHCP PD request which includes a "KEY-RDATA" option
  which contains a RSASHA256 KEY RDATA.
  [needs to be coded, needs code point allocated but otherwise no
  protocol work required]  

* DHCP server updates DNS server based on the prefix it is delegating
  and the KEY-RDATA using TSIG for authentication and responds with
  prefix.  If this is a new PD it will clear out all the old DNS
  records as part of the delegation processs.  If there are multiple
  prefixes being delegated the DNS server will be updated for all of
  them.
  [needs to be coded.  uses existing protocols]

* The CPE device configures the nameserver built in to it to server
  the reverse of the delegated prefixes.
  [needs to be coded, no protocol work required]

* CPE device generates DNS update which delegates the reverse name
  space to itself and uses SIG(0) to sign the request with owner
  name matching the reverse of the delegated prefix.
  [needs to be coded, uses existing protocols]

* The ISP's DNS server is configured to accept self signed requests.
  It examines the request. Looks at the KEY record added by the DHCP
  server and decides the request is valid.
  [exists, uses existing protocols]

At this stage the reverse space has been delegated to the CPE device
which can accept updates from machines within the home.

> In any case: All of you should expect legitimate, technical brilliant
> users attempting to connect to your SMTP servers from IPv6 addresses
> with no PTR records. This is not going to go away.  You are of course
> free to refuse those connections, but personally I find a that rather
> arrogant and pretty stupid decision.  The existence of a PTR record is
> one of many factors to consider for your spam filter.  There never has
> been any reason to make it an absolute requirement, and I am pretty sure
> the score needs to be lowered with IPv6.
> 
> 
> Bj=C3=B8rn (yes, my mail server has a proper IPv6 reverse record, but that's
> only because I am in a position to create the reverse delegation....)
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From web at typo.org  Wed Oct 16 07:52:19 2013
From: web at typo.org (Wayne E Bouchard)
Date: Wed, 16 Oct 2013 00:52:19 -0700
Subject: 15 Years ago today?.
In-Reply-To: <D0E2B9E245F287479153934106DC152824C3EB8D@CH1PRD0710MB393.namprd07.prod.outlook.com>
References: <4DF7DC2753C30C419FFB7C0024155BFD0B746253@stntexmb11.cis.neustar.com>
 <2BD6FE78-7354-465A-8D1C-0D8316612F5D@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B74634A@stntexmb11.cis.neustar.com>
 <3E930AD6-EDC5-43D2-90AA-F2F09D7196F1@neustar.biz>
 <9926C84F-2224-45D4-9FC6-D82D5523A1BC@neustar.biz>
 <825F45E1-EF94-4396-98D2-60BCD1F25550@neustar.biz>
 <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
 <D0E2B9E245F287479153934106DC152824C3EB8D@CH1PRD0710MB393.namprd07.prod.outlook.com>
Message-ID: <20131016075219.GA23407@wakko.typo.org>

You know, its funny. I saw John Curan at NANOG this past week and
started thinking about the tribute he gave to Jon back then. Time does
indeed fly with wings of eagles. There are a few men and women in
every great endeavor without which it might well never have come to
pass. Jon was one such. I didn't know him, but I knew the work he did.
Gratitude is well earned.

-Wayne

On Wed, Oct 16, 2013 at 07:32:53AM +0000, Celeste Anderson wrote:
> Rodney, et al.,
> 
> Am glad to be an old person who does remember Jon.  If anyone has special remembrances of Jon and his contributions to networking, please send to me offline.  We are preparing some material to be presented at a tribute later this month.
> 
> Celeste Anderson
> Director, Los Nettos
> USC-ITS
> celestea at usc.edu
> ________________________________________
> From: Rodney Joffe [rjoffe at centergate.com]
> Sent: Tuesday, October 15, 2013 9:13 PM
> To: NANOG
> Subject: 15 Years ago today?.
> 
> ... we lost Jon.
> 
> http://www.ietf.org/rfc/rfc2468.txt
> 
> <sigh>
> 
> Given the number of young people in the community who, last year, said "Who?", maybe its time to stop the reminders.
> 
> This world is *so* different to the way it was. Getting old sucks.
> 
> 
> 

---
Wayne Bouchard
web at typo.org
Network Dude
http://www.typo.org/~web/


From bjorn at mork.no  Wed Oct 16 08:50:16 2013
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Wed, 16 Oct 2013 10:50:16 +0200
Subject: comcast ipv6 PTR
In-Reply-To: <20131015212410.C3842837698@rock.dv.isc.org> (Mark Andrews's
 message of "Wed, 16 Oct 2013 08:24:10 +1100")
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <8738o2poov.fsf@nemi.mork.no>
 <20131015212410.C3842837698@rock.dv.isc.org>
Message-ID: <8738o1ob07.fsf@nemi.mork.no>

Mark Andrews <marka at isc.org> writes:
> In message <8738o2poov.fsf at nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
>> Mark Andrews <marka at isc.org> writes:
>> 
>> > Actually you just need to *let* the hosts update their own ptr
>> > records using UPDATE.
>> >
>> > People keep saying the PTR records don't mean anything yet still
>> > demand really strong authentication for updates of PTR records.
>> > TCP is more than a strong enough authenticator to support update
>> > from self.
>> >
>> > You can even delegate the reverse zone when doing or just after a PD.
>> >
>> > * Accept NS/DNAME updates for the reverse prefix from any address
>> >   in the delegated address range over TCP.  This avoids having a
>> >   temporatially lame delegation.  named already has code to do this
>> >   for /48's as I coded it to to support 6to4.
>> 
>> This sounded like an excellent idea at first, but then I started
>> thinking:  As a home user, would I really want to give anyone with
>> access to my network the right to change my reverse delegation?
>
> Yet this is essentially what 6to4 has been doing for years.  See
> RFC 5158.  Sometimes good enough is all that is needed.

Yes.  Could be. But there will always be these paranoid users which do
not want to allow their teenage childrens hacker friends to change
delegations and create cooool names...

> One could add a KEY record at the same time as you add the NS/DNAME
> records and use SIG(0) to authenticate subsequent updates to the
> delegation based on that key.

I really like this idea.

> The DHCP server would clear delegations on new PD presumably using
> a TSIG signed UPDATE request.

I would only do the clearing when changing the prefix owner in the
DHCPv6 backend database, but I guess that depends on how you do the
allocations.

> 	if no sig0 then allow update tcp-6to4
> 	if self-signed the allow update
> 	if this tsig then allow update
>
> Named already has the concepts of "this tsig", "self-signed",
> "tcp-6to4".  It doesn't have the concept of "no sig0" but adding
> this sort of thing is relatively straight forward.

Some sort of "this name+RR exists" conditional would be useful in the policy.

I would like to make the policy depend on
  if self-signed then allow update
  if KEY(zone) exists then deny update
  if tcp-self then allow update KEY PTR

Actually, a count of records would be useful:

  if this tsig then allow update
  if self-signed then allow update
  if count(KEY, zone) > 0 then deny update
  if tcp-self then allow update zone KEY
  if count(PTR, *.zone) > 5 then deny update
  if tcp-self then allow update *.zone PTR

Does BIND do automatic validation of NS updates vs other records?
I.e. if a NS record exists, are PTR updates inside the delegated zone
automatically denied?

> A third method would be for the CPE could send a KEY record rdata
> in the DHCP PD request that the DHCP server which would add to the
> zone with a owner name based on the allocated prefix.  SIG(0) would
> then be used to authenticate further update requests at or below
> this name.

That would also work.  But it requires co-ordinated DCHPv6 client and
server support, making it less likely to succeed IMHO.  Making those
behave is difficult enough alread.

Still, one additional concern showed up when discussing these ideas with
people being paid to be paranoid: Spamming botnets are real.  Most users
won't ever touch their reverse DNS records.  In particular, those users
with botnet controlled PCs are not going to have any KEYs.  Until the
bot programmers discover that *they* now have the power to add proper PTR
and SPF records for their spam service...

Haven't they yet discovered this on 6to4?  Well, I guess they have now,
and you will all just deny mail from 6to4 addresses regardless of DNS.


Bj?rn


From marka at isc.org  Wed Oct 16 09:44:29 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Oct 2013 20:44:29 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Wed, 16 Oct 2013 10:50:16 +0200."
 <8738o1ob07.fsf@nemi.mork.no>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org> <8738o2poov.fsf@nemi.mork.no>
 <20131015212410.C3842837698@rock.dv.isc.org> <8738o1ob07.fsf@nemi.mork.no>
Message-ID: <20131016094429.CB07384033E@rock.dv.isc.org>


In message <8738o1ob07.fsf at nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> Mark Andrews <marka at isc.org> writes:
> > In message <8738o2poov.fsf at nemi.mork.no>, =3D?utf-8?Q?Bj=3DC3=3DB8rn_Mork=
> ?=3D writes:
> >> Mark Andrews <marka at isc.org> writes:
> >>=20
> >> > Actually you just need to *let* the hosts update their own ptr
> >> > records using UPDATE.
> >> >
> >> > People keep saying the PTR records don't mean anything yet still
> >> > demand really strong authentication for updates of PTR records.
> >> > TCP is more than a strong enough authenticator to support update
> >> > from self.
> >> >
> >> > You can even delegate the reverse zone when doing or just after a PD.
> >> >
> >> > * Accept NS/DNAME updates for the reverse prefix from any address
> >> >   in the delegated address range over TCP.  This avoids having a
> >> >   temporatially lame delegation.  named already has code to do this
> >> >   for /48's as I coded it to to support 6to4.
> >>=20
> >> This sounded like an excellent idea at first, but then I started
> >> thinking:  As a home user, would I really want to give anyone with
> >> access to my network the right to change my reverse delegation?
> >
> > Yet this is essentially what 6to4 has been doing for years.  See
> > RFC 5158.  Sometimes good enough is all that is needed.
> 
> Yes.  Could be. But there will always be these paranoid users which do
> not want to allow their teenage childrens hacker friends to change
> delegations and create cooool names...
> 
> > One could add a KEY record at the same time as you add the NS/DNAME
> > records and use SIG(0) to authenticate subsequent updates to the
> > delegation based on that key.
> 
> I really like this idea.
> 
> > The DHCP server would clear delegations on new PD presumably using
> > a TSIG signed UPDATE request.
> 
> I would only do the clearing when changing the prefix owner in the
> DHCPv6 backend database, but I guess that depends on how you do the
> allocations.
> 
> > 	if no sig0 then allow update tcp-6to4
> > 	if self-signed the allow update
> > 	if this tsig then allow update
> >
> > Named already has the concepts of "this tsig", "self-signed",
> > "tcp-6to4".  It doesn't have the concept of "no sig0" but adding
> > this sort of thing is relatively straight forward.
> 
> Some sort of "this name+RR exists" conditional would be useful in the polic=
> y.
> 
> I would like to make the policy depend on
>   if self-signed then allow update
>   if KEY(zone) exists then deny update
>   if tcp-self then allow update KEY PTR
> 
> Actually, a count of records would be useful:
> 
>   if this tsig then allow update
>   if self-signed then allow update
>   if count(KEY, zone) > 0 then deny update
>   if tcp-self then allow update zone KEY
>   if count(PTR, *.zone) > 5 then deny update
>   if tcp-self then allow update *.zone PTR
> 
> Does BIND do automatic validation of NS updates vs other records?
> I.e. if a NS record exists, are PTR updates inside the delegated zone
> automatically denied?
> 
> > A third method would be for the CPE could send a KEY record rdata
> > in the DHCP PD request that the DHCP server which would add to the
> > zone with a owner name based on the allocated prefix.  SIG(0) would
> > then be used to authenticate further update requests at or below
> > this name.
> 
> That would also work.  But it requires co-ordinated DCHPv6 client and
> server support, making it less likely to succeed IMHO.  Making those
> behave is difficult enough alread.

However *now* is the perfect time to do this as many ISP's are only
starting to think about how to do IPv6.  This means installing *new*
DHCP servers.  

Similarly most households don't yet have a IPv6 CPE device.

We are talking "basically" green field.

> Still, one additional concern showed up when discussing these ideas with
> people being paid to be paranoid: Spamming botnets are real.  Most users
> won't ever touch their reverse DNS records.  In particular, those users
> with botnet controlled PCs are not going to have any KEYs.  Until the
> bot programmers discover that *they* now have the power to add proper PTR
> and SPF records for their spam service...

Your customers should be able to get names for their machines
registered in the DNS.  If that means that generic names go the way
of the dinasour then so be it.

Remember generic names were only used because there was specified
method to do this originally and inertia took over for IPv4.

This is like the reason people used ISP to send and receive email
was because they were not alway connected and it was slightly less
hassle.

> Haven't they yet discovered this on 6to4?  Well, I guess they have now,
> and you will all just deny mail from 6to4 addresses regardless of DNS.
> 
> 
> 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 david at mailplus.nl  Wed Oct 16 10:09:20 2013
From: david at mailplus.nl (MailPlus| David Hofstee)
Date: Wed, 16 Oct 2013 12:09:20 +0200
Subject: Hotmail JMRP contact
Message-ID: <78C35D6C1A82D243B830523B4193CF5F5EBB5DD5B1@SBS1.blinker.local>

Hi,

I have been trying to get around the Hotmail JMRP helpdesk scripts which only supports adding and modifying accounts.

I am seeing technical problems with the JMRP (receiving superfluous fbl mails). Can a postmaster contact me off list to resolve this? Thanks,



David Hofstee

Deliverability Management
MailPlus B.V. Netherlands

From Valdis.Kletnieks at vt.edu  Wed Oct 16 12:59:21 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 16 Oct 2013 08:59:21 -0400
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Wed, 16 Oct 2013 18:50:29 +1100."
 <20131016075029.E6C0F83ED85@rock.dv.isc.org>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org> <8738o2poov.fsf@nemi.mork.no>
 <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>
 <87mwmao693.fsf@nemi.mork.no>
 <20131016075029.E6C0F83ED85@rock.dv.isc.org>
Message-ID: <199168.1381928361@turing-police.cc.vt.edu>

On Wed, 16 Oct 2013 18:50:29 +1100, Mark Andrews said:

> I can see this being done completely automatically by the CPE device.
> It is trivial to code.  It just required ISP's to *allow* it to happen.

The rest of the plan looks OK at first glance.. However, step 0:

> * CPE generates a RSA key pair.  Stores this in non-volatile memory.
>   [needs to be coded, no protocol work required]

has proven to be a lot harder to do in the field than one might expect, due
to the very limited amount of entropy sources available to a CPE that Joe
Sixpack just pulled out of a Best Buy shopping bag.  Witness the truly huge
pile of CPE that generate horribly insecure weak self-signed certs for https....
-------------- 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/20131016/06d9590a/attachment.bin>

From marka at isc.org  Wed Oct 16 13:12:03 2013
From: marka at isc.org (Mark Andrews)
Date: Thu, 17 Oct 2013 00:12:03 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Wed, 16 Oct 2013 08:59:21 -0400."
 <199168.1381928361@turing-police.cc.vt.edu>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org> <8738o2poov.fsf@nemi.mork.no>
 <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>
 <87mwmao693.fsf@nemi.mork.no> <20131016075029.E6C0F83ED85@rock.dv.isc.org>
 <199168.1381928361@turing-police.cc.vt.edu>
Message-ID: <20131016131203.C2D13842543@rock.dv.isc.org>


In message <199168.1381928361 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu
 writes:
> 
> On Wed, 16 Oct 2013 18:50:29 +1100, Mark Andrews said:
> 
> > I can see this being done completely automatically by the CPE device.
> > It is trivial to code.  It just required ISP's to *allow* it to happen.
> 
> The rest of the plan looks OK at first glance.. However, step 0:
> 
> > * CPE generates a RSA key pair.  Stores this in non-volatile memory.
> >   [needs to be coded, no protocol work required]
> 
> has proven to be a lot harder to do in the field than one might expect, due
> to the very limited amount of entropy sources available to a CPE that Joe
> Sixpack just pulled out of a Best Buy shopping bag.  Witness the truly huge
> pile of CPE that generate horribly insecure weak self-signed certs for https.
> ...
 
Which is easily solvable when you design the CPE device to have
good sources of hardware randomness.  CPE devices are no longer
just routers which shuffle packets.  There are lots of activities
that CPE deviced do that require good randomness and it only costs
a couple of cents to add it the devices.


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


From Joshua_Sholes at cable.comcast.com  Wed Oct 16 13:24:52 2013
From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua)
Date: Wed, 16 Oct 2013 13:24:52 +0000
Subject: =?Windows-1252?Q?Re:_15_Years_ago_today=8A.?=
In-Reply-To: <D0E2B9E245F287479153934106DC152824C3EB8D@CH1PRD0710MB393.namprd07.prod.outlook.com>
Message-ID: <E308E99A91FF544B9DB12A15496C631433B20AC0@PACDCEXMB04.cable.comcast.com>

I'm kinda in the same boat as Warren -- I'm 34, and I remember that one of
the first things that I read on the NANOG list (having signed up towards
the end of my first summer internship) was the news of Jon's death.

I'm also with Laurence -- the fact that a lot of younger people said "who"
is an opportunity for instruction, not a reason to abandon memorials.

More importantly, speaking of younger folks on the list, this is a good
reminder to ask yourself:  "What can I do to be the kind of inspirational
figure that Jon was?"  Sure, it's a high bar, but those are worth jumping
for.


-- 
Josh Sholes




On 10/16/13 3:32 AM, "Celeste Anderson" <celestea at usc.edu> wrote:

>Rodney, et al.,
>
>Am glad to be an old person who does remember Jon.  If anyone has special
>remembrances of Jon and his contributions to networking, please send to
>me offline.  We are preparing some material to be presented at a tribute
>later this month.
>
>Celeste Anderson
>Director, Los Nettos
>USC-ITS
>celestea at usc.edu
>________________________________________
>From: Rodney Joffe [rjoffe at centergate.com]
>Sent: Tuesday, October 15, 2013 9:13 PM
>To: NANOG
>Subject: 15 Years ago today?.
>
>... we lost Jon.
>
>http://www.ietf.org/rfc/rfc2468.txt
>
><sigh>
>
>Given the number of young people in the community who, last year, said
>"Who?", maybe its time to stop the reminders.
>
>This world is *so* different to the way it was. Getting old sucks.
>
>
>



From jra at baylink.com  Wed Oct 16 16:06:24 2013
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 16 Oct 2013 12:06:24 -0400 (EDT)
Subject: IRC SASL Auth borked over Sprint 4G
Message-ID: <11042036.1799.1381939584253.JavaMail.root@benjamin.baylink.com>

Both WiMax and LTE, as far as I can tell, block SASL auth somehow, such that
while tethered through my Galaxy S4 (and my old Evo 4G), I can't log into
Freenode.

Does anyone here know why, or of a workaround?

This is -- According To Google -- a well known, pervasive problem.

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 sam at circlenet.us  Wed Oct 16 16:12:16 2013
From: sam at circlenet.us (Sam Moats)
Date: Wed, 16 Oct 2013 12:12:16 -0400
Subject: IRC SASL Auth borked over Sprint 4G
In-Reply-To: <11042036.1799.1381939584253.JavaMail.root@benjamin.baylink.com>
References: <11042036.1799.1381939584253.JavaMail.root@benjamin.baylink.com>
Message-ID: <660fca543e9ca31bf38edf95c5e61f28@www.circlenet.us>

We had an IBM Proventia IPS system on one network that I was 
responsible for. Despite our best configuration efforts it insisted on 
sending TCP resets to both sides with the counterparties IP address in 
the source whenever we tried SASL. I never did get a firm answer as to 
why. Perhaps it's a similar issue?
Sam Moats


On 2013-10-16 12:06, Jay Ashworth wrote:
> Both WiMax and LTE, as far as I can tell, block SASL auth somehow, 
> such that
> while tethered through my Galaxy S4 (and my old Evo 4G), I can't log 
> into
> Freenode.
>
> Does anyone here know why, or of a workaround?
>
> This is -- According To Google -- a well known, pervasive problem.
>
> Cheers,
> -- jra



From wbailey at satelliteintelligencegroup.com  Wed Oct 16 16:21:59 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Wed, 16 Oct 2013 16:21:59 +0000
Subject: IRC SASL Auth borked over Sprint 4G
In-Reply-To: <660fca543e9ca31bf38edf95c5e61f28@www.circlenet.us>
References: <11042036.1799.1381939584253.JavaMail.root@benjamin.baylink.com>,
 <660fca543e9ca31bf38edf95c5e61f28@www.circlenet.us>
Message-ID: <u526kccfbcxn6d5mt38lsnen.1381940514325@email.android.com>

Ashworth.. Are you a loyal bitchx user or are you willing to use webchat Irc? I wish they had such magical things when I was on Irc.. We were stuck trying to make winsock functiom so mIRC would work.. ;)


Sent from my Mobile Device.


-------- Original message --------
From: Sam Moats <sam at circlenet.us>
Date: 10/16/2013 9:15 AM (GMT-08:00)
To: nanog at nanog.org
Subject: Re: IRC SASL Auth borked over Sprint 4G


We had an IBM Proventia IPS system on one network that I was
responsible for. Despite our best configuration efforts it insisted on
sending TCP resets to both sides with the counterparties IP address in
the source whenever we tried SASL. I never did get a firm answer as to
why. Perhaps it's a similar issue?
Sam Moats


On 2013-10-16 12:06, Jay Ashworth wrote:
> Both WiMax and LTE, as far as I can tell, block SASL auth somehow,
> such that
> while tethered through my Galaxy S4 (and my old Evo 4G), I can't log
> into
> Freenode.
>
> Does anyone here know why, or of a workaround?
>
> This is -- According To Google -- a well known, pervasive problem.
>
> Cheers,
> -- jra



From cody at killsudo.info  Wed Oct 16 16:26:42 2013
From: cody at killsudo.info (Cody Rose)
Date: Wed, 16 Oct 2013 11:26:42 -0500
Subject: IRC SASL Auth borked over Sprint 4G
In-Reply-To: <11042036.1799.1381939584253.JavaMail.root@benjamin.baylink.com>
References: <11042036.1799.1381939584253.JavaMail.root@benjamin.baylink.com>
Message-ID: <b25a3756-09f7-45f5-8c19-d2dca4ba8a49@email.android.com>

You can always setup a bip irc box then point your clients at bip so they can stay in sync using one irc handle and central logging on the server.

https://projects.duckcorp.org/projects/bip

Should be able to configure bip to use 443 with SSL for client connections to by pass the block.

--Cody


Jay Ashworth <jra at baylink.com> wrote:
>Both WiMax and LTE, as far as I can tell, block SASL auth somehow, such
>that
>while tethered through my Galaxy S4 (and my old Evo 4G), I can't log
>into
>Freenode.
>
>Does anyone here know why, or of a workaround?
>
>This is -- According To Google -- a well known, pervasive problem.
>
>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

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

From jra at baylink.com  Wed Oct 16 16:42:07 2013
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 16 Oct 2013 12:42:07 -0400 (EDT)
Subject: IRC SASL Auth borked over Sprint 4G
In-Reply-To: <u526kccfbcxn6d5mt38lsnen.1381940514325@email.android.com>
Message-ID: <11472194.1801.1381941726965.JavaMail.root@benjamin.baylink.com>

---- Original Message -----
> From: "Warren Bailey" <wbailey at satelliteintelligencegroup.com>

> Ashworth.. Are you a loyal bitchx user or are you willing to use
> webchat Irc? I wish they had such magical things when I was on Irc..
> We were stuck trying to make winsock functiom so mIRC would work.. ;)

Pidgin on both Windows and SuSE; AndroIRC on my phone. 

I can use the webchat facility, yes, but hate losing the local logging;
I would prefer -- as befits this list -- to figure out why the network
won't cooperate.

Verizon LTE, for a datapoint, has no trouble with this.

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 wbailey at satelliteintelligencegroup.com  Wed Oct 16 16:46:25 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Wed, 16 Oct 2013 16:46:25 +0000
Subject: IRC SASL Auth borked over Sprint 4G
In-Reply-To: <11472194.1801.1381941726965.JavaMail.root@benjamin.baylink.com>
Message-ID: <CE8410DF.B6DA%wbailey@satelliteintelligencegroup.com>

My cousin is the VP Of Mobility Data at AT&T. I'll forward to see what he
thinks.

On 10/16/13 9:42 AM, "Jay Ashworth" <jra at baylink.com> wrote:

>---- Original Message -----
>> From: "Warren Bailey" <wbailey at satelliteintelligencegroup.com>
>
>> Ashworth.. Are you a loyal bitchx user or are you willing to use
>> webchat Irc? I wish they had such magical things when I was on Irc..
>> We were stuck trying to make winsock functiom so mIRC would work.. ;)
>
>Pidgin on both Windows and SuSE; AndroIRC on my phone.
>
>I can use the webchat facility, yes, but hate losing the local logging;
>I would prefer -- as befits this list -- to figure out why the network
>won't cooperate.
>
>Verizon LTE, for a datapoint, has no trouble with this.
>
>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 feldman at nanog.org  Wed Oct 16 19:31:16 2013
From: feldman at nanog.org (Steven Feldman)
Date: Wed, 16 Oct 2013 12:31:16 -0700
Subject: [NANOG-announce] Additional committee announcement
Message-ID: <CAHo4sWWRZ53RbD16oAFpeVHSWzdFKmn-e+WUidGphygN=MmY=g@mail.gmail.com>

In yesterday's announcement on committee selections, we forgot to
mention that Matt Griswold has also been reappointed to the
Communications Committee for a two-year term.

Thanks again to everyone who volunteered.

On behalf of the Board,

        Steve Feldman, vice-chair

_______________________________________________
NANOG-announce mailing list
NANOG-announce at mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce


From m.hallgren at free.fr  Wed Oct 16 20:18:25 2013
From: m.hallgren at free.fr (Michael Hallgren)
Date: Wed, 16 Oct 2013 22:18:25 +0200
Subject: IRC SASL Auth borked over Sprint 4G
In-Reply-To: <b25a3756-09f7-45f5-8c19-d2dca4ba8a49@email.android.com>
References: <11042036.1799.1381939584253.JavaMail.root@benjamin.baylink.com>
 <b25a3756-09f7-45f5-8c19-d2dca4ba8a49@email.android.com>
Message-ID: <525EF491.9040902@free.fr>

Le 16/10/2013 18:26, Cody Rose a ?crit :
> You can always setup a bip irc box then point your clients at bip so they can stay in sync using one irc handle and central logging on the server.
>
> https://projects.duckcorp.org/projects/bip
>
> Should be able to configure bip to use 443 with SSL for client connections to by pass the block.

"pass the block"? Isn't 4G globally promoted as "Internet access." Me
missing subtleties? :-)

Cheers,
mh

>
> --Cody
>
>
> Jay Ashworth <jra at baylink.com> wrote:
>> Both WiMax and LTE, as far as I can tell, block SASL auth somehow, such
>> that
>> while tethered through my Galaxy S4 (and my old Evo 4G), I can't log
>> into
>> Freenode.
>>
>> Does anyone here know why, or of a workaround?
>>
>> This is -- According To Google -- a well known, pervasive problem.
>>
>> 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 tshortal at umd.edu  Wed Oct 16 13:30:53 2013
From: tshortal at umd.edu (Timothy Shortall)
Date: Wed, 16 Oct 2013 13:30:53 +0000
Subject: =?Windows-1252?Q?RE:_15_Years_ago_today=8A.?=
In-Reply-To: <E308E99A91FF544B9DB12A15496C631433B20AC0@PACDCEXMB04.cable.comcast.com>
References: <D0E2B9E245F287479153934106DC152824C3EB8D@CH1PRD0710MB393.namprd07.prod.outlook.com>
 <E308E99A91FF544B9DB12A15496C631433B20AC0@PACDCEXMB04.cable.comcast.com>
Message-ID: <955D482599A7A640A8F9D9DE7C45C2C40A8F5D78@OITMX1006.AD.UMD.EDU>

Well said, Josh!  I second that sentiment, and something about standing on the shoulders of those giants who came before us is resonating.

Regards,
Timothy Shortall
Assistant Director, Network Infrastructure and Services
Division of Information Technology
University of Maryland at College Park
(301) 405-2994
tshortal at umd.edu


-----Original Message-----
From: Sholes, Joshua [mailto:Joshua_Sholes at cable.comcast.com] 
Sent: Wednesday, October 16, 2013 9:25 AM
To: NANOG
Subject: Re: 15 Years ago today?.

I'm kinda in the same boat as Warren -- I'm 34, and I remember that one of
the first things that I read on the NANOG list (having signed up towards
the end of my first summer internship) was the news of Jon's death.

I'm also with Laurence -- the fact that a lot of younger people said "who"
is an opportunity for instruction, not a reason to abandon memorials.

More importantly, speaking of younger folks on the list, this is a good
reminder to ask yourself:  "What can I do to be the kind of inspirational
figure that Jon was?"  Sure, it's a high bar, but those are worth jumping
for.


-- 
Josh Sholes




On 10/16/13 3:32 AM, "Celeste Anderson" <celestea at usc.edu> wrote:

>Rodney, et al.,
>
>Am glad to be an old person who does remember Jon.  If anyone has special
>remembrances of Jon and his contributions to networking, please send to
>me offline.  We are preparing some material to be presented at a tribute
>later this month.
>
>Celeste Anderson
>Director, Los Nettos
>USC-ITS
>celestea at usc.edu
>________________________________________
>From: Rodney Joffe [rjoffe at centergate.com]
>Sent: Tuesday, October 15, 2013 9:13 PM
>To: NANOG
>Subject: 15 Years ago today?.
>
>... we lost Jon.
>
>http://www.ietf.org/rfc/rfc2468.txt
>
><sigh>
>
>Given the number of young people in the community who, last year, said
>"Who?", maybe its time to stop the reminders.
>
>This world is *so* different to the way it was. Getting old sucks.
>
>
>




From sandy at tislabs.com  Wed Oct 16 21:11:59 2013
From: sandy at tislabs.com (sandy at tislabs.com)
Date: Wed, 16 Oct 2013 17:11:59 -0400 (EDT)
Subject: =?utf-8?Q?15_Years_ago_today=E2=80=A6.?=
Message-ID: <20131016211159.517B31F8034@nova.tislabs.com>

>... we lost Jon.
>...
>Given the number of young people in the community who, last year,
>said "Who?", maybe its time to stop the reminders.

Given the impact of the person, and the philosophy he ingrained in the
design of the Internet, any hint that people are beginning to forget
should motivate more frequent reminders, or tutorials, or entry quizes,
or something.

My own acquaintance with Jon was slight, but I can see his foundation
in things I care about.

--Sandy


From mpalmer at hezmatt.org  Wed Oct 16 21:25:47 2013
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Thu, 17 Oct 2013 08:25:47 +1100
Subject: comcast ipv6 PTR
In-Reply-To: <20131016131203.C2D13842543@rock.dv.isc.org>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <8738o2poov.fsf@nemi.mork.no>
 <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>
 <87mwmao693.fsf@nemi.mork.no>
 <20131016075029.E6C0F83ED85@rock.dv.isc.org>
 <199168.1381928361@turing-police.cc.vt.edu>
 <20131016131203.C2D13842543@rock.dv.isc.org>
Message-ID: <20131016212547.GC31165@hezmatt.org>

On Thu, Oct 17, 2013 at 12:12:03AM +1100, Mark Andrews wrote:
> In message <199168.1381928361 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu
>  writes:
> > On Wed, 16 Oct 2013 18:50:29 +1100, Mark Andrews said:
> > > * CPE generates a RSA key pair.  Stores this in non-volatile memory.
> > >   [needs to be coded, no protocol work required]
> > 
> > has proven to be a lot harder to do in the field than one might expect, due
> > to the very limited amount of entropy sources available to a CPE that Joe
> > Sixpack just pulled out of a Best Buy shopping bag.  Witness the truly huge
> > pile of CPE that generate horribly insecure weak self-signed certs for https.
> > ...
>  
> Which is easily solvable when you design the CPE device to have
> good sources of hardware randomness.  CPE devices are no longer
> just routers which shuffle packets.  There are lots of activities
> that CPE deviced do that require good randomness and it only costs
> a couple of cents to add it the devices.

I'm sure the NSA would be happy to chip in to ensure that the best[0]
possible source of randomness is available.

- Matt

[0] *Who* the decision is best for is left open to the imagination.

-- 
Generally the folk who love the environment in vague, frilly ways are at
odds with folk who love the environment next to the mashed potatoes.
		-- Anthony de Boer, in a place that does not exist



From pauldotwall at gmail.com  Wed Oct 16 21:28:15 2013
From: pauldotwall at gmail.com (Paul WALL)
Date: Wed, 16 Oct 2013 17:28:15 -0400
Subject: IRC SASL Auth borked over Sprint 4G
In-Reply-To: <11042036.1799.1381939584253.JavaMail.root@benjamin.baylink.com>
References: <11042036.1799.1381939584253.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAHnQ7e+88_5JQKgAH9NL+vBsnEEePTLsj=MoDPs6tErQ3KE1Gg@mail.gmail.com>

Try reaching out to Bob Azzi?


On Wed, Oct 16, 2013 at 12:06 PM, Jay Ashworth <jra at baylink.com> wrote:

> Both WiMax and LTE, as far as I can tell, block SASL auth somehow, such
> that
> while tethered through my Galaxy S4 (and my old Evo 4G), I can't log into
> Freenode.
>
> Does anyone here know why, or of a workaround?
>
> This is -- According To Google -- a well known, pervasive problem.
>
> 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 morrowc.lists at gmail.com  Wed Oct 16 22:16:51 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 16 Oct 2013 18:16:51 -0400
Subject: IRC SASL Auth borked over Sprint 4G
In-Reply-To: <CAHnQ7e+88_5JQKgAH9NL+vBsnEEePTLsj=MoDPs6tErQ3KE1Gg@mail.gmail.com>
References: <11042036.1799.1381939584253.JavaMail.root@benjamin.baylink.com>
 <CAHnQ7e+88_5JQKgAH9NL+vBsnEEePTLsj=MoDPs6tErQ3KE1Gg@mail.gmail.com>
Message-ID: <CAL9jLaYz+kYwh0Vj6qo=48RYFc56+QVeAwNb=CJHE-B0BC9n3Q@mail.gmail.com>

On Wed, Oct 16, 2013 at 5:28 PM, Paul WALL <pauldotwall at gmail.com> wrote:
> Bob Azzi

low blow capt wall... you know mr azzi will simply call ashworth the
criminal he is for stealing that bandwidth.

in all seriousness, it's possible (absent tcpdump evidence of tcp
resets) that this is a fairly well known sprint-wireless dns problem.


From marka at isc.org  Wed Oct 16 23:03:42 2013
From: marka at isc.org (Mark Andrews)
Date: Thu, 17 Oct 2013 10:03:42 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Thu, 17 Oct 2013 08:25:47 +1100."
 <20131016212547.GC31165@hezmatt.org>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org> <8738o2poov.fsf@nemi.mork.no>
 <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>
 <87mwmao693.fsf@nemi.mork.no> <20131016075029.E6C0F83ED85@rock.dv.isc.org>
 <199168.1381928361@turing-police.cc.vt.edu>
 <20131016131203.C2D13842543@rock.dv.isc.org>
 <20131016212547.GC31165@hezmatt.org>
Message-ID: <20131016230342.9C31B849B4D@rock.dv.isc.org>


In message <20131016212547.GC31165 at hezmatt.org>, Matt Palmer writes:
> On Thu, Oct 17, 2013 at 12:12:03AM +1100, Mark Andrews wrote:
> > In message <199168.1381928361 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt
> .edu
> >  writes:
> > > On Wed, 16 Oct 2013 18:50:29 +1100, Mark Andrews said:
> > > > * CPE generates a RSA key pair.  Stores this in non-volatile memory.
> > > >   [needs to be coded, no protocol work required]
> > > 
> > > has proven to be a lot harder to do in the field than one might expect, d
> ue
> > > to the very limited amount of entropy sources available to a CPE that Joe
> > > Sixpack just pulled out of a Best Buy shopping bag.  Witness the truly hu
> ge
> > > pile of CPE that generate horribly insecure weak self-signed certs for ht
> tps.
> > > ...
> >  
> > Which is easily solvable when you design the CPE device to have
> > good sources of hardware randomness.  CPE devices are no longer
> > just routers which shuffle packets.  There are lots of activities
> > that CPE deviced do that require good randomness and it only costs
> > a couple of cents to add it the devices.
> 
> I'm sure the NSA would be happy to chip in to ensure that the best[0]
> possible source of randomness is available.
> 
> - Matt
> 
> [0] *Who* the decision is best for is left open to the imagination.

CPE devices need both battery backed time of day clocks and sources
of hardware randomness.

Modern Intel CPU's provide hardware based random numbers.  It is
not like other cpu manufactures can't do the same thing.  This
doesn't increase the chip count or pcb real estate used.

It's time CPE Router vendors did a re-think.

Mark

> -- 
> Generally the folk who love the environment in vague, frilly ways are at
> odds with folk who love the environment next to the mashed potatoes.
> 		-- Anthony de Boer, in a place that does not exist
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From lyndon at orthanc.ca  Wed Oct 16 23:16:07 2013
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Wed, 16 Oct 2013 16:16:07 -0700
Subject: comcast ipv6 PTR
In-Reply-To: <20131016230342.9C31B849B4D@rock.dv.isc.org>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org> <8738o2poov.fsf@nemi.mork.no>
 <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>
 <87mwmao693.fsf@nemi.mork.no> <20131016075029.E6C0F83ED85@rock.dv.isc.org>
 <199168.1381928361@turing-police.cc.vt.edu>
 <20131016131203.C2D13842543@rock.dv.isc.org>
 <20131016212547.GC31165@hezmatt.org>
 <20131016230342.9C31B849B4D@rock.dv.isc.org>
Message-ID: <96674964-CE5B-4462-AB5C-4CC27351E40C@orthanc.ca>


On 2013-10-16, at 4:03 PM, Mark Andrews <marka at isc.org> wrote:

> Modern Intel CPU's provide hardware based random numbers.

Randomness vetted by whom? :-P  


From marka at isc.org  Wed Oct 16 23:25:00 2013
From: marka at isc.org (Mark Andrews)
Date: Thu, 17 Oct 2013 10:25:00 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Wed, 16 Oct 2013 16:16:07 -0700."
 <96674964-CE5B-4462-AB5C-4CC27351E40C@orthanc.ca>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org> <8738o2poov.fsf@nemi.mork.no>
 <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>
 <87mwmao693.fsf@nemi.mork.no> <20131016075029.E6C0F83ED85@rock.dv.isc.org>
 <199168.1381928361@turing-police.cc.vt.edu>
 <20131016131203.C2D13842543@rock.dv.isc.org>
 <20131016212547.GC31165@hezmatt.org>
 <20131016230342.9C31B849B4D@rock.dv.isc.org>
 <96674964-CE5B-4462-AB5C-4CC27351E40C@orthanc.ca>
Message-ID: <20131016232500.B189A84A084@rock.dv.isc.org>


In message <96674964-CE5B-4462-AB5C-4CC27351E40C at orthanc.ca>, Lyndon Nerenberg 
writes:
> 
> On 2013-10-16, at 4:03 PM, Mark Andrews <marka at isc.org> wrote:
> 
> > Modern Intel CPU's provide hardware based random numbers.
> 
> Randomness vetted by whom? :-P  

I really don't care for this purpose.  I'm much more worries about the
image being tampered with than the hardware random number generator.

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


From email at edylie.net  Thu Oct 17 04:24:20 2013
From: email at edylie.net (Pui Edylie)
Date: Thu, 17 Oct 2013 12:24:20 +0800
Subject: Anyone has google contact?
Message-ID: <525F6674.6040602@edylie.net>

Good Day,

We are a small ISP in Indonesia and due to limited IPv4 we are natting 
our users to a single IPv4.

It seems like Google search engine does not like this and mark our users 
as bot when they are visiting the search engine.

I have tried to reach out the support pages but not could get hold of 
anyone.

May I know if anyone could kindly share a google contact on this?

Thanks!

Best,
Edy



From nst at google.com  Thu Oct 17 04:33:02 2013
From: nst at google.com (Google NST)
Date: Thu, 17 Oct 2013 15:33:02 +1100
Subject: Anyone has google contact?
In-Reply-To: <525F6674.6040602@edylie.net>
References: <525F6674.6040602@edylie.net>
Message-ID: <CABZte2tCQkDhrycBc9D9YfMtqqrqiW2WUZ2dknHZv1M8qXSNtw@mail.gmail.com>

Hello,

  Please contact noc at google.com

Thanks

Jon


On Thu, Oct 17, 2013 at 3:24 PM, Pui Edylie <email at edylie.net> wrote:

> Good Day,
>
> We are a small ISP in Indonesia and due to limited IPv4 we are natting our
> users to a single IPv4.
>
> It seems like Google search engine does not like this and mark our users
> as bot when they are visiting the search engine.
>
> I have tried to reach out the support pages but not could get hold of
> anyone.
>
> May I know if anyone could kindly share a google contact on this?
>
> Thanks!
>
> Best,
> Edy
>
> --
>
> Jon Fairall | Network Surveillance Team | nst at google.com | +1 855 GOOGNET
> (US), +353-1-543-1500 (EU)

From morrowc.lists at gmail.com  Thu Oct 17 04:41:33 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 17 Oct 2013 00:41:33 -0400
Subject: Anyone has google contact?
In-Reply-To: <CABZte2tCQkDhrycBc9D9YfMtqqrqiW2WUZ2dknHZv1M8qXSNtw@mail.gmail.com>
References: <525F6674.6040602@edylie.net>
 <CABZte2tCQkDhrycBc9D9YfMtqqrqiW2WUZ2dknHZv1M8qXSNtw@mail.gmail.com>
Message-ID: <CAL9jLaYYWZF-7mEUY=Gy1yMeBHH1w8SxgrWtK9tfUvRO4CUjcA@mail.gmail.com>

win

On Thu, Oct 17, 2013 at 12:33 AM, Google NST <nst at google.com> wrote:
> Hello,
>
>   Please contact noc at google.com
>
> Thanks
>
> Jon
>
>
> On Thu, Oct 17, 2013 at 3:24 PM, Pui Edylie <email at edylie.net> wrote:
>
>> Good Day,
>>
>> We are a small ISP in Indonesia and due to limited IPv4 we are natting our
>> users to a single IPv4.
>>
>> It seems like Google search engine does not like this and mark our users
>> as bot when they are visiting the search engine.
>>
>> I have tried to reach out the support pages but not could get hold of
>> anyone.
>>
>> May I know if anyone could kindly share a google contact on this?
>>
>> Thanks!
>>
>> Best,
>> Edy
>>
>> --
>>
>> Jon Fairall | Network Surveillance Team | nst at google.com | +1 855 GOOGNET
>> (US), +353-1-543-1500 (EU)


From randy at psg.com  Thu Oct 17 07:53:28 2013
From: randy at psg.com (Randy Bush)
Date: Thu, 17 Oct 2013 10:53:28 +0300
Subject: 15 Years ago =?UTF-8?B?dG9kYXnigKYu?=
In-Reply-To: <20131016211159.517B31F8034@nova.tislabs.com>
References: <20131016211159.517B31F8034@nova.tislabs.com>
Message-ID: <m2iowwjptz.wl%randy@psg.com>

due to pain, people's inclination to talk about {jon, abha, itojun} may
be somewhat inversely proportional to their proximity to them.

randy


From daniel.crompton at gmail.com  Thu Oct 17 08:02:06 2013
From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=)
Date: Thu, 17 Oct 2013 10:02:06 +0200
Subject: =?UTF-8?B?UmU6IDE1IFllYXJzIGFnbyB0b2RheeKApi4=?=
In-Reply-To: <m2iowwjptz.wl%randy@psg.com>
References: <20131016211159.517B31F8034@nova.tislabs.com>
 <m2iowwjptz.wl%randy@psg.com>
Message-ID: <CALKmEuBtuFZGnn_dH=H-AshqNS2OUauyrnpqeQtxuSQFJaqOpQ@mail.gmail.com>

I hope someday I will be remembered and loved by as many people as Jon. He
sounds like a very special person.

D.


On 17 October 2013 09:53, Randy Bush <randy at psg.com> wrote:

> due to pain, people's inclination to talk about {jon, abha, itojun} may
> be somewhat inversely proportional to their proximity to them.
>
> randy
>
>


-- 
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 eugen at leitl.org  Thu Oct 17 09:45:52 2013
From: eugen at leitl.org (Eugen Leitl)
Date: Thu, 17 Oct 2013 11:45:52 +0200
Subject: comcast ipv6 PTR
In-Reply-To: <20131016230342.9C31B849B4D@rock.dv.isc.org>
References: <20131015024711.55297.qmail@joyce.lan>
 <20131015045441.5C356832A5E@rock.dv.isc.org>
 <8738o2poov.fsf@nemi.mork.no>
 <747BC821-3E94-41A5-BE73-DB262B42A46C@hopcount.ca>
 <87mwmao693.fsf@nemi.mork.no>
 <20131016075029.E6C0F83ED85@rock.dv.isc.org>
 <199168.1381928361@turing-police.cc.vt.edu>
 <20131016131203.C2D13842543@rock.dv.isc.org>
 <20131016212547.GC31165@hezmatt.org>
 <20131016230342.9C31B849B4D@rock.dv.isc.org>
Message-ID: <20131017094552.GY10405@leitl.org>

On Thu, Oct 17, 2013 at 10:03:42AM +1100, Mark Andrews wrote:

> Modern Intel CPU's provide hardware based random numbers.  It is
> not like other cpu manufactures can't do the same thing.  This
> doesn't increase the chip count or pcb real estate used.

Specifically Intel's RNG is inauditable. It should not be used
as a single source of entropy, but always mixed in with others,
unrelated sources of entropy.

There used to be an USB stick RNG called Entropykey, but that one
is currently unavailable.

A cheap/improvised, trusted way to get some physical entropy could be 
USB SDRs http://sdr.osmocom.org/trac/wiki/rtl-sdr 
especially if hooked up to an analog wideband white noise generator
http://www.maximintegrated.com/app-notes/index.mvp/id/3469
instead of just listening to the aether.

Never use entropy as is, mix it into a PRNG, use as many
entropy sources as you can. Packet timing (IRQs) can be
a source of entropy in a network device.
 
> It's time CPE Router vendors did a re-think.


From Lee at asgard.org  Wed Oct 16 10:43:56 2013
From: Lee at asgard.org (Lee Howard)
Date: Wed, 16 Oct 2013 11:43:56 +0100
Subject: comcast ipv6 PTR
In-Reply-To: <87iowyo4yn.fsf@nemi.mork.no>
Message-ID: <CE842AAF.332DD%Lee@asgard.org>



On 10/15/13 5:48 PM, "Bj?rn Mork" <bjorn at mork.no> wrote:

>
>No, renumbering is not going to be seemless.  Yes, a smarter person
>could automate everything I list above, but we all know that's not going
>to happen.

The 6renum WG at IETF just closed, with a list of work items remaining for
other WGs to complete.  I recommend RFC6879 in particular, with RFC6866
describing some parts of the problems and RFC7010 being the outstanding
work.

The IETF has generally been taken as an assumption that the home network
is 

unmanaged (see the Homenet charter and architecture document, for
instance).
The administrator of a managed network can follow RFC6879 and renumber
pretty seamlessly.  In the unmanaged home, since everything is automatic,
renumbering should be seamless.  Yes, more tools are needed (thus RFC7010).

Lee




From aledm at qix.co.uk  Thu Oct 17 11:46:56 2013
From: aledm at qix.co.uk (Aled Morris)
Date: Thu, 17 Oct 2013 12:46:56 +0100
Subject: Anyone has google contact?
In-Reply-To: <525F6674.6040602@edylie.net>
References: <525F6674.6040602@edylie.net>
Message-ID: <CAO1bj=YeKvr_PfLpXWJrU+QjjC6uyN+5LRfi231TSmUAdbjynA@mail.gmail.com>

Google is reachable via IPv6 too, you shouldn't have any problems giving
all your customers unique, fixed, IPv6 addresses.

Aled


On 17 October 2013 05:24, Pui Edylie <email at edylie.net> wrote:

> Good Day,
>
> We are a small ISP in Indonesia and due to limited IPv4 we are natting our
> users to a single IPv4.
>
> It seems like Google search engine does not like this and mark our users
> as bot when they are visiting the search engine.
>
> I have tried to reach out the support pages but not could get hold of
> anyone.
>
> May I know if anyone could kindly share a google contact on this?
>
> Thanks!
>
> Best,
> Edy
>
>
>

From bjorn at mork.no  Thu Oct 17 12:44:56 2013
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Thu, 17 Oct 2013 14:44:56 +0200
Subject: comcast ipv6 PTR
In-Reply-To: <CE842AAF.332DD%Lee@asgard.org> (Lee Howard's message of "Wed, 16
 Oct 2013 11:43:56 +0100")
References: <CE842AAF.332DD%Lee@asgard.org>
Message-ID: <87y55sjcc7.fsf@nemi.mork.no>

Lee Howard <Lee at asgard.org> writes:

> The 6renum WG at IETF just closed, with a list of work items remaining for
> other WGs to complete.  I recommend RFC6879 in particular, with RFC6866
> describing some parts of the problems and RFC7010 being the outstanding
> work.
>
> The IETF has generally been taken as an assumption that the home network
> is 
>
> unmanaged (see the Homenet charter and architecture document, for
> instance).
> The administrator of a managed network can follow RFC6879 and renumber
> pretty seamlessly.

Yes, given
 - careful planning
 - smart macro usage
 - some scripting

Feel free to show me a typical business site with more than 2 of those
in place...

FWIW, I did a little exercise on my home network, running just a few
basic services which I assume most businesses will run as well. This
resulted in a number of text configuration file formats requiring
requiring knowlegde of the prefix list (i.e. not suitable for DNS
names):
 - spamassasin (trusted_networks)
 - BIND (recursion allowed acl)
 - sendmail (relaying access)
 - ntp (peer access)
 - cups (printer access)
 - squid (http proxy access)

All of these use different configuration syntax and generally do not
support macro expansion of the prefix.  So you'd have to script any
updates.

I'm in particular fond of the sendmail and ntp syntaxes, which can best
be described as "weird".

sendmail:
 IPv6:2001:0db8:0f00     RELAY

ntp:
 restrict 2001:db8:f00:: mask ffff:ffff:ffff:: nomodify

When you can't even standardize on a prefix syntax, how the heck are you
going to make renumbering seamless??

> In the unmanaged home, since everything is automatic, renumbering
> should be seamless.

Most homes will have at least one manually configured IP device. Typical
candidates are 
 - printers
 - media (video and/or audio) playback devices
 - additional wlan access points

We can close our eyes and ignore them, but they are still there.  Yes,
yes, the firmware programmers are going to get much much smarter when
they add IPv6 to these devices.  I'm sure.

I'm still in favour of reducing the renumbering burden as much as
possible, even for home networks.


Bj?rn


From rps at maine.edu  Thu Oct 17 13:23:27 2013
From: rps at maine.edu (Ray Soucy)
Date: Thu, 17 Oct 2013 09:23:27 -0400
Subject: =?windows-1252?Q?Re=3A_15_Years_ago_today=85=2E?=
In-Reply-To: <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
References: <4DF7DC2753C30C419FFB7C0024155BFD0B746253@stntexmb11.cis.neustar.com>
 <2BD6FE78-7354-465A-8D1C-0D8316612F5D@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B74634A@stntexmb11.cis.neustar.com>
 <3E930AD6-EDC5-43D2-90AA-F2F09D7196F1@neustar.biz>
 <9926C84F-2224-45D4-9FC6-D82D5523A1BC@neustar.biz>
 <825F45E1-EF94-4396-98D2-60BCD1F25550@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B748F04@stntexmb11.cis.neustar.com>
 <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
Message-ID: <CALFTrnOaW1MmV0i2W9JpLr30mnUMyMrq=8-d60TDm-9zK8pSbQ@mail.gmail.com>

Thank you for posting this. I was born in 1984 and had no idea.  I've spent
the last day or so reading up on Jon Postel and his work.  What an amazing
guy.


On Wed, Oct 16, 2013 at 12:13 AM, Rodney Joffe <rjoffe at centergate.com>wrote:

> ... we lost Jon.
>
> http://www.ietf.org/rfc/rfc2468.txt
>
> <sigh>
>
> Given the number of young people in the community who, last year, said
> "Who?", maybe its time to stop the reminders.
>
> This world is *so* different to the way it was. Getting old sucks.
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

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

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

From jra at baylink.com  Thu Oct 17 14:00:20 2013
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 17 Oct 2013 10:00:20 -0400 (EDT)
Subject: =?utf-8?Q?Re:_15_Years_ago_today=E2=80=A6.?=
In-Reply-To: <CALFTrnOaW1MmV0i2W9JpLr30mnUMyMrq=8-d60TDm-9zK8pSbQ@mail.gmail.com>
Message-ID: <3218677.1907.1382018420050.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Ray Soucy" <rps at maine.edu>

> Thank you for posting this. I was born in 1984 and had no idea. I've
> spent
> the last day or so reading up on Jon Postel and his work. What an
> amazing
> guy.

Your work here is done, Rod. 

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 lists at peterva.net  Thu Oct 17 15:14:53 2013
From: lists at peterva.net (Peter van Arkel)
Date: Thu, 17 Oct 2013 17:14:53 +0200
Subject: 15 Years ago =?windows-1252?Q?today=85=2E?=
In-Reply-To: <CALFTrnOaW1MmV0i2W9JpLr30mnUMyMrq=8-d60TDm-9zK8pSbQ@mail.gmail.com>
References: <4DF7DC2753C30C419FFB7C0024155BFD0B746253@stntexmb11.cis.neustar.com>
 <2BD6FE78-7354-465A-8D1C-0D8316612F5D@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B74634A@stntexmb11.cis.neustar.com>
 <3E930AD6-EDC5-43D2-90AA-F2F09D7196F1@neustar.biz>
 <9926C84F-2224-45D4-9FC6-D82D5523A1BC@neustar.biz>
 <825F45E1-EF94-4396-98D2-60BCD1F25550@neustar.biz>
 <4DF7DC2753C30C419FFB7C0024155BFD0B748F04@stntexmb11.cis.neustar.com>
 <A417E1CA-58F6-4C1C-A054-350C61D36066@centergate.com>
 <CALFTrnOaW1MmV0i2W9JpLr30mnUMyMrq=8-d60TDm-9zK8pSbQ@mail.gmail.com>
Message-ID: <525FFEED.1090908@peterva.net>

Op 17-10-2013 15:23, Ray Soucy schreef:
> Thank you for posting this. I was born in 1984 and had no idea.  I've spent
> the last day or so reading up on Jon Postel and his work.  What an amazing
> guy.

Hear, hear.

I'm from 1987 and I would never have heard about Jon Postel if it
weren't for this list. IMHO, we should keep remembering people like him,
us younger people in particular.

- Peter



From joquendo at e-fensive.net  Thu Oct 17 15:46:28 2013
From: joquendo at e-fensive.net (J. Oquendo)
Date: Thu, 17 Oct 2013 10:46:28 -0500
Subject: SDSU Contact
Message-ID: <20131017154628.GA72052@e-fensive.net>

Anyone with a direct contact at SDSU preferrably security.


-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

42B0 5A53 6505 6638 44BB  3943 2BF7 D83F 210A 95AF
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF


From cloos at jhcloos.com  Thu Oct 17 20:17:39 2013
From: cloos at jhcloos.com (James Cloos)
Date: Thu, 17 Oct 2013 16:17:39 -0400
Subject: comcast ipv6 PTR
In-Reply-To: <20131015024711.55297.qmail@joyce.lan> (John Levine's message of
 "15 Oct 2013 02:47:11 -0000")
References: <20131015024711.55297.qmail@joyce.lan>
Message-ID: <m3vc0v3b43.fsf@carbon.jhcloos.org>

>>>>> "JL" == John Levine <johnl at iecc.com> writes:

JL> but normal user machines do SLAAC where the low 64 bits of the
JL> address are quasi-random.  To get any sort of DNS you'd need for
JL> the routers to watch when new hosts come on line and somehow tell
JL> the relevant DNS servers what hosts need names.

One of the arguments put forward by those who prefer dhcp6 was that the
dhcp6 server could do that for any leases.  Just like for dhcp4.

For SLAAC, something based on mdns might do?  Ie, a multicast address
where a box can announce that it just joined the lan at a specified v6.

That also might be reasonable for privacy addresses.

-JimC  (just brainstorming)
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6




From marka at isc.org  Thu Oct 17 20:47:50 2013
From: marka at isc.org (Mark Andrews)
Date: Fri, 18 Oct 2013 07:47:50 +1100
Subject: comcast ipv6 PTR
In-Reply-To: Your message of "Thu, 17 Oct 2013 14:44:56 +0200."
 <87y55sjcc7.fsf@nemi.mork.no>
References: <CE842AAF.332DD%Lee@asgard.org> <87y55sjcc7.fsf@nemi.mork.no>
Message-ID: <20131017204750.B19CC851BBC@rock.dv.isc.org>


In message <87y55sjcc7.fsf at nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> Lee Howard <Lee at asgard.org> writes:
>
> > The 6renum WG at IETF just closed, with a list of work items remaining
> for
> > other WGs to complete.  I recommend RFC6879 in particular, with RFC6866
> > describing some parts of the problems and RFC7010 being the outstanding
> > work.
> >
> > The IETF has generally been taken as an assumption that the home network
> > is
> >
> > unmanaged (see the Homenet charter and architecture document, for
> > instance).
> > The administrator of a managed network can follow RFC6879 and renumber
> > pretty seamlessly.
>
> Yes, given
>  - careful planning
>  - smart macro usage
>  - some scripting
>
> Feel free to show me a typical business site with more than 2 of those
> in place...
>
> FWIW, I did a little exercise on my home network, running just a few
> basic services which I assume most businesses will run as well. This
> resulted in a number of text configuration file formats requiring
> requiring knowlegde of the prefix list (i.e. not suitable for DNS
> names):
>  - spamassasin (trusted_networks)
>  - BIND (recursion allowed acl)

Named actually looks at netmasks and prefix lengths on interfaces
and generates named acls based on those.  Named regularly scans the
interface list and adjusts the named acl based on the changes it sees.
It could use a routing socket rather than a timer to do this.

The default allow-recursion acl uses that named acl.

If the site prefix length was available to it, say via being advertised
in the RA, it would also generate a "localsite" acl.

>  - sendmail (relaying access)
>  - ntp (peer access)
>  - cups (printer access)
>  - squid (http proxy access)
>
> All of these use different configuration syntax and generally do not
> support macro expansion of the prefix.  So you'd have to script any
> updates.

> I'm in particular fond of the sendmail and ntp syntaxes, which can best
> be described as "weird".
>
> sendmail:
>  IPv6:2001:0db8:0f00     RELAY
>
> ntp:
>  restrict 2001:db8:f00:: mask ffff:ffff:ffff:: nomodify
>
> When you can't even standardize on a prefix syntax, how the heck are you
> going to make renumbering seamless??

You have a daemon that reconfigures components of the system when
new interfaces are.  I already have dhclient do this for me with
IPv4.  It already goes and talks to machines on the other side of
the world and reconfigures them because the IPv4 address my ISP is
giving me as changed.

You have templated configuration files for that daemon to use.

> > In the unmanaged home, since everything is automatic, renumbering
> > should be seamless.
>
> Most homes will have at least one manually configured IP device. Typical
> candidates are
>  - printers
>  - media (video and/or audio) playback devices
>  - additional wlan access points
>
> We can close our eyes and ignore them, but they are still there.  Yes,
> yes, the firmware programmers are going to get much much smarter when
> they add IPv6 to these devices.  I'm sure.

Firstly ULA's will save a lot of these devices as they don't need
to be visible outside of the house.  For those that do need to be
externally reachable a "Renumber Ready" campaign would help the
punter choose the right box.

> I'm still in favour of reducing the renumbering burden as much as
> possible, even for home networks.
>
>
> Bj??rn
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From mdavids at forfun.net  Fri Oct 18 06:17:05 2013
From: mdavids at forfun.net (Marco Davids (Prive))
Date: Fri, 18 Oct 2013 09:17:05 +0300
Subject: Anyone has google contact?
In-Reply-To: <525F6674.6040602@edylie.net>
References: <525F6674.6040602@edylie.net>
Message-ID: <5260D261.8040603@forfun.net>

Hi Pui,

Have seen this url?

https://support.google.com/websearch/answer/86640?hl=en

There's some contactinformation under item 4.

--
Marco


On 10/17/13 7:24 AM, Pui Edylie wrote:
> Good Day,
>
> We are a small ISP in Indonesia and due to limited IPv4 we are natting
> our users to a single IPv4.
>
> It seems like Google search engine does not like this and mark our
> users as bot when they are visiting the search engine.
>
> I have tried to reach out the support pages but not could get hold of
> anyone.
>
> May I know if anyone could kindly share a google contact on this?
>
> Thanks!
>
> Best,
> Edy
>
>



From mpetach at netflight.com  Fri Oct 18 10:02:23 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 18 Oct 2013 03:02:23 -0700
Subject: Cogent 100M DIA in Denver
In-Reply-To: <525C82D1.7060803@rollernet.us>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
 <CAPKkNb6CVEM10eK8GM7EABUFk-nUs9+7f6aCUF=msZFr19GETw@mail.gmail.com>
 <20131014211816.GA17122@wakko.typo.org>
 <CAPKkNb5wTM--u24WAiW190DRGXVXiP19+o6Yx1u2k0xR215VjQ@mail.gmail.com>
 <525C7078.6060404@staticsafe.ca> <525C82D1.7060803@rollernet.us>
Message-ID: <CAEmG1=oMA-Zc25VTqJip=3RO2gKHu1qEJqrxGYxckUUd5w+_PQ@mail.gmail.com>

On Mon, Oct 14, 2013 at 4:48 PM, Seth Mattinen <sethm at rollernet.us> wrote:

> On 10/14/13 3:30 PM, staticsafe wrote:
>
>> On 10/14/2013 18:00, Constantine A. Murenin wrote:
>>
>>> Which other provider?  Please name at least one.
>>>
>>> Other providers either offer IPv6, or don't.  When those other
>>> providers do, good or bad, you can connect to any other IPv6 network
>>> (well, except maybe for Cogent's AS174).
>>>
>>> When Cogent offers IPv6, a lot of IPv6 networks are unreachable.  No
>>> other provider comes close.
>>>
>>> I mean, even their web-site doesn't work from many IPv6-connected
>>> hosts, because there's no route for their network:
>>>
>>> li163-XXX:~# telnet cogentco.com http
>>> Trying 2001:550:1::cc01...
>>> ^C
>>> li163-XXX:~#
>>>
>>> C.
>>>
>>
>> Fremont Linode? I see it is unreachable from my ARP Networks VPS (HE v6
>> transit) and also from behind my HE tunnel at home.
>>
>>
>
> HE and Cogen't don't peer, even after the cake.
>
> ~Seth
>
>
(continues to wait patiently for "the cake is a lie"
 references...wondering if perhaps this meme has
 run its course, and gone into the great meme hereafter...}

Matt

From manavbhatia at gmail.com  Fri Oct 18 15:40:12 2013
From: manavbhatia at gmail.com (Manav Bhatia)
Date: Fri, 18 Oct 2013 21:10:12 +0530
Subject: clear forwarding route
Message-ID: <CAG1kdogOyEVeKhhDm3oOsvuHiJEnCEz=uYWjZY+DwKvKpzBLeg@mail.gmail.com>

Hi,

I would like understand the circumstances under which an operator may want
to clear all (or a subset of) the routes programmed in the forwarding table
(FIB).

I believe the command to do this on Cisco is

clear forwarding {ipv4 | ipv6} route {* | prefix} [vrf vrf-name] module
{slot| all}

I ask this since doing this would result in the router dropping all transit
traffic till the routes get reprogrammed in the FIB.

Why would somebody ever want to do this? One scenario that i can think of
is when because of a bug a route does not get programmed in the FIB and the
operator uses this command to install this once again the FIB.

Thanks, Manav

From jabley at hopcount.ca  Fri Oct 18 16:42:12 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Fri, 18 Oct 2013 12:42:12 -0400
Subject: clear forwarding route
In-Reply-To: <CAG1kdogOyEVeKhhDm3oOsvuHiJEnCEz=uYWjZY+DwKvKpzBLeg@mail.gmail.com>
References: <CAG1kdogOyEVeKhhDm3oOsvuHiJEnCEz=uYWjZY+DwKvKpzBLeg@mail.gmail.com>
Message-ID: <13394368-EEC3-444B-94B5-07D8F36BEADC@hopcount.ca>


On 2013-10-18, at 11:40, Manav Bhatia <manavbhatia at gmail.com> wrote:

> I would like understand the circumstances under which an operator may want
> to clear all (or a subset of) the routes programmed in the forwarding table
> (FIB).

Because of bugs which have led to the FIB containing data that doesn't match the RIB, and which is causing customer enragement. They don't call it CEF for nothing.

> I believe the command to do this on Cisco is
> 
> clear forwarding {ipv4 | ipv6} route {* | prefix} [vrf vrf-name] module
> {slot| all}

Cool. Back when I was chasing packets at 6461 the best we could do was

router(config)# interface blah
router(config-if)# shutdown
router(config-if)# no shutdown

> I ask this since doing this would result in the router dropping all transit
> traffic till the routes get reprogrammed in the FIB.

Seems likely!

> Why would somebody ever want to do this?

Screaming customer on the phone.


Joe

From jsmith4112003 at yahoo.co.uk  Fri Oct 18 17:32:57 2013
From: jsmith4112003 at yahoo.co.uk (John Smith)
Date: Fri, 18 Oct 2013 18:32:57 +0100 (BST)
Subject: clear forwarding route
In-Reply-To: <CAG1kdogOyEVeKhhDm3oOsvuHiJEnCEz=uYWjZY+DwKvKpzBLeg@mail.gmail.com>
References: <CAG1kdogOyEVeKhhDm3oOsvuHiJEnCEz=uYWjZY+DwKvKpzBLeg@mail.gmail.com>
Message-ID: <1382117577.13312.YahooMailNeo@web133104.mail.ir2.yahoo.com>

This is a hack that most vendors provide, just in case their code doesnt work as expected.?

Nobody in his sane mind will clear the FIB on a live router. This creates all sorts of problems. The router starts sending out ICMP errors (unreachables, etc), BFD times out, causing all hell to break lose within the domain.

It might make some sense to do this on flow based routers where you clear the FIB so that newer flows can get established in case there are hash collisions or issues in flow caches. Even in that case its an issue as all live traffic starts hitting SW before the flow can get established.

Customers, you can rest assured, will not appreciate you doing this. And its precisely for this that you never ever do this on a live router.


On Friday, 18 October 2013, 21:31, Manav Bhatia <manavbhatia at gmail.com> wrote:
Hi,

I would like understand the circumstances under which an operator may want
to clear all (or a subset of) the routes programmed in the forwarding table
(FIB).

I believe the command to do this on Cisco is

clear forwarding {ipv4 | ipv6} route {* | prefix} [vrf vrf-name] module
{slot| all}

I ask this since doing this would result in the router dropping all transit
traffic till the routes get reprogrammed in the FIB.

Why would somebody ever want to do this? One scenario that i can think of
is when because of a bug a route does not get programmed in the FIB and the
operator uses this command to install this once again the FIB.

Thanks, Manav



From me at anuragbhatia.com  Fri Oct 18 18:03:16 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Fri, 18 Oct 2013 23:33:16 +0530
Subject: Fundamental questions of backbone design
Message-ID: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>

Hello everyone


I have some fundamental questions about backbone design. Feel free to point
me to any discussions/presentation material related to these questions.



   1. As I understand it's (sort off) common practice to give highest
   localpref to customer routes then peering and finally transit. Does this
   works well or you see issues with people who have 10+ prepends on some
   peering routes calling you to not send traffic via those circuits? Does it
   makes sense to put a rule to avoid routes 2-3 AS path away when changing
   local preference?

   2. If I have more peering capacity and relatively less capacity between
   my own PoPs and I start injecting routes in my IGP then how to prevent
   change of choking of backbone? Is it standard practice to have more
   capacity on backbone then peering links? Or I have to inject less routes in
   IGP - say a few % of total routes?

   3. How can I maintain use of routes I am learning from various other
   networks (transit+peers+customer) across my IGP? Is BGP community tagging
   good way out?

   4. How is iBGP Vs OSPF for IGP? I keep on hearing that OSPF is good &
   lot more faster in changing routes during a breakdown as compared to slow
   hold time based iBGP session. Is there's more clear comparison of
   limitations of both when designing?



Appreciate your time & help.



Thanks.

-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From m.hallgren at free.fr  Fri Oct 18 19:12:24 2013
From: m.hallgren at free.fr (Michael Hallgren)
Date: Fri, 18 Oct 2013 21:12:24 +0200
Subject: Fundamental questions of backbone design
In-Reply-To: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
References: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
Message-ID: <52618818.2080204@free.fr>

Le 18/10/2013 20:03, Anurag Bhatia a ?crit :
> Hello everyone
>
>
> I have some fundamental questions about backbone design. Feel free to point
> me to any discussions/presentation material related to these questions.
>
>
>
>    1. As I understand it's (sort off) common practice to give highest
>    localpref to customer routes then peering and finally transit. Does this
>    works well or you see issues with people who have 10+ prepends on some
>    peering routes calling you to not send traffic via those circuits? Does it
>    makes sense to put a rule to avoid routes 2-3 AS path away when changing
>    local preference?

Most often, the (``traditionally'' business driven) classification that you
mention is honored and subtler differences considered (only) in cases
where LOCAL_PREFerence is the same for some candidate routes to a
destination.

There's no ``protocol law'' ruling this, it's all your choice, that you may
base on cost, performance, or any other type of metrics that you feel
relevant... For example, you may want -- as you say -- honor the hints
from neighbors (even transitively) to route over ``less prepended
paths'' (if available) to their networks. But it's up to you, and I'd
suggest
keeping a focus on performance, path stability, neighbours reactivity
in case of failure, or some such (if you can afford it) as a metric.
Else...

>
>    2. If I have more peering capacity and relatively less capacity between
>    my own PoPs and I start injecting routes in my IGP then how to prevent
>    change of choking of backbone? Is it standard practice to have more
>    capacity on backbone then peering links? Or I have to inject less routes in
>    IGP - say a few % of total routes?

What routes do you inject into your IGP? Generally, it's nice to keep
IGP being merely a logical view of your graph of links, and keep
foreign/other routes in (i)BGP. Then, you need to take a look at the
distribution of your peering sessions over your sites with respect to
your customer sessions. Etc, etc,...

Backbone capacity versus peering capacity, depends on your mix
of peers, customers, providers...

>
>    3. How can I maintain use of routes I am learning from various other
>    networks (transit+peers+customer) across my IGP? Is BGP community tagging
>    good way out?

See above, if I understand your question correctly.

>
>    4. How is iBGP Vs OSPF for IGP? I keep on hearing that OSPF is good &
>    lot more faster in changing routes during a breakdown as compared to slow
>    hold time based iBGP session. Is there's more clear comparison of
>    limitations of both when designing?
>

Get in touch off-list, if you feel like?

Cheers,

mh

>
> Appreciate your time & help.
>
>
>
> Thanks.
>



From Grzegorz at Janoszka.pl  Fri Oct 18 20:15:02 2013
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Fri, 18 Oct 2013 22:15:02 +0200
Subject: Fundamental questions of backbone design
In-Reply-To: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
References: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
Message-ID: <526196C6.4080805@Janoszka.pl>

On 2013-10-18 20:03, Anurag Bhatia wrote:
>     1. As I understand it's (sort off) common practice to give highest
>     localpref to customer routes then peering and finally transit. Does this
>     works well or you see issues with people who have 10+ prepends on some
>     peering routes calling you to not send traffic via those circuits? Does it
>     makes sense to put a rule to avoid routes 2-3 AS path away when changing
>     local preference?

Hi,
You may try a different trick on peering routes. You rather don't peer 
with the tier 1 networks, so you may filter out (or assign a low 
localpref to) all prefixes received from peering partners which contain 
in as-path some well known asn's, like let's say 174, 1299, 3356 and so 
on. Such routes are most likely leaked and traffic via those paths will 
be either blackholed or, in the best case, going via not really optimal 
path.

>     2. If I have more peering capacity and relatively less capacity between
>     my own PoPs and I start injecting routes in my IGP then how to prevent
>     change of choking of backbone? Is it standard practice to have more
>     capacity on backbone then peering links? Or I have to inject less routes in
>     IGP - say a few % of total routes?

You may always prefer peering routes local to the PoP (giving them the 
highest localpref). This way you will not carry so much traffic on your 
backbone.

-- 
Grzegorz Janoszka



From drohan at gmail.com  Fri Oct 18 20:25:33 2013
From: drohan at gmail.com (Dan Rohan)
Date: Fri, 18 Oct 2013 13:25:33 -0700
Subject: Fundamental questions of backbone design
In-Reply-To: <526196C6.4080805@Janoszka.pl>
References: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
 <526196C6.4080805@Janoszka.pl>
Message-ID: <1A8EAFA4-8ED9-414F-805C-A1393E64C08B@gmail.com>


On Oct 18, 2013, at 1:15 PM, Grzegorz Janoszka <Grzegorz at Janoszka.pl> wrote:

> You may always prefer peering routes local to the PoP (giving them the highest localpref). This way you will not carry so much traffic on your backbone.

Just imagine what paths would look like if everyone followed that advice. Yuck. I'd say that approach makes sense for cash and bandwidth strapped providers, but its not necessarily looking out for the best interests of your customers. 




From blake at ispn.net  Fri Oct 18 21:21:55 2013
From: blake at ispn.net (Blake Hudson)
Date: Fri, 18 Oct 2013 16:21:55 -0500
Subject: clear forwarding route
In-Reply-To: <CAG1kdogOyEVeKhhDm3oOsvuHiJEnCEz=uYWjZY+DwKvKpzBLeg@mail.gmail.com>
References: <CAG1kdogOyEVeKhhDm3oOsvuHiJEnCEz=uYWjZY+DwKvKpzBLeg@mail.gmail.com>
Message-ID: <5261A673.9040308@ispn.net>

I've had a route that remained in the RIB (and consequently the FIB) 
after a BGP session had been disabled or went down (all routes but one 
were removed correctly). I'm guessing similar bugs exist in other 
portions of the software, making manual clearing tools a bandaid for 
these hard to pin down bugs.

--Blake

Manav Bhatia wrote the following on 10/18/2013 10:40 AM:
> Hi,
>
> I would like understand the circumstances under which an operator may want
> to clear all (or a subset of) the routes programmed in the forwarding table
> (FIB).
>
> I believe the command to do this on Cisco is
>
> clear forwarding {ipv4 | ipv6} route {* | prefix} [vrf vrf-name] module
> {slot| all}
>
> I ask this since doing this would result in the router dropping all transit
> traffic till the routes get reprogrammed in the FIB.
>
> Why would somebody ever want to do this? One scenario that i can think of
> is when because of a bug a route does not get programmed in the FIB and the
> operator uses this command to install this once again the FIB.
>
> Thanks, Manav



From Valdis.Kletnieks at vt.edu  Fri Oct 18 21:46:48 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 18 Oct 2013 17:46:48 -0400
Subject: Fundamental questions of backbone design
In-Reply-To: Your message of "Fri, 18 Oct 2013 23:33:16 +0530."
 <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
References: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
Message-ID: <15023.1382132808@turing-police.cc.vt.edu>

On Fri, 18 Oct 2013 23:33:16 +0530, Anurag Bhatia said:

>    localpref to customer routes then peering and finally transit. Does this
>    works well or you see issues with people who have 10+ prepends on some
>    peering routes calling you to not send traffic via those circuits?

OK. I admit being perplexed.  Under what conditions will somebody have that
many prepends and you *still* end up routing via that path if you have
another path available?

I guess if they were silly and prepended themselves 10 times and then
announced the result to the upstreams of *both* paths you have available...
-------------- 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/20131018/2d30bfd8/attachment-0001.bin>

From cidr-report at potaroo.net  Fri Oct 18 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 18 Oct 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201310182200.r9IM00HZ050061@wattle.apnic.net>

This report has been generated at Fri Oct 18 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
        11-10-13    481980      273263
        12-10-13    481294      273912
        13-10-13    481452      273859
        14-10-13    481664      273958
        15-10-13    481665      273827
        16-10-13    481569      274222
        17-10-13    481972      273358
        18-10-13    480627      273321


AS Summary
         45382  Number of ASes in routing system
         18633  Number of ASes announcing only one prefix
          4170  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      118189056  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').

 --- 18Oct13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     481115   273150   207965    43.2%   All ASes

AS6389      3057       61     2996    98.0%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS28573     3430      497     2933    85.5%   NET Servi?os de Comunica??o
                                               S.A.
AS17974     2714      105     2609    96.1%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS7029      4170     1852     2318    55.6%   WINDSTREAM - Windstream
                                               Communications Inc
AS4766      2944      954     1990    67.6%   KIXS-AS-KR Korea Telecom
AS10620     2606     1027     1579    60.6%   Telmex Colombia S.A.
AS36998     1864      346     1518    81.4%   SDN-MOBITEL
AS18566     2059      568     1491    72.4%   MEGAPATH5-US - MegaPath
                                               Corporation
AS4323      2957     1542     1415    47.9%   TWTC - tw telecom holdings,
                                               inc.
AS7303      1723      469     1254    72.8%   Telecom Argentina S.A.
AS1785      2027      815     1212    59.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1779      580     1199    67.4%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1189      136     1053    88.6%   VIETEL-AS-AP Vietel
                                               Corporation
AS22561     1242      217     1025    82.5%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS18881     1473      478      995    67.5%   Global Village Telecom
AS22773     2184     1326      858    39.3%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS35908      905       87      818    90.4%   VPLSNET - Krypt Technologies
AS7545      2089     1276      813    38.9%   TPG-INTERNET-AP TPG Telecom
                                               Limited
AS18101      981      180      801    81.7%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4808      1164      402      762    65.5%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS11830      866      118      748    86.4%   Instituto Costarricense de
                                               Electricidad y Telecom.
AS8402      1798     1056      742    41.3%   CORBINA-AS OJSC "Vimpelcom"
AS701       1510      787      723    47.9%   UUNET - MCI Communications
                                               Services, Inc. d/b/a Verizon
                                               Business
AS24560     1091      375      716    65.6%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS13977      853      142      711    83.4%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS6983      1295      585      710    54.8%   ITCDELTA - ITC^Deltacom
AS8151      1349      654      695    51.5%   Uninet S.A. de C.V.
AS4780      1001      314      687    68.6%   SEEDNET Digital United Inc.
AS6147       793      108      685    86.4%   Telefonica del Peru S.A.A.
AS855        733       55      678    92.5%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.

Total      53846    17112    36734    68.2%   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.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
        62.182.96.0/23       AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED
        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.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.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.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.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
        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.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        82.103.0.0/18        AS30901 
        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.199.250.0/24      AS5617  TPNET Telekomunikacja Polska S.A.
        91.200.188.0/22      AS44016 
        91.205.188.0/22      AS47983 
        91.207.152.0/24      AS64100 
        91.207.153.0/24      AS64100 
        91.207.178.0/23      AS48274 
        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. 
        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
        120.136.17.0/24      AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika
        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
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        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.
        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.88.230.0/23      AS49089 UA-DC Nikultsev Aleksandr Nikolaevich
        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 
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.58.248.0/21      AS27849 
        200.192.105.0/24     AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich
        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.52.47.0/24       AS55560 
        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.84.16.0/24       AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.84.17.0/24       AS17781 XINHUA Xinhua News Agency
        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.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.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.225.0/24      AS3549  GBLX Global Crossing Ltd.
        208.66.227.0/24      AS3549  GBLX Global Crossing Ltd.
        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.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
        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.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        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.146.0.0/19       AS1915  SEQUOIA-AS - National Science Foundation
        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 Oct 18 22:00:02 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 18 Oct 2013 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201310182200.r9IM027P050087@wattle.apnic.net>

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

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS30693           54119  2.8%      96.8 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 2 - AS9829            48210  2.5%      29.6 -- BSNL-NIB National Internet Backbone
 3 - AS28573           47056  2.4%      13.4 -- NET Servi?os de Comunica??o S.A.
 4 - AS8402            31897  1.6%      50.6 -- CORBINA-AS OJSC "Vimpelcom"
 5 - AS13118           23656  1.2%     503.3 -- ASN-YARTELECOM OJSC Rostelecom
 6 - AS4538            21976  1.1%      40.6 -- ERX-CERNET-BKB China Education and Research Network Center
 7 - AS4775            15847  0.8%     211.3 -- GLOBE-TELECOM-AS Globe Telecoms
 8 - AS43418           14842  0.8%     218.3 -- ANTIDOT Pryama Mova TOV
 9 - AS50710           12697  0.7%      56.2 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services
10 - AS9658            11472  0.6%    1638.9 -- ETPI-IDS-AS-AP Eastern Telecoms Phils., Inc.
11 - AS3816            11345  0.6%      27.0 -- COLOMBIA TELECOMUNICACIONES S.A. ESP
12 - AS11976           10739  0.6%      90.2 -- FIDN - Fidelity Communication International Inc.
13 - AS7552            10057  0.5%       9.7 -- VIETEL-AS-AP Vietel Corporation
14 - AS8163             9700  0.5%      25.0 -- METROTEL REDES S.A.
15 - AS10620            9697  0.5%       7.3 -- Telmex Colombia S.A.
16 - AS6629             9330  0.5%    9330.0 -- NOAA-AS - NOAA
17 - AS27831            9316  0.5%      52.0 -- Colombia M?vil
18 - AS12880            9305  0.5%      78.2 -- DCI-AS Information Technology Company (ITC)
19 - AS13489            8829  0.5%      19.2 -- EPM Telecomunicaciones S.A. E.S.P.
20 - AS7029             8752  0.5%       7.1 -- WINDSTREAM - Windstream Communications Inc


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS6629             9330  0.5%    9330.0 -- NOAA-AS - NOAA
 2 - AS62762            5609  0.3%    5609.0 -- EL-SEGUNDO-OOB - DIRECTV, LLC
 3 - AS48612            5211  0.3%    5211.0 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
 4 - AS19406            4587  0.2%    4587.0 -- TWRS-MA - Towerstream I, Inc.
 5 - AS6174             6816  0.3%    3408.0 -- SPRINTLINK8 - Sprint
 6 - AS17375            2939  0.1%    2939.0 -- EXPERIS-DATA-CENTERS-OF-VA-DR-SOLUTIONS - Virginia DR Solutions, LLC
 7 - AS32244            6566  0.3%    1641.5 -- LIQUID-WEB-INC - Liquid Web, Inc.
 8 - AS9658            11472  0.6%    1638.9 -- ETPI-IDS-AS-AP Eastern Telecoms Phils., Inc.
 9 - AS51663            3021  0.1%    1510.5 -- ASADMSOL Administration of Solikamsk city
10 - AS17206            1460  0.1%    1460.0 -- MOUNTAIN-AMERICA - Mountain America Credit Union
11 - AS5487             8395  0.4%    1199.3 -- Elisa Oyj
12 - AS22592            4732  0.2%    1183.0 -- HBP - HBP, Inc.
13 - AS2578             1896  0.1%     948.0 -- DEMOS-AS Demos, Moscow, Russia
14 - AS7202             8362  0.4%     929.1 -- FAMU - Florida A & M University
15 - AS13759             796  0.0%     796.0 -- WILKES-MULTI-HOME1 - Wilkes University
16 - AS11993             710  0.0%     710.0 -- BANCO DO BRASIL S.A.
17 - AS37367             708  0.0%     708.0 -- CALLKEY
18 - AS50337            1372  0.1%     686.0 -- TETTAS-AS TETTAS SRL
19 - AS49105             684  0.0%     684.0 -- BULLCAT-AS Bullcat Webhosting
20 - AS36279            2463  0.1%     615.8 -- MISERI-COLLEGE-1 - College Misericordia


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 109.161.64.0/20   23300  1.1%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 202.164.190.0/24  11449  0.6%   AS9658  -- ETPI-IDS-AS-AP Eastern Telecoms Phils., Inc.
 3 - 192.58.232.0/24    9330  0.5%   AS6629  -- NOAA-AS - NOAA
 6 - 115.170.128.0/17   6317  0.3%   AS4847  -- CNIX-AP China Networks Inter-Exchange
 7 - 67.210.190.0/23    5769  0.3%   AS11976 -- FIDN - Fidelity Communication International Inc.
 8 - 198.205.92.0/24    5609  0.3%   AS62762 -- EL-SEGUNDO-OOB - DIRECTV, LLC
 9 - 92.246.207.0/24    5211  0.2%   AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
10 - 67.210.188.0/23    4723  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
11 - 208.91.124.0/22    4720  0.2%   AS22592 -- HBP - HBP, Inc.
12 - 69.38.178.0/24     4587  0.2%   AS19406 -- TWRS-MA - Towerstream I, Inc.
13 - 62.84.76.0/24      4232  0.2%   AS42334 -- BBP-AS Broadband Plus s.a.l.
14 - 168.223.206.0/23   4199  0.2%   AS7202  -- FAMU - Florida A & M University
15 - 168.223.200.0/22   4141  0.2%   AS7202  -- FAMU - Florida A & M University
16 - 64.187.64.0/23     4108  0.2%   AS16608 -- KENTEC - Kentec Communications, Inc.
17 - 2.93.235.0/24      4036  0.2%   AS8402  -- CORBINA-AS OJSC "Vimpelcom"
18 - 64.187.64.0/24     3487  0.2%   AS16608 -- KENTEC - Kentec Communications, Inc.
19 - 206.105.75.0/24    3416  0.2%   AS6174  -- SPRINTLINK8 - Sprint
20 - 208.16.110.0/24    3400  0.2%   AS6174  -- SPRINTLINK8 - Sprint

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 mpetach at netflight.com  Sat Oct 19 04:12:07 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 18 Oct 2013 21:12:07 -0700
Subject: clear forwarding route
In-Reply-To: <1382117577.13312.YahooMailNeo@web133104.mail.ir2.yahoo.com>
References: <CAG1kdogOyEVeKhhDm3oOsvuHiJEnCEz=uYWjZY+DwKvKpzBLeg@mail.gmail.com>
 <1382117577.13312.YahooMailNeo@web133104.mail.ir2.yahoo.com>
Message-ID: <CAEmG1=p2wiz_du7WzXZHpMjuoosqdFV=b1wufi2LRMokeHGAHw@mail.gmail.com>

On Fri, Oct 18, 2013 at 10:32 AM, John Smith <jsmith4112003 at yahoo.co.uk>wrote:

> This is a hack that most vendors provide, just in case their code doesnt
> work as expected.
>
> Nobody in his sane mind will clear the FIB on a live router. This creates
> all sorts of problems. The router starts sending out ICMP errors
> (unreachables, etc), BFD times out, causing all hell to break lose within
> the domain.
>

Oh, plenty of people on the list here have had to do
exactly that on live routers.  Not sure whether or not
we would ever be accused of being of 'sane mind', but
that kinda comes with the territory of trying to move large
volumes of packets at high speeds around the planet.

When one or two linecards in a chassis have a bad entry
stuck in their copy of the forwarding table, and things are
getting screwy, it's better to flush and relearn the FIB
then continue black-holing traffic for a subset of the
network.  :/



> It might make some sense to do this on flow based routers where you clear
> the FIB so that newer flows can get established in case there are hash
> collisions or issues in flow caches. Even in that case its an issue as all
> live traffic starts hitting SW before the flow can get established.
>
> Customers, you can rest assured, will not appreciate you doing this. And
> its precisely for this that you never ever do this on a live router.
>

Unless of course the customer is being black-holed due to a bad
FIB entry;  in which case, the customer will most assuredly be
more appreciative of you doing it, than of you *not* doing it.

Matt


>
> On Friday, 18 October 2013, 21:31, Manav Bhatia <manavbhatia at gmail.com>
> wrote:
> Hi,
>
> I would like understand the circumstances under which an operator may want
> to clear all (or a subset of) the routes programmed in the forwarding table
> (FIB).
>
> I believe the command to do this on Cisco is
>
> clear forwarding {ipv4 | ipv6} route {* | prefix} [vrf vrf-name] module
> {slot| all}
>
> I ask this since doing this would result in the router dropping all transit
> traffic till the routes get reprogrammed in the FIB.
>
> Why would somebody ever want to do this? One scenario that i can think of
> is when because of a bug a route does not get programmed in the FIB and the
> operator uses this command to install this once again the FIB.
>
> Thanks, Manav
>
>
>

From jfmezei_nanog at vaxination.ca  Sat Oct 19 10:35:47 2013
From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei)
Date: Sat, 19 Oct 2013 06:35:47 -0400
Subject: FTTH for cable companies
Message-ID: <52626083.5090709@vaxination.ca>

I need a reality check...

For telcos, going from barely twisted copper pair to FTTH presents huge
incremental improvement. FTTN is basically a stop gap medium term
solution that is more pleasing to some beancounters.

However, for a cable company, is there an advantage to deploy FTTH/GPON
to bring light originally destined to the neighbourhood node all the way
to the home and do away with coax ?

>From what I have read, cablecos limit FTTH deployments to greenfields.

Do they save much by replaciung the "node" with a simple optical
splitter which no longer limits how much upstream bandwidth is
retransmitted back to head end ?

Will there be a point in the next 10 years where cable companies might
start to upgrade brownfields from coax to FTTH as some telcos have done ?

While in Canada, FTTH deployment by telcos has been accompanied with
IPTV deployments on the data path (single wavelength), I hear that
Verizon has used twin wavelengths, on for GPON data, and one for RFoG
for TV signals. Would it be fair to state that FIOS is basically
identical to FTTH deployments by cable companies ?

Do twin wavelength systems as deployed by Verizon end up costing far
more ? Or is the price difference mininal ?

Any information/insight appreciated.


From mark at amplex.net  Sat Oct 19 13:14:29 2013
From: mark at amplex.net (Mark Radabaugh)
Date: Sat, 19 Oct 2013 09:14:29 -0400
Subject: FTTH for cable companies
In-Reply-To: <52626083.5090709@vaxination.ca>
References: <52626083.5090709@vaxination.ca>
Message-ID: <526285B5.40605@amplex.net>

I believe the difference is fairly negligible between RFoG and IPTV.   
RFoG allows the cable companies to leverage the existing RF head end 
while FTTH requires a IPTV head end.    IPTV is less familiar to most 
cable operators and requires new investment in facilities and skills.

Mark


On 10/19/13 6:35 AM, Jean-Francois Mezei wrote:
> I need a reality check...
>
> For telcos, going from barely twisted copper pair to FTTH presents huge
> incremental improvement. FTTN is basically a stop gap medium term
> solution that is more pleasing to some beancounters.
>
> However, for a cable company, is there an advantage to deploy FTTH/GPON
> to bring light originally destined to the neighbourhood node all the way
> to the home and do away with coax ?
>
>  From what I have read, cablecos limit FTTH deployments to greenfields.
>
> Do they save much by replaciung the "node" with a simple optical
> splitter which no longer limits how much upstream bandwidth is
> retransmitted back to head end ?
>
> Will there be a point in the next 10 years where cable companies might
> start to upgrade brownfields from coax to FTTH as some telcos have done ?
>
> While in Canada, FTTH deployment by telcos has been accompanied with
> IPTV deployments on the data path (single wavelength), I hear that
> Verizon has used twin wavelengths, on for GPON data, and one for RFoG
> for TV signals. Would it be fair to state that FIOS is basically
> identical to FTTH deployments by cable companies ?
>
> Do twin wavelength systems as deployed by Verizon end up costing far
> more ? Or is the price difference mininal ?
>
> Any information/insight appreciated.
>


-- 
Mark Radabaugh
Amplex

mark at amplex.net  419.837.5015



From florin at futurefreedom.ro  Sat Oct 19 15:25:05 2013
From: florin at futurefreedom.ro (Florin Veres)
Date: Sat, 19 Oct 2013 18:25:05 +0300
Subject: FTTH for cable companies
In-Reply-To: <526285B5.40605@amplex.net>
References: <52626083.5090709@vaxination.ca>
	<526285B5.40605@amplex.net>
Message-ID: <CAG+jQO_seKL9ToKEiBq99Va37rP0h3L8bRb0Z56jMrV3BWU-VA@mail.gmail.com>

Also, RFoG keeps the same STBs as old-school FTTN, and for bean counters
it's pretty hard to justify changing a LOT of STBs to IPTV ones.
On Oct 19, 2013 4:17 PM, "Mark Radabaugh" <mark at amplex.net> wrote:

> I believe the difference is fairly negligible between RFoG and IPTV.
> RFoG allows the cable companies to leverage the existing RF head end while
> FTTH requires a IPTV head end.    IPTV is less familiar to most cable
> operators and requires new investment in facilities and skills.
>
> Mark
>
>
> On 10/19/13 6:35 AM, Jean-Francois Mezei wrote:
>
>> I need a reality check...
>>
>> For telcos, going from barely twisted copper pair to FTTH presents huge
>> incremental improvement. FTTN is basically a stop gap medium term
>> solution that is more pleasing to some beancounters.
>>
>> However, for a cable company, is there an advantage to deploy FTTH/GPON
>> to bring light originally destined to the neighbourhood node all the way
>> to the home and do away with coax ?
>>
>>  From what I have read, cablecos limit FTTH deployments to greenfields.
>>
>> Do they save much by replaciung the "node" with a simple optical
>> splitter which no longer limits how much upstream bandwidth is
>> retransmitted back to head end ?
>>
>> Will there be a point in the next 10 years where cable companies might
>> start to upgrade brownfields from coax to FTTH as some telcos have done ?
>>
>> While in Canada, FTTH deployment by telcos has been accompanied with
>> IPTV deployments on the data path (single wavelength), I hear that
>> Verizon has used twin wavelengths, on for GPON data, and one for RFoG
>> for TV signals. Would it be fair to state that FIOS is basically
>> identical to FTTH deployments by cable companies ?
>>
>> Do twin wavelength systems as deployed by Verizon end up costing far
>> more ? Or is the price difference mininal ?
>>
>> Any information/insight appreciated.
>>
>>
>
> --
> Mark Radabaugh
> Amplex
>
> mark at amplex.net  419.837.5015
>
>
>

From ml at kenweb.org  Sat Oct 19 17:48:54 2013
From: ml at kenweb.org (ML)
Date: Sat, 19 Oct 2013 13:48:54 -0400
Subject: FTTH for cable companies
In-Reply-To: <52626083.5090709@vaxination.ca>
References: <52626083.5090709@vaxination.ca>
Message-ID: <5262C606.2000200@kenweb.org>

On 10/19/2013 6:35 AM, Jean-Francois Mezei wrote:
> I need a reality check...
>
> For telcos, going from barely twisted copper pair to FTTH presents huge
> incremental improvement. FTTN is basically a stop gap medium term
> solution that is more pleasing to some beancounters.
>
> However, for a cable company, is there an advantage to deploy FTTH/GPON
> to bring light originally destined to the neighbourhood node all the way
> to the home and do away with coax ?
>
> From what I have read, cablecos limit FTTH deployments to greenfields.
>
> Do they save much by replaciung the "node" with a simple optical
> splitter which no longer limits how much upstream bandwidth is
> retransmitted back to head end ?
>
> Will there be a point in the next 10 years where cable companies might
> start to upgrade brownfields from coax to FTTH as some telcos have done ?
>
> While in Canada, FTTH deployment by telcos has been accompanied with
> IPTV deployments on the data path (single wavelength), I hear that
> Verizon has used twin wavelengths, on for GPON data, and one for RFoG
> for TV signals. Would it be fair to state that FIOS is basically
> identical to FTTH deployments by cable companies ?
>
> Do twin wavelength systems as deployed by Verizon end up costing far
> more ? Or is the price difference mininal ?
>
> Any information/insight appreciated.
>

Doing RFoG forward path is simple.  The reverse path isn't.  VZ has an
IP reverse path for VOD asset purchases and keeping their STBs in
contact with whatever element management they use.
VZ STBs depend on the the local VZ provided CPE as the reverse path for
communication.

It's been a while since I've looked at a PON deployment but I believe
the xPON waves are passively muxed with an EDFA amplified video wave and
then sent to the outside plant.







From bedard.phil at gmail.com  Sat Oct 19 17:51:09 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Sat, 19 Oct 2013 13:51:09 -0400
Subject: FTTH for cable companies
In-Reply-To: <52626083.5090709@vaxination.ca>
Message-ID: <CE883BDA.7B303%bedard.phil@gmail.com>

I think all of the MSOs in the US have long term (15-20 year) plans to
also do FTTH.  Advances in DOCSIS and coax technology seem to be outpacing
those available on the telco twisted-pair side, so it delays forklifting
the existing HFC plant. DOCSIS 3.1 requires some significant capital
investment to do things like expand upstream channel spectrum, etc. but
the costs still pale in comparison to trenching fiber to houses and will
give them enough bandwidth to supply a lot more users with higher speed
service.  There is also an evoluation to all-IP, everyone sees the writing
on the wall and many of the presentations at Cable-TEC (SCTE) in Atlanta
next week are focused on IP/IPTV, etc.  Like someone else said, it's hard
to replace millions of set-top boxes that don't speak IPTV... In a lot of
ways IPTV, etc. over a big IP pipe is much simpler than what we have today
even with RFoG.  But RFoG is compatible with all of the existing systems
in place.  

The are interesting ways to overlay PON on top of existing HFC deployments
that aren't really all that expensive, but houses aren't really being
built these days like they used to so the opportunities to build into new
developments isn't happening like it was 5-6 years ago.

As for Verizon, I think their choice to do the 1550 video wavelength had a
lot to do with how they were ingesting video in the beginning and the
back-end systems, customer premise equipment, etc.  It also doesn't
require doing things like QoS to separate Internet from video traffic.


Phil 



On 10/19/13 6:35 AM, "Jean-Francois Mezei" <jfmezei_nanog at vaxination.ca>
wrote:

>I need a reality check...
>
>For telcos, going from barely twisted copper pair to FTTH presents huge
>incremental improvement. FTTN is basically a stop gap medium term
>solution that is more pleasing to some beancounters.
>
>However, for a cable company, is there an advantage to deploy FTTH/GPON
>to bring light originally destined to the neighbourhood node all the way
>to the home and do away with coax ?
>
>From what I have read, cablecos limit FTTH deployments to greenfields.
>
>Do they save much by replaciung the "node" with a simple optical
>splitter which no longer limits how much upstream bandwidth is
>retransmitted back to head end ?
>
>Will there be a point in the next 10 years where cable companies might
>start to upgrade brownfields from coax to FTTH as some telcos have done ?
>
>While in Canada, FTTH deployment by telcos has been accompanied with
>IPTV deployments on the data path (single wavelength), I hear that
>Verizon has used twin wavelengths, on for GPON data, and one for RFoG
>for TV signals. Would it be fair to state that FIOS is basically
>identical to FTTH deployments by cable companies ?
>
>Do twin wavelength systems as deployed by Verizon end up costing far
>more ? Or is the price difference mininal ?
>
>Any information/insight appreciated.
>




From jcurran at arin.net  Sat Oct 19 18:29:25 2013
From: jcurran at arin.net (John Curran)
Date: Sat, 19 Oct 2013 18:29:25 +0000
Subject: =?Windows-1252?Q?ARIN_Meetings_=96_Weigh_In_on_Future_Format_(till_this_F?=
 =?Windows-1252?Q?riday!)?=
References: <52542541.5060408@arin.net>
Message-ID: <1E3D986E-5C02-4CB2-9721-D892FDB516A6@corp.arin.net>

NANOGers -

   ARIN is considering the appropriate frequency and format of ARIN?s
   Public Policy and Members Meetings, and if you have any thoughts
   in this area, then it would be helpful if you could complete a short
   survey (which is open to both ARIN and NANOG communities) until
   Friday 25 October 2013.

   See the attached announcement for more details!

Thanks!
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

From: ARIN <info at arin.net<mailto:info at arin.net>>
Subject: [arin-announce] ARIN Meetings ? Weigh In on Future Format
Date: October 9, 2013 12:31:13 AM GMT+09:00
To: <arin-announce at arin.net<mailto:arin-announce at arin.net>>

The ARIN Board of Trustees is discussing the appropriate frequency and
format of ARIN?s Public Policy and Members Meetings. Traditionally and
through 2014 ARIN is scheduled to hold two per year, one conjoined with
NANOG in Q3 of the year.

Please take a few minutes to respond to the short meeting survey and let
us know your opinion?.what is the correct mix that would encourage your
new or increased participation? This survey is open to the ARIN and NANOG
communities, and also to those who are not currently active in either
organization.

https://www.surveymonkey.com/s/future_meetings

The survey will remain open until Friday 25 October.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)




_______________________________________________
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (ARIN-announce at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-announce
Please contact info at arin.net if you experience any issues.


From bedard.phil at gmail.com  Sat Oct 19 18:32:07 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Sat, 19 Oct 2013 14:32:07 -0400
Subject: FTTH for cable companies
In-Reply-To: <5262C606.2000200@kenweb.org>
Message-ID: <CE884524.7B31F%bedard.phil@gmail.com>

That's no different than what MSOs are deploying as well.  Using things
like DSG the STB is using IP these days to communicate with application
servers, VoD, etc. Really the same as your VZW example, the STB uses
DOCSIS for OOB signalling instead of straight RF.


PON can use a RF video overlay or not, the PON standards have stayed away
from using 1550-1560nm for that reason, but yes it's all passively muxed.

Phil 

On 10/19/13 1:48 PM, "ML" <ml at kenweb.org> wrote:

>On 10/19/2013 6:35 AM, Jean-Francois Mezei wrote:
>> I need a reality check...
>>
>> For telcos, going from barely twisted copper pair to FTTH presents huge
>> incremental improvement. FTTN is basically a stop gap medium term
>> solution that is more pleasing to some beancounters.
>>
>> However, for a cable company, is there an advantage to deploy FTTH/GPON
>> to bring light originally destined to the neighbourhood node all the way
>> to the home and do away with coax ?
>>
>> From what I have read, cablecos limit FTTH deployments to greenfields.
>>
>> Do they save much by replaciung the "node" with a simple optical
>> splitter which no longer limits how much upstream bandwidth is
>> retransmitted back to head end ?
>>
>> Will there be a point in the next 10 years where cable companies might
>> start to upgrade brownfields from coax to FTTH as some telcos have done
>>?
>>
>> While in Canada, FTTH deployment by telcos has been accompanied with
>> IPTV deployments on the data path (single wavelength), I hear that
>> Verizon has used twin wavelengths, on for GPON data, and one for RFoG
>> for TV signals. Would it be fair to state that FIOS is basically
>> identical to FTTH deployments by cable companies ?
>>
>> Do twin wavelength systems as deployed by Verizon end up costing far
>> more ? Or is the price difference mininal ?
>>
>> Any information/insight appreciated.
>>
>
>Doing RFoG forward path is simple.  The reverse path isn't.  VZ has an
>IP reverse path for VOD asset purchases and keeping their STBs in
>contact with whatever element management they use.
>VZ STBs depend on the the local VZ provided CPE as the reverse path for
>communication.
>
>It's been a while since I've looked at a PON deployment but I believe
>the xPON waves are passively muxed with an EDFA amplified video wave and
>then sent to the outside plant.
>
>
>
>
>
>




From mpetach at netflight.com  Sat Oct 19 19:43:49 2013
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 19 Oct 2013 12:43:49 -0700
Subject: Fundamental questions of backbone design
In-Reply-To: <15023.1382132808@turing-police.cc.vt.edu>
References: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
 <15023.1382132808@turing-police.cc.vt.edu>
Message-ID: <CAEmG1=qT8dGqqD84gAwOvvbzTW+AgiK36CFdUw=EPMQ_rzO4mg@mail.gmail.com>

On Fri, Oct 18, 2013 at 2:46 PM, <Valdis.Kletnieks at vt.edu> wrote:

> On Fri, 18 Oct 2013 23:33:16 +0530, Anurag Bhatia said:
>
> >    localpref to customer routes then peering and finally transit. Does
> this
> >    works well or you see issues with people who have 10+ prepends on some
> >    peering routes calling you to not send traffic via those circuits?
>
> OK. I admit being perplexed.  Under what conditions will somebody have that
> many prepends and you *still* end up routing via that path if you have
> another path available?
>
> I guess if they were silly and prepended themselves 10 times and then
> announced the result to the upstreams of *both* paths you have available...
>


Uh...this actually happens a fair amount, to the
point that I have a standard "less-than-X-AS-PATH"
restriction in my localpref adjustments to explicitly
prevent it.

Think about it; if network A prepends 10x to network B,
and not at all to network C; but network B is a free peer
of mine, and network C is a transit network I pay money
to; following the typical convention of "routes learned
from network B get localpref'd to 5000, routes learned
from transit are localpref'd at 1000", you'd end up
pushing the traffic along the 10x prepended pathway.

If you're a network with low splay, it's less likely, as
the more intervening networks there are in the mix,
the less likely the long path is to propagate to you;
but if you're a high-splay network, there's a really
good chance you're going to see both the long path
and the short path across different categories of
links, with different localpref assignments.

A good approach to preventing that is to look
at a histogram of AS-PATH lengths in your
network, and establish a cutoff point, generally
around your 95th percentile; path lenths less
than that are "real" paths, above that are
"backup, non-preferred" paths, and then
use that cutoff in your policy arsenal:

replace:
 as-path 1-OR-LESS ".{0,1}";
replace:
 as-path 2-OR-LESS ".{0,2}";
replace:
 as-path 3-OR-LESS ".{0,3}";
replace:
 as-path 4-OR-LESS ".{0,4}";
replace:
 as-path 5-OR-LESS ".{0,5}";
replace:
 as-path 6-OR-LESS ".{0,6}";
replace:
 as-path 7-OR-LESS ".{0,7}";
replace:
 as-path 8-OR-LESS ".{0,8}";
replace:
 as-path 200-OR-MORE ".{200,}";

replace:
policy-statement SET-FREE-PEER {
    term AS-DEPTH-5-OR-LESS {
        from as-path 5-OR-LESS;
        then {
            community add C-Y-FREE-PEER;
            local-preference 2600;
            accept;
        }
    }
    term AS-DEPTH-LONGER-THAN-5 {
        then {
            community add C-Y-FREE-PEER;
            local-preference 100;
            accept;
        }
    }
    /* we will never get here, but put for readability/futureproofing */
    then reject;
}

(pre-defining a range of potential AS-PATH lengths
in your policy description tree makes it easier to
adjust up or down, as your splay factor increases
or decreases over time.)

And no, you can't quite paste this exactly into your
router directly, but it should give you an idea of
how you might control the impact long AS-PATHs
have on your routing tables.

Matt

From randy at psg.com  Sat Oct 19 22:36:13 2013
From: randy at psg.com (Randy Bush)
Date: Sun, 20 Oct 2013 01:36:13 +0300
Subject: abha ahuja
Message-ID: <m2sivwvqg2.wl%randy@psg.com>

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.

randy


From brett at the-watsons.org  Sat Oct 19 23:14:01 2013
From: brett at the-watsons.org (Brett Watson)
Date: Sat, 19 Oct 2013 16:14:01 -0700
Subject: abha ahuja
In-Reply-To: <m2sivwvqg2.wl%randy@psg.com>
References: <m2sivwvqg2.wl%randy@psg.com>
Message-ID: <04FC0A27-DC08-4303-9F15-215B2D96DF03@the-watsons.org>

Brilliant woman with a great sense of humor, just a wonderful person. Deeply missed.


Typing with thumbs...

> On Oct 19, 2013, at 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.
> 
> randy
> 


From jfmezei_nanog at vaxination.ca  Sat Oct 19 23:16:35 2013
From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei)
Date: Sat, 19 Oct 2013 19:16:35 -0400
Subject: FTTH for cable companies
In-Reply-To: <CE884524.7B31F%bedard.phil@gmail.com>
References: <CE884524.7B31F%bedard.phil@gmail.com>
Message-ID: <526312D3.6020305@vaxination.ca>

For cable companies who have the data service as part of the RFoG
wavelengths to provide coax at the CPE, how do they handle
collisions/timing on the upstream side ?

Does the ONT provide TDMA slots for the upstream wavelength to ensure
only one customer transmits RF at a time on the upstream ? Or is it all
handled within the DOCSIS /RFoG side ?


From ccosta92630 at gmail.com  Sun Oct 20 02:33:19 2013
From: ccosta92630 at gmail.com (Chris Costa)
Date: Sat, 19 Oct 2013 19:33:19 -0700
Subject: Pad 1310nm cross-connects?
Message-ID: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>

What are the opinions/views on attenuating short, 1310nm LR cross-connects.
 Assume < 20m cable length and utilizing the same vendor optics on each
side of the link.  Considering the LR transmit spec doesn't exceed the
receiver's high threshold value do you pad the receiver closer to the
median RX range to avoid potential receiver burnout over time, or just
leave it un-padded?

Thanks

From notify.sina at gmail.com  Sat Oct 19 19:57:18 2013
From: notify.sina at gmail.com (Notify Me)
Date: Sat, 19 Oct 2013 20:57:18 +0100
Subject: In Over My Head -- What do I need to setup a tiny ISP?
Message-ID: <CACK8u8+h-2te=n=s0N1JmP21nj_qZS+9XKasu8AHjjwx_T649Q@mail.gmail.com>

Hi,

Please allow me to apologize profusely if my post is offensive, or in error.
I have been lurking on this list watching and learning from all the great
posts here and am in awe of everyone here. I can only hope one day to be as
knowledgeable as anyone on this list.

That being said, some people who have a lot more faith in my abilities than
I do seem to think I am the go-to guy for network information. And they
foolishly asked me for assistance in putting together a small ISP network
which is supposed to cater for home users inside of a residential area,
very likely wireless (wifi/WIMAX).

I have no idea what the nuts and bolts of this kind of setup are. All I
have in my toolbox are some hastily learnt CCNA lingo, a good knowledge of
networks, system and network admin experience, and a deep love of open
source software.

I'm hoping the great gurus on this site can advise me on what needs to be
put together ( infrastructure, AAA, billing, etc) for this to run?

I confess I am really interested in helping my questioners put this
together, not just for whatever material gain (which is unlikely at this
point), but just for the experience which is very valuable to me. I also
have to state that I live in Nigeria, so whatever advice you offer has to
be fourth-world applicable.

I humbly await your kind responses, and I apologize once again if I am in
error.

Thanks for listening!

From swmike at swm.pp.se  Sun Oct 20 05:06:31 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sun, 20 Oct 2013 07:06:31 +0200 (CEST)
Subject: Pad 1310nm cross-connects?
In-Reply-To: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
References: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1310200703440.26825@uplift.swm.pp.se>

On Sat, 19 Oct 2013, Chris Costa wrote:

> median RX range to avoid potential receiver burnout over time, or just 
> leave it un-padded?

By "padding", you mean "insert attenuator"?

I have run networks with thousands of 10km optical links (1GBASE-LX, 
10GBASE-LR) and none of them have used attenuators for these kinds of 
links, not even with 1m cable.

The discussion has been had here before, some attenuate, some don't. There 
is no consensus.

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


From streiner at cluebyfour.org  Sun Oct 20 01:24:01 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sat, 19 Oct 2013 21:24:01 -0400 (EDT)
Subject: Pad 1310nm cross-connects?
In-Reply-To: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
References: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1310192119290.15115@whammy.cluebyfour.org>

On Sat, 19 Oct 2013, Chris Costa wrote:

> What are the opinions/views on attenuating short, 1310nm LR cross-connects.
> Assume < 20m cable length and utilizing the same vendor optics on each
> side of the link.  Considering the LR transmit spec doesn't exceed the
> receiver's high threshold value do you pad the receiver closer to the
> median RX range to avoid potential receiver burnout over time, or just
> leave it un-padded?

If this is using Cisco 10GBASE-LR optics, then padding in this instance 
should not be necessary.  However, if SR optics (again, assuming these are 
Cisco devices), would be a better fit for the distance, using an OM3 or 
OM4 multimode jumper.

The reason I asked about the vendor is because things like SR and LR can
mean different things to different vendors.

jms


From rgolodner at infratection.com  Sun Oct 20 05:10:17 2013
From: rgolodner at infratection.com (Richard Golodner)
Date: Sun, 20 Oct 2013 00:10:17 -0500
Subject: In Over My Head -- What do I need to setup a tiny ISP?
In-Reply-To: <CACK8u8+h-2te=n=s0N1JmP21nj_qZS+9XKasu8AHjjwx_T649Q@mail.gmail.com>
References: <CACK8u8+h-2te=n=s0N1JmP21nj_qZS+9XKasu8AHjjwx_T649Q@mail.gmail.com>
Message-ID: <1382245817.2047.17.camel@Andromeda>

On Sat, 2013-10-19 at 20:57 +0100, Notify Me wrote:
> Hi,
	Hello, I can not tell you how to set up an ISP. There are people on
here that have worked on doing just that and a good place for you to
start would be here:

http://www.afnog.org/

	Another good resource would be found at


http://www.nsrc.org/

	This was set up by folk who frequent the NANOG forum and these people
know their stuff.
	I interned at an ISP, but that was many years ago before wireless was
happening so I don't have much to offer other than these links.
	I wish you success in your endeavor. One suggestion from me would be
for you to use your real name so that you can be considered a
professional. Just my own opinion, but there it is.
	Sincerely, Richard Golodner




From mansaxel at besserwisser.org  Sun Oct 20 05:21:42 2013
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Sun, 20 Oct 2013 07:21:42 +0200
Subject: Pad 1310nm cross-connects?
In-Reply-To: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
References: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
Message-ID: <20131020052142.GB2783@besserwisser.org>

Subject: Pad 1310nm cross-connects? Date: Sat, Oct 19, 2013 at 07:33:19PM -0700 Quoting Chris Costa (ccosta92630 at gmail.com):
> What are the opinions/views on attenuating short, 1310nm LR cross-connects.
>  Assume < 20m cable length and utilizing the same vendor optics on each
> side of the link.  Considering the LR transmit spec doesn't exceed the
> receiver's high threshold value do you pad the receiver closer to the
> median RX range to avoid potential receiver burnout over time, or just
> leave it un-padded?

	LR usually needs padding in that scenario, IMHO. This also 
applies to MMR interconnects or other "premises" / "campus" situations. 5
or 10dB depending on patching quality -- sometimes up to 15. The value
is best determined by measuring the signal. Then compare the measurement
with the line card / SFP datasheet and determine the amount of padding
necessary. As you write, the damage from overload is gradual, so simply 
trusting "it works" is quite bad for longevity reasons. 
	Not all line cards and / or optical modules report the input signal 
level, so a good meter sometimes is necessary.
	Get a good level meter, and a reasonably good light source for 
testing and calibration purposes. I'm happy with our purchase of
SMLP4-4[0] from AFL Noyes.

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Pardon me, but do you know what it means to be TRULY ONE with your BOOTH!

[0] http://www.aflglobal.com/Products/Test-and-Inspection/Loss-Test-sets/SMLP4-4_Single-mode_Multimode_Loss_Test_Kits.aspx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131020/384f89c2/attachment.bin>

From me at anuragbhatia.com  Sun Oct 20 06:30:32 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Sun, 20 Oct 2013 12:00:32 +0530
Subject: abha ahuja
In-Reply-To: <04FC0A27-DC08-4303-9F15-215B2D96DF03@the-watsons.org>
References: <m2sivwvqg2.wl%randy@psg.com>
 <04FC0A27-DC08-4303-9F15-215B2D96DF03@the-watsons.org>
Message-ID: <CAJ0+aXayHJ8DEM-vynT7M+VHodDtj8cnGbikrdLe9StTvtS-Bg@mail.gmail.com>

That was the year when I got my first computer (and thus too young to know
her at that time) but have read quite a lot about her in recent times.

Thanks for the post Randy.


On Sun, Oct 20, 2013 at 4:44 AM, Brett Watson <brett at the-watsons.org> wrote:

> Brilliant woman with a great sense of humor, just a wonderful person.
> Deeply missed.
>
>
> Typing with thumbs...
>
> > On Oct 19, 2013, at 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.
> >
> > randy
> >
>
>


-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From gjshep at gmail.com  Sun Oct 20 07:18:12 2013
From: gjshep at gmail.com (Greg Shepherd)
Date: Sun, 20 Oct 2013 00:18:12 -0700
Subject: abha ahuja
In-Reply-To: <m2sivwvqg2.wl%randy@psg.com>
References: <m2sivwvqg2.wl%randy@psg.com>
Message-ID: <CABFReBrGTSOH7w9beE2pKbj8Xm1vOz7=GCMc6Y60FNrqCF2bzQ@mail.gmail.com>

Deeply missed. I can't believe it's been that long.


On Sat, Oct 19, 2013 at 3:36 PM, 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.
>
> randy
>
>

From pmsac.nanog at gmail.com  Sun Oct 20 10:15:14 2013
From: pmsac.nanog at gmail.com (Pedro Cavaca)
Date: Sun, 20 Oct 2013 11:15:14 +0100
Subject: In Over My Head -- What do I need to setup a tiny ISP?
In-Reply-To: <CACK8u8+h-2te=n=s0N1JmP21nj_qZS+9XKasu8AHjjwx_T649Q@mail.gmail.com>
References: <CACK8u8+h-2te=n=s0N1JmP21nj_qZS+9XKasu8AHjjwx_T649Q@mail.gmail.com>
Message-ID: <CAE42oJrL_u=DQMMknrJsoMr-7Y10rG4WHsAxPwbHMy3bVMGEzA@mail.gmail.com>

Given your starting conditions, I'd advise the reading of
http://compnetworking.about.com/cs/isps/gr/aapr-cisco_ispe.htm which you
can download a free (2001 ed.) copy of from Cisco at
ftp://ftp-eng.cisco.com/cons/isp/documents/IOSEssentialsPDF.zip.

Probably a little dated and with lots of Cisco specific stuff, but most of
the concepts can probably be extrapolated to other devices.

Not sure if it covers billing, though, and probably won't cover wifi/wimax.

HTH.



On 19 October 2013 20:57, Notify Me <notify.sina at gmail.com> wrote:

> Hi,
>
> Please allow me to apologize profusely if my post is offensive, or in
> error.
> I have been lurking on this list watching and learning from all the great
> posts here and am in awe of everyone here. I can only hope one day to be as
> knowledgeable as anyone on this list.
>
> That being said, some people who have a lot more faith in my abilities than
> I do seem to think I am the go-to guy for network information. And they
> foolishly asked me for assistance in putting together a small ISP network
> which is supposed to cater for home users inside of a residential area,
> very likely wireless (wifi/WIMAX).
>
> I have no idea what the nuts and bolts of this kind of setup are. All I
> have in my toolbox are some hastily learnt CCNA lingo, a good knowledge of
> networks, system and network admin experience, and a deep love of open
> source software.
>
> I'm hoping the great gurus on this site can advise me on what needs to be
> put together ( infrastructure, AAA, billing, etc) for this to run?
>
> I confess I am really interested in helping my questioners put this
> together, not just for whatever material gain (which is unlikely at this
> point), but just for the experience which is very valuable to me. I also
> have to state that I live in Nigeria, so whatever advice you offer has to
> be fourth-world applicable.
>
> I humbly await your kind responses, and I apologize once again if I am in
> error.
>
> Thanks for listening!
>

From sroche at lakelandnetworks.com  Sun Oct 20 13:02:39 2013
From: sroche at lakelandnetworks.com (Sam Roche)
Date: Sun, 20 Oct 2013 09:02:39 -0400
Subject: Pad 1310nm cross-connects?
In-Reply-To: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
Message-ID: <20131020130239.5132429.34560.10853@lakelandnetworks.com>


From mfidelman at meetinghouse.net  Sun Oct 20 13:12:39 2013
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Sun, 20 Oct 2013 09:12:39 -0400
Subject: In Over My Head -- What do I need to setup a tiny ISP?
In-Reply-To: <5263D557.4070409@meetinghouse.net>
References: <5263D557.4070409@meetinghouse.net>
Message-ID: <5263D6C7.3020109@meetinghouse.net>


Notify Me wrote:
>
> That being said, some people who have a lot more faith in my abilities than
> I do seem to think I am the go-to guy for network information. And they
> foolishly asked me for assistance in putting together a small ISP network
> which is supposed to cater for home users inside of a residential area,
> very likely wireless (wifi/WIMAX).
>

A key question: is this going to be a commercial service run as a
business, or an internal operation like a campus network?  The
operations aren't that different, but the scope and organiation can be
different.

Another key question:  Are you focusing just on the infrastructure
(wireless IP) or will you be providing email, hosting services, and so
forth?

> I confess I am really interested in helping my questioners put this
> together, not just for whatever material gain (which is unlikely at this
> point), but just for the experience which is very valuable to me. I also
> have to state that I live in Nigeria, so whatever advice you offer has to
> be fourth-world applicable.
>
>

I admit that your query raised my interest, so I did a little looking,
and found this:
http://www.fnbc.info/sites/default/files/fck-uploads/file/fntc/ISP%20Guide%20-%20V1.2.pdf
A guide put together by the "First Nations Technology Council" - on how
to put together an ISP on tribal lands in Canada - which might be
somewhat analogous to your situation.  It's somewhat basic, but gives an
overview - then you can start looking into the individual topics it
talks about.  You might drop them an email.
There's also been a lot of work on US tribal reservations that might
apply - you'll have to do some googling to find resources.

Now the guy you really want to talk to is Dave Hughes, of Big Sky
Telegraph - who used to do a lot of network building for rural areas in
the US and remote areas around the world - unfortunately he's long
retired - but two sources you could look at that might give you a lot
of background:
http://www.bigskytelegraph.com/ (which now seems to lead to the Dillon
Center of Excellence, focusing on best practices for rural America,
including networking)
and
http://www.davehugheslegacy.net/

There used to be an "Association for Community Networking" - folks
involved in building cooperative local networks (used to be a lot of
what I was involved in the 1990s) but that kind of activity has dried up
as more and more commercial players entered the market. And an
"Organization for Community Networks" (http://ofcn.org/) - but their web
site seems to be kind of dead (some useful links, though).  If you
google "community network" you'll find a buch of current operations -
and you might want to contact some of them.

There are also a growing number of community mesh networks in various
places - WikiPedia's page on
http://en.wikipedia.org/wiki/Wireless_community_network might be a good
starting point.  There's also an association of wireless ISPs
http://www.wispa.org/

Then there's this guy: https://www.facebook.com/theispguy - who seems to
have written a book on "so you want to be an ISP" - can't say anything
about how good it is.

Or.. you might just go looking for other ISPs in Nigeria (of which there
are quite a few) and see if you can get some advice (amazing what you
can learn over a few beers).  Maybe contact the networking people at the
nearest college or university.  I don't know what it's like in Nigeria,
but in the US, the academic community was really active in getting a lot
of early ISPs started - particularly in smaller communities.


One other thought: there are quite a few software packages floating
around for managing aspects of ISP operations (see
https://wiki.debian.org/HostingControlPanels for starters) - I expect
their user communities (and email lists) would be excellent sources of
information.

Hope this helps.

Regards,

Miles Fidelman






-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra



From mark at amplex.net  Sun Oct 20 13:20:13 2013
From: mark at amplex.net (Mark Radabaugh)
Date: Sun, 20 Oct 2013 09:20:13 -0400
Subject: In Over My Head -- What do I need to setup a tiny ISP?
In-Reply-To: <CACK8u8+h-2te=n=s0N1JmP21nj_qZS+9XKasu8AHjjwx_T649Q@mail.gmail.com>
References: <CACK8u8+h-2te=n=s0N1JmP21nj_qZS+9XKasu8AHjjwx_T649Q@mail.gmail.com>
Message-ID: <5263D88D.40604@amplex.net>

Much of the 'new' activity in ISP's is in wireless last mile.  WISPA is 
a trade organization with several mailing lists where the topics you 
mention are discussed on a regular basis and new ISP questions are not 
unusual (http://www.wispa.org/mailing-lists).  The archives of the 
general mailing list are a good place to start.

You do not have to join WISPA to subscribe to the mailing list or to see 
the archives.

Mark

On 10/19/13 3:57 PM, Notify Me wrote:
> Hi,
>
> Please allow me to apologize profusely if my post is offensive, or in error.
> I have been lurking on this list watching and learning from all the great
> posts here and am in awe of everyone here. I can only hope one day to be as
> knowledgeable as anyone on this list.
>
> That being said, some people who have a lot more faith in my abilities than
> I do seem to think I am the go-to guy for network information. And they
> foolishly asked me for assistance in putting together a small ISP network
> which is supposed to cater for home users inside of a residential area,
> very likely wireless (wifi/WIMAX).
>
> I have no idea what the nuts and bolts of this kind of setup are. All I
> have in my toolbox are some hastily learnt CCNA lingo, a good knowledge of
> networks, system and network admin experience, and a deep love of open
> source software.
>
> I'm hoping the great gurus on this site can advise me on what needs to be
> put together ( infrastructure, AAA, billing, etc) for this to run?
>
> I confess I am really interested in helping my questioners put this
> together, not just for whatever material gain (which is unlikely at this
> point), but just for the experience which is very valuable to me. I also
> have to state that I live in Nigeria, so whatever advice you offer has to
> be fourth-world applicable.
>
> I humbly await your kind responses, and I apologize once again if I am in
> error.
>
> Thanks for listening!


-- 
Mark Radabaugh
Amplex

mark at amplex.net  419.837.5015



From brandon at rd.bbc.co.uk  Sun Oct 20 13:37:53 2013
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Sun, 20 Oct 2013 14:37:53 +0100 (BST)
Subject: Pad 1310nm cross-connects?
Message-ID: <201310201337.OAA00523@sunf10.rd.bbc.co.uk>

> 	LR usually needs padding in that scenario, IMHO.

Usually does not.

1G parts are so cheap that measurement, test and the attenuators
(unless you are wrapping the fibre round a pencil) will cost more
than each device is worth. How many fail?

If in doubt check the device spec such as

http://www.cisco.com/en/US/prod/collateral/modules/ps5455/data_sheet_c78-455693.
html

                 Transmit Power (dBm)  Receive Power (dBm)
                  Maximum Minimum      Maximum  Minimum
Cisco SFP-10G-LR     0.5   -8.2          0.5     -14.4

the max levels are the same so for that part they are designed to be
fine without even the loss of a minimal interconnect.

> This also 
> applies to MMR interconnects or other "premises" / "campus" situations. 5
> or 10dB depending on patching quality -- sometimes up to 15

15 would take the above device out of spec, even 5 is marginal with
typical MMR cross connects. Over its lfe the tx output may drop
and still be within spec so you can't base this on measured when
installed levels.

> As you write, the damage from overload is gradual, so simply 
> trusting "it works" is quite bad for longevity reasons.

If it's operating within spec then return the parts if there is a
significant failure rate attributable (what temperature are you running
them at, that would need to be considered in any statistically
significant study)

If you have evidence of level affecting longevity as described please
post the data or paper demonstrating it which should then let us
choose the optimum signal level for maximum life with a reasonable
operating margin

brandon


From Valdis.Kletnieks at vt.edu  Sun Oct 20 14:55:43 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 20 Oct 2013 10:55:43 -0400
Subject: Fundamental questions of backbone design
In-Reply-To: Your message of "Sat, 19 Oct 2013 12:43:49 -0700."
 <CAEmG1=qT8dGqqD84gAwOvvbzTW+AgiK36CFdUw=EPMQ_rzO4mg@mail.gmail.com>
References: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
 <15023.1382132808@turing-police.cc.vt.edu>
 <CAEmG1=qT8dGqqD84gAwOvvbzTW+AgiK36CFdUw=EPMQ_rzO4mg@mail.gmail.com>
Message-ID: <102812.1382280943@turing-police.cc.vt.edu>

On Sat, 19 Oct 2013 12:43:49 -0700, Matthew Petach said:

> Think about it; if network A prepends 10x to network B, and not at all to
> network C; but network B is a free peer of mine, and network C is a transit
> network I pay money to; following the typical convention of "routes learned
> from network B get localpref'd to 5000, routes learned from transit are
> localpref'd at 1000", you'd end up pushing the traffic along the 10x prepended
> pathway.

Thanks.  Due to the way our private peering works, the only routes we learn
from our "network B"'s are ones that wouldn't prepend because they want to talk
to us over the peer.  So all our prepends show up via our C's.  And I was
insuffiently caffienated to consider the case that we'd see prepends on our B
side...

-------------- 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/20131020/c89c1ffd/attachment.bin>

From mdavids at forfun.net  Sun Oct 20 17:18:57 2013
From: mdavids at forfun.net (Marco Davids)
Date: Sun, 20 Oct 2013 19:18:57 +0200
Subject: abha ahuja
In-Reply-To: <m2sivwvqg2.wl%randy@psg.com>
References: <m2sivwvqg2.wl%randy@psg.com>
Message-ID: <52641081.5050707@forfun.net>

Op 20-10-13 00:36, Randy Bush schreef:
> abha ahuja, researcher and operator, died this day in 2001
All these dear people that have passed away... Makes you think about
your own mortality, doesn't it?

And the list isn't going to get shorter, I am afraid. Kinda depressing...

Perhaps we should create a special remembrance day, once a year, where
we remember all of them?
And carry on with joy on all other days.

-- 
Marco


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4219 bytes
Desc: S/MIME-cryptografische ondertekening
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131020/5581b4af/attachment.bin>

From LarrySheldon at cox.net  Sun Oct 20 17:25:07 2013
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Sun, 20 Oct 2013 12:25:07 -0500
Subject: abha ahuja
In-Reply-To: <fVL51m01E1Una3W01VL68f>
References: <m2sivwvqg2.wl%randy@psg.com> <fVL51m01E1Una3W01VL68f>
Message-ID: <526411F3.7090506@cox.net>

On 10/20/2013 12:18 PM, Marco Davids wrote:
> Op 20-10-13 00:36, Randy Bush schreef:
>> abha ahuja, researcher and operator, died this day in 2001
> All these dear people that have passed away... Makes you think about
> your own mortality, doesn't it?
>
> And the list isn't going to get shorter, I am afraid. Kinda depressing...
>
> Perhaps we should create a special remembrance day, once a year, where
> we remember all of them?
> And carry on with joy on all other days.


FWIIW:  I believe that a day to honor everybody is a day that honors nobody.



-- 
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 eric at lumaoptics.net  Sun Oct 20 04:33:08 2013
From: eric at lumaoptics.net (Eric Litvin)
Date: Sat, 19 Oct 2013 21:33:08 -0700
Subject: Pad 1310nm cross-connects?
In-Reply-To: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
References: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
Message-ID: <A2960BCF-3ADD-44A4-A3F0-5D18E8B1D6CA@lumaoptics.net>

Hi Chris,

I'm with an optics vendor, Luma optics. All our optics are field programmable to work in any intended network environment. Regarding your question, its  unnecessary to pad a 10km LR, even with such a short reach ( 20m) .  If it were an ER or ZR, it would be a different story. 
Good luck with you project. 

Regards, 

Eric Litvin
LumaOptics.net
650 996 7270

Sent from my iPhone

> On Oct 19, 2013, at 7:33 PM, Chris Costa <ccosta92630 at gmail.com> wrote:
> 
> What are the opinions/views on attenuating short, 1310nm LR cross-connects.
> Assume < 20m cable length and utilizing the same vendor optics on each
> side of the link.  Considering the LR transmit spec doesn't exceed the
> receiver's high threshold value do you pad the receiver closer to the
> median RX range to avoid potential receiver burnout over time, or just
> leave it un-padded?
> 
> Thanks


From joelja at bogus.com  Sun Oct 20 19:11:52 2013
From: joelja at bogus.com (joel jaeggli)
Date: Sun, 20 Oct 2013 12:11:52 -0700
Subject: Pad 1310nm cross-connects?
In-Reply-To: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
References: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
Message-ID: <4467732C-E306-493A-99D9-BC93E6FD3BE4@bogus.com>

It's a pretty normal situation.  even with a 1-2m jumper I see light levels that are well below the maximum rx levels for 10km optics. e.g. the max might be .5 and the actual readings are -1.4 - -2.7. our WDM terminals sit in the the adjacent racks to the pop routers so they're all like that. 

ER/ZR is another matter.

On Oct 19, 2013, at 7:33 PM, Chris Costa <ccosta92630 at gmail.com> wrote:

> What are the opinions/views on attenuating short, 1310nm LR cross-connects.
> Assume < 20m cable length and utilizing the same vendor optics on each
> side of the link.  Considering the LR transmit spec doesn't exceed the
> receiver's high threshold value do you pad the receiver closer to the
> median RX range to avoid potential receiver burnout over time, or just
> leave it un-padded?
> 
> Thanks
> 

-------------- 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/20131020/d7074737/attachment.bin>

From streiner at cluebyfour.org  Sun Oct 20 16:13:06 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sun, 20 Oct 2013 12:13:06 -0400 (EDT)
Subject: Pad 1310nm cross-connects?
In-Reply-To: <4467732C-E306-493A-99D9-BC93E6FD3BE4@bogus.com>
References: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
 <4467732C-E306-493A-99D9-BC93E6FD3BE4@bogus.com>
Message-ID: <Pine.LNX.4.64.1310201210240.15115@whammy.cluebyfour.org>

On Sun, 20 Oct 2013, joel jaeggli wrote:

> It's a pretty normal situation.  even with a 1-2m jumper I see light levels that are well below the maximum rx levels for 10km optics. e.g. the max might be .5 and the actual readings are -1.4 - -2.7. our WDM terminals sit in the the adjacent racks to the pop routers so they're all like that.
>
> ER/ZR is another matter.

Yes, ER/ZR must be attenuated unless the run is sufficiently long.  We 
have a link that's a bit too long for LR, but we still had to attenuate 
because the ER optics were reporting excessively high receive levels.

jms


From mansaxel at besserwisser.org  Sun Oct 20 19:59:04 2013
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Sun, 20 Oct 2013 21:59:04 +0200
Subject: Pad 1310nm cross-connects?
In-Reply-To: <20131020052142.GB2783@besserwisser.org>
References: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
 <20131020052142.GB2783@besserwisser.org>
Message-ID: <20131020195903.GC2783@besserwisser.org>

Subject: Re: Pad 1310nm cross-connects? Date: Sun, Oct 20, 2013 at 07:21:42AM +0200 Quoting M?ns Nilsson (mansaxel at besserwisser.org):
> Subject: Pad 1310nm cross-connects? Date: Sat, Oct 19, 2013 at 07:33:19PM -0700 Quoting Chris Costa (ccosta92630 at gmail.com):
> > What are the opinions/views on attenuating short, 1310nm LR cross-connects.
> >  Assume < 20m cable length and utilizing the same vendor optics on each
> > side of the link.  Considering the LR transmit spec doesn't exceed the
> > receiver's high threshold value do you pad the receiver closer to the
> > median RX range to avoid potential receiver burnout over time, or just
> > leave it un-padded?
> 
> 	LR usually needs padding in that scenario, IMHO. This also 

My apologies. I was thinking not of 10km / 20km class optics but the
80-100km stuff. There, padding is quite necessary in short-range setups.
For 10/20km stuff, I, too, have run lots of 2m patch cords directly
between linecards without harm.

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
One FISHWICH coming up!!

Courtesy conversions: (km->miles, km-> miles, metres/100 -> feet) 

10/1.6
6.25000000000000000000
80/1.6
50.00000000000000000000
200/(2.54*12)
6.56167979002624671916


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

From bicknell at ufp.org  Sun Oct 20 20:14:59 2013
From: bicknell at ufp.org (Leo Bicknell)
Date: Sun, 20 Oct 2013 13:14:59 -0700
Subject: Pad 1310nm cross-connects?
In-Reply-To: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
References: <CAN8DL0XVDUV20-Wk6LYuuuufq22VnNznOVRvwL=_aYt90bagkg@mail.gmail.com>
Message-ID: <20131020201459.GA8399@ussenterprise.ufp.org>

In a message written on Sat, Oct 19, 2013 at 07:33:19PM -0700, Chris Costa wrote:
> What are the opinions/views on attenuating short, 1310nm LR cross-connects.
>  Assume < 20m cable length and utilizing the same vendor optics on each
> side of the link.  Considering the LR transmit spec doesn't exceed the
> receiver's high threshold value do you pad the receiver closer to the
> median RX range to avoid potential receiver burnout over time, or just
> leave it un-padded?

With any optics, you need to go to the specifications.

I assume here you mean 10GbaseLR, although I will point out that "LR" is
ambiguous as there is also for instance OC192-LR.

I'm going to pick on Juniper specs, just because they were the easiest
to find with Google:

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/transceiver-m-mx-t-series-10-gigabit-optical-specifications.html

And similar for 1000baseLX, the similar technology for GigE:

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/transceiver-m-mx-t-series-1000base-optical-specifications.html

Note that for both 10GbaseLR and 1000baseLX the transmitter power range
is entirely inside the allowed receiver range.  They were designed this
way on purpose, to never need a pad.  An in-spec optic can never over
drive the receiver, even with zero loss.

Answering your question, I would never pad them.

Compare with for instance a 10Gbase-ER or 1000baseEX, 40km over
single mode optics.  In both cases an in-spec can exceed a receiver.
10Gbase-ER can transmit up to +4.0dBm, while the receiver needs
-1.0dBm or below.  When connecting them "back to back" a 5dB
attenuator is required to keep the receiver in-spec.  For any real
connections (over a fiber path more trivial than a jumper) a light
meter should be used, the value checked, and an attenuator that
places the circuit 1-2dB inside of the safe zone of the receiver
should be used.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131020/dc22a687/attachment.bin>

From j at arpa.com  Mon Oct 21 10:46:14 2013
From: j at arpa.com (jamie rishaw)
Date: Mon, 21 Oct 2013 05:46:14 -0500
Subject: NANOG Pager : Captain Zappos,
 white courtesy phone. Captain Zappos eng?
Message-ID: <CAJ-M0Y=dSdVFUq9yT+VSwpCNt6EE8NTbyHvkRocg+amncqqM7g@mail.gmail.com>

.. No, the white one.

</Airplane! reference>

In all seriousness - Any engs from Zappos?  Please contact me off list

TYVM

-jamie

From randy at psg.com  Mon Oct 21 14:31:28 2013
From: randy at psg.com (Randy Bush)
Date: Mon, 21 Oct 2013 16:31:28 +0200
Subject: Need understand...
In-Reply-To: <6D5364E8-6C57-4BEE-8952-3346D6C7CE8F@gmail.com>
References: <6D5364E8-6C57-4BEE-8952-3346D6C7CE8F@gmail.com>
Message-ID: <m2haca7l1b.wl%randy@psg.com>

feeling a little st00pid here.

randy

---

psg.com:/usr/home/randy> whois www.facebook.com.

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Server Name: WWW.FACEBOOK.COM.BR
   Registrar: UNIVERSO ONLINE S/A (UOL)
   Whois Server: whois.host.uol.com.br
   Referral URL: http://http://www.uol.com.br/host

>>> Last update of whois database: Mon, 21 Oct 2013 14:28:17 UTC <<<

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar.  Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability.  VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
% UOL HOST whois server

Searching for www.facebook.com.
No records matching www.facebook.com found.

psg.com:/usr/home/randy> whois -h whois.lacnic.net. facebook.com.
 % LACNIC resource: whois.lacnic.net


% Copyright LACNIC lacnic.net
%  The data below is provided for information purposes
%  and to assist persons in obtaining information about or
%  related to AS and IP numbers registrations
%  By submitting a whois query, you agree to use this data
%  only for lawful purposes.
%  2013-10-21 12:29:25 (BRST -02:00)

% No match for "FACEBOOK.COM."

% whois.lacnic.net accepts only direct match queries.
% Types of queries are: POCs, ownerid, CIDR blocks, IP
% and AS numbers.

psg.com:/usr/home/randy> whois -h whois.lacnic.net. www.facebook.com.
 % LACNIC resource: whois.lacnic.net


% Copyright LACNIC lacnic.net
%  The data below is provided for information purposes
%  and to assist persons in obtaining information about or
%  related to AS and IP numbers registrations
%  By submitting a whois query, you agree to use this data
%  only for lawful purposes.
%  2013-10-21 12:29:36 (BRST -02:00)

% No match for "WWW.FACEBOOK.COM."

% whois.lacnic.net accepts only direct match queries.
% Types of queries are: POCs, ownerid, CIDR blocks, IP
% and AS numbers.



From jabley at hopcount.ca  Mon Oct 21 14:41:10 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Mon, 21 Oct 2013 10:41:10 -0400
Subject: Need understand...
In-Reply-To: <m2haca7l1b.wl%randy@psg.com>
References: <6D5364E8-6C57-4BEE-8952-3346D6C7CE8F@gmail.com>
 <m2haca7l1b.wl%randy@psg.com>
Message-ID: <D0F93502-1F81-4C81-BD56-AE5815AFB118@hopcount.ca>


On 2013-10-21, at 10:31, Randy Bush <randy at psg.com> wrote:

> feeling a little st00pid here.

The crsnic servers return hostname matches as well as domain matches, an enduring source of confusion for many years.

You can make the server show all records that match using "=". There's other stuff, whois -h whois.crsnic.net help for more.

By default, the server your whois client is using depends on the client. Some of the code I once wrote for OpenBSD's /usr/bin/whois has survived there and has insinuated itself into other platforms; if your whois is similar then it's using Ultra's whois-servers.net collection (so it's looking up com.whois-servers.net and finding whois.verisign-grs.com. That's a different server from whois.crsnic.net (at least, it has a different address). It's all a bit of a mess.


Joe

[krill:~]% whois -h whois.crsnic.net '=facebook.com'

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Server Name: FACEBOOK.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
   IP Address: 69.41.185.229
   Registrar: TUCOWS DOMAINS INC.
   Whois Server: whois.tucows.com
   Referral URL: http://domainhelp.opensrs.net

   Server Name: FACEBOOK.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM
   IP Address: 203.36.226.2
   Registrar: INSTRA CORPORATION PTY, LTD.
   Whois Server: whois.instra.net
   Referral URL: http://www.instra.com

   Server Name: FACEBOOK.COM.LOVED.BY.WWW.SHQIPHOST.COM
   IP Address: 46.4.210.254
   Registrar: ONLINENIC, INC.
   Whois Server: whois.onlinenic.com
   Referral URL: http://www.OnlineNIC.com

   Server Name: FACEBOOK.COM.KNOWS.THAT.THE.BEST.WEB.HOSTING.IS.NASHHOST.NET
   IP Address: 78.47.16.44
   Registrar: CENTER OF UKRAINIAN INTERNET NAMES
   Whois Server: whois.ukrnames.com
   Referral URL: http://www.ukrnames.com

   Server Name: FACEBOOK.COM.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM
   IP Address: 209.126.190.70
   Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
   Whois Server: whois.PublicDomainRegistry.com
   Referral URL: http://www.PublicDomainRegistry.com

   Server Name: FACEBOOK.COM.DISABLE.YOUR.TIMELINE.NOW.WITH.THE.ORIGINAL.TIMELINE-REMOVE.NET
   IP Address: 8.8.8.8
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com

   Domain Name: FACEBOOK.COM
   Registrar: MARKMONITOR INC.
   Whois Server: whois.markmonitor.com
   Referral URL: http://www.markmonitor.com
   Name Server: A.NS.FACEBOOK.COM
   Name Server: B.NS.FACEBOOK.COM
   Status: clientDeleteProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Status: serverDeleteProhibited
   Status: serverTransferProhibited
   Status: serverUpdateProhibited
   Updated Date: 28-sep-2012
   Creation Date: 29-mar-1997
   Expiration Date: 30-mar-2020

>>> Last update of whois database: Mon, 21 Oct 2013 14:37:21 UTC <<<

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar.  Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability.  VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
[krill:~]% 



From randy at psg.com  Mon Oct 21 14:42:59 2013
From: randy at psg.com (Randy Bush)
Date: Mon, 21 Oct 2013 16:42:59 +0200
Subject: Need understand...
In-Reply-To: <D0F93502-1F81-4C81-BD56-AE5815AFB118@hopcount.ca>
References: <6D5364E8-6C57-4BEE-8952-3346D6C7CE8F@gmail.com>
 <m2haca7l1b.wl%randy@psg.com>
 <D0F93502-1F81-4C81-BD56-AE5815AFB118@hopcount.ca>
Message-ID: <m2eh7e7ki4.wl%randy@psg.com>

lovely.  i have a bad cold, can think even less than usual, and this is
not pretty.  but thanks.

randy


From Michael.Studniberg at ontario.ca  Mon Oct 21 14:58:37 2013
From: Michael.Studniberg at ontario.ca (Studniberg, Michael (MEDTE/MRI))
Date: Mon, 21 Oct 2013 14:58:37 +0000
Subject: In Over My Head -- What do I need to setup a tiny ISP?
In-Reply-To: <5263D88D.40604@amplex.net>
References: <CACK8u8+h-2te=n=s0N1JmP21nj_qZS+9XKasu8AHjjwx_T649Q@mail.gmail.com>
 <5263D88D.40604@amplex.net>
Message-ID: <1DFC15778EFBDF4DAE144917138CC1390818CD13@CTSPIGDCAPMXS21.cihs.ad.gov.on.ca>

I would also mention that Ubiquity (vendor of a lot of wireless gear) has an excellent (active and friendly) community forum. There are a number of posts on there from people in similar positions. You might give it a shot:

http://community.ubnt.com/

I do not work for Ubiquity nor do I have any material interest in the company. 

Mike

Michael Studniberg, P.Eng
Government of Ontario
Michael.Studniberg at ontario.ca
Office: (416) 212-6176
Mobile: (416) 884-1650

-----Original Message-----
From: Mark Radabaugh [mailto:mark at amplex.net] 
Sent: October 20, 2013 9:20 AM
To: nanog at nanog.org
Subject: Re: In Over My Head -- What do I need to setup a tiny ISP?

Much of the 'new' activity in ISP's is in wireless last mile.  WISPA is a trade organization with several mailing lists where the topics you mention are discussed on a regular basis and new ISP questions are not unusual (http://www.wispa.org/mailing-lists).  The archives of the general mailing list are a good place to start.

You do not have to join WISPA to subscribe to the mailing list or to see the archives.

Mark

On 10/19/13 3:57 PM, Notify Me wrote:
> Hi,
>
> Please allow me to apologize profusely if my post is offensive, or in error.
> I have been lurking on this list watching and learning from all the 
> great posts here and am in awe of everyone here. I can only hope one 
> day to be as knowledgeable as anyone on this list.
>
> That being said, some people who have a lot more faith in my abilities 
> than I do seem to think I am the go-to guy for network information. 
> And they foolishly asked me for assistance in putting together a small 
> ISP network which is supposed to cater for home users inside of a 
> residential area, very likely wireless (wifi/WIMAX).
>
> I have no idea what the nuts and bolts of this kind of setup are. All 
> I have in my toolbox are some hastily learnt CCNA lingo, a good 
> knowledge of networks, system and network admin experience, and a deep 
> love of open source software.
>
> I'm hoping the great gurus on this site can advise me on what needs to 
> be put together ( infrastructure, AAA, billing, etc) for this to run?
>
> I confess I am really interested in helping my questioners put this 
> together, not just for whatever material gain (which is unlikely at 
> this point), but just for the experience which is very valuable to me. 
> I also have to state that I live in Nigeria, so whatever advice you 
> offer has to be fourth-world applicable.
>
> I humbly await your kind responses, and I apologize once again if I am 
> in error.
>
> Thanks for listening!


--
Mark Radabaugh
Amplex

mark at amplex.net  419.837.5015




From notify.sina at gmail.com  Mon Oct 21 15:29:37 2013
From: notify.sina at gmail.com (Notify Me)
Date: Mon, 21 Oct 2013 16:29:37 +0100
Subject: In Over My Head -- What do I need to setup a tiny ISP?
In-Reply-To: <1DFC15778EFBDF4DAE144917138CC1390818CD13@CTSPIGDCAPMXS21.cihs.ad.gov.on.ca>
References: <CACK8u8+h-2te=n=s0N1JmP21nj_qZS+9XKasu8AHjjwx_T649Q@mail.gmail.com>
 <5263D88D.40604@amplex.net>
 <1DFC15778EFBDF4DAE144917138CC1390818CD13@CTSPIGDCAPMXS21.cihs.ad.gov.on.ca>
Message-ID: <CACK8u8JThE5ABs1ezG=_VPE1X_cVMO7Q1yiEYBB3DYL1H=kdBg@mail.gmail.com>

Thanks a lot everyone. You responses are so full
On Oct 21, 2013 4:21 PM, "Studniberg, Michael (MEDTE/MRI)" <
Michael.Studniberg at ontario.ca> wrote:

> I would also mention that Ubiquity (vendor of a lot of wireless gear) has
> an excellent (active and friendly) community forum. There are a number of
> posts on there from people in similar positions. You might give it a shot:
>
> http://community.ubnt.com/
>
> I do not work for Ubiquity nor do I have any material interest in the
> company.
>
> Mike
>
> Michael Studniberg, P.Eng
> Government of Ontario
> Michael.Studniberg at ontario.ca
> Office: (416) 212-6176
> Mobile: (416) 884-1650
>
> -----Original Message-----
> From: Mark Radabaugh [mailto:mark at amplex.net]
> Sent: October 20, 2013 9:20 AM
> To: nanog at nanog.org
> Subject: Re: In Over My Head -- What do I need to setup a tiny ISP?
>
> Much of the 'new' activity in ISP's is in wireless last mile.  WISPA is a
> trade organization with several mailing lists where the topics you mention
> are discussed on a regular basis and new ISP questions are not unusual (
> http://www.wispa.org/mailing-lists).  The archives of the general mailing
> list are a good place to start.
>
> You do not have to join WISPA to subscribe to the mailing list or to see
> the archives.
>
> Mark
>
> On 10/19/13 3:57 PM, Notify Me wrote:
> > Hi,
> >
> > Please allow me to apologize profusely if my post is offensive, or in
> error.
> > I have been lurking on this list watching and learning from all the
> > great posts here and am in awe of everyone here. I can only hope one
> > day to be as knowledgeable as anyone on this list.
> >
> > That being said, some people who have a lot more faith in my abilities
> > than I do seem to think I am the go-to guy for network information.
> > And they foolishly asked me for assistance in putting together a small
> > ISP network which is supposed to cater for home users inside of a
> > residential area, very likely wireless (wifi/WIMAX).
> >
> > I have no idea what the nuts and bolts of this kind of setup are. All
> > I have in my toolbox are some hastily learnt CCNA lingo, a good
> > knowledge of networks, system and network admin experience, and a deep
> > love of open source software.
> >
> > I'm hoping the great gurus on this site can advise me on what needs to
> > be put together ( infrastructure, AAA, billing, etc) for this to run?
> >
> > I confess I am really interested in helping my questioners put this
> > together, not just for whatever material gain (which is unlikely at
> > this point), but just for the experience which is very valuable to me.
> > I also have to state that I live in Nigeria, so whatever advice you
> > offer has to be fourth-world applicable.
> >
> > I humbly await your kind responses, and I apologize once again if I am
> > in error.
> >
> > Thanks for listening!
>
>
> --
> Mark Radabaugh
> Amplex
>
> mark at amplex.net  419.837.5015
>
>
>
>

From notify.sina at gmail.com  Mon Oct 21 15:34:04 2013
From: notify.sina at gmail.com (Notify Me)
Date: Mon, 21 Oct 2013 16:34:04 +0100
Subject: In Over My Head -- What do I need to setup a tiny ISP?
In-Reply-To: <1DFC15778EFBDF4DAE144917138CC1390818CD13@CTSPIGDCAPMXS21.cihs.ad.gov.on.ca>
References: <CACK8u8+h-2te=n=s0N1JmP21nj_qZS+9XKasu8AHjjwx_T649Q@mail.gmail.com>
 <5263D88D.40604@amplex.net>
 <1DFC15778EFBDF4DAE144917138CC1390818CD13@CTSPIGDCAPMXS21.cihs.ad.gov.on.ca>
Message-ID: <CACK8u8+h103F4EFfO5L8G6FwvmT5cERC_L+dqThbyXrooS5cew@mail.gmail.com>

Thank you so much everyone. I have so much information that I'm not sure
how to process it all.

I am deeply grateful. In a week or so I should probably be able to pose as
a subject matter expert (I wish)!

I'll definitely be back with more questions but for now let me just say
thank you, thank you, thank you all.
On Oct 21, 2013 4:21 PM, "Studniberg, Michael (MEDTE/MRI)" <
Michael.Studniberg at ontario.ca> wrote:

> I would also mention that Ubiquity (vendor of a lot of wireless gear) has
> an excellent (active and friendly) community forum. There are a number of
> posts on there from people in similar positions. You might give it a shot:
>
> http://community.ubnt.com/
>
> I do not work for Ubiquity nor do I have any material interest in the
> company.
>
> Mike
>
> Michael Studniberg, P.Eng
> Government of Ontario
> Michael.Studniberg at ontario.ca
> Office: (416) 212-6176
> Mobile: (416) 884-1650
>
> -----Original Message-----
> From: Mark Radabaugh [mailto:mark at amplex.net]
> Sent: October 20, 2013 9:20 AM
> To: nanog at nanog.org
> Subject: Re: In Over My Head -- What do I need to setup a tiny ISP?
>
> Much of the 'new' activity in ISP's is in wireless last mile.  WISPA is a
> trade organization with several mailing lists where the topics you mention
> are discussed on a regular basis and new ISP questions are not unusual (
> http://www.wispa.org/mailing-lists).  The archives of the general mailing
> list are a good place to start.
>
> You do not have to join WISPA to subscribe to the mailing list or to see
> the archives.
>
> Mark
>
> On 10/19/13 3:57 PM, Notify Me wrote:
> > Hi,
> >
> > Please allow me to apologize profusely if my post is offensive, or in
> error.
> > I have been lurking on this list watching and learning from all the
> > great posts here and am in awe of everyone here. I can only hope one
> > day to be as knowledgeable as anyone on this list.
> >
> > That being said, some people who have a lot more faith in my abilities
> > than I do seem to think I am the go-to guy for network information.
> > And they foolishly asked me for assistance in putting together a small
> > ISP network which is supposed to cater for home users inside of a
> > residential area, very likely wireless (wifi/WIMAX).
> >
> > I have no idea what the nuts and bolts of this kind of setup are. All
> > I have in my toolbox are some hastily learnt CCNA lingo, a good
> > knowledge of networks, system and network admin experience, and a deep
> > love of open source software.
> >
> > I'm hoping the great gurus on this site can advise me on what needs to
> > be put together ( infrastructure, AAA, billing, etc) for this to run?
> >
> > I confess I am really interested in helping my questioners put this
> > together, not just for whatever material gain (which is unlikely at
> > this point), but just for the experience which is very valuable to me.
> > I also have to state that I live in Nigeria, so whatever advice you
> > offer has to be fourth-world applicable.
> >
> > I humbly await your kind responses, and I apologize once again if I am
> > in error.
> >
> > Thanks for listening!
>
>
> --
> Mark Radabaugh
> Amplex
>
> mark at amplex.net  419.837.5015
>
>
>
>

From r.engehausen at gmail.com  Mon Oct 21 15:58:03 2013
From: r.engehausen at gmail.com (Roy)
Date: Mon, 21 Oct 2013 08:58:03 -0700
Subject: SORBS email
Message-ID: <52654F0B.9060507@gmail.com>

I sent an email to SORBS some time ago and I received this yesterday

     Reason: unable to deliver this message after 135 days

Got to admit that SORBS email servers aren't timely but they are persistent.




From sandy at tislabs.com  Mon Oct 21 17:35:42 2013
From: sandy at tislabs.com (sandy at tislabs.com)
Date: Mon, 21 Oct 2013 13:35:42 -0400 (EDT)
Subject: In Over My Head -- What do I need to setup a tiny ISP?
Message-ID: <20131021173542.5388E1F8034@nova.tislabs.com>

> I'm hoping the great gurus on this site can advise me on what needs to=20
> be put together ( infrastructure, AAA, billing, etc) for this to run?

No one has yet pointed you to the Network Startup Resource Center
http://www.nsrc.org/about.html
or AfNOG
http://www.afnog.org
which might be good resources.

--Sandy


From bzs at world.std.com  Mon Oct 21 18:50:19 2013
From: bzs at world.std.com (Barry Shein)
Date: Mon, 21 Oct 2013 14:50:19 -0400
Subject: SORBS email
In-Reply-To: <52654F0B.9060507@gmail.com>
References: <52654F0B.9060507@gmail.com>
Message-ID: <21093.30571.793652.877381@world.std.com>


On October 21, 2013 at 08:58 r.engehausen at gmail.com (Roy) wrote:
 > I sent an email to SORBS some time ago and I received this yesterday
 > 
 >      Reason: unable to deliver this message after 135 days
 > 
 > Got to admit that SORBS email servers aren't timely but they are persistent.


SORBS only deals in eternal truths.


-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From j at arpa.com  Tue Oct 22 06:18:55 2013
From: j at arpa.com (jamie rishaw)
Date: Tue, 22 Oct 2013 01:18:55 -0500
Subject: 80 Gbps ?
Message-ID: <CABL6YZRdDA3-sSaXBbjjvm1Z4eefqizAUngGF-gXfP0Hq4UeuQ@mail.gmail.com>

  I'm looking at a site named the "digital attack map" (dot com).

  There's one attack that lists an attack at some near 80 Gbps inbound.
( Clip Cap at http://screencast.com/t/M59qmJhcWSW )

  Some questions.  Maybe I've just been lucky... but,

A)  /Seriously/ ?  80 Gbps ?

B) Other than dropping routes / changing DNS and "filtering at the borders"
are there controls that operators employ that help mitigate multi-Gbps
attacks?

I understand if - by the nature of talking about it, 'we' give attackers
insight, so I'm willing to entertain private discussions; However, this
seems to be a semi appropriate place as a catalyst.

I'd be interested in a discussion, a ML, or resources that any people can
provide, via this list or off list.

-jamie
-- 
jamie rishaw // .com.arpa at j <- reverse it. ish.

*"Reality defeats prejudice."* - *Rep. Barney Frank*

From web at typo.org  Tue Oct 22 06:34:16 2013
From: web at typo.org (Wayne E Bouchard)
Date: Mon, 21 Oct 2013 23:34:16 -0700
Subject: abha ahuja
In-Reply-To: <m2sivwvqg2.wl%randy@psg.com>
References: <m2sivwvqg2.wl%randy@psg.com>
Message-ID: <20131022063416.GA46999@wakko.typo.org>

I met her briefly at the Phoenix NANOG back when. (I want to say she
was speaking with Guy Tal at the time and that's who introduced me but
not sure.) I was shocked to hear that she passed not all that long
afterwards. She was bright and full of energy and not someone you
would expect to see an obituary on just two or three years later.

On Sun, Oct 20, 2013 at 01:36:13AM +0300, Randy Bush 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.
> 
> randy

---
Wayne Bouchard
web at typo.org
Network Dude
http://www.typo.org/~web/


From rdobbins at arbor.net  Tue Oct 22 07:15:15 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 22 Oct 2013 07:15:15 +0000
Subject: 80 Gbps ?
In-Reply-To: <CABL6YZRdDA3-sSaXBbjjvm1Z4eefqizAUngGF-gXfP0Hq4UeuQ@mail.gmail.com>
References: <CABL6YZRdDA3-sSaXBbjjvm1Z4eefqizAUngGF-gXfP0Hq4UeuQ@mail.gmail.com>
Message-ID: <00389BFA-F5EA-4E04-97C2-330D5A8F0288@arbor.net>


On Oct 22, 2013, at 8:19 AM, "jamie rishaw" <j at arpa.com> wrote:

> A)  /Seriously/ ?  80 Gbps ?


100gb/sec+ DDoS attacks have been seen for the last 3 years or more - 80gb/sec isn't that rare, unfortunately.  Most (but not all) of these very high-bandwidth DDoS attacks are DNS, SNMP, ntp, or game-server reflection/amplification attacks.

> B) Other than dropping routes / changing DNS and "filtering at the borders"
> are there controls that operators employ that help mitigate multi-Gbps
> attacks?

S/RTBH, shutting down links, cooperative multi-operator mitigation, BCP38/84, etc.

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




From brian.nutter at ttu.edu  Mon Oct 21 19:44:45 2013
From: brian.nutter at ttu.edu (Nutter, Brian)
Date: Mon, 21 Oct 2013 19:44:45 +0000
Subject: FW: SSIAI Call for Papers 2014 San Diego California April 4-6
Message-ID: <CA603F1116360346B05169B25C52CFBD1F8062@cyclops06.ttu.edu>

Listkeeper,

Can you help us get the word out?

Brian



Dr. Brian Nutter, PE
Associate Professor
Associate Chairman for Undergraduate Studies
Department of Electrical and Computer Engineering
Texas Tech University
MS 3102
(806) 742-3533

From: Nutter, Brian
Sent: Monday, October 21, 2013 12:40 PM
Subject: SSIAI Call for Papers 2014 San Diego California April 4-6

Colleagues,

On behalf of the SSIAI Organizing Committee, I'd like to invite you to join us at IEEE SSIAI 2014.

The Southwest Symposium on Image Analysis and Interpretation (SSIAI) is a biennial conference dedicated to all aspects of computational analysis and interpretation of images and video. SSIAI brings together researchers and practitioners in academia, industry, and government to share and discuss the latest advances in this field. SSIAI 2014 will be held at the spectacular Humphreys Half Moon Inn & Suites in San Diego, California, U.S.A. The symposium seeks original contributions reporting novel research directions, results, and applications.



Important Dates

December 16, 2013: Papers Due

February 10, 2014: Acceptance Notification

February 24, 2014: Camera-Ready Papers Due
April 6-8, 2014: SSIAI 2014 Conference


Paper Submission
Submit a paper (4 pages max. including figures and references) in double-column IEEE conference format. Submission will be electronic using the PDF format. Accepted full papers will be of the same format with a four-page limit. For further details, please visit www.ssiai.org<http://www.ssiai.org> .

Each accepted paper will be published in the conference proceedings, provided at least one author registers in advance at the non-student rate and gives a presentation at the conference. An author's non-student registration may be applied to up to three papers by that author.


Topics of Interest (not limited to)
Mathematical models and methods
Statistical and learning methods
Features and invariants
Segmentation and grouping
Object detection and tracking
Activity detection and analysis
Image and video indexing and retrieval
Biomedical image analysis
Neuro-signal processing
Biometrics and bioinformatics
Biologically inspired computer vision
Multiscale and multispectral analysis
Remote sensing
Compressive sensing and processing
Stereoscopic and 3-D analysis
Multisensor analysis and processing
Color analysis and processing
Shape representation and recognition
Scene modeling and interpretation
Computational photography
Human computer interaction
Automated inspection
Real-time analysis
Optimization methods
Performance evaluation
Computer vision for robotics
Image and video quality assessment
Computer architectures for image/video processing






Brian



Dr. Brian Nutter, PE
Associate Professor
Associate Chairman for Undergraduate Studies
Department of Electrical and Computer Engineering
Texas Tech University
MS 3102
(806) 742-3533


From mark at viviotech.net  Tue Oct 22 16:59:07 2013
From: mark at viviotech.net (Mark Keymer)
Date: Tue, 22 Oct 2013 09:59:07 -0700
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
Message-ID: <5266AEDB.3070104@viviotech.net>

Hi,

Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?

Sincerely,

-- 
Mark Keymer



From tknchris at gmail.com  Tue Oct 22 17:00:33 2013
From: tknchris at gmail.com (chris)
Date: Tue, 22 Oct 2013 13:00:33 -0400
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <5266AEDB.3070104@viviotech.net>
References: <5266AEDB.3070104@viviotech.net>
Message-ID: <CAKnNFz-ZJWf6QuxUfWjzAW0awjATMJCtTcSWhHMP2rdM78F1bg@mail.gmail.com>

Yes I am seeing this also, getting calls from many clients that cant
resolve domains with netsol dns

chris


On Tue, Oct 22, 2013 at 12:59 PM, Mark Keymer <mark at viviotech.net> wrote:

> Hi,
>
> Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?
>
> Sincerely,
>
> --
> Mark Keymer
>
>
>

From r.engehausen at gmail.com  Tue Oct 22 17:10:10 2013
From: r.engehausen at gmail.com (Roy)
Date: Tue, 22 Oct 2013 10:10:10 -0700
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <5266AEDB.3070104@viviotech.net>
References: <5266AEDB.3070104@viviotech.net>
Message-ID: <5266B172.7020805@gmail.com>

On 10/22/2013 9:59 AM, Mark Keymer wrote:
> Hi,
>
> Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?
>
> Sincerely,
>

Yep.  One of my clients domains seems to be gone.


From carywiedemann at gmail.com  Tue Oct 22 17:10:27 2013
From: carywiedemann at gmail.com (Cary Wiedemann)
Date: Tue, 22 Oct 2013 13:10:27 -0400
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <CAKnNFz-ZJWf6QuxUfWjzAW0awjATMJCtTcSWhHMP2rdM78F1bg@mail.gmail.com>
References: <5266AEDB.3070104@viviotech.net>
 <CAKnNFz-ZJWf6QuxUfWjzAW0awjATMJCtTcSWhHMP2rdM78F1bg@mail.gmail.com>
Message-ID: <CAOutREEZnHt9jqOGUYM1M=3J=fnY_Pc2Jp=hOeQPfhqenrpn=g@mail.gmail.com>

I can also confirm that nearly all of the 'NSXX.WORLDNIC.COM' servers are
either slow to respond or down completely.  I just posted this message to
the 'outages.org' mailing list:

Anyone else seeing massive DNS issues this morning, particularly with
Network Solutions' "hosted zone" servers?

langsam:~# whois carywiedemann.com | grep "Domain servers" -A 3
   Domain servers in listed order:

   NS43.WORLDNIC.COM            205.178.190.22
   NS44.WORLDNIC.COM            206.188.198.22

langsam:~# host carywiedemann.com 206.188.198.22
;; connection timed out; no servers could be reached

Seems to be affecting far more than just my personal domain:

langsam:~# whois blueridgenetworks.com | grep -A 3 "Domain servers"
   Domain servers in listed order:

   NS23.WORLDNIC.COM            205.178.190.12
   NS24.WORLDNIC.COM            206.188.198.12

langsam:~# host blueridgenetworks.com 206.188.198.12
;; connection timed out; no servers could be reached

langsam:~# whois blueridge.com | grep -A 3 "Domain servers"
   Domain servers in listed order:

   NS33.WORLDNIC.COM            205.178.190.17
   NS34.WORLDNIC.COM            206.188.198.17

langsam:~# host blueridge.com 206.188.198.17
;; connection timed out; no servers could be reached

I don't believe any of these NSXX.WORLDNIC.COM servers are anycasted...  is
anyone else having trouble?

Not a peep out of their Twitter feed.

Thanks everyone.

- Cary Wiedemann


On Tue, Oct 22, 2013 at 1:00 PM, chris <tknchris at gmail.com> wrote:

> Yes I am seeing this also, getting calls from many clients that cant
> resolve domains with netsol dns
>
> chris
>
>
> On Tue, Oct 22, 2013 at 12:59 PM, Mark Keymer <mark at viviotech.net> wrote:
>
> > Hi,
> >
> > Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?
> >
> > Sincerely,
> >
> > --
> > Mark Keymer
> >
> >
> >
>

From r.engehausen at gmail.com  Tue Oct 22 17:14:11 2013
From: r.engehausen at gmail.com (Roy)
Date: Tue, 22 Oct 2013 10:14:11 -0700
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <5266B172.7020805@gmail.com>
References: <5266AEDB.3070104@viviotech.net> <5266B172.7020805@gmail.com>
Message-ID: <5266B263.10808@gmail.com>

On 10/22/2013 10:10 AM, Roy wrote:
> On 10/22/2013 9:59 AM, Mark Keymer wrote:
>> Hi,
>>
>> Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?
>>
>> Sincerely,
>>
>
> Yep.  One of my clients domains seems to be gone.


I am getting very slow responses from their DNS servers.  Maybe a DDOS 
against their DNS?


From robertg at garlic.com  Tue Oct 22 17:18:43 2013
From: robertg at garlic.com (Robert Glover)
Date: Tue, 22 Oct 2013 10:18:43 -0700
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <5266AEDB.3070104@viviotech.net>
References: <5266AEDB.3070104@viviotech.net>
Message-ID: <5266B373.6010001@garlic.com>

On 10/22/2013 9:59 AM, Mark Keymer wrote:
> Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?

Yes.  We started getting calls from customers with domains using
*.worldnic.com (i.e. Network Solutions) in the last 15 minutes or so.

-Bobby


From snoble at sonn.com  Tue Oct 22 17:26:44 2013
From: snoble at sonn.com (Steve Noble)
Date: Tue, 22 Oct 2013 10:26:44 -0700
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <5266B373.6010001@garlic.com>
References: <5266AEDB.3070104@viviotech.net> <5266B373.6010001@garlic.com>
Message-ID: <5266B554.7040803@sonn.com>

I noticed Kaiser uses them, sites not resolving.. This should be a fun day for call centers :(

Robert Glover wrote:
> On 10/22/2013 9:59 AM, Mark Keymer wrote:
>> Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?
>
> Yes.  We started getting calls from customers with domains using
> *.worldnic.com (i.e. Network Solutions) in the last 15 minutes or so.
>
> -Bobby
>


From morrowc.lists at gmail.com  Tue Oct 22 17:39:56 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 22 Oct 2013 13:39:56 -0400
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <5266B554.7040803@sonn.com>
References: <5266AEDB.3070104@viviotech.net> <5266B373.6010001@garlic.com>
 <5266B554.7040803@sonn.com>
Message-ID: <CAL9jLaawWtKb09jWpzecz5eFYKC38Ws176v6hXXghKXeD6LAew@mail.gmail.com>

not doubting the call-center thing, but:

;; ANSWER SECTION:
kaiserpermanente.com.   86400   IN      NS      ea-dns14.kp.org.
kaiserpermanente.com.   86400   IN      NS      ea-dns36.kp.org.
kaiserpermanente.com.   86400   IN      NS      ea-dns25.kp.org.

;; ANSWER SECTION:
kaiser.com.             7200    IN      NS      ns65.worldnic.com.
kaiser.com.             7200    IN      NS      ns66.worldnic.com.

Registrant:
Kaiser Interests
   338 Clayton St
   #10
   Denver, CO 80220
   US

   Domain Name: KAISER.COM

   ------------------------------------------------------------------------
   Promote your business to millions of viewers for only $1 a month
   Learn how you can get an Enhanced Business Listing here for your domain name.
   Learn more at http://www.NetworkSolutions.com/
   ------------------------------------------------------------------------

   Administrative Contact:
   Kaiser, Hal          kaiser at KAISER.COM
   435 CLAYTON ST
   DENVER, CO 80206-4230
   US

sure that's the kaiser you're looking for?

On Tue, Oct 22, 2013 at 1:26 PM, Steve Noble <snoble at sonn.com> wrote:
> I noticed Kaiser uses them, sites not resolving.. This should be a fun day
> for call centers :(
>
>
> Robert Glover wrote:
>>
>> On 10/22/2013 9:59 AM, Mark Keymer wrote:
>>>
>>> Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?
>>
>>
>> Yes.  We started getting calls from customers with domains using
>> *.worldnic.com (i.e. Network Solutions) in the last 15 minutes or so.
>>
>> -Bobby
>>
>


From snoble at sonn.com  Tue Oct 22 17:45:31 2013
From: snoble at sonn.com (Steve Noble)
Date: Tue, 22 Oct 2013 10:45:31 -0700
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <CAL9jLaawWtKb09jWpzecz5eFYKC38Ws176v6hXXghKXeD6LAew@mail.gmail.com>
References: <5266AEDB.3070104@viviotech.net> <5266B373.6010001@garlic.com>
 <5266B554.7040803@sonn.com>
 <CAL9jLaawWtKb09jWpzecz5eFYKC38Ws176v6hXXghKXeD6LAew@mail.gmail.com>
Message-ID: <5266B9BB.7080908@sonn.com>

It's at least permanente.net which they use for some of their sites:

http://kp.org/mydoctor/denisearvay redirects to permanente.net

Oops! Google Chrome could not find www.permanente.net

   Administrative Contact, Technical Contact:
   Sadayappan, Prince		prince.i.sadayappan at kp.org
   Kaiser Permanente
   1800 Harrison st
   Oakland, CA 94612
   US
   510-625-6996


   Record expires on 12-Nov-2017.
   Record created on 12-Nov-1999.
   Database last updated on 22-Oct-2013 12:38:41 EDT.

   Domain servers in listed order:

   NS51.WORLDNIC.COM            205.178.190.26
   NS52.WORLDNIC.COM            206.188.198.26


Christopher Morrow wrote:
> not doubting the call-center thing, but:
>
> ;; ANSWER SECTION:
> kaiserpermanente.com.   86400   IN      NS      ea-dns14.kp.org.
> kaiserpermanente.com.   86400   IN      NS      ea-dns36.kp.org.
> kaiserpermanente.com.   86400   IN      NS      ea-dns25.kp.org.
>
> ;; ANSWER SECTION:
> kaiser.com.             7200    IN      NS      ns65.worldnic.com.
> kaiser.com.             7200    IN      NS      ns66.worldnic.com.
>
> Registrant:
> Kaiser Interests
>     338 Clayton St
>     #10
>     Denver, CO 80220
>     US
>
>     Domain Name: KAISER.COM
>
>     ------------------------------------------------------------------------
>     Promote your business to millions of viewers for only $1 a month
>     Learn how you can get an Enhanced Business Listing here for your domain name.
>     Learn more at http://www.NetworkSolutions.com/
>     ------------------------------------------------------------------------
>
>     Administrative Contact:
>     Kaiser, Hal          kaiser at KAISER.COM
>     435 CLAYTON ST
>     DENVER, CO 80206-4230
>     US
>
> sure that's the kaiser you're looking for?
>
> On Tue, Oct 22, 2013 at 1:26 PM, Steve Noble<snoble at sonn.com>  wrote:
>> I noticed Kaiser uses them, sites not resolving.. This should be a fun day
>> for call centers :(
>>
>>
>> Robert Glover wrote:
>>> On 10/22/2013 9:59 AM, Mark Keymer wrote:
>>>> Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?
>>>
>>> Yes.  We started getting calls from customers with domains using
>>> *.worldnic.com (i.e. Network Solutions) in the last 15 minutes or so.
>>>
>>> -Bobby
>>>


From morrowc.lists at gmail.com  Tue Oct 22 17:59:36 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 22 Oct 2013 13:59:36 -0400
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <5266B9BB.7080908@sonn.com>
References: <5266AEDB.3070104@viviotech.net> <5266B373.6010001@garlic.com>
 <5266B554.7040803@sonn.com>
 <CAL9jLaawWtKb09jWpzecz5eFYKC38Ws176v6hXXghKXeD6LAew@mail.gmail.com>
 <5266B9BB.7080908@sonn.com>
Message-ID: <CAL9jLaYuGafWD2LhL2df9h5D43wxSX+uL8vP8hdA-xB7JmetwA@mail.gmail.com>

On Tue, Oct 22, 2013 at 1:45 PM, Steve Noble <snoble at sonn.com> wrote:
> It's at least permanente.net which they use for some of their sites:
>
> http://kp.org/mydoctor/denisearvay redirects to permanente.net
>

super awesome! why not use the infra they have for kp.org one wonders?
controlling your own destiny... over rated, they say.

> Oops! Google Chrome could not find www.permanente.net
>
>   Administrative Contact, Technical Contact:
>   Sadayappan, Prince            prince.i.sadayappan at kp.org
>   Kaiser Permanente
>   1800 Harrison st
>   Oakland, CA 94612
>   US
>   510-625-6996
>
>
>   Record expires on 12-Nov-2017.
>   Record created on 12-Nov-1999.
>   Database last updated on 22-Oct-2013 12:38:41 EDT.
>
>
>   Domain servers in listed order:
>
>   NS51.WORLDNIC.COM            205.178.190.26
>   NS52.WORLDNIC.COM            206.188.198.26
>
>
>
> Christopher Morrow wrote:
>>
>> not doubting the call-center thing, but:
>>
>> ;; ANSWER SECTION:
>> kaiserpermanente.com.   86400   IN      NS      ea-dns14.kp.org.
>> kaiserpermanente.com.   86400   IN      NS      ea-dns36.kp.org.
>> kaiserpermanente.com.   86400   IN      NS      ea-dns25.kp.org.
>>
>> ;; ANSWER SECTION:
>> kaiser.com.             7200    IN      NS      ns65.worldnic.com.
>> kaiser.com.             7200    IN      NS      ns66.worldnic.com.
>>
>> Registrant:
>> Kaiser Interests
>>     338 Clayton St
>>     #10
>>     Denver, CO 80220
>>     US
>>
>>     Domain Name: KAISER.COM
>>
>>
>> ------------------------------------------------------------------------
>>     Promote your business to millions of viewers for only $1 a month
>>     Learn how you can get an Enhanced Business Listing here for your
>> domain name.
>>     Learn more at http://www.NetworkSolutions.com/
>>
>> ------------------------------------------------------------------------
>>
>>     Administrative Contact:
>>     Kaiser, Hal          kaiser at KAISER.COM
>>     435 CLAYTON ST
>>     DENVER, CO 80206-4230
>>     US
>>
>> sure that's the kaiser you're looking for?
>>
>> On Tue, Oct 22, 2013 at 1:26 PM, Steve Noble<snoble at sonn.com>  wrote:
>>>
>>> I noticed Kaiser uses them, sites not resolving.. This should be a fun
>>> day
>>> for call centers :(
>>>
>>>
>>> Robert Glover wrote:
>>>>
>>>> On 10/22/2013 9:59 AM, Mark Keymer wrote:
>>>>>
>>>>> Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?
>>>>
>>>>
>>>> Yes.  We started getting calls from customers with domains using
>>>> *.worldnic.com (i.e. Network Solutions) in the last 15 minutes or so.
>>>>
>>>> -Bobby
>>>>
>


From lostinmoscow at gmail.com  Tue Oct 22 18:15:09 2013
From: lostinmoscow at gmail.com (Quinn Kuzmich)
Date: Tue, 22 Oct 2013 12:15:09 -0600
Subject: Is there anyone from AOL messaging on here?
Message-ID: <CANGwj1wO6v-ERuNyfRmf2YuQNGf7smT=M-ridCgmuFPpMmi+jg@mail.gmail.com>

Please contact me off-list.  We've got a persistent spammer on your network
that we can't get shut down through normal channels.

Q

From blair.trosper at gmail.com  Tue Oct 22 19:16:12 2013
From: blair.trosper at gmail.com (Blair Trosper)
Date: Tue, 22 Oct 2013 14:16:12 -0500
Subject: ipv6 and geolocation
Message-ID: <CAA5Ek4f9JXTKaQUVhTz-2=x+mZX1x1rp_Tne=bv6Zqze_fLvPQ@mail.gmail.com>

Everyone loves IPv6, and it's a fantastic technology.  However, I've been
pondering a few quirks of v6, including the low priority of PTR, but I have
a question I want to throw out there:

Do you think IPv6 geolocatoin (GeoIP) will ever be viable?

If so, when do you think this will happen?  If not, what's the superseding
solution?  (The W3C location technology fails miserably for me 100% of the
time even on IPv4).

Two of the "big four" GeoIP providers don't even catalog IPv6, and the
other two's IPv6 database is unremarkable and usually only has the country.
 (Or, in my case, a block that's clearly in the United States is deemed as
simply "(somewhere in) Asia".)

What I'm getting at is:  IPv6 geolocation is presently rather hopeless and
useless.

Eager to hear thoughts from my fellow network thinkers!

- Blair

From jabley at hopcount.ca  Tue Oct 22 19:21:56 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Tue, 22 Oct 2013 15:21:56 -0400
Subject: ipv6 and geolocation
In-Reply-To: <CAA5Ek4f9JXTKaQUVhTz-2=x+mZX1x1rp_Tne=bv6Zqze_fLvPQ@mail.gmail.com>
References: <CAA5Ek4f9JXTKaQUVhTz-2=x+mZX1x1rp_Tne=bv6Zqze_fLvPQ@mail.gmail.com>
Message-ID: <DE626156-94DD-4E63-BADF-51655032D0EC@hopcount.ca>


On 2013-10-22, at 15:16, Blair Trosper <blair.trosper at gmail.com> wrote:

> Everyone loves IPv6, and it's a fantastic technology.  However, I've been
> pondering a few quirks of v6, including the low priority of PTR,

Not sure what that means, but...

> but I have a question I want to throw out there:
> 
> Do you think IPv6 geolocatoin (GeoIP) will ever be viable?

To me it seems like an easier problem to solve than IPv4. There's no historical assignment swamp. Subnets are of fixed size. Many/most organisations who receive a direct assignment will never need a second.

> If so, when do you think this will happen?

As soon as enough people using geo-located services start doing so over v6.


Joe



From I.Smith at F5.com  Tue Oct 22 20:00:48 2013
From: I.Smith at F5.com (Ian Smith)
Date: Tue, 22 Oct 2013 20:00:48 +0000
Subject: ipv6 and geolocation
In-Reply-To: <CAA5Ek4f9JXTKaQUVhTz-2=x+mZX1x1rp_Tne=bv6Zqze_fLvPQ@mail.gmail.com>
References: <CAA5Ek4f9JXTKaQUVhTz-2=x+mZX1x1rp_Tne=bv6Zqze_fLvPQ@mail.gmail.com>
Message-ID: <419417C345CA5F48BF45F0A23955A0634A709D30@SEAEMBX02.olympus.F5Net.com>

it seems like solving your first complaint is the same work as solving your second:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 1h IN  PTR host.example.com.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 1h IN  LOC 40 45 33 N 73 59 07 W 100m 



________________________________________
From: Blair Trosper [blair.trosper at gmail.com]
Sent: Tuesday, October 22, 2013 3:16 PM
To: nanog at nanog.org
Subject: ipv6 and geolocation

Everyone loves IPv6, and it's a fantastic technology.  However, I've been
pondering a few quirks of v6, including the low priority of PTR, but I have
a question I want to throw out there:

Do you think IPv6 geolocatoin (GeoIP) will ever be viable?

If so, when do you think this will happen?  If not, what's the superseding
solution?  (The W3C location technology fails miserably for me 100% of the
time even on IPv4).

Two of the "big four" GeoIP providers don't even catalog IPv6, and the
other two's IPv6 database is unremarkable and usually only has the country.
 (Or, in my case, a block that's clearly in the United States is deemed as
simply "(somewhere in) Asia".)

What I'm getting at is:  IPv6 geolocation is presently rather hopeless and
useless.

Eager to hear thoughts from my fellow network thinkers!

- Blair


From jeroen at massar.ch  Tue Oct 22 20:17:16 2013
From: jeroen at massar.ch (Jeroen Massar)
Date: Tue, 22 Oct 2013 22:17:16 +0200
Subject: ipv6 and geolocation
In-Reply-To: <CAA5Ek4f9JXTKaQUVhTz-2=x+mZX1x1rp_Tne=bv6Zqze_fLvPQ@mail.gmail.com>
References: <CAA5Ek4f9JXTKaQUVhTz-2=x+mZX1x1rp_Tne=bv6Zqze_fLvPQ@mail.gmail.com>
Message-ID: <5266DD4C.6030003@massar.ch>

On 2013-10-22 21:16, Blair Trosper wrote:
> Everyone loves IPv6, and it's a fantastic technology.  However, I've been
> pondering a few quirks of v6, including the low priority of PTR, but I have
> a question I want to throw out there:
> 
> Do you think IPv6 geolocatoin (GeoIP) will ever be viable?

Yes, in the same way as it happens for IPv4: customer types their
address into the database for a geo-provider when they type it in to get
stuff shipped out to them...

Most consumer/hard-line ISPs typically have their users in the same
country/region as they operate, hence geo-location up to city level will
be 'easy'.

For VPN providers or more specifically IPv6-tunnel providers that is not
the case, the user might be in a completely different country than the
PoP is, or where the address space for that PoP comes from.

As such, for SixXS we are using the "Self-published IP Geolocation Data"
specification as defined in this draft by Google folks:
 http://tools.ietf.org/html/draft-google-self-published-geofeeds-02

This resolves this problem for us. More details about this and where to
find the feed etc can be found at:
  http://www.sixxs.net/faq/misc/?faq=geolocation

As mentioned there, as a content-provider, please use that data, and if
you want do also please send a notification so that we can either list
you on the above page and/or at least notify you in case things change.

Note that most VPN providers actually are more 'geo-location changers'
and thus likely will not want to do this, or will want to "lie" in their
data, for them I don't think that providers will be accepting their feeds.

> What I'm getting at is:  IPv6 geolocation is presently rather hopeless and
> useless.

One very simple approach is to take RIR data, you then end up with a
reasonably accurate location, unless, like in the above detail the
traffic actually is tunneled from somewhere else.

If wanted I can make a geo-feed available containing the data from GRH,
as that has all these little details already anyway. If somebody finds
it useful, give a yell, and I'll kick the system to produce one
(separately from the SixXS specific prefixes of course, thus under a
different URL).

Greets,
 Jeroen



From blair.trosper at gmail.com  Wed Oct 23 02:54:54 2013
From: blair.trosper at gmail.com (Blair Trosper)
Date: Tue, 22 Oct 2013 21:54:54 -0500
Subject: ipv6 and geolocation
In-Reply-To: <DE626156-94DD-4E63-BADF-51655032D0EC@hopcount.ca>
References: <CAA5Ek4f9JXTKaQUVhTz-2=x+mZX1x1rp_Tne=bv6Zqze_fLvPQ@mail.gmail.com>
 <DE626156-94DD-4E63-BADF-51655032D0EC@hopcount.ca>
Message-ID: <CAA5Ek4fFXaq5n1d2q8WQjGu-+yEdDbwHZ9aSotBWT8oYR72H2A@mail.gmail.com>

I meant that PTR isn't a priority for ISPs.  A la Comcast's rollout of IPv6
lacks PTR, as does Google in general for v4 and v6 (even though they have
it internally).


On Tue, Oct 22, 2013 at 2:21 PM, Joe Abley <jabley at hopcount.ca> wrote:

>
> On 2013-10-22, at 15:16, Blair Trosper <blair.trosper at gmail.com> wrote:
>
> > Everyone loves IPv6, and it's a fantastic technology.  However, I've been
> > pondering a few quirks of v6, including the low priority of PTR,
>
> Not sure what that means, but...
>
> > but I have a question I want to throw out there:
> >
> > Do you think IPv6 geolocatoin (GeoIP) will ever be viable?
>
> To me it seems like an easier problem to solve than IPv4. There's no
> historical assignment swamp. Subnets are of fixed size. Many/most
> organisations who receive a direct assignment will never need a second.
>
> > If so, when do you think this will happen?
>
> As soon as enough people using geo-located services start doing so over v6.
>
>
> Joe
>
>

From blhack at gmail.com  Tue Oct 22 17:13:43 2013
From: blhack at gmail.com (Ryan Mcdermott)
Date: Tue, 22 Oct 2013 10:13:43 -0700
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <CAKnNFz-ZJWf6QuxUfWjzAW0awjATMJCtTcSWhHMP2rdM78F1bg@mail.gmail.com>
References: <5266AEDB.3070104@viviotech.net>
 <CAKnNFz-ZJWf6QuxUfWjzAW0awjATMJCtTcSWhHMP2rdM78F1bg@mail.gmail.com>
Message-ID: <CAB7v+BL4v+aROMDDsu-+SL0wsd=nvdYF7Rhw=aOx_fWLXrvKeg@mail.gmail.com>

You can watch the trainwreck on twitter if you want to:
https://twitter.com/search?q=Network%20Solutions&src=typd


On Tue, Oct 22, 2013 at 10:00 AM, chris <tknchris at gmail.com> wrote:

> Yes I am seeing this also, getting calls from many clients that cant
> resolve domains with netsol dns
>
> chris
>
>
> On Tue, Oct 22, 2013 at 12:59 PM, Mark Keymer <mark at viviotech.net> wrote:
>
> > Hi,
> >
> > Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?
> >
> > Sincerely,
> >
> > --
> > Mark Keymer
> >
> >
> >
>

From blhack at gmail.com  Tue Oct 22 17:14:26 2013
From: blhack at gmail.com (Ryan Mcdermott)
Date: Tue, 22 Oct 2013 10:14:26 -0700
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <5266B172.7020805@gmail.com>
References: <5266AEDB.3070104@viviotech.net>
	<5266B172.7020805@gmail.com>
Message-ID: <CAB7v+BLTDdE8DDYQh5LqVQ5wtepftgAoYubrmUP1fryDPYG46Q@mail.gmail.com>

Recommend alternatives?


On Tue, Oct 22, 2013 at 10:10 AM, Roy <r.engehausen at gmail.com> wrote:

> On 10/22/2013 9:59 AM, Mark Keymer wrote:
>
>> Hi,
>>
>> Anyone else seeing resolving issues on WORLDNIC.COM DNS servers?
>>
>> Sincerely,
>>
>>
> Yep.  One of my clients domains seems to be gone.
>
>

From furry13 at gmail.com  Wed Oct 23 11:57:44 2013
From: furry13 at gmail.com (Jen Linkova)
Date: Wed, 23 Oct 2013 13:57:44 +0200
Subject: ipv6 and geolocation
In-Reply-To: <CAA5Ek4f9JXTKaQUVhTz-2=x+mZX1x1rp_Tne=bv6Zqze_fLvPQ@mail.gmail.com>
References: <CAA5Ek4f9JXTKaQUVhTz-2=x+mZX1x1rp_Tne=bv6Zqze_fLvPQ@mail.gmail.com>
Message-ID: <CAFU7BAQn-7b7MNPzvK3vWms-OTFf683bDGq9vnLveBfiTpRTbg@mail.gmail.com>

On Tue, Oct 22, 2013 at 9:16 PM, Blair Trosper <blair.trosper at gmail.com> wrote:
> Everyone loves IPv6, and it's a fantastic technology.  However, I've been
> pondering a few quirks of v6, including the low priority of PTR, but I have
> a question I want to throw out there:
>
> Do you think IPv6 geolocatoin (GeoIP) will ever be viable?


You might find this interesting:

https://ripe67.ripe.net/presentations/324-self-published-geo_RIPE67.pdf
http://tools.ietf.org/html/draft-google-self-published-geofeeds-02


From morrowc.lists at gmail.com  Wed Oct 23 13:40:57 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 23 Oct 2013 09:40:57 -0400
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
In-Reply-To: <CAB7v+BLTDdE8DDYQh5LqVQ5wtepftgAoYubrmUP1fryDPYG46Q@mail.gmail.com>
References: <5266AEDB.3070104@viviotech.net> <5266B172.7020805@gmail.com>
 <CAB7v+BLTDdE8DDYQh5LqVQ5wtepftgAoYubrmUP1fryDPYG46Q@mail.gmail.com>
Message-ID: <CAL9jLabSYkOaFiabV2NXBM+Zmam30gLTW28N16YT8xx_9YJeGQ@mail.gmail.com>

On Tue, Oct 22, 2013 at 1:14 PM, Ryan Mcdermott <blhack at gmail.com> wrote:
> Recommend alternatives?
>

plug for dyn .. http://dyn.com/dns/


From jstuxuhu0816 at gmail.com  Wed Oct 23 14:00:54 2013
From: jstuxuhu0816 at gmail.com (=?utf-8?B?anN0dXh1aHUwODE2?=)
Date: Wed, 23 Oct 2013 22:00:54 +0800
Subject: 80 Gbps ?
Message-ID: <tencent_BD853525208FA1EF605422C8@qq.com>


From james at freedomnet.co.nz  Wed Oct 23 14:28:15 2013
From: james at freedomnet.co.nz (james jones)
Date: Wed, 23 Oct 2013 10:28:15 -0400
Subject: MassHack and A chance to teach.
Message-ID: <CALcVfM1xp2WPJJZNh9b+Vjw6a97NVZrx805w4xzqPJnyRefUqQ@mail.gmail.com>

Hey everyone,

I am putting on a hackathon on Jan 30 - Feb 1 at the Hynes Convention
Center in Boston, MA. The basic idea is you have 48 hours to create
something cool and don't suck! We have 3 categories:

1. General Tech and Web Services
2. Cameras and Wearables
3. Healthcare


We will be giving an investment prize away to the winners and running them
through a 12 week accelerator program to launch their idea into a startup.
We are also going to have technology classes. I am looking for people
willing to do any sort of programming or networking classes. These will be
more of beginner/into classes. If any of you are willing to come and help I
can promise good beer, good food and good times. Sorry we can not cover
travel or lodging.

Also if you know anyone that might want to come and take part give them the
discount code: *NANOG*

It will give them 50% off their ticket.


Check out our website: http://masshack.com

Hope to see some of you there.


P.S. We are still looking for sponsors and exhibitors :)


-James

From bmeshier at amherst.com  Wed Oct 23 15:08:05 2013
From: bmeshier at amherst.com (Meshier, Brent)
Date: Wed, 23 Oct 2013 15:08:05 +0000
Subject: Possible DNS issues at Networksolutions aka WORLDNIC.COM?
Message-ID: <68C2CBC977F3E04799DF9C76E938E70908215401@DFEXCH1.asglp.com>

Three DNS providers I trust:

http://www.neustar.biz/enterprise/dns-services

http://www.verisigninc.com/en_US/products-and-services/network-intelligence-availability/managed-dns/index.xhtml

http://www.akamai.com/html/solutions/enhanced_dns.html


-----Original Message-----
From: Christopher Morrow [mailto:morrowc.lists at gmail.com]
Sent: Wednesday, October 23, 2013 8:41 AM
To: Ryan Mcdermott
Cc: North American Network Operators' Group
Subject: Re: Possible DNS issues at Networksolutions aka WORLDNIC.COM?

On Tue, Oct 22, 2013 at 1:14 PM, Ryan Mcdermott <blhack at gmail.com> wrote:
> Recommend alternatives?
>



--- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication.



From noc at phibee.net  Wed Oct 23 15:11:31 2013
From: noc at phibee.net (Phibee Network Operation Center)
Date: Wed, 23 Oct 2013 17:11:31 +0200
Subject: Point to Point Ethernet request
Message-ID: <5267E723.6070500@phibee.net>

Hello,

Looking for a solution to connect two sitesto my POP:

Site A:
     Frederick, MD 21701
     USA

Site B:
     Archbold, OH 43502
     USA


My POP:
     New York (into a DC: Equinix or Telehouse New York)

A Layer 2 connection at 4, 6 or 10 Mbits

Any one know a good operator for this ?

Best Regards
Jerome SCHEVINGT



From bzs at world.std.com  Wed Oct 23 17:23:40 2013
From: bzs at world.std.com (Barry Shein)
Date: Wed, 23 Oct 2013 13:23:40 -0400
Subject: Point to Point Ethernet request
In-Reply-To: <5267E723.6070500@phibee.net>
References: <5267E723.6070500@phibee.net>
Message-ID: <21096.1564.769532.499928@world.std.com>


Related, maybe:

Has anyone actually seen Comcast's "ethernet" service? This is
advertised as a symmetrical, high-speed (100mb+?) business service not
consumer stuff.

I called several times out of curiosity. Using the phone number for
this service on their website got me switched around several times by
people who seemed to barely know what I was talking about.

One wanted to engage me in a debate about why asymmetrical 20/7
(whatever it was) isn't good enough I assume because that's all she
was involved with so I muttered something about routing net blocks etc
so she gave up and switched me again. Fine.

Then I'd finally get someone who seemed reasonable, seemed to know
what I was asking about, took down my call back info and promised
someone would get back to me within one business day.

Never got a callback. Tried this a few times, same result.

So, does it exist?

I suppose if sales won't call you back you have to wonder what support
would be like.

P.S. Their website for this service invites you to enter your address
to see if it's available and assures me it is, that's where you get
the phone number to call sales.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From nospam-nanog at jensenresearch.com  Thu Oct 24 02:40:34 2013
From: nospam-nanog at jensenresearch.com (JRC NOC)
Date: Wed, 23 Oct 2013 22:40:34 -0400
Subject: BGP failure analysis and recommendations
Message-ID: <5.1.0.14.0.20131023214304.0396ead0@authsmtp.jensenresearch.com>

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://online.wsj.com/news/articles/SB10001424052702304864504579145813698584246
>>>
>>>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 morrowc.lists at gmail.com  Thu Oct 24 03:06:07 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 23 Oct 2013 23:06:07 -0400
Subject: BGP failure analysis and recommendations
In-Reply-To: <5.1.0.14.0.20131023214304.0396ead0@authsmtp.jensenresearch.com>
References: <5.1.0.14.0.20131023214304.0396ead0@authsmtp.jensenresearch.com>
Message-ID: <CAL9jLabBf7wMm+xx9EyeK-uhyTgce+22HBwve3T37eFDFaKCmg@mail.gmail.com>

On Wed, Oct 23, 2013 at 10:40 PM, JRC NOC
<nospam-nanog at jensenresearch.com> wrote:
> Is this just an unavoidable issue with scaling large networks?

nope... sounds like (to me at least) the forwarding plane and control
plane are non-congruent in your provider's network :( so as you said,
if the forwarding-plane is dorked up between you and 'the rest of
their netowrk', but the edge device you are connected to thinks
next-hops for routes are still valid... oops :(

> Is it perhaps a known side effect of MPLS?

nope.

> 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?

sadly I bet not, aside from active probing and disabling paths that
are non-functional.


From cjc+nanog at pumpky.net  Thu Oct 24 06:12:54 2013
From: cjc+nanog at pumpky.net (Crist Clark)
Date: Wed, 23 Oct 2013 23:12:54 -0700
Subject: Point to Point Ethernet request
In-Reply-To: <21096.1564.769532.499928@world.std.com>
References: <5267E723.6070500@phibee.net>
 <21096.1564.769532.499928@world.std.com>
Message-ID: <CAAcrURL9EoZ6LdAqG9k7TjZFhgyBTPosA=n5N_Pav=GnhmWzYw@mail.gmail.com>

Got 10 GbE service from a data center in Santa Clara to a campus in San
Mateo California from Comcast. Been pretty solid. Only blips have been
anounced maintenance. When I have contacted support, I really can't
complain.

It's L2. I see my BPDUs and LLDPDUs come through.

So, yeah, it exists.

Related, maybe:

Has anyone actually seen Comcast's "ethernet" service? This is
advertised as a symmetrical, high-speed (100mb+?) business service not
consumer stuff.

I called several times out of curiosity. Using the phone number for
this service on their website got me switched around several times by
people who seemed to barely know what I was talking about.

One wanted to engage me in a debate about why asymmetrical 20/7
(whatever it was) isn't good enough I assume because that's all she
was involved with so I muttered something about routing net blocks etc
so she gave up and switched me again. Fine.

Then I'd finally get someone who seemed reasonable, seemed to know
what I was asking about, took down my call back info and promised
someone would get back to me within one business day.

Never got a callback. Tried this a few times, same result.

So, does it exist?

I suppose if sales won't call you back you have to wonder what support
would be like.

P.S. Their website for this service invites you to enter your address
to see if it's available and assures me it is, that's where you get
the phone number to call sales.

--
        -Barry Shein

The World              | bzs at TheWorld.com           |
http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR,
Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*

From j at 2600hz.com  Thu Oct 24 06:27:44 2013
From: j at 2600hz.com (Joshua Goldbard)
Date: Thu, 24 Oct 2013 06:27:44 +0000
Subject: Point to Point Ethernet request
In-Reply-To: <CAAcrURL9EoZ6LdAqG9k7TjZFhgyBTPosA=n5N_Pav=GnhmWzYw@mail.gmail.com>
References: <5267E723.6070500@phibee.net>
 <21096.1564.769532.499928@world.std.com>,
 <CAAcrURL9EoZ6LdAqG9k7TjZFhgyBTPosA=n5N_Pav=GnhmWzYw@mail.gmail.com>
Message-ID: <1684B241-03DC-4C81-A311-FE4E919C40A7@2600hz.com>

Buzz me offline and I'll connect you to them. I used to work there.

Cheers,
Joshua

Sent from my iPad

> On Oct 23, 2013, at 11:13 PM, "Crist Clark" <cjc+nanog at pumpky.net> wrote:
> 
> Got 10 GbE service from a data center in Santa Clara to a campus in San
> Mateo California from Comcast. Been pretty solid. Only blips have been
> anounced maintenance. When I have contacted support, I really can't
> complain.
> 
> It's L2. I see my BPDUs and LLDPDUs come through.
> 
> So, yeah, it exists.
> 
> Related, maybe:
> 
> Has anyone actually seen Comcast's "ethernet" service? This is
> advertised as a symmetrical, high-speed (100mb+?) business service not
> consumer stuff.
> 
> I called several times out of curiosity. Using the phone number for
> this service on their website got me switched around several times by
> people who seemed to barely know what I was talking about.
> 
> One wanted to engage me in a debate about why asymmetrical 20/7
> (whatever it was) isn't good enough I assume because that's all she
> was involved with so I muttered something about routing net blocks etc
> so she gave up and switched me again. Fine.
> 
> Then I'd finally get someone who seemed reasonable, seemed to know
> what I was asking about, took down my call back info and promised
> someone would get back to me within one business day.
> 
> Never got a callback. Tried this a few times, same result.
> 
> So, does it exist?
> 
> I suppose if sales won't call you back you have to wonder what support
> would be like.
> 
> P.S. Their website for this service invites you to enter your address
> to see if it's available and assures me it is, that's where you get
> the phone number to call sales.
> 
> --
>        -Barry Shein
> 
> The World              | bzs at TheWorld.com           |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR,
> Canada
> Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From blueneon at gmail.com  Thu Oct 24 06:38:07 2013
From: blueneon at gmail.com (Tom Morris)
Date: Thu, 24 Oct 2013 02:38:07 -0400
Subject: Point to Point Ethernet request
In-Reply-To: <CAAcrURL9EoZ6LdAqG9k7TjZFhgyBTPosA=n5N_Pav=GnhmWzYw@mail.gmail.com>
References: <5267E723.6070500@phibee.net>
 <21096.1564.769532.499928@world.std.com>
 <CAAcrURL9EoZ6LdAqG9k7TjZFhgyBTPosA=n5N_Pav=GnhmWzYw@mail.gmail.com>
Message-ID: <CAEZ7Lt0xmDn9ABNxn9t3bhEbHAej5MZkUr2ia8nHoi07GmHvWA@mail.gmail.com>

Do they offer an SLA on that? I've got a couple of broadcast sites that
could use a 21st century studio to transmitter link... Bandwidth wouldn't
be that spicy (just FM stereo here) but reliability is a must!! An at&t t1
is even starting to drive us nuts by having seconds long dropouts in the
afternoons.

Tom Morris, Operations Manager, WDNA-FM

This message sent from a mobile device. Silly typos provided free of charge.
On Oct 24, 2013 2:14 AM, "Crist Clark" <cjc+nanog at pumpky.net> wrote:

> Got 10 GbE service from a data center in Santa Clara to a campus in San
> Mateo California from Comcast. Been pretty solid. Only blips have been
> anounced maintenance. When I have contacted support, I really can't
> complain.
>
> It's L2. I see my BPDUs and LLDPDUs come through.
>
> So, yeah, it exists.
>
> Related, maybe:
>
> Has anyone actually seen Comcast's "ethernet" service? This is
> advertised as a symmetrical, high-speed (100mb+?) business service not
> consumer stuff.
>
> I called several times out of curiosity. Using the phone number for
> this service on their website got me switched around several times by
> people who seemed to barely know what I was talking about.
>
> One wanted to engage me in a debate about why asymmetrical 20/7
> (whatever it was) isn't good enough I assume because that's all she
> was involved with so I muttered something about routing net blocks etc
> so she gave up and switched me again. Fine.
>
> Then I'd finally get someone who seemed reasonable, seemed to know
> what I was asking about, took down my call back info and promised
> someone would get back to me within one business day.
>
> Never got a callback. Tried this a few times, same result.
>
> So, does it exist?
>
> I suppose if sales won't call you back you have to wonder what support
> would be like.
>
> P.S. Their website for this service invites you to enter your address
> to see if it's available and assures me it is, that's where you get
> the phone number to call sales.
>
> --
>         -Barry Shein
>
> The World              | bzs at TheWorld.com           |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR,
> Canada
> Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*
>

From bross at pobox.com  Thu Oct 24 07:07:04 2013
From: bross at pobox.com (Brandon Ross)
Date: Thu, 24 Oct 2013 03:07:04 -0400 (EDT)
Subject: BGP failure analysis and recommendations
In-Reply-To: <CAL9jLabBf7wMm+xx9EyeK-uhyTgce+22HBwve3T37eFDFaKCmg@mail.gmail.com>
References: <5.1.0.14.0.20131023214304.0396ead0@authsmtp.jensenresearch.com>
 <CAL9jLabBf7wMm+xx9EyeK-uhyTgce+22HBwve3T37eFDFaKCmg@mail.gmail.com>
Message-ID: <alpine.OSX.2.02.1310240257380.624@brugal.local>

On Wed, 23 Oct 2013, Christopher Morrow wrote:

> On Wed, Oct 23, 2013 at 10:40 PM, JRC NOC
> <nospam-nanog at jensenresearch.com> wrote:
>
>> 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?
>
> sadly I bet not, aside from active probing and disabling paths that
> are non-functional.

Um, how about, don't buy services from network providers that fail in this 
way?

Since we're not naming names, I won't, but in the past there's been at 
least one provider that used multi-hop eBGP at their edges because they 
didn't want to invest in edge gear that could handle a full BGP table.  My 
concern with their network (beyond many other concerns) was that when that 
router in the middle had a soft failure, how would BGP know to route 
around it?  Answer: it wouldn't, you'd black hole.

On the opposite side of the spectrum, there was at least one provider that 
used custom software to actively probe their upstream providers and route 
around poor performance.  At one time, there was also software, hardware 
and services that you could install/run on your own network to try to 
detect these things as well, however I'm not sure how many of them are 
still on the market.

The bottom line, however, is don't buy services from companies that do a 
poor job of running their network unless you can accept these kinds of 
failures.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
Schedule a meeting:  https://doodle.com/bross            Skype:  brandonross


From rdobbins at arbor.net  Thu Oct 24 10:44:38 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Thu, 24 Oct 2013 10:44:38 +0000
Subject: 80 Gbps ?
In-Reply-To: <tencent_BD853525208FA1EF605422C8@qq.com>
References: <tencent_BD853525208FA1EF605422C8@qq.com>
Message-ID: <E2206D60-B675-497E-9BF4-123A3DCE76FE@arbor.net>


On Oct 23, 2013, at 9:00 PM, jstuxuhu0816 <jstuxuhu0816 at gmail.com> wrote:

> Basically, what you can do for the ISP network to pretect the DDOS attacks:

<https://app.box.com/s/4h2l6f4m8is6jnwk28cg>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From me at anuragbhatia.com  Thu Oct 24 10:47:44 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 24 Oct 2013 16:17:44 +0530
Subject: Fundamental questions of backbone design
In-Reply-To: <15023.1382132808@turing-police.cc.vt.edu>
References: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
 <15023.1382132808@turing-police.cc.vt.edu>
Message-ID: <CAJ0+aXbqL71jVgjoG0J_ZviWOo2+=EM8CxThW-ogEkwgGKH=Sg@mail.gmail.com>

Hi Valdis


Checkout routing table at NIXI and you will get idea what I am referring to
w.r.t. prepended routes.

http://www.nixi.in/lookingglass.php



Thanks!


On Sat, Oct 19, 2013 at 3:16 AM, <Valdis.Kletnieks at vt.edu> wrote:

> On Fri, 18 Oct 2013 23:33:16 +0530, Anurag Bhatia said:
>
> >    localpref to customer routes then peering and finally transit. Does
> this
> >    works well or you see issues with people who have 10+ prepends on some
> >    peering routes calling you to not send traffic via those circuits?
>
> OK. I admit being perplexed.  Under what conditions will somebody have that
> many prepends and you *still* end up routing via that path if you have
> another path available?
>
> I guess if they were silly and prepended themselves 10 times and then
> announced the result to the upstreams of *both* paths you have available...
>



-- 


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 Oct 24 10:49:30 2013
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 24 Oct 2013 16:19:30 +0530
Subject: Fundamental questions of backbone design
In-Reply-To: <CAEmG1=qT8dGqqD84gAwOvvbzTW+AgiK36CFdUw=EPMQ_rzO4mg@mail.gmail.com>
References: <CAJ0+aXbB3b-hBKA0oUyRedTAbcO8MWPtn+=kk8GEsZFO544HKg@mail.gmail.com>
 <15023.1382132808@turing-police.cc.vt.edu>
 <CAEmG1=qT8dGqqD84gAwOvvbzTW+AgiK36CFdUw=EPMQ_rzO4mg@mail.gmail.com>
Message-ID: <CAJ0+aXZgrB81ggKdoojWkYxSQFUG7SVci1Yi3KV-RjYJvNB+OA@mail.gmail.com>

Hi Matthew


Very cool!


That is exactly I was looking for. I was uncomfortable in using 10+ prepend
routes while ofcourse interested in tweaking localpref as everyone done
based on peers & their status (transit/downstream/peering) etc.





Thanks.


On Sun, Oct 20, 2013 at 1:13 AM, Matthew Petach <mpetach at netflight.com>wrote:

> On Fri, Oct 18, 2013 at 2:46 PM, <Valdis.Kletnieks at vt.edu> wrote:
>
> > On Fri, 18 Oct 2013 23:33:16 +0530, Anurag Bhatia said:
> >
> > >    localpref to customer routes then peering and finally transit. Does
> > this
> > >    works well or you see issues with people who have 10+ prepends on
> some
> > >    peering routes calling you to not send traffic via those circuits?
> >
> > OK. I admit being perplexed.  Under what conditions will somebody have
> that
> > many prepends and you *still* end up routing via that path if you have
> > another path available?
> >
> > I guess if they were silly and prepended themselves 10 times and then
> > announced the result to the upstreams of *both* paths you have
> available...
> >
>
>
> Uh...this actually happens a fair amount, to the
> point that I have a standard "less-than-X-AS-PATH"
> restriction in my localpref adjustments to explicitly
> prevent it.
>
> Think about it; if network A prepends 10x to network B,
> and not at all to network C; but network B is a free peer
> of mine, and network C is a transit network I pay money
> to; following the typical convention of "routes learned
> from network B get localpref'd to 5000, routes learned
> from transit are localpref'd at 1000", you'd end up
> pushing the traffic along the 10x prepended pathway.
>
> If you're a network with low splay, it's less likely, as
> the more intervening networks there are in the mix,
> the less likely the long path is to propagate to you;
> but if you're a high-splay network, there's a really
> good chance you're going to see both the long path
> and the short path across different categories of
> links, with different localpref assignments.
>
> A good approach to preventing that is to look
> at a histogram of AS-PATH lengths in your
> network, and establish a cutoff point, generally
> around your 95th percentile; path lenths less
> than that are "real" paths, above that are
> "backup, non-preferred" paths, and then
> use that cutoff in your policy arsenal:
>
> replace:
>  as-path 1-OR-LESS ".{0,1}";
> replace:
>  as-path 2-OR-LESS ".{0,2}";
> replace:
>  as-path 3-OR-LESS ".{0,3}";
> replace:
>  as-path 4-OR-LESS ".{0,4}";
> replace:
>  as-path 5-OR-LESS ".{0,5}";
> replace:
>  as-path 6-OR-LESS ".{0,6}";
> replace:
>  as-path 7-OR-LESS ".{0,7}";
> replace:
>  as-path 8-OR-LESS ".{0,8}";
> replace:
>  as-path 200-OR-MORE ".{200,}";
>
> replace:
> policy-statement SET-FREE-PEER {
>     term AS-DEPTH-5-OR-LESS {
>         from as-path 5-OR-LESS;
>         then {
>             community add C-Y-FREE-PEER;
>             local-preference 2600;
>             accept;
>         }
>     }
>     term AS-DEPTH-LONGER-THAN-5 {
>         then {
>             community add C-Y-FREE-PEER;
>             local-preference 100;
>             accept;
>         }
>     }
>     /* we will never get here, but put for readability/futureproofing */
>     then reject;
> }
>
> (pre-defining a range of potential AS-PATH lengths
> in your policy description tree makes it easier to
> adjust up or down, as your splay factor increases
> or decreases over time.)
>
> And no, you can't quite paste this exactly into your
> router directly, but it should give you an idea of
> how you might control the impact long AS-PATHs
> have on your routing tables.
>
> Matt
>



-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

From sroche at lakelandnetworks.com  Thu Oct 24 12:10:23 2013
From: sroche at lakelandnetworks.com (Sam Roche)
Date: Thu, 24 Oct 2013 08:10:23 -0400
Subject: BGP failure analysis and recommendations
In-Reply-To: <CAL9jLabBf7wMm+xx9EyeK-uhyTgce+22HBwve3T37eFDFaKCmg@mail.gmail.com>
References: <5.1.0.14.0.20131023214304.0396ead0@authsmtp.jensenresearch.com>
 <CAL9jLabBf7wMm+xx9EyeK-uhyTgce+22HBwve3T37eFDFaKCmg@mail.gmail.com>
Message-ID: <50DE6F70588444499E383C5102155B890179A05F@energyops.lakelandenergy.local>

We had a similar issue happen and modified our BGP peering to use one BGP session per provider, as we had multiple neighbours for one of our peers. 

It seems to have resolved this particular issue for us.

I would love to hear how others are actively probing their peers networks using an NMS to verify connectivity.


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: Christopher Morrow [mailto:morrowc.lists at gmail.com] 
Sent: October-23-13 11:06 PM
To: JRC NOC
Cc: nanog list
Subject: Re: BGP failure analysis and recommendations

On Wed, Oct 23, 2013 at 10:40 PM, JRC NOC <nospam-nanog at jensenresearch.com> wrote:
> Is this just an unavoidable issue with scaling large networks?

nope... sounds like (to me at least) the forwarding plane and control plane are non-congruent in your provider's network :( so as you said, if the forwarding-plane is dorked up between you and 'the rest of their netowrk', but the edge device you are connected to thinks next-hops for routes are still valid... oops :(

> Is it perhaps a known side effect of MPLS?

nope.

> 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?

sadly I bet not, aside from active probing and disabling paths that are non-functional.



From morrowc.lists at gmail.com  Thu Oct 24 13:21:14 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 24 Oct 2013 09:21:14 -0400
Subject: BGP failure analysis and recommendations
In-Reply-To: <alpine.OSX.2.02.1310240257380.624@brugal.local>
References: <5.1.0.14.0.20131023214304.0396ead0@authsmtp.jensenresearch.com>
 <CAL9jLabBf7wMm+xx9EyeK-uhyTgce+22HBwve3T37eFDFaKCmg@mail.gmail.com>
 <alpine.OSX.2.02.1310240257380.624@brugal.local>
Message-ID: <CAL9jLabrAa=i50mxfM9wBDW_q=mdpaSu0t2oSm9U87ACwXi9tw@mail.gmail.com>

On Thu, Oct 24, 2013 at 3:07 AM, Brandon Ross <bross at pobox.com> wrote:
> On Wed, 23 Oct 2013, Christopher Morrow wrote:
>
>> On Wed, Oct 23, 2013 at 10:40 PM, JRC NOC
>> <nospam-nanog at jensenresearch.com> wrote:
>>
>>> 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?
>>
>>
>> sadly I bet not, aside from active probing and disabling paths that
>> are non-functional.
>
>
> Um, how about, don't buy services from network providers that fail in this
> way?
>

I suppose the question is: "how would you know that any particular
network had this failure mode?"

until, of course, you run into it... as jrc did...


From tony at swalter.com  Thu Oct 24 14:19:49 2013
From: tony at swalter.com (Tony Patti)
Date: Thu, 24 Oct 2013 10:19:49 -0400
Subject: Point to Point Ethernet request
In-Reply-To: <CAEZ7Lt0xmDn9ABNxn9t3bhEbHAej5MZkUr2ia8nHoi07GmHvWA@mail.gmail.com>
References: <5267E723.6070500@phibee.net>
 <21096.1564.769532.499928@world.std.com>
 <CAAcrURL9EoZ6LdAqG9k7TjZFhgyBTPosA=n5N_Pav=GnhmWzYw@mail.gmail.com>
 <CAEZ7Lt0xmDn9ABNxn9t3bhEbHAej5MZkUr2ia8nHoi07GmHvWA@mail.gmail.com>
Message-ID: <0d3f01ced0c4$195659e0$4c030da0$@swalter.com>

Hi Tom,

Yes Comcast has SLA for their Enterprise Services, see page 5 (Schedule A-2)
of
http://business.comcast.com/docs/ent-terms-and-conditions/Product-Specific-A
ttachment-Ethernet-Dedicated-Internet-120412-PUBLISHED-v3.pdf?sfvrsn=0

Tony Patti
CIO
S. Walter Packaging Corp.


-----Original Message-----
From: Tom Morris [mailto:blueneon at gmail.com] 
Sent: Thursday, October 24, 2013 2:38 AM
To: NANOG list
Subject: Re: Point to Point Ethernet request

Do they offer an SLA on that? I've got a couple of broadcast sites that
could use a 21st century studio to transmitter link... Bandwidth wouldn't be
that spicy (just FM stereo here) but reliability is a must!! An at&t t1 is
even starting to drive us nuts by having seconds long dropouts in the
afternoons.

Tom Morris, Operations Manager, WDNA-FM

This message sent from a mobile device. Silly typos provided free of charge.
On Oct 24, 2013 2:14 AM, "Crist Clark" <cjc+nanog at pumpky.net> wrote:

> Got 10 GbE service from a data center in Santa Clara to a campus in 
> San Mateo California from Comcast. Been pretty solid. Only blips have 
> been anounced maintenance. When I have contacted support, I really 
> can't complain.
>
> It's L2. I see my BPDUs and LLDPDUs come through.
>
> So, yeah, it exists.
>
> Related, maybe:
>
> Has anyone actually seen Comcast's "ethernet" service? This is 
> advertised as a symmetrical, high-speed (100mb+?) business service not 
> consumer stuff.
>
> I called several times out of curiosity. Using the phone number for 
> this service on their website got me switched around several times by 
> people who seemed to barely know what I was talking about.
>
> One wanted to engage me in a debate about why asymmetrical 20/7 
> (whatever it was) isn't good enough I assume because that's all she 
> was involved with so I muttered something about routing net blocks etc 
> so she gave up and switched me again. Fine.
>
> Then I'd finally get someone who seemed reasonable, seemed to know 
> what I was asking about, took down my call back info and promised 
> someone would get back to me within one business day.
>
> Never got a callback. Tried this a few times, same result.
>
> So, does it exist?
>
> I suppose if sales won't call you back you have to wonder what support 
> would be like.
>
> P.S. Their website for this service invites you to enter your address 
> to see if it's available and assures me it is, that's where you get 
> the phone number to call sales.
>
> --
>         -Barry Shein
>
> The World              | bzs at TheWorld.com           |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR,
> Canada
> Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*
>



From bross at pobox.com  Thu Oct 24 16:00:07 2013
From: bross at pobox.com (Brandon Ross)
Date: Thu, 24 Oct 2013 12:00:07 -0400 (EDT)
Subject: BGP failure analysis and recommendations
In-Reply-To: <CAL9jLabrAa=i50mxfM9wBDW_q=mdpaSu0t2oSm9U87ACwXi9tw@mail.gmail.com>
References: <5.1.0.14.0.20131023214304.0396ead0@authsmtp.jensenresearch.com>
 <CAL9jLabBf7wMm+xx9EyeK-uhyTgce+22HBwve3T37eFDFaKCmg@mail.gmail.com>
 <alpine.OSX.2.02.1310240257380.624@brugal.local>
 <CAL9jLabrAa=i50mxfM9wBDW_q=mdpaSu0t2oSm9U87ACwXi9tw@mail.gmail.com>
Message-ID: <alpine.OSX.2.02.1310241157460.624@brugal.local>

On Thu, 24 Oct 2013, Christopher Morrow wrote:

>> Um, how about, don't buy services from network providers that fail in this
>> way?
>
> I suppose the question is: "how would you know that any particular
> network had this failure mode?"

Ask detailed questions about how their network is architected.  Do they 
use eBGP multihop anywhere?  Do they use BFD on internal Ethernet links? 
Do they put their peering links in their IGP, or directly into iBGP?

> until, of course, you run into it... as jrc did...

That too.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
Schedule a meeting:  https://doodle.com/bross            Skype:  brandonross


From EWieling at nyigc.com  Thu Oct 24 20:13:04 2013
From: EWieling at nyigc.com (Eric Wieling)
Date: Thu, 24 Oct 2013 16:13:04 -0400
Subject: Looking for Juniper P-1GE-SFP-QPP in NYC area
Message-ID: <616B4ECE1290D441AD56124FEBB03D0818C36275C7@mailserver2007.nyigc.globe>

We had a P-1GE-SFP-QPP card go out today, looking for a source in the NYC area to get it replaced ASAP.

Thanks!


From job.snijders at hibernianetworks.com  Thu Oct 24 21:25:26 2013
From: job.snijders at hibernianetworks.com (Job Snijders)
Date: Thu, 24 Oct 2013 23:25:26 +0200
Subject: Network configuration archiving
Message-ID: <20131024212526.GC14735@Eleanor.local>

Dear all,

I am unsure what we as networkers have done in the past, but I am sure 
we've done our fair share of atonement and don't have to keep using 
RANCID.

Some might say "it took ages to get rancid to do kinda what we want!", 
but not all software ages well. One might work in environments where 
archived configurations are needed to even start provisioning, one 
might desire a separation between actual config and transcient data. 

As I am evaluating our path forward, I've compiled a small list of open 
source projects with some biased highlights. Your feedback is most 
welcome, maybe I missed some interesting projects or developments. I 
would also be very interested in what other operators seek in a network 
config/state archive tool.

RANCID - http://www.shrubbery.net/rancid/
    * Support for a wild variery of devices and operating systems
    * complex perl code base [1]
    * no central developer team, the internet is littered with forks

Oxidized - https://github.com/ytti/oxidized
    * modern & sexy approach with queue & workers
    * RESTful API (example: can bump devices to the head of the queue)
    * small user & developer base
    * written in that ruby language

Gerty - https://github.com/ssinyagin/gerty
    * Seems easier to extend than RANCID
    * perl...
    * small user & developer base

punc - https://code.google.com/p/punc/
    * written in python, based on notch [2]
    * no recent developments (although 2011 was a good wine year)

[1] - http://honestnetworker.wordpress.com/2013/06/28/adding-new-device-support-to-rancid/
[2] - https://code.google.com/p/notch/

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/20131024/bf4269da/attachment.bin>

From pde at eff.org  Thu Oct 24 22:27:21 2013
From: pde at eff.org (Peter Eckersley)
Date: Thu, 24 Oct 2013 15:27:21 -0700
Subject: EFF needs your help to stop patent trolls
Message-ID: <20131024222721.GE2739@mail2.eff.org>

Hi network operators,

Apologies for a non-technical post, but I believe this is an issue of
relevance to the NANOG community.  EFF is collecting signatures from
prominent engineers and technologists for a letter to the US Congress
calling for reform of the software patent system to protect inventors
and inventive companies against patent trolls, who use patents for
extortionate purposes without ever shipping any products.  We're doing
this now because there is a window of political opportunity to actually
get this problem fixed in the next few months.

Draft text of the letter is below.  If you broadly agree and would like
to sign on, please send me a private reply with:

- Your name;

- A 1-3 line bio that summarizes your main career achievements, which
  might be a current or past affiliation, RFCs you wrote, networks you
  built, companies you founded, etc;

- Whether you hold US patents; if so, how many you hold, and (if you
  know them) the patent numbers

=============================================================

Dear Senators and Congressmen,

We, the undersigned, are a group of inventors, technologists and
entrepreneurs. Many of us have founded technology businesses; we have
invented many of the protocols, systems and devices that make the
Internet work, and we are collectively listed as the inventors on [n
thousand] patents.

We write to you today about the U.S. patent system. That system is
broken. Based on our experiences building and deploying new digital
technologies, we believe that software patents are doing more
harm than good. Perhaps it is time to reexamine the idea, dating from
the 1980s, that government-issued monopolies on algorithms, protocols
and data structures are the best way to promote the advancement of
computer science.

But that will be a hard task, and one we don't expect to happen quickly.
Unfortunately, aspects of the problem have become so acute they must be
addressed immediately.

Broad, vague patents covering software-type inventions--some of which we
ourselves are listed as inventors on--are a malfunctioning component of
America's inventive machinery. This is particularly the case when those
patents end up in the hands of non-practicing patent trolls.

These non-practicing entities do not make or sell anything. Their
exploitation of patents as a tool for extortion is undermining America?s
technological progress; patent trolls are collecting taxes on innovation
by extracting billions of dollars in dubious licensing fees, and wasting
the time and management resources of creative businesses. Many of us
would have achieved much less in our careers if the trolling problem had
been as dire in past decades as it is now.

Some legislative proposals under current consideration would fix the
trolling problem. These include:

- Requiring that patent lawsuits actually explain which patents are
  infringed by which aspects of a defendant's technology, and how;

- Making clear who really owns the patent at issue;

- Allowing courts to shift fees to winning parties, making it rational for
  those threatened with an egregious patent suit to actually fight against
  the threat rather than paying what amounts to protection money;               

- Ensuring that those who purchase common, off-the-shelf technologies are
  shielded if they are sued for using them; and

- Increasing opportunities for streamlined patent review at the patent
  office.

While subduing the trolling threat, these proposed changes will not fix
the software patent problem. Congress should consider ways to stop
software patents from interfering with open standards and open source
software; from being claimed on problems, rather than solutions; and
from being drafted so obscurely that they teach us nothing and cannot be
searched. Congress needs to examine the very question of whether their
net impact is positive. 

But for now, we urge you to implement simple and urgently necessary
reforms. We believe in the promise of technology and the power of
creation to increase access to information, to create jobs, and to make
the world a better place. Please do not let patent trolls continue to
frustrate that purpose.

-- 
Peter Eckersley                            pde at eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993


From courtneysmith at comcast.net  Fri Oct 25 02:18:49 2013
From: courtneysmith at comcast.net (Courtney Smith)
Date: Thu, 24 Oct 2013 22:18:49 -0400
Subject: BGP failure analysis and recommendations
In-Reply-To: <mailman.3549.1382595181.1246.nanog@nanog.org>
References: <mailman.3549.1382595181.1246.nanog@nanog.org>
Message-ID: <0641E8C9-D1E1-47C2-B4DD-10F987BB3D55@comcast.net>


On Oct 24, 2013, at 2:13 AM, nanog-request at nanog.org wrote:

> Message: 7
> Date: Wed, 23 Oct 2013 22:40:34 -0400
> From: JRC NOC <nospam-nanog at jensenresearch.com>
> To: nanog at nanog.org
> Subject: BGP failure analysis and recommendations
> Message-ID:
> 	<5.1.0.14.0.20131023214304.0396ead0 at authsmtp.jensenresearch.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> 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.
> 
> 



Did you provider provide an official written RFO yet?  


Courtney Smith
courtneysmith at comcast.net

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments




From eric at ericheather.com  Fri Oct 25 02:30:27 2013
From: eric at ericheather.com (Eric C. Miller)
Date: Fri, 25 Oct 2013 02:30:27 +0000
Subject: Cogent 100M DIA in Denver
In-Reply-To: <525C55BB.9020500@garlic.com>
References: <1836104546-1381780649-cardhu_decombobulator_blackberry.rim.net-1842878518-@b12.c19.bise6.blackberry>
 <525C55BB.9020500@garlic.com>
Message-ID: <DC85D08B84BB854086E9524DAB67D18715ECEE25@Teriwood.miller.local>

I'm in the middle of converting IPV4 to dualstack with Cogent. I was told that they don't have IPV6 in the edge in Tampa yet, so they are VLANing us to a core device to give us v6. So by dualstack, they must mean dualstack only from an OSI Layer 1 approach. Heartburn city.....

Robert, do you have any advice from working with their ipv6 stuff, yet?



Eric Miller, CCNP
Network Engineering Consultant
(407) 257-5115




-----Original Message-----
From: Robert Glover [mailto:robertg at garlic.com] 
Sent: Monday, October 14, 2013 4:36 PM
To: tritran at cox.net
Cc: NANOG
Subject: Re: Cogent 100M DIA in Denver

We've had them since May 2008.  Recently upgraded from 100Mb to 250Mb. 
Had minor issues here and there (no outages to speak of).

I've had some IPv6 issues since moving the link to dual-stack a few months back, but we are not deploying IPv6 to end-users yet, so I'll let them slide on that.

On 10/14/2013 12:57 PM, Tri Tran wrote:
> They're lit in the bulding and have a much faster installation interval. How reliable are they? 
> Tri Tran
>





From erikm at buh.org  Fri Oct 25 03:05:07 2013
From: erikm at buh.org (Erik Muller)
Date: Thu, 24 Oct 2013 23:05:07 -0400
Subject: Network configuration archiving
In-Reply-To: <20131024212526.GC14735@Eleanor.local>
References: <20131024212526.GC14735@Eleanor.local>
Message-ID: <5269DFE3.901@buh.org>

On 10/24/13 17:25 , Job Snijders wrote:
> Some might say "it took ages to get rancid to do kinda what we want!",
> but not all software ages well. One might work in environments where
> archived configurations are needed to even start provisioning, one
> might desire a separation between actual config and transcient data.

Rancid certainly has its warts, but other than needing to test, pull hair, 
and patch things for new OS/platform deployments, it still generally Just 
Works once you have it installed, IME... and references like 
http://www.shrubbery.net/rancid/SteveSmithFedora15.pdf that are a bit dated 
still work well as a guide for deployment on more recent server OSes.

> As I am evaluating our path forward, I've compiled a small list of open
> source projects with some biased highlights. Your feedback is most
> welcome, maybe I missed some interesting projects or developments. I
> would also be very interested in what other operators seek in a network
> config/state archive tool.

I can't claim any knowledge of its actual functionality, but I've also heard of
NOC Project - http://nocproject.org/
 From the docs, it seems like it's trying to be more of an all-in-one 
do-everything package than just an archiving tool, but it could be worth 
investigating.  It claims support for a wide array of kit, and seems to 
have a non-trivial user base.

I'm sure I'm not the only one who'd be interested to hear if your 
evaluation determines that there is a R,RAN*ID out there that we've been 
overlooking.
-e


From tammy-lists at wiztech.biz  Fri Oct 25 03:19:32 2013
From: tammy-lists at wiztech.biz (Tammy Firefly)
Date: Thu, 24 Oct 2013 21:19:32 -0600
Subject: Network configuration archiving
In-Reply-To: <5269DFE3.901@buh.org>
References: <20131024212526.GC14735@Eleanor.local> <5269DFE3.901@buh.org>
Message-ID: <A88CED1B-7FEE-413D-BFE4-C3489B0E8D20@wiztech.biz>

Rancid is known to crash cisco devices doing config backups. I've seen it on 7200/7500 routers multiple times
Tammy


Sent from my iPhone

On Oct 24, 2013, at 21:05, Erik Muller <erikm at buh.org> wrote:

> On 10/24/13 17:25 , Job Snijders wrote:
>> Some might say "it took ages to get rancid to do kinda what we want!",
>> but not all software ages well. One might work in environments where
>> archived configurations are needed to even start provisioning, one
>> might desire a separation between actual config and transcient data.
> 
> Rancid certainly has its warts, but other than needing to test, pull hair, and patch things for new OS/platform deployments, it still generally Just Works once you have it installed, IME... and references like http://www.shrubbery.net/rancid/SteveSmithFedora15.pdf that are a bit dated still work well as a guide for deployment on more recent server OSes.
> 
>> As I am evaluating our path forward, I've compiled a small list of open
>> source projects with some biased highlights. Your feedback is most
>> welcome, maybe I missed some interesting projects or developments. I
>> would also be very interested in what other operators seek in a network
>> config/state archive tool.
> 
> I can't claim any knowledge of its actual functionality, but I've also heard of
> NOC Project - http://nocproject.org/
> From the docs, it seems like it's trying to be more of an all-in-one do-everything package than just an archiving tool, but it could be worth investigating.  It claims support for a wide array of kit, and seems to have a non-trivial user base.
> 
> I'm sure I'm not the only one who'd be interested to hear if your evaluation determines that there is a R,RAN*ID out there that we've been overlooking.
> -e
> 


From surfer at mauigateway.com  Fri Oct 25 03:22:49 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Thu, 24 Oct 2013 20:22:49 -0700
Subject: BGP failure analysis and recommendations
Message-ID: <20131024202249.ED8DB5A6@resin03.mta.everyone.net>



--- courtneysmith at comcast.net wrote:
From: Courtney Smith <courtneysmith at comcast.net>
> From: JRC NOC <nospam-nanog at jensenresearch.com>

> 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 


Did you provider provide an official written RFO yet?  
------------------------------------------------------------


When deciding to keep or change providers after a major mistake 
like this is do they send out an honest description of the mistake 
and what has been done to stop it from happening again in the future.  
Corporatespeak reports are grounds for dismissal!    ;-)

scott


From nick at foobar.org  Fri Oct 25 03:25:17 2013
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 25 Oct 2013 11:25:17 +0800
Subject: Network configuration archiving
In-Reply-To: <A88CED1B-7FEE-413D-BFE4-C3489B0E8D20@wiztech.biz>
References: <20131024212526.GC14735@Eleanor.local> <5269DFE3.901@buh.org>
 <A88CED1B-7FEE-413D-BFE4-C3489B0E8D20@wiztech.biz>
Message-ID: <5269E49D.5000506@foobar.org>

On 25/10/2013 11:19, Tammy Firefly wrote:
> Rancid is known to crash cisco devices doing config backups. I've seen
> it on 7200/7500 routers multiple times

this isn't a rancid problem though.

Nick



From mysidia at gmail.com  Fri Oct 25 03:29:29 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 24 Oct 2013 22:29:29 -0500
Subject: Network configuration archiving
In-Reply-To: <A88CED1B-7FEE-413D-BFE4-C3489B0E8D20@wiztech.biz>
References: <20131024212526.GC14735@Eleanor.local> <5269DFE3.901@buh.org>
 <A88CED1B-7FEE-413D-BFE4-C3489B0E8D20@wiztech.biz>
Message-ID: <CAAAwwbXTLSF7s=pMoaGGN2RiEo-1bCdSSHQK_qgi+riyi+66Ew@mail.gmail.com>

On Thu, Oct 24, 2013 at 10:19 PM, Tammy Firefly <tammy-lists at wiztech.biz>wrote:

> Rancid is known to crash cisco devices doing config backups. I've seen it
> on 7200/7500 routers multiple times
>

I don't doubt it,  but since RANCID only uses show commands;   I would
suspect that any similar tool that uses similar show commands,  could
expose the same issue   ----   which is  obviously a router  CLI bug not a
RANCID bug.



> Tammy--
>
-JH

From mysidia at gmail.com  Fri Oct 25 03:31:08 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 24 Oct 2013 22:31:08 -0500
Subject: Network configuration archiving
In-Reply-To: <20131024212526.GC14735@Eleanor.local>
References: <20131024212526.GC14735@Eleanor.local>
Message-ID: <CAAAwwbUQvt05YvNhqT4NQDx2NQ1GKvYB1BrO51PDFLCRMApNLg@mail.gmail.com>

On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders <
job.snijders at hibernianetworks.com> wrote:

> Dear all,
> I am unsure what we as networkers have done in the past, but I am sure
> we've done our fair share of atonement and don't have to keep using
> RANCID.
>

Does the nature of the codebase and future development matter all that
much?    Not to dismiss it as a factor,   but I think other criteria should
be more important  :)

Nrmally  when I would want to compare software ----   I would be concerned
first and foremost,     (1)  What does it do/what makes it unique --  is
something special about  package X  over package Y?;
(2)   Does it meet all the  minimum needs I have right now to be a viable
solution?
           Does it grab all my configs and  put them in a permanent
revision control system?  :)

(3) How reliable is it,  can I trust it?   Is it very secure and safe to
use?    It's no good if it breaks, fails,  or does something dangerous.
How much care and feeding will it need to keep working?          If it
needs complex repair work every few weeks,  I don't like it.

(4) How easy is it to get up and running,  and to perform any required
ongoing maintenance
(5) What extra nice to have functionality does it have?


(6)  Maybe other stuff like  what language its written in,  if extra
features need to be added

--
-JH

From tammy-lists at wiztech.biz  Fri Oct 25 03:38:18 2013
From: tammy-lists at wiztech.biz (Tammy Firefly)
Date: Thu, 24 Oct 2013 21:38:18 -0600
Subject: Network configuration archiving
In-Reply-To: <CAAAwwbXTLSF7s=pMoaGGN2RiEo-1bCdSSHQK_qgi+riyi+66Ew@mail.gmail.com>
References: <20131024212526.GC14735@Eleanor.local> <5269DFE3.901@buh.org>
 <A88CED1B-7FEE-413D-BFE4-C3489B0E8D20@wiztech.biz>
 <CAAAwwbXTLSF7s=pMoaGGN2RiEo-1bCdSSHQK_qgi+riyi+66Ew@mail.gmail.com>
Message-ID: <404D8480-3397-4396-AF31-208488B80440@wiztech.biz>

Yes I 100% agree its a IOS bug. It had something to do with the way it ended a ssh session.

That was one reason we got rid of cisco at our edges and use juniper which has config backup built into JunOS (via ssh/FTP)
--Tammy


Sent from my iPhone

On Oct 24, 2013, at 21:29, Jimmy Hess <mysidia at gmail.com> wrote:

> On Thu, Oct 24, 2013 at 10:19 PM, Tammy Firefly <tammy-lists at wiztech.biz> wrote:
>> Rancid is known to crash cisco devices doing config backups. I've seen it on 7200/7500 routers multiple times
> 
> I don't doubt it,  but since RANCID only uses show commands;   I would suspect that any similar tool that uses similar show commands,  could expose the same issue   ----   which is  obviously a router  CLI bug not a RANCID bug.
> 
>  
>> Tammy-- 
> -JH

From tammy-lists at wiztech.biz  Fri Oct 25 03:39:33 2013
From: tammy-lists at wiztech.biz (Tammy Firefly)
Date: Thu, 24 Oct 2013 21:39:33 -0600
Subject: Network configuration archiving
In-Reply-To: <5269E49D.5000506@foobar.org>
References: <20131024212526.GC14735@Eleanor.local> <5269DFE3.901@buh.org>
 <A88CED1B-7FEE-413D-BFE4-C3489B0E8D20@wiztech.biz>
 <5269E49D.5000506@foobar.org>
Message-ID: <CF91BBE3-BBC1-47EF-B9FF-8AF6CD7AB6B4@wiztech.biz>

No it's not rancids fault :)


Sent from my iPhone

On Oct 24, 2013, at 21:25, Nick Hilliard <nick at foobar.org> wrote:

> On 25/10/2013 11:19, Tammy Firefly wrote:
>> Rancid is known to crash cisco devices doing config backups. I've seen
>> it on 7200/7500 routers multiple times
> 
> this isn't a rancid problem though.
> 
> Nick
> 


From kenneth.mcrae at dreamhost.com  Fri Oct 25 03:45:20 2013
From: kenneth.mcrae at dreamhost.com (Kenneth McRae)
Date: Thu, 24 Oct 2013 20:45:20 -0700
Subject: Network configuration archiving
In-Reply-To: <CAAAwwbUQvt05YvNhqT4NQDx2NQ1GKvYB1BrO51PDFLCRMApNLg@mail.gmail.com>
References: <20131024212526.GC14735@Eleanor.local>
 <CAAAwwbUQvt05YvNhqT4NQDx2NQ1GKvYB1BrO51PDFLCRMApNLg@mail.gmail.com>
Message-ID: <CALBytuYZ2WYwFUHyH4unvLTY7Wk0XEa0jp6MiW85W+=9C++gSg@mail.gmail.com>

Hiw about SolarWinds Config Mgmt software?
On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:

> On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders <
> job.snijders at hibernianetworks.com> wrote:
>
> > Dear all,
> > I am unsure what we as networkers have done in the past, but I am sure
> > we've done our fair share of atonement and don't have to keep using
> > RANCID.
> >
>
> Does the nature of the codebase and future development matter all that
> much?    Not to dismiss it as a factor,   but I think other criteria should
> be more important  :)
>
> Nrmally  when I would want to compare software ----   I would be concerned
> first and foremost,     (1)  What does it do/what makes it unique --  is
> something special about  package X  over package Y?;
> (2)   Does it meet all the  minimum needs I have right now to be a viable
> solution?
>            Does it grab all my configs and  put them in a permanent
> revision control system?  :)
>
> (3) How reliable is it,  can I trust it?   Is it very secure and safe to
> use?    It's no good if it breaks, fails,  or does something dangerous.
> How much care and feeding will it need to keep working?          If it
> needs complex repair work every few weeks,  I don't like it.
>
> (4) How easy is it to get up and running,  and to perform any required
> ongoing maintenance
> (5) What extra nice to have functionality does it have?
>
>
> (6)  Maybe other stuff like  what language its written in,  if extra
> features need to be added
>
> --
> -JH
>

From nrollo at kw-corp.com  Fri Oct 25 03:56:30 2013
From: nrollo at kw-corp.com (Nolan Rollo)
Date: Fri, 25 Oct 2013 03:56:30 +0000
Subject: Network configuration archiving
In-Reply-To: <CALBytuYZ2WYwFUHyH4unvLTY7Wk0XEa0jp6MiW85W+=9C++gSg@mail.gmail.com>
References: <20131024212526.GC14735@Eleanor.local>
 <CAAAwwbUQvt05YvNhqT4NQDx2NQ1GKvYB1BrO51PDFLCRMApNLg@mail.gmail.com>
 <CALBytuYZ2WYwFUHyH4unvLTY7Wk0XEa0jp6MiW85W+=9C++gSg@mail.gmail.com>
Message-ID: <D27DF53349E1E94AA9599001CC1C718917A31DB3@kw2k8.KWAUTO.PRI>

Puppet, Chef, cfEngine, etc... the list goes on and on, it's a matter of taste (no chef pun intended) and what you're familiar with as well as what works for your device configurations and the management team

-----Original Message-----
From: Kenneth McRae [mailto:kenneth.mcrae at dreamhost.com] 
Sent: Thursday, October 24, 2013 11:45 PM
To: Jimmy Hess
Cc: nanog at nanog.org
Subject: Re: Network configuration archiving

Hiw about SolarWinds Config Mgmt software?
On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:

> On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders < 
> job.snijders at hibernianetworks.com> wrote:
>
> > Dear all,
> > I am unsure what we as networkers have done in the past, but I am 
> > sure we've done our fair share of atonement and don't have to keep 
> > using RANCID.
> >
>
> Does the nature of the codebase and future development matter all that
> much?    Not to dismiss it as a factor,   but I think other criteria should
> be more important  :)
>
> Nrmally  when I would want to compare software ----   I would be concerned
> first and foremost,     (1)  What does it do/what makes it unique --  is
> something special about  package X  over package Y?;
> (2)   Does it meet all the  minimum needs I have right now to be a viable
> solution?
>            Does it grab all my configs and  put them in a permanent 
> revision control system?  :)
>
> (3) How reliable is it,  can I trust it?   Is it very secure and safe to
> use?    It's no good if it breaks, fails,  or does something dangerous.
> How much care and feeding will it need to keep working?          If it
> needs complex repair work every few weeks,  I don't like it.
>
> (4) How easy is it to get up and running,  and to perform any required 
> ongoing maintenance
> (5) What extra nice to have functionality does it have?
>
>
> (6)  Maybe other stuff like  what language its written in,  if extra 
> features need to be added
>
> --
> -JH
>


From tammy-lists at wiztech.biz  Fri Oct 25 03:59:08 2013
From: tammy-lists at wiztech.biz (Tammy Firefly)
Date: Thu, 24 Oct 2013 21:59:08 -0600
Subject: Network configuration archiving
In-Reply-To: <CALBytuYZ2WYwFUHyH4unvLTY7Wk0XEa0jp6MiW85W+=9C++gSg@mail.gmail.com>
References: <20131024212526.GC14735@Eleanor.local>
 <CAAAwwbUQvt05YvNhqT4NQDx2NQ1GKvYB1BrO51PDFLCRMApNLg@mail.gmail.com>
 <CALBytuYZ2WYwFUHyH4unvLTY7Wk0XEa0jp6MiW85W+=9C++gSg@mail.gmail.com>
Message-ID: <5299D42F-E962-4DFA-B817-DDEB2D8B1A98@wiztech.biz>

Is that licensed per device or per user out of curiosity ?


Sent from my iPhone

On Oct 24, 2013, at 21:45, Kenneth McRae <kenneth.mcrae at dreamhost.com> wrote:

> Hiw about SolarWinds Config Mgmt software?
> On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
> 
>> On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders <
>> job.snijders at hibernianetworks.com> wrote:
>> 
>>> Dear all,
>>> I am unsure what we as networkers have done in the past, but I am sure
>>> we've done our fair share of atonement and don't have to keep using
>>> RANCID.
>> 
>> Does the nature of the codebase and future development matter all that
>> much?    Not to dismiss it as a factor,   but I think other criteria should
>> be more important  :)
>> 
>> Nrmally  when I would want to compare software ----   I would be concerned
>> first and foremost,     (1)  What does it do/what makes it unique --  is
>> something special about  package X  over package Y?;
>> (2)   Does it meet all the  minimum needs I have right now to be a viable
>> solution?
>>           Does it grab all my configs and  put them in a permanent
>> revision control system?  :)
>> 
>> (3) How reliable is it,  can I trust it?   Is it very secure and safe to
>> use?    It's no good if it breaks, fails,  or does something dangerous.
>> How much care and feeding will it need to keep working?          If it
>> needs complex repair work every few weeks,  I don't like it.
>> 
>> (4) How easy is it to get up and running,  and to perform any required
>> ongoing maintenance
>> (5) What extra nice to have functionality does it have?
>> 
>> 
>> (6)  Maybe other stuff like  what language its written in,  if extra
>> features need to be added
>> 
>> --
>> -JH
>> 


From kenneth.mcrae at dreamhost.com  Fri Oct 25 04:08:12 2013
From: kenneth.mcrae at dreamhost.com (Kenneth McRae)
Date: Thu, 24 Oct 2013 21:08:12 -0700
Subject: Network configuration archiving
In-Reply-To: <5299D42F-E962-4DFA-B817-DDEB2D8B1A98@wiztech.biz>
References: <20131024212526.GC14735@Eleanor.local>
 <CAAAwwbUQvt05YvNhqT4NQDx2NQ1GKvYB1BrO51PDFLCRMApNLg@mail.gmail.com>
 <CALBytuYZ2WYwFUHyH4unvLTY7Wk0XEa0jp6MiW85W+=9C++gSg@mail.gmail.com>
 <5299D42F-E962-4DFA-B817-DDEB2D8B1A98@wiztech.biz>
Message-ID: <CALBytuZiL0m5p0nW3DTfTCPQZiaChC3sGxFEbcTGNX+7UWf3Ng@mail.gmail.com>

By device or you can purchase an unlimited device count..
On Oct 24, 2013 8:59 PM, "Tammy Firefly" <tammy-lists at wiztech.biz> wrote:

> Is that licensed per device or per user out of curiosity ?
>
>
> Sent from my iPhone
>
> On Oct 24, 2013, at 21:45, Kenneth McRae <kenneth.mcrae at dreamhost.com>
> wrote:
>
> > Hiw about SolarWinds Config Mgmt software?
> > On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
> >
> >> On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders <
> >> job.snijders at hibernianetworks.com> wrote:
> >>
> >>> Dear all,
> >>> I am unsure what we as networkers have done in the past, but I am sure
> >>> we've done our fair share of atonement and don't have to keep using
> >>> RANCID.
> >>
> >> Does the nature of the codebase and future development matter all that
> >> much?    Not to dismiss it as a factor,   but I think other criteria
> should
> >> be more important  :)
> >>
> >> Nrmally  when I would want to compare software ----   I would be
> concerned
> >> first and foremost,     (1)  What does it do/what makes it unique --  is
> >> something special about  package X  over package Y?;
> >> (2)   Does it meet all the  minimum needs I have right now to be a
> viable
> >> solution?
> >>           Does it grab all my configs and  put them in a permanent
> >> revision control system?  :)
> >>
> >> (3) How reliable is it,  can I trust it?   Is it very secure and safe to
> >> use?    It's no good if it breaks, fails,  or does something dangerous.
> >> How much care and feeding will it need to keep working?          If it
> >> needs complex repair work every few weeks,  I don't like it.
> >>
> >> (4) How easy is it to get up and running,  and to perform any required
> >> ongoing maintenance
> >> (5) What extra nice to have functionality does it have?
> >>
> >>
> >> (6)  Maybe other stuff like  what language its written in,  if extra
> >> features need to be added
> >>
> >> --
> >> -JH
> >>
>

From jlewis at lewis.org  Fri Oct 25 04:11:22 2013
From: jlewis at lewis.org (Jon Lewis)
Date: Fri, 25 Oct 2013 00:11:22 -0400 (EDT)
Subject: Network configuration archiving
In-Reply-To: <CALBytuZiL0m5p0nW3DTfTCPQZiaChC3sGxFEbcTGNX+7UWf3Ng@mail.gmail.com>
References: <20131024212526.GC14735@Eleanor.local>
 <CAAAwwbUQvt05YvNhqT4NQDx2NQ1GKvYB1BrO51PDFLCRMApNLg@mail.gmail.com>
 <CALBytuYZ2WYwFUHyH4unvLTY7Wk0XEa0jp6MiW85W+=9C++gSg@mail.gmail.com>
 <5299D42F-E962-4DFA-B817-DDEB2D8B1A98@wiztech.biz>
 <CALBytuZiL0m5p0nW3DTfTCPQZiaChC3sGxFEbcTGNX+7UWf3Ng@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.1310250010210.17328@soloth.lewis.org>

Or use perfectly good (RANCID + cvsweb) free software.  Hmm.

On Thu, 24 Oct 2013, Kenneth McRae wrote:

> By device or you can purchase an unlimited device count..
> On Oct 24, 2013 8:59 PM, "Tammy Firefly" <tammy-lists at wiztech.biz> wrote:
>
>> Is that licensed per device or per user out of curiosity ?
>>
>>
>> Sent from my iPhone
>>
>> On Oct 24, 2013, at 21:45, Kenneth McRae <kenneth.mcrae at dreamhost.com>
>> wrote:
>>
>>> Hiw about SolarWinds Config Mgmt software?
>>> On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
>>>
>>>> On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders <
>>>> job.snijders at hibernianetworks.com> wrote:
>>>>
>>>>> Dear all,
>>>>> I am unsure what we as networkers have done in the past, but I am sure
>>>>> we've done our fair share of atonement and don't have to keep using
>>>>> RANCID.
>>>>
>>>> Does the nature of the codebase and future development matter all that
>>>> much?    Not to dismiss it as a factor,   but I think other criteria
>> should
>>>> be more important  :)
>>>>
>>>> Nrmally  when I would want to compare software ----   I would be
>> concerned
>>>> first and foremost,     (1)  What does it do/what makes it unique --  is
>>>> something special about  package X  over package Y?;
>>>> (2)   Does it meet all the  minimum needs I have right now to be a
>> viable
>>>> solution?
>>>>           Does it grab all my configs and  put them in a permanent
>>>> revision control system?  :)
>>>>
>>>> (3) How reliable is it,  can I trust it?   Is it very secure and safe to
>>>> use?    It's no good if it breaks, fails,  or does something dangerous.
>>>> How much care and feeding will it need to keep working?          If it
>>>> needs complex repair work every few weeks,  I don't like it.
>>>>
>>>> (4) How easy is it to get up and running,  and to perform any required
>>>> ongoing maintenance
>>>> (5) What extra nice to have functionality does it have?
>>>>
>>>>
>>>> (6)  Maybe other stuff like  what language its written in,  if extra
>>>> features need to be added
>>>>
>>>> --
>>>> -JH
>>>>
>>
>

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


From phiber at phiber.org  Fri Oct 25 04:19:08 2013
From: phiber at phiber.org (Christopher Rogers)
Date: Thu, 24 Oct 2013 21:19:08 -0700
Subject: Network configuration archiving
In-Reply-To: <Pine.LNX.4.61.1310250010210.17328@soloth.lewis.org>
References: <20131024212526.GC14735@Eleanor.local>
 <CAAAwwbUQvt05YvNhqT4NQDx2NQ1GKvYB1BrO51PDFLCRMApNLg@mail.gmail.com>
 <CALBytuYZ2WYwFUHyH4unvLTY7Wk0XEa0jp6MiW85W+=9C++gSg@mail.gmail.com>
 <5299D42F-E962-4DFA-B817-DDEB2D8B1A98@wiztech.biz>
 <CALBytuZiL0m5p0nW3DTfTCPQZiaChC3sGxFEbcTGNX+7UWf3Ng@mail.gmail.com>
 <Pine.LNX.4.61.1310250010210.17328@soloth.lewis.org>
Message-ID: <CALZUEranxUu3h61M_d1=rnBSaF_csEFX+BOMAT4jEg2Lemmnzg@mail.gmail.com>

Rancid is great, we use it.  It's hard to justify paying money for
something that really isn't that complicated, especially stupid licensing
fees.

One of my problems with rancid though is that many of the commands it runs
can be somewhat intrusive, and also smacks of trying to use a configuration
management system as an active monitoring tool.

Go into the commandtable entries for your various devices, and remove
everything except the show running-config bits (or whatever your $vendor
uses) and you'll run into a lot less risk of blowing a device up with
rancid, also a lot quicker execution times.

Or just remove rancid entirely, and just ssh show running-config (using rsa
keys) on your devices and dump the output into cvs/svn/whatever.  Not
everything has ssh though.  :(

-chris




2013/10/24 Jon Lewis <jlewis at lewis.org>

> Or use perfectly good (RANCID + cvsweb) free software.  Hmm.
>
>
> On Thu, 24 Oct 2013, Kenneth McRae wrote:
>
>  By device or you can purchase an unlimited device count..
>> On Oct 24, 2013 8:59 PM, "Tammy Firefly" <tammy-lists at wiztech.biz> wrote:
>>
>>  Is that licensed per device or per user out of curiosity ?
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Oct 24, 2013, at 21:45, Kenneth McRae <kenneth.mcrae at dreamhost.com>
>>> wrote:
>>>
>>>  Hiw about SolarWinds Config Mgmt software?
>>>> On Oct 24, 2013 8:38 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
>>>>
>>>>  On Thu, Oct 24, 2013 at 4:25 PM, Job Snijders <
>>>>> job.snijders at hibernianetworks.**com<job.snijders at hibernianetworks.com>>
>>>>> wrote:
>>>>>
>>>>>  Dear all,
>>>>>> I am unsure what we as networkers have done in the past, but I am sure
>>>>>> we've done our fair share of atonement and don't have to keep using
>>>>>> RANCID.
>>>>>>
>>>>>
>>>>> Does the nature of the codebase and future development matter all that
>>>>> much?    Not to dismiss it as a factor,   but I think other criteria
>>>>>
>>>> should
>>>
>>>> be more important  :)
>>>>>
>>>>> Nrmally  when I would want to compare software ----   I would be
>>>>>
>>>> concerned
>>>
>>>> first and foremost,     (1)  What does it do/what makes it unique --  is
>>>>> something special about  package X  over package Y?;
>>>>> (2)   Does it meet all the  minimum needs I have right now to be a
>>>>>
>>>> viable
>>>
>>>> solution?
>>>>>           Does it grab all my configs and  put them in a permanent
>>>>> revision control system?  :)
>>>>>
>>>>> (3) How reliable is it,  can I trust it?   Is it very secure and safe
>>>>> to
>>>>> use?    It's no good if it breaks, fails,  or does something dangerous.
>>>>> How much care and feeding will it need to keep working?          If it
>>>>> needs complex repair work every few weeks,  I don't like it.
>>>>>
>>>>> (4) How easy is it to get up and running,  and to perform any required
>>>>> ongoing maintenance
>>>>> (5) What extra nice to have functionality does it have?
>>>>>
>>>>>
>>>>> (6)  Maybe other stuff like  what language its written in,  if extra
>>>>> features need to be added
>>>>>
>>>>> --
>>>>> -JH
>>>>>
>>>>>
>>>
>>
> ------------------------------**------------------------------**----------
>  Jon Lewis, MCP :)           |  I route
>                              |  therefore you are
> _________ http://www.lewis.org/~jlewis/**pgp<http://www.lewis.org/~jlewis/pgp>for PGP public key_________
>
>

From elouie at yahoo.com  Fri Oct 25 04:51:22 2013
From: elouie at yahoo.com (Eric A Louie)
Date: Thu, 24 Oct 2013 21:51:22 -0700 (PDT)
Subject: Network configuration archiving
In-Reply-To: <20131024212526.GC14735@Eleanor.local>
References: <20131024212526.GC14735@Eleanor.local>
Message-ID: <1382676682.45608.YahooMailNeo@web181602.mail.ne1.yahoo.com>

I know you said open source, but we're using Solarwinds Cattools with very good results.? We also have Rancid running in the background.





>________________________________
> From: Job Snijders <job.snijders at hibernianetworks.com>
>To: nanog at nanog.org 
>Sent: Thursday, October 24, 2013 2:25 PM
>Subject: Network configuration archiving
> 
>
>Dear all,
>
>I am unsure what we as networkers have done in the past, but I am sure 
>we've done our fair share of atonement and don't have to keep using 
>RANCID.
>
>Some might say "it took ages to get rancid to do kinda what we want!", 
>but not all software ages well. One might work in environments where 
>archived configurations are needed to even start provisioning, one 
>might desire a separation between actual config and transcient data. 
>
>As I am evaluating our path forward, I've compiled a small list of open 
>source projects with some biased highlights. Your feedback is most 
>welcome, maybe I missed some interesting projects or developments. I 
>would also be very interested in what other operators seek in a network 
>config/state archive tool.
>
>RANCID - http://www.shrubbery.net/rancid/
>? ? * Support for a wild variery of devices and operating systems
>? ? * complex perl code base [1]
>? ? * no central developer team, the internet is littered with forks
>
>Oxidized - https://github.com/ytti/oxidized
>? ? * modern & sexy approach with queue & workers
>? ? * RESTful API (example: can bump devices to the head of the queue)
>? ? * small user & developer base
>? ? * written in that ruby language
>
>Gerty - https://github.com/ssinyagin/gerty
>? ? * Seems easier to extend than RANCID
>? ? * perl...
>? ? * small user & developer base
>
>punc - https://code.google.com/p/punc/
>? ? * written in python, based on notch [2]
>? ? * no recent developments (although 2011 was a good wine year)
>
>[1] - http://honestnetworker.wordpress.com/2013/06/28/adding-new-device-support-to-rancid/
>[2] - https://code.google.com/p/notch/
>
>Kind regards,
>
>Job
>
>
>
>

From saku at ytti.fi  Fri Oct 25 07:07:49 2013
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 25 Oct 2013 10:07:49 +0300
Subject: Network configuration archiving
In-Reply-To: <5269DFE3.901@buh.org>
References: <20131024212526.GC14735@Eleanor.local>
 <5269DFE3.901@buh.org>
Message-ID: <20131025070749.GA6262@pob.ytti.fi>

On (2013-10-24 23:05 -0400), Erik Muller wrote:

> Rancid certainly has its warts, but other than needing to test, pull
> hair, and patch things for new OS/platform deployments, it still
> generally Just Works once you have it installed, IME... and
> references like

For us problem with rancid is that we're quite married to configuration
backups, provisioning depends on them. And we have good number of devices in
rancid and rancid runs take several hours.
Now we may need refreshed configuration backup to satisfy some dependencies to
complete some work, but if rancid is running we cannot, in worst case, we may
need to postpone some work to next working day.

We have 'one off' hack script for rancid, which fetches just one device right
now, but we cannot run it if rancid proper is currently running.

Other than that, rancid works very reliably and is highly robust. For style
rancid does not get points as there is terrible amount of code duplication for
different platforms.



Philosophically speaking, configuration backups should be completely useless,
full configuration to network should be generated from central place in
fully automated manner.
-- 
  ++ytti


From martin.pels at ams-ix.net  Fri Oct 25 08:43:43 2013
From: martin.pels at ams-ix.net (Martin Pels)
Date: Fri, 25 Oct 2013 10:43:43 +0200
Subject: Network configuration archiving
In-Reply-To: <20131025070749.GA6262@pob.ytti.fi>
References: <20131024212526.GC14735@Eleanor.local> <5269DFE3.901@buh.org>
 <20131025070749.GA6262@pob.ytti.fi>
Message-ID: <20131025104343.0e790e3f@fizzix>

On Fri, 25 Oct 2013 10:07:49 +0300
Saku Ytti <saku at ytti.fi> wrote:

> On (2013-10-24 23:05 -0400), Erik Muller wrote:
> 
> > Rancid certainly has its warts, but other than needing to test, pull
> > hair, and patch things for new OS/platform deployments, it still
> > generally Just Works once you have it installed, IME... and
> > references like
> 
> For us problem with rancid is that we're quite married to configuration
> backups, provisioning depends on them. And we have good number of devices in
> rancid and rancid runs take several hours.
> Now we may need refreshed configuration backup to satisfy some dependencies to
> complete some work, but if rancid is running we cannot, in worst case, we may
> need to postpone some work to next working day.
> 
> We have 'one off' hack script for rancid, which fetches just one device right
> now, but we cannot run it if rancid proper is currently running.

Have you tried running multiple rancid instances in parallel? (each talking to a
different batch of devices)

> Other than that, rancid works very reliably and is highly robust. For style
> rancid does not get points as there is terrible amount of code duplication for
> different platforms.

The main reason we're all stuck with rancid is that there is no standardized
way to securely pull configurations and other information from devices built by
all major vendors. Rancid, as horribly written as it may be, has over the years
incorporated ways to deal with the quirks of pretty much every CLI out there.
This is hard to duplicate.

> Philosophically speaking, configuration backups should be completely useless,
> full configuration to network should be generated from central place in
> fully automated manner.

The diff-ed backups that rancid provides serve another purpose: verifying that
what your NMS says should be configured matches the actual device
configurations.

Regards,
Martin


From shopik at inblock.ru  Fri Oct 25 09:55:26 2013
From: shopik at inblock.ru (Nikolay Shopik)
Date: Fri, 25 Oct 2013 13:55:26 +0400
Subject: A9K-MPA-20X1GE in ASR9001
Message-ID: <526A400E.2060309@inblock.ru>

Hey, anyone had issues with A9K-MPA-20X1GE in ASR9001?

It get disabled for us after 20 seconds finishing initialization, with
such message.

%PLATFORM-SCC-2-BAD_ID_HW : Failed Identification Test in 0/130/0 [1/0]
The module in 0/130/0 in this router may not be a genuineCisco product.



From shopik at inblock.ru  Fri Oct 25 10:05:27 2013
From: shopik at inblock.ru (Nikolay Shopik)
Date: Fri, 25 Oct 2013 14:05:27 +0400
Subject: A9K-MPA-20X1GE in ASR9001
In-Reply-To: <0A3447A1-8B2B-470F-9959-89BB086E63F7@rferl.org>
References: <0A3447A1-8B2B-470F-9959-89BB086E63F7@rferl.org>
Message-ID: <526A4267.4080802@inblock.ru>

I don't have any GBIC/SPF inserted in it right now, it just turn off
whole module. So won't allow me even fpd upgrade.

On 25/10/13 14:02, Ray Ludendorff wrote:
> 
> 
> It means that you did not purchase a original Cisco GBIC for the interface ..
> Therefore it will not be TAC supported if you have problems with the interface.
> There is a command to override this error and still use the interfaces.
> 
> Sent from mobile device
> 
>> On Oct 25, 2013, at 11:56, "Nikolay Shopik" <shopik at inblock.ru> wrote:
>>
>> Hey, anyone had issues with A9K-MPA-20X1GE in ASR9001?
>>
>> It get disabled for us after 20 seconds finishing initialization, with
>> such message.
>>
>> %PLATFORM-SCC-2-BAD_ID_HW : Failed Identification Test in 0/130/0 [1/0]
>> The module in 0/130/0 in this router may not be a genuineCisco product.
>>
>>


From remco at signet.nl  Fri Oct 25 10:08:53 2013
From: remco at signet.nl (Remco Bressers)
Date: Fri, 25 Oct 2013 12:08:53 +0200
Subject: A9K-MPA-20X1GE in ASR9001
In-Reply-To: <526A400E.2060309@inblock.ru>
References: <526A400E.2060309@inblock.ru>
Message-ID: <526A4335.2000802@signet.nl>

On 10/25/2013 11:55 AM, Nikolay Shopik wrote:
> Hey, anyone had issues with A9K-MPA-20X1GE in ASR9001?

Hi Nikolay,

We're using them without problems. What software are you running? I did
have major issues with flapping onboard 10G ports disabling TX.

Regards,

Remco Bressers
Signet B.V.




From shopik at inblock.ru  Fri Oct 25 10:17:01 2013
From: shopik at inblock.ru (Nikolay Shopik)
Date: Fri, 25 Oct 2013 14:17:01 +0400
Subject: A9K-MPA-20X1GE in ASR9001
In-Reply-To: <526A4335.2000802@signet.nl>
References: <526A400E.2060309@inblock.ru> <526A4335.2000802@signet.nl>
Message-ID: <526A451D.8020409@inblock.ru>

On 25/10/13 14:08, Remco Bressers wrote:
> We're using them without problems. What software are you running? I did
> have major issues with flapping onboard 10G ports disabling TX.

Tried on shiped 4.3.1 and now on 4.3.2, with same results.
Also IIRC onboard ports only accept SFP+ rigth?


From mcn4 at leicester.ac.uk  Fri Oct 25 11:59:48 2013
From: mcn4 at leicester.ac.uk (Matthew Newton)
Date: Fri, 25 Oct 2013 12:59:48 +0100
Subject: Network configuration archiving
In-Reply-To: <20131024212526.GC14735@Eleanor.local>
References: <20131024212526.GC14735@Eleanor.local>
Message-ID: <20131025115948.GF10952@rootmail.cc.le.ac.uk>

On Thu, Oct 24, 2013 at 11:25:26PM +0200, Job Snijders wrote:
> As I am evaluating our path forward, I've compiled a small list of open 
> source projects with some biased highlights. Your feedback is most 
> welcome, maybe I missed some interesting projects or developments. I 
> would also be very interested in what other operators seek in a network 
> config/state archive tool.

For the last ~8 years we've used a very simple in-house bash
script that uses SNMP to tell the switch to write its config using
tftp, and then does a wr mem. It then checks the configs into a
subversion repository and e-mails out any diffs.

One criteria we had was that our config backup system wasn't going
to get CLI access to any routers if at all possible, and this
turned out to be a good alternative. I can't think of many times
when it's failed to work; occasionally the odd switch might not
respond, but that's rare.

The only possible issue being that we're 100% Cisco, so I don't
know if other vendors support the same MIBs.

I'll try and post the script (250 lines) somewhere if anyone's
interested.

Cheers,

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at le.ac.uk>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>


From job.snijders at hibernianetworks.com  Fri Oct 25 12:27:42 2013
From: job.snijders at hibernianetworks.com (Job Snijders)
Date: Fri, 25 Oct 2013 14:27:42 +0200
Subject: Network configuration archiving
In-Reply-To: <20131025115948.GF10952@rootmail.cc.le.ac.uk>
References: <20131024212526.GC14735@Eleanor.local>
 <20131025115948.GF10952@rootmail.cc.le.ac.uk>
Message-ID: <20131025122742.GM14735@Eleanor.local>

On Fri, Oct 25, 2013 at 12:59:48PM +0100, Matthew Newton wrote:

> I'll try and post the script (250 lines) somewhere if anyone's
> interested.

It is almost always good to open source your tools, for others to learn
and benefit from! :-)

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/20131025/87c150ef/attachment.bin>

From saku at ytti.fi  Fri Oct 25 12:32:58 2013
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 25 Oct 2013 15:32:58 +0300
Subject: Network configuration archiving
In-Reply-To: <20131025104343.0e790e3f@fizzix>
References: <20131024212526.GC14735@Eleanor.local> <5269DFE3.901@buh.org>
 <20131025070749.GA6262@pob.ytti.fi>
 <20131025104343.0e790e3f@fizzix>
Message-ID: <20131025123258.GA15815@pob.ytti.fi>

On (2013-10-25 10:43 +0200), Martin Pels wrote:

> The diff-ed backups that rancid provides serve another purpose: verifying that
> what your NMS says should be configured matches the actual device
> configurations.

Diffing one rancid config to another rancid config would not help with this at
all.
You'd need to diff provisiong system config to rancid config which is
extremely complex problem, as your provisioning system is not creating 'post
parser' config, it's creating config in completely different way than what it
will be after parser.

The hard/wrong solution the problem is to have per-platform parsing
intelligence reimplemented in your provisioning system.

The two easy solutions are

a) when your provisioning system pushes change out, it saves the config it
sends, and then it views what route stored and makes note of them being the
same. If it has this logic, then rancid is not needed.

b) before your provisioning system pushes change out, it checks timestamp on
config, if timestamp is newer than its latest config push, it regenerates full
configuration. In this scenario also, rancid is not needed.



However going 100% of config is in systems is not really something many
target, nor have I seen good products for it. It's not actually hard problem,
not even when targeting multiple platforms. As platform specific intelligence
can be kept very low with some design choices.

-- 
  ++ytti


From woody at pch.net  Fri Oct 25 12:54:57 2013
From: woody at pch.net (Bill Woodcock)
Date: Fri, 25 Oct 2013 19:54:57 +0700
Subject: A9K-MPA-20X1GE in ASR9001
In-Reply-To: <526A4335.2000802@signet.nl>
References: <526A400E.2060309@inblock.ru> <526A4335.2000802@signet.nl>
Message-ID: <35DC8B21-E765-4EA8-9728-4C8A1EFA8638@pch.net>


We use that combination without difficulty as well. 

    
                -Bill


> On Oct 25, 2013, at 17:10, "Remco Bressers" <remco at signet.nl> wrote:
> 
>> On 10/25/2013 11:55 AM, Nikolay Shopik wrote:
>> Hey, anyone had issues with A9K-MPA-20X1GE in ASR9001?
> 
> Hi Nikolay,
> 
> We're using them without problems. What software are you running? I did
> have major issues with flapping onboard 10G ports disabling TX.
> 
> Regards,
> 
> Remco Bressers
> Signet B.V.
> 
> 
> 



From ahad at telcoinabox.com  Fri Oct 25 13:14:03 2013
From: ahad at telcoinabox.com (Ahad Aboss)
Date: Sat, 26 Oct 2013 00:14:03 +1100
Subject: A9K-MPA-20X1GE in ASR9001
In-Reply-To: <526A400E.2060309@inblock.ru>
References: <526A400E.2060309@inblock.ru>
Message-ID: <21F494CD-A2D6-4B81-9342-3F5B9CAB64F4@telcoinabox.com>

Have you tried a different IOS? 

Ahad

> On 25 Oct 2013, at 8:55 pm, Nikolay Shopik <shopik at inblock.ru> wrote:
> 
> Hey, anyone had issues with A9K-MPA-20X1GE in ASR9001?
> 
> It get disabled for us after 20 seconds finishing initialization, with
> such message.
> 
> %PLATFORM-SCC-2-BAD_ID_HW : Failed Identification Test in 0/130/0 [1/0]
> The module in 0/130/0 in this router may not be a genuineCisco product.
> 
> 


From shopik at inblock.ru  Fri Oct 25 13:21:19 2013
From: shopik at inblock.ru (Nikolay Shopik)
Date: Fri, 25 Oct 2013 17:21:19 +0400
Subject: A9K-MPA-20X1GE in ASR9001
In-Reply-To: <21F494CD-A2D6-4B81-9342-3F5B9CAB64F4@telcoinabox.com>
References: <526A400E.2060309@inblock.ru>
 <21F494CD-A2D6-4B81-9342-3F5B9CAB64F4@telcoinabox.com>
Message-ID: <526A704F.3030806@inblock.ru>

So far only 4.3.2 and 4.3.1. Probably gonna check it on 4.2 tree and
more recent 5.1

On 25/10/13 17:14, Ahad Aboss wrote:
> Have you tried a different IOS? 
> 
> Ahad
> 
>> On 25 Oct 2013, at 8:55 pm, Nikolay Shopik <shopik at inblock.ru> wrote:
>>
>> Hey, anyone had issues with A9K-MPA-20X1GE in ASR9001?
>>
>> It get disabled for us after 20 seconds finishing initialization, with
>> such message.
>>
>> %PLATFORM-SCC-2-BAD_ID_HW : Failed Identification Test in 0/130/0 [1/0]
>> The module in 0/130/0 in this router may not be a genuineCisco product.
>>
>>


From mcn4 at leicester.ac.uk  Fri Oct 25 13:26:02 2013
From: mcn4 at leicester.ac.uk (Matthew Newton)
Date: Fri, 25 Oct 2013 14:26:02 +0100
Subject: Network configuration archiving
In-Reply-To: <20131025122742.GM14735@Eleanor.local>
References: <20131024212526.GC14735@Eleanor.local>
 <20131025115948.GF10952@rootmail.cc.le.ac.uk>
 <20131025122742.GM14735@Eleanor.local>
Message-ID: <20131025132602.GK10952@rootmail.cc.le.ac.uk>

On Fri, Oct 25, 2013 at 02:27:42PM +0200, Job Snijders wrote:
> On Fri, Oct 25, 2013 at 12:59:48PM +0100, Matthew Newton wrote:
> 
> > I'll try and post the script (250 lines) somewhere if anyone's
> > interested.
> 
> It is almost always good to open source your tools, for others to learn
> and benefit from! :-)

As much as I totally agree with you, the problem is that if I
spent all my time publishing each small script I wrote, I'd never
have time to write small scripts :-)

I've removed local config details and pushed it up to github.
Hopefully there's enough info contained to enable someone else to
make use of it / learn from it / improve it.

https://github.com/mcnewton/cisco-config-backups

When I wrote that, neither git or scp to switches were available.
It's quite likely that there are at least two obvious improvements
that can be made.

Cheers,

Matthew



-- 
Matthew Newton, Ph.D. <mcn4 at le.ac.uk>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>


From bedard.phil at gmail.com  Fri Oct 25 14:22:07 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Fri, 25 Oct 2013 10:22:07 -0400
Subject: Network configuration archiving
In-Reply-To: <20131025123258.GA15815@pob.ytti.fi>
Message-ID: <CE8FF3F9.7BC81%bedard.phil@gmail.com>

There are companies like Tail-F who are trying to use things like YANG
definitions to dynamically build a standardized CLI which is sort of
cross-platform compatible.  The CLI you connect to is external to any
network equipment which records changes, does checking ahead of time, and
records atomic changes to the network.  The plugins underneath are there
to translate the common CLI to Junos/NETCONF/XR CLI etc.   This isn't a
new idea, tools like Opsware tried to do this in the past and at least one
provider I've worked for had their own common config language then
translated to real device configurations.

The idea is no one ever logs into a router to make a change, all changes
are recorded by the system making the change for you.  The same system
generally takes care of committing the config to device, handling errors
during provisioning, making sure configurations are synchronized between
it and the device, etc.

I'Ve been a couple places who had good home-grown RCS-based config
management systems I wish they would have open sourced.


-Phil






On 10/25/13 8:32 AM, "Saku Ytti" <saku at ytti.fi> wrote:

>On (2013-10-25 10:43 +0200), Martin Pels wrote:
>
>> The diff-ed backups that rancid provides serve another purpose:
>>verifying that
>> what your NMS says should be configured matches the actual device
>> configurations.
>
>Diffing one rancid config to another rancid config would not help with
>this at
>all.
>You'd need to diff provisiong system config to rancid config which is
>extremely complex problem, as your provisioning system is not creating
>'post
>parser' config, it's creating config in completely different way than
>what it
>will be after parser.
>
>The hard/wrong solution the problem is to have per-platform parsing
>intelligence reimplemented in your provisioning system.
>
>The two easy solutions are
>
>a) when your provisioning system pushes change out, it saves the config it
>sends, and then it views what route stored and makes note of them being
>the
>same. If it has this logic, then rancid is not needed.
>
>b) before your provisioning system pushes change out, it checks timestamp
>on
>config, if timestamp is newer than its latest config push, it regenerates
>full
>configuration. In this scenario also, rancid is not needed.
>
>
>
>However going 100% of config is in systems is not really something many
>target, nor have I seen good products for it. It's not actually hard
>problem,
>not even when targeting multiple platforms. As platform specific
>intelligence
>can be kept very low with some design choices.
>
>-- 
>  ++ytti
>




From woody at pch.net  Fri Oct 25 14:23:59 2013
From: woody at pch.net (Bill Woodcock)
Date: Fri, 25 Oct 2013 07:23:59 -0700
Subject: A9K-MPA-20X1GE in ASR9001
In-Reply-To: <526A704F.3030806@inblock.ru>
References: <526A400E.2060309@inblock.ru>
 <21F494CD-A2D6-4B81-9342-3F5B9CAB64F4@telcoinabox.com>
 <526A704F.3030806@inblock.ru>
Message-ID: <6DE86CAA-AF5D-4737-860A-CC730551D49A@pch.net>


On Oct 25, 2013, at 6:21 AM, Nikolay Shopik <shopik at inblock.ru> wrote:

> So far only 4.3.2 and 4.3.1. Probably gonna check it on 4.2 tree 

We're running 4.2.3.

                                -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/20131025/77e65529/attachment.bin>

From chip.gwyn at gmail.com  Fri Oct 25 14:40:36 2013
From: chip.gwyn at gmail.com (chip)
Date: Fri, 25 Oct 2013 10:40:36 -0400
Subject: Network configuration archiving
In-Reply-To: <CE8FF3F9.7BC81%bedard.phil@gmail.com>
References: <20131025123258.GA15815@pob.ytti.fi>
 <CE8FF3F9.7BC81%bedard.phil@gmail.com>
Message-ID: <CABGzhdsFbK69HZ3kWZVnKO9Kb=che8m4rABZbft4R0fEP8tnbQ@mail.gmail.com>

I've been intrigued by the stuff going on with NetKit and Autonetkit (
http://www.autonetkit.org).  See the preso from Pycon 2013 in Australia:
http://www.youtube.com/watch?v=EGK5jjyUBCQ

It seems like all the bits are available between the various efforts of
applications but nothing that really ties everything together.  I'll agree
with Phil that the most comprehensive I've seen is from Tail-F, as far as
off the shelf packages go.  The problem with this space is one of agility
and scale.  If you have only a handful of pieces of gear, all different
platforms, it's tough to get a system going that implements policy the way
you want or need.  It's also difficult to be agile and implement new
platforms or capabilities without lots of work.  If you have hundreds of
routers it makes sense to put forth the effort but then becomes difficult
to keep up with moves/add/changes with individual elements.  A strict and
rigorous change management process can help keep running config in sync
with offline systems but can be difficult to manage in the heat of the
moment while troubleshooting.  I think this is some of the hope of "SDN",
build standard ways of implementing config and policy that are consistent,
easy to manage, yet agile, and comprehensive.  However, I think it will be
difficult to find a One Size Fits All application.  Perhaps there can be
some common enough ground where network kit implementation becomes as
ubiquitous as system implementations.

--chip


On Fri, Oct 25, 2013 at 10:22 AM, Phil Bedard <bedard.phil at gmail.com> wrote:

> There are companies like Tail-F who are trying to use things like YANG
> definitions to dynamically build a standardized CLI which is sort of
> cross-platform compatible.  The CLI you connect to is external to any
> network equipment which records changes, does checking ahead of time, and
> records atomic changes to the network.  The plugins underneath are there
> to translate the common CLI to Junos/NETCONF/XR CLI etc.   This isn't a
> new idea, tools like Opsware tried to do this in the past and at least one
> provider I've worked for had their own common config language then
> translated to real device configurations.
>
> The idea is no one ever logs into a router to make a change, all changes
> are recorded by the system making the change for you.  The same system
> generally takes care of committing the config to device, handling errors
> during provisioning, making sure configurations are synchronized between
> it and the device, etc.
>
> I'Ve been a couple places who had good home-grown RCS-based config
> management systems I wish they would have open sourced.
>
>
> -Phil
>
>
>
>
>
>
> On 10/25/13 8:32 AM, "Saku Ytti" <saku at ytti.fi> wrote:
>
> >On (2013-10-25 10:43 +0200), Martin Pels wrote:
> >
> >> The diff-ed backups that rancid provides serve another purpose:
> >>verifying that
> >> what your NMS says should be configured matches the actual device
> >> configurations.
> >
> >Diffing one rancid config to another rancid config would not help with
> >this at
> >all.
> >You'd need to diff provisiong system config to rancid config which is
> >extremely complex problem, as your provisioning system is not creating
> >'post
> >parser' config, it's creating config in completely different way than
> >what it
> >will be after parser.
> >
> >The hard/wrong solution the problem is to have per-platform parsing
> >intelligence reimplemented in your provisioning system.
> >
> >The two easy solutions are
> >
> >a) when your provisioning system pushes change out, it saves the config it
> >sends, and then it views what route stored and makes note of them being
> >the
> >same. If it has this logic, then rancid is not needed.
> >
> >b) before your provisioning system pushes change out, it checks timestamp
> >on
> >config, if timestamp is newer than its latest config push, it regenerates
> >full
> >configuration. In this scenario also, rancid is not needed.
> >
> >
> >
> >However going 100% of config is in systems is not really something many
> >target, nor have I seen good products for it. It's not actually hard
> >problem,
> >not even when targeting multiple platforms. As platform specific
> >intelligence
> >can be kept very low with some design choices.
> >
> >--
> >  ++ytti
> >
>
>
>
>


-- 
Just my $.02, your mileage may vary,  batteries not included, etc....

From woody at pch.net  Fri Oct 25 14:43:08 2013
From: woody at pch.net (Bill Woodcock)
Date: Fri, 25 Oct 2013 07:43:08 -0700
Subject: A9K-MPA-20X1GE in ASR9001
In-Reply-To: <6DE86CAA-AF5D-4737-860A-CC730551D49A@pch.net>
References: <526A400E.2060309@inblock.ru>
 <21F494CD-A2D6-4B81-9342-3F5B9CAB64F4@telcoinabox.com>
 <526A704F.3030806@inblock.ru> <6DE86CAA-AF5D-4737-860A-CC730551D49A@pch.net>
Message-ID: <7224D5C9-F9A3-49B7-9FAF-5A8F20B44C53@pch.net>


On Oct 25, 2013, at 7:23 AM, Bill Woodcock <woody at pch.net> wrote:

> 
> On Oct 25, 2013, at 6:21 AM, Nikolay Shopik <shopik at inblock.ru> wrote:
> 
>> So far only 4.3.2 and 4.3.1. Probably gonna check it on 4.2 tree 
> 
> We're running 4.2.3.

Sorry for the multiple posts?  We're also running 4.3.0 with the combination successfully.

> router.nrt.woodynet.net:!Image:     Boot Image: /disk0/asr9k-os-mbi-4.3.0/0x100000/mbiasr9k-rp.vm
> router.nrt.woodynet.net:!Image:     Boot Image: /disk0/asr9k-os-mbi-4.3.0/lc/mbiasr9k-lc.vm
> router.jnb.woodynet.net:!Image:     Boot Image: /disk0/asr9k-os-mbi-4.2.3/0x100000/mbiasr9k-rp.vm
> router.jnb.woodynet.net:!Image:     Boot Image: /disk0/asr9k-os-mbi-4.2.3/lc/mbiasr9k-lc.vm
> 
> We have this command on the interfaces as well:
> 
> transceiver permit pid all

?which was necessary to get it to support 1gb SFPs, in addition to the 10gb SFP+ transceivers.

                                -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/20131025/779c5f40/attachment.bin>

From saku at ytti.fi  Fri Oct 25 15:03:06 2013
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 25 Oct 2013 18:03:06 +0300
Subject: Network configuration archiving
In-Reply-To: <CE8FF3F9.7BC81%bedard.phil@gmail.com>
References: <20131025123258.GA15815@pob.ytti.fi>
 <CE8FF3F9.7BC81%bedard.phil@gmail.com>
Message-ID: <20131025150306.GA6241@pob.ytti.fi>

On (2013-10-25 10:22 -0400), Phil Bedard wrote:

> There are companies like Tail-F who are trying to use things like YANG

Tail-F is very cool, but it needs support for both direction.

Abstract data -> Vendor Config    (easy problem, just agnostic ascii template)
Vendor Config -> Abstract data    (hard problem)

I don't think the latter is needed, why verify what is wrong in the config,
either it is what you want it to be or it's something else, in which case you
make it what you want it to be.
The price of knowing exactly what to fix to bring it up-to standard is very
high. It's definitely nice thing to have and necessary thing to have unless
100% is from system.
If 100% is from system, we can ommit the hard problem. To support new vendor,
you just write simple new vendor-specific templates focusing on exactly just
the subset of stuff your abstract data needs. Instead if you need to
understand vendor config, you need to understand every nyance of it, vendors
own parser gets it wrong, my chances are very small to get it right.


-- 
  ++ytti


From ray at oneunified.net  Fri Oct 25 15:15:07 2013
From: ray at oneunified.net (Raymond Burkholder)
Date: Fri, 25 Oct 2013 12:15:07 -0300
Subject: Network configuration archiving
In-Reply-To: <20131024212526.GC14735@Eleanor.local>
References: <20131024212526.GC14735@Eleanor.local>
Message-ID: <019d01ced195$003e7ab0$00bb7010$@oneunified.net>

> I am unsure what we as networkers have done in the past, but I am sure
> we've done our fair share of atonement and don't have to keep using
> RANCID.

Some people in this thread have been mentioning config generators.  There is
/ was something called netomata.  A web search brings up various references,
but their main web site appears to be offline.   Tweets stopped back in '10,
freecode.com's last submission is Jan 2011, so I don't know if they are
still alive.  But seemed like an interesting tool then.

> 
> Some might say "it took ages to get rancid to do kinda what we want!",
> but not all software ages well. One might work in environments where
> archived configurations are needed to even start provisioning, one
> might desire a separation between actual config and transcient data.
> 
> As I am evaluating our path forward, I've compiled a small list of open
> source projects with some biased highlights. Your feedback is most
> welcome, maybe I missed some interesting projects or developments. I
> would also be very interested in what other operators seek in a network
> config/state archive tool.
> 
> RANCID - http://www.shrubbery.net/rancid/
>     * Support for a wild variery of devices and operating systems
>     * complex perl code base [1]
>     * no central developer team, the internet is littered with forks
> 
> Oxidized - https://github.com/ytti/oxidized
>     * modern & sexy approach with queue & workers
>     * RESTful API (example: can bump devices to the head of the queue)
>     * small user & developer base
>     * written in that ruby language
> 
> Gerty - https://github.com/ssinyagin/gerty
>     * Seems easier to extend than RANCID
>     * perl...
>     * small user & developer base
> 
> punc - https://code.google.com/p/punc/
>     * written in python, based on notch [2]
>     * no recent developments (although 2011 was a good wine year)
> 
> [1] - http://honestnetworker.wordpress.com/2013/06/28/adding-new-
> device-support-to-rancid/
> [2] - https://code.google.com/p/notch/
> 
> Kind regards,
> 
> Job



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From shrdlu at deaddrop.org  Fri Oct 25 15:45:40 2013
From: shrdlu at deaddrop.org (Shrdlu)
Date: Fri, 25 Oct 2013 08:45:40 -0700
Subject: If you're on LinkedIn, and you use a smart phone...
Message-ID: <526A9224.1050608@deaddrop.org>

I hate to do this, but it's something that anyone managing email
servers (or just using a smart phone to update LI) needs to know
about. I just saw this on another list I'm on, and I know that there
are folks on NANOG that are on LinkedIn.

++++++++++
http://www.bishopfox.com/blog/2013/10/linkedin-intro/

LinkedIn released a new product today called Intro.  They call it
?doing the impossible?, but some might call it ?hijacking email?.
Why do we say this?  Consider the following:

Intro reconfigures your iOS device (e.g. iPhone, iPad) so that all of
your emails go through LinkedIn?s servers. You read that right. Once
you install the Intro app, all of your emails, both sent and received,
are transmitted via LinkedIn?s servers. LinkedIn is forcing all your
IMAP and SMTP data through their own servers and then analyzing and
scraping your emails for data pertaining to?whatever they feel like.

++++++++++

Read the full article. If you're using LI via your smart phone, and
you have already installed this app, you probably need to save off
your contacts and data, and wipe the phone. I wouldn't trust
uninstalling as enough, myself. In the long run, I'll be deleting my
account.

No, I don't use a smart phone to update any social media. No, I
especially do not trust LI (never have, never will). BTW, they're
currently adding back any contacts you've deleted. Thanks for
reminding me that Joe Barr, Len Sassaman, and Jay D Dyson are gone
from this world.

-- 
Life may not be the party we hoped for, but while we are here,
we might as well dance.



From nanog at shankland.org  Fri Oct 25 16:46:12 2013
From: nanog at shankland.org (Jim Shankland)
Date: Fri, 25 Oct 2013 09:46:12 -0700
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <526A9224.1050608@deaddrop.org>
References: <526A9224.1050608@deaddrop.org>
Message-ID: <526AA054.1000608@shankland.org>

Well, this concerned me at first, but then I read the description of how 
it's done 
(http://engineering.linkedin.com/mobile/linkedin-intro-doing-impossible-ios):

     We understand that operating an email proxy server carries great 
responsibility.
     We respect the fact that your email may contain very personal or 
sensitive
     information, and we will do everything we can to make sure that it 
is safe.

I find this completely reassuring.  I'd expand on that, but I have to go 
buy a used car now.

Jim Shankland


From network.ipdog at gmail.com  Fri Oct 25 16:59:40 2013
From: network.ipdog at gmail.com (Network IPdog)
Date: Fri, 25 Oct 2013 09:59:40 -0700
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <526AA054.1000608@shankland.org>
References: <526A9224.1050608@deaddrop.org> <526AA054.1000608@shankland.org>
Message-ID: <526aa37f.669c420a.3e68.ffffcdea@mx.google.com>

Also... 

I got some sand in the desert for sale... act now I even throw in some
alligators

This is a limited time offer too...

Operators are standing by...


Ruff, Ruff...!

Network IPdog

Ephesians 4:32  &  Cheers!!!

A password is like a... toothbrush  ;^) 
Choose a good one, change it regularly and don't share it.

-----Original Message-----
From: Jim Shankland [mailto:nanog at shankland.org] 
Sent: Friday, October 25, 2013 9:46 AM
To: nanog at nanog.org
Subject: Re: If you're on LinkedIn, and you use a smart phone...

Well, this concerned me at first, but then I read the description of how
it's done
(http://engineering.linkedin.com/mobile/linkedin-intro-doing-impossible-ios)
:

     We understand that operating an email proxy server carries great
responsibility.
     We respect the fact that your email may contain very personal or
sensitive
     information, and we will do everything we can to make sure that it is
safe.

I find this completely reassuring.  I'd expand on that, but I have to go buy
a used car now.

Jim Shankland



From AOsgood at Streamline-Solutions.net  Fri Oct 25 17:11:15 2013
From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood)
Date: Fri, 25 Oct 2013 13:11:15 -0400
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <526aa37f.669c420a.3e68.ffffcdea@mx.google.com>
References: <526A9224.1050608@deaddrop.org> <526AA054.1000608@shankland.org>
 <526aa37f.669c420a.3e68.ffffcdea@mx.google.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAFN+bXeiy2tHkjqcwxxSmQPCgAAAEAAAAH62lpu+UhBJhnCupwdQZ1gBAAAAAA==@Streamline-Solutions.net>

"Here is the view from your new homesite...."


Aaron D. Osgood 

Streamline Solutions L.L.C

P.O. Box 6115
Falmouth, ME 04105

TEL: 207-781-5561
MOBILE: 207-831-5829
ICQ: 206889374
GVoice: 207.518.8455
GTalk: aaron.osgood
AOsgood at Streamline-Solutions.net
http://www.streamline-solutions.net

Introducing Efficiency to Business since 1986. 




-----Original Message-----
From: Network IPdog [mailto:network.ipdog at gmail.com] 
Sent: Friday, October 25, 2013 1:00 PM
To: 'Jim Shankland'; nanog at nanog.org
Subject: RE: If you're on LinkedIn, and you use a smart phone...

Also... 

I got some sand in the desert for sale... act now I even throw in some
alligators

This is a limited time offer too...

Operators are standing by...


Ruff, Ruff...!

Network IPdog

Ephesians 4:32  &  Cheers!!!

A password is like a... toothbrush  ;^) Choose a good one, change it
regularly and don't share it.

-----Original Message-----
From: Jim Shankland [mailto:nanog at shankland.org]
Sent: Friday, October 25, 2013 9:46 AM
To: nanog at nanog.org
Subject: Re: If you're on LinkedIn, and you use a smart phone...

Well, this concerned me at first, but then I read the description of how
it's done
(http://engineering.linkedin.com/mobile/linkedin-intro-doing-impossible-ios)
:

     We understand that operating an email proxy server carries great
responsibility.
     We respect the fact that your email may contain very personal or
sensitive
     information, and we will do everything we can to make sure that it is
safe.

I find this completely reassuring.  I'd expand on that, but I have to go buy
a used car now.

Jim Shankland





From alumbis at gmail.com  Fri Oct 25 18:01:44 2013
From: alumbis at gmail.com (Pete Lumbis)
Date: Fri, 25 Oct 2013 14:01:44 -0400
Subject: BGP failure analysis and recommendations
In-Reply-To: <5.1.0.14.0.20131023214304.0396ead0@authsmtp.jensenresearch.com>
References: <5.1.0.14.0.20131023214304.0396ead0@authsmtp.jensenresearch.com>
Message-ID: <CAB0xJrNQu+tZ8eAs29bcA5Y3gnk5coRdYmsDvZB-wj5G0Nf3pQ@mail.gmail.com>

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/SB10001424052702304864504579145813698584246>
>>>>
>>>> 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 cscora at apnic.net  Fri Oct 25 18:07:08 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 26 Oct 2013 04:07:08 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201310251807.r9PI782R012123@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 26 Oct, 2013

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

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

BGP routing table entries examined:                              470253
    Prefixes after maximum aggregation:                          189267
    Deaggregation factor:                                          2.48
    Unique aggregates announced to Internet:                     233307
Total ASes present in the Internet Routing Table:                 41263
    Prefixes per ASN:                                             11.40
Origin-only ASes present in the Internet Routing Table:           35299
Origin ASes announcing only one prefix:                           16281
Transit ASes present in the Internet Routing Table:                5957
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:               713
    Unregistered ASNs in the Routing Table:                         192
Number of 32-bit ASNs allocated by the RIRs:                       5249
Number of 32-bit ASNs visible in the Routing Table:                   7
Prefixes from 32-bit ASNs in the Routing Table:                   12489
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            847
Number of addresses announced to Internet:                   2652267476
    Equivalent to 158 /8s, 22 /16s and 99 /24s
    Percentage of available address space announced:               71.6
    Percentage of allocated address space announced:               71.6
    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:      164267

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

Prefixes being announced by APNIC Region ASes:                   111549
    Total APNIC prefixes after maximum aggregation:               33829
    APNIC Deaggregation factor:                                    3.30
Prefixes being announced from the APNIC address blocks:          113639
    Unique aggregates announced from the APNIC address blocks:    46970
APNIC Region origin ASes present in the Internet Routing Table:    4880
    APNIC Prefixes per ASN:                                       23.29
APNIC Region origin ASes announcing only one prefix:               1218
APNIC Region transit ASes present in the Internet Routing Table:    839
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:      1
Number of APNIC addresses announced to Internet:              729582016
    Equivalent to 43 /8s, 124 /16s and 137 /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:                    162893
    Total ARIN prefixes after maximum aggregation:                81514
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           163685
    Unique aggregates announced from the ARIN address blocks:     75962
ARIN Region origin ASes present in the Internet Routing Table:    15905
    ARIN Prefixes per ASN:                                        10.29
ARIN Region origin ASes announcing only one prefix:                6003
ARIN Region transit ASes present in the Internet Routing Table:    1670
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:       2
Number of ARIN addresses announced to Internet:              1073475200
    Equivalent to 63 /8s, 251 /16s and 238 /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:                    118701
    Total RIPE prefixes after maximum aggregation:                61311
    RIPE Deaggregation factor:                                     1.94
Prefixes being announced from the RIPE address blocks:           122310
    Unique aggregates announced from the RIPE address blocks:     78965
RIPE Region origin ASes present in the Internet Routing Table:    17512
    RIPE Prefixes per ASN:                                         6.98
RIPE Region origin ASes announcing only one prefix:                8301
RIPE Region transit ASes present in the Internet Routing Table:    2841
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:       1
Number of RIPE addresses announced to Internet:               656716388
    Equivalent to 39 /8s, 36 /16s and 178 /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:                   52444
    Total LACNIC prefixes after maximum aggregation:               9927
    LACNIC Deaggregation factor:                                   5.28
Prefixes being announced from the LACNIC address blocks:          57512
    Unique aggregates announced from the LACNIC address blocks:   26693
LACNIC Region origin ASes present in the Internet Routing Table:   2040
    LACNIC Prefixes per ASN:                                      28.19
LACNIC Region origin ASes announcing only one prefix:               560
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:     2
Number of LACNIC addresses announced to Internet:             141095728
    Equivalent to 8 /8s, 104 /16s and 243 /24s
    Percentage of available LACNIC address space announced:        84.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:                  11607
    Total AfriNIC prefixes after maximum aggregation:              2559
    AfriNIC Deaggregation factor:                                  4.54
Prefixes being announced from the AfriNIC address blocks:         12260
    Unique aggregates announced from the AfriNIC address blocks:   4004
AfriNIC Region origin ASes present in the Internet Routing Table:   667
    AfriNIC Prefixes per ASN:                                     18.38
AfriNIC Region origin ASes announcing only one prefix:              199
AfriNIC Region transit ASes present in the Internet Routing Table:  136
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:    1
Number of AfriNIC addresses announced to Internet:             48076544
    Equivalent to 2 /8s, 221 /16s and 151 /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     2938      11558         943   Korea Telecom (KIX)
17974     2717        903          89   PT TELEKOMUNIKASI INDONESIA
 7545     2095        319         112   TPG Internet Pty Ltd
 4755     1782        391         187   TATA Communications formerly 
 9829     1557       1241          45   BSNL National Internet Backbo
 9498     1206        309          74   BHARTI Airtel Ltd.
 9583     1187         90         513   Sify Limited
 4808     1164       2127         341   CNCGROUP IP network: China169
 7552     1156       1080          13   Vietel Corporation
24560     1091        380         164   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     3062       3689          58   BellSouth.net Inc.
22773     2185       2941         139   Cox Communications, Inc.
18566     2059        379         180   Covad Communications 
 1785     2035        684         130   PaeTec Communications, Inc.
20115     1682       1653         613   Charter Communications 
 4323     1615       1101         417   Time Warner Telecom
  701     1509      11145         784   UUNET Technologies, Inc. 
30036     1387        313         577   Mediacom Communications Corp 
 7018     1336      17778         865   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     1839        544          17   OJSC "Vimpelcom"
34984     1361        244         223   TELLCOM ILETISIM HIZMETLERI A
20940     1081        394         828   Akamai Technologies European 
31148     1000         44          19   FreeNet ISP
13188      885         99          58   TOV "Bank-Inform"
 6830      770       2327         423   UPC Distribution Services
 8551      755        370          41   Bezeq International
12479      686        800          49   Uni2 Autonomous System
35228      542        246          16   Avatar Broadband Limited
34744      515        158          54   SC GVM SISTEM 2003 SRL

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     3451       1780          88   NET Servicos de Comunicao S.A
10620     2610        424         240   TVCABLE BOGOTA 
 7303     1725       1135         234   Telecom Argentina Stet-France
18881     1486        844          20   Global Village Telecom 
 8151     1348       2827         417   UniNet S.A. de C.V. 
11830      865        364          15   Instituto Costarricense de El
27947      843         93          92   Telconet S.A
 6147      789        373          27   Telefonica Del Peru 
 6503      788        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      882        338          30   LINKdotNET AS number
 6713      554        633          26   Itissalat Al-MAGHRIB
 8452      409        956           9   TEDATA
24835      294        144           9   RAYA Telecom - Egypt
 3741      258        921         216   The Internet Solution 
36992      226        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     3451       1780          88   NET Servicos de Comunicao S.A
 6389     3062       3689          58   BellSouth.net Inc.
 4766     2938      11558         943   Korea Telecom (KIX)
17974     2717        903          89   PT TELEKOMUNIKASI INDONESIA
10620     2610        424         240   TVCABLE BOGOTA 
22773     2185       2941         139   Cox Communications, Inc.
 7545     2095        319         112   TPG Internet Pty Ltd
18566     2059        379         180   Covad Communications 
 1785     2035        684         130   PaeTec Communications, Inc.
36998     1864        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      3062        3004      BellSouth.net Inc.
17974      2717        2628      PT TELEKOMUNIKASI INDONESIA
10620      2610        2370      TVCABLE BOGOTA 
22773      2185        2046      Cox Communications, Inc.
 4766      2938        1995      Korea Telecom (KIX)
 7545      2095        1983      TPG Internet Pty Ltd
 1785      2035        1905      PaeTec Communications, Inc.
18566      2059        1879      Covad Communications 
36998      1864        1859      Sudanese Mobile Telephone (ZA
 8402      1839        1822      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 
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
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.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
23.91.164.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:480     /14:917     /15:1630    /16:12844   /17:6719    /18:11266   
/19:22958   /20:32707   /21:35361   /22:49971   /23:43374   /24:249130  
/25:871     /26:990     /27:469     /28:50      /29:79      /30:20      
/31:0       /32:14      

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

  ASN   No of nets  Total ann.   Description
18566     2012          2059      Covad Communications 
36998     1829          1864      Sudanese Mobile Telephone (ZA
 6389     1712          3062      BellSouth.net Inc.
 8402     1535          1839      OJSC "Vimpelcom"
22773     1451          2185      Cox Communications, Inc.
30036     1235          1387      Mediacom Communications Corp 
11492     1197          1238      Cable One 
 1785     1085          2035      PaeTec Communications, Inc.
 6983     1034          1293      ITC^Deltacom 
22561      965          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:857       2:820       3:3         4:17        5:999       6:20     
   8:614      12:1888     13:3        14:884      15:11       16:3      
  17:17       18:19       20:21       23:498      24:1736     27:1604   
  31:1484     32:45       33:2        34:5        36:82       37:1841   
  38:920      39:4        40:181      41:3171     42:248      44:14     
  46:2031     47:7        49:681      50:837      52:12       54:39     
  55:6        56:2        57:26       58:1154     59:576      60:359    
  61:1473     62:1205     63:1979     64:4559     65:2340     66:4138   
  67:2116     68:1099     69:3291     70:877      71:491      72:2021   
  74:2566     75:328      76:309      77:1167     78:1074     79:656    
  80:1291     81:1015     82:657      83:635      84:590      85:1241   
  86:415      87:1009     88:563      89:1661     90:155      91:5658   
  92:618      93:1596     94:2037     95:1597     96:508      97:344    
  98:1048     99:42      100:31      101:613     103:3481    105:525    
 106:143     107:213     108:526     109:1912    110:974     111:1098   
 112:590     113:809     114:751     115:1035    116:990     117:838    
 118:1174    119:1294    120:372     121:745     122:1875    123:1252   
 124:1369    125:1434    128:647     129:237     130:328     131:661    
 132:348     133:158     134:545     135:67      136:278     137:268    
 138:351     139:176     140:203     141:334     142:544     143:420    
 144:501     145:89      146:519     147:405     148:767     149:356    
 150:142     151:592     152:410     153:205     154:49      155:486    
 156:286     157:424     158:282     159:768     160:356     161:483    
 162:805     163:227     164:634     165:574     166:256     167:624    
 168:1045    169:128     170:1122    171:181     172:25      173:1607   
 174:682     175:510     176:1275    177:2328    178:1947    179:195    
 180:1579    181:779     182:1341    183:454     184:661     185:951    
 186:2651    187:1502    188:1861    189:1290    190:7194    192:7111   
 193:5408    194:4040    195:3319    196:1321    197:1027    198:4744   
 199:5483    200:6106    201:2524    202:8974    203:8914    204:4517   
 205:2639    206:2836    207:2894    208:3983    209:3639    210:3012   
 211:1563    212:2140    213:1977    214:894     215:91      216:5402   
 217:1691    218:622     219:317     220:1275    221:566     222:326    
 223:508    

End of report


From nanog at rsle.net  Fri Oct 25 18:17:24 2013
From: nanog at rsle.net (R. Scott Evans)
Date: Fri, 25 Oct 2013 14:17:24 -0400
Subject: Network configuration archiving
In-Reply-To: <20131025115948.GF10952@rootmail.cc.le.ac.uk>
References: <20131024212526.GC14735@Eleanor.local>
 <20131025115948.GF10952@rootmail.cc.le.ac.uk>
Message-ID: <526AB5B4.4030801@rsle.net>

On 10/25/13 07:59, Matthew Newton wrote:
> For the last ~8 years we've used a very simple in-house bash
> script that uses SNMP to tell the switch to write its config using
> tftp, and then does a wr mem. It then checks the configs into a
> subversion repository and e-mails out any diffs.
>
> One criteria we had was that our config backup system wasn't going
> to get CLI access to any routers if at all possible, and this
> turned out to be a good alternative. I can't think of many times
> when it's failed to work; occasionally the odd switch might not
> respond, but that's rare.
>
> The only possible issue being that we're 100% Cisco, so I don't
> know if other vendors support the same MIBs.
>
> I'll try and post the script (250 lines) somewhere if anyone's
> interested.
>
> Cheers,
>
> Matthew

I have a very similar home-grown script, however I did need a mix of 
tftp and telnet/CLI depending on the particular platform (for instance 
recently I couldn't get the tftp approach to work with remote devices 
running IOS-XR or IOS-XE).

An overly simplified telnet module might look like:
-----------------------
#!/bin/sh
login=""
passwd=""
router=""
timeout=1		# increase this for larger configs

(sleep 1;
         echo $login;            sleep 1;
         echo $passwd;           sleep 1;
         echo term leng 0;       sleep 1;
         echo "sh run";          sleep $timeout;
         echo exit;              sleep 1;
) | telnet $router 2>&1
-----------------------

-Scott



From bedard.phil at gmail.com  Fri Oct 25 18:27:35 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Fri, 25 Oct 2013 14:27:35 -0400
Subject: Network configuration archiving
In-Reply-To: <20131025150306.GA6241@pob.ytti.fi>
Message-ID: <CE902D29.7BD9E%bedard.phil@gmail.com>

The vendor config->abstract data (really structured data) is the point of
YANG definitions.  I think I'm correct but Tail-F's system works by
importing the YANG definitions from the router and it builds the CLI
interpreter based on those definitions.  The trick is getting the
standards bodies and vendors to support common definitions for common
protocols like they sorta have with SNMP.  So when I need to put a route
on a router it's the same common definition and I guess the pie in the sky
goal is then using common NETCONF syntax as well to do the configuration.
So the router itself is doing the translation into whatever native format
it uses, not someone having to write translation scripts which are a PITA
when vendor syntax changes, or some new feature is added, etc.


Phil 

On 10/25/13 11:03 AM, "Saku Ytti" <saku at ytti.fi> wrote:

>On (2013-10-25 10:22 -0400), Phil Bedard wrote:
>
>> There are companies like Tail-F who are trying to use things like YANG
>
>Tail-F is very cool, but it needs support for both direction.
>
>Abstract data -> Vendor Config    (easy problem, just agnostic ascii
>template)
>Vendor Config -> Abstract data    (hard problem)
>
>I don't think the latter is needed, why verify what is wrong in the
>config,
>either it is what you want it to be or it's something else, in which case
>you
>make it what you want it to be.
>The price of knowing exactly what to fix to bring it up-to standard is
>very
>high. It's definitely nice thing to have and necessary thing to have
>unless
>100% is from system.
>If 100% is from system, we can ommit the hard problem. To support new
>vendor,
>you just write simple new vendor-specific templates focusing on exactly
>just
>the subset of stuff your abstract data needs. Instead if you need to
>understand vendor config, you need to understand every nyance of it,
>vendors
>own parser gets it wrong, my chances are very small to get it right.
>
>
>-- 
>  ++ytti
>




From saku at ytti.fi  Fri Oct 25 20:02:15 2013
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 25 Oct 2013 23:02:15 +0300
Subject: Network configuration archiving
In-Reply-To: <CE902D29.7BD9E%bedard.phil@gmail.com>
References: <20131025150306.GA6241@pob.ytti.fi>
 <CE902D29.7BD9E%bedard.phil@gmail.com>
Message-ID: <20131025200215.GA13021@pob.ytti.fi>

On (2013-10-25 14:27 -0400), Phil Bedard wrote:

> The vendor config->abstract data (really structured data) is the point of
> YANG definitions.  I think I'm correct but Tail-F's system works by

> interpreter based on those definitions.  The trick is getting the
> standards bodies and vendors to support common definitions for common
> protocols like they sorta have with SNMP.  So when I need to put a route

The idea is great, but I don't feel it's actually practical. Since already MIB
standards lag features and getting MIB into vendor code lags further.
So if you would only limit yourself deploying stuff that all your vendors
support via common standard model like YANG, you'd be in clear competitive
disadvantage in launching products.

If you can avoid doing VendorConfig -> Abstract (Or structured as you say)
Data. Things get just so much simpler.

-- 
  ++ytti


From cidr-report at potaroo.net  Fri Oct 25 22:00:01 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 25 Oct 2013 22:00:01 GMT
Subject: The Cidr Report
Message-ID: <201310252200.r9PM01DY068059@wattle.apnic.net>

This report has been generated at Fri Oct 25 21:15:16 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
        18-10-13    480627      273019
        19-10-13    481077      273120
        20-10-13    481006      272895
        21-10-13    481290      272862
        22-10-13    481091      273093
        23-10-13    481149      273457
        24-10-13    481168      273526
        25-10-13    481005      273752


AS Summary
         45446  Number of ASes in routing system
         18670  Number of ASes announcing only one prefix
          4190  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      118197248  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').

 --- 25Oct13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     481219   273777   207442    43.1%   All ASes

AS6389      3059       61     2998    98.0%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS28573     3459      480     2979    86.1%   NET Servi?os de Comunica??o
                                               S.A.
AS17974     2716      101     2615    96.3%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS7029      4190     1860     2330    55.6%   WINDSTREAM - Windstream
                                               Communications Inc
AS4766      2938      951     1987    67.6%   KIXS-AS-KR Korea Telecom
AS10620     2633     1036     1597    60.7%   Telmex Colombia S.A.
AS18566     2059      568     1491    72.4%   MEGAPATH5-US - MegaPath
                                               Corporation
AS36998     1864      375     1489    79.9%   SDN-MOBITEL
AS4323      2949     1535     1414    47.9%   TWTC - tw telecom holdings,
                                               inc.
AS7303      1725      467     1258    72.9%   Telecom Argentina S.A.
AS1785      2035      818     1217    59.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1782      579     1203    67.5%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1189      136     1053    88.6%   VIETEL-AS-AP Vietel
                                               Corporation
AS18881     1490      461     1029    69.1%   Global Village Telecom
AS22561     1241      217     1024    82.5%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS22773     2188     1360      828    37.8%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS35908      907       88      819    90.3%   VPLSNET - Krypt Technologies
AS7545      2097     1283      814    38.8%   TPG-INTERNET-AP TPG Telecom
                                               Limited
AS18101      980      180      800    81.6%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4808      1164      403      761    65.4%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS24560     1091      366      725    66.5%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS701       1510      787      723    47.9%   UUNET - MCI Communications
                                               Services, Inc. d/b/a Verizon
                                               Business
AS8402      1806     1095      711    39.4%   CORBINA-AS OJSC "Vimpelcom"
AS13977      854      143      711    83.3%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS6983      1292      583      709    54.9%   ITCDELTA - ITC^Deltacom
AS8151      1354      645      709    52.4%   Uninet S.A. de C.V.
AS4780      1001      315      686    68.5%   SEEDNET Digital United Inc.
AS6147       789      108      681    86.3%   Telefonica del Peru S.A.A.
AS855        725       55      670    92.4%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS7738       780      142      638    81.8%   Telemar Norte Leste S.A.

Total      53867    17198    36669    68.1%   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.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.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.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.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
        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.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.199.250.0/24      AS5617  TPNET Telekomunikacja Polska S.A.
        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.252.100.0/23     AS23756 PADINET-AS-ID PADINET - Padi Internet
        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
        120.136.17.0/24      AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika
        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
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        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.
        185.38.220.0/22      AS56523 AMELEKTRONIK Marek Michalkiewicz
        185.38.220.0/24      AS56523 AMELEKTRONIK Marek Michalkiewicz
        185.38.221.0/24      AS56523 AMELEKTRONIK Marek Michalkiewicz
        185.38.222.0/24      AS56523 AMELEKTRONIK Marek Michalkiewicz
        185.38.223.0/24      AS56523 AMELEKTRONIK Marek Michalkiewicz
        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 
        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
        201.131.97.0/24      AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich
        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.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.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.225.0/24      AS3549  GBLX Global Crossing Ltd.
        208.66.227.0/24      AS3549  GBLX Global Crossing Ltd.
        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.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
        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.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        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.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 Oct 25 22:00:01 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 25 Oct 2013 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201310252200.r9PM01ff068074@wattle.apnic.net>

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

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS30693          131601  6.3%     239.7 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 2 - AS9829            41233  2.0%      45.2 -- BSNL-NIB National Internet Backbone
 3 - AS8402            32614  1.6%      58.1 -- CORBINA-AS OJSC "Vimpelcom"
 4 - AS10620           30272  1.4%      19.0 -- Telmex Colombia S.A.
 5 - AS28573           22825  1.1%       7.1 -- NET Servi?os de Comunica??o S.A.
 6 - AS13118           22384  1.1%     486.6 -- ASN-YARTELECOM OJSC Rostelecom
 7 - AS29990           19230  0.9%    6410.0 -- ASN-APPNEXUS - AppNexus, Inc
 8 - AS6849            16565  0.8%      18.6 -- UKRTELNET JSC UKRTELECOM,
 9 - AS4775            16545  0.8%     246.9 -- GLOBE-TELECOM-AS Globe Telecoms
10 - AS7552            16305  0.8%      13.1 -- VIETEL-AS-AP Vietel Corporation
11 - AS29049           12856  0.6%      38.4 -- DELTA-TELECOM-AS Delta Telecom LTD.
12 - AS15808           12811  0.6%     457.5 -- ACCESSKENYA-KE ACCESSKENYA GROUP LTD is an ISP serving
13 - AS15003           12405  0.6%      31.4 -- NOBIS-TECH - Nobis Technology Group, LLC
14 - AS11976           12159  0.6%     193.0 -- FIDN - Fidelity Communication International Inc.
15 - AS4538            11828  0.6%      21.8 -- ERX-CERNET-BKB China Education and Research Network Center
16 - AS9583            11697  0.6%      10.2 -- SIFY-AS-IN Sify Limited
17 - AS17974           11431  0.6%       4.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
18 - AS4434            11023  0.5%     256.3 -- ERX-RADNET1-AS PT Rahajasa Media Internet
19 - AS5487            10067  0.5%    1438.1 -- Elisa Oyj
20 - AS42334            9676  0.5%     569.2 -- BBP-AS Broadband Plus s.a.l.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS6629             9330  0.5%    9330.0 -- NOAA-AS - NOAA
 2 - AS54465            9023  0.4%    9023.0 -- QPM-AS-1 - QuickPlay Media Inc.
 3 - AS29990           19230  0.9%    6410.0 -- ASN-APPNEXUS - AppNexus, Inc
 4 - AS22592            4949  0.2%    4949.0 -- HBP - HBP, Inc.
 5 - AS19406            4419  0.2%    4419.0 -- TWRS-MA - Towerstream I, Inc.
 6 - AS7202             8767  0.4%    4383.5 -- FAMU - Florida A & M University
 7 - AS6174             6851  0.3%    3425.5 -- SPRINTLINK8 - Sprint
 8 - AS5487            10067  0.5%    1438.1 -- Elisa Oyj
 9 - AS32528            5527  0.3%    1381.8 -- ABBOTT Abbot Labs
10 - AS37367            1231  0.1%    1231.0 -- CALLKEY
11 - AS50337            1790  0.1%     895.0 -- TETTAS-AS TETTAS SRL
12 - AS6775             3530  0.2%     706.0 -- BACKBONE_EHF_EUROPE Backbone ehf
13 - AS2                 660  0.0%     671.0 -- TSSB-AS-AP TeamCloud Solution Sdn Bhd
14 - AS2578             1201  0.1%     600.5 -- DEMOS-AS Demos, Moscow, Russia
15 - AS42334            9676  0.5%     569.2 -- BBP-AS Broadband Plus s.a.l.
16 - AS11054            7756  0.4%     554.0 -- LIVEPERSON LivePerson, Inc
17 - AS35873            3292  0.2%     548.7 -- MOVE-NETWORKS - Move Networks, inc.
18 - AS32244            6345  0.3%     528.8 -- LIQUID-WEB-INC - Liquid Web, Inc.
19 - AS56131            1034  0.1%     517.0 -- UXCCONNECT-AS-AP UXC Connect Pty Ltd
20 - AS3                6076  0.3%     818.0 -- RAFFEL-INTERNET Raffel Internet B.V.


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 109.161.64.0/20   21732  1.0%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 103.243.220.0/22  19227  0.9%   AS29990 -- ASN-APPNEXUS - AppNexus, Inc
 3 - 202.154.17.0/24   10734  0.5%   AS4434  -- ERX-RADNET1-AS PT Rahajasa Media Internet
 4 - 62.84.76.0/24      9582  0.4%   AS42334 -- BBP-AS Broadband Plus s.a.l.
 5 - 192.58.232.0/24    9330  0.4%   AS6629  -- NOAA-AS - NOAA
 6 - 206.152.15.0/24    9023  0.4%   AS54465 -- QPM-AS-1 - QuickPlay Media Inc.
 7 - 120.28.62.0/24     8196  0.4%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
 8 - 222.127.0.0/24     8117  0.4%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
 9 - 23.90.5.0/24       7551  0.3%   AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
10 - 23.90.6.0/24       7535  0.3%   AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
11 - 23.90.21.0/24      7534  0.3%   AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
12 - 121.52.144.0/24    7527  0.3%   AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
                                     AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan
13 - 67.210.188.0/23    5989  0.3%   AS11976 -- FIDN - Fidelity Communication International Inc.
14 - 67.210.190.0/23    5945  0.3%   AS11976 -- FIDN - Fidelity Communication International Inc.
15 - 202.164.190.0/24   5748  0.3%   AS9658  -- ETPI-IDS-AS-AP Eastern Telecoms Phils., Inc.
16 - 208.91.124.0/22    4949  0.2%   AS22592 -- HBP - HBP, Inc.
18 - 69.38.178.0/24     4419  0.2%   AS19406 -- TWRS-MA - Towerstream I, Inc.
19 - 168.223.200.0/22   4414  0.2%   AS7202  -- FAMU - Florida A & M University
20 - 64.187.64.0/23     4406  0.2%   AS16608 -- KENTEC - Kentec Communications, 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 julianeble at yahoo.com.br  Fri Oct 25 12:25:00 2013
From: julianeble at yahoo.com.br (Julian Eble)
Date: Fri, 25 Oct 2013 10:25:00 -0200
Subject: A9K-MPA-20X1GE in ASR9001
Message-ID: <004c01ced17d$3b6428a0$b22c79e0$@yahoo.com.br>

Hello,


Did you tried the service unsupported-transceiver command?


Eng. Julian Eble



From ebeheler at tippecanoe.in.gov  Fri Oct 25 13:54:31 2013
From: ebeheler at tippecanoe.in.gov (Edward Beheler)
Date: Fri, 25 Oct 2013 13:54:31 +0000
Subject: Network configuration archiving
In-Reply-To: <20131024212526.GC14735@Eleanor.local>
References: <20131024212526.GC14735@Eleanor.local>
Message-ID: <3EA26873F490C54891C7103B525794DC0116725E06@MITSOBEXCH03.tcg.tippecanoe.in.gov>

How simple do you want to get?  We do something like this:

!
archive
 path tftp://1.2.3.4/$h-
 write-memory
!

-----Original Message-----
From: Job Snijders [mailto:job.snijders at hibernianetworks.com] 
Sent: Thursday, October 24, 2013 5:25 PM
To: nanog at nanog.org
Subject: Network configuration archiving

Dear all,

I am unsure what we as networkers have done in the past, but I am sure we've done our fair share of atonement and don't have to keep using RANCID.

Some might say "it took ages to get rancid to do kinda what we want!", but not all software ages well. One might work in environments where archived configurations are needed to even start provisioning, one might desire a separation between actual config and transcient data. 

As I am evaluating our path forward, I've compiled a small list of open source projects with some biased highlights. Your feedback is most welcome, maybe I missed some interesting projects or developments. I would also be very interested in what other operators seek in a network config/state archive tool.

RANCID - http://www.shrubbery.net/rancid/
    * Support for a wild variery of devices and operating systems
    * complex perl code base [1]
    * no central developer team, the internet is littered with forks

Oxidized - https://github.com/ytti/oxidized
    * modern & sexy approach with queue & workers
    * RESTful API (example: can bump devices to the head of the queue)
    * small user & developer base
    * written in that ruby language

Gerty - https://github.com/ssinyagin/gerty
    * Seems easier to extend than RANCID
    * perl...
    * small user & developer base

punc - https://code.google.com/p/punc/
    * written in python, based on notch [2]
    * no recent developments (although 2011 was a good wine year)

[1] - http://honestnetworker.wordpress.com/2013/06/28/adding-new-device-support-to-rancid/
[2] - https://code.google.com/p/notch/

Kind regards,

Job



From michael.k.kehoe at gmail.com  Fri Oct 25 12:08:44 2013
From: michael.k.kehoe at gmail.com (Michael Kehoe)
Date: Fri, 25 Oct 2013 22:08:44 +1000
Subject: Network configuration archiving
In-Reply-To: <20131025115948.GF10952@rootmail.cc.le.ac.uk>
References: <20131024212526.GC14735@Eleanor.local>
 <20131025115948.GF10952@rootmail.cc.le.ac.uk>
Message-ID: <CAB73c3o+04gapuCL_Lym+AYpkBnFt39CRb+CjUroC10KMv1AAw@mail.gmail.com>

SNMP is a good/ quick way to do it, however you should keep in mind that
your configurations are not being sent securely if you're using tftp. Cisco
devices do allow you to also use ftp, rcp, scp and sftp.

As far as I'm aware (someone please correct me if I'm wrong), but Cisco is
the only vendor that supports this.

It's almost as easy to have a python/ perl script to do the exact same
thing as Matthew described but with SSH instead of SNMP.

Regards


On Fri, Oct 25, 2013 at 9:59 PM, Matthew Newton <mcn4 at leicester.ac.uk>wrote:

> On Thu, Oct 24, 2013 at 11:25:26PM +0200, Job Snijders wrote:
> > As I am evaluating our path forward, I've compiled a small list of open
> > source projects with some biased highlights. Your feedback is most
> > welcome, maybe I missed some interesting projects or developments. I
> > would also be very interested in what other operators seek in a network
> > config/state archive tool.
>
> For the last ~8 years we've used a very simple in-house bash
> script that uses SNMP to tell the switch to write its config using
> tftp, and then does a wr mem. It then checks the configs into a
> subversion repository and e-mails out any diffs.
>
> One criteria we had was that our config backup system wasn't going
> to get CLI access to any routers if at all possible, and this
> turned out to be a good alternative. I can't think of many times
> when it's failed to work; occasionally the odd switch might not
> respond, but that's rare.
>
> The only possible issue being that we're 100% Cisco, so I don't
> know if other vendors support the same MIBs.
>
> I'll try and post the script (250 lines) somewhere if anyone's
> interested.
>
> Cheers,
>
> Matthew
>
>
> --
> Matthew Newton, Ph.D. <mcn4 at le.ac.uk>
>
> Systems Specialist, Infrastructure Services,
> I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
>
> For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>
>
>

From gbakos at alpinista.org  Fri Oct 25 22:56:48 2013
From: gbakos at alpinista.org (George Bakos)
Date: Fri, 25 Oct 2013 22:56:48 +0000
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <526A9224.1050608@deaddrop.org>
References: <526A9224.1050608@deaddrop.org>
Message-ID: <20131025225648.49cf9ba3@alpinista.org>

next thing you know, Google is going to be offering free email so they
can do the same thing. 

On Fri, 25 Oct 2013 08:45:40 -0700
Shrdlu <shrdlu at deaddrop.org> wrote:

> I hate to do this, but it's something that anyone managing email
> servers (or just using a smart phone to update LI) needs to know
> about. I just saw this on another list I'm on, and I know that there
> are folks on NANOG that are on LinkedIn.
> 
> ++++++++++
> http://www.bishopfox.com/blog/2013/10/linkedin-intro/
> 
> LinkedIn released a new product today called Intro.  They call it
> ___doing the impossible___, but some might call it ___hijacking email___.
> Why do we say this?  Consider the following:
> 
> Intro reconfigures your iOS device (e.g. iPhone, iPad) so that all of
> your emails go through LinkedIn___s servers. You read that right. Once
> you install the Intro app, all of your emails, both sent and received,
> are transmitted via LinkedIn___s servers. LinkedIn is forcing all your
> IMAP and SMTP data through their own servers and then analyzing and
> scraping your emails for data pertaining to___whatever they feel like.
> 
> ++++++++++
> 
> Read the full article. If you're using LI via your smart phone, and
> you have already installed this app, you probably need to save off
> your contacts and data, and wipe the phone. I wouldn't trust
> uninstalling as enough, myself. In the long run, I'll be deleting my
> account.
> 
> No, I don't use a smart phone to update any social media. No, I
> especially do not trust LI (never have, never will). BTW, they're
> currently adding back any contacts you've deleted. Thanks for
> reminding me that Joe Barr, Len Sassaman, and Jay D Dyson are gone
> from this world.
> 
> -- 
> Life may not be the party we hoped for, but while we are here,
> we might as well dance.
> 
> 


-- 


From bedard.phil at gmail.com  Fri Oct 25 23:25:57 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Fri, 25 Oct 2013 19:25:57 -0400
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <20131025225648.49cf9ba3@alpinista.org>
Message-ID: <CE90758E.7BF83%bedard.phil@gmail.com>

I saw some antectdotal stuff on this yesterday but reading their
engineering blog entry makes me feel all warm and fuzzy inside.  Oh
nevermind, that's just the alcohol.  This is perhaps one of the worst
ideas I've seen concocted by a social media company yet.


-Phil

On 10/25/13, 6:56 PM, "George Bakos" <gbakos at alpinista.org> wrote:

>next thing you know, Google is going to be offering free email so they
>can do the same thing.
>
>On Fri, 25 Oct 2013 08:45:40 -0700
>Shrdlu <shrdlu at deaddrop.org> wrote:
>
>> I hate to do this, but it's something that anyone managing email
>> servers (or just using a smart phone to update LI) needs to know
>> about. I just saw this on another list I'm on, and I know that there
>> are folks on NANOG that are on LinkedIn.
>> 
>> ++++++++++
>> http://www.bishopfox.com/blog/2013/10/linkedin-intro/
>> 
>> LinkedIn released a new product today called Intro.  They call it
>> ___doing the impossible___, but some might call it ___hijacking
>>email___.
>> Why do we say this?  Consider the following:
>> 
>> Intro reconfigures your iOS device (e.g. iPhone, iPad) so that all of
>> your emails go through LinkedIn___s servers. You read that right. Once
>> you install the Intro app, all of your emails, both sent and received,
>> are transmitted via LinkedIn___s servers. LinkedIn is forcing all your
>> IMAP and SMTP data through their own servers and then analyzing and
>> scraping your emails for data pertaining to___whatever they feel like.
>> 
>> ++++++++++
>> 
>> Read the full article. If you're using LI via your smart phone, and
>> you have already installed this app, you probably need to save off
>> your contacts and data, and wipe the phone. I wouldn't trust
>> uninstalling as enough, myself. In the long run, I'll be deleting my
>> account.
>> 
>> No, I don't use a smart phone to update any social media. No, I
>> especially do not trust LI (never have, never will). BTW, they're
>> currently adding back any contacts you've deleted. Thanks for
>> reminding me that Joe Barr, Len Sassaman, and Jay D Dyson are gone
>> from this world.
>> 
>> -- 
>> Life may not be the party we hoped for, but while we are here,
>> we might as well dance.
>> 
>> 
>
>
>-- 
>




From pauldotwall at gmail.com  Fri Oct 25 23:48:12 2013
From: pauldotwall at gmail.com (Paul WALL)
Date: Fri, 25 Oct 2013 18:48:12 -0500
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <526A9224.1050608@deaddrop.org>
References: <526A9224.1050608@deaddrop.org>
Message-ID: <CAHnQ7eKP_8qVsK4UEFrAHy19t2_pbuPkuCmBTwFVJmyZBpjT=Q@mail.gmail.com>

Adding Zaid Ali Khan for feedback.


On Fri, Oct 25, 2013 at 10:45 AM, Shrdlu <shrdlu at deaddrop.org> wrote:

> I hate to do this, but it's something that anyone managing email
> servers (or just using a smart phone to update LI) needs to know
> about. I just saw this on another list I'm on, and I know that there
> are folks on NANOG that are on LinkedIn.
>
> ++++++++++
> http://www.bishopfox.com/blog/**2013/10/linkedin-intro/<http://www.bishopfox.com/blog/2013/10/linkedin-intro/>
>
> LinkedIn released a new product today called Intro.  They call it
> ?doing the impossible?, but some might call it ?hijacking email?.
> Why do we say this?  Consider the following:
>
> Intro reconfigures your iOS device (e.g. iPhone, iPad) so that all of
> your emails go through LinkedIn?s servers. You read that right. Once
> you install the Intro app, all of your emails, both sent and received,
> are transmitted via LinkedIn?s servers. LinkedIn is forcing all your
> IMAP and SMTP data through their own servers and then analyzing and
> scraping your emails for data pertaining to?whatever they feel like.
>
> ++++++++++
>
> Read the full article. If you're using LI via your smart phone, and
> you have already installed this app, you probably need to save off
> your contacts and data, and wipe the phone. I wouldn't trust
> uninstalling as enough, myself. In the long run, I'll be deleting my
> account.
>
> No, I don't use a smart phone to update any social media. No, I
> especially do not trust LI (never have, never will). BTW, they're
> currently adding back any contacts you've deleted. Thanks for
> reminding me that Joe Barr, Len Sassaman, and Jay D Dyson are gone
> from this world.
>
> --
> Life may not be the party we hoped for, but while we are here,
> we might as well dance.
>
>
>

From jfbeam at gmail.com  Fri Oct 25 23:51:50 2013
From: jfbeam at gmail.com (Ricky Beam)
Date: Fri, 25 Oct 2013 19:51:50 -0400
Subject: Network configuration archiving
In-Reply-To: <CAB73c3o+04gapuCL_Lym+AYpkBnFt39CRb+CjUroC10KMv1AAw@mail.gmail.com>
References: <20131024212526.GC14735@Eleanor.local>
 <20131025115948.GF10952@rootmail.cc.le.ac.uk>
 <CAB73c3o+04gapuCL_Lym+AYpkBnFt39CRb+CjUroC10KMv1AAw@mail.gmail.com>
Message-ID: <op.w5ja8og2tfhldh@rbeam.xactional.com>

On Fri, 25 Oct 2013 08:08:44 -0400, Michael Kehoe  
<michael.k.kehoe at gmail.com> wrote:
> As far as I'm aware (someone please correct me if I'm wrong), but Cisco  
> is the only vendor that supports this.

Ascend did as well.  I used to backup the MAX-TNT's via snmp.

(I've not researched the subject in over a decade.)

--Ricky


From jared at puck.nether.net  Sat Oct 26 00:22:52 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 25 Oct 2013 20:22:52 -0400
Subject: Network configuration archiving
In-Reply-To: <CAB73c3o+04gapuCL_Lym+AYpkBnFt39CRb+CjUroC10KMv1AAw@mail.gmail.com>
References: <20131024212526.GC14735@Eleanor.local>
 <20131025115948.GF10952@rootmail.cc.le.ac.uk>
 <CAB73c3o+04gapuCL_Lym+AYpkBnFt39CRb+CjUroC10KMv1AAw@mail.gmail.com>
Message-ID: <F0F45A42-A456-41A8-97DE-83180C639394@puck.nether.net>


On Oct 25, 2013, at 8:08 AM, Michael Kehoe <michael.k.kehoe at gmail.com> wrote:

> As far as I'm aware (someone please correct me if I'm wrong), but Cisco is
> the only vendor that supports this.
> 
> It's almost as easy to have a python/ perl script to do the exact same
> thing as Matthew described but with SSH instead of SNMP.
> 

You can do automation stuff like this with JunOS as well.

NTT has talked about what they have done in the past here:

http://www.nanog.org/meetings/nanog54/presentations/Tuesday/Morris.pdf

- Jared


From Valdis.Kletnieks at vt.edu  Sat Oct 26 00:24:25 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 25 Oct 2013 20:24:25 -0400
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: Your message of "Fri, 25 Oct 2013 22:56:48 -0000."
 <20131025225648.49cf9ba3@alpinista.org>
References: <526A9224.1050608@deaddrop.org>
 <20131025225648.49cf9ba3@alpinista.org>
Message-ID: <33757.1382747065@turing-police.cc.vt.edu>

On Fri, 25 Oct 2013 22:56:48 -0000, George Bakos said:
> next thing you know, Google is going to be offering free email so they
> can do the same thing.

The difference is that Google only does it to your @gmail.com address.  It
doesn't snarf up all your outbound gbakos at alpinista.org mail too.

-------------- 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/20131025/2d5055d8/attachment-0001.bin>

From jayfar at jayfar.com  Sat Oct 26 00:27:13 2013
From: jayfar at jayfar.com (Jay Farrell)
Date: Fri, 25 Oct 2013 20:27:13 -0400
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CAHnQ7eKP_8qVsK4UEFrAHy19t2_pbuPkuCmBTwFVJmyZBpjT=Q@mail.gmail.com>
References: <526A9224.1050608@deaddrop.org>
 <CAHnQ7eKP_8qVsK4UEFrAHy19t2_pbuPkuCmBTwFVJmyZBpjT=Q@mail.gmail.com>
Message-ID: <CAN414Ud1pORDO0_CBA854dtuyBrj7fd1ahSPocDEhXsFKpoY7g@mail.gmail.com>

And then of course there was this:

http://www.informationweek.com/social-business/social_networking_consumer/linkedin-responds-to-email-grabbing-suit/240161630

Linkedin denies the allegations, but I'm convinced there's something to
them. I was receiving a steady stream of linkedin invites on behalf of one
acquaintance until I marked them as spam.

Is Linkedin the kind of organization I would feel comfortable with exposing
my email to? Hell to the no!


On Fri, Oct 25, 2013 at 7:48 PM, Paul WALL <pauldotwall at gmail.com> wrote:

> Adding Zaid Ali Khan for feedback.
>
>
> On Fri, Oct 25, 2013 at 10:45 AM, Shrdlu <shrdlu at deaddrop.org> wrote:
>
> > I hate to do this, but it's something that anyone managing email
> > servers (or just using a smart phone to update LI) needs to know
> > about. I just saw this on another list I'm on, and I know that there
> > are folks on NANOG that are on LinkedIn.
> >
> > ++++++++++
> > http://www.bishopfox.com/blog/**2013/10/linkedin-intro/<
> http://www.bishopfox.com/blog/2013/10/linkedin-intro/>
> >
> > LinkedIn released a new product today called Intro.  They call it
> > ?doing the impossible?, but some might call it ?hijacking email?.
> > Why do we say this?  Consider the following:
> >
> > Intro reconfigures your iOS device (e.g. iPhone, iPad) so that all of
> > your emails go through LinkedIn?s servers. You read that right. Once
> > you install the Intro app, all of your emails, both sent and received,
> > are transmitted via LinkedIn?s servers. LinkedIn is forcing all your
> > IMAP and SMTP data through their own servers and then analyzing and
> > scraping your emails for data pertaining to?whatever they feel like.
> >
> > ++++++++++
> >
> > Read the full article. If you're using LI via your smart phone, and
> > you have already installed this app, you probably need to save off
> > your contacts and data, and wipe the phone. I wouldn't trust
> > uninstalling as enough, myself. In the long run, I'll be deleting my
> > account.
> >
> > No, I don't use a smart phone to update any social media. No, I
> > especially do not trust LI (never have, never will). BTW, they're
> > currently adding back any contacts you've deleted. Thanks for
> > reminding me that Joe Barr, Len Sassaman, and Jay D Dyson are gone
> > from this world.
> >
> > --
> > Life may not be the party we hoped for, but while we are here,
> > we might as well dance.
> >
> >
> >
>

From hartleyc at gmail.com  Fri Oct 25 23:43:10 2013
From: hartleyc at gmail.com (Chris Hartley)
Date: Fri, 25 Oct 2013 19:43:10 -0400
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CE90758E.7BF83%bedard.phil@gmail.com>
References: <20131025225648.49cf9ba3@alpinista.org>
 <CE90758E.7BF83%bedard.phil@gmail.com>
Message-ID: <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>

Anyone who has access to logs for their email infrastructure ought
probably to check for authentications to user accounts from linkedin's
servers.  Likely, people in your organization are entering their
credentials into linkedin to add to their contact list.  Is it a
problem if a social media company has your users' credentials?  I
guess it depends on your definition of "is."  The same advice might
apply to this perversion of trust as well, but I'm not sure how
linkedin is achieving this "feat."

On Fri, Oct 25, 2013 at 7:25 PM, Phil Bedard <bedard.phil at gmail.com> wrote:
> I saw some antectdotal stuff on this yesterday but reading their
> engineering blog entry makes me feel all warm and fuzzy inside.  Oh
> nevermind, that's just the alcohol.  This is perhaps one of the worst
> ideas I've seen concocted by a social media company yet.
>
>
> -Phil
>
> On 10/25/13, 6:56 PM, "George Bakos" <gbakos at alpinista.org> wrote:
>
>>next thing you know, Google is going to be offering free email so they
>>can do the same thing.
>>
>>On Fri, 25 Oct 2013 08:45:40 -0700
>>Shrdlu <shrdlu at deaddrop.org> wrote:
>>
>>> I hate to do this, but it's something that anyone managing email
>>> servers (or just using a smart phone to update LI) needs to know
>>> about. I just saw this on another list I'm on, and I know that there
>>> are folks on NANOG that are on LinkedIn.
>>>
>>> ++++++++++
>>> http://www.bishopfox.com/blog/2013/10/linkedin-intro/
>>>
>>> LinkedIn released a new product today called Intro.  They call it
>>> ___doing the impossible___, but some might call it ___hijacking
>>>email___.
>>> Why do we say this?  Consider the following:
>>>
>>> Intro reconfigures your iOS device (e.g. iPhone, iPad) so that all of
>>> your emails go through LinkedIn___s servers. You read that right. Once
>>> you install the Intro app, all of your emails, both sent and received,
>>> are transmitted via LinkedIn___s servers. LinkedIn is forcing all your
>>> IMAP and SMTP data through their own servers and then analyzing and
>>> scraping your emails for data pertaining to___whatever they feel like.
>>>
>>> ++++++++++
>>>
>>> Read the full article. If you're using LI via your smart phone, and
>>> you have already installed this app, you probably need to save off
>>> your contacts and data, and wipe the phone. I wouldn't trust
>>> uninstalling as enough, myself. In the long run, I'll be deleting my
>>> account.
>>>
>>> No, I don't use a smart phone to update any social media. No, I
>>> especially do not trust LI (never have, never will). BTW, they're
>>> currently adding back any contacts you've deleted. Thanks for
>>> reminding me that Joe Barr, Len Sassaman, and Jay D Dyson are gone
>>> from this world.
>>>
>>> --
>>> Life may not be the party we hoped for, but while we are here,
>>> we might as well dance.
>>>
>>>
>>
>>
>>--
>>
>
>
>


From mysidia at gmail.com  Sat Oct 26 06:06:51 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 26 Oct 2013 01:06:51 -0500
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>
References: <20131025225648.49cf9ba3@alpinista.org>
 <CE90758E.7BF83%bedard.phil@gmail.com>
 <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>
Message-ID: <CAAAwwbU8ct0RnVJmQ0XiWA34PWzE_eDTyjC34FAtnZ6=Duh-KA@mail.gmail.com>

On Fri, Oct 25, 2013 at 6:43 PM, Chris Hartley <hartleyc at gmail.com> wrote:

> Anyone who has access to logs for their email infrastructure ought
> probably to check for authentications to user accounts from linkedin's
> servers.
> [snip]
>

Perhaps a prudent countermeasure would be to redirect all  POP,  IMAP,  and
Webmail access to your corporate mail server from all of  LinkedIn's  IP
space to a  "Honeypot"   that will simply  log   usernames/credentials
attempted.

The list of valid credentials,  can then be used to  dispatch a warning to
the offender,  and force a password change.

This could be a useful proactive countermeasure against the  UIT
 (Unintentional Insider Threat);  of employees  inappropriately   entering
  corporate  e-mail credentials  into a known  third party service  with
 outside of organizational control.

Seeing as  Linkedin  almost certainly is not providing signed NDAs and
 privacy SLAs;   it seems reasonable that  most organizations who
understand what is going on,  would not approve  of use of the service with
their internal business email accounts.


-- 
-JH

From jhellenthal at dataix.net  Sat Oct 26 06:16:05 2013
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Sat, 26 Oct 2013 02:16:05 -0400
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CAAAwwbU8ct0RnVJmQ0XiWA34PWzE_eDTyjC34FAtnZ6=Duh-KA@mail.gmail.com>
References: <20131025225648.49cf9ba3@alpinista.org>
 <CE90758E.7BF83%bedard.phil@gmail.com>
 <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>
 <CAAAwwbU8ct0RnVJmQ0XiWA34PWzE_eDTyjC34FAtnZ6=Duh-KA@mail.gmail.com>
Message-ID: <DC311BD1-6258-4856-8660-022A58A17342@dataix.net>

Well said

-- 
 Jason Hellenthal
 Voice: 95.30.17.6/616
 JJH48-ARIN

On Oct 26, 2013, at 2:06, Jimmy Hess <mysidia at gmail.com> wrote:

On Fri, Oct 25, 2013 at 6:43 PM, Chris Hartley <hartleyc at gmail.com> wrote:

> Anyone who has access to logs for their email infrastructure ought
> probably to check for authentications to user accounts from linkedin's
> servers.
> [snip]

Perhaps a prudent countermeasure would be to redirect all  POP,  IMAP,  and
Webmail access to your corporate mail server from all of  LinkedIn's  IP
space to a  "Honeypot"   that will simply  log   usernames/credentials
attempted.

The list of valid credentials,  can then be used to  dispatch a warning to
the offender,  and force a password change.

This could be a useful proactive countermeasure against the  UIT
(Unintentional Insider Threat);  of employees  inappropriately   entering
 corporate  e-mail credentials  into a known  third party service  with
outside of organizational control.

Seeing as  Linkedin  almost certainly is not providing signed NDAs and
privacy SLAs;   it seems reasonable that  most organizations who
understand what is going on,  would not approve  of use of the service with
their internal business email accounts.


-- 
-JH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6118 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131026/67756384/attachment.bin>

From laszlo at heliacal.net  Sat Oct 26 05:44:33 2013
From: laszlo at heliacal.net (Laszlo Hanyecz)
Date: Sat, 26 Oct 2013 05:44:33 +0000
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>
References: <20131025225648.49cf9ba3@alpinista.org>
 <CE90758E.7BF83%bedard.phil@gmail.com>
 <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>
Message-ID: <1AD1E8D8-431A-405A-B3F1-74057F2B9D5B@heliacal.net>

When a user signs up for a social media account they generally do so by providing an email address like victim at freewebmailsite.com and selecting a password.  The social media site can obviously probe freewebmailsite.com and attempt to authenticate using the same password that you just provided to them (for the purpose of logging into their social media site).  I guess offering an email proxy or asking if it's ok to worm through your email for contacts is merely a formality.  How many social media users do you guess would use the same password on the social media site as they would for freewebmailsite.com (and likely their employer's organization's email)?  It's kind of like when google asks their users with android phones to provide their mobile phone number for SMS password recovery.

Laszlo

On Oct 25, 2013, at 11:43 PM, Chris Hartley <hartleyc at gmail.com> wrote:

> Anyone who has access to logs for their email infrastructure ought
> probably to check for authentications to user accounts from linkedin's
> servers.  Likely, people in your organization are entering their
> credentials into linkedin to add to their contact list.  Is it a
> problem if a social media company has your users' credentials?  I
> guess it depends on your definition of "is."  The same advice might
> apply to this perversion of trust as well, but I'm not sure how
> linkedin is achieving this "feat."
> 
> On Fri, Oct 25, 2013 at 7:25 PM, Phil Bedard <bedard.phil at gmail.com> wrote:
>> I saw some antectdotal stuff on this yesterday but reading their
>> engineering blog entry makes me feel all warm and fuzzy inside.  Oh
>> nevermind, that's just the alcohol.  This is perhaps one of the worst
>> ideas I've seen concocted by a social media company yet.
>> 
>> 
>> -Phil
>> 
>> On 10/25/13, 6:56 PM, "George Bakos" <gbakos at alpinista.org> wrote:
>> 
>>> next thing you know, Google is going to be offering free email so they
>>> can do the same thing.
>>> 
>>> On Fri, 25 Oct 2013 08:45:40 -0700
>>> Shrdlu <shrdlu at deaddrop.org> wrote:
>>> 
>>>> I hate to do this, but it's something that anyone managing email
>>>> servers (or just using a smart phone to update LI) needs to know
>>>> about. I just saw this on another list I'm on, and I know that there
>>>> are folks on NANOG that are on LinkedIn.
>>>> 
>>>> ++++++++++
>>>> http://www.bishopfox.com/blog/2013/10/linkedin-intro/
>>>> 
>>>> LinkedIn released a new product today called Intro.  They call it
>>>> ___doing the impossible___, but some might call it ___hijacking
>>>> email___.
>>>> Why do we say this?  Consider the following:
>>>> 
>>>> Intro reconfigures your iOS device (e.g. iPhone, iPad) so that all of
>>>> your emails go through LinkedIn___s servers. You read that right. Once
>>>> you install the Intro app, all of your emails, both sent and received,
>>>> are transmitted via LinkedIn___s servers. LinkedIn is forcing all your
>>>> IMAP and SMTP data through their own servers and then analyzing and
>>>> scraping your emails for data pertaining to___whatever they feel like.
>>>> 
>>>> ++++++++++
>>>> 
>>>> Read the full article. If you're using LI via your smart phone, and
>>>> you have already installed this app, you probably need to save off
>>>> your contacts and data, and wipe the phone. I wouldn't trust
>>>> uninstalling as enough, myself. In the long run, I'll be deleting my
>>>> account.
>>>> 
>>>> No, I don't use a smart phone to update any social media. No, I
>>>> especially do not trust LI (never have, never will). BTW, they're
>>>> currently adding back any contacts you've deleted. Thanks for
>>>> reminding me that Joe Barr, Len Sassaman, and Jay D Dyson are gone
>>>> from this world.
>>>> 
>>>> --
>>>> Life may not be the party we hoped for, but while we are here,
>>>> we might as well dance.
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> 
>> 
>> 
>> 
> 



From web at typo.org  Sat Oct 26 08:17:18 2013
From: web at typo.org (Wayne E Bouchard)
Date: Sat, 26 Oct 2013 01:17:18 -0700
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <DC311BD1-6258-4856-8660-022A58A17342@dataix.net>
References: <20131025225648.49cf9ba3@alpinista.org>
 <CE90758E.7BF83%bedard.phil@gmail.com>
 <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>
 <CAAAwwbU8ct0RnVJmQ0XiWA34PWzE_eDTyjC34FAtnZ6=Duh-KA@mail.gmail.com>
 <DC311BD1-6258-4856-8660-022A58A17342@dataix.net>
Message-ID: <20131026081718.GA64246@wakko.typo.org>

There's a reason I use an email alias if I sign up to places like
that and why I do not place much information on these sites...

There's a reason I maintain somewhere approaching 20 passwords in my
head too and why the password I use for accessing my own systems will
never be the password I use to access a system neither I nor my
employer control.

It's just common sense.

Remember, the greatest threat to your privacy and security is YOU! How
many of us go about detailing every aspect of our lives on facebook or
twitter or something and, if someone is of a mind to comb through it,
in the process self-disclose everything necessary for someone to
basically become us? The hackers/corporate scrapers don't even really
*HAVE* to try to thieve information anymore. We give it to them all
without them even asking!

-Wayne

On Sat, Oct 26, 2013 at 02:16:05AM -0400, Jason Hellenthal wrote:
> Well said
> 
> -- 
>  Jason Hellenthal
>  Voice: 95.30.17.6/616
>  JJH48-ARIN
> 
> On Oct 26, 2013, at 2:06, Jimmy Hess <mysidia at gmail.com> wrote:
> 
> On Fri, Oct 25, 2013 at 6:43 PM, Chris Hartley <hartleyc at gmail.com> wrote:
> 
> > Anyone who has access to logs for their email infrastructure ought
> > probably to check for authentications to user accounts from linkedin's
> > servers.
> > [snip]
> 
> Perhaps a prudent countermeasure would be to redirect all  POP,  IMAP,  and
> Webmail access to your corporate mail server from all of  LinkedIn's  IP
> space to a  "Honeypot"   that will simply  log   usernames/credentials
> attempted.
> 
> The list of valid credentials,  can then be used to  dispatch a warning to
> the offender,  and force a password change.
> 
> This could be a useful proactive countermeasure against the  UIT
> (Unintentional Insider Threat);  of employees  inappropriately   entering
>  corporate  e-mail credentials  into a known  third party service  with
> outside of organizational control.
> 
> Seeing as  Linkedin  almost certainly is not providing signed NDAs and
> privacy SLAs;   it seems reasonable that  most organizations who
> understand what is going on,  would not approve  of use of the service with
> their internal business email accounts.
> 
> 
> -- 
> -JH



---
Wayne Bouchard
web at typo.org
Network Dude
http://www.typo.org/~web/


From rsk at gsp.org  Sat Oct 26 12:07:06 2013
From: rsk at gsp.org (Rich Kulawiec)
Date: Sat, 26 Oct 2013 08:07:06 -0400
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <526A9224.1050608@deaddrop.org>
References: <526A9224.1050608@deaddrop.org>
Message-ID: <20131026120706.GA32747@gsp.org>


(My apologies to those of you who are also on the mailop list and
have already seen these remarks.)

This isn't particularly surprising: LinkedIn are spammers.  Have been
since forever.  They hit real addresses, fake addresses, mailing lists,
spamtraps, never-existed addresses, everything.

And like other dedicated spammers before them -- Spamford comes to mind --
they're quite happy to shift their abuse modality.  (You'll recall that
Spamford tried junk faxing, adware, etc.)  This is certainly a novel
approach, but it's completely in keeping with their "business philosophy".

The response is what will determine whether we'll get more of this
(of course with the self-serving lie that one can always "opt-out").
I do hope that the aggregate reply to this vicious attack on the privacy,
security and integrity of the Internet is met with widespread firewalling
and null-routing -- because if it's not, if this is actually allowed to
succeed, it WILL be copied.

(I'll add "and with legal action", but I'm not an attorney and thus
unqualified to speak to whether litigation is appropriate or even
possible.)

---rsk



From bedard.phil at gmail.com  Sat Oct 26 13:50:31 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Sat, 26 Oct 2013 06:50:31 -0700
Subject: If you're on LinkedIn, and you use a smart phone...
Message-ID: <5462970299074460243@unknownmsgid>

I had to answer the question of "Why is LinkedIn asking for my GMail
account information" to one of my parents recently. "Oh it is so they
can access your information and use it...". It is how some random guys
I play tennis with in a league keep popping up as people I should add,
since they likely succumbed to that prompt. Another practice of theirs
I do not like.

Phil From: Laszlo Hanyecz
Sent: 10/26/2013 1:44
To: Chris Hartley
Cc: Phil Bedard; Nanog
Subject: Re: If you're on LinkedIn, and you use a smart phone...
When a user signs up for a social media account they generally do so
by providing an email address like victim at freewebmailsite.com and
selecting a password.  The social media site can obviously probe
freewebmailsite.com and attempt to authenticate using the same
password that you just provided to them (for the purpose of logging
into their social media site).  I guess offering an email proxy or
asking if it's ok to worm through your email for contacts is merely a
formality.  How many social media users do you guess would use the
same password on the social media site as they would for
freewebmailsite.com (and likely their employer's organization's
email)?  It's kind of like when google asks their users with android
phones to provide their mobile phone number for SMS password recovery.

Laszlo

On Oct 25, 2013, at 11:43 PM, Chris Hartley <hartleyc at gmail.com> wrote:

> Anyone who has access to logs for their email infrastructure ought
> probably to check for authentications to user accounts from linkedin's
> servers.  Likely, people in your organization are entering their
> credentials into linkedin to add to their contact list.  Is it a
> problem if a social media company has your users' credentials?  I
> guess it depends on your definition of "is."  The same advice might
> apply to this perversion of trust as well, but I'm not sure how
> linkedin is achieving this "feat."
>
> On Fri, Oct 25, 2013 at 7:25 PM, Phil Bedard <bedard.phil at gmail.com> wrote:
>> I saw some antectdotal stuff on this yesterday but reading their
>> engineering blog entry makes me feel all warm and fuzzy inside.  Oh
>> nevermind, that's just the alcohol.  This is perhaps one of the worst
>> ideas I've seen concocted by a social media company yet.
>>
>>
>> -Phil
>>
>> On 10/25/13, 6:56 PM, "George Bakos" <gbakos at alpinista.org> wrote:
>>
>>> next thing you know, Google is going to be offering free email so they
>>> can do the same thing.
>>>
>>> On Fri, 25 Oct 2013 08:45:40 -0700
>>> Shrdlu <shrdlu at deaddrop.org> wrote:
>>>
>>>> I hate to do this, but it's something that anyone managing email
>>>> servers (or just using a smart phone to update LI) needs to know
>>>> about. I just saw this on another list I'm on, and I know that there
>>>> are folks on NANOG that are on LinkedIn.
>>>>
>>>> ++++++++++
>>>> http://www.bishopfox.com/blog/2013/10/linkedin-intro/
>>>>
>>>> LinkedIn released a new product today called Intro.  They call it
>>>> ___doing the impossible___, but some might call it ___hijacking
>>>> email___.
>>>> Why do we say this?  Consider the following:
>>>>
>>>> Intro reconfigures your iOS device (e.g. iPhone, iPad) so that all of
>>>> your emails go through LinkedIn___s servers. You read that right. Once
>>>> you install the Intro app, all of your emails, both sent and received,
>>>> are transmitted via LinkedIn___s servers. LinkedIn is forcing all your
>>>> IMAP and SMTP data through their own servers and then analyzing and
>>>> scraping your emails for data pertaining to___whatever they feel like.
>>>>
>>>> ++++++++++
>>>>
>>>> Read the full article. If you're using LI via your smart phone, and
>>>> you have already installed this app, you probably need to save off
>>>> your contacts and data, and wipe the phone. I wouldn't trust
>>>> uninstalling as enough, myself. In the long run, I'll be deleting my
>>>> account.
>>>>
>>>> No, I don't use a smart phone to update any social media. No, I
>>>> especially do not trust LI (never have, never will). BTW, they're
>>>> currently adding back any contacts you've deleted. Thanks for
>>>> reminding me that Joe Barr, Len Sassaman, and Jay D Dyson are gone
>>>> from this world.
>>>>
>>>> --
>>>> Life may not be the party we hoped for, but while we are here,
>>>> we might as well dance.
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>
>>
>>
>


From mike at mtcc.com  Sat Oct 26 06:16:56 2013
From: mike at mtcc.com (Michael Thomas)
Date: Fri, 25 Oct 2013 23:16:56 -0700
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>
References: <20131025225648.49cf9ba3@alpinista.org>
 <CE90758E.7BF83%bedard.phil@gmail.com>
 <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>
Message-ID: <526B5E58.7020600@mtcc.com>

Chris Hartley wrote:
> Anyone who has access to logs for their email infrastructure ought
> probably to check for authentications to user accounts from linkedin's
> servers.  Likely, people in your organization are entering their
> credentials into linkedin to add to their contact list.  Is it a
> problem if a social media company has your users' credentials?  I
> guess it depends on your definition of "is."  The same advice might
> apply to this perversion of trust as well, but I'm not sure how
> linkedin is achieving this "feat."
> 

Heck, it ought to show in the received headers. Of course they may purposefully
not be adding a received header in which their sleaze factor goes up even more.

Mike


From gary at baribault.net  Sat Oct 26 16:46:06 2013
From: gary at baribault.net (Gary Baribault)
Date: Sat, 26 Oct 2013 12:46:06 -0400
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <33757.1382747065@turing-police.cc.vt.edu>
References: <526A9224.1050608@deaddrop.org>
 <20131025225648.49cf9ba3@alpinista.org>
 <33757.1382747065@turing-police.cc.vt.edu>
Message-ID: <526BF1CE.6000701@baribault.net>

The other difference is that Google tells you up front, LinkedIn
installed this out of the bleue without any real permissions. Of course
if this where an opt in thing, nobody would be opting in! Well, I never
did install their app and most certainly never will, and am telling all
of my friends about this as well.

Gary Baribault
Courriel: gary at baribault.net
GPG Key: 0x685430d1
Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1

On 10/25/2013 08:24 PM, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 25 Oct 2013 22:56:48 -0000, George Bakos said:
>> next thing you know, Google is going to be offering free email so they
>> can do the same thing.
> The difference is that Google only does it to your @gmail.com address.  It
> doesn't snarf up all your outbound gbakos at alpinista.org mail too.
>



From scott at doc.net.au  Sat Oct 26 20:23:15 2013
From: scott at doc.net.au (Scott Howard)
Date: Sat, 26 Oct 2013 23:23:15 +0300
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <526BF1CE.6000701@baribault.net>
References: <526A9224.1050608@deaddrop.org>
 <20131025225648.49cf9ba3@alpinista.org>
 <33757.1382747065@turing-police.cc.vt.edu>
 <526BF1CE.6000701@baribault.net>
Message-ID: <CACnPsNVE4SNKHcXMx7dF+dwFL+LToWm4GDPKHmvuuMU+FiW9Tg@mail.gmail.com>

On Sat, Oct 26, 2013 at 7:46 PM, Gary Baribault <gary at baribault.net> wrote:

> The other difference is that Google tells you up front, LinkedIn
> installed this out of the bleue without any real permissions. Of course
> if this where an opt in thing, nobody would be opting in! Well, I never
> did install their app and most certainly never will, and am telling all
> of my friends about this as well.
>

Have you actually confirmed it's NOT opt-in?  The screenshots on the
Linked-in engineering blog referenced earlier certainly make it look like
it is.

http://engineering.linkedin.com/sites/default/files/intro_installer_0.png

Of course, you could argue there's a difference between opting-in for
"enhancing your email with Intro" and opting-in for "Please MITM all of my
email and dynamic modify it", but that's really just semantics - it
definitely appears to be opt-in.

  Scott

From mike at mtcc.com  Sat Oct 26 12:45:11 2013
From: mike at mtcc.com (Michael Thomas)
Date: Sat, 26 Oct 2013 05:45:11 -0700
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CACnPsNVE4SNKHcXMx7dF+dwFL+LToWm4GDPKHmvuuMU+FiW9Tg@mail.gmail.com>
References: <526A9224.1050608@deaddrop.org>
 <20131025225648.49cf9ba3@alpinista.org>
 <33757.1382747065@turing-police.cc.vt.edu> <526BF1CE.6000701@baribault.net>
 <CACnPsNVE4SNKHcXMx7dF+dwFL+LToWm4GDPKHmvuuMU+FiW9Tg@mail.gmail.com>
Message-ID: <526BB957.3070307@mtcc.com>

Scott Howard wrote:

> Have you actually confirmed it's NOT opt-in?  The screenshots on the
> Linked-in engineering blog referenced earlier certainly make it look like
> it is.
> 
> http://engineering.linkedin.com/sites/default/files/intro_installer_0.png
> 
> Of course, you could argue there's a difference between opting-in for
> "enhancing your email with Intro" and opting-in for "Please MITM all of my
> email and dynamic modify it", but that's really just semantics - it
> definitely appears to be opt-in.

There's consent and then  there's informed consent. Unless they explicitly
disclaim that "WE CAN AND DO READ EVERY PIECE OF MAIL YOU SEND AND RECEIVE
AND USE IT FOR WHATEVER WE WANT" then it isn't informed consent. My guess is
that the confirmation dialogs are more along the lines of "DO YOU LIKE CUTE
KITTENS?"

Mike


From andre-nanog at tomt.net  Sat Oct 26 22:20:20 2013
From: andre-nanog at tomt.net (Andre Tomt)
Date: Sun, 27 Oct 2013 00:20:20 +0200
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CAAAwwbU8ct0RnVJmQ0XiWA34PWzE_eDTyjC34FAtnZ6=Duh-KA@mail.gmail.com>
References: <20131025225648.49cf9ba3@alpinista.org>
 <CE90758E.7BF83%bedard.phil@gmail.com>
 <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>
 <CAAAwwbU8ct0RnVJmQ0XiWA34PWzE_eDTyjC34FAtnZ6=Duh-KA@mail.gmail.com>
Message-ID: <526C4024.4010409@tomt.net>

On 26. okt. 2013 08:06, Jimmy Hess wrote:
> Perhaps a prudent countermeasure would be to redirect all  POP,  IMAP,  and
> Webmail access to your corporate mail server from all of  LinkedIn's  IP
> space to a  "Honeypot"   that will simply  log   usernames/credentials
> attempted.
>
> The list of valid credentials,  can then be used to  dispatch a warning to
> the offender,  and force a password change.
>
> This could be a useful proactive countermeasure against the  UIT
>   (Unintentional Insider Threat);  of employees  inappropriately   entering
>    corporate  e-mail credentials  into a known  third party service  with
>   outside of organizational control.
>
> Seeing as  Linkedin  almost certainly is not providing signed NDAs and
>   privacy SLAs;   it seems reasonable that  most organizations who
> understand what is going on,  would not approve  of use of the service with
> their internal business email accounts.

Depends on linkedin beeing nice, but could this be an idea? In addition 
to the proposed network level controls of course. At least users could 
get a informative response rather than just some dumb error / "it doesnt 
work" if you block Intro.

http://feedback.intro.linkedin.com/forums/227301-linkedin-intro-feedback/suggestions/4801236-some-way-to-block-intro-per-domain

Votes maybe?

I considered proposing making it opt-in on the domain level, but that 
wont fly for them I'm sure.


From bedard.phil at gmail.com  Sun Oct 27 01:42:52 2013
From: bedard.phil at gmail.com (Phil Bedard)
Date: Sat, 26 Oct 2013 21:42:52 -0400
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <526C4024.4010409@tomt.net>
References: <20131025225648.49cf9ba3@alpinista.org>
 <CE90758E.7BF83%bedard.phil@gmail.com>
 <CAPnfr8+d0xjsG3scq1zeSD10ks0KfGgW17ZSsSXfO5ysjeW-Sw@mail.gmail.com>
 <CAAAwwbU8ct0RnVJmQ0XiWA34PWzE_eDTyjC34FAtnZ6=Duh-KA@mail.gmail.com>
 <526C4024.4010409@tomt.net>
Message-ID: <711DCE9D-0406-422F-A747-E6CE0B34A301@gmail.com>

I don't see that happening.  I have heard of a couple companies sending out emails saying installing it violates company IT policies and I'm sure those using MDM will create policies to disable it.  

It's one of those things which should probably just fade into history quietly.   Maybe LinkedIn should petition Apple to find a way to integrate the info.  Windows Phone for instance already internally does exactly what Intro does without scraping emails.  

Phil

> On Oct 26, 2013, at 6:20 PM, Andre Tomt <andre-nanog at tomt.net> wrote:
> 
>> On 26. okt. 2013 08:06, Jimmy Hess wrote:
>> Perhaps a prudent countermeasure would be to redirect all  POP,  IMAP,  and
>> Webmail access to your corporate mail server from all of  LinkedIn's  IP
>> space to a  "Honeypot"   that will simply  log   usernames/credentials
>> attempted.
>> 
>> The list of valid credentials,  can then be used to  dispatch a warning to
>> the offender,  and force a password change.
>> 
>> This could be a useful proactive countermeasure against the  UIT
>>  (Unintentional Insider Threat);  of employees  inappropriately   entering
>>   corporate  e-mail credentials  into a known  third party service  with
>>  outside of organizational control.
>> 
>> Seeing as  Linkedin  almost certainly is not providing signed NDAs and
>>  privacy SLAs;   it seems reasonable that  most organizations who
>> understand what is going on,  would not approve  of use of the service with
>> their internal business email accounts.
> 
> Depends on linkedin beeing nice, but could this be an idea? In addition to the proposed network level controls of course. At least users could get a informative response rather than just some dumb error / "it doesnt work" if you block Intro.
> 
> http://feedback.intro.linkedin.com/forums/227301-linkedin-intro-feedback/suggestions/4801236-some-way-to-block-intro-per-domain
> 
> Votes maybe?
> 
> I considered proposing making it opt-in on the domain level, but that wont fly for them I'm sure.
> 


From jstuxuhu0816 at gmail.com  Sun Oct 27 10:20:44 2013
From: jstuxuhu0816 at gmail.com (Xu Hu)
Date: Sun, 27 Oct 2013 18:20:44 +0800
Subject: A9K-MPA-20X1GE in ASR9001
In-Reply-To: <526A400E.2060309@inblock.ru>
References: <526A400E.2060309@inblock.ru>
Message-ID: <CAJ8G0mUfjntJ5FdVf6YcCsP1haNaL1Mxr0F8y6_BnYaPE0wPJA@mail.gmail.com>

I feel should be the hardware issue.

On Friday, October 25, 2013, Nikolay Shopik <shopik at inblock.ru> wrote:
> Hey, anyone had issues with A9K-MPA-20X1GE in ASR9001?
>
> It get disabled for us after 20 seconds finishing initialization, with
> such message.
>
> %PLATFORM-SCC-2-BAD_ID_HW : Failed Identification Test in 0/130/0 [1/0]
> The module in 0/130/0 in this router may not be a genuineCisco product.
>
>
>

From geekgirl at gmail.com  Sun Oct 27 15:52:18 2013
From: geekgirl at gmail.com (Leslie)
Date: Sun, 27 Oct 2013 08:52:18 -0700
Subject: Need help contact Smart (AS 10139) in the Philippines
Message-ID: <CAJ2h61aOkpK=+WNC7355CE9AqTfn83xzY3uDRxUJdBJL1Cd9mA@mail.gmail.com>

Hi everyone -
I always hate doing this, but I need some help getting a hold of a
technical person at Smart in the Philippines, since at least one /24
of their "smartbro" internet service is returning 504's on users
attempts to reach wikipedia for about the last week(but not if they go
to the mobile site or a domain run by wikimedia but not wikipedia
itself).  We believe that they must be running some sort of
transparent proxy which is malfunctioning.

It is possible they have some connection to AS9299 since that seems to
be their only transit provider.

In case anyone is curious the methods we've tried to get in contact
with them it includes : filling out the form for their tech support
listed on the webpage, calling their tech support, having customers
call their tech support repeatedly (sadly these two just result in
support staff reading scripts and refusing to escalate), email noc@,
emailing all of the addresses listed on their APNIC info, calling all
of the phone numbers listed on their APNIC info, and using twitter to
their customer support.  I believe a volunteer is even trying to
search for technical folks via facebook.

If anyone has any technical contacts within this organization, it
would be greatly appreciated,

Leslie


From jra at baylink.com  Sun Oct 27 18:19:47 2013
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 27 Oct 2013 14:19:47 -0400 (EDT)
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CAAAwwbU8ct0RnVJmQ0XiWA34PWzE_eDTyjC34FAtnZ6=Duh-KA@mail.gmail.com>
Message-ID: <2245767.2787.1382897987168.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jimmy Hess" <mysidia at gmail.com>

> This could be a useful proactive countermeasure against the UIT
> (Unintentional Insider Threat); of employees inappropriately entering
> corporate e-mail credentials into a known third party service with
> outside of organizational control.

Alas, it can't.  Using it against LI would work, cause you have a hope of 
knowing what address space their proxies are in.

You can't do that generically, unless you somehow whitelist the IPs your
users will be validly coming from, or figure out a way to determine what
client is connecting.

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 at baribault.net  Sun Oct 27 21:07:03 2013
From: gary at baribault.net (Gary Baribault)
Date: Sun, 27 Oct 2013 17:07:03 -0400
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CACnPsNVE4SNKHcXMx7dF+dwFL+LToWm4GDPKHmvuuMU+FiW9Tg@mail.gmail.com>
References: <526A9224.1050608@deaddrop.org>	<20131025225648.49cf9ba3@alpinista.org>	<33757.1382747065@turing-police.cc.vt.edu>	<526BF1CE.6000701@baribault.net>
 <CACnPsNVE4SNKHcXMx7dF+dwFL+LToWm4GDPKHmvuuMU+FiW9Tg@mail.gmail.com>
Message-ID: <526D8077.5010608@baribault.net>

It's opt-in in that if you bother to read the 240,405 pager of the
agreement when you install the 'upgrade' software, then you have in fact
opted in .. so legally (IANAL) you have opted in. BS!

Gary B

Gary Baribault
Courriel: gary at baribault.net
GPG Key: 0x685430d1
Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1

On 10/26/2013 04:23 PM, Scott Howard wrote:
> On Sat, Oct 26, 2013 at 7:46 PM, Gary Baribault <gary at baribault.net <mailto:gary at baribault.net>> wrote:
>
>     The other difference is that Google tells you up front, LinkedIn
>     installed this out of the bleue without any real permissions. Of
course
>     if this where an opt in thing, nobody would be opting in! Well, I
never
>     did install their app and most certainly never will, and am
telling all
>     of my friends about this as well.
>
>
> Have you actually confirmed it's NOT opt-in?  The screenshots on the
Linked-in engineering blog referenced earlier certainly make it look
like it is.
>
> http://engineering.linkedin.com/sites/default/files/intro_installer_0.png
>
> Of course, you could argue there's a difference between opting-in for
"enhancing your email with Intro" and opting-in for "Please MITM all of
my email and dynamic modify it", but that's really just semantics - it
definitely appears to be opt-in.
>
>   Scott
>



From wbailey at satelliteintelligencegroup.com  Sun Oct 27 22:11:26 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Sun, 27 Oct 2013 22:11:26 +0000
Subject: Need help contact Smart (AS 10139) in the Philippines
In-Reply-To: <CAJ2h61aOkpK=+WNC7355CE9AqTfn83xzY3uDRxUJdBJL1Cd9mA@mail.gmail.com>
Message-ID: <CE92DD5C.CD92%wbailey@satelliteintelligencegroup.com>

If memory serves me correctly, Smart is generally operated network wise by
PLDT.

PLDT is probably a decent POC to either get you squared away or pointed in
a generally better direction.

On 10/27/13 8:52 AM, "Leslie" <geekgirl at gmail.com> wrote:

>Hi everyone -
>I always hate doing this, but I need some help getting a hold of a
>technical person at Smart in the Philippines, since at least one /24
>of their "smartbro" internet service is returning 504's on users
>attempts to reach wikipedia for about the last week(but not if they go
>to the mobile site or a domain run by wikimedia but not wikipedia
>itself).  We believe that they must be running some sort of
>transparent proxy which is malfunctioning.
>
>It is possible they have some connection to AS9299 since that seems to
>be their only transit provider.
>
>In case anyone is curious the methods we've tried to get in contact
>with them it includes : filling out the form for their tech support
>listed on the webpage, calling their tech support, having customers
>call their tech support repeatedly (sadly these two just result in
>support staff reading scripts and refusing to escalate), email noc@,
>emailing all of the addresses listed on their APNIC info, calling all
>of the phone numbers listed on their APNIC info, and using twitter to
>their customer support.  I believe a volunteer is even trying to
>search for technical folks via facebook.
>
>If anyone has any technical contacts within this organization, it
>would be greatly appreciated,
>
>Leslie
>



From mysidia at gmail.com  Mon Oct 28 04:19:28 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 27 Oct 2013 23:19:28 -0500
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <2245767.2787.1382897987168.JavaMail.root@benjamin.baylink.com>
References: <CAAAwwbU8ct0RnVJmQ0XiWA34PWzE_eDTyjC34FAtnZ6=Duh-KA@mail.gmail.com>
 <2245767.2787.1382897987168.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAAAwwbUYFtTj3Yx8YeYdWh_Fv5u+dv6xhz+SjjGwMWv2FEva0Q@mail.gmail.com>

On Sun, Oct 27, 2013 at 1:19 PM, Jay Ashworth <jra at baylink.com> wrote:

>
> Alas, it can't.  Using it against LI would work, cause you have a hope of
> knowing what address space their proxies are in.
>

LI's behavior is unique.  LI is probably the only one you need to detect.


> You can't do that generically, unless you somehow whitelist the IPs your
> users will be validly coming from, or figure out a way to determine what
> client is connecting.
>

This may be easier than you think,  if remote account access is allowed
only using Web-based mail, and company managed mobile devices.
 Whitelist the  cell carrier's  mobile network, using ActiveSync.

An IMAP connection attempt from anywhere is immediately suspect.



> -- jra
>
--
-JH

From righa.shake at gmail.com  Mon Oct 28 05:45:00 2013
From: righa.shake at gmail.com (Righa Shake)
Date: Mon, 28 Oct 2013 08:45:00 +0300
Subject: Technical Contact - Global Crossing
Message-ID: <CAJO3VzzPRLVRR=gu3ywwmu4LHYUJHUCh9WSxojb-YWtv=hfXzw@mail.gmail.com>

Dear All,

Kindly would a contact from Global Crossing contact me off list.

Regards,
Righa Shake

From j at arpa.com  Mon Oct 28 10:27:41 2013
From: j at arpa.com (jamie rishaw)
Date: Mon, 28 Oct 2013 05:27:41 -0500
Subject: NOOP and Terremark
Message-ID: <CABL6YZT6HgGVo1cU1Hwj-P5hSvhnByvr6JC6eq5w-prTmJxTyg@mail.gmail.com>

1) Thank you all for responses in private re my 80Gbps thread - It's clear
that we all still consider open discussions on things like this to be
something to be kept to a small vetted community.

2) Surprised to see no threads on Terremark's epic fail w/r/t Fed-Cloud and
healthcare.gov.  News articles are of zero help since reporters have -no-
idea what the truth is and will believe anything fed to them by tech types
to get an article posted; Still curious about the actual RFO...

-jamie

From rdobbins at arbor.net  Mon Oct 28 11:35:14 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 28 Oct 2013 11:35:14 +0000
Subject: NOOP and Terremark
In-Reply-To: <CABL6YZT6HgGVo1cU1Hwj-P5hSvhnByvr6JC6eq5w-prTmJxTyg@mail.gmail.com>
References: <CABL6YZT6HgGVo1cU1Hwj-P5hSvhnByvr6JC6eq5w-prTmJxTyg@mail.gmail.com>
Message-ID: <1E91403D-3F1B-4E23-8563-9439E8F500E6@arbor.net>


On Oct 28, 2013, at 5:27 PM, jamie rishaw <j at arpa.com> wrote:

>  It's clear that we all still consider open discussions on things like this to be something to be kept to a small vetted community.

It's not clear to me at all.

Real-time discussions of specific events in order to coordinate response, sure - it's important to limit those communications to the groups/individuals who can do something useful to help in real time.  

General discussion of attack characteristics, defensive tactics, etc., absolutely not - they must be shouted from the rooftops.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From jamie at photon.com  Mon Oct 28 12:33:30 2013
From: jamie at photon.com (Jamie Bowden)
Date: Mon, 28 Oct 2013 12:33:30 +0000
Subject: Network configuration archiving
In-Reply-To: <op.w5ja8og2tfhldh@rbeam.xactional.com>
References: <20131024212526.GC14735@Eleanor.local>
 <20131025115948.GF10952@rootmail.cc.le.ac.uk>
 <CAB73c3o+04gapuCL_Lym+AYpkBnFt39CRb+CjUroC10KMv1AAw@mail.gmail.com>
 <op.w5ja8og2tfhldh@rbeam.xactional.com>
Message-ID: <465966A5F5B867419F604CD3E604C1E54D9B35B6@PRA-DCA-MAIL.pra.ray.com>

> From: Ricky Beam [mailto:jfbeam at gmail.com]
> On Fri, 25 Oct 2013 08:08:44 -0400, Michael Kehoe
> <michael.k.kehoe at gmail.com> wrote:
> > As far as I'm aware (someone please correct me if I'm wrong), but Cisco
> > is the only vendor that supports this.
> 
> Ascend did as well.  I used to backup the MAX-TNT's via snmp.

Made them easier to recover after they caught on fire?

Jamie


From luca at ninefold.com  Mon Oct 28 03:02:24 2013
From: luca at ninefold.com (Luca Salvatore)
Date: Mon, 28 Oct 2013 14:02:24 +1100
Subject: Contact at Cogenet
Message-ID: <CA+w93SsbSi6TRep5hxM53zrPw4b5PG7cF=WC=dpQY+cJNE3imA@mail.gmail.com>

Hi,
If there is anyone on list that can help me out with a routing issue with
Cogenet could you please contact me off list?
Specifically with this router  - gi9-37.mag01.mad05.atlas.cogentco.com

Thanks

From leo.vegoda at icann.org  Mon Oct 28 14:09:10 2013
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Mon, 28 Oct 2013 07:09:10 -0700
Subject: If you're on LinkedIn, and you use a smart phone...
In-Reply-To: <CAAAwwbUYFtTj3Yx8YeYdWh_Fv5u+dv6xhz+SjjGwMWv2FEva0Q@mail.gmail.com>
References: <CAAAwwbU8ct0RnVJmQ0XiWA34PWzE_eDTyjC34FAtnZ6=Duh-KA@mail.gmail.com>
 <2245767.2787.1382897987168.JavaMail.root@benjamin.baylink.com>
 <CAAAwwbUYFtTj3Yx8YeYdWh_Fv5u+dv6xhz+SjjGwMWv2FEva0Q@mail.gmail.com>
Message-ID: <5648A8908CCB564EBF46E2BC904A75B19680B6D117@EXVPMBX100-1.exc.icann.org>

Jimmy Hess wrote:

[...]

> This may be easier than you think,  if remote account access is
allowed
> only using Web-based mail, and company managed mobile devices.
> Whitelist the  cell carrier's  mobile network, using ActiveSync.
> 
> An IMAP connection attempt from anywhere is immediately suspect.

This assumes good mobile data signal and no use of home WiFi, hotel
WiFi, airport WiFi etc...

I'm not convinced your proposal is much better than stopping the device
from being useful in a significant proportion of the situations it would
be used.  
-------------- 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/20131028/d107f790/attachment.bin>

From j at arpa.com  Mon Oct 28 15:01:01 2013
From: j at arpa.com (jamie rishaw)
Date: Mon, 28 Oct 2013 10:01:01 -0500
Subject: NOOP and Terremark
In-Reply-To: <1E91403D-3F1B-4E23-8563-9439E8F500E6@arbor.net>
References: <CABL6YZT6HgGVo1cU1Hwj-P5hSvhnByvr6JC6eq5w-prTmJxTyg@mail.gmail.com>
 <1E91403D-3F1B-4E23-8563-9439E8F500E6@arbor.net>
Message-ID: <CABL6YZRgH3jYByw_BA5h+MDbJ4HtaCy4zw+-6MpZ3rHER+aCEA@mail.gmail.com>

I'm sorry, I should have phrased differently.

I meant: By the number of responses I've received that have been told to me
"in private," or with a "this is not public info,"...

While I certainly would not violate those restraints I do agree with you.

jamie



On Mon, Oct 28, 2013 at 6:35 AM, Dobbins, Roland <rdobbins at arbor.net> wrote:

>
> On Oct 28, 2013, at 5:27 PM, jamie rishaw <j at arpa.com> wrote:
>
> >  It's clear that we all still consider open discussions on things like
> this to be something to be kept to a small vetted community.
>
> It's not clear to me at all.
>
> Real-time discussions of specific events in order to coordinate response,
> sure - it's important to limit those communications to the
> groups/individuals who can do something useful to help in real time.
>
> General discussion of attack characteristics, defensive tactics, etc.,
> absolutely not - they must be shouted from the rooftops.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>           Luck is the residue of opportunity and design.
>
>                        -- John Milton
>
>
>


-- 
jamie rishaw // .com.arpa at j <- reverse it. ish.

*"Reality defeats prejudice."* - *Rep. Barney Frank*

From rdobbins at arbor.net  Mon Oct 28 15:29:07 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 28 Oct 2013 15:29:07 +0000
Subject: Repost:  links to DDoS-related press & reports.
Message-ID: <D06A7167-D25C-449B-8CA6-598C8076961B@arbor.net>


A couple of folks have asked me privately for links to some presos on DDoS, BCPs, et. al., so I'm re-posting the links here, for future citation:

DDoS & BCP presos:

<https://app.box.com/s/4h2l6f4m8is6jnwk28cg>

2009 - 2011 Arbor WISRs:

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

Current Arbor WISR:

<http://www.arbornetworks.com/report>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From bmanning at vacation.karoshi.com  Mon Oct 28 18:13:03 2013
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 28 Oct 2013 18:13:03 +0000
Subject: Repost:  links to DDoS-related press & reports.
In-Reply-To: <D06A7167-D25C-449B-8CA6-598C8076961B@arbor.net>
References: <D06A7167-D25C-449B-8CA6-598C8076961B@arbor.net>
Message-ID: <20131028181303.GD3367@vacation.karoshi.com.>

On Mon, Oct 28, 2013 at 03:29:07PM +0000, Dobbins, Roland wrote:
> 
> A couple of folks have asked me privately for links to some presos on DDoS, BCPs, et. al., so I'm re-posting the links here, for future citation:
> 
> DDoS & BCP presos:
> 
> <https://app.box.com/s/4h2l6f4m8is6jnwk28cg>
> 
> 2009 - 2011 Arbor WISRs:
> 
> <https://app.box.com/s/llwlaowbthppliyze2uw>
> 
> Current Arbor WISR:
> 
> <http://www.arbornetworks.com/report>
> 
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
> 

	and this gem...

	http://technology.ie/digital-attack-map-shows-ddos-attacks/


From jimpop at gmail.com  Tue Oct 29 16:11:27 2013
From: jimpop at gmail.com (Jim Popovitch)
Date: Tue, 29 Oct 2013 12:11:27 -0400
Subject: VZ FIOS SoCo traceroute plea
Message-ID: <CAGfsgR1CqNhW1rraFJggeXaStes3dxVBZC4OYF9xysCBCtkMcQ@mail.gmail.com>

Hello,

A desperate plea, since apparently VZ still doesn't have a public
routeserver. :-(

I need a trace from a VZ FIOS connection in Southern California, to
96.44.148.54 (Quadranet, DFW).

Private replies are welcome and encouraged.

Thank you, sorry for the noise.

-Jim P.


From kate at quadranet.com  Tue Oct 29 16:31:05 2013
From: kate at quadranet.com (Kate Gerry)
Date: Tue, 29 Oct 2013 09:31:05 -0700
Subject: VZ FIOS SoCo traceroute plea
In-Reply-To: <CAGfsgR1CqNhW1rraFJggeXaStes3dxVBZC4OYF9xysCBCtkMcQ@mail.gmail.com>
References: <CAGfsgR1CqNhW1rraFJggeXaStes3dxVBZC4OYF9xysCBCtkMcQ@mail.gmail.com>
Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F6F3960380A3@EXCH>

Jim,

Email me off-list if you're experiencing trouble. But here is the traceroute you requested:

traceroute to 96.44.148.54 (96.44.148.54), 30 hops max, 40 byte packets
 1  L100.LSANCA-VFTTP-158.verizon-gni.net (108.38.63.1)  1.243 ms  0.897 ms  1.750 ms
 2  G0-3-1-7.LSANCA-LCR-21.verizon-gni.net (130.81.140.224)  10.788 ms  9.447 ms  11.620 ms
 3  so-6-0-0-0.LAX01-BB-RTR1.verizon-gni.net (130.81.29.124)  21.252 ms ae1-0.LAX01-BB-RTR1.verizon-gni.net (130.81.199.90)  7.900 ms so-6-0-0-0.LAX01-BB-RTR1.verizon-gni.net (130.81.29.124)  8.409 ms
 4  0.xe-10-1-0.BR1.LAX15.ALTER.NET (152.63.112.245)  8.310 ms 0.xe-4-1-0.BR1.LAX15.ALTER.NET (152.63.112.229)  5.198 ms  5.463 ms
 5  ae-7.r05.lsanca03.us.bb.gin.ntt.net (129.250.8.85)  5.832 ms  5.943 ms  5.839 ms
 6  ae-2.r20.lsanca03.us.bb.gin.ntt.net (129.250.2.229)  21.661 ms  34.215 ms  19.353 ms
 7  ae-4.r20.dllstx09.us.bb.gin.ntt.net (129.250.2.169)  38.375 ms  67.575 ms  38.780 ms
 8  ae-2.r07.dllstx09.us.bb.gin.ntt.net (129.250.3.67)  40.432 ms  44.100 ms  43.442 ms
 9  ae9.ar1.dfw1.us.nlayer.net (69.31.63.168)  44.362 ms  44.263 ms  41.277 ms
10  69.31.54.194 (69.31.54.194)  36.695 ms  39.742 ms  39.902 ms
11  quadranet-colocrossing.quadranet.com (96.44.148.54)  41.168 ms  41.669 ms  41.754 ms

--
Kate Gerry
Network Manager
kate at quadranet.com
<signature snip>


-----Original Message-----
From: Jim Popovitch [mailto:jimpop at gmail.com] 
Sent: Tuesday, October 29, 2013 9:11 AM
To: nanog at nanog.org
Subject: VZ FIOS SoCo traceroute plea

Hello,

A desperate plea, since apparently VZ still doesn't have a public routeserver. :-(

I need a trace from a VZ FIOS connection in Southern California, to
96.44.148.54 (Quadranet, DFW).

Private replies are welcome and encouraged.

Thank you, sorry for the noise.

-Jim P.



From cvuljanic at gmail.com  Tue Oct 29 16:33:39 2013
From: cvuljanic at gmail.com (Craig)
Date: Tue, 29 Oct 2013 12:33:39 -0400
Subject: VZ FIOS SoCo traceroute plea
In-Reply-To: <CAGfsgR1CqNhW1rraFJggeXaStes3dxVBZC4OYF9xysCBCtkMcQ@mail.gmail.com>
References: <CAGfsgR1CqNhW1rraFJggeXaStes3dxVBZC4OYF9xysCBCtkMcQ@mail.gmail.com>
Message-ID: <CAJ=P5abofWo8VUHfJG3f9Jt4mOxwfktYaiF=qbw=nVm2sLxg0w@mail.gmail.com>

sorry for no DNS:

traceroute to 96.44.148.54 from 10.10.10.1, 30 hops max, 36 byte packets
 1	   0.0 ms	   0.0 ms	   0.0 ms	 71.245.189.1	
 2	   0.0 ms	  16.6 ms	  16.6 ms	 130.81.216.174	
 3	   0.0 ms	   0.0 ms	  33.3 ms	 130.81.209.76	
 4	  16.6 ms	  16.6 ms	  33.3 ms	 152.63.3.125	
 5	  16.6 ms	  16.6 ms	  16.6 ms	 129.250.8.37	
 6	  33.3 ms	  33.3 ms	  16.6 ms	 129.250.3.16	
 7	  50.0 ms	  50.0 ms	  50.0 ms	 129.250.3.51	
 8	  50.0 ms	  50.0 ms	  50.0 ms	 129.250.3.67	
 9	  50.0 ms	  66.6 ms	  50.0 ms	 69.31.63.168	
10	  50.0 ms	  50.0 ms	  50.0 ms	 69.31.54.194	
11	  50.0 ms	  50.0 ms	  50.0 ms	 96.44.148.54	

Trace complete.



On Tue, Oct 29, 2013 at 12:11 PM, Jim Popovitch <jimpop at gmail.com> wrote:

> Hello,
>
> A desperate plea, since apparently VZ still doesn't have a public
> routeserver. :-(
>
> I need a trace from a VZ FIOS connection in Southern California, to
> 96.44.148.54 (Quadranet, DFW).
>
> Private replies are welcome and encouraged.
>
> Thank you, sorry for the noise.
>
> -Jim P.
>
>

From morrowc.lists at gmail.com  Tue Oct 29 17:50:55 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 29 Oct 2013 13:50:55 -0400
Subject: VZ FIOS SoCo traceroute plea
In-Reply-To: <CAJ=P5abofWo8VUHfJG3f9Jt4mOxwfktYaiF=qbw=nVm2sLxg0w@mail.gmail.com>
References: <CAGfsgR1CqNhW1rraFJggeXaStes3dxVBZC4OYF9xysCBCtkMcQ@mail.gmail.com>
 <CAJ=P5abofWo8VUHfJG3f9Jt4mOxwfktYaiF=qbw=nVm2sLxg0w@mail.gmail.com>
Message-ID: <CAL9jLaYvACoRp-n9QPP2QnT4ehDTvPZWWmPUwgxK2ujwFk6+0Q@mail.gmail.com>

vz does peer with routeviews... which at least tells you if 701 sees
the routes in question, eh?

On Tue, Oct 29, 2013 at 12:33 PM, Craig <cvuljanic at gmail.com> wrote:
> sorry for no DNS:
>
> traceroute to 96.44.148.54 from 10.10.10.1, 30 hops max, 36 byte packets
>  1         0.0 ms          0.0 ms          0.0 ms        71.245.189.1
>  2         0.0 ms         16.6 ms         16.6 ms        130.81.216.174
>  3         0.0 ms          0.0 ms         33.3 ms        130.81.209.76
>  4        16.6 ms         16.6 ms         33.3 ms        152.63.3.125
>  5        16.6 ms         16.6 ms         16.6 ms        129.250.8.37
>  6        33.3 ms         33.3 ms         16.6 ms        129.250.3.16
>  7        50.0 ms         50.0 ms         50.0 ms        129.250.3.51
>  8        50.0 ms         50.0 ms         50.0 ms        129.250.3.67
>  9        50.0 ms         66.6 ms         50.0 ms        69.31.63.168
> 10        50.0 ms         50.0 ms         50.0 ms        69.31.54.194
> 11        50.0 ms         50.0 ms         50.0 ms        96.44.148.54
>
> Trace complete.
>
>
>
> On Tue, Oct 29, 2013 at 12:11 PM, Jim Popovitch <jimpop at gmail.com> wrote:
>
>> Hello,
>>
>> A desperate plea, since apparently VZ still doesn't have a public
>> routeserver. :-(
>>
>> I need a trace from a VZ FIOS connection in Southern California, to
>> 96.44.148.54 (Quadranet, DFW).
>>
>> Private replies are welcome and encouraged.
>>
>> Thank you, sorry for the noise.
>>
>> -Jim P.
>>
>>


From network.ipdog at gmail.com  Tue Oct 29 18:29:01 2013
From: network.ipdog at gmail.com (Network IPdog)
Date: Tue, 29 Oct 2013 11:29:01 -0700
Subject: VZ FIOS SoCo traceroute plea
In-Reply-To: <CAL9jLaYvACoRp-n9QPP2QnT4ehDTvPZWWmPUwgxK2ujwFk6+0Q@mail.gmail.com>
References: <CAGfsgR1CqNhW1rraFJggeXaStes3dxVBZC4OYF9xysCBCtkMcQ@mail.gmail.com>
 <CAJ=P5abofWo8VUHfJG3f9Jt4mOxwfktYaiF=qbw=nVm2sLxg0w@mail.gmail.com>
 <CAL9jLaYvACoRp-n9QPP2QnT4ehDTvPZWWmPUwgxK2ujwFk6+0Q@mail.gmail.com>
Message-ID: <526ffe6e.a186440a.1ef6.ffffd23d@mx.google.com>

>From FIOS...   Long Beach, CA

tracert 96.44.148.54

Tracing route to quadranet-colocrossing.quadranet.com [96.44.148.54]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.100.1
  2     1 ms     1 ms     1 ms  192.168.1.1
  3     6 ms     7 ms     7 ms  L100.LSANCA-VFTTP-114.verizon-gni.net
[173.58.211.1]
  4    13 ms    12 ms    11 ms  130.81.185.70
  5    11 ms    10 ms    11 ms  ae10-0.LAX01-BB-RTR2.verizon-gni.net
[130.81.199.106]
  6    46 ms    10 ms    11 ms  0.xe-11-1-0.BR1.LAX15.ALTER.NET
[152.63.114.113]
  7    16 ms    11 ms    11 ms  ae-7.r05.lsanca03.us.bb.gin.ntt.net
[129.250.8.85]
  8    15 ms    13 ms    40 ms  ae-2.r20.lsanca03.us.bb.gin.ntt.net
[129.250.2.229]
  9    46 ms    44 ms    43 ms  ae-4.r20.dllstx09.us.bb.gin.ntt.net
[129.250.2.169]
 10    46 ms    46 ms    45 ms  ae-2.r07.dllstx09.us.bb.gin.ntt.net
[129.250.3.67]
 11    49 ms    51 ms    46 ms  ae9.ar1.dfw1.us.nlayer.net [69.31.63.168]
 12    62 ms    47 ms   115 ms  69.31.54.194
 13    50 ms    45 ms    49 ms  quadranet-colocrossing.quadranet.com
[96.44.148.54]

Trace complete.


Ruff, Ruff...!

Network IPdog

Ephesians 4:32  &  Cheers!!!

A password is like a... toothbrush  ;^) 
Choose a good one, change it regularly and don't share it.

-----Original Message-----
From: Christopher Morrow [mailto:morrowc.lists at gmail.com] 
Sent: Tuesday, October 29, 2013 10:51 AM
To: Craig
Cc: nanog group
Subject: Re: VZ FIOS SoCo traceroute plea

vz does peer with routeviews... which at least tells you if 701 sees the
routes in question, eh?

On Tue, Oct 29, 2013 at 12:33 PM, Craig <cvuljanic at gmail.com> wrote:
> sorry for no DNS:
>
> traceroute to 96.44.148.54 from 10.10.10.1, 30 hops max, 36 byte packets
>  1         0.0 ms          0.0 ms          0.0 ms        71.245.189.1
>  2         0.0 ms         16.6 ms         16.6 ms        130.81.216.174
>  3         0.0 ms          0.0 ms         33.3 ms        130.81.209.76
>  4        16.6 ms         16.6 ms         33.3 ms        152.63.3.125
>  5        16.6 ms         16.6 ms         16.6 ms        129.250.8.37
>  6        33.3 ms         33.3 ms         16.6 ms        129.250.3.16
>  7        50.0 ms         50.0 ms         50.0 ms        129.250.3.51
>  8        50.0 ms         50.0 ms         50.0 ms        129.250.3.67
>  9        50.0 ms         66.6 ms         50.0 ms        69.31.63.168
> 10        50.0 ms         50.0 ms         50.0 ms        69.31.54.194
> 11        50.0 ms         50.0 ms         50.0 ms        96.44.148.54
>
> Trace complete.
>
>
>
> On Tue, Oct 29, 2013 at 12:11 PM, Jim Popovitch <jimpop at gmail.com> wrote:
>
>> Hello,
>>
>> A desperate plea, since apparently VZ still doesn't have a public 
>> routeserver. :-(
>>
>> I need a trace from a VZ FIOS connection in Southern California, to
>> 96.44.148.54 (Quadranet, DFW).
>>
>> Private replies are welcome and encouraged.
>>
>> Thank you, sorry for the noise.
>>
>> -Jim P.
>>
>>



From greg.whynott at gmail.com  Tue Oct 29 20:57:59 2013
From: greg.whynott at gmail.com (greg whynott)
Date: Tue, 29 Oct 2013 16:57:59 -0400
Subject: NFSen plugin - ddd
In-Reply-To: <51cd90256dc62e6de54aa3a7d1f49f70@localhost>
References: <49f9d2ec16de2c67b51a0229dcf18510@localhost>
 <20120805230856.GA55456@DataIX.net>
 <51cd90256dc62e6de54aa3a7d1f49f70@localhost>
Message-ID: <CAKuzA1GEUnEXkymzG9NNYwzLm2iFLUz2hMkwK5+skDOh4XTOpQ@mail.gmail.com>

now both SGI and Apple will sue them!

sad how apple can get a patent on curved corners...

it has a nice tezro look to it.   wrong color tho.




On Mon, Aug 6, 2012 at 10:40 PM, Andrew Jones <aj at jonesy.com.au> wrote:

> I did manage to get my hands on it this morning (thanks Brandon!).
> I've put it up for anyone who's interested [1], I had a couple of people
> ask for a copy if I found it.
> I haven't had a chance to look through the plugin yet, so take no
> responsibility for it.
> Cheers,
> Jonesy
>
> [1] http://www.haqthegibson.com/files/ddd.zip
>
>
> On Sun, 5 Aug 2012 19:08:56 -0400, Jason Hellenthal
> <jhellenthal at dataix.net> wrote:
> > Don't know if you ever recieved a reply for this but this is the best I
> > have come up with to get more eyes on it.
> >
> > http://sourceforge.net/apps/trac/nfsen-plugins/wiki/RequestPlugin
> >
> > I have not submitted a request for it but if you happen to come accross
> > this plugin, I would be interested.
> >
> > On Fri, Aug 03, 2012 at 01:55:21PM +1000, Andrew Jones wrote:
> >> Hi All,
> >> Does anyone have a copy of the DDoS detection plugin for NFSen called
> ddd
> >> that they could send to me?
> >> According to a blog article [1] I read, it used to be available at [2].
> >> It's not there, and I haven't had any luck trying to track it down the
> >> usual ways. If anyone is able to provide a copy, I'd appreciate it.
> >> Thanks,
> >> Jonesy
> >>
> >>
> >> [1] http://www.ccieflyer.com/2010-01-JasonRowley.php
> >> [2] http://www.synacknetworks.com/ddd/ddd.zip
>
>

From jra at baylink.com  Wed Oct 30 02:51:35 2013
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 29 Oct 2013 22:51:35 -0400
Subject: Happy Birthday, ARPANET!
Message-ID: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>

The Paley Center for Media reminds us that on this day in 1969 at 2230 PST, the first link was turned up between UCLAs Sigma 7 and SRIs 940.

A photo of the laboratory logbook is included in the Wikipedia article:

en.m.wikipedia.org/wiki/ARPANET

Cheers,
- jra

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

From mike at mtcc.com  Wed Oct 30 03:07:56 2013
From: mike at mtcc.com (Michael Thomas)
Date: Tue, 29 Oct 2013 20:07:56 -0700
Subject: Happy Birthday, ARPANET!
In-Reply-To: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>
References: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>
Message-ID: <5270780C.6010805@mtcc.com>

On 10/29/2013 07:51 PM, Jay Ashworth wrote:
> The Paley Center for Media reminds us that on this day in 1969 at 2230 PST, the first link was turned up between UCLAs Sigma 7 and SRIs 940.
>


OMG: I didn't know that I've actually worked on one of the net's first 
machines. Though not at
the time, but a Sigma 7 at UCI in the late 70's.

Mike


From trelane at trelane.net  Wed Oct 30 03:27:40 2013
From: trelane at trelane.net (Andrew D Kirch)
Date: Tue, 29 Oct 2013 23:27:40 -0400
Subject: Happy Birthday, ARPANET!
In-Reply-To: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>
References: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>
Message-ID: <52707CAC.8080509@trelane.net>

On 10/29/2013 10:51 PM, Jay Ashworth wrote:
> The Paley Center for Media reminds us that on this day in 1969 at 2230 PST, the first link was turned up between UCLAs Sigma 7 and SRIs 940.
>
> A photo of the laboratory logbook is included in the Wikipedia article:
>
> en.m.wikipedia.org/wiki/ARPANET
>
> Cheers,
> - jra
>
crap, I'm supposed to be keeping a log book?  No one told me... err do I 
have to log _EVERYTHING_ I do online? :/

Happy Birthday, Internet!

Andrew


From jra at baylink.com  Wed Oct 30 03:55:17 2013
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 29 Oct 2013 23:55:17 -0400
Subject: Happy Birthday, ARPANET!
In-Reply-To: <52707CAC.8080509@trelane.net>
References: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>
 <52707CAC.8080509@trelane.net>
Message-ID: <0af77b9e-e3a7-454a-8722-df8b0b33e696@email.android.com>

<sheldon>
In fact, not quite.

The birthday of the internet proper is generally held to be January 1, 1983, the flag day when tcp/ip was first deployed.
</sheldon>

Andrew D Kirch <trelane at trelane.net> wrote:
>On 10/29/2013 10:51 PM, Jay Ashworth wrote:
>> The Paley Center for Media reminds us that on this day in 1969 at
>2230 PST, the first link was turned up between UCLAs Sigma 7 and SRIs
>940.
>>
>> A photo of the laboratory logbook is included in the Wikipedia
>article:
>>
>> en.m.wikipedia.org/wiki/ARPANET
>>
>> Cheers,
>> - jra
>>
>crap, I'm supposed to be keeping a log book?  No one told me... err do
>I 
>have to log _EVERYTHING_ I do online? :/
>
>Happy Birthday, Internet!
>
>Andrew

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

From joly at punkcast.com  Wed Oct 30 04:07:42 2013
From: joly at punkcast.com (Joly MacFie)
Date: Wed, 30 Oct 2013 00:07:42 -0400
Subject: Happy Birthday, ARPANET!
In-Reply-To: <0af77b9e-e3a7-454a-8722-df8b0b33e696@email.android.com>
References: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>
 <52707CAC.8080509@trelane.net>
 <0af77b9e-e3a7-454a-8722-df8b0b33e696@email.android.com>
Message-ID: <CAM9VJk0DJiQgGnmgBn-b=ZJdrZ2jCCc6TXduTKmv=M-aH6RbrQ@mail.gmail.com>

It seems the Internet Society is going with October 29.

http://www.internetsociety.org/international-internet-day

On Tue, Oct 29, 2013 at 11:55 PM, Jay Ashworth <jra at baylink.com> wrote:
> <sheldon>
> In fact, not quite.
>
> The birthday of the internet proper is generally held to be January 1, 1983, the flag day when tcp/ip was first deployed.
> </sheldon>
>
> Andrew D Kirch <trelane at trelane.net> wrote:
>>On 10/29/2013 10:51 PM, Jay Ashworth wrote:
>>> The Paley Center for Media reminds us that on this day in 1969 at
>>2230 PST, the first link was turned up between UCLAs Sigma 7 and SRIs
>>940.
>>>
>>> A photo of the laboratory logbook is included in the Wikipedia
>>article:
>>>
>>> en.m.wikipedia.org/wiki/ARPANET
>>>
>>> Cheers,
>>> - jra
>>>
>>crap, I'm supposed to be keeping a log book?  No one told me... err do
>>I
>>have to log _EVERYTHING_ I do online? :/
>>
>>Happy Birthday, Internet!
>>
>>Andrew
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.



-- 
---------------------------------------------------------------
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 dougb at dougbarton.us  Wed Oct 30 06:14:03 2013
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 29 Oct 2013 23:14:03 -0700
Subject: Happy Birthday, ARPANET!
In-Reply-To: <CAM9VJk0DJiQgGnmgBn-b=ZJdrZ2jCCc6TXduTKmv=M-aH6RbrQ@mail.gmail.com>
References: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>
 <52707CAC.8080509@trelane.net>
 <0af77b9e-e3a7-454a-8722-df8b0b33e696@email.android.com>
 <CAM9VJk0DJiQgGnmgBn-b=ZJdrZ2jCCc6TXduTKmv=M-aH6RbrQ@mail.gmail.com>
Message-ID: <5270A3AB.7070801@dougbarton.us>

lo


From joly at punkcast.com  Wed Oct 30 07:00:31 2013
From: joly at punkcast.com (Joly MacFie)
Date: Wed, 30 Oct 2013 03:00:31 -0400
Subject: Happy Birthday, ARPANET!
In-Reply-To: <5270A3AB.7070801@dougbarton.us>
References: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>
 <52707CAC.8080509@trelane.net>
 <0af77b9e-e3a7-454a-8722-df8b0b33e696@email.android.com>
 <CAM9VJk0DJiQgGnmgBn-b=ZJdrZ2jCCc6TXduTKmv=M-aH6RbrQ@mail.gmail.com>
 <5270A3AB.7070801@dougbarton.us>
Message-ID: <CAM9VJk06T25RCZBiCPU8jfYA-FQRb=ZkxORjiia-ZsFQyK8gaA@mail.gmail.com>

and surely no coincidence that Oct 29 is also National Cat Day
http://www.nationalcatday.com/

On Wed, Oct 30, 2013 at 2:14 AM, Doug Barton <dougb at dougbarton.us> wrote:
> lo
>



-- 
---------------------------------------------------------------
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 tshaw at oitc.com  Wed Oct 30 11:38:39 2013
From: tshaw at oitc.com (TR Shaw)
Date: Wed, 30 Oct 2013 07:38:39 -0400
Subject: Happy Birthday, ARPANET!
In-Reply-To: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>
References: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>
Message-ID: <76BDDF71-FAF2-4453-8EE9-8E5A6AC5FE84@oitc.com>

Yikes! First it was the PDP in the British Museum and now a Sigma.  I don't feel old enough for the museum...

On Oct 29, 2013, at 10:51 PM, Jay Ashworth wrote:

> The Paley Center for Media reminds us that on this day in 1969 at 2230 PST, the first link was turned up between UCLAs Sigma 7 and SRIs 940.
> 
> A photo of the laboratory logbook is included in the Wikipedia article:
> 
> en.m.wikipedia.org/wiki/ARPANET
> 
> Cheers,
> - jra
> 
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.



From Jack.Stonebraker at mygrande.com  Wed Oct 30 15:42:29 2013
From: Jack.Stonebraker at mygrande.com (Jack Stonebraker)
Date: Wed, 30 Oct 2013 15:42:29 +0000
Subject: DDoS Prevention for a Transit Provider
Message-ID: <1C88157B8801CB448C108286C81ECB6308D4A1@SRV-SAM-MBOX02.lan.thrifty.net>

I'm looking to pick the brain of any Engineers out there who have deployed a DDoS Prevention strategy for an MSO that also runs their own transport network.  Recently, we have been seeing increasingly large spikes of traffic traversing our core.  We have determined the destination to be arbitrary, but often it is some host (A Customer CPE) south of one of our CMTS's.  While we enforce ingress and egress rate limits facing the customers, the core facing network is pretty wide open, allowing the BGP mesh to steer traffic as needed.

Initially, we've been trying to do root analysis of the traffic makeup via JFLOW data to see if simple ACL's might be a temporary stop gap, but I also want to explore a more elegant, long term solution.

The introduction of IPS's feels cost prohibitive, especially since they would need to performing control at the core, as we provide wholesale transport services on top of our enterprise services and that makes for a huge amount of homogenized traffic to be inspected.

Generally, the core can weather these spikes.  Instead, it's the edge end corresponding L3 to L2 Trunks that becomes saturated.

Any thoughts or comments would be greatly appreciated.  Thanks.

JJ Stonebraker
IP Network Engineering
Grande Communications

From rdobbins at arbor.net  Wed Oct 30 16:07:42 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 30 Oct 2013 16:07:42 +0000
Subject: DDoS Prevention for a Transit Provider
In-Reply-To: <1C88157B8801CB448C108286C81ECB6308D4A1@SRV-SAM-MBOX02.lan.thrifty.net>
References: <1C88157B8801CB448C108286C81ECB6308D4A1@SRV-SAM-MBOX02.lan.thrifty.net>
Message-ID: <35E22F7E-A9EC-439C-BF14-B5A1DD788B14@arbor.net>


On Oct 30, 2013, at 10:42 PM, Jack Stonebraker <Jack.Stonebraker at mygrande.com> wrote:

> Any thoughts or comments would be greatly appreciated.  Thanks.

<http://mailman.nanog.org/pipermail/nanog/2010-January/016747.html>

<http://mailman.nanog.org/pipermail/nanog/2013-October/061862.html>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From nrollo at kw-corp.com  Wed Oct 30 16:12:31 2013
From: nrollo at kw-corp.com (Nolan Rollo)
Date: Wed, 30 Oct 2013 16:12:31 +0000
Subject: Reverse DNS RFCs and Recommendations
Message-ID: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>

I've been (probably needlessly) pouring over the Reverse DNS RFCs for long enough to actually have questions about a subject that should be relatively unimportant. I do want to make sure that we set up our reverse DNS correctly and most efficiently the first time so that we don't irritate other network operators  with difficult regex based filtering ( http://www.gossamer-threads.com/lists/nanog/users/113633 ) and we don't have to change things as per a recommendation down the road.

RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
When using IP addresses in host names, their numbers SHOULD be
   separated by '.'s (dots) rather than any meta character such as a '-'
   (dash) and expressed in decimal.  Host names SHOULD NOT use the '_'
   (underscore) character, host names for hosts with any form of SMTP
   mail service MUST NOT use the '_' (underscore) character.  It is
   preferable to use the IP address in reverse format in the same way
   the the IN-ADDR.ARPA. domain is defined.

Now since it is only a first revision draft I'm taking what it has to say with a grain of salt and it seems has taken quite a bit of criticism on forums. I'm also not singling out on Time Warner, WOW, Comcast or Charter for their naming conventions nor do I think they are bad, I'm just using them as examples because they are local, well-known ISPs.

Actual Examples:
cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX
d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX
c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX
24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX

*Most ISP Reverse DNS Hostnames (from what I've observed) seem to use the dash "-" character with the forward format, as opposed to the reverse IN-ADDR.ARPA. dotted scheme as recommended in the draft
*Comcast and Charter all have geographic based furthest-right-hand tokens.
*Charter, WideOpenWest, Time Warner, and Comcast all have some acronym that is not immediately clear, at least to me (HSD - High Speed Data?, BYCY - Bay City, MI?, DIM - Dynamic IP Mapping?, STNY - Southern Tier New York?)

Which finally brings me to my questions:
It seems like the unspoken de facto that mail admins appreciate given the IP 203.0.113.15 is "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This seems perfectly acceptable, it's short, detailed and to the point. Is there really anything bad about this?

What, if any would you name a network, gateway, broadcast address? Should the PTR be empty?

<tinfoilhat> I've seen a lot about naming what type of technology it is (wireless, adsl, cable, etc.) in order to filter out the "high speed spammers". It seems to me that this would open up the likelihood of a targeted attack. We've all heard of security though obscurity and of course no one relies on it but we have to face the fact there are CVEs every day for various networking hardware/firmware. If an attacker can query DNS and find out that the IP is for wireless they could filter all wireless gear exploits. Is this still a good practice given the abundance of high speed data connections or is this just opening yourself up to reconnaissance?</tinfoilhat>

There is a Merit Network mailing list discussion that outlines most of what I've read that can be found here ( http://www.merit.edu/mail.archives/nanog/msg06843.html )

Nolan Rollo
VoIP Engineer
Main: 517.223.3610x114
Fax: 517.223.4120
www.kw-corp.com<http://www.kw-corp.com/>


From nick at foobar.org  Wed Oct 30 16:24:42 2013
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 30 Oct 2013 16:24:42 +0000
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
Message-ID: <527132CA.5050709@foobar.org>

> relatively unimportant. I do want to make sure that we set up our
> reverse DNS correctly

the only thing that's important is that forward and reverse DNS matches.
After that, there is no correct or incorrect, so you need to do something
that makes sense for your deployment.

Nick



From asullivan at dyn.com  Wed Oct 30 16:55:37 2013
From: asullivan at dyn.com (Andrew Sullivan)
Date: Wed, 30 Oct 2013 12:55:37 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <527132CA.5050709@foobar.org>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org>
Message-ID: <20131030165536.GC525@dyn.com>

On Wed, Oct 30, 2013 at 04:24:42PM +0000, Nick Hilliard wrote:
> the only thing that's important is that forward and reverse DNS matches.

As I think I've said before on this list, when we tried to get
consensus on that claim in the DNSOP WG at the IETF, we couldn't.
Indeed, we couldn't even get consensus on the much more bland
statement, "Some people rely on the reverse, and you might want to
take that into consideration when running your services."  

Now, IETF non-consensus on the way the Internet works is hardly a
surprise, but I thought I'd point this out just in case people want to
be prepared for flames from people who feel strongly about the matter.

Note, also, that there's an important distinction to be made between
matching reverse and mere existence of some reverse.  An lot of sites
don't require matching any more, because of the way it can bloat PTR
RRsets if there are a lot of forward names at the same IP address.

Best,

A

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


From scott at doc.net.au  Wed Oct 30 17:00:37 2013
From: scott at doc.net.au (Scott Howard)
Date: Wed, 30 Oct 2013 10:00:37 -0700
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
Message-ID: <CACnPsNXJaKDRvmk-X3zUveWMqfN2yVwSmbyMh=eRWHNUd3n2zg@mail.gmail.com>

On Wed, Oct 30, 2013 at 9:12 AM, Nolan Rollo <nrollo at kw-corp.com> wrote:

> RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
>

I think you mean an "Expired RFC Draft from 2006 written by the people from
SORBS states :"

Which finally brings me to my questions:
> It seems like the unspoken de facto that mail admins appreciate given the
> IP 203.0.113.15 is "203-0-113-15.[type].[static/dynamic].yourdomain.tld".
> This seems perfectly acceptable, it's short, detailed and to the point. Is
> there really anything bad about this?
>

No. Nothing at all, and as you've already discovered it's what is used by
probably the majority of providers that include IP addresses in rDNS.


> What, if any would you name a network, gateway, broadcast address? Should
> the PTR be empty?
>

I've never seen anyone put in rDNS for networks or broadcast addresses.
 (Naming networks was common many years ago, but it never made the jump to
DNS from what I've seen).  rDNS for gateways can be helpful for traceroute,
and there are a few documents that provide examples of naming schemes for
such hosts, but I can't seem to find them right now...  Again, these are
only samples - there's not such thing as a "right" answer.

On Wed, Oct 30, 2013 at 9:24 AM, Nick Hilliard <nick at foobar.org> wrote:

> the only thing that's important is that forward and reverse DNS matches.
> After that, there is no correct or incorrect, so you need to do something
> that makes sense for your deployment.
>

Well, yes and no...  It's true that there's no "correct" answer, but there
are "incorrect" answers - such as putting the term "dynamic" in the rDNS
for an email server. It may not be incorrect enough to break an RFC, but
it's still the wrong thing to do!

  Scott

From wbailey at satelliteintelligencegroup.com  Wed Oct 30 17:05:30 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Wed, 30 Oct 2013 17:05:30 +0000
Subject: Happy Birthday, ARPANET!
In-Reply-To: <76BDDF71-FAF2-4453-8EE9-8E5A6AC5FE84@oitc.com>
References: <f4e1ea68-2480-4147-974e-e7b846f46fbf@email.android.com>,
 <76BDDF71-FAF2-4453-8EE9-8E5A6AC5FE84@oitc.com>
Message-ID: <iqg0aeesngpqig2h62c2rj35.1383152721055@email.android.com>

Either does Ashworth.. ;)


Sent from my Mobile Device.


-------- Original message --------
From: TR Shaw <tshaw at oitc.com>
Date: 10/30/2013 4:40 AM (GMT-08:00)
To: Jay Ashworth <jra at baylink.com>
Cc: nanog at nanog.org
Subject: Re: Happy Birthday, ARPANET!


Yikes! First it was the PDP in the British Museum and now a Sigma.  I don't feel old enough for the museum...

On Oct 29, 2013, at 10:51 PM, Jay Ashworth wrote:

> The Paley Center for Media reminds us that on this day in 1969 at 2230 PST, the first link was turned up between UCLAs Sigma 7 and SRIs 940.
>
> A photo of the laboratory logbook is included in the Wikipedia article:
>
> en.m.wikipedia.org/wiki/ARPANET
>
> Cheers,
> - jra
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.



From swmike at swm.pp.se  Wed Oct 30 17:13:35 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 30 Oct 2013 18:13:35 +0100 (CET)
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131030165536.GC525@dyn.com>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
Message-ID: <alpine.DEB.2.02.1310301812230.1838@uplift.swm.pp.se>

On Wed, 30 Oct 2013, Andrew Sullivan wrote:

> On Wed, Oct 30, 2013 at 04:24:42PM +0000, Nick Hilliard wrote:
>> the only thing that's important is that forward and reverse DNS matches.
>
> As I think I've said before on this list, when we tried to get
> consensus on that claim in the DNSOP WG at the IETF, we couldn't.
> Indeed, we couldn't even get consensus on the much more bland
> statement, "Some people rely on the reverse, and you might want to
> take that into consideration when running your services."

The classic TCP wrapper had this as one of the security features, if 
reverse said something and this couldn't be verified by doing a forward 
lookup, the reverse was treated as invalid and not used for name based 
policies.

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


From asullivan at dyn.com  Wed Oct 30 17:21:37 2013
From: asullivan at dyn.com (Andrew Sullivan)
Date: Wed, 30 Oct 2013 13:21:37 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <alpine.DEB.2.02.1310301812230.1838@uplift.swm.pp.se>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <alpine.DEB.2.02.1310301812230.1838@uplift.swm.pp.se>
Message-ID: <20131030172136.GE525@dyn.com>

On Wed, Oct 30, 2013 at 06:13:35PM +0100, Mikael Abrahamsson wrote:
> The classic TCP wrapper had this as one of the security features

I would agree with that if you'd put scare-quotes around the word
"security".  In general anyone depending on the reverse tree to
provide them any kind of security is engaged in wishful thinking,
particularly if the lookup isn't validated with DNSSEC.  (But yes,
that's waht the TCP wrappers package was supposed to be doing.)

A 

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


From johnmill at brandeis.edu  Wed Oct 30 17:19:20 2013
From: johnmill at brandeis.edu (John Miller)
Date: Wed, 30 Oct 2013 13:19:20 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
Message-ID: <52713F98.2060700@brandeis.edu>

As for A records and PTR records matching, we've taken the approach that 
we'll auto-create a matching PTR where there's only a single A record 
with that IP.  Otherwise, we'll add a PTR manually.

Plenty of applications can handle multiple A records; I'm not so sure 
that the same holds true for PTR records.

John


From tim at pelican.org  Wed Oct 30 17:24:28 2013
From: tim at pelican.org (Tim Franklin)
Date: Wed, 30 Oct 2013 17:24:28 +0000 (GMT)
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <CACnPsNXJaKDRvmk-X3zUveWMqfN2yVwSmbyMh=eRWHNUd3n2zg@mail.gmail.com>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <CACnPsNXJaKDRvmk-X3zUveWMqfN2yVwSmbyMh=eRWHNUd3n2zg@mail.gmail.com>
Message-ID: <106943351.50855.1383153868625.JavaMail.zimbra@pelican.org>

> I've never seen anyone put in rDNS for networks or broadcast addresses.

I've done this a fair bit, on both a personal and professional basis.  I find it quite helpful when I forget what the subnet masks are (or fail to apply them properly) and try and Do Something with an address that can't be a host.

Regards,
Tim.


From bicknell at ufp.org  Wed Oct 30 17:36:03 2013
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 30 Oct 2013 12:36:03 -0500
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131030165536.GC525@dyn.com>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
Message-ID: <BC65C328-DF9A-480C-9DE7-4687EC1AE343@ufp.org>


On Oct 30, 2013, at 11:55 AM, Andrew Sullivan <asullivan at dyn.com> wrote:

> As I think I've said before on this list, when we tried to get
> consensus on that claim in the DNSOP WG at the IETF, we couldn't.
> Indeed, we couldn't even get consensus on the much more bland
> statement, "Some people rely on the reverse, and you might want to
> take that into consideration when running your services."  

It's taking all of my willpower to avoid an IETF rant. :)

The "SHOULD" here is one way.  A PTR record should point to a valid
forward name that resolves to the same IP address.  To quote RFC 1034,
a PTR is "a pointer to another part of the domain name space".  If the
RHS of a PTR is not a valid domain name, that's just not true.

But rather than some pedantic rant about standards there's a practical
purpose here.  Tools that receive IP addresses will generate names
using reverse lookups, those names should then work.  For instance if
trace route gives a name, "ping <name>" should then work.

But the opposite is not true.  Many forward records may point to the
same IP address, and there is no need for reverses to match.

(in shorthand)

10.0.0.1 PTR webhosting.foo.com
webhosting.foo.com A 10.0.0.1
www.sitea.com A 10.0.0.1
www.siteb.com A 10.0.0.1
www.sitec.com A 10.0.0.1

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/





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

From asullivan at dyn.com  Wed Oct 30 18:12:17 2013
From: asullivan at dyn.com (Andrew Sullivan)
Date: Wed, 30 Oct 2013 14:12:17 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <BC65C328-DF9A-480C-9DE7-4687EC1AE343@ufp.org>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <BC65C328-DF9A-480C-9DE7-4687EC1AE343@ufp.org>
Message-ID: <20131030181216.GL525@dyn.com>

On Wed, Oct 30, 2013 at 12:36:03PM -0500, Leo Bicknell wrote:
> The "SHOULD" here is one way.

Of course, there is no SHOULD anywhere.  RFC 1034 is from the era
before RFC 2119, and there really isn't any guidance on the use of the
reverse tree anywhere.  It was the discovery of that very gap way back
in 2006 that caused me to try to resurrect Daniel Senie's original
draft and drive it through DNSOP.  I think I was less cynical in those days.

> purpose here.  Tools that receive IP addresses will generate names
> using reverse lookups, those names should then work.  For instance if
> trace route gives a name, "ping <name>" should then work.

Rather than "should" here, I'd prefer to say that it'd be nice if they
work (just so that people don't mistake that should for a 2119 word).
But the distinction you're making is roughly parallel with the
distinction draft-ietf-dnsop-reverse-mapping-considerations-06 made
between existing and matching reverse entries.  I agree this
distinction is worth keeping in mind.  

> But the opposite is not true.  Many forward records may point to the
> same IP address, and there is no need for reverses to match.

I can assure you that there are people who insist that they _do_ need
to match.  It's also possible to have those multiple matches, as long
as the list is not too long.  I think the view that every forward must
have a matching reverse is somewhat unrealistic; but the last time I
expressed such a strong opinion about the reverse tree I landed in a
long interaction with the proprietor of av8.net, so I'm disinclined to
defend my opinion very hard. 

I do think that the people who think that the reverse tree is entirely
optional are neglecting the interoperability consequences of that
decision.  That interoperation is the only real reason I can see to
maintain the reverse; but it's a pretty important reason!

Best,

A

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


From jacque.olantern at yandex.com  Wed Oct 30 18:46:50 2013
From: jacque.olantern at yandex.com (Jacque O'Lantern)
Date: Wed, 30 Oct 2013 22:46:50 +0400
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC
 traffic
Message-ID: <17761383158810@web2j.yandex.ru>

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 brandon.galbraith at gmail.com  Wed Oct 30 19:09:31 2013
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Wed, 30 Oct 2013 14:09:31 -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: <CADE4tYWpoDFU22dGXirMH_vR919WbX8KK53fX+O5qc3H_mVSNg@mail.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


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
>
>

From bill at herrin.us  Wed Oct 30 19:22:55 2013
From: bill at herrin.us (William Herrin)
Date: Wed, 30 Oct 2013 15:22:55 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
Message-ID: <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>

On Wed, Oct 30, 2013 at 12:12 PM, Nolan Rollo <nrollo at kw-corp.com> wrote:
> RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
> When using IP addresses in host names, their numbers SHOULD be
>    separated by '.'s (dots) rather than any meta character such as a '-'
>    (dash) and expressed in decimal.  Host names SHOULD NOT use the '_'
>    (underscore) character, host names for hosts with any form of SMTP
>    mail service MUST NOT use the '_' (underscore) character.  It is
>    preferable to use the IP address in reverse format in the same way
>    the the IN-ADDR.ARPA. domain is defined.

Hi Nolan,

Although no longer strictly required by the DNS RFCs, names which
follow these conventions are more likely to work with everyone else's
DNS servers.

1. Use only English alphabetic characters (a-z, A-Z), numeric
characters (0-9), the hyphen and the period.

2. The periods separate non-null sections of the name. You can't start
a name with a period or have two periods side by side.

3. Start each section of the name with a letter, not a number or hyphen.

4. Two hyphens can't be side by side, nor can a hyphen start or end a
section of the name.


Finally, the cardinal rule of reverse dns: whatever name the address
resolves to must resolve back to the address. If you don't do that,
you're basically asking for a whole bunch of servers on the Internet
to reject your connections.  So:

13.12.11.10.in-addr.arpa PTR bob.examplecompany.com.
bob.examplecompany.com. A 10.11.12.15

is wrong (13!=15) and will cause your users problems! Also, if you
omit the A record and simply have the PTR record, that too will cause
your users problems. If you omit the A record, you should also omit
the PTR record and let the address stand without DNS.


> Actual Examples:
> cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX
> d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX
> c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX
> 24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX

All of these examples are fine provided the forward DNS (A record) matches.



> Which finally brings me to my questions:
> It seems like the unspoken de facto that mail admins appreciate
> given the IP 203.0.113.15 is
> "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This
> seems perfectly acceptable, it's short, detailed and to the
> point. Is there really anything bad about this?

This is mainly for the benefit of the folks who run RBLs or other mail
reputation services. They use this information when classifying the
source and grouping sources into netblocks. If you take the time to
distinguish your intended mail servers from your dialup address pool
they'll try not to include your mail server when they ban mail
directly from your dialup address pool.

It's more a human factors question than supporting any automation.
You're hoping that by explaining your network to the antispammers
they'll cut you some slack when one of your doofus users gets pwned by
a spam bot. Many will. Some won't.


> What, if any would you name a network, gateway, broadcast address?
> Should the PTR be empty?

Pretty much whatever you want or nothing at all. If it doesn't
originate packets then nobody out there cares what it's named.

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 surfer at mauigateway.com  Wed Oct 30 19:30:34 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Wed, 30 Oct 2013 12:30:34 -0700
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
Message-ID: <20131030123034.F3EFF631@m0005310.ppops.net>

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


From asullivan at dyn.com  Wed Oct 30 20:31:30 2013
From: asullivan at dyn.com (Andrew Sullivan)
Date: Wed, 30 Oct 2013 16:31:30 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
Message-ID: <20131030203129.GC1241@dyn.com>

On Wed, Oct 30, 2013 at 03:22:55PM -0400, William Herrin wrote:
> 1. Use only English alphabetic characters (a-z, A-Z), numeric
> characters (0-9), the hyphen and the period.

This was never required by any DNS RFC.  Also, they're not English
characters, but ASCII ones. 

The full stop character is not actually part of the name.  It's a
separator.  For presentation format (i.e. the one you see and
manipulate) you need to use it, but be aware that it is not a part of
the name as such.  (This is why IDNA can't provide an "alternate"
separator.)

In my opinion, it's really better to think in terms of labels.  Labels
are separated by dots in presentation format, and by label length
markers in wire format.  In order to maximise interoperability, it is
wise to stick to the LDH rule (which is roughly what William says
above: ASCII letters either upper or lower case, digts, and the
hyphen).  But in principle, labels can be made of any octets you like.

Note that, if you use IDNA (internationalized labels) in the most
recent version (IDNA2008), the U-label form doesn't allow upper case.
This yields the bizarre example that Fass is a label (LDG) and fass is
a label (LDH) and fa? is a label (U-label) but Fa? is _not_ a valid
label.

> 3. Start each section of the name with a letter, not a number or hyphen.

This isn't a requirement and hasn't been since the so-called "3com
rule" change in RFC 1123.  See RFC 1123 section 2.1.  The topmost
label, however, _cannot_ begin with a number.  No label may begin with
a hyphen.

> 4. Two hyphens can't be side by side, nor can a hyphen start or end a
> section of the name.

Two hyphens can be side be side, but if you plan to be compatible with
IDNA they can't be side by side in the 3d and 4th positions.  That is,
foobar--baz is a perfectly good label.  fo--obarbaz is not.  This is
so that strategies along the lines of "xn--", which is used for INDA,
can be used again in the future for other issues.

> Finally, the cardinal rule of reverse dns: whatever name the address
> resolves to must resolve back to the address. 

This is a requirement for matching reverse.  As I've already suggested
in this thread more than once, it is by no means an uncontroversial
claim.

Best,

A

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


From gdendy at equinix.com  Wed Oct 30 21:12:06 2013
From: gdendy at equinix.com (Greg Dendy)
Date: Wed, 30 Oct 2013 14:12:06 -0700
Subject: NANOG 60 - Atlanta - Call For Presentations is open!
Message-ID: <18336F94-2430-4F60-B060-51C81719DF5A@equinix.com>

NANOG Community,
I hope everyone enjoyed NANOG 59 in Phoenix, NANOG?s largest attended meeting.  Fresh off a great meeting, and our NANOG annual elections, we are already starting to get ready for NANOG 60 in Atlanta.  If you have a topic you'd like to speak about, the program committee would love to consider it.  Please read http://www.nanog.org/meetings/nanog60/callforpresentations for more information.
We will continue with the Monday-Wednesday format, with Tracks on Monday afternoon and Tutorials to be scheduled on Tuesday morning.  The program will begin on Monday morning at 10:00AM followed by our popular Newcomers Lunch.  The exact schedule layout can be found at http://www.nanog.org/meetings/nanog60/preagenda, please take this into account as you plan travel.  If you wish to submit a presentation, please keep these important dates in mind:

 *   Presentation Abstracts and Draft Slides Due:             December 9, 2013
 *   Final Slides Due:                                             January 6, 2014
 *   Topic List Posted:                                       December 20, 2013
 *   Agenda Published:                                       January 13, 2014

Please submit your materials to http://pc.nanog.org.

Looking forward to seeing everyone in Atlanta!

Thanks,

Greg Dendy
Chair, NANOG Program Committee


From nrollo at kw-corp.com  Wed Oct 30 21:33:38 2013
From: nrollo at kw-corp.com (Nolan Rollo)
Date: Wed, 30 Oct 2013 21:33:38 +0000
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
Message-ID: <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>

So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS? 
I'm also thinking of the famous  www.1and1.com, where the number "1" starts off one of the sections. 

<snip>

3. Start each section of the name with a letter, not a number or hyphen.

<snip>

> Actual Examples:
> cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX 
> d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX 
> c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX 
> 24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX


From surfer at mauigateway.com  Wed Oct 30 21:37:27 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Wed, 30 Oct 2013 14:37:27 -0700
Subject: Happy Birthday, ARPANET!
Message-ID: <20131030143727.F3E00F81@resin03.mta.everyone.net>



--- dougb at dougbarton.us wrote:
From: Doug Barton <dougb at dougbarton.us>

lo
----------------------------------------


Just in case some folks thought this was a typo...

https://en.wikipedia.org/wiki/ARPANET#ARPANET_deployed


:-)
scott





From jabley at hopcount.ca  Wed Oct 30 21:38:29 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 30 Oct 2013 17:38:29 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
 <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>
Message-ID: <-4014717121708942441@unknownmsgid>

On Oct 30, 2013, at 17:34, Nolan Rollo <nrollo at kw-corp.com> wrote:

> So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS?

None.

> I'm also thinking of the famous  www.1and1.com, where the number "1" starts off one of the sections.

Which is fine.


Joe


From matthias at leisi.net  Wed Oct 30 21:45:58 2013
From: matthias at leisi.net (Matthias Leisi)
Date: Wed, 30 Oct 2013 22:45:58 +0100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
Message-ID: <CALgnk9rPZ1gEbNdww9T23yjmN4FR=fxSYOqi8MCo6CHMMBnpjQ@mail.gmail.com>

On Wed, Oct 30, 2013 at 8:22 PM, William Herrin <bill at herrin.us> wrote:


> > Which finally brings me to my questions:
> > It seems like the unspoken de facto that mail admins appreciate
> > given the IP 203.0.113.15 is
> > "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This
> > seems perfectly acceptable, it's short, detailed and to the
> > point. Is there really anything bad about this?
>
>
> reputation services. They use this information when classifying the
> source and grouping sources into netblocks. If you take the time to
> distinguish your intended mail servers from your dialup address pool
> they'll try not to include your mail server when they ban mail
> directly from your dialup address pool.
>

At dnswl.org, we identify new servers from looking at the rDNS in what we
see is being queried through our logs. Names with "dynamic", "dialup" etc
or that look like they have an embedded IPv4 address are discarded through
that channel.

-- Matthias

From scott at doc.net.au  Wed Oct 30 22:01:55 2013
From: scott at doc.net.au (Scott Howard)
Date: Wed, 30 Oct 2013 15:01:55 -0700
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
 <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>
Message-ID: <CACnPsNUxTa3vYQSxuTE4x9NXFm_o+2Bp7HqMBApXcm5_G5Zr2Q@mail.gmail.com>

On Wed, Oct 30, 2013 at 2:33 PM, Nolan Rollo <nrollo at kw-corp.com> wrote:

> So in the four examples below, 3 of them preface the IP with an alpha
> character. Charter however, starts the rDNS off with a number. I'm not
> arguing with anyone but what potential problems could that cause with DNS?
> I'm also thinking of the famous  www.1and1.com, where the number "1"
> starts off one of the sections.
>

Using domain name parts that start with a number will likely cause issues
for anyone running resolvers written in the 80's.

Anyone running resolvers that are less than ~25 years will likely not have
any issues.

  Scott

From marka at isc.org  Wed Oct 30 22:21:38 2013
From: marka at isc.org (Mark Andrews)
Date: Thu, 31 Oct 2013 09:21:38 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Wed, 30 Oct 2013 15:01:55 -0700."
 <CACnPsNUxTa3vYQSxuTE4x9NXFm_o+2Bp7HqMBApXcm5_G5Zr2Q@mail.gmail.com>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
 <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>
 <CACnPsNUxTa3vYQSxuTE4x9NXFm_o+2Bp7HqMBApXcm5_G5Zr2Q@mail.gmail.com>
Message-ID: <20131030222138.2D71394BE33@rock.dv.isc.org>


In message <CACnPsNUxTa3vYQSxuTE4x9NXFm_o+2Bp7HqMBApXcm5_G5Zr2Q at mail.gmail.com>
, Scott Howard writes:
> On Wed, Oct 30, 2013 at 2:33 PM, Nolan Rollo <nrollo at kw-corp.com> wrote:
> 
> > So in the four examples below, 3 of them preface the IP with an alpha
> > character. Charter however, starts the rDNS off with a number. I'm not
> > arguing with anyone but what potential problems could that cause with DNS?
> > I'm also thinking of the famous  www.1and1.com, where the number "1"
> > starts off one of the sections.
> >
> 
> Using domain name parts that start with a number will likely cause issues
> for anyone running resolvers written in the 80's.
> 
> Anyone running resolvers that are less than ~25 years will likely not have
> any issues.
> 
>   Scott

To be more precise it will cause no problems with the DNS.  Some
pre RFC 1123 gethostbyname implementations may reject the name
but the DNS doesn't care.

Mark
-- 
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 Oct 30 22:27:24 2013
From: bill at herrin.us (William Herrin)
Date: Wed, 30 Oct 2013 18:27:24 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
 <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>
Message-ID: <CAP-guGXbXnOTaD8b-vF_rrPcFW-ZQxr-b0+AFpKBU_CNSaN+xw@mail.gmail.com>

On Wed, Oct 30, 2013 at 5:33 PM, Nolan Rollo <nrollo at kw-corp.com> wrote:
> So in the four examples below, 3 of them preface the IP with an alpha
> character. Charter however, starts the rDNS off with a number. I'm
> not arguing with anyone but what potential problems could that
> cause with DNS?

Once upon a time there were buggy software implementations which
looked at the first character of the "name" to decide whether it was a
host name or an IP address. How many of them still exist? Not many
would be my guess.

> 3. Start each section of the name with a letter, not a number or hyphen.

The question I would ask myself is: will I recognize a gain from
putting a digit first in the name instead of a letter? If yes, it's
probably enough of an advantage to not worry about the old
implementations. If no (and it surely seems to be "no" in Nolan's
case) then keep to the conventions that work even with the ancient
buggy crap.

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 mohta at necom830.hpcl.titech.ac.jp  Wed Oct 30 22:36:20 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 31 Oct 2013 07:36:20 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
Message-ID: <527189E4.3090605@necom830.hpcl.titech.ac.jp>

Nolan Rollo wrote:

> RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
> When using IP addresses in host names, their numbers SHOULD be
>     separated by '.'s (dots) rather than any meta character such as a '-'
>     (dash) and expressed in decimal.  Host names SHOULD NOT use the '_'
>     (underscore) character, host names for hosts with any form of SMTP
>     mail service MUST NOT use the '_' (underscore) character.  It is
>     preferable to use the IP address in reverse format in the same way
>     the the IN-ADDR.ARPA. domain is defined.

That's not correct.

Not all domain names are host names, which is why '_' is allowed
for some domain names such as:

      _ldap._tcp.example.com [rfc2782]

However, though rfc1034 specifies;

   For example, when naming a mail domain, the user should satisfy
   both the rules of this memo and those in RFC-822.  When creating
   a new host name, the old rules for HOSTS.TXT should be followed.

both of "should" in the rfc should, today, be interpreted as "MUST".

						Masataka Ohta



From mohta at necom830.hpcl.titech.ac.jp  Wed Oct 30 22:42:44 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 31 Oct 2013 07:42:44 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131030172136.GE525@dyn.com>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <alpine.DEB.2.02.1310301812230.1838@uplift.swm.pp.se>
 <20131030172136.GE525@dyn.com>
Message-ID: <52718B64.1030004@necom830.hpcl.titech.ac.jp>

Andrew Sullivan wrote:

>> The classic TCP wrapper had this as one of the security features
> 
> I would agree with that if you'd put scare-quotes around the word
> "security".  In general anyone depending on the reverse tree to
> provide them any kind of security is engaged in wishful thinking,

No, it's you who have wishful thinking.

> particularly if the lookup isn't validated with DNSSEC.

As is discussed recently in IETF main and dns MLs, Lack of
secure time in most environment makes DNSSEC insecure.

Legal enforcement on zone administrators makes related zones
insecure.

For most users, security by plain DNS with reverse look up is
fine.

						Masataka Ohta


From Valdis.Kletnieks at vt.edu  Wed Oct 30 23:07:33 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 30 Oct 2013 19:07:33 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Wed, 30 Oct 2013 21:33:38 -0000."
 <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
 <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>
Message-ID: <173035.1383174453@turing-police.cc.vt.edu>

On Wed, 30 Oct 2013 21:33:38 -0000, Nolan Rollo said:

> So in the four examples below, 3 of them preface the IP with an alpha
> character. Charter however, starts the rDNS off with a number. I'm not arguing
> with anyone but what potential problems could that cause with DNS?

Only if the system involved got on the net before 3com did (as RFC1123
specifically relaxed this requirement back in 1989).

And at that point, Indiana Jones would say "It belongs in a *museum*".

-------------- 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/20131030/ce2fd1c5/attachment.bin>

From Valdis.Kletnieks at vt.edu  Wed Oct 30 23:13:12 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 30 Oct 2013 19:13:12 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Thu, 31 Oct 2013 07:42:44 +0900."
 <52718B64.1030004@necom830.hpcl.titech.ac.jp>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <alpine.DEB.2.02.1310301812230.1838@uplift.swm.pp.se>
 <20131030172136.GE525@dyn.com>
 <52718B64.1030004@necom830.hpcl.titech.ac.jp>
Message-ID: <173454.1383174792@turing-police.cc.vt.edu>

On Thu, 31 Oct 2013 07:42:44 +0900, Masataka Ohta said:

> Legal enforcement on zone administrators makes related zones
> insecure.

Citation, please?
-------------- 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/20131030/52d45ac5/attachment.bin>

From mohta at necom830.hpcl.titech.ac.jp  Thu Oct 31 00:08:12 2013
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 31 Oct 2013 09:08:12 +0900
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <173454.1383174792@turing-police.cc.vt.edu>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <alpine.DEB.2.02.1310301812230.1838@uplift.swm.pp.se>
 <20131030172136.GE525@dyn.com> <52718B64.1030004@necom830.hpcl.titech.ac.jp>
 <173454.1383174792@turing-police.cc.vt.edu>
Message-ID: <52719F6C.9080607@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

>> Legal enforcement on zone administrators makes related zones
>> insecure.
> 
> Citation, please?

Snowden.

						Masataka Ohta



From bzs at world.std.com  Thu Oct 31 02:01:58 2013
From: bzs at world.std.com (Barry Shein)
Date: Wed, 30 Oct 2013 22:01:58 -0400
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <173035.1383174453@turing-police.cc.vt.edu>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <CAP-guGV5j+uPhA=32psYO0M34Wb3Pdak9VNorWQsU-ovLUXygg@mail.gmail.com>
 <D27DF53349E1E94AA9599001CC1C718917A52754@kw2k8.KWAUTO.PRI>
 <173035.1383174453@turing-police.cc.vt.edu>
Message-ID: <21105.47638.771827.261412@world.std.com>


On October 30, 2013 at 19:07 Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) wrote:
 > On Wed, 30 Oct 2013 21:33:38 -0000, Nolan Rollo said:
 > 
 > > So in the four examples below, 3 of them preface the IP with an alpha
 > > character. Charter however, starts the rDNS off with a number. I'm not arguing
 > > with anyone but what potential problems could that cause with DNS?
 > 
 > Only if the system involved got on the net before 3com did (as RFC1123
 > specifically relaxed this requirement back in 1989).
 > 
 > And at that point, Indiana Jones would say "It belongs in a *museum*".
 > 

Back when I put Boston University on the net, pre-DNS, an accidentally
included host name with a leading digit submitted for the HOSTS.TXT
file brought down probably over half the net, many many unix systems.

There was a bug in the program which converted from the HOSTS.TXT
format to the unix /etc/hosts format. It went into a loop filling the
root partitions which in those days hung a unix system hard, and many
sites used unix systems as their main or only internet connection, no
fancy on-site routers back then.

Typically sites loaded the new HOSTS.TXT file after (or exactly at)
midnight automatically so not a lot of systems staff around to recover
which made it all the more painful.

So I heard a lot about this "no leading digits in host names rule" the
next day though when everyone calmed down it was agreed that the
conversion program shouldn't have behaved so poorly.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From akennykant at gmail.com  Thu Oct 31 05:34:39 2013
From: akennykant at gmail.com (Kenny Kant)
Date: Thu, 31 Oct 2013 00:34:39 -0500
Subject: Upstream / Handoff UPS?
Message-ID: <CAFnKnOd1QzkMASyusgCt4dj=SudsuATy+2ZvV=wFOQ4yG48ZzA@mail.gmail.com>

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 cite+nanog at incertum.net  Thu Oct 31 05:52:04 2013
From: cite+nanog at incertum.net (Stefan =?utf-8?Q?F=C3=B6rster?=)
Date: Thu, 31 Oct 2013 06:52:04 +0100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
Message-ID: <20131031055204.GL3263@mail.incertum.net>


* Nolan Rollo <nrollo at kw-corp.com>:
> It seems like the unspoken de facto that mail admins appreciate
> given the IP 203.0.113.15 is
> "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This seems
> perfectly acceptable, it's short, detailed and to the point. Is
> there really anything bad about this?

Mail admins wanting matching forward/reverse DNS and hostnames that
don't "look dynamically generated" is probably more of a human than an
RFC thing: "We used to get a lot of spam from dialup IPs, or IPs
without matching reverse DNS, so let's reject anything that comes from
an IP without FcRDNS and greylist anything with more than X dashes and
Y dots in it's hostname."


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/20131031/22c6d41e/attachment.bin>

From sethm at rollernet.us  Thu Oct 31 05:52:56 2013
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 30 Oct 2013 22:52:56 -0700
Subject: Upstream / Handoff UPS?
In-Reply-To: <CAFnKnOd1QzkMASyusgCt4dj=SudsuATy+2ZvV=wFOQ4yG48ZzA@mail.gmail.com>
References: <CAFnKnOd1QzkMASyusgCt4dj=SudsuATy+2ZvV=wFOQ4yG48ZzA@mail.gmail.com>
Message-ID: <5271F038.5080707@rollernet.us>

On 10/30/13, 10:34 PM, Kenny Kant wrote:
> 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.


It is normal. They don't have to so it's your problem if you want to.
Their site spec docs probably say as much, AT&T's certainly did.
Customer provides AC power or somesuch; that can be straight utility or
off a UPS you maintain, but they're not going to maintain batteries for
you if they don't have to. Some diverse ring OC-x that came with a DC
battery plant where they were mandated to have X hours runtime on it is
a different era than today's "toss an Ethernet switch on the end of some
fiber" circuits.

~Seth


From otis at ocosa.com  Thu Oct 31 06:00:38 2013
From: otis at ocosa.com (Otis L. Surratt, Jr.)
Date: Thu, 31 Oct 2013 01:00:38 -0500
Subject: Upstream / Handoff UPS?
In-Reply-To: <CAFnKnOd1QzkMASyusgCt4dj=SudsuATy+2ZvV=wFOQ4yG48ZzA@mail.gmail.com>
References: <CAFnKnOd1QzkMASyusgCt4dj=SudsuATy+2ZvV=wFOQ4yG48ZzA@mail.gmail.com>
Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B0188AB@ocsbs.ocosa.com>

-----Original Message-----
From: Kenny Kant [mailto:akennykant at gmail.com] 
Sent: Thursday, October 31, 2013 12:35 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.

I've witnessed a data center ask the upstream to install gear inside
their data center because of the lack of UPS for demarcs.

>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.

You are not wrong IMO. Many upstreams/providers/carriers now days simply
drop a DC plant to maintain 8 hours (If I recall correctly) of run time.
Which is usually sufficient unless you've got an extended outage lasting
longer than 8 hours. If you have a UPS and generator backing I would
recommend you have them make the demarc inside your locations every
time. Most carriers could consider this extending the demarc, thus an
extra charge.


From rps at maine.edu  Thu Oct 31 14:02:58 2013
From: rps at maine.edu (Ray Soucy)
Date: Thu, 31 Oct 2013 10:02:58 -0400
Subject: latest Snowden docs show NSA intercepts all Google and Yahoo
 DC-to-DC traffic
In-Reply-To: <20131030123034.F3EFF631@m0005310.ppops.net>
References: <20131030123034.F3EFF631@m0005310.ppops.net>
Message-ID: <CALFTrnOcO0JvgMBG9JFcibc_BqvgKxoH6MDF84JVdXc5GSO6UA@mail.gmail.com>

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


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 lists at mtin.net  Thu Oct 31 15:07:43 2013
From: lists at mtin.net (Justin Wilson)
Date: Thu, 31 Oct 2013 11:07:43 -0400
Subject: Upstream / Handoff UPS?
In-Reply-To: <CAFnKnOd1QzkMASyusgCt4dj=SudsuATy+2ZvV=wFOQ4yG48ZzA@mail.gmail.com>
Message-ID: <CE97EA2F.6A7CF%lists@mtin.net>

	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 johnl at iecc.com  Thu Oct 31 15:13:02 2013
From: johnl at iecc.com (John Levine)
Date: 31 Oct 2013 15:13:02 -0000
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131031055204.GL3263@mail.incertum.net>
Message-ID: <20131031151302.60719.qmail@joyce.lan>


>Mail admins wanting matching forward/reverse DNS and hostnames that
>don't "look dynamically generated" is probably more of a human than an
>RFC thing:

Right.  Spam filtering depends on heuristics.  Mail from hosts without
matching forward/reverse DNS is overwhelmingly bot spam, so checking
for it is a very effective heuristic.

Mail from hosts with names that look dynamic is also quite spammy, but
figuring out what looks dynamic is quite hard.  I know someone who's been
tuning his regexes for years.  For most people, third party lists like
the Spamhaus PBL are more reliable.

R's,
John




From alh-ietf at tndh.net  Thu Oct 31 22:49:56 2013
From: alh-ietf at tndh.net (Tony Hain)
Date: Thu, 31 Oct 2013 15:49:56 -0700
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131031151302.60719.qmail@joyce.lan>
References: <20131031055204.GL3263@mail.incertum.net>
 <20131031151302.60719.qmail@joyce.lan>
Message-ID: <007d01ced68b$850bbbe0$8f2333a0$@tndh.net>

John Levine wrote:
> Right.  Spam filtering depends on heuristics.  Mail from hosts without
> matching forward/reverse DNS is overwhelmingly bot spam, so checking for
> it is a very effective heuristic.

Leading digit is clearly in widespread use beyond 3com & 1and1. One of the most effective heuristics in my acl list is:
\N^.*@\d{3,}\.(cn|com|net|org|us|asia)

In the last few hours it has picked off multiple messages from each of these:
Carol28 at 8447.com
Jeff17 at 3550.com
Ronald79 at 0785.com
Kevin57 at 2691.com
Deborah76 at 3585.com
Kimberly34 at 5864.com
Sarah94 at 0858.com
zavfdv at 131.com
qgmklyysyn at 163.com
pjpeng at 163.com
fahuyrw at 163.com
Daniel57 at 4704.com
Helen95 at 2620.com




From johnl at iecc.com  Thu Oct 31 23:13:38 2013
From: johnl at iecc.com (John Levine)
Date: 31 Oct 2013 23:13:38 -0000
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <007d01ced68b$850bbbe0$8f2333a0$@tndh.net>
Message-ID: <20131031231338.63641.qmail@joyce.lan>

>In the last few hours it has picked off multiple messages from each of these:
>Carol28 at 8447.com
>Jeff17 at 3550.com
>Ronald79 at 0785.com
>Kevin57 at 2691.com
>Deborah76 at 3585.com
>Kimberly34 at 5864.com
>Sarah94 at 0858.com
>zavfdv at 131.com
>qgmklyysyn at 163.com
>pjpeng at 163.com
>fahuyrw at 163.com
>Daniel57 at 4704.com
>Helen95 at 2620.com

163.com is Netease, one of the larger ISPs in China.  If you don't
have any users who speak Chinese, you can probably block it, but if
you do, you'll get complaints.



From dhc2 at dcrocker.net  Thu Oct 31 23:15:50 2013
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Thu, 31 Oct 2013 16:15:50 -0700
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <20131030165536.GC525@dyn.com>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
Message-ID: <5272E4A6.9080601@dcrocker.net>

On 10/30/2013 9:55 AM, Andrew Sullivan wrote:
> As I think I've said before on this list, when we tried to get
> consensus on that claim in the DNSOP WG at the IETF, we couldn't.
> Indeed, we couldn't even get consensus on the much more bland
> statement, "Some people rely on the reverse, and you might want to
> take that into consideration when running your services."
>
> Now, IETF non-consensus on the way the Internet works is hardly a
> surprise, but I thought I'd point this out just in case people want to
> be prepared for flames from people who feel strongly about the matter.


I'm beginning to think that documenting failures to get consensus could 
be almost as important as documenting successes, in order to provide a 
basis for countering folks who claim something is required, when there's 
explicit public experience that it isn't.

Looks to me that Andrew's note is an example of that potential benefit. 
  Rather than having to have someone remember this stuff, anyone could 
point to the 'failure' document.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From scott at doc.net.au  Thu Oct 31 23:17:22 2013
From: scott at doc.net.au (Scott Howard)
Date: Thu, 31 Oct 2013 16:17:22 -0700
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: <007d01ced68b$850bbbe0$8f2333a0$@tndh.net>
References: <20131031055204.GL3263@mail.incertum.net>
 <20131031151302.60719.qmail@joyce.lan>
 <007d01ced68b$850bbbe0$8f2333a0$@tndh.net>
Message-ID: <CACnPsNUwxeSQS2iO+gXJcF3Pvu6PrWjQp_0ThwNJGK9OZoiKtg@mail.gmail.com>

163.com (as well as 126.com which you don't have listed) is a bit of a
special case.

It's a Chinese site that offers free email address as well as a very
popular portal site - think of it as the Chinese equivalent to Yahoo or
Hotmail.

Whilst it's certainly true that a lot of spam originates from there, simply
classifying it as a spam site isn't (necessarily) correct, in the same way
that classifying yahoo or hotmail as spam isn't correct. The company behind
163.com is actually listed on the NASDAQ...

You did mention heuristics, so I'm guessing you're not actually just
outright blacklisting it, just wanted to point out that all number-only
domains aren't necessarily spam-only.

  Scott



On Thu, Oct 31, 2013 at 3:49 PM, Tony Hain <alh-ietf at tndh.net> wrote:

> John Levine wrote:
> > Right.  Spam filtering depends on heuristics.  Mail from hosts without
> > matching forward/reverse DNS is overwhelmingly bot spam, so checking for
> > it is a very effective heuristic.
>
> Leading digit is clearly in widespread use beyond 3com & 1and1. One of the
> most effective heuristics in my acl list is:
> \N^.*@\d{3,}\.(cn|com|net|org|us|asia)
>
> In the last few hours it has picked off multiple messages from each of
> these:
> Carol28 at 8447.com
> Jeff17 at 3550.com
> Ronald79 at 0785.com
> Kevin57 at 2691.com
> Deborah76 at 3585.com
> Kimberly34 at 5864.com
> Sarah94 at 0858.com
> zavfdv at 131.com
> qgmklyysyn at 163.com
> pjpeng at 163.com
> fahuyrw at 163.com
> Daniel57 at 4704.com
> Helen95 at 2620.com
>
>
>
>

From marka at isc.org  Thu Oct 31 23:51:10 2013
From: marka at isc.org (Mark Andrews)
Date: Fri, 01 Nov 2013 10:51:10 +1100
Subject: Reverse DNS RFCs and Recommendations
In-Reply-To: Your message of "Thu, 31 Oct 2013 16:15:50 -0700."
 <5272E4A6.9080601@dcrocker.net>
References: <D27DF53349E1E94AA9599001CC1C718917A523BC@kw2k8.KWAUTO.PRI>
 <527132CA.5050709@foobar.org> <20131030165536.GC525@dyn.com>
 <5272E4A6.9080601@dcrocker.net>
Message-ID: <20131031235110.D505696611F@rock.dv.isc.org>


In message <5272E4A6.9080601 at dcrocker.net>, Dave Crocker writes:
> On 10/30/2013 9:55 AM, Andrew Sullivan wrote:
> > As I think I've said before on this list, when we tried to get
> > consensus on that claim in the DNSOP WG at the IETF, we couldn't.
> > Indeed, we couldn't even get consensus on the much more bland
> > statement, "Some people rely on the reverse, and you might want to
> > take that into consideration when running your services."
> >
> > Now, IETF non-consensus on the way the Internet works is hardly a
> > surprise, but I thought I'd point this out just in case people want to
> > be prepared for flames from people who feel strongly about the matter.
> 
> 
> I'm beginning to think that documenting failures to get consensus could 
> be almost as important as documenting successes, in order to provide a 
> basis for countering folks who claim something is required, when there's 
> explicit public experience that it isn't.
> 
> Looks to me that Andrew's note is an example of that potential benefit. 
>   Rather than having to have someone remember this stuff, anyone could 
> point to the 'failure' document.

There is consensus.  There SHOULD be PTR records.  This is even
documented in various RFC.

Now the methods IPS's use to do this for home customer addresses
with IPv4 don't scale to IPv6.  They also don't let the home customer
specify the name in the PTR record.

Additionally ISP's use PTR records as a revenue source by only
offering to set them to commercial customers.  Part of this is
that it is often a manual proceedure.

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 (yes
I am aware of the typos which I will fix once the submission window
re-opens).  Similar techiques can be applied to individual IPv4
delegations.  You add PTR records rather than NS and DS records.

In named the SIG(0) signed UPDATE requests are granted using

	update-policy { grant * self *; };

when setting up the reverse zone.  The code to do it is over a
decade old at this point.

It just requires willingness to do it.  For ISP's to come out of
the 90's and use the technology that was designed to allow this to
happen.

Mark

> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org