From joly at punkcast.com  Thu Sep  1 05:48:03 2011
From: joly at punkcast.com (Joly MacFie)
Date: Thu, 1 Sep 2011 06:48:03 -0400
Subject: Webcast Friday: ISOC HK - After World IPv6 Day, what's next?
Message-ID: <CAM9VJk0jj24Y5MJu3FbicMY7NL3H1DDorucJs_7jhbKS5uzbWg@mail.gmail.com>

Many viewers worldwide were able to watch live the Internet Society Hong
Kong Chapter's excellent "*Kickstart IPv6*!" event on World IPv6 Day, Jun 8
2011, via the Internet Society Chapters Webcasting Channel. Archived at
http://bit.ly/kickstartipv6

We are happy to announce the webcast of the followup event "*After World
IPv6 Day, what's next?*" tomorrow *Friday Sep 2 2011*. Time is *2pm-5pm HKT
= 0600-0900 UTC = 0200-0500 EDT*.

*Moderator*: Charles Mok, ISOC-HK

*Guest speakers*:
Erik Kline, IPv6 Software Engineer, Google, JP
Jason Fesler, Senior Principal Architect, Yahoo!, US
Martin Levy, Director IPv6 Strategy, Hurricane Electric, US
Kevin Yin, Head of CTO Office, Great China, Cisco Systems & Commissioner of
IPv6 Forum, China

*View online*: http://www.livestream.com/internetsocietychapters/

*More info*: http://www.ipv6world.asia/event.php

What, of course, we will all be wondering is if the date of the next "test
flight" will be announced. At the recent "IPv6 Now!" event in New York with
ISOC's Phil Roberts it was suggested that a date had already been selected.
See http://www.youtube.com/watch?v=YCXTqJMMrM8



-- 
---------------------------------------------------------------
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 sergevautour at yahoo.ca  Thu Sep  1 13:36:37 2011
From: sergevautour at yahoo.ca (Serge Vautour)
Date: Thu, 1 Sep 2011 11:36:37 -0700 (PDT)
Subject: NAT444 or ?
Message-ID: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>

Hello,

Things I understand: IPv6 is the long term solution to IPv4 exhaustion. For IPv6 to work correctly, most of the IPv4 content has to be on IPv6. That's not there yet. IPv6 deployment to end users is not trivial (end user support, CPE support, etc...). Translation techniques are generally evil. IPv6->IPv4 still requires 1 IPv4 IP per end user or else you're doing NAT. IPv4->IPv6 (1-1) doesn't solve our main problem of giving users access to the IPv4 Internet.


I expect like most companies we're faced with having to extend the life of IPv4 since our users will continue to want access to the IPv4 content. Doing that by giving them an IPv6 address is not very feasible yet for many reasons. NAT444 seems like the only solution available while we slowly transition over to IPv6 over the next 20 years. Based on the this RFC, NAT444 breaks a lot of applications!

http://tools.ietf.org/html/draft-donley-nat444-impacts-01

Has anyone deployed NAT444? Can folks share their experiences? Does it really break this many apps? What other options do we have? 


Thanks,
Serge


From cb.list6 at gmail.com  Thu Sep  1 13:52:44 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Thu, 1 Sep 2011 11:52:44 -0700
Subject: NAT444 or ?
In-Reply-To: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
Message-ID: <CAD6AjGQHGEVcFwe43g6PcWoBKfEirswG8hn_QTT8apHi8yTz1A@mail.gmail.com>

On Thu, Sep 1, 2011 at 11:36 AM, Serge Vautour <sergevautour at yahoo.ca> wrote:
> Hello,
>
> Things I understand: IPv6 is the long term solution to IPv4 exhaustion. For IPv6 to work correctly, most of the IPv4 content has to be on IPv6. That's not there yet. IPv6 deployment to end users is not trivial (end user support, CPE support, etc...). Translation techniques are generally evil. IPv6->IPv4 still requires 1 IPv4 IP per end user or else you're doing NAT. IPv4->IPv6 (1-1) doesn't solve our main problem of giving users access to the IPv4 Internet.
>

Correct, all content is not there yet... but World IPv6 Day showed
that Google, Facebook, Yahoo, Microsoft and 400+ others are just about
ready to go.

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

IPv6->IPv4 does not require 1 to 1, .... any protocol translation is a
form of NATish things, and stateful NAT64 has many desirable
properties IF you already do NAT44.  Specifically, it is nice that
IPv6 flows bypass the NAT .... and as more content becomes  IPv6, NAT
becomes less and less used.  In this way, unlike NAT44 or NAT444,
NAT64 has an exit strategy that ends with proper E2E networking with
IPv6... the technology and economic incentives push the right way
(more IPv6...)

Have a look at http://tools.ietf.org/html/rfc6146

There are multiple opensource and big vendor (C, J, B, LB guys...)
implementation of NAT64 / DNS64 ... I have trialed it and plan to
deploy it, YMMV... It works great for web and email, not so great for
gaming and Skype.

>
> I expect like most companies we're faced with having to extend the life of IPv4 since our users will continue to want access to the IPv4 content. Doing that by giving them an IPv6 address is not very feasible yet for many reasons. NAT444 seems like the only solution available while we slowly transition over to IPv6 over the next 20 years. Based on the this RFC, NAT444 breaks a lot of applications!
>
> http://tools.ietf.org/html/draft-donley-nat444-impacts-01
>

This is just putting IPv4 on life support without moving needle
towards a long term solution. NAT64 = good investment to get IPv6 off
the blocks.  NAT444 = life support / money pit with forklift exit
required.

> Has anyone deployed NAT444? Can folks share their experiences? Does it really break this many apps? What other options do we have?
>

Yes, expect it to be deployed in places where the access gear can only
do IPv4 and there is no money or technology available to bring in
IPv6.

Cameron

>
> Thanks,
> Serge
>



From randy at psg.com  Thu Sep  1 14:27:14 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 02 Sep 2011 04:27:14 +0900
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
Message-ID: <m2y5y83vxp.wl%randy@psg.com>

i do not support getting paid for community service.  a primrose path.

randy



From robt at cymru.com  Thu Sep  1 15:23:11 2011
From: robt at cymru.com (Rob Thomas)
Date: Thu, 01 Sep 2011 16:23:11 -0400
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <m2y5y83vxp.wl%randy@psg.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
Message-ID: <4E5FE9AF.6020500@cymru.com>

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

Hi, team.

> i do not support getting paid for community service.  a primrose path.

Bravo and agreed!

Thanks,
Rob.
- --
Rob Thomas
Team Cymru
https://www.team-cymru.org/
"Say little and do much." M Avot 1:15

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBTl/prlkX3QAo5sgJAQLRYQP8DzUc9mjKMDFVe3QE7udfTa+pWKV4TbcQ
lM9EgatUnkyEPxahCAyAH9VKsM3YLJ0Brhnk8aJqzH4doXElKRijMw3A9DTxG+Qx
+KY+niCXQtF95XuK+kVcQsUBZHp/2evVr54B4CdMUZ9IywpB8w+FcMo6QS8sCttk
4kj7pqmigQU=
=C8gq
-----END PGP SIGNATURE-----



From BEJones at semprautilities.com  Thu Sep  1 15:30:41 2011
From: BEJones at semprautilities.com (Jones, Barry)
Date: Thu, 1 Sep 2011 13:30:41 -0700
Subject: Access and Session Control System?
In-Reply-To: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
Message-ID: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>

 
Hello all.
I am looking at a variety of systems/methods to provide (vendor, employee) access into my dmz's. I want to reduce the FW rule sets and connections to as minimal as possible. And I want the accessing party to only get to the destination I define (like a fw rule).

When I refer to access, I'm referring to the ability of a vendor or employee to perform maintenance tasks on a server(s). The server(s) will be running apps for doing different tasks - such as Shavlik, etc..,  (patching, reports, logging, etc..), so I am envisioning allowing an outside vendor/employee (from the internet or corp. net) to RDP or SSH to a given Windows or Unix based machines, then perform their application work from that jumping off point - kind of like a terminal server; but I'd like to control and audit the sessions as well.

Overall, I can allow a host/port through the FW to a single host, but I wanted to be able to do the session management and endpoint controls. FW's are ok, but you know as well as I that I now deal with lots of rules sets. And I need to also authenticate the user.

We are a couple smaller facilities (150 hosts each) and I need to be able to control and audit the sessions when requested. I have considered doing a meetingplace server, then providing escorted access for them, or doing just the FW and a "jump" host - but need the endpoint and session solution, or just using VPN - but don't want to install a host on the vendor machines. I also have looked at a product called EDMZ - wondered if anyone had experience with it?

And did I say I wanted to keep it as simple as possible? :-) It's been a few years since I've done hands-on networking work, so excuse the long-winded letter. Feel free to email me directly too.

Sincerely
Barry Jones
CISSP, GSNA


From packetjockey at gmail.com  Thu Sep  1 16:45:55 2011
From: packetjockey at gmail.com (Rafael Rodriguez)
Date: Thu, 1 Sep 2011 17:45:55 -0400
Subject: Access and Session Control System?
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <21875121-62EA-4056-A099-EBFCED0B096B@gmail.com>

I recommend you look into the Juniper SSL VPN products (SA Series). Very power boxes, intuitive admin interface (web driven) and are perfect for the "Vendor Access" type of applications.

Sent from my iPhone

On Sep 1, 2011, at 16:30, "Jones, Barry" <BEJones at semprautilities.com> wrote:

> 
> Hello all.
> I am looking at a variety of systems/methods to provide (vendor, employee) access into my dmz's. I want to reduce the FW rule sets and connections to as minimal as possible. And I want the accessing party to only get to the destination I define (like a fw rule).
> 
> When I refer to access, I'm referring to the ability of a vendor or employee to perform maintenance tasks on a server(s). The server(s) will be running apps for doing different tasks - such as Shavlik, etc..,  (patching, reports, logging, etc..), so I am envisioning allowing an outside vendor/employee (from the internet or corp. net) to RDP or SSH to a given Windows or Unix based machines, then perform their application work from that jumping off point - kind of like a terminal server; but I'd like to control and audit the sessions as well.
> 
> Overall, I can allow a host/port through the FW to a single host, but I wanted to be able to do the session management and endpoint controls. FW's are ok, but you know as well as I that I now deal with lots of rules sets. And I need to also authenticate the user.
> 
> We are a couple smaller facilities (150 hosts each) and I need to be able to control and audit the sessions when requested. I have considered doing a meetingplace server, then providing escorted access for them, or doing just the FW and a "jump" host - but need the endpoint and session solution, or just using VPN - but don't want to install a host on the vendor machines. I also have looked at a product called EDMZ - wondered if anyone had experience with it?
> 
> And did I say I wanted to keep it as simple as possible? :-) It's been a few years since I've done hands-on networking work, so excuse the long-winded letter. Feel free to email me directly too.
> 
> Sincerely
> Barry Jones
> CISSP, GSNA



From frnkblk at iname.com  Thu Sep  1 17:03:13 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 1 Sep 2011 17:03:13 -0500
Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down
 for 10 days
In-Reply-To: <001001cc5e91$598b9310$0ca2b930$@iname.com>
References: <000001cc5d68$93fc01d0$bbf40570$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643976AA@EALPO1.ukbroadband.com>
 <3A807C2C-9DD2-4A40-B11E-8583F2C562B6@delong.com>
 <ECB36694-DA05-4B05-B9A0-27BCC312BAB0@internode.com.au>
 <E1DD60718964C54A96C04CA9CB0BA811013D0286F42A@server3.MUTUALTEL.MTCNET.NET>
 <001001cc5e91$598b9310$0ca2b930$@iname.com>
Message-ID: <00a101cc68f2$f1f98e20$d5ecaa60$@iname.com>

Charter.com has also remove the quad-A's for www.charter.com.  My monitoring
system alerted me this afternoon that it couldn't get to the v6 version of
their website.  Because of DNS caching, I don't know how many hours or days
ago it was removed.

Frank

-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Friday, August 19, 2011 11:59 AM
To: nanog at nanog.org
Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days

I just noticed that the quad-A records for both those two hosts are now
gone.  DNS being what it is, I'm not sure when that happened, but our
monitoring system couldn't get the AAAA for www.qwest.com about half an hour
ago.

Hopefully CenturyLink is actively working towards IPv6-enabling their sites
again.

Frank

-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Thursday, August 18, 2011 11:14 PM
To: nanog at nanog.org
Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days

FYI, the issue is not resolved and I've not heard from either of the
companies suggesting that they're working on it.

Note their commitment to IPv6 in these releases:
http://www.prnewswire.com/news-releases/centurylink-joins-internet-community
-in-world-ipv6-day-123089908.html
http://news.centurylink.com/index.php?s=43&item=2129

Frank

-----Original Message-----
From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] 
Sent: Thursday, August 18, 2011 7:08 PM
To: Owen DeLong
Cc: nanog at nanog.org
Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days


On 19/08/2011, at 4:18 AM, Owen DeLong wrote:

It'd really suck for end users to start actively avoiding IPv6 connectivity
because it keeps breaking and for organisations that have active AAAA
records to break peoples connectivity to their resources.



+1 -- I'm all for publishing AAAA records as everyone knows, but, if you
publish AAAA records for a consumer facing service, please support and
monitor that service with a similar level to what you do for your IPv4
versions of the service.

The coming years are going to be difficult enough for end-users without
adding unnecessary anti-IPv6 sentiments to the mix.

Owen

+1 to Owen's comment.

I'd also add some more comments:

A lot of eyeballs that have v6 right now are the people with a lot of clue.
Do you want these people, who'll often be buying or recommending your
services to rate your ability to deliver as a fail?  Our experience with
IPv6 consumer broadband has been that the early adopters are the people who,
well, goto IETF meetings, follow standards and ask the bloody hard
questions.

Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated as
HE?? :-) ) most end users prefer IPv6 over IPv4.  Deeply this means there is
a tendency for v6 traffic to grow and be more important to connectivity than
you may imagine.  The tipping point for IPv6 traffic being dominant I
suspect is going to be a lower threshold of take up than people might
expect.   Consider this when thinking about the level of thought you give to
IPv6 infrastructure and PPS rates.

MMC






From dave at temk.in  Thu Sep  1 17:12:54 2011
From: dave at temk.in (David Temkin)
Date: Thu, 1 Sep 2011 18:12:54 -0400
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <m2y5y83vxp.wl%randy@psg.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
Message-ID: <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>

Randy,

How is that "getting paid"?  Receiving services in kind?

Don't know if you've ever done Habitat for Humanity, but you get a free
lunch, paid for by those who have given cash to support the cause and not
labor.

To bring it closer to home - we give our presenters a free admission -
should we also stop that?

-Dave
On Sep 1, 2011 3:27 PM, "Randy Bush" <randy at psg.com> wrote:
> i do not support getting paid for community service. a primrose path.
>
> randy
>


From jared at puck.nether.net  Thu Sep  1 17:41:00 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 1 Sep 2011 18:41:00 -0400
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
Message-ID: <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>

I have had my registration fee refunded when I was a speaker when my employer was happy to pay. This frustrated me when the meeting had low registration and lost money. 

I'm fine with people getting it waived, but the idea of everyone showing up for a "roll-call" so they can get in free is certainly not the case. This is why I suggested the BoD would have the authority to waive the fee if recommended by someone else. The reason is less important to me honestly. 

Then again, the bar for giving a bad talk is really low. People can just put in that effort instead.

Jared Mauch

On Sep 1, 2011, at 6:12 PM, David Temkin <dave at temk.in> wrote:

> Randy,
> 
> How is that "getting paid"?  Receiving services in kind?
> 
> Don't know if you've ever done Habitat for Humanity, but you get a free
> lunch, paid for by those who have given cash to support the cause and not
> labor.
> 
> To bring it closer to home - we give our presenters a free admission -
> should we also stop that?
> 
> -Dave
> On Sep 1, 2011 3:27 PM, "Randy Bush" <randy at psg.com> wrote:
>> i do not support getting paid for community service. a primrose path.
>> 
>> randy
>> 



From owen at delong.com  Thu Sep  1 17:43:00 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 1 Sep 2011 15:43:00 -0700
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
Message-ID: <43B427CC-E34B-48A7-A2B3-58578C35C2AD@delong.com>

I support conference admission for volunteers who give their time to organize
the conference, etc. (such as program committee members, steering committee
members, speakers, etc.).

I would not support other forms of remuneration or expanding the free conference
admission beyond those directly involved in organizing and/or running the
conference.

Owen

On Sep 1, 2011, at 3:12 PM, David Temkin wrote:

> Randy,
> 
> How is that "getting paid"?  Receiving services in kind?
> 
> Don't know if you've ever done Habitat for Humanity, but you get a free
> lunch, paid for by those who have given cash to support the cause and not
> labor.
> 
> To bring it closer to home - we give our presenters a free admission -
> should we also stop that?
> 
> -Dave
> On Sep 1, 2011 3:27 PM, "Randy Bush" <randy at psg.com> wrote:
>> i do not support getting paid for community service. a primrose path.
>> 
>> randy
>> 




From mike.lyon at gmail.com  Thu Sep  1 17:55:46 2011
From: mike.lyon at gmail.com (Mike Lyon)
Date: Thu, 1 Sep 2011 15:55:46 -0700
Subject: Covad / Telepacific BGP clue?
Message-ID: <CAFFgAjBNN0RrsDEH88ThEMDE5sL1y_jV7yOz-VwCH+chyJ68fQ@mail.gmail.com>

Hello Folks,

If there is anyone from Covad Wireless / Telepacifc Wireless with BGP clue,
would you contact me off list?

Thank You,
Mike


From randy at psg.com  Thu Sep  1 18:46:39 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 02 Sep 2011 08:46:39 +0900
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
Message-ID: <m2r53z4yhs.wl%randy@psg.com>

> How is that "getting paid"?  

you're kidding, right?

> Don't know if you've ever done Habitat for Humanity

no.  i teach in the poor countries.  i pay my way.

> To bring it closer to home - we give our presenters a free admission -
> should we also stop that?

i am ambivalent.  i think there is some sort of untested assumption that
this attracts an otherwise unattracted resources we need.

otoh, committees seem to attract flies.  i will not comment on their
quality.

randy



From dave at temk.in  Thu Sep  1 19:01:38 2011
From: dave at temk.in (David Temkin)
Date: Thu, 1 Sep 2011 20:01:38 -0400
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
Message-ID: <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>

On the flip side of this, many of our employers donate "our" time that they
are paying us for in order for us to serve NANOG with nary a benefit.  If
you take just committee calls for the PC alone, this is 48 hours a year - a
workweek.  Perhaps they should feel that this donation nets them something.

-Dave
On Sep 1, 2011 6:41 PM, "Jared Mauch" <jared at puck.nether.net> wrote:
> I have had my registration fee refunded when I was a speaker when my
employer was happy to pay. This frustrated me when the meeting had low
registration and lost money.
>
> I'm fine with people getting it waived, but the idea of everyone showing
up for a "roll-call" so they can get in free is certainly not the case. This
is why I suggested the BoD would have the authority to waive the fee if
recommended by someone else. The reason is less important to me honestly.
>
> Then again, the bar for giving a bad talk is really low. People can just
put in that effort instead.
>
> Jared Mauch
>
> On Sep 1, 2011, at 6:12 PM, David Temkin <dave at temk.in> wrote:
>
>> Randy,
>>
>> How is that "getting paid"? Receiving services in kind?
>>
>> Don't know if you've ever done Habitat for Humanity, but you get a free
>> lunch, paid for by those who have given cash to support the cause and not
>> labor.
>>
>> To bring it closer to home - we give our presenters a free admission -
>> should we also stop that?
>>
>> -Dave
>> On Sep 1, 2011 3:27 PM, "Randy Bush" <randy at psg.com> wrote:
>>> i do not support getting paid for community service. a primrose path.
>>>
>>> randy
>>>


From paul4004 at gmail.com  Thu Sep  1 19:03:40 2011
From: paul4004 at gmail.com (PC)
Date: Thu, 1 Sep 2011 18:03:40 -0600
Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down
 for 10 days
In-Reply-To: <001001cc5e91$598b9310$0ca2b930$@iname.com>
References: <000001cc5d68$93fc01d0$bbf40570$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643976AA@EALPO1.ukbroadband.com>
 <3A807C2C-9DD2-4A40-B11E-8583F2C562B6@delong.com>
 <ECB36694-DA05-4B05-B9A0-27BCC312BAB0@internode.com.au>
 <E1DD60718964C54A96C04CA9CB0BA811013D0286F42A@server3.MUTUALTEL.MTCNET.NET>
 <001001cc5e91$598b9310$0ca2b930$@iname.com>
Message-ID: <CAJAdsDmW4iRPxWWjyCokW-PzqoycwjxdqQcYC_pY_dWxf2Y1bg@mail.gmail.com>

The Qwest one died roughly around the time of their merger/migration to
Centurylink web sites.  I did bring up the issue with them as a customer,
and it seems the response was to disable publicly-facing IPV6 services (and
associated AAAA records) for the time being, as you observed.

Not that I agree with the "fix", but it is what it is.



On Fri, Aug 19, 2011 at 10:59 AM, Frank Bulk <frnkblk at iname.com> wrote:

> I just noticed that the quad-A records for both those two hosts are now
> gone.  DNS being what it is, I'm not sure when that happened, but our
> monitoring system couldn't get the AAAA for www.qwest.com about half an
> hour
> ago.
>
> Hopefully CenturyLink is actively working towards IPv6-enabling their sites
> again.
>
> Frank
>
> -----Original Message-----
> From: Frank Bulk [mailto:frnkblk at iname.com]
> Sent: Thursday, August 18, 2011 11:14 PM
> To: nanog at nanog.org
> Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been
> down
> for 10 days
>
> FYI, the issue is not resolved and I've not heard from either of the
> companies suggesting that they're working on it.
>
> Note their commitment to IPv6 in these releases:
>
> http://www.prnewswire.com/news-releases/centurylink-joins-internet-community
> -in-world-ipv6-day-123089908.html
> http://news.centurylink.com/index.php?s=43&item=2129
>
> Frank
>
> -----Original Message-----
> From: Matthew Moyle-Croft [mailto:mmc at internode.com.au]
> Sent: Thursday, August 18, 2011 7:08 PM
> To: Owen DeLong
> Cc: nanog at nanog.org
> Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been
> down
> for 10 days
>
>
> On 19/08/2011, at 4:18 AM, Owen DeLong wrote:
>
> It'd really suck for end users to start actively avoiding IPv6 connectivity
> because it keeps breaking and for organisations that have active AAAA
> records to break peoples connectivity to their resources.
>
>
>
> +1 -- I'm all for publishing AAAA records as everyone knows, but, if you
> publish AAAA records for a consumer facing service, please support and
> monitor that service with a similar level to what you do for your IPv4
> versions of the service.
>
> The coming years are going to be difficult enough for end-users without
> adding unnecessary anti-IPv6 sentiments to the mix.
>
> Owen
>
> +1 to Owen's comment.
>
> I'd also add some more comments:
>
> A lot of eyeballs that have v6 right now are the people with a lot of clue.
> Do you want these people, who'll often be buying or recommending your
> services to rate your ability to deliver as a fail?  Our experience with
> IPv6 consumer broadband has been that the early adopters are the people
> who,
> well, goto IETF meetings, follow standards and ask the bloody hard
> questions.
>
> Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated
> as
> HE?? :-) ) most end users prefer IPv6 over IPv4.  Deeply this means there
> is
> a tendency for v6 traffic to grow and be more important to connectivity
> than
> you may imagine.  The tipping point for IPv6 traffic being dominant I
> suspect is going to be a lower threshold of take up than people might
> expect.   Consider this when thinking about the level of thought you give
> to
> IPv6 infrastructure and PPS rates.
>
> MMC
>
>
>


From randy at psg.com  Thu Sep  1 19:13:04 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 02 Sep 2011 09:13:04 +0900
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
Message-ID: <m2hb4v4x9r.wl%randy@psg.com>

> On the flip side of this, many of our employers donate "our" time that
> they are paying us for in order for us to serve NANOG with nary a
> benefit.  If you take just committee calls for the PC alone, this is
> 48 hours a year - a workweek.  Perhaps they should feel that this
> donation nets them something.

it's "public service" not "public employment"

randy



From jra at baylink.com  Thu Sep  1 19:50:18 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 1 Sep 2011 20:50:18 -0400 (EDT)
Subject: Tampa small colo recs?
In-Reply-To: <8701686.400.1314924577802.JavaMail.root@benjamin.baylink.com>
Message-ID: <24261253.402.1314924618891.JavaMail.root@benjamin.baylink.com>

Anyone got any opinions on small colo rental in Tampa; anywhere from 8RU to a 
half-rack?  I'd prefer at least one tier 1 uplink, and at least 1 tier 2,
dial-a-yield 100Base, and 24 hour access, but I'm flexible.  Pinellas County
is also fine.

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      http://photo.imageinc.us             +1 727 647 1274



From dave at temk.in  Thu Sep  1 19:55:11 2011
From: dave at temk.in (David Temkin)
Date: Thu, 1 Sep 2011 20:55:11 -0400
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <m2hb4v4x9r.wl%randy@psg.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
Message-ID: <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>

For context in this discussion, how many times have you personally accepted
free registration in return for presenting?

-Dave
 On Sep 1, 2011 8:13 PM, "Randy Bush" <randy at psg.com> wrote:
>> On the flip side of this, many of our employers donate "our" time that
>> they are paying us for in order for us to serve NANOG with nary a
>> benefit. If you take just committee calls for the PC alone, this is
>> 48 hours a year - a workweek. Perhaps they should feel that this
>> donation nets them something.
>
> it's "public service" not "public employment"
>
> randy


From randy at psg.com  Thu Sep  1 19:56:16 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 02 Sep 2011 09:56:16 +0900
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
Message-ID: <m28vq74v9r.wl%randy@psg.com>

> For context in this discussion, how many times have you personally
> accepted free registration in return for presenting?

no idea.  i also think i was comped for being on the SC.  like jared, i
would have paid.

randy



From randy at psg.com  Thu Sep  1 20:11:25 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 02 Sep 2011 10:11:25 +0900
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
Message-ID: <m27h5r4uki.wl%randy@psg.com>

> For context in this discussion, how many times have you personally
> accepted free registration in return for presenting?

btw, i do not remember a meeting where being comped as an SC member or a
speaker affected whether i would attend or not.

[ and no, senator mccarthy, i am not now nor have i ever been a member
  of the communist party. ]

and fwiw, i would strongly support comping hardship and place a low bar
on it.

i am recently back from sigcomm, where speakers are often introduced as
"looking for a {post-doc, research, teaching} position" and where i saw
tee shirts with "to hire a post-doc, <url>." 

randy



From bill at herrin.us  Thu Sep  1 20:19:43 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 1 Sep 2011 21:19:43 -0400
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <m2hb4v4x9r.wl%randy@psg.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com> <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
Message-ID: <CAP-guGU28ZoSUHtkD8rE_y0zMgGrpxBouRRwacxbyjF9CCSo6A@mail.gmail.com>

On Thu, Sep 1, 2011 at 8:13 PM, Randy Bush <randy at psg.com> wrote:
>> On the flip side of this, many of our employers donate "our" time that
>> they are paying us for in order for us to serve NANOG with nary a
>> benefit. ?If you take just committee calls for the PC alone, this is
>> 48 hours a year - a workweek. ?Perhaps they should feel that this
>> donation nets them something.
>
> it's "public service" not "public employment"

Pay me for the honor and privilege of doing volunteer work for me?
Nice scam if you can swing it.

File this one with "pay to beta test." Not unheard of, but ungrateful.

-Bill


-- 
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 paul at paulstewart.org  Thu Sep  1 20:58:01 2011
From: paul at paulstewart.org (Paul Stewart)
Date: Thu, 1 Sep 2011 21:58:01 -0400
Subject: serviceproviderworld.com
Message-ID: <03db01cc6913$c0a8ba00$41fa2e00$@org>

Hey folks...

 

I know a couple of folks behind this new site and thought it would be
worthwhile for the NANOG community to be made aware of it.
http://www.serviceproviderworld.com/

 

It's basically going to be a directory of service providers across the world
- that's the plan as I understand it.  End-users can visit and review their
service providers etc.

 

Personally, I think this is a great concept - I've seen some online
directories of providers and most of them are either entirely Canada based
or US based and in my opinion not that great.  Please bear in mind that this
site is literally getting started - there is an email link I  found at the
bottom of the site where you can email the group for
assistance/questions/feedback. 

 

Just an FYI ...

 

Thanks,

 

Paul

 



From jra at baylink.com  Thu Sep  1 21:41:39 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 1 Sep 2011 22:41:39 -0400 (EDT)
Subject: DNS: 8.8.8.8 won't resolve noaa.gov sites?
In-Reply-To: <14827202.482.1314931062093.JavaMail.root@benjamin.baylink.com>
Message-ID: <33459001.484.1314931299450.JavaMail.root@benjamin.baylink.com>

[ Cross-posted to NANOG and Outages; replies to outages or outages-discussion;
I would set the header, but Zimbra sucks.  :-) ]

I've had my home box set to use 8.8.8.8 as its primary resolver, falling back
to the BBN anycast.

Sometime today, 8.8.8.8 appears to have stopped resolving www.noaa.gov and
www.nhc.noaa.gov:

; <<>> DiG 9.7.3-P3 <<>> @8.8.8.8 www.noaa.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34999
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.noaa.gov.                  IN      A

;; Query time: 33 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Sep  1 22:38:11 2011
;; MSG SIZE  rcvd: 30

though it resolves Yahoo and Google and Akamai.com and everything else
I throw at it.

Digging noaa.gov at 4.2.2.1 returns what I expect.

Interesting, too, that Firefox 5.0 wouldn't DTRT, even though 4.2.2.1-3 were
the backup nameservers in my resolv.conf.

Road Runner Tampa Bay connection.

Can anyone confirm or deny?  Google DNS or NOAA people here, before I go ping 
NOAA staff on Twitter?

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      http://photo.imageinc.us             +1 727 647 1274



From paul at paulgraydon.co.uk  Thu Sep  1 21:56:39 2011
From: paul at paulgraydon.co.uk (Paul)
Date: Thu, 01 Sep 2011 16:56:39 -1000
Subject: DNS: 8.8.8.8 won't resolve noaa.gov sites?
In-Reply-To: <33459001.484.1314931299450.JavaMail.root@benjamin.baylink.com>
References: <33459001.484.1314931299450.JavaMail.root@benjamin.baylink.com>
Message-ID: <4E6045E7.8030201@paulgraydon.co.uk>

Working fine for me:

$ dig @8.8.8.8 www.noaa.gov

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.noaa.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64856
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.noaa.gov.                  IN      A

;; ANSWER SECTION:
www.noaa.gov.           279     IN      CNAME   edge-hdq.woc.noaa.gov.
edge-hdq.woc.noaa.gov.  279     IN      CNAME   edge-rev.lb.noaa.gov.
edge-rev.lb.noaa.gov.   9       IN      A       140.90.200.23
edge-rev.lb.noaa.gov.   9       IN      A       140.172.17.23
edge-rev.lb.noaa.gov.   9       IN      A       129.15.96.23
edge-rev.lb.noaa.gov.   9       IN      A       140.90.33.23

;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep  2 02:54:13 2011
;; MSG SIZE  rcvd: 147



$ dig @8.8.8.8 www.nhc.noaa.gov

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.nhc.noaa.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36145
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.nhc.noaa.gov.              IN      A

;; ANSWER SECTION:
www.nhc.noaa.gov.       293     IN      CNAME   edge-nws.woc.noaa.gov.
edge-nws.woc.noaa.gov.  293     IN      CNAME   edge-rev.lb.noaa.gov.
edge-rev.lb.noaa.gov.   23      IN      A       140.172.17.23
edge-rev.lb.noaa.gov.   23      IN      A       129.15.96.23
edge-rev.lb.noaa.gov.   23      IN      A       140.90.33.23
edge-rev.lb.noaa.gov.   23      IN      A       140.90.200.23

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep  2 02:56:18 2011
;; MSG SIZE  rcvd: 151


On 09/01/2011 04:41 PM, Jay Ashworth wrote:
> [ Cross-posted to NANOG and Outages; replies to outages or outages-discussion;
> I would set the header, but Zimbra sucks.  :-) ]
>
> I've had my home box set to use 8.8.8.8 as its primary resolver, falling back
> to the BBN anycast.
>
> Sometime today, 8.8.8.8 appears to have stopped resolving www.noaa.gov and
> www.nhc.noaa.gov:
>
> ;<<>>  DiG 9.7.3-P3<<>>  @8.8.8.8 www.noaa.gov
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34999
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;www.noaa.gov.                  IN      A
>
> ;; Query time: 33 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Thu Sep  1 22:38:11 2011
> ;; MSG SIZE  rcvd: 30
>
> though it resolves Yahoo and Google and Akamai.com and everything else
> I throw at it.
>
> Digging noaa.gov at 4.2.2.1 returns what I expect.
>
> Interesting, too, that Firefox 5.0 wouldn't DTRT, even though 4.2.2.1-3 were
> the backup nameservers in my resolv.conf.
>
> Road Runner Tampa Bay connection.
>
> Can anyone confirm or deny?  Google DNS or NOAA people here, before I go ping
> NOAA staff on Twitter?
>
> Cheers,
> -- jra




From jra at baylink.com  Thu Sep  1 22:00:28 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 1 Sep 2011 23:00:28 -0400 (EDT)
Subject: WORKING: DNS: 8.8.8.8 won't resolve noaa.gov sites?
In-Reply-To: <4E6045E7.8030201@paulgraydon.co.uk>
Message-ID: <25739263.486.1314932428851.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Paul" <paul at paulgraydon.co.uk>
> To: nanog at nanog.org
> Sent: Thursday, September 1, 2011 10:56:39 PM
> Subject: Re: DNS: 8.8.8.8 won't resolve noaa.gov sites?
> Working fine for me:
> 
> $ dig @8.8.8.8 www.noaa.gov

Yeah; it was reliably broken all day, and of course, it's now fine here too.

Either someone at NOAA or Google saw that and applied a Magic Kick, or
I was just unlucky.

Sorry for the noise, folks.

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      http://photo.imageinc.us             +1 727 647 1274



From bep at whack.org  Fri Sep  2 00:29:38 2011
From: bep at whack.org (Bruce Pinsky)
Date: Thu, 01 Sep 2011 22:29:38 -0700
Subject: Access and Session Control System?
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <4E6069C2.7020601@whack.org>

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

Jones, Barry wrote:
> 
> Hello all. I am looking at a variety of systems/methods to provide
> (vendor, employee) access into my dmz's. I want to reduce the FW rule
> sets and connections to as minimal as possible. And I want the accessing
> party to only get to the destination I define (like a fw rule).
> 
> When I refer to access, I'm referring to the ability of a vendor or
> employee to perform maintenance tasks on a server(s). The server(s) will
> be running apps for doing different tasks - such as Shavlik, etc..,
> (patching, reports, logging, etc..), so I am envisioning allowing an
> outside vendor/employee (from the internet or corp. net) to RDP or SSH
> to a given Windows or Unix based machines, then perform their
> application work from that jumping off point - kind of like a terminal
> server; but I'd like to control and audit the sessions as well.
> 
> Overall, I can allow a host/port through the FW to a single host, but I
> wanted to be able to do the session management and endpoint controls.
> FW's are ok, but you know as well as I that I now deal with lots of
> rules sets. And I need to also authenticate the user.
> 
> We are a couple smaller facilities (150 hosts each) and I need to be
> able to control and audit the sessions when requested. I have considered
> doing a meetingplace server, then providing escorted access for them, or
> doing just the FW and a "jump" host - but need the endpoint and session
> solution, or just using VPN - but don't want to install a host on the
> vendor machines. I also have looked at a product called EDMZ - wondered
> if anyone had experience with it?
> 
> And did I say I wanted to keep it as simple as possible? :-) It's been a
> few years since I've done hands-on networking work, so excuse the
> long-winded letter. Feel free to email me directly too.
> 

The Cisco ASA firewall/VPN appliance with SSLVPN can provide the kind of
control you are asking for.  You can customize for different connection
profiles that are based individuals and/or groups that specify where they
can connect to and what types of connection protocols can be used.

- -- 
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5gacEACgkQE1XcgMgrtybBWgCgyh9YPD8eNMN1f/UknmL1kHoa
jUYAoNcCKqjxwo3QOv/0nSmp1aF+UPn/
=RtBT
-----END PGP SIGNATURE-----



From sarah.nataf at gmail.com  Fri Sep  2 02:18:26 2011
From: sarah.nataf at gmail.com (Sarah Nataf)
Date: Fri, 2 Sep 2011 09:18:26 +0200
Subject: Axtel Contact Information (AS6503)
Message-ID: <CAPnF7e5kN4o5uTRaRShY2EU3GNGybhhE3o8DOZwiPAckgTU8Lg@mail.gmail.com>

Does anyone have a technical or peering contact at Axtel / AS6503 to address

an apparent netblock hijacking issue?

Axtel is advertising the 2.5.6.0/24 address space to some of their peers
which is
under AS3215 management. No answer from ipmaster at axtel... / noc at avantel...

Any suggestions?
-- 
Sarah


From john-nanog at johnpeach.com  Fri Sep  2 07:21:44 2011
From: john-nanog at johnpeach.com (John Peach)
Date: Fri, 02 Sep 2011 08:21:44 -0400
Subject: Access and Session Control System?
In-Reply-To: <21875121-62EA-4056-A099-EBFCED0B096B@gmail.com>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
 <21875121-62EA-4056-A099-EBFCED0B096B@gmail.com>
Message-ID: <20110902082144.06a49f7a@bart>

On Thu, 1 Sep 2011 17:45:55 -0400
Rafael Rodriguez <packetjockey at gmail.com> wrote:

> I recommend you look into the Juniper SSL VPN products (SA Series). Very power boxes, intuitive admin interface (web driven) and are perfect for the "Vendor Access" type of applications.

They work fine (mostly), but your definition of intuitive obviously does
not coincide with mine.

> 
> Sent from my iPhone
> 
> On Sep 1, 2011, at 16:30, "Jones, Barry" <BEJones at semprautilities.com> wrote:
> 
> > 
> > Hello all.
> > I am looking at a variety of systems/methods to provide (vendor, employee) access into my dmz's. I want to reduce the FW rule sets and connections to as minimal as possible. And I want the accessing party to only get to the destination I define (like a fw rule).
> > 
> > When I refer to access, I'm referring to the ability of a vendor or employee to perform maintenance tasks on a server(s). The server(s) will be running apps for doing different tasks - such as Shavlik, etc..,  (patching, reports, logging, etc..), so I am envisioning allowing an outside vendor/employee (from the internet or corp. net) to RDP or SSH to a given Windows or Unix based machines, then perform their application work from that jumping off point - kind of like a terminal server; but I'd like to control and audit the sessions as well.
> > 
> > Overall, I can allow a host/port through the FW to a single host, but I wanted to be able to do the session management and endpoint controls. FW's are ok, but you know as well as I that I now deal with lots of rules sets. And I need to also authenticate the user.
> > 
> > We are a couple smaller facilities (150 hosts each) and I need to be able to control and audit the sessions when requested. I have considered doing a meetingplace server, then providing escorted access for them, or doing just the FW and a "jump" host - but need the endpoint and session solution, or just using VPN - but don't want to install a host on the vendor machines. I also have looked at a product called EDMZ - wondered if anyone had experience with it?
> > 
> > And did I say I wanted to keep it as simple as possible? :-) It's been a few years since I've done hands-on networking work, so excuse the long-winded letter. Feel free to email me directly too.
> > 
> > Sincerely
> > Barry Jones
> > CISSP, GSNA
> 



-- 
john



From lyle at lcrcomputer.net  Fri Sep  2 07:52:04 2011
From: lyle at lcrcomputer.net (Lyle Giese)
Date: Fri, 02 Sep 2011 07:52:04 -0500
Subject: DNS: 8.8.8.8 won't resolve noaa.gov sites?
In-Reply-To: <33459001.484.1314931299450.JavaMail.root@benjamin.baylink.com>
References: <33459001.484.1314931299450.JavaMail.root@benjamin.baylink.com>
Message-ID: <4E60D174.20102@lcrcomputer.net>

On 09/01/11 21:41, Jay Ashworth wrote:
> [ Cross-posted to NANOG and Outages; replies to outages or outages-discussion;
> I would set the header, but Zimbra sucks.  :-) ]
>
> I've had my home box set to use 8.8.8.8 as its primary resolver, falling back
> to the BBN anycast.
>
> Sometime today, 8.8.8.8 appears to have stopped resolving www.noaa.gov and
> www.nhc.noaa.gov:
>
> ;<<>>  DiG 9.7.3-P3<<>>  @8.8.8.8 www.noaa.gov
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34999
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;www.noaa.gov.                  IN      A
>
> ;; Query time: 33 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Thu Sep  1 22:38:11 2011
> ;; MSG SIZE  rcvd: 30
>
> though it resolves Yahoo and Google and Akamai.com and everything else
> I throw at it.
>
> Digging noaa.gov at 4.2.2.1 returns what I expect.
>
> Interesting, too, that Firefox 5.0 wouldn't DTRT, even though 4.2.2.1-3 were
> the backup nameservers in my resolv.conf.
>
> Road Runner Tampa Bay connection.
>
> Can anyone confirm or deny?  Google DNS or NOAA people here, before I go ping
> NOAA staff on Twitter?
>
> Cheers,
> -- jra

Jay,
wonder if this has anything to do with DNSSEC?  These records were 
resigned on Sept 2 at 08:50 GMT.  If the signature expired and they were 
late in resigning the records...

I just discovered a minor issue with dnssec tools and zonesigner in 
there.  Zonesigner defaults to a 30 day expiration and they recommend 
running it once a month.  What happens in months with 31 days?

Lyle Giese
LCR Computer Services, Inc.



From brandon.kim at brandontek.com  Fri Sep  2 08:21:20 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Fri, 2 Sep 2011 09:21:20 -0400
Subject: serviceproviderworld.com
In-Reply-To: <03db01cc6913$c0a8ba00$41fa2e00$@org>
References: <03db01cc6913$c0a8ba00$41fa2e00$@org>
Message-ID: <BLU158-W485F041D2BBCC053DDD893DC180@phx.gbl>


I agree, this sounds like a great idea.

Just checked it out, they could "lose" the 90's style logo though.....try web 2.0...at the very least...

haha...

=)



> From: paul at paulstewart.org
> To: nanog at nanog.org
> Subject: serviceproviderworld.com
> Date: Thu, 1 Sep 2011 21:58:01 -0400
> 
> Hey folks...
> 
>  
> 
> I know a couple of folks behind this new site and thought it would be
> worthwhile for the NANOG community to be made aware of it.
> http://www.serviceproviderworld.com/
> 
>  
> 
> It's basically going to be a directory of service providers across the world
> - that's the plan as I understand it.  End-users can visit and review their
> service providers etc.
> 
>  
> 
> Personally, I think this is a great concept - I've seen some online
> directories of providers and most of them are either entirely Canada based
> or US based and in my opinion not that great.  Please bear in mind that this
> site is literally getting started - there is an email link I  found at the
> bottom of the site where you can email the group for
> assistance/questions/feedback. 
> 
>  
> 
> Just an FYI ...
> 
>  
> 
> Thanks,
> 
>  
> 
> Paul
> 
>  
> 
 		 	   		  

From paul at paulstewart.org  Fri Sep  2 08:44:57 2011
From: paul at paulstewart.org (Paul Stewart)
Date: Fri, 2 Sep 2011 09:44:57 -0400
Subject: serviceproviderworld.com
In-Reply-To: <BLU158-W485F041D2BBCC053DDD893DC180@phx.gbl>
References: <03db01cc6913$c0a8ba00$41fa2e00$@org>
 <BLU158-W485F041D2BBCC053DDD893DC180@phx.gbl>
Message-ID: <043501cc6976$82bf8a30$883e9e90$@org>

Hehe... I said almost the exact same thing - oh well, give it some time and
I'm sure it'll be "prettier"...;)

 

From: brandon.j.kim at live.com [mailto:brandon.j.kim at live.com] On Behalf Of
Brandon Kim
Sent: September-02-11 9:21 AM
To: paul at paulstewart.org; nanog group
Subject: RE: serviceproviderworld.com

 

I agree, this sounds like a great idea.

Just checked it out, they could "lose" the 90's style logo though.....try
web 2.0...at the very least...

haha...

=)






From jhsu-nanog at mur.com  Fri Sep  2 09:17:59 2011
From: jhsu-nanog at mur.com (kobi hsu)
Date: Fri, 2 Sep 2011 10:17:59 -0400
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <m2r53z4yhs.wl%randy@psg.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <m2r53z4yhs.wl%randy@psg.com>
Message-ID: <CADtGNZLawkiUj-Hj0ZRmKiq1fyYadv=Fn=C9jK8FoC95DxQG6g@mail.gmail.com>

>
> > To bring it closer to home - we give our presenters a free admission -
> > should we also stop that?
>
> i am ambivalent.  i think there is some sort of untested assumption that
> this attracts an otherwise unattracted resources we need.
>
> otoh, committees seem to attract flies.  i will not comment on their
> quality.
>

Flies, ouch. Or maybe gadflies? ;-)

>From personal experience-- volunteering through committee work is fairly
easy when NANOG is an important focus for the employer/employing group. It
is very very difficult if one's management has no interest in NANOG or its
products.

For most of the time I was on the PC, I was also a full-time student, and
needed the help of student pricing to fulfill my commitment to the
community.

Even with student pricing, however, travel and hotels each year would run
into the thousands.

Given a choice between supporting NANOG, or taking those thousands and
increasing my support to my parents... once my term was up, the parents won.

For all the griping and moaning that goes on, I do think that valuable work
goes on at NANOG. I just can't afford to participate on an individual basis.
That may or may not be a loss to the community. ;-)

_kobi


From jlmcgraw at gmail.com  Fri Sep  2 09:24:23 2011
From: jlmcgraw at gmail.com (Jesse McGraw)
Date: Fri, 02 Sep 2011 10:24:23 -0400
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <4E60E717.5050406@gmail.com>

   I've recently run into a hard-to-troubleshoot issue where, somewhere 
out in the greater Internet, someone was silently dropping packets from 
my company that happened to be marked with DSCP AF21.  I'd fully expect 
others to either ignore these markings or zero them out but just 
silently dropping them seems unnecessary.

So, how do you guys treat marked packets that come into/through your 
networks?



From saku at ytti.fi  Fri Sep  2 09:48:17 2011
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 2 Sep 2011 17:48:17 +0300
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: <4E60E717.5050406@gmail.com>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
 <4E60E717.5050406@gmail.com>
Message-ID: <20110902144817.GA23688@pob.ytti.fi>

On (2011-09-02 10:24 -0400), Jesse McGraw wrote:

>   I've recently run into a hard-to-troubleshoot issue where,
> somewhere out in the greater Internet, someone was silently dropping
> packets from my company that happened to be marked with DSCP AF21.
> I'd fully expect others to either ignore these markings or zero them
> out but just silently dropping them seems unnecessary.
> 
> So, how do you guys treat marked packets that come into/through your
> networks?

There really are three options.

1. Zero them out (or mark what ever value you handle as 'public internet'

2. Leave them alone, and never use them (either you don't have QoS deployed, or
you trust MPLS EXP or comparable marking in other layer than IP, which is
explictly coloured to reflect 'public internet'

3. Have mutual trust between both parties how traffic market and trusted, this
will never work for IP transit.

Seems in this instance someone has deployed QoS and is trusting markings from
Internet, which is just broken, as they cannot anymore guarantee that customer
video/voice etc works during congestion, so the QoS product is broken.


-- 
  ++ytti



From jsaxe at briworks.com  Fri Sep  2 09:49:32 2011
From: jsaxe at briworks.com (Jeff Saxe)
Date: Fri, 2 Sep 2011 14:49:32 +0000
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: <4E60E717.5050406@gmail.com>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com><E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX
 7MB-P03.corp.se.sempra.com>,<4E60E717.5050406@gmail.com>
Message-ID: <A92EB23D9E64824189C99C5ABF833104197EA51D@mbx024-e1-nj-2.exch024.domain.local>

I must say, that seems not terribly sporting.  :-)

Seriously, I would expect that most public Internet carriers, unless you paid them extra fees to pay attention to the DSCP markings, would completely ignore them and treat it all as best-effort traffic, right up to and including the last-mile circuit that should be the congestion point at which QoS would be most useful to differentiate. I don't think it would be the stated policy of any public ISP to drop other-than-zero-marked packets, especially if it's a transit somewhere that's out of reach of either you or the other customer you're trying to reach.

But I know from personal experience that some pieces of Ethernet switch gear can have policies, even at Layer 2, which affect traffic in ways that were not obvious when the human engineers deployed them. I ran into one such problem while deploying a straight-up Internet service to a customer on some GPON gear, and I used a built-in filter to select traffic on a VLAN basis, but I didn't realize that the filter also (unconditionally) matched on Layer 2 QoS markings (802.1p in the VLAN tag) at the same time. And my core Ethernet switch had QoS globally enabled, which meant that it was snooping at the Layer 3 DSCP tag and adapting it (dividing by 8, basically) and placing it into the 802.1p field on the way out the trunk port to the GPON gear.

This didn't affect anything until the customer started using a remote backup service -- Mozy, I believe -- which, in a lame attempt to obtain better transit "for free" from ISPs who accidentally pay attention to markings, marked its own HTTPS traffic higher than zero. So my customer could reach anyplace on the Internet except for this backup service -- pings to them worked, but starting a Web session or a backup to the same exact IP address would return no packets. And when I tried from our core (not going through the GPON), it worked perfectly. It was a bit of a head-scratcher until we tcpdump'ed the traffic and looked at it carefully. I assume the same thing would have happened had one of my customers tried to use a SIP VoIP carrier through our Internet.

So, in short, I would guess that your upstream's dropping problem was *probably* accidental rather than intentional, and if you can bring it to the attention of the right people at that ISP, they'd probably be grateful.

-- Jeff Saxe
Blue Ridge InternetWorks
Charlottesville, VA




________________________________________
From: Jesse McGraw [jlmcgraw at gmail.com]
Sent: Friday, September 02, 2011 10:24 AM
To: nanog at nanog.org
Subject: Silently dropping QoS marked packets on the greater Internet

   I've recently run into a hard-to-troubleshoot issue where, somewhere
out in the greater Internet, someone was silently dropping packets from
my company that happened to be marked with DSCP AF21.  I'd fully expect
others to either ignore these markings or zero them out but just
silently dropping them seems unnecessary.

So, how do you guys treat marked packets that come into/through your
networks?




From jared at puck.nether.net  Fri Sep  2 10:07:34 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 2 Sep 2011 11:07:34 -0400
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <m28vq74v9r.wl%randy@psg.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
 <m28vq74v9r.wl%randy@psg.com>
Message-ID: <D9935F6B-4108-4864-8A67-F6D8A4D83EF2@puck.nether.net>

The SC did not receive comp registration any time while I was serving on it.  It was possible to be comped for one of a few reasons:

1) Host
2) Speaker
3) Merit
4) B&G Sponsor (i think they got 2 comp registrations)
5) the ARIN scholarship thing.

I was on the SC and also on a panel in Dallas (the case I'm thinking of).  The meetings covered Feb 14th and a snowstorm that kept people from making it.  It was a "big deal" at the time for the merit/nanog finances.

I do feel the need to suggest that Dorian/Randy are on the mark here, most of these people would pay anyways.

- Jared

On Sep 1, 2011, at 8:56 PM, Randy Bush wrote:

>> For context in this discussion, how many times have you personally
>> accepted free registration in return for presenting?
> 
> no idea.  i also think i was comped for being on the SC.  like jared, i
> would have paid.
> 
> randy




From jmamodio at gmail.com  Fri Sep  2 10:19:34 2011
From: jmamodio at gmail.com (Jorge Amodio)
Date: Fri, 2 Sep 2011 10:19:34 -0500
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <m27h5r4uki.wl%randy@psg.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
 <m27h5r4uki.wl%randy@psg.com>
Message-ID: <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>

I agree that only those organizing or with a real need of financial
support (folks from developing countries or from non-profit orgs or
some students without substantial resources) could have their
admission fee waived or reduced, all the rest MUST pay, even if you
give a talk or serve in other capacity.

As others said you are doing a "public service" to the rest of the
community and if you give a nice and valuable talk you will get the
recognition of the NANOG community and your colleagues, and we can put
into consideration including a gold star sticker for your service.

It will be really unfair for those paying (even if their companies do
it for them or don't care because they have a mountain of cash) if
there is a special benefit for some so they don't pay.

My .02
-J



From deleskie at gmail.com  Fri Sep  2 10:27:13 2011
From: deleskie at gmail.com (jim deleskie)
Date: Fri, 2 Sep 2011 12:27:13 -0300
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
 <m27h5r4uki.wl%randy@psg.com>
 <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>
Message-ID: <CAJL_ZMNCKWMMv-3MRwT43wRVEhXs+pC3tduTG6RSsMrsHB+kLQ@mail.gmail.com>

I have no problem with speakers getting in free.  Speakers may or may
not be active in the community and if you  want to continue to draw
quality speakers this is truly the least the community can do.  Many
conferences will pick up travel costs, or even token 'gifts' for
speakers.  As for committee members I have no problem with them
getting in free. Unless you have 50-60 free attendees at a conference
I don't expect its going to cause financial hardship on the org.  If a
members company is willing to pay anyway, then people always have the
option of not accepting the free entrance.  As for people 'hardship'
cases, how ever you want to define it, there is no revenue loss here
as they would be unlikely so spend $ to attend anyway if they had to
pay.


-jim

On Fri, Sep 2, 2011 at 12:19 PM, Jorge Amodio <jmamodio at gmail.com> wrote:
> I agree that only those organizing or with a real need of financial
> support (folks from developing countries or from non-profit orgs or
> some students without substantial resources) could have their
> admission fee waived or reduced, all the rest MUST pay, even if you
> give a talk or serve in other capacity.
>
> As others said you are doing a "public service" to the rest of the
> community and if you give a nice and valuable talk you will get the
> recognition of the NANOG community and your colleagues, and we can put
> into consideration including a gold star sticker for your service.
>
> It will be really unfair for those paying (even if their companies do
> it for them or don't care because they have a mountain of cash) if
> there is a special benefit for some so they don't pay.
>
> My .02
> -J
>
>



From jared at puck.nether.net  Fri Sep  2 10:55:31 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 2 Sep 2011 11:55:31 -0400
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <CAJL_ZMNCKWMMv-3MRwT43wRVEhXs+pC3tduTG6RSsMrsHB+kLQ@mail.gmail.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
 <m27h5r4uki.wl%randy@psg.com>
 <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>
 <CAJL_ZMNCKWMMv-3MRwT43wRVEhXs+pC3tduTG6RSsMrsHB+kLQ@mail.gmail.com>
Message-ID: <1C36870A-6958-4C32-94C6-0738F284BA51@puck.nether.net>

Two comments here:

In the past a human would review and refund speakers if they paid. 

A nominal co-pay may be appropriate, even if it's just $10. Students qualify for lower rates last I recall as well. We are talking about a small number of people here, at most 1-2 per conference I suspect based on historical chats. 

Jared Mauch

On Sep 2, 2011, at 11:27 AM, jim deleskie <deleskie at gmail.com> wrote:

> If a
> members company is willing to pay anyway, then people always have the
> option of not accepting the free entrance.  As for people 'hardship'
> cases, how ever you want to define it, there is no revenue loss here
> as they would be unlikely so spend $ to attend anyway if they had to
> pay.



From mark at amplex.net  Fri Sep  2 10:56:48 2011
From: mark at amplex.net (Mark Radabaugh)
Date: Fri, 02 Sep 2011 11:56:48 -0400
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: <4E60E717.5050406@gmail.com>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
 <4E60E717.5050406@gmail.com>
Message-ID: <4E60FCC0.8070003@amplex.net>

On 9/2/11 10:24 AM, Jesse McGraw wrote:
>   I've recently run into a hard-to-troubleshoot issue where, somewhere 
> out in the greater Internet, someone was silently dropping packets 
> from my company that happened to be marked with DSCP AF21.  I'd fully 
> expect others to either ignore these markings or zero them out but 
> just silently dropping them seems unnecessary.
>
> So, how do you guys treat marked packets that come into/through your 
> networks?
Generally strip at the border the specific DSCP values that would 
trigger reserved bandwidth / priority handling in the distribution and 
last mile network.    Otherwise we leave them alone.

-- 
Mark Radabaugh
Amplex

mark at amplex.net  419.837.5015




From Valdis.Kletnieks at vt.edu  Fri Sep  2 11:02:03 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 02 Sep 2011 12:02:03 -0400
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: Your message of "Fri, 02 Sep 2011 17:48:17 +0300."
 <20110902144817.GA23688@pob.ytti.fi>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
 <4E60E717.5050406@gmail.com> <20110902144817.GA23688@pob.ytti.fi>
Message-ID: <6403.1314979323@turing-police.cc.vt.edu>

On Fri, 02 Sep 2011 17:48:17 +0300, Saku Ytti said:

> Seems in this instance someone has deployed QoS and is trusting markings from
> Internet, which is just broken, as they cannot anymore guarantee that customer
> video/voice etc works during congestion, so the QoS product is broken.

Except you can't actually *guarantee* that QoS works every packet, every time,
during congestion even within the same network. Remember - QoS is just a
marking to shoot the other guy first.  If a link ends up overcommitted with QoS
traffic, you're still screwed.  And there's a second-order effect as well - if
your net is running sufficiently close to the capacity edge that QoS actually
matters, there's probably other engineering deficiencies that are just waiting
to screw you up.

Is the story I've heard about people managing to saturate a link with QoS'ed
traffic, and then having the link drop because network management traffic was
basically DoS'ed, apocryphal, or have people shot themselves in the foot that
way?

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

From deleskie at gmail.com  Fri Sep  2 11:13:19 2011
From: deleskie at gmail.com (jim deleskie)
Date: Fri, 2 Sep 2011 13:13:19 -0300
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <1C36870A-6958-4C32-94C6-0738F284BA51@puck.nether.net>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
 <m27h5r4uki.wl%randy@psg.com>
 <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>
 <CAJL_ZMNCKWMMv-3MRwT43wRVEhXs+pC3tduTG6RSsMrsHB+kLQ@mail.gmail.com>
 <1C36870A-6958-4C32-94C6-0738F284BA51@puck.nether.net>
Message-ID: <CAJL_ZMN4CpUFm0hJPyrztWerqsk9yrdUxZB=zgVHw6iJmGWtMw@mail.gmail.com>

I think a co-pay would be be reasonable.    If I human manually did a
refund I'm sure the process could ne 'fixed'.  It would be interesting
to know how many people, based on paste events this would impact.  I
agree in that I as well suspect its a very low number.

-jim

On Fri, Sep 2, 2011 at 12:55 PM, Jared Mauch <jared at puck.nether.net> wrote:
> Two comments here:
>
> In the past a human would review and refund speakers if they paid.
>
> A nominal co-pay may be appropriate, even if it's just $10. Students qualify for lower rates last I recall as well. We are talking about a small number of people here, at most 1-2 per conference I suspect based on historical chats.
>
> Jared Mauch
>
> On Sep 2, 2011, at 11:27 AM, jim deleskie <deleskie at gmail.com> wrote:
>
>> If a
>> members company is willing to pay anyway, then people always have the
>> option of not accepting the free entrance. ?As for people 'hardship'
>> cases, how ever you want to define it, there is no revenue loss here
>> as they would be unlikely so spend $ to attend anyway if they had to
>> pay.
>



From saku at ytti.fi  Fri Sep  2 11:17:51 2011
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 2 Sep 2011 19:17:51 +0300
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: <6403.1314979323@turing-police.cc.vt.edu>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
 <4E60E717.5050406@gmail.com> <20110902144817.GA23688@pob.ytti.fi>
 <6403.1314979323@turing-police.cc.vt.edu>
Message-ID: <20110902161751.GA23737@pob.ytti.fi>

On (2011-09-02 12:02 -0400), Valdis.Kletnieks at vt.edu wrote:

> Except you can't actually *guarantee* that QoS works every packet, every time,
> during congestion even within the same network. Remember - QoS is just a
> marking to shoot the other guy first.  If a link ends up overcommitted with QoS
> traffic, you're still screwed.  And there's a second-order effect as well - if

I guess you're trying to say, if the protected traffic class is out-of-contract
you're still out of luck, that is true.
If you're trying to say that any link which which is overcomitted is lost cause
anyhow, QoS or not, this of course is not true, if link is not overcommitted
QoS makes no sense.

> your net is running sufficiently close to the capacity edge that QoS actually
> matters, there's probably other engineering deficiencies that are just waiting
> to screw you up.

Lot of customers have low speed DSL connections and want to run VoIP over 
that, even if whole office is surfing lolcats.
This works, and it works perfectly when configured correctly, of course if VoIP
traffic would exceed capacity, you're still screwed, this is where planning
comes in, you will sell only X VoIP lines which will always fit, just lolcats
will load slower.
If this link gets uncontrollable priority traffic from Internet, all bets are
off, hence the options in the first post

-- 
  ++ytti



From pdonner at cisco.com  Fri Sep  2 12:16:48 2011
From: pdonner at cisco.com (Paul Donner)
Date: Fri, 02 Sep 2011 11:16:48 -0600
Subject: ISP Two-Way Utilization Studies between Subscriber and Network
Message-ID: <4E610F80.4010708@cisco.com>

Can anyone point me to useful recent studies showing the ratio of
downstream to upstream traffic loading for a typical home Internet user?

Broken out by traffic type would be really nice but not holding my breath.

Thanks,

-Donner



From randy at psg.com  Fri Sep  2 12:37:51 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 03 Sep 2011 02:37:51 +0900
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <D9935F6B-4108-4864-8A67-F6D8A4D83EF2@puck.nether.net>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
 <m28vq74v9r.wl%randy@psg.com>
 <D9935F6B-4108-4864-8A67-F6D8A4D83EF2@puck.nether.net>
Message-ID: <m2d3fi3kwg.wl%randy@psg.com>

> The SC did not receive comp registration any time while I was serving
> on it.

aha!  sorry.  my memory is not what it used to be.

> I do feel the need to suggest that Dorian/Randy are on the mark here,
> most of these people would pay anyways.

as i said, if nanog has the funds, i would support general hardship
support with a very low bar.

randy



From dotis at mail-abuse.org  Fri Sep  2 12:44:59 2011
From: dotis at mail-abuse.org (Douglas Otis)
Date: Fri, 02 Sep 2011 10:44:59 -0700
Subject: NAT444 or ?
In-Reply-To: <CAD6AjGQHGEVcFwe43g6PcWoBKfEirswG8hn_QTT8apHi8yTz1A@mail.gmail.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <CAD6AjGQHGEVcFwe43g6PcWoBKfEirswG8hn_QTT8apHi8yTz1A@mail.gmail.com>
Message-ID: <4E61161B.3000603@mail-abuse.org>

On 9/1/11 11:52 AM, Cameron Byrne wrote:
> On Thu, Sep 1, 2011 at 11:36 AM, Serge Vautour<sergevautour at yahoo.ca>  wrote:
>> Hello,
>>
>> Things I understand: IPv6 is the long term solution to IPv4 exhaustion. For IPv6 to work correctly, most of the IPv4 content has to be on IPv6. That's not there yet. IPv6 deployment to end users is not trivial (end user support, CPE support, etc...). Translation techniques are generally evil. IPv6->IPv4 still requires 1 IPv4 IP per end user or else you're doing NAT. IPv4->IPv6 (1-1) doesn't solve our main problem of giving users access to the IPv4 Internet.
> Correct, all content is not there yet... but World IPv6 Day showed
> that Google, Facebook, Yahoo, Microsoft and 400+ others are just about
> ready to go.
>
> http://en.wikipedia.org/wiki/World_IPv6_Day
>
> IPv6->IPv4 does not require 1 to 1, .... any protocol translation is a
> form of NATish things, and stateful NAT64 has many desirable
> properties IF you already do NAT44.  Specifically, it is nice that
> IPv6 flows bypass the NAT .... and as more content becomes  IPv6, NAT
> becomes less and less used.  In this way, unlike NAT44 or NAT444,
> NAT64 has an exit strategy that ends with proper E2E networking with
> IPv6... the technology and economic incentives push the right way
> (more IPv6...)
>
> Have a look at http://tools.ietf.org/html/rfc6146
>
> There are multiple opensource and big vendor (C, J, B, LB guys...)
> implementation of NAT64 / DNS64 ... I have trialed it and plan to
> deploy it, YMMV... It works great for web and email, not so great for
> gaming and Skype.
http://tools.ietf.org/html/rfc6333
http://tools.ietf.org/html/draft-bpw-pcp-nat-pmp-interworking-00
moves CPE NAT to the ISP tunneled over 192.0.0.0/29.
>> Has anyone deployed NAT444? Can folks share their experiences? Does it really break this many apps? What other options do we have?
> Yes, expect it to be deployed in places where the access gear can only
> do IPv4 and there is no money or technology available to bring in
> IPv6.
A false economy when support outweigh CPE cost.

-Doug



From bmanning at vacation.karoshi.com  Fri Sep  2 12:48:57 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 2 Sep 2011 17:48:57 +0000
Subject: admission rulz
In-Reply-To: <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>
References: <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
 <m27h5r4uki.wl%randy@psg.com>
 <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>
Message-ID: <20110902174857.GA5787@vacation.karoshi.com.>

 kind of old-skool, but I figured that NANOG was a group of peers
meeting to learn/share with each other.  most of the time i would expect
each particpant to pay her own way... under -limited- hardship cases,
as a member, i'd be happy to have my dues contribute to a stellar speaker
who is otherwise unable to attend.  but that should be a rare thing.
otherwise, i'd want the other members to occasionally pay for me to attend.

IMHO.

/bill


On Fri, Sep 02, 2011 at 10:19:34AM -0500, Jorge Amodio wrote:
> I agree that only those organizing or with a real need of financial
> support (folks from developing countries or from non-profit orgs or
> some students without substantial resources) could have their
> admission fee waived or reduced, all the rest MUST pay, even if you
> give a talk or serve in other capacity.
> 
> As others said you are doing a "public service" to the rest of the
> community and if you give a nice and valuable talk you will get the
> recognition of the NANOG community and your colleagues, and we can put
> into consideration including a gold star sticker for your service.
> 
> It will be really unfair for those paying (even if their companies do
> it for them or don't care because they have a mountain of cash) if
> there is a special benefit for some so they don't pay.
> 
> My .02
> -J



From graham at g-rock.net  Fri Sep  2 13:12:40 2011
From: graham at g-rock.net (Graham Wooden)
Date: Fri, 02 Sep 2011 13:12:40 -0500
Subject: [Semi-OT] - SIP/PRI Voice Origination & LNP for Jackson, MO
Message-ID: <20110902131240.munya83jc4s844k4@webmail.g-rock.net>

Hi there,

Casting a large net here ... any Ops on this list that has an already  
established interconnect or resell services agreement with the folling  
CLECs?  Jackson, MO is apparently a black hole and I can't get any  
ratecenters for LNP with Level3/GBLX/Paetec, so our normal SIP  
Origination channels are no good.

Here are the companies that apparently can handle LNP and Originate  
for Jackson.

** SBC/AT&T - While we can get PRIs and/or their IP Flex, they won't  
allow us to port numbers in that aren't ours - ie. we can't become a  
reseller.

** Charter Fiberlink - Not getting anywhere with them. No good sales  
contact info that has a clue. Anyone have a good sales contact?

** Big River Telephone - initially sounded interested in selling us  
their services, but won't return my follow up calls. Maybe we too  
small of a fish or maybe they dont like the competition?

** Teleport Communications Group - Not getting anywhere with them. No  
good sales contact info that has a clue. Anyone have a good sales  
contact?

What we need ... to be able to LNP 573-204 and 573-243 and have the  
inbound calls come to us, either via SIP or a NxPRI there at our  
remote POP in Jackson.
To start, we're looking to LNP about 300 to 400 numbers and have about  
50 concurrent calls. This will be ramping up ...

I would appreciate any and all replies off-list please.  Thanks!

-graham




From cscora at apnic.net  Fri Sep  2 14:10:00 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 3 Sep 2011 05:10:00 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201109021910.p82JA0vu003979@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,
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 03 Sep, 2011

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

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

BGP routing table entries examined:                              370062
    Prefixes after maximum aggregation:                          167213
    Deaggregation factor:                                          2.21
    Unique aggregates announced to Internet:                     183305
Total ASes present in the Internet Routing Table:                 38662
    Prefixes per ASN:                                              9.57
Origin-only ASes present in the Internet Routing Table:           32065
Origin ASes announcing only one prefix:                           15405
Transit ASes present in the Internet Routing Table:                5220
Transit-only ASes present in the Internet Routing Table:            139
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      36
    Max AS path prepend of ASN (22394)                               33
Prefixes from unregistered ASNs in the Routing Table:              1179
    Unregistered ASNs in the Routing Table:                         675
Number of 32-bit ASNs allocated by the RIRs:                       1700
Number of 32-bit ASNs visible in the Routing Table:                1377
Prefixes from 32-bit ASNs in the Routing Table:                    3177
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            110
Number of addresses announced to Internet:                   2472185408
    Equivalent to 147 /8s, 90 /16s and 142 /24s
    Percentage of available address space announced:               66.7
    Percentage of allocated address space announced:               66.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               91.2
Total number of prefixes smaller than registry allocations:      154267

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

Prefixes being announced by APNIC Region ASes:                    93241
    Total APNIC prefixes after maximum aggregation:               30588
    APNIC Deaggregation factor:                                    3.05
Prefixes being announced from the APNIC address blocks:           89767
    Unique aggregates announced from the APNIC address blocks:    38038
APNIC Region origin ASes present in the Internet Routing Table:    4545
    APNIC Prefixes per ASN:                                       19.75
APNIC Region origin ASes announcing only one prefix:               1248
APNIC Region transit ASes present in the Internet Routing Table:    709
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         18
Number of APNIC region 32-bit ASNs visible in the Routing Table:     79
Number of APNIC addresses announced to Internet:              625813024
    Equivalent to 37 /8s, 77 /16s and 38 /24s
    Percentage of available APNIC address space announced:         79.4

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
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, 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:                    142899
    Total ARIN prefixes after maximum aggregation:                73449
    ARIN Deaggregation factor:                                     1.95
Prefixes being announced from the ARIN address blocks:           114823
    Unique aggregates announced from the ARIN address blocks:     47244
ARIN Region origin ASes present in the Internet Routing Table:    14626
    ARIN Prefixes per ASN:                                         7.85
ARIN Region origin ASes announcing only one prefix:                5626
ARIN Region transit ASes present in the Internet Routing Table:    1551
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          36
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               804272128
    Equivalent to 47 /8s, 240 /16s and 56 /24s
    Percentage of available ARIN address space announced:          63.9

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, 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, 173/8,
                       174/8, 184/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:                     87977
    Total RIPE prefixes after maximum aggregation:                49929
    RIPE Deaggregation factor:                                     1.76
Prefixes being announced from the RIPE address blocks:            81096
    Unique aggregates announced from the RIPE address blocks:     53651
RIPE Region origin ASes present in the Internet Routing Table:    15930
    RIPE Prefixes per ASN:                                         5.09
RIPE Region origin ASes announcing only one prefix:                7931
RIPE Region transit ASes present in the Internet Routing Table:    2507
Average RIPE Region AS path length visible:                         4.6
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:     981
Number of RIPE addresses announced to Internet:               488374784
    Equivalent to 29 /8s, 28 /16s and 2 /24s
    Percentage of available RIPE address space announced:          78.7

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
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,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   34284
    Total LACNIC prefixes after maximum aggregation:               7721
    LACNIC Deaggregation factor:                                   4.44
Prefixes being announced from the LACNIC address blocks:          33570
    Unique aggregates announced from the LACNIC address blocks:   17498
LACNIC Region origin ASes present in the Internet Routing Table:   1514
    LACNIC Prefixes per ASN:                                      22.17
LACNIC Region origin ASes announcing only one prefix:               447
LACNIC Region transit ASes present in the Internet Routing Table:   279
Average LACNIC Region AS path length visible:                       4.5
    Max LACNIC Region AS path length visible:                        19
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   301
Number of LACNIC addresses announced to Internet:              87749504
    Equivalent to 5 /8s, 58 /16s and 243 /24s
    Percentage of available LACNIC address space announced:        58.1

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8317
    Total AfriNIC prefixes after maximum aggregation:              2022
    AfriNIC Deaggregation factor:                                  4.11
Prefixes being announced from the AfriNIC address blocks:          6417
    Unique aggregates announced from the AfriNIC address blocks:   2012
AfriNIC Region origin ASes present in the Internet Routing Table:   483
    AfriNIC Prefixes per ASN:                                     13.29
AfriNIC Region origin ASes announcing only one prefix:              153
AfriNIC Region transit ASes present in the Internet Routing Table:  104
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             26801152
    Equivalent to 1 /8s, 152 /16s and 244 /24s
    Percentage of available AfriNIC address space announced:       39.9

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2508      11047         954   Korea Telecom (KIX)
17974     1949        516          31   PT TELEKOMUNIKASI INDONESIA
 7545     1577        301          83   TPG Internet Pty Ltd
 4755     1538        635         169   TATA Communications formerly 
24560     1195        337         187   Bharti Airtel Ltd., Telemedia
 9829     1151        989          28   BSNL National Internet Backbo
 4808     1073       2092         305   CNCGROUP IP network: China169
 9583     1073         79         503   Sify Limited
17488     1031        192         150   Hathway IP Over Cable Interne
 7552      991       1062          11   Vietel Corporation

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

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3564       3817         227   bellsouth.net, inc. 
18566     1913        365         238   Covad Communications 
 1785     1822        680         122   PaeTec Communications, Inc.
 4323     1624       1085         396   Time Warner Telecom
20115     1590       1540         633   Charter Communications 
 7029     1581        995         230   Windstream Communications Inc
22773     1452       2906          99   Cox Communications, Inc.
19262     1393       4716         399   Verizon Global Networks 
 7018     1341       7051         877   AT&T WorldNet Services
 2386     1222        515         880   AT&T Data Communications Serv

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
34984      541        107         182   BILISIM TELEKOM
 6830      523       1811         321   UPC Distribution Services
20940      490        148         383   Akamai Technologies European 
 3292      470       2079         404   TDC Tele Danmark
12479      466        593           7   Uni2 Autonomous System
 8866      459        133          26   Bulgarian Telecommunication C
 3320      430       8152         374   Deutsche Telekom AG
29049      424         31          55   AzerSat LLC.
 8402      404        352          13   Corbina telecom
 8551      404        354          44   Bezeq International

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

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1628        298         154   TVCABLE BOGOTA 
 8151     1405       2775         351   UniNet S.A. de C.V. 
28573     1283       1003          71   NET Servicos de Comunicao S.A
 7303     1058        578         170   Telecom Argentina Stet-France
14420      715         57          88   CORPORACION NACIONAL DE TELEC
 6503      591        450          68   AVANTEL, S.A. 
22047      579        322          17   VTR PUNTO NET S.A. 
27947      561         55          82   Telconet S.A
 3816      531        232          96   Empresa Nacional de Telecomun
 7738      515        986          31   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
24863      809        147          43   LINKdotNET AS number
 8452      625        445          11   TEDATA
15475      512         74           8   Nile Online
36992      302        415          14   Etisalat MISR
 3741      266        937         227   The Internet Solution 
 6713      242        519          14   Itissalat Al-MAGHRIB
15706      219         32           6   Sudatel Internet Exchange Aut
33776      207         13          14   Starcomms Nigeria Limited
12258      194         28          61   Vodacom Internet Company 
24835      181         70          12   RAYA Telecom - Egypt

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
 6389     3564       3817         227   bellsouth.net, inc. 
23456     3177        752        1709   32-bit ASN transition
 4766     2508      11047         954   Korea Telecom (KIX)
17974     1949        516          31   PT TELEKOMUNIKASI INDONESIA
18566     1913        365         238   Covad Communications 
 1785     1822        680         122   PaeTec Communications, Inc.
10620     1628        298         154   TVCABLE BOGOTA 
 4323     1624       1085         396   Time Warner Telecom
20115     1590       1540         633   Charter Communications 
 7029     1581        995         230   Windstream Communications Inc

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

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

  ASN   No of nets  Net Savings Description
17974      1949        1918      PT TELEKOMUNIKASI INDONESIA
 1785      1822        1700      PaeTec Communications, Inc.
18566      1913        1675      Covad Communications 
 4766      2508        1554      Korea Telecom (KIX)
 7545      1577        1494      TPG Internet Pty Ltd
10620      1628        1474      TVCABLE BOGOTA 
23456      3177        1468      32-bit ASN transition
 4755      1538        1369      TATA Communications formerly 
22773      1452        1353      Cox Communications, Inc.
 7029      1581        1351      Windstream Communications Inc

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
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
26973   UNALLOCATED  12.39.152.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.154.0/23        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.155.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.159.0/24        7018       AT&T WorldNet Servic
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic

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

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

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
41.222.79.0/24       36938     >>UNKNOWN<<
41.223.92.0/22       36936     >>UNKNOWN<<
46.18.104.0/21       23456     32-bit ASN transition
50.115.0.0/20        40431     Travail Systems, LLC 

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:19       /9:12      /10:27      /11:81      /12:233     
/13:461     /14:796     /15:1410    /16:11946   /17:5944    /18:9965    
/19:19636   /20:26661   /21:26765   /22:35839   /23:34555   /24:192384  
/25:1117    /26:1301    /27:736     /28:165     /29:4       /30:0       
/31:0       /32:5       

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

  ASN   No of nets  Total ann.   Description
 6389     2200          3564      bellsouth.net, inc. 
18566     1868          1913      Covad Communications 
23456     1553          3177      32-bit ASN transition
10620     1523          1628      TVCABLE BOGOTA 
 7029     1280          1581      Windstream Communications Inc
11492     1107          1153      Cable One 
 7011     1057          1182      Citizens Utilities 
 1785     1053          1822      PaeTec Communications, Inc.
22773      942          1452      Cox Communications, Inc.
30036      928           956      Mediacom Communications Corp 

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

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

   1:363       2:51        4:15        5:1         6:3         8:348    
  12:1950     13:1        14:529      15:13       16:3        17:5      
  20:10       23:31       24:1678     27:931      31:518      32:64     
  33:3        34:2        36:4        38:734      40:107      41:2413   
  42:40       44:3        46:1076     47:3        49:229      50:413    
  52:13       54:2        55:3        56:2        57:35       58:873    
  59:491      60:376      61:1172     62:1095     63:1940     64:4007   
  65:2307     66:3927     67:1931     68:1111     69:3129     70:781    
  71:375      72:1857     74:2422     75:328      76:339      77:862    
  78:705      79:452      80:1120     81:840      82:493      83:494    
  84:683      85:1083     86:497      87:860      88:338      89:1532   
  90:231      91:4054     92:524      93:1139     94:1382     95:879    
  96:416      97:271      98:924      99:37      101:203     103:250    
 106:79      107:41      108:75      109:1012    110:662     111:748    
 112:309     113:429     114:565     115:704     116:997     117:681    
 118:884     119:1197    120:334     121:686     122:1618    123:1003   
 124:1343    125:1355    128:248     129:178     130:166     131:579    
 132:119     133:21      134:214     135:53      136:213     137:136    
 138:294     139:116     140:492     141:286     142:389     143:418    
 144:487     145:61      146:464     147:222     148:631     149:250    
 150:152     151:190     152:441     153:179     154:6       155:398    
 156:201     157:354     158:141     159:450     160:319     161:207    
 162:335     163:167     164:512     165:366     166:537     167:433    
 168:748     169:146     170:847     171:84      172:1       173:1646   
 174:615     175:399     176:156     177:244     178:1019    180:1013   
 181:25      182:609     183:243     184:351     185:1       186:1408   
 187:687     188:938     189:878     190:5153    192:5927    193:5001   
 194:3518    195:3050    196:1237    197:144     198:3585    199:4086   
 200:5440    201:1567    202:8525    203:8502    204:4241    205:2329   
 206:2675    207:2832    208:4034    209:3433    210:2712    211:1466   
 212:2084    213:1764    214:776     215:76      216:4854    217:1624   
 218:550     219:344     220:1195    221:515     222:353     223:261    


End of report



From millnert at gmail.com  Fri Sep  2 14:16:56 2011
From: millnert at gmail.com (Martin Millnert)
Date: Fri, 2 Sep 2011 21:16:56 +0200
Subject: Prefix hijacking by Michael Lindsay via Internap
In-Reply-To: <CAL+GGzFd0w-+u+NsF19AU5hUqYuARXqgua0Q+uM9a+ZAB3ia6A@mail.gmail.com>
References: <CAL+GGzE_Vi7nc3ye_Km+U+WZheMaihybtvZLa_89YydrvikQ7w@mail.gmail.com>
 <001001cc5fdc$2ebfd730$8c3f8590$@com>
 <CAAAwwbUwBaPmEdqcP1R3ChTjRTaOQ075v7qCaTSjgiMa_xeJmA@mail.gmail.com>
 <CAL+GGzGcmvW1ZFYXyDK307aj+njhpL9tjvHvo1qBgGuO3a5eQg@mail.gmail.com>
 <CAL+GGzFd0w-+u+NsF19AU5hUqYuARXqgua0Q+uM9a+ZAB3ia6A@mail.gmail.com>
Message-ID: <CAHyNd15n9fWRGKDUP3O7GKsg7YVPksABpFUa+8kR=kWD5pgnPQ@mail.gmail.com>

On Wed, Aug 31, 2011 at 12:56 PM, Denis Spirin <noc at link-telecom.net> wrote:
(snip)
> So, noone is protected from IP network stealing. And noone cares. If
> Internap or it's uplinks was more clever and more insistent - we really had
> a chance to lost our networks forever.

Denis, I think you handled it pretty well from your end.

> I definitely sure we need to found and implement some practice for prevent IP
> hijacking. I dug a lot of things about secure routing, PKI signing and so on -
> there are no working solutions now, as well as will not be in near future.

As has been referred in this thread a few times already, there's been
a long recent discussion on BGPSEC+RPKI in RIPE's address-policy
working group.

Because big red "remove-it" buttons inevitably leads to things like
http://www.guardian.co.uk/world/2011/aug/30/pakistan-bans-encryption-software
:
"Recently the regulator made it impossible for Pakistanis to access
the website of Rolling Stone magazine, after it published an article
on the high proportion of the national budget in Pakistan that goes on
its military."

> But it is possible to negotiate and arrange the formal (administrative) best
> practice for resolving and preventing such issues. Is there any ideas?

I offer: Keep records, talk to people, keep domain names. Network with
people, use GPG (perhaps even put fingerprint on business card?), and
so on.

With the latest incarnation of utter failure of the CA trust
model/design for websites, there seems to be renewed energy into
providing alternative ways to model (distributed) trust.  It looks
like to me that we're moving towards a multi-source based trust system
more and more ( http://perspectives-project.org/ ,
http://convergence.io/ ). I guess something similar will happen with
BGP data (it's suggested to be one of several metrics in convergence),
or they may just end up being pretty much the same system.  *This* is
the general path forward for a robust future Internet...

Best regards,
Martin



From msa at latt.net  Fri Sep  2 15:07:53 2011
From: msa at latt.net (Majdi S. Abbas)
Date: Fri, 2 Sep 2011 13:07:53 -0700
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>
References: <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
 <m27h5r4uki.wl%randy@psg.com>
 <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>
Message-ID: <20110902200753.GB48160@puck.nether.net>

On Fri, Sep 02, 2011 at 10:19:34AM -0500, Jorge Amodio wrote:
> As others said you are doing a "public service" to the rest of the
> community and if you give a nice and valuable talk you will get the
> recognition of the NANOG community and your colleagues, and we can put
> into consideration including a gold star sticker for your service.

	Field observations suggest that presenters are more likely to be
heckled than recognized for said service to the NANOG community. (c:

	As hard as it can be to find good talks for the program, giving
people incentive to take time out of their busy work schedules to prepare
a good talk does not seem unreasonable.

> It will be really unfair for those paying (even if their companies do
> it for them or don't care because they have a mountain of cash) if
> there is a special benefit for some so they don't pay.

	So far the speaker exemption doesn't seem to have been very
contentious unless I've missed something.

	--msa



From cidr-report at potaroo.net  Fri Sep  2 17:00:01 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 2 Sep 2011 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201109022200.p82M01ob042517@wattle.apnic.net>

BGP Update Report
Interval: 25-Aug-11 -to- 01-Sep-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS3292            40954  2.6%      87.0 -- TDC TDC Data Networks
 2 - AS38040           34921  2.2%    3492.1 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 3 - AS9829            19696  1.2%      19.3 -- BSNL-NIB National Internet Backbone
 4 - AS38543           18185  1.1%    4546.2 -- IBM-TH-AS-AP IBM THAILAND NETWORK
 5 - AS6316            17500  1.1%    1166.7 -- AS-PAETEC-NET - PaeTec Communications, Inc.
 6 - AS17974           15047  0.9%      16.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
 7 - AS32528           14994  0.9%    2142.0 -- ABBOTT Abbot Labs
 8 - AS6503            14448  0.9%       7.3 -- Axtel, S.A.B. de C.V.
 9 - AS29381           12851  0.8%     988.5 -- INET-AS Internet Service Provider
10 - AS12993           12825  0.8%     675.0 -- DEAC-AS SIA Digitalas Ekonomikas Attistibas Centrs
11 - AS9498            12204  0.8%     147.0 -- BBIL-AP BHARTI Airtel Ltd.
12 - AS2018            11393  0.7%     148.0 -- TENET-1
13 - AS19262           11302  0.7%       8.0 -- VZGNI-TRANSIT - Verizon Online LLC
14 - AS11664            9838  0.6%      46.2 -- Techtel LMDS Comunicaciones Interactivas S.A.
15 - AS45595            9564  0.6%      22.1 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited
16 - AS7552             9327  0.6%       9.0 -- VIETEL-AS-AP Vietel Corporation
17 - AS14420            8977  0.6%      12.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
18 - AS5800             8770  0.6%      47.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
19 - AS16062            8733  0.6%     873.3 -- Latvijas Tikli Ltd.
20 - AS12252            8310  0.5%      80.7 -- Telmex Peru S.A.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS38543           18185  1.1%    4546.2 -- IBM-TH-AS-AP IBM THAILAND NETWORK
 2 - AS38040           34921  2.2%    3492.1 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 3 - AS3976             3394  0.2%    3394.0 -- ERX-NURI-ASN I.Net Technologies Inc.
 4 - AS32528           14994  0.9%    2142.0 -- ABBOTT Abbot Labs
 5 - AS3454             8042  0.5%    2010.5 -- Universidad Autonoma de Nuevo Leon
 6 - AS39365            5299  0.3%    1324.8 -- MICROLINES-AS MICROLINES ISP
 7 - AS35333            1244  0.1%    1244.0 -- CITYNET-AS SIA CITYNET
 8 - AS34620            1223  0.1%    1223.0 -- MIKRONET_LTD-AS Mikronet SIA
 9 - AS2588             3520  0.2%    1173.3 -- LATNETSERVISS-AS LATNET ISP
10 - AS44483            1171  0.1%    1171.0 -- ELEKTRONS-AS Elektrons-k
11 - AS6316            17500  1.1%    1166.7 -- AS-PAETEC-NET - PaeTec Communications, Inc.
12 - AS34994            4642  0.3%    1160.5 -- LVBP-AS Baltic Pro SIA
13 - AS35484            1155  0.1%    1155.0 -- GNT-LATVIJA-AS GNT Latvija
14 - AS42979            3412  0.2%    1137.3 -- ASGLBLCOM GlobalCom-LV Autonomous System
15 - AS43340            1137  0.1%    1137.0 -- LR_EM Ministry of Economics of Republic of Latvia
16 - AS43188            1133  0.1%    1133.0 -- LDC_AS V/A "Lauksaimniecibas Datu Centrs"
17 - AS48546            1122  0.1%    1122.0 -- LETA_LV SIA LETA AS
18 - AS44698            1109  0.1%    1109.0 -- VPK-AS Chancery of the President of Latvia
19 - AS44105            1104  0.1%    1104.0 -- DROSIBA-AS Datu Drosiba, SIA
20 - AS43615            1028  0.1%    1028.0 -- MONITORINGA_CENTRS_AS SIA Monitoringa Centrs


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 202.92.235.0/24   11656  0.7%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 2 - 200.23.202.0/24    8025  0.5%   AS3454  -- Universidad Autonoma de Nuevo Leon
 3 - 130.36.34.0/24     7489  0.4%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/24     7489  0.4%   AS32528 -- ABBOTT Abbot Labs
 5 - 213.16.48.0/24     6593  0.4%   AS8866  -- BTC-AS Bulgarian Telecommunication Company Plc.
 6 - 66.248.120.0/21    6400  0.4%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 7 - 66.248.104.0/21    6323  0.4%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 8 - 61.90.164.0/24     6319  0.4%   AS38543 -- IBM-TH-AS-AP IBM THAILAND NETWORK
 9 - 58.97.61.0/24      6315  0.4%   AS38543 -- IBM-TH-AS-AP IBM THAILAND NETWORK
10 - 180.180.251.0/24   6055  0.4%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
11 - 180.180.253.0/24   6053  0.4%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
12 - 180.180.248.0/24   6050  0.4%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
13 - 180.180.250.0/24   6050  0.4%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
14 - 180.180.249.0/24   5890  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
15 - 58.137.200.0/24    5540  0.3%   AS38543 -- IBM-TH-AS-AP IBM THAILAND NETWORK
16 - 202.41.70.0/24     5314  0.3%   AS2697  -- ERX-ERNET-AS Education and Research Network
17 - 119.46.89.0/24     4805  0.3%   AS17552 -- TRUE-AS-AP True Corporation Co.,Ltd.
                                     AS7470  -- ASIAINFO-AS-AP ASIA INFONET Co.,Ltd./ TRUE INTERNET Co.,Ltd.
18 - 180.180.255.0/24   4791  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
19 - 66.248.96.0/21     4734  0.3%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
20 - 202.153.174.0/24   3614  0.2%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan

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 cidr-report at potaroo.net  Fri Sep  2 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 2 Sep 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201109022200.p82M00FN042510@wattle.apnic.net>

This report has been generated at Fri Sep  2 21:12:31 2011 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
        26-08-11    372363      219515
        27-08-11    372436      219493
        28-08-11    372391      219336
        29-08-11    372153      219814
        30-08-11    372732      219517
        31-08-11    372442      219383
        01-09-11    371724      219713
        02-09-11    373096      219844


AS Summary
         38765  Number of ASes in routing system
         16349  Number of ASes announcing only one prefix
          3564  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      108360672  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').

 --- 02Sep11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     373662   219871   153791    41.2%   All ASes

AS6389      3564      230     3334    93.5%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4766      2508      973     1535    61.2%   KIXS-AS-KR Korea Telecom
AS18566     1913      379     1534    80.2%   COVAD - Covad Communications
                                               Co.
AS22773     1452      108     1344    92.6%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1536      215     1321    86.0%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS4323      1626      398     1228    75.5%   TWTC - tw telecom holdings,
                                               inc.
AS1785      1825      776     1049    57.5%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS19262     1393      400      993    71.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS10620     1628      688      940    57.7%   Telmex Colombia S.A.
AS28573     1283      344      939    73.2%   NET Servicos de Comunicao S.A.
AS7552       991      165      826    83.4%   VIETEL-AS-AP Vietel
                                               Corporation
AS18101      951      145      806    84.8%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS24560     1195      397      798    66.8%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS8151      1411      653      758    53.7%   Uninet S.A. de C.V.
AS7303      1058      316      742    70.1%   Telecom Argentina S.A.
AS4808      1073      336      737    68.7%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS7545      1577      860      717    45.5%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1107      452      655    59.2%   LEVEL3 Level 3 Communications
AS20115     1591      954      637    40.0%   CHARTER-NET-HKY-NC - Charter
                                               Communications
AS17488     1033      397      636    61.6%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS14420      715       92      623    87.1%   CORPORACION NACIONAL DE
                                               TELECOMUNICACIONES - CNT EP
AS3549      1061      448      613    57.8%   GBLX Global Crossing Ltd.
AS17676      675       70      605    89.6%   GIGAINFRA Softbank BB Corp.
AS22561      967      364      603    62.4%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS4804       659       86      573    86.9%   MPX-AS Microplex PTY LTD
AS17974     1949     1380      569    29.2%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4780       758      199      559    73.7%   SEEDNET Digital United Inc.
AS22047      579       32      547    94.5%   VTR BANDA ANCHA S.A.
AS7011      1183      656      527    44.5%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.
AS26496      526       24      502    95.4%   PAH-INC - GoDaddy.com, Inc.

Total      39787    12537    27250    68.5%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        46.18.104.0/21       AS3.746 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        76.77.32.0/19        AS2828  XO-AS15 - XO Communications
        80.88.10.0/24        AS33774 DJAWEB
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        116.193.152.0/24     AS55536 MIHK-HK Pacswitch Globe Telecom
        116.193.153.0/24     AS55536 MIHK-HK Pacswitch Globe Telecom
        116.193.154.0/24     AS55536 MIHK-HK Pacswitch Globe Telecom
        116.193.155.0/24     AS55536 MIHK-HK Pacswitch Globe Telecom
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        181.82.15.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.16.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.17.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        181.82.18.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        190.102.32.0/20      AS30058 FDCSERVERS - FDCservers.net
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.111.87.0/24      AS24812 
        193.194.102.0/23     AS3.139 
        193.194.104.0/24     AS3.139 
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.76.0/24       AS7195  Telecorp Colombia S.A.
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.9.57.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        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.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.133.73.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        204.69.255.0/24      AS11695 THESTREET-DOT-COM - TheStreet.Com
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.72.192.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.72.194.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        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.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.58.200.0/24      AS18530 ISOMEDIA-1 - Isomedia Inc.
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


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 mysidia at gmail.com  Fri Sep  2 19:27:31 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 2 Sep 2011 19:27:31 -0500
Subject: [Nanog-futures] Admission for Committee Members
In-Reply-To: <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>
References: <062D11F0-C681-4A98-A900-B5C2EB975659@temk.in>
 <CAN6yY1ty+zLHuJ2+EzmDEWYi1CZkehpZJN2Zoyu6O7vWaSMhFw@mail.gmail.com>
 <9D6680FB-9F22-4790-B78A-73047C0A196A@temk.in>
 <0F5A2ED4-020E-457D-A7F9-A156F9FF1674@puck.nether.net>
 <B1BC8895-0D7E-4071-ADB6-AE0CEE819835@temk.in>
 <52246B69-2618-4C56-82DC-50E7A1AF8D56@puck.nether.net>
 <F0830111-6B51-471E-AC44-9DE74B36FD9E@gmail.com>
 <m2y5y83vxp.wl%randy@psg.com>
 <CAFJiuFo0ugECbhB52fvfY0ambKNadZm37BW5+dpXnWZ4Qj6T1w@mail.gmail.com>
 <2EA1A280-C49E-49F4-91A1-4341AE993140@puck.nether.net>
 <CAFJiuFoap42z5jbjm4zGgx=3AmXYqbBm36VtqDOqU_7_VOGZDg@mail.gmail.com>
 <m2hb4v4x9r.wl%randy@psg.com>
 <CAFJiuFojz3Wx3A9=OXbGwyh43xjFzs+dzsygGK7s_-q49TJE5A@mail.gmail.com>
 <m27h5r4uki.wl%randy@psg.com>
 <CAMzo+1ZU6DWSXm98dv8eZhqK1cghWF7rwvuJPSgWoVHoV90TBw@mail.gmail.com>
Message-ID: <CAAAwwbWCajj2uG9wf01UpxCQxGoXQZ92n2=RDt9tQKF0sapxbQ@mail.gmail.com>

On Fri, Sep 2, 2011 at 10:19 AM, Jorge Amodio <jmamodio at gmail.com> wrote:
> admission fee waived or reduced, all the rest MUST pay, even if you
> give a talk or serve in other capacity.
> As others said you are doing a "public service" to the rest of the
> community and if you give a nice and valuable talk you will get the

You know what I would suggest.   Give presenters who committed a sufficient time
in advance an option to have free admission, and an option to pay and donate
their free admission opportunity back.

Whether something is a "public service" or not is a matter of perspective.
Attending and paying admission is presumptively a public service also.
Should one interested in performing one public service be forced to
perform another?

Assume for the sake of argument, it's a more valuable service for a
person to present
than to pay admission,   because if there's noone presenting,  then interest and
attendance fall.

As long as you are not encountering abuses such as 'faux presenters'
just presenting
for admission.

Not all public service is free to the public.  Presumably there must  be some
motivation  for a speaker to present;  sometimes that is altruistic, sometimes
that is not.   If that motivation is free admission,   but for the
community their
service is still valuable, then who am I to argue with that?


One question you could ask... would the person even be there if they were
not giving a presentation?

If they would not, then making them pay to come donate their time sounds
like a proposition that is more adverse to the presenter.

In regards to 'fairness',  waiving admission for a presenter is not unfair, if
any attendee had an equal opportunity  for proposing to present;  those
paying simply did not avail themselves   or perhaps did not have a
meaningful thing to present....

> It will be really unfair for those paying (even if their companies do

--
-JH



From Skeeve at eintellego.net  Sat Sep  3 06:20:13 2011
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Sat, 3 Sep 2011 11:20:13 +0000
Subject: iCloud - Is it going to hurt access providers?
Message-ID: <CA883C31.2D5E0%skeeve@eintellego.net>

Hey all,

I've been thinking about the impact that iCloud (by Apple) will have on the Internet.

My guess is that 99% of consumer internet access is Asymmetrical (DSL, Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts of gigs of music, tv, backups, email, photos, documents/data and so on to their data centres.

Now, don't misunderstand me, I love the concept of iCloud, as I do DropBox, but from an Access Providers perspective, I'm thinking this might be a 'bad thing'.

>From what I can see there are some key issues:

  *   Users with plans that count upload and download together.
  *   The speed of Asymmetric tail technology such as DSL
  *   The design of access provider backhaul (from DSLAM to core) metrics
  *   The design of some transit metrics

So basically the potential issue is that a large residential provider could have thousands of users connect to iCloud, their connections slowed because of uploading data, burning their included bandwidth caps, slowing down the backhaul segment of the network, and as residential providers are mostly download, some purchase transit from their upstreams in an symmetric fashion.

This post is really just to prompt discussion if people think there is anything to actually worry about, or there are other implications that I've not really thought of yet.

?Skeeve

--

Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists

skeeve at eintellego.net<mailto:skeeve at eintellego.net> ; www.eintellego.net

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellego or eintellego at facebook.com<mailto:eintellego at facebook.com>

twitter.com/networkceoau ; www.linkedin.com/in/skeeve

PO Box 7726, Baulkham Hills, NSW 1755 Australia


--

eintellego - The Experts that the Experts call

- Juniper - HP Networking - Cisco - Brocade


From david at davidswafford.com  Sat Sep  3 06:56:17 2011
From: david at davidswafford.com (David Swafford)
Date: Sat, 3 Sep 2011 07:56:17 -0400
Subject: serviceproviderworld.com
In-Reply-To: <03db01cc6913$c0a8ba00$41fa2e00$@org>
References: <03db01cc6913$c0a8ba00$41fa2e00$@org>
Message-ID: <CAA8=vb7ZMC+irbfu6PVFYMOmwNwJeX-_6_gT+JaZ7JppX9YzxQ@mail.gmail.com>

Good concept, here's two points of feedback:

- Given the very early stages of the site, in terms of content, I
would kill off the ads for now.  If you leave it ad-free for a little
while, I think people would be more willing to make use of it
initially.  Leaving the ads in place, it feels like the sites purpose
might soley be for generating traffic to the ads, which hopefully was
not the intent.

- The layout feels very much like the common "free PHP app" format,
I'd look at tweaking the setup a bit and getting away from the
straight-line/box feel if you can.

David.


On Thu, Sep 1, 2011 at 9:58 PM, Paul Stewart <paul at paulstewart.org> wrote:
> Hey folks...
>
>
>
> I know a couple of folks behind this new site and thought it would be
> worthwhile for the NANOG community to be made aware of it.
> http://www.serviceproviderworld.com/
>
>
>
> It's basically going to be a directory of service providers across the world
> - that's the plan as I understand it. ?End-users can visit and review their
> service providers etc.
>
>
>
> Personally, I think this is a great concept - I've seen some online
> directories of providers and most of them are either entirely Canada based
> or US based and in my opinion not that great. ?Please bear in mind that this
> site is literally getting started - there is an email link I ?found at the
> bottom of the site where you can email the group for
> assistance/questions/feedback.
>
>
>
> Just an FYI ...
>
>
>
> Thanks,
>
>
>
> Paul
>
>
>
>



From paul at paulstewart.org  Sat Sep  3 07:07:39 2011
From: paul at paulstewart.org (Paul Stewart)
Date: Sat, 3 Sep 2011 08:07:39 -0400
Subject: serviceproviderworld.com
In-Reply-To: <CAA8=vb7ZMC+irbfu6PVFYMOmwNwJeX-_6_gT+JaZ7JppX9YzxQ@mail.gmail.com>
References: <03db01cc6913$c0a8ba00$41fa2e00$@org>
 <CAA8=vb7ZMC+irbfu6PVFYMOmwNwJeX-_6_gT+JaZ7JppX9YzxQ@mail.gmail.com>
Message-ID: <063d01cc6a32$15855370$408ffa50$@org>

Thanks David...

While I initially really haven't had anything to do with this site other
than opening my big mouth about it recently, it looks like I may become more
involved with it myself ;)

Yes, the advertising - just one small ad.  The reason it was placed there is
because two companies have already stepped up and bought Adwords campaigns
targeting the site specifically.  This is a bit of a marvel wonder per say
consider the site has virtually no traffic yet or content to speak of.  I
think the plan was to hold off with any advertising but then this happened.
I can definitely confirm that it will NOT become an "advertisement bloated
site" for sure.

Regarding layout, nobody involved with the site is by any means a designer -
networks and backends yes, HTML etc. definitely not ;)  Site will undergo a
facelift in coming weeks for sure - please don't let the layout scare you...

Appreciate the feedback,

Paul


-----Original Message-----
From: David Swafford [mailto:david at davidswafford.com] 
Sent: September-03-11 7:56 AM
To: Paul Stewart
Cc: nanog at nanog.org
Subject: Re: serviceproviderworld.com

Good concept, here's two points of feedback:

- Given the very early stages of the site, in terms of content, I
would kill off the ads for now.  If you leave it ad-free for a little
while, I think people would be more willing to make use of it
initially.  Leaving the ads in place, it feels like the sites purpose
might soley be for generating traffic to the ads, which hopefully was
not the intent.

- The layout feels very much like the common "free PHP app" format,
I'd look at tweaking the setup a bit and getting away from the
straight-line/box feel if you can.

David.


On Thu, Sep 1, 2011 at 9:58 PM, Paul Stewart <paul at paulstewart.org> wrote:
> Hey folks...
>
>
>
> I know a couple of folks behind this new site and thought it would be
> worthwhile for the NANOG community to be made aware of it.
> http://www.serviceproviderworld.com/
>
>
>
> It's basically going to be a directory of service providers across the
world
> - that's the plan as I understand it. ?End-users can visit and review
their
> service providers etc.
>
>
>
> Personally, I think this is a great concept - I've seen some online
> directories of providers and most of them are either entirely Canada based
> or US based and in my opinion not that great. ?Please bear in mind that
this
> site is literally getting started - there is an email link I ?found at the
> bottom of the site where you can email the group for
> assistance/questions/feedback.
>
>
>
> Just an FYI ...
>
>
>
> Thanks,
>
>
>
> Paul
>
>
>
>




From alex at corp.nac.net  Sat Sep  3 07:27:16 2011
From: alex at corp.nac.net (Alex Rubenstein)
Date: Sat, 3 Sep 2011 08:27:16 -0400
Subject: iCloud - Is it going to hurt access providers?
Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB808CEDC087E@EXCHMBX.hq.nac.net>

I think is would be short term. The home user is not going to continuously upload data. They will do an initial sync, then incrementals. 

People are doing this today with success. This is not a new thing. 



Sent via Blackberry while presumably driving with one hand

----- Original Message -----
From: Skeeve Stevens <Skeeve at eintellego.net>
To: nanog at nanog.org <nanog at nanog.org>
Sent: Sat Sep 03 07:20:13 2011
Subject: iCloud - Is it going to hurt access providers?

Hey all,

I've been thinking about the impact that iCloud (by Apple) will have on the Internet.

My guess is that 99% of consumer internet access is Asymmetrical (DSL, Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts of gigs of music, tv, backups, email, photos, documents/data and so on to their data centres.

Now, don't misunderstand me, I love the concept of iCloud, as I do DropBox, but from an Access Providers perspective, I'm thinking this might be a 'bad thing'.

From what I can see there are some key issues:

  *   Users with plans that count upload and download together.
  *   The speed of Asymmetric tail technology such as DSL
  *   The design of access provider backhaul (from DSLAM to core) metrics
  *   The design of some transit metrics

So basically the potential issue is that a large residential provider could have thousands of users connect to iCloud, their connections slowed because of uploading data, burning their included bandwidth caps, slowing down the backhaul segment of the network, and as residential providers are mostly download, some purchase transit from their upstreams in an symmetric fashion.

This post is really just to prompt discussion if people think there is anything to actually worry about, or there are other implications that I've not really thought of yet.

?Skeeve

--

Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists

skeeve at eintellego.net<mailto:skeeve at eintellego.net> ; www.eintellego.net

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellego or eintellego at facebook.com<mailto:eintellego at facebook.com>

twitter.com/networkceoau ; www.linkedin.com/in/skeeve

PO Box 7726, Baulkham Hills, NSW 1755 Australia


--

eintellego - The Experts that the Experts call

- Juniper - HP Networking - Cisco - Brocade

From khomyakov.andrey at gmail.com  Sat Sep  3 07:52:37 2011
From: khomyakov.andrey at gmail.com (Andrey Khomyakov)
Date: Sat, 3 Sep 2011 08:52:37 -0400
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CA883C31.2D5E0%skeeve@eintellego.net>
References: <AQHMaity9HUnkNMAMkC4V78M8pfEag==>
 <CA883C31.2D5E0%skeeve@eintellego.net>
Message-ID: <CAB31LOPD3tUMbO03KD+KGBKSPh3QkYrTPRQsFb+513PJ320mdg@mail.gmail.com>

My understanding was that the whole point of iCloud is to not upload but
rather use Apple's stored music files as long as you have them in your
library. You have a valid point however with other similar services, like
amazon's. But that's been out for a while.

--Andrey


On Sat, Sep 3, 2011 at 7:20 AM, Skeeve Stevens <Skeeve at eintellego.net>wrote:

> Hey all,
>
> I've been thinking about the impact that iCloud (by Apple) will have on the
> Internet.
>
> My guess is that 99% of consumer internet access is Asymmetrical (DSL,
> Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts
> of gigs of music, tv, backups, email, photos, documents/data and so on to
> their data centres.
>
> Now, don't misunderstand me, I love the concept of iCloud, as I do DropBox,
> but from an Access Providers perspective, I'm thinking this might be a 'bad
> thing'.
>
> From what I can see there are some key issues:
>
>  *   Users with plans that count upload and download together.
>  *   The speed of Asymmetric tail technology such as DSL
>  *   The design of access provider backhaul (from DSLAM to core) metrics
>  *   The design of some transit metrics
>
> So basically the potential issue is that a large residential provider could
> have thousands of users connect to iCloud, their connections slowed because
> of uploading data, burning their included bandwidth caps, slowing down the
> backhaul segment of the network, and as residential providers are mostly
> download, some purchase transit from their upstreams in an symmetric
> fashion.
>
> This post is really just to prompt discussion if people think there is
> anything to actually worry about, or there are other implications that I've
> not really thought of yet.
>
> ?Skeeve
>
> --
>
> Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists
>
> skeeve at eintellego.net<mailto:skeeve at eintellego.net> ; www.eintellego.net
>
> Phone: 1300 753 383 ; Fax: (+612) 8572 9954
>
> Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/eintellego or eintellego at facebook.com<mailto:
> eintellego at facebook.com>
>
> twitter.com/networkceoau ; www.linkedin.com/in/skeeve
>
> PO Box 7726, Baulkham Hills, NSW 1755 Australia
>
>
> --
>
> eintellego - The Experts that the Experts call
>
> - Juniper - HP Networking - Cisco - Brocade
>


From jared at puck.nether.net  Sat Sep  3 07:55:44 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 3 Sep 2011 08:55:44 -0400
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB808CEDC087E@EXCHMBX.hq.nac.net>
References: <2D0AF14BA6FB334988BC1F5D4FC38CB808CEDC087E@EXCHMBX.hq.nac.net>
Message-ID: <43E719E9-71DD-46E0-B82F-837E7DAF5EE4@puck.nether.net>

I was thinking the same thing. People have been dealing with this for years. File sharing has had the same properties in the access networks for years now. 

Jared Mauch

On Sep 3, 2011, at 8:27 AM, Alex Rubenstein <alex at corp.nac.net> wrote:

> I think is would be short term. The home user is not going to continuously upload data. They will do an initial sync, then incrementals. 
> 
> People are doing this today with success. This is not a new thing.



From jra at baylink.com  Sat Sep  3 09:17:40 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 3 Sep 2011 10:17:40 -0400 (EDT)
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CA883C31.2D5E0%skeeve@eintellego.net>
Message-ID: <31481064.643.1315059460300.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Skeeve Stevens" <Skeeve at eintellego.net>

> I've been thinking about the impact that iCloud (by Apple) will have
> on the Internet.

Aw, c'mon; what a boring Whacky Weekend thread... :-)

> So basically the potential issue is that a large residential provider
> could have thousands of users connect to iCloud, their connections
> slowed because of uploading data, burning their included bandwidth
> caps, slowing down the backhaul segment of the network, and as
> residential providers are mostly download, some purchase transit from
> their upstreams in an symmetric fashion.

IOW: The Tragedy Of The Commons.  Yup; this is definitely going to be fun.

This is, I think, slightly different from the Netflix Instant arguments we
always have: the ones wherein it's pointed out that carriers aren't really 
entitled to charge Netflix because they've made improper bets on their
capacity engineering for What Might Come Next:

Apple really had better have already *known* what the engineering of
consumer grade Internet looked like (or several high level product and
engineering people are dangerously underqualified for their jobs), so
as this problem gets worse, and I concur that it will, the result will be
that they bet wrong.

Gambling means that sometimes you lose.  Alas, the costs won't be on
Apple.

This seems to be an ongoing situation: carriers discovering that they
also bet wrong on how to engineer the network: they've been making the 
beams thinner and thinner, and then along came something reasonably
rational... that was heavy enough to break them.

Anyone betting carriers will stop gambling quite so hard, and build 
networks the way John Roebling built bridges?

Cheers,
-- jr 'first woodpecker that came along...' a
-- 
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      http://photo.imageinc.us             +1 727 647 1274



From Skeeve at eintellego.net  Sat Sep  3 09:24:59 2011
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Sat, 3 Sep 2011 14:24:59 +0000
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CAB31LOPD3tUMbO03KD+KGBKSPh3QkYrTPRQsFb+513PJ320mdg@mail.gmail.com>
Message-ID: <CA884B50.2D62A%skeeve@eintellego.net>

That is only for music? Photos will be the big killer, documents and
iDevice backups as well.

?Skeeve

--
Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net ; www.eintellego.net
Phone: 1300 753 383 ; Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/eintellego or eintellego at facebook.com
twitter.com/networkceoau ; www.linkedin.com/in/skeeve
PO Box 7726, Baulkham Hills, NSW 1755 Australia

--
eintellego - The Experts that the Experts call
- Juniper - HP Networking - Cisco - Brocade







-----Original Message-----
From: Andrey Khomyakov <khomyakov.andrey at gmail.com>
Date: Sat, 3 Sep 2011 08:52:37 -0400
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: iCloud - Is it going to hurt access providers?

>My understanding was that the whole point of iCloud is to not upload but
>rather use Apple's stored music files as long as you have them in your
>library. You have a valid point however with other similar services, like
>amazon's. But that's been out for a while.
>
>--Andrey
>
>
>On Sat, Sep 3, 2011 at 7:20 AM, Skeeve Stevens
><Skeeve at eintellego.net>wrote:
>
>> Hey all,
>>
>> I've been thinking about the impact that iCloud (by Apple) will have on
>>the
>> Internet.
>>
>> My guess is that 99% of consumer internet access is Asymmetrical (DSL,
>> Cable, wireless, etc) and iCloud when launched will 'upload' obscene
>>amounts
>> of gigs of music, tv, backups, email, photos, documents/data and so on
>>to
>> their data centres.
>>
>> Now, don't misunderstand me, I love the concept of iCloud, as I do
>>DropBox,
>> but from an Access Providers perspective, I'm thinking this might be a
>>'bad
>> thing'.
>>
>> From what I can see there are some key issues:
>>
>>  *   Users with plans that count upload and download together.
>>  *   The speed of Asymmetric tail technology such as DSL
>>  *   The design of access provider backhaul (from DSLAM to core) metrics
>>  *   The design of some transit metrics
>>
>> So basically the potential issue is that a large residential provider
>>could
>> have thousands of users connect to iCloud, their connections slowed
>>because
>> of uploading data, burning their included bandwidth caps, slowing down
>>the
>> backhaul segment of the network, and as residential providers are mostly
>> download, some purchase transit from their upstreams in an symmetric
>> fashion.
>>
>> This post is really just to prompt discussion if people think there is
>> anything to actually worry about, or there are other implications that
>>I've
>> not really thought of yet.
>>
>> ?Skeeve
>>
>> --
>>
>> Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists
>>
>> skeeve at eintellego.net<mailto:skeeve at eintellego.net> ; www.eintellego.net
>>
>> Phone: 1300 753 383 ; Fax: (+612) 8572 9954
>>
>> Cell +61 (0)414 753 383 ; skype://skeeve
>>
>> facebook.com/eintellego or eintellego at facebook.com<mailto:
>> eintellego at facebook.com>
>>
>> twitter.com/networkceoau ; www.linkedin.com/in/skeeve
>>
>> PO Box 7726, Baulkham Hills, NSW 1755 Australia
>>
>>
>> --
>>
>> eintellego - The Experts that the Experts call
>>
>> - Juniper - HP Networking - Cisco - Brocade
>>




From Skeeve at eintellego.net  Sat Sep  3 09:26:17 2011
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Sat, 3 Sep 2011 14:26:17 +0000
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <43E719E9-71DD-46E0-B82F-837E7DAF5EE4@puck.nether.net>
Message-ID: <CA884BB9.2D62E%skeeve@eintellego.net>

I'm not saying that people haven't being doing it? Dropbox is an example?
but you add millions of iPads, iPhones, iPod Touches and OSX Lion's out
there and that means a hell of a lot of new traffic.

?Skeeve

--
Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net ; www.eintellego.net
Phone: 1300 753 383 ; Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/eintellego or eintellego at facebook.com
twitter.com/networkceoau ; www.linkedin.com/in/skeeve
PO Box 7726, Baulkham Hills, NSW 1755 Australia

--
eintellego - The Experts that the Experts call
- Juniper - HP Networking - Cisco - Brocade







-----Original Message-----
From: Jared Mauch <jared at puck.nether.net>
Date: Sat, 3 Sep 2011 08:55:44 -0400
To: Alex Rubenstein <alex at corp.nac.net>
Cc: Skeeve Stevens <skeeve at eintellego.net>, "nanog at nanog.org"
<nanog at nanog.org>
Subject: Re: iCloud - Is it going to hurt access providers?

>I was thinking the same thing. People have been dealing with this for
>years. File sharing has had the same properties in the access networks
>for years now. 
>
>Jared Mauch
>
>On Sep 3, 2011, at 8:27 AM, Alex Rubenstein <alex at corp.nac.net> wrote:
>
>> I think is would be short term. The home user is not going to
>>continuously upload data. They will do an initial sync, then
>>incrementals. 
>> 
>> People are doing this today with success. This is not a new thing.




From jra at baylink.com  Sat Sep  3 09:35:22 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 3 Sep 2011 10:35:22 -0400 (EDT)
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CA884BB9.2D62E%skeeve@eintellego.net>
Message-ID: <11154734.649.1315060522973.JavaMail.root@benjamin.baylink.com>

> I'm not saying that people haven't being doing it? Dropbox is an example?
> but you add millions of iPads, iPhones, iPod Touches and OSX Lion's out
> there and that means a hell of a lot of new traffic.

Especially when you're at the end of a small hose.  Comparatively.

What's Oz's aggregate bandwidth to the US?

Will Apple be hosting on-continent?

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      http://photo.imageinc.us             +1 727 647 1274



From Valdis.Kletnieks at vt.edu  Sat Sep  3 09:38:08 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 03 Sep 2011 10:38:08 -0400
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: Your message of "Sat, 03 Sep 2011 11:20:13 -0000."
 <CA883C31.2D5E0%skeeve@eintellego.net>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
Message-ID: <15488.1315060688@turing-police.cc.vt.edu>

On Sat, 03 Sep 2011 11:20:13 -0000, Skeeve Stevens said:

> My guess is that 99% of consumer internet access is Asymmetrical (DSL, Cable,
> wireless, etc) and iCloud when launched will 'upload' obscene amounts of
> gigs of music, tv, backups, email, photos, documents/data and so on to their
> idata centres.

This is probably not goind to be any harder on your network that BitTorrent
and friends.

> From what I can see there are some key issues:

You missed the *really* key issue.

The more people store data in the cloud, the more irate people are going to be
calling your help desk if you have an outage.  We've already seen a few news
stories where a cloud service has whoopsied and lost data.

(And yes, I know that technically, the fact that Joe Sixpack made a poor choice
of backup/storage strategies doesn't impose added duties on you.  But your help
desk is going to have a hard time explaining that to a pissed-off Joe)

Am I the only one who thinks iCloud style services plus a Cogent peering
dispute is a likely "perfect storm" scenario? ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110903/9044cc85/attachment.bin>

From mansaxel at besserwisser.org  Sat Sep  3 10:03:52 2011
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Sat, 3 Sep 2011 17:03:52 +0200
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <31481064.643.1315059460300.JavaMail.root@benjamin.baylink.com>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
 <31481064.643.1315059460300.JavaMail.root@benjamin.baylink.com>
Message-ID: <20110903150351.GN24663@besserwisser.org>

Subject: Re: iCloud - Is it going to hurt access providers? Date: Sat, Sep 03, 2011 at 10:17:40AM -0400 Quoting Jay Ashworth (jra at baylink.com):
> Gambling means that sometimes you lose.  Alas, the costs won't be on
> Apple.
> 
> This seems to be an ongoing situation: carriers discovering that they
> also bet wrong on how to engineer the network: they've been making the 
> beams thinner and thinner, and then along came something reasonably
> rational... that was heavy enough to break them.
> 
> Anyone betting carriers will stop gambling quite so hard, and build 
> networks the way John Roebling built bridges?

Well put. 

I find it hard to blame the users for using the network. That is what
they pay the provider for. Any implicit assumptions about _how_ users
should use the network are simply corners cut to make things cheaper. 

Gambling. 

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
JAPAN is a WONDERFUL planet -- I wonder if we'll ever reach their level
of COMPARATIVE SHOPPING ...
-------------- 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/20110903/f8f0d5e9/attachment.bin>

From neil at domino.org  Sat Sep  3 10:32:49 2011
From: neil at domino.org (Neil J. McRae)
Date: Sat, 3 Sep 2011 15:32:49 +0000
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CA883C31.2D5E0%skeeve@eintellego.net>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
Message-ID: <C51CD6E6-7B83-4EAB-B05D-8B43DCB81A76@domino.org>

I think the effect will be limited unless Apple give alot more space away for free. there arny many iphones/pads/pods with just 5GB

Neil

On 3 Sep 2011, at 12:22, "Skeeve Stevens" <Skeeve at eintellego.net> wrote:

> Hey all,
> 
> I've been thinking about the impact that iCloud (by Apple) will have on the Internet.
> 
> My guess is that 99% of consumer internet access is Asymmetrical (DSL, Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts of gigs of music, tv, backups, email, photos, documents/data and so on to their data centres.
> 
> Now, don't misunderstand me, I love the concept of iCloud, as I do DropBox, but from an Access Providers perspective, I'm thinking this might be a 'bad thing'.
> 
> From what I can see there are some key issues:
> 
>  *   Users with plans that count upload and download together.
>  *   The speed of Asymmetric tail technology such as DSL
>  *   The design of access provider backhaul (from DSLAM to core) metrics
>  *   The design of some transit metrics
> 
> So basically the potential issue is that a large residential provider could have thousands of users connect to iCloud, their connections slowed because of uploading data, burning their included bandwidth caps, slowing down the backhaul segment of the network, and as residential providers are mostly download, some purchase transit from their upstreams in an symmetric fashion.
> 
> This post is really just to prompt discussion if people think there is anything to actually worry about, or there are other implications that I've not really thought of yet.
> 
> ?Skeeve
> 
> --
> 
> Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists
> 
> skeeve at eintellego.net<mailto:skeeve at eintellego.net> ; www.eintellego.net
> 
> Phone: 1300 753 383 ; Fax: (+612) 8572 9954
> 
> Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellego or eintellego at facebook.com<mailto:eintellego at facebook.com>
> 
> twitter.com/networkceoau ; www.linkedin.com/in/skeeve
> 
> PO Box 7726, Baulkham Hills, NSW 1755 Australia
> 
> 
> --
> 
> eintellego - The Experts that the Experts call
> 
> - Juniper - HP Networking - Cisco - Brocade
> 




From don at sandvine.com  Sat Sep  3 12:45:55 2011
From: don at sandvine.com (Don Bowman)
Date: Sat, 3 Sep 2011 17:45:55 +0000
Subject: ISP Two-Way Utilization Studies between Subscriber and Network
In-Reply-To: <4E610F80.4010708@cisco.com>
References: <4E610F80.4010708@cisco.com>
Message-ID: <C7579F0BB38EC444912308442F7E195A0FAE00@wtl-exch-1.sandvine.com>

From: Paul Donner [mailto:pdonner at cisco.com]

>Can anyone point me to useful recent studies showing the ratio of

>downstream to upstream traffic loading for a typical home Internet user?

>

>Broken out by traffic type would be really nice but not holding my breath.

>

>Thanks,

>

>-Donner





Sandvine has this on our web site, http://www.sandvine.com/news/global_broadband_trends.asp



It is broken out by application, access technology, and geography, and includes

peak-time only (as below, top-apps only). This is for home Internet use only.



Let me know if you need information from the raw data.



[img.jpg]



--don
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 46540 bytes
Desc: image002.jpg
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110903/b6c1365e/attachment.jpg>

From mysidia at gmail.com  Sat Sep  3 12:49:20 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 3 Sep 2011 12:49:20 -0500
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CA883C31.2D5E0%skeeve@eintellego.net>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
Message-ID: <CAAAwwbWGYFBw5T37WctmUxzyF5U9BUZ-B-G8gYzfnOahuC-Phg@mail.gmail.com>

On Sat, Sep 3, 2011 at 6:20 AM, Skeeve Stevens <Skeeve at eintellego.net> wrote:

> My guess is that 99% of consumer internet access is Asymmetrical (DSL, Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts of gigs of music, tv, backups, email, photos, documents/data and so on to their data centres.

What would be obscene about that is from a design POV it would be a
waste of resources.
"Music"  and "TV"    content are from a small number of sources, and
there are a massive potential number of users.

What should happen is instead of transmitting  large video files...
block checksums should be transmitted,
and only files that are completely foreign should be transferred.

Whereas everything else being "backed up"  is just an assignment of
account access to existing blocks  that would
already have been stored on the  content servers.

And then also,   a user storing  10GB of music  would probably take
only a  few megabytes of  their account space,
once the "space used"  is evenly  divided by the number of users that
have that block saved,

since a majority of music files backed up would be file-identical
with  material  someone else had already backed up,
and identical to material  already in  the iTunes store  (which they
could pre-seed their database with).


--
-JH



From seth.mos at dds.nl  Sat Sep  3 13:06:05 2011
From: seth.mos at dds.nl (Seth Mos)
Date: Sat, 3 Sep 2011 20:06:05 +0200
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CAAAwwbWGYFBw5T37WctmUxzyF5U9BUZ-B-G8gYzfnOahuC-Phg@mail.gmail.com>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
 <CAAAwwbWGYFBw5T37WctmUxzyF5U9BUZ-B-G8gYzfnOahuC-Phg@mail.gmail.com>
Message-ID: <2E935D4D-93A8-42BD-A7D3-3DCDADA6EE33@dds.nl>


Op 3 sep 2011, om 19:49 heeft Jimmy Hess het volgende geschreven:

> On Sat, Sep 3, 2011 at 6:20 AM, Skeeve Stevens <Skeeve at eintellego.net> wrote:
> 
>> My guess is that 99% of consumer internet access is Asymmetrical (DSL, Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts of gigs of music, tv, backups, email, photos, documents/data and so on to their data centres.
> 

> since a majority of music files backed up would be file-identical
> with  material  someone else had already backed up,
> and identical to material  already in  the iTunes store  (which they
> could pre-seed their database with).

How would storage vendors otherwise sell de duplication. I mean you could make the application smarter but that wouldn't sell more spinning rust or licenses.

Regards,

Seth


From web at typo.org  Sat Sep  3 14:57:46 2011
From: web at typo.org (Wayne E Bouchard)
Date: Sat, 3 Sep 2011 12:57:46 -0700
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CA883C31.2D5E0%skeeve@eintellego.net>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
Message-ID: <20110903195746.GA83947@typo.org>

If you're worried about the problem of tens of thousands of users
simultaneously trying to upload files to a "central point" then I'm
not the slightest bit concerned about the network as a whole. In this
circumstance, one of two things will happen and possibly both,
depending: either a) the users will screw themselves by flooding their
uplinks in which case they will know what they've done to themselves
and will largely accept the problems for the durration or b) (and far
more likely) the links apple is using will become flooded or the
systems overloaded in some way or another in which case the customers
will say, "MAN, this *SUCKS*" and likely whine at apple. Because the
nature of the traffic isn't much different than, say, a windows patch
release, the traffic won't be *all of a sudden* but will be spread out
over hours and days. The probability of it causing disruptions
anywhere but at the immediate source or within the near vicinity of
the desination is low, as I see it. IMO, the only ones who really need
be concerned are Apple's bandwidth prodivers because traffic will be
concentrating within their networks and especially in the nodes apple
connects to.

-Wayne

On Sat, Sep 03, 2011 at 11:20:13AM +0000, Skeeve Stevens wrote:
> Hey all,
> 
> I've been thinking about the impact that iCloud (by Apple) will have on the Internet.
> 
> My guess is that 99% of consumer internet access is Asymmetrical (DSL, Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts of gigs of music, tv, backups, email, photos, documents/data and so on to their data centres.
> 
> Now, don't misunderstand me, I love the concept of iCloud, as I do DropBox, but from an Access Providers perspective, I'm thinking this might be a 'bad thing'.
> 
> >From what I can see there are some key issues:
> 
>   *   Users with plans that count upload and download together.
>   *   The speed of Asymmetric tail technology such as DSL
>   *   The design of access provider backhaul (from DSLAM to core) metrics
>   *   The design of some transit metrics
> 
> So basically the potential issue is that a large residential provider could have thousands of users connect to iCloud, their connections slowed because of uploading data, burning their included bandwidth caps, slowing down the backhaul segment of the network, and as residential providers are mostly download, some purchase transit from their upstreams in an symmetric fashion.
> 
> This post is really just to prompt discussion if people think there is anything to actually worry about, or there are other implications that I've not really thought of yet.
> 
> ?Skeeve
> 
> --
> 
> Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists
> 
> skeeve at eintellego.net<mailto:skeeve at eintellego.net> ; www.eintellego.net
> 
> Phone: 1300 753 383 ; Fax: (+612) 8572 9954
> 
> Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellego or eintellego at facebook.com<mailto:eintellego at facebook.com>
> 
> twitter.com/networkceoau ; www.linkedin.com/in/skeeve
> 
> PO Box 7726, Baulkham Hills, NSW 1755 Australia
> 
> 
> --
> 
> eintellego - The Experts that the Experts call
> 
> - Juniper - HP Networking - Cisco - Brocade

---
Wayne Bouchard
web at typo.org
Network Dude
http://www.typo.org/~web/



From jra at baylink.com  Sat Sep  3 16:02:31 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 3 Sep 2011 17:02:31 -0400 (EDT)
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <20110903195746.GA83947@typo.org>
Message-ID: <9319944.685.1315083751735.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Wayne E Bouchard" <web at typo.org>

> and will largely accept the problems for the durration or b) (and far
> more likely) the links apple is using will become flooded or the
> systems overloaded in some way or another in which case the customers
> will say, "MAN, this *SUCKS*" and likely whine at apple.

If you think that call traffic's going to *Apple*, either you're an optimist,
or I'm nutsabago.

Cheers,
-- jr 'shut *up*' a
-- 
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      http://photo.imageinc.us             +1 727 647 1274



From jared at puck.nether.net  Sat Sep  3 17:08:50 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 3 Sep 2011 18:08:50 -0400
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <9319944.685.1315083751735.JavaMail.root@benjamin.baylink.com>
References: <9319944.685.1315083751735.JavaMail.root@benjamin.baylink.com>
Message-ID: <310A5FD6-80E3-405E-8EB5-1C2C924CEB63@puck.nether.net>


On Sep 3, 2011, at 5:02 PM, Jay Ashworth wrote:

> ----- Original Message -----
>> From: "Wayne E Bouchard" <web at typo.org>
> 
>> and will largely accept the problems for the durration or b) (and far
>> more likely) the links apple is using will become flooded or the
>> systems overloaded in some way or another in which case the customers
>> will say, "MAN, this *SUCKS*" and likely whine at apple.
> 
> If you think that call traffic's going to *Apple*, either you're an optimist,
> or I'm nutsabago.


The current apple "media" is reporting it's likely going to amazon and microsoft azure.

I've not bothered to look too deeply at dns and packet traces myself.

I'm guessing that all these things are going to hurt the DSL providers more than the docsis/fttx/pon based providers.  Those folks have broader capabilities by pushing updated configs to the devices.  The DSL based providers are more limited in my experience and likely to see a poorer ratio of up:down.  SDSL was just not common enough, so most A/VDSL based providers have something like 15:1.5 whereas comcast (for example) has 22:5.  I've seen the 22:5 service burst (or should that be buffer/manage the queue) to around 80Mb/s down in some cases.

This is something you are unlikely to see from a DSL provider unless the equipment is in-building.

- Jared


From sethm at rollernet.us  Sat Sep  3 17:25:45 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Sat, 03 Sep 2011 15:25:45 -0700
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <9319944.685.1315083751735.JavaMail.root@benjamin.baylink.com>
References: <9319944.685.1315083751735.JavaMail.root@benjamin.baylink.com>
Message-ID: <4E62A969.8080001@rollernet.us>

On 9/3/11 2:02 PM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Wayne E Bouchard" <web at typo.org>
> 
>> and will largely accept the problems for the durration or b) (and far
>> more likely) the links apple is using will become flooded or the
>> systems overloaded in some way or another in which case the customers
>> will say, "MAN, this *SUCKS*" and likely whine at apple.
> 
> If you think that call traffic's going to *Apple*, either you're an optimist,
> or I'm nutsabago.


Well, Apple is building giant mysterious data centers for something.

http://tech.fortune.cnn.com/2011/06/01/apples-new-data-center-is-visible-at-last-from-space/

~Seth



From mohacsi at niif.hu  Sat Sep  3 17:07:19 2011
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Sun, 4 Sep 2011 00:07:19 +0200 (CEST)
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CA883C31.2D5E0%skeeve@eintellego.net>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
Message-ID: <alpine.BSF.2.00.1109032357190.50673@mignon.ki.iif.hu>




On Sat, 3 Sep 2011, Skeeve Stevens wrote:

> Hey all,
>
> I've been thinking about the impact that iCloud (by Apple) will have on 
> the Internet.
>
> My guess is that 99% of consumer internet access is Asymmetrical (DSL, 
> Cable, wireless, etc) and iCloud when launched will 'upload' obscene 
> amounts of gigs of music, tv, backups, email, photos, documents/data and 
> so on to their data centres.
>
> Now, don't misunderstand me, I love the concept of iCloud, as I do 
> DropBox, but from an Access Providers perspective, I'm thinking this 
> might be a 'bad thing'.
>
> From what I can see there are some key issues:
>
>  *   Users with plans that count upload and download together.
>  *   The speed of Asymmetric tail technology such as DSL
>  *   The design of access provider backhaul (from DSLAM to core) metrics
>  *   The design of some transit metrics
>
> So basically the potential issue is that a large residential provider 
> could have thousands of users connect to iCloud, their connections 
> slowed because of uploading data, burning their included bandwidth caps, 
> slowing down the backhaul segment of the network, and as residential 
> providers are mostly download, some purchase transit from their 
> upstreams in an symmetric fashion.


In my opinion. Home networking (including personal clouds) have to change 
the brain damaged model of asymmetric tail technologies. Giving back the 
original peer-to-peer nature of networking the asymmetricity of the 
access technologies will not be tolerable in such a level (1:10) we have 
today. Maybe 1:2 should be more acceptable.

You don't have to worry bout this changes, but access provider cannot 
claim any longer 100MBps (while upload speed ~10 Mbps), but probably 60-70
Mbps (with upload ~ 30 Mbps).... They have to retune access services.


Best Regards,

 		Janos




From jra at baylink.com  Sat Sep  3 17:38:40 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 3 Sep 2011 18:38:40 -0400 (EDT)
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <4E62A969.8080001@rollernet.us>
Message-ID: <17832021.697.1315089520586.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Seth Mattinen" <sethm at rollernet.us>

> On 9/3/11 2:02 PM, Jay Ashworth wrote:
> > ----- Original Message -----
> >> From: "Wayne E Bouchard" <web at typo.org>
> >
> >> and will largely accept the problems for the durration or b) (and
> >> far
> >> more likely) the links apple is using will become flooded or the
> >> systems overloaded in some way or another in which case the
> >> customers
> >> will say, "MAN, this *SUCKS*" and likely whine at apple.
> >
> > If you think that call traffic's going to *Apple*, either you're an
> > optimist,
> > or I'm nutsabago.
> 
> Well, Apple is building giant mysterious data centers for something.
> 
> http://tech.fortune.cnn.com/2011/06/01/apples-new-data-center-is-visible-at-last-from-space/

Two people making the same mistake: end-user support telephone calls don't 
generally go to datacenters, do they? 

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      http://photo.imageinc.us             +1 727 647 1274



From mike at mtcc.com  Sat Sep  3 18:06:20 2011
From: mike at mtcc.com (Michael Thomas)
Date: Sat, 03 Sep 2011 16:06:20 -0700
Subject: static asymmetry
In-Reply-To: <alpine.BSF.2.00.1109032357190.50673@mignon.ki.iif.hu>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
 <alpine.BSF.2.00.1109032357190.50673@mignon.ki.iif.hu>
Message-ID: <4E62B2EC.80501@mtcc.com>

Mohacsi Janos wrote:
> In my opinion. Home networking (including personal clouds) have to 
> change the brain damaged model of asymmetric tail technologies. Giving 
> back the original peer-to-peer nature of networking the asymmetricity of 
> the access technologies will not be tolerable in such a level (1:10) we 
> have today. Maybe 1:2 should be more acceptable.

I think a more fundamental question is why in 2011 we're stuck with statically
shaped asymmetric up and down. You can pretty dynamically shape *within* a given
direction to do just about anything you want to the traffic, but I don't know of
last mile access technologies that do that *across* the up and downstream. If it
were more like ethernet that doesn't have those artificial distinctions, this
conversation would be moot.

I recall the reason that DOCSIS is asymmetric is had a lot to do with how they
carved out spectrum of the analog channels -- and relegating upstream to slots
that weren't very good for those analog channels. That's been about 15 years
ago though and in the mean time the internet has sort of become important.

Now things may have changed -- I'd love to hear about it. Maybe Fred or
John Chapman can comment.

Mike



From if at xip.at  Sat Sep  3 18:32:42 2011
From: if at xip.at (Ingo Flaschberger)
Date: Sun, 4 Sep 2011 01:32:42 +0200 (CEST)
Subject: static asymmetry
In-Reply-To: <4E62B2EC.80501@mtcc.com>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
 <alpine.BSF.2.00.1109032357190.50673@mignon.ki.iif.hu>
 <4E62B2EC.80501@mtcc.com>
Message-ID: <alpine.LRH.2.00.1109040118290.1054@filebunker.xip.at>

>> In my opinion. Home networking (including personal clouds) have to change 
>> the brain damaged model of asymmetric tail technologies. Giving back the 
>> original peer-to-peer nature of networking the asymmetricity of the access 
>> technologies will not be tolerable in such a level (1:10) we have today. 
>> Maybe 1:2 should be more acceptable.
>
> I think a more fundamental question is why in 2011 we're stuck with 
> statically
> shaped asymmetric up and down. You can pretty dynamically shape *within* a 
> given
> direction to do just about anything you want to the traffic, but I don't know 
> of
> last mile access technologies that do that *across* the up and downstream. If 
> it
> were more like ethernet that doesn't have those artificial distinctions, this
> conversation would be moot.
>
> I recall the reason that DOCSIS is asymmetric is had a lot to do with how 
> they
> carved out spectrum of the analog channels -- and relegating upstream to 
> slots
> that weren't very good for those analog channels. That's been about 15 years
> ago though and in the mean time the internet has sort of become important.

With dsl technologies like vdsl (flexible) or adsl (fixed 1/8 or 1/24) the 
total bandwidth (up+down) is not linear.

example:
adsl: 1mbit up, 24mbit down - total 25mbit
 	can not be used with 12.5mbit up/down.

at the co the noise is very high, as there are many lines in a bundle and 
the dslams "cry" with high signal levels into the lines.
Also the crosstalk is high.

downstream:
 	co-side: dslams send signal with high level + high level noise.
 	cpe-side: signal arrives damped, noise arrives damped -> signal to
 		noise (snr) is acceptable.
 	high bandwiths can be achieved.
upstream:
 	cpe-side: cpe send signal with high level, low level noise
 	co-side: high level noise produce crosstalk to damped signal
 		that arrives from cpe -> signal to noise (snr) is low
 	only low bandwiths can be achieved.

so dsl technologies, that use old, unshielded cables operate now at the 
maximum what the cable can do (up to 30MHz with vdsl2).
Higher speeds can only be achieved with better cables; like fiber or coax.

coax technologies use in oposite to dsl technologies no point to point 
links but bus technology to connect several customers to one head-end.
asymmetric bandwith -> more clients per head-end.

high-speed symmetric services can only be offered with new network types 
like fiber.

Kind regards,
 	Ingo Flaschberger





From phil.pierotti at gmail.com  Sat Sep  3 19:20:35 2011
From: phil.pierotti at gmail.com (Phil Pierotti)
Date: Sun, 4 Sep 2011 10:20:35 +1000
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CAAAwwbWGYFBw5T37WctmUxzyF5U9BUZ-B-G8gYzfnOahuC-Phg@mail.gmail.com>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
 <CAAAwwbWGYFBw5T37WctmUxzyF5U9BUZ-B-G8gYzfnOahuC-Phg@mail.gmail.com>
Message-ID: <CANUcKMDS+rA+3N-mbHJAq7Aoiv1Tvzvadi2Q_jdGuVGi+YTSxw@mail.gmail.com>

I'm not 100% certain and have no references to back it up but I recall
reading an article which described the Apple cloud music strategy as being
one where for existing identified music it merely stores a reference of some
kind against your account rather than actually storing an additional copy.
Presumably for the sake of sanity it would be implemented in the application
where it saves the end user the cost/time of uploading as well, if for no
other reason that said cost/time/cpu resource would also be a real cost to
Apple directly or indirectly.

Mumble-something about "even for your own music you have
ripped-not-purchased, pay $nominal-annual-fee and it magically becomes a
legal licensed object" (which obviously they did because then it becomes
something they have one single stored copy of with references on remote
accounts).

Phil P

On Sun, Sep 4, 2011 at 3:49 AM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Sat, Sep 3, 2011 at 6:20 AM, Skeeve Stevens <Skeeve at eintellego.net>
> wrote:
>
> > My guess is that 99% of consumer internet access is Asymmetrical (DSL,
> Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts
> of gigs of music, tv, backups, email, photos, documents/data and so on to
> their data centres.
>
> What would be obscene about that is from a design POV it would be a
> waste of resources.
> "Music"  and "TV"    content are from a small number of sources, and
> there are a massive potential number of users.
>
> What should happen is instead of transmitting  large video files...
> block checksums should be transmitted,
> and only files that are completely foreign should be transferred.
>
> Whereas everything else being "backed up"  is just an assignment of
> account access to existing blocks  that would
> already have been stored on the  content servers.
>
> And then also,   a user storing  10GB of music  would probably take
> only a  few megabytes of  their account space,
> once the "space used"  is evenly  divided by the number of users that
> have that block saved,
>
> since a majority of music files backed up would be file-identical
> with  material  someone else had already backed up,
> and identical to material  already in  the iTunes store  (which they
> could pre-seed their database with).
>
>
> --
> -JH
>
>


-- 
>>>> two eyes to tease, an aargh ... an oh there's a pie in there somewhere
<<<<<


From frnkblk at iname.com  Sat Sep  3 20:15:28 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Sat, 3 Sep 2011 20:15:28 -0500
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <alpine.BSF.2.00.1109032357190.50673@mignon.ki.iif.hu>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
 <alpine.BSF.2.00.1109032357190.50673@mignon.ki.iif.hu>
Message-ID: <004001cc6aa0$221efeb0$665cfc10$@iname.com>

The copper technologies of DOCSIS and xDSL are well established in
residential deployments and they are asymmetric by design.  I don't think
near-symmetric speeds are on the CableLab's and Broadband Forum's short list
of future features.  Even GPON is 1:4.  As more fiber is deployed, I believe
deployments will eventually migrate to some variation of EPON where
symmetricity is built into the design.  In the meantime it is what it is.

Somewhat tangential, has anyone graphed out the upstream/downstream ratios
of the various technologies (various generations of dial-up, DSL, fiber,
etc)?

Frank

-----Original Message-----
From: Mohacsi Janos [mailto:mohacsi at niif.hu] 
Sent: Saturday, September 03, 2011 5:07 PM
To: Skeeve Stevens
Cc: nanog at nanog.org
Subject: Re: iCloud - Is it going to hurt access providers?

<snip>

In my opinion. Home networking (including personal clouds) have to change 
the brain damaged model of asymmetric tail technologies. Giving back the 
original peer-to-peer nature of networking the asymmetricity of the 
access technologies will not be tolerable in such a level (1:10) we have 
today. Maybe 1:2 should be more acceptable.

You don't have to worry bout this changes, but access provider cannot 
claim any longer 100MBps (while upload speed ~10 Mbps), but probably 60-70
Mbps (with upload ~ 30 Mbps).... They have to retune access services.


Best Regards,

 		Janos




From frnkblk at iname.com  Sat Sep  3 20:18:11 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Sat, 3 Sep 2011 20:18:11 -0500
Subject: static asymmetry
In-Reply-To: <4E62B2EC.80501@mtcc.com>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
 <alpine.BSF.2.00.1109032357190.50673@mignon.ki.iif.hu>
 <4E62B2EC.80501@mtcc.com>
Message-ID: <004101cc6aa0$8347bc90$89d735b0$@iname.com>

Here's a very timely article on the topic of DOCSIS upstream:
http://accessintelligence.imirus.com/Mpowered/book/vcomm11/i8/p18

Frank

-----Original Message-----
From: Michael Thomas [mailto:mike at mtcc.com] 
Sent: Saturday, September 03, 2011 6:06 PM
To: Mohacsi Janos
Cc: nanog at nanog.org
Subject: static asymmetry

Mohacsi Janos wrote:
> In my opinion. Home networking (including personal clouds) have to 
> change the brain damaged model of asymmetric tail technologies. Giving 
> back the original peer-to-peer nature of networking the asymmetricity of 
> the access technologies will not be tolerable in such a level (1:10) we 
> have today. Maybe 1:2 should be more acceptable.

I think a more fundamental question is why in 2011 we're stuck with
statically
shaped asymmetric up and down. You can pretty dynamically shape *within* a
given
direction to do just about anything you want to the traffic, but I don't
know of
last mile access technologies that do that *across* the up and downstream.
If it
were more like ethernet that doesn't have those artificial distinctions,
this
conversation would be moot.

I recall the reason that DOCSIS is asymmetric is had a lot to do with how
they
carved out spectrum of the analog channels -- and relegating upstream to
slots
that weren't very good for those analog channels. That's been about 15 years
ago though and in the mean time the internet has sort of become important.

Now things may have changed -- I'd love to hear about it. Maybe Fred or
John Chapman can comment.

Mike





From jra at baylink.com  Sat Sep  3 20:27:42 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 3 Sep 2011 21:27:42 -0400 (EDT)
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <004001cc6aa0$221efeb0$665cfc10$@iname.com>
Message-ID: <33101840.709.1315099662101.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Frank Bulk" <frnkblk at iname.com>

> Subject: RE: iCloud - Is it going to hurt access providers?
> The copper technologies of DOCSIS and xDSL are well established in
> residential deployments and they are asymmetric by design. I don't think
> near-symmetric speeds are on the CableLab's and Broadband Forum's short list
> of future features. Even GPON is 1:4. As more fiber is deployed, I believe
> deployments will eventually migrate to some variation of EPON where
> symmetricity is built into the design. In the meantime it is what it
> is.

That's as may be... but the real question, I think, is this:

What's the asymmetry of the *intermediate* networks?  It wouldn't make sense
for cablemodem providers to provision symmetric transport inside their MANs
if they didn't have to... so if they *don't* have to, how hard can the push it
with the way they're provisioned now?

Or is the transport natively symmetric, as I suspect, and they're just 
letting it all sit there on the return side.  Must gall their sisters... :-)

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      http://photo.imageinc.us             +1 727 647 1274



From joe at nethead.com  Sat Sep  3 22:28:57 2011
From: joe at nethead.com (Joe Hamelin)
Date: Sat, 3 Sep 2011 20:28:57 -0700
Subject: Tampa small colo recs?
In-Reply-To: <24261253.402.1314924618891.JavaMail.root@benjamin.baylink.com>
References: <8701686.400.1314924577802.JavaMail.root@benjamin.baylink.com>
 <24261253.402.1314924618891.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAO0-hXbj5MFTqaBo4=2HTszT3vLKTmy30o4TfauaEx7N6B-WUA@mail.gmail.com>

The switch & data (or whatever they are called now, Equinox or something)
space is nice, good manager.  You'd have to go for a whole rack or cage
though.  You'd have wikipedia as a neighbor too.  I put 40+ racks in there
for Clearwire.  They are in the building with the big lizard on the side
downtown Tampa, 10th floor if I recall.
--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474


On Thu, Sep 1, 2011 at 5:50 PM, Jay Ashworth <jra at baylink.com> wrote:

> Anyone got any opinions on small colo rental in Tampa; anywhere from 8RU to
> a
> half-rack?  I'd prefer at least one tier 1 uplink, and at least 1 tier 2,
> dial-a-yield 100Base, and 24 hour access, but I'm flexible.  Pinellas
> County
> is also fine.
>
> 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      http://photo.imageinc.us             +1 727 647
> 1274
>
>


From randy at psg.com  Sun Sep  4 05:02:51 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 04 Sep 2011 12:02:51 +0200
Subject: Do Not Complicate Routing Security with Voodoo Economics
Message-ID: <m2mxek1v78.wl%randy@psg.com>

[ http://archive.psg.com/110904.broadside.html ]

	Do Not Complicate Routing Security with Voodoo Economics
			      a broadside

A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and
Goldberg[1] drew a lot of 'discussion' from the floor.  But that
discussion missed significant problems with this work.  I raise this
because of fear that uncritical acceptance of this work will be used as
the basis for others' work, or worse, misguided public policy.
 o The ISP economic and incentive model is overly naive to the point of
   being misleading, 
 o The security threat model is unrealistic and misguided, and
 o The simulations are questionable.

Basic ISP economics are quite different from those described by the
authors.  Above the tail links to paying customers, the expenses of
inter-provider traffic are often higher than the income, thanks to the
telcos' race to the bottom.  In this counter-intuitive world, transit
can often be cheaper than peering.  I.e. history shows that in the rare
cases where providers have been inclined to such games, they usually
shed traffic not stole it, the opposite of what the paper presumes.  The
paper also completely ignores the rise of the content providers as
described so well in SIGCOMM 2010 by Labovitz et alia[2]

It is not clear how to ?fix? the economic model, especially as[3] says
you can not do so with rigor.  Once one starts, e.g. the paper may lack
Tier-N peering richness which is believed to be at the edges, we have
bought into the game for which there is no clear end.

But this is irrelevant, what will motivate deployment of BGP security is
not provider traffic-shifting.  BGP security is, as its name indicates,
about security, preventing data stealing (think banking
transactions[4]), keeping miscreants from originating address space of
others (think YouTube incident) or as attack/spam sources, etc.

The largest obstacle to deployment of BGP security is that the
technology being deployed, RPKI-based origin validation and later
BGPsec, are based on an X.509 certificate hierarchy, the RPKI.  This
radically changes the current inter-ISP web of trust model to one having
ISPs' routing at the mercy of the Regional Internet Registries (RIRs).
Will the benefits of security - no more YouTube incidents, etc. - be
perceived as worth having one's routing at the whim of an
non-operational administrative monopoly?  Perhaps this is the real
economic game here, and will cause a change in the relationship between
the operators and the RIR cartel.

The paper's simulations really should be shown not to rely on the
popular but highly problematic3 Gao-Rexford model of inter-provider
relationships, that providers prefer customers over peers (in fact, a
number of global Tier-1 providers have preferred peers for decades), and
that relationships are valley free, which also has significant
exceptions.  Yet these invalid assumptions may underpin the simulation
results.

---

Randy Bush <randy at psg.com>
Dubrovnik,  2011.9.4

[1] P. Gill, M. Schapira, and S. Goldberg, Let the Market Drive
Deployment: A Strategy for Transitioning to BGP Security, SIGCOMM 2011,
August 2011.
http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p14.pdf

[2] [1] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and
F. Jahanian, ?Internet inter-domain traffic,? in SIGCOMM '10:
Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010.

[3] M. Roughan, W. Willinger, O. Maennel, D. Perouli, and R. Bush, 10
Lessons from 10 Years of Measuring and Modeling the Internet's
Autonomous Systems, IEEE Journal on Selected Areas in Communications,
Vol. 29, No. 9, pp. 1-12, Oct. 2011.
https://archive.psg.com/111000.TenLessons.pdf

[4] A. Pilosov, T. Kapela. Stealing The Internet An Internet-Scale Man
In The Middle Attack, Defcon 16, August, 2008.
http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf



From fw at deneb.enyo.de  Sun Sep  4 05:56:25 2011
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 04 Sep 2011 12:56:25 +0200
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <20110903195746.GA83947@typo.org> (Wayne E. Bouchard's message of
 "Sat, 3 Sep 2011 12:57:46 -0700")
References: <CA883C31.2D5E0%skeeve@eintellego.net>
 <20110903195746.GA83947@typo.org>
Message-ID: <871uvw8tk6.fsf@mid.deneb.enyo.de>

* Wayne E. Bouchard:

> the users will screw themselves by flooding their uplinks in which
> case they will know what they've done to themselves and will largely
> accept the problems for the durration

With shared media networks (or insufficient backhaul capacities),
congestion affects more than just the customer causing it.



From rdobbins at arbor.net  Sun Sep  4 06:24:38 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sun, 4 Sep 2011 11:24:38 +0000
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <m2mxek1v78.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
Message-ID: <004713BD-6570-444F-8A23-7706BDCFF0D2@arbor.net>

On Sep 4, 2011, at 5:02 PM, Randy Bush wrote:

> Will the benefits of security - no more YouTube incidents, etc. - be perceived as worth having one's routing at the whim of an non-operational administrative monopoly?

Given recent events in SSL CA-land, how certain are we that the putative security benefits are all that great?  Not to mention the near-certainty of a BGP version of 'PROTECT IP', once the mechanisms are in place.

Same applies to DNSSEC, of course.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From neil at domino.org  Sun Sep  4 08:26:44 2011
From: neil at domino.org (Neil J. McRae)
Date: Sun, 4 Sep 2011 13:26:44 +0000
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <m2mxek1v78.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
Message-ID: <DE645305-BF25-42AA-89C1-8C0509E577B1@domino.org>

Well said Randy - the previous paper is flawed and if the findings where true you would wonder how anyone ever created a viable online business.

Neil

Sent from my iPhone

On 4 Sep 2011, at 11:03, "Randy Bush" <randy at psg.com> wrote:

> [ http://archive.psg.com/110904.broadside.html ]
> 
>    Do Not Complicate Routing Security with Voodoo Economics
>                  a broadside
> 
> A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and
> Goldberg[1] drew a lot of 'discussion' from the floor.  But that
> discussion missed significant problems with this work.  I raise this
> because of fear that uncritical acceptance of this work will be used as
> the basis for others' work, or worse, misguided public policy.
> o The ISP economic and incentive model is overly naive to the point of
>   being misleading, 
> o The security threat model is unrealistic and misguided, and
> o The simulations are questionable.
> 
> Basic ISP economics are quite different from those described by the
> authors.  Above the tail links to paying customers, the expenses of
> inter-provider traffic are often higher than the income, thanks to the
> telcos' race to the bottom.  In this counter-intuitive world, transit
> can often be cheaper than peering.  I.e. history shows that in the rare
> cases where providers have been inclined to such games, they usually
> shed traffic not stole it, the opposite of what the paper presumes.  The
> paper also completely ignores the rise of the content providers as
> described so well in SIGCOMM 2010 by Labovitz et alia[2]
> 
> It is not clear how to ?fix? the economic model, especially as[3] says
> you can not do so with rigor.  Once one starts, e.g. the paper may lack
> Tier-N peering richness which is believed to be at the edges, we have
> bought into the game for which there is no clear end.
> 
> But this is irrelevant, what will motivate deployment of BGP security is
> not provider traffic-shifting.  BGP security is, as its name indicates,
> about security, preventing data stealing (think banking
> transactions[4]), keeping miscreants from originating address space of
> others (think YouTube incident) or as attack/spam sources, etc.
> 
> The largest obstacle to deployment of BGP security is that the
> technology being deployed, RPKI-based origin validation and later
> BGPsec, are based on an X.509 certificate hierarchy, the RPKI.  This
> radically changes the current inter-ISP web of trust model to one having
> ISPs' routing at the mercy of the Regional Internet Registries (RIRs).
> Will the benefits of security - no more YouTube incidents, etc. - be
> perceived as worth having one's routing at the whim of an
> non-operational administrative monopoly?  Perhaps this is the real
> economic game here, and will cause a change in the relationship between
> the operators and the RIR cartel.
> 
> The paper's simulations really should be shown not to rely on the
> popular but highly problematic3 Gao-Rexford model of inter-provider
> relationships, that providers prefer customers over peers (in fact, a
> number of global Tier-1 providers have preferred peers for decades), and
> that relationships are valley free, which also has significant
> exceptions.  Yet these invalid assumptions may underpin the simulation
> results.
> 
> ---
> 
> Randy Bush <randy at psg.com>
> Dubrovnik,  2011.9.4
> 
> [1] P. Gill, M. Schapira, and S. Goldberg, Let the Market Drive
> Deployment: A Strategy for Transitioning to BGP Security, SIGCOMM 2011,
> August 2011.
> http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p14.pdf
> 
> [2] [1] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and
> F. Jahanian, ?Internet inter-domain traffic,? in SIGCOMM '10:
> Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010.
> 
> [3] M. Roughan, W. Willinger, O. Maennel, D. Perouli, and R. Bush, 10
> Lessons from 10 Years of Measuring and Modeling the Internet's
> Autonomous Systems, IEEE Journal on Selected Areas in Communications,
> Vol. 29, No. 9, pp. 1-12, Oct. 2011.
> https://archive.psg.com/111000.TenLessons.pdf
> 
> [4] A. Pilosov, T. Kapela. Stealing The Internet An Internet-Scale Man
> In The Middle Attack, Defcon 16, August, 2008.
> http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf
> 
> 




From Valdis.Kletnieks at vt.edu  Sun Sep  4 08:35:42 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 04 Sep 2011 09:35:42 -0400
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: Your message of "Sat, 03 Sep 2011 18:38:40 EDT."
 <17832021.697.1315089520586.JavaMail.root@benjamin.baylink.com>
References: <17832021.697.1315089520586.JavaMail.root@benjamin.baylink.com>
Message-ID: <6053.1315143342@turing-police.cc.vt.edu>

On Sat, 03 Sep 2011 18:38:40 EDT, Jay Ashworth said:

> Two people making the same mistake: end-user support telephone calls don't 
> generally go to datacenters, do they? 

Maybe they've figured out how to let an AI answer the phones. All you need is
text-to-speech, speech-to-text, and the script the outsourced semi-trained
monkeys would have been using.

Or maybe they've not been outsourced at all, and 'Mumbai' is the codeword for
the data center, and it's all a coverup because even outsourcing a job is an
easier PR job than replacing somebody with a robot/computer. ;)

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

From randy at psg.com  Sun Sep  4 08:36:37 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 04 Sep 2011 15:36:37 +0200
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <DE645305-BF25-42AA-89C1-8C0509E577B1@domino.org>
References: <m2mxek1v78.wl%randy@psg.com>
 <DE645305-BF25-42AA-89C1-8C0509E577B1@domino.org>
Message-ID: <m239gc1lay.wl%randy@psg.com>

> the previous paper is flawed and if the findings where true you would
> wonder how anyone ever created a viable online business.

to me honest, what set me off was 

   http://transition.fcc.gov/pshs/advisory/csric3/wg-descriptions_v1

describing, among others, a routing working group of an fcc
"communications security, reliability and interoperability council"

i.e. these folk plan to write policy and procedures for operators, not
just write publish or perish papers.

randy



From randy at psg.com  Sun Sep  4 08:44:05 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 04 Sep 2011 15:44:05 +0200
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <m239gc1lay.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <DE645305-BF25-42AA-89C1-8C0509E577B1@domino.org>
 <m239gc1lay.wl%randy@psg.com>
Message-ID: <m21uvw1kyi.wl%randy@psg.com>

>> the previous paper is flawed and if the findings where true you would
>> wonder how anyone ever created a viable online business.
> 
> to me honest, what set me off was 
> 
>    http://transition.fcc.gov/pshs/advisory/csric3/wg-descriptions_v1
> 
> describing, among others, a routing working group of an fcc
> "communications security, reliability and interoperability council"
> 
> i.e. these folk plan to write policy and procedures for operators, not
> just write publish or perish papers.

apologies.  dorn caught my error

http://transition.fcc.gov/pshs/advisory/csric3/wg-descriptions_v1.pdf

randy



From patrick at ianai.net  Sun Sep  4 08:51:12 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sun, 4 Sep 2011 09:51:12 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <m2mxek1v78.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
Message-ID: <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>

Mostly excellent thoughts, well documented.  I have a question about this statement though:

> in fact, a number of global Tier-1 providers have preferred peers for decades

I assume you mean for a very limited subset of their customers?  I've checked routing on well over half the transit free networks on the planet, and for the small number of customers I was researching, they definitely preferred customer routes over peering.

-- 
TTFN,
patrick


On Sep 4, 2011, at 6:02 AM, Randy Bush wrote:

> [ http://archive.psg.com/110904.broadside.html ]
> 
> 	Do Not Complicate Routing Security with Voodoo Economics
> 			      a broadside
> 
> A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and
> Goldberg[1] drew a lot of 'discussion' from the floor.  But that
> discussion missed significant problems with this work.  I raise this
> because of fear that uncritical acceptance of this work will be used as
> the basis for others' work, or worse, misguided public policy.
> o The ISP economic and incentive model is overly naive to the point of
>   being misleading, 
> o The security threat model is unrealistic and misguided, and
> o The simulations are questionable.
> 
> Basic ISP economics are quite different from those described by the
> authors.  Above the tail links to paying customers, the expenses of
> inter-provider traffic are often higher than the income, thanks to the
> telcos' race to the bottom.  In this counter-intuitive world, transit
> can often be cheaper than peering.  I.e. history shows that in the rare
> cases where providers have been inclined to such games, they usually
> shed traffic not stole it, the opposite of what the paper presumes.  The
> paper also completely ignores the rise of the content providers as
> described so well in SIGCOMM 2010 by Labovitz et alia[2]
> 
> It is not clear how to ?fix? the economic model, especially as[3] says
> you can not do so with rigor.  Once one starts, e.g. the paper may lack
> Tier-N peering richness which is believed to be at the edges, we have
> bought into the game for which there is no clear end.
> 
> But this is irrelevant, what will motivate deployment of BGP security is
> not provider traffic-shifting.  BGP security is, as its name indicates,
> about security, preventing data stealing (think banking
> transactions[4]), keeping miscreants from originating address space of
> others (think YouTube incident) or as attack/spam sources, etc.
> 
> The largest obstacle to deployment of BGP security is that the
> technology being deployed, RPKI-based origin validation and later
> BGPsec, are based on an X.509 certificate hierarchy, the RPKI.  This
> radically changes the current inter-ISP web of trust model to one having
> ISPs' routing at the mercy of the Regional Internet Registries (RIRs).
> Will the benefits of security - no more YouTube incidents, etc. - be
> perceived as worth having one's routing at the whim of an
> non-operational administrative monopoly?  Perhaps this is the real
> economic game here, and will cause a change in the relationship between
> the operators and the RIR cartel.
> 
> The paper's simulations really should be shown not to rely on the
> popular but highly problematic3 Gao-Rexford model of inter-provider
> relationships, that providers prefer customers over peers (in fact, a
> number of global Tier-1 providers have preferred peers for decades), and
> that relationships are valley free, which also has significant
> exceptions.  Yet these invalid assumptions may underpin the simulation
> results.
> 
> ---
> 
> Randy Bush <randy at psg.com>
> Dubrovnik,  2011.9.4
> 
> [1] P. Gill, M. Schapira, and S. Goldberg, Let the Market Drive
> Deployment: A Strategy for Transitioning to BGP Security, SIGCOMM 2011,
> August 2011.
> http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p14.pdf
> 
> [2] [1] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and
> F. Jahanian, ?Internet inter-domain traffic,? in SIGCOMM '10:
> Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010.
> 
> [3] M. Roughan, W. Willinger, O. Maennel, D. Perouli, and R. Bush, 10
> Lessons from 10 Years of Measuring and Modeling the Internet's
> Autonomous Systems, IEEE Journal on Selected Areas in Communications,
> Vol. 29, No. 9, pp. 1-12, Oct. 2011.
> https://archive.psg.com/111000.TenLessons.pdf
> 
> [4] A. Pilosov, T. Kapela. Stealing The Internet An Internet-Scale Man
> In The Middle Attack, Defcon 16, August, 2008.
> http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf
> 




From deleskie at gmail.com  Sun Sep  4 08:53:09 2011
From: deleskie at gmail.com (deleskie at gmail.com)
Date: Sun, 4 Sep 2011 13:53:09 +0000
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
References: <m2mxek1v78.wl%randy@psg.com><28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
Message-ID: <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>

I have worked for more then one transit free network, and have work with people from (most) of the rest, we always prefer cust over peer, every time.

-jim
Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message-----
From: "Patrick W. Gilmore" <patrick at ianai.net>
Date: Sun, 4 Sep 2011 09:51:12 
To: North American Network Operators' Group<nanog at nanog.org>
Subject: Re: Do Not Complicate Routing Security with Voodoo Economics

Mostly excellent thoughts, well documented.  I have a question about this statement though:

> in fact, a number of global Tier-1 providers have preferred peers for decades

I assume you mean for a very limited subset of their customers?  I've checked routing on well over half the transit free networks on the planet, and for the small number of customers I was researching, they definitely preferred customer routes over peering.

-- 
TTFN,
patrick


On Sep 4, 2011, at 6:02 AM, Randy Bush wrote:

> [ http://archive.psg.com/110904.broadside.html ]
> 
> 	Do Not Complicate Routing Security with Voodoo Economics
> 			      a broadside
> 
> A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and
> Goldberg[1] drew a lot of 'discussion' from the floor.  But that
> discussion missed significant problems with this work.  I raise this
> because of fear that uncritical acceptance of this work will be used as
> the basis for others' work, or worse, misguided public policy.
> o The ISP economic and incentive model is overly naive to the point of
>   being misleading, 
> o The security threat model is unrealistic and misguided, and
> o The simulations are questionable.
> 
> Basic ISP economics are quite different from those described by the
> authors.  Above the tail links to paying customers, the expenses of
> inter-provider traffic are often higher than the income, thanks to the
> telcos' race to the bottom.  In this counter-intuitive world, transit
> can often be cheaper than peering.  I.e. history shows that in the rare
> cases where providers have been inclined to such games, they usually
> shed traffic not stole it, the opposite of what the paper presumes.  The
> paper also completely ignores the rise of the content providers as
> described so well in SIGCOMM 2010 by Labovitz et alia[2]
> 
> It is not clear how to ?fix? the economic model, especially as[3] says
> you can not do so with rigor.  Once one starts, e.g. the paper may lack
> Tier-N peering richness which is believed to be at the edges, we have
> bought into the game for which there is no clear end.
> 
> But this is irrelevant, what will motivate deployment of BGP security is
> not provider traffic-shifting.  BGP security is, as its name indicates,
> about security, preventing data stealing (think banking
> transactions[4]), keeping miscreants from originating address space of
> others (think YouTube incident) or as attack/spam sources, etc.
> 
> The largest obstacle to deployment of BGP security is that the
> technology being deployed, RPKI-based origin validation and later
> BGPsec, are based on an X.509 certificate hierarchy, the RPKI.  This
> radically changes the current inter-ISP web of trust model to one having
> ISPs' routing at the mercy of the Regional Internet Registries (RIRs).
> Will the benefits of security - no more YouTube incidents, etc. - be
> perceived as worth having one's routing at the whim of an
> non-operational administrative monopoly?  Perhaps this is the real
> economic game here, and will cause a change in the relationship between
> the operators and the RIR cartel.
> 
> The paper's simulations really should be shown not to rely on the
> popular but highly problematic3 Gao-Rexford model of inter-provider
> relationships, that providers prefer customers over peers (in fact, a
> number of global Tier-1 providers have preferred peers for decades), and
> that relationships are valley free, which also has significant
> exceptions.  Yet these invalid assumptions may underpin the simulation
> results.
> 
> ---
> 
> Randy Bush <randy at psg.com>
> Dubrovnik,  2011.9.4
> 
> [1] P. Gill, M. Schapira, and S. Goldberg, Let the Market Drive
> Deployment: A Strategy for Transitioning to BGP Security, SIGCOMM 2011,
> August 2011.
> http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p14.pdf
> 
> [2] [1] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and
> F. Jahanian, ?Internet inter-domain traffic,? in SIGCOMM '10:
> Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010.
> 
> [3] M. Roughan, W. Willinger, O. Maennel, D. Perouli, and R. Bush, 10
> Lessons from 10 Years of Measuring and Modeling the Internet's
> Autonomous Systems, IEEE Journal on Selected Areas in Communications,
> Vol. 29, No. 9, pp. 1-12, Oct. 2011.
> https://archive.psg.com/111000.TenLessons.pdf
> 
> [4] A. Pilosov, T. Kapela. Stealing The Internet An Internet-Scale Man
> In The Middle Attack, Defcon 16, August, 2008.
> http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf
> 



From randy at psg.com  Sun Sep  4 08:59:11 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 04 Sep 2011 15:59:11 +0200
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>
References: <m2mxek1v78.wl%randy@psg.com>
 <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
 <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>
Message-ID: <m2wrdoz9w0.wl%randy@psg.com>

> I have worked for more then one transit free network, and have work
> with people from (most) of the rest, we always prefer cust over peer,
> every time.

again, more than one of the world's largest providers prefer peers.  and
even if they wanted to change, it would be horribly anti-pola to the
affected customers, like white hot wires.  and one just does not do that
to customers.

randy



From patrick at ianai.net  Sun Sep  4 09:04:36 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sun, 4 Sep 2011 10:04:36 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <m2wrdoz9w0.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
 <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>
 <m2wrdoz9w0.wl%randy@psg.com>
Message-ID: <5EC234C6-1BCB-4EFF-BC68-AF999EC9E0F9@ianai.net>

On Sep 4, 2011, at 9:59 AM, Randy Bush wrote:

>> I have worked for more then one transit free network, and have work
>> with people from (most) of the rest, we always prefer cust over peer,
>> every time.
> 
> again, more than one of the world's largest providers prefer peers.  and
> even if they wanted to change, it would be horribly anti-pola to the
> affected customers, like white hot wires.  and one just does not do that
> to customers.

I repeat, you are obviously talking about a small subset of customers, right?  Please clarify.

Because I know customers of all 14 transit free networks, and these customers all believe the network is preferring their routes unless the customer sends a community to override that preference.

-- 
TTFN,
patrick




From leigh.porter at ukbroadband.com  Sun Sep  4 09:05:23 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Sun, 4 Sep 2011 14:05:23 +0000
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <m2wrdoz9w0.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
 <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>
 <m2wrdoz9w0.wl%randy@psg.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643B9501@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Randy Bush [mailto:randy at psg.com]
> Sent: 04 September 2011 15:01
> To: deleskie at gmail.com
> Cc: North American Network Operators' Group
> Subject: Re: Do Not Complicate Routing Security with Voodoo Economics
> 
> > I have worked for more then one transit free network, and have work
> > with people from (most) of the rest, we always prefer cust over peer,
> > every time.
> 
> again, more than one of the world's largest providers prefer peers.
> and
> even if they wanted to change, it would be horribly anti-pola to the
> affected customers, like white hot wires.  and one just does not do
> that
> to customers.
> 
> randy

Presumably you can change that behaviour with communities?



--
Leigh Porter


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From deleskie at gmail.com  Sun Sep  4 09:19:34 2011
From: deleskie at gmail.com (jim deleskie)
Date: Sun, 4 Sep 2011 11:19:34 -0300
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <m2wrdoz9w0.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
 <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>
 <m2wrdoz9w0.wl%randy@psg.com>
Message-ID: <CAJL_ZMP870eE5TGff6DCiRaQKbJgMpFtmq4Jg-k97GdsQzoAaw@mail.gmail.com>

While I can think of some corner cases for this, ie you have a
satellite down link from one provider and fiber to anther.  I expect
this is not the norm for most networks/customers.

-jim

On Sun, Sep 4, 2011 at 10:59 AM, Randy Bush <randy at psg.com> wrote:
>> I have worked for more then one transit free network, and have work
>> with people from (most) of the rest, we always prefer cust over peer,
>> every time.
>
> again, more than one of the world's largest providers prefer peers. ?and
> even if they wanted to change, it would be horribly anti-pola to the
> affected customers, like white hot wires. ?and one just does not do that
> to customers.
>
> randy
>



From jrex at CS.Princeton.EDU  Sun Sep  4 10:07:30 2011
From: jrex at CS.Princeton.EDU (Jennifer Rexford)
Date: Sun, 4 Sep 2011 11:07:30 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <CAJHGrrTVMja6q1-OjW2J1aa2nvJNh2PqNLY0+QZaf1Lccty0vA@mail.gmail.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <DE645305-BF25-42AA-89C1-8C0509E577B1@domino.org>
 <m239gc1lay.wl%randy@psg.com> <m21uvw1kyi.wl%randy@psg.com>
 <CAJHGrrTVMja6q1-OjW2J1aa2nvJNh2PqNLY0+QZaf1Lccty0vA@mail.gmail.com>
Message-ID: <455386DC-AB1E-44BB-A0E3-23BFC3CF5F15@CS.Princeton.EDU>


>> to me honest, what set me off was
>> 
>>    http://transition.fcc.gov/pshs/advisory/csric3/wg-descriptions_v1
>> 
>> describing, among others, a routing working group of an fcc
>> "communications security, reliability and interoperability council"
>> 
>> i.e. these folk plan to write policy and procedures for operators, not
>> just write publish or perish papers.
> 
> apologies.  dorn caught my error
> 
> http://transition.fcc.gov/pshs/advisory/csric3/wg-descriptions_v1.pdf

As one of the co-chairs of this working group, I'd like to chime in to clarify the purpose of this group.  Our goal is to assemble a group of vendors and operators (not "publish or perish" academics) to discuss and recommend effective strategies for incremental deployment of security solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It is not to design new security protocols or to "write policy and procedures for operators" -- that would of course be over-reaching and presumptuous.  The goal is specifically to identify strategies for incremental deployment of the solutions designed and evaluated by the appropriate technical groups (e.g., IETF working groups).  And, while the SIGCOMM paper you mention is an example of such a strategy, it is just one single example -- and is by no means the recommendation of a group that is not yet even fully assembled yet.  The working group will debate and discuss a great many issues before suggesting any strategies, and those strategies would be the output of the entire working group.

<tongue in cheek> As for "publish or perish" academics, I doubt you'll find that the small set of academics who choose to go knee deep into operational issues do so because they are trying to optimize their academic careers... ;) </tongue in cheek>

-- Jen


From neil at domino.org  Sun Sep  4 10:32:36 2011
From: neil at domino.org (Neil J. McRae)
Date: Sun, 4 Sep 2011 15:32:36 +0000
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <455386DC-AB1E-44BB-A0E3-23BFC3CF5F15@CS.Princeton.EDU>
Message-ID: <CA895773.5FFD%neil@domino.org>

Jen,
What operators are involved? And who represents them specifically?

Neil.

On 04/09/2011 16:07, "Jennifer Rexford" <jrex at CS.Princeton.EDU> wrote:
>
>
>As one of the co-chairs of this working group, I'd like to chime in to
>clarify the purpose of this group.  Our goal is to assemble a group of
>vendors and operators (not "publish or perish" academics) to discuss and
>recommend effective strategies for incremental deployment of security
>solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
>is not to design new security protocols or to "write policy and
>procedures for operators" -- that would of course be over-reaching and
>presumptuous.  The goal is specifically to identify strategies for
>incremental deployment of the solutions designed and evaluated by the
>appropriate technical groups (e.g., IETF working groups).  And, while the
>SIGCOMM paper you mention is an example of such a strategy, it is just
>one single example -- and is by no means the recommendation of a group
>that is not yet even fully assembled yet.  The working group will debate
>and discuss a great many issues before suggesting any strategies, and
>those strategies would be the output of the entire working group.
>
><tongue in cheek> As for "publish or perish" academics, I doubt you'll
>find that the small set of academics who choose to go knee deep into
>operational issues do so because they are trying to optimize their
>academic careers... ;) </tongue in cheek>
>
>-- Jen
>





From jrex at CS.Princeton.EDU  Sun Sep  4 10:44:49 2011
From: jrex at CS.Princeton.EDU (Jennifer Rexford)
Date: Sun, 4 Sep 2011 11:44:49 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <CA895773.5FFD%neil@domino.org>
References: <CA895773.5FFD%neil@domino.org>
Message-ID: <5B1F5300-3752-4028-80A4-65F3B8AB340E@cs.princeton.edu>

Neil,

The group is being assembled right now, so we don't have a list as of yet. 

-- Jen


Sent from my iPhone

On Sep 4, 2011, at 11:32 AM, "Neil J. McRae" <neil at domino.org> wrote:

> Jen,
> What operators are involved? And who represents them specifically?
> 
> Neil.
> 
> On 04/09/2011 16:07, "Jennifer Rexford" <jrex at CS.Princeton.EDU> wrote:
>> 
>> 
>> As one of the co-chairs of this working group, I'd like to chime in to
>> clarify the purpose of this group.  Our goal is to assemble a group of
>> vendors and operators (not "publish or perish" academics) to discuss and
>> recommend effective strategies for incremental deployment of security
>> solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
>> is not to design new security protocols or to "write policy and
>> procedures for operators" -- that would of course be over-reaching and
>> presumptuous.  The goal is specifically to identify strategies for
>> incremental deployment of the solutions designed and evaluated by the
>> appropriate technical groups (e.g., IETF working groups).  And, while the
>> SIGCOMM paper you mention is an example of such a strategy, it is just
>> one single example -- and is by no means the recommendation of a group
>> that is not yet even fully assembled yet.  The working group will debate
>> and discuss a great many issues before suggesting any strategies, and
>> those strategies would be the output of the entire working group.
>> 
>> <tongue in cheek> As for "publish or perish" academics, I doubt you'll
>> find that the small set of academics who choose to go knee deep into
>> operational issues do so because they are trying to optimize their
>> academic careers... ;) </tongue in cheek>
>> 
>> -- Jen
>> 
> 
> 



From neil at domino.org  Sun Sep  4 12:21:07 2011
From: neil at domino.org (Neil J. McRae)
Date: Sun, 4 Sep 2011 17:21:07 +0000
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <5B1F5300-3752-4028-80A4-65F3B8AB340E@cs.princeton.edu>
References: <CA895773.5FFD%neil@domino.org>,
 <5B1F5300-3752-4028-80A4-65F3B8AB340E@cs.princeton.edu>
Message-ID: <305E552C-B38C-477A-A1C0-91CF59BEA262@domino.org>

maybe volunteers from the nanog community should contact you?

On 4 Sep 2011, at 16:45, "Jennifer Rexford" <jrex at CS.Princeton.EDU> wrote:

> Neil,
> 
> The group is being assembled right now, so we don't have a list as of yet. 
> 
> -- Jen
> 
> 
> Sent from my iPhone
> 
> On Sep 4, 2011, at 11:32 AM, "Neil J. McRae" <neil at domino.org> wrote:
> 
>> Jen,
>> What operators are involved? And who represents them specifically?
>> 
>> Neil.
>> 
>> On 04/09/2011 16:07, "Jennifer Rexford" <jrex at CS.Princeton.EDU> wrote:
>>> 
>>> 
>>> As one of the co-chairs of this working group, I'd like to chime in to
>>> clarify the purpose of this group.  Our goal is to assemble a group of
>>> vendors and operators (not "publish or perish" academics) to discuss and
>>> recommend effective strategies for incremental deployment of security
>>> solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
>>> is not to design new security protocols or to "write policy and
>>> procedures for operators" -- that would of course be over-reaching and
>>> presumptuous.  The goal is specifically to identify strategies for
>>> incremental deployment of the solutions designed and evaluated by the
>>> appropriate technical groups (e.g., IETF working groups).  And, while the
>>> SIGCOMM paper you mention is an example of such a strategy, it is just
>>> one single example -- and is by no means the recommendation of a group
>>> that is not yet even fully assembled yet.  The working group will debate
>>> and discuss a great many issues before suggesting any strategies, and
>>> those strategies would be the output of the entire working group.
>>> 
>>> <tongue in cheek> As for "publish or perish" academics, I doubt you'll
>>> find that the small set of academics who choose to go knee deep into
>>> operational issues do so because they are trying to optimize their
>>> academic careers... ;) </tongue in cheek>
>>> 
>>> -- Jen
>>> 
>> 
>> 
> 




From james at gitflorida.com  Sun Sep  4 12:31:11 2011
From: james at gitflorida.com (James P. Ashton)
Date: Sun, 04 Sep 2011 13:31:11 -0400 (EDT)
Subject: Tampa small colo recs?
In-Reply-To: <24261253.402.1314924618891.JavaMail.root@benjamin.baylink.com>
Message-ID: <527113ec-94b8-4bc5-a246-88c7bffa894b@mail.gitflorida.com>

Jay,
 I recommend E Solutions, But I am biased (I build the network).

 But also in town we have,
 
 Switch and Data
 Qwest
 Peak 10
 Sago Networks
 Hostway


I know them all pretty well, so if you have any questions, fire away.


James



----- Original Message -----
Anyone got any opinions on small colo rental in Tampa; anywhere from 8RU to a 
half-rack?  I'd prefer at least one tier 1 uplink, and at least 1 tier 2,
dial-a-yield 100Base, and 24 hour access, but I'm flexible.  Pinellas County
is also fine.

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      http://photo.imageinc.us             +1 727 647 1274




From randy at psg.com  Sun Sep  4 12:56:31 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 04 Sep 2011 19:56:31 +0200
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <455386DC-AB1E-44BB-A0E3-23BFC3CF5F15@CS.Princeton.EDU>
References: <m2mxek1v78.wl%randy@psg.com>
 <DE645305-BF25-42AA-89C1-8C0509E577B1@domino.org>
 <m239gc1lay.wl%randy@psg.com> <m21uvw1kyi.wl%randy@psg.com>
 <CAJHGrrTVMja6q1-OjW2J1aa2nvJNh2PqNLY0+QZaf1Lccty0vA@mail.gmail.com>
 <455386DC-AB1E-44BB-A0E3-23BFC3CF5F15@CS.Princeton.EDU>
Message-ID: <m2ty8syywg.wl%randy@psg.com>

> As one of the co-chairs of this working group, I'd like to chime in to
> clarify the purpose of this group.  Our goal is to assemble a group of
> vendors and operators (not "publish or perish" academics) to discuss and
> recommend effective strategies for incremental deployment of security
> solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
> is not to design new security protocols or to "write policy and
> procedures for operators"

    This Working Group will recommend the framework for an industry
    agreement regarding the adoption of secure routing procedures and
    protocols based on existing work in industry and research. The
    framework will include specific technical procedures and protocols. The
    framework will be proposed in a way suitable for opt-in by large
    Internet Service Providers...

randy



From randy at psg.com  Sun Sep  4 12:57:51 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 04 Sep 2011 19:57:51 +0200
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <CAJL_ZMP870eE5TGff6DCiRaQKbJgMpFtmq4Jg-k97GdsQzoAaw@mail.gmail.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
 <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>
 <m2wrdoz9w0.wl%randy@psg.com>
 <CAJL_ZMP870eE5TGff6DCiRaQKbJgMpFtmq4Jg-k97GdsQzoAaw@mail.gmail.com>
Message-ID: <m2sjocyyu8.wl%randy@psg.com>

> While I can think of some corner cases for this, ie you have a
> satellite down link from one provider and fiber to anther.  I expect
> this is not the norm for most networks/customers.

what is it you do not understand about "more than one of the world's
largest providers?"  not in corner cases, but as core policy.

randy



From tkapela at gmail.com  Sun Sep  4 13:07:32 2011
From: tkapela at gmail.com (Anton Kapela)
Date: Sun, 4 Sep 2011 13:07:32 -0500
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <305E552C-B38C-477A-A1C0-91CF59BEA262@domino.org>
References: <CA895773.5FFD%neil@domino.org>
 <5B1F5300-3752-4028-80A4-65F3B8AB340E@cs.princeton.edu>
 <305E552C-B38C-477A-A1C0-91CF59BEA262@domino.org>
Message-ID: <-6360168165970938467@unknownmsgid>

+1

-Tk

On Sep 4, 2011, at 12:23 PM, "Neil J. McRae" <neil at domino.org> wrote:

> maybe volunteers from the nanog community should contact you?
>
> On 4 Sep 2011, at 16:45, "Jennifer Rexford" <jrex at CS.Princeton.EDU> wrote:
>
>> Neil,
>>
>> The group is being assembled right now, so we don't have a list as of yet.
>>
>> -- Jen
>>
>>
>> Sent from my iPhone
>>
>> On Sep 4, 2011, at 11:32 AM, "Neil J. McRae" <neil at domino.org> wrote:
>>
>>> Jen,
>>> What operators are involved? And who represents them specifically?
>>>
>>> Neil.
>>>
>>> On 04/09/2011 16:07, "Jennifer Rexford" <jrex at CS.Princeton.EDU> wrote:
>>>>
>>>>
>>>> As one of the co-chairs of this working group, I'd like to chime in to
>>>> clarify the purpose of this group.  Our goal is to assemble a group of
>>>> vendors and operators (not "publish or perish" academics) to discuss and
>>>> recommend effective strategies for incremental deployment of security
>>>> solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
>>>> is not to design new security protocols or to "write policy and
>>>> procedures for operators" -- that would of course be over-reaching and
>>>> presumptuous.  The goal is specifically to identify strategies for
>>>> incremental deployment of the solutions designed and evaluated by the
>>>> appropriate technical groups (e.g., IETF working groups).  And, while the
>>>> SIGCOMM paper you mention is an example of such a strategy, it is just
>>>> one single example -- and is by no means the recommendation of a group
>>>> that is not yet even fully assembled yet.  The working group will debate
>>>> and discuss a great many issues before suggesting any strategies, and
>>>> those strategies would be the output of the entire working group.
>>>>
>>>> <tongue in cheek> As for "publish or perish" academics, I doubt you'll
>>>> find that the small set of academics who choose to go knee deep into
>>>> operational issues do so because they are trying to optimize their
>>>> academic careers... ;) </tongue in cheek>
>>>>
>>>> -- Jen
>>>>
>>>
>>>
>>
>
>



From jrex at CS.Princeton.EDU  Sun Sep  4 14:27:07 2011
From: jrex at CS.Princeton.EDU (Jennifer Rexford)
Date: Sun, 4 Sep 2011 15:27:07 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <m2ty8syywg.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <DE645305-BF25-42AA-89C1-8C0509E577B1@domino.org>
 <m239gc1lay.wl%randy@psg.com> <m21uvw1kyi.wl%randy@psg.com>
 <CAJHGrrTVMja6q1-OjW2J1aa2nvJNh2PqNLY0+QZaf1Lccty0vA@mail.gmail.com>
 <455386DC-AB1E-44BB-A0E3-23BFC3CF5F15@CS.Princeton.EDU>
 <m2ty8syywg.wl%randy@psg.com>
Message-ID: <9D3F17FB-4168-46B6-A6C4-AAD6E9A6E56B@CS.Princeton.EDU>

Randy,

Yes, as the brief write-up says, the group will make "recommendations regarding the adoption" (e.g., suggesting effective strategies for incremental deployment) of "procedures and protocols based on existing work" (e.g., RPKI, BGP-SEC, etc.).  In any case, if our current wording is unclear, we can easily revise it to clarify our goals.

-- Jen


On Sep 4, 2011, at 1:56 PM, Randy Bush wrote:

>> As one of the co-chairs of this working group, I'd like to chime in to
>> clarify the purpose of this group.  Our goal is to assemble a group of
>> vendors and operators (not "publish or perish" academics) to discuss and
>> recommend effective strategies for incremental deployment of security
>> solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
>> is not to design new security protocols or to "write policy and
>> procedures for operators"
> 
>    This Working Group will recommend the framework for an industry
>    agreement regarding the adoption of secure routing procedures and
>    protocols based on existing work in industry and research. The
>    framework will include specific technical procedures and protocols. The
>    framework will be proposed in a way suitable for opt-in by large
>    Internet Service Providers...
> 
> randy




From deleskie at gmail.com  Sun Sep  4 14:29:44 2011
From: deleskie at gmail.com (jim deleskie)
Date: Sun, 4 Sep 2011 16:29:44 -0300
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <m2sjocyyu8.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
 <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>
 <m2wrdoz9w0.wl%randy@psg.com>
 <CAJL_ZMP870eE5TGff6DCiRaQKbJgMpFtmq4Jg-k97GdsQzoAaw@mail.gmail.com>
 <m2sjocyyu8.wl%randy@psg.com>
Message-ID: <CAJL_ZMPc70qv7=pKMOJmsxAnjGypZ-yE-02TP0VLYp=+mKhPOw@mail.gmail.com>

Because routing to peers as a policy instead of customer as a matter
of policy, outside of corner cases make logical sence. While many
providers aren;t good at making money it is fact the purpose of the
ventures.  If I route to a customer I get paid for it.  If I send it
to a peer I do not.



On Sun, Sep 4, 2011 at 2:57 PM, Randy Bush <randy at psg.com> wrote:
>> While I can think of some corner cases for this, ie you have a
>> satellite down link from one provider and fiber to anther. ?I expect
>> this is not the norm for most networks/customers.
>
> what is it you do not understand about "more than one of the world's
> largest providers?" ?not in corner cases, but as core policy.
>
> randy
>



From jrex at CS.Princeton.EDU  Sun Sep  4 14:30:32 2011
From: jrex at CS.Princeton.EDU (Jennifer Rexford)
Date: Sun, 4 Sep 2011 15:30:32 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <305E552C-B38C-477A-A1C0-91CF59BEA262@domino.org>
References: <CA895773.5FFD%neil@domino.org>,
 <5B1F5300-3752-4028-80A4-65F3B8AB340E@cs.princeton.edu>
 <305E552C-B38C-477A-A1C0-91CF59BEA262@domino.org>
Message-ID: <1F5AFB0F-190E-498C-9D37-84433ADBE599@CS.Princeton.EDU>

Neil,

> maybe volunteers from the nanog community should contact you?

Thanks for the suggestion!  Yes, I would encourage interested people to contact me.  We won't be able to put everyone on the working group (in the interest of having a small enough group to make progress), but we are very interested in having people who can offer their expertise, feedback, and advice throughout the process...

-- Jen


> 
> On 4 Sep 2011, at 16:45, "Jennifer Rexford" <jrex at CS.Princeton.EDU> wrote:
> 
>> Neil,
>> 
>> The group is being assembled right now, so we don't have a list as of yet. 
>> 
>> -- Jen
>> 
>> 
>> Sent from my iPhone
>> 
>> On Sep 4, 2011, at 11:32 AM, "Neil J. McRae" <neil at domino.org> wrote:
>> 
>>> Jen,
>>> What operators are involved? And who represents them specifically?
>>> 
>>> Neil.
>>> 
>>> On 04/09/2011 16:07, "Jennifer Rexford" <jrex at CS.Princeton.EDU> wrote:
>>>> 
>>>> 
>>>> As one of the co-chairs of this working group, I'd like to chime in to
>>>> clarify the purpose of this group.  Our goal is to assemble a group of
>>>> vendors and operators (not "publish or perish" academics) to discuss and
>>>> recommend effective strategies for incremental deployment of security
>>>> solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work).  It
>>>> is not to design new security protocols or to "write policy and
>>>> procedures for operators" -- that would of course be over-reaching and
>>>> presumptuous.  The goal is specifically to identify strategies for
>>>> incremental deployment of the solutions designed and evaluated by the
>>>> appropriate technical groups (e.g., IETF working groups).  And, while the
>>>> SIGCOMM paper you mention is an example of such a strategy, it is just
>>>> one single example -- and is by no means the recommendation of a group
>>>> that is not yet even fully assembled yet.  The working group will debate
>>>> and discuss a great many issues before suggesting any strategies, and
>>>> those strategies would be the output of the entire working group.
>>>> 
>>>> <tongue in cheek> As for "publish or perish" academics, I doubt you'll
>>>> find that the small set of academics who choose to go knee deep into
>>>> operational issues do so because they are trying to optimize their
>>>> academic careers... ;) </tongue in cheek>
>>>> 
>>>> -- Jen
>>>> 
>>> 
>>> 
>> 
> 




From randy at psg.com  Sun Sep  4 15:03:54 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 04 Sep 2011 22:03:54 +0200
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <CAJL_ZMPc70qv7=pKMOJmsxAnjGypZ-yE-02TP0VLYp=+mKhPOw@mail.gmail.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
 <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>
 <m2wrdoz9w0.wl%randy@psg.com>
 <CAJL_ZMP870eE5TGff6DCiRaQKbJgMpFtmq4Jg-k97GdsQzoAaw@mail.gmail.com>
 <m2sjocyyu8.wl%randy@psg.com>
 <CAJL_ZMPc70qv7=pKMOJmsxAnjGypZ-yE-02TP0VLYp=+mKhPOw@mail.gmail.com>
Message-ID: <m2mxekyt05.wl%randy@psg.com>

> Because routing to peers as a policy instead of customer as a matter
> of policy, outside of corner cases make logical sence.

welcome to the internet, it does not always make logical sense at first
glance.

the myth in academia that customers are always preferred over peers
comes from about '96 when vaf complained to asp and me (and we moved it
to nanog for general discussion) that we were not announcing an
identical prefix list to him at east and west.  the reason turned out to
be that, on one of the routers, a peer path was shorter in some cases,
so we had chosen it.  we were perfectly happy with that but vaf was not,
and he ran the larger network so won the discussion.

randy



From goldbe at cs.bu.edu  Sun Sep  4 15:16:45 2011
From: goldbe at cs.bu.edu (Sharon Goldberg)
Date: Sun, 4 Sep 2011 16:16:45 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <m2mxek1v78.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
Message-ID: <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>

In response to Randy's three criticisms of our recent
SIGCOMM'11/NANOG'52 paper, which is available here:

http://www.cs.bu.edu/~goldbe/papers/SBGPtrans_full.pdf
http://www.cs.toronto.edu/~phillipa/sbgpTrans.html

Point 1: "The ISP economic and incentive model is overly naive to the
point of being misleading"

To clarify, our paper focuses on the following question:

Given that we want as many ASes as possible to deploy path validation
(S*BGP), what sort of incremental deployment strategy should we use?

To answer this question, one first needs to understand why an AS might
have incentive to deploy S*BGP in the first place.  There are many
possible reasons (e.g., "the benefits of security" that Randy
mentions, pressure from regulators, governments, or other ASes, PR
opportunities, etc), in this paper we focused on one very specific
incentive:

An ISP might deploy S*BGP in order to increase the volume of traffic
that it transits for its customers.

We use this incentive as an "economic lever" that can be used to drive
global S*BGP deployment.   The paper shows that, even disregarding
other economic levers (like security concerns, regulations, PR, etc),
this incentive is enough to cause the majority of the Internet to
deploy S*BGP, even if (a) security plays a very small role in the BGP
decision process (i.e. security considerations influence routing
decisions only _after_ Local-Pref and AS-PATH considerations), and
even if (b) only a very small number (about 10) of ASes are "early
adopters" that initially deploy S*BGP.

Other economic levers (e.g. "the benefits of security") are
complementary, and can only aid in driving S*BGP deployment.

Our model assumes that ISPs have incentives to increase the volume of
customer traffic that they transit because "the dominant form of
pricing" in the Internet is based on traffic volumes sent, that is
95/5 percentile pricing:

http://drpeering.net/AskDrPeering/blog/articles/Ask_DrPeering/Entries/2011/4/29_The_Origins_of_95_5.html

Thus, the more traffic (at the 95 percentile) that an ISP transits for
its customer, the more they can charge that customer, and thus the
more revenue they earn.

Of course, this is not the case for *every* ISP: some ISPs may not use
95/5 percentile pricing at all, some ISPs may actually be losing money
by providing Internet transit, and are instead earning all their
revenue from other sources (e.g. IPTV, VPN, advertising, etc.), and
moreover, content providers and residential ISPs are connecting
directly more often, thus circumventing the charges of provider ISPs.
 However, major ISPs are still needed to reach most destinations, and
smaller ISPs have a choice between multiple providers:

http://www.peeringdb.com/
http://valas.gtnoise.net/lib/exe/fetch.php?media=comm083-valancius.pdf

The fact that transit service prices are plummeting is, amongst other
things, evidence of the fierce competition between ISPs over customer
traffic.  The key point of our incremental deployment strategy is to
give ISPs one more dimension along which they can compete; namely, the
ability to provide secure routes to their customers. This point is
still valid as long as _most_ ISPs earn _some_ of their revenue from
transiting customer traffic.  The existence of services like Guavus,
suggest that for many ISPs, this is indeed the case:

http://www.guavus.com/solutions/tiered-pricing

Point 2: "The security threat model is unrealistic and misguided"

Our paper does not present a security threat model at all. We do not
present a new security solution. We do not deal with the question of
whether or not S*BGP should be deployed at all, which specific
protocol (e.g. SBGP,soBGP, etc) should be deployed, or which security
guarantees should be provided. This is the subject of many previous
works. From Section 2.1: "Because our study is indifferent to attacks
and adversaries, it applies equally to each of these protocols [i.e.
SBGP, soBGP]."

As explained above, we focus only on the question "Given that we want
as many ASes as possible to adopt S*BGP, what sort of incremental
deployment strategy should we use?" Thus, we are simply trying to
maximize the number of ASes that deploy S*BGP.

Point 3: "The simulations are questionable."

>From Section 8: "The wide range of parameters involved in modeling
S*BGP deployment means that our model cannot be predictive of S*BGP
deployment in practice. Instead, our model was designed to (a) capture
a few of the most crucial issues that might drive S*BGP deployment,
while (b) taking the approach that simplicity is preferable to
complexity."

Because ASes are unwilling to divulge information about routing
policies, peering agreements, etc, every study of interdomain routing
must contend with a dearth of ground truth with respect to AS-level
topology, routing policies, and traffic matrices.  We preformed
extensive simulations to deal with this lack of ground truth. Please
see Section 8 of our paper for detailed discussion about these issues.
 Here I'll address Randy's specific criticisms with direct quotes from
our paper:

Randy: "The paper also completely ignores the rise of the content providers as
described so well in SIGCOMM 2010 by Labovitz et alia[2] It is not
clear how to ?fix? the economic model, especially as[3] says you can
not do so with rigor.  Once one starts, e.g. the paper may lack
Tier-N peering richness which is believed to be at the edges, we have
bought into the game for which there is no clear end."

Section 6.8.1: "Published AS-level topologies are known to have poor
visibility into peering links at the edge of the AS-level topology
[31]. This is particularly problematic for CPs,
because they peer with many other ASes to cut down costs of delivering
content [14] .. Thus, for sensitivity analysis, we created an
augmented AS graph with ... additional peering edges from the five
Content Providers."

For more details on this graph, see Appendix D "AS graph Sensitivity
analysis".   Also, based on Labovitz's paper, we ran simulations where
the content providers were assumed to source a vast majority (up to
50%) of total Internet traffic (as discussed in Section 3.1 and
6.8.1).  Please see Section 6.8.2 to see how these assumptions
affected our results.

Randy: "The paper's simulations really should be shown not to rely on the
popular but highly problematic Gao-Rexford model of inter-provider
relationships, that providers prefer customers over peers (in fact, a
number of global Tier-1 providers have preferred peers for decades), and
that relationships are valley free, which also has significant
exceptions.  Yet these invalid assumptions may underpin the simulation
results."

Section 8.3: "In practice,... the local routing policies used by each
AS, ... are arbitrary and not publicly known. Thus, we use a standard
model of routing policies (Appendix A) based on business relationship
and path length [16, 6]."

Here we'll interject to say that while there are definitely examples
that lie outside this
model (e.g. ASes the prefer peer routes over provider routes), it
currently remains the only general model we have, to date, of
interdomain routing.  As such, we note in Section 8.3:

"Routing policies are likely to impact our results by determining (a)
AS path lengths (longer AS paths mean it is harder to secure routes),
and (b) tiebreak set size (Section 6.6). For example, we speculate
that considering shortest path routing policy would lead to overly
optimistic results; shortest-path routing certainly leads to shorter
AS paths, and possibly also to larger tiebreak sets."

Thus, while we cannot hope to accurately model every aspect of
interdomain routing, nor predict how S*BGP deployment will proceed in
practice, we believe that ISP competition over customer traffic is a
significant economic lever for driving global S*BGP deployment.

Sincerely,
Sharon Goldberg and Michael Schapira

-- 
Sharon Goldberg
Assistant Professor, Computer Science, Boston University
http://www.cs.bu.edu/~goldbe


On Sun, Sep 4, 2011 at 6:02 AM, Randy Bush <randy at psg.com> wrote:
> [ http://archive.psg.com/110904.broadside.html ]
>
> ? ? ? ?Do Not Complicate Routing Security with Voodoo Economics
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?a broadside
>
> A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and
> Goldberg[1] drew a lot of 'discussion' from the floor. ?But that
> discussion missed significant problems with this work. ?I raise this
> because of fear that uncritical acceptance of this work will be used as
> the basis for others' work, or worse, misguided public policy.
> ?o The ISP economic and incentive model is overly naive to the point of
> ? being misleading,
> ?o The security threat model is unrealistic and misguided, and
> ?o The simulations are questionable.
>
> Basic ISP economics are quite different from those described by the
> authors. ?Above the tail links to paying customers, the expenses of
> inter-provider traffic are often higher than the income, thanks to the
> telcos' race to the bottom. ?In this counter-intuitive world, transit
> can often be cheaper than peering. ?I.e. history shows that in the rare
> cases where providers have been inclined to such games, they usually
> shed traffic not stole it, the opposite of what the paper presumes. ?The
> paper also completely ignores the rise of the content providers as
> described so well in SIGCOMM 2010 by Labovitz et alia[2]
>
> It is not clear how to ?fix? the economic model, especially as[3] says
> you can not do so with rigor. ?Once one starts, e.g. the paper may lack
> Tier-N peering richness which is believed to be at the edges, we have
> bought into the game for which there is no clear end.
>
> But this is irrelevant, what will motivate deployment of BGP security is
> not provider traffic-shifting. ?BGP security is, as its name indicates,
> about security, preventing data stealing (think banking
> transactions[4]), keeping miscreants from originating address space of
> others (think YouTube incident) or as attack/spam sources, etc.
>
> The largest obstacle to deployment of BGP security is that the
> technology being deployed, RPKI-based origin validation and later
> BGPsec, are based on an X.509 certificate hierarchy, the RPKI. ?This
> radically changes the current inter-ISP web of trust model to one having
> ISPs' routing at the mercy of the Regional Internet Registries (RIRs).
> Will the benefits of security - no more YouTube incidents, etc. - be
> perceived as worth having one's routing at the whim of an
> non-operational administrative monopoly? ?Perhaps this is the real
> economic game here, and will cause a change in the relationship between
> the operators and the RIR cartel.
>
> The paper's simulations really should be shown not to rely on the
> popular but highly problematic3 Gao-Rexford model of inter-provider
> relationships, that providers prefer customers over peers (in fact, a
> number of global Tier-1 providers have preferred peers for decades), and
> that relationships are valley free, which also has significant
> exceptions. ?Yet these invalid assumptions may underpin the simulation
> results.
>
> ---
>
> Randy Bush <randy at psg.com>
> Dubrovnik, ?2011.9.4
>
> [1] P. Gill, M. Schapira, and S. Goldberg, Let the Market Drive
> Deployment: A Strategy for Transitioning to BGP Security, SIGCOMM 2011,
> August 2011.
> http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p14.pdf
>
> [2] [1] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and
> F. Jahanian, ?Internet inter-domain traffic,? in SIGCOMM '10:
> Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010.
>
> [3] M. Roughan, W. Willinger, O. Maennel, D. Perouli, and R. Bush, 10
> Lessons from 10 Years of Measuring and Modeling the Internet's
> Autonomous Systems, IEEE Journal on Selected Areas in Communications,
> Vol. 29, No. 9, pp. 1-12, Oct. 2011.
> https://archive.psg.com/111000.TenLessons.pdf
>
> [4] A. Pilosov, T. Kapela. Stealing The Internet An Internet-Scale Man
> In The Middle Attack, Defcon 16, August, 2008.
> http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf
>
>



From blake at pfankuch.me  Sun Sep  4 15:18:42 2011
From: blake at pfankuch.me (Blake T. Pfankuch)
Date: Sun, 4 Sep 2011 20:18:42 +0000
Subject: Tampa small colo recs?
In-Reply-To: <527113ec-94b8-4bc5-a246-88c7bffa894b@mail.gitflorida.com>
References: <24261253.402.1314924618891.JavaMail.root@benjamin.baylink.com>
 <527113ec-94b8-4bc5-a246-88c7bffa894b@mail.gitflorida.com>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C8436976BF8@SHSBS.shenrons-house.local>

I've managed a few servers from sago, they have a great network and quick support responses as needed.  Hostway not had quite as good of responses from them, and some weird network issues.  However that was a few years back.

-----Original Message-----
From: James P. Ashton [mailto:james at gitflorida.com] 
Sent: Sunday, September 04, 2011 11:31 AM
To: Jay Ashworth
Cc: NANOG
Subject: Re: Tampa small colo recs?

Jay,
 I recommend E Solutions, But I am biased (I build the network).

 But also in town we have,
 
 Switch and Data
 Qwest
 Peak 10
 Sago Networks
 Hostway


I know them all pretty well, so if you have any questions, fire away.


James



----- Original Message -----
Anyone got any opinions on small colo rental in Tampa; anywhere from 8RU to a half-rack?  I'd prefer at least one tier 1 uplink, and at least 1 tier 2, dial-a-yield 100Base, and 24 hour access, but I'm flexible.  Pinellas County is also fine.

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      http://photo.imageinc.us             +1 727 647 1274



From web at typo.org  Sun Sep  4 15:45:29 2011
From: web at typo.org (Wayne E Bouchard)
Date: Sun, 4 Sep 2011 13:45:29 -0700
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <871uvw8tk6.fsf@mid.deneb.enyo.de>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
 <20110903195746.GA83947@typo.org> <871uvw8tk6.fsf@mid.deneb.enyo.de>
Message-ID: <20110904204529.GA89120@typo.org>

On Sun, Sep 04, 2011 at 12:56:25PM +0200, Florian Weimer wrote:
> * Wayne E. Bouchard:
> 
> > the users will screw themselves by flooding their uplinks in which
> > case they will know what they've done to themselves and will largely
> > accept the problems for the durration
> 
> With shared media networks (or insufficient backhaul capacities),
> congestion affects more than just the customer causing it.

Okay, so to state the obvious for those who missed the point...

The congestion will either be directly in front of user because
they're flooding their uplink or towards the destination (beit a
single central network or a set of storage clusters housed at, say, 6
different locations off 3 different providers.) It is very hard, in my
experience, for something like this to congest the general
network. The congestion occurs where either bandwidth drops off--such
as with the edge dialup, DSL, or cable modem link--or traffic
concentrates. Just like someone broadcasting a concert. Either you as
a user can't receive the feed because your pipe isn't big enough for
the stream or the network/servers sourcing the traffic get bogged down
and, generally, the rest of the folks out there not watching the feed
don't know there's a problem. If you're not participating in that
traffic, the likelihood that you'll be impacted by it drops off
dramatically. Yes, the PTP model will behave a little differently but
in that case, you're more likely to see individual users having issues
(either hosts or clients) rather than everyone as a whole and it
*still* won't impact the broader network. The more "central clusters"
you add, the more the traffic pattern will start to behave like the
PTP scenario and the lower the probabilty of broad impact.

My point was simply that if you think it through, there really isn't
any reason to be concerned about it. (It can't be any worse than the
Jackson verdict or the Pope and, as far as I recall, since we're all
still here, I don't believe the world ended when those events
happened.)

-Wayne

---
Wayne Bouchard
web at typo.org
Network Dude
http://www.typo.org/~web/



From Valdis.Kletnieks at vt.edu  Sun Sep  4 16:31:41 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 04 Sep 2011 17:31:41 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: Your message of "Sun, 04 Sep 2011 16:16:45 EDT."
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
Message-ID: <15500.1315171901@turing-police.cc.vt.edu>

On Sun, 04 Sep 2011 16:16:45 EDT, Sharon Goldberg said:

> Point 2: "The security threat model is unrealistic and misguided"
> 
> Our paper does not present a security threat model at all. We do not
> present a new security solution.

Unfortunately for all concerned, it's going to be *perceived* as a security
solution, and people will invent a threat model to match.  Anybody who thinks
otherwise is invited to compare what people *think* the meaning of the little
padlock their browser displays versus what the padlock *actually* means, or the
difference between what people *think* SPF does for their email versus what it
*actually* does.


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

From andy-nanog at bash.sh  Sun Sep  4 16:34:08 2011
From: andy-nanog at bash.sh (Andrew Mulholland)
Date: Sun, 4 Sep 2011 22:34:08 +0100
Subject: anyone from netnames / ascio on list?
Message-ID: <CAK80Fn+9HRCc=OzebfsSf6Kc-kc6PghN9O6Jo_poYs7EKy_OPw@mail.gmail.com>

Hi

Seems Netnames / Ascio have been compromised, resulting in DNS servers  for
a number of their customers (telegraph.co.uk, acer.com, betfair.com ,
theregister.co.uk etc) being changed, and the sites being redirected to an
hacked page.

list of domains affected here:
http://zone-h.org/archive/notifier=turkguvenligi.info

Seems there's no 24/7 contact for them..

e.g.

   Domain Name: ACER.COM
   Registrar: ASCIO TECHNOLOGIES, INC.
   Whois Server: whois.ascio.com
   Referral URL: http://www.ascio.com
   Name Server: NS1.YUMURTAKABUGU.COM
   Name Server: NS2.YUMURTAKABUGU.COM
   Status: ok
   Updated Date: 04-sep-2011
   Creation Date: 07-sep-1994
   Expiration Date: 17-may-2019




If anyone on list works for them, please raise the alarm internally, and/or
start responding to your customers!


thanks



Andrew


From neil at domino.org  Sun Sep  4 16:39:43 2011
From: neil at domino.org (Neil J. McRae)
Date: Sun, 4 Sep 2011 21:39:43 +0000
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
References: <m2mxek1v78.wl%randy@psg.com>,
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
Message-ID: <5C16B084-BAFA-4636-943C-97DA5E21711F@domino.org>


On 4 Sep 2011, at 21:17, "Sharon Goldberg" <goldbe at cs.bu.edu>  wrote:

thanks for responding you paper is interesting,

> Thus, while we cannot hope to accurately model every aspect of
> interdomain routing, nor predict how S*BGP deployment will proceed in
> practice, we believe that ISP competition over customer traffic is a
> significant economic lever for driving global S*BGP deployment.

 If you cannot accurately model every aspect of interdomain routing - why is that? :)

Then how can you be sure that a single stock in this model can be so influential? "significant" I think one could almost argue the opposite also or make the same case about nearly any feature in a transit product! If i stop offering community based filtering- I'd probably see revenue decline!

Yes some features in a product set drive revenue - thats all you are really saying which is fine but we have alot of features people want in the network and what would be a more useful paper would be why this one might drive more revenue growth than the others that are all fighting development prioritisation - - - which isnt clear to me in your paper.

All this paper does is confuse (mislead?) people that SBGP might have a big pot of gold attached which is doubtful in my view (interdomain routing is very complex) and the point Randy made.

Neil



From jsw at inconcepts.biz  Sun Sep  4 19:35:32 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Sun, 4 Sep 2011 20:35:32 -0400
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <20110904204529.GA89120@typo.org>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
 <20110903195746.GA83947@typo.org>
 <871uvw8tk6.fsf@mid.deneb.enyo.de>
 <20110904204529.GA89120@typo.org>
Message-ID: <CAPWAtbJON_BuHZwFi9r9fVjvC9pJm2D4q0eEXw7NycbU_grkUg@mail.gmail.com>

On Sun, Sep 4, 2011 at 4:45 PM, Wayne E Bouchard <web at typo.org> wrote:
> Okay, so to state the obvious for those who missed the point...
>
> The congestion will either be directly in front of user because
> they're flooding their uplink or towards the destination (beit a
> single central network or a set of storage clusters housed at, say, 6
> different locations off 3 different providers.) It is very hard, in my

If scaling up Internet bandwidth were the hardest thing about
deploying SaaS / "cloud" services, don't you think transit vendors
would suddenly be more profitable than EMC and friends?  It should be
obvious to you, and everyone else, that datacenter Internet
connectivity is a trivial concern compared to everything else that
goes into these platforms.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts



From patrick at ianai.net  Sun Sep  4 20:18:33 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 5 Sep 2011 09:18:33 +0800
Subject: Preferring peers over customers [was: Do Not Complicate Routing
 Security with Voodoo Economics]
In-Reply-To: <m2mxekyt05.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
 <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>
 <m2wrdoz9w0.wl%randy@psg.com>
 <CAJL_ZMP870eE5TGff6DCiRaQKbJgMpFtmq4Jg-k97GdsQzoAaw@mail.gmail.com>
 <m2sjocyyu8.wl%randy@psg.com>
 <CAJL_ZMPc70qv7=pKMOJmsxAnjGypZ-yE-02TP0VLYp=+mKhPOw@mail.gmail.com>
 <m2mxekyt05.wl%randy@psg.com>
Message-ID: <0C2D5B74-3C6D-4005-B1D1-26AACBFBD15C@ianai.net>

On Sep 5, 2011, at 4:03, Randy Bush <randy at psg.com> wrote:

>> Because routing to peers as a policy instead of customer as a matter
>> of policy, outside of corner cases make logical sence.
> 
> welcome to the internet, it does not always make logical sense at first
> glance.
> 
> the myth in academia that customers are always preferred over peers
> comes from about '96 when vaf complained to asp and me (and we moved it
> to nanog for general discussion) that we were not announcing an
> identical prefix list to him at east and west.  the reason turned out to
> be that, on one of the routers, a peer path was shorter in some cases,
> so we had chosen it.  we were perfectly happy with that but vaf was not,
> and he ran the larger network so won the discussion.

The "myth" comes from engineers at large networks saying it is so.

We could also have a small miscommunication here.  For example, if a customer were multi-homed to a peer, and the customer and peer were on the same router, and the customer had prepended a single time (making the AS path equal), by your original statement you would have sent traffic to the peer.  Most people would find that silly.  (And please do not point out customers and peers do not connect to the same router, this is a simple example for illustrative purposes.)

However, the statement you make above says that you preferred the peer because "the path was shorter".  You do not specify if that is IGP distance, AS path length, or some other metric, but it implies if the path were equal, you would prefer the customer - especially since the customer was preferred on the other coast.  So there may be assumptions on one side or the other that are not clear which are causing confusion.


Either way, this seems operationally relevant.

I would like the large networks of the world to state whether they prefer their customer routes over peer routes, and how.  For instance, does $NETWORK prefer customers only when the AS path is the same, or all the time no matter what?

Let's leave out corner cases - e.g. If a customer asks you, via communities or otherwise, to do something different.  This is a poll of default, vanilla configurations.

Please send them to me, or the list, with this subject line.  I shall compile the results and post them somewhere public.  If you cannot speak for your company, I will keep your name private.

Thanx.

-- 
TTFN
patrick




From freedman at freedman.net  Sun Sep  4 20:54:27 2011
From: freedman at freedman.net (Avi Freedman)
Date: Sun, 4 Sep 2011 21:54:27 -0400 (EDT)
Subject: Preferring peers over customers [was: Do Not Complicate Routing
Message-ID: <20110905015427.C5AB458000085@freedman.net>


Forgive my potential lack of understanding; perhaps BGP behavior has
changed or the way people use it has but my understanding is -

Since BGP is used in almost all circumstances in a mode where only
the best path to a prefix can be re-advertised, only one of the
peer or customer path can be used by a 3rd network, and if the peer 
path is used for a prefix for a customer, then a transit provider can't 
easily provide transit for that prefix back to the customer without 
serious routing shennanigans.

So isn't it in practice the case that if a provider prefers a peer to 
connect to a customer instead of the direct customer link, that:

1) The provider will lose the ability to bill for traffic delivered
   to that customer, and

2) The customer will lose redundancy of inbound path, and

3) The customer will almost certainly notice and have the chance to complain

I would expect that most cases of a provider (for a given prefix, which
is almost always a caveat here) preferring a peer to get to a customer 
would be something the customer had some input into via communities,
or by calling and bitching if the provider doesn't have a rich 
communities set or the ability to set them.

One thing one hears every so often (in cycles) is the pressure for
emerging Tier1/2 aspirants to not peer with customers of larger potential
peers who are also providers, to preserve revenue models of said larger 
peers, but that's a different situation.

And -

If applied to customers of customers, I'd think it'd revert to the cases
above.  Network X has customer Y and buys from provider C.  If C prefers
a peer to get to Y (this is all for a given prefix) and it wasn't due 
to policy expressed by X or Y via communities or request of provider C 
by X, then eventually someone's going to figure out that the backup path 
that presumably X and Y think is being paid for, isn't.  Then the people 
that pay money will bitch and action shoudl be taken.

Consistent announcements by a global network to its peers for the prefixes
of a given customer is another level of wonkiness that customers can
definitely influence by doing strange per-prefix communities settings,
but that again is probably another topic as it'd be presumably driven by 
the customer's actions, not the provider's traffic-engineering goals.

Or am I confused here on one, more, or all points?  Certainly possible.

One thing I think everyone can agree on - academic models of the ways 
that people combine routers, money, fiber, contracts, and policy almost
never catch up to the creativity, poltiics, policy, bugs, and stupidities 
that combine to make the Internet as wonderful as it is.

Avi

> On Sep 5, 2011, at 4:03, Randy Bush <randy at psg.com> wrote:
> 
> >> Because routing to peers as a policy instead of customer as a matter
> >> of policy, outside of corner cases make logical sence.
> >
> > welcome to the internet, it does not always make logical sense at first
> > glance.
> >
> > the myth in academia that customers are always preferred over peers
> > comes from about '96 when vaf complained to asp and me (and we moved it
> > to nanog for general discussion) that we were not announcing an
> > identical prefix list to him at east and west.  the reason turned out to
> > be that, on one of the routers, a peer path was shorter in some cases,
> > so we had chosen it.  we were perfectly happy with that but vaf was not,
> > and he ran the larger network so won the discussion.
> 
> The "myth" comes from engineers at large networks saying it is so.
> 
> We could also have a small miscommunication here.  For example, if a custome=
> r were multi-homed to a peer, and the customer and peer were on the same rou=
> ter, and the customer had prepended a single time (making the AS path equal)=
> , by your original statement you would have sent traffic to the peer.  Most p=
> eople would find that silly.  (And please do not point out customers and pee=
> rs do not connect to the same router, this is a simple example for illustrat=
> ive purposes.)
> 
> However, the statement you make above says that you preferred the peer becau=
> se "the path was shorter".  You do not specify if that is IGP distance, AS p=
> ath length, or some other metric, but it implies if the path were equal, you=
>  would prefer the customer - especially since the customer was preferred on t=
> he other coast.  So there may be assumptions on one side or the other that a=
> re not clear which are causing confusion.
> 
> Either way, this seems operationally relevant.
> 
> I would like the large networks of the world to state whether they prefer th=
> eir customer routes over peer routes, and how.  For instance, does $NETWORK p=
> refer customers only when the AS path is the same, or all the time no matter=
>  what?
> 
> Let's leave out corner cases - e.g. If a customer asks you, via communities o=
> r otherwise, to do something different.  This is a poll of default, vanilla c=
> onfigurations.
> 
> Please send them to me, or the list, with this subject line.  I shall compil=
> e the results and post them somewhere public.  If you cannot speak for your c=
> ompany, I will keep your name private.
> 
> Thanx.
> 
> --
> TTFN
> patrick




From ms7 at CS.Princeton.EDU  Sun Sep  4 23:04:35 2011
From: ms7 at CS.Princeton.EDU (Michael Schapira)
Date: Mon, 05 Sep 2011 00:04:35 -0400 (EDT)
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <1be2e3ab-f433-405f-9216-e958d4160b58@suckerpunch-mbx-0.CS.Princeton.EDU>
Message-ID: <9e65c1ce-b212-4471-ae35-63a95b5c9fdb@suckerpunch-mbx-0.CS.Princeton.EDU>

On Sun, Sep 4, 2011 at 5:39 PM Neil J. McRae neil at domino.org wrote:

> ... one could almost argue the opposite also or make the same case about nearly any feature in a transit product! If i stop offering
> community based filtering- I'd probably see revenue decline!
 
> Yes some features in a product set drive revenue - thats all you are really saying which is fine but we have alot of features people want in
> the network and what would be a more useful paper would be why this one might drive more revenue growth than the others that are all fighting
> development prioritisation - - - which isnt clear to me in your paper."



One crucial way in which S*BGP differs from other features is that ASes which deploy S*BGP *must* use their ability to validate paths to inform route selection (otherwise, adding security to BGP makes no sense). Therefore, S*BGP is bound to affect how traffic flows on the Internet. Our work is about harnessing this observation to drive S*BGP deployment.
 
We consider the case that security plays a very small role in the BGP decision process and, in particular, that security considerations come *after* the Local-Pref and AS-PATH length steps in the BGP decision process. We give evidence that even in this case a small set of early adopters is sufficient to transition a large fraction of the Internet to S*BGP.
 
 

 



From rdobbins at arbor.net  Sun Sep  4 23:55:29 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 5 Sep 2011 04:55:29 +0000
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <9e65c1ce-b212-4471-ae35-63a95b5c9fdb@suckerpunch-mbx-0.CS.Princeton.EDU>
References: <9e65c1ce-b212-4471-ae35-63a95b5c9fdb@suckerpunch-mbx-0.CS.Princeton.EDU>
Message-ID: <830078CE-831C-4C61-9845-E8B5ABE5C1E5@arbor.net>

On Sep 5, 2011, at 11:04 AM, Michael Schapira wrote:

> One crucial way in which S*BGP differs from other features is that ASes which deploy S*BGP *must* use their ability to validate paths to inform route selection (otherwise, adding security to BGP makes no sense).

Origin validation <> path validation.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From rdobbins at arbor.net  Mon Sep  5 00:06:13 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 5 Sep 2011 05:06:13 +0000
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <830078CE-831C-4C61-9845-E8B5ABE5C1E5@arbor.net>
References: <9e65c1ce-b212-4471-ae35-63a95b5c9fdb@suckerpunch-mbx-0.CS.Princeton.EDU>
 <830078CE-831C-4C61-9845-E8B5ABE5C1E5@arbor.net>
Message-ID: <25E64BD8-A3EB-450E-BEEF-10D2F04EB89F@arbor.net>

On Sep 5, 2011, at 11:55 AM, Dobbins, Roland wrote:

> Origin validation <> path validation.

Rather, that should read, 'Origin/path validation <> origin/path enforcement'.

The idea of origin validation is a simple one.  The idea of path validation isn't to determine the 'correctness' or 'desirability' of a particular AS-path, but rather to determine the *validity* (or at least the *feasability*) of a given AS-path.  

Origin validation is relatively easy compared to AS-path validation, and origin validation is the most important function of S*BGP.  And in a world with universal origin and AS-path validation, how is there some economic advantage to be had by deploying S*BGP?  

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From trelane at trelane.net  Mon Sep  5 01:15:38 2011
From: trelane at trelane.net (Andrew Kirch)
Date: Mon, 05 Sep 2011 02:15:38 -0400
Subject: anyone from netnames / ascio on list?
In-Reply-To: <CAK80Fn+9HRCc=OzebfsSf6Kc-kc6PghN9O6Jo_poYs7EKy_OPw@mail.gmail.com>
References: <CAK80Fn+9HRCc=OzebfsSf6Kc-kc6PghN9O6Jo_poYs7EKy_OPw@mail.gmail.com>
Message-ID: <4E64690A.6080402@trelane.net>

On 9/4/2011 5:34 PM, Andrew Mulholland wrote:

I'm not seeing the problem here?
Registrant:
  Gateway, Inc. (GATEW95532)
  7565 Irvine Center Drive

  Irvine, CA, 92618-2930
  US

  Domain name: acer.com

Technical contact:
  Administrator, Domain (DA73355)
  NetNames Hostmaster
  3rd Floor Prospero House
  241 Borough High Street
  Borough, London, SE1 1GA
  GB
  corporate-services at netnames.com
  +44.2070159370 Fax: +44.2070159375

Administrative contact:
  Wagner, Michael (MW47730)
  Gateway, Inc.
  7565 Irvine Center Drive

  Irvine, CA, 92618-2930
  US
  hostadmin at gateway.com
  +1.8008462042 Fax: +1.0000000000

Record created:           2010-10-04 17:54:28
Record last updated:      2011-09-04 22:24:04
Record expires:           2019-05-17 01:00:00

Domain servers in listed order:
  ns1.acer.com (NS1ACERC38319)
  ns2.acer.com (NS2ACERC59089)
  ns3.acer.com (NS3ACERC70649)
  ns4.acer.com (NS4ACERC28541)
  ns5.acer.com (NS5ACERC49101)
  ns6.acer.com (NS6ACERC86343)




From andy-nanog at bash.sh  Mon Sep  5 01:19:01 2011
From: andy-nanog at bash.sh (Andrew Mulholland)
Date: Mon, 5 Sep 2011 07:19:01 +0100
Subject: anyone from netnames / ascio on list?
In-Reply-To: <4E64690A.6080402@trelane.net>
References: <CAK80Fn+9HRCc=OzebfsSf6Kc-kc6PghN9O6Jo_poYs7EKy_OPw@mail.gmail.com>
 <4E64690A.6080402@trelane.net>
Message-ID: <CAK80FnLq8-M=GmoQf72Hg8vk4Tjf2eEg_Xx32WCgc3teFcNxug@mail.gmail.com>

It was resolved last night.

http://www.guardian.co.uk/technology/2011/sep/05/dns-hackers-telegraph-interview

Andrew



On Mon, Sep 5, 2011 at 7:15 AM, Andrew Kirch <trelane at trelane.net> wrote:

> On 9/4/2011 5:34 PM, Andrew Mulholland wrote:
>
> I'm not seeing the problem here?
> Registrant:
>  Gateway, Inc. (GATEW95532)
>  7565 Irvine Center Drive
>
>  Irvine, CA, 92618-2930
>  US
>
>  Domain name: acer.com
>
> Technical contact:
>  Administrator, Domain (DA73355)
>  NetNames Hostmaster
>  3rd Floor Prospero House
>  241 Borough High Street
>  Borough, London, SE1 1GA
>  GB
>  corporate-services at netnames.com
>  +44.2070159370 Fax: +44.2070159375
>
> Administrative contact:
>  Wagner, Michael (MW47730)
>  Gateway, Inc.
>  7565 Irvine Center Drive
>
>  Irvine, CA, 92618-2930
>  US
>  hostadmin at gateway.com
>  +1.8008462042 Fax: +1.0000000000
>
> Record created:           2010-10-04 17:54:28
> Record last updated:      2011-09-04 22:24:04
> Record expires:           2019-05-17 01:00:00
>
> Domain servers in listed order:
>  ns1.acer.com (NS1ACERC38319)
>  ns2.acer.com (NS2ACERC59089)
>  ns3.acer.com (NS3ACERC70649)
>  ns4.acer.com (NS4ACERC28541)
>  ns5.acer.com (NS5ACERC49101)
>  ns6.acer.com (NS6ACERC86343)
>
>
>


From randy at psg.com  Mon Sep  5 03:02:17 2011
From: randy at psg.com (Randy Bush)
Date: Mon, 05 Sep 2011 10:02:17 +0200
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <9e65c1ce-b212-4471-ae35-63a95b5c9fdb@suckerpunch-mbx-0.CS.Princeton.EDU>
References: <1be2e3ab-f433-405f-9216-e958d4160b58@suckerpunch-mbx-0.CS.Princeton.EDU>
 <9e65c1ce-b212-4471-ae35-63a95b5c9fdb@suckerpunch-mbx-0.CS.Princeton.EDU>
Message-ID: <m2ehzvzaba.wl%randy@psg.com>

> One crucial way in which S*BGP differs from other features is that
> ASes which deploy S*BGP *must* use their ability to validate paths to
> inform route selection

not really.  you may wish to read the bgpsec docs, in particular
draft-ietf-sidr-bgpsec-ops

randy



From aftab.siddiqui at gmail.com  Mon Sep  5 03:38:31 2011
From: aftab.siddiqui at gmail.com (Aftab Siddiqui)
Date: Mon, 5 Sep 2011 13:38:31 +0500
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <1F5AFB0F-190E-498C-9D37-84433ADBE599@CS.Princeton.EDU>
References: <CA895773.5FFD%neil@domino.org>
 <5B1F5300-3752-4028-80A4-65F3B8AB340E@cs.princeton.edu>
 <305E552C-B38C-477A-A1C0-91CF59BEA262@domino.org>
 <1F5AFB0F-190E-498C-9D37-84433ADBE599@CS.Princeton.EDU>
Message-ID: <CAK5YLgcF_mWbkotXqtE23TouKO7ngaEO+7J+H49Dp8k79NDtvg@mail.gmail.com>

Hi Jen,


> Thanks for the suggestion!  Yes, I would encourage interested people to
> contact me.  We won't be able to put everyone on the working group (in the
> interest of having a small enough group to make progress), but we are very
> interested in having people who can offer their expertise, feedback, and
> advice throughout the process...
>
> Well, Why not everyone? What would be the criteria to add people into the
working group? IETF or any RIR doesn't stop anyone from joining any WG.
Every member of the WG should be treated as potential contributor.


Regards,

Aftab A. Siddiqui.


From bicknell at ufp.org  Mon Sep  5 07:47:24 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 5 Sep 2011 05:47:24 -0700
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com>
Message-ID: <20110905124724.GA8292@ussenterprise.ufp.org>

In a message written on Sun, Sep 04, 2011 at 04:16:45PM -0400, Sharon Goldberg wrote:
> An ISP might deploy S*BGP in order to increase the volume of traffic
> that it transits for its customers.

I think this phrase summarizes the problem with this argument nicely.

If, as an ISP, deploying a "secure" routing protocol changes my
traffic positively or negatively something is wrong.  Securing the
routing system should not alter the routing system.

I'm afraid as long as it does this work has an uphill battle.

-- 
       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/20110905/61919f1a/attachment.bin>

From owen at delong.com  Mon Sep  5 09:18:28 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 5 Sep 2011 07:18:28 -0700
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <20110905124724.GA8292@ussenterprise.ufp.org>
References: <m2mxek1v78.wl%randy@psg.com>
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com> <20110905124724.GA8292@ussenterprise.ufp.org>
Message-ID: <C2BE4BC4-27AA-4171-802D-C863CDFB69D9@delong.com>


On Sep 5, 2011, at 5:47 AM, Leo Bicknell wrote:

> In a message written on Sun, Sep 04, 2011 at 04:16:45PM -0400, Sharon Goldberg wrote:
>> An ISP might deploy S*BGP in order to increase the volume of traffic
>> that it transits for its customers.
> 
> I think this phrase summarizes the problem with this argument nicely.
> 
> If, as an ISP, deploying a "secure" routing protocol changes my
> traffic positively or negatively something is wrong.  Securing the
> routing system should not alter the routing system.
> 
> I'm afraid as long as it does this work has an uphill battle.
> 

One could argue that rejecting routes which you previously had no way to
know you should reject will inherently alter the routing system and that this
is probably a good thing.

Owen




From jrex at CS.Princeton.EDU  Mon Sep  5 09:24:42 2011
From: jrex at CS.Princeton.EDU (Jennifer Rexford)
Date: Mon, 5 Sep 2011 10:24:42 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <C2BE4BC4-27AA-4171-802D-C863CDFB69D9@delong.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com> <20110905124724.GA8292@ussenterprise.ufp.org>
 <C2BE4BC4-27AA-4171-802D-C863CDFB69D9@delong.com>
Message-ID: <D3BB8EEF-584C-4AB6-8CAA-FBE51FC9DB61@cs.princeton.edu>


> 
> One could argue that rejecting routes which you previously had no way to
> know you should reject will inherently alter the routing system and that this
> is probably a good thing.

Good point.  Also, "tie breaking" in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic "positively or negatively" -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome...

-- Jen


From ms7 at CS.Princeton.EDU  Mon Sep  5 09:25:50 2011
From: ms7 at CS.Princeton.EDU (Michael Schapira)
Date: Mon, 05 Sep 2011 10:25:50 -0400 (EDT)
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <f4d7e84a-6b20-44f5-9f4b-ff191344ed0b@suckerpunch-mbx-0.CS.Princeton.EDU>
Message-ID: <85957663-66de-4388-b2dd-d8512358beb7@suckerpunch-mbx-0.CS.Princeton.EDU>

On Sep 5, 2011, at 11:55 AM, Dobbins, Roland wrote:

> The idea of origin validation is a simple one.  The idea of path validation isn't to determine the 'correctness' or 'desirability' of a
> particular AS-path, but rather to determine the *validity* (or at least the *feasability*) of a given AS-path.


Sorry, I was misunderstood. To clarify, I was referring only to our work (http://www.cs.utoronto.ca/~phillipa/sbgpTrans.html), where security does play a small role in the route selection process (after LocalPref and AS-PATH length), and not to the BGPsec spec. The reason why we assume that security affects the route selection process is because otherwise, even an AS that deploys S*BGP, remains vulnerable to attacks. To see why, take a look at slides 10-13 of our NANOG presentation (http://www.cs.bu.edu/~goldbe/papers/Goldberg-TransitionToSBGP-NANOG.pdf, video available at http://www.cs.utoronto.ca/~phillipa/sbgpTrans.html). The basic idea is: if an AS prefers short paths over secure paths they'll be just as vulnerable to path-shortening attacks with and without S*BGP.



From jared at puck.nether.net  Mon Sep  5 09:26:18 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 5 Sep 2011 10:26:18 -0400
Subject: Preferring peers over customers [was: Do Not Complicate Routing
 Security with Voodoo Economics]
In-Reply-To: <0C2D5B74-3C6D-4005-B1D1-26AACBFBD15C@ianai.net>
References: <m2mxek1v78.wl%randy@psg.com>
 <28B746B9-4553-489A-80E6-4BA8E6CF0A8E@ianai.net>
 <1237165422-1315144392-cardhu_decombobulator_blackberry.rim.net-1842791679-@b27.c17.bise6.blackberry>
 <m2wrdoz9w0.wl%randy@psg.com>
 <CAJL_ZMP870eE5TGff6DCiRaQKbJgMpFtmq4Jg-k97GdsQzoAaw@mail.gmail.com>
 <m2sjocyyu8.wl%randy@psg.com>
 <CAJL_ZMPc70qv7=pKMOJmsxAnjGypZ-yE-02TP0VLYp=+mKhPOw@mail.gmail.com>
 <m2mxekyt05.wl%randy@psg.com>
 <0C2D5B74-3C6D-4005-B1D1-26AACBFBD15C@ianai.net>
Message-ID: <E21A87A4-DF33-48B8-9E31-ED11E4C89299@puck.nether.net>


On Sep 4, 2011, at 9:18 PM, Patrick W. Gilmore wrote:

> I would like the large networks of the world to state whether they prefer their customer routes over peer routes, and how.  For instance, does $NETWORK prefer customers only when the AS path is the same, or all the time no matter what?
> 
> Let's leave out corner cases - e.g. If a customer asks you, via communities or otherwise, to do something different.  This is a poll of default, vanilla configurations.
> 
> Please send them to me, or the list, with this subject line.  I shall compile the results and post them somewhere public.  If you cannot speak for your company, I will keep your name private.

The NTT network has a well documented local-pref policy that shows what is done.

You can review it on the website, including showing that the default local-preference is 120.

http://www.us.ntt.net/support/policy/routing.cfm

Having worked for small players that peered with other partners/networks in the past, not following a model of customer -> peer -> transit order of preference, you can create situations where someone unexpectedly is creating a traffic black hole.

It's not saying you can't build a better model, but this is fairly straightforward and provides expected results.  Your customer routes will always be propagated to your peers.  Having communities to allow the customer to change how their routes are propagated is valuable so they can 'choose their own adventure'.  If someone wants to not announce to another provider, that is their "fault" when traffic breaks.

- Jared


From owen at delong.com  Mon Sep  5 09:53:38 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 5 Sep 2011 07:53:38 -0700
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <D3BB8EEF-584C-4AB6-8CAA-FBE51FC9DB61@cs.princeton.edu>
References: <m2mxek1v78.wl%randy@psg.com>
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com> <20110905124724.GA8292@ussenterprise.ufp.org>
 <C2BE4BC4-27AA-4171-802D-C863CDFB69D9@delong.com>
 <D3BB8EEF-584C-4AB6-8CAA-FBE51FC9DB61@cs.princeton.edu>
Message-ID: <22122255-5F6E-4395-BFF7-007CE5FE8CA9@delong.com>


On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote:

> 
>> 
>> One could argue that rejecting routes which you previously had no way to
>> know you should reject will inherently alter the routing system and that this
>> is probably a good thing.
> 
> Good point.  Also, "tie breaking" in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic "positively or negatively" -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome...
> 
> -- Jen

This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases.

The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything.

Owen




From jmaimon at ttec.com  Mon Sep  5 10:36:17 2011
From: jmaimon at ttec.com (Joe Maimon)
Date: Mon, 05 Sep 2011 11:36:17 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <22122255-5F6E-4395-BFF7-007CE5FE8CA9@delong.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com> <20110905124724.GA8292@ussenterprise.ufp.org>
 <C2BE4BC4-27AA-4171-802D-C863CDFB69D9@delong.com>
 <D3BB8EEF-584C-4AB6-8CAA-FBE51FC9DB61@cs.princeton.edu>
 <22122255-5F6E-4395-BFF7-007CE5FE8CA9@delong.com>
Message-ID: <4E64EC71.9080704@ttec.com>



Owen DeLong wrote:
>
> On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote:
>
>>
>>>
>>> One could argue that rejecting routes which you previously had no way to
>>> know you should reject will inherently alter the routing system and that this
>>> is probably a good thing.
>>
>> Good point.  Also, "tie breaking" in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic "positively or negatively" -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome...
>>
>> -- Jen
>
> This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases.
>
> The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything.
>
> Owen
>


Except if you believe we have been lucky until now and security is all 
about the future where we may be less lucky.

What I would be interested in seeing is a discussion on whether any 
anti-competitive market distortion incentives exist for large providers 
in adopting secured BGP. We might be lucky there too.

Perhaps this will finally help solve the routing slot scalability 
problem. Might also jumpstart LISP. Which may put some more steam into 
v6. Welcome to the brave new internet.

Good for everyone, right?

Are you feeling lucky?


Joe



From feamster at cc.gatech.edu  Mon Sep  5 11:51:53 2011
From: feamster at cc.gatech.edu (Nick Feamster)
Date: Mon, 5 Sep 2011 12:51:53 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <4E64EC71.9080704@ttec.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com> <20110905124724.GA8292@ussenterprise.ufp.org>
 <C2BE4BC4-27AA-4171-802D-C863CDFB69D9@delong.com>
 <D3BB8EEF-584C-4AB6-8CAA-FBE51FC9DB61@cs.princeton.edu>
 <22122255-5F6E-4395-BFF7-007CE5FE8CA9@delong.com> <4E64EC71.9080704@ttec.com>
Message-ID: <61788FCE-4637-4D54-9096-F5F3346CD5DE@cc.gatech.edu>

Three thoughts on the thread so far.

1. I think Randy raises an interesting point about the complexity of contracts.  We had a paper in SIGCOMM this year on the increasing use of more complicated interconnection contracts (and, in particular, tiered pricing).  See Section 2 of our paper [1]:
http://www.gtnoise.net/papers/library/valancius-tiers.pdf
Some of us academics are trying to get more clued up on what providers actually do. :-)  [I may start a discussion on the pricing models in this paper in a separate thread later]

2. I question what fraction of routing decisions come down to a blind tiebreak---nearly all of them are likely to be driven by some other consideration (reliability, cost, etc.).  Our paper details a richer economic model by which ASes actually select paths, for example, but it's still unclear to me how coarse or fine-grained route selection really is in practice, and to what extent more complicated contracts have evolved.  I wonder how common "blind tiebreaking" is in BGP, in real networks; the approach in Sharon's paper definitely may overstate how common that is if route selection considerations commonly involve things that are not visible in the AS graph (e.g., traffic ratios, congestion, performance), but academics could really benefit from some more insight into how rich these decisions are in practice.  

3. I think the discussion on the list so far misses what I see as the central question about the economic assumptions in that paper.  The paper assumes that all destinations are equally valuable, which we know is not the case.  This implicitly (and perhaps mistakenly?) shifts the balance of power to tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., Google).  In practice, ISPs may be willing to spend significant amounts of money to reach certain destinations or content (some destinations are more valuable than others... e.g., Google).  If the most "valuable" destinations deployed S-BGP and made everyone who wanted to connect to them deploy it, that would be more likely to succeed than the approach taken in the paper, I think.

Conclusion: All of these questions above make me wonder about two more general assumptions that it would be good to get some more insight into:
	* Who "holds the cards", in terms of dictating the terms of interconnection?  Content providers?  Access networks/eyeballs?  Tier-1s?  (many of the recent peering spats recently seem to indicate that various ASes are trying to shake the current balance(s) of power, it seems)
	* How complicated are interconnection contracts today, and how have they evolved? (i.e., how common is a random tiebreak, and how does that differ by network?)

-Nick

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

[1] Valancius, V. and Lumezanu, C. and Feamster, N. and Johari, R. and Vazirani, V.V.
How Many Tiers? Pricing in the Internet Transit Market
In ACM SIGCOMM, 2011


On Sep 5, 2011, at 11:36 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> 
>> On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote:
>> 
>>> 
>>>> 
>>>> One could argue that rejecting routes which you previously had no way to
>>>> know you should reject will inherently alter the routing system and that this
>>>> is probably a good thing.
>>> 
>>> Good point.  Also, "tie breaking" in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic "positively or negatively" -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome...
>>> 
>>> -- Jen
>> 
>> This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases.
>> 
>> The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything.
>> 
>> Owen
>> 
> 
> 
> Except if you believe we have been lucky until now and security is all about the future where we may be less lucky.
> 
> What I would be interested in seeing is a discussion on whether any anti-competitive market distortion incentives exist for large providers in adopting secured BGP. We might be lucky there too.
> 
> Perhaps this will finally help solve the routing slot scalability problem. Might also jumpstart LISP. Which may put some more steam into v6. Welcome to the brave new internet.
> 
> Good for everyone, right?
> 
> Are you feeling lucky?
> 
> 
> Joe
> 




From rdobbins at arbor.net  Mon Sep  5 12:32:57 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 5 Sep 2011 17:32:57 +0000
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <61788FCE-4637-4D54-9096-F5F3346CD5DE@cc.gatech.edu>
References: <m2mxek1v78.wl%randy@psg.com>
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com> <20110905124724.GA8292@ussenterprise.ufp.org>
 <C2BE4BC4-27AA-4171-802D-C863CDFB69D9@delong.com>
 <D3BB8EEF-584C-4AB6-8CAA-FBE51FC9DB61@cs.princeton.edu>
 <22122255-5F6E-4395-BFF7-007CE5FE8CA9@delong.com>
 <4E64EC71.9080704@ttec.com>
 <61788FCE-4637-4D54-9096-F5F3346CD5DE@cc.gatech.edu>
Message-ID: <0AC2FA8A-8B8F-4CC2-919E-C8CBE35AED9C@arbor.net>

On Sep 5, 2011, at 11:51 PM, Nick Feamster wrote:

>  If the most "valuable" destinations

'Most valuable', 'least expensive', 'least congested', 'most reliable', 'most responsive', 'least contractually onerous', 'most generous ratio', 'most  lucrative', et. al. - all these criteria and more come into play in the context of traffic engineering, and they're all relative to who you are and where you are and where you want your traffic/their traffic/someone else's traffic to go.  

And all the above vary depending upon your business type, business model, geographical reach, topological diversity, etc.  So, as you imply, one set of economic parameters and weights for one SP will be completely different for the economic parameters and weights for another SP.  It's possible to roughly generalize based upon SP type, but there are many, many variables which will affect routing selection complexity.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From caldcv at gmail.com  Mon Sep  5 12:41:03 2011
From: caldcv at gmail.com (Chris)
Date: Mon, 5 Sep 2011 13:41:03 -0400
Subject: Tampa small colo recs?
In-Reply-To: <24261253.402.1314924618891.JavaMail.root@benjamin.baylink.com>
References: <8701686.400.1314924577802.JavaMail.root@benjamin.baylink.com>
 <24261253.402.1314924618891.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAPF5agciv=ODp+zMfa+L+NdypCWDLS-0kRr5-qUhw1yaWPYzvg@mail.gmail.com>

Hivelocity has a facility in Tampa. I have a virtual private server
there with someone colo'd there and it's great. Email me off list and
I'll give you the IP address for tracerouting or whatever you need to
do.

-C



From owen at delong.com  Mon Sep  5 13:34:44 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 5 Sep 2011 11:34:44 -0700
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <4E64EC71.9080704@ttec.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com> <20110905124724.GA8292@ussenterprise.ufp.org>
 <C2BE4BC4-27AA-4171-802D-C863CDFB69D9@delong.com>
 <D3BB8EEF-584C-4AB6-8CAA-FBE51FC9DB61@cs.princeton.edu>
 <22122255-5F6E-4395-BFF7-007CE5FE8CA9@delong.com> <4E64EC71.9080704@ttec.com>
Message-ID: <FBEDEAEE-8DE0-40B6-ADD1-0AA7AC2EB75E@delong.com>


On Sep 5, 2011, at 8:36 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> 
>> On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote:
>> 
>>> 
>>>> 
>>>> One could argue that rejecting routes which you previously had no way to
>>>> know you should reject will inherently alter the routing system and that this
>>>> is probably a good thing.
>>> 
>>> Good point.  Also, "tie breaking" in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic "positively or negatively" -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome...
>>> 
>>> -- Jen
>> 
>> This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases.
>> 
>> The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything.
>> 
>> Owen
>> 
> 
> 
> Except if you believe we have been lucky until now and security is all about the future where we may be less lucky.
> 

I'm pretty sure that there is actually a fair amount of pollution in the routing table today and that it will only get worse until we have some form of security.

I believe that most spammers operate by advertising hijacked prefixes for short periods of time and then going away before people can react.

Since there have been multiple instances of proof of my above belief, I would find it very hard to believe we have been lucky until now.

> What I would be interested in seeing is a discussion on whether any anti-competitive market distortion incentives exist for large providers in adopting secured BGP. We might be lucky there too.
> 

Of course they do. We probably won't get particularly lucky there, either.

> Perhaps this will finally help solve the routing slot scalability problem. Might also jumpstart LISP. Which may put some more steam into v6. Welcome to the brave new internet.
> 

Probably not. I really doubt it will do much to help LISP.

Contrary to many people's opinions, I think that IPv4 address shortage and the coming costs of attempting to maintain IPv4 on life support will put more steam into IPv6 than any artificial move we could make in this area.

> Good for everyone, right?
> 

IPv6 is good for everyone whether they realize it or not.

LISP I'm not as convinced.

> Are you feeling lucky?
> 

No, not really.

Owen




From goldbe at cs.bu.edu  Mon Sep  5 15:04:21 2011
From: goldbe at cs.bu.edu (Sharon Goldberg)
Date: Mon, 5 Sep 2011 16:04:21 -0400
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <61788FCE-4637-4D54-9096-F5F3346CD5DE@cc.gatech.edu>
References: <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com> <20110905124724.GA8292@ussenterprise.ufp.org>
 <C2BE4BC4-27AA-4171-802D-C863CDFB69D9@delong.com>
 <D3BB8EEF-584C-4AB6-8CAA-FBE51FC9DB61@cs.princeton.edu>
 <22122255-5F6E-4395-BFF7-007CE5FE8CA9@delong.com> <4E64EC71.9080704@ttec.com>
 <61788FCE-4637-4D54-9096-F5F3346CD5DE@cc.gatech.edu>
Message-ID: <CAJHGrrR3pZG37OGShi44azhC+ABkJWmQUMhc1TQZPyVBVKwPYQ@mail.gmail.com>

Nick Feamster wrote:
> 2. I question what fraction of routing decisions come down to a blind tiebreak---nearly all of them are likely to be driven by some other consideration (reliability, cost, etc.). ?Our paper details a richer economic model by which ASes actually select paths, for example, but it's still unclear to me how coarse or fine-grained route selection really is in practice, and to what extent more complicated contracts have evolved. ?I wonder how common "blind tiebreaking" is in BGP, in real networks; the approach in Sharon's paper definitely may overstate how common that is if route selection considerations commonly involve things that are not visible in the AS graph (e.g., traffic ratios, congestion, performance), but academics could really benefit from some more insight into how rich these decisions are in practice.

We think a key point is getting lost here.

Routing policies affect our result in the following crucial way --
they determine the size of ASes' "tiebreak sets" (section 6.6).  A
tiebreak set is a set of  "equally good routes" that an source AS has
to a destination AS; in our model, an AS should prefer to route along
the _secure_ routes in its tiebreak set. Simply put, with a larger
tiebreak set, there should be more competition over customer traffic,
and thus more widespread S*BGP deployment.

In our simulations we assumed that tiebreak sets were determined by
Local-Pref (economic considerations) and AS-Path considerations.   In
practice, tiebreak sets could be larger (e.g., if ASes prefer shorter
paths over customer paths) or smaller (e.g.,  if intradomain
considerations, like hot potato routing, affect tiebreak sets) than
those in our simulations.  Like Nick said, this is a place where more
data from the ops community would be helpful to help us figure out how
big tiebreak sets really are.

However, the key point we want to emphasize is that in the simulations
we ran, the tiebreak sets are actually quite small:
1) The size of the average AS tiebreak set in our simulations is only
1.18; which mean that 80% of tiebreak sets have only one path, see
also Figure 8.
2) Security does not play a role in the vast majority (96%) of routing
decisions made in our simulations (Section 6.7).
In other words, S*BGP deployment can be driven even by a fairly small
amount of competition for customer traffic.

> 3. I think the discussion on the list so far misses what I see as the central question about the economic assumptions in that paper. ?The paper assumes that all destinations are equally valuable, which we know is not the case. ?This implicitly (and perhaps mistakenly?) shifts the balance of power to tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., Google). ?In practice, ISPs may be willing to spend significant amounts of money to reach certain destinations or content (some destinations are more valuable than others... e.g., Google). ?If the most "valuable" destinations deployed S-BGP and made everyone who wanted to connect to them deploy it, that would be more likely to succeed than the approach taken in the paper, I think.

Our paper does not assume all destinations are equally valuable.

1) As mentioned in our response to Randy, we weight content
providers more heavily  (see Section 6.8.1; we ran experiments where
the content providers collectively source 10%, 20%, 33% or 50% of
Internet traffic).

2) From Section 6.8.1: "We test the robustness of our results... by
modeling traffic locality [the idea that ASes are likely to send more
traffic to ASes that are closer to them]..." Section 6.8.2 shows our results are
insensitive to this assumption.

Sincerely,
Phillipa Gill, Michael Schapira, and Sharon Goldberg

> On Sep 5, 2011, at 11:36 AM, Joe Maimon wrote:
>
>>
>>
>> Owen DeLong wrote:
>>>
>>> On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote:
>>>
>>>>
>>>>>
>>>>> One could argue that rejecting routes which you previously had no way to
>>>>> know you should reject will inherently alter the routing system and that this
>>>>> is probably a good thing.
>>>>
>>>> Good point. ?Also, "tie breaking" in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic "positively or negatively" -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome...
>>>>
>>>> -- Jen
>>>
>>> This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases.
>>>
>>> The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything.
>>>
>>> Owen
>>>
>>
>>
>> Except if you believe we have been lucky until now and security is all about the future where we may be less lucky.
>>
>> What I would be interested in seeing is a discussion on whether any anti-competitive market distortion incentives exist for large providers in adopting secured BGP. We might be lucky there too.
>>
>> Perhaps this will finally help solve the routing slot scalability problem. Might also jumpstart LISP. Which may put some more steam into v6. Welcome to the brave new internet.
>>
>> Good for everyone, right?
>>
>> Are you feeling lucky?
>>
>>
>> Joe
>>
>
>
>



-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe



From joelja at bogus.com  Sun Sep  4 10:43:27 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Sun, 04 Sep 2011 08:43:27 -0700
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <CA883C31.2D5E0%skeeve@eintellego.net>
References: <CA883C31.2D5E0%skeeve@eintellego.net>
Message-ID: <4E639C9F.2020503@bogus.com>

On 9/3/11 04:20 , Skeeve Stevens wrote:
> Hey all,
> 
> I've been thinking about the impact that iCloud (by Apple) will have
> on the Internet.
> 
> My guess is that 99% of consumer internet access is Asymmetrical
> (DSL, Cable, wireless, etc) and iCloud when launched will 'upload'
> obscene amounts of gigs of music, tv, backups, email, photos,
> documents/data and so on to their data centres.

It won't been obscene amounts, the free tier's quota is only 10GB. the
music which is probably the thing that moves into the the cloud the
fashion you described isn't moved into the cloud by uploading.

I'd expect the reads to dominate over writes so your traffic pattern
asymmetry is preserved.

> Now, don't misunderstand me, I love the concept of iCloud, as I do
> DropBox, but from an Access Providers perspective, I'm thinking this
> might be a 'bad thing'.

having customers that want to use your service is rarely a bad thing.

One of the things that this discussion point misses is that when you
operate at a distance from your data, you become rather sensitive to
latency. while apple is rather good about caching data locally, that
doesn't eliminate it from consideration.

> From what I can see there are some key issues:
> 
> *   Users with plans that count upload and download together. *   The
> speed of Asymmetric tail technology such as DSL *   The design of
> access provider backhaul (from DSLAM to core) metrics *   The design
> of some transit metrics
> 
> So basically the potential issue is that a large residential provider
> could have thousands of users connect to iCloud, their connections
> slowed because of uploading data, burning their included bandwidth
> caps, slowing down the backhaul segment of the network, and as
> residential providers are mostly download, some purchase transit from
> their upstreams in an symmetric fashion.
> 
> This post is really just to prompt discussion if people think there
> is anything to actually worry about, or there are other implications
> that I've not really thought of yet.

> ?Skeeve
> 
> --
> 
> Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking
> Specialists
> 
> skeeve at eintellego.net<mailto:skeeve at eintellego.net> ;
> www.eintellego.net
> 
> Phone: 1300 753 383 ; Fax: (+612) 8572 9954
> 
> Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellego or
> eintellego at facebook.com<mailto:eintellego at facebook.com>
> 
> twitter.com/networkceoau ; www.linkedin.com/in/skeeve
> 
> PO Box 7726, Baulkham Hills, NSW 1755 Australia
> 
> 
> --
> 
> eintellego - The Experts that the Experts call
> 
> - Juniper - HP Networking - Cisco - Brocade
> 




From owen at delong.com  Mon Sep  5 17:09:32 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 5 Sep 2011 15:09:32 -0700
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <CAJHGrrR3pZG37OGShi44azhC+ABkJWmQUMhc1TQZPyVBVKwPYQ@mail.gmail.com>
References: <CAJHGrrShOnb0Gn8sMbn_LBP2iFK+pRjGD4ZXB_64H==+N3HpFQ@mail.gmail.com>
 <m2mxek1v78.wl%randy@psg.com> <20110905124724.GA8292@ussenterprise.ufp.org>
 <C2BE4BC4-27AA-4171-802D-C863CDFB69D9@delong.com>
 <D3BB8EEF-584C-4AB6-8CAA-FBE51FC9DB61@cs.princeton.edu>
 <22122255-5F6E-4395-BFF7-007CE5FE8CA9@delong.com> <4E64EC71.9080704@ttec.com>
 <61788FCE-4637-4D54-9096-F5F3346CD5DE@cc.gatech.edu>
 <CAJHGrrR3pZG37OGShi44azhC+ABkJWmQUMhc1TQZPyVBVKwPYQ@mail.gmail.com>
Message-ID: <96FE5C75-752F-4D59-9A69-BE519156C781@delong.com>

> 
>> 3. I think the discussion on the list so far misses what I see as the central question about the economic assumptions in that paper.  The paper assumes that all destinations are equally valuable, which we know is not the case.  This implicitly (and perhaps mistakenly?) shifts the balance of power to tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., Google).  In practice, ISPs may be willing to spend significant amounts of money to reach certain destinations or content (some destinations are more valuable than others... e.g., Google).  If the most "valuable" destinations deployed S-BGP and made everyone who wanted to connect to them deploy it, that would be more likely to succeed than the approach taken in the paper, I think.
> 
> Our paper does not assume all destinations are equally valuable.
> 
> 1) As mentioned in our response to Randy, we weight content
> providers more heavily  (see Section 6.8.1; we ran experiments where
> the content providers collectively source 10%, 20%, 33% or 50% of
> Internet traffic).
> 

The point here, however, is that the value is subjective. Not all content providers
are equally valuable. An access provider will get many complaints from users
if they are unable to reach some content providers (e.g. google) while they will
get relatively few complaints if they are unable to access others
(e.g. hasthelargehadroncolliderdestroyedtheworldyet.com).

Owen





From frnkblk at iname.com  Mon Sep  5 20:48:22 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Mon, 5 Sep 2011 20:48:22 -0500
Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down
 for 10 days
In-Reply-To: <00a101cc68f2$f1f98e20$d5ecaa60$@iname.com>
References: <000001cc5d68$93fc01d0$bbf40570$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643976AA@EALPO1.ukbroadband.com>
 <3A807C2C-9DD2-4A40-B11E-8583F2C562B6@delong.com>
 <ECB36694-DA05-4B05-B9A0-27BCC312BAB0@internode.com.au>
 <E1DD60718964C54A96C04CA9CB0BA811013D0286F42A@server3.MUTUALTEL.MTCNET.NET>
 <001001cc5e91$598b9310$0ca2b930$@iname.com>
 <00a101cc68f2$f1f98e20$d5ecaa60$@iname.com>
Message-ID: <007f01cc6c37$0f4ac060$2de04120$@iname.com>

A Chrome plugin alerted me to the fact that savvis.com has an AAAA for
www.savvis.com.  Unfortunately access to that host over IPv6 is down, too.

Frank

-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Thursday, September 01, 2011 5:03 PM
To: nanog at nanog.org
Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days

Charter.com has also remove the quad-A's for www.charter.com.  My monitoring
system alerted me this afternoon that it couldn't get to the v6 version of
their website.  Because of DNS caching, I don't know how many hours or days
ago it was removed.

Frank

-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Friday, August 19, 2011 11:59 AM
To: nanog at nanog.org
Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days

I just noticed that the quad-A records for both those two hosts are now
gone.  DNS being what it is, I'm not sure when that happened, but our
monitoring system couldn't get the AAAA for www.qwest.com about half an hour
ago.

Hopefully CenturyLink is actively working towards IPv6-enabling their sites
again.

Frank

-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Thursday, August 18, 2011 11:14 PM
To: nanog at nanog.org
Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days

FYI, the issue is not resolved and I've not heard from either of the
companies suggesting that they're working on it.

Note their commitment to IPv6 in these releases:
http://www.prnewswire.com/news-releases/centurylink-joins-internet-community
-in-world-ipv6-day-123089908.html
http://news.centurylink.com/index.php?s=43&item=2129

Frank

-----Original Message-----
From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] 
Sent: Thursday, August 18, 2011 7:08 PM
To: Owen DeLong
Cc: nanog at nanog.org
Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days


On 19/08/2011, at 4:18 AM, Owen DeLong wrote:

It'd really suck for end users to start actively avoiding IPv6 connectivity
because it keeps breaking and for organisations that have active AAAA
records to break peoples connectivity to their resources.



+1 -- I'm all for publishing AAAA records as everyone knows, but, if you
publish AAAA records for a consumer facing service, please support and
monitor that service with a similar level to what you do for your IPv4
versions of the service.

The coming years are going to be difficult enough for end-users without
adding unnecessary anti-IPv6 sentiments to the mix.

Owen

+1 to Owen's comment.

I'd also add some more comments:

A lot of eyeballs that have v6 right now are the people with a lot of clue.
Do you want these people, who'll often be buying or recommending your
services to rate your ability to deliver as a fail?  Our experience with
IPv6 consumer broadband has been that the early adopters are the people who,
well, goto IETF meetings, follow standards and ask the bloody hard
questions.

Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated as
HE?? :-) ) most end users prefer IPv6 over IPv4.  Deeply this means there is
a tendency for v6 traffic to grow and be more important to connectivity than
you may imagine.  The tipping point for IPv6 traffic being dominant I
suspect is going to be a lower threshold of take up than people might
expect.   Consider this when thinking about the level of thought you give to
IPv6 infrastructure and PPS rates.

MMC








From marka at isc.org  Mon Sep  5 20:55:00 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 06 Sep 2011 11:55:00 +1000
Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down
 for 10 days
In-Reply-To: Your message of "Mon, 05 Sep 2011 20:48:22 EST."
 <007f01cc6c37$0f4ac060$2de04120$@iname.com>
References: <000001cc5d68$93fc01d0$bbf40570$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643976AA@EALPO1.ukbroadband.com>
 <3A807C2C-9DD2-4A40-B11E-8583F2C562B6@delong.com>
 <ECB36694-DA05-4B05-B9A0-27BCC312BAB0@internode.com.au>
 <E1DD60718964C54A96C04CA9CB0BA811013D0286F42A@server3.MUTUALTEL.MTCNET.NET>
 <001001cc5e91$598b9310$0ca2b930$@iname.com>
 <00a101cc68f2$f1f98e20$d5ecaa60$@iname.com>
 <007f01cc6c37$0f4ac060$2de04120$@iname.com>
Message-ID: <20110906015500.47ED613CE38A@drugs.dv.isc.org>


In message <007f01cc6c37$0f4ac060$2de04120$@iname.com>, "Frank Bulk" writes:
> A Chrome plugin alerted me to the fact that savvis.com has an AAAA for
> www.savvis.com.  Unfortunately access to that host over IPv6 is down, too.
> 
> Frank

The fault must be local to you.  Works fine from here.

Mark
 
> -----Original Message-----
> From: Frank Bulk [mailto:frnkblk at iname.com] 
> Sent: Thursday, September 01, 2011 5:03 PM
> To: nanog at nanog.org
> Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
> for 10 days
> 
> Charter.com has also remove the quad-A's for www.charter.com.  My monitoring
> system alerted me this afternoon that it couldn't get to the v6 version of
> their website.  Because of DNS caching, I don't know how many hours or days
> ago it was removed.
> 
> Frank
> 
> -----Original Message-----
> From: Frank Bulk [mailto:frnkblk at iname.com] 
> Sent: Friday, August 19, 2011 11:59 AM
> To: nanog at nanog.org
> Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
> for 10 days
> 
> I just noticed that the quad-A records for both those two hosts are now
> gone.  DNS being what it is, I'm not sure when that happened, but our
> monitoring system couldn't get the AAAA for www.qwest.com about half an hour
> ago.
> 
> Hopefully CenturyLink is actively working towards IPv6-enabling their sites
> again.
> 
> Frank
> 
> -----Original Message-----
> From: Frank Bulk [mailto:frnkblk at iname.com] 
> Sent: Thursday, August 18, 2011 11:14 PM
> To: nanog at nanog.org
> Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
> for 10 days
> 
> FYI, the issue is not resolved and I've not heard from either of the
> companies suggesting that they're working on it.
> 
> Note their commitment to IPv6 in these releases:
> http://www.prnewswire.com/news-releases/centurylink-joins-internet-community
> -in-world-ipv6-day-123089908.html
> http://news.centurylink.com/index.php?s=43&item=2129
> 
> Frank
> 
> -----Original Message-----
> From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] 
> Sent: Thursday, August 18, 2011 7:08 PM
> To: Owen DeLong
> Cc: nanog at nanog.org
> Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down
> for 10 days
> 
> 
> On 19/08/2011, at 4:18 AM, Owen DeLong wrote:
> 
> It'd really suck for end users to start actively avoiding IPv6 connectivity
> because it keeps breaking and for organisations that have active AAAA
> records to break peoples connectivity to their resources.
> 
> 
> 
> +1 -- I'm all for publishing AAAA records as everyone knows, but, if you
> publish AAAA records for a consumer facing service, please support and
> monitor that service with a similar level to what you do for your IPv4
> versions of the service.
> 
> The coming years are going to be difficult enough for end-users without
> adding unnecessary anti-IPv6 sentiments to the mix.
> 
> Owen
> 
> +1 to Owen's comment.
> 
> I'd also add some more comments:
> 
> A lot of eyeballs that have v6 right now are the people with a lot of clue.
> Do you want these people, who'll often be buying or recommending your
> services to rate your ability to deliver as a fail?  Our experience with
> IPv6 consumer broadband has been that the early adopters are the people who,
> well, goto IETF meetings, follow standards and ask the bloody hard
> questions.
> 
> Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated as
> HE?? :-) ) most end users prefer IPv6 over IPv4.  Deeply this means there is
> a tendency for v6 traffic to grow and be more important to connectivity than
> you may imagine.  The tipping point for IPv6 traffic being dominant I
> suspect is going to be a lower threshold of take up than people might
> expect.   Consider this when thinking about the level of thought you give to
> IPv6 infrastructure and PPS rates.
> 
> MMC
> 
> 
> 
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From frnkblk at iname.com  Mon Sep  5 20:57:37 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Mon, 5 Sep 2011 20:57:37 -0500
Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down
 for 10 days
In-Reply-To: <20110906015500.47ED613CE38A@drugs.dv.isc.org>
References: <000001cc5d68$93fc01d0$bbf40570$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643976AA@EALPO1.ukbroadband.com>
 <3A807C2C-9DD2-4A40-B11E-8583F2C562B6@delong.com>
 <ECB36694-DA05-4B05-B9A0-27BCC312BAB0@internode.com.au>
 <E1DD60718964C54A96C04CA9CB0BA811013D0286F42A@server3.MUTUALTEL.MTCNET.NET>
 <001001cc5e91$598b9310$0ca2b930$@iname.com>
 <00a101cc68f2$f1f98e20$d5ecaa60$@iname.com>
 <007f01cc6c37$0f4ac060$2de04120$@iname.com>
 <20110906015500.47ED613CE38A@drugs.dv.isc.org>
Message-ID: <008601cc6c38$5a5a7db0$0f0f7910$@iname.com>

Strange, not for me.

nagios:/etc/nagios3# ping6 www.savvis.com
PING www.savvis.com(2001:460:100:1000::37) 56 data bytes
64 bytes from 2001:460:100:1000::37: icmp_seq=1 ttl=239 time=55.5 ms
64 bytes from 2001:460:100:1000::37: icmp_seq=2 ttl=239 time=55.4 ms
64 bytes from 2001:460:100:1000::37: icmp_seq=3 ttl=239 time=55.6 ms
64 bytes from 2001:460:100:1000::37: icmp_seq=4 ttl=239 time=55.4 ms
^C
--- www.savvis.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 55.465/55.517/55.608/0.176 ms
nagios:/etc/nagios3# wget -6 www.savvis.com
--2011-09-05 20:57:08--  http://www.savvis.com/
Resolving www.savvis.com... 2001:460:100:1000::37
Connecting to www.savvis.com|2001:460:100:1000::37|:80... failed: Connection
refused.
nagios:/etc/nagios3#

Frank

-----Original Message-----
From: Mark Andrews [mailto:marka at isc.org] 
Sent: Monday, September 05, 2011 8:55 PM
To: frnkblk at iname.com
Cc: nanog at nanog.org
Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days


In message <007f01cc6c37$0f4ac060$2de04120$@iname.com>, "Frank Bulk" writes:
> A Chrome plugin alerted me to the fact that savvis.com has an AAAA for
> www.savvis.com.  Unfortunately access to that host over IPv6 is down, too.
> 
> Frank

The fault must be local to you.  Works fine from here.

Mark
 
> -----Original Message-----
> From: Frank Bulk [mailto:frnkblk at iname.com] 
> Sent: Thursday, September 01, 2011 5:03 PM
> To: nanog at nanog.org
> Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been
down
> for 10 days
> 
> Charter.com has also remove the quad-A's for www.charter.com.  My
monitoring
> system alerted me this afternoon that it couldn't get to the v6 version of
> their website.  Because of DNS caching, I don't know how many hours or
days
> ago it was removed.
> 
> Frank
> 
> -----Original Message-----
> From: Frank Bulk [mailto:frnkblk at iname.com] 
> Sent: Friday, August 19, 2011 11:59 AM
> To: nanog at nanog.org
> Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been
down
> for 10 days
> 
> I just noticed that the quad-A records for both those two hosts are now
> gone.  DNS being what it is, I'm not sure when that happened, but our
> monitoring system couldn't get the AAAA for www.qwest.com about half an
hour
> ago.
> 
> Hopefully CenturyLink is actively working towards IPv6-enabling their
sites
> again.
> 
> Frank
> 
> -----Original Message-----
> From: Frank Bulk [mailto:frnkblk at iname.com] 
> Sent: Thursday, August 18, 2011 11:14 PM
> To: nanog at nanog.org
> Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been
down
> for 10 days
> 
> FYI, the issue is not resolved and I've not heard from either of the
> companies suggesting that they're working on it.
> 
> Note their commitment to IPv6 in these releases:
>
http://www.prnewswire.com/news-releases/centurylink-joins-internet-community
> -in-world-ipv6-day-123089908.html
> http://news.centurylink.com/index.php?s=43&item=2129
> 
> Frank
> 
> -----Original Message-----
> From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] 
> Sent: Thursday, August 18, 2011 7:08 PM
> To: Owen DeLong
> Cc: nanog at nanog.org
> Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been
down
> for 10 days
> 
> 
> On 19/08/2011, at 4:18 AM, Owen DeLong wrote:
> 
> It'd really suck for end users to start actively avoiding IPv6
connectivity
> because it keeps breaking and for organisations that have active AAAA
> records to break peoples connectivity to their resources.
> 
> 
> 
> +1 -- I'm all for publishing AAAA records as everyone knows, but, if you
> publish AAAA records for a consumer facing service, please support and
> monitor that service with a similar level to what you do for your IPv4
> versions of the service.
> 
> The coming years are going to be difficult enough for end-users without
> adding unnecessary anti-IPv6 sentiments to the mix.
> 
> Owen
> 
> +1 to Owen's comment.
> 
> I'd also add some more comments:
> 
> A lot of eyeballs that have v6 right now are the people with a lot of
clue.
> Do you want these people, who'll often be buying or recommending your
> services to rate your ability to deliver as a fail?  Our experience with
> IPv6 consumer broadband has been that the early adopters are the people
who,
> well, goto IETF meetings, follow standards and ask the bloody hard
> questions.
> 
> Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated
as
> HE?? :-) ) most end users prefer IPv6 over IPv4.  Deeply this means there
is
> a tendency for v6 traffic to grow and be more important to connectivity
than
> you may imagine.  The tipping point for IPv6 traffic being dominant I
> suspect is going to be a lower threshold of take up than people might
> expect.   Consider this when thinking about the level of thought you give
to
> IPv6 infrastructure and PPS rates.
> 
> MMC
> 
> 
> 
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org




From jra at baylink.com  Mon Sep  5 21:39:32 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 5 Sep 2011 22:39:32 -0400 (EDT)
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <4E639C9F.2020503@bogus.com>
Message-ID: <23006012.859.1315276772119.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Joel jaeggli" <joelja at bogus.com>

> having customers that want to use your service is rarely a bad thing.

Ask a chief engineer at a national wireless carrier who told his administrative
bosses that selling "unlimited" wireless data was a Pretty Neat Idea if he
thinks that's a good generalization to make, Joel.  :-)

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      http://photo.imageinc.us             +1 727 647 1274



From nanog at jima.tk  Mon Sep  5 22:55:12 2011
From: nanog at jima.tk (Jima)
Date: Mon, 05 Sep 2011 21:55:12 -0600
Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down
 for 10 days
In-Reply-To: <008601cc6c38$5a5a7db0$0f0f7910$@iname.com>
References: <000001cc5d68$93fc01d0$bbf40570$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643976AA@EALPO1.ukbroadband.com>
 <3A807C2C-9DD2-4A40-B11E-8583F2C562B6@delong.com>
 <ECB36694-DA05-4B05-B9A0-27BCC312BAB0@internode.com.au>
 <E1DD60718964C54A96C04CA9CB0BA811013D0286F42A@server3.MUTUALTEL.MTCNET.NET>
 <001001cc5e91$598b9310$0ca2b930$@iname.com>
 <00a101cc68f2$f1f98e20$d5ecaa60$@iname.com>
 <007f01cc6c37$0f4ac060$2de04120$@iname.com>
 <20110906015500.47ED613CE38A@drugs.dv.isc.org>
 <008601cc6c38$5a5a7db0$0f0f7910$@iname.com>
Message-ID: <4E6599A0.5010303@jima.tk>

  I'm with Frank on this one: ICMP yes, HTTP/HTTPS no, via native IPv6 
(multiple locations).  No, wait -- it shows as open from a couple 
tunnels (both HE & SixXS).  So it's not consistent.  Lovely.

  Closed from:
2607:ff50::/32 (native)
2607:fcd0::/32 (native)

  Open from:
2001:1938::/32 (SixXS tunnel)
2001:4978::/32 (SixXS tunnel)
2001:470::/32 (HE tunnel)

  That gives me a really bad feeling of what might be wrong, but I'll 
leave it to the professionals.

      Jima

On 2011-09-05 19:57, Frank Bulk wrote:
> Strange, not for me.
>
> nagios:/etc/nagios3# ping6 www.savvis.com
> PING www.savvis.com(2001:460:100:1000::37) 56 data bytes
> 64 bytes from 2001:460:100:1000::37: icmp_seq=1 ttl=239 time=55.5 ms
> 64 bytes from 2001:460:100:1000::37: icmp_seq=2 ttl=239 time=55.4 ms
> 64 bytes from 2001:460:100:1000::37: icmp_seq=3 ttl=239 time=55.6 ms
> 64 bytes from 2001:460:100:1000::37: icmp_seq=4 ttl=239 time=55.4 ms
> ^C
> --- www.savvis.com ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 2999ms
> rtt min/avg/max/mdev = 55.465/55.517/55.608/0.176 ms
> nagios:/etc/nagios3# wget -6 www.savvis.com
> --2011-09-05 20:57:08--  http://www.savvis.com/
> Resolving www.savvis.com... 2001:460:100:1000::37
> Connecting to www.savvis.com|2001:460:100:1000::37|:80... failed: Connection
> refused.
> nagios:/etc/nagios3#
>
> Frank
>
> -----Original Message-----
> From: Mark Andrews [mailto:marka at isc.org]
> Sent: Monday, September 05, 2011 8:55 PM
> To: frnkblk at iname.com
> Cc: nanog at nanog.org
> Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down
> for 10 days
>
>
> In message<007f01cc6c37$0f4ac060$2de04120$@iname.com>, "Frank Bulk" writes:
>> A Chrome plugin alerted me to the fact that savvis.com has an AAAA for
>> www.savvis.com.  Unfortunately access to that host over IPv6 is down, too.
>>
>> Frank
>
> The fault must be local to you.  Works fine from here.
>
> Mark
>
>> -----Original Message-----
>> From: Frank Bulk [mailto:frnkblk at iname.com]
>> Sent: Thursday, September 01, 2011 5:03 PM
>> To: nanog at nanog.org
>> Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been
> down
>> for 10 days
>>
>> Charter.com has also remove the quad-A's for www.charter.com.  My
> monitoring
>> system alerted me this afternoon that it couldn't get to the v6 version of
>> their website.  Because of DNS caching, I don't know how many hours or
> days
>> ago it was removed.
>>
>> Frank
>>
>> -----Original Message-----
>> From: Frank Bulk [mailto:frnkblk at iname.com]
>> Sent: Friday, August 19, 2011 11:59 AM
>> To: nanog at nanog.org
>> Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been
> down
>> for 10 days
>>
>> I just noticed that the quad-A records for both those two hosts are now
>> gone.  DNS being what it is, I'm not sure when that happened, but our
>> monitoring system couldn't get the AAAA for www.qwest.com about half an
> hour
>> ago.
>>
>> Hopefully CenturyLink is actively working towards IPv6-enabling their
> sites
>> again.
>>
>> Frank
>>
>> -----Original Message-----
>> From: Frank Bulk [mailto:frnkblk at iname.com]
>> Sent: Thursday, August 18, 2011 11:14 PM
>> To: nanog at nanog.org
>> Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been
> down
>> for 10 days
>>
>> FYI, the issue is not resolved and I've not heard from either of the
>> companies suggesting that they're working on it.
>>
>> Note their commitment to IPv6 in these releases:
>>
> http://www.prnewswire.com/news-releases/centurylink-joins-internet-community
>> -in-world-ipv6-day-123089908.html
>> http://news.centurylink.com/index.php?s=43&item=2129
>>
>> Frank
>>
>> -----Original Message-----
>> From: Matthew Moyle-Croft [mailto:mmc at internode.com.au]
>> Sent: Thursday, August 18, 2011 7:08 PM
>> To: Owen DeLong
>> Cc: nanog at nanog.org
>> Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been
> down
>> for 10 days
>>
>>
>> On 19/08/2011, at 4:18 AM, Owen DeLong wrote:
>>
>> It'd really suck for end users to start actively avoiding IPv6
> connectivity
>> because it keeps breaking and for organisations that have active AAAA
>> records to break peoples connectivity to their resources.
>>
>>
>>
>> +1 -- I'm all for publishing AAAA records as everyone knows, but, if you
>> publish AAAA records for a consumer facing service, please support and
>> monitor that service with a similar level to what you do for your IPv4
>> versions of the service.
>>
>> The coming years are going to be difficult enough for end-users without
>> adding unnecessary anti-IPv6 sentiments to the mix.
>>
>> Owen
>>
>> +1 to Owen's comment.
>>
>> I'd also add some more comments:
>>
>> A lot of eyeballs that have v6 right now are the people with a lot of
> clue.
>> Do you want these people, who'll often be buying or recommending your
>> services to rate your ability to deliver as a fail?  Our experience with
>> IPv6 consumer broadband has been that the early adopters are the people
> who,
>> well, goto IETF meetings, follow standards and ask the bloody hard
>> questions.
>>
>> Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated
> as
>> HE?? :-) ) most end users prefer IPv6 over IPv4.  Deeply this means there
> is
>> a tendency for v6 traffic to grow and be more important to connectivity
> than
>> you may imagine.  The tipping point for IPv6 traffic being dominant I
>> suspect is going to be a lower threshold of take up than people might
>> expect.   Consider this when thinking about the level of thought you give
> to
>> IPv6 infrastructure and PPS rates.
>>
>> MMC
>>
>>
>>
>>
>>
>>




From swmike at swm.pp.se  Tue Sep  6 00:25:31 2011
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 6 Sep 2011 07:25:31 +0200 (CEST)
Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down
 for 10 days
In-Reply-To: <4E6599A0.5010303@jima.tk>
References: <000001cc5d68$93fc01d0$bbf40570$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643976AA@EALPO1.ukbroadband.com>
 <3A807C2C-9DD2-4A40-B11E-8583F2C562B6@delong.com>
 <ECB36694-DA05-4B05-B9A0-27BCC312BAB0@internode.com.au>
 <E1DD60718964C54A96C04CA9CB0BA811013D0286F42A@server3.MUTUALTEL.MTCNET.NET>
 <001001cc5e91$598b9310$0ca2b930$@iname.com>
 <00a101cc68f2$f1f98e20$d5ecaa60$@iname.com>
 <007f01cc6c37$0f4ac060$2de04120$@iname.com>
 <20110906015500.47ED613CE38A@drugs.dv.isc.org>
 <008601cc6c38$5a5a7db0$0f0f7910$@iname.com> <4E6599A0.5010303@jima.tk>
Message-ID: <alpine.DEB.2.00.1109060722260.13538@uplift.swm.pp.se>

On Mon, 5 Sep 2011, Jima wrote:

> I'm with Frank on this one: ICMP yes, HTTP/HTTPS no, via native IPv6 
> (multiple locations).  No, wait -- it shows as open from a couple tunnels 
> (both HE & SixXS).  So it's not consistent.  Lovely.

$ telnet -6 www.savvis.com 80
Trying 2001:460:100:1000::37...
telnet: Unable to connect to remote host: Connection refused

I checked, it's a TCP RST packet, not ICMP unreachable. This is from 
native IPv6.

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



From lists at blackhat.bz  Tue Sep  6 02:53:38 2011
From: lists at blackhat.bz (BH)
Date: Tue, 06 Sep 2011 15:53:38 +0800
Subject: DDoS - CoD?
Message-ID: <4E65D182.8010008@blackhat.bz>

Hi all,

I am wondering if anyone has seen a large DDoS before, specifically on
port 80 UDP with data that seems to be relating to Call of Duty 4. I did
a quick packet capture, and the payload looks like this:

14:50:42.716247 IP Y1.YY.YY.YY.28960 > XX.XX.XX.XX.80: UDP, length 499
        0x0000:  4500 020f 0000 4000 2a11 5203 58bf 8138  E..... at .*.R.X..8
        0x0010:  cbaa 5739 7120 0050 01fb 3e2e ffff ffff  ..W9q..P..>.....
        0x0020:  7374 6174 7573 5265 7370 6f6e 7365 0a5c  statusResponse.\
        0x0030:  5f41 646d 696e 5c6b 696c 6c6b 7574 6572  _Admin\killkuter
        0x0040:  5c5f 456d 6169 6c5c 6b69 6c6c 6b75 7465  \_Email\killkute
        0x0050:  7240 686f 746d 6169 6c2e 636f 6d5c 5f4c  r at hotmail.com\_L
        0x0060:  6f63 6174 696f 6e5c 4652 5c5f 6d61 6e75  ocation\FR\_manu
        0x0070:  6164 6d69 6e6d 6f64 5c30 2e31 312e 3320  adminmod\0.11.3.
        0x0080:  6265 7461 5c5f 5765 6273 6974 655c 6874  beta\_Website\ht
        0x0090:  7470 3a2f 2f77 7777 2e73 7974 2e74 6561  tp://www.syt.tea
        0x00a0:  6d2e 7374 5c67 5f63 6f6d 7061 7373 5368  m.st\g_compassSh
        0x00b0:  6f77 456e 656d 6965 735c 305c 675f 6761  owEnemies\0\g_ga
        0x00c0:  6d65 7479 7065 5c77 6172 5c67 616d 656e  metype\war\gamen
        0x00d0:  616d 655c 4361 6c6c 206f 6620 4475 7479  ame\Call.of.Duty
        0x00e0:  2034 5c6d 6170 6e61 6d65 5c6d 705f 626c  .4\mapname\mp_bl
        0x00f0:  6f63 5c70 726f 746f 636f 6c5c 365c 7368  oc\protocol\6\sh
        0x0100:  6f72 7476 6572 7369 6f6e 5c31 2e37 5c73  ortversion\1.7\s
        0x0110:  765f 616c 6c6f 7741 6e6f 6e79 6d6f 7573  v_allowAnonymous
        0x0120:  5c30 5c73 765f 6469 7361 626c 6543 6c69  \0\sv_disableCli
        0x0130:  656e 7443 6f6e 736f 6c65 5c30 5c73 765f  entConsole\0\sv_
        0x0140:  666c 6f6f 6470 726f 7465 6374 5c31 5c73  floodprotect\1\s
        0x0150:  765f 686f 7374 6e61 6d65 5c5e 3120 5359  v_hostname\^1.SY
        0x0160:  5420 2d20 5e33 5444 4d20 4843 202d 205e  T.-.^3TDM.HC.-.^
        0x0170:  3120 6372 6163 6b20 5c73 765f 6d61 7863  1.crack.\sv_maxc
        0x0180:  6c69 656e 7473 5c32 305c 7376 5f6d 6178  lients\20\sv_max
        0x0190:  5069 6e67 5c31 3530 5c73 765f 6d61 7852  Ping\150\sv_maxR
        0x01a0:  6174 655c 3235 3030 305c 7376 5f6d 696e  ate\25000\sv_min
        0x01b0:  5069 6e67 5c30 5c73 765f 7072 6976 6174  Ping\0\sv_privat
        0x01c0:  6543 6c69 656e 7473 5c36 5c73 765f 7075  eClients\6\sv_pu
        0x01d0:  6e6b 6275 7374 6572 5c30 5c73 765f 7075  nkbuster\0\sv_pu
        0x01e0:  7265 5c31 5c73 765f 766f 6963 655c 305c  re\1\sv_voice\0\
        0x01f0:  7569 5f6d 6178 636c 6965 6e74 735c 3332  ui_maxclients\32
        0x0200:  5c70 7377 7264 5c30 5c6d 6f64 5c30 0a    \pswrd\0\mod\0.
14:50:42.716292 IP Y1.YY.YY.YY.28965 > XX.XX.XX.XX.80: UDP, length 870
        0x0000:  4500 0382 0000 4000 2f11 27e7 c1c0 3be0  E..... at ./.'...;.
        0x0010:  cbaa 5739 7125 0050 036e 1547 ffff ffff  ..W9q%.P.n.G....
        0x0020:  7374 6174 7573 5265 7370 6f6e 7365 0a5c  statusResponse.\
        0x0030:  7368 6f72 7476 6572 7369 6f6e 5c30 2e34  shortversion\0.4
        0x0040:  2d34 325c 7376 5f6d 6178 636c 6965 6e74  -42\sv_maxclient
        0x0050:  735c 3138 5c5f 4164 6d69 6e5c 447a 696e  s\18\_Admin\Dzin
        0x0060:  5c5f 456d 6169 6c5c 6164 6d69 6e40 6261  \_Email\admin at ba
        0x0070:  6c6b 616e 2d77 6172 732e 636f 6d5c 5f4c  lkan-wars.com\_L
        0x0080:  6f63 6174 696f 6e5c 5468 6520 556e 696f  ocation\The.Unio
        0x0090:  6e20 6f66 2053 6f76 6965 7420 536f 6369  n.of.Soviet.Soci
        0x00a0:  616c 6973 7469 6320 5265 7075 626c 6963  alistic.Republic
        0x00b0:  735c 5f57 6562 7369 7465 5c68 7474 703a  s\_Website\http:
        0x00c0:  2f2f 6261 6c6b 616e 2d77 6172 732e 636f  //balkan-wars.co
        0x00d0:  6d5c 6169 775f 7265 6d6f 7465 4b69 636b  m\aiw_remoteKick
        0x00e0:  5c31 5c61 6977 5f73 6563 7572 655c 305c  \1\aiw_secure\0\
        0x00f0:  675f 6761 6d65 7479 7065 5c77 6172 5c67  g_gametype\war\g
        0x0100:  5f68 6172 6463 6f72 655c 305c 6761 6d65  _hardcore\0\game
        0x0110:  6e61 6d65 5c49 5734 5c6d 6170 6e61 6d65  name\IW4\mapname
        0x0120:  5c6d 705f 6272 6563 6f75 7274 5c70 726f  \mp_brecourt\pro
        0x0130:  746f 636f 6c5c 3134 345c 7363 725f 6761  tocol\144\scr_ga
        0x0140:  6d65 5f61 6c6c 6f77 6b69 6c6c 6361 6d5c  me_allowkillcam\
        0x0150:  315c 7363 725f 7465 616d 5f66 6674 7970  1\scr_team_fftyp
        0x0160:  655c 305c 7376 5f61 6c6c 6f77 416e 6f6e  e\0\sv_allowAnon
        0x0170:  796d 6f75 735c 305c 7376 5f61 6c6c 6f77  ymous\0\sv_allow
        0x0180:  436c 6965 6e74 436f 6e73 6f6c 655c 315c  ClientConsole\1\
        0x0190:  7376 5f66 6c6f 6f64 5072 6f74 6563 745c  sv_floodProtect\
        0x01a0:  315c 7376 5f68 6f73 746e 616d 655c 7c46  1\sv_hostname\|F
        0x01b0:  5233 3344 4f4d 7c20 4669 6768 7465 7273  R33DOM|.Fighters
        0x01c0:  2055 4b20 4e6f 5475 6265 2d4e 6f41 6b69  .UK.NoTube-NoAki
        0x01d0:  6d62 6f2d 5444 4d20 3234 2f37 5c73 765f  mbo-TDM.24/7\sv_
        0x01e0:  6d61 7850 696e 675c 3330 305c 7376 5f6d  maxPing\300\sv_m
        0x01f0:  6178 5261 7465 5c31 3530 3030 305c 7376  axRate\150000\sv
        0x0200:  5f6d 696e 5069 6e67 5c30 5c73 765f 7072  _minPing\0\sv_pr
        0x0210:  6976 6174 6543 6c69 656e 7473 5c30 5c73  ivateClients\0\s
        0x0220:  765f 7072 6976 6174 6543 6c69 656e 7473  v_privateClients
        0x0230:  466f 7243 6c69 656e 7473 5c30 0a30 2039  ForClients\0.0.9
        0x0240:  3939 2022 5768 6974 6573 7061 726b 6c65  99."Whitesparkle
        0x0250:  7322 0a30 2038 3920 226d 6174 7269 6361  s".0.89."matrica
        0x0260:  2033 220a 3020 3734 2022 5368 616b 7567  .3".0.74."Shakug
        0x0270:  616e 220a 3020 3536 2022 3336 3048 6561  an".0.56."360Hea
        0x0280:  6453 686f 7422 0a36 3030 2037 3620 2261  dShot".600.76."a
        0x0290:  7665 6c6c 7573 220a 3630 3020 3132 3220  vellus".600.122.
        0x02a0:  2253 696c 7665 7222 0a34 3030 2031 3133  "Silver".400.113
        0x02b0:  2022 4576 616c 6f6e 220a 3131 3030 2037  ."Evalon".1100.7
        0x02c0:  3720 225e 345b 4d5e 3969 575e 345d 4465  7."^4[M^9iW^4]De
        0x02d0:  725e 220a 3130 3020 3937 2022 416e 6472  r^".100.97."Andr
        0x02e0:  6579 2053 756b 6163 6822 0a31 3030 2036  ey.Sukach".100.6
        0x02f0:  3620 2244 7a65 6968 6e6f 3933 220a 3230  6."Dzeihno93".20
        0x0300:  3020 3839 2022 5265 6e22 0a30 2031 3338  0.89."Ren".0.138
        0x0310:  2022 d1d1 d1d0 220a 3230 3020 3334 2022  ."....".200.34."
        0x0320:  7061 7631 220a 3430 3020 3138 3720 224b  pav1".400.187."K
        0x0330:  6172 6c6f 735f 3538 220a 3230 3020 3237  arlos_58".200.27
        0x0340:  3020 226d 4f6e 7374 6572 220a 3730 3020  0."mOnster".700.
        0x0350:  3137 3220 224d 6572 6365 6e61 7279 220a  172."Mercenary".
        0x0360:  3130 3230 2039 3620 226e 696b 6f6c 6122  1020.96."nikola"
        0x0370:  0a33 3030 2031 3234 2022 5349 444f 4922  .300.124."SIDOI"
        0x0380:  0a00    

As far as I know CoD 4 doesn't use port 80 UDP, and I can't see anything
else that would. The box doesn't have anything listening for port 80/udp
(it does run a web server) and never has.

Has anyone seen similar traffic before? I am struggling to figure out
what is causing this traffic, or if its existing traffic being replayed
to try and avoid filters.

Thanks




From rdobbins at arbor.net  Tue Sep  6 03:00:45 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 6 Sep 2011 08:00:45 +0000
Subject: DDoS - CoD?
In-Reply-To: <4E65D182.8010008@blackhat.bz>
References: <4E65D182.8010008@blackhat.bz>
Message-ID: <30DB1247-4534-4740-BE31-16CDFFDB6A2F@arbor.net>

On Sep 6, 2011, at 2:53 PM, BH wrote:

> Has anyone seen similar traffic before? I

I've seen DDoS traffic on UDP/80 as far back as 2002 - the miscreants often don't know a lot about TCP/IP, and if something happens to work once, they incorporate it into their attack tool defaults and keep using it over and over.

In several recent high-profile DDoS attacks, UDP/80 traffic ended up causing state exhaustion on load-balancers, as the victim sites weren't following the BCP of enforcing network access policies via stateless ACLs in hardware-based routers/layer-3 switches, and the load-balancers kept trying to load-balance this traffic from multiple purported source IPs/source ports.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From jvanoppen at spectrumnet.us  Tue Sep  6 03:01:54 2011
From: jvanoppen at spectrumnet.us (John van Oppen)
Date: Tue, 6 Sep 2011 08:01:54 +0000
Subject: DDoS - CoD?
In-Reply-To: <30DB1247-4534-4740-BE31-16CDFFDB6A2F@arbor.net>
References: <4E65D182.8010008@blackhat.bz>,
 <30DB1247-4534-4740-BE31-16CDFFDB6A2F@arbor.net>
Message-ID: <AF24AE2D4A4D334FB9B667985E2AE763C0DC30@mail1-sea.office.spectrumnet.us>

i have seen many udp/80 floods as well...  pretty common.


John van Oppen
Spectrum Networks / AS11404

________________________________________
From: Dobbins, Roland [rdobbins at arbor.net]
Sent: Tuesday, September 06, 2011 1:00 AM
To: North American Network Operators' Group
Subject: Re: DDoS - CoD?

On Sep 6, 2011, at 2:53 PM, BH wrote:

> Has anyone seen similar traffic before? I

I've seen DDoS traffic on UDP/80 as far back as 2002 - the miscreants often don't know a lot about TCP/IP, and if something happens to work once, they incorporate it into their attack tool defaults and keep using it over and over.

In several recent high-profile DDoS attacks, UDP/80 traffic ended up causing state exhaustion on load-balancers, as the victim sites weren't following the BCP of enforcing network access policies via stateless ACLs in hardware-based routers/layer-3 switches, and the load-balancers kept trying to load-balance this traffic from multiple purported source IPs/source ports.

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

                The basis of optimism is sheer terror.

                          -- Oscar Wilde





From lists at blackhat.bz  Tue Sep  6 03:03:59 2011
From: lists at blackhat.bz (BH)
Date: Tue, 06 Sep 2011 16:03:59 +0800
Subject: DDoS - CoD?
In-Reply-To: <30DB1247-4534-4740-BE31-16CDFFDB6A2F@arbor.net>
References: <4E65D182.8010008@blackhat.bz>
 <30DB1247-4534-4740-BE31-16CDFFDB6A2F@arbor.net>
Message-ID: <4E65D3EF.5010404@blackhat.bz>

On 6/09/2011 4:00 PM, Dobbins, Roland wrote:
> I've seen DDoS traffic on UDP/80 as far back as 2002 
Hi Roland,

I should be a bit more clear sorry, I too have frequently seen attacks
on 80/udp but mainly as a source (eg. compromised hosting accounts)
rather than the destination. I didn't in the past do a packet capture,
but I lookes at a couple of scripts and the data was usually randm or
just AAAAAA etc. The thing that perplexed me is why it appears to be
Call of Duty data more than anything...

Thanks



From cdel at firsthand.net  Tue Sep  6 03:09:45 2011
From: cdel at firsthand.net (Christian de Larrinaga)
Date: Tue, 6 Sep 2011 09:09:45 +0100
Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down
 for 10 days
In-Reply-To: <alpine.DEB.2.00.1109060722260.13538@uplift.swm.pp.se>
References: <000001cc5d68$93fc01d0$bbf40570$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643976AA@EALPO1.ukbroadband.com>
 <3A807C2C-9DD2-4A40-B11E-8583F2C562B6@delong.com>
 <ECB36694-DA05-4B05-B9A0-27BCC312BAB0@internode.com.au>
 <E1DD60718964C54A96C04CA9CB0BA811013D0286F42A@server3.MUTUALTEL.MTCNET.NET>
 <001001cc5e91$598b9310$0ca2b930$@iname.com>
 <00a101cc68f2$f1f98e20$d5ecaa60$@iname.com>
 <007f01cc6c37$0f4ac060$2de04120$@iname.com>
 <20110906015500.47ED613CE38A@drugs.dv.isc.org>
 <008601cc6c38$5a5a7db0$0f0f7910$@iname.com> <4E6599A0.5010303@jima.tk>
 <alpine.DEB.2.00.1109060722260.13538@uplift.swm.pp.se>
Message-ID: <7998EE35-86D1-402E-A44B-F1E2DC9A1430@firsthand.net>

via gogo6 tunnel box (http://gogo6.com/) from my UK location 
( not tested other tunnels nor native)
 
$  telnet -6 www.savvis.com 80
Trying 2001:460:100:1000::37...
Connected to www.savvis.net.

$ ping6 www.savvis.com
PING6(56=40+8+8 bytes) 2001:5c0:1110:8000:217:f2ff:fee6:ab79 --> 2001:460:100:1000::37
16 bytes from 2001:460::::xx, icmp_seq=0 hlim=243 time=149.971 ms



Christian

On 6 Sep 2011, at 06:25, Mikael Abrahamsson wrote:

> On Mon, 5 Sep 2011, Jima wrote:
> 
>> I'm with Frank on this one: ICMP yes, HTTP/HTTPS no, via native IPv6 (multiple locations).  No, wait -- it shows as open from a couple tunnels (both HE & SixXS).  So it's not consistent.  Lovely.
> 
> $ telnet -6 www.savvis.com 80
> Trying 2001:460:100:1000::37...
> telnet: Unable to connect to remote host: Connection refused
> 
> I checked, it's a TCP RST packet, not ICMP unreachable. This is from native IPv6.
> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se
> 




From gchalmers at gmail.com  Tue Sep  6 03:14:26 2011
From: gchalmers at gmail.com (Greg Chalmers)
Date: Tue, 6 Sep 2011 18:14:26 +1000
Subject: DDoS - CoD?
In-Reply-To: <4E65D3EF.5010404@blackhat.bz>
References: <4E65D182.8010008@blackhat.bz>
 <30DB1247-4534-4740-BE31-16CDFFDB6A2F@arbor.net>
 <4E65D3EF.5010404@blackhat.bz>
Message-ID: <CADr-PQ+wjF8OWCoCT5=6bnYnU-yX4oPA4wH7CezghDKWd3rm5A@mail.gmail.com>

Could be legitimate CoD servers responding to a spoofed query? How much
traffic are you talking about out of curiosity?

Regards
Greg


On Tue, Sep 6, 2011 at 6:03 PM, BH <lists at blackhat.bz> wrote:

> On 6/09/2011 4:00 PM, Dobbins, Roland wrote:
> > I've seen DDoS traffic on UDP/80 as far back as 2002
> Hi Roland,
>
> I should be a bit more clear sorry, I too have frequently seen attacks
> on 80/udp but mainly as a source (eg. compromised hosting accounts)
> rather than the destination. I didn't in the past do a packet capture,
> but I lookes at a couple of scripts and the data was usually randm or
> just AAAAAA etc. The thing that perplexed me is why it appears to be
> Call of Duty data more than anything...
>
> Thanks
>
>


From a.harrowell at gmail.com  Tue Sep  6 04:33:12 2011
From: a.harrowell at gmail.com (Alexander Harrowell)
Date: Tue, 6 Sep 2011 10:33:12 +0100
Subject: Do Not Complicate Routing Security with Voodoo Economics
In-Reply-To: <22122255-5F6E-4395-BFF7-007CE5FE8CA9@delong.com>
References: <m2mxek1v78.wl%randy@psg.com>
 <D3BB8EEF-584C-4AB6-8CAA-FBE51FC9DB61@cs.princeton.edu>
 <22122255-5F6E-4395-BFF7-007CE5FE8CA9@delong.com>
Message-ID: <201109061033.24430.a.harrowell@gmail.com>

On Monday 05 Sep 2011 15:53:38 Owen DeLong wrote:
> This is true in terms of whether you care or not, but, if one just 
looks at whether it changes the content of the FIB or not, changing 
which arbitrary tie breaker you use likely changes the contents of the 
FIB in at least some cases.
> 
> The key point is that if you are to secure a previously unsecured 
database such as the routing table, you will inherently be changing the 
contents of said database, or, your security isn't actually 
accomplishing anything.

This is true and should probably be considered a universal law. If the 
introduction of security precautions to a system does not change the 
system, the security precautions are ineffective. 

This is based on the principle that people and systems are imperfect, so 
it is extremely unlikely that there are no bad actors or wildlife in the 
pre-security state, and further that false-positive results are 
inevitable. It has the corollary that introducing security precautions 
is invariably costly, and therefore that you must consider the security 
gain relative to the inevitable costs before deciding to do so.

This is of course an intellectually difficult problem. With regard to 
BGP, the security gain is not so much determined by how bad the problem 
is now, as by how bad it could potentially be if someone took it into 
their heads to tear up the rules and declare war. The answer is "very, 
very bad indeed" which is why we're having this discussion.

It also reminds me of J.K. Galbraith's notion of the bezzle - at any 
time, there is an inventory of undiscovered embezzlement in the economy. 
Before it is discovered, both the fraudster and his or her victim 
believe themselves to possess the money that has been stolen - there is 
a net increase in psychic wealth, in JKG's words. In times of 
prosperity, the bezzle grows, and in times of recession, it shrinks.

There is a bezzle of indeterminate size in the routing table, but we 
won't find out how big it is until we audit it (i.e. deploy SBGP). Some 
of it will just be randomness - misconfigurations and errors - but some 
of it will be enemy action.


-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110906/9e2765b1/attachment.bin>

From a.harrowell at gmail.com  Tue Sep  6 05:10:22 2011
From: a.harrowell at gmail.com (Alexander Harrowell)
Date: Tue, 6 Sep 2011 11:10:22 +0100
Subject: DDoS - CoD?
In-Reply-To: <CADr-PQ+wjF8OWCoCT5=6bnYnU-yX4oPA4wH7CezghDKWd3rm5A@mail.gmail.com>
References: <4E65D182.8010008@blackhat.bz> <4E65D3EF.5010404@blackhat.bz>
 <CADr-PQ+wjF8OWCoCT5=6bnYnU-yX4oPA4wH7CezghDKWd3rm5A@mail.gmail.com>
Message-ID: <201109061110.34711.a.harrowell@gmail.com>

On Tuesday 06 Sep 2011 09:14:26 Greg Chalmers wrote:
> Could be legitimate CoD servers responding to a spoofed query?

My first thought looking at the packet dump. Interesting that some poor 
sap's hotmail address is embedded in it.

> How much
> traffic are you talking about out of curiosity?
> 
> Regards
> Greg
> 
> 
> On Tue, Sep 6, 2011 at 6:03 PM, BH <lists at blackhat.bz> wrote:
> 
> > On 6/09/2011 4:00 PM, Dobbins, Roland wrote:
> > > I've seen DDoS traffic on UDP/80 as far back as 2002
> > Hi Roland,
> >
> > I should be a bit more clear sorry, I too have frequently seen 
attacks
> > on 80/udp but mainly as a source (eg. compromised hosting accounts)
> > rather than the destination. I didn't in the past do a packet 
capture,
> > but I lookes at a couple of scripts and the data was usually randm 
or
> > just AAAAAA etc. The thing that perplexed me is why it appears to be
> > Call of Duty data more than anything...
> >
> > Thanks
> >
> >
> 

-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110906/fc467073/attachment.bin>

From lists at blackhat.bz  Tue Sep  6 08:02:37 2011
From: lists at blackhat.bz (BH)
Date: Tue, 06 Sep 2011 21:02:37 +0800
Subject: DDoS - CoD? - Activision contact
In-Reply-To: <201109061110.34711.a.harrowell@gmail.com>
References: <4E65D182.8010008@blackhat.bz> <4E65D3EF.5010404@blackhat.bz>
 <CADr-PQ+wjF8OWCoCT5=6bnYnU-yX4oPA4wH7CezghDKWd3rm5A@mail.gmail.com>
 <201109061110.34711.a.harrowell@gmail.com>
Message-ID: <4E6619ED.7000503@blackhat.bz>

Looking around, I believe the issue is that the IP has ended up on a 
master game list, so we are now getting the queries directed at US.

For anyone interested, there seems to be some info here:

http://forums.steampowered.com/forums/showthread.php?t=1670090

With the packet capture I have and the symptoms looking very alike the 
example in my original email.

I found an earlier example as well with similar symptoms:
http://forums.srcds.com/viewtopic/15737

Is there anyone from Activision on the list or does anyone have an 
Activision contact? Replies off list welcome, I can provide more details 
there.


On 6/09/2011 6:10 PM, Alexander Harrowell wrote:
> On Tuesday 06 Sep 2011 09:14:26 Greg Chalmers wrote:
>> Could be legitimate CoD servers responding to a spoofed query?
>
> My first thought looking at the packet dump. Interesting that some poor
> sap's hotmail address is embedded in it.
>
>> How much
>> traffic are you talking about out of curiosity?
>>
>> Regards
>> Greg
>>
>>
>> On Tue, Sep 6, 2011 at 6:03 PM, BH<lists at blackhat.bz>  wrote:
>>
>>> On 6/09/2011 4:00 PM, Dobbins, Roland wrote:
>>>> I've seen DDoS traffic on UDP/80 as far back as 2002
>>> Hi Roland,
>>>
>>> I should be a bit more clear sorry, I too have frequently seen
> attacks
>>> on 80/udp but mainly as a source (eg. compromised hosting accounts)
>>> rather than the destination. I didn't in the past do a packet
> capture,
>>> but I lookes at a couple of scripts and the data was usually randm
> or
>>> just AAAAAA etc. The thing that perplexed me is why it appears to be
>>> Call of Duty data more than anything...
>>>
>>> Thanks
>>>
>>>
>>
>




From jeffw at he.net  Tue Sep  6 08:47:31 2011
From: jeffw at he.net (Jeff Walter)
Date: Tue, 06 Sep 2011 06:47:31 -0700
Subject: DDoS - CoD?
In-Reply-To: <4E65D182.8010008@blackhat.bz>
References: <4E65D182.8010008@blackhat.bz>
Message-ID: <4E662473.4090303@he.net>

Call of Duty is apparently using the same flawed protocol as Quake III 
servers, so you can think of it as an amplification attack.  (I wish I'd 
forgotten all about this stuff)

You send "\xff\xff\xff\xffgetstatus\n" in a UDP packet with a spoofed 
source, and the server responds with everything you see.  With decent 
amplification (15B -> ~500B) and the number of CoD servers in world you 
could very easily build up a sizable attack.

--
Jeff Walter
Network Engineer
Hurricane Electric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jeffw.vcf
Type: text/x-vcard
Size: 305 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110906/9e112816/attachment.vcf>

From positivelyoptimistic at gmail.com  Tue Sep  6 08:49:13 2011
From: positivelyoptimistic at gmail.com (Positively Optimistic)
Date: Tue, 6 Sep 2011 08:49:13 -0500
Subject: Point to MultiPoint VPN w/qos
Message-ID: <CALBMW53T6GBAomKfY+cKh4p3zxRoe2vs4oR1OSg8BpP1+R_g=g@mail.gmail.com>

Greetings

We have acquired a new client that has 98 remote endpoints.  At each site
there is a need for 4 ip telephones and two vpn tunnels back to
two separate datacenters.  (1 voice, 1 citrix farm).   The sites don't talk
to each other, just to the two data centers.

Does anyone have a suggestion for a single piece of hardware that would
support 8 or less Ethernet interfaces and the two vpn tunnels ?

Thanks
-Optimistic


From brandon.kim at brandontek.com  Tue Sep  6 09:19:34 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Tue, 6 Sep 2011 10:19:34 -0400
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <CALBMW53T6GBAomKfY+cKh4p3zxRoe2vs4oR1OSg8BpP1+R_g=g@mail.gmail.com>
References: <CALBMW53T6GBAomKfY+cKh4p3zxRoe2vs4oR1OSg8BpP1+R_g=g@mail.gmail.com>
Message-ID: <BLU158-W653956F0D921B4490C402FDC1C0@phx.gbl>


Yes, a SonicWALL NSA 240 has 8 interfaces built in....

This sounds like a very fun project....



> Date: Tue, 6 Sep 2011 08:49:13 -0500
> Subject: Point to MultiPoint VPN w/qos
> From: positivelyoptimistic at gmail.com
> To: nanog at nanog.org
> 
> Greetings
> 
> We have acquired a new client that has 98 remote endpoints.  At each site
> there is a need for 4 ip telephones and two vpn tunnels back to
> two separate datacenters.  (1 voice, 1 citrix farm).   The sites don't talk
> to each other, just to the two data centers.
> 
> Does anyone have a suggestion for a single piece of hardware that would
> support 8 or less Ethernet interfaces and the two vpn tunnels ?
> 
> Thanks
> -Optimistic
 		 	   		  

From branto at networking-architecture.com  Tue Sep  6 09:26:23 2011
From: branto at networking-architecture.com (Brant I. Stevens)
Date: Tue, 6 Sep 2011 09:26:23 -0500
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <BLU158-W653956F0D921B4490C402FDC1C0@phx.gbl>
Message-ID: <CA8BA4BE.77729%branto@networking-architecture.com>

I would go with Cisco's DMVPN, and its multiple endpoint offerings.  A
19xx router sounds like it would meet your needs for the remotes.

Spoke-to-Spoke tunnels are created on-demand, can use dynamic routing, and
it supports multicast for things like Music on Hold, etc.

Contact me offline and I can share more.

-Brant

On 9/6/11 10:19 AM, "Brandon Kim" <brandon.kim at brandontek.com> wrote:

>
>Yes, a SonicWALL NSA 240 has 8 interfaces built in....
>
>This sounds like a very fun project....
>
>
>
>> Date: Tue, 6 Sep 2011 08:49:13 -0500
>> Subject: Point to MultiPoint VPN w/qos
>> From: positivelyoptimistic at gmail.com
>> To: nanog at nanog.org
>> 
>> Greetings
>> 
>> We have acquired a new client that has 98 remote endpoints.  At each
>>site
>> there is a need for 4 ip telephones and two vpn tunnels back to
>> two separate datacenters.  (1 voice, 1 citrix farm).   The sites don't
>>talk
>> to each other, just to the two data centers.
>> 
>> Does anyone have a suggestion for a single piece of hardware that would
>> support 8 or less Ethernet interfaces and the two vpn tunnels ?
>> 
>> Thanks
>> -Optimistic
> 		 	   		  




From seth.mos at dds.nl  Tue Sep  6 09:36:07 2011
From: seth.mos at dds.nl (Seth Mos)
Date: Tue, 06 Sep 2011 16:36:07 +0200
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <CALBMW53T6GBAomKfY+cKh4p3zxRoe2vs4oR1OSg8BpP1+R_g=g@mail.gmail.com>
References: <CALBMW53T6GBAomKfY+cKh4p3zxRoe2vs4oR1OSg8BpP1+R_g=g@mail.gmail.com>
Message-ID: <4E662FD7.2050902@dds.nl>

On 6-9-2011 15:49, Positively Optimistic wrote:
> Greetings

> Does anyone have a suggestion for a single piece of hardware that would
> support 8 or less Ethernet interfaces and the two vpn tunnels ?

Single piece of hardware, no. If 2, then yes.

A PCengines Alix 2D3 with pfSense/m0n0wall and OpenVPN UDP tunnels to 
the datacenter combined with a Power over Ethernet switch would seem a 
likely combination. A HP Procurve 8 Port gigabit desktop switch with PoE 
comes to mind. Not too expensive, fanless, quiet, reliable does VLANS.

That way you can power the router and phones from the same (smallish) 
UPS. Say a 700VA APC.

Regards,
Seth



From bhmccie at gmail.com  Tue Sep  6 10:15:19 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Tue, 06 Sep 2011 10:15:19 -0500
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <4E662FD7.2050902@dds.nl>
References: <CALBMW53T6GBAomKfY+cKh4p3zxRoe2vs4oR1OSg8BpP1+R_g=g@mail.gmail.com>
 <4E662FD7.2050902@dds.nl>
Message-ID: <4E663907.7010706@gmail.com>

CheckPoint Series 80 has 10 ports.
I think there is a Juniper option as well.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 09/06/2011 09:36 AM, Seth Mos wrote:
> On 6-9-2011 15:49, Positively Optimistic wrote:
>> Greetings
>
>> Does anyone have a suggestion for a single piece of hardware that would
>> support 8 or less Ethernet interfaces and the two vpn tunnels ?
>
> Single piece of hardware, no. If 2, then yes.
>
> A PCengines Alix 2D3 with pfSense/m0n0wall and OpenVPN UDP tunnels to 
> the datacenter combined with a Power over Ethernet switch would seem a 
> likely combination. A HP Procurve 8 Port gigabit desktop switch with 
> PoE comes to mind. Not too expensive, fanless, quiet, reliable does 
> VLANS.
>
> That way you can power the router and phones from the same (smallish) 
> UPS. Say a 700VA APC.
>
> Regards,
> Seth
>


From mark at pcinw.net  Tue Sep  6 10:26:51 2011
From: mark at pcinw.net (Mark Grigsby)
Date: Tue, 6 Sep 2011 08:26:51 -0700
Subject: DDoS - CoD?
In-Reply-To: <4E662473.4090303@he.net>
References: <4E65D182.8010008@blackhat.bz>
	<4E662473.4090303@he.net>
Message-ID: <CAKwRnJO0su1OAxVJ-9AWwmjnm1a7aS4ZFP6fUgfXLoSoCFMZ6g@mail.gmail.com>

Recently (last month) Ryan Gordon (the person responsible for porting COD to
Linux) released a patch for cod4 servers to address this specific issue.
 Here is the announcement and a link to the original email as well.  The
discussion also indicated that all of the Quake III based games suffered
from the same issue.

http://icculus.org/pipermail/cod/2011-August/015397.html

So we're getting reports of DDoS attacks, where botnets will send
> infostring queries to COD4 dedicated servers as fast as possible with
> spoofed addresses. They send a small UDP packet, and the server replies
> with a larger packet to the faked address. Multiply this by however fast
> you can stuff UDP packets into the server's incoming packet buffer per
> frame, times 7500+ public COD4 servers, and you can really bring a
> victim to its knees with a serious flood of unwanted packets.
>
> I've got a patch for COD4 for this, and I need admins to test it before
> I make an official release.
>
>     http://treefort.icculus.org/cod/cod4-lnxsrv-query-limit-test.tar.bz2
>
>
>
On Tue, Sep 6, 2011 at 6:47 AM, Jeff Walter <jeffw at he.net> wrote:

> Call of Duty is apparently using the same flawed protocol as Quake III
> servers, so you can think of it as an amplification attack.  (I wish I'd
> forgotten all about this stuff)
>
> You send "\xff\xff\xff\xffgetstatus\n" in a UDP packet with a spoofed
> source, and the server responds with everything you see.  With decent
> amplification (15B -> ~500B) and the number of CoD servers in world you
> could very easily build up a sizable attack.
>
> --
> Jeff Walter
> Network Engineer
> Hurricane Electric
>



-- 
Mark Grigsby
Network Operations Manager
PCINW (Preferred Connections Inc., NW)
3555 Gateway St. Ste. 205
Springfield, OR  97477
Voice: 800-787-3806 ext 408
DID: 541-762-1171
Fax:  541-684-0283


From rfinnesey at gmail.com  Tue Sep  6 12:22:47 2011
From: rfinnesey at gmail.com (Ryan Finnesey)
Date: Tue, 6 Sep 2011 13:22:47 -0400
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <CA8BA4BE.77729%branto@networking-architecture.com>
References: <BLU158-W653956F0D921B4490C402FDC1C0@phx.gbl>
 <CA8BA4BE.77729%branto@networking-architecture.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAACqNAZXa6FBHvI6J2nlPAwsBAAAAAA==@gmail.com>

DMVPN would only work with 100% cisco hardware right?  

-----Original Message-----
From: Brant I. Stevens [mailto:branto at networking-architecture.com] 
Sent: Tuesday, September 06, 2011 10:26 AM
To: Brandon Kim; positivelyoptimistic at gmail.com; nanog group
Subject: Re: Point to MultiPoint VPN w/qos

I would go with Cisco's DMVPN, and its multiple endpoint offerings.  A 19xx
router sounds like it would meet your needs for the remotes.

Spoke-to-Spoke tunnels are created on-demand, can use dynamic routing, and
it supports multicast for things like Music on Hold, etc.

Contact me offline and I can share more.

-Brant

On 9/6/11 10:19 AM, "Brandon Kim" <brandon.kim at brandontek.com> wrote:

>
>Yes, a SonicWALL NSA 240 has 8 interfaces built in....
>
>This sounds like a very fun project....
>
>
>
>> Date: Tue, 6 Sep 2011 08:49:13 -0500
>> Subject: Point to MultiPoint VPN w/qos
>> From: positivelyoptimistic at gmail.com
>> To: nanog at nanog.org
>> 
>> Greetings
>> 
>> We have acquired a new client that has 98 remote endpoints.  At each 
>>site  there is a need for 4 ip telephones and two vpn tunnels back to
>> two separate datacenters.  (1 voice, 1 citrix farm).   The sites don't
>>talk
>> to each other, just to the two data centers.
>> 
>> Does anyone have a suggestion for a single piece of hardware that 
>> would support 8 or less Ethernet interfaces and the two vpn tunnels ?
>> 
>> Thanks
>> -Optimistic
> 		 	   		  






From jml at packetpimp.org  Tue Sep  6 12:33:04 2011
From: jml at packetpimp.org (Jason LeBlanc)
Date: Tue, 06 Sep 2011 13:33:04 -0400
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAACqNAZXa6FBHvI6J2nlPAwsBAAAAAA==@gmail.com>
References: <BLU158-W653956F0D921B4490C402FDC1C0@phx.gbl>
 <CA8BA4BE.77729%branto@networking-architecture.com>
 <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAACqNAZXa6FBHvI6J2nlPAwsBAAAAAA==@gmail.com>
Message-ID: <4E665950.5080806@packetpimp.org>

Correct.  But it works very well and is really simple to build and 
manage.  We use 8xx routers on our spokes, very cheap.

On 09/06/2011 01:22 PM, Ryan Finnesey wrote:
> DMVPN would only work with 100% cisco hardware right?
>
> -----Original Message-----
> From: Brant I. Stevens [mailto:branto at networking-architecture.com]
> Sent: Tuesday, September 06, 2011 10:26 AM
> To: Brandon Kim; positivelyoptimistic at gmail.com; nanog group
> Subject: Re: Point to MultiPoint VPN w/qos
>
> I would go with Cisco's DMVPN, and its multiple endpoint offerings.  A 19xx
> router sounds like it would meet your needs for the remotes.
>
> Spoke-to-Spoke tunnels are created on-demand, can use dynamic routing, and
> it supports multicast for things like Music on Hold, etc.
>
> Contact me offline and I can share more.
>
> -Brant
>
> On 9/6/11 10:19 AM, "Brandon Kim"<brandon.kim at brandontek.com>  wrote:
>
>> Yes, a SonicWALL NSA 240 has 8 interfaces built in....
>>
>> This sounds like a very fun project....
>>
>>
>>
>>> Date: Tue, 6 Sep 2011 08:49:13 -0500
>>> Subject: Point to MultiPoint VPN w/qos
>>> From: positivelyoptimistic at gmail.com
>>> To: nanog at nanog.org
>>>
>>> Greetings
>>>
>>> We have acquired a new client that has 98 remote endpoints.  At each
>>> site  there is a need for 4 ip telephones and two vpn tunnels back to
>>> two separate datacenters.  (1 voice, 1 citrix farm).   The sites don't
>>> talk
>>> to each other, just to the two data centers.
>>>
>>> Does anyone have a suggestion for a single piece of hardware that
>>> would support 8 or less Ethernet interfaces and the two vpn tunnels ?
>>>
>>> Thanks
>>> -Optimistic
>> 		 	   		
>
>
>



From garrett at skjelstad.org  Tue Sep  6 12:34:16 2011
From: garrett at skjelstad.org (Garrett Skjelstad)
Date: Tue, 6 Sep 2011 10:34:16 -0700
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAACqNAZXa6FBHvI6J2nlPAwsBAAAAAA==@gmail.com>
References: <BLU158-W653956F0D921B4490C402FDC1C0@phx.gbl>
 <CA8BA4BE.77729%branto@networking-architecture.com>
 <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAACqNAZXa6FBHvI6J2nlPAwsBAAAAAA==@gmail.com>
Message-ID: <90D9F695-D31D-4051-BAF8-FD78D01C0EB7@skjelstad.org>

Yes, but look in 891s at the remotes, the 19xx are too expensive for only 4 devices.... Just my 2c

Sent from my iPhone

On Sep 6, 2011, at 10:22, "Ryan Finnesey" <rfinnesey at gmail.com> wrote:

> DMVPN would only work with 100% cisco hardware right?  
> 
> -----Original Message-----
> From: Brant I. Stevens [mailto:branto at networking-architecture.com] 
> Sent: Tuesday, September 06, 2011 10:26 AM
> To: Brandon Kim; positivelyoptimistic at gmail.com; nanog group
> Subject: Re: Point to MultiPoint VPN w/qos
> 
> I would go with Cisco's DMVPN, and its multiple endpoint offerings.  A 19xx
> router sounds like it would meet your needs for the remotes.
> 
> Spoke-to-Spoke tunnels are created on-demand, can use dynamic routing, and
> it supports multicast for things like Music on Hold, etc.
> 
> Contact me offline and I can share more.
> 
> -Brant
> 
> On 9/6/11 10:19 AM, "Brandon Kim" <brandon.kim at brandontek.com> wrote:
> 
>> 
>> Yes, a SonicWALL NSA 240 has 8 interfaces built in....
>> 
>> This sounds like a very fun project....
>> 
>> 
>> 
>>> Date: Tue, 6 Sep 2011 08:49:13 -0500
>>> Subject: Point to MultiPoint VPN w/qos
>>> From: positivelyoptimistic at gmail.com
>>> To: nanog at nanog.org
>>> 
>>> Greetings
>>> 
>>> We have acquired a new client that has 98 remote endpoints.  At each 
>>> site  there is a need for 4 ip telephones and two vpn tunnels back to
>>> two separate datacenters.  (1 voice, 1 citrix farm).   The sites don't
>>> talk
>>> to each other, just to the two data centers.
>>> 
>>> Does anyone have a suggestion for a single piece of hardware that 
>>> would support 8 or less Ethernet interfaces and the two vpn tunnels ?
>>> 
>>> Thanks
>>> -Optimistic
>>                         
> 
> 
> 
> 



From dylan.ebner at crlmed.com  Tue Sep  6 13:07:47 2011
From: dylan.ebner at crlmed.com (Dylan Ebner)
Date: Tue, 6 Sep 2011 18:07:47 +0000
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <90D9F695-D31D-4051-BAF8-FD78D01C0EB7@skjelstad.org>
References: <BLU158-W653956F0D921B4490C402FDC1C0@phx.gbl>
 <CA8BA4BE.77729%branto@networking-architecture.com>
 <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAACqNAZXa6FBHvI6J2nlPAwsBAAAAAA==@gmail.com>
 <90D9F695-D31D-4051-BAF8-FD78D01C0EB7@skjelstad.org>
Message-ID: <017265BF3B9640499754DD48777C3D2071EE04EF1E@MBX9.EXCHPROD.USA.NET>

IFRC, the 19xx and 18xx are slower than the new 89x series. We are transitioning away from 18xx because of limitations on the platform that the 89x doesn't have. When the 18xx came out a few years ago they were amazing, the new 89x are even better.
 



Dylan 


-----Original Message-----
From: Garrett Skjelstad [mailto:garrett at skjelstad.org] 
Sent: Tuesday, September 06, 2011 12:34 PM
To: Ryan Finnesey
Cc: nanoggroup
Subject: Re: Point to MultiPoint VPN w/qos

Yes, but look in 891s at the remotes, the 19xx are too expensive for only 4 devices.... Just my 2c

Sent from my iPhone

On Sep 6, 2011, at 10:22, "Ryan Finnesey" <rfinnesey at gmail.com> wrote:

> DMVPN would only work with 100% cisco hardware right?  
> 
> -----Original Message-----
> From: Brant I. Stevens [mailto:branto at networking-architecture.com] 
> Sent: Tuesday, September 06, 2011 10:26 AM
> To: Brandon Kim; positivelyoptimistic at gmail.com; nanog group
> Subject: Re: Point to MultiPoint VPN w/qos
> 
> I would go with Cisco's DMVPN, and its multiple endpoint offerings.  A 19xx
> router sounds like it would meet your needs for the remotes.
> 
> Spoke-to-Spoke tunnels are created on-demand, can use dynamic routing, and
> it supports multicast for things like Music on Hold, etc.
> 
> Contact me offline and I can share more.
> 
> -Brant
> 
> On 9/6/11 10:19 AM, "Brandon Kim" <brandon.kim at brandontek.com> wrote:
> 
>> 
>> Yes, a SonicWALL NSA 240 has 8 interfaces built in....
>> 
>> This sounds like a very fun project....
>> 
>> 
>> 
>>> Date: Tue, 6 Sep 2011 08:49:13 -0500
>>> Subject: Point to MultiPoint VPN w/qos
>>> From: positivelyoptimistic at gmail.com
>>> To: nanog at nanog.org
>>> 
>>> Greetings
>>> 
>>> We have acquired a new client that has 98 remote endpoints.  At each 
>>> site  there is a need for 4 ip telephones and two vpn tunnels back to
>>> two separate datacenters.  (1 voice, 1 citrix farm).   The sites don't
>>> talk
>>> to each other, just to the two data centers.
>>> 
>>> Does anyone have a suggestion for a single piece of hardware that 
>>> would support 8 or less Ethernet interfaces and the two vpn tunnels ?
>>> 
>>> Thanks
>>> -Optimistic
>>                         
> 
> 
> 
> 




From branto at networking-architecture.com  Tue Sep  6 13:10:22 2011
From: branto at networking-architecture.com (Brant I. Stevens)
Date: Tue, 6 Sep 2011 13:10:22 -0500
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <90D9F695-D31D-4051-BAF8-FD78D01C0EB7@skjelstad.org>
References: <BLU158-W653956F0D921B4490C402FDC1C0@phx.gbl>
 <CA8BA4BE.77729%branto@networking-architecture.com>
 <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAACqNAZXa6FBHvI6J2nlPAwsBAAAAAA==@gmail.com>
 <90D9F695-D31D-4051-BAF8-FD78D01C0EB7@skjelstad.org>
Message-ID: <B345F3B7-43B3-4C19-9DF7-F56670C70F19@networking-architecture.com>

I'd say the 89x platform is the way to go if 8 ports weren't needed.  Correct me if i am wrong...

Sent from my iPad

On Sep 6, 2011, at 1:34 PM, "Garrett Skjelstad" <garrett at skjelstad.org> wrote:

> Yes, but look in 891s at the remotes, the 19xx are too expensive for only 4 devices.... Just my 2c
> 
> Sent from my iPhone
> 
> On Sep 6, 2011, at 10:22, "Ryan Finnesey" <rfinnesey at gmail.com> wrote:
> 
>> DMVPN would only work with 100% cisco hardware right?  
>> 
>> -----Original Message-----
>> From: Brant I. Stevens [mailto:branto at networking-architecture.com] 
>> Sent: Tuesday, September 06, 2011 10:26 AM
>> To: Brandon Kim; positivelyoptimistic at gmail.com; nanog group
>> Subject: Re: Point to MultiPoint VPN w/qos
>> 
>> I would go with Cisco's DMVPN, and its multiple endpoint offerings.  A 19xx
>> router sounds like it would meet your needs for the remotes.
>> 
>> Spoke-to-Spoke tunnels are created on-demand, can use dynamic routing, and
>> it supports multicast for things like Music on Hold, etc.
>> 
>> Contact me offline and I can share more.
>> 
>> -Brant
>> 
>> On 9/6/11 10:19 AM, "Brandon Kim" <brandon.kim at brandontek.com> wrote:
>> 
>>> 
>>> Yes, a SonicWALL NSA 240 has 8 interfaces built in....
>>> 
>>> This sounds like a very fun project....
>>> 
>>> 
>>> 
>>>> Date: Tue, 6 Sep 2011 08:49:13 -0500
>>>> Subject: Point to MultiPoint VPN w/qos
>>>> From: positivelyoptimistic at gmail.com
>>>> To: nanog at nanog.org
>>>> 
>>>> Greetings
>>>> 
>>>> We have acquired a new client that has 98 remote endpoints.  At each 
>>>> site  there is a need for 4 ip telephones and two vpn tunnels back to
>>>> two separate datacenters.  (1 voice, 1 citrix farm).   The sites don't
>>>> talk
>>>> to each other, just to the two data centers.
>>>> 
>>>> Does anyone have a suggestion for a single piece of hardware that 
>>>> would support 8 or less Ethernet interfaces and the two vpn tunnels ?
>>>> 
>>>> Thanks
>>>> -Optimistic
>>> 
>> 
>> 
>> 
>> 



From sethm at rollernet.us  Tue Sep  6 13:16:40 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 06 Sep 2011 11:16:40 -0700
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <B345F3B7-43B3-4C19-9DF7-F56670C70F19@networking-architecture.com>
References: <BLU158-W653956F0D921B4490C402FDC1C0@phx.gbl>
 <CA8BA4BE.77729%branto@networking-architecture.com>
 <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAACqNAZXa6FBHvI6J2nlPAwsBAAAAAA==@gmail.com>
 <90D9F695-D31D-4051-BAF8-FD78D01C0EB7@skjelstad.org>
 <B345F3B7-43B3-4C19-9DF7-F56670C70F19@networking-architecture.com>
Message-ID: <4E666388.60605@rollernet.us>

On 9/6/11 11:10 AM, Brant I. Stevens wrote:
> I'd say the 89x platform is the way to go if 8 ports weren't needed.  Correct me if i am wrong...
> 

I believe the 89x have a built-in 8 port switch plus 2 WAN Ethernet.

~Seth




From dylan.ebner at crlmed.com  Tue Sep  6 13:18:08 2011
From: dylan.ebner at crlmed.com (Dylan Ebner)
Date: Tue, 6 Sep 2011 18:18:08 +0000
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <4E666388.60605@rollernet.us>
References: <BLU158-W653956F0D921B4490C402FDC1C0@phx.gbl>
 <CA8BA4BE.77729%branto@networking-architecture.com>
 <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAACqNAZXa6FBHvI6J2nlPAwsBAAAAAA==@gmail.com>
 <90D9F695-D31D-4051-BAF8-FD78D01C0EB7@skjelstad.org>
 <B345F3B7-43B3-4C19-9DF7-F56670C70F19@networking-architecture.com>
 <4E666388.60605@rollernet.us>
Message-ID: <017265BF3B9640499754DD48777C3D2071EE04EF39@MBX9.EXCHPROD.USA.NET>

it does. The older 87x only had a 4 port. The new 89x are the replacement for the 181x series. 

Dylan 
-----Original Message-----
From: Seth Mattinen [mailto:sethm at rollernet.us] 
Sent: Tuesday, September 06, 2011 1:17 PM
To: nanog at nanog.org
Subject: Re: Point to MultiPoint VPN w/qos

On 9/6/11 11:10 AM, Brant I. Stevens wrote:
> I'd say the 89x platform is the way to go if 8 ports weren't needed.  Correct me if i am wrong...
> 

I believe the 89x have a built-in 8 port switch plus 2 WAN Ethernet.

~Seth





From george.herbert at gmail.com  Tue Sep  6 13:19:23 2011
From: george.herbert at gmail.com (George Herbert)
Date: Tue, 6 Sep 2011 11:19:23 -0700
Subject: DDoS - CoD?
In-Reply-To: <4E662473.4090303@he.net>
References: <4E65D182.8010008@blackhat.bz>
	<4E662473.4090303@he.net>
Message-ID: <CAK__KzszC1cTe+oHXyQ4F6iqWkMk0su4qEMBLLC216XA2BxvYA@mail.gmail.com>

Arrgghhh....

This reminds me of the WebNFS attack.  Which is why Sun aborted
WebNFS's public launch, after I pointed it out during its Solaris 2.6
early access program.

Never run a volume-multiplying service on UDP if you can help it,
exposed to the outside world, without serious in-band source
verification.  Amplification attacks are a classic easy DDOS win.


-george

On Tue, Sep 6, 2011 at 6:47 AM, Jeff Walter <jeffw at he.net> wrote:
> Call of Duty is apparently using the same flawed protocol as Quake III
> servers, so you can think of it as an amplification attack. ?(I wish I'd
> forgotten all about this stuff)
>
> You send "\xff\xff\xff\xffgetstatus\n" in a UDP packet with a spoofed
> source, and the server responds with everything you see. ?With decent
> amplification (15B -> ~500B) and the number of CoD servers in world you
> could very easily build up a sizable attack.
>
> --
> Jeff Walter
> Network Engineer
> Hurricane Electric
>



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



From branto at networking-architecture.com  Tue Sep  6 13:24:45 2011
From: branto at networking-architecture.com (Brant I. Stevens)
Date: Tue, 6 Sep 2011 13:24:45 -0500
Subject: Point to MultiPoint VPN w/qos
In-Reply-To: <017265BF3B9640499754DD48777C3D2071EE04EF39@MBX9.EXCHPROD.USA.NET>
References: <BLU158-W653956F0D921B4490C402FDC1C0@phx.gbl>
 <CA8BA4BE.77729%branto@networking-architecture.com>
 <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAACqNAZXa6FBHvI6J2nlPAwsBAAAAAA==@gmail.com>
 <90D9F695-D31D-4051-BAF8-FD78D01C0EB7@skjelstad.org>
 <B345F3B7-43B3-4C19-9DF7-F56670C70F19@networking-architecture.com>
 <4E666388.60605@rollernet.us>
 <017265BF3B9640499754DD48777C3D2071EE04EF39@MBX9.EXCHPROD.USA.NET>
Message-ID: <2C908A96-88D2-4526-8C9F-69BEDD322CEE@networking-architecture.com>

I stand corrected.

Sent from my iPad

On Sep 6, 2011, at 2:19 PM, "Dylan Ebner" <dylan.ebner at crlmed.com> wrote:

> it does. The older 87x only had a 4 port. The new 89x are the replacement for the 181x series. 
> 
> Dylan 
> -----Original Message-----
> From: Seth Mattinen [mailto:sethm at rollernet.us] 
> Sent: Tuesday, September 06, 2011 1:17 PM
> To: nanog at nanog.org
> Subject: Re: Point to MultiPoint VPN w/qos
> 
> On 9/6/11 11:10 AM, Brant I. Stevens wrote:
>> I'd say the 89x platform is the way to go if 8 ports weren't needed.  Correct me if i am wrong...
>> 
> 
> I believe the 89x have a built-in 8 port switch plus 2 WAN Ethernet.
> 
> ~Seth
> 
> 
> 



From efbatey at gmail.com  Tue Sep  6 13:32:57 2011
From: efbatey at gmail.com (Everett Batey)
Date: Tue, 6 Sep 2011 11:32:57 -0700
Subject: Handicapped Supporting ISP's -- Was Re: NANOG Digest, Vol 44, Issue 21
Message-ID: <CAFBwhDbZ8SfFUpk6gTUcGOebz7724T_t5Emax2QpwoyAvmo_uw@mail.gmail.com>

If you can offer any lead(s) to service providers who may subsidize /
partially subsidize adult handicapped for internet service in LA County CA,
please, advise me on or off net.

Thank you

-- 
 R/  Everett Batey / Skype: wa6cre-10 / efbatey at gmail.com
  or efbarc at cotdazr.org or lioneverett at gmail.com / CrisisLinks
http://bit.ly/cw95Um
    (805) 616-2471 / G-Talk/Twitter: efbatey


On Tue, Sep 6, 2011 at 11:19 AM, <nanog-request at nanog.org> wrote:

> Send NANOG mailing list submissions to
>        nanog at nanog.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://mailman.nanog.org/mailman/listinfo/nanog
> or, via email, send a message with subject or body 'help' to
>
> End of NANOG Digest, Vol 44, Issue 21
> *************************************
>


From Valdis.Kletnieks at vt.edu  Tue Sep  6 14:25:44 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 06 Sep 2011 15:25:44 -0400
Subject: Handicapped Supporting ISP's -- Was Re: NANOG Digest, Vol 44,
 Issue 21
In-Reply-To: Your message of "Tue, 06 Sep 2011 11:32:57 PDT."
 <CAFBwhDbZ8SfFUpk6gTUcGOebz7724T_t5Emax2QpwoyAvmo_uw@mail.gmail.com>
References: <CAFBwhDbZ8SfFUpk6gTUcGOebz7724T_t5Emax2QpwoyAvmo_uw@mail.gmail.com>
Message-ID: <19241.1315337144@turing-police.cc.vt.edu>

On Tue, 06 Sep 2011 11:32:57 PDT, Everett Batey said:
> If you can offer any lead(s) to service providers who may subsidize /
> partially subsidize adult handicapped for internet service in LA County CA,
> please, advise me on or off net.

I can't help with the query as phrased - but would you also want to hear about
other programs that provide subsidies, even if the programs aren't run by the
service providers themselves (i.e "the LA County Deptartment of Foo will pay
half the basic monthly bill for low-income shut-ins" or similar)?

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

From frnkblk at iname.com  Tue Sep  6 16:35:41 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Tue, 6 Sep 2011 16:35:41 -0500
Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down
 for 10 days
In-Reply-To: <0C6A4A8DD60DBF4A99C300DDA771BFAB01DEB4E3C153@server3.MUTUALTEL.MTCNET.NET>
References: <000001cc5d68$93fc01d0$bbf40570$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643976AA@EALPO1.ukbroadband.com>
 <3A807C2C-9DD2-4A40-B11E-8583F2C562B6@delong.com>
 <ECB36694-DA05-4B05-B9A0-27BCC312BAB0@internode.com.au>
 <E1DD60718964C54A96C04CA9CB0BA811013D0286F42A@server3.MUTUALTEL.MTCNET.NET>
 <001001cc5e91$598b9310$0ca2b930$@iname.com>
 <0C6A4A8DD60DBF4A99C300DDA771BFAB01DEB4E3C153@server3.MUTUALTEL.MTCNET.NET>
Message-ID: <00b001cc6cdc$ed323fc0$c796bf40$@iname.com>

...and the AAAA's are back!  And port 80 responds.

Frank

-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Thursday, September 01, 2011 5:03 PM
To: 'nanog at nanog.org'
Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days

Charter.com has also remove the quad-A's for www.charter.com.  My monitoring
system alerted me this afternoon that it couldn't get to the v6 version of
their website.  Because of DNS caching, I don't know how many hours or days
ago it was removed.

Frank

-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Friday, August 19, 2011 11:59 AM
To: nanog at nanog.org
Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days

I just noticed that the quad-A records for both those two hosts are now
gone.  DNS being what it is, I'm not sure when that happened, but our
monitoring system couldn't get the AAAA for www.qwest.com about half an hour
ago.

Hopefully CenturyLink is actively working towards IPv6-enabling their sites
again.

Frank

-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Thursday, August 18, 2011 11:14 PM
To: nanog at nanog.org
Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days

FYI, the issue is not resolved and I've not heard from either of the
companies suggesting that they're working on it.

Note their commitment to IPv6 in these releases:
http://www.prnewswire.com/news-releases/centurylink-joins-internet-community
-in-world-ipv6-day-123089908.html
http://news.centurylink.com/index.php?s=43&item=2129

Frank

-----Original Message-----
From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] 
Sent: Thursday, August 18, 2011 7:08 PM
To: Owen DeLong
Cc: nanog at nanog.org
Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days


On 19/08/2011, at 4:18 AM, Owen DeLong wrote:

It'd really suck for end users to start actively avoiding IPv6 connectivity
because it keeps breaking and for organisations that have active AAAA
records to break peoples connectivity to their resources.



+1 -- I'm all for publishing AAAA records as everyone knows, but, if you
publish AAAA records for a consumer facing service, please support and
monitor that service with a similar level to what you do for your IPv4
versions of the service.

The coming years are going to be difficult enough for end-users without
adding unnecessary anti-IPv6 sentiments to the mix.

Owen

+1 to Owen's comment.

I'd also add some more comments:

A lot of eyeballs that have v6 right now are the people with a lot of clue.
Do you want these people, who'll often be buying or recommending your
services to rate your ability to deliver as a fail?  Our experience with
IPv6 consumer broadband has been that the early adopters are the people who,
well, goto IETF meetings, follow standards and ask the bloody hard
questions.

Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated as
HE?? :-) ) most end users prefer IPv6 over IPv4.  Deeply this means there is
a tendency for v6 traffic to grow and be more important to connectivity than
you may imagine.  The tipping point for IPv6 traffic being dominant I
suspect is going to be a lower threshold of take up than people might
expect.   Consider this when thinking about the level of thought you give to
IPv6 infrastructure and PPS rates.

MMC






From Bryan at bryanfields.net  Tue Sep  6 18:59:45 2011
From: Bryan at bryanfields.net (Bryan Fields)
Date: Tue, 06 Sep 2011 19:59:45 -0400
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <23006012.859.1315276772119.JavaMail.root@benjamin.baylink.com>
References: <23006012.859.1315276772119.JavaMail.root@benjamin.baylink.com>
Message-ID: <4E66B3F1.7020000@bryanfields.net>

On 9/5/2011 22:39, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Joel jaeggli" <joelja at bogus.com>
> 
>> having customers that want to use your service is rarely a bad thing.
> 
> Ask a chief engineer at a national wireless carrier who told his administrative
> bosses that selling "unlimited" wireless data was a Pretty Neat Idea if he
> thinks that's a good generalization to make, Joel.  :-)

Jay, are you saying the engineers in a wireless telecom company are driving
what plans to offer?  Hate to say it, but that's all done by marketing, and
engineering normally finds out about the plans they offer by seeing the
PDSN/SGSN going into overload :D

I would love a world where engineering was consulted by marketing :(
-- 
Bryan Fields

727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net



From surfer at mauigateway.com  Tue Sep  6 19:05:00 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 6 Sep 2011 17:05:00 -0700
Subject: iCloud - Is it going to hurt access providers?
Message-ID: <20110906170500.F7A86CB5@resin11.mta.everyone.net>



--- Bryan at bryanfields.net wrote:
From: Bryan Fields <Bryan at bryanfields.net>

I would love a world where engineering was consulted by marketing :(
---------------------------------------------



WAKE UP!!!!  You're dreaming out loud...  >;-)

scott






From v.jones at networkingunlimited.com  Tue Sep  6 19:34:43 2011
From: v.jones at networkingunlimited.com (Vincent C Jones)
Date: Tue, 06 Sep 2011 20:34:43 -0400
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <20110906170500.F7A86CB5@resin11.mta.everyone.net>
References: <20110906170500.F7A86CB5@resin11.mta.everyone.net>
Message-ID: <1315355683.5347.18.camel@X61.NetworkingUnlimited.com>


> --- Bryan at bryanfields.net wrote:
> From: Bryan Fields <Bryan at bryanfields.net>
> 
> I would love a world where engineering was consulted by marketing :(
> ---------------------------------------------
> 
> WAKE UP!!!!  You're dreaming out loud...  >;-)

Not necessarily...I've been in computer networking going on 40 years and
I've only had one employer where engineering was NOT consulted by
marketing, and that was the military, which did not have marketing :-) 

Of course, my case may be a few sigma away from normal, because I've
only had two other employers since then-- Hewlett Packard back when they
were still a techie company and myself. As an independent consultant, I
am marketing, so I can only blame myself if marketing does not consult
engineering :-D

Vince
-- 
Vincent C. Jones
Networking Unlimited, Inc.
Phone: +1 201 568-7810
V.Jones at NetworkingUnlimited.com






From arturo.servin at gmail.com  Tue Sep  6 19:35:45 2011
From: arturo.servin at gmail.com (Arturo Servin)
Date: Tue, 6 Sep 2011 21:35:45 -0300
Subject: NAT444 or ?
In-Reply-To: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
Message-ID: <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>


	NAT444 alone is not enough.

	You will need to deploy it along with 6rd or DS-lite.

	Whilst you still have global v4, use it. The best is to deploy dual-stack, but that won't last for too long.

Regards,
as-



On 1 Sep 2011, at 15:36, Serge Vautour wrote:

> Hello,
> 
> Things I understand: IPv6 is the long term solution to IPv4 exhaustion. For IPv6 to work correctly, most of the IPv4 content has to be on IPv6. That's not there yet. IPv6 deployment to end users is not trivial (end user support, CPE support, etc...). Translation techniques are generally evil. IPv6->IPv4 still requires 1 IPv4 IP per end user or else you're doing NAT. IPv4->IPv6 (1-1) doesn't solve our main problem of giving users access to the IPv4 Internet.
> 
> 
> I expect like most companies we're faced with having to extend the life of IPv4 since our users will continue to want access to the IPv4 content. Doing that by giving them an IPv6 address is not very feasible yet for many reasons. NAT444 seems like the only solution available while we slowly transition over to IPv6 over the next 20 years. Based on the this RFC, NAT444 breaks a lot of applications!
> 
> http://tools.ietf.org/html/draft-donley-nat444-impacts-01
> 
> Has anyone deployed NAT444? Can folks share their experiences? Does it really break this many apps? What other options do we have? 
> 
> 
> Thanks,
> Serge




From surfer at mauigateway.com  Tue Sep  6 19:56:45 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 6 Sep 2011 17:56:45 -0700
Subject: iCloud - Is it going to hurt access providers?
Message-ID: <20110906175645.F7A869ED@resin11.mta.everyone.net>



--- v.jones at networkingunlimited.com wrote:
From: Vincent C Jones <v.jones at networkingunlimited.com>
> --- Bryan at bryanfields.net wrote:
> From: Bryan Fields <Bryan at bryanfields.net>
> 
> I would love a world where engineering was consulted by marketing :(
> ---------------------------------------------
> 
> WAKE UP!!!!  You're dreaming out loud...  >;-)

Not necessarily...I've been in computer networking going on 40 years and
I've only had one employer where engineering was NOT consulted by
marketing, and that was the military, which did not have marketing :-) 

Of course, my case may be a few sigma away from normal, because I've
only had two other employers since then-- Hewlett Packard back when they
were still a techie company and myself. As an independent consultant, I
am marketing, so I can only blame myself if marketing does not consult
engineering :-D
-----------------------------------------------



How about (yelling again...)

WAKE UP!!!!  You're Rumpelstiltskining  :-)

scott





From tore.anderson at redpill-linpro.com  Wed Sep  7 03:13:35 2011
From: tore.anderson at redpill-linpro.com (Tore Anderson)
Date: Wed, 07 Sep 2011 10:13:35 +0200
Subject: NAT444 or ?
In-Reply-To: <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
Message-ID: <4E6727AF.4000605@redpill-linpro.com>

* Arturo Servin

> 	NAT444 alone is not enough.
> 
> 	You will need to deploy it along with 6rd or DS-lite.

In a typical DS-Lite deployment you won't be using NAT444. One of the
key advantages of DS-Lite (and A+P, I believe) is that there's only one
level of NAT between the end user and the public internet.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com



From randy at psg.com  Wed Sep  7 03:27:22 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 07 Sep 2011 10:27:22 +0200
Subject: NAT444 or ?
In-Reply-To: <4E6727AF.4000605@redpill-linpro.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <4E6727AF.4000605@redpill-linpro.com>
Message-ID: <m2bouwsqol.wl%randy@psg.com>

> In a typical DS-Lite deployment you won't be using NAT444. One of the
> key advantages of DS-Lite (and A+P, I believe) is that there's only one
> level of NAT between the end user and the public internet.

yep.  and in ds-lite that nat is in the core, so you talk to comcast's
lawyers when you need a new alg.  with a+p, the nat is under customer
control, and they just go to best buy to get the cpe that supports the
alg that they want.

randy



From leigh.porter at ukbroadband.com  Wed Sep  7 05:11:18 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 7 Sep 2011 10:11:18 +0000
Subject: NAT444 or ?
In-Reply-To: <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Arturo Servin [mailto:arturo.servin at gmail.com]
> Sent: 07 September 2011 01:37
> To: Serge Vautour
> Cc: nanog at nanog.org
> Subject: Re: NAT444 or ?
> 
> 
> 	NAT444 alone is not enough.
> 
> 	You will need to deploy it along with 6rd or DS-lite.
> 
> 	Whilst you still have global v4, use it. The best is to deploy
> dual-stack, but that won't last for too long.
> 
> Regards,
> as-

I'm going to have to deploy NAT444 with dual-stack real soon now. So I am expecting to see some issues.

A+P would be nicer perhaps, but none of the CPE I have will support it. I'll try and give people who do NAT in their CPE a public address for as long as I can, but it'll soon run out and then NAT444 will have to be used and some things will just not work very well.


--
Leigh Porter



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From randy at psg.com  Wed Sep  7 05:16:28 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 07 Sep 2011 12:16:28 +0200
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
Message-ID: <m2y5y0r72b.wl%randy@psg.com>

> I'm going to have to deploy NAT444 with dual-stack real soon now.

you may want to review the presentations from last week's apnic meeting
in busan.  real mesurements.  sufficiently scary that people who were
heavily pushing nat444 for the last two years suddenly started to say
"it was not me who pushed nat444, it was him!"  as if none of us had a
memory.

randy



From leigh.porter at ukbroadband.com  Wed Sep  7 05:31:40 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 7 Sep 2011 10:31:40 +0000
Subject: NAT444 or ?
In-Reply-To: <m2y5y0r72b.wl%randy@psg.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
 <m2y5y0r72b.wl%randy@psg.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BA7D6@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Randy Bush [mailto:randy at psg.com]
> Sent: 07 September 2011 11:18
> To: Leigh Porter
> Cc: North American Network Operators' Group
> Subject: Re: NAT444 or ?
> 
> > I'm going to have to deploy NAT444 with dual-stack real soon now.
> 
> you may want to review the presentations from last week's apnic meeting
> in busan.  real mesurements.  sufficiently scary that people who were
> heavily pushing nat444 for the last two years suddenly started to say
> "it was not me who pushed nat444, it was him!"  as if none of us had a
> memory.
> 
> randy
>

Thankyou, I'm watching it now, but I am under no illusion that it will work well. NAT44 is bad enough.

--
Leigh




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From jeffw at he.net  Wed Sep  7 10:35:03 2011
From: jeffw at he.net (Jeff Walter)
Date: Wed, 07 Sep 2011 08:35:03 -0700
Subject: DDoS - CoD? - Activision contact
In-Reply-To: <4E6619ED.7000503@blackhat.bz>
References: <4E65D182.8010008@blackhat.bz> <4E65D3EF.5010404@blackhat.bz>
 <CADr-PQ+wjF8OWCoCT5=6bnYnU-yX4oPA4wH7CezghDKWd3rm5A@mail.gmail.com>
 <201109061110.34711.a.harrowell@gmail.com> <4E6619ED.7000503@blackhat.bz>
Message-ID: <4E678F27.4050002@he.net>

On 9/6/2011 6:02 AM, BH wrote:
> Looking around, I believe the issue is that the IP has ended up on a 
> master game list, so we are now getting the queries directed at US.

Having written multiple versions of a Quake III master server (again, 
much self-hate) I pulled one of my old master query scripts out of 
mothballs and checked.  You are not listed on the CoD4 master server 
(assuming you did not alter the UDP frames you originally posted).  If 
you were you would be seeing "getInfo" and "getStatus" queries, but 
you're not.  You're seeing the "getInfoResponse" and "getStatusResponse" 
packets from a server which is listed on the master server.  This is an 
attack, nothing sinister is happening.

Your best bet is to filter all UDP traffic except for what you need (DNS 
comes to mind).  You might also want to get in contact with 
killkuter at hotmail.com and encourage them to install the previously 
mentioned patched server executable to prevent their server from being 
used as an attack amplifier.

--
Jeff Walter
Network Engineer
Hurricane Electric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jeffw.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110907/d730b0ab/attachment.vcf>

From michael.holstein at csuohio.edu  Wed Sep  7 11:02:19 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Wed, 07 Sep 2011 12:02:19 -0400
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <4E66B3F1.7020000@bryanfields.net>
References: <23006012.859.1315276772119.JavaMail.root@benjamin.baylink.com>
 <4E66B3F1.7020000@bryanfields.net>
Message-ID: <4E67958B.1080709@csuohio.edu>


> I would love a world where engineering was consulted by marketing :(
>   

Wouldn't be a problem is management invested based on engineering's
recommendations.

There are few problems that money can't solve .. in this case, it's
"sure, we can offer unlimited bandwidth, we just need to build (x) new
towers at this map of locations, based on our usage patterns".

Michael Holstein
Cleveland State University




From network.ipdog at gmail.com  Wed Sep  7 11:17:10 2011
From: network.ipdog at gmail.com (Network IP Dog)
Date: Wed, 7 Sep 2011 09:17:10 -0700
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
Message-ID: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>

FYI!!!

http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee
ms_all_diginotar_certificates_untrust.html

Google and Mozilla have also updated their browsers to block all DigiNotar
certificates, while Apple has been silent on the issue, a emblematic zombie
response!

Cheers. 


From joelja at bogus.com  Wed Sep  7 11:28:28 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Wed, 07 Sep 2011 09:28:28 -0700
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <4E67958B.1080709@csuohio.edu>
References: <23006012.859.1315276772119.JavaMail.root@benjamin.baylink.com>
 <4E66B3F1.7020000@bryanfields.net> <4E67958B.1080709@csuohio.edu>
Message-ID: <4E679BAC.4090206@bogus.com>

On 9/7/11 09:02 , Michael Holstein wrote:
> 
>> I would love a world where engineering was consulted by marketing :(
>>   
> 
> Wouldn't be a problem is management invested based on engineering's
> recommendations.
> 
> There are few problems that money can't solve .. in this case, it's
> "sure, we can offer unlimited bandwidth, we just need to build (x) new
> towers at this map of locations, based on our usage patterns".

The way to achieve a return on invested capital is to attract and retain
customers who pay for a service which they find compelling.

> Michael Holstein
> Cleveland State University
> 
> 




From a.harrowell at gmail.com  Wed Sep  7 11:34:50 2011
From: a.harrowell at gmail.com (Alexander Harrowell)
Date: Wed, 7 Sep 2011 17:34:50 +0100
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
Message-ID: <201109071735.11540.a.harrowell@gmail.com>

On Wednesday 07 Sep 2011 17:17:10 Network IP Dog wrote:
> FYI!!!
> 
> 
http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee
> ms_all_diginotar_certificates_untrust.html
> 
> Google and Mozilla have also updated their browsers to block all 
DigiNotar
> certificates, while Apple has been silent on the issue, a emblematic 
zombie
> response!
> 
> Cheers. 
> 


It would be really nice if the folk at Twitter would fix their images 
servers (i.e si*.twimg.com) to use a non-evil CA (i.e. not Comodo or 
DigiNotar or Bubba Gump's Bait, Firearms & Crypto Verification). Not 
that user pics are a great loss, but if you use 
Tweetdeck/Seesmic/whatever, the constant SSL cert warnings from dozens-
to-hundreds of user pics are noisy.


This is trivial whining on my part but it is operational.

-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110907/6cb20ff6/attachment.bin>

From dr at cluenet.de  Wed Sep  7 11:36:56 2011
From: dr at cluenet.de (Daniel Roesen)
Date: Wed, 7 Sep 2011 18:36:56 +0200
Subject: NAT444 or ?
In-Reply-To: <m2y5y0r72b.wl%randy@psg.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
 <m2y5y0r72b.wl%randy@psg.com>
Message-ID: <20110907163656.GA9961@srv03.cluenet.de>

On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote:
> > I'm going to have to deploy NAT444 with dual-stack real soon now.
> 
> you may want to review the presentations from last week's apnic meeting
> in busan.  real mesurements.  sufficiently scary that people who were
> heavily pushing nat444 for the last two years suddenly started to say
> "it was not me who pushed nat444, it was him!"  as if none of us had a
> memory.

Hm, I fail to find relevant slides discussing that. Could you please
point us to those?

I'm looking at http://meetings.apnic.net/32

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From Valdis.Kletnieks at vt.edu  Wed Sep  7 11:37:28 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 07 Sep 2011 12:37:28 -0400
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: Your message of "Wed, 07 Sep 2011 09:28:28 PDT."
 <4E679BAC.4090206@bogus.com>
References: <23006012.859.1315276772119.JavaMail.root@benjamin.baylink.com>
 <4E66B3F1.7020000@bryanfields.net> <4E67958B.1080709@csuohio.edu>
 <4E679BAC.4090206@bogus.com>
Message-ID: <3709.1315413448@turing-police.cc.vt.edu>

On Wed, 07 Sep 2011 09:28:28 PDT, Joel jaeggli said:

> The way to achieve a return on invested capital is to attract and retain
> customers who pay for a service which they find compelling.

Only true if long-term returns on investment are suitable for consideration
instead of short-term returns.

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

From leigh.porter at ukbroadband.com  Wed Sep  7 11:41:43 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 7 Sep 2011 16:41:43 +0000
Subject: NAT444 or ?
In-Reply-To: <20110907163656.GA9961@srv03.cluenet.de>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
 <m2y5y0r72b.wl%randy@psg.com> <20110907163656.GA9961@srv03.cluenet.de>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BAB51@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Daniel Roesen [mailto:dr at cluenet.de]
> Sent: 07 September 2011 17:38
> To: nanog at nanog.org
> Subject: Re: NAT444 or ?
> 
> On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote:
> > > I'm going to have to deploy NAT444 with dual-stack real soon now.
> >
> > you may want to review the presentations from last week's apnic
> meeting
> > in busan.  real mesurements.  sufficiently scary that people who were
> > heavily pushing nat444 for the last two years suddenly started to say
> > "it was not me who pushed nat444, it was him!"  as if none of us had
> a
> > memory.
> 
> Hm, I fail to find relevant slides discussing that. Could you please
> point us to those?
> 
> I'm looking at http://meetings.apnic.net/32
> 
> Best regards,
> Daniel

There is a lot in the IPv6 plenary sessions:

http://meetings.apnic.net/32/program/ipv6

This is what I am looking at right now. Randy makes some good comments in those sessions. I have not found anything yet, but I am only on session 3, pertaining specifically to issues around NAT444.

I would be looking for issues such as implementing ALGs on both NAT devices, ALG scaling on LSN boxes and issues surrounding application compatibility. I'm also looking at NAT logging for law enforcement issues. 

Is there anything planned for the next NANOG around these issues?

--
Leigh


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From joelja at bogus.com  Wed Sep  7 11:40:53 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Wed, 07 Sep 2011 09:40:53 -0700
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <3709.1315413448@turing-police.cc.vt.edu>
References: <23006012.859.1315276772119.JavaMail.root@benjamin.baylink.com>
 <4E66B3F1.7020000@bryanfields.net> <4E67958B.1080709@csuohio.edu>
 <4E679BAC.4090206@bogus.com> <3709.1315413448@turing-police.cc.vt.edu>
Message-ID: <4E679E95.4060109@bogus.com>

On 9/7/11 09:37 , Valdis.Kletnieks at vt.edu wrote:
> On Wed, 07 Sep 2011 09:28:28 PDT, Joel jaeggli said:
> 
>> The way to achieve a return on invested capital is to attract and retain
>> customers who pay for a service which they find compelling.
> 
> Only true if long-term returns on investment are suitable for consideration
> instead of short-term returns.

When was the last time you built out a network plant for a quarterly pop?




From cb.list6 at gmail.com  Wed Sep  7 11:46:01 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Wed, 7 Sep 2011 09:46:01 -0700
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <4E679BAC.4090206@bogus.com>
References: <23006012.859.1315276772119.JavaMail.root@benjamin.baylink.com>
 <4E66B3F1.7020000@bryanfields.net> <4E67958B.1080709@csuohio.edu>
 <4E679BAC.4090206@bogus.com>
Message-ID: <CAD6AjGS1iGU-qZ+d+SuTAsfK79OGVy3-Gw-5SUyKsSg56B935A@mail.gmail.com>

On Wed, Sep 7, 2011 at 9:28 AM, Joel jaeggli <joelja at bogus.com> wrote:
> On 9/7/11 09:02 , Michael Holstein wrote:
>>
>>> I would love a world where engineering was consulted by marketing :(
>>>
>>
>> Wouldn't be a problem is management invested based on engineering's
>> recommendations.
>>
>> There are few problems that money can't solve .. in this case, it's
>> "sure, we can offer unlimited bandwidth, we just need to build (x) new
>> towers at this map of locations, based on our usage patterns".
>
> The way to achieve a return on invested capital is to attract and retain
> customers who pay for a service which they find compelling.

Good simplification, but i think this thread is about the word "pay"
.... who and how much.



From Jean-Francois.TremblayING at videotron.com  Wed Sep  7 12:06:11 2011
From: Jean-Francois.TremblayING at videotron.com (Jean-Francois.TremblayING at videotron.com)
Date: Wed, 7 Sep 2011 13:06:11 -0400
Subject: NAT444 or ?
In-Reply-To: <20110907163656.GA9961@srv03.cluenet.de>
Message-ID: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>

On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote:
> > I'm going to have to deploy NAT444 with dual-stack real soon now.
> you may want to review the presentations from last week's apnic meeting
> in busan.  real mesurements.  sufficiently scary that people who were
> heavily pushing nat444 for the last two years suddenly started to say
> "it was not me who pushed nat444, it was him!"  as if none of us had a
> memory. 
>
> Hm, I fail to find relevant slides discussing that. Could you please
> point us to those?

I had the same question. I found Miyakawa-san's presentation has some 
dramatic examples of CGN NAT444 effects using Google Maps: 
http://meetings.apnic.net/__data/assets/file/0011/38297/Miyakawa-APNIC-KEYNOTE-IPv6-2011-8.pptx.pdf 


However these are with a very high address-sharing ratio (several 
thousands users per address). Using a sparser density (<= 64 users per 
address) is likely to show much less dramatic user impacts. 

/JF 

From dr at cluenet.de  Wed Sep  7 12:10:49 2011
From: dr at cluenet.de (Daniel Roesen)
Date: Wed, 7 Sep 2011 19:10:49 +0200
Subject: NAT444 or ?
In-Reply-To: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
References: <20110907163656.GA9961@srv03.cluenet.de>
 <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
Message-ID: <20110907171049.GA16507@srv03.cluenet.de>

On Wed, Sep 07, 2011 at 01:06:11PM -0400, Jean-Francois.TremblayING at videotron.com wrote:
> I had the same question. I found Miyakawa-san's presentation has some 
> dramatic examples of CGN NAT444 effects using Google Maps: 
> http://meetings.apnic.net/__data/assets/file/0011/38297/Miyakawa-APNIC-KEYNOTE-IPv6-2011-8.pptx.pdf 

Those effects are not specific to NAT444, but apply to any
provider-based NAT limiting the amount of parallel sessions available to
any one customer. Randy was (as I understood him) referring to the
evilness of double-NAT in contrast to single-state NAT (as used with
e.g. DS-Lite).

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From nonobvious at gmail.com  Wed Sep  7 12:39:02 2011
From: nonobvious at gmail.com (Bill Stewart)
Date: Wed, 7 Sep 2011 10:39:02 -0700
Subject: NANOGers home data centers - What's in your closet?
In-Reply-To: <4E4B9F7F.7070106@emmanuelcomputerconsulting.com>
References: <4E45B739.7040909@knownelement.com>
 <4E4AD305.9090108@emmanuelcomputerconsulting.com>
 <4E4AEC65.5020900@knownelement.com>
 <4E4B9F7F.7070106@emmanuelcomputerconsulting.com>
Message-ID: <CAD45i00q_Nn9ES5GdDZg8a7pmyGO+sn0Zxym0XuK=g4fdd1spQ@mail.gmail.com>

Friends of mine recently bought a large traditionally-designed house.
The former "servant's quarters" are now the server room.



From chrisjfenton at btinternet.com  Wed Sep  7 12:56:00 2011
From: chrisjfenton at btinternet.com (Chrisjfenton)
Date: Wed, 7 Sep 2011 12:56:00 -0500
Subject: iCloud - Is it going to hurt access providers?
In-Reply-To: <4E679E95.4060109@bogus.com>
References: <23006012.859.1315276772119.JavaMail.root@benjamin.baylink.com>
 <4E66B3F1.7020000@bryanfields.net> <4E67958B.1080709@csuohio.edu>
 <4E679BAC.4090206@bogus.com> <3709.1315413448@turing-police.cc.vt.edu>
 <4E679E95.4060109@bogus.com>
Message-ID: <35F03F6B-5B9C-445C-9AA3-27276A4CCCEB@btinternet.com>

Most networks have been trying to avoid that, building out a quarterly pop thing,... problem is now its an ongoing cumulative quarterly pop across many years, .... With pent up frustrated consumer demand for more and more video....including face time on these apple devices!  

Iridescent iPhone 
+1 972 757 8894



On 7 Sep 2011, at 11:40, Joel jaeggli <joelja at bogus.com> wrote:

> On 9/7/11 09:37 , Valdis.Kletnieks at vt.edu wrote:
>> On Wed, 07 Sep 2011 09:28:28 PDT, Joel jaeggli said:
>> 
>>> The way to achieve a return on invested capital is to attract and retain
>>> customers who pay for a service which they find compelling.
>> 
>> Only true if long-term returns on investment are suitable for consideration
>> instead of short-term returns.
> 
> When was the last time you built out a network plant for a quarterly pop?
> 
> 



From drew.weaver at thenap.com  Wed Sep  7 13:28:05 2011
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 7 Sep 2011 14:28:05 -0400
Subject: Mailing list/group for datacenter facilities folks
Message-ID: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>

Just wondering,

Is anyone aware whether there is already an active mailing list/group for datacenter facilities folks to discuss power, cooling, physical infrastructure, etc, etc...?

thanks,
-Drew




From jcassell at nic.mil  Wed Sep  7 14:00:53 2011
From: jcassell at nic.mil (Cassell, James D CIV DISA NS233)
Date: Wed, 7 Sep 2011 15:00:53 -0400
Subject: FW: .mil DNSSEC operational message
Message-ID: <F5F942DCF23A8A47A9BFC91000E6F619013878DA@nic02.nic.tld>


The United States Department of Defense (DoD) has authorized the DoD Network
Information Center (NIC) to sign the .mil zone using DNSSEC.  The DoD NIC
will sign the .mil zone using a phased implementation plan that will span a
three (3) month period.

The first phase will consist of signing the .mil zone with an unvalidatable
key, similar to the method used to initially sign several other gTLDs, as
well as the root zone.
  
During the second phase, the .mil zone will be signed using a validatable
key.  However, this key will not be released to IANA for inclusion in the
root zone until an operational test and assessment have been completed.
Essentially, the .mil domain will remain an island (for DNSSEC purposes)
during this phase.

The third and final phase will consist of submitting the .mil key to IANA
for publication in the Internet root zone to allow Internet-wide validation
of .mil DNS responses.
 
Tentative timeline to a signed .mil zone:
Sep 14-Sep 18  .mil zone signed with an unvalidatable key
Sep 19-Dec 11  .mil zone signed with an unpublished, validatable key
Dec 12         .mil zone signed, and its DS record is included in the root
zone

This rollout is expected to be transparent to the Internet user community,
however, if there are issues during this period, please contact the DoD NIC
at 1-800-365-3642; +1 614-692-2708.

Thank you,
DoD NIC Administration
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5209 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110907/4f58d9bd/attachment.bin>

From brandon.kim at brandontek.com  Wed Sep  7 14:06:29 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Wed, 7 Sep 2011 15:06:29 -0400
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
Message-ID: <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>



I would love to be a part of this list if there is one!!!

Cooling is not as easy as just pumping cold air into a room.....



> From: drew.weaver at thenap.com
> To: nanog at nanog.org
> Date: Wed, 7 Sep 2011 14:28:05 -0400
> Subject: Mailing list/group for datacenter facilities folks
> 
> Just wondering,
> 
> Is anyone aware whether there is already an active mailing list/group for datacenter facilities folks to discuss power, cooling, physical infrastructure, etc, etc...?
> 
> thanks,
> -Drew
> 
> 
 		 	   		  

From ryanczak at gmail.com  Wed Sep  7 14:09:07 2011
From: ryanczak at gmail.com (Matt Ryanczak)
Date: Wed, 07 Sep 2011 15:09:07 -0400
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
 <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>
Message-ID: <4E67C153.8050903@gmail.com>

On 09/07/2011 03:06 PM, Brandon Kim wrote:
> I would love to be a part of this list if there is one!!!

+1



From alex at corp.nac.net  Wed Sep  7 14:20:56 2011
From: alex at corp.nac.net (Alex Rubenstein)
Date: Wed, 7 Sep 2011 15:20:56 -0400
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
 <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>
Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB808CF0F93B1@EXCHMBX.hq.nac.net>

Perhaps there should be a DC track at NANOG?

One of the reasons I have not gone in years.

I have much knowledge and experience to share, but no one to share it with.

> 
> I would love to be a part of this list if there is one!!!
> 
> Cooling is not as easy as just pumping cold air into a room.....
> 
> 
> 
> > Just wondering,
> >
> > Is anyone aware whether there is already an active mailing list/group for
> datacenter facilities folks to discuss power, cooling, physical infrastructure, etc,
> etc...?



From seth.mos at dds.nl  Wed Sep  7 14:24:19 2011
From: seth.mos at dds.nl (Seth Mos)
Date: Wed, 7 Sep 2011 21:24:19 +0200
Subject: NAT444 or ?
In-Reply-To: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
Message-ID: <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>


Op 7 sep 2011, om 19:06 heeft Jean-Francois.TremblayING at videotron.com het volgende geschreven:

> On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote:
>>> I'm going to have to deploy NAT444 with dual-stack real soon now.
>> you may want to review the presentations from last week's apnic meeting
>> in busan.  real mesurements.  sufficiently scary that people who were
>> heavily pushing nat444 for the last two years suddenly started to say
>> "it was not me who pushed nat444, it was him!"  as if none of us had a
>> memory. 
>> 
>> Hm, I fail to find relevant slides discussing that. Could you please
>> point us to those?
> 
> I had the same question. I found Miyakawa-san's presentation has some 
> dramatic examples of CGN NAT444 effects using Google Maps: 
> http://meetings.apnic.net/__data/assets/file/0011/38297/Miyakawa-APNIC-KEYNOTE-IPv6-2011-8.pptx.pdf 
> 
> 
> However these are with a very high address-sharing ratio (several 
> thousands users per address). Using a sparser density (<= 64 users per 
> address) is likely to show much less dramatic user impacts. 

I think you have the numbers off, he started with 1000 users sharing the same IP, since you can only do 62k sessions or so and with a "normal" timeout on those sessions you ran into issues quickly.

The summary is that with anything less then 20 tcp sessions per user simultaneous google maps or earth was problematic. From 15 and downwards almost unsable.

He deducted from testing that about 10 users per IP was a more realistic limit without taking out the entire CGN "experience".

On a personal note, this isn't even taking into question things like broken virus scanners or other software updates that will happily try to do 5 sessions per second, or a msn client lost trying to do 10 per second. The most the windows IP stack will allow on client versions.

The real big issue that will be the downfall of NAT444 is the issue with ACLS and automatic blocklists and the loss of granular access control on that which the ISP has no control of. Which roughly estimates to the internet.
 
Regards,

Seth


From cboyd at gizmopartners.com  Wed Sep  7 14:26:10 2011
From: cboyd at gizmopartners.com (Chris Boyd)
Date: Wed, 7 Sep 2011 14:26:10 -0500
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
Message-ID: <30C76D48-65BD-4569-8D20-BD0D9D2ED045@gizmopartners.com>


On Sep 7, 2011, at 1:28 PM, Drew Weaver wrote:

> Just wondering,
> 
> Is anyone aware whether there is already an active mailing list/group for datacenter facilities folks to discuss power, cooling, physical infrastructure, etc, etc...?
> 

There was one at shorty.com, but that's now a paintball / Airsoft site.

$DAYJOB is willing to host a new maillist though.  Give me a while and we'll get one set up.

--Chris


From brandon.kim at brandontek.com  Wed Sep  7 14:33:04 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Wed, 7 Sep 2011 15:33:04 -0400
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB808CF0F93B1@EXCHMBX.hq.nac.net>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>,
 <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>,
 <2D0AF14BA6FB334988BC1F5D4FC38CB808CF0F93B1@EXCHMBX.hq.nac.net>
Message-ID: <BLU158-W38E4E45D9AC2DC289C36A1DC1F0@phx.gbl>


I'd like to have discussions on air flow, CRAC units, A/B power circuits....best practices etc etc.....




> From: alex at corp.nac.net
> To: brandon.kim at brandontek.com; drew.weaver at thenap.com; nanog at nanog.org
> Date: Wed, 7 Sep 2011 15:20:56 -0400
> Subject: RE: Mailing list/group for datacenter facilities folks
> 
> Perhaps there should be a DC track at NANOG?
> 
> One of the reasons I have not gone in years.
> 
> I have much knowledge and experience to share, but no one to share it with.
> 
> > 
> > I would love to be a part of this list if there is one!!!
> > 
> > Cooling is not as easy as just pumping cold air into a room.....
> > 
> > 
> > 
> > > Just wondering,
> > >
> > > Is anyone aware whether there is already an active mailing list/group for
> > datacenter facilities folks to discuss power, cooling, physical infrastructure, etc,
> > etc...?
 		 	   		  

From leigh.porter at ukbroadband.com  Wed Sep  7 15:05:08 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 7 Sep 2011 20:05:08 +0000
Subject: NAT444 or ?
In-Reply-To: <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Seth Mos [mailto:seth.mos at dds.nl]
> Sent: 07 September 2011 20:26
> To: NANOG
> Subject: Re: NAT444 or ?
> 
> I think you have the numbers off, he started with 1000 users sharing
> the same IP, since you can only do 62k sessions or so and with a
> "normal" timeout on those sessions you ran into issues quickly.
> 
> The summary is that with anything less then 20 tcp sessions per user
> simultaneous google maps or earth was problematic. From 15 and
> downwards almost unsable.
> 
> He deducted from testing that about 10 users per IP was a more
> realistic limit without taking out the entire CGN "experience".
> 
> On a personal note, this isn't even taking into question things like
> broken virus scanners or other software updates that will happily try
> to do 5 sessions per second, or a msn client lost trying to do 10 per
> second. The most the windows IP stack will allow on client versions.
> 
> The real big issue that will be the downfall of NAT444 is the issue
> with ACLS and automatic blocklists and the loss of granular access
> control on that which the ISP has no control of. Which roughly
> estimates to the internet.
> 
> Regards,
> 
> Seth

I was thinking of an average of around 100 sessions per user for working out how things scale to start with. It would also be handy to be able to apply sensible limits to new sessions, say limit the number of sessions to a single destination IP address and apply an overall session limit of perhaps 200 sessions per source IP address.

ACLs and blocklists are going to be a problem, perhaps, as LSN becomes more and more common, such things will gradually die out.

Considering that offices, schools etc regularly have far more than 10 users per IP, I think this limit is a little low. I've happily had around 300 per public IP address on a large WiFi network, granted these are all different kinds of users, it is just something that operational experience will have to demonstrate.

I would love to avoid NAT444, I do not see a viable way around it at the moment. Unless the Department of Work and Pensions release their /8 that is ;-)


--
Leigh


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From drew.weaver at thenap.com  Wed Sep  7 15:09:20 2011
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 7 Sep 2011 16:09:20 -0400
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
Message-ID: <F3318834F1F89D46857972DD4B411D7005220A668C@exchange>

dc-ops at puck.nether.net thanks Jared =)

http://puck.nether.net/mailman/listinfo/dc-ops

-Drew


-----Original Message-----
From: Drew Weaver [mailto:drew.weaver at thenap.com] 
Sent: Wednesday, September 07, 2011 2:28 PM
To: 'nanog at nanog.org'
Subject: Mailing list/group for datacenter facilities folks

Just wondering,

Is anyone aware whether there is already an active mailing list/group for datacenter facilities folks to discuss power, cooling, physical infrastructure, etc, etc...?

thanks,
-Drew





From Jean-Francois.TremblayING at videotron.com  Wed Sep  7 15:12:12 2011
From: Jean-Francois.TremblayING at videotron.com (Jean-Francois.TremblayING at videotron.com)
Date: Wed, 7 Sep 2011 16:12:12 -0400
Subject: NAT444 or ?
In-Reply-To: <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
Message-ID: <OF80740D9E.572D345B-ON85257904.006C25D4-85257904.006EFB4B@videotron.com>

>> However these are with a very high address-sharing ratio (several 
>> thousands users per address). Using a sparser density (<= 64 users per 
>> address) is likely to show much less dramatic user impacts. 
> 
> I think you have the numbers off, he started with 1000 users sharing 
> the same IP, since you can only do 62k sessions or so 

These numbers were not off. From page 19: "...we should assign at least 
1000 [..] ports per customer to assure good performance of IPv4 
applications"
"At least 1000 ports per customers" is roughly the same than "less than 
64 users per address" as I stated above. 

Btw, 90% of subscribers have less than 100 active connections at any time, 

if I read these tiny graphs correctly: 
http://www.wand.net.nz/~salcock/pam2009_final.pdf

> and with a "normal" timeout on those sessions you ran into issues 
quickly.

Agreed for UDP, but most of these sessions are TCP, which arguably time 
out 
rather rapidly after a FIN and an extra hold time. Normal duration of a 
TCP 
session is usually under a few seconds. 

This study saw an average connection time of 8 seconds for DSL, but it's 
from 2004. 
http://www.google.com/#q=A+Comparative+Study+of+TCP/IP+Traffic+Behavior+in+Broadband+Access+Networks


/JF




From dorn at hetzel.org  Wed Sep  7 15:13:26 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Wed, 7 Sep 2011 16:13:26 -0400
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
Message-ID: <CAFrZoh15T=QQU24fhNbAGjXKp0RJ1EStv3Js8dNF_SL54CR+YQ@mail.gmail.com>

On Wed, Sep 7, 2011 at 4:05 PM, Leigh Porter
<leigh.porter at ukbroadband.com>wrote:

>
> I was thinking of an average of around 100 sessions per user for working
> out how things scale to start with. It would also be handy to be able to
> apply sensible limits to new sessions, say limit the number of sessions to a
> single destination IP address and apply an overall session limit of perhaps
> 200 sessions per source IP address.
>
> ACLs and blocklists are going to be a problem, perhaps, as LSN becomes more
> and more common, such things will gradually die out.
>
> Considering that offices, schools etc regularly have far more than 10 users
> per IP, I think this limit is a little low. I've happily had around 300 per
> public IP address on a large WiFi network, granted these are all different
> kinds of users, it is just something that operational experience will have
> to demonstrate.
>
> I would love to avoid NAT444, I do not see a viable way around it at the
> moment. Unless the Department of Work and Pensions release their /8 that is
> ;-)
>
>
Perhaps it can be made ever so slightly less ugly if endpoints get an
"address" that consists of a 32 bit IP address + (n) upper bits of port
number.

This might be 4 significant bits to share an IP 16 ways, or 8 significant
bits to share it 256 ways, or whatever.

In a perfect world, all of the endpoints sharing a single IP would be off a
single concentration point of whatever sort (same tower, etc)...

The end users can still do their own NAT then, their NAT device just has to
restrict the external port range to the one assigned (or have packets with
bad source ports dropped when sent).

Ok, not really pretty, but maybe a little less ugly than twice NAT, and at
least users could have "fixed" addresses (including the upper bits of port
number).

Of course, the 0000 value for upper port bits can be reserved for "business"
grade users so they get the nice ports like 80, etc.


From davei at otd.com  Wed Sep  7 15:21:35 2011
From: davei at otd.com (David Israel)
Date: Wed, 07 Sep 2011 16:21:35 -0400
Subject: NAT444 or ?
In-Reply-To: <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
Message-ID: <4E67D24F.10706@otd.com>

On 9/7/2011 3:24 PM, Seth Mos wrote:
> I think you have the numbers off, he started with 1000 users sharing the same IP, since you can only do 62k sessions or so and with a "normal" timeout on those sessions you ran into issues quickly.
>

Remember that a TCP session is defined not just by the port, but by the 
combination of source address:source port:destination 
address:destination port.  So that's 62k sessions *per destination* per 
ip address.   In theory, this particular performance problem should only 
arise when the NAT gear insists on a unique port per session (which is 
common, but unnecessary) or when a particular destination is 
inordinately popular; the latter problem could be addressed by 
increasing the number of addresses that facebook.com and google.com 
resolve to.

I'm not advocating CGN; my point is not that this problem *should* be 
solved, merely that it *can* be.

-Dave




From cboyd at gizmopartners.com  Wed Sep  7 15:23:55 2011
From: cboyd at gizmopartners.com (Chris Boyd)
Date: Wed, 7 Sep 2011 15:23:55 -0500
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <F3318834F1F89D46857972DD4B411D7005220A668C@exchange>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
 <F3318834F1F89D46857972DD4B411D7005220A668C@exchange>
Message-ID: <7EE226F2-D556-4BBB-BC1F-923A1B38D53E@gizmopartners.com>


On Sep 7, 2011, at 3:09 PM, Drew Weaver wrote:

> dc-ops at puck.nether.net thanks Jared =)

+1, beat me to it.  Thanks!

--Chris



From leigh.porter at ukbroadband.com  Wed Sep  7 15:37:57 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 7 Sep 2011 20:37:57 +0000
Subject: NAT444 or ?
In-Reply-To: <4E67D24F.10706@otd.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl> <4E67D24F.10706@otd.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BADD2@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: David Israel [mailto:davei at otd.com]
> Sent: 07 September 2011 21:23
> To: nanog at nanog.org
> Subject: Re: NAT444 or ?
> 
> On 9/7/2011 3:24 PM, Seth Mos wrote:
> > I think you have the numbers off, he started with 1000 users sharing
> the same IP, since you can only do 62k sessions or so and with a
> "normal" timeout on those sessions you ran into issues quickly.
> >
> 
> Remember that a TCP session is defined not just by the port, but by the
> combination of source address:source port:destination
> address:destination port.  So that's 62k sessions *per destination* per
> ip address.   In theory, this particular performance problem should
> only
> arise when the NAT gear insists on a unique port per session (which is
> common, but unnecessary) or when a particular destination is
> inordinately popular; the latter problem could be addressed by
> increasing the number of addresses that facebook.com and google.com
> resolve to.

Good point, but aside from these scaling issues which I expect can be resolved to a point, the more serious issue, I think, is applications that just do not work with double NAT. Now, I have not conducted any serious research into this, but it seems that draft-donley-nat444-impacts does appear to have highlight issues that may have been down to implementation.

Other simple tricks such as ensuring that your own internal services such as DNS are available without traversing NAT also help.

Certainly some more work can be done in this area, but I fear that the only way a real idea as to how much NAT444 really doe break things will be operational experience.



--
Leigh




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From simon.perreault at viagenie.ca  Wed Sep  7 16:29:16 2011
From: simon.perreault at viagenie.ca (Simon Perreault)
Date: Wed, 07 Sep 2011 17:29:16 -0400
Subject: NAT444 or ?
In-Reply-To: <4E67D24F.10706@otd.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl> <4E67D24F.10706@otd.com>
Message-ID: <4E67E22C.80807@viagenie.ca>

David Israel wrote, on 09/07/2011 04:21 PM:
> In theory, this
> particular performance problem should only arise when the NAT gear insists on a
> unique port per session (which is common, but unnecessary)

What you're describing is known as "endpoint-independent mapping" behaviour. It
is good for not breaking applications, not so good for scalability. RFC 4787
section 4.1 makes it a MUST.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca



From blakjak at blakjak.net  Wed Sep  7 16:34:36 2011
From: blakjak at blakjak.net (Mark Foster)
Date: Thu, 08 Sep 2011 09:34:36 +1200
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <F3318834F1F89D46857972DD4B411D7005220A668C@exchange>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
 <F3318834F1F89D46857972DD4B411D7005220A668C@exchange>
Message-ID: <1315431276.1975.13.camel@hawkeye>

Have found http://www.linkedin.com/groups?about=&gid=94108 to have some
gems in it.

I mention only because it's otherwise a case of YAML (that is, Yet
Another Mailing List, not the logging format...)

Of course, not everyone uses or likes LinkedIn.

Mark.


On Wed, 2011-09-07 at 16:09 -0400, Drew Weaver wrote:

> dc-ops at puck.nether.net thanks Jared =)
> 
> http://puck.nether.net/mailman/listinfo/dc-ops
> 
> -Drew
> 
> 
> -----Original Message-----
> From: Drew Weaver [mailto:drew.weaver at thenap.com] 
> Sent: Wednesday, September 07, 2011 2:28 PM
> To: 'nanog at nanog.org'
> Subject: Mailing list/group for datacenter facilities folks
> 
> Just wondering,
> 
> Is anyone aware whether there is already an active mailing list/group for datacenter facilities folks to discuss power, cooling, physical infrastructure, etc, etc...?
> 
> thanks,
> -Drew
> 
> 
> 




From Valdis.Kletnieks at vt.edu  Wed Sep  7 17:11:57 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 07 Sep 2011 18:11:57 -0400
Subject: NAT444 or ?
In-Reply-To: Your message of "Wed, 07 Sep 2011 16:13:26 EDT."
 <CAFrZoh15T=QQU24fhNbAGjXKp0RJ1EStv3Js8dNF_SL54CR+YQ@mail.gmail.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <CAFrZoh15T=QQU24fhNbAGjXKp0RJ1EStv3Js8dNF_SL54CR+YQ@mail.gmail.com>
Message-ID: <23589.1315433517@turing-police.cc.vt.edu>

On Wed, 07 Sep 2011 16:13:26 EDT, Dorn Hetzel said:

> Perhaps it can be made ever so slightly less ugly if endpoints get an
> "address" that consists of a 32 bit IP address + (n) upper bits of port
> number.
> 
> This might be 4 significant bits to share an IP 16 ways, or 8 significant
> bits to share it 256 ways, or whatever.

And you store the 4 or 8 bits in what part of the IPv4 header, exactly?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110907/174346a2/attachment.bin>

From leigh.porter at ukbroadband.com  Wed Sep  7 18:08:01 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 7 Sep 2011 23:08:01 +0000
Subject: NAT444 or ?
In-Reply-To: <23589.1315433517@turing-police.cc.vt.edu>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <CAFrZoh15T=QQU24fhNbAGjXKp0RJ1EStv3Js8dNF_SL54CR+YQ@mail.gmail.com>
 <23589.1315433517@turing-police.cc.vt.edu>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BAE96@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> Sent: 07 September 2011 23:14
> To: Dorn Hetzel
> Cc: Leigh Porter; NANOG
> Subject: Re: NAT444 or ?
> 
> On Wed, 07 Sep 2011 16:13:26 EDT, Dorn Hetzel said:
> 
> > Perhaps it can be made ever so slightly less ugly if endpoints get an
> > "address" that consists of a 32 bit IP address + (n) upper bits of
> > port number.
> >
> > This might be 4 significant bits to share an IP 16 ways, or 8
> > significant bits to share it 256 ways, or whatever.
> 
> And you store the 4 or 8 bits in what part of the IPv4 header, exactly?


Nobody uses the TOS bits, do they? ;-)

--
Leigh




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From jra at baylink.com  Wed Sep  7 18:34:36 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 7 Sep 2011 19:34:36 -0400 (EDT)
Subject: Tampa Colos: IPv6
In-Reply-To: <20818815.1105.1315438369046.JavaMail.root@benjamin.baylink.com>
Message-ID: <14158668.1107.1315438476276.JavaMail.root@benjamin.baylink.com>

So I think my shortlist is Esol, Equinix, Qwest, and DirectColo, if they're 
not already a tenant of one of the other 3.

Anyone got any info on how those three/four are about native IPv6?

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      http://photo.imageinc.us             +1 727 647 1274



From eric at ericheather.com  Wed Sep  7 18:45:09 2011
From: eric at ericheather.com (Eric C. Miller)
Date: Wed, 7 Sep 2011 23:45:09 +0000
Subject: Brighthouse Outage in Tampa, FL
Message-ID: <DC85D08B84BB854086E9524DAB67D18751D0ED@Teriwood.miller.local>

Does anyone know what the "software bug" that hit Brighthouse in Tampa?

Eric Miller



From owen at delong.com  Wed Sep  7 19:18:15 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 7 Sep 2011 17:18:15 -0700
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
Message-ID: <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>


On Sep 7, 2011, at 1:05 PM, Leigh Porter wrote:

> 
> 
>> -----Original Message-----
>> From: Seth Mos [mailto:seth.mos at dds.nl]
>> Sent: 07 September 2011 20:26
>> To: NANOG
>> Subject: Re: NAT444 or ?
>> 
>> I think you have the numbers off, he started with 1000 users sharing
>> the same IP, since you can only do 62k sessions or so and with a
>> "normal" timeout on those sessions you ran into issues quickly.
>> 
>> The summary is that with anything less then 20 tcp sessions per user
>> simultaneous google maps or earth was problematic. From 15 and
>> downwards almost unsable.
>> 
>> He deducted from testing that about 10 users per IP was a more
>> realistic limit without taking out the entire CGN "experience".
>> 
>> On a personal note, this isn't even taking into question things like
>> broken virus scanners or other software updates that will happily try
>> to do 5 sessions per second, or a msn client lost trying to do 10 per
>> second. The most the windows IP stack will allow on client versions.
>> 
>> The real big issue that will be the downfall of NAT444 is the issue
>> with ACLS and automatic blocklists and the loss of granular access
>> control on that which the ISP has no control of. Which roughly
>> estimates to the internet.
>> 
>> Regards,
>> 
>> Seth
> 
> I was thinking of an average of around 100 sessions per user for working out how things scale to start with. It would also be handy to be able to apply sensible limits to new sessions, say limit the number of sessions to a single destination IP address and apply an overall session limit of perhaps 200 sessions per source IP address.
> 
> ACLs and blocklists are going to be a problem, perhaps, as LSN becomes more and more common, such things will gradually die out.
> 
I think that such things will kill the NAT444 user experience rather than having the NAT444 user experience problems kill the block lists.

The people maintaining said lists are generally trying to protect larger systems from abusers and don't have any strong motivation to preserve the user experience of particular ISPs or particular subsets of users.

> Considering that offices, schools etc regularly have far more than 10 users per IP, I think this limit is a little low. I've happily had around 300 per public IP address on a large WiFi network, granted these are all different kinds of users, it is just something that operational experience will have to demonstrate.
> 
Yes, but, you are counting individual users whereas at the NAT444 level, what's really being counted is end-customer sites not individual users, so the term
"users" is a bit misleading in the context. A given end-customer site may be from 1 to 50 or more individual users.

> I would love to avoid NAT444, I do not see a viable way around it at the moment. Unless the Department of Work and Pensions release their /8 that is ;-)
> 

The best mitigation really is to get IPv6 deployed as rapidly and widely as possible. The more stuff can go native IPv6, the less depends on fragile NAT444.

Owen

> 
> --
> Leigh
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________




From cdl at asgaard.org  Wed Sep  7 19:49:45 2011
From: cdl at asgaard.org (Christopher LILJENSTOLPE)
Date: Wed, 7 Sep 2011 17:49:45 -0700
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <4E67C153.8050903@gmail.com>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
 <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl> <4E67C153.8050903@gmail.com>
Message-ID: <B2C93E9B-8D02-4A9C-91B2-180FB9CFC71D@asgaard.org>

+1

--
Pardon the typos - sent from a silly keyboard

On Sep 7, 2011, at 12:09, Matt Ryanczak <ryanczak at gmail.com> wrote:

> On 09/07/2011 03:06 PM, Brandon Kim wrote:
>> I would love to be a part of this list if there is one!!!
> 
> +1
> 



From mysidia at gmail.com  Wed Sep  7 20:03:24 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 7 Sep 2011 20:03:24 -0500
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
 <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>
Message-ID: <CAAAwwbUFWosJqMd0TNhHstZ6jKO6+CPMwAemMos-xkUHDj=EmQ@mail.gmail.com>

On Wed, Sep 7, 2011 at 2:06 PM, Brandon Kim <brandon.kim at brandontek.com> wrote:
> I would love to be a part of this list if there is one!!!
>
> Cooling is not as easy as just pumping cold air into a room.....
>
?
Indeed... it's even easier than that.   Cooling is as easy as making
an entire room emit heat
to the outside environment at an average rate that is consistently
faster than heat transfer
into the room from all sources.

There are many ways of accomplishing that.      One of the best ways
is to put your room
in an already cold environment,   in  contact with an excellent
thermal conductor.

For example...   server room  in the arctic region,    at  the bottom
of  some lake.
Probably with all air removed from the environment, and a sound
thermal medium such as oil
pumped in in its place (make sure to use SSDs for all storage and no
mechanical devices).

--
-JH



From surfer at mauigateway.com  Wed Sep  7 20:32:01 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Wed, 7 Sep 2011 18:32:01 -0700
Subject: Mailing list/group for datacenter facilities folks
Message-ID: <20110907183201.F7A8D3DD@resin11.mta.everyone.net>


----- From: Jimmy Hess <mysidia at gmail.com> -----
On Wed, Sep 7, 2011 at 2:06 PM, Brandon Kim <brandon.kim at brandontek.com> wrote:

> Cooling is not as easy as just pumping cold air into a room.....


: There are many ways of accomplishing that.  One of the best ways
: is to put your room in an already cold environment, in contact 
: with an excellent thermal conductor.
: <snip>
: For example...   server room  in the arctic region,   
--------------------------------------------------



Years ago there was a guy on this list that ran the network at the Antarctic station and he told me that he had overheating issues in his datacenter, so it may not be as easy as one would think...  ;-)

scott



From brandon.kim at brandontek.com  Wed Sep  7 20:44:24 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Wed, 7 Sep 2011 21:44:24 -0400
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <20110907183201.F7A8D3DD@resin11.mta.everyone.net>
References: <20110907183201.F7A8D3DD@resin11.mta.everyone.net>
Message-ID: <BLU158-W272BFF7CCF6C12A7556589DC1E0@phx.gbl>


LOL too funny guys......

I agree it has to do with air flow....plus temps have to be just right. You don't want it too cold and 
equipment start freezing....or ice forming....



> Date: Wed, 7 Sep 2011 18:32:01 -0700
> From: surfer at mauigateway.com
> To: nanog at nanog.org
> Subject: Re: Mailing list/group for datacenter facilities folks
> 
> 
> ----- From: Jimmy Hess <mysidia at gmail.com> -----
> On Wed, Sep 7, 2011 at 2:06 PM, Brandon Kim <brandon.kim at brandontek.com> wrote:
> 
> > Cooling is not as easy as just pumping cold air into a room.....
> 
> 
> : There are many ways of accomplishing that.  One of the best ways
> : is to put your room in an already cold environment, in contact 
> : with an excellent thermal conductor.
> : <snip>
> : For example...   server room  in the arctic region,   
> --------------------------------------------------
> 
> 
> 
> Years ago there was a guy on this list that ran the network at the Antarctic station and he told me that he had overheating issues in his datacenter, so it may not be as easy as one would think...  ;-)
> 
> scott
> 
 		 	   		  

From lists at mtin.net  Wed Sep  7 22:10:02 2011
From: lists at mtin.net (Justin Wilson)
Date: Wed, 07 Sep 2011 23:10:02 -0400
Subject: Brighthouse Outage in Tampa, FL
In-Reply-To: <DC85D08B84BB854086E9524DAB67D18751D0ED@Teriwood.miller.local>
Message-ID: <CA8DAA00.1980C%lists@mtin.net>

It affected outside Tampa even.  Even went as far south as Bradenton so I
am guessing it was systemwide. For awhile their call center was so
overloaded you received a fast busy when you called.

	Justin

--
Justin Wilson <j2sw at mtin.net>
Aol & Yahoo IM: j2sw
http://www.mtin.net/blog ? xISP News
http://www.twitter.com/j2sw ? Follow me on Twitter




-----Original Message-----
From: "Eric C. Miller" <eric at ericheather.com>
Date: Wed, 7 Sep 2011 23:45:09 +0000
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: Brighthouse Outage in Tampa, FL

>Does anyone know what the "software bug" that hit Brighthouse in Tampa?
>
>Eric Miller
>





From ken at sizone.org  Wed Sep  7 23:36:51 2011
From: ken at sizone.org (Ken Chase)
Date: Thu, 8 Sep 2011 00:36:51 -0400
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <CAAAwwbUFWosJqMd0TNhHstZ6jKO6+CPMwAemMos-xkUHDj=EmQ@mail.gmail.com>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
 <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>
 <CAAAwwbUFWosJqMd0TNhHstZ6jKO6+CPMwAemMos-xkUHDj=EmQ@mail.gmail.com>
Message-ID: <20110908043651.GR17291@sizone.org>

On Wed, Sep 07, 2011 at 08:03:24PM -0500, Jimmy Hess said:
  >On Wed, Sep 7, 2011 at 2:06 PM, Brandon Kim <brandon.kim at brandontek.com> wrote:
  >> I would love to be a part of this list if there is one!!!
  >>
  >> Cooling is not as easy as just pumping cold air into a room.....
  >>
  >?
  >Indeed... it's even easier than that.   Cooling is as easy as making
  >an entire room emit heat
  >to the outside environment at an average rate that is consistently
  >faster than heat transfer
  >into the room from all sources.
  >
  >There are many ways of accomplishing that.      One of the best ways
  >is to 

repeal the laws of thermodynamics

/kc
-- 
Ken Chase - ken at sizone.org



From gih at apnic.net  Thu Sep  8 00:26:46 2011
From: gih at apnic.net (Geoff Huston)
Date: Thu, 8 Sep 2011 15:26:46 +1000
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BAB51@EALPO1.ukbroadband.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
 <m2y5y0r72b.wl%randy@psg.com> <20110907163656.GA9961@srv03.cluenet.de>
 <D181DDABABE57E4DB72FEE00331478643BAB51@EALPO1.ukbroadband.com>
Message-ID: <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>


On 08/09/2011, at 2:41 AM, Leigh Porter wrote:

> 
> 
>> -----Original Message-----
>> From: Daniel Roesen [mailto:dr at cluenet.de]
>> Sent: 07 September 2011 17:38
>> To: nanog at nanog.org
>> Subject: Re: NAT444 or ?
>> 
>> On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote:
>>>> I'm going to have to deploy NAT444 with dual-stack real soon now.
>>> 
>>> you may want to review the presentations from last week's apnic
>> meeting
>>> in busan.  real mesurements.  sufficiently scary that people who were
>>> heavily pushing nat444 for the last two years suddenly started to say
>>> "it was not me who pushed nat444, it was him!"  as if none of us had
>> a
>>> memory.
>> 
>> Hm, I fail to find relevant slides discussing that. Could you please
>> point us to those?
>> 
>> I'm looking at http://meetings.apnic.net/32
> 
> There is a lot in the IPv6 plenary sessions:
> 
> http://meetings.apnic.net/32/program/ipv6
> 
> This is what I am looking at right now. Randy makes some good comments in those sessions. I have not found anything yet, but I am only on session 3, pertaining specifically to issues around NAT444.

It may not be what Randy was referring to above, but as part of that program at APNIC32 I reported on the failure rate I am measuring for Teredo. I'm not sure its all in the slides I was using, but what I was trying to say was that STUN is simply terrible at reliably negotiating a NAT. I was then wondering what pixie dust CGNs were going to use that would have any impact on the ~50% connection failure rate I'm observing in Teredo. And if there is no such thing as pixie dust (damn!) I was then wondering if NATs are effectively unuseable if you want anything fancier than 1:1 TCP connections (like multi-user games, for example). After all, a 50% connection failure rate for STUN is hardly encouraging news for a CGN deployer if your basic objective is not to annoy your customers.

regards,
Geoff


From seth.mos at dds.nl  Thu Sep  8 00:41:58 2011
From: seth.mos at dds.nl (Seth Mos)
Date: Thu, 8 Sep 2011 07:41:58 +0200
Subject: NAT444 or ?
In-Reply-To: <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
 <m2y5y0r72b.wl%randy@psg.com> <20110907163656.GA9961@srv03.cluenet.de>
 <D181DDABABE57E4DB72FEE00331478643BAB51@EALPO1.ukbroadband.com>
 <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
Message-ID: <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>


Op 8 sep 2011, om 07:26 heeft Geoff Huston het volgende geschreven:

> 
> On 08/09/2011, at 2:41 AM, Leigh Porter wrote:
> 
> It may not be what Randy was referring to above, but as part of that program at APNIC32 I reported on the failure rate I am measuring for Teredo. I'm not sure its all in the slides I was using, but what I was trying to say was that STUN is simply terrible at reliably negotiating a NAT. I was then wondering what pixie dust CGNs were going to use that would have any impact on the ~50% connection failure rate I'm observing in Teredo. And if there is no such thing as pixie dust (damn!) I was then wondering if NATs are effectively unuseable if you want anything fancier than 1:1 TCP connections (like multi-user games, for example). After all, a 50% connection failure rate for STUN is hardly encouraging news for a CGN deployer if your basic objective is not to annoy your customers.

The striking thing I picked up is that NTT considers the CGN equipment a big black hole where money goes into. Because it won't solve their problem now or in the future and it becomes effectively a piece of equipment they need to buy and then scrap "soon" after.

They acknowledge the need, but they'd rather not buy one.
That and they (the isp) get called for anything which doesn't work.

Regards,

Seth


From leigh.porter at ukbroadband.com  Thu Sep  8 03:48:16 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 8 Sep 2011 08:48:16 +0000
Subject: NAT444 or ?
In-Reply-To: <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: 08 September 2011 01:22
> To: Leigh Porter
> Cc: Seth Mos; NANOG
> Subject: Re: NAT444 or ?
> 
> > Considering that offices, schools etc regularly have far more than 10
> users per IP, I think this limit is a little low. I've happily had
> around 300 per public IP address on a large WiFi network, granted these
> are all different kinds of users, it is just something that operational
> experience will have to demonstrate.
> >
> Yes, but, you are counting individual users whereas at the NAT444
> level, what's really being counted is end-customer sites not individual
> users, so the term
> "users" is a bit misleading in the context. A given end-customer site
> may be from 1 to 50 or more individual users.

Indeed, my users are using LTE dongles mostly so I expect they will be single users. At the moment on the WiMAX network I see around 35 sessions from a WiMAX modem on average rising to about 50 at peak times. These are a combination of individual users and "home modems".

We had some older modems that had integrated NAT that was broken and locked up the modem at 200 sessions. Then some old base station software died at about 10K sessions. So we monitor these things now..


> 
> > I would love to avoid NAT444, I do not see a viable way around it at
> the moment. Unless the Department of Work and Pensions release their /8
> that is ;-)
> >
> 
> The best mitigation really is to get IPv6 deployed as rapidly and
> widely as possible. The more stuff can go native IPv6, the less depends
> on fragile NAT444.

Absolutely. Even things like google maps, if that can be dumped on v6, it'll save a load of sessions from people. The sooner services such as Microsoft Update turn on v6 the better as well. I would also like the CDNs to be able to deliver content in v6 (even if the main page is v4) which again will reduce the traffic that has to traverse any NAT. 

Soon, I think content providers (and providers of other services on the 'net) will roll v6 because of the performance increase as v6 will not have to traverse all this NAT and be subject to session limits, timeouts and such.

--
Leigh


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From leigh.porter at ukbroadband.com  Thu Sep  8 03:52:56 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 8 Sep 2011 08:52:56 +0000
Subject: NAT444 or ?
In-Reply-To: <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
 <m2y5y0r72b.wl%randy@psg.com> <20110907163656.GA9961@srv03.cluenet.de>
 <D181DDABABE57E4DB72FEE00331478643BAB51@EALPO1.ukbroadband.com>
 <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
 <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BC0F1@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Seth Mos [mailto:seth.mos at dds.nl]
> Sent: 08 September 2011 06:43
> To: NANOG
> Subject: Re: NAT444 or ?
> 
> 
> Op 8 sep 2011, om 07:26 heeft Geoff Huston het volgende geschreven:
> 
> >
> > On 08/09/2011, at 2:41 AM, Leigh Porter wrote:
> >
> > It may not be what Randy was referring to above, but as part of that
> program at APNIC32 I reported on the failure rate I am measuring for
> Teredo. I'm not sure its all in the slides I was using, but what I was
> trying to say was that STUN is simply terrible at reliably negotiating
> a NAT. I was then wondering what pixie dust CGNs were going to use that
> would have any impact on the ~50% connection failure rate I'm observing
> in Teredo. And if there is no such thing as pixie dust (damn!) I was
> then wondering if NATs are effectively unuseable if you want anything
> fancier than 1:1 TCP connections (like multi-user games, for example).
> After all, a 50% connection failure rate for STUN is hardly encouraging
> news for a CGN deployer if your basic objective is not to annoy your
> customers.

I have a concern about some weird and wonderful VPN solutions that people may be using. I am quite sure that some of them will just not work through NAT444, though I have no evidence of this. People have problems with some VPN solutions with single NAT (especially with no ALGs). NAT444 will just be a mess.

> 
> The striking thing I picked up is that NTT considers the CGN equipment
> a big black hole where money goes into. Because it won't solve their
> problem now or in the future and it becomes effectively a piece of
> equipment they need to buy and then scrap "soon" after.

Well if you buy the 'right' solution then you can re-use it elsewhere. Many solutions use multi-purpose processing cards to deliver NAT functionality which can be used for other stuff such as firewalling or some other manor of traffic mangling. 


> 
> They acknowledge the need, but they'd rather not buy one.
> That and they (the isp) get called for anything which doesn't work.

Well at least these little problems that pop up keep people in jobs ;-) If everything just worked (tm) there would be nothing to do..

--
Leigh


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From mike at mikejones.in  Thu Sep  8 06:33:40 2011
From: mike at mikejones.in (Mike Jones)
Date: Thu, 8 Sep 2011 12:33:40 +0100
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BADD2@EALPO1.ukbroadband.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl> <4E67D24F.10706@otd.com>
 <D181DDABABE57E4DB72FEE00331478643BADD2@EALPO1.ukbroadband.com>
Message-ID: <CAAAas8EbN1P50=cOEOTwFYesUodtp=XYk0HzfmmjGOiYTqwwUQ@mail.gmail.com>

As HTTP seems to be a major factor causing a lot of short lived
connections, and several large ISPs have demonstrated that large scale
transparent HTTP proxies seem to work just fine, you could also move
the IPv4 port 80 traffic from the CGN to a transparent HTTP proxy. As
well as any benefits from caching keeping connections local it can
also combine 1000 users trying to load facebook in to a handful of
persistent connections to the facebook servers. The proxy can of
course also have its own global IPv4 address rather than going through
the NAT, I have no experience with large scale HTTP proxy deployments
but I strongly suspect a single HTTP proxy can handle traffic for a
lot more users than low hundreds currently being suggested for NAT444!
and can be scaled out separately if required.

As an end user this is probably a little worse with HTTP coming from a
different IP address to everything else, but not that much worse. As a
provider it may be much easier to scale to larger numbers of
customers. The proxy can also take IPv4-only users to a dual stacked
site over IPv6, as I am under no illusions that even with IPv6 to
every customer you will still have customers behind IPv4-only NAT
routers they bought themselves for quite a while. With some DNS tricks
this might be useful for those users reaching IPv6-only sites, however
it would probably be better if they were unable to reach those sites
at all to give them an incentive to fix their IPv6.

On 7 September 2011 21:37, Leigh Porter <leigh.porter at ukbroadband.com> wrote:
> Other simple tricks such as ensuring that your own internal services such as DNS are available without traversing NAT also help.

As obvious as this probably is, i'm sure someone will overlook it!
Also other services such as providers with CDN nodes in their network
may want to talk to the CDN operator about having those connected to
directly from the internal addresses to avoid traversing the NAT, and
I'm sure there are other services as well.

- Mike



From cb.list6 at gmail.com  Thu Sep  8 09:02:14 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Thu, 8 Sep 2011 07:02:14 -0700
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
Message-ID: <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>

On Sep 8, 2011 1:47 AM, "Leigh Porter" <leigh.porter at ukbroadband.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Owen DeLong [mailto:owen at delong.com]
> > Sent: 08 September 2011 01:22
> > To: Leigh Porter
> > Cc: Seth Mos; NANOG
> > Subject: Re: NAT444 or ?
> >
> > > Considering that offices, schools etc regularly have far more than 10
> > users per IP, I think this limit is a little low. I've happily had
> > around 300 per public IP address on a large WiFi network, granted these
> > are all different kinds of users, it is just something that operational
> > experience will have to demonstrate.
> > >
> > Yes, but, you are counting individual users whereas at the NAT444
> > level, what's really being counted is end-customer sites not individual
> > users, so the term
> > "users" is a bit misleading in the context. A given end-customer site
> > may be from 1 to 50 or more individual users.
>
> Indeed, my users are using LTE dongles mostly so I expect they will be
single users. At the moment on the WiMAX network I see around 35 sessions
from a WiMAX modem on average rising to about 50 at peak times. These are a
combination of individual users and "home modems".
>
> We had some older modems that had integrated NAT that was broken and
locked up the modem at 200 sessions. Then some old base station software
died at about 10K sessions. So we monitor these things now..
>
>
> >
> > > I would love to avoid NAT444, I do not see a viable way around it at
> > the moment. Unless the Department of Work and Pensions release their /8
> > that is ;-)
> > >
> >
> > The best mitigation really is to get IPv6 deployed as rapidly and
> > widely as possible. The more stuff can go native IPv6, the less depends
> > on fragile NAT444.
>
> Absolutely. Even things like google maps, if that can be dumped on v6,
it'll save a load of sessions from people. The sooner services such as
Microsoft Update turn on v6 the better as well. I would also like the CDNs
to be able to deliver content in v6 (even if the main page is v4) which
again will reduce the traffic that has to traverse any NAT.
>
> Soon, I think content providers (and providers of other services on the
'net) will roll v6 because of the performance increase as v6 will not have
to traverse all this NAT and be subject to session limits, timeouts and
such.
>

What do you mean by performance increase? If performance equals latency, v4
will win for a long while still. Cgn does not add measurable latency.

Cb
> --
> Leigh
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>


From ryan.g at atwgpc.net  Thu Sep  8 09:06:29 2011
From: ryan.g at atwgpc.net (Ryan Gelobter)
Date: Thu, 8 Sep 2011 09:06:29 -0500
Subject: DDoS - CoD?
In-Reply-To: <CAK__KzszC1cTe+oHXyQ4F6iqWkMk0su4qEMBLLC216XA2BxvYA@mail.gmail.com>
References: <4E65D182.8010008@blackhat.bz> <4E662473.4090303@he.net>
 <CAK__KzszC1cTe+oHXyQ4F6iqWkMk0su4qEMBLLC216XA2BxvYA@mail.gmail.com>
Message-ID: <CAFPFpmWDcmExkSZUUiDU48dbrXnz-MvTJ5y6Gz9Eta=2EUph_g@mail.gmail.com>

Sadly I see these all the time, and Valve's SRCDS is vulnerable as well
(AFAIK any Q3 engine game is too). There are unofficial patches for source
but I wish Valve and others would fix it for good. Normally I see these
types of attacks in the 1-2Gbps range but we recently have seen them in the
5-8Gbps and even 10-20Gbps range. That is about 5000-15000 servers each
sending 1-2Mbps.

http://wiki.alliedmods.net/SRCDS_Hardening#A2S_INFO_Spam

The issue was partially resolved with Team Fortress 2 servers.

I've also seen something similar to these but with DNS data.

U XXX.XXX.XXX.XXX:53 -> XXX.XXX.XXX.XXX:53
  .S.....!.....icann.org..............D..
........................D....+..........X.........XNq..Nh.m7/.icann.org.....Y.W+...zzJ

...d.8S...;...U..[~[..}z+].Ov(......;\Gx......g.....wv...&...S....\y.-..4.'.Z..u.?..f.!...<L..o
.wtE....E.M......,.e.......X..

...pechora4.e.e.......X.....pechora5.e.e.......X.....pechora6.e.e.......X.....pechora7.e.e.......X.....pechora8.e.e.......X...

..pechora1.e.e.......X.....pechora2.e.e.......X.....pechora3.e.e.......X.........XNq.(Nh.m7/.icann.org.j...N..#{Gr.+G........B
  ..Rl.4..[......}\.........u.
...'..g.....qd.y#1..[8rw1......i...g...f\.a.$2.k....v64.pKv...1./..|......C..........X.........XN

q."Nh.m7/.icann.org..1...^:.....}.....w.?..........*.........+D..(b.".....-av.X.b.K.|..R..+."i......=E.a....l.vmMqe)....i.}*Z.

.&......`..|..............................Nqb.Nh.m7/.icann.org.{.g.h"h..z..0UV.I.-.v...rZK..t.<?.l8...n...R.....x"8O...$vSR..3
  ._...a....
......o.7.wk...r....X..?n9.(...fk-...~..h.E..y".5...;..(.........(.dns1.(.hostmaster.(w.....*0......u......(.......

....3......Nq..Nh.m7/.icann.org.v5/5J....{..[.c..e.....z...;x9...DR.....^B..V..........q|.........w.D.{..eb......\...G'...=L..

..~^.......6......6...<D..k..........3.............P0.t.................0......Nq.RNh.m...icann.org. at W.
...i..Lj.....j..c%..Y..

......._K=.j..E...u.`.....L..=,.i....K._.9....8X.G...V1J...N.B.....k8..5.I..Pk..#..Vs.X.Ax...P>....d7~~..$.[..{.........l.8...
  e...&:=S2.l.}W.@#.e.LN.j..7g.s..4/52. at ...[MUXu.f9U.y~rXFH/......O<.......'..<.....y.j.


On Tue, Sep 6, 2011 at 1:19 PM, George Herbert <george.herbert at gmail.com>wrote:

> Arrgghhh....
>
> This reminds me of the WebNFS attack.  Which is why Sun aborted
> WebNFS's public launch, after I pointed it out during its Solaris 2.6
> early access program.
>
> Never run a volume-multiplying service on UDP if you can help it,
> exposed to the outside world, without serious in-band source
> verification.  Amplification attacks are a classic easy DDOS win.
>
>
> -george
>
> On Tue, Sep 6, 2011 at 6:47 AM, Jeff Walter <jeffw at he.net> wrote:
> > Call of Duty is apparently using the same flawed protocol as Quake III
> > servers, so you can think of it as an amplification attack.  (I wish I'd
> > forgotten all about this stuff)
> >
> > You send "\xff\xff\xff\xffgetstatus\n" in a UDP packet with a spoofed
> > source, and the server responds with everything you see.  With decent
> > amplification (15B -> ~500B) and the number of CoD servers in world you
> > could very easily build up a sizable attack.
> >
> > --
> > Jeff Walter
> > Network Engineer
> > Hurricane Electric
> >
>
>
>
> --
> -george william herbert
> george.herbert at gmail.com
>
>


From dylan at corp.power1.com  Thu Sep  8 09:52:45 2011
From: dylan at corp.power1.com (Dylan Bouterse)
Date: Thu, 8 Sep 2011 14:52:45 +0000
Subject: Brighthouse Outage in Tampa, FL
In-Reply-To: <CA8DAA00.1980C%lists@mtin.net>
References: <DC85D08B84BB854086E9524DAB67D18751D0ED@Teriwood.miller.local>
 <CA8DAA00.1980C%lists@mtin.net>
Message-ID: <218AB54691EB49439829EFD136F473CF0927FF69@exchange2k10.corp.power1.com>

Brighthouse in Orlando was not affected as far as I could tell, but I did hear of customers in Lakeland that were down. Pretty widespread outage.

Dylan

-----Original Message-----
From: Justin Wilson [mailto:lists at mtin.net] 
Sent: Wednesday, September 07, 2011 11:10 PM
To: nanog at nanog.org
Subject: Re: Brighthouse Outage in Tampa, FL

It affected outside Tampa even.  Even went as far south as Bradenton so I am guessing it was systemwide. For awhile their call center was so overloaded you received a fast busy when you called.

	Justin

--
Justin Wilson <j2sw at mtin.net>
Aol & Yahoo IM: j2sw
http://www.mtin.net/blog  xISP News
http://www.twitter.com/j2sw  Follow me on Twitter




-----Original Message-----
From: "Eric C. Miller" <eric at ericheather.com>
Date: Wed, 7 Sep 2011 23:45:09 +0000
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: Brighthouse Outage in Tampa, FL

>Does anyone know what the "software bug" that hit Brighthouse in Tampa?
>
>Eric Miller
>






From cboyd at gizmopartners.com  Thu Sep  8 09:52:53 2011
From: cboyd at gizmopartners.com (Chris Boyd)
Date: Thu, 8 Sep 2011 09:52:53 -0500
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <CAAAwwbUFWosJqMd0TNhHstZ6jKO6+CPMwAemMos-xkUHDj=EmQ@mail.gmail.com>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
 <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>
 <CAAAwwbUFWosJqMd0TNhHstZ6jKO6+CPMwAemMos-xkUHDj=EmQ@mail.gmail.com>
Message-ID: <FBC170D8-7D9C-44C5-B04E-4BA904E44010@gizmopartners.com>


On Sep 7, 2011, at 8:03 PM, Jimmy Hess wrote:

> Probably with all air removed from the environment, and a sound
> thermal medium such as oil
> pumped in in its place (make sure to use SSDs for all storage and no
> mechanical devices).

There are ways to submerge spinning disks.

http://www.grcooling.com/
http://www.midasgreentech.com/

:-)

--Chris



From r.engehausen at gmail.com  Thu Sep  8 10:01:45 2011
From: r.engehausen at gmail.com (Roy)
Date: Thu, 08 Sep 2011 08:01:45 -0700
Subject: Mailing list/group for datacenter facilities folks
In-Reply-To: <FBC170D8-7D9C-44C5-B04E-4BA904E44010@gizmopartners.com>
References: <F3318834F1F89D46857972DD4B411D7005220A6681@exchange>
 <BLU158-W5966B6A7AD801D052E7B39DC1F0@phx.gbl>
 <CAAAwwbUFWosJqMd0TNhHstZ6jKO6+CPMwAemMos-xkUHDj=EmQ@mail.gmail.com>
 <FBC170D8-7D9C-44C5-B04E-4BA904E44010@gizmopartners.com>
Message-ID: <4E68D8D9.9070807@gmail.com>

On 9/8/2011 7:52 AM, Chris Boyd wrote:
> On Sep 7, 2011, at 8:03 PM, Jimmy Hess wrote:
>
>> Probably with all air removed from the environment, and a sound
>> thermal medium such as oil
>> pumped in in its place (make sure to use SSDs for all storage and no
>> mechanical devices).
> There are ways to submerge spinning disks.
>
> http://www.grcooling.com/
> http://www.midasgreentech.com/
>
> :-)
>
> --Chris
>
>

IBM was making water cooled disk drives for special customers in the 
early 70s



From cdel at firsthand.net  Thu Sep  8 10:04:50 2011
From: cdel at firsthand.net (Christian de Larrinaga)
Date: Thu, 8 Sep 2011 16:04:50 +0100
Subject: what about the users re: NAT444 or ?
In-Reply-To: <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
 <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
Message-ID: <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>

I wonder if the discussion as useful as it is isn't forgetting that the edge of Internet has a stake in getting this right too! This is not just an ISP problem but one where content providers and services that is the users need to get from here to there in good order. 

So 

What can users do to encourage ISPs to deploy v6 to them?
What can users do to ease the pain in reaching IPv4 only sites once they are on IPv6 tails?

Is there not a bit of CPE needed here? What should the CPE do? and not do? should it deprecate NAT/PAT when it receives 1918 allocation from a CGN?
and less technically but relevant I think is to ask about cost? who pays?


Christian

On 8 Sep 2011, at 15:02, Cameron Byrne wrote:

> On Sep 8, 2011 1:47 AM, "Leigh Porter" <leigh.porter at ukbroadband.com> wrote:
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Owen DeLong [mailto:owen at delong.com]
>>> Sent: 08 September 2011 01:22
>>> To: Leigh Porter
>>> Cc: Seth Mos; NANOG
>>> Subject: Re: NAT444 or ?
>>> 
>>>> Considering that offices, schools etc regularly have far more than 10
>>> users per IP, I think this limit is a little low. I've happily had
>>> around 300 per public IP address on a large WiFi network, granted these
>>> are all different kinds of users, it is just something that operational
>>> experience will have to demonstrate.
>>>> 
>>> Yes, but, you are counting individual users whereas at the NAT444
>>> level, what's really being counted is end-customer sites not individual
>>> users, so the term
>>> "users" is a bit misleading in the context. A given end-customer site
>>> may be from 1 to 50 or more individual users.
>> 
>> Indeed, my users are using LTE dongles mostly so I expect they will be
> single users. At the moment on the WiMAX network I see around 35 sessions
> from a WiMAX modem on average rising to about 50 at peak times. These are a
> combination of individual users and "home modems".
>> 
>> We had some older modems that had integrated NAT that was broken and
> locked up the modem at 200 sessions. Then some old base station software
> died at about 10K sessions. So we monitor these things now..
>> 
>> 
>>> 
>>>> I would love to avoid NAT444, I do not see a viable way around it at
>>> the moment. Unless the Department of Work and Pensions release their /8
>>> that is ;-)
>>>> 
>>> 
>>> The best mitigation really is to get IPv6 deployed as rapidly and
>>> widely as possible. The more stuff can go native IPv6, the less depends
>>> on fragile NAT444.
>> 
>> Absolutely. Even things like google maps, if that can be dumped on v6,
> it'll save a load of sessions from people. The sooner services such as
> Microsoft Update turn on v6 the better as well. I would also like the CDNs
> to be able to deliver content in v6 (even if the main page is v4) which
> again will reduce the traffic that has to traverse any NAT.
>> 
>> Soon, I think content providers (and providers of other services on the
> 'net) will roll v6 because of the performance increase as v6 will not have
> to traverse all this NAT and be subject to session limits, timeouts and
> such.
>> 
> 
> What do you mean by performance increase? If performance equals latency, v4
> will win for a long while still. Cgn does not add measurable latency.
> 
> Cb
>> --
>> Leigh
>> 
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>> 




From drais at icantclick.org  Thu Sep  8 10:09:27 2011
From: drais at icantclick.org (david raistrick)
Date: Thu, 8 Sep 2011 11:09:27 -0400 (EDT)
Subject: Brighthouse Outage in Tampa, FL
In-Reply-To: <218AB54691EB49439829EFD136F473CF0927FF69@exchange2k10.corp.power1.com>
References: <DC85D08B84BB854086E9524DAB67D18751D0ED@Teriwood.miller.local>
 <CA8DAA00.1980C%lists@mtin.net>
 <218AB54691EB49439829EFD136F473CF0927FF69@exchange2k10.corp.power1.com>
Message-ID: <alpine.BSF.2.00.1109081106400.80287@murf.icantclick.org>

On Thu, 8 Sep 2011, Dylan Bouterse wrote:

> Brighthouse in Orlando was not affected as far as I could tell, but I did hear of customers in Lakeland that were down. Pretty widespread outage.

Internally at brighthouse, Tampa (southwest florida) and Orlando (central 
florida) are pretty heavily detached from each other.  There's now some 
call center, management, and engineering overlap but that only happened 
over the last few years.  network and video delivery systems are still 
significantly divergent...  (which is usually a good thing, since it means 
that when tampa breaks, orlando survives. ;)




--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html




From lyle at lcrcomputer.net  Thu Sep  8 10:49:36 2011
From: lyle at lcrcomputer.net (Lyle Giese)
Date: Thu, 08 Sep 2011 10:49:36 -0500
Subject: what about the users re: NAT444 or ?
In-Reply-To: <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
 <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
 <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
Message-ID: <4E68E410.7010005@lcrcomputer.net>

Can we really push an IPv6 agenda for CDN's when IPv6 routing at high 
backend levels is still not complete?  I certainly don't have the 
'clout' to push that, but full routing between Cogent and HE needs to be 
fixed.

Lyle Giese
LCR Computer Services, Inc.

On 09/08/11 10:04, Christian de Larrinaga wrote:
> I wonder if the discussion as useful as it is isn't forgetting that the edge of Internet has a stake in getting this right too! This is not just an ISP problem but one where content providers and services that is the users need to get from here to there in good order.
>
> So
>
> What can users do to encourage ISPs to deploy v6 to them?
> What can users do to ease the pain in reaching IPv4 only sites once they are on IPv6 tails?
>
> Is there not a bit of CPE needed here? What should the CPE do? and not do? should it deprecate NAT/PAT when it receives 1918 allocation from a CGN?
> and less technically but relevant I think is to ask about cost? who pays?
>
>
> Christian
>
> On 8 Sep 2011, at 15:02, Cameron Byrne wrote:
>
>> On Sep 8, 2011 1:47 AM, "Leigh Porter"<leigh.porter at ukbroadband.com>  wrote:
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Owen DeLong [mailto:owen at delong.com]
>>>> Sent: 08 September 2011 01:22
>>>> To: Leigh Porter
>>>> Cc: Seth Mos; NANOG
>>>> Subject: Re: NAT444 or ?
>>>>
>>>>> Considering that offices, schools etc regularly have far more than 10
>>>> users per IP, I think this limit is a little low. I've happily had
>>>> around 300 per public IP address on a large WiFi network, granted these
>>>> are all different kinds of users, it is just something that operational
>>>> experience will have to demonstrate.
>>>>>
>>>> Yes, but, you are counting individual users whereas at the NAT444
>>>> level, what's really being counted is end-customer sites not individual
>>>> users, so the term
>>>> "users" is a bit misleading in the context. A given end-customer site
>>>> may be from 1 to 50 or more individual users.
>>>
>>> Indeed, my users are using LTE dongles mostly so I expect they will be
>> single users. At the moment on the WiMAX network I see around 35 sessions
>> from a WiMAX modem on average rising to about 50 at peak times. These are a
>> combination of individual users and "home modems".
>>>
>>> We had some older modems that had integrated NAT that was broken and
>> locked up the modem at 200 sessions. Then some old base station software
>> died at about 10K sessions. So we monitor these things now..
>>>
>>>
>>>>
>>>>> I would love to avoid NAT444, I do not see a viable way around it at
>>>> the moment. Unless the Department of Work and Pensions release their /8
>>>> that is ;-)
>>>>>
>>>>
>>>> The best mitigation really is to get IPv6 deployed as rapidly and
>>>> widely as possible. The more stuff can go native IPv6, the less depends
>>>> on fragile NAT444.
>>>
>>> Absolutely. Even things like google maps, if that can be dumped on v6,
>> it'll save a load of sessions from people. The sooner services such as
>> Microsoft Update turn on v6 the better as well. I would also like the CDNs
>> to be able to deliver content in v6 (even if the main page is v4) which
>> again will reduce the traffic that has to traverse any NAT.
>>>
>>> Soon, I think content providers (and providers of other services on the
>> 'net) will roll v6 because of the performance increase as v6 will not have
>> to traverse all this NAT and be subject to session limits, timeouts and
>> such.
>>>
>>
>> What do you mean by performance increase? If performance equals latency, v4
>> will win for a long while still. Cgn does not add measurable latency.
>>
>> Cb
>>> --
>>> Leigh
>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>>
>
>




From randy at psg.com  Thu Sep  8 10:54:23 2011
From: randy at psg.com (Randy Bush)
Date: Thu, 08 Sep 2011 17:54:23 +0200
Subject: what about the users re: NAT444 or ?
In-Reply-To: <4E68E410.7010005@lcrcomputer.net>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
 <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
 <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
 <4E68E410.7010005@lcrcomputer.net>
Message-ID: <m2ehzrxc5s.wl%randy@psg.com>

> Can we really push an IPv6 agenda for CDN's when IPv6 routing at high 
> backend levels is still not complete?  I certainly don't have the 
> 'clout' to push that, but full routing between Cogent and HE needs to be 
> fixed.

if you are worried about full v4 or v6 or v8-juice routing between
cogent and X, for many values of X, then you will never be unworried.

randy



From joelja at bogus.com  Thu Sep  8 11:22:47 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Thu, 08 Sep 2011 09:22:47 -0700
Subject: what about the users re: NAT444 or ?
In-Reply-To: <4E68E410.7010005@lcrcomputer.net>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
 <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
 <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
 <4E68E410.7010005@lcrcomputer.net>
Message-ID: <4E68EBD7.1070603@bogus.com>

On 9/8/11 08:49 , Lyle Giese wrote:
> Can we really push an IPv6 agenda for CDN's when IPv6 routing at high
> backend levels is still not complete?  I certainly don't have the
> 'clout' to push that, but full routing between Cogent and HE needs to be
> fixed.

It's your job to run your network such that you have connectivity to the
destinations your customers want to reach not Cogent's or HE's...

> Lyle Giese
> LCR Computer Services, Inc.
> 
> On 09/08/11 10:04, Christian de Larrinaga wrote:
>> I wonder if the discussion as useful as it is isn't forgetting that
>> the edge of Internet has a stake in getting this right too! This is
>> not just an ISP problem but one where content providers and services
>> that is the users need to get from here to there in good order.
>>
>> So
>>
>> What can users do to encourage ISPs to deploy v6 to them?
>> What can users do to ease the pain in reaching IPv4 only sites once
>> they are on IPv6 tails?
>>
>> Is there not a bit of CPE needed here? What should the CPE do? and not
>> do? should it deprecate NAT/PAT when it receives 1918 allocation from
>> a CGN?
>> and less technically but relevant I think is to ask about cost? who pays?
>>
>>
>> Christian
>>
>> On 8 Sep 2011, at 15:02, Cameron Byrne wrote:
>>
>>> On Sep 8, 2011 1:47 AM, "Leigh Porter"<leigh.porter at ukbroadband.com> 
>>> wrote:
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Owen DeLong [mailto:owen at delong.com]
>>>>> Sent: 08 September 2011 01:22
>>>>> To: Leigh Porter
>>>>> Cc: Seth Mos; NANOG
>>>>> Subject: Re: NAT444 or ?
>>>>>
>>>>>> Considering that offices, schools etc regularly have far more than 10
>>>>> users per IP, I think this limit is a little low. I've happily had
>>>>> around 300 per public IP address on a large WiFi network, granted
>>>>> these
>>>>> are all different kinds of users, it is just something that
>>>>> operational
>>>>> experience will have to demonstrate.
>>>>>>
>>>>> Yes, but, you are counting individual users whereas at the NAT444
>>>>> level, what's really being counted is end-customer sites not
>>>>> individual
>>>>> users, so the term
>>>>> "users" is a bit misleading in the context. A given end-customer site
>>>>> may be from 1 to 50 or more individual users.
>>>>
>>>> Indeed, my users are using LTE dongles mostly so I expect they will be
>>> single users. At the moment on the WiMAX network I see around 35
>>> sessions
>>> from a WiMAX modem on average rising to about 50 at peak times. These
>>> are a
>>> combination of individual users and "home modems".
>>>>
>>>> We had some older modems that had integrated NAT that was broken and
>>> locked up the modem at 200 sessions. Then some old base station software
>>> died at about 10K sessions. So we monitor these things now..
>>>>
>>>>
>>>>>
>>>>>> I would love to avoid NAT444, I do not see a viable way around it at
>>>>> the moment. Unless the Department of Work and Pensions release
>>>>> their /8
>>>>> that is ;-)
>>>>>>
>>>>>
>>>>> The best mitigation really is to get IPv6 deployed as rapidly and
>>>>> widely as possible. The more stuff can go native IPv6, the less
>>>>> depends
>>>>> on fragile NAT444.
>>>>
>>>> Absolutely. Even things like google maps, if that can be dumped on v6,
>>> it'll save a load of sessions from people. The sooner services such as
>>> Microsoft Update turn on v6 the better as well. I would also like the
>>> CDNs
>>> to be able to deliver content in v6 (even if the main page is v4) which
>>> again will reduce the traffic that has to traverse any NAT.
>>>>
>>>> Soon, I think content providers (and providers of other services on the
>>> 'net) will roll v6 because of the performance increase as v6 will not
>>> have
>>> to traverse all this NAT and be subject to session limits, timeouts and
>>> such.
>>>>
>>>
>>> What do you mean by performance increase? If performance equals
>>> latency, v4
>>> will win for a long while still. Cgn does not add measurable latency.
>>>
>>> Cb
>>>> -- 
>>>> Leigh
>>>>
>>>>
>>>> ______________________________________________________________________
>>>> This email has been scanned by the MessageLabs Email Security System.
>>>> For more information please visit http://www.messagelabs.com/email
>>>> ______________________________________________________________________
>>>>
>>
>>
> 
> 




From dwing at cisco.com  Thu Sep  8 11:44:30 2011
From: dwing at cisco.com (Dan Wing)
Date: Thu, 8 Sep 2011 09:44:30 -0700
Subject: NAT444 or ?
In-Reply-To: <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
 <m2y5y0r72b.wl%randy@psg.com> <20110907163656.GA9961@srv03.cluenet.de>
 <D181DDABABE57E4DB72FEE00331478643BAB51@EALPO1.ukbroadband.com>
 <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
Message-ID: <028201cc6e46$94934fb0$bdb9ef10$@com>

> -----Original Message-----
> From: Geoff Huston [mailto:gih at apnic.net]
> Sent: Wednesday, September 07, 2011 10:27 PM
> To: Leigh Porter
> Cc: nanog at nanog.org list; Daniel Roesen
> Subject: Re: NAT444 or ?
> 
> 
> On 08/09/2011, at 2:41 AM, Leigh Porter wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Daniel Roesen [mailto:dr at cluenet.de]
> >> Sent: 07 September 2011 17:38
> >> To: nanog at nanog.org
> >> Subject: Re: NAT444 or ?
> >>
> >> On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote:
> >>>> I'm going to have to deploy NAT444 with dual-stack real soon now.
> >>>
> >>> you may want to review the presentations from last week's apnic
> >> meeting
> >>> in busan.  real mesurements.  sufficiently scary that people who
> were
> >>> heavily pushing nat444 for the last two years suddenly started to
> say
> >>> "it was not me who pushed nat444, it was him!"  as if none of us
> had
> >> a
> >>> memory.
> >>
> >> Hm, I fail to find relevant slides discussing that. Could you please
> >> point us to those?
> >>
> >> I'm looking at http://meetings.apnic.net/32
> >
> > There is a lot in the IPv6 plenary sessions:
> >
> > http://meetings.apnic.net/32/program/ipv6
> >
> > This is what I am looking at right now. Randy makes some good
> comments in those sessions. I have not found anything yet, but I am
> only on session 3, pertaining specifically to issues around NAT444.
> 
> It may not be what Randy was referring to above, but as part of that
> program at APNIC32 I reported on the failure rate I am measuring for
> Teredo. I'm not sure its all in the slides I was using, but what I was
> trying to say was that STUN is simply terrible at reliably negotiating
> a NAT.

Teredo does not use STUN; Teredo was implemented before STUN was fully
spec'd and does its own thing.

Teredo tries to determine if the type of NAT it is behind ("cone", 
"symmetric", etc.)  Determining the type of NAT has been found to 
be difficult, and nearly impossible (*) and removed from the current
RFC for STUN (**).  I suspect most of Teredo's failures are related 
to this procedure not working effectively.  A CGN can't improve that.

(*) http://tools.ietf.org/html/rfc5780#section-1
(**) http://tools.ietf.org/html/rfc5389#section-2

> I was then wondering what pixie dust CGNs were going to use that
> would have any impact on the ~50% connection failure rate I'm observing
> in Teredo.  And if there is no such thing as pixie dust (damn!) I was
> then wondering if NATs are effectively unuseable if you want anything
> fancier than 1:1 TCP connections (like multi-user games, for example).
> After all, a 50% connection failure rate for STUN is hardly encouraging
> news for a CGN deployer if your basic objective is not to annoy your
> customers.

If the CGN has both Endpoint-Independent Filtering (***) behavior
and Endpoint-Independent Mapping (****) behavior, the CGN won't make
Teredo worse -- Teredo will be as bad as today, caused by the home
user's own pretty NAT.  With that behavior, it also won't make 
applications that use STUN or ICE worse, or applications that use 
STUN-like or ICE-like techniques such as Skype.

(***) endpoint-independent filtering: means it doesn't filter incoming
packets after a mapping is created.  See
http://tools.ietf.org/html/rfc4787#section-5 for canonical definition.

(****) Endpoint-Independent Mapping:  means when the internal host sends a
packet with the same source port, to any destination, the same public port
is mapped.   See http://tools.ietf.org/html/rfc4787#section-4.1 for
canonical definition

-d





From dwing at cisco.com  Thu Sep  8 11:47:28 2011
From: dwing at cisco.com (Dan Wing)
Date: Thu, 8 Sep 2011 09:47:28 -0700
Subject: NAT444 or ?
In-Reply-To: <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
 <m2y5y0r72b.wl%randy@psg.com> <20110907163656.GA9961@srv03.cluenet.de>
 <D181DDABABE57E4DB72FEE00331478643BAB51@EALPO1.ukbroadband.com>
 <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
 <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
Message-ID: <028301cc6e46$feaa6e10$fbff4a30$@com>

...
> The striking thing I picked up is that NTT considers the CGN equipment
> a big black hole where money goes into. Because it won't solve their
> problem now or in the future and it becomes effectively a piece of
> equipment they need to buy and then scrap "soon" after.

It would get scrapped when all servers support dual stack.  What year
is that predicted to occur?

> They acknowledge the need, but they'd rather not buy one.
> That and they (the isp) get called for anything which doesn't work.

-d





From dwing at cisco.com  Thu Sep  8 11:52:05 2011
From: dwing at cisco.com (Dan Wing)
Date: Thu, 8 Sep 2011 09:52:05 -0700
Subject: what about the users re: NAT444 or ?
In-Reply-To: <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
 <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
 <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
Message-ID: <028401cc6e47$a3faae70$ebf00b50$@com>

> -----Original Message-----
> From: Christian de Larrinaga [mailto:cdel at firsthand.net]
> Sent: Thursday, September 08, 2011 8:05 AM
> To: Cameron Byrne
> Cc: NANOG
> Subject: what about the users re: NAT444 or ?
> 
> I wonder if the discussion as useful as it is isn't forgetting that the
> edge of Internet has a stake in getting this right too! This is not
> just an ISP problem but one where content providers and services that
> is the users need to get from here to there in good order.
> 
> So
> 
> What can users do to encourage ISPs to deploy v6 to them?
> What can users do to ease the pain in reaching IPv4 only sites once
> they are on IPv6 tails?
> 
> Is there not a bit of CPE needed here? What should the CPE do? and not
> do? should it deprecate NAT/PAT when it receives 1918 allocation from a
> CGN?

Careful with that idea -- people like their in-home network to continue
functioning even when their ISP is down or having an outage.  Consider
a home NAS holding delivering content to the stereo or the television.
It is possible to eliminate reliance on the ISP's network and still
have the in-home network function, but it's more difficult than just
continuing to run NAT44 in the home like today.  (Dual Stack-Lite
can accomplish this pretty easily, because the IPv4 addresses in
the home can be any IPv4 address whatsoever -- which allows the
in-home CPE ("B4", in Dual Stack-Lite parlance) to assign any address
it wants with its built-in DHCP server.)

-d

> and less technically but relevant I think is to ask about cost? who
> pays?
> 
> 
> Christian
> 
> On 8 Sep 2011, at 15:02, Cameron Byrne wrote:
> 
> > On Sep 8, 2011 1:47 AM, "Leigh Porter" <leigh.porter at ukbroadband.com>
> wrote:
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Owen DeLong [mailto:owen at delong.com]
> >>> Sent: 08 September 2011 01:22
> >>> To: Leigh Porter
> >>> Cc: Seth Mos; NANOG
> >>> Subject: Re: NAT444 or ?
> >>>
> >>>> Considering that offices, schools etc regularly have far more than
> 10
> >>> users per IP, I think this limit is a little low. I've happily had
> >>> around 300 per public IP address on a large WiFi network, granted
> these
> >>> are all different kinds of users, it is just something that
> operational
> >>> experience will have to demonstrate.
> >>>>
> >>> Yes, but, you are counting individual users whereas at the NAT444
> >>> level, what's really being counted is end-customer sites not
> individual
> >>> users, so the term
> >>> "users" is a bit misleading in the context. A given end-customer
> site
> >>> may be from 1 to 50 or more individual users.
> >>
> >> Indeed, my users are using LTE dongles mostly so I expect they will
> be
> > single users. At the moment on the WiMAX network I see around 35
> sessions
> > from a WiMAX modem on average rising to about 50 at peak times. These
> are a
> > combination of individual users and "home modems".
> >>
> >> We had some older modems that had integrated NAT that was broken and
> > locked up the modem at 200 sessions. Then some old base station
> software
> > died at about 10K sessions. So we monitor these things now..
> >>
> >>
> >>>
> >>>> I would love to avoid NAT444, I do not see a viable way around it
> at
> >>> the moment. Unless the Department of Work and Pensions release
> their /8
> >>> that is ;-)
> >>>>
> >>>
> >>> The best mitigation really is to get IPv6 deployed as rapidly and
> >>> widely as possible. The more stuff can go native IPv6, the less
> depends
> >>> on fragile NAT444.
> >>
> >> Absolutely. Even things like google maps, if that can be dumped on
> v6,
> > it'll save a load of sessions from people. The sooner services such
> as
> > Microsoft Update turn on v6 the better as well. I would also like the
> CDNs
> > to be able to deliver content in v6 (even if the main page is v4)
> which
> > again will reduce the traffic that has to traverse any NAT.
> >>
> >> Soon, I think content providers (and providers of other services on
> the
> > 'net) will roll v6 because of the performance increase as v6 will not
> have
> > to traverse all this NAT and be subject to session limits, timeouts
> and
> > such.
> >>
> >
> > What do you mean by performance increase? If performance equals
> latency, v4
> > will win for a long while still. Cgn does not add measurable latency.
> >
> > Cb
> >> --
> >> Leigh
> >>
> >>
> >>
> ______________________________________________________________________
> >> This email has been scanned by the MessageLabs Email Security
> System.
> >> For more information please visit http://www.messagelabs.com/email
> >>
> ______________________________________________________________________
> >>





From Mike.Rae at sjrb.ca  Thu Sep  8 11:58:18 2011
From: Mike.Rae at sjrb.ca (Mike Rae)
Date: Thu, 8 Sep 2011 10:58:18 -0600
Subject: Colo Space Provider Contact - Amsterdam Telecity2
Message-ID: <50472F725ECB89459EBAA5708D6C66DF019C8C09@PRDCG4EXVW01-5.OSS.PRD>

Hi :

If there is anyone who offers colo in Telecity2 in Amsterdam on this
list, can you please contact me off list ?

Thanks
Mike




From dwing at cisco.com  Thu Sep  8 12:04:29 2011
From: dwing at cisco.com (Dan Wing)
Date: Thu, 8 Sep 2011 10:04:29 -0700
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BADD2@EALPO1.ukbroadband.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl> <4E67D24F.10706@otd.com>
 <D181DDABABE57E4DB72FEE00331478643BADD2@EALPO1.ukbroadband.com>
Message-ID: <02c401cc6e49$5f13c1a0$1d3b44e0$@com>

> -----Original Message-----
> From: Leigh Porter [mailto:leigh.porter at ukbroadband.com]
> Sent: Wednesday, September 07, 2011 1:38 PM
> To: David Israel; nanog at nanog.org
> Subject: RE: NAT444 or ?
> 
> 
> 
> > -----Original Message-----
> > From: David Israel [mailto:davei at otd.com]
> > Sent: 07 September 2011 21:23
> > To: nanog at nanog.org
> > Subject: Re: NAT444 or ?
> >
> > On 9/7/2011 3:24 PM, Seth Mos wrote:
> > > I think you have the numbers off, he started with 1000 users
> sharing
> > the same IP, since you can only do 62k sessions or so and with a
> > "normal" timeout on those sessions you ran into issues quickly.
> > >
> >
> > Remember that a TCP session is defined not just by the port, but by
> the
> > combination of source address:source port:destination
> > address:destination port.  So that's 62k sessions *per destination*
> per
> > ip address.   In theory, this particular performance problem should
> > only
> > arise when the NAT gear insists on a unique port per session (which
> is
> > common, but unnecessary) or when a particular destination is
> > inordinately popular; the latter problem could be addressed by
> > increasing the number of addresses that facebook.com and google.com
> > resolve to.
> 
> Good point, but aside from these scaling issues which I expect can be
> resolved to a point, the more serious issue, I think, is applications
> that just do not work with double NAT. Now, I have not conducted any
> serious research into this, but it seems that draft-donley-nat444-
> impacts does appear to have highlight issues that may have been down to
> implementation.

Draft-donley-nat444-impacts conflates bandwidth constraints with CGN
with in-home NAT.  Until those are separated and then analyzed carefully,
it is harmful to draw conclusions such as "NAT444 bad; NAT44 good".

> Other simple tricks such as ensuring that your own internal services
> such as DNS are available without traversing NAT also help.

Yep.  But some users want to use other DNS servers for performance
(e.g., Google's or OpenDNS servers, especially considering they
could point the user at a 'better' (closer) CDN based on Client
IP), to avoid ISP DNS hijacking, or for content control (e.g.,
"parental control" of DNS hostnames).  That traffic will, necessarily,
traverse the CGN.  To avoid users burning through their UDP port 
allocation for those DNS queries it is useful for the CGN to 
have short timeouts for port 53.

> Certainly some more work can be done in this area, but I fear that the
> only way a real idea as to how much NAT444 really doe break things will
> be operational experience.

Yep.  (Same as everything else.)

-d


> 
> 
> --
> Leigh
> 
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________




From dwing at cisco.com  Thu Sep  8 12:10:24 2011
From: dwing at cisco.com (Dan Wing)
Date: Thu, 8 Sep 2011 10:10:24 -0700
Subject: NAT444 or ?
In-Reply-To: <4E67E22C.80807@viagenie.ca>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl> <4E67D24F.10706@otd.com>
 <4E67E22C.80807@viagenie.ca>
Message-ID: <02c501cc6e4a$32cddfd0$98699f70$@com>

> -----Original Message-----
> From: Simon Perreault [mailto:simon.perreault at viagenie.ca]
> Sent: Wednesday, September 07, 2011 2:29 PM
> To: nanog at nanog.org
> Subject: Re: NAT444 or ?
> 
> David Israel wrote, on 09/07/2011 04:21 PM:
> > In theory, this
> > particular performance problem should only arise when the NAT gear
> insists on a
> > unique port per session (which is common, but unnecessary)
> 
> What you're describing is known as "endpoint-independent mapping"
> behaviour. It
> is good for not breaking applications, not so good for scalability. RFC
> 4787 section 4.1 makes it a MUST.

There are two dimensions of that scalability, of course:

Endpoint-independent mapping means better scaling of the NAT itself, 
because it stores less state (slightly less memory for each active 
mapping and slightly less per-packet processing).  This savings
is exchanged for worse IPv4 utilization -- which I agree is not so
good for scalability.

-d





From dwing at cisco.com  Thu Sep  8 12:22:00 2011
From: dwing at cisco.com (Dan Wing)
Date: Thu, 8 Sep 2011 10:22:00 -0700
Subject: NAT444 or ?
In-Reply-To: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
References: <20110907163656.GA9961@srv03.cluenet.de>
 <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
Message-ID: <02c601cc6e4b$d21759d0$76460d70$@com>

> -----Original Message-----
> From: Jean-Francois.TremblayING at videotron.com [mailto:Jean-
> Francois.TremblayING at videotron.com]
> Sent: Wednesday, September 07, 2011 10:06 AM
> To: dr at cluenet.de
> Cc: nanog at nanog.org
> Subject: Re: NAT444 or ?
> 
> On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote:
> > > I'm going to have to deploy NAT444 with dual-stack real soon now.
> > you may want to review the presentations from last week's apnic
> meeting
> > in busan.  real mesurements.  sufficiently scary that people who were
> > heavily pushing nat444 for the last two years suddenly started to say
> > "it was not me who pushed nat444, it was him!"  as if none of us had
> a
> > memory.
> >
> > Hm, I fail to find relevant slides discussing that. Could you please
> > point us to those?
> 
> I had the same question. I found Miyakawa-san's presentation has some
> dramatic examples of CGN NAT444 effects using Google Maps:
> http://meetings.apnic.net/__data/assets/file/0011/38297/Miyakawa-APNIC-
> KEYNOTE-IPv6-2011-8.pptx.pdf
> 
> 
> However these are with a very high address-sharing ratio (several
> thousands users per address). Using a sparser density (<= 64 users per
> address) is likely to show much less dramatic user impacts.

Try it at home.  With aggressive usage of Microsoft's Terraserver,
mapquest, or google maps, I'm able to burn through 120 or so 
TCP connections.  Move the map around, zoom in/out, enable/disable 
traffic, switch between satellite and map and overlay, repeat those
steps 2-3 times.  Don't be slow and don't wait for everything 
to paint.

Or crash your browser and when it restarts watch how many connections
it makes to re-open all your tabs.

I understand iTunes opens lots of connections, but I haven't looked
at that.

To experiment with limited ports at home, load 3rd party firmware 
onto your NAT -- most of them allow controlling the number 
of mappings (and by default, have higher limits than stock
firmware).  Or consume a bunch of your mappings with a 
script (such as the brain-dead Perl script below) and then 
start your testing.  Some NATs and some servers will kill the 
TCP sessions after inactivity (which is why I describe the 
script as brain-dead).

-d

----

#!/usr/bin/perl -w
use IO::Socket;

$max = shift(@ARGV);
my $count = 0;
my $host = shift(@ARGV) || "www.example.com";
my @remote;

print "connecting to $host\n";

while ($count < $max) {
        printf ("connecting...(%d)\n", $count+1);
        $remote[$count] = IO::Socket::INET->new(
                Proto => "tcp",
                PeerAddr => $host,
                PeerPort => "80")
                        or warn "got an error";
        $count++;
}

print "press Return to exit\n";
my $junk = <STDIN>;

$count = 0;
while ($count < $max) {
        close $remote[$count];
        $count++;
}

exit;





From dwing at cisco.com  Thu Sep  8 12:44:08 2011
From: dwing at cisco.com (Dan Wing)
Date: Thu, 8 Sep 2011 10:44:08 -0700
Subject: NAT444 or ?
In-Reply-To: <m2y5y0r72b.wl%randy@psg.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <86E509F1-FD44-46EE-A6A3-DC83A46BDD60@gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BA795@EALPO1.ukbroadband.com>
 <m2y5y0r72b.wl%randy@psg.com>
Message-ID: <030301cc6e4e$e99d5b10$bcd81130$@com>

> -----Original Message-----
> From: Randy Bush [mailto:randy at psg.com]
> Sent: Wednesday, September 07, 2011 3:16 AM
> To: Leigh Porter
> Cc: North American Network Operators' Group
> Subject: Re: NAT444 or ?
> 
> > I'm going to have to deploy NAT444 with dual-stack real soon now.
> 
> you may want to review the presentations from last week's apnic meeting
> in busan.  real mesurements.  sufficiently scary that people who were
> heavily pushing nat444 for the last two years suddenly started to say
> "it was not me who pushed nat444, it was him!"  as if none of us had a
> memory.

Many of the problems are due to IPv4 address sharing, which will be
problems for A+P, CGN, HTTP proxies, and other address sharing 
technologies.  RFC6269 discusses most (or all) of those problems.
There are workarounds to those problems, but most are not 
pretty.  The solution is IPv6.

-d





From grobe0ba at gmail.com  Thu Sep  8 17:44:21 2011
From: grobe0ba at gmail.com (Atticus)
Date: Thu, 8 Sep 2011 18:44:21 -0400
Subject: kernel.org dns broken
Message-ID: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>

I can't resolve anything for kernel.org from Verizon's 3G network, or from
HE in California. I'm using HE's nameservers, with Google's as a backup.
Neither of them have any records. Anyone know what's up?

-- 
FT3(SU) Byron Grobe, USN


From lstewart at superb.net  Thu Sep  8 17:50:29 2011
From: lstewart at superb.net (Landon Stewart)
Date: Thu, 8 Sep 2011 15:50:29 -0700
Subject: kernel.org dns broken
In-Reply-To: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
Message-ID: <CABgOHgtV2U=rDVJk1woyqOuB3F_N=A5sC00uiSepwcqBBDyoog@mail.gmail.com>

On 8 September 2011 15:44, Atticus <grobe0ba at gmail.com> wrote:

> I can't resolve anything for kernel.org from Verizon's 3G network, or from
> HE in California. I'm using HE's nameservers, with Google's as a backup.
> Neither of them have any records. Anyone know what's up?


I'm seeing the same issue.  One of the authoritative name servers is timing
out and the other is not providing an authoritative record.

*# dig kernel.org @130.239.17.16 *

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> kernel.org @130.239.17.16
;; global options:  printcmd
;; connection timed out; no servers could be reached

*# dig kernel.org @209.132.180.67*

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> kernel.org @209.132.180.67
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1319
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;kernel.org.                    IN      A


-- 
Landon Stewart <LStewart at SUPERB.NET>
SuperbHosting.Net by Superb Internet Corp.
Toll Free (US/Canada): 888-354-6128 x 4199
Direct: 206-438-5879
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net


From tony.mccrory at gmail.com  Thu Sep  8 17:51:26 2011
From: tony.mccrory at gmail.com (Tony McCrory)
Date: Thu, 8 Sep 2011 23:51:26 +0100
Subject: kernel.org dns broken
In-Reply-To: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
Message-ID: <CAG9TQPmjLob6p4Tx-GAvK--r3qtJZyKxBvo=29amkoV5BNSsVw@mail.gmail.com>

On 8 September 2011 23:44, Atticus <grobe0ba at gmail.com> wrote:
> I can't resolve anything for kernel.org from Verizon's 3G network, or from
> HE in California. I'm using HE's nameservers, with Google's as a backup.
> Neither of them have any records. Anyone know what's up?

Strange one.

Also fails with my ISP (BE*There in the UK), but, org. nameservers have it fine:

$ dig kernel.org @c0.org.afilias-nst.info.

; <<>> DiG 9.6.-ESV-R3 <<>> kernel.org @c0.org.afilias-nst.info.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32885
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;kernel.org.                    IN      A

;; AUTHORITY SECTION:
kernel.org.             86400   IN      NS      ns.vger.kernel.org.
kernel.org.             86400   IN      NS      ns4.kernel.org.

;; ADDITIONAL SECTION:
ns.vger.kernel.org.     86400   IN      A       209.132.180.67
ns4.kernel.org.         86400   IN      A       130.239.17.16
ns4.kernel.org.         86400   IN      AAAA    2001:6b0:e:4017::1:1

;; Query time: 40 msec
;; SERVER: 199.19.53.1#53(199.19.53.1)
;; WHEN: Thu Sep  8 22:46:33 2011
;; MSG SIZE  rcvd: 138



From pixitha.kyle at gmail.com  Thu Sep  8 17:54:34 2011
From: pixitha.kyle at gmail.com (Kyle Duren)
Date: Thu, 8 Sep 2011 15:54:34 -0700
Subject: kernel.org dns broken
In-Reply-To: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
Message-ID: <CADehQgSvZbyXVZ+Tz-h_L-G9w_W_-wEbn=DOkBxTshwFjFi8tA@mail.gmail.com>

On Thu, Sep 8, 2011 at 3:44 PM, Atticus <grobe0ba at gmail.com> wrote:

> I can't resolve anything for kernel.org from Verizon's 3G network, or from
> HE in California. I'm using HE's nameservers, with Google's as a backup.
> Neither of them have any records. Anyone know what's up?
>
> --
> FT3(SU) Byron Grobe, USN
>

Maybe related to the hacking that they discovered recently?

http://linux.slashdot.org/story/11/08/31/2321232/Kernelorg-Compromised

-Kyle


From jhcook at gmail.com  Thu Sep  8 17:58:46 2011
From: jhcook at gmail.com (Justin Cook)
Date: Thu, 8 Sep 2011 23:58:46 +0100
Subject: kernel.org dns broken
In-Reply-To: <CADehQgSvZbyXVZ+Tz-h_L-G9w_W_-wEbn=DOkBxTshwFjFi8tA@mail.gmail.com>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
 <CADehQgSvZbyXVZ+Tz-h_L-G9w_W_-wEbn=DOkBxTshwFjFi8tA@mail.gmail.com>
Message-ID: <CAHTccjabscbpaKO8aFv=dSXL44MsOA9uA4Hg2nYmEudYrUkw_w@mail.gmail.com>

Here in London on BE*There it was not working, either. But the queries
are coming through now.

$ dig www.kernel.org +short
140.211.169.30


On Thu, Sep 8, 2011 at 11:54 PM, Kyle Duren <pixitha.kyle at gmail.com> wrote:
> On Thu, Sep 8, 2011 at 3:44 PM, Atticus <grobe0ba at gmail.com> wrote:
>
>> I can't resolve anything for kernel.org from Verizon's 3G network, or from
>> HE in California. I'm using HE's nameservers, with Google's as a backup.
>> Neither of them have any records. Anyone know what's up?
>>
>> --
>> FT3(SU) Byron Grobe, USN
>>
>
> Maybe related to the hacking that they discovered recently?
>
> http://linux.slashdot.org/story/11/08/31/2321232/Kernelorg-Compromised
>
> -Kyle
>



-- 
Justin Cook

M: +44 7500 960 000



From tony.mccrory at gmail.com  Thu Sep  8 17:59:52 2011
From: tony.mccrory at gmail.com (Tony McCrory)
Date: Thu, 8 Sep 2011 23:59:52 +0100
Subject: kernel.org dns broken
In-Reply-To: <CADehQgSvZbyXVZ+Tz-h_L-G9w_W_-wEbn=DOkBxTshwFjFi8tA@mail.gmail.com>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
 <CADehQgSvZbyXVZ+Tz-h_L-G9w_W_-wEbn=DOkBxTshwFjFi8tA@mail.gmail.com>
Message-ID: <CAG9TQPmhO0xP2po=AiWJWYQGHjQvWBLVuuZDLfWdeWXHx9Z1Rg@mail.gmail.com>

Looks like its fixed already

$  dig kernel.org @8.8.8.8

; <<>> DiG 9.6.-ESV-R3 <<>> kernel.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13079
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;kernel.org.                    IN      A

;; ANSWER SECTION:
kernel.org.             3298    IN      A       140.211.169.30



From jf at probe-networks.de  Thu Sep  8 18:11:46 2011
From: jf at probe-networks.de (Jonas Frey (Probe Networks))
Date: Fri, 09 Sep 2011 01:11:46 +0200
Subject: Saudi Telecom sending route with invalid attributes 212.118.142.0/24
Message-ID: <1315523506.3147.211.camel@wks02>

Hello,

anyone else getting a route for 212.118.142.0/24 with invalid
attributes? Seems this is (again) causing problems with some (older)
routers/software.

               Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
6-Resolve tree 2 
                AS path: 6453 39386 25019 I Unrecognized Attributes: 39
bytes
                AS path:  Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
00 00 00 64
                Accepted Multipath


-Jonas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110909/fd41dc6f/attachment.bin>

From raymond at prolocation.net  Thu Sep  8 18:14:33 2011
From: raymond at prolocation.net (Raymond Dijkxhoorn)
Date: Fri, 9 Sep 2011 01:14:33 +0200 (CEST)
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24
In-Reply-To: <1315523506.3147.211.camel@wks02>
References: <1315523506.3147.211.camel@wks02>
Message-ID: <alpine.LFD.2.00.1109090112570.20892@noc.prolocation.net>

Hi!

> anyone else getting a route for 212.118.142.0/24 with invalid
> attributes? Seems this is (again) causing problems with some (older)
> routers/software.
>
>               Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
> 6-Resolve tree 2
>                AS path: 6453 39386 25019 I Unrecognized Attributes: 39
> bytes
>                AS path:  Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
> 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
> 00 00 00 64
>                Accepted Multipath

Exactly the same here.

Sep  8 20:24:04  BBD-RC02 rpd[1334]: Received BAD update from 
94.228.128.57 (External AS 41887), aspath_attr():3472 
PA4_TYPE_ATTRSET(128) => 1 times IGNORED, family inet-unicast(1), prefix 
212.118.142.0/24

Bye,
Raymond.



From gabriel.grissett at gmail.com  Thu Sep  8 18:17:04 2011
From: gabriel.grissett at gmail.com (Gabriel Grissett)
Date: Thu, 8 Sep 2011 18:17:04 -0500
Subject: kernel.org dns broken
In-Reply-To: <CAG9TQPmhO0xP2po=AiWJWYQGHjQvWBLVuuZDLfWdeWXHx9Z1Rg@mail.gmail.com>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
 <CADehQgSvZbyXVZ+Tz-h_L-G9w_W_-wEbn=DOkBxTshwFjFi8tA@mail.gmail.com>
 <CAG9TQPmhO0xP2po=AiWJWYQGHjQvWBLVuuZDLfWdeWXHx9Z1Rg@mail.gmail.com>
Message-ID: <CAPRkJ3QDP-B=mvjWdOPbXMOhBHjQ2yOOPx16b3xGQXMEHV_=pg@mail.gmail.com>

# telnet kernel.org 80
Trying 140.211.169.30...
telnet: Unable to connect to remote host: Connection refused
# telnet kernel.org 21
Trying 140.211.169.30...
^C
# telnet www.kernel.org 80
Trying 140.211.169.30...
telnet: Unable to connect to remote host: Connection refused
# telnet www.kernel.org 21
Trying 140.211.169.30...
^C

...

199.6.1.165 http/ftp is good, 2001:6b0:e:4017:1994:313:1:0 http/ftp is not.

GeoDNS hasn't been working for a few days perhaps since the trouble
they have recently had (do not know if it was previously working
correctly).

IPs are from testing GeoDNS @ around Wed, 07 Sep 2011 19:51 GMT.
(kernel.org would resolve; www.kernel.org would not due to CNAME to
www.geo.kernel.org; attempts to resolve www.geo.kernel.org would
timeout; mirrors.kernel.org suffered a similar fate for me).

-GPG

Perhaps useful (from yesterday's terminal history):
# dig www.us.kernel.org ANY

; <<>> DiG 9.6-ESV-R4 <<>> www.us.kernel.org ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 362
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 7, ADDITIONAL: 8

;; QUESTION SECTION:
;www.us.kernel.org.             IN      ANY

;; ANSWER SECTION:
www.us.kernel.org.      600     IN      A       66.160.172.98
www.us.kernel.org.      600     IN      A       128.30.2.36
www.us.kernel.org.      600     IN      A       146.137.96.7
www.us.kernel.org.      600     IN      A       146.137.96.15
www.us.kernel.org.      600     IN      A       155.98.64.81
www.us.kernel.org.      600     IN      A       208.69.120.79
www.us.kernel.org.      600     IN      A       216.165.129.139
www.us.kernel.org.      600     IN      A       216.176.132.235

;; AUTHORITY SECTION:
kernel.org.             86400   IN      NS      ns0.kernel.org.
kernel.org.             86400   IN      NS      ns1.kernel.org.
kernel.org.             86400   IN      NS      ns3.kernel.org.
kernel.org.             86400   IN      NS      ns2.kernel.org.
kernel.org.             86400   IN      NS      ns5.kernel.org.
kernel.org.             86400   IN      NS      ns4.kernel.org.
kernel.org.             86400   IN      NS      ns.vger.kernel.org.

;; ADDITIONAL SECTION:
ns0.kernel.org.         85692   IN      A       140.211.167.34
ns1.kernel.org.         71877   IN      A       149.20.20.144
ns1.kernel.org.         600     IN      AAAA    2001:4f8:8:10::1:1
ns2.kernel.org.         29867   IN      A       149.20.4.80
ns2.kernel.org.         600     IN      AAAA    2001:4f8:1:10::1:1
ns3.kernel.org.         15397   IN      A       199.6.1.176
ns3.kernel.org.         600     IN      AAAA    2001:500:60:10::1:1
ns5.kernel.org.         600     IN      A       140.211.167.34

;; Query time: 247 msec
...
;; WHEN: Wed Sep  7 15:03:04 2011
;; MSG SIZE  rcvd: 457


On Thu, Sep 8, 2011 at 5:59 PM, Tony McCrory <tony.mccrory at gmail.com> wrote:
> Looks like its fixed already
>
> $ ?dig kernel.org @8.8.8.8
>
> ; <<>> DiG 9.6.-ESV-R3 <<>> kernel.org @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13079
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;kernel.org. ? ? ? ? ? ? ? ? ? ?IN ? ? ?A
>
> ;; ANSWER SECTION:
> kernel.org. ? ? ? ? ? ? 3298 ? ?IN ? ? ?A ? ? ? 140.211.169.30
>
>



From chaynes at centracomm.net  Thu Sep  8 18:20:33 2011
From: chaynes at centracomm.net (Clay Haynes)
Date: Thu, 8 Sep 2011 19:20:33 -0400
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24
In-Reply-To: <1315523506.3147.211.camel@wks02>
References: <1315523506.3147.211.camel@wks02>
Message-ID: <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>

On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
jf at probe-networks.de> wrote:

> Hello,
>
> anyone else getting a route for 212.118.142.0/24 with invalid
> attributes? Seems this is (again) causing problems with some (older)
> routers/software.
>
>               Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
> 6-Resolve tree 2
>                AS path: 6453 39386 25019 I Unrecognized Attributes: 39
> bytes
>                AS path:  Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
> 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
> 00 00 00 64
>                Accepted Multipath
>
>
> -Jonas
>
>
Yup! We're seeing the same thing too, and we're filtering it out.
Originating AS is 25019

-Clay


From lyle at lcrcomputer.net  Thu Sep  8 18:33:42 2011
From: lyle at lcrcomputer.net (Lyle Giese)
Date: Thu, 08 Sep 2011 18:33:42 -0500
Subject: kernel.org dns broken
In-Reply-To: <CAG9TQPmjLob6p4Tx-GAvK--r3qtJZyKxBvo=29amkoV5BNSsVw@mail.gmail.com>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
 <CAG9TQPmjLob6p4Tx-GAvK--r3qtJZyKxBvo=29amkoV5BNSsVw@mail.gmail.com>
Message-ID: <4E6950D6.1050601@lcrcomputer.net>

On 09/08/11 17:51, Tony McCrory wrote:
> On 8 September 2011 23:44, Atticus<grobe0ba at gmail.com>  wrote:
>> I can't resolve anything for kernel.org from Verizon's 3G network, or from
>> HE in California. I'm using HE's nameservers, with Google's as a backup.
>> Neither of them have any records. Anyone know what's up?
>
> Strange one.
>
> Also fails with my ISP (BE*There in the UK), but, org. nameservers have it fine:
>
> $ dig kernel.org @c0.org.afilias-nst.info.
>
> ;<<>>  DiG 9.6.-ESV-R3<<>>  kernel.org @c0.org.afilias-nst.info.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32885
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
> ;; WARNING: recursion requested but not available
>
> ;; QUESTION SECTION:
> ;kernel.org.                    IN      A
>
> ;; AUTHORITY SECTION:
> kernel.org.             86400   IN      NS      ns.vger.kernel.org.
> kernel.org.             86400   IN      NS      ns4.kernel.org.
>
> ;; ADDITIONAL SECTION:
> ns.vger.kernel.org.     86400   IN      A       209.132.180.67
> ns4.kernel.org.         86400   IN      A       130.239.17.16
> ns4.kernel.org.         86400   IN      AAAA    2001:6b0:e:4017::1:1
>
> ;; Query time: 40 msec
> ;; SERVER: 199.19.53.1#53(199.19.53.1)
> ;; WHEN: Thu Sep  8 22:46:33 2011
> ;; MSG SIZE  rcvd: 138
>

 From here (near Chicago), ns.vger.kernel.org is reporting that 
ns7.kernel.org and ns.vger.kernel.org are the authorative servers for 
kernel.org.  But the .org roots are claiming ns.vger.kernel.org and 
ns4.kernel.org are the authorative servers to use.

ns4.kernel.org is not accessable from here via IPv4 or IPv6.

ns7.kernel.org seems to be giving out sensible answers.

That will cause strange issues across the Internet until the roots match 
what ns.vger.kernel.org shows or ns4.kernel.org comes back online.

Lyle Giese
LCR Computer Services, Inc.



From lyle at lcrcomputer.net  Thu Sep  8 18:38:43 2011
From: lyle at lcrcomputer.net (Lyle Giese)
Date: Thu, 08 Sep 2011 18:38:43 -0500
Subject: what about the users re: NAT444 or ?
In-Reply-To: <4E68EBD7.1070603@bogus.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
 <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
 <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
 <4E68E410.7010005@lcrcomputer.net> <4E68EBD7.1070603@bogus.com>
Message-ID: <4E695203.50009@lcrcomputer.net>

And these 'perceived' routing issues won't be noticed nor are they 
important to CDN's?

I know what my job is, but that may not matter to the CDN's.  Reading 
this thread, I wanted to mention another problem that I feel has an 
effect on this issue.

Lyle

On 09/08/11 11:22, Joel jaeggli wrote:
> On 9/8/11 08:49 , Lyle Giese wrote:
>> Can we really push an IPv6 agenda for CDN's when IPv6 routing at high
>> backend levels is still not complete?  I certainly don't have the
>> 'clout' to push that, but full routing between Cogent and HE needs to be
>> fixed.
>
> It's your job to run your network such that you have connectivity to the
> destinations your customers want to reach not Cogent's or HE's...
>
>> Lyle Giese
>> LCR Computer Services, Inc.
>>
>> On 09/08/11 10:04, Christian de Larrinaga wrote:
>>> I wonder if the discussion as useful as it is isn't forgetting that
>>> the edge of Internet has a stake in getting this right too! This is
>>> not just an ISP problem but one where content providers and services
>>> that is the users need to get from here to there in good order.
>>>
>>> So
>>>
>>> What can users do to encourage ISPs to deploy v6 to them?
>>> What can users do to ease the pain in reaching IPv4 only sites once
>>> they are on IPv6 tails?
>>>
>>> Is there not a bit of CPE needed here? What should the CPE do? and not
>>> do? should it deprecate NAT/PAT when it receives 1918 allocation from
>>> a CGN?
>>> and less technically but relevant I think is to ask about cost? who pays?
>>>
>>>
>>> Christian
>>>
>>> On 8 Sep 2011, at 15:02, Cameron Byrne wrote:
>>>
>>>> On Sep 8, 2011 1:47 AM, "Leigh Porter"<leigh.porter at ukbroadband.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Owen DeLong [mailto:owen at delong.com]
>>>>>> Sent: 08 September 2011 01:22
>>>>>> To: Leigh Porter
>>>>>> Cc: Seth Mos; NANOG
>>>>>> Subject: Re: NAT444 or ?
>>>>>>
>>>>>>> Considering that offices, schools etc regularly have far more than 10
>>>>>> users per IP, I think this limit is a little low. I've happily had
>>>>>> around 300 per public IP address on a large WiFi network, granted
>>>>>> these
>>>>>> are all different kinds of users, it is just something that
>>>>>> operational
>>>>>> experience will have to demonstrate.
>>>>>>>
>>>>>> Yes, but, you are counting individual users whereas at the NAT444
>>>>>> level, what's really being counted is end-customer sites not
>>>>>> individual
>>>>>> users, so the term
>>>>>> "users" is a bit misleading in the context. A given end-customer site
>>>>>> may be from 1 to 50 or more individual users.
>>>>>
>>>>> Indeed, my users are using LTE dongles mostly so I expect they will be
>>>> single users. At the moment on the WiMAX network I see around 35
>>>> sessions
>>>> from a WiMAX modem on average rising to about 50 at peak times. These
>>>> are a
>>>> combination of individual users and "home modems".
>>>>>
>>>>> We had some older modems that had integrated NAT that was broken and
>>>> locked up the modem at 200 sessions. Then some old base station software
>>>> died at about 10K sessions. So we monitor these things now..
>>>>>
>>>>>
>>>>>>
>>>>>>> I would love to avoid NAT444, I do not see a viable way around it at
>>>>>> the moment. Unless the Department of Work and Pensions release
>>>>>> their /8
>>>>>> that is ;-)
>>>>>>>
>>>>>>
>>>>>> The best mitigation really is to get IPv6 deployed as rapidly and
>>>>>> widely as possible. The more stuff can go native IPv6, the less
>>>>>> depends
>>>>>> on fragile NAT444.
>>>>>
>>>>> Absolutely. Even things like google maps, if that can be dumped on v6,
>>>> it'll save a load of sessions from people. The sooner services such as
>>>> Microsoft Update turn on v6 the better as well. I would also like the
>>>> CDNs
>>>> to be able to deliver content in v6 (even if the main page is v4) which
>>>> again will reduce the traffic that has to traverse any NAT.
>>>>>
>>>>> Soon, I think content providers (and providers of other services on the
>>>> 'net) will roll v6 because of the performance increase as v6 will not
>>>> have
>>>> to traverse all this NAT and be subject to session limits, timeouts and
>>>> such.
>>>>>
>>>>
>>>> What do you mean by performance increase? If performance equals
>>>> latency, v4
>>>> will win for a long while still. Cgn does not add measurable latency.
>>>>
>>>> Cb
>>>>> --
>>>>> Leigh
>>>>>
>>>>>
>>>>> ______________________________________________________________________
>>>>> This email has been scanned by the MessageLabs Email Security System.
>>>>> For more information please visit http://www.messagelabs.com/email
>>>>> ______________________________________________________________________
>>>>>
>>>
>>>
>>
>>
>




From mehmet at akcin.net  Thu Sep  8 19:31:20 2011
From: mehmet at akcin.net (Mehmet Akcin)
Date: Thu, 8 Sep 2011 17:31:20 -0700
Subject: NANOG Orange County crew
Message-ID: <304E2146-75E8-4294-9016-866473545829@akcin.net>

Hello,

I noticed i am not the only NANOG'er in Orange County, CA as I have always thought :)

if you live in the area and interested in having a beer / lunch / dinner some time to discuss networks , gear and stuff. 

ping me off-list

mehmet


From goldbe at cs.bu.edu  Thu Sep  8 20:22:09 2011
From: goldbe at cs.bu.edu (Sharon Goldberg)
Date: Thu, 8 Sep 2011 21:22:09 -0400
Subject: Routing policies study [was: Preferring peers over customers]
Message-ID: <CAJHGrrSg-FU1cS6MJss+6XmTfzs1Ni6xgzpJavDzbTOFP0uQEA@mail.gmail.com>

Hi NANOG,

Based on recent discussions (of our paper and other topics) on this
list, it seems like research on interdomain routing could really
benefit from a better understanding of current routing policies. But
we researchers need your help here.  So, we created a short survey:

http://www.cs.toronto.edu/~phillipa/measurement/opsurvey/survey.php

We'll keep the survey data anonymous, and use it to improve research
on interdomain routing and security. We'll also post aggregated
results to the NANOG list.

We'd appreciate if you could take 5 minutes to complete our survey;
feel free to answer all of our questions, or just a few.

Thanks!

Phillipa Gill, Sharon Goldberg & Michael Schapira



From hutuworm at gmail.com  Thu Sep  8 21:05:58 2011
From: hutuworm at gmail.com (hutuworm)
Date: Fri, 9 Sep 2011 10:05:58 +0800
Subject: kernel.org dns broken
In-Reply-To: <4E6950D6.1050601@lcrcomputer.net>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
 <CAG9TQPmjLob6p4Tx-GAvK--r3qtJZyKxBvo=29amkoV5BNSsVw@mail.gmail.com>
 <4E6950D6.1050601@lcrcomputer.net>
Message-ID: <CAP+XwS8Yh=__pJnZ93GnPtSo4iR-jHGe0yHg+c8ksDE7ckW3yA@mail.gmail.com>

fatal: Unable to look up git.kernel.org (port 9418) (Name or service not
known)

# dig @8.8.8.8 git.kernel.org

; <<>> DiG 9.7.3-RedHat-9.7.3-2.el6 <<>> @8.8.8.8 git.kernel.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5492
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;git.kernel.org.                        IN      A

;; AUTHORITY SECTION:
kernel.org.             1407    IN      SOA     ns7.kernel.org.
hostmaster.ns7.kernel.org. 20110908 3600 600 604800 3600

;; Query time: 83 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep  9 18:03:02 2011
;; MSG SIZE  rcvd: 83


On Fri, Sep 9, 2011 at 7:33 AM, Lyle Giese <lyle at lcrcomputer.net> wrote:

> On 09/08/11 17:51, Tony McCrory wrote:
>
>> On 8 September 2011 23:44, Atticus<grobe0ba at gmail.com>  wrote:
>>
>>> I can't resolve anything for kernel.org from Verizon's 3G network, or
>>> from
>>> HE in California. I'm using HE's nameservers, with Google's as a backup.
>>> Neither of them have any records. Anyone know what's up?
>>>
>>
>> Strange one.
>>
>> Also fails with my ISP (BE*There in the UK), but, org. nameservers have it
>> fine:
>>
>> $ dig kernel.org @c0.org.afilias-nst.info.
>>
>> ;<<>>  DiG 9.6.-ESV-R3<<>>  kernel.org @c0.org.afilias-nst.info.
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32885
>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
>> ;; WARNING: recursion requested but not available
>>
>> ;; QUESTION SECTION:
>> ;kernel.org.                    IN      A
>>
>> ;; AUTHORITY SECTION:
>> kernel.org.             86400   IN      NS      ns.vger.kernel.org.
>> kernel.org.             86400   IN      NS      ns4.kernel.org.
>>
>> ;; ADDITIONAL SECTION:
>> ns.vger.kernel.org.     86400   IN      A       209.132.180.67
>> ns4.kernel.org.         86400   IN      A       130.239.17.16
>> ns4.kernel.org.         86400   IN      AAAA    2001:6b0:e:4017::1:1
>>
>> ;; Query time: 40 msec
>> ;; SERVER: 199.19.53.1#53(199.19.53.1)
>> ;; WHEN: Thu Sep  8 22:46:33 2011
>> ;; MSG SIZE  rcvd: 138
>>
>>
> From here (near Chicago), ns.vger.kernel.org is reporting that
> ns7.kernel.org and ns.vger.kernel.org are the authorative servers for
> kernel.org.  But the .org roots are claiming ns.vger.kernel.org and
> ns4.kernel.org are the authorative servers to use.
>
> ns4.kernel.org is not accessable from here via IPv4 or IPv6.
>
> ns7.kernel.org seems to be giving out sensible answers.
>
> That will cause strange issues across the Internet until the roots match
> what ns.vger.kernel.org shows or ns4.kernel.org comes back online.
>
> Lyle Giese
> LCR Computer Services, Inc.
>
>


From carlosm3011 at gmail.com  Thu Sep  8 23:08:50 2011
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Fri, 9 Sep 2011 01:08:50 -0300
Subject: NAT444 or ?
In-Reply-To: <CAAAas8EbN1P50=cOEOTwFYesUodtp=XYk0HzfmmjGOiYTqwwUQ@mail.gmail.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <4E67D24F.10706@otd.com>
 <D181DDABABE57E4DB72FEE00331478643BADD2@EALPO1.ukbroadband.com>
 <CAAAas8EbN1P50=cOEOTwFYesUodtp=XYk0HzfmmjGOiYTqwwUQ@mail.gmail.com>
Message-ID: <CA+z-_EUwC+Q3qikS2673vFeeduO2MXyxjDgHdxLYtXEOXzT3hw@mail.gmail.com>

When you need to pile up this amount of trickery to make something
work,  it's probably high time for letting the thing die :-)

Warm regards

Carlos

On Thu, Sep 8, 2011 at 8:33 AM, Mike Jones <mike at mikejones.in> wrote:
> As HTTP seems to be a major factor causing a lot of short lived
> connections, and several large ISPs have demonstrated that large scale
> transparent HTTP proxies seem to work just fine, you could also move
> the IPv4 port 80 traffic from the CGN to a transparent HTTP proxy. As
> well as any benefits from caching keeping connections local it can
> also combine 1000 users trying to load facebook in to a handful of
> persistent connections to the facebook servers. The proxy can of
> course also have its own global IPv4 address rather than going through
> the NAT, I have no experience with large scale HTTP proxy deployments
> but I strongly suspect a single HTTP proxy can handle traffic for a
> lot more users than low hundreds currently being suggested for NAT444!
> and can be scaled out separately if required.
>
> As an end user this is probably a little worse with HTTP coming from a
> different IP address to everything else, but not that much worse. As a
> provider it may be much easier to scale to larger numbers of
> customers. The proxy can also take IPv4-only users to a dual stacked
> site over IPv6, as I am under no illusions that even with IPv6 to
> every customer you will still have customers behind IPv4-only NAT
> routers they bought themselves for quite a while. With some DNS tricks
> this might be useful for those users reaching IPv6-only sites, however
> it would probably be better if they were unable to reach those sites
> at all to give them an incentive to fix their IPv6.
>
> On 7 September 2011 21:37, Leigh Porter <leigh.porter at ukbroadband.com> wrote:
>> Other simple tricks such as ensuring that your own internal services such as DNS are available without traversing NAT also help.
>
> As obvious as this probably is, i'm sure someone will overlook it!
> Also other services such as providers with CDN nodes in their network
> may want to talk to the CDN operator about having those connected to
> directly from the internal addresses to avoid traversing the NAT, and
> I'm sure there are other services as well.
>
> - Mike
>
>



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================



From mtinka at globaltransit.net  Fri Sep  9 00:04:39 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 9 Sep 2011 13:04:39 +0800
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: <4E60E717.5050406@gmail.com>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
 <4E60E717.5050406@gmail.com>
Message-ID: <201109091304.42712.mtinka@globaltransit.net>

On Friday, September 02, 2011 10:24:23 PM Jesse McGraw 
wrote:

>    I've recently run into a hard-to-troubleshoot issue
> where, somewhere out in the greater Internet, someone
> was silently dropping packets from my company that
> happened to be marked with DSCP AF21.  I'd fully expect
> others to either ignore these markings or zero them out
> but just silently dropping them seems unnecessary.

This is broken.

They likely aren't remarking their Internet traffic 
appropriately to avoid having to schedule it internally, and 
thus, perform some kind of action on it per their QoS 
strategy.

You may consider remarking your traffic one egress to the 
Internet to 0 (safe bet?), but this may be a platform-
specific capability, and can't tell you for sure it will 
work; needless to say, you might not want to do this anyway 
:-).

> So, how do you guys treat marked packets that come
> into/through your networks?

We generally remark all ingress IP Transit traffic to 0, 
both for v4 and v6. This includes traffic from IP Transit 
customers. In general terms, trying to provide QoS 
scheduling services to Internet traffic is fairly 
cumbersome.

There are special cases where Internet traffic could be 
marked to a non-0 value, but these would be controlled 
situations for interesting business opportunities.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110909/52572fc2/attachment.bin>

From mtinka at globaltransit.net  Fri Sep  9 00:10:00 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 9 Sep 2011 13:10:00 +0800
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: <20110902144817.GA23688@pob.ytti.fi>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <4E60E717.5050406@gmail.com> <20110902144817.GA23688@pob.ytti.fi>
Message-ID: <201109091310.01128.mtinka@globaltransit.net>

On Friday, September 02, 2011 10:48:17 PM Saku Ytti wrote:

> Seems in this instance someone has deployed QoS and is
> trusting markings from Internet, which is just broken,
> as they cannot anymore guarantee that customer
> video/voice etc works during congestion, so the QoS
> product is broken.

Despite that, one may be able to correctly schedule a 
particular type of traffic as it comes in from their 
customer bound for the Internet. However, the reverse is 
normally not very true or easy to implement, unless one is 
willing to go through the hassle of correctly identifying 
the exact traffic type for their customer that's making its 
away back, at all points of entry.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110909/71cf9525/attachment.bin>

From mtinka at globaltransit.net  Fri Sep  9 00:12:49 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 9 Sep 2011 13:12:49 +0800
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: <A92EB23D9E64824189C99C5ABF833104197EA51D@mbx024-e1-nj-2.exch024.domain.local>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <4E60E717.5050406@gmail.com>
 <A92EB23D9E64824189C99C5ABF833104197EA51D@mbx024-e1-nj-2.exch024.domain.local>
Message-ID: <201109091312.50071.mtinka@globaltransit.net>

On Friday, September 02, 2011 10:49:32 PM Jeff Saxe wrote:

> Seriously, I would expect that most public Internet
> carriers, unless you paid them extra fees to pay
> attention to the DSCP markings, would completely ignore
> them and treat it all as best-effort traffic, right up
> to and including the last-mile circuit that should be
> the congestion point at which QoS would be most useful
> to differentiate. I don't think it would be the stated
> policy of any public ISP to drop other-than-zero-marked
> packets, especially if it's a transit somewhere that's
> out of reach of either you or the other customer you're
> trying to reach.

I think that DSCP 0 is safest for Internet traffic. As such, 
if a network is going to deploy QoS, they would do well to 
implement this safety net for Internet traffic so that said 
traffic doesn't fall victim to restrictive policies of non-0 
DSCP strategies, or just as equally, doesn't get scheduled 
with a better advantage than is necessary, as that would 
cost money.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110909/458aae08/attachment.bin>

From mtinka at globaltransit.net  Fri Sep  9 00:16:18 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 9 Sep 2011 13:16:18 +0800
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: <6403.1314979323@turing-police.cc.vt.edu>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <20110902144817.GA23688@pob.ytti.fi>
 <6403.1314979323@turing-police.cc.vt.edu>
Message-ID: <201109091316.18540.mtinka@globaltransit.net>

On Saturday, September 03, 2011 12:02:03 AM 
Valdis.Kletnieks at vt.edu wrote:

> Except you can't actually *guarantee* that QoS works
> every packet, every time, during congestion even within
> the same network. Remember - QoS is just a marking to
> shoot the other guy first.  If a link ends up
> overcommitted with QoS traffic, you're still screwed. 
> And there's a second-order effect as well - if your net
> is running sufficiently close to the capacity edge that
> QoS actually matters, there's probably other engineering
> deficiencies that are just waiting to screw you up.

Agree.

What we've seen (and I suppose what the design philosophy 
suggests) is that so-called Priority traffic has the highest 
chance of survival during times of evil. But then again, 
depending on just how saturated the port queues are, even 
Priority traffic can get dropped due to lack of buffers - 
that is if it hasn't already been caught by policers that 
tend to go along with Priority queues.

> Is the story I've heard about people managing to saturate
> a link with QoS'ed traffic, and then having the link
> drop because network management traffic was basically
> DoS'ed, apocryphal, or have people shot themselves in
> the foot that way?

This sounds like a hacked attempt to get management to 
approve that 40Gbps upgrade :-).

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110909/aad0143e/attachment.bin>

From rdobbins at arbor.net  Fri Sep  9 00:33:24 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Fri, 9 Sep 2011 05:33:24 +0000
Subject: Silently dropping QoS marked packets on the greater Internet
In-Reply-To: <201109091312.50071.mtinka@globaltransit.net>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <4E60E717.5050406@gmail.com>
 <A92EB23D9E64824189C99C5ABF833104197EA51D@mbx024-e1-nj-2.exch024.domain.local>
 <201109091312.50071.mtinka@globaltransit.net>
Message-ID: <AD273038-ED92-41EC-B14D-95EBF4FE9413@arbor.net>

On Sep 9, 2011, at 12:12 PM, Mark Tinka wrote:

> I think that DSCP 0 is safest for Internet traffic.

One should certainly always re-mark any Priority 6/Priority 7 data-plane traffic at one's edges, that's pretty much a given.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From caldcv at gmail.com  Fri Sep  9 02:25:42 2011
From: caldcv at gmail.com (Chris)
Date: Fri, 9 Sep 2011 03:25:42 -0400
Subject: kernel.org dns broken
In-Reply-To: <CAP+XwS8Yh=__pJnZ93GnPtSo4iR-jHGe0yHg+c8ksDE7ckW3yA@mail.gmail.com>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
 <CAG9TQPmjLob6p4Tx-GAvK--r3qtJZyKxBvo=29amkoV5BNSsVw@mail.gmail.com>
 <4E6950D6.1050601@lcrcomputer.net>
 <CAP+XwS8Yh=__pJnZ93GnPtSo4iR-jHGe0yHg+c8ksDE7ckW3yA@mail.gmail.com>
Message-ID: <CAPF5ageTnohEoPptcfqp6+Fhv6KQ-eHpLU6k-71_ObVwhhwbqA@mail.gmail.com>

I thought kernel.org was moving to github after that compromise...



From leigh.porter at ukbroadband.com  Fri Sep  9 02:37:06 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 9 Sep 2011 07:37:06 +0000
Subject: NAT444 or ?
In-Reply-To: <CA+z-_EUwC+Q3qikS2673vFeeduO2MXyxjDgHdxLYtXEOXzT3hw@mail.gmail.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl> <4E67D24F.10706@otd.com>
 <D181DDABABE57E4DB72FEE00331478643BADD2@EALPO1.ukbroadband.com>
 <CAAAas8EbN1P50=cOEOTwFYesUodtp=XYk0HzfmmjGOiYTqwwUQ@mail.gmail.com>
 <CA+z-_EUwC+Q3qikS2673vFeeduO2MXyxjDgHdxLYtXEOXzT3hw@mail.gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BCB14@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Carlos Martinez-Cagnazzo [mailto:carlosm3011 at gmail.com]
> Sent: 09 September 2011 05:10
> To: Mike Jones
> Cc: nanog at nanog.org
> Subject: Re: NAT444 or ?
> 
> When you need to pile up this amount of trickery to make something
> work,  it's probably high time for letting the thing die :-)
> 
> Warm regards
> 
> Carlos

You could say the same thing about NAT44 from the very start!

IPv4 just needs to die sooner rather than later. For now though, there is a good many years of trickery left ;-)

--
Leigh Porter


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From ckeladis at gmail.com  Fri Sep  9 03:25:25 2011
From: ckeladis at gmail.com (Chris Keladis)
Date: Fri, 9 Sep 2011 18:25:25 +1000
Subject: kernel.org dns broken
In-Reply-To: <CAPF5ageTnohEoPptcfqp6+Fhv6KQ-eHpLU6k-71_ObVwhhwbqA@mail.gmail.com>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
 <CAG9TQPmjLob6p4Tx-GAvK--r3qtJZyKxBvo=29amkoV5BNSsVw@mail.gmail.com>
 <4E6950D6.1050601@lcrcomputer.net>
 <CAP+XwS8Yh=__pJnZ93GnPtSo4iR-jHGe0yHg+c8ksDE7ckW3yA@mail.gmail.com>
 <CAPF5ageTnohEoPptcfqp6+Fhv6KQ-eHpLU6k-71_ObVwhhwbqA@mail.gmail.com>
Message-ID: <CAE7GeSDcZ6ivyeDsTWZgnifp_W_+7F7PQHcdDY0eJBF7prVtog@mail.gmail.com>

On Fri, Sep 9, 2011 at 5:25 PM, Chris <caldcv at gmail.com> wrote:

> I thought kernel.org was moving to github after that compromise...

Yep, maybe it's related to that activity?


Chris.



From randy at psg.com  Fri Sep  9 03:44:13 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 09 Sep 2011 10:44:13 +0200
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BCB14@EALPO1.ukbroadband.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <4E67D24F.10706@otd.com>
 <D181DDABABE57E4DB72FEE00331478643BADD2@EALPO1.ukbroadband.com>
 <CAAAas8EbN1P50=cOEOTwFYesUodtp=XYk0HzfmmjGOiYTqwwUQ@mail.gmail.com>
 <CA+z-_EUwC+Q3qikS2673vFeeduO2MXyxjDgHdxLYtXEOXzT3hw@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BCB14@EALPO1.ukbroadband.com>
Message-ID: <m2ipp2w1eq.wl%randy@psg.com>

>> When you need to pile up this amount of trickery to make something
>> work,  it's probably high time for letting the thing die :-)
> You could say the same thing about NAT44 from the very start!

many of us did

randy



From jcurran at arin.net  Fri Sep  9 06:36:53 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 9 Sep 2011 11:36:53 +0000
Subject: 2011 ARIN Election process is underway!
Message-ID: <68B99863-2C6E-462B-8641-76FA3670CE4D@corp.arin.net>

Folks - 
 
   Elections for two positions on the ARIN Board of Trustees and for five
   ARIN Advisory Council members are now underway.   The biographies 
   of the candidates are available online, as well as the ability to post 
   online statements of support for candidates.  For more information, 
   please visit: <https://www.arin.net/app/election/>

   The ARIN Advisory Council is instrumental in number resource policy
   development in the region, and the ARIN Board of Trustees provides
   ongoing leadership to the organization in shaping its mission and goals.
   
   I encourage everyone to take a moment and consider the slate of 
   candidates for both of these important elections.  Voting will open
   during the Joint NANOG/ARIN meeting in Philly on October 12th.

FYI (& thanks!)
/John

John Curran
President and CEO
ARIN




From Grzegorz at Janoszka.pl  Fri Sep  9 07:41:40 2011
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Fri, 09 Sep 2011 14:41:40 +0200
Subject: Another internet depeering?
Message-ID: <4E6A0984.60307@Janoszka.pl>


Telia (AS1299) stopped announce some prefixes to us, ie 83.8.0.0/13. Is
it another internet depeering? Do you also see it?

-- 
Grzegorz Janoszka



From nanog-post at rsuc.gweep.net  Fri Sep  9 08:22:04 2011
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Fri, 9 Sep 2011 09:22:04 -0400
Subject: Another internet depeering?
In-Reply-To: <4E6A0984.60307@Janoszka.pl>
References: <4E6A0984.60307@Janoszka.pl>
Message-ID: <20110909132203.GA90662@gweep.net>

On Fri, Sep 09, 2011 at 02:41:40PM +0200, Grzegorz Janoszka wrote:
> 
> Telia (AS1299) stopped announce some prefixes to us, ie 83.8.0.0/13. Is
> it another internet depeering? Do you also see it?
 
"There are more routing policies on the Internet, Horatio, 
 Than are dreamt of in your philosophy."

I suggest examining the communities attached to the prefixes in
question. Route-views, RIPE ris, L3 LG and others in one hand,
Charlie & team's community summary page in the other
(http://http://onesc.net/communities/).


-- 
         RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG



From toddunder at gmail.com  Fri Sep  9 08:26:58 2011
From: toddunder at gmail.com (Todd Underwood)
Date: Fri, 9 Sep 2011 09:26:58 -0400
Subject: RIPE call for presentations
Message-ID: <CAB2RJyjSs8sY6iKpKg-r_5F5BR=-5qiidBtSzBu86SDernoUDA@mail.gmail.com>

Hello,

The following announcement from the RIPE Programme Committee is
probably of interest to the nanog audience.  As most of you know, RIPE
is the European analog to NANOG+ARIN and holds twice-yearly meetings
with presentations and working groups on the subject of network
engineering, operations and policy.

If you have an interesting idea for a presentation and would like to
discuss it with a member of the programme committee you can mail me or
pc at ripe.net.

cheers,

t

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

Dear colleagues,

RIPE 63 takes place on 31 October - 4 November 2011 in Vienna, Austria.

The RIPE Programme Committee is now seeking content proposals from the
RIPE community for the Plenary, BoF and tutorial sessions at RIPE 63
covering subjects including but not limited to:

  * IPv6 deployment
  * Data centre technologies
  * Network and DNS operations
  * Internet governance and regulatory practices
  * Network and routing security
  * Content delivery
  * Internet peering and mobile data exchange

Submissions
------------
Content proposals must be submitted for full consideration no later than
*18 September* using the online topic submission system at:
http://meetings.ripe.net/pc/

If you have any questions or requests concerning content submissions,
please email <pc at ripe.net>.

For more information about RIPE 63, including how to register, visit:
http://ripe63.ripe.net/

Kind regards,

The RIPE Programme Committee



From gary.buhrmaster at gmail.com  Fri Sep  9 09:07:02 2011
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 9 Sep 2011 14:07:02 +0000
Subject: kernel.org dns broken
In-Reply-To: <CAPF5ageTnohEoPptcfqp6+Fhv6KQ-eHpLU6k-71_ObVwhhwbqA@mail.gmail.com>
References: <CAJiDx7n+g1=Cw1PneQynv24R7FXu7HqUUWjSgxFcRhzT89empA@mail.gmail.com>
 <CAG9TQPmjLob6p4Tx-GAvK--r3qtJZyKxBvo=29amkoV5BNSsVw@mail.gmail.com>
 <4E6950D6.1050601@lcrcomputer.net>
 <CAP+XwS8Yh=__pJnZ93GnPtSo4iR-jHGe0yHg+c8ksDE7ckW3yA@mail.gmail.com>
 <CAPF5ageTnohEoPptcfqp6+Fhv6KQ-eHpLU6k-71_ObVwhhwbqA@mail.gmail.com>
Message-ID: <CAMfXtQxx82e+TN-mvUJp1rrJrjCFN9aKuDWoQj89OSG0smBj4w@mail.gmail.com>

On Fri, Sep 9, 2011 at 07:25, Chris <caldcv at gmail.com> wrote:
> I thought kernel.org was moving to github after that compromise...

The location of the Linus tree to github is temporary.  Linus
has stated that when the kernel.org infrastructure is rebuilt
he will move back, and github will simply be a mirror.

  http://article.gmane.org/gmane.linux.kernel/1187922

The move to github was a pragmatic decision, but its
use in the general case does raise some additional
concerns/issues which were mentioned in the announcement.

  https://lkml.org/lkml/2011/9/4/92


Gary



From Jean-Francois.TremblayING at videotron.com  Fri Sep  9 10:09:38 2011
From: Jean-Francois.TremblayING at videotron.com (Jean-Francois.TremblayING at videotron.com)
Date: Fri, 9 Sep 2011 11:09:38 -0400
Subject: CGN and CDN (was Re: what about the users re: NAT444 or ?)
In-Reply-To: <4E695203.50009@lcrcomputer.net>
Message-ID: <OF6F720EEF.5A0A7F90-ON85257906.00515568-85257906.005347E0@videotron.com>

> And these 'perceived' routing issues won't be noticed nor are they 
> important to CDN's?
> I know what my job is, but that may not matter to the CDN's.  Reading 
> this thread, I wanted to mention another problem that I feel has an 
> effect on this issue.
> Lyle

A very interesting point. In order to save precious CGN resources, 
it would not be surprising to see some ISPs asking CDNs to provide 
a private/non-routed behind-CGN leg for local CDN nodes. 

For this to work, the CGN users would probably have a different 
set of DNS servers (arguably also with a private/non-routed
leg) or some other way to differentiate these CGN clients. Lots 
of fun in the future debugging that. 

/JF



From Valdis.Kletnieks at vt.edu  Fri Sep  9 10:25:35 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 09 Sep 2011 11:25:35 -0400
Subject: CGN and CDN (was Re: what about the users re: NAT444 or ?)
In-Reply-To: Your message of "Fri, 09 Sep 2011 11:09:38 EDT."
 <OF6F720EEF.5A0A7F90-ON85257906.00515568-85257906.005347E0@videotron.com>
References: <OF6F720EEF.5A0A7F90-ON85257906.00515568-85257906.005347E0@videotron.com>
Message-ID: <31013.1315581935@turing-police.cc.vt.edu>

On Fri, 09 Sep 2011 11:09:38 EDT, Jean-Francois.TremblayING at videotron.com said:

> A very interesting point. In order to save precious CGN resources, 
> it would not be surprising to see some ISPs asking CDNs to provide 
> a private/non-routed behind-CGN leg for local CDN nodes. 
> 
> For this to work, the CGN users would probably have a different 
> set of DNS servers (arguably also with a private/non-routed
> leg) or some other way to differentiate these CGN clients. Lots 
> of fun in the future debugging that.

Especially once you have 10 or 15 CDNs doing this, all of which have different
rules of engagement. "Akamai requires us to do X, Hulu wants Y, Foobar wants Y
and specifically NOT-X..." ;)

And then Cogent will get into another peering spat and.... :)


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

From a.harrowell at gmail.com  Fri Sep  9 11:06:37 2011
From: a.harrowell at gmail.com (Alexander Harrowell)
Date: Fri, 9 Sep 2011 17:06:37 +0100
Subject: CGN and CDN (was Re: what about the users re: NAT444 or ?)
In-Reply-To: <31013.1315581935@turing-police.cc.vt.edu>
References: <OF6F720EEF.5A0A7F90-ON85257906.00515568-85257906.005347E0@videotron.com>
 <31013.1315581935@turing-police.cc.vt.edu>
Message-ID: <201109091706.54379.a.harrowell@gmail.com>

On Friday 09 Sep 2011 16:25:35 Valdis.Kletnieks at vt.edu wrote:
> On Fri, 09 Sep 2011 11:09:38 EDT, Jean-
Francois.TremblayING at videotron.com said:
> 
> > A very interesting point. In order to save precious CGN resources, 
> > it would not be surprising to see some ISPs asking CDNs to provide 
> > a private/non-routed behind-CGN leg for local CDN nodes. 
> > 

The actual problem here is that everyone assumes it'll be donkey's years 
before every last web server in the world is on IPv6.

If you're a CDN, though, you can solve this problem for your own network 
right now by deploying IPv6! Akamai says that you need 650 AS to cover 
90% of Internet traffic. I propose that effort getting content networks 
to go dual stack is better used than effort used to work around NAT444.

Further, if making your hosting network IPv6 is hard, the answer is 
surely to give the job to a CDN operator with v6 clue. I actually rather 
think CDNs are an important way of getting content onto the IPv6 
Internet.

In my view CDNing (and its sister, application acceleration) is so 
important to delivering the heavy video and complex web apps that 
dominate the modern Internet that this should be a killer. 

Still, breaking the BBC, Hulu, Level(3), Akamai, Limelight, and Google's 
video services will probably reduce your transit and backhaul bills 
significantly. Can't say it'll help with customer retention.


> > For this to work, the CGN users would probably have a different 
> > set of DNS servers (arguably also with a private/non-routed
> > leg) or some other way to differentiate these CGN clients. Lots 
> > of fun in the future debugging that.
> 
> Especially once you have 10 or 15 CDNs doing this, all of which have 
different
> rules of engagement. "Akamai requires us to do X, Hulu wants Y, Foobar 
wants Y
> and specifically NOT-X..." ;)
> 
> And then Cogent will get into another peering spat and.... :)
> 
> 
> 

-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110909/c0452861/attachment.bin>

From cdel at firsthand.net  Fri Sep  9 11:57:22 2011
From: cdel at firsthand.net (Christian de Larrinaga)
Date: Fri, 9 Sep 2011 17:57:22 +0100
Subject: CGN and CDN (was Re: what about the users re: NAT444 or ?)
In-Reply-To: <201109091706.54379.a.harrowell@gmail.com>
References: <OF6F720EEF.5A0A7F90-ON85257906.00515568-85257906.005347E0@videotron.com>
 <31013.1315581935@turing-police.cc.vt.edu>
 <201109091706.54379.a.harrowell@gmail.com>
Message-ID: <B563A3F3-6A5F-4143-A2FF-F3600F48727C@firsthand.net>

I can predict the response from the teen dens of the world! 
What does CGN mean .. Can't Get Nothing! 


Christian





On 9 Sep 2011, at 17:06, Alexander Harrowell wrote:

> On Friday 09 Sep 2011 16:25:35 Valdis.Kletnieks at vt.edu wrote:
>> On Fri, 09 Sep 2011 11:09:38 EDT, Jean-
> Francois.TremblayING at videotron.com said:
>> 
>>> A very interesting point. In order to save precious CGN resources, 
>>> it would not be surprising to see some ISPs asking CDNs to provide 
>>> a private/non-routed behind-CGN leg for local CDN nodes. 
>>> 
> 
> The actual problem here is that everyone assumes it'll be donkey's years 
> before every last web server in the world is on IPv6.
> 
> If you're a CDN, though, you can solve this problem for your own network 
> right now by deploying IPv6! Akamai says that you need 650 AS to cover 
> 90% of Internet traffic. I propose that effort getting content networks 
> to go dual stack is better used than effort used to work around NAT444.
> 
> Further, if making your hosting network IPv6 is hard, the answer is 
> surely to give the job to a CDN operator with v6 clue. I actually rather 
> think CDNs are an important way of getting content onto the IPv6 
> Internet.
> 
> In my view CDNing (and its sister, application acceleration) is so 
> important to delivering the heavy video and complex web apps that 
> dominate the modern Internet that this should be a killer. 
> 
> Still, breaking the BBC, Hulu, Level(3), Akamai, Limelight, and Google's 
> video services will probably reduce your transit and backhaul bills 
> significantly. Can't say it'll help with customer retention.
> 
> 
>>> For this to work, the CGN users would probably have a different 
>>> set of DNS servers (arguably also with a private/non-routed
>>> leg) or some other way to differentiate these CGN clients. Lots 
>>> of fun in the future debugging that.
>> 
>> Especially once you have 10 or 15 CDNs doing this, all of which have 
> different
>> rules of engagement. "Akamai requires us to do X, Hulu wants Y, Foobar 
> wants Y
>> and specifically NOT-X..." ;)
>> 
>> And then Cogent will get into another peering spat and.... :)
>> 
>> 
>> 
> 
> -- 
> The only thing worse than e-mail disclaimers...is people who send e-mail 
> to lists complaining about them




From rdobbins at arbor.net  Fri Sep  9 12:04:59 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Fri, 9 Sep 2011 17:04:59 +0000
Subject: CGN and CDN (was Re: what about the users re: NAT444 or ?)
In-Reply-To: <201109091706.54379.a.harrowell@gmail.com>
References: <OF6F720EEF.5A0A7F90-ON85257906.00515568-85257906.005347E0@videotron.com>
 <31013.1315581935@turing-police.cc.vt.edu>
 <201109091706.54379.a.harrowell@gmail.com>
Message-ID: <2835A1EE-6942-49E5-A006-92AAE1FDCB8F@arbor.net>

On Sep 9, 2011, at 11:06 PM, Alexander Harrowell wrote:

> Further, if making your hosting network IPv6 is hard, the answer is surely to give the job to a CDN operator with v6 clue.

This is a good strategy for payload-type content from unitary sources which lends itself to caching/redistribution; however, Web applications, things which link to/incorporate lots of content, etc. under the control of other organization, and 'active content' are another story, unfortunately.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From oscarcaraig at Safe-mail.net  Fri Sep  9 12:27:38 2011
From: oscarcaraig at Safe-mail.net (Oscar Caraig)
Date: Fri, 9 Sep 2011 13:27:38 -0400
Subject: Pricing for Comcast Connectivity
Message-ID: <N1B-AdILglIUVU@Safe-mail.net>

List,

Does anyone have sample pricing for Comcast's Paid Peering (http://www.comcast.com/dedicatedinternet/) service they'd be able to share?

Also, are there any transit ISPs to avoid when reaching Comcast?  I remember discussion last winter about Tata being congested, and would like to understand how common these issues are.  I'm preparing to launch a large video broadcast for the state, so any advice would be appreciated.

Thank you,
Oscar Caraig



From cdel at firsthand.net  Fri Sep  9 12:27:50 2011
From: cdel at firsthand.net (Christian de Larrinaga)
Date: Fri, 9 Sep 2011 18:27:50 +0100
Subject: what about the users re: NAT444 or ?
In-Reply-To: <028401cc6e47$a3faae70$ebf00b50$@com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
 <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
 <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
 <028401cc6e47$a3faae70$ebf00b50$@com>
Message-ID: <80E55462-0AB9-453A-B376-E2FF94517A87@firsthand.net>

exactly. don't plan to deploy what breaks things for the user edge. 

there are two issues here 

1/ what ISPs do that might break things at the edge

2/ what edge stuff is doing that will break things at the other end edge of a connection


It seems a bit odd that ISPs would actively plot to do 1/ whilst they could be making hard cash helping people at the edge avoid 2/

Odd because it adds a 3/ element which is stuff at the edge which will break stuff in the network. Do (some) operators see more money in a 1/2/3/ world?



Christian
On 8 Sep 2011, at 17:52, Dan Wing wrote:

>> Is there not a bit of CPE needed here? What should the CPE do? and not
>> do? should it deprecate NAT/PAT when it receives 1918 allocation from a
>> CGN?
> 
> Careful with that idea -- people like their in-home network to continue
> functioning even when their ISP is down or having an outage.




From jvanoppen at spectrumnet.us  Fri Sep  9 14:01:40 2011
From: jvanoppen at spectrumnet.us (John van Oppen)
Date: Fri, 9 Sep 2011 19:01:40 +0000
Subject: Pricing for Comcast Connectivity
In-Reply-To: <N1B-AdILglIUVU@Safe-mail.net>
References: <N1B-AdILglIUVU@Safe-mail.net>
Message-ID: <AF24AE2D4A4D334FB9B667985E2AE763C1937B@mail1-sea.office.spectrumnet.us>

I think all pricing is under NDA for the direct connectivity...   we have it, and I know it is under NDA for us...

Comcast is in the becoming a tier1 game in a big way so avoiding people who don't already peer with the is probably a plus if you want great connectivity to them.    The AS paths I would avoid are _3356_7922_ (usually fine, but subject to the fight de jour between level3 and Comcast) and anything on _6453_7911_ (subject to being saturated all the time).   Last I checked AS2914 and a few others still only see Comcast via 6453 which made that sub-optimal.


I can send you a AS7922 sales contact if you need it, just hit me up off list...  they also have a good list of info on peeringdb for people to contact.


Thanks,

John van Oppen
Spectrum Networks  AS 11404

-----Original Message-----
From: Oscar Caraig [mailto:oscarcaraig at Safe-mail.net] 
Sent: Friday, September 09, 2011 10:28 AM
To: nanog at nanog.org
Subject: Pricing for Comcast Connectivity

List,

Does anyone have sample pricing for Comcast's Paid Peering (http://www.comcast.com/dedicatedinternet/) service they'd be able to share?

Also, are there any transit ISPs to avoid when reaching Comcast?  I remember discussion last winter about Tata being congested, and would like to understand how common these issues are.  I'm preparing to launch a large video broadcast for the state, so any advice would be appreciated.

Thank you,
Oscar Caraig




From ren.provo at gmail.com  Fri Sep  9 14:11:01 2011
From: ren.provo at gmail.com (Ren Provo)
Date: Fri, 9 Sep 2011 15:11:01 -0400
Subject: Pricing for Comcast Connectivity
In-Reply-To: <AF24AE2D4A4D334FB9B667985E2AE763C1937B@mail1-sea.office.spectrumnet.us>
References: <N1B-AdILglIUVU@Safe-mail.net>
 <AF24AE2D4A4D334FB9B667985E2AE763C1937B@mail1-sea.office.spectrumnet.us>
Message-ID: <CAG5ReHdkyJasbUzy3gAbxWa-bqe-FMAbvQEKMG=15Gt_4G86SQ@mail.gmail.com>

Hi Oscar,

John is right about the NDA.  Feel free to reach out to Steve Lacoff,
as noted at http://www.comcast.com/dedicatedinternet/

Volume, location, term, etc. are all factors to consider.  Steve will
be at NANOG if you, or others have questions.

Cheers, -ren

On Fri, Sep 9, 2011 at 3:01 PM, John van Oppen <jvanoppen at spectrumnet.us> wrote:
> I think all pricing is under NDA for the direct connectivity... ? we have it, and I know it is under NDA for us...
>
> Comcast is in the becoming a tier1 game in a big way so avoiding people who don't already peer with the is probably a plus if you want great connectivity to them. ? ?The AS paths I would avoid are _3356_7922_ (usually fine, but subject to the fight de jour between level3 and Comcast) and anything on _6453_7911_ (subject to being saturated all the time). ? Last I checked AS2914 and a few others still only see Comcast via 6453 which made that sub-optimal.
>
>
> I can send you a AS7922 sales contact if you need it, just hit me up off list... ?they also have a good list of info on peeringdb for people to contact.
>
>
> Thanks,
>
> John van Oppen
> Spectrum Networks ?AS 11404
>
> -----Original Message-----
> From: Oscar Caraig [mailto:oscarcaraig at Safe-mail.net]
> Sent: Friday, September 09, 2011 10:28 AM
> To: nanog at nanog.org
> Subject: Pricing for Comcast Connectivity
>
> List,
>
> Does anyone have sample pricing for Comcast's Paid Peering (http://www.comcast.com/dedicatedinternet/) service they'd be able to share?
>
> Also, are there any transit ISPs to avoid when reaching Comcast? ?I remember discussion last winter about Tata being congested, and would like to understand how common these issues are. ?I'm preparing to launch a large video broadcast for the state, so any advice would be appreciated.
>
> Thank you,
> Oscar Caraig
>
>
>



From cscora at apnic.net  Fri Sep  9 14:11:35 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 10 Sep 2011 05:11:35 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201109091911.p89JBZtg023949@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,
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 10 Sep, 2011

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

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

BGP routing table entries examined:                              370301
    Prefixes after maximum aggregation:                          167415
    Deaggregation factor:                                          2.21
    Unique aggregates announced to Internet:                     183735
Total ASes present in the Internet Routing Table:                 38737
    Prefixes per ASN:                                              9.56
Origin-only ASes present in the Internet Routing Table:           32130
Origin ASes announcing only one prefix:                           15446
Transit ASes present in the Internet Routing Table:                5210
Transit-only ASes present in the Internet Routing Table:            140
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      36
    Max AS path prepend of ASN (22394)                               33
Prefixes from unregistered ASNs in the Routing Table:              1208
    Unregistered ASNs in the Routing Table:                         697
Number of 32-bit ASNs allocated by the RIRs:                       1711
Number of 32-bit ASNs visible in the Routing Table:                1397
Prefixes from 32-bit ASNs in the Routing Table:                    3204
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            101
Number of addresses announced to Internet:                   2475335424
    Equivalent to 147 /8s, 138 /16s and 159 /24s
    Percentage of available address space announced:               66.8
    Percentage of allocated address space announced:               66.8
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               91.2
Total number of prefixes smaller than registry allocations:      154300

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

Prefixes being announced by APNIC Region ASes:                    93207
    Total APNIC prefixes after maximum aggregation:               30608
    APNIC Deaggregation factor:                                    3.05
Prefixes being announced from the APNIC address blocks:           89751
    Unique aggregates announced from the APNIC address blocks:    38014
APNIC Region origin ASes present in the Internet Routing Table:    4545
    APNIC Prefixes per ASN:                                       19.75
APNIC Region origin ASes announcing only one prefix:               1250
APNIC Region transit ASes present in the Internet Routing Table:    709
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         18
Number of APNIC region 32-bit ASNs visible in the Routing Table:     83
Number of APNIC addresses announced to Internet:              626012512
    Equivalent to 37 /8s, 80 /16s and 49 /24s
    Percentage of available APNIC address space announced:         79.4

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
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, 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:                    143092
    Total ARIN prefixes after maximum aggregation:                73464
    ARIN Deaggregation factor:                                     1.95
Prefixes being announced from the ARIN address blocks:           114937
    Unique aggregates announced from the ARIN address blocks:     47325
ARIN Region origin ASes present in the Internet Routing Table:    14645
    ARIN Prefixes per ASN:                                         7.85
ARIN Region origin ASes announcing only one prefix:                5639
ARIN Region transit ASes present in the Internet Routing Table:    1554
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          36
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               804788864
    Equivalent to 47 /8s, 248 /16s and 26 /24s
    Percentage of available ARIN address space announced:          64.0

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, 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, 173/8,
                       174/8, 184/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:                     87865
    Total RIPE prefixes after maximum aggregation:                49993
    RIPE Deaggregation factor:                                     1.76
Prefixes being announced from the RIPE address blocks:            80959
    Unique aggregates announced from the RIPE address blocks:     53843
RIPE Region origin ASes present in the Internet Routing Table:    15959
    RIPE Prefixes per ASN:                                         5.07
RIPE Region origin ASes announcing only one prefix:                7952
RIPE Region transit ASes present in the Internet Routing Table:    2496
Average RIPE Region AS path length visible:                         4.6
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:     993
Number of RIPE addresses announced to Internet:               488762880
    Equivalent to 29 /8s, 33 /16s and 238 /24s
    Percentage of available RIPE address space announced:          78.7

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
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,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   34454
    Total LACNIC prefixes after maximum aggregation:               7761
    LACNIC Deaggregation factor:                                   4.44
Prefixes being announced from the LACNIC address blocks:          33754
    Unique aggregates announced from the LACNIC address blocks:   17669
LACNIC Region origin ASes present in the Internet Routing Table:   1522
    LACNIC Prefixes per ASN:                                      22.18
LACNIC Region origin ASes announcing only one prefix:               452
LACNIC Region transit ASes present in the Internet Routing Table:   275
Average LACNIC Region AS path length visible:                       4.4
    Max LACNIC Region AS path length visible:                        19
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   305
Number of LACNIC addresses announced to Internet:              88542336
    Equivalent to 5 /8s, 71 /16s and 12 /24s
    Percentage of available LACNIC address space announced:        58.6

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8314
    Total AfriNIC prefixes after maximum aggregation:              2024
    AfriNIC Deaggregation factor:                                  4.11
Prefixes being announced from the AfriNIC address blocks:          6408
    Unique aggregates announced from the AfriNIC address blocks:   1991
AfriNIC Region origin ASes present in the Internet Routing Table:   480
    AfriNIC Prefixes per ASN:                                     13.35
AfriNIC Region origin ASes announcing only one prefix:              153
AfriNIC Region transit ASes present in the Internet Routing Table:  104
Average AfriNIC Region AS path length visible:                      4.7
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             27297024
    Equivalent to 1 /8s, 160 /16s and 133 /24s
    Percentage of available AfriNIC address space announced:       40.7

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2508      11047         955   Korea Telecom (KIX)
17974     1985        516          31   PT TELEKOMUNIKASI INDONESIA
 7545     1581        301          83   TPG Internet Pty Ltd
 4755     1550        635         170   TATA Communications formerly 
24560     1176        336         192   Bharti Airtel Ltd., Telemedia
 9829     1152        989          28   BSNL National Internet Backbo
 9583     1079         80         503   Sify Limited
 4808     1077       2093         308   CNCGROUP IP network: China169
 7552     1050       1062          11   Vietel Corporation
17488      982        192         158   Hathway IP Over Cable Interne

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     3564       3817         226   bellsouth.net, inc. 
18566     1912        364         237   Covad Communications 
 1785     1822        680         122   PaeTec Communications, Inc.
 4323     1626       1085         395   Time Warner Telecom
20115     1591       1540         634   Charter Communications 
 7029     1483        995         231   Windstream Communications Inc
22773     1450       2906          99   Cox Communications, Inc.
19262     1394       4724         399   Verizon Global Networks 
 7018     1333       7050         874   AT&T WorldNet Services
30036     1327        244         687   Mediacom Communications Corp 

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
34984      544        107         178   BILISIM TELEKOM
 6830      526       1811         322   UPC Distribution Services
20940      500        154         388   Akamai Technologies European 
 3292      471       2079         405   TDC Tele Danmark
12479      468        594           8   Uni2 Autonomous System
 8866      460        133          26   Bulgarian Telecommunication C
 3320      431       8152         375   Deutsche Telekom AG
29049      424         31          55   AzerSat LLC.
 8402      406        352          13   Corbina telecom
 8551      404        354          44   Bezeq International

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

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1661        305         161   TVCABLE BOGOTA 
 8151     1409       2802         354   UniNet S.A. de C.V. 
28573     1302       1003          71   NET Servicos de Comunicao S.A
 7303     1051        578         166   Telecom Argentina Stet-France
14420      715         57          88   CORPORACION NACIONAL DE TELEC
 6503      582        450          68   AVANTEL, S.A. 
22047      579        322          17   VTR PUNTO NET S.A. 
27947      565         55          82   Telconet S.A
 3816      535        232          98   Empresa Nacional de Telecomun
 7738      515        986          31   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
24863      812        147          43   LINKdotNET AS number
 8452      596        440          15   TEDATA
15475      512         74           8   Nile Online
36992      300        415          14   Etisalat MISR
 3741      267        938         228   The Internet Solution 
 6713      242        519          14   Itissalat Al-MAGHRIB
15706      219         32           6   Sudatel Internet Exchange Aut
33776      204         13          14   Starcomms Nigeria Limited
12258      193         28          62   Vodacom Internet Company 
29571      191         17          11   Ci Telecom Autonomous system 

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
 6389     3564       3817         226   bellsouth.net, inc. 
23456     3204        762        1739   32-bit ASN transition
 4766     2508      11047         955   Korea Telecom (KIX)
17974     1985        516          31   PT TELEKOMUNIKASI INDONESIA
18566     1912        364         237   Covad Communications 
 1785     1822        680         122   PaeTec Communications, Inc.
10620     1661        305         161   TVCABLE BOGOTA 
 4323     1626       1085         395   Time Warner Telecom
20115     1591       1540         634   Charter Communications 
 7545     1581        301          83   TPG Internet Pty Ltd

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

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

  ASN   No of nets  Net Savings Description
17974      1985        1954      PT TELEKOMUNIKASI INDONESIA
 1785      1822        1700      PaeTec Communications, Inc.
18566      1912        1675      Covad Communications 
 4766      2508        1553      Korea Telecom (KIX)
10620      1661        1500      TVCABLE BOGOTA 
 7545      1581        1498      TPG Internet Pty Ltd
23456      3204        1465      32-bit ASN transition
 4755      1550        1380      TATA Communications formerly 
22773      1450        1351      Cox Communications, Inc.
 7029      1483        1252      Windstream Communications Inc

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
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
26973   UNALLOCATED  12.39.152.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.154.0/23        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.155.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.159.0/24        7018       AT&T WorldNet Servic
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic

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

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

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
41.222.79.0/24       36938     >>UNKNOWN<<
41.223.92.0/22       36936     >>UNKNOWN<<
46.18.104.0/21       23456     32-bit ASN transition
62.61.220.0/24       24974     Tachyon Europe BV - Wireless 

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:19       /9:12      /10:27      /11:81      /12:234     
/13:463     /14:798     /15:1411    /16:11956   /17:5953    /18:9998    
/19:19711   /20:26697   /21:26880   /22:35996   /23:34665   /24:192096  
/25:1106    /26:1287    /27:739     /28:163     /29:4       /30:0       
/31:0       /32:5       

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

  ASN   No of nets  Total ann.   Description
 6389     2201          3564      bellsouth.net, inc. 
18566     1868          1912      Covad Communications 
10620     1556          1661      TVCABLE BOGOTA 
23456     1549          3204      32-bit ASN transition
30036     1290          1327      Mediacom Communications Corp 
 7029     1211          1483      Windstream Communications Inc
11492     1110          1156      Cable One 
 7011     1058          1183      Citizens Utilities 
 1785     1052          1822      PaeTec Communications, Inc.
22773      940          1450      Cox Communications, Inc.

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

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

   1:365       2:50        4:15        5:1         6:3         8:349    
  12:1949     13:1        14:523      15:13       16:3        17:5      
  20:10       23:31       24:1669     27:919      31:516      32:64     
  33:3        34:2        36:4        38:737      40:107      41:2430   
  42:40       44:3        46:980      47:3        49:236      50:412    
  52:13       54:2        55:6        56:2        57:34       58:868    
  59:495      60:376      61:1172     62:1085     63:1940     64:4021   
  65:2306     66:3933     67:1933     68:1116     69:3168     70:783    
  71:377      72:1855     74:2432     75:325      76:339      77:870    
  78:667      79:455      80:1108     81:843      82:504      83:491    
  84:686      85:1091     86:412      87:862      88:345      89:1537   
  90:232      91:4073     92:524      93:1129     94:1339     95:799    
  96:424      97:272      98:913      99:37      101:202     103:266    
 106:71      107:43      108:76      109:1015    110:666     111:745    
 112:319     113:439     114:563     115:707     116:911     117:678    
 118:883     119:1199    120:334     121:687     122:1580    123:1006   
 124:1339    125:1353    128:248     129:181     130:166     131:581    
 132:119     133:21      134:215     135:52      136:212     137:134    
 138:293     139:109     140:493     141:289     142:389     143:415    
 144:488     145:61      146:466     147:228     148:635     149:250    
 150:153     151:189     152:444     153:179     154:6       155:393    
 156:201     157:354     158:143     159:456     160:320     161:207    
 162:335     163:174     164:513     165:370     166:536     167:432    
 168:746     169:146     170:844     171:84      172:1       173:1644   
 174:631     175:390     176:167     177:246     178:1007    180:1018   
 181:25      182:608     183:233     184:352     185:1       186:1412   
 187:672     188:940     189:869     190:5141    192:5913    193:5000   
 194:3524    195:3029    196:1231    197:147     198:3590    199:4108   
 200:5511    201:1635    202:8503    203:8514    204:4242    205:2339   
 206:2675    207:2819    208:4009    209:3441    210:2672    211:1465   
 212:2092    213:1762    214:772     215:76      216:4837    217:1598   
 218:549     219:345     220:1226    221:515     222:352     223:259    


End of report



From paul at paulstewart.org  Fri Sep  9 14:14:37 2011
From: paul at paulstewart.org (Paul Stewart)
Date: Fri, 9 Sep 2011 15:14:37 -0400
Subject: Pricing for Comcast Connectivity
In-Reply-To: <AF24AE2D4A4D334FB9B667985E2AE763C1937B@mail1-sea.office.spectrumnet.us>
References: <N1B-AdILglIUVU@Safe-mail.net>
 <AF24AE2D4A4D334FB9B667985E2AE763C1937B@mail1-sea.office.spectrumnet.us>
Message-ID: <030a01cc6f24$b9c939a0$2d5bace0$@org>

Yes, definitely NDA in any of our dealings... I'd say the pricing was
"competitive" for sure...

Paul


-----Original Message-----
From: John van Oppen [mailto:jvanoppen at spectrumnet.us] 
Sent: Friday, September 09, 2011 3:02 PM
To: 'Oscar Caraig'; nanog at nanog.org
Subject: RE: Pricing for Comcast Connectivity

I think all pricing is under NDA for the direct connectivity...   we have
it, and I know it is under NDA for us...

Comcast is in the becoming a tier1 game in a big way so avoiding people who
don't already peer with the is probably a plus if you want great
connectivity to them.    The AS paths I would avoid are _3356_7922_ (usually
fine, but subject to the fight de jour between level3 and Comcast) and
anything on _6453_7911_ (subject to being saturated all the time).   Last I
checked AS2914 and a few others still only see Comcast via 6453 which made
that sub-optimal.


I can send you a AS7922 sales contact if you need it, just hit me up off
list...  they also have a good list of info on peeringdb for people to
contact.


Thanks,

John van Oppen
Spectrum Networks  AS 11404

-----Original Message-----
From: Oscar Caraig [mailto:oscarcaraig at Safe-mail.net] 
Sent: Friday, September 09, 2011 10:28 AM
To: nanog at nanog.org
Subject: Pricing for Comcast Connectivity

List,

Does anyone have sample pricing for Comcast's Paid Peering
(http://www.comcast.com/dedicatedinternet/) service they'd be able to share?

Also, are there any transit ISPs to avoid when reaching Comcast?  I remember
discussion last winter about Tata being congested, and would like to
understand how common these issues are.  I'm preparing to launch a large
video broadcast for the state, so any advice would be appreciated.

Thank you,
Oscar Caraig





From joly at punkcast.com  Fri Sep  9 14:54:43 2011
From: joly at punkcast.com (Joly MacFie)
Date: Fri, 9 Sep 2011 15:54:43 -0400
Subject: Caveat emptor
Message-ID: <CAM9VJk3c0x+ijJRLEdzAVfXeU3NJhchsGQ7MbkA8=mHEAf=RbQ@mail.gmail.com>

Virginia woman sentenced to 5 years in prison for importing and selling
counterfeit Cisco computer equipment

http://content.govdelivery.com/bulletins/gd/USDHSICE-122191



-- 
---------------------------------------------------------------
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 marcus at blazingdot.com  Fri Sep  9 16:48:04 2011
From: marcus at blazingdot.com (Marcus Reid)
Date: Fri, 9 Sep 2011 21:48:04 +0000
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
Message-ID: <20110909214804.GA88934@blazingdot.com>

On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:
> FYI!!!
> 
> http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee
> ms_all_diginotar_certificates_untrust.html
> 
> Google and Mozilla have also updated their browsers to block all DigiNotar
> certificates, while Apple has been silent on the issue, a emblematic zombie
> response!

Apple has sent out a notification saying that they are removing
DigiNotar from their list of trusted root certs.

I like this response; instant CA death penalty seems to put the
incentives about where they need to be.

Marcus



From paul at paulgraydon.co.uk  Fri Sep  9 16:54:24 2011
From: paul at paulgraydon.co.uk (Paul)
Date: Fri, 09 Sep 2011 11:54:24 -1000
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
 updates
In-Reply-To: <20110909214804.GA88934@blazingdot.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
Message-ID: <4E6A8B10.3030607@paulgraydon.co.uk>

On 09/09/2011 11:48 AM, Marcus Reid wrote:
> On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:
>> FYI!!!
>>
>> http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee
>> ms_all_diginotar_certificates_untrust.html
>>
>> Google and Mozilla have also updated their browsers to block all DigiNotar
>> certificates, while Apple has been silent on the issue, a emblematic zombie
>> response!
> Apple has sent out a notification saying that they are removing
> DigiNotar from their list of trusted root certs.
>
> I like this response; instant CA death penalty seems to put the
> incentives about where they need to be.
>
> Marcus
>
Instant?  This has been going on for over a week, and a lot of damage 
could have been done in that time, especially given certs for *.*.com 
were signed against Diginotar.  Most cell phones are unable to update 
their certificates without an upgrade and you know how long it takes to 
get them through Cell Phone carriers.  A number of alternative android 
builds are adding the ability to control accepted root certs to their 
builds in the interest of speeding this up.  The CA system is 
fundamentally flawed.

Paul



From cidr-report at potaroo.net  Fri Sep  9 17:00:01 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 9 Sep 2011 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201109092200.p89M01Tf034178@wattle.apnic.net>

BGP Update Report
Interval: 01-Sep-11 -to- 08-Sep-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS38040           40360  2.3%    4036.0 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 2 - AS6316            30178  1.7%    1312.1 -- AS-PAETEC-NET - PaeTec Communications, Inc.
 3 - AS32528           24952  1.4%    4990.4 -- ABBOTT Abbot Labs
 4 - AS17974           22530  1.3%      12.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
 5 - AS7497            21193  1.2%      70.4 -- CSTNET-AS-AP Computer Network Information Center
 6 - AS9829            20142  1.2%      34.0 -- BSNL-NIB National Internet Backbone
 7 - AS38543           17923  1.0%    3584.6 -- IBM-TH-AS-AP IBM THAILAND NETWORK
 8 - AS9498            16705  1.0%      28.9 -- BBIL-AP BHARTI Airtel Ltd.
 9 - AS47794           13732  0.8%     185.6 -- ATHEEB-AS Etihad Atheeb Telecom Company
10 - AS23700           13087  0.8%     363.5 -- BM-AS-ID PT. Broadband Multimedia, Tbk
11 - AS45899           12611  0.7%       6.5 -- VNPT-AS-VN VNPT Corp
12 - AS16509           12173  0.7%     304.3 -- AMAZON-02 - Amazon.com, Inc.
13 - AS7552            12001  0.7%      11.6 -- VIETEL-AS-AP Vietel Corporation
14 - AS2697            11798  0.7%      60.2 -- ERX-ERNET-AS Education and Research Network
15 - AS56375           10387  0.6%   10387.0 -- IKRF Imam Khomeini Relief Foundation IKRF
16 - AS27738            9596  0.6%      28.1 -- Ecuadortelecom S.A.
17 - AS9299             9433  0.6%       8.1 -- IPG-AS-AP Philippine Long Distance Telephone Company
18 - AS47377            8834  0.5%     384.1 -- MES MOBISTAR ENTERPRISE SERVICES SA
19 - AS8866             8817  0.5%      42.2 -- BTC-AS Bulgarian Telecommunication Company Plc.
20 - AS5800             8457  0.5%      44.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS56375           10387  0.6%   10387.0 -- IKRF Imam Khomeini Relief Foundation IKRF
 2 - AS32528           24952  1.4%    4990.4 -- ABBOTT Abbot Labs
 3 - AS38040           40360  2.3%    4036.0 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 4 - AS38543           17923  1.0%    3584.6 -- IBM-TH-AS-AP IBM THAILAND NETWORK
 5 - AS3976             3552  0.2%    3552.0 -- ERX-NURI-ASN I.Net Technologies Inc.
 6 - AS8011             2869  0.2%    1434.5 -- AS8011 - CoreComm Internet Services Inc
 7 - AS3454             8222  0.5%    1370.3 -- Universidad Autonoma de Nuevo Leon
 8 - AS6316            30178  1.7%    1312.1 -- AS-PAETEC-NET - PaeTec Communications, Inc.
 9 - AS53295            1140  0.1%    1140.0 -- ROVI - Rovi Corporation
10 - AS17408            3335  0.2%    1111.7 -- ABOVE-AS-AP AboveNet Communications Taiwan
11 - AS48068             838  0.1%     838.0 -- VISONIC Visonic Ltd
12 - AS2                 743  0.0%     612.0 -- VISTA-AS-AP Vista Entertainment Solutions Ltd.
13 - AS44025             688  0.0%     688.0 -- KAMTELEKOM-NET Kamtelekom Ltd.
14 - AS53217             658  0.0%     658.0 -- 
15 - AS39365            2094  0.1%     523.5 -- MICROLINES-AS MICROLINES ISP
16 - AS35333             487  0.0%     487.0 -- CITYNET-AS SIA CITYNET
17 - AS34994            1940  0.1%     485.0 -- LVBP-AS Baltic Pro SIA
18 - AS34620             477  0.0%     477.0 -- MIKRONET_LTD-AS Mikronet SIA
19 - AS48546             474  0.0%     474.0 -- LETA_LV SIA LETA AS
20 - AS43188             472  0.0%     472.0 -- LDC_AS V/A "Lauksaimniecibas Datu Centrs"


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 202.92.235.0/24   12905  0.7%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 2 - 130.36.34.0/24    12464  0.7%   AS32528 -- ABBOTT Abbot Labs
 3 - 130.36.35.0/24    12464  0.7%   AS32528 -- ABBOTT Abbot Labs
 4 - 66.248.104.0/21   10477  0.6%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 5 - 91.224.110.0/23   10387  0.6%   AS56375 -- IKRF Imam Khomeini Relief Foundation IKRF
 6 - 66.248.120.0/21   10163  0.6%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 7 - 66.248.96.0/21     9440  0.5%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 8 - 200.23.202.0/24    8212  0.5%   AS3454  -- Universidad Autonoma de Nuevo Leon
 9 - 119.46.89.0/24     7334  0.4%   AS17552 -- TRUE-AS-AP True Corporation Co.,Ltd.
                                     AS7470  -- ASIAINFO-AS-AP ASIA INFONET Co.,Ltd./ TRUE INTERNET Co.,Ltd.
10 - 213.16.48.0/24     7015  0.4%   AS8866  -- BTC-AS Bulgarian Telecommunication Company Plc.
11 - 180.180.248.0/24   6829  0.4%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
12 - 180.180.253.0/24   6828  0.4%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
13 - 180.180.250.0/24   6826  0.4%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
14 - 180.180.251.0/24   6824  0.4%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
15 - 180.180.255.0/24   6551  0.4%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
16 - 145.36.122.0/24    6531  0.4%   AS7046  -- RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business
17 - 180.180.249.0/24   6494  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
18 - 61.90.164.0/24     6201  0.3%   AS38543 -- IBM-TH-AS-AP IBM THAILAND NETWORK
19 - 58.97.61.0/24      6200  0.3%   AS38543 -- IBM-TH-AS-AP IBM THAILAND NETWORK
20 - 204.246.184.0/24   6032  0.3%   AS16509 -- AMAZON-02 - Amazon.com, 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 cidr-report at potaroo.net  Fri Sep  9 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 9 Sep 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201109092200.p89M00vQ034172@wattle.apnic.net>

This report has been generated at Fri Sep  9 21:12:28 2011 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
        02-09-11    373096      219901
        03-09-11    373636      219796
        04-09-11    373666      219877
        05-09-11    373566      219844
        06-09-11    373748      219894
        07-09-11    373965      219992
        08-09-11    373797      219481
        09-09-11    373405      220098


AS Summary
         38831  Number of ASes in routing system
         16392  Number of ASes announcing only one prefix
          3564  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      108360672  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').

 --- 09Sep11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     374093   219958   154135    41.2%   All ASes

AS6389      3564      229     3335    93.6%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4766      2508      974     1534    61.2%   KIXS-AS-KR Korea Telecom
AS18566     1912      378     1534    80.2%   COVAD - Covad Communications
                                               Co.
AS22773     1451      108     1343    92.6%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1547      228     1319    85.3%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS4323      1627      397     1230    75.6%   TWTC - tw telecom holdings,
                                               inc.
AS10620     1661      591     1070    64.4%   Telmex Colombia S.A.
AS1785      1825      778     1047    57.4%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS19262     1394      400      994    71.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS7552      1415      431      984    69.5%   VIETEL-AS-AP Vietel
                                               Corporation
AS28573     1302      344      958    73.6%   NET Servicos de Comunicao S.A.
AS18101      950      144      806    84.8%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS24560     1177      386      791    67.2%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS8151      1411      659      752    53.3%   Uninet S.A. de C.V.
AS4808      1077      339      738    68.5%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS7303      1051      316      735    69.9%   Telecom Argentina S.A.
AS7545      1581      860      721    45.6%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1103      449      654    59.3%   LEVEL3 Level 3 Communications
AS30036     1327      692      635    47.9%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS3549      1080      449      631    58.4%   GBLX Global Crossing Ltd.
AS14420      715       92      623    87.1%   CORPORACION NACIONAL DE
                                               TELECOMUNICACIONES - CNT EP
AS20115     1591      971      620    39.0%   CHARTER-NET-HKY-NC - Charter
                                               Communications
AS22561      973      365      608    62.5%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS17676      675       70      605    89.6%   GIGAINFRA Softbank BB Corp.
AS17974     1985     1400      585    29.5%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4804       660       87      573    86.8%   MPX-AS Microplex PTY LTD
AS22047      579       31      548    94.6%   VTR BANDA ANCHA S.A.
AS4780       759      230      529    69.7%   SEEDNET Digital United Inc.
AS7011      1183      656      527    44.5%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.
AS15475      512        8      504    98.4%   NOL

Total      40595    13062    27533    67.8%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        46.18.104.0/21       AS3.746 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        76.77.32.0/19        AS2828  XO-AS15 - XO Communications
        80.88.10.0/24        AS33774 DJAWEB
        100.100.100.0/24     AS3549  GBLX Global Crossing Ltd.
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        181.82.15.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.16.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.17.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        181.82.18.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        190.102.32.0/20      AS30058 FDCSERVERS - FDCservers.net
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.111.87.0/24      AS24812 
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.76.0/24       AS7195  Telecorp Colombia S.A.
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.9.57.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        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.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.72.192.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.72.194.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        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.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.58.200.0/24      AS18530 ISOMEDIA-1 - Isomedia Inc.
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


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 lstewart at superb.net  Fri Sep  9 19:00:34 2011
From: lstewart at superb.net (Landon Stewart)
Date: Fri, 9 Sep 2011 17:00:34 -0700
Subject: SourceForge / geek.net contact please
Message-ID: <CABgOHgs=ZJqVts+dmkQ4iccVY5xCrC7qKi+8Lup=GTf1gz4CmQ@mail.gmail.com>

Hello Nanog,

I wrote sfnet_ops at geek.net but have had no response in over 24 hours.
 Wondering if someone from SF can contact me off list please.

-- 
Landon Stewart <LStewart at SUPERB.NET>
SuperbHosting.Net by Superb Internet Corp.
Toll Free (US/Canada): 888-354-6128 x 4199
Direct: 206-438-5879
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net


From pixitha.kyle at gmail.com  Fri Sep  9 20:26:03 2011
From: pixitha.kyle at gmail.com (Kyle Duren)
Date: Fri, 9 Sep 2011 18:26:03 -0700
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24
In-Reply-To: <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
Message-ID: <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>

Is this announcement still showing up this way (no easy way to check
myself).

-Kyle

On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes <chaynes at centracomm.net> wrote:

> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
> jf at probe-networks.de> wrote:
>
> > Hello,
> >
> > anyone else getting a route for 212.118.142.0/24 with invalid
> > attributes? Seems this is (again) causing problems with some (older)
> > routers/software.
> >
> >               Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
> > 6-Resolve tree 2
> >                AS path: 6453 39386 25019 I Unrecognized Attributes: 39
> > bytes
> >                AS path:  Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
> > 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
> > 00 00 00 64
> >                Accepted Multipath
> >
> >
> > -Jonas
> >
> >
> Yup! We're seeing the same thing too, and we're filtering it out.
> Originating AS is 25019
>
> -Clay
>


From nanog at deman.com  Fri Sep  9 22:06:42 2011
From: nanog at deman.com (Michael DeMan)
Date: Fri, 9 Sep 2011 20:06:42 -0700
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <4E6A8B10.3030607@paulgraydon.co.uk>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com> <4E6A8B10.3030607@paulgraydon.co.uk>
Message-ID: <F8A775A1-63E0-42FE-9C79-D16FEFA32EE8@deman.com>

Sorry for being ignorant here - I have not even been aware that it is possible to buy a '*.*.com' domain at all.

I though wildcards were limited to having a domain off a TLD - like '*.mydomain.tld'.

Is it true that the my browser on a windows, mac, or linux desktop may have listed as trusted authorities, an outfit that sells '*.*.tld' ?

Thanks,

- Mike

On Sep 9, 2011, at 2:54 PM, Paul wrote:

> On 09/09/2011 11:48 AM, Marcus Reid wrote:
>> On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:
>>> FYI!!!
>>> 
>>> http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee
>>> ms_all_diginotar_certificates_untrust.html
>>> 
>>> Google and Mozilla have also updated their browsers to block all DigiNotar
>>> certificates, while Apple has been silent on the issue, a emblematic zombie
>>> response!
>> Apple has sent out a notification saying that they are removing
>> DigiNotar from their list of trusted root certs.
>> 
>> I like this response; instant CA death penalty seems to put the
>> incentives about where they need to be.
>> 
>> Marcus
>> 
> Instant?  This has been going on for over a week, and a lot of damage could have been done in that time, especially given certs for *.*.com were signed against Diginotar.  Most cell phones are unable to update their certificates without an upgrade and you know how long it takes to get them through Cell Phone carriers.  A number of alternative android builds are adding the ability to control accepted root certs to their builds in the interest of speeding this up.  The CA system is fundamentally flawed.
> 
> Paul
> 




From dwhite at olp.net  Fri Sep  9 22:35:40 2011
From: dwhite at olp.net (Dan White)
Date: Fri, 9 Sep 2011 22:35:40 -0500
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <F8A775A1-63E0-42FE-9C79-D16FEFA32EE8@deman.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <4E6A8B10.3030607@paulgraydon.co.uk>
 <F8A775A1-63E0-42FE-9C79-D16FEFA32EE8@deman.com>
Message-ID: <20110910033540.GA4503@dan.olp.net>

On 09/09/11?20:06?-0700, Michael DeMan wrote:
>Sorry for being ignorant here - I have not even been aware that it is
>possible to buy a '*.*.com' domain at all.
>
>I though wildcards were limited to having a domain off a TLD - like '*.mydomain.tld'.
>
>Is it true that the my browser on a windows, mac, or linux desktop may
>have listed as trusted authorities, an outfit that sells '*.*.tld' ?

The issue is that a trusted third party's (Diginotar) trusted signing
certificate was stolen, allowing the holder to create and sign whatever
certificates he wished, which don't necessarily need to be wildcard certs
to be effective.

Certificate signers are not restricted to any domain hierarchy (a design
feature of x.509 pki), which means that *any* trusted stolen signing
certificate can wreak havok on the trusted nature of x.509.

Even the hint that the claimed Diginotar cracker has gotten her hands
on several other signing certificates may be significant motivation to find
a replacement for the existing x.509 based pki.

>On Sep 9, 2011, at 2:54 PM, Paul wrote:
>
>> On 09/09/2011 11:48 AM, Marcus Reid wrote:
>>> On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:
>>>> FYI!!!
>>>>
>>>> http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee
>>>> ms_all_diginotar_certificates_untrust.html
>>>>
>>>> Google and Mozilla have also updated their browsers to block all DigiNotar
>>>> certificates, while Apple has been silent on the issue, a emblematic zombie
>>>> response!
>>> Apple has sent out a notification saying that they are removing
>>> DigiNotar from their list of trusted root certs.
>>>
>>> I like this response; instant CA death penalty seems to put the
>>> incentives about where they need to be.
>>>
>>> Marcus
>>>
>> Instant?  This has been going on for over a week, and a lot of damage could have been done in that time, especially given certs for *.*.com were signed against Diginotar.  Most cell phones are unable to update their certificates without an upgrade and you know how long it takes to get them through Cell Phone carriers.  A number of alternative android builds are adding the ability to control accepted root certs to their builds in the interest of speeding this up.  The CA system is fundamentally flawed.
>>
>> Paul

-- 
Dan White



From mtinka at globaltransit.net  Sat Sep 10 00:46:30 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 10 Sep 2011 13:46:30 +0800
Subject: NAT444 or ?
In-Reply-To: <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
 <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
Message-ID: <201109101346.34026.mtinka@globaltransit.net>

On Thursday, September 08, 2011 01:41:58 PM Seth Mos wrote:

> The striking thing I picked up is that NTT considers the
> CGN equipment a big black hole where money goes into.
> Because it won't solve their problem now or in the
> future and it becomes effectively a piece of equipment
> they need to buy and then scrap "soon" after.
> 
> They acknowledge the need, but they'd rather not buy one.
> That and they (the isp) get called for anything which
> doesn't work.

In spending millions of hard-earned $$ toward vendors, NTT 
might not be alone in this realization.

However, in acknowledging that it's an endless blackhole 
where you won't see money necessarily coming back relative 
to the amount being put in, they may just part of a small 
handful of folk, sadly.

GPRS/3G/EDGE has made many a mobile provider especially 
notorious.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110910/8ac354ee/attachment.bin>

From mtinka at globaltransit.net  Sat Sep 10 00:49:39 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 10 Sep 2011 13:49:39 +0800
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BC0F1@EALPO1.ukbroadband.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BC0F1@EALPO1.ukbroadband.com>
Message-ID: <201109101349.39666.mtinka@globaltransit.net>

On Thursday, September 08, 2011 04:52:56 PM Leigh Porter 
wrote:

> Well if you buy the 'right' solution then you can re-use
> it elsewhere. Many solutions use multi-purpose
> processing cards to deliver NAT functionality which can
> be used for other stuff such as firewalling or some
> other manor of traffic mangling.

You'll be hard-pressed to NOT find a vendor willing to sell 
you the "right" solution for the "easy way out" :-).

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110910/e4a0e99e/attachment.bin>

From rdobbins at arbor.net  Sat Sep 10 00:52:12 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sat, 10 Sep 2011 05:52:12 +0000
Subject: NAT444 or ?
In-Reply-To: <201109101346.34026.mtinka@globaltransit.net>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
 <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
 <201109101346.34026.mtinka@globaltransit.net>
Message-ID: <56A94CD0-4CE1-4C7A-85F3-201A84E17396@arbor.net>

On Sep 10, 2011, at 12:46 PM, Mark Tinka wrote:

> GPRS/3G/EDGE has made many a mobile provider especially notorious.

All this problematic state should be broken up into smaller instantiations and distributed as close to the access edge (RAN, wireline, etc.) as possible in order to a) reduce the amount of state concentrated in a single device and b) to minimize the impact footprint when aberrant traffic inevitably fills up the state tables and said devices choke.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From mtinka at globaltransit.net  Sat Sep 10 01:02:05 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 10 Sep 2011 14:02:05 +0800
Subject: NAT444 or ?
In-Reply-To: <030301cc6e4e$e99d5b10$bcd81130$@com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <m2y5y0r72b.wl%randy@psg.com> <030301cc6e4e$e99d5b10$bcd81130$@com>
Message-ID: <201109101402.09401.mtinka@globaltransit.net>

On Friday, September 09, 2011 01:44:08 AM Dan Wing wrote:

> Many of the problems are due to IPv4 address sharing,
> which will be problems for A+P, CGN, HTTP proxies, and
> other address sharing technologies.  RFC6269 discusses
> most (or all) of those problems. There are workarounds
> to those problems, but most are not pretty.  The
> solution is IPv6.

I do expect some of these workarounds to be vendor and/or 
platform specific, as more units are deployed and the 
industry simply can't keep up with the various topologies 
and customer elasticities ISP's have to maintain.

We're already seeing evidence of this as we discuss NAT64 
options with vendors, particularly in the area of scale and 
customer experience perceptions.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110910/f31e2ba4/attachment.bin>

From mtinka at globaltransit.net  Sat Sep 10 01:11:19 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 10 Sep 2011 14:11:19 +0800
Subject: NAT444 or ?
In-Reply-To: <56A94CD0-4CE1-4C7A-85F3-201A84E17396@arbor.net>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <201109101346.34026.mtinka@globaltransit.net>
 <56A94CD0-4CE1-4C7A-85F3-201A84E17396@arbor.net>
Message-ID: <201109101411.19948.mtinka@globaltransit.net>

On Saturday, September 10, 2011 01:52:12 PM Dobbins, Roland 
wrote:

> All this problematic state should be broken up into
> smaller instantiations and distributed as close to the
> access edge (RAN, wireline, etc.) as possible in order
> to a) reduce the amount of state concentrated in a
> single device and b) to minimize the impact footprint
> when aberrant traffic inevitably fills up the state
> tables and said devices choke.

Certainly a consideration when an ISP considers scaling 
avenues for LSN's.

The issue is that there are simply too many variables, not 
least of which is what business the ISP is in.

The mobile types are a lot more problematic because they 
tend to centralize IP intelligence, and keep the RAN's 
pretty simple (although the RAN's are now becoming more 
intelligent thanks to your garden-variety IP vendors getting 
into the game). What we've seen also, with some mobile 
carriers, is that if you ask them to consider distributed IP 
architectures, they/you quickly realize that IP routing 
isn't really their core business or skill.

For your typical ISP, size notwithstanding, it will 
invariably come down to how much money and effort they're 
willing to spend or save with either centralized or 
distributed architectures. Mind you, they're also battling 
with other problems re: centralized or distributed 
solutions, e.g., broadband aggregation, the ratio of 
access:aggregation intelligence, access topology lay-outs, 
e.t.c. And somehow, in all this mix, LSN's must work, be 
they small units thrown around the network, or one or two 
large monsters sitting somewhere in the core.

We've certainly considered both options very thoroughly.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110910/9a5a30e3/attachment.bin>

From mysidia at gmail.com  Sat Sep 10 01:33:25 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 10 Sep 2011 01:33:25 -0500
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <20110909214804.GA88934@blazingdot.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
Message-ID: <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>

On Fri, Sep 9, 2011 at 4:48 PM, Marcus Reid <marcus at blazingdot.com> wrote:
> On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:
> I like this response; instant CA death penalty seems to put the
> incentives about where they need to be.

I wouldn't necessarily count them dead just yet;  although their legit
customers must be very unhappy  waking up one day to find their
legitimate working SSL certs suddenly unusable....

So DigiNotar lost their "browser trusted"  root CA status.  That
doesn't necessarily mean they will
be unable to get other root CAs to cross-sign CA certificates they
will make in the future, for the right price.

A cross-sign with CA:TRUE  is  just as good as being installed in
users' browser.


--
-JH



From rdobbins at arbor.net  Sat Sep 10 01:43:19 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sat, 10 Sep 2011 06:43:19 +0000
Subject: NAT444 or ?
In-Reply-To: <201109101411.19948.mtinka@globaltransit.net>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <201109101346.34026.mtinka@globaltransit.net>
 <56A94CD0-4CE1-4C7A-85F3-201A84E17396@arbor.net>
 <201109101411.19948.mtinka@globaltransit.net>
Message-ID: <73E8EB10-CE47-43FE-BF7B-95E967562DB6@arbor.net>

On Sep 10, 2011, at 1:11 PM, Mark Tinka wrote:

> What we've seen also, with some mobile carriers, is that if you ask them to consider distributed IP architectures, they/you quickly realize that IP routing isn't really their core business or skill.

Concur.  Many/most have essentially become 'accidental ISPs' through the rise in popularity of iDevices, and some at least are beginning to realize this and to staff and re-engineer accordingly.  It takes time, though.


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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From heinrich at hstrauss.co.za  Sat Sep 10 03:47:02 2011
From: heinrich at hstrauss.co.za (Heinrich Strauss)
Date: Sat, 10 Sep 2011 10:47:02 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
 updates
In-Reply-To: <F8A775A1-63E0-42FE-9C79-D16FEFA32EE8@deman.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com> <4E6A8B10.3030607@paulgraydon.co.uk>
 <F8A775A1-63E0-42FE-9C79-D16FEFA32EE8@deman.com>
Message-ID: <4E6B2406.2010805@hstrauss.co.za>

On 2011/09/10 05:06, Michael DeMan wrote:
> Sorry for being ignorant here - I have not even been aware that it is possible to buy a '*.*.com' domain at all.
>
> I though wildcards were limited to having a domain off a TLD - like '*.mydomain.tld'.
>
Given a private network and the need to monitor it in a private 
company[1], we generated a certificate like this for internal use signed 
by a company-internal trusted certificate authority.

Also, given the Subject Alternative Name extension, it is quite possible 
to generate a "godmode" certificate for gracefully redirecting proxied 
HTTPS requests to an "Access Denied" page or even 
nefarious-purpose-logging machine.

-H.

[1] http://en.wikipedia.org/wiki/Lawful_interception



From mysidia at gmail.com  Sat Sep 10 04:17:33 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 10 Sep 2011 04:17:33 -0500
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <4E6B2406.2010805@hstrauss.co.za>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <4E6A8B10.3030607@paulgraydon.co.uk>
 <F8A775A1-63E0-42FE-9C79-D16FEFA32EE8@deman.com>
 <4E6B2406.2010805@hstrauss.co.za>
Message-ID: <CAAAwwbXDas+HaQ7Oc5ezZmmbzUmd-LdH7mxiNXtHNN1h8+HpDA@mail.gmail.com>

On Sat, Sep 10, 2011 at 3:47 AM, Heinrich Strauss
<heinrich at hstrauss.co.za> wrote:
> On 2011/09/10 05:06, Michael DeMan wrote:
>> I though wildcards were limited to having a domain off a TLD - like
>> '*.mydomain.tld'.
The root CAs are have no technical limitation in regards to what kind
of certificates they can issue.
There is no inherent reason that technical limitations cannot be
imposed...  there are mechanisms available to do this,
if the original CA certificates were issued with restrictions:
              http://tools.ietf.org/html/rfc3280#section-4.2.1.11

Special limitations or  "security warnings"  can be raised by
individual browsers above and beyond the certificate validation rules.
I would be in favor of each  root CA certificate being name
constrained to  CNs of one TLD  per CA  certificate,  so that root CA
orgs would need a separate CA cert and separate private key for each
TLD  that CA is authorized to issue certificates in.
It would be useful if the name restriction would be extended further
to allow  2nd level wildcards to be prohibited such as  "CN=*.com"
or   "CN=*.*.com"

Browsers will honor "*" in hostname components of the CN field as
required by the RFCs.. however  a  "*.mydomain.tld"  certificate
does not match www.mydomain.tld,     "*.*.mydomain.tld"  does.

Some CAs have partaken in problematic practices such  as issuing SSL
certificates with  RFC1918 IP addresses,
or  "unofficial"  TLDs  in the CN or  subject alternative names  section.
see   https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_SSL_Certificates_for_Internal_Domains

If all the root CA certificates become name constrained,  such
problematic practices should cease.

--
-JH



From mtinka at globaltransit.net  Sat Sep 10 06:26:06 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 10 Sep 2011 19:26:06 +0800
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
Message-ID: <201109101926.09838.mtinka@globaltransit.net>

On Thursday, September 08, 2011 04:48:16 PM Leigh Porter 
wrote:

> Soon, I think content providers (and providers of other
> services on the 'net) will roll v6 because of the
> performance increase as v6 will not have to traverse all
> this NAT and be subject to session limits, timeouts and
> such.

I certainly hope so - let's hope ISP's go out and deploy v6 
beyond the core, as content providers deploy v6 for their 
content, rather have a stand-off between both ends of fence 
on who should move first.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110910/8781004f/attachment.bin>

From cb.list6 at gmail.com  Sat Sep 10 08:40:10 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sat, 10 Sep 2011 06:40:10 -0700
Subject: NAT444 or ?
In-Reply-To: <56A94CD0-4CE1-4C7A-85F3-201A84E17396@arbor.net>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
 <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
 <201109101346.34026.mtinka@globaltransit.net>
 <56A94CD0-4CE1-4C7A-85F3-201A84E17396@arbor.net>
Message-ID: <CAD6AjGRNEUHD24S7ME5J5P9q-g_g5ur=TNOZDUVSmyhmYKk6tg@mail.gmail.com>

On Sep 9, 2011 10:54 PM, "Dobbins, Roland" <rdobbins at arbor.net> wrote:
>
> On Sep 10, 2011, at 12:46 PM, Mark Tinka wrote:
>
> > GPRS/3G/EDGE has made many a mobile provider especially notorious.
>
> All this problematic state should be broken up into smaller instantiations
and distributed as close to the access edge (RAN, wireline, etc.) as
possible in order to a) reduce the amount of state concentrated in a single
device and b) to minimize the impact footprint when aberrant traffic
inevitably fills up the state tables and said devices choke.
>

Ip mobility via gtp or mobile ip generally does not work when you nat at the
'edge'.  If you don't want your ip address to change every time you change
cell sites, the nat has to be centralized.

Cb
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>                The basis of optimism is sheer terror.
>
>                          -- Oscar Wilde
>
>


From andrew.wallace at rocketmail.com  Sat Sep 10 08:55:33 2011
From: andrew.wallace at rocketmail.com (andrew.wallace)
Date: Sat, 10 Sep 2011 06:55:33 -0700 (PDT)
Subject: Hurricane Katia
Message-ID: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>

I'm hearing on the news wire 80mph winds will come to UK over the next 72 hours.

Andrew


From tshaw at oitc.com  Sat Sep 10 09:17:04 2011
From: tshaw at oitc.com (TR Shaw)
Date: Sat, 10 Sep 2011 10:17:04 -0400
Subject: Hurricane Katia
In-Reply-To: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
References: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
Message-ID: <348A6C10-9939-4281-8680-7537B3BE4052@oitc.com>


On Sep 10, 2011, at 9:55 AM, andrew.wallace wrote:

> I'm hearing on the news wire 80mph winds will come to UK over the next 72 hours.
> 
> Andrew


Andrew,

80 km maybe. TS force winds for Northern Scotland and Hebrides probably but I doubt the rest of the UK and it is only forcast to be a TS at that time

See http://www.nhc.noaa.gov/refresh/graphics_at2+shtml/102512.shtml?tswind120

Follow Katia at http://www.nhc.noaa.gov/graphics_at2.shtml?5-daynl#contents

Tom



From leigh.porter at ukbroadband.com  Sat Sep 10 09:33:35 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Sat, 10 Sep 2011 14:33:35 +0000
Subject: Hurricane Katia
In-Reply-To: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
References: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
Message-ID: <D05E89F4-F623-4871-896B-1AFD0FD82727@ukbroadband.com>

Nar it's ok, it'll pass the UK and it'll all be fine, just like the other time..

-- 
Leigh Porter


On 10 Sep 2011, at 14:57, "andrew.wallace" <andrew.wallace at rocketmail.com> wrote:

> I'm hearing on the news wire 80mph winds will come to UK over the next 72 hours.
> 
> Andrew
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From mksmith at adhost.com  Sat Sep 10 11:57:03 2011
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Sat, 10 Sep 2011 16:57:03 +0000
Subject: Administrivia - Recreating Archives
Message-ID: <CA90E503.2876A%mksmith@adhost.com>

Hello Everyone:

I am recreating the archives for the primary NANOG list, so they will be
unavailable for a "little while", probably a couple of hours.  The list
will function as expected and all messages to the list will be archived
during this process.

Regards,

Mike




From morrowc.lists at gmail.com  Sat Sep 10 13:01:00 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 10 Sep 2011 14:01:00 -0400
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24
In-Reply-To: <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
Message-ID: <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>

On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren <pixitha.kyle at gmail.com> wrote:
> Is this announcement still showing up this way (no easy way to check
> myself).

ripe ris?

> -Kyle
>
> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes <chaynes at centracomm.net> wrote:
>
>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
>> jf at probe-networks.de> wrote:
>>
>> > Hello,
>> >
>> > anyone else getting a route for 212.118.142.0/24 with invalid
>> > attributes? Seems this is (again) causing problems with some (older)
>> > routers/software.
>> >
>> > ? ? ? ? ? ? ? Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
>> > 6-Resolve tree 2
>> > ? ? ? ? ? ? ? ?AS path: 6453 39386 25019 I Unrecognized Attributes: 39
>> > bytes
>> > ? ? ? ? ? ? ? ?AS path: ?Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
>> > 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
>> > 00 00 00 64
>> > ? ? ? ? ? ? ? ?Accepted Multipath
>> >
>> >
>> > -Jonas
>> >
>> >
>> Yup! We're seeing the same thing too, and we're filtering it out.
>> Originating AS is 25019
>>
>> -Clay
>>
>



From askoorb+nanog at gmail.com  Sat Sep 10 13:52:24 2011
From: askoorb+nanog at gmail.com (Alex Brooks)
Date: Sat, 10 Sep 2011 19:52:24 +0100
Subject: Hurricane Katia
In-Reply-To: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
References: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
Message-ID: <CALKLF08io-9UVLxz-DB1Xm6xa2nLqeKOoQctvNRi2vzf94JSPg@mail.gmail.com>

On Sat, Sep 10, 2011 at 2:55 PM, andrew.wallace
<andrew.wallace at rocketmail.com> wrote:
>
> I'm hearing on the news wire 80mph winds will come to UK over the next 72 hours.
>

?Anyone worried about major weather events in the UK is probably best
either checking or subscribing to the Met Office's weather warnings at
http://www.metoffice.gov.uk/public/beta/weather/warnings/ rather than
relying on a US source (and vice-versa for US weather).

If worried about flooding, the Environment Agency's Flood Warnings are
what you're after at
http://www.environment-agency.gov.uk/homeandleisure/floods/31618.aspx.

Both Weather Warnings and Flood Warnings come in three flavours,
yellow, amber and red.  Red is the danger to life / take action level.

Currently, there is an amber 'be prepared' weather warning out for
Monday for some areas of the UK.

Currently the country wide detail is:
Weather Report
Stormy weather heading for the UK
The forecast team at the Met Office are continuing to keep an eye on
the remains of Hurricane Katia as it moves across the Atlantic Ocean.
Currently the storm lies just southeast of Newfoundland in Canada, but
it is expected to rapidly move towards northwestern parts of the UK
during the next 36 to 48 hours, arriving on Monday morning. Please see
our warnings page for further details. Issued at 1346 on Sat 10 Sep
2011.

And the warning itself
Issued at: 10 Sep 2011, 1138
Valid from: 12 Sep 2011, 0000
Valid to: 12 Sep 2011, 2359
The remains of Hurricane Katia are expected to come across the UK on
Monday bringing a spell of wet and very windy weather. There remains
some uncertainty about its track and intensity, although Scotland and
Northern Ireland are most likely to bear the brunt of the winds, The
public should be prepared for the risk of disruption to transport and
of the possibility of damage to trees and structures.

Chief Forecaster's Assessment
Forecast models continue to show some differences in the handling of
the transition of hurricane Katia to an intense extra tropical
depression, though with increasing agreement that the centre will pass
close to the north of Scotland on Monday, bringing strongest winds to
Scotland and Northern Ireland. There is the potential for 60-70 mph
gusts and 80 mph or more could occur over exposed coasts and hills.
Heavy rain will be an additional hazard for the same regions, with as
much as 50-100mm possible over parts of western Scotland.


So not too bad really in the overall scheme of things.

Alex



From Valdis.Kletnieks at vt.edu  Sat Sep 10 14:16:23 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 10 Sep 2011 15:16:23 -0400
Subject: Hurricane Katia
In-Reply-To: Your message of "Sat, 10 Sep 2011 06:55:33 PDT."
 <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
References: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
Message-ID: <107718.1315682183@turing-police.cc.vt.edu>

On Sat, 10 Sep 2011 06:55:33 PDT, "andrew.wallace" said:
> I'm hearing on the news wire 80mph winds will come to UK over the next 72 hours.

Probably 80kph was intended.

Why is this at all newsworthy?  You've previously stated that Irene-like conditions
are "normal" for Scotland, so it shouldn't be a big thing...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110910/95b3bcca/attachment.bin>

From richard.barnes at gmail.com  Sat Sep 10 17:26:14 2011
From: richard.barnes at gmail.com (Richard Barnes)
Date: Sat, 10 Sep 2011 18:26:14 -0400
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24
In-Reply-To: <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
Message-ID: <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>

Looks like the RIS collectors are seeing it originating mostly from
STC and KACST ASNs:
<http://stat.ripe.net/212.118.142.0/24>

Some of the "show ip bgp" reports on that screen are also showing
AS8866 "BTC-AS Bulgarian Telecommunication Company".  Not sure what's
up with that.

--Richard



On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren <pixitha.kyle at gmail.com> wrote:
>> Is this announcement still showing up this way (no easy way to check
>> myself).
>
> ripe ris?
>
>> -Kyle
>>
>> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes <chaynes at centracomm.net> wrote:
>>
>>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
>>> jf at probe-networks.de> wrote:
>>>
>>> > Hello,
>>> >
>>> > anyone else getting a route for 212.118.142.0/24 with invalid
>>> > attributes? Seems this is (again) causing problems with some (older)
>>> > routers/software.
>>> >
>>> > ? ? ? ? ? ? ? Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
>>> > 6-Resolve tree 2
>>> > ? ? ? ? ? ? ? ?AS path: 6453 39386 25019 I Unrecognized Attributes: 39
>>> > bytes
>>> > ? ? ? ? ? ? ? ?AS path: ?Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
>>> > 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
>>> > 00 00 00 64
>>> > ? ? ? ? ? ? ? ?Accepted Multipath
>>> >
>>> >
>>> > -Jonas
>>> >
>>> >
>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>> Originating AS is 25019
>>>
>>> -Clay
>>>
>>
>
>



From aftab.siddiqui at gmail.com  Sat Sep 10 17:49:17 2011
From: aftab.siddiqui at gmail.com (Aftab Siddiqui)
Date: Sun, 11 Sep 2011 03:49:17 +0500
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24
In-Reply-To: <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
 <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
Message-ID: <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>

with in the span of couple of hours this prefix was originated from 3 ASN
i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians).

As per the STC it was orginated by one of their customer having Juniper
router. but I still don't understand why/how they are adv this prefix with
unrecog transitive attributes.

Can any one suggest.

Regards,

Aftab A. Siddiqui


On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes <richard.barnes at gmail.com>wrote:

> Looks like the RIS collectors are seeing it originating mostly from
> STC and KACST ASNs:
> <http://stat.ripe.net/212.118.142.0/24>
>
> Some of the "show ip bgp" reports on that screen are also showing
> AS8866 "BTC-AS Bulgarian Telecommunication Company".  Not sure what's
> up with that.
>
> --Richard
>
>
>
> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
> > On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren <pixitha.kyle at gmail.com>
> wrote:
> >> Is this announcement still showing up this way (no easy way to check
> >> myself).
> >
> > ripe ris?
> >
> >> -Kyle
> >>
> >> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes <chaynes at centracomm.net>
> wrote:
> >>
> >>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
> >>> jf at probe-networks.de> wrote:
> >>>
> >>> > Hello,
> >>> >
> >>> > anyone else getting a route for 212.118.142.0/24 with invalid
> >>> > attributes? Seems this is (again) causing problems with some (older)
> >>> > routers/software.
> >>> >
> >>> >               Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
> >>> > 6-Resolve tree 2
> >>> >                AS path: 6453 39386 25019 I Unrecognized Attributes:
> 39
> >>> > bytes
> >>> >                AS path:  Attr flags e0 code 80: 00 00 fd 88 40 01 01
> 02
> >>> > 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05
> 04
> >>> > 00 00 00 64
> >>> >                Accepted Multipath
> >>> >
> >>> >
> >>> > -Jonas
> >>> >
> >>> >
> >>> Yup! We're seeing the same thing too, and we're filtering it out.
> >>> Originating AS is 25019
> >>>
> >>> -Clay
> >>>
> >>
> >
> >
>
>


From furry13 at gmail.com  Sat Sep 10 18:57:04 2011
From: furry13 at gmail.com (Jen Linkova)
Date: Sun, 11 Sep 2011 09:57:04 +1000
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24
In-Reply-To: <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
 <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
 <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
Message-ID: <CAFU7BATGgDtFh_=wynWK1UxJ99T-H-xzQJqgyFtQVwWO_Ot9Jw@mail.gmail.com>

On Sun, Sep 11, 2011 at 8:49 AM, Aftab Siddiqui
<aftab.siddiqui at gmail.com> wrote:
> with in the span of couple of hours this prefix was originated from 3 ASN
> i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians).
>
> As per the STC it was orginated by one of their customer having Juniper
> router. but I still don't understand why/how they are adv this prefix with
> unrecog transitive attributes.

For example, AS_CONFED_SEQUENCE and/or AS_CONFED_SET in AS4_PATH again..;(

> On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes <richard.barnes at gmail.com>wrote:
>
>> Looks like the RIS collectors are seeing it originating mostly from
>> STC and KACST ASNs:
>> <http://stat.ripe.net/212.118.142.0/24>
>>
>> Some of the "show ip bgp" reports on that screen are also showing
>> AS8866 "BTC-AS Bulgarian Telecommunication Company". ?Not sure what's
>> up with that.
>>
>> --Richard
>>
>>
>>
>> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow
>> <morrowc.lists at gmail.com> wrote:
>> > On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren <pixitha.kyle at gmail.com>
>> wrote:
>> >> Is this announcement still showing up this way (no easy way to check
>> >> myself).
>> >
>> > ripe ris?
>> >
>> >> -Kyle
>> >>
>> >> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes <chaynes at centracomm.net>
>> wrote:
>> >>
>> >>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
>> >>> jf at probe-networks.de> wrote:
>> >>>
>> >>> > Hello,
>> >>> >
>> >>> > anyone else getting a route for 212.118.142.0/24 with invalid
>> >>> > attributes? Seems this is (again) causing problems with some (older)
>> >>> > routers/software.
>> >>> >
>> >>> > ? ? ? ? ? ? ? Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
>> >>> > 6-Resolve tree 2
>> >>> > ? ? ? ? ? ? ? ?AS path: 6453 39386 25019 I Unrecognized Attributes:
>> 39
>> >>> > bytes
>> >>> > ? ? ? ? ? ? ? ?AS path: ?Attr flags e0 code 80: 00 00 fd 88 40 01 01
>> 02
>> >>> > 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05
>> 04
>> >>> > 00 00 00 64
>> >>> > ? ? ? ? ? ? ? ?Accepted Multipath
>> >>> >
>> >>> >
>> >>> > -Jonas
>> >>> >
>> >>> >
>> >>> Yup! We're seeing the same thing too, and we're filtering it out.
>> >>> Originating AS is 25019
>> >>>
>> >>> -Clay
>> >>>
>> >>
>> >
>> >
>>
>>
>



-- 
SY, Jen Linkova aka Furry



From jay at miscreant.org  Sat Sep 10 20:52:40 2011
From: jay at miscreant.org (Jay Mitchell)
Date: Sun, 11 Sep 2011 11:52:40 +1000
Subject: Hurricane Katia
In-Reply-To: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
References: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
Message-ID: <E28A585A-B9A4-4D20-8EBE-4401A49A5FAF@miscreant.org>

Just another average day in Scotland...

On 10/09/2011, at 11:55 PM, "andrew.wallace" <andrew.wallace at rocketmail.com> wrote:

> I'm hearing on the news wire 80mph winds will come to UK over the next 72 hours.
> 
> Andrew



From hasserw at hushmail.com  Sat Sep 10 20:55:01 2011
From: hasserw at hushmail.com (hasserw at hushmail.com)
Date: Sat, 10 Sep 2011 21:55:01 -0400
Subject: How to begin making my own ISP?
Message-ID: <20110911015501.1DC2BE671D@smtp.hushmail.com>

I want to begin making my own ISP, mainly for high speed servers 
and such, but also branching out to residential customers. I'm 
going to be in Germany for the next school year (probably either 
Frankfurt am Main or Berlin); any suggestions on what sort of 
classes I can take there that will be in English and will teach me 
all I need to know on how to build and manage my own ISP, AS, etc? 
Thanks.




From charles at knownelement.com  Sat Sep 10 21:11:32 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Sat, 10 Sep 2011 21:11:32 -0500
Subject: How to begin making my own ISP?
In-Reply-To: <20110911015501.1DC2BE671D@smtp.hushmail.com>
References: <20110911015501.1DC2BE671D@smtp.hushmail.com>
Message-ID: <4E6C18D4.9070906@knownelement.com>

On 09/10/2011 08:55 PM, hasserw at hushmail.com wrote:
> I want to begin making my own ISP, mainly for high speed servers 
> and such, but also branching out to residential customers. I'm 
> going to be in Germany for the next school year (probably either 
> Frankfurt am Main or Berlin); any suggestions on what sort of 
> classes I can take there that will be in English and will teach me 
> all I need to know on how to build and manage my own ISP, AS, etc? 
> Thanks.
>
>

I too am very interested in this topic. I'm in the process of putting a
small service provider network
together. Starting with three points of presence (Los Angeles, Kansas
City, <undetermined east coast location>).

I'm in the process of securing an AS, IP space etc. Already have all the
necessary networking gear. Working on getting
it configured and deployed.

I'm a data center guy coming into the WAN world. Learning as I go.

-- 
Charles N Wyble charles at knownelement.com @charlesnw on twitter

http://blog.knownelement.com

Building alternative,global scale,secure, cost effective bit moving platform
for tomorrows alternate default free zone.




From damian at google.com  Sun Sep 11 01:30:54 2011
From: damian at google.com (Damian Menscher)
Date: Sat, 10 Sep 2011 23:30:54 -0700
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
Message-ID: <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>

On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Fri, Sep 9, 2011 at 4:48 PM, Marcus Reid <marcus at blazingdot.com> wrote:
> > On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:
> > I like this response; instant CA death penalty seems to put the
> > incentives about where they need to be.
>
> I wouldn't necessarily count them dead just yet;  although their legit
> customers must be very unhappy  waking up one day to find their
> legitimate working SSL certs suddenly unusable....
>
> So DigiNotar lost their "browser trusted"  root CA status.  That
> doesn't necessarily mean they will
> be unable to get other root CAs to cross-sign CA certificates they
> will make in the future, for the right price.
>
> A cross-sign with CA:TRUE  is  just as good as being installed in
> users' browser.
>

The problem here wasn't just that DigiNotar was compromised, but that they
didn't have an audit trail and attempted a coverup which resulted in real
harm to users.  It will be difficult to re-gain the trust they lost.

Because of that lost trust, any cross-signed cert would likely be revoked by
the browsers.  It would also make the browser vendors question whether the
signing CA is worthy of their trust.

Damian
-- 
Damian Menscher :: Security Reliability Engineer :: Google

From tvhawaii at shaka.com  Sun Sep 11 02:33:17 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Sat, 10 Sep 2011 21:33:17 -1000
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
Message-ID: <D9E994AFC9394F48B63F5B1386E56A03@owner59e1f1502>

Damian Menscher wrote:
> The problem here wasn't just that DigiNotar was compromised, but that they
> didn't have an audit trail and attempted a coverup which resulted in real
> harm to users.  It will be difficult to re-gain the trust they lost.
>
> Because of that lost trust, any cross-signed cert would likely be revoked by
> the browsers.  It would also make the browser vendors question whether the
> signing CA is worthy of their trust.
>
> Damian

I'd be interested in hearing what you have to say about the hacker's claim at:
http://pastebin.com/85WV10EL

"d) I'm able to issue windows update, Microsoft's statement about Windows Update and that I can't issue such update is 
totally false! I already reversed ENTIRE windows update protocol, how it reads XMLs via SSL which includes URL, KB no, 
SHA-1 hash of file for each update, how it verifies that downloaded file is signed using WinVerifyTrust API, and... Simply 
I can issue updates via windows update!"

Thanks,

--Michael



From ken.gilmour at gmail.com  Sun Sep 11 02:34:03 2011
From: ken.gilmour at gmail.com (Ken Gilmour)
Date: Sun, 11 Sep 2011 09:34:03 +0200
Subject: Hurricane Katia
In-Reply-To: <E28A585A-B9A4-4D20-8EBE-4401A49A5FAF@miscreant.org>
References: <1315662933.2897.YahooMailNeo@web59607.mail.ac4.yahoo.com>
 <E28A585A-B9A4-4D20-8EBE-4401A49A5FAF@miscreant.org>
Message-ID: <CAMhuimiFy4XOjG0a+0FJeA7g1Puohbb6iuLbcHCBsOpjfvaWZw@mail.gmail.com>

Not so bad for UK but there is an extreme weather warning for the west of
Ireland

http://www.independent.ie/national-news/hurricane-alert-storm-winds-coming-as-katia-moves-in-2872652.html

--
Sent from my Android tablet. Please excuse my brevity
On Sep 11, 2011 2:53 AM, "Jay Mitchell" <jay at miscreant.org> wrote:
> Just another average day in Scotland...
>
> On 10/09/2011, at 11:55 PM, "andrew.wallace" <
andrew.wallace at rocketmail.com> wrote:
>
>> I'm hearing on the news wire 80mph winds will come to UK over the next 72
hours.
>>
>> Andrew
>

From leigh.porter at ukbroadband.com  Sun Sep 11 04:02:22 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Sun, 11 Sep 2011 09:02:22 +0000
Subject: NAT444 or ?
In-Reply-To: <CAD6AjGRNEUHD24S7ME5J5P9q-g_g5ur=TNOZDUVSmyhmYKk6tg@mail.gmail.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
 <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
 <201109101346.34026.mtinka@globaltransit.net>
 <56A94CD0-4CE1-4C7A-85F3-201A84E17396@arbor.net>
 <CAD6AjGRNEUHD24S7ME5J5P9q-g_g5ur=TNOZDUVSmyhmYKk6tg@mail.gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BD810@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Cameron Byrne [mailto:cb.list6 at gmail.com]
> Ip mobility via gtp or mobile ip generally does not work when you nat
> at the
> 'edge'.  If you don't want your ip address to change every time you
> change
> cell sites, the nat has to be centralized.
> 
> Cb

Indeed, networks with some kind of anchor point (even xDSL networks with a LNS that terminates PPP sessions) really lend themselves to a big fat NAT box simply because there is a single point where all the connections appear anyway so why not have a single box doing NAT/DPI/etc as well?

I'd agree that, usually, distributed is better but these are not distributed networks, there is a single point (or a few large single points) of contact.

--
Leigh



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From eugen at imacandi.net  Sun Sep 11 06:16:22 2011
From: eugen at imacandi.net (Eugeniu Patrascu)
Date: Sun, 11 Sep 2011 14:16:22 +0300
Subject: Access and Session Control System?
In-Reply-To: <20110902082144.06a49f7a@bart>
References: <CAB+pCuF6BNsKXbiAEXPqMXucqTJ0hfTLbDrqWBLkoY3z8+FH0g@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FC90C57B@MS-EX7MB-P03.corp.se.sempra.com>
 <21875121-62EA-4056-A099-EBFCED0B096B@gmail.com>
 <20110902082144.06a49f7a@bart>
Message-ID: <CALgc3C77vPQw=2UZ4A+qVvxS30_-7ANmEidChZPpxFh8B=M15A@mail.gmail.com>

If you also want to control where they go from the jump box, you might
want to look at http://www.xceedium.com/en/index.php as they claim to
add rules to what a remotely logged in user can do.

Juniper SA is very nice and get's intuitive after you familiriaze
yourself with it's workflow which is a pain if you're new to the box.

On Fri, Sep 2, 2011 at 15:21, John Peach <john-nanog at johnpeach.com> wrote:
> On Thu, 1 Sep 2011 17:45:55 -0400
> Rafael Rodriguez <packetjockey at gmail.com> wrote:
>
>> I recommend you look into the Juniper SSL VPN products (SA Series). Very power boxes, intuitive admin interface (web driven) and are perfect for the "Vendor Access" type of applications.
>
> They work fine (mostly), but your definition of intuitive obviously does
> not coincide with mine.
>
>>
>> Sent from my iPhone
>>
>> On Sep 1, 2011, at 16:30, "Jones, Barry" <BEJones at semprautilities.com> wrote:
>>
>> >
>> > Hello all.
>> > I am looking at a variety of systems/methods to provide (vendor, employee) access into my dmz's. I want to reduce the FW rule sets and connections to as minimal as possible. And I want the accessing party to only get to the destination I define (like a fw rule).
>> >
>> > When I refer to access, I'm referring to the ability of a vendor or employee to perform maintenance tasks on a server(s). The server(s) will be running apps for doing different tasks - such as Shavlik, etc.., ?(patching, reports, logging, etc..), so I am envisioning allowing an outside vendor/employee (from the internet or corp. net) to RDP or SSH to a given Windows or Unix based machines, then perform their application work from that jumping off point - kind of like a terminal server; but I'd like to control and audit the sessions as well.
>> >
>> > Overall, I can allow a host/port through the FW to a single host, but I wanted to be able to do the session management and endpoint controls. FW's are ok, but you know as well as I that I now deal with lots of rules sets. And I need to also authenticate the user.
>> >
>> > We are a couple smaller facilities (150 hosts each) and I need to be able to control and audit the sessions when requested. I have considered doing a meetingplace server, then providing escorted access for them, or doing just the FW and a "jump" host - but need the endpoint and session solution, or just using VPN - but don't want to install a host on the vendor machines. I also have looked at a product called EDMZ - wondered if anyone had experience with it?
>> >
>> > And did I say I wanted to keep it as simple as possible? :-) It's been a few years since I've done hands-on networking work, so excuse the long-winded letter. Feel free to email me directly too.
>> >
>> > Sincerely
>> > Barry Jones
>> > CISSP, GSNA
>>
>
>
>
> --
> john
>
>


From rdobbins at arbor.net  Sun Sep 11 06:33:39 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sun, 11 Sep 2011 11:33:39 +0000
Subject: NAT444 or ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BD810@EALPO1.ukbroadband.com>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
 <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
 <201109101346.34026.mtinka@globaltransit.net>
 <56A94CD0-4CE1-4C7A-85F3-201A84E17396@arbor.net>
 <CAD6AjGRNEUHD24S7ME5J5P9q-g_g5ur=TNOZDUVSmyhmYKk6tg@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BD810@EALPO1.ukbroadband.com>
Message-ID: <58E8E9E2-36EA-4053-A470-59BD72ABD16F@arbor.net>

On Sep 11, 2011, at 4:02 PM, Leigh Porter wrote:

> I'd agree that, usually, distributed is better but these are not distributed networks, there is a single point (or a few large single points) of contact.

The point is that these aggregations of state are quite vulnerable, and therefore they should be as distributed as is practicable.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From cb.list6 at gmail.com  Sun Sep 11 10:30:51 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sun, 11 Sep 2011 08:30:51 -0700
Subject: NAT444 or ?
In-Reply-To: <58E8E9E2-36EA-4053-A470-59BD72ABD16F@arbor.net>
References: <1314902197.33694.YahooMailNeo@web121420.mail.ne1.yahoo.com>
 <5C47414A-20FF-4242-B72A-02F35C2101B9@apnic.net>
 <BB679D1F-E58D-4EB1-A4EF-6C8C13E7547B@dds.nl>
 <201109101346.34026.mtinka@globaltransit.net>
 <56A94CD0-4CE1-4C7A-85F3-201A84E17396@arbor.net>
 <CAD6AjGRNEUHD24S7ME5J5P9q-g_g5ur=TNOZDUVSmyhmYKk6tg@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478643BD810@EALPO1.ukbroadband.com>
 <58E8E9E2-36EA-4053-A470-59BD72ABD16F@arbor.net>
Message-ID: <CAD6AjGRjf7mBhP6sEumWwL+nVhW6uWHMZT=D75XV_jpZ6fVoKw@mail.gmail.com>

On Sep 11, 2011 4:33 AM, "Dobbins, Roland" <rdobbins at arbor.net> wrote:
>
> On Sep 11, 2011, at 4:02 PM, Leigh Porter wrote:
>
> > I'd agree that, usually, distributed is better but these are not
distributed networks, there is a single point (or a few large single points)
of contact.
>
> The point is that these aggregations of state are quite vulnerable, and
therefore they should be as distributed as is practicable.
>

I don't disagree with that principle, but other priciples around scale,
cost, and oam say that we get one big box called a cgn. And, that is the
reality of service provider nat in the real world today.

For mobile providers, the cgn generally follows the mobility anchor points.
For some national providers that means nfl cities, for others that means one
per timezone.

Cb

> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>                The basis of optimism is sheer terror.
>
>                          -- Oscar Wilde
>
>

From cb.list6 at gmail.com  Sun Sep 11 10:49:33 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sun, 11 Sep 2011 08:49:33 -0700
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
Message-ID: <CAD6AjGQHz9bG8vT8Ux4=Dm3PssdRUzPgKF94rLRUC37MFhDivQ@mail.gmail.com>

On Sep 10, 2011 11:38 PM, "Damian Menscher" <damian at google.com> wrote:
>
> On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>
> > On Fri, Sep 9, 2011 at 4:48 PM, Marcus Reid <marcus at blazingdot.com>
wrote:
> > > On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:
> > > I like this response; instant CA death penalty seems to put the
> > > incentives about where they need to be.
> >
> > I wouldn't necessarily count them dead just yet;  although their legit
> > customers must be very unhappy  waking up one day to find their
> > legitimate working SSL certs suddenly unusable....
> >
> > So DigiNotar lost their "browser trusted"  root CA status.  That
> > doesn't necessarily mean they will
> > be unable to get other root CAs to cross-sign CA certificates they
> > will make in the future, for the right price.
> >
> > A cross-sign with CA:TRUE  is  just as good as being installed in
> > users' browser.
> >
>
> The problem here wasn't just that DigiNotar was compromised, but that they
> didn't have an audit trail and attempted a coverup which resulted in real
> harm to users.  It will be difficult to re-gain the trust they lost.
>
> Because of that lost trust, any cross-signed cert would likely be revoked
by
> the browsers.  It would also make the browser vendors question whether the
> signing CA is worthy of their trust.
>

Yep. The CA business is one of trust. If the CA is not trusted, they are out
of business.

Cb

> Damian
> --
> Damian Menscher :: Security Reliability Engineer :: Google

From bjorn at mork.no  Sun Sep 11 10:55:43 2011
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Sun, 11 Sep 2011 17:55:43 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <CAD6AjGQHz9bG8vT8Ux4=Dm3PssdRUzPgKF94rLRUC37MFhDivQ@mail.gmail.com>
 (Cameron Byrne's message of "Sun, 11 Sep 2011 08:49:33 -0700")
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
 <CAD6AjGQHz9bG8vT8Ux4=Dm3PssdRUzPgKF94rLRUC37MFhDivQ@mail.gmail.com>
Message-ID: <87fwk3vzsw.fsf@nemi.mork.no>

Cameron Byrne <cb.list6 at gmail.com> writes:

> Yep. The CA business is one of trust. If the CA is not trusted, they are out
> of business.

You can rewrite that: Trust is the CA business.  Trust has a price.  If
the CA is not trusted, the price increases.

Yes, they may end up out of business because of that price jump, but you
should not neglect the fact that trust is for sale here.


Bj?rn


From joelja at bogus.com  Sun Sep 11 12:19:39 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Sun, 11 Sep 2011 10:19:39 -0700
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
 updates
In-Reply-To: <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
Message-ID: <4E6CEDAB.4070307@bogus.com>

On 9/10/11 23:30 , Damian Menscher wrote:
> On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> 
>> On Fri, Sep 9, 2011 at 4:48 PM, Marcus Reid <marcus at blazingdot.com> wrote:
>>> On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:
>>> I like this response; instant CA death penalty seems to put the
>>> incentives about where they need to be.
>>
>> I wouldn't necessarily count them dead just yet;  although their legit
>> customers must be very unhappy  waking up one day to find their
>> legitimate working SSL certs suddenly unusable....
>>
>> So DigiNotar lost their "browser trusted"  root CA status.  That
>> doesn't necessarily mean they will
>> be unable to get other root CAs to cross-sign CA certificates they
>> will make in the future, for the right price.
>>
>> A cross-sign with CA:TRUE  is  just as good as being installed in
>> users' browser.
>>
> 
> The problem here wasn't just that DigiNotar was compromised, but that they
> didn't have an audit trail and attempted a coverup which resulted in real
> harm to users.  It will be difficult to re-gain the trust they lost.
> 
> Because of that lost trust, any cross-signed cert would likely be revoked by
> the browsers.  It would also make the browser vendors question whether the
> signing CA is worthy of their trust.

To pop up the stack a bit it's the fact that an organization willing to
behave in that fashion was in my list of CA certs in the first place.
Yes they're blackballed now, better late than never I suppose. What does
that say about the potential for other CAs to behave in such a fashion?

> Damian



From sthaug at nethelp.no  Sun Sep 11 13:12:18 2011
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Sun, 11 Sep 2011 20:12:18 +0200 (CEST)
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <4E6CEDAB.4070307@bogus.com>
References: <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
 <4E6CEDAB.4070307@bogus.com>
Message-ID: <20110911.201218.74676712.sthaug@nethelp.no>

> To pop up the stack a bit it's the fact that an organization willing to
> behave in that fashion was in my list of CA certs in the first place.
> Yes they're blackballed now, better late than never I suppose. What does
> that say about the potential for other CAs to behave in such a fashion?

I'd say we have every reason to believe that something similar *will*
happen again :-(

Steinar Haug, Nethelp consulting, sthaug at nethelp.no


From jgreco at ns.sol.net  Sun Sep 11 13:34:43 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Sun, 11 Sep 2011 13:34:43 -0500 (CDT)
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <4E6CEDAB.4070307@bogus.com>
Message-ID: <201109111834.p8BIYhej061989@aurora.sol.net>

> > Because of that lost trust, any cross-signed cert would likely be revoked by
> > the browsers.  It would also make the browser vendors question whether the
> > signing CA is worthy of their trust.
> 
> To pop up the stack a bit it's the fact that an organization willing to
> behave in that fashion was in my list of CA certs in the first place.
> Yes they're blackballed now, better late than never I suppose. What does
> that say about the potential for other CAs to behave in such a fashion?

The average corporation much prefers to avoid the bad publicity and will
downplay most bad things.  Your favorite CA probably included.

I think that it's hard to cope with SSL.  It doesn't do the right things
for the right reasons.  Many of us, for example, operate local root CA's
for signing of "internal" stuff; all our company gear trusts our local
root CA and lots of stuff has certs issued by it.  In an ideal world,
this would mean that our gear talking to our gear is always secure, but
with other root CA's able to offer certs for our CN's, that isn't really
true.  That's frustrating.

The reality is that - for the average user -  SSL doesn't work well 
unless about 99% of the CA's used by the general public are included 
as "trusted."  If a popular site like Blooble has a cert by DigiNotar
and the Firerox browser is constantly asking what to do, nothing really
good comes out of that ...  either people think Firerox blows, or they
learn to click on the "ignore this" (or worse the "always trust this")
button.  In about 0.0% of the cases do they actually understand the
underlying trust issues.  So there's a great amount of pressure to
just make it magically work.

However, as the number of CA's accepted in most browsers increases, 
the security of the system as a whole decreases dramatically.  Yet
the market for $1000/year SSL certs is rather low, and the guys that
are charging bargain rates for low quality certs are perhaps doing
one good thing (enabling encryption) while simultaneously doing another
bad thing (destroying any "quality" in the system).  SSL is going to
have these problems as long as we maintain the current model.

In the long run, I expect all the CA's to behave something like this -
especially the ones that have more to lose if they were to become
suddenly "untrustworthy." 

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


From lgomes00 at gmail.com  Sun Sep 11 13:42:48 2011
From: lgomes00 at gmail.com (lgomes00 at gmail.com)
Date: Sun, 11 Sep 2011 15:42:48 -0300
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <4E6CEDAB.4070307@bogus.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
 <4E6CEDAB.4070307@bogus.com>
Message-ID: <CAM_fDmZnpk4mpgyg6E70+2XL0yrKkYJDLvv3nX7W0NNUKkmg-A@mail.gmail.com>

2011/9/11, Joel jaeggli <joelja at bogus.com>:
> On 9/10/11 23:30 , Damian Menscher wrote:
>> On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>>
>>> On Fri, Sep 9, 2011 at 4:48 PM, Marcus Reid <marcus at blazingdot.com>
>>> wrote:
>>>> On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:
>>>> I like this response; instant CA death penalty seems to put the
>>>> incentives about where they need to be.
>>>
>>> I wouldn't necessarily count them dead just yet;  although their legit
>>> customers must be very unhappy  waking up one day to find their
>>> legitimate working SSL certs suddenly unusable....
>>>
>>> So DigiNotar lost their "browser trusted"  root CA status.  That
>>> doesn't necessarily mean they will
>>> be unable to get other root CAs to cross-sign CA certificates they
>>> will make in the future, for the right price.
>>>
>>> A cross-sign with CA:TRUE  is  just as good as being installed in
>>> users' browser.
>>>
>>
>> The problem here wasn't just that DigiNotar was compromised, but that they
>> didn't have an audit trail and attempted a coverup which resulted in real
>> harm to users.  It will be difficult to re-gain the trust they lost.
>>
>> Because of that lost trust, any cross-signed cert would likely be revoked
>> by
>> the browsers.  It would also make the browser vendors question whether the
>> signing CA is worthy of their trust.
>
> To pop up the stack a bit it's the fact that an organization willing to
> behave in that fashion was in my list of CA certs in the first place.
> Yes they're blackballed now, better late than never I suppose. What does
> that say about the potential for other CAs to behave in such a fashion?
>
>> Damian
>
>
>

-- 
Enviado do meu celular

Luciano P.Gomes
http://lgomes00.blogspot.com/


From mike at mikejones.in  Sun Sep 11 13:44:20 2011
From: mike at mikejones.in (Mike Jones)
Date: Sun, 11 Sep 2011 19:44:20 +0100
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
Message-ID: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>

On 11 September 2011 16:55, Bj?rn Mork <bjorn at mork.no> wrote:
> You can rewrite that: Trust is the CA business. ?Trust has a price. ?If
> the CA is not trusted, the price increases.
>
> Yes, they may end up out of business because of that price jump, but you
> should not neglect the fact that trust is for sale here.
>

The CA model is fundamentally flawed in the fact that you have CAs
whose sole "trustworthiness" is the fact that they paid for an audit
(for Microsoft, lower requirements for others), they then issue
intermediate certificates to other companies (many web hosts and other
minor companies have them) whose sole "trustworthiness" is the fact
that they paid for an intermediate certificate, all of those
companies/organisations/people are then considered trustworthy enough
to confirm the identity of my web server despite the fact that none of
them have any connection at all to me or my website.

There is already a chain of trust down the DNS tree, if that is
compromised then my SSL is already compromised (if they control my
domain, they can "verify" they are me and get a certificate), what
happened to RFC4398 and other such proposals? EV certificates have a
different status and probably still need the CA model, however with
"standard" SSL certificates the only validation done these days is
checking someone has control over the domain. DNSSEC deployment is
advanced enough now to do that automatically at the client. We just
need browsers to start checking for certificates in DNS when making a
HTTPS connection (and if one is found do client side DNSSEC validation
- I don't trust my ISPs DNS servers to validate something like that,
considering they are the ones likely to be intercepting my connections
in the first place!).

It will take a while to get updated browsers rolled out to enough
users for it do be practical to start using DNS based self-signed
certificated instead of CA-Signed certificates, so why don't any
browsers have support yet? are any of them working on it?

- Mike


From richard.barnes at gmail.com  Sun Sep 11 13:47:03 2011
From: richard.barnes at gmail.com (Richard Barnes)
Date: Sun, 11 Sep 2011 14:47:03 -0400
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
Message-ID: <CACB24Mu3qCPmePUDWviQEHJ3qNCXH9+TEZ0XEQQ-0Ge5H58OAg@mail.gmail.com>

There's an app^W^Wa Working Group for that.
<http://tools.ietf.org/wg/dane/>

On Sun, Sep 11, 2011 at 2:44 PM, Mike Jones <mike at mikejones.in> wrote:
> On 11 September 2011 16:55, Bj?rn Mork <bjorn at mork.no> wrote:
>> You can rewrite that: Trust is the CA business. ?Trust has a price. ?If
>> the CA is not trusted, the price increases.
>>
>> Yes, they may end up out of business because of that price jump, but you
>> should not neglect the fact that trust is for sale here.
>>
>
> The CA model is fundamentally flawed in the fact that you have CAs
> whose sole "trustworthiness" is the fact that they paid for an audit
> (for Microsoft, lower requirements for others), they then issue
> intermediate certificates to other companies (many web hosts and other
> minor companies have them) whose sole "trustworthiness" is the fact
> that they paid for an intermediate certificate, all of those
> companies/organisations/people are then considered trustworthy enough
> to confirm the identity of my web server despite the fact that none of
> them have any connection at all to me or my website.
>
> There is already a chain of trust down the DNS tree, if that is
> compromised then my SSL is already compromised (if they control my
> domain, they can "verify" they are me and get a certificate), what
> happened to RFC4398 and other such proposals? EV certificates have a
> different status and probably still need the CA model, however with
> "standard" SSL certificates the only validation done these days is
> checking someone has control over the domain. DNSSEC deployment is
> advanced enough now to do that automatically at the client. We just
> need browsers to start checking for certificates in DNS when making a
> HTTPS connection (and if one is found do client side DNSSEC validation
> - I don't trust my ISPs DNS servers to validate something like that,
> considering they are the ones likely to be intercepting my connections
> in the first place!).
>
> It will take a while to get updated browsers rolled out to enough
> users for it do be practical to start using DNS based self-signed
> certificated instead of CA-Signed certificates, so why don't any
> browsers have support yet? are any of them working on it?
>
> - Mike
>
>


From kmedcalf at dessus.com  Sun Sep 11 14:00:09 2011
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 11 Sep 2011 13:00:09 -0600
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
Message-ID: <7798fc1cb3ee3c42bad613adb2f3dc6d@mail.dessus.com>

Damian Menscher wrote on 2011-09-11:

> Because of that lost trust, any cross-signed cert would likely be
> revoked by the browsers.  It would also make the browser vendors
> question whether the signing CA is worthy of their trust.

And therein is the root of the problem:  Trustworthiness is assessed by what you refer to as the "browser vendors".  Unfortunately, there is no Trustworthiness assessment of those vendors.

The current system provides no more authentication or confidentiality than if everyone simply used self-signed certificates.  It is nothing more than theatre and provides no actual security benefit whatsoever.  Anyone believing otherwise is operating under a delusion.

--- Keith Medcalf
()  ascii ribbon campaign against html e-mail
/\  www.asciiribbon.org






From Valdis.Kletnieks at vt.edu  Sun Sep 11 14:32:06 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 11 Sep 2011 15:32:06 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: Your message of "Sun, 11 Sep 2011 10:19:39 PDT."
 <4E6CEDAB.4070307@bogus.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
 <4E6CEDAB.4070307@bogus.com>
Message-ID: <146102.1315769526@turing-police.cc.vt.edu>

On Sun, 11 Sep 2011 10:19:39 PDT, Joel jaeggli said:

> To pop up the stack a bit it's the fact that an organization willing to
> behave in that fashion was in my list of CA certs in the first place.
> Yes they're blackballed now, better late than never I suppose. What does
> that say about the potential for other CAs to behave in such a fashion?

I'm sure at least one of the other 250-odd certificates from 100-ish CA's
trusted by most browsers now are actually trustworthy. There is no evidence at
all that the average CA is any less trustworthy than the average DNS registrar.

However, this isn't as big a problem as one might think - the *only* thing that
an SSL sert gives you is "you reached the host your browser tried to reach". It
does *not* validate "the host you intended to reach", or "whether you should
trust this host with your data", or any of a long set of interesting security
issues.  And that one question - "did you reach the host your browser tried
to reach" doesn't really mean much unless you have DNS and routing security
in place as well.  After all, if the IP you get for www.my-bank.com is incorrect,
or the route has been hijacked, what the cert says is pretty meaningless.

Considering that we seem to muddle along just fine with a DNS that doesn't
really do DNSSEC yet(*), and a lot of black and grey hat registrars out there,
and no real BGP security either,  maybe it isn't the "sky is falling" scenario
that a lot of people want to make it.

Or maybe we should all be even more worried. ;)

(*) Has anybody actually enabled "only accept DNSSEC-signed A records"
on an end user system and left it enabled for more than a day before
giving up in disgust? ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110911/d6afb299/attachment.bin>

From Valdis.Kletnieks at vt.edu  Sun Sep 11 14:37:36 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 11 Sep 2011 15:37:36 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: Your message of "Sun, 11 Sep 2011 13:00:09 MDT."
 <7798fc1cb3ee3c42bad613adb2f3dc6d@mail.dessus.com>
References: <7798fc1cb3ee3c42bad613adb2f3dc6d@mail.dessus.com>
Message-ID: <146257.1315769856@turing-police.cc.vt.edu>

On Sun, 11 Sep 2011 13:00:09 MDT, Keith Medcalf said:
> The current system provides no more authentication or confidentiality
> than if everyone simply used self-signed certificates.

Not strictly true.  The current system at least gives you "you have reached
the hostname your browser tried to reach".  A self-signed cert doesn't
even give you that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110911/bf502718/attachment.bin>

From aaron at heyaaron.com  Sun Sep 11 17:20:51 2011
From: aaron at heyaaron.com (Aaron C. de Bruyn)
Date: Sun, 11 Sep 2011 15:20:51 -0700
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CACB24Mu3qCPmePUDWviQEHJ3qNCXH9+TEZ0XEQQ-0Ge5H58OAg@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CACB24Mu3qCPmePUDWviQEHJ3qNCXH9+TEZ0XEQQ-0Ge5H58OAg@mail.gmail.com>
Message-ID: <CAEE+rGraOyVUKYDL16aGeLT7WrTy4V1gEcRM9QriiUBoRSED6A@mail.gmail.com>

I'm pretty fond of the idea proposed by gpgAuth.One key to rule them
all (and one password) combined with the client verifying the
server.It's still in its infancy, but it works.
-A
(Full disclosure: I work with the creator of gpgAuth in our day jobs)
On Sun, Sep 11, 2011 at 11:47, Richard Barnes <richard.barnes at gmail.com> wrote:
> There's an app^W^Wa Working Group for that.
> <http://tools.ietf.org/wg/dane/>
>
> On Sun, Sep 11, 2011 at 2:44 PM, Mike Jones <mike at mikejones.in> wrote:
>> On 11 September 2011 16:55, Bj?rn Mork <bjorn at mork.no> wrote:
>>> You can rewrite that: Trust is the CA business. ?Trust has a price. ?If
>>> the CA is not trusted, the price increases.
>>>
>>> Yes, they may end up out of business because of that price jump, but you
>>> should not neglect the fact that trust is for sale here.
>>>
>>
>> The CA model is fundamentally flawed in the fact that you have CAs
>> whose sole "trustworthiness" is the fact that they paid for an audit
>> (for Microsoft, lower requirements for others), they then issue
>> intermediate certificates to other companies (many web hosts and other
>> minor companies have them) whose sole "trustworthiness" is the fact
>> that they paid for an intermediate certificate, all of those
>> companies/organisations/people are then considered trustworthy enough
>> to confirm the identity of my web server despite the fact that none of
>> them have any connection at all to me or my website.
>>
>> There is already a chain of trust down the DNS tree, if that is
>> compromised then my SSL is already compromised (if they control my
>> domain, they can "verify" they are me and get a certificate), what
>> happened to RFC4398 and other such proposals? EV certificates have a
>> different status and probably still need the CA model, however with
>> "standard" SSL certificates the only validation done these days is
>> checking someone has control over the domain. DNSSEC deployment is
>> advanced enough now to do that automatically at the client. We just
>> need browsers to start checking for certificates in DNS when making a
>> HTTPS connection (and if one is found do client side DNSSEC validation
>> - I don't trust my ISPs DNS servers to validate something like that,
>> considering they are the ones likely to be intercepting my connections
>> in the first place!).
>>
>> It will take a while to get updated browsers rolled out to enough
>> users for it do be practical to start using DNS based self-signed
>> certificated instead of CA-Signed certificates, so why don't any
>> browsers have support yet? are any of them working on it?
>>
>> - Mike
>>
>>
>
>


From james.harr at gmail.com  Sun Sep 11 17:41:27 2011
From: james.harr at gmail.com (James Harr)
Date: Sun, 11 Sep 2011 17:41:27 -0500
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAEE+rGraOyVUKYDL16aGeLT7WrTy4V1gEcRM9QriiUBoRSED6A@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CACB24Mu3qCPmePUDWviQEHJ3qNCXH9+TEZ0XEQQ-0Ge5H58OAg@mail.gmail.com>
 <CAEE+rGraOyVUKYDL16aGeLT7WrTy4V1gEcRM9QriiUBoRSED6A@mail.gmail.com>
Message-ID: <CAEAFGYj4RjCPMXje1Vxt3g=9+CrBDGwThcfEouRQ6s7HfUUUKA@mail.gmail.com>

https://bugzilla.mozilla.org/show_bug.cgi?id=647959


--- SNIP ---
This is a request to add the CA root certificate for Honest Achmed's
Used Cars and Certificates.  The requested information as per the CA
information checklist is as follows:

1. Name
Honest Achmed's Used Cars and Certificates

2. Website URL
www.honestachmed.dyndns.org

3. Organizational type
Individual (Achmed, and possibly his cousin Mustafa, who knows a bit
about computers).

4. Primary market / customer base
Absolutely anyone who'll give us money.

5. Impact to Mozilla Users
Achmed's business plan is to sell a sufficiently large number of
certificates as quickly as possible in order to become too big to fail
(see "regulatory capture"), at which point most of the rest of this
application will become irrelevant.

--- SNIP ---



On Sun, Sep 11, 2011 at 5:20 PM, Aaron C. de Bruyn <aaron at heyaaron.com> wrote:
>
> I'm pretty fond of the idea proposed by gpgAuth.One key to rule them
> all (and one password) combined with the client verifying the
> server.It's still in its infancy, but it works.
> -A
> (Full disclosure: I work with the creator of gpgAuth in our day jobs)
> On Sun, Sep 11, 2011 at 11:47, Richard Barnes <richard.barnes at gmail.com> wrote:
> > There's an app^W^Wa Working Group for that.
> > <http://tools.ietf.org/wg/dane/>
> >
> > On Sun, Sep 11, 2011 at 2:44 PM, Mike Jones <mike at mikejones.in> wrote:
> >> On 11 September 2011 16:55, Bj?rn Mork <bjorn at mork.no> wrote:
> >>> You can rewrite that: Trust is the CA business. ?Trust has a price. ?If
> >>> the CA is not trusted, the price increases.
> >>>
> >>> Yes, they may end up out of business because of that price jump, but you
> >>> should not neglect the fact that trust is for sale here.
> >>>
> >>
> >> The CA model is fundamentally flawed in the fact that you have CAs
> >> whose sole "trustworthiness" is the fact that they paid for an audit
> >> (for Microsoft, lower requirements for others), they then issue
> >> intermediate certificates to other companies (many web hosts and other
> >> minor companies have them) whose sole "trustworthiness" is the fact
> >> that they paid for an intermediate certificate, all of those
> >> companies/organisations/people are then considered trustworthy enough
> >> to confirm the identity of my web server despite the fact that none of
> >> them have any connection at all to me or my website.
> >>
> >> There is already a chain of trust down the DNS tree, if that is
> >> compromised then my SSL is already compromised (if they control my
> >> domain, they can "verify" they are me and get a certificate), what
> >> happened to RFC4398 and other such proposals? EV certificates have a
> >> different status and probably still need the CA model, however with
> >> "standard" SSL certificates the only validation done these days is
> >> checking someone has control over the domain. DNSSEC deployment is
> >> advanced enough now to do that automatically at the client. We just
> >> need browsers to start checking for certificates in DNS when making a
> >> HTTPS connection (and if one is found do client side DNSSEC validation
> >> - I don't trust my ISPs DNS servers to validate something like that,
> >> considering they are the ones likely to be intercepting my connections
> >> in the first place!).
> >>
> >> It will take a while to get updated browsers rolled out to enough
> >> users for it do be practical to start using DNS based self-signed
> >> certificated instead of CA-Signed certificates, so why don't any
> >> browsers have support yet? are any of them working on it?
> >>
> >> - Mike
> >>
> >>
> >
> >
>



--
^[:wq^M


From Valdis.Kletnieks at vt.edu  Sun Sep 11 17:52:41 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 11 Sep 2011 18:52:41 -0400
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: Your message of "Sun, 11 Sep 2011 15:20:51 PDT."
 <CAEE+rGraOyVUKYDL16aGeLT7WrTy4V1gEcRM9QriiUBoRSED6A@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CACB24Mu3qCPmePUDWviQEHJ3qNCXH9+TEZ0XEQQ-0Ge5H58OAg@mail.gmail.com>
 <CAEE+rGraOyVUKYDL16aGeLT7WrTy4V1gEcRM9QriiUBoRSED6A@mail.gmail.com>
Message-ID: <151523.1315781561@turing-police.cc.vt.edu>

On Sun, 11 Sep 2011 15:20:51 PDT, "Aaron C. de Bruyn" said:
> I'm pretty fond of the idea proposed by gpgAuth.One key to rule them
> all (and one password) combined with the client verifying the
> server.It's still in its infancy, but it works.

Yes, but it needs to be something that either (a) Joe Sixpack never
sees, or (b) Joe Sixpack actually understands.  Are either of those
true?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110911/af79e03c/attachment.bin>

From mysidia at gmail.com  Sun Sep 11 18:02:03 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 11 Sep 2011 18:02:03 -0500
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
Message-ID: <CAAAwwbWj+CDFa6sYe+3fVfNtRLzBo8mz819xKRDoy9Sug-XYMw@mail.gmail.com>

On Sun, Sep 11, 2011 at 1:30 AM, Damian Menscher <damian at google.com> wrote:
> On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> Because of that lost trust, any cross-signed cert would likely be revoked by
> the browsers. ?It would also make the browser vendors question whether the

I am not engaging in speculation that DigiNotar plans to continue to
operate, they have already stated so much.
http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx
"VASCO does not expect that the DigiNotar security incident will have
a significant impact on the company?s future revenue or business
plans."

So long as DigiNotar can show what they are required to show when they
would request
re-signing, and another CA can legitimately cross-sign their cert,
following that CA's official
correct certification practices;  it's unlikely to lead to the signer
being revoked.

As far as we know, DigiNotar is not dead,  it is just a really great
example showing how broken TLS security model is.
The trust model hard-coded into the protocol is much weaker than the
cryptography.


Since the browsers already approved that root CA's certification
practices. Particularly not
if the cross-signer is one of the larger CAs such as  Thawte or Verisign   ---
the browser might as well  remove SSL support altogether, if they will
perform a revokation
that renders 40% of internet web server SSL certs invalid.

--
-JH


From aaron at heyaaron.com  Sun Sep 11 18:10:14 2011
From: aaron at heyaaron.com (Aaron C. de Bruyn)
Date: Sun, 11 Sep 2011 16:10:14 -0700
Subject: Why are we still using the CA model? (Re: Microsoft deems all
In-Reply-To: <151523.1315781561@turing-police.cc.vt.edu>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CACB24Mu3qCPmePUDWviQEHJ3qNCXH9+TEZ0XEQQ-0Ge5H58OAg@mail.gmail.com>
 <CAEE+rGraOyVUKYDL16aGeLT7WrTy4V1gEcRM9QriiUBoRSED6A@mail.gmail.com>
 <151523.1315781561@turing-police.cc.vt.edu>
Message-ID: <CAEE+rGrYofK4niMy1ydebRzcSGD4g04qdzaxH6Fwj9j4CkQJ2w@mail.gmail.com>

Neither at the moment--but it's close.

-A

On Sun, Sep 11, 2011 at 15:52,  <Valdis.Kletnieks at vt.edu> wrote:
> On Sun, 11 Sep 2011 15:20:51 PDT, "Aaron C. de Bruyn" said:
>> I'm pretty fond of the idea proposed by gpgAuth.One key to rule them
>> all (and one password) combined with the client verifying the
>> server.It's still in its infancy, but it works.
>
> Yes, but it needs to be something that either (a) Joe Sixpack never
> sees, or (b) Joe Sixpack actually understands. ?Are either of those
> true?
>


From damian at google.com  Sun Sep 11 18:23:29 2011
From: damian at google.com (Damian Menscher)
Date: Sun, 11 Sep 2011 16:23:29 -0700
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <CAAAwwbWj+CDFa6sYe+3fVfNtRLzBo8mz819xKRDoy9Sug-XYMw@mail.gmail.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
 <CAAAwwbWj+CDFa6sYe+3fVfNtRLzBo8mz819xKRDoy9Sug-XYMw@mail.gmail.com>
Message-ID: <CABSP1Oev36hUskLcs-VWf7JhApr3+HSPCBKrFyxWfXdNqX=hpg@mail.gmail.com>

On Sun, Sep 11, 2011 at 4:02 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Sun, Sep 11, 2011 at 1:30 AM, Damian Menscher <damian at google.com>
> wrote:
> > On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> > Because of that lost trust, any cross-signed cert would likely be revoked
> by
> > the browsers.  It would also make the browser vendors question whether
> the
>
> I am not engaging in speculation that DigiNotar plans to continue to
> operate, they have already stated so much.
>
> http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx
> "VASCO does not expect that the DigiNotar security incident will have
> a significant impact on the company?s future revenue or business
> plans."
>

I think you are misinterpreting that statement -- I interpret it as meaning
VASCO will continue to exist, and possibly buy another root CA to continue
their business plans.  (They had only recently acquired DigiNotar.)

Damian
-- 
Damian Menscher :: Security Reliability Engineer :: Google

From marka at isc.org  Sun Sep 11 18:25:23 2011
From: marka at isc.org (Mark Andrews)
Date: Mon, 12 Sep 2011 09:25:23 +1000
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: Your message of "Sun, 11 Sep 2011 15:32:06 -0400."
 <146102.1315769526@turing-police.cc.vt.edu>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
 <4E6CEDAB.4070307@bogus.com> <146102.1315769526@turing-police.cc.vt.edu>
Message-ID: <20110911232523.A0CD813F9322@drugs.dv.isc.org>


In message <146102.1315769526 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu
 writes:
> (*) Has anybody actually enabled "only accept DNSSEC-signed A records"
> on an end user system and left it enabled for more than a day before
> giving up in disgust? ;)

No.  But I run with "reject anything that doesn't validate" and
have for several years now and that doesn't suck.  We will never
be in a world where all DNS records validate unless we do DNSng and
that DNSng requires that all answers be signed.

Except as a academic exercise, I would never expect anyone would
configure a validator to require that all answers validate as secure.

DNSSEC gives you "provable secure", "provable insecure" and "bogus".

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


From morrowc.lists at gmail.com  Sun Sep 11 20:57:59 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 11 Sep 2011 21:57:59 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
References: <4e67991c.a4c7440a.7735.ffff9b25@mx.google.com>
 <20110909214804.GA88934@blazingdot.com>
 <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
Message-ID: <CAL9jLabt0UBd=d6xK66SQ2SCv7WP_Ax1oV5HaRcSxpBCdUhqQA@mail.gmail.com>

somewhat rhetorically...

On Sun, Sep 11, 2011 at 2:30 AM, Damian Menscher <damian at google.com> wrote:

> Because of that lost trust, any cross-signed cert would likely be revoked by
> the browsers. ?It would also make the browser vendors question whether the
> signing CA is worthy of their trust.

given a list of ca's and certs to invalidate ... how large a list
would be practical in a browser? (baked in I mean)
  (not very, relative to the size of the domain system today)
Is this scalable?
  (no)
Is this the only answer we have left?
  (no)

-chris
(I'm not sure what better answers there are to the situation we are in
today, I do like the work in DANE-WG though... it'll be a while before
it's practical to use though, I fear)


From morrowc.lists at gmail.com  Sun Sep 11 21:01:47 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 11 Sep 2011 22:01:47 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <146257.1315769856@turing-police.cc.vt.edu>
References: <7798fc1cb3ee3c42bad613adb2f3dc6d@mail.dessus.com>
 <146257.1315769856@turing-police.cc.vt.edu>
Message-ID: <CAL9jLaZL8UygQjjcvaCbpW0qBqnSrygJb6HQTK4gh=NH45aCAg@mail.gmail.com>

On Sun, Sep 11, 2011 at 3:37 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Sun, 11 Sep 2011 13:00:09 MDT, Keith Medcalf said:
>> The current system provides no more authentication or confidentiality
>> than if everyone simply used self-signed certificates.
>
> Not strictly true. ?The current system at least gives you "you have reached
> the hostname your browser tried to reach". ?A self-signed cert doesn't
> even give you that.

really? even in the face of CA's that have signed certs for existing
domains (to not the domain owners)?

If I have a thawte cert for valdis.com on host A and one from comodo
on host B... which is the right one?


From morrowc.lists at gmail.com  Sun Sep 11 21:08:45 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 11 Sep 2011 22:08:45 -0400
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
Message-ID: <CAL9jLaZC=UCAmMSKGSZcNcD+ijODKCR8n3Lks-Ydjy6rDq-fvg@mail.gmail.com>

On Sun, Sep 11, 2011 at 2:44 PM, Mike Jones <mike at mikejones.in> wrote:
> EV certificates have a
> different status and probably still need the CA model

what's the real benefit of an EV cert? (to the service owner, not the
CA, the CA benefit is pretty clearly $$)

-chris
(I've never seen the value in EV or even DV certs really... so I'm
actually curious what the value other see in them is)


From mysidia at gmail.com  Sun Sep 11 21:23:30 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 11 Sep 2011 21:23:30 -0500
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAL9jLaZC=UCAmMSKGSZcNcD+ijODKCR8n3Lks-Ydjy6rDq-fvg@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAL9jLaZC=UCAmMSKGSZcNcD+ijODKCR8n3Lks-Ydjy6rDq-fvg@mail.gmail.com>
Message-ID: <CAAAwwbVcRq8q8C6y4zYZkovmL6HwB1O6Fif0KtKC_355SdsnmQ@mail.gmail.com>

On Sun, Sep 11, 2011 at 9:08 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:

> what's the real benefit of an EV cert? (to the service owner, not the
> CA, the CA benefit is pretty clearly $$)

The benefit is to the end user.
They see a green address bar  with the company's name displayed.

Yeah, company's name displayed -- individuals cannot apply for EVSSL certs.


With normal certs, the end user doesn't see a green address bar, and
instead of the company's
name displayed "(unknown)" is displayed and
"This web site does not supply ownership information."  is displayed.

If you ask me, hiding the company's name even when present on a non-EVSSL
cert is tantamount to saying  "Only EV-SSL certs are really trusted anyways".

So maybe  instead of these shenanigans browser makers should have just
started displaying a "don't trust this site" warning for any non-EVSSL cert.

--
-JH


From morrowc.lists at gmail.com  Sun Sep 11 21:43:46 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 11 Sep 2011 22:43:46 -0400
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAAAwwbVcRq8q8C6y4zYZkovmL6HwB1O6Fif0KtKC_355SdsnmQ@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAL9jLaZC=UCAmMSKGSZcNcD+ijODKCR8n3Lks-Ydjy6rDq-fvg@mail.gmail.com>
 <CAAAwwbVcRq8q8C6y4zYZkovmL6HwB1O6Fif0KtKC_355SdsnmQ@mail.gmail.com>
Message-ID: <CAL9jLaYYp9CK4kjdUZwae4PTGmQXEzm9UQp2oL9hkNFUMJotKg@mail.gmail.com>

On Sun, Sep 11, 2011 at 10:23 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Sun, Sep 11, 2011 at 9:08 PM, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
>
>> what's the real benefit of an EV cert? (to the service owner, not the
>> CA, the CA benefit is pretty clearly $$)
>
> The benefit is to the end user.
> They see a green address bar ?with the company's name displayed.
>
> Yeah, company's name displayed -- individuals cannot apply for EVSSL certs.
>

this isn't really a benefit though, is it? isn't the domain-name in
the location bar doing the same thing?


From SHughes at GREnergy.com  Sun Sep 11 22:06:04 2011
From: SHughes at GREnergy.com (Hughes, Scott GRE-MG)
Date: Sun, 11 Sep 2011 22:06:04 -0500
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAL9jLaYYp9CK4kjdUZwae4PTGmQXEzm9UQp2oL9hkNFUMJotKg@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAL9jLaZC=UCAmMSKGSZcNcD+ijODKCR8n3Lks-Ydjy6rDq-fvg@mail.gmail.com>
 <CAAAwwbVcRq8q8C6y4zYZkovmL6HwB1O6Fif0KtKC_355SdsnmQ@mail.gmail.com>
 <CAL9jLaYYp9CK4kjdUZwae4PTGmQXEzm9UQp2oL9hkNFUMJotKg@mail.gmail.com>
Message-ID: <221E581B-206F-4BFF-92FF-EB0761C42CA3@GREnergy.com>

On Sep 11, 2011, at 9:44 PM, "Christopher Morrow" <morrowc.lists at gmail.com> wrote:

> On Sun, Sep 11, 2011 at 10:23 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>> On Sun, Sep 11, 2011 at 9:08 PM, Christopher Morrow
>> <morrowc.lists at gmail.com> wrote:
>> 
>>> what's the real benefit of an EV cert? (to the service owner, not the
>>> CA, the CA benefit is pretty clearly $$)
>> 
>> The benefit is to the end user.
>> They see a green address bar  with the company's name displayed.
>> 
>> Yeah, company's name displayed -- individuals cannot apply for EVSSL certs.
>> 
> 
> this isn't really a benefit though, is it? isn't the domain-name in
> the location bar doing the same thing?

No. As a counter example... How may domain names do Wells Fargo and Citibank (Citi Corp? Citi Group?) operate respectively? I'm a customer, and I can't keep it straight. 

Companies that wrap their services with generic domain names (paymybills.com and the like) have no one to blame but themselves when they are targeted by scammers and phishing schemes. Even EV certificates don't help when consumers are blinded by subsidiary companies and sister companies daily (Motorola Mobility a.k.a. Google vs. Motorola Solutions.)


NOTICE TO RECIPIENT: The information contained in this message from
Great River Energy and any attachments are confidential and intended
only for the named recipient(s). If you have received this message in 
error, you are prohibited from copying, distributing or using the
information. Please contact the sender immediately by return email and
delete the original message.


 



From morrowc.lists at gmail.com  Sun Sep 11 22:28:03 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 11 Sep 2011 23:28:03 -0400
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <221E581B-206F-4BFF-92FF-EB0761C42CA3@GREnergy.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAL9jLaZC=UCAmMSKGSZcNcD+ijODKCR8n3Lks-Ydjy6rDq-fvg@mail.gmail.com>
 <CAAAwwbVcRq8q8C6y4zYZkovmL6HwB1O6Fif0KtKC_355SdsnmQ@mail.gmail.com>
 <CAL9jLaYYp9CK4kjdUZwae4PTGmQXEzm9UQp2oL9hkNFUMJotKg@mail.gmail.com>
 <221E581B-206F-4BFF-92FF-EB0761C42CA3@GREnergy.com>
Message-ID: <CAL9jLaaxMwCZAV4WBmEg5b72L=L57=ypv5ToEURgZgB9odnKMQ@mail.gmail.com>

On Sun, Sep 11, 2011 at 11:06 PM, Hughes, Scott GRE-MG
<SHughes at grenergy.com> wrote:
> Companies that wrap their services with generic domain names (paymybills.com and the like) have no one to blame but themselves when they are targeted by scammers and phishing schemes. Even EV certificates don't help when consumers are blinded by subsidiary companies and sister companies daily (Motorola Mobility a.k.a. Google vs. Motorola Solutions.)

So, part of my point here about ev/dv/etc certs is that in almost all
cases of consumer fraud and protection, HTTPS is never used. Hell,
half the spams I get are
http://IP_ADDRESS/somethign/something/something.php ... Falling back
on the 'well ev certs are there to provide protection to the consumer'
is just FUD (I think).

again, not seeing a benefit here...

-chris


From william.allen.simpson at gmail.com  Sun Sep 11 22:51:17 2011
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Sun, 11 Sep 2011 23:51:17 -0400
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAL9jLaaxMwCZAV4WBmEg5b72L=L57=ypv5ToEURgZgB9odnKMQ@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAL9jLaZC=UCAmMSKGSZcNcD+ijODKCR8n3Lks-Ydjy6rDq-fvg@mail.gmail.com>
 <CAAAwwbVcRq8q8C6y4zYZkovmL6HwB1O6Fif0KtKC_355SdsnmQ@mail.gmail.com>
 <CAL9jLaYYp9CK4kjdUZwae4PTGmQXEzm9UQp2oL9hkNFUMJotKg@mail.gmail.com>
 <221E581B-206F-4BFF-92FF-EB0761C42CA3@GREnergy.com>
 <CAL9jLaaxMwCZAV4WBmEg5b72L=L57=ypv5ToEURgZgB9odnKMQ@mail.gmail.com>
Message-ID: <4E6D81B5.60801@gmail.com>

On 9/11/11 11:28 PM, Christopher Morrow wrote:
> On Sun, Sep 11, 2011 at 11:06 PM, Hughes, Scott GRE-MG
> <SHughes at grenergy.com>  wrote:
>> Companies that wrap their services with generic domain names (paymybills.com and the like) have no one to blame but themselves when they are targeted by scammers and phishing schemes. Even EV certificates don't help when consumers are blinded by subsidiary companies and sister companies daily (Motorola Mobility a.k.a. Google vs. Motorola Solutions.)
>
> So, part of my point here about ev/dv/etc certs is that in almost all
> cases of consumer fraud and protection, HTTPS is never used. Hell,
> half the spams I get are
> http://IP_ADDRESS/somethign/something/something.php ... Falling back
> on the 'well ev certs are there to provide protection to the consumer'
> is just FUD (I think).
>
> again, not seeing a benefit here...
>
Normally, I heart my Mac.  But Apple in its infinite wisdom decided that
EV certificates are so much better, they refused to honor my edit of my
own system keychain!

So, negative benefit for the consumer.


From marcus at blazingdot.com  Sun Sep 11 23:39:52 2011
From: marcus at blazingdot.com (Marcus Reid)
Date: Mon, 12 Sep 2011 04:39:52 +0000
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <201109111834.p8BIYhej061989@aurora.sol.net>
References: <4E6CEDAB.4070307@bogus.com>
 <201109111834.p8BIYhej061989@aurora.sol.net>
Message-ID: <20110912043952.GA92788@blazingdot.com>

On Sun, Sep 11, 2011 at 01:34:43PM -0500, Joe Greco wrote:
> > > Because of that lost trust, any cross-signed cert would likely be revoked by
> > > the browsers.  It would also make the browser vendors question whether the
> > > signing CA is worthy of their trust.
> > 
> > To pop up the stack a bit it's the fact that an organization willing to
> > behave in that fashion was in my list of CA certs in the first place.
> > Yes they're blackballed now, better late than never I suppose. What does
> > that say about the potential for other CAs to behave in such a fashion?
> 
> The average corporation much prefers to avoid the bad publicity and will
> downplay most bad things.  Your favorite CA probably included.
> 
> I think that it's hard to cope with SSL.  It doesn't do the right things
> for the right reasons.  Many of us, for example, operate local root CA's
> for signing of "internal" stuff; all our company gear trusts our local
> root CA and lots of stuff has certs issued by it.  In an ideal world,
> this would mean that our gear talking to our gear is always secure, but
> with other root CA's able to offer certs for our CN's, that isn't really
> true.  That's frustrating.

You don't have to have the big fat Mozilla root cert bundle on your
machines.  Some OSes "ship" with an empty /etc/ssl, nobody tells you who
you trust.

> The reality is that - for the average user -  SSL doesn't work well 
> unless about 99% of the CA's used by the general public are included 
> as "trusted."  If a popular site like Blooble has a cert by DigiNotar
> and the Firerox browser is constantly asking what to do, nothing really
> good comes out of that ...  either people think Firerox blows, or they
> learn to click on the "ignore this" (or worse the "always trust this")
> button.  In about 0.0% of the cases do they actually understand the
> underlying trust issues.  So there's a great amount of pressure to
> just make it magically work.

How about a TXT record with the CN string of the CA cert subject in it?
If it exists and there's a conflict, don't trust it.  Seems simple
enough to implement without too much collateral damage.

> However, as the number of CA's accepted in most browsers increases, 
> the security of the system as a whole decreases dramatically.  Yet
> the market for $1000/year SSL certs is rather low, and the guys that
> are charging bargain rates for low quality certs are perhaps doing
> one good thing (enabling encryption) while simultaneously doing another
> bad thing (destroying any "quality" in the system).  SSL is going to
> have these problems as long as we maintain the current model.

I like the added "chrome" that the new browsers have for EV certs, but
users need to be stabbed in the face, green vs. blue doesn't really do
it.

> In the long run, I expect all the CA's to behave something like this -
> especially the ones that have more to lose if they were to become
> suddenly "untrustworthy." 

Yes, how do you think Verisign/Thawte/Symantec would behave if they
found that their keys were compromised?  They might do the right thing,
because they're not stupid enough to think they could get away with
trying to cover it up.  What would the browser vendors do in that case?
I hope there's a contingency plan, and if there is it seems like it
should be made public.

Marcus


From hank at efes.iucc.ac.il  Mon Sep 12 00:22:46 2011
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Mon, 12 Sep 2011 08:22:46 +0300
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <7798fc1cb3ee3c42bad613adb2f3dc6d@mail.dessus.com>
Message-ID: <5.1.0.14.2.20110912080438.037715e8@efes.iucc.ac.il>

At 13:00 11/09/2011 -0600, Keith Medcalf wrote:
>Damian Menscher wrote on 2011-09-11:
>
> > Because of that lost trust, any cross-signed cert would likely be
> > revoked by the browsers.  It would also make the browser vendors
> > question whether the signing CA is worthy of their trust.
>
>And therein is the root of the problem:  Trustworthiness is assessed by 
>what you refer to as the "browser vendors".  Unfortunately, there is no 
>Trustworthiness assessment of those vendors.
>
>The current system provides no more authentication or confidentiality than 
>if everyone simply used self-signed certificates.  It is nothing more than 
>theatre and provides no actual security benefit whatsoever.  Anyone 
>believing otherwise is operating under a delusion.

The problem is about lack of pen-testing and a philosphy of security.  In 
order to run a CA, one not only has to build the infrastructure but also 
have constant external pen-testing and patch management in place.  Whether 
it be Comodo or RSA or now Diginotar, unless an overwhelming philosphy of 
"computer and network security" is paradigmed into the corporate DNA, this 
will keep happening - and not only to CAs but to the likes of Google, 
Cisco, Microsoft, etc. (read - APT attacks).

If 60% of your employees will plug in a USB drive they find in the parking 
lot, then you have failed:
http://www.bloomberg.com/news/2011-06-27/human-errors-fuel-hacking-as-test-shows-nothing-prevents-idiocy.html

The problem for us as a community if to find a benchmark of which company 
"does have a clue" vs those that don't.  Until then, it will just be 
whack-a-mole/CA.

-Hank






>--- Keith Medcalf
>()  ascii ribbon campaign against html e-mail
>/\  www.asciiribbon.org



From Valdis.Kletnieks at vt.edu  Mon Sep 12 03:39:03 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 12 Sep 2011 04:39:03 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: Your message of "Mon, 12 Sep 2011 04:39:52 -0000."
 <20110912043952.GA92788@blazingdot.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109111834.p8BIYhej061989@aurora.sol.net>
 <20110912043952.GA92788@blazingdot.com>
Message-ID: <167272.1315816743@turing-police.cc.vt.edu>

On Mon, 12 Sep 2011 04:39:52 -0000, Marcus Reid said:

> You don't have to have the big fat Mozilla root cert bundle on your
> machines.  Some OSes "ship" with an empty /etc/ssl, nobody tells you who
> you trust.

And for those OS's (who are they, anyhow) that ship empty bundles,
how many CAs do you end up trusting anyhow?

> How about a TXT record with the CN string of the CA cert subject in it?
> If it exists and there's a conflict, don't trust it.  Seems simple
> enough to implement without too much collateral damage.

Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
to attacks via DNS poisoning (either insert a malicious TXT that matches your
malicious certificate, or insert a malicious TXT that intentionally *doesn't* match
the vicitm's certificate)....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110912/58600663/attachment.bin>

From Valdis.Kletnieks at vt.edu  Mon Sep 12 03:39:23 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 12 Sep 2011 04:39:23 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: Your message of "Sun, 11 Sep 2011 22:01:47 EDT."
 <CAL9jLaZL8UygQjjcvaCbpW0qBqnSrygJb6HQTK4gh=NH45aCAg@mail.gmail.com>
References: <7798fc1cb3ee3c42bad613adb2f3dc6d@mail.dessus.com>
 <146257.1315769856@turing-police.cc.vt.edu>
 <CAL9jLaZL8UygQjjcvaCbpW0qBqnSrygJb6HQTK4gh=NH45aCAg@mail.gmail.com>
Message-ID: <167290.1315816763@turing-police.cc.vt.edu>

On Sun, 11 Sep 2011 22:01:47 EDT, Christopher Morrow said:
> If I have a thawte cert for valdis.com on host A and one from comodo
> on host B... which is the right one?

You wouldn't have 2 certs for that... I'd have *one* cert for that. And if when
you got to the IP address you were trying to reach, the cert didn't validate as
matching the hostname, you know something fishy is up.

And if you *do* have two certs for it, I'd like to talk to the bozos at
Thawte and Comodo who obviously didn't check the paperwork. ;)



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

From lear at cisco.com  Mon Sep 12 04:30:34 2011
From: lear at cisco.com (Eliot Lear)
Date: Mon, 12 Sep 2011 11:30:34 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
 updates
In-Reply-To: <5.1.0.14.2.20110912080438.037715e8@efes.iucc.ac.il>
References: <5.1.0.14.2.20110912080438.037715e8@efes.iucc.ac.il>
Message-ID: <4E6DD13A.9050003@cisco.com>

Hank and everyone,

This is a very interesting problem.  As it happens, some folks in the
IETF have anticipated this one.  For those who are interested, Paul
Hoffman and Jakob Schlyter have been working within the DANE working
group at the IETF to provide for a means to alleviate some of the
responsibility of the browser vendors as to who gets to decide what is a
valid certificate, by allowing for that burden to be shifted to the
subject through the use of secure DNS.  A list of hashes is published in
the subject's domain indicating what are valid certificates.  And so if
a CA went rogue, the subject domains would be able to indicate to the
browser that something is afoot.  For more information, please see
http://datatracker.ietf.org/wg/dane/.

Eliot

On 9/12/11 7:22 AM, Hank Nussbacher wrote:
> At 13:00 11/09/2011 -0600, Keith Medcalf wrote:
>> Damian Menscher wrote on 2011-09-11:
>>
>> > Because of that lost trust, any cross-signed cert would likely be
>> > revoked by the browsers.  It would also make the browser vendors
>> > question whether the signing CA is worthy of their trust.
>>
>> And therein is the root of the problem:  Trustworthiness is assessed
>> by what you refer to as the "browser vendors".  Unfortunately, there
>> is no Trustworthiness assessment of those vendors.
>>
>> The current system provides no more authentication or confidentiality
>> than if everyone simply used self-signed certificates.  It is nothing
>> more than theatre and provides no actual security benefit
>> whatsoever.  Anyone believing otherwise is operating under a delusion.
>
> The problem is about lack of pen-testing and a philosphy of security. 
> In order to run a CA, one not only has to build the infrastructure but
> also have constant external pen-testing and patch management in
> place.  Whether it be Comodo or RSA or now Diginotar, unless an
> overwhelming philosphy of "computer and network security" is
> paradigmed into the corporate DNA, this will keep happening - and not
> only to CAs but to the likes of Google, Cisco, Microsoft, etc. (read -
> APT attacks).
>
> If 60% of your employees will plug in a USB drive they find in the
> parking lot, then you have failed:
> http://www.bloomberg.com/news/2011-06-27/human-errors-fuel-hacking-as-test-shows-nothing-prevents-idiocy.html
>
>
> The problem for us as a community if to find a benchmark of which
> company "does have a clue" vs those that don't.  Until then, it will
> just be whack-a-mole/CA.
>
> -Hank
>
>
>
>
>
>
>> --- Keith Medcalf
>> ()  ascii ribbon campaign against html e-mail
>> /\  www.asciiribbon.org
>
>
>


From fredan-nanog at fredan.se  Mon Sep 12 04:46:04 2011
From: fredan-nanog at fredan.se (fredrik danerklint)
Date: Mon, 12 Sep 2011 11:46:04 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <167272.1315816743@turing-police.cc.vt.edu>
References: <4E6CEDAB.4070307@bogus.com>
 <20110912043952.GA92788@blazingdot.com>
 <167272.1315816743@turing-police.cc.vt.edu>
Message-ID: <201109121146.04313.fredan-nanog@fredan.se>

> > How about a TXT record with the CN string of the CA cert subject in it?
> > If it exists and there's a conflict, don't trust it.  Seems simple
> > enough to implement without too much collateral damage.
> 
> Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
> to attacks via DNS poisoning (either insert a malicious TXT that matches
> your malicious certificate, or insert a malicious TXT that intentionally
> *doesn't* match the vicitm's certificate)....

And how do you validate the dnssec to make sure that noone has tampered with 
it.

-- 
//fredan


From millnert at gmail.com  Mon Sep 12 05:12:08 2011
From: millnert at gmail.com (Martin Millnert)
Date: Mon, 12 Sep 2011 12:12:08 +0200
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
Message-ID: <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>

Mike,

On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones <mike at mikejones.in> wrote:
> It will take a while to get updated browsers rolled out to enough
> users for it do be practical to start using DNS based self-signed
> certificated instead of CA-Signed certificates, so why don't any
> browsers have support yet? are any of them working on it?

Chrome v 14 works with DNS stapled certificates, sort of a hack. (
http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )

There are other proposals/ideas out there, completely different to
DANE / DNSSEC, like http://perspectives-project.org/ /
http://convergence.io/ .

Regard,
Martin


From greg at bestnet.kharkov.ua  Mon Sep 12 06:23:17 2011
From: greg at bestnet.kharkov.ua (Gregory Edigarov)
Date: Mon, 12 Sep 2011 14:23:17 +0300
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
Message-ID: <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>

On Mon, 12 Sep 2011 12:12:08 +0200
Martin Millnert <millnert at gmail.com> wrote:

> Mike,
> 
> On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones <mike at mikejones.in> wrote:
> > It will take a while to get updated browsers rolled out to enough
> > users for it do be practical to start using DNS based self-signed
> > certificated instead of CA-Signed certificates, so why don't any
> > browsers have support yet? are any of them working on it?
> 
> Chrome v 14 works with DNS stapled certificates, sort of a hack. (
> http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )
> 
> There are other proposals/ideas out there, completely different to
> DANE / DNSSEC, like http://perspectives-project.org/ /
> http://convergence.io/ .

I.e. instead of a set of trusted CAs there will be one distributed net
of servers, that act as a cert storage?
I do not see how that could help...
Well, I do not even see how can one trust any certificate that is
issued by commercial organization. 


-- 
With best regards,
	Gregory Edigarov


From millnert at gmail.com  Mon Sep 12 06:32:40 2011
From: millnert at gmail.com (Martin Millnert)
Date: Mon, 12 Sep 2011 13:32:40 +0200
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
Message-ID: <CAHyNd16fmspfS3=KFBozJYqhxas8VoDnOmmgP-Y2n8-onNOJgQ@mail.gmail.com>

Gregory,

On Mon, Sep 12, 2011 at 1:23 PM, Gregory Edigarov
<greg at bestnet.kharkov.ua> wrote:
> On Mon, 12 Sep 2011 12:12:08 +0200
> Martin Millnert <millnert at gmail.com> wrote:
>
>> Mike,
>>
>> On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones <mike at mikejones.in> wrote:
>> > It will take a while to get updated browsers rolled out to enough
>> > users for it do be practical to start using DNS based self-signed
>> > certificated instead of CA-Signed certificates, so why don't any
>> > browsers have support yet? are any of them working on it?
>>
>> Chrome v 14 works with DNS stapled certificates, sort of a hack. (
>> http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )
>>
>> There are other proposals/ideas out there, completely different to
>> DANE / DNSSEC, like http://perspectives-project.org/ /
>> http://convergence.io/ .
>
> I.e. instead of a set of trusted CAs there will be one distributed net
> of servers, that act as a cert storage?
> I do not see how that could help...
> Well, I do not even see how can one trust any certificate that is
> issued by commercial organization.


As I understand it the idea is that you would have the
power/capability to assign trust yourself to friends, CAs and your
cat.  This then forms some form of (washed out word-warning) web of
trust, when you connect up with others and get their
one-step-away-trust imported.


Outsourcing trust is a pretty hard problem... there's no way to get
around it, really, so this approach (as per my limited research) at
least gives you some power to control it.

Regards,
Martin


From jgreco at ns.sol.net  Mon Sep 12 06:52:50 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Mon, 12 Sep 2011 06:52:50 -0500 (CDT)
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <20110912043952.GA92788@blazingdot.com>
Message-ID: <201109121152.p8CBqocU075272@aurora.sol.net>

> > I think that it's hard to cope with SSL.  It doesn't do the right things
> > for the right reasons.  Many of us, for example, operate local root CA's
> > for signing of "internal" stuff; all our company gear trusts our local
> > root CA and lots of stuff has certs issued by it.  In an ideal world,
> > this would mean that our gear talking to our gear is always secure, but
> > with other root CA's able to offer certs for our CN's, that isn't really
> > true.  That's frustrating.
> 
> You don't have to have the big fat Mozilla root cert bundle on your
> machines.  Some OSes "ship" with an empty /etc/ssl, nobody tells you who
> you trust.

You don't have to have a web browser on your machines, either.  Also
solves the problem FSVO "solves."

Users don't really want to figure out SSL, and we shouldn't *want* them
to have to figure out SSL.  When your grandfolks (or parents or whatever)
connect up to the Internet with a PC, they just sort of expect that things
will work.  We should have found a way to make that happen - instead we
gave them SSL.  :-)

> > The reality is that - for the average user -  SSL doesn't work well 
> > unless about 99% of the CA's used by the general public are included 
> > as "trusted."  If a popular site like Blooble has a cert by DigiNotar
> > and the Firerox browser is constantly asking what to do, nothing really
> > good comes out of that ...  either people think Firerox blows, or they
> > learn to click on the "ignore this" (or worse the "always trust this")
> > button.  In about 0.0% of the cases do they actually understand the
> > underlying trust issues.  So there's a great amount of pressure to
> > just make it magically work.
> 
> How about a TXT record with the CN string of the CA cert subject in it?
> If it exists and there's a conflict, don't trust it.  Seems simple
> enough to implement without too much collateral damage.

I don't know.  It may have some potential.

> > However, as the number of CA's accepted in most browsers increases, 
> > the security of the system as a whole decreases dramatically.  Yet
> > the market for $1000/year SSL certs is rather low, and the guys that
> > are charging bargain rates for low quality certs are perhaps doing
> > one good thing (enabling encryption) while simultaneously doing another
> > bad thing (destroying any "quality" in the system).  SSL is going to
> > have these problems as long as we maintain the current model.
> 
> I like the added "chrome" that the new browsers have for EV certs, but
> users need to be stabbed in the face, green vs. blue doesn't really do
> it.

Perhaps what we need is to stab some Internet folks in the face too,
though, for allowing the perpetuation of Much Badness(tm).  We might
really be better off, for example, if we could get a ".bank" TLD that
was operated in a rational manner, where only the bank's proper name
was registered, all websites had to run as subdomains, and SSL certs
for .bank could only be issued by ... well maybe even just one CA, or
at most two or three.

I mean, there's still so much wrong with that model too, but it has
some more-correct things built into it.

> > In the long run, I expect all the CA's to behave something like this -
> > especially the ones that have more to lose if they were to become
> > suddenly "untrustworthy." 
> 
> Yes, how do you think Verisign/Thawte/Symantec would behave if they
> found that their keys were compromised?  They might do the right thing,
> because they're not stupid enough to think they could get away with
> trying to cover it up. 

Wow, you're ... pleasantly naive? (not meant as an insult AT ALL!)  Or 
maybe I'm just hopelessly cynical.  But I do see that as naive; I expect
that at a minimum the spin machine would be running at full tilt and
it would be downplayed as much as possible.

> What would the browser vendors do in that case?

Interesting question.

> I hope there's a contingency plan, and if there is it seems like it
> should be made public.

Okay.  :-)

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


From coy.hile at coyhile.com  Mon Sep 12 07:08:56 2011
From: coy.hile at coyhile.com (Coy Hile)
Date: Mon, 12 Sep 2011 12:08:56 +0000
Subject: EV SSL Certs
Message-ID: <CAJS2yDtaDeEftM=kxZFc+fC5F2d8EjJoK0NrrWVYSChBQvfqYw@mail.gmail.com>

>
> On Sun, Sep 11, 2011 at 9:08 PM, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
>
>> what's the real benefit of an EV cert? (to the service owner, not the
>> CA, the CA benefit is pretty clearly $$)
>
> The benefit is to the end user.
> They see a green address bar ?with the company's name displayed.
>
> Yeah, company's name displayed -- individuals cannot apply for EVSSL certs.
>
>
> With normal certs, the end user doesn't see a green address bar, and
> instead of the company's
> name displayed "(unknown)" is displayed and
> "This web site does not supply ownership information." ?is displayed.
>
> If you ask me, hiding the company's name even when present on a non-EVSSL
> cert is tantamount to saying ?"Only EV-SSL certs are really trusted anyways".
>
> So maybe ?instead of these shenanigans browser makers should have just
> started displaying a "don't trust this site" warning for any non-EVSSL cert.
>

As an academic aside, exactly what would one set on his (internal)
root CA so that internally-trusted certs signed by that CA would show
up as EV certs?


From leigh.porter at ukbroadband.com  Mon Sep 12 08:36:53 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 12 Sep 2011 13:36:53 +0000
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Gregory Edigarov [mailto:greg at bestnet.kharkov.ua]
> I.e. instead of a set of trusted CAs there will be one distributed net
> of servers, that act as a cert storage?
> I do not see how that could help...
> Well, I do not even see how can one trust any certificate that is
> issued by commercial organization.
> 

There should be a government body to issue certificates then ;-)

But Gregory is right, you cannot really trust anybody completely. Even the larger and more respectable commercial organisations will be unable to resist <insert intel organisation here> when they ask for dodgy certs so they can intercept something..

No, as soon as you have somebody who is not yourself in control without any third party verifiably independent oversight then you have to carefully define what you mean by trust.

--
Leigh Porter


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From cody at killsudo.info  Mon Sep 12 08:37:19 2011
From: cody at killsudo.info (Cody Rose)
Date: Mon, 12 Sep 2011 08:37:19 -0500
Subject: EV SSL Certs
In-Reply-To: <CAJS2yDtaDeEftM=kxZFc+fC5F2d8EjJoK0NrrWVYSChBQvfqYw@mail.gmail.com>
References: <CAJS2yDtaDeEftM=kxZFc+fC5F2d8EjJoK0NrrWVYSChBQvfqYw@mail.gmail.com>
Message-ID: <1811927.NUycTqnEQz@laptop.killsudo.info>

On Monday, September 12, 2011 12:08:56 PM Coy Hile wrote:
> > On Sun, Sep 11, 2011 at 9:08 PM, Christopher Morrow
> > 
> > <morrowc.lists at gmail.com> wrote:
> >> what's the real benefit of an EV cert? (to the service owner, not the
> >> CA, the CA benefit is pretty clearly $$)
> > 
> > The benefit is to the end user.
> > They see a green address bar  with the company's name displayed.
> > 
> > Yeah, company's name displayed -- individuals cannot apply for EVSSL
> > certs.
> > 
> > 
> > With normal certs, the end user doesn't see a green address bar, and
> > instead of the company's
> > name displayed "(unknown)" is displayed and
> > "This web site does not supply ownership information."  is displayed.
> > 
> > If you ask me, hiding the company's name even when present on a
> > non-EVSSL
> > cert is tantamount to saying  "Only EV-SSL certs are really trusted
> > anyways".
> > 
> > So maybe  instead of these shenanigans browser makers should have just
> > started displaying a "don't trust this site" warning for any non-EVSSL
> > cert.
> As an academic aside, exactly what would one set on his (internal)
> root CA so that internally-trusted certs signed by that CA would show
> up as EV certs?

The certificate would need a authority specific OID included in the extension 
field and you would have to modify the browser to acknowledge the OID as 
legitmate.

Regards,
 
Cody Rose
NOC & Sys Admin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110912/cfa992ea/attachment-0001.bin>

From millnert at gmail.com  Mon Sep 12 09:09:43 2011
From: millnert at gmail.com (Martin Millnert)
Date: Mon, 12 Sep 2011 16:09:43 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <20110911.201218.74676712.sthaug@nethelp.no>
References: <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
 <4E6CEDAB.4070307@bogus.com>
 <20110911.201218.74676712.sthaug@nethelp.no>
Message-ID: <CAHyNd163a5Yc=sCM7a6DamG=Jm1XecnPmcFbnu=OwDxn--b1ag@mail.gmail.com>

Steinar,

On Sun, Sep 11, 2011 at 8:12 PM,  <sthaug at nethelp.no> wrote:
>> To pop up the stack a bit it's the fact that an organization willing to
>> behave in that fashion was in my list of CA certs in the first place.
>> Yes they're blackballed now, better late than never I suppose. What does
>> that say about the potential for other CAs to behave in such a fashion?
>
> I'd say we have every reason to believe that something similar *will*
> happen again :-(

Something similar, including use of purchased (not only limited to
stolen certs), is ongoing already, all of the time.  (I had a fellow
IRC-chat-friend report from a certain very western-allied middle
eastern country that there's ISP/state-scale SSL-MITM ongoing there,
for all https traffic.)

The comment on starting out with an empty /etc/ssl is valid.  Most of
the normally included CA's you almost never run into on the wild web
anyway. There were some blog postings about this last time a CA was
busted. Shave off 90% of them and you have at least come a bit on the
way (goal 100%).

The absence of proof is *not* proof of absence, and in this particular
case it's pretty safe to assume some abuse is ongoing somewhere, 24/7.

Cheers,
Martin


From cjp at 0x1.net  Mon Sep 12 09:25:11 2011
From: cjp at 0x1.net (Christopher J. Pilkington)
Date: Mon, 12 Sep 2011 10:25:11 -0400
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <221E581B-206F-4BFF-92FF-EB0761C42CA3@GREnergy.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAL9jLaZC=UCAmMSKGSZcNcD+ijODKCR8n3Lks-Ydjy6rDq-fvg@mail.gmail.com>
 <CAAAwwbVcRq8q8C6y4zYZkovmL6HwB1O6Fif0KtKC_355SdsnmQ@mail.gmail.com>
 <CAL9jLaYYp9CK4kjdUZwae4PTGmQXEzm9UQp2oL9hkNFUMJotKg@mail.gmail.com>
 <221E581B-206F-4BFF-92FF-EB0761C42CA3@GREnergy.com>
Message-ID: <E72AD44C-5A3E-41EE-833D-E84B72D07E82@0x1.net>

On Sep 11, 2011, at 11:06 PM, Hughes, Scott GRE-MG wrote:

> Companies that wrap their services with generic domain names (paymybills.com and the like) have no one to blame but themselves when they are targeted by scammers and phishing schemes. Even EV certificates don't help when consumers are blinded by subsidiary companies and sister companies daily (Motorola Mobility a.k.a. Google vs. Motorola Solutions.)


GE Money Bank is notorious for this? from a retail store's main page they redirect you to https://www3.onlinecreditcenter6.com.  (No-EV certificate, either.)

-cjp

From jason.duerstock at gallaudet.edu  Mon Sep 12 09:32:39 2011
From: jason.duerstock at gallaudet.edu (Jason Duerstock)
Date: Mon, 12 Sep 2011 10:32:39 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <4E6DD13A.9050003@cisco.com>
References: <5.1.0.14.2.20110912080438.037715e8@efes.iucc.ac.il>
 <4E6DD13A.9050003@cisco.com>
Message-ID: <CAJNn=DNMrGC42i4Q_Wjvz-i9uV_4w1YnfM8vcX4g_wnXLoT=vA@mail.gmail.com>

Except that this just shifts the burden of trust on to DNSSEC, which also
necessitates a central authority of 'trust'.  Unless there's an explicitly
more secure way of storing DNSSEC private keys, this just moves the bullseye
from CAs to DNSSEC signers.

Jason

On Mon, Sep 12, 2011 at 5:30 AM, Eliot Lear <lear at cisco.com> wrote:

> Hank and everyone,
>
> This is a very interesting problem.  As it happens, some folks in the
> IETF have anticipated this one.  For those who are interested, Paul
> Hoffman and Jakob Schlyter have been working within the DANE working
> group at the IETF to provide for a means to alleviate some of the
> responsibility of the browser vendors as to who gets to decide what is a
> valid certificate, by allowing for that burden to be shifted to the
> subject through the use of secure DNS.  A list of hashes is published in
> the subject's domain indicating what are valid certificates.  And so if
> a CA went rogue, the subject domains would be able to indicate to the
> browser that something is afoot.  For more information, please see
> http://datatracker.ietf.org/wg/dane/.
>
> Eliot
>
> On 9/12/11 7:22 AM, Hank Nussbacher wrote:
> > At 13:00 11/09/2011 -0600, Keith Medcalf wrote:
> >> Damian Menscher wrote on 2011-09-11:
> >>
> >> > Because of that lost trust, any cross-signed cert would likely be
> >> > revoked by the browsers.  It would also make the browser vendors
> >> > question whether the signing CA is worthy of their trust.
> >>
> >> And therein is the root of the problem:  Trustworthiness is assessed
> >> by what you refer to as the "browser vendors".  Unfortunately, there
> >> is no Trustworthiness assessment of those vendors.
> >>
> >> The current system provides no more authentication or confidentiality
> >> than if everyone simply used self-signed certificates.  It is nothing
> >> more than theatre and provides no actual security benefit
> >> whatsoever.  Anyone believing otherwise is operating under a delusion.
> >
> > The problem is about lack of pen-testing and a philosphy of security.
> > In order to run a CA, one not only has to build the infrastructure but
> > also have constant external pen-testing and patch management in
> > place.  Whether it be Comodo or RSA or now Diginotar, unless an
> > overwhelming philosphy of "computer and network security" is
> > paradigmed into the corporate DNA, this will keep happening - and not
> > only to CAs but to the likes of Google, Cisco, Microsoft, etc. (read -
> > APT attacks).
> >
> > If 60% of your employees will plug in a USB drive they find in the
> > parking lot, then you have failed:
> >
> http://www.bloomberg.com/news/2011-06-27/human-errors-fuel-hacking-as-test-shows-nothing-prevents-idiocy.html
> >
> >
> > The problem for us as a community if to find a benchmark of which
> > company "does have a clue" vs those that don't.  Until then, it will
> > just be whack-a-mole/CA.
> >
> > -Hank
> >
> >
> >
> >
> >
> >
> >> --- Keith Medcalf
> >> ()  ascii ribbon campaign against html e-mail
> >> /\  www.asciiribbon.org
> >
> >
> >
>
>

From johnl at iecc.com  Mon Sep 12 09:46:03 2011
From: johnl at iecc.com (John Levine)
Date: 12 Sep 2011 14:46:03 -0000
Subject: DANE and DNSSEC, was Microsoft deems all DigiNotar
In-Reply-To: <CAJNn=DNMrGC42i4Q_Wjvz-i9uV_4w1YnfM8vcX4g_wnXLoT=vA@mail.gmail.com>
Message-ID: <20110912144603.62752.qmail@joyce.lan>

In article <CAJNn=DNMrGC42i4Q_Wjvz-i9uV_4w1YnfM8vcX4g_wnXLoT=vA at mail.gmail.com> you write:
>Except that this just shifts the burden of trust on to DNSSEC, which also
>necessitates a central authority of 'trust'.  Unless there's an explicitly
>more secure way of storing DNSSEC private keys, this just moves the bullseye
>from CAs to DNSSEC signers.

It does, but it also limits the damage.  If you lose your DNSSEC key,
bad guys can forge names below you in the DNS tree.  If you lose your
CA key, bad guys can forge any name they want.

Or to look at it another way, if I put effort into securing my own
DNS, and I am careful about the providers above me in the tree, I can
limit the chance of DNSSEC compromise.  With SSL, it doesn't matter
what I do, I'm always at the mercy of the next Diginotar.

R's,
John


From randy at psg.com  Mon Sep 12 09:46:46 2011
From: randy at psg.com (Randy Bush)
Date: Mon, 12 Sep 2011 16:46:46 +0200
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
 <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>
Message-ID: <m2fwk1kecp.wl%randy@psg.com>

> But Gregory is right, you cannot really trust anybody completely. Even
> the larger and more respectable commercial organisations will be
> unable to resist <insert intel organisation here> when they ask for
> dodgy certs so they can intercept something..
> 
> No, as soon as you have somebody who is not yourself in control
> without any third party verifiably independent oversight then you have
> to carefully define what you mean by trust.

i am having trouble with all this.  i am supposed to only trust myself
to identify citibank's web site?  and what to i smoke to get that
knowledge?  let's get real here.

with dane, i trust whoever runs dns for citibank to identify the cert
for citibank.  this seems much more reasonable than other approaches,
though i admit to not having dived deeply into them all.

randy


From mike at mtcc.com  Mon Sep 12 09:53:57 2011
From: mike at mtcc.com (Michael Thomas)
Date: Mon, 12 Sep 2011 07:53:57 -0700
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <m2fwk1kecp.wl%randy@psg.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
 <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>
 <m2fwk1kecp.wl%randy@psg.com>
Message-ID: <4E6E1D05.3050902@mtcc.com>

Randy Bush wrote:
>> But Gregory is right, you cannot really trust anybody completely. Even
>> the larger and more respectable commercial organisations will be
>> unable to resist <insert intel organisation here> when they ask for
>> dodgy certs so they can intercept something..
>>
>> No, as soon as you have somebody who is not yourself in control
>> without any third party verifiably independent oversight then you have
>> to carefully define what you mean by trust.
> 
> i am having trouble with all this.  i am supposed to only trust myself
> to identify citibank's web site?  and what to i smoke to get that
> knowledge?  let's get real here.
> 
> with dane, i trust whoever runs dns for citibank to identify the cert
> for citibank.  this seems much more reasonable than other approaches,
> though i admit to not having dived deeply into them all.

It seems to me that this depends a lot on how much you can tolerate single
points of failure. The current de-trusting is certainly going to cause trouble
for whoever used that CA, but the internet didn't roll over and die either.
If the root DNS keys were compromised in an all DNS rooted world... unhappiness
would ensue in great volume.

Mike, poison and choices...


From randy at psg.com  Mon Sep 12 09:57:44 2011
From: randy at psg.com (Randy Bush)
Date: Mon, 12 Sep 2011 16:57:44 +0200
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <4E6E1D05.3050902@mtcc.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
 <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>
 <m2fwk1kecp.wl%randy@psg.com> <4E6E1D05.3050902@mtcc.com>
Message-ID: <m2d3f5kduf.wl%randy@psg.com>

>> with dane, i trust whoever runs dns for citibank to identify the cert
>> for citibank.  this seems much more reasonable than other approaches,
>> though i admit to not having dived deeply into them all.
> If the root DNS keys were compromised in an all DNS rooted world...
> unhappiness would ensue in great volume.

as eliot pointed out, to defeat dane as currently written, you would
have to compromise dnssec at the same time as you compromised the CA at
the same time as you ran the mitm.  i.e. it _adds_ dnssec assurance to
CA trust.

randy


From greg at bestnet.kharkov.ua  Mon Sep 12 10:04:59 2011
From: greg at bestnet.kharkov.ua (Gregory Edigarov)
Date: Mon, 12 Sep 2011 18:04:59 +0300
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <4E6E1D05.3050902@mtcc.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
 <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>
 <m2fwk1kecp.wl%randy@psg.com> <4E6E1D05.3050902@mtcc.com>
Message-ID: <20110912180459.6108b3ce@greg.bestnet.kharkov.ua>

On Mon, 12 Sep 2011 07:53:57 -0700
Michael Thomas <mike at mtcc.com> wrote:

> Randy Bush wrote:
> >> But Gregory is right, you cannot really trust anybody completely.
> >> Even the larger and more respectable commercial organisations will
> >> be unable to resist <insert intel organisation here> when they ask
> >> for dodgy certs so they can intercept something..
> >>
> >> No, as soon as you have somebody who is not yourself in control
> >> without any third party verifiably independent oversight then you
> >> have to carefully define what you mean by trust.
> > 
> > i am having trouble with all this.  i am supposed to only trust
> > myself to identify citibank's web site?  and what to i smoke to get
> > that knowledge?  let's get real here.
> > 
> > with dane, i trust whoever runs dns for citibank to identify the
> > cert for citibank.  this seems much more reasonable than other
> > approaches, though i admit to not having dived deeply into them all.
> 
> It seems to me that this depends a lot on how much you can tolerate
> single points of failure. The current de-trusting is certainly going
> to cause trouble for whoever used that CA, but the internet didn't
> roll over and die either. If the root DNS keys were compromised in an
> all DNS rooted world... unhappiness would ensue in great volume.
> 
> Mike, poison and choices...
> 
let me state clearly what am I writing about:
ok, suppose, there is a site on the internet, that has a certificate
issued by one of the major CAs. how could one know, that certificate
wasn't issued to forged identity?  


From mike at mtcc.com  Mon Sep 12 10:09:59 2011
From: mike at mtcc.com (Michael Thomas)
Date: Mon, 12 Sep 2011 08:09:59 -0700
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <m2d3f5kduf.wl%randy@psg.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>	<CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>	<20110912142317.7d4008a8@greg.bestnet.kharkov.ua>	<D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>	<m2fwk1kecp.wl%randy@psg.com>	<4E6E1D05.3050902@mtcc.com>
 <m2d3f5kduf.wl%randy@psg.com>
Message-ID: <4E6E20C7.9030905@mtcc.com>

Randy Bush wrote:
>>> with dane, i trust whoever runs dns for citibank to identify the cert
>>> for citibank.  this seems much more reasonable than other approaches,
>>> though i admit to not having dived deeply into them all.
>> If the root DNS keys were compromised in an all DNS rooted world...
>> unhappiness would ensue in great volume.
> 
> as eliot pointed out, to defeat dane as currently written, you would
> have to compromise dnssec at the same time as you compromised the CA at
> the same time as you ran the mitm.  i.e. it _adds_ dnssec assurance to
> CA trust.

Yes, I saw that. It also drives up complexity too and makes you wonder what
the added value of those cert vendors is for the money you're forking over.
Especially when you consider the criticality of dns naming for everything
except web site host names using tls. And how long would it be before browsers
allowed self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?

Mike


From randy at psg.com  Mon Sep 12 10:12:24 2011
From: randy at psg.com (Randy Bush)
Date: Mon, 12 Sep 2011 17:12:24 +0200
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <4E6E20C7.9030905@mtcc.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
 <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>
 <m2fwk1kecp.wl%randy@psg.com> <4E6E1D05.3050902@mtcc.com>
 <m2d3f5kduf.wl%randy@psg.com> <4E6E20C7.9030905@mtcc.com>
Message-ID: <m28vptkd5z.wl%randy@psg.com>

>> as eliot pointed out, to defeat dane as currently written, you would
>> have to compromise dnssec at the same time as you compromised the CA at
>> the same time as you ran the mitm.  i.e. it _adds_ dnssec assurance to
>> CA trust.
> Yes, I saw that. It also drives up complexity too and makes you wonder
> what the added value of those cert vendors is for the money you're
> forking over.  Especially when you consider the criticality of dns
> naming for everything except web site host names using tls. And how
> long would it be before browsers allowed
> self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?

agree


From millnert at gmail.com  Mon Sep 12 10:17:55 2011
From: millnert at gmail.com (Martin Millnert)
Date: Mon, 12 Sep 2011 17:17:55 +0200
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <4E6E20C7.9030905@mtcc.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
 <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>
 <m2fwk1kecp.wl%randy@psg.com> <4E6E1D05.3050902@mtcc.com>
 <m2d3f5kduf.wl%randy@psg.com> <4E6E20C7.9030905@mtcc.com>
Message-ID: <CAHyNd17W1UORzGTDAwM9jTgB30FZfhJ-TWNajiFn=sLNJ7OT0g@mail.gmail.com>

On Mon, Sep 12, 2011 at 5:09 PM, Michael Thomas <mike at mtcc.com> wrote:
> And how long would it be before browsers allowed self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?

As previously mentioned, Chrome >= v14 already does.

Regards,
Martin


From morrowc.lists at gmail.com  Mon Sep 12 10:22:11 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 12 Sep 2011 11:22:11 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <167290.1315816763@turing-police.cc.vt.edu>
References: <7798fc1cb3ee3c42bad613adb2f3dc6d@mail.dessus.com>
 <146257.1315769856@turing-police.cc.vt.edu>
 <CAL9jLaZL8UygQjjcvaCbpW0qBqnSrygJb6HQTK4gh=NH45aCAg@mail.gmail.com>
 <167290.1315816763@turing-police.cc.vt.edu>
Message-ID: <CAL9jLaY2veC84OwsKmgcrmcw5YW5nJy9ynkZWzM6sUtfDS1eMg@mail.gmail.com>

On Mon, Sep 12, 2011 at 4:39 AM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Sun, 11 Sep 2011 22:01:47 EDT, Christopher Morrow said:
>> If I have a thawte cert for valdis.com on host A and one from comodo
>> on host B... which is the right one?
>
> You wouldn't have 2 certs for that... I'd have *one* cert for that. And if when
> you got to the IP address you were trying to reach, the cert didn't validate as
> matching the hostname, you know something fishy is up.
>
> And if you *do* have two certs for it, I'd like to talk to the bozos at
> Thawte and Comodo who obviously didn't check the paperwork. ;)

this has already happened with mozilla.com, google.com, microsoft.com
.... my point was that as a user, and as a service operator, what in
today's CA world helps me know that the service operator's certificate
is what my user-client sees? some 'trust' in the fact that
thawte/comodo/verisign/cnnic didn't issue a cert for the
service-operator's service incorrectly?

I think I need a method that the service operator can use to signal to
my user-client outside the certificate itself that the certificate
#1234 is the 'right' one.


From mike at mtcc.com  Mon Sep 12 10:24:32 2011
From: mike at mtcc.com (Michael Thomas)
Date: Mon, 12 Sep 2011 08:24:32 -0700
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAHyNd17W1UORzGTDAwM9jTgB30FZfhJ-TWNajiFn=sLNJ7OT0g@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>	<CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>	<20110912142317.7d4008a8@greg.bestnet.kharkov.ua>	<D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>	<m2fwk1kecp.wl%randy@psg.com>	<4E6E1D05.3050902@mtcc.com>	<m2d3f5kduf.wl%randy@psg.com>	<4E6E20C7.9030905@mtcc.com>
 <CAHyNd17W1UORzGTDAwM9jTgB30FZfhJ-TWNajiFn=sLNJ7OT0g@mail.gmail.com>
Message-ID: <4E6E2430.1040807@mtcc.com>

Martin Millnert wrote:
> On Mon, Sep 12, 2011 at 5:09 PM, Michael Thomas <mike at mtcc.com> wrote:
>> And how long would it be before browsers allowed self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?
> 
> As previously mentioned, Chrome >= v14 already does.

The perils of coming in late in a thread :)

Mike


From ml-nanog090304q at elcsplace.com  Mon Sep 12 10:30:37 2011
From: ml-nanog090304q at elcsplace.com (Ted Cooper)
Date: Tue, 13 Sep 2011 01:30:37 +1000
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <m28vptkd5z.wl%randy@psg.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
 <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>
 <m2fwk1kecp.wl%randy@psg.com> <4E6E1D05.3050902@mtcc.com>
 <m2d3f5kduf.wl%randy@psg.com> <4E6E20C7.9030905@mtcc.com>
 <m28vptkd5z.wl%randy@psg.com>
Message-ID: <4E6E259D.6000603@elcsplace.com>

On 13/09/11 01:12, Randy Bush wrote:
>>> as eliot pointed out, to defeat dane as currently written, you would
>>> have to compromise dnssec at the same time as you compromised the CA at
>>> the same time as you ran the mitm.  i.e. it _adds_ dnssec assurance to
>>> CA trust.
>> Yes, I saw that. It also drives up complexity too and makes you wonder
>> what the added value of those cert vendors is for the money you're
>> forking over.  Especially when you consider the criticality of dns
>> naming for everything except web site host names using tls. And how
>> long would it be before browsers allowed
>> self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?
> 
> agree

I would have thought that was a perfectly acceptable end point.

The multiple CA's go away (oops), replaced with everyone being able to
publish and authenticate their own certificates. The DNS has to be
compromised to publish certificates, but if they've managed to do that,
it doesn't matter what certificate you had in the first place.

There are already public keys in the DNS for DKIM which work quite well.

It lowers the cost for getting an SSL cert for your domain, but
certainly not the security. Getting a cert for a domain is laughable
these days. It's either too easy, or stupendously hard and ridiculous.
EV certs are a joke as demonstrated by the thousands of people still
getting phished since end users don't look at the address bar anyway.

So long as it's encrypted and in some way secured against the domain,
it's good enough isn't it?


From nanog at u61.u22.net  Mon Sep 12 10:40:56 2011
From: nanog at u61.u22.net (Always Learning)
Date: Mon, 12 Sep 2011 16:40:56 +0100
Subject: Disappointing ARIN - A great advertisement for the USA ?
Message-ID: <1315842056.4599.49.camel@m6.u226.com>


Hallo North Americans,

I am from Europe. A contributor on the Centos (the largest Red Hat
clone) list suggested I reposted my ARIN item on your list.


I have a BASH script called .w
It contains

	#! /bin/bash
	whois $1
	host $1

When I type

        .w 51.51.51.51 

I receive a normal and conventional display of data because that IP
address is not 'organised' by ARIN. When I type:-

        .w 64.64.64.64

I receive a one line summary of possible matches, which always
includes ARIN, but omits the details we used to receive before ARIN
implemented its much criticised "improved" service.

My second script .wa is more useful for North American IP enquiries:-

	#! /bin/bash
        whois -h whois.arin.net n + $1
	host $1

On some occasions I get a normal display of Northern American data. The
'n' and '+' are not part of WHOIS. They are ARIN's own parameters. This
example produces a 'near-as-possible-because-it-is-ARIN' display:-

	.wa 65.65.65.65

However when ARIN automatically forwards the query to a North American
RWHOIS the query is apparently malformed and nothing useful is
displayed. For example:-

	.wa 66.66.66.66


The Internet was created in North America. Many people around the world
would appreciate your help in getting ARIN to revert to normal WHOIS
displays. ARIN wants enquirers to click on web page after web page to
try and find the information previously displayed in a single response.
Frankly that weird attitude is stark raving bonkers!


-- 
With best regards,

Paul.
England,
EU.




From jeroen at unfix.org  Mon Sep 12 11:17:12 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Mon, 12 Sep 2011 18:17:12 +0200
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <1315842056.4599.49.camel@m6.u226.com>
References: <1315842056.4599.49.camel@m6.u226.com>
Message-ID: <4E6E3088.7010109@unfix.org>

On 2011-09-12 17:40 , Always Learning wrote:

Dear person who is to scared to setup a regular email account in his own
full name.

[..]
> The Internet was created in North America. Many people around the world
> would appreciate your help in getting ARIN to revert to normal WHOIS
> displays. ARIN wants enquirers to click on web page after web page to
> try and find the information previously displayed in a single response.
> Frankly that weird attitude is stark raving bonkers!

You are confusing RPSL (RFC2650) with WHOIS (RFC812,RFC954,RFC3912).

Now, I agree on the part that ARIN should be doing RPSL, or even more,
just start using the RIPE whois server for serving their data.
Converting that all over though is not something that will happen
easily. (and ARIN has an RPSL server somewhere, but it is not that well
populated if at all remotely current)

Next to that the bigger question is of course what you are looking for
in the whois data.


NANOG is not ARIN btw, thus you are posting to the wrong mailinglist for
your rant, for that see:
 https://www.arin.net/participate/mailing_lists/

Oh, and there they also like to see your real name and not a junk mail
address. Just like on the RIPE mailinglists, you know in the old country.

Greets,
 Jeroen


From jlewis at lewis.org  Mon Sep 12 11:32:20 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 12 Sep 2011 12:32:20 -0400 (EDT)
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <4E6E3088.7010109@unfix.org>
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
Message-ID: <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org>

On Mon, 12 Sep 2011, Jeroen Massar wrote:

> On 2011-09-12 17:40 , Always Learning wrote:
>
> Dear person who is to scared to setup a regular email account in his own
> full name.
>
> [..]
>> The Internet was created in North America. Many people around the world
>> would appreciate your help in getting ARIN to revert to normal WHOIS
>> displays. ARIN wants enquirers to click on web page after web page to
>> try and find the information previously displayed in a single response.
>> Frankly that weird attitude is stark raving bonkers!
>
> You are confusing RPSL (RFC2650) with WHOIS (RFC812,RFC954,RFC3912).

No he's not.  He's complaining that sometime in the past few weeks (or is 
it months now?) ARIN changed the behavior of their whois server.  New 
output for the query 209.208.0.1 is (omitting comments):

Internet Connect Company, Inc. ICC-1 (NET-209-208-0-0-1) 209.208.0.0 - 209.208.127.255
American Registry for Internet Numbers NET209 (NET-209-0-0-0-0) 209.0.0.0 - 209.255.255.255

The old behavior was that ARIN's whois server would respond with the data 
from NET-209-208-0-0-1.  i.e.

NetRange:       209.208.0.0 - 209.208.127.255
CIDR:           209.208.0.0/17
OriginAS:
NetName:        ICC-1
NetHandle:      NET-209-208-0-0-1
Parent:         NET-209-0-0-0-0
NetType:        Direct Allocation
...

This is rather an annoying change for anyone who uses whois much as it 
means every ARIN query is now at least two queries and there are doubtless 
scripts in use to grab information from whois that broke as a result of 
this change.  NANOG isn't the place to complain about this though. 
Perhaps PPML is closer to the right place.

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


From nanog at u61.u22.net  Mon Sep 12 11:46:33 2011
From: nanog at u61.u22.net (Always Learning)
Date: Mon, 12 Sep 2011 17:46:33 +0100
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org>
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
 <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org>
Message-ID: <1315845993.4599.66.camel@m6.u226.com>


On Mon, 2011-09-12 at 12:32 -0400, Jon Lewis wrote:

> No he's not.  He's complaining that sometime in the past few weeks (or is 
> it months now?) ARIN changed the behavior of their whois server.  New 
> output for the query 209.208.0.1 is (omitting comments):
> 
> Internet Connect Company, Inc. ICC-1 (NET-209-208-0-0-1) 209.208.0.0 - 209.208.127.255
> American Registry for Internet Numbers NET209 (NET-209-0-0-0-0) 209.0.0.0 - 209.255.255.255
> 
> The old behavior was that ARIN's whois server would respond with the data 
> from NET-209-208-0-0-1.  i.e.
> 
> NetRange:       209.208.0.0 - 209.208.127.255
> CIDR:           209.208.0.0/17
> OriginAS:
> NetName:        ICC-1
> NetHandle:      NET-209-208-0-0-1
> Parent:         NET-209-0-0-0-0
> NetType:        Direct Allocation
> ...
> 
> This is rather an annoying change for anyone who uses whois much as it 
> means every ARIN query is now at least two queries and there are doubtless 
> scripts in use to grab information from whois that broke as a result of 
> this change.  NANOG isn't the place to complain about this though. 
> Perhaps PPML is closer to the right place.

Thank you for confirming the problem. I'll try your PPML @ ARIN
suggestion.


-- 
With best regards,

Paul,
England,
EU.




From eric at telic.us  Mon Sep 12 11:46:05 2011
From: eric at telic.us (Eric Krichbaum)
Date: Mon, 12 Sep 2011 11:46:05 -0500
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org>
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
 <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org>
Message-ID: <118501cc716b$7a6c2990$6f447cb0$@telic.us>

That was on June 25th according to Mark Kosters.  They started to answer
with both the parent and delegated objects.  That hosed the way RWHOIS data
was being reported to most things as the client won't know which to send
through to the rwhois servers.  Still works from an old SCO box but not from
anything current.

A "+" flag on the query from some clients will get it to recurse, but for my
tests kicked back "%error 350 Invalid Query Syntax". 

My issue with that response is that the general whois query shouldn't have
to have an extra flag passed to get the data you asked for in the first
place.   This traps out most of the standard users from ever getting the
correct data.  It also makes the rwhois data almost impossible for the
general public to get.

Eric




-----Original Message-----
From: Jon Lewis [mailto:jlewis at lewis.org] 
Sent: Monday, September 12, 2011 11:32 AM
To: Jeroen Massar
Cc: ppml at arin.net; NANOG
Subject: Re: Disappointing ARIN - A great advertisement for the USA ?

On Mon, 12 Sep 2011, Jeroen Massar wrote:

> On 2011-09-12 17:40 , Always Learning wrote:
>
> Dear person who is to scared to setup a regular email account in his 
> own full name.
>
> [..]
>> The Internet was created in North America. Many people around the 
>> world would appreciate your help in getting ARIN to revert to normal 
>> WHOIS displays. ARIN wants enquirers to click on web page after web 
>> page to try and find the information previously displayed in a single
response.
>> Frankly that weird attitude is stark raving bonkers!
>
> You are confusing RPSL (RFC2650) with WHOIS (RFC812,RFC954,RFC3912).

No he's not.  He's complaining that sometime in the past few weeks (or is it
months now?) ARIN changed the behavior of their whois server.  New output
for the query 209.208.0.1 is (omitting comments):

Internet Connect Company, Inc. ICC-1 (NET-209-208-0-0-1) 209.208.0.0 -
209.208.127.255 American Registry for Internet Numbers NET209
(NET-209-0-0-0-0) 209.0.0.0 - 209.255.255.255

The old behavior was that ARIN's whois server would respond with the data
from NET-209-208-0-0-1.  i.e.

NetRange:       209.208.0.0 - 209.208.127.255
CIDR:           209.208.0.0/17
OriginAS:
NetName:        ICC-1
NetHandle:      NET-209-208-0-0-1
Parent:         NET-209-0-0-0-0
NetType:        Direct Allocation
...

This is rather an annoying change for anyone who uses whois much as it means
every ARIN query is now at least two queries and there are doubtless scripts
in use to grab information from whois that broke as a result of this change.
NANOG isn't the place to complain about this though. 
Perhaps PPML is closer to the right place.

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





From jlewis at lewis.org  Mon Sep 12 11:53:47 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 12 Sep 2011 12:53:47 -0400 (EDT)
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <118501cc716b$7a6c2990$6f447cb0$@telic.us>
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
 <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org>
 <118501cc716b$7a6c2990$6f447cb0$@telic.us>
Message-ID: <Pine.LNX.4.61.1109121251290.18171@soloth.lewis.org>

On Mon, 12 Sep 2011, Eric Krichbaum wrote:

> That was on June 25th according to Mark Kosters.  They started to answer
> with both the parent and delegated objects.  That hosed the way RWHOIS data
> was being reported to most things as the client won't know which to send
> through to the rwhois servers.  Still works from an old SCO box but not from
> anything current.
>
> A "+" flag on the query from some clients will get it to recurse, but for my
> tests kicked back "%error 350 Invalid Query Syntax".

Prepending the query with a + "works" for me, in that I get the expected 
data, but there's additional unexpeced data (full record for the Parent, 
even if the Parent is just an ARIN /8) in the output that will probably 
still cause problems for scripts.


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


From morrowc.lists at gmail.com  Mon Sep 12 11:58:32 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 12 Sep 2011 12:58:32 -0400
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <Pine.LNX.4.61.1109121251290.18171@soloth.lewis.org>
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
 <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org>
 <118501cc716b$7a6c2990$6f447cb0$@telic.us>
 <Pine.LNX.4.61.1109121251290.18171@soloth.lewis.org>
Message-ID: <CAL9jLaayDkb-M07ATdDNaAsHDQEkWTp-Xh4JMtrstZ8gy1hXfw@mail.gmail.com>

On Mon, Sep 12, 2011 at 12:53 PM, Jon Lewis <jlewis at lewis.org> wrote:
> On Mon, 12 Sep 2011, Eric Krichbaum wrote:
>
>> That was on June 25th according to Mark Kosters. ?They started to answer
>> with both the parent and delegated objects. ?That hosed the way RWHOIS
>> data
>> was being reported to most things as the client won't know which to send
>> through to the rwhois servers. ?Still works from an old SCO box but not
>> from
>> anything current.
>>
>> A "+" flag on the query from some clients will get it to recurse, but for
>> my
>> tests kicked back "%error 350 Invalid Query Syntax".
>
> Prepending the query with a + "works" for me, in that I get the expected
> data, but there's additional unexpeced data (full record for the Parent,
> even if the Parent is just an ARIN /8) in the output that will probably
> still cause problems for scripts.


my guess is that ARIN is hoping folks turn to the actual RESTful
interface for many scripted purposes...I keep expecting to see some
example python/perl/etc off:

<https://www.arin.net/resources/whoisrws/index.html>

but at least the api is documented, it ought to be fairly
straightforward to make a simple whois client.
(that could be extended to be used in whatever scripty thing you were
using before)
-chris


From nanog at u61.u22.net  Mon Sep 12 12:13:59 2011
From: nanog at u61.u22.net (Always Learning)
Date: Mon, 12 Sep 2011 18:13:59 +0100
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <4E6E3088.7010109@unfix.org>
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
Message-ID: <1315847639.4599.89.camel@m6.u226.com>


On Mon, 2011-09-12 at 18:17 +0200, Jeroen Massar wrote:
> On 2011-09-12 17:40 , Always Learning wrote:
> 
> Dear person who is to scared to setup a regular email account in his own
> full name.

Beste Fuzzel,

Mijn naam is Paul. It was at the bottom of my posting.

Sorry I have never ever had a Hotmail account. I prefer to use
nanog at u61.u22.net for this list. I really do not want to set-up another
email account for your personal benefit.

> You are confusing RPSL (RFC2650) with WHOIS (RFC812,RFC954,RFC3912).

No I am not.  A basic WHOIS enquiry is what I was writing about.

> Next to that the bigger question is of course what you are looking for
> in the whois data.

Primarily IP ranges to block and/or abuse email addresses.

>  https://www.arin.net/participate/mailing_lists/

Thank you.  I will try it.

> Oh, and there they also like to see your real name and not a junk mail
> address. Just like on the RIPE mailinglists, you know in the old country.

The ARIN web page http://lists.arin.net/mailman/listinfo/arin-ppml
states

	Your name (optional):

The 'old country' sounds a bit South African to me. I'm European and
English.

> Greets,

Groet in Dutch or Greetings in English.

Have a nice day.


Paul
Always Learning, hopefully until I die.




From jlewis at lewis.org  Mon Sep 12 12:22:13 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 12 Sep 2011 13:22:13 -0400 (EDT)
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CAL9jLaayDkb-M07ATdDNaAsHDQEkWTp-Xh4JMtrstZ8gy1hXfw@mail.gmail.com>
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
 <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org>
 <118501cc716b$7a6c2990$6f447cb0$@telic.us>
 <Pine.LNX.4.61.1109121251290.18171@soloth.lewis.org>
 <CAL9jLaayDkb-M07ATdDNaAsHDQEkWTp-Xh4JMtrstZ8gy1hXfw@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.1109121303230.18171@soloth.lewis.org>

On Mon, 12 Sep 2011, Christopher Morrow wrote:

> my guess is that ARIN is hoping folks turn to the actual RESTful
> interface for many scripted purposes...I keep expecting to see some
> example python/perl/etc off:
>
> <https://www.arin.net/resources/whoisrws/index.html>

  Should I change my code to parse the RESTful Interface instead of the
  NICNAME/WHOIS TCP port 43 service?

  Absolutely. We encourage use of the new RESTful service for the purposes
  of programmatic consumption. ARIN plans to make more features available
  on the RESTful interface. The NICNAME/WHOIS service will remain accessible,
  but it may not support the enhanced features we intend to incorporate
  within Whois-RWS.

It'd be nice if the NICNAME/WHOIS was left alone as far as default 
behavior is concerned.

So, our tools that use the NICNAME/WHOIS service for lookups at all the 
other RIRs, now need to be updated to support ARIN's overcomplicated 
web/XML, which nobody else uses?...and it seems even with RWS you still 
need to do multiple queries to go from having an IP to having the full 
whois record.

How does the community (other than some programmers) benefit from this?

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


From nick at foobar.org  Mon Sep 12 12:33:11 2011
From: nick at foobar.org (Nick Hilliard)
Date: Mon, 12 Sep 2011 18:33:11 +0100
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <4E6E3088.7010109@unfix.org>
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
Message-ID: <4E6E4257.3060103@foobar.org>

On 12/09/2011 17:17, Jeroen Massar wrote:
> You are confusing RPSL (RFC2650) with WHOIS (RFC812,RFC954,RFC3912).

and you are confusing RPSL with RIPE-181 syntax.  RIPE-181 and its
grandchildren is a specification for whois information.  RPSL is a routing
policy language which uses ripe-181 format.  The two are not the same.

> Now, I agree on the part that ARIN should be doing RPSL, or even more,
> just start using the RIPE whois server for serving their data.

Now wait one moment until I bog you down with 20 years worth of legacy
paranoia, "Not Invented Here" and useless history about why this shouldn't
ever have happened...

Nick


From bonomi at mail.r-bonomi.com  Mon Sep 12 12:39:50 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Mon, 12 Sep 2011 12:39:50 -0500 (CDT)
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <CAL9jLaY2veC84OwsKmgcrmcw5YW5nJy9ynkZWzM6sUtfDS1eMg@mail.gmail.com>
Message-ID: <201109121739.p8CHdovQ002359@mail.r-bonomi.com>


> Date: Mon, 12 Sep 2011 11:22:11 -0400
> Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy,
>  releases updates
> From: Christopher Morrow <morrowc.lists at gmail.com>
>
> I think I need a method that the service operator can use to signal to my 
> user-client outside the certificate itself that the certificate
> #1234 is the 'right' one.

A certificate that cdrtifies the crertificate is valid, maybe?

And why would you trust that any more than the origial certificate?

And, if you do trust *that* certificate, what do you need the original
one for?


Seriously, about the only way I see to ameliorate this kind of problem is
for people to use self-signed certificates that are then authenticated
by _multiple_ 'trust anchors'.  If the end-user world raises warnings
for a certificate 'authenticated' by say, less than five separate entities.
then the compomise of any _single_ anchor is of pretty much 'no' value.  
Even better, let the user set the 'paranoia' level -- how many different
'trusted' authorities have to have authenticated the self-signed certificate
before the user 'really trusts' it.

Similarly, the certificate 'owner' can decide how much 'redundancy' it
wants in the 'authentiation' of it's identity -- how many separate 
authorities it gets to 'co-sign' it's certificate.




From damian at google.com  Mon Sep 12 12:50:09 2011
From: damian at google.com (Damian Menscher)
Date: Mon, 12 Sep 2011 10:50:09 -0700
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <CAHyNd163a5Yc=sCM7a6DamG=Jm1XecnPmcFbnu=OwDxn--b1ag@mail.gmail.com>
References: <CAAAwwbUqiRnJws_hi=5at4uN-cn+qq7PqsYSeWO_OizQkrVyrA@mail.gmail.com>
 <CABSP1Ofnjj27TsA=U4zs7-tpU67pbysSVFygD=WYtJwyTXzDWw@mail.gmail.com>
 <4E6CEDAB.4070307@bogus.com> <20110911.201218.74676712.sthaug@nethelp.no>
 <CAHyNd163a5Yc=sCM7a6DamG=Jm1XecnPmcFbnu=OwDxn--b1ag@mail.gmail.com>
Message-ID: <CABSP1Oe3ho4UH9yvHfuR2QWuygHyhjW7hnRY+A8TG01pBvR=6w@mail.gmail.com>

On Mon, Sep 12, 2011 at 7:09 AM, Martin Millnert <millnert at gmail.com> wrote:

>
> Something similar, including use of purchased (not only limited to
> stolen certs), is ongoing already, all of the time.  (I had a fellow
> IRC-chat-friend report from a certain very western-allied middle
> eastern country that there's ISP/state-scale SSL-MITM ongoing there,
> for all https traffic.)


If this were true, don't you think your friend would provide an SSL cert?

Damian
-- 
Damian Menscher :: Security Reliability Engineer :: Google

From morrowc.lists at gmail.com  Mon Sep 12 13:00:06 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 12 Sep 2011 14:00:06 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <201109121739.p8CHdovQ002359@mail.r-bonomi.com>
References: <CAL9jLaY2veC84OwsKmgcrmcw5YW5nJy9ynkZWzM6sUtfDS1eMg@mail.gmail.com>
 <201109121739.p8CHdovQ002359@mail.r-bonomi.com>
Message-ID: <CAL9jLaYMH6NjoSUzB4UxYzXtC8Qm8LP3owK9wRBvCaz9BKoasw@mail.gmail.com>

On Mon, Sep 12, 2011 at 1:39 PM, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
>
>> Date: Mon, 12 Sep 2011 11:22:11 -0400
>> Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy,
>> ?releases updates
>> From: Christopher Morrow <morrowc.lists at gmail.com>
>>
>> I think I need a method that the service operator can use to signal to my
>> user-client outside the certificate itself that the certificate
>> #1234 is the 'right' one.
>
> A certificate that cdrtifies the crertificate is valid, maybe?

so the DANE work does this, sort of... you sign (with dnssec) your
cert fingerprint, the client does a lookup (requiring dnssec signed
responses) to verify that the cert FP matches that which is in DNS.

> And why would you trust that any more than the origial certificate?

at least in this case the domain owner (presumably the service owner
in question) has signed (with their private key) the DNS content you
get back.

There are failure modes, but it's more in line with the
service-owner/service-user level not some oddball thirdparty.

> Seriously, about the only way I see to ameliorate this kind of problem is
> for people to use self-signed certificates that are then authenticated
> by _multiple_ 'trust anchors'. ?If the end-user world raises warnings
> for a certificate 'authenticated' by say, less than five separate entities.
> then the compomise of any _single_ anchor is of pretty much 'no' value.
> Even better, let the user set the 'paranoia' level -- how many different
> 'trusted' authorities have to have authenticated the self-signed certificate
> before the user 'really trusts' it.
>

this almost sounds like GPS position fixing... 'require 4 satellites
in view', or something along those lines. Interesting as an idea
though.

-chris


From nicotine at warningg.com  Mon Sep 12 13:23:16 2011
From: nicotine at warningg.com (Brandon Ewing)
Date: Mon, 12 Sep 2011 13:23:16 -0500
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <Pine.LNX.4.61.1109121251290.18171@soloth.lewis.org>
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
 <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org>
 <118501cc716b$7a6c2990$6f447cb0$@telic.us>
 <Pine.LNX.4.61.1109121251290.18171@soloth.lewis.org>
Message-ID: <20110912182316.GC582@radiological.warningg.com>

On Mon, Sep 12, 2011 at 12:53:47PM -0400, Jon Lewis wrote:
> Prepending the query with a + "works" for me, in that I get the expected 
> data, but there's additional unexpeced data (full record for the Parent, 
> even if the Parent is just an ARIN /8) in the output that will probably 
> still cause problems for scripts.

I'm just sad I can't get the RWHOIS referral from an ip query for jwhois to
follow automatically anymore.

-- 
Brandon Ewing                                        (nicotine at warningg.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110912/f801e7a2/attachment.bin>

From mike at mikejones.in  Mon Sep 12 13:23:37 2011
From: mike at mikejones.in (Mike Jones)
Date: Mon, 12 Sep 2011 19:23:37 +0100
Subject: Microsoft deems all DigiNotar certificates untrustworthy,
 releases updates
In-Reply-To: <201109121739.p8CHdovQ002359@mail.r-bonomi.com>
References: <CAL9jLaY2veC84OwsKmgcrmcw5YW5nJy9ynkZWzM6sUtfDS1eMg@mail.gmail.com>
 <201109121739.p8CHdovQ002359@mail.r-bonomi.com>
Message-ID: <CAAAas8GUGBG7YCHLZ0M4OEozODXVBuJQ6HSq7e2RQy0h8MWX+g@mail.gmail.com>

On 12 September 2011 18:39, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
> Seriously, about the only way I see to ameliorate this kind of problem is
> for people to use self-signed certificates that are then authenticated
> by _multiple_ 'trust anchors'. ?If the end-user world raises warnings
> for a certificate 'authenticated' by say, less than five separate entities.
> then the compomise of any _single_ anchor is of pretty much 'no' value.
> Even better, let the user set the 'paranoia' level -- how many different
> 'trusted' authorities have to have authenticated the self-signed certificate
> before the user 'really trusts' it.

So if I want my small website to support encryption, I now have to pay
5 companies, and hope that all my users have those 5 CAs in their
browser? Much better to use the existing DNS infrastructure (that all
5 of them would likely be using for their validation anyway), and not
have to pay anyone anything.

- Mike


From balbee at orscheln.com  Mon Sep 12 13:42:59 2011
From: balbee at orscheln.com (Ben Albee)
Date: Mon, 12 Sep 2011 13:42:59 -0500
Subject: vyatta for bgp
Message-ID: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>

Does anybody currently use vyatta as a bgp router for their company? If
so have you ran into any problems with using that instead of a cisco or
juniper router?


From rdobbins at arbor.net  Mon Sep 12 13:56:26 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 12 Sep 2011 18:56:26 +0000
Subject: vyatta for bgp
In-Reply-To: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
Message-ID: <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>

On Sep 13, 2011, at 1:42 AM, Ben Albee wrote:

> Does anybody currently use vyatta as a bgp router for their company?

The days of public-facing software-based routers were over years ago - you need an ASIC-based edge router, else you'll end up getting zorched.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From fredan-nanog at fredan.se  Mon Sep 12 14:00:32 2011
From: fredan-nanog at fredan.se (fredrik danerklint)
Date: Mon, 12 Sep 2011 21:00:32 +0200
Subject: vyatta for bgp
In-Reply-To: <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
Message-ID: <201109122100.32852.fredan-nanog@fredan.se>

> The days of public-facing software-based routers were over years ago - you
> need an ASIC-based edge router, else you'll end up getting zorched.

wait, what?

-- 
//fredan


From mksmith at adhost.com  Mon Sep 12 14:08:34 2011
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Mon, 12 Sep 2011 19:08:34 +0000
Subject: vyatta for bgp
In-Reply-To: <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
Message-ID: <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>

> -----Original Message-----
> From: Dobbins, Roland [mailto:rdobbins at arbor.net]
> Sent: Monday, September 12, 2011 11:56 AM
> To: North American Network Operators' Group
> Subject: Re: vyatta for bgp
> 
> On Sep 13, 2011, at 1:42 AM, Ben Albee wrote:
> 
> > Does anybody currently use vyatta as a bgp router for their company?
> 
> The days of public-facing software-based routers were over years ago - you
> need an ASIC-based edge router, else you'll end up getting zorched.
> 
How do you come to this conclusion?  I think a software-based router for enterprise level (let's say on the 1G per provider level) can handle a fair amount of zorching.  I checked the Cisco and Juniper docs and neither vendor is anywhere near releasing their anit-zorching ASICs.

Mike 



From nick at foobar.org  Mon Sep 12 14:35:14 2011
From: nick at foobar.org (Nick Hilliard)
Date: Mon, 12 Sep 2011 20:35:14 +0100
Subject: vyatta for bgp
In-Reply-To: <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
Message-ID: <4E6E5EF2.9040502@foobar.org>

On 12/09/2011 20:08, Michael K. Smith - Adhost wrote:
> How do you come to this conclusion?  I think a software-based router for
> enterprise level (let's say on the 1G per provider level) can handle a
> fair amount of zorching.

I presume by "a fair amount", I presume you mean "barely any"?

At large packet sizes, an "enterprise level" router will just about handle
a 1G DoS attack.  Thing is, bandwidth DoS / DDoS is sufficiently easy to
pull off on a large scale that a 1G DoS is pretty easy.

Incidentally, most service providers use "enterprise level" as a by-word
for mediocre quality kit, lacking in both stability and useful features.

Nick


From rdobbins at arbor.net  Mon Sep 12 14:35:59 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 12 Sep 2011 19:35:59 +0000
Subject: vyatta for bgp
In-Reply-To: <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
Message-ID: <3D7E4228-A457-44D2-82C0-10CCE5B2B1EE@arbor.net>

On Sep 13, 2011, at 2:08 AM, Michael K. Smith - Adhost wrote:

> How do you come to this conclusion?

Unhappy experiences.

;>

>  I think a software-based router for enterprise level (let's say on the 1G per provider level) can handle a fair amount of zorching.

My experiences indicates otherwise, FWIW.  It's very easy to packet a software-based router over a relatively small transit link in the mb/sec range, much less gb/sec - it happens all the time, FYI.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From jared at compuwizz.net  Mon Sep 12 14:41:23 2011
From: jared at compuwizz.net (Jared Geiger)
Date: Mon, 12 Sep 2011 15:41:23 -0400
Subject: vyatta for bgp
In-Reply-To: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
Message-ID: <CAHuchRDj-gQgD9Et-rjw_RPKJp0UHc=FkT2fbrNMudPBCBYaCA@mail.gmail.com>

On Mon, Sep 12, 2011 at 2:42 PM, Ben Albee <balbee at orscheln.com> wrote:

> Does anybody currently use vyatta as a bgp router for their company? If
> so have you ran into any problems with using that instead of a cisco or
> juniper router?
>
>
There was a bug where you couldn't use two IPv4 peers and then add IPv6. I
haven't tested the newest versions yet to see if it still exists. Works
great for two IPv4 peers.

From owen at delong.com  Mon Sep 12 14:45:18 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Sep 2011 12:45:18 -0700
Subject: vyatta for bgp
In-Reply-To: <4E6E5EF2.9040502@foobar.org>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
Message-ID: <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>


On Sep 12, 2011, at 12:35 PM, Nick Hilliard wrote:

> On 12/09/2011 20:08, Michael K. Smith - Adhost wrote:
>> How do you come to this conclusion?  I think a software-based router for
>> enterprise level (let's say on the 1G per provider level) can handle a
>> fair amount of zorching.
> 
> I presume by "a fair amount", I presume you mean "barely any"?
> 
> At large packet sizes, an "enterprise level" router will just about handle
> a 1G DoS attack.  Thing is, bandwidth DoS / DDoS is sufficiently easy to
> pull off on a large scale that a 1G DoS is pretty easy.
> 
> Incidentally, most service providers use "enterprise level" as a by-word
> for mediocre quality kit, lacking in both stability and useful features.
> 
> Nick

In your typical enterprise environment, a 1G DoS will zorch the link long
before it zorches the router at the enterprise side.

I agree that software-based routers are not a good choice for a backbone
provider, but, for an enterprise that is dealing with <1gbps links coming
in from ?3 providers, the difference in cost makes a software router an
attractive option in many cases.

Of course it is important to understand the limitations of the solution you
choose, but, in such an environment, a USD100,000+ ASIC based router
may be like trying to kill a mosquito with a sledge hammer.

Owen

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

From lear at cisco.com  Mon Sep 12 14:53:59 2011
From: lear at cisco.com (Eliot Lear)
Date: Mon, 12 Sep 2011 21:53:59 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
 updates
In-Reply-To: <CAJNn=DNMrGC42i4Q_Wjvz-i9uV_4w1YnfM8vcX4g_wnXLoT=vA@mail.gmail.com>
References: <5.1.0.14.2.20110912080438.037715e8@efes.iucc.ac.il>
 <4E6DD13A.9050003@cisco.com>
 <CAJNn=DNMrGC42i4Q_Wjvz-i9uV_4w1YnfM8vcX4g_wnXLoT=vA@mail.gmail.com>
Message-ID: <4E6E6357.5010000@cisco.com>



On 9/12/11 4:32 PM, Jason Duerstock wrote:
> Except that this just shifts the burden of trust on to DNSSEC, which
> also necessitates a central authority of 'trust'.  Unless there's an
> explicitly more secure way of storing DNSSEC private keys, this just
> moves the bullseye from CAs to DNSSEC signers.

I said "some", not all, of the responsibility.  By adding an independent
PKI there is an additional control put in place to confirm that in fact
the signer is authorized to sign.  Should one go as far as to remove CA
caches from browsers altogether?

Eliot


From rdobbins at arbor.net  Mon Sep 12 15:12:43 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 12 Sep 2011 20:12:43 +0000
Subject: vyatta for bgp
In-Reply-To: <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
Message-ID: <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>

On Sep 13, 2011, at 2:45 AM, Owen DeLong wrote:

> In your typical enterprise environment, a 1G DoS will zorch the link long before it zorches the router at the enterprise side.

This contradicts my experience - I've repeatedly witnessed only a few mb/sec of 64-byte packets making software-based routers fall over, including just last month.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From mansaxel at besserwisser.org  Mon Sep 12 15:31:59 2011
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Mon, 12 Sep 2011 22:31:59 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <201109121146.04313.fredan-nanog@fredan.se>
References: <4E6CEDAB.4070307@bogus.com>
 <20110912043952.GA92788@blazingdot.com>
 <167272.1315816743@turing-police.cc.vt.edu>
 <201109121146.04313.fredan-nanog@fredan.se>
Message-ID: <20110912203159.GA31219@besserwisser.org>

Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy, releases Date: Mon, Sep 12, 2011 at 11:46:04AM +0200 Quoting fredrik danerklint (fredan-nanog at fredan.se):
> > > How about a TXT record with the CN string of the CA cert subject in it?
> > > If it exists and there's a conflict, don't trust it.  Seems simple
> > > enough to implement without too much collateral damage.
> > 
> > Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
> > to attacks via DNS poisoning (either insert a malicious TXT that matches
> > your malicious certificate, or insert a malicious TXT that intentionally
> > *doesn't* match the vicitm's certificate)....
> 
> And how do you validate the dnssec to make sure that noone has tampered with 
> it.

Since you are from Sweden, and in an IT job, you probably have personal
relations to someone who has personal relations to one of the swedes
or other nationalities that were present at the key ceremonies for the
root. Once you've established that the signatures on the root KSK are good
(which -- because of the above -- should be doable OOB quite easily for
you) you can start validating the entire chain of trust.

Quite trivial, in fact. 

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Am I in GRADUATE SCHOOL yet?
-------------- 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/20110912/8f41905e/attachment.bin>

From chuckchurch at gmail.com  Mon Sep 12 15:34:22 2011
From: chuckchurch at gmail.com (Chuck Church)
Date: Mon, 12 Sep 2011 16:34:22 -0400
Subject: vyatta for bgp
In-Reply-To: <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
Message-ID: <005101cc718b$5b7b93c0$1272bb40$@com>

----Original Message-----
From: Dobbins, Roland [mailto:rdobbins at arbor.net] 
Sent: Monday, September 12, 2011 2:56 PM
To: North American Network Operators' Group
Subject: Re: vyatta for bgp

>zorched.

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

Zorch.  I like that.  Sounds like a Batman fight-scene bubble word.

Is the concern over a DDOS aimed against the router itself, or just massive
flows passing through?

Chuck



From Valdis.Kletnieks at vt.edu  Mon Sep 12 15:37:49 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 12 Sep 2011 16:37:49 -0400
Subject: vyatta for bgp
In-Reply-To: Your message of "Mon, 12 Sep 2011 20:12:43 -0000."
 <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
 <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>
Message-ID: <36336.1315859869@turing-police.cc.vt.edu>

On Mon, 12 Sep 2011 20:12:43 -0000, "Dobbins, Roland" said:
> This contradicts my experience - I've repeatedly witnessed only a few mb/sec
> of 64-byte packets making software-based routers fall over, including just last
> month.

On the flip side, there's a *lot* of sites that have to make trade-offs, and the
risk that their $10K software-based router may fall over doesn't justify adding
another zero to the price tag, especially if their network includes a lot of
branch offices that would all add another zero....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110912/31e8e44d/attachment.bin>

From rdobbins at arbor.net  Mon Sep 12 15:41:06 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 12 Sep 2011 20:41:06 +0000
Subject: vyatta for bgp
In-Reply-To: <005101cc718b$5b7b93c0$1272bb40$@com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <005101cc718b$5b7b93c0$1272bb40$@com>
Message-ID: <0DAD0C57-5E6E-4F64-8EE7-5ED315F70BBB@arbor.net>

On Sep 13, 2011, at 3:34 AM, Chuck Church wrote:

> Is the concern over a DDOS aimed against the router itself, or just massive flows passing through?

Yes, but mainly the former.

;>

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From Valdis.Kletnieks at vt.edu  Mon Sep 12 15:41:03 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 12 Sep 2011 16:41:03 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: Your message of "Mon, 12 Sep 2011 22:31:59 +0200."
 <20110912203159.GA31219@besserwisser.org>
References: <4E6CEDAB.4070307@bogus.com>
 <20110912043952.GA92788@blazingdot.com>
 <167272.1315816743@turing-police.cc.vt.edu>
 <201109121146.04313.fredan-nanog@fredan.se>
 <20110912203159.GA31219@besserwisser.org>
Message-ID: <36459.1315860063@turing-police.cc.vt.edu>

On Mon, 12 Sep 2011 22:31:59 +0200, M?ns Nilsson said:

> Since you are from Sweden, and in an IT job, you probably have personal
> relations to someone who has personal relations to one of the swedes
> or other nationalities that were present at the key ceremonies for the
> root. Once you've established that the signatures on the root KSK are good
> (which -- because of the above -- should be doable OOB quite easily for
> you) you can start validating the entire chain of trust.
> 
> Quite trivial, in fact.

I'll note that the PGP "strongly connected set" has grown all the way to 45,000
or so keys in 2 decades of growth.  There are several billion Internet users. What
may be workable for Fredrik is probably *not* scalable to Joe Sixpack.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110912/a17bcf66/attachment.bin>

From everton.marques at gmail.com  Mon Sep 12 15:43:44 2011
From: everton.marques at gmail.com (Everton Marques)
Date: Mon, 12 Sep 2011 17:43:44 -0300
Subject: vyatta for bgp
In-Reply-To: <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
 <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>
Message-ID: <CAFn5mmHdu8XGJtwukU8y80H74aK0-c0kKupyAye2XXPSM7h3CQ@mail.gmail.com>

On Mon, Sep 12, 2011 at 5:12 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
> On Sep 13, 2011, at 2:45 AM, Owen DeLong wrote:
>
>> In your typical enterprise environment, a 1G DoS will zorch the link long before it zorches the router at the enterprise side.
>
> This contradicts my experience - I've repeatedly witnessed only a few mb/sec of 64-byte packets making software-based routers fall over, including just last month.

Would Cisco ISR G2 3925E classify as software-based router?
Expected NDR performance is about 1845 pps (64-byte packets).
That should deliver room for some 100s of Mbps.
Do you expect it to bend itself down under a few Mbps of 64-byte packets?

http://www.anticisco.ru/pubs/ISR_G2_Perfomance.pdf

Everton


From fredan-nanog at fredan.se  Mon Sep 12 15:42:35 2011
From: fredan-nanog at fredan.se (fredrik danerklint)
Date: Mon, 12 Sep 2011 22:42:35 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <20110912203159.GA31219@besserwisser.org>
References: <4E6CEDAB.4070307@bogus.com>
 <201109121146.04313.fredan-nanog@fredan.se>
 <20110912203159.GA31219@besserwisser.org>
Message-ID: <201109122242.35932.fredan-nanog@fredan.se>

> > > > How about a TXT record with the CN string of the CA cert subject in
> > > > it? If it exists and there's a conflict, don't trust it.  Seems
> > > > simple enough to implement without too much collateral damage.
> > > 
> > > Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
> > > to attacks via DNS poisoning (either insert a malicious TXT that
> > > matches your malicious certificate, or insert a malicious TXT that
> > > intentionally *doesn't* match the vicitm's certificate)....
> > 
> > And how do you validate the dnssec to make sure that noone has tampered
> > with it.
> 
> Since you are from Sweden, and in an IT job, you probably have personal
> relations to someone who has personal relations to one of the swedes
> or other nationalities that were present at the key ceremonies for the
> root. Once you've established that the signatures on the root KSK are good
> (which -- because of the above -- should be doable OOB quite easily for
> you) you can start validating the entire chain of trust.
> 
> Quite trivial, in fact.

and how about a end user, who doesn't understand a computer at all, to be able 
verify the signatures, correctly?

-- 
//fredan


From balbee at orscheln.com  Mon Sep 12 15:52:57 2011
From: balbee at orscheln.com (Ben Albee)
Date: Mon, 12 Sep 2011 15:52:57 -0500
Subject: vyatta for bgp 
Message-ID: <625DBB8B2639984C8DA8F8EB45A39BB60610DE99@neuman.orscheln.oi.local>

Thanks for the all the feed-back. 

 

We will only have two ipv4 BGP peers (both 5mb/sec links) to the same
ISP. We are doing BGP because we plan to add a second ISP at one of our
locations in the future.  We are not any near a large enterprise, this
will be replacing two DSL lines and a T1. 


From rdobbins at arbor.net  Mon Sep 12 15:52:54 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 12 Sep 2011 20:52:54 +0000
Subject: vyatta for bgp
In-Reply-To: <CAFn5mmHdu8XGJtwukU8y80H74aK0-c0kKupyAye2XXPSM7h3CQ@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
 <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>
 <CAFn5mmHdu8XGJtwukU8y80H74aK0-c0kKupyAye2XXPSM7h3CQ@mail.gmail.com>
Message-ID: <8183E51F-9630-4F4F-807F-C40CBADD57EE@arbor.net>

On Sep 13, 2011, at 3:43 AM, Everton Marques wrote:

> Would Cisco ISR G2 3925E classify as software-based router?

Yes.

> Do you expect it to bend itself down under a few Mbps of 64-byte packets?

Especially if they're directed at the router itself, at some point, sure - though the ISR2 certainly has more horsepower than the original ISRs, and I've personally yet to witness an ISR2 being DDoSed, so I've no feel for the specific numbers.  Features also play a role.

This isn't to say that the ISR2 isn't a fine router - but rather that one must be cognizant of performance envelopes prior to deployment in order to determine suitability to purpose.  One can't reasonably expect vendors to exceed their design constraints in any type of equipment.

;>

One can and should test the specific performance envelope of any prospective infrastructure purchase, of course.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From michael at rancid.berkeley.edu  Mon Sep 12 15:58:30 2011
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Mon, 12 Sep 2011 13:58:30 -0700
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <1315847639.4599.89.camel@m6.u226.com>
References: <1315842056.4599.49.camel@m6.u226.com>
 <4E6E3088.7010109@unfix.org> <1315847639.4599.89.camel@m6.u226.com>
Message-ID: <4E6E7276.2070106@rancid.berkeley.edu>

On 09/12/11 10:13, Always Learning wrote:

> Primarily IP ranges to block and/or abuse email addresses.
>
>>   https://www.arin.net/participate/mailing_lists/
>
> Thank you.  I will try it.
>
>> Oh, and there they also like to see your real name and not a junk mail
>> address. Just like on the RIPE mailinglists, you know in the old country.
>
> The ARIN web page http://lists.arin.net/mailman/listinfo/arin-ppml
> states
>
> 	Your name (optional):

I think arin-discuss would be a better place for this than arin-ppml.

> The 'old country' sounds a bit South African to me. I'm European and
> English.

I think Jeroen's point was that you didn't need to pass judgement on all 
of North America and/or the USA because ARIN did something you didn't like.

michael


From mansaxel at besserwisser.org  Mon Sep 12 16:03:36 2011
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Mon, 12 Sep 2011 23:03:36 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <201109122242.35932.fredan-nanog@fredan.se>
References: <4E6CEDAB.4070307@bogus.com>
 <201109121146.04313.fredan-nanog@fredan.se>
 <20110912203159.GA31219@besserwisser.org>
 <201109122242.35932.fredan-nanog@fredan.se>
Message-ID: <20110912210336.GB31219@besserwisser.org>

Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy, releases Date: Mon, Sep 12, 2011 at 10:42:35PM +0200 Quoting fredrik danerklint (fredan-nanog at fredan.se):

> > Quite trivial, in fact.
> 
> and how about a end user, who doesn't understand a computer at all, to be able 
> verify the signatures, correctly?

Joe Sixpack clicks through today. He will, too, later, but, one of
the Fine Things with DANE is that no entity can produce valid data for
anything outside its own domain(s). Damage limitation is quite important,
while admittingly not being the silver bullet.

The existence of a free and secure chain of trust will put a price
pressure on DV certificates, which just might create a situation where
the marginal cost for doing TLS is so low that it is hard to set up a
web site without.

Taken together, this creates a situation where valid, verified
certificates are the norm, for real, which makes it all the more possible
to flag the exceptions much more annoyingly. Perhaps even refuse to
open them.
-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
... this must be what it's like to be a COLLEGE GRADUATE!!
-------------- 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/20110912/028e7f17/attachment.bin>

From randy at psg.com  Mon Sep 12 16:05:51 2011
From: randy at psg.com (Randy Bush)
Date: Mon, 12 Sep 2011 23:05:51 +0200
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <4E6E4257.3060103@foobar.org>
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
 <4E6E4257.3060103@foobar.org>
Message-ID: <m2ehzlqxn4.wl%randy@psg.com>

>> Now, I agree on the part that ARIN should be doing RPSL, or even
>> more, just start using the RIPE whois server for serving their data.
> Now wait one moment until I bog you down with 20 years worth of legacy
> paranoia, "Not Invented Here" and useless history about why this
> shouldn't ever have happened...

you omitted looking at the code

randy


From jasper at pointless.net  Mon Sep 12 16:08:23 2011
From: jasper at pointless.net (Jasper Wallace)
Date: Mon, 12 Sep 2011 22:08:23 +0100 (BST)
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
Message-ID: <alpine.DEB.2.00.1109122203120.2129@ybpnyubfg>

On Mon, 12 Sep 2011, Gregory Edigarov wrote:

> On Mon, 12 Sep 2011 12:12:08 +0200
> Martin Millnert <millnert at gmail.com> wrote:
> 
> > Mike,
> > 
> > On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones <mike at mikejones.in> wrote:
> > > It will take a while to get updated browsers rolled out to enough
> > > users for it do be practical to start using DNS based self-signed
> > > certificated instead of CA-Signed certificates, so why don't any
> > > browsers have support yet? are any of them working on it?
> > 
> > Chrome v 14 works with DNS stapled certificates, sort of a hack. (
> > http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )
> > 
> > There are other proposals/ideas out there, completely different to
> > DANE / DNSSEC, like http://perspectives-project.org/ /
> > http://convergence.io/ .
> 
> I.e. instead of a set of trusted CAs there will be one distributed net
> of servers, that act as a cert storage?
> I do not see how that could help...

The point of perspectives and convergence is this. The browser says:

>From my point of view site X has a certificate with fingerprint Y, what do 
you guys all see from your points of view?

If the perspectives/convergence servers see a different certificate then 
you know that you are the victim of a mitm attack..

I.E. the perspectives and convergence system does not attempt to assert 
anything about a sites identity, just that everyone sees the same cert for 
a site.

(of course if the mitm is happening close enough to the site 
networktopologicly speaking than all the perspectives/convergence servers 
will see the same, fake, cert and your out of luck).

> Well, I do not even see how can one trust any certificate that is
> issued by commercial organization. 

perspectives and convergence don't issue certs.

-- 
[http://pointless.net/]                                   [0x2ECA0975]


From brent at servuhome.net  Mon Sep 12 16:13:40 2011
From: brent at servuhome.net (Brent Jones)
Date: Mon, 12 Sep 2011 14:13:40 -0700
Subject: vyatta for bgp
In-Reply-To: <8183E51F-9630-4F4F-807F-C40CBADD57EE@arbor.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
 <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>
 <CAFn5mmHdu8XGJtwukU8y80H74aK0-c0kKupyAye2XXPSM7h3CQ@mail.gmail.com>
 <8183E51F-9630-4F4F-807F-C40CBADD57EE@arbor.net>
Message-ID: <CAHhm0WQqsBD3N+cUwpNJKoKNeMAdeUtRy-UAtmFAannkhA3_Bw@mail.gmail.com>

On Mon, Sep 12, 2011 at 1:52 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
> On Sep 13, 2011, at 3:43 AM, Everton Marques wrote:
>
>> Would Cisco ISR G2 3925E classify as software-based router?
>
> Yes.
>
>> Do you expect it to bend itself down under a few Mbps of 64-byte packets?
>
> Especially if they're directed at the router itself, at some point, sure - though the ISR2 certainly has more horsepower than the original ISRs, and I've personally yet to witness an ISR2 being DDoSed, so I've no feel for the specific numbers. ?Features also play a role.
>
> This isn't to say that the ISR2 isn't a fine router - but rather that one must be cognizant of performance envelopes prior to deployment in order to determine suitability to purpose. ?One can't reasonably expect vendors to exceed their design constraints in any type of equipment.
>
> ;>
>
> One can and should test the specific performance envelope of any prospective infrastructure purchase, of course.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
> ? ? ? ? ? ? ? ?The basis of optimism is sheer terror.
>
> ? ? ? ? ? ? ? ? ? ? ? ? ?-- Oscar Wilde
>
>
>

Lots of devices can have trouble if you direct high PPS to the control
plane, and will exhibit performance degradation, leading up to a DoS
eventually.
That isn't limited to software based routers at all, it will impact
dedicated ASICs. Vendors put together solutions for this, to protect
the router itself/control plane, whether its a software based routed
or ASICs.
Now if this was a Microtik with an 1Ghz Intel Atom CPU, sure, lots of
things could take that thing offline, even funny looks. But a modern,
multi-core/multi-thread system with multi-queued NICs will handle
hundreds of thousands of PPS directed to the router itself before
having issues, of nearly any packet size.
A high end ASIC can handle millions/tens of millions PPS, but directed
to the control plane (which is often a general purpose CPU as well,
Intel or PowerPC), probably not in most scenarios.

I think its very fair for a small/medium sized organization to run
software based routers, Vyatta included.

-- 
Brent Jones
brent at servuhome.net


From markk at arin.net  Mon Sep 12 16:14:54 2011
From: markk at arin.net (Mark Kosters)
Date: Mon, 12 Sep 2011 21:14:54 +0000
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <4E6E7276.2070106@rancid.berkeley.edu>
Message-ID: <CA93EB60.463DC%markk@arin.net>

On 9/12/11 4:58 PM, "Michael Sinatra" <michael at rancid.berkeley.edu> wrote:

>On 09/12/11 10:13, Always Learning wrote:
>
>> Primarily IP ranges to block and/or abuse email addresses.
>>
>>>   https://www.arin.net/participate/mailing_lists/
>>
>> Thank you.  I will try it.
>>
>>> Oh, and there they also like to see your real name and not a junk mail
>>> address. Just like on the RIPE mailinglists, you know in the old
>>>country.
>>
>> The ARIN web page http://lists.arin.net/mailman/listinfo/arin-ppml
>> states
>>
>> 	Your name (optional):
>
>I think arin-discuss would be a better place for this than arin-ppml.

Actually, I think the best place to have this particular conversation is
arin-tech-discuss. ARIN engineering hangs out there and does respond. I'm
not sure if all of NANOG wants to hear about the various behaviors of
different whois clients dealing with different whois servers around the
globe. If you are interested in the more global whois directory service
problem, there is emerging work going on in the IETF to tackle the
directory service problem called WEIRDS.

Regards,
Mark
ARIN CTO



From rdobbins at arbor.net  Mon Sep 12 16:27:32 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 12 Sep 2011 21:27:32 +0000
Subject: vyatta for bgp
In-Reply-To: <CAHhm0WQqsBD3N+cUwpNJKoKNeMAdeUtRy-UAtmFAannkhA3_Bw@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
 <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>
 <CAFn5mmHdu8XGJtwukU8y80H74aK0-c0kKupyAye2XXPSM7h3CQ@mail.gmail.com>
 <8183E51F-9630-4F4F-807F-C40CBADD57EE@arbor.net>
 <CAHhm0WQqsBD3N+cUwpNJKoKNeMAdeUtRy-UAtmFAannkhA3_Bw@mail.gmail.com>
Message-ID: <F3A9017F-0F85-4033-8477-E0F1F88B2788@arbor.net>

On Sep 13, 2011, at 4:13 AM, Brent Jones wrote:

> A high end ASIC can handle millions/tens of millions PPS, but directed
> to the control plane (which is often a general purpose CPU as well,
> Intel or PowerPC), probably not in most scenarios.

CoPP.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From dmm at 1-4-5.net  Mon Sep 12 16:28:03 2011
From: dmm at 1-4-5.net (David Meyer)
Date: Mon, 12 Sep 2011 14:28:03 -0700
Subject: [NANOG-announce] NANOG 53 draft agenda available
Message-ID: <CAHiKxWhCt8qGN6bZtzzje-HzHgpbicMjBPV1hMzGzpdxb1iqnA@mail.gmail.com>

Please see http://www.nanog.org/meetings/nanog53/agenda.html.

Note that the Loews room block expires on 09/23/2011. Note also that
the standard registration fee runs through 10/04/2011.

Looking forward to seeing you in Philadelphia.

Thanks,

Dave

(for the NANOG PC)

_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce


From randy at psg.com  Mon Sep 12 16:28:07 2011
From: randy at psg.com (Randy Bush)
Date: Mon, 12 Sep 2011 23:28:07 +0200
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CA93EB60.463DC%markk@arin.net>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
Message-ID: <m262kxqwm0.wl%randy@psg.com>

> I'm not sure if all of NANOG wants to hear about the various behaviors
> of different whois clients dealing with different whois servers around
> the globe.

i doubt if there is anything which *all* of nanog wants to hear.

but i suspect a damned lot of us care about whois behavior, as we either
deal with whois (i do daily) or help our csas and nocs who do.

randy


From millnert at gmail.com  Mon Sep 12 16:36:54 2011
From: millnert at gmail.com (Martin Millnert)
Date: Mon, 12 Sep 2011 23:36:54 +0200
Subject: vyatta for bgp
In-Reply-To: <CAHhm0WQqsBD3N+cUwpNJKoKNeMAdeUtRy-UAtmFAannkhA3_Bw@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
 <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>
 <CAFn5mmHdu8XGJtwukU8y80H74aK0-c0kKupyAye2XXPSM7h3CQ@mail.gmail.com>
 <8183E51F-9630-4F4F-807F-C40CBADD57EE@arbor.net>
 <CAHhm0WQqsBD3N+cUwpNJKoKNeMAdeUtRy-UAtmFAannkhA3_Bw@mail.gmail.com>
Message-ID: <CAHyNd15vrhUx55fyiOg5DCeqN0oE_xsQ=SORm1jd_nkKW=vxcQ@mail.gmail.com>

Brent,

On Mon, Sep 12, 2011 at 11:13 PM, Brent Jones <brent at servuhome.net> wrote:
> Lots of devices can have trouble if you direct high PPS to the control
> plane, and will exhibit performance degradation, leading up to a DoS
> eventually.
> That isn't limited to software based routers at all, it will impact
> dedicated ASICs. Vendors put together solutions for this, to protect
> the router itself/control plane, whether its a software based routed
> or ASICs.
> Now if this was a Microtik with an 1Ghz Intel Atom CPU, sure, lots of
> things could take that thing offline, even funny looks. But a modern,
> multi-core/multi-thread system with multi-queued NICs will handle
> hundreds of thousands of PPS directed to the router itself before
> having issues, of nearly any packet size.
> A high end ASIC can handle millions/tens of millions PPS, but directed
> to the control plane (which is often a general purpose CPU as well,
> Intel or PowerPC), probably not in most scenarios.
>
> I think its very fair for a small/medium sized organization to run
> software based routers, Vyatta included.
>

Speaking of Mikrotik there, I recently pushed 350kpps small packets
through an x86 routeros image running under kvm (using vt-d for nic)
on my desktop machine (which is a number i seem to run into more than
once when it comes to linux/linux-derivative forwarding on single
queue & core). I saw a release note claiming their next sw release
will do 15-20% more on both mips and x86. Unsurprisingly is open
source software forwarding very far from 10G linerate of small pps
through single cpu core still.
350kpps of 64B packets is of course merely 180 Mbps (notably, actually
sufficient for handling incoming small packets on a 100 Mbps uplink).

Re adversaries or random scum filling your uplinks with useless bits,
I think I hear the largest DDoS'es now have filled 100G links, so..
don't make yourself a packeting target if you happen to run smaller
links than that? :)

Generally on staying alive through DDoS by anything else than some
degree of luck, I guess having more bandwith between your network and
your peers than what your peers all have to their peers is advised
(the statement could possibly be improved upon using some minimum cut
graph theory language).

Best,
Martin


From dot at dotat.at  Mon Sep 12 16:37:18 2011
From: dot at dotat.at (Tony Finch)
Date: Mon, 12 Sep 2011 22:37:18 +0100
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
Message-ID: <alpine.LSU.2.00.1109122232100.24644@hermes-2.csi.cam.ac.uk>

Mike Jones <mike at mikejones.in> wrote:
>
> DNSSEC deployment is advanced enough now to do that automatically at the
> client.

Sadly not quite. DNSSEC does have the potential to provide an alternative
public key infrastructure, and I'm keen to see that happen. But although
it works well between authoritative servers and recursive resolvers, there
are a lot of shitty DNS forwardersin CPE and captive portals and so on
which do not understand DNSSEC. And DNSSEC does not work unless all the
forwarders and recursors that you are using support it. So DNSSEC on the
client has a long way to go.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Hebrides, Southeast Bailey: Westerly 5 to 7 until later in south Hebrides,
otherwise northwesterly 3 or 4, increasing 5 to 7. Rough or very rough,
occasionally high in south Hebrides. Rain or showers. Good, occasionally
poor.


From nick at foobar.org  Mon Sep 12 16:38:57 2011
From: nick at foobar.org (Nick Hilliard)
Date: Mon, 12 Sep 2011 22:38:57 +0100
Subject: vyatta for bgp
In-Reply-To: <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
Message-ID: <4E6E7BF1.2050903@foobar.org>

On 12/09/2011 20:45, Owen DeLong wrote:
> In your typical enterprise environment, a 1G DoS will zorch the link long
> before it zorches the router at the enterprise side.

It sure will, unless you have multiple 1G links into your router, in which
case the ddos will effectively trash all the links.

> I agree that software-based routers are not a good choice for a backbone
> provider, but, for an enterprise that is dealing with <1gbps links coming
> in from ?3 providers, the difference in cost makes a software router an
> attractive option in many cases.
> 
> Of course it is important to understand the limitations of the solution you
> choose, but, in such an environment, a USD100,000+ ASIC based router
> may be like trying to kill a mosquito with a sledge hammer.

Indeed - as you implicitly point out, it's a cost / benefit thing.  So then
the question becomes this: for the set of organisations which are large
enough to warrant multiple 1G upstreams, how long an outage can they
sustain before the price difference becomes worth it?

Let's throw some figures around (ridiculously simplified):  a company has a
choice between a pair of $10k software routers or something like a pair of
MX80s for $25k each.  So, one solution costs $20k; the other $50k.  $30k
cost difference works out as $625 per month depreciation (4 year).  I.e.
not going to affect the bottom line in any meaningful way.

Now say that this company has a DoS attack for 24h, and the company
effectively loses one day of revenue.  On the basis that there are 260
office working days per year, the point at which spending an extra $30k for
a hardware router would be of net benefit to the company would be 260*30k =
$7.8m.  I.e. if your annual revenue is higher than that, and if spending
that cash would mitigate against your DoS problems, then it would be worth
your while in terms of direct loss mitigation.

Of course, this analysis is quite simplistic and excludes things like
damage to reputation, online stores, the likelihood of DoS attacks
happening in the first place, the cost of transit and many other points of
reality.  However, the point is that the break-even point for getting
serious horsepower for your transit requirements is surprisingly low once
you take into account the relationship between functional corporate
internet connectivity and either or both of corporate revenue and corporate
productivity.

It's extraordinary how much attention senior management starts paying when
everyone in the office starts twiddling their thumbs because connectivity
has been down for the day.

Nick



From dmm at 1-4-5.net  Mon Sep 12 16:44:56 2011
From: dmm at 1-4-5.net (David Meyer)
Date: Mon, 12 Sep 2011 14:44:56 -0700
Subject: [NANOG-announce] NANOG 53 draft agenda available
In-Reply-To: <20110912214016.GL6700@trace.bind.com>
References: <CAHiKxWhCt8qGN6bZtzzje-HzHgpbicMjBPV1hMzGzpdxb1iqnA@mail.gmail.com>
 <20110912214016.GL6700@trace.bind.com>
Message-ID: <CAHiKxWiqPQ2zas-k+o7h6-p5uA-FFugySBL_rTKgaw6N=4sw2w@mail.gmail.com>

 Sure. NANOG support can you update please?

Thanks,

Dave

On Mon, Sep 12, 2011 at 2:40 PM, Aaron Hughes <aaronh at bind.com> wrote:
> David,
>
> I am also running the Peering Track (which will be good for IXs and such to know to contact me ahead of time). Can you please add 'Aaron Hughes, CTO 6connect' to the Peering Track as well?
>
> Thanks!
>
> Cheers,
> Aaron
>
> On Mon, Sep 12, 2011 at 02:28:03PM -0700, David Meyer wrote:
>> Please see http://www.nanog.org/meetings/nanog53/agenda.html.
>>
>> Note that the Loews room block expires on 09/23/2011. Note also that
>> the standard registration fee runs through 10/04/2011.
>>
>> Looking forward to seeing you in Philadelphia.
>>
>> Thanks,
>>
>> Dave
>>
>> (for the NANOG PC)
>>
>> --
>> NANOG-announce mailing list
>> NANOG-announce at nanog.org
>> https://mailman.nanog.org/mailman/listinfo/nanog-announce
>
> --
>
> Aaron Hughes
> aaronh at bind.com
> +1-831-824-4161
> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
> http://www.bind.com/
>

_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce


From dot at dotat.at  Mon Sep 12 16:51:04 2011
From: dot at dotat.at (Tony Finch)
Date: Mon, 12 Sep 2011 22:51:04 +0100
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <201109122242.35932.fredan-nanog@fredan.se>
References: <4E6CEDAB.4070307@bogus.com>
 <201109121146.04313.fredan-nanog@fredan.se>
 <20110912203159.GA31219@besserwisser.org>
 <201109122242.35932.fredan-nanog@fredan.se>
Message-ID: <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>

fredrik danerklint <fredan-nanog at fredan.se> wrote:
>
> and how about a end user, who doesn't understand a computer at all, to
> be able verify the signatures, correctly?

The current trust model for DNSSEC relies on the vendor of the validator
to bootstrap trust in the root key. This is partly a matter of pragmatism
since the validator is a black-box agent acting on the user's behalf, like
any other software.

It is also required by the root key management policies, since a root key
rollover takes a small number of weeks, much shorter than the
not-in-service shelf life of validating software and hardware. This means
that a validator cannot simply use the root key as a trust anchor and
expect to work: it needs some extra infrastructure supported by the vendor
to authenticate the root key if there happens to have been a rollover
between finalizing the software and deploying it.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Biscay, FitzRoy: Southwesterly 4 or 5, veering northerly or northwesterly 5 or
6, occasionally 7 later in southeast Fitzroy. Rough or very rough. Rain or
showers. Good, occasionally poor.


From dot at dotat.at  Mon Sep 12 17:00:47 2011
From: dot at dotat.at (Tony Finch)
Date: Mon, 12 Sep 2011 23:00:47 +0100
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <4E6E20C7.9030905@mtcc.com>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
 <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>
 <m2fwk1kecp.wl%randy@psg.com> <4E6E1D05.3050902@mtcc.com>
 <m2d3f5kduf.wl%randy@psg.com> <4E6E20C7.9030905@mtcc.com>
Message-ID: <alpine.LSU.2.00.1109122253100.24644@hermes-2.csi.cam.ac.uk>

> > > > with dane, i trust whoever runs dns for citibank to identify the cert
> > > > for citibank.  this seems much more reasonable than other approaches,
> > > > though i admit to not having dived deeply into them all.
> > > If the root DNS keys were compromised in an all DNS rooted world...
> > > unhappiness would ensue in great volume.

Compromise of DNSSEC == compromise of one or more DNS registries.
This is a fate sharing situation. A few single points of failure
rather than hundreds.

Note that a big weak point in the DNS is the interface between the
registrars and the registry. If you have a domain you have to trust the
registry to impose suitable restrictions on its registrars to prevent a
dodgy registrar from stealing your domain. Another, of course, is the
interface between a registrar and its customers.

> It also drives up complexity too and makes you wonder what the added
> value of those cert vendors is for the money you're forking over.

During rollout the cert vendors will be providing backwards compatibility.

> Especially when you consider the criticality of dns naming for everything
> except web site host names using tls.

If a website using TLS loses its DNS then (a) you can't reach it, and (b)
the attacker can trivially obtain a new domain validated certificate.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Fisher, German Bight, Humber, Thames, Dover: Southwest 7 to severe gale 9.
Rough or very rough, becoming high in Fisher. Showers. Moderate or good.


From fredan-nanog at fredan.se  Mon Sep 12 17:04:39 2011
From: fredan-nanog at fredan.se (fredrik danerklint)
Date: Tue, 13 Sep 2011 00:04:39 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
Message-ID: <201109130004.40256.fredan-nanog@fredan.se>

Tony,

Thanks for this explanation! 

I think this is what I've been looking for regarding securing DNSSEC.


> > and how about a end user, who doesn't understand a computer at all, to
> > be able verify the signatures, correctly?
> 
> The current trust model for DNSSEC relies on the vendor of the validator
> to bootstrap trust in the root key. This is partly a matter of pragmatism
> since the validator is a black-box agent acting on the user's behalf, like
> any other software.
> 
> It is also required by the root key management policies, since a root key
> rollover takes a small number of weeks, much shorter than the
> not-in-service shelf life of validating software and hardware. This means
> that a validator cannot simply use the root key as a trust anchor and
> expect to work: it needs some extra infrastructure supported by the vendor
> to authenticate the root key if there happens to have been a rollover
> between finalizing the software and deploying it.
> 
> Tony.

-- 
//fredan


From marcus at blazingdot.com  Mon Sep 12 17:16:45 2011
From: marcus at blazingdot.com (Marcus Reid)
Date: Mon, 12 Sep 2011 22:16:45 +0000
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <alpine.LSU.2.00.1109122253100.24644@hermes-2.csi.cam.ac.uk>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
 <D181DDABABE57E4DB72FEE00331478643BDF6E@EALPO1.ukbroadband.com>
 <m2fwk1kecp.wl%randy@psg.com> <4E6E1D05.3050902@mtcc.com>
 <m2d3f5kduf.wl%randy@psg.com> <4E6E20C7.9030905@mtcc.com>
 <alpine.LSU.2.00.1109122253100.24644@hermes-2.csi.cam.ac.uk>
Message-ID: <20110912221645.GA98357@blazingdot.com>

On Mon, Sep 12, 2011 at 11:00:47PM +0100, Tony Finch wrote:
> Note that a big weak point in the DNS is the interface between the
> registrars and the registry. If you have a domain you have to trust the
> registry to impose suitable restrictions on its registrars to prevent a
> dodgy registrar from stealing your domain. Another, of course, is the
> interface between a registrar and its customers.

Just in case anybody missed it, ups.com, theregister.co.uk, and others
were hijacked in this way last week.

http://www.theregister.co.uk/2011/09/05/dns_hijack_service_updated/

Marcus


From mysidia at gmail.com  Mon Sep 12 18:02:27 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 12 Sep 2011 18:02:27 -0500
Subject: Why are we still using the CA model? (Re: Microsoft deems all
 DigiNotar certificates untrustworthy, releases updates)
In-Reply-To: <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
References: <CAAAas8Fua4EbjwKs_wkrcyr1Y6TqXQYNOAC5VGANKmh3hNSfUA@mail.gmail.com>
 <CAHyNd14PWaAgB6t8e0Z3PWc-GhhjXyNOydtB=H0f-2bYaLJ83A@mail.gmail.com>
 <20110912142317.7d4008a8@greg.bestnet.kharkov.ua>
Message-ID: <CAAAwwbUvjejkHdFno7Kmf0+ow_7GgEcmRS3U0d71BWoW4BsUqw@mail.gmail.com>

On Mon, Sep 12, 2011 at 6:23 AM, Gregory Edigarov
<greg at bestnet.kharkov.ua> wrote:
> I.e. instead of a set of trusted CAs there will be one distributed net
> of servers, that act as a cert storage?
> I do not see how that could help...
More lines of defense on top of the CA model.
Consider instead of abandoning the CA model altogether, you utilize
DNSSEC binding of the certificate
that must also be signed by a CA.

If _either_  the DNSSEC record isn't present,  doesn't validate,  OR
the certificate is not properly signed
by a CA,  then the certificate is considered invalid.

In this manner,   DNSSEC protects you against interception by a rogue
CA -- chances
are the rogue CA has not also discovered your DNSSEC secret keys,
and the  CA signature protects you against a compromise of the DNS, or an attack
by your domain registrar    --  your domain registrar is probably not
a CA and doesn't
have the right paperwork,
therefore can't get a CA signed certificate with your company's name.


The browsers then just need to revise their trust model  to require no
CA be affiliated with or
owned by any organization affiliated with a provider of domain
registration or DNS hosting services,
to ensure there's no domain registrar  entrusted to sign certs, and no
CA entrusted to maintain
DNSSEC data.

--
-JH


From mysidia at gmail.com  Mon Sep 12 18:39:41 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 12 Sep 2011 18:39:41 -0500
Subject: EV SSL Certs
In-Reply-To: <CAJS2yDtaDeEftM=kxZFc+fC5F2d8EjJoK0NrrWVYSChBQvfqYw@mail.gmail.com>
References: <CAJS2yDtaDeEftM=kxZFc+fC5F2d8EjJoK0NrrWVYSChBQvfqYw@mail.gmail.com>
Message-ID: <CAAAwwbWM3UPPYTbRcTAM9A1w0bVy0-CQStahJfBN+KV+c6extg@mail.gmail.com>

On Mon, Sep 12, 2011 at 7:08 AM, Coy Hile <coy.hile at coyhile.com> wrote:
> As an academic aside, exactly what would one set on his (internal)
> root CA so that internally-trusted certs signed by that CA would show
> up as EV certs?

This is not possible without changing browser source code and recompiling
(or debugging/editing the browser binary).
The IDs of certificates that are allowed to sign EVSSL CAs are
hard-wired in the browser.
In some browsers, this also means it's impossible for an end user to
"untrust"  or  remove
an EVSSL CA.

It also means you cannot as a site adminsitrator, make an
administrative decision to internally
add an internal EVSSL CA,  without customizing every browser.

If you ask me...  it's shoddy software design.   EVSSL CAs should be
configurable,
but none of the major browsers provide the knobs to  manually add or
remove EVSSL
access to/from a trusted CA.

--
-JH


From mysidia at gmail.com  Mon Sep 12 19:49:28 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 12 Sep 2011 19:49:28 -0500
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CA93EB60.463DC%markk@arin.net>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
Message-ID: <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>

>>I think arin-discuss would be a better place for this than arin-ppml.
You're suggesting using ARIN's private members-only mailing list over
a public one?
That doesn't make sense,  because this is a public issue, not a members issue.
PPML isn't right either, that's a numbering policy discussion list,
and this is an operational issue,
not a policy matter.

I think  this is a very simple matter, however...  in some way ARIN
changed their WHOIS service that introduced major
serious breakage.

They need to fix that and revert their WHOIS service to its original
query syntax and responses, which worked just fine.

--
-JH


From coy.hile at coyhile.com  Mon Sep 12 19:57:40 2011
From: coy.hile at coyhile.com (Coy Hile)
Date: Tue, 13 Sep 2011 00:57:40 +0000
Subject: EV SSL Certs
In-Reply-To: <CAAAwwbWM3UPPYTbRcTAM9A1w0bVy0-CQStahJfBN+KV+c6extg@mail.gmail.com>
References: <CAJS2yDtaDeEftM=kxZFc+fC5F2d8EjJoK0NrrWVYSChBQvfqYw@mail.gmail.com>
 <CAAAwwbWM3UPPYTbRcTAM9A1w0bVy0-CQStahJfBN+KV+c6extg@mail.gmail.com>
Message-ID: <CAJS2yDv+fJC2wmgNnimV=F7D7POakWNmR8oV-yzogBGxgjAseg@mail.gmail.com>

On Mon, Sep 12, 2011 at 11:39 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Mon, Sep 12, 2011 at 7:08 AM, Coy Hile <coy.hile at coyhile.com> wrote:
>> As an academic aside, exactly what would one set on his (internal)
>> root CA so that internally-trusted certs signed by that CA would show
>> up as EV certs?
>
> This is not possible without changing browser source code and recompiling
> (or debugging/editing the browser binary).
> The IDs of certificates that are allowed to sign EVSSL CAs are
> hard-wired in the browser.
> In some browsers, this also means it's impossible for an end user to
> "untrust" ?or ?remove
> an EVSSL CA.
>
> It also means you cannot as a site adminsitrator, make an
> administrative decision to internally
> add an internal EVSSL CA, ?without customizing every browser.
>
> If you ask me... ?it's shoddy software design. ? EVSSL CAs should be
> configurable,
> but none of the major browsers provide the knobs to ?manually add or
> remove EVSSL
> access to/from a trusted CA.
>

Thanks. I saw something about it on TechNet.  (I'm using Windows for
my internal CA).  I'm guessing those instructions may work for IE
only.  If I find anything interesting, I'll let you know.


From robert at vyatta.com  Mon Sep 12 20:03:59 2011
From: robert at vyatta.com (Robert Bays)
Date: Mon, 12 Sep 2011 18:03:59 -0700
Subject: vyatta for bgp
In-Reply-To: <C7EE963D-5836-43B1-8378-5D194F562FE0@vyatta.com>
References: <C7EE963D-5836-43B1-8378-5D194F562FE0@vyatta.com>
Message-ID: <03072071-E15F-424E-9945-239CDAE1E55C@vyatta.com>

> On Sep 13, 2011, at 2:45 AM, Roland Dobbins wrote:
> This contradicts my experience - I've repeatedly witnessed only a few mb/sec of 64-byte packets making software-based  routers fall over, including just last month.


It's easy to get 6Mpps using Vyatta or most other software based routers on modern server grade hardware.  If both your link and hardware capacity don't exceed the maximum load the bad guys can throw at you, then you are doomed to failure regardless without upstream cooperation.  In the case of an enterprise, neither of those two things are always guaranteed.  Software based routers work great for many use cases, it just depends on what you are looking for.  And sometimes they are the only option, for example as services migrate into the cloud.

Software based routers are only going to get better.  Roland, if you are in the Bay Area I invite you to drop by Vyatta HQ in Belmont and I will show you a demo of our next generation software which is doing an 5x increase in throughput over our last generation on the same off the shelf Intel X86 processors.  We expect that number to only increase over the short term.  Lot's of CPU horsepower solves a multitude of woes.

The one thing I do agree with you on is?
> One can and should test the specific performance envelope of any prospective infrastructure purchase, of course.

cheers,
robert.

From heather.schiller at verizon.com  Mon Sep 12 20:18:55 2011
From: heather.schiller at verizon.com (Schiller, Heather A)
Date: Mon, 12 Sep 2011 21:18:55 -0400
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24
In-Reply-To: <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
 <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
 <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
Message-ID: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F19D22DE@FHDP1LUMXC7V43.us.one.verizon.com>


Could be this..?

http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/configuration-statement/independent-domain-edit-routing-options.html  

"unrecognized transitive attributes" depend on whatever code version you are running... What's more important is how the unrecoginized attribute is handled.  Ideally you accept and pass the route and log it.  The problem is with devices that aren't so graceful.. dropping sessions and wreaking havoc:

http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml

--Heather 

-----Original Message-----
From: Aftab Siddiqui [mailto:aftab.siddiqui at gmail.com] 
Sent: Saturday, September 10, 2011 6:49 PM
To: Richard Barnes
Cc: Jonas Frey (Probe Networks); nanog at nanog.org
Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24

with in the span of couple of hours this prefix was originated from 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians).

As per the STC it was orginated by one of their customer having Juniper router. but I still don't understand why/how they are adv this prefix with unrecog transitive attributes.

Can any one suggest.

Regards,

Aftab A. Siddiqui


On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes <richard.barnes at gmail.com>wrote:

> Looks like the RIS collectors are seeing it originating mostly from 
> STC and KACST ASNs:
> <http://stat.ripe.net/212.118.142.0/24>
>
> Some of the "show ip bgp" reports on that screen are also showing
> AS8866 "BTC-AS Bulgarian Telecommunication Company".  Not sure what's 
> up with that.
>
> --Richard
>
>
>
> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow 
> <morrowc.lists at gmail.com> wrote:
> > On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren <pixitha.kyle at gmail.com>
> wrote:
> >> Is this announcement still showing up this way (no easy way to 
> >> check myself).
> >
> > ripe ris?
> >
> >> -Kyle
> >>
> >> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes 
> >> <chaynes at centracomm.net>
> wrote:
> >>
> >>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) < 
> >>> jf at probe-networks.de> wrote:
> >>>
> >>> > Hello,
> >>> >
> >>> > anyone else getting a route for 212.118.142.0/24 with invalid 
> >>> > attributes? Seems this is (again) causing problems with some 
> >>> > (older) routers/software.
> >>> >
> >>> >               Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 
> >>> > 1 6-Resolve tree 2
> >>> >                AS path: 6453 39386 25019 I Unrecognized Attributes:
> 39
> >>> > bytes
> >>> >                AS path:  Attr flags e0 code 80: 00 00 fd 88 40 
> >>> > 01 01
> 02
> >>> > 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 
> >>> > 40 05
> 04
> >>> > 00 00 00 64
> >>> >                Accepted Multipath
> >>> >
> >>> >
> >>> > -Jonas
> >>> >
> >>> >
> >>> Yup! We're seeing the same thing too, and we're filtering it out.
> >>> Originating AS is 25019
> >>>
> >>> -Clay
> >>>
> >>
> >
> >
>
>


From mysidia at gmail.com  Mon Sep 12 20:48:31 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 12 Sep 2011 20:48:31 -0500
Subject: vyatta for bgp
In-Reply-To: <4E6E5EF2.9040502@foobar.org>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
Message-ID: <CAAAwwbUKO+tnwkfUcZO9c6e6SkD_5e=dzU3xYCGr28bV00hB-w@mail.gmail.com>

On Mon, Sep 12, 2011 at 2:35 PM, Nick Hilliard <nick at foobar.org> wrote:
> I presume by "a fair amount", I presume you mean "barely any"?
> At large packet sizes, an "enterprise level" router will just about handle
> a 1G DoS attack. ?Thing is, bandwidth DoS / DDoS is sufficiently easy to
[snip]
How much "zorching" a software router can take  depends on a lot of factors.
If the hardware necessary to size appropriately for the link is
economical and sufficient,
zorching is not the largest concern.   1G link speed and 100M  link
speed offer very different
worst-case scenarios;  the link can be zorched long before the router is.

A software router running in a 32bit OS on an old Pentium 4   can take
a lot less zorching than a router running
on a server with  6-core  4Ghz  CPUs,  when interrupt coalescing is
present and utilized efficiently.

Hardware basic routers have a lower forwarding latency,  which makes
them more suitable for
ISP/carrier  networks,  the "hop delay" penalty is lower,  and  jitter
might be a concern on a router running
a non real-time OS such as a vanilla Linux kernel or other OS not
specially designed for the router task,
but there's otherwise nothing wrong with appropriately specc'ed
software forwarders.


One thing..  the OP was asking about anyone using Vyatta for BGP.
Using Vyatta for BGP doesn't necessarily mean the Vyatta unit is
actually a device
forwarding the packets...  someone could be using it as a route server, or for
otherwise populating forwarding  tables of other devices with
third-party next hops :-)


--
-JH


From tvarriale at comcast.net  Mon Sep 12 21:09:27 2011
From: tvarriale at comcast.net (Tony Varriale)
Date: Mon, 12 Sep 2011 21:09:27 -0500
Subject: vyatta for bgp
In-Reply-To: <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
 <572B9AAF-D885-49C0-9523-E5F18D71508D@arbor.net>
Message-ID: <4E6EBB57.6060206@comcast.net>

On 9/12/2011 3:12 PM, Dobbins, Roland wrote:
> On Sep 13, 2011, at 2:45 AM, Owen DeLong wrote:
>
>> In your typical enterprise environment, a 1G DoS will zorch the link long before it zorches the router at the enterprise side.
> This contradicts my experience - I've repeatedly witnessed only a few mb/sec of 64-byte packets making software-based routers fall over, including just last month.
>
> -----------------------------------------------------------------------
> Roland Dobbins<rdobbins at arbor.net>  //<http://www.arbornetworks.com>
>
> 		The basis of optimism is sheer terror.
>
> 			  -- Oscar Wilde
>
>
>
+1

tv


From michael at rancid.berkeley.edu  Mon Sep 12 22:07:07 2011
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Mon, 12 Sep 2011 20:07:07 -0700
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
Message-ID: <4E6EC8DB.4010602@rancid.berkeley.edu>

On 09/12/11 17:49, Jimmy Hess wrote:
>>> I think arin-discuss would be a better place for this than arin-ppml.
> You're suggesting using ARIN's private members-only mailing list over
> a public one?
> That doesn't make sense,  because this is a public issue, not a members issue.
> PPML isn't right either, that's a numbering policy discussion list,
> and this is an operational issue,
> not a policy matter.

I meant arin-tech-discuss, and Mark properly corrected me on that. 
arin-tech-discuss is a public mailing list, and much more appropriate 
for this sort of discussion than PPML.

> I think  this is a very simple matter, however...  in some way ARIN
> changed their WHOIS service that introduced major
> serious breakage.
>
> They need to fix that and revert their WHOIS service to its original
> query syntax and responses, which worked just fine.

Unfortunately, the original poster, against advice given to him, posted 
an insulting, jingoistic, inane, and even more derogatory version of his 
NANOG post, apparently in an effort to spur discussion.  What was once a 
legitimate issue (and I agree one that needs to be addressed) now looks 
more like troll-bait.  Unsurprisingly, nobody has responded.

michael


From ryan.g at atwgpc.net  Mon Sep 12 22:15:10 2011
From: ryan.g at atwgpc.net (Ryan Gelobter)
Date: Mon, 12 Sep 2011 22:15:10 -0500
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
Message-ID: <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>

I e-mailed Marco (md) the creator of 'whois' back in July when this started
and he stated he was going to try to work around the rWHOIS issue in the
next release. Sadly there hasn't been a new release yet but I am hopeful.

From nanog at u61.u22.net  Mon Sep 12 22:44:58 2011
From: nanog at u61.u22.net (Always Learning)
Date: Tue, 13 Sep 2011 04:44:58 +0100
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <4E6EC8DB.4010602@rancid.berkeley.edu>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <4E6EC8DB.4010602@rancid.berkeley.edu>
Message-ID: <1315885498.4599.204.camel@m6.u226.com>


On Mon, 2011-09-12 at 20:07 -0700, Michael Sinatra wrote:

> Unfortunately, the original poster, against advice given to him,
> posted an insulting, jingoistic, inane, and even more derogatory
> version of his NANOG post, apparently in an effort to spur discussion.
> What was once a legitimate issue (and I agree one that needs to be
> addressed) now looks more like troll-bait.  Unsurprisingly, nobody has
> responded.

I was attempting to write in 'Obama-style'.

I do make a perfectly valid point, perhaps oblivious to many North
Americans who generally are insular, that the world does expect the
Americans to do Internet things properly.

Many North Americans appear not to understand the general world-wide
attitude towards the USA. When something goes wrong at ARIN which
affects American IPs, the world seems to blame the Americans. Although
there is a clear distinction, certainly in my mind, between one rather
small organisation and a state of circa 280 million, never-the-less the
world generally blames the Americans. The only noticeable exception when
the USA is not blamed for the faults and omissions of an American
organisation is Micro$oft.

Why does it take the concerns of an European to waken-up the Americans
to the outstanding ARIN problem?  Perhaps some of you can continue the
campaign for the restoration of a basic North American WHOIS ?  The rest
of the world has a fully functioning WHOIS but not the USA (or Canada).

My posting was never meant to be insulting or jingoistic or inane and
certainly not derogatory. I was attempting to make those that can
influence ARIN have some pride in presenting their country's
achievements and services in the best possible way.

Like it or not, the Americans run the Internet: Google (the world's
biggest spying operation), Micro$oft, Facebook, Yahoo, Twitter, Ebay and
their Paypal, Cisco etc. etc. and of course ARIN.

> .... What was once a legitimate issue ....

Remains "a legitimate issue" until ARIN resolves it, if ever.


-- 
With best regards,

Paul.
England,
EU.




From bmanning at vacation.karoshi.com  Mon Sep 12 22:51:43 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 13 Sep 2011 03:51:43 +0000
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
Message-ID: <20110913035143.GB2014@vacation.karoshi.com.>

On Mon, Sep 12, 2011 at 10:15:10PM -0500, Ryan Gelobter wrote:
> I e-mailed Marco (md) the creator of 'whois' back in July when this started
> and he stated he was going to try to work around the rWHOIS issue in the
> next release. Sadly there hasn't been a new release yet but I am hopeful.

	I don't remember Marco creating "whois"...  
	there was the Network Service Center Phonebook - and Dan Long/BBN
	mashed it into something you could query ... like finger!  (circa 1990)

/bill


From tom at ninjabadger.net  Tue Sep 13 03:40:00 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Tue, 13 Sep 2011 09:40:00 +0100
Subject: vyatta for bgp
In-Reply-To: <CAHuchRDj-gQgD9Et-rjw_RPKJp0UHc=FkT2fbrNMudPBCBYaCA@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CAHuchRDj-gQgD9Et-rjw_RPKJp0UHc=FkT2fbrNMudPBCBYaCA@mail.gmail.com>
Message-ID: <1315903205.15284.0.camel@teh-desktop>

On Mon, 2011-09-12 at 15:41 -0400, Jared Geiger wrote:
> There was a bug where you couldn't use two IPv4 peers and then add
> IPv6. I haven't tested the newest versions yet to see if it still
> exists. Works great for two IPv4 peers.

Discussion between developers on bugfixes can often be seen in ##vyatta
on Freenode. :)

I find it interesting to idle/chime-in occasionally at least.

Tom



From ahebert at pubnix.net  Tue Sep 13 05:36:51 2011
From: ahebert at pubnix.net (Alain Hebert)
Date: Tue, 13 Sep 2011 06:36:51 -0400
Subject: vyatta for bgp
In-Reply-To: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
Message-ID: <4E6F3243.4080803@pubnix.net>

      Hi,

     In the past, I helped a few small ISP (sub 1Gbps) with software 
routers setup like Vyatta (Well FreeBSD/64 + Quagga really).

     Until recently the hardware required to run over 500Mbps + could be 
as pricey as a pair recycle Cisco 7206VXR since most MBs where coming 
with only 1 PCI busses which could kills the BW+PPS depending on the 
amount of interfaces you use.

     Now-a-days MBs with more than 1 PCI bus have become cheaper and 
shouldn't be a problem.

Its all in the setup anyway:

     2 servers ($3k each with 4 interface).
     Split your uplink on each router.
     1 link for "client-reflector" | OSPF | <whatever you like> between 
the router.
     VRRP back-end.

     PS: Sub 10Gbps, any DDoS will kill the link before killing those 
routers, but there is solutions to this which is hella-easy to deal with 
in this situation.

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


On 09/12/11 14:42, Ben Albee wrote:
> Does anybody currently use vyatta as a bgp router for their company? If
> so have you ran into any problems with using that instead of a cisco or
> juniper router?
>


From graham at g-rock.net  Tue Sep 13 07:16:24 2011
From: graham at g-rock.net (Graham Wooden)
Date: Tue, 13 Sep 2011 07:16:24 -0500
Subject: BGP Communities for H.E. and Deltacom?
Message-ID: <CA94B3C8.3EB40%graham@g-rock.net>

Hi there,

Any one know what are the acceptable BGP communities are for H.E. and
Deltacom?
At one of our POPs we?re using an aggregate provider and I need to help them
to fix some prefixes that I am announcing from another POP (ie. Lower the
metric so only use the backhaul for failure of the other side).

I was hoping that they would be listed on the One Step?s bgp community
listing.  Any links to such documents for both HE and Deltacom would be
great and would be much appreciated. Thank you,

-graham



From Valdis.Kletnieks at vt.edu  Tue Sep 13 09:17:39 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 13 Sep 2011 10:17:39 -0400
Subject: vyatta for bgp
In-Reply-To: Your message of "Mon, 12 Sep 2011 20:48:31 CDT."
 <CAAAwwbUKO+tnwkfUcZO9c6e6SkD_5e=dzU3xYCGr28bV00hB-w@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <CAAAwwbUKO+tnwkfUcZO9c6e6SkD_5e=dzU3xYCGr28bV00hB-w@mail.gmail.com>
Message-ID: <96796.1315923459@turing-police.cc.vt.edu>

On Mon, 12 Sep 2011 20:48:31 CDT, Jimmy Hess said:

> One thing..  the OP was asking about anyone using Vyatta for BGP.
> Using Vyatta for BGP doesn't necessarily mean the Vyatta unit is actually a device
> forwarding the packets...  someone could be using it as a route server, or for
> otherwise populating forwarding  tables of other devices with
> third-party next hops :-)

I would expect a properly configured Vyatta running as a route server
to be pretty darn near zortch-proof, no?  (Barring BGP packet-o-death
issues of course - but is there a router vendor who *hasn't* had at
least 2 or 3 of those? ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110913/b6ffba8f/attachment.bin>

From Valdis.Kletnieks at vt.edu  Tue Sep 13 09:21:22 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 13 Sep 2011 10:21:22 -0400
Subject: vyatta for bgp
In-Reply-To: Your message of "Mon, 12 Sep 2011 22:38:57 BST."
 <4E6E7BF1.2050903@foobar.org>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <D8CD26287252844898B508C40824D8F451C123@AD-EXH02.adhost.lan>
 <4E6E5EF2.9040502@foobar.org>
 <ECCC1534-4B5D-4DD4-8043-0B44278F4E32@delong.com>
 <4E6E7BF1.2050903@foobar.org>
Message-ID: <97172.1315923682@turing-police.cc.vt.edu>

On Mon, 12 Sep 2011 22:38:57 BST, Nick Hilliard said:

> Let's throw some figures around (ridiculously simplified):  a company has a
> choice between a pair of $10k software routers or something like a pair of
> MX80s for $25k each.  So, one solution costs $20k; the other $50k.  $30k
> cost difference works out as $625 per month depreciation (4 year).  I.e.
> not going to affect the bottom line in any meaningful way.
> 
> Now say that this company has a DoS attack for 24h, and the company
> effectively loses one day of revenue.  On the basis that there are 260
> office working days per year, the point at which spending an extra $30k for
> a hardware router would be of net benefit to the company would be 260*30k =
> $7.8m.  I.e. if your annual revenue is higher than that, and if spending
> that cash would mitigate against your DoS problems, then it would be worth
> your while in terms of direct loss mitigation.
> 
> Of course, this analysis is quite simplistic and excludes things like
> damage to reputation, online stores, the likelihood of DoS attacks
> happening in the first place, the cost of transit and many other points of
> reality.

One important thing it overlooks is what percent of DDoS attackqs are simple
"flood the pipe" attacks directed at a target behind the router.  If you got a
100M or  1G pipe to the outside world and you're getting hammered by multiple G
worth of packets, things are going to suck no matter what the router is.  And
let's face it, kicking that pipe to 10G is gonna cost a bit....

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

From oscar.vives at gmail.com  Tue Sep 13 09:29:30 2011
From: oscar.vives at gmail.com (Tei)
Date: Tue, 13 Sep 2011 16:29:30 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <201109130004.40256.fredan-nanog@fredan.se>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
Message-ID: <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>

*a random php programmer shows*

He, I just want to self-sign my CERT's and remove the ugly warning that
browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I
just don't want to use cleartext for internet data transfer.  HTTP is like
telnet, and HTTPS is like ssh. But with ssh is just can connect, with
browsers theres this ugly warning and "fuck you, self-signed certificate"
from the browsers.  Please make the pain stop!.

--Tei

-- 
--
?in del ?ensaje.

From cmadams at hiwaay.net  Tue Sep 13 09:45:39 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 13 Sep 2011 09:45:39 -0500
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
Message-ID: <20110913144538.GB19208@hiwaay.net>

Once upon a time, Tei <oscar.vives at gmail.com> said:
> He, I just want to self-sign my CERT's and remove the ugly warning that
> browsers shows.

SSL without some verification of the far end is useless, as a
man-in-the-middle attack can create self-signed certs just as easily.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From goldbe at cs.bu.edu  Tue Sep 13 09:45:33 2011
From: goldbe at cs.bu.edu (Sharon Goldberg)
Date: Tue, 13 Sep 2011 10:45:33 -0400
Subject: Soliciting your opinions on routing research: A routing policies
 survey
Message-ID: <CAJHGrrT01dbsywoguFasF=9a3b6cYfLcFx8cwhQ35o33Dw9f3A@mail.gmail.com>

Hi NANOG,

27 ops have already responded to our routing policies survey; we're
hoping to gather more responses before the week is over.  We're
collecting information about how you configure routing policies in
your network to improve the models we use in our research on routing
and security.  We'll also share the aggregated results with the NANOG
list.

The survey is anonymous and should take under 5 minutes to complete.
Feel free to answer all our questions, or just a few:
http://www.cs.toronto.edu/~phillipa/measurement/opsurvey/survey.php

We?d also be grateful if you could forward the survey to ops at other
organizations who may not be reading NANOG. Thanks all of you that
have responded so far!

Phillipa Gill (U of Toronto), Michael Schapira (Princeton), Sharon
Goldberg (Boston University)


From alter3d at alter3d.ca  Tue Sep 13 09:48:21 2011
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Tue, 13 Sep 2011 10:48:21 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
Message-ID: <4E6F6D35.2050201@alter3d.ca>

Really?  You can "just connect" with SSH?

root at somebox:~# ssh 1.2.3.4
The authenticity of host '1.2.3.4 (1.2.3.4)' can't be established.
RSA key fingerprint is 03:26:2c:b2:cd:fd:05:fc:87:70:4b:06:58:40:e7:c3.
Are you sure you want to continue connecting (yes/no)?

That's no different that having to permanently accept a self-signed SSL 
cert...

- Pete


On 9/13/2011 10:29 AM, Tei wrote:
> *a random php programmer shows*
>
> He, I just want to self-sign my CERT's and remove the ugly warning that
> browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I
> just don't want to use cleartext for internet data transfer.  HTTP is like
> telnet, and HTTPS is like ssh. But with ssh is just can connect, with
> browsers theres this ugly warning and "fuck you, self-signed certificate"
> from the browsers.  Please make the pain stop!.
>
> --Tei
>



From davei at otd.com  Tue Sep 13 09:54:25 2011
From: davei at otd.com (David Israel)
Date: Tue, 13 Sep 2011 10:54:25 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
Message-ID: <4E6F6EA1.3050500@otd.com>

On 9/13/2011 10:29 AM, Tei wrote:
> *a random php programmer shows*
>
> He, I just want to self-sign my CERT's and remove the ugly warning that
> browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I
> just don't want to use cleartext for internet data transfer.  HTTP is like
> telnet, and HTTPS is like ssh. But with ssh is just can connect, with
> browsers theres this ugly warning and "fuck you, self-signed certificate"
> from the browsers.  Please make the pain stop!.
>

With ssh, you will get a warning if the remote host key is not known, 
with a fingerprint and advice not to accept it if you don't know if it 
is correct.  This is a direct analog to the warning that the remote 
host's certificate cannot be verified.  In both cases, you are given the 
chance to accept the key/certificate and continue going; depending on 
the implementation, you might also be given the option to accept it once 
or forever.  Ssh is actually prone to bigger, uglier, more explicit "you 
probably don't want to trust this" warnings, especially about things 
like key changes.



From rbf+nanog at panix.com  Tue Sep 13 09:58:55 2011
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Tue, 13 Sep 2011 09:58:55 -0500
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <20110913144538.GB19208@hiwaay.net>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <20110913144538.GB19208@hiwaay.net>
Message-ID: <20110913145855.GA23605@panix.com>

On Tue, Sep 13, 2011 at 09:45:39AM -0500, Chris Adams wrote:
> Once upon a time, Tei <oscar.vives at gmail.com> said:
> > He, I just want to self-sign my CERT's and remove the ugly warning that
> > browsers shows.
> 
> SSL without some verification of the far end is useless, as a
> man-in-the-middle attack can create self-signed certs just as easily.

It protects against attacks where the attacker merely monitors the
traffic between the two endpoints.

As you suggest, it does not protect against MITM, but that's different
from being useless.  

The value of protecting against the former but not the latter may vary
by situation, but it's not always zero.  Not all attackers/attacks that
can sniff also have the capability and willingness to MITM.

(And even SSL w/ endpoint verification isn't absolute security.  For
example, it doesn't protect against endpoint compromises.  But that
doesn't make it endpoint verification useless.)

     -- Brett


From Valdis.Kletnieks at vt.edu  Tue Sep 13 10:03:15 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 13 Sep 2011 11:03:15 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: Your message of "Tue, 13 Sep 2011 16:29:30 +0200."
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
Message-ID: <99196.1315926195@turing-police.cc.vt.edu>

On Tue, 13 Sep 2011 16:29:30 +0200, Tei said:
> He, I just want to self-sign my CERT's and remove the ugly warning that
> browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I

The warning is there for a *reason* - namely that if you have a self-signed
cert, a first time visitor has *zero* way to verify it's *your* self-signed
cert and not some hijacker's self-signed cert.

> just don't want to use cleartext for internet data transfer.  HTTP is like
> telnet, and HTTPS is like ssh. But with ssh is just can connect, with
> browsers theres this ugly warning and "fuck you, self-signed certificate"
> from the browsers.  Please make the pain stop!.

If you use SSH to connect, and either ignore the "host key has changed" or
"authenticity can't be established, continue connecting?" messages, you get
what you deserve - those are the *exact* same issues that your browser warns
about self-signed certs.  And if you *don't* ignore them on SSH - why do you
want to ignore them on SSL?

Note that there's another big difference between SSH and SSL - the number of
people who are allowed to SSH to a given machine is (a) usually small and (b)
pre-identified up front.  So if Fred gets an "unknown host key" while SSH'ing
to the server you just set up, that's probably not a big issue because you
presumably know who Fred is and just created an account for him, so you can
supply him with the footprint of the SSH host key to double-verify.  That does
*not* scale to Internet-facing web services.

Of course, if you have a *private* *internal* webserver with limited users,
you're free to use a self-signed cert and use your browser's handy "Add
security exemption" dialog and check "Permanent".

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

From cmadams at hiwaay.net  Tue Sep 13 10:17:02 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 13 Sep 2011 10:17:02 -0500
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <20110913145855.GA23605@panix.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <20110913144538.GB19208@hiwaay.net> <20110913145855.GA23605@panix.com>
Message-ID: <20110913151702.GD19208@hiwaay.net>

Once upon a time, Brett Frankenberger <rbf+nanog at panix.com> said:
> On Tue, Sep 13, 2011 at 09:45:39AM -0500, Chris Adams wrote:
> > Once upon a time, Tei <oscar.vives at gmail.com> said:
> > > He, I just want to self-sign my CERT's and remove the ugly warning that
> > > browsers shows.
> > 
> > SSL without some verification of the far end is useless, as a
> > man-in-the-middle attack can create self-signed certs just as easily.
> 
> It protects against attacks where the attacker merely monitors the
> traffic between the two endpoints.

Someone who can monitor can most likely inject false traffic and thus
MITM.

In any case, a system that is supposed to provide end-to-end security
shouldn't be considered secure if it can be easily bypassed.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From michiel at klaver.it  Tue Sep 13 10:22:27 2011
From: michiel at klaver.it (Michiel Klaver)
Date: Tue, 13 Sep 2011 17:22:27 +0200
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
Message-ID: <4E6F7533.4020901@klaver.it>

At 22-07-28164 20:59, Tei wrote:
> *a random php programmer shows*
>
> He, I just want to self-sign my CERT's and remove the ugly warning that
> browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I
> just don't want to use cleartext for internet data transfer.  HTTP is like
> telnet, and HTTPS is like ssh. But with ssh is just can connect, with
> browsers theres this ugly warning and "fuck you, self-signed certificate"
> from the browsers.  Please make the pain stop!.
>
> --Tei
>

No need for (financial) pain, there are free of charge ssl certificates 
available, see for example:

http://www.startssl.com/?app=1
http://www.cacert.org/



From cmadams at hiwaay.net  Tue Sep 13 10:24:28 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 13 Sep 2011 10:24:28 -0500
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <99196.1315926195@turing-police.cc.vt.edu>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <99196.1315926195@turing-police.cc.vt.edu>
Message-ID: <20110913152427.GE19208@hiwaay.net>

Once upon a time, Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at vt.edu> said:
> If you use SSH to connect, and either ignore the "host key has changed" or
> "authenticity can't be established, continue connecting?" messages, you get
> what you deserve - those are the *exact* same issues that your browser warns
> about self-signed certs.  And if you *don't* ignore them on SSH - why do you
> want to ignore them on SSL?

A big difference between SSH keys and SSL certificates is that SSL certs
have a built-in expiration date (which is a good thing, as nothing is
secure forever).  When that expiration date rolls around, the admin may
create a new key/cert pair, rather than just renewing the previous cert,
which would cause all the visitors that accepted the previous cert to
get a new and nastier warning that the cert has changed.  How do the
visitors know the difference between this case and a hijack/MITM?

Certs are almost guaranteed to change over time as technology changes.
For example, it used to be common to have 512 bit certs with an MD5
signature hash.  Now 1024 bit and SHA1 are the norm, and many are moving
to 2048 bit (and some to stronger hashes).  Having people get used to
periodically accepting a changed cert defeats the purpose of signed
certs (and again, effectively breaks SSL).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From bicknell at ufp.org  Tue Sep 13 10:37:47 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 13 Sep 2011 08:37:47 -0700
Subject: vyatta for bgp
In-Reply-To: <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
Message-ID: <20110913153747.GA91938@ussenterprise.ufp.org>

In a message written on Mon, Sep 12, 2011 at 06:56:26PM +0000, Dobbins, Roland wrote:
> The days of public-facing software-based routers were over years ago - you need an ASIC-based edge router, else you'll end up getting zorched.

Some enterprises get MPLS L3 VPN service from their providers, and
need boxes that can route packets to it and speak BGP to inject
their routes.  They are not, per se, connected to the Internet, and
thus won't be "zorched", at least in the sense you are using it.

Also, many enterprises get DS-3, Cable Modem, or 100M Ethernet
handoffs, and won't ever get a faster "zorch" due to link speed.

-- 
       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/20110913/7f028418/attachment.bin>

From morgan.miskell at caro.net  Tue Sep 13 10:49:54 2011
From: morgan.miskell at caro.net (Morgan Miskell)
Date: Tue, 13 Sep 2011 11:49:54 -0400
Subject: Twitter
Message-ID: <1315928994.3128.14.camel@cromagnon>

Anyone from twitter on the list?  If so, can you drop me an email so
that I can get some assistance with a routing issue?
-- 
Morgan A. Miskell
CaroNet Data Centers
704-643-8330 x206
----------------------------------------------------------------------------
The information contained in this e-mail is confidential and is intended
only for the named recipient(s). If you are not the intended recipient
you must not copy, distribute, or take any action or reliance on it. If
you have received this e-mail in error, please notify the sender. Any
unauthorized disclosure of the information contained in this e-mail is
strictly prohibited.
----------------------------------------------------------------------------



From patrick at newnog.org  Mon Sep 12 22:40:39 2011
From: patrick at newnog.org (Patrick W. Gilmore)
Date: Mon, 12 Sep 2011 23:40:39 -0400
Subject: NANOG Nomination Dates
Message-ID: <5E5DEC08-7887-4025-BEA3-2DAA6D8D0BD0@newnog.org>

Everyone,

I would like to remind everyone about some important dates that are coming up:

	* September 12, 2011 begins the nomination process for Program Committee Candidates.
	* September 13, 2011 the nomination process for the Board closes.


As a reminder, the Program Committee is a group of sixteen individuals from the NANOG community who together are responsible for the solicitation and selection of material for NANOG meeting programs.

Per the NewNOG bylaws, eligible candidates each will serve a two-year term.  To be eligible to be appointed as a member of the Program Committee, an individual must have attended one NANOG conference within the prior calendar year (12 months) and be a member in good standing.  Broad technical knowledge of Internet operations and familiarity with NANOG meetings are useful attributes.  Having constructive opinions and ideas about how NANOG meetings might be improved is of high value.  A willingness to recruit presentations for each meeting is required.  

Please send nominations to nominations at nanog.org.  If you are nominating another person, please provide that person's name and email address.  If you are nominating yourself, please provide a Statement of Intent and a Biography, each with a suggested limit of 150 words.  For samples, please see the 2010 candidate lists, <http://www.nanog.org/governance/elections/2010elections/>.


As always, if you have a questions, please email nominations at nanog.org.

Thank you for your support, and your participation in the community.

-- 
TTFN,
patrick



From deepak at ai.net  Tue Sep 13 14:54:52 2011
From: deepak at ai.net (Deepak Jain)
Date: Tue, 13 Sep 2011 15:54:52 -0400
Subject: vyatta for bgp
In-Reply-To: <20110913153747.GA91938@ussenterprise.ufp.org>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
Message-ID: <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>

In a message written on Mon, Sep 12, 2011 at 06:56:26PM +0000, Dobbins, Roland wrote:
> The days of public-facing software-based routers were over years ago - you need an ASIC-based edge router, else you'll end up getting zorched.

Some enterprises get MPLS L3 VPN service from their providers, and need boxes that can route packets to it and speak BGP to inject their routes.  They are not, per se, connected to the Internet, and thus won't be "zorched", at least in the sense you are using it.

Also, many enterprises get DS-3, Cable Modem, or 100M Ethernet handoffs, and won't ever get a faster "zorch" due to link speed.

---

Picking up on what Leo wrote:

I think the OP stated he is using less than 10M (or a few T1s or something). The term Enterprise covers a lot of ground from SMEs to LBs. 

It's important to clarify that no router is perfect and all of them are sufficiently complex beasties to fully understand your problem/solution set. 

Software routers are simpler in that almost all of their complexities lie in their CPU/bus/interrupt limitations and provided you haven't hit those limits the software can do just about anything you ask of it. 

Hardware-assisted routers are promised to move lots and lots of pps and tolerate all kinds of bad behavior -- with all kinds of caveats, like control plane policing, understanding the minutiae of their ASIC design/layout and of course various oddities in their software configurations and releases (turn this on, but not with that, if you want this feature to work). 

Without rehashing 20+ years of collective knowledge & caveats on hardware-assisted routers, smaller guys who want to test their approach to purchasing need some kind of answer better than "it depends".

Even though "it depends"  (based on total uplink speeds), here are my suggestions:

<200 mb/s a circa 2010+ software router, even talking to the internet as a whole, is probably fine, even to run BGP. You may have some weird edge cases where you can be attacked, but your pipe will probably limit you. At this level, you can also lean on your ISP to help if you get into a jam.

200mb/s to 2Gb/s , your software router may keep up, and you need to start considering hardware assisted routing and a stiff breeze could make your router fall over. More time will be required to tune your software router that could be better spent elsewhere. At the higher end of this range, your ISP is less able to help you (filter good traffic from bad) and you need to be able to do some of this in your router. Pipe speed is less of an issue and you can have badly behaved traffic that "zorches" you at far less than link speed.

2Gb/s +, your software solution is a dead duck or an accident waiting to happen. You will be victim to oddities related to inconsistent performance, jitter, and of course malicious attacks. You probably want more advanced traffic and profiling features a hardware platform allows you (at wire speed) too.  Your ISP's hardware router will only do what you ask (nicely) for your ISP to do... and even that is limited. You are basically "big enough" to manage these connections on your own and should have equipment and staff available to do so.

I just took a stab at the ranges and the concepts, only limited to the OP's context and directed at "Enterprise" customers. ISP's probably can't use these limits for their own router solution/sizing -- and we all know that ISPs vary in quality, especially at 4am when you are being DOS'd....so ymmv.

HTH,

Deepak Jain
AiNET



From jra at baylink.com  Tue Sep 13 15:50:50 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 13 Sep 2011 16:50:50 -0400 (EDT)
Subject: Transit pricing?
Message-ID: <25474169.1637.1315947050292.JavaMail.root@benjamin.baylink.com>

Anyone mind telling me, off list and not for attribution, what they're
paying for straight or blended transit in a colo datacenter?  Trying to 
evaluate a quote.  /mbps, GigE fiber access.

Cheers,
-- jr 'Shhhh, James :-)' a
-- 
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      http://photo.imageinc.us             +1 727 647 1274


From rdobbins at arbor.net  Tue Sep 13 18:36:18 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 13 Sep 2011 23:36:18 +0000
Subject: vyatta for bgp
In-Reply-To: <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
Message-ID: <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>

On Sep 14, 2011, at 5:54 AM, Deepak Jain wrote:

> Some enterprises get MPLS L3 VPN service from their providers, and need boxes that can route packets to it and speak BGP to inject their routes.  They are not, per se, connected to the Internet, and thus won't be "zorched", at least in the sense you are using it.

Hence 'public-facing'.

;>

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From morrowc.lists at gmail.com  Tue Sep 13 21:26:37 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 13 Sep 2011 22:26:37 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <4E6F7533.4020901@klaver.it>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <4E6F7533.4020901@klaver.it>
Message-ID: <CAL9jLabBszvurr_VAUb3ryVYq+GkZNCAsm8FTDDs1m9hJGSv+w@mail.gmail.com>

On Tue, Sep 13, 2011 at 11:22 AM, Michiel Klaver <michiel at klaver.it> wrote:
> At 22-07-28164 20:59, Tei wrote:
>>
>> *a random php programmer shows*
>>
>> He, I just want to self-sign my CERT's and remove the ugly warning that
>> browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I
>> just don't want to use cleartext for internet data transfer. ?HTTP is like
>> telnet, and HTTPS is like ssh. But with ssh is just can connect, with
>> browsers theres this ugly warning and "fuck you, self-signed certificate"
>> from the browsers. ?Please make the pain stop!.
>>
>> --Tei
>>
>
> No need for (financial) pain, there are free of charge ssl certificates
> available, see for example:
>
> http://www.startssl.com/?app=1

eddy stopped issuing

> http://www.cacert.org/

these I hadn't seen... or I had and promptly forgotten about them
since they don't get included in any browser/app/OS :(

Affirmtrust is supposed to start issuing certs 'soon' though, free.

-chris


From nanog at jima.tk  Tue Sep 13 22:33:30 2011
From: nanog at jima.tk (Jima)
Date: Tue, 13 Sep 2011 21:33:30 -0600
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <CAL9jLabBszvurr_VAUb3ryVYq+GkZNCAsm8FTDDs1m9hJGSv+w@mail.gmail.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <4E6F7533.4020901@klaver.it>
 <CAL9jLabBszvurr_VAUb3ryVYq+GkZNCAsm8FTDDs1m9hJGSv+w@mail.gmail.com>
Message-ID: <4E70208A.3010103@jima.tk>

On 2011-09-13 20:26, Christopher Morrow wrote:
> On Tue, Sep 13, 2011 at 11:22 AM, Michiel Klaver<michiel at klaver.it>  wrote:
>> No need for (financial) pain, there are free of charge ssl certificates
>> available, see for example:
>>
>> http://www.startssl.com/?app=1
>
> eddy stopped issuing

  Huh?  I'm a bit lost here, since I had two StartSSL certs issued 
yesterday afternoon.

      Jima


From morrowc.lists at gmail.com  Tue Sep 13 22:44:11 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 13 Sep 2011 23:44:11 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <4E70208A.3010103@jima.tk>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <4E6F7533.4020901@klaver.it>
 <CAL9jLabBszvurr_VAUb3ryVYq+GkZNCAsm8FTDDs1m9hJGSv+w@mail.gmail.com>
 <4E70208A.3010103@jima.tk>
Message-ID: <CAL9jLabGYJbYYVT1o+fcLGqOaD3q_i3hQDPqg0jNx7HeAHZupA@mail.gmail.com>

On Tue, Sep 13, 2011 at 11:33 PM, Jima <nanog at jima.tk> wrote:
> On 2011-09-13 20:26, Christopher Morrow wrote:
>>
>> On Tue, Sep 13, 2011 at 11:22 AM, Michiel Klaver<michiel at klaver.it>
>> ?wrote:
>>>
>>> No need for (financial) pain, there are free of charge ssl certificates
>>> available, see for example:
>>>
>>> http://www.startssl.com/?app=1
>>
>> eddy stopped issuing
>
> ?Huh? ?I'm a bit lost here, since I had two StartSSL certs issued yesterday
> afternoon.

orly? wierd, they made a press release ~last-june (I think?) stating
they were stopping issuance indefinitely. I do hope they are actually
issuing again :)

I like my random numbers to be free.

-chris


From morrowc.lists at gmail.com  Tue Sep 13 22:51:42 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 13 Sep 2011 23:51:42 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <CAL9jLabGYJbYYVT1o+fcLGqOaD3q_i3hQDPqg0jNx7HeAHZupA@mail.gmail.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <4E6F7533.4020901@klaver.it>
 <CAL9jLabBszvurr_VAUb3ryVYq+GkZNCAsm8FTDDs1m9hJGSv+w@mail.gmail.com>
 <4E70208A.3010103@jima.tk>
 <CAL9jLabGYJbYYVT1o+fcLGqOaD3q_i3hQDPqg0jNx7HeAHZupA@mail.gmail.com>
Message-ID: <CAL9jLaZBhXBSgUqB_E_9dCEiY=v7WBr_WG8vdVCKvRKnhJDyiQ@mail.gmail.com>

On Tue, Sep 13, 2011 at 11:44 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Tue, Sep 13, 2011 at 11:33 PM, Jima <nanog at jima.tk> wrote:
>> On 2011-09-13 20:26, Christopher Morrow wrote:
>>>
>>> On Tue, Sep 13, 2011 at 11:22 AM, Michiel Klaver<michiel at klaver.it>
>>> ?wrote:
>>>>
>>>> No need for (financial) pain, there are free of charge ssl certificates
>>>> available, see for example:
>>>>
>>>> http://www.startssl.com/?app=1
>>>
>>> eddy stopped issuing
>>
>> ?Huh? ?I'm a bit lost here, since I had two StartSSL certs issued yesterday
>> afternoon.
>
> orly? wierd, they made a press release ~last-june (I think?) stating
> they were stopping issuance indefinitely. I do hope they are actually
> issuing again :)

<http://threatpost.com/en_us/blogs/ca-startssl-compromised-says-certificates-not-affected-062111>

has a link to the startssl page about this, which doesn't appear to
load for me (now)... maybe they are back in business!

>
> I like my random numbers to be free.
>
> -chris
>


From ml-nanog090304q at elcsplace.com  Tue Sep 13 22:55:05 2011
From: ml-nanog090304q at elcsplace.com (Ted Cooper)
Date: Wed, 14 Sep 2011 13:55:05 +1000
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <CAL9jLabGYJbYYVT1o+fcLGqOaD3q_i3hQDPqg0jNx7HeAHZupA@mail.gmail.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <4E6F7533.4020901@klaver.it>
 <CAL9jLabBszvurr_VAUb3ryVYq+GkZNCAsm8FTDDs1m9hJGSv+w@mail.gmail.com>
 <4E70208A.3010103@jima.tk>
 <CAL9jLabGYJbYYVT1o+fcLGqOaD3q_i3hQDPqg0jNx7HeAHZupA@mail.gmail.com>
Message-ID: <4E702599.6020509@elcsplace.com>

On 14/09/11 13:44, Christopher Morrow wrote:
> On Tue, Sep 13, 2011 at 11:33 PM, Jima <nanog at jima.tk> wrote:
>>  Huh?  I'm a bit lost here, since I had two StartSSL certs issued yesterday
>> afternoon.
> 
> orly? wierd, they made a press release ~last-june (I think?) stating
> they were stopping issuance indefinitely. I do hope they are actually
> issuing again :)
> 
> I like my random numbers to be free.

As claimed by the DigiNotar hacker - He compromised their servers but
Eddy was manually approving certs at the time and so no certs were signed.

There was information about it on the site, but it seems to be gone now.
Articles still show a screenshot of the message you're talking about [1]
, but the site was back alive in July when I needed a certificate.

"A separate notice on another part of the company's site says that its
services would be unavailable until June 20, " [2]

I've certainly been able to issue certificates for myself since then.

[1]
http://news.netcraft.com/archives/2011/06/22/startssl-suspends-services-after-security-breach.html

[2]
http://threatpost.com/en_us/blogs/ca-startssl-compromised-says-certificates-not-affected-062111






From owen at delong.com  Tue Sep 13 23:37:42 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 13 Sep 2011 21:37:42 -0700
Subject: what about the users re: NAT444 or ?
In-Reply-To: <028401cc6e47$a3faae70$ebf00b50$@com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
 <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
 <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
 <028401cc6e47$a3faae70$ebf00b50$@com>
Message-ID: <23CAA459-B646-46C6-9EFC-D249678436E3@delong.com>


On Sep 8, 2011, at 9:52 AM, Dan Wing wrote:

>> -----Original Message-----
>> From: Christian de Larrinaga [mailto:cdel at firsthand.net]
>> Sent: Thursday, September 08, 2011 8:05 AM
>> To: Cameron Byrne
>> Cc: NANOG
>> Subject: what about the users re: NAT444 or ?
>> 
>> I wonder if the discussion as useful as it is isn't forgetting that the
>> edge of Internet has a stake in getting this right too! This is not
>> just an ISP problem but one where content providers and services that
>> is the users need to get from here to there in good order.
>> 
>> So
>> 
>> What can users do to encourage ISPs to deploy v6 to them?

Call up and ask for it? Vote with their $$ and their feet?

>> What can users do to ease the pain in reaching IPv4 only sites once
>> they are on IPv6 tails?

1. Encourage the sites they care about to implement IPv6.
2. Why is being on an IPv6 tail exclusive of being on an IPv4 tail. I would want
	to be on a dual-stack tail (which is what I currently have).

>> 
>> Is there not a bit of CPE needed here? What should the CPE do? and not
>> do? should it deprecate NAT/PAT when it receives 1918 allocation from a
>> CGN?
> 
> Careful with that idea -- people like their in-home network to continue
> functioning even when their ISP is down or having an outage.  Consider
> a home NAS holding delivering content to the stereo or the television.
> It is possible to eliminate reliance on the ISP's network and still
> have the in-home network function, but it's more difficult than just
> continuing to run NAT44 in the home like today.  (Dual Stack-Lite

One can do that with or without NAT. This claim that one cannot
keep a network running without a service provider connected if you
don't run NAT is a myth of dubious origin.

> can accomplish this pretty easily, because the IPv4 addresses in
> the home can be any IPv4 address whatsoever -- which allows the
> in-home CPE ("B4", in Dual Stack-Lite parlance) to assign any address
> it wants with its built-in DHCP server.)
> 

There are other ways to accomplish this as well.

> -d
> 
>> and less technically but relevant I think is to ask about cost? who
>> pays?

In some cases, ISPs will provide new CPE to their end users. In other cases,
end-users will be expected to pay to upgrade their own.

Owen

>> 
>> 
>> Christian
>> 
>> On 8 Sep 2011, at 15:02, Cameron Byrne wrote:
>> 
>>> On Sep 8, 2011 1:47 AM, "Leigh Porter" <leigh.porter at ukbroadband.com>
>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Owen DeLong [mailto:owen at delong.com]
>>>>> Sent: 08 September 2011 01:22
>>>>> To: Leigh Porter
>>>>> Cc: Seth Mos; NANOG
>>>>> Subject: Re: NAT444 or ?
>>>>> 
>>>>>> Considering that offices, schools etc regularly have far more than
>> 10
>>>>> users per IP, I think this limit is a little low. I've happily had
>>>>> around 300 per public IP address on a large WiFi network, granted
>> these
>>>>> are all different kinds of users, it is just something that
>> operational
>>>>> experience will have to demonstrate.
>>>>>> 
>>>>> Yes, but, you are counting individual users whereas at the NAT444
>>>>> level, what's really being counted is end-customer sites not
>> individual
>>>>> users, so the term
>>>>> "users" is a bit misleading in the context. A given end-customer
>> site
>>>>> may be from 1 to 50 or more individual users.
>>>> 
>>>> Indeed, my users are using LTE dongles mostly so I expect they will
>> be
>>> single users. At the moment on the WiMAX network I see around 35
>> sessions
>>> from a WiMAX modem on average rising to about 50 at peak times. These
>> are a
>>> combination of individual users and "home modems".
>>>> 
>>>> We had some older modems that had integrated NAT that was broken and
>>> locked up the modem at 200 sessions. Then some old base station
>> software
>>> died at about 10K sessions. So we monitor these things now..
>>>> 
>>>> 
>>>>> 
>>>>>> I would love to avoid NAT444, I do not see a viable way around it
>> at
>>>>> the moment. Unless the Department of Work and Pensions release
>> their /8
>>>>> that is ;-)
>>>>>> 
>>>>> 
>>>>> The best mitigation really is to get IPv6 deployed as rapidly and
>>>>> widely as possible. The more stuff can go native IPv6, the less
>> depends
>>>>> on fragile NAT444.
>>>> 
>>>> Absolutely. Even things like google maps, if that can be dumped on
>> v6,
>>> it'll save a load of sessions from people. The sooner services such
>> as
>>> Microsoft Update turn on v6 the better as well. I would also like the
>> CDNs
>>> to be able to deliver content in v6 (even if the main page is v4)
>> which
>>> again will reduce the traffic that has to traverse any NAT.
>>>> 
>>>> Soon, I think content providers (and providers of other services on
>> the
>>> 'net) will roll v6 because of the performance increase as v6 will not
>> have
>>> to traverse all this NAT and be subject to session limits, timeouts
>> and
>>> such.
>>>> 
>>> 
>>> What do you mean by performance increase? If performance equals
>> latency, v4
>>> will win for a long while still. Cgn does not add measurable latency.
>>> 
>>> Cb
>>>> --
>>>> Leigh
>>>> 
>>>> 
>>>> 
>> ______________________________________________________________________
>>>> This email has been scanned by the MessageLabs Email Security
>> System.
>>>> For more information please visit http://www.messagelabs.com/email
>>>> 
>> ______________________________________________________________________
>>>> 
> 
> 



From owen at delong.com  Tue Sep 13 23:42:41 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 13 Sep 2011 21:42:41 -0700
Subject: NAT444 or ?
In-Reply-To: <02c401cc6e49$5f13c1a0$1d3b44e0$@com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl> <4E67D24F.10706@otd.com>
 <D181DDABABE57E4DB72FEE00331478643BADD2@EALPO1.ukbroadband.com>
 <02c401cc6e49$5f13c1a0$1d3b44e0$@com>
Message-ID: <AE9B65E4-0FFF-484D-9231-CBA5EB8D2930@delong.com>

>> 
>> Good point, but aside from these scaling issues which I expect can be
>> resolved to a point, the more serious issue, I think, is applications
>> that just do not work with double NAT. Now, I have not conducted any
>> serious research into this, but it seems that draft-donley-nat444-
>> impacts does appear to have highlight issues that may have been down to
>> implementation.
> 
> Draft-donley-nat444-impacts conflates bandwidth constraints with CGN
> with in-home NAT.  Until those are separated and then analyzed carefully,
> it is harmful to draw conclusions such as "NAT444 bad; NAT44 good".
> 

Continuing to make this claim does not make it any more true.

Draft-donley took networks and measured their real-world functionality
without NAT444, then, added NAT444 and repeated the same tests.
Regardless of the underlying issue(s), the addition of NAT444 to the
mix resulted in the forms of service degradation enumerated in the draft.

Further, I would not ever say "NAT444 bad; NAT44 good". I would say,
rather, "NAT44 bad, NAT444 worse". I think that's a pretty safe and non-
harmful thing to say.

>> Other simple tricks such as ensuring that your own internal services
>> such as DNS are available without traversing NAT also help.
> 
> Yep.  But some users want to use other DNS servers for performance
> (e.g., Google's or OpenDNS servers, especially considering they
> could point the user at a 'better' (closer) CDN based on Client
> IP), to avoid ISP DNS hijacking, or for content control (e.g.,
> "parental control" of DNS hostnames).  That traffic will, necessarily,
> traverse the CGN.  To avoid users burning through their UDP port 
> allocation for those DNS queries it is useful for the CGN to 
> have short timeouts for port 53.
> 
If the user chooses to use a DNS server on the other side of a NAT, then,
they are choosing to inflict whatever damage upon themselves. I'm not
saying that short UDP/53 timeouts are a bad idea, but, I am saying that
the more stuff you funnel through an LSN at the carrier, the more stuff
you will see break. This would lead me to want to avoid funneling anything
through said NAT which I could avoid. Then again, I run my own
authoritative and recursive nameservers in my home and don't use
any NAT at all, so, perhaps my perspective is different from others.

>> Certainly some more work can be done in this area, but I fear that the
>> only way a real idea as to how much NAT444 really doe break things will
>> be operational experience.
> 
> Yep.  (Same as everything else.)
> 

I'm sure that will happen soon enough. I, for one, am not looking forward
to the experience.

Owen



From dwing at cisco.com  Wed Sep 14 00:18:53 2011
From: dwing at cisco.com (Dan Wing)
Date: Tue, 13 Sep 2011 22:18:53 -0700
Subject: what about the users re: NAT444 or ?
In-Reply-To: <23CAA459-B646-46C6-9EFC-D249678436E3@delong.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
 <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
 <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
 <028401cc6e47$a3faae70$ebf00b50$@com>
 <23CAA459-B646-46C6-9EFC-D249678436E3@delong.com>
Message-ID: <0a4801cc729d$cbe69520$63b3bf60$@com>

> One can do that with or without NAT. This claim that one cannot
> keep a network running without a service provider connected if you
> don't run NAT is a myth of dubious origin.

If the hosts are running DHCP, and the ISP is running the DHCP
server?  I guess they will fall back (after a while) to link-local
and continue on their merry way.

> > can accomplish this pretty easily, because the IPv4 addresses in
> > the home can be any IPv4 address whatsoever -- which allows the
> > in-home CPE ("B4", in Dual Stack-Lite parlance) to assign any address
> > it wants with its built-in DHCP server.)
> >
> 
> There are other ways to accomplish this as well.

-d

> > -d
> >
> >> and less technically but relevant I think is to ask about cost? who
> >> pays?
> 
> In some cases, ISPs will provide new CPE to their end users. In other
> cases,
> end-users will be expected to pay to upgrade their own.
> 
> Owen
> 
> >>
> >>
> >> Christian
> >>
> >> On 8 Sep 2011, at 15:02, Cameron Byrne wrote:
> >>
> >>> On Sep 8, 2011 1:47 AM, "Leigh Porter"
> <leigh.porter at ukbroadband.com>
> >> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Owen DeLong [mailto:owen at delong.com]
> >>>>> Sent: 08 September 2011 01:22
> >>>>> To: Leigh Porter
> >>>>> Cc: Seth Mos; NANOG
> >>>>> Subject: Re: NAT444 or ?
> >>>>>
> >>>>>> Considering that offices, schools etc regularly have far more
> than
> >> 10
> >>>>> users per IP, I think this limit is a little low. I've happily
> had
> >>>>> around 300 per public IP address on a large WiFi network, granted
> >> these
> >>>>> are all different kinds of users, it is just something that
> >> operational
> >>>>> experience will have to demonstrate.
> >>>>>>
> >>>>> Yes, but, you are counting individual users whereas at the NAT444
> >>>>> level, what's really being counted is end-customer sites not
> >> individual
> >>>>> users, so the term
> >>>>> "users" is a bit misleading in the context. A given end-customer
> >> site
> >>>>> may be from 1 to 50 or more individual users.
> >>>>
> >>>> Indeed, my users are using LTE dongles mostly so I expect they
> will
> >> be
> >>> single users. At the moment on the WiMAX network I see around 35
> >> sessions
> >>> from a WiMAX modem on average rising to about 50 at peak times.
> These
> >> are a
> >>> combination of individual users and "home modems".
> >>>>
> >>>> We had some older modems that had integrated NAT that was broken
> and
> >>> locked up the modem at 200 sessions. Then some old base station
> >> software
> >>> died at about 10K sessions. So we monitor these things now..
> >>>>
> >>>>
> >>>>>
> >>>>>> I would love to avoid NAT444, I do not see a viable way around
> it
> >> at
> >>>>> the moment. Unless the Department of Work and Pensions release
> >> their /8
> >>>>> that is ;-)
> >>>>>>
> >>>>>
> >>>>> The best mitigation really is to get IPv6 deployed as rapidly and
> >>>>> widely as possible. The more stuff can go native IPv6, the less
> >> depends
> >>>>> on fragile NAT444.
> >>>>
> >>>> Absolutely. Even things like google maps, if that can be dumped on
> >> v6,
> >>> it'll save a load of sessions from people. The sooner services such
> >> as
> >>> Microsoft Update turn on v6 the better as well. I would also like
> the
> >> CDNs
> >>> to be able to deliver content in v6 (even if the main page is v4)
> >> which
> >>> again will reduce the traffic that has to traverse any NAT.
> >>>>
> >>>> Soon, I think content providers (and providers of other services
> on
> >> the
> >>> 'net) will roll v6 because of the performance increase as v6 will
> not
> >> have
> >>> to traverse all this NAT and be subject to session limits, timeouts
> >> and
> >>> such.
> >>>>
> >>>
> >>> What do you mean by performance increase? If performance equals
> >> latency, v4
> >>> will win for a long while still. Cgn does not add measurable
> latency.
> >>>
> >>> Cb
> >>>> --
> >>>> Leigh
> >>>>
> >>>>
> >>>>
> >>
> ______________________________________________________________________
> >>>> This email has been scanned by the MessageLabs Email Security
> >> System.
> >>>> For more information please visit http://www.messagelabs.com/email
> >>>>
> >>
> ______________________________________________________________________
> >>>>
> >
> >



From dwing at cisco.com  Wed Sep 14 00:28:17 2011
From: dwing at cisco.com (Dan Wing)
Date: Tue, 13 Sep 2011 22:28:17 -0700
Subject: NAT444 or ?
In-Reply-To: <AE9B65E4-0FFF-484D-9231-CBA5EB8D2930@delong.com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl> <4E67D24F.10706@otd.com>
 <D181DDABABE57E4DB72FEE00331478643BADD2@EALPO1.ukbroadband.com>
 <02c401cc6e49$5f13c1a0$1d3b44e0$@com>
 <AE9B65E4-0FFF-484D-9231-CBA5EB8D2930@delong.com>
Message-ID: <0a4d01cc729f$1bc0abc0$53420340$@com>

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Tuesday, September 13, 2011 9:43 PM
> To: Dan Wing
> Cc: 'Leigh Porter'; 'David Israel'; nanog at nanog.org
> Subject: Re: NAT444 or ?
> 
> >>
> >> Good point, but aside from these scaling issues which I expect can
> be
> >> resolved to a point, the more serious issue, I think, is
> applications
> >> that just do not work with double NAT. Now, I have not conducted any
> >> serious research into this, but it seems that draft-donley-nat444-
> >> impacts does appear to have highlight issues that may have been down
> to
> >> implementation.
> >
> > Draft-donley-nat444-impacts conflates bandwidth constraints with CGN
> > with in-home NAT.  Until those are separated and then analyzed
> carefully,
> > it is harmful to draw conclusions such as "NAT444 bad; NAT44 good".
> >
> 
> Continuing to make this claim does not make it any more true.
> 
> Draft-donley took networks and measured their real-world functionality
> without NAT444, then, added NAT444 and repeated the same tests.
> Regardless of the underlying issue(s), the addition of NAT444 to the
> mix resulted in the forms of service degradation enumerated in the
> draft.

I disagree it reached that conclusion.  That may have been its
intent.

> Further, I would not ever say "NAT444 bad; NAT44 good". I would say,
> rather, "NAT44 bad, NAT444 worse". I think that's a pretty safe and
> non-harmful thing to say.

Yes, your statement is completely accurate.  I agree that IPv4 address 
sharing causes additional problems (which encompasses all forms of 
IPv4 address sharing), and CGN causes additional problems.

> >> Other simple tricks such as ensuring that your own internal services
> >> such as DNS are available without traversing NAT also help.
> >
> > Yep.  But some users want to use other DNS servers for performance
> > (e.g., Google's or OpenDNS servers, especially considering they
> > could point the user at a 'better' (closer) CDN based on Client
> > IP), to avoid ISP DNS hijacking, or for content control (e.g.,
> > "parental control" of DNS hostnames).  That traffic will,
> necessarily,
> > traverse the CGN.  To avoid users burning through their UDP port
> > allocation for those DNS queries it is useful for the CGN to
> > have short timeouts for port 53.
> >
> If the user chooses to use a DNS server on the other side of a NAT,
> then,
> they are choosing to inflict whatever damage upon themselves. I'm not
> saying that short UDP/53 timeouts are a bad idea, but, I am saying that
> the more stuff you funnel through an LSN at the carrier, the more stuff
> you will see break. This would lead me to want to avoid funneling
> anything
> through said NAT which I could avoid. Then again, I run my own
> authoritative and recursive nameservers in my home and don't use
> any NAT at all, so, perhaps my perspective is different from others.

Yeah, you are probably of about 1000 or maybe 3000 people in the 
world that do that.  Seems to be a minority.

> >> Certainly some more work can be done in this area, but I fear that
> the
> >> only way a real idea as to how much NAT444 really doe break things
> will
> >> be operational experience.
> >
> > Yep.  (Same as everything else.)
> >
> 
> I'm sure that will happen soon enough. I, for one, am not looking
> forward to the experience.

Neither am I.

But if major content providers cannot provide AAAA on their
properties, and if ISPs and CPE vendors do not make IPv6
available and working, and if web browsers don't adopt faster
fallback to IPv4 when IPv6 is borked ....  We will all be 
behind NATs.

-d




From maxsec at gmail.com  Wed Sep 14 05:42:35 2011
From: maxsec at gmail.com (Martin Hepworth)
Date: Wed, 14 Sep 2011 11:42:35 +0100
Subject: ouch..
Message-ID: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>

http://www.overpromisesunderdelivers.net/


-- 
Martin Hepworth
Oxford, UK

From galu at packetdam.com  Wed Sep 14 05:51:00 2011
From: galu at packetdam.com (Vlad Galu)
Date: Wed, 14 Sep 2011 12:51:00 +0200
Subject: ouch..
In-Reply-To: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
Message-ID: <E963444C-A6C5-4399-AB1D-806F59C63389@packetdam.com>

On Sep 14, 2011, at 12:42 PM, Martin Hepworth wrote:
> http://www.overpromisesunderdelivers.net/


Saying the other brand sucks doesn't make yours any better. Besides, there are other big players on the market. Terribly lame of Cisco...
 
Vlad Galu
galu at packetdam.com






From nick at foobar.org  Wed Sep 14 05:54:59 2011
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 14 Sep 2011 11:54:59 +0100
Subject: ouch..
In-Reply-To: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
Message-ID: <4E708803.5040506@foobar.org>

On 14/09/2011 11:42, Martin Hepworth wrote:
> http://www.overpromisesunderdelivers.net/

Wow, classy.

Nick


From nanog at rhemasound.org  Wed Sep 14 06:15:08 2011
From: nanog at rhemasound.org (Brian Raaen)
Date: Wed, 14 Sep 2011 07:15:08 -0400
Subject: ouch..
In-Reply-To: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
Message-ID: <20110914111508.GA6498@brian>

Looks like some random person registered this one.  The domain and ip do not look related to cisco even though someone has falsely pasted their logo all over the site.



whois overpromisesunderdelivers.net

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.

   Domain Name: OVERPROMISESUNDERDELIVERS.NET
   Registrar: GODADDY.COM, INC.
   Whois Server: whois.godaddy.com
   Referral URL: http://registrar.godaddy.com
   Name Server: NS35.DOMAINCONTROL.COM
   Name Server: NS36.DOMAINCONTROL.COM
   Status: clientDeleteProhibited
   Status: clientRenewProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Updated Date: 05-sep-2011
   Creation Date: 05-sep-2011
   Expiration Date: 05-sep-2012

Registrant:
   Domains by Proxy, Inc.
   DomainsByProxy.com
   15111 N. Hayden Rd., Ste 160, PMB 353
   Scottsdale, Arizona 85260
   United States

   Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
   Domain Name: OVERPROMISESUNDERDELIVERS.NET
      Created on: 05-Sep-11
      Expires on: 05-Sep-12
      Last Updated on: 05-Sep-11

   Administrative Contact:
      Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
      Domains by Proxy, Inc.
      DomainsByProxy.com
      15111 N. Hayden Rd., Ste 160, PMB 353
      Scottsdale, Arizona 85260
      United States
      (480) 624-2599      Fax -- (480) 624-2598

   Technical Contact:
      Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
      Domains by Proxy, Inc.
      DomainsByProxy.com
      15111 N. Hayden Rd., Ste 160, PMB 353
      Scottsdale, Arizona 85260
      United States
      (480) 624-2599      Fax -- (480) 624-2598

   Domain servers in listed order:
      NS35.DOMAINCONTROL.COM
      NS36.DOMAINCONTROL.COM



braaen at brian:~$ dig OVERPROMISESUNDERDELIVERS.NET

; <<>> DiG 9.7.3 <<>> OVERPROMISESUNDERDELIVERS.NET
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40339
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;OVERPROMISESUNDERDELIVERS.NET. IN      A

;; ANSWER SECTION:
OVERPROMISESUNDERDELIVERS.NET. 3364 IN  A       98.129.229.190

;; AUTHORITY SECTION:
OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns36.domaincontrol.com.
OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns35.domaincontrol.com.

;; ADDITIONAL SECTION:
ns35.domaincontrol.com. 3046    IN      A       216.69.185.18
ns36.domaincontrol.com. 3046    IN      A       208.109.255.18


braaen at brian:~$ dig -x 98.129.229.190

; <<>> DiG 9.7.3 <<>> -x 98.129.229.190
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26507
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;190.229.129.98.in-addr.arpa.   IN      PTR

;; AUTHORITY SECTION:
229.129.98.in-addr.arpa. 300    IN      SOA     ns.rackspace.com. hostmaster.rackspace.com. 1314291452 3600 300 1814400 300



---
Brian Raaen
Network Architect
Zcorum
On Wed, Sep 14, 2011 at 11:42:35AM +0100, Martin Hepworth wrote:
> http://www.overpromisesunderdelivers.net/
> 
> 
> -- 
> Martin Hepworth
> Oxford, UK


From nanog at u61.u22.net  Wed Sep 14 06:20:15 2011
From: nanog at u61.u22.net (Always Learning)
Date: Wed, 14 Sep 2011 12:20:15 +0100
Subject: ouch..
In-Reply-To: <20110914111508.GA6498@brian>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian>
Message-ID: <1315999215.15630.3.camel@m6.u226.com>


On Wed, 2011-09-14 at 07:15 -0400, Brian Raaen wrote:

> Looks like some random person registered this one.  The domain and ip
> do not look related to cisco even though someone has falsely pasted
> their logo all over the site.

(1) If Cisco were responsible, would they want to advertise the fact ?

(2) If Cisco feel their intellectual and copyright property is being
abused, Cisco lawyers would have the Cisco name and branding removed in
seconds !


Paul,
England,
EU.




From geier at geier.ne.tz  Wed Sep 14 06:20:56 2011
From: geier at geier.ne.tz (Frank Habicht)
Date: Wed, 14 Sep 2011 14:20:56 +0300
Subject: ouch..
In-Reply-To: <20110914111508.GA6498@brian>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian>
Message-ID: <4E708E18.3070006@geier.ne.tz>

Main cisco page has a link to it...

Frank

On 9/14/2011 2:15 PM, Brian Raaen wrote:
> Looks like some random person registered this one.  The domain and ip do not look related to cisco even though someone has falsely pasted their logo all over the site.
> 
> 
> 
> whois overpromisesunderdelivers.net
> 
> 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.
> 
>    Domain Name: OVERPROMISESUNDERDELIVERS.NET
>    Registrar: GODADDY.COM, INC.
>    Whois Server: whois.godaddy.com
>    Referral URL: http://registrar.godaddy.com
>    Name Server: NS35.DOMAINCONTROL.COM
>    Name Server: NS36.DOMAINCONTROL.COM
>    Status: clientDeleteProhibited
>    Status: clientRenewProhibited
>    Status: clientTransferProhibited
>    Status: clientUpdateProhibited
>    Updated Date: 05-sep-2011
>    Creation Date: 05-sep-2011
>    Expiration Date: 05-sep-2012
> 
> Registrant:
>    Domains by Proxy, Inc.
>    DomainsByProxy.com
>    15111 N. Hayden Rd., Ste 160, PMB 353
>    Scottsdale, Arizona 85260
>    United States
> 
>    Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
>    Domain Name: OVERPROMISESUNDERDELIVERS.NET
>       Created on: 05-Sep-11
>       Expires on: 05-Sep-12
>       Last Updated on: 05-Sep-11
> 
>    Administrative Contact:
>       Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
>       Domains by Proxy, Inc.
>       DomainsByProxy.com
>       15111 N. Hayden Rd., Ste 160, PMB 353
>       Scottsdale, Arizona 85260
>       United States
>       (480) 624-2599      Fax -- (480) 624-2598
> 
>    Technical Contact:
>       Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
>       Domains by Proxy, Inc.
>       DomainsByProxy.com
>       15111 N. Hayden Rd., Ste 160, PMB 353
>       Scottsdale, Arizona 85260
>       United States
>       (480) 624-2599      Fax -- (480) 624-2598
> 
>    Domain servers in listed order:
>       NS35.DOMAINCONTROL.COM
>       NS36.DOMAINCONTROL.COM
> 
> 
> 
> braaen at brian:~$ dig OVERPROMISESUNDERDELIVERS.NET
> 
> ; <<>> DiG 9.7.3 <<>> OVERPROMISESUNDERDELIVERS.NET
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40339
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> 
> ;; QUESTION SECTION:
> ;OVERPROMISESUNDERDELIVERS.NET. IN      A
> 
> ;; ANSWER SECTION:
> OVERPROMISESUNDERDELIVERS.NET. 3364 IN  A       98.129.229.190
> 
> ;; AUTHORITY SECTION:
> OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns36.domaincontrol.com.
> OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns35.domaincontrol.com.
> 
> ;; ADDITIONAL SECTION:
> ns35.domaincontrol.com. 3046    IN      A       216.69.185.18
> ns36.domaincontrol.com. 3046    IN      A       208.109.255.18
> 
> 
> braaen at brian:~$ dig -x 98.129.229.190
> 
> ; <<>> DiG 9.7.3 <<>> -x 98.129.229.190
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26507
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;190.229.129.98.in-addr.arpa.   IN      PTR
> 
> ;; AUTHORITY SECTION:
> 229.129.98.in-addr.arpa. 300    IN      SOA     ns.rackspace.com. hostmaster.rackspace.com. 1314291452 3600 300 1814400 300
> 
> 
> 
> ---
> Brian Raaen
> Network Architect
> Zcorum
> On Wed, Sep 14, 2011 at 11:42:35AM +0100, Martin Hepworth wrote:
>> http://www.overpromisesunderdelivers.net/
>>
>>
>> -- 
>> Martin Hepworth
>> Oxford, UK
> 



From markrefresh12 at gmail.com  Wed Sep 14 06:27:20 2011
From: markrefresh12 at gmail.com (Mark Smith)
Date: Wed, 14 Sep 2011 14:27:20 +0300
Subject: HP A-series, H3C, Huawei and their capabilities in real-life
Message-ID: <CAE79DorP-waM_EdHQJvQMw+mftM+BAv35tGhTz7TeYJTy-ON1Q@mail.gmail.com>

Hi list

Does anyone have (or know somebody who has) real-life experience of HP
A-series (former Huawei and H3C) high-end routers in service provider
environment? From the specs they look very good (both features and
performance) but the specs don't tell everything and nothing can
replace real-life experience.

The features I'm interested in include (not in any specific order)
- v4 and v6 routing
- BGP (full feed)
- OSPF and IS-IS
- MPLS(-TE) P/PE functionality (RSVP, L3VPN, VPLS)

For example this box
http://h17007.www1.hp.com/us/en/products/routers/HP_A8800_Router_Series/index.aspx

Any info or pointers greatly appreciated.

Rgds,
Mark


From ebais at a2b-internet.com  Wed Sep 14 06:55:47 2011
From: ebais at a2b-internet.com (Erik Bais)
Date: Wed, 14 Sep 2011 13:55:47 +0200
Subject: ouch..
In-Reply-To: <4E708E18.3070006@geier.ne.tz>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
Message-ID: <00a601cc72d5$3dc653b0$b952fb10$@com>

Hi Frank,

http://blogs.cisco.com/tag/overpromise/  

Quote from the blog: "Some vendors have repeatedly over-promised and under
delivered, and still somehow receive credit for their vision! (You can read
more about one vendor's repeated broken promises here.)" 

http://www.overpromisesunderdelivers.net/  

https://twitter.com/#!/CiscoSystems/status/113226120601677825  

https://twitter.com/#!/CiscoNL/statuses/113577908525744129 

Personally I think this is a pathetic action from Cisco, however I'm not
surprised by them doing it ... 

Regards,
Erik Bais

> -----Original Message-----
> From: Frank Habicht [mailto:geier at geier.ne.tz]
> Sent: Wednesday, September 14, 2011 1:21 PM
> To: nanog at nanog.org
> Subject: Re: ouch..
> 
> Main cisco page has a link to it...
> 
> Frank
> 
> On 9/14/2011 2:15 PM, Brian Raaen wrote:
> > Looks like some random person registered this one.  The domain and ip
> do not look related to cisco even though someone has falsely pasted
> their logo all over the site.
> >
> >
> >
> > whois overpromisesunderdelivers.net
> >
> > 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.
> >
> >    Domain Name: OVERPROMISESUNDERDELIVERS.NET
> >    Registrar: GODADDY.COM, INC.
> >    Whois Server: whois.godaddy.com
> >    Referral URL: http://registrar.godaddy.com
> >    Name Server: NS35.DOMAINCONTROL.COM
> >    Name Server: NS36.DOMAINCONTROL.COM
> >    Status: clientDeleteProhibited
> >    Status: clientRenewProhibited
> >    Status: clientTransferProhibited
> >    Status: clientUpdateProhibited
> >    Updated Date: 05-sep-2011
> >    Creation Date: 05-sep-2011
> >    Expiration Date: 05-sep-2012
> >
> > Registrant:
> >    Domains by Proxy, Inc.
> >    DomainsByProxy.com
> >    15111 N. Hayden Rd., Ste 160, PMB 353
> >    Scottsdale, Arizona 85260
> >    United States
> >
> >    Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
> >    Domain Name: OVERPROMISESUNDERDELIVERS.NET
> >       Created on: 05-Sep-11
> >       Expires on: 05-Sep-12
> >       Last Updated on: 05-Sep-11
> >
> >    Administrative Contact:
> >       Private, Registration
> OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
> >       Domains by Proxy, Inc.
> >       DomainsByProxy.com
> >       15111 N. Hayden Rd., Ste 160, PMB 353
> >       Scottsdale, Arizona 85260
> >       United States
> >       (480) 624-2599      Fax -- (480) 624-2598
> >
> >    Technical Contact:
> >       Private, Registration
> OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
> >       Domains by Proxy, Inc.
> >       DomainsByProxy.com
> >       15111 N. Hayden Rd., Ste 160, PMB 353
> >       Scottsdale, Arizona 85260
> >       United States
> >       (480) 624-2599      Fax -- (480) 624-2598
> >
> >    Domain servers in listed order:
> >       NS35.DOMAINCONTROL.COM
> >       NS36.DOMAINCONTROL.COM
> >
> >
> >
> > braaen at brian:~$ dig OVERPROMISESUNDERDELIVERS.NET
> >
> > ; <<>> DiG 9.7.3 <<>> OVERPROMISESUNDERDELIVERS.NET
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40339
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> >
> > ;; QUESTION SECTION:
> > ;OVERPROMISESUNDERDELIVERS.NET. IN      A
> >
> > ;; ANSWER SECTION:
> > OVERPROMISESUNDERDELIVERS.NET. 3364 IN  A       98.129.229.190
> >
> > ;; AUTHORITY SECTION:
> > OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS
> ns36.domaincontrol.com.
> > OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS
> ns35.domaincontrol.com.
> >
> > ;; ADDITIONAL SECTION:
> > ns35.domaincontrol.com. 3046    IN      A       216.69.185.18
> > ns36.domaincontrol.com. 3046    IN      A       208.109.255.18
> >
> >
> > braaen at brian:~$ dig -x 98.129.229.190
> >
> > ; <<>> DiG 9.7.3 <<>> -x 98.129.229.190
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26507
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;190.229.129.98.in-addr.arpa.   IN      PTR
> >
> > ;; AUTHORITY SECTION:
> > 229.129.98.in-addr.arpa. 300    IN      SOA     ns.rackspace.com.
> hostmaster.rackspace.com. 1314291452 3600 300 1814400 300
> >
> >
> >
> > ---
> > Brian Raaen
> > Network Architect
> > Zcorum
> > On Wed, Sep 14, 2011 at 11:42:35AM +0100, Martin Hepworth wrote:
> >> http://www.overpromisesunderdelivers.net/
> >>
> >>
> >> --
> >> Martin Hepworth
> >> Oxford, UK
> >
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1392 / Virus Database: 1520/3895 - Release Date: 09/13/11



From nanog at rhemasound.org  Wed Sep 14 06:58:21 2011
From: nanog at rhemasound.org (Brian Raaen)
Date: Wed, 14 Sep 2011 07:58:21 -0400
Subject: ouch..
In-Reply-To: <4E708E18.3070006@geier.ne.tz>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
Message-ID: <20110914115821.GB6498@brian>

Nice, I didn't see that.  Then I guess whoever set up this site was a shill for Cisco, I just love how instead of focusing on developing better products, that they are more about marketing now.

---
Brian Raaen
Network Architect
Zcorum

On Wed, Sep 14, 2011 at 02:20:56PM +0300, Frank Habicht wrote:
> Main cisco page has a link to it...
> 
> Frank
> 
> On 9/14/2011 2:15 PM, Brian Raaen wrote:
> > Looks like some random person registered this one.  The domain and ip do not look related to cisco even though someone has falsely pasted their logo all over the site.
> > 
> > 
> > 
> > whois overpromisesunderdelivers.net
> > 
> > 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.
> > 
> >    Domain Name: OVERPROMISESUNDERDELIVERS.NET
> >    Registrar: GODADDY.COM, INC.
> >    Whois Server: whois.godaddy.com
> >    Referral URL: http://registrar.godaddy.com
> >    Name Server: NS35.DOMAINCONTROL.COM
> >    Name Server: NS36.DOMAINCONTROL.COM
> >    Status: clientDeleteProhibited
> >    Status: clientRenewProhibited
> >    Status: clientTransferProhibited
> >    Status: clientUpdateProhibited
> >    Updated Date: 05-sep-2011
> >    Creation Date: 05-sep-2011
> >    Expiration Date: 05-sep-2012
> > 
> > Registrant:
> >    Domains by Proxy, Inc.
> >    DomainsByProxy.com
> >    15111 N. Hayden Rd., Ste 160, PMB 353
> >    Scottsdale, Arizona 85260
> >    United States
> > 
> >    Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
> >    Domain Name: OVERPROMISESUNDERDELIVERS.NET
> >       Created on: 05-Sep-11
> >       Expires on: 05-Sep-12
> >       Last Updated on: 05-Sep-11
> > 
> >    Administrative Contact:
> >       Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
> >       Domains by Proxy, Inc.
> >       DomainsByProxy.com
> >       15111 N. Hayden Rd., Ste 160, PMB 353
> >       Scottsdale, Arizona 85260
> >       United States
> >       (480) 624-2599      Fax -- (480) 624-2598
> > 
> >    Technical Contact:
> >       Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
> >       Domains by Proxy, Inc.
> >       DomainsByProxy.com
> >       15111 N. Hayden Rd., Ste 160, PMB 353
> >       Scottsdale, Arizona 85260
> >       United States
> >       (480) 624-2599      Fax -- (480) 624-2598
> > 
> >    Domain servers in listed order:
> >       NS35.DOMAINCONTROL.COM
> >       NS36.DOMAINCONTROL.COM
> > 
> > 
> > 
> > braaen at brian:~$ dig OVERPROMISESUNDERDELIVERS.NET
> > 
> > ; <<>> DiG 9.7.3 <<>> OVERPROMISESUNDERDELIVERS.NET
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40339
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> > 
> > ;; QUESTION SECTION:
> > ;OVERPROMISESUNDERDELIVERS.NET. IN      A
> > 
> > ;; ANSWER SECTION:
> > OVERPROMISESUNDERDELIVERS.NET. 3364 IN  A       98.129.229.190
> > 
> > ;; AUTHORITY SECTION:
> > OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns36.domaincontrol.com.
> > OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns35.domaincontrol.com.
> > 
> > ;; ADDITIONAL SECTION:
> > ns35.domaincontrol.com. 3046    IN      A       216.69.185.18
> > ns36.domaincontrol.com. 3046    IN      A       208.109.255.18
> > 
> > 
> > braaen at brian:~$ dig -x 98.129.229.190
> > 
> > ; <<>> DiG 9.7.3 <<>> -x 98.129.229.190
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26507
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> > 
> > ;; QUESTION SECTION:
> > ;190.229.129.98.in-addr.arpa.   IN      PTR
> > 
> > ;; AUTHORITY SECTION:
> > 229.129.98.in-addr.arpa. 300    IN      SOA     ns.rackspace.com. hostmaster.rackspace.com. 1314291452 3600 300 1814400 300
> > 
> > 
> > 
> > ---
> > Brian Raaen
> > Network Architect
> > Zcorum
> > On Wed, Sep 14, 2011 at 11:42:35AM +0100, Martin Hepworth wrote:
> >> http://www.overpromisesunderdelivers.net/
> >>
> >>
> >> -- 
> >> Martin Hepworth
> >> Oxford, UK
> > 
> 
> 


From bclark at spectraaccess.com  Wed Sep 14 07:01:28 2011
From: bclark at spectraaccess.com (Bret Clark)
Date: Wed, 14 Sep 2011 08:01:28 -0400
Subject: ouch..
In-Reply-To: <20110914115821.GB6498@brian>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <20110914115821.GB6498@brian>
Message-ID: <4E709798.1020703@spectraaccess.com>

On 09/14/2011 07:58 AM, Brian Raaen wrote:
> Nice, I didn't see that.  Then I guess whoever set up this site was a shill for Cisco, I just love how instead of focusing on developing better products, that they are more about marketing now.
>
> ---
> Brian Raaen
> Network Architect

Cisco has always been about marketing from since Chambers took over way 
back when!


From owen at delong.com  Wed Sep 14 07:29:40 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Sep 2011 05:29:40 -0700
Subject: what about the users re: NAT444 or ?
In-Reply-To: <0a4801cc729d$cbe69520$63b3bf60$@com>
References: <OFE03D0C83.D3E7AC70-ON85257904.005DDB08-85257904.005DF395@videotron.com>
 <7315DFDF-C5D2-4894-8980-F3E44C355D28@dds.nl>
 <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
 <4A76411A-509E-411A-B230-F2176793DCB7@delong.com>
 <D181DDABABE57E4DB72FEE00331478643BC0CC@EALPO1.ukbroadband.com>
 <CAD6AjGTQvx3OaVM5syPxR_9DZiEBp1Ls7ijqE0A_UvgvHcOUAg@mail.gmail.com>
 <DC69578A-2B2B-4364-8F10-737588559443@firsthand.net>
 <028401cc6e47$a3faae70$ebf00b50$@com>
 <23CAA459-B646-46C6-9EFC-D249678436E3@delong.com>
 <0a4801cc729d$cbe69520$63b3bf60$@com>
Message-ID: <E496F6B3-37E1-4F27-9D17-ECB482BDA50E@delong.com>


On Sep 13, 2011, at 10:18 PM, Dan Wing wrote:

>> One can do that with or without NAT. This claim that one cannot
>> keep a network running without a service provider connected if you
>> don't run NAT is a myth of dubious origin.
> 
> If the hosts are running DHCP, and the ISP is running the DHCP
> server?  I guess they will fall back (after a while) to link-local
> and continue on their merry way.
> 

That's some pretty big IFs. Even if I were using DHCP to get the prefix
from my service provider via DHCP-PD, I'd back-stop that with some
form of local DHCP server and deal with the need for manual intervention
when the provider renumbered me.

In my experience, getting renumbered is a rare enough experience that
I don't pay Comcast $60/year for a static address.

Owen

>>> can accomplish this pretty easily, because the IPv4 addresses in
>>> the home can be any IPv4 address whatsoever -- which allows the
>>> in-home CPE ("B4", in Dual Stack-Lite parlance) to assign any address
>>> it wants with its built-in DHCP server.)
>>> 
>> 
>> There are other ways to accomplish this as well.
> 
> -d
> 
>>> -d
>>> 
>>>> and less technically but relevant I think is to ask about cost? who
>>>> pays?
>> 
>> In some cases, ISPs will provide new CPE to their end users. In other
>> cases,
>> end-users will be expected to pay to upgrade their own.
>> 
>> Owen
>> 
>>>> 
>>>> 
>>>> Christian
>>>> 
>>>> On 8 Sep 2011, at 15:02, Cameron Byrne wrote:
>>>> 
>>>>> On Sep 8, 2011 1:47 AM, "Leigh Porter"
>> <leigh.porter at ukbroadband.com>
>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Owen DeLong [mailto:owen at delong.com]
>>>>>>> Sent: 08 September 2011 01:22
>>>>>>> To: Leigh Porter
>>>>>>> Cc: Seth Mos; NANOG
>>>>>>> Subject: Re: NAT444 or ?
>>>>>>> 
>>>>>>>> Considering that offices, schools etc regularly have far more
>> than
>>>> 10
>>>>>>> users per IP, I think this limit is a little low. I've happily
>> had
>>>>>>> around 300 per public IP address on a large WiFi network, granted
>>>> these
>>>>>>> are all different kinds of users, it is just something that
>>>> operational
>>>>>>> experience will have to demonstrate.
>>>>>>>> 
>>>>>>> Yes, but, you are counting individual users whereas at the NAT444
>>>>>>> level, what's really being counted is end-customer sites not
>>>> individual
>>>>>>> users, so the term
>>>>>>> "users" is a bit misleading in the context. A given end-customer
>>>> site
>>>>>>> may be from 1 to 50 or more individual users.
>>>>>> 
>>>>>> Indeed, my users are using LTE dongles mostly so I expect they
>> will
>>>> be
>>>>> single users. At the moment on the WiMAX network I see around 35
>>>> sessions
>>>>> from a WiMAX modem on average rising to about 50 at peak times.
>> These
>>>> are a
>>>>> combination of individual users and "home modems".
>>>>>> 
>>>>>> We had some older modems that had integrated NAT that was broken
>> and
>>>>> locked up the modem at 200 sessions. Then some old base station
>>>> software
>>>>> died at about 10K sessions. So we monitor these things now..
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> I would love to avoid NAT444, I do not see a viable way around
>> it
>>>> at
>>>>>>> the moment. Unless the Department of Work and Pensions release
>>>> their /8
>>>>>>> that is ;-)
>>>>>>>> 
>>>>>>> 
>>>>>>> The best mitigation really is to get IPv6 deployed as rapidly and
>>>>>>> widely as possible. The more stuff can go native IPv6, the less
>>>> depends
>>>>>>> on fragile NAT444.
>>>>>> 
>>>>>> Absolutely. Even things like google maps, if that can be dumped on
>>>> v6,
>>>>> it'll save a load of sessions from people. The sooner services such
>>>> as
>>>>> Microsoft Update turn on v6 the better as well. I would also like
>> the
>>>> CDNs
>>>>> to be able to deliver content in v6 (even if the main page is v4)
>>>> which
>>>>> again will reduce the traffic that has to traverse any NAT.
>>>>>> 
>>>>>> Soon, I think content providers (and providers of other services
>> on
>>>> the
>>>>> 'net) will roll v6 because of the performance increase as v6 will
>> not
>>>> have
>>>>> to traverse all this NAT and be subject to session limits, timeouts
>>>> and
>>>>> such.
>>>>>> 
>>>>> 
>>>>> What do you mean by performance increase? If performance equals
>>>> latency, v4
>>>>> will win for a long while still. Cgn does not add measurable
>> latency.
>>>>> 
>>>>> Cb
>>>>>> --
>>>>>> Leigh
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>> ______________________________________________________________________
>>>>>> This email has been scanned by the MessageLabs Email Security
>>>> System.
>>>>>> For more information please visit http://www.messagelabs.com/email
>>>>>> 
>>>> 
>> ______________________________________________________________________
>>>>>> 
>>> 
>>> 



From chuckchurch at gmail.com  Wed Sep 14 07:37:48 2011
From: chuckchurch at gmail.com (Chuck Church)
Date: Wed, 14 Sep 2011 08:37:48 -0400
Subject: ouch..
In-Reply-To: <00a601cc72d5$3dc653b0$b952fb10$@com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com>
Message-ID: <001601cc72db$1cd5a6f0$5680f4d0$@com>

-----Original Message-----
>From: Erik Bais [mailto:ebais at a2b-internet.com] 
>Sent: Wednesday, September 14, 2011 7:56 AM
>To: 'Frank Habicht'; nanog at nanog.org
>Subject: RE: ouch..


>Personally I think this is a pathetic action from Cisco, however I'm not
>surprised by them doing it ... 

>Regards,
>Erik Bais

Does seem odd that Cisco would use Go Daddy.  My first thought was a
disgruntled (ex) Juniper Employee.  Then again, Juniper did bash Cisco in
its cartoon strips all those years.  Payback???




From owen at delong.com  Wed Sep 14 07:44:08 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Sep 2011 05:44:08 -0700
Subject: ouch..
In-Reply-To: <4E708803.5040506@foobar.org>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <4E708803.5040506@foobar.org>
Message-ID: <1EF0E9C1-B1B9-45EA-80A2-54C6AB77073D@delong.com>


On Sep 14, 2011, at 3:54 AM, Nick Hilliard wrote:

> On 14/09/2011 11:42, Martin Hepworth wrote:
>> http://www.overpromisesunderdelivers.net/
> 
> Wow, classy.
> 
> Nick

Wow... If Cisco slides any further into mudslinging, I'll expect the company to run
for president.

Owen



From owen at delong.com  Wed Sep 14 07:47:23 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Sep 2011 05:47:23 -0700
Subject: ouch..
In-Reply-To: <20110914111508.GA6498@brian>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian>
Message-ID: <35786865-4BDF-49D7-9C9B-13DC2ED7951B@delong.com>

Or possibly Cisco is trying to cover their tracks.

Owen

On Sep 14, 2011, at 4:15 AM, Brian Raaen wrote:

> Looks like some random person registered this one.  The domain and ip do not look related to cisco even though someone has falsely pasted their logo all over the site.
> 
> 
> 
> whois overpromisesunderdelivers.net
> 
> 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.
> 
>   Domain Name: OVERPROMISESUNDERDELIVERS.NET
>   Registrar: GODADDY.COM, INC.
>   Whois Server: whois.godaddy.com
>   Referral URL: http://registrar.godaddy.com
>   Name Server: NS35.DOMAINCONTROL.COM
>   Name Server: NS36.DOMAINCONTROL.COM
>   Status: clientDeleteProhibited
>   Status: clientRenewProhibited
>   Status: clientTransferProhibited
>   Status: clientUpdateProhibited
>   Updated Date: 05-sep-2011
>   Creation Date: 05-sep-2011
>   Expiration Date: 05-sep-2012
> 
> Registrant:
>   Domains by Proxy, Inc.
>   DomainsByProxy.com
>   15111 N. Hayden Rd., Ste 160, PMB 353
>   Scottsdale, Arizona 85260
>   United States
> 
>   Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
>   Domain Name: OVERPROMISESUNDERDELIVERS.NET
>      Created on: 05-Sep-11
>      Expires on: 05-Sep-12
>      Last Updated on: 05-Sep-11
> 
>   Administrative Contact:
>      Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
>      Domains by Proxy, Inc.
>      DomainsByProxy.com
>      15111 N. Hayden Rd., Ste 160, PMB 353
>      Scottsdale, Arizona 85260
>      United States
>      (480) 624-2599      Fax -- (480) 624-2598
> 
>   Technical Contact:
>      Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
>      Domains by Proxy, Inc.
>      DomainsByProxy.com
>      15111 N. Hayden Rd., Ste 160, PMB 353
>      Scottsdale, Arizona 85260
>      United States
>      (480) 624-2599      Fax -- (480) 624-2598
> 
>   Domain servers in listed order:
>      NS35.DOMAINCONTROL.COM
>      NS36.DOMAINCONTROL.COM
> 
> 
> 
> braaen at brian:~$ dig OVERPROMISESUNDERDELIVERS.NET
> 
> ; <<>> DiG 9.7.3 <<>> OVERPROMISESUNDERDELIVERS.NET
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40339
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> 
> ;; QUESTION SECTION:
> ;OVERPROMISESUNDERDELIVERS.NET. IN      A
> 
> ;; ANSWER SECTION:
> OVERPROMISESUNDERDELIVERS.NET. 3364 IN  A       98.129.229.190
> 
> ;; AUTHORITY SECTION:
> OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns36.domaincontrol.com.
> OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns35.domaincontrol.com.
> 
> ;; ADDITIONAL SECTION:
> ns35.domaincontrol.com. 3046    IN      A       216.69.185.18
> ns36.domaincontrol.com. 3046    IN      A       208.109.255.18
> 
> 
> braaen at brian:~$ dig -x 98.129.229.190
> 
> ; <<>> DiG 9.7.3 <<>> -x 98.129.229.190
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26507
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;190.229.129.98.in-addr.arpa.   IN      PTR
> 
> ;; AUTHORITY SECTION:
> 229.129.98.in-addr.arpa. 300    IN      SOA     ns.rackspace.com. hostmaster.rackspace.com. 1314291452 3600 300 1814400 300
> 
> 
> 
> ---
> Brian Raaen
> Network Architect
> Zcorum
> On Wed, Sep 14, 2011 at 11:42:35AM +0100, Martin Hepworth wrote:
>> http://www.overpromisesunderdelivers.net/
>> 
>> 
>> -- 
>> Martin Hepworth
>> Oxford, UK



From saku at ytti.fi  Wed Sep 14 07:56:05 2011
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 14 Sep 2011 15:56:05 +0300
Subject: ouch..
In-Reply-To: <001601cc72db$1cd5a6f0$5680f4d0$@com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com>
 <001601cc72db$1cd5a6f0$5680f4d0$@com>
Message-ID: <20110914125605.GA10496@pob.ytti.fi>


One:
> Looks like some random person registered this one.  The domain and ip do not
> look related to cisco even though someone has falsely pasted their logo all
> over the site.

Another:
> Does seem odd that Cisco would use Go Daddy.  My first thought was a
> disgruntled (ex) Juniper Employee.  Then again, Juniper did bash Cisco in
> its cartoon strips all those years.  Payback???

I'm bit surprised people actually think where campaign site is hosted and who
has registered domain can be used to predict who is responsible for it. Cisco
marketing probably have tons of webshops from whom they buy campaigns, what
ever company was responsibly for winning this bid happens to use godaddy and
rackspace.
Our marketing has bought campaigns which have been hosted in our competitors
networks, they don't understand to ask from the bidder where and how will the
pages be hosted.


-- 
  ++ytti


From nmaxpierson at gmail.com  Wed Sep 14 08:33:22 2011
From: nmaxpierson at gmail.com (N. Max Pierson)
Date: Wed, 14 Sep 2011 08:33:22 -0500
Subject: ouch..
In-Reply-To: <20110914125605.GA10496@pob.ytti.fi>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com>
 <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
Message-ID: <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>

Check out the White Papar referenced ....

http://www.overpromisesunderdelivers.net/pdfs/Why_Cisco_Not_Juniper.pdf

It has Cisco's usual White Paper format and their copyright stamped on the
bottom which is also dates "9/11". If it's not Cisco or one of it's
affiliates, I would expect them to be contacting their so called "Marketing"
folks anytime now.

If this really is Cisco .... i'm with Owen and expect a presidential bid
announcement any second now ....

Either way, it's pathetic. If someone is going to slander in the fashion the
site has done, they should at least put a contact form somewhere for some
feedback :)

-
Max

On Wed, Sep 14, 2011 at 7:56 AM, Saku Ytti <saku at ytti.fi> wrote:

>
> One:
> > Looks like some random person registered this one.  The domain and ip do
> not
> > look related to cisco even though someone has falsely pasted their logo
> all
> > over the site.
>
> Another:
> > Does seem odd that Cisco would use Go Daddy.  My first thought was a
> > disgruntled (ex) Juniper Employee.  Then again, Juniper did bash Cisco in
> > its cartoon strips all those years.  Payback???
>
> I'm bit surprised people actually think where campaign site is hosted and
> who
> has registered domain can be used to predict who is responsible for it.
> Cisco
> marketing probably have tons of webshops from whom they buy campaigns, what
> ever company was responsibly for winning this bid happens to use godaddy
> and
> rackspace.
> Our marketing has bought campaigns which have been hosted in our
> competitors
> networks, they don't understand to ask from the bidder where and how will
> the
> pages be hosted.
>
>
> --
>  ++ytti
>
>

From morrowc.lists at gmail.com  Wed Sep 14 08:35:38 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 14 Sep 2011 09:35:38 -0400
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <4E702599.6020509@elcsplace.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <4E6F7533.4020901@klaver.it>
 <CAL9jLabBszvurr_VAUb3ryVYq+GkZNCAsm8FTDDs1m9hJGSv+w@mail.gmail.com>
 <4E70208A.3010103@jima.tk>
 <CAL9jLabGYJbYYVT1o+fcLGqOaD3q_i3hQDPqg0jNx7HeAHZupA@mail.gmail.com>
 <4E702599.6020509@elcsplace.com>
Message-ID: <CAL9jLaZ=4JGYuqQTBnC1a2oN2JCBRoybDC5yT8NVgue=dBaVAA@mail.gmail.com>

On Tue, Sep 13, 2011 at 11:55 PM, Ted Cooper
<ml-nanog090304q at elcsplace.com> wrote:
>
> As claimed by the DigiNotar hacker - He compromised their servers but
> Eddy was manually approving certs at the time and so no certs were signed.
>
> There was information about it on the site, but it seems to be gone now.
> Articles still show a screenshot of the message you're talking about [1]
> , but the site was back alive in July when I needed a certificate.
>
> "A separate notice on another part of the company's site says that its
> services would be unavailable until June 20, " [2]
>
> I've certainly been able to issue certificates for myself since then.

indeed, cool! I was able to have a site cert issued lastnight as well.
This is (for me) good news :)

-chris


From nanog at u61.u22.net  Wed Sep 14 08:36:55 2011
From: nanog at u61.u22.net (Always Learning)
Date: Wed, 14 Sep 2011 14:36:55 +0100
Subject: ouch..
In-Reply-To: <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com> <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
Message-ID: <1316007415.15630.12.camel@m6.u226.com>


On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:

> Either way, it's pathetic. If someone is going to slander in the
> fashion the site has done, they should at least put a contact form
> somewhere for some feedback :)

Slander means falsehood. Cisco tells lies ?


-- 
With best regards,

Paul.
England,
EU.




From sthaug at nethelp.no  Wed Sep 14 08:40:26 2011
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 14 Sep 2011 15:40:26 +0200 (CEST)
Subject: ouch..
In-Reply-To: <1316007415.15630.12.camel@m6.u226.com>
References: <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
Message-ID: <20110914.154026.74699429.sthaug@nethelp.no>

> Slander means falsehood. Cisco tells lies ?

If you believe any vendors out there are white knights (telling no
lies) you may need a reality check.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no


From nmaxpierson at gmail.com  Wed Sep 14 08:44:10 2011
From: nmaxpierson at gmail.com (N. Max Pierson)
Date: Wed, 14 Sep 2011 08:44:10 -0500
Subject: ouch..
In-Reply-To: <1316007415.15630.12.camel@m6.u226.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com>
 <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
Message-ID: <CAD69L80w3Jc4WPbQLRV7YYgDQBLUxugz8E7Azoc5ZKFJxNBtqg@mail.gmail.com>

Define Cisco in your context please. Cisco marketing?? Cisco sales?? Cisco
TAC? Cisco product development??

I've been told several lies by some Cisco SE's that have worked with me, but
I wouldn't go as far to say "Cisco lies".

-
Max

On Wed, Sep 14, 2011 at 8:36 AM, Always Learning <nanog at u61.u22.net> wrote:

>
> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
>
> > Either way, it's pathetic. If someone is going to slander in the
> > fashion the site has done, they should at least put a contact form
> > somewhere for some feedback :)
>
> Slander means falsehood. Cisco tells lies ?
>
>
> --
> With best regards,
>
> Paul.
> England,
> EU.
>
>
>

From james at freedomnet.co.nz  Wed Sep 14 08:56:53 2011
From: james at freedomnet.co.nz (James Jones)
Date: Wed, 14 Sep 2011 06:56:53 -0700
Subject: ouch..
In-Reply-To: <1316007415.15630.12.camel@m6.u226.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com> <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
Message-ID: <E951DD90-165C-49E0-8239-8CA6840FEA67@freedomnet.co.nz>

:)

Sent from my iPhone

On Sep 14, 2011, at 6:36 AM, Always Learning <nanog at u61.u22.net> wrote:

> 
> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
> 
>> Either way, it's pathetic. If someone is going to slander in the
>> fashion the site has done, they should at least put a contact form
>> somewhere for some feedback :)
> 
> Slander means falsehood. Cisco tells lies ?
> 
> 
> -- 
> With best regards,
> 
> Paul.
> England,
> EU.
> 
> 
> 


From Valdis.Kletnieks at vt.edu  Wed Sep 14 09:15:57 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 14 Sep 2011 10:15:57 -0400
Subject: ouch..
In-Reply-To: Your message of "Wed, 14 Sep 2011 08:44:10 CDT."
 <CAD69L80w3Jc4WPbQLRV7YYgDQBLUxugz8E7Azoc5ZKFJxNBtqg@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com> <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <CAD69L80w3Jc4WPbQLRV7YYgDQBLUxugz8E7Azoc5ZKFJxNBtqg@mail.gmail.com>
Message-ID: <149550.1316009757@turing-police.cc.vt.edu>

On Wed, 14 Sep 2011 08:44:10 CDT, "N. Max Pierson" said:
> Define Cisco in your context please. Cisco marketing?? Cisco sales?? Cisco
> TAC? Cisco product development??

Cisco outsourced PR campaign?  Wouldn't be the first time a company has hired a
shop, stuck a link to the result on their home page, and then been surprised by
what they linked to.

In any case, I'm sure *somebody* is having an uncomfortable conversation
in their supervisor's office this morning. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110914/df604886/attachment.bin>

From leigh.porter at ukbroadband.com  Wed Sep 14 09:41:26 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 14 Sep 2011 14:41:26 +0000
Subject: ouch..
In-Reply-To: <1316007415.15630.12.camel@m6.u226.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com> <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Always Learning [mailto:nanog at u61.u22.net]
> Sent: 14 September 2011 14:39
> To: N. Max Pierson
> Cc: nanog at nanog.org
> Subject: Re: ouch..
> 
> 
> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
> 
> > Either way, it's pathetic. If someone is going to slander in the
> > fashion the site has done, they should at least put a contact form
> > somewhere for some feedback :)
> 
> Slander means falsehood. Cisco tells lies ?
> 
> 
> --
> With best regards,
> 
> Paul.
> England,
> EU.


Lies? So who has 100G MX series cards then..?

--
Leigh



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From james at freedomnet.co.nz  Wed Sep 14 10:00:18 2011
From: james at freedomnet.co.nz (James Jones)
Date: Wed, 14 Sep 2011 08:00:18 -0700
Subject: ouch..
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com> <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
Message-ID: <7033AC21-3074-4541-8D5C-B37E7AF57201@freedomnet.co.nz>

Funny they forget to mention that Cisco doesn't have 100g any where.

Sent from my iPhone

On Sep 14, 2011, at 7:41 AM, Leigh Porter <leigh.porter at ukbroadband.com> wrote:

> 
> 
>> -----Original Message-----
>> From: Always Learning [mailto:nanog at u61.u22.net]
>> Sent: 14 September 2011 14:39
>> To: N. Max Pierson
>> Cc: nanog at nanog.org
>> Subject: Re: ouch..
>> 
>> 
>> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
>> 
>>> Either way, it's pathetic. If someone is going to slander in the
>>> fashion the site has done, they should at least put a contact form
>>> somewhere for some feedback :)
>> 
>> Slander means falsehood. Cisco tells lies ?
>> 
>> 
>> --
>> With best regards,
>> 
>> Paul.
>> England,
>> EU.
> 
> 
> Lies? So who has 100G MX series cards then..?
> 
> --
> Leigh
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 


From Allen.Sutton at CenturyLink.com  Wed Sep 14 10:45:12 2011
From: Allen.Sutton at CenturyLink.com (Sutton, Allen)
Date: Wed, 14 Sep 2011 10:45:12 -0500
Subject: NANOG Digest, Vol 44, Issue 55 - Re: ouch..
In-Reply-To: <mailman.7604.1316001353.1873.nanog@nanog.org>
References: <mailman.7604.1316001353.1873.nanog@nanog.org>
Message-ID: <748075CF27B6504182B8F3F8E23C2FA341B015D40E@PKDWES2V3.EQ.Intranet>


Well, I'm not surprised at all, being that Cisco also does this to Alcatel-Lucent:

http://www.youtube.com/watch?v=uX3zvjX3c5Q

I think Cisco is just running scared now.  If they didn't charge so much for their products, they wouldn't have this problem.  In addition, I think they also thought that they would be # 1 forever and that nobody could touch them, so they just stopped trying to stay ahead of the competition.
_________________________________
Allen


-----Original Message-----
From: nanog-request at nanog.org [mailto:nanog-request at nanog.org]
Sent: Wednesday, September 14, 2011 7:56 AM
To: nanog at nanog.org
Subject: NANOG Digest, Vol 44, Issue 55

Send NANOG mailing list submissions to
        nanog at nanog.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://mailman.nanog.org/mailman/listinfo/nanog
or, via email, send a message with subject or body 'help' to
        nanog-request at nanog.org

You can reach the person managing the list at
        nanog-owner at nanog.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..."


Today's Topics:

   1. RE: NAT444 or ? (Dan Wing)
   2. ouch.. (Martin Hepworth)
   3. Re: ouch.. (Vlad Galu)
   4. Re: ouch.. (Nick Hilliard)
   5. Re: ouch.. (Brian Raaen)
   6. Re: ouch.. (Always Learning)
   7. Re: ouch.. (Frank Habicht)
   8. HP A-series, H3C, Huawei and their capabilities in real-life
      (Mark Smith)
   9. RE: ouch.. (Erik Bais)


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

Message: 1
Date: Tue, 13 Sep 2011 22:28:17 -0700
From: "Dan Wing" <dwing at cisco.com>
To: "'Owen DeLong'" <owen at delong.com>
Cc: nanog at nanog.org
Subject: RE: NAT444 or ?
Message-ID: <0a4d01cc729f$1bc0abc0$53420340$@com>
Content-Type: text/plain;       charset="us-ascii"

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Tuesday, September 13, 2011 9:43 PM
> To: Dan Wing
> Cc: 'Leigh Porter'; 'David Israel'; nanog at nanog.org
> Subject: Re: NAT444 or ?
>
> >>
> >> Good point, but aside from these scaling issues which I expect can
> be
> >> resolved to a point, the more serious issue, I think, is
> applications
> >> that just do not work with double NAT. Now, I have not conducted
> >> any serious research into this, but it seems that
> >> draft-donley-nat444- impacts does appear to have highlight issues
> >> that may have been down
> to
> >> implementation.
> >
> > Draft-donley-nat444-impacts conflates bandwidth constraints with CGN
> > with in-home NAT.  Until those are separated and then analyzed
> carefully,
> > it is harmful to draw conclusions such as "NAT444 bad; NAT44 good".
> >
>
> Continuing to make this claim does not make it any more true.
>
> Draft-donley took networks and measured their real-world functionality
> without NAT444, then, added NAT444 and repeated the same tests.
> Regardless of the underlying issue(s), the addition of NAT444 to the
> mix resulted in the forms of service degradation enumerated in the
> draft.

I disagree it reached that conclusion.  That may have been its intent.

> Further, I would not ever say "NAT444 bad; NAT44 good". I would say,
> rather, "NAT44 bad, NAT444 worse". I think that's a pretty safe and
> non-harmful thing to say.

Yes, your statement is completely accurate.  I agree that IPv4 address sharing causes additional problems (which encompasses all forms of
IPv4 address sharing), and CGN causes additional problems.

> >> Other simple tricks such as ensuring that your own internal
> >> services such as DNS are available without traversing NAT also help.
> >
> > Yep.  But some users want to use other DNS servers for performance
> > (e.g., Google's or OpenDNS servers, especially considering they
> > could point the user at a 'better' (closer) CDN based on Client IP),
> > to avoid ISP DNS hijacking, or for content control (e.g., "parental
> > control" of DNS hostnames).  That traffic will,
> necessarily,
> > traverse the CGN.  To avoid users burning through their UDP port
> > allocation for those DNS queries it is useful for the CGN to have
> > short timeouts for port 53.
> >
> If the user chooses to use a DNS server on the other side of a NAT,
> then, they are choosing to inflict whatever damage upon themselves.
> I'm not saying that short UDP/53 timeouts are a bad idea, but, I am
> saying that the more stuff you funnel through an LSN at the carrier,
> the more stuff you will see break. This would lead me to want to avoid
> funneling anything through said NAT which I could avoid. Then again, I
> run my own authoritative and recursive nameservers in my home and
> don't use any NAT at all, so, perhaps my perspective is different from
> others.

Yeah, you are probably of about 1000 or maybe 3000 people in the world that do that.  Seems to be a minority.

> >> Certainly some more work can be done in this area, but I fear that
> the
> >> only way a real idea as to how much NAT444 really doe break things
> will
> >> be operational experience.
> >
> > Yep.  (Same as everything else.)
> >
>
> I'm sure that will happen soon enough. I, for one, am not looking
> forward to the experience.

Neither am I.

But if major content providers cannot provide AAAA on their properties, and if ISPs and CPE vendors do not make IPv6 available and working, and if web browsers don't adopt faster fallback to IPv4 when IPv6 is borked ....  We will all be behind NATs.

-d





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

Message: 2
Date: Wed, 14 Sep 2011 11:42:35 +0100
From: Martin Hepworth <maxsec at gmail.com>
To: nanog at nanog.org
Subject: ouch..
Message-ID:
        <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

http://www.overpromisesunderdelivers.net/


--
Martin Hepworth
Oxford, UK


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

Message: 3
Date: Wed, 14 Sep 2011 12:51:00 +0200
From: Vlad Galu <galu at packetdam.com>
To: Martin Hepworth <maxsec at gmail.com>
Cc: nanog at nanog.org
Subject: Re: ouch..
Message-ID: <E963444C-A6C5-4399-AB1D-806F59C63389 at packetdam.com>
Content-Type: text/plain; charset=iso-8859-1

On Sep 14, 2011, at 12:42 PM, Martin Hepworth wrote:
> http://www.overpromisesunderdelivers.net/


Saying the other brand sucks doesn't make yours any better. Besides, there are other big players on the market. Terribly lame of Cisco...

Vlad Galu
galu at packetdam.com







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

Message: 4
Date: Wed, 14 Sep 2011 11:54:59 +0100
From: Nick Hilliard <nick at foobar.org>
To: nanog at nanog.org
Subject: Re: ouch..
Message-ID: <4E708803.5040506 at foobar.org>
Content-Type: text/plain; charset=ISO-8859-1

On 14/09/2011 11:42, Martin Hepworth wrote:
> http://www.overpromisesunderdelivers.net/

Wow, classy.

Nick



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

Message: 5
Date: Wed, 14 Sep 2011 07:15:08 -0400
From: Brian Raaen <nanog at rhemasound.org>
To: Martin Hepworth <maxsec at gmail.com>
Cc: nanog at nanog.org
Subject: Re: ouch..
Message-ID: <20110914111508.GA6498 at brian>
Content-Type: text/plain; charset=us-ascii

Looks like some random person registered this one.  The domain and ip do not look related to cisco even though someone has falsely pasted their logo all over the site.



whois overpromisesunderdelivers.net

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.

   Domain Name: OVERPROMISESUNDERDELIVERS.NET
   Registrar: GODADDY.COM, INC.
   Whois Server: whois.godaddy.com
   Referral URL: http://registrar.godaddy.com
   Name Server: NS35.DOMAINCONTROL.COM
   Name Server: NS36.DOMAINCONTROL.COM
   Status: clientDeleteProhibited
   Status: clientRenewProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Updated Date: 05-sep-2011
   Creation Date: 05-sep-2011
   Expiration Date: 05-sep-2012

Registrant:
   Domains by Proxy, Inc.
   DomainsByProxy.com
   15111 N. Hayden Rd., Ste 160, PMB 353
   Scottsdale, Arizona 85260
   United States

   Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
   Domain Name: OVERPROMISESUNDERDELIVERS.NET
      Created on: 05-Sep-11
      Expires on: 05-Sep-12
      Last Updated on: 05-Sep-11

   Administrative Contact:
      Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
      Domains by Proxy, Inc.
      DomainsByProxy.com
      15111 N. Hayden Rd., Ste 160, PMB 353
      Scottsdale, Arizona 85260
      United States
      (480) 624-2599      Fax -- (480) 624-2598

   Technical Contact:
      Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
      Domains by Proxy, Inc.
      DomainsByProxy.com
      15111 N. Hayden Rd., Ste 160, PMB 353
      Scottsdale, Arizona 85260
      United States
      (480) 624-2599      Fax -- (480) 624-2598

   Domain servers in listed order:
      NS35.DOMAINCONTROL.COM
      NS36.DOMAINCONTROL.COM



braaen at brian:~$ dig OVERPROMISESUNDERDELIVERS.NET

; <<>> DiG 9.7.3 <<>> OVERPROMISESUNDERDELIVERS.NET
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40339
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;OVERPROMISESUNDERDELIVERS.NET. IN      A

;; ANSWER SECTION:
OVERPROMISESUNDERDELIVERS.NET. 3364 IN  A       98.129.229.190

;; AUTHORITY SECTION:
OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns36.domaincontrol.com.
OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns35.domaincontrol.com.

;; ADDITIONAL SECTION:
ns35.domaincontrol.com. 3046    IN      A       216.69.185.18
ns36.domaincontrol.com. 3046    IN      A       208.109.255.18


braaen at brian:~$ dig -x 98.129.229.190

; <<>> DiG 9.7.3 <<>> -x 98.129.229.190
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26507
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;190.229.129.98.in-addr.arpa.   IN      PTR

;; AUTHORITY SECTION:
229.129.98.in-addr.arpa. 300    IN      SOA     ns.rackspace.com. hostmaster.rackspace.com. 1314291452 3600 300 1814400 300



---
Brian Raaen
Network Architect
Zcorum
On Wed, Sep 14, 2011 at 11:42:35AM +0100, Martin Hepworth wrote:
> http://www.overpromisesunderdelivers.net/
>
>
> --
> Martin Hepworth
> Oxford, UK



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

Message: 6
Date: Wed, 14 Sep 2011 12:20:15 +0100
From: Always Learning <nanog at u61.u22.net>
To: Brian Raaen <nanog at rhemasound.org>
Cc: nanog at nanog.org
Subject: Re: ouch..
Message-ID: <1315999215.15630.3.camel at m6.u226.com>
Content-Type: text/plain


On Wed, 2011-09-14 at 07:15 -0400, Brian Raaen wrote:

> Looks like some random person registered this one.  The domain and ip
> do not look related to cisco even though someone has falsely pasted
> their logo all over the site.

(1) If Cisco were responsible, would they want to advertise the fact ?

(2) If Cisco feel their intellectual and copyright property is being
abused, Cisco lawyers would have the Cisco name and branding removed in
seconds !


Paul,
England,
EU.





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

Message: 7
Date: Wed, 14 Sep 2011 14:20:56 +0300
From: Frank Habicht <geier at geier.ne.tz>
To: nanog at nanog.org
Subject: Re: ouch..
Message-ID: <4E708E18.3070006 at geier.ne.tz>
Content-Type: text/plain; charset=ISO-8859-1

Main cisco page has a link to it...

Frank

On 9/14/2011 2:15 PM, Brian Raaen wrote:
> Looks like some random person registered this one.  The domain and ip do not look related to cisco even though someone has falsely pasted their logo all over the site.
>
>
>
> whois overpromisesunderdelivers.net
>
> 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.
>
>    Domain Name: OVERPROMISESUNDERDELIVERS.NET
>    Registrar: GODADDY.COM, INC.
>    Whois Server: whois.godaddy.com
>    Referral URL: http://registrar.godaddy.com
>    Name Server: NS35.DOMAINCONTROL.COM
>    Name Server: NS36.DOMAINCONTROL.COM
>    Status: clientDeleteProhibited
>    Status: clientRenewProhibited
>    Status: clientTransferProhibited
>    Status: clientUpdateProhibited
>    Updated Date: 05-sep-2011
>    Creation Date: 05-sep-2011
>    Expiration Date: 05-sep-2012
>
> Registrant:
>    Domains by Proxy, Inc.
>    DomainsByProxy.com
>    15111 N. Hayden Rd., Ste 160, PMB 353
>    Scottsdale, Arizona 85260
>    United States
>
>    Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
>    Domain Name: OVERPROMISESUNDERDELIVERS.NET
>       Created on: 05-Sep-11
>       Expires on: 05-Sep-12
>       Last Updated on: 05-Sep-11
>
>    Administrative Contact:
>       Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
>       Domains by Proxy, Inc.
>       DomainsByProxy.com
>       15111 N. Hayden Rd., Ste 160, PMB 353
>       Scottsdale, Arizona 85260
>       United States
>       (480) 624-2599      Fax -- (480) 624-2598
>
>    Technical Contact:
>       Private, Registration  OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
>       Domains by Proxy, Inc.
>       DomainsByProxy.com
>       15111 N. Hayden Rd., Ste 160, PMB 353
>       Scottsdale, Arizona 85260
>       United States
>       (480) 624-2599      Fax -- (480) 624-2598
>
>    Domain servers in listed order:
>       NS35.DOMAINCONTROL.COM
>       NS36.DOMAINCONTROL.COM
>
>
>
> braaen at brian:~$ dig OVERPROMISESUNDERDELIVERS.NET
>
> ; <<>> DiG 9.7.3 <<>> OVERPROMISESUNDERDELIVERS.NET
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40339
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
>
> ;; QUESTION SECTION:
> ;OVERPROMISESUNDERDELIVERS.NET. IN      A
>
> ;; ANSWER SECTION:
> OVERPROMISESUNDERDELIVERS.NET. 3364 IN  A       98.129.229.190
>
> ;; AUTHORITY SECTION:
> OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns36.domaincontrol.com.
> OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS      ns35.domaincontrol.com.
>
> ;; ADDITIONAL SECTION:
> ns35.domaincontrol.com. 3046    IN      A       216.69.185.18
> ns36.domaincontrol.com. 3046    IN      A       208.109.255.18
>
>
> braaen at brian:~$ dig -x 98.129.229.190
>
> ; <<>> DiG 9.7.3 <<>> -x 98.129.229.190
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26507
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;190.229.129.98.in-addr.arpa.   IN      PTR
>
> ;; AUTHORITY SECTION:
> 229.129.98.in-addr.arpa. 300    IN      SOA     ns.rackspace.com. hostmaster.rackspace.com. 1314291452 3600 300 1814400 300
>
>
>
> ---
> Brian Raaen
> Network Architect
> Zcorum
> On Wed, Sep 14, 2011 at 11:42:35AM +0100, Martin Hepworth wrote:
>> http://www.overpromisesunderdelivers.net/
>>
>>
>> --
>> Martin Hepworth
>> Oxford, UK
>




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

Message: 8
Date: Wed, 14 Sep 2011 14:27:20 +0300
From: Mark Smith <markrefresh12 at gmail.com>
To: NANOG at nanog.org
Subject: HP A-series, H3C, Huawei and their capabilities in real-life
Message-ID:
        <CAE79DorP-waM_EdHQJvQMw+mftM+BAv35tGhTz7TeYJTy-ON1Q at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi list

Does anyone have (or know somebody who has) real-life experience of HP
A-series (former Huawei and H3C) high-end routers in service provider
environment? From the specs they look very good (both features and
performance) but the specs don't tell everything and nothing can
replace real-life experience.

The features I'm interested in include (not in any specific order)
- v4 and v6 routing
- BGP (full feed)
- OSPF and IS-IS
- MPLS(-TE) P/PE functionality (RSVP, L3VPN, VPLS)

For example this box
http://h17007.www1.hp.com/us/en/products/routers/HP_A8800_Router_Series/index.aspx

Any info or pointers greatly appreciated.

Rgds,
Mark



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

Message: 9
Date: Wed, 14 Sep 2011 13:55:47 +0200
From: "Erik Bais" <ebais at a2b-internet.com>
To: "'Frank Habicht'" <geier at geier.ne.tz>,      <nanog at nanog.org>
Subject: RE: ouch..
Message-ID: <00a601cc72d5$3dc653b0$b952fb10$@com>
Content-Type: text/plain;       charset="us-ascii"

Hi Frank,

http://blogs.cisco.com/tag/overpromise/

Quote from the blog: "Some vendors have repeatedly over-promised and under
delivered, and still somehow receive credit for their vision! (You can read
more about one vendor's repeated broken promises here.)"

http://www.overpromisesunderdelivers.net/

https://twitter.com/#!/CiscoSystems/status/113226120601677825

https://twitter.com/#!/CiscoNL/statuses/113577908525744129

Personally I think this is a pathetic action from Cisco, however I'm not
surprised by them doing it ...

Regards,
Erik Bais

> -----Original Message-----
> From: Frank Habicht [mailto:geier at geier.ne.tz]
> Sent: Wednesday, September 14, 2011 1:21 PM
> To: nanog at nanog.org
> Subject: Re: ouch..
>
> Main cisco page has a link to it...
>
> Frank
>
> On 9/14/2011 2:15 PM, Brian Raaen wrote:
> > Looks like some random person registered this one.  The domain and ip
> do not look related to cisco even though someone has falsely pasted
> their logo all over the site.
> >
> >
> >
> > whois overpromisesunderdelivers.net
> >
> > 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.
> >
> >    Domain Name: OVERPROMISESUNDERDELIVERS.NET
> >    Registrar: GODADDY.COM, INC.
> >    Whois Server: whois.godaddy.com
> >    Referral URL: http://registrar.godaddy.com
> >    Name Server: NS35.DOMAINCONTROL.COM
> >    Name Server: NS36.DOMAINCONTROL.COM
> >    Status: clientDeleteProhibited
> >    Status: clientRenewProhibited
> >    Status: clientTransferProhibited
> >    Status: clientUpdateProhibited
> >    Updated Date: 05-sep-2011
> >    Creation Date: 05-sep-2011
> >    Expiration Date: 05-sep-2012
> >
> > Registrant:
> >    Domains by Proxy, Inc.
> >    DomainsByProxy.com
> >    15111 N. Hayden Rd., Ste 160, PMB 353
> >    Scottsdale, Arizona 85260
> >    United States
> >
> >    Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
> >    Domain Name: OVERPROMISESUNDERDELIVERS.NET
> >       Created on: 05-Sep-11
> >       Expires on: 05-Sep-12
> >       Last Updated on: 05-Sep-11
> >
> >    Administrative Contact:
> >       Private, Registration
> OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
> >       Domains by Proxy, Inc.
> >       DomainsByProxy.com
> >       15111 N. Hayden Rd., Ste 160, PMB 353
> >       Scottsdale, Arizona 85260
> >       United States
> >       (480) 624-2599      Fax -- (480) 624-2598
> >
> >    Technical Contact:
> >       Private, Registration
> OVERPROMISESUNDERDELIVERS.NET at domainsbyproxy.com
> >       Domains by Proxy, Inc.
> >       DomainsByProxy.com
> >       15111 N. Hayden Rd., Ste 160, PMB 353
> >       Scottsdale, Arizona 85260
> >       United States
> >       (480) 624-2599      Fax -- (480) 624-2598
> >
> >    Domain servers in listed order:
> >       NS35.DOMAINCONTROL.COM
> >       NS36.DOMAINCONTROL.COM
> >
> >
> >
> > braaen at brian:~$ dig OVERPROMISESUNDERDELIVERS.NET
> >
> > ; <<>> DiG 9.7.3 <<>> OVERPROMISESUNDERDELIVERS.NET
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40339
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> >
> > ;; QUESTION SECTION:
> > ;OVERPROMISESUNDERDELIVERS.NET. IN      A
> >
> > ;; ANSWER SECTION:
> > OVERPROMISESUNDERDELIVERS.NET. 3364 IN  A       98.129.229.190
> >
> > ;; AUTHORITY SECTION:
> > OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS
> ns36.domaincontrol.com.
> > OVERPROMISESUNDERDELIVERS.NET. 3364 IN  NS
> ns35.domaincontrol.com.
> >
> > ;; ADDITIONAL SECTION:
> > ns35.domaincontrol.com. 3046    IN      A       216.69.185.18
> > ns36.domaincontrol.com. 3046    IN      A       208.109.255.18
> >
> >
> > braaen at brian:~$ dig -x 98.129.229.190
> >
> > ; <<>> DiG 9.7.3 <<>> -x 98.129.229.190
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26507
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;190.229.129.98.in-addr.arpa.   IN      PTR
> >
> > ;; AUTHORITY SECTION:
> > 229.129.98.in-addr.arpa. 300    IN      SOA     ns.rackspace.com.
> hostmaster.rackspace.com. 1314291452 3600 300 1814400 300
> >
> >
> >
> > ---
> > Brian Raaen
> > Network Architect
> > Zcorum
> > On Wed, Sep 14, 2011 at 11:42:35AM +0100, Martin Hepworth wrote:
> >> http://www.overpromisesunderdelivers.net/
> >>
> >>
> >> --
> >> Martin Hepworth
> >> Oxford, UK
> >
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1392 / Virus Database: 1520/3895 - Release Date: 09/13/11




End of NANOG Digest, Vol 44, Issue 55
*************************************


From paul at paulgraydon.co.uk  Wed Sep 14 10:46:19 2011
From: paul at paulgraydon.co.uk (Paul)
Date: Wed, 14 Sep 2011 05:46:19 -1000
Subject: ouch..
Message-ID: <mdaa47vlvw4clb323f6yellg.1316015179882@email.android.com>

http://www.cisco.com/en/US/prod/collateral/routers/ps5763/CRS-1x100GE_DS.html ? 

James Jones <james at freedomnet.co.nz> wrote:

>Funny they forget to mention that Cisco doesn't have 100g any where.
>
>Sent from my iPhone
>
>On Sep 14, 2011, at 7:41 AM, Leigh Porter <leigh.porter at ukbroadband.com> wrote:
>
>> 
>> 
>>> -----Original Message-----
>>> From: Always Learning [mailto:nanog at u61.u22.net]
>>> Sent: 14 September 2011 14:39
>>> To: N. Max Pierson
>>> Cc: nanog at nanog.org
>>> Subject: Re: ouch..
>>> 
>>> 
>>> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
>>> 
>>>> Either way, it's pathetic. If someone is going to slander in the
>>>> fashion the site has done, they should at least put a contact form
>>>> somewhere for some feedback :)
>>> 
>>> Slander means falsehood. Cisco tells lies ?
>>> 
>>> 
>>> --
>>> With best regards,
>>> 
>>> Paul.
>>> England,
>>> EU.
>> 
>> 
>> Lies? So who has 100G MX series cards then..?
>> 
>> --
>> Leigh
>> 
>> 
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
>> 
>

From randy at psg.com  Wed Sep 14 10:48:51 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 14 Sep 2011 17:48:51 +0200
Subject: ouch..
In-Reply-To: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
Message-ID: <m262kvt998.wl%randy@psg.com>

> http://www.overpromisesunderdelivers.net/

amazingly professional.  not.

but lead contestant for pathetic jealousy post of the year


From leigh.porter at ukbroadband.com  Wed Sep 14 11:01:43 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 14 Sep 2011 16:01:43 +0000
Subject: ouch..
In-Reply-To: <mdaa47vlvw4clb323f6yellg.1316015179882@email.android.com>
References: <mdaa47vlvw4clb323f6yellg.1316015179882@email.android.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643BF74B@EALPO1.ukbroadband.com>

Great, can you actually order one and really have it delivered? Not that you would really want to I guess, but if you were into that kind of thing..

Point me to it if I am wrong, but I still do not see an MX-series 100G interface even on the Juniper site..

http://www.juniper.net/us/en/products-services/routing/mx-series/mx960/#modules

--
Leigh


> -----Original Message-----
> From: Paul [mailto:paul at paulgraydon.co.uk]
> Sent: 14 September 2011 16:48
> To: James Jones; Leigh Porter
> Cc: nanog at nanog.org; Always Learning
> Subject: Re: ouch..
> 
> http://www.cisco.com/en/US/prod/collateral/routers/ps5763/CRS-
> 1x100GE_DS.html ?
> 
> James Jones <james at freedomnet.co.nz> wrote:
> 
> >Funny they forget to mention that Cisco doesn't have 100g any where.
> >
> >Sent from my iPhone
> >
> >On Sep 14, 2011, at 7:41 AM, Leigh Porter
> <leigh.porter at ukbroadband.com> wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: Always Learning [mailto:nanog at u61.u22.net]
> >>> Sent: 14 September 2011 14:39
> >>> To: N. Max Pierson
> >>> Cc: nanog at nanog.org
> >>> Subject: Re: ouch..
> >>>
> >>>
> >>> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
> >>>
> >>>> Either way, it's pathetic. If someone is going to slander in the
> >>>> fashion the site has done, they should at least put a contact form
> >>>> somewhere for some feedback :)
> >>>
> >>> Slander means falsehood. Cisco tells lies ?
> >>>
> >>>
> >>> --
> >>> With best regards,
> >>>
> >>> Paul.
> >>> England,
> >>> EU.
> >>
> >>
> >> Lies? So who has 100G MX series cards then..?
> >>
> >> --
> >> Leigh
> >>
> >>
> >>
> >>
> ______________________________________________________________________
> >> This email has been scanned by the MessageLabs Email Security
> System.
> >> For more information please visit http://www.messagelabs.com/email
> >>
> ______________________________________________________________________
> >>
> >
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

From james at freedomnet.co.nz  Wed Sep 14 11:01:29 2011
From: james at freedomnet.co.nz (James Jones)
Date: Wed, 14 Sep 2011 09:01:29 -0700
Subject: ouch..
In-Reply-To: <mdaa47vlvw4clb323f6yellg.1316015179882@email.android.com>
References: <mdaa47vlvw4clb323f6yellg.1316015179882@email.android.com>
Message-ID: <324CC9EB-FEA9-4F27-B1AC-D6A6890251AC@freedomnet.co.nz>

I stand corrected. I willing to admit when I am wrong. So do that only have 100Gb on the carrier routers?

Sent from my iPhone

On Sep 14, 2011, at 8:46 AM, Paul  <paul at paulgraydon.co.uk> wrote:

> http://www.cisco.com/en/US/prod/collateral/routers/ps5763/CRS-1x100GE_DS.html ? 
> 
> James Jones <james at freedomnet.co.nz> wrote:
> 
>> Funny they forget to mention that Cisco doesn't have 100g any where.
>> 
>> Sent from my iPhone
>> 
>> On Sep 14, 2011, at 7:41 AM, Leigh Porter <leigh.porter at ukbroadband.com> wrote:
>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Always Learning [mailto:nanog at u61.u22.net]
>>>> Sent: 14 September 2011 14:39
>>>> To: N. Max Pierson
>>>> Cc: nanog at nanog.org
>>>> Subject: Re: ouch..
>>>> 
>>>> 
>>>> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
>>>> 
>>>>> Either way, it's pathetic. If someone is going to slander in the
>>>>> fashion the site has done, they should at least put a contact form
>>>>> somewhere for some feedback :)
>>>> 
>>>> Slander means falsehood. Cisco tells lies ?
>>>> 
>>>> 
>>>> --
>>>> With best regards,
>>>> 
>>>> Paul.
>>>> England,
>>>> EU.
>>> 
>>> 
>>> Lies? So who has 100G MX series cards then..?
>>> 
>>> --
>>> Leigh
>>> 
>>> 
>>> 
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>> 
>> 


From davei at otd.com  Wed Sep 14 11:02:01 2011
From: davei at otd.com (David Israel)
Date: Wed, 14 Sep 2011 12:02:01 -0400
Subject: ouch..
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com> <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
Message-ID: <4E70CFF9.8050505@otd.com>

On 9/14/2011 10:41 AM, Leigh Porter wrote:
> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
>>> Either way, it's pathetic. If someone is going to slander in the
>>> fashion the site has done, they should at least put a contact form
>>> somewhere for some feedback :)
>> Slander means falsehood. Cisco tells lies ?
>>
>
> Lies? So who has 100G MX series cards then..?
>

That's disingenuous.  The question was not whether Cisco has ever lied, 
but whether the web page lies.  The web page very carefully picks and 
chooses facts, but I don't think it actually lies.  Therefore, it isn't 
slander.  It's just mudslinging.

Also, on another note, nobody should be surprised that the registration 
information doesn't say "Cisco."  Think about it: would they want "whois 
overpromisesunderdelivers.com" to say "Cisco" all over it?





From lou at metron.com  Wed Sep 14 12:02:48 2011
From: lou at metron.com (Lou Katz)
Date: Wed, 14 Sep 2011 10:02:48 -0700
Subject: Microsoft deems all DigiNotar certificates untrustworthy, releases
In-Reply-To: <20110913152427.GE19208@hiwaay.net>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <99196.1315926195@turing-police.cc.vt.edu>
 <20110913152427.GE19208@hiwaay.net>
Message-ID: <20110914170248.GA93613@metron.com>

The problem that I see with browser response to self-signed (or org generated) certs is
not the warning(s) but the assertion that the cert is invalid. Not issued by one of the
players in the Protection Racket does not make the cert invalid. It may be untrustable,
unreliable, from an unknown and/or unverifiable source, but it IS a valid cert. Certs in
a revocation list or malformed certs are invalid. 

After all, the Diginotar certs were 'valid', until revoked. Apparently the (arbitrary)
inclusion or exclusion of a root cert by each browser creator or distributer is
equated with validity. By removing the Diginotar root cert, suddenly ALL Diginotar
certs are now reported to end users as Invalid? By refusing to include a CACert root
certificate, no CACert certificate is 'valid'? I think not.

-- 

-=[L]=-
Hand typed on my Remington portable



From jeroen at unfix.org  Wed Sep 14 12:16:57 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Wed, 14 Sep 2011 19:16:57 +0200
Subject: Opta revokes Diginotar TTP license (Was: Microsoft deems all DigiNotar
 certificates untrustworthy, releases)
In-Reply-To: <20110914170248.GA93613@metron.com>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <99196.1315926195@turing-police.cc.vt.edu>
 <20110913152427.GE19208@hiwaay.net> <20110914170248.GA93613@metron.com>
Message-ID: <4E70E189.3070203@unfix.org>

And to end this thread as this effectively ends Diginotar troubles for
the Interwebz:

Dutch official statement:
http://www.opta.nl/nl/actueel/alle-publicaties/publicatie/?id=3469

English Summary "OPTA revokes Diginotar License as TTP":
http://www.circleid.com/posts/opta_revokes_diginotar_license_as_ttp/

Greets,
 Jeroen


From nanog at u61.u22.net  Wed Sep 14 14:53:54 2011
From: nanog at u61.u22.net (Always Learning)
Date: Wed, 14 Sep 2011 20:53:54 +0100
Subject: Opta revokes Diginotar TTP license (Was: Microsoft deems all
 DigiNotar certificates untrustworthy, releases)
In-Reply-To: <4E70E189.3070203@unfix.org>
References: <4E6CEDAB.4070307@bogus.com>
 <201109122242.35932.fredan-nanog@fredan.se>
 <alpine.LSU.2.00.1109122241480.24644@hermes-2.csi.cam.ac.uk>
 <201109130004.40256.fredan-nanog@fredan.se>
 <CACg3zYHrY7g1NhrrKGs=oPFKryr8pfvsrr=pxB5DY78Simx85Q@mail.gmail.com>
 <99196.1315926195@turing-police.cc.vt.edu>
 <20110913152427.GE19208@hiwaay.net> <20110914170248.GA93613@metron.com>
 <4E70E189.3070203@unfix.org>
Message-ID: <1316030034.15630.26.camel@m6.u226.com>


On Wed, 2011-09-14 at 19:16 +0200, Jeroen Massar wrote:

> And to end this thread as this effectively ends Diginotar troubles for
> the Interwebz:
> 
> Dutch official statement:
> http://www.opta.nl/nl/actueel/alle-publicaties/publicatie/?id=3469

Bedankt. Vertaling (my own translation, niet slecht voor een
buitenlander) ....

OPTA regulates the Dutch communications market including consumer
protection.

OPTA has now ended the registration of Diginotar as a supplier of
authorised certificates for electronic signatures. 

An investigation by OPTA revealed the trustworthiness of approved
certificates from Diginotar can no longer be guaranteed.

This means the business of issuing authorised certificates must stop and
no new authorised certificates must be issued.


-- 
With best regards,

Paul.
England,
EU.




From brandon.galbraith at gmail.com  Wed Sep 14 15:40:13 2011
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Wed, 14 Sep 2011 15:40:13 -0500
Subject: ouch..
In-Reply-To: <4E70CFF9.8050505@otd.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com>
 <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
 <4E70CFF9.8050505@otd.com>
Message-ID: <CADE4tYWnFYoXuC7h3jWAprbW8aYjgY2Lfcv+tJc9+ZBThgsRQA@mail.gmail.com>

On Wed, Sep 14, 2011 at 11:02 AM, David Israel <davei at otd.com> wrote:

> On 9/14/2011 10:41 AM, Leigh Porter wrote:
>
>> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
>>
>>> Either way, it's pathetic. If someone is going to slander in the
>>>> fashion the site has done, they should at least put a contact form
>>>> somewhere for some feedback :)
>>>>
>>> Slander means falsehood. Cisco tells lies ?
>>>
>>>
>> Lies? So who has 100G MX series cards then..?
>>
>>
> That's disingenuous.  The question was not whether Cisco has ever lied, but
> whether the web page lies.  The web page very carefully picks and chooses
> facts, but I don't think it actually lies.  Therefore, it isn't slander.
>  It's just mudslinging.
>
> Also, on another note, nobody should be surprised that the registration
> information doesn't say "Cisco."  Think about it: would they want "whois
> overpromisesunderdelivers.com" to say "Cisco" all over it?
>
>
Juniper: Who needs to waste time with pathetic marketing videos when you're
gear just works.

-- 
Brandon Galbraith
US Voice: 630.492.0464

From surfer at mauigateway.com  Wed Sep 14 16:05:13 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Wed, 14 Sep 2011 14:05:13 -0700
Subject: ouch..
Message-ID: <20110914140513.613A5998@resin15.mta.everyone.net>



--- brandon.galbraith at gmail.com wrote:
From: Brandon Galbraith <brandon.galbraith at gmail.com>

Juniper: Who needs to waste time with pathetic marketing videos when you're
gear just works.
---------------------------------------------------


Unless it's the ERX series.  Blech, it puts a bad taste in my mouth just writing the acronym ERX.  Thank $deity that I don't have to work on those anymore...

scott


From michael.hare at doit.wisc.edu  Wed Sep 14 16:20:13 2011
From: michael.hare at doit.wisc.edu (Michael Hare)
Date: Wed, 14 Sep 2011 16:20:13 -0500
Subject: ouch..
In-Reply-To: <20110914140513.613A5998@resin15.mta.everyone.net>
References: <20110914140513.613A5998@resin15.mta.everyone.net>
Message-ID: <4E711A8D.2070804@doit.wisc.edu>

You seem to have accidentally put an 'R' between your E and X ;)

On 9/14/2011 4:05 PM, Scott Weeks wrote:
>
>
> --- brandon.galbraith at gmail.com wrote:
> From: Brandon Galbraith<brandon.galbraith at gmail.com>
>
> Juniper: Who needs to waste time with pathetic marketing videos when you're
> gear just works.
> ---------------------------------------------------
>
>
> Unless it's the ERX series.  Blech, it puts a bad taste in my mouth just writing the acronym ERX.  Thank $deity that I don't have to work on those anymore...
>
> scott
>


From don at bowenvale.co.nz  Wed Sep 14 16:24:25 2011
From: don at bowenvale.co.nz (Don Gould)
Date: Thu, 15 Sep 2011 09:24:25 +1200
Subject: ouch..
In-Reply-To: <20110914140513.613A5998@resin15.mta.everyone.net>
References: <20110914140513.613A5998@resin15.mta.everyone.net>
Message-ID: <4E711B89.3080203@bowenvale.co.nz>

Well...

Seems to be popping up on global NOG lists today.

When you're already in trouble with the wife you go have a beer with 
your mates.

This campaign got all of you to stop talking about NAT444 and focused on 
talking about Cisco and Juniper gear.

Hell, if I put my tinfoil hat on, I'd say this was a joint venture by 
both vendors to get you all to focus on their kit and stop looking at 
other brands or talking about technology standards.

How many of you have sat and thought about the merit of this web site?

* Does Juniper break promises?
* Does Cisco break them?
* What bad things and experiences have you had with Cisco, Juniper?
* What is the best technology for each company?
* Did you know that Cisco has a 100Gb solution?

...I could go on...

It's 9:20am here and I woke up to a flurry of the worlds leading IP 
people talking about Cisco and Juniper -

To:  <TheMarketingGuysFromCiscoJuniper> From:  <OtherBrandUser>
Subject:  Global brand awareness Marketing campaign
----------------------------------------------------
Body:  Job well done.

D

On 15/09/2011 9:05 a.m., Scott Weeks wrote:
>
>
> --- brandon.galbraith at gmail.com wrote:
> From: Brandon Galbraith<brandon.galbraith at gmail.com>
>
> Juniper: Who needs to waste time with pathetic marketing videos when you're
> gear just works.
> ---------------------------------------------------
>
>
> Unless it's the ERX series.  Blech, it puts a bad taste in my mouth just writing the acronym ERX.  Thank $deity that I don't have to work on those anymore...
>
> scott
>




From bicknell at ufp.org  Wed Sep 14 16:46:51 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 14 Sep 2011 14:46:51 -0700
Subject: ouch..
In-Reply-To: <4E711B89.3080203@bowenvale.co.nz>
References: <20110914140513.613A5998@resin15.mta.everyone.net>
 <4E711B89.3080203@bowenvale.co.nz>
Message-ID: <20110914214651.GA64938@ussenterprise.ufp.org>

In a message written on Thu, Sep 15, 2011 at 09:24:25AM +1200, Don Gould wrote:
> How many of you have sat and thought about the merit of this web site?

Ok, I'll take a swing at your list...

> * Does Juniper break promises?

Yes.

> * Does Cisco break them?

Yes.

> * What bad things and experiences have you had with Cisco, Juniper?

It might take me several days, and many pages to compile that list.

> * What is the best technology for each company?

Cisco: The AGS+ was ahead of its time.
Jiniper: The Olive is quite nifty.

> * Did you know that Cisco has a 100Gb solution?

Yes, but I can't afford it.

Now, with that out of the way, how much does everyone else hate even the
thought of NAT444?

:) :) :)

-- 
       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/20110914/2c95de6d/attachment.bin>

From jra at baylink.com  Wed Sep 14 17:37:57 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 14 Sep 2011 18:37:57 -0400 (EDT)
Subject: Summary: US Colo transit pricing
In-Reply-To: <3896792.1869.1316038626542.JavaMail.root@benjamin.baylink.com>
Message-ID: <5532443.1889.1316039877175.JavaMail.root@benjamin.baylink.com>

My apologies; I was just too damned tired to do this last night, by which
time I had gotten my answer: $17 for a 5 way blend based on L3 and GBLX, in 
Tampa, isn't really all that bad. (100mbs commit; GigE fiber redundant)

City      Pipe        Commit        Carrier(s)         $/mbs
=======================================================================
various   1G+         unk           Cogent/HE          <1
various   1G          1G            HE                 1 for 3yr cont.
various   1G+         unk           carriers not spec  2-3
multi     10G/agg     10G           carrier not spec   3
various   unk         1G            carrier not spec   3-20[1]
LAmetro   4x1G        250-500M      carriers not spec  <5
NYC/colo  1G          500M          carrier not spec   5
var/colo  1G          100-1G        blend not spec     15-20 down to 8
Portland  1G          100M          AboveNet           9
various   unk         700Magg       Internap           9
var/colo  unk         unk           blend not spec.    10
various   unk         50-100M       carriers not spec  20-10
unk/colo  1G          150Magg       Tier2 not spec     15 renego from *50*
SF/colo   unk         "small"       carriers not spec  45

Those are sorted in ascending order by the lowest rate quoted; where
I could discern that it was for colo delivery, I've said so.  Some commits
(and hence rates) were aggregated over pipes or sites; if it was clear that
the price applied to multiple quotes or blended bandwidth I've noted that
too.

My thanks to the folks who took a moment to contribute; the outcome of my 
inquiry was "nah; I guess the price I got quoted really isn't all that bad,
given the quality of the datacenter involved (which is quite nicely done).

Cheers,
-- jra

[1]"depending on how many beers we'd had together at NANOG meetings"
-- 
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      http://photo.imageinc.us             +1 727 647 1274


From don at bowenvale.co.nz  Wed Sep 14 17:52:31 2011
From: don at bowenvale.co.nz (Don Gould)
Date: Thu, 15 Sep 2011 10:52:31 +1200
Subject: ouch..
In-Reply-To: <20110914214651.GA64938@ussenterprise.ufp.org>
References: <20110914140513.613A5998@resin15.mta.everyone.net>
 <4E711B89.3080203@bowenvale.co.nz>
 <20110914214651.GA64938@ussenterprise.ufp.org>
Message-ID: <4E71302F.6060205@bowenvale.co.nz>



On 15/09/2011 9:46 a.m., Leo Bicknell wrote:
> Now, with that out of the way, how much does everyone else hate even the
> thought of NAT444?

Clearly some hate it enough to go to the trouble of making a 'we think 
they suck' web site in an attempt to draw readers in a different direction.

Now with respect to your list... I'm sure there will be many that will 
be quite interested to see it, so Monday?

:)

Beer

D


From james at freedomnet.co.nz  Wed Sep 14 18:08:57 2011
From: james at freedomnet.co.nz (James Jones)
Date: Wed, 14 Sep 2011 16:08:57 -0700
Subject: ouch..
In-Reply-To: <20110914214651.GA64938@ussenterprise.ufp.org>
References: <20110914140513.613A5998@resin15.mta.everyone.net>
 <4E711B89.3080203@bowenvale.co.nz>
 <20110914214651.GA64938@ussenterprise.ufp.org>
Message-ID: <4E713409.3080808@freedomnet.co.nz>

On 9/14/11 2:46 PM, Leo Bicknell wrote:
> In a message written on Thu, Sep 15, 2011 at 09:24:25AM +1200, Don Gould wrote:
>> How many of you have sat and thought about the merit of this web site?
> Ok, I'll take a swing at your list...
>
>> * Does Juniper break promises?
> Yes.
>
>> * Does Cisco break them?
> Yes.
>
>> * What bad things and experiences have you had with Cisco, Juniper?
> It might take me several days, and many pages to compile that list.
>
>> * What is the best technology for each company?
> Cisco: The AGS+ was ahead of its time.
> Jiniper: The Olive is quite nifty.
>
>> * Did you know that Cisco has a 100Gb solution?
> Yes, but I can't afford it.
>
> Now, with that out of the way, how much does everyone else hate even the
> thought of NAT444?
>
> :) :) :)
>

Just the thought of NAT444 makes my stomach turn.




From MGauvin at dryden.ca  Wed Sep 14 18:35:28 2011
From: MGauvin at dryden.ca (Mark Gauvin)
Date: Wed, 14 Sep 2011 18:35:28 -0500
Subject: ouch..
In-Reply-To: <4E713409.3080808@freedomnet.co.nz>
References: <20110914140513.613A5998@resin15.mta.everyone.net>
 <4E711B89.3080203@bowenvale.co.nz>
 <20110914214651.GA64938@ussenterprise.ufp.org>
 <4E713409.3080808@freedomnet.co.nz>
Message-ID: <D6189AA0-DCE7-4F0A-A272-C525A8C59140@dryden.ca>

Nat444 or frontal labotomy hmm let's see at least with the second I  
would still be able to make a living as a micro soft network admin;)

Sent from my iPhone

On 2011-09-14, at 6:07 PM, "James Jones" <james at freedomnet.co.nz> wrote:

> On 9/14/11 2:46 PM, Leo Bicknell wrote:
>> In a message written on Thu, Sep 15, 2011 at 09:24:25AM +1200, Don  
>> Gould wrote:
>>> How many of you have sat and thought about the merit of this web  
>>> site?
>> Ok, I'll take a swing at your list...
>>
>>> * Does Juniper break promises?
>> Yes.
>>
>>> * Does Cisco break them?
>> Yes.
>>
>>> * What bad things and experiences have you had with Cisco, Juniper?
>> It might take me several days, and many pages to compile that list.
>>
>>> * What is the best technology for each company?
>> Cisco: The AGS+ was ahead of its time.
>> Jiniper: The Olive is quite nifty.
>>
>>> * Did you know that Cisco has a 100Gb solution?
>> Yes, but I can't afford it.
>>
>> Now, with that out of the way, how much does everyone else hate  
>> even the
>> thought of NAT444?
>>
>> :) :) :)
>>
>
> Just the thought of NAT444 makes my stomach turn.
>
>
>


From nanog at deman.com  Thu Sep 15 01:15:08 2011
From: nanog at deman.com (Michael DeMan)
Date: Wed, 14 Sep 2011 23:15:08 -0700
Subject: ouch..
In-Reply-To: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
Message-ID: <24CD5C8F-604D-4929-9780-445526E9B19B@deman.com>

Good grief.

Tell me ANY vendor who has not had this happen?

| QUALIFIER | - A vendor who has been in business at least ten years please.

- Mike DeMan

On Sep 14, 2011, at 3:42 AM, Martin Hepworth wrote:

> http://www.overpromisesunderdelivers.net/
> 
> 
> -- 
> Martin Hepworth
> Oxford, UK



From leigh.porter at ukbroadband.com  Thu Sep 15 01:36:42 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 15 Sep 2011 06:36:42 +0000
Subject: ouch..
In-Reply-To: <D6189AA0-DCE7-4F0A-A272-C525A8C59140@dryden.ca>
References: <20110914140513.613A5998@resin15.mta.everyone.net>
 <4E711B89.3080203@bowenvale.co.nz>
 <20110914214651.GA64938@ussenterprise.ufp.org>
 <4E713409.3080808@freedomnet.co.nz>,
 <D6189AA0-DCE7-4F0A-A272-C525A8C59140@dryden.ca>
Message-ID: <DA37A3E7-0FD3-4D02-941C-519AADBA6836@ukbroadband.com>

I'm looking forward to the awful experience of NAT444 promoting IPv6.


-- 
Leigh Porter


On 15 Sep 2011, at 00:37, "Mark Gauvin" <MGauvin at dryden.ca> wrote:

> Nat444 or frontal labotomy hmm let's see at least with the second I  
> would still be able to make a living as a micro soft network admin;)
> 
> Sent from my iPhone
> 
> On 2011-09-14, at 6:07 PM, "James Jones" <james at freedomnet.co.nz> wrote:
> 
>> On 9/14/11 2:46 PM, Leo Bicknell wrote:
>>> In a message written on Thu, Sep 15, 2011 at 09:24:25AM +1200, Don  
>>> Gould wrote:
>>>> How many of you have sat and thought about the merit of this web  
>>>> site?
>>> Ok, I'll take a swing at your list...
>>> 
>>>> * Does Juniper break promises?
>>> Yes.
>>> 
>>>> * Does Cisco break them?
>>> Yes.
>>> 
>>>> * What bad things and experiences have you had with Cisco, Juniper?
>>> It might take me several days, and many pages to compile that list.
>>> 
>>>> * What is the best technology for each company?
>>> Cisco: The AGS+ was ahead of its time.
>>> Jiniper: The Olive is quite nifty.
>>> 
>>>> * Did you know that Cisco has a 100Gb solution?
>>> Yes, but I can't afford it.
>>> 
>>> Now, with that out of the way, how much does everyone else hate  
>>> even the
>>> thought of NAT444?
>>> 
>>> :) :) :)
>>> 
>> 
>> Just the thought of NAT444 makes my stomach turn.
>> 
>> 
>> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From Valdis.Kletnieks at vt.edu  Thu Sep 15 01:46:24 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 15 Sep 2011 02:46:24 -0400
Subject: ouch..
In-Reply-To: Your message of "Thu, 15 Sep 2011 06:36:42 -0000."
 <DA37A3E7-0FD3-4D02-941C-519AADBA6836@ukbroadband.com>
References: <20110914140513.613A5998@resin15.mta.everyone.net>
 <4E711B89.3080203@bowenvale.co.nz>
 <20110914214651.GA64938@ussenterprise.ufp.org>
 <4E713409.3080808@freedomnet.co.nz>
 <D6189AA0-DCE7-4F0A-A272-C525A8C59140@dryden.ca>
 <DA37A3E7-0FD3-4D02-941C-519AADBA6836@ukbroadband.com>
Message-ID: <34855.1316069184@turing-police.cc.vt.edu>

On Thu, 15 Sep 2011 06:36:42 -0000, Leigh Porter said:
> I'm looking forward to the awful experience of NAT444 promoting IPv6.

In NAT444, no one can hear you scream....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110915/c3eda28e/attachment-0001.bin>

From leigh.porter at ukbroadband.com  Thu Sep 15 02:20:22 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 15 Sep 2011 07:20:22 +0000
Subject: ouch..
In-Reply-To: <34855.1316069184@turing-police.cc.vt.edu>
References: <20110914140513.613A5998@resin15.mta.everyone.net>
 <4E711B89.3080203@bowenvale.co.nz>
 <20110914214651.GA64938@ussenterprise.ufp.org>
 <4E713409.3080808@freedomnet.co.nz>
 <D6189AA0-DCE7-4F0A-A272-C525A8C59140@dryden.ca>
 <DA37A3E7-0FD3-4D02-941C-519AADBA6836@ukbroadband.com>,
 <34855.1316069184@turing-police.cc.vt.edu>
Message-ID: <5B2F69E5-5A91-40C0-BC4B-410C9E56160E@ukbroadband.com>


That will either be because you exceeded your port count or the RTSP ALG is broken.

-- 
Leigh Porter


On 15 Sep 2011, at 07:48, "Valdis.Kletnieks at vt.edu" <Valdis.Kletnieks at vt.edu> wrote:

> On Thu, 15 Sep 2011 06:36:42 -0000, Leigh Porter said:
>> I'm looking forward to the awful experience of NAT444 promoting IPv6.
> 
> In NAT444, no one can hear you scream....

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From leschnik at gmail.com  Thu Sep 15 02:51:07 2011
From: leschnik at gmail.com (Jason Leschnik)
Date: Thu, 15 Sep 2011 17:51:07 +1000
Subject: ouch..
In-Reply-To: <CADE4tYWnFYoXuC7h3jWAprbW8aYjgY2Lfcv+tJc9+ZBThgsRQA@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com>
 <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
 <4E70CFF9.8050505@otd.com>
 <CADE4tYWnFYoXuC7h3jWAprbW8aYjgY2Lfcv+tJc9+ZBThgsRQA@mail.gmail.com>
Message-ID: <CAN1XHtdHV5p7bK-na3G9iPCPL5hHXeVkf0sRcW=R9Ukjjqb91A@mail.gmail.com>

>>
> Juniper: Who needs to waste time with pathetic marketing videos when you're
> gear just works.
>

If this is really from Cisco, it must put a smile on the face of
Juniper to know their competitor of 10x the revenue is watching their
moves so closely... Typically in the Mac vs. PC adds you see the non
established player (apple) making pokes at the established.

-- 
Regards,
Jason Leschnik.

Mob. 0432 35 4224
Uni mail. jml974 at uow.edu.au


From swmike at swm.pp.se  Thu Sep 15 05:17:43 2011
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 15 Sep 2011 12:17:43 +0200 (CEST)
Subject: ouch..
In-Reply-To: <CAN1XHtdHV5p7bK-na3G9iPCPL5hHXeVkf0sRcW=R9Ukjjqb91A@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com> <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
 <4E70CFF9.8050505@otd.com>
 <CADE4tYWnFYoXuC7h3jWAprbW8aYjgY2Lfcv+tJc9+ZBThgsRQA@mail.gmail.com>
 <CAN1XHtdHV5p7bK-na3G9iPCPL5hHXeVkf0sRcW=R9Ukjjqb91A@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1109151217030.13829@uplift.swm.pp.se>

On Thu, 15 Sep 2011, Jason Leschnik wrote:

> If this is really from Cisco, it must put a smile on the face of Juniper 
> to know their competitor of 10x the revenue is watching their moves so 
> closely... Typically in the Mac vs. PC adds you see the non established 
> player (apple) making pokes at the established.

I asked our account manager. I got the following link:

<http://blogs.cisco.com/news/trust-relationships-and-reputation-how-cisco-differs-from-the-competition/>

Yes, it's indeed from Cisco.

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


From owen at delong.com  Thu Sep 15 06:44:01 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 15 Sep 2011 04:44:01 -0700
Subject: ouch..
In-Reply-To: <CAN1XHtdHV5p7bK-na3G9iPCPL5hHXeVkf0sRcW=R9Ukjjqb91A@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com> <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
 <4E70CFF9.8050505@otd.com>
 <CADE4tYWnFYoXuC7h3jWAprbW8aYjgY2Lfcv+tJc9+ZBThgsRQA@mail.gmail.com>
 <CAN1XHtdHV5p7bK-na3G9iPCPL5hHXeVkf0sRcW=R9Ukjjqb91A@mail.gmail.com>
Message-ID: <7098B053-6896-4D8A-8715-1FDE0802327C@delong.com>


On Sep 15, 2011, at 12:51 AM, Jason Leschnik wrote:

>>> 
>> Juniper: Who needs to waste time with pathetic marketing videos when you're
>> gear just works.
>> 
> 
> If this is really from Cisco, it must put a smile on the face of
> Juniper to know their competitor of 10x the revenue is watching their
> moves so closely... Typically in the Mac vs. PC adds you see the non
> established player (apple) making pokes at the established.

OTOH, you do see Micr0$0ft doing everything they can to imitate Apple.

I was at Valley Fair mall the other day. Micr0$0ft is apparently building a
new store directly across from the Apple store there. They have gone to
the trouble and expense of covering the "under construction" paneling
with a full-color mural touting this fact, including employees dressed in
brightly colored Apple-store-like T-shirts sporting name badges identical
to those worn by the employees in the Apple store.

I wonder if Micr0$0ft is going to develop a Zune cash register, too?

Owen



From rps at maine.edu  Thu Sep 15 08:05:48 2011
From: rps at maine.edu (Ray Soucy)
Date: Thu, 15 Sep 2011 09:05:48 -0400
Subject: vyatta for bgp
In-Reply-To: <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
Message-ID: <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>

Is Vyatta really not suited for the task?

I keep checking up on it and holding off looking into it as they don't
support multicast yet.

Modern commodity sever hardware these days often out-powers big iron
enough to make up for not using ASICs, though, at least on the lower
end of the spectrum.

Does anyone have any more details on Vyatta not scaling?  Were you
trying to run it as a VM?  What were you using for NICs? etc.

The hardware matters.  Saying Vyatta doesn't cut it could mean anything...

On Tue, Sep 13, 2011 at 7:36 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
> On Sep 14, 2011, at 5:54 AM, Deepak Jain wrote:
>
>> Some enterprises get MPLS L3 VPN service from their providers, and need boxes that can route packets to it and speak BGP to inject their routes. ?They are not, per se, connected to the Internet, and thus won't be "zorched", at least in the sense you are using it.
>
> Hence 'public-facing'.
>
> ;>
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
> ? ? ? ? ? ? ? ?The basis of optimism is sheer terror.
>
> ? ? ? ? ? ? ? ? ? ? ? ? ?-- Oscar Wilde
>
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From nanog at jima.tk  Thu Sep 15 08:32:21 2011
From: nanog at jima.tk (Jima)
Date: Thu, 15 Sep 2011 07:32:21 -0600 (MDT)
Subject: ouch..
In-Reply-To: <7098B053-6896-4D8A-8715-1FDE0802327C@delong.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com>
 <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
 <4E70CFF9.8050505@otd.com>
 <CADE4tYWnFYoXuC7h3jWAprbW8aYjgY2Lfcv+tJc9+ZBThgsRQA@mail.gmail.com>
 <CAN1XHtdHV5p7bK-na3G9iPCPL5hHXeVkf0sRcW=R9Ukjjqb91A@mail.gmail.com>
 <7098B053-6896-4D8A-8715-1FDE0802327C@delong.com>
Message-ID: <60920.2001:470:e030:d000:28a7:bdff:fe11:8542.1316093541.squirrel@laughton.us>

On Thu, 15 Sep 2011, Owen DeLong wrote:
> On Sep 15, 2011, at 12:51 AM, Jason Leschnik wrote:
>> If this is really from Cisco, it must put a smile on the face of
>> Juniper to know their competitor of 10x the revenue is watching their
>> moves so closely... Typically in the Mac vs. PC adds you see the non
>> established player (apple) making pokes at the established.
>
> OTOH, you do see Micr0$0ft doing everything they can to imitate Apple.
>
> I was at Valley Fair mall the other day. Micr0$0ft is apparently building
> a
> new store directly across from the Apple store there.

 It's funny; they did the exact same thing at Mall of America maybe a year
ago.  I guess your report confirms it was a strategy, rather than a
really absurd coincidence.

     Jima



From ahebert at pubnix.net  Thu Sep 15 08:51:00 2011
From: ahebert at pubnix.net (Alain Hebert)
Date: Thu, 15 Sep 2011 09:51:00 -0400
Subject: vyatta for bgp
In-Reply-To: <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
 <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
Message-ID: <4E7202C4.9050502@pubnix.net>

      Hi,

     As usual this end-up in what people prefer.

     Vyatta is as good as the hardware it runs on, the backend they use 
and the people configuring/maintaining it.

     The nature of ASIC make it more reliable than a multi-purpose 
device (aka server) running an OS written for it.

     It end up being a choice between risk and cost and being that you 
can get your hand on second hand iron for cheap these days...

     Why risk it.

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


On 09/15/11 09:05, Ray Soucy wrote:
> Is Vyatta really not suited for the task?
>
> I keep checking up on it and holding off looking into it as they don't
> support multicast yet.
>
> Modern commodity sever hardware these days often out-powers big iron
> enough to make up for not using ASICs, though, at least on the lower
> end of the spectrum.
>
> Does anyone have any more details on Vyatta not scaling?  Were you
> trying to run it as a VM?  What were you using for NICs? etc.
>
> The hardware matters.  Saying Vyatta doesn't cut it could mean anything...
>
> On Tue, Sep 13, 2011 at 7:36 PM, Dobbins, Roland<rdobbins at arbor.net>  wrote:
>> On Sep 14, 2011, at 5:54 AM, Deepak Jain wrote:
>>
>>> Some enterprises get MPLS L3 VPN service from their providers, and need boxes that can route packets to it and speak BGP to inject their routes.  They are not, per se, connected to the Internet, and thus won't be "zorched", at least in the sense you are using it.
>> Hence 'public-facing'.
>>
>> ;>
>>
>> -----------------------------------------------------------------------
>> Roland Dobbins<rdobbins at arbor.net>  //<http://www.arbornetworks.com>
>>
>>                 The basis of optimism is sheer terror.
>>
>>                           -- Oscar Wilde
>>
>>
>>
>
>


From leschnik at gmail.com  Thu Sep 15 08:58:48 2011
From: leschnik at gmail.com (Jason Leschnik)
Date: Thu, 15 Sep 2011 23:58:48 +1000
Subject: vyatta for bgp
In-Reply-To: <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
 <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
Message-ID: <CAN1XHtfrVk28=zoDOxkZLZ14AgAP1Ax+hwr6k_=uq8B+OoRGTw@mail.gmail.com>

Ray

Download the Podcast "The Packet Pushers - Show 31" they talk a little
about this topic... If nothing else it's a great listen

Cheers!

On Thu, Sep 15, 2011 at 11:05 PM, Ray Soucy <rps at maine.edu> wrote:
> Is Vyatta really not suited for the task?
>
> I keep checking up on it and holding off looking into it as they don't
> support multicast yet.
>
> Modern commodity sever hardware these days often out-powers big iron
> enough to make up for not using ASICs, though, at least on the lower
> end of the spectrum.
>
> Does anyone have any more details on Vyatta not scaling? ?Were you
> trying to run it as a VM? ?What were you using for NICs? etc.
>
> The hardware matters. ?Saying Vyatta doesn't cut it could mean anything...
>

-- 
Regards,
Jason Leschnik.

Mob. 0432 35 4224
Uni mail. jml974 at uow.edu.au


From tayeb.meftah at gmail.com  Thu Sep 15 09:02:31 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 15 Sep 2011 16:02:31 +0200
Subject: Open Letters to Sixxs
Message-ID: <391A8D586FE94AB08C5E66B712BA4378@work>

Hello People

i have one question:

why SIXXS is very strict like that ?

forcing a special address format is a idiotic work

everyone have a format of address

everyone have his way of saying address

every country have there language.

there's bilion of address definition at this time.

signed up for Sixxs for 2 times and resulted in a refuse because of bad address

Sixxs, please would you revise your requiremant ?

Emailed you for one month and still have no reply ?

did you has a coppy of my passport ?

did you saw my identity card ?

have you called me ?

anyway, i have realy not seen any Strict service like you, SIXXS.

i can evean pay for your service, if you wish.

just fix your policy and by nice with people like everyone is.

Thank you.

    Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213660347746


__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com


From tayeb.meftah at gmail.com  Thu Sep 15 09:12:14 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 15 Sep 2011 16:12:14 +0200
Subject: Open Letters to Sixxs
References: <391A8D586FE94AB08C5E66B712BA4378@work>
 <7DC97F2A-5733-4BDF-892C-8E63F617E41E@voiceworks.nl>
Message-ID: <179E400888B9449E9393556CC09358CC@work>

ok, that's a positive answer.
but let me ask you a question:
do HE.NET peer with cogent? level3?
that the way i'm looking arround SIXXS and they look like a IPV6 POLICE !

  ----- Original Message ----- 
  From: Arjan Van Der Oest 
  To: Meftah Tayeb 
  Cc: ipv6-ops at lists.cluenet.de ; nanog at nanog.org 
  Sent: Thursday, September 15, 2011 4:20 PM
  Subject: Re: Open Letters to Sixxs


  On 15Sep, 2011, at 16:02 , Meftah Tayeb wrote:
    Hello People

    i have one question:

    why SIXXS is very strict like that ?





  Why sent this to this list. Consider using another tunnelbroker if you're not satisfied with Sixxs. I can recommend Hurricane, www.tunnelbroker.com (this is, by no means, a judgement on Sixxs and their services).

  -- 
  Met vriendelijke groet,

  Arjan van der Oest
  Senior Network Engineer / Security Officer

  Voiceworks BV - Editiestraat 29 - 1321 NG Almere



  __________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________

  Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

  http://www.eset.com



__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com


From mike at mikejones.in  Thu Sep 15 09:58:38 2011
From: mike at mikejones.in (Mike Jones)
Date: Thu, 15 Sep 2011 15:58:38 +0100
Subject: Open Letters to Sixxs
In-Reply-To: <179E400888B9449E9393556CC09358CC@work>
References: <391A8D586FE94AB08C5E66B712BA4378@work>
 <7DC97F2A-5733-4BDF-892C-8E63F617E41E@voiceworks.nl>
 <179E400888B9449E9393556CC09358CC@work>
Message-ID: <CAAAas8GZuN2Hht8VSKTVRCeZ2pTT6sHwqhu+Xy0JgJ1LfSWGXA@mail.gmail.com>

On 15 September 2011 15:12, Meftah Tayeb <tayeb.meftah at gmail.com> wrote:
> ok, that's a positive answer.
> but let me ask you a question:
> do HE.NET peer with cogent? level3?

  4   189 ms   134 ms    99 ms  10gigabitethernet7-4.core1.nyc4.he.net
[2001:470:0:3e::1]
  5   131 ms   152 ms   111 ms  2001:470:0:202::2
  6   144 ms   147 ms   238 ms  2001:1900:19:7::4
  7   132 ms   241 ms   143 ms  vl-4060.car2.NewYork2.Level3.net
[2001:1900:4:1::fe]
[Jitter is my cable connection, not reflective of the performance of
HEs network]

As for cogent - Does anyone really care? this is only a problem for
reaching a single homed network behind cogent, and anyone running such
a network knows that their IPv6 connectivity doesn't work properly
anyway and they are the broken ones.

Whatever you think of the issues surrounding the peering dispute (I am
sure at least comcast agree with cogent that a Tier 1 network should
pay what is essentially a Tier 2 network for peering!), the fact
remains that HE did get there first with their defacto tier 1 status,
and for the time being at least "working IPv6" is realistically
"working IPv6 connection to HE and peers".

The more users/content that is behind HE and peers that is not
reachable from cogent the better, as it puts more pressure on them to
start behaving themselves and peering properly like everyone else.

- Mike


From tayeb.meftah at gmail.com  Thu Sep 15 10:01:33 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 15 Sep 2011 17:01:33 +0200
Subject: Open Letters to Sixxs
References: <391A8D586FE94AB08C5E66B712BA4378@work>
 <7DC97F2A-5733-4BDF-892C-8E63F617E41E@voiceworks.nl>
 <179E400888B9449E9393556CC09358CC@work>
 <CAAAas8GZuN2Hht8VSKTVRCeZ2pTT6sHwqhu+Xy0JgJ1LfSWGXA@mail.gmail.com>
Message-ID: <4299CDD40A66466FADF8854A9765F913@work>

Good thinking mike
i do have a VoIp carrier single homed with Cogent.
any solution?
(*NO IPV4!*)

----- Original Message ----- 
From: "Mike Jones" <mike at mikejones.in>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: "Arjan Van Der Oest" <Arjan at voiceworks.nl>; <nanog at nanog.org>; 
<ipv6-ops at lists.cluenet.de>
Sent: Thursday, September 15, 2011 4:58 PM
Subject: Re: Open Letters to Sixxs


> On 15 September 2011 15:12, Meftah Tayeb <tayeb.meftah at gmail.com> wrote:
>> ok, that's a positive answer.
>> but let me ask you a question:
>> do HE.NET peer with cogent? level3?
>
>  4   189 ms   134 ms    99 ms  10gigabitethernet7-4.core1.nyc4.he.net
> [2001:470:0:3e::1]
>  5   131 ms   152 ms   111 ms  2001:470:0:202::2
>  6   144 ms   147 ms   238 ms  2001:1900:19:7::4
>  7   132 ms   241 ms   143 ms  vl-4060.car2.NewYork2.Level3.net
> [2001:1900:4:1::fe]
> [Jitter is my cable connection, not reflective of the performance of
> HEs network]
>
> As for cogent - Does anyone really care? this is only a problem for
> reaching a single homed network behind cogent, and anyone running such
> a network knows that their IPv6 connectivity doesn't work properly
> anyway and they are the broken ones.
>
> Whatever you think of the issues surrounding the peering dispute (I am
> sure at least comcast agree with cogent that a Tier 1 network should
> pay what is essentially a Tier 2 network for peering!), the fact
> remains that HE did get there first with their defacto tier 1 status,
> and for the time being at least "working IPv6" is realistically
> "working IPv6 connection to HE and peers".
>
> The more users/content that is behind HE and peers that is not
> reachable from cogent the better, as it puts more pressure on them to
> start behaving themselves and peering properly like everyone else.
>
> - Mike
>
>
> __________ Information provenant d'ESET NOD32 Antivirus, version de la 
> base des signatures de virus 6465 (20110915) __________
>
> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> 


__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com





From tayeb.meftah at gmail.com  Thu Sep 15 10:19:45 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 15 Sep 2011 17:19:45 +0200
Subject: Open Letters to Sixxs
References: <391A8D586FE94AB08C5E66B712BA4378@work>
 <CAEnbrFmfTOtC2t50=Wxvv=ya-_v3Aydp4iXBaLxBo0+rkzwtFQ@mail.gmail.com>
Message-ID: <90DCEEBF4DC44F5BB9BCBA64FB66AA36@work>

Pim Van,
i am just looking for a alternative way.
i don't need this stupid SixXs at all anymore.
also, Pim, are you Pim for Multicast? no IGMP? :D
:)
Thank you

----- Original Message ----- 
From: "Pim van Pelt" <pim at ipng.nl>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: <ipv6-ops at lists.cluenet.de>; <nanog at nanog.org>
Sent: Thursday, September 15, 2011 5:28 PM
Subject: Re: Open Letters to Sixxs


> Hoi,
>
> Meftah perhaps you mailed the wrong people -- you seem to be
> specifically addressing SixXS, but you mailed nanog at nanog.org and
> ipv6-ops at lists.cluenet.de, both of which may not be able to
> authoritatively answer your questions.
>
>
> On Thu, Sep 15, 2011 at 4:02 PM, Meftah Tayeb <tayeb.meftah at gmail.com> 
> wrote:
>> why SIXXS is very strict like that ?
> I suppose it's up to SixXS to define their policy (one account per
> person comes to mind *) and revise it if they see a need. They are
> free to accept or reject any user and I do not believe they have an
> obligation to serve any given user (ie access is a privilege not a
> right), and I think they have a right to ask for information just as
> much as users have a right to not use their service if they believe
> the amount of information SixXS wants to know about them and their
> intended use is too much. In general I think they are rather
> transparent about rejection reasons, in your case likely because you
> neglected to heed the FAQ item on one account per person.
>
> I'm not sure bringing this up in the scope of nanog or ipv6-ops is
> productive. It's not clear to me, except for your plethora of
> questions, what you are trying to accomplish.
>
> I'm sorry you feel that SixXS is not the right place for you. Luckily
> there's plenty of choice in high quality tunnelbrokers, as others in
> this thread have pointed out.
>
> groet,
> Pim
>
> *) http://www.sixxs.net/faq/account/?faq=oneaccount
> -- 
> Pim van Pelt <pim at ipng.nl>
> PBVP1-RIPE - http://www.ipng.nl/
>
>
> __________ Information provenant d'ESET NOD32 Antivirus, version de la 
> base des signatures de virus 6465 (20110915) __________
>
> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> 


__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com





From trelane at trelane.net  Thu Sep 15 11:10:32 2011
From: trelane at trelane.net (Andrew Kirch)
Date: Thu, 15 Sep 2011 12:10:32 -0400
Subject: Open Letters to Sixxs
In-Reply-To: <391A8D586FE94AB08C5E66B712BA4378@work>
References: <391A8D586FE94AB08C5E66B712BA4378@work>
Message-ID: <4E722378.1070804@trelane.net>

On 9/15/2011 10:02 AM, Meftah Tayeb wrote:
> Hello People
>
> i have one question:
>
> why SIXXS is very strict like that ?
>

I concur in all respects with your assessment of SIXXS.  Being a
volunteer does not give you carte-blanche to act like the rear end of a
horse.  I don't care if your service is free, your behavior is slowing,
not speeding the adoption of IPv6.  Grow up.

Andrew


From brandon at rd.bbc.co.uk  Thu Sep 15 11:14:00 2011
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Thu, 15 Sep 2011 17:14:00 +0100 (BST)
Subject: Open Letters to Sixxs
Message-ID: <201109151614.RAA13930@sunf10.rd.bbc.co.uk>

> I concur in all respects with your assessment of SIXXS.  Being a
> volunteer does not give you carte-blanche to act like the rear end of a
> horse.

Actually it does, it's theirs to do as they wish. Anyone else is
free to make what they may consider to be a better service.

> I don't care if your service is free, your behavior is slowing,
> not speeding the adoption of IPv6.  Grow up.

Tunnels are not the future, it's probably just as well
they make it hard to create more.

IPv6, do it properly, do it now

brandon


From rps at maine.edu  Thu Sep 15 11:32:20 2011
From: rps at maine.edu (Ray Soucy)
Date: Thu, 15 Sep 2011 12:32:20 -0400
Subject: vyatta for bgp
In-Reply-To: <CAN1XHtfrVk28=zoDOxkZLZ14AgAP1Ax+hwr6k_=uq8B+OoRGTw@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
 <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
 <CAN1XHtfrVk28=zoDOxkZLZ14AgAP1Ax+hwr6k_=uq8B+OoRGTw@mail.gmail.com>
Message-ID: <CALFTrnMKqpJvq+U0E9n5BQnmx8vNAM6aDuPC0f8TwsedM6DDhA@mail.gmail.com>

Thanks for the tip, first time I hear this podcast.

On Thu, Sep 15, 2011 at 9:58 AM, Jason Leschnik <leschnik at gmail.com> wrote:
> Ray
>
> Download the Podcast "The Packet Pushers - Show 31" they talk a little
> about this topic... If nothing else it's a great listen
>
> Cheers!
>
> On Thu, Sep 15, 2011 at 11:05 PM, Ray Soucy <rps at maine.edu> wrote:
>> Is Vyatta really not suited for the task?
>>
>> I keep checking up on it and holding off looking into it as they don't
>> support multicast yet.
>>
>> Modern commodity sever hardware these days often out-powers big iron
>> enough to make up for not using ASICs, though, at least on the lower
>> end of the spectrum.
>>
>> Does anyone have any more details on Vyatta not scaling? ?Were you
>> trying to run it as a VM? ?What were you using for NICs? etc.
>>
>> The hardware matters. ?Saying Vyatta doesn't cut it could mean anything...
>>
>
> --
> Regards,
> Jason Leschnik.
>
> Mob. 0432 35 4224
> Uni mail. jml974 at uow.edu.au
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From tayeb.meftah at gmail.com  Thu Sep 15 11:24:27 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 15 Sep 2011 18:24:27 +0200
Subject: IPV6 over a PPTP Link
Message-ID: <C249D3C3D3E6402BAAEBD07D90BF0E90@work>

Hello,
can i ofer ipv6 addresses through a PPTP connection using cisco ?
if yes, how please ?
Thank you
    Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213660347746


__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com


From jared at puck.nether.net  Thu Sep 15 11:36:42 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 15 Sep 2011 12:36:42 -0400
Subject: IPV6 over a PPTP Link
In-Reply-To: <C249D3C3D3E6402BAAEBD07D90BF0E90@work>
References: <C249D3C3D3E6402BAAEBD07D90BF0E90@work>
Message-ID: <63748057-899F-4325-B25B-71A12A69D294@puck.nether.net>

I did this in the past without troubles.

http://www.gossamer-threads.com/lists/nsp/ipv6/27525

Should give you some help.

- Jared

-- snip --
! 
vpdn enable 
! 
vpdn-group 1 
! Default PPTP VPDN group 
accept-dialin 
protocol pptp 
virtual-template 1 
! 
interface Virtual-Template1 
ip unnumbered FastEthernet2/0 
ipv6 unnumbered FastEthernet2/0 
ipv6 enable 
ipv6 nd reachable-time 30 
no ipv6 nd suppress-ra 
peer default ip address pool DIAL-IN 
peer default ipv6 pool DIAL-IN6 
ppp encrypt mppe 128 
ppp authentication ms-chap 
ppp ipcp dns 129.250.35.250 129.250.35.251 
! 
ip local pool DIAL-IN 10.10.15.72 10.10.15.79 
ipv6 local pool DIAL-IN6 3ffe:3ffe:0:7080::/62 64
-- snip --

On Sep 15, 2011, at 12:24 PM, Meftah Tayeb wrote:

> Hello,
> can i ofer ipv6 addresses through a PPTP connection using cisco ?
> if yes, how please ?
> Thank you
>    Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/ 
> phone: +21321656139
> Mobile: +213660347746
> 
> 
> __________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________
> 
> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 



From tayeb.meftah at gmail.com  Thu Sep 15 12:38:14 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 15 Sep 2011 19:38:14 +0200
Subject: IPV6 over a PPTP Link
References: <C249D3C3D3E6402BAAEBD07D90BF0E90@work>
 <63748057-899F-4325-B25B-71A12A69D294@puck.nether.net>
Message-ID: <3210657A42284615809374B6190B8B01@work>

ok, that's using RA
but i want to do a routed interface
so give the PPTP host a static ip and route through it
thank you

----- Original Message ----- 
From: "Jared Mauch" <jared at puck.nether.net>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: <nanog at nanog.org>
Sent: Thursday, September 15, 2011 6:36 PM
Subject: Re: IPV6 over a PPTP Link


I did this in the past without troubles.

http://www.gossamer-threads.com/lists/nsp/ipv6/27525

Should give you some help.

- Jared

-- snip --
!
vpdn enable
!
vpdn-group 1
! Default PPTP VPDN group
accept-dialin
protocol pptp
virtual-template 1
!
interface Virtual-Template1
ip unnumbered FastEthernet2/0
ipv6 unnumbered FastEthernet2/0
ipv6 enable
ipv6 nd reachable-time 30
no ipv6 nd suppress-ra
peer default ip address pool DIAL-IN
peer default ipv6 pool DIAL-IN6
ppp encrypt mppe 128
ppp authentication ms-chap
ppp ipcp dns 129.250.35.250 129.250.35.251
!
ip local pool DIAL-IN 10.10.15.72 10.10.15.79
ipv6 local pool DIAL-IN6 3ffe:3ffe:0:7080::/62 64
-- snip --

On Sep 15, 2011, at 12:24 PM, Meftah Tayeb wrote:

> Hello,
> can i ofer ipv6 addresses through a PPTP connection using cisco ?
> if yes, how please ?
> Thank you
>    Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/
> phone: +21321656139
> Mobile: +213660347746
>
>
> __________ Information provenant d'ESET NOD32 Antivirus, version de la 
> base des signatures de virus 6465 (20110915) __________
>
> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
>
> http://www.eset.com
>



__________ Information provenant d'ESET NOD32 Antivirus, version de la base 
des signatures de virus 6465 (20110915) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com




__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com





From cmadams at hiwaay.net  Thu Sep 15 13:07:02 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 15 Sep 2011 13:07:02 -0500
Subject: ouch..
In-Reply-To: <60920.2001:470:e030:d000:28a7:bdff:fe11:8542.1316093541.squirrel@laughton.us>
References: <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
 <4E70CFF9.8050505@otd.com>
 <CADE4tYWnFYoXuC7h3jWAprbW8aYjgY2Lfcv+tJc9+ZBThgsRQA@mail.gmail.com>
 <CAN1XHtdHV5p7bK-na3G9iPCPL5hHXeVkf0sRcW=R9Ukjjqb91A@mail.gmail.com>
 <7098B053-6896-4D8A-8715-1FDE0802327C@delong.com>
 <60920.2001:470:e030:d000:28a7:bdff:fe11:8542.1316093541.squirrel@laughton.us>
Message-ID: <20110915180701.GB31116@hiwaay.net>

Once upon a time, Jima <nanog at jima.tk> said:
> On Thu, 15 Sep 2011, Owen DeLong wrote:
> > I was at Valley Fair mall the other day. Micr0$0ft is apparently building
> > a
> > new store directly across from the Apple store there.
> 
>  It's funny; they did the exact same thing at Mall of America maybe a year
> ago.  I guess your report confirms it was a strategy, rather than a
> really absurd coincidence.

They could be following the (possibly urban legend) Burger King model.
Supposedly, McDonald's would spend a bunch of time and money doing
market research, surveys, and such before placing a new restaurant.
Burger King would wait for McDonald's to spend the time and money, and
then open a new restaurant across the street.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From jra at baylink.com  Thu Sep 15 13:09:06 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 15 Sep 2011 14:09:06 -0400 (EDT)
Subject: ouch..
In-Reply-To: <CAN1XHtdHV5p7bK-na3G9iPCPL5hHXeVkf0sRcW=R9Ukjjqb91A@mail.gmail.com>
Message-ID: <9363407.1973.1316110146435.JavaMail.root@benjamin.baylink.com>

---- Original Message -----
> From: "Jason Leschnik" <leschnik at gmail.com>

> If this is really from Cisco, it must put a smile on the face of
> Juniper to know their competitor of 10x the revenue is watching their
> moves so closely... Typically in the Mac vs. PC adds you see the non
> established player (apple) making pokes at the established.

And we all remember how that worked out *last* time:

  http://www.macmothership.com/gallery/newads2/seriouslyIBM_l.jpg

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      http://photo.imageinc.us             +1 727 647 1274


From nanog at jima.tk  Thu Sep 15 13:23:07 2011
From: nanog at jima.tk (Jima)
Date: Thu, 15 Sep 2011 12:23:07 -0600 (MDT)
Subject: ouch..
In-Reply-To: <20110915180701.GB31116@hiwaay.net>
References: <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
 <4E70CFF9.8050505@otd.com>
 <CADE4tYWnFYoXuC7h3jWAprbW8aYjgY2Lfcv+tJc9+ZBThgsRQA@mail.gmail.com>
 <CAN1XHtdHV5p7bK-na3G9iPCPL5hHXeVkf0sRcW=R9Ukjjqb91A@mail.gmail.com>
 <7098B053-6896-4D8A-8715-1FDE0802327C@delong.com>
 <60920.2001:470:e030:d000:28a7:bdff:fe11:8542.1316093541.squirrel@laughton.us>
 <20110915180701.GB31116@hiwaay.net>
Message-ID: <49912.2001:470:e030:d000:28a7:bdff:fe11:8542.1316110987.squirrel@laughton.us>

> Once upon a time, Jima <nanog at jima.tk> said:
>> On Thu, 15 Sep 2011, Owen DeLong wrote:
>> > I was at Valley Fair mall the other day. Micr0$0ft is apparently
>> building
>> > a
>> > new store directly across from the Apple store there.
>>
>>  It's funny; they did the exact same thing at Mall of America maybe a
>> year
>> ago.  I guess your report confirms it was a strategy, rather than a
>> really absurd coincidence.
>
> They could be following the (possibly urban legend) Burger King model.
> Supposedly, McDonald's would spend a bunch of time and money doing
> market research, surveys, and such before placing a new restaurant.
> Burger King would wait for McDonald's to spend the time and money, and
> then open a new restaurant across the street.

 Oh, wow; been a few years since I heard that one.  I'll admit, it seems
at least remotely viable.

 No, in the MoA case I'd say it's more about obvious, direct competition;
of all the (according to the site) 4.3 miles of potential storefront at
Mall of America, Microsoft chose *directly across the hallway* from the
long-standing Apple Store.  (Okay, that might be hyperbole -- it may have
been a shop or two down, as well; I forget.)

     Jima



From jared at puck.nether.net  Thu Sep 15 14:27:12 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 15 Sep 2011 15:27:12 -0400
Subject: IPV6 over a PPTP Link
In-Reply-To: <3210657A42284615809374B6190B8B01@work>
References: <C249D3C3D3E6402BAAEBD07D90BF0E90@work>
 <63748057-899F-4325-B25B-71A12A69D294@puck.nether.net>
 <3210657A42284615809374B6190B8B01@work>
Message-ID: <A9BF5735-10A2-4996-B857-B1569C1D3E8A@puck.nether.net>

So, in order to do that, I recommend you do the backend authentication via RADIUS to handle this provisioning and routing.

Cisco has documentation on the AV pairs that are necessary to send in the RADIUS response that goes to your PPTP device.  Make sure that you are using something with a beefy enough CPU to perform this as PPTP/IPv6 may be in the "slow-path" depending on the device.  You want as much to be offloaded to the hardware as feasible.

- Jared

On Sep 15, 2011, at 1:38 PM, Meftah Tayeb wrote:

> ok, that's using RA
> but i want to do a routed interface
> so give the PPTP host a static ip and route through it
> thank you
> 
> ----- Original Message ----- From: "Jared Mauch" <jared at puck.nether.net>
> To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
> Cc: <nanog at nanog.org>
> Sent: Thursday, September 15, 2011 6:36 PM
> Subject: Re: IPV6 over a PPTP Link
> 
> 
> I did this in the past without troubles.
> 
> http://www.gossamer-threads.com/lists/nsp/ipv6/27525
> 
> Should give you some help.
> 
> - Jared
> 
> -- snip --
> !
> vpdn enable
> !
> vpdn-group 1
> ! Default PPTP VPDN group
> accept-dialin
> protocol pptp
> virtual-template 1
> !
> interface Virtual-Template1
> ip unnumbered FastEthernet2/0
> ipv6 unnumbered FastEthernet2/0
> ipv6 enable
> ipv6 nd reachable-time 30
> no ipv6 nd suppress-ra
> peer default ip address pool DIAL-IN
> peer default ipv6 pool DIAL-IN6
> ppp encrypt mppe 128
> ppp authentication ms-chap
> ppp ipcp dns 129.250.35.250 129.250.35.251
> !
> ip local pool DIAL-IN 10.10.15.72 10.10.15.79
> ipv6 local pool DIAL-IN6 3ffe:3ffe:0:7080::/62 64
> -- snip --
> 
> On Sep 15, 2011, at 12:24 PM, Meftah Tayeb wrote:
> 
>> Hello,
>> can i ofer ipv6 addresses through a PPTP connection using cisco ?
>> if yes, how please ?
>> Thank you
>>   Meftah Tayeb
>> IT Consulting
>> http://www.tmvoip.com/
>> phone: +21321656139
>> Mobile: +213660347746
>> 
>> 
>> __________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________
>> 
>> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
> 
> 
> 
> __________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________
> 
> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________
> 
> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 



From tayeb.meftah at gmail.com  Thu Sep 15 14:18:26 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 15 Sep 2011 21:18:26 +0200
Subject: IPV6 over a PPTP Link
References: <C249D3C3D3E6402BAAEBD07D90BF0E90@work>
 <63748057-899F-4325-B25B-71A12A69D294@puck.nether.net>
 <3210657A42284615809374B6190B8B01@work>
 <A9BF5735-10A2-4996-B857-B1569C1D3E8A@puck.nether.net>
Message-ID: <0B005065C3AA4F4C8156912F4AF1A6FA@work>

great suggestion
i didn't want to use it for a high load of users, just for 2 linked routers
but anyway, i did it through a 6in4 tunnel over PPTP
Thank you

----- Original Message ----- 
From: "Jared Mauch" <jared at puck.nether.net>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: <nanog at nanog.org>
Sent: Thursday, September 15, 2011 9:27 PM
Subject: Re: IPV6 over a PPTP Link


So, in order to do that, I recommend you do the backend authentication via 
RADIUS to handle this provisioning and routing.

Cisco has documentation on the AV pairs that are necessary to send in the 
RADIUS response that goes to your PPTP device.  Make sure that you are using 
something with a beefy enough CPU to perform this as PPTP/IPv6 may be in the 
"slow-path" depending on the device.  You want as much to be offloaded to 
the hardware as feasible.

- Jared

On Sep 15, 2011, at 1:38 PM, Meftah Tayeb wrote:

> ok, that's using RA
> but i want to do a routed interface
> so give the PPTP host a static ip and route through it
> thank you
>
> ----- Original Message ----- From: "Jared Mauch" <jared at puck.nether.net>
> To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
> Cc: <nanog at nanog.org>
> Sent: Thursday, September 15, 2011 6:36 PM
> Subject: Re: IPV6 over a PPTP Link
>
>
> I did this in the past without troubles.
>
> http://www.gossamer-threads.com/lists/nsp/ipv6/27525
>
> Should give you some help.
>
> - Jared
>
> -- snip --
> !
> vpdn enable
> !
> vpdn-group 1
> ! Default PPTP VPDN group
> accept-dialin
> protocol pptp
> virtual-template 1
> !
> interface Virtual-Template1
> ip unnumbered FastEthernet2/0
> ipv6 unnumbered FastEthernet2/0
> ipv6 enable
> ipv6 nd reachable-time 30
> no ipv6 nd suppress-ra
> peer default ip address pool DIAL-IN
> peer default ipv6 pool DIAL-IN6
> ppp encrypt mppe 128
> ppp authentication ms-chap
> ppp ipcp dns 129.250.35.250 129.250.35.251
> !
> ip local pool DIAL-IN 10.10.15.72 10.10.15.79
> ipv6 local pool DIAL-IN6 3ffe:3ffe:0:7080::/62 64
> -- snip --
>
> On Sep 15, 2011, at 12:24 PM, Meftah Tayeb wrote:
>
>> Hello,
>> can i ofer ipv6 addresses through a PPTP connection using cisco ?
>> if yes, how please ?
>> Thank you
>>   Meftah Tayeb
>> IT Consulting
>> http://www.tmvoip.com/
>> phone: +21321656139
>> Mobile: +213660347746
>>
>>
>> __________ Information provenant d'ESET NOD32 Antivirus, version de la 
>> base des signatures de virus 6465 (20110915) __________
>>
>> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>
>
>
> __________ Information provenant d'ESET NOD32 Antivirus, version de la 
> base des signatures de virus 6465 (20110915) __________
>
> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
> __________ Information provenant d'ESET NOD32 Antivirus, version de la 
> base des signatures de virus 6465 (20110915) __________
>
> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>



__________ Information provenant d'ESET NOD32 Antivirus, version de la base 
des signatures de virus 6466 (20110915) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com




__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6466 (20110915) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com





From bgold at simons-rock.edu  Thu Sep 15 14:34:27 2011
From: bgold at simons-rock.edu (Brian Gold)
Date: Thu, 15 Sep 2011 15:34:27 -0400
Subject: routing issue for verizon dsl customers in western massachusetts
Message-ID: <014d01cc73de$7b92bd50$72b837f0$@simons-rock.edu>

Hello all, I posted this to the tech at lopsa mailing list and was advised to
repost it here. If anyone can help, I would be very happy to avoid having to
deal with hours more of Verizon level 1 tech support.

 

Over the past week, we've discovered that there is an issue with the way
some Verizon DSL customers are being routed in Western Massachusetts that is
preventing them from reaching my employers public IPs. The problem is only
limited to Verizon DSL customers, everyone else can reach these IP addresses
just fine. After many hours on the phone with Verizon tech support, I
finally managed to get myself and one of my coworker's home dsl connections
switched from a "redback router" to a "juniper router" which resolved the
issue, but only for us. I was told that everyone else in the area that is
being affected by the issue have to individually call Verizon tech support,
go through the same multi-hour troubleshooting steps, and if the technician
is bright enough to recognize what is going on, get their issue escalated up
to the central office where (in 2-4 business days) they will be switched
over to the juniper router. Obviously, this is not the ideal solution. I'd
really like to make the higher ups at Verizon aware of this issue and come
up with a solution for all of the affected customers, but because I only
have a residential account and my employer doesn't use Verizon, I've been
stymied in all of my attempts so far. Does anyone here have any contacts at
Verizon that I could get in touch with?


From morrowc.lists at gmail.com  Thu Sep 15 14:39:06 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 15 Sep 2011 15:39:06 -0400
Subject: routing issue for verizon dsl customers in western massachusetts
In-Reply-To: <014d01cc73de$7b92bd50$72b837f0$@simons-rock.edu>
References: <014d01cc73de$7b92bd50$72b837f0$@simons-rock.edu>
Message-ID: <CAL9jLaZbnASaiRuBic+ayKMEGOTXMUeKWD2FmT+TMnYDFniziQ@mail.gmail.com>

On Thu, Sep 15, 2011 at 3:34 PM, Brian Gold <bgold at simons-rock.edu> wrote:
> Hello all, I posted this to the tech at lopsa mailing list and was advised to
> repost it here. If anyone can help, I would be very happy to avoid having to
> deal with hours more of Verizon level 1 tech support.
>
>
>
> Over the past week, we've discovered that there is an issue with the way
> some Verizon DSL customers are being routed in Western Massachusetts that is
> preventing them from reaching my employers public IPs. The problem is only
> limited to Verizon DSL customers, everyone else can reach these IP addresses
> just fine. After many hours on the phone with Verizon tech support, I
> finally managed to get myself and one of my coworker's home dsl connections
> switched from a "redback router" to a "juniper router" which resolved the
> issue, but only for us. I was told that everyone else in the area that is
> being affected by the issue have to individually call Verizon tech support,
> go through the same multi-hour troubleshooting steps, and if the technician
> is bright enough to recognize what is going on, get their issue escalated up
> to the central office where (in 2-4 business days) they will be switched
> over to the juniper router. Obviously, this is not the ideal solution. I'd

actually it's not a bad solution.. if verizon is looking to lose lots
of money on tech support calls... :)

> really like to make the higher ups at Verizon aware of this issue and come

If you buy verizon services at your day job you can probably make
noise through your sales droids better than here (sadly)... verizon
likes to jump when customers have problems, if the customer is a large
corporation or other 'important' customer.

> up with a solution for all of the affected customers, but because I only
> have a residential account and my employer doesn't use Verizon, I've been
> stymied in all of my attempts so far. Does anyone here have any contacts at
> Verizon that I could get in touch with?
>
>


From Valdis.Kletnieks at vt.edu  Thu Sep 15 14:58:10 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 15 Sep 2011 15:58:10 -0400
Subject: Open Letters to Sixxs
In-Reply-To: Your message of "Thu, 15 Sep 2011 17:01:33 +0200."
 <4299CDD40A66466FADF8854A9765F913@work>
References: <391A8D586FE94AB08C5E66B712BA4378@work>
 <7DC97F2A-5733-4BDF-892C-8E63F617E41E@voiceworks.nl>
 <179E400888B9449E9393556CC09358CC@work>
 <CAAAas8GZuN2Hht8VSKTVRCeZ2pTT6sHwqhu+Xy0JgJ1LfSWGXA@mail.gmail.com>
 <4299CDD40A66466FADF8854A9765F913@work>
Message-ID: <13849.1316116690@turing-police.cc.vt.edu>

On Thu, 15 Sep 2011 17:01:33 +0200, Meftah Tayeb said:
> Good thinking mike
> i do have a VoIp carrier single homed with Cogent.
> any solution?

Sure.  Make sure you have alternate plans for when Cogent gets into another
peering tiff.  Not *if*, but *when*.  And you probably want to have a long,
detailed, technical discussion with your Voip carrier about what *they* intend
to do when Cogent gets into a peering tiff.

And while you're at it, see if you can find out what *other* surprises their
network design has in it - I'm willing to bet a large pizza with everything but
anchovies that "single homed with Cogent" is *not* the only massive deficiency
in their network - it's probably the equivalent of finding a brown M&M backstage
at a Van Halen concert...

(Yes, there's corner cases where "single homing to a Tier-1" makes business
sense, if the pipe is really cheap and you can survive the revenue hit caused
by a routing/peering spat. I don't think "VOIP carrier" is one of those corner
cases)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110915/555175ce/attachment-0001.bin>

From jared at puck.nether.net  Thu Sep 15 15:12:18 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 15 Sep 2011 16:12:18 -0400
Subject: IPV6 over a PPTP Link
In-Reply-To: <0B005065C3AA4F4C8156912F4AF1A6FA@work>
References: <C249D3C3D3E6402BAAEBD07D90BF0E90@work>
 <63748057-899F-4325-B25B-71A12A69D294@puck.nether.net>
 <3210657A42284615809374B6190B8B01@work>
 <A9BF5735-10A2-4996-B857-B1569C1D3E8A@puck.nether.net>
 <0B005065C3AA4F4C8156912F4AF1A6FA@work>
Message-ID: <20110915201218.GA84964@puck.nether.net>


On Thu, Sep 15, 2011 at 09:18:26PM +0200, Meftah Tayeb wrote:
> great suggestion
> i didn't want to use it for a high load of users, just for 2 linked routers
> but anyway, i did it through a 6in4 tunnel over PPTP

	If that's your goal, you should just use GRE or IPIP if the IPs are
static on each end.  You may be able to create the local user on the device if one
end is a dynamic IP, but I don't have experience there with PPTP on IOS.

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.


From skbohrer at simons-rock.edu  Thu Sep 15 15:13:02 2011
From: skbohrer at simons-rock.edu (Steve Bohrer)
Date: Thu, 15 Sep 2011 16:13:02 -0400
Subject: routing issue for verizon dsl customers in western massachusetts
In-Reply-To: <CAL9jLaZbnASaiRuBic+ayKMEGOTXMUeKWD2FmT+TMnYDFniziQ@mail.gmail.com>
References: <014d01cc73de$7b92bd50$72b837f0$@simons-rock.edu>
 <CAL9jLaZbnASaiRuBic+ayKMEGOTXMUeKWD2FmT+TMnYDFniziQ@mail.gmail.com>
Message-ID: <73C3F4CB-C541-438F-BC68-6074BD8B8045@simons-rock.edu>

On Sep 15, 2011, at 3:39 PM, Christopher Morrow wrote:

> On Thu, Sep 15, 2011 at 3:34 PM, Brian Gold <bgold at simons-rock.edu>  
> wrote:
>> Over the past week, we've discovered that there is an issue with  
>> the way
>> some Verizon DSL customers are being routed in Western  
>> Massachusetts that is
>> preventing them from reaching my employers public IPs. The problem  
>> is only
>> limited to Verizon DSL customers, everyone else can reach these IP  
>> addresses
>> just fine. After many hours on the phone with Verizon tech support, I
>> finally managed to get myself and one of my coworker's home dsl  
>> connections
>> switched from a "redback router" to a "juniper router" which  
>> resolved the
>> issue, but only for us.

[...]
>
> If you buy verizon services at your day job you can probably make
> noise through your sales droids better than here (sadly)... verizon
> likes to jump when customers have problems, if the customer is a large
> corporation or other 'important' customer.


That is just the problem! The college does not buy any Verizon network  
stuff directly, so we don't really have any access to their support.  
(We have a few cell phones, but not enough to be "important".)

Brian Gold (who first posted) happens to have their DSL to his house,  
and he was one of five who have reported the problem, so that gave him  
a slight in. But the only techs he could reach as an "end user" were  
not high enough up to fix this problem in a general way. After  
pressing them for literally hours, he was able to get transfered to  
their NOC, and get the problem resolved for his one address. But, they  
would not give him the NOC contact, and he had to repeat this multi- 
hour process to get it fixed for an other user. Verizon's DSL support  
suggested that we get our bandwith provider involved, and so they  
tried to pitch in, but they don't have any Verizon NOC contact either,  
especially since this issue is purely within a small corner of  
Verizon's DSL network, not on any of Verizon's links to our provider.

This issue hits only a few Verizon DSL users in NW Mass. It does not  
really seem like a routing problem, because the affected users can  
reach many of the servers in our AS, but not some addresses.  
Unfortunately, the "blocked" addresses include our web server and our  
mail server, so our staff who live out there noticed the issue pretty  
quickly. Traceroutes from Brian's house show that for our blocked  
hosts, the users don't get beyond Verizon's NAT.

The Verizon tech's "fix" of re-patching Brian's DSL line in to a  
different router feels to me like there is a config problem in the  
other router, but the tech we got is not authorized to alter the  
config. It would be nice if we could reach someone who could actually  
edit the broken config and make it right. Anyone from Verzion's NOC  
for Western Mass reading this? Or, does anyone else have useful  
contact info for them?

FWIW, Simon's Rock is 208.81.88.0/21, AS 19345. Here are a failed and  
a good trace from Brian's house, to different servers on our campus :

FAILS:
Tracing route to wilbur.simons-rock.edu [208.81.88.15]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.10.1
  2     1 ms     1 ms     1 ms  192.168.1.1
  3    53 ms   104 ms   116 ms  10.14.1.1
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.

WORKS:
Tracing route to dev.simons-rock.edu [208.81.88.25]
over a maximum of 30 hops:

1    <1 ms    <1 ms    <1 ms  192.168.10.1
2     1 ms     1 ms     1 ms  192.168.1.1
3    87 ms    54 ms    54 ms  10.14.1.1
4    99 ms   109 ms   103 ms at-0-3-0-1711.WMA-CORE-RTR2.verizon- 
gni.net [130.81.10.77]
5    16 ms    18 ms    16 ms  so-7-3-1-0.NY5030-BB-RTR2.verizon- 
gni.net [130.81.20.6]
6    19 ms    17 ms    17 ms  0.xe-3-1-0.BR3.NYC4.ALTER.NET  
[152.63.2.81]
7    18 ms    21 ms    18 ms  204.255.168.194
8   108 ms   188 ms   116 ms  pos5-0-2488M.cr1.BOS1.gblx.net  
[67.17.94.57]
9    24 ms    28 ms    23 ms  pos0-0-0-155M.ar1.BOS1.gblx.net  
[67.17.70.162]
10   121 ms   160 ms   127 ms  64.213.79.250
11    77 ms    77 ms    78 ms  208.81.88.25

Trace complete.

Anyways, thanks for any suggestions you can offer.

Steve Bohrer
Network Administrator
ITS, Bard College at Simon's Rock
413-528-7645




From morrowc.lists at gmail.com  Thu Sep 15 15:52:26 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 15 Sep 2011 16:52:26 -0400
Subject: routing issue for verizon dsl customers in western massachusetts
In-Reply-To: <73C3F4CB-C541-438F-BC68-6074BD8B8045@simons-rock.edu>
References: <014d01cc73de$7b92bd50$72b837f0$@simons-rock.edu>
 <CAL9jLaZbnASaiRuBic+ayKMEGOTXMUeKWD2FmT+TMnYDFniziQ@mail.gmail.com>
 <73C3F4CB-C541-438F-BC68-6074BD8B8045@simons-rock.edu>
Message-ID: <CAL9jLaZYQfFj_hSwCWPK5H2iyFSoRWQT375MmbXzt=r6W-muUw@mail.gmail.com>

On Thu, Sep 15, 2011 at 4:13 PM, Steve Bohrer <skbohrer at simons-rock.edu> wrote:
> On Sep 15, 2011, at 3:39 PM, Christopher Morrow wrote:
>
>> On Thu, Sep 15, 2011 at 3:34 PM, Brian Gold <bgold at simons-rock.edu> wrote:
>>>
>>> Over the past week, we've discovered that there is an issue with the way
>>> some Verizon DSL customers are being routed in Western Massachusetts that
>>> is
>>> preventing them from reaching my employers public IPs. The problem is
>>> only
>>> limited to Verizon DSL customers, everyone else can reach these IP
>>> addresses
>>> just fine. After many hours on the phone with Verizon tech support, I
>>> finally managed to get myself and one of my coworker's home dsl
>>> connections
>>> switched from a "redback router" to a "juniper router" which resolved the
>>> issue, but only for us.
>
> [...]
>>
>> If you buy verizon services at your day job you can probably make
>> noise through your sales droids better than here (sadly)... verizon
>> likes to jump when customers have problems, if the customer is a large
>> corporation or other 'important' customer.
>
>
> That is just the problem! The college does not buy any Verizon network stuff
> directly, so we don't really have any access to their support. (We have a
> few cell phones, but not enough to be "important".)
>
> Brian Gold (who first posted) happens to have their DSL to his house, and he
> was one of five who have reported the problem, so that gave him a slight in.
> But the only techs he could reach as an "end user" were not high enough up
> to fix this problem in a general way. After pressing them for literally
> hours, he was able to get transfered to their NOC, and get the problem
> resolved for his one address. But, they would not give him the NOC contact,
> and he had to repeat this multi-hour process to get it fixed for an other
> user. Verizon's DSL support suggested that we get our bandwith provider
> involved, and so they tried to pitch in, but they don't have any Verizon NOC
> contact either, especially since this issue is purely within a small corner
> of Verizon's DSL network, not on any of Verizon's links to our provider.
>
> This issue hits only a few Verizon DSL users in NW Mass. It does not really
> seem like a routing problem, because the affected users can reach many of
> the servers in our AS, but not some addresses. Unfortunately, the "blocked"
> addresses include our web server and our mail server, so our staff who live
> out there noticed the issue pretty quickly. Traceroutes from Brian's house
> show that for our blocked hosts, the users don't get beyond Verizon's NAT.

I wasn't aware verizon implemented CGN already... way to be a 'first
mover' in this field verizon!

>
> The Verizon tech's "fix" of re-patching Brian's DSL line in to a different
> router feels to me like there is a config problem in the other router, but
> the tech we got is not authorized to alter the config. It would be nice if
> we could reach someone who could actually edit the broken config and make it
> right. Anyone from Verzion's NOC for Western Mass reading this? Or, does
> anyone else have useful contact info for them?

you probably want someone in the NOC which is (I think) stil in
Reston, va... I don't think they have separate noc's per region. The
first-line tech folks you chat with on the phone really arent' able
(even to login really) to fix devices in the field :(

anyways, this looks crappy :( but yeah for CGN being all it's cracked up to be!

-chris

>
> FWIW, Simon's Rock is 208.81.88.0/21, AS 19345. Here are a failed and a good
> trace from Brian's house, to different servers on our campus :
>
> FAILS:
> Tracing route to wilbur.simons-rock.edu [208.81.88.15]
> over a maximum of 30 hops:
>
> ?1 ? ?<1 ms ? ?<1 ms ? ?<1 ms ?192.168.10.1
> ?2 ? ? 1 ms ? ? 1 ms ? ? 1 ms ?192.168.1.1
> ?3 ? ?53 ms ? 104 ms ? 116 ms ?10.14.1.1
> ?4 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out.
> ?5 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out.
> ?6 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out.
> ?7 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out.
>
> WORKS:
> Tracing route to dev.simons-rock.edu [208.81.88.25]
> over a maximum of 30 hops:
>
> 1 ? ?<1 ms ? ?<1 ms ? ?<1 ms ?192.168.10.1
> 2 ? ? 1 ms ? ? 1 ms ? ? 1 ms ?192.168.1.1
> 3 ? ?87 ms ? ?54 ms ? ?54 ms ?10.14.1.1
> 4 ? ?99 ms ? 109 ms ? 103 ms at-0-3-0-1711.WMA-CORE-RTR2.verizon-gni.net
> [130.81.10.77]
> 5 ? ?16 ms ? ?18 ms ? ?16 ms ?so-7-3-1-0.NY5030-BB-RTR2.verizon-gni.net
> [130.81.20.6]
> 6 ? ?19 ms ? ?17 ms ? ?17 ms ?0.xe-3-1-0.BR3.NYC4.ALTER.NET [152.63.2.81]
> 7 ? ?18 ms ? ?21 ms ? ?18 ms ?204.255.168.194
> 8 ? 108 ms ? 188 ms ? 116 ms ?pos5-0-2488M.cr1.BOS1.gblx.net [67.17.94.57]
> 9 ? ?24 ms ? ?28 ms ? ?23 ms ?pos0-0-0-155M.ar1.BOS1.gblx.net [67.17.70.162]
> 10 ? 121 ms ? 160 ms ? 127 ms ?64.213.79.250
> 11 ? ?77 ms ? ?77 ms ? ?78 ms ?208.81.88.25
>
> Trace complete.
>
> Anyways, thanks for any suggestions you can offer.
>
> Steve Bohrer
> Network Administrator
> ITS, Bard College at Simon's Rock
> 413-528-7645
>
>
>
>


From heather.schiller at verizon.com  Thu Sep 15 18:51:04 2011
From: heather.schiller at verizon.com (Schiller, Heather A)
Date: Thu, 15 Sep 2011 19:51:04 -0400
Subject: The Cidr Report - 4byte ASN handling
In-Reply-To: <201109092200.p89M00vQ034172@wattle.apnic.net>
References: <201109092200.p89M00vQ034172@wattle.apnic.net>
Message-ID: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661AFED@FHDP1LUMXC7V43.us.one.verizon.com>

 
I thought AS-plain notation was the standard for 4-byte ASN's?  Also to cidr report folks, in the web version, clicking on the ASN for these takes you to the page for AS3 (MIT)

46.18.104.0/21    AS3.746 
195.54.52.0/23  	AS3.523  		
195.54.52.0/24  	AS3.523  		
195.54.53.0/24  	AS3.523  

route-views>sh ip bgp 195.54.52.0
BGP routing table entry for 195.54.52.0/24, version 218523
Paths: (34 available, best #34, table Default-IP-Routing-Table)
  Not advertised to any peer
  3257 3356 3255 3.523 3.523 3.523
    89.149.178.10 from 89.149.178.10 (213.200.87.91)
      Origin IGP, metric 10, localpref 100, valid, external
      Community: 3257:8091 3257:30042 3257:50001 3257:54900 3257:54901

-----Original Message-----
From: cidr-report at potaroo.net [mailto:cidr-report at potaroo.net] 
Sent: Friday, September 09, 2011 6:00 PM
To: cidr-report at potaroo.net
Cc: apops at apops.net; afnog at afnog.org; nanog at nanog.org; eof-list at ripe.net; routing-wg at ripe.net
Subject: The Cidr Report

This report has been generated at Fri Sep  9 21:12:28 2011 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
        02-09-11    373096      219901
        03-09-11    373636      219796
        04-09-11    373666      219877
        05-09-11    373566      219844
        06-09-11    373748      219894
        07-09-11    373965      219992
        08-09-11    373797      219481
        09-09-11    373405      220098


AS Summary
         38831  Number of ASes in routing system
         16392  Number of ASes announcing only one prefix
          3564  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      108360672  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').

 --- 09Sep11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     374093   219958   154135    41.2%   All ASes

AS6389      3564      229     3335    93.6%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4766      2508      974     1534    61.2%   KIXS-AS-KR Korea Telecom
AS18566     1912      378     1534    80.2%   COVAD - Covad Communications
                                               Co.
AS22773     1451      108     1343    92.6%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1547      228     1319    85.3%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS4323      1627      397     1230    75.6%   TWTC - tw telecom holdings,
                                               inc.
AS10620     1661      591     1070    64.4%   Telmex Colombia S.A.
AS1785      1825      778     1047    57.4%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS19262     1394      400      994    71.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS7552      1415      431      984    69.5%   VIETEL-AS-AP Vietel
                                               Corporation
AS28573     1302      344      958    73.6%   NET Servicos de Comunicao S.A.
AS18101      950      144      806    84.8%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS24560     1177      386      791    67.2%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS8151      1411      659      752    53.3%   Uninet S.A. de C.V.
AS4808      1077      339      738    68.5%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS7303      1051      316      735    69.9%   Telecom Argentina S.A.
AS7545      1581      860      721    45.6%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1103      449      654    59.3%   LEVEL3 Level 3 Communications
AS30036     1327      692      635    47.9%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS3549      1080      449      631    58.4%   GBLX Global Crossing Ltd.
AS14420      715       92      623    87.1%   CORPORACION NACIONAL DE
                                               TELECOMUNICACIONES - CNT EP
AS20115     1591      971      620    39.0%   CHARTER-NET-HKY-NC - Charter
                                               Communications
AS22561      973      365      608    62.5%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS17676      675       70      605    89.6%   GIGAINFRA Softbank BB Corp.
AS17974     1985     1400      585    29.5%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4804       660       87      573    86.8%   MPX-AS Microplex PTY LTD
AS22047      579       31      548    94.6%   VTR BANDA ANCHA S.A.
AS4780       759      230      529    69.7%   SEEDNET Digital United Inc.
AS7011      1183      656      527    44.5%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.
AS15475      512        8      504    98.4%   NOL

Total      40595    13062    27533    67.8%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        46.18.104.0/21       AS3.746 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        76.77.32.0/19        AS2828  XO-AS15 - XO Communications
        80.88.10.0/24        AS33774 DJAWEB
        100.100.100.0/24     AS3549  GBLX Global Crossing Ltd.
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        181.82.15.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.16.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.17.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        181.82.18.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        190.102.32.0/20      AS30058 FDCSERVERS - FDCservers.net
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.111.87.0/24      AS24812 
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.76.0/24       AS7195  Telecorp Colombia S.A.
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.9.57.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        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.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.72.192.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.72.194.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        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.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.58.200.0/24      AS18530 ISOMEDIA-1 - Isomedia Inc.
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


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 matt.shadbolt at gmail.com  Thu Sep 15 19:16:35 2011
From: matt.shadbolt at gmail.com (Matt Shadbolt)
Date: Fri, 16 Sep 2011 10:16:35 +1000
Subject: ouch..
In-Reply-To: <4e724294.1e30960a.372e.79d5SMTPIN_ADDED@mx.google.com>
References: <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
 <4E70CFF9.8050505@otd.com>
 <CADE4tYWnFYoXuC7h3jWAprbW8aYjgY2Lfcv+tJc9+ZBThgsRQA@mail.gmail.com>
 <CAN1XHtdHV5p7bK-na3G9iPCPL5hHXeVkf0sRcW=R9Ukjjqb91A@mail.gmail.com>
 <7098B053-6896-4D8A-8715-1FDE0802327C@delong.com>
 <20110915180701.GB31116@hiwaay.net>
 <4e724294.1e30960a.372e.79d5SMTPIN_ADDED@mx.google.com>
Message-ID: <CABhux+AztGwFS_ssBOjzsN2tSL1+qNgp9VD4zeUAb7JYAMh9Jg@mail.gmail.com>

Microsoft had a direct dig at vmware recently (good video IMO)

http://vmlimited.ctp.trafficmgr.com/

Matt

On Fri, Sep 16, 2011 at 4:23 AM, Jima <nanog at jima.tk> wrote:

> > Once upon a time, Jima <nanog at jima.tk> said:
> >> On Thu, 15 Sep 2011, Owen DeLong wrote:
> >> > I was at Valley Fair mall the other day. Micr0$0ft is apparently
> >> building
> >> > a
> >> > new store directly across from the Apple store there.
> >>
> >>  It's funny; they did the exact same thing at Mall of America maybe a
> >> year
> >> ago.  I guess your report confirms it was a strategy, rather than a
> >> really absurd coincidence.
> >
> > They could be following the (possibly urban legend) Burger King model.
> > Supposedly, McDonald's would spend a bunch of time and money doing
> > market research, surveys, and such before placing a new restaurant.
> > Burger King would wait for McDonald's to spend the time and money, and
> > then open a new restaurant across the street.
>
>  Oh, wow; been a few years since I heard that one.  I'll admit, it seems
> at least remotely viable.
>
>  No, in the MoA case I'd say it's more about obvious, direct competition;
> of all the (according to the site) 4.3 miles of potential storefront at
> Mall of America, Microsoft chose *directly across the hallway* from the
> long-standing Apple Store.  (Okay, that might be hyperbole -- it may have
> been a shop or two down, as well; I forget.)
>
>     Jima
>
>
>


-- 
*mattlog.net*

From swm at emanon.com  Thu Sep 15 20:02:10 2011
From: swm at emanon.com (Scott Morris)
Date: Thu, 15 Sep 2011 21:02:10 -0400
Subject: ouch..
In-Reply-To: <7033AC21-3074-4541-8D5C-B37E7AF57201@freedomnet.co.nz>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com> <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
 <7033AC21-3074-4541-8D5C-B37E7AF57201@freedomnet.co.nz>
Message-ID: <4E72A012.5080205@emanon.com>

Now just where would the fun in THAT be?  ;)

Scott

On 9/14/11 11:00 AM, James Jones wrote:
> Funny they forget to mention that Cisco doesn't have 100g any where.
>
> Sent from my iPhone
>
> On Sep 14, 2011, at 7:41 AM, Leigh Porter <leigh.porter at ukbroadband.com> wrote:
>
>>
>>> -----Original Message-----
>>> From: Always Learning [mailto:nanog at u61.u22.net]
>>> Sent: 14 September 2011 14:39
>>> To: N. Max Pierson
>>> Cc: nanog at nanog.org
>>> Subject: Re: ouch..
>>>
>>>
>>> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
>>>
>>>> Either way, it's pathetic. If someone is going to slander in the
>>>> fashion the site has done, they should at least put a contact form
>>>> somewhere for some feedback :)
>>> Slander means falsehood. Cisco tells lies ?
>>>
>>>
>>> --
>>> With best regards,
>>>
>>> Paul.
>>> England,
>>> EU.
>>
>> Lies? So who has 100G MX series cards then..?
>>
>> --
>> Leigh
>>
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
>>
>
>



From skbohrer at simons-rock.edu  Thu Sep 15 21:09:32 2011
From: skbohrer at simons-rock.edu (Steve Bohrer)
Date: Thu, 15 Sep 2011 22:09:32 -0400
Subject: routing issue for verizon dsl customers in western massachusetts
In-Reply-To: <CAL9jLaZYQfFj_hSwCWPK5H2iyFSoRWQT375MmbXzt=r6W-muUw@mail.gmail.com>
References: <014d01cc73de$7b92bd50$72b837f0$@simons-rock.edu>
 <CAL9jLaZbnASaiRuBic+ayKMEGOTXMUeKWD2FmT+TMnYDFniziQ@mail.gmail.com>
 <73C3F4CB-C541-438F-BC68-6074BD8B8045@simons-rock.edu>
 <CAL9jLaZYQfFj_hSwCWPK5H2iyFSoRWQT375MmbXzt=r6W-muUw@mail.gmail.com>
Message-ID: <FC2CDAD3-4546-4B3A-9E26-92B18048ACD8@simons-rock.edu>

On Sep 15, 2011, at 4:52 PM, Christopher Morrow wrote:
>
> I wasn't aware verizon implemented CGN already... way to be a 'first
> mover' in this field verizon!
>

Maybe they are tying it out here in the sticks, where the glitches  
only hit single-digit numbers of users? (Though, I'd think if it was  
actually new, then they might have a higher-order tech paying  
attention to the glitches.) Oh well. Close enough, mostly.

Steve




From robertg at garlic.com  Thu Sep 15 21:20:04 2011
From: robertg at garlic.com (Robert Glover)
Date: Thu, 15 Sep 2011 19:20:04 -0700
Subject: Anyone from Covad here?
Message-ID: <4E72B254.6080501@garlic.com>

Covad (or should I say Megapath now..),

You have DNS servers that are failing to resolve anything at this time:

64.105.172.26 and 64.105.172.27 are both failing.

This is a Bad Thing as these are the servers that the majority of our 
Covad customers use.

Sincerely,
Bobby Glover
Director of Information Services
SVI Incorporated



From marcus at blazingdot.com  Thu Sep 15 21:38:05 2011
From: marcus at blazingdot.com (Marcus Reid)
Date: Fri, 16 Sep 2011 02:38:05 +0000
Subject: Anyone from Covad here?
In-Reply-To: <4E72B254.6080501@garlic.com>
References: <4E72B254.6080501@garlic.com>
Message-ID: <20110916023805.GA32936@blazingdot.com>

On Thu, Sep 15, 2011 at 07:20:04PM -0700, Robert Glover wrote:
> Covad (or should I say Megapath now..),
> 
> You have DNS servers that are failing to resolve anything at this time:
> 
> 64.105.172.26 and 64.105.172.27 are both failing.
> 
> This is a Bad Thing as these are the servers that the majority of our 
> Covad customers use.

Called it in to the right guy.

Marcus


From morrowc.lists at gmail.com  Fri Sep 16 00:04:50 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 16 Sep 2011 01:04:50 -0400
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
Message-ID: <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>

I hate to beat/stab a dead horsey, but I found this by happenstance:

<https://www.arin.net/resources/whoisrws/whois_diff.html>

which describes some of the differences between RWS output and
traditional output.

For the scripty-minded folks out there:
$ wget -O - -q http://whois.arin.net/rest/ip/128.2.35.50.txt
NetRange:       128.2.0.0 - 128.2.255.255
CIDR:           128.2.0.0/16
OriginAS:       AS9
NetName:        CMU-NET
NetHandle:      NET-128-2-0-0-1
Parent:         NET-128-0-0-0-0
NetType:        Direct Assignment
RegDate:        1984-04-17
Updated:        2010-05-03
Ref:            http://whois.arin.net/rest/net/NET-128-2-0-0-1

I reckon that for a simple script replacement of: "whois ip"

the above would get you buy fairly neatly (you could account for the
differences between old/new formats with the link above as well, if so
inclined).

-chris

On Mon, Sep 12, 2011 at 11:15 PM, Ryan Gelobter <ryan.g at atwgpc.net> wrote:
> I e-mailed Marco (md) the creator of 'whois' back in July when this started
> and he stated he was going to try to work around the rWHOIS issue in the
> next release. Sadly there hasn't been a new release yet but I am hopeful.
>


From randy at psg.com  Fri Sep 16 00:45:15 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 16 Sep 2011 07:45:15 +0200
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
Message-ID: <m2ipotf3bo.wl%randy@psg.com>

> I hate to beat/stab a dead horsey, but I found this by happenstance:
> 
> <https://www.arin.net/resources/whoisrws/whois_diff.html>
> 
> which describes some of the differences between RWS output and
> traditional output.
> 
> For the scripty-minded folks out there:
> $ wget -O - -q http://whois.arin.net/rest/ip/128.2.35.50.txt
> ...

i used to dial 411.  now i have to build a machine from tinkertoys
to open the fridge and get information.

i am sure someone thought this was progress.  you gotta love it.

randy


From ops.lists at gmail.com  Fri Sep 16 03:06:11 2011
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Fri, 16 Sep 2011 13:36:11 +0530
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <m2ipotf3bo.wl%randy@psg.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
Message-ID: <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>

Someone laying that "restful whois" to rest or at least maintaining
the old whois in parallel would be great.

Lots and lots of scripts to go spammer hunting using regexps to find
all the netblocks assigned to a spammer had to be rewritten :(

On Fri, Sep 16, 2011 at 11:15 AM, Randy Bush <randy at psg.com> wrote:
>
> i used to dial 411. ?now i have to build a machine from tinkertoys
> to open the fridge and get information.
>
> i am sure someone thought this was progress. ?you gotta love it.
>



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From davehart at gmail.com  Fri Sep 16 03:15:43 2011
From: davehart at gmail.com (Dave Hart)
Date: Fri, 16 Sep 2011 08:15:43 +0000
Subject: routing issue for verizon dsl customers in western massachusetts
In-Reply-To: <CAL9jLaZYQfFj_hSwCWPK5H2iyFSoRWQT375MmbXzt=r6W-muUw@mail.gmail.com>
References: <014d01cc73de$7b92bd50$72b837f0$@simons-rock.edu>
 <CAL9jLaZbnASaiRuBic+ayKMEGOTXMUeKWD2FmT+TMnYDFniziQ@mail.gmail.com>
 <73C3F4CB-C541-438F-BC68-6074BD8B8045@simons-rock.edu>
 <CAL9jLaZYQfFj_hSwCWPK5H2iyFSoRWQT375MmbXzt=r6W-muUw@mail.gmail.com>
Message-ID: <CAMbSiYDb0jrhUJCsVKr8oJfDwaWdqZs1nqs-LKTh=UdWrx7DMA@mail.gmail.com>

On Thu, Sep 15, 2011 at 20:52 UTC, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Thu, Sep 15, 2011 at 4:13 PM, Steve Bohrer <skbohrer at simons-rock.edu> wrote:
>> Traceroutes from Brian's house
>> show that for our blocked hosts, the users don't get beyond Verizon's NAT.
>
> I wasn't aware verizon implemented CGN already... way to be a 'first
> mover' in this field verizon!

I am betting they have not.

>> FAILS:
>> Tracing route to wilbur.simons-rock.edu [208.81.88.15]
>> over a maximum of 30 hops:
>>
>> ?1 ? ?<1 ms ? ?<1 ms ? ?<1 ms ?192.168.10.1
>> ?2 ? ? 1 ms ? ? 1 ms ? ? 1 ms ?192.168.1.1
>> ?3 ? ?53 ms ? 104 ms ? 116 ms ?10.14.1.1
>> ?4 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out.
>> ?5 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out.
>> ?6 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out.
>> ?7 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out.

Here's a trace to the same destination from a Verizon residential DSL
on Maryland's Eastern Shore:

Tracing route to wilbur.simons-rock.edu [208.81.88.15]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.201.1
  2    25 ms    25 ms    24 ms  10.31.8.1
  3    38 ms    99 ms    78 ms
at-4-3-0-1712.sal-core-rtr1.verizon-gni.net [130.81.136.122]
  4    26 ms    26 ms    26 ms
so-0-0-0-0.sal-core-rtr2.verizon-gni.net [130.81.18.247]
  5    94 ms    31 ms    31 ms  130.81.20.238
  6    32 ms    32 ms    32 ms  0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73]
  7    32 ms    33 ms    31 ms  te2-3.ar6.DCA3.gblx.net [64.215.195.113]
  8    33 ms    33 ms    32 ms  xe6-2-0-10G.scr2.WDC2.gblx.net [67.16.136.197]
  9    37 ms    38 ms    38 ms  so2-2-0-10G.scr2.NYC1.gblx.net [67.17.95.102]
 10    43 ms    44 ms    44 ms  pos9-0-2488M.cr2.BOS1.gblx.net [67.17.94.157]
 11   244 ms   200 ms   204 ms  pos1-0-0-155M.ar1.BOS1.gblx.net [67.17.70.165]
 12    50 ms    51 ms    50 ms  64.213.79.250
 13    49 ms    50 ms    48 ms  wilbur.simons-rock.edu [208.81.88.15]

192.168.201.1 is the router behind the bridged ADSL CPE which
terminates the customer PPPoE.  10.31.8.1 is RFC 1918, but is not a
NAT.  I know from various "test my crappy broadband" sites that the
only drain bramage on the provider side of the link is routine
consumer-class port blocking (SMB networking, SQL, and of course port
80 so the mothe#@#$rs can charge extra for "business" with static IP
and unblocked http).  At least https works.

Looking at Brian's trace above, I can't help wondering if the client
is 444'd, but not due to CGN/LSN.  Could both 192.168.10.1 and
192.168.1.1 be on-premises, with 192.168.1.1 terminating PPPoE?  The
latencies seem to confirm.  It is possible it's only a single level of
NAT on .1.1, with more-respectable routing by .10.1...

Cheers,
Dave Hart


From randy at psg.com  Fri Sep 16 03:21:47 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 16 Sep 2011 10:21:47 +0200
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
Message-ID: <m2hb4cgan8.wl%randy@psg.com>

> Someone laying that "restful whois" to rest or at least maintaining
> the old whois in parallel would be great.
> 
> Lots and lots of scripts to go spammer hunting using regexps to find
> all the netblocks assigned to a spammer had to be rewritten :(

when you have a monopoly, you do not have the slightest instinct to
think of the effects of your actions on others.

randy


From fweimer at bfk.de  Fri Sep 16 04:20:31 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 16 Sep 2011 09:20:31 +0000
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org> (Jon Lewis's
 message of "Mon, 12 Sep 2011 12:32:20 -0400 (EDT)")
References: <1315842056.4599.49.camel@m6.u226.com> <4E6E3088.7010109@unfix.org>
 <Pine.LNX.4.61.1109121225211.18171@soloth.lewis.org>
Message-ID: <82lito7sio.fsf@mid.bfk.de>

* Jon Lewis:

> No he's not.  He's complaining that sometime in the past few weeks (or
> is it months now?) ARIN changed the behavior of their whois server.

Ahem, ARIN's WHOIS server has been sending such responses for ages.
Maybe the change is that more addresses trigger this behavior, but you
could get the handle list before.  Even sending the "+" flag has been
requested before:

| Date: Fri, 27 Dec 2002 22:19:09 +0100
| 
| Package: whois
| Version: 4.6.1
| Severity: normal
| Tags: patch
| 
| Please include the "+" flag when querying information for IP addresses
| from whois.arin.net.  This way, whois(1) will print useful information
| and not just the useless overview.

<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174497>

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From tayeb.meftah at gmail.com  Fri Sep 16 04:38:59 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Fri, 16 Sep 2011 11:38:59 +0200
Subject: 6To4 Transition Concideration
Message-ID: <7CC7BDF5B81C44808A89DE13AFD03C96@work>

Hello,
i have a Question about 6To4
in my understand (i hop is true):
Iana has set up the prefix 2002::/16 specialy for the 6To4 transition method
if i get a /32 from a RIR, Could i use the 6To4 to provide it ?
and in my understanding is not pocible
cause the client has to calculate the compatible /48 of his /32 IPV4 address and tunnel it to the 6To4 prefix of 192.168.1.1/24
please let me know
thank you

    Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213660347746


__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6468 (20110916) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com


From swmike at swm.pp.se  Fri Sep 16 05:05:30 2011
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 16 Sep 2011 12:05:30 +0200 (CEST)
Subject: 6To4 Transition Concideration
In-Reply-To: <7CC7BDF5B81C44808A89DE13AFD03C96@work>
References: <7CC7BDF5B81C44808A89DE13AFD03C96@work>
Message-ID: <alpine.DEB.2.00.1109161204250.13829@uplift.swm.pp.se>

On Fri, 16 Sep 2011, Meftah Tayeb wrote:

> Hello,
> i have a Question about 6To4
> in my understand (i hop is true):
> Iana has set up the prefix 2002::/16 specialy for the 6To4 transition method
> if i get a /32 from a RIR, Could i use the 6To4 to provide it ?

No, then it's not 6to4 anymore. 6to4 is specifically the addresses you 
mentioned. If you use anything else, then it's 6RD.

You also need to run your own 6RD-gateway, of course.

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


From tayeb.meftah at gmail.com  Fri Sep 16 04:56:53 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Fri, 16 Sep 2011 11:56:53 +0200
Subject: 6To4 Transition Concideration
References: <7CC7BDF5B81C44808A89DE13AFD03C96@work>
 <alpine.DEB.2.00.1109161204250.13829@uplift.swm.pp.se>
Message-ID: <9EB9EC2C6AA34F06AD46674C17559746@work>

Mike,
Thank you
any documentation about 6RD ?
i don't want to do RA.
thank you

----- Original Message ----- 
From: "Mikael Abrahamsson" <swmike at swm.pp.se>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: <nanog at nanog.org>
Sent: Friday, September 16, 2011 12:05 PM
Subject: Re: 6To4 Transition Concideration


> On Fri, 16 Sep 2011, Meftah Tayeb wrote:
>
>> Hello,
>> i have a Question about 6To4
>> in my understand (i hop is true):
>> Iana has set up the prefix 2002::/16 specialy for the 6To4 transition 
>> method
>> if i get a /32 from a RIR, Could i use the 6To4 to provide it ?
>
> No, then it's not 6to4 anymore. 6to4 is specifically the addresses you 
> mentioned. If you use anything else, then it's 6RD.
>
> You also need to run your own 6RD-gateway, of course.
>
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se
>
>
> __________ Information provenant d'ESET NOD32 Antivirus, version de la 
> base des signatures de virus 6468 (20110916) __________
>
> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> 


__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6468 (20110916) __________

Le message a ?t? v?rifi? par ESET NOD32 Antivirus.

http://www.eset.com





From swmike at swm.pp.se  Fri Sep 16 05:10:11 2011
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 16 Sep 2011 12:10:11 +0200 (CEST)
Subject: 6To4 Transition Concideration
In-Reply-To: <9EB9EC2C6AA34F06AD46674C17559746@work>
References: <7CC7BDF5B81C44808A89DE13AFD03C96@work>
 <alpine.DEB.2.00.1109161204250.13829@uplift.swm.pp.se>
 <9EB9EC2C6AA34F06AD46674C17559746@work>
Message-ID: <alpine.DEB.2.00.1109161209150.13829@uplift.swm.pp.se>

On Fri, 16 Sep 2011, Meftah Tayeb wrote:

> any documentation about 6RD ?

<http://tools.ietf.org/html/rfc5969>

<http://en.wikipedia.org/wiki/IPv6_rapid_deployment>

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


From jcurran at arin.net  Fri Sep 16 05:53:39 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 16 Sep 2011 10:53:39 +0000
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <m2hb4cgan8.wl%randy@psg.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com>
Message-ID: <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>

On Sep 16, 2011, at 3:21 AM, Randy Bush wrote:
> 
> when you have a monopoly, you do not have the slightest instinct to
> think of the effects of your actions on others.

Randy - 
 
  Over the last decade, we've run multiple consultations with the 
  community regarding changing Whois.  These have either been the
  result of internal recommendations or suggestions from the ARIN
  community, and have covered a wide range of issues including the
  format of responses, the number of responses returned, the AUP
  for the Whois data, and more.  All of the archives of these are
  on https://www.arin.net/participate/acsp/index.html.  

  If you have a particular suggestion for changing whois, please 
  feel free to submit it.  If you'd prefer a different process
  altogether for discussing changes, please let me know.

FYI,
/John

John Curran
President and CEO
ARIN



From bgold at simons-rock.edu  Fri Sep 16 06:51:44 2011
From: bgold at simons-rock.edu (bgold at simons-rock.edu)
Date: Fri, 16 Sep 2011 07:51:44 -0400 (EDT)
Subject: routing issue for verizon dsl customers in western massachusetts
In-Reply-To: <CAMbSiYDb0jrhUJCsVKr8oJfDwaWdqZs1nqs-LKTh=UdWrx7DMA@mail.gmail.com>
References: <014d01cc73de$7b92bd50$72b837f0$@simons-rock.edu>
 <CAL9jLaZbnASaiRuBic+ayKMEGOTXMUeKWD2FmT+TMnYDFniziQ@mail.gmail.com>
 <73C3F4CB-C541-438F-BC68-6074BD8B8045@simons-rock.edu>
 <CAL9jLaZYQfFj_hSwCWPK5H2iyFSoRWQT375MmbXzt=r6W-muUw@mail.gmail.com>
 <CAMbSiYDb0jrhUJCsVKr8oJfDwaWdqZs1nqs-LKTh=UdWrx7DMA@mail.gmail.com>
Message-ID: <57425.10.30.2.44.1316173904.squirrel@lock.simons-rock.edu>

> On Thu, Sep 15, 2011 at 20:52 UTC, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
>> On Thu, Sep 15, 2011 at 4:13 PM, Steve Bohrer <skbohrer at simons-rock.edu>
>> wrote:
>>> Traceroutes from Brian's house
>>> show that for our blocked hosts, the users don't get beyond Verizon's
>>> NAT.
>>
>> I wasn't aware verizon implemented CGN already... way to be a 'first
>> mover' in this field verizon!
>
> I am betting they have not.
>
>>> FAILS:
>>> Tracing route to wilbur.simons-rock.edu [208.81.88.15]
>>> over a maximum of 30 hops:
>>>
>>> ??1 ?? ??<1 ms ?? ??<1 ms ?? ??<1 ms ??192.168.10.1
>>> ??2 ?? ?? 1 ms ?? ?? 1 ms ?? ?? 1 ms ??192.168.1.1
>>> ??3 ?? ??53 ms ?? 104 ms ?? 116 ms ??10.14.1.1
>>> ??4 ?? ?? * ?? ?? ?? ??* ?? ?? ?? ??* ?? ?? Request timed out.
>>> ??5 ?? ?? * ?? ?? ?? ??* ?? ?? ?? ??* ?? ?? Request timed out.
>>> ??6 ?? ?? * ?? ?? ?? ??* ?? ?? ?? ??* ?? ?? Request timed out.
>>> ??7 ?? ?? * ?? ?? ?? ??* ?? ?? ?? ??* ?? ?? Request timed out.
>
> Here's a trace to the same destination from a Verizon residential DSL
> on Maryland's Eastern Shore:
>
> Tracing route to wilbur.simons-rock.edu [208.81.88.15]
> over a maximum of 30 hops:
>
>   1    <1 ms    <1 ms    <1 ms  192.168.201.1
>   2    25 ms    25 ms    24 ms  10.31.8.1
>   3    38 ms    99 ms    78 ms
> at-4-3-0-1712.sal-core-rtr1.verizon-gni.net [130.81.136.122]
>   4    26 ms    26 ms    26 ms
> so-0-0-0-0.sal-core-rtr2.verizon-gni.net [130.81.18.247]
>   5    94 ms    31 ms    31 ms  130.81.20.238
>   6    32 ms    32 ms    32 ms  0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73]
>   7    32 ms    33 ms    31 ms  te2-3.ar6.DCA3.gblx.net [64.215.195.113]
>   8    33 ms    33 ms    32 ms  xe6-2-0-10G.scr2.WDC2.gblx.net
> [67.16.136.197]
>   9    37 ms    38 ms    38 ms  so2-2-0-10G.scr2.NYC1.gblx.net
> [67.17.95.102]
>  10    43 ms    44 ms    44 ms  pos9-0-2488M.cr2.BOS1.gblx.net
> [67.17.94.157]
>  11   244 ms   200 ms   204 ms  pos1-0-0-155M.ar1.BOS1.gblx.net
> [67.17.70.165]
>  12    50 ms    51 ms    50 ms  64.213.79.250
>  13    49 ms    50 ms    48 ms  wilbur.simons-rock.edu [208.81.88.15]
>
> 192.168.201.1 is the router behind the bridged ADSL CPE which
> terminates the customer PPPoE.  10.31.8.1 is RFC 1918, but is not a
> NAT.  I know from various "test my crappy broadband" sites that the
> only drain bramage on the provider side of the link is routine
> consumer-class port blocking (SMB networking, SQL, and of course port
> 80 so the mothe#@#$rs can charge extra for "business" with static IP
> and unblocked http).  At least https works.
>
> Looking at Brian's trace above, I can't help wondering if the client
> is 444'd, but not due to CGN/LSN.  Could both 192.168.10.1 and
> 192.168.1.1 be on-premises, with 192.168.1.1 terminating PPPoE?  The
> latencies seem to confirm.  It is possible it's only a single level of
> NAT on .1.1, with more-respectable routing by .10.1...

In my setup, 192.168.10.1 is my DD-WRT router and 192.168.1.1 is the DSL
modem. When I ran a traceroute directly from the DSL modem's web
interface, I got the following results:

1    57 ms    98 ms   129 ms  10.14.1.1
3     *        *        *     Request timed out.
5     *        *        *     Request timed out.
5     *        *        *     Request timed out.
6     *        *        *     Request timed out.

>
> Cheers,
> Dave Hart
>
>



From randy at psg.com  Fri Sep 16 10:03:07 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 16 Sep 2011 17:03:07 +0200
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com>
 <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
Message-ID: <m2y5xoedhw.wl%randy@psg.com>

> If you have a particular suggestion for changing whois, please 
> feel free to submit it.

simple.  don't.

if you want to do something new, don't call it whois.

randy


From leigh.porter at ukbroadband.com  Fri Sep 16 10:17:59 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 16 Sep 2011 15:17:59 +0000
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <m2y5xoedhw.wl%randy@psg.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com>
 <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net> <m2y5xoedhw.wl%randy@psg.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643C0769@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Randy Bush [mailto:randy at psg.com]
> Sent: 16 September 2011 16:05
> To: John Curran
> Cc: NANOG list
> Subject: Re: Disappointing ARIN - A great advertisement for the USA ?
> 
> > If you have a particular suggestion for changing whois, please
> > feel free to submit it.
> 
> simple.  don't.
> 
> if you want to do something new, don't call it whois.
> 
> randy
> 


Or call it whois and offer the service somewhere else.. Just not in a way that breaks everything.

--
Leigh




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From jcurran at arin.net  Fri Sep 16 10:35:47 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 16 Sep 2011 15:35:47 +0000
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643C0769@EALPO1.ukbroadband.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com>
 <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
 <m2y5xoedhw.wl%randy@psg.com>
 <D181DDABABE57E4DB72FEE00331478643C0769@EALPO1.ukbroadband.com>
Message-ID: <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>

On Sep 16, 2011, at 10:17 AM, Leigh Porter wrote:

> -----Original Message-----
>> From: Randy Bush [mailto:randy at psg.com]
>> Sent: 16 September 2011 16:05
>> To: John Curran
>> Cc: NANOG list
>> Subject: Re: Disappointing ARIN - A great advertisement for the USA ?
>> 
>>> If you have a particular suggestion for changing whois, please
>>> feel free to submit it.
>> 
>> simple.  don't.
>> 
>> if you want to do something new, don't call it whois.
>> 
>> randy
>> 
> 
> Or call it whois and offer the service somewhere else.. Just not in a way that breaks everything.

One approach would be the use of an option flag on the query to obtain 
the new hierarchical output  No flag = no output change.  Would that 
suffice?

/John

John Curran
President and CEO
ARIN



From ops.lists at gmail.com  Fri Sep 16 10:37:04 2011
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Fri, 16 Sep 2011 21:07:04 +0530
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com>
 <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
 <m2y5xoedhw.wl%randy@psg.com>
 <D181DDABABE57E4DB72FEE00331478643C0769@EALPO1.ukbroadband.com>
 <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>
Message-ID: <CAArzuotW78wK-98ScSkk20vGLiENAatY0RZc6ROf-Dr79abO8w@mail.gmail.com>

As the new arin whois is best suited for REST .. offer it only over
REST?  Queries from shell prompts can go on the same way they've gone
on for years.

On Fri, Sep 16, 2011 at 9:05 PM, John Curran <jcurran at arin.net> wrote:
>
> One approach would be the use of an option flag on the query to obtain
> the new hierarchical output ?No flag = no output change. ?Would that
> suffice?



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From randy at psg.com  Fri Sep 16 10:40:35 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 16 Sep 2011 17:40:35 +0200
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com>
 <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
 <m2y5xoedhw.wl%randy@psg.com>
 <D181DDABABE57E4DB72FEE00331478643C0769@EALPO1.ukbroadband.com>
 <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>
Message-ID: <m2sjnwebrg.wl%randy@psg.com>

> One approach would be the use of an option flag on the query to obtain 
> the new hierarchical output  No flag = no output change.  Would that 
> suffice?

how to do something new is best discussed by folk who want or need
something new, the folk with skin in the game.  so, though i have an
opinion that your suggestion seems reasonable at first blush, it is
worth the pixels on which it is printed.

what i care about is pola.  please do not change what works and which a
lot of fingers and scripts rely.

randy


From jcurran at arin.net  Fri Sep 16 10:44:58 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 16 Sep 2011 15:44:58 +0000
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <m2sjnwebrg.wl%randy@psg.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com>
 <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
 <m2y5xoedhw.wl%randy@psg.com>
 <D181DDABABE57E4DB72FEE00331478643C0769@EALPO1.ukbroadband.com>
 <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net> <m2sjnwebrg.wl%randy@psg.com>
Message-ID: <5C53830A-DC19-4BBF-B0D4-0BB204D3412E@arin.net>

On Sep 16, 2011, at 10:40 AM, Randy Bush wrote:

>> One approach would be the use of an option flag on the query to obtain 
>> the new hierarchical output  No flag = no output change.  Would that 
>> suffice?
> 
> how to do something new is best discussed by folk who want or need
> something new, the folk with skin in the game.  so, though i have an
> opinion that your suggestion seems reasonable at first blush, it is
> worth the pixels on which it is printed.
> 
> what i care about is pola.  please do not change what works and which a
> lot of fingers and scripts rely.

Randy - 
   
  Can you expand your response some?  I'm not certain I understand
  whether an option would suffice, nor the pola reference. I do get
  that we shouldn't be changing default output upon which scripts
  rely.

/John

John Curran
President and CEO
ARIN



From randy at psg.com  Fri Sep 16 10:53:50 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 16 Sep 2011 17:53:50 +0200
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <5C53830A-DC19-4BBF-B0D4-0BB204D3412E@arin.net>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com>
 <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
 <m2y5xoedhw.wl%randy@psg.com>
 <D181DDABABE57E4DB72FEE00331478643C0769@EALPO1.ukbroadband.com>
 <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>
 <m2sjnwebrg.wl%randy@psg.com>
 <5C53830A-DC19-4BBF-B0D4-0BB204D3412E@arin.net>
Message-ID: <m2r53geb5d.wl%randy@psg.com>

>>> One approach would be the use of an option flag on the query to obtain 
>>> the new hierarchical output  No flag = no output change.  Would that 
>>> suffice?
>> how to do something new is best discussed by folk who want or need
>> something new, the folk with skin in the game.  so, though i have an
>> opinion that your suggestion seems reasonable at first blush, it is
>> worth the pixels on which it is printed.
> Can you expand your response some?

yes i can inflate the syntax, but the semantics would be the same.

my opinion on how something new should be done is not highly relevant as
i am not invested in something new, have not looked deeply into what new
thing you want to do, ...  but if you insist on my stating an opinion,
then adding some optional and non-interfering syntactic sugar to the
whois query will likely not break people's fingers or scripts.

inflated enough for you?

> I'm not certain I understand whether an option would suffice

what i tried to say was neigher do i.  but i suspect it may.

> nor the pola reference.

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

i.e. it is what the users will bear :)

> I do get that we shouldn't be changing default output upon which
> scripts rely.

bingo!

randy


From rps at maine.edu  Fri Sep 16 10:57:50 2011
From: rps at maine.edu (Ray Soucy)
Date: Fri, 16 Sep 2011 11:57:50 -0400
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <1315885498.4599.204.camel@m6.u226.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <4E6EC8DB.4010602@rancid.berkeley.edu>
 <1315885498.4599.204.camel@m6.u226.com>
Message-ID: <CALFTrnPxSWMMvtZeQ+vG5VwSdZqR2H1sA9ZLB5tGzKKjpaz88Q@mail.gmail.com>

Saying NANOG = ARIN is like saying Middle East = Terrorist.  That kind
of generalization is never useful.  ARIN is one of many non-Government
organizations that make decisions regarding the Internet.

As for your reference to "Obama-style" I'm not sure if you're trying
to pay homage to, or insult the POTUS, either way it's not piratically
constructive to the conversation; especially on a technical mailing
list.  Please check politics at the door.

As mentioned by several others, if you have a problem with changes
made by ARIN, an independent non-profit corporation, then it seems
logical to contact them and not a community of network operators who
have little or no control over ARIN.

On Mon, Sep 12, 2011 at 11:44 PM, Always Learning <nanog at u61.u22.net> wrote:
>
> On Mon, 2011-09-12 at 20:07 -0700, Michael Sinatra wrote:
>
>> Unfortunately, the original poster, against advice given to him,
>> posted an insulting, jingoistic, inane, and even more derogatory
>> version of his NANOG post, apparently in an effort to spur discussion.
>> What was once a legitimate issue (and I agree one that needs to be
>> addressed) now looks more like troll-bait. ?Unsurprisingly, nobody has
>> responded.
>
> I was attempting to write in 'Obama-style'.
>
> I do make a perfectly valid point, perhaps oblivious to many North
> Americans who generally are insular, that the world does expect the
> Americans to do Internet things properly.
>
> Many North Americans appear not to understand the general world-wide
> attitude towards the USA. When something goes wrong at ARIN which
> affects American IPs, the world seems to blame the Americans. Although
> there is a clear distinction, certainly in my mind, between one rather
> small organisation and a state of circa 280 million, never-the-less the
> world generally blames the Americans. The only noticeable exception when
> the USA is not blamed for the faults and omissions of an American
> organisation is Micro$oft.
>
> Why does it take the concerns of an European to waken-up the Americans
> to the outstanding ARIN problem? ?Perhaps some of you can continue the
> campaign for the restoration of a basic North American WHOIS ? ?The rest
> of the world has a fully functioning WHOIS but not the USA (or Canada).
>
> My posting was never meant to be insulting or jingoistic or inane and
> certainly not derogatory. I was attempting to make those that can
> influence ARIN have some pride in presenting their country's
> achievements and services in the best possible way.
>
> Like it or not, the Americans run the Internet: Google (the world's
> biggest spying operation), Micro$oft, Facebook, Yahoo, Twitter, Ebay and
> their Paypal, Cisco etc. etc. and of course ARIN.
>
>> .... What was once a legitimate issue ....
>
> Remains "a legitimate issue" until ARIN resolves it, if ever.
>
>
> --
> With best regards,
>
> Paul.
> England,
> EU.
>
>
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From randy at psg.com  Fri Sep 16 11:11:24 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 16 Sep 2011 18:11:24 +0200
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CALFTrnPxSWMMvtZeQ+vG5VwSdZqR2H1sA9ZLB5tGzKKjpaz88Q@mail.gmail.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <4E6EC8DB.4010602@rancid.berkeley.edu>
 <1315885498.4599.204.camel@m6.u226.com>
 <CALFTrnPxSWMMvtZeQ+vG5VwSdZqR2H1sA9ZLB5tGzKKjpaz88Q@mail.gmail.com>
Message-ID: <m2iposeac3.wl%randy@psg.com>

> Saying NANOG = ARIN is like saying Middle East = Terrorist.  That kind
> of generalization is never useful.  ARIN is one of many non-Government
> organizations that make decisions regarding the Internet.
> 
> As for your reference to "Obama-style" I'm not sure if you're trying
> to pay homage to, or insult the POTUS, either way it's not piratically
> constructive to the conversation; especially on a technical mailing
> list.  Please check politics at the door.

qed, eh?

yes, the op conflated a bunch of crap with the valid technical problem
s/he raised.  but can the rest of us please try to stick to technalia?

> As mentioned by several others, if you have a problem with changes
> made by ARIN, an independent non-profit corporation, then it seems
> logical to contact them and not a community of network operators who
> have little or no control over ARIN.

arin says they serve the community.  this change affects the community,
they broke my fingers and a few scripts.  for others, such as suresh,
they broke a *lot* of software.

and discussing it here seems to be having useful effect, thanks john.

randy


From hasserw at hushmail.com  Fri Sep 16 13:10:29 2011
From: hasserw at hushmail.com (hasserw at hushmail.com)
Date: Fri, 16 Sep 2011 14:10:29 -0400
Subject: How to begin making my own ISP?
Message-ID: <20110916181029.24C11E671D@smtp.hushmail.com>

No one replied with any useful information. I guess no one wants 
competition on this list? Pretty poor tactic.

On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
>I want to begin making my own ISP, mainly for high speed servers 
>and such, but also branching out to residential customers. I'm 
>going to be in Germany for the next school year (probably either 
>Frankfurt am Main or Berlin); any suggestions on what sort of 
>classes I can take there that will be in English and will teach me 
>
>all I need to know on how to build and manage my own ISP, AS, etc? 
>
>Thanks.



From jra at baylink.com  Fri Sep 16 13:11:34 2011
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 16 Sep 2011 14:11:34 -0400 (EDT)
Subject: Summary: US Colo transit pricing
In-Reply-To: <5532443.1889.1316039877175.JavaMail.root@benjamin.baylink.com>
Message-ID: <28195505.2125.1316196694587.JavaMail.root@benjamin.baylink.com>

---- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>

> My thanks to the folks who took a moment to contribute; the outcome of my
> inquiry was "nah; I guess the price I got quoted really isn't all that bad,
> given the quality of the datacenter involved (which is quite nicely done).

And the fact that they don't charge cross connect fees; I just got back from
touring Equinix/S&D.  Plant's nice enough, especially if you need -48v...

but the cross-connect charges definitely put you in the "are you shopping
the right category of data center" picture: $500 setup, $225 for coax/325 for
fiber.  For an empty cable.  Yeah, I know, I know; being surprised at the
magnitude of that means this really is my first rodeo.  It had to happen
some time.  :-)

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      http://photo.imageinc.us             +1 727 647 1274


From EWieling at nyigc.com  Fri Sep 16 13:14:07 2011
From: EWieling at nyigc.com (Eric Wieling)
Date: Fri, 16 Sep 2011 14:14:07 -0400
Subject: How to begin making my own ISP?
In-Reply-To: <20110916181029.24C11E671D@smtp.hushmail.com>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
Message-ID: <C262B52114110B4586FAF49F074F05800D9691BD70@mailserver2007.nyigc.globe>

I think the question was far too vague.  The first thing you need to start an ISP is LOTS OF MONEY.  

-----Original Message-----
From: hasserw at hushmail.com [mailto:hasserw at hushmail.com] 
Sent: Friday, September 16, 2011 2:10 PM
To: nanog at nanog.org
Subject: Re: How to begin making my own ISP?

No one replied with any useful information. I guess no one wants competition on this list? Pretty poor tactic.

On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
>I want to begin making my own ISP, mainly for high speed servers and 
>such, but also branching out to residential customers. I'm going to be 
>in Germany for the next school year (probably either Frankfurt am Main 
>or Berlin); any suggestions on what sort of classes I can take there 
>that will be in English and will teach me
>
>all I need to know on how to build and manage my own ISP, AS, etc? 
>
>Thanks.



From eric at telic.us  Fri Sep 16 13:19:14 2011
From: eric at telic.us (Eric Krichbaum)
Date: Fri, 16 Sep 2011 13:19:14 -0500
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com> <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
 <m2y5xoedhw.wl%randy@psg.com>
 <D181DDABABE57E4DB72FEE00331478643C0769@EALPO1.ukbroadband.com>
 <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>
Message-ID: <06fa01cc749d$26863980$7392ac80$@telic.us>

-----Original Message-----
From: John Curran [mailto:jcurran at arin.net] 
Sent: Friday, September 16, 2011 10:36 AM
To: Leigh Porter
Cc: NANOG list
Subject: Re: Disappointing ARIN - A great advertisement for the USA ?

<snip>

>One approach would be the use of an option flag on the query to obtain the
new hierarchical output  No flag = no output change.  Would that suffice?

>/John

>John Curran
>President and CEO
>ARIN

I think so.  The flag that Mark sent me when I pinged you about this a while
ago doesn't work when it hits the rwhois server so the opposite would be
desirable.  Original display with no flag and flag for this current display
would put the scripts back into operation.

Eric






From mtinka at globaltransit.net  Fri Sep 16 13:11:24 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 17 Sep 2011 02:11:24 +0800
Subject: The Cidr Report - 4byte ASN handling
In-Reply-To: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661AFED@FHDP1LUMXC7V43.us.one.verizon.com>
References: <201109092200.p89M00vQ034172@wattle.apnic.net>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661AFED@FHDP1LUMXC7V43.us.one.verizon.com>
Message-ID: <201109170211.28305.mtinka@globaltransit.net>

On Friday, September 16, 2011 07:51:04 AM Schiller, Heather 
A wrote:

> I thought AS-plain notation was the standard for 4-byte
> ASN's?

as-plain is not the "standard" per se. Think of it more as 
the "preferred" option within the industry.

	o All major vendors support it, so there's no need
	  to convert to as-dot when you upgrade your router
	  software to support 4-byte ASN's.

	o as-plain doesn't break your AS_PATH regular
	  expressions, which is very useful.

	o as-plain is a known representation format among
	  operators, and 4-byte ASN's continuing this
	  tradition keeps the network stable.


as-dot notation looks really Cool & Sexy (tm), but is 
cumbersome for your AS_PATH regular expressions. It doesn't 
make things impossible, just, well, cumbersome :-).

Hope this helps.

Cheers,

Mark.	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110917/fda52677/attachment-0001.bin>

From MatlockK at exempla.org  Fri Sep 16 13:22:24 2011
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Fri, 16 Sep 2011 12:22:24 -0600
Subject: How to begin making my own ISP?
In-Reply-To: <C262B52114110B4586FAF49F074F05800D9691BD70@mailserver2007.nyigc.globe>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
 <C262B52114110B4586FAF49F074F05800D9691BD70@mailserver2007.nyigc.globe>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C710B045AF@LMC-MAIL2.exempla.org>

The second thing is that you need to have at least a VAGUE idea what you
want to actually offer.

A DSL ISP is VASTLY different than a Co-Location ISP. 

I'd say you need to sit down and take a long hard look at exactly you
want to do, *then* figure out what you need to do in order to accomplish
it. 

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk at exempla.org


-----Original Message-----
From: Eric Wieling [mailto:EWieling at nyigc.com] 
Sent: Friday, September 16, 2011 12:14 PM
To: hasserw at hushmail.com; nanog at nanog.org
Subject: RE: How to begin making my own ISP?

I think the question was far too vague.  The first thing you need to
start an ISP is LOTS OF MONEY.  

-----Original Message-----
From: hasserw at hushmail.com [mailto:hasserw at hushmail.com] 
Sent: Friday, September 16, 2011 2:10 PM
To: nanog at nanog.org
Subject: Re: How to begin making my own ISP?

No one replied with any useful information. I guess no one wants
competition on this list? Pretty poor tactic.

On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
>I want to begin making my own ISP, mainly for high speed servers and 
>such, but also branching out to residential customers. I'm going to be 
>in Germany for the next school year (probably either Frankfurt am Main 
>or Berlin); any suggestions on what sort of classes I can take there 
>that will be in English and will teach me
>
>all I need to know on how to build and manage my own ISP, AS, etc? 
>
>Thanks.


*** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice ***



From mikea at mikea.ath.cx  Fri Sep 16 13:24:11 2011
From: mikea at mikea.ath.cx (mikea)
Date: Fri, 16 Sep 2011 13:24:11 -0500
Subject: How to begin making my own ISP?
In-Reply-To: <20110916181029.24C11E671D@smtp.hushmail.com>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
Message-ID: <20110916182410.GA32073@mikea.ath.cx>

On Fri, Sep 16, 2011 at 02:10:29PM -0400, hasserw at hushmail.com wrote:
> No one replied with any useful information. I guess no one wants 
> competition on this list? Pretty poor tactic.
> 
> On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
> >I want to begin making my own ISP, mainly for high speed servers 
> >and such, but also branching out to residential customers. I'm 
> >going to be in Germany for the next school year (probably either 
> >Frankfurt am Main or Berlin); any suggestions on what sort of 
> >classes I can take there that will be in English and will teach me 
> >
> >all I need to know on how to build and manage my own ISP, AS, etc? 
> >
> >Thanks.

It's not safe to ass-u-me that absence of a reply is due to a desire to
avoid competition. I strongly suspect that the answer to your question is
very large, very complex, highly dependent on your location, business plan,
connectivity, and the like, and that people simply don't have the free time
to devote to tutoring you in how to build and run your startup. I know I
don't.

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


From jimmy.changa007 at gmail.com  Fri Sep 16 13:24:22 2011
From: jimmy.changa007 at gmail.com (Jimmy Changa)
Date: Fri, 16 Sep 2011 14:24:22 -0400
Subject: How to begin making my own ISP?
In-Reply-To: <20110916181029.24C11E671D@smtp.hushmail.com>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
Message-ID: <CAGSJx7v6g2xupK4T0_DNORPAeG6EDYs_0LwzvHizJYO92PhA8Q@mail.gmail.com>

Based on this email, I would suggest Marketing/PR classes ;)

Accounting?

On Fri, Sep 16, 2011 at 2:10 PM, <hasserw at hushmail.com> wrote:

> No one replied with any useful information. I guess no one wants
> competition on this list? Pretty poor tactic.
>
> On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
> >I want to begin making my own ISP, mainly for high speed servers
> >and such, but also branching out to residential customers. I'm
> >going to be in Germany for the next school year (probably either
> >Frankfurt am Main or Berlin); any suggestions on what sort of
> >classes I can take there that will be in English and will teach me
> >
> >all I need to know on how to build and manage my own ISP, AS, etc?
> >
> >Thanks.
>
>
>

From nanog at jima.tk  Fri Sep 16 13:38:55 2011
From: nanog at jima.tk (Jima)
Date: Fri, 16 Sep 2011 12:38:55 -0600 (MDT)
Subject: How to begin making my own ISP?
In-Reply-To: <20110916182410.GA32073@mikea.ath.cx>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
 <20110916182410.GA32073@mikea.ath.cx>
Message-ID: <45298.2001:470:e030:d000:28a7:bdff:fe11:8542.1316198335.squirrel@laughton.us>

On Fri, 16 Sep 2011, mikea wrote:
> On Fri, Sep 16, 2011 at 02:10:29PM -0400, hasserw at hushmail.com wrote:
>> No one replied with any useful information. I guess no one wants
>> competition on this list? Pretty poor tactic.
>
> It's not safe to ass-u-me that absence of a reply is due to a desire to
> avoid competition. I strongly suspect that the answer to your question is
> very large, very complex, highly dependent on your location, business
> plan,
> connectivity, and the like, and that people simply don't have the free
> time
> to devote to tutoring you in how to build and run your startup. I know I
> don't.

 Furthermore, it's a truly poor assumption that the larger portion of
starting one's own ISP is a purely technical exercise.  I'd say the
financial, political, and marketing aspects are far more daunting than
the nuts-n-bolts side of things.  However, if you really want to get
advice about the tech side of it, I'd consider looking for an internship
with an ISP.

 Of course, another possible mistake was to assume that the majority of
NANOG members work for ISPs (as such).  Other entities operate networks,
y'know.

     Jima



From skbohrer at simons-rock.edu  Fri Sep 16 13:42:52 2011
From: skbohrer at simons-rock.edu (Steve Bohrer)
Date: Fri, 16 Sep 2011 14:42:52 -0400
Subject: Traceroute losses through NYC1.gblx.net?
Message-ID: <CE188505-3E93-4F9E-94E2-C65EA0B7C7B7@simons-rock.edu>

My general question is "what meaning do I give to lossy traceroutes,  
even when pings show no problem."

Can I expect that backbone routers should never give me timeouts on a  
traceroute through them, so, lots of asterisks from these systems  
indicate a packet loss problem that needs to be fixed?

Or, are these traceroute asterisks essentially meaningless, and should  
be expected on any busy link?

More specifically, is anyone else getting lots of *s for NYC1.gblx.net  
for traceroutes through them? If I do three traceroutes through there,  
at least one will show losses at or beyond the NYC1 hops (and, the *s  
beyond NYC1 might be getting lost in NYC1, rather than indicating a  
different error).  But, Global Crossing's on-line tools don't show any  
loss.

I am at simons-rock.edu, in Western Mass, and we connect via Boston. A  
few days ago, our users of a database that's hosted at our parent  
campus, bard.edu, started complaining of many frequent (but  
intermittent) delays. Bard is in the Hudson Valley, and connects via  
Poughkeepsie. Both of our local providers connect to Global Crossing.  
Once before, we saw similar database symptoms, and that time, Bard had  
a problem dropping packets at their gateway. So I think these symptoms  
mean packet loss is happening somewhere. However, this time, pings  
from Simon's Rock to Bard, and vice-versa, show essentially no errors,  
typically 1000 pings will get through 100%.

Still, despite the good pings, traceroutes from either end show lots  
of asterisks at or after Global Crossing's NYC1.gblx.net links. I have  
opened a ticket with our provider, who has opened one with Global  
Crossing; and Bard has done the same with their end, but no  
significant response so far. (Bard's Graduate campus, located in New  
York City, is having similar poor database performance, so I'm pretty  
sure it is not just my end. Staff at the main Bard campus have no  
troubles, so it seems a network problem, not a server problem.)

As I understand it, an asterisk in traceroute means that the sending  
machine did not get any reply to a given packet. Since the traceroute  
packets have small TTL values, it expects to get a reply when the TTL  
is decremented to zero. But, I don't know if big routers are just lazy  
about sending such responses, or if these asterisks really indicate  
packets getting lost.  (As far as I remember in the past, when things  
work well, I never see *s at the central links, but, I have not really  
done any baseline testing of the link from here to Bard when the  
database was working.)

So, another question is why pings work so well when traceroutes work  
so poorly. (By experiment, I believe our database application performs  
more like traceroute than like ping.)  Is it packet size? Different  
handling for different sorts of traffic? Magic?

Here are some sample traceroutes each way:
Simon's Rock to Bard:

2h189:bin skbohrer$ traceroute -q5 -S bip.bard.edu
traceroute to bip.bard.edu (192.246.228.16), 64 hops max, 40 byte  
packets
  1  10.30.2.1 (10.30.2.1)  1.514 ms  1.791 ms  0.684 ms  0.761 ms   
0.712 ms (0% loss)
  2  michael.simons-rock.edu (208.81.88.1)  2.509 ms  1.882 ms  0.899  
ms  1.345 ms  2.057 ms (0% loss)
  3  64.213.79.249 (64.213.79.249)  104.294 ms  10.605 ms  17.106 ms   
18.987 ms  38.740 ms (0% loss)
  4  pos2-0-155M.cr2.BOS1.gblx.net (67.17.70.166)  21.962 ms  20.411  
ms  8.394 ms  23.308 ms  10.192 ms (0% loss)
  5  so1-2-0-2488M.scr2.NYC1.gblx.net (67.17.94.158)  15.738 ms   
14.582 ms  17.306 ms  24.444 ms  15.466 ms (0% loss)
  6  ae3-30g.scr3.NYC1.gblx.net (67.17.104.189)  15.586 ms  13.358 ms  
ae0-30G.scr4.NYC1.gblx.net (67.16.139.2)  13.875 ms  13.495 ms  12.780  
ms (0% loss)
  7  e5-1-30G.ar9.NYC1.gblx.net (67.16.142.54)  75.184 ms  
lag1.ar9.NYC1.gblx.net (67.16.142.50)  15.766 ms  11.947 ms *  
e5-1-30G.ar9.NYC1.gblx.net (67.16.142.54)  25.916 ms (20% loss)
  8  * * wbs-connect.gigabitethernet1-0-2.asr1.jfk1.gblx.net  
(64.211.195.6)  55.909 ms  73.803 ms * (60% loss)
  9  * pghknyshj42-xe-0-3-0.lightower.net (72.22.160.150)  16.521 ms   
21.817 ms  23.715 ms  17.236 ms (20% loss)
10  pghknyshj91-ae0-66.lightower.net (72.22.160.165)  76.257 ms   
27.712 ms  20.372 ms  18.923 ms  55.355 ms (0% loss)
11  kgtnnykgj91-ae3.66.lightower.net (72.22.160.107)  18.088 ms   
51.631 ms  19.052 ms  20.876 ms  22.942 ms (0% loss)
12  BardCollege-cust.customer.hvdata.net (64.72.66.234)  51.243 ms   
47.800 ms  32.835 ms  19.040 ms  55.661 ms (0% loss)
13  *^C


Bard to SR (their version of traceroute doen't have the handy -S  
option):

SRDB/users/usrsr/finrep: traceroute mail.simons-rock.edu
trying to get source for mail.simons-rock.edu
source should be 10.20.11.23
traceroute to hedwig.simons-rock.edu (208.81.88.14) from 10.20.11.23  
(10.20.11.23), 30 hops max
outgoing MTU = 1500
  1  hcrcgw (10.20.11.1)  1 ms  0 ms  0 ms
  2  hyphen (192.246.235.1)  1 ms  1 ms  1 ms
  3  BardCollege-hvdn.customer.hvdata.net (64.72.66.233)  1 ms  1 ms   
1 ms
  4  pghknyshj91-xe-5-2-0.lightower.net (72.22.160.106)  2 ms  2 ms  2  
ms
  5  pghknyshj42-ae0-66.lightower.net (72.22.160.159)  27 ms  2 ms  2 ms
  6  nycmnyzrj42-xe-0-3-0.lightower.net (72.22.160.151)  4 ms  4 ms  4  
ms
  7  ve463.ar9.NYC1.gblx.net (64.211.195.5)  4 ms  4 ms  4 ms
  8  * ae0-40G.scr1.NYC1.gblx.net (67.16.138.253)  4 ms  4 ms
  9  pos5-0-2488M.cr1.BOS1.gblx.net (67.17.94.57)  9 ms  
pos9-0-2488M.cr2.BOS1.gblx.net (67.17.94.157)  9 ms  11 ms
10  pos1-0-0-155M.ar1.BOS1.gblx.net (67.17.70.165)  14 ms  10 ms  9 ms
11  64.213.79.250 (64.213.79.250)  15 ms  15 ms  18 ms
^C


For more automated testing, I used -m10 to set the max hops so that  
the traces stop within the backbone network, as this avoids any issue  
of the boxes at the ends not really responding to traceroutes. That  
way, I could assume any * was a real time out. I also used -q4 for 4  
queries to each host. With a few hundred traceroutes each direction,  
more than 75% from SR to Bard, and more than 94% from Bard to SR,  
showed an asterisk at or past the NYC1 hops. There were zero asterisks  
on the links before NYC1 from either side.

Thanks for any insights.

Steve Bohrer
Network Administrator
ITS, Bard College at Simon's Rock
413-528-7645





From bmanning at vacation.karoshi.com  Fri Sep 16 13:42:18 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 16 Sep 2011 18:42:18 +0000
Subject: How to begin making my own ISP?
In-Reply-To: <20110916181029.24C11E671D@smtp.hushmail.com>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
Message-ID: <20110916184218.GA17456@vacation.karoshi.com.>

On Fri, Sep 16, 2011 at 02:10:29PM -0400, hasserw at hushmail.com wrote:
> No one replied with any useful information. I guess no one wants 
> competition on this list? Pretty poor tactic.
> 
> On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
> >I want to begin making my own ISP, mainly for high speed servers 
> >and such, but also branching out to residential customers. I'm 
> >going to be in Germany for the next school year (probably either 
> >Frankfurt am Main or Berlin); any suggestions on what sort of 
> >classes I can take there that will be in English and will teach me 
> >
> >all I need to know on how to build and manage my own ISP, AS, etc? 
> >
> >Thanks.
> 

	"... First,  You make a roux!"  - Julia Childs

Clearly its not a easy/simple as it used to be but its not rocket science either.

you have to decide where you want to start;   eyeballs, content, or get others to defray 
the cost of yur access.

Once you select which target you are after, then you can pick your gear.  I am going to
presume OSS and fully depricated kit to keep your costs down and to boost your learning
skills.

On the presumption you want to run BGP I suggest you invest in some colo space at/near
a public internet exchange w/ a large number of players..  SIX was good, Telx was good,
and the S&D pops were as well - at least four/five years ago.

slip you old HP laptop into the rack and buy a cross connect to the exchange fabric.
replace the OS on the laptop w/ FreeBSD or CentOS, from ports, add SSH and Quagga.

Chat up potential peers at the exchange and see whom will peer w/ you using a Private ASN.

Contact ARIN or third party broker to lease some IP space and an ASN.  If you can't find/justify
the resources 'cause your just starting out,  there is private space and private ASN.

Configure Quagga w/ the obtained ASN and announce the IP prefix(es).


TaDa ...  You are an ISP!

/bill


From henry at AegisInfoSys.com  Fri Sep 16 13:45:12 2011
From: henry at AegisInfoSys.com (Henry Yen)
Date: Fri, 16 Sep 2011 14:45:12 -0400
Subject: How to begin making my own ISP?
In-Reply-To: <20110911015501.1DC2BE671D@smtp.hushmail.com>
References: <20110911015501.1DC2BE671D@smtp.hushmail.com>
Message-ID: <20110916184512.GX6006@nntp.AegisInfoSys.com>

On Sat, Sep 10, 2011 at 21:55:01PM -0400, hasserw at hushmail.com wrote:
> I want to begin making my own ISP, mainly for high speed servers 
> and such, but also branching out to residential customers. I'm 
> going to be in Germany for the next school year (probably either 
> Frankfurt am Main or Berlin); any suggestions on what sort of 
> classes I can take there that will be in English and will teach me 
> all I need to know on how to build and manage my own ISP, AS, etc? 

Whatever you do, I think you should avoid sending spam when soliciting
your services, like this one:

  Received: from mail.brighttelecom.net(96.125.175.69), claiming to be "voiceanddata.brighttelecom.net"
   via SMTP by NGW.AegisInfoSys.com, id smtpdQ7Nl4c; Fri, 16 Sep 2011 14:29:01 -0400
  Date: Fri, 16 Sep 2011 18:28:53 GMT
  From: brian at brighttelecom.net (Bright Telecom)

-- 
Henry Yen                                       Aegis Information Systems, Inc.
Senior Systems Programmer                       Hicksville, New York


From jared at puck.nether.net  Fri Sep 16 13:50:28 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 16 Sep 2011 14:50:28 -0400
Subject: Traceroute losses through NYC1.gblx.net?
In-Reply-To: <CE188505-3E93-4F9E-94E2-C65EA0B7C7B7@simons-rock.edu>
References: <CE188505-3E93-4F9E-94E2-C65EA0B7C7B7@simons-rock.edu>
Message-ID: <D8E49131-42C9-4303-8867-C729CEFCE330@puck.nether.net>


On Sep 16, 2011, at 2:42 PM, Steve Bohrer wrote:

> My general question is "what meaning do I give to lossy traceroutes, even when pings show no problem."
> 
> Can I expect that backbone routers should never give me timeouts on a traceroute through them, so, lots of asterisks from these systems indicate a packet loss problem that needs to be fixed?
> 
> Or, are these traceroute asterisks essentially meaningless, and should be expected on any busy link?

Basically, you should expect timeouts in the middle of the path from any large network from time-to-time.

It could be for any number of reasons, ddos, control-plane "busyness", etc..

There was even a provider that once limited the ability for people to see inside their network.

The true tests are always end-to-end tests.  I recommend having a host at each end that you can run pings or iperf from.  This will aide you greatly in diagnosing the trouble.  Traceroute (or, more specifically TTL expiry handling by a multipurpose device) is often lower on the priority list than things to keep the element "alive and operational".

Your outputs showed good results on each end of the path, meaning that the device was perhaps rate-limiting the TTL expiry traffic or had something else going on.

- Jared

From morrowc.lists at gmail.com  Fri Sep 16 13:53:17 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 16 Sep 2011 14:53:17 -0400
Subject: Traceroute losses through NYC1.gblx.net?
In-Reply-To: <CE188505-3E93-4F9E-94E2-C65EA0B7C7B7@simons-rock.edu>
References: <CE188505-3E93-4F9E-94E2-C65EA0B7C7B7@simons-rock.edu>
Message-ID: <CAL9jLaZk7Ofw9io4Knh6jCk=eq1RpMo0iEgnibhGkdUEZDmgng@mail.gmail.com>

On Fri, Sep 16, 2011 at 2:42 PM, Steve Bohrer <skbohrer at simons-rock.edu> wrote:

> Can I expect that backbone routers should never give me timeouts on a
> traceroute through them, so, lots of asterisks from these systems indicate a
> packet loss problem that needs to be fixed?

something inside the router has to make the icmp-unreachable-ttl-expired, right?
perhaps that thing is rate-limited (in hardware/software) so that a
line-rate flood of ttl=1 packets won't induce an outbound dos attack
effect?

perhaps that is a shared resource among all of the ports on the
pic/card/chassis?

perhaps the function that does this does more than just make
ttl-expired? (other error codes or other ancillary functions)

> Or, are these traceroute asterisks essentially meaningless, and should be
> expected on any busy link?

think router not link, but.... probably less important that you don't
see ttl-expired messages, but that you do see no packet
loss/mal-effects with the protocols you care about (ping? http? smtp?)

it's also possible that the destination has requested gblx to filter
udp toward it (depending on what sort of a day they are having and how
much fun gblx wants to incur)

-chris


From bmanning at vacation.karoshi.com  Fri Sep 16 13:53:11 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 16 Sep 2011 18:53:11 +0000
Subject: How to begin making my own ISP?
In-Reply-To: <20110916181029.24C11E671D@smtp.hushmail.com>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
Message-ID: <20110916185311.GB17456@vacation.karoshi.com.>

On Fri, Sep 16, 2011 at 02:10:29PM -0400, hasserw at hushmail.com wrote:
> No one replied with any useful information. I guess no one wants 
> competition on this list? Pretty poor tactic.
> 
> On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
> >I want to begin making my own ISP, mainly for high speed servers 
> >and such, but also branching out to residential customers. I'm 
> >going to be in Germany for the next school year (probably either 
> >Frankfurt am Main or Berlin); any suggestions on what sort of 
> >classes I can take there that will be in English and will teach me 
> >
> >all I need to know on how to build and manage my own ISP, AS, etc? 
> >
> >Thanks.
> 

	What they said.  

	However - this is the NANOG list, not the EOF.  If you
	are going to play in the EU space, you should ask there.
	
	Also - if you are just playing w/ nuts/bolts - a valuable 
	resource is the NSRC site.  They do excellent work in 
	helping the technology challanged understand and deploy
	communications systems.

	http://www.nsrc.org/

	you might also want to talk to the DENIC folks and likely RIPE NCC.

	http://www.ripe.net
	http://ww.denic.de

	Good Luck, you wet-behind-the-ears whippersnapper.  

/bill


From Valdis.Kletnieks at vt.edu  Fri Sep 16 13:53:03 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 16 Sep 2011 14:53:03 -0400
Subject: How to begin making my own ISP?
In-Reply-To: Your message of "Fri, 16 Sep 2011 18:42:18 -0000."
 <20110916184218.GA17456@vacation.karoshi.com>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
 <20110916184218.GA17456@vacation.karoshi.com>
Message-ID: <61195.1316199183@turing-police.cc.vt.edu>

On Fri, 16 Sep 2011 18:42:18 -0000, bmanning at vacation.karoshi.com said:
> Configure Quagga w/ the obtained ASN and announce the IP prefix(es).

> TaDa ...  You are an ISP!

Now all you need is a business plan that pays for the rack space. ;)

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

From bmanning at vacation.karoshi.com  Fri Sep 16 13:58:36 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 16 Sep 2011 18:58:36 +0000
Subject: How to begin making my own ISP?
In-Reply-To: <61195.1316199183@turing-police.cc.vt.edu>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
 <20110916184218.GA17456@vacation.karoshi.com>
 <61195.1316199183@turing-police.cc.vt.edu>
Message-ID: <20110916185836.GC17456@vacation.karoshi.com.>

On Fri, Sep 16, 2011 at 02:53:03PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 16 Sep 2011 18:42:18 -0000, bmanning at vacation.karoshi.com said:
> > Configure Quagga w/ the obtained ASN and announce the IP prefix(es).
> 
> > TaDa ...  You are an ISP!
> 
> Now all you need is a business plan that pays for the rack space. ;)
> 

	and the Internet Numbering resource fees, the cross connects, power,
	spares, ...  and if you tak in money,  insurance, taxes, accounting,
	sys-admin costs (unless this is best-effort service that yu can 
	"fire & forget" or your paying clients don't care when you are down 
	for three weeks - looking for replacement kit and the time to configure
	it -after- your homework is done...)

	But this song isnt about Alice...

/bill



From dr at cluenet.de  Fri Sep 16 14:16:01 2011
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 16 Sep 2011 21:16:01 +0200
Subject: The Cidr Report - 4byte ASN handling
In-Reply-To: <201109170211.28305.mtinka@globaltransit.net>
References: <201109092200.p89M00vQ034172@wattle.apnic.net>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661AFED@FHDP1LUMXC7V43.us.one.verizon.com>
 <201109170211.28305.mtinka@globaltransit.net>
Message-ID: <20110916191601.GA2118@srv03.cluenet.de>

On Sat, Sep 17, 2011 at 02:11:24AM +0800, Mark Tinka wrote:
> > I thought AS-plain notation was the standard for 4-byte
> > ASN's?
> 
> as-plain is not the "standard" per se.

RFC5396 on as-plain is on track becoming one.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From cscora at apnic.net  Fri Sep 16 14:21:31 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 17 Sep 2011 05:21:31 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201109161921.p8GJLV9G007596@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,
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 17 Sep, 2011

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

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

BGP routing table entries examined:                              371690
    Prefixes after maximum aggregation:                          167917
    Deaggregation factor:                                          2.21
    Unique aggregates announced to Internet:                     184823
Total ASes present in the Internet Routing Table:                 38823
    Prefixes per ASN:                                              9.57
Origin-only ASes present in the Internet Routing Table:           32200
Origin ASes announcing only one prefix:                           15478
Transit ASes present in the Internet Routing Table:                5208
Transit-only ASes present in the Internet Routing Table:            134
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      36
    Max AS path prepend of ASN (22394)                               33
Prefixes from unregistered ASNs in the Routing Table:              1319
    Unregistered ASNs in the Routing Table:                         742
Number of 32-bit ASNs allocated by the RIRs:                       1739
Number of 32-bit ASNs visible in the Routing Table:                1415
Prefixes from 32-bit ASNs in the Routing Table:                    3247
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            111
Number of addresses announced to Internet:                   2477780352
    Equivalent to 147 /8s, 175 /16s and 237 /24s
    Percentage of available address space announced:               66.9
    Percentage of allocated address space announced:               66.9
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               91.3
Total number of prefixes smaller than registry allocations:      154979

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

Prefixes being announced by APNIC Region ASes:                    93491
    Total APNIC prefixes after maximum aggregation:               30741
    APNIC Deaggregation factor:                                    3.04
Prefixes being announced from the APNIC address blocks:           90025
    Unique aggregates announced from the APNIC address blocks:    38232
APNIC Region origin ASes present in the Internet Routing Table:    4567
    APNIC Prefixes per ASN:                                       19.71
APNIC Region origin ASes announcing only one prefix:               1258
APNIC Region transit ASes present in the Internet Routing Table:    710
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         21
Number of APNIC region 32-bit ASNs visible in the Routing Table:     88
Number of APNIC addresses announced to Internet:              627559520
    Equivalent to 37 /8s, 103 /16s and 204 /24s
    Percentage of available APNIC address space announced:         79.6

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
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, 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:                    143323
    Total ARIN prefixes after maximum aggregation:                73655
    ARIN Deaggregation factor:                                     1.95
Prefixes being announced from the ARIN address blocks:           115248
    Unique aggregates announced from the ARIN address blocks:     47939
ARIN Region origin ASes present in the Internet Routing Table:    14662
    ARIN Prefixes per ASN:                                         7.86
ARIN Region origin ASes announcing only one prefix:                5652
ARIN Region transit ASes present in the Internet Routing Table:    1553
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          36
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               804847104
    Equivalent to 47 /8s, 248 /16s and 254 /24s
    Percentage of available ARIN address space announced:          64.0

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, 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, 173/8,
                       174/8, 184/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:                     88191
    Total RIPE prefixes after maximum aggregation:                50131
    RIPE Deaggregation factor:                                     1.76
Prefixes being announced from the RIPE address blocks:            81218
    Unique aggregates announced from the RIPE address blocks:     53898
RIPE Region origin ASes present in the Internet Routing Table:    15982
    RIPE Prefixes per ASN:                                         5.08
RIPE Region origin ASes announcing only one prefix:                7963
RIPE Region transit ASes present in the Internet Routing Table:    2501
Average RIPE Region AS path length visible:                         4.6
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1003
Number of RIPE addresses announced to Internet:               488917248
    Equivalent to 29 /8s, 36 /16s and 73 /24s
    Percentage of available RIPE address space announced:          78.8

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
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,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   34743
    Total LACNIC prefixes after maximum aggregation:               7768
    LACNIC Deaggregation factor:                                   4.47
Prefixes being announced from the LACNIC address blocks:          34025
    Unique aggregates announced from the LACNIC address blocks:   17820
LACNIC Region origin ASes present in the Internet Routing Table:   1527
    LACNIC Prefixes per ASN:                                      22.28
LACNIC Region origin ASes announcing only one prefix:               451
LACNIC Region transit ASes present in the Internet Routing Table:   273
Average LACNIC Region AS path length visible:                       4.4
    Max LACNIC Region AS path length visible:                        19
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   308
Number of LACNIC addresses announced to Internet:              89082496
    Equivalent to 5 /8s, 79 /16s and 74 /24s
    Percentage of available LACNIC address space announced:        59.0

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8517
    Total AfriNIC prefixes after maximum aggregation:              2026
    AfriNIC Deaggregation factor:                                  4.20
Prefixes being announced from the AfriNIC address blocks:          6597
    Unique aggregates announced from the AfriNIC address blocks:   2037
AfriNIC Region origin ASes present in the Internet Routing Table:   486
    AfriNIC Prefixes per ASN:                                     13.57
AfriNIC Region origin ASes announcing only one prefix:              154
AfriNIC Region transit ASes present in the Internet Routing Table:  105
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             27220736
    Equivalent to 1 /8s, 159 /16s and 91 /24s
    Percentage of available AfriNIC address space announced:       40.6

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2508      11047         955   Korea Telecom (KIX)
17974     2010        516          31   PT TELEKOMUNIKASI INDONESIA
 7545     1597        303          85   TPG Internet Pty Ltd
 4755     1548        639         170   TATA Communications formerly 
24560     1182        337         194   Bharti Airtel Ltd., Telemedia
 9829     1155        989          28   BSNL National Internet Backbo
 9583     1078         80         505   Sify Limited
 4808     1069       2088         302   CNCGROUP IP network: China169
 7552      978       1062          11   Vietel Corporation
17488      957        189         159   Hathway IP Over Cable Interne

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     3563       3817         226   bellsouth.net, inc. 
18566     1912        364         237   Covad Communications 
 1785     1820        680         122   PaeTec Communications, Inc.
 4323     1626       1085         393   Time Warner Telecom
 7029     1608       1008         195   Windstream Communications Inc
20115     1595       1542         634   Charter Communications 
22773     1455       2906          99   Cox Communications, Inc.
30036     1423        263         688   Mediacom Communications Corp 
19262     1395       4724         399   Verizon Global Networks 
 7018     1331       7050         869   AT&T WorldNet Services

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

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
34984      559        108         179   BILISIM TELEKOM
 6830      524       1811         322   UPC Distribution Services
20940      515        166         401   Akamai Technologies European 
 3292      472       2080         404   TDC Tele Danmark
12479      472        594           8   Uni2 Autonomous System
 8866      460        133          26   Bulgarian Telecommunication C
 3320      432       8152         376   Deutsche Telekom AG
29049      424         31          55   AzerSat LLC.
 8402      415        352          13   Corbina telecom
 8551      403        354          44   Bezeq International

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

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1675        308         159   TVCABLE BOGOTA 
 8151     1409       2802         355   UniNet S.A. de C.V. 
28573     1351       1012          68   NET Servicos de Comunicao S.A
 7303     1156        678         170   Telecom Argentina Stet-France
14420      730         57          92   CORPORACION NACIONAL DE TELEC
 6503      580        450          68   AVANTEL, S.A. 
22047      579        322          17   VTR PUNTO NET S.A. 
27947      568         55          82   Telconet S.A
 3816      535        232          98   Empresa Nacional de Telecomun
11172      516         85          91   Servicios Alestra S.A de C.V 

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

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863      813        147          43   LINKdotNET AS number
 8452      698        445          11   TEDATA
15475      513         74           8   Nile Online
36992      308        415          14   Etisalat MISR
 3741      267        938         228   The Internet Solution 
 6713      242        519          14   Itissalat Al-MAGHRIB
33776      239         13           8   Starcomms Nigeria Limited
15706      219         32           6   Sudatel Internet Exchange Aut
12258      198         28          58   Vodacom Internet Company 
29571      198         17          13   Ci Telecom Autonomous system 

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
 6389     3563       3817         226   bellsouth.net, inc. 
23456     3247        770        1753   32-bit ASN transition
 4766     2508      11047         955   Korea Telecom (KIX)
17974     2010        516          31   PT TELEKOMUNIKASI INDONESIA
18566     1912        364         237   Covad Communications 
 1785     1820        680         122   PaeTec Communications, Inc.
10620     1675        308         159   TVCABLE BOGOTA 
 4323     1626       1085         393   Time Warner Telecom
 7029     1608       1008         195   Windstream Communications Inc
 7545     1597        303          85   TPG Internet Pty Ltd

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

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

  ASN   No of nets  Net Savings Description
17974      2010        1979      PT TELEKOMUNIKASI INDONESIA
 1785      1820        1698      PaeTec Communications, Inc.
18566      1912        1675      Covad Communications 
 4766      2508        1553      Korea Telecom (KIX)
10620      1675        1516      TVCABLE BOGOTA 
 7545      1597        1512      TPG Internet Pty Ltd
23456      3247        1494      32-bit ASN transition
 7029      1608        1413      Windstream Communications Inc
 4755      1548        1378      TATA Communications formerly 
22773      1455        1356      Cox Communications, Inc.

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
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
26973   UNALLOCATED  12.39.152.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.154.0/23        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.155.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.159.0/24        7018       AT&T WorldNet Servic
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic

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

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

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
41.222.79.0/24       36938     >>UNKNOWN<<
41.223.92.0/22       36936     >>UNKNOWN<<
46.18.104.0/21       23456     32-bit ASN transition
50.115.128.0/21      20248     Take 2 Hosting, Inc. 

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:19       /9:12      /10:27      /11:81      /12:235     
/13:464     /14:800     /15:1411    /16:11970   /17:5965    /18:10012   
/19:19731   /20:26875   /21:26973   /22:36182   /23:34758   /24:192858  
/25:1105    /26:1294    /27:744     /28:165     /29:4       /30:0       
/31:0       /32:5       

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

  ASN   No of nets  Total ann.   Description
 6389     2200          3563      bellsouth.net, inc. 
18566     1868          1912      Covad Communications 
23456     1571          3247      32-bit ASN transition
10620     1570          1675      TVCABLE BOGOTA 
30036     1381          1423      Mediacom Communications Corp 
 7029     1308          1608      Windstream Communications Inc
11492     1114          1152      Cable One 
 7011     1058          1183      Citizens Utilities 
 1785     1052          1820      PaeTec Communications, Inc.
22773      945          1455      Cox Communications, Inc.

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

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

   1:372       2:52        4:15        5:1         6:3         8:351    
  12:1951     13:1        14:540      15:13       16:3        17:5      
  20:10       23:32       24:1678     27:940      31:530      32:64     
  33:4        34:2        36:4        38:742      40:108      41:2576   
  42:48       44:3        46:983      47:3        49:243      50:419    
  52:13       54:2        55:5        56:2        57:35       58:876    
  59:501      60:376      61:1175     62:1088     63:1944     64:4047   
  65:2300     66:3928     67:1939     68:1100     69:3174     70:783    
  71:377      72:1859     74:2437     75:315      76:339      77:870    
  78:665      79:469      80:1122     81:839      82:503      83:499    
  84:687      85:1086     86:410      87:869      88:347      89:1535   
  90:234      91:4088     92:527      93:1150     94:1331     95:791    
  96:437      97:272      98:932      99:37      101:207     103:301    
 106:94      107:44      108:76      109:1017    110:668     111:784    
 112:313     113:440     114:566     115:685     116:922     117:680    
 118:891     119:1199    120:338     121:685     122:1602    123:1015   
 124:1355    125:1354    128:248     129:179     130:167     131:577    
 132:120     133:21      134:215     135:53      136:212     137:137    
 138:294     139:108     140:493     141:288     142:389     143:407    
 144:483     145:61      146:468     147:214     148:636     149:251    
 150:153     151:190     152:452     153:177     154:6       155:390    
 156:202     157:356     158:144     159:461     160:324     161:207    
 162:334     163:176     164:508     165:372     166:536     167:433    
 168:747     169:146     170:860     171:84      172:4       173:1639   
 174:628     175:393     176:176     177:251     178:999     180:1067   
 181:26      182:616     183:237     184:366     185:1       186:1440   
 187:667     188:938     189:872     190:5156    192:5911    193:5005   
 194:3522    195:3057    196:1251    197:148     198:3591    199:4101   
 200:5514    201:1636    202:8528    203:8484    204:4251    205:2333   
 206:2667    207:2829    208:4032    209:3457    210:2693    211:1467   
 212:2088    213:1768    214:784     215:75      216:4849    217:1610   
 218:552     219:333     220:1197    221:514     222:343     223:266    


End of report


From charles at knownelement.com  Fri Sep 16 14:45:33 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Fri, 16 Sep 2011 14:45:33 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
Message-ID: <4E73A75D.50002@knownelement.com>



Wow this turned into a very long post....

On 09/16/2011 01:10 PM, hasserw at hushmail.com wrote:
> No one replied with any useful information. I guess no one wants
> competition on this list? Pretty poor tactic.
>
> On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
>

Mr hasserw at husmail.com, the net is big enough for many forms of networks 
and competition to exist. The fact that you write from a hushmail 
address is intriguing to me. That may have kept others from answering 
entirely.

Using ones real name/personal e-mail address builds a reputation. It 
also helps if you've posted other threads in the past. Looking over my 
post history (both replies and  threads i started), one will see a 
progression of learning and participation. I don't recall seeing any 
posts from you in the past. As such, it may not have been wise to burst 
onto the scene and say "please to do my homework for me".  Contributing 
to a few threads, starting a couple of your own (on a more specific 
subject) and saying "this is what I'm planning to do, here is what I've 
researched, please tell me if I'm doing it horribly wrong" is a good way 
to start in any community.

I had high hopes for the thread you had started, but am disappointed by 
the somewhat juvenile response that you sent. I believe you killed off 
the opportunity for some excellent discussion. So I'm starting another 
one, in the event people are ignoring the previous thread. Plus my title 
is cooler!

I did learn some things from that thread (such as nsrc.org). Thank you 
for posting those links and inspiring the title of this thread Bill.

In my case, I have knowledge (through consuming way too much *NOG lists 
and other resources). However all of my experience is in data 
center/enterprise LAN networking. WAN experience is limited to default 
BGP route delivery or statically configured links. So I have never built 
an ISP network before.  I want to join the community, and as such am 
seeking advice before I blindly go off and end up being one of "those" 
AS. :)


Here is what I am doing and how I plan to go about doing it. Feedback 
most welcome. Please be critical but polite. :)

The previous thread mentioned business plan. That's absolutely critical. 
Competing on delivering the Internet is foolish at this point in the 
game. I'm giving net access away for free, and making money off of hyper 
localized advertising). I'm also using existing co location facilities 
and networks.

Looking over my linked in profile will demonstrate my existing expertise 
on the business and tech side of both online and hyper local 
advertising, and large scale, distributed server operations.  However 
I'm currently not experienced on the network build out side. I figured 
the only way to get the level of experience I want, is to build a 
service provider network.

I'm in the process of building out a backbone network across the United 
States. Starting off small  (3 points of presence: 600 West 7th st Los 
Angeles, 60 hudson NYC , 324 E 11th KC MO). In two cases I'm leveraging 
existing relationships with strong WAN engineers who will be receiving 
some equity in my startup, in one I'm a new customer off the street and 
doing everything myself other then the basic colo services (net drop, 
power, cooling, security, smart hands).

This backbone network will be used to terminate regional wireless 
networks. The wireless networks are being funded by the communities that 
the network serves through direct donations and by hyper localized 
advertising sales.

So here we go with technical nuts/bolts of the plan (as bill so 
eloquently put it):
"I am going to presume OSS and fully depricated kit to keep your costs 
down and to boost your learning skills."

Something like that.

1) Obtain ASN from ARIN (using LOA from existing upstream relationships).

2) Obtain ipv6 space from ARIN (inquired about getting space and ran 
into some issues. need to speak with my co founder and get details. 
evidently getting brand new v6 space for a brand new network is fairly 
difficult. for now may just announce a /48 from he.net. ) Yes I did come 
up with a sub netting plan for the entire United States out of a single 
/48. It's quite ingenious really. More details on request if anyone 
wants them.

3) Announce prefixes from initial point of presence locations for 
availability / traffic engineering reasons. Using a mix of Quagga on 
Linux virtual machiens, pfSense on dell servers and Cisco gear.

So more or less the steps that Bill mentioned in his response. It was 
somewhat tongue in cheek, but also quite accurate.  I'm bootstrapping 
with personal funds / gear at the moment. However I believe it can be 
"done right". I also have a fair amount of gear I've been obtaining over 
the past few years with the specific intent of building an ISP. The 
business plan has evolved over time. It's now at a rather mature point, 
and it's time to get my hands dirty.

Whew. Sorry for the long post. Hopefully folks will read it. :)


From leigh.porter at ukbroadband.com  Fri Sep 16 14:58:30 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 16 Sep 2011 19:58:30 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <4E73A75D.50002@knownelement.com>
References: <4E73A75D.50002@knownelement.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Charles N Wyble [mailto:charles at knownelement.com]
> Sent: 16 September 2011 20:47
> To: nanog at nanog.org
> Subject: wet-behind-the-ears whippersnapper seeking advice on building
> a nationwide network
> 
> 
> 
> Wow this turned into a very long post....
> 
> On 09/16/2011 01:10 PM, hasserw at hushmail.com wrote:
> > No one replied with any useful information. I guess no one wants
> > competition on this list? Pretty poor tactic.
> >
> > On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
> >
> 
> 
> 2) Obtain ipv6 space from ARIN (inquired about getting space and ran
> into some issues. need to speak with my co founder and get details.
> evidently getting brand new v6 space for a brand new network is fairly
> difficult. for now may just announce a /48 from he.net. ) Yes I did
> come
> up with a sub netting plan for the entire United States out of a single
> /48. It's quite ingenious really. More details on request if anyone
> wants them.
> 


I wonder what would happen if a new ARIN member requested an IPv4 block of say a /16 for a new business? Or even a smaller block. I don't know what the current ARIN rules are but RIPE will currently give out six months worth of space. Now, in six months, I don't expect there to be any left anyway, so what will likely be all the v4 you ever get.

Very soon it'll be nigh on impossible for new entrants to the ISP business to get their own v4 space.

--
Leigh




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From charles at knownelement.com  Fri Sep 16 15:01:58 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Fri, 16 Sep 2011 15:01:58 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
References: <4E73A75D.50002@knownelement.com>
 <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
Message-ID: <4E73AB36.10204@knownelement.com>

On 09/16/2011 02:58 PM, Leigh Porter wrote:
>
>> -----Original Message-----
>> From: Charles N Wyble [mailto:charles at knownelement.com]
>> Sent: 16 September 2011 20:47
>> To: nanog at nanog.org
>> Subject: wet-behind-the-ears whippersnapper seeking advice on building
>> a nationwide network
>>
>>
>>
>> Wow this turned into a very long post....
>>
>> On 09/16/2011 01:10 PM, hasserw at hushmail.com wrote:
>>> No one replied with any useful information. I guess no one wants
>>> competition on this list? Pretty poor tactic.
>>>
>>> On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
>>>
>>
>> 2) Obtain ipv6 space from ARIN (inquired about getting space and ran
>> into some issues. need to speak with my co founder and get details.
>> evidently getting brand new v6 space for a brand new network is fairly
>> difficult. for now may just announce a /48 from he.net. ) Yes I did
>> come
>> up with a sub netting plan for the entire United States out of a single
>> /48. It's quite ingenious really. More details on request if anyone
>> wants them.
>>
>
> I wonder what would happen if a new ARIN member requested an IPv4 block of say a /16 for a new business? Or even a smaller block. I don't know what the current ARIN rules are but RIPE will currently give out six months worth of space. Now, in six months, I don't expect there to be any left anyway, so what will likely be all the v4 you ever get.

Hah. True.

I actually don't want any v4 space at all. I'm fine with using provider 
space for my minimal v4 needs. However I believe if I had existing v4 
space, that v6 space would be easier to obtain.

> Very soon it'll be nigh on impossible for new entrants to the ISP business to get their own v4 space.

Indeed.

In my case, I'm perfectly happy with v6 space. Can have very minimal v4 
space for the time being. Google/netflix/facebook are reachable on v6. 
This is the vast majority of the net traffic. I can do large scale nat 
for v4 only content.

One aspect of my network, will be operational transparency. So as much 
as possible will be viewable in real time. This includes v4/v6 traffic 
statistics.

Also we do plan to expand into Europe and Asia. We are starting in the 
US first due to the relationships we have already established. If anyone 
is interested in supporting our activities in Europe, please let me know.

By our/we, I mean http://freenetworkfoundation.org/ (that's the non 
profit piece. the advertising part is separate but will help fund the 
non profit piece). Lots of dual use work being done.


From bmanning at vacation.karoshi.com  Fri Sep 16 15:05:37 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 16 Sep 2011 20:05:37 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
References: <4E73A75D.50002@knownelement.com>
 <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
Message-ID: <20110916200537.GD17456@vacation.karoshi.com.>

On Fri, Sep 16, 2011 at 07:58:30PM +0000, Leigh Porter wrote:
> 
> I wonder what would happen if a new ARIN member requested an IPv4 block of say a /16 for a new business? Or even a smaller block. I don't know what the current ARIN rules are but RIPE will currently give out six months worth of space. Now, in six months, I don't expect there to be any left anyway, so what will likely be all the v4 you ever get.
> 
> Very soon it'll be nigh on impossible for new entrants to the ISP business to get their own v4 space.
> 
> --
> Leigh

	a new entrant in the ARIN service region would have to meet the allocation criteria as
	specified in current policy.  Same w/ any RIR.   If the RIPE region policy is to hand
	out a six month supply, thats wonderful!  (you mean if I state my six month need is a 
	/28, RIPE will allocate that to me?  I thunk there was a floor on min allocation size!)

	Which was why I mentioned address brokers.  It will be possible to get IPv4 space after
	the RIR pools are exausted by leasing space from someone who has it.  That has been the
	case since -prior- to any RIR coming to existance.  Case in point,  COMCAST leases
	IP space to its clients/customers.... as does ATT, VSN, TW, ad-nausa.

	Some brokers will not restrict what their clients can do w/ the space - unlike the
	brokers listed above.

/bill


From nick at foobar.org  Fri Sep 16 15:06:06 2011
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 16 Sep 2011 21:06:06 +0100
Subject: The Cidr Report - 4byte ASN handling
In-Reply-To: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661AFED@FHDP1LUMXC7V43.us.one.verizon.com>
References: <201109092200.p89M00vQ034172@wattle.apnic.net>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661AFED@FHDP1LUMXC7V43.us.one.verizon.com>
Message-ID: <4E73AC2E.2070303@foobar.org>

On 16/09/2011 00:51, Schiller, Heather A wrote:
> I thought AS-plain notation was the standard for 4-byte ASN's?

Wasn't there an RFC written about this by some australian bloke?  I'd say
that whoever maintains the CIDR report these days should really take a
couple of minutes to clue themselves in about asplain syntax.

Nick




From rcarpen at network1.net  Fri Sep 16 15:09:02 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Fri, 16 Sep 2011 16:09:02 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
Message-ID: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>

> 
> 
> I wonder what would happen if a new ARIN member requested an IPv4
> block of say a /16 for a new business? Or even a smaller block. I
> don't know what the current ARIN rules are but RIPE will currently
> give out six months worth of space. Now, in six months, I don't
> expect there to be any left anyway, so what will likely be all the
> v4 you ever get.
> 
> Very soon it'll be nigh on impossible for new entrants to the ISP
> business to get their own v4 space.
> 
> --
> Leigh

As an ISP, ARIN will not give you any space if you are new. You have to already have an equivalent amount of space from another provider. I think it is really stupid, and encourages wasting IP space, but that is what the current policy is.

-Randy


From charles at knownelement.com  Fri Sep 16 15:15:14 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Fri, 16 Sep 2011 15:15:14 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
References: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
Message-ID: <4E73AE52.8030501@knownelement.com>

On 09/16/2011 03:09 PM, Randy Carpenter wrote:
>>
> As an ISP, ARIN will not give you any space if you are new. You have to already have an equivalent amount of space from another provider. I think it is really stupid, and encourages wasting IP space, but that is what the current policy is.

Ah yes. I believe that is the problem we ran into. Where would I find 
more information about this? Is https://www.arin.net/policy/nrpm.html 
the best place? Am I considered an LIR if I simply run an access network 
and don't hand out space to 3rd parties for re assignment? (BTW should I 
be asking these type of questions here, or on an arin list?)




From randy at psg.com  Fri Sep 16 15:36:46 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 16 Sep 2011 22:36:46 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
Message-ID: <m262ksdy1t.wl%randy@psg.com>

> As an ISP, ARIN will not give you any space if you are new. You have
> to already have an equivalent amount of space from another provider.

does arin *really* still have that amazing barrier to market entry?

arin claims to be a shining example of industry self-governance.  to me,
this barrier to entry looks far more like industry self-protection from
new entrants.

and before anyone starts bleeding about the routing table, to me that
sounds like you fear new entrants forcing you to make a small upgrade to
your protected business as usual.

randy


From achatz at forthnet.gr  Fri Sep 16 15:49:17 2011
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Fri, 16 Sep 2011 23:49:17 +0300
Subject: The Cidr Report - 4byte ASN handling
In-Reply-To: <4E73AC2E.2070303@foobar.org>
References: <201109092200.p89M00vQ034172@wattle.apnic.net>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661AFED@FHDP1LUMXC7V43.us.one.verizon.com>
 <4E73AC2E.2070303@foobar.org>
Message-ID: <4E73B64D.6040804@forthnet.gr>

Strangely, both the RFC (5396) and the CIDR report appear to be written by the same 
guy...Geoff.

btw, am i the only one who finds it easier to remember asdot formatted ASNs?

-
Tassos


Nick Hilliard wrote on 16/9/2011 23:06:
> On 16/09/2011 00:51, Schiller, Heather A wrote:
>> I thought AS-plain notation was the standard for 4-byte ASN's?
> Wasn't there an RFC written about this by some australian bloke?  I'd say
> that whoever maintains the CIDR report these days should really take a
> couple of minutes to clue themselves in about asplain syntax.
>
> Nick
>
>
>
>


From nathan at atlasnetworks.us  Fri Sep 16 15:50:56 2011
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Fri, 16 Sep 2011 20:50:56 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m262ksdy1t.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>

> > As an ISP, ARIN will not give you any space if you are new. You have
> > to already have an equivalent amount of space from another provider.
> 
> does arin *really* still have that amazing barrier to market entry?

Yes.  If you want PI space, you have to start off with PA space, utilize it, and then apply for PI space and an AS #, with contracts demonstrating your intention to multihome.  Then, you have to *migrate* off the PA space and surrender it back to the 'owner'.  You cannot get further PI allocations until you've done this.


From bmanning at vacation.karoshi.com  Fri Sep 16 15:56:17 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 16 Sep 2011 20:56:17 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <20110916205617.GE17456@vacation.karoshi.com.>

On Fri, Sep 16, 2011 at 08:50:56PM +0000, Nathan Eisenberg wrote:
> > > As an ISP, ARIN will not give you any space if you are new. You have
> > > to already have an equivalent amount of space from another provider.
> > 
> > does arin *really* still have that amazing barrier to market entry?
> 
> Yes.  If you want PI space, you have to start off with PA space, utilize it, and then apply for PI space and an AS #, with contracts demonstrating your intention to multihome.  Then, you have to *migrate* off the PA space and surrender it back to the 'owner'.  You cannot get further PI allocations until you've done this.
> 

	good thing Mr Hushmail does not have to deal w/ this policy.  He
	can go to Ripe and get space... :)

/bill


From hasserw at hushmail.com  Fri Sep 16 16:28:13 2011
From: hasserw at hushmail.com (hasserw at hushmail.com)
Date: Fri, 16 Sep 2011 17:28:13 -0400
Subject: How to begin making my own ISP?
Message-ID: <20110916212813.1F29AE672D@smtp.hushmail.com>

On Fri, 16 Sep 2011 16:02:39 -0400 Markus <universe at truemetal.org> 
wrote:
>Wait a sec :)  So the info I sent you about RIPE and Germany 
wasn't useful to you at all? :(

I didn't receive any such email, sorry. Try resending it if you 
still have it ?

@ Everyone else: thank you for the useful information. I didn't 
mean to come off as being bratty with my competition notation, it 
was meant as a bump to the posting and not an insult at anyone.

More info: yes, I was planning on having some co-lo sort of stuff, 
maybe running a dedicated server provider. However on my own IP 
space, and a good method of getting bandwidth of cheap. Stuff like 
paying 5?/GB makes me feel sick.



From charles at knownelement.com  Fri Sep 16 16:34:04 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Fri, 16 Sep 2011 16:34:04 -0500
Subject: How to begin making my own ISP?
In-Reply-To: <20110916212813.1F29AE672D@smtp.hushmail.com>
References: <20110916212813.1F29AE672D@smtp.hushmail.com>
Message-ID: <4E73C0CC.4090901@knownelement.com>

On 09/16/2011 04:28 PM, hasserw at hushmail.com wrote:
> On Fri, 16 Sep 2011 16:02:39 -0400 Markus <universe at truemetal.org> 
> wrote:
>
> I didn't receive any such email, sorry. Try resending it if you 
> still have it ?

Maybe hushmail blocked it? :)

> @ Everyone else: thank you for the useful information. I didn't 
> mean to come off as being bratty with my competition notation, it 
> was meant as a bump to the posting and not an insult at anyone.

Thanks for clarifying.

> More info: yes, I was planning on having some co-lo sort of stuff, 
> maybe running a dedicated server provider. However on my own IP 
> space, and a good method of getting bandwidth of cheap. Stuff like 
> paying 5?/GB makes me feel sick.

Hmmmm. Me thinks that's a no go. You are entering an incredibly
stiff competitive space. If you do have some magic pixie dust, I would sell
it to the highest bidder. :) (I do believe people were seeking pixie dust in
the 444 thread if I recall correctly).

Not to be snide, but what makes you think you have something that will
let you break into the colo market against a huge assortment of players?
(ref the lots and lots and lots of money response). You'll need some hefty
capital to attract customers. Plus if you can only compete on price, the
established players will just cut costs to match you.

That's all my opinion of course.




-- 
Charles N Wyble charles at knownelement.com @charlesnw on twitter

http://blog.knownelement.com

Building alternative,global scale,secure, cost effective bit moving platform
for tomorrows alternate default free zone.



From streiner at cluebyfour.org  Fri Sep 16 16:34:38 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 16 Sep 2011 17:34:38 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
References: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
Message-ID: <Pine.LNX.4.64.1109161723560.17783@whammy.cluebyfour.org>

On Fri, 16 Sep 2011, Randy Carpenter wrote:

>> I wonder what would happen if a new ARIN member requested an IPv4
>> block of say a /16 for a new business? Or even a smaller block. I
>> don't know what the current ARIN rules are but RIPE will currently
>> give out six months worth of space. Now, in six months, I don't
>> expect there to be any left anyway, so what will likely be all the
>> v4 you ever get.
>
> As an ISP, ARIN will not give you any space if you are new. You have to 
> already have an equivalent amount of space from another provider. I 
> think it is really stupid, and encourages wasting IP space, but that is 
> what the current policy is.

If you go to ARIN, day one, and ask for address space, they have no way of 
determining if your request is justified, beyond whatever pie-in-the-sky 
guesses and growth projections you give them.  You're asking for address 
space, sight unseen, in this case.  That would be like someone going to a 
bank and asking for a loan, with no documentation, collateral, or anything 
else to give the bank confidence that they'll pay the loan back.

That's why the slow-start model has been used, particularly for v4 space.
If you started off by getting PA space from one or more of your upstreams, 
then there should be additional documentation to back up your request 
(SWIP entries, RWHOIS data, etc).

When I still worked in the ISP world, the startup I worked for started off 
with PA space, and then grew into PI space, and handed the PA space back 
to their upstreams as it was vacated.  I had no problems getting subsequent
PI blocks because our documentation was in order.

jms


From charles at knownelement.com  Fri Sep 16 16:37:52 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Fri, 16 Sep 2011 16:37:52 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <Pine.LNX.4.64.1109161723560.17783@whammy.cluebyfour.org>
References: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <Pine.LNX.4.64.1109161723560.17783@whammy.cluebyfour.org>
Message-ID: <4E73C1B0.5060209@knownelement.com>

On 09/16/2011 04:34 PM, Justin M. Streiner wrote:
> On Fri, 16 Sep 2011, Randy Carpenter wrote:
>
>
> If you go to ARIN, day one, and ask for address space, they have no
> way of determining if your request is justified, beyond whatever
> pie-in-the-sky guesses and growth projections you give them.  You're
> asking for address space, sight unseen, in this case.  That would be
> like someone going to a bank and asking for a loan, with no
> documentation, collateral, or anything else to give the bank
> confidence that they'll pay the loan back.
>
> That's why the slow-start model has been used, particularly for v4 space.
> If you started off by getting PA space from one or more of your
> upstreams, then there should be additional documentation to back up
> your request (SWIP entries, RWHOIS data, etc).
>
> When I still worked in the ISP world, the startup I worked for started
> off with PA space, and then grew into PI space, and handed the PA
> space back to their upstreams as it was vacated.  I had no problems
> getting subsequent
> PI blocks because our documentation was in order.

Alright. This seems fair.

Easy enough to get some big chunks of v6 space from up streams and then
justify the PI space.

I shall have to do that then.




-- 
Charles N Wyble charles at knownelement.com @charlesnw on twitter

http://blog.knownelement.com

Building alternative,global scale,secure, cost effective bit moving platform
for tomorrows alternate default free zone.



From randy at psg.com  Fri Sep 16 16:38:40 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 16 Sep 2011 23:38:40 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <Pine.LNX.4.64.1109161723560.17783@whammy.cluebyfour.org>
References: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <Pine.LNX.4.64.1109161723560.17783@whammy.cluebyfour.org>
Message-ID: <m2y5xocgm7.wl%randy@psg.com>

>> As an ISP, ARIN will not give you any space if you are new. You have to 
>> already have an equivalent amount of space from another provider. I 
>> think it is really stupid, and encourages wasting IP space, but that is 
>> what the current policy is.
> 
> If you go to ARIN, day one, and ask for address space, they have no way of 
> determining if your request is justified, beyond whatever pie-in-the-sky 
> guesses and growth projections you give them.

why is this not a problem in any other region?

randy


From tvhawaii at shaka.com  Fri Sep 16 16:43:59 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Fri, 16 Sep 2011 11:43:59 -1000
Subject: How to begin making my own ISP?
References: <20110916212813.1F29AE672D@smtp.hushmail.com>
Message-ID: <E58B42C199144149BFAB3F26445FFE87@owner59e1f1502>

hasserw at hushmail.com wrote:
> On Fri, 16 Sep 2011 16:02:39 -0400 Markus <universe at truemetal.org>
> wrote:
>> Wait a sec :)  So the info I sent you about RIPE and Germany
> wasn't useful to you at all? :(
>
> I didn't receive any such email, sorry. Try resending it if you
> still have it ?
>
> @ Everyone else: thank you for the useful information. I didn't
> mean to come off as being bratty with my competition notation, it
> was meant as a bump to the posting and not an insult at anyone.
>
> More info: yes, I was planning on having some co-lo sort of stuff,
> maybe running a dedicated server provider. However on my own IP
> space, and a good method of getting bandwidth of cheap. Stuff like
> paying 5?/GB makes me feel sick.


Oldie but goodie:

http://www.amazon.com/gp/product/0471314994/ref=olp_product_details?ie=UTF8&me=&seller=




From streiner at cluebyfour.org  Fri Sep 16 16:45:17 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 16 Sep 2011 17:45:17 -0400 (EDT)
Subject: How to begin making my own ISP?
In-Reply-To: <20110916181029.24C11E671D@smtp.hushmail.com>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
Message-ID: <Pine.LNX.4.64.1109161737530.17783@whammy.cluebyfour.org>

On Fri, 16 Sep 2011, hasserw at hushmail.com wrote:

> No one replied with any useful information. I guess no one wants
> competition on this list? Pretty poor tactic.

Honestly, I did have an insightful email drafted up for your original 
post, but the more I thought about it, the more I felt like I was getting 
troll-baited.

I do see posts on this list from time to time, and on other related lists, 
from people who appear to be pretty new to the game, and that's perfectly 
OK.  I will not bash a newbie for being a newbie, because we were all 
newbies at one point or another.  However, expecting other people to do 
all the work and give you all of the answers, and then criticizing the 
group when they didn't do that, based on a very vague definition of a 
requirement is just bad form.

Since you mentioned school years in your original post, I'm going to 
assume that you're also pretty young.  Just remember - mailing list 
archives are forever ;)

jms

> On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
>> I want to begin making my own ISP, mainly for high speed servers
>> and such, but also branching out to residential customers. I'm
>> going to be in Germany for the next school year (probably either
>> Frankfurt am Main or Berlin); any suggestions on what sort of
>> classes I can take there that will be in English and will teach me
>>
>> all I need to know on how to build and manage my own ISP, AS, etc?
>>
>> Thanks.
>
>
>


From streiner at cluebyfour.org  Fri Sep 16 16:47:31 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 16 Sep 2011 17:47:31 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <m2y5xocgm7.wl%randy@psg.com>
References: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <Pine.LNX.4.64.1109161723560.17783@whammy.cluebyfour.org>
 <m2y5xocgm7.wl%randy@psg.com>
Message-ID: <Pine.LNX.4.64.1109161746210.17783@whammy.cluebyfour.org>

On Fri, 16 Sep 2011, Randy Bush wrote:

>> If you go to ARIN, day one, and ask for address space, they have no way of
>> determining if your request is justified, beyond whatever pie-in-the-sky
>> guesses and growth projections you give them.
>
> why is this not a problem in any other region?

I don't have experience in working with the other RIRs, or their 
address assignment policies, so I can't speak to that.

jms


From leigh.porter at ukbroadband.com  Fri Sep 16 16:51:09 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 16 Sep 2011 21:51:09 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m262ksdy1t.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643C0B75@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Randy Bush [mailto:randy at psg.com]
> Sent: 16 September 2011 21:38
> To: Randy Carpenter
> Cc: North American Network Operators' Group
> Subject: Re: wet-behind-the-ears whippersnapper seeking advice on
> building a nationwide network
> 
> > As an ISP, ARIN will not give you any space if you are new. You have
> > to already have an equivalent amount of space from another provider.
> 
> does arin *really* still have that amazing barrier to market entry?
> 
> arin claims to be a shining example of industry self-governance.  to
> me,
> this barrier to entry looks far more like industry self-protection from
> new entrants.
> 
> and before anyone starts bleeding about the routing table, to me that
> sounds like you fear new entrants forcing you to make a small upgrade
> to
> your protected business as usual.


People have been bleating about routing tables sizes for years and everything has been fine. You could argue that the bleating has helped keep the size down of course, perhaps it has.

--
Leigh





______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From randy at psg.com  Fri Sep 16 16:56:23 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 16 Sep 2011 23:56:23 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643C0B75@EALPO1.ukbroadband.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <D181DDABABE57E4DB72FEE00331478643C0B75@EALPO1.ukbroadband.com>
Message-ID: <m2wrd8cfso.wl%randy@psg.com>

> People have been bleating about routing tables sizes for years and
> everything has been fine. You could argue that the bleating has helped
> keep the size down of course, perhaps it has.

guy walks into a psychiatrist's office waving a newspaper.  shrink
asks "why are you waving that newspaper?"  guy responds "to keep
the elephants away."  shrink says "heck, there are no elephants for
thousands of miles."  guy responds "pretty effective isn't it!"


From cidr-report at potaroo.net  Fri Sep 16 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 16 Sep 2011 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201109162200.p8GM00Xp095586@wattle.apnic.net>

BGP Update Report
Interval: 08-Sep-11 -to- 15-Sep-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS8447           100707  3.4%    1038.2 -- TELEKOM-AT A1 Telekom Austria AG
 2 - AS23966           36362  1.2%     103.9 -- LDN-AS-PK LINKdotNET Telecom Limited
 3 - AS9829            34349  1.2%      37.5 -- BSNL-NIB National Internet Backbone
 4 - AS7497            32748  1.1%     108.4 -- CSTNET-AS-AP Computer Network Information Center
 5 - AS16212           31226  1.1%    1040.9 -- LORAL-SKYNET-ASN Loral Skynet - Aflenz ES (Telekom Austria)
 6 - AS29571           30063  1.0%     151.8 -- CITelecom-AS
 7 - AS22566           29051  1.0%     785.2 -- Maxcom Telecomunicaciones, S.A.B. de C.V.
 8 - AS12486           26743  0.9%     922.2 -- YEMENNET YT - YEMEN NET Autonomous Number
 9 - AS4845            26731  0.9%    1336.5 -- SINGTEL-TW Chung Hsiao East Road
10 - AS8452            25895  0.9%      27.5 -- TE-AS TE-AS
11 - AS7552            25185  0.9%      18.9 -- VIETEL-AS-AP Vietel Corporation
12 - AS32528           24881  0.8%    3554.4 -- ABBOTT Abbot Labs
13 - AS38040           24861  0.8%    2486.1 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
14 - AS5800            24545  0.8%     134.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
15 - AS6316            23777  0.8%    1251.4 -- AS-PAETEC-NET - PaeTec Communications, Inc.
16 - AS47794           20855  0.7%     281.8 -- ATHEEB-AS Etihad Atheeb Telecom Company
17 - AS16305           19756  0.7%    1039.8 -- mobilkom austria AG
18 - AS1901            19698  0.7%    1036.7 -- EUNETAT-AS eTel Austria Gesmbh u. CO KG
19 - AS9498            19452  0.7%      23.7 -- BBIL-AP BHARTI Airtel Ltd.
20 - AS38543           18078  0.6%    3615.6 -- IBM-TH-AS-AP IBM THAILAND NETWORK


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS56375           15079  0.5%   15079.0 -- IKRF Imam Khomeini Relief Foundation IKRF
 2 - AS3454             8062  0.3%    4031.0 -- Universidad Autonoma de Nuevo Leon
 3 - AS38543           18078  0.6%    3615.6 -- IBM-TH-AS-AP IBM THAILAND NETWORK
 4 - AS32528           24881  0.8%    3554.4 -- ABBOTT Abbot Labs
 5 - AS3976             3499  0.1%    3499.0 -- ERX-NURI-ASN I.Net Technologies Inc.
 6 - AS38040           24861  0.8%    2486.1 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 7 - AS49963            1831  0.1%    1831.0 -- BELRTS-AS Regional TeleSystem Ltd
 8 - AS15326            8641  0.3%    1728.2 -- BINARYBROADBAND - BINARY BROADBAND
 9 - AS30740            1649  0.1%    1649.0 -- EXA-AS Exa Networks Limited
10 - AS46018            1576  0.1%    1576.0 -- DEPPERIN-AS-ID Departemen Perindustrian Republik Indonesia
11 - AS16910            1534  0.1%    1534.0 -- FARM-CREDIT - Farm Credit Financial Partners, Inc.
12 - AS38510            3067  0.1%    1533.5 -- DEPTAN-AS-ID KEMENTERIAN PERTANIAN REPUBLIK INDONESIA
13 - AS35571            1526  0.1%    1526.0 -- COMSERVICE-AS CJSC MultiLine
14 - AS42102            2944  0.1%    1472.0 -- ASN-LRNC L&R Network Consulting
15 - AS14321            1400  0.1%    1400.0 -- SERVICIO-UNITELLER - Servicio Uniteller, Inc.
16 - AS4845            26731  0.9%    1336.5 -- SINGTEL-TW Chung Hsiao East Road
17 - AS17408            3981  0.1%    1327.0 -- ABOVE-AS-AP AboveNet Communications Taiwan
18 - AS4555             5065  0.2%    1266.2 -- EP0-BLK-ASNBLOCK-5 - Almond Oil Process, LLC.
19 - AS6316            23777  0.8%    1251.4 -- AS-PAETEC-NET - PaeTec Communications, Inc.
20 - AS45259            1206  0.0%    1206.0 -- BRUHAAS-BN Suites 11-12, 3rd Floor


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 91.224.110.0/23   15079  0.5%   AS56375 -- IKRF Imam Khomeini Relief Foundation IKRF
 2 - 130.36.34.0/24    12418  0.4%   AS32528 -- ABBOTT Abbot Labs
 3 - 130.36.35.0/24    12418  0.4%   AS32528 -- ABBOTT Abbot Labs
 4 - 202.92.235.0/24   11874  0.4%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 5 - 66.248.96.0/21    10536  0.3%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 6 - 66.248.120.0/21   10212  0.3%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 7 - 206.80.93.0/24     8108  0.3%   AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
 8 - 200.23.202.0/24    8060  0.3%   AS3454  -- Universidad Autonoma de Nuevo Leon
 9 - 61.90.164.0/24     6321  0.2%   AS38543 -- IBM-TH-AS-AP IBM THAILAND NETWORK
10 - 58.97.61.0/24      6318  0.2%   AS38543 -- IBM-TH-AS-AP IBM THAILAND NETWORK
11 - 213.16.48.0/24     5887  0.2%   AS8866  -- BTC-AS Bulgarian Telecommunication Company Plc.
12 - 145.36.122.0/24    5559  0.2%   AS7046  -- RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business
13 - 58.137.200.0/24    5434  0.2%   AS38543 -- IBM-TH-AS-AP IBM THAILAND NETWORK
14 - 202.41.70.0/24     5334  0.2%   AS2697  -- ERX-ERNET-AS Education and Research Network
15 - 180.180.255.0/24   4265  0.1%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
16 - 180.180.253.0/24   4181  0.1%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
17 - 180.180.248.0/24   4179  0.1%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
18 - 180.180.250.0/24   4177  0.1%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
19 - 180.180.251.0/24   4176  0.1%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
20 - 202.153.174.0/24   3973  0.1%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan

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 cidr-report at potaroo.net  Fri Sep 16 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 16 Sep 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201109162200.p8GM00mS095581@wattle.apnic.net>

This report has been generated at Fri Sep 16 21:12:30 2011 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
        09-09-11    373405      219926
        10-09-11    374200      219948
        11-09-11    374395      220145
        12-09-11    374644      220217
        13-09-11    374944      220346
        14-09-11    375016      220084
        15-09-11    374599      220272
        16-09-11    374860      220298


AS Summary
         38909  Number of ASes in routing system
         16445  Number of ASes announcing only one prefix
          3563  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      108368864  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').

 --- 16Sep11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     375091   220040   155051    41.3%   All ASes

AS6389      3563      229     3334    93.6%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4766      2508      974     1534    61.2%   KIXS-AS-KR Korea Telecom
AS18566     1912      378     1534    80.2%   COVAD - Covad Communications
                                               Co.
AS22773     1455      108     1347    92.6%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1545      227     1318    85.3%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS4323      1626      395     1231    75.7%   TWTC - tw telecom holdings,
                                               inc.
AS1785      1793      775     1018    56.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS10620     1675      658     1017    60.7%   Telmex Colombia S.A.
AS28573     1351      353      998    73.9%   NET Servicos de Comunicao S.A.
AS19262     1395      400      995    71.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS7303      1156      308      848    73.4%   Telecom Argentina S.A.
AS18101      951      144      807    84.9%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS7552       978      178      800    81.8%   VIETEL-AS-AP Vietel
                                               Corporation
AS24560     1182      396      786    66.5%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS8151      1415      656      759    53.6%   Uninet S.A. de C.V.
AS4808      1069      333      736    68.8%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS30036     1423      693      730    51.3%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS7545      1597      873      724    45.3%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1105      450      655    59.3%   LEVEL3 Level 3 Communications
AS14420      732       97      635    86.7%   CORPORACION NACIONAL DE
                                               TELECOMUNICACIONES - CNT EP
AS20115     1595      967      628    39.4%   CHARTER-NET-HKY-NC - Charter
                                               Communications
AS22561      973      361      612    62.9%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS3549      1051      446      605    57.6%   GBLX Global Crossing Ltd.
AS17676      675       70      605    89.6%   GIGAINFRA Softbank BB Corp.
AS17974     2010     1406      604    30.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4804       660       87      573    86.8%   MPX-AS Microplex PTY LTD
AS17488      958      387      571    59.6%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS22047      579       29      550    95.0%   VTR BANDA ANCHA S.A.
AS7011      1183      656      527    44.5%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.
AS4780       725      218      507    69.9%   SEEDNET Digital United Inc.

Total      40840    13252    27588    67.6%   Top 30 total


Possible Bogus Routes

        5.0.0.0/16           AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        5.1.0.0/21           AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        5.1.24.0/24          AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        46.18.104.0/21       AS3.746 
        50.115.160.0/20      AS32097 WII-KC - WholeSale Internet, Inc.
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        80.88.10.0/24        AS33774 DJAWEB
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.45.1.0/24        AS29571 CITelecom-AS
        172.45.2.0/24        AS29571 CITelecom-AS
        172.45.3.0/24        AS29571 CITelecom-AS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        181.82.15.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.16.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.17.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        181.82.18.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        185.0.0.0/16         AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        185.1.0.0/21         AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        185.24.0.0/24        AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        190.102.32.0/20      AS30058 FDCSERVERS - FDCservers.net
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        190.122.208.0/24     AS28066 COOP. MARIANO ACOSTA
        190.122.209.0/24     AS28066 COOP. MARIANO ACOSTA
        190.122.210.0/24     AS28066 COOP. MARIANO ACOSTA
        190.122.211.0/24     AS28066 COOP. MARIANO ACOSTA
        190.122.212.0/24     AS28066 COOP. MARIANO ACOSTA
        190.122.213.0/24     AS28066 COOP. MARIANO ACOSTA
        190.122.214.0/24     AS28066 COOP. MARIANO ACOSTA
        190.122.215.0/24     AS28066 COOP. MARIANO ACOSTA
        193.111.87.0/24      AS24812 
        195.54.52.0/23       AS3.523 
        195.54.52.0/24       AS3.523 
        195.54.53.0/24       AS3.523 
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.76.0/24       AS7195  Telecorp Colombia S.A.
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.9.57.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        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.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.72.192.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.72.194.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        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.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.58.200.0/24      AS18530 ISOMEDIA-1 - Isomedia Inc.
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


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 nathan at atlasnetworks.us  Fri Sep 16 17:14:12 2011
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Fri, 16 Sep 2011 22:14:12 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <Pine.LNX.4.64.1109161723560.17783@whammy.cluebyfour.org>
References: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <Pine.LNX.4.64.1109161723560.17783@whammy.cluebyfour.org>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B56C069@ex-mb-1.corp.atlasnetworks.us>

> When I still worked in the ISP world, the startup I worked for started off with
> PA space, and then grew into PI space, and handed the PA space back to
> their upstreams as it was vacated.  I had no problems getting subsequent PI
> blocks because our documentation was in order.

The documentation isn't the pain.  The renumbering is, *especially* if you're running a service provider network:

'Dear dedicated server customer, we're taking away your IPs, please don't be angry with us even though it will cost you untold hours of work to hunt down all the tiny implications of renumbering.  Never mind the lost business it might cause if you miss something.'

'Dear internet access user who happens to run a bunch of IPSEC tunnels: Have fun fixing all your tunnels!  Don't worry, we'll figure out an off-hours time that works for everyone, and that makes all the pain go away, right?  You won't harbor any resentment, right?'

(Wow, that comes off more bitter than I expected...)

Oh well... Since new IPv4 allocations are fast approaching the same scarcity as unobtanium, I guess it's too late to worry about it now.  Anyways, apparently IPv6 fixes all of this, or something.

Nathan


From ikiris at gmail.com  Fri Sep 16 17:19:29 2011
From: ikiris at gmail.com (Blake Dunlap)
Date: Fri, 16 Sep 2011 17:19:29 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B56C069@ex-mb-1.corp.atlasnetworks.us>
References: <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <Pine.LNX.4.64.1109161723560.17783@whammy.cluebyfour.org>
 <8C26A4FDAE599041A13EB499117D3C286B56C069@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <CAJvB4t=B_m_mbMSTEToAXN5uvnzZPCHT8_w0OTdFf-fmbVUfKA@mail.gmail.com>

> 'Dear dedicated server customer, we're taking away your IPs, please don't
> be angry with us even though it will cost you untold hours of work to hunt
> down all the tiny implications of renumbering.  Never mind the lost business
> it might cause if you miss something.'
>
> 'Dear internet access user who happens to run a bunch of IPSEC tunnels:
> Have fun fixing all your tunnels!  Don't worry, we'll figure out an
> off-hours time that works for everyone, and that makes all the pain go away,
> right?  You won't harbor any resentment, right?'
>
> (Wow, that comes off more bitter than I expected...)
>
> Oh well... Since new IPv4 allocations are fast approaching the same
> scarcity as unobtanium, I guess it's too late to worry about it now.
>  Anyways, apparently IPv6 fixes all of this, or something.
>
> Nathan
>
>
Yeah I'm going through this fun right now at a company I work for.
Definately not pleasant for us or our customers.

-Blake

From kuenzler at init7.net  Fri Sep 16 18:12:50 2011
From: kuenzler at init7.net (Fredy Kuenzler)
Date: Sat, 17 Sep 2011 01:12:50 +0200
Subject: IPV6 over a PPTP Link
In-Reply-To: <C249D3C3D3E6402BAAEBD07D90BF0E90@work>
References: <C249D3C3D3E6402BAAEBD07D90BF0E90@work>
Message-ID: <4E73D7F2.7050601@init7.net>

Am 15.09.2011 18:24, schrieb Meftah Tayeb:
> can i ofer ipv6 addresses through a PPTP connection using cisco ?
> if yes, how please ?

These slides were presented on various conferences showing native v6 via 
L2TP. While you asked for PPTP, I thought to point to the link anyway, maybe 
the slides are useful.

http://www.blogg.ch/uploads/Native-IPv6-via-xdsl-how-to-tweak-your-LNS_v0.41.pdf

Fredy K?nzler
Init7 / AS13030


From shrdlu at deaddrop.org  Fri Sep 16 19:15:36 2011
From: shrdlu at deaddrop.org (Lynda)
Date: Fri, 16 Sep 2011 17:15:36 -0700
Subject: How to begin making my own ISP?
In-Reply-To: <E58B42C199144149BFAB3F26445FFE87@owner59e1f1502>
References: <20110916212813.1F29AE672D@smtp.hushmail.com>
 <E58B42C199144149BFAB3F26445FFE87@owner59e1f1502>
Message-ID: <4E73E6A8.3040205@deaddrop.org>

On 9/16/2011 2:43 PM, Michael Painter wrote:
> hasserw at hushmail.com wrote:

>> @ Everyone else: thank you for the useful information. I didn't
>> mean to come off as being bratty with my competition notation, it
>> was meant as a bump to the posting and not an insult at anyone.

> Oldie but goodie:
>
> http://www.amazon.com/gp/product/0471314994/ref=olp_product_details?ie=UTF8&me=&seller=

Whoa. How strange. I actually *own* that book...but then, I'm old, and 
crotchety, and know what ISIS is (yes, I love saying that).

That said, one oh-so-brief word of advice to Mr Hushmail, and it's 
accurate, from YEARS of experience, and will hopefully be taken 
seriously. First step, before you follow any of the others, is to make a 
business model. Second is to find a venture capitalist group, and 
convince them that you have your ducks in a row, and plan to make them 
(and yourself) rich. Otherwise, don't give up your day job.

Not being remotely cruel, here (and I could be, and I'm good at it). If 
you aren't spending someone else's money, you need to have plenty of 
your own, and I'd bet you don't. I suspect you would be shocked at the 
amount of money a startup similar to what you're proposing would take. 
Here's a clue; the number will have at least 7 digits (US Dollars). It's 
always about money. So it goes.

-- 
"Democratic nations must try to find ways to starve the terrorist
and the hijacker of the oxygen of publicity on which they depend."
                   Margaret Thatcher


From mysidia at gmail.com  Fri Sep 16 19:43:15 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 16 Sep 2011 19:43:15 -0500
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com>
 <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
Message-ID: <CAAAwwbXR9UPP2fZR5fP40g3z+kvy-62L9YbeUBCWxFrnS5kXxg@mail.gmail.com>

On Fri, Sep 16, 2011 at 5:53 AM, John Curran <jcurran at arin.net> wrote:
> On Sep 16, 2011, at 3:21 AM, Randy Bush wrote:
> Randy -
> ?Over the last decade, we've run multiple consultations with the

While I appreciate that ARIN has had community consultations...
It needs to be understood that the WHOIS service is a critical service
that many people rely upon,  and many people/organizations have developed
tools and internal processes that work with the WHOIS service and rely on it
continuing to operate in the manner it has operated in the past.

There may be no RFC specifying the exact contents of the WHOIS output and
the query syntax, but these are de-facto standards and should not be changed
without a great deal of care.

Many stakeholders are unlikely to be well-represented in the consultation
process.

ARIN should acknowledge this fact, and therefore ensure that any changes
suggested  do not break or significantly alter the standard behavior
and operation
of WHOIS,  when a WHOIS user is not issuing a query specifically asking to
utilize a new feature or format.

When new changes are being proposed they should be operated on a separate WHOIS
system in parallel.

The community consultation process should not merely be  "take this
list of suggestions",
there  should be ACCEPTANCE TESTING  and approval by the community of the final
result.


Regards,

--
-JH


From charles at knownelement.com  Fri Sep 16 20:52:18 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Fri, 16 Sep 2011 20:52:18 -0500
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <CAAAwwbXR9UPP2fZR5fP40g3z+kvy-62L9YbeUBCWxFrnS5kXxg@mail.gmail.com>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com> <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
 <CAAAwwbXR9UPP2fZR5fP40g3z+kvy-62L9YbeUBCWxFrnS5kXxg@mail.gmail.com>
Message-ID: <4E73FD52.6060706@knownelement.com>

Does whois have a bug tracker somewhere? That seems to be the place to
file these sort of things.


From ben at adversary.org  Fri Sep 16 20:41:57 2011
From: ben at adversary.org (Ben McGinnes)
Date: Sat, 17 Sep 2011 11:41:57 +1000
Subject: How to begin making my own ISP?
In-Reply-To: <4E73C0CC.4090901@knownelement.com>
References: <20110916212813.1F29AE672D@smtp.hushmail.com>
 <4E73C0CC.4090901@knownelement.com>
Message-ID: <4E73FAE5.2020707@adversary.org>

On 17/09/11 7:34 AM, Charles N Wyble wrote:
> On 09/16/2011 04:28 PM, hasserw at hushmail.com wrote:
>> On Fri, 16 Sep 2011 16:02:39 -0400 Markus <universe at truemetal.org> 
>> wrote:
>>
>> I didn't receive any such email, sorry. Try resending it if you 
>> still have it ?
> 
> Maybe hushmail blocked it? :)

That's not outside the realms of possibility, especially if the sender
was using OpenPGP.  Hushmail does many odd things with its
implementation (e.g. still no support for PGP/MIME or even SHA-2).


Regards,
Ben

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

From joe at nethead.com  Fri Sep 16 23:30:43 2011
From: joe at nethead.com (Joe Hamelin)
Date: Fri, 16 Sep 2011 21:30:43 -0700
Subject: How to begin making my own ISP?
In-Reply-To: <4E73FAE5.2020707@adversary.org>
References: <20110916212813.1F29AE672D@smtp.hushmail.com>
 <4E73C0CC.4090901@knownelement.com>
 <4E73FAE5.2020707@adversary.org>
Message-ID: <CAO0-hXa4Bg9CGJ0Wg=tAugCcZMFWfNupudaOukCE6+6YNZs4zA@mail.gmail.com>

When we needed an ISP in Yakima back in '95 we found a rich guy in Seattle,
got him to hire an old SunOS geek and an illegal Englishman, and a very
small space on the 19th floor of the Westin.  Then we talked him into
putting his first POP in Yakima where he would have immediate paying
customers.   He was tired of using broken UUCP email for his trading
company.  That was our "hook".  That ISP founded what is now SIX, so not all
was lost.

joe at wolfe.net
--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474


On Fri, Sep 16, 2011 at 6:41 PM, Ben McGinnes <ben at adversary.org> wrote:

> On 17/09/11 7:34 AM, Charles N Wyble wrote:
> > On 09/16/2011 04:28 PM, hasserw at hushmail.com wrote:
> >> On Fri, 16 Sep 2011 16:02:39 -0400 Markus <universe at truemetal.org>
> >> wrote:
> >>
> >> I didn't receive any such email, sorry. Try resending it if you
> >> still have it ?
> >
> > Maybe hushmail blocked it? :)
>
> That's not outside the realms of possibility, especially if the sender
> was using OpenPGP.  Hushmail does many odd things with its
> implementation (e.g. still no support for PGP/MIME or even SHA-2).
>
>
> Regards,
> Ben
>
>

From mtinka at globaltransit.net  Fri Sep 16 23:36:13 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 17 Sep 2011 12:36:13 +0800
Subject: The Cidr Report - 4byte ASN handling
In-Reply-To: <20110916191601.GA2118@srv03.cluenet.de>
References: <201109092200.p89M00vQ034172@wattle.apnic.net>
 <201109170211.28305.mtinka@globaltransit.net>
 <20110916191601.GA2118@srv03.cluenet.de>
Message-ID: <201109171236.16778.mtinka@globaltransit.net>

On Saturday, September 17, 2011 03:16:01 AM Daniel Roesen 
wrote:

> RFC5396 on as-plain is on track becoming one.

Indeed.

I suppose it will be interesting to see how the vendors 
respond to this. Would they retract support for as-dot, as 
it's been shipping for a while now?

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110917/2810ab07/attachment.bin>

From mtinka at globaltransit.net  Fri Sep 16 23:39:10 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 17 Sep 2011 12:39:10 +0800
Subject: The Cidr Report - 4byte ASN handling
In-Reply-To: <4E73B64D.6040804@forthnet.gr>
References: <201109092200.p89M00vQ034172@wattle.apnic.net>
 <4E73AC2E.2070303@foobar.org> <4E73B64D.6040804@forthnet.gr>
Message-ID: <201109171239.10460.mtinka@globaltransit.net>

On Saturday, September 17, 2011 04:49:17 AM Tassos 
Chatzithomaoglou wrote:

> btw, am i the only one who finds it easier to remember
> asdot formatted ASNs?

They're easier to remember, but if you operate an ASN for a 
reasonable period of time, it's okay to assume that you will 
remember it, whether it's as-plain or otherwise.

The same would hold true for your favorite upstreams, peers, 
customers and role model ISP's :-).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110917/9b2f44fe/attachment.bin>

From joe at nethead.com  Sat Sep 17 00:11:30 2011
From: joe at nethead.com (Joe Hamelin)
Date: Fri, 16 Sep 2011 22:11:30 -0700
Subject: The Cidr Report - 4byte ASN handling
In-Reply-To: <201109171239.10460.mtinka@globaltransit.net>
References: <201109092200.p89M00vQ034172@wattle.apnic.net>
 <4E73AC2E.2070303@foobar.org> <4E73B64D.6040804@forthnet.gr>
 <201109171239.10460.mtinka@globaltransit.net>
Message-ID: <CAO0-hXZjpMkH3dt7gCWjYUKUqhrtGcUqmdcU+-UCvD9-3HUJEg@mail.gmail.com>

I say we all start using octal two's complement for extended ASNs.

(note to self: don't post to NANOG after a night out with a vendor.)

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474


On Fri, Sep 16, 2011 at 9:39 PM, Mark Tinka <mtinka at globaltransit.net>wrote:

> On Saturday, September 17, 2011 04:49:17 AM Tassos
> Chatzithomaoglou wrote:
>
> > btw, am i the only one who finds it easier to remember
> > asdot formatted ASNs?
>
> They're easier to remember, but if you operate an ASN for a
> reasonable period of time, it's okay to assume that you will
> remember it, whether it's as-plain or otherwise.
>
> The same would hold true for your favorite upstreams, peers,
> customers and role model ISP's :-).
>
> Cheers,
>
> Mark.
>

From markrefresh12 at gmail.com  Sat Sep 17 03:12:46 2011
From: markrefresh12 at gmail.com (Mark Smith)
Date: Sat, 17 Sep 2011 11:12:46 +0300
Subject: HP A-series, H3C, Huawei and their capabilities in real-life
In-Reply-To: <CAE79DorP-waM_EdHQJvQMw+mftM+BAv35tGhTz7TeYJTy-ON1Q@mail.gmail.com>
References: <CAE79DorP-waM_EdHQJvQMw+mftM+BAv35tGhTz7TeYJTy-ON1Q@mail.gmail.com>
Message-ID: <CAE79Dorz-hQPJkq4AUqz6hE+dnWpr5KuUy721xsfWqoRjD0uGA@mail.gmail.com>

My apologies for using gmail. Company policy prohibits the use of
corporate email and identity.

Nobody has heard nothing? Hear no evil? ;)

What we basically have at this point is vendor specifications, sales
talk and rumors that big boys have built large networks using these
boxes (or predecessors of them, i.e. Huawei) especially in Asia and
former Soviet countries. There are also some western references such
as BT.

With BT the references only mention Huawei, not HP. Does Huawei still
sell (wired) routers under their own brand? Or is the BT reference
network consisting purely of mobile stuff, (UMTS etc) and does not
include traditional wired infrastructure (IP/BGP/MPLS routers)? Or is
the HP's acquisition so new that the references are only mentioning
Huawei?

This resembles detective's work :)

The price of these boxes is quite attractive, but there are lots of
buts. For example, how much do they have in common with Huawei boxes?
Traditionally HP networking gear excluding basic pizzabox switches has
not been very convincing.

Even comment like "they suck, stay away from them" would be very valuable.


From swmike at swm.pp.se  Sat Sep 17 03:34:25 2011
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sat, 17 Sep 2011 10:34:25 +0200 (CEST)
Subject: HP A-series, H3C, Huawei and their capabilities in real-life
In-Reply-To: <CAE79Dorz-hQPJkq4AUqz6hE+dnWpr5KuUy721xsfWqoRjD0uGA@mail.gmail.com>
References: <CAE79DorP-waM_EdHQJvQMw+mftM+BAv35tGhTz7TeYJTy-ON1Q@mail.gmail.com>
 <CAE79Dorz-hQPJkq4AUqz6hE+dnWpr5KuUy721xsfWqoRjD0uGA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1109171032030.13829@uplift.swm.pp.se>

On Sat, 17 Sep 2011, Mark Smith wrote:

> Does Huawei still sell (wired) routers under their own brand?

Yes. See NE40E/NE80E/NE5000E.

> The price of these boxes is quite attractive, but there are lots of 
> buts. For example, how much do they have in common with Huawei boxes? 
> Traditionally HP networking gear excluding basic pizzabox switches has 
> not been very convincing.

My opinion is that the H3C stuff from 5 years ago is not generally good. I 
don't know about their current gen. Huawei current gear is decent, they're 
worth testing. If you like them they're as you say, available at a 
generally good price point.

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


From gdxnfx at gmail.com  Sat Sep 17 05:20:35 2011
From: gdxnfx at gmail.com (=?utf-8?B?Z2R4bmZ4?=)
Date: Sat, 17 Sep 2011 18:20:35 +0800
Subject: =?utf-8?B?UmU6IFJlOiBJUFY2IG92ZXIgYSBQUFRQIExpbms=?=
References: <C249D3C3D3E6402BAAEBD07D90BF0E90@work>
Message-ID: <201109171820312503016@gmail.com>


Maybe you can try,i am not sure it will work or not, i don't have the lab to test the script at this moment.


aaa attribute list IPV6
attribute type addrv6 "DHCPv6POOL" protocol ipv6 
!
username ipv6 privilege 0 password ipv6
username ipv6 aaa attribute list IPV6
!


Terry


???? Jared Mauch 
????? 2011-09-16  00:36:58 
???? Meftah Tayeb 
??? nanog 
??? Re: IPV6 over a PPTP Link 
 
I did this in the past without troubles.
http://www.gossamer-threads.com/lists/nsp/ipv6/27525
Should give you some help.
- Jared
-- snip --
! 
vpdn enable 
! 
vpdn-group 1 
! Default PPTP VPDN group 
accept-dialin 
protocol pptp 
virtual-template 1 
! 
interface Virtual-Template1 
ip unnumbered FastEthernet2/0 
ipv6 unnumbered FastEthernet2/0 
ipv6 enable 
ipv6 nd reachable-time 30 
no ipv6 nd suppress-ra 
peer default ip address pool DIAL-IN 
peer default ipv6 pool DIAL-IN6 
ppp encrypt mppe 128 
ppp authentication ms-chap 
ppp ipcp dns 129.250.35.250 129.250.35.251 
! 
ip local pool DIAL-IN 10.10.15.72 10.10.15.79 
ipv6 local pool DIAL-IN6 3ffe:3ffe:0:7080::/62 64
-- snip --
On Sep 15, 2011, at 12:24 PM, Meftah Tayeb wrote:
> Hello,
> can i ofer ipv6 addresses through a PPTP connection using cisco ?
> if yes, how please ?
> Thank you
>    Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/ 
> phone: +21321656139
> Mobile: +213660347746
> 
> 
> __________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6465 (20110915) __________
> 
> Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 

From michael at rancid.berkeley.edu  Sat Sep 17 11:45:18 2011
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Sat, 17 Sep 2011 09:45:18 -0700
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com> <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
 <m2y5xoedhw.wl%randy@psg.com>
 <D181DDABABE57E4DB72FEE00331478643C0769@EALPO1.ukbroadband.com>
 <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>
Message-ID: <4E74CE9E.9020700@rancid.berkeley.edu>

On 09/16/11 08:35, John Curran wrote:
> On Sep 16, 2011, at 10:17 AM, Leigh Porter wrote:
>
>> -----Original Message-----
>>> From: Randy Bush [mailto:randy at psg.com]
>>> Sent: 16 September 2011 16:05
>>> To: John Curran
>>> Cc: NANOG list
>>> Subject: Re: Disappointing ARIN - A great advertisement for the USA ?
>>>
>>>> If you have a particular suggestion for changing whois, please
>>>> feel free to submit it.
>>>
>>> simple.  don't.
>>>
>>> if you want to do something new, don't call it whois.
>>>
>>> randy
>>>
>>
>> Or call it whois and offer the service somewhere else.. Just not in a way that breaks everything.
>
> One approach would be the use of an option flag on the query to obtain
> the new hierarchical output  No flag = no output change.  Would that
> suffice?

I think this would be a good way to proceed.  John, has this been 
suggested as part of ASCP and does it need to be?  If so, I can do it.

We would also need to understand if there would be any disruption to 
users of whois caused by changing the default output back to the 
traditional output.

Thanks to Randy and John for turning this into a reasonable discussion.

michael


From joelja at bogus.com  Sat Sep 17 12:01:12 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Sat, 17 Sep 2011 10:01:12 -0700
Subject: ouch..
In-Reply-To: <4E711B89.3080203@bowenvale.co.nz>
References: <20110914140513.613A5998@resin15.mta.everyone.net>
 <4E711B89.3080203@bowenvale.co.nz>
Message-ID: <4E74D258.4030709@bogus.com>

On 9/14/11 14:24 , Don Gould wrote:

> * Did you know that Cisco has a 100Gb solution?

need more L3 1u TORs with 4 x 40 and 48 x  10...


From joelja at bogus.com  Sat Sep 17 12:06:49 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Sat, 17 Sep 2011 10:06:49 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <4E74D3A9.9070305@bogus.com>

On 9/16/11 13:50 , Nathan Eisenberg wrote:
>>> As an ISP, ARIN will not give you any space if you are new. You
>>> have to already have an equivalent amount of space from another
>>> provider.
>> 
>> does arin *really* still have that amazing barrier to market
>> entry?
> 
> Yes.  If you want PI space, you have to start off with PA space,
> utilize it, and then apply for PI space and an AS #, with contracts
> demonstrating your intention to multihome.  Then, you have to
> *migrate* off the PA space and surrender it back to the 'owner'.  You
> cannot get further PI allocations until you've done this.

The ARIN community is easily it's own worst enemy.





From ikiris at gmail.com  Sat Sep 17 12:28:39 2011
From: ikiris at gmail.com (Blake Dunlap)
Date: Sat, 17 Sep 2011 12:28:39 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <4E74D3A9.9070305@bogus.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com>
Message-ID: <CAJvB4tkBg5sAROQV-S36AJtFw7qqA22acz8XF5D59wqNhc3L-A@mail.gmail.com>

On Sat, Sep 17, 2011 at 12:06, Joel jaeggli <joelja at bogus.com> wrote:

> .
>
> The ARIN community is easily it's own worst enemy.
>
>
Not to mention the difficulty of actually getting a provider to let you
announce their PA IP space to other providers if you already are / want
multihoming.

I just got turned down by one of mine just yesterday for that. I'm looking
at having to keep a T1 at my office with one of my existing providers that
is going away due to footprint issues (Windstream will sell connectivity,
but requires the ip space to be localized, even if originated by customer,
so don't move or expand or anything) just to be able to announce their
number space because H.E. and my other providers refuses to do it outright.

I'm fairly fed up with the bunch at this point, and probably going to cancel
most of my current providers once I get my own space just out of spite.


Forcing PA space for multihoming before a minimum threshold is
understandable, but trying to obtain said PA space can be an exercise in
futility, which is amusing in a perverse way, because some of the providers
are the same employeers of people advocating for exactly that design in PPML
et al. Which is especially annoying coming from a provider that happily did
this for customers so its not like I don't understand the issues etc.

-Blake

From randy at psg.com  Sat Sep 17 12:41:11 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 17 Sep 2011 19:41:11 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <4E74D3A9.9070305@bogus.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com>
Message-ID: <m2iporawy0.wl%randy@psg.com>

>>>> As an ISP, ARIN will not give you any space if you are new. You
>>>> have to already have an equivalent amount of space from another
>>>> provider.
>>> does arin *really* still have that amazing barrier to market
>>> entry?
>> Yes.  If you want PI space, you have to start off with PA space,
>> utilize it, and then apply for PI space and an AS #, with contracts
>> demonstrating your intention to multihome.  Then, you have to
>> *migrate* off the PA space and surrender it back to the 'owner'.  You
>> cannot get further PI allocations until you've done this.
> The ARIN community is easily it's own worst enemy.

the arin policy weenie industry is one of the internet's worst enemies

randy


From jcurran at arin.net  Sat Sep 17 12:47:06 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 17 Sep 2011 17:47:06 +0000
Subject: Disappointing ARIN - A great advertisement for the USA ?
In-Reply-To: <4E74CE9E.9020700@rancid.berkeley.edu>
References: <4E6E7276.2070106@rancid.berkeley.edu>
 <CA93EB60.463DC%markk@arin.net>
 <CAAAwwbWSDh9A39d1+EYZ2MG=EqDSEvDdyhN+eU0HYPUTvyvjZg@mail.gmail.com>
 <CAFPFpmX=sprc9m2CHUfs+bTqW3xUh7zpgK27kvZsc4V-ZAPnGA@mail.gmail.com>
 <CAL9jLaaZyu_EVBQp+-PLCLsgphc6SaaYPQwXDmvqX9OnUL84rg@mail.gmail.com>
 <m2ipotf3bo.wl%randy@psg.com>
 <CAArzuoumgh-8768F8rMMZjK_uxAcQPkSjtjxfvwrvgo=O3mu=w@mail.gmail.com>
 <m2hb4cgan8.wl%randy@psg.com>
 <FE44BC89-E416-4B28-83A9-58E1A9350C96@arin.net>
 <m2y5xoedhw.wl%randy@psg.com>
 <D181DDABABE57E4DB72FEE00331478643C0769@EALPO1.ukbroadband.com>
 <FA2D9593-8682-4CD8-BF3F-5CC62BA893A8@arin.net>
 <4E74CE9E.9020700@rancid.berkeley.edu>
Message-ID: <4545B026-726D-4600-9FC5-38C0F64CEE12@arin.net>

On Sep 17, 2011, at 12:45 PM, Michael Sinatra wrote:

>> One approach would be the use of an option flag on the query to obtain
>> the new hierarchical output  No flag = no output change.  Would that
>> suffice?
> 
> I think this would be a good way to proceed.  John, has this been suggested as part of ASCP and does it need to be?  If so, I can do it.

No need to submit it; I have the action item.

> We would also need to understand if there would be any disruption to users of whois caused by changing the default output back to the traditional output.

One hopes not, but prudence calls for adequate prior notice so that 
folks can test and plan accordingly.  Expect more information shortly.

/John

John Curran
President and CEO
ARIN



From cb.list6 at gmail.com  Sat Sep 17 12:51:08 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sat, 17 Sep 2011 10:51:08 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2iporawy0.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
Message-ID: <CAD6AjGR1WaiN0HQknvkDbfYdq4k6j7uVWcrQ8=qPs2QTefBwiw@mail.gmail.com>

On Sep 17, 2011 10:41 AM, "Randy Bush" <randy at psg.com> wrote:
>
> >>>> As an ISP, ARIN will not give you any space if you are new. You
> >>>> have to already have an equivalent amount of space from another
> >>>> provider.
> >>> does arin *really* still have that amazing barrier to market
> >>> entry?
> >> Yes.  If you want PI space, you have to start off with PA space,
> >> utilize it, and then apply for PI space and an AS #, with contracts
> >> demonstrating your intention to multihome.  Then, you have to
> >> *migrate* off the PA space and surrender it back to the 'owner'.  You
> >> cannot get further PI allocations until you've done this.
> > The ARIN community is easily it's own worst enemy.
>
> the arin policy weenie industry is one of the internet's worst enemies
>
> randy
>

+1

I will echo my displeasure with the idea that you can only get a lot if you
already have a lot.  This mess is enough to make cgn look appealing...

One more reason we can all do ourselves a favor by moving to ipv6, remove
the number scarcity issue and associated baggage of begging for numbers

Cb

From owen at delong.com  Sat Sep 17 12:55:28 2011
From: owen at delong.com (Owen DeLong)
Date: Sat, 17 Sep 2011 10:55:28 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2iporawy0.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
Message-ID: <489893F2-CDA8-4B75-B1C0-B2B14C91291C@delong.com>

All of the speculation and comment on this thread has been something
to watch, but, it's not actually all that accurate.

https://www.arin.net/policy/nrpm.html#four2

NRPM 4.2 provides several ways in which an ISP can qualify for space

As has been mentioned in this thread, efficiently using a PA allocation
from an upstream provider is one such mechanism. (4.2.2.1, 4.2.2.2).

However, if you can show an immediate need for a /22 or more within
the next 30 days (not particularly hard if you are building an ISP), you
can qualify under 4.2.1.6 without any prior utilization.

I know of a number of ISPs that have obtained their initial allocations in
this manner.

Owen



From rekoil at semihuman.com  Sat Sep 17 13:05:33 2011
From: rekoil at semihuman.com (Chris Woodfield)
Date: Sat, 17 Sep 2011 11:05:33 -0700
Subject: ouch..
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <20110914111508.GA6498@brian> <4E708E18.3070006@geier.ne.tz>
 <00a601cc72d5$3dc653b0$b952fb10$@com> <001601cc72db$1cd5a6f0$5680f4d0$@com>
 <20110914125605.GA10496@pob.ytti.fi>
 <CAD69L80_7KS3GEjv57UH5EsqAxQLssP1R3EFAmhUdLZamU4iwA@mail.gmail.com>
 <1316007415.15630.12.camel@m6.u226.com>
 <D181DDABABE57E4DB72FEE00331478643BF621@EALPO1.ukbroadband.com>
Message-ID: <72250A46-EDE2-4AA3-9E99-0996FA22B89E@semihuman.com>

Or..."Go ahead and keep buying 6509 chassis, the 7600 brand is just a marketing thing"

-C

On Sep 14, 2011, at 7:41 AM, Leigh Porter wrote:

> 
> 
>> -----Original Message-----
>> From: Always Learning [mailto:nanog at u61.u22.net]
>> Sent: 14 September 2011 14:39
>> To: N. Max Pierson
>> Cc: nanog at nanog.org
>> Subject: Re: ouch..
>> 
>> 
>> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
>> 
>>> Either way, it's pathetic. If someone is going to slander in the
>>> fashion the site has done, they should at least put a contact form
>>> somewhere for some feedback :)
>> 
>> Slander means falsehood. Cisco tells lies ?
>> 
>> 
>> --
>> With best regards,
>> 
>> Paul.
>> England,
>> EU.
> 
> 
> Lies? So who has 100G MX series cards then..?
> 
> --
> Leigh
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 



From jcurran at arin.net  Sat Sep 17 13:10:10 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 17 Sep 2011 18:10:10 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2iporawy0.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
Message-ID: <06B724A8-01D7-460C-A0FB-FF10694757CD@arin.net>

On Sep 17, 2011, at 1:41 PM, Randy Bush wrote:

>>> Yes.  If you want PI space, you have to start off with PA space,
>>> utilize it, and then apply for PI space and an AS #, with contracts
>>> demonstrating your intention to multihome.  Then, you have to
>>> *migrate* off the PA space and surrender it back to the 'owner'.  You
>>> cannot get further PI allocations until you've done this.
>> The ARIN community is easily it's own worst enemy.
> 
> the arin policy weenie industry is one of the internet's worst enemies

Randy - 
 
  I have absolutely no doubt that there are sufficient folks 
  participating in NANOG to get nearly any policy desired 
  through the ARIN policy process. To the extent that folks 
  don't care to learn the current policies and participate in 
  the policy development process, they end up supporting the 
  current policies through their inaction.

/John

John Curran
President and CEO
ARIN

  


From rcarpen at network1.net  Sat Sep 17 13:13:22 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Sat, 17 Sep 2011 14:13:22 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <489893F2-CDA8-4B75-B1C0-B2B14C91291C@delong.com>
Message-ID: <462737ff-25e5-4846-9ac5-061cf580824b@zimbra.network1.net>


----- Original Message -----
> All of the speculation and comment on this thread has been something
> to watch, but, it's not actually all that accurate.
> 
> https://www.arin.net/policy/nrpm.html#four2
> 
> NRPM 4.2 provides several ways in which an ISP can qualify for space
> 
> As has been mentioned in this thread, efficiently using a PA
> allocation
> from an upstream provider is one such mechanism. (4.2.2.1, 4.2.2.2).
> 
> However, if you can show an immediate need for a /22 or more within
> the next 30 days (not particularly hard if you are building an ISP),
> you
> can qualify under 4.2.1.6 without any prior utilization.
> 
> I know of a number of ISPs that have obtained their initial
> allocations in
> this manner.
> 
> Owen

I have a small ISP customer who is not multi-homed, and is using about a /21 and a half of space, and is expanding. Their upstream is refusing to give them more space, so they wanted to get their own, and give back the space to the upstream, with the possible exception of a small block for their servers, which would be very difficult to renumber. We explained this all, and the response we got from ARIN was that we needed to have a full /20 from the upstream, at which time we could easily get a /20 of new space. In order to qualify for the immediate need, we would need to show need for the entire /20, of which we would need to fully utilize (renumber into) within 30 days. That is not even remotely possible.

The problem with this whole thing is that I have no less than 4 ISPs that are in almost the same boat.

-Randy


From jcurran at arin.net  Sat Sep 17 13:19:24 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 17 Sep 2011 18:19:24 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <4E73A75D.50002@knownelement.com>
References: <4E73A75D.50002@knownelement.com>
Message-ID: <72847EAE-636C-4255-A77A-BDD021802B3D@arin.net>

On Sep 16, 2011, at 3:45 PM, Charles N Wyble wrote:
> 
> 2) Obtain ipv6 space from ARIN (inquired about getting space and ran into some issues. need to speak with my co founder and get details. evidently getting brand new v6 space for a brand new network is fairly difficult. for now may just announce a /48 from he.net. ) 

Charles - 
 
Criteria for new IPv6 allocations is here: https://www.arin.net/policy/nrpm.html#six51, and includes meeting any of one the following:

 ? Having a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries, or;
 ? Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or;
 ? By providing a reasonable plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years.

I'm not certain how this is "fairly difficult", but can have someone from the ARIN Registration Services helpdesk contact you to work through your circumstances.  (please contact me directly if that's desired.)

FYI,
/John

John Curran
President and CEO
ARIN




From jcurran at arin.net  Sat Sep 17 13:22:17 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 17 Sep 2011 18:22:17 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <462737ff-25e5-4846-9ac5-061cf580824b@zimbra.network1.net>
References: <462737ff-25e5-4846-9ac5-061cf580824b@zimbra.network1.net>
Message-ID: <C5087CD8-9FDB-474F-92F7-27B4CBB13FC6@arin.net>

On Sep 17, 2011, at 2:13 PM, Randy Carpenter wrote:

> I have a small ISP customer who is not multi-homed, and is using about a /21 and a half of space, and is expanding. Their upstream is refusing to give them more space, so they wanted to get their own, and give back the space to the upstream, with the possible exception of a small block for their servers, which would be very difficult to renumber. We explained this all, and the response we got from ARIN was that we needed to have a full /20 from the upstream, at which time we could easily get a /20 of new space. In order to qualify for the immediate need, we would need to show need for the entire /20, of which we would need to fully utilize (renumber into) within 30 days. That is not even remotely possible.
> 
> The problem with this whole thing is that I have no less than 4 ISPs that are in almost the same boat.

Randy - 
 
  If that policy is an issue for many of your customers, can you 
  please come up with an alternative policy for consideration by
  the community?  

Thanks!
/John

John Curran
President and CEO
ARIN





From owen at delong.com  Sat Sep 17 13:24:48 2011
From: owen at delong.com (Owen DeLong)
Date: Sat, 17 Sep 2011 11:24:48 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <72847EAE-636C-4255-A77A-BDD021802B3D@arin.net>
References: <4E73A75D.50002@knownelement.com>
 <72847EAE-636C-4255-A77A-BDD021802B3D@arin.net>
Message-ID: <698606D3-09D3-4967-A9B9-78F0BA810078@delong.com>


On Sep 17, 2011, at 11:19 AM, John Curran wrote:

> On Sep 16, 2011, at 3:45 PM, Charles N Wyble wrote:
>> 
>> 2) Obtain ipv6 space from ARIN (inquired about getting space and ran into some issues. need to speak with my co founder and get details. evidently getting brand new v6 space for a brand new network is fairly difficult. for now may just announce a /48 from he.net. ) 
> 
> Charles - 
> 
> Criteria for new IPv6 allocations is here: https://www.arin.net/policy/nrpm.html#six51, and includes meeting any of one the following:
> 
> ? Having a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries, or;
> ? Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or;
> ? By providing a reasonable plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years.
> 
> I'm not certain how this is "fairly difficult", but can have someone from the ARIN Registration Services helpdesk contact you to work through your circumstances.  (please contact me directly if that's desired.)
> 

And it is about to get even easier under 2011-3 when it is implemented:

https://www.arin.net/policy/proposals/2011_3.html

Owen



From owen at delong.com  Sat Sep 17 13:27:56 2011
From: owen at delong.com (Owen DeLong)
Date: Sat, 17 Sep 2011 11:27:56 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <462737ff-25e5-4846-9ac5-061cf580824b@zimbra.network1.net>
References: <462737ff-25e5-4846-9ac5-061cf580824b@zimbra.network1.net>
Message-ID: <92BC53CF-5B28-4001-9B34-E086D0CEA393@delong.com>


On Sep 17, 2011, at 11:13 AM, Randy Carpenter wrote:

> 
> ----- Original Message -----
>> All of the speculation and comment on this thread has been something
>> to watch, but, it's not actually all that accurate.
>> 
>> https://www.arin.net/policy/nrpm.html#four2
>> 
>> NRPM 4.2 provides several ways in which an ISP can qualify for space
>> 
>> As has been mentioned in this thread, efficiently using a PA
>> allocation
>> from an upstream provider is one such mechanism. (4.2.2.1, 4.2.2.2).
>> 
>> However, if you can show an immediate need for a /22 or more within
>> the next 30 days (not particularly hard if you are building an ISP),
>> you
>> can qualify under 4.2.1.6 without any prior utilization.
>> 
>> I know of a number of ISPs that have obtained their initial
>> allocations in
>> this manner.
>> 
>> Owen
> 
> I have a small ISP customer who is not multi-homed, and is using about a /21 and a half of space, and is expanding. Their upstream is refusing to give them more space, so they wanted to get their own, and give back the space to the upstream, with the possible exception of a small block for their servers, which would be very difficult to renumber. We explained this all, and the response we got from ARIN was that we needed to have a full /20 from the upstream, at which time we could easily get a /20 of new space. In order to qualify for the immediate need, we would need to show need for the entire /20, of which we would need to fully utilize (renumber into) within 30 days. That is not even remotely possible.
> 

Or, they could easily multihome and qualify at a much smaller threshold.

> The problem with this whole thing is that I have no less than 4 ISPs that are in almost the same boat.

Then propose a policy change to rectify it.

Owen



From charles at knownelement.com  Sat Sep 17 14:20:11 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Sat, 17 Sep 2011 14:20:11 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <72847EAE-636C-4255-A77A-BDD021802B3D@arin.net>
References: <4E73A75D.50002@knownelement.com>
 <72847EAE-636C-4255-A77A-BDD021802B3D@arin.net>
Message-ID: <4E74F2EB.2030703@knownelement.com>

On 09/17/2011 01:19 PM, John Curran wrote:
> On Sep 16, 2011, at 3:45 PM, Charles N Wyble wrote:
>> 2) Obtain ipv6 space from ARIN (inquired about getting space and ran into some issues. need to speak with my co founder and get details. evidently getting brand new v6 space for a brand new network is fairly difficult. for now may just announce a /48 from he.net. )
> Charles -
>
> Criteria for new IPv6 allocations is here: https://www.arin.net/policy/nrpm.html#six51, and includes meeting any of one the following:

Thanks for the link.

>   ? Having a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries, or;

Sure.

>   ? Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or;

That is our goal. I have two upstreams who are ready to peer with me 
once I obtain an ASN.
>   ? By providing a reasonable plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years.

We submitted a numbering / subnet plan with our application, and stated 
we intended to multihome. Essentially we are trying to get both ASN and 
IP space at the same time. Bit of a chicken and egg problem perhaps.


Time to secure those letters of authorization and get that ASN. I think 
once we have that, the process should move forward pretty rapidly.


> I'm not certain how this is "fairly difficult", but can have someone from the ARIN Registration Services helpdesk contact you to work through your circumstances.  (please contact me directly if that's desired.)

I may take you up on that. Thanks for the offer to assist. I'll read 
over the doc you sent and the sections Owen mentioned. I think I just 
didn't have enough information on the process. Looks like this will be 
very straightforward.





From joelja at bogus.com  Sat Sep 17 15:21:40 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Sat, 17 Sep 2011 13:21:40 -0700
Subject: Traceroute losses through NYC1.gblx.net?
In-Reply-To: <CE188505-3E93-4F9E-94E2-C65EA0B7C7B7@simons-rock.edu>
References: <CE188505-3E93-4F9E-94E2-C65EA0B7C7B7@simons-rock.edu>
Message-ID: <4E750154.1070009@bogus.com>

On 9/16/11 11:42 , Steve Bohrer wrote:
> My general question is "what meaning do I give to lossy traceroutes,
> even when pings show no problem."
> 
> Can I expect that backbone routers should never give me timeouts on a
> traceroute through them, so, lots of asterisks from these systems
> indicate a packet loss problem that needs to be fixed?

generation of icmp exceptions e.g. ttl exceeded can/is delberately rate
limited, such traffic is sent up to the control plane. if a router is
passing traffic loss free through the forwarding plane then you can
conclude that it's loss free through the forwarding plane.

> Or, are these traceroute asterisks essentially meaningless, and should
> be expected on any busy link?

more like it's not trivial to conclude what they mean.



From randy at psg.com  Sat Sep 17 16:05:53 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 17 Sep 2011 23:05:53 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <CAD6AjGR1WaiN0HQknvkDbfYdq4k6j7uVWcrQ8=qPs2QTefBwiw@mail.gmail.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <CAD6AjGR1WaiN0HQknvkDbfYdq4k6j7uVWcrQ8=qPs2QTefBwiw@mail.gmail.com>
Message-ID: <m2hb4ac21a.wl%randy@psg.com>

> One more reason we can all do ourselves a favor by moving to ipv6,
> remove the number scarcity issue and associated baggage of begging for
> numbers

silly hope.  we created monopoly organizations.  this kind of thing is
self-perpetuating.

randy


From randy at psg.com  Sat Sep 17 16:06:58 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 17 Sep 2011 23:06:58 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <06B724A8-01D7-460C-A0FB-FF10694757CD@arin.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <06B724A8-01D7-460C-A0FB-FF10694757CD@arin.net>
Message-ID: <m2fwjuc1zh.wl%randy@psg.com>

>   I have absolutely no doubt that there are sufficient folks 
>   participating in NANOG to get nearly any policy desired 
>   through the ARIN policy process. To the extent that folks 
>   don't care to learn the current policies and participate in 
>   the policy development process, they end up supporting the 
>   current policies through their inaction.

the disgust factor is a major barrier to 'participation.'

randy


From jcurran at arin.net  Sat Sep 17 16:12:41 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 17 Sep 2011 21:12:41 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2fwjuc1zh.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <06B724A8-01D7-460C-A0FB-FF10694757CD@arin.net> <m2fwjuc1zh.wl%randy@psg.com>
Message-ID: <84932893-1A74-4148-B144-6AD0BCB98F5C@arin.net>

On Sep 17, 2011, at 5:06 PM, Randy Bush wrote:

>>  I have absolutely no doubt that there are sufficient folks 
>>  participating in NANOG to get nearly any policy desired 
>>  through the ARIN policy process. To the extent that folks 
>>  don't care to learn the current policies and participate in 
>>  the policy development process, they end up supporting the 
>>  current policies through their inaction.
> 
> the disgust factor is a major barrier to 'participation.'

Strange...  You seem to overcome it well enough to join in the
discussion on PPML, but not to actual propose changes to policy.

That's your choice.

/John

John Curran
President and CEO
ARIN



From randy at psg.com  Sat Sep 17 16:15:05 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 17 Sep 2011 23:15:05 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <84932893-1A74-4148-B144-6AD0BCB98F5C@arin.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <06B724A8-01D7-460C-A0FB-FF10694757CD@arin.net>
 <m2fwjuc1zh.wl%randy@psg.com>
 <84932893-1A74-4148-B144-6AD0BCB98F5C@arin.net>
Message-ID: <m2d3eyc1ly.wl%randy@psg.com>

>>>  I have absolutely no doubt that there are sufficient folks 
>>>  participating in NANOG to get nearly any policy desired 
>>>  through the ARIN policy process. To the extent that folks 
>>>  don't care to learn the current policies and participate in 
>>>  the policy development process, they end up supporting the 
>>>  current policies through their inaction.
>> the disgust factor is a major barrier to 'participation.'
> Strange...  You seem to overcome it well enough to join in the
> discussion on PPML, but not to actual propose changes to policy.

i believe you are mistaken.  i am not knowingly a subscriber to ppml,
and am not, to the best of my knowledge, participating in any
discussion(s) there.

randy


From jcurran at arin.net  Sat Sep 17 16:18:49 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 17 Sep 2011 21:18:49 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2hb4ac21a.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <CAD6AjGR1WaiN0HQknvkDbfYdq4k6j7uVWcrQ8=qPs2QTefBwiw@mail.gmail.com>
 <m2hb4ac21a.wl%randy@psg.com>
Message-ID: <D5ABDB1A-1CD7-4B41-B91C-27584E73E40A@arin.net>

On Sep 17, 2011, at 5:05 PM, Randy Bush wrote:

>> One more reason we can all do ourselves a favor by moving to ipv6,
>> remove the number scarcity issue and associated baggage of begging for
>> numbers
> 
> silly hope.  we created monopoly organizations.  this kind of thing is
> self-perpetuating.

Randy - If you wish to propose an alternative which accomplishes the mission 
in a different manner, feel free to do so. The community has every opportunity 
and right to accomplish unique Internet number administration as it sees fit.

/John

John Curran
President and CEO
ARIN






From randy at psg.com  Sat Sep 17 16:19:37 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 17 Sep 2011 23:19:37 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2d3eyc1ly.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <06B724A8-01D7-460C-A0FB-FF10694757CD@arin.net>
 <m2fwjuc1zh.wl%randy@psg.com>
 <84932893-1A74-4148-B144-6AD0BCB98F5C@arin.net>
 <m2d3eyc1ly.wl%randy@psg.com>
Message-ID: <m2bouic1ee.wl%randy@psg.com>

>> Strange...  You seem to overcome it well enough to join in the
>> discussion on PPML, but not to actual propose changes to policy.
> i believe you are mistaken.  i am not knowingly a subscriber to ppml,
> and am not, to the best of my knowledge, participating in any
> discussion(s) there.

a search of my inbound and outbound mail for the last ten days shows no
mail to or from "ppml."

so i can debug, could you please forward to me a message where you
believe i am participating in ppml?

randy


From randy at psg.com  Sat Sep 17 16:23:15 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 17 Sep 2011 23:23:15 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <D5ABDB1A-1CD7-4B41-B91C-27584E73E40A@arin.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <CAD6AjGR1WaiN0HQknvkDbfYdq4k6j7uVWcrQ8=qPs2QTefBwiw@mail.gmail.com>
 <m2hb4ac21a.wl%randy@psg.com>
 <D5ABDB1A-1CD7-4B41-B91C-27584E73E40A@arin.net>
Message-ID: <m2aaa2c18c.wl%randy@psg.com>

>>> One more reason we can all do ourselves a favor by moving to ipv6,
>>> remove the number scarcity issue and associated baggage of begging for
>>> numbers
>> silly hope.  we created monopoly organizations.  this kind of thing is
>> self-perpetuating.
> Randy - If you wish to propose an alternative which accomplishes the
> mission in a different manner, feel free to do so. The community has
> every opportunity and right to accomplish unique Internet number
> administration as it sees fit.

rick adams was right.  this could be done very minimally with some
software and maybe six to ten folk to back it up.  organizations with 50
to 130 people and budgets of tens of millions of dollars per year should
be embarrassing.

randy


From jcurran at arin.net  Sat Sep 17 16:32:38 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 17 Sep 2011 21:32:38 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2aaa2c18c.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <CAD6AjGR1WaiN0HQknvkDbfYdq4k6j7uVWcrQ8=qPs2QTefBwiw@mail.gmail.com>
 <m2hb4ac21a.wl%randy@psg.com>
 <D5ABDB1A-1CD7-4B41-B91C-27584E73E40A@arin.net> <m2aaa2c18c.wl%randy@psg.com>
Message-ID: <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>

On Sep 17, 2011, at 5:23 PM, Randy Bush wrote:
>> Randy - If you wish to propose an alternative which accomplishes the
>> mission in a different manner, feel free to do so. The community has
>> every opportunity and right to accomplish unique Internet number
>> administration as it sees fit.
> 
> rick adams was right.  this could be done very minimally with some
> software and maybe six to ten folk to back it up.  

I actually agree with you that it could be done with less people, 
if you want to do away with the policies altogether and the biannual 
meetings discussing the same, the need for elections for an ARIN AC
and meetings, the coordination with the other RIRs and ICANN, and 
the engagement with organizations such as ISOC, IGF, and ITU.  We 
will be talking about the costs of running ARIN on the last day of 
the ARIN meeting in Philly in case you want more details on the cost
side of the equation and the value delivered.

/John

John Curran
President and CEO
ARIN



From randy at psg.com  Sat Sep 17 16:37:46 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 17 Sep 2011 23:37:46 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <CAD6AjGR1WaiN0HQknvkDbfYdq4k6j7uVWcrQ8=qPs2QTefBwiw@mail.gmail.com>
 <m2hb4ac21a.wl%randy@psg.com>
 <D5ABDB1A-1CD7-4B41-B91C-27584E73E40A@arin.net>
 <m2aaa2c18c.wl%randy@psg.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
Message-ID: <m28vpmc0k5.wl%randy@psg.com>

>> rick adams was right.  this could be done very minimally with some
>> software and maybe six to ten folk to back it up.  

gedanken experiment.  instead of frelling up whois, printing comic
books, and playing weenie regulators, design and describe an rir with a
sign on the door which says "internet number bookkeeper," has a high
level of automation, two sw engs to maintain it, two support people, two
people to shovel paper and a small bit of money, and one to post overly
aggressive defensive messages on nanog.

and you still owe me a copy of my alleged posting(s) to ppml.

randy


From jcurran at arin.net  Sat Sep 17 16:39:32 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 17 Sep 2011 21:39:32 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2bouic1ee.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <06B724A8-01D7-460C-A0FB-FF10694757CD@arin.net>
 <m2fwjuc1zh.wl%randy@psg.com>
 <84932893-1A74-4148-B144-6AD0BCB98F5C@arin.net>
 <m2d3eyc1ly.wl%randy@psg.com> <m2bouic1ee.wl%randy@psg.com>
Message-ID: <49D96523-FE3F-407B-A973-46E5D39A372C@arin.net>

On Sep 17, 2011, at 5:19 PM, Randy Bush wrote:

>>> Strange...  You seem to overcome it well enough to join in the
>>> discussion on PPML, but not to actual propose changes to policy.
>> i believe you are mistaken.  i am not knowingly a subscriber to ppml,
>> and am not, to the best of my knowledge, participating in any
>> discussion(s) there.
> 
> a search of my inbound and outbound mail for the last ten days shows no
> mail to or from "ppml."
> 
> so i can debug, could you please forward to me a message where you
> believe i am participating in ppml?

Attached; this doesn't count your commentary of ARIN policies on other 
mailing lists, as it would be more numerous but less productive.

In any case, we've fully left the realm of operational matters and
scope of the NANOG list. 

/John

Begin forwarded message:

> From: Randy Bush <randy at psg.com>
> Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for	an	IPv6	naysayer...)
> Date: February 21, 2011 9:00:50 PM EST
> To: Dan Wing <dwing at cisco.com>
> Cc: 'NANOG list' <nanog at nanog.org>, 'ARIN-PPML List' <arin-ppml at arin.net>
> 
>>> http://tools.ietf.org/html/draft-donley-nat444-impacts-01
>> That document conflates problems of NAT444 with problems of NAT44 
>> with problems of bandwidth starvation with problems of CGN.
> 
> it may require a delicate palate to differentiate the different flavors
> of <bleep>
> 
> randy
> 




From randy at psg.com  Sat Sep 17 16:42:52 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 17 Sep 2011 23:42:52 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <49D96523-FE3F-407B-A973-46E5D39A372C@arin.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <06B724A8-01D7-460C-A0FB-FF10694757CD@arin.net>
 <m2fwjuc1zh.wl%randy@psg.com>
 <84932893-1A74-4148-B144-6AD0BCB98F5C@arin.net>
 <m2d3eyc1ly.wl%randy@psg.com> <m2bouic1ee.wl%randy@psg.com>
 <49D96523-FE3F-407B-A973-46E5D39A372C@arin.net>
Message-ID: <m27h56c0bn.wl%randy@psg.com>

>> From: Randy Bush <randy at psg.com>
>> Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for	an	IPv6	naysayer...)
>> Date: February 21, 2011 9:00:50 PM EST
>> To: Dan Wing <dwing at cisco.com>
>> Cc: 'NANOG list' <nanog at nanog.org>, 'ARIN-PPML List' <arin-ppml at arin.net>
>> 
>>>> http://tools.ietf.org/html/draft-donley-nat444-impacts-01
>>> That document conflates problems of NAT444 with problems of NAT44 
>>> with problems of bandwidth starvation with problems of CGN.
>> 
>> it may require a delicate palate to differentiate the different flavors
>> of <bleep>
>> 
>> randy

sorry, it looks like six months ago i hit reply to a message where ppml
was cc:ed.  as i was not a ppml subscriber, i presume it did not even
make it to the ppml list.

randy


From randy at psg.com  Sat Sep 17 16:45:04 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 17 Sep 2011 23:45:04 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m27h56c0bn.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <6f8a8faf-ab5d-4130-8b22-94bf874e2595@zimbra.network1.net>
 <m262ksdy1t.wl%randy@psg.com>
 <8C26A4FDAE599041A13EB499117D3C286B569FFB@ex-mb-1.corp.atlasnetworks.us>
 <4E74D3A9.9070305@bogus.com> <m2iporawy0.wl%randy@psg.com>
 <06B724A8-01D7-460C-A0FB-FF10694757CD@arin.net>
 <m2fwjuc1zh.wl%randy@psg.com>
 <84932893-1A74-4148-B144-6AD0BCB98F5C@arin.net>
 <m2d3eyc1ly.wl%randy@psg.com> <m2bouic1ee.wl%randy@psg.com>
 <49D96523-FE3F-407B-A973-46E5D39A372C@arin.net>
 <m27h56c0bn.wl%randy@psg.com>
Message-ID: <m262kqc07z.wl%randy@psg.com>

>>> From: Randy Bush <randy at psg.com>
>>> Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for	an	IPv6	naysayer...)
>>> Date: February 21, 2011 9:00:50 PM EST
>>> To: Dan Wing <dwing at cisco.com>
>>> Cc: 'NANOG list' <nanog at nanog.org>, 'ARIN-PPML List' <arin-ppml at arin.net>
>>> 
>>>>> http://tools.ietf.org/html/draft-donley-nat444-impacts-01
>>>> That document conflates problems of NAT444 with problems of NAT44 
>>>> with problems of bandwidth starvation with problems of CGN.
>>> 
>>> it may require a delicate palate to differentiate the different flavors
>>> of <bleep>
>>> 
>>> randy
> 
> sorry, it looks like six months ago i hit reply to a message where ppml
> was cc:ed.  as i was not a ppml subscriber, i presume it did not even
> make it to the ppml list.
> 
> randy

oh, and i did propose an alternative solution to the problems of which
the above complained.  see rfc 6346.

randy


From rcarpen at network1.net  Sat Sep 17 18:52:03 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Sat, 17 Sep 2011 19:52:03 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <92BC53CF-5B28-4001-9B34-E086D0CEA393@delong.com>
Message-ID: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>


> > I have a small ISP customer who is not multi-homed, and is using
> > about a /21 and a half of space, and is expanding. Their upstream
> > is refusing to give them more space, so they wanted to get their
> > own, and give back the space to the upstream, with the possible
> > exception of a small block for their servers, which would be very
> > difficult to renumber. We explained this all, and the response we
> > got from ARIN was that we needed to have a full /20 from the
> > upstream, at which time we could easily get a /20 of new space. In
> > order to qualify for the immediate need, we would need to show
> > need for the entire /20, of which we would need to fully utilize
> > (renumber into) within 30 days. That is not even remotely
> > possible.
> > 
> 
> Or, they could easily multihome and qualify at a much smaller
> threshold.

Unfortunately, this is prohibitively expensive. They are small rural telcos who are connected to a collective state-wide fiber network. Any second provider would could an order of magnitude (or more) more than what they have, and would likely be delivered over the same fiber network anyway.
 
> > The problem with this whole thing is that I have no less than 4
> > ISPs that are in almost the same boat.
> 
> Then propose a policy change to rectify it.

Noted, and planned :-)

-Randy


From jra at baylink.com  Sat Sep 17 20:42:49 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 17 Sep 2011 21:42:49 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <462737ff-25e5-4846-9ac5-061cf580824b@zimbra.network1.net>
Message-ID: <16768041.2191.1316310169735.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Randy Carpenter" <rcarpen at network1.net>

> I have a small ISP customer who is not multi-homed, and is using about
> a /21 and a half of space, and is expanding. Their upstream is
> refusing to give them more space, so they wanted to get their own, and
> give back the space to the upstream, with the possible exception of a
> small block for their servers, which would be very difficult to
> renumber. We explained this all, and the response we got from ARIN was
> that we needed to have a full /20 from the upstream, at which time we
> could easily get a /20 of new space. In order to qualify for the
> immediate need, we would need to show need for the entire /20, of
> which we would need to fully utilize (renumber into) within 30 days.
> That is not even remotely possible.

And worse, it violates best practices[1] rather thoroughly.

Cheers,
-- jra
[1]Never expand to anything smaller than twice what you have now.
-- 
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      http://photo.imageinc.us             +1 727 647 1274


From rdobbins at arbor.net  Sun Sep 18 00:24:15 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sun, 18 Sep 2011 05:24:15 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <4E73AB36.10204@knownelement.com>
References: <4E73A75D.50002@knownelement.com>
 <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <4E73AB36.10204@knownelement.com>
Message-ID: <D0AAF090-9C66-4C6B-82C8-2BD7F30466A8@arbor.net>

On Sep 17, 2011, at 3:01 AM, Charles N Wyble wrote:

> One aspect of my network, will be operational transparency. So as much as possible will be viewable in real time. This includes v4/v6 traffic statistics.

These books are required reading, IMHO:

<http://www.amazon.com/Practical-BGP-Russ-White/dp/0321127005/>

<http://www.amazon.com/Router-Security-Strategies-Securing-Network/dp/1587053365/>

<http://www.amazon.com/Network-Flow-Analysis-Michael-Lucas/dp/1593272030/>

Also, see the following:

<https://files.me.com/roland.dobbins/c07vk1>

<https://files.me.com/roland.dobbins/y4ykq0>

<https://files.me.com/roland.dobbins/prguob>

<https://files.me.com/roland.dobbins/k4zw3x>

<https://files.me.com/roland.dobbins/dweagy>

<https://files.me.com/roland.dobbins/9i8xwl>

<https://files.me.com/roland.dobbins/m4g34u>

<https://files.me.com/roland.dobbins/679xji>

<https://files.me.com/roland.dobbins/l53gjr>

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From charles at knownelement.com  Sun Sep 18 00:58:15 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Sun, 18 Sep 2011 00:58:15 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
Message-ID: <4E758877.5070002@knownelement.com>

On 09/17/2011 06:52 PM, Randy Carpenter wrote:
>>> I have a small ISP customer who is not multi-homed, and is using
>>> about a /21 and a half of space, and is expanding. Their upstream
>>> is refusing to give them more space, so they wanted to get their
>>> own, and give back the space to the upstream, with the possible
>>> exception of a small block for their servers, which would be very
>>> difficult to renumber. We explained this all, and the response we
>>> got from ARIN was that we needed to have a full /20 from the
>>> upstream, at which time we could easily get a /20 of new space. In
>>> order to qualify for the immediate need, we would need to show
>>> need for the entire /20, of which we would need to fully utilize
>>> (renumber into) within 30 days. That is not even remotely
>>> possible.
>>>
>> Or, they could easily multihome and qualify at a much smaller
>> threshold.
> Unfortunately, this is prohibitively expensive. They are small rural telcos who are connected to a collective state-wide fiber network. Any second provider would could an order of magnitude (or more) more than what they have, and would likely be delivered over the same fiber network anyway.

Um.... really? You can't find anyone out there who would give you an
LOA? No friendly ISP? I'm getting LOA from a buddy of mine that
administers a couple existing ISP networks. It's not that difficult in
my opinion. I mean does it have to be a wireline upstream provider? Or
can it just be any AS who is friendly? I guess it's different for me as
this is a green field deployment and I expect to peer all over the
United States at dozens of POPS. As opposed to being a more traditional
access network provider in a particular geographic region.



>  
>>> The problem with this whole thing is that I have no less than 4
>>> ISPs that are in almost the same boat.
>> Then propose a policy change to rectify it.
> Noted, and planned :-)

I look forward to those discussions. I'm kind of intrigued by policy
now, after starting this process. At first I was a bit irritated but now
after John/Owen posted links and comments, it's a walk in the park. Just
waiting on an LOA from my buddy and I should be able to get that ASN and
associated /32.


-- 
Charles N Wyble charles at knownelement.com @charlesnw on twitter

http://blog.knownelement.com

Building alternative,global scale,secure, cost effective bit moving platform
for tomorrows alternate default free zone.



From a.harrowell at gmail.com  Sun Sep 18 09:17:56 2011
From: a.harrowell at gmail.com (Alexander Harrowell)
Date: Sun, 18 Sep 2011 15:17:56 +0100
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m28vpmc0k5.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net> <m28vpmc0k5.wl%randy@psg.com>
Message-ID: <201109181518.10864.a.harrowell@gmail.com>

On Saturday 17 Sep 2011 22:37:46 Randy Bush wrote:
> one to post overly aggressive defensive messages on nanog

I am not convinced that Mr. Bush is best placed to comment on this 
particular issue.

-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110918/ee733fda/attachment.bin>

From randy at psg.com  Sun Sep 18 09:24:20 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 18 Sep 2011 16:24:20 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <201109181518.10864.a.harrowell@gmail.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com>
Message-ID: <m2ty8a9be3.wl%randy@psg.com>

>> one to post overly aggressive defensive messages on nanog
> I am not convinced that Mr. Bush is best placed to comment on this
> particular issue.

you seem to have a problem differentiating defense from offense.  i
recommend you not play chess.  :)

randy


From jcurran at arin.net  Sun Sep 18 09:39:32 2011
From: jcurran at arin.net (John Curran)
Date: Sun, 18 Sep 2011 14:39:32 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2ty8a9be3.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com> <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
Message-ID: <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>

On Sep 18, 2011, at 10:24 AM, Randy Bush wrote:
> 
>>> one to post overly aggressive defensive messages on nanog
>> I am not convinced that Mr. Bush is best placed to comment on this
>> particular issue.
> 
> you seem to have a problem differentiating defense from offense.  i
> recommend you not play chess.  :)

Randy is perfectly right in expressing his concerns about the registry
system that we've built (as long as its on a mailing list which supports
the topic), since we're doing a function on behalf of the entire Internet
community and spending everyone's money in the process.  While it may not
matter to him a bit, I'll defend his (and anyone's else right) to critique 
the quality and cost effectiveness of the job we're doing.  

/John

John Curran
President and CEO
ARIN




From randy at psg.com  Sun Sep 18 09:49:48 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 18 Sep 2011 16:49:48 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
Message-ID: <m2sjntaos3.wl%randy@psg.com>

>>>> one to post overly aggressive defensive messages on nanog
>>> I am not convinced that Mr. Bush is best placed to comment on this
>>> particular issue.
>> you seem to have a problem differentiating defense from offense.  i
>> recommend you not play chess.  :)
> Randy is perfectly right in expressing his concerns about the registry
> system that we've built (as long as its on a mailing list which
> supports the topic), since we're doing a function on behalf of the
> entire Internet community and spending everyone's money in the
> process.  While it may not matter to him a bit, I'll defend his (and
> anyone's else right) to critique the quality and cost effectiveness of
> the job we're doing.

thanks.  :)

i suspect some folk may be missing a few clues here.  first is that you
and i have been friends since the late '80s.  second is that i was a
founding board member of arin.  and third, there is the concept of the
loyal opposition.

i just think that we, as a culture, have let things get waaaay out of
whack.  john is paid to defend the status grow.

randy


From david at davidswafford.com  Sun Sep 18 11:04:38 2011
From: david at davidswafford.com (David Swafford)
Date: Sun, 18 Sep 2011 12:04:38 -0400
Subject: ouch..
In-Reply-To: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
Message-ID: <CAA8=vb4PJxjjcK_kpwKgXdoYX3CLJ_oeyrTnsm90a37yY5V+Ow@mail.gmail.com>

I find it very amusing when viewing the statement regarding the Nexus
product line, "announced 2008, delivered a few months later...",
considering that it has significant QA issues that have made us regret
our purchases of all Nexus gear.   We are primarily a Cat6509 shop and
standard features, ones that have been around for decades, simply were
left out of Nexus just so they could rush to market  (VTP comes to
mind on the 5K line).

David.


On Wed, Sep 14, 2011 at 6:42 AM, Martin Hepworth <maxsec at gmail.com> wrote:
> http://www.overpromisesunderdelivers.net/
>
>
> --
> Martin Hepworth
> Oxford, UK
>


From amaged at gmail.com  Sun Sep 18 12:04:36 2011
From: amaged at gmail.com (Ahmed Maged)
Date: Sun, 18 Sep 2011 19:04:36 +0200
Subject: ouch..
In-Reply-To: <CAA8=vb4PJxjjcK_kpwKgXdoYX3CLJ_oeyrTnsm90a37yY5V+Ow@mail.gmail.com>
References: <CAGDKorJEvBHG21zOtmoS634pCKgGb2o96ahCuePKqmunSX402Q@mail.gmail.com>
 <CAA8=vb4PJxjjcK_kpwKgXdoYX3CLJ_oeyrTnsm90a37yY5V+Ow@mail.gmail.com>
Message-ID: <CA+DBAX78j484TwFnj32Cezuav1ut-bA9_LO1pMJW2HuS4u0=eA@mail.gmail.com>

http://www.youtube.com/watch?v=i1BfhRauFvw&feature=player_embedded

On Sun, Sep 18, 2011 at 6:04 PM, David Swafford <david at davidswafford.com> wrote:
> I find it very amusing when viewing the statement regarding the Nexus
> product line, "announced 2008, delivered a few months later...",
> considering that it has significant QA issues that have made us regret
> our purchases of all Nexus gear. ? We are primarily a Cat6509 shop and
> standard features, ones that have been around for decades, simply were
> left out of Nexus just so they could rush to market ?(VTP comes to
> mind on the 5K line).
>
> David.
>
>
> On Wed, Sep 14, 2011 at 6:42 AM, Martin Hepworth <maxsec at gmail.com> wrote:
>> http://www.overpromisesunderdelivers.net/
>>
>>
>> --
>> Martin Hepworth
>> Oxford, UK
>>
>
>


From bensons at queuefull.net  Sun Sep 18 13:53:57 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Sun, 18 Sep 2011 14:53:57 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2sjntaos3.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net> <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com> <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net> <m2sjntaos3.wl%randy@psg.com>
Message-ID: <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>


On Sep 18, 2011, at 10:49 AM, Randy Bush wrote:
> i just think that we, as a culture, have let things get waaaay out of
> whack.  john is paid to defend the status grow.


I like that: "status grow".  It seems pretty clear to me that, as humans, we're not very good at organizational contraction.  We're much better at expanding scope, even until it produces undesirable consequences.  Competition is a friend in such scenarios, when it's allowed...  As are revolutions, when competition is not allowed.

In John's case (on behalf of ARIN as is befitting his role) he welcomes change as long as it's funneled through the ARIN-managed channels.  In other words, change is welcome as long as it reinforces ARIN's role as facilitator.  Unfortunately, the gauntlet of "policy weenies" that influence ARIN don't necessarily represent the "community" as they might claim - they represent themselves, their ideologies, etc.  So if you want the ARIN system to change, it's your choice whether to engage within that system or outside it.  Neither seems very useful to me; we can just ignore ARIN as alternatives emerge, and ARIN can catch up or not.

Which, astoundingly, leads to an operational comment / question:  As IPv4 trading is already taking place, what are you (as operators) planning to do when asked to route prefixes that have been bought/sold?  Will you accept alternative (whois) registry sources?  Will you accept legal documentation proving ownership and/or right-to-use, as an alternative to registry validation?

Cheers,
-Benson



From randy at psg.com  Sun Sep 18 14:09:00 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 18 Sep 2011 21:09:00 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
Message-ID: <m2ipopacs3.wl%randy@psg.com>

> IPv4 trading is already taking place, what are you (as operators)
> planning to do when asked to route prefixes that have been
> bought/sold?  Will you accept alternative (whois) registry sources?

why the heck should i have to?  the iana and the frelling rirs' one
principal task is to register.  if they do not register transfers then
what are we all smoking?  and, as far as i know, they are registering
transfers from sale of ip assets.

randy


From bensons at queuefull.net  Sun Sep 18 14:36:58 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Sun, 18 Sep 2011 15:36:58 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2ipopacs3.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net> <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com> <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net> <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <m2ipopacs3.wl%randy@psg.com>
Message-ID: <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>


On Sep 18, 2011, at 3:09 PM, Randy Bush wrote:

>> IPv4 trading is already taking place, what are you (as operators)
>> planning to do when asked to route prefixes that have been
>> bought/sold?  Will you accept alternative (whois) registry sources?
> 
> why the heck should i have to?  the iana and the frelling rirs' one
> principal task is to register.  if they do not register transfers then
> what are we all smoking?

I don't disagree...

>  and, as far as i know, they are registering
> transfers from sale of ip assets.


Apparently true for some.  But I'm told of others that have bought legacy IPv4 prefixes with no intention of updating whois at this time - no desire to enter into a relationship with ARIN and be subjected to existing "policy", for instance.  I can't speak for their rationale beyond this.  But I do believe that several of them will try to get their prefix routed, at some point.

Cheers,
-Benson




From randy at psg.com  Sun Sep 18 14:51:11 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 18 Sep 2011 21:51:11 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <m2ipopacs3.wl%randy@psg.com>
 <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>
Message-ID: <m2fwjtaats.wl%randy@psg.com>

> I'm told of others that have bought legacy IPv4 prefixes with no
> intention of updating whois at this time - no desire to enter into a
> relationship with ARIN and be subjected to existing "policy", for
> instance.

so your point is that your friends at depository.com will be attractive
to ip address space buyers because they will offer a less religious rsa.
and the question is whether the ops community will believe their whois
and install a separate rpki trust root for them?

could be.  but i would not want to have that as my business plan.

randy, who is all for a less religious rsa


From bensons at queuefull.net  Sun Sep 18 15:08:38 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Sun, 18 Sep 2011 16:08:38 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2fwjtaats.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net> <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com> <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net> <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <m2ipopacs3.wl%randy@psg.com>
 <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>
 <m2fwjtaats.wl%randy@psg.com>
Message-ID: <231A19B8-0AF4-41FC-9B2B-A2FE5B6BEBAE@queuefull.net>


On Sep 18, 2011, at 15:51, Randy Bush <randy at psg.com> wrote:

>> I'm told of others that have bought legacy IPv4 prefixes with no
>> intention of updating whois at this time - no desire to enter into a
>> relationship with ARIN and be subjected to existing "policy", for
>> instance.
> 
> so your point is that your friends at depository.com will be attractive
> to ip address space buyers because they will offer a less religious rsa.
> and the question is whether the ops community will believe their whois
> and install a separate rpki trust root for them?

For instance, yes.

I'm also wondering if the ops community will accept other sources of proof such as legal documents (or something else?), in lieu of Whois records from an RIR, Depository, or elsewhere. 

> could be.  but i would not want to have that as my business plan.
> 
> randy, who is all for a less religious rsa

You wouldn't bet on ARIN being religious for the foreseeable future? ;) Or, you wouldn't bet on the ops community embracing alternatives?

Cheers,
-Benson



From cb.list6 at gmail.com  Sun Sep 18 15:17:57 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sun, 18 Sep 2011 13:17:57 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <231A19B8-0AF4-41FC-9B2B-A2FE5B6BEBAE@queuefull.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <m2ipopacs3.wl%randy@psg.com>
 <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>
 <m2fwjtaats.wl%randy@psg.com>
 <231A19B8-0AF4-41FC-9B2B-A2FE5B6BEBAE@queuefull.net>
Message-ID: <CAD6AjGR7pEwpw+qOdMkODXRjhmw=dpg7GYuOsRpo0ttqevGWfg@mail.gmail.com>

On Sep 18, 2011 1:08 PM, "Benson Schliesser" <bensons at queuefull.net> wrote:
>
>
> On Sep 18, 2011, at 15:51, Randy Bush <randy at psg.com> wrote:
>
> >> I'm told of others that have bought legacy IPv4 prefixes with no
> >> intention of updating whois at this time - no desire to enter into a
> >> relationship with ARIN and be subjected to existing "policy", for
> >> instance.
> >
> > so your point is that your friends at depository.com will be attractive
> > to ip address space buyers because they will offer a less religious rsa.
> > and the question is whether the ops community will believe their whois
> > and install a separate rpki trust root for them?
>
> For instance, yes.
>
> I'm also wondering if the ops community will accept other sources of proof
such as legal documents (or something else?), in lieu of Whois records from
an RIR, Depository, or elsewhere.
>
> > could be.  but i would not want to have that as my business plan.
> >
> > randy, who is all for a less religious rsa
>
> You wouldn't bet on ARIN being religious for the foreseeable future? ;)
Or, you wouldn't bet on the ops community embracing alternatives?
>
> Cheers,
> -Benson
>

Call me optimistic but .... ipv6 does not have these issues...

For anyone making STRATEGIC choices about ipv4 investments... beware of
sharks in these waters, not just the cgn pains

Are we having fun yet?

Cb

From sethm at rollernet.us  Sun Sep 18 15:29:58 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Sun, 18 Sep 2011 13:29:58 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <231A19B8-0AF4-41FC-9B2B-A2FE5B6BEBAE@queuefull.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net> <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com> <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net> <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <m2ipopacs3.wl%randy@psg.com>
 <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>
 <m2fwjtaats.wl%randy@psg.com>
 <231A19B8-0AF4-41FC-9B2B-A2FE5B6BEBAE@queuefull.net>
Message-ID: <4E7654C6.9020705@rollernet.us>

On 9/18/11 1:08 PM, Benson Schliesser wrote:
> 
> On Sep 18, 2011, at 15:51, Randy Bush <randy at psg.com> wrote:
> 
>>> I'm told of others that have bought legacy IPv4 prefixes with no
>>> intention of updating whois at this time - no desire to enter into a
>>> relationship with ARIN and be subjected to existing "policy", for
>>> instance.
>>
>> so your point is that your friends at depository.com will be attractive
>> to ip address space buyers because they will offer a less religious rsa.
>> and the question is whether the ops community will believe their whois
>> and install a separate rpki trust root for them?
> 
> For instance, yes.
> 
> I'm also wondering if the ops community will accept other sources of proof such as legal documents (or something else?), in lieu of Whois records from an RIR, Depository, or elsewhere. 
> 

I wouldn't embrace abandoning whois. Its usefulness is far more than
just the prefix "owner" and their ISP. In fact, you may end up with a
registry of these as the new bogon space that everyone should filter. If
I saw abuse or other garbage from some block that did not exist in
whois, I'm not going to care to go search for some BS legal document to
find out who the responsible party is. Or worse, I find it and the
involved parties claim it's privileged information and refuse to
disclose it.

~Seth


From seth.mos at dds.nl  Thu Sep 15 15:28:27 2011
From: seth.mos at dds.nl (Seth Mos)
Date: Thu, 15 Sep 2011 22:28:27 +0200
Subject: routing issue for verizon dsl customers in western massachusetts
Message-ID: <gnrly4plbdialdblv18x5eqb.1316118507524@email.android.com>

Congratulations on your nat444 connection. I suspect a autoblocklist of sorts. They somehow always end up blocking the hosts you are using.

I vaguely remember my watchguard firebox 1000 doing so. It was red too.

Regards and good luck,

Seth

typed on a tiny touchscreen, why exactly?

Steve Bohrer <skbohrer at simons-rock.edu>schreef:

>On Sep 15, 2011, at 3:39 PM, Christopher Morrow wrote:
>
>> On Thu, Sep 15, 2011 at 3:34 PM, Brian Gold <bgold at simons-rock.edu>  
>> wrote:
>>> Over the past week, we've discovered that there is an issue with  
>>> the way
>>> some Verizon DSL customers are being routed in Western  
>>> Massachusetts that is
>>> preventing them from reaching my employers public IPs. The problem  
>>> is only
>>> limited to Verizon DSL customers, everyone else can reach these IP  
>>> addresses
>>> just fine. After many hours on the phone with Verizon tech support, I
>>> finally managed to get myself and one of my coworker's home dsl  
>>> connections
>>> switched from a "redback router" to a "juniper router" which  
>>> resolved the
>>> issue, but only for us.
>
>[...]
>>
>> If you buy verizon services at your day job you can probably make
>> noise through your sales droids better than here (sadly)... verizon
>> likes to jump when customers have problems, if the customer is a large
>> corporation or other 'important' customer.
>
>
>That is just the problem! The college does not buy any Verizon network  
>stuff directly, so we don't really have any access to their support.  
>(We have a few cell phones, but not enough to be "important".)
>
>Brian Gold (who first posted) happens to have their DSL to his house,  
>and he was one of five who have reported the problem, so that gave him  
>a slight in. But the only techs he could reach as an "end user" were  
>not high enough up to fix this problem in a general way. After  
>pressing them for literally hours, he was able to get transfered to  
>their NOC, and get the problem resolved for his one address. But, they  
>would not give him the NOC contact, and he had to repeat this multi- 
>hour process to get it fixed for an other user. Verizon's DSL support  
>suggested that we get our bandwith provider involved, and so they  
>tried to pitch in, but they don't have any Verizon NOC contact either,  
>especially since this issue is purely within a small corner of  
>Verizon's DSL network, not on any of Verizon's links to our provider.
>
>This issue hits only a few Verizon DSL users in NW Mass. It does not  
>really seem like a routing problem, because the affected users can  
>reach many of the servers in our AS, but not some addresses.  
>Unfortunately, the "blocked" addresses include our web server and our  
>mail server, so our staff who live out there noticed the issue pretty  
>quickly. Traceroutes from Brian's house show that for our blocked  
>hosts, the users don't get beyond Verizon's NAT.
>
>The Verizon tech's "fix" of re-patching Brian's DSL line in to a  
>different router feels to me like there is a config problem in the  
>other router, but the tech we got is not authorized to alter the  
>config. It would be nice if we could reach someone who could actually  
>edit the broken config and make it right. Anyone from Verzion's NOC  
>for Western Mass reading this? Or, does anyone else have useful  
>contact info for them?
>
>FWIW, Simon's Rock is 208.81.88.0/21, AS 19345. Here are a failed and  
>a good trace from Brian's house, to different servers on our campus :
>
>FAILS:
>Tracing route to wilbur.simons-rock.edu [208.81.88.15]
>over a maximum of 30 hops:
>
>  1    <1 ms    <1 ms    <1 ms  192.168.10.1
>  2     1 ms     1 ms     1 ms  192.168.1.1
>  3    53 ms   104 ms   116 ms  10.14.1.1
>  4     *        *        *     Request timed out.
>  5     *        *        *     Request timed out.
>  6     *        *        *     Request timed out.
>  7     *        *        *     Request timed out.
>
>WORKS:
>Tracing route to dev.simons-rock.edu [208.81.88.25]
>over a maximum of 30 hops:
>
>1    <1 ms    <1 ms    <1 ms  192.168.10.1
>2     1 ms     1 ms     1 ms  192.168.1.1
>3    87 ms    54 ms    54 ms  10.14.1.1
>4    99 ms   109 ms   103 ms at-0-3-0-1711.WMA-CORE-RTR2.verizon- 
>gni.net [130.81.10.77]
>5    16 ms    18 ms    16 ms  so-7-3-1-0.NY5030-BB-RTR2.verizon- 
>gni.net [130.81.20.6]
>6    19 ms    17 ms    17 ms  0.xe-3-1-0.BR3.NYC4.ALTER.NET  
>[152.63.2.81]
>7    18 ms    21 ms    18 ms  204.255.168.194
>8   108 ms   188 ms   116 ms  pos5-0-2488M.cr1.BOS1.gblx.net  
>[67.17.94.57]
>9    24 ms    28 ms    23 ms  pos0-0-0-155M.ar1.BOS1.gblx.net  
>[67.17.70.162]
>10   121 ms   160 ms   127 ms  64.213.79.250
>11    77 ms    77 ms    78 ms  208.81.88.25
>
>Trace complete.
>
>Anyways, thanks for any suggestions you can offer.
>
>Steve Bohrer
>Network Administrator
>ITS, Bard College at Simon's Rock
>413-528-7645
>
>
>

From frnkblk at iname.com  Sun Sep 18 17:12:05 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Sun, 18 Sep 2011 17:12:05 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <4E758877.5070002@knownelement.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
Message-ID: <005901cc764f$ffe01030$ffa03090$@iname.com>

Where I live in rural America, I would not be surprised that someone who wanted to start an ISP might only be able to cost-justify one upstream.  When one Internet T-1 is $1,200/month, getting a second T-1 for that price from another provider just to get an AS or PI is definitely cost-prohibitive and may go against their business plan.  

Our own company has just one upstream provider (from geographically diverse POPs), our state's telecom coop, and to multi-home solely to meet ARIN's policy doesn't make sense.  Fortunately we were using enough address space to meet the /20 requirement.  

Charles, if you wrote a policy that allowed smaller ISPs to obtain a PI without the multihoming requirement if they demonstrated that multihoming was burdensome, I would support it at arin-ppml.

Frank

-----Original Message-----
From: Charles N Wyble [mailto:charles at knownelement.com] 
Sent: Sunday, September 18, 2011 12:58 AM
To: nanog at nanog.org
Subject: Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

On 09/17/2011 06:52 PM, Randy Carpenter wrote:
>>> I have a small ISP customer who is not multi-homed, and is using
>>> about a /21 and a half of space, and is expanding. Their upstream
>>> is refusing to give them more space, so they wanted to get their
>>> own, and give back the space to the upstream, with the possible
>>> exception of a small block for their servers, which would be very
>>> difficult to renumber. We explained this all, and the response we
>>> got from ARIN was that we needed to have a full /20 from the
>>> upstream, at which time we could easily get a /20 of new space. In
>>> order to qualify for the immediate need, we would need to show
>>> need for the entire /20, of which we would need to fully utilize
>>> (renumber into) within 30 days. That is not even remotely
>>> possible.
>>>
>> Or, they could easily multihome and qualify at a much smaller
>> threshold.
> Unfortunately, this is prohibitively expensive. They are small rural telcos who are connected to a collective state-wide fiber network. Any second provider would could an order of magnitude (or more) more than what they have, and would likely be delivered over the same fiber network anyway.

Um.... really? You can't find anyone out there who would give you an
LOA? No friendly ISP? I'm getting LOA from a buddy of mine that
administers a couple existing ISP networks. It's not that difficult in
my opinion. I mean does it have to be a wireline upstream provider? Or
can it just be any AS who is friendly? I guess it's different for me as
this is a green field deployment and I expect to peer all over the
United States at dozens of POPS. As opposed to being a more traditional
access network provider in a particular geographic region.



>  
>>> The problem with this whole thing is that I have no less than 4
>>> ISPs that are in almost the same boat.
>> Then propose a policy change to rectify it.
> Noted, and planned :-)

I look forward to those discussions. I'm kind of intrigued by policy
now, after starting this process. At first I was a bit irritated but now
after John/Owen posted links and comments, it's a walk in the park. Just
waiting on an LOA from my buddy and I should be able to get that ASN and
associated /32.


-- 
Charles N Wyble charles at knownelement.com @charlesnw on twitter

http://blog.knownelement.com

Building alternative,global scale,secure, cost effective bit moving platform
for tomorrows alternate default free zone.





From leigh.porter at ukbroadband.com  Sun Sep 18 18:37:16 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Sun, 18 Sep 2011 23:37:16 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <005901cc764f$ffe01030$ffa03090$@iname.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Frank Bulk [mailto:frnkblk at iname.com]
> Sent: 18 September 2011 23:14
> To: 'Charles N Wyble'; nanog at nanog.org
> Subject: RE: wet-behind-the-ears whippersnapper seeking advice on
> building a nationwide network
> 
> Where I live in rural America, I would not be surprised that someone
> who wanted to start an ISP might only be able to cost-justify one
> upstream.  When one Internet T-1 is $1,200/month, getting a second T-1
> for that price from another provider just to get an AS or PI is
> definitely cost-prohibitive and may go against their business plan.
> 
> Our own company has just one upstream provider (from geographically
> diverse POPs), our state's telecom coop, and to multi-home solely to
> meet ARIN's policy doesn't make sense.  Fortunately we were using
> enough address space to meet the /20 requirement.
> 
> Charles, if you wrote a policy that allowed smaller ISPs to obtain a PI
> without the multihoming requirement if they demonstrated that
> multihoming was burdensome, I would support it at arin-ppml.
> 
> Frank

I'll happily 'multihome' anybody over a GRE tunnel if it helps ;-)

--
Leigh



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

From jcurran at arin.net  Sun Sep 18 20:20:37 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 19 Sep 2011 01:20:37 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com> <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
Message-ID: <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>

On Sep 18, 2011, at 2:53 PM, Benson Schliesser wrote:
> 
> In John's case (on behalf of ARIN as is befitting his role) he welcomes change as long as it's funneled through the ARIN-managed channels.  In other words, change is welcome as long as it reinforces ARIN's role as facilitator.  

Benson - 

By "ARIN-managed channels", do you mean via mechanisms that were 
established by those elected by the ARIN membership"?

I do indeed believe that efforts to change ARIN should be directed 
to through the channels that are overseen by member-elected ARIN 
Advisory Council and member-elected ARIN Board of Trustees. 

E.g., if you want to change ARIN policies, then there is the ARIN 
PDP (Policy Development Process) which is open to anyone and driven 
by the ARIN Advisory Council.  The process is well documented and 
allows input from the entire community including public polls of 
support for policy changes by both onsite remote participants of 
the Public Policy Meeting (PPM). Similarly, if you want to change 
the scope of ARIN's mission or fees or our operational tasking,
you can talk to the members of the Board of Trustees who are 
unpaid volunteers elected by the ARIN membership.

Engaging from "within the system" definitely means working via channels 
that operate or are defined by member-elected bodies of the system. I
don't think you could have any meaningful self-governance in any model
without this occurring (but would welcome examples of good models of 
governance if you have any counter-examples)  

However, your statement that I only welcome change funneled through 
"ARIN-managed channels" is incorrect, as I have made it quite plain 
on multiple occasions that the structure of the Internet number 
registry system itself is not necessarily a discussion that should
be held within the existing structure (e.g. RIRs and ICANN), but might 
also be appropriately held external to the existing structure (such as 
by operator forums or the Internet Governance Forum).  I believe that 
the community is must always be able to engage in multi-stakeholder 
self-governance discussions, and that does not imply ARIN having any 
unique role in facilitation.

Such a perspective (of welcoming discussion in any forum) is perfectly 
befitting my role at ARIN and not in conflict as you seem to imply, as 
my job is to make sure that the mission of community-led Internet number 
resource management is fulfilled, not the promotion any specific 
organizational model for accomplishing the task.

FYI,
/John

John Curran
President and CEO
ARIN




From frnkblk at iname.com  Sun Sep 18 20:25:01 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Sun, 18 Sep 2011 20:25:01 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
Message-ID: <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>

I understand that tunneling meets the letter of the ARIN policy, but I'll make the bold assumption that wasn't the spirit of the policy when it was written.  Maybe the policy needs to be amended to clarify that.

Frank

-----Original Message-----
From: Leigh Porter [mailto:leigh.porter at ukbroadband.com] 
Sent: Sunday, September 18, 2011 6:37 PM
To: frnkblk at iname.com; 'Charles N Wyble'; nanog at nanog.org
Subject: RE: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

> -----Original Message-----
> From: Frank Bulk [mailto:frnkblk at iname.com]
> Sent: 18 September 2011 23:14
> To: 'Charles N Wyble'; nanog at nanog.org
> Subject: RE: wet-behind-the-ears whippersnapper seeking advice on
> building a nationwide network
> 
> Where I live in rural America, I would not be surprised that someone
> who wanted to start an ISP might only be able to cost-justify one
> upstream.  When one Internet T-1 is $1,200/month, getting a second T-1
> for that price from another provider just to get an AS or PI is
> definitely cost-prohibitive and may go against their business plan.
> 
> Our own company has just one upstream provider (from geographically
> diverse POPs), our state's telecom coop, and to multi-home solely to
> meet ARIN's policy doesn't make sense.  Fortunately we were using
> enough address space to meet the /20 requirement.
> 
> Charles, if you wrote a policy that allowed smaller ISPs to obtain a PI
> without the multihoming requirement if they demonstrated that
> multihoming was burdensome, I would support it at arin-ppml.
> 
> Frank

I'll happily 'multihome' anybody over a GRE tunnel if it helps ;-)

--
Leigh



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From jcurran at arin.net  Sun Sep 18 20:45:15 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 19 Sep 2011 01:45:15 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com> <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <m2ipopacs3.wl%randy@psg.com>
 <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>
Message-ID: <F0798D42-A253-4316-BEAB-54CCFF85BB89@arin.net>

On Sep 18, 2011, at 3:36 PM, Benson Schliesser wrote:
> On Sep 18, 2011, at 3:09 PM, Randy Bush wrote:
>> why the heck should i have to?  the iana and the frelling rirs' one
>> principal task is to register.  if they do not register transfers then
>> what are we all smoking?
> 
> I don't disagree...
> 
>> and, as far as i know, they are registering
>> transfers from sale of ip assets.

ARIN maintains the registry according to the policies in the
region. These are policies are developed by the community at 
large, recommended for adoption by the ARIN AC, and ratified 
by the ARIN Board.

All transfer requests which meet the policies get approved and
updated in the registry.  ARIN does turn down transfer requests 
which don't meet policy, and this potential is often understood 
and covered in proposed sale documents for IP address blocks.

FYI,
/John

John Curran
President and CEO
ARIN



From charles at knownelement.com  Sun Sep 18 20:51:15 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Sun, 18 Sep 2011 20:51:15 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
Message-ID: <4E76A013.1050203@knownelement.com>

On 09/18/2011 08:25 PM, Frank Bulk wrote:
> I understand that tunneling meets the letter of the ARIN policy, but I'll make the bold assumption that wasn't the spirit of the policy when it was written.  Maybe the policy needs to be amended to clarify that.

Well that would be a shame in my opinion. When one is boot strapping a
network, it's very useful to have an ASN/PI space. Especially for v6. If
one starts with a "real" upstream and a multihomed via tunnel, is that
really so bad?

I don't think it is.

I am now very fascinated with the policy around all this. I didn't think
my thread would touch off this passionate discussion. I've only gotten a
few really useful response (from John/Owen/Roland) which come to think
of it, is about what I would expect. I was hoping for more technical
responses. Go gripe on the ARIN lists if you really truly want policy
changes.

I greatly appreciate the clarification of policy and relevant docs etc.
Seems really straightforward to me now.

Now let's get back to technical / nuts and bolts discussion of building
an ISP shall we?

-- 
Charles N Wyble charles at knownelement.com @charlesnw on twitter

http://blog.knownelement.com

Building alternative,global scale,secure, cost effective bit moving platform
for tomorrows alternate default free zone.



From tony at lavanauts.org  Sun Sep 18 21:27:14 2011
From: tony at lavanauts.org (Antonio Querubin)
Date: Sun, 18 Sep 2011 16:27:14 -1000 (HST)
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
Message-ID: <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>

On Sun, 18 Sep 2011, Frank Bulk wrote:

> I understand that tunneling meets the letter of the ARIN policy, but 
> I'll make the bold assumption that wasn't the spirit of the policy when 
> it was written.  Maybe the policy needs to be amended to clarify that.

I think this is a bad idea and I suspect would slow IPv6 deployment. 
Potential latency issues aside, is there a technical (not political) 
reason for doing so?

Antonio Querubin
e-mail:  tony at lavanauts.org
xmpp:  antonioquerubin at gmail.com


From frnkblk at iname.com  Sun Sep 18 21:41:42 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Sun, 18 Sep 2011 21:41:42 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
Message-ID: <005c01cc7675$a9f94a80$fdebdf80$@iname.com>

I should have made myself more clear -- the policy amendment would make
clear that multihoming requires only one facilities-based connection and
that the other connections could be fulfilled via tunnels.  This may be
heresy for some.

Frank

-----Original Message-----
From: Antonio Querubin [mailto:tony at lavanauts.org] 
Sent: Sunday, September 18, 2011 9:27 PM
To: Frank Bulk
Cc: 'Leigh Porter'; 'Charles N Wyble'; nanog at nanog.org
Subject: RE: wet-behind-the-ears whippersnapper seeking advice on building a
nationwide network

On Sun, 18 Sep 2011, Frank Bulk wrote:

> I understand that tunneling meets the letter of the ARIN policy, but 
> I'll make the bold assumption that wasn't the spirit of the policy when 
> it was written.  Maybe the policy needs to be amended to clarify that.

I think this is a bad idea and I suspect would slow IPv6 deployment. 
Potential latency issues aside, is there a technical (not political) 
reason for doing so?

Antonio Querubin
e-mail:  tony at lavanauts.org
xmpp:  antonioquerubin at gmail.com



From mysidia at gmail.com  Sun Sep 18 21:54:10 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 18 Sep 2011 21:54:10 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
Message-ID: <CAAAwwbWRyJDSsDTTKZRYCmLZWnTVOp0kzhLxBsw=sdfmD3gDOg@mail.gmail.com>

On Sun, Sep 18, 2011 at 8:25 PM, Frank Bulk <frnkblk at iname.com> wrote:
> I understand that tunneling meets the letter of the ARIN policy, but I'll make the bold assumption that wasn't the spirit of the policy when it was written. ?Maybe the policy needs to be amended to clarify that.
>

ARIN is not in a position to judge the technical merits of a certain
network design.
Tunneling may be ill-advised, but that's the network operator's choice.

The choice of using tunnelling does not mean that they no longer will
need IP addressing,
or that  they are not multihomed anymore.

> Frank
--
-JH


From bensons at queuefull.net  Sun Sep 18 23:57:47 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Mon, 19 Sep 2011 00:57:47 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net> <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com> <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net> <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>
Message-ID: <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net>



On Sep 18, 2011, at 21:20, John Curran <jcurran at arin.net> wrote:

> On Sep 18, 2011, at 2:53 PM, Benson Schliesser wrote:
>> 
>> In John's case (on behalf of ARIN as is befitting his role) he welcomes change as long as it's funneled through the ARIN-managed channels.  In other words, change is welcome as long as it reinforces ARIN's role as facilitator.  
> 
> ... <a bunch of stuff that encourages people to use ARIN-managed channels> ...

For what it's worth, I agree that ARIN has a pretty good governance structure. (With the exception of NomCom this year, which is shamefully unbalanced.) That hasn't stopped it from becoming an ideological anachronism. Or from becoming interested in self-preservation. It's only natural for such organizations. 

And despite this, I do encourage folks here to participate in PPML. It's the only way ARIN will get more perspective. (Though, admittedly it is a bit like banging ones own head against the wall...)

> However, your statement that I only welcome change funneled through 
> "ARIN-managed channels" is incorrect, as I have made it quite plain 
> on multiple occasions that the structure of the Internet number 
> registry system itself is not necessarily a discussion that should
> be held within the existing structure (e.g. RIRs and ICANN), but might 
> also be appropriately held external to the existing structure (such as 
> by operator forums or the Internet Governance Forum).

Are you suggesting that ARIN policy or procedure might change as a direct result of discussion in e.g. IGF? Or perhaps here on NANOG?

Cheers,
-Benson



From mmzinyi at yahoo.com  Mon Sep 19 00:49:16 2011
From: mmzinyi at yahoo.com (jacob miller)
Date: Sun, 18 Sep 2011 22:49:16 -0700 (PDT)
Subject: SDH Fiber Problem
Message-ID: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>

Hi ,

Dont know if this is the correct forum to ask this however I have been having the following problem on SDH network.

I have been trying to create EoS however am getting the following:

I can ping on point to point
I have BGP up and running

When I try to pass traffic over the link my clients are unable to pass any meanigful traffic asn browsing is impossible.

Any assistance? and direction in terms of any Fiber/SDH forums will be greatly appreciated.


Regards,
Jacob Miller


From tomas.paseka at pacnet.com  Mon Sep 19 01:15:49 2011
From: tomas.paseka at pacnet.com (Paseka, Tomas)
Date: Mon, 19 Sep 2011 14:15:49 +0800
Subject: SDH Fiber Problem
In-Reply-To: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
Message-ID: <8F2D7FAEB5A33144B510ABE6219FB2DF0FA38F82@W3HKEXCHVS1.asianetcom.com>

Checked your MTU settings?

-----Original Message-----
From: jacob miller [mailto:mmzinyi at yahoo.com] 
Sent: Monday, 19 September 2011 1:49 PM
To: nanog at nanog.org
Subject: SDH Fiber Problem

Hi ,

Dont know if this is the correct forum to ask this however I have been having the following problem on SDH network.

I have been trying to create EoS however am getting the following:

I can ping on point to point
I have BGP up and running

When I try to pass traffic over the link my clients are unable to pass any meanigful traffic asn browsing is impossible.

Any assistance? and direction in terms of any Fiber/SDH forums will be greatly appreciated.


Regards,
Jacob Miller



From owen at delong.com  Mon Sep 19 01:48:23 2011
From: owen at delong.com (Owen DeLong)
Date: Sun, 18 Sep 2011 23:48:23 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
Message-ID: <DEC08F19-D58E-4C66-8E46-A36591EEC31D@delong.com>

I disagree. I think that the underlying physical topology of your network is something
ARIN is quite intentionally agnostic about.

Owen

On Sep 18, 2011, at 6:25 PM, Frank Bulk wrote:

> I understand that tunneling meets the letter of the ARIN policy, but I'll make the bold assumption that wasn't the spirit of the policy when it was written.  Maybe the policy needs to be amended to clarify that.
> 
> Frank
> 
> -----Original Message-----
> From: Leigh Porter [mailto:leigh.porter at ukbroadband.com] 
> Sent: Sunday, September 18, 2011 6:37 PM
> To: frnkblk at iname.com; 'Charles N Wyble'; nanog at nanog.org
> Subject: RE: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network
> 
>> -----Original Message-----
>> From: Frank Bulk [mailto:frnkblk at iname.com]
>> Sent: 18 September 2011 23:14
>> To: 'Charles N Wyble'; nanog at nanog.org
>> Subject: RE: wet-behind-the-ears whippersnapper seeking advice on
>> building a nationwide network
>> 
>> Where I live in rural America, I would not be surprised that someone
>> who wanted to start an ISP might only be able to cost-justify one
>> upstream.  When one Internet T-1 is $1,200/month, getting a second T-1
>> for that price from another provider just to get an AS or PI is
>> definitely cost-prohibitive and may go against their business plan.
>> 
>> Our own company has just one upstream provider (from geographically
>> diverse POPs), our state's telecom coop, and to multi-home solely to
>> meet ARIN's policy doesn't make sense.  Fortunately we were using
>> enough address space to meet the /20 requirement.
>> 
>> Charles, if you wrote a policy that allowed smaller ISPs to obtain a PI
>> without the multihoming requirement if they demonstrated that
>> multihoming was burdensome, I would support it at arin-ppml.
>> 
>> Frank
> 
> I'll happily 'multihome' anybody over a GRE tunnel if it helps ;-)
> 
> --
> Leigh
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 



From randy at psg.com  Mon Sep 19 01:55:17 2011
From: randy at psg.com (Randy Bush)
Date: Mon, 19 Sep 2011 08:55:17 +0200
Subject: SDH Fiber Problem
In-Reply-To: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
Message-ID: <m2aaa19g2y.wl%randy@psg.com>

> I can ping on point to point
> I have BGP up and running
> When I try to pass traffic over the link my clients are unable to pass
> any meanigful traffic asn browsing is impossible.

mtu?  try various size pings.

filters?

randy


From jcurran at arin.net  Mon Sep 19 01:59:29 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 19 Sep 2011 06:59:29 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com> <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>
 <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net>
Message-ID: <77D61AE7-613F-4CA2-BA2E-67ACB41E8656@arin.net>

On Sep 19, 2011, at 12:57 AM, Benson Schliesser wrote:

>> However, your statement that I only welcome change funneled through 
>> "ARIN-managed channels" is incorrect, as I have made it quite plain 
>> on multiple occasions that the structure of the Internet number 
>> registry system itself is not necessarily a discussion that should
>> be held within the existing structure (e.g. RIRs and ICANN), but might 
>> also be appropriately held external to the existing structure (such as 
>> by operator forums or the Internet Governance Forum).
> 
> Are you suggesting that ARIN policy or procedure might change as a direct result of discussion in e.g. IGF? Or perhaps here on NANOG?

No.  What I am noting is that there are even venues available for those 
who wish to completely restructure the Internet number registry system 
from the outside, i.e. taking a revolutionary as opposed to evolutionary
approach to change.

FYI,
/John

John Curran
President and CEO
ARIN





From owen at delong.com  Mon Sep 19 02:02:20 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 19 Sep 2011 00:02:20 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <4E76A013.1050203@knownelement.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <4E76A013.1050203@knownelement.com>
Message-ID: <5BEA7B94-DDC4-4CA5-AD8C-E68E24E28FAB@delong.com>


On Sep 18, 2011, at 6:51 PM, Charles N Wyble wrote:

> On 09/18/2011 08:25 PM, Frank Bulk wrote:
>> I understand that tunneling meets the letter of the ARIN policy, but I'll make the bold assumption that wasn't the spirit of the policy when it was written.  Maybe the policy needs to be amended to clarify that.
> 
> Well that would be a shame in my opinion. When one is boot strapping a
> network, it's very useful to have an ASN/PI space. Especially for v6. If
> one starts with a "real" upstream and a multihomed via tunnel, is that
> really so bad?
> 
> I don't think it is.
> 

As someone who has authored the occasional ARIN policy, I will say
that I believe ARIN policy is intentionally agnostic about underlying
physical and logical topology of your network beyond those aspects
defined in the policy.

I do not believe that there was any intention to preclude tunnels
and that if there had been, the policy authors and/or the community
would have been perfectly capable of adding language to express
that intent.

As such, no, I don't believe that the use of tunnels is outside of the
spirit of the policy as it is written.

Owen



From mmzinyi at yahoo.com  Mon Sep 19 02:22:34 2011
From: mmzinyi at yahoo.com (jacob miller)
Date: Mon, 19 Sep 2011 00:22:34 -0700 (PDT)
Subject: SDH Fiber Problem
In-Reply-To: <m2aaa19g2y.wl%randy@psg.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>
Message-ID: <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>

I have tried the pings and am able to ping through with a size of 1600 with the df-bit set

without the df-bit am able to get up to 9000.

The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998.
The switch is a 2960 Cisco switch.

I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic.

Regards,
jacob Miller



----- Original Message -----
From: Randy Bush <randy at psg.com>
To: jacob miller <mmzinyi at yahoo.com>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Sent: Monday, September 19, 2011 9:55 AM
Subject: Re: SDH Fiber Problem

> I can ping on point to point
> I have BGP up and running
> When I try to pass traffic over the link my clients are unable to pass
> any meanigful traffic asn browsing is impossible.

mtu?? try various size pings.

filters?

randy



From randy at psg.com  Mon Sep 19 02:34:35 2011
From: randy at psg.com (Randy Bush)
Date: Mon, 19 Sep 2011 09:34:35 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <F0798D42-A253-4316-BEAB-54CCFF85BB89@arin.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <m2ipopacs3.wl%randy@psg.com>
 <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>
 <F0798D42-A253-4316-BEAB-54CCFF85BB89@arin.net>
Message-ID: <m262kp9e9g.wl%randy@psg.com>

> All transfer requests which meet the policies get approved and
> updated in the registry.  ARIN does turn down transfer requests 
> which don't meet policy, and this potential is often understood 
> and covered in proposed sale documents for IP address blocks.

would you be willing to describe what kind and how many requests
have been denied and for what reasons?  what fraction of reality
does arin whois represent?  how big of a market opportunity is
arin giving depository and its ilk?

randy


From aj at sneep.net  Mon Sep 19 02:38:28 2011
From: aj at sneep.net (Alastair Johnson)
Date: Mon, 19 Sep 2011 00:38:28 -0700
Subject: SDH Fiber Problem
In-Reply-To: <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
Message-ID: <4E76F174.5030306@sneep.net>

On 9/19/2011 12:22 AM, jacob miller wrote:
> I have tried the pings and am able to ping through with a size of 1600 with the df-bit set
>
> without the df-bit am able to get up to 9000.
>
> The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998.
> The switch is a 2960 Cisco switch.
>
> I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic.

How much traffic are you trying to pass over the link?
How big is the underlying VCAT? Is it possible that this is 
misconfigured does not have enough bandwidth?
Depending on the underlying EoSONET/EoSDH bandwidth, you might need to 
pace traffic into the ADM to avoid overrunning buffers.

aj


From mmzinyi at yahoo.com  Mon Sep 19 02:58:39 2011
From: mmzinyi at yahoo.com (jacob miller)
Date: Mon, 19 Sep 2011 00:58:39 -0700 (PDT)
Subject: SDH Fiber Problem
In-Reply-To: <4E76F174.5030306@sneep.net>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
 <4E76F174.5030306@sneep.net>
Message-ID: <1316419119.47941.YahooMailNeo@web39508.mail.mud.yahoo.com>

The entire link is an STM4 that has been channelised.
We are using 3xSTM1 for the EoS service.
The VCG group is configured with 3xSTM1.



Regards,
Jacob Miller



----- Original Message -----
From: Alastair Johnson <aj at sneep.net>
To: jacob miller <mmzinyi at yahoo.com>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Sent: Monday, September 19, 2011 10:38 AM
Subject: Re: SDH Fiber Problem

On 9/19/2011 12:22 AM, jacob miller wrote:
> I have tried the pings and am able to ping through with a size of 1600 with the df-bit set
>
> without the df-bit am able to get up to 9000.
>
> The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998.
> The switch is a 2960 Cisco switch.
>
> I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic.

How much traffic are you trying to pass over the link?
How big is the underlying VCAT? Is it possible that this is 
misconfigured does not have enough bandwidth?
Depending on the underlying EoSONET/EoSDH bandwidth, you might need to 
pace traffic into the ADM to avoid overrunning buffers.

aj



From leigh.porter at ukbroadband.com  Mon Sep 19 03:10:13 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 19 Sep 2011 08:10:13 +0000
Subject: SDH Fiber Problem
In-Reply-To: <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>,
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
Message-ID: <ABAE7F69-A596-49F5-93EA-FF528F2EB38A@ukbroadband.com>

What exactly do you mean by meaningful traffic? ICMP from port to port works, can you pass TCP? SSH between routers? Establish a TCP session over it?

Are you using Juniper SRXs ? :-)

-- 
Leigh Porter


On 19 Sep 2011, at 08:24, "jacob miller" <mmzinyi at yahoo.com> wrote:

> I have tried the pings and am able to ping through with a size of 1600 with the df-bit set
> 
> without the df-bit am able to get up to 9000.
> 
> The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998.
> The switch is a 2960 Cisco switch.
> 
> I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic.
> 
> Regards,
> jacob Miller
> 
> 
> 
> ----- Original Message -----
> From: Randy Bush <randy at psg.com>
> To: jacob miller <mmzinyi at yahoo.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Sent: Monday, September 19, 2011 9:55 AM
> Subject: Re: SDH Fiber Problem
> 
>> I can ping on point to point
>> I have BGP up and running
>> When I try to pass traffic over the link my clients are unable to pass
>> any meanigful traffic asn browsing is impossible.
> 
> mtu?  try various size pings.
> 
> filters?
> 
> randy
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From mmzinyi at yahoo.com  Mon Sep 19 03:14:12 2011
From: mmzinyi at yahoo.com (jacob miller)
Date: Mon, 19 Sep 2011 01:14:12 -0700 (PDT)
Subject: SDH Fiber Problem
In-Reply-To: <ABAE7F69-A596-49F5-93EA-FF528F2EB38A@ukbroadband.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>,
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
 <ABAE7F69-A596-49F5-93EA-FF528F2EB38A@ukbroadband.com>
Message-ID: <1316420052.39155.YahooMailNeo@web39501.mail.mud.yahoo.com>

By meanigful traffic I mean traffic like Http traffic

Am able to ssh no problem.

Most of the clients on the link are using it for browsing.
However we find that even though they are able to resolve and ping different sites.
When it comes to opening of the page we have the page reading as opening opening .. but the page never gets opened.

Regards,
Jacob Miller



----- Original Message -----
From: Leigh Porter <leigh.porter at ukbroadband.com>
To: jacob miller <mmzinyi at yahoo.com>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Sent: Monday, September 19, 2011 11:10 AM
Subject: Re: SDH Fiber Problem

What exactly do you mean by meaningful traffic? ICMP from port to port works, can you pass TCP? SSH between routers? Establish a TCP session over it?

Are you using Juniper SRXs ? :-)

-- 
Leigh Porter


On 19 Sep 2011, at 08:24, "jacob miller" <mmzinyi at yahoo.com> wrote:

> I have tried the pings and am able to ping through with a size of 1600 with the df-bit set
> 
> without the df-bit am able to get up to 9000.
> 
> The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998.
> The switch is a 2960 Cisco switch.
> 
> I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic.
> 
> Regards,
> jacob Miller
> 
> 
> 
> ----- Original Message -----
> From: Randy Bush <randy at psg.com>
> To: jacob miller <mmzinyi at yahoo.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Sent: Monday, September 19, 2011 9:55 AM
> Subject: Re: SDH Fiber Problem
> 
>> I can ping on point to point
>> I have BGP up and running
>> When I try to pass traffic over the link my clients are unable to pass
>> any meanigful traffic asn browsing is impossible.
> 
> mtu?? try various size pings.
> 
> filters?
> 
> randy
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From leigh.porter at ukbroadband.com  Mon Sep 19 03:17:28 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 19 Sep 2011 08:17:28 +0000
Subject: SDH Fiber Problem
In-Reply-To: <1316420052.39155.YahooMailNeo@web39501.mail.mud.yahoo.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>,
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
 <ABAE7F69-A596-49F5-93EA-FF528F2EB38A@ukbroadband.com>,
 <1316420052.39155.YahooMailNeo@web39501.mail.mud.yahoo.com>
Message-ID: <82933B17-9992-47FB-8472-3F5112F118E2@ukbroadband.com>

It does sound like an MTU issue. Symptoms are typical. Did you try pings end to end with DF bit set and full size datagrams?



-- 
Leigh Porter


On 19 Sep 2011, at 09:15, "jacob miller" <mmzinyi at yahoo.com> wrote:

> By meanigful traffic I mean traffic like Http traffic
> 
> Am able to ssh no problem.
> 
> Most of the clients on the link are using it for browsing.
> However we find that even though they are able to resolve and ping different sites.
> When it comes to opening of the page we have the page reading as opening opening .. but the page never gets opened.
> 
> Regards,
> Jacob Miller
> 
> 
> 
> ----- Original Message -----
> From: Leigh Porter <leigh.porter at ukbroadband.com>
> To: jacob miller <mmzinyi at yahoo.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Sent: Monday, September 19, 2011 11:10 AM
> Subject: Re: SDH Fiber Problem
> 
> What exactly do you mean by meaningful traffic? ICMP from port to port works, can you pass TCP? SSH between routers? Establish a TCP session over it?
> 
> Are you using Juniper SRXs ? :-)
> 
> -- 
> Leigh Porter
> 
> 
> On 19 Sep 2011, at 08:24, "jacob miller" <mmzinyi at yahoo.com> wrote:
> 
>> I have tried the pings and am able to ping through with a size of 1600 with the df-bit set
>> 
>> without the df-bit am able to get up to 9000.
>> 
>> The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998.
>> The switch is a 2960 Cisco switch.
>> 
>> I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic.
>> 
>> Regards,
>> jacob Miller
>> 
>> 
>> 
>> ----- Original Message -----
>> From: Randy Bush <randy at psg.com>
>> To: jacob miller <mmzinyi at yahoo.com>
>> Cc: "nanog at nanog.org" <nanog at nanog.org>
>> Sent: Monday, September 19, 2011 9:55 AM
>> Subject: Re: SDH Fiber Problem
>> 
>>> I can ping on point to point
>>> I have BGP up and running
>>> When I try to pass traffic over the link my clients are unable to pass
>>> any meanigful traffic asn browsing is impossible.
>> 
>> mtu?  try various size pings.
>> 
>> filters?
>> 
>> randy
>> 
>> 
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From mmzinyi at yahoo.com  Mon Sep 19 04:20:06 2011
From: mmzinyi at yahoo.com (jacob miller)
Date: Mon, 19 Sep 2011 02:20:06 -0700 (PDT)
Subject: SDH Fiber Problem
In-Reply-To: <82933B17-9992-47FB-8472-3F5112F118E2@ukbroadband.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>,
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
 <ABAE7F69-A596-49F5-93EA-FF528F2EB38A@ukbroadband.com>,
 <1316420052.39155.YahooMailNeo@web39501.mail.mud.yahoo.com>
 <82933B17-9992-47FB-8472-3F5112F118E2@ukbroadband.com>
Message-ID: <1316424006.67260.YahooMailNeo@web39501.mail.mud.yahoo.com>

I have triend to do a ping with the DF bit set.
Maximum am able to get to is 1600.
This am guessing is because of the fact I have set the mtu size on My interface to 1600.

I have also enable all alarms on the node and am getting the following alarm which is registering as beign Minor.

"High Order Path Signal Label Mismatch"

Regards,
jacob Miller



----- Original Message -----
From: Leigh Porter <leigh.porter at ukbroadband.com>
To: jacob miller <mmzinyi at yahoo.com>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Sent: Monday, September 19, 2011 11:17 AM
Subject: Re: SDH Fiber Problem

It does sound like an MTU issue. Symptoms are typical. Did you try pings end to end with DF bit set and full size datagrams?



-- 
Leigh Porter


On 19 Sep 2011, at 09:15, "jacob miller" <mmzinyi at yahoo.com> wrote:

> By meanigful traffic I mean traffic like Http traffic
> 
> Am able to ssh no problem.
> 
> Most of the clients on the link are using it for browsing.
> However we find that even though they are able to resolve and ping different sites.
> When it comes to opening of the page we have the page reading as opening opening .. but the page never gets opened.
> 
> Regards,
> Jacob Miller
> 
> 
> 
> ----- Original Message -----
> From: Leigh Porter <leigh.porter at ukbroadband.com>
> To: jacob miller <mmzinyi at yahoo.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Sent: Monday, September 19, 2011 11:10 AM
> Subject: Re: SDH Fiber Problem
> 
> What exactly do you mean by meaningful traffic? ICMP from port to port works, can you pass TCP? SSH between routers? Establish a TCP session over it?
> 
> Are you using Juniper SRXs ? :-)
> 
> -- 
> Leigh Porter
> 
> 
> On 19 Sep 2011, at 08:24, "jacob miller" <mmzinyi at yahoo.com> wrote:
> 
>> I have tried the pings and am able to ping through with a size of 1600 with the df-bit set
>> 
>> without the df-bit am able to get up to 9000.
>> 
>> The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998.
>> The switch is a 2960 Cisco switch.
>> 
>> I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic.
>> 
>> Regards,
>> jacob Miller
>> 
>> 
>> 
>> ----- Original Message -----
>> From: Randy Bush <randy at psg.com>
>> To: jacob miller <mmzinyi at yahoo.com>
>> Cc: "nanog at nanog.org" <nanog at nanog.org>
>> Sent: Monday, September 19, 2011 9:55 AM
>> Subject: Re: SDH Fiber Problem
>> 
>>> I can ping on point to point
>>> I have BGP up and running
>>> When I try to pass traffic over the link my clients are unable to pass
>>> any meanigful traffic asn browsing is impossible.
>> 
>> mtu?? try various size pings.
>> 
>> filters?
>> 
>> randy
>> 
>> 
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From leigh.porter at ukbroadband.com  Mon Sep 19 04:23:02 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 19 Sep 2011 09:23:02 +0000
Subject: SDH Fiber Problem
In-Reply-To: <1316424006.67260.YahooMailNeo@web39501.mail.mud.yahoo.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>,
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
 <ABAE7F69-A596-49F5-93EA-FF528F2EB38A@ukbroadband.com>,
 <1316420052.39155.YahooMailNeo@web39501.mail.mud.yahoo.com>
 <82933B17-9992-47FB-8472-3F5112F118E2@ukbroadband.com>,
 <1316424006.67260.YahooMailNeo@web39501.mail.mud.yahoo.com>
Message-ID: <C4D68053-10AD-4931-A8EA-2411F9F7A201@ukbroadband.com>

Did you try turning it off and on again? ;-)

-- 
Leigh Porter


On 19 Sep 2011, at 10:21, "jacob miller" <mmzinyi at yahoo.com> wrote:

> I have triend to do a ping with the DF bit set.
> Maximum am able to get to is 1600.
> This am guessing is because of the fact I have set the mtu size on My interface to 1600.
> 
> I have also enable all alarms on the node and am getting the following alarm which is registering as beign Minor.
> 
> "High Order Path Signal Label Mismatch"
> 
> Regards,
> jacob Miller
> 
> 
> 
> ----- Original Message -----
> From: Leigh Porter <leigh.porter at ukbroadband.com>
> To: jacob miller <mmzinyi at yahoo.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Sent: Monday, September 19, 2011 11:17 AM
> Subject: Re: SDH Fiber Problem
> 
> It does sound like an MTU issue. Symptoms are typical. Did you try pings end to end with DF bit set and full size datagrams?
> 
> 
> 
> -- 
> Leigh Porter
> 
> 
> On 19 Sep 2011, at 09:15, "jacob miller" <mmzinyi at yahoo.com> wrote:
> 
>> By meanigful traffic I mean traffic like Http traffic
>> 
>> Am able to ssh no problem.
>> 
>> Most of the clients on the link are using it for browsing.
>> However we find that even though they are able to resolve and ping different sites.
>> When it comes to opening of the page we have the page reading as opening opening .. but the page never gets opened.
>> 
>> Regards,
>> Jacob Miller
>> 
>> 
>> 
>> ----- Original Message -----
>> From: Leigh Porter <leigh.porter at ukbroadband.com>
>> To: jacob miller <mmzinyi at yahoo.com>
>> Cc: "nanog at nanog.org" <nanog at nanog.org>
>> Sent: Monday, September 19, 2011 11:10 AM
>> Subject: Re: SDH Fiber Problem
>> 
>> What exactly do you mean by meaningful traffic? ICMP from port to port works, can you pass TCP? SSH between routers? Establish a TCP session over it?
>> 
>> Are you using Juniper SRXs ? :-)
>> 
>> -- 
>> Leigh Porter
>> 
>> 
>> On 19 Sep 2011, at 08:24, "jacob miller" <mmzinyi at yahoo.com> wrote:
>> 
>>> I have tried the pings and am able to ping through with a size of 1600 with the df-bit set
>>> 
>>> without the df-bit am able to get up to 9000.
>>> 
>>> The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998.
>>> The switch is a 2960 Cisco switch.
>>> 
>>> I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic.
>>> 
>>> Regards,
>>> jacob Miller
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>> From: Randy Bush <randy at psg.com>
>>> To: jacob miller <mmzinyi at yahoo.com>
>>> Cc: "nanog at nanog.org" <nanog at nanog.org>
>>> Sent: Monday, September 19, 2011 9:55 AM
>>> Subject: Re: SDH Fiber Problem
>>> 
>>>> I can ping on point to point
>>>> I have BGP up and running
>>>> When I try to pass traffic over the link my clients are unable to pass
>>>> any meanigful traffic asn browsing is impossible.
>>> 
>>> mtu?  try various size pings.
>>> 
>>> filters?
>>> 
>>> randy
>>> 
>>> 
>>> 
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
>> 
>> 
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From mmzinyi at yahoo.com  Mon Sep 19 04:33:33 2011
From: mmzinyi at yahoo.com (jacob miller)
Date: Mon, 19 Sep 2011 02:33:33 -0700 (PDT)
Subject: SDH Fiber Problem
In-Reply-To: <C4D68053-10AD-4931-A8EA-2411F9F7A201@ukbroadband.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>,
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
 <ABAE7F69-A596-49F5-93EA-FF528F2EB38A@ukbroadband.com>,
 <1316420052.39155.YahooMailNeo@web39501.mail.mud.yahoo.com>
 <82933B17-9992-47FB-8472-3F5112F118E2@ukbroadband.com>,
 <1316424006.67260.YahooMailNeo@web39501.mail.mud.yahoo.com>
 <C4D68053-10AD-4931-A8EA-2411F9F7A201@ukbroadband.com>
Message-ID: <1316424813.11391.YahooMailNeo@web39504.mail.mud.yahoo.com>

Did so and am able to ping through

Regards,
Jacob Miller



----- Original Message -----
From: Leigh Porter <leigh.porter at ukbroadband.com>
To: jacob miller <mmzinyi at yahoo.com>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Sent: Monday, September 19, 2011 12:23 PM
Subject: Re: SDH Fiber Problem

Did you try turning it off and on again? ;-)

-- 
Leigh Porter


On 19 Sep 2011, at 10:21, "jacob miller" <mmzinyi at yahoo.com> wrote:

> I have triend to do a ping with the DF bit set.
> Maximum am able to get to is 1600.
> This am guessing is because of the fact I have set the mtu size on My interface to 1600.
> 
> I have also enable all alarms on the node and am getting the following alarm which is registering as beign Minor.
> 
> "High Order Path Signal Label Mismatch"
> 
> Regards,
> jacob Miller
> 
> 
> 
> ----- Original Message -----
> From: Leigh Porter <leigh.porter at ukbroadband.com>
> To: jacob miller <mmzinyi at yahoo.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Sent: Monday, September 19, 2011 11:17 AM
> Subject: Re: SDH Fiber Problem
> 
> It does sound like an MTU issue. Symptoms are typical. Did you try pings end to end with DF bit set and full size datagrams?
> 
> 
> 
> -- 
> Leigh Porter
> 
> 
> On 19 Sep 2011, at 09:15, "jacob miller" <mmzinyi at yahoo.com> wrote:
> 
>> By meanigful traffic I mean traffic like Http traffic
>> 
>> Am able to ssh no problem.
>> 
>> Most of the clients on the link are using it for browsing.
>> However we find that even though they are able to resolve and ping different sites.
>> When it comes to opening of the page we have the page reading as opening opening .. but the page never gets opened.
>> 
>> Regards,
>> Jacob Miller
>> 
>> 
>> 
>> ----- Original Message -----
>> From: Leigh Porter <leigh.porter at ukbroadband.com>
>> To: jacob miller <mmzinyi at yahoo.com>
>> Cc: "nanog at nanog.org" <nanog at nanog.org>
>> Sent: Monday, September 19, 2011 11:10 AM
>> Subject: Re: SDH Fiber Problem
>> 
>> What exactly do you mean by meaningful traffic? ICMP from port to port works, can you pass TCP? SSH between routers? Establish a TCP session over it?
>> 
>> Are you using Juniper SRXs ? :-)
>> 
>> -- 
>> Leigh Porter
>> 
>> 
>> On 19 Sep 2011, at 08:24, "jacob miller" <mmzinyi at yahoo.com> wrote:
>> 
>>> I have tried the pings and am able to ping through with a size of 1600 with the df-bit set
>>> 
>>> without the df-bit am able to get up to 9000.
>>> 
>>> The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998.
>>> The switch is a 2960 Cisco switch.
>>> 
>>> I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic.
>>> 
>>> Regards,
>>> jacob Miller
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>> From: Randy Bush <randy at psg.com>
>>> To: jacob miller <mmzinyi at yahoo.com>
>>> Cc: "nanog at nanog.org" <nanog at nanog.org>
>>> Sent: Monday, September 19, 2011 9:55 AM
>>> Subject: Re: SDH Fiber Problem
>>> 
>>>> I can ping on point to point
>>>> I have BGP up and running
>>>> When I try to pass traffic over the link my clients are unable to pass
>>>> any meanigful traffic asn browsing is impossible.
>>> 
>>> mtu?? try various size pings.
>>> 
>>> filters?
>>> 
>>> randy
>>> 
>>> 
>>> 
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
>> 
>> 
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From eugen at leitl.org  Mon Sep 19 05:46:25 2011
From: eugen at leitl.org (Eugen Leitl)
Date: Mon, 19 Sep 2011 12:46:25 +0200
Subject: Internet mauled by bears
Message-ID: <20110919104625.GB25711@leitl.org>


http://news.techeye.net/internet/internet-attacked-by-bears#.TnZXk5rhOv8.reddit

Internet attacked by bears

Is there a picnic basket in this node?  16 Sep 2011 09:44 | by Nick Farrell
in Rome | Filed in Internet

Internet attacked by bears -

Techies in Idaho have been scratching their heads trying to work out why the
state has the slowest networks in the Land of the Free.

Pando Network released the findings of a nationwide study on internet speeds.
It found Idaho has the slowest networks, while Rhode Island, New Jersey and
Massachusetts are at the top of the pack.

The New York Times took it upon itself to find out why Idaho's internet was
the slowest and came out with the surprising result that it was all due to
bears.

Now many of you would probably think that slow internet times are probably
due to the fact that only 1,567,582 live in Idaho and telephone companies
can't be bothered investing in cable. It is known as the Potato State because
that is its major crop and several of its politicians have been root
vegetables.

But according to the Times, another problem is that the internet depends on
line-of-site towers to get over the more mountainous regions. This is where
the bears come in.

Bears like the internet towers because they are ideal for scratching that
part of their backs that they can't normally itch.

Your average bear will rub against a tower and cause it to lose line of site
connections. Barry Ramsay told the Times that when it happened work crews had
to ride up in snowmobiles to discover the problem.

He pointed out that these are the kind of problems city folk probably don't
have in an urban area because there is a bear shortage. 




From ops.lists at gmail.com  Mon Sep 19 05:50:05 2011
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Mon, 19 Sep 2011 16:20:05 +0530
Subject: Internet mauled by bears
In-Reply-To: <20110919104625.GB25711@leitl.org>
References: <20110919104625.GB25711@leitl.org>
Message-ID: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>

On Mon, Sep 19, 2011 at 4:16 PM, Eugen Leitl <eugen at leitl.org> wrote:
> He pointed out that these are the kind of problems city folk probably don't
> have in an urban area because there is a bear shortage.

And backwoods towns have rednecks with shotguns, and bubba the backhoe
driver exists everywhere there's a road ..

-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From lists at blackhat.bz  Mon Sep 19 06:42:57 2011
From: lists at blackhat.bz (BH)
Date: Mon, 19 Sep 2011 19:42:57 +0800
Subject: SDH Fiber Problem
In-Reply-To: <1316424813.11391.YahooMailNeo@web39504.mail.mud.yahoo.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>,
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
 <ABAE7F69-A596-49F5-93EA-FF528F2EB38A@ukbroadband.com>,
 <1316420052.39155.YahooMailNeo@web39501.mail.mud.yahoo.com>
 <82933B17-9992-47FB-8472-3F5112F118E2@ukbroadband.com>,
 <1316424006.67260.YahooMailNeo@web39501.mail.mud.yahoo.com>
 <C4D68053-10AD-4931-A8EA-2411F9F7A201@ukbroadband.com>
 <1316424813.11391.YahooMailNeo@web39504.mail.mud.yahoo.com>
Message-ID: <4E772AC1.7070608@blackhat.bz>

Have you tried doing a tcpdump to see if that shows anything meaningful?

On 19/09/2011 5:33 PM, jacob miller wrote:
> Did so and am able to ping through
>
> Regards,
> Jacob Miller
>
>
>
> ----- Original Message -----
> From: Leigh Porter<leigh.porter at ukbroadband.com>
> To: jacob miller<mmzinyi at yahoo.com>
> Cc: "nanog at nanog.org"<nanog at nanog.org>
> Sent: Monday, September 19, 2011 12:23 PM
> Subject: Re: SDH Fiber Problem
>
> Did you try turning it off and on again? ;-)
>



From Valdis.Kletnieks at vt.edu  Mon Sep 19 06:59:07 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 19 Sep 2011 07:59:07 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: Your message of "Sun, 18 Sep 2011 13:17:57 PDT."
 <CAD6AjGR7pEwpw+qOdMkODXRjhmw=dpg7GYuOsRpo0ttqevGWfg@mail.gmail.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net> <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com> <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net> <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <m2ipopacs3.wl%randy@psg.com>
 <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>
 <m2fwjtaats.wl%randy@psg.com>
 <231A19B8-0AF4-41FC-9B2B-A2FE5B6BEBAE@queuefull.net>
 <CAD6AjGR7pEwpw+qOdMkODXRjhmw=dpg7GYuOsRpo0ttqevGWfg@mail.gmail.com>
Message-ID: <39115.1316433547@turing-police.cc.vt.edu>

On Sun, 18 Sep 2011 13:17:57 PDT, Cameron Byrne said:

> Call me optimistic but .... ipv6 does not have these issues...
> 
> For anyone making STRATEGIC choices about ipv4 investments... beware of
> sharks in these waters, not just the cgn pains

For many of us (especiially the ones who have ipv6 deployed already), the
problem isn't *our* strategic choices, the problem is the less-than-strategic
choices made by the network owning the other end of the connection.  If we're
ready to talk over IPv6, but the other end instead decides to try to talk to us
over a NAT444 or from a prefix that's got sketchy history, there really isn't
much we can do about it.

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

From jcurran at arin.net  Mon Sep 19 07:14:25 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 19 Sep 2011 12:14:25 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m262kp9e9g.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com> <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <m2ipopacs3.wl%randy@psg.com>
 <6B792534-B1C8-4E93-B509-1B8165DC2851@queuefull.net>
 <F0798D42-A253-4316-BEAB-54CCFF85BB89@arin.net> <m262kp9e9g.wl%randy@psg.com>
Message-ID: <86FB699E-2099-4361-B41E-FD45FAD3140B@arin.net>

On Sep 19, 2011, at 3:34 AM, Randy Bush wrote:

>> All transfer requests which meet the policies get approved and
>> updated in the registry.  ARIN does turn down transfer requests 
>> which don't meet policy, and this potential is often understood 
>> and covered in proposed sale documents for IP address blocks.
> 
> would you be willing to describe what kind and how many requests
> have been denied and for what reasons?  what fraction of reality
> does arin whois represent? 


Randy - We try to collect and publish statistics for the majority
of registry operations, and this includes transfer requests.  The 
number of transfer requests and number approved are in the monthly 
stats: https://www.arin.net/knowledge/statistics/index.html   We
do not have reason codes for denials of registration requests since 
in many cases there are are multiple criteria and a failed request 
is effectively "did not meet any of the available policy criteria.'

Your second question is harder to answer, since it is quite possible
that a transfer request to a party which doesn't qualify results in
a subsequent request to a party that does. We are, of course, quite 
capable of blindly approving all transfer requests, but the community
policy would have to direct us to do so since existing policy directs
us to only approve transfers to parties that have documented need.
One has to presume that this is how the operator community wishes
ARIN to operate or that that they'd establish policies otherwise.

FYI,
/John

John Curran
President and CEO
ARIN




From kwallace at pcconnection.com  Mon Sep 19 09:34:06 2011
From: kwallace at pcconnection.com (Wallace Keith)
Date: Mon, 19 Sep 2011 10:34:06 -0400
Subject: SDH Fiber Problem
In-Reply-To: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
Message-ID: <B92E4A692F0F6B419EE79045D420F72A2F39520E3F@MKA176.pcc.int>


>I have been trying to create EoS however am getting the following:

>I can ping on point to point
>I have BGP up and running

>When I try to pass traffic over the link my clients are unable to pass any meanigful traffic asn browsing is impossible.

>Any assistance? and direction in terms of any Fiber/SDH forums will be greatly appreciated.


Is this SDH router to router, or are you handing it off as Ethernet?  I had a similar problem, and it was simply a mismatched duplex setting.

-Keith


From eesslinger at fpu-tn.com  Mon Sep 19 11:45:08 2011
From: eesslinger at fpu-tn.com (Eric J Esslinger)
Date: Mon, 19 Sep 2011 11:45:08 -0500
Subject: Internet mauled by bears
In-Reply-To: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
Message-ID: <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>




> -----Original Message-----
> From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com]
>
>
> On Mon, Sep 19, 2011 at 4:16 PM, Eugen Leitl <eugen at leitl.org> wrote:
> > He pointed out that these are the kind of problems city
> folk probably
> > don't have in an urban area because there is a bear shortage.
>
> And backwoods towns have rednecks with shotguns, and bubba
> the backhoe driver exists everywhere there's a road ..
To be honest, while we have had some 'shotgun peppered' fiber runs in our rural TN town (mostly in one spot, due to dove hunters), after comparing notes with a lady that works for Mediacom I think it is preferable to having to have security escorts for their crews in some rough urban areas because gangs will shoot up plant then wait for the crews to show up so they can rob them.

Everyone has issues as which are as diverse as the areas we deploy in.
__________________________
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities
http://www.fpu-tn.com/
(931)433-1522 ext 165

This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Eric J Esslinger.vcf
Type: text/x-vcard
Size: 498 bytes
Desc: Eric J Esslinger.vcf
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110919/da9f1867/attachment.vcf>

From michael at rancid.berkeley.edu  Mon Sep 19 11:47:35 2011
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Mon, 19 Sep 2011 09:47:35 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
Message-ID: <4E777227.90107@rancid.berkeley.edu>

On 09/18/11 19:41, Frank Bulk wrote:
> I should have made myself more clear -- the policy amendment would make
> clear that multihoming requires only one facilities-based connection and
> that the other connections could be fulfilled via tunnels.  This may be
> heresy for some.

I don't think the policy should specify the underlying transport at all. 
  That strikes me as out-of-scope for ARIN.

michael



From frnkblk at iname.com  Mon Sep 19 12:08:33 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Mon, 19 Sep 2011 12:08:33 -0500
Subject: IPv6 side of www.charter.com has been down since Friday,
 September 16 5:12 am Central
Message-ID: <001601cc76ee$c30c50c0$4924f240$@iname.com>

The IPv6 side of www.charter.com has been down since Friday, September 16
5:12 am Central.  Emails to their NOC have gone unanswered.  If anyone on
list can nudge their ops group that would be appreciated.

Frank


nagios:/home/fbulk# wget -6 www.charter.com
--2011-09-19 08:23:58--  http://www.charter.com/
Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:24:20--  (try: 2)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:24:43--  (try: 3)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:07--  (try: 4)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:32--  (try: 5)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:58--  (try: 6)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:26:25--  (try: 7)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:26:53--  (try: 8)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:27:22--  (try: 9)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:27:52--  (try:10)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:28:23--  (try:11)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:28:54--  (try:12)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:29:25--  (try:13)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:29:56--  (try:14)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:30:27--  (try:15)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:30:58--  (try:16)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:31:29--  (try:17)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:32:00--  (try:18)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:32:31--  (try:19)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:33:02--  (try:20)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Giving up.

nagios:/home/fbulk#



From paul4004 at gmail.com  Mon Sep 19 12:13:14 2011
From: paul4004 at gmail.com (PC)
Date: Mon, 19 Sep 2011 11:13:14 -0600
Subject: IPv6 side of www.charter.com has been down since Friday,
 September 16 5:12 am Central
In-Reply-To: <001601cc76ee$c30c50c0$4924f240$@iname.com>
References: <001601cc76ee$c30c50c0$4924f240$@iname.com>
Message-ID: <CAJAdsDkUJOapWAyDe_-BHgmT33YJr=xSXUJ_7gHw=aghYwDMwQ@mail.gmail.com>

Works fine here.

# wget -6 www.charter.com
--2011-09-19 10:24:37--  http://www.charter.com/
Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `index.html'

    [
<=>
] 112,940      288K/s   in 0.4s

2011-09-19 10:24:43 (288 KB/s) - `index.html' saved [112940]


traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 80
byte packets
 1  2607:f2f8:xxxx::1 (2607:f2f8:xxxx::1)  18.721 ms  18.699 ms  18.689 ms
 2  2001:504:13::1a (2001:504:13::1a)  1.256 ms  1.672 ms  1.428 ms
 3  10gigabitethernet1-2.core1.den1.he.net (2001:470:0:15d::1)  26.498 ms
26.486 ms  26.466 ms
 4  10gigabitethernet1-1.core1.chi1.he.net (2001:470:0:1af::1)  49.986 ms
49.529 ms  49.521 ms
 5  2001:470:0:114::2 (2001:470:0:114::2)  50.105 ms  49.632 ms  49.626 ms
 6  bbr02chcgil-tge0-1-0-0.il.chcg.charter.com (2001:506:100:313::1)  55.805
ms  54.254 ms bbr02chcgil-tge0-0-0-0.il.chcg.charter.com(2001:506:100:305::1)
 55.880 ms
 7  bbr01olvemo-tge0-4-0-4.mo.olve.charter.com (2001:506:100:55::1)  69.465
ms  63.351 ms  63.314 ms
 8  bdr01tncomo-tge1-1.mo.tnco.charter.com (2001:506:100:23::2)  60.018 ms
59.597 ms  59.586 ms
 9  2001:506:100:6c::2 (2001:506:100:6c::2)  60.251 ms  60.245 ms  60.236 ms
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *


On Mon, Sep 19, 2011 at 11:08 AM, Frank Bulk <frnkblk at iname.com> wrote:

> The IPv6 side of www.charter.com has been down since Friday, September 16
> 5:12 am Central.  Emails to their NOC have gone unanswered.  If anyone on
> list can nudge their ops group that would be appreciated.
>
> Frank
>
>
> nagios:/home/fbulk# wget -6 www.charter.com
> --2011-09-19 08:23:58--  http://www.charter.com/
> Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:24:20--  (try: 2)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:24:43--  (try: 3)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:25:07--  (try: 4)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:25:32--  (try: 5)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:25:58--  (try: 6)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:26:25--  (try: 7)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:26:53--  (try: 8)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:27:22--  (try: 9)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:27:52--  (try:10)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:28:23--  (try:11)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:28:54--  (try:12)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:29:25--  (try:13)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:29:56--  (try:14)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:30:27--  (try:15)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:30:58--  (try:16)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:31:29--  (try:17)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:32:00--  (try:18)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:32:31--  (try:19)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Retrying.
>
> --2011-09-19 08:33:02--  (try:20)  http://www.charter.com/
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> Connection timed out.
> Giving up.
>
> nagios:/home/fbulk#
>
>
>

From frnkblk at iname.com  Mon Sep 19 12:38:12 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Mon, 19 Sep 2011 12:38:12 -0500
Subject: IPv6 side of www.charter.com has been down since Friday,
 September 16 5:12 am Central
In-Reply-To: <CAJAdsDkUJOapWAyDe_-BHgmT33YJr=xSXUJ_7gHw=aghYwDMwQ@mail.gmail.com>
References: <001601cc76ee$c30c50c0$4924f240$@iname.com>
 <CAJAdsDkUJOapWAyDe_-BHgmT33YJr=xSXUJ_7gHw=aghYwDMwQ@mail.gmail.com>
Message-ID: <001e01cc76f2$e7aefd70$b70cf850$@iname.com>

I've been told by someone else offline that it's fine for them, too.  Last
hop according to tcptraceroute6 is Qwest.  Anyone else going to
www.charter.com (IPv6) through Qwest?

 

nagios:/home/fbulk# tcptraceroute6 www.charter.com

traceroute to www.charter.com (2607:f428:3:1:80:80:80:1) from
2607:fe28:0:1000::5, port 80, from port 43838, 30 hops max, 60 bytes packets

1  2607:fe28:0:1003::2 (2607:fe28:0:1003::2)  1.075 ms  1.258 ms  1.857 ms

2  router-core.mtcnet.net (2607:fe28:0:1000::1)  1.625 ms  2.271 ms  1.331
ms

3  sxct.sxcy.mtcnet.net (2607:fe28:11:1002::197)  2.581 ms  1.568 ms  1.215
ms

4  v6-siouxcenter.sxcy.137.netins.net (2001:5f8:7f06::5)  3.347 ms  3.007 ms
2.640 ms

5  v6-ins-db1-te-13-2-219.desm.netins.net (2001:5f8:1:1::1)  7.441 ms  7.121
ms  6.798 ms

6  v6-ins-dc1-et-8-2.desm.netins.net (2001:5f8::1:1)  8.682 ms  8.294 ms
7.910 ms

7  2001:428:3801:210:0:1:0:1 (2001:428:3801:210:0:1:0:1)  20.790 ms  20.447
ms  20.133 ms

8  * * *

9  * * *

10  * * *

11  * * *

12  * * *

13  * * *

14  * * *

15  * * *

16  * * *

17  * * *

18  * * *

19  * * *

20  * * *

21  * * *

22  * * *

23  * * *

24  * * *

25  * * *

26  * * *

27  * * *

28  * * *

29  * * *

30  * * *

nagios:/home/fbulk#

 

 

Frank

 

From: PC [mailto:paul4004 at gmail.com] 
Sent: Monday, September 19, 2011 12:13 PM
To: frnkblk at iname.com
Cc: nanog at nanog.org
Subject: Re: IPv6 side of www.charter.com has been down since Friday,
September 16 5:12 am Central

 

Works fine here.

# wget -6 www.charter.com
--2011-09-19 10:24:37--  http://www.charter.com/
Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `index.html'

    [  <=>
] 112,940      288K/s   in 0.4s

2011-09-19 10:24:43 (288 KB/s) - `index.html' saved [112940]


traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 80
byte packets
 1  2607:f2f8:xxxx::1 (2607:f2f8:xxxx::1)  18.721 ms  18.699 ms  18.689 ms
 2  2001:504:13::1a (2001:504:13::1a)  1.256 ms  1.672 ms  1.428 ms
 3  10gigabitethernet1-2.core1.den1.he.net (2001:470:0:15d::1)  26.498 ms
26.486 ms  26.466 ms
 4  10gigabitethernet1-1.core1.chi1.he.net (2001:470:0:1af::1)  49.986 ms
49.529 ms  49.521 ms
 5  2001:470:0:114::2 (2001:470:0:114::2)  50.105 ms  49.632 ms  49.626 ms
 6  bbr02chcgil-tge0-1-0-0.il.chcg.charter.com (2001:506:100:313::1)  55.805
ms  54.254 ms bbr02chcgil-tge0-0-0-0.il.chcg.charter.com
(2001:506:100:305::1)  55.880 ms
 7  bbr01olvemo-tge0-4-0-4.mo.olve.charter.com (2001:506:100:55::1)  69.465
ms  63.351 ms  63.314 ms
 8  bdr01tncomo-tge1-1.mo.tnco.charter.com (2001:506:100:23::2)  60.018 ms
59.597 ms  59.586 ms
 9  2001:506:100:6c::2 (2001:506:100:6c::2)  60.251 ms  60.245 ms  60.236 ms
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *



On Mon, Sep 19, 2011 at 11:08 AM, Frank Bulk <frnkblk at iname.com> wrote:

The IPv6 side of www.charter.com has been down since Friday, September 16
5:12 am Central.  Emails to their NOC have gone unanswered.  If anyone on
list can nudge their ops group that would be appreciated.

Frank


nagios:/home/fbulk# wget -6 www.charter.com
--2011-09-19 08:23:58--  http://www.charter.com/
Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:24:20--  (try: 2)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:24:43--  (try: 3)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:07--  (try: 4)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:32--  (try: 5)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:58--  (try: 6)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:26:25--  (try: 7)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:26:53--  (try: 8)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:27:22--  (try: 9)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:27:52--  (try:10)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:28:23--  (try:11)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:28:54--  (try:12)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:29:25--  (try:13)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:29:56--  (try:14)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:30:27--  (try:15)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:30:58--  (try:16)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:31:29--  (try:17)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:32:00--  (try:18)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:32:31--  (try:19)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:33:02--  (try:20)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Giving up.

nagios:/home/fbulk#



 


From jml at packetpimp.org  Mon Sep 19 12:41:23 2011
From: jml at packetpimp.org (Jason LeBlanc)
Date: Mon, 19 Sep 2011 13:41:23 -0400
Subject: Internet mauled by bears
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
Message-ID: <4E777EC3.6010507@packetpimp.org>

We have had fiber shot with what apparently was apparently a handgun in 
down town Miami.  Interesting that is fairly common.

On 09/19/2011 12:45 PM, Eric J Esslinger wrote:
>
>
>> -----Original Message-----
>> From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com]
>>
>>
>> On Mon, Sep 19, 2011 at 4:16 PM, Eugen Leitl<eugen at leitl.org>  wrote:
>>> He pointed out that these are the kind of problems city
>> folk probably
>>> don't have in an urban area because there is a bear shortage.
>> And backwoods towns have rednecks with shotguns, and bubba
>> the backhoe driver exists everywhere there's a road ..
> To be honest, while we have had some 'shotgun peppered' fiber runs in our rural TN town (mostly in one spot, due to dove hunters), after comparing notes with a lady that works for Mediacom I think it is preferable to having to have security escorts for their crews in some rough urban areas because gangs will shoot up plant then wait for the crews to show up so they can rob them.
>
> Everyone has issues as which are as diverse as the areas we deploy in.
> __________________________
> Eric Esslinger
> Information Services Manager - Fayetteville Public Utilities
> http://www.fpu-tn.com/
> (931)433-1522 ext 165
>
> This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.


From paul4004 at gmail.com  Mon Sep 19 12:54:45 2011
From: paul4004 at gmail.com (PC)
Date: Mon, 19 Sep 2011 11:54:45 -0600
Subject: Internet mauled by bears
In-Reply-To: <4E777EC3.6010507@packetpimp.org>
References: <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <4E777EC3.6010507@packetpimp.org>
Message-ID: <CAJAdsDkba8LWv=1jc_z=DAu65Mf3QT9_H=-Jwo3WzSCU7eAJkQ@mail.gmail.com>

Worth a read:
http://blog.level3.com/2011/08/04/the-10-most-bizarre-and-annoying-causes-of-fiber-cuts/


On Mon, Sep 19, 2011 at 11:41 AM, Jason LeBlanc <jml at packetpimp.org> wrote:

> We have had fiber shot with what apparently was apparently a handgun in
> down town Miami.  Interesting that is fairly common.
>
>
> On 09/19/2011 12:45 PM, Eric J Esslinger wrote:
>
>>
>>
>>  -----Original Message-----
>>> From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com]
>>>
>>>
>>> On Mon, Sep 19, 2011 at 4:16 PM, Eugen Leitl<eugen at leitl.org>  wrote:
>>>
>>>> He pointed out that these are the kind of problems city
>>>>
>>> folk probably
>>>
>>>> don't have in an urban area because there is a bear shortage.
>>>>
>>> And backwoods towns have rednecks with shotguns, and bubba
>>> the backhoe driver exists everywhere there's a road ..
>>>
>> To be honest, while we have had some 'shotgun peppered' fiber runs in our
>> rural TN town (mostly in one spot, due to dove hunters), after comparing
>> notes with a lady that works for Mediacom I think it is preferable to having
>> to have security escorts for their crews in some rough urban areas because
>> gangs will shoot up plant then wait for the crews to show up so they can rob
>> them.
>>
>> Everyone has issues as which are as diverse as the areas we deploy in.
>> __________________________
>> Eric Esslinger
>> Information Services Manager - Fayetteville Public Utilities
>> http://www.fpu-tn.com/
>> (931)433-1522 ext 165
>>
>> This message may contain confidential and/or proprietary information and
>> is intended for the person/entity to whom it was originally addressed. Any
>> use by others is strictly prohibited.
>>
>
>

From nick at flhsi.com  Mon Sep 19 12:57:55 2011
From: nick at flhsi.com (Nick Olsen)
Date: Mon, 19 Sep 2011 13:57:55 -0400
Subject: IPv6 side of www.charter.com has been down since Friday,
 September 16 5:12 am Central
Message-ID: <155861a0$152e3abf$45084047$@com>

Takes our HE tunnel to get out. Were also Native with Cogent (Not that it 
gets us anything..)

No dice.


[root at bench ~]# wget -6 www.charter.com

--2011-09-19 13:53:17--  http://www.charter.com/

Resolving www.charter.com... 2607:f428:3:1:80:80:80:1

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80...


Times Out


[root at bench ~]# traceroute6 www.charter.com

traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 40 
byte packets

 1   (2606:2400:141::1)  1.169 ms  1.157 ms  1.145 ms

 2   (2606:2400:222::d)  31.685 ms  36.812 ms  37.104 ms

 3   (2606:2400:222::5)  37.387 ms  37.456 ms  37.477 ms

 4  brevardwireless-1.tunnel.tserv7.ash1.ipv6.he.net (2001:470:1f0d:c5::1)  
123.090 ms  123.371 ms  123.334 ms

 5  v104.core1.ash1.he.net (2001:470:0:40::2)  122.542 ms  122.523 ms  
122.516 ms

 6  10gigabitethernet1-2.core1.atl1.he.net (2001:470:0:1b5::2)  142.508 ms  
129.220 ms  131.762 ms

 7  2001:470:0:115::2 (2001:470:0:115::2)  131.537 ms  131.696 ms  131.739 
ms

 8  bbr01sghlga-tge0-2-0-1.ga.sghl.charter.com (2001:506:100:326::1)  
143.856 ms bbr01sghlga-tge0-0-0-0.ga.sghl.charter.com (2001:506:100:308::1) 
 140.164 ms  140.196 ms

 9  bbr01blvlil-tge0-3-0-4.il.blvl.charter.com (2001:506:100:42::2)  
151.880 ms  152.019 ms  151.955 ms

10  bbr01olvemo-tge0-1-0-6.mo.olve.charter.com (2001:506:100:8::1)  151.669 
ms  151.681 ms  151.665 ms

11  bdr01tncomo-tge1-1.mo.tnco.charter.com (2001:506:100:23::2)  149.784 ms 
 149.851 ms  149.852 ms

12  2001:506:100:6c::2 (2001:506:100:6c::2)  147.953 ms  147.470 ms  
147.479 ms

13  * * *

14  * * *

15  * * *

16  * * *

17  * * *

18  *


Nick Olsen

Network Operations
(855) FLSPEED  x106

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

From: "Frank Bulk" <frnkblk at iname.com>

Sent: Monday, September 19, 2011 1:38 PM

To: "PC" <paul4004 at gmail.com>

Subject: RE: IPv6 side of www.charter.com has been down since Friday, 
September 16 5:12 am Central


I've been told by someone else offline that it's fine for them, too.  Last

hop according to tcptraceroute6 is Qwest.  Anyone else going to

www.charter.com (IPv6) through Qwest?


nagios:/home/fbulk# tcptraceroute6 www.charter.com


traceroute to www.charter.com (2607:f428:3:1:80:80:80:1) from

2607:fe28:0:1000::5, port 80, from port 43838, 30 hops max, 60 bytes 
packets


1  2607:fe28:0:1003::2 (2607:fe28:0:1003::2)  1.075 ms  1.258 ms  1.857 ms


2  router-core.mtcnet.net (2607:fe28:0:1000::1)  1.625 ms  2.271 ms  1.331

ms


3  sxct.sxcy.mtcnet.net (2607:fe28:11:1002::197)  2.581 ms  1.568 ms  
1.215

ms


4  v6-siouxcenter.sxcy.137.netins.net (2001:5f8:7f06::5)  3.347 ms  3.007 
ms

2.640 ms


5  v6-ins-db1-te-13-2-219.desm.netins.net (2001:5f8:1:1::1)  7.441 ms  
7.121

ms  6.798 ms


6  v6-ins-dc1-et-8-2.desm.netins.net (2001:5f8::1:1)  8.682 ms  8.294 ms

7.910 ms


7  2001:428:3801:210:0:1:0:1 (2001:428:3801:210:0:1:0:1)  20.790 ms  
20.447

ms  20.133 ms


8  * * *


9  * * *


10  * * *


11  * * *


12  * * *


13  * * *


14  * * *


15  * * *


16  * * *


17  * * *


18  * * *


19  * * *


20  * * *


21  * * *


22  * * *


23  * * *


24  * * *


25  * * *


26  * * *


27  * * *


28  * * *


29  * * *


30  * * *


nagios:/home/fbulk#


Frank


From: PC [mailto:paul4004 at gmail.com] 

Sent: Monday, September 19, 2011 12:13 PM

To: frnkblk at iname.com

Cc: nanog at nanog.org

Subject: Re: IPv6 side of www.charter.com has been down since Friday,

September 16 5:12 am Central


Works fine here.


# wget -6 www.charter.com

--2011-09-19 10:24:37--  http://www.charter.com/

Resolving www.charter.com... 2607:f428:3:1:80:80:80:1

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: `index.html'


[  <=>

] 112,940      288K/s   in 0.4s


2011-09-19 10:24:43 (288 KB/s) - `index.html' saved [112940]


traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 80

byte packets

1  2607:f2f8:xxxx::1 (2607:f2f8:xxxx::1)  18.721 ms  18.699 ms  18.689 ms

2  2001:504:13::1a (2001:504:13::1a)  1.256 ms  1.672 ms  1.428 ms

3  10gigabitethernet1-2.core1.den1.he.net (2001:470:0:15d::1)  26.498 ms

26.486 ms  26.466 ms

4  10gigabitethernet1-1.core1.chi1.he.net (2001:470:0:1af::1)  49.986 ms

49.529 ms  49.521 ms

5  2001:470:0:114::2 (2001:470:0:114::2)  50.105 ms  49.632 ms  49.626 ms

6  bbr02chcgil-tge0-1-0-0.il.chcg.charter.com (2001:506:100:313::1)  
55.805

ms  54.254 ms bbr02chcgil-tge0-0-0-0.il.chcg.charter.com

(2001:506:100:305::1)  55.880 ms

7  bbr01olvemo-tge0-4-0-4.mo.olve.charter.com (2001:506:100:55::1)  69.465

ms  63.351 ms  63.314 ms

8  bdr01tncomo-tge1-1.mo.tnco.charter.com (2001:506:100:23::2)  60.018 ms

59.597 ms  59.586 ms

9  2001:506:100:6c::2 (2001:506:100:6c::2)  60.251 ms  60.245 ms  60.236 
ms

10  * * *

11  * * *

12  * * *

13  * * *

14  * * *


On Mon, Sep 19, 2011 at 11:08 AM, Frank Bulk <frnkblk at iname.com> wrote:


The IPv6 side of www.charter.com has been down since Friday, September 16

5:12 am Central.  Emails to their NOC have gone unanswered.  If anyone on

list can nudge their ops group that would be appreciated.


Frank


nagios:/home/fbulk# wget -6 www.charter.com

--2011-09-19 08:23:58--  http://www.charter.com/

Resolving www.charter.com... 2607:f428:3:1:80:80:80:1

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:24:20--  (try: 2)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:24:43--  (try: 3)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:25:07--  (try: 4)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:25:32--  (try: 5)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:25:58--  (try: 6)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:26:25--  (try: 7)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:26:53--  (try: 8)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:27:22--  (try: 9)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:27:52--  (try:10)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:28:23--  (try:11)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:28:54--  (try:12)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:29:25--  (try:13)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:29:56--  (try:14)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:30:27--  (try:15)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:30:58--  (try:16)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:31:29--  (try:17)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:32:00--  (try:18)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:32:31--  (try:19)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Retrying.


--2011-09-19 08:33:02--  (try:20)  http://www.charter.com/

Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:

Connection timed out.

Giving up.


nagios:/home/fbulk#



From raymond at prolocation.net  Mon Sep 19 13:48:22 2011
From: raymond at prolocation.net (Raymond Dijkxhoorn)
Date: Mon, 19 Sep 2011 20:48:22 +0200 (CEST)
Subject: IPv6 side of www.charter.com has been down since Friday, September
 16 5:12 am Central
In-Reply-To: <155861a0$152e3abf$45084047$@com>
References: <155861a0$152e3abf$45084047$@com>
Message-ID: <alpine.LFD.2.00.1109192047420.16021@noc.prolocation.net>

Hi!

> Takes our HE tunnel to get out. Were also Native with Cogent (Not that it
> gets us anything..)
>
> No dice.

Native also no luck here (from .nl) :

[root at ipv6proxy ~]#  traceroute6 www.charter.com
traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 80 
byte packets
  1  2a00:d00:ff:131::253 (2a00:d00:ff:131::253)  0.610 ms  0.708 ms  0.700 
ms
  2  2a00:d00:1:4::2 (2a00:d00:1:4::2)  0.644 ms  0.637 ms  0.745 ms
  3  hurricane-electric.nikhef.nlsix.net (2001:7f8:13::a500:6939:1)  0.549 
ms  0.547 ms  0.551 ms
  4  10gigabitethernet1-4.core1.lon1.he.net (2001:470:0:3f::1)  8.584 ms 
8.587 ms  8.609 ms
  5  10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:3e::1)  76.459 ms 
76.473 ms  76.453 ms
  6  10gigabitethernet8-3.core1.chi1.he.net (2001:470:0:1c6::2)  97.787 ms 
96.714 ms  93.772 ms
  7  2001:470:0:114::2 (2001:470:0:114::2)  93.941 ms  93.924 ms  93.968 ms
  8  bbr02chcgil-tge0-1-0-1.il.chcg.charter.com (2001:506:100:31d::1) 
104.974 ms bbr02chcgil-tge0-0-0-1.il.chcg.charter.com 
(2001:506:100:317::2)  99.650 ms 
bbr02chcgil-tge0-0-0-0.il.chcg.charter.com (2001:506:100:305::1)  99.767 
ms
  9  bbr01olvemo-tge0-5-0-4.mo.olve.charter.com (2001:506:100:5c::2) 
106.416 ms  101.397 ms  101.371 ms
10  * * *
11  2001:506:100:6c::2 (2001:506:100:6c::2)  101.667 ms  101.553 ms 
101.598 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  *^C
[root at ipv6proxy ~]# ping6 www.charter.com
PING www.charter.com(2607:f428:3:1:80:80:80:1) 56 data bytes
^C
--- www.charter.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3700ms

[root at ipv6proxy ~]# wget -6 www.charter.com
--2011-09-19 20:47:13--  http://www.charter.com/
Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80...

Bye,
Raymond.


From jvanoppen at spectrumnet.us  Mon Sep 19 13:50:50 2011
From: jvanoppen at spectrumnet.us (John van Oppen)
Date: Mon, 19 Sep 2011 18:50:50 +0000
Subject: Internet mauled by bears
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
Message-ID: <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>

We had a cow break down a door to a remote microwave site once...    now we are the proud owners of a generator backed electric fence at that site...    Rural physical plant issues are almost always entertaining.  :)

John


-----Original Message-----
From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] 
Sent: Monday, September 19, 2011 9:45 AM
To: 'nanog at nanog.org'
Subject: RE: Internet mauled by bears




> -----Original Message-----
> From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com]
>
>
> On Mon, Sep 19, 2011 at 4:16 PM, Eugen Leitl <eugen at leitl.org> wrote:
> > He pointed out that these are the kind of problems city
> folk probably
> > don't have in an urban area because there is a bear shortage.
>
> And backwoods towns have rednecks with shotguns, and bubba the backhoe 
> driver exists everywhere there's a road ..
To be honest, while we have had some 'shotgun peppered' fiber runs in our rural TN town (mostly in one spot, due to dove hunters), after comparing notes with a lady that works for Mediacom I think it is preferable to having to have security escorts for their crews in some rough urban areas because gangs will shoot up plant then wait for the crews to show up so they can rob them.

Everyone has issues as which are as diverse as the areas we deploy in.
__________________________
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/
(931)433-1522 ext 165

This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.


From ryan at longlines.com  Mon Sep 19 14:09:12 2011
From: ryan at longlines.com (Ryan Gray)
Date: Mon, 19 Sep 2011 14:09:12 -0500
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24
In-Reply-To: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F19D22DE@FHDP1LUMXC7V43.us.one.verizon.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
 <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
 <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F19D22DE@FHDP1LUMXC7V43.us.one.verizon.com>
Message-ID: <C353DE35-7505-48B1-AFF3-C20DB30A966B@longlines.com>

Actually just started seeing these problems again today.  Is anyone else seeing this today from something other than 212.118.142.0/24?  Looks like it started about two hours ago.


Regards,
Ryan Gray
Long Lines
www.longlines.com





On Sep 12, 2011, at 8:18 PM, Schiller, Heather A wrote:

> 
> Could be this..?
> 
> http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/configuration-statement/independent-domain-edit-routing-options.html  
> 
> "unrecognized transitive attributes" depend on whatever code version you are running... What's more important is how the unrecoginized attribute is handled.  Ideally you accept and pass the route and log it.  The problem is with devices that aren't so graceful.. dropping sessions and wreaking havoc:
> 
> http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml
> 
> --Heather 
> 
> -----Original Message-----
> From: Aftab Siddiqui [mailto:aftab.siddiqui at gmail.com] 
> Sent: Saturday, September 10, 2011 6:49 PM
> To: Richard Barnes
> Cc: Jonas Frey (Probe Networks); nanog at nanog.org
> Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24
> 
> with in the span of couple of hours this prefix was originated from 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians).
> 
> As per the STC it was orginated by one of their customer having Juniper router. but I still don't understand why/how they are adv this prefix with unrecog transitive attributes.
> 
> Can any one suggest.
> 
> Regards,
> 
> Aftab A. Siddiqui
> 
> 
> On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes <richard.barnes at gmail.com>wrote:
> 
>> Looks like the RIS collectors are seeing it originating mostly from 
>> STC and KACST ASNs:
>> <http://stat.ripe.net/212.118.142.0/24>
>> 
>> Some of the "show ip bgp" reports on that screen are also showing
>> AS8866 "BTC-AS Bulgarian Telecommunication Company".  Not sure what's 
>> up with that.
>> 
>> --Richard
>> 
>> 
>> 
>> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow 
>> <morrowc.lists at gmail.com> wrote:
>>> On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren <pixitha.kyle at gmail.com>
>> wrote:
>>>> Is this announcement still showing up this way (no easy way to 
>>>> check myself).
>>> 
>>> ripe ris?
>>> 
>>>> -Kyle
>>>> 
>>>> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes 
>>>> <chaynes at centracomm.net>
>> wrote:
>>>> 
>>>>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) < 
>>>>> jf at probe-networks.de> wrote:
>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> anyone else getting a route for 212.118.142.0/24 with invalid 
>>>>>> attributes? Seems this is (again) causing problems with some 
>>>>>> (older) routers/software.
>>>>>> 
>>>>>>              Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 
>>>>>> 1 6-Resolve tree 2
>>>>>>               AS path: 6453 39386 25019 I Unrecognized Attributes:
>> 39
>>>>>> bytes
>>>>>>               AS path:  Attr flags e0 code 80: 00 00 fd 88 40 
>>>>>> 01 01
>> 02
>>>>>> 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 
>>>>>> 40 05
>> 04
>>>>>> 00 00 00 64
>>>>>>               Accepted Multipath
>>>>>> 
>>>>>> 
>>>>>> -Jonas
>>>>>> 
>>>>>> 
>>>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>>>> Originating AS is 25019
>>>>> 
>>>>> -Clay
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 



From Valdis.Kletnieks at vt.edu  Mon Sep 19 14:23:03 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 19 Sep 2011 15:23:03 -0400
Subject: IPv6 side of www.charter.com has been down since Friday,
 September 16 5:12 am Central
In-Reply-To: Your message of "Mon, 19 Sep 2011 13:57:55 EDT."
 <155861a0$152e3abf$45084047$@com>
References: <155861a0$152e3abf$45084047$@com>
Message-ID: <12830.1316460183@turing-police.cc.vt.edu>

On Mon, 19 Sep 2011 13:57:55 EDT, Nick Olsen said:
> Takes our HE tunnel to get out. Were also Native with Cogent (Not that it 
> gets us anything..)
> 
> No dice.

wget throws a timeout from here too, from the internet2 side.

%  traceroute6 -A www.charter.com
traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 80 byte packets
 1  isb-6509-1.vl103.cns.ipv6.vt.edu (2001:468:c80:2103::1) [AS1312]  0.523 ms  0.727 ms  0.715 ms
 2  isb-6509-2.po51.cns.ipv6.vt.edu (2001:468:c80:f220::1) [AS1312]  0.413 ms  0.629 ms  0.616 ms
 3  isb-7606-2.te3-3.cns.ipv6.vt.edu (2001:468:c80:f222::2) [AS1312]  0.560 ms  0.537 ms  0.769 ms
 4  matp-lvl3-7609-1.vl10.cns.ipv6.vt.edu (2001:468:cfe:1002::1) [AS40220]  8.542 ms  8.524 ms  8.494 ms
 5  xe-3-0-0.277.asbn0.tr-cps.internet2.edu (2001:468:f000:2234::1) [*]  9.164 ms  9.134 ms  9.096 ms
 6  2001:1860:110:f03::1 (2001:1860:110:f03::1) [AS101]  27.520 ms  27.521 ms  27.429 ms
 7  2001:468:f000:1110::2 (2001:468:f000:1110::2) [*]  27.776 ms  27.665 ms  27.465 ms
 8  bbr02chcgil-tge0-0-0-0.il.chcg.charter.com (2001:506:100:305::1) [*]  29.087 ms  29.001 ms bbr02chcgil-tge0-0-0-1.il.chcg.charter.com (2001:506:100:317::2) [*]  28.855 ms
 9  * * *

And that's all she wrote...  Nice RTTs till it hits a brick wall near Chicago..

Anybody seeing anything *else* impacted by this?  How many IPv6 customers does
Charter have?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110919/575216f2/attachment-0001.bin>

From heather.schiller at verizon.com  Mon Sep 19 14:26:29 2011
From: heather.schiller at verizon.com (Schiller, Heather A)
Date: Mon, 19 Sep 2011 15:26:29 -0400
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24 - Redux
In-Reply-To: <C353DE35-7505-48B1-AFF3-C20DB30A966B@longlines.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
 <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
 <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F19D22DE@FHDP1LUMXC7V43.us.one.verizon.com>
 <C353DE35-7505-48B1-AFF3-C20DB30A966B@longlines.com>
Message-ID: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661B95C@FHDP1LUMXC7V43.us.one.verizon.com>


Seeing it again here too.. Has anyone contacted them?

..and for folks who are choosing to blackhole the prefix in order to supress the route, please remember not to export it!

AS25019	SAUDINETSTC-AS Autonomus System Number for SaudiNet	2011-09-08 18:23:53 UTC	2011-09-19 19:16:27 UTC
AS8866	BTC-AS Bulgarian Telecommunication Company Plc.	2011-09-08 18:35:14 UTC	2011-09-19 19:15:42 UTC
AS10026	PACNET Pacnet Global Ltd	2011-09-11 02:41:40 UTC	2011-09-19 16:00:00 UTC
AS8767	MNET-AS M-net AS	2011-09-14 12:13:01 UTC	2011-09-14 12:14:00 UTC
AS3561	SAVVIS - Savvis	2011-09-09 19:42:15 UTC	2011-09-10 16:27:18 UTC
AS3549	GBLX Global Crossing Ltd.	2011-09-09 16:13:15 UTC	2011-09-09 17:05:38 UTC
AS1239	SPRINTLINK - Sprint	2011-09-09 03:18:28 UTC	2011-09-09 15:56:41 UTC
AS65000	-Private Use AS-	2011-09-08 18:34:28 UTC	2011-09-08 18:34:29 UTC

 --heather 

-----Original Message-----
From: Ryan Gray [mailto:ryan at longlines.com] 
Sent: Monday, September 19, 2011 3:09 PM
To: Schiller, Heather A
Cc: Aftab Siddiqui; Richard Barnes; Jonas Frey (Probe Networks); nanog at nanog.org
Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24

Actually just started seeing these problems again today.  Is anyone else seeing this today from something other than 212.118.142.0/24?  Looks like it started about two hours ago.


Regards,
Ryan Gray
Long Lines
www.longlines.com





On Sep 12, 2011, at 8:18 PM, Schiller, Heather A wrote:

> 
> Could be this..?
> 
> http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/confi
> guration-statement/independent-domain-edit-routing-options.html
> 
> "unrecognized transitive attributes" depend on whatever code version you are running... What's more important is how the unrecoginized attribute is handled.  Ideally you accept and pass the route and log it.  The problem is with devices that aren't so graceful.. dropping sessions and wreaking havoc:
> 
> http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml
> 
> --Heather
> 
> -----Original Message-----
> From: Aftab Siddiqui [mailto:aftab.siddiqui at gmail.com]
> Sent: Saturday, September 10, 2011 6:49 PM
> To: Richard Barnes
> Cc: Jonas Frey (Probe Networks); nanog at nanog.org
> Subject: Re: Saudi Telecom sending route with invalid attributes 
> 212.118.142.0/24
> 
> with in the span of couple of hours this prefix was originated from 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians).
> 
> As per the STC it was orginated by one of their customer having Juniper router. but I still don't understand why/how they are adv this prefix with unrecog transitive attributes.
> 
> Can any one suggest.
> 
> Regards,
> 
> Aftab A. Siddiqui
> 
> 
> On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes <richard.barnes at gmail.com>wrote:
> 
>> Looks like the RIS collectors are seeing it originating mostly from 
>> STC and KACST ASNs:
>> <http://stat.ripe.net/212.118.142.0/24>
>> 
>> Some of the "show ip bgp" reports on that screen are also showing
>> AS8866 "BTC-AS Bulgarian Telecommunication Company".  Not sure what's 
>> up with that.
>> 
>> --Richard
>> 
>> 
>> 
>> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow 
>> <morrowc.lists at gmail.com> wrote:
>>> On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren <pixitha.kyle at gmail.com>
>> wrote:
>>>> Is this announcement still showing up this way (no easy way to 
>>>> check myself).
>>> 
>>> ripe ris?
>>> 
>>>> -Kyle
>>>> 
>>>> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes 
>>>> <chaynes at centracomm.net>
>> wrote:
>>>> 
>>>>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) < 
>>>>> jf at probe-networks.de> wrote:
>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> anyone else getting a route for 212.118.142.0/24 with invalid 
>>>>>> attributes? Seems this is (again) causing problems with some
>>>>>> (older) routers/software.
>>>>>> 
>>>>>>              Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
>>>>>> 1 6-Resolve tree 2
>>>>>>               AS path: 6453 39386 25019 I Unrecognized Attributes:
>> 39
>>>>>> bytes
>>>>>>               AS path:  Attr flags e0 code 80: 00 00 fd 88 40
>>>>>> 01 01
>> 02
>>>>>> 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 
>>>>>> 05
>> 04
>>>>>> 00 00 00 64
>>>>>>               Accepted Multipath
>>>>>> 
>>>>>> 
>>>>>> -Jonas
>>>>>> 
>>>>>> 
>>>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>>>> Originating AS is 25019
>>>>> 
>>>>> -Clay
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 



From g at 1337.io  Mon Sep 19 14:29:04 2011
From: g at 1337.io (Gino)
Date: Mon, 19 Sep 2011 12:29:04 -0700
Subject: IPv6 side of www.charter.com has been down since Friday, September
 16 5:12 am Central
In-Reply-To: <155861a0$152e3abf$45084047$@com>
References: <155861a0$152e3abf$45084047$@com>
Message-ID: <4E779800.1050507@1337.io>

Strange, a curl request works for me through one of our he.net tunnels
but not the other (sorry, won't post the address space on the list).


On 9/19/11 10:57 AM, Nick Olsen wrote:
> Takes our HE tunnel to get out. Were also Native with Cogent (Not that it 
> gets us anything..)
> 
> No dice.
> 
> 
> [root at bench ~]# wget -6 www.charter.com
> 
> --2011-09-19 13:53:17--  http://www.charter.com/
> 
> Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80...
> 
> 
> Times Out
> 
> 
> [root at bench ~]# traceroute6 www.charter.com
> 
> traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 40 
> byte packets
> 
>  1   (2606:2400:141::1)  1.169 ms  1.157 ms  1.145 ms
> 
>  2   (2606:2400:222::d)  31.685 ms  36.812 ms  37.104 ms
> 
>  3   (2606:2400:222::5)  37.387 ms  37.456 ms  37.477 ms
> 
>  4  brevardwireless-1.tunnel.tserv7.ash1.ipv6.he.net (2001:470:1f0d:c5::1)  
> 123.090 ms  123.371 ms  123.334 ms
> 
>  5  v104.core1.ash1.he.net (2001:470:0:40::2)  122.542 ms  122.523 ms  
> 122.516 ms
> 
>  6  10gigabitethernet1-2.core1.atl1.he.net (2001:470:0:1b5::2)  142.508 ms  
> 129.220 ms  131.762 ms
> 
>  7  2001:470:0:115::2 (2001:470:0:115::2)  131.537 ms  131.696 ms  131.739 
> ms
> 
>  8  bbr01sghlga-tge0-2-0-1.ga.sghl.charter.com (2001:506:100:326::1)  
> 143.856 ms bbr01sghlga-tge0-0-0-0.ga.sghl.charter.com (2001:506:100:308::1) 
>  140.164 ms  140.196 ms
> 
>  9  bbr01blvlil-tge0-3-0-4.il.blvl.charter.com (2001:506:100:42::2)  
> 151.880 ms  152.019 ms  151.955 ms
> 
> 10  bbr01olvemo-tge0-1-0-6.mo.olve.charter.com (2001:506:100:8::1)  151.669 
> ms  151.681 ms  151.665 ms
> 
> 11  bdr01tncomo-tge1-1.mo.tnco.charter.com (2001:506:100:23::2)  149.784 ms 
>  149.851 ms  149.852 ms
> 
> 12  2001:506:100:6c::2 (2001:506:100:6c::2)  147.953 ms  147.470 ms  
> 147.479 ms
> 
> 13  * * *
> 
> 14  * * *
> 
> 15  * * *
> 
> 16  * * *
> 
> 17  * * *
> 
> 18  *
> 
> 
> Nick Olsen
> 
> Network Operations
> (855) FLSPEED  x106
> 
> ----------------------------------------
> 
> From: "Frank Bulk" <frnkblk at iname.com>
> 
> Sent: Monday, September 19, 2011 1:38 PM
> 
> To: "PC" <paul4004 at gmail.com>
> 
> Subject: RE: IPv6 side of www.charter.com has been down since Friday, 
> September 16 5:12 am Central
> 
> 
> I've been told by someone else offline that it's fine for them, too.  Last
> 
> hop according to tcptraceroute6 is Qwest.  Anyone else going to
> 
> www.charter.com (IPv6) through Qwest?
> 
> 
> nagios:/home/fbulk# tcptraceroute6 www.charter.com
> 
> 
> traceroute to www.charter.com (2607:f428:3:1:80:80:80:1) from
> 
> 2607:fe28:0:1000::5, port 80, from port 43838, 30 hops max, 60 bytes 
> packets
> 
> 
> 1  2607:fe28:0:1003::2 (2607:fe28:0:1003::2)  1.075 ms  1.258 ms  1.857 ms
> 
> 
> 2  router-core.mtcnet.net (2607:fe28:0:1000::1)  1.625 ms  2.271 ms  1.331
> 
> ms
> 
> 
> 3  sxct.sxcy.mtcnet.net (2607:fe28:11:1002::197)  2.581 ms  1.568 ms  
> 1.215
> 
> ms
> 
> 
> 4  v6-siouxcenter.sxcy.137.netins.net (2001:5f8:7f06::5)  3.347 ms  3.007 
> ms
> 
> 2.640 ms
> 
> 
> 5  v6-ins-db1-te-13-2-219.desm.netins.net (2001:5f8:1:1::1)  7.441 ms  
> 7.121
> 
> ms  6.798 ms
> 
> 
> 6  v6-ins-dc1-et-8-2.desm.netins.net (2001:5f8::1:1)  8.682 ms  8.294 ms
> 
> 7.910 ms
> 
> 
> 7  2001:428:3801:210:0:1:0:1 (2001:428:3801:210:0:1:0:1)  20.790 ms  
> 20.447
> 
> ms  20.133 ms
> 
> 
> 8  * * *
> 
> 
> 9  * * *
> 
> 
> 10  * * *
> 
> 
> 11  * * *
> 
> 
> 12  * * *
> 
> 
> 13  * * *
> 
> 
> 14  * * *
> 
> 
> 15  * * *
> 
> 
> 16  * * *
> 
> 
> 17  * * *
> 
> 
> 18  * * *
> 
> 
> 19  * * *
> 
> 
> 20  * * *
> 
> 
> 21  * * *
> 
> 
> 22  * * *
> 
> 
> 23  * * *
> 
> 
> 24  * * *
> 
> 
> 25  * * *
> 
> 
> 26  * * *
> 
> 
> 27  * * *
> 
> 
> 28  * * *
> 
> 
> 29  * * *
> 
> 
> 30  * * *
> 
> 
> nagios:/home/fbulk#
> 
> 
> Frank
> 
> 
> From: PC [mailto:paul4004 at gmail.com] 
> 
> Sent: Monday, September 19, 2011 12:13 PM
> 
> To: frnkblk at iname.com
> 
> Cc: nanog at nanog.org
> 
> Subject: Re: IPv6 side of www.charter.com has been down since Friday,
> 
> September 16 5:12 am Central
> 
> 
> Works fine here.
> 
> 
> # wget -6 www.charter.com
> 
> --2011-09-19 10:24:37--  http://www.charter.com/
> 
> Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... connected.
> 
> HTTP request sent, awaiting response... 200 OK
> 
> Length: unspecified [text/html]
> 
> Saving to: `index.html'
> 
> 
> [  <=>
> 
> ] 112,940      288K/s   in 0.4s
> 
> 
> 2011-09-19 10:24:43 (288 KB/s) - `index.html' saved [112940]
> 
> 
> traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 80
> 
> byte packets
> 
> 1  2607:f2f8:xxxx::1 (2607:f2f8:xxxx::1)  18.721 ms  18.699 ms  18.689 ms
> 
> 2  2001:504:13::1a (2001:504:13::1a)  1.256 ms  1.672 ms  1.428 ms
> 
> 3  10gigabitethernet1-2.core1.den1.he.net (2001:470:0:15d::1)  26.498 ms
> 
> 26.486 ms  26.466 ms
> 
> 4  10gigabitethernet1-1.core1.chi1.he.net (2001:470:0:1af::1)  49.986 ms
> 
> 49.529 ms  49.521 ms
> 
> 5  2001:470:0:114::2 (2001:470:0:114::2)  50.105 ms  49.632 ms  49.626 ms
> 
> 6  bbr02chcgil-tge0-1-0-0.il.chcg.charter.com (2001:506:100:313::1)  
> 55.805
> 
> ms  54.254 ms bbr02chcgil-tge0-0-0-0.il.chcg.charter.com
> 
> (2001:506:100:305::1)  55.880 ms
> 
> 7  bbr01olvemo-tge0-4-0-4.mo.olve.charter.com (2001:506:100:55::1)  69.465
> 
> ms  63.351 ms  63.314 ms
> 
> 8  bdr01tncomo-tge1-1.mo.tnco.charter.com (2001:506:100:23::2)  60.018 ms
> 
> 59.597 ms  59.586 ms
> 
> 9  2001:506:100:6c::2 (2001:506:100:6c::2)  60.251 ms  60.245 ms  60.236 
> ms
> 
> 10  * * *
> 
> 11  * * *
> 
> 12  * * *
> 
> 13  * * *
> 
> 14  * * *
> 
> 
> On Mon, Sep 19, 2011 at 11:08 AM, Frank Bulk <frnkblk at iname.com> wrote:
> 
> 
> The IPv6 side of www.charter.com has been down since Friday, September 16
> 
> 5:12 am Central.  Emails to their NOC have gone unanswered.  If anyone on
> 
> list can nudge their ops group that would be appreciated.
> 
> 
> Frank
> 
> 
> nagios:/home/fbulk# wget -6 www.charter.com
> 
> --2011-09-19 08:23:58--  http://www.charter.com/
> 
> Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:24:20--  (try: 2)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:24:43--  (try: 3)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:25:07--  (try: 4)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:25:32--  (try: 5)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:25:58--  (try: 6)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:26:25--  (try: 7)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:26:53--  (try: 8)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:27:22--  (try: 9)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:27:52--  (try:10)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:28:23--  (try:11)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:28:54--  (try:12)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:29:25--  (try:13)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:29:56--  (try:14)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:30:27--  (try:15)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:30:58--  (try:16)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:31:29--  (try:17)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:32:00--  (try:18)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:32:31--  (try:19)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:33:02--  (try:20)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Giving up.
> 
> 
> nagios:/home/fbulk#
> 
> 

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system. If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.


From Brian.Schleeper at chartercom.com  Mon Sep 19 14:56:54 2011
From: Brian.Schleeper at chartercom.com (Schleeper, Brian)
Date: Mon, 19 Sep 2011 14:56:54 -0500
Subject: IPv6 side of www.charter.com has been down since Friday,
 September 16 5:12 am Central
In-Reply-To: <001601cc76ee$c30c50c0$4924f240$@iname.com>
References: <001601cc76ee$c30c50c0$4924f240$@iname.com>
Message-ID: <1DB5A12D98EB024FA4A9D0355029655A064C0DE3@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM>

It looks like we have identified the issue, and we are currently working to resolve as quickly as possible.  

-Brian



-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Monday, September 19, 2011 12:09 PM
To: nanog at nanog.org
Subject: IPv6 side of www.charter.com has been down since Friday, September 16 5:12 am Central

The IPv6 side of www.charter.com has been down since Friday, September 16
5:12 am Central.  Emails to their NOC have gone unanswered.  If anyone on
list can nudge their ops group that would be appreciated.

Frank


nagios:/home/fbulk# wget -6 www.charter.com
--2011-09-19 08:23:58--  http://www.charter.com/
Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:24:20--  (try: 2)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:24:43--  (try: 3)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:07--  (try: 4)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:32--  (try: 5)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:58--  (try: 6)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:26:25--  (try: 7)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:26:53--  (try: 8)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:27:22--  (try: 9)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:27:52--  (try:10)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:28:23--  (try:11)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:28:54--  (try:12)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:29:25--  (try:13)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:29:56--  (try:14)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:30:27--  (try:15)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:30:58--  (try:16)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:31:29--  (try:17)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:32:00--  (try:18)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:32:31--  (try:19)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:33:02--  (try:20)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Giving up.

nagios:/home/fbulk#



E-MAIL CONFIDENTIALITY NOTICE: 

 

 

 

The contents of this e-mail message and 
any attachments are intended solely for the 
addressee(s) and may contain confidential 
and/or legally privileged information. If you 
are not the intended recipient of this message 
or if this message has been addressed to you 
in error, please immediately alert the sender
 by reply e-mail and then delete this message 
and any attachments. If you are not the 
intended recipient, you are notified that 
any use, dissemination, distribution, copying, 
or storage of this message or any attachment 
is strictly prohibited.










From frnkblk at iname.com  Mon Sep 19 15:05:04 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Mon, 19 Sep 2011 15:05:04 -0500
Subject: IPv6 side of www.charter.com has been down since Friday,
 September 16 5:12 am Central
In-Reply-To: <4E779800.1050507@1337.io>
References: <155861a0$152e3abf$45084047$@com> <4E779800.1050507@1337.io>
Message-ID: <002e01cc7707$6baf51b0$430df510$@iname.com>

Several offlist contacts have shared working and non-working results, so
it's a mixed bag.  

Frank

-----Original Message-----
From: Gino [mailto:g at 1337.io] 
Sent: Monday, September 19, 2011 2:29 PM
To: nanog at nanog.org
Subject: Re: IPv6 side of www.charter.com has been down since Friday,
September 16 5:12 am Central

Strange, a curl request works for me through one of our he.net tunnels
but not the other (sorry, won't post the address space on the list).


On 9/19/11 10:57 AM, Nick Olsen wrote:
> Takes our HE tunnel to get out. Were also Native with Cogent (Not that it 
> gets us anything..)
> 
> No dice.
> 
> 
> [root at bench ~]# wget -6 www.charter.com
> 
> --2011-09-19 13:53:17--  http://www.charter.com/
> 
> Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80...
> 
> 
> Times Out
> 
> 
> [root at bench ~]# traceroute6 www.charter.com
> 
> traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 40 
> byte packets
> 
>  1   (2606:2400:141::1)  1.169 ms  1.157 ms  1.145 ms
> 
>  2   (2606:2400:222::d)  31.685 ms  36.812 ms  37.104 ms
> 
>  3   (2606:2400:222::5)  37.387 ms  37.456 ms  37.477 ms
> 
>  4  brevardwireless-1.tunnel.tserv7.ash1.ipv6.he.net (2001:470:1f0d:c5::1)

> 123.090 ms  123.371 ms  123.334 ms
> 
>  5  v104.core1.ash1.he.net (2001:470:0:40::2)  122.542 ms  122.523 ms  
> 122.516 ms
> 
>  6  10gigabitethernet1-2.core1.atl1.he.net (2001:470:0:1b5::2)  142.508 ms

> 129.220 ms  131.762 ms
> 
>  7  2001:470:0:115::2 (2001:470:0:115::2)  131.537 ms  131.696 ms  131.739

> ms
> 
>  8  bbr01sghlga-tge0-2-0-1.ga.sghl.charter.com (2001:506:100:326::1)  
> 143.856 ms bbr01sghlga-tge0-0-0-0.ga.sghl.charter.com
(2001:506:100:308::1) 
>  140.164 ms  140.196 ms
> 
>  9  bbr01blvlil-tge0-3-0-4.il.blvl.charter.com (2001:506:100:42::2)  
> 151.880 ms  152.019 ms  151.955 ms
> 
> 10  bbr01olvemo-tge0-1-0-6.mo.olve.charter.com (2001:506:100:8::1)
151.669 
> ms  151.681 ms  151.665 ms
> 
> 11  bdr01tncomo-tge1-1.mo.tnco.charter.com (2001:506:100:23::2)  149.784
ms 
>  149.851 ms  149.852 ms
> 
> 12  2001:506:100:6c::2 (2001:506:100:6c::2)  147.953 ms  147.470 ms  
> 147.479 ms
> 
> 13  * * *
> 
> 14  * * *
> 
> 15  * * *
> 
> 16  * * *
> 
> 17  * * *
> 
> 18  *
> 
> 
> Nick Olsen
> 
> Network Operations
> (855) FLSPEED  x106
> 
> ----------------------------------------
> 
> From: "Frank Bulk" <frnkblk at iname.com>
> 
> Sent: Monday, September 19, 2011 1:38 PM
> 
> To: "PC" <paul4004 at gmail.com>
> 
> Subject: RE: IPv6 side of www.charter.com has been down since Friday, 
> September 16 5:12 am Central
> 
> 
> I've been told by someone else offline that it's fine for them, too.  Last
> 
> hop according to tcptraceroute6 is Qwest.  Anyone else going to
> 
> www.charter.com (IPv6) through Qwest?
> 
> 
> nagios:/home/fbulk# tcptraceroute6 www.charter.com
> 
> 
> traceroute to www.charter.com (2607:f428:3:1:80:80:80:1) from
> 
> 2607:fe28:0:1000::5, port 80, from port 43838, 30 hops max, 60 bytes 
> packets
> 
> 
> 1  2607:fe28:0:1003::2 (2607:fe28:0:1003::2)  1.075 ms  1.258 ms  1.857 ms
> 
> 
> 2  router-core.mtcnet.net (2607:fe28:0:1000::1)  1.625 ms  2.271 ms  1.331
> 
> ms
> 
> 
> 3  sxct.sxcy.mtcnet.net (2607:fe28:11:1002::197)  2.581 ms  1.568 ms  
> 1.215
> 
> ms
> 
> 
> 4  v6-siouxcenter.sxcy.137.netins.net (2001:5f8:7f06::5)  3.347 ms  3.007 
> ms
> 
> 2.640 ms
> 
> 
> 5  v6-ins-db1-te-13-2-219.desm.netins.net (2001:5f8:1:1::1)  7.441 ms  
> 7.121
> 
> ms  6.798 ms
> 
> 
> 6  v6-ins-dc1-et-8-2.desm.netins.net (2001:5f8::1:1)  8.682 ms  8.294 ms
> 
> 7.910 ms
> 
> 
> 7  2001:428:3801:210:0:1:0:1 (2001:428:3801:210:0:1:0:1)  20.790 ms  
> 20.447
> 
> ms  20.133 ms
> 
> 
> 8  * * *
> 
> 
> 9  * * *
> 
> 
> 10  * * *
> 
> 
> 11  * * *
> 
> 
> 12  * * *
> 
> 
> 13  * * *
> 
> 
> 14  * * *
> 
> 
> 15  * * *
> 
> 
> 16  * * *
> 
> 
> 17  * * *
> 
> 
> 18  * * *
> 
> 
> 19  * * *
> 
> 
> 20  * * *
> 
> 
> 21  * * *
> 
> 
> 22  * * *
> 
> 
> 23  * * *
> 
> 
> 24  * * *
> 
> 
> 25  * * *
> 
> 
> 26  * * *
> 
> 
> 27  * * *
> 
> 
> 28  * * *
> 
> 
> 29  * * *
> 
> 
> 30  * * *
> 
> 
> nagios:/home/fbulk#
> 
> 
> Frank
> 
> 
> From: PC [mailto:paul4004 at gmail.com] 
> 
> Sent: Monday, September 19, 2011 12:13 PM
> 
> To: frnkblk at iname.com
> 
> Cc: nanog at nanog.org
> 
> Subject: Re: IPv6 side of www.charter.com has been down since Friday,
> 
> September 16 5:12 am Central
> 
> 
> Works fine here.
> 
> 
> # wget -6 www.charter.com
> 
> --2011-09-19 10:24:37--  http://www.charter.com/
> 
> Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... connected.
> 
> HTTP request sent, awaiting response... 200 OK
> 
> Length: unspecified [text/html]
> 
> Saving to: `index.html'
> 
> 
> [  <=>
> 
> ] 112,940      288K/s   in 0.4s
> 
> 
> 2011-09-19 10:24:43 (288 KB/s) - `index.html' saved [112940]
> 
> 
> traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 80
> 
> byte packets
> 
> 1  2607:f2f8:xxxx::1 (2607:f2f8:xxxx::1)  18.721 ms  18.699 ms  18.689 ms
> 
> 2  2001:504:13::1a (2001:504:13::1a)  1.256 ms  1.672 ms  1.428 ms
> 
> 3  10gigabitethernet1-2.core1.den1.he.net (2001:470:0:15d::1)  26.498 ms
> 
> 26.486 ms  26.466 ms
> 
> 4  10gigabitethernet1-1.core1.chi1.he.net (2001:470:0:1af::1)  49.986 ms
> 
> 49.529 ms  49.521 ms
> 
> 5  2001:470:0:114::2 (2001:470:0:114::2)  50.105 ms  49.632 ms  49.626 ms
> 
> 6  bbr02chcgil-tge0-1-0-0.il.chcg.charter.com (2001:506:100:313::1)  
> 55.805
> 
> ms  54.254 ms bbr02chcgil-tge0-0-0-0.il.chcg.charter.com
> 
> (2001:506:100:305::1)  55.880 ms
> 
> 7  bbr01olvemo-tge0-4-0-4.mo.olve.charter.com (2001:506:100:55::1)  69.465
> 
> ms  63.351 ms  63.314 ms
> 
> 8  bdr01tncomo-tge1-1.mo.tnco.charter.com (2001:506:100:23::2)  60.018 ms
> 
> 59.597 ms  59.586 ms
> 
> 9  2001:506:100:6c::2 (2001:506:100:6c::2)  60.251 ms  60.245 ms  60.236 
> ms
> 
> 10  * * *
> 
> 11  * * *
> 
> 12  * * *
> 
> 13  * * *
> 
> 14  * * *
> 
> 
> On Mon, Sep 19, 2011 at 11:08 AM, Frank Bulk <frnkblk at iname.com> wrote:
> 
> 
> The IPv6 side of www.charter.com has been down since Friday, September 16
> 
> 5:12 am Central.  Emails to their NOC have gone unanswered.  If anyone on
> 
> list can nudge their ops group that would be appreciated.
> 
> 
> Frank
> 
> 
> nagios:/home/fbulk# wget -6 www.charter.com
> 
> --2011-09-19 08:23:58--  http://www.charter.com/
> 
> Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:24:20--  (try: 2)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:24:43--  (try: 3)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:25:07--  (try: 4)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:25:32--  (try: 5)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:25:58--  (try: 6)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:26:25--  (try: 7)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:26:53--  (try: 8)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:27:22--  (try: 9)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:27:52--  (try:10)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:28:23--  (try:11)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:28:54--  (try:12)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:29:25--  (try:13)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:29:56--  (try:14)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:30:27--  (try:15)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:30:58--  (try:16)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:31:29--  (try:17)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:32:00--  (try:18)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:32:31--  (try:19)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Retrying.
> 
> 
> --2011-09-19 08:33:02--  (try:20)  http://www.charter.com/
> 
> Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
> 
> Connection timed out.
> 
> Giving up.
> 
> 
> nagios:/home/fbulk#
> 
> 

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system. If you are
not the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.




From frnkblk at iname.com  Mon Sep 19 15:42:50 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Mon, 19 Sep 2011 15:42:50 -0500
Subject: IPv6 side of www.charter.com has been down since Friday,
 September 16 5:12 am Central
In-Reply-To: <1DB5A12D98EB024FA4A9D0355029655A064C0DE3@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM>
References: <001601cc76ee$c30c50c0$4924f240$@iname.com>
 <1DB5A12D98EB024FA4A9D0355029655A064C0DE3@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM>
Message-ID: <002f01cc770c$b2897ed0$179c7c70$@iname.com>

Our monitoring system reported that the site now is accessible -- thanks!

Frank

-----Original Message-----
From: Schleeper, Brian [mailto:Brian.Schleeper at chartercom.com] 
Sent: Monday, September 19, 2011 2:57 PM
To: frnkblk at iname.com; nanog at nanog.org
Subject: RE: IPv6 side of www.charter.com has been down since Friday,
September 16 5:12 am Central

It looks like we have identified the issue, and we are currently working to
resolve as quickly as possible.  

-Brian

-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Monday, September 19, 2011 12:09 PM
To: nanog at nanog.org
Subject: IPv6 side of www.charter.com has been down since Friday, September
16 5:12 am Central

The IPv6 side of www.charter.com has been down since Friday, September 16
5:12 am Central.  Emails to their NOC have gone unanswered.  If anyone on
list can nudge their ops group that would be appreciated.

Frank


nagios:/home/fbulk# wget -6 www.charter.com
--2011-09-19 08:23:58--  http://www.charter.com/
Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:24:20--  (try: 2)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:24:43--  (try: 3)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:07--  (try: 4)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:32--  (try: 5)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:25:58--  (try: 6)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:26:25--  (try: 7)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:26:53--  (try: 8)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:27:22--  (try: 9)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:27:52--  (try:10)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:28:23--  (try:11)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:28:54--  (try:12)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:29:25--  (try:13)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:29:56--  (try:14)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:30:27--  (try:15)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:30:58--  (try:16)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:31:29--  (try:17)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:32:00--  (try:18)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:32:31--  (try:19)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Retrying.

--2011-09-19 08:33:02--  (try:20)  http://www.charter.com/
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... failed:
Connection timed out.
Giving up.

nagios:/home/fbulk#



E-MAIL CONFIDENTIALITY NOTICE: 

 

 

 

The contents of this e-mail message and 
any attachments are intended solely for the 
addressee(s) and may contain confidential 
and/or legally privileged information. If you 
are not the intended recipient of this message 
or if this message has been addressed to you 
in error, please immediately alert the sender
 by reply e-mail and then delete this message 
and any attachments. If you are not the 
intended recipient, you are notified that 
any use, dissemination, distribution, copying, 
or storage of this message or any attachment 
is strictly prohibited.











From morrowc.lists at gmail.com  Mon Sep 19 15:54:23 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 19 Sep 2011 16:54:23 -0400
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24 - Redux
In-Reply-To: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661B95C@FHDP1LUMXC7V43.us.one.verizon.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
 <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
 <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F19D22DE@FHDP1LUMXC7V43.us.one.verizon.com>
 <C353DE35-7505-48B1-AFF3-C20DB30A966B@longlines.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661B95C@FHDP1LUMXC7V43.us.one.verizon.com>
Message-ID: <CAL9jLaZr3rfPY4A4vb8cdy9N2hR_8-bB0pzp6o5XY2A1hzsm1Q@mail.gmail.com>

In the off chance that no one already attempted an email to the folks
nominally in charge there:

person:         Hejji almazroua
address:        SaudiNet
address:        P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
phone:          +9661 218 0300
fax-no:         +9661 218 0311
e-mail:         info at irnetco.net
nic-hdl:        Ha125-RIPE
mnt-by:         irnetco-ripe-mnt
source:         RIPE # Filtered

person:       Suliman I. Al-Zain
address:      Saudi Telecom Co. (SaudiNet)
address:      P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
phone:        +9661 218 2034
fax-no:       +9661 218 0311
e-mail:       suliman.alzain at saudi.net.sa
nic-hdl:      SA702-RIPE
source:       RIPE # Filtered


Do the Saudi-Telecom folks have a method to suppress the /24
(212.118.142.0/24) which is also covered by: 212.118.128.0/19

it'd really help lots of other Internet folk if you'd suppress this /24 ...

-chris

On Mon, Sep 19, 2011 at 3:26 PM, Schiller, Heather A
<heather.schiller at verizon.com> wrote:
>
> Seeing it again here too.. Has anyone contacted them?
>
> ..and for folks who are choosing to blackhole the prefix in order to supress the route, please remember not to export it!
>
> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet ? ? 2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
> AS8866 ?BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08 18:35:14 UTC 2011-09-19 19:15:42 UTC
> AS10026 PACNET Pacnet Global Ltd ? ? ? ?2011-09-11 02:41:40 UTC 2011-09-19 16:00:00 UTC
> AS8767 ?MNET-AS M-net AS ? ? ? ?2011-09-14 12:13:01 UTC 2011-09-14 12:14:00 UTC
> AS3561 ?SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18 UTC
> AS3549 ?GBLX Global Crossing Ltd. ? ? ? 2011-09-09 16:13:15 UTC 2011-09-09 17:05:38 UTC
> AS1239 ?SPRINTLINK - Sprint ? ? 2011-09-09 03:18:28 UTC 2011-09-09 15:56:41 UTC
> AS65000 -Private Use AS- ? ? ? ?2011-09-08 18:34:28 UTC 2011-09-08 18:34:29 UTC
>
> ?--heather
>
> -----Original Message-----
> From: Ryan Gray [mailto:ryan at longlines.com]
> Sent: Monday, September 19, 2011 3:09 PM
> To: Schiller, Heather A
> Cc: Aftab Siddiqui; Richard Barnes; Jonas Frey (Probe Networks); nanog at nanog.org
> Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24
>
> Actually just started seeing these problems again today. ?Is anyone else seeing this today from something other than 212.118.142.0/24? ?Looks like it started about two hours ago.
>
>
> Regards,
> Ryan Gray
> Long Lines
> www.longlines.com
>
>
>
>
>
> On Sep 12, 2011, at 8:18 PM, Schiller, Heather A wrote:
>
>>
>> Could be this..?
>>
>> http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/confi
>> guration-statement/independent-domain-edit-routing-options.html
>>
>> "unrecognized transitive attributes" depend on whatever code version you are running... What's more important is how the unrecoginized attribute is handled. ?Ideally you accept and pass the route and log it. ?The problem is with devices that aren't so graceful.. dropping sessions and wreaking havoc:
>>
>> http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml
>>
>> --Heather
>>
>> -----Original Message-----
>> From: Aftab Siddiqui [mailto:aftab.siddiqui at gmail.com]
>> Sent: Saturday, September 10, 2011 6:49 PM
>> To: Richard Barnes
>> Cc: Jonas Frey (Probe Networks); nanog at nanog.org
>> Subject: Re: Saudi Telecom sending route with invalid attributes
>> 212.118.142.0/24
>>
>> with in the span of couple of hours this prefix was originated from 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians).
>>
>> As per the STC it was orginated by one of their customer having Juniper router. but I still don't understand why/how they are adv this prefix with unrecog transitive attributes.
>>
>> Can any one suggest.
>>
>> Regards,
>>
>> Aftab A. Siddiqui
>>
>>
>> On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes <richard.barnes at gmail.com>wrote:
>>
>>> Looks like the RIS collectors are seeing it originating mostly from
>>> STC and KACST ASNs:
>>> <http://stat.ripe.net/212.118.142.0/24>
>>>
>>> Some of the "show ip bgp" reports on that screen are also showing
>>> AS8866 "BTC-AS Bulgarian Telecommunication Company". ?Not sure what's
>>> up with that.
>>>
>>> --Richard
>>>
>>>
>>>
>>> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow
>>> <morrowc.lists at gmail.com> wrote:
>>>> On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren <pixitha.kyle at gmail.com>
>>> wrote:
>>>>> Is this announcement still showing up this way (no easy way to
>>>>> check myself).
>>>>
>>>> ripe ris?
>>>>
>>>>> -Kyle
>>>>>
>>>>> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes
>>>>> <chaynes at centracomm.net>
>>> wrote:
>>>>>
>>>>>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
>>>>>> jf at probe-networks.de> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> anyone else getting a route for 212.118.142.0/24 with invalid
>>>>>>> attributes? Seems this is (again) causing problems with some
>>>>>>> (older) routers/software.
>>>>>>>
>>>>>>> ? ? ? ? ? ? ?Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
>>>>>>> 1 6-Resolve tree 2
>>>>>>> ? ? ? ? ? ? ? AS path: 6453 39386 25019 I Unrecognized Attributes:
>>> 39
>>>>>>> bytes
>>>>>>> ? ? ? ? ? ? ? AS path: ?Attr flags e0 code 80: 00 00 fd 88 40
>>>>>>> 01 01
>>> 02
>>>>>>> 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40
>>>>>>> 05
>>> 04
>>>>>>> 00 00 00 64
>>>>>>> ? ? ? ? ? ? ? Accepted Multipath
>>>>>>>
>>>>>>>
>>>>>>> -Jonas
>>>>>>>
>>>>>>>
>>>>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>>>>> Originating AS is 25019
>>>>>>
>>>>>> -Clay
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>


From morrowc.lists at gmail.com  Mon Sep 19 15:58:00 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 19 Sep 2011 16:58:00 -0400
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24 - Redux
In-Reply-To: <CAL9jLaZr3rfPY4A4vb8cdy9N2hR_8-bB0pzp6o5XY2A1hzsm1Q@mail.gmail.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
 <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
 <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F19D22DE@FHDP1LUMXC7V43.us.one.verizon.com>
 <C353DE35-7505-48B1-AFF3-C20DB30A966B@longlines.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661B95C@FHDP1LUMXC7V43.us.one.verizon.com>
 <CAL9jLaZr3rfPY4A4vb8cdy9N2hR_8-bB0pzp6o5XY2A1hzsm1Q@mail.gmail.com>
Message-ID: <CAL9jLaZCEcJNZYvy60QGCcPeF3nFMbq-zFiwy34w53ag8FDibQ@mail.gmail.com>

suliman.alzain at saudi.net.sa - bounces :( Ripe folks (if listening)
perhaps you could ping the other live POC's there and request an
update? :)

On Mon, Sep 19, 2011 at 4:54 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> In the off chance that no one already attempted an email to the folks
> nominally in charge there:
>
> person: ? ? ? ? Hejji almazroua
> address: ? ? ? ?SaudiNet
> address: ? ? ? ?P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> phone: ? ? ? ? ?+9661 218 0300
> fax-no: ? ? ? ? +9661 218 0311
> e-mail: ? ? ? ? info at irnetco.net
> nic-hdl: ? ? ? ?Ha125-RIPE
> mnt-by: ? ? ? ? irnetco-ripe-mnt
> source: ? ? ? ? RIPE # Filtered
>
> person: ? ? ? Suliman I. Al-Zain
> address: ? ? ?Saudi Telecom Co. (SaudiNet)
> address: ? ? ?P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> phone: ? ? ? ?+9661 218 2034
> fax-no: ? ? ? +9661 218 0311
> e-mail: ? ? ? suliman.alzain at saudi.net.sa
> nic-hdl: ? ? ?SA702-RIPE
> source: ? ? ? RIPE # Filtered
>
>
> Do the Saudi-Telecom folks have a method to suppress the /24
> (212.118.142.0/24) which is also covered by: 212.118.128.0/19
>
> it'd really help lots of other Internet folk if you'd suppress this /24 ...
>
> -chris
>
> On Mon, Sep 19, 2011 at 3:26 PM, Schiller, Heather A
> <heather.schiller at verizon.com> wrote:
>>
>> Seeing it again here too.. Has anyone contacted them?
>>
>> ..and for folks who are choosing to blackhole the prefix in order to supress the route, please remember not to export it!
>>
>> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet ? ? 2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
>> AS8866 ?BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08 18:35:14 UTC 2011-09-19 19:15:42 UTC
>> AS10026 PACNET Pacnet Global Ltd ? ? ? ?2011-09-11 02:41:40 UTC 2011-09-19 16:00:00 UTC
>> AS8767 ?MNET-AS M-net AS ? ? ? ?2011-09-14 12:13:01 UTC 2011-09-14 12:14:00 UTC
>> AS3561 ?SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18 UTC
>> AS3549 ?GBLX Global Crossing Ltd. ? ? ? 2011-09-09 16:13:15 UTC 2011-09-09 17:05:38 UTC
>> AS1239 ?SPRINTLINK - Sprint ? ? 2011-09-09 03:18:28 UTC 2011-09-09 15:56:41 UTC
>> AS65000 -Private Use AS- ? ? ? ?2011-09-08 18:34:28 UTC 2011-09-08 18:34:29 UTC
>>
>> ?--heather
>>
>> -----Original Message-----
>> From: Ryan Gray [mailto:ryan at longlines.com]
>> Sent: Monday, September 19, 2011 3:09 PM
>> To: Schiller, Heather A
>> Cc: Aftab Siddiqui; Richard Barnes; Jonas Frey (Probe Networks); nanog at nanog.org
>> Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24
>>
>> Actually just started seeing these problems again today. ?Is anyone else seeing this today from something other than 212.118.142.0/24? ?Looks like it started about two hours ago.
>>
>>
>> Regards,
>> Ryan Gray
>> Long Lines
>> www.longlines.com
>>
>>
>>
>>
>>
>> On Sep 12, 2011, at 8:18 PM, Schiller, Heather A wrote:
>>
>>>
>>> Could be this..?
>>>
>>> http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/confi
>>> guration-statement/independent-domain-edit-routing-options.html
>>>
>>> "unrecognized transitive attributes" depend on whatever code version you are running... What's more important is how the unrecoginized attribute is handled. ?Ideally you accept and pass the route and log it. ?The problem is with devices that aren't so graceful.. dropping sessions and wreaking havoc:
>>>
>>> http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml
>>>
>>> --Heather
>>>
>>> -----Original Message-----
>>> From: Aftab Siddiqui [mailto:aftab.siddiqui at gmail.com]
>>> Sent: Saturday, September 10, 2011 6:49 PM
>>> To: Richard Barnes
>>> Cc: Jonas Frey (Probe Networks); nanog at nanog.org
>>> Subject: Re: Saudi Telecom sending route with invalid attributes
>>> 212.118.142.0/24
>>>
>>> with in the span of couple of hours this prefix was originated from 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians).
>>>
>>> As per the STC it was orginated by one of their customer having Juniper router. but I still don't understand why/how they are adv this prefix with unrecog transitive attributes.
>>>
>>> Can any one suggest.
>>>
>>> Regards,
>>>
>>> Aftab A. Siddiqui
>>>
>>>
>>> On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes <richard.barnes at gmail.com>wrote:
>>>
>>>> Looks like the RIS collectors are seeing it originating mostly from
>>>> STC and KACST ASNs:
>>>> <http://stat.ripe.net/212.118.142.0/24>
>>>>
>>>> Some of the "show ip bgp" reports on that screen are also showing
>>>> AS8866 "BTC-AS Bulgarian Telecommunication Company". ?Not sure what's
>>>> up with that.
>>>>
>>>> --Richard
>>>>
>>>>
>>>>
>>>> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow
>>>> <morrowc.lists at gmail.com> wrote:
>>>>> On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren <pixitha.kyle at gmail.com>
>>>> wrote:
>>>>>> Is this announcement still showing up this way (no easy way to
>>>>>> check myself).
>>>>>
>>>>> ripe ris?
>>>>>
>>>>>> -Kyle
>>>>>>
>>>>>> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes
>>>>>> <chaynes at centracomm.net>
>>>> wrote:
>>>>>>
>>>>>>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
>>>>>>> jf at probe-networks.de> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> anyone else getting a route for 212.118.142.0/24 with invalid
>>>>>>>> attributes? Seems this is (again) causing problems with some
>>>>>>>> (older) routers/software.
>>>>>>>>
>>>>>>>> ? ? ? ? ? ? ?Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
>>>>>>>> 1 6-Resolve tree 2
>>>>>>>> ? ? ? ? ? ? ? AS path: 6453 39386 25019 I Unrecognized Attributes:
>>>> 39
>>>>>>>> bytes
>>>>>>>> ? ? ? ? ? ? ? AS path: ?Attr flags e0 code 80: 00 00 fd 88 40
>>>>>>>> 01 01
>>>> 02
>>>>>>>> 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40
>>>>>>>> 05
>>>> 04
>>>>>>>> 00 00 00 64
>>>>>>>> ? ? ? ? ? ? ? Accepted Multipath
>>>>>>>>
>>>>>>>>
>>>>>>>> -Jonas
>>>>>>>>
>>>>>>>>
>>>>>>> Yup! We're seeing the same thing too, and we're filtering it out.
>>>>>>> Originating AS is 25019
>>>>>>>
>>>>>>> -Clay
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>


From ebais at a2b-internet.com  Mon Sep 19 16:17:17 2011
From: ebais at a2b-internet.com (Erik Bais)
Date: Mon, 19 Sep 2011 23:17:17 +0200
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24 - Redux
In-Reply-To: <CAL9jLaZCEcJNZYvy60QGCcPeF3nFMbq-zFiwy34w53ag8FDibQ@mail.gmail.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
 <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
 <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F19D22DE@FHDP1LUMXC7V43.us.one.verizon.com>
 <C353DE35-7505-48B1-AFF3-C20DB30A966B@longlines.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661B95C@FHDP1LUMXC7V43.us.one.verizon.com>
 <CAL9jLaZr3rfPY4A4vb8cdy9N2hR_8-bB0pzp6o5XY2A1hzsm1Q@mail.gmail.com>
 <CAL9jLaZCEcJNZYvy60QGCcPeF3nFMbq-zFiwy34w53ag8FDibQ@mail.gmail.com>
Message-ID: <010701cc7711$82dd6ac0$88984040$@com>

Hi Chris, 

I've send an email to the person I know within STC responsible for
international transit. 

Let's hope he can assist. 

Regards,
Erik Bais

> -----Original Message-----
> From: Christopher Morrow [mailto:morrowc.lists at gmail.com]
> Sent: Monday, September 19, 2011 10:58 PM
> To: Schiller, Heather A; info at irnetco.net
> Cc: Jonas Frey (Probe Networks); nanog at nanog.org
> Subject: Re: Saudi Telecom sending route with invalid attributes
> 212.118.142.0/24 - Redux
> 
> suliman.alzain at saudi.net.sa - bounces :( Ripe folks (if listening)
> perhaps you could ping the other live POC's there and request an
> update? :)
> 
> On Mon, Sep 19, 2011 at 4:54 PM, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
> > In the off chance that no one already attempted an email to the folks
> > nominally in charge there:
> >
> > person: ? ? ? ? Hejji almazroua
> > address: ? ? ? ?SaudiNet
> > address: ? ? ? ?P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> > phone: ? ? ? ? ?+9661 218 0300
> > fax-no: ? ? ? ? +9661 218 0311
> > e-mail: ? ? ? ? info at irnetco.net
> > nic-hdl: ? ? ? ?Ha125-RIPE
> > mnt-by: ? ? ? ? irnetco-ripe-mnt
> > source: ? ? ? ? RIPE # Filtered
> >
> > person: ? ? ? Suliman I. Al-Zain
> > address: ? ? ?Saudi Telecom Co. (SaudiNet)
> > address: ? ? ?P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> > phone: ? ? ? ?+9661 218 2034
> > fax-no: ? ? ? +9661 218 0311
> > e-mail: ? ? ? suliman.alzain at saudi.net.sa
> > nic-hdl: ? ? ?SA702-RIPE
> > source: ? ? ? RIPE # Filtered
> >
> >
> > Do the Saudi-Telecom folks have a method to suppress the /24
> > (212.118.142.0/24) which is also covered by: 212.118.128.0/19
> >
> > it'd really help lots of other Internet folk if you'd suppress this
> /24 ...
> >
> > -chris
> >
> > On Mon, Sep 19, 2011 at 3:26 PM, Schiller, Heather A
> > <heather.schiller at verizon.com> wrote:
> >>
> >> Seeing it again here too.. Has anyone contacted them?
> >>
> >> ..and for folks who are choosing to blackhole the prefix in order to
> supress the route, please remember not to export it!
> >>
> >> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet
> 2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
> >> AS8866 ?BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08
> 18:35:14 UTC 2011-09-19 19:15:42 UTC
> >> AS10026 PACNET Pacnet Global Ltd ? ? ? ?2011-09-11 02:41:40 UTC
> 2011-09-19 16:00:00 UTC
> >> AS8767 ?MNET-AS M-net AS ? ? ? ?2011-09-14 12:13:01 UTC 2011-09-14
> 12:14:00 UTC
> >> AS3561 ?SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18
> UTC
> >> AS3549 ?GBLX Global Crossing Ltd. ? ? ? 2011-09-09 16:13:15 UTC
> 2011-09-09 17:05:38 UTC
> >> AS1239 ?SPRINTLINK - Sprint ? ? 2011-09-09 03:18:28 UTC 2011-09-09
> 15:56:41 UTC
> >> AS65000 -Private Use AS- ? ? ? ?2011-09-08 18:34:28 UTC 2011-09-08
> 18:34:29 UTC
> >>
> >> ?--heather
> >>
> >> -----Original Message-----
> >> From: Ryan Gray [mailto:ryan at longlines.com]
> >> Sent: Monday, September 19, 2011 3:09 PM
> >> To: Schiller, Heather A
> >> Cc: Aftab Siddiqui; Richard Barnes; Jonas Frey (Probe Networks);
> nanog at nanog.org
> >> Subject: Re: Saudi Telecom sending route with invalid attributes
> 212.118.142.0/24
> >>
> >> Actually just started seeing these problems again today. ?Is anyone
> else seeing this today from something other than 212.118.142.0/24?
> ?Looks like it started about two hours ago.
> >>
> >>
> >> Regards,
> >> Ryan Gray
> >> Long Lines
> >> www.longlines.com
> >>
> >>
> >>
> >>
> >>
> >> On Sep 12, 2011, at 8:18 PM, Schiller, Heather A wrote:
> >>
> >>>
> >>> Could be this..?
> >>>
> >>>
> http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/confi
> >>> guration-statement/independent-domain-edit-routing-options.html
> >>>
> >>> "unrecognized transitive attributes" depend on whatever code
> version you are running... What's more important is how the
> unrecoginized attribute is handled. ?Ideally you accept and pass the
> route and log it. ?The problem is with devices that aren't so
> graceful.. dropping sessions and wreaking havoc:
> >>>
> >>> http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml
> >>>
> >>> --Heather
> >>>
> >>> -----Original Message-----
> >>> From: Aftab Siddiqui [mailto:aftab.siddiqui at gmail.com]
> >>> Sent: Saturday, September 10, 2011 6:49 PM
> >>> To: Richard Barnes
> >>> Cc: Jonas Frey (Probe Networks); nanog at nanog.org
> >>> Subject: Re: Saudi Telecom sending route with invalid attributes
> >>> 212.118.142.0/24
> >>>
> >>> with in the span of couple of hours this prefix was originated from
> 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original
> custodians).
> >>>
> >>> As per the STC it was orginated by one of their customer having
> Juniper router. but I still don't understand why/how they are adv this
> prefix with unrecog transitive attributes.
> >>>
> >>> Can any one suggest.
> >>>
> >>> Regards,
> >>>
> >>> Aftab A. Siddiqui
> >>>
> >>>
> >>> On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes
> <richard.barnes at gmail.com>wrote:
> >>>
> >>>> Looks like the RIS collectors are seeing it originating mostly
> from
> >>>> STC and KACST ASNs:
> >>>> <http://stat.ripe.net/212.118.142.0/24>
> >>>>
> >>>> Some of the "show ip bgp" reports on that screen are also showing
> >>>> AS8866 "BTC-AS Bulgarian Telecommunication Company". ?Not sure
> what's
> >>>> up with that.
> >>>>
> >>>> --Richard
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow
> >>>> <morrowc.lists at gmail.com> wrote:
> >>>>> On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren
> <pixitha.kyle at gmail.com>
> >>>> wrote:
> >>>>>> Is this announcement still showing up this way (no easy way to
> >>>>>> check myself).
> >>>>>
> >>>>> ripe ris?
> >>>>>
> >>>>>> -Kyle
> >>>>>>
> >>>>>> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes
> >>>>>> <chaynes at centracomm.net>
> >>>> wrote:
> >>>>>>
> >>>>>>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
> >>>>>>> jf at probe-networks.de> wrote:
> >>>>>>>
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> anyone else getting a route for 212.118.142.0/24 with invalid
> >>>>>>>> attributes? Seems this is (again) causing problems with some
> >>>>>>>> (older) routers/software.
> >>>>>>>>
> >>>>>>>> ? ? ? ? ? ? ?Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
> >>>>>>>> 1 6-Resolve tree 2
> >>>>>>>> ? ? ? ? ? ? ? AS path: 6453 39386 25019 I Unrecognized
> Attributes:
> >>>> 39
> >>>>>>>> bytes
> >>>>>>>> ? ? ? ? ? ? ? AS path: ?Attr flags e0 code 80: 00 00 fd 88 40
> >>>>>>>> 01 01
> >>>> 02
> >>>>>>>> 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01
> 40
> >>>>>>>> 05
> >>>> 04
> >>>>>>>> 00 00 00 64
> >>>>>>>> ? ? ? ? ? ? ? Accepted Multipath
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -Jonas
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Yup! We're seeing the same thing too, and we're filtering it
> out.
> >>>>>>> Originating AS is 25019
> >>>>>>>
> >>>>>>> -Clay
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1410 / Virus Database: 1520/3906 - Release Date: 09/19/11



From morrowc.lists at gmail.com  Mon Sep 19 16:24:48 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 19 Sep 2011 17:24:48 -0400
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24 - Redux
In-Reply-To: <010701cc7711$82dd6ac0$88984040$@com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
 <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
 <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F19D22DE@FHDP1LUMXC7V43.us.one.verizon.com>
 <C353DE35-7505-48B1-AFF3-C20DB30A966B@longlines.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661B95C@FHDP1LUMXC7V43.us.one.verizon.com>
 <CAL9jLaZr3rfPY4A4vb8cdy9N2hR_8-bB0pzp6o5XY2A1hzsm1Q@mail.gmail.com>
 <CAL9jLaZCEcJNZYvy60QGCcPeF3nFMbq-zFiwy34w53ag8FDibQ@mail.gmail.com>
 <010701cc7711$82dd6ac0$88984040$@com>
Message-ID: <CAL9jLaY2aok9jXAkrxXBj0qyNGHyrdS-6i1ADqsu_+w3T7pNbA@mail.gmail.com>

On Mon, Sep 19, 2011 at 5:17 PM, Erik Bais <ebais at a2b-internet.com> wrote:
> Hi Chris,
>
> I've send an email to the person I know within STC responsible for
> international transit.
>
> Let's hope he can assist.

excellent! :)

>> -----Original Message-----
>> From: Christopher Morrow [mailto:morrowc.lists at gmail.com]
>> Sent: Monday, September 19, 2011 10:58 PM
>> To: Schiller, Heather A; info at irnetco.net
>> Cc: Jonas Frey (Probe Networks); nanog at nanog.org
>> Subject: Re: Saudi Telecom sending route with invalid attributes
>> 212.118.142.0/24 - Redux
>>
>> suliman.alzain at saudi.net.sa - bounces :( Ripe folks (if listening)
>> perhaps you could ping the other live POC's there and request an
>> update? :)
>>
>> On Mon, Sep 19, 2011 at 4:54 PM, Christopher Morrow
>> <morrowc.lists at gmail.com> wrote:
>> > In the off chance that no one already attempted an email to the folks
>> > nominally in charge there:
>> >
>> > person: ? ? ? ? Hejji almazroua
>> > address: ? ? ? ?SaudiNet
>> > address: ? ? ? ?P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
>> > phone: ? ? ? ? ?+9661 218 0300
>> > fax-no: ? ? ? ? +9661 218 0311
>> > e-mail: ? ? ? ? info at irnetco.net
>> > nic-hdl: ? ? ? ?Ha125-RIPE
>> > mnt-by: ? ? ? ? irnetco-ripe-mnt
>> > source: ? ? ? ? RIPE # Filtered
>> >
>> > person: ? ? ? Suliman I. Al-Zain
>> > address: ? ? ?Saudi Telecom Co. (SaudiNet)
>> > address: ? ? ?P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
>> > phone: ? ? ? ?+9661 218 2034
>> > fax-no: ? ? ? +9661 218 0311
>> > e-mail: ? ? ? suliman.alzain at saudi.net.sa
>> > nic-hdl: ? ? ?SA702-RIPE
>> > source: ? ? ? RIPE # Filtered
>> >
>> >
>> > Do the Saudi-Telecom folks have a method to suppress the /24
>> > (212.118.142.0/24) which is also covered by: 212.118.128.0/19
>> >
>> > it'd really help lots of other Internet folk if you'd suppress this
>> /24 ...
>> >
>> > -chris
>> >
>> > On Mon, Sep 19, 2011 at 3:26 PM, Schiller, Heather A
>> > <heather.schiller at verizon.com> wrote:
>> >>
>> >> Seeing it again here too.. Has anyone contacted them?
>> >>
>> >> ..and for folks who are choosing to blackhole the prefix in order to
>> supress the route, please remember not to export it!
>> >>
>> >> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet
>> 2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
>> >> AS8866 ?BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08
>> 18:35:14 UTC 2011-09-19 19:15:42 UTC
>> >> AS10026 PACNET Pacnet Global Ltd ? ? ? ?2011-09-11 02:41:40 UTC
>> 2011-09-19 16:00:00 UTC
>> >> AS8767 ?MNET-AS M-net AS ? ? ? ?2011-09-14 12:13:01 UTC 2011-09-14
>> 12:14:00 UTC
>> >> AS3561 ?SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18
>> UTC
>> >> AS3549 ?GBLX Global Crossing Ltd. ? ? ? 2011-09-09 16:13:15 UTC
>> 2011-09-09 17:05:38 UTC
>> >> AS1239 ?SPRINTLINK - Sprint ? ? 2011-09-09 03:18:28 UTC 2011-09-09
>> 15:56:41 UTC
>> >> AS65000 -Private Use AS- ? ? ? ?2011-09-08 18:34:28 UTC 2011-09-08
>> 18:34:29 UTC
>> >>
>> >> ?--heather
>> >>
>> >> -----Original Message-----
>> >> From: Ryan Gray [mailto:ryan at longlines.com]
>> >> Sent: Monday, September 19, 2011 3:09 PM
>> >> To: Schiller, Heather A
>> >> Cc: Aftab Siddiqui; Richard Barnes; Jonas Frey (Probe Networks);
>> nanog at nanog.org
>> >> Subject: Re: Saudi Telecom sending route with invalid attributes
>> 212.118.142.0/24
>> >>
>> >> Actually just started seeing these problems again today. ?Is anyone
>> else seeing this today from something other than 212.118.142.0/24?
>> ?Looks like it started about two hours ago.
>> >>
>> >>
>> >> Regards,
>> >> Ryan Gray
>> >> Long Lines
>> >> www.longlines.com
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Sep 12, 2011, at 8:18 PM, Schiller, Heather A wrote:
>> >>
>> >>>
>> >>> Could be this..?
>> >>>
>> >>>
>> http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/confi
>> >>> guration-statement/independent-domain-edit-routing-options.html
>> >>>
>> >>> "unrecognized transitive attributes" depend on whatever code
>> version you are running... What's more important is how the
>> unrecoginized attribute is handled. ?Ideally you accept and pass the
>> route and log it. ?The problem is with devices that aren't so
>> graceful.. dropping sessions and wreaking havoc:
>> >>>
>> >>> http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml
>> >>>
>> >>> --Heather
>> >>>
>> >>> -----Original Message-----
>> >>> From: Aftab Siddiqui [mailto:aftab.siddiqui at gmail.com]
>> >>> Sent: Saturday, September 10, 2011 6:49 PM
>> >>> To: Richard Barnes
>> >>> Cc: Jonas Frey (Probe Networks); nanog at nanog.org
>> >>> Subject: Re: Saudi Telecom sending route with invalid attributes
>> >>> 212.118.142.0/24
>> >>>
>> >>> with in the span of couple of hours this prefix was originated from
>> 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original
>> custodians).
>> >>>
>> >>> As per the STC it was orginated by one of their customer having
>> Juniper router. but I still don't understand why/how they are adv this
>> prefix with unrecog transitive attributes.
>> >>>
>> >>> Can any one suggest.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Aftab A. Siddiqui
>> >>>
>> >>>
>> >>> On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes
>> <richard.barnes at gmail.com>wrote:
>> >>>
>> >>>> Looks like the RIS collectors are seeing it originating mostly
>> from
>> >>>> STC and KACST ASNs:
>> >>>> <http://stat.ripe.net/212.118.142.0/24>
>> >>>>
>> >>>> Some of the "show ip bgp" reports on that screen are also showing
>> >>>> AS8866 "BTC-AS Bulgarian Telecommunication Company". ?Not sure
>> what's
>> >>>> up with that.
>> >>>>
>> >>>> --Richard
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow
>> >>>> <morrowc.lists at gmail.com> wrote:
>> >>>>> On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren
>> <pixitha.kyle at gmail.com>
>> >>>> wrote:
>> >>>>>> Is this announcement still showing up this way (no easy way to
>> >>>>>> check myself).
>> >>>>>
>> >>>>> ripe ris?
>> >>>>>
>> >>>>>> -Kyle
>> >>>>>>
>> >>>>>> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes
>> >>>>>> <chaynes at centracomm.net>
>> >>>> wrote:
>> >>>>>>
>> >>>>>>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
>> >>>>>>> jf at probe-networks.de> wrote:
>> >>>>>>>
>> >>>>>>>> Hello,
>> >>>>>>>>
>> >>>>>>>> anyone else getting a route for 212.118.142.0/24 with invalid
>> >>>>>>>> attributes? Seems this is (again) causing problems with some
>> >>>>>>>> (older) routers/software.
>> >>>>>>>>
>> >>>>>>>> ? ? ? ? ? ? ?Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
>> >>>>>>>> 1 6-Resolve tree 2
>> >>>>>>>> ? ? ? ? ? ? ? AS path: 6453 39386 25019 I Unrecognized
>> Attributes:
>> >>>> 39
>> >>>>>>>> bytes
>> >>>>>>>> ? ? ? ? ? ? ? AS path: ?Attr flags e0 code 80: 00 00 fd 88 40
>> >>>>>>>> 01 01
>> >>>> 02
>> >>>>>>>> 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01
>> 40
>> >>>>>>>> 05
>> >>>> 04
>> >>>>>>>> 00 00 00 64
>> >>>>>>>> ? ? ? ? ? ? ? Accepted Multipath
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> -Jonas
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> Yup! We're seeing the same thing too, and we're filtering it
>> out.
>> >>>>>>> Originating AS is 25019
>> >>>>>>>
>> >>>>>>> -Clay
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1410 / Virus Database: 1520/3906 - Release Date: 09/19/11
>
>


From warren at kumari.net  Mon Sep 19 18:28:41 2011
From: warren at kumari.net (Warren Kumari)
Date: Mon, 19 Sep 2011 19:28:41 -0400
Subject: How to begin making my own ISP?
In-Reply-To: <61195.1316199183@turing-police.cc.vt.edu>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
 <20110916184218.GA17456@vacation.karoshi.com>
 <61195.1316199183@turing-police.cc.vt.edu>
Message-ID: <99E8A147-F666-49FE-91E7-A95DDFE760FB@kumari.net>


On Sep 16, 2011, at 2:53 PM, Valdis.Kletnieks at vt.edu wrote:

> On Fri, 16 Sep 2011 18:42:18 -0000, bmanning at vacation.karoshi.com said:
>> Configure Quagga w/ the obtained ASN and announce the IP prefix(es).
> 
>> TaDa ...  You are an ISP!
> 
> Now all you need is a business plan that pays for the rack space. ;)

http://www.monkeybagel.com/consult.html

I'd also recommend reading the "Systems Hardware Integration Tasks" linked to from: http://www.monkeybagel.com/process.html

W

From lstewart at superb.net  Mon Sep 19 18:36:57 2011
From: lstewart at superb.net (Landon Stewart)
Date: Mon, 19 Sep 2011 16:36:57 -0700
Subject: Is yahoo seriously blocking emails with variants of the words
 "occupywallstreet"?
Message-ID: <CABgOHgt_yOezkzWk-Tz1vXneSMwMBQyHqwa1ULibfx7yR7VYMQ@mail.gmail.com>

Hi Guys,

Is yahoo seriously blocking emails with variants of the words
"occupywallstreet"?

-- 
Landon Stewart <LStewart at SUPERB.NET>
SuperbHosting.Net by Superb Internet Corp.
Toll Free (US/Canada): 888-354-6128 x 4199
Direct: 206-438-5879
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net

From ken at stox.org  Mon Sep 19 18:40:30 2011
From: ken at stox.org (Ken Stox)
Date: Mon, 19 Sep 2011 18:40:30 -0500
Subject: Is yahoo seriously blocking emails with variants of the words
 "occupywallstreet"?
In-Reply-To: <CABgOHgt_yOezkzWk-Tz1vXneSMwMBQyHqwa1ULibfx7yR7VYMQ@mail.gmail.com>
References: <CABgOHgt_yOezkzWk-Tz1vXneSMwMBQyHqwa1ULibfx7yR7VYMQ@mail.gmail.com>
Message-ID: <1316475631.23919.1.camel@daedelus.stox.org>

A quick test shows that they are not blocking, at least for me.

-Ken Stox
 ken at stox.org



From jlewis at lewis.org  Mon Sep 19 20:02:07 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 19 Sep 2011 21:02:07 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
Message-ID: <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>

On Sun, 18 Sep 2011, Frank Bulk wrote:

> I should have made myself more clear -- the policy amendment would make
> clear that multihoming requires only one facilities-based connection and
> that the other connections could be fulfilled via tunnels.  This may be
> heresy for some.

That's not multihoming.

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


From ops.lists at gmail.com  Mon Sep 19 20:34:22 2011
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Tue, 20 Sep 2011 07:04:22 +0530
Subject: Internet mauled by bears
In-Reply-To: <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
Message-ID: <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>

On Tue, Sep 20, 2011 at 12:20 AM, John van Oppen
<jvanoppen at spectrumnet.us> wrote:
> We had a cow break down a door to a remote microwave site once... ? ?now we are the proud owners of a generator backed electric fence at that site... ? ?Rural physical plant issues are almost always entertaining. ?:)

Your crews turning up there the next time a cow tries its luck are
guaranteed a steak dinner then.

-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From richard.barnes at gmail.com  Mon Sep 19 20:49:03 2011
From: richard.barnes at gmail.com (Richard Barnes)
Date: Mon, 19 Sep 2011 21:49:03 -0400
Subject: Internet mauled by bears
In-Reply-To: <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
Message-ID: <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>

And if they turn up the voltage on the fence high enough, dinner could be
cooked by the time the crew gets there!

On Sep 19, 2011 9:34 PM, "Suresh Ramasubramanian" <ops.lists at gmail.com>
wrote:

On Tue, Sep 20, 2011 at 12:20 AM, John van Oppen
<jvanoppen at spectrumnet.us> wrote:
> We had a cow br...
Your crews turning up there the next time a cow tries its luck are
guaranteed a steak dinner then.


-- 
Suresh Ramasubramanian (ops.lists at gmail.com)

From gary.buhrmaster at gmail.com  Mon Sep 19 21:02:33 2011
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Tue, 20 Sep 2011 02:02:33 +0000
Subject: Internet mauled by bears
In-Reply-To: <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
Message-ID: <CAMfXtQzvboLQyxJSWKcVG8Y3H=Fsncx-UdgqScn2tt+vEVW1Fw@mail.gmail.com>

On Tue, Sep 20, 2011 at 01:49, Richard Barnes <richard.barnes at gmail.com> wrote:
> And if they turn up the voltage on the fence high enough, dinner could be
> cooked by the time the crew gets there!

Not quite.  The point of the electric fence is to discourage
moooving through it, but you do not want to kill (or
seriously injure) your livestock.  That, however does not
always work as expected.  Cows are really dumb creatures.
And while an electric fence may discourage them, I have
seen the extra special ones just lounge against the electric
fence for a long time (I presume until the brain notices that
something does not feel right, so perhaps they should
consider, but only consider, being somewhere else).
On a good day the cow goes (or does not go) where you
want it.  On a bad day you repair the electric fence.

Gary


From cboyd at gizmopartners.com  Mon Sep 19 21:05:05 2011
From: cboyd at gizmopartners.com (Chris Boyd)
Date: Mon, 19 Sep 2011 21:05:05 -0500
Subject: Internet mauled by bears
In-Reply-To: <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
Message-ID: <0F38D158-E643-45C3-91D6-0A505BFFAAE1@gizmopartners.com>


On Sep 19, 2011, at 8:49 PM, Richard Barnes wrote:

> And if they turn up the voltage on the fence high enough, dinner could be
> cooked by the time the crew gets there!

Nah, they are high frequency and high voltage, but very low current.  It's uncomfortable and may cause local burning similar to a TENS unit turned up too high.

Here's another "critter ate the Internet" blog post:
http://blog.lafayetteprofiber.com/2008/06/nutria-ratsand-fiber.html

--Chris
(who once fell off the top of a dual level loading chute when he didn't see the hot wire that someone strung 3 feet above the chute.)

From matthew at matthew.at  Mon Sep 19 22:05:23 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 19 Sep 2011 20:05:23 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
Message-ID: <4E7802F3.2020806@matthew.at>

On 9/19/2011 6:02 PM, Jon Lewis wrote:
> On Sun, 18 Sep 2011, Frank Bulk wrote:
>
>> I should have made myself more clear -- the policy amendment would make
>> clear that multihoming requires only one facilities-based connection and
>> that the other connections could be fulfilled via tunnels.  This may be
>> heresy for some.
>
> That's not multihoming.

Really? Lets try these and see how you do:

1) One IP connection via a T-1. Second IP connection via GRE tunnel 
carried on first.

2) One IP connection via a T-1 that doesn't have transit, only peering 
with providers B and C. IP connections via two GRE tunnels to providers 
B and C.

3) One IP connection via MPLS over T-1. Second IP connection via 
different MPLS virtual circuit over the same T-1.

4) One IP connection via Frame Relay over T-1. Second IP connection via 
Frame Relay over the same T-1.

5) One IP connection via a T-1. Second IP connection via a different T-1 
that is multiplexed on the same DS3.

6) One IP connection via a T-1. Second IP connection via a different T-1 
that is on separate physical pairs, but in the same cable bundle.

Matthew Kaufman


From matthew at matthew.at  Mon Sep 19 22:07:47 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 19 Sep 2011 20:07:47 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
Message-ID: <4E780383.2070801@matthew.at>

On 9/19/2011 6:02 PM, Jon Lewis wrote:
> On Sun, 18 Sep 2011, Frank Bulk wrote:
>
>> I should have made myself more clear -- the policy amendment would make
>> clear that multihoming requires only one facilities-based connection and
>> that the other connections could be fulfilled via tunnels.  This may be
>> heresy for some.
>
> That's not multihoming.
>

Note that for the purpose of needing an AS number, it most certainly 
is... as the result is distinct routing policy from either the 
facilities-based provider or the source of the tunnel(s).

Matthew Kaufman



From randy at psg.com  Mon Sep 19 22:32:04 2011
From: randy at psg.com (Randy Bush)
Date: Tue, 20 Sep 2011 05:32:04 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <4E7802F3.2020806@matthew.at>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
Message-ID: <m21uvbyjm3.wl%randy@psg.com>

> 1) One IP connection via a T-1. Second IP connection via GRE tunnel 
> carried on first.
> 
> 2) One IP connection via a T-1 that doesn't have transit, only peering 
> with providers B and C. IP connections via two GRE tunnels to providers 
> B and C.
> 
> 3) One IP connection via MPLS over T-1. Second IP connection via 
> different MPLS virtual circuit over the same T-1.
> 
> 4) One IP connection via Frame Relay over T-1. Second IP connection via 
> Frame Relay over the same T-1.
> 
> 5) One IP connection via a T-1. Second IP connection via a different T-1 
> that is multiplexed on the same DS3.
> 
> 6) One IP connection via a T-1. Second IP connection via a different T-1 
> that is on separate physical pairs, but in the same cable bundle.

you left out one connection via a chevy full of hollerith cards and the
second a canoe full of 7 track tape in waterproof containers.

we now return you to the real internet, where we invent new usefull
things occasionally but try to refrain from redefining well-understood
terms on a daily basis (unless we are in marketing).

randy


From matthew at matthew.at  Mon Sep 19 22:32:25 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 19 Sep 2011 20:32:25 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <m21uvbyjm3.wl%randy@psg.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
Message-ID: <4E780949.3080507@matthew.at>

On 9/19/2011 8:32 PM, Randy Bush wrote:
> you left out one connection via a chevy full of hollerith cards and 
> the second a canoe full of 7 track tape in waterproof containers.

They certainly have different loss characteristics, even if you don't 
get unique routing policy out of it.

Matthew Kaufman


From matthew at matthew.at  Mon Sep 19 22:37:23 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 19 Sep 2011 20:37:23 -0700
Subject: How to begin making my own ISP?
In-Reply-To: <C262B52114110B4586FAF49F074F05800D9691BD70@mailserver2007.nyigc.globe>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
 <C262B52114110B4586FAF49F074F05800D9691BD70@mailserver2007.nyigc.globe>
Message-ID: <4E780A73.3010306@matthew.at>

On 9/16/2011 11:14 AM, Eric Wieling wrote:
> I think the question was far too vague.  The first thing you need to start an ISP is LOTS OF MONEY.
>

That's if you want to make a little money running an ISP. If you want to 
make lots of money running an ISP, it takes *even more* money.

Matthew Kaufman


From matthew at matthew.at  Mon Sep 19 22:40:06 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 19 Sep 2011 20:40:06 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
References: <4E73A75D.50002@knownelement.com>
 <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
Message-ID: <4E780B16.9070600@matthew.at>

On 9/16/2011 12:58 PM, Leigh Porter wrote:
>
>
> I wonder what would happen if a new ARIN member requested an IPv4 block of say a /16 for a new business? Or even a smaller block. I don't know what the current ARIN rules are but RIPE will currently give out six months worth of space. Now, in six months, I don't expect there to be any left anyway, so what will likely be all the v4 you ever get.
>
> Very soon it'll be nigh on impossible for new entrants to the ISP business to get their own v4 space.
>

Isn't that the point?

Matthew Kaufman


From matthew at matthew.at  Mon Sep 19 23:02:49 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 19 Sep 2011 21:02:49 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
Message-ID: <4E781069.5090108@matthew.at>

On 9/18/2011 7:27 PM, Antonio Querubin wrote:
> On Sun, 18 Sep 2011, Frank Bulk wrote:
>
>> I understand that tunneling meets the letter of the ARIN policy, but 
>> I'll make the bold assumption that wasn't the spirit of the policy 
>> when it was written.  Maybe the policy needs to be amended to clarify 
>> that.
>
> I think this is a bad idea and I suspect would slow IPv6 deployment. 
> Potential latency issues aside, is there a technical (not political) 
> reason for doing so?

How does making it easier to use up the last of the free pool slow IPv6 
deployment?

Matthew Kaufman


From jra at baylink.com  Mon Sep 19 23:07:06 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 20 Sep 2011 00:07:06 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m21uvbyjm3.wl%randy@psg.com>
Message-ID: <21961749.2409.1316491626619.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Randy Bush" <randy at psg.com>

> you left out one connection via a chevy full of hollerith cards and
> the second a canoe full of 7 track tape in waterproof containers.

That's "a station wagon full of magtape".  Henry would be disappointed.

Cheers,
-- jra
* See also http://www.merit.edu/mail.archives/nanog/msg15422.html
-- 
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      http://photo.imageinc.us             +1 727 647 1274


From charles at knownelement.com  Mon Sep 19 23:11:17 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Mon, 19 Sep 2011 23:11:17 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <4E780B16.9070600@matthew.at>
References: <4E73A75D.50002@knownelement.com>
 <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <4E780B16.9070600@matthew.at>
Message-ID: <4E781265.9080603@knownelement.com>

On 09/19/2011 10:40 PM, Matthew Kaufman wrote:
> On 9/16/2011 12:58 PM, Leigh Porter wrote:
>>
>>
>> I wonder what would happen if a new ARIN member requested an IPv4
>> block of say a /16 for a new business? Or even a smaller block. I
>> don't know what the current ARIN rules are but RIPE will currently
>> give out six months worth of space. Now, in six months, I don't
>> expect there to be any left anyway, so what will likely be all the v4
>> you ever get.
>>
>> Very soon it'll be nigh on impossible for new entrants to the ISP
>> business to get their own v4 space.
>>
>
> Isn't that the point?

That's what I'm thinking. :)

I don't plan on requesting any v4 space from ARIN. Just using provider
space for the small v4 traffic needs.

-- 
Charles N Wyble charles at knownelement.com @charlesnw on twitter

http://blog.knownelement.com

Building alternative,global scale,secure, cost effective bit moving platform
for tomorrows alternate default free zone.



From Valdis.Kletnieks at vt.edu  Mon Sep 19 23:14:59 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 20 Sep 2011 00:14:59 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: Your message of "Tue, 20 Sep 2011 05:32:04 +0200."
 <m21uvbyjm3.wl%randy@psg.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
Message-ID: <9606.1316492099@turing-police.cc.vt.edu>

On Tue, 20 Sep 2011 05:32:04 +0200, Randy Bush said:

> you left out one connection via a chevy full of hollerith cards and the
> second a canoe full of 7 track tape in waterproof containers.

Does anybody actually *have* a functional 7 track drive?  I remember seeing a
story on PBS (may have been a Nova episode) where they discussed the fact that
NASA had literally thousands of 7 track tapes of telemetry data and no way to
read them because their last 7 track drive had died, and IBM had no 7 track
read/write heads left either...

(I admit we still have a rack of 9-track tapes in ez-loader seals in our tape
library, though we got rid of our last IBM 3420 about a decade ago. I think
most of them are tapes we've lost track of ownership info, and don't dare
dispose of in case the owner turns up.. ;)

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

From randy at psg.com  Mon Sep 19 23:20:24 2011
From: randy at psg.com (Randy Bush)
Date: Tue, 20 Sep 2011 06:20:24 +0200
Subject: old media (was: wannabe isp)
In-Reply-To: <9606.1316492099@turing-police.cc.vt.edu>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu>
Message-ID: <m2vcsnx2t3.wl%randy@psg.com>

> Does anybody actually *have* a functional 7 track drive?

if you really need one, i know what trail i would start to follow.
there are folk keeping old stuff alive and pulling arcane things
off old media (like the besm-6 system).

randy


From joelja at bogus.com  Mon Sep 19 23:32:41 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Mon, 19 Sep 2011 21:32:41 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <9606.1316492099@turing-police.cc.vt.edu>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu>
Message-ID: <4E781769.2050909@bogus.com>

given that as 729 maxes out at 800cpi there are probably slightly kinky
ways to attack the problem, e.g. someone doing it with disk packs.

http://chrisfenton.com/cray-1-digital-archeology/

there's still plenty of equipment that can wrap 1/2" tape around a spindle.

On 9/19/11 21:14 , Valdis.Kletnieks at vt.edu wrote:
> On Tue, 20 Sep 2011 05:32:04 +0200, Randy Bush said:
> 
>> you left out one connection via a chevy full of hollerith cards and the
>> second a canoe full of 7 track tape in waterproof containers.
> 
> Does anybody actually *have* a functional 7 track drive?  I remember seeing a
> story on PBS (may have been a Nova episode) where they discussed the fact that
> NASA had literally thousands of 7 track tapes of telemetry data and no way to
> read them because their last 7 track drive had died, and IBM had no 7 track
> read/write heads left either...
> 
> (I admit we still have a rack of 9-track tapes in ez-loader seals in our tape
> library, though we got rid of our last IBM 3420 about a decade ago. I think
> most of them are tapes we've lost track of ownership info, and don't dare
> dispose of in case the owner turns up.. ;)
> 



From r.engehausen at gmail.com  Mon Sep 19 23:33:58 2011
From: r.engehausen at gmail.com (Roy)
Date: Mon, 19 Sep 2011 21:33:58 -0700
Subject: old media
In-Reply-To: <m2vcsnx2t3.wl%randy@psg.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu> <m2vcsnx2t3.wl%randy@psg.com>
Message-ID: <4E7817B6.30208@gmail.com>

On 9/19/2011 9:20 PM, Randy Bush wrote:
>> Does anybody actually *have* a functional 7 track drive?
> if you really need one, i know what trail i would start to follow.
> there are folk keeping old stuff alive and pulling arcane things
> off old media (like the besm-6 system).
>
> randy
>
>


I haven't heard about te BESM-6 since the 1970s when I was studying 
Warsaw Pact Computers!

The BESM-6 was delivered from the factory without any software.


From aftab.siddiqui at gmail.com  Mon Sep 19 23:56:03 2011
From: aftab.siddiqui at gmail.com (Aftab Siddiqui)
Date: Tue, 20 Sep 2011 09:56:03 +0500
Subject: Saudi Telecom sending route with invalid attributes
 212.118.142.0/24 - Redux
In-Reply-To: <CAL9jLaY2aok9jXAkrxXBj0qyNGHyrdS-6i1ADqsu_+w3T7pNbA@mail.gmail.com>
References: <1315523506.3147.211.camel@wks02>
 <CAGWn6LTZa5Z3siNnWj3L4jP-SExwBP_Y+sK2fWvkL_Gvy6zAvQ@mail.gmail.com>
 <CADehQgSEdakCKAbqVMepVySQc-Vs-E02r_r0N-SPKBtyHLV7SQ@mail.gmail.com>
 <CAL9jLaYZqPW1t4LzocnwH32V83LHAFTpbHFuxXhY4TPDTmqECQ@mail.gmail.com>
 <CACB24Mu9WyHNo_HyGJFo2fXVfRXVKBzo+5Lcjm37YftwOXnMrw@mail.gmail.com>
 <CAK5YLgcenPt4iUrHCBH2g0d28+fG7NRKaz+7c6xW3kuRsq04QQ@mail.gmail.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F19D22DE@FHDP1LUMXC7V43.us.one.verizon.com>
 <C353DE35-7505-48B1-AFF3-C20DB30A966B@longlines.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F661B95C@FHDP1LUMXC7V43.us.one.verizon.com>
 <CAL9jLaZr3rfPY4A4vb8cdy9N2hR_8-bB0pzp6o5XY2A1hzsm1Q@mail.gmail.com>
 <CAL9jLaZCEcJNZYvy60QGCcPeF3nFMbq-zFiwy34w53ag8FDibQ@mail.gmail.com>
 <010701cc7711$82dd6ac0$88984040$@com>
 <CAL9jLaY2aok9jXAkrxXBj0qyNGHyrdS-6i1ADqsu_+w3T7pNbA@mail.gmail.com>
Message-ID: <CAK5YLgfYeExO0Q0xqQWtjTyoY6vpxhZWahXy2o+5==894YyV5A@mail.gmail.com>

I got an email response on 11th Sep when made a complaint for the same, they
said, it is one of our customer's prefix. THATS IT.

They didn't share any reason for rogue attributes, for them it is more
likely a Juniper box their client is using.

Very helpfull info though :)

Regards,

Aftab A. Siddiqui


On Tue, Sep 20, 2011 at 2:24 AM, Christopher Morrow <morrowc.lists at gmail.com
> wrote:

> On Mon, Sep 19, 2011 at 5:17 PM, Erik Bais <ebais at a2b-internet.com> wrote:
> > Hi Chris,
> >
> > I've send an email to the person I know within STC responsible for
> > international transit.
> >
> > Let's hope he can assist.
>
> excellent! :)
>
> >> -----Original Message-----
> >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com]
> >> Sent: Monday, September 19, 2011 10:58 PM
> >> To: Schiller, Heather A; info at irnetco.net
> >> Cc: Jonas Frey (Probe Networks); nanog at nanog.org
> >> Subject: Re: Saudi Telecom sending route with invalid attributes
> >> 212.118.142.0/24 - Redux
> >>
> >> suliman.alzain at saudi.net.sa - bounces :( Ripe folks (if listening)
> >> perhaps you could ping the other live POC's there and request an
> >> update? :)
> >>
> >> On Mon, Sep 19, 2011 at 4:54 PM, Christopher Morrow
> >> <morrowc.lists at gmail.com> wrote:
> >> > In the off chance that no one already attempted an email to the folks
> >> > nominally in charge there:
> >> >
> >> > person:         Hejji almazroua
> >> > address:        SaudiNet
> >> > address:        P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> >> > phone:          +9661 218 0300
> >> > fax-no:         +9661 218 0311
> >> > e-mail:         info at irnetco.net
> >> > nic-hdl:        Ha125-RIPE
> >> > mnt-by:         irnetco-ripe-mnt
> >> > source:         RIPE # Filtered
> >> >
> >> > person:       Suliman I. Al-Zain
> >> > address:      Saudi Telecom Co. (SaudiNet)
> >> > address:      P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
> >> > phone:        +9661 218 2034
> >> > fax-no:       +9661 218 0311
> >> > e-mail:       suliman.alzain at saudi.net.sa
> >> > nic-hdl:      SA702-RIPE
> >> > source:       RIPE # Filtered
> >> >
> >> >
> >> > Do the Saudi-Telecom folks have a method to suppress the /24
> >> > (212.118.142.0/24) which is also covered by: 212.118.128.0/19
> >> >
> >> > it'd really help lots of other Internet folk if you'd suppress this
> >> /24 ...
> >> >
> >> > -chris
> >> >
> >> > On Mon, Sep 19, 2011 at 3:26 PM, Schiller, Heather A
> >> > <heather.schiller at verizon.com> wrote:
> >> >>
> >> >> Seeing it again here too.. Has anyone contacted them?
> >> >>
> >> >> ..and for folks who are choosing to blackhole the prefix in order to
> >> supress the route, please remember not to export it!
> >> >>
> >> >> AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet
> >> 2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
> >> >> AS8866  BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08
> >> 18:35:14 UTC 2011-09-19 19:15:42 UTC
> >> >> AS10026 PACNET Pacnet Global Ltd        2011-09-11 02:41:40 UTC
> >> 2011-09-19 16:00:00 UTC
> >> >> AS8767  MNET-AS M-net AS        2011-09-14 12:13:01 UTC 2011-09-14
> >> 12:14:00 UTC
> >> >> AS3561  SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18
> >> UTC
> >> >> AS3549  GBLX Global Crossing Ltd.       2011-09-09 16:13:15 UTC
> >> 2011-09-09 17:05:38 UTC
> >> >> AS1239  SPRINTLINK - Sprint     2011-09-09 03:18:28 UTC 2011-09-09
> >> 15:56:41 UTC
> >> >> AS65000 -Private Use AS-        2011-09-08 18:34:28 UTC 2011-09-08
> >> 18:34:29 UTC
> >> >>
> >> >>  --heather
> >> >>
> >> >> -----Original Message-----
> >> >> From: Ryan Gray [mailto:ryan at longlines.com]
> >> >> Sent: Monday, September 19, 2011 3:09 PM
> >> >> To: Schiller, Heather A
> >> >> Cc: Aftab Siddiqui; Richard Barnes; Jonas Frey (Probe Networks);
> >> nanog at nanog.org
> >> >> Subject: Re: Saudi Telecom sending route with invalid attributes
> >> 212.118.142.0/24
> >> >>
> >> >> Actually just started seeing these problems again today.  Is anyone
> >> else seeing this today from something other than 212.118.142.0/24?
> >>  Looks like it started about two hours ago.
> >> >>
> >> >>
> >> >> Regards,
> >> >> Ryan Gray
> >> >> Long Lines
> >> >> www.longlines.com
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sep 12, 2011, at 8:18 PM, Schiller, Heather A wrote:
> >> >>
> >> >>>
> >> >>> Could be this..?
> >> >>>
> >> >>>
> >> http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/confi
> >> >>> guration-statement/independent-domain-edit-routing-options.html
> >> >>>
> >> >>> "unrecognized transitive attributes" depend on whatever code
> >> version you are running... What's more important is how the
> >> unrecoginized attribute is handled.  Ideally you accept and pass the
> >> route and log it.  The problem is with devices that aren't so
> >> graceful.. dropping sessions and wreaking havoc:
> >> >>>
> >> >>> http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml
> >> >>>
> >> >>> --Heather
> >> >>>
> >> >>> -----Original Message-----
> >> >>> From: Aftab Siddiqui [mailto:aftab.siddiqui at gmail.com]
> >> >>> Sent: Saturday, September 10, 2011 6:49 PM
> >> >>> To: Richard Barnes
> >> >>> Cc: Jonas Frey (Probe Networks); nanog at nanog.org
> >> >>> Subject: Re: Saudi Telecom sending route with invalid attributes
> >> >>> 212.118.142.0/24
> >> >>>
> >> >>> with in the span of couple of hours this prefix was originated from
> >> 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original
> >> custodians).
> >> >>>
> >> >>> As per the STC it was orginated by one of their customer having
> >> Juniper router. but I still don't understand why/how they are adv this
> >> prefix with unrecog transitive attributes.
> >> >>>
> >> >>> Can any one suggest.
> >> >>>
> >> >>> Regards,
> >> >>>
> >> >>> Aftab A. Siddiqui
> >> >>>
> >> >>>
> >> >>> On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes
> >> <richard.barnes at gmail.com>wrote:
> >> >>>
> >> >>>> Looks like the RIS collectors are seeing it originating mostly
> >> from
> >> >>>> STC and KACST ASNs:
> >> >>>> <http://stat.ripe.net/212.118.142.0/24>
> >> >>>>
> >> >>>> Some of the "show ip bgp" reports on that screen are also showing
> >> >>>> AS8866 "BTC-AS Bulgarian Telecommunication Company".  Not sure
> >> what's
> >> >>>> up with that.
> >> >>>>
> >> >>>> --Richard
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow
> >> >>>> <morrowc.lists at gmail.com> wrote:
> >> >>>>> On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren
> >> <pixitha.kyle at gmail.com>
> >> >>>> wrote:
> >> >>>>>> Is this announcement still showing up this way (no easy way to
> >> >>>>>> check myself).
> >> >>>>>
> >> >>>>> ripe ris?
> >> >>>>>
> >> >>>>>> -Kyle
> >> >>>>>>
> >> >>>>>> On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes
> >> >>>>>> <chaynes at centracomm.net>
> >> >>>> wrote:
> >> >>>>>>
> >> >>>>>>> On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
> >> >>>>>>> jf at probe-networks.de> wrote:
> >> >>>>>>>
> >> >>>>>>>> Hello,
> >> >>>>>>>>
> >> >>>>>>>> anyone else getting a route for 212.118.142.0/24 with invalid
> >> >>>>>>>> attributes? Seems this is (again) causing problems with some
> >> >>>>>>>> (older) routers/software.
> >> >>>>>>>>
> >> >>>>>>>>              Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree
> >> >>>>>>>> 1 6-Resolve tree 2
> >> >>>>>>>>               AS path: 6453 39386 25019 I Unrecognized
> >> Attributes:
> >> >>>> 39
> >> >>>>>>>> bytes
> >> >>>>>>>>               AS path:  Attr flags e0 code 80: 00 00 fd 88 40
> >> >>>>>>>> 01 01
> >> >>>> 02
> >> >>>>>>>> 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01
> >> 40
> >> >>>>>>>> 05
> >> >>>> 04
> >> >>>>>>>> 00 00 00 64
> >> >>>>>>>>               Accepted Multipath
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> -Jonas
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> Yup! We're seeing the same thing too, and we're filtering it
> >> out.
> >> >>>>>>> Originating AS is 25019
> >> >>>>>>>
> >> >>>>>>> -Clay
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >> -----
> >> No virus found in this message.
> >> Checked by AVG - www.avg.com
> >> Version: 10.0.1410 / Virus Database: 1520/3906 - Release Date: 09/19/11
> >
> >
>
>

From barton at barton.net  Tue Sep 20 00:22:43 2011
From: barton at barton.net (Barton F Bruce)
Date: Tue, 20 Sep 2011 01:22:43 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <9606.1316492099@turing-police.cc.vt.edu>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu>
Message-ID: <4E782323.4090906@barton.net>

*This message was transferred with a trial version of CommuniGate(r) Pro*


 >Does anybody actually *have* a functional 7 track drive?

The folks restoring at least one IBM 1401 probably have several.

    http://ibm-1401.info/

Other than replacing a lot of older tab shop hardware, a primary
function for may 1401s was to do card reading and printing for jobs
submitted on 7 track tape to 7094s.



From henry at AegisInfoSys.com  Tue Sep 20 01:00:28 2011
From: henry at AegisInfoSys.com (Henry Yen)
Date: Tue, 20 Sep 2011 02:00:28 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <4E782323.4090906@barton.net>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu> <4E782323.4090906@barton.net>
Message-ID: <20110920060028.GX6006@nntp.AegisInfoSys.com>

On Tue, Sep 20, 2011 at 01:22:43AM -0400, Barton F Bruce wrote:
> >Does anybody actually *have* a functional 7 track drive?
> 
> The folks restoring at least one IBM 1401 probably have several.
> 
>    http://ibm-1401.info/

A few (dozen) years ago, I was treated to a interesting demonstration where
a coworker poured an oily fluid containing tiny metallic flakes on a patch
of tape.  The "bits" on the tape could be clearly seen by the naked eye,
and could be decoded (ever so slowly!) using a magnifying glass.

-- 
Henry Yen                                       Aegis Information Systems, Inc.
Senior Systems Programmer                       Hicksville, New York


From joelja at bogus.com  Tue Sep 20 02:37:55 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Tue, 20 Sep 2011 00:37:55 -0700
Subject: Internet mauled by bears
In-Reply-To: <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
Message-ID: <4E7842D3.3090305@bogus.com>

On 9/19/11 18:49 , Richard Barnes wrote:
> And if they turn up the voltage on the fence high enough, dinner could be
> cooked by the time the crew gets there!

montana experience says:

cows have rather thick skin, sheep come with insulation, and bison will
go through anything that gets in their way including 3 x 6" diameter
corner posts and 4 strands of barbed and 2 hot wires.

horses on the other hand are pansies.

livestock always ends up on the other side of the fence...

> On Sep 19, 2011 9:34 PM, "Suresh Ramasubramanian" <ops.lists at gmail.com>
> wrote:
> 
> On Tue, Sep 20, 2011 at 12:20 AM, John van Oppen
> <jvanoppen at spectrumnet.us> wrote:
>> We had a cow br...
> Your crews turning up there the next time a cow tries its luck are
> guaranteed a steak dinner then.
> 
> 



From dan.holme at gmail.com  Tue Sep 20 03:49:40 2011
From: dan.holme at gmail.com (Daniel Holme)
Date: Tue, 20 Sep 2011 09:49:40 +0100
Subject: SDH Fiber Problem
In-Reply-To: <1316424006.67260.YahooMailNeo@web39501.mail.mud.yahoo.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
 <ABAE7F69-A596-49F5-93EA-FF528F2EB38A@ukbroadband.com>
 <1316420052.39155.YahooMailNeo@web39501.mail.mud.yahoo.com>
 <82933B17-9992-47FB-8472-3F5112F118E2@ukbroadband.com>
 <1316424006.67260.YahooMailNeo@web39501.mail.mud.yahoo.com>
Message-ID: <CANhyFpdgyY+y3+rL8=H4UfuWJXBDZtBrE-Ee3fiPFSkkcn=QrQ@mail.gmail.com>

On 19 September 2011 10:20, jacob miller <mmzinyi at yahoo.com> wrote:
> I have triend to do a ping with the DF bit set.
> Maximum am able to get to is 1600.
> This am guessing is because of the fact I have set the mtu size on My interface to 1600.

You could extend this test by sending TCP packets across to simulate
the HTTP flow, ideally looking at the packets as they come in at the
other end. At least this way you're closer to replicating the problem
than just using ICMP.

If this doesn't get you anywhere, and as you can get ICMP packets of
1600byte across the link then have you thought about looking elsewhere
for the problem? Potentially further up the path to the Internet?

-- 
Daniel Holme


From randy at psg.com  Tue Sep 20 03:50:29 2011
From: randy at psg.com (Randy Bush)
Date: Tue, 20 Sep 2011 10:50:29 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <20110920060028.GX6006@nntp.AegisInfoSys.com>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu>
 <4E782323.4090906@barton.net>
 <20110920060028.GX6006@nntp.AegisInfoSys.com>
Message-ID: <m2ehzbwqay.wl%randy@psg.com>

>>    http://ibm-1401.info/
> A few (dozen) years ago, I was treated to a interesting demonstration
> where a coworker poured an oily fluid containing tiny metallic flakes
> on a patch of tape.  The "bits" on the tape could be clearly seen by
> the naked eye, and could be decoded (ever so slowly!) using a
> magnifying glass.

standard ops procedure on those old tapes

randy


From bmanning at vacation.karoshi.com  Tue Sep 20 04:25:46 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 20 Sep 2011 09:25:46 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <9606.1316492099@turing-police.cc.vt.edu>
References: <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu>
Message-ID: <20110920092546.GA3829@vacation.karoshi.com.>

On Tue, Sep 20, 2011 at 12:14:59AM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Tue, 20 Sep 2011 05:32:04 +0200, Randy Bush said:
> 
> > you left out one connection via a chevy full of hollerith cards and the
> > second a canoe full of 7 track tape in waterproof containers.
> 
> Does anybody actually *have* a functional 7 track drive?  I remember seeing a
> story on PBS (may have been a Nova episode) where they discussed the fact that
> NASA had literally thousands of 7 track tapes of telemetry data and no way to
> read them because their last 7 track drive had died, and IBM had no 7 track
> read/write heads left either...
> 
> (I admit we still have a rack of 9-track tapes in ez-loader seals in our tape
> library, though we got rid of our last IBM 3420 about a decade ago. I think
> most of them are tapes we've lost track of ownership info, and don't dare
> dispose of in case the owner turns up.. ;)
> 

	I know of two sites that have them and there are folks who keep
	older kit running.  its not cheap and they are not high volume.

/bill


From bonomi at mail.r-bonomi.com  Tue Sep 20 05:28:23 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Tue, 20 Sep 2011 05:28:23 -0500 (CDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <21961749.2409.1316491626619.JavaMail.root@benjamin.baylink.com>
Message-ID: <201109201028.p8KASNOw061314@mail.r-bonomi.com>


> Date: Tue, 20 Sep 2011 00:07:06 -0400 (EDT)
> From: Jay Ashworth <jra at baylink.com>
> Subject: Re: wet-behind-the-ears whippersnapper seeking advice on building a
>  nationwide network
>
> > From: "Randy Bush" <randy at psg.com>
>
> > you left out one connection via a chevy full of hollerith cards and the 
> > second a canoe full of 7 track tape in waterproof containers.
>
> That's "a station wagon full of magtape".  Henry would be disappointed.

The zoo didn't use it.   The station wagon transport layer -- which gave
an entirely new meaning to 'jumbo packets' -- was a point-to-point link
between a couple of North Carolina locations.




From tvhawaii at shaka.com  Tue Sep 20 05:29:11 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Tue, 20 Sep 2011 00:29:11 -1000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu> <4E782323.4090906@barton.net>
 <20110920060028.GX6006@nntp.AegisInfoSys.com> <m2ehzbwqay.wl%randy@psg.com>
Message-ID: <373D3EDBD71C47FD9BA089223D831D32@owner59e1f1502>

Randy Bush wrote:
>>>    http://ibm-1401.info/
>> A few (dozen) years ago, I was treated to a interesting demonstration
>> where a coworker poured an oily fluid containing tiny metallic flakes
>> on a patch of tape.  The "bits" on the tape could be clearly seen by
>> the naked eye, and could be decoded (ever so slowly!) using a
>> magnifying glass.
>
> standard ops procedure on those old tapes
>
> randy

Yep.  The method I was taught (IBM) was to loop the tape into the 'developing' solution container and see-saw it back and 
forth to make sure the mag. particles were distributed.
Pull it out and wait until the medium evaporated.  Lay it down and carefully place 'scotch-tape' over the record.  Pull 
the scotch tape up and re-tape it to a white, blank,  "punched card".
I still have the adjustable magnifier with the bit areas marked on the reticle.

--Michael 



From bonomi at mail.r-bonomi.com  Tue Sep 20 05:31:47 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Tue, 20 Sep 2011 05:31:47 -0500 (CDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <9606.1316492099@turing-police.cc.vt.edu>
Message-ID: <201109201031.p8KAVlJm061351@mail.r-bonomi.com>


> From: Valdis.Kletnieks at vt.edu
> Subject: Re: wet-behind-the-ears whippersnapper seeking advice on building a
>  nationwide network
> Date: Tue, 20 Sep 2011 00:14:59 -0400
>
>
> Does anybody actually *have* a functional 7 track drive? 

I _think_ there's a guy in OZ that still has one or more.

Haven't been in touch with him for several years though.




From david at cantrell.org.uk  Tue Sep 20 05:57:20 2011
From: david at cantrell.org.uk (David Cantrell)
Date: Tue, 20 Sep 2011 11:57:20 +0100
Subject: Internet mauled by bears
In-Reply-To: <4E7842D3.3090305@bogus.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com>
Message-ID: <20110920105720.GA11712@bytemark.barnyard.co.uk>

On Tue, Sep 20, 2011 at 12:37:55AM -0700, Joel jaeggli wrote:

> cows have rather thick skin, sheep come with insulation, and bison will
> go through anything that gets in their way including 3 x 6" diameter
> corner posts and 4 strands of barbed and 2 hot wires.
> 
> horses on the other hand are pansies.
> 
> livestock always ends up on the other side of the fence...

Man, whoever invents the Moebius fence will make a FORTUNE.

-- 
David Cantrell | Official London Perl Mongers Bad Influence

    Deck of Cards: $1.29.
    "101 Solitaire Variations" book: $6.59.
    Cheap replacement for the one thing Windows is good at: priceless
        -- Shane Lazarus


From jamie at photon.com  Tue Sep 20 06:57:43 2011
From: jamie at photon.com (Jamie Bowden)
Date: Tue, 20 Sep 2011 07:57:43 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <9606.1316492099@turing-police.cc.vt.edu>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu>
Message-ID: <275FEA2949B48341A3B46F424B613D857D4B@WDC-MX.photon.com>



> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> Sent: Tuesday, September 20, 2011 12:15 AM
> 
> On Tue, 20 Sep 2011 05:32:04 +0200, Randy Bush said:
> 
> > you left out one connection via a chevy full of hollerith cards and
> the
> > second a canoe full of 7 track tape in waterproof containers.
> 
> Does anybody actually *have* a functional 7 track drive?  I remember
> seeing a
> story on PBS (may have been a Nova episode) where they discussed the
> fact that
> NASA had literally thousands of 7 track tapes of telemetry data and no
> way to
> read them because their last 7 track drive had died, and IBM had no 7
> track
> read/write heads left either...
> 
> (I admit we still have a rack of 9-track tapes in ez-loader seals in
> our tape
> library, though we got rid of our last IBM 3420 about a decade ago. I
> think
> most of them are tapes we've lost track of ownership info, and don't
> dare
> dispose of in case the owner turns up.. ;)

It's worse than that.  I spent a little time working at NASA LaRC, and
even if you had a functional drive, the tapes are mostly garbage (we had
tens of thousands of 9 track spools that had spent decades in rooms with
no temp or humidity controls).  No point in trying to read data from a
tape that's shedding the layer of magnetic material.  We were not
unique.

Jamie


From harbor235 at gmail.com  Tue Sep 20 06:59:00 2011
From: harbor235 at gmail.com (harbor235)
Date: Tue, 20 Sep 2011 07:59:00 -0400
Subject: insurance
Message-ID: <CAB_zYd+R7UhF-AjkO=oz+C8FckLFqcWXecSRLHrUKFzZron+BQ@mail.gmail.com>

Curious if anyone out there is acting as an independent contractor,
consultant,  or small business,
if so do you use professional liability insurance? What should I look out
for and is there any good
brokers that offer inexpensive yet reliable insurance?


thanks as always,


Mike

From jlewis at lewis.org  Tue Sep 20 07:01:46 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 20 Sep 2011 08:01:46 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <4E7802F3.2020806@matthew.at>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
Message-ID: <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>

On Mon, 19 Sep 2011, Matthew Kaufman wrote:

> On 9/19/2011 6:02 PM, Jon Lewis wrote:
>> On Sun, 18 Sep 2011, Frank Bulk wrote:
>> 
>>> I should have made myself more clear -- the policy amendment would make
>>> clear that multihoming requires only one facilities-based connection and
>>> that the other connections could be fulfilled via tunnels.  This may be
>>> heresy for some.
>> 
>> That's not multihoming.
>
> Really? Lets try these and see how you do:

The ARIN NRPM actually defines it:

  2.7. Multihomed

  An organization is multihomed if it receives full-time connectivity from
  more than one ISP and has one or more routing prefixes announced by at
  least two of its upstream ISPs.

IMO, "full-time connectivity" would mean a leased line, ethernet, or even 
wireless connection, but not a GRE or other tunnel (which is entirely 
dependent on other connectivity).

i.e. if you have a leased line connection to ISP-A, and a tunnel over that 
connection to ISP-B, and either A or your leased line fail, then you're 
down.  That's not multihoming.

Some of the scenarios you suggested are pretty unusual and would have to 
be considered on a case by case basis.  i.e. a shared T1 to some common 
point over which you peer with 2 providers?  I'd argue in that case, 
whoever provides or terminates the T1 in that case is your one transit 
provider, and again, you're really not multihomed...unless its your T1 and 
your router at the remote side, and that router has ethernet to the two 
providers...then that router is multihomed, and though most of your 
network is not, I'd argue that you have satisfied the requirement for 
being multihomed.

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


From harbor235 at gmail.com  Tue Sep 20 08:00:10 2011
From: harbor235 at gmail.com (harbor235)
Date: Tue, 20 Sep 2011 09:00:10 -0400
Subject: insurance
In-Reply-To: <CAB_zYd+R7UhF-AjkO=oz+C8FckLFqcWXecSRLHrUKFzZron+BQ@mail.gmail.com>
References: <CAB_zYd+R7UhF-AjkO=oz+C8FckLFqcWXecSRLHrUKFzZron+BQ@mail.gmail.com>
Message-ID: <CAB_zYdK3hT0ZjtmmPyk7WWEZCdZd4_oU8xNb-xoFb24kJFQS5g@mail.gmail.com>

Than you for the responses, I want to clarify that I am talking about
professional
laibility and not general liability insurance. Professional liability being
insurance
that covers "errors or omissions while executing professional work" that may
adversely
impact a business your are contracting with.

thanx,

Mike

On Tue, Sep 20, 2011 at 7:59 AM, harbor235 <harbor235 at gmail.com> wrote:

> Curious if anyone out there is acting as an independent contractor,
> consultant,  or small business,
> if so do you use professional liability insurance? What should I look out
> for and is there any good
> brokers that offer inexpensive yet reliable insurance?
>
>
> thanks as always,
>
>
> Mike
>

From Valdis.Kletnieks at vt.edu  Tue Sep 20 08:11:13 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 20 Sep 2011 09:11:13 -0400
Subject: insurance
In-Reply-To: Your message of "Tue, 20 Sep 2011 07:59:00 EDT."
 <CAB_zYd+R7UhF-AjkO=oz+C8FckLFqcWXecSRLHrUKFzZron+BQ@mail.gmail.com>
References: <CAB_zYd+R7UhF-AjkO=oz+C8FckLFqcWXecSRLHrUKFzZron+BQ@mail.gmail.com>
Message-ID: <28624.1316524273@turing-police.cc.vt.edu>

On Tue, 20 Sep 2011 07:59:00 EDT, harbor235 said:
> Curious if anyone out there is acting as an independent contractor,
> consultant,  or small business,
> if so do you use professional liability insurance?

I don't consult myself, but is *anybody* crazy enough to do consulting
in the litigation-crazy US without carrying errors-and-omissions
insurance?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110920/8926ba52/attachment.bin>

From cmadams at hiwaay.net  Tue Sep 20 08:13:07 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 20 Sep 2011 08:13:07 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <20110920060028.GX6006@nntp.AegisInfoSys.com>
References: <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu> <4E782323.4090906@barton.net>
 <20110920060028.GX6006@nntp.AegisInfoSys.com>
Message-ID: <20110920131307.GC17421@hiwaay.net>

Once upon a time, Henry Yen <henry at AegisInfoSys.com> said:
> A few (dozen) years ago, I was treated to a interesting demonstration where
> a coworker poured an oily fluid containing tiny metallic flakes on a patch
> of tape.  The "bits" on the tape could be clearly seen by the naked eye,
> and could be decoded (ever so slowly!) using a magnifying glass.

Dad has a little magnifying glass above a tray of metallic particles
with a slot below that.  He could pull a tape through the slot, tap the
device, and the particles would line up with the bits.

Of course, he also still has his NASA-issued slide rule still in his
desk at work. :-)
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From joe at ngn-networks.com  Tue Sep 20 08:50:13 2011
From: joe at ngn-networks.com (=?utf-8?B?Sm9lIEZyZWVtYW4=?=)
Date: Tue, 20 Sep 2011 09:50:13 -0400
Subject: =?utf-8?B?Q29zdGEgUmljYW4gU2VydmljZSBwcm92aWRlcnM/?=
Message-ID: <mailman.37.1316526602.1870.nanog@nanog.org>

I'm looking for any providers in Costa Rica that can service a location in San Pedro, San Jose, that can provide me 40Mbps service via Ethernet hand off, that does NOT use RACSA facilities. 

Please contact me off list. 

From jason at thebaughers.com  Tue Sep 20 09:15:26 2011
From: jason at thebaughers.com (Jason Baugher)
Date: Tue, 20 Sep 2011 09:15:26 -0500
Subject: Internet mauled by bears
In-Reply-To: <4E7842D3.3090305@bogus.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com>
Message-ID: <4E789FFE.9050702@thebaughers.com>

On 9/20/2011 2:37 AM, Joel jaeggli wrote:
> On 9/19/11 18:49 , Richard Barnes wrote:
>> And if they turn up the voltage on the fence high enough, dinner could be
>> cooked by the time the crew gets there!
> montana experience says:
>
> cows have rather thick skin, sheep come with insulation, and bison will
> go through anything that gets in their way including 3 x 6" diameter
> corner posts and 4 strands of barbed and 2 hot wires.
>
> horses on the other hand are pansies.
>
> livestock always ends up on the other side of the fence...
In Illinois:

Cows actually train to electric fence (hot wire) fairly well. They don't 
like being shocked too much. Once they get used to the fence, you can 
shut it off and they'll stay in for weeks because they won't even 
attempt it. That said, sometimes you get a cow that just really wants to 
be difficult and will go through anything. That cow is suddenly turned 
into hamburger.

Pigs also train to electric fence well. As tough as their hide is, it 
shocks well.

Sheep are difficult. Other than when they are recently sheared, they 
have a natural protection across 95% of their body. Unless it hits them 
in the head or lower leg, they aren't going to feel it. Even when 
sheared, they are a very stubborn animal. I've seen them standing facing 
a fence, swaying forward and backward, almost like they're trying to 
time the shock pulse. Then they go on through and tear up the wire and 
posts in the process. I've seen 4 strands of wire spaced about 10 inches 
apart and they won't stay in.

Horses are okay, but you have to tie things to the wire so they can see 
it. They're too dumb to remember where it is, apparently.

There is a big range of fence boxes. Some have a long pulse that isn't 
too "hot". If you hold one of these, they make your hand and arm muscles 
clench up but they don't hurt too much. The other end of the range have 
a short "hot" pulse that will jump a good distance and will burn through 
green weeds. These hurt.
>> On Sep 19, 2011 9:34 PM, "Suresh Ramasubramanian"<ops.lists at gmail.com>
>> wrote:
>>
>> On Tue, Sep 20, 2011 at 12:20 AM, John van Oppen
>> <jvanoppen at spectrumnet.us>  wrote:
>>> We had a cow br...
>> Your crews turning up there the next time a cow tries its luck are
>> guaranteed a steak dinner then.
>>
>>
>
>



From harbor235 at gmail.com  Tue Sep 20 09:31:34 2011
From: harbor235 at gmail.com (harbor235)
Date: Tue, 20 Sep 2011 10:31:34 -0400
Subject: insurance
In-Reply-To: <4E78A138.4040709@colo4.com>
References: <CAB_zYd+R7UhF-AjkO=oz+C8FckLFqcWXecSRLHrUKFzZron+BQ@mail.gmail.com>
 <CAB_zYdK3hT0ZjtmmPyk7WWEZCdZd4_oU8xNb-xoFb24kJFQS5g@mail.gmail.com>
 <4E78A138.4040709@colo4.com>
Message-ID: <CAB_zYd+sM9Zt87qJGMw5OaB3PANwdzPM-iqW5D9E1TGYTU1oXA@mail.gmail.com>

So what is the difference with E&O and professional insurance?

Mike

On Tue, Sep 20, 2011 at 10:20 AM, Dave Ellis <dave at colo4.com> wrote:

> My wife works for an insurance Agency and handles small business lines.
> Want me to have her contact you?
>
>
> On 09/20/2011 08:00 AM, harbor235 wrote:
>
>> Than you for the responses, I want to clarify that I am talking about
>> professional
>> laibility and not general liability insurance. Professional liability
>> being
>> insurance
>> that covers "errors or omissions while executing professional work" that
>> may
>> adversely
>> impact a business your are contracting with.
>>
>> thanx,
>>
>> Mike
>>
>> On Tue, Sep 20, 2011 at 7:59 AM, harbor235<harbor235 at gmail.com>  wrote:
>>
>> Curious if anyone out there is acting as an independent contractor,
>>> consultant,  or small business,
>>> if so do you use professional liability insurance? What should I look out
>>> for and is there any good
>>> brokers that offer inexpensive yet reliable insurance?
>>>
>>>
>>> thanks as always,
>>>
>>>
>>> Mike
>>>
>>>

From branto at networking-architecture.com  Tue Sep 20 09:32:54 2011
From: branto at networking-architecture.com (Brant I. Stevens)
Date: Tue, 20 Sep 2011 09:32:54 -0500
Subject: insurance
In-Reply-To: <28624.1316524273@turing-police.cc.vt.edu>
Message-ID: <CA9E1BB4.792C7%branto@networking-architecture.com>



On 9/20/11 9:11 AM, "Valdis.Kletnieks at vt.edu" <Valdis.Kletnieks at vt.edu>
wrote:

>On Tue, 20 Sep 2011 07:59:00 EDT, harbor235 said:
>> Curious if anyone out there is acting as an independent contractor,
>> consultant,  or small business,
>> if so do you use professional liability insurance?

Many clients won't do business with you unless you provide the certificate
indicating you have the appropriate level of coverage.  In the networking
business, this can often be 1 or 2 million dollars.

>
>I don't consult myself, but is *anybody* crazy enough to do consulting
>in the litigation-crazy US without carrying errors-and-omissions
>insurance?
I'm sure there are some people who do, but I'd say they were stupid over
crazy.

>



From tshaw at oitc.com  Tue Sep 20 09:35:33 2011
From: tshaw at oitc.com (TR Shaw)
Date: Tue, 20 Sep 2011 10:35:33 -0400
Subject: insurance
In-Reply-To: <CAB_zYd+sM9Zt87qJGMw5OaB3PANwdzPM-iqW5D9E1TGYTU1oXA@mail.gmail.com>
References: <CAB_zYd+R7UhF-AjkO=oz+C8FckLFqcWXecSRLHrUKFzZron+BQ@mail.gmail.com>
 <CAB_zYdK3hT0ZjtmmPyk7WWEZCdZd4_oU8xNb-xoFb24kJFQS5g@mail.gmail.com>
 <4E78A138.4040709@colo4.com>
 <CAB_zYd+sM9Zt87qJGMw5OaB3PANwdzPM-iqW5D9E1TGYTU1oXA@mail.gmail.com>
Message-ID: <7947D1F2-49EC-4E0D-AF7D-8C93C52CFDB4@oitc.com>

Sameo sameo plus you'll need standard liability if you have clients that come to your office or if you work on their site.  Usually your contract will dictate the minimum required.


On Sep 20, 2011, at 10:31 AM, harbor235 wrote:

> So what is the difference with E&O and professional insurance?
> 
> Mike
> 
> On Tue, Sep 20, 2011 at 10:20 AM, Dave Ellis <dave at colo4.com> wrote:
> 
>> My wife works for an insurance Agency and handles small business lines.
>> Want me to have her contact you?
>> 
>> 
>> On 09/20/2011 08:00 AM, harbor235 wrote:
>> 
>>> Than you for the responses, I want to clarify that I am talking about
>>> professional
>>> laibility and not general liability insurance. Professional liability
>>> being
>>> insurance
>>> that covers "errors or omissions while executing professional work" that
>>> may
>>> adversely
>>> impact a business your are contracting with.
>>> 
>>> thanx,
>>> 
>>> Mike
>>> 
>>> On Tue, Sep 20, 2011 at 7:59 AM, harbor235<harbor235 at gmail.com>  wrote:
>>> 
>>> Curious if anyone out there is acting as an independent contractor,
>>>> consultant,  or small business,
>>>> if so do you use professional liability insurance? What should I look out
>>>> for and is there any good
>>>> brokers that offer inexpensive yet reliable insurance?
>>>> 
>>>> 
>>>> thanks as always,
>>>> 
>>>> 
>>>> Mike
>>>> 
>>>> 



From rfinnesey at gmail.com  Tue Sep 20 09:36:31 2011
From: rfinnesey at gmail.com (Ryan Finnesey)
Date: Tue, 20 Sep 2011 10:36:31 -0400
Subject: insurance
In-Reply-To: <CA9E1BB4.792C7%branto@networking-architecture.com>
References: <28624.1316524273@turing-police.cc.vt.edu>
 <CA9E1BB4.792C7%branto@networking-architecture.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAPDEJlQ8vWtAglG4AgTiQa5CgQAAEAAAAKtcTE++f6xKo7SmfwFzNYYBAAAAAA==@gmail.com>



-----Original Message-----
From: Brant I. Stevens [mailto:branto at networking-architecture.com] 
Sent: Tuesday, September 20, 2011 10:33 AM
To: Valdis.Kletnieks at vt.edu; harbor235
Cc: NANOG list
Subject: Re: insurance



On 9/20/11 9:11 AM, "Valdis.Kletnieks at vt.edu" <Valdis.Kletnieks at vt.edu>
wrote:

>On Tue, 20 Sep 2011 07:59:00 EDT, harbor235 said:
>> Curious if anyone out there is acting as an independent contractor, 
>> consultant,  or small business, if so do you use professional 
>> liability insurance?

Many clients won't do business with you unless you provide the certificate
indicating you have the appropriate level of coverage.  In the networking
business, this can often be 1 or 2 million dollars.

>
>I don't consult myself, but is *anybody* crazy enough to do consulting 
>in the litigation-crazy US without carrying errors-and-omissions 
>insurance?
I'm sure there are some people who do, but I'd say they were stupid over
crazy.

>

[Ryan Finnesey] At one of the User Groups I run the pizza place needs 6
million dollars in insurance just to make a delivery to the building.

Cheers
Ryan





From rcarpen at network1.net  Tue Sep 20 10:10:30 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Tue, 20 Sep 2011 11:10:30 -0400 (EDT)
Subject: insurance
In-Reply-To: <28624.1316524273@turing-police.cc.vt.edu>
Message-ID: <d9561a14-bb8f-4d65-b0bc-2ae9fc8914ef@zimbra.network1.net>


----- Original Message -----
> On Tue, 20 Sep 2011 07:59:00 EDT, harbor235 said:
> > Curious if anyone out there is acting as an independent contractor,
> > consultant,  or small business,
> > if so do you use professional liability insurance?
> 
> I don't consult myself, but is *anybody* crazy enough to do
> consulting
> in the litigation-crazy US without carrying errors-and-omissions
> insurance?

The reality is that with the mega-insurance companies able to set whatever crazy premiums they feel like, and raise them every other month, the cost of being fully insured is sometimes more than what you can charge as a consultant.

-Randy


From jack at bonyari.com  Tue Sep 20 10:15:13 2011
From: jack at bonyari.com (Jack Morgan)
Date: Tue, 20 Sep 2011 08:15:13 -0700
Subject: insurance
In-Reply-To: <d9561a14-bb8f-4d65-b0bc-2ae9fc8914ef@zimbra.network1.net>
References: <d9561a14-bb8f-4d65-b0bc-2ae9fc8914ef@zimbra.network1.net>
Message-ID: <4E78AE01.7060104@bonyari.com>

Randy,

On 09/20/2011 08:10 AM, Randy Carpenter wrote:
> 
> ----- Original Message -----
>> On Tue, 20 Sep 2011 07:59:00 EDT, harbor235 said:
>>> Curious if anyone out there is acting as an independent contractor,
>>> consultant,  or small business,
>>> if so do you use professional liability insurance?
>>
>> I don't consult myself, but is *anybody* crazy enough to do
>> consulting
>> in the litigation-crazy US without carrying errors-and-omissions
>> insurance?
> 
> The reality is that with the mega-insurance companies able to set whatever crazy premiums they feel like, and raise them every other month, the cost of being fully insured is sometimes more than what you can charge as a consultant.

This is just not true. Insurance companies are regulated by State
Insurance boards. If an insurance company wants to raise rates, they
have to submit a proposal to the their state insurance board. They can
only raise rates for a "class" of customers. For example, all customers
aged 50 - 62.



-- 
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan <jack at bonayri.com>
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A

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

From dorn at hetzel.org  Tue Sep 20 10:33:31 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Tue, 20 Sep 2011 11:33:31 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <Pine.LNX.4.61.1109201015090.25015@soloth.lewis.org>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CAFrZoh0VeNsFs33ykerUTkE1pL9CF6ZyQ6VC3EneHsMG9Gah6Q@mail.gmail.com>
 <Pine.LNX.4.61.1109201015090.25015@soloth.lewis.org>
Message-ID: <CAFrZoh0oVRkcaGnmDP+Or=dKXZJX2qo80Mxo6rJK1P=aE5LTyw@mail.gmail.com>

On Tue, Sep 20, 2011 at 10:22 AM, Jon Lewis <jlewis at lewis.org> wrote:

> On Tue, 20 Sep 2011, Dorn Hetzel wrote:
>
>  If what you have is LEC frame relay service over which you have PVCs to
>> two
>> providers of IP transit service, then, IMO, you are multihomed.  Are you
>> protected against every single failure mode?  No, but then neither are
>> many
>> folks with more traditional methods of multihoming.  You are certainly
>> afforded reasonable protection against routing issues on each of your two
>> providers.
>>
>
> I'd agree in that case that you do have connectivity to two providers and
> are multihomed, though in a very foolish way.
>
> Past experience has taught me that while Layer 2 LEC frame certainly fails,
it may do so quite a bit less often than the rate of routing flaps, peering
spats, and everything else that can go wrong at Layers 3..9 ...  So while
it's not physically diverse, it may still yield a significant reduction in
downtime compared to that same T1 direct to a single Layer 3 provider...


>
>  How about a hard T1 to provider A and a GRE tunnel over a 3G router for a
>> backup?  That's certainly physically diverse...
>>
>
> If I was the ARIN auditor, I'd say that's borderline acceptable as
> multihomed.  It's not much different from one of your connections being
> "wireless", as long as that 3G connection is of sufficient bandwidth to of
> meaningful utility if the T1 is down.  If your primary connection is
> T1/T3/ethernet/etc. and your second is a v.90 modem, then I'd probably call
> BS on the claim of being multihomed.
>
> So now you think ARIN should be judging how much bandwidth is enough, and
how much is not?  Perhaps I just have a corporate ASN, and my backup
 connection is the most I can afford to make sure at least email gets
through when the primary is down.

It's a slippery slope from "v.90 not good enough" to "less than 2xOCn not
good enough" where n can be adjusted to suitably limit competition...

-dorn

From lanning at lanning.cc  Tue Sep 20 11:06:20 2011
From: lanning at lanning.cc (Robert Hajime Lanning)
Date: Tue, 20 Sep 2011 09:06:20 -0700
Subject: Internet mauled by bears
In-Reply-To: <4E7842D3.3090305@bogus.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com>
Message-ID: <4E78B9FC.2010608@lanning.cc>

On 09/20/11 00:37, Joel jaeggli wrote:
> 
> livestock always ends up on the other side of the fence...

Must be the greener pastures.

-- 
END OF LINE
      --MCP


From jlewis at lewis.org  Tue Sep 20 11:13:01 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 20 Sep 2011 12:13:01 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <CAFrZoh0oVRkcaGnmDP+Or=dKXZJX2qo80Mxo6rJK1P=aE5LTyw@mail.gmail.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CAFrZoh0VeNsFs33ykerUTkE1pL9CF6ZyQ6VC3EneHsMG9Gah6Q@mail.gmail.com>
 <Pine.LNX.4.61.1109201015090.25015@soloth.lewis.org>
 <CAFrZoh0oVRkcaGnmDP+Or=dKXZJX2qo80Mxo6rJK1P=aE5LTyw@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.1109201156590.25015@soloth.lewis.org>

Dorn, you have some interesting mail habits.  Your message was sent 
directly to me (without list).  My reply to that message was to you 
(without the list).  Now you're replying to that reply and including the 
list again.  That's generally frowned upon, but in this particular case, 
no harm done.

More inline....

On Tue, 20 Sep 2011, Dorn Hetzel wrote:

>>  How about a hard T1 to provider A and a GRE tunnel over a 3G router for a
>>> backup?  That's certainly physically diverse...
>>
>> If I was the ARIN auditor, I'd say that's borderline acceptable as
>> multihomed.  It's not much different from one of your connections being
>> "wireless", as long as that 3G connection is of sufficient bandwidth to of
>> meaningful utility if the T1 is down.  If your primary connection is
>> T1/T3/ethernet/etc. and your second is a v.90 modem, then I'd probably call
>> BS on the claim of being multihomed.
>>
> So now you think ARIN should be judging how much bandwidth is enough, and
> how much is not?

To a certain degree, yes.  If your normal traffic level is several hundred 
mbit/s for instance, and you're doing that with one provider via gigabit 
ethernet, then a 3g wireless connection and GRE tunnel to a second 
AS is not multihoming.

If you open the door to that sort of interpretation, then every org with a 
T1 and a backup dial-up connection can claim to be "multihomed".

In either of these cases, it's not enough to just have the connection. 
The ARIN NRPM definition of Multihomed includes "has one or more routing 
prefixes announced by at least two of its upstream ISPs."  Are you really 
going to announce your prefix[es] to both your real provider _and_ your 
ridiculously low bandwidth provider?  Even if you prepend the latter 
considerably, you're likely to receive some traffic via that path.

> It's a slippery slope from "v.90 not good enough" to "less than 2xOCn not
> good enough" where n can be adjusted to suitably limit competition...

Perhaps the manual should be updated to replace "full-time connectivity" 
with something a bit more fleshed out specifying that the full-time 
connectivity be via dedicated circuit [frame-relay permanent virtual 
circuits included, if you can still find a LEC willing to sell them] or 
PTP wireless.

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


From Bryan at bryanfields.net  Tue Sep 20 11:20:22 2011
From: Bryan at bryanfields.net (Bryan Fields)
Date: Tue, 20 Sep 2011 12:20:22 -0400
Subject: insurance
In-Reply-To: <d9561a14-bb8f-4d65-b0bc-2ae9fc8914ef@zimbra.network1.net>
References: <d9561a14-bb8f-4d65-b0bc-2ae9fc8914ef@zimbra.network1.net>
Message-ID: <4E78BD46.6040104@bryanfields.net>

On 9/20/2011 11:10, Randy Carpenter wrote:
> The reality is that with the mega-insurance companies able to set whatever
> crazy premiums they feel like, and raise them every other month, the cost
> of being fully insured is sometimes more than what you can charge as a
> consultant.

This is sad, but true.  Insurance was fully 1/4 of any income we made back
when I owned an ISP around 2001-2004.

-- 
Bryan Fields

727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net


From vixie at isc.org  Tue Sep 20 11:43:42 2011
From: vixie at isc.org (Paul Vixie)
Date: Tue, 20 Sep 2011 16:43:42 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net> (Benson
 Schliesser's message of "Mon, 19 Sep 2011 00:57:47 -0400")
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>
 <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net>
Message-ID: <g3ipondv0h.fsf@nsa.vix.com>

Benson Schliesser <bensons at queuefull.net> writes:

> For what it's worth, I agree that ARIN has a pretty good governance
> structure. (With the exception of NomCom this year, which is shamefully
> unbalanced.) ...

as the chairman of the 2011 ARIN NomCom, i hope you'll explain further,
either publically here, or privately, as you prefer.
-- 
Paul Vixie
KI6YSY


From dorn at hetzel.org  Tue Sep 20 12:00:53 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Tue, 20 Sep 2011 13:00:53 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <Pine.LNX.4.61.1109201156590.25015@soloth.lewis.org>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CAFrZoh0VeNsFs33ykerUTkE1pL9CF6ZyQ6VC3EneHsMG9Gah6Q@mail.gmail.com>
 <Pine.LNX.4.61.1109201015090.25015@soloth.lewis.org>
 <CAFrZoh0oVRkcaGnmDP+Or=dKXZJX2qo80Mxo6rJK1P=aE5LTyw@mail.gmail.com>
 <Pine.LNX.4.61.1109201156590.25015@soloth.lewis.org>
Message-ID: <CAFrZoh0verjQc=mM2djNq+PjF1JqCGH78gFeX3fO8MK4+jzyMQ@mail.gmail.com>

On Tue, Sep 20, 2011 at 12:13 PM, Jon Lewis <jlewis at lewis.org> wrote:

> Dorn, you have some interesting mail habits.  Your message was sent
> directly to me (without list).  My reply to that message was to you (without
> the list).  Now you're replying to that reply and including the list again.
>  That's generally frowned upon, but in this particular case, no harm done.
>
>
My apologies on that.  I made the first reply from my droid, meant to
reply/all, but somehow failed that and just used reply.

When I got your reply to just me, I realized what I had done, and tried to
correct it by including the last two bits of conversation
and changing it back to reply/all.  The original conversation had started as
public, so I admit I probably assumed that I could revert
it back to public with no harm.  Nonetheless, you are correct, it was not
the best form overall...


> More inline....
>
>
> On Tue, 20 Sep 2011, Dorn Hetzel wrote:
>
>   How about a hard T1 to provider A and a GRE tunnel over a 3G router for a
>>>
>>>> backup?  That's certainly physically diverse...
>>>>
>>>
>>> If I was the ARIN auditor, I'd say that's borderline acceptable as
>>> multihomed.  It's not much different from one of your connections being
>>> "wireless", as long as that 3G connection is of sufficient bandwidth to
>>> of
>>> meaningful utility if the T1 is down.  If your primary connection is
>>> T1/T3/ethernet/etc. and your second is a v.90 modem, then I'd probably
>>> call
>>> BS on the claim of being multihomed.
>>>
>>>  So now you think ARIN should be judging how much bandwidth is enough,
>> and
>> how much is not?
>>
>
> To a certain degree, yes.  If your normal traffic level is several hundred
> mbit/s for instance, and you're doing that with one provider via gigabit
> ethernet, then a 3g wireless connection and GRE tunnel to a second AS is not
> multihoming.
>
> If you open the door to that sort of interpretation, then every org with a
> T1 and a backup dial-up connection can claim to be "multihomed".
>
> Well, if their backup dial-up connection is *normally dialed up* and
*normally announcing routes* I would certainly agree that it is.  Note that
I use the word *normally* instead of *always*, since very nearly nothing can
manage to do something *always* in the strictest sense of the word   :)


> In either of these cases, it's not enough to just have the connection. The
> ARIN NRPM definition of Multihomed includes "has one or more routing
> prefixes announced by at least two of its upstream ISPs."  Are you really
> going to announce your prefix[es] to both your real provider _and_ your
> ridiculously low bandwidth provider?  Even if you prepend the latter
> considerably, you're likely to receive some traffic via that path.
>
> Well, it's ugly, but it's possible to announce more specific prefixes over
the route you want the traffic to take, say announcing two /24's over the
main connection and one /23 over the backup.  Yes, I know it pollutes the
route table, etc etc, but it can work and I have held my nose and done it
when it was the only feasible solution...

>
>  It's a slippery slope from "v.90 not good enough" to "less than 2xOCn not
>> good enough" where n can be adjusted to suitably limit competition...
>>
>
> Perhaps the manual should be updated to replace "full-time connectivity"
> with something a bit more fleshed out specifying that the full-time
> connectivity be via dedicated circuit [frame-relay permanent virtual
> circuits included, if you can still find a LEC willing to sell them] or PTP
> wireless.
>
>
> I use a LEC frame PVC every day, so I can vouch for their continued
existence :)

My personal opinion is that full-time connectivity just needs to mean
"normally connected", and that questions of transmission technology and
bandwidth are out of scope with regards to this discussion.  Frankly, even a
second BGP session over a GRE tunnel riding the Layer 3 connectivity
provided by the primary connection is STILL redundant for some types of
failures as long as the failure is not in the middle of the portion of the
primary network that the GRE tunnel transits...

Regards,

-Dorn

From bensons at queuefull.net  Tue Sep 20 12:01:41 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Tue, 20 Sep 2011 12:01:41 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <g3ipondv0h.fsf@nsa.vix.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net> <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com> <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net> <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>
 <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net>
 <g3ipondv0h.fsf@nsa.vix.com>
Message-ID: <C58EECBC-0ECE-40E9-95E7-A832190E5BC6@queuefull.net>

Hi, Paul.

On Sep 20, 2011, at 11:43, Paul Vixie <vixie at isc.org> wrote:

> Benson Schliesser <bensons at queuefull.net> writes:
> 
>> For what it's worth, I agree that ARIN has a pretty good governance
>> structure. (With the exception of NomCom this year, which is shamefully
>> unbalanced.) ...
> 
> as the chairman of the 2011 ARIN NomCom, i hope you'll explain further,
> either publically here, or privately, as you prefer.

My understanding is that the NomCom consists of 7 people. Of those, 2 come from the board and 2 come from the AC. Together, those 4 members of the existing establishment choose the remaining 3 NomCom members. In the past, there was at least the appearance of random selection for some of the NomCom members. But in any case, due to its composition, the NomCom has the appearance of a body biased in favor of the existing establishment.

Please correct any misunderstanding that I might have. Otherwise, I encourage an update to the structure of future NomComs.

Cheers,
-Benson



From hank at efes.iucc.ac.il  Tue Sep 20 12:13:09 2011
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Tue, 20 Sep 2011 20:13:09 +0300 (IDT)
Subject: 4.0.0.0/8?
Message-ID: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>

Did Level3 withdraw 4.0.0.0/8 today and start announcing it as two /9s?

-Hank


From morrowc.lists at gmail.com  Tue Sep 20 12:13:29 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 20 Sep 2011 13:13:29 -0400
Subject: old media (was: wannabe isp)
In-Reply-To: <m2vcsnx2t3.wl%randy@psg.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu>
 <m2vcsnx2t3.wl%randy@psg.com>
Message-ID: <CAL9jLaZEXM4=HuNs6XJ2ouFbE-PFDPotG=+sYZOC=W21O+bs=Q@mail.gmail.com>

On Tue, Sep 20, 2011 at 12:20 AM, Randy Bush <randy at psg.com> wrote:
>> Does anybody actually *have* a functional 7 track drive?
>
> if you really need one, i know what trail i would start to follow.
> there are folk keeping old stuff alive and pulling arcane things
> off old media (like the besm-6 system).

the text archive folks (talk at blackhat) may as well have a method to
read these.


From patrick at ianai.net  Tue Sep 20 12:14:48 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 20 Sep 2011 13:14:48 -0400
Subject: 4.0.0.0/8?
In-Reply-To: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>
References: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>
Message-ID: <D94701AB-4D43-43C3-AD7A-895B83DE1C9F@ianai.net>

On Sep 20, 2011, at 1:13 PM, Hank Nussbacher wrote:

> Did Level3 withdraw 4.0.0.0/8 today and start announcing it as two /9s?

I don't know if it was today, but I see two /9s.

-- 
TTFN,
patrick



From hank at efes.iucc.ac.il  Tue Sep 20 12:22:06 2011
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Tue, 20 Sep 2011 20:22:06 +0300 (IDT)
Subject: 4.0.0.0/8?
In-Reply-To: <D94701AB-4D43-43C3-AD7A-895B83DE1C9F@ianai.net>
References: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>
 <D94701AB-4D43-43C3-AD7A-895B83DE1C9F@ianai.net>
Message-ID: <alpine.LRH.2.00.1109202020340.18276@efes.iucc.ac.il>

On Tue, 20 Sep 2011, Patrick W. Gilmore wrote:

Newbie question:

If I do:
route-views>sho ip bgp 4.0.0.0
BGP routing table entry for 4.0.0.0/9, version 821994

why do I see the /9 and not the /8 by default?  If I do a specific lookup 
for 4.0.0.0/8 it is there as well.

Thanks,
Hank

> On Sep 20, 2011, at 1:13 PM, Hank Nussbacher wrote:
>
>> Did Level3 withdraw 4.0.0.0/8 today and start announcing it as two /9s?
>
> I don't know if it was today, but I see two /9s.
>
>


From cmadams at hiwaay.net  Tue Sep 20 12:25:32 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 20 Sep 2011 12:25:32 -0500
Subject: 4.0.0.0/8?
In-Reply-To: <alpine.LRH.2.00.1109202020340.18276@efes.iucc.ac.il>
References: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>
 <D94701AB-4D43-43C3-AD7A-895B83DE1C9F@ianai.net>
 <alpine.LRH.2.00.1109202020340.18276@efes.iucc.ac.il>
Message-ID: <20110920172532.GG17421@hiwaay.net>

Once upon a time, Hank Nussbacher <hank at efes.iucc.ac.il> said:
> Newbie question:
> 
> If I do:
> route-views>sho ip bgp 4.0.0.0
> BGP routing table entry for 4.0.0.0/9, version 821994
> 
> why do I see the /9 and not the /8 by default?  If I do a specific lookup 
> for 4.0.0.0/8 it is there as well.

I'd guess because that's the way routing lookups work; the more-specific
match always "wins".
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From joelja at bogus.com  Tue Sep 20 12:23:46 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Tue, 20 Sep 2011 10:23:46 -0700
Subject: 4.0.0.0/8?
In-Reply-To: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>
References: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>
Message-ID: <4E78CC22.2020605@bogus.com>

routeviews says the /9s have been announced for a while

the route object for 4.0.0.0/9 was last updated 20060203

On 9/20/11 10:13 , Hank Nussbacher wrote:
> Did Level3 withdraw 4.0.0.0/8 today and start announcing it as two /9s?
> 
> -Hank
> 



From ras at e-gerbil.net  Tue Sep 20 12:27:30 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 20 Sep 2011 12:27:30 -0500
Subject: 4.0.0.0/8?
In-Reply-To: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>
References: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>
Message-ID: <20110920172730.GI49464@gerbil.cluepon.net>

On Tue, Sep 20, 2011 at 08:13:09PM +0300, Hank Nussbacher wrote:
> Did Level3 withdraw 4.0.0.0/8 today and start announcing it as two /9s?

Level3 has been announcing 2x /9's as well as the /8 for some time now, 
ever since Telefonica's unfortunate incident where they allowed a 
customer to hijack 12.0.0.0/8 because they don't prefix-list filter 
customers properly IIRC.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From joelja at bogus.com  Tue Sep 20 12:24:51 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Tue, 20 Sep 2011 10:24:51 -0700
Subject: 4.0.0.0/8?
In-Reply-To: <alpine.LRH.2.00.1109202020340.18276@efes.iucc.ac.il>
References: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>
 <D94701AB-4D43-43C3-AD7A-895B83DE1C9F@ianai.net>
 <alpine.LRH.2.00.1109202020340.18276@efes.iucc.ac.il>
Message-ID: <4E78CC63.7070909@bogus.com>

On 9/20/11 10:22 , Hank Nussbacher wrote:
> On Tue, 20 Sep 2011, Patrick W. Gilmore wrote:
> 
> Newbie question:
> 
> If I do:
> route-views>sho ip bgp 4.0.0.0
> BGP routing table entry for 4.0.0.0/9, version 821994
> 
> why do I see the /9 and not the /8 by default?  If I do a specific
> lookup for 4.0.0.0/8 it is there as well.

more-specific wins unless you specifically ask for all routes.

> Thanks,
> Hank
> 
>> On Sep 20, 2011, at 1:13 PM, Hank Nussbacher wrote:
>>
>>> Did Level3 withdraw 4.0.0.0/8 today and start announcing it as two /9s?
>>
>> I don't know if it was today, but I see two /9s.
>>
>>
> 



From charles at knownelement.com  Tue Sep 20 12:40:58 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Tue, 20 Sep 2011 12:40:58 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <CAFrZoh0verjQc=mM2djNq+PjF1JqCGH78gFeX3fO8MK4+jzyMQ@mail.gmail.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CAFrZoh0VeNsFs33ykerUTkE1pL9CF6ZyQ6VC3EneHsMG9Gah6Q@mail.gmail.com>
 <Pine.LNX.4.61.1109201015090.25015@soloth.lewis.org>
 <CAFrZoh0oVRkcaGnmDP+Or=dKXZJX2qo80Mxo6rJK1P=aE5LTyw@mail.gmail.com>
 <Pine.LNX.4.61.1109201156590.25015@soloth.lewis.org>
 <CAFrZoh0verjQc=mM2djNq+PjF1JqCGH78gFeX3fO8MK4+jzyMQ@mail.gmail.com>
Message-ID: <4E78D02A.4000909@knownelement.com>

I plan to announce my ASN out of 3 physically diverse hops over 100mbps 
or gige. I believe that qualifies as multihoming under pretty much all 
definitions?

On that note, is anyone familiar with peering fabrics in 60 Hudson and 
600 West 7th (or peering fabrics that are fiber close in those locations)?

Initial connectivity/peering will be with my initial ISP friend in 600, 
and with KCIX in KC MO.

Would like to also peer with any peering exchanges in LA and NYC. I 
suppose peeringdb.com would be the place to look for this? (bringing 
this thread back on the original topic, though multihoming discussions 
definitely fall under the starting an isp category) :)


From morrowc.lists at gmail.com  Tue Sep 20 12:54:15 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 20 Sep 2011 13:54:15 -0400
Subject: 4.0.0.0/8?
In-Reply-To: <20110920172730.GI49464@gerbil.cluepon.net>
References: <alpine.LRH.2.00.1109202009430.17921@efes.iucc.ac.il>
 <20110920172730.GI49464@gerbil.cluepon.net>
Message-ID: <CAL9jLaZhmHAcKqZHTfan5VdfvHUipj2QEjhfC6VyETymeiOGqA@mail.gmail.com>

On Tue, Sep 20, 2011 at 1:27 PM, Richard A Steenbergen <ras at e-gerbil.net> wrote:
> On Tue, Sep 20, 2011 at 08:13:09PM +0300, Hank Nussbacher wrote:
>> Did Level3 withdraw 4.0.0.0/8 today and start announcing it as two /9s?
>
> Level3 has been announcing 2x /9's as well as the /8 for some time now,
> ever since Telefonica's unfortunate incident where they allowed a

<cough>I think they still don't</cough>
-chris


From markk at arin.net  Tue Sep 20 13:20:12 2011
From: markk at arin.net (Mark Kosters)
Date: Tue, 20 Sep 2011 18:20:12 +0000
Subject: FW: [arin-announce] Change to Whois Query Behavior
In-Reply-To: <4E77832A.6090907@arin.net>
Message-ID: <CA9E506B.47756%markk@arin.net>

Apologies for the cross post from ARIN-Announce. Thought that many of you
would be interested in hearing about the upcoming ARIN Whois change given
the recent discussion on NANOG.

Regards,
Mark 
ARIN CTO 

On 9/19/11 2:00 PM, "ARIN" <info at arin.net> wrote:

>ARIN announces a pending change to Whois query behavior on port 43.
>
>Prior to 25 June 2011, a query for an IP address in the ARIN region
>would return with that assignment/allocation within the ARIN region, and
>a query in the ARIN region for an IP address with no
>assignment/allocation would result in a ?no match? response. On 25 June,
>a change was misapplied. The intent of this change was to return ARIN?s
>/8 for IP queries within ARIN?s region for which there is no
>assignment/allocation, a behavior meant to align ARIN?s Whois output
>with that of the other RIRs. However, this change introduced an
>unintended behavior of returning ARIN?s /8, in addition to the desired
>results, in responses where IP addresses had been assigned or allocated.
>This change in behavior has created some confusion. On 2 October, ARIN
>will reinstate the previous behavior for Whois IP queries so that
>results are returned the way they were before 25 June.
>
>ARIN has provided two examples of a Whois query for reference:
>
>* Query with ARIN's /8 returned in the result set hierarchy:
>https://www.arin.net/announcements/2011/20110919.html#example1
>
>* Query without ARIN's /8 returned in the result set:
>https://www.arin.net/announcements/2011/20110919.html#example2
>
>Whois-RWS behavior will not change as it was not affected by the
>configuration change made on 25 June.
>
>We apologize for any confusion this has caused.
>
>
>
>Regards,
>Mark Kosters
>Chief Technical Officer
>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 bzs at world.std.com  Tue Sep 20 13:22:50 2011
From: bzs at world.std.com (Barry Shein)
Date: Tue, 20 Sep 2011 14:22:50 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <20110920060028.GX6006@nntp.AegisInfoSys.com>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu>
 <4E782323.4090906@barton.net>
 <20110920060028.GX6006@nntp.AegisInfoSys.com>
Message-ID: <20088.55802.219178.728299@world.std.com>


On September 20, 2011 at 02:00 henry at AegisInfoSys.com (Henry Yen) wrote:
 > 
 > A few (dozen) years ago, I was treated to a interesting demonstration where
 > a coworker poured an oily fluid containing tiny metallic flakes on a patch
 > of tape.  The "bits" on the tape could be clearly seen by the naked eye,
 > and could be decoded (ever so slowly!) using a magnifying glass.

Magnetic Tape Developer, you can still buy it (see link below). I
remember playing with the stuff back in the days when punch cards were
still your friend. I suppose it wouldn't be that hard to make your own
but I think the liquid was a fast-drying light solvent or CFC, not
oily, so it'd dry, you could read it, and then shake/wipe/dust it off.

It was supposedly handy for recovering physically mangled tapes, it
wasn't that rare for a tape to just get jammed in a drive and get so
crumpled it wouldn't go thru a drive any more and you didn't have a
backup tho usually at that point you dug out the original punch cards
and re-created the data set or whatever, had the data re-keyed (that
means punched back onto punchcards, or even key-to-tape, from its
pencil+paper source) because using tape developer would be too
expensive in terms of people-hours. Or you just applied to law school
and hoped for the best.


  http://www.cardserv.asia/joomla/index.php?option=com_content&view=article&id=21&Itemid=10

or

  http://tinyurl.com/6kak4o7

     -b



From owen at delong.com  Tue Sep 20 13:54:54 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 20 Sep 2011 11:54:54 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
Message-ID: <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>


On Sep 20, 2011, at 5:01 AM, Jon Lewis wrote:

> On Mon, 19 Sep 2011, Matthew Kaufman wrote:
> 
>> On 9/19/2011 6:02 PM, Jon Lewis wrote:
>>> On Sun, 18 Sep 2011, Frank Bulk wrote:
>>>> I should have made myself more clear -- the policy amendment would make
>>>> clear that multihoming requires only one facilities-based connection and
>>>> that the other connections could be fulfilled via tunnels.  This may be
>>>> heresy for some.
>>> That's not multihoming.
>> 
>> Really? Lets try these and see how you do:
> 
> The ARIN NRPM actually defines it:
> 
> 2.7. Multihomed
> 
> An organization is multihomed if it receives full-time connectivity from
> more than one ISP and has one or more routing prefixes announced by at
> least two of its upstream ISPs.
> 
> IMO, "full-time connectivity" would mean a leased line, ethernet, or even wireless connection, but not a GRE or other tunnel (which is entirely dependent on other connectivity).
> 

Why would you say that a GRE or other tunnel is not full-time connectivity? I have full-time GRE tunnels to two ISPs and they do actually constitute multihoming under the ARIN interpretation of NRPM 2.7.

> i.e. if you have a leased line connection to ISP-A, and a tunnel over that connection to ISP-B, and either A or your leased line fail, then you're down.  That's not multihoming.
> 

In my case, I have full-time circuits to two entities that provide very limited IPv4 services. I use those two connections to route GRE tunnels to routers in colocation facilities. My AS consists of the routers in the colocation facilities combined with the routers at my primary location and the networks to which they are attached. The GRE tunnels provide OSPF and iBGP routing to the routers at my primary location and my prefixes are anchored on the routers at the primary location. The colo routers provide the eBGP border connectivity to the upstream routers at each of the colos.

In what way is this not multihoming?

Now, let's look at some alternatives...

If I have only a single router at my primary location, is it still multihoming? I would say yes. Perhaps less reliable, but, that is not ARIN's concern.

If I have only a single physical link over which the multiple tunnels are connected, am I still receiving full time connectivity from two providers over the multiple tunnels?
Yes, actually, I am. Again, it's not as reliable, but, reliability is not ARIN's concern.

> Some of the scenarios you suggested are pretty unusual and would have to be considered on a case by case basis.  i.e. a shared T1 to some common point over which you peer with 2 providers?  I'd argue in that case, whoever provides or terminates the T1 in that case is your one transit provider, and again, you're really not multihomed...unless its your T1 and your router at the remote side, and that router has ethernet to the two providers...then that router is multihomed, and though most of your network is not, I'd argue that you have satisfied the requirement for being multihomed.
> 

I think you are delving much deeper into the internals of someones network than it is customary for ARIN to do in order to pass judgment on whether or not it is multihomed.

Owen



From patrick at ianai.net  Tue Sep 20 14:01:07 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 20 Sep 2011 15:01:07 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
Message-ID: <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>

On Sep 20, 2011, at 2:54 PM, Owen DeLong wrote:
> Why would you say that a GRE or other tunnel is not full-time connectivity? I have full-time GRE tunnels to two ISPs and they do actually constitute multihoming under the ARIN interpretation of NRPM 2.7.
> 
>> i.e. if you have a leased line connection to ISP-A, and a tunnel over that connection to ISP-B, and either A or your leased line fail, then you're down.  That's not multihoming.
>> 
> 
> In my case, I have full-time circuits to two entities that provide very limited IPv4 services. I use those two connections to route GRE tunnels to routers in colocation facilities. My AS consists of the routers in the colocation facilities combined with the routers at my primary location and the networks to which they are attached. The GRE tunnels provide OSPF and iBGP routing to the routers at my primary location and my prefixes are anchored on the routers at the primary location. The colo routers provide the eBGP border connectivity to the upstream routers at each of the colos.
> 
> In what way is this not multihoming?

In the way that you are apparently incapable of reading what was written.  Jon very clearly states that if the GRE tunnel goes over the same physical infrastructure, it is not multihoming.  Then you go on to explain how you have two physical lines.

I'd tell you to stop trolling, but I honestly wonder if you are trolling.

-- 
TTFN,
patrick



From fasterfourier at gmail.com  Tue Sep 20 14:01:44 2011
From: fasterfourier at gmail.com (Robert Johnson)
Date: Tue, 20 Sep 2011 15:01:44 -0400
Subject: DC74
Message-ID: <CAOq=Mm=9EEdGm9reFrgubG89BkZ4xkNKKeo+bn2_U6XXMrHT7w@mail.gmail.com>

If anyone here is using DC74 (www.dc74.com) for colocation and would
like to share their experiences, I'm all ears. Thanks in advance.

Robert


From cbrookes at gmail.com  Tue Sep 20 14:06:18 2011
From: cbrookes at gmail.com (Chris Brookes)
Date: Tue, 20 Sep 2011 14:06:18 -0500
Subject: lots of latency on qwest to google?
Message-ID: <CAAzPvNxtQiAMpJoMvVaSB-pUWRduBfYdSUNLDmFnuatRbxvCUw@mail.gmail.com>

Anyone else seeing a lot of latency to google via qwest?

..

11     2 ms     2 ms     2 ms  min-edge-12.inet.qwest.net [207.225.128.1]
12    15 ms    13 ms    12 ms  chx-edge-03.inet.qwest.net [67.14.38.5]
13    12 ms    21 ms    13 ms  72.14.214.78
14    13 ms    13 ms    13 ms  72.14.236.178
15    61 ms    61 ms    61 ms  216.239.43.80
16    72 ms    61 ms    62 ms  66.249.94.200
17   152 ms   145 ms   144 ms  216.239.43.213
18   148 ms   149 ms   150 ms  64.233.175.2
19   149 ms   150 ms   149 ms  66.249.94.34
20   212 ms   221 ms   212 ms  66.249.94.105
21   244 ms   244 ms   245 ms  66.249.94.75
22   244 ms   244 ms   244 ms  209.85.241.33
23   244 ms   243 ms   243 ms  74.125.236.52


From sclark at netwolves.com  Tue Sep 20 14:10:23 2011
From: sclark at netwolves.com (Steve Clark)
Date: Tue, 20 Sep 2011 15:10:23 -0400
Subject: lots of latency on qwest to google?
In-Reply-To: <CAAzPvNxtQiAMpJoMvVaSB-pUWRduBfYdSUNLDmFnuatRbxvCUw@mail.gmail.com>
References: <CAAzPvNxtQiAMpJoMvVaSB-pUWRduBfYdSUNLDmFnuatRbxvCUw@mail.gmail.com>
Message-ID: <4E78E51F.3060700@netwolves.com>

On 09/20/2011 03:06 PM, Chris Brookes wrote:
> Anyone else seeing a lot of latency to google via qwest?
>
> ..
>
> 11     2 ms     2 ms     2 ms  min-edge-12.inet.qwest.net [207.225.128.1]
> 12    15 ms    13 ms    12 ms  chx-edge-03.inet.qwest.net [67.14.38.5]
> 13    12 ms    21 ms    13 ms  72.14.214.78
> 14    13 ms    13 ms    13 ms  72.14.236.178
> 15    61 ms    61 ms    61 ms  216.239.43.80
> 16    72 ms    61 ms    62 ms  66.249.94.200
> 17   152 ms   145 ms   144 ms  216.239.43.213
> 18   148 ms   149 ms   150 ms  64.233.175.2
> 19   149 ms   150 ms   149 ms  66.249.94.34
> 20   212 ms   221 ms   212 ms  66.249.94.105
> 21   244 ms   244 ms   245 ms  66.249.94.75
> 22   244 ms   244 ms   244 ms  209.85.241.33
> 23   244 ms   243 ms   243 ms  74.125.236.52
>
We are seeing a routing loop at Qwest at one of our sites.

5  ge-5-2-0-0.ATL01-BB-RTR1.verizon-gni.net (130.81.17.115)  16.142 ms  16.093 ms  16.101 ms
  6  0.xe-7-1-0.BR3.ATL4.ALTER.NET (152.63.80.73)  16.682 ms  16.254 ms  16.232 ms
  7  204.255.168.222 (204.255.168.222)  16.412 ms  22.460 ms  21.343 ms
  8  eug-core-02.inet.qwest.net (67.14.32.33)  100.977 ms  99.921 ms  101.427 ms
  9  eug-edge-04.inet.qwest.net (205.171.150.38)  99.565 ms  98.840 ms  100.322 ms
10  207.109.242.6 (207.109.242.6)  112.195 ms  110.977 ms  112.466 ms
11  eug-edge-04.inet.qwest.net (207.109.242.5)  110.768 ms  111.701 ms  111.362 ms
12  207.109.242.6 (207.109.242.6)  117.494 ms  113.060 ms  113.308 ms
13  eug-edge-04.inet.qwest.net (207.109.242.5)  120.939 ms  120.411 ms  119.971 ms
14  207.109.242.6 (207.109.242.6)  125.842 ms  122.599 ms  122.036 ms
15  eug-edge-04.inet.qwest.net (207.109.242.5)  120.446 ms  118.881 ms  119.204 ms
16  207.109.242.6 (207.109.242.6)  125.540 ms  125.478 ms  138.716 ms
17  eug-edge-04.inet.qwest.net (207.109.242.5)  138.225 ms  132.476 ms  131.683 ms
18  207.109.242.6 (207.109.242.6)  141.288 ms  142.909 ms  150.655 ms
19  eug-edge-04.inet.qwest.net (207.109.242.5)  148.538 ms  148.713 ms  148.130 ms
20  207.109.242.6 (207.109.242.6)  156.247 ms  152.812 ms  155.129 ms
21  eug-edge-04.inet.qwest.net (207.109.242.5)  156.888 ms  158.048 ms  156.072 ms
22  207.109.242.6 (207.109.242.6)  165.790 ms  165.101 ms  168.350 ms
23  eug-edge-04.inet.qwest.net (207.109.242.5)  166.783 ms  167.106 ms  165.928 ms
24  207.109.242.6 (207.109.242.6)  175.051 ms  176.857 ms  175.693 ms
25  eug-edge-04.inet.qwest.net (207.109.242.5)  176.788 ms  176.379 ms  175.867 ms
26  207.109.242.6 (207.109.242.6)  184.702 ms  184.590 ms  186.183 ms
27  eug-edge-04.inet.qwest.net (207.109.242.5)  186.509 ms  187.398 ms  185.913 ms
28  207.109.242.6 (207.109.242.6)  194.984 ms  196.161 ms  195.821 ms
29  eug-edge-04.inet.qwest.net (207.109.242.5)  196.193 ms  195.687 ms  196.331 ms
30  207.109.242.6 (207.109.242.6)  205.271 ms  205.732 ms  205.718 ms



-- 
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com

From owen at delong.com  Tue Sep 20 14:10:44 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 20 Sep 2011 12:10:44 -0700
Subject: insurance
In-Reply-To: <4E78AE01.7060104@bonyari.com>
References: <d9561a14-bb8f-4d65-b0bc-2ae9fc8914ef@zimbra.network1.net>
 <4E78AE01.7060104@bonyari.com>
Message-ID: <2C44254A-9953-4F8A-9643-18A58A6C4F68@delong.com>


On Sep 20, 2011, at 8:15 AM, Jack Morgan wrote:

> Randy,
> 
> On 09/20/2011 08:10 AM, Randy Carpenter wrote:
>> 
>> ----- Original Message -----
>>> On Tue, 20 Sep 2011 07:59:00 EDT, harbor235 said:
>>>> Curious if anyone out there is acting as an independent contractor,
>>>> consultant,  or small business,
>>>> if so do you use professional liability insurance?
>>> 
>>> I don't consult myself, but is *anybody* crazy enough to do
>>> consulting
>>> in the litigation-crazy US without carrying errors-and-omissions
>>> insurance?
>> 
>> The reality is that with the mega-insurance companies able to set whatever crazy premiums they feel like, and raise them every other month, the cost of being fully insured is sometimes more than what you can charge as a consultant.
> 
> This is just not true. Insurance companies are regulated by State
> Insurance boards. If an insurance company wants to raise rates, they
> have to submit a proposal to the their state insurance board. They can
> only raise rates for a "class" of customers. For example, all customers
> aged 50 - 62.
> 

This is generally NOT true for E&O and Professional liability insurance.

For the most part, that goes largely unregulated. The state insurance boards
tend to focus on consumer-oriented forms of insurance (auto, home, life).

Owen



From mikea at mikea.ath.cx  Tue Sep 20 14:17:16 2011
From: mikea at mikea.ath.cx (mikea)
Date: Tue, 20 Sep 2011 14:17:16 -0500
Subject: lots of latency on qwest to google?
In-Reply-To: <CAAzPvNxtQiAMpJoMvVaSB-pUWRduBfYdSUNLDmFnuatRbxvCUw@mail.gmail.com>
References: <CAAzPvNxtQiAMpJoMvVaSB-pUWRduBfYdSUNLDmFnuatRbxvCUw@mail.gmail.com>
Message-ID: <20110920191716.GC63713@mikea.ath.cx>

On Tue, Sep 20, 2011 at 02:06:18PM -0500, Chris Brookes wrote:
> Anyone else seeing a lot of latency to google via qwest?
> 
> ..
> 
> 11     2 ms     2 ms     2 ms  min-edge-12.inet.qwest.net [207.225.128.1]
> 12    15 ms    13 ms    12 ms  chx-edge-03.inet.qwest.net [67.14.38.5]
> 13    12 ms    21 ms    13 ms  72.14.214.78
	The above address is is in Google IP space
> 14    13 ms    13 ms    13 ms  72.14.236.178
	The above address is is in Google IP space
> 15    61 ms    61 ms    61 ms  216.239.43.80
	The above address is is in Google IP space
> 16    72 ms    61 ms    62 ms  66.249.94.200
	The above address is is in Google IP space
> 17   152 ms   145 ms   144 ms  216.239.43.213
	The above address is is in Google IP space
> 18   148 ms   149 ms   150 ms  64.233.175.2
	The above address is is in Google IP space
> 19   149 ms   150 ms   149 ms  66.249.94.34
	The above address is is in Google IP space
> 20   212 ms   221 ms   212 ms  66.249.94.105
	The above address is is in Google IP space
> 21   244 ms   244 ms   245 ms  66.249.94.75
	The above address is is in Google IP space
> 22   244 ms   244 ms   244 ms  209.85.241.33
	The above address is is in Google IP space
> 23   244 ms   243 ms   243 ms  74.125.236.52
	The above address is is in Google IP space

Looks to me like the latency from Qwest to Google
(chx-edge-03.inet.qwest.net [67.14.38.5] to 72.14.214.78) is quite
tolerable, but the delay(s) inside Google are a tad bit high. I see much
the same thing from work and from home to 74.125.236.52. As soon as I jump
from my provider's upstream (Qwest at work, Cox at home) to Google, the
times go up sharply along the route to 74.125.236.52. 

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


From cmadams at hiwaay.net  Tue Sep 20 14:18:23 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 20 Sep 2011 14:18:23 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
Message-ID: <20110920191822.GA9818@hiwaay.net>

Once upon a time, Patrick W. Gilmore <patrick at ianai.net> said:
> In the way that you are apparently incapable of reading what was written.  Jon very clearly states that if the GRE tunnel goes over the same physical infrastructure, it is not multihoming.  Then you go on to explain how you have two physical lines.

Devil's advocate: if you have links to two carriers, but they are
delivered via the same LEC on the same fiber, are you multihomed?  What
about if you have two LECs at your facility, but the two circuits share
a common path elsewhere (outside of your knowledge)?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From owen at delong.com  Tue Sep 20 14:16:01 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 20 Sep 2011 12:16:01 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <Pine.LNX.4.61.1109201156590.25015@soloth.lewis.org>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CAFrZoh0VeNsFs33ykerUTkE1pL9CF6ZyQ6VC3EneHsMG9Gah6Q@mail.gmail.com>
 <Pine.LNX.4.61.1109201015090.25015@soloth.lewis.org>
 <CAFrZoh0oVRkcaGnmDP+Or=dKXZJX2qo80Mxo6rJK1P=aE5LTyw@mail.gmail.com>
 <Pine.LNX.4.61.1109201156590.25015@soloth.lewis.org>
Message-ID: <D5EFD229-9879-470A-8919-293336530865@delong.com>

> 
> If you open the door to that sort of interpretation, then every org with a T1 and a backup dial-up connection can claim to be "multihomed".
> 
You say that like it's a bad thing.

> In either of these cases, it's not enough to just have the connection. The ARIN NRPM definition of Multihomed includes "has one or more routing prefixes announced by at least two of its upstream ISPs."  Are you really going to announce your prefix[es] to both your real provider _and_ your ridiculously low bandwidth provider?  Even if you prepend the latter considerably, you're likely to receive some traffic via that path.
> 

If you have a GRE tunnel to each of 2 ISPs and announce your route over BGP to them, or, have some other configuration with them and they both announce your prefix to the rest of the world, that meets the ARIN test. The rest is an issue for the network administrator and not a matter for ARIN policy.

ARIN policy does not require your network to be functional or even useful. It's up to each administrator to decide how they want to operate their network and what level of dysfunction/lost packets they consider acceptable.

>> It's a slippery slope from "v.90 not good enough" to "less than 2xOCn not
>> good enough" where n can be adjusted to suitably limit competition...
> 
> Perhaps the manual should be updated to replace "full-time connectivity" with something a bit more fleshed out specifying that the full-time connectivity be via dedicated circuit [frame-relay permanent virtual circuits included, if you can still find a LEC willing to sell them] or PTP wireless.
> 

I would oppose such a policy change. I believe it is out of scope for ARIN's mission of address administration.

Owen



From rcarpen at network1.net  Tue Sep 20 14:21:51 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Tue, 20 Sep 2011 15:21:51 -0400 (EDT)
Subject: insurance
In-Reply-To: <2C44254A-9953-4F8A-9643-18A58A6C4F68@delong.com>
Message-ID: <658df69e-4b52-4937-b493-13b1dbed8c42@zimbra.network1.net>


> >> The reality is that with the mega-insurance companies able to set
> >> whatever crazy premiums they feel like, and raise them every
> >> other month, the cost of being fully insured is sometimes more
> >> than what you can charge as a consultant.
> > 
> > This is just not true. Insurance companies are regulated by State
> > Insurance boards. If an insurance company wants to raise rates,
> > they
> > have to submit a proposal to the their state insurance board. They
> > can
> > only raise rates for a "class" of customers. For example, all
> > customers
> > aged 50 - 62.
> > 
> 
> This is generally NOT true for E&O and Professional liability
> insurance.
> 
> For the most part, that goes largely unregulated. The state insurance
> boards
> tend to focus on consumer-oriented forms of insurance (auto, home,
> life).
> 
> Owen

Yep. I don't remember the specifics, but our quote was ridiculous (like $thousands per month). Our health insurance premiums also goes up 30+% nearly every year. So much for regulation there...

-Randy


From dorn at hetzel.org  Tue Sep 20 14:24:30 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Tue, 20 Sep 2011 15:24:30 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <D5EFD229-9879-470A-8919-293336530865@delong.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CAFrZoh0VeNsFs33ykerUTkE1pL9CF6ZyQ6VC3EneHsMG9Gah6Q@mail.gmail.com>
 <Pine.LNX.4.61.1109201015090.25015@soloth.lewis.org>
 <CAFrZoh0oVRkcaGnmDP+Or=dKXZJX2qo80Mxo6rJK1P=aE5LTyw@mail.gmail.com>
 <Pine.LNX.4.61.1109201156590.25015@soloth.lewis.org>
 <D5EFD229-9879-470A-8919-293336530865@delong.com>
Message-ID: <CAFrZoh1J0xc3yDXdVT9t5C6u-sxqJ6-0ynPHwLy=MosTC2G4qw@mail.gmail.com>

On Sep 20, 2011 3:21 PM, "Owen DeLong" <owen at delong.com> wrote:
>
> >
> > If you open the door to that sort of interpretation, then every org with
a T1 and a backup dial-up connection can claim to be "multihomed".
> >
> You say that like it's a bad thing.
>
> > In either of these cases, it's not enough to just have the connection.
The ARIN NRPM definition of Multihomed includes "has one or more routing
prefixes announced by at least two of its upstream ISPs."  Are you really
going to announce your prefix[es] to both your real provider _and_ your
ridiculously low bandwidth provider?  Even if you prepend the latter
considerably, you're likely to receive some traffic via that path.
> >
>
> If you have a GRE tunnel to each of 2 ISPs and announce your route over
BGP to them, or, have some other configuration with them and they both
announce your prefix to the rest of the world, that meets the ARIN test. The
rest is an issue for the network administrator and not a matter for ARIN
policy.
>
> ARIN policy does not require your network to be functional or even useful.
It's up to each administrator to decide how they want to operate their
network and what level of dysfunction/lost packets they consider acceptable.
>
> >> It's a slippery slope from "v.90 not good enough" to "less than 2xOCn
not
> >> good enough" where n can be adjusted to suitably limit competition...
> >
> > Perhaps the manual should be updated to replace "full-time connectivity"
with something a bit more fleshed out specifying that the full-time
connectivity be via dedicated circuit [frame-relay permanent virtual
circuits included, if you can still find a LEC willing to sell them] or PTP
wireless.
> >
>
> I would oppose such a policy change. I believe it is out of scope for
ARIN's mission of address administration.
>

It should be opposed because it would smack of restraint of trade, and that
is not a good place to be.

From paul4004 at gmail.com  Tue Sep 20 14:24:55 2011
From: paul4004 at gmail.com (PC)
Date: Tue, 20 Sep 2011 13:24:55 -0600
Subject: lots of latency on qwest to google?
In-Reply-To: <CAAzPvNxtQiAMpJoMvVaSB-pUWRduBfYdSUNLDmFnuatRbxvCUw@mail.gmail.com>
References: <CAAzPvNxtQiAMpJoMvVaSB-pUWRduBfYdSUNLDmFnuatRbxvCUw@mail.gmail.com>
Message-ID: <CAJAdsDnz21Urwt203fi-Lb=E31bEcSjk8US7FsvVv_XrMywpPg@mail.gmail.com>

You can traceroute from all their POPS here if you'd like:

https://kai02.centurylink.com/PtapRpts/Public/BackboneReport.aspx

Having said that, that IP has similar horrible latency from my non-qwest
connection.  Additionally, google does not resolve to that IP for me, which
is expected.  It does look like poor routing on google's network.  There's
one hop counting for 100 latency, then another adding another 100ms latency,
with little latency increases at other intermediary hops.  I suspect
something heading overseas and back between hop 5-6 and 7-8.

 3. google.com.any2ix.coresite.com
0.0%    97    1.0   4.0   0.7  67.1  12.1
 4.
64.233.174.31
0.0%    97    0.9   7.7   0.8  87.2  19.1
 5.
64.233.174.192
0.0%    97    1.2   1.5   1.0  10.8   1.3
 6.
64.233.174.177
0.0%    96  108.0 113.6 107.8 201.0  13.4
 7.
66.249.94.107
0.0%    96  108.7 113.7 108.4 157.9   9.8
 8.
66.249.94.105
0.0%    96  171.8 175.3 171.6 247.9  12.8
 9.
66.249.94.75
0.0%    96  203.4 204.5 203.1 251.7   6.9
10.
209.85.241.33
0.0%    96  204.7 203.9 203.4 206.6   0.5
11.
74.125.236.52
0.0%    96  204.2 203.8 203.2 204.7   0.4




On Tue, Sep 20, 2011 at 1:06 PM, Chris Brookes <cbrookes at gmail.com> wrote:

> Anyone else seeing a lot of latency to google via qwest?
>
> ..
>
> 11     2 ms     2 ms     2 ms  min-edge-12.inet.qwest.net [207.225.128.1]
> 12    15 ms    13 ms    12 ms  chx-edge-03.inet.qwest.net [67.14.38.5]
> 13    12 ms    21 ms    13 ms  72.14.214.78
> 14    13 ms    13 ms    13 ms  72.14.236.178
> 15    61 ms    61 ms    61 ms  216.239.43.80
> 16    72 ms    61 ms    62 ms  66.249.94.200
> 17   152 ms   145 ms   144 ms  216.239.43.213
> 18   148 ms   149 ms   150 ms  64.233.175.2
> 19   149 ms   150 ms   149 ms  66.249.94.34
> 20   212 ms   221 ms   212 ms  66.249.94.105
> 21   244 ms   244 ms   245 ms  66.249.94.75
> 22   244 ms   244 ms   244 ms  209.85.241.33
> 23   244 ms   243 ms   243 ms  74.125.236.52
>
>

From sethm at rollernet.us  Tue Sep 20 15:00:05 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 20 Sep 2011 13:00:05 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <CAFrZoh1J0xc3yDXdVT9t5C6u-sxqJ6-0ynPHwLy=MosTC2G4qw@mail.gmail.com>
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CAFrZoh0VeNsFs33ykerUTkE1pL9CF6ZyQ6VC3EneHsMG9Gah6Q@mail.gmail.com>
 <Pine.LNX.4.61.1109201015090.25015@soloth.lewis.org>
 <CAFrZoh0oVRkcaGnmDP+Or=dKXZJX2qo80Mxo6rJK1P=aE5LTyw@mail.gmail.com>
 <Pine.LNX.4.61.1109201156590.25015@soloth.lewis.org>
 <D5EFD229-9879-470A-8919-293336530865@delong.com>
 <CAFrZoh1J0xc3yDXdVT9t5C6u-sxqJ6-0ynPHwLy=MosTC2G4qw@mail.gmail.com>
Message-ID: <4E78F0C5.9030802@rollernet.us>

On 9/20/11 12:24 PM, Dorn Hetzel wrote:
> On Sep 20, 2011 3:21 PM, "Owen DeLong" <owen at delong.com> wrote:
>>
>>>
>>> If you open the door to that sort of interpretation, then every org with
> a T1 and a backup dial-up connection can claim to be "multihomed".
>>>
>> You say that like it's a bad thing.
>>
>>> In either of these cases, it's not enough to just have the connection.
> The ARIN NRPM definition of Multihomed includes "has one or more routing
> prefixes announced by at least two of its upstream ISPs."  Are you really
> going to announce your prefix[es] to both your real provider _and_ your
> ridiculously low bandwidth provider?  Even if you prepend the latter
> considerably, you're likely to receive some traffic via that path.

Yes. I've done it before. As long as the provider supports BGP
communities to tweak localperf you won't get any traffic over it and you
won't even need to prepend once. Prepending is really only a last resort
if you got stuck with a dud provider that doesn't support communities.

~Seth


From cbrookes at gmail.com  Tue Sep 20 14:59:55 2011
From: cbrookes at gmail.com (Chris Brookes)
Date: Tue, 20 Sep 2011 14:59:55 -0500
Subject: lots of latency on qwest to google?
In-Reply-To: <CAJAdsDnz21Urwt203fi-Lb=E31bEcSjk8US7FsvVv_XrMywpPg@mail.gmail.com>
References: <CAAzPvNxtQiAMpJoMvVaSB-pUWRduBfYdSUNLDmFnuatRbxvCUw@mail.gmail.com>
 <CAJAdsDnz21Urwt203fi-Lb=E31bEcSjk8US7FsvVv_XrMywpPg@mail.gmail.com>
Message-ID: <CAAzPvNxXS+MUztuWq9k9xgQk0C4e8=Z+rQkLV49u8i4JhK-oKQ@mail.gmail.com>

On 20 September 2011 14:24, PC <paul4004 at gmail.com> wrote:

> Having said that, that IP has similar horrible latency from my non-qwest
> connection.? Additionally, google does not resolve to that IP for me, which
> is expected.? It does look like poor routing on google's network.? There's

I mentioned qwest because when I checked via another path (HE) it was
fine. Does appear to be a google issue, I guess, based on further
testing. Ho hum..


From patrick at ianai.net  Tue Sep 20 15:05:05 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 20 Sep 2011 16:05:05 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <20110920191822.GA9818@hiwaay.net>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
Message-ID: <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>

On Sep 20, 2011, at 3:18 PM, Chris Adams wrote:
> Once upon a time, Patrick W. Gilmore <patrick at ianai.net> said:
>> In the way that you are apparently incapable of reading what was written.  Jon very clearly states that if the GRE tunnel goes over the same physical infrastructure, it is not multihoming.  Then you go on to explain how you have two physical lines.
> 
> Devil's advocate: if you have links to two carriers, but they are
> delivered via the same LEC on the same fiber, are you multihomed?  What
> about if you have two LECs at your facility, but the two circuits share
> a common path elsewhere (outside of your knowledge)?

Fair question.

As a customer, if your two transit circuits are in the same conduit, I do not consider that redundant.

However, I believe the spirit of the NRPM is clear.  Two circuits in the same conduit would qualify, one circuit with two BGP sessions does not.

As has been famously and repeatedly mentioned here and just about everywhere else John is subscribed, ARIN is a VERY open organization.  If you disagree with the NRPM, or even with an interpretation of it, feel free to offer up new language that would better fit your view.  If the community agrees, POOF!, you have a new rule.

-- 
TTFN,
patrick



From dorn at hetzel.org  Tue Sep 20 15:13:57 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Tue, 20 Sep 2011 16:13:57 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
 <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
Message-ID: <CAFrZoh3RW19=8DmBmu6424nJzgM2E4cUXm4DM4aSpA_thb8C3w@mail.gmail.com>

On Tue, Sep 20, 2011 at 4:05 PM, Patrick W. Gilmore <patrick at ianai.net>wrote:

> On Sep 20, 2011, at 3:18 PM, Chris Adams wrote:
> >  Once upon a time, Patrick W. Gilmore <patrick at ianai.net> said:
> >> In the way that you are apparently incapable of reading what was
> written.  Jon very clearly states that if the GRE tunnel goes over the same
> physical infrastructure, it is not multihoming.  Then you go on to explain
> how you have two physical lines.
> >
> > Devil's advocate: if you have links to two carriers, but they are
> > delivered via the same LEC on the same fiber, are you multihomed?  What
> > about if you have two LECs at your facility, but the two circuits share
> > a common path elsewhere (outside of your knowledge)?
>
> Fair question.
>
> As a customer, if your two transit circuits are in the same conduit, I do
> not consider that redundant.
>
> However, I believe the spirit of the NRPM is clear.  Two circuits in the
> same conduit would qualify, one circuit with two BGP sessions does not.
>
> As has been famously and repeatedly mentioned here and just about
> everywhere else John is subscribed, ARIN is a VERY open organization.  If
> you disagree with the NRPM, or even with an interpretation of it, feel free
> to offer up new language that would better fit your view.  If the community
> agrees, POOF!, you have a new rule.
>
>  Ok, I would propose something like:

"full time connection to two or more providers" should be satisfied when the
network involved has (or has contracted for and will have) two or more
connections that are diverse from each other at ANY point in their path
between the end network location or locations and the far end BGP peers,
whether or not the two or more connections are exposed to one or more common
points of failure, as long as their are any failure modes for which one
connection can provide protection against that failure mode somewhere in the
other connection.

Whew :)

I am sure someone can say it better!

-Dorn

From surfer at mauigateway.com  Tue Sep 20 15:41:52 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 20 Sep 2011 13:41:52 -0700
Subject: lots of latency on qwest to google?
Message-ID: <20110920134152.88577EA5@resin06.mta.everyone.net>



--- paul4004 at gmail.com wrote:
From: PC <paul4004 at gmail.com>

You can traceroute from all their POPS here if you'd like:

https://kai02.centurylink.com/PtapRpts/Public/BackboneReport.aspx
---------------------------------------------



Hmmm, it seems to work with only one vendor's browser.  Anyone else notice that?

scott


From jlewis at lewis.org  Tue Sep 20 16:02:34 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 20 Sep 2011 17:02:34 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <20110920191822.GA9818@hiwaay.net>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
Message-ID: <Pine.LNX.4.61.1109201539070.25015@soloth.lewis.org>

On Tue, 20 Sep 2011, Chris Adams wrote:

> Devil's advocate: if you have links to two carriers, but they are
> delivered via the same LEC on the same fiber, are you multihomed?  What
> about if you have two LECs at your facility, but the two circuits share
> a common path elsewhere (outside of your knowledge)?

I'd say you are.  End users frequently don't know the layout of their 
carrier's networks, and I certainly wouldn't expect ARIN to be interested 
in that level of detail.

What's next?  Are you going to ask if I'd require that your router have 
dual power supplies from different UPS's, or that if they don't have dual 
power, you have a router per transit connection?

It's a shame ARIN's auditors don't hang out here (or if they do, that they 
don't jump in and end these sorts of "what if" circle-jerks).  It's a 
simple enough question...have they already seen applications for IP/ASN 
resources where the applicant was required to be multihomed and their 
connectivity was one leased line and a GRE tunnel with BGP to a second 
provider.  Was the request approved?

How many providers will even provision such a service?

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


From Valdis.Kletnieks at vt.edu  Tue Sep 20 16:07:15 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 20 Sep 2011 17:07:15 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: Your message of "Tue, 20 Sep 2011 16:13:57 EDT."
 <CAFrZoh3RW19=8DmBmu6424nJzgM2E4cUXm4DM4aSpA_thb8C3w@mail.gmail.com>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
 <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
 <CAFrZoh3RW19=8DmBmu6424nJzgM2E4cUXm4DM4aSpA_thb8C3w@mail.gmail.com>
Message-ID: <23249.1316552835@turing-police.cc.vt.edu>

On Tue, 20 Sep 2011 16:13:57 EDT, Dorn Hetzel said:
> "full time connection to two or more providers" should be satisfied when the
> network involved has (or has contracted for and will have) two or more
> connections that are diverse from each other at ANY point in their path
> between the end network location or locations and the far end BGP peers,

I'm reading your statement as if you got the logic backwards - because this
doesn't rule out "pipe from one provider and tunnel across same pipe to another
provider, because the tunnel is diverse after it emerges from the first
provider's pipe. But since you know *up front* that the two connections have
fate sharing, it's not clear that it's "good enough" multihoming to count as
two *real* full time connections.

> points of failure, as long as their are any failure modes for which one
> connection can provide protection against that failure mode somewhere in the
> other connection.

As long as there is *A* failure mode?  Hmm. <invents a movie-plot failure mode
involving crazed ninjas with katanas loose in a switch room at one provider>.
Yep, it's unlikely crazed ninjas will attack the switch rooms at both providers.

I'm pretty sure what you intended to say there isn't what I read it as...



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

From matthew at matthew.at  Tue Sep 20 16:11:43 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 20 Sep 2011 14:11:43 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
 <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
Message-ID: <4E79018F.6010406@matthew.at>

On 9/20/11 1:05 PM, Patrick W. Gilmore wrote:
> However, I believe the spirit of the NRPM is clear. Two circuits in 
> the same conduit would qualify, one circuit with two BGP sessions does 
> not.

Totally disagree. If I have a metro ethernet circuit and can see both my 
transit providers over the same circuit, that's clearly multihoming.

As is a single DS3 over which I run two T-1s to different providers. Or 
two ATM or Frame Relay VCs.

Matthew Kaufman


From rbf+nanog at panix.com  Tue Sep 20 16:19:19 2011
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Tue, 20 Sep 2011 16:19:19 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network
In-Reply-To: <CAFrZoh3RW19=8DmBmu6424nJzgM2E4cUXm4DM4aSpA_thb8C3w@mail.gmail.com>
References: <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
 <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
 <CAFrZoh3RW19=8DmBmu6424nJzgM2E4cUXm4DM4aSpA_thb8C3w@mail.gmail.com>
Message-ID: <20110920211919.GA24848@panix.com>

On Tue, Sep 20, 2011 at 04:13:57PM -0400, Dorn Hetzel wrote:
> 
> "full time connection to two or more providers" should be satisfied when the
> network involved has (or has contracted for and will have) two or more
> connections that are diverse from each other at ANY point in their path
> between the end network location or locations and the far end BGP peers,
> whether or not the two or more connections are exposed to one or more common
> points of failure, as long as their are any failure modes for which one
> connection can provide protection against that failure mode somewhere in the
> other connection.

The GRE tunnel configuration being discussed in this thread passes this test. 
Consider the following:
   ISP #1 has transit connections to upstream A and B.
   ISP #2 has transit connections to upstream C and D
   ISP 1 and ISP 2 peer.

Customer gets a connection to ISP #1 and runs BGP, and, over that
connection, establishes a GRE tunnel to ISP #2, and runs BGP over that
also.

I assume your last clause requires that each connection provide
protection against a failure more in the other connection (not just
that one of the two provide protection against a failure mode on the
other).  This is satisfied.  In my example:

ISP #1 provides protection against ISP #2 having a complete meltdown.

ISP #2 provides protection against ISP #1 losing both its upstream
connections.

     -- Brett


From nanog at wjp.net  Tue Sep 20 16:25:44 2011
From: nanog at wjp.net (Bill P)
Date: Tue, 20 Sep 2011 14:25:44 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network -- ENOUGH ALREADY!
In-Reply-To: <4E79018F.6010406@matthew.at>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
 <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
 <4E79018F.6010406@matthew.at>
Message-ID: <4E7904D8.4000600@wjp.net>

This has deviated so far from a useful technical discussion, it isn't even 
amusing anymore.

 From http://www.nanog.org/mailinglist/

Our pre-posting guide for messages to the NANOG e-mail list:

     Does my email have operational/technical content?

ANSWER: NO.

     Would I be interested in reading this email?

ANSWER: YES, obviously (unless it wasn't me posting it.)  I am also the 
guy at work who everyone avoids because I am the annoying talker who never 
shuts up.  I often get confused when people just walk off in the middle of 
a "conversation" (ie: when I won't shut the hell up and/or let anyone else 
talk.)

     Would 10,000 other Internet engineers want to read this?

NO.

STOP.

-bill


ps.  Those who chime in with a witty comment or yet another opinion just 
when the thread seems to be slowing down are just as guilty as the ones 
who keep it doing by writing paragraph after paragraph "refuting" what the 
others have said.  (When neither side has an inkling of wanting to 
acquiesce to the other side.)

ObGodwin: Hitler.

Can we be done now?


From bret at getjive.com  Tue Sep 20 16:27:29 2011
From: bret at getjive.com (Bret Palsson)
Date: Tue, 20 Sep 2011 15:27:29 -0600
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network -- ENOUGH ALREADY!
In-Reply-To: <4E7904D8.4000600@wjp.net>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
 <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
 <4E79018F.6010406@matthew.at> <4E7904D8.4000600@wjp.net>
Message-ID: <399A63EC-DAE8-4DE0-A404-F4DF0598715F@getjive.com>

Thank you! 112 Emails on this subject, I am sick of it.

On Sep 20, 2011, at 3:25 PM, Bill P wrote:

> This has deviated so far from a useful technical discussion, it isn't even amusing anymore.
> 
> From http://www.nanog.org/mailinglist/
> 
> Our pre-posting guide for messages to the NANOG e-mail list:
> 
>    Does my email have operational/technical content?
> 
> ANSWER: NO.
> 
>    Would I be interested in reading this email?
> 
> ANSWER: YES, obviously (unless it wasn't me posting it.)  I am also the guy at work who everyone avoids because I am the annoying talker who never shuts up.  I often get confused when people just walk off in the middle of a "conversation" (ie: when I won't shut the hell up and/or let anyone else talk.)
> 
>    Would 10,000 other Internet engineers want to read this?
> 
> NO.
> 
> STOP.
> 
> -bill
> 
> 
> ps.  Those who chime in with a witty comment or yet another opinion just when the thread seems to be slowing down are just as guilty as the ones who keep it doing by writing paragraph after paragraph "refuting" what the others have said.  (When neither side has an inkling of wanting to acquiesce to the other side.)
> 
> ObGodwin: Hitler.
> 
> Can we be done now?
> 



From paul4004 at gmail.com  Tue Sep 20 16:49:08 2011
From: paul4004 at gmail.com (PC)
Date: Tue, 20 Sep 2011 15:49:08 -0600
Subject: lots of latency on qwest to google?
In-Reply-To: <20110920134152.88577EA5@resin06.mta.everyone.net>
References: <20110920134152.88577EA5@resin06.mta.everyone.net>
Message-ID: <CAJAdsDkA9s4fZh+KQDYhHm1gSDgAZtuevR+Q5MF-k8tVp6WrHw@mail.gmail.com>

I tried two  vendors without issue (firefox 5 + IE 9).  The only nuance I
saw is the "enter" key didn't work in IE9 for when I entered in the domain
to initiate the traceroute.  Clicking "run test" instead works fine.


On Tue, Sep 20, 2011 at 2:41 PM, Scott Weeks <surfer at mauigateway.com> wrote:

>
>
> --- paul4004 at gmail.com wrote:
> From: PC <paul4004 at gmail.com>
>
> You can traceroute from all their POPS here if you'd like:
>
> https://kai02.centurylink.com/PtapRpts/Public/BackboneReport.aspx
> ---------------------------------------------
>
>
>
> Hmmm, it seems to work with only one vendor's browser.  Anyone else notice
> that?
>
> scott
>
>

From owen at delong.com  Tue Sep 20 17:21:05 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 20 Sep 2011 15:21:05 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <CAFrZoh3RW19=8DmBmu6424nJzgM2E4cUXm4DM4aSpA_thb8C3w@mail.gmail.com>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
 <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
 <CAFrZoh3RW19=8DmBmu6424nJzgM2E4cUXm4DM4aSpA_thb8C3w@mail.gmail.com>
Message-ID: <377DAA44-417E-4349-A374-E4848426148A@delong.com>

>> 
>> Ok, I would propose something like:
> 
> "full time connection to two or more providers" should be satisfied when the
> network involved has (or has contracted for and will have) two or more
> connections that are diverse from each other at ANY point in their path
> between the end network location or locations and the far end BGP peers,
> whether or not the two or more connections are exposed to one or more common
> points of failure, as long as their are any failure modes for which one
> connection can provide protection against that failure mode somewhere in the
> other connection.
> 
> Whew :)
> 
> I am sure someone can say it better!
> 
> -Dorn

FWIW, two GRE tunnels over the same physical tail circuit to different
providers on the other side would satisfy that condition.

Frankly, I don't believe that your expanded definition changes anything
from the current state of affairs.

Owen



From owen at delong.com  Tue Sep 20 17:26:33 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 20 Sep 2011 15:26:33 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <Pine.LNX.4.61.1109201539070.25015@soloth.lewis.org>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
 <Pine.LNX.4.61.1109201539070.25015@soloth.lewis.org>
Message-ID: <E174A0CE-E34D-48C3-A2B6-4B0C90AEE49E@delong.com>


On Sep 20, 2011, at 2:02 PM, Jon Lewis wrote:

> On Tue, 20 Sep 2011, Chris Adams wrote:
> 
>> Devil's advocate: if you have links to two carriers, but they are
>> delivered via the same LEC on the same fiber, are you multihomed?  What
>> about if you have two LECs at your facility, but the two circuits share
>> a common path elsewhere (outside of your knowledge)?
> 
> I'd say you are.  End users frequently don't know the layout of their carrier's networks, and I certainly wouldn't expect ARIN to be interested in that level of detail.
> 
> What's next?  Are you going to ask if I'd require that your router have dual power supplies from different UPS's, or that if they don't have dual power, you have a router per transit connection?
> 
> It's a shame ARIN's auditors don't hang out here (or if they do, that they don't jump in and end these sorts of "what if" circle-jerks).  It's a simple enough question...have they already seen applications for IP/ASN resources where the applicant was required to be multihomed and their connectivity was one leased line and a GRE tunnel with BGP to a second provider.  Was the request approved?
> 
> How many providers will even provision such a service?
> 

I know for a fact that ARIN has received and approved such requests.

I do not know whether ARIN was aware of the exact details of the underlying topology in question at the time they approved the request or not.

I was a consultant filling out the applications for my clients at the time. It wasn't quite exactly what you describe, it was 2 GRE tunnels to different providers over a tail circuit from a third provider.

As long as you can show transit and/or peering with two ASNs (usually through a peering contract or letter of intent from the peer/transit provider), ARIN considers you to be multihomed for policy purposes. The underlying physical or logical mechanisms by which you reach those two (or more) neighbor ASNs are not ARIN's concern.

Owen



From dorn at hetzel.org  Tue Sep 20 17:50:30 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Tue, 20 Sep 2011 18:50:30 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <20110920211919.GA24848@panix.com>
References: <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
 <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
 <CAFrZoh3RW19=8DmBmu6424nJzgM2E4cUXm4DM4aSpA_thb8C3w@mail.gmail.com>
 <20110920211919.GA24848@panix.com>
Message-ID: <CAFrZoh0Bqem294i7cfEcqNzZLSdUrdnRN1BC2SZp_tH_mPCchg@mail.gmail.com>

On Tue, Sep 20, 2011 at 5:19 PM, Brett Frankenberger <rbf+nanog at panix.com>wrote:

> On Tue, Sep 20, 2011 at 04:13:57PM -0400, Dorn Hetzel wrote:
> >
> > "full time connection to two or more providers" should be satisfied when
> the
> > network involved has (or has contracted for and will have) two or more
> > connections that are diverse from each other at ANY point in their path
> > between the end network location or locations and the far end BGP peers,
> > whether or not the two or more connections are exposed to one or more
> common
> > points of failure, as long as their are any failure modes for which one
> > connection can provide protection against that failure mode somewhere in
> the
> > other connection.
>
> The GRE tunnel configuration being discussed in this thread passes this
> test.
> Consider the following:
>   ISP #1 has transit connections to upstream A and B.
>   ISP #2 has transit connections to upstream C and D
>   ISP 1 and ISP 2 peer.
>
> Customer gets a connection to ISP #1 and runs BGP, and, over that
> connection, establishes a GRE tunnel to ISP #2, and runs BGP over that
> also.
>
> I assume your last clause requires that each connection provide
> protection against a failure more in the other connection (not just
> that one of the two provide protection against a failure mode on the
> other).  This is satisfied.  In my example:
>
> ISP #1 provides protection against ISP #2 having a complete meltdown.
>
> ISP #2 provides protection against ISP #1 losing both its upstream
> connections.
>
>     -- Brett
>

Yes, that is what I was trying to say, that there are at least k providers,
k>=2, and that at least 2 of those k
providers offer at least some redundancy for some possible failure modes in
the other provider.

Your example is especially plausible if it happens that the router from
which ISP #1 provides me service
is the same router, or at least close in the same POP, to the router from
which they peer with ISP#2.

ISP#1 might then have a complete backbone meltdown, but retain their local
peering session with ISP#2,
which would allow me to still reach my tunnel endpoint in ISP#2 and the BGP
session resulting.

-Dorn

From wavetossed at googlemail.com  Tue Sep 20 18:34:49 2011
From: wavetossed at googlemail.com (Michael Dillon)
Date: Tue, 20 Sep 2011 16:34:49 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <m2sjntaos3.wl%randy@psg.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
Message-ID: <CAGQYzEZrDPt6DzGzcVsnO8RF--_f+EB4P3F6fCsx5nvtQraK8A@mail.gmail.com>

Randy is right that ARIN has missed a step here.

It is unfortunate that there is no tool in existence that would test
conformance of a whois server, and with hindsight, it would have been
a good idea for ARIN to sponsor such a tool on one of the open source
repo sites like github or googlecode.

Instead, various people have encoded bits of the knowledge of how
whois should work, into their own private and closed source systems so
nobody, including ARIN, has a good way to test conformance of any
system changes that they make.

We can only hope that in future, protocol definitions and protocol
testing tools will be developed in a more open fashion so that there
is, in fact, an issue tracker where anyone can open a ticket and
complain about something that appears to be a bug. I don't think ARIN
should be doing issue tracking like this, or closed source
development, when there are so many open source tools available.
Bitbucket and Codeplex are another couple that come to mind.

-- Michael Dillon

On 18 September 2011 07:49, Randy Bush <randy at psg.com> wrote:
>>>>> one to post overly aggressive defensive messages on nanog
>>>> I am not convinced that Mr. Bush is best placed to comment on this
>>>> particular issue.
>>> you seem to have a problem differentiating defense from offense. ?i
>>> recommend you not play chess. ?:)
>> Randy is perfectly right in expressing his concerns about the registry
>> system that we've built (as long as its on a mailing list which
>> supports the topic), since we're doing a function on behalf of the
>> entire Internet community and spending everyone's money in the
>> process. ?While it may not matter to him a bit, I'll defend his (and
>> anyone's else right) to critique the quality and cost effectiveness of
>> the job we're doing.
>
> thanks. ?:)
>
> i suspect some folk may be missing a few clues here. ?first is that you
> and i have been friends since the late '80s. ?second is that i was a
> founding board member of arin. ?and third, there is the concept of the
> loyal opposition.
>
> i just think that we, as a culture, have let things get waaaay out of
> whack. ?john is paid to defend the status grow.
>
> randy
>
>


From don at bowenvale.co.nz  Tue Sep 20 18:55:08 2011
From: don at bowenvale.co.nz (Don Gould)
Date: Wed, 21 Sep 2011 11:55:08 +1200
Subject: How to begin making my own ISP?
In-Reply-To: <20110916181029.24C11E671D@smtp.hushmail.com>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
Message-ID: <4E7927DC.3000604@bowenvale.co.nz>

Hasserw,

First I must apologise for not responding, I did see this message and 
did mean to attempt to help you out as I am currently working though 
this exact process in a very small proof of concept network with an even 
smaller budget.

To address our question, a good starting point is a Cisco CCNA.

If you review the list archive for the past month you will find a very 
interesting thread linking to guys who are running massive home networks 
just for their learning, that in turn will link you to detailed public 
CVs showing the sort of stuff that these guys are trained and training in.

You also need some business training to understand how to structure the 
business aspects of your project.  An MBA is a good qualification but 
there are many less high level courses you could look at as well.

NA Nog is an operational list (with a lot of rant and fun stuff) and not 
really a business focused or educational list, so your initial query 
simply ran under the radar.

D


On 17/09/2011 6:10 a.m., hasserw at hushmail.com wrote:
> No one replied with any useful information. I guess no one wants
> competition on this list? Pretty poor tactic.
>
> On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
>> I want to begin making my own ISP, mainly for high speed servers
>> and such, but also branching out to residential customers. I'm
>> going to be in Germany for the next school year (probably either
>> Frankfurt am Main or Berlin); any suggestions on what sort of
>> classes I can take there that will be in English and will teach me
>>
>> all I need to know on how to build and manage my own ISP, AS, etc?
>>
>> Thanks.
>
>

-- 
Don Gould
31 Acheson Ave
Mairehau
Christchurch, New Zealand
Ph: + 64 3 348 7235
Mobile: + 64 21 114 0699



From bmanning at vacation.karoshi.com  Tue Sep 20 19:15:07 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 21 Sep 2011 00:15:07 +0000
Subject: insurance
In-Reply-To: <658df69e-4b52-4937-b493-13b1dbed8c42@zimbra.network1.net>
References: <2C44254A-9953-4F8A-9643-18A58A6C4F68@delong.com>
 <658df69e-4b52-4937-b493-13b1dbed8c42@zimbra.network1.net>
Message-ID: <20110921001507.GA4953@vacation.karoshi.com.>

On Tue, Sep 20, 2011 at 03:21:51PM -0400, Randy Carpenter wrote:
> 
> > >> The reality is that with the mega-insurance companies able to set
> > >> whatever crazy premiums they feel like, and raise them every
> > >> other month, the cost of being fully insured is sometimes more
> > >> than what you can charge as a consultant.
> > > 
> > > This is just not true. Insurance companies are regulated by State
> > > Insurance boards. If an insurance company wants to raise rates,
> > > they
> > > have to submit a proposal to the their state insurance board. They
> > > can
> > > only raise rates for a "class" of customers. For example, all
> > > customers
> > > aged 50 - 62.
> > > 
> > 
> > This is generally NOT true for E&O and Professional liability
> > insurance.
> > 
> > For the most part, that goes largely unregulated. The state insurance
> > boards
> > tend to focus on consumer-oriented forms of insurance (auto, home,
> > life).
> > 
> > Owen
> 
> Yep. I don't remember the specifics, but our quote was ridiculous (like $thousands per month). Our health insurance premiums also goes up 30+% nearly every year. So much for regulation there...
> 
> -Randy

	Back n the day - I used Hartford for insurance.  It was very reasonable.
	Premiums went up once in the 15yrs we were active.

/bill


From jra at baylink.com  Tue Sep 20 20:07:44 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 20 Sep 2011 21:07:44 -0400 (EDT)
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <20110920191822.GA9818@hiwaay.net>
Message-ID: <26807971.2527.1316567264402.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Chris Adams" <cmadams at hiwaay.net>

> What about if you have two LECs at your facility, but the two circuits
> share a common path elsewhere (outside of your knowledge)?

p=1.0, *even* if you're paying for guaranteed physical diversity.

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      http://photo.imageinc.us             +1 727 647 1274


From jra at baylink.com  Tue Sep 20 20:11:10 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 20 Sep 2011 21:11:10 -0400 (EDT)
Subject: What's a reasonable attack surface? (was: Re: wet-behind-the-ears
 whippersnapper yada yada)
In-Reply-To: <23249.1316552835@turing-police.cc.vt.edu>
Message-ID: <13512334.2529.1316567470873.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>

> As long as there is *A* failure mode? Hmm. <invents a movie-plot failure mode
> involving crazed ninjas with katanas loose in a switch room at one provider>.
> Yep, it's unlikely crazed ninjas will attack the switch rooms at both
> providers.

I too am a Schneier fan.  But terrorists watch movies, too.

Cheers,
-- jr 'Once is happenstance...' a
-- 
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      http://photo.imageinc.us             +1 727 647 1274


From joe.gersch at secure64.com  Tue Sep 20 21:53:57 2011
From: joe.gersch at secure64.com (Joseph Gersch)
Date: Tue, 20 Sep 2011 20:53:57 -0600
Subject: akamai rate limiting?
Message-ID: <25D91B29-C48A-4A49-B793-2843B2C6173D@secure64.com>

Does anyone know if Akamai edgesuite servers rate limits or blacklists caching servers that query it too often?  It appears that queries are timing out if we exceed a query load to edgesuite.

 Does anyone at Akamai know if there are any changes to rate limiting or an abnormally high load?



Joseph Gersch
Chief Operating Officer
Secure64 Software Corporation



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

From cb.list6 at gmail.com  Tue Sep 20 22:17:53 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Tue, 20 Sep 2011 20:17:53 -0700
Subject: akamai rate limiting?
In-Reply-To: <25D91B29-C48A-4A49-B793-2843B2C6173D@secure64.com>
References: <25D91B29-C48A-4A49-B793-2843B2C6173D@secure64.com>
Message-ID: <CAD6AjGRHcAH7PNHiE-YV_GysVpx3hJtKkm=-kRr4_RGhTLExnA@mail.gmail.com>

On Sep 20, 2011 7:54 PM, "Joseph Gersch" <joe.gersch at secure64.com> wrote:
>
> Does anyone know if Akamai edgesuite servers rate limits or blacklists
caching servers that query it too often?  It appears that queries are timing
out if we exceed a query load to edgesuite.
>
>  Does anyone at Akamai know if there are any changes to rate limiting or
an abnormally high load?
>
>

Akamai traffic is dropping on my network now.

Emailed their noc, no eta on fix

Cb
>
> Joseph Gersch
> Chief Operating Officer
> Secure64 Software Corporation
>
>
>

From paul4004 at gmail.com  Wed Sep 21 00:25:27 2011
From: paul4004 at gmail.com (PC)
Date: Tue, 20 Sep 2011 23:25:27 -0600
Subject: Internet mauled by bears
In-Reply-To: <4E789FFE.9050702@thebaughers.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com> <4E789FFE.9050702@thebaughers.com>
Message-ID: <CAJAdsDkLKrMhmPqzb6Lbc-7THpRwkDjnOUjP3B0O4yRsU_wE_Q@mail.gmail.com>

On the other hand, I've been told that during a power outage cattle can
sometimes "smell" that the electricity is gone... all their noses start
sniffing after one in the pasture starts... and make a run for it...
Probably is an old wives tale...

Yeah, Sheep or Goat proof fence?  Good luck.  Here they just let them roam
and the sheep herders follow them... until they bring them out of the
mountains for the winter.

On Tue, Sep 20, 2011 at 8:15 AM, Jason Baugher <jason at thebaughers.com>wrote:

> On 9/20/2011 2:37 AM, Joel jaeggli wrote:
>
>> On 9/19/11 18:49 , Richard Barnes wrote:
>>
>>> And if they turn up the voltage on the fence high enough, dinner could be
>>> cooked by the time the crew gets there!
>>>
>> montana experience says:
>>
>> cows have rather thick skin, sheep come with insulation, and bison will
>> go through anything that gets in their way including 3 x 6" diameter
>> corner posts and 4 strands of barbed and 2 hot wires.
>>
>> horses on the other hand are pansies.
>>
>> livestock always ends up on the other side of the fence...
>>
> In Illinois:
>
> Cows actually train to electric fence (hot wire) fairly well. They don't
> like being shocked too much. Once they get used to the fence, you can shut
> it off and they'll stay in for weeks because they won't even attempt it.
> That said, sometimes you get a cow that just really wants to be difficult
> and will go through anything. That cow is suddenly turned into hamburger.
>
> Pigs also train to electric fence well. As tough as their hide is, it
> shocks well.
>
> Sheep are difficult. Other than when they are recently sheared, they have a
> natural protection across 95% of their body. Unless it hits them in the head
> or lower leg, they aren't going to feel it. Even when sheared, they are a
> very stubborn animal. I've seen them standing facing a fence, swaying
> forward and backward, almost like they're trying to time the shock pulse.
> Then they go on through and tear up the wire and posts in the process. I've
> seen 4 strands of wire spaced about 10 inches apart and they won't stay in.
>
> Horses are okay, but you have to tie things to the wire so they can see it.
> They're too dumb to remember where it is, apparently.
>
> There is a big range of fence boxes. Some have a long pulse that isn't too
> "hot". If you hold one of these, they make your hand and arm muscles clench
> up but they don't hurt too much. The other end of the range have a short
> "hot" pulse that will jump a good distance and will burn through green
> weeds. These hurt.
>
>  On Sep 19, 2011 9:34 PM, "Suresh Ramasubramanian"<ops.lists@**gmail.com<ops.lists at gmail.com>
>>> >
>>> wrote:
>>>
>>> On Tue, Sep 20, 2011 at 12:20 AM, John van Oppen
>>> <jvanoppen at spectrumnet.us>  wrote:
>>>
>>>> We had a cow br...
>>>>
>>> Your crews turning up there the next time a cow tries its luck are
>>> guaranteed a steak dinner then.
>>>
>>>
>>>
>>
>>
>
>

From paul4004 at gmail.com  Wed Sep 21 00:35:25 2011
From: paul4004 at gmail.com (PC)
Date: Tue, 20 Sep 2011 23:35:25 -0600
Subject: Internet mauled by bears
In-Reply-To: <CAJAdsDkLKrMhmPqzb6Lbc-7THpRwkDjnOUjP3B0O4yRsU_wE_Q@mail.gmail.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com> <4E789FFE.9050702@thebaughers.com>
 <CAJAdsDkLKrMhmPqzb6Lbc-7THpRwkDjnOUjP3B0O4yRsU_wE_Q@mail.gmail.com>
Message-ID: <CAJAdsDnEe2A7+zi5=gDCzf-UQ9gCXGsYjpVAaDpcp_913XTwRg@mail.gmail.com>

One more problem:  Many of these rural mountain "small" WISP towers (such as
Idaho from this article), do not have electricity.  Winter access is via
snow machine, snow-shoe, or helicopter, -- and power is obtained via solar
panels and batteries.  They are often placed on forest service or BLM land,
or other private property leases without facilities.

On Tue, Sep 20, 2011 at 11:25 PM, PC <paul4004 at gmail.com> wrote:

> On the other hand, I've been told that during a power outage cattle can
> sometimes "smell" that the electricity is gone... all their noses start
> sniffing after one in the pasture starts... and make a run for it...
> Probably is an old wives tale...
>
> Yeah, Sheep or Goat proof fence?  Good luck.  Here they just let them roam
> and the sheep herders follow them... until they bring them out of the
> mountains for the winter.
>
>
> On Tue, Sep 20, 2011 at 8:15 AM, Jason Baugher <jason at thebaughers.com>wrote:
>
>> On 9/20/2011 2:37 AM, Joel jaeggli wrote:
>>
>>> On 9/19/11 18:49 , Richard Barnes wrote:
>>>
>>>> And if they turn up the voltage on the fence high enough, dinner could
>>>> be
>>>> cooked by the time the crew gets there!
>>>>
>>> montana experience says:
>>>
>>> cows have rather thick skin, sheep come with insulation, and bison will
>>> go through anything that gets in their way including 3 x 6" diameter
>>> corner posts and 4 strands of barbed and 2 hot wires.
>>>
>>> horses on the other hand are pansies.
>>>
>>> livestock always ends up on the other side of the fence...
>>>
>> In Illinois:
>>
>> Cows actually train to electric fence (hot wire) fairly well. They don't
>> like being shocked too much. Once they get used to the fence, you can shut
>> it off and they'll stay in for weeks because they won't even attempt it.
>> That said, sometimes you get a cow that just really wants to be difficult
>> and will go through anything. That cow is suddenly turned into hamburger.
>>
>> Pigs also train to electric fence well. As tough as their hide is, it
>> shocks well.
>>
>> Sheep are difficult. Other than when they are recently sheared, they have
>> a natural protection across 95% of their body. Unless it hits them in the
>> head or lower leg, they aren't going to feel it. Even when sheared, they are
>> a very stubborn animal. I've seen them standing facing a fence, swaying
>> forward and backward, almost like they're trying to time the shock pulse.
>> Then they go on through and tear up the wire and posts in the process. I've
>> seen 4 strands of wire spaced about 10 inches apart and they won't stay in.
>>
>> Horses are okay, but you have to tie things to the wire so they can see
>> it. They're too dumb to remember where it is, apparently.
>>
>> There is a big range of fence boxes. Some have a long pulse that isn't too
>> "hot". If you hold one of these, they make your hand and arm muscles clench
>> up but they don't hurt too much. The other end of the range have a short
>> "hot" pulse that will jump a good distance and will burn through green
>> weeds. These hurt.
>>
>>  On Sep 19, 2011 9:34 PM, "Suresh Ramasubramanian"<ops.lists@**gmail.com<ops.lists at gmail.com>
>>>> >
>>>> wrote:
>>>>
>>>> On Tue, Sep 20, 2011 at 12:20 AM, John van Oppen
>>>> <jvanoppen at spectrumnet.us>  wrote:
>>>>
>>>>> We had a cow br...
>>>>>
>>>> Your crews turning up there the next time a cow tries its luck are
>>>> guaranteed a steak dinner then.
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

From mjp16 at ieee.uow.edu.au  Wed Sep 21 02:49:57 2011
From: mjp16 at ieee.uow.edu.au (mjp16 at ieee.uow.edu.au)
Date: Wed, 21 Sep 2011 14:49:57 +0700
Subject: No subject
Message-ID: <mailman.38.1316591404.1870.nanog@nanog.org>

Your message was not delivered due to the following reason:

Your message was not delivered because the destination server was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message was not delivered within 5 days:
Host 86.112.1.86 is not responding.

The following recipients could not receive this message:
<nanog at nanog.org>

Please reply to postmaster at ieee.uow.edu.au
if you feel this message to be in error.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: text.zip
Type: application/octet-stream
Size: 29206 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110921/71851a79/attachment.obj>

From julien at gormotte.info  Wed Sep 21 03:36:25 2011
From: julien at gormotte.info (Julien Gormotte)
Date: Wed, 21 Sep 2011 10:36:25 +0200
Subject: How to begin making my own ISP?
In-Reply-To: <4E7927DC.3000604@bowenvale.co.nz>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
 <4E7927DC.3000604@bowenvale.co.nz>
Message-ID: <4E79A209.4030801@gormotte.info>

Hello,

If you are able to read french, there are useful informations :

the fai-locaux mailing list archives :
https://lists.fdn.fr/wws

A series of posts on this blog :
http://blog.spyou.org/wordpress-mu/2010/06/09/comment-devenir-son-propre-fai-1-la-theorie/
http://blog.spyou.org/wordpress-mu/2010/06/10/comment-devenir-son-propre-fai-2-la-base/
http://blog.spyou.org/wordpress-mu/2010/06/15/comment-devenir-son-propre-fai-3-interconnexion/
http://blog.spyou.org/wordpress-mu/2010/08/02/comment-devenir-son-propre-fai-4-administratif/
http://blog.spyou.org/wordpress-mu/2010/08/09/comment-devenir-son-propre-fai-5-le-tres-haut-debit/
http://blog.spyou.org/wordpress-mu/2010/08/14/comment-devenir-son-propre-fai-6-cas-pratique/
http://blog.spyou.org/wordpress-mu/2010/08/17/comment-devenir-son-propre-fai-7-securite/
http://blog.spyou.org/wordpress-mu/2010/08/17/comment-devenir-son-propre-fai-8-services/
http://blog.spyou.org/wordpress-mu/2010/08/19/comment-devenir-son-propre-fai-9-cas-concret/

Some informations are france-specific (in regards of law, etc...), but 
it can be useful.
A lot of informations about ISP creation has been discussed lately, 
because FDN, a french association that is the oldest ISP still active in 
france, decided to create (with other associations) a "federation" to 
help the creation of new associative isps. You can see the FDN website 
(http://www.fdn.fr/)

Le 21/09/2011 01:55, Don Gould a ?crit :
> Hasserw,
>
> First I must apologise for not responding, I did see this message and 
> did mean to attempt to help you out as I am currently working though 
> this exact process in a very small proof of concept network with an 
> even smaller budget.
>
> To address our question, a good starting point is a Cisco CCNA.
>
> If you review the list archive for the past month you will find a very 
> interesting thread linking to guys who are running massive home 
> networks just for their learning, that in turn will link you to 
> detailed public CVs showing the sort of stuff that these guys are 
> trained and training in.
>
> You also need some business training to understand how to structure 
> the business aspects of your project.  An MBA is a good qualification 
> but there are many less high level courses you could look at as well.
>
> NA Nog is an operational list (with a lot of rant and fun stuff) and 
> not really a business focused or educational list, so your initial 
> query simply ran under the radar.
>
> D
>
>
> On 17/09/2011 6:10 a.m., hasserw at hushmail.com wrote:
>> No one replied with any useful information. I guess no one wants
>> competition on this list? Pretty poor tactic.
>>
>> On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
>>> I want to begin making my own ISP, mainly for high speed servers
>>> and such, but also branching out to residential customers. I'm
>>> going to be in Germany for the next school year (probably either
>>> Frankfurt am Main or Berlin); any suggestions on what sort of
>>> classes I can take there that will be in English and will teach me
>>>
>>> all I need to know on how to build and manage my own ISP, AS, etc?
>>>
>>> Thanks.
>>
>>
>



From kate at quadranet.com  Wed Sep 21 07:39:26 2011
From: kate at quadranet.com (Kate Gerry)
Date: Wed, 21 Sep 2011 05:39:26 -0700
Subject: RADB/RIR Scraper
Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>

I'm looking for a good utility that I can run locally to scrape RADB, ARIN, other RIRs to add to my or customer prefix lists... Anybody have a good tool for this? I currently end up visiting https://www.dan.me.uk/filtergen and creating one off that.

Thoughts?

--
Kate
QuadraNet, Inc
530 W 6th Street #901
Los Angeles, CA 90014
kate at quadranet.com<mailto:kate at quadranet.com>


From kate at quadranet.com  Wed Sep 21 07:40:14 2011
From: kate at quadranet.com (Kate Gerry)
Date: Wed, 21 Sep 2011 05:40:14 -0700
Subject: RADB/RIR Scraper
In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D98A0@EXCH>

Crap! Sorry about that, I sent the post as an HTML message. :(

--
Kate
QuadraNet, Inc
530 W 6th Street #901
Los Angeles, CA 90014
kate at quadranet.com

From: Kate Gerry 
Sent: Wednesday, September 21, 2011 5:39 AM
To: nanog at nanog.org
Cc: Kate Gerry
Subject: RADB/RIR Scraper

I'm looking for a good utility that I can run locally to scrape RADB, ARIN, other RIRs to add to my or customer prefix lists... Anybody have a good tool for this? I currently end up visiting https://www.dan.me.uk/filtergen and creating one off that.

Thoughts?

--
Kate
QuadraNet, Inc
530 W 6th Street #901
Los Angeles, CA 90014
kate at quadranet.com



From greg at bestnet.kharkov.ua  Wed Sep 21 07:54:23 2011
From: greg at bestnet.kharkov.ua (Gregory Edigarov)
Date: Wed, 21 Sep 2011 15:54:23 +0300
Subject: RADB/RIR Scraper
In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D98A0@EXCH>
References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
 <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D98A0@EXCH>
Message-ID: <20110921155423.7b9a917f@greg.bestnet.kharkov.ua>

here is mine:

#!/bin/sh


echo "-i origin $1" |nc whois.radb.net 43


On Wed, 21 Sep 2011 05:40:14 -0700
Kate Gerry <kate at quadranet.com> wrote:

> Crap! Sorry about that, I sent the post as an HTML message. :(
> 
> --
> Kate
> QuadraNet, Inc
> 530 W 6th Street #901
> Los Angeles, CA 90014
> kate at quadranet.com
> 
> From: Kate Gerry 
> Sent: Wednesday, September 21, 2011 5:39 AM
> To: nanog at nanog.org
> Cc: Kate Gerry
> Subject: RADB/RIR Scraper
> 
> I'm looking for a good utility that I can run locally to scrape RADB,
> ARIN, other RIRs to add to my or customer prefix lists... Anybody
> have a good tool for this? I currently end up visiting
> https://www.dan.me.uk/filtergen and creating one off that.
> 
> Thoughts?
> 
> --
> Kate
> QuadraNet, Inc
> 530 W 6th Street #901
> Los Angeles, CA 90014
> kate at quadranet.com
> 
> 


From nick at foobar.org  Wed Sep 21 08:01:56 2011
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 21 Sep 2011 14:01:56 +0100
Subject: RADB/RIR Scraper
In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
Message-ID: <4E79E044.2010202@foobar.org>

On 21/09/2011 13:39, Kate Gerry wrote:
> I'm looking for a good utility that I can run locally to scrape RADB,
> ARIN, other RIRs to add to my or customer prefix lists... Anybody have a
> good tool for this? I currently end up visiting
> https://www.dan.me.uk/filtergen and creating one off that.

there is irrtoolset.  If you can get beyond the unfriendly user interface,
it will do all sorts of interesting things, including generating prefix
lists in both cisco and juniper format.

http://irrtoolset.isc.org/

Lots of people don't like irrtoolset, mostly for very good reasons.
However for either very simple or very complicated stuff, it can be quite
useful.

Nick


From morrowc.lists at gmail.com  Wed Sep 21 08:56:03 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 21 Sep 2011 09:56:03 -0400
Subject: RADB/RIR Scraper
In-Reply-To: <4E79E044.2010202@foobar.org>
References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
 <4E79E044.2010202@foobar.org>
Message-ID: <CAL9jLaYD2G7kXsnHb1Q7iu+L0Omj74DO=9TzLjr_iBjFuw+Gtw@mail.gmail.com>

<http://www.nanog.org/meetings/nanog36/presentations/steenbergen.pdf>

has some pointers to tools Richard wrote (and presented a few times
now) at nanog meetings.
(to save you reading the pdf... which is a good read:
<http://irrpt.sourceforge.net/>

On Wed, Sep 21, 2011 at 9:01 AM, Nick Hilliard <nick at foobar.org> wrote:
> On 21/09/2011 13:39, Kate Gerry wrote:
>> I'm looking for a good utility that I can run locally to scrape RADB,
>> ARIN, other RIRs to add to my or customer prefix lists... Anybody have a
>> good tool for this? I currently end up visiting
>> https://www.dan.me.uk/filtergen and creating one off that.
>
> there is irrtoolset. ?If you can get beyond the unfriendly user interface,
> it will do all sorts of interesting things, including generating prefix
> lists in both cisco and juniper format.
>
> http://irrtoolset.isc.org/
>
> Lots of people don't like irrtoolset, mostly for very good reasons.
> However for either very simple or very complicated stuff, it can be quite
> useful.
>
> Nick
>
>


From nick at foobar.org  Wed Sep 21 09:08:21 2011
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 21 Sep 2011 15:08:21 +0100
Subject: RADB/RIR Scraper
In-Reply-To: <CAL9jLaYD2G7kXsnHb1Q7iu+L0Omj74DO=9TzLjr_iBjFuw+Gtw@mail.gmail.com>
References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
 <4E79E044.2010202@foobar.org>
 <CAL9jLaYD2G7kXsnHb1Q7iu+L0Omj74DO=9TzLjr_iBjFuw+Gtw@mail.gmail.com>
Message-ID: <4E79EFD5.10804@foobar.org>

On 21/09/2011 14:56, Christopher Morrow wrote:
> <http://www.nanog.org/meetings/nanog36/presentations/steenbergen.pdf>
> 
> has some pointers to tools Richard wrote (and presented a few times
> now) at nanog meetings.
> (to save you reading the pdf... which is a good read:
> <http://irrpt.sourceforge.net/>

There's also Marco D'Itri's rpsltool:

http://www.linux.it/~md/software/

Of the two, I prefer rpsltool (sorry ras!) - its templating facilities are
better.  It's also written in perl which tends to be better for text
processing.  PHP is a pain for text processing.

Although both of these these tools are very good, neither of them
implements anything near a complete RPSL parser, which is why I made my
earlier command about the usefulness of irrtoolset for certain types of
user.  If you just want basic stuff, irrtoolset will probably do what you
want out of the box.  If you want moderately complicated stuff, you may run
into irritating limitations in irrtoolset's rtconfig command.  However, if
you want to do really complicated stuff, then it's the only code-base out
there which implements an almost complete RPSL implementation.  And there
is a small number of organisations out there who use irrtoolset to its
fullest capabilities.

Nick


From hannes at stressinduktion.org  Wed Sep 21 09:09:40 2011
From: hannes at stressinduktion.org (Hannes Frederic Sowa)
Date: Wed, 21 Sep 2011 16:09:40 +0200
Subject: RADB/RIR Scraper
In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
Message-ID: <20110921140940.GG24609@order.stressinduktion.org>

On Wed, Sep 21, 2011 at 05:39:26AM -0700, Kate Gerry wrote:
> I'm looking for a good utility that I can run locally to scrape RADB, ARIN, other RIRs to add to my or customer prefix lists... Anybody have a good tool for this? I currently end up visiting https://www.dan.me.uk/filtergen and creating one off that.
> 
> Thoughts?

<http://www.lexa.ru/snar/bgpq/index_en.html>

or you could have alook at

| whois -h filtergen.level3.com -- help

if you get blocked by whois rate limiting.

Greetings,

  Hannes



From hannes at stressinduktion.org  Wed Sep 21 09:32:43 2011
From: hannes at stressinduktion.org (Hannes Frederic Sowa)
Date: Wed, 21 Sep 2011 16:32:43 +0200
Subject: RADB/RIR Scraper
In-Reply-To: <20110921140940.GG24609@order.stressinduktion.org>
References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
 <20110921140940.GG24609@order.stressinduktion.org>
Message-ID: <20110921143243.GB29303@order.stressinduktion.org>

On Wed, Sep 21, 2011 at 04:09:40PM +0200, Hannes Frederic Sowa wrote:
> <http://www.lexa.ru/snar/bgpq/index_en.html>

The url above links to the predecessor project. The code that I actually use
is available here:

  <http://snar.spb.ru/prog/bgpq3/>

Greetings,

  Hannes



From randy at psg.com  Wed Sep 21 10:22:01 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 21 Sep 2011 17:22:01 +0200
Subject: RADB/RIR Scraper
In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
Message-ID: <m2vcslrkdi.wl%randy@psg.com>

peval()


From betty at newnog.org  Wed Sep 21 10:59:50 2011
From: betty at newnog.org (Betty Burke)
Date: Wed, 21 Sep 2011 11:59:50 -0400
Subject: [NANOG-announce] NANOG 53 Update
Message-ID: <CABhExiyFLyC4FOHZtTVuihVF-ahBk4dHcoVpUAGfc+vgnJDSWw@mail.gmail.com>

Colleagues:

A short NANOG 53 reminder and update. NANOG 53 will be held in Philadelphia,
PA on* October 9-12, 2011*.  NANOG 53 will begin with tutorials starting
early Sunday afternoon, October 9th. The meeting will adjourn approximately
12 noon on Wednesday, October 12th.

Thank you to our NANOG 53 Speakers and to the NANOG Program Committee.
 Attendees are sure to enjoy another fantastic program.  The posted agenda
continues to be updated, however, the NANOG 53 program is expected to remain
as posted!  Do not delay, register for NANOG 53 now as the* registration
rate will increase on October 4, 2011.*
http://www.nanog.org/meetings/nanog53/agenda.html
http://www.nanog.org/meetings/nanog53/nanog53_registration.html


Please note the Loews Philadelphia *Hotel Group Rate Expires on September
23, 2011*.  Make your reservation as soon as possible.
http://www.nanog.org/meetings/nanog53/hotel.php

In addition to a wonderful program, attendees will be treated to our famous
"Sponsor Socials".  NANOG 53 Attendees will have ample social networking
opportunities during each day and through out the evening.  Philadelphia is
a wonderful place to visit and NANOG is grateful to our host, Comcast, for
the opportunity to return to the City of Brotherly Love.  Make sure to join
us and be a part of the NANOG experience.

Should you have any questions or concerns regarding your reservation, the
hotel, or NANOG 53 in general, please be sure to send a note to *
nanog-support at nanog.org or phone us at +1 510 492 4030.*


Betty

Betty Burke
NewNOG/NANOG Executive Director
Office (810) 214-1218
-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

From zeusdadog at gmail.com  Wed Sep 21 11:38:34 2011
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Wed, 21 Sep 2011 12:38:34 -0400
Subject: Anyone used Adtran NetVanta 1544?
Message-ID: <CADs2+OHx4X+_S=nCByWDum23-0FYzHYFcZZ+CHtXpeqB04-mKQ@mail.gmail.com>

Has anyone have experience using Adtran NetVanta 1544 as a iSCSI SAN
switch?  Or any Adtran switch in general?  Any problems or unexpected
issues?

Thanks!


From ask at develooper.com  Wed Sep 21 12:28:40 2011
From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=)
Date: Wed, 21 Sep 2011 10:28:40 -0700
Subject: vyatta for bgp
In-Reply-To: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
Message-ID: <EF1E7686-0BF8-4349-AB90-1067FB8C6731@develooper.com>


On Sep 12, 2011, at 11:42, Ben Albee wrote:

> Does anybody currently use vyatta as a bgp router for their company? If
> so have you ran into any problems with using that instead of a cisco or
> juniper router?

We're using Vyatta for a handful of fast ethernet links to the internet, with I think about three dozen BGP peers.  (Mix of IPv4 and IPv6; about four full feeds on each protocol, the rest is peering).  It's not as mature or polished as I understand some of the Cisco or Juniper platforms are; but on our small scale it's fine.

We have a decent amount of of Linux expertise in the office (and virtually zero for Juniper/Cisco/...), so having more familiar tools on the routers is nice.

As a small shop it's also convenient that the boxes are cheap (so we can have two hot ones with VRRP etc and cheaply a third cold spare) and that the spare parts etc are the same or similar to the rest of the boxes in the rack.


 - ask

-- 
http://askask.com/

From walter.keen at rainierconnect.net  Wed Sep 21 12:44:44 2011
From: walter.keen at rainierconnect.net (Walter Keen)
Date: Wed, 21 Sep 2011 10:44:44 -0700
Subject: Anyone used Adtran NetVanta 1544?
In-Reply-To: <CADs2+OHx4X+_S=nCByWDum23-0FYzHYFcZZ+CHtXpeqB04-mKQ@mail.gmail.com>
References: <CADs2+OHx4X+_S=nCByWDum23-0FYzHYFcZZ+CHtXpeqB04-mKQ@mail.gmail.com>
Message-ID: <4E7A228C.3050500@rainierconnect.net>

I've used Adtran ethernet switches.  I wouldn't call them feature-rich, 
but they do seem to work.  If possible test thouroughly before putting 
in production.  I've seen some layer 3 issues with them that they 
quickly fixed in subsequent firmware releases.  I was not stress testing 
them with traffic however.


On 09/21/2011 09:38 AM, Jay Nakamura wrote:
> Has anyone have experience using Adtran NetVanta 1544 as a iSCSI SAN
> switch?  Or any Adtran switch in general?  Any problems or unexpected
> issues?
>
> Thanks!
>


From ren.provo at gmail.com  Wed Sep 21 13:11:36 2011
From: ren.provo at gmail.com (Ren Provo)
Date: Wed, 21 Sep 2011 14:11:36 -0400
Subject: Fwd: [NANOG-announce] NANOG 53 Update
In-Reply-To: <CAG5ReHfMT6mbGDHNe5pttUPqz73qj0dWFCU2fk49VMZKZ++U=Q@mail.gmail.com>
References: <CABhExiyFLyC4FOHZtTVuihVF-ahBk4dHcoVpUAGfc+vgnJDSWw@mail.gmail.com>
 <CAG5ReHfMT6mbGDHNe5pttUPqz73qj0dWFCU2fk49VMZKZ++U=Q@mail.gmail.com>
Message-ID: <CAG5ReHdrvKkSQF9eF=F-g+yx4gtiw1GjDXrzzpT7QVEi6vKWoA@mail.gmail.com>

Thanks for the reminder Betty!

Comcast is hosting a social on Sunday night, October 9th, from
6:30-9:30pm on the 43rd floor at Comcast Center.

NANOG and ARIN participants, registered by Wednesday the 5th of
October, will be on the guest list with security in the lobby. ?Late
registrants will need to work with security onsite so please register
early instead. ?Photo ID will be required for all participants to
proceed from the lobby to the 43rd floor.

A pair of trolley cars will make an optional continuous loop between
the Loews Hotel and Comcast Center. ?The stroll is about a half a mile
/ 15 minutes with Philadelphia City Hall at the mid-spot.

https://www.arin.net/participate/meetings/ARIN-XXVIII/social.html has
details as well.

We look forward to a great night in Philly to kick-off the week.

Cheers, -ren

On Wed, Sep 21, 2011 at 11:59 AM, Betty Burke <betty at newnog.org> wrote:
> Colleagues:
>
> A short NANOG 53 reminder and update. NANOG 53 will be held in Philadelphia,
> PA on* October 9-12, 2011*. ?NANOG 53 will begin with tutorials starting
> early Sunday afternoon, October 9th. The meeting will adjourn approximately
> 12 noon on Wednesday, October 12th.
>
> Thank you to our NANOG 53 Speakers and to the NANOG Program Committee.
> ?Attendees are sure to enjoy another fantastic program. ?The posted agenda
> continues to be updated, however, the NANOG 53 program is expected to remain
> as posted! ?Do not delay, register for NANOG 53 now as the* registration
> rate will increase on October 4, 2011.*
> http://www.nanog.org/meetings/nanog53/agenda.html
> http://www.nanog.org/meetings/nanog53/nanog53_registration.html
>
>
> Please note the Loews Philadelphia *Hotel Group Rate Expires on September
> 23, 2011*. ?Make your reservation as soon as possible.
> http://www.nanog.org/meetings/nanog53/hotel.php
>
> In addition to a wonderful program, attendees will be treated to our famous
> "Sponsor Socials". ?NANOG 53 Attendees will have ample social networking
> opportunities during each day and through out the evening. ?Philadelphia is
> a wonderful place to visit and NANOG is grateful to our host, Comcast, for
> the opportunity to return to the City of Brotherly Love. ?Make sure to join
> us and be a part of the NANOG experience.
>
> Should you have any questions or concerns regarding your reservation, the
> hotel, or NANOG 53 in general, please be sure to send a note to *
> nanog-support at nanog.org or phone us at +1 510 492 4030.*
>
>
> Betty
>
> Betty Burke
> NewNOG/NANOG Executive Director
> Office (810) 214-1218
>
> _______________________________________________
> NANOG-announce mailing list
> NANOG-announce at nanog.org
> https://mailman.nanog.org/mailman/listinfo/nanog-announce
>


From keegan.holley at sungard.com  Wed Sep 21 14:11:29 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 21 Sep 2011 15:11:29 -0400
Subject: What's a reasonable attack surface? (was: Re: wet-behind-the-ears
 whippersnapper yada yada)
In-Reply-To: <13512334.2529.1316567470873.JavaMail.root@benjamin.baylink.com>
References: <23249.1316552835@turing-police.cc.vt.edu>
 <13512334.2529.1316567470873.JavaMail.root@benjamin.baylink.com>
Message-ID: <CABO8Q6T0nqv90j0Y9xch1Wu8FGx+9kpX3CJeO80RBO_OkQKAuw@mail.gmail.com>

I think people tend to go overboard in the planning phases for something
like this.  I remember rumors of a certain large ISP getting along fine for
several years installing routers with a password like "getsmein".  There are
plenty of groups that publish guidelines on ISP configuration as well as a
wealth of books on the subject.  You'll just have to start out with the
basics and learn as you go.  I'm not sure you can get a magic bullet from a
mailing list though.

2011/9/20 Jay Ashworth <jra at baylink.com>

> ----- Original Message -----
> > From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>
>
> > As long as there is *A* failure mode? Hmm. <invents a movie-plot failure
> mode
> > involving crazed ninjas with katanas loose in a switch room at one
> provider>.
> > Yep, it's unlikely crazed ninjas will attack the switch rooms at both
> > providers.
>
> I too am a Schneier fan.  But terrorists watch movies, too.
>
> Cheers,
> -- jr 'Once is happenstance...' a
> --
> 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      http://photo.imageinc.us             +1 727 647
> 1274
>
>
>

From blake at pfankuch.me  Wed Sep 21 14:16:19 2011
From: blake at pfankuch.me (Blake T. Pfankuch)
Date: Wed, 21 Sep 2011 19:16:19 +0000
Subject: Anyone used Adtran NetVanta 1544?
In-Reply-To: <CADs2+OHx4X+_S=nCByWDum23-0FYzHYFcZZ+CHtXpeqB04-mKQ@mail.gmail.com>
References: <CADs2+OHx4X+_S=nCByWDum23-0FYzHYFcZZ+CHtXpeqB04-mKQ@mail.gmail.com>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C8436985D58@SHSBS.shenrons-house.local>

We use Adtran switches semi-frequently at work and I have a few pain points, but many good things about them.

My biggest complaint is the availability of support if you need something from them.  They operate under pseudo standard business hours which can be a deal breaker for some.  

Obviously AOS is very similar to IOS in the syntax which is a plus, minor little differences which drive you nuts when you switch back and forth with cisco and Adtran all day, however with some of the more advanced switching functions I find them a little lacking.  When we have used these for smaller VMware deployments we traditionally build port channels to the VMware hosts for the data connections, and the port channel load balance methods available are a little lacking. 

Past that I don't mind them one bit, and actually push for an Adtran over a low end HP/3Com web managed switch when the customer doesn't want to pony up for Cisco gear.  For the price you cant beat the configuration simplicity for the IOS aware people, and the webUI for end users is not that bad.  You can't completely mangle the switch config from webUI by mistake anymore which most would consider a bonus...
 
If you are looking at integrating multiple of these devices and building port channels between them, I would highly recommend manually specifying the spanning tree priority on the device.  6 months from now when you reboot a switch for an AOS upgrade it might come back up and you end up bringing down the entire network.  I've now seen the 3 times on production networks now which are pushing the limits of the SMB NetVanta switches imo.

"Show run verbose" will become a close friend :)  and make sure you document the crap out of everything you set up :)

Also make sure you are getting the G2 switches they are about 1000 times better than the G1 switches.  You can actually get 2 of these in 1u and either stack them or vrrp them for more seamless failover.  Feel free to ping me off list if you have more questions, I can outline some of the deployments we have used them for, issues I have seen on individual cases and where I have seen them work well.

Blake Pfankuch

-----Original Message-----
From: Jay Nakamura [mailto:zeusdadog at gmail.com] 
Sent: Wednesday, September 21, 2011 10:39 AM
To: NANOG
Subject: Anyone used Adtran NetVanta 1544?

Has anyone have experience using Adtran NetVanta 1544 as a iSCSI SAN switch?  Or any Adtran switch in general?  Any problems or unexpected issues?

Thanks!



From tad1214 at gmail.com  Wed Sep 21 15:07:56 2011
From: tad1214 at gmail.com (Thomas Donnelly)
Date: Wed, 21 Sep 2011 13:07:56 -0700
Subject: Anyone used Adtran NetVanta 1544?
In-Reply-To: <CADs2+OHx4X+_S=nCByWDum23-0FYzHYFcZZ+CHtXpeqB04-mKQ@mail.gmail.com>
References: <CADs2+OHx4X+_S=nCByWDum23-0FYzHYFcZZ+CHtXpeqB04-mKQ@mail.gmail.com>
Message-ID: <op.v16cvir6wjyiia@tw-mbp13-tdonnelly.local>

I have been a big fan of the Adtran gear for years for small businesses  
and remote offices. We used the NetVanta 1335 Poe - A IPSec capable Layer3  
Poe switch with a T1 wic in the back, all crammed into a 1U platform,  
isn't only hard to find among all vendors, it was cheap and we never had  
any reliability issues with them in about 20 remote offices.

Adtran to me has never been data center grade, but for an IT guy who wants  
a familiar command line and reliable "enterprise grade" switch on the  
cheap, you can't go wrong with Adtran.

I think with a iSCSI SAN you would be just fine. The specs on it look up  
to par and if their previous performance is telling of their current  
products, I think asking for a demo unit or picking just one up would be a  
great choice.

-=Tom


On Wed, 21 Sep 2011 09:38:34 -0700, Jay Nakamura <zeusdadog at gmail.com>  
wrote:

> Has anyone have experience using Adtran NetVanta 1544 as a iSCSI SAN
> switch?  Or any Adtran switch in general?  Any problems or unexpected
> issues?
>
> Thanks!
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


From nicotine at warningg.com  Wed Sep 21 15:12:49 2011
From: nicotine at warningg.com (Brandon Ewing)
Date: Wed, 21 Sep 2011 15:12:49 -0500
Subject: RADB/RIR Scraper
In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
Message-ID: <20110921201249.GC30658@radiological.warningg.com>

On Wed, Sep 21, 2011 at 05:39:26AM -0700, Kate Gerry wrote:
> I'm looking for a good utility that I can run locally to scrape RADB, ARIN, other RIRs to 
> add to my or customer prefix lists... Anybody have a good tool for this? I currently end 
> up visiting https://www.dan.me.uk/filtergen and creating one off that.

whois -h filtergen.level3.net

-- 
Brandon Ewing                                        (nicotine at warningg.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110921/6be9d1ca/attachment.bin>

From drew.linsalata at gmail.com  Wed Sep 21 16:49:10 2011
From: drew.linsalata at gmail.com (Drew Linsalata)
Date: Wed, 21 Sep 2011 17:49:10 -0400
Subject: Any Verizon routing folks listening?
Message-ID: <4772E25C-E658-45E4-BEAF-A336348C1A5D@gmail.com>


We're seeing complaints from VZ DSL customers in the NY area that are unable to exchange any IP traffic with mail hosts on multiple netblocks. Port independent. Sounds like auto- blacklisting run amok.

Off list contact welcomed and appreciated.
--

Sent from my iPhone



From Vinny_Abello at Dell.com  Wed Sep 21 16:57:18 2011
From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com)
Date: Wed, 21 Sep 2011 21:57:18 +0000
Subject: Internet mauled by bears
In-Reply-To: <CAJAdsDkLKrMhmPqzb6Lbc-7THpRwkDjnOUjP3B0O4yRsU_wE_Q@mail.gmail.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com> <4E789FFE.9050702@thebaughers.com>
 <CAJAdsDkLKrMhmPqzb6Lbc-7THpRwkDjnOUjP3B0O4yRsU_wE_Q@mail.gmail.com>
Message-ID: <FD9B2CB2B33E394FAE3B746695476057129E5CD8@DFWX10HMPTC05.AMER.DELL.COM>

I'd believe that regarding the cattle. 

When the company I used to work for years ago was focused more on residential services including dial-up, we had a customer who constantly complained about problems getting or staying connected to our dial-up service. When one of our techs was on the phone discussing the problem, he heard this steady ticking noise. When asked what that noise was, the customer told him it was interference from his electric fence for his cows. Long story short, the electric fence was causing all the noise on the phone line messing up his connection. Now the funny part is he found turning the fence off would improve his connectivity, but he said whenever he did that his cows would escape! So, there might be some truth to that. :)

-Vinny

-----Original Message-----
From: PC [mailto:paul4004 at gmail.com] 
Sent: Wednesday, September 21, 2011 1:25 AM
To: Jason Baugher
Cc: nanog at nanog.org
Subject: Re: Internet mauled by bears

On the other hand, I've been told that during a power outage cattle can
sometimes "smell" that the electricity is gone... all their noses start
sniffing after one in the pasture starts... and make a run for it...
Probably is an old wives tale...

Yeah, Sheep or Goat proof fence?  Good luck.  Here they just let them roam
and the sheep herders follow them... until they bring them out of the
mountains for the winter.

On Tue, Sep 20, 2011 at 8:15 AM, Jason Baugher <jason at thebaughers.com>wrote:

> On 9/20/2011 2:37 AM, Joel jaeggli wrote:
>
>> On 9/19/11 18:49 , Richard Barnes wrote:
>>
>>> And if they turn up the voltage on the fence high enough, dinner could be
>>> cooked by the time the crew gets there!
>>>
>> montana experience says:
>>
>> cows have rather thick skin, sheep come with insulation, and bison will
>> go through anything that gets in their way including 3 x 6" diameter
>> corner posts and 4 strands of barbed and 2 hot wires.
>>
>> horses on the other hand are pansies.
>>
>> livestock always ends up on the other side of the fence...
>>
> In Illinois:
>
> Cows actually train to electric fence (hot wire) fairly well. They don't
> like being shocked too much. Once they get used to the fence, you can shut
> it off and they'll stay in for weeks because they won't even attempt it.
> That said, sometimes you get a cow that just really wants to be difficult
> and will go through anything. That cow is suddenly turned into hamburger.
>
> Pigs also train to electric fence well. As tough as their hide is, it
> shocks well.
>
> Sheep are difficult. Other than when they are recently sheared, they have a
> natural protection across 95% of their body. Unless it hits them in the head
> or lower leg, they aren't going to feel it. Even when sheared, they are a
> very stubborn animal. I've seen them standing facing a fence, swaying
> forward and backward, almost like they're trying to time the shock pulse.
> Then they go on through and tear up the wire and posts in the process. I've
> seen 4 strands of wire spaced about 10 inches apart and they won't stay in.
>
> Horses are okay, but you have to tie things to the wire so they can see it.
> They're too dumb to remember where it is, apparently.
>
> There is a big range of fence boxes. Some have a long pulse that isn't too
> "hot". If you hold one of these, they make your hand and arm muscles clench
> up but they don't hurt too much. The other end of the range have a short
> "hot" pulse that will jump a good distance and will burn through green
> weeds. These hurt.
>
>  On Sep 19, 2011 9:34 PM, "Suresh Ramasubramanian"<ops.lists@**gmail.com<ops.lists at gmail.com>
>>> >
>>> wrote:
>>>
>>> On Tue, Sep 20, 2011 at 12:20 AM, John van Oppen
>>> <jvanoppen at spectrumnet.us>  wrote:
>>>
>>>> We had a cow br...
>>>>
>>> Your crews turning up there the next time a cow tries its luck are
>>> guaranteed a steak dinner then.
>>>
>>>
>>>
>>
>>
>
>


From packetjockey at gmail.com  Wed Sep 21 17:06:59 2011
From: packetjockey at gmail.com (Rafael Rodriguez)
Date: Wed, 21 Sep 2011 18:06:59 -0400
Subject: RADB/RIR Scraper
In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
References: <4B4120B1642DCF48ACA84E4F82C8E1F66B5D3D989F@EXCH>
Message-ID: <5A5B0B42-2BE8-4B4D-B98D-4422571E5A55@gmail.com>

I've yet to use this myself but it looks like what you are looking for.

bgpq3

http://snar.spb.ru/prog/bgpq3/bgpq3-0.1.7.html

Sent from my iPhone

On Sep 21, 2011, at 8:39, Kate Gerry <kate at quadranet.com> wrote:

> I'm looking for a good utility that I can run locally to scrape RADB, ARIN, other RIRs to add to my or customer prefix lists... Anybody have a good tool for this? I currently end up visiting https://www.dan.me.uk/filtergen and creating one off that.
> 
> Thoughts?
> 
> --
> Kate
> QuadraNet, Inc
> 530 W 6th Street #901
> Los Angeles, CA 90014
> kate at quadranet.com<mailto:kate at quadranet.com>
> 


From andreas at livejournalinc.com  Wed Sep 21 18:14:26 2011
From: andreas at livejournalinc.com (Andreas Echavez)
Date: Wed, 21 Sep 2011 16:14:26 -0700
Subject: vyatta for bgp
In-Reply-To: <4E7202C4.9050502@pubnix.net>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
 <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
 <4E7202C4.9050502@pubnix.net>
Message-ID: <CAJ0Nkqi14_JxxOPOG0_ZcNhXo7BD=WjpOb14evzD2Z2AyXGCMA@mail.gmail.com>

I'll chime in,

In an enterprise environment, I've worked with software routers as well as
hardware beasts (ala Junipers, Cisco 6500s, ASAs, and more).

Ultimately, the network is as reliable as you build it. With software, it's
much cheaper to divide and scale horizontally. Hardware devices are
expensive and usually horizontal scalability never happens. So in reality,
an enterprise blows 100k on two routers, they both flop because of some
"firmware bug", and you're down.

The most reliable/cost effective solution is the cheap and redundant
approach to architecture.

Reliable hardware is incredibly inexpensive, and every year we get better
CPUs and (recently) GPUs that are providing APIs and interfaces to their
incredible parallel processing capability.

btw, you guys might find
PacketShader<http://shader.kaist.edu/packetshader/>a pretty
interesting concept

-Andreas

On Thu, Sep 15, 2011 at 6:51 AM, Alain Hebert <ahebert at pubnix.net> wrote:

>     Hi,
>
>    As usual this end-up in what people prefer.
>
>    Vyatta is as good as the hardware it runs on, the backend they use and
> the people configuring/maintaining it.
>
>    The nature of ASIC make it more reliable than a multi-purpose device
> (aka server) running an OS written for it.
>
>    It end up being a choice between risk and cost and being that you can
> get your hand on second hand iron for cheap these days...
>
>    Why risk it.
>
>
> -----
> Alain Hebert                                ahebert at pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443
>
>
> On 09/15/11 09:05, Ray Soucy wrote:
>
>> Is Vyatta really not suited for the task?
>>
>> I keep checking up on it and holding off looking into it as they don't
>> support multicast yet.
>>
>> Modern commodity sever hardware these days often out-powers big iron
>> enough to make up for not using ASICs, though, at least on the lower
>> end of the spectrum.
>>
>> Does anyone have any more details on Vyatta not scaling?  Were you
>> trying to run it as a VM?  What were you using for NICs? etc.
>>
>> The hardware matters.  Saying Vyatta doesn't cut it could mean anything...
>>
>> On Tue, Sep 13, 2011 at 7:36 PM, Dobbins, Roland<rdobbins at arbor.net>
>>  wrote:
>>
>>> On Sep 14, 2011, at 5:54 AM, Deepak Jain wrote:
>>>
>>>  Some enterprises get MPLS L3 VPN service from their providers, and need
>>>> boxes that can route packets to it and speak BGP to inject their routes.
>>>>  They are not, per se, connected to the Internet, and thus won't be
>>>> "zorched", at least in the sense you are using it.
>>>>
>>> Hence 'public-facing'.
>>>
>>> ;>
>>>
>>> ------------------------------**------------------------------**
>>> -----------
>>> Roland Dobbins<rdobbins at arbor.net>  //<http://www.arbornetworks.**com<http://www.arbornetworks.com>
>>> >
>>>
>>>                The basis of optimism is sheer terror.
>>>
>>>                          -- Oscar Wilde
>>>
>>>
>>>
>>>
>>
>>
>

From brandon.galbraith at gmail.com  Wed Sep 21 18:41:12 2011
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Wed, 21 Sep 2011 16:41:12 -0700
Subject: vyatta for bgp
In-Reply-To: <CAJ0Nkqi14_JxxOPOG0_ZcNhXo7BD=WjpOb14evzD2Z2AyXGCMA@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
 <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
 <4E7202C4.9050502@pubnix.net>
 <CAJ0Nkqi14_JxxOPOG0_ZcNhXo7BD=WjpOb14evzD2Z2AyXGCMA@mail.gmail.com>
Message-ID: <CADE4tYW4AK_T4UMdZapYy+jf_LnpYWqXG2-SkRH2T_7y+Nb0iQ@mail.gmail.com>

On Wed, Sep 21, 2011 at 4:14 PM, Andreas Echavez <andreas at livejournalinc.com
> wrote:

>
> The most reliable/cost effective solution is the cheap and redundant
> approach to architecture.
>
> Reliable hardware is incredibly inexpensive, and every year we get better
> CPUs and (recently) GPUs that are providing APIs and interfaces to their
> incredible parallel processing capability.
>
> -Andreas
>
>
+1 Scaling Horizontally. Applies to your networking gear, your applications,
etc. If you assume anything is going to break, just get more and
scale/architect properly.



> On Thu, Sep 15, 2011 at 6:51 AM, Alain Hebert <ahebert at pubnix.net> wrote:
>
> >     Hi,
> >
> >    As usual this end-up in what people prefer.
> >
> >    Vyatta is as good as the hardware it runs on, the backend they use and
> > the people configuring/maintaining it.
> >
> >    The nature of ASIC make it more reliable than a multi-purpose device
> > (aka server) running an OS written for it.
> >
> >    It end up being a choice between risk and cost and being that you can
> > get your hand on second hand iron for cheap these days...
> >
> >    Why risk it.
> >
> >
> > -----
> > Alain Hebert                                ahebert at pubnix.net
> > PubNIX Inc.
> > 50 boul. St-Charles
> > P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
> > Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443
> >
> >
> > On 09/15/11 09:05, Ray Soucy wrote:
> >
> >> Is Vyatta really not suited for the task?
> >>
> >> I keep checking up on it and holding off looking into it as they don't
> >> support multicast yet.
> >>
> >> Modern commodity sever hardware these days often out-powers big iron
> >> enough to make up for not using ASICs, though, at least on the lower
> >> end of the spectrum.
> >>
> >> Does anyone have any more details on Vyatta not scaling?  Were you
> >> trying to run it as a VM?  What were you using for NICs? etc.
> >>
> >> The hardware matters.  Saying Vyatta doesn't cut it could mean
> anything...
> >>
> >> On Tue, Sep 13, 2011 at 7:36 PM, Dobbins, Roland<rdobbins at arbor.net>
> >>  wrote:
> >>
> >>> On Sep 14, 2011, at 5:54 AM, Deepak Jain wrote:
> >>>
> >>>  Some enterprises get MPLS L3 VPN service from their providers, and
> need
> >>>> boxes that can route packets to it and speak BGP to inject their
> routes.
> >>>>  They are not, per se, connected to the Internet, and thus won't be
> >>>> "zorched", at least in the sense you are using it.
> >>>>
> >>> Hence 'public-facing'.
> >>>
> >>> ;>
> >>>
> >>> ------------------------------**------------------------------**
> >>> -----------
> >>> Roland Dobbins<rdobbins at arbor.net>  //<http://www.arbornetworks.**com<
> http://www.arbornetworks.com>
> >>> >
> >>>
> >>>                The basis of optimism is sheer terror.
> >>>
> >>>                          -- Oscar Wilde
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
>



-- 
Brandon Galbraith
US Voice: 630.492.0464

From patrick at ianai.net  Wed Sep 21 18:43:05 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Wed, 21 Sep 2011 19:43:05 -0400
Subject: akamai rate limiting?
In-Reply-To: <CAD6AjGRHcAH7PNHiE-YV_GysVpx3hJtKkm=-kRr4_RGhTLExnA@mail.gmail.com>
References: <25D91B29-C48A-4A49-B793-2843B2C6173D@secure64.com>
 <CAD6AjGRHcAH7PNHiE-YV_GysVpx3hJtKkm=-kRr4_RGhTLExnA@mail.gmail.com>
Message-ID: <E0DF4767-DED5-4670-92B2-B9D75485323F@ianai.net>

On Sep 20, 2011, at 11:17 PM, Cameron Byrne wrote:
> On Sep 20, 2011 7:54 PM, "Joseph Gersch" <joe.gersch at secure64.com> wrote:
>> 
>> Does anyone know if Akamai edgesuite servers rate limits or blacklists
>> caching servers that query it too often?  It appears that queries are timing
>> out if we exceed a query load to edgesuite.
>> 
>> Does anyone at Akamai know if there are any changes to rate limiting or
>> an abnormally high load?

> Akamai traffic is dropping on my network now.
> 
> Emailed their noc, no eta on fix

Cameron & I have been in contact off-list, and all issues have been resolved.

More generally: Hopefully it will come as no surprise that Akamai has some rate-limiting parameters configured.  The Internet is a nasty place, and every contentious provider should have protections in place.

If anyone sees any problems with Akamai name servers or anything else, noc at akamai.com is monitored 24/7 and should be able to either help directly, or get you in touch with the right people who can.

-- 
TTFN,
patrick



From pradeep.bangera at imdea.org  Wed Sep 21 20:58:04 2011
From: pradeep.bangera at imdea.org (Pradeep Bangera)
Date: Thu, 22 Sep 2011 03:58:04 +0200
Subject: Question on 95th percentile and Over-usage transit pricing
Message-ID: <1316656684.2498.36.camel@Pradeep>

Hello NANOG,

I have a fundamental question regarding 95th percentile pricing. I will
make some prerequisite assumptions to set $/Mbps values before posting
my actual question.

Eg., For 1Gbps commitment, I will pay roughly $3/Mbps. Similarly for
10Gbps, 100Gbps I may pay $2/Mbps and $1/Mbps.

This appears like a sub-linear economy of scale pricing model followed
in transit pricing.

Now if I commit 1 Gbps over a 10Gbps provisioned link, I will pay fixed
monthly fee of $3000 for the 95th peak not exceeding the committed rate
of 1Gbps.

Now if my 95th peak is above the committed rate, say, 2Gbps or 4 Gbps or
8 Gbps, I believe I have to pay: $3000 + [over-usage_bandwidth_charges]
monthly.

Question: Does this over-usage bandwidth charge a linear cost function
or is it sub-linear like the committed bandwidth pricing? I mean, will
it cost me the same $/Mbps as over-usage charges for all 2Gbps, 4Gbps
and 8Gbps 95th percentile peaks? or is it

Over-usage_charges(2Gbps) > Over-usage_charges(4Gbps) >
Over-usage_charges(8Gbps) ?

I will be grateful for the replies!  

With regards

Pradeep Bangera
Research Assistant
Institute IMDEA Networks
Madrid, Spain



From patrick at ianai.net  Wed Sep 21 19:06:38 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Wed, 21 Sep 2011 20:06:38 -0400
Subject: Question on 95th percentile and Over-usage transit pricing
In-Reply-To: <1316656684.2498.36.camel@Pradeep>
References: <1316656684.2498.36.camel@Pradeep>
Message-ID: <1D881613-ADDE-44BE-B9A7-C8B9C96EBBB7@ianai.net>

On Sep 21, 2011, at 9:58 PM, Pradeep Bangera wrote:

> I have a fundamental question regarding 95th percentile pricing. I will
> make some prerequisite assumptions to set $/Mbps values before posting
> my actual question.
> 
> Eg., For 1Gbps commitment, I will pay roughly $3/Mbps. Similarly for
> 10Gbps, 100Gbps I may pay $2/Mbps and $1/Mbps.
> 
> This appears like a sub-linear economy of scale pricing model followed
> in transit pricing.
> 
> Now if I commit 1 Gbps over a 10Gbps provisioned link, I will pay fixed
> monthly fee of $3000 for the 95th peak not exceeding the committed rate
> of 1Gbps.
> 
> Now if my 95th peak is above the committed rate, say, 2Gbps or 4 Gbps or
> 8 Gbps, I believe I have to pay: $3000 + [over-usage_bandwidth_charges]
> monthly.
> 
> Question: Does this over-usage bandwidth charge a linear cost function
> or is it sub-linear like the committed bandwidth pricing? I mean, will
> it cost me the same $/Mbps as over-usage charges for all 2Gbps, 4Gbps
> and 8Gbps 95th percentile peaks? or is it
> 
> Over-usage_charges(2Gbps) > Over-usage_charges(4Gbps) >
> Over-usage_charges(8Gbps) ?

This answer is going to suck, but it is the truth.  In short, the answer, like so many things, is:
	IT DEPENDS

When you sign a contract, the overage can be more, same, or less depending on what you negotiate.  Of course, what you can negotiate depends on your leverage.  If you you have a lot of traffic, or desirable traffic (e.g. inbound traffic), then you can negotiate favorable terms.  If not, well, not.

Typically, 1 Gbps commit is not enough to garner a favorable rate on the overage, so expect to pay at least the same as the commit rate on overage.

If you have a lot more, you can negotiate tiers.  E.g. The first 10G is $X/Mbps, but if you hit 20G, you get charged 20000 * $Y (where Y < X, obviously).  This can lead to interesting situations where 19 Gbps costs more than 20 Gbps.  But dems da breaks.

-- 
TTFN,
patrick



From charles at knownelement.com  Wed Sep 21 23:24:06 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Wed, 21 Sep 2011 23:24:06 -0500
Subject: vyatta for bgp
In-Reply-To: <CAJ0Nkqi14_JxxOPOG0_ZcNhXo7BD=WjpOb14evzD2Z2AyXGCMA@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
 <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
 <4E7202C4.9050502@pubnix.net>
 <CAJ0Nkqi14_JxxOPOG0_ZcNhXo7BD=WjpOb14evzD2Z2AyXGCMA@mail.gmail.com>
Message-ID: <4E7AB866.2070202@knownelement.com>

On 09/21/2011 06:14 PM, Andreas Echavez wrote:
> btw, you guys might find
> PacketShader<http://shader.kaist.edu/packetshader/>a pretty
> interesting concept
>
> -Andreas

Excellent! I was wondering how far along this was. Good to see. Very 
exciting.

I've got a couple parallel systems sitting around looking for packets to 
route...

If anyone is doing research in this area, please let me know. Most of my 
research has been into accelerating IDS/IPS and fuzzing workloads with 
parallel systems. (Yes that's on top of starting an ISP).

I've been looking into http://www.read.cs.ucla.edu/click/Click




From don at bowenvale.co.nz  Wed Sep 21 23:48:44 2011
From: don at bowenvale.co.nz (Don Gould)
Date: Thu, 22 Sep 2011 16:48:44 +1200
Subject: How to begin making my own ISP?
In-Reply-To: <4E79A209.4030801@gormotte.info>
References: <20110916181029.24C11E671D@smtp.hushmail.com>
 <4E7927DC.3000604@bowenvale.co.nz> <4E79A209.4030801@gormotte.info>
Message-ID: <4E7ABE2C.7090004@bowenvale.co.nz>

Hello,

I don't know if that was directed at me or the OP, but very interesting 
stuff thanks.

No I don't read French, but google does. :)

D


On 21/09/2011 8:36 p.m., Julien Gormotte wrote:
> Hello,
>
> If you are able to read french, there are useful informations :
>
> the fai-locaux mailing list archives :
> https://lists.fdn.fr/wws
>
> A series of posts on this blog :
> http://blog.spyou.org/wordpress-mu/2010/06/09/comment-devenir-son-propre-fai-1-la-theorie/
>
> http://blog.spyou.org/wordpress-mu/2010/06/10/comment-devenir-son-propre-fai-2-la-base/
>
> http://blog.spyou.org/wordpress-mu/2010/06/15/comment-devenir-son-propre-fai-3-interconnexion/
>
> http://blog.spyou.org/wordpress-mu/2010/08/02/comment-devenir-son-propre-fai-4-administratif/
>
> http://blog.spyou.org/wordpress-mu/2010/08/09/comment-devenir-son-propre-fai-5-le-tres-haut-debit/
>
> http://blog.spyou.org/wordpress-mu/2010/08/14/comment-devenir-son-propre-fai-6-cas-pratique/
>
> http://blog.spyou.org/wordpress-mu/2010/08/17/comment-devenir-son-propre-fai-7-securite/
>
> http://blog.spyou.org/wordpress-mu/2010/08/17/comment-devenir-son-propre-fai-8-services/
>
> http://blog.spyou.org/wordpress-mu/2010/08/19/comment-devenir-son-propre-fai-9-cas-concret/
>
>
> Some informations are france-specific (in regards of law, etc...), but
> it can be useful.
> A lot of informations about ISP creation has been discussed lately,
> because FDN, a french association that is the oldest ISP still active in
> france, decided to create (with other associations) a "federation" to
> help the creation of new associative isps. You can see the FDN website
> (http://www.fdn.fr/)
>
> Le 21/09/2011 01:55, Don Gould a ?crit :
>> Hasserw,
>>
>> First I must apologise for not responding, I did see this message and
>> did mean to attempt to help you out as I am currently working though
>> this exact process in a very small proof of concept network with an
>> even smaller budget.
>>
>> To address our question, a good starting point is a Cisco CCNA.
>>
>> If you review the list archive for the past month you will find a very
>> interesting thread linking to guys who are running massive home
>> networks just for their learning, that in turn will link you to
>> detailed public CVs showing the sort of stuff that these guys are
>> trained and training in.
>>
>> You also need some business training to understand how to structure
>> the business aspects of your project. An MBA is a good qualification
>> but there are many less high level courses you could look at as well.
>>
>> NA Nog is an operational list (with a lot of rant and fun stuff) and
>> not really a business focused or educational list, so your initial
>> query simply ran under the radar.
>>
>> D
>>
>>
>> On 17/09/2011 6:10 a.m., hasserw at hushmail.com wrote:
>>> No one replied with any useful information. I guess no one wants
>>> competition on this list? Pretty poor tactic.
>>>
>>> On Sat, 10 Sep 2011 21:55:01 -0400 hasserw at hushmail.com wrote:
>>>> I want to begin making my own ISP, mainly for high speed servers
>>>> and such, but also branching out to residential customers. I'm
>>>> going to be in Germany for the next school year (probably either
>>>> Frankfurt am Main or Berlin); any suggestions on what sort of
>>>> classes I can take there that will be in English and will teach me
>>>>
>>>> all I need to know on how to build and manage my own ISP, AS, etc?
>>>>
>>>> Thanks.
>>>
>>>
>>
>
>

-- 
Don Gould
31 Acheson Ave
Mairehau
Christchurch, New Zealand
Ph: + 64 3 348 7235
Mobile: + 64 21 114 0699



From brandon.galbraith at gmail.com  Thu Sep 22 00:01:04 2011
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Wed, 21 Sep 2011 22:01:04 -0700
Subject: Question on 95th percentile and Over-usage transit pricing
In-Reply-To: <1D881613-ADDE-44BE-B9A7-C8B9C96EBBB7@ianai.net>
References: <1316656684.2498.36.camel@Pradeep>
 <1D881613-ADDE-44BE-B9A7-C8B9C96EBBB7@ianai.net>
Message-ID: <CADE4tYXGoAdqVQ_GegcWuuWNv2GukLWUnb=yCQEQpG7hT3x0hA@mail.gmail.com>

On Wed, Sep 21, 2011 at 5:06 PM, Patrick W. Gilmore <patrick at ianai.net>wrote:


> If you have a lot more, you can negotiate tiers.  E.g. The first 10G is
> $X/Mbps, but if you hit 20G, you get charged 20000 * $Y (where Y < X,
> obviously).  This can lead to interesting situations where 19 Gbps costs
> more than 20 Gbps.  But dems da breaks.
>
> --
> TTFN,
> patrick
>

I knew of a place that used to push "fake" traffic over a link to ensure
they were in the cheaper (higher) tier. Who knew business rules overriding
engineering could result in non-optimal situations.

-- 
Brandon Galbraith
US Voice: 630.492.0464

From paul4004 at gmail.com  Thu Sep 22 00:54:56 2011
From: paul4004 at gmail.com (PC)
Date: Wed, 21 Sep 2011 23:54:56 -0600
Subject: Question on 95th percentile and Over-usage transit pricing
In-Reply-To: <CADE4tYXGoAdqVQ_GegcWuuWNv2GukLWUnb=yCQEQpG7hT3x0hA@mail.gmail.com>
References: <1316656684.2498.36.camel@Pradeep>
 <1D881613-ADDE-44BE-B9A7-C8B9C96EBBB7@ianai.net>
 <CADE4tYXGoAdqVQ_GegcWuuWNv2GukLWUnb=yCQEQpG7hT3x0hA@mail.gmail.com>
Message-ID: <CAJAdsDnHxPqrumaxaEyD=uRhP8tXf4NvdCL91aEXPs--Khg7GQ@mail.gmail.com>

An optimal solution would be a tiered system where the adjusted price only
applies to traffic units over the price tier threshold and not retroactively
to all traffic units.

On Wed, Sep 21, 2011 at 11:01 PM, Brandon Galbraith <
brandon.galbraith at gmail.com> wrote:

> On Wed, Sep 21, 2011 at 5:06 PM, Patrick W. Gilmore <patrick at ianai.net
> >wrote:
>
>
> > If you have a lot more, you can negotiate tiers.  E.g. The first 10G is
> > $X/Mbps, but if you hit 20G, you get charged 20000 * $Y (where Y < X,
> > obviously).  This can lead to interesting situations where 19 Gbps costs
> > more than 20 Gbps.  But dems da breaks.
> >
> > --
> > TTFN,
> > patrick
> >
>
> I knew of a place that used to push "fake" traffic over a link to ensure
> they were in the cheaper (higher) tier. Who knew business rules overriding
> engineering could result in non-optimal situations.
>
> --
> Brandon Galbraith
> US Voice: 630.492.0464
>

From cb.list6 at gmail.com  Thu Sep 22 00:55:26 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Wed, 21 Sep 2011 22:55:26 -0700
Subject: akamai rate limiting?
In-Reply-To: <E0DF4767-DED5-4670-92B2-B9D75485323F@ianai.net>
References: <25D91B29-C48A-4A49-B793-2843B2C6173D@secure64.com>
 <CAD6AjGRHcAH7PNHiE-YV_GysVpx3hJtKkm=-kRr4_RGhTLExnA@mail.gmail.com>
 <E0DF4767-DED5-4670-92B2-B9D75485323F@ianai.net>
Message-ID: <CAD6AjGTJYX8Ut57=3ZU6eaDvbKhvWj1jPB=e2de_Emm5JoDjNQ@mail.gmail.com>

On Sep 21, 2011 4:43 PM, "Patrick W. Gilmore" <patrick at ianai.net> wrote:
>
> On Sep 20, 2011, at 11:17 PM, Cameron Byrne wrote:
> > On Sep 20, 2011 7:54 PM, "Joseph Gersch" <joe.gersch at secure64.com>
wrote:
> >>
> >> Does anyone know if Akamai edgesuite servers rate limits or blacklists
> >> caching servers that query it too often?  It appears that queries are
timing
> >> out if we exceed a query load to edgesuite.
> >>
> >> Does anyone at Akamai know if there are any changes to rate limiting or
> >> an abnormally high load?
>
> > Akamai traffic is dropping on my network now.
> >
> > Emailed their noc, no eta on fix
>
> Cameron & I have been in contact off-list, and all issues have been
resolved.
>
> More generally: Hopefully it will come as no surprise that Akamai has some
rate-limiting parameters configured.  The Internet is a nasty place, and
every contentious provider should have protections in place.
>
> If anyone sees any problems with Akamai name servers or anything else,
noc at akamai.com is monitored 24/7 and should be able to either help directly,
or get you in touch with the right people who can.
>

Thanks to Patrick and team at Akamai for resolving this quickly

Cb

> --
> TTFN,
> patrick
>
>

From patrick at ianai.net  Thu Sep 22 01:27:51 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Thu, 22 Sep 2011 02:27:51 -0400
Subject: Question on 95th percentile and Over-usage transit pricing
In-Reply-To: <CAJAdsDnHxPqrumaxaEyD=uRhP8tXf4NvdCL91aEXPs--Khg7GQ@mail.gmail.com>
References: <1316656684.2498.36.camel@Pradeep>
 <1D881613-ADDE-44BE-B9A7-C8B9C96EBBB7@ianai.net>
 <CADE4tYXGoAdqVQ_GegcWuuWNv2GukLWUnb=yCQEQpG7hT3x0hA@mail.gmail.com>
 <CAJAdsDnHxPqrumaxaEyD=uRhP8tXf4NvdCL91aEXPs--Khg7GQ@mail.gmail.com>
Message-ID: <F03E5D4D-2443-49DC-A7C0-AABC2700083E@ianai.net>

On Sep 22, 2011, at 1:54 AM, PC wrote:

> An optimal solution would be a tiered system where the adjusted price only applies to traffic units over the price tier threshold and not retroactively to all traffic units.

Optimal for whom?

Also, I doubt you can make that claim as you do not know the costs or other business conditions of every deal.

-- 
TTFN,
patrick


> On Wed, Sep 21, 2011 at 11:01 PM, Brandon Galbraith <brandon.galbraith at gmail.com> wrote:
> On Wed, Sep 21, 2011 at 5:06 PM, Patrick W. Gilmore <patrick at ianai.net>wrote:
> 
> 
> > If you have a lot more, you can negotiate tiers.  E.g. The first 10G is
> > $X/Mbps, but if you hit 20G, you get charged 20000 * $Y (where Y < X,
> > obviously).  This can lead to interesting situations where 19 Gbps costs
> > more than 20 Gbps.  But dems da breaks.
> >
> > --
> > TTFN,
> > patrick
> >
> 
> I knew of a place that used to push "fake" traffic over a link to ensure
> they were in the cheaper (higher) tier. Who knew business rules overriding
> engineering could result in non-optimal situations.
> 
> --
> Brandon Galbraith
> US Voice: 630.492.0464
> 



From charles at knownelement.com  Thu Sep 22 01:41:51 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Thu, 22 Sep 2011 01:41:51 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building
 a nationwide network -- ENOUGH ALREADY!
In-Reply-To: <399A63EC-DAE8-4DE0-A404-F4DF0598715F@getjive.com>
References: <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at>
 <Pine.LNX.4.61.1109200750300.25015@soloth.lewis.org>
 <CF92A88C-E336-4C30-A159-4ABCF38A6177@delong.com>
 <AE4B8895-9B3B-48B3-97F3-85C2AB14D71A@ianai.net>
 <20110920191822.GA9818@hiwaay.net>
 <CDDA6EAF-5EBA-46A5-A3E4-49260FBF629A@ianai.net>
 <4E79018F.6010406@matthew.at> <4E7904D8.4000600@wjp.net>
 <399A63EC-DAE8-4DE0-A404-F4DF0598715F@getjive.com>
Message-ID: <4E7AD8AF.2040308@knownelement.com>

My apologies to all. I was hoping the conversation would be of an 
operational nature.

I deleted the vast majority of messages in the thread as they weren't 
relevant.

If anyone wants I can post smaller scope subject threads. Or a summary 
of the operationally relevant bits in the thread.


Bret Palsson <bret at getjive.com> wrote:

    Thank you! 112 Emails on this subject, I am sick of it.



From p.lynch at netappliant.com  Thu Sep 22 05:37:19 2011
From: p.lynch at netappliant.com (Pierce Lynch)
Date: Thu, 22 Sep 2011 10:37:19 +0000
Subject: vyatta for bgp
In-Reply-To: <CAJ0Nkqi14_JxxOPOG0_ZcNhXo7BD=WjpOb14evzD2Z2AyXGCMA@mail.gmail.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
 <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
 <4E7202C4.9050502@pubnix.net>
 <CAJ0Nkqi14_JxxOPOG0_ZcNhXo7BD=WjpOb14evzD2Z2AyXGCMA@mail.gmail.com>
Message-ID: <A4428DD467A70E48B98693F1E20B198C01613619@V-ENT02.eu.netappliant.com>

Andreas Echavez [mailto:andreas at livejournalinc.com] originally wrote:
> Ultimately, the network is as reliable as you build it. With software, it's much cheaper to divide and scale horizontally. Hardware devices are expensive and usually horizontal 
> scalability never happens. So in reality, an enterprise blows 100k on two routers, they both flop because of some "firmware bug", and you're down.

With this in mind, I am keen to understand how many implementations of packages such as Quagga and Zebra that the group use. With the likes of Vyatta being discussed, I am keen to see if products such as Quagga as still regularly used as it used to be.

Thoughts welcome!

Kind regards,

/P.


From jcdill.lists at gmail.com  Thu Sep 22 09:58:35 2011
From: jcdill.lists at gmail.com (JC Dill)
Date: Thu, 22 Sep 2011 07:58:35 -0700
Subject: Internet mauled by bears
In-Reply-To: <4E789FFE.9050702@thebaughers.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com> <4E789FFE.9050702@thebaughers.com>
Message-ID: <4E7B4D1B.1020005@gmail.com>

On 20/09/11 7:15 AM, Jason Baugher wrote:
>
> Horses are okay, but you have to tie things to the wire so they can 
> see it. They're too dumb to remember where it is, apparently.

This has nothing to do with the horse's ability to see or remember where 
the fence it.  It has to do with the value (both financial and 
emotional) the owner places on the animal, and the ensuing costs if it 
breaks the fence.  Horses can get hurt quite easily, vet bills can run 
into hundreds or thousands of dollars quite quickly.  Most horse owners 
will spend far more than the replacement cost of the animal in vet bills 
and husbandry to heal it when it gets injured, because the animal has a 
"member of the household" status in their lives and can't easily be 
replaced by a similar animal.  So they flag wire fences to help the 
horse avoid getting hurt.  Then there's liability.  In many states, if a 
horse gets out on the road and gets hit, the horse owner is liable for 
the damages to the car and occupants.  If someone in the car is injured 
or killed (likely if the horse is hit head-on and comes thru the 
windshield) the liability costs can be significant, run into millions of 
dollars.  For this reason, many equestrian insurance policies require 
that electric fencing be flagged.

Other livestock aren't as likely to cause fatal injuries to car 
occupants if they are hit, because the animal's body is lower to the 
road, less likely to come over the hood.

jc



From randy at psg.com  Thu Sep 22 10:12:04 2011
From: randy at psg.com (Randy Bush)
Date: Thu, 22 Sep 2011 17:12:04 +0200
Subject: Internet mauled by bears
In-Reply-To: <4E7B4D1B.1020005@gmail.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com> <4E789FFE.9050702@thebaughers.com>
 <4E7B4D1B.1020005@gmail.com>
Message-ID: <m2ty84pq63.wl%randy@psg.com>

while we still lived on the farm, two vallies away was gordon, who ran a
dairy farm, milked, and delivered around coos and curry counties twice a
week.  he told of deciding to go down to the big city, san francisco.
so he put good clothes on and packed a suitcase and headed south (a long
day drive).  he said that when he got to san francisco, he was amazed
that people were walking around in farm coveralls like those he left at
home.

all the country boy engineers here make me think of gordon's story.

randy


From jason at thebaughers.com  Thu Sep 22 10:31:14 2011
From: jason at thebaughers.com (Jason Baugher)
Date: Thu, 22 Sep 2011 10:31:14 -0500
Subject: Internet mauled by bears
In-Reply-To: <4E7B4D1B.1020005@gmail.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com> <4E789FFE.9050702@thebaughers.com>
 <4E7B4D1B.1020005@gmail.com>
Message-ID: <4E7B54C2.4060106@thebaughers.com>

On 9/22/2011 9:58 AM, JC Dill wrote:
> On 20/09/11 7:15 AM, Jason Baugher wrote:
>>
>> Horses are okay, but you have to tie things to the wire so they can 
>> see it. They're too dumb to remember where it is, apparently.
>
> This has nothing to do with the horse's ability to see or remember 
> where the fence it.  It has to do with the value (both financial and 
> emotional) the owner places on the animal, and the ensuing costs if it 
> breaks the fence.  Horses can get hurt quite easily, vet bills can run 
> into hundreds or thousands of dollars quite quickly.  Most horse 
> owners will spend far more than the replacement cost of the animal in 
> vet bills and husbandry to heal it when it gets injured, because the 
> animal has a "member of the household" status in their lives and can't 
> easily be replaced by a similar animal.  So they flag wire fences to 
> help the horse avoid getting hurt.  Then there's liability.  In many 
> states, if a horse gets out on the road and gets hit, the horse owner 
> is liable for the damages to the car and occupants.  If someone in the 
> car is injured or killed (likely if the horse is hit head-on and comes 
> thru the windshield) the liability costs can be significant, run into 
> millions of dollars.  For this reason, many equestrian insurance 
> policies require that electric fencing be flagged.
>
> Other livestock aren't as likely to cause fatal injuries to car 
> occupants if they are hit, because the animal's body is lower to the 
> road, less likely to come over the hood.
>
> jc
>
>
>
That's interesting to know. It's also interesting to note that other 
animals, with the possible exception of sheep, will not run through an 
electric fence once they know that it is there. Sheep do it intentionally.


From shrdlu at deaddrop.org  Thu Sep 22 10:52:09 2011
From: shrdlu at deaddrop.org (Lynda)
Date: Thu, 22 Sep 2011 08:52:09 -0700
Subject: Internet mauled by bears
In-Reply-To: <4E7B54C2.4060106@thebaughers.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com> <4E789FFE.9050702@thebaughers.com>
 <4E7B4D1B.1020005@gmail.com> <4E7B54C2.4060106@thebaughers.com>
Message-ID: <4E7B59A9.2070301@deaddrop.org>

On 9/22/2011 8:31 AM, Jason Baugher wrote:
> On 9/22/2011 9:58 AM, JC Dill wrote:

[re: horses]
>> Other livestock aren't as likely to cause fatal injuries to car
>> occupants if they are hit, because the animal's body is lower to the
>> road, less likely to come over the hood.

> That's interesting to know. It's also interesting to note that other
> animals, with the possible exception of sheep, will not run through an
> electric fence once they know that it is there. Sheep do it intentionally.

Domesticated sheep are born with vague intelligence, but this is gone by 
the time they are adults. There can be no speaking of intention, because 
they are incapable.

A lamb bounces around, playful and amusing, and if it sees a fence, it 
*stops* short of the fence. Sheep will run straight into the fence, and 
snap their necks, if at the front of a herd. Been there. Seen it. Sheep 
are stupid. Really.

-- 
...most of us have as our claim to fame the ability to talk to
inanimate objects and convince them they want to listen to us.
               Valdis Kletnieks


From chuckchurch at gmail.com  Thu Sep 22 10:55:04 2011
From: chuckchurch at gmail.com (Chuck Church)
Date: Thu, 22 Sep 2011 11:55:04 -0400
Subject: Internet mauled by bears
In-Reply-To: <4E7B54C2.4060106@thebaughers.com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com> <4E789FFE.9050702@thebaughers.com>
 <4E7B4D1B.1020005@gmail.com> <4E7B54C2.4060106@thebaughers.com>
Message-ID: <000901cc793f$ff584fe0$fe08efa0$@com>

Can we take this offline?  I don't believe livestock behavior patterns have
much operational content.


Thanks,

Chuck

-----Original Message-----
From: Jason Baugher [mailto:jason at thebaughers.com] 
Sent: Thursday, September 22, 2011 11:31 AM
To: nanog at nanog.org
Subject: Re: Internet mauled by bears

On 9/22/2011 9:58 AM, JC Dill wrote:
> On 20/09/11 7:15 AM, Jason Baugher wrote:
>>
>> Horses are okay, but you have to tie things to the wire so they can 
>> see it. They're too dumb to remember where it is, apparently.
>
> This has nothing to do with the horse's ability to see or remember 
> where the fence it.  It has to do with the value (both financial and 
> emotional) the owner places on the animal, and the ensuing costs if it 
> breaks the fence.  Horses can get hurt quite easily, vet bills can run 
> into hundreds or thousands of dollars quite quickly.  Most horse 
> owners will spend far more than the replacement cost of the animal in 
> vet bills and husbandry to heal it when it gets injured, because the 
> animal has a "member of the household" status in their lives and can't 
> easily be replaced by a similar animal.  So they flag wire fences to 
> help the horse avoid getting hurt.  Then there's liability.  In many 
> states, if a horse gets out on the road and gets hit, the horse owner 
> is liable for the damages to the car and occupants.  If someone in the 
> car is injured or killed (likely if the horse is hit head-on and comes 
> thru the windshield) the liability costs can be significant, run into 
> millions of dollars.  For this reason, many equestrian insurance 
> policies require that electric fencing be flagged.
>
> Other livestock aren't as likely to cause fatal injuries to car 
> occupants if they are hit, because the animal's body is lower to the 
> road, less likely to come over the hood.
>
> jc
>
>
>
That's interesting to know. It's also interesting to note that other 
animals, with the possible exception of sheep, will not run through an 
electric fence once they know that it is there. Sheep do it intentionally.



From bpasdar at batblue.com  Thu Sep 22 11:51:00 2011
From: bpasdar at batblue.com (Babak Pasdar)
Date: Thu, 22 Sep 2011 12:51:00 -0400
Subject: PBB v. PBB-TE
Message-ID: <20110922165100.016388d1@concur.batblue.com>

Could I get some feedback from the list on PBB (802.1ah) v. PBB-TE (802.1Qay).  Very specifically around:

1.  PBB-TE's Customer side MAC learning and management capabilities.  
2.  PBB's direct or augmented ability to handle broadcast floods.

Also, any recommendations from the list on strong PBB-TE vendors would be appreciated.

Thanks for your feedback in advance.

Best Regards,

Babak

--
Babak Pasdar
President & CEO | Certified Ethical Hacker
Bat Blue Networks
(p) 212.461.3322 x3005 | (f) 212.584.9999 |  www.BatBlue.com

Bat Blue's AS: 25885 | BGP Policy | Peering Policy

Watch: Cloud Security Video | Cloud Network Video

The Official WiFi Provider for ESPN's X Games

From malayter at gmail.com  Thu Sep 22 12:31:34 2011
From: malayter at gmail.com (Ryan Malayter)
Date: Thu, 22 Sep 2011 10:31:34 -0700 (PDT)
Subject: Question on 95th percentile and Over-usage transit pricing
In-Reply-To: <CAJAdsDnHxPqrumaxaEyD=uRhP8tXf4NvdCL91aEXPs--Khg7GQ@mail.gmail.com>
References: <1316656684.2498.36.camel@Pradeep>
 <1D881613-ADDE-44BE-B9A7-C8B9C96EBBB7@ianai.net>
 <CADE4tYXGoAdqVQ_GegcWuuWNv2GukLWUnb=yCQEQpG7hT3x0hA@mail.gmail.com>
 <CAJAdsDnHxPqrumaxaEyD=uRhP8tXf4NvdCL91aEXPs--Khg7GQ@mail.gmail.com>
Message-ID: <c9a90062-a0a5-43e3-8cd2-79226528c465@17g2000yqv.googlegroups.com>



On Sep 22, 12:54?am, PC <paul4... at gmail.com> wrote:
> An optimal solution would be a tiered system where the adjusted price only
> applies to traffic units over the price tier threshold and not retroactively
> to all traffic units.

I have seen a more "optimal" scheme about 15 years ago. Pricing was a
smooth function, but it was for software licensing, not networking.

As I recall, their scheme went something like:
invoice_amount = some_constant * (quantity)^0.75

This seemed smart to me. It gave the customer incentives to invest
more, but also got rid of silly discontinuities that would cause
irrational customer and salesperson behavior.

Has anyone seen something similar in the service provider world? All I
ever see are arbitrary step functions.


From fredan-nanog at fredan.se  Thu Sep 22 13:14:20 2011
From: fredan-nanog at fredan.se (fredrik danerklint)
Date: Thu, 22 Sep 2011 20:14:20 +0200
Subject: Question on 95th percentile and Over-usage transit pricing
In-Reply-To: <c9a90062-a0a5-43e3-8cd2-79226528c465@17g2000yqv.googlegroups.com>
References: <1316656684.2498.36.camel@Pradeep>
 <CAJAdsDnHxPqrumaxaEyD=uRhP8tXf4NvdCL91aEXPs--Khg7GQ@mail.gmail.com>
 <c9a90062-a0a5-43e3-8cd2-79226528c465@17g2000yqv.googlegroups.com>
Message-ID: <201109222014.20574.fredan-nanog@fredan.se>

I like thisone!

> As I recall, their scheme went something like:
> invoice_amount = some_constant * (quantity)^0.75
-- 
//fredan


From charles at knownelement.com  Thu Sep 22 13:38:27 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Thu, 22 Sep 2011 13:38:27 -0500
Subject: vyatta for bgp
In-Reply-To: <A4428DD467A70E48B98693F1E20B198C01613619@V-ENT02.eu.netappliant.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
 <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
 <4E7202C4.9050502@pubnix.net>
 <CAJ0Nkqi14_JxxOPOG0_ZcNhXo7BD=WjpOb14evzD2Z2AyXGCMA@mail.gmail.com>
 <A4428DD467A70E48B98693F1E20B198C01613619@V-ENT02.eu.netappliant.com>
Message-ID: <4E7B80A3.1000005@knownelement.com>

On 09/22/2011 05:37 AM, Pierce Lynch wrote:
> Andreas Echavez [mailto:andreas at livejournalinc.com] originally wrote:
>> Ultimately, the network is as reliable as you build it. With software, it's much cheaper to divide and scale horizontally. Hardware devices are expensive and usually horizontal
>> scalability never happens. So in reality, an enterprise blows 100k on two routers, they both flop because of some "firmware bug", and you're down.
> With this in mind, I am keen to understand how many implementations of packages such as Quagga and Zebra that the group use. With the likes of Vyatta being discussed, I am keen to see if products such as Quagga as still regularly used as it used to be.

I think that the original/upstream versions are out of date as compared 
to the one maintained by Vyatta. Or Google (for their MPLS processing 
needs). See 
http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nanog50 
<http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nanog50>



> Thoughts welcome!
>
> Kind regards,
>
> /P.
>



From swhyte at gmail.com  Thu Sep 22 14:03:21 2011
From: swhyte at gmail.com (Scott Whyte)
Date: Thu, 22 Sep 2011 12:03:21 -0700
Subject: vyatta for bgp
In-Reply-To: <4E7B80A3.1000005@knownelement.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
 <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
 <4E7202C4.9050502@pubnix.net>
 <CAJ0Nkqi14_JxxOPOG0_ZcNhXo7BD=WjpOb14evzD2Z2AyXGCMA@mail.gmail.com>
 <A4428DD467A70E48B98693F1E20B198C01613619@V-ENT02.eu.netappliant.com>
 <4E7B80A3.1000005@knownelement.com>
Message-ID: <4E7B8679.4000003@gmail.com>

On 9/22/11 11:38 , Charles N Wyble wrote:
> On 09/22/2011 05:37 AM, Pierce Lynch wrote:
>> Andreas Echavez [mailto:andreas at livejournalinc.com] originally wrote:
>>> Ultimately, the network is as reliable as you build it. With
>>> software, it's much cheaper to divide and scale horizontally.
>>> Hardware devices are expensive and usually horizontal
>>> scalability never happens. So in reality, an enterprise blows 100k on
>>> two routers, they both flop because of some "firmware bug", and
>>> you're down.
>> With this in mind, I am keen to understand how many implementations of
>> packages such as Quagga and Zebra that the group use. With the likes
>> of Vyatta being discussed, I am keen to see if products such as Quagga
>> as still regularly used as it used to be.
>
> I think that the original/upstream versions are out of date as compared
> to the one maintained by Vyatta. Or Google (for their MPLS processing
> needs). See
> http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nanog50
> <http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nanog50>

We are actively supporting Quagga.  We currently have a git repo at 
code.google.com with some BGP multipath updates, and are working with 
ISC to provide SQA on that branch.  Hopefully more features will be 
forthcoming.  Search quagga-dev if you're interested in more details.

Vyatta has done a lot of great work on Quagga, as have many others.  It 
would be nice to see all the various useful branches merged into a 
cherry-picked mainline that would simplify the Quagga development 
community's lives considerably.

-Scott


From nanog at data102.com  Thu Sep 22 14:04:28 2011
From: nanog at data102.com (randal k)
Date: Thu, 22 Sep 2011 13:04:28 -0600
Subject: yahoo mail admin anywhere?
Message-ID: <CANeLk7TiLFqr_D1P+AkE-X8Ci2WzA71C3UU8CWJnzw_Tu3V8TA@mail.gmail.com>

We have a situation where we/many of our customers are unable to receive
email from Yahoo due to broken DNS, which really doesn't look broken. As I
don't have error numbers, just undeliverables, automated support is not
useful. Off-list is fine, but posting a real honest-to-gosh-real-life
contact to NANOG would probably be awesome to more people than just me ;-)

Thanks!
Randal Kohutek, Data102
randal at data102.com
rkohutek at gmail.com because the above probably won't work!
719-387-0000x1337

From mpalmer at hezmatt.org  Thu Sep 22 15:52:10 2011
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Fri, 23 Sep 2011 06:52:10 +1000
Subject: Question on 95th percentile and Over-usage transit pricing
In-Reply-To: <c9a90062-a0a5-43e3-8cd2-79226528c465@17g2000yqv.googlegroups.com>
References: <1316656684.2498.36.camel@Pradeep>
 <1D881613-ADDE-44BE-B9A7-C8B9C96EBBB7@ianai.net>
 <CADE4tYXGoAdqVQ_GegcWuuWNv2GukLWUnb=yCQEQpG7hT3x0hA@mail.gmail.com>
 <CAJAdsDnHxPqrumaxaEyD=uRhP8tXf4NvdCL91aEXPs--Khg7GQ@mail.gmail.com>
 <c9a90062-a0a5-43e3-8cd2-79226528c465@17g2000yqv.googlegroups.com>
Message-ID: <20110922205210.GU15512@hezmatt.org>

On Thu, Sep 22, 2011 at 10:31:34AM -0700, Ryan Malayter wrote:
> On Sep 22, 12:54?am, PC <paul4... at gmail.com> wrote:
> > An optimal solution would be a tiered system where the adjusted price only
> > applies to traffic units over the price tier threshold and not retroactively
> > to all traffic units.
> 
> I have seen a more "optimal" scheme about 15 years ago. Pricing was a
> smooth function, but it was for software licensing, not networking.
> 
> As I recall, their scheme went something like:
> invoice_amount = some_constant * (quantity)^0.75
> 
> This seemed smart to me. It gave the customer incentives to invest
> more, but also got rid of silly discontinuities that would cause
> irrational customer and salesperson behavior.
> 
> Has anyone seen something similar in the service provider world? All I
> ever see are arbitrary step functions.

I actually had this discussion quite recently with The Powers, as we have
some fairly interesting issues with the results of our newly adjusted
pricing steps.

The rationale behind sticking with the steps was "everyone else does it that
way, so when customers are making comparisons they need to be able to make a
meaningful comparison" and "continuous functions are too hard".  Given that
we're not a market leader in network traffic, I somewhat see the logic
behind the first, and given the average customer has trouble understanding
that XGB per month at $Y/GB => $X*Y, I totally see the point on the second,
*in general*.

However, if you want it, ask for it.  Go so far as to say that you'll only
consider pricing functions that are continuous, and therefore will be making
an apples-for-apples comparison.  You'll exclude a lot of the market, simply
because the contracts can't be modified like that or the billing system
can't handle it, but I'm fairly confident that the data to create such a
function exists at every sanely-run network provider.

- Matt

-- 
"For once, Microsoft wasn't exaggerating when they named it the 'Jet Engine'
-- your data's the seagull."
		-- Chris Adams



From Valdis.Kletnieks at vt.edu  Thu Sep 22 17:11:54 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 22 Sep 2011 18:11:54 -0400
Subject: Internet mauled by bears
In-Reply-To: Your message of "Thu, 22 Sep 2011 11:55:04 EDT."
 <000901cc793f$ff584fe0$fe08efa0$@com>
References: <CAArzuov089YT0mu9CpPiOWkX+=dqOkX7TW3QhsNESoT6UjGLHw@mail.gmail.com>
 <D2D37F15EBBD524693E9F3CB32D0208042C1348694@exchange.corp.fpu-tn.com>
 <AF24AE2D4A4D334FB9B667985E2AE763C32A8E@mail1-sea.office.spectrumnet.us>
 <CAArzuouAKjMqkyrVUPW7HY0LRvwkhzipHLD+B6PVx-cPhJ8W0w@mail.gmail.com>
 <CACB24MvmPQhp-oHJTkqV+sOcTx=5JRM6PjFznU7xDdv45XKE3w@mail.gmail.com>
 <4E7842D3.3090305@bogus.com> <4E789FFE.9050702@thebaughers.com>
 <4E7B4D1B.1020005@gmail.com> <4E7B54C2.4060106@thebaughers.com>
 <000901cc793f$ff584fe0$fe08efa0$@com>
Message-ID: <39044.1316729514@turing-police.cc.vt.edu>

On Thu, 22 Sep 2011 11:55:04 EDT, Chuck Church said:
> Can we take this offline?  I don't believe livestock behavior patterns have
> much operational content.

What's the mathematical difference between modelling a sheep
stampede and modelling a slashdotting?  The word is "sheeple" for
a reason...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110922/8d6f8917/attachment.bin>

From paul4004 at gmail.com  Thu Sep 22 17:23:41 2011
From: paul4004 at gmail.com (PC)
Date: Thu, 22 Sep 2011 16:23:41 -0600
Subject: Question on 95th percentile and Over-usage transit pricing
In-Reply-To: <F03E5D4D-2443-49DC-A7C0-AABC2700083E@ianai.net>
References: <1316656684.2498.36.camel@Pradeep>
 <1D881613-ADDE-44BE-B9A7-C8B9C96EBBB7@ianai.net>
 <CADE4tYXGoAdqVQ_GegcWuuWNv2GukLWUnb=yCQEQpG7hT3x0hA@mail.gmail.com>
 <CAJAdsDnHxPqrumaxaEyD=uRhP8tXf4NvdCL91aEXPs--Khg7GQ@mail.gmail.com>
 <F03E5D4D-2443-49DC-A7C0-AABC2700083E@ianai.net>
Message-ID: <CAJAdsD=TGzSTSrb-XExsFx2vqC-inR4f52ChwGD7-Baib-__kw@mail.gmail.com>

I don't know every particular deal, but I felt it's a solution to the
person's situation whom I replied to who was producing fake traffic for
bandwidth they purchase.

The point is to suggest that his pricing scheme where it's potential for the
total bill to be cheaper by purposely wasting a resource and directing a
traffic flood at the ISP's router or some poor sap's netblock is a
suboptimal one and not in anyone's best interest.

I don't know the costs of his deal, but I think that an arrangement which
has progressed to the customer running a traffic flood to the SP core to get
the bill down is not economically nor politically beneficial to anyone
involved in that person's scenario anymore.

The business conditions can throw a wrench into things though...  a huge
one.


On Thu, Sep 22, 2011 at 12:27 AM, Patrick W. Gilmore <patrick at ianai.net>wrote:

> On Sep 22, 2011, at 1:54 AM, PC wrote:
>
> > An optimal solution would be a tiered system where the adjusted price
> only applies to traffic units over the price tier threshold and not
> retroactively to all traffic units.
>
> Optimal for whom?
>
> Also, I doubt you can make that claim as you do not know the costs or other
> business conditions of every deal.
>
> --
> TTFN,
> patrick
>
>
> > On Wed, Sep 21, 2011 at 11:01 PM, Brandon Galbraith <
> brandon.galbraith at gmail.com> wrote:
> > On Wed, Sep 21, 2011 at 5:06 PM, Patrick W. Gilmore <patrick at ianai.net
> >wrote:
> >
> >
> > > If you have a lot more, you can negotiate tiers.  E.g. The first 10G is
> > > $X/Mbps, but if you hit 20G, you get charged 20000 * $Y (where Y < X,
> > > obviously).  This can lead to interesting situations where 19 Gbps
> costs
> > > more than 20 Gbps.  But dems da breaks.
> > >
> > > --
> > > TTFN,
> > > patrick
> > >
> >
> > I knew of a place that used to push "fake" traffic over a link to ensure
> > they were in the cheaper (higher) tier. Who knew business rules
> overriding
> > engineering could result in non-optimal situations.
> >
> > --
> > Brandon Galbraith
> > US Voice: 630.492.0464
> >
>
>
>

From bfehn at metcom.org  Thu Sep 22 17:24:24 2011
From: bfehn at metcom.org (Robert J. Fehn)
Date: Thu, 22 Sep 2011 18:24:24 -0400
Subject: automated response
Message-ID: <11109221824.AA338239852@metcom.org>

I will be out of the office until Monday, October 3rd.  I will be checking email daily and, there's always the cell phone.

METCOM: Any IT concerns can be handled by Christin Edwards at 301-373-4733 Ext 262 or, email her at: cedwards at metcom.org 

CALS: BOD issues can come to me or Vice Chair, Stanis Inscoe. Call or text if important.

PERSONAL: I'll get back to you within 24hrs if you leave contact info..

Thanks!

Bob



From rpug at linux.com  Thu Sep 22 19:55:33 2011
From: rpug at linux.com (Ryan Pugatch)
Date: Thu, 22 Sep 2011 20:55:33 -0400
Subject: Verizon / FiOS network
Message-ID: <6b8e973364bb465f5fe35c583271d756.squirrel@wm.horrible.net>

Hi,

Anyone noticing anything weird with the Verizon / FiOS network?

Seems like many people on their network are having trouble getting to us
(on Sidera / RCN) but not everyone.

Traceroutes appear sane, so just wondering if anyone else is running into
similar troubles.

Ryan



From vixie at isc.org  Thu Sep 22 20:03:20 2011
From: vixie at isc.org (Paul Vixie)
Date: Fri, 23 Sep 2011 01:03:20 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <C58EECBC-0ECE-40E9-95E7-A832190E5BC6@queuefull.net> (Benson
 Schliesser's message of "Tue, 20 Sep 2011 12:01:41 -0500")
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>
 <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net>
 <g3ipondv0h.fsf@nsa.vix.com>
 <C58EECBC-0ECE-40E9-95E7-A832190E5BC6@queuefull.net>
Message-ID: <g34o04vzmv.fsf@nsa.vix.com>

Benson Schliesser <bensons at queuefull.net> writes:

> Hi, Paul.

sorry for the delay.  i'll include the entirety of this short thread.

>>> For what it's worth, I agree that ARIN has a pretty good governance
>>> structure. (With the exception of NomCom this year, which is shamefully
>>> unbalanced.) ...
>> 
>> as the chairman of the 2011 ARIN NomCom, i hope you'll explain further,
>> either publically here, or privately, as you prefer.
>
> My understanding is that the NomCom consists of 7 people. Of those, 2
> come from the board and 2 come from the AC. Together, those 4 members of
> the existing establishment choose the remaining 3 NomCom members. In the
> past, there was at least the appearance of random selection for some of
> the NomCom members. But in any case, due to its composition, the NomCom
> has the appearance of a body biased in favor of the existing
> establishment.
>
> Please correct any misunderstanding that I might have. Otherwise, I
> encourage an update to the structure of future NomComs.

can you explain what it was about prior nomcoms that gave the appearance
of random selection?  to the best of my knowledge, including knowledge i
gained as chair of the 2008 ARIN NomCom, we've been doing it the same way
for quite a while now.  so i do not understand your reference to "at least
the appearance of random selection" in the past.

since ARIN members-in-good-standing elect the board and advisory council,
and also make up three of the four seats of the nominations committee, i
do not share your view on "bias" as expressed above.  i think it shows
that ARIN is clearly governed by its members -- which is as it should be.

by your two references to "the existing establishment" do you intend to
imply that ARIN's members don't currently have the establishment that they
want, or that they could not change this establishment if they wanted to,
or that ARIN's members are themselves part of "the existing establishment"
in some way that's bad?

ARIN's bylaws firmly place control of ARIN into the hands of its members.
if you think that's the wrong approach, i'm curious to hear your reasoning
and your proposed alternative.
-- 
Paul Vixie
KI6YSY


From morrowc.lists at gmail.com  Thu Sep 22 20:21:46 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 22 Sep 2011 21:21:46 -0400
Subject: Verizon / FiOS network
In-Reply-To: <6b8e973364bb465f5fe35c583271d756.squirrel@wm.horrible.net>
References: <6b8e973364bb465f5fe35c583271d756.squirrel@wm.horrible.net>
Message-ID: <CAL9jLaZexGQFPKQV+1tciHp8DAktxs0yrx+Wx7N=5W7jsrwJ5Q@mail.gmail.com>

On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
> Hi,
>
> Anyone noticing anything weird with the Verizon / FiOS network?
>
> Seems like many people on their network are having trouble getting to us
> (on Sidera / RCN) but not everyone.
>

it's, obviously, simpler to help diagnose this when you provide some
semblance of destination address, port, protocol...

just sayin'!

-chris
(fios user who could help, if only there was enough info to go on)


From rpug at linux.com  Thu Sep 22 20:32:35 2011
From: rpug at linux.com (Ryan Pugatch)
Date: Thu, 22 Sep 2011 21:32:35 -0400
Subject: Verizon / FiOS network
In-Reply-To: <CAL9jLaZexGQFPKQV+1tciHp8DAktxs0yrx+Wx7N=5W7jsrwJ5Q@mail.gmail.com>
References: <6b8e973364bb465f5fe35c583271d756.squirrel@wm.horrible.net>
 <CAL9jLaZexGQFPKQV+1tciHp8DAktxs0yrx+Wx7N=5W7jsrwJ5Q@mail.gmail.com>
Message-ID: <cdae61c9e0158c7c03921c4a587bc221.squirrel@wm.horrible.net>

> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
>> Hi,
>>
>> Anyone noticing anything weird with the Verizon / FiOS network?
>>
>> Seems like many people on their network are having trouble getting to us
>> (on Sidera / RCN) but not everyone.
>>
>
> it's, obviously, simpler to help diagnose this when you provide some
> semblance of destination address, port, protocol...
>
> just sayin'!
>
> -chris
> (fios user who could help, if only there was enough info to go on)
>
>

HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21



From bensons at queuefull.net  Thu Sep 22 21:05:51 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Thu, 22 Sep 2011 21:05:51 -0500
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <g34o04vzmv.fsf@nsa.vix.com>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net> <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com> <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net> <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>
 <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net>
 <g3ipondv0h.fsf@nsa.vix.com>
 <C58EECBC-0ECE-40E9-95E7-A832190E5BC6@queuefull.net>
 <g34o04vzmv.fsf@nsa.vix.com>
Message-ID: <171BF180-F19E-49A0-9B78-977F56B09A3E@queuefull.net>

Hi, Paul.

On Sep 22, 2011, at 8:03 PM, Paul Vixie wrote:

>> My understanding is that the NomCom consists of 7 people. Of those, 2
>> come from the board and 2 come from the AC. Together, those 4 members of
>> the existing establishment choose the remaining 3 NomCom members. In the
>> past, there was at least the appearance of random selection for some of
>> the NomCom members. But in any case, due to its composition, the NomCom
>> has the appearance of a body biased in favor of the existing
>> establishment.
>> 
>> Please correct any misunderstanding that I might have. Otherwise, I
>> encourage an update to the structure of future NomComs.
> 
> can you explain what it was about prior nomcoms that gave the appearance
> of random selection?  to the best of my knowledge, including knowledge i
> gained as chair of the 2008 ARIN NomCom, we've been doing it the same way
> for quite a while now.  so i do not understand your reference to "at least
> the appearance of random selection" in the past.

Earlier this year I received the following from ARIN member services:  "This year the NomCom charter was changed by the Board.  In the past the 3 Member volunteers were selected at random.  This year the 3 volunteers will be chosen by the 4 current members of the NomCom (2 from the Board 2 from the AC)"

The above quote was sent to me in response to a query I made, inquiring how the NomCom would be chosen in 2011.  It is consistent with what I was told in 2010, when I was chosen to be part of the 2010 NomCom.  At that time I was told that Member volunteers were chosen randomly.  During my NomCom tenure, however, it was suggested to me privately that there was very little randomness involved in the selection process; I was told that individuals were specifically chosen for NomCom.  I don't know what to make of this disparity, honestly, which is why I referenced "the appearance of random selection".

> since ARIN members-in-good-standing elect the board and advisory council,
> and also make up three of the four seats of the nominations committee, i
> do not share your view on "bias" as expressed above.  i think it shows
> that ARIN is clearly governed by its members -- which is as it should be.
> 
> by your two references to "the existing establishment" do you intend to
> imply that ARIN's members don't currently have the establishment that they
> want, or that they could not change this establishment if they wanted to,
> or that ARIN's members are themselves part of "the existing establishment"
> in some way that's bad?

The NomCom acts as a filter, of sorts.  It chooses the candidates that the membership will see.  The fact that the NomCom is so closely coupled with the existing leadership has an unfortunate appearance that suggests a bias.  I'm unable to say whether the bias exists, is recognized, and/or is reflected in the slate of candidates.  But it seems like an easy enough thing to avoid.

As for my use of "existing establishment":  I'm of the impression that a relatively small group of individuals drive ARIN, that most ARIN members don't actively participate.  I have my own opinions on why this is, but they aren't worth elaborating at this time - in fact, I suspect many ARIN members here on NANOG can speak for themselves if they wanted to.  In any case, this is just my impression.  If you would rather share some statistics on member participation, election fairness, etc, then such facts might be more useful.

> ARIN's bylaws firmly place control of ARIN into the hands of its members.
> if you think that's the wrong approach, i'm curious to hear your reasoning
> and your proposed alternative.

One of ARIN's governance strengths is the availability of petition at many steps, including for candidates rejected by the NomCom.  Likewise, as you noted, leaders are elected by the membership.  For these reasons I previously noted that "ARIN has a pretty good governance structure" and I continue to think so.  It could be improved by increased member involvement, as well as broader involvement from the community. (For instance, policy petitions should include responses from the entire affected community, not just PPML.)  But my criticisms should be interpreted as constructive, and are not an indictment of the whole approach.

Cheers,
-Benson



From vixie at isc.org  Thu Sep 22 23:57:12 2011
From: vixie at isc.org (Paul Vixie)
Date: Fri, 23 Sep 2011 04:57:12 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <171BF180-F19E-49A0-9B78-977F56B09A3E@queuefull.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>
 <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net>
 <g3ipondv0h.fsf@nsa.vix.com>
 <C58EECBC-0ECE-40E9-95E7-A832190E5BC6@queuefull.net>
 <g34o04vzmv.fsf@nsa.vix.com>
 <171BF180-F19E-49A0-9B78-977F56B09A3E@queuefull.net>
Message-ID: <20110923045712.000017c2@unknown>

On Thu, 22 Sep 2011 21:05:51 -0500
Benson Schliesser <bensons at queuefull.net> wrote:

> Earlier this year I received the following from ARIN member
> services:  "This year the NomCom charter was changed by the Board.
> In the past the 3 Member volunteers were selected at random.  This
> year the 3 volunteers will be chosen by the 4 current members of the
> NomCom (2 from the Board 2 from the AC)"

yow.  i should have remembered this, you'd think.

> The above quote was sent to me in response to a query I made,
> inquiring how the NomCom would be chosen in 2011.  It is consistent
> with what I was told in 2010, when I was chosen to be part of the
> 2010 NomCom.  At that time I was told that Member volunteers were
> chosen randomly.  During my NomCom tenure, however, it was suggested
> to me privately that there was very little randomness involved in the
> selection process; I was told that individuals were specifically
> chosen for NomCom.  I don't know what to make of this disparity,
> honestly, which is why I referenced "the appearance of random
> selection".

suggested to you privately by arin staff?

> The NomCom acts as a filter, of sorts.  It chooses the candidates
> that the membership will see.  The fact that the NomCom is so closely
> coupled with the existing leadership has an unfortunate appearance
> that suggests a bias.  I'm unable to say whether the bias exists, is
> recognized, and/or is reflected in the slate of candidates.  But it
> seems like an easy enough thing to avoid.

you seem to mean that the appearance of bias would be easy to avoid,
then.

> As for my use of "existing establishment":  I'm of the impression
> that a relatively small group of individuals drive ARIN, that most
> ARIN members don't actively participate.  I have my own opinions on
> why this is, but they aren't worth elaborating at this time - in
> fact, I suspect many ARIN members here on NANOG can speak for
> themselves if they wanted to.  In any case, this is just my
> impression.  If you would rather share some statistics on member
> participation, election fairness, etc, then such facts might be more
> useful.

i think our participation level in elections is quite high and i'll ask
for details and see them published here.

> > ARIN's bylaws firmly place control of ARIN into the hands of its
> > members. if you think that's the wrong approach, i'm curious to
> > hear your reasoning and your proposed alternative.
> 
> One of ARIN's governance strengths is the availability of petition at
> many steps, including for candidates rejected by the NomCom.
> Likewise, as you noted, leaders are elected by the membership.  For
> these reasons I previously noted that "ARIN has a pretty good
> governance structure" and I continue to think so.  It could be
> improved by increased member involvement, as well as broader
> involvement from the community. (For instance, policy petitions
> should include responses from the entire affected community, not just
> PPML.)  But my criticisms should be interpreted as constructive, and
> are not an indictment of the whole approach.

thanks for saying so.
-- 
Paul Vixie


From jduncan at juniper.net  Fri Sep 23 00:40:40 2011
From: jduncan at juniper.net (Jim Duncan)
Date: Fri, 23 Sep 2011 01:40:40 -0400
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <20110923045712.000017c2@unknown>
Message-ID: <A4C6A166C36F5F40A5767E6F66358FC0BAD175C1EB@EMBX01-WF.jnpr.net>

Paul (and NANOG readers, because Paul actually already knows this),

With my parliamentarian hat on:

A nominating committee's essential function is to ensure that a minimum number of qualified, vetted individuals are placed on the slate of candidates for election. it should never be a gating function; it is an important safeguard to allow the nomination of qualified individuals outside the nominating committee and "from the floor" before votes are cast. 

In the corporate world, nominating committees, for good or bad, have become instruments for rigorously constraining the slate of candidates for executive offices. The practice has become so common and widespread that many assume it is proper in all situations (much in the same way that the US Congress' standing rules modifying the "table" motion have caused the public to believe incorrectly that "tabling an issue" is the same as "postponing it indefinitely"; tabling correctly means the issue will be moved to a later time in the current meeting.

Although organizations may decide for themselves how a nominating committee will operate, it is inconsistent with the general principles of parliamentary process -- whichever standard you choose, Robert's, Sturgis, or another -- for all candidates to be forced to pass through the gauntlet of the nominating committee. In a perfect world, the nominating committee assists with preparations for elections, finds suitable candidates (at least one for every vacant position) and possibly identifies and cultivates future leadership for the organization.

More than my two cents' worth, but I got involved in parliamentary process exactly because of misunderstandings and misapplications like what I think may be happening here.  I'll be happy to explain further, if needed or desired.

I now return you to the more traditional discussions for this mailing list. ;-)

        Jim


--
James N. Duncan, CISSP
Manager, Juniper Networks Security Incident Response Team (Juniper SIRT)
E-mail: jduncan at juniper.net  Mobile: +1 919 608 0748
PGP key fingerprint:  E09E EA55 DA28 1399 75EB  D6A2 7092 9A9C 6DC3 1821


----- Original Message -----
From: Paul Vixie [mailto:vixie at isc.org]
Sent: Friday, September 23, 2011 12:57 AM
To: nanog at nanog.org <nanog at nanog.org>
Subject: Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

On Thu, 22 Sep 2011 21:05:51 -0500
Benson Schliesser <bensons at queuefull.net> wrote:

> Earlier this year I received the following from ARIN member
> services:  "This year the NomCom charter was changed by the Board.
> In the past the 3 Member volunteers were selected at random.  This
> year the 3 volunteers will be chosen by the 4 current members of the
> NomCom (2 from the Board 2 from the AC)"

yow.  i should have remembered this, you'd think.

> The above quote was sent to me in response to a query I made,
> inquiring how the NomCom would be chosen in 2011.  It is consistent
> with what I was told in 2010, when I was chosen to be part of the
> 2010 NomCom.  At that time I was told that Member volunteers were
> chosen randomly.  During my NomCom tenure, however, it was suggested
> to me privately that there was very little randomness involved in the
> selection process; I was told that individuals were specifically
> chosen for NomCom.  I don't know what to make of this disparity,
> honestly, which is why I referenced "the appearance of random
> selection".

suggested to you privately by arin staff?

> The NomCom acts as a filter, of sorts.  It chooses the candidates
> that the membership will see.  The fact that the NomCom is so closely
> coupled with the existing leadership has an unfortunate appearance
> that suggests a bias.  I'm unable to say whether the bias exists, is
> recognized, and/or is reflected in the slate of candidates.  But it
> seems like an easy enough thing to avoid.

you seem to mean that the appearance of bias would be easy to avoid,
then.

> As for my use of "existing establishment":  I'm of the impression
> that a relatively small group of individuals drive ARIN, that most
> ARIN members don't actively participate.  I have my own opinions on
> why this is, but they aren't worth elaborating at this time - in
> fact, I suspect many ARIN members here on NANOG can speak for
> themselves if they wanted to.  In any case, this is just my
> impression.  If you would rather share some statistics on member
> participation, election fairness, etc, then such facts might be more
> useful.

i think our participation level in elections is quite high and i'll ask
for details and see them published here.

> > ARIN's bylaws firmly place control of ARIN into the hands of its
> > members. if you think that's the wrong approach, i'm curious to
> > hear your reasoning and your proposed alternative.
> 
> One of ARIN's governance strengths is the availability of petition at
> many steps, including for candidates rejected by the NomCom.
> Likewise, as you noted, leaders are elected by the membership.  For
> these reasons I previously noted that "ARIN has a pretty good
> governance structure" and I continue to think so.  It could be
> improved by increased member involvement, as well as broader
> involvement from the community. (For instance, policy petitions
> should include responses from the entire affected community, not just
> PPML.)  But my criticisms should be interpreted as constructive, and
> are not an indictment of the whole approach.

thanks for saying so.
-- 
Paul Vixie



From fweimer at bfk.de  Fri Sep 23 02:15:46 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 23 Sep 2011 07:15:46 +0000
Subject: Question on 95th percentile and Over-usage transit pricing
In-Reply-To: <1316656684.2498.36.camel@Pradeep> (Pradeep Bangera's message of
 "Thu, 22 Sep 2011 03:58:04 +0200")
References: <1316656684.2498.36.camel@Pradeep>
Message-ID: <824o03ohjx.fsf@mid.bfk.de>

* Pradeep Bangera:

> Question: Does this over-usage bandwidth charge a linear cost function
> or is it sub-linear like the committed bandwidth pricing?

Percentile-based pricing is never linear.  It's not even a continuous
function of bandwidth usage.  This is inherent to the percentile
functional, so it doesn't matter how the quantity that comes out of that
is priced.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From owen at delong.com  Fri Sep 23 03:01:23 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 23 Sep 2011 01:01:23 -0700
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <171BF180-F19E-49A0-9B78-977F56B09A3E@queuefull.net>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net> <m28vpmc0k5.wl%randy@psg.com>
 <201109181518.10864.a.harrowell@gmail.com> <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net> <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>
 <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net>
 <g3ipondv0h.fsf@nsa.vix.com>
 <C58EECBC-0ECE-40E9-95E7-A832190E5BC6@queuefull.net>
 <g34o04vzmv.fsf@nsa.vix.com>
 <171BF180-F19E-49A0-9B78-977F56B09A3E@queuefull.net>
Message-ID: <277A7743-14E7-4FC2-91D2-E0772F262DFF@delong.com>

> 
> The NomCom acts as a filter, of sorts.  It chooses the candidates that the membership will see.  The fact that the NomCom is so closely coupled with the existing leadership has an unfortunate appearance that suggests a bias.  I'm unable to say whether the bias exists, is recognized, and/or is reflected in the slate of candidates.  But it seems like an easy enough thing to avoid.
> 

This statement ignores the existence of the petition process and the relatively low threshold required to get a candidate not approved or selected by the nomcom onto the ballot if there is even a very limited desire to do so.

> As for my use of "existing establishment":  I'm of the impression that a relatively small group of individuals drive ARIN, that most ARIN members don't actively participate.  I have my own opinions on why this is, but they aren't worth elaborating at this time - in fact, I suspect many ARIN members here on NANOG can speak for themselves if they wanted to.  In any case, this is just my impression.  If you would rather share some statistics on member participation, election fairness, etc, then such facts might be more useful.
> 

My inclination is that the lack of participation generally indicates that the majority are not upset by the way ARIN is doing things. I know that the beginning of my participation in ARIN was the result of my deciding that some of the ways ARIN was doing things needed changing.

>> ARIN's bylaws firmly place control of ARIN into the hands of its members.
>> if you think that's the wrong approach, i'm curious to hear your reasoning
>> and your proposed alternative.
> 
> One of ARIN's governance strengths is the availability of petition at many steps, including for candidates rejected by the NomCom.  Likewise, as you noted, leaders are elected by the membership.  For these reasons I previously noted that "ARIN has a pretty good governance structure" and I continue to think so.  It could be improved by increased member involvement, as well as broader involvement from the community. (For instance, policy petitions should include responses from the entire affected community, not just PPML.)  But my criticisms should be interpreted as constructive, and are not an indictment of the whole approach.
> 

OK, so you are aware of the petition process after all. That makes your statement at the top of this message somewhat perplexing.

I agree that increased member participation would be a good thing.

I do not believe that including petition responses from people who aren't willing to join PPML even if it's just long enough to support the petition in question would be useful. It takes almost no effort to join PPML, support a petition, and then leave PPML if you are that determined not to participate. Further, I think that it is reasonable to expect at least a modicum of participation in the policy process in order to participate in the petition process. Requiring supporters to be on PPML at the time they support the petition seems like a reasonable threshold to me. Finally, absent some mechanism such as requiring a PPML subscription, it might be somewhat difficult to avoid petition stuffing.

Owen



From jcurran at arin.net  Fri Sep 23 04:51:46 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 23 Sep 2011 09:51:46 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <20110923045712.000017c2@unknown>
References: <D181DDABABE57E4DB72FEE00331478643C0A52@EALPO1.ukbroadband.com>
 <65DFC547-ADF6-4B21-8646-2F71E10AAFD0@arin.net>
 <m28vpmc0k5.wl%randy@psg.com> <201109181518.10864.a.harrowell@gmail.com>
 <m2ty8a9be3.wl%randy@psg.com>
 <CC163246-EEE5-44D0-8651-2555FBC4DC32@arin.net>
 <m2sjntaos3.wl%randy@psg.com>
 <38D128A4-627A-4160-BD38-40FE3DF57318@queuefull.net>
 <B113B2BF-03F4-4E1C-9843-BF46B7526039@arin.net>
 <66794606-C40E-4EDF-A62F-A0F53CB61C6D@queuefull.net>
 <g3ipondv0h.fsf@nsa.vix.com>
 <C58EECBC-0ECE-40E9-95E7-A832190E5BC6@queuefull.net>
 <g34o04vzmv.fsf@nsa.vix.com>
 <171BF180-F19E-49A0-9B78-977F56B09A3E@queuefull.net>
 <20110923045712.000017c2@unknown>
Message-ID: <BCFADB61-9052-434E-BCA9-2EE7170EC339@arin.net>

On Sep 23, 2011, at 12:57 AM, Paul Vixie wrote:

> On Thu, 22 Sep 2011 21:05:51 -0500
> Benson Schliesser <bensons at queuefull.net> wrote:
> 
>> As for my use of "existing establishment":  I'm of the impression
>> that a relatively small group of individuals drive ARIN, that most
>> ARIN members don't actively participate.  I have my own opinions on
>> why this is, but they aren't worth elaborating at this time - in
>> fact, I suspect many ARIN members here on NANOG can speak for
>> themselves if they wanted to.  In any case, this is just my
>> impression.  If you would rather share some statistics on member
>> participation, election fairness, etc, then such facts might be more
>> useful.
> 
> i think our participation level in elections is quite high and i'll ask
> for details and see them published here.

Paul - 
 
  Information regarding ARIN's last election is online here:

   <https://www.arin.net/announcements/2010/20101019_ElectionWinners.html>

  I've attached the relevant section regarding participation, and it should
  be noted that more than 12% of the potential electorate voted in last year's 
  election.  This is typical turnout for our elections, and while I have been
  told anecdotally that this is relatively high turnout for membership 
  organization, I do not have hard data points for comparison at this time.

  I would encourage all NANOG members to confirm their designated member
  representatives with ARIN (i.e. the official organizational contacts) and 
  vote (or if someone else in your organization encourage them to do so) in
  the upcoming ARIN election for the ARIN Advisory Council and the ARIN Board 
  of Trustee positions.

FYI,
/John

John Curran
President and CEO
ARIN

=== From  <https://www.arin.net/announcements/2010/20101019_ElectionWinners.html>

2010 VOTER STATISTICS 

3,690 ARIN members as of 21 September 2010 

2,834 Eligible voters* as of 21 September 2010 

   *ARIN members in good standing with properly registered Designated Member Representatives on record 1 January 2010 

355 unique member organizations cast a ballot in the Board of Trustees election. 

356 unique member organizations cast a ballot in the Advisory Council election. 

364 unique member organizations cast a ballot in either the Board of Trustees or Advisory Council election




From jcurran at arin.net  Fri Sep 23 05:35:02 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 23 Sep 2011 10:35:02 +0000
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <A4C6A166C36F5F40A5767E6F66358FC0BAD175C1EB@EMBX01-WF.jnpr.net>
References: <A4C6A166C36F5F40A5767E6F66358FC0BAD175C1EB@EMBX01-WF.jnpr.net>
Message-ID: <AFB08AFB-3443-4AB1-9739-2BA9E6992F45@arin.net>

On Sep 23, 2011, at 1:40 AM, Jim Duncan wrote:
> With my parliamentarian hat on:
> A nominating committee's essential function is to ensure that a minimum number of qualified, vetted individuals are placed on the slate of candidates for election. it should never be a gating function; it is an important safeguard to allow the nomination of qualified individuals outside the nominating committee and "from the floor" before votes are cast. 
> ...

> Although organizations may decide for themselves how a nominating committee will operate, it is inconsistent with the general principles of parliamentary process -- whichever standard you choose, Robert's, Sturgis, or another -- for all candidates to be forced to pass through the gauntlet of the nominating committee. 

Jim - 
  
  I agree with you in principle regarding the NomCom's essential 
  function, but note that your requirement that the Nominating 
  Committee pass _all_ candidates minimally qualified is not the 
  only valid approach.  In the case of ARIN, the NomCom process
  provides a sufficient number of qualified qualified candidates
  but is specifically not required to provide all such candidates
  <https://www.arin.net/participate/elections/nomcom_faqs.html>

  The protection of the parliamentary representation principle that
  you allude to (i.e. the freedom for members of an organization to 
  choose its own leadership) to is instead provided via a petition 
  process.  This mechanism provides a comparable safeguard by allowing
  anyone to be added to the ballot if they desire such and can show 
  some support in the community for their candidacy.

  Note that ARIN's initial Bylaws only provided for direct selection 
  of new Board members by the ARIN Board from a list of candidates 
  chosen by the ARIN AC.  In subsequent years, this was changed to be 
  a separate NomCom, and a petition process requiring support of 15% 
  of the electorate was added. The petition threshold was then lowered 
  to 5% of the electorate, and then again recently lowered to be now
  2% of the electorate. The ARIN Board has reviewed the election process 
  in each of the recent years to see if any further changes are required.

  Further evolution of this process is quite possible, and discussion
  here (or on an ARIN mailing list) will help inform the ARIN Board 
  about the community views on this matter.

Thanks!
/John

John Curran
President and CEO
ARIN



From rsm at fast-serv.com  Fri Sep 23 05:56:05 2011
From: rsm at fast-serv.com (Randy McAnally)
Date: Fri, 23 Sep 2011 06:56:05 -0400
Subject: Verizon / FiOS network
In-Reply-To: <cdae61c9e0158c7c03921c4a587bc221.squirrel@wm.horrible.net>
References: <6b8e973364bb465f5fe35c583271d756.squirrel@wm.horrible.net>
 <CAL9jLaZexGQFPKQV+1tciHp8DAktxs0yrx+Wx7N=5W7jsrwJ5Q@mail.gmail.com>
 <cdae61c9e0158c7c03921c4a587bc221.squirrel@wm.horrible.net>
Message-ID: <CACA4923-5E3B-4A8A-A699-3F2634476E4D@fast-serv.com>

Not able to connect to 146.115.38.21 via fios or verizon 3g so the problem doesn't seem to be fios specific. 

Sent from my IPhone (pardon the typo's)

On Sep 22, 2011, at 9:32 PM, "Ryan Pugatch" <rpug at linux.com> wrote:

>> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
>>> Hi,
>>> 
>>> Anyone noticing anything weird with the Verizon / FiOS network?
>>> 
>>> Seems like many people on their network are having trouble getting to us
>>> (on Sidera / RCN) but not everyone.
>>> 
>> 
>> it's, obviously, simpler to help diagnose this when you provide some
>> semblance of destination address, port, protocol...
>> 
>> just sayin'!
>> 
>> -chris
>> (fios user who could help, if only there was enough info to go on)
>> 
>> 
> 
> HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21
> 

From ryan at u13.net  Fri Sep 23 08:35:16 2011
From: ryan at u13.net (Ryan Rawdon)
Date: Fri, 23 Sep 2011 09:35:16 -0400
Subject: Verizon / FiOS network
In-Reply-To: <cdae61c9e0158c7c03921c4a587bc221.squirrel@wm.horrible.net>
References: <6b8e973364bb465f5fe35c583271d756.squirrel@wm.horrible.net>
 <CAL9jLaZexGQFPKQV+1tciHp8DAktxs0yrx+Wx7N=5W7jsrwJ5Q@mail.gmail.com>
 <cdae61c9e0158c7c03921c4a587bc221.squirrel@wm.horrible.net>
Message-ID: <A323BE5B-FD0C-4AC5-8198-8CE7E3DDD632@u13.net>


On Sep 22, 2011, at 9:32 PM, Ryan Pugatch wrote:

>> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
>>> Hi,
>>> 
>>> Anyone noticing anything weird with the Verizon / FiOS network?
>>> 
>>> Seems like many people on their network are having trouble getting to us
>>> (on Sidera / RCN) but not everyone.
>>> 
>> 
>> it's, obviously, simpler to help diagnose this when you provide some
>> semblance of destination address, port, protocol...
>> 
>> just sayin'!
>> 
>> -chris
>> (fios user who could help, if only there was enough info to go on)
>> 
>> 
> 
> HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21
> 
> 

From FiOS and non-FiOS locations I get the same result:

HTTP: timeout
HTTPS: connects and loads (Zimbra webmail page)
also can ping via ICMP just fine


Traceroute from fios is via Level3 from the DC area to Boston where it is handed off to RCN and then 2 hops to the destination

From tknchris at gmail.com  Fri Sep 23 08:38:26 2011
From: tknchris at gmail.com (chris)
Date: Fri, 23 Sep 2011 09:38:26 -0400
Subject: Verizon / FiOS network
In-Reply-To: <A323BE5B-FD0C-4AC5-8198-8CE7E3DDD632@u13.net>
References: <6b8e973364bb465f5fe35c583271d756.squirrel@wm.horrible.net>
 <CAL9jLaZexGQFPKQV+1tciHp8DAktxs0yrx+Wx7N=5W7jsrwJ5Q@mail.gmail.com>
 <cdae61c9e0158c7c03921c4a587bc221.squirrel@wm.horrible.net>
 <A323BE5B-FD0C-4AC5-8198-8CE7E3DDD632@u13.net>
Message-ID: <CAKnNFz-m+mrdbZPA8bwhoCBD+Bp-Ko6TAhP-voS4cn9BmQV6TA@mail.gmail.com>

HTTP doesnt appear to be open from any network I try Verizon or otherwise so
I'm not sure its network related

On Fri, Sep 23, 2011 at 9:35 AM, Ryan Rawdon <ryan at u13.net> wrote:

>
> On Sep 22, 2011, at 9:32 PM, Ryan Pugatch wrote:
>
> >> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
> >>> Hi,
> >>>
> >>> Anyone noticing anything weird with the Verizon / FiOS network?
> >>>
> >>> Seems like many people on their network are having trouble getting to
> us
> >>> (on Sidera / RCN) but not everyone.
> >>>
> >>
> >> it's, obviously, simpler to help diagnose this when you provide some
> >> semblance of destination address, port, protocol...
> >>
> >> just sayin'!
> >>
> >> -chris
> >> (fios user who could help, if only there was enough info to go on)
> >>
> >>
> >
> > HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21
> >
> >
>
> From FiOS and non-FiOS locations I get the same result:
>
> HTTP: timeout
> HTTPS: connects and loads (Zimbra webmail page)
> also can ping via ICMP just fine
>
>
> Traceroute from fios is via Level3 from the DC area to Boston where it is
> handed off to RCN and then 2 hops to the destination
>

From jra at baylink.com  Fri Sep 23 09:17:38 2011
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 23 Sep 2011 10:17:38 -0400 (EDT)
Subject: Commercial DNS service opinions?
Message-ID: <25076238.2837.1316787458644.JavaMail.root@benjamin.baylink.com>

Open, Super, Dyn?

Will any of them do hidden-master?

Off list; I'll summarize.

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      http://photo.imageinc.us             +1 727 647 1274


From morrowc.lists at gmail.com  Fri Sep 23 09:40:37 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 23 Sep 2011 10:40:37 -0400
Subject: Commercial DNS service opinions?
In-Reply-To: <25076238.2837.1316787458644.JavaMail.root@benjamin.baylink.com>
References: <25076238.2837.1316787458644.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAL9jLaaPc=YVOtKkL8G1p_TqFWPj8VyzGz=rapfNSy0vYREujA@mail.gmail.com>

On Fri, Sep 23, 2011 at 10:17 AM, Jay Ashworth <jra at baylink.com> wrote:
> Open, Super, Dyn?
>
> Will any of them do hidden-master?
>
> Off list; I'll summarize.

recursive AND authoritative? or ?


From bill at herrin.us  Fri Sep 23 10:14:16 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 23 Sep 2011 11:14:16 -0400
Subject: Verizon / FiOS network
In-Reply-To: <cdae61c9e0158c7c03921c4a587bc221.squirrel@wm.horrible.net>
References: <6b8e973364bb465f5fe35c583271d756.squirrel@wm.horrible.net>
 <CAL9jLaZexGQFPKQV+1tciHp8DAktxs0yrx+Wx7N=5W7jsrwJ5Q@mail.gmail.com>
 <cdae61c9e0158c7c03921c4a587bc221.squirrel@wm.horrible.net>
Message-ID: <CAP-guGUkPeEVtEzEiM=ucOsoswdbw6egdtcKm79x3AE2AmP_hQ@mail.gmail.com>

On Thu, Sep 22, 2011 at 9:32 PM, Ryan Pugatch <rpug at linux.com> wrote:
>> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
>>> Hi,
>>>
>>> Anyone noticing anything weird with the Verizon / FiOS network?
>>>
>>> Seems like many people on their network are having trouble getting to us
>>> (on Sidera / RCN) but not everyone.
>>>
>>
>> it's, obviously, simpler to help diagnose this when you provide some
>> semblance of destination address, port, protocol...
>>
>> just sayin'!
>>
>> -chris
>> (fios user who could help, if only there was enough info to go on)
>>
>>
>
> HTTP/HTTPS over 80, 443. ?Sample IP: 146.115.38.21


Firewalled at or near 146.115.38.21. It allows ICMP, TCP 25 and TCP
443 but not TCP 80.

[lily:kroot:/home/kroot:!] traceroute -T -p 25 146.115.38.21
traceroute to 146.115.38.21 (146.115.38.21), 30 hops max, 40 byte packets
 1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.295 ms
0.989 ms  1.111 ms
 2  G0-3-4-3.WASHDC-LCR-22.verizon-gni.net (130.81.48.122)  1.431 ms
1.838 ms  1.533 ms
 3  so-3-1-0-0.RES-BB-RTR2.verizon-gni.net (130.81.151.232)  1.580 ms
1.628 ms  1.601 ms
 4  0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158)  3.524 ms  3.716 ms  3.448 ms
 5  * * *
 6  vlan52.ebr2.Washington12.Level3.net (4.69.146.222)  2.449 ms
3.238 ms  2.441 ms
 7  4.69.148.49 (4.69.148.49)  9.562 ms  9.403 ms  9.354 ms
 8  ae-1-8.bar2.Boston1.Level3.net (4.69.140.97)  14.749 ms  14.622 ms
 14.627 ms
 9  RCN-CORPORA.bar2.Boston1.Level3.net (4.53.50.14)  17.960 ms
17.906 ms  17.924 ms
10  port-chan8.aggr1.sbo.ma.rcn.net (207.172.15.151)  18.603 ms
18.589 ms  18.866 ms
11  207.172.19.247 (207.172.19.247)  13.466 ms  13.524 ms  13.580 ms
12  webmail.tripadvisor.com (146.115.38.21)  17.950 ms  17.897 ms  17.935 ms

[lily:kroot:/home/kroot:!] traceroute -T -p 80 146.115.38.21
traceroute to 146.115.38.21 (146.115.38.21), 30 hops max, 40 byte packets
 1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  2.072 ms
1.712 ms  1.506 ms
 2  G0-3-4-3.WASHDC-LCR-22.verizon-gni.net (130.81.48.122)  2.180 ms
1.991 ms  2.021 ms
 3  so-3-1-0-0.RES-BB-RTR2.verizon-gni.net (130.81.151.232)  1.693 ms
1.479 ms  1.676 ms
 4  0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158)  3.441 ms  3.616 ms  3.426 ms
 5  * * *
 6  vlan52.ebr2.Washington12.Level3.net (4.69.146.222)  2.415 ms
2.994 ms  2.729 ms
 7  4.69.148.49 (4.69.148.49)  9.822 ms  9.314 ms  9.478 ms
 8  ae-1-8.bar2.Boston1.Level3.net (4.69.140.97)  14.695 ms  14.982 ms
 14.598 ms
 9  RCN-CORPORA.bar2.Boston1.Level3.net (4.53.50.14)  18.395 ms
18.315 ms  18.179 ms
10  port-chan8.aggr1.sbo.ma.rcn.net (207.172.15.151)  18.366 ms
18.476 ms  18.511 ms
11  207.172.19.247 (207.172.19.247)  13.857 ms  14.040 ms  13.508 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  *^C



-- 
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 pradeep.bangera at imdea.org  Fri Sep 23 11:45:43 2011
From: pradeep.bangera at imdea.org (Pradeep Bangera)
Date: Fri, 23 Sep 2011 18:45:43 +0200
Subject: NANOG Digest, Vol 44, Issue 103
In-Reply-To: <mailman.9019.1316788838.1873.nanog@nanog.org>
References: <mailman.9019.1316788838.1873.nanog@nanog.org>
Message-ID: <1316796343.2532.55.camel@Pradeep>

Dear All,

Thanks for all the replies! I would like to see more, to learn more!

Since I (Research Assistant) am not from network operations and
management domain, I am trying to model the transit pricing function. In
my research work, I am using a pricing model from this work! This
pricing model is as follows:-- Transit price = Constant * (aggregate
traffic)^0.75, which is exactly similar to the one described by Ryan
Malayter in his earlier message. Hence I am wondering, whether the
pricing should be a linear(CDR*[95th peak]) or sub-linear (like the
above)?

With Regards
Pradeep
Research Assistant
Institute IMDEA Networks
Madrid, Spain


On Fri, 2011-09-23 at 09:40 -0500, nanog-request at nanog.org wrote:

> Send NANOG mailing list submissions to
> 	nanog at nanog.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://mailman.nanog.org/mailman/listinfo/nanog
> or, via email, send a message with subject or body 'help' to
> 	nanog-request at nanog.org
> 
> You can reach the person managing the list at
> 	nanog-owner at nanog.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NANOG digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Question on 95th percentile and Over-usage transit
>       pricing (Florian Weimer)
>    2. Re: wet-behind-the-ears whippersnapper seeking advice on
>       building a nationwide network (Owen DeLong)
>    3. Re: wet-behind-the-ears whippersnapper seeking advice on
>       building a nationwide network (John Curran)
>    4. Re: wet-behind-the-ears whippersnapper seeking advice on
>       building a nationwide network (John Curran)
>    5. Re: Verizon / FiOS network (Randy McAnally)
>    6. Re: Verizon / FiOS network (Ryan Rawdon)
>    7. Re: Verizon / FiOS network (chris)
>    8. Commercial DNS service opinions? (Jay Ashworth)
>    9. Re: Commercial DNS service opinions? (Christopher Morrow)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 23 Sep 2011 07:15:46 +0000
> From: Florian Weimer <fweimer at bfk.de>
> To: Pradeep Bangera <pradeep.bangera at imdea.org>
> Cc: nanog at nanog.org
> Subject: Re: Question on 95th percentile and Over-usage transit
> 	pricing
> Message-ID: <824o03ohjx.fsf at mid.bfk.de>
> Content-Type: text/plain; charset=iso-8859-1
> 
> * Pradeep Bangera:
> 
> > Question: Does this over-usage bandwidth charge a linear cost function
> > or is it sub-linear like the committed bandwidth pricing?
> 
> Percentile-based pricing is never linear.  It's not even a continuous
> function of bandwidth usage.  This is inherent to the percentile
> functional, so it doesn't matter how the quantity that comes out of that
> is priced.
> 
> -- 
> Florian Weimer                <fweimer at bfk.de>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstra?e 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 23 Sep 2011 01:01:23 -0700
> From: Owen DeLong <owen at delong.com>
> To: Benson Schliesser <bensons at queuefull.net>
> Cc: Paul Vixie <vixie at isc.org>, nanog at nanog.org
> Subject: Re: wet-behind-the-ears whippersnapper seeking advice on
> 	building a nationwide network
> Message-ID: <277A7743-14E7-4FC2-91D2-E0772F262DFF at delong.com>
> Content-Type: text/plain; charset=us-ascii
> 
> > 
> > The NomCom acts as a filter, of sorts.  It chooses the candidates that the membership will see.  The fact that the NomCom is so closely coupled with the existing leadership has an unfortunate appearance that suggests a bias.  I'm unable to say whether the bias exists, is recognized, and/or is reflected in the slate of candidates.  But it seems like an easy enough thing to avoid.
> > 
> 
> This statement ignores the existence of the petition process and the relatively low threshold required to get a candidate not approved or selected by the nomcom onto the ballot if there is even a very limited desire to do so.
> 
> > As for my use of "existing establishment":  I'm of the impression that a relatively small group of individuals drive ARIN, that most ARIN members don't actively participate.  I have my own opinions on why this is, but they aren't worth elaborating at this time - in fact, I suspect many ARIN members here on NANOG can speak for themselves if they wanted to.  In any case, this is just my impression.  If you would rather share some statistics on member participation, election fairness, etc, then such facts might be more useful.
> > 
> 
> My inclination is that the lack of participation generally indicates that the majority are not upset by the way ARIN is doing things. I know that the beginning of my participation in ARIN was the result of my deciding that some of the ways ARIN was doing things needed changing.
> 
> >> ARIN's bylaws firmly place control of ARIN into the hands of its members.
> >> if you think that's the wrong approach, i'm curious to hear your reasoning
> >> and your proposed alternative.
> > 
> > One of ARIN's governance strengths is the availability of petition at many steps, including for candidates rejected by the NomCom.  Likewise, as you noted, leaders are elected by the membership.  For these reasons I previously noted that "ARIN has a pretty good governance structure" and I continue to think so.  It could be improved by increased member involvement, as well as broader involvement from the community. (For instance, policy petitions should include responses from the entire affected community, not just PPML.)  But my criticisms should be interpreted as constructive, and are not an indictment of the whole approach.
> > 
> 
> OK, so you are aware of the petition process after all. That makes your statement at the top of this message somewhat perplexing.
> 
> I agree that increased member participation would be a good thing.
> 
> I do not believe that including petition responses from people who aren't willing to join PPML even if it's just long enough to support the petition in question would be useful. It takes almost no effort to join PPML, support a petition, and then leave PPML if you are that determined not to participate. Further, I think that it is reasonable to expect at least a modicum of participation in the policy process in order to participate in the petition process. Requiring supporters to be on PPML at the time they support the petition seems like a reasonable threshold to me. Finally, absent some mechanism such as requiring a PPML subscription, it might be somewhat difficult to avoid petition stuffing.
> 
> Owen
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 23 Sep 2011 09:51:46 +0000
> From: John Curran <jcurran at arin.net>
> To: Paul Vixie <vixie at isc.org>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: wet-behind-the-ears whippersnapper seeking advice on
> 	building a nationwide network
> Message-ID: <BCFADB61-9052-434E-BCA9-2EE7170EC339 at arin.net>
> Content-Type: text/plain; charset="us-ascii"
> 
> On Sep 23, 2011, at 12:57 AM, Paul Vixie wrote:
> 
> > On Thu, 22 Sep 2011 21:05:51 -0500
> > Benson Schliesser <bensons at queuefull.net> wrote:
> > 
> >> As for my use of "existing establishment":  I'm of the impression
> >> that a relatively small group of individuals drive ARIN, that most
> >> ARIN members don't actively participate.  I have my own opinions on
> >> why this is, but they aren't worth elaborating at this time - in
> >> fact, I suspect many ARIN members here on NANOG can speak for
> >> themselves if they wanted to.  In any case, this is just my
> >> impression.  If you would rather share some statistics on member
> >> participation, election fairness, etc, then such facts might be more
> >> useful.
> > 
> > i think our participation level in elections is quite high and i'll ask
> > for details and see them published here.
> 
> Paul - 
>  
>   Information regarding ARIN's last election is online here:
> 
>    <https://www.arin.net/announcements/2010/20101019_ElectionWinners.html>
> 
>   I've attached the relevant section regarding participation, and it should
>   be noted that more than 12% of the potential electorate voted in last year's 
>   election.  This is typical turnout for our elections, and while I have been
>   told anecdotally that this is relatively high turnout for membership 
>   organization, I do not have hard data points for comparison at this time.
> 
>   I would encourage all NANOG members to confirm their designated member
>   representatives with ARIN (i.e. the official organizational contacts) and 
>   vote (or if someone else in your organization encourage them to do so) in
>   the upcoming ARIN election for the ARIN Advisory Council and the ARIN Board 
>   of Trustee positions.
> 
> FYI,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> === From  <https://www.arin.net/announcements/2010/20101019_ElectionWinners.html>
> 
> 2010 VOTER STATISTICS 
> 
> 3,690 ARIN members as of 21 September 2010 
> 
> 2,834 Eligible voters* as of 21 September 2010 
> 
>    *ARIN members in good standing with properly registered Designated Member Representatives on record 1 January 2010 
> 
> 355 unique member organizations cast a ballot in the Board of Trustees election. 
> 
> 356 unique member organizations cast a ballot in the Advisory Council election. 
> 
> 364 unique member organizations cast a ballot in either the Board of Trustees or Advisory Council election
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 23 Sep 2011 10:35:02 +0000
> From: John Curran <jcurran at arin.net>
> To: Jim Duncan <jduncan at juniper.net>
> Cc: "vixie at isc.org" <vixie at isc.org>, "nanog at nanog.org"
> 	<nanog at nanog.org>
> Subject: Re: wet-behind-the-ears whippersnapper seeking advice on
> 	building a nationwide network
> Message-ID: <AFB08AFB-3443-4AB1-9739-2BA9E6992F45 at arin.net>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Sep 23, 2011, at 1:40 AM, Jim Duncan wrote:
> > With my parliamentarian hat on:
> > A nominating committee's essential function is to ensure that a minimum number of qualified, vetted individuals are placed on the slate of candidates for election. it should never be a gating function; it is an important safeguard to allow the nomination of qualified individuals outside the nominating committee and "from the floor" before votes are cast. 
> > ...
> 
> > Although organizations may decide for themselves how a nominating committee will operate, it is inconsistent with the general principles of parliamentary process -- whichever standard you choose, Robert's, Sturgis, or another -- for all candidates to be forced to pass through the gauntlet of the nominating committee. 
> 
> Jim - 
>   
>   I agree with you in principle regarding the NomCom's essential 
>   function, but note that your requirement that the Nominating 
>   Committee pass _all_ candidates minimally qualified is not the 
>   only valid approach.  In the case of ARIN, the NomCom process
>   provides a sufficient number of qualified qualified candidates
>   but is specifically not required to provide all such candidates
>   <https://www.arin.net/participate/elections/nomcom_faqs.html>
> 
>   The protection of the parliamentary representation principle that
>   you allude to (i.e. the freedom for members of an organization to 
>   choose its own leadership) to is instead provided via a petition 
>   process.  This mechanism provides a comparable safeguard by allowing
>   anyone to be added to the ballot if they desire such and can show 
>   some support in the community for their candidacy.
> 
>   Note that ARIN's initial Bylaws only provided for direct selection 
>   of new Board members by the ARIN Board from a list of candidates 
>   chosen by the ARIN AC.  In subsequent years, this was changed to be 
>   a separate NomCom, and a petition process requiring support of 15% 
>   of the electorate was added. The petition threshold was then lowered 
>   to 5% of the electorate, and then again recently lowered to be now
>   2% of the electorate. The ARIN Board has reviewed the election process 
>   in each of the recent years to see if any further changes are required.
> 
>   Further evolution of this process is quite possible, and discussion
>   here (or on an ARIN mailing list) will help inform the ARIN Board 
>   about the community views on this matter.
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Fri, 23 Sep 2011 06:56:05 -0400
> From: Randy McAnally <rsm at fast-serv.com>
> To: "rpug at linux.com" <rpug at linux.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: Verizon / FiOS network
> Message-ID: <CACA4923-5E3B-4A8A-A699-3F2634476E4D at fast-serv.com>
> Content-Type: text/plain;	charset=us-ascii
> 
> Not able to connect to 146.115.38.21 via fios or verizon 3g so the problem doesn't seem to be fios specific. 
> 
> Sent from my IPhone (pardon the typo's)
> 
> On Sep 22, 2011, at 9:32 PM, "Ryan Pugatch" <rpug at linux.com> wrote:
> 
> >> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
> >>> Hi,
> >>> 
> >>> Anyone noticing anything weird with the Verizon / FiOS network?
> >>> 
> >>> Seems like many people on their network are having trouble getting to us
> >>> (on Sidera / RCN) but not everyone.
> >>> 
> >> 
> >> it's, obviously, simpler to help diagnose this when you provide some
> >> semblance of destination address, port, protocol...
> >> 
> >> just sayin'!
> >> 
> >> -chris
> >> (fios user who could help, if only there was enough info to go on)
> >> 
> >> 
> > 
> > HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21
> > 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Fri, 23 Sep 2011 09:35:16 -0400
> From: Ryan Rawdon <ryan at u13.net>
> To: rpug at linux.com
> Cc: nanog at nanog.org
> Subject: Re: Verizon / FiOS network
> Message-ID: <A323BE5B-FD0C-4AC5-8198-8CE7E3DDD632 at u13.net>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> On Sep 22, 2011, at 9:32 PM, Ryan Pugatch wrote:
> 
> >> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
> >>> Hi,
> >>> 
> >>> Anyone noticing anything weird with the Verizon / FiOS network?
> >>> 
> >>> Seems like many people on their network are having trouble getting to us
> >>> (on Sidera / RCN) but not everyone.
> >>> 
> >> 
> >> it's, obviously, simpler to help diagnose this when you provide some
> >> semblance of destination address, port, protocol...
> >> 
> >> just sayin'!
> >> 
> >> -chris
> >> (fios user who could help, if only there was enough info to go on)
> >> 
> >> 
> > 
> > HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21
> > 
> > 
> 
> >From FiOS and non-FiOS locations I get the same result:
> 
> HTTP: timeout
> HTTPS: connects and loads (Zimbra webmail page)
> also can ping via ICMP just fine
> 
> 
> Traceroute from fios is via Level3 from the DC area to Boston where it is handed off to RCN and then 2 hops to the destination
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Fri, 23 Sep 2011 09:38:26 -0400
> From: chris <tknchris at gmail.com>
> To: Ryan Rawdon <ryan at u13.net>
> Cc: nanog at nanog.org
> Subject: Re: Verizon / FiOS network
> Message-ID:
> 	<CAKnNFz-m+mrdbZPA8bwhoCBD+Bp-Ko6TAhP-voS4cn9BmQV6TA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> HTTP doesnt appear to be open from any network I try Verizon or otherwise so
> I'm not sure its network related
> 
> On Fri, Sep 23, 2011 at 9:35 AM, Ryan Rawdon <ryan at u13.net> wrote:
> 
> >
> > On Sep 22, 2011, at 9:32 PM, Ryan Pugatch wrote:
> >
> > >> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
> > >>> Hi,
> > >>>
> > >>> Anyone noticing anything weird with the Verizon / FiOS network?
> > >>>
> > >>> Seems like many people on their network are having trouble getting to
> > us
> > >>> (on Sidera / RCN) but not everyone.
> > >>>
> > >>
> > >> it's, obviously, simpler to help diagnose this when you provide some
> > >> semblance of destination address, port, protocol...
> > >>
> > >> just sayin'!
> > >>
> > >> -chris
> > >> (fios user who could help, if only there was enough info to go on)
> > >>
> > >>
> > >
> > > HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21
> > >
> > >
> >
> > From FiOS and non-FiOS locations I get the same result:
> >
> > HTTP: timeout
> > HTTPS: connects and loads (Zimbra webmail page)
> > also can ping via ICMP just fine
> >
> >
> > Traceroute from fios is via Level3 from the DC area to Boston where it is
> > handed off to RCN and then 2 hops to the destination
> >
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Fri, 23 Sep 2011 10:17:38 -0400 (EDT)
> From: Jay Ashworth <jra at baylink.com>
> To: NANOG <nanog at nanog.org>
> Subject: Commercial DNS service opinions?
> Message-ID:
> 	<25076238.2837.1316787458644.JavaMail.root at benjamin.baylink.com>
> Content-Type: text/plain; charset=utf-8
> 
> Open, Super, Dyn?
> 
> Will any of them do hidden-master?
> 
> Off list; I'll summarize.
> 
> 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      http://photo.imageinc.us             +1 727 647 1274
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Fri, 23 Sep 2011 10:40:37 -0400
> From: Christopher Morrow <morrowc.lists at gmail.com>
> To: Jay Ashworth <jra at baylink.com>
> Cc: NANOG <nanog at nanog.org>
> Subject: Re: Commercial DNS service opinions?
> Message-ID:
> 	<CAL9jLaaPc=YVOtKkL8G1p_TqFWPj8VyzGz=rapfNSy0vYREujA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Fri, Sep 23, 2011 at 10:17 AM, Jay Ashworth <jra at baylink.com> wrote:
> > Open, Super, Dyn?
> >
> > Will any of them do hidden-master?
> >
> > Off list; I'll summarize.
> 
> recursive AND authoritative? or ?
> 
> 
> 
> End of NANOG Digest, Vol 44, Issue 103
> **************************************



From pradeep.bangera at imdea.org  Fri Sep 23 11:51:59 2011
From: pradeep.bangera at imdea.org (Pradeep Bangera)
Date: Fri, 23 Sep 2011 18:51:59 +0200
Subject: Question on 95th percentile and Over-usage transit
In-Reply-To: <mailman.9019.1316788838.1873.nanog@nanog.org>
References: <mailman.9019.1316788838.1873.nanog@nanog.org>
Message-ID: <1316796719.2532.58.camel@Pradeep>

*//Sorry for the earlier misguiding email subject//*

Dear All,

Thanks for all the replies! I would like to see more, to learn more!

Since I (Research Assistant) am not from network operations and
management domain, I am trying to model the transit pricing function. In
my research work, I am using a pricing model from this work! This
pricing model is as follows:-- Transit price = Constant * (aggregate
traffic)^0.75, which is exactly similar to the one described by Ryan
Malayter in his earlier message. Hence I am wondering, whether the
pricing should be a linear(CDR*[95th peak]) or sub-linear (like the
above)?

With Regards
Pradeep
Research Assistant
Institute IMDEA Networks
Madrid, Spain


On Fri, 2011-09-23 at 09:40 -0500, nanog-request at nanog.org wrote:
> Send NANOG mailing list submissions to
> 	nanog at nanog.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://mailman.nanog.org/mailman/listinfo/nanog
> or, via email, send a message with subject or body 'help' to
> 	nanog-request at nanog.org
> 
> You can reach the person managing the list at
> 	nanog-owner at nanog.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NANOG digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Question on 95th percentile and Over-usage transit
>       pricing (Florian Weimer)
>    2. Re: wet-behind-the-ears whippersnapper seeking advice on
>       building a nationwide network (Owen DeLong)
>    3. Re: wet-behind-the-ears whippersnapper seeking advice on
>       building a nationwide network (John Curran)
>    4. Re: wet-behind-the-ears whippersnapper seeking advice on
>       building a nationwide network (John Curran)
>    5. Re: Verizon / FiOS network (Randy McAnally)
>    6. Re: Verizon / FiOS network (Ryan Rawdon)
>    7. Re: Verizon / FiOS network (chris)
>    8. Commercial DNS service opinions? (Jay Ashworth)
>    9. Re: Commercial DNS service opinions? (Christopher Morrow)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 23 Sep 2011 07:15:46 +0000
> From: Florian Weimer <fweimer at bfk.de>
> To: Pradeep Bangera <pradeep.bangera at imdea.org>
> Cc: nanog at nanog.org
> Subject: Re: Question on 95th percentile and Over-usage transit
> 	pricing
> Message-ID: <824o03ohjx.fsf at mid.bfk.de>
> Content-Type: text/plain; charset=iso-8859-1
> 
> * Pradeep Bangera:
> 
> > Question: Does this over-usage bandwidth charge a linear cost function
> > or is it sub-linear like the committed bandwidth pricing?
> 
> Percentile-based pricing is never linear.  It's not even a continuous
> function of bandwidth usage.  This is inherent to the percentile
> functional, so it doesn't matter how the quantity that comes out of that
> is priced.
> 
> -- 
> Florian Weimer                <fweimer at bfk.de>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstra?e 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 23 Sep 2011 01:01:23 -0700
> From: Owen DeLong <owen at delong.com>
> To: Benson Schliesser <bensons at queuefull.net>
> Cc: Paul Vixie <vixie at isc.org>, nanog at nanog.org
> Subject: Re: wet-behind-the-ears whippersnapper seeking advice on
> 	building a nationwide network
> Message-ID: <277A7743-14E7-4FC2-91D2-E0772F262DFF at delong.com>
> Content-Type: text/plain; charset=us-ascii
> 
> > 
> > The NomCom acts as a filter, of sorts.  It chooses the candidates that the membership will see.  The fact that the NomCom is so closely coupled with the existing leadership has an unfortunate appearance that suggests a bias.  I'm unable to say whether the bias exists, is recognized, and/or is reflected in the slate of candidates.  But it seems like an easy enough thing to avoid.
> > 
> 
> This statement ignores the existence of the petition process and the relatively low threshold required to get a candidate not approved or selected by the nomcom onto the ballot if there is even a very limited desire to do so.
> 
> > As for my use of "existing establishment":  I'm of the impression that a relatively small group of individuals drive ARIN, that most ARIN members don't actively participate.  I have my own opinions on why this is, but they aren't worth elaborating at this time - in fact, I suspect many ARIN members here on NANOG can speak for themselves if they wanted to.  In any case, this is just my impression.  If you would rather share some statistics on member participation, election fairness, etc, then such facts might be more useful.
> > 
> 
> My inclination is that the lack of participation generally indicates that the majority are not upset by the way ARIN is doing things. I know that the beginning of my participation in ARIN was the result of my deciding that some of the ways ARIN was doing things needed changing.
> 
> >> ARIN's bylaws firmly place control of ARIN into the hands of its members.
> >> if you think that's the wrong approach, i'm curious to hear your reasoning
> >> and your proposed alternative.
> > 
> > One of ARIN's governance strengths is the availability of petition at many steps, including for candidates rejected by the NomCom.  Likewise, as you noted, leaders are elected by the membership.  For these reasons I previously noted that "ARIN has a pretty good governance structure" and I continue to think so.  It could be improved by increased member involvement, as well as broader involvement from the community. (For instance, policy petitions should include responses from the entire affected community, not just PPML.)  But my criticisms should be interpreted as constructive, and are not an indictment of the whole approach.
> > 
> 
> OK, so you are aware of the petition process after all. That makes your statement at the top of this message somewhat perplexing.
> 
> I agree that increased member participation would be a good thing.
> 
> I do not believe that including petition responses from people who aren't willing to join PPML even if it's just long enough to support the petition in question would be useful. It takes almost no effort to join PPML, support a petition, and then leave PPML if you are that determined not to participate. Further, I think that it is reasonable to expect at least a modicum of participation in the policy process in order to participate in the petition process. Requiring supporters to be on PPML at the time they support the petition seems like a reasonable threshold to me. Finally, absent some mechanism such as requiring a PPML subscription, it might be somewhat difficult to avoid petition stuffing.
> 
> Owen
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 23 Sep 2011 09:51:46 +0000
> From: John Curran <jcurran at arin.net>
> To: Paul Vixie <vixie at isc.org>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: wet-behind-the-ears whippersnapper seeking advice on
> 	building a nationwide network
> Message-ID: <BCFADB61-9052-434E-BCA9-2EE7170EC339 at arin.net>
> Content-Type: text/plain; charset="us-ascii"
> 
> On Sep 23, 2011, at 12:57 AM, Paul Vixie wrote:
> 
> > On Thu, 22 Sep 2011 21:05:51 -0500
> > Benson Schliesser <bensons at queuefull.net> wrote:
> > 
> >> As for my use of "existing establishment":  I'm of the impression
> >> that a relatively small group of individuals drive ARIN, that most
> >> ARIN members don't actively participate.  I have my own opinions on
> >> why this is, but they aren't worth elaborating at this time - in
> >> fact, I suspect many ARIN members here on NANOG can speak for
> >> themselves if they wanted to.  In any case, this is just my
> >> impression.  If you would rather share some statistics on member
> >> participation, election fairness, etc, then such facts might be more
> >> useful.
> > 
> > i think our participation level in elections is quite high and i'll ask
> > for details and see them published here.
> 
> Paul - 
>  
>   Information regarding ARIN's last election is online here:
> 
>    <https://www.arin.net/announcements/2010/20101019_ElectionWinners.html>
> 
>   I've attached the relevant section regarding participation, and it should
>   be noted that more than 12% of the potential electorate voted in last year's 
>   election.  This is typical turnout for our elections, and while I have been
>   told anecdotally that this is relatively high turnout for membership 
>   organization, I do not have hard data points for comparison at this time.
> 
>   I would encourage all NANOG members to confirm their designated member
>   representatives with ARIN (i.e. the official organizational contacts) and 
>   vote (or if someone else in your organization encourage them to do so) in
>   the upcoming ARIN election for the ARIN Advisory Council and the ARIN Board 
>   of Trustee positions.
> 
> FYI,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> === From  <https://www.arin.net/announcements/2010/20101019_ElectionWinners.html>
> 
> 2010 VOTER STATISTICS 
> 
> 3,690 ARIN members as of 21 September 2010 
> 
> 2,834 Eligible voters* as of 21 September 2010 
> 
>    *ARIN members in good standing with properly registered Designated Member Representatives on record 1 January 2010 
> 
> 355 unique member organizations cast a ballot in the Board of Trustees election. 
> 
> 356 unique member organizations cast a ballot in the Advisory Council election. 
> 
> 364 unique member organizations cast a ballot in either the Board of Trustees or Advisory Council election
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 23 Sep 2011 10:35:02 +0000
> From: John Curran <jcurran at arin.net>
> To: Jim Duncan <jduncan at juniper.net>
> Cc: "vixie at isc.org" <vixie at isc.org>, "nanog at nanog.org"
> 	<nanog at nanog.org>
> Subject: Re: wet-behind-the-ears whippersnapper seeking advice on
> 	building a nationwide network
> Message-ID: <AFB08AFB-3443-4AB1-9739-2BA9E6992F45 at arin.net>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Sep 23, 2011, at 1:40 AM, Jim Duncan wrote:
> > With my parliamentarian hat on:
> > A nominating committee's essential function is to ensure that a minimum number of qualified, vetted individuals are placed on the slate of candidates for election. it should never be a gating function; it is an important safeguard to allow the nomination of qualified individuals outside the nominating committee and "from the floor" before votes are cast. 
> > ...
> 
> > Although organizations may decide for themselves how a nominating committee will operate, it is inconsistent with the general principles of parliamentary process -- whichever standard you choose, Robert's, Sturgis, or another -- for all candidates to be forced to pass through the gauntlet of the nominating committee. 
> 
> Jim - 
>   
>   I agree with you in principle regarding the NomCom's essential 
>   function, but note that your requirement that the Nominating 
>   Committee pass _all_ candidates minimally qualified is not the 
>   only valid approach.  In the case of ARIN, the NomCom process
>   provides a sufficient number of qualified qualified candidates
>   but is specifically not required to provide all such candidates
>   <https://www.arin.net/participate/elections/nomcom_faqs.html>
> 
>   The protection of the parliamentary representation principle that
>   you allude to (i.e. the freedom for members of an organization to 
>   choose its own leadership) to is instead provided via a petition 
>   process.  This mechanism provides a comparable safeguard by allowing
>   anyone to be added to the ballot if they desire such and can show 
>   some support in the community for their candidacy.
> 
>   Note that ARIN's initial Bylaws only provided for direct selection 
>   of new Board members by the ARIN Board from a list of candidates 
>   chosen by the ARIN AC.  In subsequent years, this was changed to be 
>   a separate NomCom, and a petition process requiring support of 15% 
>   of the electorate was added. The petition threshold was then lowered 
>   to 5% of the electorate, and then again recently lowered to be now
>   2% of the electorate. The ARIN Board has reviewed the election process 
>   in each of the recent years to see if any further changes are required.
> 
>   Further evolution of this process is quite possible, and discussion
>   here (or on an ARIN mailing list) will help inform the ARIN Board 
>   about the community views on this matter.
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Fri, 23 Sep 2011 06:56:05 -0400
> From: Randy McAnally <rsm at fast-serv.com>
> To: "rpug at linux.com" <rpug at linux.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: Verizon / FiOS network
> Message-ID: <CACA4923-5E3B-4A8A-A699-3F2634476E4D at fast-serv.com>
> Content-Type: text/plain;	charset=us-ascii
> 
> Not able to connect to 146.115.38.21 via fios or verizon 3g so the problem doesn't seem to be fios specific. 
> 
> Sent from my IPhone (pardon the typo's)
> 
> On Sep 22, 2011, at 9:32 PM, "Ryan Pugatch" <rpug at linux.com> wrote:
> 
> >> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
> >>> Hi,
> >>> 
> >>> Anyone noticing anything weird with the Verizon / FiOS network?
> >>> 
> >>> Seems like many people on their network are having trouble getting to us
> >>> (on Sidera / RCN) but not everyone.
> >>> 
> >> 
> >> it's, obviously, simpler to help diagnose this when you provide some
> >> semblance of destination address, port, protocol...
> >> 
> >> just sayin'!
> >> 
> >> -chris
> >> (fios user who could help, if only there was enough info to go on)
> >> 
> >> 
> > 
> > HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21
> > 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Fri, 23 Sep 2011 09:35:16 -0400
> From: Ryan Rawdon <ryan at u13.net>
> To: rpug at linux.com
> Cc: nanog at nanog.org
> Subject: Re: Verizon / FiOS network
> Message-ID: <A323BE5B-FD0C-4AC5-8198-8CE7E3DDD632 at u13.net>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> On Sep 22, 2011, at 9:32 PM, Ryan Pugatch wrote:
> 
> >> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
> >>> Hi,
> >>> 
> >>> Anyone noticing anything weird with the Verizon / FiOS network?
> >>> 
> >>> Seems like many people on their network are having trouble getting to us
> >>> (on Sidera / RCN) but not everyone.
> >>> 
> >> 
> >> it's, obviously, simpler to help diagnose this when you provide some
> >> semblance of destination address, port, protocol...
> >> 
> >> just sayin'!
> >> 
> >> -chris
> >> (fios user who could help, if only there was enough info to go on)
> >> 
> >> 
> > 
> > HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21
> > 
> > 
> 
> >From FiOS and non-FiOS locations I get the same result:
> 
> HTTP: timeout
> HTTPS: connects and loads (Zimbra webmail page)
> also can ping via ICMP just fine
> 
> 
> Traceroute from fios is via Level3 from the DC area to Boston where it is handed off to RCN and then 2 hops to the destination
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Fri, 23 Sep 2011 09:38:26 -0400
> From: chris <tknchris at gmail.com>
> To: Ryan Rawdon <ryan at u13.net>
> Cc: nanog at nanog.org
> Subject: Re: Verizon / FiOS network
> Message-ID:
> 	<CAKnNFz-m+mrdbZPA8bwhoCBD+Bp-Ko6TAhP-voS4cn9BmQV6TA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> HTTP doesnt appear to be open from any network I try Verizon or otherwise so
> I'm not sure its network related
> 
> On Fri, Sep 23, 2011 at 9:35 AM, Ryan Rawdon <ryan at u13.net> wrote:
> 
> >
> > On Sep 22, 2011, at 9:32 PM, Ryan Pugatch wrote:
> >
> > >> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
> > >>> Hi,
> > >>>
> > >>> Anyone noticing anything weird with the Verizon / FiOS network?
> > >>>
> > >>> Seems like many people on their network are having trouble getting to
> > us
> > >>> (on Sidera / RCN) but not everyone.
> > >>>
> > >>
> > >> it's, obviously, simpler to help diagnose this when you provide some
> > >> semblance of destination address, port, protocol...
> > >>
> > >> just sayin'!
> > >>
> > >> -chris
> > >> (fios user who could help, if only there was enough info to go on)
> > >>
> > >>
> > >
> > > HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21
> > >
> > >
> >
> > From FiOS and non-FiOS locations I get the same result:
> >
> > HTTP: timeout
> > HTTPS: connects and loads (Zimbra webmail page)
> > also can ping via ICMP just fine
> >
> >
> > Traceroute from fios is via Level3 from the DC area to Boston where it is
> > handed off to RCN and then 2 hops to the destination
> >
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Fri, 23 Sep 2011 10:17:38 -0400 (EDT)
> From: Jay Ashworth <jra at baylink.com>
> To: NANOG <nanog at nanog.org>
> Subject: Commercial DNS service opinions?
> Message-ID:
> 	<25076238.2837.1316787458644.JavaMail.root at benjamin.baylink.com>
> Content-Type: text/plain; charset=utf-8
> 
> Open, Super, Dyn?
> 
> Will any of them do hidden-master?
> 
> Off list; I'll summarize.
> 
> 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      http://photo.imageinc.us             +1 727 647 1274
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Fri, 23 Sep 2011 10:40:37 -0400
> From: Christopher Morrow <morrowc.lists at gmail.com>
> To: Jay Ashworth <jra at baylink.com>
> Cc: NANOG <nanog at nanog.org>
> Subject: Re: Commercial DNS service opinions?
> Message-ID:
> 	<CAL9jLaaPc=YVOtKkL8G1p_TqFWPj8VyzGz=rapfNSy0vYREujA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Fri, Sep 23, 2011 at 10:17 AM, Jay Ashworth <jra at baylink.com> wrote:
> > Open, Super, Dyn?
> >
> > Will any of them do hidden-master?
> >
> > Off list; I'll summarize.
> 
> recursive AND authoritative? or ?
> 
> 
> 
> End of NANOG Digest, Vol 44, Issue 103
> **************************************




From rpug at linux.com  Fri Sep 23 12:20:45 2011
From: rpug at linux.com (Ryan Pugatch)
Date: Fri, 23 Sep 2011 13:20:45 -0400
Subject: Verizon / FiOS network
In-Reply-To: <CAKnNFz-m+mrdbZPA8bwhoCBD+Bp-Ko6TAhP-voS4cn9BmQV6TA@mail.gmail.com>
References: <6b8e973364bb465f5fe35c583271d756.squirrel@wm.horrible.net>
 <CAL9jLaZexGQFPKQV+1tciHp8DAktxs0yrx+Wx7N=5W7jsrwJ5Q@mail.gmail.com>
 <cdae61c9e0158c7c03921c4a587bc221.squirrel@wm.horrible.net>
 <A323BE5B-FD0C-4AC5-8198-8CE7E3DDD632@u13.net>
 <CAKnNFz-m+mrdbZPA8bwhoCBD+Bp-Ko6TAhP-voS4cn9BmQV6TA@mail.gmail.com>
Message-ID: <d17231ff2ece780502a41f04424afd23.squirrel@wm.horrible.net>

My original email wasn't too clear.  This host specifically does not allow
80, but does allow 443.  What I was trying to explain is that we are
seeing the issue occur on several hosts on both 80 and 443.

Sorry for the confusion.

Ryan


> HTTP doesnt appear to be open from any network I try Verizon or otherwise
> so
> I'm not sure its network related
>
> On Fri, Sep 23, 2011 at 9:35 AM, Ryan Rawdon <ryan at u13.net> wrote:
>
>>
>> On Sep 22, 2011, at 9:32 PM, Ryan Pugatch wrote:
>>
>> >> On Thu, Sep 22, 2011 at 8:55 PM, Ryan Pugatch <rpug at linux.com> wrote:
>> >>> Hi,
>> >>>
>> >>> Anyone noticing anything weird with the Verizon / FiOS network?
>> >>>
>> >>> Seems like many people on their network are having trouble getting
>> to
>> us
>> >>> (on Sidera / RCN) but not everyone.
>> >>>
>> >>
>> >> it's, obviously, simpler to help diagnose this when you provide some
>> >> semblance of destination address, port, protocol...
>> >>
>> >> just sayin'!
>> >>
>> >> -chris
>> >> (fios user who could help, if only there was enough info to go on)
>> >>
>> >>
>> >
>> > HTTP/HTTPS over 80, 443.  Sample IP: 146.115.38.21
>> >
>> >
>>
>> From FiOS and non-FiOS locations I get the same result:
>>
>> HTTP: timeout
>> HTTPS: connects and loads (Zimbra webmail page)
>> also can ping via ICMP just fine
>>
>>
>> Traceroute from fios is via Level3 from the DC area to Boston where it
>> is
>> handed off to RCN and then 2 hops to the destination
>>
>




From Valdis.Kletnieks at vt.edu  Fri Sep 23 12:27:48 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 23 Sep 2011 13:27:48 -0400
Subject: Question on 95th percentile and Over-usage transit
In-Reply-To: Your message of "Fri, 23 Sep 2011 18:51:59 +0200."
 <1316796719.2532.58.camel@Pradeep>
References: <mailman.9019.1316788838.1873.nanog@nanog.org>
 <1316796719.2532.58.camel@Pradeep>
Message-ID: <6727.1316798868@turing-police.cc.vt.edu>

On Fri, 23 Sep 2011 18:51:59 +0200, Pradeep Bangera said:

> Malayter in his earlier message. Hence I am wondering, whether the
> pricing should be a linear(CDR*[95th peak]) or sub-linear (like the
> above)?

Yes. :)

I think you'll find actual contracts out in the wild that do it either way, and
probably lots of variants as well, because the organizations buying the transit
have differing motivations.  Some will want to minimize their monthly expenses
at all costs and hope they don't get a surprise billing spike due to high
traffic, while others may very well be willing to pay 10% more a month for a
"guaranteed no surprises" billing structure for budgeting reasons.

Now, if you have a good model for "how likely is each method to result in
surprises in the real world".... ;)

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

From egermann at limanews.com  Fri Sep 23 13:29:59 2011
From: egermann at limanews.com (Eric Germann)
Date: Fri, 23 Sep 2011 11:29:59 -0700
Subject: BGP visibility for /24 End User Allocation
Message-ID: <730AF3879A3A3844B3FB5A881A3DFBC8D0EEC08A68@VA3DIAXVS091.RED001.local>

Long time on-again-off-again lurker.

Looking to multihome in the most efficient mode.

Our two upstreams are AS11530 (Embarq) and AS10796 (Time Warner).  Diverse routed fiber from each at 10Mbps.

Our traffic profile is highly asymmetric as a consumer of bandwidth (12-15Mbps average inbound aggregate, 2-3Mbps aggregate very bursty outbound).

Years ago when I tinkered with BGP there were substantial issues with getting any prefix too small through filters to see the "greater Internet" (IIRC it was a /19 at that time).

Given we really could justify a /24 realistically, what is the current status of filtering in terms of having that /24 get to the "vast majority" of the Internet given the two providers in question?

Thanks for any advice in advance.

EKG


From sethm at rollernet.us  Fri Sep 23 13:34:13 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 23 Sep 2011 11:34:13 -0700
Subject: BGP visibility for /24 End User Allocation
In-Reply-To: <730AF3879A3A3844B3FB5A881A3DFBC8D0EEC08A68@VA3DIAXVS091.RED001.local>
References: <730AF3879A3A3844B3FB5A881A3DFBC8D0EEC08A68@VA3DIAXVS091.RED001.local>
Message-ID: <4E7CD125.2000709@rollernet.us>

On 9/23/11 11:29 AM, Eric Germann wrote:
> Long time on-again-off-again lurker.
> 
> Looking to multihome in the most efficient mode.
> 
> Our two upstreams are AS11530 (Embarq) and AS10796 (Time Warner).  Diverse routed fiber from each at 10Mbps.
> 
> Our traffic profile is highly asymmetric as a consumer of bandwidth (12-15Mbps average inbound aggregate, 2-3Mbps aggregate very bursty outbound).
> 
> Years ago when I tinkered with BGP there were substantial issues with getting any prefix too small through filters to see the "greater Internet" (IIRC it was a /19 at that time).
> 
> Given we really could justify a /24 realistically, what is the current status of filtering in terms of having that /24 get to the "vast majority" of the Internet given the two providers in question?
> 
> Thanks for any advice in advance.
> 

A /24 is has been the gold standard for a while, you shouldn't have any
problems.

~Seth


From rcarpen at network1.net  Fri Sep 23 13:56:05 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Fri, 23 Sep 2011 14:56:05 -0400 (EDT)
Subject: BGP visibility for /24 End User Allocation
In-Reply-To: <4E7CD125.2000709@rollernet.us>
Message-ID: <3464630f-840a-4b28-ae44-4954c1a21285@zimbra.network1.net>


We have routed a couple of /24s via BGP for a long time. 10+ years for one of them. We have never had any issues. If you get an End-User assignment from ARIN, it is probably even easier than getting providers to route a /24 out of another provider's space.


-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1
----

----- Original Message -----
> On 9/23/11 11:29 AM, Eric Germann wrote:
> > Long time on-again-off-again lurker.
> > 
> > Looking to multihome in the most efficient mode.
> > 
> > Our two upstreams are AS11530 (Embarq) and AS10796 (Time Warner).
> >  Diverse routed fiber from each at 10Mbps.
> > 
> > Our traffic profile is highly asymmetric as a consumer of bandwidth
> > (12-15Mbps average inbound aggregate, 2-3Mbps aggregate very
> > bursty outbound).
> > 
> > Years ago when I tinkered with BGP there were substantial issues
> > with getting any prefix too small through filters to see the
> > "greater Internet" (IIRC it was a /19 at that time).
> > 
> > Given we really could justify a /24 realistically, what is the
> > current status of filtering in terms of having that /24 get to the
> > "vast majority" of the Internet given the two providers in
> > question?
> > 
> > Thanks for any advice in advance.
> > 
> 
> A /24 is has been the gold standard for a while, you shouldn't have
> any
> problems.
> 
> ~Seth
> 
> 
> 


From cscora at apnic.net  Fri Sep 23 14:29:58 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 24 Sep 2011 05:29:58 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201109231929.p8NJTwQr016544@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,
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 24 Sep, 2011

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

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

BGP routing table entries examined:                              374059
    Prefixes after maximum aggregation:                          168238
    Deaggregation factor:                                          2.22
    Unique aggregates announced to Internet:                     184911
Total ASes present in the Internet Routing Table:                 38886
    Prefixes per ASN:                                              9.62
Origin-only ASes present in the Internet Routing Table:           32232
Origin ASes announcing only one prefix:                           15494
Transit ASes present in the Internet Routing Table:                5223
Transit-only ASes present in the Internet Routing Table:            138
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      35
    Max AS path prepend of ASN (23456)                               31
Prefixes from unregistered ASNs in the Routing Table:              1402
    Unregistered ASNs in the Routing Table:                         772
Number of 32-bit ASNs allocated by the RIRs:                       1762
Number of 32-bit ASNs visible in the Routing Table:                1431
Prefixes from 32-bit ASNs in the Routing Table:                    3276
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:             97
Number of addresses announced to Internet:                   2479145472
    Equivalent to 147 /8s, 196 /16s and 194 /24s
    Percentage of available address space announced:               66.9
    Percentage of allocated address space announced:               66.9
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               91.4
Total number of prefixes smaller than registry allocations:      156426

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

Prefixes being announced by APNIC Region ASes:                    93852
    Total APNIC prefixes after maximum aggregation:               30727
    APNIC Deaggregation factor:                                    3.05
Prefixes being announced from the APNIC address blocks:           90378
    Unique aggregates announced from the APNIC address blocks:    37990
APNIC Region origin ASes present in the Internet Routing Table:    4575
    APNIC Prefixes per ASN:                                       19.75
APNIC Region origin ASes announcing only one prefix:               1262
APNIC Region transit ASes present in the Internet Routing Table:    709
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         19
Number of APNIC region 32-bit ASNs visible in the Routing Table:     88
Number of APNIC addresses announced to Internet:              627667040
    Equivalent to 37 /8s, 105 /16s and 112 /24s
    Percentage of available APNIC address space announced:         79.6

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
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, 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:                    143860
    Total ARIN prefixes after maximum aggregation:                73754
    ARIN Deaggregation factor:                                     1.95
Prefixes being announced from the ARIN address blocks:           115959
    Unique aggregates announced from the ARIN address blocks:     48009
ARIN Region origin ASes present in the Internet Routing Table:    14685
    ARIN Prefixes per ASN:                                         7.90
ARIN Region origin ASes announcing only one prefix:                5659
ARIN Region transit ASes present in the Internet Routing Table:    1562
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          25
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               804997888
    Equivalent to 47 /8s, 251 /16s and 75 /24s
    Percentage of available ARIN address space announced:          64.0

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, 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, 173/8,
                       174/8, 184/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:                     89445
    Total RIPE prefixes after maximum aggregation:                50349
    RIPE Deaggregation factor:                                     1.78
Prefixes being announced from the RIPE address blocks:            82150
    Unique aggregates announced from the RIPE address blocks:     54043
RIPE Region origin ASes present in the Internet Routing Table:    15994
    RIPE Prefixes per ASN:                                         5.14
RIPE Region origin ASes announcing only one prefix:                7970
RIPE Region transit ASes present in the Internet Routing Table:    2509
Average RIPE Region AS path length visible:                         4.6
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1018
Number of RIPE addresses announced to Internet:               489770368
    Equivalent to 29 /8s, 49 /16s and 77 /24s
    Percentage of available RIPE address space announced:          78.9

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
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,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   34957
    Total LACNIC prefixes after maximum aggregation:               7779
    LACNIC Deaggregation factor:                                   4.49
Prefixes being announced from the LACNIC address blocks:          34257
    Unique aggregates announced from the LACNIC address blocks:   17926
LACNIC Region origin ASes present in the Internet Routing Table:   1527
    LACNIC Prefixes per ASN:                                      22.43
LACNIC Region origin ASes announcing only one prefix:               447
LACNIC Region transit ASes present in the Internet Routing Table:   273
Average LACNIC Region AS path length visible:                       4.5
    Max LACNIC Region AS path length visible:                        19
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   310
Number of LACNIC addresses announced to Internet:              89159552
    Equivalent to 5 /8s, 80 /16s and 119 /24s
    Percentage of available LACNIC address space announced:        59.0

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8500
    Total AfriNIC prefixes after maximum aggregation:              1993
    AfriNIC Deaggregation factor:                                  4.26
Prefixes being announced from the AfriNIC address blocks:          6578
    Unique aggregates announced from the AfriNIC address blocks:   1995
AfriNIC Region origin ASes present in the Internet Routing Table:   488
    AfriNIC Prefixes per ASN:                                     13.48
AfriNIC Region origin ASes announcing only one prefix:              156
AfriNIC Region transit ASes present in the Internet Routing Table:  102
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    3
Number of AfriNIC addresses announced to Internet:             26803968
    Equivalent to 1 /8s, 152 /16s and 255 /24s
    Percentage of available AfriNIC address space announced:       39.9

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2503      11048         956   Korea Telecom (KIX)
17974     2004        519          33   PT TELEKOMUNIKASI INDONESIA
 7545     1599        303          86   TPG Internet Pty Ltd
 4755     1555        639         169   TATA Communications formerly 
 7552     1397       1064           7   Vietel Corporation
24560     1182        337         194   Bharti Airtel Ltd., Telemedia
 9829     1158        989          28   BSNL National Internet Backbo
 9583     1085         80         502   Sify Limited
 4808     1074       2098         304   CNCGROUP IP network: China169
18101      950        117         142   Reliance Infocom Ltd Internet

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     3561       3817         226   bellsouth.net, inc. 
18566     1913        365         238   Covad Communications 
 1785     1826        680         123   PaeTec Communications, Inc.
 7029     1706       1008         194   Windstream Communications Inc
 4323     1623       1082         391   Time Warner Telecom
20115     1597       1543         633   Charter Communications 
22773     1458       2907          99   Cox Communications, Inc.
30036     1420        264         677   Mediacom Communications Corp 
19262     1396       4728         400   Verizon Global Networks 
 7018     1332       7050         869   AT&T WorldNet Services

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

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402      967        352          13   Corbina telecom
34984      566        108         181   BILISIM TELEKOM
20940      542        181         420   Akamai Technologies European 
 6830      533       1813         325   UPC Distribution Services
 3320      493       8167         381   Deutsche Telekom AG
 3292      477       2082         407   TDC Tele Danmark
12479      476        594           8   Uni2 Autonomous System
 8866      462        133          26   Bulgarian Telecommunication C
29049      424         31          55   AzerSat LLC.
 3301      405       1904         354   TeliaNet Sweden

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

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1679        309         156   TVCABLE BOGOTA 
 8151     1416       2795         354   UniNet S.A. de C.V. 
28573     1362       1013          70   NET Servicos de Comunicao S.A
 7303     1161        681         173   Telecom Argentina Stet-France
14420      734         58          88   CORPORACION NACIONAL DE TELEC
 6503      582        450          69   AVANTEL, S.A. 
22047      580        322          17   VTR PUNTO NET S.A. 
27947      566         55          79   Telconet S.A
 3816      535        232          98   Empresa Nacional de Telecomun
11172      516         85          91   Servicios Alestra S.A de C.V 

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

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863      812        147          43   LINKdotNET AS number
 8452      710        445          11   TEDATA
15475      451         74           8   Nile Online
36992      291        415          14   Etisalat MISR
 3741      274        938         229   The Internet Solution 
15706      244         32           6   Sudatel Internet Exchange Aut
 6713      242        519          14   Itissalat Al-MAGHRIB
33776      239         13           8   Starcomms Nigeria Limited
12258      198         28          58   Vodacom Internet Company 
29571      190         17          11   Ci Telecom Autonomous system 

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
 6389     3561       3817         226   bellsouth.net, inc. 
23456     3276        774        1775   32-bit ASN transition
 4766     2503      11048         956   Korea Telecom (KIX)
17974     2004        519          33   PT TELEKOMUNIKASI INDONESIA
18566     1913        365         238   Covad Communications 
 1785     1826        680         123   PaeTec Communications, Inc.
 7029     1706       1008         194   Windstream Communications Inc
10620     1679        309         156   TVCABLE BOGOTA 
 4323     1623       1082         391   Time Warner Telecom
 7545     1599        303          86   TPG Internet Pty Ltd

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

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

  ASN   No of nets  Net Savings Description
17974      2004        1971      PT TELEKOMUNIKASI INDONESIA
 1785      1826        1703      PaeTec Communications, Inc.
18566      1913        1675      Covad Communications 
 4766      2503        1547      Korea Telecom (KIX)
10620      1679        1523      TVCABLE BOGOTA 
 7545      1599        1513      TPG Internet Pty Ltd
 7029      1706        1512      Windstream Communications Inc
23456      3276        1501      32-bit ASN transition
 7552      1397        1390      Vietel Corporation
 4755      1555        1386      TATA Communications formerly 

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

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

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
26973   UNALLOCATED  12.39.152.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.154.0/23        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.155.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.159.0/24        7018       AT&T WorldNet Servic
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic

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

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

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
41.222.79.0/24       36938     >>UNKNOWN<<
41.223.92.0/22       36936     >>UNKNOWN<<
46.18.104.0/21       23456     32-bit ASN transition
62.61.220.0/24       24974     Tachyon Europe BV - Wireless 

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:19       /9:12      /10:27      /11:81      /12:234     
/13:464     /14:801     /15:1416    /16:11985   /17:5990    /18:10025   
/19:19811   /20:27043   /21:27104   /22:36625   /23:34934   /24:194103  
/25:1117    /26:1336    /27:752     /28:171     /29:4       /30:0       
/31:0       /32:5       

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

  ASN   No of nets  Total ann.   Description
 6389     2198          3561      bellsouth.net, inc. 
18566     1869          1913      Covad Communications 
10620     1574          1679      TVCABLE BOGOTA 
23456     1564          3276      32-bit ASN transition
 7029     1403          1706      Windstream Communications Inc
30036     1377          1420      Mediacom Communications Corp 
11492     1114          1152      Cable One 
 7011     1057          1182      Citizens Utilities 
 1785     1053          1826      PaeTec Communications, Inc.
22773      947          1458      Cox Communications, Inc.

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

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

   1:384       2:297       4:15        5:1         6:3         8:351    
  12:1956     13:1        14:543      15:13       16:3        17:7      
  20:10       23:35       24:1681     27:945      31:543      32:64     
  33:4        34:2        36:4        38:742      40:108      41:2586   
  42:48       44:3        46:992      47:3        49:257      50:421    
  52:13       54:2        55:4        56:2        57:35       58:875    
  59:492      60:340      61:1179     62:1093     63:1940     64:4048   
  65:2303     66:3968     67:1951     68:1116     69:3188     70:814    
  71:377      72:1856     74:2455     75:349      76:341      77:870    
  78:790      79:479      80:1126     81:838      82:505      83:517    
  84:622      85:1086     86:409      87:873      88:351      89:1581   
  90:267      91:4120     92:524      93:1289     94:1325     95:904    
  96:437      97:276      98:931      99:37      101:210     103:316    
 106:70      107:52      108:79      109:1026    110:669     111:784    
 112:324     113:446     114:566     115:688     116:864     117:711    
 118:891     119:1210    120:334     121:686     122:1609    123:1003   
 124:1359    125:1358    128:244     129:179     130:165     131:583    
 132:120     133:21      134:216     135:54      136:212     137:139    
 138:289     139:120     140:494     141:287     142:387     143:411    
 144:486     145:58      146:471     147:215     148:639     149:259    
 150:153     151:191     152:446     153:177     154:6       155:395    
 156:203     157:359     158:146     159:463     160:325     161:207    
 162:339     163:177     164:507     165:373     166:534     167:432    
 168:751     169:146     170:860     171:83      172:1       173:1653   
 174:643     175:400     176:212     177:275     178:998     180:1079   
 181:30      182:626     183:219     184:378     185:1       186:1458   
 187:669     188:944     189:868     190:5164    192:5906    193:5018   
 194:3529    195:3069    196:1250    197:175     198:3591    199:4124   
 200:5520    201:1636    202:8518    203:8483    204:4254    205:2341   
 206:2677    207:2827    208:4030    209:3455    210:2670    211:1464   
 212:2087    213:1776    214:781     215:76      216:4879    217:1609   
 218:559     219:339     220:1227    221:513     222:342     223:263    


End of report


From david at davidswafford.com  Fri Sep 23 15:15:47 2011
From: david at davidswafford.com (David Swafford)
Date: Fri, 23 Sep 2011 16:15:47 -0400
Subject: BGP visibility for /24 End User Allocation
In-Reply-To: <730AF3879A3A3844B3FB5A881A3DFBC8D0EEC08A68@VA3DIAXVS091.RED001.local>
References: <730AF3879A3A3844B3FB5A881A3DFBC8D0EEC08A68@VA3DIAXVS091.RED001.local>
Message-ID: <CAA8=vb6YOoUDazkJqYocyy_R=K605XifMcGfTN8npAB_NTU5DA@mail.gmail.com>

Shouldn't be an issue.  We're advertising 4 x \24s and using much more BW.

David.


On Fri, Sep 23, 2011 at 2:29 PM, Eric Germann <egermann at limanews.com> wrote:
> Long time on-again-off-again lurker.
>
> Looking to multihome in the most efficient mode.
>
> Our two upstreams are AS11530 (Embarq) and AS10796 (Time Warner). ?Diverse routed fiber from each at 10Mbps.
>
> Our traffic profile is highly asymmetric as a consumer of bandwidth (12-15Mbps average inbound aggregate, 2-3Mbps aggregate very bursty outbound).
>
> Years ago when I tinkered with BGP there were substantial issues with getting any prefix too small through filters to see the "greater Internet" (IIRC it was a /19 at that time).
>
> Given we really could justify a /24 realistically, what is the current status of filtering in terms of having that /24 get to the "vast majority" of the Internet given the two providers in question?
>
> Thanks for any advice in advance.
>
> EKG
>
>


From randy at psg.com  Fri Sep 23 16:14:28 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 23 Sep 2011 23:14:28 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <A4C6A166C36F5F40A5767E6F66358FC0BAD175C1EB@EMBX01-WF.jnpr.net>
References: <20110923045712.000017c2@unknown>
 <A4C6A166C36F5F40A5767E6F66358FC0BAD175C1EB@EMBX01-WF.jnpr.net>
Message-ID: <m239fnotaj.wl%randy@psg.com>

> A nominating committee's essential function is to ensure that a
> minimum number of qualified, vetted individuals are placed on the
> slate of candidates for election.

it should ensure that folk who are not *technically* qualified, e.g. not
members, not human people, ... are not on the slate.  period.

> it should never be a gating function

fact: it has been

randy


From cidr-report at potaroo.net  Fri Sep 23 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 23 Sep 2011 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201109232200.p8NM00XS081014@wattle.apnic.net>

BGP Update Report
Interval: 15-Sep-11 -to- 22-Sep-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS8866            73955  2.6%     153.8 -- BTC-AS Bulgarian Telecommunication Company Plc.
 2 - AS9829            57553  2.0%      49.7 -- BSNL-NIB National Internet Backbone
 3 - AS9246            32010  1.1%    2462.3 -- GTA-AP Teleguam Holdings, LLC
 4 - AS38040           30394  1.1%    2171.0 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 5 - AS17488           26505  0.9%      27.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet
 6 - AS6316            24478  0.9%     185.4 -- AS-PAETEC-NET - PaeTec Communications, Inc.
 7 - AS32528           24102  0.8%    3012.8 -- ABBOTT Abbot Labs
 8 - AS5800            22082  0.8%     116.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 9 - AS7552            19628  0.7%      13.9 -- VIETEL-AS-AP Vietel Corporation
10 - AS9498            18155  0.6%      21.4 -- BBIL-AP BHARTI Airtel Ltd.
11 - AS16916           16921  0.6%     940.1 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
12 - AS24560           16731  0.6%      14.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
13 - AS38543           15811  0.6%    3162.2 -- IBM-TH-AS-AP IBM THAILAND NETWORK
14 - AS17974           14641  0.5%       7.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
15 - AS8402            14638  0.5%      13.3 -- CORBINA-AS OJSC "Vimpelcom"
16 - AS14420           13575  0.5%      18.5 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
17 - AS8452            13428  0.5%      18.8 -- TE-AS TE-AS
18 - AS9475            12473  0.4%     831.5 -- WU-TH-AP Walailuk University
19 - AS25620           11759  0.4%      59.1 -- COTAS LTDA.
20 - AS45595           11724  0.4%      27.1 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS50975           11193  0.4%    5596.5 -- AVX_AS AVX Czech republic s.r.o
 2 - AS56375            4434  0.2%    4434.0 -- IKRF Imam Khomeini Relief Foundation IKRF
 3 - AS3976             3507  0.1%    3507.0 -- ERX-NURI-ASN I.Net Technologies Inc.
 4 - AS38543           15811  0.6%    3162.2 -- IBM-TH-AS-AP IBM THAILAND NETWORK
 5 - AS32528           24102  0.8%    3012.8 -- ABBOTT Abbot Labs
 6 - AS9246            32010  1.1%    2462.3 -- GTA-AP Teleguam Holdings, LLC
 7 - AS22793            2202  0.1%    2202.0 -- CASSOCORP - CASSO Corporation
 8 - AS38040           30394  1.1%    2171.0 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 9 - AS26493            1694  0.1%    1694.0 -- GHI - Group Health Incorporated
10 - AS9562             8340  0.3%    1191.4 -- MSU-TH-AP Mahasarakham University
11 - AS45009            1079  0.0%    1079.0 -- MRSNET-AS OJSC Multyservisnaya radioset
12 - AS17425            6321  0.2%    1053.5 -- EPA-AS-TH Provincial Electricity Authority of Thailand.
13 - AS16916           16921  0.6%     940.1 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
14 - AS9475            12473  0.4%     831.5 -- WU-TH-AP Walailuk University
15 - AS3454             8313  0.3%     831.3 -- Universidad Autonoma de Nuevo Leon
16 - AS5868              718  0.0%     718.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
17 - AS48333             687  0.0%     687.0 -- AATVC AATVC CJSC
18 - AS11028             567  0.0%     567.0 -- SETIATHOME - SETIATHOME
19 - AS38528             512  0.0%     512.0 -- LANIC-AS-AP Lao National Internet Committee
20 - AS19674            1485  0.1%     495.0 -- NAVPOINT - Navpoint Internet


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 206.80.93.0/24    16860  0.6%   AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
 2 - 202.92.235.0/24   13828  0.5%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 3 - 130.36.34.0/24    12024  0.4%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/24    12024  0.4%   AS32528 -- ABBOTT Abbot Labs
 5 - 66.248.96.0/21    10808  0.4%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 6 - 66.248.120.0/21   10732  0.4%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 7 - 200.23.202.0/24    8161  0.3%   AS3454  -- Universidad Autonoma de Nuevo Leon
 8 - 213.16.48.0/24     6644  0.2%   AS8866  -- BTC-AS Bulgarian Telecommunication Company Plc.
 9 - 145.36.122.0/24    6282  0.2%   AS7046  -- RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business
10 - 109.75.0.0/21      5910  0.2%   AS50975 -- AVX_AS AVX Czech republic s.r.o
11 - 61.90.164.0/24     5610  0.2%   AS38543 -- IBM-TH-AS-AP IBM THAILAND NETWORK
12 - 58.97.61.0/24      5608  0.2%   AS38543 -- IBM-TH-AS-AP IBM THAILAND NETWORK
13 - 109.75.8.0/23      5283  0.2%   AS50975 -- AVX_AS AVX Czech republic s.r.o
14 - 180.180.253.0/24   5142  0.2%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
15 - 180.180.248.0/24   5140  0.2%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
16 - 180.180.251.0/24   5137  0.2%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
17 - 180.180.250.0/24   5136  0.2%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
18 - 180.180.249.0/24   5013  0.2%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
19 - 180.180.255.0/24   4806  0.2%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
20 - 202.41.70.0/24     4646  0.2%   AS2697  -- ERX-ERNET-AS Education and Research Network

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 cidr-report at potaroo.net  Fri Sep 23 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 23 Sep 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201109232200.p8NM00me081009@wattle.apnic.net>

This report has been generated at Fri Sep 23 21:12:15 2011 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
        16-09-11    374860      220342
        17-09-11    375515      220511
        18-09-11    375310      220632
        19-09-11    375594      220892
        20-09-11    375707      221389
        21-09-11    376330      220810
        22-09-11    376744      221221
        23-09-11    377111      221339


AS Summary
         38986  Number of ASes in routing system
         16483  Number of ASes announcing only one prefix
          3560  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      108362720  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').

 --- 23Sep11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     377486   221314   156172    41.4%   All ASes

AS6389      3560      229     3331    93.6%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS18566     1913      379     1534    80.2%   COVAD - Covad Communications
                                               Co.
AS4766      2503      973     1530    61.1%   KIXS-AS-KR Korea Telecom
AS22773     1458      109     1349    92.5%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1552      225     1327    85.5%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS4323      1625      394     1231    75.8%   TWTC - tw telecom holdings,
                                               inc.
AS1785      1829      781     1048    57.3%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS28573     1368      344     1024    74.9%   NET Servicos de Comunicao S.A.
AS19262     1395      400      995    71.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS7552      1398      406      992    71.0%   VIETEL-AS-AP Vietel
                                               Corporation
AS7303      1162      311      851    73.2%   Telecom Argentina S.A.
AS10620     1678      839      839    50.0%   Telmex Colombia S.A.
AS18101      939      146      793    84.5%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS24560     1182      405      777    65.7%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS8151      1420      647      773    54.4%   Uninet S.A. de C.V.
AS30036     1420      682      738    52.0%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS4808      1072      335      737    68.8%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS7545      1599      875      724    45.3%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1106      451      655    59.2%   LEVEL3 Level 3 Communications
AS14420      734       92      642    87.5%   CORPORACION NACIONAL DE
                                               TELECOMUNICACIONES - CNT EP
AS17676      679       70      609    89.7%   GIGAINFRA Softbank BB Corp.
AS20115     1597      989      608    38.1%   CHARTER-NET-HKY-NC - Charter
                                               Communications
AS22561      972      364      608    62.6%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS3549      1060      453      607    57.3%   GBLX Global Crossing Ltd.
AS17974     2003     1411      592    29.6%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4804       660       87      573    86.8%   MPX-AS Microplex PTY LTD
AS22047      580       28      552    95.2%   VTR BANDA ANCHA S.A.
AS7011      1181      656      525    44.5%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.
AS4780       761      242      519    68.2%   SEEDNET Digital United Inc.
AS8402       966      447      519    53.7%   CORBINA-AS OJSC "Vimpelcom"

Total      41372    13770    27602    66.7%   Top 30 total


Possible Bogus Routes

        5.0.0.0/16           AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        5.1.0.0/21           AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        5.1.24.0/24          AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        46.18.104.0/21       AS19735 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        80.88.10.0/24        AS33774 DJAWEB
        91.231.144.0/24      AS34119 WILDCARD-AS Wildcard UK Ltd
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        185.0.0.0/16         AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        185.1.0.0/21         AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        185.24.0.0/24        AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        190.102.32.0/20      AS30058 FDCSERVERS - FDCservers.net
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.111.87.0/24      AS24812 
        195.54.52.0/23       AS19713 ASBAGNJUK PC Bagnjuk Maksim Valerjevich
        195.54.52.0/24       AS19713 ASBAGNJUK PC Bagnjuk Maksim Valerjevich
        195.54.53.0/24       AS19713 ASBAGNJUK PC Bagnjuk Maksim Valerjevich
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS19429 ETB - Colombia
        200.24.76.0/24       AS7195  Telecorp Colombia S.A.
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.9.57.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        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.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.72.192.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.72.194.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        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.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.58.200.0/24      AS18530 ISOMEDIA-1 - Isomedia Inc.
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


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 glen.kent at gmail.com  Fri Sep 23 20:12:19 2011
From: glen.kent at gmail.com (Glen Kent)
Date: Sat, 24 Sep 2011 06:42:19 +0530
Subject: Strange static route
Message-ID: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>

Hi,

I have seen a few operators adding static routes like:
0.0.0.0/1 some next-hop and
128.0.0.0/1 some next-hop.

Why would anyone want to add such static routes? What does 0.0.0.0/1
mean. Note that the netmask is 1 and not 0.

Thanks,
Glen


From jmaslak at antelope.net  Fri Sep 23 20:18:42 2011
From: jmaslak at antelope.net (Joel Maslak)
Date: Fri, 23 Sep 2011 19:18:42 -0600
Subject: Strange static route
In-Reply-To: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
References: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
Message-ID: <85B958C1-E6DA-4FFC-B6E6-3962BFD3E424@antelope.net>

Protection against learning a bad default route through whatever routing protocol they are learning, since these two routes would be more specific than any typical default route.  They probably got burned learning a default route.

On Sep 23, 2011, at 7:12 PM, Glen Kent <glen.kent at gmail.com> wrote:

> Hi,
> 
> I have seen a few operators adding static routes like:
> 0.0.0.0/1 some next-hop and
> 128.0.0.0/1 some next-hop.
> 
> Why would anyone want to add such static routes? What does 0.0.0.0/1
> mean. Note that the netmask is 1 and not 0.
> 
> Thanks,
> Glen
> 


From deleskie at gmail.com  Fri Sep 23 20:57:09 2011
From: deleskie at gmail.com (jim deleskie)
Date: Fri, 23 Sep 2011 22:57:09 -0300
Subject: Strange static route
In-Reply-To: <85B958C1-E6DA-4FFC-B6E6-3962BFD3E424@antelope.net>
References: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
 <85B958C1-E6DA-4FFC-B6E6-3962BFD3E424@antelope.net>
Message-ID: <CAJL_ZMNm6u=JQA9prKiyyAkzPwPJf22zxZjRXKS8HPh+2+JRkA@mail.gmail.com>

Wouldn't it make more sense to filter in bound default?  or use a single
static default if you where worried about that?

-jim

On Fri, Sep 23, 2011 at 10:18 PM, Joel Maslak <jmaslak at antelope.net> wrote:

> Protection against learning a bad default route through whatever routing
> protocol they are learning, since these two routes would be more specific
> than any typical default route.  They probably got burned learning a default
> route.
>
> On Sep 23, 2011, at 7:12 PM, Glen Kent <glen.kent at gmail.com> wrote:
>
> > Hi,
> >
> > I have seen a few operators adding static routes like:
> > 0.0.0.0/1 some next-hop and
> > 128.0.0.0/1 some next-hop.
> >
> > Why would anyone want to add such static routes? What does 0.0.0.0/1
> > mean. Note that the netmask is 1 and not 0.
> >
> > Thanks,
> > Glen
> >
>
>

From jlewis at lewis.org  Fri Sep 23 21:15:26 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Fri, 23 Sep 2011 22:15:26 -0400 (EDT)
Subject: Strange static route
In-Reply-To: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
References: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.1109232214410.25015@soloth.lewis.org>

On Sat, 24 Sep 2011, Glen Kent wrote:

> Hi,
>
> I have seen a few operators adding static routes like:
> 0.0.0.0/1 some next-hop and
> 128.0.0.0/1 some next-hop.

It means half the IPv4 internet goes one way.  Half goes the other way.

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


From sfouant at shortestpathfirst.net  Fri Sep 23 21:41:01 2011
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Fri, 23 Sep 2011 22:41:01 -0400
Subject: Strange static route
In-Reply-To: <Pine.LNX.4.61.1109232214410.25015@soloth.lewis.org>
References: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
 <Pine.LNX.4.61.1109232214410.25015@soloth.lewis.org>
Message-ID: <3E196DE6-134B-4C13-9A1B-18A9BE9107A0@shortestpathfirst.net>

Well considering that native multicast isn't enabled end to end Internet wide, and class E address space isn't used, it's more like half your IPv4 Internet goes one way, and ~38% goes the other way... :-b

Stefan Fouant
JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks

Follow us on Twitter @JuniperEducate

Sent from my iPad

On Sep 23, 2011, at 10:15 PM, Jon Lewis <jlewis at lewis.org> wrote:

> On Sat, 24 Sep 2011, Glen Kent wrote:
> 
>> Hi,
>> 
>> I have seen a few operators adding static routes like:
>> 0.0.0.0/1 some next-hop and
>> 128.0.0.0/1 some next-hop.
> 
> It means half the IPv4 internet goes one way.  Half goes the other way.
> 
> ----------------------------------------------------------------------
> Jon Lewis, MCP :)           |  I route
> Senior Network Engineer     |  therefore you are
> Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> 


From morrowc.lists at gmail.com  Fri Sep 23 21:55:37 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 23 Sep 2011 22:55:37 -0400
Subject: Strange static route
In-Reply-To: <CAJL_ZMNm6u=JQA9prKiyyAkzPwPJf22zxZjRXKS8HPh+2+JRkA@mail.gmail.com>
References: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
 <85B958C1-E6DA-4FFC-B6E6-3962BFD3E424@antelope.net>
 <CAJL_ZMNm6u=JQA9prKiyyAkzPwPJf22zxZjRXKS8HPh+2+JRkA@mail.gmail.com>
Message-ID: <CAL9jLabUHuJgWdhKOkaHWwTYTRr_y9wP6DvfDT-bTWZL-XZwrg@mail.gmail.com>

On Fri, Sep 23, 2011 at 9:57 PM, jim deleskie <deleskie at gmail.com> wrote:
> Wouldn't it make more sense to filter in bound default? ?or use a single
> static default if you where worried about that?

there's lots of smarter things you COULD do :) this, it seems to me,
is a great thing for the operations bcp folks to work out though :)


From mysidia at gmail.com  Sat Sep 24 18:02:05 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 24 Sep 2011 18:02:05 -0500
Subject: Strange static route
In-Reply-To: <CAJL_ZMNm6u=JQA9prKiyyAkzPwPJf22zxZjRXKS8HPh+2+JRkA@mail.gmail.com>
References: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
 <85B958C1-E6DA-4FFC-B6E6-3962BFD3E424@antelope.net>
 <CAJL_ZMNm6u=JQA9prKiyyAkzPwPJf22zxZjRXKS8HPh+2+JRkA@mail.gmail.com>
Message-ID: <CAAAwwbXi-KACz0aD2M6tAguV6yv7hKM47Cna5J-tDjs9VE420A@mail.gmail.com>

On Fri, Sep 23, 2011 at 8:57 PM, jim deleskie <deleskie at gmail.com> wrote:
> Wouldn't it make more sense to filter in bound default? ?or use a single
> static default if you where worried about that?

Yes,  the  aesthetics of using a  "/1 route" for that purpose are very poor.

Don't implement design objectives using subtle side-effects,   when a
proper tool
is available -- human errors later are likely.

Using a /1   static  to  achieve a  "longer prefix"  to override a
default falls in that
category, when    routers have  a  filtering mechanism capable of
explicitly expressing
the desired policy  :)

> -jim
--
-JH


From will at willscorner.net  Sat Sep 24 19:43:28 2011
From: will at willscorner.net (Will Dean)
Date: Sat, 24 Sep 2011 20:43:28 -0400
Subject: Earthlink Contact - DNS cache poisoning
Message-ID: <4AA82A6A-0588-49ED-B5BF-D39B94B50DA4@willscorner.net>

Anyone out there in Earthlink land? I am seeing what looks to be a cache poisoning attack on ns1.mindspring.com.

Sporadic of course so it takes a few queries to replicate. 

will$ dig www.google.com @207.69.188.185

; <<>> DiG 9.7.3 <<>> www.google.com @207.69.188.185
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26196
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         60      IN      A       64.27.117.179
www.google.com.         60      IN      A       69.25.212.24

;; AUTHORITY SECTION:
www.google.com.         65535   IN      NS      WSC2.JOMAX.NET.
www.google.com.         65535   IN      NS      WSC1.JOMAX.NET.

;; Query time: 88 msec
;; SERVER: 207.69.188.185#53(207.69.188.185)
;; WHEN: Sat Sep 24 20:25:40 2011
;; MSG SIZE  rcvd: 120


- Will

From mysidia at gmail.com  Sat Sep 24 19:51:11 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 24 Sep 2011 19:51:11 -0500
Subject: Earthlink Contact - DNS cache poisoning
In-Reply-To: <4AA82A6A-0588-49ED-B5BF-D39B94B50DA4@willscorner.net>
References: <4AA82A6A-0588-49ED-B5BF-D39B94B50DA4@willscorner.net>
Message-ID: <CAAAwwbVY6W5tyE7dQbP1cUX_ExbFrAQW7KzGLOceS5G-dFRCog@mail.gmail.com>

On Sat, Sep 24, 2011 at 7:43 PM, Will Dean <will at willscorner.net> wrote:

The  "JOMAX.NET"  response is  indicative that there's a  Paxfire box
in the mix,
intercepting the DNS query  (probably installed by the ISP).


> Anyone out there in Earthlink land? I am seeing what looks to be a cache poisoning attack on ns1.mindspring.com.

> ;; AUTHORITY SECTION:
> www.google.com. ? ? ? ? 65535 ? IN ? ? ?NS ? ? ?WSC2.JOMAX.NET.
> www.google.com. ? ? ? ? 65535 ? IN ? ? ?NS ? ? ?WSC1.JOMAX.NET.


--
-JH


From morrowc.lists at gmail.com  Sat Sep 24 20:07:16 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 24 Sep 2011 21:07:16 -0400
Subject: Earthlink Contact - DNS cache poisoning
In-Reply-To: <CAAAwwbVY6W5tyE7dQbP1cUX_ExbFrAQW7KzGLOceS5G-dFRCog@mail.gmail.com>
References: <4AA82A6A-0588-49ED-B5BF-D39B94B50DA4@willscorner.net>
 <CAAAwwbVY6W5tyE7dQbP1cUX_ExbFrAQW7KzGLOceS5G-dFRCog@mail.gmail.com>
Message-ID: <CAL9jLaa+1yFZ-+Shk32aRP-Fs1YN_KJ38Bgt-91nNhDUXF3UMw@mail.gmail.com>

On Sat, Sep 24, 2011 at 8:51 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Sat, Sep 24, 2011 at 7:43 PM, Will Dean <will at willscorner.net> wrote:
>
> The ?"JOMAX.NET" ?response is ?indicative that there's a ?Paxfire box
> in the mix,
> intercepting the DNS query ?(probably installed by the ISP).
>

I think actually.. earthlink uses barefruit? (or they did when ...
kaminsky was off doing his destruction of the dns liars gangs...)
Maybe the same backend is used though for the advertizer side?
(barefruit provides the appliance, some third-party is the
advertiser/website-host... same for paxfire?)

>
>> Anyone out there in Earthlink land? I am seeing what looks to be a cache poisoning attack on ns1.mindspring.com.
>
>> ;; AUTHORITY SECTION:
>> www.google.com. ? ? ? ? 65535 ? IN ? ? ?NS ? ? ?WSC2.JOMAX.NET.
>> www.google.com. ? ? ? ? 65535 ? IN ? ? ?NS ? ? ?WSC1.JOMAX.NET.
>
>
> --
> -JH
>
>


From will at willscorner.net  Sat Sep 24 20:21:49 2011
From: will at willscorner.net (Will Dean)
Date: Sat, 24 Sep 2011 21:21:49 -0400
Subject: Earthlink Contact - DNS cache poisoning
In-Reply-To: <CAL9jLaa+1yFZ-+Shk32aRP-Fs1YN_KJ38Bgt-91nNhDUXF3UMw@mail.gmail.com>
References: <4AA82A6A-0588-49ED-B5BF-D39B94B50DA4@willscorner.net>
 <CAAAwwbVY6W5tyE7dQbP1cUX_ExbFrAQW7KzGLOceS5G-dFRCog@mail.gmail.com>
 <CAL9jLaa+1yFZ-+Shk32aRP-Fs1YN_KJ38Bgt-91nNhDUXF3UMw@mail.gmail.com>
Message-ID: <945F85AC-905A-4EC0-946E-D187AFC94837@willscorner.net>


On Sep 24, 2011, at 9:07 PM, Christopher Morrow wrote:

> On Sat, Sep 24, 2011 at 8:51 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> I think actually.. earthlink uses barefruit? (or they did when ...
> kaminsky was off doing his destruction of the dns liars gangs...)
> Maybe the same backend is used though for the advertizer side?
> (barefruit provides the appliance, some third-party is the
> advertiser/website-host... same for paxfire?)
> 

Barefruit was just for returning a search engine result for a NXDOMAIN response.

It appears Earthlink is now using Paxfire to sniff and proxy a users traffic to at least one popular website. Besides the obvious privacy implications, it introduces a nice captcha on Google.

- Will

From cb.list6 at gmail.com  Sat Sep 24 20:33:04 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sat, 24 Sep 2011 18:33:04 -0700
Subject: Nxdomain redirect revenue
Message-ID: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>

Just an fyi for anyone who has a marketing person dreaming up a big nxdomain
redirect business cases, the stats are actually very very poor... it does
not make much money at all.

It is very important to ask the redirect partners about yields... meaning,
you may find that less than 5% of nxdomain redirects can be actually served
an ad page because 95%+ of nxd are printer lookups and such that cannot be
served an ad page.  Then from that less than 5% pool, the click through
rates are around 1%

Net net, no free money of any meaningful value.  But, ymmv... but I don't
think by much.

Cb

From morrowc.lists at gmail.com  Sat Sep 24 20:35:48 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 24 Sep 2011 21:35:48 -0400
Subject: Earthlink Contact - DNS cache poisoning
In-Reply-To: <945F85AC-905A-4EC0-946E-D187AFC94837@willscorner.net>
References: <4AA82A6A-0588-49ED-B5BF-D39B94B50DA4@willscorner.net>
 <CAAAwwbVY6W5tyE7dQbP1cUX_ExbFrAQW7KzGLOceS5G-dFRCog@mail.gmail.com>
 <CAL9jLaa+1yFZ-+Shk32aRP-Fs1YN_KJ38Bgt-91nNhDUXF3UMw@mail.gmail.com>
 <945F85AC-905A-4EC0-946E-D187AFC94837@willscorner.net>
Message-ID: <CAL9jLabOuEHhQyRudGrqGprvrWb7axboSupYG=bf9a6dyga-_A@mail.gmail.com>

On Sat, Sep 24, 2011 at 9:21 PM, Will Dean <will at willscorner.net> wrote:
>
> On Sep 24, 2011, at 9:07 PM, Christopher Morrow wrote:
>
>> On Sat, Sep 24, 2011 at 8:51 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>> I think actually.. earthlink uses barefruit? (or they did when ...
>> kaminsky was off doing his destruction of the dns liars gangs...)
>> Maybe the same backend is used though for the advertizer side?
>> (barefruit provides the appliance, some third-party is the
>> advertiser/website-host... same for paxfire?)
>>
>
> Barefruit was just for returning a search engine result for a NXDOMAIN response.

ah, paxfire does the same...

>
> It appears Earthlink is now using Paxfire to sniff and proxy a users traffic to at least one popular website. Besides the obvious privacy implications, it introduces a nice captcha on Google.

hrm, they could simply use the appliances to answer: "www.google.com
-> jomax.net-ns-answer" which is a frontend simply 30[24]'ing off to
the jomax-esque site... Oh, you get the captcha though via earthlink?
that sucks :(

-chris


From morrowc.lists at gmail.com  Sat Sep 24 20:36:43 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 24 Sep 2011 21:36:43 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
Message-ID: <CAL9jLaay+UXKaiSUKnHEWViz5oFfUXeX7e-LrHAnVnVTd3PVeQ@mail.gmail.com>

On Sat, Sep 24, 2011 at 9:33 PM, Cameron Byrne <cb.list6 at gmail.com> wrote:
> Just an fyi for anyone who has a marketing person dreaming up a big nxdomain
> redirect business cases, the stats are actually very very poor... it does
> not make much money at all.
>
> It is very important to ask the redirect partners about yields... meaning,
> you may find that less than 5% of nxdomain redirects can be actually served
> an ad page because 95%+ of nxd are printer lookups and such that cannot be
> served an ad page. ?Then from that less than 5% pool, the click through
> rates are around 1%
>
> Net net, no free money of any meaningful value. ?But, ymmv... but I don't
> think by much.
>

that's some interesting data points, thanks!

> Cb
>


From mysidia at gmail.com  Sat Sep 24 22:09:22 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 24 Sep 2011 22:09:22 -0500
Subject: Nxdomain redirect revenue
In-Reply-To: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
Message-ID: <CAAAwwbXkNS4PosmTYQ-=CCaMpZgzd3JKZhxBJMVcSfrdMuvV7Q@mail.gmail.com>

On Sat, Sep 24, 2011 at 8:33 PM, Cameron Byrne <cb.list6 at gmail.com> wrote:
> Just an fyi for anyone who has a marketing person dreaming up a big nxdomain
> redirect business cases, the stats are actually very very poor... it does
> not make much money at all.
> It is very important to ask the redirect partners about yields... meaning,
> you may find that less than 5% of nxdomain redirects can be actually served

Not to take any position on there being a "business case"  for
NXDOMAIN redirect,
or not but....    the percentage of NXdomain redirects that actually
serve ads  isn't too important.
It's absolute numbers that matter,  even if it's  just 1% of
NXDOMAINS by percent.

The rest of the 99% are referred to as "noise"  and aren't relevant
for justifying or failing
to justify.

The important number is   at what frequency the _average_  user will
encounter the redirect
while they are surfing.    If a sufficient proportion of their users
see the ads at a sufficient rate,
then they will probably justify whatever cost they have for the ad serving.

When they are doing this crappy stuff like  redirecting google.com DNS
 to intercept
search requests;  I have little doubt that they are able to inject
sufficient volume of ads to
make some sort of  "business case"  behind the    hijacking evilness.


Regards,

--
-JH


From rekoil at semihuman.com  Sat Sep 24 23:27:35 2011
From: rekoil at semihuman.com (Chris Woodfield)
Date: Sat, 24 Sep 2011 21:27:35 -0700
Subject: AT&T Wireless outage in SoCal
Message-ID: <9C61C481-7673-4F91-B731-8E9FAEFCDF95@semihuman.com>

Hearing rumblings of a major AT&T Wireless outage in southern California. Anyone have more detail? Limited to cell towers or are transit circuits affected?

-Chris

From choprboy at dakotacom.net  Sun Sep 25 00:24:07 2011
From: choprboy at dakotacom.net (Adrian)
Date: Sat, 24 Sep 2011 22:24:07 -0700
Subject: AT&T Wireless outage in SoCal
In-Reply-To: <9C61C481-7673-4F91-B731-8E9FAEFCDF95@semihuman.com>
References: <9C61C481-7673-4F91-B731-8E9FAEFCDF95@semihuman.com>
Message-ID: <201109242224.08092.choprboy@dakotacom.net>

On Saturday 24 September 2011 21:27, Chris Woodfield wrote:
> Hearing rumblings of a major AT&T Wireless outage in southern California.
> Anyone have more detail? Limited to cell towers or are transit circuits
> affected?
>

Apparently their switching and core infrastructure (affecting both voice and 
data) across the LA basin. Been ongoing since about 5pm PDT. One of the 
latest words from their corporate people:

  "Company officials told KCBS and KCAL-TV that about 1,000 cell phone towers 
were out of service and the problems were not expected to be fixed until 2:30 
a.m. Sunday."


Adrian



From choprboy at dakotacom.net  Sun Sep 25 00:28:34 2011
From: choprboy at dakotacom.net (Adrian)
Date: Sat, 24 Sep 2011 22:28:34 -0700
Subject: AT&T Wireless outage in SoCal
In-Reply-To: <201109242224.08092.choprboy@dakotacom.net>
References: <9C61C481-7673-4F91-B731-8E9FAEFCDF95@semihuman.com>
 <201109242224.08092.choprboy@dakotacom.net>
Message-ID: <201109242228.34603.choprboy@dakotacom.net>

On Saturday 24 September 2011 22:24, Adrian wrote:
> On Saturday 24 September 2011 21:27, Chris Woodfield wrote:
> > Hearing rumblings of a major AT&T Wireless outage in southern California.
> > Anyone have more detail? Limited to cell towers or are transit circuits
> > affected?
>
> Apparently their switching and core infrastructure (affecting both voice
> and data) across the LA basin.

***I should clarify, apparently it is only affecting the ATT cell service. 
Transit/landline service is apparently unaffected.


Adrian



From tom at snnap.net  Sun Sep 25 04:37:18 2011
From: tom at snnap.net (Tom Storey)
Date: Sun, 25 Sep 2011 10:37:18 +0100
Subject: Strange static route
In-Reply-To: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
References: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
Message-ID: <CAFDgZgXHMBwA3rfkEauvRs60QaNPWqyr5m46yBkZB7nJ6VS7yQ@mail.gmail.com>

I found I had to do this many years ago on some Cisco routers to get them to
load balance (per packet) across two links. Adding 0.0.0.0/0 routes across
both links just resulted in traffic routing across one link. Broke it into
two /1's per link and it worked perfectly.


On 24 September 2011 02:12, Glen Kent <glen.kent at gmail.com> wrote:

> Hi,
>
> I have seen a few operators adding static routes like:
> 0.0.0.0/1 some next-hop and
> 128.0.0.0/1 some next-hop.
>
> Why would anyone want to add such static routes? What does 0.0.0.0/1
> mean. Note that the netmask is 1 and not 0.
>
> Thanks,
> Glen
>
>

From a.harrowell at gmail.com  Sun Sep 25 06:39:53 2011
From: a.harrowell at gmail.com (Alexander Harrowell)
Date: Sun, 25 Sep 2011 12:39:53 +0100
Subject: Nxdomain redirect revenue
In-Reply-To: <CAAAwwbXkNS4PosmTYQ-=CCaMpZgzd3JKZhxBJMVcSfrdMuvV7Q@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <CAAAwwbXkNS4PosmTYQ-=CCaMpZgzd3JKZhxBJMVcSfrdMuvV7Q@mail.gmail.com>
Message-ID: <201109251240.06149.a.harrowell@gmail.com>

On Sunday 25 Sep 2011 04:09:22 Jimmy Hess wrote:
> On Sat, Sep 24, 2011 at 8:33 PM, Cameron Byrne <cb.list6 at gmail.com> 
wrote:
> > Just an fyi for anyone who has a marketing person dreaming up a big 
nxdomain
> > redirect business cases, the stats are actually very very poor... it 
does
> > not make much money at all.
> > It is very important to ask the redirect partners about yields... 
meaning,
> > you may find that less than 5% of nxdomain redirects can be actually 
served
> 
> Not to take any position on there being a "business case"  for
> NXDOMAIN redirect,
> or not but....    the percentage of NXdomain redirects that actually
> serve ads  isn't too important.
> It's absolute numbers that matter,  even if it's  just 1% of
> NXDOMAINS by percent.
> 
> The rest of the 99% are referred to as "noise"  and aren't relevant
> for justifying or failing
> to justify.
> 
> The important number is   at what frequency the _average_  user will
> encounter the redirect
> while they are surfing.    If a sufficient proportion of their users
> see the ads at a sufficient rate,
> then they will probably justify whatever cost they have for the ad 
serving.
> 
> When they are doing this crappy stuff like  redirecting google.com DNS
>  to intercept
> search requests;  I have little doubt that they are able to inject
> sufficient volume of ads to
> make some sort of  "business case"  behind the    hijacking evilness.
> 
> 
> Regards,
> 
> --
> -JH

I think a special mention should go to hardware vendors who adopt this 
dreadful practice in network equipment. I recently encountered an 
enterprise-grade WLAN router from vendor D that has the horrible habit 
of intercepting some % of queries to its local DNS cache resolver and 
forwarding to an affiliate Yahoo! search page, lousy with ads, under 
vendor D's control.


This includes things like www.google.co.uk. I don't manage this device 
and therefore have opened a ticket with those who do to get them to turn 
the damn thing off, while in the meantime adding *.[vendor D]search.com 
127.0.0.1 to my /etc/hosts.


I must admit to being tempted to "fault" it with something heavy in 
order to force its replacement:-)


But if anyone from vendor-D is on the list: congratulations, you've 
managed to invent a network device that is by definition untrustworthy, 
and I will never buy anything from your company.



-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110925/0807b5ad/attachment.bin>

From jmaslak at antelope.net  Sun Sep 25 08:10:47 2011
From: jmaslak at antelope.net (Joel Maslak)
Date: Sun, 25 Sep 2011 07:10:47 -0600
Subject: Strange static route
In-Reply-To: <CAFDgZgXHMBwA3rfkEauvRs60QaNPWqyr5m46yBkZB7nJ6VS7yQ@mail.gmail.com>
References: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
 <CAFDgZgXHMBwA3rfkEauvRs60QaNPWqyr5m46yBkZB7nJ6VS7yQ@mail.gmail.com>
Message-ID: <633D426D-0889-4B49-96BB-37DFC25B438F@antelope.net>

On Sep 25, 2011, at 3:37 AM, Tom Storey <tom at snnap.net> wrote:

> I found I had to do this many years ago on some Cisco routers to get them to
> load balance (per packet) across two links. Adding 0.0.0.0/0 routes across
> both links just resulted in traffic routing across one link. Broke it into
> two /1's per link and it worked perfectly.


Two other reasons for this too:

1) Something won't redistribute 0.0.0.0/0 on the network.  Either because the person doesn't know the command to tell the router to do it, or because the router simply won't redistribute a default route.

2) Could also be failover.  One router might be advertising 0.0.0.0/0 on one end of the network. A different router on a different part of the network might be advertising the two /1's.  The /1's would be used unless they became unreachable.

From ge at linuxbox.org  Sun Sep 25 10:37:17 2011
From: ge at linuxbox.org (Gadi Evron)
Date: Sun, 25 Sep 2011 18:37:17 +0300
Subject: "general badness" AS-based reputation system
Message-ID: <4E7F4AAD.8020400@linuxbox.org>

Having run one of these in the past, when take-downs of C&Cs was still 
semi-useful, my ethos on this is problematic, however, I am as of yet 
undecided as to this one. An AS-based reputation system for all sorts of 
badness:

http://bgpranking.circl.lu/

In my opinion, third-party security based AS-reputation systems will 
eventually become de-facto border filtering systems for ISPs, but that 
day is still not here, as that is still socially unacceptable in our 
circles, and will remain so until it becomes _necessary_.

Regardless of my musings of Operators World cultural future, this 
systems seems rather interesting, and no doubt you'd want to take a look 
at your listing.

Gadi.


From jerome at ceriz.fr  Sun Sep 25 12:42:09 2011
From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=)
Date: Sun, 25 Sep 2011 19:42:09 +0200
Subject: Strange static route
In-Reply-To: <85B958C1-E6DA-4FFC-B6E6-3962BFD3E424@antelope.net>
References: <CAPLq3UPDGcq5gi_5XSz47riZf_jytypHfZL_CH7khyZuU6opzg@mail.gmail.com>
 <85B958C1-E6DA-4FFC-B6E6-3962BFD3E424@antelope.net>
Message-ID: <4E7F67F1.10709@ceriz.fr>

Joel, Glen,

Le 24/09/2011 03:18, Joel Maslak a ?crit :
> Protection against learning a bad default route through whatever 
> routing protocol they are learning, since these two routes would
> be more specific than any typical default route.  They probably
> got burned learning a default route.

Having a default route, or rather having a route to every possible
adresses, is required when you expunge your routing tables of some
prefixes yet you still wish to contact them relying on the next-hop's table.

Simple application is to filter incoming routes longer than /20 or /21
to free up some memory on your routers (reducing the global table from
377k to less than 100k routes is a nice perspective ;) )

But a default route is an obvious move and could easily be leeked by an
upstream, yet replacing yours if not properly filtered. So, using more
precise routes (/1s to /8s) helps avoiding these risks and yet lets you
roughly balance load to several gateways.

-- 
J?r?me Nicolle


From bill at opensourcerouting.org  Sun Sep 25 17:31:54 2011
From: bill at opensourcerouting.org (Bill Shetti)
Date: Sun, 25 Sep 2011 15:31:54 -0700
Subject: vyatta for bgp
Message-ID: <CAAo1Ghp47vJzNUNg4p1-cgpcpF7J9FKWtLzaB1qRnurYqVqzAA@mail.gmail.com>

On 9/22/11 11:38 , Charles N Wyble wrote:
>* On 09/22/2011 05:37 AM, Pierce Lynch wrote:*>>* Andreas Echavez [mailto:andreas at livejournalinc.com <https://mailman.nanog.org/mailman/listinfo/nanog>] originally wrote:*>>>* Ultimately, the network is as reliable as you build it. With*>>>* software, it's much cheaper to divide and scale horizontally.*>>>* Hardware devices are expensive and usually horizontal*>>>* scalability never happens. So in reality, an enterprise blows 100k on*>>>* two routers, they both flop because of some "firmware bug", and*>>>* you're down.*>>* With this in mind, I am keen to understand how many implementations of*>>* packages such as Quagga and Zebra that the group use. With the likes*>>* of Vyatta being discussed, I am keen to see if products such as Quagga*>>* as still regularly used as it used to be.*>**>* I think that the original/upstream versions are out of date as compared*>* to the one maintained by Vyatta. Or Google (for their MPLS processing*>* needs). See*>* http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nanog50*>* <http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nanog50>*
> We are actively supporting Quagga.  We currently have a git repo at
> code.google.com with some BGP multipath updates, and are working with
> ISC to provide SQA on that branch.  Hopefully more features will be
> forthcoming.  Search quagga-dev if you're interested in more details.
>
> Vyatta has done a lot of great work on Quagga, as have many others.  It
> would be nice to see all the various useful branches merged into a
> cherry-picked mainline that would simplify the Quagga development
> community's lives considerably.

> -Scott

we [opensourcerouting.org (ISC project)] are working on providing SQA
around Quagga. Our goal is to enable the community to build a more
stable, feature rich version of the quagga baseline.We're providing
testing, release management, and helping develop patches, features
etc.

We have started to test quagga's baseline code (99.18) covering

a) compliance (RFCs) and interop (with J and C)

b) scenario/functional/scale/performance testing

c) resilience and security testing

We already found several issues and have started to bug fix with the
community. See the quagga-dev list and bugzilla at quagga.net for
details. Examples - scale limits on BGP, incorrect route calculation,
etc (this is the main branch NOT variants)

In addition, we are also testing other branches and benchmarking them.
Vyatta's code and google's MP updates are some of many variants we are
working with (testing). Over the next few months of testing the
mainline, and variants, we will also work with the community (Vyatta,
google, independent committers, and others) to facilitate a merged
release. We will also test this against different configurations (OSs,
Servers, and switches ;p).

As part of the merge we will also help review and manage code with the
community, leveraging some of the experiences from ISC in bind.

If anyone has used Quagga in their network in any sort of
configuration, or even modified code to improve it, please contact us
(me or info at opensourcerouting.org).

As we are putting together the release and tests for
scenario/functional/scale/perf/etc -  input would be greatly
appreciated. We have a repository also which we can open up for new
code/patches etc, but it needs to also be given to the community.

As I have stated are working with Vyatta (and google, and others not
be mentioned), but more are always welcome.

We will be at Nanog in philly - come find me or one of my team members.

Thanks

Bill

From nick at foobar.org  Sun Sep 25 17:37:20 2011
From: nick at foobar.org (Nick Hilliard)
Date: Sun, 25 Sep 2011 23:37:20 +0100
Subject: Nxdomain redirect revenue
In-Reply-To: <201109251240.06149.a.harrowell@gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <CAAAwwbXkNS4PosmTYQ-=CCaMpZgzd3JKZhxBJMVcSfrdMuvV7Q@mail.gmail.com>
 <201109251240.06149.a.harrowell@gmail.com>
Message-ID: <4E7FAD20.8070006@foobar.org>

On 25/09/2011 12:39, Alexander Harrowell wrote:
> I think a special mention should go to hardware vendors who adopt this 
> dreadful practice in network equipment. I recently encountered an 
> enterprise-grade WLAN router from vendor D that has the horrible habit 

It is not libellous to associate a vendor's real name with calmly stated
matters of objective fact concerning their products.

I'd be interested to know the particular model that you're referring to
here - like you, to put it on a list of kit that I will never buy.

Re: "enterprise-grade" - did you mean this as a compliment or an insult?

Nick


From mysidia at gmail.com  Sun Sep 25 18:31:42 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 25 Sep 2011 18:31:42 -0500
Subject: "general badness" AS-based reputation system
In-Reply-To: <4E7F4AAD.8020400@linuxbox.org>
References: <4E7F4AAD.8020400@linuxbox.org>
Message-ID: <CAAAwwbW4SM0icz33UnASMPVqgY7sEvveG1RUELtdyf8gH5uvaQ@mail.gmail.com>

On Sun, Sep 25, 2011 at 10:37 AM, Gadi Evron <ge at linuxbox.org> wrote:
> In my opinion, third-party security based AS-reputation systems will
> eventually become de-facto border filtering systems for ISPs, but that day
> is still not here, as that is still socially unacceptable in our circles,
> and will remain so until it becomes _necessary_.

Sorry... what makes  you think the problem with use of a
AS-reputation systems is
social and not technical?

IP packets are not stamped with the numbers of any of the AS they
transitted to reach your network.
The IP protocol simply does not expose AS number information,
therefore,  for filtering purposes,
you don't actually have the information....

It's difficult to justify a complex  AS-reputation system that would
have limited
effectiveness, and really, is  little better than other reputation
system methods
(such as source address blacklisting)

--
-JH


From mysidia at gmail.com  Sun Sep 25 18:53:01 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 25 Sep 2011 18:53:01 -0500
Subject: Nxdomain redirect revenue
In-Reply-To: <4E7FAD20.8070006@foobar.org>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <CAAAwwbXkNS4PosmTYQ-=CCaMpZgzd3JKZhxBJMVcSfrdMuvV7Q@mail.gmail.com>
 <201109251240.06149.a.harrowell@gmail.com>
 <4E7FAD20.8070006@foobar.org>
Message-ID: <CAAAwwbUWCgwfVxTSo5E=21oKvWCW2kBo6PvohZ3gw=x3LN=bfA@mail.gmail.com>

On Sun, Sep 25, 2011 at 5:37 PM, Nick Hilliard <nick at foobar.org> wrote:
> On 25/09/2011 12:39, Alexander Harrowell wrote:
>> I think a special mention should go to hardware vendors who adopt this
>> dreadful practice in network equipment. I recently encountered an
>> enterprise-grade WLAN router from vendor D that has the horrible habit
>
> It is not libellous to associate a vendor's real name with calmly stated
> matters of objective fact concerning their products.
>

I would guess he is referring to this  "Advanced DNS Security"   misfeature :

http://www.dslreports.com/forum/r25921912-DLINK-Router-Advanced-DNS-Setup-Causing-Issues-


--
-JH


From mkarir at merit.edu  Sun Sep 25 20:23:00 2011
From: mkarir at merit.edu (Manish Karir)
Date: Sun, 25 Sep 2011 21:23:00 -0400
Subject: "general badness" AS-based reputation system
In-Reply-To: <mailman.9160.1316989916.1873.nanog@nanog.org>
References: <mailman.9160.1316989916.1873.nanog@nanog.org>
Message-ID: <0EA58FFF-2FBE-4977-BC62-211842FEB52E@merit.edu>



On Sep 25, 2011, at 6:31 PM, nanog-request at nanog.org wrote:

> Message: 9
> Date: Sun, 25 Sep 2011 18:37:17 +0300
> From: Gadi Evron <ge at linuxbox.org>
> To: nanog at nanog.org
> Subject: "general badness" AS-based reputation system
> Message-ID: <4E7F4AAD.8020400 at linuxbox.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Having run one of these in the past, when take-downs of C&Cs was still 
> semi-useful, my ethos on this is problematic, however, I am as of yet 
> undecided as to this one. An AS-based reputation system for all sorts of 
> badness:
> 
> http://bgpranking.circl.lu/
> 
> In my opinion, third-party security based AS-reputation systems will 
> eventually become de-facto border filtering systems for ISPs, but that 
> day is still not here, as that is still socially unacceptable in our 
> circles, and will remain so until it becomes _necessary_.
> 
> Regardless of my musings of Operators World cultural future, this 
> systems seems rather interesting, and no doubt you'd want to take a look 
> at your listing.
> 
> Gadi.

We tried to outline some of the challenges of building such a system in our NANOG52 presentation:

http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf

In particular see slide 4. where we tried to lay down what we think the requirements are for a socially acceptable
reputation system.  

With a bit of luck we might be able to announce the release of our system before the next NANOG mtg, but in 
my opinion collating host reputation reports is just a small and the easiest part of the effort.  The key is in 
solving the challenges of allowing (and incentivizing) participation and being robust to false information
injection.

Comments are welcome.

Thanks.
-manish




From tvest at eyeconomics.com  Sun Sep 25 22:31:47 2011
From: tvest at eyeconomics.com (Tom Vest)
Date: Sun, 25 Sep 2011 23:31:47 -0400
Subject: "general badness" AS-based reputation system
In-Reply-To: <0EA58FFF-2FBE-4977-BC62-211842FEB52E@merit.edu>
References: <mailman.9160.1316989916.1873.nanog@nanog.org>
 <0EA58FFF-2FBE-4977-BC62-211842FEB52E@merit.edu>
Message-ID: <A0C871B5-DAE5-433B-9331-6907F3D13053@eyeconomics.com>


On Sep 25, 2011, at 9:23 PM, Manish Karir wrote:

> On Sep 25, 2011, at 6:31 PM, nanog-request at nanog.org wrote:
> 
>> Message: 9
>> Date: Sun, 25 Sep 2011 18:37:17 +0300
>> From: Gadi Evron <ge at linuxbox.org>
>> To: nanog at nanog.org
>> Subject: "general badness" AS-based reputation system
>> Message-ID: <4E7F4AAD.8020400 at linuxbox.org>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> 
>> Having run one of these in the past, when take-downs of C&Cs was still 
>> semi-useful, my ethos on this is problematic, however, I am as of yet 
>> undecided as to this one. An AS-based reputation system for all sorts of 
>> badness:
>> 
>> http://bgpranking.circl.lu/
>> 
>> In my opinion, third-party security based AS-reputation systems will 
>> eventually become de-facto border filtering systems for ISPs, but that 
>> day is still not here, as that is still socially unacceptable in our 
>> circles, and will remain so until it becomes _necessary_.
>> 
>> Regardless of my musings of Operators World cultural future, this 
>> systems seems rather interesting, and no doubt you'd want to take a look 
>> at your listing.
>> 
>> Gadi.
> 
> We tried to outline some of the challenges of building such a system in our NANOG52 presentation:
> 
> http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf
> 
> In particular see slide 4. where we tried to lay down what we think the requirements are for a socially acceptable
> reputation system.  
> 
> With a bit of luck we might be able to announce the release of our system before the next NANOG mtg, but in 
> my opinion collating host reputation reports is just a small and the easiest part of the effort.  The key is in 
> solving the challenges of allowing (and incentivizing) participation and being robust to false information
> injection.
> 
> Comments are welcome.
> 
> Thanks.
> -manish

Hi Manish, 

Looks like very interesting work.

Does the system that you'll be announcing provide some means of coming to terms with challenges like the following?
 
1. Many large operators administer multiple ASNs, but some of the resulting AS sibling relationships may not be identifiable as such based on public-facing whois records, or interconnection relationships, or any other public data sources. Does your system incorporate some means of attributing reputation-related information at the (multi-AS) institutional level -- even when the contours of such institutions are not self-evident?

2. Some members of the ARIN community have recently floated a policy proposal which if approved would make ASNs transferable, and some supporters of that proposal have argued that RIR involvement in such transfers should be strictly limited to the passive recording of whatever information is voluntarily disclosed by the transacting parties, if and when a disclosure is made. Does your system ascribe reputation "strictly" to specific ASNs, such that declared changes in an ASN's "ownership"/control would not affect that ASNs accumulated reputation record to-date? Alternately, if declared changes to an ASN's ownership would affect (e.g., restart) an ASN's reputation history, will your system incorporate some mechanism for assessing the material/operational "substance" of ASN re-registration events (e.g., to filter for possible "re-registrations of convenience")? 

I like to ask these sort of questions (for any/all proposed systems like this) because it seems to me that any system that associates increasing value with a cumulative record of consistent "approved" behavior over time must take extra care not to provide *asymmetrical* opportunities (i.e., to some but not all participants) to isolate and sanitize their own "disapproved" behavior, thereby leaving their longstanding (favorable) reputations intact. 

Note that this problem is *not* reducible to the idea that a reputation system must be absolutely infallible. Obviously it is not reasonable to demand something that is impossible to deliver. However, it is altogether reasonable to demand that any system that is intentionally designed to produce a new, endogenously-driven reputation-based hierarchy of operational entities does something more than just recreate and reinforce pre-existing hierarchies that are completely orthogonal to "reputation."

Look forward to hearing more!

Regards, 

TV
   




 

From mkarir at merit.edu  Mon Sep 26 00:11:50 2011
From: mkarir at merit.edu (Manish Karir)
Date: Mon, 26 Sep 2011 01:11:50 -0400
Subject: "general badness" AS-based reputation system
In-Reply-To: <A0C871B5-DAE5-433B-9331-6907F3D13053@eyeconomics.com>
References: <mailman.9160.1316989916.1873.nanog@nanog.org>
 <0EA58FFF-2FBE-4977-BC62-211842FEB52E@merit.edu>
 <A0C871B5-DAE5-433B-9331-6907F3D13053@eyeconomics.com>
Message-ID: <0971129B-EC85-42C1-9B0D-6EA4420D3550@merit.edu>


On Sep 25, 2011, at 11:31 PM, Tom Vest wrote:

> 
> On Sep 25, 2011, at 9:23 PM, Manish Karir wrote:
> 
>> On Sep 25, 2011, at 6:31 PM, nanog-request at nanog.org wrote:
>> 
>>> Message: 9
>>> Date: Sun, 25 Sep 2011 18:37:17 +0300
>>> From: Gadi Evron <ge at linuxbox.org>
>>> To: nanog at nanog.org
>>> Subject: "general badness" AS-based reputation system
>>> Message-ID: <4E7F4AAD.8020400 at linuxbox.org>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>> 
>>> Having run one of these in the past, when take-downs of C&Cs was still 
>>> semi-useful, my ethos on this is problematic, however, I am as of yet 
>>> undecided as to this one. An AS-based reputation system for all sorts of 
>>> badness:
>>> 
>>> http://bgpranking.circl.lu/
>>> 
>>> In my opinion, third-party security based AS-reputation systems will 
>>> eventually become de-facto border filtering systems for ISPs, but that 
>>> day is still not here, as that is still socially unacceptable in our 
>>> circles, and will remain so until it becomes _necessary_.
>>> 
>>> Regardless of my musings of Operators World cultural future, this 
>>> systems seems rather interesting, and no doubt you'd want to take a look 
>>> at your listing.
>>> 
>>> Gadi.
>> 
>> We tried to outline some of the challenges of building such a system in our NANOG52 presentation:
>> 
>> http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf
>> 
>> In particular see slide 4. where we tried to lay down what we think the requirements are for a socially acceptable
>> reputation system.  
>> 
>> With a bit of luck we might be able to announce the release of our system before the next NANOG mtg, but in 
>> my opinion collating host reputation reports is just a small and the easiest part of the effort.  The key is in 
>> solving the challenges of allowing (and incentivizing) participation and being robust to false information
>> injection.
>> 
>> Comments are welcome.
>> 
>> Thanks.
>> -manish
> 
> Hi Manish, 
> 
> Looks like very interesting work.
> 
> Does the system that you'll be announcing provide some means of coming to terms with challenges like the following?
> 
> 1. Many large operators administer multiple ASNs, but some of the resulting AS sibling relationships may not be identifiable as such based on public-facing whois records, or interconnection relationships, or any other public data sources. Does your system incorporate some means of attributing reputation-related information at the (multi-AS) institutional level -- even when the contours of such institutions are not self-evident?
> 
> 2. Some members of the ARIN community have recently floated a policy proposal which if approved would make ASNs transferable, and some supporters of that proposal have argued that RIR involvement in such transfers should be strictly limited to the passive recording of whatever information is voluntarily disclosed by the transacting parties, if and when a disclosure is made. Does your system ascribe reputation "strictly" to specific ASNs, such that declared changes in an ASN's "ownership"/control would not affect that ASNs accumulated reputation record to-date? Alternately, if declared changes to an ASN's ownership would affect (e.g., restart) an ASN's reputation history, will your system incorporate some mechanism for assessing the material/operational "substance" of ASN re-registration events (e.g., to filter for possible "re-registrations of convenience")? 
> 
> I like to ask these sort of questions (for any/all proposed systems like this) because it seems to me that any system that associates increasing value with a cumulative record of consistent "approved" behavior over time must take extra care not to provide *asymmetrical* opportunities (i.e., to some but not all participants) to isolate and sanitize their own "disapproved" behavior, thereby leaving their longstanding (favorable) reputations intact. 
> 
> Note that this problem is *not* reducible to the idea that a reputation system must be absolutely infallible. Obviously it is not reasonable to demand something that is impossible to deliver. However, it is altogether reasonable to demand that any system that is intentionally designed to produce a new, endogenously-driven reputation-based hierarchy of operational entities does something more than just recreate and reinforce pre-existing hierarchies that are completely orthogonal to "reputation."
> 
> Look forward to hearing more!
> 
> Regards, 
> 
> TV
> 
> 
> 
> 
> 

Hi Tom,

At what granularity reputation is useful is an excellent question.  Obviously we already have lots of single data source based host reputation sources.
Other possible aggregations are prefixes, ASNs, and as you suggest organizations (which might be multi-ASN).  Another extreme possible aggregation is country.

In my opinion BGP prefix is the right level of aggregation up to be actually useful rather than narrow host reputation lists.  You might expect hosts in a 
prefix to be under the same security policy regime and hence have similar
likelihood of future malicious behavior so this approach would be more useful than host reputation which is entirely reactive and ASN reputation which 
does'nt allow for different parts of an organization which might run their networks with different policies.  

In our system an ASN's reputation at any given time is based on aggregating up the reputation of all the prefixes originated by that ASN.  Therefore it does
not really have a reputation that exists independently of its component prefixes.  If an ASN were to be transferred we would simply recompute the 
current reputation to be based on the new set of prefixes it is originating.

For prefix reputation you would want to track it on a historical basis with the assumption that it is quite unlikely that a prefixes reputation will undergo a sudden change and therefore tracking historical data would be useful.  We do not do this right now, but this is not a solved problem yet ;)

-manish








From ops.lists at gmail.com  Mon Sep 26 00:29:19 2011
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Mon, 26 Sep 2011 10:59:19 +0530
Subject: "general badness" AS-based reputation system
In-Reply-To: <0971129B-EC85-42C1-9B0D-6EA4420D3550@merit.edu>
References: <mailman.9160.1316989916.1873.nanog@nanog.org>
 <0EA58FFF-2FBE-4977-BC62-211842FEB52E@merit.edu>
 <A0C871B5-DAE5-433B-9331-6907F3D13053@eyeconomics.com>
 <0971129B-EC85-42C1-9B0D-6EA4420D3550@merit.edu>
Message-ID: <CAArzuou+wHVLNpNW1LNuc7QXxPYx49oL=mHm_bp3mSpPtTLsqA@mail.gmail.com>

I would probably limit this to simply identifying rogue prefixes [such as
those prefixes - and there are some - owned entirely by criminal spammers,
botnet C&Cs etc]

[let us not get into a discussion on listing criteria or what constitutes
criminal spam just now, there's a whole lot of such discussion and even a
decent RFC draft]
http://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists-07

On Mon, Sep 26, 2011 at 10:41 AM, Manish Karir <mkarir at merit.edu> wrote:

>
> On Sep 25, 2011, at 11:31 PM, Tom Vest wrote:
>
> >
> > On Sep 25, 2011, at 9:23 PM, Manish Karir wrote:
> >
> >> On Sep 25, 2011, at 6:31 PM, nanog-request at nanog.org wrote:
> >>
> >>> Message: 9
> >>> Date: Sun, 25 Sep 2011 18:37:17 +0300
> >>> From: Gadi Evron <ge at linuxbox.org>
> >>> To: nanog at nanog.org
> >>> Subject: "general badness" AS-based reputation system
> >>> Message-ID: <4E7F4AAD.8020400 at linuxbox.org>
> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >>>
> >>> Having run one of these in the past, when take-downs of C&Cs was still
> >>> semi-useful, my ethos on this is problematic, however, I am as of yet
> >>> undecided as to this one. An AS-based reputation system for all sorts
> of
> >>> badness:
> >>>
> >>> http://bgpranking.circl.lu/
> >>>
> >>> In my opinion, third-party security based AS-reputation systems will
> >>> eventually become de-facto border filtering systems for ISPs, but that
> >>> day is still not here, as that is still socially unacceptable in our
> >>> circles, and will remain so until it becomes _necessary_.
> >>>
> >>> Regardless of my musings of Operators World cultural future, this
> >>> systems seems rather interesting, and no doubt you'd want to take a
> look
> >>> at your listing.
> >>>
> >>> Gadi.
> >>
> >> We tried to outline some of the challenges of building such a system in
> our NANOG52 presentation:
> >>
> >>
> http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf
> >>
> >> In particular see slide 4. where we tried to lay down what we think the
> requirements are for a socially acceptable
> >> reputation system.
> >>
> >> With a bit of luck we might be able to announce the release of our
> system before the next NANOG mtg, but in
> >> my opinion collating host reputation reports is just a small and the
> easiest part of the effort.  The key is in
> >> solving the challenges of allowing (and incentivizing) participation and
> being robust to false information
> >> injection.
> >>
> >> Comments are welcome.
> >>
> >> Thanks.
> >> -manish
> >
> > Hi Manish,
> >
> > Looks like very interesting work.
> >
> > Does the system that you'll be announcing provide some means of coming to
> terms with challenges like the following?
> >
> > 1. Many large operators administer multiple ASNs, but some of the
> resulting AS sibling relationships may not be identifiable as such based on
> public-facing whois records, or interconnection relationships, or any other
> public data sources. Does your system incorporate some means of attributing
> reputation-related information at the (multi-AS) institutional level -- even
> when the contours of such institutions are not self-evident?
> >
> > 2. Some members of the ARIN community have recently floated a policy
> proposal which if approved would make ASNs transferable, and some supporters
> of that proposal have argued that RIR involvement in such transfers should
> be strictly limited to the passive recording of whatever information is
> voluntarily disclosed by the transacting parties, if and when a disclosure
> is made. Does your system ascribe reputation "strictly" to specific ASNs,
> such that declared changes in an ASN's "ownership"/control would not affect
> that ASNs accumulated reputation record to-date? Alternately, if declared
> changes to an ASN's ownership would affect (e.g., restart) an ASN's
> reputation history, will your system incorporate some mechanism for
> assessing the material/operational "substance" of ASN re-registration events
> (e.g., to filter for possible "re-registrations of convenience")?
> >
> > I like to ask these sort of questions (for any/all proposed systems like
> this) because it seems to me that any system that associates increasing
> value with a cumulative record of consistent "approved" behavior over time
> must take extra care not to provide *asymmetrical* opportunities (i.e., to
> some but not all participants) to isolate and sanitize their own
> "disapproved" behavior, thereby leaving their longstanding (favorable)
> reputations intact.
> >
> > Note that this problem is *not* reducible to the idea that a reputation
> system must be absolutely infallible. Obviously it is not reasonable to
> demand something that is impossible to deliver. However, it is altogether
> reasonable to demand that any system that is intentionally designed to
> produce a new, endogenously-driven reputation-based hierarchy of operational
> entities does something more than just recreate and reinforce pre-existing
> hierarchies that are completely orthogonal to "reputation."
> >
> > Look forward to hearing more!
> >
> > Regards,
> >
> > TV
> >
> >
> >
> >
> >
>
> Hi Tom,
>
> At what granularity reputation is useful is an excellent question.
>  Obviously we already have lots of single data source based host reputation
> sources.
> Other possible aggregations are prefixes, ASNs, and as you suggest
> organizations (which might be multi-ASN).  Another extreme possible
> aggregation is country.
>
> In my opinion BGP prefix is the right level of aggregation up to be
> actually useful rather than narrow host reputation lists.  You might expect
> hosts in a
> prefix to be under the same security policy regime and hence have similar
> likelihood of future malicious behavior so this approach would be more
> useful than host reputation which is entirely reactive and ASN reputation
> which
> does'nt allow for different parts of an organization which might run their
> networks with different policies.
>
> In our system an ASN's reputation at any given time is based on aggregating
> up the reputation of all the prefixes originated by that ASN.  Therefore it
> does
> not really have a reputation that exists independently of its component
> prefixes.  If an ASN were to be transferred we would simply recompute the
> current reputation to be based on the new set of prefixes it is
> originating.
>
> For prefix reputation you would want to track it on a historical basis with
> the assumption that it is quite unlikely that a prefixes reputation will
> undergo a sudden change and therefore tracking historical data would be
> useful.  We do not do this right now, but this is not a solved problem yet
> ;)
>
> -manish
>
>
>
>
>
>
>
>


-- 
Suresh Ramasubramanian (ops.lists at gmail.com)

From a.harrowell at gmail.com  Mon Sep 26 03:18:10 2011
From: a.harrowell at gmail.com (Alexander Harrowell)
Date: Mon, 26 Sep 2011 09:18:10 +0100
Subject: Nxdomain redirect revenue
In-Reply-To: <4E7FAD20.8070006@foobar.org>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <201109251240.06149.a.harrowell@gmail.com> <4E7FAD20.8070006@foobar.org>
Message-ID: <201109260918.10831.a.harrowell@gmail.com>

On Sunday 25 Sep 2011 23:37:20 Nick Hilliard wrote:
> On 25/09/2011 12:39, Alexander Harrowell wrote:
> > I think a special mention should go to hardware vendors who adopt 
this 
> > dreadful practice in network equipment. I recently encountered an 
> > enterprise-grade WLAN router from vendor D that has the horrible 
habit 
> 
> It is not libellous to associate a vendor's real name with calmly 
stated
> matters of objective fact concerning their products.
> 
> I'd be interested to know the particular model that you're referring 
to
> here - like you, to put it on a list of kit that I will never buy.
> 
> Re: "enterprise-grade" - did you mean this as a compliment or an 
insult?
> 
> Nick
> 

It's D-Link, if you hadn't guessed, and it's the DIR series.

Regarding "enterprise", these devices are not service provider kit but 
they're not under-the-TV-set either, and our use-case is basically 
typical of a branch-office set up. In which the DIR works really well, 
if it didn't do demented things with DNS.

-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110926/6c747c7f/attachment.bin>

From fweimer at bfk.de  Mon Sep 26 03:29:53 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Mon, 26 Sep 2011 08:29:53 +0000
Subject: Nxdomain redirect revenue
In-Reply-To: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 (Cameron Byrne's message of "Sat, 24 Sep 2011 18:33:04 -0700")
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
Message-ID: <82sjnjg0zi.fsf@mid.bfk.de>

* Cameron Byrne:

> It is very important to ask the redirect partners about yields... meaning,
> you may find that less than 5% of nxdomain redirects can be actually served
> an ad page because 95%+ of nxd are printer lookups and such that cannot be
> served an ad page.  Then from that less than 5% pool, the click through
> rates are around 1%

Is this with strict NXDOMAIN rewriting, or were existing names
redirected as well?  (AFAIK, most platforms do the latter, hijacking
bfk.de, for example.)

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From naiden.dimitrov at maxtelecom.bg  Mon Sep 26 05:07:45 2011
From: naiden.dimitrov at maxtelecom.bg (Naiden Dimitrov)
Date: Mon, 26 Sep 2011 13:07:45 +0300
Subject: flow generating tool
Message-ID: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>

Hello,



I need a tool that generates traffic flows from different source IP addresses for network tests.



Regards,



Naiden Dimitrov
Mobile: +359 885 906 155
naiden.dimitrov at maxtelecom.bg<mailto:naiden.dimitrov at maxtelecom.bg>
www.maxtelecom.bg<http://www.maxtelecom.bg>






From leschnik at gmail.com  Mon Sep 26 05:21:26 2011
From: leschnik at gmail.com (Jason Leschnik)
Date: Mon, 26 Sep 2011 20:21:26 +1000
Subject: flow generating tool
In-Reply-To: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
References: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
Message-ID: <CAN1XHteVTKSLuZ9RxVna4ZzuXXcisbT5ePeO385-X4Xu5J01PQ@mail.gmail.com>

Iperf is a good start

http://iperf.sourceforge.net/

Would be interested in any other tools as well.

-- 
Regards,
Jason Leschnik.

[m] 0432 35 4224
[w@] jason dot leschnik <at> ansto dot gov dot au<jason.leschnik at ansto.gov.au>
[U@] jml974 at uow.edu.au

From naiden.dimitrov at maxtelecom.bg  Mon Sep 26 06:49:50 2011
From: naiden.dimitrov at maxtelecom.bg (Naiden Dimitrov)
Date: Mon, 26 Sep 2011 14:49:50 +0300
Subject: flow generating tool
In-Reply-To: <m2oby7edd9.fsf@sslvpn-97-43.sei.cmu.edu>
References: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
 <m2oby7edd9.fsf@sslvpn-97-43.sei.cmu.edu>
Message-ID: <D200EA14D9516C49B07F3DA72D7E24C13371308ED1@INXS.max.sf>

Thank you for the response, but this is a tool that examines data flows. I need a tool that generates data flows in order to test network equipment.

Regards,

Naiden Dimitrov
naiden.dimitrov at maxtelecom.bg
www.maxtelecom.bg





-----Original Message-----
From: George Jones [mailto:gmj at cert.org]
Sent: Monday, September 26, 2011 2:45 PM
To: Naiden Dimitrov
Cc: nanog at nanog.org
Subject: Re: flow generating tool

>>>>> On Mon, 26 Sep 2011 13:07:45 +0300, Naiden Dimitrov <naiden.dimitrov at maxtelecom.bg> said:

    nd> Hello, I need a tool that generates traffic flows from different
    nd> source IP addresses for network tests.

http://tools.netsa.cert.org/yaf/


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6494 (20110926) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6494 (20110926) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



From tvest at eyeconomics.com  Mon Sep 26 07:13:06 2011
From: tvest at eyeconomics.com (Tom Vest)
Date: Mon, 26 Sep 2011 08:13:06 -0400
Subject: "general badness" AS-based reputation system
In-Reply-To: <0971129B-EC85-42C1-9B0D-6EA4420D3550@merit.edu>
References: <mailman.9160.1316989916.1873.nanog@nanog.org>
 <0EA58FFF-2FBE-4977-BC62-211842FEB52E@merit.edu>
 <A0C871B5-DAE5-433B-9331-6907F3D13053@eyeconomics.com>
 <0971129B-EC85-42C1-9B0D-6EA4420D3550@merit.edu>
Message-ID: <71CA3387-35B2-4C53-98F2-485B6385622A@eyeconomics.com>


On Sep 26, 2011, at 1:11 AM, Manish Karir wrote:

> 
> On Sep 25, 2011, at 11:31 PM, Tom Vest wrote:
> 
>> 
>> On Sep 25, 2011, at 9:23 PM, Manish Karir wrote:
>> 
>>> On Sep 25, 2011, at 6:31 PM, nanog-request at nanog.org wrote:
>>> 
>>>> Message: 9
>>>> Date: Sun, 25 Sep 2011 18:37:17 +0300
>>>> From: Gadi Evron <ge at linuxbox.org>
>>>> To: nanog at nanog.org
>>>> Subject: "general badness" AS-based reputation system
>>>> Message-ID: <4E7F4AAD.8020400 at linuxbox.org>
>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>> 
>>>> Having run one of these in the past, when take-downs of C&Cs was still 
>>>> semi-useful, my ethos on this is problematic, however, I am as of yet 
>>>> undecided as to this one. An AS-based reputation system for all sorts of 
>>>> badness:
>>>> 
>>>> http://bgpranking.circl.lu/
>>>> 
>>>> In my opinion, third-party security based AS-reputation systems will 
>>>> eventually become de-facto border filtering systems for ISPs, but that 
>>>> day is still not here, as that is still socially unacceptable in our 
>>>> circles, and will remain so until it becomes _necessary_.
>>>> 
>>>> Regardless of my musings of Operators World cultural future, this 
>>>> systems seems rather interesting, and no doubt you'd want to take a look 
>>>> at your listing.
>>>> 
>>>> Gadi.
>>> 
>>> We tried to outline some of the challenges of building such a system in our NANOG52 presentation:
>>> 
>>> http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf
>>> 
>>> In particular see slide 4. where we tried to lay down what we think the requirements are for a socially acceptable
>>> reputation system.  
>>> 
>>> With a bit of luck we might be able to announce the release of our system before the next NANOG mtg, but in 
>>> my opinion collating host reputation reports is just a small and the easiest part of the effort.  The key is in 
>>> solving the challenges of allowing (and incentivizing) participation and being robust to false information
>>> injection.
>>> 
>>> Comments are welcome.
>>> 
>>> Thanks.
>>> -manish
>> 
>> Hi Manish, 
>> 
>> Looks like very interesting work.
>> 
>> Does the system that you'll be announcing provide some means of coming to terms with challenges like the following?
>> 
>> 1. Many large operators administer multiple ASNs, but some of the resulting AS sibling relationships may not be identifiable as such based on public-facing whois records, or interconnection relationships, or any other public data sources. Does your system incorporate some means of attributing reputation-related information at the (multi-AS) institutional level -- even when the contours of such institutions are not self-evident?
>> 
>> 2. Some members of the ARIN community have recently floated a policy proposal which if approved would make ASNs transferable, and some supporters of that proposal have argued that RIR involvement in such transfers should be strictly limited to the passive recording of whatever information is voluntarily disclosed by the transacting parties, if and when a disclosure is made. Does your system ascribe reputation "strictly" to specific ASNs, such that declared changes in an ASN's "ownership"/control would not affect that ASNs accumulated reputation record to-date? Alternately, if declared changes to an ASN's ownership would affect (e.g., restart) an ASN's reputation history, will your system incorporate some mechanism for assessing the material/operational "substance" of ASN re-registration events (e.g., to filter for possible "re-registrations of convenience")? 
>> 
>> I like to ask these sort of questions (for any/all proposed systems like this) because it seems to me that any system that associates increasing value with a cumulative record of consistent "approved" behavior over time must take extra care not to provide *asymmetrical* opportunities (i.e., to some but not all participants) to isolate and sanitize their own "disapproved" behavior, thereby leaving their longstanding (favorable) reputations intact. 
>> 
>> Note that this problem is *not* reducible to the idea that a reputation system must be absolutely infallible. Obviously it is not reasonable to demand something that is impossible to deliver. However, it is altogether reasonable to demand that any system that is intentionally designed to produce a new, endogenously-driven reputation-based hierarchy of operational entities does something more than just recreate and reinforce pre-existing hierarchies that are completely orthogonal to "reputation."
>> 
>> Look forward to hearing more!
>> 
>> Regards, 
>> 
>> TV

> Hi Tom,
> 
> At what granularity reputation is useful is an excellent question.  Obviously we already have lots of single data source based host reputation sources.
> Other possible aggregations are prefixes, ASNs, and as you suggest organizations (which might be multi-ASN).  Another extreme possible aggregation is country.
> 
> In my opinion BGP prefix is the right level of aggregation up to be actually useful rather than narrow host reputation lists.  You might expect hosts in a 
> prefix to be under the same security policy regime and hence have similar
> likelihood of future malicious behavior so this approach would be more useful than host reputation which is entirely reactive and ASN reputation which 
> does'nt allow for different parts of an organization which might run their networks with different policies.  
> 
> In our system an ASN's reputation at any given time is based on aggregating up the reputation of all the prefixes originated by that ASN.  Therefore it does
> not really have a reputation that exists independently of its component prefixes.  If an ASN were to be transferred we would simply recompute the 
> current reputation to be based on the new set of prefixes it is originating.
> 
> For prefix reputation you would want to track it on a historical basis with the assumption that it is quite unlikely that a prefixes reputation will undergo a sudden change and therefore tracking historical data would be useful.  We do not do this right now, but this is not a solved problem yet ;)
> 
> -manish

Thanks Manish. 

If I understand your response correctly, it sounds like the proposed system treats prefix-level reputation "strictly," ala my (#2) questions above. Given the fact that several RIRs already permit the transfer of prefixes between different ASN-operating entities, it might be worth considering the same questions again with the subject "ASN" replaced by "prefix." If some quantity of IPv4 continues to be necessary in order for an operator to be meaningfully autonomous, and this condition persists for a decade or longer after the unallocated IPv4 pool is depleted (assumptions that were frequently cited by IPv4 transfer policy supporters), it seems reasonable to assume that the already large number of single (IPv4) prefix-originating ASNs will only continue to grow, as small quantities of IPv4 are transferred from incumbent operators with "large" IPv4 reserves to new entrants who are likely to be highly dependent on the transferred resources (which might carry their own lingering reputation "baggage") for interdomain connectivity. To me at least, that suggests that the capacity to track reputation-relevant information over time and across "ownership" changes is likely to become an increasingly important requirement/demand driver for reputation systems, while the applicability of origin-AS information averaging methods is likely to continue declining. 

Food for thought, 

TV








From gmj at cert.org  Mon Sep 26 07:45:22 2011
From: gmj at cert.org (George Jones)
Date: Mon, 26 Sep 2011 08:45:22 -0400
Subject: flow generating tool
In-Reply-To: <D200EA14D9516C49B07F3DA72D7E24C13371308ED1@INXS.max.sf> (Naiden
 Dimitrov's message of "Mon, 26 Sep 2011 14:49:50 +0300")
References: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
 <m2oby7edd9.fsf@sslvpn-97-43.sei.cmu.edu>
 <D200EA14D9516C49B07F3DA72D7E24C13371308ED1@INXS.max.sf>
Message-ID: <m2y5xbcw0t.fsf@sslvpn-97-43.sei.cmu.edu>

>>>>> On Mon, 26 Sep 2011 14:49:50 +0300, Naiden Dimitrov <naiden.dimitrov at maxtelecom.bg> said:

    nd> Thank you for the response, but this is a tool that examines
    nd> data flows. 

Sorry I missed your context.  YAF will generate flows (which is what I
thought you were asking) as it sees packets stream by, but it sounds
like you want something that puts traffic on the wire.

An old standby is:

  http://tcpreplay.synfin.net/

and of course there are commercial options.  Not sure how up to date
this is, but there are quite a few options listed here:

  http://www.protocoltesting.com/trgen.html

---George Jones


From ebais at a2b-internet.com  Mon Sep 26 08:03:54 2011
From: ebais at a2b-internet.com (Erik Bais)
Date: Mon, 26 Sep 2011 15:03:54 +0200
Subject: flow generating tool
In-Reply-To: <D200EA14D9516C49B07F3DA72D7E24C13371308ED1@INXS.max.sf>
References: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
 <m2oby7edd9.fsf@sslvpn-97-43.sei.cmu.edu>
 <D200EA14D9516C49B07F3DA72D7E24C13371308ED1@INXS.max.sf>
Message-ID: <007101cc7c4c$bf18bd10$3d4a3730$@com>

Perhaps not a tool as in software, but clearly something that you might want
to have a look at : 

Ixia and Spirent devices ... Those are mostly used for applications like
generating different kind of traffic. 

Erik Bais





From jiaruchen at gmail.com  Mon Sep 26 08:36:46 2011
From: jiaruchen at gmail.com (jiaruchen at gmail.com)
Date: Mon, 26 Sep 2011 13:36:46 +0000
Subject: flow generating tool
Message-ID: <1811440887-1317044547-cardhu_decombobulator_blackberry.rim.net-1692329397-@b16.c10.bise6.blackberry>

Iperf(linux) and jperf(windows) does generate traffic flows. You simply set up sender/receiver and it'll generate traffic load. It can generate 10gig line rate unicast flows but multicast replication is limited because it is software based. 

Iperf/jperf however, is not as flexible or anywhere as feature rich and powerful as some of the other hardware solutions as mentioned earlier - ex: ixia, spirent etc. 

-Jia 
------Original Message------
From: Erik Bais
To: 'Naiden Dimitrov'
To: 'George Jones'
Cc: nanog at nanog.org
Subject: RE: flow generating tool
Sent: Sep 26, 2011 9:03 AM

Perhaps not a tool as in software, but clearly something that you might want
to have a look at : 

Ixia and Spirent devices ... Those are mostly used for applications like
generating different kind of traffic. 

Erik Bais








From ge at linuxbox.org  Mon Sep 26 08:52:04 2011
From: ge at linuxbox.org (Gadi Evron)
Date: Mon, 26 Sep 2011 16:52:04 +0300
Subject: "general badness" AS-based reputation system
In-Reply-To: <CAAAwwbW4SM0icz33UnASMPVqgY7sEvveG1RUELtdyf8gH5uvaQ@mail.gmail.com>
References: <4E7F4AAD.8020400@linuxbox.org>
 <CAAAwwbW4SM0icz33UnASMPVqgY7sEvveG1RUELtdyf8gH5uvaQ@mail.gmail.com>
Message-ID: <4E808384.7010300@linuxbox.org>

On 9/26/11 2:31 AM, Jimmy Hess wrote:
> Sorry... what makes  you think the problem with use of a
> AS-reputation systems is
> social and not technical?
>
> IP packets are not stamped with the numbers of any of the AS they
> transitted to reach your network.
> The IP protocol simply does not expose AS number information,
> therefore,  for filtering purposes,
> you don't actually have the information....

Filtering is dangerous, especially when done with ASNs. There are many 
technical challenges and many levels of filtering, all are technical 
issues and policy decisions based on how bad it's needed. Let's not 
forget how dangerous it is to block a network just to find out that your 
customers no longer get service, that is a much bigger issue that 
figuring our what is out technically, IMO.

I am in agreement with you -- which is why I focus on the cultural aspect.

Gadi.


From ge at linuxbox.org  Mon Sep 26 08:56:54 2011
From: ge at linuxbox.org (Gadi Evron)
Date: Mon, 26 Sep 2011 16:56:54 +0300
Subject: "general badness" AS-based reputation system
In-Reply-To: <0EA58FFF-2FBE-4977-BC62-211842FEB52E@merit.edu>
References: <mailman.9160.1316989916.1873.nanog@nanog.org>
 <0EA58FFF-2FBE-4977-BC62-211842FEB52E@merit.edu>
Message-ID: <4E8084A6.7000801@linuxbox.org>

> We tried to outline some of the challenges of building such a system in our NANOG52 presentation:
>
> http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf
>
> In particular see slide 4. where we tried to lay down what we think the requirements are for a socially acceptable
> reputation system.
>
> With a bit of luck we might be able to announce the release of our system before the next NANOG mtg, but in
> my opinion collating host reputation reports is just a small and the easiest part of the effort.  The key is in
> solving the challenges of allowing (and incentivizing) participation and being robust to false information
> injection.

I've actually encountered a system that was accepted for operational use 
once. Bad data was added at some point (bound to happen) and the system 
was shut down.

Thanks for sharing your slides, keep up the good work!

	Gadi.


From leschnik at gmail.com  Mon Sep 26 09:02:11 2011
From: leschnik at gmail.com (Jason Leschnik)
Date: Tue, 27 Sep 2011 00:02:11 +1000
Subject: flow generating tool
In-Reply-To: <1811440887-1317044547-cardhu_decombobulator_blackberry.rim.net-1692329397-@b16.c10.bise6.blackberry>
References: <1811440887-1317044547-cardhu_decombobulator_blackberry.rim.net-1692329397-@b16.c10.bise6.blackberry>
Message-ID: <CAN1XHtd7FMZ7T6XOM8Rcr5uTbAYBvNGKPd3-0P9DqYrGpTktQA@mail.gmail.com>

Does anyone follow a network performance testing methodology, using hardware
from companies like ixia/spirent?

I know that basic testing is typically done for validation of configs, but i
assume other issues would make themselves apparent when pushed to these
higher loads.

thoughts/comments?

Thanks

-- 
Regards,
Jason Leschnik.

[m] 0432 35 4224
[w@] jason dot leschnik <at> ansto dot gov dot au<jason.leschnik at ansto.gov.au>
[U@] jml974 at uow.edu.au

From cb.list6 at gmail.com  Mon Sep 26 09:25:05 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 26 Sep 2011 07:25:05 -0700
Subject: Nxdomain redirect revenue
In-Reply-To: <82sjnjg0zi.fsf@mid.bfk.de>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de>
Message-ID: <CAD6AjGRpGbRZoWGXnbp4nKyC5cyVeSg9UdhdSbyyEk3gPMiCBQ@mail.gmail.com>

On Sep 26, 2011 1:29 AM, "Florian Weimer" <fweimer at bfk.de> wrote:
>
> * Cameron Byrne:
>
> > It is very important to ask the redirect partners about yields...
meaning,
> > you may find that less than 5% of nxdomain redirects can be actually
served
> > an ad page because 95%+ of nxd are printer lookups and such that cannot
be
> > served an ad page.  Then from that less than 5% pool, the click through
> > rates are around 1%
>
> Is this with strict NXDOMAIN rewriting, or were existing names
> redirected as well?  (AFAIK, most platforms do the latter, hijacking
> bfk.de, for example.)
>

I have no experience with hijacking real names, which others have noted is
evil.

Cb
> --
> Florian Weimer                <fweimer at bfk.de>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstra?e 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99

From gmj at cert.org  Mon Sep 26 09:29:47 2011
From: gmj at cert.org (George Jones)
Date: Mon, 26 Sep 2011 10:29:47 -0400
Subject: flow generating tool
In-Reply-To: <CAN1XHtd7FMZ7T6XOM8Rcr5uTbAYBvNGKPd3-0P9DqYrGpTktQA@mail.gmail.com>
 (Jason Leschnik's message of "Mon, 26 Sep 2011 10:02:11 -0400")
References: <1811440887-1317044547-cardhu_decombobulator_blackberry.rim.net-1692329397-@b16.c10.bise6.blackberry>
 <CAN1XHtd7FMZ7T6XOM8Rcr5uTbAYBvNGKPd3-0P9DqYrGpTktQA@mail.gmail.com>
Message-ID: <m2ipofcr6s.fsf@sslvpn-97-43.sei.cmu.edu>

>>>>> On Mon, 26 Sep 2011 10:02:11 -0400, Jason Leschnik <leschnik at gmail.com> said:

    jl> Does anyone follow a network performance testing methodology,
    jl> using hardware from companies like ixia/spirent?

Probably more/more formal than you want, but:

  http://www.ietf.org/dyn/wg/charter/bmwg-charter

And I think you may find that some of the vendor folks are active in the WG.

---George Jones



From galu at packetdam.com  Mon Sep 26 09:30:33 2011
From: galu at packetdam.com (Vlad Galu)
Date: Mon, 26 Sep 2011 16:30:33 +0200
Subject: flow generating tool
In-Reply-To: <CAN1XHtd7FMZ7T6XOM8Rcr5uTbAYBvNGKPd3-0P9DqYrGpTktQA@mail.gmail.com>
References: <1811440887-1317044547-cardhu_decombobulator_blackberry.rim.net-1692329397-@b16.c10.bise6.blackberry>
 <CAN1XHtd7FMZ7T6XOM8Rcr5uTbAYBvNGKPd3-0P9DqYrGpTktQA@mail.gmail.com>
Message-ID: <8A814890-2A09-496C-869B-E68FB6BBC473@packetdam.com>

On Sep 26, 2011, at 4:02 PM, Jason Leschnik wrote:
> Does anyone follow a network performance testing methodology, using hardware
> from companies like ixia/spirent?
> 
> I know that basic testing is typically done for validation of configs, but i
> assume other issues would make themselves apparent when pushed to these
> higher loads.
> 
> thoughts/comments?
> 
> Thanks


It really depends on the product you are testing. If forwarding performance is what you want to measure, you would do it with various routing table sizes (starting small and ending with a global table). Packet size is also something you should look at.

We could provide better suggestions if you tell us what your product is.

Vlad Galu
galu at packetdam.com






From morrowc.lists at gmail.com  Mon Sep 26 09:36:51 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 26 Sep 2011 10:36:51 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <CAD6AjGRpGbRZoWGXnbp4nKyC5cyVeSg9UdhdSbyyEk3gPMiCBQ@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de>
 <CAD6AjGRpGbRZoWGXnbp4nKyC5cyVeSg9UdhdSbyyEk3gPMiCBQ@mail.gmail.com>
Message-ID: <CAL9jLaaGpu7AzoR2eyVsCDg1Ts2f_wcvhBRbEVxaMzxKPMw_sg@mail.gmail.com>

On Mon, Sep 26, 2011 at 10:25 AM, Cameron Byrne <cb.list6 at gmail.com> wrote:
> On Sep 26, 2011 1:29 AM, "Florian Weimer" <fweimer at bfk.de> wrote:
>>
>> * Cameron Byrne:
>>
>> > It is very important to ask the redirect partners about yields...
> meaning,
>> > you may find that less than 5% of nxdomain redirects can be actually
> served
>> > an ad page because 95%+ of nxd are printer lookups and such that cannot
> be
>> > served an ad page. ?Then from that less than 5% pool, the click through
>> > rates are around 1%
>>
>> Is this with strict NXDOMAIN rewriting, or were existing names
>> redirected as well? ?(AFAIK, most platforms do the latter, hijacking
>> bfk.de, for example.)
>>
>
> I have no experience with hijacking real names, which others have noted is
> evil.

I'm curious, is there some belief that the use of hte nxdomain
hijacking/rewriting is actually of use to 'users' ? (I'd seen folk
claim that the revenue was super-nice, and also it's super beneficial
to users...)

I don't happen to believe either of these reasons, cameron's note
about checking for the right set of numbers before signing contracts
seems to indicate that the revenue wasn't there either...

-chris


From creynolds at tsieda.com  Mon Sep 26 09:50:50 2011
From: creynolds at tsieda.com (Chuck Reynolds)
Date: Mon, 26 Sep 2011 10:50:50 -0400
Subject: flow generating tool
In-Reply-To: <8A814890-2A09-496C-869B-E68FB6BBC473@packetdam.com>
References: <1811440887-1317044547-cardhu_decombobulator_blackberry.rim.net-1692329397-@b16.c10.bise6.blackberry>
 <CAN1XHtd7FMZ7T6XOM8Rcr5uTbAYBvNGKPd3-0P9DqYrGpTktQA@mail.gmail.com>
 <8A814890-2A09-496C-869B-E68FB6BBC473@packetdam.com>
Message-ID: <00be01cc7c5b$b2dd56a0$189803e0$@com>

We have quite a number of companies using hardware from companies like Ixia
and Spirent - the key is to use tools that makes it easy to setup a testing
methodology without hiring a support staff. 

You can contact me directly for more information and how others like Cisco,
At&T, Vodafone and many more are doing this sort of testing. 

Regards,

Chuck
creynolds at tsieda.com

-----Original Message-----
From: Vlad Galu [mailto:galu at packetdam.com] 
Sent: Monday, September 26, 2011 10:31 AM
To: Jason Leschnik
Cc: George Jones; nanog at nanog.org; Naiden Dimitrov
Subject: Re: flow generating tool

On Sep 26, 2011, at 4:02 PM, Jason Leschnik wrote:
> Does anyone follow a network performance testing methodology, using
hardware
> from companies like ixia/spirent?
> 
> I know that basic testing is typically done for validation of configs, but
i
> assume other issues would make themselves apparent when pushed to these
> higher loads.
> 
> thoughts/comments?
> 
> Thanks


It really depends on the product you are testing. If forwarding performance
is what you want to measure, you would do it with various routing table
sizes (starting small and ending with a global table). Packet size is also
something you should look at.

We could provide better suggestions if you tell us what your product is.

Vlad Galu
galu at packetdam.com








From drew.weaver at thenap.com  Mon Sep 26 10:36:24 2011
From: drew.weaver at thenap.com (Drew Weaver)
Date: Mon, 26 Sep 2011 11:36:24 -0400
Subject: Sprint 3G/4G PPTP VPN connectivity
Message-ID: <F3318834F1F89D46857972DD4B411D7005220A6A82@exchange>

Has anyone been able to pull any magic off that allows PPTP connectivity over sprint's 3G/4G wireless network?

I assume they're just filtering it flat out, but before I contact them I wanted to see if anyone has found a resolution on their own.

I have several Nexus S 4G devices which are unable to get PPTP connections over 3G/4G but if you enable WIFI it comes up instantly.

I've been researching this off and on all weekend but wondered if anyone else had run into this issue.

thanks,
-Drew


From ekim.ittag at gmail.com  Mon Sep 26 10:47:33 2011
From: ekim.ittag at gmail.com (Mike Gatti)
Date: Mon, 26 Sep 2011 08:47:33 -0700
Subject: e-mail blacklisted - TIOPAN.COM
Message-ID: <0090EA58-091D-4ECA-8BCD-5121A66E763B@gmail.com>

If there is someone from the Company TIOPAN.COM on the list can you please contact me off line. 
My apologies to the other members of the list for using the list as a contact method. 

Thank you, 
--
Michael Gatti  
cell.949.735.5612
ekim.ittag at gmail.com
(UTC-8)





From tmaufer at gmail.com  Mon Sep 26 10:51:18 2011
From: tmaufer at gmail.com (Thomas Maufer)
Date: Mon, 26 Sep 2011 08:51:18 -0700
Subject: flow generating tool
In-Reply-To: <007101cc7c4c$bf18bd10$3d4a3730$@com>
References: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
 <m2oby7edd9.fsf@sslvpn-97-43.sei.cmu.edu>
 <D200EA14D9516C49B07F3DA72D7E24C13371308ED1@INXS.max.sf>
 <007101cc7c4c$bf18bd10$3d4a3730$@com>
Message-ID: <CA+HC50-Tu6K6gS23b99BUM0ELNOcUTgAyshiTy_Jb=K6ampHeQ@mail.gmail.com>

Another commercial tool (for large-scale application re-creation) is the Mu
Studio Performance Suite from Mu Dynamics:
http://www.mudynamics.com/resources/collaterals_noreg/Mu_Studio_Performance_Suite.pdf

~tom



On Mon, Sep 26, 2011 at 06:03, Erik Bais <ebais at a2b-internet.com> wrote:

> Perhaps not a tool as in software, but clearly something that you might
> want
> to have a look at :
>
> Ixia and Spirent devices ... Those are mostly used for applications like
> generating different kind of traffic.
>
> Erik Bais
>
>
>
>
>

From paul4004 at gmail.com  Mon Sep 26 12:07:16 2011
From: paul4004 at gmail.com (PC)
Date: Mon, 26 Sep 2011 11:07:16 -0600
Subject: Sprint 3G/4G PPTP VPN connectivity
In-Reply-To: <F3318834F1F89D46857972DD4B411D7005220A6A82@exchange>
References: <F3318834F1F89D46857972DD4B411D7005220A6A82@exchange>
Message-ID: <CAJAdsD==Qnn-XBqAhogTg4=gQr-mUtReycZ8VaDae5u=fnpnpA@mail.gmail.com>

I can't comment on your device or any interop issues, but I used l2tp ipsec
with this carrier without issue, if that might be an option.


On Mon, Sep 26, 2011 at 9:36 AM, Drew Weaver <drew.weaver at thenap.com> wrote:

> Has anyone been able to pull any magic off that allows PPTP connectivity
> over sprint's 3G/4G wireless network?
>
> I assume they're just filtering it flat out, but before I contact them I
> wanted to see if anyone has found a resolution on their own.
>
> I have several Nexus S 4G devices which are unable to get PPTP connections
> over 3G/4G but if you enable WIFI it comes up instantly.
>
> I've been researching this off and on all weekend but wondered if anyone
> else had run into this issue.
>
> thanks,
> -Drew
>
>

From dholmes at mwdh2o.com  Mon Sep 26 12:27:12 2011
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Mon, 26 Sep 2011 10:27:12 -0700
Subject: AT&T Wireless outage in SoCal
In-Reply-To: <201109242228.34603.choprboy@dakotacom.net>
References: <9C61C481-7673-4F91-B731-8E9FAEFCDF95@semihuman.com>
 <201109242224.08092.choprboy@dakotacom.net>
 <201109242228.34603.choprboy@dakotacom.net>
Message-ID: <922ACC42D498884AA02B3565688AF99533FEE3E10B@USEXMBS01.mwd.h2o>

Friday at 4 pm PDT our AT&T landline facilities fed by a Pasadena CO SONET ring, went dark.

-----Original Message-----
From: Adrian [mailto:choprboy at dakotacom.net]
Sent: Saturday, September 24, 2011 10:29 PM
To: nanog at nanog.org
Subject: Re: AT&T Wireless outage in SoCal

On Saturday 24 September 2011 22:24, Adrian wrote:
> On Saturday 24 September 2011 21:27, Chris Woodfield wrote:
> > Hearing rumblings of a major AT&T Wireless outage in southern California.
> > Anyone have more detail? Limited to cell towers or are transit circuits
> > affected?
>
> Apparently their switching and core infrastructure (affecting both voice
> and data) across the LA basin.

***I should clarify, apparently it is only affecting the ATT cell service.
Transit/landline service is apparently unaffected.


Adrian



This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.


From sethm at rollernet.us  Mon Sep 26 12:30:07 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 26 Sep 2011 10:30:07 -0700
Subject: Sprint 3G/4G PPTP VPN connectivity
In-Reply-To: <F3318834F1F89D46857972DD4B411D7005220A6A82@exchange>
References: <F3318834F1F89D46857972DD4B411D7005220A6A82@exchange>
Message-ID: <4E80B69F.4050803@rollernet.us>

On 9/26/11 8:36 AM, Drew Weaver wrote:
> Has anyone been able to pull any magic off that allows PPTP connectivity over sprint's 3G/4G wireless network?
> 
> I assume they're just filtering it flat out, but before I contact them I wanted to see if anyone has found a resolution on their own.
> 
> I have several Nexus S 4G devices which are unable to get PPTP connections over 3G/4G but if you enable WIFI it comes up instantly.
> 
> I've been researching this off and on all weekend but wondered if anyone else had run into this issue.
> 


I use often use PPTP on my original HTC EVO. Just tested it now and it
worked. 3G only, no 4G in my city.

~Seth


From cb.list6 at gmail.com  Mon Sep 26 12:33:35 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 26 Sep 2011 10:33:35 -0700
Subject: Sprint 3G/4G PPTP VPN connectivity
In-Reply-To: <4E80B69F.4050803@rollernet.us>
References: <F3318834F1F89D46857972DD4B411D7005220A6A82@exchange>
 <4E80B69F.4050803@rollernet.us>
Message-ID: <CAD6AjGQB1bZu6_WE++5_MM=se96b2a6tWAn=_Jqqi3mcww3Qeg@mail.gmail.com>

On Mon, Sep 26, 2011 at 10:30 AM, Seth Mattinen <sethm at rollernet.us> wrote:
> On 9/26/11 8:36 AM, Drew Weaver wrote:
>> Has anyone been able to pull any magic off that allows PPTP connectivity over sprint's 3G/4G wireless network?
>>
>> I assume they're just filtering it flat out, but before I contact them I wanted to see if anyone has found a resolution on their own.
>>
>> I have several Nexus S 4G devices which are unable to get PPTP connections over 3G/4G but if you enable WIFI it comes up instantly.
>>
>> I've been researching this off and on all weekend but wondered if anyone else had run into this issue.
>>
>
>
> I use often use PPTP on my original HTC EVO. Just tested it now and it
> worked. 3G only, no 4G in my city.
>

I have seen MTU issues with PPTP on cellular networks before with
Android.  You might want to try clamping the MTU down on the server
side.

Cameron


From lists-wispa at atomsplash.com  Mon Sep 26 12:41:32 2011
From: lists-wispa at atomsplash.com (Nick W)
Date: Mon, 26 Sep 2011 10:41:32 -0700
Subject: Sprint 3G/4G PPTP VPN connectivity
In-Reply-To: <F3318834F1F89D46857972DD4B411D7005220A6A82@exchange>
References: <F3318834F1F89D46857972DD4B411D7005220A6A82@exchange>
Message-ID: <CAJg9_YwHyMiu8TMJ+yihQUcd6kegTTRvKZqf9++UjzscL0ESGA@mail.gmail.com>

I have my EVO 4G connected right now over PPTP. I have seen issues
previously, but it seems like it varies from cell tower to cell tower.


On Mon, Sep 26, 2011 at 8:36 AM, Drew Weaver <drew.weaver at thenap.com> wrote:

> Has anyone been able to pull any magic off that allows PPTP connectivity
> over sprint's 3G/4G wireless network?
>
> I assume they're just filtering it flat out, but before I contact them I
> wanted to see if anyone has found a resolution on their own.
>
> I have several Nexus S 4G devices which are unable to get PPTP connections
> over 3G/4G but if you enable WIFI it comes up instantly.
>
> I've been researching this off and on all weekend but wondered if anyone
> else had run into this issue.
>
> thanks,
> -Drew
>
>

From sethm at rollernet.us  Mon Sep 26 12:47:22 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 26 Sep 2011 10:47:22 -0700
Subject: Sprint 3G/4G PPTP VPN connectivity
In-Reply-To: <CAD6AjGQB1bZu6_WE++5_MM=se96b2a6tWAn=_Jqqi3mcww3Qeg@mail.gmail.com>
References: <F3318834F1F89D46857972DD4B411D7005220A6A82@exchange>
 <4E80B69F.4050803@rollernet.us>
 <CAD6AjGQB1bZu6_WE++5_MM=se96b2a6tWAn=_Jqqi3mcww3Qeg@mail.gmail.com>
Message-ID: <4E80BAAA.8040902@rollernet.us>

On 9/26/11 10:33 AM, Cameron Byrne wrote:
> On Mon, Sep 26, 2011 at 10:30 AM, Seth Mattinen <sethm at rollernet.us> wrote:
>> On 9/26/11 8:36 AM, Drew Weaver wrote:
>>> Has anyone been able to pull any magic off that allows PPTP connectivity over sprint's 3G/4G wireless network?
>>>
>>> I assume they're just filtering it flat out, but before I contact them I wanted to see if anyone has found a resolution on their own.
>>>
>>> I have several Nexus S 4G devices which are unable to get PPTP connections over 3G/4G but if you enable WIFI it comes up instantly.
>>>
>>> I've been researching this off and on all weekend but wondered if anyone else had run into this issue.
>>>
>>
>>
>> I use often use PPTP on my original HTC EVO. Just tested it now and it
>> worked. 3G only, no 4G in my city.
>>
> 
> I have seen MTU issues with PPTP on cellular networks before with
> Android.  You might want to try clamping the MTU down on the server
> side.
> 


I had issues with older versions of Android, but those manifested
themselves as the PPTP tunnel would connect but no traffic would pass
over it. It was either the last update or the one before last that
resolved it for me.

~Seth


From rps at maine.edu  Mon Sep 26 12:49:21 2011
From: rps at maine.edu (Ray Soucy)
Date: Mon, 26 Sep 2011 13:49:21 -0400
Subject: vyatta for bgp
In-Reply-To: <A4428DD467A70E48B98693F1E20B198C01613619@V-ENT02.eu.netappliant.com>
References: <625DBB8B2639984C8DA8F8EB45A39BB60610DDF2@neuman.orscheln.oi.local>
 <CE23EFD8-F940-414B-ADAD-55502760C259@arbor.net>
 <20110913153747.GA91938@ussenterprise.ufp.org>
 <D338D1613B32624285BB321A5CF3DB25478F451A75@ginga.ai.net>
 <01544EDA-80E3-4880-8046-9A88C92A32D3@arbor.net>
 <CALFTrnMMPA1MsNLtrp5auE0uPVCO2aj5aME3ym8rE_qwDZoC0A@mail.gmail.com>
 <4E7202C4.9050502@pubnix.net>
 <CAJ0Nkqi14_JxxOPOG0_ZcNhXo7BD=WjpOb14evzD2Z2AyXGCMA@mail.gmail.com>
 <A4428DD467A70E48B98693F1E20B198C01613619@V-ENT02.eu.netappliant.com>
Message-ID: <CALFTrnNC9-V4pFcg_Wb2t++0sBojKQw2rnte1a3x-irvaX132w@mail.gmail.com>

We service most of the state's public schools and libraries (about
1000).  Historically the CPE of choice was a small Cisco ISR (1600,
1700, 1800, and 1900 most recently).  As bandwidth levels went up, and
Ethernet-based transport services became available, we started looking
and leveraging FOSS on commodity hardware to lower costs and move
services to the edge.  Right now we have about 100 of the bigger
school districts being services by a Linux-based appliance running
XORP for its routing engine (we would have tried Quagga, but they
don't support multicast routing yet, nor does Vyatta).

It's been a learning experience.  Most of the problems we ran into
have been resolved by tuning the kernel parameters to act more like a
router than a desktop or server.  XORP itself has had a rocky ride
since we started, so the stability of the project has also been a
concern.  Thankfully it is seeing somewhat active development again.
I will note that XORP is very touchy about how it's configured; if you
have well tested configuration templates it's fine, but it's very easy
to get it into a crashing state based on something as little the order
of configuration directives.  For the most part once it's running it's
stable.

Modest hardware (3.2GHz dual-core Xeon, 2GB RAM, with 1GB tied up as a
RAM disk) seems to do the job well for 100 Mbps without much issue,
and that's with stateful firewall, and web content filtering in place.

Instead of doing it in-house we found a vendor in MA that was doing
something similar to what we wanted and had them develop a modified
version of their existing offering for us.  The vendor is MECnet for
those interested.

On Thu, Sep 22, 2011 at 6:37 AM, Pierce Lynch <p.lynch at netappliant.com> wrote:
> Andreas Echavez [mailto:andreas at livejournalinc.com] originally wrote:
>> Ultimately, the network is as reliable as you build it. With software, it's much cheaper to divide and scale horizontally. Hardware devices are expensive and usually horizontal
>> scalability never happens. So in reality, an enterprise blows 100k on two routers, they both flop because of some "firmware bug", and you're down.
>
> With this in mind, I am keen to understand how many implementations of packages such as Quagga and Zebra that the group use. With the likes of Vyatta being discussed, I am keen to see if products such as Quagga as still regularly used as it used to be.
>
> Thoughts welcome!
>
> Kind regards,
>
> /P.
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From Valdis.Kletnieks at vt.edu  Mon Sep 26 13:11:49 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 26 Sep 2011 14:11:49 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: Your message of "Mon, 26 Sep 2011 10:36:51 EDT."
 <CAL9jLaaGpu7AzoR2eyVsCDg1Ts2f_wcvhBRbEVxaMzxKPMw_sg@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de>
 <CAD6AjGRpGbRZoWGXnbp4nKyC5cyVeSg9UdhdSbyyEk3gPMiCBQ@mail.gmail.com>
 <CAL9jLaaGpu7AzoR2eyVsCDg1Ts2f_wcvhBRbEVxaMzxKPMw_sg@mail.gmail.com>
Message-ID: <10876.1317060709@turing-police.cc.vt.edu>

On Mon, 26 Sep 2011 10:36:51 EDT, Christopher Morrow said:

> I'm curious, is there some belief that the use of hte nxdomain
> hijacking/rewriting is actually of use to 'users' ?

"of use to users" is, in general, incompatible with "race to the bottom".

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

From morrowc.lists at gmail.com  Mon Sep 26 13:17:34 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 26 Sep 2011 14:17:34 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <10876.1317060709@turing-police.cc.vt.edu>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de>
 <CAD6AjGRpGbRZoWGXnbp4nKyC5cyVeSg9UdhdSbyyEk3gPMiCBQ@mail.gmail.com>
 <CAL9jLaaGpu7AzoR2eyVsCDg1Ts2f_wcvhBRbEVxaMzxKPMw_sg@mail.gmail.com>
 <10876.1317060709@turing-police.cc.vt.edu>
Message-ID: <CAL9jLaZC0eofXFRQqV-ySTrpYUi7uCi74_oGpSnxLibnaxko8A@mail.gmail.com>

On Mon, Sep 26, 2011 at 2:11 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Mon, 26 Sep 2011 10:36:51 EDT, Christopher Morrow said:
>
>> I'm curious, is there some belief that the use of hte nxdomain
>> hijacking/rewriting is actually of use to 'users' ?
>
> "of use to users" is, in general, incompatible with "race to the bottom".

my point is that on the one hand the marketeers say: "This is a great
help to your users who are confused by the missing dns entries! They
like it! It is a benefit and a comfort to them!"

and on the other hand: "You will make lots of mullah from the nxdomain
rewriting! it's wonderful!"
  (plus some mumbling about, why would you want to give that money
away to the content providers of the world for free?)

-chris
(I don't believe that it's a great help, nor that customers actually
WANT it, nor that it makes great gobs of money... but I'm willing to
be educated)


From joey at q7.com  Mon Sep 26 14:18:52 2011
From: joey at q7.com (Joe Pruett)
Date: Mon, 26 Sep 2011 12:18:52 -0700
Subject: robtex phantom data
Message-ID: <4E80D01C.1090602@q7.com>

i've tried asking the robtex folks where they get  their as-macro data,
but have not received a response.  i'm trying to figure out where they
are getting the as-spiretech as-macro from.  i know i created that years
ago, but i can't find it in any of the routing registries i might have
used.  i may have forgotten to delete it, but i can't figure out where
it is in order to kill it off.  other data in robtex seems to be
current, so it seems likely that they are getting the data from a db
somewhere, but where?

anyone out there have any good ideas of where to look?  or if robtex has
a known issue with as-macros?


From surfer at mauigateway.com  Mon Sep 26 14:20:00 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 26 Sep 2011 12:20:00 -0700
Subject: vyatta for bgp
Message-ID: <20110926122000.9059A2DB@resin04.mta.everyone.net>

--- rps at maine.edu wrote:
From: Ray Soucy <rps at maine.edu>

We service most of the state's public schools and libraries (about
1000).  Historically the CPE of choice was a small Cisco ISR (1600,
1700, 1800, and 1900 most recently).  As bandwidth levels went up, and
Ethernet-based transport services became available, we started looking
and leveraging FOSS on commodity hardware to lower costs and move
services to the edge.  Right now we have about 100 of the bigger
school districts being services by a Linux-based appliance running
XORP for its routing engine (we would have tried Quagga, but they
don't support multicast routing yet, nor does Vyatta).

It's been a learning experience.  Most of the problems we ran into
have been resolved by tuning the kernel parameters to act more like a
router than a desktop or server.  XORP itself has had a rocky ride
since we started, so the stability of the project has also been a
concern.  Thankfully it is seeing somewhat active development again.
I will note that XORP is very touchy about how it's configured; if you
have well tested configuration templates it's fine, but it's very easy
to get it into a crashing state based on something as little the order
of configuration directives.  For the most part once it's running it's
stable.
--------------------------------------------------------------------



After roll-out and after a time in steady-state operation did you do an analysis of human and hardware/software costs (as well as service to end sites, such as outages that might not have happened with normal routers and LAN switches) to see if you actually saved money?

scott


















From Jonathon.Exley at kordia.co.nz  Mon Sep 26 14:35:40 2011
From: Jonathon.Exley at kordia.co.nz (Jonathon Exley)
Date: Tue, 27 Sep 2011 08:35:40 +1300
Subject: flow generating tool
In-Reply-To: <CAN1XHteVTKSLuZ9RxVna4ZzuXXcisbT5ePeO385-X4Xu5J01PQ@mail.gmail.com>
References: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
 <CAN1XHteVTKSLuZ9RxVna4ZzuXXcisbT5ePeO385-X4Xu5J01PQ@mail.gmail.com>
Message-ID: <3E3FDD2AC2CEF442A9D2B00CF5F6D040011A566805@winexmp02>

The venerable mgen (http://cs.itd.nrl.navy.mil/work/mgen/) is another good option, provided you don't want lots of bandwidth.
It has some flexibility in scripting the flows it creates.

Jonathon 

-----Original Message-----
From: Jason Leschnik [mailto:leschnik at gmail.com] 
Sent: Monday, 26 September 2011 11:21 p.m.
To: Naiden Dimitrov
Cc: nanog at nanog.org
Subject: Re: flow generating tool

Iperf is a good start

http://iperf.sourceforge.net/

Would be interested in any other tools as well.

--
Regards,
Jason Leschnik.

[m] 0432 35 4224
[w@] jason dot leschnik <at> ansto dot gov dot au<jason.leschnik at ansto.gov.au> [U@] jml974 at uow.edu.au
This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).



From ep at eddieparra.net  Mon Sep 26 14:45:08 2011
From: ep at eddieparra.net (Eddie Parra)
Date: Mon, 26 Sep 2011 12:45:08 -0700
Subject: flow generating tool
In-Reply-To: <007101cc7c4c$bf18bd10$3d4a3730$@com>
References: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
 <m2oby7edd9.fsf@sslvpn-97-43.sei.cmu.edu>
 <D200EA14D9516C49B07F3DA72D7E24C13371308ED1@INXS.max.sf>
 <007101cc7c4c$bf18bd10$3d4a3730$@com>
Message-ID: <CAEPmyEhhHEgBLrP5Dc7xGVwfhriPoFYj9kMNVC4AcyXzV55=Rw@mail.gmail.com>

If you are looking to automate any of your testing, +1 Ixia if the box
is using the Agilent OS/Interface (I forget how they are marketing it
now).  In regards to automation, I recently heard the Spirent
interface was quite handy for generating scripts from GUI
interactions, but I have not used it myself.

HTHs,

-Eddie




On Mon, Sep 26, 2011 at 6:03 AM, Erik Bais <ebais at a2b-internet.com> wrote:
> Perhaps not a tool as in software, but clearly something that you might want
> to have a look at :
>
> Ixia and Spirent devices ... Those are mostly used for applications like
> generating different kind of traffic.
>
> Erik Bais
>
>
>
>
>


From Jonathon.Exley at kordia.co.nz  Mon Sep 26 14:45:24 2011
From: Jonathon.Exley at kordia.co.nz (Jonathon Exley)
Date: Tue, 27 Sep 2011 08:45:24 +1300
Subject: flow generating tool
In-Reply-To: <CAN1XHtd7FMZ7T6XOM8Rcr5uTbAYBvNGKPd3-0P9DqYrGpTktQA@mail.gmail.com>
References: <1811440887-1317044547-cardhu_decombobulator_blackberry.rim.net-1692329397-@b16.c10.bise6.blackberry>
 <CAN1XHtd7FMZ7T6XOM8Rcr5uTbAYBvNGKPd3-0P9DqYrGpTktQA@mail.gmail.com>
Message-ID: <3E3FDD2AC2CEF442A9D2B00CF5F6D040011A566806@winexmp02>

The test plan you use depends upon what you want to test - raw pps throughput, route convergence time, qos performance, etc.
We use Exfo (http://www.exfo.com) testers working to a mac-swap loopback for commissioning testing of Ethernet access circuits, looking at the usual loss/throughput/latency/jitter metrics and burst size.
When checking out new equipment in the lab we also use scapy scripts (http://www.secdev.org/projects/scapy/) to look at things like Ethertype and L2CP transparency.

Jonathon 


-----Original Message-----
From: Jason Leschnik [mailto:leschnik at gmail.com] 
Sent: Tuesday, 27 September 2011 3:02 a.m.
To: jiaruchen at gmail.com
Cc: George Jones; nanog at nanog.org; Naiden Dimitrov
Subject: Re: flow generating tool

Does anyone follow a network performance testing methodology, using hardware from companies like ixia/spirent?

I know that basic testing is typically done for validation of configs, but i assume other issues would make themselves apparent when pushed to these higher loads.

thoughts/comments?

Thanks

--
Regards,
Jason Leschnik.

[m] 0432 35 4224
[w@] jason dot leschnik <at> ansto dot gov dot au<jason.leschnik at ansto.gov.au> [U@] jml974 at uow.edu.au
This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).



From rps at maine.edu  Mon Sep 26 15:22:25 2011
From: rps at maine.edu (Ray Soucy)
Date: Mon, 26 Sep 2011 16:22:25 -0400
Subject: vyatta for bgp
In-Reply-To: <20110926122000.9059A2DB@resin04.mta.everyone.net>
References: <20110926122000.9059A2DB@resin04.mta.everyone.net>
Message-ID: <CALFTrnNP1KRdSAcn=f5QUwYKpw74CVP7qm4+=9AqHZ6vG=+tig@mail.gmail.com>

There are a lot of variables that would skew numbers in favor of using
FOSS on commodity hardware in our situation, that wouldn't necessarily
apply to others.  Primarily because these are used to provide services
that are in part funded through the federal E-rate program, and need
to comply with restrictions such as CIPA.

For example, we moved from centralized web filtering using WCCP and
racks of proxy servers, to pushing that service out to the edge.  That
move alone provided more savings than the hardware cost of the
project, so we actually made a net profit from the move in our
situation.

Not sure that would easily apply to anyone.

As for the OpEx and CapEx v. traditional players...

The units are engineered so that they run the entire OS on a RAM disk;
so configuration management is much like what you would find with a
traditional router (only saved configuration survives a reboot, etc --
think of it like a live distribution with controlled persistence).

A physical disk is used for logging, but does not take out the system
upon failure (we've had maybe 3 disk failures that turned out to be
thermal conditions of where equipment was installed -- boiler rooms --
and service was maintained until we had a technician out to swap the
unit).  So operationally, they've been pretty much equivalent of a
Cisco solution and we haven't seen much of an increase in activity
aside from supporting the extra services that weren't previously
available.

The skill set is a little different though.  Having a strong
understanding of the internals of a Linux system along side
traditional networking skills is a must if you go in this direction.

For us, the ability to have more tools to poke at the state of the
system and troubleshoot issues (such as performing packet captures
directly on the device) has been invaluable.  It has allowed us to
track down issues (such as TCP window scaling problems with unnamed
cloud services and their incorrectly configured load balancers)
remotely that would have required on-site capture in the past.

It's also provided us with the flexibility to quickly implement
operational changes as we see a need, such as implementing automatic
nightly backup of configurations to our central servers (using a
simple CRON job), or rolling out scripted changes.

Using an off-the-shelf distribution of Linux and a FOSS routing
package will probably not do the trick for you.  If you take the time
to build a custom distribution that only has what you need; makes use
of known stable package versions, and is engineered to function as a
widely-deployed unit (configuration management, logging, etc) that is
where the savings will come in, because you won't need to see the
significant increase in OpEx that opponents usually point to.  We were
debating on if we should do that in-house or not.  I think if you're
talking about 1000 units then in makes sense to try in-house, on a
smaller scale you really want to find a partner that can engineer the
system for you.

Vyatta looks like it's addressed a lot of the issues it needs to --
though I've never used it in production -- but I would still like to
see more from them in tuning the OS to function better as a router and
less like a server.  Last time I checked they didn't seem to touch
much except setting Linux to allow forwarding.  I'm optimistic though.

Now we just need Intel to step up with some ASICs and open source
drivers that could be plugged into Linux. (On a side note, we make use
of some SFP PCI-X cards for our direct optical connected sites to save
money there too; working well with up to ZX SFPs).

On Mon, Sep 26, 2011 at 3:20 PM, Scott Weeks <surfer at mauigateway.com> wrote:
> --- rps at maine.edu wrote:
> From: Ray Soucy <rps at maine.edu>
>
> We service most of the state's public schools and libraries (about
> 1000). ?Historically the CPE of choice was a small Cisco ISR (1600,
> 1700, 1800, and 1900 most recently). ?As bandwidth levels went up, and
> Ethernet-based transport services became available, we started looking
> and leveraging FOSS on commodity hardware to lower costs and move
> services to the edge. ?Right now we have about 100 of the bigger
> school districts being services by a Linux-based appliance running
> XORP for its routing engine (we would have tried Quagga, but they
> don't support multicast routing yet, nor does Vyatta).
>
> It's been a learning experience. ?Most of the problems we ran into
> have been resolved by tuning the kernel parameters to act more like a
> router than a desktop or server. ?XORP itself has had a rocky ride
> since we started, so the stability of the project has also been a
> concern. ?Thankfully it is seeing somewhat active development again.
> I will note that XORP is very touchy about how it's configured; if you
> have well tested configuration templates it's fine, but it's very easy
> to get it into a crashing state based on something as little the order
> of configuration directives. ?For the most part once it's running it's
> stable.
> --------------------------------------------------------------------
>
>
>
> After roll-out and after a time in steady-state operation did you do an analysis of human and hardware/software costs (as well as service to end sites, such as outages that might not have happened with normal routers and LAN switches) to see if you actually saved money?
>
> scott
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From morrowc.lists at gmail.com  Mon Sep 26 15:32:36 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 26 Sep 2011 16:32:36 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <CAL9jLaZC0eofXFRQqV-ySTrpYUi7uCi74_oGpSnxLibnaxko8A@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de>
 <CAD6AjGRpGbRZoWGXnbp4nKyC5cyVeSg9UdhdSbyyEk3gPMiCBQ@mail.gmail.com>
 <CAL9jLaaGpu7AzoR2eyVsCDg1Ts2f_wcvhBRbEVxaMzxKPMw_sg@mail.gmail.com>
 <10876.1317060709@turing-police.cc.vt.edu>
 <CAL9jLaZC0eofXFRQqV-ySTrpYUi7uCi74_oGpSnxLibnaxko8A@mail.gmail.com>
Message-ID: <CAL9jLaZZqv=Aw9vuGyy2fdB0NFo=tjvwykAuE2HwEGONF9_ggQ@mail.gmail.com>

On Mon, Sep 26, 2011 at 2:17 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Mon, Sep 26, 2011 at 2:11 PM, ?<Valdis.Kletnieks at vt.edu> wrote:
>> On Mon, 26 Sep 2011 10:36:51 EDT, Christopher Morrow said:
>>
>>> I'm curious, is there some belief that the use of hte nxdomain
>>> hijacking/rewriting is actually of use to 'users' ?
>>
>> "of use to users" is, in general, incompatible with "race to the bottom".
>
> my point is that on the one hand the marketeers say: "This is a great
> help to your users who are confused by the missing dns entries! They
> like it! It is a benefit and a comfort to them!"
>
> and on the other hand: "You will make lots of mullah from the nxdomain
> rewriting! it's wonderful!"

s/mullah/moolah/ :( context switch fail.

> ?(plus some mumbling about, why would you want to give that money
> away to the content providers of the world for free?)
>
> -chris
> (I don't believe that it's a great help, nor that customers actually
> WANT it, nor that it makes great gobs of money... but I'm willing to
> be educated)
>


From lorell at hathcock.org  Mon Sep 26 15:41:02 2011
From: lorell at hathcock.org (Lorell Hathcock)
Date: Mon, 26 Sep 2011 15:41:02 -0500
Subject: OSPF Visualizer?
Message-ID: <020601cc7c8c$9afe6250$d0fb26f0$@hathcock.org>

All:

 

I am a small Wireless ISP in need of an OSPF visualizer that does not cost
an arm and a leg.

 

I would like one that can listen to LSA's in each area and build a map of
the network.

 

I anticipate that I could trouble OSPF issues with such a system.

 

Any open source projects?

 

Thanks in advance,

 

Lorell Hathcock


From ep at eddieparra.net  Mon Sep 26 15:47:47 2011
From: ep at eddieparra.net (Eddie Parra)
Date: Mon, 26 Sep 2011 13:47:47 -0700
Subject: OSPF Visualizer?
In-Reply-To: <020601cc7c8c$9afe6250$d0fb26f0$@hathcock.org>
References: <020601cc7c8c$9afe6250$d0fb26f0$@hathcock.org>
Message-ID: <CAEPmyEjMJvqkfh-7gfoANKiTK2VZYP=B1yBPqnafiAQKr6wHzg@mail.gmail.com>

Lorell,

This project has not been updated in some time:

http://ospfviz.sourceforge.net/

If you want a commercial product, check out Packet Design's "Route
Explorer" (aka "REX")

HTHs,

-Eddie




On Mon, Sep 26, 2011 at 1:41 PM, Lorell Hathcock <lorell at hathcock.org> wrote:
> All:
>
>
>
> I am a small Wireless ISP in need of an OSPF visualizer that does not cost
> an arm and a leg.
>
>
>
> I would like one that can listen to LSA's in each area and build a map of
> the network.
>
>
>
> I anticipate that I could trouble OSPF issues with such a system.
>
>
>
> Any open source projects?
>
>
>
> Thanks in advance,
>
>
>
> Lorell Hathcock
>
>


From surfer at mauigateway.com  Mon Sep 26 16:06:40 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 26 Sep 2011 14:06:40 -0700
Subject: vyatta for bgp
Message-ID: <20110926140640.9059B0F6@resin04.mta.everyone.net>

On Mon, Sep 26, 2011 at 3:20 PM, Scott Weeks <surfer at mauigateway.com> wrote:
> --- rps at maine.edu wrote:
> From: Ray Soucy <rps at maine.edu>
>
> We service most of the state's public schools and 
> libraries (about 1000).  Historically the CPE of 
> choice was a small Cisco ISR (1600,1700, 1800, and 
> 1900 most recently).  As bandwidth levels went up, 
> and Ethernet-based transport services became 
> available, we started looking and leveraging FOSS 
> on commodity hardware to lower costs and move


>> After roll-out and after a time in steady-state 
>> operation did you do an analysis of human and 
>> hardware/software costs (as well as service to 
>> end sites, such as outages that might not have 
>> happened with normal routers and LAN switches) 
>> to see if you actually saved money?


: For us, the ability to have more tools to poke 
: at the state of the system and troubleshoot 
: issues (such as performing packet captures
: directly on the device) has been invaluable.  
: It has allowed us to track down issues (such 
: as TCP window scaling problems with unnamed
: cloud services and their incorrectly configured 
: load balancers) remotely that would have 
: required on-site capture in the past.



This alone would put me in heaven, rather than the mirror to an open port and sniff it procedure...  :-)

Thanks for the response,
scott



From Skeeve at eintellego.net  Mon Sep 26 17:45:55 2011
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Mon, 26 Sep 2011 22:45:55 +0000
Subject: Internet Governance Fight Looms
Message-ID: <CAA73DA4.48347%skeeve@eintellego.net>

Hey all,

A pretty important meeting is happening at the IGF (Internet Governance Forum) at the moment with a fight about how the internet itself is managed.

The article below gives a good overview of the situation.

http://news.dot-nxt.com/2011/09/22/internet-governance-fight-looms

The worrying thing is the size and power of some of the countries who want to do things differently than our present multi-stakeholder approach.

As the writer quotes "Nothing less than the fate of the future evolution of the Internet is at stake".  It sounds dramatic, but if certain powers get their way, it could be close to the truth.

There are numerous people from our community going to be attending the event in Africa and no doubt will report back to us with what is happening.

?Skeeve

--

Skeeve Stevens, CEO - eintellego Pty Ltd

skeeve at eintellego.net<mailto:skeeve at eintellego.net> ; www.eintellego.net

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellego

twitter.com/networkceoau ; www.linkedin.com/in/skeeve

PO Box 7726, Baulkham Hills, NSW 1755 Australia


--

eintellego - The Experts Who The Experts Call
Juniper - HP Networking - Cisco - Brocade

From ethan at cs.washington.edu  Mon Sep 26 18:47:29 2011
From: ethan at cs.washington.edu (Ethan Katz-Bassett)
Date: Mon, 26 Sep 2011 16:47:29 -0700
Subject: Announcement of University of Washington routing study
In-Reply-To: <77E718FF-E901-49E9-AB72-7E048EBB03FF@ianai.net>
References: <CAGvYMCqrw+LciM+eEAEcHqrigGnJWxLvF5OdUkgWU+_YD+Lw-A@mail.gmail.com>
 <77E718FF-E901-49E9-AB72-7E048EBB03FF@ianai.net>
Message-ID: <CAGvYMCofBbeT1hNmHtGMiio0z8tJ-YO9bo+Oxf6Wg7v6RaP_Pw@mail.gmail.com>

Just a quick note now that our experiments have been underway for a month.
 Our study has been running smoothly so far, and we expect to eventually
have an interesting report on it.

If possible, can someone from Hurricane Electric please contact us off list?
 We have a quick question about our study.

Thanks!
Ethan and Valas (at cs.washington.edu and gatech.edu, respectively)

On Thu, Aug 18, 2011 at 5:38 PM, Patrick W. Gilmore <patrick at ianai.net>wrote:

> On behalf of the community, if I may be so bold (and I'm sure others will
> speak up if they disagree), thank you for the notice of this experiment.
>
> Also, thank you for doing the research.
>
> --
> TTFN,
> patrick
>
> On Aug 18, 2011, at 19:32, Ethan Katz-Bassett <ethan at cs.washington.edu>
> wrote:
>
> > Hi NANOG,
> >
> >
> > From August 24 to October 4, the University of Washington and Georgia
> Tech
> > will conduct an Internet routing study using AS-PATH poisoning.  The
> study
> > will *only* affect the Georgia Tech experimental prefix
> > 184.164.224.0/19(and its sub-prefixes).  The prefix serves *no active
> > users/services* so the
> > study should not affect any production prefixes or users.  We plan to
> insert
> > AS numbers into our announcements to route around some networks.  We will
> > always start AS-PATHs with our own ASN 47065.  We will limit ourselves to
> at
> > most 10 announcement changes per hour (and generally will change the
> > announcement for a given sub-prefix at most every 90 minutes).
> >
> >
> > This experiment is almost identical to one that Georgia Tech conducted in
> > June and July without problems or complaints
> > (http://mailman.nanog.org/pipermail/nanog/2011-June/037527.html), so we
> do
> > not anticipate any issues.  Others have done similar studies in the past
> > (e.g., Randy Bush et al.:
> > http://www.psg.com/~olaf/measurements/as3130/visibility.pdf<
> http://www.google.com/url?sa=D&q=http://www.psg.com/~olaf/measurements/as3130/visibility.pdf
> >).
> > If, for any reason, you want us not to include your ASN in announcements
> for
> > our prefix, please opt-out at any time before August 24 at:
> > http://www.surveymonkey.com/s/9P2TD7T .  A few ASes opted out of the
> > previous Georgia Tech study, and we will continue to honor those
> opt-outs.
> >
> >
> > Please feel free to contact me directly with any questions.
> >
> >
> > Cheers,
> >
> > Ethan Katz-Bassett
> >
> > http://www.cs.washington.edu/homes/ethan/
> >
> > University of Washington
> >
>

From dmm at 1-4-5.net  Mon Sep 26 20:43:33 2011
From: dmm at 1-4-5.net (David Meyer)
Date: Mon, 26 Sep 2011 18:43:33 -0700
Subject: [NANOG-announce] PC Nominations Reminder to NANOG Announce
In-Reply-To: <CABhExiwg1T=4DLkzMzNM6DKM8xX=pA5Wm_yzZXRJeDFKZjttqw@mail.gmail.com>
References: <CABhExiwg1T=4DLkzMzNM6DKM8xX=pA5Wm_yzZXRJeDFKZjttqw@mail.gmail.com>
Message-ID: <CAHiKxWjr6zXpuU0xnOF0KLhuD8X9grb3=xNaBZmGDYjMG+bM6Q@mail.gmail.com>

Hey Folks,

Just a reminder that nominations for the Program Committee are open. The PC
is a group of sixteen individuals from the NANOG community who together are
responsible for the NANOG program.  The folks we choose will shape the
future of NANOG.

With that in mind, I encourage you to self-nominate or nominate a member of
the community who you feel has energy and ideas about how the NANOG meetings
can improve and evolve. And for those who haven't served on the PC, it is a
great to work with our community and it is a very rewarding experience.
NANOG has a great tradition; please consider contributing to it as part of
the Program Committee.

So if you want to self-nominate or if you want to nominate someone else,
send your nomination to nominations at nanog.org.  If you are nominating
another person, please provide that person's name and email address.  If you
are nominating yourself, please provide a Statement of Intent and a
Biography, each with a suggested limit of 150 words.  For samples, please
see the 2010 candidate lists, <
http://www.nanog.org/governance/elections/2010elections/>.

As always, if you have a questions, please email nominations at nanog.org.

Thnx,

Dave

(for the NANOG PC/community)
-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

From mmzinyi at yahoo.com  Tue Sep 27 02:15:31 2011
From: mmzinyi at yahoo.com (jacob miller)
Date: Tue, 27 Sep 2011 00:15:31 -0700 (PDT)
Subject: SDH Fiber Problem
In-Reply-To: <82933B17-9992-47FB-8472-3F5112F118E2@ukbroadband.com>
References: <1316411356.5123.YahooMailNeo@web39505.mail.mud.yahoo.com>
 <m2aaa19g2y.wl%randy@psg.com>,
 <1316416954.47830.YahooMailNeo@web39506.mail.mud.yahoo.com>
 <ABAE7F69-A596-49F5-93EA-FF528F2EB38A@ukbroadband.com>,
 <1316420052.39155.YahooMailNeo@web39501.mail.mud.yahoo.com>
 <82933B17-9992-47FB-8472-3F5112F118E2@ukbroadband.com>
Message-ID: <1317107731.7203.YahooMailNeo@web39501.mail.mud.yahoo.com>



Managed to solve this problem.

It was MTU related as my routers had an MTU size set at 1600.

Removed this setting from both ends and managed to get traffic flowing.

Had earlier terminated a laptop at one end of the link just to test and found I was able to push more than 20MB.

Thanks for your assistance on this.

Regards,
Jacob Miller


----- Original Message -----
From: Leigh Porter <leigh.porter at ukbroadband.com>
To: jacob miller <mmzinyi at yahoo.com>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Sent: Monday, September 19, 2011 11:17 AM
Subject: Re: SDH Fiber Problem

It does sound like an MTU issue. Symptoms are typical. Did you try pings end to end with DF bit set and full size datagrams?



-- 
Leigh Porter


On 19 Sep 2011, at 09:15, "jacob miller" <mmzinyi at yahoo.com> wrote:

> By meanigful traffic I mean traffic like Http traffic
> 
> Am able to ssh no problem.
> 
> Most of the clients on the link are using it for browsing.
> However we find that even though they are able to resolve and ping different sites.
> When it comes to opening of the page we have the page reading as opening opening .. but the page never gets opened.
> 
> Regards,
> Jacob Miller
> 
> 
> 
> ----- Original Message -----
> From: Leigh Porter <leigh.porter at ukbroadband.com>
> To: jacob miller <mmzinyi at yahoo.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Sent: Monday, September 19, 2011 11:10 AM
> Subject: Re: SDH Fiber Problem
> 
> What exactly do you mean by meaningful traffic? ICMP from port to port works, can you pass TCP? SSH between routers? Establish a TCP session over it?
> 
> Are you using Juniper SRXs ? :-)
> 
> -- 
> Leigh Porter
> 
> 
> On 19 Sep 2011, at 08:24, "jacob miller" <mmzinyi at yahoo.com> wrote:
> 
>> I have tried the pings and am able to ping through with a size of 1600 with the df-bit set
>> 
>> without the df-bit am able to get up to 9000.
>> 
>> The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998.
>> The switch is a 2960 Cisco switch.
>> 
>> I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic.
>> 
>> Regards,
>> jacob Miller
>> 
>> 
>> 
>> ----- Original Message -----
>> From: Randy Bush <randy at psg.com>
>> To: jacob miller <mmzinyi at yahoo.com>
>> Cc: "nanog at nanog.org" <nanog at nanog.org>
>> Sent: Monday, September 19, 2011 9:55 AM
>> Subject: Re: SDH Fiber Problem
>> 
>>> I can ping on point to point
>>> I have BGP up and running
>>> When I try to pass traffic over the link my clients are unable to pass
>>> any meanigful traffic asn browsing is impossible.
>> 
>> mtu?? try various size pings.
>> 
>> filters?
>> 
>> randy
>> 
>> 
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From lists at quux.de  Tue Sep 27 03:14:11 2011
From: lists at quux.de (Jens Link)
Date: Tue, 27 Sep 2011 10:14:11 +0200
Subject: wet-behind-the-ears whippersnapper seeking advice on building a
 nationwide network
In-Reply-To: <9606.1316492099@turing-police.cc.vt.edu> (Valdis Kletnieks's
 message of "Tue, 20 Sep 2011 00:14:59 -0400")
References: <cead2751-cd2f-4b41-a418-930ea9d52a5a@zimbra.network1.net>
 <4E758877.5070002@knownelement.com>
 <005901cc764f$ffe01030$ffa03090$@iname.com>
 <D181DDABABE57E4DB72FEE00331478643C1537@EALPO1.ukbroadband.com>
 <005a01cc766a$f3ce3450$db6a9cf0$@iname.com>
 <alpine.OSX.2.00.1109181614070.152@antonio-querubins-imac-g5-9.local>
 <005c01cc7675$a9f94a80$fdebdf80$@iname.com>
 <Pine.LNX.4.61.1109192101350.25015@soloth.lewis.org>
 <4E7802F3.2020806@matthew.at> <m21uvbyjm3.wl%randy@psg.com>
 <9606.1316492099@turing-police.cc.vt.edu>
Message-ID: <87r5321jxo.fsf@pc8.berlin.quux.de>

Valdis.Kletnieks at vt.edu writes:

> Does anybody actually *have* a functional 7 track drive? 

Maybe the people running <http://www.cray-cyber.org> have one.

(If you ever come to Munich, try to visit this museum.) 

Jens
-- 
-------------------------------------------------------------------------
| Foelderichstr. 40   | 13595 Berlin, Germany    | +49-151-18721264     |
| http://blog.quux.de | jabber: jenslink at guug.de | -------------------  | 
-------------------------------------------------------------------------


From william.allen.simpson at gmail.com  Tue Sep 27 03:57:34 2011
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Tue, 27 Sep 2011 04:57:34 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <82sjnjg0zi.fsf@mid.bfk.de>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de>
Message-ID: <4E818FFE.70908@gmail.com>

On 9/26/11 4:29 AM, Florian Weimer wrote:
> Is this with strict NXDOMAIN rewriting, or were existing names
> redirected as well?  (AFAIK, most platforms do the latter, hijacking
> bfk.de, for example.)
>
Has anybody tried bringing a criminal complaint for interference with
computer (network) data?

Certainly, hijacking google.com NS records to JOMAX.NET would be a
criminal interference.  After all, that's all DNSsec signed now,
isn't it?

Arguably, substituting a false reply for NXDOMAIN would be, too.

It's time to find a champion to lead the charge.  Maybe Google?




From tias at netnod.se  Tue Sep 27 04:03:13 2011
From: tias at netnod.se (Mathias Wolkert)
Date: Tue, 27 Sep 2011 11:03:13 +0200
Subject: flow generating tool
In-Reply-To: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
References: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
Message-ID: <4E819151.3010209@netnod.se>

Linux pktgen.
http://landley.net/kdocs/ols/2005/ols2005v2-pages-19-32.pdf

/Tias


On 9/26/11 12:07 , Naiden Dimitrov wrote:
> Hello,
>
>
>
> I need a tool that generates traffic flows from different source IP addresses for network tests.
>
>
>
> Regards,
>
>
>
> Naiden Dimitrov
> Mobile: +359 885 906 155
> naiden.dimitrov at maxtelecom.bg<mailto:naiden.dimitrov at maxtelecom.bg>
> www.maxtelecom.bg<http://www.maxtelecom.bg>
>
>
>
>
>



From mysidia at gmail.com  Tue Sep 27 06:50:28 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 27 Sep 2011 06:50:28 -0500
Subject: Nxdomain redirect revenue
In-Reply-To: <4E818FFE.70908@gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
Message-ID: <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>

On Tue, Sep 27, 2011 at 3:57 AM, William Allen Simpson
<william.allen.simpson at gmail.com> wrote:
[snip]
> Certainly, hijacking google.com NS records to JOMAX.NET would be a
> criminal interference. ?After all, that's all DNSsec signed now,
> isn't it?

I would rather see DNSSEC  and TLS/HTTPS get implemented end to end.
The last thing we need is a court to step in and say "It's not legal
for an ISP to
blacklist, block, or redirect traffic,  to any hostname or IP address."

Most likely the ISPs'  lawyers were smart enough to include a clause
in the ToS/AUP allowing
the ISP to intercept, blackhole, or redirect access to any hostname or
IP address.

The name for an ISP intercepting traffic from its own users is  not
"interference"  or  "DoS",
because they're breaking the operation of (er) only their own network.


The solution is to spread their name as widely as possible, so
consumers can make an informed
choice if they wish to avoid service providers that engage in abusive practices,
and bring it attention to regulators if the service providers are
acting as an abusive monopoly in regards to their interception
practices.

--
-JH


From morrowc.lists at gmail.com  Tue Sep 27 08:27:00 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 27 Sep 2011 09:27:00 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
Message-ID: <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>

On Tue, Sep 27, 2011 at 7:50 AM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Tue, Sep 27, 2011 at 3:57 AM, William Allen Simpson
> <william.allen.simpson at gmail.com> wrote:
> [snip]
>> Certainly, hijacking google.com NS records to JOMAX.NET would be a
>> criminal interference. ?After all, that's all DNSsec signed now,
>> isn't it?
>
> I would rather see DNSSEC ?and TLS/HTTPS get implemented end to end.

how does tls/https help here? if you get sent to the 'wrong host'
whether or not it does https/tls is irrelevant, no? (save the case of
chrome and domain pinning)

> The solution is to spread their name as widely as possible, so
> consumers can make an informed
> choice if they wish to avoid service providers that engage in abusive practices,
> and bring it attention to regulators if the service providers are
> acting as an abusive monopoly in regards to their interception
> practices.

sadly, not everyone has a choice in providers  :(


From lee at asgard.org  Tue Sep 27 08:35:42 2011
From: lee at asgard.org (Lee Howard)
Date: Tue, 27 Sep 2011 09:35:42 -0400
Subject: Volunteers needed for TWC IPv6 trial
Message-ID: <00da01cc7d1a$5a5fc7f0$0f1f57d0$@org>

Time Warner Cable is expanding our residential IPv6 trials in several
markets, and we need more people.  If you're a Time Warner Cable High Speed
Internet subscriber, and are interested in participating in our IPv6 trials,
please let us know!   We have a short form at
http://www.timewarnercable.com/Corporate/support/IPv6_volunteerform.html
that will help us find the right mix of people, equipment, and locations, to
get the most out of our trials.

Thanks in advance for participating!

Lee Howard
Time Warner Cable



From cabenth at gmail.com  Tue Sep 27 09:05:55 2011
From: cabenth at gmail.com (eric clark)
Date: Tue, 27 Sep 2011 07:05:55 -0700
Subject: Environmental monitoring options
Message-ID: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>

I'd like to ask the list what products people are using to monitor their
environments. By this I'm referring to datacenters, and other equipment.
Temperature, humidity, airflow, cameras, dry contacts, door sensors, leak
detection, all that sort of thing.

I've used Netbotz in the past. Looking to see what else is out there that
people like.

Thanks

E

From chaim.rieger at gmail.com  Tue Sep 27 09:19:17 2011
From: chaim.rieger at gmail.com (Chaim Rieger)
Date: Tue, 27 Sep 2011 07:19:17 -0700
Subject: Environmental monitoring options
In-Reply-To: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
References: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
Message-ID: <CAJoowQjkKO7jSH63OVgz3_JaHtvfnqHAa9hxPk0gHapWqSAJrQ@mail.gmail.com>

zabbix

From Valdis.Kletnieks at vt.edu  Tue Sep 27 09:19:35 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 27 Sep 2011 10:19:35 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: Your message of "Tue, 27 Sep 2011 09:27:00 EDT."
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
Message-ID: <33830.1317133175@turing-police.cc.vt.edu>

On Tue, 27 Sep 2011 09:27:00 EDT, Christopher Morrow said:
> On Tue, Sep 27, 2011 at 7:50 AM, Jimmy Hess <mysidia at gmail.com> wrote:

> > I would rather see DNSSEC and TLS/HTTPS get implemented end to end.
>
> how does tls/https help here? if you get sent to the 'wrong host'
> whether or not it does https/tls is irrelevant, no? (save the case of
> chrome and domain pinning)

Well, actually, Chrome-like domain pinning and/or using DNSSEC to verify the
provenance of an SSL cert is the whiole reason Jimmy probably wants DNSSEC and
TLS...Unless you do that sort of stuff, there's no way to *tell* if you ended
up at the wrong host...

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

From william.allen.simpson at gmail.com  Tue Sep 27 09:20:25 2011
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Tue, 27 Sep 2011 10:20:25 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>	<82sjnjg0zi.fsf@mid.bfk.de>	<4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
Message-ID: <4E81DBA9.7050303@gmail.com>

On 9/27/11 7:50 AM, Jimmy Hess wrote:
> On Tue, Sep 27, 2011 at 3:57 AM, William Allen Simpson
> <william.allen.simpson at gmail.com>  wrote:
> [snip]
>> Certainly, hijacking google.com NS records to JOMAX.NET would be a
>> criminal interference.  After all, that's all DNSsec signed now,
>> isn't it?
>
> I would rather see DNSSEC  and TLS/HTTPS get implemented end to end.

They are.

> The last thing we need is a court to step in and say "It's not legal
> for an ISP to
> blacklist, block, or redirect traffic,  to any hostname or IP address."
>
Don't distort my words.  It amuses me when so-called conservative
cyber-libertarians hate the idea of courts stepping in to enforce
laws, except the laws governing their own contracts enforcing
payments regardless of the quality of their goods.

The cable and satellite industry forced through digital protection
acts -- to protect their revenue streams.  Now, it's time to use
those acts against them.

It's not legal for an ISP to modify computer data.  Especially
digitally signed data.  That's a criminal offense.

It's not legal for a vendor to sell or give away equipment that aids
interception and modification of data.  That's a criminal offense.


> Most likely the ISPs'  lawyers were smart enough to include a clause
> in the ToS/AUP allowing
> the ISP to intercept, blackhole, or redirect access to any hostname or
> IP address.
>
It's not legal to insert a clause allowing criminal conduct.  There's
no safe haven for criminal conduct.


> The name for an ISP intercepting traffic from its own users is  not
> "interference"  or  "DoS",
> because they're breaking the operation of (er) only their own network.
>
No, they're breaking the operation of my network and my computers.  My
network connects to their network.


> The solution is to spread their name as widely as possible, so
> consumers can make an informed
> choice if they wish to avoid service providers that engage in abusive practices,
> and bring it attention to regulators if the service providers are
> acting as an abusive monopoly in regards to their interception
> practices.
>
There are no choices.  They *are* abusive monopolies.

Why are "regulators" better than courts?

After all, the regulators will also involve courts.


From jantman at oit.rutgers.edu  Tue Sep 27 09:24:03 2011
From: jantman at oit.rutgers.edu (Jason Antman)
Date: Tue, 27 Sep 2011 10:24:03 -0400
Subject: Environmental monitoring options
In-Reply-To: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
References: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
Message-ID: <4E81DC83.6060500@oit.rutgers.edu>

eric clark wrote:
> I'd like to ask the list what products people are using to monitor their
> environments. By this I'm referring to datacenters, and other equipment.
> Temperature, humidity, airflow, cameras, dry contacts, door sensors, leak
> detection, all that sort of thing.
>
> I've used Netbotz in the past. Looking to see what else is out there that
> people like.
>
> Thanks
>
> E
>   
Coming from a University environment... data center has all sorts of
different solutions, including some NetBotz. Leak detection and physical
plant/HVAC stuff is mostly "legacy" (bell and flashing lights) in the
Ops room. Latest project has been deploying Websensors
(http://www.eesensors.com/WebsensorEM01B.html) distributed around the
room. We also have a few prototype boards, sort of like a netbotz
without the camera, that were done as a senior project for an EE student
a few years back... actually quite stable and useful.

In smaller TCs/ERs, i.e. anything one room with a few racks, we
generally either have a netbot plus whatever addon for the UPS or, if we
have a services machine deployed there (Linux box for dhcp/dns/remote
access) we use a Dalls One-Wire adapter with some sensors, accessed
through OWFS on that box and monitored in Nagios.

-J. Antman

-- 

Jason Antman
System Administrator
Rutgers University
OIT Central Systems & Services / NetOps

Office: 732-445-6363
Cell: 732-983-7256
jantman at oit.rutgers.edu



From tony at swalter.com  Tue Sep 27 09:36:51 2011
From: tony at swalter.com (Tony Patti)
Date: Tue, 27 Sep 2011 10:36:51 -0400
Subject: Environmental monitoring options
In-Reply-To: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
References: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
Message-ID: <021101cc7d22$e56b3430$b0419c90$@com>

Hi Eric,

Also take a look at IT Watch Dogs at http://www.itwatchdogs.com/ 

Tony Patti
CIO
S. Walter Packaging Corp.
tony at swalter.com
phone: 215-676-8888
fax: 215-698-7119
http://www.swalter.com



-----Original Message-----
From: eric clark [mailto:cabenth at gmail.com] 
Sent: Tuesday, September 27, 2011 10:06 AM
To: NANOG list
Subject: Environmental monitoring options

I'd like to ask the list what products people are using to monitor their
environments. By this I'm referring to datacenters, and other equipment.
Temperature, humidity, airflow, cameras, dry contacts, door sensors, leak
detection, all that sort of thing.

I've used Netbotz in the past. Looking to see what else is out there that
people like.

Thanks

E



From alex at corp.nac.net  Tue Sep 27 09:46:19 2011
From: alex at corp.nac.net (Alex Rubenstein)
Date: Tue, 27 Sep 2011 10:46:19 -0400
Subject: Environmental monitoring options
In-Reply-To: <021101cc7d22$e56b3430$b0419c90$@com>
References: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
 <021101cc7d22$e56b3430$b0419c90$@com>
Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DE4B7@EXCHMBX.hq.nac.net>

> I'd like to ask the list what products people are using to monitor
> their environments.


www.controlbyweb.com has some nifty stuff that we use extensively.





From Valdis.Kletnieks at vt.edu  Tue Sep 27 09:48:26 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 27 Sep 2011 10:48:26 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: Your message of "Tue, 27 Sep 2011 10:20:25 EDT."
 <4E81DBA9.7050303@gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <4E81DBA9.7050303@gmail.com>
Message-ID: <34752.1317134906@turing-police.cc.vt.edu>

On Tue, 27 Sep 2011 10:20:25 EDT, William Allen Simpson said:

> It's not legal for an ISP to modify computer data.  Especially
> digitally signed data.  That's a criminal offense.

Citation?

Hint - a *big* chunk of ISPs have NAT deployed, and that's messing with packet
headers.  Much as many of us would like to see NAT go away, I don't think we
want an environment where deploying NAT gets us a new roommate and best friend
named Bubba.  Oh, and if you're not modifying the TTL field, you're Doing It
Wrong.

> It's not legal for a vendor to sell or give away equipment that aids
> interception and modification of data.  That's a criminal offense.

Again, citiation?

Meanwhile, CALEA *requires* you to have a network that aids in at least
the interception of data.  What's a poor ISP to do?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110927/58e02251/attachment.bin>

From morrowc.lists at gmail.com  Tue Sep 27 09:49:56 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 27 Sep 2011 10:49:56 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <33830.1317133175@turing-police.cc.vt.edu>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <33830.1317133175@turing-police.cc.vt.edu>
Message-ID: <CAL9jLaZB+96Y=EWHXfnUiqdudZnT_5mmhjn8Aut0atkBx4ySTQ@mail.gmail.com>

On Tue, Sep 27, 2011 at 10:19 AM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Tue, 27 Sep 2011 09:27:00 EDT, Christopher Morrow said:
>> On Tue, Sep 27, 2011 at 7:50 AM, Jimmy Hess <mysidia at gmail.com> wrote:
>
>> > I would rather see DNSSEC and TLS/HTTPS get implemented end to end.
>>
>> how does tls/https help here? if you get sent to the 'wrong host'
>> whether or not it does https/tls is irrelevant, no? (save the case of
>> chrome and domain pinning)
>
> Well, actually, Chrome-like domain pinning and/or using DNSSEC to verify the
> provenance of an SSL cert is the whiole reason Jimmy probably wants DNSSEC and
> TLS...Unless you do that sort of stuff, there's no way to *tell* if you ended
> up at the wrong host...

to paraphrase mo: "this will not scale" (you can't possibly pin
everyone that matters (to all users) inside the binary)  It's a cute
intermediate trick until the CA problem is resolved/executed and
DNSSEC arrives in full (on the service AND client side).

-chris


From bgold at simons-rock.edu  Tue Sep 27 09:53:50 2011
From: bgold at simons-rock.edu (bgold at simons-rock.edu)
Date: Tue, 27 Sep 2011 10:53:50 -0400 (EDT)
Subject: Environmental monitoring options
In-Reply-To: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
References: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
Message-ID: <57494.10.30.2.44.1317135230.squirrel@lock.simons-rock.edu>

> I'd like to ask the list what products people are using to monitor their
> environments. By this I'm referring to datacenters, and other equipment.
> Temperature, humidity, airflow, cameras, dry contacts, door sensors, leak
> detection, all that sort of thing.
>
> I've used Netbotz in the past. Looking to see what else is out there that
> people like.
>
> Thanks
>
> E
>

We've been using RoomAlert units (http://environmentmonitor.com/)
monitored by nagios via snmp. Multiple temp/humidity probes, power, flood,
etc. All graphed nicely by pnp4nagios.


From david at davidswafford.com  Tue Sep 27 10:04:44 2011
From: david at davidswafford.com (David)
Date: Tue, 27 Sep 2011 11:04:44 -0400
Subject: Environmental monitoring options
In-Reply-To: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
References: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
Message-ID: <F5EA1975-2714-49C7-A3AB-26F31C91732B@davidswafford.com>

We're using Asentria units.  They do temp/humidity monitored via snmp.

David 

Sent from my iPhone

On Sep 27, 2011, at 10:05 AM, eric clark <cabenth at gmail.com> wrote:

> I'd like to ask the list what products people are using to monitor their
> environments. By this I'm referring to datacenters, and other equipment.
> Temperature, humidity, airflow, cameras, dry contacts, door sensors, leak
> detection, all that sort of thing.
> 
> I've used Netbotz in the past. Looking to see what else is out there that
> people like.
> 
> Thanks
> 
> E


From rubensk at gmail.com  Tue Sep 27 10:41:56 2011
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 27 Sep 2011 12:41:56 -0300
Subject: Nxdomain redirect revenue
In-Reply-To: <34752.1317134906@turing-police.cc.vt.edu>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <4E81DBA9.7050303@gmail.com>
 <34752.1317134906@turing-police.cc.vt.edu>
Message-ID: <CAGFn2k3+ioRHgxH3V1yKX0sqyh3FX2XvbAsqiuePPg_rKc97gQ@mail.gmail.com>

On Tue, Sep 27, 2011 at 11:48 AM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Tue, 27 Sep 2011 10:20:25 EDT, William Allen Simpson said:
>
>> It's not legal for an ISP to modify computer data. ?Especially
>> digitally signed data. ?That's a criminal offense.
>
> Citation?

Could tampering with DNSSEC and/or TLS fall into DMCA grounds ?



Rubens


From heather.schiller at verizon.com  Tue Sep 27 11:34:19 2011
From: heather.schiller at verizon.com (Schiller, Heather A)
Date: Tue, 27 Sep 2011 12:34:19 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <4E818FFE.70908@gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
Message-ID: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F674890D@FHDP1LUMXC7V43.us.one.verizon.com>



Paxfire gets sued:
http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html
http://www.courthousenews.com/2011/08/08/38796.htm
http://www.pcmag.com/article2/0,2817,2390529,00.asp

Paxfire files counter suit:
http://www.techdirt.com/articles/20110809/17305215460/paxfire-responds-says-it-doesnt-hijack-searches-will-seek-sanctions-against-lawyers.shtml
http://www.techdirt.com/articles/20110906/03371515808/paxfire-sues-lawyers-individual-who-filed-class-action-lawsuit-over-its-search-redirects.shtml
http://www.prweb.com/releases/2011/9/prweb8765163.htm
  

-----Original Message-----
From: William Allen Simpson [mailto:william.allen.simpson at gmail.com] 
Sent: Tuesday, September 27, 2011 4:58 AM
To: nanog at nanog.org
Subject: Re: Nxdomain redirect revenue

On 9/26/11 4:29 AM, Florian Weimer wrote:
> Is this with strict NXDOMAIN rewriting, or were existing names 
> redirected as well?  (AFAIK, most platforms do the latter, hijacking 
> bfk.de, for example.)
>
Has anybody tried bringing a criminal complaint for interference with computer (network) data?

Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference.  After all, that's all DNSsec signed now, isn't it?

Arguably, substituting a false reply for NXDOMAIN would be, too.

It's time to find a champion to lead the charge.  Maybe Google?





From hvgeekwtrvl at gmail.com  Tue Sep 27 11:40:13 2011
From: hvgeekwtrvl at gmail.com (james machado)
Date: Tue, 27 Sep 2011 09:40:13 -0700
Subject: flow generating tool
In-Reply-To: <4E819151.3010209@netnod.se>
References: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
 <4E819151.3010209@netnod.se>
Message-ID: <CADVasu6cXuTwxuV255G1PjJoZXzNiPKX89yAQbNZvb5yCNtYdA@mail.gmail.com>

you might also try D-ITG  http://www.grid.unina.it/software/ITG/index.php

james


From dmiller at tiggee.com  Tue Sep 27 11:41:17 2011
From: dmiller at tiggee.com (David Miller)
Date: Tue, 27 Sep 2011 12:41:17 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <CAGFn2k3+ioRHgxH3V1yKX0sqyh3FX2XvbAsqiuePPg_rKc97gQ@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <4E81DBA9.7050303@gmail.com> <34752.1317134906@turing-police.cc.vt.edu>
 <CAGFn2k3+ioRHgxH3V1yKX0sqyh3FX2XvbAsqiuePPg_rKc97gQ@mail.gmail.com>
Message-ID: <4E81FCAD.6090109@tiggee.com>

On 9/27/2011 11:41 AM, Rubens Kuhl wrote:
> On Tue, Sep 27, 2011 at 11:48 AM,<Valdis.Kletnieks at vt.edu>  wrote:
>> On Tue, 27 Sep 2011 10:20:25 EDT, William Allen Simpson said:
>>
>>> It's not legal for an ISP to modify computer data.  Especially
>>> digitally signed data.  That's a criminal offense.
>> Citation?
> Could tampering with DNSSEC and/or TLS fall into DMCA grounds ?

Doubtful.  DMCA (the C is Copyright) protects copyright owners.  I have 
never seen anyone claim copyright over their DNS records.

Interesting thought, but copyright law is a tangled mess that I would 
guess is probably the wrong tactic if someone were planning to legally 
oppose/attack service providers using NXDOMAIN redirection.  Also, only 
the 'owner' of a copyright can bring suit.

-DMM



From william.allen.simpson at gmail.com  Tue Sep 27 12:11:32 2011
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Tue, 27 Sep 2011 13:11:32 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F674890D@FHDP1LUMXC7V43.us.one.verizon.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <B9EBD2474913AD4A995B8C7B8BEF8C0E14F674890D@FHDP1LUMXC7V43.us.one.verizon.com>
Message-ID: <4E8203C4.5030406@gmail.com>

>> On 9/26/11 4:29 AM, Florian Weimer wrote:
>> Is this with strict NXDOMAIN rewriting, or were existing names
>> redirected as well?  (AFAIK, most platforms do the latter, hijacking
>> bfk.de, for example.)
>>

I responded:
> Has anybody tried bringing a criminal complaint for interference with computer (network) data?
>
> Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference.  After all, that's all DNSsec signed now, isn't it?
>
> Arguably, substituting a false reply for NXDOMAIN would be, too.
>
> It's time to find a champion to lead the charge.  Maybe Google?
>

On 9/27/11 12:34 PM, Schiller, Heather A top posted:
> Paxfire gets sued:
> http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html
> http://www.courthousenews.com/2011/08/08/38796.htm
> http://www.pcmag.com/article2/0,2817,2390529,00.asp
>
> Paxfire files counter suit:
> http://www.techdirt.com/articles/20110809/17305215460/paxfire-responds-says-it-doesnt-hijack-searches-will-seek-sanctions-against-lawyers.shtml
> http://www.techdirt.com/articles/20110906/03371515808/paxfire-sues-lawyers-individual-who-filed-class-action-lawsuit-over-its-search-redirects.shtml
> http://www.prweb.com/releases/2011/9/prweb8765163.htm
>
Thanks, Heather, I didn't know/remember about the civil suit.  Good start.

But I'm talking about criminal.  They're different.


From william.allen.simpson at gmail.com  Tue Sep 27 12:45:24 2011
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Tue, 27 Sep 2011 13:45:24 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: <CAGFn2k3+ioRHgxH3V1yKX0sqyh3FX2XvbAsqiuePPg_rKc97gQ@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <4E81DBA9.7050303@gmail.com> <34752.1317134906@turing-police.cc.vt.edu>
 <CAGFn2k3+ioRHgxH3V1yKX0sqyh3FX2XvbAsqiuePPg_rKc97gQ@mail.gmail.com>
Message-ID: <4E820BB4.9060904@gmail.com>

On 9/27/11 11:41 AM, Rubens Kuhl wrote:
> On Tue, Sep 27, 2011 at 11:48 AM,<Valdis.Kletnieks at vt.edu>  wrote:
>> On Tue, 27 Sep 2011 10:20:25 EDT, William Allen Simpson said:
>>
>>> It's not legal for an ISP to modify computer data.  Especially
>>> digitally signed data.  That's a criminal offense.
>>
>> Citation?
>
> Could tampering with DNSSEC and/or TLS fall into DMCA grounds ?
>
Good thought, but I was thinking more along the lines of UETA and
E-SIGN, along with the usual criminal penalties for forgery and
fraud (and intent to defraud).

I'm pretty sure those are state by state.

On the US Federal level, there's 18 USC 2511 - Interception and
disclosure of wire, oral, or electronic communications prohibited.

In any case, there's plenty of law to choose, we simply need a solid
test case.  Family members are Wide Open West (WOW) subscribers, and
they are listed among the miscreant companies that Heather linked.
I'd happily be a plaintiff based on my use of their network, but we
probably need some actual affected subscribers.


From johnl at iecc.com  Tue Sep 27 13:31:34 2011
From: johnl at iecc.com (John Levine)
Date: 27 Sep 2011 18:31:34 -0000
Subject: Nxdomain redirect revenue
In-Reply-To: <4E81DBA9.7050303@gmail.com>
Message-ID: <20110927183134.83967.qmail@joyce.lan>

>It's not legal for an ISP to modify computer data.  Especially
>digitally signed data.  That's a criminal offense.

It is indeed illegal to break into someone's else's computer and
tamper with the data therein.

It is frankly ridiculous to try to apply that law to data in your own
equipment.  If you think computer tampering laws apply to the
operation of one's own DNS cache, provide case law.

For case law confirming that similar language in the Stored
Communication Act doesn't apply to data on your own equipment, see the
recently dismissed cases of Holomaxx vs. Microsoft and Holomaxx
vs. Yahoo.

R's,
John

PS: Can we stop playing Junior Lawyer now?



From ekim.ittag at gmail.com  Tue Sep 27 14:21:28 2011
From: ekim.ittag at gmail.com (Mike Gatti)
Date: Tue, 27 Sep 2011 12:21:28 -0700
Subject: Authoritative DNS server for 12.54.94.0/23 PTR
Message-ID: <CFBBD42E-A2C3-4DB2-9C4D-3FEF33F4E9F9@gmail.com>

Hello Nanog Members, 

We have been having some issue doing reverse lookups for ip's in the 12.54.94.0/23 prefix. We know that this block is assigned to AT&T and AT&T has assigned that block to Siemens Medical (based on whois queries). We are now trying to find out who would be the authoritative DNS server that would resolve PTR queries for these IP addresses. Would someone from AT&T (or Siemens) or someone that has that info please contact me offline to discuss?

Thanks Everyone, 
--
Michael Gatti  
cell.949.735.5612
ekim.ittag at gmail.com
(UTC-8)





From abigabaw at gmail.com  Tue Sep 27 14:41:32 2011
From: abigabaw at gmail.com (Wilson Abigaba)
Date: Tue, 27 Sep 2011 22:41:32 +0300
Subject: Authoritative DNS server for 12.54.94.0/23 PTR
In-Reply-To: <CFBBD42E-A2C3-4DB2-9C4D-3FEF33F4E9F9@gmail.com>
References: <CFBBD42E-A2C3-4DB2-9C4D-3FEF33F4E9F9@gmail.com>
Message-ID: <CAN1xXHE-h0Dkg8vz3SV3RLRrsfy6DbtLXk14dd4_wxdLuSsizw@mail.gmail.com>

Hi Michael,

Have you tried reaching the contacts at
http://whois.arin.net/rest/poc/JMO282-ARIN.html directly?

Kind Regards,
Wilson


On Tue, Sep 27, 2011 at 22:21, Mike Gatti <ekim.ittag at gmail.com> wrote:
> Hello Nanog Members,
>
> We have been having some issue doing reverse lookups for ip's in the 12.54.94.0/23 prefix. We know that this block is assigned to AT&T and AT&T has assigned that block to Siemens Medical (based on whois queries). We are now trying to find out who would be the authoritative DNS server that would resolve PTR queries for these IP addresses. Would someone from AT&T (or Siemens) or someone that has that info please contact me offline to discuss?
>
> Thanks Everyone,
> --
> Michael Gatti
> cell.949.735.5612
> ekim.ittag at gmail.com
> (UTC-8)
>
>
>
>
>


From packetjockey at gmail.com  Tue Sep 27 14:44:20 2011
From: packetjockey at gmail.com (Rafael Rodriguez)
Date: Tue, 27 Sep 2011 15:44:20 -0400
Subject: flow generating tool
In-Reply-To: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
References: <D200EA14D9516C49B07F3DA72D7E24C13371308E7F@INXS.max.sf>
Message-ID: <662A0BF8-05A9-4B09-8955-344CA78FACED@gmail.com>

If a software based solution is OK, check out IxChariot, endpoints can be Windows, Linux, OS X, and Solaris. Used it years ago and was happy with it.
http://www.ixchariot.com/



Sent from my iPhone

On Sep 26, 2011, at 6:07, Naiden Dimitrov <naiden.dimitrov at maxtelecom.bg> wrote:

> Hello,
> 
> 
> 
> I need a tool that generates traffic flows from different source IP addresses for network tests.
> 
> 
> 
> Regards,
> 
> 
> 
> Naiden Dimitrov
> Mobile: +359 885 906 155
> naiden.dimitrov at maxtelecom.bg<mailto:naiden.dimitrov at maxtelecom.bg>
> www.maxtelecom.bg<http://www.maxtelecom.bg>
> 
> 
> 
> 
> 


From keegan.holley at sungard.com  Tue Sep 27 15:06:59 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Tue, 27 Sep 2011 16:06:59 -0400
Subject: Authoritative DNS server for 12.54.94.0/23 PTR
In-Reply-To: <CFBBD42E-A2C3-4DB2-9C4D-3FEF33F4E9F9@gmail.com>
References: <CFBBD42E-A2C3-4DB2-9C4D-3FEF33F4E9F9@gmail.com>
Message-ID: <CABO8Q6SG+tkijtT1SGJT+u-_1ThzN6VLfSg+C2Q0ozKrCQiRog@mail.gmail.com>

it looks like ATT still answers the queries.  I'd assume that any changes
would have to be authorized by the customer though.  Why not just call
Siemens Medical?

; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 12.54.91.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21619
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;1.91.54.12.in-addr.arpa.    IN    PTR

;; AUTHORITY SECTION:
54.12.in-addr.arpa.    900    IN    SOA    xbru.br.ns.els-gms.att.net.
rm-hostmaster.ems.att.com. 1179 86400 10000 600000 172800



2011/9/27 Mike Gatti <ekim.ittag at gmail.com>

> Hello Nanog Members,
>
> We have been having some issue doing reverse lookups for ip's in the
> 12.54.94.0/23 prefix. We know that this block is assigned to AT&T and AT&T
> has assigned that block to Siemens Medical (based on whois queries). We are
> now trying to find out who would be the authoritative DNS server that would
> resolve PTR queries for these IP addresses. Would someone from AT&T (or
> Siemens) or someone that has that info please contact me offline to discuss?
>
> Thanks Everyone,
> --
> Michael Gatti
> cell.949.735.5612
> ekim.ittag at gmail.com
> (UTC-8)
>
>
>
>
>
>

From nick at foobar.org  Tue Sep 27 15:45:22 2011
From: nick at foobar.org (Nick Hilliard)
Date: Tue, 27 Sep 2011 21:45:22 +0100
Subject: Nxdomain redirect revenue
In-Reply-To: <20110927183134.83967.qmail@joyce.lan>
References: <20110927183134.83967.qmail@joyce.lan>
Message-ID: <4E8235E2.5000304@foobar.org>

On 27/09/2011 19:31, John Levine wrote:
> For case law confirming that similar language in the Stored
> Communication Act doesn't apply to data on your own equipment, see the
> recently dismissed cases of Holomaxx vs. Microsoft and Holomaxx
> vs. Yahoo.

In Europe, things are slightly different.  Traffic snooping is considered
to be a breach of consumer data protection directives and is treated
accordingly.  One of the more interesting cases was BT + Phorm:

> http://en.wikipedia.org/wiki/Phorm#European_Commission_case_against_UK_over_Phorm

While the case never went to court, all parties backed down and there
hasn't been a similar case since then.

There is another aspect to this: european IP service providers can claim
"mere conduit" status (similar to US "common carrier") under the terms of
the Electronic Commerce Directive 2000/31/EC (as transcribed into local
legislation), provided during the process of transmission they do "not
select or modify the information contained in the transmission".  It would
seem possible that changing DNS packets in transit could come under the
scope of "select or modify", thereby leaving the IP service provider liable
for the information transmitted.  This can act as a deterrent to service
providers who feel that modifying data in-flight is a good idea.

Nick



From jcdill.lists at gmail.com  Tue Sep 27 15:54:26 2011
From: jcdill.lists at gmail.com (JC Dill)
Date: Tue, 27 Sep 2011 13:54:26 -0700
Subject: Nxdomain redirect revenue
In-Reply-To: <4E81DBA9.7050303@gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>	<82sjnjg0zi.fsf@mid.bfk.de>	<4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <4E81DBA9.7050303@gmail.com>
Message-ID: <4E823802.2050708@gmail.com>

On 27/09/11 7:20 AM, William Allen Simpson wrote:
>
>
>> Most likely the ISPs'  lawyers were smart enough to include a clause
>> in the ToS/AUP allowing
>> the ISP to intercept, blackhole, or redirect access to any hostname or
>> IP address.
>>
> It's not legal to insert a clause allowing criminal conduct.  There's
> no safe haven for criminal conduct.


I'm not sure that it's *illegal to insert a clause* for conduct that is 
forbidden by law.  I'm pretty sure you can claim almost anything in the 
contract.  What is illegal is enforcement of an illegal clause.  Law 
trumps contract terms - that's WHY we have civil laws - to protect 
people from unscrupulous business dealings.  And that's why most 
contracts have a clause that says if a particular clause in the contract 
is found invalid the rest of the contract still stands - because so many 
contracts DO have invalid clauses.  For example, many employment 
contracts have non-compete clauses that forbid the employee from going 
to work for a competitor.  But in many states these clauses violate the 
state's right-to-work laws.  The company lawyers KNOW the clause is 
illegal, but they insert it in the employment contracts anyway, to try 
to fool employees into thinking they will get sued if they go to work 
for a competitor.


>> The name for an ISP intercepting traffic from its own users is  not
>> "interference"  or  "DoS",
>> because they're breaking the operation of (er) only their own network.
>>
> No, they're breaking the operation of my network and my computers.  My
> network connects to their network.

But you have no recourse, their network, their rules.  (Right?)  You 
*might* have recourse if they were modifying traffic you sent to their 
customer, but in this case they are modifying traffic that originates 
FROM their customer.  I'm not convinced that redirecting this traffic is 
any different from blocking it (e.g. firewall to prevent employees from 
accessing facebook or torrents).

I believe the only entity who has recourse is the entity who is paying 
them for service - e.g. their (paying) customer.

jc



From bonomi at mail.r-bonomi.com  Tue Sep 27 16:13:32 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Tue, 27 Sep 2011 16:13:32 -0500 (CDT)
Subject: Nxdomain redirect revenue
In-Reply-To: <4E823802.2050708@gmail.com>
Message-ID: <201109272113.p8RLDWfA043444@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Tue Sep 27 15:54:37 2011
> Date: Tue, 27 Sep 2011 13:54:26 -0700
> From: JC Dill <jcdill.lists at gmail.com>
> To: NANOG list <nanog at nanog.org>
> Subject: Re: Nxdomain redirect revenue
>
> On 27/09/11 7:20 AM, William Allen Simpson wrote:
> >
> >
> >> Most likely the ISPs'  lawyers were smart enough to include a clause
> >> in the ToS/AUP allowing
> >> the ISP to intercept, blackhole, or redirect access to any hostname or
> >> IP address.
> >>
> > It's not legal to insert a clause allowing criminal conduct.  There's
> > no safe haven for criminal conduct.
>
>
> I'm not sure that it's *illegal to insert a clause* for conduct that is 
> forbidden by law.  I'm pretty sure you can claim almost anything in the 
> contract.  What is illegal is enforcement of an illegal clause.  Law 
> trumps contract terms - that's WHY we have civil laws - to protect 
> people from unscrupulous business dealings.  And that's why most 
> contracts have a clause that says if a particular clause in the contract 
> is found invalid the rest of the contract still stands - because so many 
> contracts DO have invalid clauses.  For example, many employment 
> contracts have non-compete clauses that forbid the employee from going 
> to work for a competitor.  But in many states these clauses violate the 
> state's right-to-work laws.  The company lawyers KNOW the clause is 
> illegal, but they insert it in the employment contracts anyway, to try 
> to fool employees into thinking they will get sued if they go to work 
> for a competitor.
>
>
> >> The name for an ISP intercepting traffic from its own users is  not
> >> "interference"  or  "DoS",
> >> because they're breaking the operation of (er) only their own network.
> >>
> > No, they're breaking the operation of my network and my computers.  My
> > network connects to their network.
>
> But you have no recourse, their network, their rules.  (Right?)  You 
> *might* have recourse if they were modifying traffic you sent to their 
> customer, but in this case they are modifying traffic that originates 
> FROM their customer.  I'm not convinced that redirecting this traffic is 
> any different from blocking it (e.g. firewall to prevent employees from 
> accessing facebook or torrents).
>
> I believe the only entity who has recourse is the entity who is paying 
> them for service - e.g. their (paying) customer.

In the specific case of 'falsifying' a DNS return for what would have been
a NXDOMAIN, that is "mostly' correct.  but consider whqat happens  when 
you get into the situation of querying a DNSBL operator -- where an 'error'
result _is_ a desired return value.

Now, when the provider returns 'false and misleading' data for what would 
be, under normal conditions, a SUCCESSFUL query -- say, returning a 'bogus'
address for a well-known search-engine, so as to bee able to manipulate the
results -- then the party whose traffic is being 'stolen', and sent to the 
bogus server, THAT party may well have grounds for a civil suit for 'tortuous
interference with a business relationship'.  In this situation, there are 
also possible criminal sanctions, under 'wiretapping' prohibitions, among
others.



From jbates at brightok.net  Tue Sep 27 16:25:33 2011
From: jbates at brightok.net (Jack Bates)
Date: Tue, 27 Sep 2011 16:25:33 -0500
Subject: RSVP-TE and link coloring
Message-ID: <4E823F4D.4030307@brightok.net>

Question, do vendors/protocol work well with specifying different colors 
on opposite sides of a link?

What I was wondering is if I could make one direction of a ring one 
color and the other direction a different color for ease of path 
selection in RSVP-TE.


Jack


From mysidia at gmail.com  Tue Sep 27 17:08:42 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 27 Sep 2011 17:08:42 -0500
Subject: Nxdomain redirect revenue
In-Reply-To: <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
Message-ID: <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>

On Tue, Sep 27, 2011 at 8:27 AM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:

> how does tls/https help here? if you get sent to the 'wrong host'
> whether or not it does https/tls is irrelevant, no? (save the case of
> chrome and domain pinning)

Because the operator of the "wrong host"    cannot obtain a SSL certificate for
the right host's domain from a legitimate CA.

When the user types in  '[therightdomain].com'
and their browser immediately sends them to  https://therightdomain.com

the HTTPS request will fail and show the user an error message if the
site is the wrong one,
instead of allowing the wrong server to produce a response.


To be clear, I am suggesting HTTPS should be the default, all servers
should support it,
and once a browser learns that a site supports HTTPS,  it should
maintain a memory of that
fact in a hash table,  and refuse to access the site over HTTP unless
specifically requested
(in order to prevent downgrade attacks) and refuse to try HTTP first
when a new domain is entered.

The http://  schema should be removed/deprecated,  and replaced with
insecurehttp://
And plain HTTP only used first if the user types that.

That is, HTTPs should become assumed.


Regards,

--
-JH


From dave at mvn.net  Tue Sep 27 17:29:36 2011
From: dave at mvn.net (David E. Smith)
Date: Tue, 27 Sep 2011 17:29:36 -0500
Subject: Nxdomain redirect revenue
In-Reply-To: <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
Message-ID: <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>

On Tue, Sep 27, 2011 at 17:08, Jimmy Hess <mysidia at gmail.com> wrote:
> That is, HTTPs should become assumed.

As much as that would be wonderful from a security standpoint, IMO
it's not realistic to expect every mom-and-pop posting a personal Web
site to pay extra for a static/dedicated IP address from their hosting
company (even if IPv6 were widely deployed, Web hosts probably would
charge extra for this just on principle), and to pay extra for an SSL
certificate, even a "weak" one that only verifies the domain name.

If a given Web site's developers think their content is "important"
(however they define the term), they certainly can add SSL to the
site; in the grand scheme of things the cost is pretty small. But
assuming everyone can/should do this is probably a step too far.

That said, there's nothing wrong with browser extensions that try
HTTPS first, and I'd wager that sooner or later one of the big
browsers will make that a built-in option.

David Smith
MVN.net


From mysidia at gmail.com  Tue Sep 27 17:46:47 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 27 Sep 2011 17:46:47 -0500
Subject: Nxdomain redirect revenue
In-Reply-To: <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
 <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
Message-ID: <CAAAwwbVLmh+MsXU-axOy=twz+oWvszyZ3O8n-bMqpna4tR7Xtg@mail.gmail.com>

On Tue, Sep 27, 2011 at 5:29 PM, David E. Smith <dave at mvn.net> wrote:
> On Tue, Sep 27, 2011 at 17:08, Jimmy Hess <mysidia at gmail.com> wrote:
>> That is, HTTPs should become assumed.
> As much as that would be wonderful from a security standpoint, IMO
> it's not realistic to expect every mom-and-pop posting a personal Web
> site to pay extra for a static/dedicated IP address from their hosting
> company (even if IPv6 were widely deployed, Web hosts probably would

Thanks to TLS  SNI (server name indication), a dedicated IP address is
no longer necessarily,
RFC 3546, 3.1.

Yes, it is realistic to expect every mom-and-pop posting a personal
web site to utilize a provider that implements SNI,  and the sooner
they do it.

It's also realistic to expect them to buy one of those $15  SSL certificates.
Heck....   1 year .COM  registration used to cost a lot more than that.

We're not talking about huge recurring costs here.

--
-JH


From eric at opticfusion.net  Tue Sep 27 18:11:18 2011
From: eric at opticfusion.net (Eric Stockwell)
Date: Tue, 27 Sep 2011 16:11:18 -0700
Subject: Environmental monitoring options
In-Reply-To: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
References: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
Message-ID: <4E825816.1030603@opticfusion.net>

We use both the ITWatchDogs MiniGoose and the NTI EnviroMux. Both 
provide similar feature sets,  but the MiniGoose has a nicer web 
interface and is less expensive.

Eric Stockwell
Optic Fusion


On 09/27/2011 07:05 AM, eric clark wrote:
> I'd like to ask the list what products people are using to monitor their
> environments. By this I'm referring to datacenters, and other equipment.
> Temperature, humidity, airflow, cameras, dry contacts, door sensors, leak
> detection, all that sort of thing.
>
> I've used Netbotz in the past. Looking to see what else is out there that
> people like.
>
> Thanks
>
> E


From owen at delong.com  Tue Sep 27 18:09:03 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 27 Sep 2011 16:09:03 -0700
Subject: Nxdomain redirect revenue
In-Reply-To: <CAAAwwbVLmh+MsXU-axOy=twz+oWvszyZ3O8n-bMqpna4tR7Xtg@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
 <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
 <CAAAwwbVLmh+MsXU-axOy=twz+oWvszyZ3O8n-bMqpna4tR7Xtg@mail.gmail.com>
Message-ID: <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>


On Sep 27, 2011, at 3:46 PM, Jimmy Hess wrote:

> On Tue, Sep 27, 2011 at 5:29 PM, David E. Smith <dave at mvn.net> wrote:
>> On Tue, Sep 27, 2011 at 17:08, Jimmy Hess <mysidia at gmail.com> wrote:
>>> That is, HTTPs should become assumed.
>> As much as that would be wonderful from a security standpoint, IMO
>> it's not realistic to expect every mom-and-pop posting a personal Web
>> site to pay extra for a static/dedicated IP address from their hosting
>> company (even if IPv6 were widely deployed, Web hosts probably would
> 
> Thanks to TLS  SNI (server name indication), a dedicated IP address is
> no longer necessarily,
> RFC 3546, 3.1.
> 

Except when it is.

> Yes, it is realistic to expect every mom-and-pop posting a personal
> web site to utilize a provider that implements SNI,  and the sooner
> they do it.
> 

No, it isn't because it requires you to send the domain portion of the URL
in clear text and it may be that you don't necessarily want to disclose even
that much information about your browsing to the public.

> It's also realistic to expect them to buy one of those $15  SSL certificates.
> Heck....   1 year .COM  registration used to cost a lot more than that.
> 

Meh... I disagree. I don't think there's any reason to encrypt web sites
that don't use authentication and are not providing personally identifying
information or other "secret" data. I run several web servers virtual and
real on one of my systems. Some of them have SSL, some of them don't.
Even the ones that have SSL don't encrypt everything. There's no reason
to encrypt that which does not need encryption and it's just an extra cost
in terms of server resources and client resources to do so.

> We're not talking about huge recurring costs here.
> 

That depends. If it's a popular web site that delivers a lot of content,
the additional CPU horsepower just to do the cryptography and the
additional power to drive it could actually be very significant.

For the average mom and pop, no, it's not a huge cost, but, neither is
it necessarily a cost worth bothering with.

Frankly, I don't expect static (or at least static-enough) addresses to
cost extra in IPv6. You can already get a /48 from Hurricane Electric
for free as long as you have IPv4 access. I suspect that eventually
other IPv6 providers will have to at least match that standard.

Owen



From rubensk at gmail.com  Tue Sep 27 18:34:15 2011
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 27 Sep 2011 20:34:15 -0300
Subject: Nxdomain redirect revenue
In-Reply-To: <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
 <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
Message-ID: <CAGFn2k3wbhBxRxtKaOU8V8F4FmAZuqB59WQw_EGwwE=ekghrwA@mail.gmail.com>

On Tue, Sep 27, 2011 at 7:29 PM, David E. Smith <dave at mvn.net> wrote:
> On Tue, Sep 27, 2011 at 17:08, Jimmy Hess <mysidia at gmail.com> wrote:
>> That is, HTTPs should become assumed.
>
> As much as that would be wonderful from a security standpoint, IMO
> it's not realistic to expect every mom-and-pop posting a personal Web
> site to pay extra for a static/dedicated IP address from their hosting
> company (even if IPv6 were widely deployed, Web hosts probably would
> charge extra for this just on principle), and to pay extra for an SSL
> certificate, even a "weak" one that only verifies the domain name.

Self-signed certificates published thru DNSSEC using CAA/DANE can cost nothing.
(And somebody else pointed out SNI to have TLS work without exclusive
IP requirement)

Rubens


From mysidia at gmail.com  Tue Sep 27 18:55:28 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 27 Sep 2011 18:55:28 -0500
Subject: Nxdomain redirect revenue
In-Reply-To: <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
 <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
 <CAAAwwbVLmh+MsXU-axOy=twz+oWvszyZ3O8n-bMqpna4tR7Xtg@mail.gmail.com>
 <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
Message-ID: <CAAAwwbX8LE7X1vNSr+=ZOWdRjgXxRUy=PaC_A21Vi46-H-EEgA@mail.gmail.com>

On Tue, Sep 27, 2011 at 6:09 PM, Owen DeLong <owen at delong.com> wrote:
> On Sep 27, 2011, at 3:46 PM, Jimmy Hess wrote:
>
> No, it isn't because it requires you to send the domain portion of the URL
> in clear text and it may be that you don't necessarily want to disclose even
> that much information about your browsing to the public.

That's OK.  You're kind of mincing security objectives here.
In regards to preventing tactics such as domain hijacking bt service providers,
the goal behind this would be integrity, not confidentiality.

The objective of using SSL is not to strongly encrypt data to keep it
secret, it's
to apply whatever is necessary to provide a level of integrity assurance.

The SSL cipher can almost be the null cipher, for all it matters,
but at least RC4  56-bit  or so would be needed,  because
the null cipher doesn't have message digests in TLS.

--
-JH


From pelzi at pelzi.net  Tue Sep 27 18:56:50 2011
From: pelzi at pelzi.net (Jussi Peltola)
Date: Wed, 28 Sep 2011 02:56:50 +0300
Subject: Nxdomain redirect revenue
In-Reply-To: <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
 <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
 <CAAAwwbVLmh+MsXU-axOy=twz+oWvszyZ3O8n-bMqpna4tR7Xtg@mail.gmail.com>
 <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
Message-ID: <20110927235650.GP22443@pokute.pelzi.net>

On Tue, Sep 27, 2011 at 04:09:03PM -0700, Owen DeLong wrote:
> No, it isn't because it requires you to send the domain portion of the URL
> in clear text and it may be that you don't necessarily want to disclose even
> that much information about your browsing to the public.
 
And speaking https to a per-domain ip address reveals nothing about
browsing habits?


From mpalmer at hezmatt.org  Tue Sep 27 19:26:45 2011
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Wed, 28 Sep 2011 10:26:45 +1000
Subject: Nxdomain redirect revenue
In-Reply-To: <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
Message-ID: <20110928002645.GO30570@mistress.hezmatt.org>

On Tue, Sep 27, 2011 at 05:08:42PM -0500, Jimmy Hess wrote:
> On Tue, Sep 27, 2011 at 8:27 AM, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
> 
> > how does tls/https help here? if you get sent to the 'wrong host'
> > whether or not it does https/tls is irrelevant, no? (save the case of
> > chrome and domain pinning)
> 
> Because the operator of the "wrong host"    cannot obtain a SSL
> certificate for the right host's domain from a legitimate CA.

Oh, if only 'twere true... even without control of the DNS for the domain,
there have been plenty of certificates erroneously issued.  With DNS
control, doing the necessary validation steps required for the issuance of a
certificate is child's play.

Then, of course, there's the issues with what constitutes a "legitimate" CA;
the list of CAs that I'd never want to trust, but which are in my browser by
default, is long and notorious.

- Matt



From rcarpen at network1.net  Tue Sep 27 19:31:20 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Tue, 27 Sep 2011 20:31:20 -0400 (EDT)
Subject: Environmental monitoring options
In-Reply-To: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
Message-ID: <ee7239f1-9860-451b-99eb-8d4b270ca942@zimbra.network1.net>


We have some Tripp Lite UPS units that have SNMP cards. You can add their ENVIROSENSE module for pretty cheap to get temperature and humidity. There are contacts for additional sensors as well.


-Randy


----- Original Message -----
> I'd like to ask the list what products people are using to monitor
> their
> environments. By this I'm referring to datacenters, and other
> equipment.
> Temperature, humidity, airflow, cameras, dry contacts, door sensors,
> leak
> detection, all that sort of thing.
> 
> I've used Netbotz in the past. Looking to see what else is out there
> that
> people like.
> 
> Thanks
> 
> E
> 
> 


From cmadams at hiwaay.net  Tue Sep 27 20:44:10 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 27 Sep 2011 20:44:10 -0500
Subject: Nxdomain redirect revenue
In-Reply-To: <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
 <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
 <CAAAwwbVLmh+MsXU-axOy=twz+oWvszyZ3O8n-bMqpna4tR7Xtg@mail.gmail.com>
 <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
Message-ID: <20110928014410.GB21359@hiwaay.net>

Once upon a time, Owen DeLong <owen at delong.com> said:
> No, it isn't because it requires you to send the domain portion of the URL
> in clear text and it may be that you don't necessarily want to disclose even
> that much information about your browsing to the public.

If you don't want even the site you are browsing public, HTTPS is not
the solution.  Without SNI, HTTPS is one-site-per-IP (nobody uses the
subjectAltName to host multiple different sites on the same IP in
practice), so all somebody has to do it fetch the certificate from the
same IP/port and look at the CN/subjectAltName.  Either that's the site
you went to, or you accepted the host/cert mismatch (and are a target
for spoofing).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From davehart at gmail.com  Tue Sep 27 21:06:56 2011
From: davehart at gmail.com (Dave Hart)
Date: Wed, 28 Sep 2011 02:06:56 +0000
Subject: Authoritative DNS server for 12.54.94.0/23 PTR
In-Reply-To: <CABO8Q6SG+tkijtT1SGJT+u-_1ThzN6VLfSg+C2Q0ozKrCQiRog@mail.gmail.com>
References: <CFBBD42E-A2C3-4DB2-9C4D-3FEF33F4E9F9@gmail.com>
 <CABO8Q6SG+tkijtT1SGJT+u-_1ThzN6VLfSg+C2Q0ozKrCQiRog@mail.gmail.com>
Message-ID: <CAMbSiYDFmyVf_YmaW=W0pdoOenj3iZob=Ns6JivyvS16zQsxfg@mail.gmail.com>

On Tue, Sep 27, 2011 at 20:06 UTC, Keegan Holley wrote:
> it looks like ATT still answers the queries.

Actually those two /24s are delegated to siemensmedical.com
nameservers.  Your query typo'd the third octet:

; <<>> DiG 9.8.0-P4 <<>> +trace -x 12.54.94.1
;; global options: +cmd
.                       492919  IN      NS      h.root-servers.net.
.                       492919  IN      NS      l.root-servers.net.
.                       492919  IN      NS      a.root-servers.net.
.                       492919  IN      NS      k.root-servers.net.
.                       492919  IN      NS      j.root-servers.net.
.                       492919  IN      NS      e.root-servers.net.
.                       492919  IN      NS      d.root-servers.net.
.                       492919  IN      NS      c.root-servers.net.
.                       492919  IN      NS      g.root-servers.net.
.                       492919  IN      NS      b.root-servers.net.
.                       492919  IN      NS      f.root-servers.net.
.                       492919  IN      NS      m.root-servers.net.
.                       492919  IN      NS      i.root-servers.net.
;; Received 449 bytes from 64.13.115.12#53(64.13.115.12) in 179 ms

in-addr.arpa.           172800  IN      NS      b.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      e.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      d.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      c.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      f.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      a.in-addr-servers.arpa.
;; Received 417 bytes from 192.228.79.201#53(b.root-servers.net) in 135 ms

12.in-addr.arpa.        86400   IN      NS      cbru.br.ns.els-gms.att.net.
12.in-addr.arpa.        86400   IN      NS      cmtu.mt.ns.els-gms.att.net.
12.in-addr.arpa.        86400   IN      NS      dbru.br.ns.els-gms.att.net.
12.in-addr.arpa.        86400   IN      NS      dmtu.mt.ns.els-gms.att.net.
;; Received 141 bytes from 2001:500:87::87#53(b.in-addr-servers.arpa) in 128 ms

94.54.12.in-addr.arpa.  172800  IN      NS      ns0.siemensmedical.com.
94.54.12.in-addr.arpa.  172800  IN      NS      ns.siemensmedical.com.
;; Received 94 bytes from
199.191.128.106#53(dbru.br.ns.els-gms.att.net) in 204 ms

;; connection timed out; no servers could be reached
And it appears the delegated nameservers are unresponsive.

Cheers,
Dave Hart


From owen at delong.com  Wed Sep 28 00:23:34 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 27 Sep 2011 22:23:34 -0700
Subject: Nxdomain redirect revenue
In-Reply-To: <CAAAwwbX8LE7X1vNSr+=ZOWdRjgXxRUy=PaC_A21Vi46-H-EEgA@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
 <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
 <CAAAwwbVLmh+MsXU-axOy=twz+oWvszyZ3O8n-bMqpna4tR7Xtg@mail.gmail.com>
 <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
 <CAAAwwbX8LE7X1vNSr+=ZOWdRjgXxRUy=PaC_A21Vi46-H-EEgA@mail.gmail.com>
Message-ID: <7904957E-3C10-4DD2-86DF-2FF0D6F0B1DF@delong.com>


On Sep 27, 2011, at 4:55 PM, Jimmy Hess wrote:

> On Tue, Sep 27, 2011 at 6:09 PM, Owen DeLong <owen at delong.com> wrote:
>> On Sep 27, 2011, at 3:46 PM, Jimmy Hess wrote:
>> 
>> No, it isn't because it requires you to send the domain portion of the URL
>> in clear text and it may be that you don't necessarily want to disclose even
>> that much information about your browsing to the public.
> 
> That's OK.  You're kind of mincing security objectives here.
> In regards to preventing tactics such as domain hijacking bt service providers,
> the goal behind this would be integrity, not confidentiality.
> 
> The objective of using SSL is not to strongly encrypt data to keep it
> secret, it's
> to apply whatever is necessary to provide a level of integrity assurance.
> 
> The SSL cipher can almost be the null cipher, for all it matters,
> but at least RC4  56-bit  or so would be needed,  because
> the null cipher doesn't have message digests in TLS.
> 
> --
> -JH

As has been pointed out... SSL certs do almost nothing for integrity.

Owen



From keegan.holley at sungard.com  Wed Sep 28 01:35:34 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 28 Sep 2011 02:35:34 -0400
Subject: Authoritative DNS server for 12.54.94.0/23 PTR
In-Reply-To: <CABO8Q6SG+tkijtT1SGJT+u-_1ThzN6VLfSg+C2Q0ozKrCQiRog@mail.gmail.com>
References: <CFBBD42E-A2C3-4DB2-9C4D-3FEF33F4E9F9@gmail.com>
 <CABO8Q6SG+tkijtT1SGJT+u-_1ThzN6VLfSg+C2Q0ozKrCQiRog@mail.gmail.com>
Message-ID: <CABO8Q6Ths0GSp-Au48k0dnKqn2v9xoG9JuHF7kyjY1ZRdgKGbw@mail.gmail.com>

Looks like I typo'd the third octet.

2011/9/27 Keegan Holley <keegan.holley at sungard.com>

> it looks like ATT still answers the queries.  I'd assume that any changes
> would have to be authorized by the customer though.  Why not just call
> Siemens Medical?
>
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 12.54.91.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21619
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;1.91.54.12.in-addr.arpa.    IN    PTR
>
> ;; AUTHORITY SECTION:
> 54.12.in-addr.arpa.    900    IN    SOA    xbru.br.ns.els-gms.att.net.
> rm-hostmaster.ems.att.com. 1179 86400 10000 600000 172800
>
>
>
>
> 2011/9/27 Mike Gatti <ekim.ittag at gmail.com>
>
>> Hello Nanog Members,
>>
>> We have been having some issue doing reverse lookups for ip's in the
>> 12.54.94.0/23 prefix. We know that this block is assigned to AT&T and
>> AT&T has assigned that block to Siemens Medical (based on whois queries). We
>> are now trying to find out who would be the authoritative DNS server that
>> would resolve PTR queries for these IP addresses. Would someone from AT&T
>> (or Siemens) or someone that has that info please contact me offline to
>> discuss?
>>
>> Thanks Everyone,
>> --
>> Michael Gatti
>> cell.949.735.5612
>> ekim.ittag at gmail.com
>> (UTC-8)
>>
>>
>>
>>
>>
>>
>

From serrano.miser at gmail.com  Wed Sep 28 04:32:56 2011
From: serrano.miser at gmail.com (Serranos)
Date: Wed, 28 Sep 2011 10:32:56 +0100
Subject: "general badness" AS-based reputation system
In-Reply-To: <0EA58FFF-2FBE-4977-BC62-211842FEB52E@merit.edu>
References: <mailman.9160.1316989916.1873.nanog@nanog.org>
 <0EA58FFF-2FBE-4977-BC62-211842FEB52E@merit.edu>
Message-ID: <B6088DD0-2FD0-4D82-A287-985FF7D74BED@gmail.com>

On Sep 26, 2011, at 02:23 , Manish Karir wrote:

> We tried to outline some of the challenges of building such a system in our NANOG52 presentation:
> 
> http://www.merit.edu/networkresearch/papers/pdf/2011/NANOG52_reputation-nanog.pdf
> 
> In particular see slide 4. where we tried to lay down what we think the requirements are for a socially acceptable
> reputation system.  
> 
> With a bit of luck we might be able to announce the release of our system before the next NANOG mtg, but in 
> my opinion collating host reputation reports is just a small and the easiest part of the effort.  The key is in 
> solving the challenges of allowing (and incentivizing) participation and being robust to false information
> injection.

Hi Manish.

As mentioned by Gadi, the maintenance of such tools is not often easy, in particular since some datasources may disappear or become obsolete over time. For example, to have a global view of the BGP landscape the best service I know is RIS from RIPE, but there aren't many alternatives. Although this problem may be reduced through an increase of the total number of datasources, it is something to be considered. Also, since historical data is considered, the fact that some datasources may disappear over time can affect the ranking value.

Most importantly, this type of approach is dependent on the level of commitment the network community has, which may be mined by not enough incentives (the problem mentioned in slide 3). Namely (as stated before) the problem of certain customers not being able to reach critical systems "just" because that ASN was considered evil, is a strong incentive *not* to adhere to the system. This is IMHO THE biggest Problem. Also, if you are a transit AS do you think this to be a viable approach?

Although I think this philosophy has strong arguments to move forward, it also has many challenges that must be dealt with and the biggest ones are not technical (what a surprise?).

Thanks for your valuable contribution.

Regards,
S.



From rbf+nanog at panix.com  Wed Sep 28 06:42:14 2011
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Wed, 28 Sep 2011 06:42:14 -0500
Subject: Nxdomain redirect revenue
In-Reply-To: <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
 <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
 <CAAAwwbVLmh+MsXU-axOy=twz+oWvszyZ3O8n-bMqpna4tR7Xtg@mail.gmail.com>
 <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
Message-ID: <20110928114214.GA29685@panix.com>

On Tue, Sep 27, 2011 at 04:09:03PM -0700, Owen DeLong wrote:
> 
> > Yes, it is realistic to expect every mom-and-pop posting a personal
> > web site to utilize a provider that implements SNI,  and the sooner
> > they do it.
> 
> No, it isn't because it requires you to send the domain portion of the URL
> in clear text and it may be that you don't necessarily want to disclose even
> that much information about your browsing to the public.

That's what happens without SNI.  Without SNI, the IP address of the
server is sent in the clear; anyone who captures that traffic knows the
IP address, and, without SNI, anyone who want s to translate the IP
address to a domain name need only connect to the server and see what
certificate is presented.

     -- Brett


From cabenth at gmail.com  Wed Sep 28 09:53:44 2011
From: cabenth at gmail.com (eric clark)
Date: Wed, 28 Sep 2011 07:53:44 -0700
Subject: Environmental monitoring options
In-Reply-To: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
References: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
Message-ID: <CALn8JwOFV8iMHXp_po9NrCQVKT5s1Cguot+0Ghw99jDcO23Q-A@mail.gmail.com>

Thanks for all the replies everyone.

Some good options, though I am surprised by how few options I'm finding that
have a good centralized management system. I have to deploy monitoring to a
bunch of sites spread around the world, centralized management is key.

Thanks for all the suggestions.

From dwhite at olp.net  Wed Sep 28 10:06:01 2011
From: dwhite at olp.net (Dan White)
Date: Wed, 28 Sep 2011 10:06:01 -0500
Subject: Environmental monitoring options
In-Reply-To: <CALn8JwOFV8iMHXp_po9NrCQVKT5s1Cguot+0Ghw99jDcO23Q-A@mail.gmail.com>
References: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
 <CALn8JwOFV8iMHXp_po9NrCQVKT5s1Cguot+0Ghw99jDcO23Q-A@mail.gmail.com>
Message-ID: <20110928150601.GH4620@dan.olp.net>

On 28/09/11?07:53?-0700, eric clark wrote:
>Thanks for all the replies everyone.
>
>Some good options, though I am surprised by how few options I'm finding that
>have a good centralized management system. I have to deploy monitoring to a
>bunch of sites spread around the world, centralized management is key.
>
>Thanks for all the suggestions.

Someone else mentioned Assentria, which we also use for our contact closure
alarms. We configure a north bound SNMP interface towards our central trap
management system (Vaonet).

-- 
Dan White


From psirt at cisco.com  Wed Sep 28 11:00:00 2011
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 28 Sep 2011 12:00:00 -0400
Subject: Cisco Security Advisory: Cisco Unified Communications Manager Session
 Initiation Protocol Memory Leak Vulnerabilities 
Message-ID: <2011092812001.cucm@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cisco Security Advisory: Cisco Unified Communications Manager Session
Initiation Protocol Memory Leak Vulnerability

Advisory ID: cisco-sa-20110928-cucm

Revision 1.0

For Public Release 2011 September 28 1600 UTC (GMT)

+--------------------------------------------------------------------

Summary
=======

Cisco Unified Communications Manager contains a memory leak
vulnerability that could be triggered through the processing of
malformed Session Initiation Protocol (SIP) messages. Exploitation of
this vulnerability could cause an interruption of voice services.
Cisco has released free software updates for supported Cisco Unified
Communications Manager versions to address the vulnerability. A
workaround exists for this SIP vulnerability.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110928-cucm.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory
bundled publication includes ten Cisco Security Advisories. Nine of
the advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the Cisco IOS Software releases that
correct the vulnerability or vulnerabilities detailed in the advisory
as well as the Cisco IOS Software releases that correct all
vulnerabilities in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Security Advisory Bundled Publication" at the
following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Cisco IOS Software is affected by the SIP vulnerability described in
this advisory. A separate Cisco Security Advisory has been published
to disclose the vulnerabilities that affect the Cisco IOS software at
the following location:
http://www.cisco.com/warp/public/707/cisco-sa-20110928-sip.shtml.

Affected Products
=================

Vulnerable Products
+------------------

The following products are affected by the vulnerability that is
described in this advisory:

  * Cisco Unified Communications Manager 6.x
  * Cisco Unified Communications Manager 7.x
  * Cisco Unified Communications Manager 8.x

Note: Cisco Unified Communications Manager version 6.1 reached the
End of Software Maintenance on September 3, 2011. Customers using
Cisco Unified Communications Manager 6.x versions, should contact
their Cisco support team for assistance in upgrading to a supported
version of Cisco Unified Communications Manager.

Products Confirmed Not Vulnerable
+--------------------------------

Cisco Unified Communications Manager version 4.x is not affected by
this vulnerability. No other Cisco products are currently known to be
affected by this vulnerability.

Details
=======

Cisco Unified Communications Manager is the call processing component
of the Cisco IP Telephony solution that extends enterprise telephony
features and functions to packet telephony network devices, such as
IP phones, media processing devices, VoIP gateways, and multimedia
applications.

Memory Leak Vulnerability in SIP
+-------------------------------

Cisco Unified Communications Manager contains a vulnerability that
involves the processing of SIP messages. Cisco Unified Communications
Manager may leak session control buffers (SCBs) when processing a
malformed SIP message. Continued exploitation of the vulnerability
may cause a critical process to fail, which could result in the
disruption of voice services. All SIP ports (TCP ports 5060 and 5061
and UDP ports 5060 and 5061) are affected.

This SIP vulnerability is documented in Cisco bug ID CSCtl86047 and
has been assigned the CVE identifier CVE-2011-2072. This vulnerability
is fixed in Cisco Unified Communications Manager versions 8.6(1),
8.5(1)su2, and 7.1(5b)su4. [Note: there is not a software Service Update
for the 6.x version that contains the fix.]

Note: This vulnerability also affects Cisco IOS Software. The
corresponding Cisco bug ID is CSCto88686. Refer to the separate Cisco
Security Advisory for the Cisco IOS Software for additional details.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

* CSCtl86047

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


Impact
======

Successful exploitation of the vulnerability that is described in
this advisory could allow a remote attacker to trigger a memory leak
that could result in the interruption of voice services. Cisco
Unified Communications Manager will restart the affected processes,
but repeated attacks may result in a sustained denial of service
(DoS) condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to determine
exposure and a complete upgrade solution. Cisco recommends upgrading
to a release equal to or later than the release in the "Recommended
Releases" column of the table.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Additionally, the Cisco IOS Software Checker is available on
the Cisco Security Intelligence Operations (SIO) portal at
http://tools.cisco.com/security/center/selectIOSVersion.x. It provides
several features for checking which Security Advisories affect specified
versions of Cisco IOS Software.

+---------------------------------------+
|      Cisco Unified      | Recommended |
|  Communication Manager  |   Release   |
|         Version         |             |
|-------------------------+-------------|
| 7.x                     | 7.1(5b)su4  |
|-------------------------+-------------|
| 8.x*                    | 8.5(1)su2,  |
|                         | 8.6(1)      |
+---------------------------------------+

*The recommended releases listed in the table above are the latest
Cisco Unified Communications Manager versions available at the
publication of this advisory. Software updates for 6.1 and 8.0 are
not available for CSCtl86047. Customers using these versions should
consult their Cisco support team for assistance in upgrading to a
supported release.

Cisco Unified Communications Manager software can be downloaded from
the following link:

http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=268439621

Workarounds
===========

A workaround exists for customers who do not require SIP in their
environment. Cisco Unified Communication Manager versions 6.1(4), 7.1
(2) and 8.0(1) introduced the ability to disable SIP processing. SIP
processing is enabled by default. Use the following instructions to
disable SIP processing:

  * Step 1: Log in to the Cisco Unified CM Administration web
    interface.

  * Step 2: Navigate to "System > Service Parameters" and select the
    appropriate Cisco Unified Communications Manager server and the
    Cisco CallManager service.

  * Step 3: Change the SIP Interoperability Enabled parameter to
    False and click "Save".

    Note: For a SIP processing change to take effect, the Cisco
    CallManager Service must be restarted. For information on how to
    restart the service, refer to the "Restarting the Cisco
    CallManager Service" section of the document at
    http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/7_1_2/ccmcfg/b03dpi.html#wp1075124

    It is possible to mitigate this vulnerability by implementing
    filtering on screening devices and permitting access to TCP ports
    5060 and 5061 and UDP ports 5060 and 5061 only from networks that
    require SIP access to Cisco Unified Communications Manager
    servers.

    Additional mitigations that can be deployed on Cisco devices in
    the network are available in the companion document "Cisco
    Applied Mitigation Bulletin: Identifying and Mitigating
    Exploitation of the Multiple Vulnerabilities in Cisco Voice
    Products" which is available at the following location:

    http://www.cisco.com/warp/public/707/cisco-amb-20110928-voice.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address this
vulnerability. Prior to deploying software, customers should consult
their maintenance provider or check the software for feature set
compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature
sets they have purchased. By installing, downloading, accessing
or otherwise using such software upgrades, customers agree to be
bound by the terms of Cisco's software license terms found at
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found during internal testing and the
troubleshooting of customer service requests.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-cucm.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+------------------------------------------------------------+
| Revision 1.0 | 2011-September-28 | Initial public release. |
+------------------------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities
in Cisco products, obtaining assistance with security
incidents, and registering to receive security information
from Cisco, is available on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
This includes instructions for press inquiries regarding
Cisco security notices. All Cisco security advisories are available at
http://www.cisco.com/go/psirt.

+--------------------------------------------------------------------
Copyright 2010-2011 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAk6Cp2AACgkQQXnnBKKRMNBjhAD9GKvtDztX+sVsYR4zpP3A2D3S
wcFSudybB1DabA/OxwgA/iSVEqO/rJRHx5V9BrnZqLdvqmzcMjo5oLTgbKdlGIG8
=5svm
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 28 11:00:00 2011
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 28 Sep 2011 12:00:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Data-Link Switching
 Vulnerability 
Message-ID: <2011092812001.dlsw@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cisco Security Advisory: Cisco IOS Software Data-Link Switching
Vulnerability

Advisory ID: cisco-sa-20110928-dlsw

Revision 1.0

For Public Release 2011 September 28 1600 UTC (GMT)

+---------------------------------------------------------------------

Summary
=======

Cisco IOS Software contains a memory leak vulnerability in the
Data-Link Switching (DLSw) feature that could result in a device
reload when processing crafted IP Protocol 91 packets.

Cisco has released free software updates that address this
vulnerability.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110928-dlsw.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory
bundled publication includes ten Cisco Security Advisories. Nine of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the Cisco IOS Software releases that
correct the vulnerability or vulnerabilities detailed in the advisory as
well as the Cisco IOS Software releases that correct all vulnerabilities
in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Security Advisory Bundled Publication" at the
following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Affected Products
=================

Vulnerable Products
+------------------

Cisco IOS devices with the DLSw promiscuous feature enabled are affected
by the vulnerability described in this advisory. Devices with the DLSw
promiscuous feature enabled contain a line in the configuration defining
a local DLSw peer with the promiscuous keyword. This configuration
can be observed by issuing the command "show running-config". Systems
configured with the DLSw promiscuous feature enabled contain a line
similar to one of the following:

    dlsw local-peer promiscuous

or

    dlsw local-peer peer-id <IP address> promiscuous

To determine the software that runs on a Cisco IOS device, log in to
the device and issue the "show version" command to display the system
banner. Cisco IOS Software identifies itself as "Cisco Internetwork
Operating System Software" or "Cisco IOS Software." Other Cisco devices
do not have the "show version" command or give different output.

The following example shows output from a device running IOS version
15.0(1)M1:

    Router> show version
    Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2009 by Cisco Systems, Inc.
    Compiled Wed 02-Dec-09 17:17 by prod_rel_team

Additional information about Cisco IOS Software release naming
conventions is available in the white paper Cisco IOS and NX-OS
Software Reference Guide at:

http://www.cisco.com/web/about/security/intelligence/ios-ref.html.

Products Confirmed Not Vulnerable
+--------------------------------

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

DLSw provides a means of transporting IBM Systems Network
Architecture (SNA) and network BIOS (NetBIOS) traffic over an IP
network. The Cisco implementation of DLSw over Fast Sequence
Transport (FST) uses IP Protocol 91. The promiscuous DLSw feature
permits the local peer to establish connection with remote peers that
are not statically configured.

A Cisco IOS device that is configured for DLSw listens for IP
protocol 91 packets. Depending on the DLSw configuration, UDP port
2067, and, one or more TCP ports can also be opened. The
vulnerability described in this document can only be exploited via IP
Protocol 91 and can not be exploited using either the UDP or TCP
transports.

Devices with only statically configured DLSw peers are not affected
by this vulnerability.

This vulnerability is documented in Cisco bug ID CSCth69364 and has been
assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2011-0945.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss


* CSCth69364 ("DLSw FST Memory Leak")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


Impact
======

Successful exploitation of the vulnerability may result in a memory
leak that can lead to a denial of service condition. Memory
exhaustion can cause an affected Cisco IOS device to reload or become
unresponsive; a power cycle might be required to recover from the
condition.

To identify the memory leak caused by this vulnerability, issue the
"show dlsw peers | include FST.*DISCONN" command; a monotonically
increasing list of FST peers that remain in the DISCONN state indicates
that memory is being held, as shown in the following example:

    Router> show dlsw peers | include FST.*DISCONN
    FST 176.74.146.194  DISCONN          1         0  prom      0    -   -        -
    FST 9.180.128.186   DISCONN          1         0  prom      0    -   -        -
    FST 139.71.105.39   DISCONN          1         0  prom      0    -   -        -
    FST 138.150.39.18   DISCONN          1         0  prom      0    -   -        -
    FST 253.240.220.167 DISCONN          1         0  prom      0    -   -        -
    FST 252.186.119.224 DISCONN          1         0  prom      0    -   -        -
    FST 41.255.172.252  DISCONN          1         0  prom      0    -   -        -
    ! --- Output truncated
    Router>

Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to determine
exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Additionally, the Cisco IOS Software Checker is available on
the Cisco Security Intelligence Operations (SIO) portal at
http://tools.cisco.com/security/center/selectIOSVersion.x. It provides
several features for checking which Security Advisories affect specified
versions of Cisco IOS Software.

Cisco IOS Software
+-----------------

Each row of the following Cisco IOS Software table corresponds to a
Cisco IOS Software train. If a particular train is vulnerable, the
earliest releases that contain the fix are listed in the First Fixed
Release For This Advisory column. The First Fixed Release for All
Advisories in the September 2011 Bundled Publication column lists the
earliest possible releases that correct all the published
vulnerabilities in the Cisco IOS Software Security Advisory bundled
publication. Cisco recommends upgrading to the latest available
release, where possible.

+------------------------------------------------------------+
|   Major    |         Availability of Repaired Releases     |
|  Release   |                                               |
|------------+-----------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.0-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 12.0-based releases                  |
|------------------------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.1-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.1E      | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.2-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 12.2       | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     |                       |
|            | fixed in Release 12.4 |                       |
| 12.2B      |                       | Vulnerable; first     |
|            | Releases up to and    | fixed in Release 12.4 |
|            | including 12.2(2)B7   |                       |
|            | are not vulnerable.   |                       |
|------------+-----------------------+-----------------------|
| 12.2BC     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2BW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     |                       |
|            | fixed in Release      |                       |
|            | 12.2SB                | Vulnerable; first     |
| 12.2BX     |                       | fixed in Release      |
|            | Releases up to and    | 12.2SB                |
|            | including 12.2(15)BX  |                       |
|            | are not vulnerable.   |                       |
|------------+-----------------------+-----------------------|
| 12.2BY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2BZ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2CX     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2CY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2CZ     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2DA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2DD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2DX     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2EU     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Releases up to and    |
| 12.2EW     | Not vulnerable        | including 12.2(20)EW4 |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2EWA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2EX     | Not vulnerable        | 12.2(55)EX3           |
|------------+-----------------------+-----------------------|
| 12.2EY     | Not vulnerable        | 12.2(58)EY            |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2EZ     | Not vulnerable        | to any release in     |
|            |                       | 15.0SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2FX     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2FY     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2EX                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2FZ     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; migrate   |
| 12.2IRA    | to any release in     | to any release in     |
|            | 12.2IRG               | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; migrate   |
| 12.2IRB    | to any release in     | to any release in     |
|            | 12.2IRG               | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; migrate   |
| 12.2IRC    | to any release in     | to any release in     |
|            | 12.2IRG               | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IRD    | 12.2(33)IRD1          | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IRE    | 12.2(33)IRE3          | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; migrate   |
| 12.2IRF    | to any release in     | to any release in     |
|            | 12.2IRG               | 12.2IRG               |
|------------+-----------------------+-----------------------|
| 12.2IRG    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXA    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXB    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXC    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXD    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXE    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXF    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXG    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXH    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2JA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2JK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2MB     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2MC     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2MRA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SRD               |
|------------+-----------------------+-----------------------|
| 12.2MRB    | Not vulnerable        | 12.2(33)MRB5          |
|------------+-----------------------+-----------------------|
|            | Releases prior to     | Releases prior to     |
|            | 12.2(30)S are         | 12.2(30)S are         |
|            | vulnerable; Releases  | vulnerable; Releases  |
| 12.2S      | 12.2(30)S and later   | 12.2(30)S and later   |
|            | are not vulnerable.   | are not vulnerable.   |
|            | First fixed in        | First fixed in        |
|            | Release 12.2SB        | Release 12.2SB        |
|------------+-----------------------+-----------------------|
|            | 12.2(31)SB20          | 12.2(31)SB2012.2(33)  |
| 12.2SB     |                       | SB10                  |
|            | 12.2(33)SB10          |                       |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SBC    | fixed in Release      | fixed in Release      |
|            | 12.2SB                | 12.2SB                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SCA    | fixed in Release      | fixed in Release      |
|            | 12.2SCC               | 12.2SCC               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SCB    | fixed in Release      | fixed in Release      |
|            | 12.2SCC               | 12.2SCC               |
|------------+-----------------------+-----------------------|
| 12.2SCC    | 12.2(33)SCC7          | 12.2(33)SCC7          |
|------------+-----------------------+-----------------------|
|            | 12.2(33)SCD6          |                       |
| 12.2SCD    |                       | 12.2(33)SCD6          |
|            | 12.2(33)SCD7          |                       |
|------------+-----------------------+-----------------------|
|            | 12.2(33)SCE1          | 12.2(33)SCE112.2(33)  |
| 12.2SCE    |                       | SCE2                  |
|            | 12.2(33)SCE2          |                       |
|------------+-----------------------+-----------------------|
| 12.2SCF    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SE     | Not vulnerable        | 12.2(55)SE312.2(58)SE |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SEA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SEB    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SEC    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SED    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SEE    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SEF    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(25)SEG4 are      |
|            |                       | vulnerable; Releases  |
| 12.2SEG    | Not vulnerable        | 12.2(25)SEG4 and      |
|            |                       | later are not         |
|            |                       | vulnerable. First     |
|            |                       | fixed in Release      |
|            |                       | 12.2EX                |
|------------+-----------------------+-----------------------|
|            | Releases prior to     | Releases prior to     |
|            | 12.2(40)SG are        | 12.2(53)SG4 are       |
| 12.2SG     | vulnerable; Releases  | vulnerable; Releases  |
|            | 12.2(40)SG and later  | 12.2(53)SG4 and later |
|            | are not vulnerable.   | are not vulnerable.   |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2SGA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2SL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2SM     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2SO     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SQ     | Not vulnerable        | 12.2(50)SQ3           |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SRA    | fixed in Release      | fixed in Release      |
|            | 12.2SRD               | 12.2SRD               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SRB    | fixed in Release      | fixed in Release      |
|            | 12.2SRD               | 12.2SRD               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SRC    | fixed in Release      | fixed in Release      |
|            | 12.2SRD               | 12.2SRD               |
|------------+-----------------------+-----------------------|
| 12.2SRD    | 12.2(33)SRD6          | 12.2(33)SRD6          |
|------------+-----------------------+-----------------------|
| 12.2SRE    | 12.2(33)SRE3          | 12.2(33)SRE4          |
|------------+-----------------------+-----------------------|
| 12.2STE    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SU     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Releases prior to     | Releases prior to     |
|            | 12.2(29a)SV are       | 12.2(29a)SV are       |
|            | vulnerable; Releases  | vulnerable; Releases  |
| 12.2SV     | 12.2(29a)SV and later | 12.2(29a)SV and later |
|            | are not vulnerable.   | are not vulnerable.   |
|            | Migrate to any        | Migrate to any        |
|            | release in 12.2SVD    | release in 12.2SVD    |
|------------+-----------------------+-----------------------|
| 12.2SVA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVD    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVE    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Releases prior to     | Vulnerable; contact   |
|            | 12.2(25)SW12 are      | your support          |
|            | vulnerable; Releases  | organization per the  |
| 12.2SW     | 12.2(25)SW12 and      | instructions in the   |
|            | later are not         | Obtaining Fixed       |
|            | vulnerable.           | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SX     | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SXA    | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SXB    | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SXD    | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SXE    | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
| 12.2SXF    | 12.2(18)SXF17b        | 12.2(18)SXF17b        |
|------------+-----------------------+-----------------------|
| 12.2SXH    | 12.2(33)SXH8a         | 12.2(33)SXH8a         |
|------------+-----------------------+-----------------------|
| 12.2SXI    | 12.2(33)SXI6          | 12.2(33)SXI6          |
|------------+-----------------------+-----------------------|
| 12.2SXJ    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SY     | 12.2(50)SY            | 12.2(50)SY            |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SZ     | fixed in Release      | fixed in Release      |
|            | 12.2SB                | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2T      | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2TPC    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2XA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XB     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2XC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XF     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XG     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XH     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XI     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XJ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XM     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XN     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XNA    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XNB    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XNC    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XND    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XNE    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XNF    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(54)XO are        |
| 12.2XO     | Not vulnerable        | vulnerable; Releases  |
|            |                       | 12.2(54)XO and later  |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
| 12.2XQ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XR     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XS     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XT     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XU     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XV     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Releases prior to     |                       |
|            | 12.2(4)YA8 are        |                       |
|            | vulnerable; Releases  | Vulnerable; first     |
| 12.2YA     | 12.2(4)YA8 and later  | fixed in Release 12.4 |
|            | are not vulnerable.   |                       |
|            | First fixed in        |                       |
|            | Release 12.4          |                       |
|------------+-----------------------+-----------------------|
| 12.2YB     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YF     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YG     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YH     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            | Releases prior to     | your support          |
|            | 12.2(8)YJ1 are        | organization per the  |
| 12.2YJ     | vulnerable; Releases  | instructions in the   |
|            | 12.2(8)YJ1 and later  | Obtaining Fixed       |
|            | are not vulnerable.   | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YL     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YM     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YN     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YO     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YP     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YQ     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YR     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YS     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YT     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YU     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            | Releases prior to     | your support          |
|            | 12.2(11)YV1 are       | organization per the  |
| 12.2YV     | vulnerable; Releases  | instructions in the   |
|            | 12.2(11)YV1 and later | Obtaining Fixed       |
|            | are not vulnerable.   | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YW     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YX     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YY     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YZ     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2ZA     | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2ZB     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2ZC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZE     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZF     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZG     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Releases prior to     |                       |
|            | 12.2(13)ZH6 are       |                       |
|            | vulnerable; Releases  | Vulnerable; first     |
| 12.2ZH     | 12.2(13)ZH6 and later | fixed in Release 12.4 |
|            | are not vulnerable.   |                       |
|            | First fixed in        |                       |
|            | Release 12.4          |                       |
|------------+-----------------------+-----------------------|
| 12.2ZJ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2ZL     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2ZP     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2ZU     | fixed in Release      | fixed in Release      |
|            | 12.2SXH               | 12.2SXH               |
|------------+-----------------------+-----------------------|
| 12.2ZX     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2ZY     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2ZYA    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.3-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 12.3       | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3B      | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.3BC     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SCC               |
|------------+-----------------------+-----------------------|
| 12.3BW     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3JA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3JEA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3JEB    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3JEC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3JED    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Releases up to and    | Releases up to and    |
|            | including 12.3(2)JK3  | including 12.3(2)JK3  |
|            | are not vulnerable.   | are not vulnerable.   |
| 12.3JK     | Releases 12.3(8)JK1   | Releases 12.3(8)JK1   |
|            | and later are not     | and later are not     |
|            | vulnerable. First     | vulnerable. First     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3JL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3JX     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3T      | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            | Releases up to and    | your support          |
|            | including 12.3(4)     | organization per the  |
| 12.3TPC    | TPC11a are not        | instructions in the   |
|            | vulnerable.           | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.3VA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Releases prior to     |                       |
|            | 12.3(2)XA7 are        |                       |
|            | vulnerable; Releases  | Vulnerable; first     |
| 12.3XA     | 12.3(2)XA7 and later  | fixed in Release 12.4 |
|            | are not vulnerable.   |                       |
|            | First fixed in        |                       |
|            | Release 12.4          |                       |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3XB     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.3XC     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3XD     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3XE     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3XF     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.3XG     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3XI     | fixed in Release      | fixed in Release      |
|            | 12.2SB                | 12.2SB                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3XJ     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.3XK     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3XL     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.3XQ     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3XR     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3XS     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3XU     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3XW     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.3XX     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3XY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3XZ     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3YA     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3YD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3YF     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3YG     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3YH     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3YI     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3YJ     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.3YK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3YM     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3YQ     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     |                       |
|            | fixed in Release      |                       |
|            | 12.4T                 | Vulnerable; first     |
| 12.3YS     |                       | fixed in Release      |
|            | Releases up to and    | 12.4T                 |
|            | including 12.3(11)YS1 |                       |
|            | are not vulnerable.   |                       |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3YT     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3YU     | fixed in Release      | fixed in Release      |
|            | 12.4XB                | 12.4XB                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; first     |
| 12.3YX     | to any release in     | fixed in Release      |
|            | 12.4XR                | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3YZ     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3ZA     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.4-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 12.4       | 12.4(25e)             | 12.4(25f)             |
|------------+-----------------------+-----------------------|
| 12.4GC     | 12.4(24)GC4           | 12.4(24)GC4           |
|------------+-----------------------+-----------------------|
| 12.4JA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JAX    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JDA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JDC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JHA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JHB    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JHC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JMA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JMB    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
|            |                       | to any release in     |
|            |                       | 12.4JA                |
| 12.4JX     | Not vulnerable        |                       |
|            |                       | Releases up to and    |
|            |                       | including 12.4(21a)JX |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
| 12.4JY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4MD     | Not vulnerable        | 12.4(24)MD6 on        |
|            |                       | 28-Oct-2011           |
|------------+-----------------------+-----------------------|
| 12.4MDA    | Not vulnerable        | 12.4(24)MDA7          |
|------------+-----------------------+-----------------------|
| 12.4MDB    | Not vulnerable        | 12.4(24)MDB3          |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.4MR     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.4MRA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.4MRB    | Not vulnerable        | fixed in Release      |
|            |                       | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4SW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | 12.4(15)T15           | 12.4(15)T16           |
| 12.4T      |                       |                       |
|            | 12.4(24)T5            | 12.4(24)T6            |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XA     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4XB     | 12.4(2)XB12           | 12.4(2)XB12           |
|------------+-----------------------+-----------------------|
| 12.4XC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XD     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4XE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.4XF     | Not vulnerable        | fixed in Release      |
|            |                       | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XG     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4XJ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4XK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4XL     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Releases up to and    |                       |
|            | including 12.4(15)XM  |                       |
|            | are not vulnerable.   |                       |
|            |                       | Vulnerable; first     |
| 12.4XM     | Releases 12.4(15)XM3  | fixed in Release      |
|            | and later are not     | 12.4T                 |
|            | vulnerable. First     |                       |
|            | fixed in Release      |                       |
|            | 12.4T                 |                       |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4XN     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4XP     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.4XQ     | Not vulnerable        | fixed in Release      |
|            |                       | 12.4T                 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.4XR     | Not vulnerable        | fixed in Release      |
|            |                       | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XT     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4XV     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XW     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XY     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XZ     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4YA     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4YB     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.4YD     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; fixed in  |
|            |                       | 12.4(22)YE6 on        |
| 12.4YE     | Not vulnerable        | 30-Sept-2011; 12.4    |
|            |                       | (24)YE7 available on  |
|            |                       | 17-Oct-2011           |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.4YG     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.0-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
|            | 15.0(1)M4             |                       |
| 15.0M      |                       | 15.0(1)M7             |
|            | 15.0(1)M5a            |                       |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.0MR     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.0MRA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | 15.0(1)S3a            |                       |
|            |                       | 15.0(1)S4             |
|            | 15.0(1)S4             |                       |
| 15.0S      |                       | Cisco IOS XE devices: |
|            | Cisco IOS XE devices: | Please see Cisco      |
|            | Please see Cisco      | IOS-XE Software       |
|            | IOS-XE Software       | Availability          |
|            | Availability          |                       |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.0SA     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 15.0SE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Cisco IOS XE devices: | Cisco IOS XE devices: |
| 15.0SG     | Please see Cisco      | Please see Cisco      |
|            | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 15.0XA     | fixed in Release      | fixed in Release      |
|            | 15.1T                 | 15.1T                 |
|------------+-----------------------+-----------------------|
|            | Cisco IOS XE devices: | Cisco IOS XE devices: |
| 15.0XO     | Please see Cisco      | Please see Cisco      |
|            | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.1-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.1EY     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 15.1GC     | Not vulnerable        | fixed in Release      |
|            |                       | 15.1T                 |
|------------+-----------------------+-----------------------|
| 15.1M      | Not vulnerable        | 15.1(4)M2; Available  |
|            |                       | on 30-SEP-11          |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.1MR     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | 15.1(1)S1             | 15.1(2)S2             |
|            |                       |                       |
|            | 15.1(2)S              | 15.1(3)S              |
| 15.1S      |                       |                       |
|            | Cisco IOS XE devices: | Cisco IOS XE devices: |
|            | Please see Cisco      | Please see Cisco      |
|            | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | 15.1(1)T3             |                       |
|            |                       |                       |
|            | 15.1(2)T2             | 15.1(2)T4 15.1(1)T4   |
| 15.1T      |                       | on 8-Dec-2011         |
|            | 15.1(2)T2a            |                       |
|            |                       |                       |
|            | 15.1(3)T              |                       |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 15.1XB     | fixed in Release      | fixed in Release      |
|            | 15.1T                 | 15.1T                 |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.2-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 15.2-based releases                  |
+------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

Cisco IOS XE Software is affected by the vulnerability disclosed in
this document.

+------------------------------------------------------------+
|  Cisco   |   First    |    First Fixed Release for All     |
|  IOS XE  |   Fixed    |  Advisories in the September 2011  |
| Release  |  Release   |        Bundled Publication         |
|----------+------------+------------------------------------|
| 2.1.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.2.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.3.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.4.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.5.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.6.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 3.1.xS   | 3.1.3S     | Vulnerable; migrate to 3.3.2S or   |
|          |            | later                              |
|----------+------------+------------------------------------|
| 3.1.xSG  | Not        | Vulnerable; migrate to 3.2.0SG or  |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 3.2.xS   | 3.2.1S     | Vulnerable; migrate to 3.3.2S or   |
|          |            | later                              |
|----------+------------+------------------------------------|
| 3.2.xSG  | Not        | Not vulnerable                     |
|          | vulnerable |                                    |
|----------+------------+------------------------------------|
| 3.3.xS   | Not        | 3.3.2S                             |
|          | vulnerable |                                    |
|----------+------------+------------------------------------|
| 3.4.xS   | Not        | Not vulnerable                     |
|          | vulnerable |                                    |
+------------------------------------------------------------+

For mapping of Cisco IOS XE to Cisco IOS releases, please refer to
the Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and
Cisco IOS XE 3SG Release Notes.

Cisco IOS XR Software
+--------------------

Cisco IOS XR Software is not affected by any of the vulnerabilities
in the September 2011 bundled publication.

Workarounds
===========

This vulnerability can be mitigated by using Control Plane Policing
(CoPP) to only allow IP Protocol 91 packets sent by valid peers.

Mitigation techniques that can be deployed on Cisco devices within
the network are available in the Cisco Applied Mitigation Bulletin
companion document for this advisory:

http://www.cisco.com/warp/public/707/cisco-amb-20110928-dlsw.shtml

Control Plane Policing
+---------------------

Control Plane Policing (CoPP) can be used to block untrusted IP
Protocol 91 packets sent to the affected device. Cisco IOS Software
Releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the
CoPP feature. CoPP may be configured on a device to protect the
management and control planes to minimize the risk and effectiveness
of direct infrastructure attacks by explicitly permitting, and if
configured, rate-limiting only authorized traffic that is sent to
infrastructure devices in accordance with existing security policies
and configurations. The following example, which uses 192.168.100.1
to represent a trusted host, can be adapted to your network.

    !-- Deny FST traffic on IP protocol 91 from trusted
    !-- hosts to all IP addresses configured on all interfaces of the affected device
    !-- so that it will be allowed by the CoPP feature

    access-list 111 deny 91 host 192.168.100.1 any

    !-- Permit all other FST traffic on IP protocol 91
    !-- sent to all IP addresses configured on all interfaces of the affected
    !-- device so that it will be policed and dropped by the CoPP feature

    access-list 111 permit 91 any any

    !-- Permit (Police or Drop)/Deny (Allow) all other Layer3
    !-- and Layer4 traffic in accordance with existing security
    !-- policies and configurations for traffic that is authorized
    !-- to be sent to infrastructure devices

    !-- Create a Class-Map for traffic to be policed by
    !-- the CoPP feature

    class-map match-all drop-fst-91-class
      match access-group 111

    !-- Create a Policy-Map that will be applied to the
    !-- Control-Plane of the device.

    policy-map input-CoPP-policy
      class drop-fst-91-class
        drop


    !-- Apply the Policy-Map to the Control-Plane of the
    !-- device

    control-plane
      service-policy input input-CoPP-policy


In the above CoPP example, the access control list entries (ACEs)
that match the potential exploit packets with the "permit" action
result in these packets being discarded by the policy map "drop"
function, while packets that match the deny action (not shown) are
not affected by the policy-map drop function. Note that in the 12.2S
and 12.0S Cisco IOS trains the policy-map syntax is different, as
shown in the following example:

    policy-map input-CoPP-policy
      class drop-fst-91-class
        police 32000 1500 1500 conform-action drop exceed-action drop

Additional information on the CoPP feature is available at: Control
Plane Policing Implementation Best Practices.

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature
sets they have purchased. By installing, downloading, accessing
or otherwise using such software upgrades, customers agree to be
bound by the terms of Cisco's software license terms found at
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered during Cisco internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20110323-dlsw.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+------------------------------------------------------------+
| Revision 1.0 | 2011-September-28 | Initial public release  |
+------------------------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities
in Cisco products, obtaining assistance with security
incidents, and registering to receive security information
from Cisco, is available on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
This includes instructions for press inquiries regarding
Cisco security notices. All Cisco security advisories are available at
http://www.cisco.com/go/psirt.

+--------------------------------------------------------------------
Copyright 2010-2011 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAk6Cp2EACgkQQXnnBKKRMNDlUwD/RunFKu5OItJXD8gTi5PtkxMz
CoIx3+/EIJjznWKJnBoA/3bh8zYaW5Et3pvnmF9Hm2nImvFT1jMZOIv1zWfAMsXX
=oqzZ
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 28 11:00:00 2011
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 28 Sep 2011 12:00:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software IP Service Level
 Agreement Vulnerability 
Message-ID: <2011092812001.ipsla@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cisco Security Advisory: Cisco IOS Software IP Service Level
Agreement Vulnerability

Advisory ID: cisco-sa-20110928-ipsla

Revision 1.0

For Public Release 2011 September 28 1600 UTC (GMT)

+---------------------------------------------------------------------

Summary
=======

The Cisco IOS IP Service Level Agreement (IP SLA) feature contains a
denial of service (DoS) vulnerability. The vulnerability is triggered
when malformed UDP packets are sent to a vulnerable device. The
vulnerable UDP port numbers depend on the device configuration.
Default ports are not used for the vulnerable UDP IP SLA operation or
for the UDP responder ports.

Cisco has released free software updates that address this
vulnerability.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110928-ipsla.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory
bundled publication includes ten Cisco Security Advisories. Nine of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the Cisco IOS Software releases that
correct the vulnerability or vulnerabilities detailed in the advisory as
well as the Cisco IOS Software releases that correct all vulnerabilities
in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Security Advisory Bundled Publication" at the
following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Affected Products
=================

Vulnerable Products
+------------------

Cisco devices that are running Cisco IOS Software are vulnerable when
they are configured for IP SLA, either as responders or as
originators of vulnerable IP SLA operations.

To determine the Cisco IOS Software release that is running on a Cisco
product, administrators can log in to the device and issue the "show
version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or "Cisco
IOS Software." The image name displays in parentheses, followed by
"Version" and the Cisco IOS Software release name. Other Cisco devices
do not have the "show version" command or may provide different output.

The following example shows output from a device that runs a Cisco
IOS Software image:

    Router> show version
    Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2009 by Cisco Systems, Inc.
    Compiled Wed 02-Dec-09 17:17 by prod_rel_team


    !--- output truncated


Additional information about Cisco IOS Software release naming
conventions is available in the white paper Cisco IOS and NX-OS
Software Reference Guide available at:

http://www.cisco.com/web/about/security/intelligence/ios-ref.html

Products Confirmed Not Vulnerable
+--------------------------------

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

IP SLA is an embedded agent in Cisco IOS Software designed to measure
and monitor common network performance metrics like jitter, latency
(delay), and packet loss.

The vulnerability that is described in this document is triggered by
malformed UDP packets triggered by malformed IP SLA packets sent to
the vulnerable device and port. A vulnerable device can be an IP SLA
responder or the source device of a vulnerable IP SLA operation.

This vulnerability is documented in Cisco bug ID CSCtk67073 and has been
assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2011-3272.

Vulnerable IP SLA Responder Configurations
+-----------------------------------------

A device configured either as an IP SLA general responder or a
permanent IP SLA UDP responder is vulnerable.

The general responder processes IP SLA control protocol packets on
UDP port 1967 and then may dynamically open vulnerable UDP ports
according to the IP SLA operations requested using the control
protocol. The configuration for a general responder is as follows:

    ip sla responder

The IP SLA UDP permanent responder is also vulnerable. An example
configuration is as follows:

    ip sla responder udp-echo port 300

There is no default UDP port number for the UDP permanent responder

Alternatively, both the general responder and the permanent responder
can be identified with the "show ip sla responder" command. The general
responder is vulnerable when it has been enabled. The permanent
responder is vulnerable only when it has been enabled and the "udpEcho
Responder" is present. In the Following example, the general responder
is not vulnerable because it has not been enabled but the permanent
responder is vulnerable because it has been enabled with a UDP echo
responder:

    Router# show ip sla responder
            General IP SLA Responder on Control port 1967
    General IP SLA Responder is: Disabled

            Permanent Port IP SLA Responder
    Permanent Port IP SLA Responder is: Enabled

    udpEcho Responder: 
      IP Address             Port
      0.0.0.0                 300

Vulnerable IP SLA Source Device Configurations
+---------------------------------------------

An IP SLA source device is a Cisco IOS device that has at least one
IP SLA operation configured. To be vulnerable a probe originator
needs to have at least one scheduled probe that uses either of the
following IP SLA operations:

  * udp-jitter probe
  * udp-echo

A vulnerable IP SLA source device configuration includes all the
following commands:

  * An "ip sla" global configuration command to define an IP SLA
    operation

  * Either a "udp-echo" or a "udp-jitter" IP SLA configuration command

  * An "ip sla schedule" global configuration command that activates
    one of the probes that uses a vulnerable IP SLA operation

The following examples show a source device that is configured for IP
SLA UDP echo and UDP jitter probes:

    ip sla 201
     udp-echo 192.168.134.21 201
    ip sla schedule 201 start-time now

    ip sla 301
     udp-jitter 192.168.134.121 122
    ip sla schedule 301 start-time now

The destination UDP ports for the probes need to be configured. If
the source UDP port is not configured an available port number will
be used when the probe is started. A device that originates a
vulnerable operation will be vulnerable on the source UDP ports of
the probe and a responder will be vulnerable on the destination UDP
port used for the probe.

IP SLA probes can be configured using Simple Network Management
Protocol (SNMP). In that case, by default, the "show running
configuration" command will not include the IP SLA probe
configuration. The "show ip sla configuration" command can be used to
verify whether a probe has been configured either by the command line
or via SNMP.

    Router# show ip sla configuration | include operation
    Type of operation to perform: udp-jitter
    Type of operation to perform: udp-echo

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss


* CSCtk67073 ("IP SLA Memory Corruption Vulnerability")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


Impact
======

Successful exploitation of the vulnerability described in this
document may result in the reload of a vulnerable device. Repeated
exploitation could result in a DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to determine
exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Additionally, the Cisco IOS Software Checker is available on
the Cisco Security Intelligence Operations (SIO) portal at
http://tools.cisco.com/security/center/selectIOSVersion.x. It provides
several features for checking which Security Advisories affect specified
versions of Cisco IOS Software.

Cisco IOS Software
+-----------------

Each row of the following Cisco IOS Software table corresponds to a
Cisco IOS Software train. If a particular train is vulnerable, the
earliest releases that contain the fix are listed in the First Fixed
Release For This Advisory column. The First Fixed Release for All
Advisories in the September 2011 Bundled Publication column lists the
earliest possible releases that correct all the published
vulnerabilities in the Cisco IOS Software Security Advisory bundled
publication. Cisco recommends upgrading to the latest available
release, where possible.

+------------------------------------------------------------+
|   Major    |         Availability of Repaired Releases     |
|  Release   |                                               |
|------------+-----------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 12.0-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 12.0-based releases                  |
|------------------------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 12.1-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 12.1-based releases                  |
|------------------------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 12.2-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 12.2-based releases                  |
|------------------------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 12.3-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 12.3-based releases                  |
|------------------------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 12.4-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 12.4-based releases                  |
|------------------------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 15.0-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 15.0-based releases                  |
|------------------------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 15.1-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 15.1EY     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            | Vulnerable;      | Vulnerable; first fixed in |
| 15.1GC     | first fixed in   | Release 15.1T              |
|            | Release 15.1T    |                            |
|------------+------------------+----------------------------|
| 15.1M      | Not vulnerable   | 15.1(4)M2; Available on    |
|            |                  | 30-SEP-11                  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 15.1MR     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            | 15.1(2)S         | 15.1(2)S2                  |
|            |                  |                            |
|            | Cisco IOS XE     | 15.1(3)S                   |
| 15.1S      | devices: Please  |                            |
|            | see Cisco IOS-XE | Cisco IOS XE devices:      |
|            | Software         | Please see Cisco IOS-XE    |
|            | Availability     | Software Availability      |
|------------+------------------+----------------------------|
|            | 15.1(1)T3        | 15.1(1)T4; Available on    |
|            |                  | 08-DEC-11                  |
| 15.1T      | 15.1(2)T4        |                            |
|            |                  | 15.1(2)T4                  |
|            | 15.1(3)T2        |                            |
|            |                  | 15.1(3)T2                  |
|------------+------------------+----------------------------|
|            | Vulnerable;      | Vulnerable; first fixed in |
| 15.1XB     | first fixed in   | Release 15.1T              |
|            | Release 15.1T    |                            |
|------------+------------------+----------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 15.2-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 15.2-based releases                  |
+------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

Cisco IOS XE Software is affected by the vulnerability disclosed in
this document.

+------------------------------------------------------------+
|  Cisco  |   First Fixed   |  First Fixed Release for All   |
| IOS XE  |     Release     |  Advisories in the September   |
| Release |                 |    2011 Bundled Publication    |
|---------+-----------------+--------------------------------|
|         | Vulnerable;     | Vulnerable; migrate to 3.3.2S  |
| 2.1.x   | migrate to      | or later                       |
|         | 3.3.2S or later |                                |
|---------+-----------------+--------------------------------|
|         | Vulnerable;     | Vulnerable; migrate to 3.3.2S  |
| 2.2.x   | migrate to      | or later                       |
|         | 3.3.2S or later |                                |
|---------+-----------------+--------------------------------|
|         | Vulnerable;     | Vulnerable; migrate to 3.3.2S  |
| 2.3.x   | migrate to      | or later                       |
|         | 3.3.2S or later |                                |
|---------+-----------------+--------------------------------|
|         | Vulnerable;     | Vulnerable; migrate to 3.3.2S  |
| 2.4.x   | migrate to      | or later                       |
|         | 3.3.2S or later |                                |
|---------+-----------------+--------------------------------|
|         | Vulnerable;     | Vulnerable; migrate to 3.3.2S  |
| 2.5.x   | migrate to      | or later                       |
|         | 3.3.2S or later |                                |
|---------+-----------------+--------------------------------|
|         | Vulnerable;     | Vulnerable; migrate to 3.3.2S  |
| 2.6.x   | migrate to      | or later                       |
|         | 3.3.2S or later |                                |
|---------+-----------------+--------------------------------|
|         | Vulnerable;     | Vulnerable; migrate to 3.3.2S  |
| 3.1.xS  | migrate to      | or later                       |
|         | 3.3.2S or later |                                |
|---------+-----------------+--------------------------------|
|         | Vulnerable;     |                                |
| 3.1.xSG | migrate to      | Vulnerable; migrate to 3.2.0SG |
|         | 3.2.0SG or      | or later                       |
|         | later           |                                |
|---------+-----------------+--------------------------------|
|         | Vulnerable;     | Vulnerable; migrate to 3.3.2S  |
| 3.2.xS  | migrate to      | or later                       |
|         | 3.3.2S or later |                                |
|---------+-----------------+--------------------------------|
| 3.2.xSG | Not vulnerable  | Not vulnerable                 |
|---------+-----------------+--------------------------------|
| 3.3.xS  | 3.3.0S          | 3.3.2S                         |
|---------+-----------------+--------------------------------|
| 3.4.xS  | Not vulnerable  | Not vulnerable                 |
+------------------------------------------------------------+

For mapping of Cisco IOS XE to Cisco IOS releases, please refer to
the Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and
Cisco IOS XE 3SG Release Notes.

Cisco IOS XR Software
+--------------------

Cisco IOS XR Software is not affected by any of the vulnerabilities
in the September 2011 bundled publication.

Workarounds
===========

There are no workarounds for this vulnerability, but there are
mitigations that can be deployed on a general IP SLA responder to
reduce the exposure to this vulnerability.

General IP SLA Responder Mitigation
+----------------------------------

For devices that are configured as general responders, a mitigation
is to restrict IP SLA control packets on UDP port 1967 that are
addressed to the vulnerable device to permit only trusted probe
originators to open UDP ports that could be exploited. This can be
accomplished using techniques such as Infrastructure Access list or
Control Plane Protection.

For devices configured as general responders, mitigation techniques
that can be deployed on Cisco devices within the network are
available in the Cisco Applied Mitigation Bulletin companion document
for this advisory:

http://www.cisco.com/warp/public/707/cisco-amb-20110928-ipsla.shtml

IP SLA Permanent Responder Mitigation
+------------------------------------

For the permanent responder, the mitigation is to filter UDP packets
addressed to the configured UDP port of each permanent responder to
permit packets from the IP addresses of trusted devices.

IP SLA Source Devices Mitigation
+-------------------------------

For IP SLA source devices, a mitigation is to allow only UDP packets
from trusted devices (that is, devices that are the target of IP SLA
operations).

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature
sets they have purchased. By installing, downloading, accessing
or otherwise using such software upgrades, customers agree to be
bound by the terms of Cisco's software license terms found at
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found during Cisco internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-ipsla.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+------------------------------------------------------------+
| Revision 1.0   | 2011-Sep-28   | Initial public release    |
+------------------------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities
in Cisco products, obtaining assistance with security
incidents, and registering to receive security information
from Cisco, is available on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
This includes instructions for press inquiries regarding
Cisco security notices. All Cisco security advisories are available at
http://www.cisco.com/ go/psirt.

+--------------------------------------------------------------------
Copyright 2010-2011 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAk6Cp2MACgkQQXnnBKKRMNBZ6gD/WbLQXIuIcQjySn9TOSycPflx
p7H07864wibshk3qznsA/37viRZKYBrkXc+mgT5C5kIs9Elx3l+L5v0EDJ1K+jZI
=OF08
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 28 11:00:00 2011
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 28 Sep 2011 12:00:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software IPv6 Denial of Service
 Vulnerability 
Message-ID: <2011092812001.ipv6@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cisco Security Advisory: Cisco IOS Software IPv6 Denial of Service
Vulnerability

Advisory ID: cisco-sa-20110928-ipv6

Revision 1.0

For Public Release 2011 September 28 1600 UTC (GMT)

+--------------------------------------------------------------------

Summary
=======

Cisco IOS Software contains a vulnerability in the IP version 6
(IPv6) protocol stack implementation that could allow an
unauthenticated, remote attacker to cause a reload of an affected
device that has IPv6 enabled. The vulnerability may be triggered when
the device processes a malformed IPv6 packet.

Cisco has released free software updates that address this
vulnerability. There are no workarounds to mitigate this
vulnerability.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110928-ipv6.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory
bundled publication includes ten Cisco Security Advisories. Nine of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the Cisco IOS Software releases that
correct the vulnerability or vulnerabilities detailed in the advisory as
well as the Cisco IOS Software releases that correct all vulnerabilities
in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Security Advisory Bundled Publication" at the
following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Affected Products
=================

This vulnerability affects devices that are running Cisco IOS
Software and configured for IPv6 operation. IPv6 is not enabled by
default in Cisco IOS Software.

Vulnerable Products
+------------------

Cisco devices that are running an affected version of Cisco IOS
Software and configured for IPv6 operation are vulnerable. A device
that is running Cisco IOS Software and that has IPv6 enabled will
show some interfaces with assigned IPv6 addresses when the "show ipv6
interface brief" command is executed.

The "show ipv6 interface brief" command will produce an error message
if the version of Cisco IOS Software in use does not support IPv6, or
will not show any interfaces with IPv6 address if IPv6 is disabled.
The system is not vulnerable in these scenarios.

Sample output of the "show ipv6 interface brief" command on a system
that is configured for IPv6 operation follows:

    router>show ipv6 interface brief
    FastEthernet0/0            [up/up]
        FE80::222:90FF:FEB0:1098
        2001:DB8:2:93::3
        200A:1::1
    FastEthernet0/1            [up/up]
        FE80::222:90FF:FEB0:1099
        2001:DB8:2:94::1
    Serial0/0/0                [down/down]
        unassigned
    Serial0/0/0.4              [down/down]
        unassigned
    Serial0/0/0.5              [down/down]
        unassigned
    Serial0/0/0.6              [down/down]
        unassigned

Alternatively, the IPv6 protocol is enabled if the interface
configuration command "ipv6 address <IPv6 address>" or "ipv6 enable"
is present in the configuration. Both may be present, as shown in the
vulnerable configuration in the following example shows:

    interface FastEthernet0/1
     ipv6 address 2001:0DB8:C18:1::/64 eui-64
    !
    interface FastEthernet0/2
     ipv6 enable

A device that is running Cisco IOS Software and that has IPv6 enabled
on a physical or logical interface is vulnerable even if ipv6
unicast-routing is globally disabled (that is, the device is not
routing IPv6 packets).

To determine the Cisco IOS Software release that is running on a Cisco
product, administrators can log in to the device and issue the "show
version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or "Cisco
IOS Software." The image name displays in parentheses, followed by
"Version" and the Cisco IOS Software release name. Other Cisco devices
do not have the "show version" command or may provide different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 15.0(1)M1 with an installed image name of
C3900-UNIVERSALK9-M:

    Router> show version
    Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2009 by Cisco Systems, Inc.
    Compiled Wed 02-Dec-09 17:17 by prod_rel_team

    !--- output truncated

Additional information about Cisco IOS Software release
naming conventions is available in the white paper Cisco
IOS and NX-OS Software Reference Guide available at
http://www.cisco.com/web/about/security/intelligence/ios-ref.html.

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS XR Software and Cisco IOS XE Software are not affected by
this vulnerability.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

IPv6, which was designed by the Internet Engineering Task Force
(IETF), is intended to replace the current version, IP Version 4
(IPv4).

A vulnerability exists when Cisco IOS Software processes IPv6
packets. An attacker could exploit this vulnerability by sending
malformed IPv6 packets to physical or logical interfaces that are
configured to process IPv6 traffic. Transit traffic cannot trigger
this vulnerability. Exploitation could cause an affected system to
reload.

This vulnerability is documented in Cisco bug ID CSCtj41194, and
has been assigned Common Vulnerabilities and Exposures (CVE) ID
CVE-2011-0944.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss


* CSCtj41194 ("Crafted IPv6 packet causes device reload")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


Impact
======

Successful exploitation of the vulnerability that is described in
this advisory may cause a reload of an affected device. Repeated
exploitation could result in a sustained denial of service condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to determine
exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Additionally, the Cisco IOS Software Checker is available on
the Cisco Security Intelligence Operations (SIO) portal at
http://tools.cisco.com/security/center/selectIOSVersion.x. It provides
several features for checking which Security Advisories affect specified
versions of Cisco IOS Software.

Cisco IOS Software
+-----------------

Each row of the following Cisco IOS Software table corresponds to a
Cisco IOS Software train. If a particular train is vulnerable, the
earliest releases that contain the fix are listed in the First Fixed
Release For This Advisory column. The First Fixed Release for All
Advisories in the September 2011 Bundled Publication column lists the
earliest possible releases that correct all the published
vulnerabilities in the Cisco IOS Software Security Advisory bundled
publication. Cisco recommends upgrading to the latest available
release, where possible.

+------------------------------------------------------------+
|   Major    |         Availability of Repaired Releases     |
|  Release   |                                               |
|------------+-----------------------------------------------|
|  Affected  |                    | First Fixed Release for  |
| 12.0-Based |    First Fixed     |  All Advisories in the   |
|  Releases  |      Release       |  September 2011 Bundled  |
|            |                    |       Publication        |
|------------------------------------------------------------|
| There are no affected 12.0 based releases                  |
|------------------------------------------------------------|
|  Affected  |                    | First Fixed Release for  |
| 12.1-Based |    First Fixed     |  All Advisories in the   |
|  Releases  |      Release       |  September 2011 Bundled  |
|            |                    |       Publication        |
|------------+--------------------+--------------------------|
| 12.1E      | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SXF       |
|------------+--------------------+--------------------------|
|  Affected  |                    | First Fixed Release for  |
| 12.2-Based |    First Fixed     |  All Advisories in the   |
|  Releases  |      Release       |  September 2011 Bundled  |
|            |                    |       Publication        |
|------------+--------------------+--------------------------|
| 12.2       | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
| 12.2B      | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
| 12.2BC     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
| 12.2BW     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2BX     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SB        |
|------------+--------------------+--------------------------|
| 12.2BY     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2BZ     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2CX     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
| 12.2CY     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2CZ     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SB        |
|------------+--------------------+--------------------------|
| 12.2DA     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2DD     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2DX     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2EU     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Releases up to and       |
| 12.2EW     | Not vulnerable     | including 12.2(20)EW4    |
|            |                    | are not vulnerable.      |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2EWA    | Not vulnerable     | the instructions in      |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2EX     | Not vulnerable     | 12.2(55)EX3              |
|------------+--------------------+--------------------------|
| 12.2EY     | Not vulnerable     | 12.2(58)EY               |
|------------+--------------------+--------------------------|
| 12.2EZ     | Not vulnerable     | Vulnerable; migrate to   |
|            |                    | any release in 15.0SE    |
|------------+--------------------+--------------------------|
| 12.2FX     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SE        |
|------------+--------------------+--------------------------|
| 12.2FY     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2EX        |
|------------+--------------------+--------------------------|
| 12.2FZ     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SE        |
|------------+--------------------+--------------------------|
| 12.2IRA    | Not vulnerable     | Vulnerable; migrate to   |
|            |                    | any release in 12.2IRG   |
|------------+--------------------+--------------------------|
| 12.2IRB    | Not vulnerable     | Vulnerable; migrate to   |
|            |                    | any release in 12.2IRG   |
|------------+--------------------+--------------------------|
| 12.2IRC    | Not vulnerable     | Vulnerable; migrate to   |
|            |                    | any release in 12.2IRG   |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2IRD    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2IRE    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2IRF    | Not vulnerable     | Vulnerable; migrate to   |
|            |                    | any release in 12.2IRG   |
|------------+--------------------+--------------------------|
| 12.2IRG    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2IXA    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2IXB    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2IXC    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2IXD    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2IXE    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2IXF    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2IXG    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2IXH    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2JA     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2JK     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2MB     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2MC     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
| 12.2MRA    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SRD       |
|------------+--------------------+--------------------------|
| 12.2MRB    | Not vulnerable     | 12.2(33)MRB5             |
|------------+--------------------+--------------------------|
|            |                    | Releases prior to 12.2   |
|            |                    | (30)S are vulnerable;    |
| 12.2S      | Not vulnerable     | Releases 12.2(30)S and   |
|            |                    | later are not            |
|            |                    | vulnerable. First fixed  |
|            |                    | in Release 12.2SB        |
|------------+--------------------+--------------------------|
| 12.2SB     | Not vulnerable     | 12.2(31)SB2012.2(33)SB10 |
|------------+--------------------+--------------------------|
| 12.2SBC    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SB        |
|------------+--------------------+--------------------------|
| 12.2SCA    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SCC       |
|------------+--------------------+--------------------------|
| 12.2SCB    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SCC       |
|------------+--------------------+--------------------------|
| 12.2SCC    | Not vulnerable     | 12.2(33)SCC7             |
|------------+--------------------+--------------------------|
| 12.2SCD    | Not vulnerable     | 12.2(33)SCD6             |
|------------+--------------------+--------------------------|
| 12.2SCE    | Not vulnerable     | 12.2(33)SCE112.2(33)SCE2 |
|------------+--------------------+--------------------------|
| 12.2SCF    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2SE     | Not vulnerable     | 12.2(55)SE312.2(58)SE    |
|------------+--------------------+--------------------------|
| 12.2SEA    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SE        |
|------------+--------------------+--------------------------|
| 12.2SEB    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SE        |
|------------+--------------------+--------------------------|
| 12.2SEC    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SE        |
|------------+--------------------+--------------------------|
| 12.2SED    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SE        |
|------------+--------------------+--------------------------|
| 12.2SEE    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SE        |
|------------+--------------------+--------------------------|
| 12.2SEF    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SE        |
|------------+--------------------+--------------------------|
|            |                    | Releases prior to 12.2   |
|            |                    | (25)SEG4 are vulnerable; |
| 12.2SEG    | Not vulnerable     | Releases 12.2(25)SEG4    |
|            |                    | and later are not        |
|            |                    | vulnerable. First fixed  |
|            |                    | in Release 12.2EX        |
|------------+--------------------+--------------------------|
|            |                    | Releases prior to 12.2   |
|            |                    | (53)SG4 are vulnerable;  |
| 12.2SG     | Not vulnerable     | Releases 12.2(53)SG4 and |
|            |                    | later are not            |
|            |                    | vulnerable.              |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2SGA    | Not vulnerable     | the instructions in      |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2SL     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2SM     | Not vulnerable     | the instructions in      |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2SO     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2SQ     | Not vulnerable     | 12.2(50)SQ3              |
|------------+--------------------+--------------------------|
| 12.2SRA    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SRD       |
|------------+--------------------+--------------------------|
| 12.2SRB    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SRD       |
|------------+--------------------+--------------------------|
| 12.2SRC    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SRD       |
|------------+--------------------+--------------------------|
| 12.2SRD    | Not vulnerable     | 12.2(33)SRD6             |
|------------+--------------------+--------------------------|
| 12.2SRE    | Not vulnerable     | 12.2(33)SRE4             |
|------------+--------------------+--------------------------|
| 12.2STE    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2SU     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
|            |                    | Releases prior to 12.2   |
|            |                    | (29a)SV are vulnerable;  |
| 12.2SV     | Not vulnerable     | Releases 12.2(29a)SV and |
|            |                    | later are not            |
|            |                    | vulnerable. Migrate to   |
|            |                    | any release in 12.2SVD   |
|------------+--------------------+--------------------------|
| 12.2SVA    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2SVC    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2SVD    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2SVE    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2SW     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2SX     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SXF       |
|------------+--------------------+--------------------------|
| 12.2SXA    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SXF       |
|------------+--------------------+--------------------------|
| 12.2SXB    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SXF       |
|------------+--------------------+--------------------------|
| 12.2SXD    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SXF       |
|------------+--------------------+--------------------------|
| 12.2SXE    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SXF       |
|------------+--------------------+--------------------------|
| 12.2SXF    | Not vulnerable     | 12.2(18)SXF17b           |
|------------+--------------------+--------------------------|
| 12.2SXH    | Not vulnerable     | 12.2(33)SXH8a            |
|------------+--------------------+--------------------------|
| 12.2SXI    | Not vulnerable     | 12.2(33)SXI6             |
|------------+--------------------+--------------------------|
| 12.2SXJ    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2SY     | Not vulnerable     | 12.2(50)SY               |
|------------+--------------------+--------------------------|
| 12.2SZ     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SB        |
|------------+--------------------+--------------------------|
| 12.2T      | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2TPC    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2XA     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XB     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
| 12.2XC     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XD     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XE     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XF     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XG     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XH     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XI     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XJ     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XK     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XL     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XM     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XN     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            | See Cisco IOS-XE   | See Cisco IOS-XE         |
| 12.2XNA    | Software           | Software Availability    |
|            | Availability       |                          |
|------------+--------------------+--------------------------|
|            | See Cisco IOS-XE   | See Cisco IOS-XE         |
| 12.2XNB    | Software           | Software Availability    |
|            | Availability       |                          |
|------------+--------------------+--------------------------|
|            | See Cisco IOS-XE   | See Cisco IOS-XE         |
| 12.2XNC    | Software           | Software Availability    |
|            | Availability       |                          |
|------------+--------------------+--------------------------|
|            | See Cisco IOS-XE   | See Cisco IOS-XE         |
| 12.2XND    | Software           | Software Availability    |
|            | Availability       |                          |
|------------+--------------------+--------------------------|
|            | See Cisco IOS-XE   | See Cisco IOS-XE         |
| 12.2XNE    | Software           | Software Availability    |
|            | Availability       |                          |
|------------+--------------------+--------------------------|
|            | See Cisco IOS-XE   | See Cisco IOS-XE         |
| 12.2XNF    | Software           | Software Availability    |
|            | Availability       |                          |
|------------+--------------------+--------------------------|
|            |                    | Releases prior to 12.2   |
|            |                    | (54)XO are vulnerable;   |
| 12.2XO     | Not vulnerable     | Releases 12.2(54)XO and  |
|            |                    | later are not            |
|            |                    | vulnerable.              |
|------------+--------------------+--------------------------|
| 12.2XQ     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XR     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XS     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XT     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XU     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XV     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2XW     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2YA     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
| 12.2YB     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2YC     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2YD     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2YE     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YF     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YG     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YH     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YJ     | Not vulnerable     | the instructions in      |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2YK     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YL     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2YM     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YN     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2YO     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2YP     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YQ     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YR     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YS     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YT     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YU     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YV     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YW     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YX     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YY     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2YZ     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2ZA     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SXF       |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2ZB     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2ZC     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2ZD     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2ZE     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
| 12.2ZF     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
| 12.2ZG     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2ZH     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4          |
|------------+--------------------+--------------------------|
| 12.2ZJ     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2ZL     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.2ZP     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.2ZU     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.2SXH       |
|------------+--------------------+--------------------------|
| 12.2ZX     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2ZY     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.2ZYA    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|  Affected  |                    | First Fixed Release for  |
| 12.3-Based |    First Fixed     |  All Advisories in the   |
|  Releases  |      Release       |  September 2011 Bundled  |
|            |                    |       Publication        |
|------------------------------------------------------------|
| There are no affected 12.3 based releases                  |
|------------------------------------------------------------|
|  Affected  |                    | First Fixed Release for  |
| 12.4-Based |    First Fixed     |  All Advisories in the   |
|  Releases  |      Release       |  September 2011 Bundled  |
|            |                    |       Publication        |
|------------+--------------------+--------------------------|
| 12.4       | Not vulnerable     | 12.4(25f)                |
|------------+--------------------+--------------------------|
| 12.4GC     | 12.4(24)GC4        | 12.4(24)GC4              |
|------------+--------------------+--------------------------|
| 12.4JA     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4JAX    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4JDA    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4JDC    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4JHA    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4JHB    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4JHC    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4JK     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4JL     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4JMA    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4JMB    | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; migrate to   |
|            |                    | any release in 12.4JA    |
| 12.4JX     | Not vulnerable     |                          |
|            |                    | Releases up to and       |
|            |                    | including 12.4(21a)JX    |
|            |                    | are not vulnerable.      |
|------------+--------------------+--------------------------|
| 12.4JY     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4MD     | Not vulnerable     | 12.4(24)MD6 on           |
|            |                    | 28-Oct-2011              |
|------------+--------------------+--------------------------|
| 12.4MDA    | Not vulnerable     | 12.4(24)MDA7             |
|------------+--------------------+--------------------------|
| 12.4MDB    | Not vulnerable     | 12.4(24)MDB3             |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.4MR     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.4MRA    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.4MRB    | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4SW     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            | Only 12.4(24)T     |                          |
|            | through 12.4(24)T4 | 12.4(24)T6               |
| 12.4T      | are affected;      |                          |
|            | first fixed in     | 12.4(15)T16              |
|            | 12.4(24)T3c and    |                          |
|            | 12.4(24)T5         |                          |
|------------+--------------------+--------------------------|
| 12.4XA     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4XB     | Not vulnerable     | 12.4(2)XB12              |
|------------+--------------------+--------------------------|
| 12.4XC     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4XD     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4XE     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4XF     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4XG     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4XJ     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4XK     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.4XL     | Not vulnerable     | the instructions in      |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.4XM     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.4XN     | Not vulnerable     | the instructions in      |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.4XP     | Not vulnerable     | the instructions in      |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 12.4XQ     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4XR     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4XT     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4XV     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
| 12.4XW     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4XY     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4XZ     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
| 12.4YA     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 12.4T         |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.4YB     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.4YD     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; fixed in     |
|            |                    | 12.4(22)YE6 on           |
| 12.4YE     | Not vulnerable     | 30-Sept-2011; 12.4(24)   |
|            |                    | YE7 available on         |
|            |                    | 17-Oct-2011              |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 12.4YG     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|  Affected  |                    | First Fixed Release for  |
| 15.0-Based |    First Fixed     |  All Advisories in the   |
|  Releases  |      Release       |  September 2011 Bundled  |
|            |                    |       Publication        |
|------------+--------------------+--------------------------|
| 15.0M      | 15.0(1)M5          | 15.0(1)M7                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 15.0MR     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 15.0MRA    | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            | Not vulnerable     | 15.0(1)S4                |
|            |                    |                          |
| 15.0S      | Cisco IOS XE       | Cisco IOS XE devices:    |
|            | devices: see Cisco | see Cisco IOS-XE         |
|            | IOS-XE Software    | Software Availability    |
|            | Availability       |                          |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 15.0SA     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 15.0SE     | Not vulnerable     | Not vulnerable           |
|------------+--------------------+--------------------------|
|            | Cisco IOS XE       | Cisco IOS XE devices:    |
| 15.0SG     | devices: see Cisco | see Cisco IOS-XE         |
|            | IOS-XE Software    | Software Availability    |
|            | Availability       |                          |
|------------+--------------------+--------------------------|
|            | Vulnerable; First  | Vulnerable; First fixed  |
| 15.0XA     | fixed in Release   | in Release 15.1T         |
|            | 15.1T              |                          |
|------------+--------------------+--------------------------|
|            | Cisco IOS XE       |                          |
|            | devices: Please    | Cisco IOS XE devices:    |
| 15.0XO     | see Cisco IOS-XE   | Please see Cisco IOS-XE  |
|            | Software           | Software Availability    |
|            | Availability       |                          |
|------------+--------------------+--------------------------|
|  Affected  |                    | First Fixed Release for  |
| 15.1-Based |    First Fixed     |  All Advisories in the   |
|  Releases  |      Release       |  September 2011 Bundled  |
|            |                    |       Publication        |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 15.1EY     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
| 15.1GC     | Not vulnerable     | Vulnerable; First fixed  |
|            |                    | in Release 15.1T         |
|------------+--------------------+--------------------------|
| 15.1M      | Not vulnerable     | 15.1(4)M2; Available on  |
|            |                    | 30-SEP-11                |
|------------+--------------------+--------------------------|
|            |                    | Vulnerable; contact your |
|            |                    | support organization per |
| 15.1MR     | Not vulnerable     | the instructions in the  |
|            |                    | Obtaining Fixed Software |
|            |                    | section of this          |
|            |                    | advisory.                |
|------------+--------------------+--------------------------|
|            | Not vulnerable     | 15.1(2)S2                |
|            |                    |                          |
|            | Cisco IOS XE       | 15.1(3)S                 |
| 15.1S      | devices: See Cisco |                          |
|            | IOS-XE Software    | Cisco IOS XE devices:    |
|            | Availability       | See Cisco IOS-XE         |
|            |                    | Software Availability    |
|------------+--------------------+--------------------------|
|            | 15.1(1)T3          |                          |
|            |                    | 15.1(2)T4 15.1(1)T4 on   |
| 15.1T      | 15.1(2)T3          | 8-Dec-2011               |
|            |                    |                          |
|            | 15.1(3)T1          |                          |
|------------+--------------------+--------------------------|
|            | Vulnerable; First  | Vulnerable; First fixed  |
| 15.1XB     | fixed in Release   | in Release 15.1T         |
|            | 15.1T              |                          |
|------------+--------------------+--------------------------|
|  Affected  |                    | First Fixed Release for  |
| 15.2-Based |    First Fixed     |  All Advisories in the   |
|  Releases  |      Release       |  September 2011 Bundled  |
|            |                    |       Publication        |
|------------------------------------------------------------|
| There are no affected 15.2 based releases                  |
+------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

+------------------------------------------------------------+
|  Cisco   |   First    |    First Fixed Release for All     |
|  IOS XE  |   Fixed    |  Advisories in the September 2011  |
| Release  |  Release   |        Bundled Publication         |
|----------+------------+------------------------------------|
| 2.1.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.2.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.3.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.4.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.5.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.6.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 3.1.xS   | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 3.1.xSG  | Not        | Vulnerable; migrate to 3.2.0SG or  |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 3.2.xS   | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 3.2.xSG  | Not        | Not vulnerable                     |
|          | vulnerable |                                    |
|----------+------------+------------------------------------|
| 3.3.xS   | Not        | 3.3.2S                             |
|          | vulnerable |                                    |
|----------+------------+------------------------------------|
| 3.4.xS   | Not        | Not vulnerable                     |
|          | vulnerable |                                    |
+------------------------------------------------------------+

For mapping of Cisco IOS XE to Cisco IOS releases, please refer to
the Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and
Cisco IOS XE 3SG Release Notes.

Cisco IOS XR Software
+--------------------

Cisco IOS XR Software is not affected by any of the vulnerabilities
in the September 2011 bundled publication.

Workarounds
===========

There are no workarounds for this vulnerability if IPv6 configuration
is required.

Obtaining Fixed Software
========================

Cisco has released free software updates that address this
vulnerability. Prior to deploying software, customers should consult
their maintenance provider or check the software for feature set
compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature
sets they have purchased. By installing, downloading, accessing
or otherwise using such software upgrades, customers agree to be
bound by the terms of Cisco's software license terms found at
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability that is described in this advisory.

This vulnerability was discovered by Cisco during internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-ipv6.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+------------------------------------------------------------+
| Revision 1.0 | 2011-September-28 | Initial public release. |
+------------------------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities
in Cisco products, obtaining assistance with security
incidents, and registering to receive security information
from Cisco, is available on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
This includes instructions for press inquiries regarding
Cisco security notices. All Cisco security advisories are available at
http://www.cisco.com/go/psirt.

+--------------------------------------------------------------------
Copyright 2010-2011 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAk6Cp2UACgkQQXnnBKKRMNDOnwD/dwZvi6wHRpTsYyfLbLrCfyOs
8+WevPYlJBddySoqwHYA/14o6NuZ2rculYMYCusovUgM/SZf3N+euXWs897W6V5M
=uQiZ
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 28 11:00:00 2011
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 28 Sep 2011 12:00:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software IPv6 over MPLS
 Vulnerabilities 
Message-ID: <2011092812001.ipv6mpls@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cisco Security Advisory: Cisco IOS Software IPv6 over MPLS
Vulnerabilities

Advisory ID: cisco-sa-20110928-ipv6mpls

Revision 1.0

For Public Release 2011 September 28 1600 UTC (GMT)

+---------------------------------------------------------------------

Summary
=======

Cisco IOS Software is affected by two vulnerabilities that cause a
Cisco IOS device to reload when processing IP version 6 (IPv6)
packets over a Multiprotocol Label Switching (MPLS) domain. These
vulnerabilities are:

  * Crafted IPv6 Packet May Cause MPLS-Configured Device to Reload
  * ICMPv6 Packet May Cause MPLS-Configured Device to Reload

Cisco has released free software updates that address these
vulnerabilities.

Workarounds that mitigate these vulnerabilities are available.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110928-ipv6mpls.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory
bundled publication includes ten Cisco Security Advisories. Nine of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the Cisco IOS Software releases that
correct the vulnerability or vulnerabilities detailed in the advisory as
well as the Cisco IOS Software releases that correct all vulnerabilities
in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Security Advisory Bundled Publication" at the
following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Affected Products
=================

Vulnerable Products
+------------------

Cisco IOS Software or Cisco IOS XE Software devices (hereafter both
referenced as Cisco IOS Software in this document) that are running
vulnerable versions of Cisco IOS Software and configured for MPLS are
affected by two vulnerabilities related to IPv6 traffic that
traverses an MPLS domain. The two vulnerabilities are independent of
each other.

Note: IPv6 does not need to be configured on the affected devices
themselves. The vulnerabilities do require the MPLS label switched
packets to have specific IPv6 payloads to be exploited.

To determine whether a device is configured for MPLS, log in to the
device and issue the command-line interface (CLI) command "show mpls
interface". If the IP state is "Yes", the device is vulnerable. The
following example shows a device that has MPLS configured on
interface Ethernet0/0:

    Router#show mpls interface
    Interface       IP           Tunnel  BGP  Static  Operational
    Ethernet0/0   Yes (ldp)    No      No   No       Yes
    Router#

The following two examples show responses from a device with MPLS
forwarding disabled. The first example shows a return of no
interfaces:

    router#show mpls interface
    Interface              IP            Tunnel   BGP Static Operational
    routers#

In the second example, the device provides a message indicating that
MPLS forwarding is not configured:

    router#show mpls interface
    no MPLS apps enabled or MPLS not enabled on any interfaces

    router#

To determine the Cisco IOS Software release that is running on a Cisco
product, administrators can log in to the device and issue the "show
version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or "Cisco
IOS Software." The image name displays in parentheses, followed by
"Version" and the Cisco IOS Software release name. Other Cisco devices
do not have the "show version" command or may provide different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 15.0(1)M1 with an installed image name of
C3900-UNIVERSALK9-M:

    Router> show version
    Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2009 by Cisco Systems, Inc.
    Compiled Wed 02-Dec-09 17:17 by prod_rel_team


    !--- output truncated


Additional information about Cisco IOS Software
release naming conventions is available in the white
paper Cisco IOS and NX-OS Software Reference Guide at
http://www.cisco.com/web/about/security/intelligence/ios-ref.html.

Products Confirmed Not Vulnerable
+--------------------------------

Devices that are not configured for MPLS are not vulnerable.

The following products have been confirmed not to be affected by
these vulnerabilities:

  * Cisco IOS XR Software

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

The packet handling nodes in an MPLS network are called provider
routers (P routers) and provider edge routers (PE routers) and are
configured with MPLS. Both P and PE routers are vulnerable to both
the vulnerabilities disclosed in this advisory.

In networks that have MPLS enabled and could carry MPLS label
switched packets with IPv6 payloads, the device may crash when
processing MPLS label switched packets with specific IPv6 payloads.
Typical deployment scenarios that would be affected by either
vulnerability would be Cisco IPv6 Provider Edge Router (6PE) or IPv6
VPN Provider Edge Router (6VPE).

Crafted IPv6 Packet May Cause MPLS-Configured Device to Reload
+-------------------------------------------------------------

A crafted IPv6 packet may cause the device to crash when the packet
is processed by Cisco IOS Software because the MPLS TTL has expired.
The crafted packet used to exploit this vulnerability would be
silently discarded in Cisco IOS Software if received on an interface
where the packet did not have an MPLS label.

This vulnerability is documented in Cisco bug ID CSCto07919 and has been
assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2011-3274.

ICMPv6 Packet May Cause MPLS-Configured Device to Reload
+-------------------------------------------------------------

A valid ICMPv6 packet may cause the device to crash when the packet
is processed by Cisco IOS Software because the MPLS TTL has expired.
The packet used to exploit this vulnerability would not affect Cisco
IOS Software if received on an interface where the packet did not
have an MPLS label.

This vulnerability is documented in Cisco bug ID CSCtj30155 and has been
assigned CVE ID CVE-2011-3282.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerabilities in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss


* CSCto07919 ("Crafted IPv6 packet may cause MPLS configured device to
reload")

CVSS Base Score - 6.1
    Access Vector -            Adjacent Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 5.0
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


* CSCtj30155 ("ICMPv6 packet may cause MPLS configured device to
reload")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


Impact
======

Successful exploitation of these vulnerabilities may cause the device
to reload. Repeated exploitation could result in a sustained denial
of service condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to determine
exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Additionally, the Cisco IOS Software Checker is available on
the Cisco Security Intelligence Operations (SIO) portal at
http://tools.cisco.com/security/center/selectIOSVersion.x. It provides
several features for checking which Security Advisories affect specified
versions of Cisco IOS Software.

Cisco IOS Software
+-----------------

Each row of the following Cisco IOS Software table corresponds to a
Cisco IOS Software train. If a particular train is vulnerable, the
earliest releases that contain the fix are listed in the First Fixed
Release For This Advisory column. The First Fixed Release for All
Advisories in the September 2011 Bundled Publication column lists the
earliest possible releases that correct all the published
vulnerabilities in the Cisco IOS Software Security Advisory bundled
publication. Cisco recommends upgrading to the latest available
release, where possible.

+------------------------------------------------------------+
|   Major    |         Availability of Repaired Releases     |
|  Release   |                                               |
|------------+-----------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.0-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |   For This Advisory   |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 12.0-based releases                  |
|------------------------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.1-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |   For This Advisory   |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 12.1E      | Not vulnerable        | 12.2(18)SXF17b        |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.2-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |   For This Advisory   |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 12.2       | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2B      | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2BC     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2BW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2BX     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2BY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2BZ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2CX     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2CY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2CZ     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2DA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2DD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2DX     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2EU     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Releases up to and    |
| 12.2EW     | Not vulnerable        | including 12.2(20)EW4 |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2EWA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2EX     | Not vulnerable        | 12.2(55)EX3           |
|------------+-----------------------+-----------------------|
| 12.2EY     | Not vulnerable        | 12.2(58)EY            |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2EZ     | Not vulnerable        | to any release in     |
|            |                       | 15.0SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2FX     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2FY     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2EX                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2FZ     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2IRA    | Not vulnerable        | to any release in     |
|            |                       | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2IRB    | Not vulnerable        | to any release in     |
|            |                       | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2IRC    | Not vulnerable        | to any release in     |
|            |                       | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IRD    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IRE    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2IRF    | Not vulnerable        | to any release in     |
|            |                       | 12.2IRG               |
|------------+-----------------------+-----------------------|
| 12.2IRG    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXB    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXC    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXD    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXE    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXF    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXG    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXH    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2JA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2JK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2MB     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2MC     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2MRA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SRD               |
|------------+-----------------------+-----------------------|
| 12.2MRB    | Not vulnerable        | 12.2(33)MRB5          |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(30)S are         |
|            |                       | vulnerable; Releases  |
| 12.2S      | Not vulnerable        | 12.2(30)S and later   |
|            |                       | are not vulnerable.   |
|            |                       | First fixed in        |
|            |                       | Release 12.2SB        |
|------------+-----------------------+-----------------------|
|            |                       | 12.2(31)SB20          |
| 12.2SB     | Not vulnerable        |                       |
|            |                       | 12.2(33)SB10          |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SBC    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SB                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SCA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SCC               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SCB    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SCC               |
|------------+-----------------------+-----------------------|
| 12.2SCC    | Not vulnerable        | 12.2(33)SCC7          |
|------------+-----------------------+-----------------------|
| 12.2SCD    | Not vulnerable        | 12.2(33)SCD6          |
|------------+-----------------------+-----------------------|
|            |                       | 12.2(33)SCE1          |
| 12.2SCE    | Not vulnerable        |                       |
|            |                       | 12.2(33)SCE2          |
|------------+-----------------------+-----------------------|
| 12.2SCF    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | 12.2(55)SE3           |
| 12.2SE     | Not vulnerable        |                       |
|            |                       | 12.2(58)SE            |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SEA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SEB    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SEC    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SED    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SEE    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SEF    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(25)SEG4 are      |
|            |                       | vulnerable; Releases  |
| 12.2SEG    | Not vulnerable        | 12.2(25)SEG4 and      |
|            |                       | later are not         |
|            |                       | vulnerable. First     |
|            |                       | fixed in Release      |
|            |                       | 12.2EX                |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(53)SG4 are       |
| 12.2SG     | Not vulnerable        | vulnerable; Releases  |
|            |                       | 12.2(53)SG4 and later |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2SGA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2SL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2SM     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2SO     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SQ     | Not vulnerable        | 12.2(50)SQ3           |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SRA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SRD               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SRB    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SRD               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SRC    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SRD               |
|------------+-----------------------+-----------------------|
| 12.2SRD    | Not vulnerable        | 12.2(33)SRD6          |
|------------+-----------------------+-----------------------|
| 12.2SRE    | 12.2(33)SRE4          | 12.2(33)SRE4          |
|------------+-----------------------+-----------------------|
| 12.2STE    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SU     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(29a)SV are       |
|            |                       | vulnerable; Releases  |
| 12.2SV     | Not vulnerable        | 12.2(29a)SV and later |
|            |                       | are not vulnerable.   |
|            |                       | Migrate to any        |
|            |                       | release in 12.2SVD    |
|------------+-----------------------+-----------------------|
| 12.2SVA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVD    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVE    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2SW     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SX     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SXA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SXB    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SXD    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SXE    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
| 12.2SXF    | Not vulnerable        | 12.2(18)SXF17b        |
|------------+-----------------------+-----------------------|
| 12.2SXH    | Not vulnerable        | 12.2(33)SXH8a         |
|------------+-----------------------+-----------------------|
| 12.2SXI    | Not vulnerable        | 12.2(33)SXI6          |
|------------+-----------------------+-----------------------|
| 12.2SXJ    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SY     | Not vulnerable        | 12.2(50)SY            |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2SZ     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2T      | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2TPC    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2XA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XB     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2XC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XF     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XG     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XH     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XI     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XJ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XM     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XN     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XNA    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
| 12.2XNB    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
| 12.2XNC    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
| 12.2XND    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
| 12.2XNE    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
| 12.2XNF    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(54)XO are        |
| 12.2XO     | Not vulnerable        | vulnerable; Releases  |
|            |                       | 12.2(54)XO and later  |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
| 12.2XQ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XR     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XS     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XT     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XU     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XV     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YA     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2YB     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YF     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YG     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YH     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YJ     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YL     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YM     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YN     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YO     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YP     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YQ     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YR     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YS     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YT     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YU     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YV     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YW     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YX     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YY     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YZ     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2ZA     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2ZB     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2ZC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZE     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZF     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZG     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZH     | Not vulnerable        | Vulnerable; first     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZJ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2ZL     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2ZP     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; first     |
| 12.2ZU     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXH               |
|------------+-----------------------+-----------------------|
| 12.2ZX     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2ZY     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2ZYA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.3-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |   For This Advisory   |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 12.3-based releases                  |
|------------------------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.4-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |   For This Advisory   |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 12.4-based releases                  |
|------------------------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.0-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |   For This Advisory   |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 15.0M      | 15.0(1)M7             | 15.0(1)M7             |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 15.0MR     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 15.0MRA    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 15.0S      | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.0SA     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 15.0SE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 15.0SG     | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 15.0XA     | fixed in Release      | fixed in Release      |
|            | 15.1T                 | 15.1T                 |
|------------+-----------------------+-----------------------|
| 15.0XO     | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.1-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |   For This Advisory   |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.1EY     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 15.1GC     | fixed in Release      | fixed in Release      |
|            | 15.1T                 | 15.1T                 |
|------------+-----------------------+-----------------------|
| 15.1M      | 15.1(4)M1             | 15.1(4)M2; Available  |
|            |                       | on 30-SEP-11          |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.1MR     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 15.1S      | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
|            | 15.1(1)T4; Available  |                       |
|            | on 09-DEC-11          | 15.1(2)T4             |
| 15.1T      |                       |                       |
|            | 15.1(2)T4             | 15.1(1)T4 on          |
|            |                       | 8-Dec-2011            |
|            | 15.1(3)T2             |                       |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 15.1XB     | fixed in Release      | fixed in Release      |
|            | 15.1T                 | 15.1T                 |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.2-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |   For This Advisory   |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 15.2-based releases                  |
+------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

Cisco IOS XE Software is affected by the vulnerability disclosed in
this document.

+------------------------------------------------------------+
|  Cisco   |  First Fixed   |  First Fixed Release for All   |
|  IOS XE  |  Release For   |  Advisories in the September   |
| Release  | This Advisory  |    2011 Bundled Publication    |
|----------+----------------+--------------------------------|
|          | Vulnerable;    |                                |
| 2.1.x    | migrate to     | Vulnerable; migrate to 3.3.2S  |
|          | 3.3.2S or      | or later                       |
|          | later          |                                |
|----------+----------------+--------------------------------|
|          | Vulnerable;    |                                |
| 2.2.x    | migrate to     | Vulnerable; migrate to 3.3.2S  |
|          | 3.3.2S or      | or later                       |
|          | later          |                                |
|----------+----------------+--------------------------------|
|          | Vulnerable;    |                                |
| 2.3.x    | migrate to     | Vulnerable; migrate to 3.3.2S  |
|          | 3.3.2S or      | or later                       |
|          | later          |                                |
|----------+----------------+--------------------------------|
|          | Vulnerable;    |                                |
| 2.4.x    | migrate to     | Vulnerable; migrate to 3.3.2S  |
|          | 3.3.2S or      | or later                       |
|          | later          |                                |
|----------+----------------+--------------------------------|
|          | Vulnerable;    |                                |
| 2.5.x    | migrate to     | Vulnerable; migrate to 3.3.2S  |
|          | 3.3.2S or      | or later                       |
|          | later          |                                |
|----------+----------------+--------------------------------|
|          | Vulnerable;    |                                |
| 2.6.x    | migrate to     | Vulnerable; migrate to 3.3.2S  |
|          | 3.3.2S or      | or later                       |
|          | later          |                                |
|----------+----------------+--------------------------------|
| 3.1.xS   | 3.1.4S         | Vulnerable; migrate to 3.3.2S  |
|          |                | or later                       |
|----------+----------------+--------------------------------|
| 3.1.xSG  | Not vulnerable | Vulnerable; migrate to 3.2.0SG |
|          |                | or later                       |
|----------+----------------+--------------------------------|
|          | Vulnerable;    |                                |
| 3.2.xS   | migrate to     | Vulnerable; migrate to 3.3.2S  |
|          | 3.3.2S or      | or later                       |
|          | later          |                                |
|----------+----------------+--------------------------------|
| 3.2.xSG  | Not vulnerable | Not vulnerable                 |
|----------+----------------+--------------------------------|
| 3.3.xS   | 3.3.2S         | 3.3.2S                         |
|----------+----------------+--------------------------------|
| 3.4.xS   | Not vulnerable | Not vulnerable                 |
+------------------------------------------------------------+

For mapping of Cisco IOS XE to Cisco IOS releases, please refer to
the Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and
Cisco IOS XE 3SG Release Notes.

Cisco IOS XR Software
+--------------------

Cisco IOS XR Software is not affected by the vulnerability disclosed
in this document.

Cisco IOS XR Software is not affected by any of the vulnerabilities
in the September 2011 bundled publication.

Workarounds
===========

For both vulnerabilities the following workaround applies:

Disabling MPLS TTL Propagation
+-----------------------------

Disabling MPLS TTL propagation will prevent exploitation of these
vulnerabilities. MPLS TTL propagation will have to be disabled on all
PE routers in the MPLS domain. To disable MPLS TTL propagation, enter
the global configuration command "no mpls ip propagate-ttl". If only "no
mpls ip propagate-ttl forward" is configured, the vulnerabilities could
still be exploited from within the MPLS domain.

For more information about the MPLS TTL propagation command, refer to
the configuration guide at:

http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m1.html#wp1013846

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature
sets they have purchased. By installing, downloading, accessing
or otherwise using such software upgrades, customers agree to be
bound by the terms of Cisco's software license terms found at
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to http://www.cisco.com/en/US/support/
tsd_cisco_worldwide_contacts.html for additional TAC contact
information, including localized telephone numbers, and instructions
and e-mail addresses for use in various languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerabilities described in this advisory.

These vulnerabilities were discovered when handling customer support
calls.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-ipv6mpls.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+------------------------------------------------------------+
| Revision 1.0 | 2011-September-28 | Initial public release  |
+------------------------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities
in Cisco products, obtaining assistance with security
incidents, and registering to receive security information
from Cisco, is available on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
This includes instructions for press inquiries regarding
Cisco security notices. All Cisco security advisories are available at
http://www.cisco.com/go/psirt.

+--------------------------------------------------------------------
Copyright 2010-2011 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAk6Cp2QACgkQQXnnBKKRMNBQSAD9F2jD01t7WK98WW1TcHuB0ORh
ttZaRD2ayENEbxklbQgA/j6rRzsG/jk1QW1pJjZme3WKwdvNLy9BzRPTsONBz5Cv
=kk0N
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 28 11:00:00 2011
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 28 Sep 2011 12:00:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Session Initiation
 Protocol Denial of Service Vulnerabilities 
Message-ID: <2011092812001.sip@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cisco Security Advisory: Cisco IOS Software Session Initiation
Protocol Denial of Service Vulnerabilities

Advisory ID: cisco-sa-20110928-sip

Revision 1.0

For Public Release 2011 September 28 1600 UTC (GMT)

+--------------------------------------------------------------------

Summary
=======

Multiple vulnerabilities exist in the Session Initiation Protocol
(SIP) implementation in Cisco IOS Software and Cisco IOS XE Software
that could allow an unauthenticated, remote attacker to cause a
reload of an affected device or trigger memory leaks that may result
in system instabilities. Affected devices would need to be configured
to process SIP messages for these vulnerabilities to be exploitable.

Cisco has released free software updates that address these
vulnerabilities. There are no workarounds for devices that must run
SIP; however, mitigations are available to limit exposure to the
vulnerabilities.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110928-sip.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory
bundled publication includes ten Cisco Security Advisories. Nine of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the Cisco IOS Software releases that
correct the vulnerability or vulnerabilities detailed in the advisory as
well as the Cisco IOS Software releases that correct all vulnerabilities
in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Security Advisory Bundled Publication" at the
following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Cisco Unified Communications Manager (CUCM) is affected by one of the
vulnerabilities described in this advisory. A separate Cisco Security
Advisory has been published to disclose the vulnerability that affects
the Cisco Unified Communications Manager at the following location:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-cucm.shtml

Vulnerable Products
+------------------

Cisco devices are affected when they are running affected Cisco IOS
Software and Cisco IOS XE Software versions that are configured to
process SIP messages.

Recent versions of Cisco IOS Software do not process SIP messages by
default. Creating a dial peer by issuing the "dial-peer voice"
configuration command will start the SIP processes, causing the Cisco
IOS device to process SIP messages. In addition, several features in
Cisco Unified Communications Manager Express, such as ephones, will
automatically start the SIP process when they are configured, which
could cause the affected device to start processing SIP messages. An
example of an affected configuration follows:

    dial-peer voice <Voice dial-peer tag> voip
     ...
    !

In addition to inspecting the Cisco IOS device configuration for a
"dial-peer" command that causes the device to process SIP messages,
administrators can also use the "show processes | include SIP" command
to determine whether Cisco IOS Software is running the processes that
handle SIP messages. In the following example, the presence of the
processes CCSIP_UDP_SOCKET or CCSIP_TCP_SOCKET indicates that the Cisco
IOS device will process SIP messages:

    Router# show processes | include SIP
     149 Mwe 40F48254            4          1    400023108/24000  0 CCSIP_UDP_SOCKET
     150 Mwe 40F48034            4          1    400023388/24000  0 CCSIP_TCP_SOCKET

Note: Because there are several ways a device running Cisco IOS Software
can start processing SIP messages, the "show processes | include SIP"
command should be used to determine whether the device is processing SIP
messages instead of relying on the presence of specific configuration
commands.

Cisco Unified Border Element images are also affected by two of these
vulnerabilities.

Note: The Cisco Unified Border Element feature (previously known as
the Cisco Multiservice IP-to-IP Gateway) is a special Cisco IOS
Software image that runs on Cisco multiservice gateway platforms.
This feature provides a network-to-network interface point for
billing, security, call admission control, quality of service, and
signaling interworking.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 15.0(1)M1 with an installed image name of
C3900-UNIVERSALK9-M:

    Router> show version
    Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2009 by Cisco Systems, Inc.
    Compiled Wed 02-Dec-09 17:17 by prod_rel_team

    !--- output truncated

Additional information about Cisco IOS Software release
naming conventions is available in the white paper Cisco
IOS and NX-OS Software Reference Guide available at
http://www.cisco.com/web/about/security/intelligence/ios-ref.html.

Cisco IOS XE Software is affected by these vulnerabilities.

Note: Cisco Unified Communications Manager is affected by one of the
vulnerabilities described in this advisory. A separate Cisco Security
Advisory has been published to disclose the vulnerability that affects
the Cisco Unified Communications Manager at the following location:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-cucm.shtml

Products Confirmed Not Vulnerable
+--------------------------------

The SIP application layer gateway (ALG), which is used by the Cisco
IOS Network Address Translation (NAT) and firewall features of Cisco
IOS Software, is not affected by these vulnerabilities.

Cisco IOS XR Software is not affected by these vulnerabilities.

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

SIP is a popular signaling protocol that is used to manage voice and
video calls across IP networks such as the Internet. SIP is
responsible for handling all aspects of call setup and termination.
Voice and video are the most popular types of sessions that SIP
handles, but the protocol has the flexibility to accommodate other
applications that require call setup and termination. SIP call
signaling can use UDP (port 5060), TCP (port 5060), or Transport
Layer Security (TLS; TCP port 5061) as the underlying transport
protocol.

Multiple vulnerabilities exist in the SIP implementation in Cisco IOS
Software that could allow a remote attacker to cause an affected
device to reload or to trigger memory leaks that may result in system
instabilities. These vulnerabilities are triggered when the device
that is running Cisco IOS Software processes crafted SIP messages.
Only traffic destined to the device can trigger the vulnerabilities;
transit SIP traffic is not an exploit vector.

Note: In cases where SIP is running over TCP transport, a TCP
three-way handshake is necessary to exploit these vulnerabilities.

The vulnerabilities are as follow:

CSCth03022 may cause a reload of an affected device. This vulnerability
has been assigned Common Vulnerabilities and Exposures (CVE) ID
CVE-2011-0939.

CSCti48504 may cause memory leaks. This vulnerability has been assigned
CVE ID CVE-2011-3275.

CSCto88686 may cause memory leaks or reloads of affected devices. This
vulnerability has been assigned CVE ID CVE-2011-2072.

Note: this vulnerability also affects Cisco Unified Communications
Manager. The corresponding Cisco bug ID is CSCtl86047. Refer to the
separate Cisco Security Advisory for the Cisco Unified Communications
Manager for additional details.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerabilities in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at

http://intellishield.cisco.com/security/alertmanager/cvss

Note that all vulnerabilities in this advisory (CSCth03022, CSCti48504,
and CSCto88686) have been scored in an identical manner, assuming a
complete denial of service (DoS) condition.

* CSCth03022, CSCti48504, CSCto88686

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


Impact
======

Successful exploitation of the vulnerabilities in this advisory may
result in system instabilities or a reload of an affected device.
Repeated exploitation could result in a sustained DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to determine
exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Additionally, the Cisco IOS Software Checker is available on
the Cisco Security Intelligence Operations (SIO) portal at
http://tools.cisco.com/security/center/selectIOSVersion.x. It provides
several features for checking which Security Advisories affect specified
versions of Cisco IOS Software.

Cisco IOS Software
+-----------------

Each row of the following Cisco IOS Software table corresponds to a
Cisco IOS Software train. If a particular train is vulnerable, the
earliest releases that contain the fix are listed in the First Fixed
Release For This Advisory column. The First Fixed Release for All
Advisories in the September 2011 Bundled Publication column lists the
earliest possible releases that correct all the published
vulnerabilities in the Cisco IOS Software Security Advisory bundled
publication. Cisco recommends upgrading to the latest available
release, where possible.

+------------------------------------------------------------+
|   Major    |         Availability of Repaired Releases     |
|  Release   |                                               |
|------------+-----------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.0-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 12.0 based releases                  |
|------------------------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.1-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.1E      | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.2-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 12.2       | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2B      | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2BC     | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2BW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2BX     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2BY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2BZ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2CX     | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2CY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2CZ     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2DA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2DD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2DX     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2EU     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Releases up to and    |
| 12.2EW     | Not vulnerable        | including 12.2(20)EW4 |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2EWA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2EX     | Not vulnerable        | 12.2(55)EX3           |
|------------+-----------------------+-----------------------|
| 12.2EY     | Not vulnerable        | 12.2(58)EY            |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2EZ     | Not vulnerable        | to any release in     |
|            |                       | 15.0SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2FX     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2FY     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2EX                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2FZ     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2IRA    | Not vulnerable        | to any release in     |
|            |                       | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2IRB    | Not vulnerable        | to any release in     |
|            |                       | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2IRC    | Not vulnerable        | to any release in     |
|            |                       | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IRD    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IRE    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
| 12.2IRF    | Not vulnerable        | to any release in     |
|            |                       | 12.2IRG               |
|------------+-----------------------+-----------------------|
| 12.2IRG    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXB    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXC    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXD    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXE    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXF    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXG    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IXH    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2JA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2JK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2MB     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2MC     | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2MRA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SRD               |
|------------+-----------------------+-----------------------|
| 12.2MRB    | Not vulnerable        | 12.2(33)MRB5          |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(30)S are         |
|            |                       | vulnerable; Releases  |
| 12.2S      | Not vulnerable        | 12.2(30)S and later   |
|            |                       | are not vulnerable.   |
|            |                       | First fixed in        |
|            |                       | Release 12.2SB        |
|------------+-----------------------+-----------------------|
| 12.2SB     | Not vulnerable        | 12.2(31)SB2012.2(33)  |
|            |                       | SB10                  |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SBC    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SB                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SCA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SCC               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SCB    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SCC               |
|------------+-----------------------+-----------------------|
| 12.2SCC    | Not vulnerable        | 12.2(33)SCC7          |
|------------+-----------------------+-----------------------|
| 12.2SCD    | Not vulnerable        | 12.2(33)SCD6          |
|------------+-----------------------+-----------------------|
| 12.2SCE    | Not vulnerable        | 12.2(33)SCE112.2(33)  |
|            |                       | SCE2                  |
|------------+-----------------------+-----------------------|
| 12.2SCF    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SE     | Not vulnerable        | 12.2(55)SE312.2(58)SE |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SEA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SEB    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SEC    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SED    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SEE    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SEF    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SE                |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(25)SEG4 are      |
|            |                       | vulnerable; Releases  |
| 12.2SEG    | Not vulnerable        | 12.2(25)SEG4 and      |
|            |                       | later are not         |
|            |                       | vulnerable. First     |
|            |                       | fixed in Release      |
|            |                       | 12.2EX                |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(53)SG4 are       |
| 12.2SG     | Not vulnerable        | vulnerable; Releases  |
|            |                       | 12.2(53)SG4 and later |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2SGA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2SL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2SM     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2SO     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SQ     | Not vulnerable        | 12.2(50)SQ3           |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SRA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SRD               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SRB    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SRD               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SRC    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SRD               |
|------------+-----------------------+-----------------------|
| 12.2SRD    | Not vulnerable        | 12.2(33)SRD6          |
|------------+-----------------------+-----------------------|
| 12.2SRE    | Not vulnerable        | 12.2(33)SRE4          |
|------------+-----------------------+-----------------------|
| 12.2STE    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SU     | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(29a)SV are       |
|            |                       | vulnerable; Releases  |
| 12.2SV     | Not vulnerable        | 12.2(29a)SV and later |
|            |                       | are not vulnerable.   |
|            |                       | Migrate to any        |
|            |                       | release in 12.2SVD    |
|------------+-----------------------+-----------------------|
| 12.2SVA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVD    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVE    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2SW     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SX     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SXA    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SXB    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SXD    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SXE    | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
| 12.2SXF    | Not vulnerable        | 12.2(18)SXF17b        |
|------------+-----------------------+-----------------------|
| 12.2SXH    | Not vulnerable        | 12.2(33)SXH8a         |
|------------+-----------------------+-----------------------|
| 12.2SXI    | Not vulnerable        | 12.2(33)SXI6          |
|------------+-----------------------+-----------------------|
| 12.2SXJ    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SY     | Not vulnerable        | 12.2(50)SY            |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2SZ     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2T      | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2TPC    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2XA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XB     | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2XC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XF     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XG     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XH     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XI     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XJ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XM     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XN     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XNA    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
| 12.2XNB    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
| 12.2XNC    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
| 12.2XND    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
| 12.2XNE    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
| 12.2XNF    | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(54)XO are        |
| 12.2XO     | Not vulnerable        | vulnerable; Releases  |
|            |                       | 12.2(54)XO and later  |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
| 12.2XQ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XR     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XS     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XT     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XU     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XV     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YA     | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2YB     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YF     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YG     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YH     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YJ     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YL     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YM     | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YN     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YO     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YP     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YQ     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YR     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YS     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YT     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YU     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YV     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YW     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YX     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YY     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2YZ     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2ZA     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2ZB     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2ZC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZE     | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZF     | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZG     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZH     | Not vulnerable        | Vulnerable; First     |
|            |                       | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZJ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2ZL     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2ZP     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.2ZU     | Not vulnerable        | fixed in Release      |
|            |                       | 12.2SXH               |
|------------+-----------------------+-----------------------|
| 12.2ZX     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2ZY     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2ZYA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.3-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 12.3 based releases                  |
|------------------------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.4-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 12.4       | Not vulnerable        | 12.4(25f)             |
|------------+-----------------------+-----------------------|
| 12.4GC     | 12.4(24)GC4           | 12.4(24)GC4           |
|------------+-----------------------+-----------------------|
| 12.4JA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JAX    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JDA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JDC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JHA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JHB    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JHC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JMA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JMB    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; migrate   |
|            |                       | to any release in     |
|            |                       | 12.4JA                |
| 12.4JX     | Not vulnerable        |                       |
|            |                       | Releases up to and    |
|            |                       | including 12.4(21a)JX |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
| 12.4JY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4MD     | Not vulnerable        | 12.4(24)MD6 on        |
|            |                       | 28-Oct-2011           |
|------------+-----------------------+-----------------------|
| 12.4MDA    | Not vulnerable        | 12.4(24)MDA7          |
|------------+-----------------------+-----------------------|
| 12.4MDB    | Not vulnerable        | 12.4(24)MDB3          |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            | Releases up to and    | organization per the  |
| 12.4MR     | including 12.4(6)MR1  | instructions in the   |
|            | are not vulnerable.   | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4MRA    | instructions in       | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; First     | Vulnerable; First     |
| 12.4MRB    | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4SW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | 12.4(24)T6            | 12.4(24)T6            |
| 12.4T      |                       |                       |
|            | 12.4(15)T16           | 12.4(15)T16           |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.4XA     | Not vulnerable        | fixed in Release      |
|            |                       | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4XB     | Not vulnerable        | 12.4(2)XB12           |
|------------+-----------------------+-----------------------|
|            | Vulnerable; First     |                       |
| 12.4XC     | Fixed in Release      | Not vulnerable        |
|            | 12.4T                 |                       |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.4XD     | Not vulnerable        | fixed in Release      |
|            |                       | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Not vulnerable        |                       |
|            |                       |                       |
| 12.4XE     | Vulnerable; First     | Not vulnerable        |
|            | Fixed in Release      |                       |
|            | 12.4T                 |                       |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.4XF     | Not vulnerable        | fixed in Release      |
|            |                       | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Releases up to and    |                       |
|            | including 12.4(9)XG1  |                       |
|            | are not vulnerable.   |                       |
|            |                       | Vulnerable; First     |
| 12.4XG     | Releases 12.4(9)XG3   | fixed in Release      |
|            | and later are not     | 12.4T                 |
|            | vulnerable. First     |                       |
|            | fixed in Release      |                       |
|            | 12.4T                 |                       |
|------------+-----------------------+-----------------------|
|            | Not vulnerable        |                       |
|            |                       |                       |
| 12.4XJ     | Vulnerable; First     | Not vulnerable        |
|            | Fixed in Release      |                       |
|            | 12.4T                 |                       |
|------------+-----------------------+-----------------------|
| 12.4XK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4XL     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Releases up to and    |                       |
|            | including 12.4(15)XM  |                       |
|            | are not vulnerable.   |                       |
|            |                       | Vulnerable; First     |
| 12.4XM     | Releases 12.4(15)XM3  | fixed in Release      |
|            | and later are not     | 12.4T                 |
|            | vulnerable. First     |                       |
|            | fixed in Release      |                       |
|            | 12.4T                 |                       |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.4XN     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.4XP     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.4XQ     | Not vulnerable        | fixed in Release      |
|            |                       | 12.4T                 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.4XR     | Not vulnerable        | fixed in Release      |
|            |                       | 12.4T                 |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 12.4XT     | Not vulnerable        | fixed in Release      |
|            |                       | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4XV     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; First     | Vulnerable; First     |
| 12.4XW     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; First     | Vulnerable; First     |
| 12.4XY     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; First     | Vulnerable; First     |
| 12.4XZ     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; First     | Vulnerable; First     |
| 12.4YA     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4YB     | instructions in       | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.4YD     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; fixed in  |
|            |                       | 12.4(22)YE6 on        |
| 12.4YE     | Not vulnerable        | 30-Sept-2011; 12.4    |
|            |                       | (24)YE7 available on  |
|            |                       | 17-Oct-2011           |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.4YG     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.0-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 15.0M      | 15.0(1)M7             | 15.0(1)M7             |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.0MR     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.0MRA    | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Not vulnerable        | 15.0(1)S4             |
|            |                       |                       |
| 15.0S      | Cisco IOS XE devices: | Cisco IOS XE devices: |
|            | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.0SA     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 15.0SE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Cisco IOS XE devices: | Cisco IOS XE devices: |
| 15.0SG     | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
|            | Vulnerable; First     | Vulnerable; First     |
| 15.0XA     | fixed in Release      | fixed in Release      |
|            | 15.1T                 | 15.1T                 |
|------------+-----------------------+-----------------------|
|            | Cisco IOS XE devices: | Cisco IOS XE devices: |
| 15.0XO     | See Cisco IOS-XE      | See Cisco IOS-XE      |
|            | Software Availability | Software Availability |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.1-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.1EY     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; First     | Vulnerable; First     |
| 15.1GC     | fixed in Release      | fixed in Release      |
|            | 15.1T                 | 15.1T                 |
|------------+-----------------------+-----------------------|
| 15.1M      | 15.1(4)M1             | 15.1(4)M2; Available  |
|            |                       | on 30-SEP-11          |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.1MR     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | 15.1(2)S2             |
|            | Not vulnerable        |                       |
|            |                       | 15.1(3)S              |
| 15.1S      | Cisco IOS XE devices: |                       |
|            | See Cisco IOS-XE      | Cisco IOS XE devices: |
|            | Software Availability | See Cisco IOS-XE      |
|            |                       | Software Availability |
|------------+-----------------------+-----------------------|
|            | 15.1(2)T4             | 15.1(2)T4 15.1(1)T4   |
| 15.1T      |                       | on 8-Dec-2011         |
|            | 15.1(3)T2             |                       |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; First     |
| 15.1XB     | 15.1(4)XB5            | fixed in Release      |
|            |                       | 15.1T                 |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.2-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 15.2 based releases                  |
+------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

+------------------------------------------------------------+
|  Cisco   |   First    |    First Fixed Release for All     |
|  IOS XE  |   Fixed    |  Advisories in the September 2011  |
| Release  |  Release   |        Bundled Publication         |
|----------+------------+------------------------------------|
| 2.1.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | Vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.2.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | Vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.3.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | Vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.4.x    | Not        | Vulnerable; migrate to 3.3.2S or   |
|          | Vulnerable | later                              |
|----------+------------+------------------------------------|
| 2.5.x    | 3.1.3S     | Vulnerable; migrate to 3.3.2S or   |
|          |            | later                              |
|----------+------------+------------------------------------|
| 2.6.x    | 3.1.3S     | Vulnerable; migrate to 3.3.2S or   |
|          |            | later                              |
|----------+------------+------------------------------------|
| 3.1.xS   | 3.1.3S     | Vulnerable; migrate to 3.3.2S or   |
|          |            | later                              |
|----------+------------+------------------------------------|
| 3.1.xSG  | Not        | Vulnerable; migrate to 3.2.0SG or  |
|          | vulnerable | later                              |
|----------+------------+------------------------------------|
| 3.2.xS   | 3.2.1S     | Vulnerable; migrate to 3.3.2S or   |
|          |            | later                              |
|----------+------------+------------------------------------|
| 3.2.xSG  | Not        | Not vulnerable                     |
|          | vulnerable |                                    |
|----------+------------+------------------------------------|
| 3.3.xS   | Not        | 3.3.2S                             |
|          | Vulnerable |                                    |
|----------+------------+------------------------------------|
| 3.4.xS   | Not        | Not Vulnerable                     |
|          | Vulnerable |                                    |
+------------------------------------------------------------+

For mapping of Cisco IOS XE to Cisco IOS releases, please refer to
the Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and
Cisco IOS XE 3SG Release Notes.

Cisco IOS XR System Software
+---------------------------

Cisco IOS XR Software is not affected by any of the vulnerabilities
in the September 2011 bundled publication.

Workarounds
===========

If the affected Cisco IOS device requires SIP for VoIP services, SIP
cannot be disabled and no workarounds are available. Users are
advised to apply mitigation techniques to help limit exposure to the
vulnerabilities. Mitigation consists of allowing only legitimate
devices to connect to affected devices. To increase effectiveness,
the mitigation must be coupled with measures against spoofing on the
network edge. This action is required because SIP can use UDP as the
transport protocol.

Additional mitigations that can be deployed on Cisco
devices within the network are available in the companion
document "Cisco Applied Mitigation Bulletin:Identifying and
Mitigating Exploitation of the Multiple Vulnerabilities
in Cisco Voice Products" at the following location:
http://www.cisco.com/warp/public/707/cisco-amb-20110928-voice.shtml.

Disabling SIP Listening Ports
+----------------------------

For devices that do not require SIP to be enabled, the simplest and
most effective workaround is to disable SIP processing on the device.
Some versions of Cisco IOS Software allow administrators to disable
SIP with the following commands:

    sip-ua
     no transport udp
     no transport tcp
     no transport tcp tls

Warning: When applying this workaround to devices that are processing
Media Gateway Control Protocol (MGCP) or H.323 calls, the device will
not stop SIP processing while active calls are being processed. Under
these circumstances, this workaround should be implemented during a
maintenance window when active calls can be briefly stopped.

The "show udp connections", "show tcp brief all", and "show processes |
include SIP" commands can be used to confirm that the SIP UDP and TCP
ports are closed after applying this workaround.

Depending on the Cisco IOS Software version in use, when SIP is
disabled, the output from the "show ip sockets" command may still show
the SIP ports open, but sending traffic to them will cause the SIP
process to display the following message:

    *Jun 2 11:36:47.691: sip_udp_sock_process_read: SIP UDP Listener is DISABLED

Control Plane Policing
+---------------------

For devices that need to offer SIP services, it is possible to use
Control Plane Policing (CoPP) to block SIP traffic to the device from
untrusted sources. Cisco IOS Releases 12.0S, 12.2SX, 12.2S, 12.3T,
12.4, and 12.4T support the CoPP feature. CoPP may be configured on a
device to protect the management and control planes to minimize the
risk and effectiveness of direct infrastructure attacks by explicitly
permitting only authorized traffic sent to infrastructure devices in
accordance with existing security policies and configurations. The
following example can be adapted to specific network configurations:

    !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted.
    !-- Everything else is not trusted. The following access list is used
    !-- to determine what traffic needs to be dropped by a control plane
    !-- policy (the CoPP feature): if the access list matches (permit)
    !-- then traffic will be dropped and if the access list does not
    !-- match (deny) then traffic will be processed by the router.
    access-list 100 deny udp 192.168.1.0 0.0.0.255 any eq 5060
    access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5060
    access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5061
    access-list 100 deny udp host 172.16.1.1 any eq 5060
    access-list 100 deny tcp host 172.16.1.1 any eq 5060
    access-list 100 deny tcp host 172.16.1.1 any eq 5061
    access-list 100 permit udp any any eq 5060
    access-list 100 permit tcp any any eq 5060
    access-list 100 permit tcp any any eq 5061

    !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4
    !-- traffic in accordance with existing security policies and
    !-- configurations for traffic that is authorized to be sent
    !-- to infrastructure devices.
    !-- Create a Class-Map for traffic to be policed by
    !-- the CoPP feature.
    class-map match-all drop-sip-class
      match access-group 100

    !-- Create a Policy-Map that will be applied to the
    !-- Control-Plane of the device.
    policy-map control-plane-policy
     class drop-sip-class
      drop

    !-- Apply the Policy-Map to the Control-Plane of the
    !-- device.
    control-plane
     service-policy input control-plane-policy

Note: Because SIP can use UDP as a transport protocol, it is possible
to spoof the source address of an IP packet, which may bypass access
control lists that permit communication to these ports from trusted
IP addresses.

In the preceding CoPP example, the access control entries (ACEs) that
match the potential exploit packets with the permit action cause these
packets to be discarded by the policy-map drop function, whereas
packets that match the deny action (not shown) are not affected by the
policy-map drop function. Additional information on the configuration
and use of the CoPP feature can be found at
http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html.

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature
sets they have purchased. By installing, downloading, accessing
or otherwise using such software upgrades, customers agree to be
bound by the terms of Cisco's software license terms found at
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerabilities described in this advisory.

These vulnerabilities were discovered by Cisco during internal
testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-sip.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+------------------------------------------------------------+
| Revision 1.0 | 2011-September-28 | Initial public release. |
+------------------------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities
in Cisco products, obtaining assistance with security
incidents, and registering to receive security information
from Cisco, is available on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
This includes instructions for press inquiries regarding
Cisco security notices. All Cisco security advisories are available at
http://www.cisco.com/go/psirt.

+--------------------------------------------------------------------
Copyright 2010-2011 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAk6Cp2gACgkQQXnnBKKRMNDX3gD/UeN/lhANnUYaPYTJesK+CgTF
Hnpss1asMqYlNes4DlgA/idrlbSx8cbkiX0rrhhHEkTNFRcVmvxA3gJhKq9s9GsO
=XFrW
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 28 11:00:00 2011
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 28 Sep 2011 12:00:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Smart Install Remote Code
 Execution Vulnerability 
Message-ID: <2011092812001.smart-install@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cisco Security Advisory: Cisco IOS Software Smart Install Remote Code
Execution Vulnerability

Advisory ID: cisco-sa-20110928-smart-install

Revision 1.0

For Public Release 2011 September 28 1600 UTC (GMT)

+--------------------------------------------------------------------

Summary
=======

A vulnerability exists in the Smart Install feature of Cisco Catalyst
Switches running Cisco IOS Software that could allow an
unauthenticated, remote attacker to perform remote code execution on
the affected device.

Cisco has released free software updates that address this
vulnerability.

There are no workarounds available to mitigate this vulnerability
other than disabling the Smart Install feature.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110928-smart-install.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory
bundled publication includes ten Cisco Security Advisories. Nine of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the Cisco IOS Software releases that
correct the vulnerability or vulnerabilities detailed in the advisory as
well as the Cisco IOS Software releases that correct all vulnerabilities
in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Security Advisory Bundled Publication" at the
following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Affected Products
=================

This vulnerability only affects Cisco Catalyst Switches and Cisco
Integrated Services Routers with the Smart Install feature enabled.

Vulnerable Products
+------------------

Devices configured as a Smart Install client or director are affected
by this vulnerability. To display Smart Install information, use the
"show vstack config" privileged EXEC command on the Smart Install
director or client. The outputs of the show commands are different
when entered on the director or on the client. The following is the
output of the "show vstack config" in a device configured as a Smart
Install client:

    switch#show vstack config
     Role: Client
     Vstack Director IP address: 10.1.1.163

The following is the output of the "show vstack config" in a Cisco
Catalyst Switch configured as a Smart Install director:

    Director# show vstack config

    Role: Director
     Vstack Director IP address: 10.1.1.163
     Vstack Mode: Basic
     Vstack default management vlan: 1
     Vstack management Vlans: none
     Vstack Config file: tftp://10.1.1.100/default-config.txt
     Vstack Image file: tftp://10.1.1.100/c3750e-universalk9-tar.122-
     Join Window Details:
             Window: Open (default)
             Operation Mode: auto (default)
     Vstack Backup Details:
             Mode: On (default)
             Repository: flash:/vstack (default)

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 15.0(1)M1 with an installed image name of
C3900-UNIVERSALK9-M:

    Router> show version
    Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2009 by Cisco Systems, Inc.
    Compiled Wed 02-Dec-09 17:17 by prod_rel_team

    !--- output truncated

Additional information about Cisco IOS Software release
naming conventions is available in the white paper Cisco
IOS and NX-OS Software Reference Guide available at
http://www.cisco.com/web/about/security/intelligence/ios-ref.html.

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS XR Software is not affected by this vulnerability.

Cisco IOS XE Software is not affected by this vulnerability.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

Smart Install is a plug-and-play configuration and image-management
feature that provides zero-touch deployment for new switches and
Cisco Integrated Services Routers. This means that a customer can
ship a device to a location, place it in the network and power it on
with no configuration required on the device.

A vulnerability exists in the Smart Install feature of Cisco Catalyst
Switches running Cisco IOS Software that could allow an
unauthenticated, remote attacker to perform remote code execution on
the affected device. Smart Install uses TCP port 4786 for
communication. An established TCP connection with a completed TCP
three-way handshake is needed to be able to trigger this
vulnerability.

This vulnerability is documented in Cisco bug ID CSCto10165, and
has been assigned Common Vulnerabilities and Exposures (CVE) ID
CVE-2011-3271.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss


* CSCto10165 ("Smart Install Crashes with certain IP Packets")

CVSS Base Score - 10.0
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   Complete
    Integrity Impact -         Complete
    Availability Impact -      Complete

CVSS Temporal Score - 8.3
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


Impact
======

Successful exploitation could allow an unauthenticated, remote
attacker to perform remote code execution on the affected device.

Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to determine
exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Additionally, the Cisco IOS Software Checker is available on
the Cisco Security Intelligence Operations (SIO) portal at
http://tools.cisco.com/security/center/selectIOSVersion.x. It provides
several features for checking which Security Advisories affect specified
versions of Cisco IOS Software.

Cisco IOS Software
+-----------------

Each row of the following Cisco IOS Software table corresponds to a
Cisco IOS Software train. If a particular train is vulnerable, the
earliest releases that contain the fix are listed in the First Fixed
Release For This Advisory column. The First Fixed Release for All
Advisories in the September 2011 Bundled Publication column lists the
earliest possible releases that correct all the published
vulnerabilities in the Cisco IOS Software Security Advisory bundled
publication. Cisco recommends upgrading to the latest available
release, where possible.

+------------------------------------------------------------+
|   Major    |         Availability of Repaired Releases     |
|  Release   |                                               |
|------------+-----------------------------------------------|
|  Affected  |  First Fixed   | First Fixed Release for All  |
| 12.0-Based |    Release     | Advisories in the September  |
|  Releases  |                |   2011 Bundled Publication   |
|------------------------------------------------------------|
| There are no affected 12.0 based releases                  |
|------------------------------------------------------------|
|  Affected  |  First Fixed   | First Fixed Release for All  |
| 12.1-Based |    Release     | Advisories in the September  |
|  Releases  |                |   2011 Bundled Publication   |
|------------------------------------------------------------|
| There are no affected 12.1 based releases                  |
|------------------------------------------------------------|
|  Affected  |  First Fixed   | First Fixed Release for All  |
| 12.2-Based |    Release     | Advisories in the September  |
|  Releases  |                |   2011 Bundled Publication   |
|------------+----------------+------------------------------|
| 12.2       | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
| 12.2B      | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
| 12.2BC     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
| 12.2BW     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2BX     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SB               |
|------------+----------------+------------------------------|
| 12.2BY     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2BZ     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2CX     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
| 12.2CY     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2CZ     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SB               |
|------------+----------------+------------------------------|
| 12.2DA     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2DD     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2DX     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2EU     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            |                | Releases up to and including |
| 12.2EW     | Not vulnerable | 12.2(20)EW4 are not          |
|            |                | vulnerable.                  |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2EWA    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2EX     | 12.2(55)EX3    | 12.2(55)EX3                  |
|------------+----------------+------------------------------|
| 12.2EY     | 12.2(58)EY     | 12.2(58)EY                   |
|------------+----------------+------------------------------|
|            | Vulnerable;    |                              |
|            | migrate to any |                              |
|            | release in     |                              |
|            | 15.0SE         |                              |
| 12.2EZ     |                | Vulnerable; migrate to any   |
|            | Releases up to | release in 15.0SE            |
|            | and including  |                              |
|            | 12.2(53)EZ are |                              |
|            | not            |                              |
|            | vulnerable.    |                              |
|------------+----------------+------------------------------|
| 12.2FX     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SE               |
|------------+----------------+------------------------------|
| 12.2FY     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2EX               |
|------------+----------------+------------------------------|
| 12.2FZ     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SE               |
|------------+----------------+------------------------------|
| 12.2IRA    | Not vulnerable | Vulnerable; migrate to any   |
|            |                | release in 12.2IRG           |
|------------+----------------+------------------------------|
| 12.2IRB    | Not vulnerable | Vulnerable; migrate to any   |
|            |                | release in 12.2IRG           |
|------------+----------------+------------------------------|
| 12.2IRC    | Not vulnerable | Vulnerable; migrate to any   |
|            |                | release in 12.2IRG           |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2IRD    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2IRE    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2IRF    | Not vulnerable | Vulnerable; migrate to any   |
|            |                | release in 12.2IRG           |
|------------+----------------+------------------------------|
| 12.2IRG    | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2IXA    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2IXB    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2IXC    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2IXD    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2IXE    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2IXF    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2IXG    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2IXH    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2JA     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2JK     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2MB     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2MC     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
| 12.2MRA    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SRD              |
|------------+----------------+------------------------------|
| 12.2MRB    | Not vulnerable | 12.2(33)MRB5                 |
|------------+----------------+------------------------------|
|            |                | Releases prior to 12.2(30)S  |
|            |                | are vulnerable; Releases     |
| 12.2S      | Not vulnerable | 12.2(30)S and later are not  |
|            |                | vulnerable. First fixed in   |
|            |                | Release 12.2SB               |
|------------+----------------+------------------------------|
|            |                | 12.2(31)SB20                 |
| 12.2SB     | Not vulnerable |                              |
|            |                | 12.2(33)SB10                 |
|------------+----------------+------------------------------|
| 12.2SBC    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SB               |
|------------+----------------+------------------------------|
| 12.2SCA    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SCC              |
|------------+----------------+------------------------------|
| 12.2SCB    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SCC              |
|------------+----------------+------------------------------|
| 12.2SCC    | Not vulnerable | 12.2(33)SCC7                 |
|------------+----------------+------------------------------|
| 12.2SCD    | Not vulnerable | 12.2(33)SCD6                 |
|------------+----------------+------------------------------|
|            |                | 12.2(33)SCE1                 |
| 12.2SCE    | Not vulnerable |                              |
|            |                | 12.2(33)SCE2                 |
|------------+----------------+------------------------------|
| 12.2SCF    | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            | Releases up to | 12.2(55)SE3                  |
| 12.2SE     | and including  |                              |
|            | 12.2(54)SE are | 12.2(58)SE                   |
|            | not vulnerable |                              |
|------------+----------------+------------------------------|
| 12.2SEA    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SE               |
|------------+----------------+------------------------------|
| 12.2SEB    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SE               |
|------------+----------------+------------------------------|
| 12.2SEC    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SE               |
|------------+----------------+------------------------------|
| 12.2SED    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SE               |
|------------+----------------+------------------------------|
| 12.2SEE    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SE               |
|------------+----------------+------------------------------|
| 12.2SEF    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SE               |
|------------+----------------+------------------------------|
|            |                | Releases prior to 12.2(25)   |
|            |                | SEG4 are vulnerable;         |
| 12.2SEG    | Not vulnerable | Releases 12.2(25)SEG4 and    |
|            |                | later are not vulnerable.    |
|            |                | First fixed in Release       |
|            |                | 12.2EX                       |
|------------+----------------+------------------------------|
|            |                | Releases prior to 12.2(53)   |
| 12.2SG     | Not vulnerable | SG4 are vulnerable; Releases |
|            |                | 12.2(53)SG4 and later are    |
|            |                | not vulnerable.              |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2SGA    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2SL     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2SM     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2SO     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2SQ     | Not vulnerable | 12.2(50)SQ3                  |
|------------+----------------+------------------------------|
| 12.2SRA    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SRD              |
|------------+----------------+------------------------------|
| 12.2SRB    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SRD              |
|------------+----------------+------------------------------|
| 12.2SRC    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SRD              |
|------------+----------------+------------------------------|
| 12.2SRD    | Not vulnerable | 12.2(33)SRD6                 |
|------------+----------------+------------------------------|
| 12.2SRE    | Not vulnerable | 12.2(33)SRE4                 |
|------------+----------------+------------------------------|
| 12.2STE    | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2SU     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
|            |                | Releases prior to 12.2(29a)  |
|            |                | SV are vulnerable; Releases  |
| 12.2SV     | Not vulnerable | 12.2(29a)SV and later are    |
|            |                | not vulnerable. Migrate to   |
|            |                | any release in 12.2SVD       |
|------------+----------------+------------------------------|
| 12.2SVA    | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2SVC    | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2SVD    | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2SVE    | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2SW     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2SX     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SXF              |
|------------+----------------+------------------------------|
| 12.2SXA    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SXF              |
|------------+----------------+------------------------------|
| 12.2SXB    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SXF              |
|------------+----------------+------------------------------|
| 12.2SXD    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SXF              |
|------------+----------------+------------------------------|
| 12.2SXE    | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SXF              |
|------------+----------------+------------------------------|
| 12.2SXF    | Not vulnerable | 12.2(18)SXF17b               |
|------------+----------------+------------------------------|
| 12.2SXH    | Not vulnerable | 12.2(33)SXH8a                |
|------------+----------------+------------------------------|
| 12.2SXI    | Not vulnerable | 12.2(33)SXI6                 |
|------------+----------------+------------------------------|
| 12.2SXJ    | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2SY     | Not vulnerable | 12.2(50)SY                   |
|------------+----------------+------------------------------|
| 12.2SZ     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SB               |
|------------+----------------+------------------------------|
| 12.2T      | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2TPC    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2XA     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XB     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
| 12.2XC     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XD     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XE     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XF     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XG     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XH     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XI     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XJ     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XK     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XL     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XM     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XN     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            | Please see     |                              |
| 12.2XNA    | Cisco IOS-XE   | Please see Cisco IOS-XE      |
|            | Software       | Software Availability        |
|            | Availability   |                              |
|------------+----------------+------------------------------|
|            | Please see     |                              |
| 12.2XNB    | Cisco IOS-XE   | Please see Cisco IOS-XE      |
|            | Software       | Software Availability        |
|            | Availability   |                              |
|------------+----------------+------------------------------|
|            | Please see     |                              |
| 12.2XNC    | Cisco IOS-XE   | Please see Cisco IOS-XE      |
|            | Software       | Software Availability        |
|            | Availability   |                              |
|------------+----------------+------------------------------|
|            | Please see     |                              |
| 12.2XND    | Cisco IOS-XE   | Please see Cisco IOS-XE      |
|            | Software       | Software Availability        |
|            | Availability   |                              |
|------------+----------------+------------------------------|
|            | Please see     |                              |
| 12.2XNE    | Cisco IOS-XE   | Please see Cisco IOS-XE      |
|            | Software       | Software Availability        |
|            | Availability   |                              |
|------------+----------------+------------------------------|
|            | Please see     |                              |
| 12.2XNF    | Cisco IOS-XE   | Please see Cisco IOS-XE      |
|            | Software       | Software Availability        |
|            | Availability   |                              |
|------------+----------------+------------------------------|
|            |                | Releases prior to 12.2(54)XO |
| 12.2XO     | Not vulnerable | are vulnerable; Releases     |
|            |                | 12.2(54)XO and later are not |
|            |                | vulnerable.                  |
|------------+----------------+------------------------------|
| 12.2XQ     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XR     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XS     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XT     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XU     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XV     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2XW     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2YA     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
| 12.2YB     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2YC     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2YD     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2YE     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YF     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YG     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YH     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YJ     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2YK     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YL     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2YM     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YN     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2YO     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2YP     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YQ     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YR     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YS     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YT     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YU     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YV     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YW     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YX     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YY     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2YZ     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2ZA     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SXF              |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2ZB     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2ZC     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2ZD     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2ZE     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
| 12.2ZF     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
| 12.2ZG     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2ZH     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.4                 |
|------------+----------------+------------------------------|
| 12.2ZJ     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2ZL     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 12.2ZP     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
| 12.2ZU     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 12.2SXH              |
|------------+----------------+------------------------------|
| 12.2ZX     | Not vulnerable | Not vulnerable               |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2ZY     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 12.2ZYA    | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|  Affected  |  First Fixed   | First Fixed Release for All  |
| 12.3-Based |    Release     | Advisories in the September  |
|  Releases  |                |   2011 Bundled Publication   |
|------------------------------------------------------------|
| There are no affected 12.3 based releases                  |
|------------------------------------------------------------|
|  Affected  |  First Fixed   | First Fixed Release for All  |
| 12.4-Based |    Release     | Advisories in the September  |
|  Releases  |                |   2011 Bundled Publication   |
|------------------------------------------------------------|
| There are no affected 12.4 based releases                  |
|------------------------------------------------------------|
|  Affected  |  First Fixed   | First Fixed Release for All  |
| 15.0-Based |    Release     | Advisories in the September  |
|  Releases  |                |   2011 Bundled Publication   |
|------------------------------------------------------------|
| There are no affected 15.0 based releases                  |
|------------------------------------------------------------|
|  Affected  |  First Fixed   | First Fixed Release for All  |
| 15.1-Based |    Release     | Advisories in the September  |
|  Releases  |                |   2011 Bundled Publication   |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 15.1EY     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
| 15.1GC     | Not vulnerable | Vulnerable; First fixed in   |
|            |                | Release 15.1T                |
|------------+----------------+------------------------------|
|            | 15.1(4)M2;     | 15.1(4)M2; Available on      |
| 15.1M      | Available on   | 30-SEP-11                    |
|            | 30-SEP-11      |                              |
|------------+----------------+------------------------------|
|            |                | Vulnerable; contact your     |
|            |                | support organization per the |
| 15.1MR     | Not vulnerable | instructions in the          |
|            |                | Obtaining Fixed Software     |
|            |                | section of this advisory.    |
|------------+----------------+------------------------------|
|            |                | 15.1(2)S2                    |
| 15.1S      | Not vulnerable |                              |
|            |                | 15.1(3)S                     |
|------------+----------------+------------------------------|
|            |                | 15.1(2)T4                    |
| 15.1T      | 15.1(3)T2      |                              |
|            |                | 15.1(1)T4 on 8-Dec-2011      |
|------------+----------------+------------------------------|
|            | Vulnerable;    |                              |
|            | First fixed in |                              |
|            | Release 15.1T  |                              |
|            |                | Vulnerable; First fixed in   |
| 15.1XB     | Releases up to | Release 15.1T                |
|            | and including  |                              |
|            | 15.1(1)XB are  |                              |
|            | not            |                              |
|            | vulnerable.    |                              |
|------------+----------------+------------------------------|
|  Affected  |  First Fixed   | First Fixed Release for All  |
| 15.2-Based |    Release     | Advisories in the September  |
|  Releases  |                |   2011 Bundled Publication   |
|------------------------------------------------------------|
| There are no affected 15.2 based releases                  |
+------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

Cisco IOS XE Software is not affected by the vulnerability disclosed
in this advisory.

Cisco IOS XR Software
+--------------------

Cisco IOS XR Software is not affected by the vulnerability disclosed
in this advisory.

Cisco IOS XR Software is not affected by the vulnerabilities
disclosed in the September 28, 2011, Cisco IOS Software Security
Advisory bundled publication.

Workarounds
===========

There are no workarounds available to mitigate this vulnerability
other than disabling the Smart Install feature. The Smart Install
Feature is enabled by default in client switches. No configuration is
needed in client switches.

If Smart Install feature is not required, and the device supports
the configuration command "no vstack" as introduced by Cisco Bug
ID CSCtj75729, then disabling Smart Install, with the "no vstack"
configuration command mitigates this vulnerability.

Additional mitigations that can be deployed on Cisco devices within the
network are available in the Cisco Applied Mitigation Bulletin companion
document for this advisory, which is available at the following link:

http://www.cisco.com/warp/public/707/cisco-amb-20110928-smart-install.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address this
vulnerability. Prior to deploying software, customers should consult
their maintenance provider or check the software for feature set
compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature
sets they have purchased. By installing, downloading, accessing
or otherwise using such software upgrades, customers agree to be
bound by the terms of Cisco's software license terms found at
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered and reported to Cisco by Greg Jones
of Digital Assurance.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-smart-install.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+------------------------------------------------------------+
| Revision 1.0 | 2011-September-28 | Initial public release  |
+------------------------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at http://www.cisco.com/en/US/products/
products_security_vulnerability_policy.html. This includes
instructions for press inquiries regarding Cisco security notices.
All Cisco security advisories are available at http://www.cisco.com/
go/psirt.

+--------------------------------------------------------------------
Copyright 2010-2011 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAk6Cp2kACgkQQXnnBKKRMNDdKgD+O6C0i2f0RXM757+tLSehkxsW
NBAYqM590ni6eZvq7PwA/1WW59WEHU0DY2mgou/w2doZmIWczbfihzBwvIUyvHPa
=mkgL
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 28 11:00:00 2011
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 28 Sep 2011 12:00:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software IPS and Zone-Based
 Firewall Vulnerabilities 
Message-ID: <2011092812001.zbfw@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cisco Security Advisory: Cisco IOS Software IPS and Zone-Based
Firewall Vulnerabilities

Advisory ID: cisco-sa-20110928-zbfw

Revision 1.0

For Public Release 2011 September 28 1600 UTC (GMT)

+--------------------------------------------------------------------

Summary
=======

Cisco IOS Software contains two vulnerabilities related to Cisco IOS
Intrusion Prevention System (IPS) and Cisco IOS Zone-Based Firewall
features. These vulnerabilities are:

  * Memory leak in Cisco IOS Software
  * Cisco IOS Software Denial of Service when processing specially
    crafted HTTP packets

Cisco has released free software updates that address these
vulnerabilities.

Workarounds that mitigate these vulnerabilities are not available.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110928-zbfw.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory
bundled publication includes ten Cisco Security Advisories. Nine of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the Cisco IOS Software releases that
correct the vulnerability or vulnerabilities detailed in the advisory as
well as the Cisco IOS Software releases that correct all vulnerabilities
in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Security Advisory Bundled Publication" at the
following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Affected Products
=================

Vulnerable Products
+------------------

Cisco IOS devices running vulnerable versions of Cisco IOS Software
are affected by two vulnerabilities in Cisco IOS IPS and Cisco IOS
Zone-Based Firewall. The two vulnerabilities are independent of each
other. Details to confirm affected configurations are provided below.

  * Memory leak in Cisco IOS Software

    A device that is configured for either Cisco IOS IPS or Cisco IOS
    Zone-Based Firewall (or both), may experience a memory leak under
    high rates of new session creation flows through the device.
    To determine if a device is configured with Cisco IOS IPS, log
    into the device and issue the "show ip ips interfaces" CLI command.
    If the output shows an IPS rule either in the inbound or outbound
    direction set, then the device is vulnerable. This example, shows
    a device with an IPS rule set on Interface Gigabit Ethernet 0/0
    in the inbound direction:

        Router#show ip ips interfaces
            Interface Configuration
              Interface GigabitEthernet0/0
                Inbound IPS rule is example_ips_rule
                Outgoing IPS rule is not set
        Router#

    A device that is not configured for Cisco IOS IPS will return a
    blank line. The following example shows a device on which Cisco
    IOS IPS is not configured:

        Router#show ip ips interfaces

        Router#

    To determine whether a device is configured with Zone-Based
    Firewall, log into the device and issue the "show zone security"
    CLI command. If the output shows a member interface under a zone
    name, then the device is vulnerable. This example, shows a device
    with Zone-Based Firewall rules configured on both
    GigabitEthernet0/0 and GigabitEthernet0/1

        Router#show zone security
        zone self
          Description: System defined zone


        zone inside
          Description: *** Inside Network ***
          Member Interfaces:
            GigabitEthernet0/0


        zone outside
          Description: *** Outside Network ***
          Member Interfaces:
            GigabitEthernet0/1


        Router#

    Note: The device is vulnerable if configured with Zone-Based
    Firewall, regardless of the type of packet inspection being
    performed.

  * Cisco IOS Software Denial of Service when processing specially
    crafted HTTP packets

    A device is vulnerable if configured under the following
    circumstances:

    - HTTP Layer 7 Application Control and Inspection and Cisco IOS
    IPS are enabled.
    - HTTP Layer 7 Application Control and Inspection with match
    request arg regex parameter on the HTTP class map. This
    configuration is affected regardless if Cisco IOS IPS is enabled
    or not.

    The device is not vulnerable under other configurations. A
    summary of different configurations and their affect by this
    vulnerability is provided below:

    +--------------------------------------------------------+
    |                                            | Affected  |
    |          Configuration on Device           |  or not   |
    |                                            | Affected  |
    |--------------------------------------------+-----------|
    | Only Cisco IOS IPS enabled                 | Not       |
    |                                            | Affected  |
    |--------------------------------------------+-----------|
    | HTTP Layer 4 Stateful Inspection with      | Not       |
    | Cisco IOS IPS enabled                      | Affected  |
    |--------------------------------------------+-----------|
    | HTTP Layer 4 Stateful Inspection with      | Not       |
    | Cisco IOS IPS disabled                     | Affected  |
    |--------------------------------------------+-----------|
    | HTTP Layer 7 Application Control and       | Affected  |
    | Inspection with Cisco IOS IPS enabled      |           |
    |--------------------------------------------+-----------|
    | HTTP Layer 7 Application Control and       |           |
    | Inspection with match arg regex parameter. | Affected  |
    | With or without Cisco IOS IPS enabled.     |           |
    |--------------------------------------------+-----------|
    | HTTP Layer 7 Application Control and       |           |
    | Inspection without match arg regex         | Not       |
    | parameter. With or without Cisco IOS IPS   | Affected  |
    | enabled.                                   |           |
    +--------------------------------------------------------+

    The following example shows an affected device configured with
    HTTP Layer 7 Application Control and Inspection and Cisco IOS IPS
    enabled:

        !
        ip ips name myips
        !
        ip ips signature-category
          category all
           retired true
          category ios_ips basic
           retired false
        !
        !
        class-map type inspect match-any layer4-classmap
         match protocol http
        !
        class-map type inspect http match-any layer7-classmap
          match  request arg length gt 15
        !
        !
        policy-map type inspect http layer7-policymap
         class type inspect http layer7-classmap
          reset
          log
        policy-map type inspect layer4-policymap
         class type inspect layer4-classmap
          inspect
          service-policy http layer7-policymap
         class class-default
          drop
        !
        zone security inside
         description ** Inside Network **
        zone security outside
         description ** Outside Network **
        zone-pair security in2out source inside destination outside
         description ** Zone Pair - inside to outside **
         service-policy type inspect layer4-policymap
        !
        !
        interface GigabitEthernet0/0
         ip address 192.168.0.6 255.255.255.0
         ip ips myips in
         zone-member security inside
        !
        interface GigabitEthernet0/1
         ip address 192.168.1.1 255.255.255.0
         zone-member security outside
        !

    The following example shows an affected device configured with
    HTTP Layer 7 Application Control and Inspection with the match
    request arg regex parameter on the HTTP class map:

        !
        parameter-map type regex example
         pattern [^\x00-\x80]
        !
        class-map type inspect match-any layer4-classmap
         match protocol http
        !
        class-map type inspect http match-any layer7-classmap
         match  request arg regex example
        !
        !
        policy-map type inspect http layer7-policymap
         class type inspect http layer7-classmap
          reset
          log
        policy-map type inspect layer4-policymap
         class type inspect layer4-classmap
          inspect
          service-policy http layer7-policymap
         class class-default
          drop
        !
        zone security inside
         description ** Inside Network **
        zone security outside
         description ** Outside Network **
        zone-pair security in2out source inside destination outside
         description ** Zone Pair - inside to outside **
         service-policy type inspect layer4-policymap
        !
        interface GigabitEthernet0/0
         ip address 192.168.0.6 255.255.255.0
         zone-member security inside
        !
        interface GigabitEthernet0/1
         ip address 192.168.1.1 255.255.255.0
         zone-member security outside
        !

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 15.0(1)M1 with an installed image name of
C3900-UNIVERSALK9-M:

    Router> show version
    Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2009 by Cisco Systems, Inc.
    Compiled Wed 02-Dec-09 17:17 by prod_rel_team

    !--- output truncated

Additional information about Cisco IOS Software
release naming conventions is available in the white
paper Cisco IOS and NX-OS Software Reference Guide at
http://www.cisco.com/web/about/security/intelligence/ios-ref.html.

Products Confirmed Not Vulnerable
+--------------------------------

The following products are confirmed not vulnerable:

  * Cisco PIX 500 Series Firewall
  * Cisco ASA 5500 Series Adaptive Security Appliance
  * Firewall Services Module (FWSM) for Catalyst 6500 Series Switches
    and 7600 Series Routers
  * Virtual Firewall (VFW) application on the multiservice blade
    (MSB) on the Cisco XR 12000 Series Router
  * Cisco ACE Application Control Engine Module
  * Cisco IOS devices configured with legacy Cisco IOS Firewall
    Support
  * Cisco IOS XR Software
  * Cisco IOS XE Software
  * Cisco IPS Appliances
  * Cisco Catalyst 6500 Series ASA Services Module
  * Content Based Access Control (CBAC)

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

Firewalls are networking devices that control access to the network
assets of an organization. Firewalls are often positioned at the
entrance points of networks. Cisco IOS Software provides a set of
security features that allow the configuration of a simple or
elaborate firewall policy according to particular requirements.

Cisco IOS IPS is an inline, deep-packet inspection feature that
effectively mitigates a wide range of network attacks.

  * Memory leak in Cisco IOS Software

    Devices with affected configurations may observe a memory leak
    under high rates of new session creation flows through the
    device.

    Logs may indicate a message similar to " *CCE: CCE 7 tuple table
    entry to add not malloced." or "CCE: CCE 7 tuple table adding
    data to invalid hash entry." when the device experiences this
    memory leak.

    The output of show processes memory sorted will show an
    increasing amount of memory being held in the "Chunk Manager"
    process in the "Holding" column. The following example shows the
    output of the "show processes memory sorted" CLI command:

        Router#show processes memory sorted
        Processor Pool Total:  930768768 Used:   90497932 Free:  840270836
              I/O Pool Total:   12582912 Used:    6138704 Free:    6444208

         PID TTY  Allocated      Freed    Holding    Getbufs    Retbufs Process
           1   0  130499156   72333476   58304964          0          0 Chunk Manager

    For this particular vulnerability applying Zone-Based Policy
    Firewall denial of service protection does not protect against
    the memory leak due to Cisco bug ID CSCtq28732.

    This vulnerability is documented in Cisco bug ID CSCti79848 and
    has been assigned Common Vulnerabilities and Exposures (CVE) ID
    CVE-2011-3273.

  * Cisco IOS Software Denial of Service when processing specially
    crafted HTTP packets

    Devices with affected configurations may hang or crash when
    processing a specially crafted HTTP packets.

    If the device supports and is configured with scheduler
    isr-watchdog then the device will reset and reload if the
    vulnerability is exploited, rather than just hang. For more
    information on the "scheduler isr-watchdog" command consult the
    Cisco IOS Configuration Fundamentals Command Reference at the
    following link:
    
    http://www.cisco.com/en/US/docs/ios/fundamentals/command/reference/cf_r1.html#wp1079401

    This vulnerability is documented in Cisco bug ID CSCto68554 and has
    been assigned CVE ID CVE-2011-3281.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerabilities in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss


* CSCti79848 ("Memory leak in Cisco IOS Software when device is
configured with either Cisco IOS IPS or ZBFW")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


* CSCto68554 ("Cisco IOS Software Denial of Service when processing
specially crafted HTTP packets")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


Impact
======

Successful exploitation of these vulnerabilities may result in:

  * Memory leak in Cisco IOS Software

    The device may run out of memory resulting in instability or the
    device crashing.

  * Cisco IOS Software Denial of Service when processing specially
    crafted HTTP packets

    The device may crash or hang. If the device hangs, it will have
    to be power cycled to recover. If the device supports and is
    configured with scheduler isr-watchdog then the device will reset
    and reload if the vulnerability is exploited.

    For more information on the "scheduler isr-watchdog" command
    consult the Cisco IOS Configuration Fundamentals Command
    Reference at the following link:
    
    http://www.cisco.com/en/US/docs/ios/fundamentals/command/reference/cf_r1.html#wp1079401

Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to determine
exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Additionally, the Cisco IOS Software Checker is available on
the Cisco Security Intelligence Operations (SIO) portal at
http://tools.cisco.com/security/center/selectIOSVersion.x. It provides
several features for checking which Security Advisories affect specified
versions of Cisco IOS Software.

Cisco IOS Software
+-----------------

Each row of the following Cisco IOS Software table corresponds to a
Cisco IOS Software train. If a particular train is vulnerable, the
earliest releases that contain the fix are listed in the First Fixed
Release For This Advisory column. The First Fixed Release for All
Advisories in the September 2011 Bundled Publication column lists the
earliest possible releases that correct all the published
vulnerabilities in the Cisco IOS Software Security Advisory bundled
publication. Cisco recommends upgrading to the latest available
release, where possible.

+------------------------------------------------------------+
|   Major    |         Availability of Repaired Releases     |
|  Release   |                                               |
|------------+-----------------------------------------------|
|  Affected  | First Fixed  |  First Fixed Release for All   |
| 12.0-Based | Release for  |  Advisories in the September   |
|  Releases  |     This     |    2011 Bundled Publication    |
|            |   Advisory   |                                |
|------------------------------------------------------------|
| There are no affected 12.0 based releases                  |
|------------------------------------------------------------|
|  Affected  | First Fixed  |  First Fixed Release for All   |
| 12.1-Based | Release for  |  Advisories in the September   |
|  Releases  |     This     |    2011 Bundled Publication    |
|            |   Advisory   |                                |
|------------+--------------+--------------------------------|
| 12.1E      | Not          | 12.2(18)SXF17b                 |
|            | Vulnerable   |                                |
|------------+--------------+--------------------------------|
|  Affected  | First Fixed  |  First Fixed Release for All   |
| 12.2-Based | Release for  |  Advisories in the September   |
|  Releases  |     This     |    2011 Bundled Publication    |
|            |   Advisory   |                                |
|------------+--------------+--------------------------------|
| 12.2       | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
| 12.2B      | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
| 12.2BC     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
| 12.2BW     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2BX     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SB                 |
|------------+--------------+--------------------------------|
| 12.2BY     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2BZ     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2CX     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
| 12.2CY     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2CZ     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SB                 |
|------------+--------------+--------------------------------|
| 12.2DA     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2DD     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2DX     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2EU     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            | Not          | Releases up to and including   |
| 12.2EW     | vulnerable   | 12.2(20)EW4 are not            |
|            |              | vulnerable.                    |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2EWA    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2EX     | Not          | 12.2(55)EX3                    |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2EY     | Not          | 12.2(58)EY                     |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2EZ     | Not          | Vulnerable; migrate to any     |
|            | vulnerable   | release in 15.0SE              |
|------------+--------------+--------------------------------|
| 12.2FX     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SE                 |
|------------+--------------+--------------------------------|
| 12.2FY     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2EX                 |
|------------+--------------+--------------------------------|
| 12.2FZ     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SE                 |
|------------+--------------+--------------------------------|
| 12.2IRA    | Not          | Vulnerable; migrate to any     |
|            | vulnerable   | release in 12.2IRG             |
|------------+--------------+--------------------------------|
| 12.2IRB    | Not          | Vulnerable; migrate to any     |
|            | vulnerable   | release in 12.2IRG             |
|------------+--------------+--------------------------------|
| 12.2IRC    | Not          | Vulnerable; migrate to any     |
|            | vulnerable   | release in 12.2IRG             |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2IRD    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2IRE    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2IRF    | Not          | Vulnerable; migrate to any     |
|            | vulnerable   | release in 12.2IRG             |
|------------+--------------+--------------------------------|
| 12.2IRG    | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2IXA    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2IXB    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2IXC    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2IXD    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2IXE    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2IXF    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2IXG    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2IXH    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2JA     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2JK     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2MB     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2MC     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
| 12.2MRA    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SRD                |
|------------+--------------+--------------------------------|
| 12.2MRB    | Not          | 12.2(33)MRB5                   |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            |              | Releases prior to 12.2(30)S    |
|            | Not          | are vulnerable; Releases 12.2  |
| 12.2S      | vulnerable   | (30)S and later are not        |
|            |              | vulnerable. First fixed in     |
|            |              | Release 12.2SB                 |
|------------+--------------+--------------------------------|
|            | Not          | 12.2(31)SB20                   |
| 12.2SB     | vulnerable   |                                |
|            |              | 12.2(33)SB10                   |
|------------+--------------+--------------------------------|
| 12.2SBC    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SB                 |
|------------+--------------+--------------------------------|
| 12.2SCA    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SCC                |
|------------+--------------+--------------------------------|
| 12.2SCB    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SCC                |
|------------+--------------+--------------------------------|
| 12.2SCC    | Not          | 12.2(33)SCC7                   |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SCD    | Not          | 12.2(33)SCD6                   |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            | Not          | 12.2(33)SCE1                   |
| 12.2SCE    | vulnerable   |                                |
|            |              | 12.2(33)SCE2                   |
|------------+--------------+--------------------------------|
| 12.2SCF    | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            | Not          | 12.2(55)SE3                    |
| 12.2SE     | vulnerable   |                                |
|            |              | 12.2(58)SE                     |
|------------+--------------+--------------------------------|
| 12.2SEA    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SE                 |
|------------+--------------+--------------------------------|
| 12.2SEB    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SE                 |
|------------+--------------+--------------------------------|
| 12.2SEC    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SE                 |
|------------+--------------+--------------------------------|
| 12.2SED    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SE                 |
|------------+--------------+--------------------------------|
| 12.2SEE    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SE                 |
|------------+--------------+--------------------------------|
| 12.2SEF    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SE                 |
|------------+--------------+--------------------------------|
|            |              | Releases prior to 12.2(25)SEG4 |
|            | Not          | are vulnerable; Releases 12.2  |
| 12.2SEG    | vulnerable   | (25)SEG4 and later are not     |
|            |              | vulnerable. First fixed in     |
|            |              | Release 12.2EX                 |
|------------+--------------+--------------------------------|
|            |              | Releases prior to 12.2(53)SG4  |
| 12.2SG     | Not          | are vulnerable; Releases 12.2  |
|            | vulnerable   | (53)SG4 and later are not      |
|            |              | vulnerable.                    |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2SGA    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2SL     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2SM     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2SO     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SQ     | Not          | 12.2(50)SQ3                    |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SRA    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SRD                |
|------------+--------------+--------------------------------|
| 12.2SRB    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SRD                |
|------------+--------------+--------------------------------|
| 12.2SRC    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SRD                |
|------------+--------------+--------------------------------|
| 12.2SRD    | Not          | 12.2(33)SRD6                   |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SRE    | Not          | 12.2(33)SRE4                   |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2STE    | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SU     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
|            |              | Releases prior to 12.2(29a)SV  |
|            | Not          | are vulnerable; Releases 12.2  |
| 12.2SV     | vulnerable   | (29a)SV and later are not      |
|            |              | vulnerable. Migrate to any     |
|            |              | release in 12.2SVD             |
|------------+--------------+--------------------------------|
| 12.2SVA    | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SVC    | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SVD    | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SVE    | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2SW     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2SX     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SXF                |
|------------+--------------+--------------------------------|
| 12.2SXA    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SXF                |
|------------+--------------+--------------------------------|
| 12.2SXB    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SXF                |
|------------+--------------+--------------------------------|
| 12.2SXD    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SXF                |
|------------+--------------+--------------------------------|
| 12.2SXE    | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SXF                |
|------------+--------------+--------------------------------|
| 12.2SXF    | Not          | 12.2(18)SXF17b                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SXH    | Not          | 12.2(33)SXH8a                  |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SXI    | Not          | 12.2(33)SXI6                   |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SXJ    | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SY     | Not          | 12.2(50)SY                     |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2SZ     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SB                 |
|------------+--------------+--------------------------------|
| 12.2T      | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2TPC    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2XA     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XB     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
| 12.2XC     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XD     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XE     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XF     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XG     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XH     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XI     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XJ     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XK     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XL     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XM     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XN     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            | See Cisco    |                                |
| 12.2XNA    | IOS-XE       | See Cisco IOS-XE Software      |
|            | Software     | Availability                   |
|            | Availability |                                |
|------------+--------------+--------------------------------|
|            | See Cisco    |                                |
| 12.2XNB    | IOS-XE       | See Cisco IOS-XE Software      |
|            | Software     | Availability                   |
|            | Availability |                                |
|------------+--------------+--------------------------------|
|            | See Cisco    |                                |
| 12.2XNC    | IOS-XE       | See Cisco IOS-XE Software      |
|            | Software     | Availability                   |
|            | Availability |                                |
|------------+--------------+--------------------------------|
|            | See Cisco    |                                |
| 12.2XND    | IOS-XE       | See Cisco IOS-XE Software      |
|            | Software     | Availability                   |
|            | Availability |                                |
|------------+--------------+--------------------------------|
|            | See Cisco    |                                |
| 12.2XNE    | IOS-XE       | See Cisco IOS-XE Software      |
|            | Software     | Availability                   |
|            | Availability |                                |
|------------+--------------+--------------------------------|
|            | See Cisco    |                                |
| 12.2XNF    | IOS-XE       | See Cisco IOS-XE Software      |
|            | Software     | Availability                   |
|            | Availability |                                |
|------------+--------------+--------------------------------|
|            |              | Releases prior to 12.2(54)XO   |
| 12.2XO     | Not          | are vulnerable; Releases 12.2  |
|            | vulnerable   | (54)XO and later are not       |
|            |              | vulnerable.                    |
|------------+--------------+--------------------------------|
| 12.2XQ     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XR     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XS     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XT     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XU     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XV     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2XW     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2YA     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
| 12.2YB     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2YC     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2YD     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2YE     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YF     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YG     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YH     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YJ     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2YK     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YL     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2YM     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YN     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2YO     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2YP     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YQ     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YR     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YS     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YT     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YU     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YV     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YW     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YX     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YY     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2YZ     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2ZA     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SXF                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2ZB     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2ZC     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2ZD     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2ZE     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
| 12.2ZF     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
| 12.2ZG     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2ZH     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.4                   |
|------------+--------------+--------------------------------|
| 12.2ZJ     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2ZL     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 12.2ZP     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
| 12.2ZU     | Not          | Vulnerable; first fixed in     |
|            | vulnerable   | Release 12.2SXH                |
|------------+--------------+--------------------------------|
| 12.2ZX     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2ZY     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 12.2ZYA    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|  Affected  | First Fixed  |  First Fixed Release for All   |
| 12.3-Based | Release for  |  Advisories in the September   |
|  Releases  |     This     |    2011 Bundled Publication    |
|            |   Advisory   |                                |
|------------------------------------------------------------|
| There are no affected 12.3 based releases                  |
|------------------------------------------------------------|
|  Affected  | First Fixed  |  First Fixed Release for All   |
| 12.4-Based | Release for  |  Advisories in the September   |
|  Releases  |     This     |    2011 Bundled Publication    |
|            |   Advisory   |                                |
|------------------------------------------------------------|
| There are no affected 12.4 based releases                  |
|------------------------------------------------------------|
|  Affected  | First Fixed  |  First Fixed Release for All   |
| 15.0-Based | Release for  |  Advisories in the September   |
|  Releases  |     This     |    2011 Bundled Publication    |
|            |   Advisory   |                                |
|------------+--------------+--------------------------------|
| 15.0M      | 15.0(1)M7    | 15.0(1)M7                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 15.0MR     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 15.0MRA    | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            | See Cisco    |                                |
| 15.0S      | IOS-XE       | See Cisco IOS-XE Software      |
|            | Software     | Availability                   |
|            | Availability |                                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 15.0SA     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
| 15.0SE     | Not          | Not vulnerable                 |
|            | vulnerable   |                                |
|------------+--------------+--------------------------------|
|            | See Cisco    |                                |
| 15.0SG     | IOS-XE       | See Cisco IOS-XE Software      |
|            | Software     | Availability                   |
|            | Availability |                                |
|------------+--------------+--------------------------------|
|            | Vulnerable;  |                                |
| 15.0XA     | first fixed  | Vulnerable; first fixed in     |
|            | in Release   | Release 15.1T                  |
|            | 15.1T        |                                |
|------------+--------------+--------------------------------|
|            | See Cisco    |                                |
| 15.0XO     | IOS-XE       | See Cisco IOS-XE Software      |
|            | Software     | Availability                   |
|            | Availability |                                |
|------------+--------------+--------------------------------|
|  Affected  | First Fixed  |  First Fixed Release for All   |
| 15.1-Based | Release for  |  Advisories in the September   |
|  Releases  |     This     |    2011 Bundled Publication    |
|            |   Advisory   |                                |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 15.1EY     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            | Vulnerable;  |                                |
| 15.1GC     | first fixed  | Vulnerable; first fixed in     |
|            | in Release   | Release 15.1T                  |
|            | 15.1T        |                                |
|------------+--------------+--------------------------------|
| 15.1M      | 15.1(4)M1    | 15.1(4)M2; Available on        |
|            |              | 30-SEP-11                      |
|------------+--------------+--------------------------------|
|            |              | Vulnerable; contact your       |
|            | Not          | support organization per the   |
| 15.1MR     | vulnerable   | instructions in the Obtaining  |
|            |              | Fixed Software section of this |
|            |              | advisory.                      |
|------------+--------------+--------------------------------|
|            | See Cisco    |                                |
| 15.1S      | IOS-XE       | See Cisco IOS-XE Software      |
|            | Software     | Availability                   |
|            | Availability |                                |
|------------+--------------+--------------------------------|
|            | 15.1(1)T4;   |                                |
|            | Available on |                                |
|            | 08-Dec-2011  | 15.1(2)T4                      |
| 15.1T      |              |                                |
|            | 15.1(2)T4    | 15.1(1)T4 on 8-Dec-2011        |
|            |              |                                |
|            | 15.1(3)T2    |                                |
|------------+--------------+--------------------------------|
|            | Vulnerable;  |                                |
| 15.1XB     | first fixed  | Vulnerable; first fixed in     |
|            | in Release   | Release 15.1T                  |
|            | 15.1T        |                                |
|------------+--------------+--------------------------------|
|  Affected  | First Fixed  |  First Fixed Release for All   |
| 15.2-Based | Release for  |  Advisories in the September   |
|  Releases  |     This     |    2011 Bundled Publication    |
|            |   Advisory   |                                |
|------------------------------------------------------------|
| There are no affected 15.2 based releases                  |
+------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

Cisco IOS XE Software is not affected by the vulnerabilities
disclosed in this document.

+------------------------------------------------------------+
|  Cisco   |  First Fixed   |  First Fixed Release for All   |
|  IOS XE  |  Release For   |  Advisories in the September   |
| Release  | This Advisory  |    2011 Bundled Publication    |
|----------+----------------+--------------------------------|
| 2.1.x    | Not vulnerable | Vulnerable; migrate to 3.3.2S  |
|          |                | or later                       |
|----------+----------------+--------------------------------|
| 2.2.x    | Not vulnerable | Vulnerable; migrate to 3.3.2S  |
|          |                | or later                       |
|----------+----------------+--------------------------------|
| 2.3.x    | Not vulnerable | Vulnerable; migrate to 3.3.2S  |
|          |                | or later                       |
|----------+----------------+--------------------------------|
| 2.4.x    | Not vulnerable | Vulnerable; migrate to 3.3.2S  |
|          |                | or later                       |
|----------+----------------+--------------------------------|
| 2.5.x    | Not vulnerable | Vulnerable; migrate to 3.3.2S  |
|          |                | or later                       |
|----------+----------------+--------------------------------|
| 2.6.x    | Not vulnerable | Vulnerable; migrate to 3.3.2S  |
|          |                | or later                       |
|----------+----------------+--------------------------------|
| 3.1.xS   | Not vulnerable | Vulnerable; migrate to 3.3.2S  |
|          |                | or later                       |
|----------+----------------+--------------------------------|
| 3.1.xSG  | Not vulnerable | Vulnerable; migrate to 3.2.0SG |
|          |                | or later                       |
|----------+----------------+--------------------------------|
| 3.2.xS   | Not vulnerable | Vulnerable; migrate to 3.3.2S  |
|          |                | or later                       |
|----------+----------------+--------------------------------|
| 3.2.xSG  | Not vulnerable | Not vulnerable                 |
|----------+----------------+--------------------------------|
| 3.3.xS   | Not vulnerable | 3.3.2S                         |
|----------+----------------+--------------------------------|
| 3.4.xS   | Not vulnerable | Not vulnerable                 |
+------------------------------------------------------------+

For mapping of Cisco IOS XE to Cisco IOS releases, please refer to
the Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and
Cisco IOS XE 3SG Release Notes.

Cisco IOS XR Software
+--------------------

Cisco IOS XR Software is not affected by the vulnerabilities
disclosed in this document.

Cisco IOS XR Software is not affected by any of the vulnerabilities
in the September 2011 bundled publication.

Workarounds
===========

Workarounds that mitigate these vulnerabilities are not available.

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature
sets they have purchased. By installing, downloading, accessing
or otherwise using such software upgrades, customers agree to be
bound by the terms of Cisco's software license terms found at
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerabilities described in this advisory.

These vulnerabilities were discovered while handling customer support
calls.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-zbfw.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+------------------------------------------------------------+
| Revision 1.0 | 2011-September-28 | Initial public release. |
+------------------------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities
in Cisco products, obtaining assistance with security
incidents, and registering to receive security information
from Cisco, is available on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
This includes instructions for press inquiries regarding
Cisco security notices. All Cisco security advisories are available at
http://www.cisco.com/go/psirt.

+--------------------------------------------------------------------
Copyright 2010-2011 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAk6Cp2wACgkQQXnnBKKRMNDczwD8CQbBRLSBdYML0id/QNwXTCO0
lKPvItw21VC8zN6eF1YA/3GNLczrQt1qm1NAFMnhNbQxWryUh7MiZLcVRQ+UA3HW
=pHTr
-----END PGP SIGNATURE-----


From Valdis.Kletnieks at vt.edu  Wed Sep 28 12:00:30 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 28 Sep 2011 13:00:30 -0400
Subject: Nxdomain redirect revenue
In-Reply-To: Your message of "Tue, 27 Sep 2011 16:09:03 PDT."
 <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAL9jLaaOdE3djf6UnYGwdBnuGRnQ3iMbc+QAMT4nYtKL5LDhdg@mail.gmail.com>
 <CAAAwwbWSRk_gtngLRg=nQHSQRGG80J__DY6fUhs_aHcxO5bMaw@mail.gmail.com>
 <CAE4VuKFASMmaNnDexDfF_8YiEp8dmL6vE+4Y2Cmx3X38GqTtjA@mail.gmail.com>
 <CAAAwwbVLmh+MsXU-axOy=twz+oWvszyZ3O8n-bMqpna4tR7Xtg@mail.gmail.com>
 <67EF0A3B-714E-4856-9E85-8D1B1E9AC150@delong.com>
Message-ID: <9965.1317229230@turing-police.cc.vt.edu>

On Tue, 27 Sep 2011 16:09:03 PDT, Owen DeLong said:
> No, it isn't because it requires you to send the domain portion of the URL
> in clear text and it may be that you don't necessarily want to disclose even
> that much information about your browsing to the public.

If that's an actual concern, I suggest you talk to the nice people at
https://www.torproject.org/  - and remember that tor was originally
designed by the US government so our spooks could fly under the wire,
so it's patriotic to run a tor relay. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110928/fe374c61/attachment.bin>

From psirt at cisco.com  Wed Sep 28 11:00:00 2011
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 28 Sep 2011 12:00:00 -0400
Subject: Cisco Security Advisory: Cisco 10000 Series Denial of Service
 Vulnerability 
Message-ID: <2011092812001.c10k@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cisco Security Advisory: Cisco 10000 Series Denial of Service
Vulnerability

Advisory ID: cisco-sa-20110928-c10k

Revision 1.0

For Public Release 2011 September 28 1600 UTC (GMT)

+---------------------------------------------------------------------

Summary
=======

The Cisco 10000 Series Router is affected by a denial of service
(DoS) vulnerability that can allow an attacker to cause a device
reload by sending a series of ICMP packets.

Cisco has released free software updates that address this
vulnerability.

Workarounds that mitigate this vulnerability are also available.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110928-c10k.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory
bundled publication includes ten Cisco Security Advisories. Nine of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the Cisco IOS Software releases that
correct the vulnerability or vulnerabilities detailed in the advisory as
well as the Cisco IOS Software releases that correct all vulnerabilities
in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Security Advisory Bundled Publication" at the
following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Affected Products
=================

Vulnerable Products
+------------------

Cisco 10000 Series Routers that are running an affected version of
Cisco IOS are affected.

To determine the Cisco IOS Software release that is running on a Cisco
product, administrators can log in to the device and issue the "show
version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or "Cisco
IOS Software." The image name displays in parentheses, followed by
"Version" and the Cisco IOS Software release name. Other Cisco devices
do not have the "show version" command or may provide different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 15.0(1)M1 with an installed image name of
C3900-UNIVERSALK9-M:

    Router> show version
    Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2009 by Cisco Systems, Inc.
    Compiled Wed 02-Dec-09 17:17 by prod_rel_team

    !--- output truncated

Additional information about Cisco IOS Software release naming
conventions is available in the white paper Cisco IOS and NX-OS
Software Reference Guide available at:

http://www.cisco.com/web/about/security/intelligence/ios-ref.html.

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS XR Software is not affected by this vulnerability.

Cisco IOS XE Software is not affected by this vulnerability.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

The Cisco 10000 Series Router is affected by a denial of service
(DoS) vulnerability where an unauthenticated attacker could cause a
device reload by sending a series of ICMP packets.

Traffic destined to the device or transit traffic could trigger the
effects of this vulnerability.

This vulnerability is documented in Cisco Bug ID CSCtk62453 and has been
assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2011-3270.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss


* CSCtk62453 ("Certain ICMP packets may cause device to reload")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed

Impact
======

Successful exploitation of this vulnerability could cause an affected
device to reload. Repeated exploitation could result in a sustained
DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to determine
exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Additionally, the Cisco IOS Software Checker is available on
the Cisco Security Intelligence Operations (SIO) portal at
http://tools.cisco.com/security/center/selectIOSVersion.x. It provides
several features for checking which Security Advisories affect specified
versions of Cisco IOS Software.

Cisco IOS Software
+-----------------

Each row of the following Cisco IOS Software table corresponds to a
Cisco IOS Software train. If a particular train is vulnerable, the
earliest releases that contain the fix are listed in the First Fixed
Release For This Advisory column. The First Fixed Release for All
Advisories in the September 2011 Bundled Publication column lists the
earliest possible releases that correct all the published
vulnerabilities in the Cisco IOS Software Security Advisory bundled
publication. Cisco recommends upgrading to the latest available
release, where possible.

+------------------------------------------------------------+
|   Major    |         Availability of Repaired Releases     |
|  Release   |                                               |
|------------+-----------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 12.0-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 12.0 based releases                  |
|------------------------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 12.1-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 12.1 based releases                  |
|------------------------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 12.2-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------+------------------+----------------------------|
| 12.2       | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
| 12.2B      | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
| 12.2BC     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
| 12.2BW     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2BX     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SB             |
|------------+------------------+----------------------------|
| 12.2BY     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2BZ     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2CX     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
| 12.2CY     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2CZ     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SB             |
|------------+------------------+----------------------------|
| 12.2DA     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2DD     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2DX     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2EU     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            |                  | Releases up to and         |
| 12.2EW     | Not vulnerable   | including 12.2(20)EW4 are  |
|            |                  | not vulnerable.            |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2EWA    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2EX     | Not vulnerable   | 12.2(55)EX3                |
|------------+------------------+----------------------------|
| 12.2EY     | Not vulnerable   | 12.2(58)EY                 |
|------------+------------------+----------------------------|
| 12.2EZ     | Not vulnerable   | Vulnerable; migrate to any |
|            |                  | release in 15.0SE          |
|------------+------------------+----------------------------|
| 12.2FX     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SE             |
|------------+------------------+----------------------------|
| 12.2FY     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2EX             |
|------------+------------------+----------------------------|
| 12.2FZ     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SE             |
|------------+------------------+----------------------------|
| 12.2IRA    | Not vulnerable   | Vulnerable; migrate to any |
|            |                  | release in 12.2IRG         |
|------------+------------------+----------------------------|
| 12.2IRB    | Not vulnerable   | Vulnerable; migrate to any |
|            |                  | release in 12.2IRG         |
|------------+------------------+----------------------------|
| 12.2IRC    | Not vulnerable   | Vulnerable; migrate to any |
|            |                  | release in 12.2IRG         |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2IRD    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2IRE    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2IRF    | Not vulnerable   | Vulnerable; migrate to any |
|            |                  | release in 12.2IRG         |
|------------+------------------+----------------------------|
| 12.2IRG    | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2IXA    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2IXB    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2IXC    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2IXD    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2IXE    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2IXF    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2IXG    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2IXH    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2JA     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2JK     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2MB     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2MC     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
| 12.2MRA    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SRD            |
|------------+------------------+----------------------------|
| 12.2MRB    | Not vulnerable   | 12.2(33)MRB5               |
|------------+------------------+----------------------------|
|            |                  | 12.2(30)S are vulnerable;  |
|            |                  | Releases12.2(30)S and      |
| 12.2S      | Not vulnerable   | later are not vulnerable.  |
|            |                  | First fixed in Release     |
|            |                  | 12.2SB                     |
|------------+------------------+----------------------------|
|            | Releases prior   |                            |
|            | to 12.2(31)SB18  |                            |
|            | and 12.2(33)SB9  | 12.2(31)SB20               |
| 12.2SB     | are not          |                            |
|            | vulnerable.      | 12.2(33)SB10               |
|            |                  |                            |
|            | 12.2(33)SB10     |                            |
|------------+------------------+----------------------------|
| 12.2SBC    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SB             |
|------------+------------------+----------------------------|
| 12.2SCA    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SCC            |
|------------+------------------+----------------------------|
| 12.2SCB    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SCC            |
|------------+------------------+----------------------------|
| 12.2SCC    | Not vulnerable   | 12.2(33)SCC7               |
|------------+------------------+----------------------------|
| 12.2SCD    | Not vulnerable   | 12.2(33)SCD6               |
|------------+------------------+----------------------------|
|            |                  | 12.2(33)SCE1               |
| 12.2SCE    | Not vulnerable   |                            |
|            |                  | 12.2(33)SCE2               |
|------------+------------------+----------------------------|
| 12.2SCF    | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            |                  | 12.2(55)SE3                |
| 12.2SE     | Not vulnerable   |                            |
|            |                  | 12.2(58)SE                 |
|------------+------------------+----------------------------|
| 12.2SEA    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SE             |
|------------+------------------+----------------------------|
| 12.2SEB    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SE             |
|------------+------------------+----------------------------|
| 12.2SEC    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SE             |
|------------+------------------+----------------------------|
| 12.2SED    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SE             |
|------------+------------------+----------------------------|
| 12.2SEE    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SE             |
|------------+------------------+----------------------------|
| 12.2SEF    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SE             |
|------------+------------------+----------------------------|
|            |                  | Releases prior to 12.2(25) |
|            |                  | SEG4 are vulnerable;       |
| 12.2SEG    | Not vulnerable   | Releases12.2(25)SEG4 and   |
|            |                  | later are not vulnerable.  |
|            |                  | First fixed in Release     |
|            |                  | 12.2EX                     |
|------------+------------------+----------------------------|
|            |                  | Releases prior to 12.2(53) |
| 12.2SG     | Not vulnerable   | SG4 are vulnerable;        |
|            |                  | Releases 12.2(53)SG4 and   |
|            |                  | later are not vulnerable.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2SGA    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2SL     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2SM     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2SO     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2SQ     | Not vulnerable   | 12.2(50)SQ3                |
|------------+------------------+----------------------------|
| 12.2SRA    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SRD            |
|------------+------------------+----------------------------|
| 12.2SRB    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SRD            |
|------------+------------------+----------------------------|
| 12.2SRC    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SRD            |
|------------+------------------+----------------------------|
| 12.2SRD    | Not vulnerable   | 12.2(33)SRD6               |
|------------+------------------+----------------------------|
| 12.2SRE    | Not vulnerable   | 12.2(33)SRE4               |
|------------+------------------+----------------------------|
| 12.2STE    | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2SU     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
|            |                  | Releases prior to 12.2     |
|            |                  | (29a)SV are vulnerable;    |
| 12.2SV     | Not vulnerable   | Releases 12.2(29a)SV and   |
|            |                  | later are not vulnerable.  |
|            |                  | Migrate to any release in  |
|            |                  | 12.2SVD                    |
|------------+------------------+----------------------------|
| 12.2SVA    | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2SVC    | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2SVD    | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2SVE    | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2SW     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2SX     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SXF            |
|------------+------------------+----------------------------|
| 12.2SXA    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SXF            |
|------------+------------------+----------------------------|
| 12.2SXB    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SXF            |
|------------+------------------+----------------------------|
| 12.2SXD    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SXF            |
|------------+------------------+----------------------------|
| 12.2SXE    | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SXF            |
|------------+------------------+----------------------------|
| 12.2SXF    | Not vulnerable   | 12.2(18)SXF17b             |
|------------+------------------+----------------------------|
| 12.2SXH    | Not vulnerable   | 12.2(33)SXH8a              |
|------------+------------------+----------------------------|
| 12.2SXI    | Not vulnerable   | 12.2(33)SXI6               |
|------------+------------------+----------------------------|
| 12.2SXJ    | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2SY     | Not vulnerable   | 12.2(50)SY                 |
|------------+------------------+----------------------------|
| 12.2SZ     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SB             |
|------------+------------------+----------------------------|
| 12.2T      | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2TPC    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2XA     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XB     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
| 12.2XC     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XD     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XE     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XF     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XG     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XH     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XI     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XJ     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XK     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XL     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XM     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XN     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            | Please see Cisco | Please see Cisco IOS-XE    |
| 12.2XNA    | IOS-XE Software  | Software Availability      |
|            | Availability     |                            |
|------------+------------------+----------------------------|
|            | Please see Cisco | Please see Cisco IOS-XE    |
| 12.2XNB    | IOS-XE Software  | Software Availability      |
|            | Availability     |                            |
|------------+------------------+----------------------------|
|            | Please see Cisco | Please see Cisco IOS-XE    |
| 12.2XNC    | IOS-XE Software  | Software Availability      |
|            | Availability     |                            |
|------------+------------------+----------------------------|
|            | Please see Cisco | Please see Cisco IOS-XE    |
| 12.2XND    | IOS-XE Software  | Software Availability      |
|            | Availability     |                            |
|------------+------------------+----------------------------|
|            | Please see Cisco | Please see Cisco IOS-XE    |
| 12.2XNE    | IOS-XE Software  | Software Availability      |
|            | Availability     |                            |
|------------+------------------+----------------------------|
|            | Please see Cisco | Please see Cisco IOS-XE    |
| 12.2XNF    | IOS-XE Software  | Software Availability      |
|            | Availability     |                            |
|------------+------------------+----------------------------|
|            |                  | Releases prior to 12.2(54) |
| 12.2XO     | Not vulnerable   | XO are vulnerable;         |
|            |                  | Releases12.2(54)XO and     |
|            |                  | later are not vulnerable.  |
|------------+------------------+----------------------------|
| 12.2XQ     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XR     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XS     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XT     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XU     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XV     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2XW     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2YA     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
| 12.2YB     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2YC     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2YD     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2YE     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YF     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YG     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YH     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YJ     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2YK     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YL     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2YM     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YN     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2YO     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2YP     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YQ     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YR     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YS     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YT     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YU     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YV     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YW     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YX     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YY     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2YZ     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2ZA     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SXF            |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2ZB     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2ZC     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2ZD     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2ZE     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
| 12.2ZF     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
| 12.2ZG     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2ZH     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.4               |
|------------+------------------+----------------------------|
| 12.2ZJ     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2ZL     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 12.2ZP     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 12.2ZU     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 12.2SXH            |
|------------+------------------+----------------------------|
| 12.2ZX     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2ZY     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 12.2ZYA    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 12.3-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 12.3 based releases                  |
|------------------------------------------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 12.4-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 12.4 based releases                  |
|------------------------------------------------------------|
|  Affected  |   First Fixed    |                            |
| 15.0-Based |     Release      | Bundle First Fixed Release |
|  Releases  |                  |                            |
|------------+------------------+----------------------------|
| 15.0M      | Not vulnerable   | 15.0(1)M7                  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 15.0MR     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 15.0MRA    | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 15.0S      | 15.0(1)S3a       | 15.0(1)S4                  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 15.0SA     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 15.0SE     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 15.0SG     | Not vulnerable   | Not vulnerable             |
|------------+------------------+----------------------------|
| 15.0XA     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 15.1T              |
|------------+------------------+----------------------------|
|            |                  | Releases prior to 15.0(2)  |
| 15.0XO     | Not vulnerable   | XO1 are vulnerable;        |
|            |                  | Releases15.0(2)XO1 and     |
|            |                  | later are not vulnerable.  |
|------------+------------------+----------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 15.1-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 15.1EY     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
| 15.1GC     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 15.1T              |
|------------+------------------+----------------------------|
| 15.1M      | Not vulnerable   | 15.1(4)M2; Available on    |
|            |                  | 30-SEP-11                  |
|------------+------------------+----------------------------|
|            |                  | Vulnerable; contact your   |
|            |                  | support organization per   |
| 15.1MR     | Not vulnerable   | the instructions in the    |
|            |                  | Obtaining Fixed Software   |
|            |                  | section of this advisory.  |
|------------+------------------+----------------------------|
|            |                  | 15.1(2)S2                  |
| 15.1S      | Not vulnerable   |                            |
|            |                  | 15.1(3)S                   |
|------------+------------------+----------------------------|
|            |                  | 15.1(2)T4                  |
| 15.1T      | Not vulnerable   |                            |
|            |                  | 15.1(1)T4 on 8-Dec-2011    |
|------------+------------------+----------------------------|
| 15.1XB     | Not vulnerable   | Vulnerable; First fixed in |
|            |                  | Release 15.1T              |
|------------+------------------+----------------------------|
|  Affected  |                  |  First Fixed Release for   |
| 15.2-Based |   First Fixed    |   All Advisories in the    |
|  Releases  |     Release      |   September 2011 Bundled   |
|            |                  |        Publication         |
|------------------------------------------------------------|
| There are no affected 15.2 based releases                  |
+------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

Cisco IOS XE Software is not affected by the vulnerability disclosed
in this advisory.

Cisco IOS XR Software
+--------------------

Cisco IOS XR Software is not affected by the vulnerability disclosed
in this advisory.

Cisco IOS XR Software is not affected by the vulnerabilities
disclosed in the September 28, 2011, Cisco IOS Software Security
Advisory bundled publication.

Workarounds
===========

Traffic destined to the device or transit traffic could trigger the
effects of this vulnerability. Subsequently, the only workaround
available is to block ICMP packets destined to the affected device
and all ICMP transit traffic.

Obtaining Fixed Software
========================

Cisco has released free software updates that address this
vulnerability. Prior to deploying software, customers should consult
their maintenance provider or check the software for feature set
compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature
sets they have purchased. By installing, downloading, accessing
or otherwise using such software upgrades, customers agree to be
bound by the terms of Cisco's software license terms found at
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered while troubleshooting a customer
service request.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-c10k.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+------------------------------------------------------------+
| Revision 1.0 | 2011-September-28 | Initial public release  |
+------------------------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities
in Cisco products, obtaining assistance with security
incidents, and registering to receive security information
from Cisco, is available on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
This includes instructions for press inquiries regarding
Cisco security notices. All Cisco security advisories are available at
http://www.cisco.com/ go/psirt.

+--------------------------------------------------------------------
Copyright 2010-2011 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAk6Cp14ACgkQQXnnBKKRMNBOWAD/YQDJsUpQlEAe+4lUl7/WGqtg
yCddHaRTE9faZTPn4OkA+weoFjsiEbq4xztfYsQkSsApLSXq4/WdiUCfd/tucqrW
=kYjE
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 28 11:00:00 2011
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 28 Sep 2011 12:00:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Network Address
 Translation Vulnerabilities 
Message-ID: <2011092812001.nat@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cisco Security Advisory: Cisco IOS Software Network Address
Translation Vulnerabilities

Advisory ID: cisco-sa-20110928-nat

Revision 1.0

For Public Release 2011 Sep 28 1600 UTC (GMT)

+--------------------------------------------------------------------

Summary
=======

The Cisco IOS Software network address translation (NAT) feature
contains multiple denial of service (DoS) vulnerabilities in the
translation of the following protocols:

  * NetMeeting Directory (Lightweight Directory Access Protocol,
    LDAP)
  * Session Initiation Protocol (Multiple vulnerabilities)
  * H.323 protocol

All the vulnerabilities described in this document are caused by
packets in transit on the affected devices when those packets require
application layer translation.

Cisco has released free software updates that address these
vulnerabilities.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110928-nat.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory
bundled publication includes ten Cisco Security Advisories. Nine of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the Cisco IOS Software releases that
correct the vulnerability or vulnerabilities detailed in the advisory as
well as the Cisco IOS Software releases that correct all vulnerabilities
in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Security Advisory Bundled Publication" at the
following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Affected Products
=================

Vulnerable Products
+------------------

Cisco devices that are running Cisco IOS Software are vulnerable when
they are configured for NAT and contain support for one or more of
the following features:

  * NetMeeting Directory NAT (LDAP on TCP port 389)
  * NAT for Session Initiation Protocol (SIP)
  * NAT for H.323

The preferred method to verify whether NAT is enabled on a Cisco IOS
device is to log in to the device and issue the "show ip nat
statistics" command. If NAT is active the sections Outside interfaces
and Inside interfaces will each include at least one interface. The
following example shows a device on which the NAT feature is active:

    Router#show ip nat statistics

    Total translations: 2 (0 static, 2 dynamic; 0 extended)
    Outside interfaces: Serial0
    Inside interfaces: Ethernet1
    Hits: 135  Misses: 5
    Expired translations: 2
    Dynamic mappings:
    -- Inside Source
    access-list 1 pool mypool refcount 2
     pool mypool: netmask 255.255.255.0
            start 192.168.10.1 end 192.168.10.254
            type generic, total addresses 14, allocated 2 (14%), misses 0

Depending on the Cisco IOS Software release, the interface lists can
be in the lines following the Outside interfaces and Inside
interfaces lines. In releases that support the section filter on show
commands, the administrator can determine whether NAT is active by
using the "show ip nat statistics | section interfaces" command:

    Router> show ip nat statistics | section interfaces
    Outside interfaces:
      GigabitEthernet0/0
    Inside interfaces:
      GigabitEthernet0/1
    Router>

Alternatively, to determine whether NAT has been enabled in the Cisco
IOS Software configuration, either the "ip nat inside" and "ip nat
outside" commands must be present in different interfaces or, in the
case of the NAT Virtual Interface, the "ip nat enable" interface command
will be present.

To determine the Cisco IOS Software release that is running on a Cisco
product, administrators can log in to the device and issue the "show
version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or "Cisco
IOS Software." The image name displays in parentheses, followed by
"Version" and the Cisco IOS Software release name. Other Cisco devices
do not have the "show version" command or may provide different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 15.0(1)M1 with an installed image name of
C3900-UNIVERSALK9-M:

    Router> show version
    Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2009 by Cisco Systems, Inc.
    Compiled Wed 02-Dec-09 17:17 by prod_rel_team


    !--- output truncated


Additional information about Cisco IOS Software release naming
conventions is available in White Paper: Cisco IOS and NX-OS Software
Reference Guide.

Products Confirmed Not Vulnerable
+--------------------------------

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

NAT for NetMeeting Directory (LDAP) Vulnerability
+------------------------------------------------

LDAP is a protocol for querying and modifying data of directory
services implemented in IP networks. NAT for NetMeeting Directory,
also known as the Internet Locator Service (ILS), translates LDAP
packets on TCP port 389. The inspected port is not configurable.

This vulnerability is triggered by malformed transit LDAP traffic
that needs to be processed by the NAT for NetMeeting Directory
feature.

This vulnerability is documented in Cisco bug ID CSCtd10712 and has been
assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2011-0946.

NAT for SIP DoS Vulnerabilities
+------------------------------

Four vulnerabilities in the NAT for SIP feature are described in this
document:

NAT of SIP over TCP vulnerability: Crafted SIP packets on TCP port
5060 could cause unpredictable results, including the reload of the
vulnerable device. Translation of SIP over TCP packets will be disabled
by default with the fix for this vulnerability. This vulnerability is
documented in Cisco bug ID CSCso02147 and has been assigned Common
Vulnerabilities and Exposures CVE-2011-3276.

Provider edge Multiprotocol Label Switching (MPLS) NAT of SIP over UDP
packets DoS vulnerability: A malformed SIP packet on UDP 5060 that
transits an MPLS enabled vulnerable device that needs an MPLS tag
to be imposed on the malformed packet might reload the device. This
vulnerability is documented in Cisco bug ID CSCti98219 and has been
assigned CVE ID CVE-2011-3279.

NAT of crafted SIP over UDP packets DoS vulnerabilities: There are two
DoS vulnerabilities related to similar crafted packets on UDP port 5060
that require SIP translation: the first is a vulnerability that will
cause the device to reload and the second will cause a memory leak
that could lead to a DoS condition, including reload of the vulnerable
device. The NAT of SIP vulnerabilities are documented in Cisco bug ID
CSCti48483 and Cisco bug ID CSCtj04672. They have been assigned CVE IDs
CVE-2011-3278 and CVE-2011-3280.

NAT of H.323 Packets DoS Vulnerability
+-------------------------------------

Transit crafted H.323 packets on TCP port 1720 could cause a reload of
the vulnerable device. This vulnerability is documented in Cisco bug ID
CSCth11006 and has been assigned Common Vulnerabilities and Exposures
(CVE) ID CVE-2011-3277.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerabilities in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss


* CSCtd10712 ("NAT LDAP Vulnerability")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


* CSCso02147 ("NAT of SIP over TCP Vulnerability")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


* CSCti98219 ("Provider-Edge MPLS NAT of SIP over UDP packets
Vulnerability")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


* CSCti48483/CSCtj04672 ("NAT of crafted SIP packets vulnerabilities")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


* CSCth11006 ("NAT of H.323 Packets DoS Vulnerability")

CVSS Base Score - 7.8
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           None
    Confidentiality Impact -   None
    Integrity Impact -         None
    Availability Impact -      Complete

CVSS Temporal Score - 6.4
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


Impact
======

Successful exploitation of these vulnerabilities can cause the device
to reload or become unresponsive. For the NAT of UDP over SIP
vulnerability that corresponds to Cisco bug CSCtj04672, it is also
possible that exploitation can cause a memory leak. Repeated
exploitation of the memory leak vulnerability can lead to a DoS
condition in which the device reloads or becomes unresponsive.
Reloading may occur automatically, or the device may require manual
intervention to reload.

Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to determine
exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Additionally, the Cisco IOS Software Checker is available on
the Cisco Security Intelligence Operations (SIO) portal at
http://tools.cisco.com/security/center/selectIOSVersion.x. It provides
several features for checking which Security Advisories affect specified
versions of Cisco IOS Software.

Cisco IOS Software
+-----------------

Each row of the following Cisco IOS Software table corresponds to a
Cisco IOS Software train. If a particular train is vulnerable, the
earliest releases that contain the fix are listed in the First Fixed
Release For This Advisory column. The First Fixed Release for All
Advisories in the September 2011 Bundled Publication column lists the
earliest possible releases that correct all the published
vulnerabilities in the Cisco IOS Software Security Advisory bundled
publication. Cisco recommends upgrading to the latest available
release, where possible.

+------------------------------------------------------------+
|   Major    |         Availability of Repaired Releases     |
|  Release   |                                               |
|------------+-----------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.0-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 12.0-based releases                  |
|------------------------------------------------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.1-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.1E      | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.2-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 12.2       | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2B      | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2BC     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2BW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2BX     | fixed in Release      | fixed in Release      |
|            | 12.2SB                | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2BY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2BZ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2CX     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2CY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2CZ     | fixed in Release      | fixed in Release      |
|            | 12.2SB                | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2DA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2DD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2DX     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2EU     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     |                       |
|            | fixed in Release      |                       |
|            | 12.2SG                | Releases up to and    |
| 12.2EW     |                       | including 12.2(20)EW4 |
|            | Releases up to and    | are not vulnerable.   |
|            | including 12.2(20)EW4 |                       |
|            | are not vulnerable.   |                       |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            | Vulnerable; first     | organization per the  |
| 12.2EWA    | fixed in Release      | instructions in the   |
|            | 12.2SG                | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2EX     | 12.2(55)EX            | 12.2(55)EX3           |
|------------+-----------------------+-----------------------|
|            | 12.2(52)EY            |                       |
| 12.2EY     |                       | 12.2(58)EY            |
|            | 12.2(52)EY1b          |                       |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; migrate   |
| 12.2EZ     | to any release in     | to any release in     |
|            | 15.0SE                | 15.0SE                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2FX     | fixed in Release      | fixed in Release      |
|            | 12.2SE                | 12.2SE                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2FY     | fixed in Release      | fixed in Release      |
|            | 12.2EX                | 12.2EX                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2FZ     | fixed in Release      | fixed in Release      |
|            | 12.2SE                | 12.2SE                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; migrate   |
| 12.2IRA    | to any release in     | to any release in     |
|            | 12.2IRG               | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; migrate   |
| 12.2IRB    | to any release in     | to any release in     |
|            | 12.2IRG               | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; migrate   |
| 12.2IRC    | to any release in     | to any release in     |
|            | 12.2IRG               | 12.2IRG               |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IRD    | 12.2(33)IRD1          | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 12.2IRE    | 12.2(33)IRE3          | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; migrate   |
| 12.2IRF    | to any release in     | to any release in     |
|            | 12.2IRG               | 12.2IRG               |
|------------+-----------------------+-----------------------|
| 12.2IRG    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXA    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXB    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXC    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXD    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXE    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXF    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXG    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2IXH    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2JA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2JK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2MB     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2MC     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2MRA    | fixed in Release      | fixed in Release      |
|            | 12.2SRD               | 12.2SRD               |
|------------+-----------------------+-----------------------|
| 12.2MRB    | 12.2(33)MRB5          | 12.2(33)MRB5          |
|------------+-----------------------+-----------------------|
|            | Releases prior to     | Releases prior to     |
|            | 12.2(30)S are         | 12.2(30)S are         |
|            | vulnerable; Releases  | vulnerable; Releases  |
| 12.2S      | 12.2(30)S and later   | 12.2(30)S and later   |
|            | are not vulnerable.   | are not vulnerable.   |
|            | First fixed in        | First fixed in        |
|            | Release 12.2SB        | Release 12.2SB        |
|------------+-----------------------+-----------------------|
|            | 12.2(31)SB20          | 12.2(31)SB2012.2(33)  |
| 12.2SB     |                       | SB10                  |
|            | 12.2(33)SB10          |                       |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SBC    | fixed in Release      | fixed in Release      |
|            | 12.2SB                | 12.2SB                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SCA    | fixed in Release      | fixed in Release      |
|            | 12.2SCC               | 12.2SCC               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SCB    | fixed in Release      | fixed in Release      |
|            | 12.2SCC               | 12.2SCC               |
|------------+-----------------------+-----------------------|
| 12.2SCC    | 12.2(33)SCC7          | 12.2(33)SCC7          |
|------------+-----------------------+-----------------------|
|            | 12.2(33)SCD6          |                       |
| 12.2SCD    |                       | 12.2(33)SCD6          |
|            | 12.2(33)SCD7          |                       |
|------------+-----------------------+-----------------------|
| 12.2SCE    | 12.2(33)SCE1          | 12.2(33)SCE1          |
|------------+-----------------------+-----------------------|
| 12.2SCF    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | 12.2(55)SE2           | 12.2(55)SE3           |
| 12.2SE     |                       |                       |
|            | 12.2(58)SE            | 12.2(58)SE            |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SEA    | fixed in Release      | fixed in Release      |
|            | 12.2SE                | 12.2SE                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SEB    | fixed in Release      | fixed in Release      |
|            | 12.2SE                | 12.2SE                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SEC    | fixed in Release      | fixed in Release      |
|            | 12.2SE                | 12.2SE                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SED    | fixed in Release      | fixed in Release      |
|            | 12.2SE                | 12.2SE                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SEE    | fixed in Release      | fixed in Release      |
|            | 12.2SE                | 12.2SE                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SEF    | fixed in Release      | fixed in Release      |
|            | 12.2SE                | 12.2SE                |
|------------+-----------------------+-----------------------|
|            | Releases prior to     | Releases prior to     |
|            | 12.2(25)SEG4 are      | 12.2(25)SEG4 are      |
|            | vulnerable; Releases  | vulnerable; Releases  |
| 12.2SEG    | 12.2(25)SEG4 and      | 12.2(25)SEG4 and      |
|            | later are not         | later are not         |
|            | vulnerable. First     | vulnerable. First     |
|            | fixed in Release      | fixed in Release      |
|            | 12.2EX                | 12.2EX                |
|------------+-----------------------+-----------------------|
|            |                       | Releases prior to     |
|            |                       | 12.2(53)SG4 are       |
| 12.2SG     | 12.2(53)SG4           | vulnerable; Releases  |
|            |                       | 12.2(53)SG4 and later |
|            |                       | are not vulnerable.   |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            | Vulnerable; first     | organization per the  |
| 12.2SGA    | fixed in Release      | instructions in the   |
|            | 12.2SG                | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2SL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2SM     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2SO     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SQ     | 12.2(50)SQ3           | 12.2(50)SQ3           |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SRA    | fixed in Release      | fixed in Release      |
|            | 12.2SRD               | 12.2SRD               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SRB    | fixed in Release      | fixed in Release      |
|            | 12.2SRD               | 12.2SRD               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SRC    | fixed in Release      | fixed in Release      |
|            | 12.2SRD               | 12.2SRD               |
|------------+-----------------------+-----------------------|
| 12.2SRD    | 12.2(33)SRD6          | 12.2(33)SRD6          |
|------------+-----------------------+-----------------------|
| 12.2SRE    | 12.2(33)SRE3          | 12.2(33)SRE4          |
|------------+-----------------------+-----------------------|
| 12.2STE    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SU     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Releases prior to     | Releases prior to     |
|            | 12.2(29b)SV1 are      | 12.2(29a)SV are       |
|            | vulnerable; Releases  | vulnerable; Releases  |
| 12.2SV     | 12.2(29b)SV1 and      | 12.2(29a)SV and later |
|            | later are not         | are not vulnerable.   |
|            | vulnerable. Migrate   | Migrate to any        |
|            | to any release in     | release in 12.2SVD    |
|            | 12.2SVD               |                       |
|------------+-----------------------+-----------------------|
| 12.2SVA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVD    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SVE    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2SW     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SX     | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SXA    | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SXB    | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SXD    | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SXE    | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
| 12.2SXF    | 12.2(18)SXF17b        | 12.2(18)SXF17b        |
|------------+-----------------------+-----------------------|
|            | 12.2(33)SXH6          |                       |
| 12.2SXH    |                       | 12.2(33)SXH8a         |
|            | 12.2(33)SXH8a         |                       |
|------------+-----------------------+-----------------------|
|            | 12.2(33)SXI2          |                       |
|            |                       |                       |
| 12.2SXI    | 12.2(33)SXI2a         | 12.2(33)SXI6          |
|            |                       |                       |
|            | 12.2(33)SXI4a         |                       |
|------------+-----------------------+-----------------------|
| 12.2SXJ    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2SY     | 12.2(50)SY            | 12.2(50)SY            |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2SZ     | fixed in Release      | fixed in Release      |
|            | 12.2SB                | 12.2SB                |
|------------+-----------------------+-----------------------|
| 12.2T      | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2TPC    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2XA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XB     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2XC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XF     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XG     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XH     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XI     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XJ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XM     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XN     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XNA    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XNB    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XNC    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XND    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XNE    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Please see Cisco      | Please see Cisco      |
| 12.2XNF    | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Releases prior to     |                       |
|            | 12.2(54)XO are        | Releases prior to     |
|            | vulnerable; Releases  | 12.2(54)XO are        |
| 12.2XO     | 12.2(54)XO and later  | vulnerable; Releases  |
|            | are not vulnerable.   | 12.2(54)XO and later  |
|            | First fixed in        | are not vulnerable.   |
|            | Release 12.2SG        |                       |
|------------+-----------------------+-----------------------|
| 12.2XQ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XR     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XS     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XT     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XU     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XV     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2XW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YA     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2YB     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YF     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YG     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YH     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YJ     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YL     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YM     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YN     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2YO     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2YP     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YQ     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YR     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YS     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YT     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YU     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YV     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YW     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YX     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YY     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2YZ     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2ZA     | fixed in Release      | fixed in Release      |
|            | 12.2SXF               | 12.2SXF               |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2ZB     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2ZC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZE     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZF     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZG     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.2ZH     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.2ZJ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2ZL     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.2ZP     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.2ZU     | fixed in Release      | fixed in Release      |
|            | 12.2SXH               | 12.2SXH               |
|------------+-----------------------+-----------------------|
| 12.2ZX     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2ZY     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.2ZYA    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.3-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 12.3       | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3B      | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3BC     | fixed in Release      | fixed in Release      |
|            | 12.2SCC               | 12.2SCC               |
|------------+-----------------------+-----------------------|
| 12.3BW     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3JA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3JEA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3JEB    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3JEC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3JED    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Releases up to and    | Releases up to and    |
|            | including 12.3(2)JK3  | including 12.3(2)JK3  |
|            | are not vulnerable.   | are not vulnerable.   |
| 12.3JK     |                       | Releases 12.3(8)JK1   |
|            | Releases 12.3(8)JK1   | and later are not     |
|            | and later are not     | vulnerable. First     |
|            | vulnerable. First     | fixed in Release 12.4 |
|            | fixed in Release 12.4 |                       |
|------------+-----------------------+-----------------------|
| 12.3JL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3JX     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3T      | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3TPC    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.3VA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3XA     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3XB     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.3XC     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3XD     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3XE     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3XF     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.3XG     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3XI     | fixed in Release      | fixed in Release      |
|            | 12.2SB                | 12.2SB                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3XJ     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.3XK     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3XL     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.3XQ     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3XR     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3XS     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3XU     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3XW     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 12.3XX     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3XY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3XZ     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3YA     | Vulnerable; first     | Vulnerable; first     |
|            | fixed in Release 12.4 | fixed in Release 12.4 |
|------------+-----------------------+-----------------------|
| 12.3YD     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3YF     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3YG     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3YH     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3YI     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3YJ     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.3YK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.3YM     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3YQ     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3YS     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3YT     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3YU     | fixed in Release      | fixed in Release      |
|            | 12.4XB                | 12.4XB                |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3YX     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.3YZ     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.3ZA     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 12.4-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 12.4       | 12.4(25f)             | 12.4(25f)             |
|------------+-----------------------+-----------------------|
| 12.4GC     | 12.4(24)GC4           | 12.4(24)GC4           |
|------------+-----------------------+-----------------------|
| 12.4JA     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JAX    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JDA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JDC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JHA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JHB    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JHC    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JL     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JMA    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4JMB    | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; migrate   | Vulnerable; migrate   |
|            | to any release in     | to any release in     |
|            | 12.4JA                | 12.4JA                |
| 12.4JX     |                       |                       |
|            | Releases up to and    | Releases up to and    |
|            | including 12.4(21a)JX | including 12.4(21a)JX |
|            | are not vulnerable.   | are not vulnerable.   |
|------------+-----------------------+-----------------------|
| 12.4JY     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4MD     | 12.4(24)MD6 on        | 12.4(24)MD6 on        |
|            | 28-Oct-11             | 28-Oct-11             |
|------------+-----------------------+-----------------------|
| 12.4MDA    | 12.4(24)MDA7          | 12.4(24)MDA7          |
|------------+-----------------------+-----------------------|
| 12.4MDB    | 12.4(24)MDB3          | 12.4(24)MDB3          |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4MR     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4MRA    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4MRB    | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4SW     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | 12.4(15)T16           | 12.4(15)T16           |
| 12.4T      |                       |                       |
|            | 12.4(24)T6            | 12.4(24)T6            |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XA     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4XB     | 12.4(2)XB12           | 12.4(2)XB12           |
|------------+-----------------------+-----------------------|
| 12.4XC     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XD     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4XE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XF     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XG     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4XJ     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
| 12.4XK     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4XL     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XM     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4XN     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4XP     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XQ     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XR     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XT     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
| 12.4XV     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XW     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XY     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4XZ     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 12.4YA     | fixed in Release      | fixed in Release      |
|            | 12.4T                 | 12.4T                 |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4YB     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4YD     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | 12.4(22)YE6;          | 12.4(22)YE6;          |
|            | Available on          | Available on          |
|            | 30-SEP-11             | 30-SEP-11             |
| 12.4YE     |                       |                       |
|            | 12.4(24)YE7;          | 12.4(24)YE7;          |
|            | Available on          | Available on          |
|            | 17-OCT-11             | 17-OCT-11             |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 12.4YG     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.0-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
| 15.0M      | 15.0(1)M7             | 15.0(1)M7             |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 15.0MR     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 15.0MRA    | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
|            | 15.0(1)S4             | 15.0(1)S4             |
|            |                       |                       |
| 15.0S      | Cisco IOS XE devices: | Cisco IOS XE devices: |
|            | Please see Cisco      | Please see Cisco      |
|            | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Vulnerable; contact   | Vulnerable; contact   |
|            | your support          | your support          |
|            | organization per the  | organization per the  |
| 15.0SA     | instructions in the   | instructions in the   |
|            | Obtaining Fixed       | Obtaining Fixed       |
|            | Software section of   | Software section of   |
|            | this advisory.        | this advisory.        |
|------------+-----------------------+-----------------------|
| 15.0SE     | Not vulnerable        | Not vulnerable        |
|------------+-----------------------+-----------------------|
|            | Cisco IOS XE devices: | Cisco IOS XE devices: |
| 15.0SG     | Please see Cisco      | Please see Cisco      |
|            | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 15.0XA     | fixed in Release      | fixed in Release      |
|            | 15.1T                 | 15.1T                 |
|------------+-----------------------+-----------------------|
|            | Cisco IOS XE devices: | Cisco IOS XE devices: |
| 15.0XO     | Please see Cisco      | Please see Cisco      |
|            | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.1-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.1EY     | 15.1(2)EY             | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 15.1GC     | fixed in Release      | fixed in Release      |
|            | 15.1T                 | 15.1T                 |
|------------+-----------------------+-----------------------|
| 15.1M      | 15.1(4)M2; Available  | 15.1(4)M2; Available  |
|            | on 30-SEP-11          | on 30-SEP-11          |
|------------+-----------------------+-----------------------|
|            |                       | Vulnerable; contact   |
|            |                       | your support          |
|            |                       | organization per the  |
| 15.1MR     | Not vulnerable        | instructions in the   |
|            |                       | Obtaining Fixed       |
|            |                       | Software section of   |
|            |                       | this advisory.        |
|------------+-----------------------+-----------------------|
|            | 15.1(2)S2             | 15.1(2)S2             |
|            |                       |                       |
|            | 15.1(3)S              | 15.1(3)S              |
| 15.1S      |                       |                       |
|            | Cisco IOS XE devices: | Cisco IOS XE devices: |
|            | Please see Cisco      | Please see Cisco      |
|            | IOS-XE Software       | IOS-XE Software       |
|            | Availability          | Availability          |
|------------+-----------------------+-----------------------|
|            | 15.1(1)T4; Available  | 15.1(1)T4; Available  |
|            | on 09-DEC-11          | on 09-DEC-11          |
| 15.1T      |                       |                       |
|            | 15.1(2)T4             | 15.1(2)T4             |
|            |                       |                       |
|            | 15.1(3)T2             | 15.1(3)T2             |
|------------+-----------------------+-----------------------|
|            | Vulnerable; first     | Vulnerable; first     |
| 15.1XB     | fixed in Release      | fixed in Release      |
|            | 15.1T                 | 15.1T                 |
|------------+-----------------------+-----------------------|
|  Affected  |                       |  First Fixed Release  |
| 15.2-Based |  First Fixed Release  | for All Advisories in |
|  Releases  |                       |  the September 2011   |
|            |                       |  Bundled Publication  |
|------------------------------------------------------------|
| There are no affected 15.2-based releases                  |
+------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

+------------------------------------------------------------+
|  Cisco  |   First Fixed   |  First Fixed Release for All   |
| IOS XE  |     Release     |  Advisories in the September   |
| Release |                 |    2011 Bundled Publication    |
|---------+-----------------+--------------------------------|
| 2.1.x   | Not vulnerable  | Vulnerable; migrate to 3.3.2S  |
|         |                 | or later                       |
|---------+-----------------+--------------------------------|
| 2.2.x   | Not vulnerable  | Vulnerable; migrate to 3.3.2S  |
|         |                 | or later                       |
|---------+-----------------+--------------------------------|
| 2.3.x   | Not vulnerable  | Vulnerable; migrate to 3.3.2S  |
|         |                 | or later                       |
|---------+-----------------+--------------------------------|
| 2.4.x   | Not vulnerable  | Vulnerable; migrate to 3.3.2S  |
|         |                 | or later                       |
|---------+-----------------+--------------------------------|
| 2.5.x   | Not vulnerable  | Vulnerable; migrate to 3.3.2S  |
|         |                 | or later                       |
|---------+-----------------+--------------------------------|
| 2.6.x   | Not vulnerable  | Vulnerable; migrate to 3.3.2S  |
|         |                 | or later                       |
|---------+-----------------+--------------------------------|
| 3.1.xS  | Not vulnerable  | Vulnerable; migrate to 3.3.2S  |
|         |                 | or later                       |
|---------+-----------------+--------------------------------|
|         | Vulnerable;     |                                |
| 3.1.xSG | migrate to      | Vulnerable; migrate to 3.2.0SG |
|         | 3.2.0SG or      | or later                       |
|         | later           |                                |
|---------+-----------------+--------------------------------|
| 3.2.xS  | Not vulnerable  | Vulnerable; migrate to 3.3.2S  |
|         |                 | or later                       |
|---------+-----------------+--------------------------------|
| 3.2.xSG | Not vulnerable  | Not vulnerable                 |
|---------+-----------------+--------------------------------|
| 3.3.xS  | Not vulnerable  | 3.3.2S                         |
|---------+-----------------+--------------------------------|
| 3.4.xS  | Not vulnerable  | Not vulnerable                 |
+------------------------------------------------------------+

For mapping of Cisco IOS XE to Cisco IOS releases, please refer to
the Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and
Cisco IOS XE 3SG Release Notes.

Cisco IOS XR Software
+--------------------

Cisco IOS XR Software is not affected by any of the vulnerabilities
in the September 2011 bundled publication.

Workarounds
===========

It is possible to mitigate the vulnerabilities in this advisory by
disabling the translation of embedded IP addresses in the payload of
IP packets. Disabling NAT for the different protocols requires
different configurations. For some protocols, a single command can be
used. Other protocols require individual NAT translation rules be
added to the configuration.

NAT LDAP Vulnerability Mitigation
+---------------------------------

To disable NAT of LDAP, port-based address translation needs to be
configured to disable LDAP inspection using the no-payload keyword.
This will still allow the NAT of LDAP packets at Layer 3 (non-port
specific). Translation of other non-LDAP protocols translation will
not be affected. Applications that use embedded IP addresses in LDAP,
such as NetMeeting Directory, will be negatively impacted if the
embedded IP addresses need to be translated.

The following is an example configuration that includes the
mitigation for two NAT rules.


    !-- NAT rule for port TCP/389 to disable IP NAT for LDAP translation
    !-- Takes precedence over the non-port translation rule.

    ip nat outside source static tcp 192.168.0.1 389 192.168.1.1 389 no-payload
    ip nat outside source static tcp 192.168.0.3 389 192.168.1.3 389 no-payload

    !-- Translation rule for all other protocols

    ip nat outside source static 192.168.0.1 192.168.1.1
    ip nat outside source static 192.168.0.3 192.168.1.3

    interface GigabitEthernet0/0
      ip nat inside

    interface GigabitEthernet0/1
      ip nat outside

Each NAT translation rule in the configuration will need to be
updated to include a per-port rule that disables translation of TCP
packets on port 389.

NAT for SIP over TCP DoS Vulnerability Mitigation
+------------------------------------------------

Mitigation for this vulnerability consists of disabling NAT for SIP
over the TCP transport by using the "no ip nat service sip tcp port
5060" global configuration command.

NAT of Crafted SIP over UDP Packets DoS Vulnerability Mitigation
+---------------------------------------------------------------

Mitigation of these vulnerabilities consists of disabling NAT for SIP
over the UDP transport by using the "no ip nat service sip udp port
5060" global configuration command.

NAT for Crafted H.323 Packets DoS Vulnerability Mitigation
+---------------------------------------------------------

Mitigation for this vulnerability consists of disabling NAT for H.323
and H.225.0 using the "no ip nat service h225" global configuration
command.

Obtaining Fixed Software
========================

Cisco has released free software updates that address this
vulnerability. Prior to deploying software, customers should consult
their maintenance provider or check the software for feature set
compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature
sets they have purchased. By installing, downloading, accessing
or otherwise using such software upgrades, customers agree to be
bound by the terms of Cisco's software license terms found at
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerabilities described in this advisory.

The NAT LDAP vulnerability and the NAT of crafted SIP packets
vulnerabilities were found during internal Cisco testing. The NAT
SIP/TCP vulnerability, provider edge MPLS NAT of SIP over UDP packets
vulnerability, and NAT of H.323 packets DoS vulnerabilities were found
during troubleshooting of TAC service requests.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20110928-nat.shtml
In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+------------------------------------------------------------+
| Revision 1.0   | 2011-Sep-28   | Initial public release    |
+------------------------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities
in Cisco products, obtaining assistance with security
incidents, and registering to receive security information
from Cisco, is available on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
This includes instructions for press inquiries regarding
Cisco security notices. All Cisco security advisories are available at
http://www.cisco.com/ go/psirt.

+--------------------------------------------------------------------
Copyright 2010-2011 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAk6Cp2YACgkQQXnnBKKRMNAOugD/Qr4CA7ZO3CeTOcQnwg+oMx+c
NjHD7/tFD6PNnBBJF1IA/jMWm3G+EDQeuwMQ0ijB1QvXEApsX4ZJFNJyMgiFtL5x
=B/LS
-----END PGP SIGNATURE-----


From millnert at gmail.com  Wed Sep 28 14:26:34 2011
From: millnert at gmail.com (Martin Millnert)
Date: Wed, 28 Sep 2011 21:26:34 +0200
Subject: Nxdomain redirect revenue
In-Reply-To: <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
Message-ID: <CAHyNd168+32WYd6QhM937+az8kxO8L_oe2eNGE9rdJON=DHM0Q@mail.gmail.com>

Jimmy,

On Tue, Sep 27, 2011 at 1:50 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> The name for an ISP intercepting traffic from its own users is ?not
> "interference" ?or ?"DoS",
> because they're breaking the operation of (er) only their own network.

This statement somehow assumes that users of said network were only
intending to communicate within that same network. I think this
applies to so few networks it can be ignored in the discussion.

If I have a partner/customer/supplier/$foo in [common carrier/public
carrier] network X, and there is no D/DoS or other form of abuse
ongoing, and the operator of X willfully denies our communication, the
operator of X should have pretty darn good reasons for doing so (on
the order of having been ordered by the proper judicial system (which
should be well-functional, but that's a bit out of scope for the
discussion I guess)).

Operators should take great care to not break communication, including
tampering with internet architectures such as DNS, and it must be
possible to hold those who do responsible for their actions.

Regards,
Martin


From bill at herrin.us  Wed Sep 28 15:08:21 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 28 Sep 2011 16:08:21 -0400
Subject: Seeking clueful TWTelecom engineer
Message-ID: <CAP-guGVehBKqDZQLOmJ2HB5kk-f2w_BE3MP8HtsnUcEH_bhy5g@mail.gmail.com>

There's a packet filtering problem on your peering link with Godaddy
in Phoenix. Ongoing for about 7 or 8 hours now. Details in your ticket
#CI000596124.

Front line techs insist that, "This is godaddy's problem. We're
sending them packets." Apparently you're not in contact with godaddy
to resolve the problem even though it seems to only affect twtelecom's
peering link with godaddy.

Requests using the same source and destination IP address pairs routed
via Qwest or Sprint succeed.

Thanks in advanced,
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 mysidia at gmail.com  Wed Sep 28 18:51:24 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 28 Sep 2011 18:51:24 -0500
Subject: Nxdomain redirect revenue
In-Reply-To: <CAHyNd168+32WYd6QhM937+az8kxO8L_oe2eNGE9rdJON=DHM0Q@mail.gmail.com>
References: <CAD6AjGQpqTMP9bKAMz4HmWcH_GOA7pWrFqntteqWj1YCBPZgUg@mail.gmail.com>
 <82sjnjg0zi.fsf@mid.bfk.de> <4E818FFE.70908@gmail.com>
 <CAAAwwbWYQfpoHEReiyamy8fO0g0Edh=1+1usKkMk22PWO+i=Pg@mail.gmail.com>
 <CAHyNd168+32WYd6QhM937+az8kxO8L_oe2eNGE9rdJON=DHM0Q@mail.gmail.com>
Message-ID: <CAAAwwbV-qU=TzhknoGf1yM=UvjuRL_acrFybZ8zv__d2bjHQzQ@mail.gmail.com>

On Wed, Sep 28, 2011 at 2:26 PM, Martin Millnert <millnert at gmail.com> wrote:
Hi,
I think you're echoing a common misconception here:
> If I have a partner/customer/supplier/$foo in [common carrier/public
> carrier] network X, and there is no D/DoS or other form of abuse

ISPs are not like traditional telephone carriers.  ISPs are not common carriers.
They are not common carriers legally, and they are not _like_ common
carriers operationally.

They are empowered to provide whatever types of service and service
levels to their subscriber that their properly agreed upon terms of
service provides for....


Most end users of an ISP don't even get a SLA,  let alone a promise
that any IP address
will be reachable.    Also, thanks to peering spats and other various phenomena,
it's actually an  impossible promise for an ISP to make.

Due to the nature of the internet  ISPs  _often_  make decisions that
result in discrimination
of traffic based on its type, its source, destination,  payload contents, etc.

Blackholing spammer IP addresses is a common example; and ISPs could not do that
if they were common carriers.

> ongoing, and the operator of X willfully denies our communication, the
> operator of X should have pretty darn good reasons for doing so (on

In your opinion the operator should have a "pretty darn good reason"
for doing so.
But in reality,  the  internet service subscriber's  subscription
agreement will state
what's a "pretty darn good reason";  generally, the agreement states
that any reason
at all, or no reason,  solely at the operator's discretion,  is good enough.

> Operators should take great care to not break communication, including
> tampering with internet architectures such as DNS, and it must be
> possible to hold those who do responsible for their actions.

It occurs that an ISP deploying a custom DNS service that implements
their own policies
of munging redirects or producing "false" answers  is not "tampering"
with anyone else's server.


--
-JH


From glen.kent at gmail.com  Thu Sep 29 08:13:49 2011
From: glen.kent at gmail.com (Glen Kent)
Date: Thu, 29 Sep 2011 18:43:49 +0530
Subject: facebook spying on us?
Message-ID: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>

Hi,

I see that i have multiple TCP sessions established with facebook.
They come up even after i reboot my laptop and dont login to facebook!

D:\Documents and Settings\gkent>netstat -a | more

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    gkent:3974    www-10-02-snc5.facebook.com:http  ESTABLISHED
  TCP    gkent:3977    www-11-05-prn1.facebook.com:http  ESTABLISHED
  TCP    gkent:3665
a184-84-111-139.deploy.akamaitechnologies.com:http  ESTABLISHED

[clipped]

Any idea why these connections are established (with facebook and
akamaitechnologies) and how i can kill them? Since my laptop has
several connections open with facebook, what kind of information is
flowing there?

I also wonder about the kind of servers facebook must be having to be
able to manage millions of TCP connections that must be terminating
there.

Glen


From w3yni1 at gmail.com  Thu Sep 29 08:16:36 2011
From: w3yni1 at gmail.com (Charles Mills)
Date: Thu, 29 Sep 2011 09:16:36 -0400
Subject: facebook spying on us?
In-Reply-To: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
Message-ID: <CAOF0KO_xR3HY-tXYGqpaUvXFYUgM4TTMEQV-=f_bKYAL-eXL=Q@mail.gmail.com>

Could be something related to the earlier cookie controversy that was
discussed.

I did dig too deeply into exactly what they were doing however.

Chuck

On Thu, Sep 29, 2011 at 9:13 AM, Glen Kent <glen.kent at gmail.com> wrote:

> Hi,
>
> I see that i have multiple TCP sessions established with facebook.
> They come up even after i reboot my laptop and dont login to facebook!
>
> D:\Documents and Settings\gkent>netstat -a | more
>
> Active Connections
>
>  Proto  Local Address          Foreign Address        State
>  TCP    gkent:3974    www-10-02-snc5.facebook.com:http  ESTABLISHED
>  TCP    gkent:3977    www-11-05-prn1.facebook.com:http  ESTABLISHED
>  TCP    gkent:3665
> a184-84-111-139.deploy.akamaitechnologies.com:http  ESTABLISHED
>
> [clipped]
>
> Any idea why these connections are established (with facebook and
> akamaitechnologies) and how i can kill them? Since my laptop has
> several connections open with facebook, what kind of information is
> flowing there?
>
> I also wonder about the kind of servers facebook must be having to be
> able to manage millions of TCP connections that must be terminating
> there.
>
> Glen
>
>

From cabenth at gmail.com  Thu Sep 29 08:19:27 2011
From: cabenth at gmail.com (Eric Clark)
Date: Thu, 29 Sep 2011 06:19:27 -0700
Subject: facebook spying on us?
In-Reply-To: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
Message-ID: <B7BD8540-1F6D-4754-8D78-51ADD4A9FDB0@gmail.com>

did you start your browser before looking at your connection list?

However, you're on a window's box, so it wouldn't surprise me if they helpfully started ie for you....

If you didn't start the browser you use to go to facebook (and its not ie), its fairly interesting.



On Sep 29, 2011, at 6:13 AM, Glen Kent wrote:

> Hi,
> 
> I see that i have multiple TCP sessions established with facebook.
> They come up even after i reboot my laptop and dont login to facebook!
> 
> D:\Documents and Settings\gkent>netstat -a | more
> 
> Active Connections
> 
>  Proto  Local Address          Foreign Address        State
>  TCP    gkent:3974    www-10-02-snc5.facebook.com:http  ESTABLISHED
>  TCP    gkent:3977    www-11-05-prn1.facebook.com:http  ESTABLISHED
>  TCP    gkent:3665
> a184-84-111-139.deploy.akamaitechnologies.com:http  ESTABLISHED
> 
> [clipped]
> 
> Any idea why these connections are established (with facebook and
> akamaitechnologies) and how i can kill them? Since my laptop has
> several connections open with facebook, what kind of information is
> flowing there?
> 
> I also wonder about the kind of servers facebook must be having to be
> able to manage millions of TCP connections that must be terminating
> there.
> 
> Glen
> 



From jason.duerstock at gallaudet.edu  Thu Sep 29 08:20:16 2011
From: jason.duerstock at gallaudet.edu (Jason Duerstock)
Date: Thu, 29 Sep 2011 09:20:16 -0400
Subject: facebook spying on us?
In-Reply-To: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
Message-ID: <CAJNn=DM6MQa+HsafD1iEaUwOrkNUPeH00tn25TrM-gDVBY=r4g@mail.gmail.com>

Use 'netstat -ao' to see which process(es) they are associated with.
Then use a sniffer to see what actual traffic they carry.

Jason

On Thu, Sep 29, 2011 at 9:13 AM, Glen Kent <glen.kent at gmail.com> wrote:
> Hi,
>
> I see that i have multiple TCP sessions established with facebook.
> They come up even after i reboot my laptop and dont login to facebook!
>
> D:\Documents and Settings\gkent>netstat -a | more
>
> Active Connections
>
> ?Proto ?Local Address ? ? ? ? ?Foreign Address ? ? ? ?State
> ?TCP ? ?gkent:3974 ? ?www-10-02-snc5.facebook.com:http ?ESTABLISHED
> ?TCP ? ?gkent:3977 ? ?www-11-05-prn1.facebook.com:http ?ESTABLISHED
> ?TCP ? ?gkent:3665
> a184-84-111-139.deploy.akamaitechnologies.com:http ?ESTABLISHED
>
> [clipped]
>
> Any idea why these connections are established (with facebook and
> akamaitechnologies) and how i can kill them? Since my laptop has
> several connections open with facebook, what kind of information is
> flowing there?
>
> I also wonder about the kind of servers facebook must be having to be
> able to manage millions of TCP connections that must be terminating
> there.
>
> Glen
>
>


From ahebert at pubnix.net  Thu Sep 29 08:23:42 2011
From: ahebert at pubnix.net (Alain Hebert)
Date: Thu, 29 Sep 2011 09:23:42 -0400
Subject: facebook spying on us?
In-Reply-To: <B7BD8540-1F6D-4754-8D78-51ADD4A9FDB0@gmail.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <B7BD8540-1F6D-4754-8D78-51ADD4A9FDB0@gmail.com>
Message-ID: <4E84715E.7000509@pubnix.net>

  ( Being this is a Windows box)

     Want to scare yourself silly?

     . Power off the PC;
     . Plug it a switch;
     . Mirror the PC port into a Unix box running Wireshark;
     . Boot the PC

     Enjoy all the info leakages from all the apps you installed over 
the years.

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


On 09/29/11 09:19, Eric Clark wrote:
> did you start your browser before looking at your connection list?
>
> However, you're on a window's box, so it wouldn't surprise me if they helpfully started ie for you....
>
> If you didn't start the browser you use to go to facebook (and its not ie), its fairly interesting.
>
>
>
> On Sep 29, 2011, at 6:13 AM, Glen Kent wrote:
>
>> Hi,
>>
>> I see that i have multiple TCP sessions established with facebook.
>> They come up even after i reboot my laptop and dont login to facebook!
>>
>> D:\Documents and Settings\gkent>netstat -a | more
>>
>> Active Connections
>>
>>   Proto  Local Address          Foreign Address        State
>>   TCP    gkent:3974    www-10-02-snc5.facebook.com:http  ESTABLISHED
>>   TCP    gkent:3977    www-11-05-prn1.facebook.com:http  ESTABLISHED
>>   TCP    gkent:3665
>> a184-84-111-139.deploy.akamaitechnologies.com:http  ESTABLISHED
>>
>> [clipped]
>>
>> Any idea why these connections are established (with facebook and
>> akamaitechnologies) and how i can kill them? Since my laptop has
>> several connections open with facebook, what kind of information is
>> flowing there?
>>
>> I also wonder about the kind of servers facebook must be having to be
>> able to manage millions of TCP connections that must be terminating
>> there.
>>
>> Glen
>>
>
>


From doon.bulk at inoc.net  Thu Sep 29 08:25:16 2011
From: doon.bulk at inoc.net (Patrick Muldoon)
Date: Thu, 29 Sep 2011 09:25:16 -0400
Subject: facebook spying on us?
In-Reply-To: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
Message-ID: <00413157-C15A-4F5A-9079-8BE6098E3559@inoc.net>

On Sep 29, 2011, at 9:13 AM, Glen Kent wrote:

> Hi,
> 
> I see that i have multiple TCP sessions established with facebook.
> They come up even after i reboot my laptop and dont login to facebook!
> 
> D:\Documents and Settings\gkent>netstat -a | more
> 
> Active Connections
> 
>  Proto  Local Address          Foreign Address        State
>  TCP    gkent:3974    www-10-02-snc5.facebook.com:http  ESTABLISHED
>  TCP    gkent:3977    www-11-05-prn1.facebook.com:http  ESTABLISHED
>  TCP    gkent:3665
> a184-84-111-139.deploy.akamaitechnologies.com:http  ESTABLISHED
> 
> [clipped]
> 
> Any idea why these connections are established (with facebook and
> akamaitechnologies) and how i can kill them? Since my laptop has
> several connections open with facebook, what kind of information is
> flowing there?
> 

Use a sniffer like wireshark, and see what the traffic is? 

Are you using a chat program that supports facebook chat?  Or perhaps a game or an application  that uses facebook for something?  

Really it could be anything as there are lots of applications that have grown up around the Facebook Eco system.. 

Also are you browsing the web?  There are facebook like buttons and the such all over the web.  So you don't even need to be logged in or have visited yet after the reboot. 

> I also wonder about the kind of servers facebook must be having to be
> able to manage millions of TCP connections that must be terminating
> there.



Lots of them.  There is video of their new DC floating around that shows them.. 

http://www.datacenterknowledge.com/archives/2011/04/18/video-inside-facebooks-server-room/


-Patrick

--
Patrick Muldoon
Network/Software Engineer
INOC (http://www.inoc.net)
PGPKEY (http://www.inoc.net/~doon)
Key ID: 0x370D752C

Base 8 is just like base 10, if you are missing two fingers.  - Tom Lehrer



From Valdis.Kletnieks at vt.edu  Thu Sep 29 08:27:10 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 29 Sep 2011 09:27:10 -0400
Subject: facebook spying on us?
In-Reply-To: Your message of "Thu, 29 Sep 2011 18:43:49 +0530."
 <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
Message-ID: <62349.1317302830@turing-police.cc.vt.edu>

On Thu, 29 Sep 2011 18:43:49 +0530, Glen Kent said:
> Any idea why these connections are established (with facebook and
> akamaitechnologies) and how i can kill them? Since my laptop has
> several connections open with facebook, what kind of information is
> flowing there?

Probably you visited other pages that have links to Facebook on them.  Try
installing NoScript or similar in your browser and don't allow Facebook javascript,
and see if these connections evaporate.

Akamai is a content-caching service, just means somebody paid to have their
content be (hopefully) nearer to you network-wise.
 
> I also wonder about the kind of servers facebook must be having to be
> able to manage millions of TCP connections that must be terminating
> there.

Two words: Big Honkin' Load Balancers.  OK, maybe more than two words. ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110929/9f3f24db/attachment-0001.bin>

From erik.soosalu at calyxinc.com  Thu Sep 29 08:34:38 2011
From: erik.soosalu at calyxinc.com (Erik Soosalu)
Date: Thu, 29 Sep 2011 09:34:38 -0400
Subject: facebook spying on us?
In-Reply-To: <00413157-C15A-4F5A-9079-8BE6098E3559@inoc.net>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <00413157-C15A-4F5A-9079-8BE6098E3559@inoc.net>
Message-ID: <0B224A2FE01CC54C860290D42474BF600505A8D9@exchange.nff.local>

At least on a win 7 box, netstat -b gives the process that initiated the
connection.

Likely opened due to a link or something from some other web page.


-----Original Message-----
From: Patrick Muldoon [mailto:doon.bulk at inoc.net] 
Sent: Thursday, September 29, 2011 9:25 AM
To: Glen Kent
Cc: nanog at nanog.org
Subject: Re: facebook spying on us?

On Sep 29, 2011, at 9:13 AM, Glen Kent wrote:

> Hi,
> 
> I see that i have multiple TCP sessions established with facebook.
> They come up even after i reboot my laptop and dont login to facebook!
> 
> D:\Documents and Settings\gkent>netstat -a | more
> 
> Active Connections
> 
>  Proto  Local Address          Foreign Address        State
>  TCP    gkent:3974    www-10-02-snc5.facebook.com:http  ESTABLISHED
>  TCP    gkent:3977    www-11-05-prn1.facebook.com:http  ESTABLISHED
>  TCP    gkent:3665
> a184-84-111-139.deploy.akamaitechnologies.com:http  ESTABLISHED
> 
> [clipped]
> 
> Any idea why these connections are established (with facebook and
> akamaitechnologies) and how i can kill them? Since my laptop has
> several connections open with facebook, what kind of information is
> flowing there?
> 

Use a sniffer like wireshark, and see what the traffic is? 

Are you using a chat program that supports facebook chat?  Or perhaps a
game or an application  that uses facebook for something?  

Really it could be anything as there are lots of applications that have
grown up around the Facebook Eco system.. 

Also are you browsing the web?  There are facebook like buttons and the
such all over the web.  So you don't even need to be logged in or have
visited yet after the reboot. 

> I also wonder about the kind of servers facebook must be having to be
> able to manage millions of TCP connections that must be terminating
> there.



Lots of them.  There is video of their new DC floating around that shows
them.. 

http://www.datacenterknowledge.com/archives/2011/04/18/video-inside-face
books-server-room/


-Patrick

--
Patrick Muldoon
Network/Software Engineer
INOC (http://www.inoc.net)
PGPKEY (http://www.inoc.net/~doon)
Key ID: 0x370D752C

Base 8 is just like base 10, if you are missing two fingers.  - Tom
Lehrer





From os10rules at gmail.com  Thu Sep 29 08:36:49 2011
From: os10rules at gmail.com (Greg Ihnen)
Date: Thu, 29 Sep 2011 09:06:49 -0430
Subject: facebook spying on us?
In-Reply-To: <62349.1317302830@turing-police.cc.vt.edu>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <62349.1317302830@turing-police.cc.vt.edu>
Message-ID: <5899A994-B7D3-42F9-BDD6-E5DED5A2CDA9@gmail.com>

Install Ghostery on your browsers and you'll see even more connections pages want to make behind the scenes to tracking sites etc. It's not just javascript.

Greg
On Sep 29, 2011, at 8:57 AM, Valdis.Kletnieks at vt.edu wrote:

> On Thu, 29 Sep 2011 18:43:49 +0530, Glen Kent said:
>> Any idea why these connections are established (with facebook and
>> akamaitechnologies) and how i can kill them? Since my laptop has
>> several connections open with facebook, what kind of information is
>> flowing there?
> 
> Probably you visited other pages that have links to Facebook on them.  Try
> installing NoScript or similar in your browser and don't allow Facebook javascript,
> and see if these connections evaporate.
> 
> Akamai is a content-caching service, just means somebody paid to have their
> content be (hopefully) nearer to you network-wise.
> 
>> I also wonder about the kind of servers facebook must be having to be
>> able to manage millions of TCP connections that must be terminating
>> there.
> 
> Two words: Big Honkin' Load Balancers.  OK, maybe more than two words. ;)
> 



From dhill at mindcry.org  Thu Sep 29 09:20:10 2011
From: dhill at mindcry.org (David Hill)
Date: Thu, 29 Sep 2011 10:20:10 -0400
Subject: facebook spying on us?
In-Reply-To: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
Message-ID: <20110929142010.GB1915@olive.mindcry.lan>

On Thu, Sep 29, 2011 at 06:43:49PM +0530, Glen Kent wrote:
:Hi,
:
:I see that i have multiple TCP sessions established with facebook.
:They come up even after i reboot my laptop and dont login to facebook!
:
:D:\Documents and Settings\gkent>netstat -a | more
:
:Active Connections
:
:  Proto  Local Address          Foreign Address        State
:  TCP    gkent:3974    www-10-02-snc5.facebook.com:http  ESTABLISHED
:  TCP    gkent:3977    www-11-05-prn1.facebook.com:http  ESTABLISHED
:  TCP    gkent:3665
:a184-84-111-139.deploy.akamaitechnologies.com:http  ESTABLISHED
:
:[clipped]
:
:Any idea why these connections are established (with facebook and
:akamaitechnologies) and how i can kill them? Since my laptop has
:several connections open with facebook, what kind of information is
:flowing there?
:
:I also wonder about the kind of servers facebook must be having to be
:able to manage millions of TCP connections that must be terminating
:there.
:
:Glen
:

For the more paranoid open source users, I have found using the xxxterm
web browser to help quite a bit.   You can read about it at
http://www.xxxterm.org



From keegan.holley at sungard.com  Thu Sep 29 09:55:07 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 29 Sep 2011 10:55:07 -0400
Subject: facebook spying on us?
In-Reply-To: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
Message-ID: <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>

Well what's making the connection?  It looks like unencrypted http, if your
social security number and last known addresses are streaming by you should
be able to see them.  It's a bit of a jump to say that FB (not that I'm
particularly fond of them) is spying on you from a single netstat command.
You probably clicked login with facebook for some site and it's just
autologging you in or overzealous prefetching.  Either way, I think we can
all stop making tinfoil hats now...


2011/9/29 Glen Kent <glen.kent at gmail.com>

> Hi,
>
> I see that i have multiple TCP sessions established with facebook.
> They come up even after i reboot my laptop and dont login to facebook!
>
> D:\Documents and Settings\gkent>netstat -a | more
>
> Active Connections
>
>  Proto  Local Address          Foreign Address        State
>  TCP    gkent:3974    www-10-02-snc5.facebook.com:http  ESTABLISHED
>  TCP    gkent:3977    www-11-05-prn1.facebook.com:http  ESTABLISHED
>  TCP    gkent:3665
> a184-84-111-139.deploy.akamaitechnologies.com:http  ESTABLISHED
>
> [clipped]
>
> Any idea why these connections are established (with facebook and
> akamaitechnologies) and how i can kill them? Since my laptop has
> several connections open with facebook, what kind of information is
> flowing there?
>
> I also wonder about the kind of servers facebook must be having to be
> able to manage millions of TCP connections that must be terminating
> there.
>
> Glen
>
>
>

From rcarpen at network1.net  Thu Sep 29 12:33:48 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Thu, 29 Sep 2011 13:33:48 -0400 (EDT)
Subject: Cisco switch LACP + 802.1q
In-Reply-To: <5dd35f6d-d7e8-469e-9f4e-f8fdab191cc2@zimbra.network1.net>
Message-ID: <5b2d8ee6-5de0-4b06-9bba-e6abde5e667c@zimbra.network1.net>


I am tearing my hair out with an issue, and I hope someone can point something out to me that I am missing.

I am setting up 2-port LACP sets on a Cisco 2960G-24TS-L, which then need to be 802.1q trunk ports.

I have set it up as follows:

interface Port-channel1
  switchport mode trunk
!
interface Port-channel2
  switchport mode trunk
!
interface Port-channel3
  switchport mode trunk
!
interface Port-channel4
  switchport mode trunk
!
interface GigabitEthernet0/1
 channel-protocol lacp
 channel-group 1 mode active
!
interface GigabitEthernet0/2
 channel-protocol lacp
 channel-group 1 mode active
!
interface GigabitEthernet0/3
 channel-protocol lacp
 channel-group 2 mode active
!         
interface GigabitEthernet0/4
 channel-protocol lacp
 channel-group 2 mode active
!
interface GigabitEthernet0/5
 channel-protocol lacp
 channel-group 3 mode active
!
interface GigabitEthernet0/6
 channel-protocol lacp
 channel-group 3 mode active
!
interface GigabitEthernet0/7
 switchport mode trunk
 channel-protocol lacp
 channel-group 4 mode active
!
interface GigabitEthernet0/8
 switchport mode trunk
 channel-protocol lacp
 channel-group 4 mode active


The problem is that after some period of time (sometimes minutes, sometimes hours), port-channel1 loses the "switchport mode trunk"

It just disappears from the config.  If I try to put it back, it adds "switchport mode trunk" to the member ports (Gi0/1, Gi0/2) as well, which does not work. I have to tear it all out and start again. It will then work for a while again.

port-channel2 and port-channel3 are not in use yet, but port-channel4 is, and works just fine.

It is running IOS 15.0(1)SE. It was running 12.2 before, and it was doing the same thing, so I upgraded it to the latest available.

What could be the issue?

thanks,
-Randy


From chris.young at intermetro.net  Thu Sep 29 12:56:39 2011
From: chris.young at intermetro.net (Christopher Young)
Date: Thu, 29 Sep 2011 10:56:39 -0700
Subject: LACP between Riverstone RS8000 and Cisco ASX9000
Message-ID: <4E84B157.4030904@intermetro.net>

This is my first post to Nanog. I apologize if it is off-topic but I 
have been driving myself crazy trying to figure this out.

Is anyone familiar with configuring LACP between Riverstone RS8000 
(Running ROS 9.4.0.4) and a Cisco ASX9000.
I am attempting to bring in 2 Gigabit Fiber links from NTT  and bond 
them using LACP we will be using these links for a full BGP feed.

Any help would be appreciated, replies on or off list are alright with me.

-- 
Regards,
Christopher Young
Network Operations
InterMetro Communications, Inc.
805-433-8000 Main
805-433-0050 Direct
805-433-2589 Mobile
805-582-1006 Fax

*** Contact our NOC at 866-446-2662 or via email 'network.operations at intermetro.net'  ***

*** The information contained within this E-Mail and any attached document(s) is confidential and/or privileged. It is intended solely for the use of the addressee(s) named above. Unauthorized disclosure, photocopying, distribution or use of the information contained herein is prohibited. If you believe that you have received this E-Mail in error, please notify the sender by reply transmission or call 805-433-8000 and delete the message without reviewing, copying or disclosing the message, any attachments or any contents thereof.



  



From jason.duerstock at gallaudet.edu  Thu Sep 29 13:18:07 2011
From: jason.duerstock at gallaudet.edu (Jason Duerstock)
Date: Thu, 29 Sep 2011 14:18:07 -0400
Subject: Cisco switch LACP + 802.1q
In-Reply-To: <5b2d8ee6-5de0-4b06-9bba-e6abde5e667c@zimbra.network1.net>
References: <5dd35f6d-d7e8-469e-9f4e-f8fdab191cc2@zimbra.network1.net>
 <5b2d8ee6-5de0-4b06-9bba-e6abde5e667c@zimbra.network1.net>
Message-ID: <CAJNn=DOR4-ZvTsdfcMLgbeoOYPUHzjizE17z8D=htE+NNzP+2g@mail.gmail.com>

My limited understanding and experience with port-channels is that the
member port configurations need to match the port channel
configuration, at least with respect to 'switchport mode trunk',
'switchport trunk encapsulation' and 'switchport trunk allowed vlan'.
This is between a 6500 and a WLC4404, so your mileage will obviously
vary.  What does the configuration look on the device that is
connected to the 2960?

Jason

On Thu, Sep 29, 2011 at 1:33 PM, Randy Carpenter <rcarpen at network1.net> wrote:
>
> I am tearing my hair out with an issue, and I hope someone can point something out to me that I am missing.
>
> I am setting up 2-port LACP sets on a Cisco 2960G-24TS-L, which then need to be 802.1q trunk ports.
>
> I have set it up as follows:
>
> interface Port-channel1
> ?switchport mode trunk
> !
> interface Port-channel2
> ?switchport mode trunk
> !
> interface Port-channel3
> ?switchport mode trunk
> !
> interface Port-channel4
> ?switchport mode trunk
> !
> interface GigabitEthernet0/1
> ?channel-protocol lacp
> ?channel-group 1 mode active
> !
> interface GigabitEthernet0/2
> ?channel-protocol lacp
> ?channel-group 1 mode active
> !
> interface GigabitEthernet0/3
> ?channel-protocol lacp
> ?channel-group 2 mode active
> !
> interface GigabitEthernet0/4
> ?channel-protocol lacp
> ?channel-group 2 mode active
> !
> interface GigabitEthernet0/5
> ?channel-protocol lacp
> ?channel-group 3 mode active
> !
> interface GigabitEthernet0/6
> ?channel-protocol lacp
> ?channel-group 3 mode active
> !
> interface GigabitEthernet0/7
> ?switchport mode trunk
> ?channel-protocol lacp
> ?channel-group 4 mode active
> !
> interface GigabitEthernet0/8
> ?switchport mode trunk
> ?channel-protocol lacp
> ?channel-group 4 mode active
>
>
> The problem is that after some period of time (sometimes minutes, sometimes hours), port-channel1 loses the "switchport mode trunk"
>
> It just disappears from the config. ?If I try to put it back, it adds "switchport mode trunk" to the member ports (Gi0/1, Gi0/2) as well, which does not work. I have to tear it all out and start again. It will then work for a while again.
>
> port-channel2 and port-channel3 are not in use yet, but port-channel4 is, and works just fine.
>
> It is running IOS 15.0(1)SE. It was running 12.2 before, and it was doing the same thing, so I upgraded it to the latest available.
>
> What could be the issue?
>
> thanks,
> -Randy
>
>


From BEJones at semprautilities.com  Thu Sep 29 14:11:48 2011
From: BEJones at semprautilities.com (Jones, Barry)
Date: Thu, 29 Sep 2011 12:11:48 -0700
Subject: Synology Disk DS211J
In-Reply-To: <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
Message-ID: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A34@MS-EX7MB-P03.corp.se.sempra.com>

Hey all.
A little off topic, but wanted to share... I purchased a home storage Synology DS1511+. After configuring it on the home net, I did some captures to look at the protocols, and noticed that the DS1511+ is making outgoing connections to 59.124.41.242 (www) and 59.124.41.245 (port 81 & 89) on a regular basis. These addresses are owned by Synology and Chungwa Telecom in Taiwan. 

So far, I've not been able to find much information on their support sites, or Synology's wiki, but I wanted to put it out there. 

GET / HTTP/1.1
Host: 59.124.41.245:81
Accept: */*

HTTP/1.1 200 OK
Date: Thu, 22 Sep 2011 00:11:00 GMT
Server: Apache/2.2.16 (Unix) mod_ssl/2.2.16 OpenSSL/1.0.0c PHP/5.3.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 103
Content-Type: text/html

----------------------------------------
Barry Jones - CISSP GSNA
Project Manager
Sempra Energy Utilities
www.sempra.com
(760) 271-6822
P please don't print this e-mail unless you really need to. 

----------------------------------------
The content contained in this electronic message is not intended to constitute formation of a contract binding Sempra Energy. Sempra Energy will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs.

This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone.

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


From bicknell at ufp.org  Thu Sep 29 14:34:18 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 29 Sep 2011 12:34:18 -0700
Subject: Synology Disk DS211J
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A34@MS-EX7MB-P03.corp.se.sempra.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A34@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <20110929193418.GA35190@ussenterprise.ufp.org>

In a message written on Thu, Sep 29, 2011 at 12:11:48PM -0700, Jones, Barry wrote:
> A little off topic, but wanted to share... I purchased a home storage Synology DS1511+. After configuring it on the home net, I did some captures to look at the protocols, and noticed that the DS1511+ is making outgoing connections to 59.124.41.242 (www) and 59.124.41.245 (port 81 & 89) on a regular basis. These addresses are owned by Synology and Chungwa Telecom in Taiwan. 
> 
> So far, I've not been able to find much information on their support sites, or Synology's wiki, but I wanted to put it out there. 
> 
> GET / HTTP/1.1
> Host: 59.124.41.245:81
> Accept: */*

Perhaps a little further digging was in order?  For instance, putting
the IP and port in a web browser (http://59.124.41.245:81) which
returns:

<html><head><title>Current IP Check</title></head><body>Current IP Address: REDACTED</body></html>

Looking at Synology's web page we find:
http://www.synology.com/dsm/internet_connection.php?lang=us

If they are going to do things like UPNP to open a port, and then DDNS
to let you get there from the outside world than the box needs to know
your outside NAT address, and simple relays like this are the best bet.
It's another ugly hack to get around the problems of a NAT in the
middle.  I bet the box also checks for a new version of software from
time to time.

While I would like vendors to better disclose the "phone home" behavior
of their devices, virtually every computing device does this in some way
or another if only to check for new software.  Windows and Mac's check a
web server to know if you are "connected to the internet" or not.  NAT
traversal often uses a relay.  DDNS registrations need the real IP, and
so on.

Not much to see here, really, other than how ugly some of our protocols
are in the real world.

-- 
       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/20110929/2bc666a1/attachment-0001.bin>

From rcarpen at network1.net  Thu Sep 29 14:52:03 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Thu, 29 Sep 2011 15:52:03 -0400 (EDT)
Subject: Cisco switch LACP + 802.1q
In-Reply-To: <5b2d8ee6-5de0-4b06-9bba-e6abde5e667c@zimbra.network1.net>
Message-ID: <6ccf3b9f-5043-402a-bfa3-e0ebcb75a45a@zimbra.network1.net>


Thanks for all the suggestions.

I added the "switchport mode trunk" to the interfaces, and it did start working properly after a reload of the switch.
Before the reboot, it would not work.

-Randy


----- Original Message -----
> 
> I am tearing my hair out with an issue, and I hope someone can point
> something out to me that I am missing.
> 
> I am setting up 2-port LACP sets on a Cisco 2960G-24TS-L, which then
> need to be 802.1q trunk ports.
> 
> I have set it up as follows:
> 
> interface Port-channel1
>   switchport mode trunk
> !
> interface Port-channel2
>   switchport mode trunk
> !
> interface Port-channel3
>   switchport mode trunk
> !
> interface Port-channel4
>   switchport mode trunk
> !
> interface GigabitEthernet0/1
>  channel-protocol lacp
>  channel-group 1 mode active
> !
> interface GigabitEthernet0/2
>  channel-protocol lacp
>  channel-group 1 mode active
> !
> interface GigabitEthernet0/3
>  channel-protocol lacp
>  channel-group 2 mode active
> !
> interface GigabitEthernet0/4
>  channel-protocol lacp
>  channel-group 2 mode active
> !
> interface GigabitEthernet0/5
>  channel-protocol lacp
>  channel-group 3 mode active
> !
> interface GigabitEthernet0/6
>  channel-protocol lacp
>  channel-group 3 mode active
> !
> interface GigabitEthernet0/7
>  switchport mode trunk
>  channel-protocol lacp
>  channel-group 4 mode active
> !
> interface GigabitEthernet0/8
>  switchport mode trunk
>  channel-protocol lacp
>  channel-group 4 mode active
> 
> 
> The problem is that after some period of time (sometimes minutes,
> sometimes hours), port-channel1 loses the "switchport mode trunk"
> 
> It just disappears from the config.  If I try to put it back, it adds
> "switchport mode trunk" to the member ports (Gi0/1, Gi0/2) as well,
> which does not work. I have to tear it all out and start again. It
> will then work for a while again.
> 
> port-channel2 and port-channel3 are not in use yet, but port-channel4
> is, and works just fine.
> 
> It is running IOS 15.0(1)SE. It was running 12.2 before, and it was
> doing the same thing, so I upgraded it to the latest available.
> 
> What could be the issue?
> 
> thanks,
> -Randy
> 


From mpalmer at hezmatt.org  Thu Sep 29 16:30:40 2011
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Fri, 30 Sep 2011 07:30:40 +1000
Subject: Synology Disk DS211J
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A34@MS-EX7MB-P03.corp.se.sempra.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A34@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <20110929213040.GB3401@mistress.hezmatt.org>

On Thu, Sep 29, 2011 at 12:11:48PM -0700, Jones, Barry wrote:
> A little off topic, but wanted to share... I purchased a home storage
> Synology DS1511+.  After configuring it on the home net, I did some
> captures to look at the protocols, and noticed that the DS1511+ is making
> outgoing connections to 59.124.41.242 (www) and 59.124.41.245 (port 81 &
> 89) on a regular basis.  These addresses are owned by Synology and Chungwa
> Telecom in Taiwan.

And this is why the prudent home admin runs a firewall device he or she can
trust, and has a "default deny" rule in place even for outgoing connections.

- Matt



From nathan at atlasnetworks.us  Thu Sep 29 16:58:23 2011
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 29 Sep 2011 21:58:23 +0000
Subject: Synology Disk DS211J
In-Reply-To: <20110929213040.GB3401@mistress.hezmatt.org>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A34@MS-EX7MB-P03.corp.se.sempra.com>
 <20110929213040.GB3401@mistress.hezmatt.org>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B58F425@ex-mb-1.corp.atlasnetworks.us>

> And this is why the prudent home admin runs a firewall device he or she can
> trust, and has a "default deny" rule in place even for outgoing connections.
> 
> - Matt
> 
> 

The prudent home admin has a default deny rule for outgoing HTTP to port 80?  I doubt it.


From jra at baylink.com  Thu Sep 29 17:40:58 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 29 Sep 2011 18:40:58 -0400 (EDT)
Subject: Synology Disk DS211J
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B58F425@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <27102549.3680.1317336058096.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Nathan Eisenberg" <nathan at atlasnetworks.us>

> > And this is why the prudent home admin runs a firewall device he or she can
> > trust, and has a "default deny" rule in place even for outgoing connections.
> 
> The prudent home admin has a default deny rule for outgoing HTTP to
> port 80? I doubt it.

Why not?  You can poke holes in it specific to *workstations*; anything that
isn't a workstation doesn't generally need to be phoning home without you 
knowing about 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      http://photo.imageinc.us             +1 727 647 1274


From BEJones at semprautilities.com  Thu Sep 29 18:13:46 2011
From: BEJones at semprautilities.com (Jones, Barry)
Date: Thu, 29 Sep 2011 16:13:46 -0700
Subject: Synology Disk DS211J
In-Reply-To: <20110929213040.GB3401@mistress.hezmatt.org>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A34@MS-EX7MB-P03.corp.se.sempra.com>
 <20110929213040.GB3401@mistress.hezmatt.org>
Message-ID: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A50@MS-EX7MB-P03.corp.se.sempra.com>

Yep! 

-----Original Message-----
From: Matthew Palmer [mailto:mpalmer at hezmatt.org] 
Sent: Thursday, September 29, 2011 2:31 PM
To: nanog at nanog.org
Subject: Re: Synology Disk DS211J

On Thu, Sep 29, 2011 at 12:11:48PM -0700, Jones, Barry wrote:
> A little off topic, but wanted to share... I purchased a home storage 
> Synology DS1511+.  After configuring it on the home net, I did some 
> captures to look at the protocols, and noticed that the DS1511+ is 
> making outgoing connections to 59.124.41.242 (www) and 59.124.41.245 
> (port 81 &
> 89) on a regular basis.  These addresses are owned by Synology and 
> Chungwa Telecom in Taiwan.

And this is why the prudent home admin runs a firewall device he or she can trust, and has a "default deny" rule in place even for outgoing connections.

- Matt




From BEJones at semprautilities.com  Thu Sep 29 18:16:44 2011
From: BEJones at semprautilities.com (Jones, Barry)
Date: Thu, 29 Sep 2011 16:16:44 -0700
Subject: Synology Disk DS211J
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A50@MS-EX7MB-P03.corp.se.sempra.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A34@MS-EX7MB-P03.corp.se.sempra.com>
 <20110929213040.GB3401@mistress.hezmatt.org>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A50@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A51@MS-EX7MB-P03.corp.se.sempra.com>

Or, open those specific ports as needed, then close. PITA though (pain in the @ss)

-----Original Message-----
From: Jones, Barry [mailto:BEJones at semprautilities.com] 
Sent: Thursday, September 29, 2011 4:14 PM
To: 'Matthew Palmer'; nanog at nanog.org
Subject: RE: Synology Disk DS211J

Yep! 

-----Original Message-----
From: Matthew Palmer [mailto:mpalmer at hezmatt.org]
Sent: Thursday, September 29, 2011 2:31 PM
To: nanog at nanog.org
Subject: Re: Synology Disk DS211J

On Thu, Sep 29, 2011 at 12:11:48PM -0700, Jones, Barry wrote:
> A little off topic, but wanted to share... I purchased a home storage 
> Synology DS1511+.  After configuring it on the home net, I did some 
> captures to look at the protocols, and noticed that the DS1511+ is 
> making outgoing connections to 59.124.41.242 (www) and 59.124.41.245 
> (port 81 &
> 89) on a regular basis.  These addresses are owned by Synology and 
> Chungwa Telecom in Taiwan.

And this is why the prudent home admin runs a firewall device he or she can trust, and has a "default deny" rule in place even for outgoing connections.

- Matt





From bonomi at mail.r-bonomi.com  Thu Sep 29 19:46:09 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Thu, 29 Sep 2011 19:46:09 -0500 (CDT)
Subject: Synology Disk DS211J
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B58F425@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <201109300046.p8U0k9l9061612@mail.r-bonomi.com>


> From: Nathan Eisenberg <nathan at atlasnetworks.us>
> Subject: RE: Synology Disk DS211J
> Date: Thu, 29 Sep 2011 21:58:23 +0000
>
> > And this is why the prudent home admin runs a firewall device he or she 
> > can trust, and has a "default deny" rule in place even for outgoing 
> > connections.
> >
> > - Matt
> >
> >
>
> The prudent home admin has a default deny rule for outgoing HTTP to port 
> 80?  I doubt it.
>

No, the prudent nd knowledgable prudent home admin does not have default deny
rule just for outgoing HTTP to port 80.

He has a  defult deny rule  for _everything_.  Every internal source address,
and every destination port.  Then he pokes holes in that 'deny everything'
for specific machines to make the kinds of external connections that _they_
need to make.

Blocking outgoing port 80, _except_ from an internal proxy server, is not
necessrily a bad idea.   If the legitimte web clients are all configured
to use the proxy server, then _direct_ external connection attempts are 
an indication that something "not so legitimate" may be runningunning.





From joelja at bogus.com  Thu Sep 29 21:10:10 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Thu, 29 Sep 2011 19:10:10 -0700
Subject: Synology Disk DS211J
In-Reply-To: <201109300046.p8U0k9l9061612@mail.r-bonomi.com>
References: <201109300046.p8U0k9l9061612@mail.r-bonomi.com>
Message-ID: <4E852502.9070007@bogus.com>

On 9/29/11 17:46 , Robert Bonomi wrote:
>> From: Nathan Eisenberg <nathan at atlasnetworks.us>
>> Subject: RE: Synology Disk DS211J
>> Date: Thu, 29 Sep 2011 21:58:23 +0000
>>
>>> And this is why the prudent home admin runs a firewall device he or she 
>>> can trust, and has a "default deny" rule in place even for outgoing 
>>> connections.
>>>
>>> - Matt
>>>
>>>
>>
>> The prudent home admin has a default deny rule for outgoing HTTP to port 
>> 80?  I doubt it.
>>
> 
> No, the prudent nd knowledgable prudent home admin does not have default deny
> rule just for outgoing HTTP to port 80.
> 
> He has a  defult deny rule  for _everything_.  Every internal source address,
> and every destination port.  Then he pokes holes in that 'deny everything'
> for specific machines to make the kinds of external connections that _they_
> need to make.

Tell me how that flys with the customers in your household...

> Blocking outgoing port 80, _except_ from an internal proxy server, is not
> necessrily a bad idea.   If the legitimte web clients are all configured
> to use the proxy server, then _direct_ external connection attempts are 
> an indication that something "not so legitimate" may be runningunning.
> 
> 
> 
> 



From bmanning at vacation.karoshi.com  Thu Sep 29 23:14:39 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 30 Sep 2011 04:14:39 +0000
Subject: Synology Disk DS211J
In-Reply-To: <4E852502.9070007@bogus.com>
References: <201109300046.p8U0k9l9061612@mail.r-bonomi.com>
 <4E852502.9070007@bogus.com>
Message-ID: <20110930041439.GA11043@vacation.karoshi.com.>

On Thu, Sep 29, 2011 at 07:10:10PM -0700, Joel jaeggli wrote:
> On 9/29/11 17:46 , Robert Bonomi wrote:
> >> From: Nathan Eisenberg <nathan at atlasnetworks.us>
> >> Subject: RE: Synology Disk DS211J
> >> Date: Thu, 29 Sep 2011 21:58:23 +0000
> >>
> >>> And this is why the prudent home admin runs a firewall device he or she 
> >>> can trust, and has a "default deny" rule in place even for outgoing 
> >>> connections.
> >>>
> >>> - Matt
> >>>
> >>>
> >>
> >> The prudent home admin has a default deny rule for outgoing HTTP to port 
> >> 80?  I doubt it.
> >>
> > 
> > No, the prudent nd knowledgable prudent home admin does not have default deny
> > rule just for outgoing HTTP to port 80.
> > 
> > He has a  defult deny rule  for _everything_.  Every internal source address,
> > and every destination port.  Then he pokes holes in that 'deny everything'
> > for specific machines to make the kinds of external connections that _they_
> > need to make.
> 
> Tell me how that flys with the customers in your household...
> 

	They are freeloaders, not customers.  If they -PAID-
	for service, then it would be a different conversation.

/bill


From swmike at swm.pp.se  Fri Sep 30 00:07:50 2011
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 30 Sep 2011 07:07:50 +0200 (CEST)
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
Message-ID: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>


Just thought I'd share some operational info.

PFC3B will by default punt IPv6 packets with fragmentation header to RP 
and route them there, with the obvious performance penalty this incurs.

Workaround is to change this behaviour, meaning ACLs won't work for 
packets with fragmentation header anymore:

   #platform ipv6 acl fragment hardware ?
     drop     Drop IPv6 fragments at hardware
     forward  Forward IPv6 fragments at hardware

PFC3C is supposed to not be affected.

A lot of Teredo and 6to4 traffic has fragmentation headers, so this 
actually is a real problem. We discovered this at our Teredo relay 
upstream router.

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


From morrowc.lists at gmail.com  Fri Sep 30 00:55:55 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 30 Sep 2011 01:55:55 -0400
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
Message-ID: <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>

On Fri, Sep 30, 2011 at 1:07 AM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
>
> Just thought I'd share some operational info.
>
> PFC3B will by default punt IPv6 packets with fragmentation header to RP and
> route them there, with the obvious performance penalty this incurs.

when will vendors learn that punting to the RE/RP/smarts for packets
in the fastpath is ... not just 'unwise' but wholesale stupid? :(

>
> Workaround is to change this behaviour, meaning ACLs won't work for packets
> with fragmentation header anymore:
>
> ?#platform ipv6 acl fragment hardware ?
> ? ?drop ? ? Drop IPv6 fragments at hardware
> ? ?forward ?Forward IPv6 fragments at hardware
>

your recommendation is to ... forward? (or perhaps not 'recommendation' but:
"Forward means do not pass go, just ship out the proper egress interface.
 drop means ... send to hell"

If you do nothing the default behavior is to send the packet to the
RP... why? (why would you want this packet sent to the RP? it's got a
valid destination, no? so deliver it out the egress interface?)

thanks!
-chris

> PFC3C is supposed to not be affected.
>
> A lot of Teredo and 6to4 traffic has fragmentation headers, so this actually
> is a real problem. We discovered this at our Teredo relay upstream router.
>
> --
> Mikael Abrahamsson ? ?email: swmike at swm.pp.se
>
>


From swmike at swm.pp.se  Fri Sep 30 01:13:37 2011
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 30 Sep 2011 08:13:37 +0200 (CEST)
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation
 header
In-Reply-To: <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1109300811292.13829@uplift.swm.pp.se>

On Fri, 30 Sep 2011, Christopher Morrow wrote:

> If you do nothing the default behavior is to send the packet to the 
> RP... why? (why would you want this packet sent to the RP? it's got a 
> valid destination, no? so deliver it out the egress interface?)

I was told it's because PFC3B can't look into the packet far enough to 
determine what the payload is (TCP/UDP etc) and port, that's only the RP 
that can do ACL handling of the packet.

So if you configure "forward", people can put a fragmentation header on 
the packet and skip past your ACL.

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


From mpalmer at hezmatt.org  Fri Sep 30 01:18:44 2011
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Fri, 30 Sep 2011 16:18:44 +1000
Subject: Synology Disk DS211J
In-Reply-To: <4E852502.9070007@bogus.com>
References: <201109300046.p8U0k9l9061612@mail.r-bonomi.com>
 <4E852502.9070007@bogus.com>
Message-ID: <20110930061844.GE3401@mistress.hezmatt.org>

On Thu, Sep 29, 2011 at 07:10:10PM -0700, Joel jaeggli wrote:
> On 9/29/11 17:46 , Robert Bonomi wrote:
> >> From: Nathan Eisenberg <nathan at atlasnetworks.us>
> >> Subject: RE: Synology Disk DS211J
> >> Date: Thu, 29 Sep 2011 21:58:23 +0000
> >>
> >>> And this is why the prudent home admin runs a firewall device he or she 
> >>> can trust, and has a "default deny" rule in place even for outgoing 
> >>> connections.
> >>>
> >>> - Matt
> >>>
> >>>
> >>
> >> The prudent home admin has a default deny rule for outgoing HTTP to port 
> >> 80?  I doubt it.
> >>
> > 
> > No, the prudent nd knowledgable prudent home admin does not have default deny
> > rule just for outgoing HTTP to port 80.
> > 
> > He has a  defult deny rule  for _everything_.  Every internal source address,
> > and every destination port.  Then he pokes holes in that 'deny everything'
> > for specific machines to make the kinds of external connections that _they_
> > need to make.
> 
> Tell me how that flys with the customers in your household...

Perfectly fine.  My users know not to go plugging random devices in, and I
properly configure the firewall to account for all legitimate traffic before
the device is commissioned.

- Matt



From william.allen.simpson at gmail.com  Fri Sep 30 04:05:35 2011
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Fri, 30 Sep 2011 05:05:35 -0400
Subject: Facebook insecure by design
Message-ID: <4E85865F.60700@gmail.com>

In accord with the recent thread, "facebook spying on us?"

We should also worry about other spying on us.  Without
some sort of rudimentary security, all that personally
identifiable information is exposed on our ISP networks,
over WiFi, etc.

Facebook claims to be able to run over TLS connections.
Not so much (see attached picture).

This wasn't an "app", this is the simple default content of a
page accessed after a Google search.

   https://www.facebook.com/ceelogreen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen shot 2011-09-30 at 4.54.53 AM.png
Type: image/png
Size: 27356 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110930/e2a2e3f1/attachment-0001.png>

From saku at ytti.fi  Fri Sep 30 05:02:57 2011
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 30 Sep 2011 13:02:57 +0300
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
Message-ID: <20110930100257.GA30922@pob.ytti.fi>

On (2011-09-30 01:55 -0400), Christopher Morrow wrote:
 
> when will vendors learn that punting to the RE/RP/smarts for packets
> in the fastpath is ... not just 'unwise' but wholesale stupid? :(

What to do with IP options or IPv6 hop-by-hop options? What to do with IPv6
packets which contain options which push TCP/UDP past your lookup view?

Punting transit is not only not stupid but also necessary in hardware routers
which cannot handle every case in hardware (which is all routers).
There should just be adequate way to limit these and there should exist default
limitation.

-- 
  ++ytti


From lists at foks.se  Fri Sep 30 06:19:47 2011
From: lists at foks.se (foks)
Date: Fri, 30 Sep 2011 13:19:47 +0200
Subject: Mails to Google being blocked for illegal attachments
Message-ID: <20110930111947.5A677F2D5905D@bmail04.one.com>

Hello,

Since Sep 7 Google has bounced a specific type of our mails with this
message:

host aspmx.l.google.com[74.125.43.27] said: 552-5.7.0 Our system
detected an illegal attachment on your message. Please 552-5.7.0 visit
http://mail.google.com/support/bin/answer.py?answer=6590 to 552 5.7.0
review our attachment guidelines. z4si211085bkd.116 (in reply to end of
DATA command)

The only attachment is a gif image so it seems that Googles check is
wrong. Has anyone experienced this issue, or has any helpful contact
information to Google? I have checked
http://www.google.com/support/a/bin/static.py?page=contacting_support.ht
ml and called these numbers, but they were not able to help me.

Regards,
J?rgen Nilsson

From askoorb+nanog at gmail.com  Fri Sep 30 06:34:02 2011
From: askoorb+nanog at gmail.com (Alex Brooks)
Date: Fri, 30 Sep 2011 12:34:02 +0100
Subject: Mails to Google being blocked for illegal attachments
In-Reply-To: <20110930111947.5A677F2D5905D@bmail04.one.com>
References: <20110930111947.5A677F2D5905D@bmail04.one.com>
Message-ID: <CALKLF0_vySKaY4k7Eu_u8UZHGNYCivCecbsa4uTXHbfONdg=TA@mail.gmail.com>

On Fri, Sep 30, 2011 at 12:19 PM, foks <lists at foks.se> wrote:
>
> Hello,
>
> Since Sep 7 Google has bounced a specific type of our mails with this
> message:
>
> host aspmx.l.google.com[74.125.43.27] said: 552-5.7.0 Our system
> detected an illegal attachment on your message. Please 552-5.7.0 visit
> http://mail.google.com/support/bin/answer.py?answer=6590 to 552 5.7.0
> review our attachment guidelines. z4si211085bkd.116 (in reply to end of
> DATA command)
>
> The only attachment is a gif image so it seems that Googles check is
> wrong. Has anyone experienced this issue, or has any helpful contact
> information to Google? I have checked
> http://www.google.com/support/a/bin/static.py?page=contacting_support.ht
> ml and called these numbers, but they were not able to help me.

Hi,

Have you reported it through their support pages?  The one you're
after is probably:
https://mail.google.com/support/bin/request.py?contact_type=gtag_headers&group=bugflow_attachmentsnewbug&trouble_type=attachments

Generally, checking
https://mail.google.com/support/bin/static.py?page=known_issues.cs is
the first place to go with GMail issues if you're not an Apps
customer; they have a link to reporting problems at the bottom.
Though if you're not an Apps customer (or can't find one to report the
issue on your behalf as not receiving e-mails from you), I wouldn't
hold out too much hope for a response from it.

Do let us know how you solve the problem in the end.

Alex


From tayeb.meftah at gmail.com  Fri Sep 30 07:05:42 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Fri, 30 Sep 2011 14:05:42 +0200
Subject: Mails to Google being blocked for illegal attachments
References: <20110930111947.5A677F2D5905D@bmail04.one.com>
Message-ID: <0AE25C9061CD4DD3BA3C5CC11858590B@work>

Hey
my guess is that maybe the Image have bean built using a Non licensed 
version of Adobe fotoshop or some other software
the US embassy refused it for me cause of that.

----- Original Message ----- 
From: "foks" <lists at foks.se>
To: <nanog at nanog.org>
Sent: Friday, September 30, 2011 1:19 PM
Subject: Mails to Google being blocked for illegal attachments


Hello,

Since Sep 7 Google has bounced a specific type of our mails with this
message:

host aspmx.l.google.com[74.125.43.27] said: 552-5.7.0 Our system
detected an illegal attachment on your message. Please 552-5.7.0 visit
http://mail.google.com/support/bin/answer.py?answer=6590 to 552 5.7.0
review our attachment guidelines. z4si211085bkd.116 (in reply to end of
DATA command)

The only attachment is a gif image so it seems that Googles check is
wrong. Has anyone experienced this issue, or has any helpful contact
information to Google? I have checked
http://www.google.com/support/a/bin/static.py?page=contacting_support.ht
ml and called these numbers, but they were not able to help me.

Regards,
J?rgen Nilsson

__________ Information from ESET NOD32 Antivirus, version of virus signature 
database 6505 (20110930) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__________ Information from ESET NOD32 Antivirus, version of virus signature database 6505 (20110930) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From leigh.porter at ukbroadband.com  Fri Sep 30 07:32:15 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 30 Sep 2011 12:32:15 +0000
Subject: Mails to Google being blocked for illegal attachments
In-Reply-To: <0AE25C9061CD4DD3BA3C5CC11858590B@work>
References: <20110930111947.5A677F2D5905D@bmail04.one.com>
 <0AE25C9061CD4DD3BA3C5CC11858590B@work>
Message-ID: <D181DDABABE57E4DB72FEE00331478643CB25E@EALPO1.ukbroadband.com>

Yeah.. +1 reasons not to use Google Aps..

--
Leigh Porter


> -----Original Message-----
> From: Meftah Tayeb [mailto:tayeb.meftah at gmail.com]
> Sent: 30 September 2011 13:19
> To: foks; nanog at nanog.org
> Subject: Re: Mails to Google being blocked for illegal attachments
> 
> Hey
> my guess is that maybe the Image have bean built using a Non licensed
> version of Adobe fotoshop or some other software
> the US embassy refused it for me cause of that.
> 
> ----- Original Message -----
> From: "foks" <lists at foks.se>
> To: <nanog at nanog.org>
> Sent: Friday, September 30, 2011 1:19 PM
> Subject: Mails to Google being blocked for illegal attachments
> 
> 
> Hello,
> 
> Since Sep 7 Google has bounced a specific type of our mails with this
> message:
> 
> host aspmx.l.google.com[74.125.43.27] said: 552-5.7.0 Our system
> detected an illegal attachment on your message. Please 552-5.7.0 visit
> http://mail.google.com/support/bin/answer.py?answer=6590 to 552 5.7.0
> review our attachment guidelines. z4si211085bkd.116 (in reply to end of
> DATA command)
> 
> The only attachment is a gif image so it seems that Googles check is
> wrong. Has anyone experienced this issue, or has any helpful contact
> information to Google? I have checked
> http://www.google.com/support/a/bin/static.py?page=contacting_support.h
> t
> ml and called these numbers, but they were not able to help me.
> 
> Regards,
> J?rgen Nilsson
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature
> database 6505 (20110930) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 6505 (20110930) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From nanog at maunier.org  Fri Sep 30 07:32:18 2011
From: nanog at maunier.org (Pierre-Yves Maunier)
Date: Fri, 30 Sep 2011 14:32:18 +0200
Subject: Synology Disk DS211J
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A34@MS-EX7MB-P03.corp.se.sempra.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A34@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <CAEGdXrPD5i7HGog6sDV74CpBaAdcJSoMKHB45+7xpuv1oVA9dA@mail.gmail.com>

2011/9/29 Jones, Barry <BEJones at semprautilities.com>

> Hey all.
> A little off topic, but wanted to share... I purchased a home storage
> Synology DS1511+. After configuring it on the home net, I did some captures
> to look at the protocols, and noticed that the DS1511+ is making outgoing
> connections to 59.124.41.242 (www) and 59.124.41.245 (port 81 & 89) on a
> regular basis. These addresses are owned by Synology and Chungwa Telecom in
> Taiwan.
>
> So far, I've not been able to find much information on their support sites,
> or Synology's wiki, but I wanted to put it out there.
>
>
>
Maybe it's for checking new firmware update availability...

-- 
Pierre-Yves Maunier

From ben at bencarleton.com  Fri Sep 30 07:32:31 2011
From: ben at bencarleton.com (Ben Carleton)
Date: Fri, 30 Sep 2011 08:32:31 -0400
Subject: Facebook insecure by design
In-Reply-To: <4E85865F.60700@gmail.com>
References: <4E85865F.60700@gmail.com>
Message-ID: <4E85B6DF.8020803@bencarleton.com>

Actually, the reason for what happened in your example is that Cee Lo's 
page has what is **technically** an app (called I Want You, as seen in 
the sidebar under his profile photo) set as the default screen for when 
you view his page. The app (that does admittedly looks like it could be 
an official feature from facebook) uses externally-hosted HTTP-only 
content, which Facebook will detect and warn you about.

-- Ben

On 9/30/2011 5:05 AM, William Allen Simpson wrote:
> In accord with the recent thread, "facebook spying on us?"
>
> We should also worry about other spying on us.  Without
> some sort of rudimentary security, all that personally
> identifiable information is exposed on our ISP networks,
> over WiFi, etc.
>
> Facebook claims to be able to run over TLS connections.
> Not so much (see attached picture).
>
> This wasn't an "app", this is the simple default content of a
> page accessed after a Google search.
>
>   https://www.facebook.com/ceelogreen



From jra at baylink.com  Fri Sep 30 08:13:44 2011
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 30 Sep 2011 09:13:44 -0400 (EDT)
Subject: Synology Disk DS211J
In-Reply-To: <20110930041439.GA11043@vacation.karoshi.com.>
Message-ID: <14599845.3694.1317388424048.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: bmanning at vacation.karoshi.com

> > Tell me how that flys with the customers in your household...
> 
> They are freeloaders, not customers. If they -PAID-
> for service, then it would be a different conversation.

I'm pretty sure that was a "wife approval factor"/"not everyone's a geek"
observation, Bill.  

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      http://photo.imageinc.us             +1 727 647 1274


From harbor235 at gmail.com  Fri Sep 30 08:50:29 2011
From: harbor235 at gmail.com (harbor235)
Date: Fri, 30 Sep 2011 09:50:29 -0400
Subject: events
Message-ID: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>

What is everyone using to collect, alert, and analyze syslog data?
I am looking for something that can generate reports as well as support
multiple vendors. We have done some home grown stuff in the past but
would be interested in something  that incorprates all the best features.

Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones
out there?


Mike

From hhoffman at ip-solutions.net  Fri Sep 30 08:56:01 2011
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Fri, 30 Sep 2011 09:56:01 -0400
Subject: events
In-Reply-To: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
Message-ID: <4E85CA71.6030003@ip-solutions.net>

It's a bit old but still works well. Russel Fulton and I worked on this 
when I was down in NZ.

You still need to run syslog-ng but this allows you to ignore, warn, 
alert on logs via regex.


http://www.ip-solutions.net/syslog-ng/


Cheers,
Harry



On 09/30/2011 09:50 AM, harbor235 wrote:
> What is everyone using to collect, alert, and analyze syslog data?
> I am looking for something that can generate reports as well as support
> multiple vendors. We have done some home grown stuff in the past but
> would be interested in something  that incorprates all the best features.
>
> Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones
> out there?
>
>
> Mike
>


From blake at pfankuch.me  Fri Sep 30 08:56:42 2011
From: blake at pfankuch.me (Blake T. Pfankuch)
Date: Fri, 30 Sep 2011 13:56:42 +0000
Subject: Synology Disk DS211J
In-Reply-To: <20110930061844.GE3401@mistress.hezmatt.org>
References: <201109300046.p8U0k9l9061612@mail.r-bonomi.com>
 <4E852502.9070007@bogus.com> <20110930061844.GE3401@mistress.hezmatt.org>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C843698D12C@SHSBS.shenrons-house.local>

The easy way around the unhappy significant other/minion shaped offspring solution is to put all of the "end user" devices On a separate VLAN, and then treat that as an open DMZ.  Then everything operational (ironic in a home) on your secured production network (restrict all outbound/inbound except what is needed).  If you really want to complicate it you should even put your wireless into a separate VLAN as well, and secure it as appropriate.  Gives you the ability firewall between networks, thus making sure that when your minions eventually get something nasty going on the PC they use, it doesn't spread through the rest of the network.  Also means you can deploy some form of content filtering policies through various solutions to prevent your minions from discovering the sites running on the most recent TLD addition.  

This assumes that most people reading this email have the ability to run multiple routed subnets behind their home firewall.  Be it a layer 3 switch with ACL's or multiple physical interfaces and the ability to have them act independently.  

Personally I run 8 separate networks (some with multiple routed subnets).  Wireless data, management network, voice networks, game consoles, storage, internal servers, DMZ servers and Project network.  Only reason why there is no "end user" network is that there are no wired drops anywhere in the house, so that falls under the wireless data. That network gets internet access and connectivity to file sharing off the internal servers and all internet traffic runs through Anti-Virus/Anti-Spyware before going outbound and inbound.

Blake

-----Original Message-----
From: Matthew Palmer [mailto:mpalmer at hezmatt.org] 
Sent: Friday, September 30, 2011 12:19 AM
To: nanog at nanog.org
Subject: Re: Synology Disk DS211J

On Thu, Sep 29, 2011 at 07:10:10PM -0700, Joel jaeggli wrote:
> On 9/29/11 17:46 , Robert Bonomi wrote:
> >> From: Nathan Eisenberg <nathan at atlasnetworks.us>
> >> Subject: RE: Synology Disk DS211J
> >> Date: Thu, 29 Sep 2011 21:58:23 +0000
> >>
> >>> And this is why the prudent home admin runs a firewall device he 
> >>> or she can trust, and has a "default deny" rule in place even for 
> >>> outgoing connections.
> >>>
> >>> - Matt
> >>>
> >>>
> >>
> >> The prudent home admin has a default deny rule for outgoing HTTP to 
> >> port 80?  I doubt it.
> >>
> > 
> > No, the prudent nd knowledgable prudent home admin does not have 
> > default deny rule just for outgoing HTTP to port 80.
> > 
> > He has a  defult deny rule  for _everything_.  Every internal source 
> > address, and every destination port.  Then he pokes holes in that 'deny everything'
> > for specific machines to make the kinds of external connections that 
> > _they_ need to make.
> 
> Tell me how that flys with the customers in your household...

Perfectly fine.  My users know not to go plugging random devices in, and I properly configure the firewall to account for all legitimate traffic before the device is commissioned.

- Matt




From brandon.kim at brandontek.com  Fri Sep 30 09:04:23 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Fri, 30 Sep 2011 10:04:23 -0400
Subject: events
In-Reply-To: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
Message-ID: <BLU158-W21D2C52C94CF7C65AFA6EDCF70@phx.gbl>


I've been testing ManageEngines Syslog application. It works pretty good so far, I haven't really hammered
it with a lot of devices. 

Splunk is suppose to be king of the hill I hear, but so is their pricing.....





> Date: Fri, 30 Sep 2011 09:50:29 -0400
> Subject: events
> From: harbor235 at gmail.com
> To: nanog at nanog.org
> 
> What is everyone using to collect, alert, and analyze syslog data?
> I am looking for something that can generate reports as well as support
> multiple vendors. We have done some home grown stuff in the past but
> would be interested in something  that incorprates all the best features.
> 
> Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones
> out there?
> 
> 
> Mike
 		 	   		  

From morrowc.lists at gmail.com  Fri Sep 30 09:09:54 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 30 Sep 2011 10:09:54 -0400
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <20110930100257.GA30922@pob.ytti.fi>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
Message-ID: <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>

On Fri, Sep 30, 2011 at 6:02 AM, Saku Ytti <saku at ytti.fi> wrote:
> On (2011-09-30 01:55 -0400), Christopher Morrow wrote:
>
>> when will vendors learn that punting to the RE/RP/smarts for packets
>> in the fastpath is ... not just 'unwise' but wholesale stupid? :(
>
> What to do with IP options or IPv6 hop-by-hop options? What to do with IPv6
> packets which contain options which push TCP/UDP past your lookup view?

a switch to be used that stops processing this sort of thing, in an
internet core (and honestly most enterprise core) routers, all I want
is packet-in/packet-out. there's no need for anything else, stop
trying to send line-rate packets to the cpu.

> Punting transit is not only not stupid but also necessary in hardware routers
> which cannot handle every case in hardware (which is all routers).

no. all you need is a default 'do not process these, just fwd them'
switch. (or, a switch at any rate that the operator can select one way
or the other, they SHOULD know what is the best for their deployment).

> There should just be adequate way to limit these and there should exist default
> limitation.

I really think zero limit is the right limit... (for a large number of
deployments)


From saku at ytti.fi  Fri Sep 30 09:26:39 2011
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 30 Sep 2011 17:26:39 +0300
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
Message-ID: <20110930142639.GA30986@pob.ytti.fi>

On (2011-09-30 10:09 -0400), Christopher Morrow wrote:

> a switch to be used that stops processing this sort of thing, in an
> internet core (and honestly most enterprise core) routers, all I want
> is packet-in/packet-out. there's no need for anything else, stop
> trying to send line-rate packets to the cpu.

This would break e.g. RSVP. For some instances dropping all of them in hardware
is an option, for other instances ignoring and forwarding without understanding
is ok but some situation you simply must punt.

> no. all you need is a default 'do not process these, just fwd them'
> switch. (or, a switch at any rate that the operator can select one way
> or the other, they SHOULD know what is the best for their deployment).

It would also break L4 ACL under certain situations, as well as RSVP as already
explained. And probably issues I'm not aware of. Unsure if blind forwarding is
best option. But I'm all for giving operator options, but calling it stupid
that vendors punt something is misguided.

> I really think zero limit is the right limit... (for a large number of
> deployments)

Traceroute would also break. Unpoliced punting certainly is extremely unwise,
but punting to a level that does not introduce significant CPU load, should be
safest default.


-- 
  ++ytti


From bicknell at ufp.org  Fri Sep 30 09:27:34 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 30 Sep 2011 07:27:34 -0700
Subject: Synology Disk DS211J
In-Reply-To: <CC75EEBF17C7374EA8309102B7B10C843698D12C@SHSBS.shenrons-house.local>
References: <201109300046.p8U0k9l9061612@mail.r-bonomi.com>
 <4E852502.9070007@bogus.com> <20110930061844.GE3401@mistress.hezmatt.org>
 <CC75EEBF17C7374EA8309102B7B10C843698D12C@SHSBS.shenrons-house.local>
Message-ID: <20110930142734.GA86851@ussenterprise.ufp.org>

In a message written on Fri, Sep 30, 2011 at 01:56:42PM +0000, Blake T. Pfankuch wrote:
> Personally I run 8 separate networks (some with multiple routed subnets).  Wireless data, management network, voice networks, game consoles, storage, internal servers, DMZ servers and Project network.  Only reason why there is no "end user" network is that there are no wired drops anywhere in the house, so that falls under the wireless data. That network gets internet access and connectivity to file sharing off the internal servers and all internet traffic runs through Anti-Virus/Anti-Spyware before going outbound and inbound.

You've inspired me to go invest in Alcoa stock.  NYSE AA for anyone
else interested.  The tin-foil demand in this thread alone must
have them running an extra shift. :)

-- 
       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/20110930/33318170/attachment.bin>

From morrowc.lists at gmail.com  Fri Sep 30 09:45:54 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 30 Sep 2011 10:45:54 -0400
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <20110930142639.GA30986@pob.ytti.fi>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
Message-ID: <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>

On Fri, Sep 30, 2011 at 10:26 AM, Saku Ytti <saku at ytti.fi> wrote:
> explained. And probably issues I'm not aware of. Unsure if blind forwarding is
> best option. But I'm all for giving operator options, but calling it stupid
> that vendors punt something is misguided.

after this long, yes... this is just dumb, there's no reason that the
default should be punt. There are cases (you've brought up a few)
where it's required today because of design limitations, there really
shouldn't be cases like this anymore. this isn't our first rodeo,
'lessons learned' and all that...

>
>> I really think zero limit is the right limit... (for a large number of
>> deployments)
>
> Traceroute would also break. Unpoliced punting certainly is extremely unwise,

traceroute could certainly be handled in the fastpath.

> but punting to a level that does not introduce significant CPU load, should be
> safest default.

what is that limit? from a single port? from a single linecard? from a
chassis? how about we remove complexity here and just deal with this
in the fastpath?

My point in calling this all 'stupid' is that by now we all have been
burned by this sort of behavior, vendors have heard from all of us
that 'this is really not a good answer', enough is enough please stop
doing this.

-chris


From saku at ytti.fi  Fri Sep 30 10:08:08 2011
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 30 Sep 2011 18:08:08 +0300
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
Message-ID: <20110930150808.GA30995@pob.ytti.fi>

On (2011-09-30 10:45 -0400), Christopher Morrow wrote:

> after this long, yes... this is just dumb, there's no reason that the
> default should be punt. There are cases (you've brought up a few)
> where it's required today because of design limitations, there really
> shouldn't be cases like this anymore. this isn't our first rodeo,
> 'lessons learned' and all that...

Certainly possible, but will you pay the premium? I won't. To implement IPv6
according to standard your lookup engine needs to have MTU wide view, so up-to
65kB. Most common view today probably is 64B and highest I know 256B.
And for the corner cases where this isn't enough, I'm happy to handle it in
software, rather than pay premium to do it all in hardware.

> traceroute could certainly be handled in the fastpath.

Yup. But again who would pay for this? I cannot be dossed by TTL exceeds as
there is sufficient protetion mechanism in my hardware. So I would not pay
premium for this feature.

> what is that limit? from a single port? from a single linecard? from a
> chassis? how about we remove complexity here and just deal with this
> in the fastpath?

It would increase cost and complexity greatly. If I could get it for free, then
I would take it, but I have lot more important things I want router vendors fix
first. I do wish vendor would do is test box with attack vectors and implement
sane defaults (IOS-XR is relatively good in this respect, or maybe it just
looks that way as rest of them are really bad with their defaults).

Very recently I had chat with GSR owner who was happy how GSR/IOS is solid DDoS
resistant platform, while actually it is impossible to protect GSR/IOS (outside
iACL) as none of the protections (rACL/CoPP) are implemented in hardware. 7600
is reasonably good for its age in this matter.
But even modern examples, like MX80 completely fail with defaults. Killed MX80
in lab with bit over 5Mbps of IP options. Protection is quite easy but still
most people do not do it, so vendors really should ship boxes with saner
defaults.

-- 
  ++ytti


From nick at foobar.org  Fri Sep 30 10:24:01 2011
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 30 Sep 2011 16:24:01 +0100
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
Message-ID: <4E85DF11.1030905@foobar.org>

On 30/09/2011 15:45, Christopher Morrow wrote:
> traceroute could certainly be handled in the fastpath.

which traceroute?  icmp?  udp?  tcp?  Traceroute is not a single protocol.

> what is that limit? from a single port? from a single linecard? from a
> chassis? how about we remove complexity here and just deal with this
> in the fastpath?

on a pfc3, the mls rate limiters deal with handling all punts from the
chassis to the RP.  It's difficult to handle this in any other way.

> My point in calling this all 'stupid' is that by now we all have been
> burned by this sort of behavior, vendors have heard from all of us
> that 'this is really not a good answer', enough is enough please stop
> doing this.

"This is a Hard Problem".  There is a balance to be drawn between hardware
complexity, cost and lifecycle.  In the case of the PFC3, we're talking
about hardware which was released in 2000 - 11 years ago.  The ipv6
fragment punting problem was fixed in the pfc3c, which was released in
2003.  I'm aware that cisco is still selling the pfc3b, but they really
only push the rsp720 for internet stuff (if they're pushing the 6500/7600
line at all).

Nick



From mohacsi at niif.hu  Fri Sep 30 10:38:06 2011
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Fri, 30 Sep 2011 17:38:06 +0200 (CEST)
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation
 header
In-Reply-To: <4E85DF11.1030905@foobar.org>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
 <4E85DF11.1030905@foobar.org>
Message-ID: <alpine.BSF.2.00.1109301736220.98791@mignon.ki.iif.hu>




On Fri, 30 Sep 2011, Nick Hilliard wrote:

> On 30/09/2011 15:45, Christopher Morrow wrote:
>> traceroute could certainly be handled in the fastpath.
>
> which traceroute?  icmp?  udp?  tcp?  Traceroute is not a single protocol.
>
>> what is that limit? from a single port? from a single linecard? from a
>> chassis? how about we remove complexity here and just deal with this
>> in the fastpath?
>
> on a pfc3, the mls rate limiters deal with handling all punts from the
> chassis to the RP.  It's difficult to handle this in any other way.
>
>> My point in calling this all 'stupid' is that by now we all have been
>> burned by this sort of behavior, vendors have heard from all of us
>> that 'this is really not a good answer', enough is enough please stop
>> doing this.
>
> "This is a Hard Problem".  There is a balance to be drawn between hardware
> complexity, cost and lifecycle.  In the case of the PFC3, we're talking
> about hardware which was released in 2000 - 11 years ago.  The ipv6
> fragment punting problem was fixed in the pfc3c, which was released in
> 2003.  I'm aware that cisco is still selling the pfc3b, but they really
> only push the rsp720 for internet stuff (if they're pushing the 6500/7600
> line at all).

They are pushing sup2T - however more for enterprise ip layer (6500 
series).
 	Regards,
 		Janos Mohacsi



From Vinny_Abello at Dell.com  Fri Sep 30 10:53:19 2011
From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com)
Date: Fri, 30 Sep 2011 15:53:19 +0000
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <20110930142639.GA30986@pob.ytti.fi>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
Message-ID: <FD9B2CB2B33E394FAE3B746695476057129EB590@DFWX10HMPTC05.AMER.DELL.COM>

Path MTU discovery would also break... oh wait, that's usually broken anyway.

-Vinny

-----Original Message-----
From: Saku Ytti [mailto:saku at ytti.fi] 
Sent: Friday, September 30, 2011 10:27 AM
To: nanog at nanog.org
Subject: Re: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header

On (2011-09-30 10:09 -0400), Christopher Morrow wrote:

> a switch to be used that stops processing this sort of thing, in an
> internet core (and honestly most enterprise core) routers, all I want
> is packet-in/packet-out. there's no need for anything else, stop
> trying to send line-rate packets to the cpu.

This would break e.g. RSVP. For some instances dropping all of them in hardware
is an option, for other instances ignoring and forwarding without understanding
is ok but some situation you simply must punt.

> no. all you need is a default 'do not process these, just fwd them'
> switch. (or, a switch at any rate that the operator can select one way
> or the other, they SHOULD know what is the best for their deployment).

It would also break L4 ACL under certain situations, as well as RSVP as already
explained. And probably issues I'm not aware of. Unsure if blind forwarding is
best option. But I'm all for giving operator options, but calling it stupid
that vendors punt something is misguided.

> I really think zero limit is the right limit... (for a large number of
> deployments)

Traceroute would also break. Unpoliced punting certainly is extremely unwise,
but punting to a level that does not introduce significant CPU load, should be
safest default.


-- 
  ++ytti



From nick at foobar.org  Fri Sep 30 11:00:51 2011
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 30 Sep 2011 17:00:51 +0100
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <alpine.BSF.2.00.1109301736220.98791@mignon.ki.iif.hu>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
 <4E85DF11.1030905@foobar.org>
 <alpine.BSF.2.00.1109301736220.98791@mignon.ki.iif.hu>
Message-ID: <4E85E7B3.7050001@foobar.org>

On 30/09/2011 16:38, Mohacsi Janos wrote:
> They are pushing sup2T - however more for enterprise ip layer (6500 series).

they are now, yes.  But until the sup2t started becoming available a couple
of weeks ago the only option for the 6500 was a sup720.  You're right that
this was only pushed on the enterprise market.

Of course, if you wanted a 10g capable service provider router and didn't
want an asr9k, they were pushing the 7600 because the 6500 is a switch and
the 7600 is a router and the two are totally different, no really you've
gotta believe it.  But at least the rsp720 could handle ipv6 fragments better.

Nick



From morrowc.lists at gmail.com  Fri Sep 30 11:30:16 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 30 Sep 2011 12:30:16 -0400
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <4E85DF11.1030905@foobar.org>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
 <4E85DF11.1030905@foobar.org>
Message-ID: <CAL9jLaa7fNkw_GG9_UemR95v-s=Ae2MLPv-ii6NaGvGvPntopg@mail.gmail.com>

On Fri, Sep 30, 2011 at 11:24 AM, Nick Hilliard <nick at foobar.org> wrote:
> On 30/09/2011 15:45, Christopher Morrow wrote:
>> traceroute could certainly be handled in the fastpath.
>
> which traceroute? ?icmp? ?udp? ?tcp? ?Traceroute is not a single protocol.
>

traceroute is really an example of 'packet expired, send
unreachable'... that, today is basically:
  o grab 64bytes of header (or something similar)
  o shove that in a payload
  o use the src as the dst
  o stick my src on
  o set icmp
  o crc and fire

there's not really any need to do this in the slow path, is there?
-chris


From morrowc.lists at gmail.com  Fri Sep 30 11:31:15 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 30 Sep 2011 12:31:15 -0400
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <4E85E7B3.7050001@foobar.org>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
 <4E85DF11.1030905@foobar.org>
 <alpine.BSF.2.00.1109301736220.98791@mignon.ki.iif.hu>
 <4E85E7B3.7050001@foobar.org>
Message-ID: <CAL9jLaZc07eEVVZRKiAHKSLkrp7cJZ_asEy9tdcX6xp5_qx4cQ@mail.gmail.com>

On Fri, Sep 30, 2011 at 12:00 PM, Nick Hilliard <nick at foobar.org> wrote:
> Of course, if you wanted a 10g capable service provider router and didn't
> want an asr9k, they were pushing the 7600 because the 6500 is a switch and
> the 7600 is a router and the two are totally different, no really you've
> gotta believe it. ?But at least the rsp720 could handle ipv6 fragments better.
>

if I turn my head to the side I can almost believe you.


From pfunix at gmail.com  Fri Sep 30 11:37:22 2011
From: pfunix at gmail.com (Beavis)
Date: Fri, 30 Sep 2011 10:37:22 -0600
Subject: events
In-Reply-To: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
Message-ID: <CAMvhC_44gr4rS026fLDYZ1=KZHCs83gG-LQ6PTR-M44U5HamHQ@mail.gmail.com>

We use splunk works ok except with the amount of text data you can
process with it (depends on license).

-B

On Fri, Sep 30, 2011 at 7:50 AM, harbor235 <harbor235 at gmail.com> wrote:
> What is everyone using to collect, alert, and analyze syslog data?
> I am looking for something that can generate reports as well as support
> multiple vendors. We have done some home grown stuff in the past but
> would be interested in something ?that incorprates all the best features.
>
> Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones
> out there?
>
>
> Mike
>



-- 
()? ascii ribbon campaign - against html e-mail
/\? www.asciiribbon.org?? - against proprietary attachments

Disclaimer:
http://goldmark.org/jeff/stupid-disclaimers/


From nick at foobar.org  Fri Sep 30 11:38:09 2011
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 30 Sep 2011 17:38:09 +0100
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <CAL9jLaa7fNkw_GG9_UemR95v-s=Ae2MLPv-ii6NaGvGvPntopg@mail.gmail.com>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
 <4E85DF11.1030905@foobar.org>
 <CAL9jLaa7fNkw_GG9_UemR95v-s=Ae2MLPv-ii6NaGvGvPntopg@mail.gmail.com>
Message-ID: <4E85F071.80201@foobar.org>

On 30/09/2011 17:30, Christopher Morrow wrote:
> traceroute is really an example of 'packet expired, send
> unreachable'... that, today is basically:
>   o grab 64bytes of header (or something similar)
>   o shove that in a payload
>   o use the src as the dst
>   o stick my src on
>   o set icmp
>   o crc and fire
> 
> there's not really any need to do this in the slow path, is there?

there are unconfirmed rumours that icmp ping and traceroute are handled by
hardware on the asr1k.  I don't know if they are true.   But you're right -
it would be good to support this without resorting to hammering the routing
engine.  I don't really like the idea of punters running traceroutes
reducing my bgp convergence time.

Nick



From morrowc.lists at gmail.com  Fri Sep 30 11:44:29 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 30 Sep 2011 12:44:29 -0400
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <4E85F071.80201@foobar.org>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
 <4E85DF11.1030905@foobar.org>
 <CAL9jLaa7fNkw_GG9_UemR95v-s=Ae2MLPv-ii6NaGvGvPntopg@mail.gmail.com>
 <4E85F071.80201@foobar.org>
Message-ID: <CAL9jLaZRzJKDhvw4KwPwzCCSYwyRF4-PUFasp-6pgDUqp69P7g@mail.gmail.com>

On Fri, Sep 30, 2011 at 12:38 PM, Nick Hilliard <nick at foobar.org> wrote:
> On 30/09/2011 17:30, Christopher Morrow wrote:
>> traceroute is really an example of 'packet expired, send
>> unreachable'... that, today is basically:
>> ? o grab 64bytes of header (or something similar)
>> ? o shove that in a payload
>> ? o use the src as the dst
>> ? o stick my src on
>> ? o set icmp
>> ? o crc and fire
>>
>> there's not really any need to do this in the slow path, is there?
>
> there are unconfirmed rumours that icmp ping and traceroute are handled by
> hardware on the asr1k. ?I don't know if they are true. ? But you're right -

some platforms do some/all of this in hardware, yes. (I forget the matrix)

> it would be good to support this without resorting to hammering the routing
> engine. ?I don't really like the idea of punters running traceroutes
> reducing my bgp convergence time.

this is exactly why punting anything NOT management and/or
routing-protocols should be banned. Thanks for making that point
explicitly.

-chris


From brandon.kim at brandontek.com  Fri Sep 30 12:21:41 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Fri, 30 Sep 2011 13:21:41 -0400
Subject: events
In-Reply-To: <CAMvhC_44gr4rS026fLDYZ1=KZHCs83gG-LQ6PTR-M44U5HamHQ@mail.gmail.com>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>,
 <CAMvhC_44gr4rS026fLDYZ1=KZHCs83gG-LQ6PTR-M44U5HamHQ@mail.gmail.com>
Message-ID: <BLU158-W6487104EECF26B798950DADCF70@phx.gbl>


Is it really that expensive, and WORTH the expense?




> Date: Fri, 30 Sep 2011 10:37:22 -0600
> Subject: Re: events
> From: pfunix at gmail.com
> To: harbor235 at gmail.com
> CC: nanog at nanog.org
> 
> We use splunk works ok except with the amount of text data you can
> process with it (depends on license).
> 
> -B
> 
> On Fri, Sep 30, 2011 at 7:50 AM, harbor235 <harbor235 at gmail.com> wrote:
> > What is everyone using to collect, alert, and analyze syslog data?
> > I am looking for something that can generate reports as well as support
> > multiple vendors. We have done some home grown stuff in the past but
> > would be interested in something  that incorprates all the best features.
> >
> > Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones
> > out there?
> >
> >
> > Mike
> >
> 
> 
> 
> -- 
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
> 
> Disclaimer:
> http://goldmark.org/jeff/stupid-disclaimers/
> 
 		 	   		  

From packetjockey at gmail.com  Fri Sep 30 12:24:11 2011
From: packetjockey at gmail.com (Rafael Rodriguez)
Date: Fri, 30 Sep 2011 13:24:11 -0400
Subject: events
In-Reply-To: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
Message-ID: <CALWyk_DdzZmw6tj1j639u4J7Wp8DcT82W5hqPLCK4Ku8_j3skA@mail.gmail.com>

Use Splunk here.

Cheers,
RR

On Fri, Sep 30, 2011 at 9:50 AM, harbor235 <harbor235 at gmail.com> wrote:

> What is everyone using to collect, alert, and analyze syslog data?
> I am looking for something that can generate reports as well as support
> multiple vendors. We have done some home grown stuff in the past but
> would be interested in something  that incorprates all the best features.
>
> Soalrwinds, splunk, fwanalog, and others come to mind, any other good ones
> out there?
>
>
> Mike
>

From mloftis at wgops.com  Fri Sep 30 12:36:58 2011
From: mloftis at wgops.com (Michael Loftis)
Date: Fri, 30 Sep 2011 11:36:58 -0600
Subject: events
In-Reply-To: <BLU158-W6487104EECF26B798950DADCF70@phx.gbl>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
 <CAMvhC_44gr4rS026fLDYZ1=KZHCs83gG-LQ6PTR-M44U5HamHQ@mail.gmail.com>
 <BLU158-W6487104EECF26B798950DADCF70@phx.gbl>
Message-ID: <CAHDg04sNcKMBf8+sxw3ZRVkhRFwKQU8vLvLTSJxXY+THL2wGBA@mail.gmail.com>

On Fri, Sep 30, 2011 at 11:21 AM, Brandon Kim
<brandon.kim at brandontek.com> wrote:
>
> Is it really that expensive, and WORTH the expense?

IMO, from price quotes I've gotten in the past, it's astronomically
expensive.  As for worth it...depends.  If you're dealing with events
for say payment processing systems, it might be.  But as a general use
tool, it's way outside of being worth it.  You license based on the
incoming bytes of logging data.  But you still have to buy the
hardware to process it.  They also expect you to pay for that license
time and time again.


From brandon.kim at brandontek.com  Fri Sep 30 13:13:44 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Fri, 30 Sep 2011 14:13:44 -0400
Subject: events
In-Reply-To: <CAHDg04sNcKMBf8+sxw3ZRVkhRFwKQU8vLvLTSJxXY+THL2wGBA@mail.gmail.com>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>,
 <CAMvhC_44gr4rS026fLDYZ1=KZHCs83gG-LQ6PTR-M44U5HamHQ@mail.gmail.com>,
 <BLU158-W6487104EECF26B798950DADCF70@phx.gbl>,
 <CAHDg04sNcKMBf8+sxw3ZRVkhRFwKQU8vLvLTSJxXY+THL2wGBA@mail.gmail.com>
Message-ID: <BLU158-W116567FE383FF900DF0ACDDCF70@phx.gbl>


Thank you! That's a bummer about the way they license their product.

All it takes is another "splunk" company to come out with something just as competitive....

I've been happy with my basic ManageEngine's syslog, but I may be looking at Solarwinds too...



> Date: Fri, 30 Sep 2011 11:36:58 -0600
> Subject: Re: events
> From: mloftis at wgops.com
> To: brandon.kim at brandontek.com
> CC: pfunix at gmail.com; harbor235 at gmail.com; nanog at nanog.org
> 
> On Fri, Sep 30, 2011 at 11:21 AM, Brandon Kim
> <brandon.kim at brandontek.com> wrote:
> >
> > Is it really that expensive, and WORTH the expense?
> 
> IMO, from price quotes I've gotten in the past, it's astronomically
> expensive.  As for worth it...depends.  If you're dealing with events
> for say payment processing systems, it might be.  But as a general use
> tool, it's way outside of being worth it.  You license based on the
> incoming bytes of logging data.  But you still have to buy the
> hardware to process it.  They also expect you to pay for that license
> time and time again.
 		 	   		  

From jason at lixfeld.ca  Fri Sep 30 13:21:38 2011
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Fri, 30 Sep 2011 14:21:38 -0400
Subject: events
In-Reply-To: <BLU158-W116567FE383FF900DF0ACDDCF70@phx.gbl>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>,
 <CAMvhC_44gr4rS026fLDYZ1=KZHCs83gG-LQ6PTR-M44U5HamHQ@mail.gmail.com>,
 <BLU158-W6487104EECF26B798950DADCF70@phx.gbl>,
 <CAHDg04sNcKMBf8+sxw3ZRVkhRFwKQU8vLvLTSJxXY+THL2wGBA@mail.gmail.com>
 <BLU158-W116567FE383FF900DF0ACDDCF70@phx.gbl>
Message-ID: <C73D04D0-8FA2-4B69-95D9-9017ED0ED446@lixfeld.ca>

On 2011-09-30, at 2:13 PM, Brandon Kim wrote:

> I've been happy with my basic ManageEngine's syslog, but I may be looking at Solarwinds too...

I've just installed the Splunk eval myself, but I'm curious about your ManageEngine experiences.  I don't have any interest in using ManageEngine as an NMS; I have a couple of tools that I use for that already.  Can you use ManageEngine's syslog without having to set it up to monitor all of your devices first?  Have you looked at the TRAP support in ManageEngine?

From dougb at dougbarton.us  Fri Sep 30 13:25:53 2011
From: dougb at dougbarton.us (Doug Barton)
Date: Fri, 30 Sep 2011 11:25:53 -0700
Subject: Synology Disk DS211J
In-Reply-To: <14599845.3694.1317388424048.JavaMail.root@benjamin.baylink.com>
References: <14599845.3694.1317388424048.JavaMail.root@benjamin.baylink.com>
Message-ID: <4E8609B1.7040001@dougbarton.us>

On 09/30/2011 06:13, Jay Ashworth wrote:
> "not everyone's a geek"

Right!


Doug (wait, what?!?)

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/



From Josh.Stephens at solarwinds.com  Fri Sep 30 13:29:43 2011
From: Josh.Stephens at solarwinds.com (Stephens, Josh)
Date: Fri, 30 Sep 2011 18:29:43 +0000
Subject: events
In-Reply-To: <BLU158-W116567FE383FF900DF0ACDDCF70@phx.gbl>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>, 
 <CAMvhC_44gr4rS026fLDYZ1=KZHCs83gG-LQ6PTR-M44U5HamHQ@mail.gmail.com>,
 <BLU158-W6487104EECF26B798950DADCF70@phx.gbl>,
 <CAHDg04sNcKMBf8+sxw3ZRVkhRFwKQU8vLvLTSJxXY+THL2wGBA@mail.gmail.com>
 <BLU158-W116567FE383FF900DF0ACDDCF70@phx.gbl>
Message-ID: <7715397372EE344E96F03DBEA1E8894E3DFB778A@ADF-MBX-02.tul.solarwinds.net>

I'm obviously biased as I'm the Head Geek here at SolarWinds but if you need any help or guidance with our products feel free to ping me off list.

Josh

-----Original Message-----
From: Brandon Kim [mailto:brandon.kim at brandontek.com] 
Sent: Friday, September 30, 2011 1:14 PM
To: mloftis at wgops.com
Cc: nanog group
Subject: RE: events


Thank you! That's a bummer about the way they license their product.

All it takes is another "splunk" company to come out with something just as competitive....

I've been happy with my basic ManageEngine's syslog, but I may be looking at Solarwinds too...



> Date: Fri, 30 Sep 2011 11:36:58 -0600
> Subject: Re: events
> From: mloftis at wgops.com
> To: brandon.kim at brandontek.com
> CC: pfunix at gmail.com; harbor235 at gmail.com; nanog at nanog.org
> 
> On Fri, Sep 30, 2011 at 11:21 AM, Brandon Kim
> <brandon.kim at brandontek.com> wrote:
> >
> > Is it really that expensive, and WORTH the expense?
> 
> IMO, from price quotes I've gotten in the past, it's astronomically
> expensive.  As for worth it...depends.  If you're dealing with events
> for say payment processing systems, it might be.  But as a general use
> tool, it's way outside of being worth it.  You license based on the
> incoming bytes of logging data.  But you still have to buy the
> hardware to process it.  They also expect you to pay for that license
> time and time again.
 		 	   		  


From ukpong.ukpong at gmail.com  Fri Sep 30 13:44:06 2011
From: ukpong.ukpong at gmail.com (Ukpong Ukpong)
Date: Fri, 30 Sep 2011 19:44:06 +0100
Subject: events
In-Reply-To: <C73D04D0-8FA2-4B69-95D9-9017ED0ED446@lixfeld.ca>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
 <CAMvhC_44gr4rS026fLDYZ1=KZHCs83gG-LQ6PTR-M44U5HamHQ@mail.gmail.com>
 <BLU158-W6487104EECF26B798950DADCF70@phx.gbl>
 <CAHDg04sNcKMBf8+sxw3ZRVkhRFwKQU8vLvLTSJxXY+THL2wGBA@mail.gmail.com>
 <BLU158-W116567FE383FF900DF0ACDDCF70@phx.gbl>
 <C73D04D0-8FA2-4B69-95D9-9017ED0ED446@lixfeld.ca>
Message-ID: <-3411316358946087267@unknownmsgid>

Have you tried qradar? It's rather good



On 30 Sep 2011, at 19:21, Jason Lixfeld <jason at lixfeld.ca> wrote:

> On 2011-09-30, at 2:13 PM, Brandon Kim wrote:
>
>> I've been happy with my basic ManageEngine's syslog, but I may be looking at Solarwinds too...
>
> I've just installed the Splunk eval myself, but I'm curious about your ManageEngine experiences.  I don't have any interest in using ManageEngine as an NMS; I have a couple of tools that I use for that already.  Can you use ManageEngine's syslog without having to set it up to monitor all of your devices first?  Have you looked at the TRAP support in ManageEngine?


From jeffg at opennms.org  Fri Sep 30 13:53:23 2011
From: jeffg at opennms.org (Jeff Gehlbach)
Date: Fri, 30 Sep 2011 14:53:23 -0400
Subject: events
In-Reply-To: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
Message-ID: <4E861023.7020001@opennms.org>

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

On 09/30/2011 09:50 AM, harbor235 wrote:

> Soalrwinds, splunk, fwanalog, and others come to mind, any other
good ones
> out there?

We've made some great strides in OpenNMS in the area of syslog event
processing.  The upcoming 1.10 release will be much easier to get
going, particularly since we now have pluggable message parsers -- you
no longer need Wireshark and a black belt in regular expressions to
start receiving events from syslog sources.  We've also made it
possible to split the syslog rules across multiple files, which makes
maintaining your own rules much easier compared to the old monolithic
style.

It's still not going to be Splunk-easy to configure, but it's now
darned close to Netcool OMNIbus syslogd probe-easy.  Plus you get
pretty JasperReports reports based on your events like this one (or
roll your own):

http://opennms.org/~jeffg/event-analysis-sample.pdf

Also flexible event notifications, event de-duplication, and SNMP trap
handling as well as service-assurance polling, performance data
collection via SNMP, HTTP, WMI, SQL/JDBC, and other protocols.

Oh yeah, it's 100% free / libre / open source software.  And you can
get support for it from my employer.

PR hat off,
- -jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6GEB0ACgkQB3953+hexDrEPACfRzSKZxijkirgVgTA0OTRrGjX
27IAoJ7Ef0Cv33zRsYVN50YNbL3tVvLq
=5v3H
-----END PGP SIGNATURE-----


From cscora at apnic.net  Fri Sep 30 14:39:20 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 1 Oct 2011 05:39:20 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201109301939.p8UJdKE1023629@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,
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 01 Oct, 2011

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

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

BGP routing table entries examined:                              374848
    Prefixes after maximum aggregation:                          168719
    Deaggregation factor:                                          2.22
    Unique aggregates announced to Internet:                     185153
Total ASes present in the Internet Routing Table:                 38930
    Prefixes per ASN:                                              9.63
Origin-only ASes present in the Internet Routing Table:           32252
Origin ASes announcing only one prefix:                           15477
Transit ASes present in the Internet Routing Table:                5218
Transit-only ASes present in the Internet Routing Table:            137
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:              1474
    Unregistered ASNs in the Routing Table:                         802
Number of 32-bit ASNs allocated by the RIRs:                       1802
Number of 32-bit ASNs visible in the Routing Table:                1460
Prefixes from 32-bit ASNs in the Routing Table:                    3347
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            103
Number of addresses announced to Internet:                   2481536768
    Equivalent to 147 /8s, 233 /16s and 63 /24s
    Percentage of available address space announced:               67.0
    Percentage of allocated address space announced:               67.0
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               91.4
Total number of prefixes smaller than registry allocations:      156962

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

Prefixes being announced by APNIC Region ASes:                    93945
    Total APNIC prefixes after maximum aggregation:               30799
    APNIC Deaggregation factor:                                    3.05
Prefixes being announced from the APNIC address blocks:           90409
    Unique aggregates announced from the APNIC address blocks:    37945
APNIC Region origin ASes present in the Internet Routing Table:    4567
    APNIC Prefixes per ASN:                                       19.80
APNIC Region origin ASes announcing only one prefix:               1260
APNIC Region transit ASes present in the Internet Routing Table:    707
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         19
Number of APNIC region 32-bit ASNs visible in the Routing Table:     90
Number of APNIC addresses announced to Internet:              628377696
    Equivalent to 37 /8s, 116 /16s and 72 /24s
    Percentage of available APNIC address space announced:         79.7

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
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, 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:                    143988
    Total ARIN prefixes after maximum aggregation:                73994
    ARIN Deaggregation factor:                                     1.95
Prefixes being announced from the ARIN address blocks:           116124
    Unique aggregates announced from the ARIN address blocks:     47994
ARIN Region origin ASes present in the Internet Routing Table:    14694
    ARIN Prefixes per ASN:                                         7.90
ARIN Region origin ASes announcing only one prefix:                5653
ARIN Region transit ASes present in the Internet Routing Table:    1557
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          25
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               804495360
    Equivalent to 47 /8s, 243 /16s and 160 /24s
    Percentage of available ARIN address space announced:          63.9

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, 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, 173/8,
                       174/8, 184/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:                     89839
    Total RIPE prefixes after maximum aggregation:                50430
    RIPE Deaggregation factor:                                     1.78
Prefixes being announced from the RIPE address blocks:            82551
    Unique aggregates announced from the RIPE address blocks:     54098
RIPE Region origin ASes present in the Internet Routing Table:    16005
    RIPE Prefixes per ASN:                                         5.16
RIPE Region origin ASes announcing only one prefix:                7962
RIPE Region transit ASes present in the Internet Routing Table:    2506
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1032
Number of RIPE addresses announced to Internet:               490070912
    Equivalent to 29 /8s, 53 /16s and 227 /24s
    Percentage of available RIPE address space announced:          78.9

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
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,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   35011
    Total LACNIC prefixes after maximum aggregation:               7797
    LACNIC Deaggregation factor:                                   4.49
Prefixes being announced from the LACNIC address blocks:          34336
    Unique aggregates announced from the LACNIC address blocks:   18003
LACNIC Region origin ASes present in the Internet Routing Table:   1530
    LACNIC Prefixes per ASN:                                      22.44
LACNIC Region origin ASes announcing only one prefix:               449
LACNIC Region transit ASes present in the Internet Routing Table:   279
Average LACNIC Region AS path length visible:                       4.5
    Max LACNIC Region AS path length visible:                        19
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   322
Number of LACNIC addresses announced to Internet:              89805184
    Equivalent to 5 /8s, 90 /16s and 81 /24s
    Percentage of available LACNIC address space announced:        59.5

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8547
    Total AfriNIC prefixes after maximum aggregation:              2002
    AfriNIC Deaggregation factor:                                  4.27
Prefixes being announced from the AfriNIC address blocks:          6606
    Unique aggregates announced from the AfriNIC address blocks:   1963
AfriNIC Region origin ASes present in the Internet Routing Table:   488
    AfriNIC Prefixes per ASN:                                     13.54
AfriNIC Region origin ASes announcing only one prefix:              153
AfriNIC Region transit ASes present in the Internet Routing Table:  103
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             27644160
    Equivalent to 1 /8s, 165 /16s and 209 /24s
    Percentage of available AfriNIC address space announced:       41.2

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2509      11048         962   Korea Telecom (KIX)
17974     1986        519          33   PT TELEKOMUNIKASI INDONESIA
 7545     1607        303          86   TPG Internet Pty Ltd
 4755     1546        638         176   TATA Communications formerly 
24560     1184        346         195   Bharti Airtel Ltd., Telemedia
 9829     1158        989          28   BSNL National Internet Backbo
 7552     1105       1064           7   Vietel Corporation
 9583     1086         80         502   Sify Limited
 4808     1074       2096         303   CNCGROUP IP network: China169
18101      952        165         142   Reliance Infocom Ltd Internet

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     3557       3817         225   bellsouth.net, inc. 
18566     1915        366         239   Covad Communications 
 1785     1829        680         124   PaeTec Communications, Inc.
 7029     1720       1008         194   Windstream Communications Inc
 4323     1625       1082         391   Time Warner Telecom
20115     1595       1542         635   Charter Communications 
22773     1456       2907         100   Cox Communications, Inc.
19262     1395       4728         400   Verizon Global Networks 
30036     1390        252         666   Mediacom Communications Corp 
 7018     1338       7051         874   AT&T WorldNet Services

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

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1224        352          13   Corbina telecom
34984      577        108         180   BILISIM TELEKOM
 6830      557       1873         333   UPC Distribution Services
20940      530        178         408   Akamai Technologies European 
 3320      501       8169         383   Deutsche Telekom AG
 3292      479       2082         408   TDC Tele Danmark
12479      474        593           7   Uni2 Autonomous System
 8866      459        133          26   Bulgarian Telecommunication C
29049      423         31          55   AzerSat LLC.
 8551      404        354          44   Bezeq International

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

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1681        310         155   TVCABLE BOGOTA 
 8151     1410       2823         344   UniNet S.A. de C.V. 
28573     1368       1013          70   NET Servicos de Comunicao S.A
 7303     1164        683         175   Telecom Argentina Stet-France
14420      742         58          87   CORPORACION NACIONAL DE TELEC
22047      581        322          17   VTR PUNTO NET S.A. 
 6503      577        450          69   AVANTEL, S.A. 
27947      573         71          83   Telconet S.A
 3816      536        232          98   Empresa Nacional de Telecomun
11172      521         85          93   Servicios Alestra S.A de C.V 

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

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863      813        147          37   LINKdotNET AS number
 8452      663        445          11   TEDATA
15475      449         74           8   Nile Online
36992      293        415          14   Etisalat MISR
 3741      278        939         231   The Internet Solution 
15706      244         32           6   Sudatel Internet Exchange Aut
 6713      242        519          14   Itissalat Al-MAGHRIB
33776      239         13           8   Starcomms Nigeria Limited
12258      198         28          58   Vodacom Internet Company 
29571      192         17          11   Ci Telecom Autonomous system 

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
 6389     3557       3817         225   bellsouth.net, inc. 
 4766     2509      11048         962   Korea Telecom (KIX)
17974     1986        519          33   PT TELEKOMUNIKASI INDONESIA
18566     1915        366         239   Covad Communications 
 1785     1829        680         124   PaeTec Communications, Inc.
 7029     1720       1008         194   Windstream Communications Inc
10620     1681        310         155   TVCABLE BOGOTA 
 4323     1625       1082         391   Time Warner Telecom
 7545     1607        303          86   TPG Internet Pty Ltd
20115     1595       1542         635   Charter Communications 

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

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

  ASN   No of nets  Net Savings Description
17974      1986        1953      PT TELEKOMUNIKASI INDONESIA
 1785      1829        1705      PaeTec Communications, Inc.
18566      1915        1676      Covad Communications 
 4766      2509        1547      Korea Telecom (KIX)
 7029      1720        1526      Windstream Communications Inc
10620      1681        1526      TVCABLE BOGOTA 
 7545      1607        1521      TPG Internet Pty Ltd
 4755      1546        1370      TATA Communications formerly 
22773      1456        1356      Cox Communications, Inc.
28573      1368        1298      NET Servicos de Comunicao S.A

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
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
26973   UNALLOCATED  12.39.152.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.154.0/23        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.155.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.159.0/24        7018       AT&T WorldNet Servic
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic

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

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

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
41.222.79.0/24       36938     >>UNKNOWN<<
41.223.92.0/22       36936     >>UNKNOWN<<
62.61.220.0/24       24974     Tachyon Europe BV - Wireless 
62.61.221.0/24       24974     Tachyon Europe BV - Wireless 

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:19       /9:12      /10:27      /11:81      /12:235     
/13:463     /14:802     /15:1420    /16:11981   /17:5988    /18:10044   
/19:19827   /20:26999   /21:27144   /22:36733   /23:34891   /24:194773  
/25:1132    /26:1345    /27:752     /28:171     /29:4       /30:0       
/31:0       /32:5       

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

  ASN   No of nets  Total ann.   Description
 6389     2194          3557      bellsouth.net, inc. 
18566     1870          1915      Covad Communications 
10620     1576          1681      TVCABLE BOGOTA 
 7029     1417          1720      Windstream Communications Inc
30036     1351          1390      Mediacom Communications Corp 
 8402     1185          1224      Corbina telecom
11492     1115          1153      Cable One 
 1785     1054          1829      PaeTec Communications, Inc.
 7011     1052          1173      Citizens Utilities 
22773      945          1456      Cox Communications, Inc.

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

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

   1:381       2:393       4:15        5:1         6:3         8:353    
  12:1956     13:1        14:532      15:13       16:3        17:7      
  20:10       23:36       24:1688     27:959      31:564      32:65     
  33:4        34:2        36:4        38:746      40:108      41:2639   
  42:48       44:3        46:993      47:3        49:263      50:432    
  52:13       55:3        56:2        57:38       58:879      59:492    
  60:365      61:1178     62:1089     63:1935     64:4052     65:2306   
  66:3979     67:1952     68:1102     69:3194     70:814      71:377    
  72:1849     74:2458     75:350      76:341      77:883      78:829    
  79:480      80:1122     81:835      82:503      83:501      84:622    
  85:1118     86:408      87:876      88:352      89:1591     90:268    
  91:4143     92:535      93:1339     94:1318     95:964      96:440    
  97:277      98:905      99:37      101:209     103:331     106:70     
 107:56      108:47      109:1034    110:663     111:796     112:322    
 113:449     114:569     115:681     116:870     117:689     118:866    
 119:1208    120:334     121:678     122:1605    123:1013    124:1353   
 125:1393    128:244     129:178     130:163     131:580     132:112    
 133:21      134:214     135:54      136:213     137:139     138:288    
 139:122     140:494     141:292     142:388     143:416     144:482    
 145:63      146:471     147:215     148:641     149:264     150:155    
 151:193     152:446     153:177     154:6       155:385     156:207    
 157:361     158:150     159:465     160:322     161:206     162:336    
 163:178     164:511     165:374     166:536     167:432     168:739    
 169:147     170:865     171:85      172:1       173:1641    174:648    
 175:417     176:246     177:291     178:1031    180:1090    181:37     
 182:627     183:215     184:355     185:1       186:1493    187:676    
 188:923     189:826     190:5177    192:5916    193:5011    194:3528   
 195:3078    196:1257    197:174     198:3626    199:4140    200:5520   
 201:1641    202:8580    203:8492    204:4258    205:2357    206:2676   
 207:2824    208:4041    209:3464    210:2696    211:1463    212:2044   
 213:1776    214:785     215:90      216:4897    217:1594    218:561    
 219:338     220:1227    221:514     222:342     223:263    

End of report


From bmanning at vacation.karoshi.com  Fri Sep 30 14:53:46 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 30 Sep 2011 19:53:46 +0000
Subject: FCC - with Klezmer backup
Message-ID: <20110930195346.GD1468@vacation.karoshi.com.>


http://gcn.com/articles/2011/09/26/fcc-net-neutrality-rules-nov-20.aspx

wondering who is going to publically announce any changes prior to the 20nov date.

Or is this a non-issue for the Internet as we know it?  

/bill


From nick at flhsi.com  Fri Sep 30 15:04:37 2011
From: nick at flhsi.com (Nick Olsen)
Date: Fri, 30 Sep 2011 16:04:37 -0400
Subject: Synology Disk DS211J
Message-ID: <5449bd8$62a59bb7$407cb47$@com>

It's updates, I've got a 1511+ here and at the office. It phones home to 
check for updates. I noticed this the day I got it. Blocked the dst IP and 
that was the only thing that "broke".


Nick Olsen

Network Operations
(855) FLSPEED  x106

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

From: "Pierre-Yves Maunier" <nanog at maunier.org>

Sent: Friday, September 30, 2011 8:32 AM

To: "Jones, Barry" <BEJones at semprautilities.com>

Subject: Re: Synology Disk DS211J


2011/9/29 Jones, Barry <BEJones at semprautilities.com>


> Hey all.

> A little off topic, but wanted to share... I purchased a home storage

> Synology DS1511+. After configuring it on the home net, I did some 
captures

> to look at the protocols, and noticed that the DS1511+ is making 
outgoing

> connections to 59.124.41.242 (www) and 59.124.41.245 (port 81 & 89) on a

> regular basis. These addresses are owned by Synology and Chungwa Telecom 
in

> Taiwan.

>

> So far, I've not been able to find much information on their support 
sites,

> or Synology's wiki, but I wanted to put it out there.

>

>

>

Maybe it's for checking new firmware update availability...


-- 

Pierre-Yves Maunier


From bonomi at mail.r-bonomi.com  Fri Sep 30 15:13:50 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Fri, 30 Sep 2011 15:13:50 -0500 (CDT)
Subject: FCC - with Klezmer backup
In-Reply-To: <20110930195346.GD1468@vacation.karoshi.com.>
Message-ID: <201109302013.p8UKDoI8069423@mail.r-bonomi.com>


> Date: Fri, 30 Sep 2011 19:53:46 +0000
> From: bmanning at vacation.karoshi.com
> To: nanog at nanog.org
> Subject: FCC - with Klezmer backup
>
>
> http://gcn.com/articles/2011/09/26/fcc-net-neutrality-rules-nov-20.aspx
>
> wondering who is going to publically announce any changes prior to the 
> 20nov date.
>
> Or is this a non-issue for the Internet as we know it?

I suspect that anyone that was doing it hadn't made any noise about 
_doing_ it, so they're unlikely to announce that they've _stopped_ do
ing so.  All such an announcement would accomplish is to 'confirm
suspicions', which is (obviously) not to that provider's advantage.




From frnkblk at iname.com  Fri Sep 30 15:22:48 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Fri, 30 Sep 2011 15:22:48 -0500
Subject: Environmental monitoring options
In-Reply-To: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
References: <CALn8JwN8nfweip4QOo-H25Gt6rF0F4SiSJsgX=PV8OjJ474HkQ@mail.gmail.com>
Message-ID: <001501cc7fae$b8de8690$2a9b93b0$@iname.com>

There's also DPS Telecom (http://www.dpstele.com).

Frank

-----Original Message-----
From: eric clark [mailto:cabenth at gmail.com] 
Sent: Tuesday, September 27, 2011 9:06 AM
To: NANOG list
Subject: Environmental monitoring options

I'd like to ask the list what products people are using to monitor their
environments. By this I'm referring to datacenters, and other equipment.
Temperature, humidity, airflow, cameras, dry contacts, door sensors, leak
detection, all that sort of thing.

I've used Netbotz in the past. Looking to see what else is out there that
people like.

Thanks

E



From bmanning at vacation.karoshi.com  Fri Sep 30 15:24:09 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 30 Sep 2011 20:24:09 +0000
Subject: FCC - with Klezmer backup
In-Reply-To: <201109302013.p8UKDoI8069423@mail.r-bonomi.com>
References: <20110930195346.GD1468@vacation.karoshi.com.>
 <201109302013.p8UKDoI8069423@mail.r-bonomi.com>
Message-ID: <20110930202409.GA2622@vacation.karoshi.com.>

On Fri, Sep 30, 2011 at 03:13:50PM -0500, Robert Bonomi wrote:
> 
> > Date: Fri, 30 Sep 2011 19:53:46 +0000
> > From: bmanning at vacation.karoshi.com
> > To: nanog at nanog.org
> > Subject: FCC - with Klezmer backup
> >
> >
> > http://gcn.com/articles/2011/09/26/fcc-net-neutrality-rules-nov-20.aspx
> >
> > wondering who is going to publically announce any changes prior to the 
> > 20nov date.
> >
> > Or is this a non-issue for the Internet as we know it?
> 
> I suspect that anyone that was doing it hadn't made any noise about 
> _doing_ it, so they're unlikely to announce that they've _stopped_ do
> ing so.  All such an announcement would accomplish is to 'confirm
> suspicions', which is (obviously) not to that provider's advantage.
> 

	but there -are- reporting requirements now... :)
	and a formal complaint process...

	flash mobs - ready to file complaints about Ameritech?  PacBell?  GTE?

/bill


From charles at knownelement.com  Fri Sep 30 16:22:49 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Fri, 30 Sep 2011 16:22:49 -0500
Subject: FCC - with Klezmer backup
In-Reply-To: <20110930195346.GD1468@vacation.karoshi.com.>
References: <20110930195346.GD1468@vacation.karoshi.com.>
Message-ID: <4E863329.6050905@knownelement.com>

On 09/30/2011 02:53 PM, bmanning at vacation.karoshi.com wrote:
> http://gcn.com/articles/2011/09/26/fcc-net-neutrality-rules-nov-20.aspx
>
> wondering who is going to publically announce any changes prior to the 20nov date.
>
> Or is this a non-issue for the Internet as we know it?  
>
> /bill
>

What does

"commercial terms of their broadband services."

mean?

Peering arrangements? Transit pricing?

-- 
Charles N Wyble charles at knownelement.com @charlesnw on twitter

http://blog.knownelement.com

Building alternative,global scale,secure, cost effective bit moving platform
for tomorrows alternate default free zone.



From Valdis.Kletnieks at vt.edu  Fri Sep 30 16:35:52 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 30 Sep 2011 17:35:52 -0400
Subject: Synology Disk DS211J
In-Reply-To: Your message of "Fri, 30 Sep 2011 04:14:39 -0000."
 <20110930041439.GA11043@vacation.karoshi.com>
References: <201109300046.p8U0k9l9061612@mail.r-bonomi.com>
 <4E852502.9070007@bogus.com>
 <20110930041439.GA11043@vacation.karoshi.com>
Message-ID: <149545.1317418552@turing-police.cc.vt.edu>

On Fri, 30 Sep 2011 04:14:39 -0000, bmanning at vacation.karoshi.com said:

> > Tell me how that flys with the customers in your household...
>
> 	They are freeloaders, not customers.  If they -PAID-
> 	for service, then it would be a different conversation.

Time to cue up "Move it on over" by George Thorogood, 'cause that kind of
talk will leave you sleeping in the doghouse tonight. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110930/19f7b471/attachment.bin>

From bmanning at vacation.karoshi.com  Fri Sep 30 16:41:47 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 30 Sep 2011 21:41:47 +0000
Subject: Synology Disk DS211J
In-Reply-To: <149545.1317418552@turing-police.cc.vt.edu>
References: <201109300046.p8U0k9l9061612@mail.r-bonomi.com>
 <4E852502.9070007@bogus.com> <20110930041439.GA11043@vacation.karoshi.com>
 <149545.1317418552@turing-police.cc.vt.edu>
Message-ID: <20110930214147.GA2826@vacation.karoshi.com.>

On Fri, Sep 30, 2011 at 05:35:52PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 30 Sep 2011 04:14:39 -0000, bmanning at vacation.karoshi.com said:
> 
> > > Tell me how that flys with the customers in your household...
> >
> > 	They are freeloaders, not customers.  If they -PAID-
> > 	for service, then it would be a different conversation.
> 
> Time to cue up "Move it on over" by George Thorogood, 'cause that kind of
> talk will leave you sleeping in the doghouse tonight. ;)

 the doghouse will have net then... :)

/bill


From steve at pirk.com  Fri Sep 30 16:54:38 2011
From: steve at pirk.com (steve pirk [egrep])
Date: Fri, 30 Sep 2011 14:54:38 -0700
Subject: Were A record domain names ever limited to 23 characters?
Message-ID: <CAK4no04rVMZOyqGL0DU-BZpD+j46M+xOGFto4ETw=82LKnowjA@mail.gmail.com>

I seem to recollect back the 1999 or 2000 times that I was unable to
register a domain name that was 24 characters long. Shortly after that, I
heard that the character limit had been increased to like 128 characters,
and we were able to register the name.

Can anyone offer some input, or is this a memory of a bad dream?
;-]

-- Steve Pirk
Yensid

From BEJones at semprautilities.com  Fri Sep 30 16:59:04 2011
From: BEJones at semprautilities.com (Jones, Barry)
Date: Fri, 30 Sep 2011 14:59:04 -0700
Subject: facebook spying on us?
In-Reply-To: <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
Message-ID: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A62@MS-EX7MB-P03.corp.se.sempra.com>

I can't tell you the kind of servers, but I can say that I was recently in Prineville, OR, where FB is building a data center (and a second data center). I was used to the ol data centers - you know, where there's raised floors, cabinets, cool air, a guard and a few guys around with some screens? 

But this was massive. I was amazed at the size - a few city blocks long and a city block wide, with a transformer and power line the size of a small city. I wonder if the Feds were involved. 

http://www.oregonlive.com/business/index.ssf/2010/01/facebook_picks_prineville_for.html


"I also wonder about the kind of servers facebook must be having to be 
> able to manage millions of TCP connections that must be terminating 
> there."


-----Original Message-----
From: Keegan Holley [mailto:keegan.holley at sungard.com] 
Sent: Thursday, September 29, 2011 7:55 AM
To: Glen Kent
Cc: nanog at nanog.org
Subject: Re: facebook spying on us?

Well what's making the connection?  It looks like unencrypted http, if your social security number and last known addresses are streaming by you should be able to see them.  It's a bit of a jump to say that FB (not that I'm particularly fond of them) is spying on you from a single netstat command.
You probably clicked login with facebook for some site and it's just autologging you in or overzealous prefetching.  Either way, I think we can all stop making tinfoil hats now...


2011/9/29 Glen Kent <glen.kent at gmail.com>

> Hi,
>
> I see that i have multiple TCP sessions established with facebook.
> They come up even after i reboot my laptop and dont login to facebook!
>
> D:\Documents and Settings\gkent>netstat -a | more
>
> Active Connections
>
>  Proto  Local Address          Foreign Address        State
>  TCP    gkent:3974    www-10-02-snc5.facebook.com:http  ESTABLISHED
>  TCP    gkent:3977    www-11-05-prn1.facebook.com:http  ESTABLISHED
>  TCP    gkent:3665
> a184-84-111-139.deploy.akamaitechnologies.com:http  ESTABLISHED
>
> [clipped]
>
> Any idea why these connections are established (with facebook and
> akamaitechnologies) and how i can kill them? Since my laptop has 
> several connections open with facebook, what kind of information is 
> flowing there?
>
> I also wonder about the kind of servers facebook must be having to be 
> able to manage millions of TCP connections that must be terminating 
> there.
>
> Glen
>
>
>


From cidr-report at potaroo.net  Fri Sep 30 17:00:01 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 30 Sep 2011 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201109302200.p8UM01GJ093560@wattle.apnic.net>

BGP Update Report
Interval: 22-Sep-11 -to- 29-Sep-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            44536  2.8%      61.9 -- BSNL-NIB National Internet Backbone
 2 - AS5800            36718  2.3%     180.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 3 - AS38040           29537  1.9%    2109.8 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 4 - AS6316            29336  1.9%    1466.8 -- AS-PAETEC-NET - PaeTec Communications, Inc.
 5 - AS32528           23323  1.5%    7774.3 -- ABBOTT Abbot Labs
 6 - AS9246            21941  1.4%    2742.6 -- GTA-AP Teleguam Holdings, LLC
 7 - AS9498            20692  1.3%      25.0 -- BBIL-AP BHARTI Airtel Ltd.
 8 - AS16916           16874  1.1%    3374.8 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
 9 - AS16010           15785  1.0%     129.4 -- RUSTAVI2ONLINEAS Caucasus Online LLC
10 - AS50975           14852  0.9%    7426.0 -- AVX_AS AVX Czech republic s.r.o
11 - AS8866            14004  0.9%      30.0 -- BTC-AS Bulgarian Telecommunication Company Plc.
12 - AS9475            13406  0.8%     957.6 -- WU-TH-AP Walailuk University
13 - AS17974           13239  0.8%       8.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
14 - AS8402            12985  0.8%      12.8 -- CORBINA-AS OJSC "Vimpelcom"
15 - AS8151            12023  0.8%      12.3 -- Uninet S.A. de C.V.
16 - AS7552            11853  0.8%       8.5 -- VIETEL-AS-AP Vietel Corporation
17 - AS9808            11389  0.7%      17.1 -- CMNET-GD Guangdong Mobile Communication Co.Ltd.
18 - AS9562             9980  0.6%    2495.0 -- MSU-TH-AP Mahasarakham University
19 - AS9649             9765  0.6%     184.2 -- MOPH-TH-AP Information Technology Office
20 - AS22793            9582  0.6%    9582.0 -- CASSOCORP - CASSO Corporation


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS22793            9582  0.6%    9582.0 -- CASSOCORP - CASSO Corporation
 2 - AS32528           23323  1.5%    7774.3 -- ABBOTT Abbot Labs
 3 - AS50975           14852  0.9%    7426.0 -- AVX_AS AVX Czech republic s.r.o
 4 - AS8499             4650  0.3%    4650.0 -- Space Hellas S.A.
 5 - AS16916           16874  1.1%    3374.8 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
 6 - AS9246            21941  1.4%    2742.6 -- GTA-AP Teleguam Holdings, LLC
 7 - AS9562             9980  0.6%    2495.0 -- MSU-TH-AP Mahasarakham University
 8 - AS3976             2391  0.1%    2391.0 -- ERX-NURI-ASN I.Net Technologies Inc.
 9 - AS38040           29537  1.9%    2109.8 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
10 - AS20098            2067  0.1%    2067.0 -- BCBS-AL - Blue Cross Blue Shield of Alabama
11 - AS8011             3426  0.2%    1713.0 -- AS8011 - CoreComm Internet Services Inc
12 - AS6316            29336  1.9%    1466.8 -- AS-PAETEC-NET - PaeTec Communications, Inc.
13 - AS17425            7550  0.5%    1258.3 -- EPA-AS-TH Provincial Electricity Authority of Thailand.
14 - AS44025            1218  0.1%    1218.0 -- KAMTELEKOM-NET Kamtelekom Ltd.
15 - AS17408            3304  0.2%    1101.3 -- ABOVE-AS-AP AboveNet Communications Taiwan
16 - AS9475            13406  0.8%     957.6 -- WU-TH-AP Walailuk University
17 - AS56772             920  0.1%     920.0 -- UFMOLDOVA-AS I.C.S. "RED UNION FENOSA" S.A.
18 - AS3                1787  0.1%     288.0 -- CICA Centro Informatico Cientifico de Andalucia
19 - AS3                 593  0.0%     597.0 -- CICA Centro Informatico Cientifico de Andalucia
20 - AS38543            2260  0.1%     565.0 -- IBM-TH-AS-AP IBM THAILAND NETWORK


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 206.80.93.0/24    16867  1.0%   AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
 2 - 202.92.235.0/24   14393  0.8%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 3 - 213.16.48.0/24    11975  0.7%   AS8866  -- BTC-AS Bulgarian Telecommunication Company Plc.
 4 - 130.36.34.0/24    11657  0.7%   AS32528 -- ABBOTT Abbot Labs
 5 - 130.36.35.0/24    11657  0.7%   AS32528 -- ABBOTT Abbot Labs
 6 - 66.248.120.0/21   10574  0.6%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 7 - 66.248.96.0/21     9639  0.6%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 8 - 207.53.145.0/24    9582  0.6%   AS22793 -- CASSOCORP - CASSO Corporation
 9 - 66.248.104.0/21    9064  0.5%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
10 - 109.75.0.0/21      8228  0.5%   AS50975 -- AVX_AS AVX Czech republic s.r.o
11 - 109.75.8.0/23      6624  0.4%   AS50975 -- AVX_AS AVX Czech republic s.r.o
12 - 180.180.253.0/24   5869  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
13 - 180.180.250.0/24   5826  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
14 - 180.180.248.0/24   5825  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
15 - 145.36.122.0/24    5630  0.3%   AS7046  -- RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business
16 - 180.180.249.0/24   4962  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
17 - 202.41.70.0/24     4828  0.3%   AS2697  -- ERX-ERNET-AS Education and Research Network
18 - 195.190.32.0/19    4650  0.3%   AS8499  -- Space Hellas S.A.
19 - 180.180.255.0/24   4417  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
20 - 200.23.202.0/24    3766  0.2%   AS3454  -- Universidad Autonoma de Nuevo Leon

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 cidr-report at potaroo.net  Fri Sep 30 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 30 Sep 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201109302200.p8UM00P3093555@wattle.apnic.net>

This report has been generated at Fri Sep 30 21:12:35 2011 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
        23-09-11    377111      221388
        24-09-11    377558      221596
        25-09-11    377652      221708
        26-09-11    377754      222001
        27-09-11    377784      221985
        28-09-11    378019      221838
        29-09-11    378145      221391
        30-09-11    377480      221774


AS Summary
         39016  Number of ASes in routing system
         16481  Number of ASes announcing only one prefix
          3556  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      108295136  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').

 --- 30Sep11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     377614   221830   155784    41.3%   All ASes

AS6389      3556      228     3328    93.6%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS18566     1915      380     1535    80.2%   COVAD - Covad Communications
                                               Co.
AS4766      2509      979     1530    61.0%   KIXS-AS-KR Korea Telecom
AS22773     1457      110     1347    92.5%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1543      231     1312    85.0%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS4323      1629      394     1235    75.8%   TWTC - tw telecom holdings,
                                               inc.
AS28573     1368      319     1049    76.7%   NET Servicos de Comunicao S.A.
AS1785      1832      784     1048    57.2%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS19262     1395      401      994    71.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS7552      1392      430      962    69.1%   VIETEL-AS-AP Vietel
                                               Corporation
AS7303      1164      321      843    72.4%   Telecom Argentina S.A.
AS10620     1681      843      838    49.9%   Telmex Colombia S.A.
AS18101      954      155      799    83.8%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS24560     1173      391      782    66.7%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS8151      1415      649      766    54.1%   Uninet S.A. de C.V.
AS4808      1074      335      739    68.8%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS30036     1390      671      719    51.7%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS7545      1607      895      712    44.3%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1104      450      654    59.2%   LEVEL3 Level 3 Communications
AS14420      742       91      651    87.7%   CORPORACION NACIONAL DE
                                               TELECOMUNICACIONES - CNT EP
AS3549      1055      448      607    57.5%   GBLX Global Crossing Ltd.
AS20115     1595      988      607    38.1%   CHARTER-NET-HKY-NC - Charter
                                               Communications
AS22561      967      363      604    62.5%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS17676      673       70      603    89.6%   GIGAINFRA Softbank BB Corp.
AS4804       677       89      588    86.9%   MPX-AS Microplex PTY LTD
AS17974     1983     1414      569    28.7%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS22047      581       28      553    95.2%   VTR BANDA ANCHA S.A.
AS8402      1186      637      549    46.3%   CORBINA-AS OJSC "Vimpelcom"
AS7011      1173      647      526    44.8%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.
AS17488      908      390      518    57.0%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet

Total      41698    14131    27567    66.1%   Top 30 total


Possible Bogus Routes

        5.0.0.0/16           AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        5.1.0.0/21           AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        5.1.24.0/24          AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        80.88.10.0/24        AS33774 DJAWEB
        89.145.168.0/21      AS3257  TINET-BACKBONE Tinet SpA
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        185.0.0.0/16         AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        185.1.0.0/21         AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        185.24.0.0/24        AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        188.32.0.0/16        AS42610 NCNET-AS National Cable Networks
        190.102.32.0/20      AS30058 FDCSERVERS - FDCservers.net
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.111.87.0/24      AS24812 
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.9.57.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        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.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.72.192.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.72.194.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        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.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.58.200.0/24      AS18530 ISOMEDIA-1 - Isomedia Inc.
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        223.130.17.0/24      AS45500 BGEPTYLTD-AS-AP BG&E Pty Limited


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 bmanning at vacation.karoshi.com  Fri Sep 30 17:00:36 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 30 Sep 2011 22:00:36 +0000
Subject: Were A record domain names ever limited to 23 characters?
In-Reply-To: <CAK4no04rVMZOyqGL0DU-BZpD+j46M+xOGFto4ETw=82LKnowjA@mail.gmail.com>
References: <CAK4no04rVMZOyqGL0DU-BZpD+j46M+xOGFto4ETw=82LKnowjA@mail.gmail.com>
Message-ID: <20110930220036.GB2826@vacation.karoshi.com.>

On Fri, Sep 30, 2011 at 02:54:38PM -0700, steve pirk [egrep] wrote:
> I seem to recollect back the 1999 or 2000 times that I was unable to
> register a domain name that was 24 characters long. Shortly after that, I
> heard that the character limit had been increased to like 128 characters,
> and we were able to register the name.
> 
> Can anyone offer some input, or is this a memory of a bad dream?
> ;-]
> 
> -- Steve Pirk
> Yensid

the foundational DNS spec sez:


http://www.ietf.org/rfc/rfc1035.txt

2.3.1
[elided]
There are also some restrictions on the length.  Labels must be 63 characters or less.

/bill


From joelja at bogus.com  Fri Sep 30 17:12:54 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Fri, 30 Sep 2011 15:12:54 -0700
Subject: facebook spying on us?
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A62@MS-EX7MB-P03.corp.se.sempra.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A62@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <4E863EE6.9000207@bogus.com>

On 9/30/11 14:59 , Jones, Barry wrote:
> I can't tell you the kind of servers, but I can say that I was
> recently in Prineville, OR, where FB is building a data center (and a
> second data center). I was used to the ol data centers - you know,
> where there's raised floors, cabinets, cool air, a guard and a few
> guys around with some screens?
> 
> But this was massive. I was amazed at the size - a few city blocks
> long and a city block wide, with a transformer and power line the
> size of a small city. I wonder if the Feds were involved.

the bonneville power administration.



From sghuter at nsrc.org  Fri Sep 30 17:19:36 2011
From: sghuter at nsrc.org (Steven G. Huter)
Date: Fri, 30 Sep 2011 15:19:36 -0700 (PDT)
Subject: facebook spying on us?
In-Reply-To: <4E863EE6.9000207@bogus.com>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A62@MS-EX7MB-P03.corp.se.sempra.com>
 <4E863EE6.9000207@bogus.com>
Message-ID: <alpine.DEB.2.00.1109301515520.13780@nsrc.org>

>> I can't tell you the kind of servers, but I can say that I was
>> recently in Prineville, OR, where FB is building a data center (and a
>> second data center). I was used to the ol data centers - you know,
>> where there's raised floors, cabinets, cool air, a guard and a few
>> guys around with some screens?
>>
>> But this was massive. I was amazed at the size - a few city blocks
>> long and a city block wide, with a transformer and power line the
>> size of a small city. I wonder if the Feds were involved.
>
> the bonneville power administration.

hey joelja

this August 2011 article in the Economist outlines some relevant info
about the prineville, oregon FB datacenter.

http://www.economist.com/node/21525237

steve



From steve at pirk.com  Fri Sep 30 17:20:36 2011
From: steve at pirk.com (steve pirk [egrep])
Date: Fri, 30 Sep 2011 15:20:36 -0700
Subject: Were A record domain names ever limited to 23 characters?
In-Reply-To: <4e863c0b.07e6640a.0a87.ffffe4e2SMTPIN_ADDED@mx.google.com>
References: <CAK4no04rVMZOyqGL0DU-BZpD+j46M+xOGFto4ETw=82LKnowjA@mail.gmail.com>
 <4e863c0b.07e6640a.0a87.ffffe4e2SMTPIN_ADDED@mx.google.com>
Message-ID: <CAK4no06MKrLrp0p7_x4fu9HFcTQ4gFv+PdUJpEOXjfjC-RyrYA@mail.gmail.com>

Found a decent starting reference. It was a Network solutions limit... I
*knew* it! LOL
http://www.123-domain-register.com/longdomainnames.htm

The domain in question was inspectorgadgetthemovie.com 27 characters long
including the .tld. I was off by one, the limit was 22 characters for the A
record name and 4 characters for .com, .net, .org, .gov and .edu.

>From the 123-domain-register web page:

> The word is out... and the experts have been taking advantage of a change
> in Domain Name regulations that allows up to 67 characters in domain names.
>
> How this will impact you:
>
>    -
>
>    Long domain names filled with keywords can get you ranked higher on the
>    search engines. (yes, the search engines will rank them)
>
>    -
>
>    For those who could not get a DOT.COM domain name, or were limited by
>    the 22 character limit, those days are over...for awhile anyway.
>
>    -
>
>    This revolution is driven by entrepreneurs who can act quickly. If you
>    do not act soon, all the good domains will be gone, and you will have to pay
>    premiums you do not want to in order get the domain name you want.
>
> Since 1993, Network Solutions has registered more than 3.4 million domain
> names -- all limited to 26 characters. Now that their exclusive government
> contract is ending, competitors have tossed this artificial limit and are
> allowing longer names.
>
Cool, I was not dreaming... ;-]
--steve

On Fri, Sep 30, 2011 at 15:00, <bmanning at vacation.karoshi.com> wrote:

> On Fri, Sep 30, 2011 at 02:54:38PM -0700, steve pirk [egrep] wrote:
> > I seem to recollect back the 1999 or 2000 times that I was unable to
> > register a domain name that was 24 characters long. Shortly after that, I
> > heard that the character limit had been increased to like 128 characters,
> > and we were able to register the name.
> >
> > Can anyone offer some input, or is this a memory of a bad dream?
> > ;-]
> >
> > -- Steve Pirk
> > Yensid
>
> the foundational DNS spec sez:
>
>
> http://www.ietf.org/rfc/rfc1035.txt
>
> 2.3.1
> [elided]
> There are also some restrictions on the length.  Labels must be 63
> characters or less.
>
> /bill
>



-- 
steve pirk
refiamerica.org
"father... the sleeper has awakened..." paul atreides - dune
kexp.org member august '09

From brandon.kim at brandontek.com  Fri Sep 30 17:24:10 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Fri, 30 Sep 2011 18:24:10 -0400
Subject: events
In-Reply-To: <C73D04D0-8FA2-4B69-95D9-9017ED0ED446@lixfeld.ca>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>, ,
 <CAMvhC_44gr4rS026fLDYZ1=KZHCs83gG-LQ6PTR-M44U5HamHQ@mail.gmail.com>, ,
 <BLU158-W6487104EECF26B798950DADCF70@phx.gbl>, ,
 <CAHDg04sNcKMBf8+sxw3ZRVkhRFwKQU8vLvLTSJxXY+THL2wGBA@mail.gmail.com>,
 <BLU158-W116567FE383FF900DF0ACDDCF70@phx.gbl>,
 <C73D04D0-8FA2-4B69-95D9-9017ED0ED446@lixfeld.ca>
Message-ID: <BLU158-W51526AC4FB773DAD41D9A9DCF70@phx.gbl>


Good question, we do not use manageengine for NMS and I have no desire to use them either.
I tried their NMS platform last year and it was "ok", the interface just seemed a little clunky....

Setting up ManageEngine syslog was a breeze and now we get alerts based on what kind of messages
we want, it's pretty hands off, I'm sure you could fine tune it further...

But I hear that solarwinds NPM has syslog built into it, so I'm thinking of going with one product that covers
it all....



> Subject: Re: events
> From: jason at lixfeld.ca
> Date: Fri, 30 Sep 2011 14:21:38 -0400
> To: nanog at nanog.org
> 
> On 2011-09-30, at 2:13 PM, Brandon Kim wrote:
> 
> > I've been happy with my basic ManageEngine's syslog, but I may be looking at Solarwinds too...
> 
> I've just installed the Splunk eval myself, but I'm curious about your ManageEngine experiences.  I don't have any interest in using ManageEngine as an NMS; I have a couple of tools that I use for that already.  Can you use ManageEngine's syslog without having to set it up to monitor all of your devices first?  Have you looked at the TRAP support in ManageEngine?
 		 	   		  

From tvhawaii at shaka.com  Fri Sep 30 17:41:00 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Fri, 30 Sep 2011 12:41:00 -1000
Subject: facebook spying on us?
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A62@MS-EX7MB-P03.corp.se.sempra.com>
 <4E863EE6.9000207@bogus.com> <alpine.DEB.2.00.1109301515520.13780@nsrc.org>
Message-ID: <A6B4520BA1B94065B3E3F285B304A4F1@owner59e1f1502>

Steven G. Huter wrote:
> this August 2011 article in the Economist outlines some relevant info
> about the prineville, oregon FB datacenter.
>
> http://www.economist.com/node/21525237
>
> steve

Informative article..."It's the climate, stupid".

Got a laugh out of:
"The server racks are nearly silent, and their internal fans whirr almost imperceptibly.
The only exceptions are network switches which, Facebook staff notes, are perversely designed by even the biggest firms to 
vent air out of their sides. As a result, they run loud and hot-and are openly sworn at." 



From joelja at bogus.com  Fri Sep 30 17:48:50 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Fri, 30 Sep 2011 15:48:50 -0700
Subject: facebook spying on us?
In-Reply-To: <alpine.DEB.2.00.1109301515520.13780@nsrc.org>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A62@MS-EX7MB-P03.corp.se.sempra.com>
 <4E863EE6.9000207@bogus.com> <alpine.DEB.2.00.1109301515520.13780@nsrc.org>
Message-ID: <4E864752.2030105@bogus.com>

On 9/30/11 15:19 , Steven G. Huter wrote:
>>> I can't tell you the kind of servers, but I can say that I was
>>> recently in Prineville, OR, where FB is building a data center (and a
>>> second data center). I was used to the ol data centers - you know,
>>> where there's raised floors, cabinets, cool air, a guard and a few
>>> guys around with some screens?
>>>
>>> But this was massive. I was amazed at the size - a few city blocks
>>> long and a city block wide, with a transformer and power line the
>>> size of a small city. I wonder if the Feds were involved.
>>
>> the bonneville power administration.
> 
> hey joelja
> 
> this August 2011 article in the Economist outlines some relevant info
> about the prineville, oregon FB datacenter.
> 
> http://www.economist.com/node/21525237

ambient cooling is important just like power is important, by sonic.net
gets ~240days of ambient in santa rosa so it's feasible

wholesale market prices a driven by availability from the largest
producer. so you'll pay market price as benchmarked at the bonnevilla
transmission yard just as is much of california and az the refence price
is at palo verde az.

there's only one coal plan in oregon and it's 600MW of generating
capacity in boardman that's portland general electric.

we've got a 20MW interuptable contract with siliconvalley power
precisely becuase it's vanishingly close to the wholesale rate compared
to PGEs pricing structure so if you ever wonder why the DCs are in
sunnyvale and santa clara but not mountainview, there's a good reason.

> steve
> 



From sethm at rollernet.us  Fri Sep 30 17:58:19 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 30 Sep 2011 15:58:19 -0700
Subject: facebook spying on us?
In-Reply-To: <A6B4520BA1B94065B3E3F285B304A4F1@owner59e1f1502>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A62@MS-EX7MB-P03.corp.se.sempra.com>
 <4E863EE6.9000207@bogus.com> <alpine.DEB.2.00.1109301515520.13780@nsrc.org>
 <A6B4520BA1B94065B3E3F285B304A4F1@owner59e1f1502>
Message-ID: <4E86498B.9070109@rollernet.us>

On 9/30/11 3:41 PM, Michael Painter wrote:
> Steven G. Huter wrote:
>> this August 2011 article in the Economist outlines some relevant info
>> about the prineville, oregon FB datacenter.
>>
>> http://www.economist.com/node/21525237
>>
>> steve
> 
> Informative article..."It's the climate, stupid".
> 
> Got a laugh out of:
> "The server racks are nearly silent, and their internal fans whirr
> almost imperceptibly.
> The only exceptions are network switches which, Facebook staff notes,
> are perversely designed by even the biggest firms to vent air out of
> their sides. As a result, they run loud and hot-and are openly sworn at."
> 


Which says to me that FB staff has no clue how chassis switches are
constructed, or they don't like switches with vertically oriented line
cards.

~Seth


From callahanwarlick at gmail.com  Fri Sep 30 18:05:37 2011
From: callahanwarlick at gmail.com (Callahan Warlick)
Date: Fri, 30 Sep 2011 16:05:37 -0700
Subject: facebook spying on us?
In-Reply-To: <4E86498B.9070109@rollernet.us>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A62@MS-EX7MB-P03.corp.se.sempra.com>
 <4E863EE6.9000207@bogus.com>
 <alpine.DEB.2.00.1109301515520.13780@nsrc.org>
 <A6B4520BA1B94065B3E3F285B304A4F1@owner59e1f1502>
 <4E86498B.9070109@rollernet.us>
Message-ID: <CA+6MkbPvERpWkVib9-izpPpXA392uiw0UpB_MSj8H0cy8FDCrw@mail.gmail.com>

It was a relative comparison, and it's off the shelf network gear.

-Callahan

On Fri, Sep 30, 2011 at 3:58 PM, Seth Mattinen <sethm at rollernet.us> wrote:
> On 9/30/11 3:41 PM, Michael Painter wrote:
>> Steven G. Huter wrote:
>>> this August 2011 article in the Economist outlines some relevant info
>>> about the prineville, oregon FB datacenter.
>>>
>>> http://www.economist.com/node/21525237
>>>
>>> steve
>>
>> Informative article..."It's the climate, stupid".
>>
>> Got a laugh out of:
>> "The server racks are nearly silent, and their internal fans whirr
>> almost imperceptibly.
>> The only exceptions are network switches which, Facebook staff notes,
>> are perversely designed by even the biggest firms to vent air out of
>> their sides. As a result, they run loud and hot-and are openly sworn at."
>>
>
>
> Which says to me that FB staff has no clue how chassis switches are
> constructed, or they don't like switches with vertically oriented line
> cards.
>
> ~Seth
>
>


From joelja at bogus.com  Fri Sep 30 18:06:01 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Fri, 30 Sep 2011 16:06:01 -0700
Subject: facebook spying on us?
In-Reply-To: <4E86498B.9070109@rollernet.us>
References: <CAPLq3UOHKF3kSRkcqyjBJpJ3wLoJtrJG2ehqiiz1Mv3Sog8P=Q@mail.gmail.com>
 <CABO8Q6TG3msHQmy8Jzzmzb3y1ut+feGYvA3nYH_NGFQgvqo1qQ@mail.gmail.com>
 <E36EB8E60B5EB244AAFCFEF0AF0A116D02FE359A62@MS-EX7MB-P03.corp.se.sempra.com>
 <4E863EE6.9000207@bogus.com> <alpine.DEB.2.00.1109301515520.13780@nsrc.org>
 <A6B4520BA1B94065B3E3F285B304A4F1@owner59e1f1502>
 <4E86498B.9070109@rollernet.us>
Message-ID: <4E864B59.9070502@bogus.com>

On 9/30/11 15:58 , Seth Mattinen wrote:
> On 9/30/11 3:41 PM, Michael Painter wrote:
>> Steven G. Huter wrote:
>>> this August 2011 article in the Economist outlines some relevant info
>>> about the prineville, oregon FB datacenter.
>>>
>>> http://www.economist.com/node/21525237
>>>
>>> steve
>>
>> Informative article..."It's the climate, stupid".
>>
>> Got a laugh out of:
>> "The server racks are nearly silent, and their internal fans whirr
>> almost imperceptibly.
>> The only exceptions are network switches which, Facebook staff notes,
>> are perversely designed by even the biggest firms to vent air out of
>> their sides. As a result, they run loud and hot-and are openly sworn at."
>>
> 
> 
> Which says to me that FB staff has no clue how chassis switches are
> constructed, or they don't like switches with vertically oriented line
> cards.

nobody puts a chassis switch at the top of a rack...

there are several 1u tors orderable with either ftb or btf airflow but,
it is a design consideration.

> ~Seth
> 



From dave at temk.in  Fri Sep 30 20:08:14 2011
From: dave at temk.in (Dave Temkin)
Date: Fri, 30 Sep 2011 21:08:14 -0400
Subject: Cross posting:  Call for Program Committee candidates for the NANOG PC
Message-ID: <4E8667FE.1040706@temk.in>

All,

If you've ever thought about helping to give back to the community and you regularly attend NANOG 
conferences, please consider running for the NANOG Program Committee.  Committee nominations close on 
10/11/2011, and we need your help!

The seventeen-member NANOG Program Committee solicits talks, works with potential speakers to refine 
presentations, and reviews proposals for technical accuracy and relevance to the NANOG audience.  We need 
people from all walks of life who can help us recruit and vet talks of interest to the broad spectrum of 
NANOG attendees.

More information can be found about how the NANOG community governs itself here:  
http://www.nanog.org/governance/ .

Thanks,
-Dave Temkin


From rdobbins at arbor.net  Fri Sep 30 20:27:09 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sat, 1 Oct 2011 01:27:09 +0000
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
Message-ID: <A123184A-7361-4C7D-9E68-143F11E0894F@arbor.net>

On Sep 30, 2011, at 9:45 PM, Christopher Morrow wrote:

> enough is enough please stop doing this.

Yes, but keep in mind that this particular issue has to do with an ASIC which is several years old and which contains other significant handicaps as well (viz. NetFlow caveats, no per-interface uRPF mode, etc.).

So, complaining about most anything on this particular ASIC isn't going to accomplish much, unfortunately.  The key is to a) evaluate newer ASICs on more operationally useful platforms in order to see how they handle this sort of thing (EARL8 should be fine, AFAICT) and b) put the appropriate requirements into RFCs so that vendors have a monetary value associated with doing the right thing.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From rdobbins at arbor.net  Fri Sep 30 20:32:24 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sat, 1 Oct 2011 01:32:24 +0000
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <CAL9jLaZRzJKDhvw4KwPwzCCSYwyRF4-PUFasp-6pgDUqp69P7g@mail.gmail.com>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
 <4E85DF11.1030905@foobar.org>
 <CAL9jLaa7fNkw_GG9_UemR95v-s=Ae2MLPv-ii6NaGvGvPntopg@mail.gmail.com>
 <4E85F071.80201@foobar.org>
 <CAL9jLaZRzJKDhvw4KwPwzCCSYwyRF4-PUFasp-6pgDUqp69P7g@mail.gmail.com>
Message-ID: <3B77D4F9-F20A-4560-A549-43FB72E1AF68@arbor.net>

On Sep 30, 2011, at 11:44 PM, Christopher Morrow wrote:

> this is exactly why punting anything NOT management and/or routing-protocols should be banned. Thanks for making that point explicitly.

And this is the requirement which should be placed in RFPs, along with other specific requirements for ACL handling, flow telemetry functionality, uRPF, et. al.

If folks want to influence vendors to do the Right Thing, they have to expend the time and effort to quantify and qualify said Right Thing(s), and then put it into RFP requirements.  Otherwise, complaining post-procurement isn't generally going to accomplish much.

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From morrowc.lists at gmail.com  Fri Sep 30 20:44:52 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 30 Sep 2011 21:44:52 -0400
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <3B77D4F9-F20A-4560-A549-43FB72E1AF68@arbor.net>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
 <4E85DF11.1030905@foobar.org>
 <CAL9jLaa7fNkw_GG9_UemR95v-s=Ae2MLPv-ii6NaGvGvPntopg@mail.gmail.com>
 <4E85F071.80201@foobar.org>
 <CAL9jLaZRzJKDhvw4KwPwzCCSYwyRF4-PUFasp-6pgDUqp69P7g@mail.gmail.com>
 <3B77D4F9-F20A-4560-A549-43FB72E1AF68@arbor.net>
Message-ID: <CAL9jLaYXOuWL6ZzpRef=gAz_WWf5OCRLZtaV1Asb15FgSxW5HA@mail.gmail.com>

On Fri, Sep 30, 2011 at 9:32 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
> On Sep 30, 2011, at 11:44 PM, Christopher Morrow wrote:
>
>> this is exactly why punting anything NOT management and/or routing-protocols should be banned. Thanks for making that point explicitly.
>
> And this is the requirement which should be placed in RFPs, along with other specific requirements for ACL handling, flow telemetry functionality, uRPF, et. al.
>
> If folks want to influence vendors to do the Right Thing, they have to expend the time and effort to quantify and qualify said Right Thing(s), and then put it into RFP requirements. ?Otherwise, complaining post-procurement isn't generally going to accomplish much.
>

yes, my bitchfest was also a 'could we all start asking for this, now?' ... :)


From morrowc.lists at gmail.com  Fri Sep 30 20:48:44 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 30 Sep 2011 21:48:44 -0400
Subject: Cisco 7600 PFC3B(XL) and IPv6 packets with fragmentation header
In-Reply-To: <CAL9jLaYXOuWL6ZzpRef=gAz_WWf5OCRLZtaV1Asb15FgSxW5HA@mail.gmail.com>
References: <alpine.DEB.2.00.1109300700280.13829@uplift.swm.pp.se>
 <CAL9jLaY5yaxsKXu+A3ua3wBfQXxaKQqy1jt0usbe+vGW-AKE4g@mail.gmail.com>
 <20110930100257.GA30922@pob.ytti.fi>
 <CAL9jLaZEwVLhaQcDtsKaM3Gjrh9F+WUzvUAcM7=tNiMoipW_aQ@mail.gmail.com>
 <20110930142639.GA30986@pob.ytti.fi>
 <CAL9jLaaOtQAfebrd10KYF+SSjD4rCsNDV8C0TGww9q=oSj-Uww@mail.gmail.com>
 <4E85DF11.1030905@foobar.org>
 <CAL9jLaa7fNkw_GG9_UemR95v-s=Ae2MLPv-ii6NaGvGvPntopg@mail.gmail.com>
 <4E85F071.80201@foobar.org>
 <CAL9jLaZRzJKDhvw4KwPwzCCSYwyRF4-PUFasp-6pgDUqp69P7g@mail.gmail.com>
 <3B77D4F9-F20A-4560-A549-43FB72E1AF68@arbor.net>
 <CAL9jLaYXOuWL6ZzpRef=gAz_WWf5OCRLZtaV1Asb15FgSxW5HA@mail.gmail.com>
Message-ID: <CAL9jLaaQ-LGQp-4ugbzJ38c==zjeXizUX03_ZdzafjeaRJPZew@mail.gmail.com>

On Fri, Sep 30, 2011 at 9:44 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Fri, Sep 30, 2011 at 9:32 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>> On Sep 30, 2011, at 11:44 PM, Christopher Morrow wrote:
>>
>>> this is exactly why punting anything NOT management and/or routing-protocols should be banned. Thanks for making that point explicitly.
>>
>> And this is the requirement which should be placed in RFPs, along with other specific requirements for ACL handling, flow telemetry functionality, uRPF, et. al.
>>
>> If folks want to influence vendors to do the Right Thing, they have to expend the time and effort to quantify and qualify said Right Thing(s), and then put it into RFP requirements. ?Otherwise, complaining post-procurement isn't generally going to accomplish much.
>>
>
> yes, my bitchfest was also a 'could we all start asking for this, now?' ... :)
>


From charles at knownelement.com  Fri Sep 30 22:31:09 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Fri, 30 Sep 2011 22:31:09 -0500
Subject: Synology Disk DS211J
In-Reply-To: <CC75EEBF17C7374EA8309102B7B10C843698D12C@SHSBS.shenrons-house.local>
References: <201109300046.p8U0k9l9061612@mail.r-bonomi.com>
 <4E852502.9070007@bogus.com> <20110930061844.GE3401@mistress.hezmatt.org>
 <CC75EEBF17C7374EA8309102B7B10C843698D12C@SHSBS.shenrons-house.local>
Message-ID: <4E86897D.9050307@knownelement.com>

On 09/30/2011 08:56 AM, Blake T. Pfankuch wrote:
> The easy way around the unhappy significant other/minion shaped offspring solution is to put all of the "end user" devices On a separate VLAN, and then treat that as an open DMZ.  Then everything operational (ironic in a home) on your secured production network (restrict all outbound/inbound except what is needed).  If you really want to complicate it you should even put your wireless into a separate VLAN as well, and secure it as appropriate.  Gives you the ability firewall between networks, thus making sure that when your minions eventually get something nasty going on the PC they use, it doesn't spread through the rest of the network.  Also means you can deploy some form of content filtering policies through various solutions to prevent your minions from discovering the sites running on the most recent TLD addition.  

Packet fence. Per user vlans. RADIUS back end auth with one time
passwords. I'm trying to package all this into a turnkey distro for my
own deployment across hundreds of sites. As such I need it anyway and
don't mind open sourcing it. It's been an on again/off again project but
it's really close to release.



> This assumes that most people reading this email have the ability to run multiple routed subnets behind their home firewall.  Be it a layer 3 switch with ACL's or multiple physical interfaces and the ability to have them act independently.  

Routing on a stick to pfSense for me. Though I could use my l3 switch I
guess. *shrugs*

> Personally I run 8 separate networks (some with multiple routed subnets).  Wireless data, management network, voice networks, game consoles, storage, internal servers, DMZ servers and Project network.  Only reason why there is no "end user" network is that there are no wired drops anywhere in the house, so that falls under the wireless data. That network gets internet access and connectivity to file sharing off the internal servers and all internet traffic runs through Anti-Virus/Anti-Spyware before going outbound and inbound.

No. You aren't paranoid enough. See above. If it was turnkey, more
people would use it.

> Blake
>
> -----Original Message-----
> From: Matthew Palmer [mailto:mpalmer at hezmatt.org] 
> Sent: Friday, September 30, 2011 12:19 AM
> To: nanog at nanog.org
> Subject: Re: Synology Disk DS211J
>
> On Thu, Sep 29, 2011 at 07:10:10PM -0700, Joel jaeggli wrote:
>

-- 
Charles N Wyble charles at knownelement.com @charlesnw on twitter

http://blog.knownelement.com

Building alternative,global scale,secure, cost effective bit moving platform
for tomorrows alternate default free zone.



From joe at nethead.com  Fri Sep 30 22:32:07 2011
From: joe at nethead.com (Joe Hamelin)
Date: Fri, 30 Sep 2011 20:32:07 -0700
Subject: Were A record domain names ever limited to 23 characters?
In-Reply-To: <CAK4no06MKrLrp0p7_x4fu9HFcTQ4gFv+PdUJpEOXjfjC-RyrYA@mail.gmail.com>
References: <CAK4no04rVMZOyqGL0DU-BZpD+j46M+xOGFto4ETw=82LKnowjA@mail.gmail.com>
 <4e863c0b.07e6640a.0a87.ffffe4e2SMTPIN_ADDED@mx.google.com>
 <CAK4no06MKrLrp0p7_x4fu9HFcTQ4gFv+PdUJpEOXjfjC-RyrYA@mail.gmail.com>
Message-ID: <CAO0-hXYpQwKSZr100ujBuumW12Ppjts8WadMVz5es=wRkB_sCw@mail.gmail.com>

> On Fri, Sep 30, 2011 at 02:54:38PM -0700, steve pirk [egrep] wrote:
>  I seem to recollect back the 1999 or 2000 times that I was unable to
>  register a domain name that was 24 characters long...

I remember tales from when there was an eight character limit.  But that was
back when you didn't have to pay for them and they assigned you a class-c
block automatically.  Of course it took six weeks to register because there
was only one person running the registry.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

From gwbnanog at gmail.com  Fri Sep 30 23:28:13 2011
From: gwbnanog at gmail.com (Greg B - NANOG)
Date: Sat, 1 Oct 2011 00:28:13 -0400
Subject: Latency issue - TWC NYC / Roadrunner - AS12271 / AS7843
Message-ID: <CAC81+sEpmWMjwB9ZDNfoP8dbkcA__dL9fDHOUa71X8K8=JYp0w@mail.gmail.com>

Hi,
If anyone from Time Warner Cable / Roadrunner is monitoring, there's been a
high latency issue on your network in NYC both yesterday (for at least 10
hours) and again this evening to most/all of the internet. Please contact me
off-list if you need more information. Thanks.

Sample pings/traces below as of 10/01/2011 12:15 US Eastern:


1.
>From my home TWC connection - see hop 7:

ping www.xo.com
--- www.xo.com ping statistics ---
12 packets transmitted, 12 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 143.868/146.355/149.656/2.064 ms

traceroute www.xo.com
traceroute to www.xo.com (205.158.160.76), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  3.751 ms  0.587 ms  0.651 ms
 2  cpe-72-225-224-1.nyc.res.rr.com (72.225.224.1)  27.711 ms  29.453 ms
 12.336 ms
 3  g-2-0-nycmnya-rtr2.nyc.rr.com (24.29.139.66)  8.927 ms  8.468 ms  9.707
ms
 4  nycmnytg-10g-0-0-0.nyc.rr.com (24.29.148.29)  17.222 ms  21.110 ms
 15.531 ms
 5  * * *
 6  ae-4-0.cr0.nyc30.tbone.rr.com (66.109.6.78)  8.618 ms
    107.14.19.24 (107.14.19.24)  8.880 ms
    ae-4-0.cr0.nyc30.tbone.rr.com (66.109.6.78)  7.763 ms
 7  ae-1-0.pr0.nyc30.tbone.rr.com (66.109.6.161)  104.189 ms
    107.14.19.153 (107.14.19.153)  100.793 ms  103.203 ms
 8  216.55.0.109 (216.55.0.109)  105.266 ms
    216.55.0.65 (216.55.0.65)  104.000 ms
    216.55.0.61 (216.55.0.61)  101.070 ms
 9  vb1011.rar3.washington-dc.us.xo.net (216.156.0.21)  138.200 ms  140.265
ms  142.332 ms
10  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  140.559 ms  140.501 ms
 145.405 ms
11  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  139.805 ms  141.493 ms
 141.685 ms
12  ae0d0.mcr1.dallas-tx.us.xo.net (216.156.0.82)  140.758 ms  138.310 ms
 140.159 ms
13  216.55.13.100 (216.55.13.100)  139.605 ms  142.972 ms  140.269 ms
14  txplan01-fw01a-eth1.dc.xo.com (205.158.160.201)  141.185 ms  165.681 ms
 138.875 ms
15  xonlbvip.pla.dc.xo.com (205.158.160.76)  138.432 ms  136.816 ms  138.662
ms


2.
>From my home TWC connection - see hop 7:

ping www.level3.net
--- www.level3.net ping statistics ---
12 packets transmitted, 12 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 58.380/60.156/61.647/0.937 ms

traceroute www.level3.net
traceroute to www.level3.net (4.68.90.77), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 3.703 ms 0.621 ms 0.588 ms
2 cpe-72-225-224-1.nyc.res.rr.com (72.225.224.1) 25.585 ms 30.256 ms 28.233
ms
3 g-2-0-nycmnya-rtr2.nyc.rr.com (24.29.139.66) 11.273 ms 11.575 ms 9.182 ms
4 nycmnytg-10g-0-0-0.nyc.rr.com (24.29.148.29) 21.087 ms 11.580 ms 11.638 ms
5 * * *
6 ae-4-0.cr0.nyc30.tbone.rr.com (66.109.6.78) 10.537 ms
107.14.19.24 (107.14.19.24) 8.745 ms 10.463 ms
7 ae-1-0.pr0.nyc30.tbone.rr.com (66.109.6.161) 108.194 ms
107.14.19.153 (107.14.19.153) 109.087 ms
ae-1-0.pr0.nyc30.tbone.rr.com (66.109.6.161) 109.317 ms
8 * * *
9 ae-31-51.ebr1.newark1.level3.net (4.69.156.30) 112.040 ms 108.726 ms
107.861 ms
10 ae-2-2.ebr1.newyork1.level3.net (4.69.132.97) 110.525 ms 110.807 ms
109.539 ms
11 ae-4-4.ebr1.newyork2.level3.net (4.69.141.18) 105.738 ms 109.069 ms
110.558 ms
12 ae-1-100.ebr2.newyork2.level3.net (4.69.135.254) 110.856 ms 106.272 ms
101.736 ms
13 ae-2-2.ebr1.chicago1.level3.net (4.69.132.65) 137.025 ms 133.715 ms
150.440 ms
14 ae-6-6.ebr1.chicago2.level3.net (4.69.140.190) 129.500 ms 131.001 ms
132.307 ms
15 ae-3-3.ebr2.denver1.level3.net (4.69.132.61) 61.386 ms 58.412 ms 61.884
ms
16 ge-9-0.hsa1.denver1.level3.net (4.69.147.101) 60.336 ms 59.978 ms 60.035
ms
17 4.68.94.26 (4.68.94.26) 58.137 ms 57.445 ms 58.010 ms
18 4.68.94.33 (4.68.94.33) 61.125 ms 59.451 ms 60.578 ms
19 eth2.l3hqdc7705.idc1.broomfield1.level3.net (4.68.92.2) 61.251 ms 58.341
ms 61.785 ms
20 4.68.92.33 (4.68.92.33) 60.866 ms 60.884 ms 60.179 ms
21 * * *
22 * * *

3.
>From my home TWC connection - see hop 7:

ping www.globalcrossing.com
--- wwwgblx.lb.globalcrossing.com ping statistics ---
12 packets transmitted, 12 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 115.264/119.452/123.780/2.929 ms

traceroute www.globalcrossing.com
traceroute: Warning: www.globalcrossing.com has multiple addresses; using
207.218.55.197
traceroute to wwwgblx.lb.globalcrossing.com (207.218.55.197), 64 hops max,
52 byte packets
 1  192.168.1.1 (192.168.1.1)  1.407 ms  0.758 ms  0.585 ms
 2  cpe-72-225-224-1.nyc.res.rr.com (72.225.224.1)  18.393 ms  18.194 ms
 10.682 ms
 3  g-2-0-nycmnya-rtr2.nyc.rr.com (24.29.139.66)  7.720 ms  8.155 ms  9.412
ms
 4  nycmnytg-10g-0-0-0.nyc.rr.com (24.29.148.29)  13.247 ms  11.104 ms
 12.423 ms
 5  * * *
 6  107.14.19.24 (107.14.19.24)  10.703 ms  8.618 ms  9.633 ms
 7  ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163)  87.927 ms  88.377 ms
 86.158 ms
 8  tengigabitethernet3-3.ar7.nyc1.gblx.net (64.213.104.193)  88.005 ms
    66.109.9.210 (66.109.9.210)  90.130 ms
    te7-4.ar1.nyc8.gblx.net (208.48.23.1)  90.725 ms
 9  * * *
10  * * *

From kkadow at gmail.com  Fri Sep 30 23:39:49 2011
From: kkadow at gmail.com (Kevin Kadow)
Date: Sat, 1 Oct 2011 00:39:49 -0400
Subject: events
In-Reply-To: <-3411316358946087267@unknownmsgid>
References: <CAB_zYdJ6au02ofnsVFOw7Zi2hLV+_z4_-uKrkxkCizzsrGq=Xw@mail.gmail.com>
 <CAMvhC_44gr4rS026fLDYZ1=KZHCs83gG-LQ6PTR-M44U5HamHQ@mail.gmail.com>
 <BLU158-W6487104EECF26B798950DADCF70@phx.gbl>
 <CAHDg04sNcKMBf8+sxw3ZRVkhRFwKQU8vLvLTSJxXY+THL2wGBA@mail.gmail.com>
 <BLU158-W116567FE383FF900DF0ACDDCF70@phx.gbl>
 <C73D04D0-8FA2-4B69-95D9-9017ED0ED446@lixfeld.ca>
 <-3411316358946087267@unknownmsgid>
Message-ID: <CAMY_91vqLo065S8gsLUHJwXVsER_W9VTP8O-R30YMa4CfiyqpA@mail.gmail.com>

On Fri, Sep 30, 2011 at 2:44 PM, Ukpong Ukpong <ukpong.ukpong at gmail.com> wrote:
> Have you tried qradar? It's rather good

I've used  Splunk and QRadar;  both are available as free VMware
appliances with limitations on log volume, sufficient for testing.  Or
if you're mostly looking at webserver/proxy/firewall logs, Sawmill is
worth checking out.

I've also been looking into using Lancope's replicator to take in
syslog UDP and send copies to multiple loggers, since some appliances
only support a single syslog destination.

Kevin