From jsw at inconcepts.biz  Thu Dec  1 02:36:13 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Thu, 1 Dec 2011 03:36:13 -0500
Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64:
 are they possible in DOCSIS networks?)
In-Reply-To: <CAAAas8Hu5HLVjf+Xx9edF_J_fTm8JmSFnGsSQJVb405y3htr=Q@mail.gmail.com>
References: <CAAAas8Hu5HLVjf+Xx9edF_J_fTm8JmSFnGsSQJVb405y3htr=Q@mail.gmail.com>
Message-ID: <CAPWAtbLtHa_SsRr28q9CvWcZzOmqEEQSoFN_jz84d69V9DryJA@mail.gmail.com>

On Wed, Nov 30, 2011 at 9:15 PM, Mike Jones <mike at mikejones.in> wrote:
> Link-Local?
>
> For "true" P-t-P links I guess you don't need any addresses on the

Point-to-point links in your backbone are by far the easiest thing to
defend against this attack.  I wish we would steer the discussion away
from point-to-point links that are entirely within the control of the
operator, as this is really quite well understood.  Major ISPs
including Level3 are already doing /126 to their customers today as
well.  In fact, Level3 does not even reserve a /64, they will hand out
::0/126 to one customer on a given access router, ::4/126 to the next.
 It clearly works.

The access layer for non point-to-point customers, on the other hand,
is less well-understood.  That's why we keep having these discussions.
 Getting customers (and their device/software) to work correctly with
link-local addressing and DHCP-PD or similar is going to be an uphill
battle in a hosting environment.  It also breaks down immediately if
the hosting customer, for example, wishes to use ND to be able to
provision addresses on two or more servers from a common subnet.  So
there are both perception and practical problems / limitations with
this approach.  I'm not saying it's a bad idea, but it won't work in
some instances.

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


From doctorchd at gmail.com  Thu Dec  1 04:11:12 2011
From: doctorchd at gmail.com (Dmitry Cherkasov)
Date: Thu, 1 Dec 2011 12:11:12 +0200
Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS
 networks?
In-Reply-To: <CAFBC9EF.1B86A0%john_brzozowski@cable.comcast.com>
References: <CAP5kh1A0+5zkJvBmoiMCA85R__4SmCPkcxOD52t7FNHuNb_vtA@mail.gmail.com>
 <CAFBC9EF.1B86A0%john_brzozowski@cable.comcast.com>
Message-ID: <CAP5kh1B4oPCu5c6L7iKC6qPOhGLj6bYdQRucmhJ23VFzgMMFhg@mail.gmail.com>

John,

Due to your note I carefully read again Cable Labs specs and found
that really SLAAC is not prohibited. According to CM-SP-MULPIv3.0:

* If the M bit in the RA is set to 1, the CM (cable modem) MUST use DHCPv6 ...;
* If there are no prefix information options in the RA, the CM MUST
NOT perform SLAAC;
* If the RA contains a prefix advertisement with the A bit set to 0,
the CM MUST NOT perform SLAAC on that prefix.

That means that if M bit in the RA is set to 0 and RA contains a
prefix advertisement with the A bit set to 1 nothing prevents CM from
SLAAC.
And if so we probably better reserve /64 per network just in case we
may use SLAAC in it in the future. While we do not use SLAAC we can
shorten the range of actually used IPv6 addresses by using longer then
/64 prefix.

You are completely right that prefix delegation enforce DHCPv6 so
SLAAC mentioned above can be used only for CMs, not for CPE.

Just a note: as far as I can see available DOCSIS 3.0 CMTSes do not
support the ability of SLAAC for CMs currently (checked Casa and Cisco
uBR10K).


Dmitry Cherkasov



2011/11/30 Brzozowski, John <John_Brzozowski at cable.comcast.com>:
> Technically this is not true. ?SLAAC is not prohibited, it does come with
> side affects that complicate the deployment of IPv6. ?It is technically
> feasible to use SLAAC, it is just not practical in most cases.
>
> Stateful DHCPv6 is the preferred mechanism for address and configuration
> assignment. ?Prefix delegation requires the use of stateful DHCPv6 in
> DOCSIS networks.
>
> John
> =========================================
> John Jason Brzozowski
> Comcast Cable
> e) mailto:john_brzozowski at cable.comcast.com
> o) 609-377-6594
> m) 484-962-0060
> w) http://www.comcast6.net
> =========================================
>
>
>
>
> On 11/29/11 7:09 AM, "Dmitry Cherkasov" <doctorchd at gmail.com> wrote:
>
>>Steven,
>>
>>SLAAC is prohibited for using in DOCSIS networks, router
>>advertisements that allow SLAAC must be ignored by end-devices,
>>therefore DHCPv6 is the only way of configuring (if not talking about
>>statical assignment). I have seen at least Windows7 handling this
>>properly in its default configuration: it starts DHCPv6 negotiation
>>instead of auto-configuration.
>>
>>Dmitry Cherkasov
>>
>>
>>
>>2011/11/29 Steven Bellovin <smb at cs.columbia.edu>:
>>>
>>> On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
>>>
>>>>
>>>> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
>>>>
>>>>> It's a good practice to reserve a 64-bit prefix for each network.
>>>>> That's a good general rule. ?For point to point or link networks you
>>>>> can use something as small as a 126-bit prefix (we do).
>>>>>
>>>>
>>>> Technically, absent buggy {firm,soft}ware, you can use a /127. There's
>>>>no
>>>> actual benefit to doing anything longer than a /64 unless you have
>>>> buggy *ware (ping pong attacks only work against buggy *ware),
>>>> and there can be some advantages to choosing addresses other than
>>>> ::1 and ::2 in some cases. If you're letting outside packets target
>>>>your
>>>> point-to-point links, you have bigger problems than neighbor table
>>>> attacks. If not, then the neighbor table attack is a bit of a
>>>>red-herring.
>>>>
>>>
>>> The context is DOCSIS, i.e., primarily residential cable modem users,
>>>and
>>> the cable company ISPs do not want to spend time on customer care and
>>> hand-holding. ?How are most v6 machines configured by default? ?That is,
>>> what did Microsoft do for Windows Vista and Windows 7? ?If they're set
>>>for
>>> stateless autoconfig, I strongly suspect that most ISPs will want to
>>>stick
>>> with that and hand out /64s to each network. ?(That's apart from the
>>>larger
>>> question of why they should want to do anything else...)
>>>
>>>
>>> ? ? ? ? ? ? ? ?--Steve Bellovin, https://www.cs.columbia.edu/~smb
>>>
>>>
>>>
>>>
>>>
>>>
>>
>


From bjohnson at drtel.com  Thu Dec  1 08:10:02 2011
From: bjohnson at drtel.com (Brian Johnson)
Date: Thu, 1 Dec 2011 14:10:02 +0000
Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS
 networks?
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B60F4BF@ex-mb-1.corp.atlasnetworks.us>
References: <CAF976C9.1B7412%john_brzozowski@cable.comcast.com>
 <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com>
 <DEBECAC9A6D5224D95078F3CDC36225809C431@TKMNAEXCH.thyssenna.com>
 <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com>
 <4ED52053.5040102@bogus.com>
 <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com>
 <CAAAwwbU4upBZWmXiixWAXYmfAg5_DydytDBLjOZ3MNHGmDR3xQ@mail.gmail.com>
 <CALFTrnNFjFZtmWay4T4ASYbZZf0vcaaUVc7G=sLEyV78qKBAgw@mail.gmail.com>
 <CAPWAtbJVXyg4xx77tvO5UASyLMhL8-OUkwA3dYawqDPx=0pO-Q@mail.gmail.com>
 <CALFTrnPtuihjLdpqLw9LzicLmHyuRnfT=2Lw_P+h7YCffNtbcA@mail.gmail.com>
 <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com>
 <CALFTrnOd3gqob=ZD9qGJVmoAAGef8A-WEAyAA3uMSQU9y17sNg@mail.gmail.com>
 <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com>
 <8C26A4FDAE599041A13EB499117D3C286B60F4BF@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <F05D77A9631CAE4097F7B69095F1B06F597419A0@EX02.drtel.lan>

Nathan,

I respect your positions,  but you presume too much. I'm in no way an evangelist, but I agree with most of the points made by those you categorize as such. I'll reply specifically in-line.

>-----Original Message-----
>From: Nathan Eisenberg [mailto:nathan at atlasnetworks.us]
>Sent: Wednesday, November 30, 2011 4:05 PM
>To: nanog at nanog.org
>Subject: RE: IPv6 prefixes longer then /64: are they possible in DOCSIS
>networks?
>
<SNIP>
>
>Or you might do what a lot of us have done: get sick of arguing with the
>evangelists about how /64's don't make sense for everyone in every scenario.
>Get sick of trying to argue that every home's CPE doesn't need a /48
>delegated to it so that it can automatically subdelegate longer networks to
>devices which will in turn subdelegate even longer prefixes to devices which
>"something that hasn't been invented yet will use, and if you don't set it up
>this way, history will prove that you're an unimaginative fool".  Get sick of
>hearing "It's a huge address space, so don't worry about being conservative -
>sitting 'on the shelf' or sitting unused in a network are the same thing" (I guess
>we'll migrate to an even bigger address space if we someday have other
>stellar bodies in our local star system to send packets to, despite the average
>home network utilizing far, far less than .00[...]01% of their address space... -
>add a lot more 0's if the /48 guys win out...)

It sounds like you are still in the IPv4 paradigm. I agree with your statements, but not your tone or implications. I think you misread people who have immense knowledge on the subject matter and care deeply with people who are grinding an axe for political or emotional purposes. If someone argued with you on the subtleties of gravity and doesn't accept the basic premise of gravity, you would likely respond similarly.

>
>This new IPv6 world is full of lazy evangelists, who are so excited about same-
>sized subnets, stateless address configuration and globally unique and
>routable addresses for purposes that no one can quite imagine yet, that they
>cannot engage in a logical and rational discussion with the rest of us.  Instead,
>we go back and forth over the same concerns, until the patience of the list has
>been utterly worn out - at which point, these individuals always throw their
>hands in the air, and exclaim: "You're wrong, and your customers will tell you
>that with their feet", and presume that they have then proven you wrong.

I'm rubber your glue.... Never mind.  The things you are minimalizing are some of the design specifications of the protocol. It's like arguing about the fact that IPv4 has certain headers and they are dumb. GET OVER IT!

And no one will ever prove you wrong. It's that everyone else will do one thing and you will do something else. Live with your decision.

This debate result can be seen in situations where people are too far apart at the start. This may be due to the paradigm shift to IPv6 from IPv4.

>
>As has been pointed out, there is a lot of human nature at work here: these
>individuals have made low-level emotional investments in their arguments,
>and divided the IPv6-think world into two categories: Us (right), and Not Us
>(wrong).  When someone does this, it can take a significant amount of
>psychology to get the conversation to a rational place, and unless you have a
>real need to see eye to eye with them, it's often easier to move on.  In any
>case, do the research and testing, and make sure that at least your own
>deployments have rational addressing policies (whatever you determine that
>might be).

I wish you hadn't gone into the psychological babble here. You are right about this though. Do what you think is best for you. Please do not denigrate others for not coming to the same conclusions as you.

When you ask for an opinion on this type of medium, about a controversial topic, you will get this type of thread. Live it.... Love it!

- Brian Johnson


From jra at baylink.com  Thu Dec  1 08:41:35 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 1 Dec 2011 09:41:35 -0500 (EST)
Subject: Wired mag piece on the Water Utility SCADA 'Attack'
In-Reply-To: <14351735.1125.1322750472895.JavaMail.root@benjamin.baylink.com>
Message-ID: <21004746.1127.1322750495937.JavaMail.root@benjamin.baylink.com>

Damn that was quick:

  http://j.mp/rvWnEC

(hat tip: lauren at vortex)

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 cra at WPI.EDU  Thu Dec  1 08:42:07 2011
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 1 Dec 2011 09:42:07 -0500
Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS
 networks?
In-Reply-To: <CAAAwwbVJsE2okH8RzefZFYngx49-vgH3nq+cuTk8woz7u32NwA@mail.gmail.com>
References: <DEBECAC9A6D5224D95078F3CDC36225809C431@TKMNAEXCH.thyssenna.com>
 <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com>
 <4ED52053.5040102@bogus.com>
 <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com>
 <CAAAwwbU4upBZWmXiixWAXYmfAg5_DydytDBLjOZ3MNHGmDR3xQ@mail.gmail.com>
 <CALFTrnNFjFZtmWay4T4ASYbZZf0vcaaUVc7G=sLEyV78qKBAgw@mail.gmail.com>
 <CAPWAtbJVXyg4xx77tvO5UASyLMhL8-OUkwA3dYawqDPx=0pO-Q@mail.gmail.com>
 <CALFTrnPtuihjLdpqLw9LzicLmHyuRnfT=2Lw_P+h7YCffNtbcA@mail.gmail.com>
 <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com>
 <CAAAwwbVJsE2okH8RzefZFYngx49-vgH3nq+cuTk8woz7u32NwA@mail.gmail.com>
Message-ID: <20111201144207.GN9465@angus.ind.WPI.EDU>

On Wed, Nov 30, 2011 at 06:55:56PM -0600, Jimmy Hess wrote:
> On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong <owen at delong.com> wrote:
> > On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote:
> > I do believe that there is no benefit to longer prefixes than /64.
> > Nobody has provided any convincing evidence to the contrary.
> 
> Yes they have, thoroughly;   mitigation of this one particular issue, ND table
> overflow is a benefit.  You simply don't have to worry about this issue in
> the most important place it arises if you implement long prefixes for all
> P-t-P links from the start.
> 
> I do believe there is no benefit to prefixes shorter than /126 for P-t-P links.
> Nobody has provided convincing evidence to the contrary.
> 
> > There are better ways to mitigate ND than longer prefixes.
> 
> Please explain.    What are the better ways that you would propose
> of mitigating ND table overflows?
> If you can show a rational alternative, then it would be persuasive as
> a better option.

Jumping in here, how about static ND entries?  Then you can use the
/64 for P-t-P, but set the few static ND entries you need, and turn
off dynamic ND.  An out-of-band provisioning system could add static
ND entries as needed.

Another idea, perhaps more useful for client LANs, would be to have a
fixed mapping between IPv6 IID and MAC address.  Use DHCPv6 to force
clients' lower 64 bits to be equal to their MAC address (EUI-64 or
similar) and program the router to use this directly instead of using
NDP, or statically program the ND table on the router from the DHCPv6
lease data--there is already precedent for doing this with IPv4 & ARP
using DHCP Snooping or Relay or Proxy on the router.


From nanog at data102.com  Thu Dec  1 09:17:08 2011
From: nanog at data102.com (randal k)
Date: Thu, 1 Dec 2011 08:17:08 -0700
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <CAD45i01K_e4pkuvmJwHQp3rGMYo21Cb_XMBZ+a6PMzaCHf7Tog@mail.gmail.com>
References: <CAJEFqDfht_k4wG3ev2m5uJWNhak16p=LMkPtJoBUSBmea+=uow@mail.gmail.com>
 <48778.1321883369@turing-police.cc.vt.edu>
 <CAJEFqDdP8JLLJNFM++JBHncREOic=X0TsUy2KUfvKp7VKLCzgA@mail.gmail.com>
 <4ECAB566.5070408@blakjak.net>
 <CAJEFqDfDiEOOOtSht2ivSDi8SyGBut8hw5fLOWrSn2b+HYdVNg@mail.gmail.com>
 <CAD45i01K_e4pkuvmJwHQp3rGMYo21Cb_XMBZ+a6PMzaCHf7Tog@mail.gmail.com>
Message-ID: <CANeLk7TjUsrV9RLAtNYnECWVu+1se_in70Lypav=Z5KTvjdnKA@mail.gmail.com>

This is a huge point. We've had a LOT of trouble finding good network
engineers who have all of the previously mentioned "soft" attributes -
attitude, team player, can write, can speak, can run a small project - and
are more than just Cisco pimps. I cannot explain how frustrating it is to
meet a newly minted CCNP who has zero Linux experience, can't script
anything, can't setup a syslog server, doesn't understand AD much less
LDAP, etc. Imagine, an employee who can help themselves 90% of the time ...

Finding the diamond that has strong niche skill, networking, with a broad &
just-deep-enough sysadmin background has been very, very hard. I cannot
emphasize enough the importance of cross-training. Immensely valuable.

Randal

On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewart <nonobvious at gmail.com> wrote:

>  And yeah, sometimes it means that you need to go
> learn technologies like Active Directory
>
 [snip]

>
> In addition to learning scripting languages
>

From jra at baylink.com  Thu Dec  1 09:24:59 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 1 Dec 2011 10:24:59 -0500 (EST)
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <CANeLk7TjUsrV9RLAtNYnECWVu+1se_in70Lypav=Z5KTvjdnKA@mail.gmail.com>
Message-ID: <17004148.1137.1322753099098.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "randal k" <nanog at data102.com>

> Finding the diamond that has strong niche skill, networking, with a broad &
> just-deep-enough sysadmin background has been very, very hard. I cannot
> emphasize enough the importance of cross-training. Immensely valuable.

A relatively serviceable argument can be made that that guy who knows every 
parameter of every command of every version of IOS ever shipped, and which
bugs are in which ones...

is like that cause he's an Aspie, and you're not gonna *get* the other stuff
from him or her, no matter how hard you try.

Luckily, by the time you get to the point where you *need* that person, your
staff is usually large enough that you can absorb some savants.

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 leigh.porter at ukbroadband.com  Thu Dec  1 09:21:17 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 1 Dec 2011 15:21:17 +0000
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <CANeLk7TjUsrV9RLAtNYnECWVu+1se_in70Lypav=Z5KTvjdnKA@mail.gmail.com>
References: <CAJEFqDfht_k4wG3ev2m5uJWNhak16p=LMkPtJoBUSBmea+=uow@mail.gmail.com>
 <48778.1321883369@turing-police.cc.vt.edu>
 <CAJEFqDdP8JLLJNFM++JBHncREOic=X0TsUy2KUfvKp7VKLCzgA@mail.gmail.com>
 <4ECAB566.5070408@blakjak.net>
 <CAJEFqDfDiEOOOtSht2ivSDi8SyGBut8hw5fLOWrSn2b+HYdVNg@mail.gmail.com>
 <CAD45i01K_e4pkuvmJwHQp3rGMYo21Cb_XMBZ+a6PMzaCHf7Tog@mail.gmail.com>
 <CANeLk7TjUsrV9RLAtNYnECWVu+1se_in70Lypav=Z5KTvjdnKA@mail.gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE003314786444CC5E@EALPO1.ukbroadband.com>

I am looking for just such a person now. Good Juniper, some Cisco and Sysadmin experience with an ISP background..

I expect it will be immensely difficult to find somebody. What makes it even more frustrating is that just such a person was not all that long ago made redundant!

So if anybody is looking for something to do around London...

--
Leigh


> -----Original Message-----
> From: randal k [mailto:nanog at data102.com]
> Sent: 01 December 2011 15:19
> To: Bill Stewart
> Cc: nanog at nanog.org
> Subject: Re: Looking for a Tier 1 ISP Mentor for career advice.
> 
> This is a huge point. We've had a LOT of trouble finding good network
> engineers who have all of the previously mentioned "soft" attributes -
> attitude, team player, can write, can speak, can run a small project -
> and
> are more than just Cisco pimps. I cannot explain how frustrating it is
> to
> meet a newly minted CCNP who has zero Linux experience, can't script
> anything, can't setup a syslog server, doesn't understand AD much less
> LDAP, etc. Imagine, an employee who can help themselves 90% of the time
> ...
> 
> Finding the diamond that has strong niche skill, networking, with a
> broad &
> just-deep-enough sysadmin background has been very, very hard. I cannot
> emphasize enough the importance of cross-training. Immensely valuable.
> 
> Randal
> 
> On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewart <nonobvious at gmail.com>
> wrote:
> 
> >  And yeah, sometimes it means that you need to go
> > learn technologies like Active Directory
> >
>  [snip]
> 
> >
> > In addition to learning scripting languages
> >
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud
> service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From manager at monmouth.com  Thu Dec  1 09:52:39 2011
From: manager at monmouth.com (Mark Stevens)
Date: Thu, 01 Dec 2011 10:52:39 -0500
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <D181DDABABE57E4DB72FEE003314786444CC5E@EALPO1.ukbroadband.com>
References: <CAJEFqDfht_k4wG3ev2m5uJWNhak16p=LMkPtJoBUSBmea+=uow@mail.gmail.com>
 <48778.1321883369@turing-police.cc.vt.edu>
 <CAJEFqDdP8JLLJNFM++JBHncREOic=X0TsUy2KUfvKp7VKLCzgA@mail.gmail.com>
 <4ECAB566.5070408@blakjak.net>
 <CAJEFqDfDiEOOOtSht2ivSDi8SyGBut8hw5fLOWrSn2b+HYdVNg@mail.gmail.com>
 <CAD45i01K_e4pkuvmJwHQp3rGMYo21Cb_XMBZ+a6PMzaCHf7Tog@mail.gmail.com>
 <CANeLk7TjUsrV9RLAtNYnECWVu+1se_in70Lypav=Z5KTvjdnKA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE003314786444CC5E@EALPO1.ukbroadband.com>
Message-ID: <4ED7A2C7.7010105@monmouth.com>

It takes me years to find such people and when I do, I try very hard to 
keep them! I have 3 key people that fit the "soft" attribute criteria 
Randal mentioned, but with a premium skill set in their specific 
function. Good luck with your task Leigh!

Mark Stevens


On 12/1/2011 10:21 AM, Leigh Porter wrote:
> I am looking for just such a person now. Good Juniper, some Cisco and Sysadmin experience with an ISP background..
>
> I expect it will be immensely difficult to find somebody. What makes it even more frustrating is that just such a person was not all that long ago made redundant!
>
> So if anybody is looking for something to do around London...
>
> --
> Leigh
>
>
>> -----Original Message-----
>> From: randal k [mailto:nanog at data102.com]
>> Sent: 01 December 2011 15:19
>> To: Bill Stewart
>> Cc: nanog at nanog.org
>> Subject: Re: Looking for a Tier 1 ISP Mentor for career advice.
>>
>> This is a huge point. We've had a LOT of trouble finding good network
>> engineers who have all of the previously mentioned "soft" attributes -
>> attitude, team player, can write, can speak, can run a small project -
>> and
>> are more than just Cisco pimps. I cannot explain how frustrating it is
>> to
>> meet a newly minted CCNP who has zero Linux experience, can't script
>> anything, can't setup a syslog server, doesn't understand AD much less
>> LDAP, etc. Imagine, an employee who can help themselves 90% of the time
>> ...
>>
>> Finding the diamond that has strong niche skill, networking, with a
>> broad&
>> just-deep-enough sysadmin background has been very, very hard. I cannot
>> emphasize enough the importance of cross-training. Immensely valuable.
>>
>> Randal
>>
>> On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewart<nonobvious at gmail.com>
>> wrote:
>>
>>>   And yeah, sometimes it means that you need to go
>>> learn technologies like Active Directory
>>>
>>   [snip]
>>
>>> In addition to learning scripting languages
>>>
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud
>> service.
>> For more information please visit http://www.symanteccloud.com
>> ______________________________________________________________________
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>
>
>


From igor at ergens.org  Thu Dec  1 10:07:15 2011
From: igor at ergens.org (Igor Ybema)
Date: Thu, 1 Dec 2011 17:07:15 +0100
Subject: bgp update destroying transit on redback routers ?
Message-ID: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>

Hi there,
Since about 15:00u GMT we receive bgp updates from our transit which
destroys the bgp sessions with them with message:

send NOTIFICATION: 3/9 (update: optional attribute error) with 11 byte
data. mxReadMs=610

We use redback smartedge routers (SE100) currently for BGP.

Anyone who have seen this also?

regards, Igor

From bicknell at ufp.org  Thu Dec  1 10:13:18 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 1 Dec 2011 08:13:18 -0800
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <CANeLk7TjUsrV9RLAtNYnECWVu+1se_in70Lypav=Z5KTvjdnKA@mail.gmail.com>
References: <CAJEFqDfht_k4wG3ev2m5uJWNhak16p=LMkPtJoBUSBmea+=uow@mail.gmail.com>
 <48778.1321883369@turing-police.cc.vt.edu>
 <CAJEFqDdP8JLLJNFM++JBHncREOic=X0TsUy2KUfvKp7VKLCzgA@mail.gmail.com>
 <4ECAB566.5070408@blakjak.net>
 <CAJEFqDfDiEOOOtSht2ivSDi8SyGBut8hw5fLOWrSn2b+HYdVNg@mail.gmail.com>
 <CAD45i01K_e4pkuvmJwHQp3rGMYo21Cb_XMBZ+a6PMzaCHf7Tog@mail.gmail.com>
 <CANeLk7TjUsrV9RLAtNYnECWVu+1se_in70Lypav=Z5KTvjdnKA@mail.gmail.com>
Message-ID: <20111201161317.GA66722@ussenterprise.ufp.org>

In a message written on Thu, Dec 01, 2011 at 08:17:08AM -0700, randal k wrote:
> This is a huge point. We've had a LOT of trouble finding good network
> engineers who have all of the previously mentioned "soft" attributes -
> attitude, team player, can write, can speak, can run a small project - and
> are more than just Cisco pimps. I cannot explain how frustrating it is to
> meet a newly minted CCNP who has zero Linux experience, can't script
> anything, can't setup a syslog server, doesn't understand AD much less
> LDAP, etc. Imagine, an employee who can help themselves 90% of the time ...

I've been on both sides of this coin, looking for folks with these
sorts of skills and finding them very difficult to find but also
looking for employers who valued this base of skills when I have
been job hunting in the past.

My observation is that most ISP's want this broad base of skills,
but won't pay for it.  The folks with these skills promptly move
in one of a few directions.  They become consultants making huge
money but dealing with the clueless.  They become SE's for vendors
and VAR's, where their skills can earn them comissions.  The few
lucky ones become Architects or Principal Engineers and provide
vision and run key projects, but then they aren't doing much day
to day work.

More interestingly, the people with these sorts of skills got them
because they like touching everything and maintaining their end to
end knowledge.  While it's more a problem on the corporate side, a
lot of folks want to hire this knowledge and then put them in a
role where their hands are tied, unable to access all of these
parts.  Obstensibly the goal is to have them lead and mentor the
clueless in control of the various elements, but the few folks I've
seen try it quickly get frustrated, see no future in it, and leave.
No where is this more true than when these sorts of folks are brought in
to manage outsourced arrangements.

It's a wonderful double edged sword.  Someone who can think their
way out of a myriad of technical problems is also smart enough to
evaluate the orginizational structure and dynamics, predict their
own future (or lack thereof), predict the success and failure rates
of the current envornment and leave if they don't think it's a net
positive.

I do think NANOG as a community could do a better job in helping
employers and potential employees in this industry find each other.
I know nanog-jobs exists, but it doesn't seem to have traction with
either side of the problem.

-- 
       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/20111201/fafae197/attachment.bin>

From leigh.porter at ukbroadband.com  Thu Dec  1 10:36:39 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 1 Dec 2011 16:36:39 +0000
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <20111201161317.GA66722@ussenterprise.ufp.org>
References: <CAJEFqDfht_k4wG3ev2m5uJWNhak16p=LMkPtJoBUSBmea+=uow@mail.gmail.com>
 <48778.1321883369@turing-police.cc.vt.edu>
 <CAJEFqDdP8JLLJNFM++JBHncREOic=X0TsUy2KUfvKp7VKLCzgA@mail.gmail.com>
 <4ECAB566.5070408@blakjak.net>
 <CAJEFqDfDiEOOOtSht2ivSDi8SyGBut8hw5fLOWrSn2b+HYdVNg@mail.gmail.com>
 <CAD45i01K_e4pkuvmJwHQp3rGMYo21Cb_XMBZ+a6PMzaCHf7Tog@mail.gmail.com>
 <CANeLk7TjUsrV9RLAtNYnECWVu+1se_in70Lypav=Z5KTvjdnKA@mail.gmail.com>
 <20111201161317.GA66722@ussenterprise.ufp.org>
Message-ID: <D181DDABABE57E4DB72FEE003314786444CF34@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell at ufp.org]
> Sent: 01 December 2011 16:15
> To: nanog at nanog.org
> Subject: Re: Looking for a Tier 1 ISP Mentor for career advice.


> It's a wonderful double edged sword.  Someone who can think their way
> out of a myriad of technical problems is also smart enough to evaluate
> the orginizational structure and dynamics, predict their own future (or
> lack thereof), predict the success and failure rates of the current
> envornment and leave if they don't think it's a net positive.


An excellent analysis of the situation.

--
Leigh


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From snar at snar.spb.ru  Thu Dec  1 10:38:03 2011
From: snar at snar.spb.ru (Alexandre Snarskii)
Date: Thu, 1 Dec 2011 20:38:03 +0400
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
Message-ID: <20111201163803.GA50110@snar.spb.ru>

On Thu, Dec 01, 2011 at 05:07:15PM +0100, Igor Ybema wrote:
> Hi there,
> Since about 15:00u GMT we receive bgp updates from our transit which
> destroys the bgp sessions with them with message:
> 
> send NOTIFICATION: 3/9 (update: optional attribute error) with 11 byte
> data. mxReadMs=610
> 
> We use redback smartedge routers (SE100) currently for BGP.
> 
> Anyone who have seen this also?

Have a complaint from our customer too. On our side (juniper) this is 
logged as: 

NOTIFICATION received from <peer-ip> (External AS <peer-as>): code 3 
(Update Message Error) subcode 9 (error with optional attribute), 
Data:  c0 07 08 00 00 00

As far as I can decode this attribute this is: 
c0: optional, transitive, no partial, no extended-length
07: AGGREGATOR
08: attribute length is 8 bytes. 

I think attribute length may be a problem here, because per RFC

AGGREGATOR is an optional transitive attribute of length 6.

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 



From igor at ergens.org  Thu Dec  1 11:03:17 2011
From: igor at ergens.org (Igor Ybema)
Date: Thu, 1 Dec 2011 18:03:17 +0100
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <20111201163803.GA50110@snar.spb.ru>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
 <20111201163803.GA50110@snar.spb.ru>
Message-ID: <CANwiKaaRr6zd62_MSnPE2VRHs-kZBsO9YbKMQ97w-a0JDBhAvg@mail.gmail.com>

>
> AGGREGATOR is an optional transitive attribute of length 6.
>
> --
> In theory, there is no difference between theory and practice.
> But, in practice, there is.


Typical, because:

AGGREGATOR is an optional transitive attribute of length 6.
            The attribute contains the last AS number that formed the
            aggregate route (encoded as 2 octets), followed by the IP
            address of the BGP speaker that formed the aggregate route
            (encoded as 4 octets).  Usage of this attribute is described
            in 5.1.7

And what to do with 4-byte AS-numbers then? That would explain the 8 bytes.

regards, Igor


From igor at ergens.org  Thu Dec  1 11:08:54 2011
From: igor at ergens.org (Igor Ybema)
Date: Thu, 1 Dec 2011 18:08:54 +0100
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <CANwiKaaRr6zd62_MSnPE2VRHs-kZBsO9YbKMQ97w-a0JDBhAvg@mail.gmail.com>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
 <20111201163803.GA50110@snar.spb.ru>
 <CANwiKaaRr6zd62_MSnPE2VRHs-kZBsO9YbKMQ97w-a0JDBhAvg@mail.gmail.com>
Message-ID: <CANwiKabrQLYxyUDgGbwTDjJs0CKpP5hnnT4bdzNurpmL0szy7g@mail.gmail.com>

> And what to do with 4-byte AS-numbers then? That would explain the 8 bytes.
>

Looking futher:

Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that
can be used to propagate four-octet based AS path information cross
BGP speakers that do not support the four-octet AS numbers.

However this router is AS4 capable, but probably fails to understand a
4-byte AS in the normal AGGREGATOR attribute. If I understand
correctly a AS4 capable router should understand when announcing that
to it's peer.

I'm I correct? Should I file this as a bug? (redback/ericsson is
already looking also)

regards, Igor


From dholmes at mwdh2o.com  Thu Dec  1 11:26:13 2011
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Thu, 1 Dec 2011 09:26:13 -0800
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <4ED7A2C7.7010105@monmouth.com>
References: <CAJEFqDfht_k4wG3ev2m5uJWNhak16p=LMkPtJoBUSBmea+=uow@mail.gmail.com>
 <48778.1321883369@turing-police.cc.vt.edu>
 <CAJEFqDdP8JLLJNFM++JBHncREOic=X0TsUy2KUfvKp7VKLCzgA@mail.gmail.com>
 <4ECAB566.5070408@blakjak.net>
 <CAJEFqDfDiEOOOtSht2ivSDi8SyGBut8hw5fLOWrSn2b+HYdVNg@mail.gmail.com>
 <CAD45i01K_e4pkuvmJwHQp3rGMYo21Cb_XMBZ+a6PMzaCHf7Tog@mail.gmail.com>
 <CANeLk7TjUsrV9RLAtNYnECWVu+1se_in70Lypav=Z5KTvjdnKA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE003314786444CC5E@EALPO1.ukbroadband.com>
 <4ED7A2C7.7010105@monmouth.com>
Message-ID: <922ACC42D498884AA02B3565688AF995340255F3F3@USEXMBS01.mwd.h2o>

Personally, I have worked in places where I have performed all of the skills below (router/switch/Unix/Linux/AD/firewall/proxy/web admin/sendmail admin, etc.), and also in places where just router/switch/architect layer 1-3 skills were the primary focus. I prefer the latter, and find this to be a personal choice as to what makes for a meaningful and fulfilling job. The fact that so few network engineers are to be found with all of these skills, I think, speaks for itself in that many network engineers have made the choice, and that choice is to be focused on layers 1-3, which, with DWDM through BGP, offers many challenging, different, and varied technology complexities the mastery of which makes work meaningful and rewarding.

-----Original Message-----
From: Mark Stevens [mailto:manager at monmouth.com]
Sent: Thursday, December 01, 2011 7:53 AM
To: nanog at nanog.org
Subject: Re: Looking for a Tier 1 ISP Mentor for career advice.

It takes me years to find such people and when I do, I try very hard to
keep them! I have 3 key people that fit the "soft" attribute criteria
Randal mentioned, but with a premium skill set in their specific
function. Good luck with your task Leigh!

Mark Stevens


On 12/1/2011 10:21 AM, Leigh Porter wrote:
> I am looking for just such a person now. Good Juniper, some Cisco and Sysadmin experience with an ISP background..
>
> I expect it will be immensely difficult to find somebody. What makes it even more frustrating is that just such a person was not all that long ago made redundant!
>
> So if anybody is looking for something to do around London...
>
> --
> Leigh
>
>
>> -----Original Message-----
>> From: randal k [mailto:nanog at data102.com]
>> Sent: 01 December 2011 15:19
>> To: Bill Stewart
>> Cc: nanog at nanog.org
>> Subject: Re: Looking for a Tier 1 ISP Mentor for career advice.
>>
>> This is a huge point. We've had a LOT of trouble finding good network
>> engineers who have all of the previously mentioned "soft" attributes -
>> attitude, team player, can write, can speak, can run a small project -
>> and
>> are more than just Cisco pimps. I cannot explain how frustrating it is
>> to
>> meet a newly minted CCNP who has zero Linux experience, can't script
>> anything, can't setup a syslog server, doesn't understand AD much less
>> LDAP, etc. Imagine, an employee who can help themselves 90% of the time
>> ...
>>
>> Finding the diamond that has strong niche skill, networking, with a
>> broad&
>> just-deep-enough sysadmin background has been very, very hard. I cannot
>> emphasize enough the importance of cross-training. Immensely valuable.
>>
>> Randal
>>
>> On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewart<nonobvious at gmail.com>
>> wrote:
>>
>>>   And yeah, sometimes it means that you need to go
>>> learn technologies like Active Directory
>>>
>>   [snip]
>>
>>> In addition to learning scripting languages
>>>
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud
>> service.
>> For more information please visit http://www.symanteccloud.com
>> ______________________________________________________________________
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>
>
>


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 sakamura at gmail.com  Thu Dec  1 11:30:18 2011
From: sakamura at gmail.com (Ishmael Rufus)
Date: Thu, 1 Dec 2011 11:30:18 -0600
Subject: Broadband providers in downtown Chicago
Message-ID: <CAL-SDLHzrjHs3e+rwshNY0TS63CXCE=90D8d9wJz4JEca=1Aog@mail.gmail.com>

Our company is in a building at 200 w. Monroe and we have difficulty
finding an internet service provider that could at least provide
1Mbps+ Upload bandwidth that is not Cogent Communications.

Is it really this difficult finding a decent internet service provider
in downtown Chicago?


From david at davidradcliffe.org  Thu Dec  1 12:26:56 2011
From: david at davidradcliffe.org (David Radcliffe)
Date: Thu, 1 Dec 2011 13:26:56 -0500
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <4ED7A2C7.7010105@monmouth.com>
References: <CAJEFqDfht_k4wG3ev2m5uJWNhak16p=LMkPtJoBUSBmea+=uow@mail.gmail.com>
 <D181DDABABE57E4DB72FEE003314786444CC5E@EALPO1.ukbroadband.com>
 <4ED7A2C7.7010105@monmouth.com>
Message-ID: <201112011326.57351.david@davidradcliffe.org>

I keep running into cases where people do not know how to adequately use my 
talents so the compensation is too light...

Or they require relocation, even though the nature of the job is virtual 
(hands on not really required).

At least it is nice to see some folks out there who do need people like me.

Over the years I've been a (very good) coder, sysadmin, DBA, network engineer, 
etc. with strong Cisco and some Juniper (of course a couple days self training 
and I am pretty strong on anything).

I'm not a job hopper so I have to either really hate my position or get an 
offer too good to refuse, for me to change companies.

For me the "too good" includes things like telecommute (I am well set up for 
that), good salary/package (have that now..the salary part anyway), limited 
paperwork a plus (we pay you salary, you provide results...no pointy haired 
bosses here), a company who's motto is not "Panic! Because planning is just 
too much effort."

I guess my advice is:

Don't miss out on someone who might be your star employee just to keep doing 
things the old way.  Telecommuting can be very effective with the proper 
management tools.  Obviously, working from home is not for everyone so the 
employee needs to be dedicated to the process.

The best technical people can be quirky.  I once had a guy on my team who 
customers thought was rude so I had to handle sites where people had met him 
before.  I recognized he was desperately shy and did not deal with people 
well.  He was a very talented technician so rather than loose him I was able 
to redeploy his abilities to projects not involving humans.  Worked out well.

For me it's lists.  I do way better when I have lists I can check off.  I make 
lists for everything and get a warm feeling when I check off an items.  I like 
the word "check" because it brings up a picture in my head of a list with 
check marks.  Freaky, huh?

On Thursday, December 01, 2011 10:52:39 AM Mark Stevens wrote:
> It takes me years to find such people and when I do, I try very hard to
> keep them! I have 3 key people that fit the "soft" attribute criteria
> Randal mentioned, but with a premium skill set in their specific
> function. Good luck with your task Leigh!
> 
> Mark Stevens
> 
> On 12/1/2011 10:21 AM, Leigh Porter wrote:
> > I am looking for just such a person now. Good Juniper, some Cisco and
> > Sysadmin experience with an ISP background..
> > 
> > I expect it will be immensely difficult to find somebody. What makes it
> > even more frustrating is that just such a person was not all that long
> > ago made redundant!
> > 
> > So if anybody is looking for something to do around London...
> > 
> > --
> > Leigh
> > 
> >> -----Original Message-----
> >> From: randal k [mailto:nanog at data102.com]
> >> Sent: 01 December 2011 15:19
> >> To: Bill Stewart
> >> Cc: nanog at nanog.org
> >> Subject: Re: Looking for a Tier 1 ISP Mentor for career advice.
> >> 
> >> This is a huge point. We've had a LOT of trouble finding good network
> >> engineers who have all of the previously mentioned "soft" attributes -
> >> attitude, team player, can write, can speak, can run a small project -
> >> and
> >> are more than just Cisco pimps. I cannot explain how frustrating it is
> >> to
> >> meet a newly minted CCNP who has zero Linux experience, can't script
> >> anything, can't setup a syslog server, doesn't understand AD much less
> >> LDAP, etc. Imagine, an employee who can help themselves 90% of the time
> >> ...
> >> 
> >> Finding the diamond that has strong niche skill, networking, with a
> >> broad&
> >> just-deep-enough sysadmin background has been very, very hard. I cannot
> >> emphasize enough the importance of cross-training. Immensely valuable.
> >> 
> >> Randal
> >> 
> >> On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewart<nonobvious at gmail.com>
> >> 
> >> wrote:
> >>>   And yeah, sometimes it means that you need to go
> >>> 
> >>> learn technologies like Active Directory
> >>> 
> >>   [snip]
> >>> 
> >>> In addition to learning scripting languages
> >> 
> >> ______________________________________________________________________
> >> This email has been scanned by the Symantec Email Security.cloud
> >> service.
> >> For more information please visit http://www.symanteccloud.com
> >> ______________________________________________________________________
> > 
> > ______________________________________________________________________
> > This email has been scanned by the Symantec Email Security.cloud service.
> > For more information please visit http://www.symanteccloud.com
> > ______________________________________________________________________

-- 
David Radcliffe
Network Engineer/Linux Specialist
david at davidradcliffe.org
www.davidradcliffe.org

Nothing ever gets solved better with panic.
If you do not know the answer, it is probably "42."


From surfer at mauigateway.com  Thu Dec  1 12:47:22 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Thu, 1 Dec 2011 10:47:22 -0800
Subject: Looking for a Tier 1 ISP Mentor for career advice.
Message-ID: <20111201104722.F5796A6A@resin09.mta.everyone.net>




---- On 12/1/2011 10:21 AM, Leigh Porter wrote: ---------
> I am looking for just such a person now. Good Juniper, some Cisco and Sysadmin experience with an ISP background..
[...]
> So if anybody is looking for something to do around London...
-----------------------------------------------------


Something I'd like to tell hiring folks lurking out there based on my 
experiences from living on an island far from population centers where 
all the jobs are...  :-)

One way to get such folks, as described in the previous posts, is to allow 
telecommuting.  Have them come into the main office immediately after hiring 
them for 3-4 months, evaluate them and show them what's expected.  Then let 
them go home to telecommute and have them come into the office a couple/few 
times a year for a week or two each time.  They can even be required to work 
the same hours as the location where all the other engineers are.  Or, on the 
big networks folks living in places like Hawaii can be the carry-over shift
from US timezone to Asian timezones.  This allows for a more productive 
employee many times because they are enjoying life where they live, rather 
than be forced into the larger population centers.

In our industry, especially with all the tools we have today, it would seem 
that telecommuting would be more accepted, but it's not and I don't understand 
why.

scott


From olivier.benghozi at wifirst.fr  Thu Dec  1 13:03:06 2011
From: olivier.benghozi at wifirst.fr (Olivier Benghozi)
Date: Thu, 1 Dec 2011 20:03:06 +0100
Subject: bgp update destroying transit on redback routers ?
Message-ID: <A895B3BA-D2F6-4491-9740-96174A710C40@wifirst.fr>

Alexandre Snarskii <snar at snar.spb.ru> wrote:
> AGGREGATOR is an optional transitive attribute of length 6.
>             The attribute contains the last AS number that formed the
>             aggregate route (encoded as 2 octets), followed by the IP
>             address of the BGP speaker that formed the aggregate route
>             (encoded as 4 octets).  Usage of this attribute is described
>             in 5.1.7
> 
> And what to do with 4-byte AS-numbers then? That would explain the 8 bytes.


Hi,

we also have some issues with this here, the update message the Redback logged is:

ffff ffff
ffff ffff
ffff ffff
ffff ffff
0049  02
0000
002e
4001 01 00
4002 12   02   04   00000513  00000d1c  0000b611  0000b611
4003 04 50ef82c1
4006 00
c007 08 00 0000 0000 0000 00
16 ce7d a4


The prefix is 206.125.164.0/22, AS-PATH is 1299 3356 46609 46609 (Telia, Level3, and finally Hostlogistic with one prepend).
The AGGREGATOR is full of 0. I guess this could be what bothers the Redback/Ericsson code.

I see the same route by other sessions, and the aggregator looks OK, since the sh bgp says:

206.125.164.0/22
[...]
8218 4436 46609 46609
[...]
  Origin incomplete, localpref 100, med 100, weight 100, external, best
  aggregator: 206.125.165.242, AS 46609, atomic-aggregate


So Hostlogistic route to Level3 is malformed (according to the RFC, the AGGREGATOR content is mandatory if the attribute is present), but their route to NLayer is OK. Or maybe a Level3 router has a problem?
Anyway, our Redback/Ericsson routers are the problem now, since the other vendors don't throw away the BGP sessions...
I've opened a case at Ericsson, still waiting for an answer :-/


regards,
Olivier Benghozi
Wifirst



From igor at ergens.org  Thu Dec  1 13:06:29 2011
From: igor at ergens.org (Igor Ybema)
Date: Thu, 1 Dec 2011 20:06:29 +0100
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <A895B3BA-D2F6-4491-9740-96174A710C40@wifirst.fr>
References: <A895B3BA-D2F6-4491-9740-96174A710C40@wifirst.fr>
Message-ID: <CANwiKaa9eh2c+coWp4e80A1SDz7QdSXBFAWWA_zTVPL4+SMOiQ@mail.gmail.com>

> So Hostlogistic route to Level3 is malformed (according to the RFC, the AGGREGATOR content is mandatory if the attribute is present), but their route to NLayer is OK. Or maybe a Level3 router has a problem?
> Anyway, our Redback/Ericsson routers are the problem now, since the other vendors don't throw away the BGP sessions...
> I've opened a case at Ericsson, still waiting for an answer :-/

Correct. This was pointed out to me just now off-list by another reader.
Ericsson coder also contacted me and noted that is fixed a few months
ago, but he is not sure which release has the fix. I hope he will
respond on-list about this for everyone to read.

regards, Igor


From frnkblk at iname.com  Thu Dec  1 13:42:31 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 1 Dec 2011 13:42:31 -0600
Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down
 for 10 days
In-Reply-To: <E1DD60718964C54A96C04CA9CB0BA81101E8136F8301@server3.MUTUALTEL.MTCNET.NET>
References: <000001cc5d68$93fc01d0$bbf40570$@iname.com>
 <0C6A4A8DD60DBF4A99C300DDA771BFAB01E8192746C7@server3.MUTUALTEL.MTCNET.NET>
 <E1DD60718964C54A96C04CA9CB0BA81101E8136F8301@server3.MUTUALTEL.MTCNET.NET>
Message-ID: <000a01ccb061$5d60c100$18224300$@iname.com>

AAAA and IPv6 access to www.centurylink.com were restored around 11:30 am
U.S. Central.

Frank

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

Well, sometime yesterday www.centurylink.com removed it AAAA record(s).

www.qwest.com still has them.

Frank

-----Original Message-----
From: Frank Bulk [mailto:frnkblk at iname.com] 
Sent: Monday, October 24, 2011 1:47 PM
To: 'nanog at nanog.org'
Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down
for 10 days

Good news: access to the v6 version of www.qwest.com came up at 12:30 pm
today -- it redirects to www.centurylink.com, but at least it's working.

Only www.savvis.com remains in my list of service provider websites that
have non-working IPv6.

Frank

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

The IPv6 version of www.qwest.com has been down for 10 days.  Wget shows a
301 to www.centurylink.com, but that also fails.  Emails to the nocs at both
companies have gone unanswered.  Unless HE is deployed in a web browser,
this behavior leads to a bad end-user experience.

If anyone can prod either of these two companies that would be much
appreciated.

Frank


nagios:/home/fbulk# wget -6 www.qwest.com
--2011-08-18 00:32:40--  http://www.qwest.com/
Resolving www.qwest.com... 2001:428:b21:1::20
Connecting to www.qwest.com|2001:428:b21:1::20|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.centurylink.com/ [following]
--2011-08-18 00:32:40--  http://www.centurylink.com/
Resolving www.centurylink.com... 2001:428:b21:1::22
Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed:
Connection timed out.
Retrying.

--2011-08-18 00:33:02--  (try: 2)  http://www.centurylink.com/
Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed:
Connection timed out.
Retrying.

--2011-08-18 00:33:25--  (try: 3)  http://www.centurylink.com/
Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed:
Connection timed out.
Retrying.

--2011-08-18 00:33:49--  (try: 4)  http://www.centurylink.com/
Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed:
Connection timed out.
Retrying.

Etc...





From jsw at inconcepts.biz  Thu Dec  1 14:13:51 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Thu, 1 Dec 2011 15:13:51 -0500
Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS
 networks?
In-Reply-To: <20111201144207.GN9465@angus.ind.WPI.EDU>
References: <DEBECAC9A6D5224D95078F3CDC36225809C431@TKMNAEXCH.thyssenna.com>
 <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com>
 <4ED52053.5040102@bogus.com>
 <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com>
 <CAAAwwbU4upBZWmXiixWAXYmfAg5_DydytDBLjOZ3MNHGmDR3xQ@mail.gmail.com>
 <CALFTrnNFjFZtmWay4T4ASYbZZf0vcaaUVc7G=sLEyV78qKBAgw@mail.gmail.com>
 <CAPWAtbJVXyg4xx77tvO5UASyLMhL8-OUkwA3dYawqDPx=0pO-Q@mail.gmail.com>
 <CALFTrnPtuihjLdpqLw9LzicLmHyuRnfT=2Lw_P+h7YCffNtbcA@mail.gmail.com>
 <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com>
 <CAAAwwbVJsE2okH8RzefZFYngx49-vgH3nq+cuTk8woz7u32NwA@mail.gmail.com>
 <20111201144207.GN9465@angus.ind.WPI.EDU>
Message-ID: <CAPWAtbKEjn2Wej51yrj_J5hPsfUkyFmKrHuX87Mm579H+MFKkA@mail.gmail.com>

On Thu, Dec 1, 2011 at 9:42 AM, Chuck Anderson <cra at wpi.edu> wrote:
> Jumping in here, how about static ND entries? ?Then you can use the
> /64 for P-t-P, but set the few static ND entries you need, and turn
> off dynamic ND. ?An out-of-band provisioning system could add static
> ND entries as needed.
>
> Another idea, perhaps more useful for client LANs, would be to have a
> fixed mapping between IPv6 IID and MAC address. ?Use DHCPv6 to force

Chuck, you are certainly correct that if ND resolution can be
deactivated for an interface, there won't be an ND exhaustion problem
on it.  That's why I characterize the problem as ND exhaustion.  :-)
Whether or not this is practical for a given environment is up to the
operators to decide.

I, for example, know it is much easier for me to configure a /126
P-t-P than keep static ND entries and disable ND on those links.  In
my own backbone, your suggestion can be practical, but what about
customer links?  If the customer changes his device, he may present a
different MAC address to my interface.  Then I've got a static ND
entry pointing to his old MAC address... resulting in a ticket, and
ops work, which would not have been necessary with a simple /126.

DHCPv6 with snooping and learning disabled would be great for the
datacenter LAN if I thought I could get customers to bite off on it.
When vendors begin delivering this feature it is something we will
strongly consider.  I don't know if customers will prefer to have this
and need to run a DHCPv6 client, or prefer to have a /120 (or similar)
for the approximate number of addresses they plan to use.

I am not closed to alternatives.  I want to give my customers /64s as
soon as it becomes practical and production-ready.  That is why we
always reserve a /64 for each subnet, even though it is provisioned as
a longer subnet.

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


From igor at ergens.org  Thu Dec  1 14:15:48 2011
From: igor at ergens.org (Igor Ybema)
Date: Thu, 1 Dec 2011 21:15:48 +0100
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
Message-ID: <CANwiKaYraWPd9WxFs5PDad3Jr+xgXP_+tFk0Wt84u1bRduD4yQ@mail.gmail.com>

Hi all,

A new update. A coder from ericsson told me that the problem is not
4-byte asn related. It is related to aggregator-asn=0 and
aggregator-ip=0.0.0.0. Ericsson does not accept this as valid ASN and
IP-address.

The question is now, are all other vendors wrong in accepting this
attribute (clearly ASN=0 and IP=0.0.0.0 isn't corresponding to the RFC
stating 'which shall contain its own AS number and IP address') or is
Ericsson being to strict?

regards, Igor


From morrowc.lists at gmail.com  Thu Dec  1 14:19:22 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 1 Dec 2011 15:19:22 -0500
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <CANwiKaYraWPd9WxFs5PDad3Jr+xgXP_+tFk0Wt84u1bRduD4yQ@mail.gmail.com>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
 <CANwiKaYraWPd9WxFs5PDad3Jr+xgXP_+tFk0Wt84u1bRduD4yQ@mail.gmail.com>
Message-ID: <CAL9jLabVYZGmRGeeseFNKM0-8THPGBb3pudHNomJp2Ptd9DtsA@mail.gmail.com>

On Thu, Dec 1, 2011 at 3:15 PM, Igor Ybema <igor at ergens.org> wrote:
> Hi all,
>
> A new update. A coder from ericsson told me that the problem is not
> 4-byte asn related. It is related to aggregator-asn=0 and
> aggregator-ip=0.0.0.0. Ericsson does not accept this as valid ASN and
> IP-address.
>
> The question is now, are all other vendors wrong in accepting this
> attribute (clearly ASN=0 and IP=0.0.0.0 isn't corresponding to the RFC
> stating 'which shall contain its own AS number and IP address') or is
> Ericsson being to strict?

<http://tools.ietf.org/html/draft-wkumari-idr-as0-01>

one of the reasons the above was written...

>
> regards, Igor
>


From igor at ergens.org  Thu Dec  1 14:23:16 2011
From: igor at ergens.org (Igor Ybema)
Date: Thu, 1 Dec 2011 21:23:16 +0100
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <CAL9jLabVYZGmRGeeseFNKM0-8THPGBb3pudHNomJp2Ptd9DtsA@mail.gmail.com>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
 <CANwiKaYraWPd9WxFs5PDad3Jr+xgXP_+tFk0Wt84u1bRduD4yQ@mail.gmail.com>
 <CAL9jLabVYZGmRGeeseFNKM0-8THPGBb3pudHNomJp2Ptd9DtsA@mail.gmail.com>
Message-ID: <CANwiKab+5VdjJz7vYMXx9G9B4WHNOqN0ymxQNTxc2eWomGdTag@mail.gmail.com>

> <http://tools.ietf.org/html/draft-wkumari-idr-as0-01>
>
> one of the reasons the above was written...

That does not include when ASN=0 is used in the aggregator attribute.
Could you add that?

regards, Igor


From morrowc.lists at gmail.com  Thu Dec  1 14:36:26 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 1 Dec 2011 15:36:26 -0500
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <CANwiKab+5VdjJz7vYMXx9G9B4WHNOqN0ymxQNTxc2eWomGdTag@mail.gmail.com>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
 <CANwiKaYraWPd9WxFs5PDad3Jr+xgXP_+tFk0Wt84u1bRduD4yQ@mail.gmail.com>
 <CAL9jLabVYZGmRGeeseFNKM0-8THPGBb3pudHNomJp2Ptd9DtsA@mail.gmail.com>
 <CANwiKab+5VdjJz7vYMXx9G9B4WHNOqN0ymxQNTxc2eWomGdTag@mail.gmail.com>
Message-ID: <CAL9jLaaoP5JnOZqW-y-bYoKrXJP_zmAhdcaGKrHY0fDrA9sTxA@mail.gmail.com>

On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema <igor at ergens.org> wrote:
>> <http://tools.ietf.org/html/draft-wkumari-idr-as0-01>
>>
>> one of the reasons the above was written...
>
> That does not include when ASN=0 is used in the aggregator attribute.
> Could you add that?

that's a warren question...


From dave at temk.in  Thu Dec  1 14:42:11 2011
From: dave at temk.in (Dave Temkin)
Date: Thu, 01 Dec 2011 15:42:11 -0500
Subject: [NANOG-announce] NANOG54 (San Diego, Feb 5-8,
 2012): Early Bird Registration Expiring on Sunday, 12/4
Message-ID: <4ED7E6A3.2020703@temk.in>

Please note that the Early Bird registration for NANOG54 expires on Sunday, 12/4.  Register now and save $75 
off the regular registration fee!

Also, as a reminder, the Call for Presentations is still open!  Have something that you think is relevant to 
the NANOG community and would like to have the chance to present it?  Please see 
http://www.nanog.org/meetings/nanog54/callforpresentations.html for more information.

Looking forward to seeing you in sunny San Diego!

-Dave
(For the NANOG Program Committee)


_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce


From david at davidradcliffe.org  Thu Dec  1 15:35:27 2011
From: david at davidradcliffe.org (David Radcliffe)
Date: Thu, 1 Dec 2011 16:35:27 -0500
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <20111201104722.F5796A6A@resin09.mta.everyone.net>
References: <20111201104722.F5796A6A@resin09.mta.everyone.net>
Message-ID: <201112011635.27951.david@davidradcliffe.org>

The reason it is not more accepted is too many people still think "If I cannot 
see you you must not be working."

Since I like to work and code (I spend 10 hours a day on the computer at the 
office, think about work related stuff in the shower, and often write Perl code 
at home to deal with various household tasks) I work quite well at home.  
There are more distractions at the office and my productivity is greater in my 
home computer room during those times I have to put in some extra for the 
office.

Actually, the best reason I have for working from home is I work much better 
when naked and they have asked me to stop showing up that way at the office.

On Thursday, December 01, 2011 01:47:22 PM Scott Weeks wrote:
> ---- On 12/1/2011 10:21 AM, Leigh Porter wrote: ---------
> 
> > I am looking for just such a person now. Good Juniper, some Cisco and
> > Sysadmin experience with an ISP background..
> 
> [...]
> 
> > So if anybody is looking for something to do around London...
> 
> -----------------------------------------------------
> 
> 
> Something I'd like to tell hiring folks lurking out there based on my
> experiences from living on an island far from population centers where
> all the jobs are...  :-)
> 
> One way to get such folks, as described in the previous posts, is to allow
> telecommuting.  Have them come into the main office immediately after
> hiring them for 3-4 months, evaluate them and show them what's expected. 
> Then let them go home to telecommute and have them come into the office a
> couple/few times a year for a week or two each time.  They can even be
> required to work the same hours as the location where all the other
> engineers are.  Or, on the big networks folks living in places like Hawaii
> can be the carry-over shift from US timezone to Asian timezones.  This
> allows for a more productive employee many times because they are enjoying
> life where they live, rather than be forced into the larger population
> centers.
> 
> In our industry, especially with all the tools we have today, it would seem
> that telecommuting would be more accepted, but it's not and I don't
> understand why.
> 
> scott

-- 
David Radcliffe
Network Engineer/Linux Specialist
david at davidradcliffe.org
www.davidradcliffe.org

Nothing ever gets solved better with panic.
If you do not know the answer, it is probably "42."


From jeff.tantsura at ericsson.com  Thu Dec  1 15:56:43 2011
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Thu, 1 Dec 2011 16:56:43 -0500
Subject: bgp update destroying transit on redback routers ?
Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>

Hi,

Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols.
There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds.

To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yakov about it, without any results though. 
So for those who have it configured - please rethink whether you really need it.

As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code.
Patch will be made available.

Please contact me for any further clarifications.

Regards,
Jeff

P.S. Warren has recently  included AGGREGATOR in the draft, please see

 2. Behavior
   This document specifies that a BGP speaker MUST NOT originate or
   propagate a route with an AS number of zero.  If a BGP speaker
   receives a route which has an AS number of zero in the AS_PATH (or
   AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
   This same behavior applies to routes containing zero as the
   Aggregator or AS4 Aggregator.



From bmanning at vacation.karoshi.com  Thu Dec  1 16:22:12 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 1 Dec 2011 22:22:12 +0000
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <201112011635.27951.david@davidradcliffe.org>
References: <20111201104722.F5796A6A@resin09.mta.everyone.net>
 <201112011635.27951.david@davidradcliffe.org>
Message-ID: <20111201222212.GA5671@vacation.karoshi.com.>

On Thu, Dec 01, 2011 at 04:35:27PM -0500, David Radcliffe wrote:
> The reason it is not more accepted is too many people still think "If I cannot 
> see you you must not be working."
> 

	actually, i've heard the real reason is corporate liability ...
	that said, there is an advantage for team f2f mtgs on a periodic
	basis.

/bill


From warren at kumari.net  Thu Dec  1 17:04:52 2011
From: warren at kumari.net (Warren Kumari)
Date: Thu, 1 Dec 2011 18:04:52 -0500
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <CAL9jLaaoP5JnOZqW-y-bYoKrXJP_zmAhdcaGKrHY0fDrA9sTxA@mail.gmail.com>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
 <CANwiKaYraWPd9WxFs5PDad3Jr+xgXP_+tFk0Wt84u1bRduD4yQ@mail.gmail.com>
 <CAL9jLabVYZGmRGeeseFNKM0-8THPGBb3pudHNomJp2Ptd9DtsA@mail.gmail.com>
 <CANwiKab+5VdjJz7vYMXx9G9B4WHNOqN0ymxQNTxc2eWomGdTag@mail.gmail.com>
 <CAL9jLaaoP5JnOZqW-y-bYoKrXJP_zmAhdcaGKrHY0fDrA9sTxA@mail.gmail.com>
Message-ID: <B532EA73-026A-4ADD-93BC-9DB100E2BF97@kumari.net>


On Dec 1, 2011, at 3:36 PM, Christopher Morrow wrote:

> On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema <igor at ergens.org> wrote:
>>> <http://tools.ietf.org/html/draft-wkumari-idr-as0-01>
>>> 
>>> one of the reasons the above was written...
>> 
>> That does not include when ASN=0 is used in the aggregator attribute.
>> Could you add that?
> 
> that's a warren question...

http://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it.

Thanks all,
W



From jeff.tantsura at ericsson.com  Thu Dec  1 18:01:42 2011
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Thu, 1 Dec 2011 19:01:42 -0500
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <B532EA73-026A-4ADD-93BC-9DB100E2BF97@kumari.net>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
 <CANwiKaYraWPd9WxFs5PDad3Jr+xgXP_+tFk0Wt84u1bRduD4yQ@mail.gmail.com>
 <CAL9jLabVYZGmRGeeseFNKM0-8THPGBb3pudHNomJp2Ptd9DtsA@mail.gmail.com>
 <CANwiKab+5VdjJz7vYMXx9G9B4WHNOqN0ymxQNTxc2eWomGdTag@mail.gmail.com>
 <CAL9jLaaoP5JnOZqW-y-bYoKrXJP_zmAhdcaGKrHY0fDrA9sTxA@mail.gmail.com>
 <B532EA73-026A-4ADD-93BC-9DB100E2BF97@kumari.net>
Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C256342@EUSAACMS0701.eamcs.ericsson.se>

Thanks Warren!
I have already brought this to the list.

Regards,
Jeff


-----Original Message-----
From: Warren Kumari [mailto:warren at kumari.net] 
Sent: Thursday, December 01, 2011 3:05 PM
To: Christopher Morrow
Cc: nanog at nanog.org
Subject: Re: bgp update destroying transit on redback routers ?


On Dec 1, 2011, at 3:36 PM, Christopher Morrow wrote:

> On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema <igor at ergens.org> wrote:
>>> <http://tools.ietf.org/html/draft-wkumari-idr-as0-01>
>>> 
>>> one of the reasons the above was written...
>> 
>> That does not include when ASN=0 is used in the aggregator attribute.
>> Could you add that?
> 
> that's a warren question...

http://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it.

Thanks all,
W




From tom+nanog at oneshoeco.com  Thu Dec  1 18:26:43 2011
From: tom+nanog at oneshoeco.com (Tom Lanyon)
Date: Fri, 2 Dec 2011 10:56:43 +1030
Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64:
 are they possible in DOCSIS networks?)
In-Reply-To: <CAAAas8Hu5HLVjf+Xx9edF_J_fTm8JmSFnGsSQJVb405y3htr=Q@mail.gmail.com>
References: <CAAAas8Hu5HLVjf+Xx9edF_J_fTm8JmSFnGsSQJVb405y3htr=Q@mail.gmail.com>
Message-ID: <3C80F0BD-1B61-4664-8B7E-F29C90C664CF@oneshoeco.com>

Hi,

On 01/12/2011, at 12:45 PM, Mike Jones wrote:
> Link-Local?
> [snip]
> Am I a complete idiot missing some obvious major issues with link
> locals, or am i just the only one not thinking IPv4-think? Opinions?
> :)


In a DC / hosting provider context, we're doing this.

We started out assigning all of our PtP links (where we had /31s in the IPv4 world) IPv6 /64s and addressing using ::1 and ::2 with /127 masks from these /64s (to address potential ND table overflow concerns), but have now settled on using automatic link-local addresses instead.

Our IGP propagates the routers' /128 loopbacks and these are used for routing user traffic.

Having the IGP table only contain the /128 loopbacks, and none of the PtP networks is nice. :)


On 01/12/2011, at 12:52 PM, Ray Soucy wrote:
> I for one get really irritated when my traceroutes and pings are
> broken and I need to troubleshoot things. ;-)  But I guess something
> has to give.

You don't have to give up working traceroute / ping to use link-local on your PtPs.  

Our traffic routes through globally reachable router loopbacks which looks pretty in traceroutes, are pingable and doesn't break PMTUD.

Tom



From John_Brzozowski at Cable.Comcast.com  Thu Dec  1 20:33:43 2011
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Fri, 2 Dec 2011 02:33:43 +0000
Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS
 networks?
In-Reply-To: <CAP5kh1B4oPCu5c6L7iKC6qPOhGLj6bYdQRucmhJ23VFzgMMFhg@mail.gmail.com>
Message-ID: <CAFCDCE8.1B8FD0%john_brzozowski@cable.comcast.com>

See below.


On 12/1/11 5:11 AM, "Dmitry Cherkasov" <doctorchd at gmail.com> wrote:

>John,
>
>Due to your note I carefully read again Cable Labs specs and found
>that really SLAAC is not prohibited. According to CM-SP-MULPIv3.0:
[jjmb] I was part of the team that wrote IPv6 for DOCSIS, so I know the
history well.  ;)

>
>* If the M bit in the RA is set to 1, the CM (cable modem) MUST use
>DHCPv6 ...;
>* If there are no prefix information options in the RA, the CM MUST
>NOT perform SLAAC;
[jjmb] even if there are PIOs and the A bit is set to 0, the CM will
not/must not perform SLAAC.

>* If the RA contains a prefix advertisement with the A bit set to 0,
>the CM MUST NOT perform SLAAC on that prefix.
[jjmb] yes, see above.
>
>That means that if M bit in the RA is set to 0 and RA contains a
>prefix advertisement with the A bit set to 1 nothing prevents CM from
>SLAAC.
[jjmb] correct.

>And if so we probably better reserve /64 per network just in case we
>may use SLAAC in it in the future. While we do not use SLAAC we can
>shorten the range of actually used IPv6 addresses by using longer then
>/64 prefix.
[jjmb] I suppose, again not sure why you would want to take this route.
This also assumes no PIOs in the RA.  Please note there are other
operational reason why SLAAC is not a truly deployable alternative.  We
can discuss off list if you are interested.
>
>You are completely right that prefix delegation enforce DHCPv6 so
>SLAAC mentioned above can be used only for CMs, not for CPE.
[jjmb] similar to cable modems, CPEs that only request or require IA_NA
could conceivably use SLAAC.  Same caveat and comments as above.

>
>Just a note: as far as I can see available DOCSIS 3.0 CMTSes do not
>support the ability of SLAAC for CMs currently (checked Casa and Cisco
>uBR10K).
[jjmb] I am sure you make it work on at least one of the above. :)
>
>
>Dmitry Cherkasov
>
>
>
>2011/11/30 Brzozowski, John <John_Brzozowski at cable.comcast.com>:
>> Technically this is not true.  SLAAC is not prohibited, it does come
>>with
>> side affects that complicate the deployment of IPv6.  It is technically
>> feasible to use SLAAC, it is just not practical in most cases.
>>
>> Stateful DHCPv6 is the preferred mechanism for address and configuration
>> assignment.  Prefix delegation requires the use of stateful DHCPv6 in
>> DOCSIS networks.
>>
>> John
>> =========================================
>> John Jason Brzozowski
>> Comcast Cable
>> e) mailto:john_brzozowski at cable.comcast.com
>> o) 609-377-6594
>> m) 484-962-0060
>> w) http://www.comcast6.net
>> =========================================
>>
>>
>>
>>
>> On 11/29/11 7:09 AM, "Dmitry Cherkasov" <doctorchd at gmail.com> wrote:
>>
>>>Steven,
>>>
>>>SLAAC is prohibited for using in DOCSIS networks, router
>>>advertisements that allow SLAAC must be ignored by end-devices,
>>>therefore DHCPv6 is the only way of configuring (if not talking about
>>>statical assignment). I have seen at least Windows7 handling this
>>>properly in its default configuration: it starts DHCPv6 negotiation
>>>instead of auto-configuration.
>>>
>>>Dmitry Cherkasov
>>>
>>>
>>>
>>>2011/11/29 Steven Bellovin <smb at cs.columbia.edu>:
>>>>
>>>> On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
>>>>
>>>>>
>>>>> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
>>>>>
>>>>>> It's a good practice to reserve a 64-bit prefix for each network.
>>>>>> That's a good general rule.  For point to point or link networks you
>>>>>> can use something as small as a 126-bit prefix (we do).
>>>>>>
>>>>>
>>>>> Technically, absent buggy {firm,soft}ware, you can use a /127.
>>>>>There's
>>>>>no
>>>>> actual benefit to doing anything longer than a /64 unless you have
>>>>> buggy *ware (ping pong attacks only work against buggy *ware),
>>>>> and there can be some advantages to choosing addresses other than
>>>>> ::1 and ::2 in some cases. If you're letting outside packets target
>>>>>your
>>>>> point-to-point links, you have bigger problems than neighbor table
>>>>> attacks. If not, then the neighbor table attack is a bit of a
>>>>>red-herring.
>>>>>
>>>>
>>>> The context is DOCSIS, i.e., primarily residential cable modem users,
>>>>and
>>>> the cable company ISPs do not want to spend time on customer care and
>>>> hand-holding.  How are most v6 machines configured by default?  That
>>>>is,
>>>> what did Microsoft do for Windows Vista and Windows 7?  If they're set
>>>>for
>>>> stateless autoconfig, I strongly suspect that most ISPs will want to
>>>>stick
>>>> with that and hand out /64s to each network.  (That's apart from the
>>>>larger
>>>> question of why they should want to do anything else...)
>>>>
>>>>
>>>>                --Steve Bellovin, https://www.cs.columbia.edu/~smb
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>



From malayter at gmail.com  Thu Dec  1 20:57:58 2011
From: malayter at gmail.com (Ryan Malayter)
Date: Thu, 1 Dec 2011 18:57:58 -0800 (PST)
Subject: Broadband providers in downtown Chicago
In-Reply-To: <CAL-SDLHzrjHs3e+rwshNY0TS63CXCE=90D8d9wJz4JEca=1Aog@mail.gmail.com>
References: <CAL-SDLHzrjHs3e+rwshNY0TS63CXCE=90D8d9wJz4JEca=1Aog@mail.gmail.com>
Message-ID: <681d5b9d-cc1d-4238-9972-73f381b8f282@w1g2000vba.googlegroups.com>



On Dec 1, 11:30?am, Ishmael Rufus <sakam... at gmail.com> wrote:
> Our company is in a building at 200 w. Monroe and we have difficulty
> finding an internet service provider that could at least provide
> 1Mbps+ Upload bandwidth that is not Cogent Communications.
>
> Is it really this difficult finding a decent internet service provider
> in downtown Chicago?

No, it isn't. Unless your building management has an exclusive deal
with Cogent. We have our choice of basically every national Tier-1 and
all the larger regional players around the corner on Monroe.


From wayne at staff.msen.com  Thu Dec  1 22:04:23 2011
From: wayne at staff.msen.com (Michael R. Wayne)
Date: Thu, 1 Dec 2011 23:04:23 -0500
Subject: IP addresses are now assets
Message-ID: <20111202040423.GL1397@manor.msen.com>

>From http://www.detnews.com/article/20111201/BIZ/112010483/1361/Borders-selling-Internet-addresses-for-$786-000

   Borders selling Internet addresses for $786,000

   Bill Rochelle/ Bloomberg News

   Borders Group Inc., the liquidated Ann Arbor-based bookseller, will
   generate $786,000 by selling Internet addresses, thanks to the
   current shortage.

   In September, Borders was authorized to sell most of the intellectual
   property to Barnes & Noble Inc. for $13.9 million. Borders' block
   of 65,536 IPv4 Internet protocol numbers weren't sold.

   After negotiating with multiple prospective buyers, Cerner Corp.
   agreed to buy the Internet addresses for $12 each. Other bids were
   as low as $1.50 each, according to a bankruptcy court filing.

   The sale to Cerner is scheduled for approval at the Dec. 20 hearing
   where Borders also hopes the bankruptcy court will confirm the
   liquidating Chapter 11 plan. The plan distributes assets in the
   order of priority called for in bankruptcy law.

   The disclosure statement says unsecured creditors with $812 million
   to $850 million in claims can expect to recover from 4 percent to
   10 percent. The projected recovery doesn't include proceeds from
   lawsuits.

   Borders completed liquidating the remaining stores in September and
   separately sold store leases and intellectual property.

   Borders had 642 stores on entering bankruptcy in February and was
   operating 399 when the final liquidations began. It listed assets
   of $1.28 billion and liabilities totaling $1.29 billion.


From jcurran at arin.net  Thu Dec  1 23:20:39 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 2 Dec 2011 05:20:39 +0000
Subject: IP addresses are now assets
Message-ID: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>

Wayne - 

Your subject line (IP addresses are now assets) could mislead folks, 
so I'd advise waiting to review the actual sale order once approved by
the court before making summary conclusions.  

ARIN holds that IP address space is not property but is managed as a 
public resource.  Address holders may have certain rights (such as the 
right to be the registrant of the address block, the right to transfer the 
registration, etc.) but these rights intersect with additional rights to the 
same address blocks which are held by the community (such as the right
of visibility to the public portion of registrations).  The registry policies 
(set by the community via open and transparent processes) govern the 
intersection and application of these rights.

For this reason, ARIN works with parties transferring their rights in IP 
address space to make sure that the documents reflect that sales of
rights are subject to the transfer policies in the region, including in this 
particular case.  A party may transfer their rights to IP addresses, and
such rights may have value to an estate, but this does not make the 
IP addresses "property" per se.

Thanks!
/John

John Curran
President and CEO
ARIN





From paul at paulgraydon.co.uk  Thu Dec  1 23:55:56 2011
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Thu, 01 Dec 2011 19:55:56 -1000
Subject: IP addresses are now assets
In-Reply-To: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
Message-ID: <4ED8686C.6020803@paulgraydon.co.uk>

On 12/1/2011 7:20 PM, John Curran wrote:
> Wayne -
>
> Your subject line (IP addresses are now assets) could mislead folks,
> so I'd advise waiting to review the actual sale order once approved by
> the court before making summary conclusions.
>
> ARIN holds that IP address space is not property but is managed as a
> public resource.  Address holders may have certain rights (such as the
> right to be the registrant of the address block, the right to transfer the
> registration, etc.) but these rights intersect with additional rights to the
> same address blocks which are held by the community (such as the right
> of visibility to the public portion of registrations).  The registry policies
> (set by the community via open and transparent processes) govern the
> intersection and application of these rights.
>
> For this reason, ARIN works with parties transferring their rights in IP
> address space to make sure that the documents reflect that sales of
> rights are subject to the transfer policies in the region, including in this
> particular case.  A party may transfer their rights to IP addresses, and
> such rights may have value to an estate, but this does not make the
> IP addresses "property" per se.
>
> Thanks!
> /John
>

Why'd you have to spoil the fun?  You're supposed to wait a few days, 
let the pointless righteous fury build up and then step in and try to do 
the firefighting thing.  It's must have been all but a month since the 
last time this flared up, it's surely about time it flared up again?  
Wouldn't want anyone to miss out on the fun ;)

Paul


From Valdis.Kletnieks at vt.edu  Fri Dec  2 01:48:31 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 02 Dec 2011 02:48:31 -0500
Subject: IP addresses are now assets
In-Reply-To: Your message of "Fri, 02 Dec 2011 05:20:39 GMT."
 <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
Message-ID: <44762.1322812111@turing-police.cc.vt.edu>

On Fri, 02 Dec 2011 05:20:39 GMT, John Curran said:
> ARIN holds that IP address space is not property but is managed as a
> public resource.  Address holders may have certain rights (such as the
> right to be the registrant of the address block, the right to transfer the
> registration, etc.) but these rights intersect with additional rights to the
> same address blocks which are held by the community (such as the right
> of visibility to the public portion of registrations).  The registry policies
> (set by the community via open and transparent processes) govern the
> intersection and application of these rights.

Would it be correct to summarize the ARIN position as "It's murkier than Cerner
makes it out to be, and some lawyers are gonna get stinking filthy rich
litigating this one"?

:)

-------------- 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/20111202/cbe841c3/attachment.bin>

From rjs at rob.sh  Fri Dec  2 01:55:29 2011
From: rjs at rob.sh (Rob Shakir)
Date: Fri, 2 Dec 2011 07:55:29 +0000
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <B532EA73-026A-4ADD-93BC-9DB100E2BF97@kumari.net>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
 <CANwiKaYraWPd9WxFs5PDad3Jr+xgXP_+tFk0Wt84u1bRduD4yQ@mail.gmail.com>
 <CAL9jLabVYZGmRGeeseFNKM0-8THPGBb3pudHNomJp2Ptd9DtsA@mail.gmail.com>
 <CANwiKab+5VdjJz7vYMXx9G9B4WHNOqN0ymxQNTxc2eWomGdTag@mail.gmail.com>
 <CAL9jLaaoP5JnOZqW-y-bYoKrXJP_zmAhdcaGKrHY0fDrA9sTxA@mail.gmail.com>
 <B532EA73-026A-4ADD-93BC-9DB100E2BF97@kumari.net>
Message-ID: <37A1C204-8DB0-4452-A7D5-9C5A12542E03@rob.sh>


On 1 Dec 2011, at 23:04, Warren Kumari wrote:

> tp://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it.

Whilst we are on the subject of relevant drafts - it should be noted that situations like this provide significant motivation for the work presented in both [0] and [1] (full disclosure: I am the editor of [0]).  I'd really encourage the community to review both documents and comment on whether they provide benefit in this problem space.  I'm very happy to take feedback on the requirements draft [0] particularly - since this aimed to describe this problem from an operator perspective.

Essentially, until something is done in a more general sense in the protocol, we will continue to see threads  liked this one popping up every few months.

I'll post a further update to the nanog list when we have requested a working group last-call on the requirements draft asking for reviews.

Thanks for your time,
r.


[0]: http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-02
[1]: http://tools.ietf.org/html/draft-ietf-idr-error-handling-00



From eugen at leitl.org  Fri Dec  2 03:18:12 2011
From: eugen at leitl.org (Eugen Leitl)
Date: Fri, 2 Dec 2011 10:18:12 +0100
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <20111201104722.F5796A6A@resin09.mta.everyone.net>
References: <20111201104722.F5796A6A@resin09.mta.everyone.net>
Message-ID: <20111202091812.GG31847@leitl.org>

On Thu, Dec 01, 2011 at 10:47:22AM -0800, Scott Weeks wrote:

> In our industry, especially with all the tools we have today, it would seem 
> that telecommuting would be more accepted, but it's not and I don't understand 
> why.

People are social primates, alphas like access to nonverbal cues for
reading and control of their supposed underlings. Same reasons for
concentrations in big cities: interaction density is higher for business
dinners while underlings are not too far away. Net ops are more like
hunter-gatherers than anything, so there's considerable culture clash. 


From rs at seastrom.com  Fri Dec  2 05:52:44 2011
From: rs at seastrom.com (Robert E. Seastrom)
Date: Fri, 02 Dec 2011 06:52:44 -0500
Subject: IP addresses are now assets
In-Reply-To: <44762.1322812111@turing-police.cc.vt.edu> (Valdis Kletnieks's
 message of "Fri, 02 Dec 2011 02:48:31 -0500")
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
Message-ID: <86r50n42cz.fsf@seastrom.com>


Valdis.Kletnieks at vt.edu writes:

> Would it be correct to summarize the ARIN position as "It's murkier than Cerner
> makes it out to be, and some lawyers are gonna get stinking filthy rich
> litigating this one"?
>
> :)

In any litigation, Counsel always wins.  I often remind myself that
there's still time to go to law school.  :-)

-r



From t.dahm at resolution.de  Fri Dec  2 06:25:41 2011
From: t.dahm at resolution.de (Thorsten Dahm)
Date: Fri, 02 Dec 2011 12:25:41 +0000
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <201112011635.27951.david@davidradcliffe.org>
References: <20111201104722.F5796A6A@resin09.mta.everyone.net>
 <201112011635.27951.david@davidradcliffe.org>
Message-ID: <4ED8C3C5.2010404@resolution.de>

Am 12/1/11 9:35 PM, schrieb David Radcliffe:
> Since I like to work and code (I spend 10 hours a day on the computer at the
> office, think about work related stuff in the shower, and often write Perl code
> at home to deal with various household tasks) I work quite well at home.
> There are more distractions at the office and my productivity is greater in my
> home computer room during those times I have to put in some extra for the
> office.

The downside of this is that you are not around in the office in case 
someone wants to talk to you. I often end up with guys from our 
operations team or other teams stopping at my desk and ask questions. Or 
guys who want to have a quick chat about a problem and want to ask for 
an advice or idea. Or people who want to learn Perl and have a question 
that you can answer in 30 seconds.

Yes, I know, they can call you, or send an Email, but nothing beats the 
good old "Let's go for a coffee, I'd like to ask you a question".

cheers,
Thorsten


From eugen at leitl.org  Fri Dec  2 06:34:07 2011
From: eugen at leitl.org (Eugen Leitl)
Date: Fri, 2 Dec 2011 13:34:07 +0100
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <4ED8C3C5.2010404@resolution.de>
References: <20111201104722.F5796A6A@resin09.mta.everyone.net>
 <201112011635.27951.david@davidradcliffe.org>
 <4ED8C3C5.2010404@resolution.de>
Message-ID: <20111202123407.GK31847@leitl.org>

On Fri, Dec 02, 2011 at 12:25:41PM +0000, Thorsten Dahm wrote:

> Yes, I know, they can call you, or send an Email, but nothing beats the  
> good old "Let's go for a coffee, I'd like to ask you a question".

Some people just put up a dedicated netbook with a permanent
video/audio link (can be a problem with limited residential
upstram) for a poor man's telepresence.

What could potentially work even better is to build a
virtual office using e.g. OpenQwaq http://code.google.com/p/openqwaq/
(not sure the codes are fully done in the open sourced
version yet, but they'll be there in a few months).


From leigh.porter at ukbroadband.com  Fri Dec  2 06:39:37 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 2 Dec 2011 12:39:37 +0000
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <4ED8C3C5.2010404@resolution.de>
References: <20111201104722.F5796A6A@resin09.mta.everyone.net>
 <201112011635.27951.david@davidradcliffe.org>
 <4ED8C3C5.2010404@resolution.de>
Message-ID: <D181DDABABE57E4DB72FEE003314786444E8E7@EALPO1.ukbroadband.com>

> -----Original Message-----
> From: Thorsten Dahm [mailto:t.dahm at resolution.de]
> Sent: 02 December 2011 12:28
> To: nanog at nanog.org
> Subject: Re: Looking for a Tier 1 ISP Mentor for career advice.
> 
> Am 12/1/11 9:35 PM, schrieb David Radcliffe:
> > Since I like to work and code (I spend 10 hours a day on the computer
> at the
> > office, think about work related stuff in the shower, and often write
> Perl code
> > at home to deal with various household tasks) I work quite well at
> home.
> > There are more distractions at the office and my productivity is
> greater in my
> > home computer room during those times I have to put in some extra for
> the
> > office.
> 
> The downside of this is that you are not around in the office in case
> someone wants to talk to you. I often end up with guys from our
> operations team or other teams stopping at my desk and ask questions.
> Or
> guys who want to have a quick chat about a problem and want to ask for
> an advice or idea. Or people who want to learn Perl and have a question
> that you can answer in 30 seconds.

And it means you do not get 'noticed' as much. I work from home when I have a task to get done that benefits from not having to talk to people. A specific document that needs completing or some more PowerPoint waffle for a pointless meeting with people who won't get it anyway.

Other than that, I try to be in the office.

--
Leigh




______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

From jcurran at arin.net  Fri Dec  2 06:42:03 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 2 Dec 2011 12:42:03 +0000
Subject: IP addresses are now assets
In-Reply-To: <44762.1322812111@turing-police.cc.vt.edu>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
Message-ID: <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>

On Dec 2, 2011, at 2:48 AM, <Valdis.Kletnieks at vt.edu> wrote:

> Would it be correct to summarize the ARIN position as "It's murkier than Cerner
> makes it out to be, and some lawyers are gonna get stinking filthy rich
> litigating this one"?

It's pretty simple: you can write a contract to transfer IP 
addresses in accordance with policy, and we are now seeing 
most parties come to us in advance either to prequalify or 
make the sale conditional on approval.

FYI,
/John

John Curran
President and CEO
ARIN



From joly at punkcast.com  Fri Dec  2 06:57:26 2011
From: joly at punkcast.com (Joly MacFie)
Date: Fri, 2 Dec 2011 07:57:26 -0500
Subject: IP addresses are now assets
In-Reply-To: <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
Message-ID: <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>

Hi John,

I'm sorry to be thick, but can you explain  "right of visibility to the
public portion of registrations" a little further?.

Under what circumstances might ARIN deny approval?

j

On Fri, Dec 2, 2011 at 7:42 AM, John Curran <jcurran at arin.net> wrote:

> On Dec 2, 2011, at 2:48 AM, <Valdis.Kletnieks at vt.edu> wrote:
>
> > Would it be correct to summarize the ARIN position as "It's murkier than
> Cerner
> > makes it out to be, and some lawyers are gonna get stinking filthy rich
> > litigating this one"?
>
> It's pretty simple: you can write a contract to transfer IP
> addresses in accordance with policy, and we are now seeing
> most parties come to us in advance either to prequalify or
> make the sale conditional on approval.
>
> FYI,
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>


-- 
---------------------------------------------------------------
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 dbg at net-geek.org  Fri Dec  2 07:12:48 2011
From: dbg at net-geek.org (Daniel Ginsburg)
Date: Fri, 2 Dec 2011 17:12:48 +0400
Subject: draft-ietf-idr-as0-00 (bgp update destroying transit on redback
 routers ?)
In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
Message-ID: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>

Hi,

This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attribute.

The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous.

If the network employs the "no-aggregator-id" knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about.

In other words, the "no-aggregator-id" knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute.

On 02.12.2011, at 1:56, Jeff Tantsura wrote:

> Hi,
> 
> Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols.
> There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds.
> 
> To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yakov about it, without any results though. 
> So for those who have it configured - please rethink whether you really need it.
> 
> As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code.
> Patch will be made available.
> 
> Please contact me for any further clarifications.
> 
> Regards,
> Jeff
> 
> P.S. Warren has recently  included AGGREGATOR in the draft, please see
> 
> 2. Behavior
>   This document specifies that a BGP speaker MUST NOT originate or
>   propagate a route with an AS number of zero.  If a BGP speaker
>   receives a route which has an AS number of zero in the AS_PATH (or
>   AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
>   This same behavior applies to routes containing zero as the
>   Aggregator or AS4 Aggregator.
> 



From jcurran at arin.net  Fri Dec  2 07:18:45 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 2 Dec 2011 13:18:45 +0000
Subject: IP addresses are now assets
In-Reply-To: <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
Message-ID: <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>

On Dec 2, 2011, at 7:57 AM, Joly MacFie wrote:

> Hi John,
> 
> I'm sorry to be thick, but can you explain  "right of visibility to the
> public portion of registrations" a little further?.
> 
> Under what circumstances might ARIN deny approval?

Joly - 
 
  Requests are processed according the transfer policies
  <https://www.arin.net/policy/nrpm.html#eight>.  If a 
  request doesn't meet the transfer policy (e.g. the sale
  is not to an actual entity that has an operational need
  for address space or it is more space than needed for the
  next twelve months), then it will be denied.  
  
  If you think that ARIN should operate under different 
  policies in the management of the IP address space in
  the region, you can submit a policy proposal to change
  the policy as desired:
  <https://www.arin.net/participate/how_to_participate.html>

Thanks!
/John

John Curran
President and CEO
ARIN




From leigh.porter at ukbroadband.com  Fri Dec  2 07:23:49 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 2 Dec 2011 13:23:49 +0000
Subject: IP addresses are now assets
In-Reply-To: <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
Message-ID: <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: John Curran [mailto:jcurran at arin.net]
> Joly -
> 
>   Requests are processed according the transfer policies
>   <https://www.arin.net/policy/nrpm.html#eight>.  If a
>   request doesn't meet the transfer policy (e.g. the sale
>   is not to an actual entity that has an operational need
>   for address space or it is more space than needed for the
>   next twelve months), then it will be denied.


Presumably organisations will check this and fake the appropriate paperwork and come up with some plausible excuse for requiring the space within the next 12 months BEFORE they part with their cash.

It would be most amusing for somebody to buy space, hand over the money and then have ARIN deny the transfer.

So I do wonder, how is this policy is being enforced and will ARIN be investigating this current news item?

-- 
Leigh Porter


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From jgreco at ns.sol.net  Fri Dec  2 07:16:20 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Fri, 2 Dec 2011 07:16:20 -0600 (CST)
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <4ED8C3C5.2010404@resolution.de>
Message-ID: <201112021316.pB2DGKGm014444@aurora.sol.net>

> Am 12/1/11 9:35 PM, schrieb David Radcliffe:
> > Since I like to work and code (I spend 10 hours a day on the computer at the
> > office, think about work related stuff in the shower, and often write Perl code
> > at home to deal with various household tasks) I work quite well at home.
> > There are more distractions at the office and my productivity is greater in my
> > home computer room during those times I have to put in some extra for the
> > office.
> 
> The downside of this is that you are not around in the office in case 
> someone wants to talk to you. I often end up with guys from our 
> operations team or other teams stopping at my desk and ask questions. Or 
> guys who want to have a quick chat about a problem and want to ask for 
> an advice or idea. Or people who want to learn Perl and have a question 
> that you can answer in 30 seconds.
> 
> Yes, I know, they can call you, or send an Email, but nothing beats the 
> good old "Let's go for a coffee, I'd like to ask you a question".

Which really stops being practical once you exceed (approx) one building 
in size.  It was interesting during the early days to note that there were
certain people who did a lot of their interaction on IRC, even when in the
office, even when sitting a few cubes away from each other sometimes.  It
definitely enabled telepresence - obviously not as good as "being there",
but it was funny every now and then when you'd go looking for that person
and find out they were out today at a different office, or telecommuting.

It seems to me that we've not been as successful as we might at this whole
telecommuting thing, because people - especially at small companies - ARE
used to being able to grab a coffee, and there's a reluctance to lose that.

... 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 randy at psg.com  Fri Dec  2 08:02:48 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 02 Dec 2011 23:02:48 +0900
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <CANwiKab+5VdjJz7vYMXx9G9B4WHNOqN0ymxQNTxc2eWomGdTag@mail.gmail.com>
References: <CANwiKaZxZdUH1jgWxkSQ+dGA-07dLFgJ9OwyyL4sWUkGdqsTDw@mail.gmail.com>
 <CANwiKaYraWPd9WxFs5PDad3Jr+xgXP_+tFk0Wt84u1bRduD4yQ@mail.gmail.com>
 <CAL9jLabVYZGmRGeeseFNKM0-8THPGBb3pudHNomJp2Ptd9DtsA@mail.gmail.com>
 <CANwiKab+5VdjJz7vYMXx9G9B4WHNOqN0ymxQNTxc2eWomGdTag@mail.gmail.com>
Message-ID: <m2y5uv9ilz.wl%randy@psg.com>

>> <http://tools.ietf.org/html/draft-wkumari-idr-as0-01>
>> one of the reasons the above was written...
> That does not include when ASN=0 is used in the aggregator attribute.
> Could you add that?

next rev


From gary.buhrmaster at gmail.com  Fri Dec  2 08:08:03 2011
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 2 Dec 2011 06:08:03 -0800
Subject: IP addresses are now assets
In-Reply-To: <86r50n42cz.fsf@seastrom.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <86r50n42cz.fsf@seastrom.com>
Message-ID: <CAMfXtQz76wVZ0oa5Dodr_ddqMrxEh2UnF5HWg79AH0ty5mNv_w@mail.gmail.com>

On Fri, Dec 2, 2011 at 03:52, Robert E. Seastrom <rs at seastrom.com> wrote:
....
> In any litigation, Counsel always wins. ?I often remind myself that
> there's still time to go to law school. ?:-)

It may be too late.  The glory days of getting a JD
and then racking in the money are apparently over.
I remember reading recently (in the NYTimes?) that
newly minted lawyers are having a hard time finding
employment, as the customers of the law firms are
pushing back on the ever higher fees, and the firms
are responding by a combination of outsourcing some
research, and using non-lawyers for other work,
reducing the demand for (and hiring of) new lawyers.
Exceptions noted for the Harvard grads due to the OBN.


From bicknell at ufp.org  Fri Dec  2 08:11:51 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 2 Dec 2011 06:11:51 -0800
Subject: IP addresses are now assets
In-Reply-To: <20111202040423.GL1397@manor.msen.com>
References: <20111202040423.GL1397@manor.msen.com>
Message-ID: <20111202141151.GA20138@ussenterprise.ufp.org>

In a message written on Thu, Dec 01, 2011 at 11:04:23PM -0500, Michael R. Wayne wrote:
>    After negotiating with multiple prospective buyers, Cerner Corp.
>    agreed to buy the Internet addresses for $12 each. Other bids were
>    as low as $1.50 each, according to a bankruptcy court filing.

Someone should tell Cerner Corp you can still get them for free,
and thus they overpaid by oh, $12 an address!

-- 
       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/20111202/0d3eb9bf/attachment.bin>

From snar at snar.spb.ru  Fri Dec  2 08:35:54 2011
From: snar at snar.spb.ru (Alexandre Snarskii)
Date: Fri, 2 Dec 2011 18:35:54 +0400
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
Message-ID: <20111202143554.GA66539@snar.spb.ru>

On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote:
> Hi,
> 
> Let me take it over from now on, I'm the IP Routing/MPLS Product Manager 
> at Ericsson responsible for all routing protocols.
> There's nothing wrong in checking ASN in AGGREGATOR, we don't really want 
> see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) 
> came into the worlds.

This draft says that

If a BGP speaker receives a route which has an AS number of zero in the
AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a 
WITHDRAW. This same behavior applies to routes containing zero as the 
Aggregator or AS4 Aggregator.

but observed behaviour was more like following: 

If a BGP speaker receives [bad route] it MUST close session immediately 
with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with 
optional attribute'.

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 



From mtinka at globaltransit.net  Fri Dec  2 08:57:42 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 2 Dec 2011 22:57:42 +0800
Subject: ATT GigE issue on 11/19 in Kansas City
In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F31F@USEXMBS01.mwd.h2o>
References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01>
 <7BE0B126-8F07-43C5-8081-1AC0CFB0DF0F@gmail.com>
 <922ACC42D498884AA02B3565688AF995340255F31F@USEXMBS01.mwd.h2o>
Message-ID: <201112022257.47727.mtinka@globaltransit.net>

On Thursday, December 01, 2011 02:56:37 AM Holmes,David A 
wrote:

> What I have seen lately with telco's building and
> operating Metro Ethernet Forum (MEF) based Ethernet
> networks is that relatively inexperienced telco staff
> are in charge of configuring and operating the networks,
> where telco operational staff are unaware of layer 2
> Ethernet network nuances, nuances that in an Enterprise
> environment network engineers must know, or else.

We use RANCID here, quite heavily, to help guide 
provisioning engineers so they are better prepared for the 
future, and actually understand what it is they are 
configuring.

Pre-provisioning training is all good and well, but hands-on 
experience always has the chance of "going the other way". 
While RANCID is after-the-fact, it's a great tool for 
refining what the folk on the ground know.

It certainly has helped us a great deal, over the years.

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/20111202/e1abbbdf/attachment-0001.bin>

From ryan at u13.net  Fri Dec  2 09:02:56 2011
From: ryan at u13.net (Ryan Rawdon)
Date: Fri, 2 Dec 2011 10:02:56 -0500
Subject: Recent DNS attacks from China?
In-Reply-To: <F3318834F1F89D46857972DD4B411D7005274280E8@exchange>
References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org>
 <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com>
 <CACB24MstXHDXq9LtfUpcanxV4SYKk7ke-aiWTrggHE5KrO1VPg@mail.gmail.com>
 <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org>
 <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local>
 <F3318834F1F89D46857972DD4B411D7005274280E8@exchange>
Message-ID: <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net>


On Nov 30, 2011, at 3:12 PM, Drew Weaver wrote:

> 
> -----Original Message-----
> From: Rob.Vercouteren at kpn.com [mailto:Rob.Vercouteren at kpn.com] 
> Sent: Wednesday, November 30, 2011 3:05 PM
> To: MatlockK at exempla.org; richard.barnes at gmail.com; andrew.wallace at rocketmail.com
> Cc: nanog at nanog.org; leland at taranta.discpro.org
> Subject: RE: Recent DNS attacks from China?
> 
> Yes it is, but the problem is that our servers are "attacking" the so called source address. All the answers are going back to the "source". It is huge amplification attacks. (some sort of smurf if you want) The ip addresses are spoofed (We did a capture and saw all different ttl's so coming from behind different hops) And yes we saw the ANY queries for all the domains.
> 
> I still wonder how it is still possible that ip addresses can be spoofed nowadays

We're a smaller shop and started receiving these queries last night, roughly 1000 queries per minute or less.  We're seeing that the source (victim) addresses are changing every few minutes, the TTLs vary within a given source address, and while most of the source/victim addresses have been Chinese we are seeing a few which are not, such as 74.125.90.83 (Google).  The queries are coming in to ns1.traffiq.com (perhaps ns2 also, I haven't checked) and are for traffiq.com/ANY which unfortunately gives a 492 byte response.


> 
> =================
> 
> Rob,
> 
> Transit providers can bill for the denial of service traffic and they claim it's too expensive to run URPF because of the extra lookup.
> 
> -Drew
> 



From hannigan at gmail.com  Fri Dec  2 09:16:55 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 2 Dec 2011 10:16:55 -0500
Subject: IP addresses are now assets
In-Reply-To: <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
Message-ID: <CAMDXq5PzrUhUUi3brBjWN1-bOBMhFUVVvVVJA0YCfc=4UiFoPQ@mail.gmail.com>

On Fri, Dec 2, 2011 at 8:23 AM, Leigh Porter
<leigh.porter at ukbroadband.com> wrote:
>
>
>> -----Original Message-----
>> From: John Curran [mailto:jcurran at arin.net]
>> Joly -
>>
>> ? Requests are processed according the transfer policies
>> ? <https://www.arin.net/policy/nrpm.html#eight>. ?If a
>> ? request doesn't meet the transfer policy (e.g. the sale
>> ? is not to an actual entity that has an operational need
>> ? for address space or it is more space than needed for the
>> ? next twelve months), then it will be denied.
>
>
> Presumably organisations will check this and fake the appropriate paperwork and come up with some plausible excuse for requiring the space within the next 12 months BEFORE they part with their cash.
>
> It would be most amusing for somebody to buy space, hand over the money and then have ARIN deny the transfer.
>
> So I do wonder, how is this policy is being enforced and will ARIN be investigating this current news item?
>

ARIN, on many occasions, has stated that they have no authority over
legacy address space. They made this declaration in the Kamens/sex.com
case. I haven't heard that anything has changed since then.

Nortel/MSN was the first, big, public transaction. There have been
others prior to Nortel. There will be more after Borders.

Circuit City:

http://www.slideshare.net/Streambank/offering-memo-ip-addresses-92111final

Best.

-M<


From leland at taranta.discpro.org  Fri Dec  2 09:17:22 2011
From: leland at taranta.discpro.org (Leland Vandervort)
Date: Fri, 2 Dec 2011 16:17:22 +0100
Subject: Recent DNS attacks from China?
In-Reply-To: <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net>
References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org>
 <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com>
 <CACB24MstXHDXq9LtfUpcanxV4SYKk7ke-aiWTrggHE5KrO1VPg@mail.gmail.com>
 <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org>
 <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local>
 <F3318834F1F89D46857972DD4B411D7005274280E8@exchange>
 <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net>
Message-ID: <AE136E15-EFBE-456E-80A7-EE3D608D1883@taranta.discpro.org>

Yup.. they're all "ANY" requests.  The varying TTLs indicates that they're most likely spoofed.  We are also now seeing similar traffic from RFC1918 "source" addresses trying to ingress our network (but being stopped by our border filters).

Looks like the kiddies are playing.... 


On 2 Dec 2011, at 16:02, Ryan Rawdon wrote:

> 
> On Nov 30, 2011, at 3:12 PM, Drew Weaver wrote:
> 
>> 
>> -----Original Message-----
>> From: Rob.Vercouteren at kpn.com [mailto:Rob.Vercouteren at kpn.com] 
>> Sent: Wednesday, November 30, 2011 3:05 PM
>> To: MatlockK at exempla.org; richard.barnes at gmail.com; andrew.wallace at rocketmail.com
>> Cc: nanog at nanog.org; leland at taranta.discpro.org
>> Subject: RE: Recent DNS attacks from China?
>> 
>> Yes it is, but the problem is that our servers are "attacking" the so called source address. All the answers are going back to the "source". It is huge amplification attacks. (some sort of smurf if you want) The ip addresses are spoofed (We did a capture and saw all different ttl's so coming from behind different hops) And yes we saw the ANY queries for all the domains.
>> 
>> I still wonder how it is still possible that ip addresses can be spoofed nowadays
> 
> We're a smaller shop and started receiving these queries last night, roughly 1000 queries per minute or less.  We're seeing that the source (victim) addresses are changing every few minutes, the TTLs vary within a given source address, and while most of the source/victim addresses have been Chinese we are seeing a few which are not, such as 74.125.90.83 (Google).  The queries are coming in to ns1.traffiq.com (perhaps ns2 also, I haven't checked) and are for traffiq.com/ANY which unfortunately gives a 492 byte response.
> 
> 
>> 
>> =================
>> 
>> Rob,
>> 
>> Transit providers can bill for the denial of service traffic and they claim it's too expensive to run URPF because of the extra lookup.
>> 
>> -Drew
>> 



From david at davidradcliffe.org  Fri Dec  2 09:20:19 2011
From: david at davidradcliffe.org (David Radcliffe)
Date: Fri, 2 Dec 2011 10:20:19 -0500
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <4ED8C3C5.2010404@resolution.de>
References: <20111201104722.F5796A6A@resin09.mta.everyone.net>
 <201112011635.27951.david@davidradcliffe.org>
 <4ED8C3C5.2010404@resolution.de>
Message-ID: <201112021020.20348.david@davidradcliffe.org>

On Friday, December 02, 2011 07:25:41 AM Thorsten Dahm wrote:
> Am 12/1/11 9:35 PM, schrieb David Radcliffe:
> > Since I like to work and code (I spend 10 hours a day on the computer at
> > the office, think about work related stuff in the shower, and often
> > write Perl code at home to deal with various household tasks) I work
> > quite well at home. There are more distractions at the office and my
> > productivity is greater in my home computer room during those times I
> > have to put in some extra for the office.
> 
> The downside of this is that you are not around in the office in case
> someone wants to talk to you. I often end up with guys from our
> operations team or other teams stopping at my desk and ask questions. Or
> guys who want to have a quick chat about a problem and want to ask for
> an advice or idea. Or people who want to learn Perl and have a question
> that you can answer in 30 seconds.
> 
> Yes, I know, they can call you, or send an Email, but nothing beats the
> good old "Let's go for a coffee, I'd like to ask you a question".
> 
> cheers,
> Thorsten

Actually, that is the upside.  Everywhere I have worked there are the people 
who will come to you before they even try to think of an answer.  Your work 
gets interrupted because they did not have to send an email and wanted an 
excuse to socialize.

It's much better to have a record (email) of most conversations especially 
when there are technical points which may be helpful to refer to in the 
future.

F2F is fine when you are working on pushing your point as it is easier to 
create "presence" but 99% of all meetings and impromptu discussions in the 
office waste more time than provide any real benefit.

I know plenty of people (my wife included) who disagree and feel there is 
great benefit in F2F but I contended they are just more comfortable with the 
old fashioned way they have always done things.

There are people even today who will print and bring me an email to discuss 
the reported problem rather than forward information electronically.  That is 
just because it is difficult for people to break their comfort molds to see a 
more productive method.

I do not say it is easy.  I understand people think the way they do things, 
the things which make them comfortable, seem best but in this case F2F is not 
best for everyone.

If someone says to me "Let's go for a coffee, I'd like to ask you a question" 
what I hear is "Gee, you are not busy.  Why are you getting a paycheck?  Let's 
go talk shop and other non-work related stuff.  I have a legitimate question 
and I want to socialize."

I have a better idea, send email.  If the question is too deep we can "meet" 
on the phone.  I have a TeamSpeak server.  Want to get together?  Let's grab a 
beer after work or we can chat on TS while wandering through Left4Dead.

F2F is for semi-work related activities.  If you need to paint a picture we 
can bounce a diagram back and forth (please use open standards -- .odg, .dia, 
etc. -- and not proprietary -- .vsd) or we can draw simple stuff in Coccinella 
or OpenMeeting (I have servers set up).  We can use email.  We can use chat (I 
have Coccinella and a local server for our in-house and use Pidgin for AIM, 
Yahoo, MSN for my outside contacts).  I have Logitech 9000 cameras so if you 
really, really want to see me I will configure my VoIP (Asterisk server at 
home) so we can look at each other.

The whole "I have to be in your space in an office for work to be effective" is 
so nineteenth century.

Seriously:

"You talked to Ted the other day about the NetFlow based bandwidth billing 
project.  What were the details and decisions?  Can you remember the important 
points?"

"No.  But the discussion was electronic so I will pass you the email 
chain/chat log/etc."

My dream is roll out of bed, make coffee, walk upstairs into my computer room 
and begin work.  Deal with conversations via email/work the online job queue.  
Maybe attend a quarterly face-time meeting with the company.  Maybe the people 
are nice.  That would be cool.  Maybe a monthly meeting at the home office in 
Atlanta on the 3rd Friday because the company provides tickets to Jazz at the 
High Museum.  I can dream...

-- 
David Radcliffe
Network Engineer/Linux Specialist
david at davidradcliffe.org
www.davidradcliffe.org

Nothing ever gets solved better with panic.
If you do not know the answer, it is probably "42."


From mtinka at globaltransit.net  Fri Dec  2 09:19:28 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 2 Dec 2011 23:19:28 +0800
Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS
 networks?
In-Reply-To: <CALFTrnPbNEOyRrPpqUTGqfRR3YK7-hp8A+U=BM=+kqpepHnRhg@mail.gmail.com>
References: <CAF976C9.1B7412%john_brzozowski@cable.comcast.com>
 <193BA8AA-22C3-4682-954B-B0A25A762647@exonetric.com>
 <CALFTrnPbNEOyRrPpqUTGqfRR3YK7-hp8A+U=BM=+kqpepHnRhg@mail.gmail.com>
Message-ID: <201112022319.32328.mtinka@globaltransit.net>

On Thursday, December 01, 2011 08:19:51 AM Ray Soucy wrote:

> There is a lot of talk about "buggy" systems that are
> unable to handle prefixes longer than 64; but I've yet
> to encounter one.  I imagine if I did it would be
> treated as a bug and fixed.  So to the question of
> supporting different prefix lengths: Yes.  You should
> support any valid IPv6 prefix length; it takes a few
> extra lines of code in the beginning; but will save you
> a lot of re-coding in the end.

Exactly.

/126's for point-to-points, and /112's for router LAN's 
here, 6 years and counting.

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/20111202/453f0ee0/attachment.bin>

From jmaslak at antelope.net  Fri Dec  2 09:23:56 2011
From: jmaslak at antelope.net (Joel Maslak)
Date: Fri, 2 Dec 2011 08:23:56 -0700
Subject: Recent DNS attacks from China?
In-Reply-To: <AE136E15-EFBE-456E-80A7-EE3D608D1883@taranta.discpro.org>
References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org>
 <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com>
 <CACB24MstXHDXq9LtfUpcanxV4SYKk7ke-aiWTrggHE5KrO1VPg@mail.gmail.com>
 <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org>
 <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local>
 <F3318834F1F89D46857972DD4B411D7005274280E8@exchange>
 <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net>
 <AE136E15-EFBE-456E-80A7-EE3D608D1883@taranta.discpro.org>
Message-ID: <CADb+6TCQ3mzP=LEzXOsccRFUhKhbzehRBJrEmv+oocFJOHexEQ@mail.gmail.com>

Other than being non-compliant, is an "ANY" query used by any major
software?  Could someone rate limit ANY responses to mitigate this
particular issue?

On Fri, Dec 2, 2011 at 8:17 AM, Leland Vandervort <
leland at taranta.discpro.org> wrote:

> Yup.. they're all "ANY" requests.  The varying TTLs indicates that they're
> most likely spoofed.  We are also now seeing similar traffic from RFC1918
> "source" addresses trying to ingress our network (but being stopped by our
> border filters).
>
> Looks like the kiddies are playing....
>
>
> On 2 Dec 2011, at 16:02, Ryan Rawdon wrote:
>
> >
> > On Nov 30, 2011, at 3:12 PM, Drew Weaver wrote:
> >
> >>
> >> -----Original Message-----
> >> From: Rob.Vercouteren at kpn.com [mailto:Rob.Vercouteren at kpn.com]
> >> Sent: Wednesday, November 30, 2011 3:05 PM
> >> To: MatlockK at exempla.org; richard.barnes at gmail.com;
> andrew.wallace at rocketmail.com
> >> Cc: nanog at nanog.org; leland at taranta.discpro.org
> >> Subject: RE: Recent DNS attacks from China?
> >>
> >> Yes it is, but the problem is that our servers are "attacking" the so
> called source address. All the answers are going back to the "source". It
> is huge amplification attacks. (some sort of smurf if you want) The ip
> addresses are spoofed (We did a capture and saw all different ttl's so
> coming from behind different hops) And yes we saw the ANY queries for all
> the domains.
> >>
> >> I still wonder how it is still possible that ip addresses can be
> spoofed nowadays
> >
> > We're a smaller shop and started receiving these queries last night,
> roughly 1000 queries per minute or less.  We're seeing that the source
> (victim) addresses are changing every few minutes, the TTLs vary within a
> given source address, and while most of the source/victim addresses have
> been Chinese we are seeing a few which are not, such as 74.125.90.83
> (Google).  The queries are coming in to ns1.traffiq.com (perhaps ns2
> also, I haven't checked) and are for traffiq.com/ANY which unfortunately
> gives a 492 byte response.
> >
> >
> >>
> >> =================
> >>
> >> Rob,
> >>
> >> Transit providers can bill for the denial of service traffic and they
> claim it's too expensive to run URPF because of the extra lookup.
> >>
> >> -Drew
> >>
>
>
>

From jcurran at arin.net  Fri Dec  2 09:33:25 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 2 Dec 2011 15:33:25 +0000
Subject: IP addresses are now assets
In-Reply-To: <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
Message-ID: <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>

On Dec 2, 2011, at 8:23 AM, Leigh Porter wrote:

> So I do wonder, how is this policy is being enforced and will ARIN be investigating this current news item?

Leigh - 
 
  No investigation is needed, as I already noted the parties
  have sought out ARIN in advance.  Note that original sales
  solicitation states:  "Sale may be subject to compliance with 
  certain requirements of the American Registry of Internet 
  Numbers ("ARIN") and the court materials to date reflect this.

FYI,
/John

John Curran
President and CEO
ARIN



From cmadams at hiwaay.net  Fri Dec  2 09:36:25 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 2 Dec 2011 09:36:25 -0600
Subject: Recent DNS attacks from China?
In-Reply-To: <CADb+6TCQ3mzP=LEzXOsccRFUhKhbzehRBJrEmv+oocFJOHexEQ@mail.gmail.com>
References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org>
 <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com>
 <CACB24MstXHDXq9LtfUpcanxV4SYKk7ke-aiWTrggHE5KrO1VPg@mail.gmail.com>
 <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org>
 <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local>
 <F3318834F1F89D46857972DD4B411D7005274280E8@exchange>
 <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net>
 <AE136E15-EFBE-456E-80A7-EE3D608D1883@taranta.discpro.org>
 <CADb+6TCQ3mzP=LEzXOsccRFUhKhbzehRBJrEmv+oocFJOHexEQ@mail.gmail.com>
Message-ID: <20111202153625.GB3207@hiwaay.net>

Once upon a time, Joel Maslak <jmaslak at antelope.net> said:
> Other than being non-compliant, is an "ANY" query used by any major
> software?  Could someone rate limit ANY responses to mitigate this
> particular issue?

I believe qmail still uses ANY lookups.
-- 
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  Fri Dec  2 09:37:08 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 2 Dec 2011 07:37:08 -0800
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <4ED8C3C5.2010404@resolution.de>
References: <20111201104722.F5796A6A@resin09.mta.everyone.net>
 <201112011635.27951.david@davidradcliffe.org>
 <4ED8C3C5.2010404@resolution.de>
Message-ID: <20111202153708.GA23268@ussenterprise.ufp.org>

In a message written on Fri, Dec 02, 2011 at 12:25:41PM +0000, Thorsten Dahm wrote:
> The downside of this is that you are not around in the office in case 
> someone wants to talk to you. I often end up with guys from our 
> operations team or other teams stopping at my desk and ask questions. Or 
> guys who want to have a quick chat about a problem and want to ask for 
> an advice or idea. Or people who want to learn Perl and have a question 
> that you can answer in 30 seconds.

I've both delt with remote employees and been a telecommuter.  After
those experiences, and reading a few books I've decided the hardest
thing about having successful telecommuters is dealing with the
folks in the office.

Telecommuters quickly turn to technology, they want to video-chat
with collegues.  Are eager to pick up the phone and talk.  They
reach out (generally).  It's the folks in the office that are
reluctant.  They don't see the point of figuring out how the video
chat software works, of setting their status to indicate what they
are doing, and so on.

The "water cooler" conversations can be moved to Skype, FaceTime,
Google Hangouts, or any number of other solutions, but it requires
everyone to be in that mindset.

If you have telecommuters _everyone_ in the office should be forced
to work from home at least 2 weeks a year, including the manager.
It's only from that experience you learn to deal with your telecommuting
co-workers in a way that raises everyone's productivity.

Once over that hump there are huge rewards to having telecommuters.
You can pay lower salaries as people can live in cheaper locations.
People in multiple timezones provide better natural coverage.  People
are much more willing to do off hour work when they can roll out
of bed at 5AM and be working at 5:05 in their PJ's, rather than
getting up at 4 and getting dressed to drive in and do the work.

-- 
       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/20111202/7ee43b5e/attachment.bin>

From Rob.Vercouteren at kpn.com  Fri Dec  2 09:40:52 2011
From: Rob.Vercouteren at kpn.com (Rob.Vercouteren at kpn.com)
Date: Fri, 2 Dec 2011 16:40:52 +0100
Subject: Recent DNS attacks from China?
In-Reply-To: <CADb+6TCQ3mzP=LEzXOsccRFUhKhbzehRBJrEmv+oocFJOHexEQ@mail.gmail.com>
References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org>
 <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com>
 <CACB24MstXHDXq9LtfUpcanxV4SYKk7ke-aiWTrggHE5KrO1VPg@mail.gmail.com>
 <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org>
 <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local>
 <F3318834F1F89D46857972DD4B411D7005274280E8@exchange>
 <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net>
 <AE136E15-EFBE-456E-80A7-EE3D608D1883@taranta.discpro.org>
 <CADb+6TCQ3mzP=LEzXOsccRFUhKhbzehRBJrEmv+oocFJOHexEQ@mail.gmail.com>
Message-ID: <3454EA54E9F18A4993A4B99F07A01D9D014D53F63976@W2055.kpnnl.local>

Since it is spoofed traffic we block the "source", so not participating in flooding the real ip address.
The real issue is verify unicast reverse path not being implemented. So that the ip addresses cannot be spoofed!
(unless we are dealing with some major unknown vurlnerabilities in our infrastructure)
After a few days we will unblock again.


Regards,

Rob Vercouteren 




From t.dahm at resolution.de  Fri Dec  2 10:40:51 2011
From: t.dahm at resolution.de (Thorsten Dahm)
Date: Fri, 02 Dec 2011 16:40:51 +0000
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <201112021316.pB2DGKGm014444@aurora.sol.net>
References: <201112021316.pB2DGKGm014444@aurora.sol.net>
Message-ID: <4ED8FF93.1050603@resolution.de>

Am 12/2/11 1:16 PM, schrieb Joe Greco:
>> Thorsten Dahm:
>> The downside of this is that you are not around in the office in case
>> someone wants to talk to you. I often end up with guys from our
>> operations team or other teams stopping at my desk and ask questions. Or
>> guys who want to have a quick chat about a problem and want to ask for
>> an advice or idea. Or people who want to learn Perl and have a question
>> that you can answer in 30 seconds.
>
> Which really stops being practical once you exceed (approx) one building
> in size.

I think it often depends on how you define practical. Normally, you sit 
with your own team, that means it is a practical solution for the 
network engineers, but perhaps not for the server admins and the network 
engineers anymore, since the server admins may sit in a different 
building, different city, different continent, ....

cheers,
Thorsten


From cjp at 0x1.net  Fri Dec  2 11:18:25 2011
From: cjp at 0x1.net (Christopher J. Pilkington)
Date: Fri, 2 Dec 2011 12:18:25 -0500
Subject: IP addresses are now assets
In-Reply-To: <20111202040423.GL1397@manor.msen.com>
References: <20111202040423.GL1397@manor.msen.com>
Message-ID: <-2177556483850811793@unknownmsgid>

On Dec 1, 2011, at 23:04, "Michael R. Wayne" <wayne at staff.msen.com> wrote:

> After negotiating with multiple prospective buyers, Cerner Corp.
>   agreed to buy the Internet addresses for $12 each. Other bids were
>   as low as $1.50 each, according to a bankruptcy court filing.

Clearly the addresses with the last octet of 00 and ff should be
discounted, since no one wants to be zero, and ff just seems to get
everyone's attention.

-cjp


From sakamura at gmail.com  Fri Dec  2 11:21:04 2011
From: sakamura at gmail.com (Ishmael Rufus)
Date: Fri, 2 Dec 2011 11:21:04 -0600
Subject: IP addresses are now assets
In-Reply-To: <-2177556483850811793@unknownmsgid>
References: <20111202040423.GL1397@manor.msen.com>
 <-2177556483850811793@unknownmsgid>
Message-ID: <CAL-SDLHHMeFB1oB_cR_vNC0jQ-wi+K6f04tjhnuGA259FPAC0g@mail.gmail.com>

I have acres on the moon that are up for sale.

On Fri, Dec 2, 2011 at 11:18 AM, Christopher J. Pilkington <cjp at 0x1.net> wrote:
> On Dec 1, 2011, at 23:04, "Michael R. Wayne" <wayne at staff.msen.com> wrote:
>
>> After negotiating with multiple prospective buyers, Cerner Corp.
>> ? agreed to buy the Internet addresses for $12 each. Other bids were
>> ? as low as $1.50 each, according to a bankruptcy court filing.
>
> Clearly the addresses with the last octet of 00 and ff should be
> discounted, since no one wants to be zero, and ff just seems to get
> everyone's attention.
>
> -cjp
>


From jcurran at arin.net  Fri Dec  2 11:46:30 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 2 Dec 2011 17:46:30 +0000
Subject: IP addresses are now assets
In-Reply-To: <CAMDXq5PzrUhUUi3brBjWN1-bOBMhFUVVvVVJA0YCfc=4UiFoPQ@mail.gmail.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <CAMDXq5PzrUhUUi3brBjWN1-bOBMhFUVVvVVJA0YCfc=4UiFoPQ@mail.gmail.com>
Message-ID: <787B2512-1152-42DB-8022-D28C13CFD9A6@corp.arin.net>

On Dec 2, 2011, at 10:16 AM, Martin Hannigan wrote:

> ARIN, on many occasions, has stated that they have no authority over
> legacy address space. They made this declaration in the Kamens/sex.com
> case. I haven't heard that anything has changed since then.

Martin - 

ARIN will maintain the registry in accordance with community policy
for all addresses and that includes legacy address space.

Thanks,
/John

John Curran
President and CEO
ARIN



From cscora at apnic.net  Fri Dec  2 13:21:11 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 3 Dec 2011 05:21:11 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201112021921.pB2JLBYO010309@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 Dec, 2011

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

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

BGP routing table entries examined:                              383257
    Prefixes after maximum aggregation:                          167342
    Deaggregation factor:                                          2.29
    Unique aggregates announced to Internet:                     188231
Total ASes present in the Internet Routing Table:                 39463
    Prefixes per ASN:                                              9.71
Origin-only ASes present in the Internet Routing Table:           32445
Origin ASes announcing only one prefix:                           15489
Transit ASes present in the Internet Routing Table:                5326
Transit-only ASes present in the Internet Routing Table:            142
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:              1825
    Unregistered ASNs in the Routing Table:                         938
Number of 32-bit ASNs allocated by the RIRs:                       2031
Number of 32-bit ASNs visible in the Routing Table:                1692
Prefixes from 32-bit ASNs in the Routing Table:                    4000
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:             86
Number of addresses announced to Internet:                   2497290368
    Equivalent to 148 /8s, 217 /16s and 160 /24s
    Percentage of available address space announced:               67.4
    Percentage of allocated address space announced:               67.4
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               91.7
Total number of prefixes smaller than registry allocations:      161883

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

Prefixes being announced by APNIC Region ASes:                    95145
    Total APNIC prefixes after maximum aggregation:               31175
    APNIC Deaggregation factor:                                    3.05
Prefixes being announced from the APNIC address blocks:           91627
    Unique aggregates announced from the APNIC address blocks:    38267
APNIC Region origin ASes present in the Internet Routing Table:    4600
    APNIC Prefixes per ASN:                                       19.92
APNIC Region origin ASes announcing only one prefix:               1249
APNIC Region transit ASes present in the Internet Routing Table:    727
Average APNIC Region AS path length visible:                        4.4
    Max APNIC Region AS path length visible:                         18
Number of APNIC region 32-bit ASNs visible in the Routing Table:    116
Number of APNIC addresses announced to Internet:              631205216
    Equivalent to 37 /8s, 159 /16s and 109 /24s
    Percentage of available APNIC address space announced:         80.0

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 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:                    146116
    Total ARIN prefixes after maximum aggregation:                74691
    ARIN Deaggregation factor:                                     1.96
Prefixes being announced from the ARIN address blocks:           118285
    Unique aggregates announced from the ARIN address blocks:     48671
ARIN Region origin ASes present in the Internet Routing Table:    14775
    ARIN Prefixes per ASN:                                         8.01
ARIN Region origin ASes announcing only one prefix:                5644
ARIN Region transit ASes present in the Internet Routing Table:    1574
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:               803370432
    Equivalent to 47 /8s, 226 /16s and 117 /24s
    Percentage of available ARIN address space announced:          63.8

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 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:                     92913
    Total RIPE prefixes after maximum aggregation:                51424
    RIPE Deaggregation factor:                                     1.81
Prefixes being announced from the RIPE address blocks:            85148
    Unique aggregates announced from the RIPE address blocks:     54728
RIPE Region origin ASes present in the Internet Routing Table:    16155
    RIPE Prefixes per ASN:                                         5.27
RIPE Region origin ASes announcing only one prefix:                7997
RIPE Region transit ASes present in the Internet Routing Table:    2543
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:    1186
Number of RIPE addresses announced to Internet:               492772928
    Equivalent to 29 /8s, 95 /16s and 30 /24s
    Percentage of available RIPE address space announced:          79.4

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       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:                   36582
    Total LACNIC prefixes after maximum aggregation:               7943
    LACNIC Deaggregation factor:                                   4.61
Prefixes being announced from the LACNIC address blocks:          36006
    Unique aggregates announced from the LACNIC address blocks:   18774
LACNIC Region origin ASes present in the Internet Routing Table:   1554
    LACNIC Prefixes per ASN:                                      23.17
LACNIC Region origin ASes announcing only one prefix:               442
LACNIC Region transit ASes present in the Internet Routing Table:   286
Average LACNIC Region AS path length visible:                       4.5
    Max LACNIC Region AS path length visible:                        18
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   374
Number of LACNIC addresses announced to Internet:              94397312
    Equivalent to 5 /8s, 160 /16s and 99 /24s
    Percentage of available LACNIC address space announced:        62.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:                   8338
    Total AfriNIC prefixes after maximum aggregation:              2041
    AfriNIC Deaggregation factor:                                  4.09
Prefixes being announced from the AfriNIC address blocks:          6390
    Unique aggregates announced from the AfriNIC address blocks:   2012
AfriNIC Region origin ASes present in the Internet Routing Table:   504
    AfriNIC Prefixes per ASN:                                     12.68
AfriNIC Region origin ASes announcing only one prefix:              157
AfriNIC Region transit ASes present in the Internet Routing Table:  110
Average AfriNIC Region AS path length visible:                      4.5
    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:             30034432
    Equivalent to 1 /8s, 202 /16s and 74 /24s
    Percentage of available AfriNIC address space announced:       44.8

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     2510      11105         973   Korea Telecom (KIX)
17974     1652        503          38   PT TELEKOMUNIKASI INDONESIA
 7545     1626        303          87   TPG Internet Pty Ltd
 4755     1511        381         157   TATA Communications formerly 
 7552     1386       1064           7   Vietel Corporation
 9829     1166        989          28   BSNL National Internet Backbo
 9583     1095         80         494   Sify Limited
 4808     1079       2038         305   CNCGROUP IP network: China169
24560      985        390         151   Bharti Airtel Ltd., Telemedia
18101      958        121         155   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     3483       3814         218   bellsouth.net, inc. 
 7029     2912       1016         199   Windstream Communications Inc
18566     2093        383         177   Covad Communications 
 1785     1852        680         120   PaeTec Communications, Inc.
 4323     1616       1073         386   Time Warner Telecom
20115     1603       1546         625   Charter Communications 
22773     1507       2909         104   Cox Communications, Inc.
30036     1435        257         675   Mediacom Communications Corp 
19262     1388       4683         401   Verizon Global Networks 
 7018     1314       7029         860   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     1552        480          15   Corbina telecom
 6830      645       1927         412   UPC Distribution Services
34984      616        116         195   BILISIM TELEKOM
20940      546        174         437   Akamai Technologies European 
 3320      517       8168         390   Deutsche Telekom AG
12479      494        601          13   Uni2 Autonomous System
 3292      480       2106         407   TDC Tele Danmark
 8866      462        133          26   Bulgarian Telecommunication C
 8551      451        366          45   Bezeq International
31148      413         22         115   FreeNet ISP

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     1702        315         180   TVCABLE BOGOTA 
28573     1537       1059          72   NET Servicos de Comunicao S.A
 8151     1334       2985         345   UniNet S.A. de C.V. 
 7303     1239        751         174   Telecom Argentina Stet-France
27947      606         72          89   Telconet S.A
22047      582        322          17   VTR PUNTO NET S.A. 
 7738      553       1050          31   Telecomunicacoes da Bahia S.A
 6503      552        434          68   AVANTEL, S.A. 
 3816      547        237          89   Empresa Nacional de Telecomun
11172      527         85          95   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
 8452      926        958          13   TEDATA
24863      785        146          35   LINKdotNET AS number
 3741      281        939         230   The Internet Solution 
15706      242         32           6   Sudatel Internet Exchange Aut
 6713      235        519          14   Itissalat Al-MAGHRIB
33776      231         13          10   Starcomms Nigeria Limited
29571      217         17          13   Ci Telecom Autonomous system 
12258      195         28          60   Vodacom Internet Company 
24835      190         80           8   RAYA Telecom - Egypt
16637      160        662          82   MTN Network Solutions

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3483       3814         218   bellsouth.net, inc. 
 7029     2912       1016         199   Windstream Communications Inc
 4766     2510      11105         973   Korea Telecom (KIX)
18566     2093        383         177   Covad Communications 
 1785     1852        680         120   PaeTec Communications, Inc.
10620     1702        315         180   TVCABLE BOGOTA 
17974     1652        503          38   PT TELEKOMUNIKASI INDONESIA
 7545     1626        303          87   TPG Internet Pty Ltd
 4323     1616       1073         386   Time Warner Telecom
20115     1603       1546         625   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
 7029      2912        2713      Windstream Communications Inc
18566      2093        1916      Covad Communications 
 1785      1852        1732      PaeTec Communications, Inc.
17974      1652        1614      PT TELEKOMUNIKASI INDONESIA
 7545      1626        1539      TPG Internet Pty Ltd
 4766      2510        1537      Korea Telecom (KIX)
 8402      1552        1537      Corbina telecom
10620      1702        1522      TVCABLE BOGOTA 
28573      1537        1465      NET Servicos de Comunicao S.A
22773      1507        1403      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
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
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
14764   UNALLOCATED  12.108.237.0/24       7018       AT&T WorldNet Servic

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

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

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

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

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

Network            Origin AS  Description
41.222.79.0/24       37345     MEDALLION Communications
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 
64.21.192.0/20       11610     Internet Nebraska Corporation
64.21.212.0/22       11610     Internet Nebraska Corporation
64.21.216.0/21       11610     Internet Nebraska Corporation
66.171.32.0/20         705     UUNET Technologies, Inc. 
66.175.222.0/23      30058     FDC Servers.net, LLC 
66.180.239.0/24      35888     VIGNETTE CORPORATION 

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:236     
/13:463     /14:807     /15:1437    /16:12055   /17:6113    /18:10143   
/19:20053   /20:27738   /21:28008   /22:38142   /23:35692   /24:198843  
/25:1181    /26:1400    /27:785     /28:14      /29:3       /30:0       
/31:0       /32:5       

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

  ASN   No of nets  Total ann.   Description
 7029     2541          2912      Windstream Communications Inc
 6389     2126          3483      bellsouth.net, inc. 
18566     2042          2093      Covad Communications 
10620     1597          1702      TVCABLE BOGOTA 
 8402     1527          1552      Corbina telecom
30036     1395          1435      Mediacom Communications Corp 
11492     1119          1156      Cable One 
 1785     1058          1852      PaeTec Communications, Inc.
 7011     1048          1165      Citizens Utilities 
22773      967          1507      Cox Communications, Inc.

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

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

   1:442       2:489       4:15        5:1         6:3         8:359    
  12:1947     13:1        14:548      15:11       16:3        17:7      
  20:9        23:69       24:1694     27:1059     31:717      32:67     
  33:2        34:2        36:4        38:770      39:1        40:114    
  41:2860     42:66       43:1        44:3        46:1111     47:3      
  49:292      50:450      52:13       55:6        56:2        57:49     
  58:939      59:486      60:358      61:1178     62:913      63:1968   
  64:4049     65:2308     66:4368     67:1998     68:1174     69:3147   
  70:904      71:361      72:1772     74:2641     75:430      76:320    
  77:907      78:890      79:438      80:1142     81:834      82:523    
  83:527      84:471      85:1164     86:410      87:907      88:341    
  89:1587     90:246      91:4314     92:532      93:1423     94:1327   
  95:1096     96:397      97:285      98:764      99:37      101:121    
 103:523     106:7       107:103     108:88      109:1120    110:668    
 111:818     112:367     113:487     114:622     115:700     116:896    
 117:708     118:870     119:1229    120:349     121:667     122:1567   
 123:1019    124:1348    125:1349    128:278     129:185     130:183    
 131:632     132:155     133:21      134:222     135:54      136:212    
 137:146     138:287     139:123     140:491     141:253     142:379    
 143:405     144:498     145:62      146:475     147:221     148:643    
 149:270     150:166     151:192     152:449     153:171     154:7      
 155:381     156:209     157:359     158:156     159:523     160:333    
 161:214     162:364     163:176     164:521     165:385     166:542    
 167:453     168:823     169:146     170:822     171:87      172:4      
 173:1767    174:586     175:418     176:329     177:411     178:1150   
 180:1178    181:39      182:669     183:242     184:399     185:1      
 186:1478    187:784     188:947     189:1164    190:5286    192:5965   
 193:5118    194:3555    195:3119    196:1283    197:169     198:3624   
 199:4235    200:5523    201:1696    202:8474    203:8494    204:4322   
 205:2409    206:2668    207:2839    208:4011    209:3551    210:2730   
 211:1473    212:1991    213:1804    214:813     215:92      216:4933   
 217:1486    218:577     219:340     220:1252    221:525     222:325    
 223:229    

End of report


From streiner at cluebyfour.org  Fri Dec  2 13:23:54 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 2 Dec 2011 14:23:54 -0500 (EST)
Subject: IP addresses are now assets
In-Reply-To: <20111202141151.GA20138@ussenterprise.ufp.org>
References: <20111202040423.GL1397@manor.msen.com>
 <20111202141151.GA20138@ussenterprise.ufp.org>
Message-ID: <Pine.LNX.4.64.1112021414001.3791@whammy.cluebyfour.org>

On Fri, 2 Dec 2011, Leo Bicknell wrote:

> In a message written on Thu, Dec 01, 2011 at 11:04:23PM -0500, Michael R. Wayne wrote:
>>    After negotiating with multiple prospective buyers, Cerner Corp.
>>    agreed to buy the Internet addresses for $12 each. Other bids were
>>    as low as $1.50 each, according to a bankruptcy court filing.
>
> Someone should tell Cerner Corp you can still get them for free,
> and thus they overpaid by oh, $12 an address!

I'm waiting for someone to come back and balk at $12/address, and try to 
reduce the number of addresses they buy, forgetting that pesky powers-of-two
business:  "In the interest of containing the cost of the deal, XYZ Corp has
agreed to buy 27,000 addresses instead of the original 65,536."

That will be a definite facepalm moment.

jms


From leigh.porter at ukbroadband.com  Fri Dec  2 13:29:43 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 2 Dec 2011 19:29:43 +0000
Subject: IP addresses are now assets
In-Reply-To: <Pine.LNX.4.64.1112021414001.3791@whammy.cluebyfour.org>
References: <20111202040423.GL1397@manor.msen.com>
 <20111202141151.GA20138@ussenterprise.ufp.org>
 <Pine.LNX.4.64.1112021414001.3791@whammy.cluebyfour.org>
Message-ID: <D181DDABABE57E4DB72FEE003314786444F267@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Justin M. Streiner [mailto:streiner at cluebyfour.org]
> Sent: 02 December 2011 19:26
> To: Leo Bicknell
> Cc: NANOG
> Subject: Re: IP addresses are now assets
> 
> On Fri, 2 Dec 2011, Leo Bicknell wrote:
> 
> > In a message written on Thu, Dec 01, 2011 at 11:04:23PM -0500,
> Michael R. Wayne wrote:
> >>    After negotiating with multiple prospective buyers, Cerner Corp.
> >>    agreed to buy the Internet addresses for $12 each. Other bids
> were
> >>    as low as $1.50 each, according to a bankruptcy court filing.
> >
> > Someone should tell Cerner Corp you can still get them for free,
> > and thus they overpaid by oh, $12 an address!
> 
> I'm waiting for someone to come back and balk at $12/address, and try
> to
> reduce the number of addresses they buy, forgetting that pesky powers-
> of-two
> business:  "In the interest of containing the cost of the deal, XYZ
> Corp has
> agreed to buy 27,000 addresses instead of the original 65,536."
> 
> That will be a definite facepalm moment.
> 
> jms


So about a /18 a /19 a /21 and a /23 then ;-)


--
Leigh



______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From jsahala at gmail.com  Fri Dec  2 13:37:29 2011
From: jsahala at gmail.com (joshua sahala)
Date: Fri, 2 Dec 2011 12:37:29 -0700
Subject: IP addresses are now assets
In-Reply-To: <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
Message-ID: <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>

On Thu, Dec 1, 2011 at 10:20 PM, John Curran <jcurran at arin.net> wrote:[cut]
> Your subject line (IP addresses are now assets) could mislead folks,
[cut]
ianal, but the treatment of ip addresses by the bankruptcy court would
tend to agree with the definition of an asset from webster's new world
law dictionary (http://law.yourdictionary.com/asset):

   Any property or right that is owned by a person or entity and has
   monetary value. See also liability.

   All of the property of a person or entity or its total value;
   entries on a balance sheet listing such property.

   intangible asset
      An asset that is not a physical thing and only evidenced by a
      written document.


the addresses are being exchanged for money, in order to pay a
debt...how is this not a sale of an asset?


> ARIN holds that IP address space is not property but is managed as a> public resource.

imho, if it were truly a 'public resource' and managed as such, it
would be returned to the appropriate rir for reassignment, rather than
being auctioned off to the highest bidder by a (commodities)
broker...administrative and processing fees are one thing, but this is
pure commoditisation of a so-called 'public resource' by speculators.

i am, unfortunately, in the minority on this topic


On Fri, Dec 2, 2011 at 8:33 AM, John Curran <jcurran at arin.net> wrote:
[cut]
> ?"Sale may be subject to compliance with certain requirements of
>  the American Registry of Internet Numbers ("ARIN") and the court
>  materials to date reflect this.

MAY versus WILL -- rfc2119 contains a pretty clear definition of each,
which i am pretty sure echoes legal precedent..but again, ianal, so,
ymmv, etc, etc



the speculative market exists and is growing, why do certain factions
of the community keep trying to pretend that it doesn't?

/joshua


From surfer at mauigateway.com  Fri Dec  2 13:47:46 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 2 Dec 2011 11:47:46 -0800
Subject: IP addresses are now assets
Message-ID: <20111202114746.BA3898EE@resin04.mta.everyone.net>



--- jsahala at gmail.com wrote:
the speculative market exists and is growing, why do certain factions
of the community keep trying to pretend that it doesn't?
-------------------------------------------


Because they're busy getting ipv6 up and that will make these things less important?  >;-)

scott


From jfbeam at gmail.com  Fri Dec  2 13:49:39 2011
From: jfbeam at gmail.com (Ricky Beam)
Date: Fri, 02 Dec 2011 14:49:39 -0500
Subject: IP addresses are now assets
In-Reply-To: <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
 <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
Message-ID: <op.v5vn01a5tfhldh@rbeam.xactional.com>

On Fri, 02 Dec 2011 14:37:29 -0500, joshua sahala <jsahala at gmail.com>  
wrote:
>    Any property or right that is owned by a person or entity and has
>    monetary value. See also liability.

If it was a RIR assignment, it's not "owned".  It's more akin to a  
"lease".  That said, there are documented rules/proceedures for  
transfering assignments.  I'm not entirely sure they apply here.

Legacy assignments are, obviously, a very different story.

--Ricky


From jlightfoot at gmail.com  Fri Dec  2 13:53:43 2011
From: jlightfoot at gmail.com (John Lightfoot)
Date: Fri, 2 Dec 2011 14:53:43 -0500
Subject: IP addresses are now assets
In-Reply-To: <-2177556483850811793@unknownmsgid>
References: <20111202040423.GL1397@manor.msen.com>
 <-2177556483850811793@unknownmsgid>
Message-ID: <00c601ccb12c$1b3b72e0$51b258a0$@gmail.com>

I have a boatload of IPv6 addresses I'm willing to sell at the low, low price of $.01 each.

-----Original Message-----
From: Christopher J. Pilkington [mailto:cjp at 0x1.net] 
Sent: Friday, December 02, 2011 12:18 PM
To: Michael R. Wayne
Cc: NANOG
Subject: Re: IP addresses are now assets

On Dec 1, 2011, at 23:04, "Michael R. Wayne" <wayne at staff.msen.com> wrote:

> After negotiating with multiple prospective buyers, Cerner Corp.
>   agreed to buy the Internet addresses for $12 each. Other bids were
>   as low as $1.50 each, according to a bankruptcy court filing.

Clearly the addresses with the last octet of 00 and ff should be discounted, since no one wants to be zero, and ff just seems to get everyone's attention.

-cjp



From bonomi at mail.r-bonomi.com  Fri Dec  2 13:56:35 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Fri, 2 Dec 2011 13:56:35 -0600 (CST)
Subject: IP addresses are now assets
In-Reply-To: <D181DDABABE57E4DB72FEE003314786444F267@EALPO1.ukbroadband.com>
Message-ID: <201112021956.pB2JuZDg012655@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Fri Dec  2 13:29:31 2011
> From: Leigh Porter <leigh.porter at ukbroadband.com>
> To: "Justin M. Streiner" <streiner at cluebyfour.org>,
>         Leo Bicknell
>  <bicknell at ufp.org>
> Subject: RE: IP addresses are now assets
> Date: Fri, 2 Dec 2011 19:29:43 +0000
> Cc: NANOG <nanog at nanog.org>
>
>
>
> > -----Original Message-----
> > From: Justin M. Streiner [mailto:streiner at cluebyfour.org]
> > Sent: 02 December 2011 19:26
> > To: Leo Bicknell
> > Cc: NANOG
> > Subject: Re: IP addresses are now assets
> > 
> > On Fri, 2 Dec 2011, Leo Bicknell wrote:
> > 
> > > In a message written on Thu, Dec 01, 2011 at 11:04:23PM -0500,
> > Michael R. Wayne wrote:
> > >>    After negotiating with multiple prospective buyers, Cerner Corp.
> > >>    agreed to buy the Internet addresses for $12 each. Other bids
> > were
> > >>    as low as $1.50 each, according to a bankruptcy court filing.
> > >
> > > Someone should tell Cerner Corp you can still get them for free,
> > > and thus they overpaid by oh, $12 an address!
> > 
> > I'm waiting for someone to come back and balk at $12/address, and try
> > to
> > reduce the number of addresses they buy, forgetting that pesky powers-
> > of-two
> > business:  "In the interest of containing the cost of the deal, XYZ
> > Corp has
> > agreed to buy 27,000 addresses instead of the original 65,536."
> > 
> > That will be a definite facepalm moment.
> > 
> > jms
>
>
> So about a /18 a /19 a /21 and a /23 then ;-)

Methinks it ought to be restricted to some combination of a /17, a /19, a /23,
a /29, and a /31.  It's all 'prime' number-space, after all.   <groan.




From henry at AegisInfoSys.com  Fri Dec  2 14:01:31 2011
From: henry at AegisInfoSys.com (Henry Yen)
Date: Fri, 2 Dec 2011 15:01:31 -0500
Subject: IP addresses are now assets
In-Reply-To: <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
 <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
Message-ID: <20111202200131.GT29174@nntp.AegisInfoSys.com>

On Fri, Dec 02, 2011 at 12:37:29PM -0700, joshua sahala wrote:
> On Thu, Dec 1, 2011 at 10:20 PM, John Curran <jcurran at arin.net> wrote:[cut]
> > Your subject line (IP addresses are now assets) could mislead folks,
> [cut]
> ianal, but the treatment of ip addresses by the bankruptcy court would
> tend to agree with the definition of an asset from webster's new world
> law dictionary (http://law.yourdictionary.com/asset):
> 
>    Any property or right that is owned by a person or entity and has
>    monetary value. See also liability.
> 
>    All of the property of a person or entity or its total value;
>    entries on a balance sheet listing such property.
> 
>    intangible asset
>       An asset that is not a physical thing and only evidenced by a
>       written document.
> 
> 
> the addresses are being exchanged for money, in order to pay a
> debt...how is this not a sale of an asset?

I guess I'm in the same minority in that I agree with you.

Note that "Asset" !== "Property".

The IP addresses in question are unquestionably "Assets" (albeit
"Restricted assets" or hard-to-value assets), but not so evidently
"Property".  So, the original subject line "IP addresses are now assets"
seems accurate; it does not say "IP addresses are now property".
Conflation of the two terms is in the mind of the reader, and perhaps
that's what John Curran was seeking to clarify.

-- 
Henry Yen                                       Aegis Information Systems, Inc.
Senior Systems Programmer                       Hicksville, New York


From bonomi at mail.r-bonomi.com  Fri Dec  2 14:06:58 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Fri, 2 Dec 2011 14:06:58 -0600 (CST)
Subject: IP addresses are now assets
In-Reply-To: <00c601ccb12c$1b3b72e0$51b258a0$@gmail.com>
Message-ID: <201112022006.pB2K6wAr012733@mail.r-bonomi.com>


"John Lightfoot" <jlightfoot at gmail.com> wrote;

> I have a boatload of IPv6 addresses I'm willing to sell at the low, low price of $.01 each.

Good for you.  _I_ have somewhat over 17.8 million IPv4 addresses, in 3 large
blocks, for which I will sell my 'right to use', at half your offering price.




From surfer at mauigateway.com  Fri Dec  2 14:05:37 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 2 Dec 2011 12:05:37 -0800
Subject: Looking for a Tier 1 ISP Mentor for career advice.
Message-ID: <20111202120537.BA389A4C@resin04.mta.everyone.net>



--- david at davidradcliffe.org wrote:
From: David Radcliffe <david at davidradcliffe.org>

Actually, the best reason I have for working from home is I work much better 
when naked and they have asked me to stop showing up that way at the office.
------------------------------------------------


Woah, woah, woah!  The absolute painnnnn of that image is breaking my mind apart! >;-) 

scott


From mike at mikejones.in  Fri Dec  2 14:14:58 2011
From: mike at mikejones.in (Mike Jones)
Date: Fri, 2 Dec 2011 20:14:58 +0000
Subject: IP addresses are now assets
In-Reply-To: <20111202200131.GT29174@nntp.AegisInfoSys.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
 <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
 <20111202200131.GT29174@nntp.AegisInfoSys.com>
Message-ID: <CAAAas8HAq4z+ONpXuP-9V-JOZfN4zNXYDZmAA0Ufaq5JT5QpSw@mail.gmail.com>

On 2 December 2011 20:01, Henry Yen <henry at aegisinfosys.com> wrote:
> On Fri, Dec 02, 2011 at 12:37:29PM -0700, joshua sahala wrote:
>> On Thu, Dec 1, 2011 at 10:20 PM, John Curran <jcurran at arin.net> wrote:[cut]
>> > Your subject line (IP addresses are now assets) could mislead folks,
>> [cut]
>> ianal, but the treatment of ip addresses by the bankruptcy court would
>> tend to agree with the definition of an asset from webster's new world
>> law dictionary (http://law.yourdictionary.com/asset):
>>
>> ? ?Any property or right that is owned by a person or entity and has
>> ? ?monetary value. See also liability.
>>
>> ? ?All of the property of a person or entity or its total value;
>> ? ?entries on a balance sheet listing such property.
>>
>> ? ?intangible asset
>> ? ? ? An asset that is not a physical thing and only evidenced by a
>> ? ? ? written document.
>>
>>
>> the addresses are being exchanged for money, in order to pay a
>> debt...how is this not a sale of an asset?
>
> I guess I'm in the same minority in that I agree with you.
>
> Note that "Asset" !== "Property".
>
> The IP addresses in question are unquestionably "Assets" (albeit
> "Restricted assets" or hard-to-value assets), but not so evidently
> "Property". ?So, the original subject line "IP addresses are now assets"
> seems accurate; it does not say "IP addresses are now property".
> Conflation of the two terms is in the mind of the reader, and perhaps
> that's what John Curran was seeking to clarify.
>

What about land? it's a public resource that you've paid money to
someone in exchange for transferring their rights over that public
resource to you.

That said, I think in the case of land shortages there is an argument
that land no longer being used by someone should be freed up for use
by new people. Although i'm not entirely sure how to justify a
"instead of selling it you have to return it so it can be allocated to
whoever has a need for it" policy without also justifying the same for
my house, which has spare rooms that I don't need.

- Mike


From jloiacon at csc.com  Fri Dec  2 14:28:22 2011
From: jloiacon at csc.com (Joe Loiacono)
Date: Fri, 2 Dec 2011 15:28:22 -0500
Subject: IP addresses are now assets
In-Reply-To: <CAAAas8HAq4z+ONpXuP-9V-JOZfN4zNXYDZmAA0Ufaq5JT5QpSw@mail.gmail.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
 <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
 <20111202200131.GT29174@nntp.AegisInfoSys.com>
 <CAAAas8HAq4z+ONpXuP-9V-JOZfN4zNXYDZmAA0Ufaq5JT5QpSw@mail.gmail.com>
Message-ID: <OFDAF8761E.84A6303A-ON8525795A.00703E5A-8525795A.007076A7@csc.com>

Mike Jones <mike at mikejones.in> wrote on 12/02/2011 03:14:58 PM:

> What about land? it's a public resource that you've paid money to
> someone in exchange for transferring their rights over that public
> resource to you.

Land is private property.

Joe

From surfer at mauigateway.com  Fri Dec  2 14:30:53 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 2 Dec 2011 12:30:53 -0800
Subject: Looking for a Tier 1 ISP Mentor for career advice.
Message-ID: <20111202123053.BA389EAF@resin04.mta.everyone.net>



--- bicknell at ufp.org wrote:
From: Leo Bicknell <bicknell at ufp.org>

If you have telecommuters _everyone_ in the office should be forced
to work from home at least 2 weeks a year, including the manager.
It's only from that experience you learn to deal with your telecommuting
co-workers in a way that raises everyone's productivity.
---------------------------------------------

I have been bemoaning the lack of telecommuting positions available 
since I last did that permanently from 1998-2002.  I could never 
figure out how to get the managers since then to understand how to
manage remote workers effectively, as that's what I think the problem 
is.  The manager's ability to value an employee in this century's 
methodology, rather than the old way: "wow, he was in the office 10 
hours today.  He must've gotten a lot of work done".  When, actually, 
the person played around for 6 of those hours while looking busy.  

Having the manager work from home, even temporarily, would solve this.
Now if I can just get them to actually do that...  :-)



---------------------------------------------------
Once over that hump there are huge rewards to having telecommuters.
You can pay lower salaries as people can live in cheaper locations.
---------------------------------------------------

The company gets to pay for less space, too.  Have a "hot cube" where
everyone uses it for the day(s) they need to work in the office.


I really hope manager-types are listening.  You limit yourselves to
those available in your immediate area and the skills they have.
Opening yourselves to telecommuting allows you to hire folks with 
skills that may match your needs more effectively.  

Personally, I am working at smaller networks than I would like to,
but I get to live on Kauai and surf places like this every day:

www.imagemania.net/data/media/22/Polihale%20Beach,%20Kauai,%20Hawaii.jpg

when I'd rather get back into BGP and operating large networks because I 
enjoy it.  However, I will not give up life's fun things just to do that 
for a living.  I know I'm not the only one out there who thinks this way.

scott












--- bicknell at ufp.org wrote:

From: Leo Bicknell <bicknell at ufp.org>
To: nanog at nanog.org
Subject: Re: Looking for a Tier 1 ISP Mentor for career advice.
Date: Fri, 2 Dec 2011 07:37:08 -0800

In a message written on Fri, Dec 02, 2011 at 12:25:41PM +0000, Thorsten Dahm wrote:
> The downside of this is that you are not around in the office in case 
> someone wants to talk to you. I often end up with guys from our 
> operations team or other teams stopping at my desk and ask questions. Or 
> guys who want to have a quick chat about a problem and want to ask for 
> an advice or idea. Or people who want to learn Perl and have a question 
> that you can answer in 30 seconds.

I've both delt with remote employees and been a telecommuter.  After
those experiences, and reading a few books I've decided the hardest
thing about having successful telecommuters is dealing with the
folks in the office.

Telecommuters quickly turn to technology, they want to video-chat
with collegues.  Are eager to pick up the phone and talk.  They
reach out (generally).  It's the folks in the office that are
reluctant.  They don't see the point of figuring out how the video
chat software works, of setting their status to indicate what they
are doing, and so on.

The "water cooler" conversations can be moved to Skype, FaceTime,
Google Hangouts, or any number of other solutions, but it requires
everyone to be in that mindset.

If you have telecommuters _everyone_ in the office should be forced
to work from home at least 2 weeks a year, including the manager.
It's only from that experience you learn to deal with your telecommuting
co-workers in a way that raises everyone's productivity.

Once over that hump there are huge rewards to having telecommuters.
You can pay lower salaries as people can live in cheaper locations.
People in multiple timezones provide better natural coverage.  People
are much more willing to do off hour work when they can roll out
of bed at 5AM and be working at 5:05 in their PJ's, rather than
getting up at 4 and getting dressed to drive in and do the work.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/




From surfer at mauigateway.com  Fri Dec  2 14:33:12 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 2 Dec 2011 12:33:12 -0800
Subject: Looking for a Tier 1 ISP Mentor for career advice.
Message-ID: <20111202123312.BA389E70@resin04.mta.everyone.net>



Apologies for the rapid-shot email.  It's Friday...  :-)


--- bmanning at vacation.karoshi.com wrote:
From: bmanning at vacation.karoshi.com

On Thu, Dec 01, 2011 at 04:35:27PM -0500, David Radcliffe wrote:
> The reason it is not more accepted is too many people still think "If I cannot 
> see you you must not be working."
> 

	actually, i've heard the real reason is corporate liability ...
	that said, there is an advantage for team f2f mtgs on a periodic
	basis.
----------------------------------------------


I don't follow.  Could you elaborate?  What is the liability?

scott


From jgreco at ns.sol.net  Fri Dec  2 14:36:38 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Fri, 2 Dec 2011 14:36:38 -0600 (CST)
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <4ED8FF93.1050603@resolution.de>
Message-ID: <201112022036.pB2Kacxg019907@aurora.sol.net>

> Am 12/2/11 1:16 PM, schrieb Joe Greco:
> >> Thorsten Dahm:
> >> The downside of this is that you are not around in the office in case
> >> someone wants to talk to you. I often end up with guys from our
> >> operations team or other teams stopping at my desk and ask questions. Or
> >> guys who want to have a quick chat about a problem and want to ask for
> >> an advice or idea. Or people who want to learn Perl and have a question
> >> that you can answer in 30 seconds.
> >
> > Which really stops being practical once you exceed (approx) one building
> > in size.
> 
> I think it often depends on how you define practical. Normally, you sit 
> with your own team, that means it is a practical solution for the 
> network engineers, but perhaps not for the server admins and the network 
> engineers anymore, since the server admins may sit in a different 
> building, different city, different continent, ....

While any absolute rule would be silly, of course, I would have thought my
point was sufficiently clear.  There comes a point at which all the people
you may want to talk to are no longer sitting in the same building.  That
doesn't mean all buildings will successfully allow F2F meetings (Pentagon)
or that having groups within the same building will encourage F2F meetings.
It's a simple fact that once you *must* deal with someone in another building,
the amount of time and effort involved gets much higher and more inconvenient.
If you manage to find a way to keep your group small and all in the same
building, then what I said doesn't apply, but that can itself become
impractical as a company grows.

... 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 bicknell at ufp.org  Fri Dec  2 14:51:32 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 2 Dec 2011 12:51:32 -0800
Subject: IP addresses are now assets
In-Reply-To: <OFDAF8761E.84A6303A-ON8525795A.00703E5A-8525795A.007076A7@csc.com>
References: <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
 <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
 <20111202200131.GT29174@nntp.AegisInfoSys.com>
 <CAAAas8HAq4z+ONpXuP-9V-JOZfN4zNXYDZmAA0Ufaq5JT5QpSw@mail.gmail.com>
 <OFDAF8761E.84A6303A-ON8525795A.00703E5A-8525795A.007076A7@csc.com>
Message-ID: <20111202205132.GA35186@ussenterprise.ufp.org>

In a message written on Fri, Dec 02, 2011 at 03:28:22PM -0500, Joe Loiacono wrote:
> Mike Jones <mike at mikejones.in> wrote on 12/02/2011 03:14:58 PM:
> > What about land? it's a public resource that you've paid money to
> > someone in exchange for transferring their rights over that public
> > resource to you.
> 
> Land is private property.

Some land in some countries is private property.

-- 
       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/20111202/6a70690f/attachment.bin>

From morrowc.lists at gmail.com  Fri Dec  2 15:06:31 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 2 Dec 2011 16:06:31 -0500
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <20111202143554.GA66539@snar.spb.ru>
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
 <20111202143554.GA66539@snar.spb.ru>
Message-ID: <CAL9jLaY7qeqP6f7yx0d9LRqLt2-PBrGuVbwWh+xxNnz6a3cKOQ@mail.gmail.com>

On Fri, Dec 2, 2011 at 9:35 AM, Alexandre Snarskii <snar at snar.spb.ru> wrote:

> This draft says that

...note it's a DRAFT, not a STANDARD...

>
> If a BGP speaker receives a route which has an AS number of zero in the
> AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a
> WITHDRAW. This same behavior applies to routes containing zero as the
> Aggregator or AS4 Aggregator.
>
> but observed behaviour was more like following:
>
> If a BGP speaker receives [bad route] it MUST close session immediately
> with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with
> optional attribute'.

hence this old behavor


From jcurran at arin.net  Fri Dec  2 15:08:58 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 2 Dec 2011 21:08:58 +0000
Subject: IP addresses are now assets
In-Reply-To: <CAMDXq5PzrUhUUi3brBjWN1-bOBMhFUVVvVVJA0YCfc=4UiFoPQ@mail.gmail.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <CAMDXq5PzrUhUUi3brBjWN1-bOBMhFUVVvVVJA0YCfc=4UiFoPQ@mail.gmail.com>
Message-ID: <787B2512-1152-42DB-8022-D28C13CFD9A6@corp.arin.net>

On Dec 2, 2011, at 10:16 AM, Martin Hannigan wrote:

> ARIN, on many occasions, has stated that they have no authority over
> legacy address space. They made this declaration in the Kamens/sex.com
> case. I haven't heard that anything has changed since then.

Martin - 

ARIN will maintain the registry in accordance with community policy
for all addresses and that includes legacy address space.

Thanks,
/John

John Curran
President and CEO
ARIN



From tvhawaii at shaka.com  Fri Dec  2 15:12:22 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Fri, 2 Dec 2011 11:12:22 -1000
Subject: Wired mag piece on the Water Utility SCADA 'Attack'
References: <21004746.1127.1322750495937.JavaMail.root@benjamin.baylink.com>
Message-ID: <769C9B4F0AAD420E9E776AA03EFDBDB2@owner59e1f1502>

Jay Ashworth wrote:
> Damn that was quick:
>
>  http://j.mp/rvWnEC

And more FUD from the FBI?

http://www.information-age.com/channels/security-and-continuity/news/1676243/hackers-accessed-city-infrastructure-via-scada-fbi.thtml 



From jsahala at gmail.com  Fri Dec  2 15:12:53 2011
From: jsahala at gmail.com (joshua sahala)
Date: Fri, 2 Dec 2011 14:12:53 -0700
Subject: IP addresses are now assets
In-Reply-To: <CAAAas8HAq4z+ONpXuP-9V-JOZfN4zNXYDZmAA0Ufaq5JT5QpSw@mail.gmail.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
 <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
 <20111202200131.GT29174@nntp.AegisInfoSys.com>
 <CAAAas8HAq4z+ONpXuP-9V-JOZfN4zNXYDZmAA0Ufaq5JT5QpSw@mail.gmail.com>
Message-ID: <CA+WCFcM-4bRKjhY8_nXV=X+Jd_3WaEeCtj+C4usPCAvyMbL0Rg@mail.gmail.com>

>> On Fri, Dec 02, 2011 at 12:37:29PM -0700, joshua sahala wrote:

>>> ? ?Any property or right that is owned by a person or entity and has
>>> ? ?monetary value. See also liability.
>>>
>>> ? ?All of the property of a person or entity or its total value;
>>> ? ?entries on a balance sheet listing such property.
>>>
>>> ? ?intangible asset
>>> ? ? ? An asset that is not a physical thing and only evidenced by a
>>> ? ? ? written document.
>>>

> On 2 December 2011 20:01, Henry Yen <henry at aegisinfosys.com> wrote:
>> Note that "Asset" !== "Property".

reread the definition:  an asset is property.  an intangible asset is
merely one type of asset.


On Fri, Dec 2, 2011 at 1:14 PM, Mike Jones <mike at mikejones.in> wrote:
> What about land? it's a public resource that you've paid money to
> someone in exchange for transferring their rights over that public
> resource to you.

land is a tangible asset, and has largely been privatised when it
comes to ownership.  you can lease public lands, but when your lease
ends, it is returned to the "owner" (the government), and any
"improvements" (if allowed at all) are torn down or given over.
sometimes you can sublet your lease, but this doesn't make it a new
contract or change the original terms.


> That said, I think in the case of land shortages there is an argument
> that land no longer being used by someone should be freed up for use
> by new people.

this starts drifting into a philosophical debate on privatisation and
the use, control, and management of 'the commons' (land, water, air,
etc.) and something which is largely (further) offtopic for this list.

but, i digress...and the various dead horses here have all been beaten
beyond recognition

/joshua
-- 
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
? ? ? ? - Douglas Adams -


From tayeb.meftah at gmail.com  Thu Dec  1 13:40:58 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 1 Dec 2011 21:40:58 +0200
Subject: MPLS based routing
Message-ID: <9534BC585E6B42998E44A47A5FBC0730@work>

hello guys,
if i want to label my routes in a cisco router
i did run through ldp configuration step
now i see that labels are distributed, but if i traceroute it from another router i didn't see the icmp arg for the mpls label
did i miss anything?
atached my configuration :)
    Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213660347746


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6678 (20111202) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: c2800
Type: application/octet-stream
Size: 4106 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111201/b93946ee/attachment.obj>

From jcurran at arin.net  Fri Dec  2 15:39:19 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 2 Dec 2011 21:39:19 +0000
Subject: IP addresses are now assets
In-Reply-To: <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
 <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
Message-ID: <7B8BD3E7-7CFB-4056-AE9A-6B99506245C5@corp.arin.net>

On Dec 2, 2011, at 2:37 PM, joshua sahala wrote:

>   intangible asset
>      An asset that is not a physical thing and only evidenced by a
>      written document.
> 
> the addresses are being exchanged for money, in order to pay a
> debt...how is this not a sale of an asset?

Joshua - 
 
  Rights to addresses (in the registration database) are being 
  transferred for money.  Those rights may indeed be "assets"
  (although that's likely a question better suited for lawyers)

  Perhaps "Rights to IP addresses can be sold!" would be a better
  title, but it's not exactly newsworthy since we've all known that
  for some time: <http://www.circleid.com/posts/psst_interested_in_some_lightly_used_ip_addresses/>

>> ARIN holds that IP address space is not property but is managed as a> public resource.
> 
> imho, if it were truly a 'public resource' and managed as such, it
> would be returned to the appropriate rir for reassignment, rather than
> being auctioned off to the highest bidder by a (commodities) broker...

 Agreed.  However, attempting fairly to administrate a resource 
 as it becomes increasingly scarce is quite problematic, and yet
 there is a real need emerging among network operators for IPv4 
 space as the regional free pool diminishes.  The limited market
 mechanism provides a motivation for getting these resources back
 into use, while still taking the communities need for accurate  
 record keeping and avoidance of deaggregation into consideration.

> administrative and processing fees are one thing, but this is
> pure commoditisation of a so-called 'public resource' by speculators.
> 
> i am, unfortunately, in the minority on this topic

 It shouldn't be speculators, unless they're particularly skilled
 at faking the operational need for the space they're obtaining
 and willing to risk losing the entire investment if detected.

> On Fri, Dec 2, 2011 at 8:33 AM, John Curran <jcurran at arin.net> wrote:
> [cut]
>>  "Sale may be subject to compliance with certain requirements of
>> the American Registry of Internet Numbers ("ARIN") and the court
>> materials to date reflect this.
> 
> MAY versus WILL -- rfc2119 contains a pretty clear definition of each,
> which i am pretty sure echoes legal precedent..but again, ianal, so,
> ymmv, etc, etc

 I referenced that language because it is in the public solicitation.
 Actual legal documents on transfers to date have been quite explicit
 on this point.

> the speculative market exists and is growing, why do certain factions
> of the community keep trying to pretend that it doesn't?

 Again, there is a limited market emerging in IPv4 address space, one 
 in which the transfer recipient must demonstrate an operational need.

 Attempting to use the transfer policy to speculate would be rather
 adventurous (since one must agree contractually to compliance with 
 the registry policies and to the veracity of the information on the 
 transfer request...)  That doesn't mean it won't happen, only that we 
 hope that it will not get materially in the way of service providers
 who do need additional address space.

FYI,
/John

John Curran
President and CEO
ARIN




From cidr-report at potaroo.net  Fri Dec  2 16:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 2 Dec 2011 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201112022200.pB2M00w8061222@wattle.apnic.net>

BGP Update Report
Interval: 24-Nov-11 -to- 01-Dec-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS42116          155829  8.6%    2554.6 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
 2 - AS17974           56880  3.1%      29.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
 3 - AS9829            51998  2.9%      76.9 -- BSNL-NIB National Internet Backbone
 4 - AS7552            35758  2.0%      25.7 -- VIETEL-AS-AP Vietel Corporation
 5 - AS8402            34317  1.9%      23.4 -- CORBINA-AS OJSC "Vimpelcom"
 6 - AS19743           31349  1.7%    5224.8 -- 
 7 - AS32528           23173  1.3%    5793.2 -- ABBOTT Abbot Labs
 8 - AS5800            23021  1.3%      93.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 9 - AS20632           19705  1.1%    2463.1 -- PETERSTAR-AS PeterStar
10 - AS27738           17426  1.0%      51.3 -- Ecuadortelecom S.A.
11 - AS24560           15430  0.8%      19.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
12 - AS31148           14932  0.8%      36.2 -- FREENET-AS FreeNet ISP
13 - AS19223           12750  0.7%   12750.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions
14 - AS6316            11179  0.6%    2235.8 -- AS-PAETEC-NET - PaeTec Communications, Inc.
15 - AS45595           10053  0.6%      60.9 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited
16 - AS16322            8751  0.5%      71.1 -- PARSONLINE PARSONLINE Autonomous System
17 - AS3255             8074  0.5%      49.8 -- UARNET-AS Ukrainian Academic and Research Network
18 - AS4                8066  0.5%       6.0 -- Maria Irma Salazar
19 - AS9583             7792  0.4%       9.5 -- SIFY-AS-IN Sify Limited
20 - AS14522            7656  0.4%      37.3 -- Satnet


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS19223           12750  0.7%   12750.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions
 2 - AS32528           23173  1.3%    5793.2 -- ABBOTT Abbot Labs
 3 - AS19743           31349  1.7%    5224.8 -- 
 4 - AS42116          155829  8.6%    2554.6 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
 5 - AS20632           19705  1.1%    2463.1 -- PETERSTAR-AS PeterStar
 6 - AS6316            11179  0.6%    2235.8 -- AS-PAETEC-NET - PaeTec Communications, Inc.
 7 - AS4                8066  0.5%       6.0 -- Maria Irma Salazar
 8 - AS39353            3701  0.2%    1233.7 -- PRINCAST-AS Gobierno del Principado de Asturias
 9 - AS40329            1142  0.1%    1142.0 -- REH-PROPERTY - REH Property
10 - AS38528             977  0.1%     977.0 -- LANIC-AS-AP Lao National Internet Committee
11 - AS53362             961  0.1%     961.0 -- MIXIT-AS - Mixit, Inc.
12 - AS8163              848  0.1%     848.0 -- METROTEL REDES S.A.
13 - AS10099             732  0.0%     732.0 -- HKUNICOM1-AP China Unicom (Hong Kong) Operations Limited
14 - AS57282             612  0.0%     612.0 -- SOPREX-AS SOPREX D.o.o.
15 - AS55696             596  0.0%     596.0 -- SCOM-AS-ID Starcom Solusindo PT.
16 - AS48068             566  0.0%     566.0 -- VISONIC Visonic Ltd
17 - AS11943             533  0.0%     533.0 -- GLOBE - Globe Wireless
18 - AS33076             505  0.0%     505.0 -- ISC-TGD1 Internet Systems Consortium, Inc.
19 - AS24562             493  0.0%     493.0 -- UNESCAP-AS-AP The United Nations Economic and Social Commission for Asia and the Pacific (ESCAP)
20 - AS10445            1878  0.1%     469.5 -- HTG - Huntleigh Telcom


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 84.204.132.0/24   19656  1.0%   AS20632 -- PETERSTAR-AS PeterStar
 2 - 67.97.156.0/24    12750  0.7%   AS19223 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions
 3 - 130.36.34.0/24    11582  0.6%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/24    11582  0.6%   AS32528 -- ABBOTT Abbot Labs
 5 - 176.213.100.0/22   7269  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
 6 - 65.122.196.0/24    7193  0.4%   AS19743 -- 
 7 - 190.96.120.0/21    6725  0.3%   AS4     -- Maria Irma Salazar
 8 - 66.248.104.0/21    6487  0.3%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 9 - 95.78.100.0/22     6364  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
10 - 95.78.104.0/22     6364  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
11 - 95.78.108.0/22     6357  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
12 - 95.78.88.0/22      6357  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
13 - 95.78.84.0/22      6351  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
14 - 46.147.92.0/22     6328  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
15 - 46.147.120.0/22    6320  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
16 - 95.78.0.0/22       6303  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
17 - 95.78.20.0/22      6294  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
18 - 95.78.8.0/22       6264  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
19 - 95.78.80.0/22      6264  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
20 - 95.78.16.0/22      6262  0.3%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"

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

This report has been generated at Fri Dec  2 21:12:17 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
        25-11-11    385336      226339
        26-11-11    385360      226218
        27-11-11    385375      226061
        28-11-11    385468      226133
        29-11-11    385372      226417
        30-11-11    385256      226157
        01-12-11    385044      226357
        02-12-11    385297      226059


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

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

Table     385422   226094   159328    41.3%   All ASes

AS6389      3484      221     3263    93.7%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS18566     2094      406     1688    80.6%   COVAD - Covad Communications
                                               Co.
AS4766      2514      996     1518    60.4%   KIXS-AS-KR Korea Telecom
AS7029      2953     1527     1426    48.3%   WINDSTREAM - Windstream
                                               Communications Inc
AS22773     1507      113     1394    92.5%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1508      212     1296    85.9%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS4323      1617      388     1229    76.0%   TWTC - tw telecom holdings,
                                               inc.
AS28573     1538      391     1147    74.6%   NET Servicos de Comunicao S.A.
AS1785      1856      783     1073    57.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS19262     1388      402      986    71.0%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS10620     1703      726      977    57.4%   Telmex Colombia S.A.
AS7552      1386      415      971    70.1%   VIETEL-AS-AP Vietel
                                               Corporation
AS7303      1239      359      880    71.0%   Telecom Argentina S.A.
AS18101      959      156      803    83.7%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS8151      1338      546      792    59.2%   Uninet S.A. de C.V.
AS8402      1492      709      783    52.5%   CORBINA-AS OJSC "Vimpelcom"
AS30036     1435      681      754    52.5%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS4808      1079      336      743    68.9%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS7545      1626      947      679    41.8%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS17974     1653      974      679    41.1%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS3356      1102      455      647    58.7%   LEVEL3 Level 3 Communications
AS17676      673       72      601    89.3%   GIGAINFRA Softbank BB Corp.
AS24560      985      392      593    60.2%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS20115     1603     1029      574    35.8%   CHARTER-NET-HKY-NC - Charter
                                               Communications
AS4804       664       95      569    85.7%   MPX-AS Microplex PTY LTD
AS22561      931      376      555    59.6%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS22047      582       33      549    94.3%   VTR BANDA ANCHA S.A.
AS17488      945      413      532    56.3%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS3549       951      422      529    55.6%   GBLX Global Crossing Ltd.
AS7011      1169      647      522    44.7%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.

Total      43974    15222    28752    65.4%   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       AS37345 MEDALLION
        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.175.222.0/23      AS30058 FDCSERVERS - FDCservers.net
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        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 
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        80.88.10.0/24        AS33774 DJAWEB
        98.159.96.0/20       AS46975 
        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)
        176.227.144.0/20     AS29119 SERVIHOSTING-AS ServiHosting Networks S.L.
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        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.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.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.9.55.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.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.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 
        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 France Telecom S.A.
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications 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
        209.222.240.0/22     AS19747 
        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.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 jeff.tantsura at ericsson.com  Fri Dec  2 16:14:35 2011
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Fri, 2 Dec 2011 17:14:35 -0500
Subject: bgp update destroying transit on redback routers ?
In-Reply-To: <20111202143554.GA66539@snar.spb.ru>
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
 <20111202143554.GA66539@snar.spb.ru>
Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C2EDEB6@EUSAACMS0701.eamcs.ericsson.se>

Hi Alexandre,

You are right, the behavior is exactly as per RFC4271 section 6:
"When any of the conditions described here are detected, a
NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed.
So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and close the connection.

Ideally it should be treated as "treat-as-withdraw" as per draft-chen-ebgp-error-handling, however please note - this is still a draft, 
not a normative document and with all my support it takes time to implement.

Once again, we understand the implications for our customers and hence going to disable ASN 0 check.

P.S. We have strong evidence that the update in question was caused by a bug on a freshly updated router (I'm not going to disclose the vendor) 

Regards,
Jeff


-----Original Message-----
From: Alexandre Snarskii [mailto:snar at snar.spb.ru] 
Sent: Friday, December 02, 2011 6:36 AM
To: Jeff Tantsura
Cc: nanog at nanog.org
Subject: Re: bgp update destroying transit on redback routers ?

On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote:
> Hi,
> 
> Let me take it over from now on, I'm the IP Routing/MPLS Product 
> Manager at Ericsson responsible for all routing protocols.
> There's nothing wrong in checking ASN in AGGREGATOR, we don't really 
> want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 
> (draft-ietf-idr-as0-00) came into the worlds.

This draft says that

If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator.

but observed behaviour was more like following: 

If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with optional attribute'.

--
In theory, there is no difference between theory and practice. 
But, in practice, there is. 



From Valdis.Kletnieks at vt.edu  Fri Dec  2 16:56:17 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 02 Dec 2011 17:56:17 -0500
Subject: IP addresses are now assets
In-Reply-To: Your message of "Fri, 02 Dec 2011 12:37:29 MST."
 <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
 <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
Message-ID: <12129.1322866577@turing-police.cc.vt.edu>

On Fri, 02 Dec 2011 12:37:29 MST, joshua sahala said:
> the speculative market exists and is growing, why do certain factions
> of the community keep trying to pretend that it doesn't?

I'm sure at least some of those factions pretend it doesn't because admitting
it does would be a game changer.  I'm sure that *somebody* has a business model
that assumes the non-existence of the speculatie market.  And everybody knows
that you never admit the business model is crap until *after* the IPO. ;)

-------------- 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/20111202/b7bdd78f/attachment.bin>

From owen at delong.com  Fri Dec  2 17:01:56 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 2 Dec 2011 15:01:56 -0800
Subject: IP addresses are now assets
In-Reply-To: <12129.1322866577@turing-police.cc.vt.edu>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <44762.1322812111@turing-police.cc.vt.edu>
 <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
 <CAM9VJk3-JXKpiG=Q5=5nHi2-mP83My8N9ahMsocdRKtNRkvuGg@mail.gmail.com>
 <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net>
 <D181DDABABE57E4DB72FEE003314786444EAE5@EALPO1.ukbroadband.com>
 <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net>
 <CA+WCFcNJQP9aD710vqjSbziQx+Ght_T=vdWug4iBk322CoyZgw@mail.gmail.com>
 <12129.1322866577@turing-police.cc.vt.edu>
Message-ID: <4B760F89-5969-4EE1-B111-E9BF0B9F20B0@delong.com>


On Dec 2, 2011, at 2:56 PM, Valdis.Kletnieks at vt.edu wrote:

> On Fri, 02 Dec 2011 12:37:29 MST, joshua sahala said:
>> the speculative market exists and is growing, why do certain factions
>> of the community keep trying to pretend that it doesn't?
> 
> I'm sure at least some of those factions pretend it doesn't because admitting
> it does would be a game changer.  I'm sure that *somebody* has a business model
> that assumes the non-existence of the speculatie market.  And everybody knows
> that you never admit the business model is crap until *after* the IPO. ;)
> 

I admit it exists, but, I think it is currently relatively small and would hate to provide
it any additional incentives to grow. I think it has the potential to be very harmful
to the IPv4 internet in general. As long as it is relatively small, it's like a mosquito.
Turning it into a B-17 would be bad.

Just my $0.02.

Owen



From bonomi at mail.r-bonomi.com  Fri Dec  2 17:55:23 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Fri, 2 Dec 2011 17:55:23 -0600 (CST)
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <20111202123312.BA389E70@resin04.mta.everyone.net>
Message-ID: <201112022355.pB2NtNCh014147@mail.r-bonomi.com>


 "Scott Weeks" <surfer at mauigateway.com> wrote:
>
> Apologies for the rapid-shot email.  It's Friday...  :-)
>
> bmanning at vacation.karoshi.com wrote:
>
>> On Thu, Dec 01, 2011 at 04:35:27PM -0500, David Radcliffe wrote:
>> > The reason it is not more accepted is too many people still think "If I 
>> > cannot see you you must not be working."
>>
>>     actually, i've heard the real reason is corporate liability ...
>>     that said, there is an advantage for team f2f mtgs on a periodic
>>     basis.
>
> I don't follow.  Could you elaborate?  What is the liability?

I don't know for certain, but I expect "work at home' employeees fall under
the scope of the employers "Workmans Compenstation" liability covrerage,
with regard to injuries sustained "on the job".

Now, consider what happens if the employee sustains an 'on the job' injury,
due to something in the 'workplace' (done by the homeowner on his own time)
that is _NOT_ "OHSA-compliant".

At that point, as it is sometimes put in U.S. Dept. of Ag. bureaucratese:

  'A large quantity of organic waste/byproducts forcefully impacted the
   high-speed rotary impeller."




From eric at roxanne.org  Fri Dec  2 18:09:55 2011
From: eric at roxanne.org (Eric Gauthier)
Date: Fri, 2 Dec 2011 19:09:55 -0500
Subject: ISP access in Ogden, UT
Message-ID: <20111203000954.GA27743@roxanne.org>

looking for 100 mbps access to a new office in Ogden, UT but don't
know who the decent players are who already have fiber locally so
we can avoid huge build out costs.  Suggestions off list would be 
appreciated!

- Eric :)


From bret at getjive.com  Fri Dec  2 18:26:13 2011
From: bret at getjive.com (Bret Palsson)
Date: Fri, 2 Dec 2011 17:26:13 -0700
Subject: ISP access in Ogden, UT
In-Reply-To: <20111203000954.GA27743@roxanne.org>
References: <20111203000954.GA27743@roxanne.org>
Message-ID: <-8215472759514631341@unknownmsgid>

Xmission if they service there.

Sent from my iPhone

On Dec 2, 2011, at 5:10 PM, Eric Gauthier <eric at roxanne.org> wrote:

> looking for 100 mbps access to a new office in Ogden, UT but don't
> know who the decent players are who already have fiber locally so
> we can avoid huge build out costs.  Suggestions off list would be
> appreciated!
>
> - Eric :)
>


From mysidia at gmail.com  Fri Dec  2 18:26:48 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 2 Dec 2011 18:26:48 -0600
Subject: IP addresses are now assets
In-Reply-To: <20111202040423.GL1397@manor.msen.com>
References: <20111202040423.GL1397@manor.msen.com>
Message-ID: <CAAAwwbVire3eY=tfe_tRH_WjysW3O4PDmuxn0egCxDj4YbrN8A@mail.gmail.com>

On Thu, Dec 1, 2011 at 10:04 PM, Michael R. Wayne <wayne at staff.msen.com> wrote:
> From http://www.detnews.com/article/20111201/BIZ/112010483/1361/Borders-selling-Internet-addresses-for-$786-000
> ? Borders selling Internet addresses for $786,000

Your IP address is an "asset"  like the office you rent to setup a business in.
Happening to be the occupant gives you certain rights, but it doesn't
automatically make the space some property that the occupant automatically
gains ownership of.

If your lease permits it, you can probably re-sell your right to
occupy the space,
so long as the lease says you can do that, and you follow all the terms and
requirements agreed upon.

So there's no issue with Borders "selling" addresses, so long as the
proper policies are being followed
for transfer of addresses.


What underlies all the "occupants" of IP address space, are agreements
with IP address
registries, and the community,  to provide unique usage of IP addresses.

The existence of unique IP addresses exist only because of the
community and the address
registries' efforts;  the community "owns"  the uniqueness of IP
addresses, which is a kind
of intangible property,  because they built this,  and you own what you build.

That is... uniqueness of IP address entries in an address registry you
operate doesn't happen by accident.

--
-JH


From jra at baylink.com  Fri Dec  2 18:44:39 2011
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 2 Dec 2011 19:44:39 -0500 (EST)
Subject: IP addresses are now assets
In-Reply-To: <EB76C778-6751-404A-A9B6-3ECA8251BF18@arin.net>
Message-ID: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "John Curran" <jcurran at arin.net>

> On Dec 2, 2011, at 2:48 AM, <Valdis.Kletnieks at vt.edu> wrote:
> > Would it be correct to summarize the ARIN position as "It's murkier than Cerner
> > makes it out to be, and some lawyers are gonna get stinking filthy rich
> > litigating this one"?
> 
> It's pretty simple: you can write a contract to transfer IP
> addresses in accordance with policy, and we are now seeing
> most parties come to us in advance either to prequalify or
> make the sale conditional on approval.

No, Valdis, the ARIN position is "if we wanted Curran to have a sense of humor,
we'd have issued him one".  

:-)

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 jtowne at slic.com  Fri Dec  2 18:47:34 2011
From: jtowne at slic.com (Jonathan Towne)
Date: Fri, 2 Dec 2011 19:47:34 -0500
Subject: Overall Netflix bandwidth usage numbers on a network?
Message-ID: <20111203004732.GH13315@hijacked.us>

Been lurking for a while and posed a question to a few folks without much
response, figured someone here might've done something like this already.

So, before I go about building wheels that already exist:

I'm interested in doing a bit of a passive survey of bandwidth usage on
my network (smallish isp, a few thousand DSL/FTTx customers) to understand
the percentage of average/overall traffic generated by Netflix streaming.

What I have available is a few gigabit transport switches providing me with
mirror ports, a juniper MX series router running 10.4 code, plenty of BSD
machines and libpcap-fu.

What I'm looking for is either a timed-average or moments-glance number
of the traffic.  For instance, on an interface moving 150mbit/sec total,
50mbit/sec of it is attributed to Netflix right now.  I'm pretty handy with
RRDtool, so that isn't out of the question, either.

I've really only spent dinnertime considering this, but have come up with
two potential approaches so far, and haven't actively investigated either
of them:

* firewall terms and counters on the MX router + snmp
* writing a quick libpcap application to filter and count in a completely
  out-of-band way on one of my monitoring hosts

Some challenges I can see:

* Nailing down the streaming source for Netflix, that is, IP ranges etc.
* Making assumptions about CDN source IPs that could be used for something
  else, and further, should I care?

Happy to hear thoughts about this, helpful or not!  I know Netflix themselves
have probably done plenty of studies like this, but pretty likely not limited
to my customer base.  Not aiming for anything creepy or crazy, just some
vague understanding of what's going on, and the ability to do some trending
for future planning.

-- Jonathan Towne


From andy-nanog at bash.sh  Fri Dec  2 18:56:34 2011
From: andy-nanog at bash.sh (Andrew Mulholland)
Date: Sat, 3 Dec 2011 00:56:34 +0000
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <20111203004732.GH13315@hijacked.us>
References: <20111203004732.GH13315@hijacked.us>
Message-ID: <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>

Surely this is what Netflow is for.


no need to re-invent the wheel.


Andrew


On Sat, Dec 3, 2011 at 12:47 AM, Jonathan Towne <jtowne at slic.com> wrote:

> Been lurking for a while and posed a question to a few folks without much
> response, figured someone here might've done something like this already.
>
> So, before I go about building wheels that already exist:
>
> I'm interested in doing a bit of a passive survey of bandwidth usage on
> my network (smallish isp, a few thousand DSL/FTTx customers) to understand
> the percentage of average/overall traffic generated by Netflix streaming.
>
> What I have available is a few gigabit transport switches providing me with
> mirror ports, a juniper MX series router running 10.4 code, plenty of BSD
> machines and libpcap-fu.
>
> What I'm looking for is either a timed-average or moments-glance number
> of the traffic.  For instance, on an interface moving 150mbit/sec total,
> 50mbit/sec of it is attributed to Netflix right now.  I'm pretty handy with
> RRDtool, so that isn't out of the question, either.
>
> I've really only spent dinnertime considering this, but have come up with
> two potential approaches so far, and haven't actively investigated either
> of them:
>
> * firewall terms and counters on the MX router + snmp
> * writing a quick libpcap application to filter and count in a completely
>  out-of-band way on one of my monitoring hosts
>
> Some challenges I can see:
>
> * Nailing down the streaming source for Netflix, that is, IP ranges etc.
> * Making assumptions about CDN source IPs that could be used for something
>  else, and further, should I care?
>
> Happy to hear thoughts about this, helpful or not!  I know Netflix
> themselves
> have probably done plenty of studies like this, but pretty likely not
> limited
> to my customer base.  Not aiming for anything creepy or crazy, just some
> vague understanding of what's going on, and the ability to do some trending
> for future planning.
>
> -- Jonathan Towne
>
>

From jtowne at slic.com  Fri Dec  2 18:58:48 2011
From: jtowne at slic.com (Jonathan Towne)
Date: Fri, 2 Dec 2011 19:58:48 -0500
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
Message-ID: <20111203005847.GI13315@hijacked.us>

Wow.. not sure how I missed that option.  Exactly why I posted before dumping
a bunch of time into a bottomless bucket!

Thanks.. :)

-- Jonathan Towne


On Sat, Dec 03, 2011 at 12:56:34AM +0000, Andrew Mulholland scribbled:
# Surely this is what Netflow is for.
# 
# 
# no need to re-invent the wheel.
# 
# 
# Andrew
# 
# 
# On Sat, Dec 3, 2011 at 12:47 AM, Jonathan Towne <jtowne at slic.com> wrote:
# 
# > Been lurking for a while and posed a question to a few folks without much
# > response, figured someone here might've done something like this already.
# >
# > So, before I go about building wheels that already exist:
# >
# > I'm interested in doing a bit of a passive survey of bandwidth usage on
# > my network (smallish isp, a few thousand DSL/FTTx customers) to understand
# > the percentage of average/overall traffic generated by Netflix streaming.
# >
# > What I have available is a few gigabit transport switches providing me with
# > mirror ports, a juniper MX series router running 10.4 code, plenty of BSD
# > machines and libpcap-fu.
# >
# > What I'm looking for is either a timed-average or moments-glance number
# > of the traffic.  For instance, on an interface moving 150mbit/sec total,
# > 50mbit/sec of it is attributed to Netflix right now.  I'm pretty handy with
# > RRDtool, so that isn't out of the question, either.
# >
# > I've really only spent dinnertime considering this, but have come up with
# > two potential approaches so far, and haven't actively investigated either
# > of them:
# >
# > * firewall terms and counters on the MX router + snmp
# > * writing a quick libpcap application to filter and count in a completely
# >  out-of-band way on one of my monitoring hosts
# >
# > Some challenges I can see:
# >
# > * Nailing down the streaming source for Netflix, that is, IP ranges etc.
# > * Making assumptions about CDN source IPs that could be used for something
# >  else, and further, should I care?
# >
# > Happy to hear thoughts about this, helpful or not!  I know Netflix
# > themselves
# > have probably done plenty of studies like this, but pretty likely not
# > limited
# > to my customer base.  Not aiming for anything creepy or crazy, just some
# > vague understanding of what's going on, and the ability to do some trending
# > for future planning.
# >
# > -- Jonathan Towne
# >
# >


From mpalmer at hezmatt.org  Fri Dec  2 19:01:26 2011
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Sat, 3 Dec 2011 12:01:26 +1100
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <201112022355.pB2NtNCh014147@mail.r-bonomi.com>
References: <20111202123312.BA389E70@resin04.mta.everyone.net>
 <201112022355.pB2NtNCh014147@mail.r-bonomi.com>
Message-ID: <20111203010126.GO3707@hezmatt.org>

On Fri, Dec 02, 2011 at 05:55:23PM -0600, Robert Bonomi wrote:
> 
>  "Scott Weeks" <surfer at mauigateway.com> wrote:
> >
> > Apologies for the rapid-shot email.  It's Friday...  :-)
> >
> > bmanning at vacation.karoshi.com wrote:
> >
> >> On Thu, Dec 01, 2011 at 04:35:27PM -0500, David Radcliffe wrote:
> >> > The reason it is not more accepted is too many people still think "If I 
> >> > cannot see you you must not be working."
> >>
> >>     actually, i've heard the real reason is corporate liability ...
> >>     that said, there is an advantage for team f2f mtgs on a periodic
> >>     basis.
> >
> > I don't follow.  Could you elaborate?  What is the liability?
> 
> I don't know for certain, but I expect "work at home' employeees fall under
> the scope of the employers "Workmans Compenstation" liability covrerage,
> with regard to injuries sustained "on the job".

"There are those who say this has already happened"

http://www.news.com.au/business/telstra-forced-to-pay-costs-compensation-after-worker-dale-hargreaves-slips-while-working-at-home/story-e6frfm1i-1226081649913

Now, I'm sure the facts of the matter haven't gotten in the way of the story
there, but I'm struggling to come up with a set of circumstances which
*don't* involve an application of palm to face.

- Matt

-- 
You know you have a distributed system when the crash of a computer you?ve
never heard of stops you from getting any work done.
		-- Leslie Lamport "Security Engineering: A Guide to Building
		   Dependable Distributed Systems"



From jcurran at arin.net  Fri Dec  2 21:33:55 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 3 Dec 2011 03:33:55 +0000
Subject: IP addresses are now assets
In-Reply-To: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com>
References: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com>
Message-ID: <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net>

On Dec 2, 2011, at 7:44 PM, Jay Ashworth wrote:
> 
> No, Valdis, the ARIN position is "if we wanted Curran to have a sense of humor,
> we'd have issued him one".  


Changes in this area may be proposed via the ARIN Consultation and 
Suggestion Process - <https://www.arin.net/participate/acsp/index.html>  

;-)
/John

John Curran
President and CEO
ARIN





From bmanning at vacation.karoshi.com  Fri Dec  2 22:01:29 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sat, 3 Dec 2011 04:01:29 +0000
Subject: IP addresses are now assets
In-Reply-To: <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net>
References: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com>
 <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net>
Message-ID: <20111203040129.GA16517@vacation.karoshi.com.>

On Sat, Dec 03, 2011 at 03:33:55AM +0000, John Curran wrote:
> On Dec 2, 2011, at 7:44 PM, Jay Ashworth wrote:
> > 
> > No, Valdis, the ARIN position is "if we wanted Curran to have a sense of humor,
> > we'd have issued him one".  
> 
> 
> Changes in this area may be proposed via the ARIN Consultation and 
> Suggestion Process - <https://www.arin.net/participate/acsp/index.html>  
> 
> ;-)
> /John
> 
> John Curran
> President and CEO
> ARIN
> 

	Mischief Managed.

The text of the submitted suggestion is included below.
 
Sincerely,

Communications and Member Services
American Registry for Internet Numbers (ARIN)
--------------------------------------------------------------------------------
Suggestion received and needing confirmation:

That ARIN or a party it designates assign one or more sense(s) of humour to the CEO.

--------------------------------------------------------------------------------
The ARIN Consultation and Suggestion Process (ACSP) is available at:
http://www.arin.net/participate/acsp/index.html     

/bill


From jra at baylink.com  Fri Dec  2 22:05:09 2011
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 02 Dec 2011 23:05:09 -0500
Subject: IP addresses are now assets
In-Reply-To: <20111203040129.GA16517@vacation.karoshi.com.>
References: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com>
 <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net>
 <20111203040129.GA16517@vacation.karoshi.com.>
Message-ID: <21f7b846-4603-4b4b-9219-c457b47ccb66@email.android.com>

Ah... *this* is the Whacky Weekend thread.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

bmanning at vacation.karoshi.com wrote:

On Sat, Dec 03, 2011 at 03:33:55AM +0000, John Curran wrote:
> On Dec 2, 2011, at 7:44 PM, Jay Ashworth wrote:
> > 
> > No, Valdis, the ARIN position is "if we wanted Curran to have a sense of humor,
> > we'd have issued him one". 
> 
> 
> Changes in this area may be proposed via the ARIN Consultation and 
> Suggestion Process - <https://www.arin.net/participate/acsp/index.html>; 
> 
> ;-)
> /John
> 
> John Curran
> President and CEO
> ARIN
> 

	Mischief Managed.

The text of the submitted suggestion is included below.

Sincerely,

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

Suggestion received and needing confirmation:

That ARIN or a party it designates assign one or more sense(s) of humour to the CEO.

_____________________________________________

The ARIN Consultation and Suggestion Process (ACSP) is available at:
http://www.arin.net/participate/acsp/index.html 

/bill


From jay at west.net  Sat Dec  3 00:06:11 2011
From: jay at west.net (Jay Hennigan)
Date: Fri, 02 Dec 2011 22:06:11 -0800
Subject: RFOs, was:ATT GigE issue...
In-Reply-To: <CAAAas8FqmLk21j4KpYXgRRqST-AG+zG75vX_MmzTMZ6QdPFrvQ@mail.gmail.com>
References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01>
 <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com>
 <CACk08n9KYyOLbOG==X+8n4pByy46kMVyRkmRw4-752__cr=xpQ@mail.gmail.com>
 <4ED650E4.3050705@ispn.net> <BB2651EB-60FC-49EC-9089-01720CEAF3A3@gmail.com>
 <4ED66BD3.3050603@ttec.com>
 <CAAAas8FqmLk21j4KpYXgRRqST-AG+zG75vX_MmzTMZ6QdPFrvQ@mail.gmail.com>
Message-ID: <4ED9BC53.9050900@west.net>

On 11/30/11 11:35 AM, Mike Jones wrote:
> On 30 November 2011 17:45, Joe Maimon <jmaimon at ttec.com> wrote:

> "The outage was caused by an engineer turning off the wrong router, it
> has been turned back on and service restored"
> "The outage appears to have been caused by a bug in the routers
> firmware, we are working with the vendor on a fix"
> "There was an outage, now service is back up again"

When the RFO gets filtered through the marketing department, it gets
interesting, and totally useless.  This is what we got as an official
RFO for an outsourced hosted VoIP service (carrier shall remain
nameless) that was for all practical purposes down hard for two DAYS due
to a botched planned software upgrade, verbatim and in its entirety:

"Coincident with this upgrade, we experienced an Operating System-level
failure on the underlying application server platform which had the
effect of defeating the redundancy paradigm designed into our service
architecture."

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From jeff.tantsura at ericsson.com  Sat Dec  3 02:21:33 2011
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Sat, 3 Dec 2011 03:21:33 -0500
Subject: draft-ietf-idr-as0-00  (bgp update destroying transit on
 redback routers ?)
In-Reply-To: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
 <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C2EDF8A@EUSAACMS0701.eamcs.ericsson.se>

Hi Daniel,

I do understand the use of it however have my doubts about usability as such, I'd really like to see anyone using it for the reason below.
All of updates with ASN 0 I have seen in the past few years were there due to software bugs, not explicit configuration - same as this one.

Warren/ idr -  I do support addition of AGGREGATOR in the draft

Regards,
Jeff

P.S. Jeffrey/John -  this draft makes use of "no-aggregator-id"  de facto illigal, are you (your customers) OK with it? 
Thanks!

-----Original Message-----
From: Daniel Ginsburg [mailto:dbg at net-geek.org] 
Sent: Friday, December 02, 2011 5:13 AM
To: Jeff Tantsura; Warren Kumari
Cc: nanog at nanog.org; idr at ietf.org
Subject: draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)

Hi,

This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attribute.

The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous.

If the network employs the "no-aggregator-id" knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about.

In other words, the "no-aggregator-id" knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute.

On 02.12.2011, at 1:56, Jeff Tantsura wrote:

> Hi,
> 
> Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols.
> There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds.
> 
> To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yakov about it, without any results though. 
> So for those who have it configured - please rethink whether you really need it.
> 
> As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code.
> Patch will be made available.
> 
> Please contact me for any further clarifications.
> 
> Regards,
> Jeff
> 
> P.S. Warren has recently  included AGGREGATOR in the draft, please see
> 
> 2. Behavior
>   This document specifies that a BGP speaker MUST NOT originate or
>   propagate a route with an AS number of zero.  If a BGP speaker
>   receives a route which has an AS number of zero in the AS_PATH (or
>   AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
>   This same behavior applies to routes containing zero as the
>   Aggregator or AS4 Aggregator.
> 



From maxsec at gmail.com  Sat Dec  3 02:36:11 2011
From: maxsec at gmail.com (Martin Hepworth)
Date: Sat, 3 Dec 2011 08:36:11 +0000
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <20111203005847.GI13315@hijacked.us>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
Message-ID: <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>

Also checkout Adrian Cockcroft presentations on their architecture which
describes how they use aws and CDns etc

Martin

On Saturday, 3 December 2011, Jonathan Towne <jtowne at slic.com> wrote:
> Wow.. not sure how I missed that option.  Exactly why I posted before
dumping
> a bunch of time into a bottomless bucket!
>
> Thanks.. :)
>
> -- Jonathan Towne
>
>
> On Sat, Dec 03, 2011 at 12:56:34AM +0000, Andrew Mulholland scribbled:
> # Surely this is what Netflow is for.
> #
> #
> # no need to re-invent the wheel.
> #
> #
> # Andrew
> #
> #
> # On Sat, Dec 3, 2011 at 12:47 AM, Jonathan Towne <jtowne at slic.com> wrote:
> #
> # > Been lurking for a while and posed a question to a few folks without
much
> # > response, figured someone here might've done something like this
already.
> # >
> # > So, before I go about building wheels that already exist:
> # >
> # > I'm interested in doing a bit of a passive survey of bandwidth usage
on
> # > my network (smallish isp, a few thousand DSL/FTTx customers) to
understand
> # > the percentage of average/overall traffic generated by Netflix
streaming.
> # >
> # > What I have available is a few gigabit transport switches providing
me with
> # > mirror ports, a juniper MX series router running 10.4 code, plenty of
BSD
> # > machines and libpcap-fu.
> # >
> # > What I'm looking for is either a timed-average or moments-glance
number
> # > of the traffic.  For instance, on an interface moving 150mbit/sec
total,
> # > 50mbit/sec of it is attributed to Netflix right now.  I'm pretty
handy with
> # > RRDtool, so that isn't out of the question, either.
> # >
> # > I've really only spent dinnertime considering this, but have come up
with
> # > two potential approaches so far, and haven't actively investigated
either
> # > of them:
> # >
> # > * firewall terms and counters on the MX router + snmp
> # > * writing a quick libpcap application to filter and count in a
completely
> # >  out-of-band way on one of my monitoring hosts
> # >
> # > Some challenges I can see:
> # >
> # > * Nailing down the streaming source for Netflix, that is, IP ranges
etc.
> # > * Making assumptions about CDN source IPs that could be used for
something
> # >  else, and further, should I care?
> # >
> # > Happy to hear thoughts about this, helpful or not!  I know Netflix
> # > themselves
> # > have probably done plenty of studies like this, but pretty likely not
> # > limited
> # > to my customer base.  Not aiming for anything creepy or crazy, just
some
> # > vague understanding of what's going on, and the ability to do some
trending
> # > for future planning.
> # >
> # > -- Jonathan Towne
> # >
> # >
>
>

-- 
-- 
Martin Hepworth
Oxford, UK

From jra at baylink.com  Sat Dec  3 10:40:54 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 3 Dec 2011 11:40:54 -0500 (EST)
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <4ED8C3C5.2010404@resolution.de>
Message-ID: <4415664.1377.1322930454781.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Thorsten Dahm" <t.dahm at resolution.de>

> The downside of this is that you are not around in the office in case
> someone wants to talk to you. I often end up with guys from our
> operations team or other teams stopping at my desk and ask questions.
> Or guys who want to have a quick chat about a problem and want to ask for
> an advice or idea. Or people who want to learn Perl and have a
> question that you can answer in 30 seconds.
> 
> Yes, I know, they can call you, or send an Email, but nothing beats
> the good old "Let's go for a coffee, I'd like to ask you a question".

"Private IRC server".

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 brian.peter.dickson at gmail.com  Sat Dec  3 11:22:56 2011
From: brian.peter.dickson at gmail.com (Brian Dickson)
Date: Sat, 3 Dec 2011 12:22:56 -0500
Subject: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on
 redback routers ?)
In-Reply-To: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
 <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
Message-ID: <CAH1iCioe+aekc8oWUeyoec+7vuHNKj=UY9i7AgjjRyp44ZRT7g@mail.gmail.com>

Can anyone familiar with this knob and its usage, answer a question:

Would anything break, in terms of use of that knob, if instead of
"zeroing" the AGGREGATOR, the local AS (as seen from the outside
world, in the case of confederations) were used?

Would the functionality of the knob, in reducing updates, be preserved?

Would routes be considered malformed or would it trigger any other bad behavior?

Perhaps this is a way of resolving the conflict between this knob and
the AS0 draft?

Brian

On Fri, Dec 2, 2011 at 8:12 AM, Daniel Ginsburg <dbg at net-geek.org> wrote:
> Hi,
>
> This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attribute.
>
> The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous.
>
> If the network employs the "no-aggregator-id" knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about.
>
> In other words, the "no-aggregator-id" knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute.
>
> On 02.12.2011, at 1:56, Jeff Tantsura wrote:
>
>> Hi,
>>
>> Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols.
>> There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds.
>>
>> To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yakov about it, without any results though.
>> So for those who have it configured - please rethink whether you really need it.
>>
>> As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code.
>> Patch will be made available.
>>
>> Please contact me for any further clarifications.
>>
>> Regards,
>> Jeff
>>
>> P.S. Warren has recently ?included AGGREGATOR in the draft, please see
>>
>> 2. Behavior
>> ? This document specifies that a BGP speaker MUST NOT originate or
>> ? propagate a route with an AS number of zero. ?If a BGP speaker
>> ? receives a route which has an AS number of zero in the AS_PATH (or
>> ? AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
>> ? This same behavior applies to routes containing zero as the
>> ? Aggregator or AS4 Aggregator.
>>
>
> _______________________________________________
> Idr mailing list
> Idr at ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nickellman at gmail.com  Sat Dec  3 12:28:26 2011
From: nickellman at gmail.com (brian nikell)
Date: Sat, 3 Dec 2011 11:28:26 -0700
Subject: book to buy
Message-ID: <CAMKfM=iPGiM=YdmV5P-RZ179yTQnr4CoucF=f=5sbgQPqWgWng@mail.gmail.com>

The filter bubble.   Eli pariser

-- 
-B

From joly at punkcast.com  Sat Dec  3 13:23:13 2011
From: joly at punkcast.com (Joly MacFie)
Date: Sat, 3 Dec 2011 14:23:13 -0500
Subject: book to buy
In-Reply-To: <CAMKfM=iPGiM=YdmV5P-RZ179yTQnr4CoucF=f=5sbgQPqWgWng@mail.gmail.com>
References: <CAMKfM=iPGiM=YdmV5P-RZ179yTQnr4CoucF=f=5sbgQPqWgWng@mail.gmail.com>
Message-ID: <CAM9VJk2fiER+pC0kx2r0d0Gbtv5sNi09YBWeOy5EP1DXj3czOw@mail.gmail.com>

(to save googling and, perhaps, book reading)
http://www.thefilterbubble.com/



On Sat, Dec 3, 2011 at 1:28 PM, brian nikell <nickellman at gmail.com> wrote:

> The filter bubble.   Eli pariser
>
> --
> -B
>



-- 
---------------------------------------------------------------
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 gary.buhrmaster at gmail.com  Sat Dec  3 14:26:55 2011
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Sat, 3 Dec 2011 12:26:55 -0800
Subject: IP addresses are now assets
In-Reply-To: <4ed99f4d.8569e70a.7cd1.4ddcSMTPIN_ADDED@mx.google.com>
References: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com>
 <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net>
 <4ed99f4d.8569e70a.7cd1.4ddcSMTPIN_ADDED@mx.google.com>
Message-ID: <CAMfXtQytAdup5qZYAm_SWaQ50WxDpb64qBuE8Yx2RjPdnE3EZA@mail.gmail.com>

On Fri, Dec 2, 2011 at 20:01,  <bmanning at vacation.karoshi.com> wrote:
.....
> --------------------------------------------------------------------------------
> Suggestion received and needing confirmation:
>
> That ARIN or a party it designates assign one or more sense(s) of humour to the CEO.
>

I believe this suggestion suffers from being too non-specific,
and could lead to unintended consequences.  ARIN could,
for example, assign John a slapstick comedy sense of humor
and all the chairs at the next meeting would have a whoopee
cushion.  And do you really want John taking on the role
of a Don Rickles as an insult comedian?

And, of course 87% percentage of the population believes
that they already have an above average sense of humor
(and 62% of the population believes any statement with
a statistic in it).

I would recommend that this suggestion be revised
with community input into what type of humor can
achieve a community consensus.

Gary


From surfer at mauigateway.com  Sat Dec  3 15:14:49 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Sat, 3 Dec 2011 13:14:49 -0800
Subject: Looking for a Tier 1 ISP Mentor for career advice.
Message-ID: <20111203131449.2DA7AE1@resin03.mta.everyone.net>


------- bonomi at mail.r-bonomi.com wrote: -------
 "Scott Weeks" <surfer at mauigateway.com> wrote:
> bmanning at vacation.karoshi.com wrote:
>>
>>     actually, i've heard the real reason is corporate liability ...
>>     that said, there is an advantage for team f2f mtgs on a periodic
>>     basis.
>
> I don't follow.  Could you elaborate?  What is the liability?

I don't know for certain, but I expect "work at home' employeees fall under
the scope of the employers "Workmans Compenstation" liability covrerage,
with regard to injuries sustained "on the job".

Now, consider what happens if the employee sustains an 'on the job' injury,
due to something in the 'workplace' (done by the homeowner on his own time)
that is _NOT_ "OHSA-compliant".
-------------------------------------------------



Well, if that's a big issue for companies and managers it seems like 
something easy to write up in the contract for work.  Even other things 
they worry about could be written to protect them and I think we'd still 
sign up if we didn't have to up root our lives to do work we enjoy.  That 
is unless the gov't forces companies to treat the home as a workplace when 
telecommuting.  I still have the sneaking suspicion that many managers 
don't feel they have enough control when one telecommutes as well as the 
other things discussed in this thread.

scott



  'A large quantity of organic waste/byproducts forcefully impacted the
   high-speed rotary impeller."

I'm going to steal that one...  :-)









From jra at baylink.com  Sat Dec  3 15:25:58 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 3 Dec 2011 16:25:58 -0500 (EST)
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <20111203131449.2DA7AE1@resin03.mta.everyone.net>
Message-ID: <23213419.1407.1322947558601.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Scott Weeks" <surfer at mauigateway.com>

> That is unless the gov't forces companies to treat the home as a workplace
> when telecommuting. I still have the sneaking suspicion that many managers
> don't feel they have enough control when one telecommutes as well as
> the other things discussed in this thread.

They tried, a couple years ago.  The fecal matter hit the rotary impeller.

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 mpetach at netflight.com  Sat Dec  3 16:24:45 2011
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 3 Dec 2011 14:24:45 -0800
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: <20111202123053.BA389EAF@resin04.mta.everyone.net>
References: <20111202123053.BA389EAF@resin04.mta.everyone.net>
Message-ID: <CAEmG1=rTmQmZiHn0pc0NeRDb9dB+FNXF7RCqJEQRYB2+xyshbQ@mail.gmail.com>

On Fri, Dec 2, 2011 at 12:30 PM, Scott Weeks <surfer at mauigateway.com> wrote:
> --- bicknell at ufp.org wrote:
> From: Leo Bicknell <bicknell at ufp.org>
>
> If you have telecommuters _everyone_ in the office should be forced
> to work from home at least 2 weeks a year, including the manager.
> It's only from that experience you learn to deal with your telecommuting
> co-workers in a way that raises everyone's productivity.
> ---------------------------------------------
>
> I have been bemoaning the lack of telecommuting positions available
> since I last did that permanently from 1998-2002. ?I could never
> figure out how to get the managers since then to understand how to
> manage remote workers effectively, as that's what I think the problem
> is. ?The manager's ability to value an employee in this century's
> methodology, rather than the old way: "wow, he was in the office 10
> hours today. ?He must've gotten a lot of work done". ?When, actually,
> the person played around for 6 of those hours while looking busy.
>
> Having the manager work from home, even temporarily, would solve this.
> Now if I can just get them to actually do that... ?:-)

Easy.  Have the managers manage people halfway around the planet.

Only a tiny minority of my team works in the same timezone I do;
if I made my team members fit to my office-day work schedule,
they'd quickly mutiny.  Working from home lets me interact with
them at more reasonable hours for them, without causing too much
undue impact to my life schedule.

It also  helps when you're managing people 12,000 miles away;
there's almost zero chance of "face to face" time in the office,
so you quickly learn to use IRC, IM, and remote access
voice conference bridges to do realtime or near-realtime interaction
when needed, and email for longer-term threads.

> I really hope manager-types are listening. ?You limit yourselves to
> those available in your immediate area and the skills they have.
> Opening yourselves to telecommuting allows you to hire folks with
> skills that may match your needs more effectively.

Some of us are; unfortunately, we're not the ones with open headcount
for hiring, because nobody on our teams ever wants to leave.  ;-P

> Personally, I am working at smaller networks than I would like to,
> but I get to live on Kauai and surf places like this every day:
>
> www.imagemania.net/data/media/22/Polihale%20Beach,%20Kauai,%20Hawaii.jpg
>
> when I'd rather get back into BGP and operating large networks because I
> enjoy it. ?However, I will not give up life's fun things just to do that
> for a living. ?I know I'm not the only one out there who thinks this way.

Totally agree; I've been courted by companies that are eager to hire
me, but once the subject of telecommuting is broached, they suddenly
backpedal; to me, that's a clear sign there's an impedance mismatch,
at which point I usually politely end the conversation.

> scott

Matt


From bensons at queuefull.net  Sat Dec  3 16:28:07 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Sat, 3 Dec 2011 16:28:07 -0600
Subject: IP addresses are now assets
In-Reply-To: <CAMfXtQytAdup5qZYAm_SWaQ50WxDpb64qBuE8Yx2RjPdnE3EZA@mail.gmail.com>
References: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com>
 <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net>
 <4ed99f4d.8569e70a.7cd1.4ddcSMTPIN_ADDED@mx.google.com>
 <CAMfXtQytAdup5qZYAm_SWaQ50WxDpb64qBuE8Yx2RjPdnE3EZA@mail.gmail.com>
Message-ID: <6F188E67-5F10-4312-942C-9D7343C79016@queuefull.net>

It's hard to sustain that kind of commitment... so we need to form a Humor Advisory Committee. Their job would be to determine which behaviors the community finds most humorous. When the community doesn't produce enough material, the comedy HAC would write jokes on our behalf (for adoption by John following legal assessment, board approval, etc).

Cheers,
-Benson


On Dec 3, 2011, at 2:26 PM, Gary Buhrmaster wrote:

> On Fri, Dec 2, 2011 at 20:01,  <bmanning at vacation.karoshi.com> wrote:
> .....
>> --------------------------------------------------------------------------------
>> Suggestion received and needing confirmation:
>> 
>> That ARIN or a party it designates assign one or more sense(s) of humour to the CEO.
>> 
> 
> I believe this suggestion suffers from being too non-specific,
> and could lead to unintended consequences.  ARIN could,
> for example, assign John a slapstick comedy sense of humor
> and all the chairs at the next meeting would have a whoopee
> cushion.  And do you really want John taking on the role
> of a Don Rickles as an insult comedian?
> 
> And, of course 87% percentage of the population believes
> that they already have an above average sense of humor
> (and 62% of the population believes any statement with
> a statistic in it).
> 
> I would recommend that this suggestion be revised
> with community input into what type of humor can
> achieve a community consensus.
> 
> Gary
> 



From Valdis.Kletnieks at vt.edu  Sat Dec  3 17:59:00 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 03 Dec 2011 18:59:00 -0500
Subject: Looking for a Tier 1 ISP Mentor for career advice.
In-Reply-To: Your message of "Sat, 03 Dec 2011 11:40:54 EST."
 <4415664.1377.1322930454781.JavaMail.root@benjamin.baylink.com>
References: <4415664.1377.1322930454781.JavaMail.root@benjamin.baylink.com>
Message-ID: <41372.1322956740@turing-police.cc.vt.edu>

On Sat, 03 Dec 2011 11:40:54 EST, Jay Ashworth said:

> "Private IRC server".

Amen to that.

I've decided that our private Jabber server has resulted in an order of
magnitude improvement in dealing with "quick question for ya" requests, as you
can cut/paste to/from as needed (it's still kinda hard to cut-n-paste what the
co-worker said over coffee or over the phone ;) with less overhead than e-mail
(especially for things that take 3-4 RTTs to resolve).

-------------- 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/20111203/14f132f9/attachment-0001.bin>

From thegameiam at yahoo.com  Sat Dec  3 20:18:48 2011
From: thegameiam at yahoo.com (David Barak)
Date: Sat, 3 Dec 2011 18:18:48 -0800 (PST)
Subject: IP addresses are now assets
Message-ID: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com>

Should the HAC be expected to manage the transition to HumorV6?

David

From bonomi at mail.r-bonomi.com  Sun Dec  4 00:21:41 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sun, 4 Dec 2011 00:21:41 -0600 (CST)
Subject: IP addresses are now assets
In-Reply-To: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com>
Message-ID: <201112040621.pB46Lf8v025406@mail.r-bonomi.com>


From: David Barak <thegameiam at yahoo.com>
>
> Should the HAC be expected to manage the transition to HumorV6?
>

BEFORE that is introduced, one needs a mailing-list designated for discussion
of the potential problems an dangers associated therewith, similar to the
ACM's discussion list on computer technoogy.  May I propose that it be called
the "Humor-esque Digest".  An approprite 'publisher' would be the I.S.P.F.[1],
with the editor required to use Alfred E. Neuman as his professional psuedonym.

"if you're going to do a thing, do it RIGHT!!"

"Anything worth doing, is worth over-doing."


Footnotes:
  [1]  International 'Save the Pun' Foundation -- yes,  they -really- exist.



From david at davidswafford.com  Sun Dec  4 04:59:06 2011
From: david at davidswafford.com (David Swafford)
Date: Sun, 4 Dec 2011 05:59:06 -0500
Subject: Broadband providers in downtown Chicago
In-Reply-To: <CAL-SDLHzrjHs3e+rwshNY0TS63CXCE=90D8d9wJz4JEca=1Aog@mail.gmail.com>
References: <CAL-SDLHzrjHs3e+rwshNY0TS63CXCE=90D8d9wJz4JEca=1Aog@mail.gmail.com>
Message-ID: <CAA8=vb6tGGxcPCTh2Yur8sZqH-mhQ91CCL1uJiWZYUaiXpaQtw@mail.gmail.com>

When you say "broadband", are you trying to source a residential
provider in downtown?  I could see that being a challenge....  Take a
look around for a metro-eth based Internet pipes, I'm sure they are
plenty in that area.  TWTC might be one to check out if you're against
Cogent [Level3].

David.

On Thu, Dec 1, 2011 at 12:30 PM, Ishmael Rufus <sakamura at gmail.com> wrote:
> Our company is in a building at 200 w. Monroe and we have difficulty
> finding an internet service provider that could at least provide
> 1Mbps+ Upload bandwidth that is not Cogent Communications.
>
> Is it really this difficult finding a decent internet service provider
> in downtown Chicago?
>


From gary.buhrmaster at gmail.com  Sun Dec  4 09:15:01 2011
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Sun, 4 Dec 2011 07:15:01 -0800
Subject: IP addresses are now assets
In-Reply-To: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com>
References: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com>
Message-ID: <CAMfXtQx2q1MNKT29ggTuaD7QBoKbkmp05F7TJJnW37WusSjo=Q@mail.gmail.com>

On Sat, Dec 3, 2011 at 18:18, David Barak <thegameiam at yahoo.com> wrote:

> Should the HAC be expected to manage the transition to HumorV6?
>

I am not that familiar with Humorv6.  Has Hv6 had sufficient
operational input, or is it based on a philosophically pure
redesign of humor making it theoretically funny, but
in practice most of the humor falls flat.  Does it require a
redesign of the existing infrastructure (i.e. comedy clubs)
in order to get the joke?  And, of course, is the British
implementation of HumourV6 compatible the American
implementation of HumorV6?

Gary

From jra at baylink.com  Sun Dec  4 11:58:08 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 4 Dec 2011 12:58:08 -0500 (EST)
Subject: IP addresses are now assets
In-Reply-To: <201112040621.pB46Lf8v025406@mail.r-bonomi.com>
Message-ID: <20692863.1531.1323021488787.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Robert Bonomi" <bonomi at mail.r-bonomi.com>

> "if you're going to do a thing, do it RIGHT!!"
> 
> "Anything worth doing, is worth over-doing."

I love a good self-referential posting; don't you?

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  Sun Dec  4 12:12:32 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 4 Dec 2011 13:12:32 -0500 (EST)
Subject: On Working Remotely
Message-ID: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>

Some more thoughts on telecommuting, from the guy who built Stack Overflow.

http://www.codinghorror.com/blog/2010/05/on-working-remotely.html

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 keegan.holley at sungard.com  Sun Dec  4 12:46:51 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 4 Dec 2011 13:46:51 -0500
Subject: On Working Remotely
In-Reply-To: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
Message-ID: <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>

Maybe I have a different personality, but I find it much easier to work
from home (provided home is empty).  I think "networking" from home, which
I do periodically during the week is different from coding from home which
I do on the weekends.  It does take some getting used to.  I find I'm much
more productive from home. (again as long as home is empty)  I spend less
time talking about sports (professional, college and little league) TV, the
opposite sex, hunting... etc. etc.  I also tend to make healthier choices
since the coffee and cigarettes aren't free and no one invites me to order
pizza for lunch when I'm at home.  To each his own though.

2011/12/4 Jay Ashworth <jra at baylink.com>

> Some more thoughts on telecommuting, from the guy who built Stack Overflow.
>
> http://www.codinghorror.com/blog/2010/05/on-working-remotely.html
>
> 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 leigh.porter at ukbroadband.com  Sun Dec  4 12:54:53 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Sun, 4 Dec 2011 18:54:53 +0000
Subject: On Working Remotely
In-Reply-To: <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE0033147864450388@EALPO1.ukbroadband.com>

This pretty much says it all, I think:

http://www.youtube.com/watch?v=co_DNpTMKXk

--
Leigh


> -----Original Message-----
> From: Keegan Holley [mailto:keegan.holley at sungard.com]
> Sent: 04 December 2011 18:50
> To: Jay Ashworth
> Cc: NANOG
> Subject: Re: On Working Remotely
> 
> Maybe I have a different personality, but I find it much easier to work
> from home (provided home is empty).  I think "networking" from home,
> which
> I do periodically during the week is different from coding from home
> which
> I do on the weekends.  It does take some getting used to.  I find I'm
> much
> more productive from home. (again as long as home is empty)  I spend
> less
> time talking about sports (professional, college and little league) TV,
> the
> opposite sex, hunting... etc. etc.  I also tend to make healthier
> choices
> since the coffee and cigarettes aren't free and no one invites me to
> order
> pizza for lunch when I'm at home.  To each his own though.
> 
> 2011/12/4 Jay Ashworth <jra at baylink.com>
> 
> > Some more thoughts on telecommuting, from the guy who built Stack
> Overflow.
> >
> > http://www.codinghorror.com/blog/2010/05/on-working-remotely.html
> >
> > 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
> >
> >
> >
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud
> service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From excelsio at gmx.com  Sun Dec  4 13:21:02 2011
From: excelsio at gmx.com (excelsio at gmx.com)
Date: Sun, 04 Dec 2011 20:21:02 +0100
Subject: HP IPv6 RA Guard
Message-ID: <20111204192104.37340@gmx.com>

Hi,

 sorry to disappoint you, but there?s a reason why HP bought H3C/3Com. And of course, those switches have some advanced features, as well:

 - IPV6 DHCP snooping
 - IPV6 ND detection
 - IPV6 ND snooping
 - SAVI (Source Address Validation), http://tools.ietf.org/wg/savi/

 Christian

 >I wonder if this is evidence that they plan to continue to develop the >Procurve line and eventually abandon the 3Com line. Uncertainty of >which line would win out has kept me (and others I'm sure) from >wanting to invest in anything HP.

From morrowc.lists at gmail.com  Sun Dec  4 16:53:36 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 4 Dec 2011 17:53:36 -0500
Subject: HP IPv6 RA Guard
In-Reply-To: <20111204192104.37340@gmx.com>
References: <20111204192104.37340@gmx.com>
Message-ID: <CAL9jLaaxBO3jqHWu3GLYn6_BHO-MV5F-N_N6Gn76_hVP+RkC8g@mail.gmail.com>

On Sun, Dec 4, 2011 at 2:21 PM,  <excelsio at gmx.com> wrote:
> Hi,
>
> ?sorry to disappoint you, but there?s a reason why HP bought H3C/3Com. And of course, those switches have some advanced features, as well:
>

does the set of 'advanced features' include: "A cli that is
scriptable" ? cause the HPOS interface is fraught with crappy
scriptable bits :(
(yes there are rancid hp-login-like things, yes they all suck rocks)

-chris


From cdel at firsthand.net  Mon Dec  5 02:27:48 2011
From: cdel at firsthand.net (cdel.firsthand.net)
Date: Mon, 5 Dec 2011 08:27:48 +0000
Subject: IP addresses are now assets
In-Reply-To: <CAMfXtQx2q1MNKT29ggTuaD7QBoKbkmp05F7TJJnW37WusSjo=Q@mail.gmail.com>
References: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com>
 <CAMfXtQx2q1MNKT29ggTuaD7QBoKbkmp05F7TJJnW37WusSjo=Q@mail.gmail.com>
Message-ID: <30AF119C-F83E-469B-8E49-73DF7330D773@firsthand.net>

The British have been using the correct six character word length for humour ad memoriam. 


Christian de Larrinaga


On 4 Dec 2011, at 15:15, Gary Buhrmaster <gary.buhrmaster at gmail.com> wrote:

> On Sat, Dec 3, 2011 at 18:18, David Barak <thegameiam at yahoo.com> wrote:
> 
>> Should the HAC be expected to manage the transition to HumorV6?
>> 
> 
> I am not that familiar with Humorv6.  Has Hv6 had sufficient
> operational input, or is it based on a philosophically pure
> redesign of humor making it theoretically funny, but
> in practice most of the humor falls flat.  Does it require a
> redesign of the existing infrastructure (i.e. comedy clubs)
> in order to get the joke?  And, of course, is the British
> implementation of HumourV6 compatible the American
> implementation of HumorV6?
> 
> Gary


From owen at delong.com  Mon Dec  5 04:17:08 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 5 Dec 2011 02:17:08 -0800
Subject: IP addresses are now assets
In-Reply-To: <30AF119C-F83E-469B-8E49-73DF7330D773@firsthand.net>
References: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com>
 <CAMfXtQx2q1MNKT29ggTuaD7QBoKbkmp05F7TJJnW37WusSjo=Q@mail.gmail.com>
 <30AF119C-F83E-469B-8E49-73DF7330D773@firsthand.net>
Message-ID: <9895F3A7-847D-44BA-A2E2-43418BE3E677@delong.com>

Extra and unnecessary characters do not a correct word make.

Owen

On Dec 5, 2011, at 12:27 AM, cdel.firsthand.net wrote:

> The British have been using the correct six character word length for humour ad memoriam. 
> 
> 
> Christian de Larrinaga
> 
> 
> On 4 Dec 2011, at 15:15, Gary Buhrmaster <gary.buhrmaster at gmail.com> wrote:
> 
>> On Sat, Dec 3, 2011 at 18:18, David Barak <thegameiam at yahoo.com> wrote:
>> 
>>> Should the HAC be expected to manage the transition to HumorV6?
>>> 
>> 
>> I am not that familiar with Humorv6.  Has Hv6 had sufficient
>> operational input, or is it based on a philosophically pure
>> redesign of humor making it theoretically funny, but
>> in practice most of the humor falls flat.  Does it require a
>> redesign of the existing infrastructure (i.e. comedy clubs)
>> in order to get the joke?  And, of course, is the British
>> implementation of HumourV6 compatible the American
>> implementation of HumorV6?
>> 
>> Gary



From david at davidradcliffe.org  Mon Dec  5 09:09:08 2011
From: david at davidradcliffe.org (David Radcliffe)
Date: Mon, 5 Dec 2011 10:09:08 -0500
Subject: On Working Remotely
In-Reply-To: <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>
Message-ID: <201112051009.09009.david@davidradcliffe.org>

Same here.  I like isolation just fine and work much more productively and 
usually for a longer time at home.  I don't have kids and my wife has learned 
when she is home if I say I will be working, don't bother me.

It actually works quite well.  I like socializing but not when my mind is on 
work.  I can code very effectively for hours without breaking because I get in 
the zone easily at home.

I do have to say to anyone planning to work from home, make sure you have a 
proper work space.  I have a computer room.  It contains a dozen systems, 
electronics gear and parts (I used to have time for that hobby), and 
comfortable and ergonomic work spaces.  There is no TV.  No reason for one 
because this is the work room.  The mind set should be "I am now in the work 
room, so I am at work."  Really works for me.

On Sunday, December 04, 2011 01:46:51 PM Keegan Holley wrote:
> Maybe I have a different personality, but I find it much easier to work
> from home (provided home is empty).  I think "networking" from home, which
> I do periodically during the week is different from coding from home which
> I do on the weekends.  It does take some getting used to.  I find I'm much
> more productive from home. (again as long as home is empty)  I spend less
> time talking about sports (professional, college and little league) TV, the
> opposite sex, hunting... etc. etc.  I also tend to make healthier choices
> since the coffee and cigarettes aren't free and no one invites me to order
> pizza for lunch when I'm at home.  To each his own though.
> 
> 2011/12/4 Jay Ashworth <jra at baylink.com>
> 
> > Some more thoughts on telecommuting, from the guy who built Stack
> > Overflow.
> > 
> > http://www.codinghorror.com/blog/2010/05/on-working-remotely.html
> > 
> > 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

-- 
David Radcliffe
Network Engineer/Linux Specialist
david at davidradcliffe.org
www.davidradcliffe.org

Nothing ever gets solved better with panic.
If you do not know the answer, it is probably "42."


From paul at blacknight.com  Mon Dec  5 09:20:57 2011
From: paul at blacknight.com (Paul Kelly :: Blacknight)
Date: Mon, 5 Dec 2011 15:20:57 +0000
Subject: yahoo mail admin(s)
Message-ID: <08EEEAD796731546A6662E346C71CA3825036A6B@bkexchmbx01.blacknight.local>

Hi There,

Could a yahoo.com mail admin contact me offlist please? We get calls from customers saying that e-mails from their yahoo.com e-mail address to us bounce back due to a DNS lookup issue.

The issue seems intermittent but it's at a level that is sufficient enough to  raise some eyebrows by the head of our customer service team.

Cheers,

Paul

Paul Kelly
Technical Director
Microsoft Gold Certified Partner
Blacknight Internet Solutions ltd
Hosting, Colocation, Dedicated servers
IP Transit Services
Tel: +353(0)599183072
Lo-call: 1850 929 929
DDI: +353 (0) 59 9183091

e-mail: paul at blacknight.com
web: http://www.blacknight.com

Blacknight Internet Solutions Ltd,
Unit 12A,Barrowside Business Park,
Sleaty Road,
Graiguecullen,
Carlow,
Ireland

Company No.: 370845



From mike at mtcc.com  Mon Dec  5 09:22:43 2011
From: mike at mtcc.com (Michael Thomas)
Date: Mon, 05 Dec 2011 07:22:43 -0800
Subject: On Working Remotely
In-Reply-To: <201112051009.09009.david@davidradcliffe.org>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>
 <201112051009.09009.david@davidradcliffe.org>
Message-ID: <4EDCE1C3.2070208@mtcc.com>

What the heck...

I've been working on a project for the last three years at home and
mostly by myself. It has been one of the more productive times of my
life codingwise precisely because I am at home and can juggle life's
responsibilities as needed all without really having one. When you go
into the office day-in day-out you have artificial bounds of work/life
-- even though we all know they're blurry these days. I don't know...
I really don't relish those bounds all that much anymore because
inspirations hit when they do, not when you happen to be in the
office (like, oh say, after the morning shower).

The downside is not having somebody to bounce ideas off of, even
if it's mostly a soliloquy. I've worked around that by having a weekly
meeting with others working on the project which works ok, but it's
not always adequate. On the other hand given that my project is
related to skiing, the lift conversations are terrifyingly geeky for the
poor souls riding with us :)

MIke

On 12/05/2011 07:09 AM, David Radcliffe wrote:
> Same here.  I like isolation just fine and work much more productively and
> usually for a longer time at home.  I don't have kids and my wife has learned
> when she is home if I say I will be working, don't bother me.
>
> It actually works quite well.  I like socializing but not when my mind is on
> work.  I can code very effectively for hours without breaking because I get in
> the zone easily at home.
>
> I do have to say to anyone planning to work from home, make sure you have a
> proper work space.  I have a computer room.  It contains a dozen systems,
> electronics gear and parts (I used to have time for that hobby), and
> comfortable and ergonomic work spaces.  There is no TV.  No reason for one
> because this is the work room.  The mind set should be "I am now in the work
> room, so I am at work."  Really works for me.
>
> On Sunday, December 04, 2011 01:46:51 PM Keegan Holley wrote:
>> Maybe I have a different personality, but I find it much easier to work
>> from home (provided home is empty).  I think "networking" from home, which
>> I do periodically during the week is different from coding from home which
>> I do on the weekends.  It does take some getting used to.  I find I'm much
>> more productive from home. (again as long as home is empty)  I spend less
>> time talking about sports (professional, college and little league) TV, the
>> opposite sex, hunting... etc. etc.  I also tend to make healthier choices
>> since the coffee and cigarettes aren't free and no one invites me to order
>> pizza for lunch when I'm at home.  To each his own though.
>>
>> 2011/12/4 Jay Ashworth<jra at baylink.com>
>>
>>> Some more thoughts on telecommuting, from the guy who built Stack
>>> Overflow.
>>>
>>> http://www.codinghorror.com/blog/2010/05/on-working-remotely.html
>>>
>>> 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 sean at seanharlow.info  Mon Dec  5 09:35:27 2011
From: sean at seanharlow.info (Sean Harlow)
Date: Mon, 5 Dec 2011 10:35:27 -0500
Subject: On Working Remotely
In-Reply-To: <201112051009.09009.david@davidradcliffe.org>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>
 <201112051009.09009.david@davidradcliffe.org>
Message-ID: <5E35BA1B-0B09-4E3E-8F45-B9A4F2EDEDBC@seanharlow.info>

I can not agree with this more.  I have been working from home for two years now and unfortunately live in a small apartment where I do not have a dedicated space to assign for "work".  My "workstation" is also my gaming machine and my servers sit right next to my game consoles.  It's impossible to get entirely in to a work mindset when your bed is literally two feet from where you sit.  This one's hard to solve when you don't have the space, I can certainly say there's a reason I have the most time put in to Skyrim out of all of my friends.

Another thing you might not think about is how much it can interfere with anything you consider part of a morning routine.  Where you used to get up at 8, shower, eat breakfast, get dressed, etc. before heading in to start work at 9 it doesn't take long before you realize you can instead wake up at 8:59, put on whatever pants might be within arm's reach, and sit down at your chair.  Next thing you know it's 6 PM and you haven't eaten or showered yet.  I've started setting an alarm and trying to work out in the morning to counter this and it works pretty well, but it took some effort.

tl;dr version: Working in an office provides structure that you may depend on without realizing it.  Be prepared to replicate as much of that structure as needed to remain productive and not turn in to a slob.
----------
Sean Harlow
sean at seanharlow.info

On Dec 5, 2011, at 10:09 AM, David Radcliffe wrote:

> I do have to say to anyone planning to work from home, make sure you have a 
> proper work space.  I have a computer room.  It contains a dozen systems, 
> electronics gear and parts (I used to have time for that hobby), and 
> comfortable and ergonomic work spaces.  There is no TV.  No reason for one 
> because this is the work room.  The mind set should be "I am now in the work 
> room, so I am at work."  Really works for me.



From jschauma at netmeister.org  Mon Dec  5 09:40:04 2011
From: jschauma at netmeister.org (Jan Schaumann)
Date: Mon, 5 Dec 2011 10:40:04 -0500
Subject: On Working Remotely
In-Reply-To: <201112051009.09009.david@davidradcliffe.org>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>
 <201112051009.09009.david@davidradcliffe.org>
Message-ID: <20111205154003.GP22948@netmeister.org>

David Radcliffe <david at davidradcliffe.org> wrote:
 
> I do have to say to anyone planning to work from home, make sure you have a 
> proper work space.

For whatever it's worth:

I have been working from home for the last 3.5 years.  I live in
Manhattan in a one-bedroom with a 4 year and now a 2 months old
daughter, meaning I work on my laptop in the middle of the livingroom
with all my life around me.

I context-switch a lot; I put down the laptop to read my daughters a
story or play for a few minutes, I go shopping, cook etc.  But: when I
go to visit the office (about once a quarter or so), I wonder how on
earth my colleagues get any work done.  They are constantly interrupted,
asked to have coffee, lunch, breakfast, a snack, go for a walk and just
chew the fat.

Yes, I work a lot at night and on the weekends.  That is the one thing
that people who do not work from home are not aware of: you have no more
distinction between "home" and "office", which usually means that when
I'm home, I'm working.

I could see how having a "home office" with a closed door could create
this impression of "going to the office" and "coming home", but I don't
find it either desirable nor (in Manhattan) practical.

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

From lists at mtin.net  Mon Dec  5 09:55:00 2011
From: lists at mtin.net (Justin Wilson)
Date: Mon, 05 Dec 2011 10:55:00 -0500
Subject: On Working Remotely
In-Reply-To: <20111205154003.GP22948@netmeister.org>
Message-ID: <CB025215.21AAF%lists@mtin.net>

I have been working from my home on a regular basis for almost 4 years
now. I visit clients and routinely travel for projects.  However, I work
80% out of my home office.  I have instant messenger for clients who want
to ask a quick question.  Sometimes we just end up chewing the fat, which
is a nice distraction.

I agree with a dedicated workspace as much as possible.  Doesn't have to
be a separate room or whatever.  Just a place set aside where you can keep
work things separate from everything else. Even if you have 2 desks side
by side.  Buddy of mine lives in a small flat and has 2 small desks side
by side.  The second desk is for gaming and other activities.  This way he
can just "walk away" from work and not have to move things out of the way.
 When he returns things are right where they were.

My breaks consist of going downstairs and playing a round of some online
game for 10 minutes or so.  I find myself much more productive as well.
No more hour long commute one way. I can use that hour much more
productive or simply sleep in because I was up late working on a router.

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




From bblackford at gmail.com  Mon Dec  5 10:13:19 2011
From: bblackford at gmail.com (Bill Blackford)
Date: Mon, 5 Dec 2011 08:13:19 -0800
Subject: On Working Remotely
In-Reply-To: <20111205154003.GP22948@netmeister.org>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>
 <201112051009.09009.david@davidradcliffe.org>
 <20111205154003.GP22948@netmeister.org>
Message-ID: <CAMv18ONHgTPue0s8qbOZ42oSGCyyZj08trHwYj6rkBz2E+WUyw@mail.gmail.com>

Reading this thread, is encouraging to me. My whole team are remote
workers and for myself, I've asked to maintain a cube in a nearby POP.
I have small ones at home who don't understand why dad can't be as
available to them as they wish. For me, I can't focus well with these
kind of distractions especially if I'm on a call or can't drop what
I'm doing, but I admire those who can. Also, at this point, I don't
have a dedicated "office" area at home and find myself huddled over a
work bench in the garage next to my server rack. Not the most ergo
setting.

That said, unlike my co-workers, I don't get a home office stipend, I
spend more in gas and my days are longer when I add the commute time
into the mix. Ideally, I would like to transition to working more at
home. I also perceive it's going to take some time for me to change
the paradigm of 9-5, (6-4) and transition to a model where I can work
the same amount of hours and be just as productive by logging in these
hours in non-contiguous chunks. Having the ability to "context-switch"
as Jan has labeled it, I believe is key here. This is a helpful
thread, thanks you all for sharing.

-b


On Mon, Dec 5, 2011 at 7:40 AM, Jan Schaumann <jschauma at netmeister.org> wrote:
> David Radcliffe <david at davidradcliffe.org> wrote:
>
>> I do have to say to anyone planning to work from home, make sure you have a
>> proper work space.
>
> For whatever it's worth:
>
> I have been working from home for the last 3.5 years. ?I live in
> Manhattan in a one-bedroom with a 4 year and now a 2 months old
> daughter, meaning I work on my laptop in the middle of the livingroom
> with all my life around me.
>
> I context-switch a lot; I put down the laptop to read my daughters a
> story or play for a few minutes, I go shopping, cook etc. ?But: when I
> go to visit the office (about once a quarter or so), I wonder how on
> earth my colleagues get any work done. ?They are constantly interrupted,
> asked to have coffee, lunch, breakfast, a snack, go for a walk and just
> chew the fat.
>
> Yes, I work a lot at night and on the weekends. ?That is the one thing
> that people who do not work from home are not aware of: you have no more
> distinction between "home" and "office", which usually means that when
> I'm home, I'm working.
>
> I could see how having a "home office" with a closed door could create
> this impression of "going to the office" and "coming home", but I don't
> find it either desirable nor (in Manhattan) practical.
>
> -Jan
>



-- 
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.....


From david at davidradcliffe.org  Mon Dec  5 10:49:40 2011
From: david at davidradcliffe.org (David Radcliffe)
Date: Mon, 5 Dec 2011 11:49:40 -0500
Subject: On Working Remotely
In-Reply-To: <5E35BA1B-0B09-4E3E-8F45-B9A4F2EDEDBC@seanharlow.info>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <201112051009.09009.david@davidradcliffe.org>
 <5E35BA1B-0B09-4E3E-8F45-B9A4F2EDEDBC@seanharlow.info>
Message-ID: <201112051149.40594.david@davidradcliffe.org>

Yes, it is easier (I think) if you have the space to dedicate a work room.  My 
game system is in my computer room but I only game twice a week and only with 
my friends.  I have no doubt I might be diagnosed with a little OCD (or 
something) but

Q: Game?
A: It's not Wednesday night.
Q: But you could run the game now?
A: Yes.
Q: But?
A: It's not Wednesday.  I could force myself but the universe would feel odd.

I guess it's really about the mindset.  I suspect I would still work 
effectively in a smaller, non-dedicated workspace.  I have before in hotel 
rooms.  Not at my mother's house.  She doesn't get "Gee, mom, I need to focus 
for a while."

Obviously, there is no one solution for everyone but I hope to find a way (with 
current employer, but most likely will have to change employers) for me to 
work from home.  Part of my goal is actually to find someone who will more 
deeply use my talents.

As you say, you can find yourself rolling out of bed and dropping into work 
without eating or showering.  I have often done this and am quite comfortable 
with it.

On Monday, December 05, 2011 10:35:27 AM Sean Harlow wrote:
> I can not agree with this more.  I have been working from home for two
> years now and unfortunately live in a small apartment where I do not have
> a dedicated space to assign for "work".  My "workstation" is also my
> gaming machine and my servers sit right next to my game consoles.  It's
> impossible to get entirely in to a work mindset when your bed is literally
> two feet from where you sit.  This one's hard to solve when you don't have
> the space, I can certainly say there's a reason I have the most time put
> in to Skyrim out of all of my friends.
> 
> Another thing you might not think about is how much it can interfere with
> anything you consider part of a morning routine.  Where you used to get up
> at 8, shower, eat breakfast, get dressed, etc. before heading in to start
> work at 9 it doesn't take long before you realize you can instead wake up
> at 8:59, put on whatever pants might be within arm's reach, and sit down
> at your chair.  Next thing you know it's 6 PM and you haven't eaten or
> showered yet.  I've started setting an alarm and trying to work out in the
> morning to counter this and it works pretty well, but it took some effort.
> 
> tl;dr version: Working in an office provides structure that you may depend
> on without realizing it.  Be prepared to replicate as much of that
> structure as needed to remain productive and not turn in to a slob.
> ----------
> Sean Harlow
> sean at seanharlow.info
>

-- 
David Radcliffe
Network Engineer/Linux Specialist
david at davidradcliffe.org
www.davidradcliffe.org

Nothing ever gets solved better with panic.
If you do not know the answer, it is probably "42."


From david at davidradcliffe.org  Mon Dec  5 11:00:25 2011
From: david at davidradcliffe.org (David Radcliffe)
Date: Mon, 5 Dec 2011 12:00:25 -0500
Subject: On Working Remotely
In-Reply-To: <20111205154003.GP22948@netmeister.org>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <201112051009.09009.david@davidradcliffe.org>
 <20111205154003.GP22948@netmeister.org>
Message-ID: <201112051200.25542.david@davidradcliffe.org>

I know many people who can work as you and we all adjust to our setting.  I 
just also know people who gravitate to their distractions and need the wall to 
define work.  It's best for me even though I will work as effectively at 
midnight as in the middle of the day.

I have to say I am impressed.  Working with a 4 year old and 2 month old 
around.  Wow.

On Monday, December 05, 2011 10:40:04 AM Jan Schaumann wrote:
> 
> For whatever it's worth:
> 
> I have been working from home for the last 3.5 years.  I live in
> Manhattan in a one-bedroom with a 4 year and now a 2 months old
> daughter, meaning I work on my laptop in the middle of the livingroom
> with all my life around me.
> 
> I context-switch a lot; I put down the laptop to read my daughters a
> story or play for a few minutes, I go shopping, cook etc.  But: when I
> go to visit the office (about once a quarter or so), I wonder how on
> earth my colleagues get any work done.  They are constantly interrupted,
> asked to have coffee, lunch, breakfast, a snack, go for a walk and just
> chew the fat.
> 
> Yes, I work a lot at night and on the weekends.  That is the one thing
> that people who do not work from home are not aware of: you have no more
> distinction between "home" and "office", which usually means that when
> I'm home, I'm working.
> 
> I could see how having a "home office" with a closed door could create
> this impression of "going to the office" and "coming home", but I don't
> find it either desirable nor (in Manhattan) practical.
> 
> -Jan

-- 
David Radcliffe
Network Engineer/Linux Specialist
david at davidradcliffe.org
www.davidradcliffe.org

Nothing ever gets solved better with panic.
If you do not know the answer, it is probably "42."


From mtinka at globaltransit.net  Fri Dec  2 09:03:52 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 2 Dec 2011 23:03:52 +0800
Subject: APRICOT-2012: Call for Papers
Message-ID: <201112022303.52917.mtinka@globaltransit.net>

Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT)
21 February - 2 March 2012, New Delhi, India
http://www.apricot2012.net

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

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

We are looking for people and proposals that would:

- Offer a technical tutorial on an appropriate topic; and/or
- Participate in the technical conference sessions as a speaker; and/or
- Convene and chair a Birds of a Feather (BOF) session.

Please submit proposals on-line at:

	http://submission.apnic.net/

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

Call for Papers Opens:          22 November 2011
First Draft Program Published:  19 December 2011
Final Deadline for Submissions: 10 February 2012
Final Program Published:        17 February 2012
Final Slides Received:          25 February 2012

PROGRAM MATERIAL
----------------

The APRICOT Programme is organised in three parts, including
workshops, tutorials and the conference. The APNIC Policy SIG and
Annual Members Meeting will be held during the APRICOT conference.

Topics for tutorials and conference would include amongst others
relevant to Internet Operations and Technologies:

- IPv4 / IPv6 Routing and operations
- IPv4 address runout / IPv6 deployment and transition technologies
- Backbone operations
- ISP and Carrier services
- Network security issues (NSP-SEC, DDoS Anti-Spam, Anti-Malware)
- Peering / IXPs
- DNS / DNSSEC
- Internet policy (Security, Regulation, Content Management, Addressing, etc)
- Access and Transport Technologies, including broadband deployment, Cable/DSL, wireless, WiMax, metro ethernet, fiber
  network, MPLS
- Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming)

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

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

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

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

While the majority of speaking slots will be filled by the first
submission deadline, a limited number of slots may be available up to
the final submission deadline for presentations that are exceptionally
timely, important, or of critical operational importance.

Please submit on-line at:

	http://submission.apnic.net/

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

        pc-chairs at apricot.net

We look forward to receiving your presentation proposals.

Mark Tinka & Jonny Martin
Co-Chairs, APRICOT Programme Committee
program at apricot.net
-------------- 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/20111202/69782a94/attachment-0001.bin>

From alexlh at ripe.net  Mon Dec  5 09:20:27 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:20:27 +0100
Subject: 128.0.0.0/16 configured as martians in some routers
Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>

Dear Colleagues,

The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.

All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.

We urge everyone to change the default behaviour of their Juniper routers:

set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow

128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:

http://www.ris.ripe.net/debogon/

To facilitate testing, the following prefixes are being announced:

prefix	pinagble address

128.0.0.0/16	128.0.0.1
128.0.8.0/21	128.0.8.1
128.0.24.0/24	128.0.24.1

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC

From alexlh at ripe.net  Mon Dec  5 09:20:27 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:20:27 +0100
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers
Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>

Dear Colleagues,

The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.

All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.

We urge everyone to change the default behaviour of their Juniper routers:

set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow

128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:

http://www.ris.ripe.net/debogon/

To facilitate testing, the following prefixes are being announced:

prefix	pinagble address

128.0.0.0/16	128.0.0.1
128.0.8.0/21	128.0.8.1
128.0.24.0/24	128.0.24.1

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC



From alexlh at ripe.net  Mon Dec  5 09:48:39 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:48:39 +0100
Subject: 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
Message-ID: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>

Dear Colleagues,

The correct prefix and pingable address list for the Debogonising Project is:

prefix	        pinagble address

128.0.0.0/21	128.0.0.1
128.0.24.0/24	128.0.24.1

Our apologies for the oversight.

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC


On Dec 5, 2011, at 16:20, Alex Le Heux wrote:

> Dear Colleagues,
> 
> The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.
> 
> All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.
> 
> We urge everyone to change the default behaviour of their Juniper routers:
> 
> set routing-options martians 128.0.0.0/16 orlonger allow
> set routing-options martians 191.255.0.0/16 orlonger allow
> set routing-options martians 223.255.255.0/24 exact allow
> 
> 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:
> 
> http://www.ris.ripe.net/debogon/
> 
> To facilitate testing, the following prefixes are being announced:
> 
> prefix	pinagble address
> 
> 128.0.0.0/16	128.0.0.1
> 128.0.8.0/21	128.0.8.1
> 128.0.24.0/24	128.0.24.1
> 
> Best regards,
> 
> Alex Le Heux
> Policy Implementation Co-ordinator
> RIPE NCC






From alexlh at ripe.net  Mon Dec  5 09:20:27 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:20:27 +0100
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers
Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>

Dear Colleagues,

The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.

All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.

We urge everyone to change the default behaviour of their Juniper routers:

set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow

128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:

http://www.ris.ripe.net/debogon/

To facilitate testing, the following prefixes are being announced:

prefix	pinagble address

128.0.0.0/16	128.0.0.1
128.0.8.0/21	128.0.8.1
128.0.24.0/24	128.0.24.1

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC


From alexlh at ripe.net  Mon Dec  5 09:20:27 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:20:27 +0100
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers
Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>

Dear Colleagues,

The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.

All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.

We urge everyone to change the default behaviour of their Juniper routers:

set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow

128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:

http://www.ris.ripe.net/debogon/

To facilitate testing, the following prefixes are being announced:

prefix	pinagble address

128.0.0.0/16	128.0.0.1
128.0.8.0/21	128.0.8.1
128.0.24.0/24	128.0.24.1

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC


From alexlh at ripe.net  Mon Dec  5 09:20:27 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:20:27 +0100
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers
Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>

Dear Colleagues,

The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.

All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.

We urge everyone to change the default behaviour of their Juniper routers:

set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow

128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:

http://www.ris.ripe.net/debogon/

To facilitate testing, the following prefixes are being announced:

prefix	pinagble address

128.0.0.0/16	128.0.0.1
128.0.8.0/21	128.0.8.1
128.0.24.0/24	128.0.24.1

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC


From alexlh at ripe.net  Mon Dec  5 09:20:27 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:20:27 +0100
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers
Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>

Dear Colleagues,

The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.

All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.

We urge everyone to change the default behaviour of their Juniper routers:

set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow

128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:

http://www.ris.ripe.net/debogon/

To facilitate testing, the following prefixes are being announced:

prefix	pinagble address

128.0.0.0/16	128.0.0.1
128.0.8.0/21	128.0.8.1
128.0.24.0/24	128.0.24.1

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC


From alexlh at ripe.net  Mon Dec  5 09:20:27 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:20:27 +0100
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers
Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>

Dear Colleagues,

The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.

All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.

We urge everyone to change the default behaviour of their Juniper routers:

set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow

128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:

http://www.ris.ripe.net/debogon/

To facilitate testing, the following prefixes are being announced:

prefix	pinagble address

128.0.0.0/16	128.0.0.1
128.0.8.0/21	128.0.8.1
128.0.24.0/24	128.0.24.1

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC


From alexlh at ripe.net  Mon Dec  5 09:48:39 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:48:39 +0100
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in somerouters
In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
Message-ID: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>

Dear Colleagues,

The correct prefix and pingable address list for the Debogonising Project is:

prefix	        pinagble address

128.0.0.0/21	128.0.0.1
128.0.24.0/24	128.0.24.1

Our apologies for the oversight.

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC


On Dec 5, 2011, at 16:20, Alex Le Heux wrote:

> Dear Colleagues,
> 
> The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.
> 
> All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.
> 
> We urge everyone to change the default behaviour of their Juniper routers:
> 
> set routing-options martians 128.0.0.0/16 orlonger allow
> set routing-options martians 191.255.0.0/16 orlonger allow
> set routing-options martians 223.255.255.0/24 exact allow
> 
> 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:
> 
> http://www.ris.ripe.net/debogon/
> 
> To facilitate testing, the following prefixes are being announced:
> 
> prefix	pinagble address
> 
> 128.0.0.0/16	128.0.0.1
> 128.0.8.0/21	128.0.8.1
> 128.0.24.0/24	128.0.24.1
> 
> Best regards,
> 
> Alex Le Heux
> Policy Implementation Co-ordinator
> RIPE NCC








From macsaorsa at gmail.com  Mon Dec  5 11:52:57 2011
From: macsaorsa at gmail.com (Paul Brown)
Date: Mon, 05 Dec 2011 12:52:57 -0500
Subject: High latency/dropped packets on Mitel circuit in LA
Message-ID: <4EDD04F9.8010407@gmail.com>

I'm having some pretty bad connection issues with one of my remote
offices in LA. I figured it was probably wind-related last week but it's
still going on today. The vendor (Mitel) is saying that they're testing
the circuit as good to the router, but I doubt it because I'm seeing the
same missed pings on both the outside and inside interfaces from here
(Richmond, VA) across the MPLS network.

I know it's possible that it could be the router, but my gut tells me
it's a circuit issue. Does anybody know of anything going on out there?

Thanks,
Paul


From victoresposito at yahoo.com  Mon Dec  5 12:41:42 2011
From: victoresposito at yahoo.com (Victor Esposito)
Date: Mon, 5 Dec 2011 10:41:42 -0800 (PST)
Subject: Global BGP and Google
Message-ID: <1323110502.64552.YahooMailNeo@web160104.mail.bf1.yahoo.com>

Has anyone had any experience with a Global? ASN, and Google inappropriately associating IP's to the wrong countries?
?
We have our AS registered in Argentina, with ARIN space under it.? From time to time, Google thinks the IP's are in Argentina, even though they are in the US.? We have this issue elsewhere across the globe as well.
?
I was pondering multiple ASN's, but I was not sure if there was a better method for dealing with this.
?
?
Thanks in advance!

Victor Esposito

From cmadams at hiwaay.net  Mon Dec  5 13:44:22 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 5 Dec 2011 13:44:22 -0600
Subject: 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>
Message-ID: <20111205194422.GC26078@hiwaay.net>

Once upon a time, Alex Le Heux <alexlh at ripe.net> said:
> Dear Colleagues,
> 
> The correct prefix and pingable address list for the Debogonising Project is:
> 
> prefix	        pinagble address
> 
> 128.0.0.0/21	128.0.0.1
> 128.0.24.0/24	128.0.24.1
> 
> Our apologies for the oversight.

Are these prefixes being announced widely?  I don't see anything for
128.0.0.0/16 from my upstreams, nor at many public looking glasses.

-- 
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 bmanning at vacation.karoshi.com  Mon Dec  5 13:50:17 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 5 Dec 2011 19:50:17 +0000
Subject: On Working Remotely
In-Reply-To: <201112051200.25542.david@davidradcliffe.org>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <201112051009.09009.david@davidradcliffe.org>
 <20111205154003.GP22948@netmeister.org>
 <201112051200.25542.david@davidradcliffe.org>
Message-ID: <20111205195017.GA1454@vacation.karoshi.com.>


the problem w/ working from home is that not everyone appreciates "Those Darned Accordians" or
"Insane Clown Posse" or "Donny and Marie Osmand" at 0330 local cranked up to 11...

Much easier to pull off in a remote, mostly empty office building.

And no one complains about my singing off key.

/bill


From tayeb.meftah at gmail.com  Sun Dec  4 12:27:21 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Sun, 4 Dec 2011 20:27:21 +0200
Subject: 128.0.0.0/16 configured as martians in some routers
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>
 <20111205194422.GC26078@hiwaay.net>
Message-ID: <2E68B0902E15414AA2CFD150B36AD438@work>

We do have it from Level3:

C:\Documents and Settings\TAYEB>tracert 128.0.0.1

D?termination de l'itin?raire vers 128.0.0.1 avec un maximum de 30 sauts.

  1     1 ms     3 ms     3 ms  172.28.0.1
  2     3 ms     3 ms     3 ms  10.16.0.1
  3    13 ms    15 ms    16 ms  41.200.0.1
  4    32 ms    12 ms    16 ms  172.17.2.25
  5    15 ms    16 ms    16 ms  213.140.58.10
  6    35 ms    40 ms    34 ms  212.73.253.65
  7    39 ms    39 ms    39 ms  ae-5-6.bar2.Marseille1.Level3.net 
[4.69.151.13]

  8    52 ms    76 ms    54 ms  ae-15-15.ebr1.Frankfurt1.Level3.net 
[4.69.143.24
6]
  9    56 ms    56 ms    55 ms  ae-81-81.csw3.Frankfurt1.Level3.net 
[4.69.140.10
]
 10    55 ms    55 ms    57 ms  ae-82-82.ebr2.Frankfurt1.Level3.net 
[4.69.140.25
]
 11    58 ms    67 ms    62 ms  ae-46-46.ebr1.Dusseldorf1.Level3.net 
[4.69.143.1
69]
 12    55 ms    55 ms    56 ms  ae-24-24.ebr2.Dusseldorf1.Level3.net 
[4.69.143.1
94]
 13   172 ms    58 ms    57 ms  ae-48-48.ebr1.Amsterdam1.Level3.net 
[4.69.143.20
9]
 14    58 ms    58 ms    67 ms  ae-59-114.csw1.Amsterdam1.Level3.net 
[4.69.153.1
98]
 15    60 ms    62 ms    62 ms  ae-19-51.sar1.Amsterdam1.Level3.net 
[4.69.139.14
6]
 16     *       56 ms    58 ms  128.0.0.1

Itin?raire d?termin?.

C:\Documents and Settings\TAYEB>

----- Original Message ----- 
From: "Chris Adams" <cmadams at hiwaay.net>
To: "Alex Le Heux" <alexlh at ripe.net>
Cc: <nanog at nanog.org>
Sent: Monday, December 05, 2011 9:44 PM
Subject: Re: 128.0.0.0/16 configured as martians in some routers


> Once upon a time, Alex Le Heux <alexlh at ripe.net> said:
>> Dear Colleagues,
>>
>> The correct prefix and pingable address list for the Debogonising Project 
>> is:
>>
>> prefix         pinagble address
>>
>> 128.0.0.0/21 128.0.0.1
>> 128.0.24.0/24 128.0.24.1
>>
>> Our apologies for the oversight.
>
> Are these prefixes being announced widely?  I don't see anything for
> 128.0.0.0/16 from my upstreams, nor at many public looking glasses.
>
> -- 
> 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.
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6686 (20111205) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> 


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6686 (20111205) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From pixitha.kyle at gmail.com  Mon Dec  5 16:09:11 2011
From: pixitha.kyle at gmail.com (Kyle Duren)
Date: Mon, 5 Dec 2011 14:09:11 -0800
Subject: 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <20111205194422.GC26078@hiwaay.net>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>
 <20111205194422.GC26078@hiwaay.net>
Message-ID: <CADehQgQxgNKtU4ZHfb=-kwHN4kqSF6TfAwUYp=EVEh7gMc6HWQ@mail.gmail.com>

I'm see them from NTT.

-Kyle

On Mon, Dec 5, 2011 at 11:44 AM, Chris Adams <cmadams at hiwaay.net> wrote:

> Once upon a time, Alex Le Heux <alexlh at ripe.net> said:
> > Dear Colleagues,
> >
> > The correct prefix and pingable address list for the Debogonising
> Project is:
> >
> > prefix                pinagble address
> >
> > 128.0.0.0/21  128.0.0.1
> > 128.0.24.0/24 128.0.24.1
> >
> > Our apologies for the oversight.
>
> Are these prefixes being announced widely?  I don't see anything for
> 128.0.0.0/16 from my upstreams, nor at many public looking glasses.
>
> --
> 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 andy at andy.net  Mon Dec  5 16:19:12 2011
From: andy at andy.net (Andy Warner)
Date: Tue, 6 Dec 2011 06:19:12 +0800
Subject: Global BGP and Google
In-Reply-To: <1323110502.64552.YahooMailNeo@web160104.mail.bf1.yahoo.com>
References: <1323110502.64552.YahooMailNeo@web160104.mail.bf1.yahoo.com>
Message-ID: <CAL4ZOFj=xgqb29kXiu17cbf+cxcRCoyUA_9YLrM=XnSs5uwtZA@mail.gmail.com>

On Tue, Dec 6, 2011 at 2:41 AM, Victor Esposito
<victoresposito at yahoo.com> wrote:
> Has anyone had any experience with a Global? ASN, and Google inappropriately associating IP's to the wrong countries?
>
> We have our AS registered in Argentina, with ARIN space under it.? From time to time, Google thinks the IP's are in Argentina, even though they are in the US.? We have this issue elsewhere across the globe as well.
>
> I was pondering multiple ASN's, but I was not sure if there was a better method for dealing with this.
>
>
> Thanks in advance!
>
> Victor Esposito

Maintaining IP-Geolocation mappings in inherently hard so they're not
perfect. You'll probably need to update multiple IP Geolocation
providers, but you can provide corrections to Google using this form:

http://www.google.com/support/websearch/bin/request.py?contact_type=ip

--
Andy


From jbates at brightok.net  Mon Dec  5 16:25:11 2011
From: jbates at brightok.net (Jack Bates)
Date: Mon, 05 Dec 2011 16:25:11 -0600
Subject: On Working Remotely
In-Reply-To: <201112051200.25542.david@davidradcliffe.org>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <201112051009.09009.david@davidradcliffe.org>
 <20111205154003.GP22948@netmeister.org>
 <201112051200.25542.david@davidradcliffe.org>
Message-ID: <4EDD44C7.4060506@brightok.net>

On 12/5/2011 11:00 AM, David Radcliffe wrote:
> I know many people who can work as you and we all adjust to our setting.  I
> just also know people who gravitate to their distractions and need the wall to
> define work.  It's best for me even though I will work as effectively at
> midnight as in the middle of the day.
>
> I have to say I am impressed.  Working with a 4 year old and 2 month old
> around.  Wow.
>

Being a forced office worker, I can honestly say that I still get more 
done at home at night than I do during the day at the office. I'm most 
productive when I have scheduled maintenance, as I'm permitted to sleep 
in, which puts me working during my comfortable time frames (I hate 
getting up early).

When I was younger, I did my best work at the applebee's bar. Even had 
my own brass plate on the bar. C++ and tequila worked well together.

For the record, my home schooling son does more work late at night as well.


Jack


From jbates at brightok.net  Mon Dec  5 16:33:16 2011
From: jbates at brightok.net (Jack Bates)
Date: Mon, 05 Dec 2011 16:33:16 -0600
Subject: 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <20111205194422.GC26078@hiwaay.net>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>
 <20111205194422.GC26078@hiwaay.net>
Message-ID: <4EDD46AC.60909@brightok.net>

On 12/5/2011 1:44 PM, Chris Adams wrote:
> Once upon a time, Alex Le Heux<alexlh at ripe.net>  said:
>> Dear Colleagues,
>>
>> The correct prefix and pingable address list for the Debogonising Project is:
>>
>> prefix	        pinagble address
>>
>> 128.0.0.0/21	128.0.0.1
>> 128.0.24.0/24	128.0.24.1
>>
>> Our apologies for the oversight.
>
> Are these prefixes being announced widely?  I don't see anything for
> 128.0.0.0/16 from my upstreams, nor at many public looking glasses.
>

Once I updated junos 10.4R7.5 martian list, I saw them both from level3 
and qwest, but not from Sprint.


Jack


From cmadams at hiwaay.net  Mon Dec  5 16:36:54 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 5 Dec 2011 16:36:54 -0600
Subject: 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <4EDD46AC.60909@brightok.net>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>
 <20111205194422.GC26078@hiwaay.net> <4EDD46AC.60909@brightok.net>
Message-ID: <20111205223654.GD26078@hiwaay.net>

Once upon a time, Jack Bates <jbates at brightok.net> said:
> On 12/5/2011 1:44 PM, Chris Adams wrote:
> >Once upon a time, Alex Le Heux<alexlh at ripe.net>  said:
> >>Dear Colleagues,
> >>
> >>The correct prefix and pingable address list for the Debogonising Project 
> >>is:
> >>
> >>prefix	        pinagble address
> >>
> >>128.0.0.0/21	128.0.0.1
> >>128.0.24.0/24	128.0.24.1
> >>
> >>Our apologies for the oversight.
> >
> >Are these prefixes being announced widely?  I don't see anything for
> >128.0.0.0/16 from my upstreams, nor at many public looking glasses.
> 
> Once I updated junos 10.4R7.5 martian list, I saw them both from level3 
> and qwest, but not from Sprint.

Sorry, I should have said where I looked.  I'm not seeing them from
Sprint or CenturyLink, nor am I seeing them at route-views/looking
glasses from AT&T or TWTC.
-- 
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 richard.barnes at gmail.com  Mon Dec  5 17:24:35 2011
From: richard.barnes at gmail.com (Richard Barnes)
Date: Mon, 5 Dec 2011 18:24:35 -0500
Subject: Global BGP and Google
In-Reply-To: <CAL4ZOFj=xgqb29kXiu17cbf+cxcRCoyUA_9YLrM=XnSs5uwtZA@mail.gmail.com>
References: <1323110502.64552.YahooMailNeo@web160104.mail.bf1.yahoo.com>
 <CAL4ZOFj=xgqb29kXiu17cbf+cxcRCoyUA_9YLrM=XnSs5uwtZA@mail.gmail.com>
Message-ID: <CACB24MuM8Qc1xZ0HfSrfZjXXC1XPLZ1DxTFQLWFsw4m4WCLJ3A@mail.gmail.com>

See also this:
https://labs.ripe.net/Members/denis/geolocation-prototype-for-ripe-database

Speak up if you want something similar in the ARIN or LACNIC regions.

--Richard

On Dec 5, 2011 5:19 PM, "Andy Warner" <andy at andy.net> wrote:

On Tue, Dec 6, 2011 at 2:41 AM, Victor Esposito
<victoresposito at yahoo.com> wrote:
> Has anyone had a...
Maintaining IP-Geolocation mappings in inherently hard so they're not
perfect. You'll probably need to update multiple IP Geolocation
providers, but you can provide corrections to Google using this form:

http://www.google.com/support/websearch/bin/request.py?contact_type=ip

--
Andy

From bmanning at vacation.karoshi.com  Mon Dec  5 17:44:19 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 5 Dec 2011 23:44:19 +0000
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with
 malware!]
Message-ID: <20111205234419.GD1454@vacation.karoshi.com.>


 With permission....


----- Forwarded message from Fyodor <fyodor at insecure.org> -----

Date: Mon, 5 Dec 2011 14:35:30 -0800

Hi Folks.  I've just discovered that C|Net's Download.Com site has
started wrapping their Nmap downloads (as well as other free software
like VLC) in a trojan installer which does things like installing a
sketchy "StartNow" toolbar, changing the user's default search engine
to Microsoft Bing, and changing their home page to Microsoft's MSN.

The way it works is that C|Net's download page (screenshot attached)
offers what they claim to be Nmap's Windows installer.  They even
provide the correct file size for our official installer.  But users
actually get a Cnet-created trojan installer.  That program does the
dirty work before downloading and executing Nmap's real installer.

Of course the problem is that users often just click through installer
screens, trusting that download.com gave them the real installer and
knowing that the Nmap project wouldn't put malicious code in our
installer.  Then the next time the user opens their browser, they
find that their computer is hosed with crappy toolbars, Bing searches,
Microsoft as their home page, and whatever other shenanigans the
software performs!  The worst thing is that users will think we (Nmap
Project) did this to them!

I took and attached a screen shot of the C|Net trojan Nmap installer
in action.  Note how they use our registered "Nmap" trademark in big
letters right above the malware "special offer" as if we somehow
endorsed or allowed this.  Of course they also violated our trademark
by claiming this download is an Nmap installer when we have nothing to
do with the proprietary trojan installer.

In addition to the deception and trademark violation, and potential
violation of the Computer Fraud and Abuse Act, this clearly violates
Nmap's copyright.  This is exactly why Nmap isn't under the plain GPL.
Our license (http://nmap.org/book/man-legal.html) specifically adds a
clause forbidding software which "integrates/includes/aggregates Nmap
into a proprietary executable installer" unless that software itself
conforms to various GPL requirements (this proprietary C|Net
download.com software and the toolbar don't).  We've long known that
malicious parties might try to distribute a trojan Nmap installer, but
we never thought it would be C|Net's Download.com, which is owned by
CBS!  And we never thought Microsoft would be sponsoring this
activity!

It is worth noting that C|Net's exact schemes vary.  Here is a story
about their shenanigans:

http://www.extremetech.com/computing/93504-download-com-wraps-downloads-in-bloatware-lies-about-motivations

It is interesting to compare the trojaned VLC screenshot in that
article with the Nmap one I've attached.  In that case, the user just
clicks "Next step" to have their machine infected.  And they wrote
"SAFE, TRUSTED, AND SPYWARE FREE" in the trojan-VLC title bar.  It is
telling that they decided to remove that statement in their newer
trojan installer.  In fact, if we UPX-unpack the Trojan CNet
executable and send it to VirusTotal.com, it is detected as malware by
Panda, McAfee, F-Secure, etc:

http://bit.ly/cnet-nmap-vt

According to Download.com's own stats, hundreds of people download the
trojan Nmap installer every week!  So the first order of business is
to notify the community so that nobody else falls for this scheme.
Please help spread the word.

Of course the next step is to go after C|Net until they stop doing
this for ALL of the software they distribute.  So far, the most they
have offered is:

  "If you would like to opt out of the Download.com Installer you can
   submit a request to cnet-installer at cbsinteractive.com. All opt-out
   requests are carefully reviewed on a case-by-case basis."

In other words, "we'll violate your trademarks and copyright and
squandering your goodwill until you tell us to stop, and then we'll
consider your request 'on a case-by-case basis' depending on how much
money we make from infecting your users and how scary your legal
threat is.

F*ck them!  If anyone knows a great copyright attorney in the U.S.,
please send me the details or ask them to get in touch with me.

Also, shame on Microsoft for paying C|Net to trojan open source
software!

Cheers,
Fyodor

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


From jay at west.net  Mon Dec  5 18:39:55 2011
From: jay at west.net (Jay Hennigan)
Date: Mon, 05 Dec 2011 16:39:55 -0800
Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco
In-Reply-To: <CAJO3VzzLSSbWbr57dAjaMr0-ZyHNEmhA2xMVQypxMOZpWStnMw@mail.gmail.com>
References: <CAJO3VzzLSSbWbr57dAjaMr0-ZyHNEmhA2xMVQypxMOZpWStnMw@mail.gmail.com>
Message-ID: <4EDD645B.6070001@west.net>

On 11/19/11 8:11 AM, Righa Shake wrote:
> Hi,
> 
> Am having a problem that is buffling.
> 
> I recently changed a POS link encapsulation from PPP to Frame-relay.
> Since that time the POS interface keeps resetting from time to time.
> 
> On my BGP session am receiving cease notifications from my upstream
> provider.
> 
> The setup is such that we have a cisco on one end and a Juniper on the
> other.
> 
> interface POS0/0/0
>  mtu 4474

Does this match the other end?

>  no ip address
>  no ip unreachables
>  encapsulation frame-relay

You might try "encapsulation frame-relay ietf"  for full compatibility
with non-Cisco gear at the other end.


>  logging event link-status
>  crc 32
>  pos scramble-atm
>  frame-relay lmi-type ansi
> end
> 
> ROUTERshow run int pos0/0/0.101
> Building configuration...

[snippage]
> !
> interface POS0/0/0.101 point-to-point

>   LMI enq sent  81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up
                  ^^^^^                 ^^^^^
Something is dropping frames.

[snippage]

>   Last clearing of "show interface" counters 1w2d

[snippage]

>      6970870 runts, 2179 giants, 0 throttles
>               0 parity
>      892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored,
> 3335463 abort

Lots of CRC line errors, runts, giants, LMI dropped frames.  Kind of
looks like you could have a physical problem with the link itself.


--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From surfer at mauigateway.com  Mon Dec  5 18:55:04 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 5 Dec 2011 16:55:04 -0800
Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco
Message-ID: <20111205165504.2DC0C71@m0005297.ppops.net>



On 11/19/11 8:11 AM, Righa Shake wrote:
> Hi,
> 
> Am having a problem that is buffling.
> 
> I recently changed a POS link encapsulation from PPP to Frame-relay.
> Since that time the POS interface keeps resetting from time to time.
> 
> On my BGP session am receiving cease notifications from my upstream
> provider.
> 
> The setup is such that we have a cisco on one end and a Juniper on the
> other.
-------------------------------------------------------



Were you not able to get it going after the discussion on AfNOG?

http://afnog.org/pipermail/afnog/2011-November/000016.html

What else is happening?  Still seeing alarms and flapping at the 
reduced rate?  If so, what alarms and how often is it flapping?


scott







From jsaxe at briworks.com  Mon Dec  5 19:20:56 2011
From: jsaxe at briworks.com (Jeff Saxe)
Date: Tue, 6 Dec 2011 01:20:56 +0000
Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco
In-Reply-To: <CAJO3VzzLSSbWbr57dAjaMr0-ZyHNEmhA2xMVQypxMOZpWStnMw@mail.gmail.com>
References: <CAJO3VzzLSSbWbr57dAjaMr0-ZyHNEmhA2xMVQypxMOZpWStnMw@mail.gmail.com>
Message-ID: <A92EB23D9E64824189C99C5ABF8331042081A6DA@mbx024-e1-nj-2.exch024.domain.local>

Ah, memories are flooding back from my Voice over Frame Relay days on a Cisco MC3810. We would crush compressed G.729a voice and barely-enough data for 24 remote call center employees into, I believe, two quarter-T1 frame DLCI's to keep costs down. Anyway, I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that your router was an "end user" device and its directly-connected partner device was not your other router, which you control, but the frame carrier's frame-relay switch. Your router was a DTE device, and their switch, which was in a more "important" position in control of the frame-relay NBMA cloud, was the DCE device. Your router then slaved to the frame switch via LMI signaling, so that the upstream switch instructed you which DLCIs existed and were up at the moment.

So if you connect up two routers with frame-relay encap and each thinks it is the DTE, and neither one is taking the role of the frame switch, then when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes go by and they don't hear the responses to their LMI enquiries, they will bring all the DLCI's down. I thought they would then stay down forever, i.e., not flap, but maybe you are shutting / no shutting the POS circuit to try again. Anyway, I believe the very simple fix is

interface POS0/0/0
frame-relay intf-type dce

So this will turn your Cisco side of the circuit into "DCE" mode, and if the Juniper side stays in "DTE" mode (the default, so probably not listed in the config), then the LMI should start behaving between the two. And yes, as Jay Hennigan suggested, you might need to use "encap frame-relay ietf" to be compatible with non-Cisco gear, or you might need to adjust the frame-relay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DLCI 1023, whatever. I think you'll need to adjust the two ends until you see LMI enquiries both sent and received; right now the "show interface" from the Cisco side shows it has not received any LMI enq yet.


Good luck, and I hope it's that simple.   :-)


Jeff Saxe
blue ridge internetworks

321 east main st ? suite 200
charlottesville va  22902
434.817.0707 x 2024
www.briworks.com

Central Virginia?s technology authority since 2000.

________________________________________
From: Righa Shake [righa.shake at gmail.com]
Sent: Saturday, November 19, 2011 11:11 AM
To: afnog at afnog.org
Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco

Hi,

Am having a problem that is buffling.

I recently changed a POS link encapsulation from PPP to Frame-relay.
Since that time the POS interface keeps resetting from time to time.

On my BGP session am receiving cease notifications from my upstream
provider.

The setup is such that we have a cisco on one end and a Juniper on the
other.

interface POS0/0/0
 mtu 4474
 no ip address
 no ip unreachables
 encapsulation frame-relay
 logging event link-status
 crc 32
 pos scramble-atm
 frame-relay lmi-type ansi
end

ROUTERshow run int pos0/0/0.101
Building configuration...


!
interface POS0/0/0.101 point-to-point
ip address X.X.X.X 255.255.255.252
frame-relay interface-dlci 101
end

ROUTER#show int pos0/0/0
POS0/0/0 is up, line protocol is up
  Hardware is SPA-2XOC12-POS
  MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 6/255, rxload 38/255
  Encapsulation FRAME-RELAY, crc 32, loopback not set
  Keepalive set (10 sec)
  Scramble enabled
  LMI enq sent  81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE  segmentation
inactive
  FR SVC disabled, LAPF state down
  Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts
0
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 1w2d
  Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 94336000 bits/sec, 13151 packets/sec
  5 minute output rate 16470000 bits/sec, 7049 packets/sec
     12211574207 packets input, 10967607038364 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     6970870 runts, 2179 giants, 0 throttles
              0 parity
     892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored,
3335463 abort
     6379191154 packets output, 1614018181446 bytes, 0 underruns
     0 output errors, 0 applique, 4 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions


Any assistance on this will be greatly appreciated.


Regards,
Righa Shake


From smb at cs.columbia.edu  Mon Dec  5 19:29:51 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Mon, 5 Dec 2011 20:29:51 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <20111205234419.GD1454@vacation.karoshi.com.>
References: <20111205234419.GD1454@vacation.karoshi.com.>
Message-ID: <7C3EC9B8-0A33-4382-B21E-3905BB986428@cs.columbia.edu>

> 
> 
> F*ck them!  If anyone knows a great copyright attorney in the U.S.,
> please send me the details or ask them to get in touch with me.


Hmm -- did you say "copyright"?  I wonder what would happen if you sent
them a DMCA takedown notice.  To quote Salvor Hardin, "It's a poor atom 
blaster that doesn't point both ways."  (And there's another Hardin
quote that seems particularly apt when talking about wielding the DMCA:
"Never let your sense of morals prevent you from doing what is right.")

		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From jra at baylink.com  Mon Dec  5 20:07:49 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 5 Dec 2011 21:07:49 -0500 (EST)
Subject: IP addresses are now assets
In-Reply-To: <9895F3A7-847D-44BA-A2E2-43418BE3E677@delong.com>
Message-ID: <30536137.1671.1323137269092.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Owen DeLong" <owen at delong.com>
> On Dec 5, 2011, at 12:27 AM, cdel.firsthand.net wrote: 
> > The British have been using the correct six character word length
> > for humour ad memoriam.
>
> Extra and unnecessary characters do not a correct word make.

The u is silent.

Like the 3 in Hen3ry.

Cheers,
-- jr 'Stein with an "e-i" and Styne with a "y".' 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 jra at baylink.com  Mon Dec  5 20:12:19 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 5 Dec 2011 21:12:19 -0500 (EST)
Subject: On Working Remotely
In-Reply-To: <20111205195017.GA1454@vacation.karoshi.com.>
Message-ID: <25162019.1673.1323137539364.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: bmanning at vacation.karoshi.com

> the problem w/ working from home is that not everyone appreciates "Those
> Darned Accordians" or "Insane Clown Posse" or "Donny and Marie Osmand" at
> 0330 local cranked up to 11...

Nope, Manning; sorry: if you're gonna cop to Donny and Marie, you gotta spell
their last name right.  :-)

Cheers,
-- jr 'at least he didn't spell it Donnie' 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 jra at baylink.com  Mon Dec  5 20:16:35 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 5 Dec 2011 21:16:35 -0500 (EST)
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <20111205234419.GD1454@vacation.karoshi.com.>
Message-ID: <16796209.1677.1323137795128.JavaMail.root@benjamin.baylink.com>

Fyodor:
> F*ck them! If anyone knows a great copyright attorney in the U.S.,
> please send me the details or ask them to get in touch with me.

Larry Lessig?  Mike Godwin?

Might as well start at the top, dude.

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 jcurran at arin.net  Mon Dec  5 21:09:50 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 6 Dec 2011 03:09:50 +0000
Subject: IP addresses are now assets
In-Reply-To: <4ED8686C.6020803@paulgraydon.co.uk>
References: <B4A0C113-1601-4AB7-97A0-607DFA26B861@arin.net>
 <4ED8686C.6020803@paulgraydon.co.uk>
Message-ID: <457C7781-E2B7-4AD0-BE26-8EB8A1EF7AF4@corp.arin.net>

On Dec 2, 2011, at 1:55 AM, Paul Graydon wrote:

> On 12/1/2011 7:20 PM, John Curran wrote:
>> Wayne -
>> 
>> Your subject line (IP addresses are now assets) could mislead folks,
>> so I'd advise waiting to review the actual sale order once approved by
>> the court before making summary conclusions.
>> 
>> ARIN holds that IP address space is not property but is managed as a
>> public resource.  Address holders may have certain rights (such as the
>> right to be the registrant of the address block, the right to transfer the
>> registration, etc.) but these rights intersect with additional rights to the
>> same address blocks which are held by the community (such as the right
>> of visibility to the public portion of registrations).  The registry policies
>> (set by the community via open and transparent processes) govern the
>> intersection and application of these rights.
>> 
>> For this reason, ARIN works with parties transferring their rights in IP
>> address space to make sure that the documents reflect that sales of
>> rights are subject to the transfer policies in the region, including in this
>> particular case.  A party may transfer their rights to IP addresses, and
>> such rights may have value to an estate, but this does not make the
>> IP addresses "property" per se.
>> 
>> Thanks!
>> /John
>> 
> 
> Why'd you have to spoil the fun?  You're supposed to wait a few days, let the pointless righteous fury build up and then step in and try to do the firefighting thing.  It's must have been all but a month since the last time this flared up, it's surely about time it flared up again?  Wouldn't want anyone to miss out on the fun ;)

That's okay...  it will happen anyway. ;-)

For those who are following this matter, there are some more complete
articles now (including pointers to the court documents filed) - 

  <http://www.theregister.co.uk/2011/12/05/borders_flogs_ipv4_addys/>
  <http://domainincite.com/docs/borders-cerner-ipv4.pdf>

FYI,
/John

John Curran
President and CEO
ARIN

From daniel.unam.ipv6 at gmail.com  Mon Dec  5 21:35:35 2011
From: daniel.unam.ipv6 at gmail.com (Daniel Espejel)
Date: Mon, 05 Dec 2011 21:35:35 -0600
Subject: HP IPv6 RA Guard
In-Reply-To: <mailman.15875.1323080381.1873.nanog@nanog.org>
References: <mailman.15875.1323080381.1873.nanog@nanog.org>
Message-ID: <4EDD8D87.30208@gmail.com>

So,still assuming the fact that attackers will use the same "traditional
ipv4" methods to alter the correct functioning over a network?...Well,
maybe. Toda's IPv6 expertise for some network andmins and security
experts is minimal. So most trainning and understanding before
implementing its a good idea.

For example, the RA-Guard method has a significant vulnerability: It's
not designed to identify a "complex" IPv6-many extension headers formed
packet (F. Gont - 6Networks). Some other security oriented mechanisms
may fail because of the low IPv6 compliance.

Regards.


-- 
Daniel Espejel P?rez
T?cnico Acad?mico
D.G.T.I.C. - U.N.A.M.
GT-IPv6 CLARA / GT-IPv6 U.N.A.M.



From streiner at cluebyfour.org  Mon Dec  5 22:01:04 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Mon, 5 Dec 2011 23:01:04 -0500 (EST)
Subject: On Working Remotely
In-Reply-To: <201112051009.09009.david@davidradcliffe.org>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>
 <201112051009.09009.david@davidradcliffe.org>
Message-ID: <Pine.LNX.4.64.1112052251400.5835@whammy.cluebyfour.org>

On Mon, 5 Dec 2011, David Radcliffe wrote:

> I do have to say to anyone planning to work from home, make sure you have a
> proper work space.  I have a computer room.  It contains a dozen systems,
> electronics gear and parts (I used to have time for that hobby), and
> comfortable and ergonomic work spaces.  There is no TV.  No reason for one
> because this is the work room.  The mind set should be "I am now in the work
> room, so I am at work."  Really works for me.

That's one of the reasons that I don't work from home very much at this 
point - I don't have a proper office, however I'm hoping to fix that some 
time next year.  The other reasons I don't work from home very much are 
that my job still has a lot of hands-on responsibilities (which I don't 
mind - pulling cable or racking equipment is a nice break from staring at 
a screen for long periods of time), and, unfortunately, upper managements'
perceptions of things like teleworking and flex/comp time have not caught 
up with the times :(

jms


From bill at herrin.us  Mon Dec  5 22:20:04 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 5 Dec 2011 18:20:04 -1000
Subject: On Working Remotely
In-Reply-To: <CAP-guGW_y9eM9pR0W-6OVX1EsMPt=ZgZiGq8465Qk9y-+N2JBg@mail.gmail.com>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <CAP-guGW_y9eM9pR0W-6OVX1EsMPt=ZgZiGq8465Qk9y-+N2JBg@mail.gmail.com>
Message-ID: <CAP-guGURnxE0cMBRTPFW5pS_XekUCmvRyjhaRUrHtT9dYuxr7Q@mail.gmail.com>

I teleworked for a few years back in the '90s. I would share a couple
of thoughts:

1. You have to have the disposition for it. For a coder, you have to
be the kind of person who sits down at a computer and writes code,
just because. If it would "require discipline" for you to work from a
home office, telework may not be right for you.

2. If most of the team works in an office, full time telework for any
member of the team is hard. Folks working together in an office
develop a social dynamic. Folks who aren't there aren't a part of that
dynamic. Teleworking is most likely to work out when most or all of
the team teleworks, not just particular members.

2a. You can still telework two days a week and spend the other three
in an office. But not Monday or Friday. Especially not Friday -- after
the rest of the week working in the office, you just won't do it. Your
brain will turn off if you try to work from home Friday after Thursday
in the office.

3. Beware tracking hours. Try to select work which is goal and
deadline based. Your supervisor won't see you in your seat; he can
only judge your performance on what you actually accomplish. When I
teleworked, I found myself taking breaks to mow the lawn, ride a bike
on a nice day or tinker with a personal server. Tracking hours under
such circumstances is almost impossibly hard. Measuring progress
towards a goal is less so.

-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 frnkblk at iname.com  Tue Dec  6 00:11:42 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Tue, 6 Dec 2011 00:11:42 -0600
Subject: Email from AssetAuctions
Message-ID: <017501ccb3dd$ec6e7cf0$c54b76d0$@iname.com>

Did anyone else received unsolicited an email from AssetAuctions?  Our CFO
received an email from them selling two full /16's and a partial /16.  There
is an unsubscribe feature, but I thought it was interesting, in light of the
Border's IP sale event.  

I was encouraged by this language,
	This opportunity is available to a company with justifiable 
	need to acquire large contiguous blocks of IP addresses. 

	The Buyer must ensure compliance with certain requirements 
	of the American Registry of Internet Numbers ("ARIN"). 
	Transfer of these IP addresses may be subject to approval 
	by "ARIN" and contingent on verification the transfer 
	request meets the requirements of NRPM 8.3 
	(https://www.arin.net/policy/nrpm.html#eight).

Frank



From andrew.wallace at rocketmail.com  Tue Dec  6 00:14:48 2011
From: andrew.wallace at rocketmail.com (andrew.wallace)
Date: Mon, 5 Dec 2011 22:14:48 -0800 (PST)
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <20111205234419.GD1454@vacation.karoshi.com.>
References: <20111205234419.GD1454@vacation.karoshi.com.>
Message-ID: <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>

Using fruitful language and acting like a child isn't going to see you taken seriously.

Andrew

> ----- Forwarded message from Fyodor <fyodor at insecure.org> -----
> F*ck them!? If anyone knows a great copyright attorney in the U.S.,
> please send me the details or ask them to get in touch with me.
>
> Also, shame on Microsoft for paying C|Net to trojan open source
> software!
>
> Cheers,
> Fyodor
>
> ----- End forwarded message -----

From jvanoppen at spectrumnet.us  Tue Dec  6 00:15:44 2011
From: jvanoppen at spectrumnet.us (John van Oppen)
Date: Tue, 6 Dec 2011 06:15:44 +0000
Subject: 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <20111205223654.GD26078@hiwaay.net>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>
 <20111205194422.GC26078@hiwaay.net> <4EDD46AC.60909@brightok.net>
 <20111205223654.GD26078@hiwaay.net>
Message-ID: <AF24AE2D4A4D334FB9B667985E2AE763019C45FE@mail1-sea.office.spectrumnet.us>

Here is my little table for 128.0.0.0/21 based on our upstreams:

AS7922: Yes
AS174: No
AS2914: Yes
AS3257: Yes
AS2914: Yes
AS2828: No
AS209: Yes


John @ AS11404


From mtinka at globaltransit.net  Tue Dec  6 00:19:00 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Tue, 6 Dec 2011 14:19:00 +0800
Subject: On Working Remotely
In-Reply-To: <4EDD44C7.4060506@brightok.net>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <201112051200.25542.david@davidradcliffe.org> <4EDD44C7.4060506@brightok.net>
Message-ID: <201112061419.03657.mtinka@globaltransit.net>

On Tuesday, December 06, 2011 06:25:11 AM Jack Bates wrote:

> Being a forced office worker, I can honestly say that I
> still get more done at home at night than I do during
> the day at the office. I'm most productive when I have
> scheduled maintenance, as I'm permitted to sleep in,
> which puts me working during my comfortable time frames
> (I hate getting up early).

Agree, I get more work done at home as well, be it at night 
or during the day, than I do during office hours as the a 
good chunk of the week normally ends up being full of face-
to-face meetings, and then it's over.

It is harder to work at home becuse of the distractions, but 
when I can, it is more effective.

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/20111206/b0d9657c/attachment.bin>

From eyeronic.design at gmail.com  Tue Dec  6 00:23:41 2011
From: eyeronic.design at gmail.com (Mike Hale)
Date: Mon, 5 Dec 2011 22:23:41 -0800
Subject: High latency/dropped packets on Mitel circuit in LA
In-Reply-To: <4EDD04F9.8010407@gmail.com>
References: <4EDD04F9.8010407@gmail.com>
Message-ID: <CAN3um4zPFV6WbYhhrp9vz1LCXfVFDAAV7UagzeS9kKrHTG6h9w@mail.gmail.com>

I've had some odd issues with Level 3 in LA, but that was due to an issue
with their TWOceanic interconnect.  Other than that, I haven't heard of
anything.

Do you see any errors on your interface?

- Mike
On Mon, Dec 5, 2011 at 9:52 AM, Paul Brown <macsaorsa at gmail.com> wrote:

> I'm having some pretty bad connection issues with one of my remote
> offices in LA. I figured it was probably wind-related last week but it's
> still going on today. The vendor (Mitel) is saying that they're testing
> the circuit as good to the router, but I doubt it because I'm seeing the
> same missed pings on both the outside and inside interfaces from here
> (Richmond, VA) across the MPLS network.
>
> I know it's possible that it could be the router, but my gut tells me
> it's a circuit issue. Does anybody know of anything going on out there?
>
> Thanks,
> Paul
>
>


-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

From lstewart at superb.net  Tue Dec  6 00:45:56 2011
From: lstewart at superb.net (Landon Stewart)
Date: Mon, 5 Dec 2011 22:45:56 -0800
Subject: On Working Remotely
In-Reply-To: <5E35BA1B-0B09-4E3E-8F45-B9A4F2EDEDBC@seanharlow.info>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <CABO8Q6SO1jXWmqx1S9++rpr1fyVFKcE-vWL9KLfCXr70jz9tFw@mail.gmail.com>
 <201112051009.09009.david@davidradcliffe.org>
 <5E35BA1B-0B09-4E3E-8F45-B9A4F2EDEDBC@seanharlow.info>
Message-ID: <CABgOHgtk=88YR+2yekDrbuFWrYf_N+jjWKdL72y41VkgCO-ZWA@mail.gmail.com>

This thread reminded me of a The Oatmeal comic I saw not too long ago.
 This explains the *good* and *horrible* about working from home.

http://theoatmeal.com/comics/working_home

-- 
Landon Stewart <LStewart at Superb.Net>
Manager of Systems and Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net

From fweimer at bfk.de  Tue Dec  6 02:50:46 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Tue, 06 Dec 2011 08:50:46 +0000
Subject: 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> (Alex Le Heux's
 message of "Mon, 5 Dec 2011 16:20:27 +0100")
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
Message-ID: <82zkf6t76h.fsf@mid.bfk.de>

* Alex Le Heux:

> The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by
> default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline
> that this /16 should no longer be reserved as specialised address
> space.

Would someone please clarify the impact?  Will it result in a blackhole,
or will the entire announcement be suppressed?  I suspect the latter,
given what we see and what Chris Adams has reported.

-- 
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 mtinka at globaltransit.net  Tue Dec  6 03:23:53 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Tue, 6 Dec 2011 17:23:53 +0800
Subject: 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <82zkf6t76h.fsf@mid.bfk.de>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <82zkf6t76h.fsf@mid.bfk.de>
Message-ID: <201112061723.56243.mtinka@globaltransit.net>

On Tuesday, December 06, 2011 04:50:46 PM Florian Weimer wrote:

> Would someone please clarify the impact?  Will it result in a blackhole,
> or will the entire announcement be suppressed?  I suspect the latter,
> given what we see and what Chris Adams has reported.

This is what we see on Cisco IOS and IOS XR boxes:

lab#sh ip bgp 128.0.0.0
BGP routing table entry for 128.0.0.0/21, version 260804693
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2         
  3491 3257 1103 12654
    61.11.xxx.yy (metric 34400) from 61.11.xxx.zz (61.11.xxx.zz)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 24218:1
      Originator: 61.11.xxx.yy, Cluster list: 0.0.0.2
  3491 3257 1103 12654
    61.11.xxx.yy (metric 34400) from 61.11.xxx.ww (61.11.xxx.ww)
      Origin IGP, metric 0, localpref 100, valid, internal
      Community: 24218:1
      Originator: 61.11.xxx.yy, Cluster list: 0.0.0.2
lab#


RP/0/RSP0/CPU0:lab#sh route 128.0.0.0
Tue Dec  6 17:09:13.439 MYT

Routing entry for 128.0.0.0/21
  Known via "bgp 24218", distance 200, metric 0
  Tag 3491, type internal
  Installed Dec  4 20:00:33.089 for 1d21h
  Routing Descriptor Blocks
    61.11.xxx.yy, from 61.11.yyy.zz
      Route metric is 0
  No advertising protos. 
RP/0/RSP0/CPU0:lab#


This is what we see on an unfixed Juniper:

tinka at lab# run show route 128.0.0.0 

inet.0: 384214 destinations, 768288 routes (384212 active, 0 holddown, 4 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 20w2d 13:21:14
                      Discard

[edit]
tinka at lab#


tinka at lab# run show route 128.0.0.0/21 

inet.0: 384218 destinations, 768296 routes (384216 active, 0 holddown, 4 hidden)
Restart Complete

[edit]
tinka at lab#


tinka at edge-gw-1-sin-pip.sg# run show route 128.0.0.0/21 hidden                            

inet.0: 384224 destinations, 768308 routes (384222 active, 0 holddown, 4 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

128.0.0.0/21        [BGP/170] 1d 21:17:54, MED 0, localpref 100, from 61.11.xxx.ww
                      AS path: 3491 3257 1103 12654 I
                    > to 124.158.xxx.uu via ge-0/0/0.0, Push 16052
                      to 124.158.xxx.vv via ge-0/0/0.0, Push 16017
                      to 124.158.xxx.ww via ge-0/1/0.0, Push 16052
                      to 124.158.xxx.xx via ge-0/1/0.0, Push 16017
                    [BGP/170] 1d 21:17:54, MED 0, localpref 100, from 61.11.xxx.zz
                      AS path: 3491 3257 1103 12654 I
                    > to 124.158.xxx.uu via ge-0/0/0.0, Push 16052
                      to 124.158.xxx.vv via ge-0/0/0.0, Push 16017
                      to 124.158.xxx.ww via ge-0/1/0.0, Push 16052
                      to 124.158.xxx.xx via ge-0/1/0.0, Push 16017

[edit]
tinka at edge-gw-1-sin-pip.sg#


tinka at lab# run show route 128.0.0.0/21 hidden extensive | match State 
                State: <Hidden Martian Int Ext>
                State: <Hidden Martian Int Ext>

[edit]
tinka at lab#


tinka at lab# run show interfaces terse
<snip>
...

fxp1                    up    up  
fxp1.0                  up    up   inet     10.0.0.1/8      
                                            10.0.0.4/8      
                                            128.0.0.1/2     
                                            128.0.0.4/2     
                                   inet6    fe80::200:ff:fe00:4/64
                                            fec0::a:0:0:4/64
                                   tnp      0x4 

<snip>
...

[edit]
tinka at lab#


This is what we see on a Cisco router which lives behind
an unfixed Juniper router that is peering externally:

lab#sh ip bgp 128.0.0.0
% Network not in table
lab#


So our deduction - if a Juniper router is in the data path,
it will blackhole traffic destined to this address.

If a Juniper is in the control plane path, it will 
filter this prefix and not send it to the rest of the 
network.

Either way, you're screwed :-).

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/20111206/482077fb/attachment-0001.bin>

From rps at maine.edu  Tue Dec  6 07:46:22 2011
From: rps at maine.edu (Ray Soucy)
Date: Tue, 6 Dec 2011 08:46:22 -0500
Subject: HP IPv6 RA Guard
In-Reply-To: <4EDD8D87.30208@gmail.com>
References: <mailman.15875.1323080381.1873.nanog@nanog.org>
 <4EDD8D87.30208@gmail.com>
Message-ID: <CALFTrnO7PdoBuSiEwSqxnmD7uEPSr9JuFjGEED_Jzizbqa+HRQ@mail.gmail.com>

I think of RA Guard as a Layer-2 stability feature, rather than a
security feature.

You're correct that it is unable to deal with RA crafted in a
fragmented packet on the majority (if not all) of implementations.

The issue of rogue RA exists on every network, regardless of whether
or not the IT group has deployed IPv6 or is aware of the IPv6 traffic
on that network.

Windows ICS is the most common "accidental" cause of rogue RA on a LAN.

On Mon, Dec 5, 2011 at 10:35 PM, Daniel Espejel
<daniel.unam.ipv6 at gmail.com> wrote:
> So,still assuming the fact that attackers will use the same "traditional
> ipv4" methods to alter the correct functioning over a network?...Well,
> maybe. Toda's IPv6 expertise for some network andmins and security
> experts is minimal. So most trainning and understanding before
> implementing its a good idea.
>
> For example, the RA-Guard method has a significant vulnerability: It's
> not designed to identify a "complex" IPv6-many extension headers formed
> packet (F. Gont - 6Networks). Some other security oriented mechanisms
> may fail because of the low IPv6 compliance.
>
> Regards.
>
>
> --
> Daniel Espejel P?rez
> T?cnico Acad?mico
> D.G.T.I.C. - U.N.A.M.
> GT-IPv6 CLARA / GT-IPv6 U.N.A.M.
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From jloiacon at csc.com  Tue Dec  6 08:22:55 2011
From: jloiacon at csc.com (Joe Loiacono)
Date: Tue, 6 Dec 2011 09:22:55 -0500
Subject: On Working Remotely
In-Reply-To: <CAP-guGURnxE0cMBRTPFW5pS_XekUCmvRyjhaRUrHtT9dYuxr7Q@mail.gmail.com>
References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com>
 <CAP-guGW_y9eM9pR0W-6OVX1EsMPt=ZgZiGq8465Qk9y-+N2JBg@mail.gmail.com>
 <CAP-guGURnxE0cMBRTPFW5pS_XekUCmvRyjhaRUrHtT9dYuxr7Q@mail.gmail.com>
Message-ID: <OF5A046917.D40F42A2-ON8525795E.004ED852-8525795E.004F00ED@csc.com>

Beware the office with an Internet connection too:

http://xkcd.com/862/

Don't forget to 'mouseover' the graphic.

Joe

William Herrin <bill at herrin.us> wrote on 12/05/2011 11:20:04 PM:

> 3. Beware tracking hours. Try to select work which is goal and
> deadline based. Your supervisor won't see you in your seat; he can
> only judge your performance on what you actually accomplish. When I
> teleworked, I found myself taking breaks to mow the lawn, ride a bike
> on a nice day or tinker with a personal server. Tracking hours under
> such circumstances is almost impossibly hard. Measuring progress
> towards a goal is less so.

From mir at ripe.net  Tue Dec  6 08:49:33 2011
From: mir at ripe.net (Mirjam Kuehne)
Date: Tue, 06 Dec 2011 15:49:33 +0100
Subject: New on RIPE Labs: The Curious Case of 128.0/16
Message-ID: <4EDE2B7D.9050603@ripe.net>

Dear colleagues,

Related to the discussion about 128.0/16, we did some measurements. The 
details can be found on RIPE Labs:

https://labs.ripe.net/Members/emileaben/the-curious-case-of-128.0-16

Kind regards,
Mirjam Kuehne
RIPE NCC


From cmadams at hiwaay.net  Tue Dec  6 09:38:31 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 6 Dec 2011 09:38:31 -0600
Subject: New on RIPE Labs: The Curious Case of 128.0/16
In-Reply-To: <4EDE2B7D.9050603@ripe.net>
References: <4EDE2B7D.9050603@ripe.net>
Message-ID: <20111206153831.GA22818@hiwaay.net>

Once upon a time, Mirjam Kuehne <mir at ripe.net> said:
> Dear colleagues,
> 
> Related to the discussion about 128.0/16, we did some measurements. The 
> details can be found on RIPE Labs:
> 
> https://labs.ripe.net/Members/emileaben/the-curious-case-of-128.0-16
> 
> Kind regards,
> Mirjam Kuehne
> RIPE NCC

Using RIPE's traceroute web interface, I can see that Sprint is
filtering 128.0.0.0/16:

from 128.0.0.1
traceroute to 216.180.54.1 (216.180.54.1), 30 hops max, 40 byte packets
 1  gw.nik-guest.nikrtr.ripe.net (193.0.0.234)  0.803 ms  1.005 ms  1.061 ms
 2  ams16-core-1.gigabiteth8-1-0.swip.net (195.69.145.139)  0.551 ms  0.466 ms  0.641 ms
 3  ams-core-1.tengige0-0-0-6.tele2.net (130.244.49.198)  3.378 ms  3.467 ms  3.624 ms
 4  nyc9-core-1.pos8-0-0.tele2.net (130.244.218.214)  76.618 ms  76.683 ms  76.746 ms
 5  * * *

from 193.0.0.232
traceroute to 216.180.54.1 (216.180.54.1), 30 hops max, 40 byte packets
 1  gw.nik-guest.nikrtr.ripe.net (193.0.0.234)  0.466 ms  0.514 ms  0.608 ms
 2  ams16-core-1.gigabiteth8-1-0.swip.net (195.69.145.139)  0.684 ms  0.581 ms  0.563 ms
 3  ams-core-1.tengige0-0-0-6.tele2.net (130.244.49.198)  3.890 ms  3.919 ms  3.912 ms
 4  nyc9-core-1.pos8-0-0.tele2.net (130.244.218.214)  76.292 ms  76.317 ms  76.304 ms
 5  144.223.26.73 (144.223.26.73)  76.639 ms  76.475 ms  76.511 ms
(and on to my IP)

I believe that Sprint is using Cisco, not Juniper.  This is either a
manual filter or there is another (unidentified) issue with some Cisco
configurations.

I've opened a ticket with Sprint, although I don't know how far it will
go, since I'm getting a MySQL syntax error trying to view the ticket in
their web interface (somebody must not understand SQL injection security
issues).

-- 
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 jbates at brightok.net  Tue Dec  6 09:47:21 2011
From: jbates at brightok.net (Jack Bates)
Date: Tue, 06 Dec 2011 09:47:21 -0600
Subject: New on RIPE Labs: The Curious Case of 128.0/16
In-Reply-To: <20111206153831.GA22818@hiwaay.net>
References: <4EDE2B7D.9050603@ripe.net> <20111206153831.GA22818@hiwaay.net>
Message-ID: <4EDE3909.6040105@brightok.net>

On 12/6/2011 9:38 AM, Chris Adams wrote:
>
> I believe that Sprint is using Cisco, not Juniper.  This is either a
> manual filter or there is another (unidentified) issue with some Cisco
> configurations.
>

People are less likely to read an RFC changing the reserved addresses. 
Even people who didn't filter unassigned addressing, might filter RFC 
reserved addressing. The fact that it's built into some routers 
automatically kind of makes the point.


Jack


From tdurack at gmail.com  Tue Dec  6 10:02:28 2011
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 6 Dec 2011 11:02:28 -0500
Subject: Mexico City IP/Ethernet/Wave/Fiber/Colo/IXP etc...
Message-ID: <CAE_ug16SP8mT0U8EiCNTW9OuvXxUSYECCM1q_XmxJMeWHUzi3g@mail.gmail.com>

I'm looking for connectivity options in the Mexico City area. Initial
impressions suggest Mexico has a fairly closed market. That being
said:
Who offers good IP/BGP connectivity in and around Mexico City?Who
offers good Ethernet connectivity in and around Mexico City?Who offers
wave/fiber services in and around Mexico City.Where are the colo/IXPs
located?
Feedback on or off-list appreciated. I'm not looking for a salesman.
Thanks,
-- 
Tim:>


From joelja at bogus.com  Tue Dec  6 10:04:01 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Tue, 06 Dec 2011 08:04:01 -0800
Subject: 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <82zkf6t76h.fsf@mid.bfk.de>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <82zkf6t76h.fsf@mid.bfk.de>
Message-ID: <4EDE3CF1.2070005@bogus.com>

On 12/6/11 00:50 , Florian Weimer wrote:
> * Alex Le Heux:
> 
>> The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by
>> default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline
>> that this /16 should no longer be reserved as specialised address
>> space.
> 
> Would someone please clarify the impact?  Will it result in a blackhole,
> or will the entire announcement be suppressed?  I suspect the latter,
> given what we see and what Chris Adams has reported.

http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/routing-configuring-martian-addresses.html




From keegan.holley at sungard.com  Tue Dec  6 10:07:44 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Tue, 6 Dec 2011 11:07:44 -0500
Subject: Writable SNMP
Message-ID: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>

For a few years now I been wondering why more networks do not use writable
SNMP.  Most automation solutions actually script a login to the various
equipment.  This comes with extra code for different vendors, different
prompts and any quirk that the developer is aware of and constant patches
as new ones come up.  Writable SNMP seems like an easier way to deal with
scripted configuration changes as well as information gathering.
Admittedly, you will have to deal with proprietary mibs and reformat the
data once it's returned.  Most people consider it insecure, but in reality
it's no worse than any other management protocol.  Yes I know netconf is
better, but in most circles I'd have problems explaining what netconf is,
why it's better and that I'm not making it up.  So I'll take what I can get.

From jared at puck.nether.net  Tue Dec  6 10:16:02 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 6 Dec 2011 11:16:02 -0500
Subject: Writable SNMP
In-Reply-To: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
Message-ID: <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>


On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote:

> For a few years now I been wondering why more networks do not use writable
> SNMP.  Most automation solutions actually script a login to the various
> equipment.  This comes with extra code for different vendors, different
> prompts and any quirk that the developer is aware of and constant patches
> as new ones come up.  Writable SNMP seems like an easier way to deal with
> scripted configuration changes as well as information gathering.
> Admittedly, you will have to deal with proprietary mibs and reformat the
> data once it's returned.  Most people consider it insecure, but in reality
> it's no worse than any other management protocol.  Yes I know netconf is
> better, but in most circles I'd have problems explaining what netconf is,
> why it's better and that I'm not making it up.  So I'll take what I can get.

Some of the problems is the bulk nature of some config changes (or transactional
nature on those that support atomic operations) have been harder to automate.

Anyone that has spent any quantity of time with ASN.1 generally would agree.

I recall some bay networks gear you could only program with the proper OID
as the cli was basically a SNMP-SET operation on the device.

The errors/feedback tends to be very poor over SNMP as well as you may need
to walk/revisit a large number of elements to make things happen properly.

Have you had a good experience with using SNMP-Write?  I have not.

- Jared

From morrowc.lists at gmail.com  Tue Dec  6 10:28:04 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 6 Dec 2011 11:28:04 -0500
Subject: Writable SNMP
In-Reply-To: <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
Message-ID: <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>

On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch <jared at puck.nether.net> wrote:
>
> On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote:
>
>> For a few years now I been wondering why more networks do not use writable
>> SNMP. ?Most automation solutions actually script a login to the various
>> equipment. ?This comes with extra code for different vendors, different
>> prompts and any quirk that the developer is aware of and constant patches
>> as new ones come up. ?Writable SNMP seems like an easier way to deal with
>> scripted configuration changes as well as information gathering.
>> Admittedly, you will have to deal with proprietary mibs and reformat the
>> data once it's returned. ?Most people consider it insecure, but in reality
>> it's no worse than any other management protocol. ?Yes I know netconf is
>> better, but in most circles I'd have problems explaining what netconf is,
>> why it's better and that I'm not making it up. ?So I'll take what I can get.
>
> Some of the problems is the bulk nature of some config changes (or transactional
> nature on those that support atomic operations) have been harder to automate.
>
> Anyone that has spent any quantity of time with ASN.1 generally would agree.
>
> I recall some bay networks gear you could only program with the proper OID
> as the cli was basically a SNMP-SET operation on the device.

yea... same with cascade devices... icky things (both bay and cascade!)

> The errors/feedback tends to be very poor over SNMP as well as you may need
> to walk/revisit a large number of elements to make things happen properly.

fun story/fact, you can send an snmp write to the broadcast address of
a network of NT (at least, probably also post-nt versions of the OS)
machines, and set their default-ttl to some arbitrary number. "Your
network is too chatty... not anymore! now your internet is 5 hops
across!"

> Have you had a good experience with using SNMP-Write? ?I have not.

long ago, in a network far away (not on the interwebs) we used snmp
write to trigger a tftp config load. It worked nicely... I'm fairly
certain I'd not do this on an internet connected network today though.

Also, who tests snmp WRITE in their code? at scale? for daily
operations tasks? ... (didn't the snmp incident in 2002 teach us
something?)

-chris


From Valdis.Kletnieks at vt.edu  Tue Dec  6 10:48:06 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 06 Dec 2011 11:48:06 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: Your message of "Mon, 05 Dec 2011 22:14:48 PST."
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
Message-ID: <9523.1323190086@turing-police.cc.vt.edu>

On Mon, 05 Dec 2011 22:14:48 PST, "andrew.wallace" said:
> Using fruitful language and acting like a child isn't going to see you taken seriously.

No, he *does* want fruitful language - one that produces results.  I think you meant
some other word instead.

As far as "acting like a child", I'm reasonably sure that if CNet was doing the
same thing to the good name of your consulting company, you'd react similarly.

> ----- Forwarded message from Fyodor <fyodor at insecure.org>

On the other hand, just being Fyodor is sufficient to get him taken seriously.




-------------- 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/20111206/0caf1f37/attachment-0001.bin>

From keegan.holley at sungard.com  Tue Dec  6 10:49:05 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Tue, 6 Dec 2011 11:49:05 -0500
Subject: Writable SNMP
In-Reply-To: <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
Message-ID: <CABO8Q6TF9=okuKiyUvH9dZZBNPLjJFnzbXUP8VuU7WQL6EB4jA@mail.gmail.com>

2011/12/6 Christopher Morrow <morrowc.lists at gmail.com>

> On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch <jared at puck.nether.net>
> wrote:
> >
> > On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote:
> >
> >> For a few years now I been wondering why more networks do not use
> writable
> >> SNMP.  Most automation solutions actually script a login to the various
> >> equipment.  This comes with extra code for different vendors, different
> >> prompts and any quirk that the developer is aware of and constant
> patches
> >> as new ones come up.  Writable SNMP seems like an easier way to deal
> with
> >> scripted configuration changes as well as information gathering.
> >> Admittedly, you will have to deal with proprietary mibs and reformat the
> >> data once it's returned.  Most people consider it insecure, but in
> reality
> >> it's no worse than any other management protocol.  Yes I know netconf is
> >> better, but in most circles I'd have problems explaining what netconf
> is,
> >> why it's better and that I'm not making it up.  So I'll take what I can
> get.
> >
> > Some of the problems is the bulk nature of some config changes (or
> transactional
> > nature on those that support atomic operations) have been harder to
> automate.
> >
> > Anyone that has spent any quantity of time with ASN.1 generally would
> agree.
> >
> > I recall some bay networks gear you could only program with the proper
> OID
> > as the cli was basically a SNMP-SET operation on the device.
>
> yea... same with cascade devices... icky things (both bay and cascade!)
>
> > The errors/feedback tends to be very poor over SNMP as well as you may
> need
> > to walk/revisit a large number of elements to make things happen
> properly.
>
> fun story/fact, you can send an snmp write to the broadcast address of
> a network of NT (at least, probably also post-nt versions of the OS)
> machines, and set their default-ttl to some arbitrary number. "Your
> network is too chatty... not anymore! now your internet is 5 hops
> across!"
>

Let's leave the legacy boxes out of this.  Remember that SNMP bug that
could keel over a cisco router?  I forget the details other than the guy
who wrote c code at black hat to kill routers after cisco refused to patch.

>
> > Have you had a good experience with using SNMP-Write?  I have not.
>
> long ago, in a network far away (not on the interwebs) we used snmp
> write to trigger a tftp config load. It worked nicely... I'm fairly
> certain I'd not do this on an internet connected network today though.
>

I can see the other comments about interactive commands and bulk
read/writes, but what's the harm of doing it on internet connected boxes
vs. non-internet boxes.  Just about everyone uses snmp reads in the
interwebs and as such filters it at their edges and hopefully on each
platform.  You'd secure it the same way you'd secure readable SNMP I
assume.

>
> Also, who tests snmp WRITE in their code? at scale? for daily
> operations tasks?


lol, that could be a problem.


> ... (didn't the snmp incident in 2002 teach us
> something?)
>
> Please elaborate.

> -chris
>
>

From bkain1 at ford.com  Tue Dec  6 11:00:45 2011
From: bkain1 at ford.com (Kain, Rebecca (.))
Date: Tue, 6 Dec 2011 17:00:45 +0000
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <9523.1323190086@turing-police.cc.vt.edu>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
Message-ID: <7DB845D64966DC44A1CC592780539B4B028C43@naembx40.exchange.ford.com>

Not that anyone cares but personally, I'm happy fyodor posted this and I'm forwarding it to anyone that I think might use download.com.  I think it's crap anyone changes anyone's code like that
 

-----Original Message-----
From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
Sent: Tuesday, December 06, 2011 11:48 AM
To: andrew.wallace
Cc: fyodor at insecure.org; nanog at nanog.org
Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

On Mon, 05 Dec 2011 22:14:48 PST, "andrew.wallace" said:
> Using fruitful language and acting like a child isn't going to see you taken seriously.

No, he *does* want fruitful language - one that produces results.  I think you meant
some other word instead.

As far as "acting like a child", I'm reasonably sure that if CNet was doing the
same thing to the good name of your consulting company, you'd react similarly.

> ----- Forwarded message from Fyodor <fyodor at insecure.org>

On the other hand, just being Fyodor is sufficient to get him taken seriously.






From eric-list at truenet.com  Tue Dec  6 11:00:47 2011
From: eric-list at truenet.com (Eric Tykwinski)
Date: Tue, 6 Dec 2011 12:00:47 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmapwith
 malware!]
In-Reply-To: <9523.1323190086@turing-police.cc.vt.edu>
References: <20111205234419.GD1454@vacation.karoshi.com><1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
Message-ID: <018b01ccb438$99cd0420$cd670c60$@truenet.com>

Maybe it's just me, but I would think that simply getting them listed on
stopbadware.org and other similar sites would probably have much more of an
effect.
The bad publicity can cause them to change tactics, but it takes some time.
I've seen much quicker results from blacklisting on Google and other search
engines.

Sincerely,

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


-----Original Message-----
From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
Sent: Tuesday, December 06, 2011 11:48 AM
To: andrew.wallace
Cc: fyodor at insecure.org; nanog at nanog.org
Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling
Nmapwith malware!]

On Mon, 05 Dec 2011 22:14:48 PST, "andrew.wallace" said:
> Using fruitful language and acting like a child isn't going to see you
taken seriously.

No, he *does* want fruitful language - one that produces results.  I think
you meant some other word instead.

As far as "acting like a child", I'm reasonably sure that if CNet was doing
the same thing to the good name of your consulting company, you'd react
similarly.

> ----- Forwarded message from Fyodor <fyodor at insecure.org>

On the other hand, just being Fyodor is sufficient to get him taken
seriously.







From pixitha.kyle at gmail.com  Tue Dec  6 11:14:17 2011
From: pixitha.kyle at gmail.com (Kyle Duren)
Date: Tue, 6 Dec 2011 09:14:17 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmapwith
 malware!]
In-Reply-To: <018b01ccb438$99cd0420$cd670c60$@truenet.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <018b01ccb438$99cd0420$cd670c60$@truenet.com>
Message-ID: <CADehQgRY50ryn3t7Z8SF58g_7BrCHC1Q6rMcASbkWn2Hi0mCfA@mail.gmail.com>

http://krebsonsecurity.com/2011/12/download-com-bundling-toolbars-trojans/


Its already getting some press...

He could always send them a Cease and Desist letter like Wireshark had to
do....

-Kyle
On Tue, Dec 6, 2011 at 9:00 AM, Eric Tykwinski <eric-list at truenet.com>wrote:

> Maybe it's just me, but I would think that simply getting them listed on
> stopbadware.org and other similar sites would probably have much more of
> an
> effect.
> The bad publicity can cause them to change tactics, but it takes some time.
> I've seen much quicker results from blacklisting on Google and other search
> engines.
>
> Sincerely,
>
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
> F: 610-429-3222
>
>
> -----Original Message-----
> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> Sent: Tuesday, December 06, 2011 11:48 AM
> To: andrew.wallace
> Cc: fyodor at insecure.org; nanog at nanog.org
> Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling
> Nmapwith malware!]
>
> On Mon, 05 Dec 2011 22:14:48 PST, "andrew.wallace" said:
> > Using fruitful language and acting like a child isn't going to see you
> taken seriously.
>
> No, he *does* want fruitful language - one that produces results.  I think
> you meant some other word instead.
>
> As far as "acting like a child", I'm reasonably sure that if CNet was doing
> the same thing to the good name of your consulting company, you'd react
> similarly.
>
> > ----- Forwarded message from Fyodor <fyodor at insecure.org>
>
> On the other hand, just being Fyodor is sufficient to get him taken
> seriously.
>
>
>
>
>
>
>

From jared at puck.nether.net  Tue Dec  6 11:15:35 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 6 Dec 2011 12:15:35 -0500
Subject: Writable SNMP
In-Reply-To: <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
Message-ID: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>


On Dec 6, 2011, at 11:28 AM, Christopher Morrow wrote:

> long ago, in a network far away (not on the interwebs) we used snmp
> write to trigger a tftp config load. It worked nicely... I'm fairly
> certain I'd not do this on an internet connected network today though.

Many vendors have poor TFTP implementations, such that any additional
latency creates very slow transfer rates.  This is why things like the
RCPD were done, and others use FTP/HTTP even.  I am not sure if you can
tell it to trigger some protocol other than TFTP in IOS.

As someone who has moved large configs around in the past (1-16MB in cases)
transfer speeds do matter.

> Also, who tests snmp WRITE in their code? at scale? for daily
> operations tasks? ... (didn't the snmp incident in 2002 teach us
> something?)

This is also a whole other interesting problem.  Part of it is lack of
exposure to it.  Part of it is ease of operation.  Many people still
telnet over when they should use ssh.  (feedback is more immediate if
you are not in the VTY ACL for example).  People revert to what they
are comfortable with.  Some it's scripts, others its typing configure
or conf t and hitting ? a lot.

There's no reason one can't program a device with SNMP, the main issue IMHO
has always been what I dubbed "config drift".  You have your desired
configuration and variances that happen over time.  If you don't force
a 'wr mem' or similar event after you trigger a 'copy tftp run' operation,
you may have troubles that are not apparent if there is a power failure
or other lossage.  The boot-time parser doesn't interpret SNMP, it parses
text.  This and other reasons have made people fail-safe to using the language
most easily interpreted by the device.

- Jared

From william.allen.simpson at gmail.com  Tue Dec  6 11:34:31 2011
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Tue, 06 Dec 2011 12:34:31 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmapwith
 malware!]
In-Reply-To: <018b01ccb438$99cd0420$cd670c60$@truenet.com>
References: <20111205234419.GD1454@vacation.karoshi.com><1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <018b01ccb438$99cd0420$cd670c60$@truenet.com>
Message-ID: <4EDE5227.7030409@gmail.com>

On 12/6/11 12:00 PM, Eric Tykwinski wrote:
> Maybe it's just me, but I would think that simply getting them listed on
> stopbadware.org and other similar sites would probably have much more of an
> effect.
> The bad publicity can cause them to change tactics, but it takes some time.
> I've seen much quicker results from blacklisting on Google and other search
> engines.
>
I've reported it as a malware site via Firefox.  Have you?

But the whole site should be scanned for other/similar malware, and blocked
accordingly.  Probably a harder problem, as it gives different downloads
depending on browser and OS.


From streiner at cluebyfour.org  Tue Dec  6 11:35:35 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 6 Dec 2011 12:35:35 -0500 (EST)
Subject: Writable SNMP
In-Reply-To: <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
Message-ID: <Pine.LNX.4.64.1112061225380.20786@whammy.cluebyfour.org>

On Tue, 6 Dec 2011, Jared Mauch wrote:

> I recall some bay networks gear you could only program with the proper OID
> as the cli was basically a SNMP-SET operation on the device.

The mere mention of Bay Networks and Site Manager (read: Site Mangler or 
Site Damager) is enough to get my blood pressure up a few points, and I 
haven't touched that stuff since probably 1999 or 2000.  The CLI was quite 
horrible, and their somewhat IOS-like command shell (BCC) was not much 
better.

> Have you had a good experience with using SNMP-Write?  I have not.

The most I've done using SNMP SETs is backed up configurations from 
network devices at my old job.  That part worked (and works) very well, 
but I never tried pushing config changes out to devices that way.

jms


From dorian at blackrose.org  Tue Dec  6 11:39:34 2011
From: dorian at blackrose.org (Dorian Kim)
Date: Tue, 6 Dec 2011 12:39:34 -0500
Subject: Writable SNMP
In-Reply-To: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
Message-ID: <20111206173934.GK21378@blackrose.org>

On Tue, Dec 06, 2011 at 12:15:35PM -0500, Mauch, Jared wrote:
> > Also, who tests snmp WRITE in their code? at scale? for daily
> > operations tasks? ... (didn't the snmp incident in 2002 teach us
> > something?)
> 
> There's no reason one can't program a device with SNMP, the main issue IMHO

There is one good reason. Every vendor seem to assign a junior intern to
maintanining SNMP code, so you are interfacing with your router via a very 
suspect interface. 

-dorian


From surfer at mauigateway.com  Tue Dec  6 11:40:03 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 6 Dec 2011 09:40:03 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with
 malware!]
Message-ID: <20111206094003.2DB8579@resin04.mta.everyone.net>


-----Original Message-----
From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 

> ----- Forwarded message from Fyodor <fyodor at insecure.org>

On the other hand, just being Fyodor is sufficient to get him taken seriously.
----------------------------


------- bkain1 at ford.com wrote: -------
From: "Kain, Rebecca (.)" <bkain1 at ford.com>

Not that anyone cares but personally, I'm happy fyodor posted this and 
I'm forwarding it to anyone that I think might use download.com.  I 
think it's crap anyone changes anyone's code like that
---------------------------------------



I used to use download.com a lot.  I trusted them.  I told friends they 
were trustworthy.  What Valdis said.  That's all it took for me to stop 
using them and to tell everyone I know to stop.  Hope someone at 
download.com is listening.

scott











From smb at cs.columbia.edu  Tue Dec  6 12:09:57 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Tue, 6 Dec 2011 13:09:57 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmapwith
 malware!]
In-Reply-To: <4EDE5227.7030409@gmail.com>
References: <20111205234419.GD1454@vacation.karoshi.com><1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <018b01ccb438$99cd0420$cd670c60$@truenet.com> <4EDE5227.7030409@gmail.com>
Message-ID: <5FF36843-3075-4EFB-BA3F-621AA1B3E03F@cs.columbia.edu>


On Dec 6, 2011, at 12:34 31PM, William Allen Simpson wrote:

> On 12/6/11 12:00 PM, Eric Tykwinski wrote:
>> Maybe it's just me, but I would think that simply getting them listed on
>> stopbadware.org and other similar sites would probably have much more of an
>> effect.
>> The bad publicity can cause them to change tactics, but it takes some time.
>> I've seen much quicker results from blacklisting on Google and other search
>> engines.
>> 
> I've reported it as a malware site via Firefox.  Have you?
> 
> But the whole site should be scanned for other/similar malware, and blocked
> accordingly.  Probably a harder problem, as it gives different downloads
> depending on browser and OS.
> 
> 
Per the Krebs on Security link that Kyle just posted (and beat me to it),
the installer is already flagged as malware by a number of different scanners.


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From andrew.wallace at rocketmail.com  Tue Dec  6 12:30:20 2011
From: andrew.wallace at rocketmail.com (andrew.wallace)
Date: Tue, 6 Dec 2011 10:30:20 -0800 (PST)
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <9523.1323190086@turing-police.cc.vt.edu>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
Message-ID: <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>

On Tue, Dec 6, 2011 at 4:48 PM,? <Valdis.Kletnieks at vt.edu> wrote:
> On the other hand, just being Fyodor is sufficient to get him taken seriously.

It could be argued that Nmap is malware, and such software has already been called to be made illegal.

If I was Cnet, I would stop distributing his software altogether.

Link: http://nmap.org/book/legal-issues.html

Andrew

From ikiris at gmail.com  Tue Dec  6 12:42:48 2011
From: ikiris at gmail.com (Blake Dunlap)
Date: Tue, 6 Dec 2011 12:42:48 -0600
Subject: Writable SNMP
In-Reply-To: <Pine.LNX.4.64.1112061225380.20786@whammy.cluebyfour.org>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <Pine.LNX.4.64.1112061225380.20786@whammy.cluebyfour.org>
Message-ID: <CAJvB4tnfjQJBp4B4Z7VqLUYb02YmCppLvM+cdoQrHq9Y_DgWXg@mail.gmail.com>

Yes, Site Mangler. Do not stir that nest. Thar be dragons.

-Blake

On Tue, Dec 6, 2011 at 11:35, Justin M. Streiner <streiner at cluebyfour.org>wrote:

> On Tue, 6 Dec 2011, Jared Mauch wrote:
>
>  I recall some bay networks gear you could only program with the proper OID
>> as the cli was basically a SNMP-SET operation on the device.
>>
>
> The mere mention of Bay Networks and Site Manager (read: Site Mangler or
> Site Damager) is enough to get my blood pressure up a few points, and I
> haven't touched that stuff since probably 1999 or 2000.  The CLI was quite
> horrible, and their somewhat IOS-like command shell (BCC) was not much
> better.
>
>
>  Have you had a good experience with using SNMP-Write?  I have not.
>>
>
> The most I've done using SNMP SETs is backed up configurations from
> network devices at my old job.  That part worked (and works) very well, but
> I never tried pushing config changes out to devices that way.
>
> jms
>
>

From nathan at atlasnetworks.us  Tue Dec  6 12:54:34 2011
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Tue, 6 Dec 2011 18:54:34 +0000
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B619CD6@ex-mb-1.corp.atlasnetworks.us>

> It could be argued that Nmap is malware, and such software has already
> been called to be made illegal.
> 
> If I was Cnet, I would stop distributing his software altogether.
> 
> Link: http://nmap.org/book/legal-issues.html

It could.  But making such an argument calls the arguer's grasp of reality into question.  Nmap is a tool, like any other.  It has no more ethical value than a nail gun or a hammer.  In the hands of an engineer, it is a valuable addition to a toolkit.  In the hands of an attacker, it can become a weapon.

If it could be argued that Nmap is malware, then it could be argued that hammers are weapons; therefore, we should call on Home Depot to stop carrying these deadly instruments with all due alacrity - or at least have governments step in and create licensing programs for hand tools.

Nathan Eisenberg


From owen at delong.com  Tue Dec  6 12:50:40 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 6 Dec 2011 10:50:40 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
Message-ID: <58A8514A-94C8-48A2-A0EC-2A0AE4F0D4C7@delong.com>


On Dec 6, 2011, at 10:30 AM, andrew.wallace wrote:

> On Tue, Dec 6, 2011 at 4:48 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>> On the other hand, just being Fyodor is sufficient to get him taken seriously.
> 
> It could be argued that Nmap is malware, and such software has already been called to be made illegal.
> 
> If I was Cnet, I would stop distributing his software altogether.
> 
> Link: http://nmap.org/book/legal-issues.html
> 
> Andrew
> 

That's a stretch. Malware generally, IMHO, means software which does something other than what it claims to do.

I don't believe that nmap does anything other than what it claims. I understand you may not like the idea of having such a tool available to users of your network. Personally, I'd rather that the users had access to such a tool than live without it myself. Kind of a double-edged sword, I know, but, nmap is a tool. In and of itself, neither bad nor good. Malice is in the intent of the user.

This distinguishes it from malware in that with malware, malice is in the intent of the author and not the user. Malware, once installed, does what its author wants it to do regardless of the intent of the user.

Sure, you can do things with nmap that are at best antisocial and at worst potentially illegal.

I can do things with a Bowie Knife that are as well.

However, used properly in the right context, both can be very useful tools.

I don't think we should outlaw either one. Then again, I'm rather liberal in that regard. I believe that we should not ban something if it has both legitimate and nefarious uses, but, rather, should only ban those things which pose a public hazard and have no legitimate use.

I suspect that he would rather Cnet stop distributing his software altogether than do what they are doing.

I appreciate the warning and have stopped using CNET as a result.

Owen



From rps at maine.edu  Tue Dec  6 12:56:36 2011
From: rps at maine.edu (Ray Soucy)
Date: Tue, 6 Dec 2011 13:56:36 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
Message-ID: <CALFTrnMrGpp=Z9q+wbEnryXVWivRho1n6t7f=W82wKq24jzwsA@mail.gmail.com>

I'm pretty sure nmap is the exact opposite of Malware.

It's an essential information security tool.

Fyodor,

Reach out to the Free Software Foundation and EFF.  They may not be
able to help directly, but I'm sure that they could put you in touch
with some pro bono legal experts that could give you the right advice
on how to act.

As mentioned, both Lessig, and Eben Moglen, would be good starting points.

On Tue, Dec 6, 2011 at 1:30 PM, andrew.wallace
<andrew.wallace at rocketmail.com> wrote:
> On Tue, Dec 6, 2011 at 4:48 PM,? <Valdis.Kletnieks at vt.edu> wrote:
>> On the other hand, just being Fyodor is sufficient to get him taken seriously.
>
> It could be argued that Nmap is malware, and such software has already been called to be made illegal.
>
> If I was Cnet, I would stop distributing his software altogether.
>
> Link: http://nmap.org/book/legal-issues.html
>
> Andrew
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From bkain1 at ford.com  Tue Dec  6 12:57:34 2011
From: bkain1 at ford.com (Kain, Rebecca (.))
Date: Tue, 6 Dec 2011 18:57:34 +0000
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B619CD6@ex-mb-1.corp.atlasnetworks.us>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <8C26A4FDAE599041A13EB499117D3C286B619CD6@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <7DB845D64966DC44A1CC592780539B4B02910C@naembx40.exchange.ford.com>

Having seen the previous owner of my house's cabinet building skills, and living with them, I'm all for licensing! 

-----Original Message-----
From: Nathan Eisenberg [mailto:nathan at atlasnetworks.us] 
Sent: Tuesday, December 06, 2011 1:55 PM
To: nanog at nanog.org
Subject: RE: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

> It could be argued that Nmap is malware, and such software has already
> been called to be made illegal.
> 
> If I was Cnet, I would stop distributing his software altogether.
> 
> Link: http://nmap.org/book/legal-issues.html

It could.  But making such an argument calls the arguer's grasp of reality into question.  Nmap is a tool, like any other.  It has no more ethical value than a nail gun or a hammer.  In the hands of an engineer, it is a valuable addition to a toolkit.  In the hands of an attacker, it can become a weapon.

If it could be argued that Nmap is malware, then it could be argued that hammers are weapons; therefore, we should call on Home Depot to stop carrying these deadly instruments with all due alacrity - or at least have governments step in and create licensing programs for hand tools.

Nathan Eisenberg



From henry at AegisInfoSys.com  Tue Dec  6 13:05:48 2011
From: henry at AegisInfoSys.com (Henry Yen)
Date: Tue, 6 Dec 2011 14:05:48 -0500
Subject: New on RIPE Labs: The Curious Case of 128.0/16
In-Reply-To: <20111206153831.GA22818@hiwaay.net>
References: <4EDE2B7D.9050603@ripe.net> <20111206153831.GA22818@hiwaay.net>
Message-ID: <20111206190548.GJ29174@nntp.AegisInfoSys.com>

On Tue, Dec 06, 2011 at 09:38:31AM -0600, Chris Adams wrote:
> Using RIPE's traceroute web interface, I can see that Sprint is
> filtering 128.0.0.0/16:

> I believe that Sprint is using Cisco, not Juniper.  This is either a
> manual filter or there is another (unidentified) issue with some Cisco
> configurations.

I've been getting spam from NTT for several days in that range; a Sprint-based
traceroute:

   2  sl-gw28-nyc-15-1-3-28-ts0.sprintlink.net (160.81.237.61)  10.880 ms   10.604 ms   9.359 ms
   3  sl-crs1-nyc-0-6-3-0.sprintlink.net (144.232.3.188)  10.345 ms   10.559 ms
  11.802 ms
   4  144.232.4.87 (144.232.4.87)  9.178 ms   7.928 ms 144.232.4.91 (144.232.4.91)  9.304 ms
   5  xe-0-2-0-2.r06.nycmny01.us.bb.gin.ntt.net (129.250.8.73)  8.841 ms   9.977 ms   7.947 ms
   6  ae-2.r22.nycmny01.us.bb.gin.ntt.net (129.250.4.174)  11.497 ms   10.610 ms
   11.682 ms
   7  ae-4.r21.sttlwa01.us.bb.gin.ntt.net (129.250.2.51)  85.541 ms   86.744 ms
  84.994 ms
   8  ae-0.r20.sttlwa01.us.bb.gin.ntt.net (129.250.2.53)  88.498 ms   87.313 ms
  88.387 ms
   9  ae-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.3.53)  95.862 ms   96.692 ms
  96.558 ms
  10  ae-2.r20.mlpsca01.us.bb.gin.ntt.net (129.250.5.6)  97.193 ms   96.742 ms   97.046 ms
  11  * * *
  12  ae-0.r01.mlpsca01.us.wh.verio.net (129.250.26.170)  98.053 ms   97.402 ms
  95.332 ms
  13  ge-26.a0410i.mlpsca01.us.wh.verio.net (204.202.1.226)  99.151 ms   99.001 ms   96.926 ms
  14  ca1-lam00092.vwh.net (192.217.122.217)  95.274 ms   97.104 ms   96.247 ms
  15  arnmarkt.org (128.121.86.33)  90.872 ms   91.109 ms   91.995 ms

-- 
Henry Yen                                       Aegis Information Systems, Inc.
Senior Systems Programmer                       Hicksville, New York


From harbor235 at gmail.com  Tue Dec  6 13:11:49 2011
From: harbor235 at gmail.com (harbor235)
Date: Tue, 6 Dec 2011 14:11:49 -0500
Subject: vrf address familiy upgrade
Message-ID: <CAB_zYdL19f_aTeuM6b2Tm4LNqFrzefDpgfdfLZKsmXiV=BzC2w@mail.gmail.com>

I was wondering if anyone has had experience with the vrf cli upgrade
command that upgrades an existing V4 only VRf to a multi-protocol vrf?

command:

(config)# vrf upgrade-cli multi-af-mode ........


My issue is that it fails to upgrade the my, one of the pre-requisites is
that the
vrf must exist, it does??????


thanx as always,

Mike

From jsw at inconcepts.biz  Tue Dec  6 13:18:52 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Tue, 6 Dec 2011 14:18:52 -0500
Subject: Writable SNMP
In-Reply-To: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
Message-ID: <CAPWAtbJubOh2vszRuOro=aYUiJe1KKQopgO1HHHPXGzznZznNg@mail.gmail.com>

On Tue, Dec 6, 2011 at 11:07 AM, Keegan Holley
<keegan.holley at sungard.com> wrote:
> For a few years now I been wondering why more networks do not use writable
> SNMP. ?Most automation solutions actually script a login to the various

I've spent enough time writing code to deal with SNMP (our own stack,
not using Net-SNMP or friends) to have a more in-depth understanding
of SNMP's pitfalls than most people.  It is TERRIBLE and should be
totally gutted and replaced with something more sane, less likely to
have bugs, etc.  There is a good reason why many major bugs have
popped up over the years allowing devices to be crashed with crafted
SNMP packets -- it's honestly not that easy to get right, especially
if you really implement every possible encoding so some random
customer with a brain-damaged SNMP client stack won't come crying to
you that his client won't work.

Juniper does not support writing via SNMP.  I am glad.  Hopefully that
is the first step toward not supporting SNMP at all.

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


From jra at baylink.com  Tue Dec  6 13:31:58 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 6 Dec 2011 14:31:58 -0500 (EST)
Subject: get IP address on login
In-Reply-To: <Pine.LNX.4.64ras.1112060850360.26014@nimbus.anzio.com>
Message-ID: <8659180.1785.1323199917885.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Bob Rasmussen" <ras at anzio.com>

> > >On my OSR5 test system, I see SSH_CLIENT and SSH_CONNECTION set in
> > >the environment upon login. Does that help?

> These are set by the SSH daemon, only if you're running an SSH
> connection. If you're not, you should be :-)

Well, on a disconnected internal system, telnet's probably ok; there's a
way to get it in telnet as well, but you have to do some guessing.

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 jhoppes at cfunet.net  Tue Dec  6 13:52:20 2011
From: jhoppes at cfunet.net (Josh V. Hoppes)
Date: Tue, 6 Dec 2011 19:52:20 +0000
Subject: GPON Vendors
Message-ID: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>

Hello NANOG,

Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola.  We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies.

Josh Hoppes
Network Engineer
Cedar Falls Utilities




From jethro.binks at strath.ac.uk  Tue Dec  6 13:56:38 2011
From: jethro.binks at strath.ac.uk (Jethro R Binks)
Date: Tue, 6 Dec 2011 19:56:38 +0000 (GMT)
Subject: Writable SNMP
In-Reply-To: <CAPWAtbJubOh2vszRuOro=aYUiJe1KKQopgO1HHHPXGzznZznNg@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CAPWAtbJubOh2vszRuOro=aYUiJe1KKQopgO1HHHPXGzznZznNg@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1112061949100.89376@qrswnz.pp.fgengu.np.hx>

On Tue, 6 Dec 2011, Jeff Wheeler wrote:

> On Tue, Dec 6, 2011 at 11:07 AM, Keegan Holley
> <keegan.holley at sungard.com> wrote:
> > For a few years now I been wondering why more networks do not use writable
> > SNMP. ?Most automation solutions actually script a login to the various
> 
...
> Juniper does not support writing via SNMP.  I am glad.  Hopefully that
> is the first step toward not supporting SNMP at all.

So what are the alternatives these days then for automation or batch 
operations?

clogin etc from shrubbery's rancid?

Net::Appliance::Session

... ?


.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.

From morrowc.lists at gmail.com  Tue Dec  6 13:57:54 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 6 Dec 2011 14:57:54 -0500
Subject: Writable SNMP
In-Reply-To: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
Message-ID: <CAL9jLabyFBjukeZ9pqopTiDxj=zmSrWnPrvjzcuE+qAycTPFHg@mail.gmail.com>

On Tue, Dec 6, 2011 at 12:15 PM, Jared Mauch <jared at puck.nether.net> wrote:
>
> On Dec 6, 2011, at 11:28 AM, Christopher Morrow wrote:
>
>> long ago, in a network far away (not on the interwebs) we used snmp
>> write to trigger a tftp config load. It worked nicely... I'm fairly
>> certain I'd not do this on an internet connected network today though.
>
> Many vendors have poor TFTP implementations, such that any additional
> latency creates very slow transfer rates. ?This is why things like the
> RCPD were done, and others use FTP/HTTP even. ?I am not sure if you can
> tell it to trigger some protocol other than TFTP in IOS.

agreed, I did say 'long time ago' :) (like before 2000 long time ago)
I get the impression we could have said copy http:// instead of tftp
though. (if it were supported at the time, http I mean)

> As someone who has moved large configs around in the past (1-16MB in cases)
> transfer speeds do matter.

agreed

>> Also, who tests snmp WRITE in their code? at scale? for daily
>> operations tasks? ... (didn't the snmp incident in 2002 teach us
>> something?)
>
> This is also a whole other interesting problem. ?Part of it is lack of
> exposure to it. ?Part of it is ease of operation. ?Many people still
> telnet over when they should use ssh. ?(feedback is more immediate if
> you are not in the VTY ACL for example). ?People revert to what they
> are comfortable with. ?Some it's scripts, others its typing configure
> or conf t and hitting ? a lot.
>
> There's no reason one can't program a device with SNMP, the main issue IMHO
> has always been what I dubbed "config drift". ?You have your desired
> configuration and variances that happen over time. ?If you don't force
> a 'wr mem' or similar event after you trigger a 'copy tftp run' operation,
> you may have troubles that are not apparent if there is a power failure
> or other lossage. ?The boot-time parser doesn't interpret SNMP, it parses
> text. ?This and other reasons have made people fail-safe to using the language
> most easily interpreted by the device.

Yup, I think the OP was maybe getting at:
  "Why can't I snmp configure my cisco/juniper/alteon device?"

I took that to mean (probably naively?) that they also would validate
configs and update drift out of the configuration. You CAN force a 'wr
mem' via snmp as well, of course (in cisco world).


From morrowc.lists at gmail.com  Tue Dec  6 14:00:27 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 6 Dec 2011 15:00:27 -0500
Subject: Writable SNMP
In-Reply-To: <CABO8Q6TF9=okuKiyUvH9dZZBNPLjJFnzbXUP8VuU7WQL6EB4jA@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <CABO8Q6TF9=okuKiyUvH9dZZBNPLjJFnzbXUP8VuU7WQL6EB4jA@mail.gmail.com>
Message-ID: <CAL9jLaa8MMeooBPpQjKSna18-nLipzPf3fvbsi0PLEo=9peYWA@mail.gmail.com>

On Tue, Dec 6, 2011 at 11:49 AM, Keegan Holley
<keegan.holley at sungard.com> wrote:
> 2011/12/6 Christopher Morrow <morrowc.lists at gmail.com>
>>
>> On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch <jared at puck.nether.net>
>> wrote:
>> >
>> > On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote:
>> >
>> >> For a few years now I been wondering why more networks do not use
>> >> writable
>> >> SNMP. ?Most automation solutions actually script a login to the various
>> >> equipment. ?This comes with extra code for different vendors, different
>> >> prompts and any quirk that the developer is aware of and constant
>> >> patches
>> >> as new ones come up. ?Writable SNMP seems like an easier way to deal
>> >> with
>> >> scripted configuration changes as well as information gathering.
>> >> Admittedly, you will have to deal with proprietary mibs and reformat
>> >> the
>> >> data once it's returned. ?Most people consider it insecure, but in
>> >> reality
>> >> it's no worse than any other management protocol. ?Yes I know netconf
>> >> is
>> >> better, but in most circles I'd have problems explaining what netconf
>> >> is,
>> >> why it's better and that I'm not making it up. ?So I'll take what I can
>> >> get.
>> >
>> > Some of the problems is the bulk nature of some config changes (or
>> > transactional
>> > nature on those that support atomic operations) have been harder to
>> > automate.
>> >
>> > Anyone that has spent any quantity of time with ASN.1 generally would
>> > agree.
>> >
>> > I recall some bay networks gear you could only program with the proper
>> > OID
>> > as the cli was basically a SNMP-SET operation on the device.
>>
>> yea... same with cascade devices... icky things (both bay and cascade!)
>>
>> > The errors/feedback tends to be very poor over SNMP as well as you may
>> > need
>> > to walk/revisit a large number of elements to make things happen
>> > properly.
>>
>> fun story/fact, you can send an snmp write to the broadcast address of
>> a network of NT (at least, probably also post-nt versions of the OS)
>> machines, and set their default-ttl to some arbitrary number. "Your
>> network is too chatty... not anymore! now your internet is 5 hops
>> across!"
>
>
> Let's leave the legacy boxes out of this.? Remember that SNMP bug that could
> keel over a cisco router?? I forget the details other than the guy who wrote
> c code at black hat to kill routers after cisco refused to patch.
>>
>>
>> > Have you had a good experience with using SNMP-Write? ?I have not.
>>
>> long ago, in a network far away (not on the interwebs) we used snmp
>> write to trigger a tftp config load. It worked nicely... I'm fairly
>> certain I'd not do this on an internet connected network today though.
>
>
> I can see the other comments about interactive commands and bulk
> read/writes, but what's the harm of doing it on internet connected boxes vs.
> non-internet boxes.? Just about everyone uses snmp reads in the interwebs

I think the general feeling is that snmp is udp so it's spoofable and
your perimeter acls will never be 100% (or rather, are you willing to
risk them not being 100%?)

> and as such filters it at their edges and hopefully on each platform.? You'd
> secure it the same way you'd secure readable SNMP I assume.

read is 'painful', write can be downright deadly (to your SLAs).

>>
>> Also, who tests snmp WRITE in their code? at scale? for daily
>> operations tasks?
>
>
> lol, that could be a problem.

yea, I bet the number of people that test, at scale/operations-pace,
snmp WRITE is countable on a single hand.

>>
>> ... (didn't the snmp incident in 2002 teach us
>> something?)
>>
> Please elaborate.

<http://www.cisco.com/warp/public/707/cisco-sa-20010227-ios-snmp-ilmi.shtml>

oh, 2001... memory lag :(


From morrowc.lists at gmail.com  Tue Dec  6 14:01:26 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 6 Dec 2011 15:01:26 -0500
Subject: Writable SNMP
In-Reply-To: <20111206173934.GK21378@blackrose.org>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
 <20111206173934.GK21378@blackrose.org>
Message-ID: <CAL9jLaaE=cDxHPHFFCZgHqh9EOzz+qAkvD+S4uJVh_z1yoWLAA@mail.gmail.com>

On Tue, Dec 6, 2011 at 12:39 PM, Dorian Kim <dorian at blackrose.org> wrote:
> On Tue, Dec 06, 2011 at 12:15:35PM -0500, Mauch, Jared wrote:
>> > Also, who tests snmp WRITE in their code? at scale? for daily
>> > operations tasks? ... (didn't the snmp incident in 2002 teach us
>> > something?)
>>
>> There's no reason one can't program a device with SNMP, the main issue IMHO
>
> There is one good reason. Every vendor seem to assign a junior intern to
> maintanining SNMP code, so you are interfacing with your router via a very
> suspect interface.

this is exactly my 'testing' commment... and you thought bgp bugs were
painful :)


From morrowc.lists at gmail.com  Tue Dec  6 14:04:19 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 6 Dec 2011 15:04:19 -0500
Subject: Writable SNMP
In-Reply-To: <alpine.BSF.2.00.1112061949100.89376@qrswnz.pp.fgengu.np.hx>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CAPWAtbJubOh2vszRuOro=aYUiJe1KKQopgO1HHHPXGzznZznNg@mail.gmail.com>
 <alpine.BSF.2.00.1112061949100.89376@qrswnz.pp.fgengu.np.hx>
Message-ID: <CAL9jLaaTGHLnPmunKEWVJSNtuzW_cMDQvTfZnmBtE2REPepi=w@mail.gmail.com>

On Tue, Dec 6, 2011 at 2:56 PM, Jethro R Binks
<jethro.binks at strath.ac.uk> wrote:

> So what are the alternatives these days then for automation or batch
> operations?
>
> clogin etc from shrubbery's rancid?
>
> Net::Appliance::Session

netconf!


From bicknell at ufp.org  Tue Dec  6 14:13:38 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 6 Dec 2011 12:13:38 -0800
Subject: Writable SNMP
In-Reply-To: <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
Message-ID: <20111206201338.GA47906@ussenterprise.ufp.org>

In a message written on Tue, Dec 06, 2011 at 11:16:02AM -0500, Jared Mauch wrote:
> Anyone that has spent any quantity of time with ASN.1 generally would agree.

SNMP has two fatal flaws for large scale write based configuration.

ASN.1 was basically obsolete before it was written.  It was designed
to be a compact data transfer format in the days of 56k lines, and
is nothing but annoying in practice.  Hard to write, hard to debug,
hard to understand to save a little bandwidth which no longer
matters.

(Note, there is apparently an XML version of ASN.1 which may or may
not make things better, but I have never seen a single bit of gear
anywhere that implemented it.)

But then on top of ASN.1, the transaction model is all wrong.  No
way to group writes together (e.g. commit a series of changes at
once).  One RTT incurred for each write/read-back (for verification,
since it's UDP).  If you try and configure a device with SNMP over
a 500ms link it might take longer than the lifespan of the gear!  :)

Jared also makes a good point about the device not reading SNMP on
boot, it reads a text file, and being able to alter that directly
makes more sense.

Lastly, let's not forget that at most vendors SNMP seems to be a
low priority item.  How many years was it after we had IPv6 BGP
before there was an IPv6 BGP MIB actually implemented?

I actually would submit SNMP was never the right tool for the job,
just the tool we had.  Even today where it's most popular use is
to poll interfaces for statistics it would be easier on the device,
programmer, and operator to make one tcp connection, send a list
of things to poll, and get back a blob of text.  I hesitate to say
XML + Restful, becuse I think it need not be that specific solution,
but that is a solution that meets the criteria.  The only thing SNMP has
going for it at this point in time is inertia.

-- 
       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/20111206/ed61de54/attachment.bin>

From thegameiam at yahoo.com  Tue Dec  6 14:28:36 2011
From: thegameiam at yahoo.com (David Barak)
Date: Tue, 6 Dec 2011 12:28:36 -0800 (PST)
Subject: Writable SNMP
In-Reply-To: <CAPWAtbJubOh2vszRuOro=aYUiJe1KKQopgO1HHHPXGzznZznNg@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CAPWAtbJubOh2vszRuOro=aYUiJe1KKQopgO1HHHPXGzznZznNg@mail.gmail.com>
Message-ID: <1323203316.14305.YahooMailNeo@web31806.mail.mud.yahoo.com>

From: Jeff Wheeler <jsw at inconcepts.biz>

>Juniper does not support writing via SNMP.? I am glad.? Hopefully that
>is the first step toward not supporting SNMP at all.

If I recall correctly, wasn't the old FORE CLI implemented via localhost SNMP? ?I liked using them, but that's a special case...

David Barak
Need Geek Rock? Try The Franchise:?
http://www.listentothefranchise.com

From jared at puck.nether.net  Tue Dec  6 14:38:13 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 6 Dec 2011 14:38:13 -0600
Subject: Writable SNMP
In-Reply-To: <20111206201338.GA47906@ussenterprise.ufp.org>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <20111206201338.GA47906@ussenterprise.ufp.org>
Message-ID: <0A93187E-1D91-4A16-AE59-AA156A56C91C@puck.nether.net>

What SNMP does have for it is it is lightweight (to some extent) vs XML that can get quite bulky, and certainly is the case when trying to do many interfaces at once. 

I have seen better precision with snmp vs cli interaction/tcp based interaction. 

snmpbulkwalk has been my cruel mistress for several years... But does provide the detail/accuracy most days. 

Also keep in mind most hardware only pulls or pushes counters every 5s anyways...

Jared Mauch

On Dec 6, 2011, at 2:13 PM, Leo Bicknell <bicknell at ufp.org> wrote:

> 
> I actually would submit SNMP was never the right tool for the job,
> just the tool we had.  Even today where it's most popular use is
> to poll interfaces for statistics it would be easier on the device,
> programmer, and operator to make one tcp connection, send a list
> of things to poll, and get back a blob of text.  I hesitate to say
> XML + Restful, becuse I think it need not be that specific solution,
> but that is a solution that meets the criteria.  The only thing SNMP has
> going for it at this point in time is inertia.


From bstengel at kinber.org  Tue Dec  6 15:01:21 2011
From: bstengel at kinber.org (Brian Stengel)
Date: Tue, 6 Dec 2011 16:01:21 -0500
Subject: CMDB on the cheap...
Message-ID: <CABLLS=P-CwaOy-t8hQ7vHhh5T_aUW8P0-MU+7fO9z3T6Yv563g@mail.gmail.com>

Any recommendations for CMDB software on the cheap?  Building out nodes at
a few commercial co-los and a number of non-commercial (member) spaces.

thanks,
brian

-- 
Brian Stengel
KINBER Director of Operations
bstengel at kinber.org
M: 412.398.2333
GV: 412.254.3481
Skype: brian_stengel

KINBER - Keystone Initiative for Network Based Education and Research -
www.kinber.org
PennREN - Pennsylvania's Research and Education Network

From surfer at mauigateway.com  Tue Dec  6 15:05:39 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 6 Dec 2011 13:05:39 -0800
Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco
Message-ID: <20111206130539.2DBEED9@resin04.mta.everyone.net>



Did Jeff's suggestion work?

: interface POS0/0/0
: frame-relay intf-type dce

If so, please let the list know, so when someone comes 
across this thread while searching for the fix they can 
figure it out without having to email the list.  If it 
didn't help contact me off-line and I will be happy to 
troubleshoot it with you.

scott





________________________________________
From: Righa Shake [righa.shake at gmail.com]
Sent: Saturday, November 19, 2011 11:11 AM
To: afnog at afnog.org
Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco

Hi,

Am having a problem that is buffling.

I recently changed a POS link encapsulation from PPP to Frame-relay.
Since that time the POS interface keeps resetting from time to time.

On my BGP session am receiving cease notifications from my upstream
provider.

The setup is such that we have a cisco on one end and a Juniper on the
other.

interface POS0/0/0
 mtu 4474
 no ip address
 no ip unreachables
 encapsulation frame-relay
 logging event link-status
 crc 32
 pos scramble-atm
 frame-relay lmi-type ansi
end

ROUTERshow run int pos0/0/0.101
Building configuration...


!
interface POS0/0/0.101 point-to-point
ip address X.X.X.X 255.255.255.252
frame-relay interface-dlci 101
end

ROUTER#show int pos0/0/0
POS0/0/0 is up, line protocol is up
  Hardware is SPA-2XOC12-POS
  MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 6/255, rxload 38/255
  Encapsulation FRAME-RELAY, crc 32, loopback not set
  Keepalive set (10 sec)
  Scramble enabled
  LMI enq sent  81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE  segmentation
inactive
  FR SVC disabled, LAPF state down
  Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts
0
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 1w2d
  Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 94336000 bits/sec, 13151 packets/sec
  5 minute output rate 16470000 bits/sec, 7049 packets/sec
     12211574207 packets input, 10967607038364 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     6970870 runts, 2179 giants, 0 throttles
              0 parity
     892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored,
3335463 abort
     6379191154 packets output, 1614018181446 bytes, 0 underruns
     0 output errors, 0 applique, 4 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions


Any assistance on this will be greatly appreciated.






--- jsaxe at briworks.com wrote:

From: Jeff Saxe <jsaxe at briworks.com>
 
I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that your router was an "end user" device and its directly-connected partner device was not your other router, which you control, but the frame carrier's frame-relay switch. Your router was a DTE device, and their switch, which was in a more "important" position in control of the frame-relay NBMA cloud, was the DCE device. Your router then slaved to the frame switch via LMI signaling, so that the upstream switch instructed you which DLCIs existed and were up at the moment.

So if you connect up two routers with frame-relay encap and each thinks it is the DTE, and neither one is taking the role of the frame switch, then when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes go by and they don't hear the responses to their LMI enquiries, they will bring all the DLCI's down. I thought they would then stay down forever, i.e., not flap, but maybe you are shutting / no shutting the POS circuit to try again. Anyway, I believe the very simple fix is

interface POS0/0/0
frame-relay intf-type dce

So this will turn your Cisco side of the circuit into "DCE" mode, and if the Juniper side stays in "DTE" mode (the default, so probably not listed in the config), then the LMI should start behaving between the two. And yes, as Jay Hennigan suggested, you might need to use "encap frame-relay ietf" to be compatible with non-Cisco gear, or you might need to adjust the frame-relay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DLCI 1023, whatever. I think you'll need to adjust the two ends until you see LMI enquiries both sent and received; right now the "show interface" from the Cisco side shows it has not received any LMI enq yet.


Good luck, and I hope it's that simple.   :-)


From swm at emanon.com  Tue Dec  6 15:14:32 2011
From: swm at emanon.com (Scott Morris)
Date: Tue, 06 Dec 2011 16:14:32 -0500
Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco
In-Reply-To: <20111206130539.2DBEED9@resin04.mta.everyone.net>
References: <20111206130539.2DBEED9@resin04.mta.everyone.net>
Message-ID: <4EDE85B8.9080801@emanon.com>


From dholmes at mwdh2o.com  Tue Dec  6 15:16:00 2011
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Tue, 6 Dec 2011 13:16:00 -0800
Subject: Internet Edge and Defense in Depth
Message-ID: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>

Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device?

Regards,

David



  ________________________________
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 george.herbert at gmail.com  Tue Dec  6 15:16:32 2011
From: george.herbert at gmail.com (George Herbert)
Date: Tue, 6 Dec 2011 13:16:32 -0800
Subject: CMDB on the cheap...
In-Reply-To: <CABLLS=P-CwaOy-t8hQ7vHhh5T_aUW8P0-MU+7fO9z3T6Yv563g@mail.gmail.com>
References: <CABLLS=P-CwaOy-t8hQ7vHhh5T_aUW8P0-MU+7fO9z3T6Yv563g@mail.gmail.com>
Message-ID: <CAK__KzuYOt9QSRXgi7oRmUhyBonn5t8j5qymKheREgZkvfsvXQ@mail.gmail.com>

Everyone I know has either paid through the nose or written one from
scratch.  No good open source projects that worked out.

Most people couldn't build well from scratch.  I have been a couple of
places that did, it was man-year of senior grade guy effort range.



On Tue, Dec 6, 2011 at 1:01 PM, Brian Stengel <bstengel at kinber.org> wrote:
> Any recommendations for CMDB software on the cheap? ?Building out nodes at
> a few commercial co-los and a number of non-commercial (member) spaces.
>
> thanks,
> brian
>
> --
> Brian Stengel
> KINBER Director of Operations
> bstengel at kinber.org
> M: 412.398.2333
> GV: 412.254.3481
> Skype: brian_stengel
>
> KINBER - Keystone Initiative for Network Based Education and Research -
> www.kinber.org
> PennREN - Pennsylvania's Research and Education Network



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


From swm at emanon.com  Tue Dec  6 15:17:44 2011
From: swm at emanon.com (Scott Morris)
Date: Tue, 06 Dec 2011 16:17:44 -0500
Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco
In-Reply-To: <20111206130539.2DBEED9@resin04.mta.everyone.net>
References: <20111206130539.2DBEED9@resin04.mta.everyone.net>
Message-ID: <4EDE8678.4070507@emanon.com>

The mismatch problem of DCE/DTE should definitely indicate that your
PVCs aren't up.  But that shouldn't result in the high quantity of CRC
errors in the interface counters.  That should just result in your LMI
enquiry count increasing with LMI response sitting at zero.

I have to say I've never tried running frame-relay on a SONET
interface.  And if you're only using a single PVC there, I'd certainly
love to know WHY you're doing that!  :)

But setting one side to DCE so that it'll respond to LMI will certainly
make the frame-relay (L2) portion of things operate properly.  But if
you have something else occurring causing the CRCs along the way, then
that's not really going to help at all!

Did anything else coincide with you changing the encapsulation?

Scott



On 12/6/11 4:05 PM, Scott Weeks wrote:
> Did Jeff's suggestion work?
>
> : interface POS0/0/0
> : frame-relay intf-type dce
>
> If so, please let the list know, so when someone comes 
> across this thread while searching for the fix they can 
> figure it out without having to email the list.  If it 
> didn't help contact me off-line and I will be happy to 
> troubleshoot it with you.
>
> scott
>
>
>
>
>
> ________________________________________
> From: Righa Shake [righa.shake at gmail.com]
> Sent: Saturday, November 19, 2011 11:11 AM
> To: afnog at afnog.org
> Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco
>
> Hi,
>
> Am having a problem that is buffling.
>
> I recently changed a POS link encapsulation from PPP to Frame-relay.
> Since that time the POS interface keeps resetting from time to time.
>
> On my BGP session am receiving cease notifications from my upstream
> provider.
>
> The setup is such that we have a cisco on one end and a Juniper on the
> other.
>
> interface POS0/0/0
>  mtu 4474
>  no ip address
>  no ip unreachables
>  encapsulation frame-relay
>  logging event link-status
>  crc 32
>  pos scramble-atm
>  frame-relay lmi-type ansi
> end
>
> ROUTERshow run int pos0/0/0.101
> Building configuration...
>
>
> !
> interface POS0/0/0.101 point-to-point
> ip address X.X.X.X 255.255.255.252
> frame-relay interface-dlci 101
> end
>
> ROUTER#show int pos0/0/0
> POS0/0/0 is up, line protocol is up
>   Hardware is SPA-2XOC12-POS
>   MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec,
>      reliability 255/255, txload 6/255, rxload 38/255
>   Encapsulation FRAME-RELAY, crc 32, loopback not set
>   Keepalive set (10 sec)
>   Scramble enabled
>   LMI enq sent  81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up
>   LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
>   LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE  segmentation
> inactive
>   FR SVC disabled, LAPF state down
>   Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts
> 0
>   Last input 00:00:00, output 00:00:00, output hang never
>   Last clearing of "show interface" counters 1w2d
>   Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   5 minute input rate 94336000 bits/sec, 13151 packets/sec
>   5 minute output rate 16470000 bits/sec, 7049 packets/sec
>      12211574207 packets input, 10967607038364 bytes, 0 no buffer
>      Received 0 broadcasts (0 IP multicasts)
>      6970870 runts, 2179 giants, 0 throttles
>               0 parity
>      892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored,
> 3335463 abort
>      6379191154 packets output, 1614018181446 bytes, 0 underruns
>      0 output errors, 0 applique, 4 interface resets
>      0 unknown protocol drops
>      0 output buffer failures, 0 output buffers swapped out
>      0 carrier transitions
>
>
> Any assistance on this will be greatly appreciated.
>
>
>
>
>
>
> --- jsaxe at briworks.com wrote:
>
> From: Jeff Saxe <jsaxe at briworks.com>
>  
> I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that your router was an "end user" device and its directly-connected partner device was not your other router, which you control, but the frame carrier's frame-relay switch. Your router was a DTE device, and their switch, which was in a more "important" position in control of the frame-relay NBMA cloud, was the DCE device. Your router then slaved to the frame switch via LMI signaling, so that the upstream switch instructed you which DLCIs existed and were up at the moment.
>
> So if you connect up two routers with frame-relay encap and each thinks it is the DTE, and neither one is taking the role of the frame switch, then when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes go by and they don't hear the responses to their LMI enquiries, they will bring all the DLCI's down. I thought they would then stay down forever, i.e., not flap, but maybe you are shutting / no shutting the POS circuit to try again. Anyway, I believe the very simple fix is
>
> interface POS0/0/0
> frame-relay intf-type dce
>
> So this will turn your Cisco side of the circuit into "DCE" mode, and if the Juniper side stays in "DTE" mode (the default, so probably not listed in the config), then the LMI should start behaving between the two. And yes, as Jay Hennigan suggested, you might need to use "encap frame-relay ietf" to be compatible with non-Cisco gear, or you might need to adjust the frame-relay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DLCI 1023, whatever. I think you'll need to adjust the two ends until you see LMI enquiries both sent and received; right now the "show interface" from the Cisco side shows it has not received any LMI enq yet.
>
>
> Good luck, and I hope it's that simple.   :-)
>
>
>



From bhmccie at gmail.com  Tue Dec  6 15:25:38 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Tue, 06 Dec 2011 15:25:38 -0600
Subject: Internet Edge and Defense in Depth
In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
Message-ID: <4EDE8852.30506@gmail.com>

I personally have not seen it done in large environments. Hardware isn't 
there yet. I've seen it done in small business environments. Not a fan 
of the idea.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 12/06/2011 03:16 PM, Holmes,David A wrote:
> Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device?
>
> Regards,
>
> David
>
>
>
>    ________________________________
> 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 jim at miltonsecurity.com  Tue Dec  6 15:32:04 2011
From: jim at miltonsecurity.com (JAMES MCMURRY)
Date: Tue, 6 Dec 2011 13:32:04 -0800
Subject: Internet Edge and Defense in Depth
In-Reply-To: <4EDE8852.30506@gmail.com>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
 <4EDE8852.30506@gmail.com>
Message-ID: <4C0D4D97-780B-4F04-A8EE-E4FD204B03D6@miltonsecurity.com>

I have seen at quite a few of our customers locations, starting out with a lofty goal of putting everything in a single box (UTM) and turning every single option on.

In ~ 30% of the firms who do so it works out ok (not great, but it works).  In the majority, the customer winds up turning features off one by one, and moving those to another system.


Jim


On Dec 6, 2011, at 1:25 PM, -Hammer- wrote:

> I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea.
> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> 
> 
> On 12/06/2011 03:16 PM, Holmes,David A wrote:
>> Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device?
>> 
>> Regards,
>> 
>> David
>> 
>> 
>> 
>>   ________________________________
>> 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 david at davidswafford.com  Tue Dec  6 15:37:24 2011
From: david at davidswafford.com (David Swafford)
Date: Tue, 6 Dec 2011 16:37:24 -0500
Subject: Internet Edge and Defense in Depth
In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
Message-ID: <CAA8=vb5PzUz=CxhMxE=B0fxXGVe1oNjRK6+4qpWqjpQvhmVRHw@mail.gmail.com>

They're proposing that so you buy their device, not renew support on
your existing ones :-D

Personally we just went through this w/ Palo Alto Networks.  We bought
a handful of their all-in-one firewalls simply for their web-filtering
functionality (replacing Bluecoats).  They pitched repetitively that
we should replace all of our firewalls with just their box and
collapse it.

I must say, from a support perspective, the concept of "this box does
web filtering, and that box handles the firewall of our public facing
servers" is worth it's weight in gold.  Web filtering alone can get
stupid complex if you let it.   Do you really want to troubleshoot an
inbound web server issue while trying to sort through rules like "Jeff
is allowed to get to Facebook, Marketing can get to Twitter, HR can
see everything, oh wait here's the DMZ rules....".

Boxes are cheap in an environment where staffing is lean.  In SoHo,
and smaller SMBs I could see it being different... we're on the larger
of the "medium business" / small Enterprise side of the fence.

David.


On Tue, Dec 6, 2011 at 4:16 PM, Holmes,David A <dholmes at mwdh2o.com> wrote:
> Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device?
>
> Regards,
>
> David
>
>
>
> ?________________________________
> 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 techgrrl at gmail.com  Tue Dec  6 15:37:53 2011
From: techgrrl at gmail.com (Elle Plato)
Date: Tue, 6 Dec 2011 13:37:53 -0800
Subject: CMDB on the cheap...
In-Reply-To: <CAK__KzuYOt9QSRXgi7oRmUhyBonn5t8j5qymKheREgZkvfsvXQ@mail.gmail.com>
References: <CABLLS=P-CwaOy-t8hQ7vHhh5T_aUW8P0-MU+7fO9z3T6Yv563g@mail.gmail.com>
 <CAK__KzuYOt9QSRXgi7oRmUhyBonn5t8j5qymKheREgZkvfsvXQ@mail.gmail.com>
Message-ID: <CAO771F+G37Sm6-p_p=NZvtQ=mMZhwMvEamE_KfGUniyke3P==Q@mail.gmail.com>

On Tue, Dec 6, 2011 at 1:16 PM, George Herbert <george.herbert at gmail.com> wrote:
> Everyone I know has either paid through the nose or written one from
> scratch. ?No good open source projects that worked out.
>
> Most people couldn't build well from scratch. ?I have been a couple of
> places that did, it was man-year of senior grade guy effort range.
>

And 10-20% (or more) of an FTE in support.  New devices need to be
onboarded, new OS versions make
subtle changes in the code, etc.  The upside is that they can be
powerful tools to automate mass
config changes, and along with config parsing code, they can be
powerful tools to standardize networks.

Elle Janet Plato


From jof at thejof.com  Tue Dec  6 15:44:05 2011
From: jof at thejof.com (Jonathan Lassoff)
Date: Tue, 6 Dec 2011 13:44:05 -0800
Subject: Internet Edge and Defense in Depth
In-Reply-To: <CAA8=vb5PzUz=CxhMxE=B0fxXGVe1oNjRK6+4qpWqjpQvhmVRHw@mail.gmail.com>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
 <CAA8=vb5PzUz=CxhMxE=B0fxXGVe1oNjRK6+4qpWqjpQvhmVRHw@mail.gmail.com>
Message-ID: <CAHsqw9v8LbLNhyiNqFKyWBmHu85UtV9sLFzcUpa36bGYCcjjBQ@mail.gmail.com>

I would argue that collapsing all of your policy evaluation and routing for
a size/zone/area/whatever into one box is actually somewhat detrimental to
stability (and consequently, security to a certain extent).

Cramming every little feature under the sun into one appliance makes for
great glossy brochures and Powerpoint decks, but I just don't think it's
practical.

Take a LAMP hosting operation for example. Which will scale the furthest to
handle the most amount of traffic and stateful sessions: iptables and snort
on each multi-core server, or one massive central box with some interface
hardware and Cavium Octeons.
If built properly, my money's on the distributed setup.

Cheers,
jof

From Valdis.Kletnieks at vt.edu  Tue Dec  6 15:45:51 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 06 Dec 2011 16:45:51 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: Your message of "Tue, 06 Dec 2011 10:30:20 PST."
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
Message-ID: <36733.1323207951@turing-police.cc.vt.edu>

On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said:
> It could be argued that Nmap is malware, and such software has already been called to be made illegal.

Called by whom, other than yourself?
-------------- 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/20111206/44d7512a/attachment.bin>

From streiner at cluebyfour.org  Tue Dec  6 16:06:08 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 6 Dec 2011 17:06:08 -0500 (EST)
Subject: Internet Edge and Defense in Depth
In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
Message-ID: <Pine.LNX.4.64.1112061648480.20786@whammy.cluebyfour.org>

On Tue, 6 Dec 2011, Holmes,David A wrote:

> Some firewall vendors are proposing to collapse all Internet edge 
> functions into a single device (border router, firewall, IPS, caching 
> engine, proxy, etc.). A general Internet edge design principle has been 
> the "defense in depth" concept. Is anyone collapsing all Internet edge 
> functions into one device?

As others have said, this could make sense at the smaller end of the scale 
(SOHO, branch offices, small shops, etc), but I haven't see an all-in-one 
box that scales up to the traffic loads or handles things like routing 
protcools especially well in a large network.  The marketing folks will 
often dance around the issue of throughput dropping as services or 
modules are turned on, but that's a big problem.  I'm perfectly happy 
having border routers sitting at my borders, doing the routing, and 
firewalls elsewhere, doing the firewalling :)

Another thing to remember is that existing router manufacturers have 
gotten pretty good (a few exceptions aside) at building pretty stable 
routing implementations.  All-in-one box manufacturers that claim to be 
able to handle IPv6, BGP, OSPF(v2/v3), etc are basically starting out from 
scratch and don't have the benefit of the 10+ years of experience that 
Cisco/Juniper/et al have in building routers.

jms


From enwpst47 at gmail.com  Tue Dec  6 16:07:47 2011
From: enwpst47 at gmail.com (Dan Collins)
Date: Tue, 6 Dec 2011 17:07:47 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <36733.1323207951@turing-police.cc.vt.edu>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <36733.1323207951@turing-police.cc.vt.edu>
Message-ID: <CAMG9zygV4R74o6OPDzH5_OxoMtLY8K-2L6YDe6giv5rvoKmp-g@mail.gmail.com>

On Tue, Dec 6, 2011 at 4:45 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said:
>> It could be argued that Nmap is malware, and such software has already been called to be made illegal.
>
> Called by whom, other than yourself?

Germany?

http://www.schneier.com/blog/archives/2007/08/new_german_hack.html

--
Dan Collins


From jsaxe at briworks.com  Tue Dec  6 16:18:07 2011
From: jsaxe at briworks.com (Jeff Saxe)
Date: Tue, 6 Dec 2011 22:18:07 +0000
Subject: GPON Vendors
In-Reply-To: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
References: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
Message-ID: <A92EB23D9E64824189C99C5ABF8331042081B231@mbx024-e1-nj-2.exch024.domain.local>

Here at Blue Ridge InternetWorks we evaluated a few vendors (a couple of years ago) and are extremely happy with our choice of Calix E7. The engineering is top-notch, optical components are good quality, boot time is very fast, decent GUI (not perfect, but improves with each software release), software upgrades have been (knock wood) seamless every time, etc. And the E7 line is easy to use -- I hear tell that the C7 line had a horrible CLI and cryptic GUI and was powerful-but-demanding, but the E7 just acts like a big Ethernet switch with VLANs, customer-side rate-limiting, and a little bit of DHCP snooping, security, and multicast processing. And their tech support, both pre-sales and on-demand, have been responsive and very helpful every time I've called on them. I don't think they are cheap, and we wish they made an ONT model with many Ethernet ports but no POTS and RF video, but that's just a product mix suggestion. Overall we are really happy, and it's easy to deploy and making us actual money.

We have a rather small network, with a 2-slot (thin) E7 chassis. They also have a 20-slot large chassis. Only reservations I would have about it: 

- Currently runs only RSTP, but not MST. So difficult to load-balance redundant links into our switching core. I don't remember if MST is on the planned feature list.

- Currently no true IPv6 support. You can hand off IPv6 over a "straight transparent LAN" connection, but you can't use the DHCP snooping / IP source verify features, which they have in v4, to ensure that a customer must use DHCPv6 to get their address and then cannot impersonate another customer with a manual IPv6 address. Calix says full IPv6 support is planned.

- We had a few 711GX ONTs that developed optical transceiver failures in the field. It could be something that we did, but it seemed to me that it was just a bad batch of components in that specific product, since the 710GX and 711GE and 716GE's were all fine. All were replaced under warranty just fine, so no complaints other than customer downtime and our time to repair.

Feel free to ping me off-list for any other questions.


Jeff Saxe
blue ridge internetworks

321 east main st ? suite 200
charlottesville va  22902
434.817.0707 x 2024
www.briworks.com

Central Virginia?s technology authority since 2000.

________________________________________
From: Josh V. Hoppes [jhoppes at cfunet.net]
Sent: Tuesday, December 06, 2011 2:52 PM
To: nanog at nanog.org
Subject: GPON Vendors

Hello NANOG,

Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola.  We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies.

Josh Hoppes
Network Engineer
Cedar Falls Utilities





From ncolton at allophone.net  Tue Dec  6 16:30:03 2011
From: ncolton at allophone.net (Nick Colton)
Date: Tue, 6 Dec 2011 15:30:03 -0700
Subject: GPON Vendors
In-Reply-To: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
References: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
Message-ID: <CAFR7TW8p26jSO9NrbjO+-48iG0VzkUJyL6fEf5T7mU+DVoA3kw@mail.gmail.com>

We have a Calix C7 as well as some E7-2's in a few markets for a little
over a year.  We only deal with GPON/AE deployments and the C7 worked to
get us started but the E7 is definitely more purpose built for ethernet &
fiber services. Just started several major build-outs which pushed us to
re-evaluate vendors and after looking at a few other vendors we ended up
going back to the Calix E7 platform. Due to price and features vs other
vendors.  We have three E7-20's that we're turning up.  I would agree with
Jeff's positives.  They are starting to roll out indoor ONT's which will
shave some cost off of the ONT & Battery for the CPE.

- They do only support RSTP now, not MST but in our deployment we have 2 x
10 GE LAG ports on two separate line switching cards.  MST will be coming
in a future release.

- True IPv6 support is coming next year

- Quite a few other new features coming in the next year that we're excited
to see.

Feel free to ping me off-list if you have any other questions.

Nick Colton
Director of Network Operations
ALLO Communications


On Tue, Dec 6, 2011 at 12:52 PM, Josh V. Hoppes <jhoppes at cfunet.net> wrote:

> Hello NANOG,
>
> Due to unforeseen circumstances we need to consider alternative vendors
> for our GPON system, moving away from Motorola.  We wanted to throw out a
> line and find out what other networks have deployed and what experiences
> they have had positive or negative with them. Thanks in advance for any
> replies.
>
> Josh Hoppes
> Network Engineer
> Cedar Falls Utilities
>
>
>
>

From Valdis.Kletnieks at vt.edu  Tue Dec  6 16:39:57 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 06 Dec 2011 17:39:57 -0500
Subject: Writable SNMP
In-Reply-To: Your message of "Tue, 06 Dec 2011 14:18:52 EST."
 <CAPWAtbJubOh2vszRuOro=aYUiJe1KKQopgO1HHHPXGzznZznNg@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CAPWAtbJubOh2vszRuOro=aYUiJe1KKQopgO1HHHPXGzznZznNg@mail.gmail.com>
Message-ID: <39027.1323211197@turing-police.cc.vt.edu>

On Tue, 06 Dec 2011 14:18:52 EST, Jeff Wheeler said:

> I've spent enough time writing code to deal with SNMP (our own stack,
> not using Net-SNMP or friends) to have a more in-depth understanding
> of SNMP's pitfalls than most people.  It is TERRIBLE and should be
> totally gutted and replaced with something more sane, less likely to
> have bugs, etc.

A number of years ago, I pointed out that the official rfc-index.txt listed
the publication date of RFC1442 as April 1, 1993 rather than April 1993.

Draw your own conclusions. ;)
-------------- 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/20111206/b3968eb7/attachment.bin>

From paul at paulgraydon.co.uk  Tue Dec  6 17:02:45 2011
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Tue, 06 Dec 2011 13:02:45 -1000
Subject: Internet Edge and Defense in Depth
In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
Message-ID: <4EDE9F15.2020601@paulgraydon.co.uk>

On 12/06/2011 11:16 AM, Holmes,David A wrote:
> Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device?
>
> Regards,
>
> David
>
>
Yikes... single point of failure.  I really dislike the notion that all 
the security comes down to a single potentially compromisable point.  
Our security functions like IPS run separate to centralised logging, 
etc. etc. so that if someone does happen to break in to a particular 
point there are still further things they need to try to compromise 
before they can have their wicked way, or whatever it is they want to do.
Sure the economies of a centralised box and the convenience are probably 
tempting, and it's better than nothing, but I can't picture it actually 
being an improvement over split out functions.

Paul


From edward.dore at freethought-internet.co.uk  Tue Dec  6 17:12:13 2011
From: edward.dore at freethought-internet.co.uk (Edward Dore)
Date: Tue, 6 Dec 2011 23:12:13 +0000
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <CAMG9zygV4R74o6OPDzH5_OxoMtLY8K-2L6YDe6giv5rvoKmp-g@mail.gmail.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <36733.1323207951@turing-police.cc.vt.edu>
 <CAMG9zygV4R74o6OPDzH5_OxoMtLY8K-2L6YDe6giv5rvoKmp-g@mail.gmail.com>
Message-ID: <094787A0-3840-48E5-B837-9B73AFE98EC0@freethought-internet.co.uk>

On 6 Dec 2011, at 22:07, Dan Collins wrote:

> On Tue, Dec 6, 2011 at 4:45 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>> On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said:
>>> It could be argued that Nmap is malware, and such software has already been called to be made illegal.
>> 
>> Called by whom, other than yourself?
> 
> Germany?
> 
> http://www.schneier.com/blog/archives/2007/08/new_german_hack.html
> 
> --
> Dan Collins
> 

There's a big difference between "hacking tools" and malware.

Edward Dore 
Freethought Internet 

From xmin0s at gmail.com  Tue Dec  6 17:13:14 2011
From: xmin0s at gmail.com (Tim Eberhard)
Date: Tue, 6 Dec 2011 17:13:14 -0600
Subject: Internet Edge and Defense in Depth
In-Reply-To: <4C0D4D97-780B-4F04-A8EE-E4FD204B03D6@miltonsecurity.com>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
 <4EDE8852.30506@gmail.com>
 <4C0D4D97-780B-4F04-A8EE-E4FD204B03D6@miltonsecurity.com>
Message-ID: <CAHoW-Rn3R=JLLAQG4gz36L+wBP3Mz8C_-jOsq5xRhOAd0nNH3w@mail.gmail.com>

To echo what James has already said..

I would say it's possible on the low/medium size enterprise network
market. With that stated 70-80% of the time it's not designed
correctly or a vendor issue pops up causing them to disable the
feature.

Careful planning must be done ahead of time. When looking at the spec
sheets you can't look at the numbers and take them for face value. In
most cases those numbers were achieved when *only* running that
specific feature.

So if a vendor claims 90meg of IPS throughput, 500meg of firewall
throughput and 100meg of UTM. Chances are that 90meg of IPS traffic
will take the box to it's knees. So if you're planning using the data
sheet numbers you've most likely already failed.

Plan carefully, test throughly, and in the end..you still may hit a
bug or unexpected show stopper. I'd rather use the best tool for the
job rather than jam everything into once box so I can share a
chassis...

Just my two cents,
-Tim Eberhard

On Tue, Dec 6, 2011 at 3:32 PM, JAMES MCMURRY <jim at miltonsecurity.com> wrote:
> I have seen at quite a few of our customers locations, starting out with a lofty goal of putting everything in a single box (UTM) and turning every single option on.
>
> In ~ 30% of the firms who do so it works out ok (not great, but it works). ?In the majority, the customer winds up turning features off one by one, and moving those to another system.
>
>
> Jim
>
>
> On Dec 6, 2011, at 1:25 PM, -Hammer- wrote:
>
>> I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea.
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 12/06/2011 03:16 PM, Holmes,David A wrote:
>>> Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device?
>>>
>>> Regards,
>>>
>>> David
>>>
>>>
>>>
>>> ? ________________________________
>>> 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 robert at timetraveller.org  Tue Dec  6 17:20:05 2011
From: robert at timetraveller.org (Robert Brockway)
Date: Wed, 7 Dec 2011 09:20:05 +1000 (EST)
Subject: Internet Edge and Defense in Depth
In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
Message-ID: <alpine.DEB.2.00.1112070910270.8973@castor.opentrend.net>

On Tue, 6 Dec 2011, Holmes,David A wrote:

> Some firewall vendors are proposing to collapse all Internet edge 
> functions into a single device (border router, firewall, IPS, caching 
> engine, proxy, etc.). A general Internet edge design principle has been 
> the "defense in depth" concept. Is anyone collapsing all Internet edge 
> functions into one device?

Hi David.  A principle of network firewall design has long been that you 
want to minimise services (proxy, etc) running there as they can be a 
vector for attack against the firewall itself.

In the end this is about risk analysis.  In most cases I would recommend 
against loading the firewall with additional functionality, for a variety 
of reasons.  In some cases it may make sense to do so.

This is completely separate to whether servers should even have a firewall 
or IPS in front of them.  That's another (interesting) discussion :)

Cheers,

Rob

-- 
Email: robert at timetraveller.org		Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.practicalsysadmin.com
Director, Software in the Public Interest (http://spi-inc.org/)
Free & Open Source: The revolution that quietly changed the world
"One ought not to believe anything, save that which can be proven by nature and the force of reason" -- Frederick II (26 December 1194 ? 13 December 1250)

From Bryan at bryanfields.net  Tue Dec  6 17:24:25 2011
From: Bryan at bryanfields.net (Bryan Fields)
Date: Tue, 06 Dec 2011 18:24:25 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
Message-ID: <4EDEA429.2000709@bryanfields.net>

On 12/6/2011 13:30, andrew.wallace wrote:
> It could be argued that Nmap is malware, and such software has already been called to be made illegal.
> 
> If I was Cnet, I would stop distributing his software altogether.
> 
> Link: http://nmap.org/book/legal-issues.html

If this is not trolling and you actually believe this, just wow.....

Nmap is just a tool, and any tool can be misused by people for criminal acts.
 It's really no different than a gun in that regard.  Both are incredibly
useful things in the right hands, mere tools to further security.  However in
the wrong hands they can be used to commit crimes and break other peoples
security.

-- 
Bryan Fields

727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net


From jtowne at slic.com  Tue Dec  6 17:28:43 2011
From: jtowne at slic.com (Jonathan Towne)
Date: Tue, 6 Dec 2011 18:28:43 -0500
Subject: GPON Vendors
In-Reply-To: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
References: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
Message-ID: <20111206232841.GS13315@hijacked.us>

Another vote for Calix here, but we started with Occam B-series gear (DSL+POTS) and
kept buying their gear into the GPON times.  Calix bought them.. so the vote is for
Calix, even though I haven't used their C or E series gear.

I do a fair amount of scripting for various tasks and have been fairly happy with
their EPS ring protection.. not exactly like running [M|R]STP, but really quite
resilient, at any rate.

Their software is all running on a Linux core, has a decent (but not great)
Cisco-ish CLI, and a very good web-UI.  It seems like they're focusing more on the
web-UI than the CLI, these days, but both are built on the same internals.

We use B-6322 GPON blades (and quite a few of them, adding more on a daily basis..)
and mainly their 12 blade chassis'.  These chassis only have an option for -48VDC
power, but are very well built overall, and the software is getting better on every
new release.  I expect we're nearing a sort of magic period of time when the Calix
engineers and the Occam engineers are on the same page and really making progress,
copying the best features from each platform onto the other.  It seems to be showing
in the early OccamOS 7.x releases, I can't speak for the C/E OS', I've never used
them.

-- Jonathan Towne


On Tue, Dec 06, 2011 at 07:52:20PM +0000, Josh V. Hoppes scribbled:
# Hello NANOG,
# 
# Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola.  We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies.
# 
# Josh Hoppes
# Network Engineer
# Cedar Falls Utilities
# 
# 
# 


From andrew.wallace at rocketmail.com  Tue Dec  6 17:49:29 2011
From: andrew.wallace at rocketmail.com (andrew.wallace)
Date: Tue, 6 Dec 2011 15:49:29 -0800 (PST)
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <4EDEA429.2000709@bryanfields.net>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
Message-ID: <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>

A trojan can be used for good if in the right hands as a remote access tool for business use.


Andrew


________________________________
 From: Bryan Fields <Bryan at bryanfields.net>
To: "nanog at nanog.org" <nanog at nanog.org> 
Sent: Tuesday, December 6, 2011 11:24 PM
Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
 
On 12/6/2011 13:30, andrew.wallace wrote:
> It could be argued that Nmap is malware, and such software has already been called to be made illegal.
> 
> If I was Cnet, I would stop distributing his software altogether.
> 
> Link: http://nmap.org/book/legal-issues.html

If this is not trolling and you actually believe this, just wow.....

Nmap is just a tool, and any tool can be misused by people for criminal acts.
It's really no different than a gun in that regard.? Both are incredibly
useful things in the right hands, mere tools to further security.? However in
the wrong hands they can be used to commit crimes and break other peoples
security.

-- 
Bryan Fields

727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net

From tshaw at oitc.com  Tue Dec  6 17:55:06 2011
From: tshaw at oitc.com (TR Shaw)
Date: Tue, 6 Dec 2011 18:55:06 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
Message-ID: <311C806B-2E39-453A-ADCC-612C8A531FE1@oitc.com>

I can't believe this...

Andrew, please check the dictionary second definition of Trojan before proceeding.

A "remote access tool" is ssh, VNC and others and these are definitely not trojans. Get a grip.

Trojan Horse
noun noun Greek Mythology
a hollow wooden statue of a horse in which the Greeks concealed themselves in order to enter Troy.
? (also Trojan horse) figurative a person or thing intended secretly to undermine or bring about the downfall of an enemy or opponent : the rebels may use this peace accord as a Trojan horse to try and take over.
? (also Trojan horse) Computing a program designed to breach the security of a computer system while ostensibly performing some innocuous function.

Tom

On Dec 6, 2011, at 6:49 PM, andrew.wallace wrote:

> A trojan can be used for good if in the right hands as a remote access tool for business use.
> 
> 
> Andrew
> 
> 
> ________________________________
> From: Bryan Fields <Bryan at bryanfields.net>
> To: "nanog at nanog.org" <nanog at nanog.org> 
> Sent: Tuesday, December 6, 2011 11:24 PM
> Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
> 
> On 12/6/2011 13:30, andrew.wallace wrote:
>> It could be argued that Nmap is malware, and such software has already been called to be made illegal.
>> 
>> If I was Cnet, I would stop distributing his software altogether.
>> 
>> Link: http://nmap.org/book/legal-issues.html
> 
> If this is not trolling and you actually believe this, just wow.....
> 
> Nmap is just a tool, and any tool can be misused by people for criminal acts.
> It's really no different than a gun in that regard.  Both are incredibly
> useful things in the right hands, mere tools to further security.  However in
> the wrong hands they can be used to commit crimes and break other peoples
> security.
> 
> -- 
> Bryan Fields
> 
> 727-409-1194 - Voice
> 727-214-2508 - Fax
> http://bryanfields.net



From Valdis.Kletnieks at vt.edu  Tue Dec  6 17:59:59 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 06 Dec 2011 18:59:59 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: Your message of "Tue, 06 Dec 2011 17:07:47 EST."
 <CAMG9zygV4R74o6OPDzH5_OxoMtLY8K-2L6YDe6giv5rvoKmp-g@mail.gmail.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <36733.1323207951@turing-police.cc.vt.edu>
 <CAMG9zygV4R74o6OPDzH5_OxoMtLY8K-2L6YDe6giv5rvoKmp-g@mail.gmail.com>
Message-ID: <42091.1323215999@turing-police.cc.vt.edu>

On Tue, 06 Dec 2011 17:07:47 EST, Dan Collins said:
> On Tue, Dec 6, 2011 at 4:45 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> > On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said:
> >> It could be argued that Nmap is malware, and such software has already been called to be made illegal.
> >
> > Called by whom, other than yourself?
>
> Germany?
>
> http://www.schneier.com/blog/archives/2007/08/new_german_hack.html

I rest my case. ;)

Anybody know if they ever fixed their law?
-------------- 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/20111206/1a41d8ae/attachment.bin>

From rdobbins at arbor.net  Tue Dec  6 18:36:05 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 7 Dec 2011 00:36:05 +0000
Subject: Internet Edge and Defense in Depth
In-Reply-To: <alpine.DEB.2.00.1112070910270.8973@castor.opentrend.net>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
 <alpine.DEB.2.00.1112070910270.8973@castor.opentrend.net>
Message-ID: <2321C0A3-264A-4460-94BE-8A7F1214F3C3@arbor.net>


On Dec 7, 2011, at 6:20 AM, Robert Brockway wrote:

> This is completely separate to whether servers should even have a firewall or IPS in front of them.  That's another (interesting) discussion :)

<http://www.nanog.org/meetings/nanog48/presentations/Monday/Kaeo_FilterTrend_ISPSec_N48.pdf>

<http://www.ausnog.net/images/ausnog-05/presentations/7-2-stateofdanger.pdf>

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From mvh at hosteurope.de  Tue Dec  6 18:44:10 2011
From: mvh at hosteurope.de (Malte von dem Hagen)
Date: Wed, 07 Dec 2011 01:44:10 +0100
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <42091.1323215999@turing-police.cc.vt.edu>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <36733.1323207951@turing-police.cc.vt.edu>
 <CAMG9zygV4R74o6OPDzH5_OxoMtLY8K-2L6YDe6giv5rvoKmp-g@mail.gmail.com>
 <42091.1323215999@turing-police.cc.vt.edu>
Message-ID: <4EDEB6DA.9010100@hosteurope.de>

Hi,

Valdis.Kletnieks at vt.edu wrote on Mi, 2011-12-07 at 00:59+0100:
> On Tue, 06 Dec 2011 17:07:47 EST, Dan Collins said:
>> On Tue, Dec 6, 2011 at 4:45 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>>> On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said:
>>>> It could be argued that Nmap is malware, and such software has already been called to be made illegal.
>>>
>>> Called by whom, other than yourself?
>>
>> Germany?
>>
>> http://www.schneier.com/blog/archives/2007/08/new_german_hack.html
> 
> I rest my case. ;)
> 
> Anybody know if they ever fixed their law?

not really. There have been some highest court decisions regarding this
law saying the criminal liability depends on the intention someone
produces or owns such tools - German jurisprudence is much more than the
wording of the written law (though we have a lot of written laws,
including many very strange ones). ;-)

De facto, everybody in the industry continues to use "dual use" tools
without fear of punishment and I am not aware of any dubious court
decisions - the law was created for clearly illegal uses of such tools.

Nontheless, as said by others, "hacker tools" != "malware".

Regards,

Malte
-- 
Malte von dem Hagen
Head of Network Engineering & Operations
-----------------------------------------------------------------------
Host Europe GmbH - http://www.hosteurope.de
Welserstra?e 14 - 51149 K?ln - Germany
Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678
Gesch?ftsf?hrer: Patrick Pulverm?ller, Thomas Vollrath

(*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min.
aus den dt. Mobilfunknetzen

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

From Valdis.Kletnieks at vt.edu  Tue Dec  6 19:03:15 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 06 Dec 2011 20:03:15 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: Your message of "Tue, 06 Dec 2011 15:49:29 PST."
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
Message-ID: <44850.1323219795@turing-police.cc.vt.edu>

On Tue, 06 Dec 2011 15:49:29 PST, "andrew.wallace" said:
> A trojan can be used for good if in the right hands as a remote access tool for business use.

Best troll line since n3td3v got banned from full-disclosure.  Well played, I've been
outclassed, I'm outta here.

-------------- 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/20111206/1b89db02/attachment.bin>

From mike at mtcc.com  Tue Dec  6 19:09:54 2011
From: mike at mtcc.com (Michael Thomas)
Date: Tue, 06 Dec 2011 17:09:54 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <44850.1323219795@turing-police.cc.vt.edu>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
 <44850.1323219795@turing-police.cc.vt.edu>
Message-ID: <4EDEBCE2.4010405@mtcc.com>

On 12/06/2011 05:03 PM, Valdis.Kletnieks at vt.edu wrote:
> On Tue, 06 Dec 2011 15:49:29 PST, "andrew.wallace" said:
>> A trojan can be used for good if in the right hands as a remote access tool for business use.
> Best troll line since n3td3v got banned from full-disclosure.  Well played, I've been
> outclassed, I'm outta here.
>

I had assumed that he meant this in terms of red light districts.

Mike


From tvhawaii at shaka.com  Tue Dec  6 19:36:08 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Tue, 6 Dec 2011 15:36:08 -1000
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
 <44850.1323219795@turing-police.cc.vt.edu>
Message-ID: <6598045046084577A2247C7C114441E0@owner59e1f1502>

----- Original Message ----- 
From: <Valdis.Kletnieks at vt.edu>
To: <nanog at nanog.org>
Sent: Tuesday, December 06, 2011 3:03 PM
Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

On Tue, 06 Dec 2011 15:49:29 PST, "andrew.wallace" said:
>> A trojan can be used for good if in the right hands as a remote access tool for business use.

>Best troll line since n3td3v got banned from full-disclosure.  Well played, I've been
>outclassed, I'm outta here.

Maybe andrew's been reading http://wikileaks.org/the-spyfiles.html  ?


From owen at delong.com  Tue Dec  6 20:10:14 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 6 Dec 2011 18:10:14 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
Message-ID: <C1FC59BC-47C3-4BC3-AE78-A06CA1650A10@delong.com>

Carrier IQ does not qualify as a good use of a Trojan and comes about as close to your definition as I can think of.

No, a Trojan is malware. Any software which operates without the knowledge or consent of the user to engage in operations the user would not reasonably expect is not being used for good, no matter how well intentioned.

Owen

On Dec 6, 2011, at 3:49 PM, andrew.wallace wrote:

> A trojan can be used for good if in the right hands as a remote access tool for business use.
> 
> 
> Andrew
> 
> 
> ________________________________
> From: Bryan Fields <Bryan at bryanfields.net>
> To: "nanog at nanog.org" <nanog at nanog.org> 
> Sent: Tuesday, December 6, 2011 11:24 PM
> Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
> 
> On 12/6/2011 13:30, andrew.wallace wrote:
>> It could be argued that Nmap is malware, and such software has already been called to be made illegal.
>> 
>> If I was Cnet, I would stop distributing his software altogether.
>> 
>> Link: http://nmap.org/book/legal-issues.html
> 
> If this is not trolling and you actually believe this, just wow.....
> 
> Nmap is just a tool, and any tool can be misused by people for criminal acts.
> It's really no different than a gun in that regard.  Both are incredibly
> useful things in the right hands, mere tools to further security.  However in
> the wrong hands they can be used to commit crimes and break other peoples
> security.
> 
> -- 
> Bryan Fields
> 
> 727-409-1194 - Voice
> 727-214-2508 - Fax
> http://bryanfields.net



From Valdis.Kletnieks at vt.edu  Tue Dec  6 20:20:52 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 06 Dec 2011 21:20:52 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: Your message of "Tue, 06 Dec 2011 17:09:54 PST."
 <4EDEBCE2.4010405@mtcc.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
 <44850.1323219795@turing-police.cc.vt.edu>
 <4EDEBCE2.4010405@mtcc.com>
Message-ID: <48657.1323224452@turing-police.cc.vt.edu>

On Tue, 06 Dec 2011 17:09:54 PST, Michael Thomas said:
> On 12/06/2011 05:03 PM, Valdis.Kletnieks at vt.edu wrote:
> > On Tue, 06 Dec 2011 15:49:29 PST, "andrew.wallace" said:
> >> A trojan can be used for good if in the right hands as a remote access tool for business use.

> I had assumed that he meant this in terms of red light districts.

But then it's not exactly remote access, is 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/20111206/12d4d534/attachment.bin>

From Valdis.Kletnieks at vt.edu  Tue Dec  6 20:20:03 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 06 Dec 2011 21:20:03 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: Your message of "Tue, 06 Dec 2011 18:10:14 PST."
 <C1FC59BC-47C3-4BC3-AE78-A06CA1650A10@delong.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
 <C1FC59BC-47C3-4BC3-AE78-A06CA1650A10@delong.com>
Message-ID: <48621.1323224403@turing-police.cc.vt.edu>

On Tue, 06 Dec 2011 18:10:14 PST, Owen DeLong said:

> No, a Trojan is malware. Any software which operates without the
> knowledge or consent of the user to engage in operations the user would
> not reasonably expect is not being used for good, no matter how well
> intentioned.

Strictly speaking, it's "without the knowledge or consent of the *owner*". Especially
in corporate environments, "owner" != "user".
-------------- 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/20111206/286a8f95/attachment.bin>

From mtinka at globaltransit.net  Tue Dec  6 21:25:19 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 7 Dec 2011 11:25:19 +0800
Subject: GPON Vendors
In-Reply-To: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
References: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
Message-ID: <201112071125.22810.mtinka@globaltransit.net>

On Wednesday, December 07, 2011 03:52:20 AM Josh V. Hoppes 
wrote:

> Due to unforeseen circumstances we need to consider
> alternative vendors for our GPON system, moving away
> from Motorola.  We wanted to throw out a line and find
> out what other networks have deployed and what
> experiences they have had positive or negative with
> them. Thanks in advance for any replies.

We're using Huawei for this.

It's a stable system, and they do this quite well. Watch out 
for the EMS though; it's great for management and 
provisioning, but customer migration is not supported (yet).

The ONU that ships from Huawei is also not terribly good as 
a clever CPE. So if you're thinking of doing interesting 
things, suggest you use their ONU as a bridge and have 
something else terminating the PPPoE/DHCP sessions.

Otherwise, I'd certainly recommend looking at Huawei for 
this. We've been reasonably happy using them for our FTTH 
and IPTv deployment.

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/20111207/b1593dc0/attachment.bin>

From daniel.unam.ipv6 at gmail.com  Tue Dec  6 21:39:32 2011
From: daniel.unam.ipv6 at gmail.com (Daniel Espejel)
Date: Tue, 06 Dec 2011 21:39:32 -0600
Subject: HP IPv6 RA Guard
In-Reply-To: <CALFTrnO7PdoBuSiEwSqxnmD7uEPSr9JuFjGEED_Jzizbqa+HRQ@mail.gmail.com>
References: <mailman.15875.1323080381.1873.nanog@nanog.org>	<4EDD8D87.30208@gmail.com>
 <CALFTrnO7PdoBuSiEwSqxnmD7uEPSr9JuFjGEED_Jzizbqa+HRQ@mail.gmail.com>
Message-ID: <4EDEDFF4.9030606@gmail.com>

Well, as a stability feature may work if better understanding of the
internet protocols is given to all the network specialist (almost a
paradox, all those documents are free to be checked for all the people).

Of course, the problem with the rogue IPv6 packets and "malformed"
packets will exists as long as IPv6
is being deployed wide spread, and the proposed mechanisms on how to
deal with those problems is, as it seems, a passion for some guys, and a
job for other ones, but always thinking on the Internet growth is the
main focus of those whom participate actively to reach that objective.

For Rogue V6's maybe some ACLs could work, but increases complexity.
Maybe some mechanisms in the receiving nodes could work too, but
requires a lot of computer resources and in that situations the LoWPAN
will suffer its own success; so actually a solution should be adequate
to each situation.
BR

On 06/12/11 07:46, Ray Soucy wrote:
> I think of RA Guard as a Layer-2 stability feature, rather than a
> security feature.
>
> You're correct that it is unable to deal with RA crafted in a
> fragmented packet on the majority (if not all) of implementations.
>
> The issue of rogue RA exists on every network, regardless of whether
> or not the IT group has deployed IPv6 or is aware of the IPv6 traffic
> on that network.
>
> Windows ICS is the most common "accidental" cause of rogue RA on a LAN.
>
> On Mon, Dec 5, 2011 at 10:35 PM, Daniel Espejel
> <daniel.unam.ipv6 at gmail.com> wrote:
>> So,still assuming the fact that attackers will use the same "traditional
>> ipv4" methods to alter the correct functioning over a network?...Well,
>> maybe. Toda's IPv6 expertise for some network andmins and security
>> experts is minimal. So most trainning and understanding before
>> implementing its a good idea.
>>
>> For example, the RA-Guard method has a significant vulnerability: It's
>> not designed to identify a "complex" IPv6-many extension headers formed
>> packet (F. Gont - 6Networks). Some other security oriented mechanisms
>> may fail because of the low IPv6 compliance.
>>
>> Regards.
>>
>>
>> --
>> Daniel Espejel P?rez
>> T?cnico Acad?mico
>> D.G.T.I.C. - U.N.A.M.
>> GT-IPv6 CLARA / GT-IPv6 U.N.A.M.
>>
>>
>
>

-- 
Daniel Espejel P?rez
T?cnico Acad?mico
D.G.T.I.C. - U.N.A.M.
GT-IPv6 CLARA / GT-IPv6 U.N.A.M.



From mtinka at globaltransit.net  Tue Dec  6 21:45:13 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 7 Dec 2011 11:45:13 +0800
Subject: GPON Vendors
In-Reply-To: <A92EB23D9E64824189C99C5ABF8331042081B231@mbx024-e1-nj-2.exch024.domain.local>
References: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
 <A92EB23D9E64824189C99C5ABF8331042081B231@mbx024-e1-nj-2.exch024.domain.local>
Message-ID: <201112071145.16217.mtinka@globaltransit.net>

On Wednesday, December 07, 2011 06:18:07 AM Jeff Saxe wrote:

> - Currently runs only RSTP, but not MST. So difficult to
> load-balance redundant links into our switching core. I
> don't remember if MST is on the planned feature list.

We run LACP either to the same or different routers 
depending on a few internal factors.

For LACP to different routers, we use MC-LAG.

Don't want to have to deal with "Spamming" Tree :-).

> - Currently no true IPv6 support. You can hand off IPv6
> over a "straight transparent LAN" connection, but you
> can't use the DHCP snooping / IP source verify features,
> which they have in v4, to ensure that a customer must
> use DHCPv6 to get their address and then cannot
> impersonate another customer with a manual IPv6 address.
> Calix says full IPv6 support is planned.

Same problem on the Huawei, too.

Full support is planned for mid-to-late 2013. Of course, 
that puts a dent in our plans.

> - We had a few 711GX ONTs that developed optical
> transceiver failures in the field. It could be something
> that we did, but it seemed to me that it was just a bad
> batch of components in that specific product, since the
> 710GX and 711GE and 716GE's were all fine. All were
> replaced under warranty just fine, so no complaints
> other than customer downtime and our time to repair.

We've found that the Huawei works well with other vendor 
optics too. Cisco, Juniper, OEM's. All good.

Of course, for 10Gbps uplinks, the SFP+ units are bought 
from Huawei. We have some SPF+ modules from Cisco and their 
OEM's, but haven't tried them on the Huawei. Experience 
suggests it would work, but they're quite premium that we 
always need them for the Cisco's anyway :-).

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/20111207/d4b5fc39/attachment.bin>

From mtinka at globaltransit.net  Tue Dec  6 21:58:59 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 7 Dec 2011 11:58:59 +0800
Subject: Internet Edge and Defense in Depth
In-Reply-To: <alpine.DEB.2.00.1112070910270.8973@castor.opentrend.net>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
 <alpine.DEB.2.00.1112070910270.8973@castor.opentrend.net>
Message-ID: <201112071159.02647.mtinka@globaltransit.net>

We've been fairly against centralizing functions, even 
though marketing scripts suggest it is worth doing.

Not security-related per se, but for smaller PoP's, we'll 
collapse P/PE functions into a single box. As others have 
mentioned, this makes sense when scale is small.

But on a large scale, we've not been one to buy into multi-
chassis-type arrangements. With boxes getting smaller and 
more powerful due to Ethernet being the implicitly agreed-
upon medium, it's still cheaper (and more resilient) to buy 
smaller boxes and distribute services than take one large 
one and stick them all in there.

I'm hoping the OP can draw a parallel for their own 
situation, if this is useful.

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/20111207/71ea0109/attachment.bin>

From fyodor at insecure.org  Tue Dec  6 22:18:53 2011
From: fyodor at insecure.org (Fyodor)
Date: Tue, 6 Dec 2011 20:18:53 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
References: <20111205234419.GD1454@vacation.karoshi.com.>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
Message-ID: <20111207041853.GL24540@syn.titan.net>

On Mon, Dec 05, 2011 at 10:14:48PM -0800, andrew.wallace wrote:
>
> Using fruitful language and acting like a child isn't going to see
> you taken seriously.

I'm sorry that my language offended you. But if you ever spend more
than 14 years creating free software as a gift to the community, only
to have it used as bait by a giant corporation to infect your users
with malware, then you may understand my rage.

The good news is that many users are sick and tired of having their
machines hijacked by malware.  Especially by CNET Download.Com, which
still says on their own adware policy page:

  "In your letters, user reviews, and polls, you told us bundled
   adware was unacceptable--no matter how harmless it might be. We want
   you to know what you're getting when you download from CNET
   Download.com, and no other download site can promise that."
   --http://www.cnet.com/2723-13403_1-461-16.html

Um, what people WANT when they download Nmap is Nmap itself.  Not to
have their searches redirected to Bing and their home page changed to
Microsoft's MSN.

Speaking of which, Microsoft emailed me today.  They said that they
didn't know they were sponsoring CNET to trojan open source software,
and that they have stopped doing it.  But the trojan installer uses
your Internet connection to obtain more "special offers" from CNET,
and they immediately switched to installing a "Babylon toolbar" and
search engine redirect instead.  Then CNET removed that and are now
promoting their own "techtracker" tool.  Apparently the heat is so
high that even malware vendors are refusing to have any more part in
CNET's antics!  But if CNET isn't stopped, the malware vendors will
come crawling back eventually and CNET will be there to receive them.

There have been dozens of news articles in the last day and hundreds
of outraged comments on blogs, Twitter, Facebook, etc.  In the midst
of all this terrible PR, Download.com went in last night and quietly
switched their Nmap downloads back to our real installer.  At least
for now.  But that isn't enough--they are still infecting the
installers for thousands of other packages!  For example, they have
currently infected the installer for a children's coloring book app:

http://download.cnet.com/Kea-Coloring-Book/3000-2102_4-10360620.html

Have they no shame at all??!

I've created a page with the situation background, links to the news
articles, and the latest updates:

http://insecure.org/news/download-com-fiasco.html

Feel free to share it.  Together, I hope we can get Download.Com to
apologize and cease this reprehensible behavior!

Cheers,
Fyodor


From tvhawaii at shaka.com  Tue Dec  6 22:53:08 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Tue, 6 Dec 2011 18:53:08 -1000
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
References: <20111205234419.GD1454@vacation.karoshi.com.>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <20111207041853.GL24540@syn.titan.net>
Message-ID: <765968889B724C4896CE5E38559C5E11@owner59e1f1502>

Fyodor wrote:
> On Mon, Dec 05, 2011 at 10:14:48PM -0800, andrew.wallace wrote:
>> 
>> Using fruitful language and acting like a child isn't going to see
>> you taken seriously.
> 
> I'm sorry that my language offended you. But if you ever spend more
> than 14 years creating free software as a gift to the community, only
> to have it used as bait by a giant corporation to infect your users
> with malware, then you may understand my rage.
> 
> The good news is that many users are sick and tired of having their
> machines hijacked by malware.  Especially by CNET Download.Com, which
> still says on their own adware policy page:
> 
>  "In your letters, user reviews, and polls, you told us bundled
>   adware was unacceptable--no matter how harmless it might be. We want
>   you to know what you're getting when you download from CNET
>   Download.com, and no other download site can promise that."
>   --http://www.cnet.com/2723-13403_1-461-16.html
> 
> Um, what people WANT when they download Nmap is Nmap itself.  Not to
> have their searches redirected to Bing and their home page changed to
> Microsoft's MSN.
> 
> Speaking of which, Microsoft emailed me today.  They said that they
> didn't know they were sponsoring CNET to trojan open source software,
> and that they have stopped doing it.  But the trojan installer uses
> your Internet connection to obtain more "special offers" from CNET,
> and they immediately switched to installing a "Babylon toolbar" and
> search engine redirect instead.  Then CNET removed that and are now
> promoting their own "techtracker" tool.  Apparently the heat is so
> high that even malware vendors are refusing to have any more part in
> CNET's antics!  But if CNET isn't stopped, the malware vendors will
> come crawling back eventually and CNET will be there to receive them.
> 
> There have been dozens of news articles in the last day and hundreds
> of outraged comments on blogs, Twitter, Facebook, etc.  In the midst
> of all this terrible PR, Download.com went in last night and quietly
> switched their Nmap downloads back to our real installer.  At least
> for now.  But that isn't enough--they are still infecting the
> installers for thousands of other packages!  For example, they have
> currently infected the installer for a children's coloring book app:
> 
> http://download.cnet.com/Kea-Coloring-Book/3000-2102_4-10360620.html
> 
> Have they no shame at all??!
> 
> I've created a page with the situation background, links to the news
> articles, and the latest updates:
> 
> http://insecure.org/news/download-com-fiasco.html
> 
> Feel free to share it.  Together, I hope we can get Download.Com to
> apologize and cease this reprehensible behavior!
> 
> Cheers,
> Fyodor

No, there's no shame when money's involved.
Do Unto Others as they would do unto you...sue the fsck out of them.
--Michael



From wjhns61 at hardakers.net  Tue Dec  6 23:21:50 2011
From: wjhns61 at hardakers.net (Wes Hardaker)
Date: Tue, 06 Dec 2011 21:21:50 -0800
Subject: Writable SNMP
In-Reply-To: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 (Keegan Holley's message of "Tue, 6 Dec 2011 11:07:44 -0500")
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
Message-ID: <0lehwh9csx.fsf@wjh.hardakers.net>

>>>>> On Tue, 6 Dec 2011 11:07:44 -0500, Keegan Holley <keegan.holley at sungard.com> said:

KH> Admittedly, you will have to deal with proprietary mibs and reformat
KH> the data once it's returned.

That's the nail in the coffin of just about every configuration
protocol.  Until multiple vendors implement a common model, no
technology is going to work.  SNMP certainly suffered from multiple
vendors doing different things in their private MIBs while also
implementing the standard MIBs is a standard way.

You could probably get two vendors (X and Y) to agree that all
devices have N interfaces with M-bit counters to represent traffic.  The
problem, especially with configuration, comes when vendor X uses virtual
interfaces (eth0:1) to model interfaces with multiple addresses and
vendor Y uses a single interface identifier with a sub-tail to list all
the addresses assigned to the interface.  Now this problem is at least
solvable, given enough code, to take a configuration set from one device
and covert it to the other, which in part is the goal of netconf: to
enable a language that will hopefully allow a transformation process to
succeed and thus bring about the holy grail of a singular management
protocol.

But in the end, every problem will still end up in the odd case where
vendor X produces a config set with 2 "rows" and vendor Y produces a
config set with 3 "rows" and no magical transformation can possibly get
from point A to point B because the data models simply don't align.  At all.
When the internals aren't compatable, there isn't a data model to be
written.  No matter if it's in txt, SMIv2, XML, yang or moon dust.

And hence the reason homogeneous networks with rdist distributed config
files were born.
-- 
Wes Hardaker                                     


From wjhns61 at hardakers.net  Tue Dec  6 23:37:44 2011
From: wjhns61 at hardakers.net (Wes Hardaker)
Date: Tue, 06 Dec 2011 21:37:44 -0800
Subject: Writable SNMP
In-Reply-To: <20111206173934.GK21378@blackrose.org> (Dorian Kim's message of
 "Tue, 6 Dec 2011 12:39:34 -0500")
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
 <20111206173934.GK21378@blackrose.org>
Message-ID: <0laa759c2f.fsf@wjh.hardakers.net>

>>>>> On Tue, 6 Dec 2011 12:39:34 -0500, Dorian Kim <dorian at blackrose.org> said:

DK> There is one good reason. Every vendor seem to assign a junior intern to
DK> maintanining SNMP code, so you are interfacing with your router via a very 
DK> suspect interface. 

The marking folks believed that when X dollars had to be spent, most
folks would rather buy a box where .99X was spent on a "new spiffy routing
feature" rather than on a manageable device.  To change that, people
need to start writing RFPs very very differently so that more points
(dollars) are given to boxes that have consistent, standardized
management interfaces rather than to boxes with new feature Z.
Unfortunately, I don't have high hopes for that as institutions don't
make money from having manageable networks.  They make money from having
fast and furious networks and that's what drives industry progress.

[note: I'm not saying this is right or wrong; just that it's true.  I
could argue, and have, both sides quite effectively]
-- 
Wes Hardaker                                     


From mtinka at globaltransit.net  Wed Dec  7 00:56:15 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 7 Dec 2011 14:56:15 +0800
Subject: Internet Edge and Defense in Depth
In-Reply-To: <201112071159.02647.mtinka@globaltransit.net>
References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o>
 <alpine.DEB.2.00.1112070910270.8973@castor.opentrend.net>
 <201112071159.02647.mtinka@globaltransit.net>
Message-ID: <201112071456.19899.mtinka@globaltransit.net>

On Wednesday, December 07, 2011 11:58:59 AM Mark Tinka 
wrote:

> But on a large scale, we've not been one to buy into
> multi- chassis-type arrangements.

s/multi-chassis-type/logical routers.

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/20111207/2c1ce4fb/attachment.bin>

From owen at delong.com  Wed Dec  7 01:35:06 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 6 Dec 2011 23:35:06 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <48621.1323224403@turing-police.cc.vt.edu>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
 <C1FC59BC-47C3-4BC3-AE78-A06CA1650A10@delong.com>
 <48621.1323224403@turing-police.cc.vt.edu>
Message-ID: <EF9A2C8B-95AB-40FC-A64F-B3B37B20F63C@delong.com>


On Dec 6, 2011, at 6:20 PM, <Valdis.Kletnieks at vt.edu> <Valdis.Kletnieks at vt.edu> wrote:

> On Tue, 06 Dec 2011 18:10:14 PST, Owen DeLong said:
> 
>> No, a Trojan is malware. Any software which operates without the
>> knowledge or consent of the user to engage in operations the user would
>> not reasonably expect is not being used for good, no matter how well
>> intentioned.
> 
> Strictly speaking, it's "without the knowledge or consent of the *owner*". Especially
> in corporate environments, "owner" != "user".

I would argue that the superset applies in a proper definition here.

Software which operates with the knowledge and consent of the owner, but, not the
knowledge or consent of the end-user is still, IMHO, nefarious at best.

Owen



From owen at delong.com  Wed Dec  7 01:43:20 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 6 Dec 2011 23:43:20 -0800
Subject: GPON Vendors
In-Reply-To: <201112071125.22810.mtinka@globaltransit.net>
References: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
 <201112071125.22810.mtinka@globaltransit.net>
Message-ID: <50C7EBA9-A4E7-46E2-BEBA-F6C11005E8E6@delong.com>

In any such vendor choice, I'd say make sure that they have workable
IPv6 before making any major investments. Otherwise, you've got a
dead-end platform that won't serve you very well for very many years.

Owen

On Dec 6, 2011, at 7:25 PM, Mark Tinka wrote:

> On Wednesday, December 07, 2011 03:52:20 AM Josh V. Hoppes 
> wrote:
> 
>> Due to unforeseen circumstances we need to consider
>> alternative vendors for our GPON system, moving away
>> from Motorola.  We wanted to throw out a line and find
>> out what other networks have deployed and what
>> experiences they have had positive or negative with
>> them. Thanks in advance for any replies.
> 
> We're using Huawei for this.
> 
> It's a stable system, and they do this quite well. Watch out 
> for the EMS though; it's great for management and 
> provisioning, but customer migration is not supported (yet).
> 
> The ONU that ships from Huawei is also not terribly good as 
> a clever CPE. So if you're thinking of doing interesting 
> things, suggest you use their ONU as a bridge and have 
> something else terminating the PPPoE/DHCP sessions.
> 
> Otherwise, I'd certainly recommend looking at Huawei for 
> this. We've been reasonably happy using them for our FTTH 
> and IPTv deployment.
> 
> Cheers,
> 
> Mark.



From owen at delong.com  Wed Dec  7 01:47:41 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 6 Dec 2011 23:47:41 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <765968889B724C4896CE5E38559C5E11@owner59e1f1502>
References: <20111205234419.GD1454@vacation.karoshi.com.>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <20111207041853.GL24540@syn.titan.net>
 <765968889B724C4896CE5E38559C5E11@owner59e1f1502>
Message-ID: <4781EB66-BFD6-4AED-B028-BAE727F3F26B@delong.com>

<Amused thought, may have no basis in law>

Could he send their hosting company a take-down order for the download.com site?

</Amused thought>

On Dec 6, 2011, at 8:53 PM, Michael Painter wrote:

> Fyodor wrote:
>> On Mon, Dec 05, 2011 at 10:14:48PM -0800, andrew.wallace wrote:
>>> Using fruitful language and acting like a child isn't going to see
>>> you taken seriously.
>> I'm sorry that my language offended you. But if you ever spend more
>> than 14 years creating free software as a gift to the community, only
>> to have it used as bait by a giant corporation to infect your users
>> with malware, then you may understand my rage.
>> The good news is that many users are sick and tired of having their
>> machines hijacked by malware.  Especially by CNET Download.Com, which
>> still says on their own adware policy page:
>> "In your letters, user reviews, and polls, you told us bundled
>>  adware was unacceptable--no matter how harmless it might be. We want
>>  you to know what you're getting when you download from CNET
>>  Download.com, and no other download site can promise that."
>>  --http://www.cnet.com/2723-13403_1-461-16.html
>> Um, what people WANT when they download Nmap is Nmap itself.  Not to
>> have their searches redirected to Bing and their home page changed to
>> Microsoft's MSN.
>> Speaking of which, Microsoft emailed me today.  They said that they
>> didn't know they were sponsoring CNET to trojan open source software,
>> and that they have stopped doing it.  But the trojan installer uses
>> your Internet connection to obtain more "special offers" from CNET,
>> and they immediately switched to installing a "Babylon toolbar" and
>> search engine redirect instead.  Then CNET removed that and are now
>> promoting their own "techtracker" tool.  Apparently the heat is so
>> high that even malware vendors are refusing to have any more part in
>> CNET's antics!  But if CNET isn't stopped, the malware vendors will
>> come crawling back eventually and CNET will be there to receive them.
>> There have been dozens of news articles in the last day and hundreds
>> of outraged comments on blogs, Twitter, Facebook, etc.  In the midst
>> of all this terrible PR, Download.com went in last night and quietly
>> switched their Nmap downloads back to our real installer.  At least
>> for now.  But that isn't enough--they are still infecting the
>> installers for thousands of other packages!  For example, they have
>> currently infected the installer for a children's coloring book app:
>> http://download.cnet.com/Kea-Coloring-Book/3000-2102_4-10360620.html
>> Have they no shame at all??!
>> I've created a page with the situation background, links to the news
>> articles, and the latest updates:
>> http://insecure.org/news/download-com-fiasco.html
>> Feel free to share it.  Together, I hope we can get Download.Com to
>> apologize and cease this reprehensible behavior!
>> Cheers,
>> Fyodor
> 
> No, there's no shame when money's involved.
> Do Unto Others as they would do unto you...sue the fsck out of them.
> --Michael
> 



From jared at puck.nether.net  Wed Dec  7 01:55:47 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 7 Dec 2011 02:55:47 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <4781EB66-BFD6-4AED-B028-BAE727F3F26B@delong.com>
References: <20111205234419.GD1454@vacation.karoshi.com.>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <20111207041853.GL24540@syn.titan.net>
 <765968889B724C4896CE5E38559C5E11@owner59e1f1502>
 <4781EB66-BFD6-4AED-B028-BAE727F3F26B@delong.com>
Message-ID: <741ADD38-9F5C-4CD6-BAB8-DC571133A4DB@puck.nether.net>


On Dec 7, 2011, at 2:47 AM, Owen DeLong wrote:

> <Amused thought, may have no basis in law>
> 
> Could he send their hosting company a take-down order for the download.com site?
> 
> </Amused thought>

Might be feasible to take over the domain if SOPA were passed :)

I am glad that CBS Interactive/CNET has started to see the light, here is hoping there will be subsequent corrective actions taken.

- Jared

From mtinka at globaltransit.net  Wed Dec  7 02:45:59 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 7 Dec 2011 16:45:59 +0800
Subject: GPON Vendors
In-Reply-To: <50C7EBA9-A4E7-46E2-BEBA-F6C11005E8E6@delong.com>
References: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
 <201112071125.22810.mtinka@globaltransit.net>
 <50C7EBA9-A4E7-46E2-BEBA-F6C11005E8E6@delong.com>
Message-ID: <201112071646.02408.mtinka@globaltransit.net>

On Wednesday, December 07, 2011 03:43:20 PM Owen DeLong 
wrote:

> In any such vendor choice, I'd say make sure that they
> have workable IPv6 before making any major investments.
> Otherwise, you've got a dead-end platform that won't
> serve you very well for very many years.

GPON deployment for FTTH tends to be, really, an Ethernet 
switch. There is just additional intelligence thrown in to 
keep the thing from being suicidal at Layer 2 for that many 
customers when doing typical consumer broadband.

If you're using the GPON AN as as a regular switch, i.e., 
one VLAN per customer, then you can roll IPv6 to your FTTH 
customers just as you would on a Cisco Catalyst switch, for 
example.

But most operators are using them for broadband deployments, 
and the split horizon mechanisms implemented as part of the 
Broadband Forum spec. for GPON make it unintuitive that v6 
be supported off the bat for DHCP and PPPoE. Of course, this 
isn't rocket science, and just needs to be added in software 
- a problem many vendors are suffering from. As we do with 
all of them, keep pushing for support for the features you 
need in v6. Just make sure you don't buy a dud.

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/20111207/5a4c3630/attachment.bin>

From mtinka at globaltransit.net  Wed Dec  7 03:10:35 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 7 Dec 2011 17:10:35 +0800
Subject: Martian 128.0.0.0/16 - Fixed Releases in Junos
In-Reply-To: <4EDE3CF1.2070005@bogus.com>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <82zkf6t76h.fsf@mid.bfk.de> <4EDE3CF1.2070005@bogus.com>
Message-ID: <201112071710.35618.mtinka@globaltransit.net>

For those who might not be aware, an OS-level fix has been 
integrated into the following Junos releases:

	- 10.0R5
	- 10.4R8
	- 10.4R9
	- 11.1R7
	- 11.2R4
	- 11.3R3
	- 11.4R1
	- 11.4R2
	- 12.1R1

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/20111207/916af8ad/attachment.bin>

From Valdis.Kletnieks at vt.edu  Wed Dec  7 06:37:03 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 07 Dec 2011 07:37:03 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: Your message of "Tue, 06 Dec 2011 23:35:06 PST."
 <EF9A2C8B-95AB-40FC-A64F-B3B37B20F63C@delong.com>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
 <C1FC59BC-47C3-4BC3-AE78-A06CA1650A10@delong.com>
 <48621.1323224403@turing-police.cc.vt.edu>
 <EF9A2C8B-95AB-40FC-A64F-B3B37B20F63C@delong.com>
Message-ID: <16296.1323261423@turing-police.cc.vt.edu>

On Tue, 06 Dec 2011 23:35:06 PST, Owen DeLong said:
> Software which operates with the knowledge and consent of the owner, but, not the
> knowledge or consent of the end-user is still, IMHO, nefarious at best.

Yeah well... that horse left the barn once this company in Redmon released
an operating system that allows the AD admins to push GPO policy. ;)



-------------- 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/20111207/af149e6d/attachment.bin>

From owen at delong.com  Wed Dec  7 08:23:50 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 7 Dec 2011 06:23:50 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <16296.1323261423@turing-police.cc.vt.edu>
References: <20111205234419.GD1454@vacation.karoshi.com>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <9523.1323190086@turing-police.cc.vt.edu>
 <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com>
 <4EDEA429.2000709@bryanfields.net>
 <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com>
 <C1FC59BC-47C3-4BC3-AE78-A06CA1650A10@delong.com>
 <48621.1323224403@turing-police.cc.vt.edu>
 <EF9A2C8B-95AB-40FC-A64F-B3B37B20F63C@delong.com>
 <16296.1323261423@turing-police.cc.vt.edu>
Message-ID: <4977146B-6BC1-4D1D-ADD3-EE4EAFD30C8C@delong.com>


On Dec 7, 2011, at 4:37 AM, Valdis.Kletnieks at vt.edu wrote:

> On Tue, 06 Dec 2011 23:35:06 PST, Owen DeLong said:
>> Software which operates with the knowledge and consent of the owner, but, not the
>> knowledge or consent of the end-user is still, IMHO, nefarious at best.
> 
> Yeah well... that horse left the barn once this company in Redmon released
> an operating system that allows the AD admins to push GPO policy. ;)
> 
> 
> 

What makes you think I don't consider Windows to be malware?

Owen



From asmith at ursinus.edu  Wed Dec  7 08:34:58 2011
From: asmith at ursinus.edu (Smith, C. Aaron)
Date: Wed, 7 Dec 2011 09:34:58 -0500
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <20111207041853.GL24540@syn.titan.net>
References: <20111205234419.GD1454@vacation.karoshi.com.>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <20111207041853.GL24540@syn.titan.net>
Message-ID: <2246F8B902DEFB44B0A83C82D366F5521E70B1A33D@Exchange02.ursinus.local>

Fyodor,

Thanks for taking the fight to them.

A simple fan of nmap,
Aaron Smith
Ursinus College



From graham at g-rock.net  Wed Dec  7 08:39:08 2011
From: graham at g-rock.net (Graham Wooden)
Date: Wed, 07 Dec 2011 09:39:08 -0500
Subject: [OT] Domain Name broker
Message-ID: <20111207093908.z32zln7lco4kc8ko@webmail.iamforeverme.com>

Hi there,

Through one of our recent acquisitions, we have a domain name that we  
will be phasing out.  We believe there is some value to it and have  
already identified a fortune 100 company's business unit that is using  
the same name, who is using their country based tld.  Now, they may be  
completely happy with that, who knows - but would like to investigate  
with a broker to help reach out to them or help identify other  
potential buyers. A simple request out to them for a marketing contact  
has gone unaswered.

Anyone have any experience in selling a domain name through a broker  
service that helps identifing potential buyers?

Replies off list are welcomed.  Thanks,

-graham






From caldcv at gmail.com  Wed Dec  7 09:02:56 2011
From: caldcv at gmail.com (Chris)
Date: Wed, 7 Dec 2011 10:02:56 -0500
Subject: [OT] Domain Name broker
In-Reply-To: <20111207093908.z32zln7lco4kc8ko@webmail.iamforeverme.com>
References: <20111207093908.z32zln7lco4kc8ko@webmail.iamforeverme.com>
Message-ID: <CAPF5agfpj2SK_ojqPKeK-s7KU+M1js34y8gPK8ZbMLObUS6vnA@mail.gmail.com>

Auction it on Sedo because they will handle the escrow. I would avoid
selling it yourself because you'll just get scam artists and if it's
Fortune 500, definitely cash in.


From cmadams at hiwaay.net  Wed Dec  7 09:12:40 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 7 Dec 2011 09:12:40 -0600
Subject: New on RIPE Labs: The Curious Case of 128.0/16
In-Reply-To: <20111206153831.GA22818@hiwaay.net>
References: <4EDE2B7D.9050603@ripe.net> <20111206153831.GA22818@hiwaay.net>
Message-ID: <20111207151240.GA20080@hiwaay.net>

Once upon a time, Chris Adams <cmadams at hiwaay.net> said:
> Using RIPE's traceroute web interface, I can see that Sprint is
> filtering 128.0.0.0/16:

Sprint is now passing routes and traffic in 128.0.0.0/16.

-- 
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 graham at g-rock.net  Wed Dec  7 09:16:49 2011
From: graham at g-rock.net (=?utf-8?B?Z3JhaGFtQGctcm9jay5uZXQ=?=)
Date: Wed, 07 Dec 2011 10:16:49 -0500
Subject: =?utf-8?B?UmU6IFtPVF0gRG9tYWluIE5hbWUgYnJva2Vy?=
Message-ID: <mailman.67.1323271003.1870.nanog@nanog.org>

Looking at that path as well. Thanks Chris. 

Parent company of the target business unit is a fortune 100. 

Sent from my HTC on the Now Network from Sprint!

----- Reply message -----
From: "Chris" <caldcv at gmail.com>
Date: Wed, Dec 7, 2011 9:02 am
Subject: [OT] Domain Name broker
To: <nanog at nanog.org>

Auction it on Sedo because they will handle the escrow. I would avoid
selling it yourself because you'll just get scam artists and if it's
Fortune 500, definitely cash in.


From david at davidswafford.com  Tue Dec  6 05:16:10 2011
From: david at davidswafford.com (David Swafford)
Date: Tue, 6 Dec 2011 06:16:10 -0500
Subject: 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
Message-ID: <CAA8=vb7TN-TzMDcE-vR4Ky3UFpdQhjYhFohgL1wJGFeL77=F6w@mail.gmail.com>

Hi Alex,

In Dayton, Ohio, US, we are not seeing any 128... routes from TWTC (AS 4323).

In St. Louis, Ohio, US, we are seeing the 128.0.0.0/21 via Level 3 (AS 3356).


David Swafford,
Sr. Network Engineer, CareSource



On Mon, Dec 5, 2011 at 10:20 AM, Alex Le Heux <alexlh at ripe.net> wrote:
> Dear Colleagues,
>
> The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.
>
> All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.
>
> We urge everyone to change the default behaviour of their Juniper routers:
>
> set routing-options martians 128.0.0.0/16 orlonger allow
> set routing-options martians 191.255.0.0/16 orlonger allow
> set routing-options martians 223.255.255.0/24 exact allow
>
> 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:
>
> http://www.ris.ripe.net/debogon/
>
> To facilitate testing, the following prefixes are being announced:
>
> prefix ?pinagble address
>
> 128.0.0.0/16 ? ?128.0.0.1
> 128.0.8.0/21 ? ?128.0.8.1
> 128.0.24.0/24 ? 128.0.24.1
>
> Best regards,
>
> Alex Le Heux
> Policy Implementation Co-ordinator
> RIPE NCC


From alexlh at ripe.net  Mon Dec  5 09:48:39 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:48:39 +0100
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
Message-ID: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>

Dear Colleagues,

The correct prefix and pingable address list for the Debogonising Project is:

prefix	        pinagble address

128.0.0.0/21	128.0.0.1
128.0.24.0/24	128.0.24.1

Our apologies for the oversight.

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC


On Dec 5, 2011, at 16:20, Alex Le Heux wrote:

> Dear Colleagues,
> 
> The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.
> 
> All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.
> 
> We urge everyone to change the default behaviour of their Juniper routers:
> 
> set routing-options martians 128.0.0.0/16 orlonger allow
> set routing-options martians 191.255.0.0/16 orlonger allow
> set routing-options martians 223.255.255.0/24 exact allow
> 
> 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:
> 
> http://www.ris.ripe.net/debogon/
> 
> To facilitate testing, the following prefixes are being announced:
> 
> prefix	pinagble address
> 
> 128.0.0.0/16	128.0.0.1
> 128.0.8.0/21	128.0.8.1
> 128.0.24.0/24	128.0.24.1
> 
> Best regards,
> 
> Alex Le Heux
> Policy Implementation Co-ordinator
> RIPE NCC







From alexlh at ripe.net  Mon Dec  5 09:20:27 2011
From: alexlh at ripe.net (Alex Le Heux)
Date: Mon, 5 Dec 2011 16:20:27 +0100
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers
Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>

Dear Colleagues,

The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.

All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.

We urge everyone to change the default behaviour of their Juniper routers:

set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow

128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:

http://www.ris.ripe.net/debogon/

To facilitate testing, the following prefixes are being announced:

prefix	pinagble address

128.0.0.0/16	128.0.0.1
128.0.8.0/21	128.0.8.1
128.0.24.0/24	128.0.24.1

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC


From keegan.holley at sungard.com  Wed Dec  7 10:19:24 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 7 Dec 2011 11:19:24 -0500
Subject: Writable SNMP
In-Reply-To: <CAL9jLabyFBjukeZ9pqopTiDxj=zmSrWnPrvjzcuE+qAycTPFHg@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
 <CAL9jLabyFBjukeZ9pqopTiDxj=zmSrWnPrvjzcuE+qAycTPFHg@mail.gmail.com>
Message-ID: <CABO8Q6TsZssYOBGoWXcaxBB3SnNkDsaK48EG0Zq6uEt9uZj+aw@mail.gmail.com>

>
> > There's no reason one can't program a device with SNMP, the main issue
> IMHO
> > has always been what I dubbed "config drift".  You have your desired
> > configuration and variances that happen over time.  If you don't force
> > a 'wr mem' or similar event after you trigger a 'copy tftp run'
> operation,
> > you may have troubles that are not apparent if there is a power failure
> > or other lossage.  The boot-time parser doesn't interpret SNMP, it parses
> > text.  This and other reasons have made people fail-safe to using the
> language
> > most easily interpreted by the device.
>
> Yup, I think the OP was maybe getting at:
>  "Why can't I snmp configure my cisco/juniper/alteon device?"
>
> I took that to mean (probably naively?) that they also would validate
> configs and update drift out of the configuration. You CAN force a 'wr
> mem' via snmp as well, of course (in cisco world).
>

It was more curiosity.  I'm looking in to scripting and starting to get
tired of having to account for ssh/telnet, credentials, differences in
platforms and code from the same vendor and my various failed attempts to
do all of the above.  Most of the automation suites I've seen work via
logins, rancid,HP NA etc etc.  Although there are better programmers that
can and have made it work it still seems cumbersome to me. I've pretty much
made the assumption that writable SNMP was a bad idea but have never
actually tried it.  I was curious what others were using, netconf or just
scripted logins. I'm also fighting a losing battle to convince people that
netconf isn't evil.  It strikes me as odd that if I wanted to talk to a
database/website full of credit card and billing info there's a long list
of API's I could use, but if I wanted to talk to the router or firewall in
front of it I can only use ssh or telnet.

From keegan.holley at sungard.com  Wed Dec  7 10:29:46 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 7 Dec 2011 11:29:46 -0500
Subject: Writable SNMP
In-Reply-To: <CAL9jLaa8MMeooBPpQjKSna18-nLipzPf3fvbsi0PLEo=9peYWA@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <CABO8Q6TF9=okuKiyUvH9dZZBNPLjJFnzbXUP8VuU7WQL6EB4jA@mail.gmail.com>
 <CAL9jLaa8MMeooBPpQjKSna18-nLipzPf3fvbsi0PLEo=9peYWA@mail.gmail.com>
Message-ID: <CABO8Q6QMoNGaTgU1VxoWvP76F3XCJVhpnxGZHbTs0-cMw7_RRw@mail.gmail.com>

>
>
> > I can see the other comments about interactive commands and bulk
> > read/writes, but what's the harm of doing it on internet connected boxes
> vs.
> > non-internet boxes.  Just about everyone uses snmp reads in the interwebs
>
> I think the general feeling is that snmp is udp so it's spoofable and
> your perimeter acls will never be 100% (or rather, are you willing to
> risk them not being 100%?)
>

That's a given even though there's still the string to deny the spoofed
traffic someone could cause a fair amount of trouble if they knew what your
acl's look like.  That being said I don't think I've ever seen a company
that doesn't at least use SNMP for billing and basic monitoring and many
don't think to block it at their edge.  It's hard to convince someone to
change something that's been around for years though.  SNMP is flawed
though and enabling writes just makes it worse.

>
> > and as such filters it at their edges and hopefully on each platform.
> You'd
> > secure it the same way you'd secure readable SNMP I assume.
>
> read is 'painful', write can be downright deadly (to your SLAs).
>
> >>
> >> Also, who tests snmp WRITE in their code? at scale? for daily
> >> operations tasks?
> >
> >
> > lol, that could be a problem.
>
> yea, I bet the number of people that test, at scale/operations-pace,
> snmp WRITE is countable on a single hand.
>
> >>
> >> ... (didn't the snmp incident in 2002 teach us
> >> something?)
> >>
> > Please elaborate.
>
> <
> http://www.cisco.com/warp/public/707/cisco-sa-20010227-ios-snmp-ilmi.shtml
> >
>
> oh, 2001... memory lag :(
>

I don't remember hearing about this causing issues in a production network.
 According to the article you can just filter SNMP by IP which should be in
place anyway.  It's triggered by some sort of hidden string which would
make it malicious, unless I'm missing something.

In lieu of a software upgrade, a workaround can be applied to certain IOS
releases by disabling the ILMI community or "**ilmi*" view and applying an
access list to prevent unauthorized access to SNMP. Any affected system,
regardless of software release, may be protected by filtering SNMP traffic
at a network perimeter or on individual devices.

From blake at ispn.net  Wed Dec  7 10:57:13 2011
From: blake at ispn.net (Blake Hudson)
Date: Wed, 07 Dec 2011 10:57:13 -0600
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
Message-ID: <4EDF9AE9.9040700@ispn.net>

Yeah, that's an interesting one. We currently utilize netflow for this, 
but you also need to consider that netflix streaming is just port 80 www 
traffic. Because netflix uses CDNs, its difficult to pin down the 
traffic to specific hosts in the CDN and say that this traffic was 
netflix, while this traffic was the latest windows update (remember this 
is often a shared hosting platform). We've done our own testing and have 
come to a good solution which uses a combination of nbar, packet 
marking, and netflow to come to a conclusion. On a ~160Mbps link, 
netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest 
of the traffic is predominantly other forms of HTTP traffic (including 
other video streaming services).


Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
> Also checkout Adrian Cockcroft presentations on their architecture which
> describes how they use aws and CDns etc
>
> Martin
>
>


From gcroft at shoremortgage.com  Wed Dec  7 11:31:46 2011
From: gcroft at shoremortgage.com (Gregory Croft)
Date: Wed, 7 Dec 2011 12:31:46 -0500
Subject: BGP and Firewalls...
Message-ID: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>

Hi All, 

 

Does anyone have any experience with using firewalls as edge devices
when BGP is concerned? 

Specifically the Palo Alto series of devices. 

 

If so please contact me off list. 

 

Thank you. 

 

 

Thank you, 

Gregory S. Croft 

 

 


From morrowc.lists at gmail.com  Wed Dec  7 11:43:55 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 7 Dec 2011 12:43:55 -0500
Subject: BGP and Firewalls...
In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
Message-ID: <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>

On Wed, Dec 7, 2011 at 12:31 PM, Gregory Croft <gcroft at shoremortgage.com> wrote:
> Hi All,
>
>
>
> Does anyone have any experience with using firewalls as edge devices
> when BGP is concerned?
>
> Specifically the Palo Alto series of devices.

nokia/checkpoint has done this for ages. what's the problem you have?


From morrowc.lists at gmail.com  Wed Dec  7 11:51:29 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 7 Dec 2011 12:51:29 -0500
Subject: Writable SNMP
In-Reply-To: <CABO8Q6QMoNGaTgU1VxoWvP76F3XCJVhpnxGZHbTs0-cMw7_RRw@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <CABO8Q6TF9=okuKiyUvH9dZZBNPLjJFnzbXUP8VuU7WQL6EB4jA@mail.gmail.com>
 <CAL9jLaa8MMeooBPpQjKSna18-nLipzPf3fvbsi0PLEo=9peYWA@mail.gmail.com>
 <CABO8Q6QMoNGaTgU1VxoWvP76F3XCJVhpnxGZHbTs0-cMw7_RRw@mail.gmail.com>
Message-ID: <CAL9jLaaQPMJo+wc9wCchg8=tmQqjR0tkWzWo+PJbRz4Zcwz0JA@mail.gmail.com>

On Wed, Dec 7, 2011 at 11:29 AM, Keegan Holley
<keegan.holley at sungard.com> wrote:
>>
>> > I can see the other comments about interactive commands and bulk
>> > read/writes, but what's the harm of doing it on internet connected boxes
>> > vs.
>> > non-internet boxes.? Just about everyone uses snmp reads in the
>> > interwebs
>>
>> I think the general feeling is that snmp is udp so it's spoofable and
>> your perimeter acls will never be 100% (or rather, are you willing to
>> risk them not being 100%?)
>
>
> That's a given even though there's still the string to deny the spoofed
> traffic someone could cause a fair amount of trouble if they knew what your

so... be cautious here, the 'acl' on the community string is really
'who can use this string' you have to still process the packet to some
extent before you decide that the string doesn't match NMS1's ip
address :(

you need also to traffic filter (in Cisco CoPP, in Juniper
LoopbackFilter)... that said, someone can bomb your loopback with
'public' and just spoof the src to your NMS, or your NOC or ... all
easy to figure out :( (well the noc is at least :) ).

> acl's look like. ?That being said I don't think I've ever seen a company
> that doesn't at least use SNMP for billing and basic monitoring and many
> don't think to block it at their edge. ?It's hard to convince someone to

yea, RO though, at least... though still, you process the packets to
see 'oh yea, not my string' :(

> change something that's been around for years though. ?SNMP is flawed though
> and enabling writes just makes it worse.

yes.

>>
>>
>> > and as such filters it at their edges and hopefully on each platform.
>> > You'd
>> > secure it the same way you'd secure readable SNMP I assume.
>>
>> read is 'painful', write can be downright deadly (to your SLAs).
>>
>> >>
>> >> Also, who tests snmp WRITE in their code? at scale? for daily
>> >> operations tasks?
>> >
>> >
>> > lol, that could be a problem.
>>
>> yea, I bet the number of people that test, at scale/operations-pace,
>> snmp WRITE is countable on a single hand.
>>
>> >>
>> >> ... (didn't the snmp incident in 2002 teach us
>> >> something?)
>> >>
>> > Please elaborate.
>>
>>
>> <http://www.cisco.com/warp/public/707/cisco-sa-20010227-ios-snmp-ilmi.shtml>
>>
>> oh, 2001... memory lag :(
>
>
> I don't remember hearing about this causing issues in a production network.

There were lots of people with things changing on their devices
without their knowledge :(

> ?According to the article you can just filter SNMP by IP which should be in
> place anyway. ?It's triggered by some sort of hidden string which would make
> it malicious, unless I'm missing something.

yep, just 'hey there's a hidden community string, which isn't supposed
to actually be available outside the local box, and is RW... whoops!
the intern made it available :('

coupled with the fact that 90% of the industry had the same roots for
snmp code;(

> In lieu of a software upgrade, a workaround can be applied to certain IOS
> releases by disabling the ILMI community or "*ilmi" view and applying an
> access list to prevent unauthorized access to SNMP. Any affected system,
> regardless of software release, may be protected by filtering SNMP traffic
> at a network perimeter or on individual devices.

right, but as I said above, the community-string restrictions don't
help you in cases where you haven't filtered source-addresses in
loopback/copp :( people still get to grind on your router's snmp
process, maybe there's another way in, maybe there's a bug in the
snmpd :(

-chris


From morrowc.lists at gmail.com  Wed Dec  7 11:53:01 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 7 Dec 2011 12:53:01 -0500
Subject: Writable SNMP
In-Reply-To: <CABO8Q6TsZssYOBGoWXcaxBB3SnNkDsaK48EG0Zq6uEt9uZj+aw@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
 <CAL9jLabyFBjukeZ9pqopTiDxj=zmSrWnPrvjzcuE+qAycTPFHg@mail.gmail.com>
 <CABO8Q6TsZssYOBGoWXcaxBB3SnNkDsaK48EG0Zq6uEt9uZj+aw@mail.gmail.com>
Message-ID: <CAL9jLaZ-PxAGA7aX9jy=uVgFLJDHKZ5wV_GcncWU=+=-7R0Zuw@mail.gmail.com>

On Wed, Dec 7, 2011 at 11:19 AM, Keegan Holley
<keegan.holley at sungard.com> wrote:
> It was more curiosity. ?I'm looking in to scripting and starting to get
> tired of having to account for ssh/telnet, credentials, differences in

'write a library'... someone once said.

> platforms and code from the same vendor and my various failed attempts to do
> all of the above. ?Most of the automation suites I've seen work via logins,
> rancid,HP NA etc etc. ?Although there are better programmers that can and
> have made it work it still seems cumbersome to me. I've pretty much made the

it is, somewhat, yes.

> assumption that writable SNMP was a bad idea but have never actually tried
> it. ?I was curious what others were using, netconf or just scripted logins.
> I'm also fighting a losing battle to convince people that netconf isn't
> evil. ?It strikes me as odd that if I wanted to talk to a database/website
> full of credit card and billing info there's a long list of API's I could
> use, but if I wanted to talk to the router or firewall in front of it I can
> only use ssh or telnet.

sad, right? there are millions of restful program writers, only a few
thousand network device programmers, and the vast majority of 'network
management' is done by people perfectly happy with 'cisco-works' :(


From gcroft at shoremortgage.com  Wed Dec  7 12:04:10 2011
From: gcroft at shoremortgage.com (Gregory Croft)
Date: Wed, 7 Dec 2011 13:04:10 -0500
Subject: BGP and Firewalls...
In-Reply-To: <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
 <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>
Message-ID: <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>

I'm not having problems... Well, not yet anyways.  :) 

Just investigating to see if there is a reason I shouldn't use a
firewall at the edge versus a dedicated router as well as to see if
anyone can share their specific experience with the PAN devices. 

Thanks everyone! 
Greg




-----Original Message-----
From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com]
On Behalf Of Christopher Morrow
Sent: Wednesday, December 07, 2011 12:44 PM
To: Gregory Croft
Cc: nanog at nanog.org
Subject: Re: BGP and Firewalls...

On Wed, Dec 7, 2011 at 12:31 PM, Gregory Croft
<gcroft at shoremortgage.com> wrote:
> Hi All,
>
>
>
> Does anyone have any experience with using firewalls as edge devices 
> when BGP is concerned?
>
> Specifically the Palo Alto series of devices.

nokia/checkpoint has done this for ages. what's the problem you have?


From dholmes at mwdh2o.com  Wed Dec  7 12:19:58 2011
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Wed, 7 Dec 2011 10:19:58 -0800
Subject: BGP and Firewalls...
In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
 <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>
 <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
Message-ID: <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o>

My concern is whether or not consolidating border router and firewall functions in the same device violates, if not explicitly, then the spirit of the "defense in depth" Internet edge design principle. Here is a link to a Department of Homeland Security document where this is discussed (for control systems, but has general application), but not addressed directly: http://www.inl.gov/technicalpublications/Documents/3375141.pdf

The old Checkpoint/Nokia firewalls consolidated routing and firewall functions, but the question is one of layered defenses, such that it seems intuitive that it is inherently more difficult for the bad actor to penetrate network defenses the more devices that have to be penetrated.



-----Original Message-----
From: Gregory Croft [mailto:gcroft at shoremortgage.com]
Sent: Wednesday, December 07, 2011 10:04 AM
To: Christopher Morrow
Cc: nanog at nanog.org
Subject: RE: BGP and Firewalls...

I'm not having problems... Well, not yet anyways.  :)

Just investigating to see if there is a reason I shouldn't use a
firewall at the edge versus a dedicated router as well as to see if
anyone can share their specific experience with the PAN devices.

Thanks everyone!
Greg




-----Original Message-----
From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com]
On Behalf Of Christopher Morrow
Sent: Wednesday, December 07, 2011 12:44 PM
To: Gregory Croft
Cc: nanog at nanog.org
Subject: Re: BGP and Firewalls...

On Wed, Dec 7, 2011 at 12:31 PM, Gregory Croft
<gcroft at shoremortgage.com> wrote:
> Hi All,
>
>
>
> Does anyone have any experience with using firewalls as edge devices
> when BGP is concerned?
>
> Specifically the Palo Alto series of devices.

nokia/checkpoint has done this for ages. what's the problem you have?


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 bicknell at ufp.org  Wed Dec  7 12:36:53 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 7 Dec 2011 10:36:53 -0800
Subject: BGP and Firewalls...
In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
 <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>
 <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
 <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o>
Message-ID: <20111207183653.GA98645@ussenterprise.ufp.org>

In a message written on Wed, Dec 07, 2011 at 10:19:58AM -0800, Holmes,David A wrote:
> My concern is whether or not consolidating border router and firewall functions in the same device violates, if not explicitly, then the spirit of the "defense in depth" Internet edge design principle. Here is a link to a Department of Homeland Security document where this is discussed (for control systems, but has general application), but not addressed directly: http://www.inl.gov/technicalpublications/Documents/3375141.pdf

I don't think you're looking at defense in depth in the right way,
and thus your question doesn't quite make sense.

If you look at the attack vector described in the paper you link
it shows what many of us in the ISP world call the "soft gooey
center".  As you see the attacker finds a way to bypass the corporate
firewall, and once inside the network there are no further controls
to prevent the attacker from hopping between corporate desktops,
corporate servers, and eventually a SCADA network.

Defense in depth is about internal compartmentalization.  The diagram
shows deploying additional firewalls between corporate LAN users
and corporate servers, and then again between corproate servers and
SCADA networks.  The idea is even if the attacker is able to bypass
one firewall, they have to pass through a second to get to another
zone.

Even with a defense in depth design with these multiple firewalls
(really, access control points), there is still the question you
ask, should the checkpoint devices be multiple boxes (e.g. firewall
and IDS in separate chassis) or unified boxes (firewall+IDS in a
single box).  It's really a totally orthogonal question.

What defense in depth does not allow you to do (from my understanding)
is consolidate these multiple firewall functions into one large
virtual firewall, because then you're back to a single point of
failure/control.

To summarize, "defense in depth" requires access control and
monitoring between different security zones, and that those access
control devices be not shared with devices handling other zones.
The devices themselves can include multiple functions on a single
device without affecting the strategy.

Is stacking functions on one device a good idea?  Well, millions of
residential users do it (firewall+ids+ips all in one), and plenty of
corporate users have had trouble scaling all in one devices.  Multiple
devices provides greater opportunity to select best in breed, but adds
more failure points and more things to manage and coorolate.  Which
tradeoffs are best for you and your network is something that can't be
easily answered with a rule, or by someone else on the Internet.

-- 
       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/20111207/153ea901/attachment.bin>

From frnkblk at iname.com  Wed Dec  7 13:10:31 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Wed, 7 Dec 2011 13:10:31 -0600
Subject: GPON Vendors
In-Reply-To: <201112071646.02408.mtinka@globaltransit.net>
References: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
 <201112071125.22810.mtinka@globaltransit.net>
 <50C7EBA9-A4E7-46E2-BEBA-F6C11005E8E6@delong.com>
 <201112071646.02408.mtinka@globaltransit.net>
Message-ID: <01cf01ccb513$e3f54590$abdfd0b0$@iname.com>

In late August Calix came to our site and tested their IPv6 support on the
C7 platform for their upcoming 8.0 release.  They tested both on GPON and
VDSL2 using the N:1 (VLAN per service) approach.  There were some issues
that prevented all the CPE I had from working, but since then they've taken
it back and completed that work.  I've invited them back onsite to re-test
so we can validate before they begin their controlled release.

Frank

-----Original Message-----
From: Mark Tinka [mailto:mtinka at globaltransit.net] 
Sent: Wednesday, December 07, 2011 2:46 AM
To: Owen DeLong
Cc: nanog at nanog.org
Subject: Re: GPON Vendors

On Wednesday, December 07, 2011 03:43:20 PM Owen DeLong 
wrote:

> In any such vendor choice, I'd say make sure that they
> have workable IPv6 before making any major investments.
> Otherwise, you've got a dead-end platform that won't
> serve you very well for very many years.

GPON deployment for FTTH tends to be, really, an Ethernet 
switch. There is just additional intelligence thrown in to 
keep the thing from being suicidal at Layer 2 for that many 
customers when doing typical consumer broadband.

If you're using the GPON AN as as a regular switch, i.e., 
one VLAN per customer, then you can roll IPv6 to your FTTH 
customers just as you would on a Cisco Catalyst switch, for 
example.

But most operators are using them for broadband deployments, 
and the split horizon mechanisms implemented as part of the 
Broadband Forum spec. for GPON make it unintuitive that v6 
be supported off the bat for DHCP and PPPoE. Of course, this 
isn't rocket science, and just needs to be added in software 
- a problem many vendors are suffering from. As we do with 
all of them, keep pushing for support for the features you 
need in v6. Just make sure you don't buy a dud.

Mark.



From morrowc.lists at gmail.com  Wed Dec  7 14:43:44 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 7 Dec 2011 15:43:44 -0500
Subject: BGP and Firewalls...
In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
 <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>
 <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
Message-ID: <CAL9jLaZ_fP+cho6nZHvpc+Bf3ZMnez-dQ2UibRJn3qnFkdTg8g@mail.gmail.com>

On Wed, Dec 7, 2011 at 1:04 PM, Gregory Croft <gcroft at shoremortgage.com> wrote:
> I'm not having problems... Well, not yet anyways. ?:)
>
> Just investigating to see if there is a reason I shouldn't use a
> firewall at the edge versus a dedicated router as well as to see if
> anyone can share their specific experience with the PAN devices.

do you have power or space concerns?
do you want to have a single point of failure?
do you want to have some limitations in what your devices can effectively do?

you probably want to be able to fail the firewall and maintain some
level of access to the site (the router), you may want to fail the
router but still maintain local network services from the router
south.

don't put all your eggs in one basket, unless you only have 1 U of
space and 1 power plug.


From rcarpen at network1.net  Wed Dec  7 15:54:13 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Wed, 07 Dec 2011 16:54:13 -0500 (EST)
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <43c838e2-d866-4d4b-ac6c-31b8f90c7246@zimbra.network1.net>
Message-ID: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>


Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco?

I successfully have cisco-cisco and juniper-juniper without problems.

When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me.


-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1
----



From randy at psg.com  Wed Dec  7 16:02:30 2011
From: randy at psg.com (Randy Bush)
Date: Thu, 08 Dec 2011 07:02:30 +0900
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
References: <43c838e2-d866-4d4b-ac6c-31b8f90c7246@zimbra.network1.net>
 <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
Message-ID: <m24nxchwg9.wl%randy@psg.com>

> When I am trying to peer to one of my upstreams (who has cisco) with
> my Juniper SRX, They are seeing the link-local address as the
> next-hop

use global v6 addresses


From rcarpen at network1.net  Wed Dec  7 16:09:48 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Wed, 07 Dec 2011 17:09:48 -0500 (EST)
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <m24nxchwg9.wl%randy@psg.com>
Message-ID: <fcda76ae-b05b-4592-ab24-cfb4b04ae952@zimbra.network1.net>


We are using global addresses, but on the Cisco side, it is seeing the Link-Local as the next-hop.


-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1
----

----- Original Message -----
> > When I am trying to peer to one of my upstreams (who has cisco)
> > with
> > my Juniper SRX, They are seeing the link-local address as the
> > next-hop
> 
> use global v6 addresses
> 
> 


From galu at packetdam.com  Wed Dec  7 16:27:49 2011
From: galu at packetdam.com (Vlad Galu)
Date: Wed, 07 Dec 2011 22:27:49 +0000
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
References: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
Message-ID: <4EDFE865.2040304@packetdam.com>

Randy Carpenter wrote:
> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco?
>
> I successfully have cisco-cisco and juniper-juniper without problems.
>
> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me.
>

Any reasons against exchanging v6 prefixes over a v4 session?


From rcarpen at network1.net  Wed Dec  7 16:30:24 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Wed, 07 Dec 2011 17:30:24 -0500 (EST)
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <4EDFE865.2040304@packetdam.com>
Message-ID: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net>


BGP is working fine, it is when they are trying to forward the packets back to me. They are seeing the Link-Local as the next-hop, which, for some reason, they cannot get to.


-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1
----

----- Original Message -----
> Randy Carpenter wrote:
> > Does anyone have any suggestions on setting up BGP peering between
> > Juniper (SRX) and Cisco?
> >
> > I successfully have cisco-cisco and juniper-juniper without
> > problems.
> >
> > When I am trying to peer to one of my upstreams (who has cisco)
> > with my Juniper SRX, They are seeing the link-local address as the
> > next-hop, but are unable to get an ND entry for it, and thus
> > cannot forward traffic to me.
> >
> 
> Any reasons against exchanging v6 prefixes over a v4 session?
> 
> 


From jeroen at mompl.net  Wed Dec  7 16:32:32 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 07 Dec 2011 14:32:32 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <20111207041853.GL24540@syn.titan.net>
References: <20111205234419.GD1454@vacation.karoshi.com.>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <20111207041853.GL24540@syn.titan.net>
Message-ID: <4EDFE980.10407@mompl.net>

Fyodor wrote:
> switched their Nmap downloads back to our real installer.  At least
> for now.  But that isn't enough--they are still infecting the
> installers for thousands of other packages!  

I am sorry about these problems, it is unacceptable.

Sourceforge, at least a year or 2 ago, did something that was only
slightly less unacceptable. They had (or still have?) ads that would
display when you click a donwload link at some site, say
http://www.clamwin.com/content/view/18/46/

In this example (and clamwin had no part in that) the redirect of the
download link would show an add for another virus scanner (but in fact
it was malware, or, so broken it'd behave like malware). I know of
actual cases where someone accidentally downloaded the software from the
add, and messed up their computer.

So much for pointing them to a free virus scanner...

-- 
Earthquake Magnitude: 3.1
Date: Wednesday, December  7, 2011 15:57:44 UTC
Location: northern Alaska
Latitude: 65.9462; Longitude: -148.7381
Depth: 30.90 km



From galu at packetdam.com  Wed Dec  7 16:34:51 2011
From: galu at packetdam.com (Vlad Galu)
Date: Wed, 07 Dec 2011 22:34:51 +0000
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net>
References: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net>
Message-ID: <4EDFEA0B.8040506@packetdam.com>

Randy Carpenter wrote:
> BGP is working fine, it is when they are trying to forward the packets back to me. They are seeing the Link-Local as the next-hop, which, for some reason, they cannot get to.
>
>
> -Randy

Sorry Randy, I'd skimmed through your initial mail too quickly and 
missed the point.


From jbates at brightok.net  Wed Dec  7 16:42:33 2011
From: jbates at brightok.net (Jack Bates)
Date: Wed, 07 Dec 2011 16:42:33 -0600
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net>
References: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net>
Message-ID: <4EDFEBD9.7060806@brightok.net>



On 12/7/2011 4:30 PM, Randy Carpenter wrote:
>
> BGP is working fine, it is when they are trying to forward the packets back to me. They are seeing the Link-Local as the next-hop, which, for some reason, they cannot get to.
>
>

Your subject is misleading. It appears to be an NDP problem. Check 
configs and firewall rules on both sides to make sure NDP isn't being 
interrupted.

I've not seen any NDP compatibility problems between IOS 12.2SR, 12.3T, 
and Junos 9.3, 9.6, 10.4. However, there are several vendor commands as 
well as firewall rulesets, which could NDP itself.


Jack



From bicknell at ufp.org  Wed Dec  7 16:50:48 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 7 Dec 2011 14:50:48 -0800
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <4EDFEBD9.7060806@brightok.net>
 <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
References: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net>
 <4EDFEBD9.7060806@brightok.net>
 <43c838e2-d866-4d4b-ac6c-31b8f90c7246@zimbra.network1.net>
 <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
Message-ID: <20111207225048.GA8250@ussenterprise.ufp.org>

In a message written on Wed, Dec 07, 2011 at 04:54:13PM -0500, Randy Carpenter wrote:
> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco?

In a message written on Wed, Dec 07, 2011 at 04:42:33PM -0600, Jack Bates wrote:
> Your subject is misleading. It appears to be an NDP problem. Check 
> configs and firewall rules on both sides to make sure NDP isn't being 
> interrupted.

+1, although the original post may have a clue.

For those used to M and T series boxes configuring an SRX on the
command line you may be surprised to find a security {} top level
section with all new never seen before security policies that may,
for instance, block NDP.

-- 
       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/20111207/46063347/attachment.bin>

From jeroen at mompl.net  Wed Dec  7 16:52:31 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 07 Dec 2011 14:52:31 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <20111207041853.GL24540@syn.titan.net>
References: <20111205234419.GD1454@vacation.karoshi.com.>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <20111207041853.GL24540@syn.titan.net>
Message-ID: <4EDFEE2F.5090803@mompl.net>

Fyodor wrote:
> switched their Nmap downloads back to our real installer.  At least
> for now.  But that isn't enough--they are still infecting the
> installers for thousands of other packages!  

I am sorry about these problems, it is unacceptable.

Sourceforge, at least a year or 2 ago, did something that was only
slightly less unacceptable. They had (or still have?) ads that would
display when you click a donwload link at some site, say
http://www.clamwin.com/content/view/18/46/

In this example (and clamwin had no part in that) the redirect of the
download link would show an add for another virus scanner (but in fact
it was malware, or, so broken it'd behave like malware). I know of
actual cases where someone accidentally downloaded the software from the
add, and messed up their computer.

So much for pointing them to a free virus scanner...

-- 
Earthquake Magnitude: 3.1
Date: Wednesday, December  7, 2011 15:57:44 UTC
Location: northern Alaska
Latitude: 65.9462; Longitude: -148.7381
Depth: 30.90 km



From peter216 at gmail.com  Wed Dec  7 16:49:13 2011
From: peter216 at gmail.com (Peter Rubenstein)
Date: Wed, 7 Dec 2011 17:49:13 -0500
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
References: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
Message-ID: <-5313560550570988594@unknownmsgid>

Try setting local-address in the bgp neighbor config on the Juniper side?

--Peter

On Dec 7, 2011, at 4:54 PM, Randy Carpenter <rcarpen at network1.net> wrote:

>
> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco?
>
> I successfully have cisco-cisco and juniper-juniper without problems.
>
> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me.
>
>
> -Randy
>
> --
> | Randy Carpenter
> | Vice President - IT Services
> | Red Hat Certified Engineer
> | First Network Group, Inc.
> | (800)578-6381, Opt. 1
> ----
>
>


From owen at delong.com  Wed Dec  7 17:10:33 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 7 Dec 2011 15:10:33 -0800
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <4EDFE865.2040304@packetdam.com>
References: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
 <4EDFE865.2040304@packetdam.com>
Message-ID: <3CBC089D-6B61-405B-BF42-F38E951AF85C@delong.com>


On Dec 7, 2011, at 2:27 PM, Vlad Galu wrote:

> Randy Carpenter wrote:
>> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco?
>> 
>> I successfully have cisco-cisco and juniper-juniper without problems.
>> 
>> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me.
>> 
> 
> Any reasons against exchanging v6 prefixes over a v4 session?

Multiple single points of failure.
Complexity of the configuration
More difficult to troubleshoot
Unnecessary cross-protocol dependencies.

Just to name the ones that come to mind instantly.

Any reason for it?

Owen



From jra at baylink.com  Wed Dec  7 17:24:53 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 7 Dec 2011 18:24:53 -0500 (EST)
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <CAMG9zygV4R74o6OPDzH5_OxoMtLY8K-2L6YDe6giv5rvoKmp-g@mail.gmail.com>
Message-ID: <25640550.1899.1323300293410.JavaMail.root@benjamin.baylink.com>

Isn't it a little early for Whacky Weekend?

----- Original Message -----
> From: "Dan Collins" <enwpst47 at gmail.com>

> On Tue, Dec 6, 2011 at 4:45 PM, <Valdis.Kletnieks at vt.edu> wrote:
> > On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said:
> >> It could be argued that Nmap is malware, and such software has
> >> already been called to be made illegal.
> >
> > Called by whom, other than yourself?
> 
> Germany?
> 
> http://www.schneier.com/blog/archives/2007/08/new_german_hack.html

Perhaps.  But Valdis and you both misinterpreted what Andrew said: 
he said that "malware" has already been called to be made illegal --
he really only invited you to infer that he was in fact *making* the
argument that nmap was indeed malware, and you both bit beautifully.

Now PDFTT, people.

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 rcarpen at network1.net  Wed Dec  7 18:53:33 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Wed, 07 Dec 2011 19:53:33 -0500 (EST)
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <-5313560550570988594@unknownmsgid>
References: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
 <-5313560550570988594@unknownmsgid>
Message-ID: <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net>

Tried that. I agree with others that it is an NDP issue. NDP for the GUA is fine, but just not for the link local. Is there something that would block only link local by default?

I should add that I have another uplink to a different provider that works perfectly. The other end is Juniper for that one.

-Randy

On Dec 7, 2011, at 17:53, Peter Rubenstein <peter216 at gmail.com> wrote:

> Try setting local-address in the bgp neighbor config on the Juniper side?
> 
> --Peter
> 
> On Dec 7, 2011, at 4:54 PM, Randy Carpenter <rcarpen at network1.net> wrote:
> 
>> 
>> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco?
>> 
>> I successfully have cisco-cisco and juniper-juniper without problems.
>> 
>> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me.
>> 
>> 
>> -Randy
>> 
>> --
>> | Randy Carpenter
>> | Vice President - IT Services
>> | Red Hat Certified Engineer
>> | First Network Group, Inc.
>> | (800)578-6381, Opt. 1
>> ----
>> 
>> 
> 


From rdobbins at arbor.net  Wed Dec  7 21:03:27 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Thu, 8 Dec 2011 03:03:27 +0000
Subject: BGP and Firewalls...
In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
 <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>
 <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
Message-ID: <9113804F-09D0-44D4-8FF5-0564865785FA@arbor.net>


On Dec 8, 2011, at 1:04 AM, Gregory Croft wrote:

> Just investigating to see if there is a reason I shouldn't use a firewall at the edge versus a dedicated router 

You should only use a dedicate router if you want your network to remain available.

;>

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

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From streiner at cluebyfour.org  Wed Dec  7 21:35:43 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 7 Dec 2011 22:35:43 -0500 (EST)
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net>
References: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
 <-5313560550570988594@unknownmsgid>
 <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net>
Message-ID: <Pine.LNX.4.64.1112072231090.30173@whammy.cluebyfour.org>

On Wed, 7 Dec 2011, Randy Carpenter wrote:

> Tried that. I agree with others that it is an NDP issue. NDP for the 
> GUA is fine, but just not for the link local. Is there something that 
> would block only link local by default?

Do you have any possibly-overly-strict firewall filters applied to the 
interface on the Juniper box?

> I should add that I have another uplink to a different provider that 
> works perfectly. The other end is Juniper for that one.

I have IPv6 BGP sessions, using v6 addresses, up and traffic moving, using 
Juniper M-series on my end, and various gear on the remote end, including 
some Cisco devices.  Haven't run into any funky NDP-ish issues in the 3 
years it's been running.

have you opened a case with JTAC?

jms


From rdobbins at arbor.net  Wed Dec  7 21:43:34 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Thu, 8 Dec 2011 03:43:34 +0000
Subject: BGP and Firewalls...
In-Reply-To: <20111207183653.GA98645@ussenterprise.ufp.org>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
 <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>
 <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
 <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o>
 <20111207183653.GA98645@ussenterprise.ufp.org>
Message-ID: <D33F99D7-7299-4602-B0D4-8FC4A460C3C5@arbor.net>


On Dec 8, 2011, at 1:36 AM, Leo Bicknell wrote:

> I don't think you're looking at defense in depth in the right way,

Actually, it sometimes seems as if nobody in the industry understands what 'defense in depth' really means, heh.

'Defense in depth' is a military term of art which equates to 'trading space for time in order to facilitate attrition of enemy forces'.  It does not have any real relevance to infosec/opsec; unfortunately, its original meaning has been corrupted and so it is widely (and incorrectly) used in place of the more appropriate 'combined arms approach' or 'jointness' or 'mutual support' or 'layered defense' metaphors.  Hannibal's tactics at Cannae are generally cited as the canonical (pardon the pun) example of actual military defense in depth.

;>

-----------------------------------------------------------------------
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  Wed Dec  7 22:13:12 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Wed, 7 Dec 2011 20:13:12 -0800
Subject: BGP and Firewalls...
In-Reply-To: <D33F99D7-7299-4602-B0D4-8FC4A460C3C5@arbor.net>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
 <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>
 <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
 <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o>
 <20111207183653.GA98645@ussenterprise.ufp.org>
 <D33F99D7-7299-4602-B0D4-8FC4A460C3C5@arbor.net>
Message-ID: <CAD6AjGT8pQifstqFjABgMR8XzBP81jyHYhq3KvM1nvQC4qX=Qg@mail.gmail.com>

On Dec 7, 2011 7:49 PM, "Dobbins, Roland" <rdobbins at arbor.net> wrote:
>
>
> On Dec 8, 2011, at 1:36 AM, Leo Bicknell wrote:
>
> > I don't think you're looking at defense in depth in the right way,
>
> Actually, it sometimes seems as if nobody in the industry understands
what 'defense in depth' really means, heh.
>

On a personal note , it is one of my least favorite terms because it is
overused and generally used by people selling things, and defense in depth
means throw eveything and the kitchen sink at the problem instead of
matching threats / risks / vulnerabilities with security controls and
threat mitigation and management.

Defense in depth = blank check , in too many instances

Yes, layers of security are good.

No, a car with mattresses strapped to both ends is not safer to drive.

Cb

> 'Defense in depth' is a military term of art which equates to 'trading
space for time in order to facilitate attrition of enemy forces'.  It does
not have any real relevance to infosec/opsec; unfortunately, its original
meaning has been corrupted and so it is widely (and incorrectly) used in
place of the more appropriate 'combined arms approach' or 'jointness' or
'mutual support' or 'layered defense' metaphors.  Hannibal's tactics at
Cannae are generally cited as the canonical (pardon the pun) example of
actual military defense in depth.
>
> ;>
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>                The basis of optimism is sheer terror.
>
>                          -- Oscar Wilde
>
>

From streiner at cluebyfour.org  Wed Dec  7 22:50:43 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 7 Dec 2011 23:50:43 -0500 (EST)
Subject: BGP and Firewalls...
In-Reply-To: <CAD6AjGT8pQifstqFjABgMR8XzBP81jyHYhq3KvM1nvQC4qX=Qg@mail.gmail.com>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
 <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>
 <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
 <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o>
 <20111207183653.GA98645@ussenterprise.ufp.org>
 <D33F99D7-7299-4602-B0D4-8FC4A460C3C5@arbor.net>
 <CAD6AjGT8pQifstqFjABgMR8XzBP81jyHYhq3KvM1nvQC4qX=Qg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1112072334320.30173@whammy.cluebyfour.org>

On Wed, 7 Dec 2011, Cameron Byrne wrote:

> On a personal note , it is one of my least favorite terms because it is
> overused and generally used by people selling things, and defense in depth
> means throw eveything and the kitchen sink at the problem instead of
> matching threats / risks / vulnerabilities with security controls and
> threat mitigation and management.

It's something that is used all too often as a handy verbal crutch in 
sales pitches.  I'm wondering how long it is before the text below is lifted 
verbatim and put into some vendors' sales/marketing materials.

"Our security products are truly best-of-breed - we take defense in depth 
to a whole new level that none of our competitors can match.  We have the 
breadth and depth of knowledge and a proven track record in the security 
space to exceed our customers' expectations and deliver the optimum user 
experience.  We can leverage the synergies and cohesion that exist across 
our product line to tailor a set of deliverables to meet virtually any need."

*ducks* ;)

jms


From mtinka at globaltransit.net  Wed Dec  7 22:55:52 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Thu, 8 Dec 2011 12:55:52 +0800
Subject: GPON Vendors
In-Reply-To: <01cf01ccb513$e3f54590$abdfd0b0$@iname.com>
References: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
 <201112071646.02408.mtinka@globaltransit.net>
 <01cf01ccb513$e3f54590$abdfd0b0$@iname.com>
Message-ID: <201112081255.58300.mtinka@globaltransit.net>

On Thursday, December 08, 2011 03:10:31 AM Frank Bulk wrote:

> In late August Calix came to our site and tested their
> IPv6 support on the C7 platform for their upcoming 8.0
> release.  They tested both on GPON and VDSL2 using the
> N:1 (VLAN per service) approach.  There were some issues
> that prevented all the CPE I had from working, but since
> then they've taken it back and completed that work. 
> I've invited them back onsite to re-test so we can
> validate before they begin their controlled release.

Sounds great.

Keep us posted as they develop the software. It would be 
interesting to see what issues arise in this area.

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/20111208/1cb6e1d9/attachment.bin>

From jtowne at slic.com  Wed Dec  7 22:58:03 2011
From: jtowne at slic.com (Jonathan Towne)
Date: Wed, 7 Dec 2011 23:58:03 -0500
Subject: GPON Vendors
In-Reply-To: <201112081255.58300.mtinka@globaltransit.net>
References: <A5731D651F134C44BE4B7C54E9C49071A3BA87@cfu-exc-02.cfu.local>
 <201112071646.02408.mtinka@globaltransit.net>
 <01cf01ccb513$e3f54590$abdfd0b0$@iname.com>
 <201112081255.58300.mtinka@globaltransit.net>
Message-ID: <20111208045801.GB13315@hijacked.us>

Indeed, I'm very interested in the outcome of this, as well.
I've been pestering my Calix SE for a long while about proper
IPv6 support.

-- Jonathan Towne

On Thu, Dec 08, 2011 at 12:55:52PM +0800, Mark Tinka scribbled:
# On Thursday, December 08, 2011 03:10:31 AM Frank Bulk wrote:
# 
# > In late August Calix came to our site and tested their
# > IPv6 support on the C7 platform for their upcoming 8.0
# > release.  They tested both on GPON and VDSL2 using the
# > N:1 (VLAN per service) approach.  There were some issues
# > that prevented all the CPE I had from working, but since
# > then they've taken it back and completed that work. 
# > I've invited them back onsite to re-test so we can
# > validate before they begin their controlled release.
# 
# Sounds great.
# 
# Keep us posted as they develop the software. It would be 
# interesting to see what issues arise in this area.
# 
# Mark.




From jbates at brightok.net  Thu Dec  8 00:42:26 2011
From: jbates at brightok.net (Jack Bates)
Date: Thu, 08 Dec 2011 00:42:26 -0600
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net>
References: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
 <-5313560550570988594@unknownmsgid>
 <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net>
Message-ID: <4EE05C52.7020607@brightok.net>

On 12/7/2011 6:53 PM, Randy Carpenter wrote:
> Tried that. I agree with others that it is an NDP issue. NDP for the GUA is fine, but just not for the link local. Is there something that would block only link local by default?
>
> I should add that I have another uplink to a different provider that works perfectly. The other end is Juniper for that one.
>

Might check the cisco provider to see if they have something weird on 
your interface filtering/config.

port mirroring ndp traffic or running ndp tracing flags might provide 
you with more clues.

You also mentioned success with cisco to cisco, but you were unclear if 
that was with the same cisco provider you are having problems with.

Another possibility for a workaround or additional testing is them 
placing a manual neighbor entry into the cisco. I've never tried it with 
a link-local, though.


Jack


From Skeeve at eintellego.net  Thu Dec  8 01:29:37 2011
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Thu, 8 Dec 2011 07:29:37 +0000
Subject: Juniper MX80 Virtual Chassis
Message-ID: <CB06B28E.50822%skeeve@eintellego.net>

Hey all,

Thought I'd ask here to see if anyone has heard.

In May 2010 Juniper announced that Virtual Chassis would be available in the MX80 platform in the second half of 2011.

Anyone know if it is still being planned for release or if its been removed from the platform features?

?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 vicky at geeks.net.np  Thu Dec  8 01:47:22 2011
From: vicky at geeks.net.np (Vicky Shrestha)
Date: Wed, 7 Dec 2011 23:47:22 -0800
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net>
References: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
 <-5313560550570988594@unknownmsgid>
 <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net>
Message-ID: <7E5ED5CC-121A-45F4-8315-47EB79703F2F@geeks.net.np>

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

On Dec 7, 2011, at 4:53 PM, Randy Carpenter wrote:

> Tried that. I agree with others that it is an NDP issue. NDP for the GUA is fine, but just not for the link local. Is there something that would block only link local by default?

We faced a problem with Cisco routers where it will have partial reachability over IPv6, in the same LAN. Looking further, We found that it was having problem with Neighbor solicitations.

The solution then was to remove the IPv6 configs from the interface and putting them back. This problem was quite unpredictable and we were unable to reproduce.


> I should add that I have another uplink to a different provider that works perfectly. The other end is Juniper for that one.
> 
> -Randy
> 
> On Dec 7, 2011, at 17:53, Peter Rubenstein <peter216 at gmail.com> wrote:
> 
>> Try setting local-address in the bgp neighbor config on the Juniper side?
>> 
>> --Peter
>> 
>> On Dec 7, 2011, at 4:54 PM, Randy Carpenter <rcarpen at network1.net> wrote:
>> 
>>> 
>>> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco?
>>> 
>>> I successfully have cisco-cisco and juniper-juniper without problems.
>>> 
>>> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me.
>>> 
>>> 
>>> -Randy
>>> 
>>> --
>>> | Randy Carpenter
>>> | Vice President - IT Services
>>> | Red Hat Certified Engineer
>>> | First Network Group, Inc.
>>> | (800)578-6381, Opt. 1
>>> ----
>>> 
>>> 
>> 
> 

Regards,


Vicky Shrestha

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

iQEcBAEBAgAGBQJO4GuKAAoJEGi4SIJCvhMLpjYIAIhTUjsmoy9TSqKayfITZFJZ
DtDaNq+l/GUxmfUecsacbmEQmS0iXbj66Lm400JvKsO9hPjUbpN73jJM/GqT45Gl
DWF6+jqVfC+Nes/FUylS0kcWxWDjehETpfo3IO3kuA5hJQ0ELHyiVU1ReHwtCkoV
Zy4HHP0spfO4g6KORZqEtHa6tM13QGZg7CLOCHaUJi8IVl3quCnrn/oUyjcl1PFI
dNwlY1pr22ArA4TgKzKUimUNNxLhjld+UsIdAdyf7xN3HN9Ki6gqsnXiuAqFWPqW
E2lA4ViKwOHwyaE82iSAGl9A9qcrPJd7lCVGbiP9aW9Y2ZcS4kVEZkc3gXPkiAg=
=253w
-----END PGP SIGNATURE-----


From jeroen at mompl.net  Thu Dec  8 03:32:06 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Thu, 08 Dec 2011 01:32:06 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <20111207041853.GL24540@syn.titan.net>
References: <20111205234419.GD1454@vacation.karoshi.com.>
 <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com>
 <20111207041853.GL24540@syn.titan.net>
Message-ID: <4EE08416.3020702@mompl.net>

Fyodor wrote:
> switched their Nmap downloads back to our real installer.  At least
> for now.  But that isn't enough--they are still infecting the
> installers for thousands of other packages!  

I am sorry about these problems, it is unacceptable.

Sourceforge, at least a year or 2 ago, did something that was only
slightly less unacceptable. They had (or still have?) ads that would
display when you click a donwload link at some site, say
http://www.clamwin.com/content/view/18/46/

In this example (and clamwin had no part in that) the redirect of the
download link would show an add for another virus scanner (but in fact
it was malware, or, so broken it'd behave like malware). I know of
actual cases where someone accidentally downloaded the software from the
add, and messed up their computer.

So much for pointing them to a free virus scanner...

-- 
Earthquake Magnitude: 3.1
Date: Wednesday, December  7, 2011 15:57:44 UTC
Location: northern Alaska
Latitude: 65.9462; Longitude: -148.7381
Depth: 30.90 km




From bhmccie at gmail.com  Thu Dec  8 08:24:29 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 08 Dec 2011 08:24:29 -0600
Subject: BGP and Firewalls...
In-Reply-To: <D33F99D7-7299-4602-B0D4-8FC4A460C3C5@arbor.net>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
 <CAL9jLaZmt=9Px-DQYFN7H6Vq1cSk=wyhVE+Y-QMc7_Js-mOZ0g@mail.gmail.com>
 <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com>
 <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o>
 <20111207183653.GA98645@ussenterprise.ufp.org>
 <D33F99D7-7299-4602-B0D4-8FC4A460C3C5@arbor.net>
Message-ID: <4EE0C89D.3040400@gmail.com>

Roland,
     While I understand that the definition has nothing to do with IT 
Security there is no question that many folks use the phrase to 
summarize a layered IT security model.

Edge routers with ACLs to filter white noise go to edge L3/4 firewalls 
to filter their layer go to load balancers to terminate SSL (not really 
security I know) which go to L7 firewalls to inspect HTTP just to get to 
the web server. Then you have the whole layered DMZs for the 
WEBs/APPs/DBs/inside etc. We employ "defense in depth" and everyone is 
familiar with the concept even if they are using the phrase incorrectly. 
And our wonderful federal auditors expect it and call it the same thing.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 12/07/2011 09:43 PM, Dobbins, Roland wrote:
> On Dec 8, 2011, at 1:36 AM, Leo Bicknell wrote:
>
>    
>> I don't think you're looking at defense in depth in the right way,
>>      
> Actually, it sometimes seems as if nobody in the industry understands what 'defense in depth' really means, heh.
>
> 'Defense in depth' is a military term of art which equates to 'trading space for time in order to facilitate attrition of enemy forces'.  It does not have any real relevance to infosec/opsec; unfortunately, its original meaning has been corrupted and so it is widely (and incorrectly) used in place of the more appropriate 'combined arms approach' or 'jointness' or 'mutual support' or 'layered defense' metaphors.  Hannibal's tactics at Cannae are generally cited as the canonical (pardon the pun) example of actual military defense in depth.
>
> ;>
>
> -----------------------------------------------------------------------
> Roland Dobbins<rdobbins at arbor.net>  //<http://www.arbornetworks.com>
>
> 		The basis of optimism is sheer terror.
>
> 			  -- Oscar Wilde
>
>
>    

From david at davidswafford.com  Thu Dec  8 08:49:36 2011
From: david at davidswafford.com (David)
Date: Thu, 8 Dec 2011 09:49:36 -0500
Subject: BGP and Firewalls...
In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
Message-ID: <76238EAE-2B76-41A1-9AB8-90A66DFB66CE@davidswafford.com>

I wouldn't do it.  We have 8 x PA-2050s and run into a lot of wierd bugs.... (just doing web filtering)

David

Sent from an email server.

On Dec 7, 2011, at 12:31 PM, "Gregory Croft" <gcroft at shoremortgage.com> wrote:

> Hi All, 
> 
> 
> 
> Does anyone have any experience with using firewalls as edge devices
> when BGP is concerned? 
> 
> Specifically the Palo Alto series of devices. 
> 
> 
> 
> If so please contact me off list. 
> 
> 
> 
> Thank you. 
> 
> 
> 
> 
> 
> Thank you, 
> 
> Gregory S. Croft 
> 
> 
> 
> 
> 


From righa.shake at gmail.com  Thu Dec  8 09:02:00 2011
From: righa.shake at gmail.com (Righa Shake)
Date: Thu, 8 Dec 2011 18:02:00 +0300
Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco
In-Reply-To: <4EDE8678.4070507@emanon.com>
References: <20111206130539.2DBEED9@resin04.mta.everyone.net>
 <4EDE8678.4070507@emanon.com>
Message-ID: <CAJO3Vzw=kzN7YzWYJmX=S62XRn8o4HrnMr0BVt1gDkbM+6yDEw@mail.gmail.com>

The interface finally stabalised.

This after performing segment by segment loop tests at SDH level.
We found errors which were sorted after which the service has been better
the random flaps have since disappeared.

Now dealing with random BGP cease notifications I receive from my upstream.

Thank you all for your assistance in helping solve this.

Regards,
Righa Shake




On Wed, Dec 7, 2011 at 12:17 AM, Scott Morris <swm at emanon.com> wrote:

> The mismatch problem of DCE/DTE should definitely indicate that your
> PVCs aren't up.  But that shouldn't result in the high quantity of CRC
> errors in the interface counters.  That should just result in your LMI
> enquiry count increasing with LMI response sitting at zero.
>
> I have to say I've never tried running frame-relay on a SONET
> interface.  And if you're only using a single PVC there, I'd certainly
> love to know WHY you're doing that!  :)
>
> But setting one side to DCE so that it'll respond to LMI will certainly
> make the frame-relay (L2) portion of things operate properly.  But if
> you have something else occurring causing the CRCs along the way, then
> that's not really going to help at all!
>
> Did anything else coincide with you changing the encapsulation?
>
> Scott
>
>
>
> On 12/6/11 4:05 PM, Scott Weeks wrote:
> > Did Jeff's suggestion work?
> >
> > : interface POS0/0/0
> > : frame-relay intf-type dce
> >
> > If so, please let the list know, so when someone comes
> > across this thread while searching for the fix they can
> > figure it out without having to email the list.  If it
> > didn't help contact me off-line and I will be happy to
> > troubleshoot it with you.
> >
> > scott
> >
> >
> >
> >
> >
> > ________________________________________
> > From: Righa Shake [righa.shake at gmail.com]
> > Sent: Saturday, November 19, 2011 11:11 AM
> > To: afnog at afnog.org
> > Subject: Flapping POS Interface on Frame-relay between a Juniper and
> Cisco
> >
> > Hi,
> >
> > Am having a problem that is buffling.
> >
> > I recently changed a POS link encapsulation from PPP to Frame-relay.
> > Since that time the POS interface keeps resetting from time to time.
> >
> > On my BGP session am receiving cease notifications from my upstream
> > provider.
> >
> > The setup is such that we have a cisco on one end and a Juniper on the
> > other.
> >
> > interface POS0/0/0
> >  mtu 4474
> >  no ip address
> >  no ip unreachables
> >  encapsulation frame-relay
> >  logging event link-status
> >  crc 32
> >  pos scramble-atm
> >  frame-relay lmi-type ansi
> > end
> >
> > ROUTERshow run int pos0/0/0.101
> > Building configuration...
> >
> >
> > !
> > interface POS0/0/0.101 point-to-point
> > ip address X.X.X.X 255.255.255.252
> > frame-relay interface-dlci 101
> > end
> >
> > ROUTER#show int pos0/0/0
> > POS0/0/0 is up, line protocol is up
> >   Hardware is SPA-2XOC12-POS
> >   MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec,
> >      reliability 255/255, txload 6/255, rxload 38/255
> >   Encapsulation FRAME-RELAY, crc 32, loopback not set
> >   Keepalive set (10 sec)
> >   Scramble enabled
> >   LMI enq sent  81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up
> >   LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
> >   LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE  segmentation
> > inactive
> >   FR SVC disabled, LAPF state down
> >   Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface
> broadcasts
> > 0
> >   Last input 00:00:00, output 00:00:00, output hang never
> >   Last clearing of "show interface" counters 1w2d
> >   Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
> >   Queueing strategy: fifo
> >   Output queue: 0/40 (size/max)
> >   5 minute input rate 94336000 bits/sec, 13151 packets/sec
> >   5 minute output rate 16470000 bits/sec, 7049 packets/sec
> >      12211574207 packets input, 10967607038364 bytes, 0 no buffer
> >      Received 0 broadcasts (0 IP multicasts)
> >      6970870 runts, 2179 giants, 0 throttles
> >               0 parity
> >      892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0
> ignored,
> > 3335463 abort
> >      6379191154 packets output, 1614018181446 bytes, 0 underruns
> >      0 output errors, 0 applique, 4 interface resets
> >      0 unknown protocol drops
> >      0 output buffer failures, 0 output buffers swapped out
> >      0 carrier transitions
> >
> >
> > Any assistance on this will be greatly appreciated.
> >
> >
> >
> >
> >
> >
> > --- jsaxe at briworks.com wrote:
> >
> > From: Jeff Saxe <jsaxe at briworks.com>
> >
> > I believe this is the explanation for your flapping: a PPP link is
> intended to go between two routers over, for instance, a private leased
> line, so both of the devices are peers, neither one particularly special.
> Frame-relay, by contrast, was originally designed so that your router was
> an "end user" device and its directly-connected partner device was not your
> other router, which you control, but the frame carrier's frame-relay
> switch. Your router was a DTE device, and their switch, which was in a more
> "important" position in control of the frame-relay NBMA cloud, was the DCE
> device. Your router then slaved to the frame switch via LMI signaling, so
> that the upstream switch instructed you which DLCIs existed and were up at
> the moment.
> >
> > So if you connect up two routers with frame-relay encap and each thinks
> it is the DTE, and neither one is taking the role of the frame switch, then
> when you bring them up, they will initially optimistically think their
> DLCIs are up and working, and the routing protocol and traffic will come
> up... but both of them will be waiting for the frame switch to send them
> LMI indicating that their idea of the DLCI up/down status is correct. When
> a couple minutes go by and they don't hear the responses to their LMI
> enquiries, they will bring all the DLCI's down. I thought they would then
> stay down forever, i.e., not flap, but maybe you are shutting / no shutting
> the POS circuit to try again. Anyway, I believe the very simple fix is
> >
> > interface POS0/0/0
> > frame-relay intf-type dce
> >
> > So this will turn your Cisco side of the circuit into "DCE" mode, and if
> the Juniper side stays in "DTE" mode (the default, so probably not listed
> in the config), then the LMI should start behaving between the two. And
> yes, as Jay Hennigan suggested, you might need to use "encap frame-relay
> ietf" to be compatible with non-Cisco gear, or you might need to adjust the
> frame-relay lmi-type -- one type sends the LMI on DLCI number 0, one of
> them on DLCI 1023, whatever. I think you'll need to adjust the two ends
> until you see LMI enquiries both sent and received; right now the "show
> interface" from the Cisco side shows it has not received any LMI enq yet.
> >
> >
> > Good luck, and I hope it's that simple.   :-)
> >
> >
> >
>
>
>

From betty at newnog.org  Thu Dec  8 12:44:58 2011
From: betty at newnog.org (Betty Burke <betty@nanog.org>)
Date: Thu, 8 Dec 2011 13:44:58 -0500
Subject: [NANOG-announce] NANOG 54 Hotel Update
Message-ID: <CABhExizCsaxaACN1Dwygy9PZEB_Udmn490iVHe6KiRhsXrExjw@mail.gmail.com>

Dear NANOG Community,

On behalf of the Board of Directors, I am happy to share some wonderful
news regarding hotel accommodations for our NANOG 54 meeting in San Diego.
The hotel has been undergoing renovations and recently completed remodeling
of all its guest rooms and meeting space. The last phase of the hotel
remodel will include the main lobby, which they plan to complete before our
meeting.

The Board has been working closely with the hotel to ensure the remodel
will have no effect on NANOG 54, scheduled for February 5 - 8, 2012. As a
result of our conversations, the hotel has agreed to reduce the individual
guest room rate from $199 +tax/ night to $169 + tax/night.   For
reservations already made, the hotel will make an adjustment to your daily
rate, reflecting the new NANOG 54 rate.

In addition, if you make your reservation by January 4th, 2012, you will be
entered into a drawing to win 10,000 Starwood Preferred Guest points!

For your reference, below please find a copy of the original letter from
the hotel.

We look forward to seeing you all in San Diego!

Sincerely,

Betty Burke,
Executive Director





Greetings from San Diego!


We are looking forward to welcoming you to America?s Finest City for the
NANOG Annual Meeting in February 2012.

Over the last year, The Westin Gaslamp Quarter has completed a refresh of
our guest rooms, meeting space and WestinWORKOUT?, and we are in the final
phase of our lobby renovation.  To celebrate and to help manage your travel
expense, we are happy to offer a discounted conference rate of $169 plus
tax (originally $199!)  For any reservations that have already been made,
we will reduce your confirmed rate for you.

Early Bird Special: If you make your reservation by January 4, 2012, you
will be entered into a drawing to win 10,000 Starwood Preferred Guest
points!


Be well,

Keri Robinson
General Manager
-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

From bogus@does.not.exist.com  Wed Dec  7 16:23:30 2011
From: bogus@does.not.exist.com ()
Date: Wed, 07 Dec 2011 22:23:30 -0000
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
Message-ID: <mailman.69.1323373462.1870.nanog@nanog.org>

Fyodor wrote:
> switched their Nmap downloads back to our real installer.  At least
> for now.  But that isn't enough--they are still infecting the
> installers for thousands of other packages!  

I am sorry about these problems, it is unacceptable.

Sourceforge, at least a year or 2 ago, did something that was only slightly less unacceptable. They had (or still have?) ads that would display when you click a donwload link at some site, say http://www.clamwin.com/content/view/18/46/

In this example (and clamwin had no part in that) the redirect of the download link would show an add for another virus scanner (but in fact it was malware, or, so broken it'd behave like malware). I know of actual cases where someone accidentally downloaded the software from the add, and messed up their computer.

So much for pointing them to a free virus scanner...

-- 
Earthquake Magnitude: 3.1
Date: Wednesday, December  7, 2011 15:57:44 UTC
Location: northern Alaska
Latitude: 65.9462; Longitude: -148.7381
Depth: 30.90 km


From tayeb.meftah at gmail.com  Wed Dec  7 13:12:42 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Wed, 7 Dec 2011 21:12:42 +0200
Subject: Traceroute explanation
Message-ID: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>

Hey folks,
i see a strange traceroute there

D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
avec un maximum de 30 sauts :

  1     2 ms     1 ms     1 ms  172.28.0.1
  2     1 ms     1 ms     1 ms  localhost [10.16.0.2]
  3    10 ms    10 ms    13 ms  41.200.16.1
  4    11 ms    10 ms    11 ms  172.17.2.25
  5    21 ms    21 ms    21 ms  213.140.58.10
  6    34 ms    31 ms    55 ms  pos14-0.palermo9.pal.seabone.net [195.22.197.125
]
  7    34 ms    33 ms    35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
  8   106 ms    68 ms    67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
  9    74 ms    73 ms    74 ms  ae-1-12.bar1.budapest1.level3.net [4.69.141.249]
 10    63 ms    63 ms    79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
 11    85 ms    84 ms    84 ms  v15-core1.stsisp.ro [193.151.28.1]
 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
 13    81 ms    81 ms    81 ms  193.231.72.10
 14    92 ms    92 ms    93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
 15    89 ms    89 ms    89 ms  webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7
2.52]
Itin?raire d?termin?.
C:\Documents and Settings\TAYEB>
Seabone, then level3, then Tinet, then level3, then tinet ?
if is that a routing stufs that i don't know, please let me know :)
i never saw that befaure

    Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213660347746


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


From ristic.sasa at gmail.com  Thu Dec  8 14:58:44 2011
From: ristic.sasa at gmail.com (Sasa Ristic)
Date: Thu, 8 Dec 2011 21:58:44 +0100
Subject: Traceroute explanation
In-Reply-To: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
Message-ID: <CAPVpXLxtZBfrXDcjmqv6McEvwS0ik6PEkqb6uzCEwq57hS_tXw@mail.gmail.com>

Hi,

nothing surprises me from Tinet any more... at one time all my traffic
from Europe was routed through some Hong Kong router of theirs...

but, enough jokes...

this could be the path the packets are traversing through, nothing
wrong with it, as long as everything is working fine... ie. packet
gets delivered to destination, and reply comes back, within reasonable
time frame... not like traveling across the globe...   :)


Regards,

On Wed, Dec 7, 2011 at 20:12, Meftah Tayeb <tayeb.meftah at gmail.com> wrote:
> Hey folks,
> i see a strange traceroute there
>
> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
> avec un maximum de 30 sauts :
>
> ?1 ? ? 2 ms ? ? 1 ms ? ? 1 ms ?172.28.0.1
> ?2 ? ? 1 ms ? ? 1 ms ? ? 1 ms ?localhost [10.16.0.2]
> ?3 ? ?10 ms ? ?10 ms ? ?13 ms ?41.200.16.1
> ?4 ? ?11 ms ? ?10 ms ? ?11 ms ?172.17.2.25
> ?5 ? ?21 ms ? ?21 ms ? ?21 ms ?213.140.58.10
> ?6 ? ?34 ms ? ?31 ms ? ?55 ms ?pos14-0.palermo9.pal.seabone.net [195.22.197.125
> ]
> ?7 ? ?34 ms ? ?33 ms ? ?35 ms ?ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
> ?8 ? 106 ms ? ?68 ms ? ?67 ms ?xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
> ?9 ? ?74 ms ? ?73 ms ? ?74 ms ?ae-1-12.bar1.budapest1.level3.net [4.69.141.249]
> ?10 ? ?63 ms ? ?63 ms ? ?79 ms ?euroweb-gw.ip4.tinet.net [77.67.66.154]
> ?11 ? ?85 ms ? ?84 ms ? ?84 ms ?v15-core1.stsisp.ro [193.151.28.1]
> ?12 ? 100 ms ? 100 ms ? 102 ms ?inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
> ?13 ? ?81 ms ? ?81 ms ? ?81 ms ?193.231.72.10
> ?14 ? ?92 ms ? ?92 ms ? ?93 ms ?ip4-89-238-225-90.euroweb.ro [89.238.225.90]
> ?15 ? ?89 ms ? ?89 ms ? ?89 ms ?webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7
> 2.52]
> Itin?raire d?termin?.
> C:\Documents and Settings\TAYEB>
> Seabone, then level3, then Tinet, then level3, then tinet ?
> if is that a routing stufs that i don't know, please let me know :)
> i never saw that befaure
>
> ? ?Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/
> phone: +21321656139
> Mobile: +213660347746
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>



-- 
ricky


From tayeb.meftah at gmail.com  Wed Dec  7 13:28:29 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Wed, 7 Dec 2011 21:28:29 +0200
Subject: Traceroute explanation
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
 <CAPVpXLxtZBfrXDcjmqv6McEvwS0ik6PEkqb6uzCEwq57hS_tXw@mail.gmail.com>
Message-ID: <2FD6D432C9294AC48791EA12083DA975@work>

yeah,
i'm ok with you for that
but the hell surprise is that i am going to telecom italia that i realy 
don't like anymore, Level3 aguin, then tinet, then level3, then tinet ?
that strange.

----- Original Message ----- 
From: "Sasa Ristic" <ristic.sasa at gmail.com>
To: <nanog at nanog.org>
Sent: Thursday, December 08, 2011 10:58 PM
Subject: Re: Traceroute explanation


Hi,

nothing surprises me from Tinet any more... at one time all my traffic
from Europe was routed through some Hong Kong router of theirs...

but, enough jokes...

this could be the path the packets are traversing through, nothing
wrong with it, as long as everything is working fine... ie. packet
gets delivered to destination, and reply comes back, within reasonable
time frame... not like traveling across the globe...   :)


Regards,

On Wed, Dec 7, 2011 at 20:12, Meftah Tayeb <tayeb.meftah at gmail.com> wrote:
> Hey folks,
> i see a strange traceroute there
>
> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
> avec un maximum de 30 sauts :
>
> 1 2 ms 1 ms 1 ms 172.28.0.1
> 2 1 ms 1 ms 1 ms localhost [10.16.0.2]
> 3 10 ms 10 ms 13 ms 41.200.16.1
> 4 11 ms 10 ms 11 ms 172.17.2.25
> 5 21 ms 21 ms 21 ms 213.140.58.10
> 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net [195.22.197.125
> ]
> 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
> 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
> 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net [4.69.141.249]
> 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154]
> 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1]
> 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
> 13 81 ms 81 ms 81 ms 193.231.72.10
> 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro [89.238.225.90]
> 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7
> 2.52]
> Itin?raire d?termin?.
> C:\Documents and Settings\TAYEB>
> Seabone, then level3, then Tinet, then level3, then tinet ?
> if is that a routing stufs that i don't know, please let me know :)
> i never saw that befaure
>
> Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/
> phone: +21321656139
> Mobile: +213660347746
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6695 (20111208) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>



-- 
ricky



__________ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From fred at cisco.com  Thu Dec  8 15:23:43 2011
From: fred at cisco.com (Fred Baker)
Date: Thu, 8 Dec 2011 14:23:43 -0700
Subject: Traceroute explanation
In-Reply-To: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
Message-ID: <E5169CA8-4554-41FA-9F34-F46ADD271F6C@cisco.com>

This is just a guess, but I'll bet the route changed while you were measuring it.

Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was

172.28.0.1 -> 10.16.0.2
           -> 41.200.16.1
           -> 172.17.2.25
           -> 213.140.58.10
           -> 195.22.195.125
           -> 4.69.151.13
           -> 213.200.68.61
           -> somewhere else

and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is

172.28.0.1 -> 10.16.0.2
           -> 41.200.16.1
           -> 172.17.2.25
           -> 213.140.58.10
           -> 195.22.195.125
           -> unknown
           -> unknown
           -> 4.69.141.249
           -> 77.67.66.154
           -> and so on

The effect would be to get a result like this.

Next time you see something like this, suggestion: repeat the traceroute and see what you get.


On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:

> Hey folks,
> i see a strange traceroute there
> 
> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
> avec un maximum de 30 sauts :
> 
>  1     2 ms     1 ms     1 ms  172.28.0.1
>  2     1 ms     1 ms     1 ms  localhost [10.16.0.2]
>  3    10 ms    10 ms    13 ms  41.200.16.1
>  4    11 ms    10 ms    11 ms  172.17.2.25
>  5    21 ms    21 ms    21 ms  213.140.58.10
>  6    34 ms    31 ms    55 ms  pos14-0.palermo9.pal.seabone.net [195.22.197.125
> ]
>  7    34 ms    33 ms    35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
>  8   106 ms    68 ms    67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>  9    74 ms    73 ms    74 ms  ae-1-12.bar1.budapest1.level3.net [4.69.141.249]
> 10    63 ms    63 ms    79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
> 11    85 ms    84 ms    84 ms  v15-core1.stsisp.ro [193.151.28.1]
> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
> 13    81 ms    81 ms    81 ms  193.231.72.10
> 14    92 ms    92 ms    93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
> 15    89 ms    89 ms    89 ms  webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7
> 2.52]
> Itin?raire d?termin?.
> C:\Documents and Settings\TAYEB>
> Seabone, then level3, then Tinet, then level3, then tinet ?
> if is that a routing stufs that i don't know, please let me know :)
> i never saw that befaure
> 
>    Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/ 
> phone: +21321656139
> Mobile: +213660347746
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 



From tayeb.meftah at gmail.com  Wed Dec  7 13:51:08 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Wed, 7 Dec 2011 21:51:08 +0200
Subject: Traceroute explanation
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
 <E5169CA8-4554-41FA-9F34-F46ADD271F6C@cisco.com>
Message-ID: <BA24CC8904B545D5AC25296C649AC715@work>

big thank for that
but, i am testing that for one day :)


----- Original Message ----- 
From: "Fred Baker" <fred at cisco.com>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: <nanog at nanog.org>
Sent: Thursday, December 08, 2011 11:23 PM
Subject: Re: Traceroute explanation


This is just a guess, but I'll bet the route changed while you were 
measuring it.

Traceroute sends a request, awaits a response, sends a request, ... Suppose 
that the route was

172.28.0.1 -> 10.16.0.2
           -> 41.200.16.1
           -> 172.17.2.25
           -> 213.140.58.10
           -> 195.22.195.125
           -> 4.69.151.13
           -> 213.200.68.61
           -> somewhere else

and after the test got that far, two systems got inserted into the path 
before level3, resulting in the route entering level3 at a different point, 
4.69.141.249. What you now have is

172.28.0.1 -> 10.16.0.2
           -> 41.200.16.1
           -> 172.17.2.25
           -> 213.140.58.10
           -> 195.22.195.125
           -> unknown
           -> unknown
           -> 4.69.141.249
           -> 77.67.66.154
           -> and so on

The effect would be to get a result like this.

Next time you see something like this, suggestion: repeat the traceroute and 
see what you get.


On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:

> Hey folks,
> i see a strange traceroute there
>
> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
> avec un maximum de 30 sauts :
>
>  1     2 ms     1 ms     1 ms  172.28.0.1
>  2     1 ms     1 ms     1 ms  localhost [10.16.0.2]
>  3    10 ms    10 ms    13 ms  41.200.16.1
>  4    11 ms    10 ms    11 ms  172.17.2.25
>  5    21 ms    21 ms    21 ms  213.140.58.10
>  6    34 ms    31 ms    55 ms  pos14-0.palermo9.pal.seabone.net 
> [195.22.197.125
> ]
>  7    34 ms    33 ms    35 ms  ae-5-6.bar2.marseille1.level3.net 
> [4.69.151.13]
>  8   106 ms    68 ms    67 ms  xe-1-1-0.mil10.ip4.tinet.net 
> [213.200.68.61]
>  9    74 ms    73 ms    74 ms  ae-1-12.bar1.budapest1.level3.net 
> [4.69.141.249]
> 10    63 ms    63 ms    79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
> 11    85 ms    84 ms    84 ms  v15-core1.stsisp.ro [193.151.28.1]
> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
> 13    81 ms    81 ms    81 ms  193.231.72.10
> 14    92 ms    92 ms    93 ms  ip4-89-238-225-90.euroweb.ro 
> [89.238.225.90]
> 15    89 ms    89 ms    89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
> [193.231.7
> 2.52]
> Itin?raire d?termin?.
> C:\Documents and Settings\TAYEB>
> Seabone, then level3, then Tinet, then level3, then tinet ?
> if is that a routing stufs that i don't know, please let me know :)
> i never saw that befaure
>
>    Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/
> phone: +21321656139
> Mobile: +213660347746
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6695 (20111208) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>



__________ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From smb at cs.columbia.edu  Thu Dec  8 15:33:09 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Thu, 8 Dec 2011 16:33:09 -0500
Subject: Traceroute explanation
In-Reply-To: <BA24CC8904B545D5AC25296C649AC715@work>
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
 <E5169CA8-4554-41FA-9F34-F46ADD271F6C@cisco.com>
 <BA24CC8904B545D5AC25296C649AC715@work>
Message-ID: <B43BBF1B-E4D0-4D9F-836D-E1FA553C148B@cs.columbia.edu>

On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote:

> big thank for that
> but, i am testing that for one day :)



Can you do an AStraceroute or manually translate those addresses into AS#s?  
That is, might level3 and tinet  be using multiple AS#s, in which case this
isn't unreasonable?





> 
> 
> ----- Original Message ----- From: "Fred Baker" <fred at cisco.com>
> To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
> Cc: <nanog at nanog.org>
> Sent: Thursday, December 08, 2011 11:23 PM
> Subject: Re: Traceroute explanation
> 
> 
> This is just a guess, but I'll bet the route changed while you were measuring it.
> 
> Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was
> 
> 172.28.0.1 -> 10.16.0.2
>          -> 41.200.16.1
>          -> 172.17.2.25
>          -> 213.140.58.10
>          -> 195.22.195.125
>          -> 4.69.151.13
>          -> 213.200.68.61
>          -> somewhere else
> 
> and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is
> 
> 172.28.0.1 -> 10.16.0.2
>          -> 41.200.16.1
>          -> 172.17.2.25
>          -> 213.140.58.10
>          -> 195.22.195.125
>          -> unknown
>          -> unknown
>          -> 4.69.141.249
>          -> 77.67.66.154
>          -> and so on
> 
> The effect would be to get a result like this.
> 
> Next time you see something like this, suggestion: repeat the traceroute and see what you get.
> 
> 
> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
> 
>> Hey folks,
>> i see a strange traceroute there
>> 
>> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
>> avec un maximum de 30 sauts :
>> 
>> 1     2 ms     1 ms     1 ms  172.28.0.1
>> 2     1 ms     1 ms     1 ms  localhost [10.16.0.2]
>> 3    10 ms    10 ms    13 ms  41.200.16.1
>> 4    11 ms    10 ms    11 ms  172.17.2.25
>> 5    21 ms    21 ms    21 ms  213.140.58.10
>> 6    34 ms    31 ms    55 ms  pos14-0.palermo9.pal.seabone.net [195.22.197.125
>> ]
>> 7    34 ms    33 ms    35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
>> 8   106 ms    68 ms    67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>> 9    74 ms    73 ms    74 ms  ae-1-12.bar1.budapest1.level3.net [4.69.141.249]
>> 10    63 ms    63 ms    79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>> 11    85 ms    84 ms    84 ms  v15-core1.stsisp.ro [193.151.28.1]
>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>> 13    81 ms    81 ms    81 ms  193.231.72.10
>> 14    92 ms    92 ms    93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
>> 15    89 ms    89 ms    89 ms  webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7
>> 2.52]
>> Itin?raire d?termin?.
>> C:\Documents and Settings\TAYEB>
>> Seabone, then level3, then Tinet, then level3, then tinet ?
>> if is that a routing stufs that i don't know, please let me know :)
>> i never saw that befaure
>> 
>>   Meftah Tayeb
>> IT Consulting
>> http://www.tmvoip.com/
>> phone: +21321656139
>> Mobile: +213660347746
>> 
>> 
>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From tayeb.meftah at gmail.com  Wed Dec  7 13:56:16 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Wed, 7 Dec 2011 21:56:16 +0200
Subject: Traceroute explanation
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
 <E5169CA8-4554-41FA-9F34-F46ADD271F6C@cisco.com>
 <BA24CC8904B545D5AC25296C649AC715@work>
 <B43BBF1B-E4D0-4D9F-836D-E1FA553C148B@cs.columbia.edu>
Message-ID: <9A5844D670E44A18B87B629A9E3848C0@work>

please tel me how to ?
i don't know astraceroute:)

----- Original Message ----- 
From: "Steven Bellovin" <smb at cs.columbia.edu>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: "Fred Baker" <fred at cisco.com>; <nanog at nanog.org>
Sent: Thursday, December 08, 2011 11:33 PM
Subject: Re: Traceroute explanation


On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote:

> big thank for that
> but, i am testing that for one day :)



Can you do an AStraceroute or manually translate those addresses into AS#s?
That is, might level3 and tinet  be using multiple AS#s, in which case this
isn't unreasonable?





>
>
> ----- Original Message ----- From: "Fred Baker" <fred at cisco.com>
> To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
> Cc: <nanog at nanog.org>
> Sent: Thursday, December 08, 2011 11:23 PM
> Subject: Re: Traceroute explanation
>
>
> This is just a guess, but I'll bet the route changed while you were 
> measuring it.
>
> Traceroute sends a request, awaits a response, sends a request, ... 
> Suppose that the route was
>
> 172.28.0.1 -> 10.16.0.2
>          -> 41.200.16.1
>          -> 172.17.2.25
>          -> 213.140.58.10
>          -> 195.22.195.125
>          -> 4.69.151.13
>          -> 213.200.68.61
>          -> somewhere else
>
> and after the test got that far, two systems got inserted into the path 
> before level3, resulting in the route entering level3 at a different 
> point, 4.69.141.249. What you now have is
>
> 172.28.0.1 -> 10.16.0.2
>          -> 41.200.16.1
>          -> 172.17.2.25
>          -> 213.140.58.10
>          -> 195.22.195.125
>          -> unknown
>          -> unknown
>          -> 4.69.141.249
>          -> 77.67.66.154
>          -> and so on
>
> The effect would be to get a result like this.
>
> Next time you see something like this, suggestion: repeat the traceroute 
> and see what you get.
>
>
> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
>
>> Hey folks,
>> i see a strange traceroute there
>>
>> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
>> avec un maximum de 30 sauts :
>>
>> 1     2 ms     1 ms     1 ms  172.28.0.1
>> 2     1 ms     1 ms     1 ms  localhost [10.16.0.2]
>> 3    10 ms    10 ms    13 ms  41.200.16.1
>> 4    11 ms    10 ms    11 ms  172.17.2.25
>> 5    21 ms    21 ms    21 ms  213.140.58.10
>> 6    34 ms    31 ms    55 ms  pos14-0.palermo9.pal.seabone.net 
>> [195.22.197.125
>> ]
>> 7    34 ms    33 ms    35 ms  ae-5-6.bar2.marseille1.level3.net 
>> [4.69.151.13]
>> 8   106 ms    68 ms    67 ms  xe-1-1-0.mil10.ip4.tinet.net 
>> [213.200.68.61]
>> 9    74 ms    73 ms    74 ms  ae-1-12.bar1.budapest1.level3.net 
>> [4.69.141.249]
>> 10    63 ms    63 ms    79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>> 11    85 ms    84 ms    84 ms  v15-core1.stsisp.ro [193.151.28.1]
>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>> 13    81 ms    81 ms    81 ms  193.231.72.10
>> 14    92 ms    92 ms    93 ms  ip4-89-238-225-90.euroweb.ro 
>> [89.238.225.90]
>> 15    89 ms    89 ms    89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
>> [193.231.7
>> 2.52]
>> Itin?raire d?termin?.
>> C:\Documents and Settings\TAYEB>
>> Seabone, then level3, then Tinet, then level3, then tinet ?
>> if is that a routing stufs that i don't know, please let me know :)
>> i never saw that befaure
>>
>>   Meftah Tayeb
>> IT Consulting
>> http://www.tmvoip.com/
>> phone: +21321656139
>> Mobile: +213660347746
>>
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus 
>> signature database 6695 (20111208) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6695 (20111208) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6695 (20111208) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
>


--Steve Bellovin, https://www.cs.columbia.edu/~smb







__________ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From harsha at cs.ucr.edu  Thu Dec  8 15:37:11 2011
From: harsha at cs.ucr.edu (Harsha V. Madhyastha)
Date: Thu, 8 Dec 2011 13:37:11 -0800
Subject: Traceroute explanation
In-Reply-To: <E5169CA8-4554-41FA-9F34-F46ADD271F6C@cisco.com>
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
 <E5169CA8-4554-41FA-9F34-F46ADD271F6C@cisco.com>
Message-ID: <92EC0281-B08C-43EF-8694-1D470FCE60F8@cs.ucr.edu>

Another explanation could be load balancing. As Fred mentioned, traceroute sends out different packets for different hops on the path and since these packets have different headers, load balancers on the path may hash packets with different TTL values on to different paths.

Check out http://www.paris-traceroute.net/ for more information.

--Harsha

On Dec 8, 2011, at 1:23 PM, Fred Baker wrote:

> This is just a guess, but I'll bet the route changed while you were measuring it.
> 
> Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was
> 
> 172.28.0.1 -> 10.16.0.2
>           -> 41.200.16.1
>           -> 172.17.2.25
>           -> 213.140.58.10
>           -> 195.22.195.125
>           -> 4.69.151.13
>           -> 213.200.68.61
>           -> somewhere else
> 
> and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is
> 
> 172.28.0.1 -> 10.16.0.2
>           -> 41.200.16.1
>           -> 172.17.2.25
>           -> 213.140.58.10
>           -> 195.22.195.125
>           -> unknown
>           -> unknown
>           -> 4.69.141.249
>           -> 77.67.66.154
>           -> and so on
> 
> The effect would be to get a result like this.
> 
> Next time you see something like this, suggestion: repeat the traceroute and see what you get.
> 
> 
> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
> 
>> Hey folks,
>> i see a strange traceroute there
>> 
>> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
>> avec un maximum de 30 sauts :
>> 
>> 1     2 ms     1 ms     1 ms  172.28.0.1
>> 2     1 ms     1 ms     1 ms  localhost [10.16.0.2]
>> 3    10 ms    10 ms    13 ms  41.200.16.1
>> 4    11 ms    10 ms    11 ms  172.17.2.25
>> 5    21 ms    21 ms    21 ms  213.140.58.10
>> 6    34 ms    31 ms    55 ms  pos14-0.palermo9.pal.seabone.net [195.22.197.125
>> ]
>> 7    34 ms    33 ms    35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
>> 8   106 ms    68 ms    67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>> 9    74 ms    73 ms    74 ms  ae-1-12.bar1.budapest1.level3.net [4.69.141.249]
>> 10    63 ms    63 ms    79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>> 11    85 ms    84 ms    84 ms  v15-core1.stsisp.ro [193.151.28.1]
>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>> 13    81 ms    81 ms    81 ms  193.231.72.10
>> 14    92 ms    92 ms    93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
>> 15    89 ms    89 ms    89 ms  webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7
>> 2.52]
>> Itin?raire d?termin?.
>> C:\Documents and Settings\TAYEB>
>> Seabone, then level3, then Tinet, then level3, then tinet ?
>> if is that a routing stufs that i don't know, please let me know :)
>> i never saw that befaure
>> 
>>   Meftah Tayeb
>> IT Consulting
>> http://www.tmvoip.com/ 
>> phone: +21321656139
>> Mobile: +213660347746
>> 
>> 
>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
> 
> 



From smb at cs.columbia.edu  Thu Dec  8 15:39:49 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Thu, 8 Dec 2011 16:39:49 -0500
Subject: Traceroute explanation
In-Reply-To: <9A5844D670E44A18B87B629A9E3848C0@work>
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
 <E5169CA8-4554-41FA-9F34-F46ADD271F6C@cisco.com>
 <BA24CC8904B545D5AC25296C649AC715@work>
 <B43BBF1B-E4D0-4D9F-836D-E1FA553C148B@cs.columbia.edu>
 <9A5844D670E44A18B87B629A9E3848C0@work>
Message-ID: <0A74E3F6-C110-4BA6-99E0-3166291CB587@cs.columbia.edu>

I don't know what platform you're using, but there's a separate command.  See
http://www.shrubbery.net/astraceroute/ .  If you're using Linux, there's probably
a package in your favorite repository.  There seem to be other variants floating
around the net.  If you're using Windows, I have no idea what's available.


On Dec 7, 2011, at 2:56 16PM, Meftah Tayeb wrote:

> please tel me how to ?
> i don't know astraceroute:)
> 
> ----- Original Message ----- From: "Steven Bellovin" <smb at cs.columbia.edu>
> To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
> Cc: "Fred Baker" <fred at cisco.com>; <nanog at nanog.org>
> Sent: Thursday, December 08, 2011 11:33 PM
> Subject: Re: Traceroute explanation
> 
> 
> On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote:
> 
>> big thank for that
>> but, i am testing that for one day :)
> 
> 
> 
> Can you do an AStraceroute or manually translate those addresses into AS#s?
> That is, might level3 and tinet  be using multiple AS#s, in which case this
> isn't unreasonable?
> 
> 
> 
> 
> 
>> 
>> 
>> ----- Original Message ----- From: "Fred Baker" <fred at cisco.com>
>> To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
>> Cc: <nanog at nanog.org>
>> Sent: Thursday, December 08, 2011 11:23 PM
>> Subject: Re: Traceroute explanation
>> 
>> 
>> This is just a guess, but I'll bet the route changed while you were measuring it.
>> 
>> Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was
>> 
>> 172.28.0.1 -> 10.16.0.2
>>         -> 41.200.16.1
>>         -> 172.17.2.25
>>         -> 213.140.58.10
>>         -> 195.22.195.125
>>         -> 4.69.151.13
>>         -> 213.200.68.61
>>         -> somewhere else
>> 
>> and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is
>> 
>> 172.28.0.1 -> 10.16.0.2
>>         -> 41.200.16.1
>>         -> 172.17.2.25
>>         -> 213.140.58.10
>>         -> 195.22.195.125
>>         -> unknown
>>         -> unknown
>>         -> 4.69.141.249
>>         -> 77.67.66.154
>>         -> and so on
>> 
>> The effect would be to get a result like this.
>> 
>> Next time you see something like this, suggestion: repeat the traceroute and see what you get.
>> 
>> 
>> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
>> 
>>> Hey folks,
>>> i see a strange traceroute there
>>> 
>>> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
>>> avec un maximum de 30 sauts :
>>> 
>>> 1     2 ms     1 ms     1 ms  172.28.0.1
>>> 2     1 ms     1 ms     1 ms  localhost [10.16.0.2]
>>> 3    10 ms    10 ms    13 ms  41.200.16.1
>>> 4    11 ms    10 ms    11 ms  172.17.2.25
>>> 5    21 ms    21 ms    21 ms  213.140.58.10
>>> 6    34 ms    31 ms    55 ms  pos14-0.palermo9.pal.seabone.net [195.22.197.125
>>> ]
>>> 7    34 ms    33 ms    35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
>>> 8   106 ms    68 ms    67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>>> 9    74 ms    73 ms    74 ms  ae-1-12.bar1.budapest1.level3.net [4.69.141.249]
>>> 10    63 ms    63 ms    79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>>> 11    85 ms    84 ms    84 ms  v15-core1.stsisp.ro [193.151.28.1]
>>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>>> 13    81 ms    81 ms    81 ms  193.231.72.10
>>> 14    92 ms    92 ms    93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
>>> 15    89 ms    89 ms    89 ms  webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7
>>> 2.52]
>>> Itin?raire d?termin?.
>>> C:\Documents and Settings\TAYEB>
>>> Seabone, then level3, then Tinet, then level3, then tinet ?
>>> if is that a routing stufs that i don't know, please let me know :)
>>> i never saw that befaure
>>> 
>>>  Meftah Tayeb
>>> IT Consulting
>>> http://www.tmvoip.com/
>>> phone: +21321656139
>>> Mobile: +213660347746
>>> 
>>> 
>>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
>>> 
>>> The message was checked by ESET NOD32 Antivirus.
>>> 
>>> http://www.eset.com
>>> 
>> 
>> 
>> 
>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
>> 
>> 
>> 
>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
>> 
>> 
>> 
>> 
> 
> 
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
> 
> 
> 
> 
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From raymond at prolocation.net  Thu Dec  8 15:40:10 2011
From: raymond at prolocation.net (Raymond Dijkxhoorn)
Date: Thu, 8 Dec 2011 22:40:10 +0100
Subject: Traceroute explanation
In-Reply-To: <9A5844D670E44A18B87B629A9E3848C0@work>
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
 <E5169CA8-4554-41FA-9F34-F46ADD271F6C@cisco.com>
 <BA24CC8904B545D5AC25296C649AC715@work>
 <B43BBF1B-E4D0-4D9F-836D-E1FA553C148B@cs.columbia.edu>
 <9A5844D670E44A18B87B629A9E3848C0@work>
Message-ID: <89151835-9FE8-49ED-8D17-2D1E3EDF70AC@prolocation.net>

Hai!

Check with lft or mtr ... 

Thanks,
Raymond Dijkxhoorn, Prolocation


Op 7 dec. 2011 om 20:56 heeft "Meftah Tayeb" <tayeb.meftah at gmail.com> het volgende geschreven:

> please tel me how to ?
> i don't know astraceroute:)
> 
> ----- Original Message ----- From: "Steven Bellovin" <smb at cs.columbia.edu>
> To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
> Cc: "Fred Baker" <fred at cisco.com>; <nanog at nanog.org>
> Sent: Thursday, December 08, 2011 11:33 PM
> Subject: Re: Traceroute explanation
> 
> 
> On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote:
> 
>> big thank for that
>> but, i am testing that for one day :)
> 
> 
> 
> Can you do an AStraceroute or manually translate those addresses into AS#s?
> That is, might level3 and tinet  be using multiple AS#s, in which case this
> isn't unreasonable?
> 
> 
> 
> 
> 
>> 
>> 
>> ----- Original Message ----- From: "Fred Baker" <fred at cisco.com>
>> To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
>> Cc: <nanog at nanog.org>
>> Sent: Thursday, December 08, 2011 11:23 PM
>> Subject: Re: Traceroute explanation
>> 
>> 
>> This is just a guess, but I'll bet the route changed while you were measuring it.
>> 
>> Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was
>> 
>> 172.28.0.1 -> 10.16.0.2
>>         -> 41.200.16.1
>>         -> 172.17.2.25
>>         -> 213.140.58.10
>>         -> 195.22.195.125
>>         -> 4.69.151.13
>>         -> 213.200.68.61
>>         -> somewhere else
>> 
>> and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is
>> 
>> 172.28.0.1 -> 10.16.0.2
>>         -> 41.200.16.1
>>         -> 172.17.2.25
>>         -> 213.140.58.10
>>         -> 195.22.195.125
>>         -> unknown
>>         -> unknown
>>         -> 4.69.141.249
>>         -> 77.67.66.154
>>         -> and so on
>> 
>> The effect would be to get a result like this.
>> 
>> Next time you see something like this, suggestion: repeat the traceroute and see what you get.
>> 
>> 
>> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
>> 
>>> Hey folks,
>>> i see a strange traceroute there
>>> 
>>> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
>>> avec un maximum de 30 sauts :
>>> 
>>> 1     2 ms     1 ms     1 ms  172.28.0.1
>>> 2     1 ms     1 ms     1 ms  localhost [10.16.0.2]
>>> 3    10 ms    10 ms    13 ms  41.200.16.1
>>> 4    11 ms    10 ms    11 ms  172.17.2.25
>>> 5    21 ms    21 ms    21 ms  213.140.58.10
>>> 6    34 ms    31 ms    55 ms  pos14-0.palermo9.pal.seabone.net [195.22.197.125
>>> ]
>>> 7    34 ms    33 ms    35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
>>> 8   106 ms    68 ms    67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>>> 9    74 ms    73 ms    74 ms  ae-1-12.bar1.budapest1.level3.net [4.69.141.249]
>>> 10    63 ms    63 ms    79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>>> 11    85 ms    84 ms    84 ms  v15-core1.stsisp.ro [193.151.28.1]
>>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>>> 13    81 ms    81 ms    81 ms  193.231.72.10
>>> 14    92 ms    92 ms    93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
>>> 15    89 ms    89 ms    89 ms  webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7
>>> 2.52]
>>> Itin?raire d?termin?.
>>> C:\Documents and Settings\TAYEB>
>>> Seabone, then level3, then Tinet, then level3, then tinet ?
>>> if is that a routing stufs that i don't know, please let me know :)
>>> i never saw that befaure
>>> 
>>>  Meftah Tayeb
>>> IT Consulting
>>> http://www.tmvoip.com/
>>> phone: +21321656139
>>> Mobile: +213660347746
>>> 
>>> 
>>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
>>> 
>>> The message was checked by ESET NOD32 Antivirus.
>>> 
>>> http://www.eset.com
>>> 
>> 
>> 
>> 
>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
>> 
>> 
>> 
>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
>> 
>> 
>> 
>> 
> 
> 
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
> 
> 
> 
> 
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 


From tayeb.meftah at gmail.com  Wed Dec  7 14:04:31 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Wed, 7 Dec 2011 22:04:31 +0200
Subject: Traceroute explanation
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
 <E5169CA8-4554-41FA-9F34-F46ADD271F6C@cisco.com>
 <BA24CC8904B545D5AC25296C649AC715@work>
 <B43BBF1B-E4D0-4D9F-836D-E1FA553C148B@cs.columbia.edu>
 <9A5844D670E44A18B87B629A9E3848C0@work>
 <89151835-9FE8-49ED-8D17-2D1E3EDF70AC@prolocation.net>
Message-ID: <2172512BA3A94DB498EDC8F9003A2856@work>

Using LFT:
root at debian:~# lft 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  172.28.1.1 (172.28.1.1)  0.798 ms  0.711 ms
 2  10.16.0.2 (10.16.0.2)  0.414 ms  0.331 ms
 3  41.200.16.1 (41.200.16.1)  11.400 ms  11.474 ms
 4  172.17.2.25 (172.17.2.25)  10.184 ms  11.322 ms
 5  213.140.58.10 (213.140.58.10)  11.264 ms  10.623 ms
 6  212.73.253.65 (212.73.253.65)  30.330 ms  32.391 ms
 7  ae-4-5.bar1.Marseille1.Level3.net (4.69.151.9)  32.177 ms  32.219 ms
 8  ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238)  42.160 ms  42.318 ms
root at debian:~# lft www.rri.ro
traceroute to www.rri.ro (193.231.72.52), 30 hops max, 60 byte packets
 1  172.28.1.1 (172.28.1.1)  0.819 ms  0.737 ms
 2  10.16.0.2 (10.16.0.2)  0.402 ms  0.335 ms
 3  41.200.16.1 (41.200.16.1)  10.592 ms  10.209 ms
 4  172.17.2.25 (172.17.2.25)  10.146 ms  10.559 ms
 5  213.140.58.10 (213.140.58.10)  11.258 ms  10.369 ms
 6  pos14-0.palermo9.pal.seabone.net (195.22.197.125)  30.817 ms  31.439 ms
 7  ae-5-6.bar2.Marseille1.Level3.net (4.69.151.13)  33.968 ms  31.395 ms
 8  ge-0-0-0.mil19.ip4.tinet.net (213.200.68.145)  57.178 ms 
xe-1-1-0.mil10.ip4.
tinet.net (213.200.68.61)  57.749 ms
 9  ae-1-12.bar1.Budapest1.Level3.net (4.69.141.249)  61.835 ms  62.317 ms
10  euroweb-gw.ip4.tinet.net (77.67.66.154)  61.361 ms  60.292 ms
11  v15-core1.stsisp.ro (193.151.28.1)  163.662 ms  144.245 ms
12  inet-crli1.qrli1.buh.ew.ro (81.24.28.226)  91.309 ms  89.880 ms
13  193.231.72.10 (193.231.72.10)  80.790 ms  79.354 ms
14  ip4-89-238-225-90.euroweb.ro (89.238.225.90)  91.067 ms  90.906 ms
15  webrri.rri.ro.72.231.193.in-addr.arpa (193.231.72.52)  79.196 ms  79.389 
ms
root at debian:~#

----- Original Message ----- 
From: "Raymond Dijkxhoorn" <raymond at prolocation.net>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: "Steven Bellovin" <smb at cs.columbia.edu>; <nanog at nanog.org>
Sent: Thursday, December 08, 2011 11:40 PM
Subject: Re: Traceroute explanation


Hai!

Check with lft or mtr ...

Thanks,
Raymond Dijkxhoorn, Prolocation


Op 7 dec. 2011 om 20:56 heeft "Meftah Tayeb" <tayeb.meftah at gmail.com> het 
volgende geschreven:

> please tel me how to ?
> i don't know astraceroute:)
>
> ----- Original Message ----- From: "Steven Bellovin" <smb at cs.columbia.edu>
> To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
> Cc: "Fred Baker" <fred at cisco.com>; <nanog at nanog.org>
> Sent: Thursday, December 08, 2011 11:33 PM
> Subject: Re: Traceroute explanation
>
>
> On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote:
>
>> big thank for that
>> but, i am testing that for one day :)
>
>
>
> Can you do an AStraceroute or manually translate those addresses into 
> AS#s?
> That is, might level3 and tinet  be using multiple AS#s, in which case 
> this
> isn't unreasonable?
>
>
>
>
>
>>
>>
>> ----- Original Message ----- From: "Fred Baker" <fred at cisco.com>
>> To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
>> Cc: <nanog at nanog.org>
>> Sent: Thursday, December 08, 2011 11:23 PM
>> Subject: Re: Traceroute explanation
>>
>>
>> This is just a guess, but I'll bet the route changed while you were 
>> measuring it.
>>
>> Traceroute sends a request, awaits a response, sends a request, ... 
>> Suppose that the route was
>>
>> 172.28.0.1 -> 10.16.0.2
>>         -> 41.200.16.1
>>         -> 172.17.2.25
>>         -> 213.140.58.10
>>         -> 195.22.195.125
>>         -> 4.69.151.13
>>         -> 213.200.68.61
>>         -> somewhere else
>>
>> and after the test got that far, two systems got inserted into the path 
>> before level3, resulting in the route entering level3 at a different 
>> point, 4.69.141.249. What you now have is
>>
>> 172.28.0.1 -> 10.16.0.2
>>         -> 41.200.16.1
>>         -> 172.17.2.25
>>         -> 213.140.58.10
>>         -> 195.22.195.125
>>         -> unknown
>>         -> unknown
>>         -> 4.69.141.249
>>         -> 77.67.66.154
>>         -> and so on
>>
>> The effect would be to get a result like this.
>>
>> Next time you see something like this, suggestion: repeat the traceroute 
>> and see what you get.
>>
>>
>> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
>>
>>> Hey folks,
>>> i see a strange traceroute there
>>>
>>> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52]
>>> avec un maximum de 30 sauts :
>>>
>>> 1     2 ms     1 ms     1 ms  172.28.0.1
>>> 2     1 ms     1 ms     1 ms  localhost [10.16.0.2]
>>> 3    10 ms    10 ms    13 ms  41.200.16.1
>>> 4    11 ms    10 ms    11 ms  172.17.2.25
>>> 5    21 ms    21 ms    21 ms  213.140.58.10
>>> 6    34 ms    31 ms    55 ms  pos14-0.palermo9.pal.seabone.net 
>>> [195.22.197.125
>>> ]
>>> 7    34 ms    33 ms    35 ms  ae-5-6.bar2.marseille1.level3.net 
>>> [4.69.151.13]
>>> 8   106 ms    68 ms    67 ms  xe-1-1-0.mil10.ip4.tinet.net 
>>> [213.200.68.61]
>>> 9    74 ms    73 ms    74 ms  ae-1-12.bar1.budapest1.level3.net 
>>> [4.69.141.249]
>>> 10    63 ms    63 ms    79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>>> 11    85 ms    84 ms    84 ms  v15-core1.stsisp.ro [193.151.28.1]
>>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>>> 13    81 ms    81 ms    81 ms  193.231.72.10
>>> 14    92 ms    92 ms    93 ms  ip4-89-238-225-90.euroweb.ro 
>>> [89.238.225.90]
>>> 15    89 ms    89 ms    89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
>>> [193.231.7
>>> 2.52]
>>> Itin?raire d?termin?.
>>> C:\Documents and Settings\TAYEB>
>>> Seabone, then level3, then Tinet, then level3, then tinet ?
>>> if is that a routing stufs that i don't know, please let me know :)
>>> i never saw that befaure
>>>
>>>  Meftah Tayeb
>>> IT Consulting
>>> http://www.tmvoip.com/
>>> phone: +21321656139
>>> Mobile: +213660347746
>>>
>>>
>>> __________ Information from ESET NOD32 Antivirus, version of virus 
>>> signature database 6695 (20111208) __________
>>>
>>> The message was checked by ESET NOD32 Antivirus.
>>>
>>> http://www.eset.com
>>>
>>
>>
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus 
>> signature database 6695 (20111208) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>>
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus 
>> signature database 6695 (20111208) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>>
>>
>>
>
>
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
>
>
>
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6695 (20111208) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6695 (20111208) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>


__________ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From raymond at prolocation.net  Thu Dec  8 16:19:57 2011
From: raymond at prolocation.net (Raymond Dijkxhoorn)
Date: Thu, 8 Dec 2011 23:19:57 +0100 (CET)
Subject: {Spam?} Re: Traceroute explanation
In-Reply-To: <2172512BA3A94DB498EDC8F9003A2856@work>
References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work>
 <E5169CA8-4554-41FA-9F34-F46ADD271F6C@cisco.com>
 <BA24CC8904B545D5AC25296C649AC715@work>
 <B43BBF1B-E4D0-4D9F-836D-E1FA553C148B@cs.columbia.edu>
 <9A5844D670E44A18B87B629A9E3848C0@work>
 <89151835-9FE8-49ED-8D17-2D1E3EDF70AC@prolocation.net>
 <2172512BA3A94DB498EDC8F9003A2856@work>
Message-ID: <alpine.LFD.2.00.1112082317380.30691@noc.prolocation.net>

Hi!

> Using LFT:
> root at debian:~# lft 8.8.8.8
> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> 1  172.28.1.1 (172.28.1.1)  0.798 ms  0.711 ms
> 2  10.16.0.2 (10.16.0.2)  0.414 ms  0.331 ms
> 3  41.200.16.1 (41.200.16.1)  11.400 ms  11.474 ms
> 4  172.17.2.25 (172.17.2.25)  10.184 ms  11.322 ms
> 5  213.140.58.10 (213.140.58.10)  11.264 ms  10.623 ms
> 6  212.73.253.65 (212.73.253.65)  30.330 ms  32.391 ms
> 7  ae-4-5.bar1.Marseille1.Level3.net (4.69.151.9)  32.177 ms  32.219 ms
> 8  ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238)  42.160 ms  42.318 ms

> root at debian:~# lft www.rri.ro
> traceroute to www.rri.ro (193.231.72.52), 30 hops max, 60 byte packets
> 1  172.28.1.1 (172.28.1.1)  0.819 ms  0.737 ms
> 2  10.16.0.2 (10.16.0.2)  0.402 ms  0.335 ms
> 3  41.200.16.1 (41.200.16.1)  10.592 ms  10.209 ms
> 4  172.17.2.25 (172.17.2.25)  10.146 ms  10.559 ms
> 5  213.140.58.10 (213.140.58.10)  11.258 ms  10.369 ms
> 6  pos14-0.palermo9.pal.seabone.net (195.22.197.125)  30.817 ms  31.439 ms
> 7  ae-5-6.bar2.Marseille1.Level3.net (4.69.151.13)  33.968 ms  31.395 ms
> 8  ge-0-0-0.mil19.ip4.tinet.net (213.200.68.145)  57.178 ms 
> xe-1-1-0.mil10.ip4.
> tinet.net (213.200.68.61)  57.749 ms
> 9  ae-1-12.bar1.Budapest1.Level3.net (4.69.141.249)  61.835 ms  62.317 ms
> 10  euroweb-gw.ip4.tinet.net (77.67.66.154)  61.361 ms  60.292 ms
> 11  v15-core1.stsisp.ro (193.151.28.1)  163.662 ms  144.245 ms
> 12  inet-crli1.qrli1.buh.ew.ro (81.24.28.226)  91.309 ms  89.880 ms
> 13  193.231.72.10 (193.231.72.10)  80.790 ms  79.354 ms
> 14  ip4-89-238-225-90.euroweb.ro (89.238.225.90)  91.067 ms  90.906 ms
> 15  webrri.rri.ro.72.231.193.in-addr.arpa (193.231.72.52)  79.196 ms  79.389 
> ms
> root at debian:~#

lft -A snows ASN also.

Example:

[root at lft ~]# lft -A www.rri.ro -d 80
Tracing .....................T
TTL LFT trace to webrri.rri.ro.72.231.193.in-addr.arpa 
(193.231.72.52):80/tcp
  1  [34108] vrrp-253.bbd.prolocation.net (95.128.88.253) 0.3/0.3ms
  2  [41887] breedband-delft-rc02-gige-1.prolocation.net (94.228.128.57) 
11.8/1.4ms
  3  [12871] gigabone10-3.prolocation.net (213.197.27.165) 1.3/1.4ms
  4  [1200] amx1.fra.ew.ro (195.69.144.121) 59.5/31.5ms
  5  [6663] inet-qrli1.crli1.buh.ew.ro (81.24.28.225) 38.1/38.1ms
  6  [6663] inet-crli1.qrli1.buh.ew.ro (81.24.28.226) 37.4/37.5ms
  7  [6663] qrli11.drli1.buh.ew.ro (81.24.28.242) 37.9/37.9ms
  8  [6663] ip4-89-238-225-90.euroweb.ro (89.238.225.90) 37.7/37.7ms
  9  [34808] 193.231.72.10 37.9/37.9ms
10  [34808] [target open] webrri.rri.ro.72.231.193.in-addr.arpa 
(193.231.72.52):80 37.8/38.0ms

Bye,
Raymond.



From pixitha.kyle at gmail.com  Thu Dec  8 17:48:46 2011
From: pixitha.kyle at gmail.com (Kyle Duren)
Date: Thu, 8 Dec 2011 15:48:46 -0800
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <4edd576f.858d2a0a.6293.6cacSMTPIN_ADDED@mx.google.com>
References: <4edd576f.858d2a0a.6293.6cacSMTPIN_ADDED@mx.google.com>
Message-ID: <CADehQgRHjD5h6RiA7Ur=f3v+R74tuQ0GhNYK8MH+qLDdaQR2GA@mail.gmail.com>

http://download.cnet.com/8301-2007_4-57338809-12/a-note-from-sean-regarding-the-download.com-installer/

In case no one saw this yet.

-Kyle

From tvhawaii at shaka.com  Thu Dec  8 19:00:26 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Thu, 8 Dec 2011 15:00:26 -1000
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
References: <4edd576f.858d2a0a.6293.6cacSMTPIN_ADDED@mx.google.com>
 <CADehQgRHjD5h6RiA7Ur=f3v+R74tuQ0GhNYK8MH+qLDdaQR2GA@mail.gmail.com>
Message-ID: <890D7664EF3C402B81F2F02D704FB6F7@owner59e1f1502>

Kyle Duren wrote:
> http://download.cnet.com/8301-2007_4-57338809-12/a-note-from-sean-regarding-the-download.com-installer/
>
> In case no one saw this yet.
>
> -Kyle

Sean's apology for their 'mistake' rings hollow.
They've had almost 4 months to implement a solution to rectify these 'mistakes', but chose to ignore it until the uproar 
caused by the nmap community.
http://www.extremetech.com/computing/93504-download-com-wraps-downloads-in-bloatware-lies-about-motivations

It's always about the Money.

--Michael 



From mysidia at gmail.com  Thu Dec  8 20:38:11 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 8 Dec 2011 20:38:11 -0600
Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap
 with malware!]
In-Reply-To: <890D7664EF3C402B81F2F02D704FB6F7@owner59e1f1502>
References: <4edd576f.858d2a0a.6293.6cacSMTPIN_ADDED@mx.google.com>
 <CADehQgRHjD5h6RiA7Ur=f3v+R74tuQ0GhNYK8MH+qLDdaQR2GA@mail.gmail.com>
 <890D7664EF3C402B81F2F02D704FB6F7@owner59e1f1502>
Message-ID: <CAAAwwbXFAk_u7L-kiorkXUePsmbvzt15At9yxWYBEAJeZMCrgQ@mail.gmail.com>

On Thu, Dec 8, 2011 at 7:00 PM, Michael Painter <tvhawaii at shaka.com> wrote:
> Sean's apology for their 'mistake' rings hollow.
> They've had almost 4 months to implement a solution to rectify these
> 'mistakes', but chose to ignore it until the uproar caused by the nmap
[snip]

I would say it doesn't read 'unhollow'   It's just plain inadequate
and doesn't do anything to settle the concerns,  whether you accept
the apology as sincere or not.  Yes, it is obviously a mistake...
but the clear  mistake is not a technical one of "bundling an open
source application";   the mistake is actually a bad decision. The
decision to "bundle" anything;  something they obviously haven't
admitted yet is a bad practice or failure in judgement.

Apparently they don't comprehend that, if you are a download
repository, you don't surprise your users by tampering with files,
regardless of whether the application is open source or proprietary.
Oh..  that they apologized about one thing, essentially means they
admit the existence of the other bad thing that they don't apologize
for.

Their explanation of the problem is they don't intend to bundle open
source software.
Well,  that implies there _ARE_  things they intend to tamper with the
file for by bundling in their own installer.  Otherwise they wouldn't
have written the bundling system in the first place.

I'm saying...  if  Download.com  wanted to continue to be a trusted
download site,
they shouldn't have been tampering with any author application files,
whether open source or not.
They got caught red-handed.

The de facto admission that they do ever,   has one simple implication...
Download.com  is simply not to be trusted,  anymore, to not bundle
executables with unknown software.


In my book,  nothing  download.com  does can redeem their trust at
this point,  they destroyed their sites and CNET's status permanently;
  end users need to be warned that they are no longer safe for any
download,  even "known programs",  period.


--
-JH


From matthew at matthew.at  Thu Dec  8 23:41:28 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 08 Dec 2011 21:41:28 -0800
Subject: seeking clueful assistance at speakeasy-now-megapath
Message-ID: <4EE19F88.5070504@matthew.at>

See subject. Contact me off-list please.

Matthew Kaufman


From furry13 at gmail.com  Fri Dec  9 01:14:07 2011
From: furry13 at gmail.com (Jen Linkova)
Date: Fri, 9 Dec 2011 18:14:07 +1100
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net>
References: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
 <-5313560550570988594@unknownmsgid>
 <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net>
Message-ID: <CAFU7BATdm3HASc91nZ8gC3fwYSOOkxUz8i-13XfWxx30OqwO3w@mail.gmail.com>

On Thu, Dec 8, 2011 at 11:53 AM, Randy Carpenter <rcarpen at network1.net> wrote:
> Tried that. I agree with others that it is an NDP issue. NDP for the GUA is fine, but just not for the link local. Is there something that would block only link local by default?
>
> I should add that I have another uplink to a different provider that works perfectly. The other end is Juniper for that one.

Just to begin with:
0) Does your Juniper device have the neighbor cache entry for Cisco
link-local address? What is the state of the entry?

Can you get packet capture on both sides?

1) is Cisco sending NS packets?
2) is your Juniper receiving them?
3) is Juniper device sending anything back?
4) are those NA reaching Cisco?

Any switch on the path?

[lazy mode on] I'd also suggest:
 - debug ipv6 nd on cisco
 - checking for bugs for IOS and JunOS versions you are using

> On Dec 7, 2011, at 17:53, Peter Rubenstein <peter216 at gmail.com> wrote:
>
>> Try setting local-address in the bgp neighbor config on the Juniper side?
>>
>> --Peter
>>
>> On Dec 7, 2011, at 4:54 PM, Randy Carpenter <rcarpen at network1.net> wrote:
>>
>>>
>>> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco?
>>>
>>> I successfully have cisco-cisco and juniper-juniper without problems.
>>>
>>> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me.
>>>
>>>
>>> -Randy
>>>
>>> --
>>> | Randy Carpenter
>>> | Vice President - IT Services
>>> | Red Hat Certified Engineer
>>> | First Network Group, Inc.
>>> | (800)578-6381, Opt. 1
>>> ----
>>>
>>>
>>
>



-- 
SY, Jen Linkova aka Furry


From furry13 at gmail.com  Fri Dec  9 06:57:39 2011
From: furry13 at gmail.com (Jen Linkova)
Date: Fri, 9 Dec 2011 23:57:39 +1100
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
References: <43c838e2-d866-4d4b-ac6c-31b8f90c7246@zimbra.network1.net>
 <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
Message-ID: <CAFU7BASaVth0suRGQqwGLHiAmZyV5TYhvwmcvu7GD+7Kc8oE7Q@mail.gmail.com>

On Thu, Dec 8, 2011 at 8:54 AM, Randy Carpenter <rcarpen at network1.net> wrote:
> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me.

on second thought - why are they using link-local as the next-hop in
the first place if the eBGP session is established over GUA?

-- 
SY, Jen Linkova aka Furry


From eric-list at truenet.com  Fri Dec  9 08:22:29 2011
From: eric-list at truenet.com (Eric Tykwinski)
Date: Fri, 9 Dec 2011 09:22:29 -0500
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers
In-Reply-To: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>
Message-ID: <00f701ccb67d$fbbda9e0$f338fda0$@truenet.com>

If anyone on Cogent is lurking, we are not receiving the announcements yet
in our BGP table.

Double checked on the looking glass, and it looks company wide.
http://www.cogentco.com/en/network/looking-glass

The space is seen through Level3...

Sincerely,

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

-----Original Message-----
From: Alex Le Heux [mailto:alexlh at ripe.net] 
Sent: Monday, December 05, 2011 10:49 AM
To: Routing WG
Cc: lacnog at lacnic.net; PacNOG List; nanog at nanog.org; menog at menog.net; UKNOF
List; SANOG List; ncc-announce at ripe.net; Address Policy Working Group; AfNOG
List
Subject: Re: [ncc-announce] 128.0.0.0/16 configured as martians in some
routers

Dear Colleagues,

The correct prefix and pingable address list for the Debogonising Project
is:

prefix	        pinagble address

128.0.0.0/21	128.0.0.1
128.0.24.0/24	128.0.24.1

Our apologies for the oversight.

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC



From mtinka at globaltransit.net  Fri Dec  9 08:45:03 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 9 Dec 2011 22:45:03 +0800
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <CAFU7BASaVth0suRGQqwGLHiAmZyV5TYhvwmcvu7GD+7Kc8oE7Q@mail.gmail.com>
References: <43c838e2-d866-4d4b-ac6c-31b8f90c7246@zimbra.network1.net>
 <f9ee2e41-7565-4a75-952b-32335ace80a2@zimbra.network1.net>
 <CAFU7BASaVth0suRGQqwGLHiAmZyV5TYhvwmcvu7GD+7Kc8oE7Q@mail.gmail.com>
Message-ID: <201112092245.07430.mtinka@globaltransit.net>

On Friday, December 09, 2011 08:57:39 PM Jen Linkova wrote:

> on second thought - why are they using link-local as the
> next-hop in the first place if the eBGP session is
> established over GUA?

This topic was heavily discussed on 'ipv6-ops' back in 
February. You may take a look here for all the details on 
this:

http://lists.cluenet.de/pipermail/ipv6-ops/2011-
February/004887.html

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/20111209/2413c002/attachment.bin>

From tayeb.meftah at gmail.com  Thu Dec  8 07:15:25 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 8 Dec 2011 15:15:25 +0200
Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers
References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net>
 <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net>
 <00f701ccb67d$fbbda9e0$f338fda0$@truenet.com>
Message-ID: <97DEB10E04E3448F949903181E2378A2@work>

we are also receyving it through level3.

----- Original Message ----- 
From: "Eric Tykwinski" <eric-list at truenet.com>
To: "'Alex Le Heux'" <alexlh at ripe.net>
Cc: <nanog at nanog.org>
Sent: Friday, December 09, 2011 4:22 PM
Subject: RE: [ncc-announce] 128.0.0.0/16 configured as martians in some 
routers


> If anyone on Cogent is lurking, we are not receiving the announcements yet
> in our BGP table.
>
> Double checked on the looking glass, and it looks company wide.
> http://www.cogentco.com/en/network/looking-glass
>
> The space is seen through Level3...
>
> Sincerely,
>
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
> F: 610-429-3222
>
> -----Original Message-----
> From: Alex Le Heux [mailto:alexlh at ripe.net]
> Sent: Monday, December 05, 2011 10:49 AM
> To: Routing WG
> Cc: lacnog at lacnic.net; PacNOG List; nanog at nanog.org; menog at menog.net; 
> UKNOF
> List; SANOG List; ncc-announce at ripe.net; Address Policy Working Group; 
> AfNOG
> List
> Subject: Re: [ncc-announce] 128.0.0.0/16 configured as martians in some
> routers
>
> Dear Colleagues,
>
> The correct prefix and pingable address list for the Debogonising Project
> is:
>
> prefix         pinagble address
>
> 128.0.0.0/21 128.0.0.1
> 128.0.24.0/24 128.0.24.1
>
> Our apologies for the oversight.
>
> Best regards,
>
> Alex Le Heux
> Policy Implementation Co-ordinator
> RIPE NCC
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6697 (20111209) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> 


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6697 (20111209) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From david at davidswafford.com  Fri Dec  9 10:05:41 2011
From: david at davidswafford.com (David)
Date: Fri, 9 Dec 2011 11:05:41 -0500
Subject: BGP and Firewalls...
In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC309220756375@mail.shoremortgage.com>
References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com>
 <76238EAE-2B76-41A1-9AB8-90A66DFB66CE@davidswafford.com>
 <1F4D60B00DE5FB42AD4BB2BC06DC309220756375@mail.shoremortgage.com>
Message-ID: <89B4DA68-B416-4061-89FE-9FEDE97C8CDD@davidswafford.com>

SSL interception was the most painful -- PaloAlto finally confirmed it as a bug in 3.1.9, havnt upgraded yet.  it basicall eats ssl traffic sporadically.

had another issue during go-live where a "commit" caused the box to crash (3.1.9)

and anothere during that same week where a malformed ssl packet crashed the dataplane.

all cases involved significant interruptions because most did not trigger ha-related failovers.  palo also support was extremely slow in all cases weve had and from that perspective alone i would not put all of my eggs into it.  great box for web filtering from a feature perspective, but my bluecoats were much more stabile in their 4 yr life than the first 2weeks on our 2050s

david.

Sent from an email server.

On Dec 8, 2011, at 10:11 AM, "Gregory Croft" <gcroft at shoremortgage.com> wrote:

> What kind of Bugs are you running into? 
> I have two PA500's at the moment and haven't really had any issues with
> web filtering. 
> 
> 
> 
> Thank you, 
> Gregory S. Croft 
> 
> -----Original Message-----
> From: David [mailto:david at davidswafford.com] 
> Sent: Thursday, December 08, 2011 9:50 AM
> To: Gregory Croft
> Cc: <nanog at nanog.org>
> Subject: Re: BGP and Firewalls...
> 
> I wouldn't do it.  We have 8 x PA-2050s and run into a lot of wierd
> bugs.... (just doing web filtering)
> 
> David
> 
> Sent from an email server.
> 
> On Dec 7, 2011, at 12:31 PM, "Gregory Croft" <gcroft at shoremortgage.com>
> wrote:
> 
>> Hi All,
>> 
>> 
>> 
>> Does anyone have any experience with using firewalls as edge devices 
>> when BGP is concerned?
>> 
>> Specifically the Palo Alto series of devices. 
>> 
>> 
>> 
>> If so please contact me off list. 
>> 
>> 
>> 
>> Thank you. 
>> 
>> 
>> 
>> 
>> 
>> Thank you,
>> 
>> Gregory S. Croft
>> 
>> 
>> 
>> 
>> 


From rcarpen at network1.net  Fri Dec  9 10:38:44 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Fri, 09 Dec 2011 11:38:44 -0500 (EST)
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <CAFU7BATdm3HASc91nZ8gC3fwYSOOkxUz8i-13XfWxx30OqwO3w@mail.gmail.com>
Message-ID: <a6ebe3db-f373-44d8-88ec-0617d104e7b9@zimbra.network1.net>



----- Original Message -----
> On Thu, Dec 8, 2011 at 11:53 AM, Randy Carpenter
> <rcarpen at network1.net> wrote:
> > Tried that. I agree with others that it is an NDP issue. NDP for
> > the GUA is fine, but just not for the link local. Is there
> > something that would block only link local by default?
> >
> > I should add that I have another uplink to a different provider
> > that works perfectly. The other end is Juniper for that one.
> 
> Just to begin with:
> 0) Does your Juniper device have the neighbor cache entry for Cisco
> link-local address? What is the state of the entry?

Sometimes it does, sometimes I can't seem to get it.


> Can you get packet capture on both sides?

We have done this.
 
> 1) is Cisco sending NS packets?

Yes.

> 2) is your Juniper receiving them?

It does not appear to. Tracing v6 stuff on juniper seems to be hit or miss.

> 3) is Juniper device sending anything back?

No. (because of #2)

> 4) are those NA reaching Cisco?

No. (because of #2)

> Any switch on the path?

It is an L2 circuit that rides a couple of different pieces of gear before it lands at the other side.
 
> [lazy mode on] I'd also suggest:
>  - debug ipv6 nd on cisco
>  - checking for bugs for IOS and JunOS versions you are using


From cdl at asgaard.org  Fri Dec  9 11:19:17 2011
From: cdl at asgaard.org (Christopher LILJENSTOLPE)
Date: Fri, 9 Dec 2011 09:19:17 -0800
Subject: Writable SNMP
In-Reply-To: <1323203316.14305.YahooMailNeo@web31806.mail.mud.yahoo.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CAPWAtbJubOh2vszRuOro=aYUiJe1KKQopgO1HHHPXGzznZznNg@mail.gmail.com>
 <1323203316.14305.YahooMailNeo@web31806.mail.mud.yahoo.com>
Message-ID: <A83B0183-B2B3-4DA2-99A7-7A522CAB78CA@asgaard.org>



On 06Dec2011, at 12.28, David Barak wrote:

> From: Jeff Wheeler <jsw at inconcepts.biz>
> 
>> Juniper does not support writing via SNMP.  I am glad.  Hopefully that
>> is the first step toward not supporting SNMP at all.
> 
> If I recall correctly, wasn't the old FORE CLI implemented via localhost SNMP?  I liked using them, but that's a special case...

Wellfleet

> 
> David Barak
> Need Geek Rock? Try The Franchise: 
> http://www.listentothefranchise.com

--  
???
Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf

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

From fmartin at linkedin.com  Fri Dec  9 12:37:09 2011
From: fmartin at linkedin.com (Franck Martin)
Date: Fri, 9 Dec 2011 18:37:09 +0000
Subject: Sad IPv4 story?
Message-ID: <CB07955B.497B3%fmartin@linkedin.com>

I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like?

This is just a data point.


From matthew at matthew.at  Fri Dec  9 12:38:56 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 09 Dec 2011 10:38:56 -0800
Subject: Sad IPv4 story?
In-Reply-To: <CB07955B.497B3%fmartin@linkedin.com>
References: <CB07955B.497B3%fmartin@linkedin.com>
Message-ID: <4EE255C0.1030304@matthew.at>

On 12/9/2011 10:37 AM, Franck Martin wrote:
> I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like?
>
> This is just a data point.
>
I hear those are $12/each.

How much do they have in the budget for this?

Matthew Kaufman


From patrick at ianai.net  Fri Dec  9 12:39:29 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Fri, 9 Dec 2011 13:39:29 -0500
Subject: Sad IPv4 story?
In-Reply-To: <CB07955B.497B3%fmartin@linkedin.com>
References: <CB07955B.497B3%fmartin@linkedin.com>
Message-ID: <3BB8E3D1-5D17-4D4C-8148-727660598EBD@ianai.net>

On Dec 9, 2011, at 1:37 PM, Franck Martin wrote:

> I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like?
> 
> This is just a data point.

Interesting data point.

Would be more interesting to find out "the way they would like".  For instance, is it a "bullet-proof" hoster who promises each spammer 1K IP addresses across dozens of discontiguous /24s?

Or is it a DSL provider with 10K subs, and APNIC would only give them a /22 until next year?

-- 
TTFN,
patrick



From fred at cisco.com  Fri Dec  9 13:07:55 2011
From: fred at cisco.com (Fred Baker)
Date: Fri, 9 Dec 2011 11:07:55 -0800
Subject: Sad IPv4 story?
In-Reply-To: <CB07955B.497B3%fmartin@linkedin.com>
References: <CB07955B.497B3%fmartin@linkedin.com>
Message-ID: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>


On Dec 9, 2011, at 10:37 AM, Franck Martin wrote:

> I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like?
> 
> This is just a data point.

We're going to be hearing a lot more of these. It's the nature of finite resources, and of human nature when faced with them. At some point, this will find its way into courtrooms under the rubric of a barrier to entry. It already has in terms of antitrust when a company wanted to move its PA prefix to different upstream.




From fmartin at linkedin.com  Fri Dec  9 13:12:39 2011
From: fmartin at linkedin.com (Franck Martin)
Date: Fri, 9 Dec 2011 19:12:39 +0000
Subject: Sad IPv4 story?
In-Reply-To: <3BB8E3D1-5D17-4D4C-8148-727660598EBD@ianai.net>
Message-ID: <CB079C96.497DE%fmartin@linkedin.com>

Option 2) and think country wide ISP growing very fast.

On 12/9/11 10:39 , "Patrick W. Gilmore" <patrick at ianai.net> wrote:

>On Dec 9, 2011, at 1:37 PM, Franck Martin wrote:
>
>> I just had a personal email from a brand new ISP in the Asia-Pacific
>>area desperately looking for enough IPv4 to be able to run their
>>business the way they would like?
>> 
>> This is just a data point.
>
>Interesting data point.
>
>Would be more interesting to find out "the way they would like".  For
>instance, is it a "bullet-proof" hoster who promises each spammer 1K IP
>addresses across dozens of discontiguous /24s?
>
>Or is it a DSL provider with 10K subs, and APNIC would only give them a
>/22 until next year?
>
>-- 
>TTFN,
>patrick
>
>



From cscora at apnic.net  Fri Dec  9 13:22:50 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 10 Dec 2011 05:22:50 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201112091922.pB9JMojO011592@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 Dec, 2011

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

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

BGP routing table entries examined:                              384553
    Prefixes after maximum aggregation:                          167591
    Deaggregation factor:                                          2.29
    Unique aggregates announced to Internet:                     188778
Total ASes present in the Internet Routing Table:                 39528
    Prefixes per ASN:                                              9.73
Origin-only ASes present in the Internet Routing Table:           32469
Origin ASes announcing only one prefix:                           15507
Transit ASes present in the Internet Routing Table:                5346
Transit-only ASes present in the Internet Routing Table:            144
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:              1864
    Unregistered ASNs in the Routing Table:                         973
Number of 32-bit ASNs allocated by the RIRs:                       2059
Number of 32-bit ASNs visible in the Routing Table:                1713
Prefixes from 32-bit ASNs in the Routing Table:                    4069
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:             82
Number of addresses announced to Internet:                   2499466496
    Equivalent to 148 /8s, 250 /16s and 213 /24s
    Percentage of available address space announced:               67.4
    Percentage of allocated address space announced:               67.4
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               91.7
Total number of prefixes smaller than registry allocations:      162332

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

Prefixes being announced by APNIC Region ASes:                    95338
    Total APNIC prefixes after maximum aggregation:               31228
    APNIC Deaggregation factor:                                    3.05
Prefixes being announced from the APNIC address blocks:           91808
    Unique aggregates announced from the APNIC address blocks:    38427
APNIC Region origin ASes present in the Internet Routing Table:    4601
    APNIC Prefixes per ASN:                                       19.95
APNIC Region origin ASes announcing only one prefix:               1248
APNIC Region transit ASes present in the Internet Routing Table:    727
Average APNIC Region AS path length visible:                        4.4
    Max APNIC Region AS path length visible:                         18
Number of APNIC region 32-bit ASNs visible in the Routing Table:    119
Number of APNIC addresses announced to Internet:              631071072
    Equivalent to 37 /8s, 157 /16s and 97 /24s
    Percentage of available APNIC address space announced:         80.0

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 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:                    146344
    Total ARIN prefixes after maximum aggregation:                74781
    ARIN Deaggregation factor:                                     1.96
Prefixes being announced from the ARIN address blocks:           118441
    Unique aggregates announced from the ARIN address blocks:     48663
ARIN Region origin ASes present in the Internet Routing Table:    14799
    ARIN Prefixes per ASN:                                         8.00
ARIN Region origin ASes announcing only one prefix:                5662
ARIN Region transit ASes present in the Internet Routing Table:    1579
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:               803365568
    Equivalent to 47 /8s, 226 /16s and 98 /24s
    Percentage of available ARIN address space announced:          63.8

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 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:                     93411
    Total RIPE prefixes after maximum aggregation:                51508
    RIPE Deaggregation factor:                                     1.81
Prefixes being announced from the RIPE address blocks:            85799
    Unique aggregates announced from the RIPE address blocks:     55001
RIPE Region origin ASes present in the Internet Routing Table:    16170
    RIPE Prefixes per ASN:                                         5.31
RIPE Region origin ASes announcing only one prefix:                7996
RIPE Region transit ASes present in the Internet Routing Table:    2557
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:    1199
Number of RIPE addresses announced to Internet:               493969856
    Equivalent to 29 /8s, 113 /16s and 97 /24s
    Percentage of available RIPE address space announced:          79.6

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       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:                   36815
    Total LACNIC prefixes after maximum aggregation:               7940
    LACNIC Deaggregation factor:                                   4.64
Prefixes being announced from the LACNIC address blocks:          36277
    Unique aggregates announced from the LACNIC address blocks:   18889
LACNIC Region origin ASes present in the Internet Routing Table:   1556
    LACNIC Prefixes per ASN:                                      23.31
LACNIC Region origin ASes announcing only one prefix:               441
LACNIC Region transit ASes present in the Internet Routing Table:   289
Average LACNIC Region AS path length visible:                       4.5
    Max LACNIC Region AS path length visible:                        18
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   379
Number of LACNIC addresses announced to Internet:              94673024
    Equivalent to 5 /8s, 164 /16s and 152 /24s
    Percentage of available LACNIC address space announced:        62.7

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:                   8406
    Total AfriNIC prefixes after maximum aggregation:              2062
    AfriNIC Deaggregation factor:                                  4.08
Prefixes being announced from the AfriNIC address blocks:          6460
    Unique aggregates announced from the AfriNIC address blocks:   2059
AfriNIC Region origin ASes present in the Internet Routing Table:   503
    AfriNIC Prefixes per ASN:                                     12.84
AfriNIC Region origin ASes announcing only one prefix:              160
AfriNIC Region transit ASes present in the Internet Routing Table:  110
Average AfriNIC Region AS path length visible:                      4.5
    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:             30395392
    Equivalent to 1 /8s, 207 /16s and 204 /24s
    Percentage of available AfriNIC address space announced:       45.3

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      11104         970   Korea Telecom (KIX)
17974     1694        503          38   PT TELEKOMUNIKASI INDONESIA
 7545     1631        303          86   TPG Internet Pty Ltd
 4755     1511        385         158   TATA Communications formerly 
 7552     1392       1064           7   Vietel Corporation
 9829     1170        989          28   BSNL National Internet Backbo
 9583     1099         81         496   Sify Limited
 4808     1076       2034         303   CNCGROUP IP network: China169
24560      982        381         162   Bharti Airtel Ltd., Telemedia
18101      960        122         155   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     3481       3814         218   bellsouth.net, inc. 
 7029     2916       1017         200   Windstream Communications Inc
18566     2093        383         177   Covad Communications 
 1785     1855        680         121   PaeTec Communications, Inc.
 4323     1617       1073         385   Time Warner Telecom
20115     1602       1548         628   Charter Communications 
22773     1505       2909         104   Cox Communications, Inc.
30036     1443        258         675   Mediacom Communications Corp 
19262     1388       4683         401   Verizon Global Networks 
 7018     1309       7029         858   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     1581        480          15   Corbina telecom
 6830      644       1927         412   UPC Distribution Services
34984      624        132         201   BILISIM TELEKOM
 2118      550         99          14   EUnet/RELCOM Autonomous Syste
20940      544        174         434   Akamai Technologies European 
 3320      528       8161         394   Deutsche Telekom AG
12479      493        601          12   Uni2 Autonomous System
 3292      480       2106         407   TDC Tele Danmark
 8866      462        133          26   Bulgarian Telecommunication C
 8551      423        366          45   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     1720        318         155   TVCABLE BOGOTA 
28573     1549       1059          72   NET Servicos de Comunicao S.A
 8151     1459       2985         349   UniNet S.A. de C.V. 
 7303     1239        751         174   Telecom Argentina Stet-France
27947      617         72          91   Telconet S.A
22047      582        322          17   VTR PUNTO NET S.A. 
 6503      554        434          68   AVANTEL, S.A. 
 7738      553       1050          31   Telecomunicacoes da Bahia S.A
 3816      547        237          89   Empresa Nacional de Telecomun
11172      528         86          95   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
 8452      963        958          13   TEDATA
24863      785        146          35   LINKdotNET AS number
 3741      281        939         230   The Internet Solution 
15706      242         32           6   Sudatel Internet Exchange Aut
33776      240         13           8   Starcomms Nigeria Limited
 6713      235        519          14   Itissalat Al-MAGHRIB
29571      217         17          13   Ci Telecom Autonomous system 
12258      195         28          60   Vodacom Internet Company 
24835      193         80           8   RAYA Telecom - Egypt
16637      164        664          83   MTN Network Solutions

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3481       3814         218   bellsouth.net, inc. 
 7029     2916       1017         200   Windstream Communications Inc
 4766     2509      11104         970   Korea Telecom (KIX)
18566     2093        383         177   Covad Communications 
 1785     1855        680         121   PaeTec Communications, Inc.
10620     1720        318         155   TVCABLE BOGOTA 
17974     1694        503          38   PT TELEKOMUNIKASI INDONESIA
 7545     1631        303          86   TPG Internet Pty Ltd
 4323     1617       1073         385   Time Warner Telecom
20115     1602       1548         628   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
 7029      2916        2716      Windstream Communications Inc
18566      2093        1916      Covad Communications 
 1785      1855        1734      PaeTec Communications, Inc.
17974      1694        1656      PT TELEKOMUNIKASI INDONESIA
 8402      1581        1566      Corbina telecom
10620      1720        1565      TVCABLE BOGOTA 
 7545      1631        1545      TPG Internet Pty Ltd
 4766      2509        1539      Korea Telecom (KIX)
28573      1549        1477      NET Servicos de Comunicao S.A
22773      1505        1401      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
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
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

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

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

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

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

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

Network            Origin AS  Description
37.0.24.0/21         50794     AS Levira
37.1.88.0/21         50763     MCKAYCOM LTD
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 
64.21.192.0/20       11610     Internet Nebraska Corporation
64.21.212.0/22       11610     Internet Nebraska Corporation
64.21.216.0/21       11610     Internet Nebraska Corporation
66.171.32.0/20         705     UUNET Technologies, 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:236     
/13:465     /14:812     /15:1442    /16:12042   /17:6104    /18:10146   
/19:20068   /20:27797   /21:28040   /22:38213   /23:35782   /24:199713  
/25:1176    /26:1417    /27:783     /28:170     /29:3       /30:0       
/31:0       /32:5       

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

  ASN   No of nets  Total ann.   Description
 7029     2545          2916      Windstream Communications Inc
 6389     2124          3481      bellsouth.net, inc. 
18566     2042          2093      Covad Communications 
10620     1615          1720      TVCABLE BOGOTA 
 8402     1556          1581      Corbina telecom
30036     1403          1443      Mediacom Communications Corp 
11492     1116          1153      Cable One 
 1785     1060          1855      PaeTec Communications, Inc.
 7011     1050          1166      Citizens Utilities 
22773      966          1505      Cox Communications, Inc.

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

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

   1:445       2:483       4:15        5:1         6:3         8:360    
  12:1944     13:1        14:557      15:11       16:3        17:7      
  20:9        23:72       24:1699     27:1113     31:721      32:67     
  33:2        34:2        36:4        38:771      39:1        40:114    
  41:2895     42:69       43:1        44:3        46:1127     47:3      
  49:228      50:459      52:13       55:5        56:2        57:45     
  58:945      59:487      60:342      61:1176     62:912      63:1970   
  64:4079     65:2307     66:4364     67:2004     68:1178     69:3141   
  70:916      71:362      72:1776     74:2639     75:431      76:319    
  77:937      78:886      79:439      80:1142     81:847      82:521    
  83:529      84:470      85:1169     86:409      87:910      88:353    
  89:1589     90:247      91:4340     92:539      93:1408     94:1324   
  95:1131     96:395      97:285      98:784      99:38      101:122    
 103:538     106:8       107:106     108:95      109:1096    110:670    
 111:823     112:375     113:485     114:617     115:703     116:876    
 117:712     118:878     119:1240    120:343     121:681     122:1557   
 123:1022    124:1365    125:1341    128:275     129:189     130:181    
 131:579     132:158     133:21      134:221     135:55      136:212    
 137:147     138:286     139:123     140:491     141:254     142:382    
 143:404     144:505     145:66      146:474     147:222     148:638    
 149:272     150:165     151:192     152:445     153:171     154:7      
 155:380     156:209     157:358     158:156     159:503     160:334    
 161:221     162:363     163:183     164:523     165:387     166:542    
 167:459     168:818     169:146     170:823     171:90      172:4      
 173:1786    174:591     175:415     176:339     177:429     178:1138   
 180:1173    181:38      182:675     183:253     184:399     185:1      
 186:1480    187:785     188:939     189:1173    190:5288    192:5969   
 193:5121    194:3797    195:3366    196:1273    197:172     198:3618   
 199:4216    200:5543    201:1702    202:8486    203:8523    204:4328   
 205:2404    206:2670    207:2842    208:4015    209:3558    210:2755   
 211:1469    212:1982    213:1795    214:822     215:92      216:4934   
 217:1488    218:578     219:344     220:1250    221:529     222:326    
 223:262    

End of report


From bensons at queuefull.net  Fri Dec  9 14:47:06 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Fri, 9 Dec 2011 14:47:06 -0600
Subject: Sad IPv4 story?
In-Reply-To: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
Message-ID: <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>


On Dec 9, 2011, at 1:07 PM, Fred Baker wrote:

> On Dec 9, 2011, at 10:37 AM, Franck Martin wrote:
> 
>> I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like?
>> 
>> This is just a data point.
> 
> We're going to be hearing a lot more of these. It's the nature of finite resources, and of human nature when faced with them. At some point, this will find its way into courtrooms under the rubric of a barrier to entry. It already has in terms of antitrust when a company wanted to move its PA prefix to different upstream.

+1 to Fred's comments.  Hopefully, the existence of an open IPv4 address market will help avoid some of the worst.  (At least for a while, until the rising prices get too high for a competitive environment.  And maybe by then the price of IPv4 addresses will have made IPv6 deployment a much more obvious choice to reluctant CFO-types.)

Cheers,
-Benson

---
Disclaimers:
1. I am not a lawyer, and nothing in this message should be construed as advice.
2. I, Benson Schliesser, am an employee of Cisco Systems; however, opinions expressed in this email are my own views and not those of Cisco Systems or anybody else.





From mark at exonetric.com  Fri Dec  9 14:57:22 2011
From: mark at exonetric.com (Mark Blackman)
Date: Fri, 9 Dec 2011 20:57:22 +0000
Subject: Sad IPv4 story?
In-Reply-To: <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
 <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
Message-ID: <1B40C293-E7A7-4C17-ACF0-EBE6FE4F42A4@exonetric.com>


On 9 Dec 2011, at 20:47, Benson Schliesser wrote:

> 
> On Dec 9, 2011, at 1:07 PM, Fred Baker wrote:
> 
>> On Dec 9, 2011, at 10:37 AM, Franck Martin wrote:
>> 
>>> I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like?
>>> 
>>> This is just a data point.
>> 
>> We're going to be hearing a lot more of these. It's the nature of finite resources, and of human nature when faced with them. At some point, this will find its way into courtrooms under the rubric of a barrier to entry. It already has in terms of antitrust when a company wanted to move its PA prefix to different upstream.

I've had transit service pulled, so the provider can reclaim the /21 that was bundled with the transit.

- Mark



From bensons at queuefull.net  Fri Dec  9 15:05:12 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Fri, 9 Dec 2011 15:05:12 -0600
Subject: Sad IPv4 story?
In-Reply-To: <1B40C293-E7A7-4C17-ACF0-EBE6FE4F42A4@exonetric.com>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
 <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
 <1B40C293-E7A7-4C17-ACF0-EBE6FE4F42A4@exonetric.com>
Message-ID: <4E600760-233F-4F9F-B30D-8A3931271548@queuefull.net>


On Dec 9, 2011, at 2:57 PM, Mark Blackman wrote:
>> On Dec 9, 2011, at 1:07 PM, Fred Baker wrote:
>>> We're going to be hearing a lot more of these. It's the nature of finite resources, and of human nature when faced with them. At some point, this will find its way into courtrooms under the rubric of a barrier to entry. It already has in terms of antitrust when a company wanted to move its PA prefix to different upstream.
> 
> I've had transit service pulled, so the provider can reclaim the /21 that was bundled with the transit.

I'm sorry to hear about that...  Do you know why they reclaimed the block?  E.g. was it used to support a "higher margin" service for another customer?

-Benson



From mark at exonetric.com  Fri Dec  9 15:11:32 2011
From: mark at exonetric.com (Mark Blackman)
Date: Fri, 9 Dec 2011 21:11:32 +0000
Subject: Sad IPv4 story?
In-Reply-To: <4E600760-233F-4F9F-B30D-8A3931271548@queuefull.net>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
 <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
 <1B40C293-E7A7-4C17-ACF0-EBE6FE4F42A4@exonetric.com>
 <4E600760-233F-4F9F-B30D-8A3931271548@queuefull.net>
Message-ID: <B42884DC-F125-4D5C-9C30-A99C47718434@exonetric.com>

On 9 Dec 2011, at 21:05, Benson Schliesser <bensons at queuefull.net> wrote:

> 
> On Dec 9, 2011, at 2:57 PM, Mark Blackman wrote:
>>> On Dec 9, 2011, at 1:07 PM, Fred Baker wrote:
>>>> We're going to be hearing a lot more of these. It's the nature of finite resources, and of human nature when faced with them. At some point, this will find its way into courtrooms under the rubric of a barrier to entry. It already has in terms of antitrust when a company wanted to move its PA prefix to different upstream.
>> 
>> I've had transit service pulled, so the provider can reclaim the /21 that was bundled with the transit.
> 
> I'm sorry to hear about that...  Do you know why they reclaimed the block?  E.g. was it used to support a "higher margin" service for another customer?
> 
> -Benson

Leased line customers.

From Valdis.Kletnieks at vt.edu  Fri Dec  9 15:12:21 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 09 Dec 2011 16:12:21 -0500
Subject: Sad IPv4 story?
In-Reply-To: Your message of "Fri, 09 Dec 2011 14:47:06 CST."
 <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
 <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
Message-ID: <14031.1323465141@turing-police.cc.vt.edu>

On Fri, 09 Dec 2011 14:47:06 CST, Benson Schliesser said:

> +1 to Fred's comments.  Hopefully, the existence of an open IPv4 address
> market will help avoid some of the worst.  (At least for a while, until
> the rising prices get too high for a competitive environment.  And maybe
> by then the price of IPv4 addresses will have made IPv6 deployment a
> much more obvious choice to reluctant CFO-types.)

I suspect the opposite is in fact true - if there is an open market, many sites
will continue deluding themselves and make the end game that much more painful.
If you haven't been able to sell the CFO types on the need to deploy IPv6 *yet*
(consider that you *should* have been specifying "Ipv6-ready" on capex for at
least 4-5 years already, so most of the gear on the floor should be ready to
go), you're going to be *screwed* when you finally get moving.  Among other
things, all the *good* IPv6 experts will already have found good gigs, and it's
gonna either take a bigger paycheck to headhunt one, or you'll be stuck with
the dregs of the market (either way, it will cost you more).

-------------- 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/20111209/6454243d/attachment.bin>

From jared at puck.nether.net  Fri Dec  9 15:16:08 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 9 Dec 2011 16:16:08 -0500
Subject: Sad IPv4 story?
In-Reply-To: <14031.1323465141@turing-police.cc.vt.edu>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
 <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
 <14031.1323465141@turing-police.cc.vt.edu>
Message-ID: <D0522098-479D-4691-8E06-5451CA250861@puck.nether.net>


On Dec 9, 2011, at 4:12 PM, Valdis.Kletnieks at vt.edu wrote:

> I suspect the opposite is in fact true - if there is an open market, many sites
> will continue deluding themselves and make the end game that much more painful.
> If you haven't been able to sell the CFO types on the need to deploy IPv6 *yet*
> (consider that you *should* have been specifying "Ipv6-ready" on capex for at
> least 4-5 years already, so most of the gear on the floor should be ready to
> go), you're going to be *screwed* when you finally get moving.  Among other
> things, all the *good* IPv6 experts will already have found good gigs, and it's
> gonna either take a bigger paycheck to headhunt one, or you'll be stuck with
> the dregs of the market (either way, it will cost you more).

I've had recruiters calling me about IPv6 related jobs for at least 2 years now.

Some are full-time, others contract work.

If you haven't IPv6 enabled your capable devices yet, get on it.  Most providers
will give you IPv6 for free now, and will allocate you space from their blocks.

If you are an ARIN member, you can get your block of IPv6 address by submitting a simple
form as long as you already have IPv4 space.

Get on it, make them work this month and have your space already allocated prior to the
start of 2012.

- jared



From dougb at dougbarton.us  Fri Dec  9 15:20:12 2011
From: dougb at dougbarton.us (Doug Barton)
Date: Fri, 09 Dec 2011 13:20:12 -0800
Subject: Sad IPv4 story?
In-Reply-To: <D0522098-479D-4691-8E06-5451CA250861@puck.nether.net>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
 <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
 <14031.1323465141@turing-police.cc.vt.edu>
 <D0522098-479D-4691-8E06-5451CA250861@puck.nether.net>
Message-ID: <4EE27B8C.5000707@dougbarton.us>

On 12/09/2011 13:16, Jared Mauch wrote:
> I've had recruiters calling me about IPv6 related jobs for at least 2 years now.
> 
> Some are full-time, others contract work.

+1, mostly contract stuff that I've had to turn down because my travel
capacity is limited nowadays. From the standpoint of IPv6, it's already
"next quarter."


Doug

-- 

		[^L]

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/



From tom.ammon at utah.edu  Fri Dec  9 15:33:58 2011
From: tom.ammon at utah.edu (Tom Ammon)
Date: Fri, 9 Dec 2011 21:33:58 +0000
Subject: best DHCPv6 server?
Message-ID: <34FB1D1922F27F439B677D238AF0A4AC03A6B1@X-MB10.xds.umail.utah.edu>

Hi All, 

I'm wondering, what would you say is the best DHCPv6 server for a large enterprise? We've played with dibbler and the ISC server, and have had some interesting (and annoying) results with the ISC server. At first blush, dibbler appears to work better. 

Thoughts?

Tom

-----------------------------------------------------------------------------
Tom Ammon
Network Engineer
M: (801)674-9273
tom.ammon at utah.edu

Center for High Performance Computing
University of Utah
http://www.chpc.utah.edu
-----------------------------------------------------------------------------




From deepak at ai.net  Fri Dec  9 15:38:12 2011
From: deepak at ai.net (Deepak Jain)
Date: Fri, 09 Dec 2011 16:38:12 -0500
Subject: Sad IPv4 story?
In-Reply-To: <D0522098-479D-4691-8E06-5451CA250861@puck.nether.net>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
 <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
 <14031.1323465141@turing-police.cc.vt.edu>
 <D0522098-479D-4691-8E06-5451CA250861@puck.nether.net>
Message-ID: <4EE27FC4.7070201@ai.net>


> If you haven't IPv6 enabled your capable devices yet, get on it.  Most providers
> will give you IPv6 for free now, and will allocate you space from their blocks.
>
> If you are an ARIN member, you can get your block of IPv6 address by submitting a simple
> form as long as you already have IPv4 space.
>
> Get on it, make them work this month and have your space already allocated prior to the
> start of 2012.
>

I can tell you that (as of Dec 2011) *lots and lots* of networks (big 
ones, even some of the biggest) are in no real position to support 
nearly universal customer IPv6 service yet. There are networks that have 
IPv6 "somewhere".. but even where we've been requesting IPv6 turned up 
alongside existing IPv4 sessions sometimes the turnaround is months and 
months with lots of repeated banging -- even where the gear and the 
uplinks support it.

Some of this is that (esp internal) tools still aren't where they need 
to be. Some of this is that once we IPv6 becomes the "standard"... well, 
security and other concerns will challenge all the infrastructure in place.

And this is all before you get into issues of inconsistent views of the 
IPv6 RIB, and the rest.

Just my opinion, hopefully someone else has a better experience.

DJ




From owen at delong.com  Fri Dec  9 15:37:04 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 9 Dec 2011 16:37:04 -0500
Subject: Sad IPv4 story?
In-Reply-To: <D0522098-479D-4691-8E06-5451CA250861@puck.nether.net>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
 <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
 <14031.1323465141@turing-police.cc.vt.edu>
 <D0522098-479D-4691-8E06-5451CA250861@puck.nether.net>
Message-ID: <B3767D5D-B74C-40E7-A8E6-A50773925D36@delong.com>

> 
> 
> 
> If you are an ARIN member, you can get your block of IPv6 address by submitting a simple
> form as long as you already have IPv4 space.
> 

Not exactly...

1. You don't have to be an ARIN member.
2. Even if you don't have IPv4 space, you can still use a simple form. You just need to put a little more information on that form.

Owen

From cidr-report at potaroo.net  Fri Dec  9 16:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 9 Dec 2011 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201112092200.pB9M00Mi088244@wattle.apnic.net>

BGP Update Report
Interval: 01-Dec-11 -to- 08-Dec-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS42116          216141 10.4%    3929.8 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
 2 - AS8402            45654  2.2%      28.6 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS24560           44354  2.1%      46.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
 4 - AS9829            30074  1.4%      47.8 -- BSNL-NIB National Internet Backbone
 5 - AS44568           25231  1.2%    2803.4 -- OPSOURCE-UK OpSource, Inc
 6 - AS32528           25070  1.2%    6267.5 -- ABBOTT Abbot Labs
 7 - AS5800            24783  1.2%      90.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 8 - AS7552            24639  1.2%      17.8 -- VIETEL-AS-AP Vietel Corporation
 9 - AS19743           20793  1.0%    2970.4 -- 
10 - AS20632           19982  1.0%     587.7 -- PETERSTAR-AS PeterStar
11 - AS11830           18116  0.9%      55.2 -- Instituto Costarricense de Electricidad y Telecom.
12 - AS31148           17299  0.8%      41.7 -- FREENET-AS FreeNet ISP
13 - AS27738           15592  0.8%      45.9 -- Ecuadortelecom S.A.
14 - AS6316            15209  0.7%     227.0 -- AS-PAETEC-NET - PaeTec Communications, Inc.
15 - AS1785            13444  0.7%       7.9 -- AS-PAETEC-NET - PaeTec Communications, Inc.
16 - AS19223           12864  0.6%   12864.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions
17 - AS17974           12226  0.6%       8.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
18 - AS39353           11648  0.6%    3882.7 -- PRINCAST-AS Gobierno del Principado de Asturias
19 - AS27964           10851  0.5%      97.8 -- RSONet
20 - AS14420           10482  0.5%      21.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS19223           12864  0.6%   12864.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions
 2 - AS18823            8516  0.4%    8516.0 -- MEDICALERT - Medicalert Foundation
 3 - AS32528           25070  1.2%    6267.5 -- ABBOTT Abbot Labs
 4 - AS42116          216141 10.4%    3929.8 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
 5 - AS39353           11648  0.6%    3882.7 -- PRINCAST-AS Gobierno del Principado de Asturias
 6 - AS19743           20793  1.0%    2970.4 -- 
 7 - AS44568           25231  1.2%    2803.4 -- OPSOURCE-UK OpSource, Inc
 8 - AS37378            2590  0.1%    2590.0 -- NIGERIA-AIRFORCE
 9 - AS6066             3542  0.2%    1771.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
10 - AS10209            1634  0.1%    1634.0 -- SYNOPSYS-AS-JP-AP Japan HUB and Data Center
11 - AS28170            4351  0.2%    1087.8 -- 
12 - AS53362             928  0.0%     928.0 -- MIXIT-AS - Mixit, Inc.
13 - AS55696             755  0.0%     755.0 -- SCOM-AS-ID Starcom Solusindo PT.
14 - AS8163              749  0.0%     749.0 -- METROTEL REDES S.A.
15 - AS6072             9646  0.5%     689.0 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com
16 - AS22878            6905  0.3%     627.7 -- ASACENET1 - ACENET, INC.
17 - AS20632           19982  1.0%     587.7 -- PETERSTAR-AS PeterStar
18 - AS11943             558  0.0%     558.0 -- GLOBE - Globe Wireless
19 - AS19674            1596  0.1%     532.0 -- NAVPOINT - Navpoint Internet
20 - AS33076             524  0.0%     524.0 -- ISC-TGD1 Internet Systems Consortium, Inc.


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 84.204.132.0/24   19878  0.9%   AS20632 -- PETERSTAR-AS PeterStar
 2 - 67.97.156.0/24    12864  0.6%   AS19223 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions
 3 - 130.36.34.0/24    12533  0.6%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/24    12533  0.6%   AS32528 -- ABBOTT Abbot Labs
 5 - 88.151.16.0/22    11646  0.5%   AS39353 -- PRINCAST-AS Gobierno del Principado de Asturias
 6 - 66.248.96.0/21     9872  0.5%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 7 - 75.141.48.0/24     8516  0.4%   AS18823 -- MEDICALERT - Medicalert Foundation
 8 - 95.78.100.0/22     8417  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
 9 - 46.147.84.0/22     8411  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
10 - 46.147.92.0/22     8404  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
11 - 95.78.104.0/22     8391  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
12 - 95.78.88.0/22      8390  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
13 - 95.78.80.0/22      8389  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
14 - 95.78.16.0/22      8388  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
15 - 176.213.100.0/22   8388  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
16 - 95.78.108.0/22     8377  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
17 - 46.147.88.0/22     8376  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
18 - 95.78.12.0/22      8376  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
19 - 95.78.20.0/22      8376  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"
20 - 46.147.80.0/22     8365  0.4%   AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding"

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 Dec  9 16:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 9 Dec 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201112092200.pB9M00JM088239@wattle.apnic.net>

This report has been generated at Fri Dec  9 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
        02-12-11    385297      226100
        03-12-11    385231      226034
        04-12-11    385299      226287
        05-12-11    385441      226550
        06-12-11    385599      226848
        07-12-11    385865      226928
        08-12-11    385744      227259
        09-12-11    386491      227289


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

 --- 09Dec11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     386646   227364   159282    41.2%   All ASes

AS6389      3481      221     3260    93.7%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS18566     2093      412     1681    80.3%   COVAD - Covad Communications
                                               Co.
AS4766      2513      993     1520    60.5%   KIXS-AS-KR Korea Telecom
AS7029      2957     1524     1433    48.5%   WINDSTREAM - Windstream
                                               Communications Inc
AS22773     1505      113     1392    92.5%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1508      213     1295    85.9%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS4323      1618      387     1231    76.1%   TWTC - tw telecom holdings,
                                               inc.
AS28573     1549      402     1147    74.0%   NET Servicos de Comunicao S.A.
AS1785      1858      783     1075    57.9%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS10620     1721      702     1019    59.2%   Telmex Colombia S.A.
AS19262     1388      401      987    71.1%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS7552      1305      421      884    67.7%   VIETEL-AS-AP Vietel
                                               Corporation
AS7303      1239      359      880    71.0%   Telecom Argentina S.A.
AS8402      1507      667      840    55.7%   CORBINA-AS OJSC "Vimpelcom"
AS18101      963      156      807    83.8%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS8151      1459      657      802    55.0%   Uninet S.A. de C.V.
AS30036     1443      681      762    52.8%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS4808      1076      334      742    69.0%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS7545      1630      946      684    42.0%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1105      457      648    58.6%   LEVEL3 Level 3 Communications
AS17676      675       74      601    89.0%   GIGAINFRA Softbank BB Corp.
AS4804       663       95      568    85.7%   MPX-AS Microplex PTY LTD
AS17974     1694     1133      561    33.1%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS20115     1602     1043      559    34.9%   CHARTER-NET-HKY-NC - Charter
                                               Communications
AS22561      931      376      555    59.6%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS22047      582       33      549    94.3%   VTR BANDA ANCHA S.A.
AS3549       959      415      544    56.7%   GBLX Global Crossing Ltd.
AS24560      982      448      534    54.4%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS7011      1167      647      520    44.6%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.
AS17488      931      412      519    55.7%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet

Total      44104    15505    28599    64.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-
        37.1.88.0/21         AS50763 MCKAYCOM MCKAYCOM LTD
        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.175.222.0/23      AS30058 FDCSERVERS - FDCservers.net
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        80.88.10.0/24        AS33774 DJAWEB
        98.159.96.0/20       AS46975 
        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)
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        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.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.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.9.55.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.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.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        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 France Telecom S.A.
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications 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
        209.222.240.0/22     AS19747 
        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.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 jared at puck.nether.net  Fri Dec  9 16:04:49 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 9 Dec 2011 17:04:49 -0500
Subject: Sad IPv4 story?
In-Reply-To: <4EE27FC4.7070201@ai.net>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com>
 <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net>
 <14031.1323465141@turing-police.cc.vt.edu>
 <D0522098-479D-4691-8E06-5451CA250861@puck.nether.net>
 <4EE27FC4.7070201@ai.net>
Message-ID: <0D317931-9E45-46BF-98C4-05D7C124A3AF@puck.nether.net>


On Dec 9, 2011, at 4:38 PM, Deepak Jain wrote:

> I can tell you that (as of Dec 2011) *lots and lots* of networks (big ones, even some of the biggest) are in no real position to support nearly universal customer IPv6 service yet. There are networks that have IPv6 "somewhere".. but even where we've been requesting IPv6 turned up alongside existing IPv4 sessions sometimes the turnaround is months and months with lots of repeated banging -- even where the gear and the uplinks support it.

I think you are working with the wrong carriers in that case perhaps?  As part of a turn-up this year, IPv6 was a standard question, including the IP/BGP request form that had separate tabs for IPv6 and address space requests along-side the IPv4 BGP/space request.  The cases were with Cogent and Abovenet for connections in the US.  I know that NTT can also do IPv6 as well.  I think that some of what you may be terming the big-guys such as at&t and verizon/uunet are still behind the curve but they are largely in the managed services and not internet space from what I can tell.  Internet is a side thing they sell and not a primary line of business.

> Some of this is that (esp internal) tools still aren't where they need to be. Some of this is that once we IPv6 becomes the "standard"... well, security and other concerns will challenge all the infrastructure in place.

I do agree that most tools seem to be IPv4 centric these days at least for management of the device (Eg: no SNMP over IPv6 only).

You can do much of the monitoring over IPv6.
 
> And this is all before you get into issues of inconsistent views of the IPv6 RIB, and the rest.

While this still exists, this is something that will resolve itself with increased adoption.

> 
> Just my opinion, hopefully someone else has a better experience.

My experience as well.

- Jared

From dr at cluenet.de  Fri Dec  9 16:55:28 2011
From: dr at cluenet.de (Daniel Roesen)
Date: Fri, 9 Dec 2011 23:55:28 +0100
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <a6ebe3db-f373-44d8-88ec-0617d104e7b9@zimbra.network1.net>
References: <CAFU7BATdm3HASc91nZ8gC3fwYSOOkxUz8i-13XfWxx30OqwO3w@mail.gmail.com>
 <a6ebe3db-f373-44d8-88ec-0617d104e7b9@zimbra.network1.net>
Message-ID: <20111209225528.GA21768@srv03.cluenet.de>

On Fri, Dec 09, 2011 at 11:38:44AM -0500, Randy Carpenter wrote:
> > 1) is Cisco sending NS packets?
> 
> Yes.
> 
> > 2) is your Juniper receiving them?
> 
> It does not appear to. Tracing v6 stuff on juniper seems to be hit or miss.
[...]
> > Any switch on the path?
> 
> It is an L2 circuit that rides a couple of different pieces of gear before it lands at the other side.

Sounds like this equipment having problems with IPv6 multicast...

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From matthew at matthew.at  Fri Dec  9 17:01:06 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 09 Dec 2011 15:01:06 -0800
Subject: seeking clueful assistance at speakeasy-now-megapath
In-Reply-To: <4EE19F88.5070504@matthew.at>
References: <4EE19F88.5070504@matthew.at>
Message-ID: <4EE29332.6030203@matthew.at>

On 12/8/2011 9:41 PM, Matthew Kaufman wrote:
> See subject. Contact me off-list please.
>
> Matthew Kaufman
>

Six helpful responses later and the issue is resolved. Thanks to 
everyone who reached out.

Matthew Kaufman


From furry13 at gmail.com  Fri Dec  9 18:06:58 2011
From: furry13 at gmail.com (Jen Linkova)
Date: Sat, 10 Dec 2011 11:06:58 +1100
Subject: Juniper <-> Cisco IPv6 BGP peering
In-Reply-To: <20111209225528.GA21768@srv03.cluenet.de>
References: <CAFU7BATdm3HASc91nZ8gC3fwYSOOkxUz8i-13XfWxx30OqwO3w@mail.gmail.com>
 <a6ebe3db-f373-44d8-88ec-0617d104e7b9@zimbra.network1.net>
 <20111209225528.GA21768@srv03.cluenet.de>
Message-ID: <CAFU7BAR8xPHdJW_6coUUFPgZcezzZSEm1DuU2K3toqF8mhqDfw@mail.gmail.com>

On Sat, Dec 10, 2011 at 9:55 AM, Daniel Roesen <dr at cluenet.de> wrote:
>> > Any switch on the path?
>>
>> It is an L2 circuit that rides a couple of different pieces of gear before it lands at the other side.
>
> Sounds like this equipment having problems with IPv6 multicast...

Yep, that's why I was asking - but it doesn't explain how/why ND for
GUA works in this case.

-- 
SY, Jen Linkova aka Furry


From keegan.holley at sungard.com  Fri Dec  9 20:22:40 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Fri, 9 Dec 2011 21:22:40 -0500
Subject: Writable SNMP
In-Reply-To: <CAL9jLaZ-PxAGA7aX9jy=uVgFLJDHKZ5wV_GcncWU=+=-7R0Zuw@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
 <CAL9jLabyFBjukeZ9pqopTiDxj=zmSrWnPrvjzcuE+qAycTPFHg@mail.gmail.com>
 <CABO8Q6TsZssYOBGoWXcaxBB3SnNkDsaK48EG0Zq6uEt9uZj+aw@mail.gmail.com>
 <CAL9jLaZ-PxAGA7aX9jy=uVgFLJDHKZ5wV_GcncWU=+=-7R0Zuw@mail.gmail.com>
Message-ID: <CABO8Q6QbiV1i8qoFOb1CKgn8Ae86dap-UJp0LFXLq_m3V7PApA@mail.gmail.com>

>
>
> > assumption that writable SNMP was a bad idea but have never actually
> tried
> > it.  I was curious what others were using, netconf or just scripted
> logins.
> > I'm also fighting a losing battle to convince people that netconf isn't
> > evil.  It strikes me as odd that if I wanted to talk to a
> database/website
> > full of credit card and billing info there's a long list of API's I could
> > use, but if I wanted to talk to the router or firewall in front of it I
> can
> > only use ssh or telnet.
>
> sad, right? there are millions of restful program writers, only a few
> thousand network device programmers, and the vast majority of 'network
> management' is done by people perfectly happy with 'cisco-works' :(
>
>
according to the law of supply and demand, that would be.... demand? right?
;)

From joelja at bogus.com  Fri Dec  9 20:25:52 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Fri, 09 Dec 2011 18:25:52 -0800
Subject: Writable SNMP
In-Reply-To: <CABO8Q6QbiV1i8qoFOb1CKgn8Ae86dap-UJp0LFXLq_m3V7PApA@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
 <CAL9jLabyFBjukeZ9pqopTiDxj=zmSrWnPrvjzcuE+qAycTPFHg@mail.gmail.com>
 <CABO8Q6TsZssYOBGoWXcaxBB3SnNkDsaK48EG0Zq6uEt9uZj+aw@mail.gmail.com>
 <CAL9jLaZ-PxAGA7aX9jy=uVgFLJDHKZ5wV_GcncWU=+=-7R0Zuw@mail.gmail.com>
 <CABO8Q6QbiV1i8qoFOb1CKgn8Ae86dap-UJp0LFXLq_m3V7PApA@mail.gmail.com>
Message-ID: <4EE2C330.2090907@bogus.com>

On 12/9/11 18:22 , Keegan Holley wrote:
>>
>>
>>> assumption that writable SNMP was a bad idea but have never actually
>> tried
>>> it.  I was curious what others were using, netconf or just scripted
>> logins.
>>> I'm also fighting a losing battle to convince people that netconf isn't
>>> evil.  It strikes me as odd that if I wanted to talk to a
>> database/website
>>> full of credit card and billing info there's a long list of API's I could
>>> use, but if I wanted to talk to the router or firewall in front of it I
>> can
>>> only use ssh or telnet.

http://www.juniper.net/support/products/netconf/

>> sad, right? there are millions of restful program writers, only a few
>> thousand network device programmers, and the vast majority of 'network
>> management' is done by people perfectly happy with 'cisco-works' :(
>>
>>
> according to the law of supply and demand, that would be.... demand? right?
> ;)
> 



From keegan.holley at sungard.com  Fri Dec  9 20:28:05 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Fri, 9 Dec 2011 21:28:05 -0500
Subject: Writable SNMP
In-Reply-To: <4EE2C330.2090907@bogus.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net>
 <CAL9jLabyFBjukeZ9pqopTiDxj=zmSrWnPrvjzcuE+qAycTPFHg@mail.gmail.com>
 <CABO8Q6TsZssYOBGoWXcaxBB3SnNkDsaK48EG0Zq6uEt9uZj+aw@mail.gmail.com>
 <CAL9jLaZ-PxAGA7aX9jy=uVgFLJDHKZ5wV_GcncWU=+=-7R0Zuw@mail.gmail.com>
 <CABO8Q6QbiV1i8qoFOb1CKgn8Ae86dap-UJp0LFXLq_m3V7PApA@mail.gmail.com>
 <4EE2C330.2090907@bogus.com>
Message-ID: <CABO8Q6TpkDsQ58_P6QvZy+3Kd1Z7atBg2G_fJj1hbCw-gUBREg@mail.gmail.com>

2011/12/9 Joel jaeggli <joelja at bogus.com>

> On 12/9/11 18:22 , Keegan Holley wrote:
> >>
> >>
> >>> assumption that writable SNMP was a bad idea but have never actually
> >> tried
> >>> it.  I was curious what others were using, netconf or just scripted
> >> logins.
> >>> I'm also fighting a losing battle to convince people that netconf isn't
> >>> evil.  It strikes me as odd that if I wanted to talk to a
> >> database/website
> >>> full of credit card and billing info there's a long list of API's I
> could
> >>> use, but if I wanted to talk to the router or firewall in front of it I
> >> can
> >>> only use ssh or telnet.
>
> http://www.juniper.net/support/products/netconf/
>

+1
sadly there are still those that think netconf is black magic hacker voodo
though

From keegan.holley at sungard.com  Fri Dec  9 20:30:47 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Fri, 9 Dec 2011 21:30:47 -0500
Subject: Writable SNMP
In-Reply-To: <CAL9jLaaQPMJo+wc9wCchg8=tmQqjR0tkWzWo+PJbRz4Zcwz0JA@mail.gmail.com>
References: <CABO8Q6QsPUDv88SJKAEn2VutE7s0fdLpSLGL2dAo54UvSDr_PA@mail.gmail.com>
 <CDEE94CC-4811-4B20-AC94-BD8E5C710F4F@puck.nether.net>
 <CAL9jLabi=JcMLG9qhNhnnVv3uy2N47-rarvtzchjM2hS50whUA@mail.gmail.com>
 <CABO8Q6TF9=okuKiyUvH9dZZBNPLjJFnzbXUP8VuU7WQL6EB4jA@mail.gmail.com>
 <CAL9jLaa8MMeooBPpQjKSna18-nLipzPf3fvbsi0PLEo=9peYWA@mail.gmail.com>
 <CABO8Q6QMoNGaTgU1VxoWvP76F3XCJVhpnxGZHbTs0-cMw7_RRw@mail.gmail.com>
 <CAL9jLaaQPMJo+wc9wCchg8=tmQqjR0tkWzWo+PJbRz4Zcwz0JA@mail.gmail.com>
Message-ID: <CABO8Q6RNJX+GtK1vxeXOSK7+TDMmTus=9aiONy6r=6uQY2+hnQ@mail.gmail.com>

>
>
> > In lieu of a software upgrade, a workaround can be applied to certain IOS
> > releases by disabling the ILMI community or "*ilmi" view and applying an
> > access list to prevent unauthorized access to SNMP. Any affected system,
> > regardless of software release, may be protected by filtering SNMP
> traffic
> > at a network perimeter or on individual devices.
>
> right, but as I said above, the community-string restrictions don't
> help you in cases where you haven't filtered source-addresses in
> loopback/copp :( people still get to grind on your router's snmp
> process, maybe there's another way in, maybe there's a bug in the
> snmpd :(
>
> even if you filtered you could still get spoofed traffic.  What if some
employee wrote code to trace route across your network and send spoofed
packets with or without a good string.  Provided you aren't filtering snmp
at your edge, which many don't they could pretty easily melt your network
with a few boxes.  This is true of the ever present snmp poll as well.
(conspiracy theory over)

From kauer at biplane.com.au  Sat Dec 10 00:17:57 2011
From: kauer at biplane.com.au (Karl Auer)
Date: Sat, 10 Dec 2011 17:17:57 +1100
Subject: best DHCPv6 server?
In-Reply-To: <34FB1D1922F27F439B677D238AF0A4AC03A6B1@X-MB10.xds.umail.utah.edu>
References: <34FB1D1922F27F439B677D238AF0A4AC03A6B1@X-MB10.xds.umail.utah.edu>
Message-ID: <1323497877.2480.105.camel@karl>

On Fri, 2011-12-09 at 21:33 +0000, Tom Ammon wrote:
> I'm wondering, what would you say is the best DHCPv6 server for a
> large enterprise? We've played with dibbler and the ISC server, and
> have had some interesting (and annoying) results with the ISC server.
> At first blush, dibbler appears to work better. 

For capacity, speed, features, scalability, extensibility,
configurability, automation, monitoring - Nominum's "DCS" software is
unparalled. Oh, and it has full IPv6 support.

Not to denigrate Dibbler, or ISC's DHCP server, both of which are
excellent, but they do not stand comparison with DCS. It is truly
industrial strength, in world where that phrase is badly over-used.

The flip side - DCS is VERY expensive.

I'm not a shareholder, just a very satisfied user. Happy to answer
questions off-list.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

-------------- 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/20111210/bad39310/attachment.bin>

From randy at psg.com  Sat Dec 10 01:58:14 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 10 Dec 2011 16:58:14 +0900
Subject: Sad IPv4 story?
In-Reply-To: <CB07955B.497B3%fmartin@linkedin.com>
References: <CB07955B.497B3%fmartin@linkedin.com>
Message-ID: <m21usceu3t.wl%randy@psg.com>

> I just had a personal email from a brand new ISP in the Asia-Pacific
> area desperately looking for enough IPv4 to be able to run their
> business the way they would like?

and we are supposed to be surprised or feel sorry?  you're kidding,
right?  they're lucky to be in a/p.  at least they can get a /22.

i especially like the "the way they would like" part.  the way i would
like to run my business is to go into the office every friday and scoop
up the cash that fell from the sky all week.

reality is such a pain in the ass.

randy


From keegan.holley at sungard.com  Sat Dec 10 02:15:01 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sat, 10 Dec 2011 03:15:01 -0500
Subject: Sad IPv4 story?
In-Reply-To: <m21usceu3t.wl%randy@psg.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
Message-ID: <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>



Sent from my iPhone

On Dec 10, 2011, at 2:58 AM, Randy Bush <randy at psg.com> wrote:

>> I just had a personal email from a brand new ISP in the Asia-Pacific
>> area desperately looking for enough IPv4 to be able to run their
>> business the way they would like?
> 
> and we are supposed to be surprised or feel sorry?  you're kidding,
> right?  they're lucky to be in a/p.  at least they can get a /22.
> 
> i especially like the "the way they would like" part.  the way i would
> like to run my business is to go into the office every friday and scoop
> up the cash that fell from the sky all week.
> 
> reality is such a pain in the ass.
> 
> randy
> 
+1 aren't we way past all of the predicted exhaustion dates.  There are slot of as's that have ignored this.
> 


From o.calvano at gmail.com  Sat Dec 10 03:03:04 2011
From: o.calvano at gmail.com (Olivier CALVANO)
Date: Sat, 10 Dec 2011 10:03:04 +0100
Subject: Local Loop at Singapore
Message-ID: <CAJajPecazG6TmGqibWycH3OKys99A1HKqKJ6w4RsoA4VGfbUjw@mail.gmail.com>

Hi

anyone have a contact of a local telco for buy a link in metro of the
Singapore City ?

We want connect a customer based at singapore to our rack of Equinix or *
I-Advantage

Thanks for your help
best regards
Olivier

*

From bmanning at vacation.karoshi.com  Sat Dec 10 06:22:07 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sat, 10 Dec 2011 12:22:07 +0000
Subject: Sad IPv4 story?
In-Reply-To: <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
Message-ID: <20111210122207.GA6072@vacation.karoshi.com.>

On Sat, Dec 10, 2011 at 03:15:01AM -0500, Keegan Holley wrote:
> 
> 
> Sent from my iPhone
> 
> On Dec 10, 2011, at 2:58 AM, Randy Bush <randy at psg.com> wrote:
> 
> >> I just had a personal email from a brand new ISP in the Asia-Pacific
> >> area desperately looking for enough IPv4 to be able to run their
> >> business the way they would likeb&
> > 
> > and we are supposed to be surprised or feel sorry?  you're kidding,
> > right?  they're lucky to be in a/p.  at least they can get a /22.
> > 
> > i especially like the "the way they would like" part.  the way i would
> > like to run my business is to go into the office every friday and scoop
> > up the cash that fell from the sky all week.
> > 
> > reality is such a pain in the ass.
> > 
> > randy
> > 
> +1 aren't we way past all of the predicted exhaustion dates.  There are slot of as's that have ignored this.
> > 
> 

	predictions are ... predictions!  guesses.  swag.   nothing more/less.
	
	i will say this however.  after fifteen years, I am exhausted listening to
	
	ipv6 v. ipv4  bickering.   (and after five years of running native ipv6-only

	networks - i've re-introduced ipv4 to the mix... go figure)

/bill


From keegan.holley at sungard.com  Sat Dec 10 10:17:32 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sat, 10 Dec 2011 11:17:32 -0500
Subject: Sad IPv4 story?
In-Reply-To: <4ee34f53.e616440a.269a.ffffd8dcSMTPIN_ADDED@mx.google.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <4ee34f53.e616440a.269a.ffffd8dcSMTPIN_ADDED@mx.google.com>
Message-ID: <CABO8Q6SK9Bf2rp10PiKVfAbgzqscWOVX4=Q5kJBUX6=aO39x1Q@mail.gmail.com>

2011/12/10 <bmanning at vacation.karoshi.com>

> On Sat, Dec 10, 2011 at 03:15:01AM -0500, Keegan Holley wrote:
> >
> >
> > Sent from my iPhone
> >
> > On Dec 10, 2011, at 2:58 AM, Randy Bush <randy at psg.com> wrote:
> >
> > >> I just had a personal email from a brand new ISP in the Asia-Pacific
> > >> area desperately looking for enough IPv4 to be able to run their
> > >> business the way they would likeb &
> > >
> > > and we are supposed to be surprised or feel sorry?  you're kidding,
> > > right?  they're lucky to be in a/p.  at least they can get a /22.
> > >
> > > i especially like the "the way they would like" part.  the way i would
> > > like to run my business is to go into the office every friday and scoop
> > > up the cash that fell from the sky all week.
> > >
> > > reality is such a pain in the ass.
> > >
> > > randy
> > >
> > +1 aren't we way past all of the predicted exhaustion dates.  There are
> slot of as's that have ignored this.
> > >
> >
>
>         predictions are ... predictions!  guesses.  swag.   nothing
> more/less.
>
>        i will say this however.  after fifteen years, I am exhausted
> listening to
>
>        ipv6 v. ipv4  bickering.   (and after five years of running native
> ipv6-only
>
>        networks - i've re-introduced ipv4 to the mix... go figure)
>
> /bill
>
> I see your point.  The world was supposed to end dozens of times as well.
 Sorry to hear you had to reintroduce v4.  I suppose if dinosaurs were
still around we'd have to capitulate to them too.  The people who see a
T-rex and say "hey I thought they were extinct?!" would just get eaten. but
I digress. I'm not sure I'd open a new ISP at this point and expect to get
any respectable amount of IP space from the RIR right now.

From bmanning at vacation.karoshi.com  Sat Dec 10 11:07:06 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sat, 10 Dec 2011 17:07:06 +0000
Subject: Sad IPv4 story?
In-Reply-To: <CABO8Q6SK9Bf2rp10PiKVfAbgzqscWOVX4=Q5kJBUX6=aO39x1Q@mail.gmail.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <4ee34f53.e616440a.269a.ffffd8dcSMTPIN_ADDED@mx.google.com>
 <CABO8Q6SK9Bf2rp10PiKVfAbgzqscWOVX4=Q5kJBUX6=aO39x1Q@mail.gmail.com>
Message-ID: <20111210170706.GA6745@vacation.karoshi.com.>

On Sat, Dec 10, 2011 at 11:17:32AM -0500, Keegan Holley wrote:
> 2011/12/10 <bmanning at vacation.karoshi.com>
> 
> > On Sat, Dec 10, 2011 at 03:15:01AM -0500, Keegan Holley wrote:
> > >
> > >
> > > Sent from my iPhone
> > >
> > > On Dec 10, 2011, at 2:58 AM, Randy Bush <randy at psg.com> wrote:
> > >
> > > >> I just had a personal email from a brand new ISP in the Asia-Pacific
> > > >> area desperately looking for enough IPv4 to be able to run their
> > > >> business the way they would likeb &
> > > >
> > > > and we are supposed to be surprised or feel sorry?  you're kidding,
> > > > right?  they're lucky to be in a/p.  at least they can get a /22.
> > > >
> > > > i especially like the "the way they would like" part.  the way i would
> > > > like to run my business is to go into the office every friday and scoop
> > > > up the cash that fell from the sky all week.
> > > >
> > > > reality is such a pain in the ass.
> > > >
> > > > randy
> > > >
> > > +1 aren't we way past all of the predicted exhaustion dates.  There are
> > slot of as's that have ignored this.
> > > >
> > >
> >
> >         predictions are ... predictions!  guesses.  swag.   nothing
> > more/less.
> >
> >        i will say this however.  after fifteen years, I am exhausted
> > listening to
> >
> >        ipv6 v. ipv4  bickering.   (and after five years of running native
> > ipv6-only
> >
> >        networks - i've re-introduced ipv4 to the mix... go figure)
> >
> > /bill
> >
> > I see your point.  The world was supposed to end dozens of times as well.
>  Sorry to hear you had to reintroduce v4.  I suppose if dinosaurs were
> still around we'd have to capitulate to them too.  The people who see a
> T-rex and say "hey I thought they were extinct?!" would just get eaten. but
> I digress. I'm not sure I'd open a new ISP at this point and expect to get
> any respectable amount of IP space from the RIR right now.

	funny thing about tools.  good ones are around and used for years, decades,
	centuries, while others have a much shorter shelf life.

	the craftsman 3/16" and the 1/4" phillips I got from my grandfather and will
	likely end up w/ one of my grandsons.  the pocket fisherman and the 87blade
	pocket knife are ebay fodder...  

	its not about capitulation, its about usefullness.  the only concern about
	IPv4 these days is one of global uniqueness.  the big win, if you can call it
	a big win is that there is much less potential pressure on the global routing
	table if you stick w/ IPv4. (*)

* in both v4/v6 families, the prospect of fully routing /32s scares to socks off most
  sane engineers.  the horror of v6 is fully routing /48s!!!!

/bill


From netsecguy at gmail.com  Sat Dec 10 13:49:01 2011
From: netsecguy at gmail.com (NetSecGuy)
Date: Sat, 10 Dec 2011 14:49:01 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
Message-ID: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>

I have a Linode VPS in Japan that I can't access from Verizon FIOS,
but can access from other locations.  I'm not sure who to blame.

The host, 106.187.34.33, is behind the gateway 106.187.34.1:

>From FIOS to 106.187.34.1  (this works).

traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets

 4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  9.960 ms
9.957 ms  6.666 ms
 5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
12.298 ms  13.463 ms  13.706 ms
 6  0.ae2.br1.iad8.alter.net (152.63.32.158)  14.571 ms  14.372 ms  14.003 ms
 7  204.255.169.218 (204.255.169.218)  14.692 ms  14.759 ms  13.670 ms
 8  sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229)  13.077 ms
12.577 ms  14.954 ms
 9  sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200)  31.443 ms
    sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37)  33.005 ms
    sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200)  31.507 ms
10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  57.610 ms
58.322 ms  59.098 ms
11  otejbb204.kddnet.ad.jp (203.181.100.45)  196.063 ms
    otejbb203.kddnet.ad.jp (203.181.100.13)  188.846 ms
    otejbb204.kddnet.ad.jp (203.181.100.21)  195.277 ms
12  cm-fcu203.kddnet.ad.jp (124.215.194.180)  214.760 ms
    cm-fcu203.kddnet.ad.jp (124.215.194.164)  198.925 ms
    cm-fcu203.kddnet.ad.jp (124.215.194.180)  200.583 ms
13  124.215.199.122 (124.215.199.122)  193.086 ms *  194.967 ms

This does not work from FIOS:

traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets

 4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  34.229 ms
8.743 ms  8.878 ms
 5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
15.402 ms  13.008 ms  14.932 ms
 6  0.ae2.br1.iad8.alter.net (152.63.32.158)  13.325 ms  13.245 ms  13.802 ms
 7  204.255.169.218 (204.255.169.218)  14.820 ms  14.232 ms  13.491 ms
 8  lap-brdr-03.inet.qwest.net (67.14.22.78)  90.170 ms  92.273 ms  145.887 ms
 9  63.146.26.70 (63.146.26.70)  92.482 ms  92.287 ms  94.000 ms
10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.135 ms
58.520 ms  58.055 ms
11  otejbb203.kddnet.ad.jp (203.181.100.17)  205.844 ms
    otejbb204.kddnet.ad.jp (203.181.100.25)  189.929 ms
    otejbb203.kddnet.ad.jp (203.181.100.17)  204.846 ms
12  sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77)  87.229 ms
    sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  88.796 ms  88.717 ms
13  124.215.199.122 (124.215.199.122)  193.584 ms  202.208 ms  192.989 ms
14  * * *

Same IP from different network:

traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets

 6  ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105)  2.230 ms  1.847
ms  1.938 ms
 7  ae-92-92.csw4.Washington1.Level3.net (4.69.134.158)  2.010 ms
1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146)  1.942 ms
 8  ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189)  12.515 ms
ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181)  12.519 ms  12.507
ms
 9  ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81)  65.957 ms
65.958 ms  66.056 ms
10  ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42)  66.063 ms
ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46)  65.985 ms
ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34)  66.026 ms
11  ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143)  66.162 ms
66.160 ms  66.238 ms
12  KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14)  193.317 ms
 193.447 ms  193.305 ms
13  lajbb001.kddnet.ad.jp (59.128.2.101)  101.544 ms  101.543 ms
lajbb002.kddnet.ad.jp (59.128.2.185)  66.563 ms
14  otejbb203.kddnet.ad.jp (203.181.100.13)  164.217 ms  164.221 ms  164.330 ms
15  cm-fcu203.kddnet.ad.jp (124.215.194.164)  180.350 ms
cm-fcu203.kddnet.ad.jp (124.215.194.180)  172.779 ms
cm-fcu203.kddnet.ad.jp (124.215.194.164)  185.824 ms
16  124.215.199.122 (124.215.199.122)  175.703 ms  175.700 ms  168.268 ms
17  li377-33.members.linode.com (106.187.34.33)  174.381 ms  174.383
ms  174.368 ms

The last hop is KDDI, but things work from via Level3 and not sprint.
Linode blames Verizon, but I'm not seeing how it's them.

Any ideas?


From derek at derekivey.com  Sat Dec 10 15:52:01 2011
From: derek at derekivey.com (Derek Ivey)
Date: Sat, 10 Dec 2011 16:52:01 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
Message-ID: <4EE3D481.2030007@derekivey.com>

Do you have a firewall running on the Linode VPS? Any chance something 
like fail2ban blocked your IP for too many invalid logins? Are you able 
to ping your FIOS IP from the VPS? Try doing a traceroute on the VPS to 
your FIOS IP. Perhaps there is some issue getting back to you. Based on 
the traceroutes you provided, it doesn't look like Verizon's issue.

Derek

On 12/10/2011 2:49 PM, NetSecGuy wrote:
> I have a Linode VPS in Japan that I can't access from Verizon FIOS,
> but can access from other locations.  I'm not sure who to blame.
>
> The host, 106.187.34.33, is behind the gateway 106.187.34.1:
>
>  From FIOS to 106.187.34.1  (this works).
>
> traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets
>
>   4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  9.960 ms
> 9.957 ms  6.666 ms
>   5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 12.298 ms  13.463 ms  13.706 ms
>   6  0.ae2.br1.iad8.alter.net (152.63.32.158)  14.571 ms  14.372 ms  14.003 ms
>   7  204.255.169.218 (204.255.169.218)  14.692 ms  14.759 ms  13.670 ms
>   8  sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229)  13.077 ms
> 12.577 ms  14.954 ms
>   9  sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200)  31.443 ms
>      sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37)  33.005 ms
>      sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200)  31.507 ms
> 10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  57.610 ms
> 58.322 ms  59.098 ms
> 11  otejbb204.kddnet.ad.jp (203.181.100.45)  196.063 ms
>      otejbb203.kddnet.ad.jp (203.181.100.13)  188.846 ms
>      otejbb204.kddnet.ad.jp (203.181.100.21)  195.277 ms
> 12  cm-fcu203.kddnet.ad.jp (124.215.194.180)  214.760 ms
>      cm-fcu203.kddnet.ad.jp (124.215.194.164)  198.925 ms
>      cm-fcu203.kddnet.ad.jp (124.215.194.180)  200.583 ms
> 13  124.215.199.122 (124.215.199.122)  193.086 ms *  194.967 ms
>
> This does not work from FIOS:
>
> traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets
>
>   4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  34.229 ms
> 8.743 ms  8.878 ms
>   5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 15.402 ms  13.008 ms  14.932 ms
>   6  0.ae2.br1.iad8.alter.net (152.63.32.158)  13.325 ms  13.245 ms  13.802 ms
>   7  204.255.169.218 (204.255.169.218)  14.820 ms  14.232 ms  13.491 ms
>   8  lap-brdr-03.inet.qwest.net (67.14.22.78)  90.170 ms  92.273 ms  145.887 ms
>   9  63.146.26.70 (63.146.26.70)  92.482 ms  92.287 ms  94.000 ms
> 10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.135 ms
> 58.520 ms  58.055 ms
> 11  otejbb203.kddnet.ad.jp (203.181.100.17)  205.844 ms
>      otejbb204.kddnet.ad.jp (203.181.100.25)  189.929 ms
>      otejbb203.kddnet.ad.jp (203.181.100.17)  204.846 ms
> 12  sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77)  87.229 ms
>      sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  88.796 ms  88.717 ms
> 13  124.215.199.122 (124.215.199.122)  193.584 ms  202.208 ms  192.989 ms
> 14  * * *
>
> Same IP from different network:
>
> traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets
>
>   6  ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105)  2.230 ms  1.847
> ms  1.938 ms
>   7  ae-92-92.csw4.Washington1.Level3.net (4.69.134.158)  2.010 ms
> 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146)  1.942 ms
>   8  ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189)  12.515 ms
> ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181)  12.519 ms  12.507
> ms
>   9  ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81)  65.957 ms
> 65.958 ms  66.056 ms
> 10  ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42)  66.063 ms
> ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46)  65.985 ms
> ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34)  66.026 ms
> 11  ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143)  66.162 ms
> 66.160 ms  66.238 ms
> 12  KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14)  193.317 ms
>   193.447 ms  193.305 ms
> 13  lajbb001.kddnet.ad.jp (59.128.2.101)  101.544 ms  101.543 ms
> lajbb002.kddnet.ad.jp (59.128.2.185)  66.563 ms
> 14  otejbb203.kddnet.ad.jp (203.181.100.13)  164.217 ms  164.221 ms  164.330 ms
> 15  cm-fcu203.kddnet.ad.jp (124.215.194.164)  180.350 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.180)  172.779 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.164)  185.824 ms
> 16  124.215.199.122 (124.215.199.122)  175.703 ms  175.700 ms  168.268 ms
> 17  li377-33.members.linode.com (106.187.34.33)  174.381 ms  174.383
> ms  174.368 ms
>
> The last hop is KDDI, but things work from via Level3 and not sprint.
> Linode blames Verizon, but I'm not seeing how it's them.
>
> Any ideas?
>



From stb at lassitu.de  Sat Dec 10 18:11:54 2011
From: stb at lassitu.de (Stefan Bethke)
Date: Sun, 11 Dec 2011 01:11:54 +0100
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
Message-ID: <6F2C07FD-0C60-4010-938D-E5976B513803@lassitu.de>

Am 10.12.2011 um 20:49 schrieb NetSecGuy:

> This does not work from FIOS:
> 
> traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets
> 
> 4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  34.229 ms
> 8.743 ms  8.878 ms
> 5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 15.402 ms  13.008 ms  14.932 ms
> 6  0.ae2.br1.iad8.alter.net (152.63.32.158)  13.325 ms  13.245 ms  13.802 ms
> 7  204.255.169.218 (204.255.169.218)  14.820 ms  14.232 ms  13.491 ms
> 8  lap-brdr-03.inet.qwest.net (67.14.22.78)  90.170 ms  92.273 ms  145.887 ms
> 9  63.146.26.70 (63.146.26.70)  92.482 ms  92.287 ms  94.000 ms
> 10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.135 ms
> 58.520 ms  58.055 ms
> 11  otejbb203.kddnet.ad.jp (203.181.100.17)  205.844 ms
>    otejbb204.kddnet.ad.jp (203.181.100.25)  189.929 ms
>    otejbb203.kddnet.ad.jp (203.181.100.17)  204.846 ms
> 12  sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77)  87.229 ms
>    sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  88.796 ms  88.717 ms
> 13  124.215.199.122 (124.215.199.122)  193.584 ms  202.208 ms  192.989 ms
> 14  * * *

From FIOS in BOS:
 3  g14-0-7-1544.bstnma-lcr-05.verizon-gni.net (130.81.49.80)  132.408 ms  130.742 ms  139.945 ms
 4  so-7-2-0-0.bos-bb-rtr1.verizon-gni.net (130.81.29.172)  132.405 ms  137.776 ms  134.929 ms
 5  so-9-1-0-0.ny325-bb-rtr1.verizon-gni.net (130.81.19.70)  139.872 ms  141.344 ms  150.117 ms
 6  0.so-0-0-0.xt1.nyc4.alter.net (152.63.1.41)  142.381 ms  141.256 ms  139.873 ms
 7  0.ae3.br2.nyc4.alter.net (152.63.3.110)  169.904 ms  169.769 ms  167.357 ms
 8  nyc-brdr-02.inet.qwest.net (63.146.27.209)  140.164 ms  142.500 ms  142.880 ms
 9  lap-brdr-03.inet.qwest.net (67.14.22.78)  274.856 ms  226.176 ms  232.839 ms
10  63.146.26.70 (63.146.26.70)  224.891 ms  223.915 ms  225.082 ms
11  lajbb002.kddnet.ad.jp (59.128.2.73)  227.355 ms
    lajbb001.kddnet.ad.jp (59.128.2.173)  236.509 ms
    lajbb002.kddnet.ad.jp (59.128.2.177)  226.723 ms
12  otejbb204.kddnet.ad.jp (203.181.100.25)  324.419 ms
    otejbb203.kddnet.ad.jp (203.181.100.13)  336.141 ms
    otejbb204.kddnet.ad.jp (203.181.100.45)  330.458 ms
13  cm-fcu203.kddnet.ad.jp (124.215.194.164)  336.209 ms
    cm-fcu203.kddnet.ad.jp (124.215.194.180)  334.191 ms
    cm-fcu203.kddnet.ad.jp (124.215.194.164)  327.027 ms
14  124.215.199.122 (124.215.199.122)  334.904 ms  324.853 ms *

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811





From eyeronic.design at gmail.com  Sat Dec 10 18:33:06 2011
From: eyeronic.design at gmail.com (Mike Hale)
Date: Sat, 10 Dec 2011 16:33:06 -0800
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <6F2C07FD-0C60-4010-938D-E5976B513803@lassitu.de>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <6F2C07FD-0C60-4010-938D-E5976B513803@lassitu.de>
Message-ID: <CAN3um4zGYCUXg+Rzq60tQ-WE7stncZEknWbTBSy+M7nEXjz7sQ@mail.gmail.com>

Disable your firewall and run TCPDump on your host when you try to ping
it.

Does the ICMP packet get to your host?
On Sat, Dec 10, 2011 at 4:11 PM, Stefan Bethke <stb at lassitu.de> wrote:

> Am 10.12.2011 um 20:49 schrieb NetSecGuy:
>
> > This does not work from FIOS:
> >
> > traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets
> >
> > 4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  34.229 ms
> > 8.743 ms  8.878 ms
> > 5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> > 15.402 ms  13.008 ms  14.932 ms
> > 6  0.ae2.br1.iad8.alter.net (152.63.32.158)  13.325 ms  13.245 ms
>  13.802 ms
> > 7  204.255.169.218 (204.255.169.218)  14.820 ms  14.232 ms  13.491 ms
> > 8  lap-brdr-03.inet.qwest.net (67.14.22.78)  90.170 ms  92.273 ms
>  145.887 ms
> > 9  63.146.26.70 (63.146.26.70)  92.482 ms  92.287 ms  94.000 ms
> > 10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.135 ms
> > 58.520 ms  58.055 ms
> > 11  otejbb203.kddnet.ad.jp (203.181.100.17)  205.844 ms
> >    otejbb204.kddnet.ad.jp (203.181.100.25)  189.929 ms
> >    otejbb203.kddnet.ad.jp (203.181.100.17)  204.846 ms
> > 12  sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77)  87.229 ms
> >    sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  88.796 ms
>  88.717 ms
> > 13  124.215.199.122 (124.215.199.122)  193.584 ms  202.208 ms  192.989 ms
> > 14  * * *
>
> From FIOS in BOS:
>  3  g14-0-7-1544.bstnma-lcr-05.verizon-gni.net (130.81.49.80)  132.408 ms
>  130.742 ms  139.945 ms
>  4  so-7-2-0-0.bos-bb-rtr1.verizon-gni.net (130.81.29.172)  132.405 ms
>  137.776 ms  134.929 ms
>  5  so-9-1-0-0.ny325-bb-rtr1.verizon-gni.net (130.81.19.70)  139.872 ms
>  141.344 ms  150.117 ms
>  6  0.so-0-0-0.xt1.nyc4.alter.net (152.63.1.41)  142.381 ms  141.256 ms
>  139.873 ms
>  7  0.ae3.br2.nyc4.alter.net (152.63.3.110)  169.904 ms  169.769 ms
>  167.357 ms
>  8  nyc-brdr-02.inet.qwest.net (63.146.27.209)  140.164 ms  142.500 ms
>  142.880 ms
>  9  lap-brdr-03.inet.qwest.net (67.14.22.78)  274.856 ms  226.176 ms
>  232.839 ms
> 10  63.146.26.70 (63.146.26.70)  224.891 ms  223.915 ms  225.082 ms
> 11  lajbb002.kddnet.ad.jp (59.128.2.73)  227.355 ms
>    lajbb001.kddnet.ad.jp (59.128.2.173)  236.509 ms
>    lajbb002.kddnet.ad.jp (59.128.2.177)  226.723 ms
> 12  otejbb204.kddnet.ad.jp (203.181.100.25)  324.419 ms
>    otejbb203.kddnet.ad.jp (203.181.100.13)  336.141 ms
>    otejbb204.kddnet.ad.jp (203.181.100.45)  330.458 ms
> 13  cm-fcu203.kddnet.ad.jp (124.215.194.164)  336.209 ms
>    cm-fcu203.kddnet.ad.jp (124.215.194.180)  334.191 ms
>    cm-fcu203.kddnet.ad.jp (124.215.194.164)  327.027 ms
> 14  124.215.199.122 (124.215.199.122)  334.904 ms  324.853 ms *
>
> --
> Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811
>
>
>
>
>


-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

From bzs at world.std.com  Sat Dec 10 19:48:45 2011
From: bzs at world.std.com (Barry Shein)
Date: Sat, 10 Dec 2011 20:48:45 -0500
Subject: Sad IPv4 story?
In-Reply-To: <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
Message-ID: <20196.3069.632519.601259@world.std.com>


>> I just had a personal email from a brand new ISP in the Asia-Pacific
>> area desperately looking for enough IPv4 to be able to run their
>> business the way they would like?

This sniping elicited by the above seems inappropriate and
unprofessional, the request/anecdote seemed reasonable and could
elicit solutions such as partnerships, etc.

-- 
        -Barry Shein

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


From Valdis.Kletnieks at vt.edu  Sat Dec 10 22:07:06 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 10 Dec 2011 23:07:06 -0500
Subject: Sad IPv4 story?
In-Reply-To: Your message of "Sat, 10 Dec 2011 20:48:45 EST."
 <20196.3069.632519.601259@world.std.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
Message-ID: <15282.1323576426@turing-police.cc.vt.edu>

On Sat, 10 Dec 2011 20:48:45 EST, Barry Shein said:
> >> I just had a personal email from a brand new ISP in the Asia-Pacific
> >> area desperately looking for enough IPv4 to be able to run their
> >> business the way they would like?
>
> This sniping elicited by the above seems inappropriate and
> unprofessional, the request/anecdote seemed reasonable and could
> elicit solutions such as partnerships, etc.

No Barry, I respectfully disagree.  It's almost 2012.  The first predictions of
IPv4 exhaustion were made *last century*.  We've been predicting it to the
month level for like 5 years now.  Any business that is making business plans
and models that doesn't take "we may not get IPv4 space" into account and have
a contingency plan for that *deserves* to be soundly mocked and ridiculed in
public.
-------------- 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/20111210/820bb657/attachment.bin>

From randy at psg.com  Sat Dec 10 22:18:06 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 11 Dec 2011 13:18:06 +0900
Subject: Sad IPv4 story?
In-Reply-To: <20196.3069.632519.601259@world.std.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
Message-ID: <m2ehwbd9mp.wl%randy@psg.com>

>>> I just had a personal email from a brand new ISP in the Asia-Pacific
>>> area desperately looking for enough IPv4 to be able to run their
>>> business the way they would like?
> 
> This sniping elicited by the above seems inappropriate and
> unprofessional, the request/anecdote seemed reasonable and could
> elicit solutions such as partnerships, etc.

i am sure they look forward to your generous offer.

randy


From randy at psg.com  Sat Dec 10 22:38:02 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 11 Dec 2011 13:38:02 +0900
Subject: Sad IPv4 story?
In-Reply-To: <15282.1323576426@turing-police.cc.vt.edu>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
 <15282.1323576426@turing-police.cc.vt.edu>
Message-ID: <m2borfd8ph.wl%randy@psg.com>

> No Barry, I respectfully disagree.  It's almost 2012.  The first
> predictions of IPv4 exhaustion were made *last century*.  We've been
> predicting it to the month level for like 5 years now.  Any business
> that is making business plans and models that doesn't take "we may not
> get IPv4 space" into account and have a contingency plan for that
> *deserves* to be soundly mocked and ridiculed in public.

mocking someone who shows up when the party is already over is not
overly kind or useful.  making clear to the world that the part is over
is more useful.  i could not decide between a number of very appropriate
floyd songs, but i think 'time' says it well

    Ticking away the moments that make up a dull day 
    Fritter and waste the hours in an offhand way
    Kicking around on a piece of ground in your home town
    Waiting for someone or something to show you the way

    Tired of lying in the sunshine staying home to watch the rain
    And you are young and life is long and there is time to kill today
    And then one day you find ten years have got behind you
    No one told you when to run, you missed the starting gun

    And you run and you run to catch up with the sun, but it's sinking
    Racing around to come up behind you again
    The sun is the same in a relative way, but you're older
    Shorter of breath and one day closer to death

    Every year is getting shorter, never seem to find the time
    Plans that either come to naught or half a page of scribbled lines
    Hanging on quiet desperation is the English way
    The time is gone, the song is over, thought I'd something more to say

randy


From joelja at bogus.com  Sat Dec 10 23:42:04 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Sat, 10 Dec 2011 21:42:04 -0800
Subject: Sad IPv4 story?
In-Reply-To: <20196.3069.632519.601259@world.std.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
Message-ID: <4EE442AC.1020309@bogus.com>

On 12/10/11 17:48 , Barry Shein wrote:
> 
>>> I just had a personal email from a brand new ISP in the Asia-Pacific
>>> area desperately looking for enough IPv4 to be able to run their
>>> business the way they would like?
> 
> This sniping elicited by the above seems inappropriate and
> unprofessional, the request/anecdote seemed reasonable and could
> elicit solutions such as partnerships, etc.

engineering solutions work with the constraints at hand.

The maximum ipv4 delegation size to be issued in apnic is a /22. one has
to assume that when it's gone it's gone.

given that constraint, I know how I'd build it.



From tagno25 at gmail.com  Sat Dec 10 23:43:11 2011
From: tagno25 at gmail.com (Philip Dorr)
Date: Sat, 10 Dec 2011 21:43:11 -0800
Subject: Sad IPv4 story?
In-Reply-To: <m2borfd8ph.wl%randy@psg.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
 <15282.1323576426@turing-police.cc.vt.edu> <m2borfd8ph.wl%randy@psg.com>
Message-ID: <CABidiT+Yx_AB09x8FDfu3odcDxqUnbB0Fbt=_iQwYXifWoarQQ@mail.gmail.com>

On Sat, Dec 10, 2011 at 8:38 PM, Randy Bush <randy at psg.com> wrote:
>> No Barry, I respectfully disagree. ?It's almost 2012. ?The first
>> predictions of IPv4 exhaustion were made *last century*. ?We've been
>> predicting it to the month level for like 5 years now. ?Any business
>> that is making business plans and models that doesn't take "we may not
>> get IPv4 space" into account and have a contingency plan for that
>> *deserves* to be soundly mocked and ridiculed in public.
>
> mocking someone who shows up when the party is already over is not
> overly kind or useful. ?making clear to the world that the part is over
> is more useful.

The party is not over, it is just moving from a house to a stadium,
with a large drive between.


From mysidia at gmail.com  Sat Dec 10 23:54:08 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 10 Dec 2011 23:54:08 -0600
Subject: Sad IPv4 story?
In-Reply-To: <CABidiT+Yx_AB09x8FDfu3odcDxqUnbB0Fbt=_iQwYXifWoarQQ@mail.gmail.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
 <15282.1323576426@turing-police.cc.vt.edu>
 <m2borfd8ph.wl%randy@psg.com>
 <CABidiT+Yx_AB09x8FDfu3odcDxqUnbB0Fbt=_iQwYXifWoarQQ@mail.gmail.com>
Message-ID: <CAAAwwbU7f1DFsZRpfxh7r7-wVL-TgSjuyuDSvFDoz0_fgutD=g@mail.gmail.com>

On Sat, Dec 10, 2011 at 11:43 PM, Philip Dorr <tagno25 at gmail.com> wrote:
> On Sat, Dec 10, 2011 at 8:38 PM, Randy Bush <randy at psg.com> wrote:
>> mocking someone who shows up when the party is already over is not
>> overly kind or useful. ?making clear to the world that the part is over

> The party is not over, it is just moving from a house to a stadium,
> with a large drive between.

That's a different party.     It doesn't really get started until
people arrive at it.

So far the IPv6 party's been pretty small due to the expense of the rocket ship
upgrades required to reach the planet that party is going to be held on.

-- 
-JH


From joelja at bogus.com  Sun Dec 11 00:03:50 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Sat, 10 Dec 2011 22:03:50 -0800
Subject: Sad IPv4 story?
In-Reply-To: <4EE442AC.1020309@bogus.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com> <4EE442AC.1020309@bogus.com>
Message-ID: <4EE447C6.8040308@bogus.com>

On 12/10/11 21:42 , Joel jaeggli wrote:
> On 12/10/11 17:48 , Barry Shein wrote:
>>
>>>> I just had a personal email from a brand new ISP in the Asia-Pacific
>>>> area desperately looking for enough IPv4 to be able to run their
>>>> business the way they would like?
>>
>> This sniping elicited by the above seems inappropriate and
>> unprofessional, the request/anecdote seemed reasonable and could
>> elicit solutions such as partnerships, etc.
> 
> engineering solutions work with the constraints at hand.
> 
> The maximum ipv4 delegation size to be issued in apnic is a /22. one has
> to assume that when it's gone it's gone.
> 
> given that constraint, I know how I'd build it.

Setting aside the sad story part for the moment, Would this be a good
subject for a BOF? Are there others who would be willing to participate
(residendential,transit or dc operators, and potentially vendors of
equipment or address transfer brokers).

I'd call it something like:

IPV4 runout - Doing more with less.

* IPV4 runout means new entrants will from the outset deploy techniques
  the present operators consider undesirable.

* IPV6 should be appearing as part and parcel of new greenfield projects
I would think.

* On the vendor side CGN hardware is becoming a mature product space.

* Datacenter/ICP operators confront a similar set of problems both
supporting outgoing connections for large pools and incoming termination.



> 



From randy at psg.com  Sun Dec 11 01:14:19 2011
From: randy at psg.com (Randy Bush)
Date: Sun, 11 Dec 2011 16:14:19 +0900
Subject: Sad IPv4 story?
In-Reply-To: <CAAAwwbU7f1DFsZRpfxh7r7-wVL-TgSjuyuDSvFDoz0_fgutD=g@mail.gmail.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
 <15282.1323576426@turing-police.cc.vt.edu>
 <m2borfd8ph.wl%randy@psg.com>
 <CABidiT+Yx_AB09x8FDfu3odcDxqUnbB0Fbt=_iQwYXifWoarQQ@mail.gmail.com>
 <CAAAwwbU7f1DFsZRpfxh7r7-wVL-TgSjuyuDSvFDoz0_fgutD=g@mail.gmail.com>
Message-ID: <m262hnd1h0.wl%randy@psg.com>

> So far the IPv6 party's been pretty small due to the expense of the
> rocket ship upgrades required to reach the planet that party is going
> to be held on.

for those of us who have been here on B-612 nuturing the rose for over
a decade, you 'adult' geographers seem to live on a very grey and
depressing asteroid.

randy


From jcurran at arin.net  Sun Dec 11 05:52:21 2011
From: jcurran at arin.net (John Curran)
Date: Sun, 11 Dec 2011 11:52:21 +0000
Subject: Sad IPv4 story?
In-Reply-To: <CB07955B.497B3%fmartin@linkedin.com>
References: <CB07955B.497B3%fmartin@linkedin.com>
Message-ID: <F1612CA4-8B27-4509-BD4F-568F553744C6@corp.arin.net>

On Dec 9, 2011, at 1:37 PM, Franck Martin wrote:

> I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like?
> 
> This is just a data point.

Franck - 
 
  Thanks for the data point - I'm certain there are others folks
  out there with similar experiences that we're not hearing about.

  Of course, the theory was that at this point they'd be able to 
  use IPv6 to connect customers up to the Internet. Such theory 
  was predicated on a presumed strong motivation for everyone already
  connected via IPv4 to deploy IPv6 in parallel (i.e. dual-stack) and 
  some elusive TBD transition mechanisms which were to make IPv6 
  customers interoperate with those that hadn't yet deployed IPv6  
  in parallel.  

  Reality looks very different, in that existing organizations
  find it difficult to understand why to add IPv6 connectivity to 
  their existing public-facing servers, and the state of the art in 
  achieving transparent operation for IPv6 connected systems to the 
  rest of the Internet running only IPv4 is still effectively a 
  work-in-progress...

  While your data point may be from the Asia-Pacific region, that
  same story is going to repeated in every region (RIPE NCC will
  be running out shortly, and ARIN has 1 to 2 years depending on
  the actual request rate that materializes)  Service providers in
  the ARIN region need to carefully consider their answer to that
  same situation, because it will be occurring here soon enough.

  There is one thing that everyone can do to reduce the impact of
  this transition, and this is getting in front of their business
  customers (and small business/power users who have public-facing
  content) to explain that the Internet is going be running IPv4
  and IPv6 for quite some time in parallel and that getting their
  public-facing servers connected up also via IPv6 is a very good
  idea (if anyone wants help doing this sort of customer education 
  ARIN's https://www.arin.net/knowledge, NRO's http://www.nro.net/ipv6, 
  and APNIC's IPv6 Act Now http://www.ipv6actnow.org web sites are all 
  good sources on materials for this sort of effort.)

  The sooner we get the content on IPv6 in addition to IPv4, the sooner 
  that connecting new customers up via IPv6 without additional unique 
  IPv4 address space becomes viable (and obviously if we had the vast
  majority of content already on IPv6, then connecting new customers 
  via IPv6 would be simple indeed.)

FYI,
/John

John Curran
President and CEO
ARIN




From eric at eparsonage.com  Sun Dec 11 07:41:08 2011
From: eric at eparsonage.com (Eric Parsonage)
Date: Mon, 12 Dec 2011 00:11:08 +1030
Subject: Sad IPv4 story?
In-Reply-To: <15282.1323576426@turing-police.cc.vt.edu>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
 <15282.1323576426@turing-police.cc.vt.edu>
Message-ID: <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com>


On 11/12/2011, at 2:37 PM, Valdis.Kletnieks at vt.edu wrote:

> On Sat, 10 Dec 2011 20:48:45 EST, Barry Shein said:
>>>> I just had a personal email from a brand new ISP in the Asia-Pacific
>>>> area desperately looking for enough IPv4 to be able to run their
>>>> business the way they would like?
>> 
>> This sniping elicited by the above seems inappropriate and
>> unprofessional, the request/anecdote seemed reasonable and could
>> elicit solutions such as partnerships, etc.
> 
> No Barry, I respectfully disagree.  It's almost 2012.  The first predictions of
> IPv4 exhaustion were made *last century*.  We've been predicting it to the
> month level for like 5 years now.  Any business that is making business plans
> and models that doesn't take "we may not get IPv4 space" into account and have
> a contingency plan for that *deserves* to be soundly mocked and ridiculed in
> public.


You could take this one step further and say any industry that has had this much warning and hasn?t taken it into account *deserves* to be soundly mocked and ridiculed in public. 

From ler762 at gmail.com  Sun Dec 11 08:44:21 2011
From: ler762 at gmail.com (Lee)
Date: Sun, 11 Dec 2011 09:44:21 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
Message-ID: <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>

On 12/10/11, NetSecGuy <netsecguy at gmail.com> wrote:
> I have a Linode VPS in Japan that I can't access from Verizon FIOS,
> but can access from other locations.  I'm not sure who to blame.

I can't get to 106.187.34.33 or 106.187.34.1 using Verizon FIOS

C:\>tracert 106.187.34.33

Tracing route to li377-33.members.linode.com [106.187.34.33]
over a maximum of 30 hops:
    [.. snip ..]
  5    23 ms     4 ms     4 ms
so-14-0-0-0.RES-BB-RTR2.verizon-gni.net [130.81.22.56]
  6    73 ms     6 ms     7 ms  0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73]
  7     8 ms     6 ms     7 ms  dcp-brdr-03.inet.qwest.net [63.146.26.105]
  8     8 ms     9 ms     9 ms  sl-crs1-dc-0-1-0-0.sprintlink.net
[144.232.19.229]
  9    28 ms    26 ms    44 ms  sl-crs1-dc-0-5-3-0.sprintlink.net
[144.232.24.37]
 10   177 ms   176 ms   177 ms  lajbb001.kddnet.ad.jp [59.128.2.173]
 11    43 ms    41 ms    42 ms  sl-crs1-oma-0-9-2-0.sprintlink.net
[144.232.2.177]
 12   291 ms     *      301 ms  cm-fcu203.kddnet.ad.jp [124.215.194.164]
 13   286 ms   279 ms   282 ms  124.215.199.122
 14    81 ms    81 ms    82 ms  sl-crs1-sj-0-5-3-0.sprintlink.net
[144.232.20.99]
 15    88 ms    86 ms    87 ms  sl-st20-pa-9-0-0.sprintlink.net [144.232.8.108]
 16   405 ms   406 ms   399 ms  144.223.243.126
 17   364 ms   386 ms   406 ms  pajbb001.kddnet.ad.jp [111.87.3.41]
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *     ^C

C:\>tracert 106.187.34.1

Tracing route to gw-li377.linode.com [106.187.34.1]
over a maximum of 30 hops:
    [.. snip ..]
  5     5 ms    24 ms    24 ms  so-3-1-0-0.RES-BB-RTR2.verizon-gni.net
[130.81.151.232]
  6     7 ms     7 ms     7 ms  0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73]
  7     8 ms     7 ms     7 ms  dcp-brdr-03.inet.qwest.net [63.146.26.105]
  8    84 ms    84 ms    84 ms  lap-brdr-03.inet.qwest.net [67.14.22.78]
  9   171 ms   174 ms   176 ms  63.146.26.70
 10   178 ms   177 ms   177 ms  lajbb001.kddnet.ad.jp [59.128.2.173]
 11   283 ms   284 ms   284 ms  otejbb203.kddnet.ad.jp [203.181.100.9]
 12   289 ms   287 ms   287 ms  cm-fcu203.kddnet.ad.jp [124.215.194.164]
 13     *        *        *     Request timed out.
 14    83 ms    81 ms    82 ms  sl-crs1-sj-0-12-0-1.sprintlink.net
[144.232.9.224]
 15     *        *        *     Request timed out.
 16   403 ms   407 ms   404 ms  144.223.243.126
 17     *        *        *     Request timed out.
 18   501 ms   499 ms   501 ms
otejbb203.kddnet.ad.jp.100.181.203.in-addr.arpa [203.181.100.137]
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *     ^C

Lee

>
> The host, 106.187.34.33, is behind the gateway 106.187.34.1:
>
> From FIOS to 106.187.34.1  (this works).
>
> traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets
>
>  4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  9.960 ms
> 9.957 ms  6.666 ms
>  5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 12.298 ms  13.463 ms  13.706 ms
>  6  0.ae2.br1.iad8.alter.net (152.63.32.158)  14.571 ms  14.372 ms  14.003
> ms
>  7  204.255.169.218 (204.255.169.218)  14.692 ms  14.759 ms  13.670 ms
>  8  sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229)  13.077 ms
> 12.577 ms  14.954 ms
>  9  sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200)  31.443 ms
>     sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37)  33.005 ms
>     sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200)  31.507 ms
> 10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  57.610 ms
> 58.322 ms  59.098 ms
> 11  otejbb204.kddnet.ad.jp (203.181.100.45)  196.063 ms
>     otejbb203.kddnet.ad.jp (203.181.100.13)  188.846 ms
>     otejbb204.kddnet.ad.jp (203.181.100.21)  195.277 ms
> 12  cm-fcu203.kddnet.ad.jp (124.215.194.180)  214.760 ms
>     cm-fcu203.kddnet.ad.jp (124.215.194.164)  198.925 ms
>     cm-fcu203.kddnet.ad.jp (124.215.194.180)  200.583 ms
> 13  124.215.199.122 (124.215.199.122)  193.086 ms *  194.967 ms
>
> This does not work from FIOS:
>
> traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets
>
>  4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  34.229 ms
> 8.743 ms  8.878 ms
>  5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 15.402 ms  13.008 ms  14.932 ms
>  6  0.ae2.br1.iad8.alter.net (152.63.32.158)  13.325 ms  13.245 ms  13.802
> ms
>  7  204.255.169.218 (204.255.169.218)  14.820 ms  14.232 ms  13.491 ms
>  8  lap-brdr-03.inet.qwest.net (67.14.22.78)  90.170 ms  92.273 ms  145.887
> ms
>  9  63.146.26.70 (63.146.26.70)  92.482 ms  92.287 ms  94.000 ms
> 10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.135 ms
> 58.520 ms  58.055 ms
> 11  otejbb203.kddnet.ad.jp (203.181.100.17)  205.844 ms
>     otejbb204.kddnet.ad.jp (203.181.100.25)  189.929 ms
>     otejbb203.kddnet.ad.jp (203.181.100.17)  204.846 ms
> 12  sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77)  87.229 ms
>     sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  88.796 ms  88.717
> ms
> 13  124.215.199.122 (124.215.199.122)  193.584 ms  202.208 ms  192.989 ms
> 14  * * *
>
> Same IP from different network:
>
> traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets
>
>  6  ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105)  2.230 ms  1.847
> ms  1.938 ms
>  7  ae-92-92.csw4.Washington1.Level3.net (4.69.134.158)  2.010 ms
> 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146)  1.942 ms
>  8  ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189)  12.515 ms
> ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181)  12.519 ms  12.507
> ms
>  9  ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81)  65.957 ms
> 65.958 ms  66.056 ms
> 10  ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42)  66.063 ms
> ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46)  65.985 ms
> ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34)  66.026 ms
> 11  ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143)  66.162 ms
> 66.160 ms  66.238 ms
> 12  KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14)  193.317 ms
>  193.447 ms  193.305 ms
> 13  lajbb001.kddnet.ad.jp (59.128.2.101)  101.544 ms  101.543 ms
> lajbb002.kddnet.ad.jp (59.128.2.185)  66.563 ms
> 14  otejbb203.kddnet.ad.jp (203.181.100.13)  164.217 ms  164.221 ms  164.330
> ms
> 15  cm-fcu203.kddnet.ad.jp (124.215.194.164)  180.350 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.180)  172.779 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.164)  185.824 ms
> 16  124.215.199.122 (124.215.199.122)  175.703 ms  175.700 ms  168.268 ms
> 17  li377-33.members.linode.com (106.187.34.33)  174.381 ms  174.383
> ms  174.368 ms
>
> The last hop is KDDI, but things work from via Level3 and not sprint.
> Linode blames Verizon, but I'm not seeing how it's them.
>
> Any ideas?
>
>


From netsecguy at gmail.com  Sun Dec 11 12:02:42 2011
From: netsecguy at gmail.com (NetSecGuy)
Date: Sun, 11 Dec 2011 13:02:42 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
Message-ID: <CA+buB7fL9BuZX9WNu=zsqxSeiZSWZbusRZV_szcrv8hkCqTT3w@mail.gmail.com>

I should have included reverse traces to begin with.  No firewall on VPS.

Trace from the VPS to a router close to me.

traceroute to 130.81.199.4 (130.81.199.4), 64 hops max, 40 byte packets
 1  106.187.33.2 (106.187.33.2)  1 ms  0 ms  0 ms
 2  124.215.199.121 (124.215.199.121)  6 ms  1 ms  13 ms
 3  59.128.4.121 (59.128.4.121)  2 ms otejbb204.kddnet.ad.jp
(124.215.194.177)  2 ms  2 ms
 4  lajbb001.kddnet.ad.jp (203.181.100.14)  126 ms  100 ms
lajbb002.kddnet.ad.jp (203.181.100.22)  162 ms
 5  ix-la1.kddnet.ad.jp (59.128.2.70)  108 ms ix-la1.kddnet.ad.jp
(59.128.2.178)  102 ms  102 ms
 6  lap-brdr-03.inet.qwest.net (63.146.26.69)  99 ms  101 ms  99 ms
 7  63.146.26.210 (63.146.26.210)  99 ms  101 ms  99 ms
 8  0.ae3.XL3.LAX15.ALTER.NET (152.63.113.186)  102 ms  102 ms  101 ms
 9  * * *
10  * * *

Tracer from VPS to a router close to my other location, not Verizon.

traceroute to 4.59.244.49 (4.59.244.49), 64 hops max, 40 byte packets
 1  106.187.33.2 (106.187.33.2)  1 ms  1 ms  1 ms
 2  124.215.199.121 (124.215.199.121)  9 ms  1 ms  1 ms
 3  59.128.4.121 (59.128.4.121)  2 ms otejbb204.kddnet.ad.jp
(124.215.194.177)  9 ms 59.128.4.121 (59.128.4.121)  2 ms
 4  lajbb001.kddnet.ad.jp (203.181.100.18)  108 ms
lajbb002.kddnet.ad.jp (203.181.100.22)  101 ms  101 ms
 5  ix-la2.kddnet.ad.jp (59.128.2.102)  116 ms  116 ms
ix-la2.kddnet.ad.jp (59.128.2.186)  125 ms
 6  xe-11-3-0.edge2.LosAngeles9.Level3.net (4.53.228.13)  111 ms  101 ms  101 ms
 7  vlan70.csw2.LosAngeles1.Level3.net (4.69.144.126)  110 ms
vlan90.csw4.LosAngeles1.Level3.net (4.69.144.254)  108 ms
vlan60.csw1.LosAngeles1.Level3.net (4.69.144.62)  103 ms
 8  ae-63-63.ebr3.LosAngeles1.Level3.net (4.69.137.33)  110 ms  117 ms
ae-73-73.ebr3.LosAngeles1.Level3.net (4.69.137.37)  108 ms
 9  ae-4-4.ebr4.Washington1.Level3.net (4.69.132.82)  178 ms  180 ms  166 ms
10  ae-64-64.csw1.Washington1.Level3.net (4.69.134.178)  174 ms  166 ms  166 ms
11  ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145)  172 ms  165 ms  172 ms
12  ae-8-8.car2.Baltimore1.Level3.net (4.69.134.106)  181 ms  174 ms  174 ms
13  ae-11-11.car1.Baltimore1.Level3.net (4.69.134.109)  181 ms *  174 ms


From joseph.snyder at gmail.com  Sun Dec 11 14:11:01 2011
From: joseph.snyder at gmail.com (Joseph Snyder)
Date: Sun, 11 Dec 2011 15:11:01 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <CA+buB7fL9BuZX9WNu=zsqxSeiZSWZbusRZV_szcrv8hkCqTT3w@mail.gmail.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CA+buB7fL9BuZX9WNu=zsqxSeiZSWZbusRZV_szcrv8hkCqTT3w@mail.gmail.com>
Message-ID: <421a1b73-817f-42d4-ab1e-9c5beaa96174@email.android.com>

I believe 130.81 is blocked. Traceroute to your gateway address.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

NetSecGuy <netsecguy at gmail.com> wrote:

I should have included reverse traces to begin with. No firewall on VPS.

Trace from the VPS to a router close to me.

traceroute to 130.81.199.4 (130.81.199.4), 64 hops max, 40 byte packets
1 106.187.33.2 (106.187.33.2) 1 ms 0 ms 0 ms
2 124.215.199.121 (124.215.199.121) 6 ms 1 ms 13 ms
3 59.128.4.121 (59.128.4.121) 2 ms otejbb204.kddnet.ad.jp
(124.215.194.177) 2 ms 2 ms
4 lajbb001.kddnet.ad.jp (203.181.100.14) 126 ms 100 ms
lajbb002.kddnet.ad.jp (203.181.100.22) 162 ms
5 ix-la1.kddnet.ad.jp (59.128.2.70) 108 ms ix-la1.kddnet.ad.jp
(59.128.2.178) 102 ms 102 ms
6 lap-brdr-03.inet.qwest.net (63.146.26.69) 99 ms 101 ms 99 ms
7 63.146.26.210 (63.146.26.210) 99 ms 101 ms 99 ms
8 0.ae3.XL3.LAX15.ALTER.NET (152.63.113.186) 102 ms 102 ms 101 ms
9 * * *
10 * * *

Tracer from VPS to a router close to my other location, not Verizon.

traceroute to 4.59.244.49 (4.59.244.49), 64 hops max, 40 byte packets
1 106.187.33.2 (106.187.33.2) 1 ms 1 ms 1 ms
2 124.215.199.121 (124.215.199.121) 9 ms 1 ms 1 ms
3 59.128.4.121 (59.128.4.121) 2 ms otejbb204.kddnet.ad.jp
(124.215.194.177) 9 ms 59.128.4.121 (59.128.4.121) 2 ms
4 lajbb001.kddnet.ad.jp (203.181.100.18) 108 ms
lajbb002.kddnet.ad.jp (203.181.100.22) 101 ms 101 ms
5 ix-la2.kddnet.ad.jp (59.128.2.102) 116 ms 116 ms
ix-la2.kddnet.ad.jp (59.128.2.186) 125 ms
6 xe-11-3-0.edge2.LosAngeles9.Level3.net (4.53.228.13) 111 ms 101 ms 101 ms
7 vlan70.csw2.LosAngeles1.Level3.net (4.69.144.126) 110 ms
vlan90.csw4.LosAngeles1.Level3.net (4.69.144.254) 108 ms
vlan60.csw1.LosAngeles1.Level3.net (4.69.144.62) 103 ms
8 ae-63-63.ebr3.LosAngeles1.Level3.net (4.69.137.33) 110 ms 117 ms
ae-73-73.ebr3.LosAngeles1.Level3.net (4.69.137.37) 108 ms
9 ae-4-4.ebr4.Washington1.Level3.net (4.69.132.82) 178 ms 180 ms 166 ms
10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 174 ms 166 ms 166 ms
11 ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 172 ms 165 ms 172 ms
12 ae-8-8.car2.Baltimore1.Level3.net (4.69.134.106) 181 ms 174 ms 174 ms
13 ae-11-11.car1.Baltimore1.Level3.net (4.69.134.109) 181 ms * 174 ms


From jof at thejof.com  Sun Dec 11 14:56:52 2011
From: jof at thejof.com (Jonathan Lassoff)
Date: Sun, 11 Dec 2011 12:56:52 -0800
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
Message-ID: <CAHsqw9shh3YeCOmzK6VPLS2AQtMN06SdzqkUUbBYSX+H4Gv7zA@mail.gmail.com>

On Sat, Dec 10, 2011 at 11:49 AM, NetSecGuy <netsecguy at gmail.com> wrote:

> I have a Linode VPS in Japan that I can't access from Verizon FIOS,
> but can access from other locations.  I'm not sure who to blame.
>
> The host, 106.187.34.33, is behind the gateway 106.187.34.1:
>
> From FIOS to 106.187.34.1  (this works).
>
> traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets
>
>  4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  9.960 ms
> 9.957 ms  6.666 ms
>  5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 12.298 ms  13.463 ms  13.706 ms
>  6  0.ae2.br1.iad8.alter.net (152.63.32.158)  14.571 ms  14.372 ms
>  14.003 ms
>  7  204.255.169.218 (204.255.169.218)  14.692 ms  14.759 ms  13.670 ms
>  8  sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229)  13.077 ms
> 12.577 ms  14.954 ms
>  9  sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200)  31.443 ms
>    sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37)  33.005 ms
>    sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200)  31.507 ms
> 10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  57.610 ms
> 58.322 ms  59.098 ms
> 11  otejbb204.kddnet.ad.jp (203.181.100.45)  196.063 ms
>    otejbb203.kddnet.ad.jp (203.181.100.13)  188.846 ms
>    otejbb204.kddnet.ad.jp (203.181.100.21)  195.277 ms
> 12  cm-fcu203.kddnet.ad.jp (124.215.194.180)  214.760 ms
>    cm-fcu203.kddnet.ad.jp (124.215.194.164)  198.925 ms
>    cm-fcu203.kddnet.ad.jp (124.215.194.180)  200.583 ms
> 13  124.215.199.122 (124.215.199.122)  193.086 ms *  194.967 ms
>
> This does not work from FIOS:
>
> traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets
>
>  4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  34.229 ms
> 8.743 ms  8.878 ms
>  5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 15.402 ms  13.008 ms  14.932 ms
>  6  0.ae2.br1.iad8.alter.net (152.63.32.158)  13.325 ms  13.245 ms
>  13.802 ms
>  7  204.255.169.218 (204.255.169.218)  14.820 ms  14.232 ms  13.491 ms
>  8  lap-brdr-03.inet.qwest.net (67.14.22.78)  90.170 ms  92.273 ms
>  145.887 ms
>  9  63.146.26.70 (63.146.26.70)  92.482 ms  92.287 ms  94.000 ms
> 10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.135 ms
> 58.520 ms  58.055 ms
> 11  otejbb203.kddnet.ad.jp (203.181.100.17)  205.844 ms
>    otejbb204.kddnet.ad.jp (203.181.100.25)  189.929 ms
>    otejbb203.kddnet.ad.jp (203.181.100.17)  204.846 ms
> 12  sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77)  87.229 ms
>    sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  88.796 ms  88.717
> ms
> 13  124.215.199.122 (124.215.199.122)  193.584 ms  202.208 ms  192.989 ms
> 14  * * *
>
> Same IP from different network:
>
> traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets
>
>  6  ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105)  2.230 ms  1.847
> ms  1.938 ms
>  7  ae-92-92.csw4.Washington1.Level3.net (4.69.134.158)  2.010 ms
> 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146)  1.942 ms
>  8  ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189)  12.515 ms
> ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181)  12.519 ms  12.507
> ms
>  9  ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81)  65.957 ms
> 65.958 ms  66.056 ms
> 10  ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42)  66.063 ms
> ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46)  65.985 ms
> ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34)  66.026 ms
> 11  ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143)  66.162 ms
> 66.160 ms  66.238 ms
> 12  KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14)  193.317 ms
>  193.447 ms  193.305 ms
> 13  lajbb001.kddnet.ad.jp (59.128.2.101)  101.544 ms  101.543 ms
> lajbb002.kddnet.ad.jp (59.128.2.185)  66.563 ms
> 14  otejbb203.kddnet.ad.jp (203.181.100.13)  164.217 ms  164.221 ms
>  164.330 ms
> 15  cm-fcu203.kddnet.ad.jp (124.215.194.164)  180.350 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.180)  172.779 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.164)  185.824 ms
> 16  124.215.199.122 (124.215.199.122)  175.703 ms  175.700 ms  168.268 ms
> 17  li377-33.members.linode.com (106.187.34.33)  174.381 ms  174.383
> ms  174.368 ms
>
>
In doing a little probing right now, from various source addresses, I'm
unable to reproduce the problem.

I've seen failures similar to this one (where the source address matters;
some work, some don't) when multi-port LAGs or ECMP paths have a single
link in them fail, but are still detected and forwarded over as if it was
up. This can happen, for example, if you run a LAG with no channeling
protocol (like LACP or PAGP), that hashes source and destination IPs to
pick a link (to ensure consistent paths per-path, and with ports,
per-flow). If one of those links fails in the underlying media or physical
path, but the link is still detected as up, packets to some IPs (but not
others) will just drop on the flor.

Now, in this particular case, it doesn't seem like the path to both
destinations seem like they even take the same path (so that previous
hypothesis is pure conjecture). Perhaps routes were actively shifting
between KDDI and Sprint (which would explain weird AS paths like
VZB->Qwest->Sprint->KDDI->Sprint)? The IP space belongs to KDDI and is
originated by them, and they're just allocating it for Linode's use.



> The last hop is KDDI, but things work from via Level3 and not sprint.
> Linode blames Verizon, but I'm not seeing how it's them.
>

Honestly, I'd see if Linode can work with KDDI to make sure they're
announcing (and others are receiving and routing) to that IP space as
intended.

There's not enough info here to point fingers, but I would think that they
would be the organization most empowered to do anything about this.

Cheers,
jof

From network.ipdog at gmail.com  Sun Dec 11 16:46:20 2011
From: network.ipdog at gmail.com (Network IP Dog)
Date: Sun, 11 Dec 2011 14:46:20 -0800
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
Message-ID: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>

>From 90701 - Artesia, CA.   FIOS

No Go here too!!!



C:\WINDOWS\system32>tracert 106.187.34.1

Tracing route to gw-li377.linode.com [106.187.34.1]
over a maximum of 30 hops:

  1    22 ms    34 ms    <1 ms  Tomato [192.168.100.1]
  2    49 ms     1 ms     1 ms  Verizon [192.168.1.1]
  3    36 ms     6 ms     6 ms  L100.LSANCA-VFTTP-114.verizon-gni.net
[173.58.21
1.1]
  4    24 ms     9 ms     9 ms  G0-9-1-4.LSANCA-LCR-21.verizon-gni.net
[130.81.1
85.72]
  5    24 ms     9 ms     8 ms  so-4-1-0-0.LAX01-BB-RTR1.verizon-gni.net
[130.81
.151.246]
  6    24 ms     9 ms     8 ms  0.ae1.BR3.LAX15.ALTER.NET [152.63.2.129]
  7    38 ms     8 ms     8 ms  ae6.edge1.LosAngeles9.level3.net
[4.68.62.169]
  8    25 ms    10 ms    10 ms  63.146.26.70
  9    24 ms     9 ms     8 ms  lajbb001.kddnet.ad.jp [59.128.2.173]
 10    24 ms     9 ms     8 ms  lajbb001.kddnet.ad.jp [59.128.2.181]
 11   140 ms   110 ms   108 ms  otejbb203.kddnet.ad.jp [203.181.100.9]
 12   140 ms   124 ms   111 ms  cm-fcu203.kddnet.ad.jp [124.215.194.164]
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *     ^C
C:\WINDOWS\system32>tracert 106.187.34.33

Tracing route to li377-33.members.linode.com [106.187.34.33]
over a maximum of 30 hops:

  1    22 ms     1 ms    <1 ms  Tomato [192.168.100.1]
  2    31 ms     1 ms     1 ms  Verizon [192.168.1.1]
  3    51 ms    10 ms    11 ms  L100.LSANCA-VFTTP-114.verizon-gni.net
[173.58.21
1.1]
  4    42 ms     9 ms    33 ms  G0-9-1-4.LSANCA-LCR-21.verizon-gni.net
[130.81.1
85.72]
  5    40 ms    15 ms     9 ms  so-4-1-0-0.LAX01-BB-RTR1.verizon-gni.net
[130.81
.151.246]
  6    31 ms     8 ms     8 ms  0.ae1.BR3.LAX15.ALTER.NET [152.63.2.129]
  7    61 ms    10 ms    16 ms  lap-brdr-03.inet.qwest.net [63.146.26.209]
  8    31 ms    10 ms    10 ms  63.146.26.70
  9    31 ms     9 ms     9 ms  lajbb001.kddnet.ad.jp [59.128.2.173]
 10    31 ms     9 ms     8 ms  lajbb001.kddnet.ad.jp [59.128.2.181]
 11   125 ms   118 ms   109 ms  otejbb203.kddnet.ad.jp [203.181.100.9]
 12   156 ms   111 ms   143 ms  124.215.199.122
 13   126 ms   112 ms   137 ms  124.215.199.122
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *     ^C
C:\WINDOWS\system32>


E = 4:32  &  Cheers!!!

-----Original Message-----
From: Lee [mailto:ler762 at gmail.com] 
Sent: Sunday, December 11, 2011 6:44 AM
To: NetSecGuy
Cc: nanog at nanog.org
Subject: Re: Inaccessible network from Verizon, accessible elsewhere.

On 12/10/11, NetSecGuy <netsecguy at gmail.com> wrote:
> I have a Linode VPS in Japan that I can't access from Verizon FIOS,
> but can access from other locations.  I'm not sure who to blame.

I can't get to 106.187.34.33 or 106.187.34.1 using Verizon FIOS

C:\>tracert 106.187.34.33

Tracing route to li377-33.members.linode.com [106.187.34.33]
over a maximum of 30 hops:
    [.. snip ..]
  5    23 ms     4 ms     4 ms
so-14-0-0-0.RES-BB-RTR2.verizon-gni.net [130.81.22.56]
  6    73 ms     6 ms     7 ms  0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73]
  7     8 ms     6 ms     7 ms  dcp-brdr-03.inet.qwest.net [63.146.26.105]
  8     8 ms     9 ms     9 ms  sl-crs1-dc-0-1-0-0.sprintlink.net
[144.232.19.229]
  9    28 ms    26 ms    44 ms  sl-crs1-dc-0-5-3-0.sprintlink.net
[144.232.24.37]
 10   177 ms   176 ms   177 ms  lajbb001.kddnet.ad.jp [59.128.2.173]
 11    43 ms    41 ms    42 ms  sl-crs1-oma-0-9-2-0.sprintlink.net
[144.232.2.177]
 12   291 ms     *      301 ms  cm-fcu203.kddnet.ad.jp [124.215.194.164]
 13   286 ms   279 ms   282 ms  124.215.199.122
 14    81 ms    81 ms    82 ms  sl-crs1-sj-0-5-3-0.sprintlink.net
[144.232.20.99]
 15    88 ms    86 ms    87 ms  sl-st20-pa-9-0-0.sprintlink.net
[144.232.8.108]
 16   405 ms   406 ms   399 ms  144.223.243.126
 17   364 ms   386 ms   406 ms  pajbb001.kddnet.ad.jp [111.87.3.41]
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *     ^C

C:\>tracert 106.187.34.1

Tracing route to gw-li377.linode.com [106.187.34.1]
over a maximum of 30 hops:
    [.. snip ..]
  5     5 ms    24 ms    24 ms  so-3-1-0-0.RES-BB-RTR2.verizon-gni.net
[130.81.151.232]
  6     7 ms     7 ms     7 ms  0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73]
  7     8 ms     7 ms     7 ms  dcp-brdr-03.inet.qwest.net [63.146.26.105]
  8    84 ms    84 ms    84 ms  lap-brdr-03.inet.qwest.net [67.14.22.78]
  9   171 ms   174 ms   176 ms  63.146.26.70
 10   178 ms   177 ms   177 ms  lajbb001.kddnet.ad.jp [59.128.2.173]
 11   283 ms   284 ms   284 ms  otejbb203.kddnet.ad.jp [203.181.100.9]
 12   289 ms   287 ms   287 ms  cm-fcu203.kddnet.ad.jp [124.215.194.164]
 13     *        *        *     Request timed out.
 14    83 ms    81 ms    82 ms  sl-crs1-sj-0-12-0-1.sprintlink.net
[144.232.9.224]
 15     *        *        *     Request timed out.
 16   403 ms   407 ms   404 ms  144.223.243.126
 17     *        *        *     Request timed out.
 18   501 ms   499 ms   501 ms
otejbb203.kddnet.ad.jp.100.181.203.in-addr.arpa [203.181.100.137]
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *     ^C

Lee

>
> The host, 106.187.34.33, is behind the gateway 106.187.34.1:
>
> From FIOS to 106.187.34.1  (this works).
>
> traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets
>
>  4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  9.960 ms
> 9.957 ms  6.666 ms
>  5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 12.298 ms  13.463 ms  13.706 ms
>  6  0.ae2.br1.iad8.alter.net (152.63.32.158)  14.571 ms  14.372 ms  14.003
> ms
>  7  204.255.169.218 (204.255.169.218)  14.692 ms  14.759 ms  13.670 ms
>  8  sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229)  13.077 ms
> 12.577 ms  14.954 ms
>  9  sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200)  31.443 ms
>     sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37)  33.005 ms
>     sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200)  31.507 ms
> 10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  57.610 ms
> 58.322 ms  59.098 ms
> 11  otejbb204.kddnet.ad.jp (203.181.100.45)  196.063 ms
>     otejbb203.kddnet.ad.jp (203.181.100.13)  188.846 ms
>     otejbb204.kddnet.ad.jp (203.181.100.21)  195.277 ms
> 12  cm-fcu203.kddnet.ad.jp (124.215.194.180)  214.760 ms
>     cm-fcu203.kddnet.ad.jp (124.215.194.164)  198.925 ms
>     cm-fcu203.kddnet.ad.jp (124.215.194.180)  200.583 ms
> 13  124.215.199.122 (124.215.199.122)  193.086 ms *  194.967 ms
>
> This does not work from FIOS:
>
> traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets
>
>  4  so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4)  34.229 ms
> 8.743 ms  8.878 ms
>  5  so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 15.402 ms  13.008 ms  14.932 ms
>  6  0.ae2.br1.iad8.alter.net (152.63.32.158)  13.325 ms  13.245 ms  13.802
> ms
>  7  204.255.169.218 (204.255.169.218)  14.820 ms  14.232 ms  13.491 ms
>  8  lap-brdr-03.inet.qwest.net (67.14.22.78)  90.170 ms  92.273 ms
145.887
> ms
>  9  63.146.26.70 (63.146.26.70)  92.482 ms  92.287 ms  94.000 ms
> 10  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.135 ms
> 58.520 ms  58.055 ms
> 11  otejbb203.kddnet.ad.jp (203.181.100.17)  205.844 ms
>     otejbb204.kddnet.ad.jp (203.181.100.25)  189.929 ms
>     otejbb203.kddnet.ad.jp (203.181.100.17)  204.846 ms
> 12  sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77)  87.229 ms
>     sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  88.796 ms  88.717
> ms
> 13  124.215.199.122 (124.215.199.122)  193.584 ms  202.208 ms  192.989 ms
> 14  * * *
>
> Same IP from different network:
>
> traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets
>
>  6  ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105)  2.230 ms  1.847
> ms  1.938 ms
>  7  ae-92-92.csw4.Washington1.Level3.net (4.69.134.158)  2.010 ms
> 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146)  1.942 ms
>  8  ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189)  12.515 ms
> ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181)  12.519 ms  12.507
> ms
>  9  ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81)  65.957 ms
> 65.958 ms  66.056 ms
> 10  ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42)  66.063 ms
> ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46)  65.985 ms
> ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34)  66.026 ms
> 11  ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143)  66.162 ms
> 66.160 ms  66.238 ms
> 12  KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14)  193.317 ms
>  193.447 ms  193.305 ms
> 13  lajbb001.kddnet.ad.jp (59.128.2.101)  101.544 ms  101.543 ms
> lajbb002.kddnet.ad.jp (59.128.2.185)  66.563 ms
> 14  otejbb203.kddnet.ad.jp (203.181.100.13)  164.217 ms  164.221 ms
164.330
> ms
> 15  cm-fcu203.kddnet.ad.jp (124.215.194.164)  180.350 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.180)  172.779 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.164)  185.824 ms
> 16  124.215.199.122 (124.215.199.122)  175.703 ms  175.700 ms  168.268 ms
> 17  li377-33.members.linode.com (106.187.34.33)  174.381 ms  174.383
> ms  174.368 ms
>
> The last hop is KDDI, but things work from via Level3 and not sprint.
> Linode blames Verizon, but I'm not seeing how it's them.
>
> Any ideas?
>
>



From dave at temk.in  Sun Dec 11 18:29:53 2011
From: dave at temk.in (Dave Temkin)
Date: Sun, 11 Dec 2011 16:29:53 -0800
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <4EDF9AE9.9040700@ispn.net>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net>
Message-ID: <4EE54B01.6000305@temk.in>

Feel free to contact peering at netflix<dot>com - we're happy to provide you with delivery statistics for 
traffic terminating on your network.

Regards,
-Dave Temkin
Netflix

On 12/7/11 8:57 AM, Blake Hudson wrote:
> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that 
> netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the 
> traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the 
> latest windows update (remember this is often a shared hosting platform). We've done our own testing and 
> have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a 
> conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest 
> of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
>
>
> Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
>> Also checkout Adrian Cockcroft presentations on their architecture which
>> describes how they use aws and CDns etc
>>
>> Martin
>>
>>
>



From joseph.snyder at gmail.com  Sun Dec 11 18:37:26 2011
From: joseph.snyder at gmail.com (Joseph Snyder)
Date: Sun, 11 Dec 2011 19:37:26 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>
Message-ID: <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>

I hope it's not an outdated martian problem firewall or route filter. For the Traceroute from linode to FiOS, Traceroute to the FiOS gateway address.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Network IP Dog <network.ipdog at gmail.com> wrote:

>From 90701 - Artesia, CA. FIOS

No Go here too!!!



C:\WINDOWS\system32>tracert 106.187.34.1

Tracing route to gw-li377.linode.com [106.187.34.1]
over a maximum of 30 hops:

1 22 ms 34 ms <1 ms Tomato [192.168.100.1]
2 49 ms 1 ms 1 ms Verizon [192.168.1.1]
3 36 ms 6 ms 6 ms L100.LSANCA-VFTTP-114.verizon-gni.net
[173.58.21
1.1]
4 24 ms 9 ms 9 ms G0-9-1-4.LSANCA-LCR-21.verizon-gni.net
[130.81.1
85.72]
5 24 ms 9 ms 8 ms so-4-1-0-0.LAX01-BB-RTR1.verizon-gni.net
[130.81
.151.246]
6 24 ms 9 ms 8 ms 0.ae1.BR3.LAX15.ALTER.NET [152.63.2.129]
7 38 ms 8 ms 8 ms ae6.edge1.LosAngeles9.level3.net
[4.68.62.169]
8 25 ms 10 ms 10 ms 63.146.26.70
9 24 ms 9 ms 8 ms lajbb001.kddnet.ad.jp [59.128.2.173]
10 24 ms 9 ms 8 ms lajbb001.kddnet.ad.jp [59.128.2.181]
11 140 ms 110 ms 108 ms otejbb203.kddnet.ad.jp [203.181.100.9]
12 140 ms 124 ms 111 ms cm-fcu203.kddnet.ad.jp [124.215.194.164]
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * ^C
C:\WINDOWS\system32>tracert 106.187.34.33

Tracing route to li377-33.members.linode.com [106.187.34.33]
over a maximum of 30 hops:

1 22 ms 1 ms <1 ms Tomato [192.168.100.1]
2 31 ms 1 ms 1 ms Verizon [192.168.1.1]
3 51 ms 10 ms 11 ms L100.LSANCA-VFTTP-114.verizon-gni.net
[173.58.21
1.1]
4 42 ms 9 ms 33 ms G0-9-1-4.LSANCA-LCR-21.verizon-gni.net
[130.81.1
85.72]
5 40 ms 15 ms 9 ms so-4-1-0-0.LAX01-BB-RTR1.verizon-gni.net
[130.81
.151.246]
6 31 ms 8 ms 8 ms 0.ae1.BR3.LAX15.ALTER.NET [152.63.2.129]
7 61 ms 10 ms 16 ms lap-brdr-03.inet.qwest.net [63.146.26.209]
8 31 ms 10 ms 10 ms 63.146.26.70
9 31 ms 9 ms 9 ms lajbb001.kddnet.ad.jp [59.128.2.173]
10 31 ms 9 ms 8 ms lajbb001.kddnet.ad.jp [59.128.2.181]
11 125 ms 118 ms 109 ms otejbb203.kddnet.ad.jp [203.181.100.9]
12 156 ms 111 ms 143 ms 124.215.199.122
13 126 ms 112 ms 137 ms 124.215.199.122
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * ^C
C:\WINDOWS\system32>


E = 4:32 & Cheers!!!

-----Original Message-----
From: Lee [mailto:ler762 at gmail.com] 
Sent: Sunday, December 11, 2011 6:44 AM
To: NetSecGuy
Cc: nanog at nanog.org
Subject: Re: Inaccessible network from Verizon, accessible elsewhere.

On 12/10/11, NetSecGuy <netsecguy at gmail.com> wrote:
> I have a Linode VPS in Japan that I can't access from Verizon FIOS,
> but can access from other locations. I'm not sure who to blame.

I can't get to 106.187.34.33 or 106.187.34.1 using Verizon FIOS

C:\>tracert 106.187.34.33

Tracing route to li377-33.members.linode.com [106.187.34.33]
over a maximum of 30 hops:
[.. snip ..]
5 23 ms 4 ms 4 ms
so-14-0-0-0.RES-BB-RTR2.verizon-gni.net [130.81.22.56]
6 73 ms 6 ms 7 ms 0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73]
7 8 ms 6 ms 7 ms dcp-brdr-03.inet.qwest.net [63.146.26.105]
8 8 ms 9 ms 9 ms sl-crs1-dc-0-1-0-0.sprintlink.net
[144.232.19.229]
9 28 ms 26 ms 44 ms sl-crs1-dc-0-5-3-0.sprintlink.net
[144.232.24.37]
10 177 ms 176 ms 177 ms lajbb001.kddnet.ad.jp [59.128.2.173]
11 43 ms 41 ms 42 ms sl-crs1-oma-0-9-2-0.sprintlink.net
[144.232.2.177]
12 291 ms * 301 ms cm-fcu203.kddnet.ad.jp [124.215.194.164]
13 286 ms 279 ms 282 ms 124.215.199.122
14 81 ms 81 ms 82 ms sl-crs1-sj-0-5-3-0.sprintlink.net
[144.232.20.99]
15 88 ms 86 ms 87 ms sl-st20-pa-9-0-0.sprintlink.net
[144.232.8.108]
16 405 ms 406 ms 399 ms 144.223.243.126
17 364 ms 386 ms 406 ms pajbb001.kddnet.ad.jp [111.87.3.41]
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * ^C

C:\>tracert 106.187.34.1

Tracing route to gw-li377.linode.com [106.187.34.1]
over a maximum of 30 hops:
[.. snip ..]
5 5 ms 24 ms 24 ms so-3-1-0-0.RES-BB-RTR2.verizon-gni.net
[130.81.151.232]
6 7 ms 7 ms 7 ms 0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73]
7 8 ms 7 ms 7 ms dcp-brdr-03.inet.qwest.net [63.146.26.105]
8 84 ms 84 ms 84 ms lap-brdr-03.inet.qwest.net [67.14.22.78]
9 171 ms 174 ms 176 ms 63.146.26.70
10 178 ms 177 ms 177 ms lajbb001.kddnet.ad.jp [59.128.2.173]
11 283 ms 284 ms 284 ms otejbb203.kddnet.ad.jp [203.181.100.9]
12 289 ms 287 ms 287 ms cm-fcu203.kddnet.ad.jp [124.215.194.164]
13 * * * Request timed out.
14 83 ms 81 ms 82 ms sl-crs1-sj-0-12-0-1.sprintlink.net
[144.232.9.224]
15 * * * Request timed out.
16 403 ms 407 ms 404 ms 144.223.243.126
17 * * * Request timed out.
18 501 ms 499 ms 501 ms
otejbb203.kddnet.ad.jp.100.181.203.in-addr.arpa [203.181.100.137]
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * ^C

Lee

>
> The host, 106.187.34.33, is behind the gateway 106.187.34.1:
>
> From FIOS to 106.187.34.1 (this works).
>
> traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets
>
> 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 9.960 ms
> 9.957 ms 6.666 ms
> 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 12.298 ms 13.463 ms 13.706 ms
> 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 14.571 ms 14.372 ms 14.003
> ms
> 7 204.255.169.218 (204.255.169.218) 14.692 ms 14.759 ms 13.670 ms
> 8 sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229) 13.077 ms
> 12.577 ms 14.954 ms
> 9 sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.443 ms
> sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37) 33.005 ms
> sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.507 ms
> 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 57.610 ms
> 58.322 ms 59.098 ms
> 11 otejbb204.kddnet.ad.jp (203.181.100.45) 196.063 ms
> otejbb203.kddnet.ad.jp (203.181.100.13) 188.846 ms
> otejbb204.kddnet.ad.jp (203.181.100.21) 195.277 ms
> 12 cm-fcu203.kddnet.ad.jp (124.215.194.180) 214.760 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.164) 198.925 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.180) 200.583 ms
> 13 124.215.199.122 (124.215.199.122) 193.086 ms * 194.967 ms
>
> This does not work from FIOS:
>
> traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets
>
> 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms
> 8.743 ms 8.878 ms
> 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3)
> 15.402 ms 13.008 ms 14.932 ms
> 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802
> ms
> 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms
> 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms
145.887
> ms
> 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms
> 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms
> 58.520 ms 58.055 ms
> 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms
> otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms
> otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms
> 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms
> sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717
> ms
> 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms
> 14 * * *
>
> Same IP from different network:
>
> traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets
>
> 6 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) 2.230 ms 1.847
> ms 1.938 ms
> 7 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 2.010 ms
> 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 1.942 ms
> 8 ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 12.515 ms
> ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 12.519 ms 12.507
> ms
> 9 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 65.957 ms
> 65.958 ms 66.056 ms
> 10 ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42) 66.063 ms
> ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46) 65.985 ms
> ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34) 66.026 ms
> 11 ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143) 66.162 ms
> 66.160 ms 66.238 ms
> 12 KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14) 193.317 ms
> 193.447 ms 193.305 ms
> 13 lajbb001.kddnet.ad.jp (59.128.2.101) 101.544 ms 101.543 ms
> lajbb002.kddnet.ad.jp (59.128.2.185) 66.563 ms
> 14 otejbb203.kddnet.ad.jp (203.181.100.13) 164.217 ms 164.221 ms
164.330
> ms
> 15 cm-fcu203.kddnet.ad.jp (124.215.194.164) 180.350 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.180) 172.779 ms
> cm-fcu203.kddnet.ad.jp (124.215.194.164) 185.824 ms
> 16 124.215.199.122 (124.215.199.122) 175.703 ms 175.700 ms 168.268 ms
> 17 li377-33.members.linode.com (106.187.34.33) 174.381 ms 174.383
> ms 174.368 ms
>
> The last hop is KDDI, but things work from via Level3 and not sprint.
> Linode blames Verizon, but I'm not seeing how it's them.
>
> Any ideas?
>
>



From randy at psg.com  Sun Dec 11 18:55:40 2011
From: randy at psg.com (Randy Bush)
Date: Mon, 12 Dec 2011 09:55:40 +0900
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>
Message-ID: <m2liqiboc3.wl%randy@psg.com>

from home lan

% traceroute gw-li377.linode.com
traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  1.471 ms  0.725 ms  0.555 ms
 2  tokyo10-f03.flets.2iij.net (210.149.34.72)  7.241 ms  6.651 ms  6.939 ms
 3  tokyo10-ntteast0.flets.2iij.net (210.149.34.157)  5.573 ms  6.109 ms  5.346 ms
 4  tky001lip20.iij.net (210.149.34.97)  6.410 ms  7.471 ms  7.934 ms
 5  tky001bb10.iij.net (58.138.100.209)  6.670 ms  9.251 ms  5.866 ms
 6  tky009bf00.iij.net (58.138.80.17)  6.730 ms
    tky008bf02.iij.net (58.138.80.13)  7.021 ms
    tky009bf00.iij.net (58.138.80.17)  8.593 ms
 7  tky001ix05.iij.net (58.138.82.2)  9.767 ms
    tky001ix05.iij.net (58.138.82.6)  6.101 ms
    tky001ix01.iij.net (58.138.80.106)  8.420 ms
 8  203.181.102.61 (203.181.102.61)  19.514 ms
    203.181.102.21 (203.181.102.21)  6.054 ms
    203.181.102.61 (203.181.102.61)  11.478 ms
 9  otejbb203.kddnet.ad.jp (118.155.197.129)  7.457 ms
    otejbb203.kddnet.ad.jp (59.128.7.129)  7.835 ms
    otejbb204.kddnet.ad.jp (59.128.7.130)  7.824 ms
10  cm-fcu203.kddnet.ad.jp (124.215.194.180)  15.860 ms  16.401 ms
    cm-fcu203.kddnet.ad.jp (124.215.194.164)  17.519 ms
11  124.215.199.122 (124.215.199.122)  7.892 ms *  11.984 ms


From brandon.kim at brandontek.com  Sun Dec 11 19:06:44 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Sun, 11 Dec 2011 20:06:44 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <m2liqiboc3.wl%randy@psg.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>,
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>,
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>,
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>,
 <m2liqiboc3.wl%randy@psg.com>
Message-ID: <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>


I too am now experiencing issues. I cannot get to www.cisco.com and various websites.
Some websites work lightning quick, some take a long time to load, and some just don't load at all.....




> Date: Mon, 12 Dec 2011 09:55:40 +0900
> From: randy at psg.com
> To: nanog at nanog.org
> Subject: Re: Inaccessible network from Verizon, accessible elsewhere.
> 
> from home lan
> 
> % traceroute gw-li377.linode.com
> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets
>  1  192.168.0.1 (192.168.0.1)  1.471 ms  0.725 ms  0.555 ms
>  2  tokyo10-f03.flets.2iij.net (210.149.34.72)  7.241 ms  6.651 ms  6.939 ms
>  3  tokyo10-ntteast0.flets.2iij.net (210.149.34.157)  5.573 ms  6.109 ms  5.346 ms
>  4  tky001lip20.iij.net (210.149.34.97)  6.410 ms  7.471 ms  7.934 ms
>  5  tky001bb10.iij.net (58.138.100.209)  6.670 ms  9.251 ms  5.866 ms
>  6  tky009bf00.iij.net (58.138.80.17)  6.730 ms
>     tky008bf02.iij.net (58.138.80.13)  7.021 ms
>     tky009bf00.iij.net (58.138.80.17)  8.593 ms
>  7  tky001ix05.iij.net (58.138.82.2)  9.767 ms
>     tky001ix05.iij.net (58.138.82.6)  6.101 ms
>     tky001ix01.iij.net (58.138.80.106)  8.420 ms
>  8  203.181.102.61 (203.181.102.61)  19.514 ms
>     203.181.102.21 (203.181.102.21)  6.054 ms
>     203.181.102.61 (203.181.102.61)  11.478 ms
>  9  otejbb203.kddnet.ad.jp (118.155.197.129)  7.457 ms
>     otejbb203.kddnet.ad.jp (59.128.7.129)  7.835 ms
>     otejbb204.kddnet.ad.jp (59.128.7.130)  7.824 ms
> 10  cm-fcu203.kddnet.ad.jp (124.215.194.180)  15.860 ms  16.401 ms
>     cm-fcu203.kddnet.ad.jp (124.215.194.164)  17.519 ms
> 11  124.215.199.122 (124.215.199.122)  7.892 ms *  11.984 ms
> 
 		 	   		  

From faisal at snappydsl.net  Sun Dec 11 20:06:16 2011
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Sun, 11 Dec 2011 21:06:16 -0500
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <4EE54B01.6000305@temk.in>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
Message-ID: <4EE56198.40307@snappydsl.net>

Which leads to a question to be asked...

Is netflix willing to peer directly with ISP / NSP's ?

Regards.

Faisal Imtiaz
Snappy Internet&  Telecom


On 12/11/2011 7:29 PM, Dave Temkin wrote:
> Feel free to contact peering at netflix<dot>com - we're happy to provide 
> you with delivery statistics for traffic terminating on your network.
>
> Regards,
> -Dave Temkin
> Netflix
>
> On 12/7/11 8:57 AM, Blake Hudson wrote:
>> Yeah, that's an interesting one. We currently utilize netflow for 
>> this, but you also need to consider that netflix streaming is just 
>> port 80 www traffic. Because netflix uses CDNs, its difficult to pin 
>> down the traffic to specific hosts in the CDN and say that this 
>> traffic was netflix, while this traffic was the latest windows update 
>> (remember this is often a shared hosting platform). We've done our 
>> own testing and have come to a good solution which uses a combination 
>> of nbar, packet marking, and netflow to come to a conclusion. On a 
>> ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each 
>> evening. The rest of the traffic is predominantly other forms of HTTP 
>> traffic (including other video streaming services).
>>
>>
>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
>>> Also checkout Adrian Cockcroft presentations on their architecture 
>>> which
>>> describes how they use aws and CDns etc
>>>
>>> Martin
>>>
>>>
>>
>
>
>


From joelja at bogus.com  Sun Dec 11 21:21:49 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Sun, 11 Dec 2011 19:21:49 -0800
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <4EE56198.40307@snappydsl.net>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
Message-ID: <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>

Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?

Sent from my iPhone

On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal at snappydsl.net> wrote:

> Which leads to a question to be asked...
> 
> Is netflix willing to peer directly with ISP / NSP's ?
> 
> Regards.
> 
> Faisal Imtiaz
> Snappy Internet&  Telecom
> 
> 
> On 12/11/2011 7:29 PM, Dave Temkin wrote:
>> Feel free to contact peering at netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
>> 
>> Regards,
>> -Dave Temkin
>> Netflix
>> 
>> On 12/7/11 8:57 AM, Blake Hudson wrote:
>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
>>> 
>>> 
>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
>>>> Also checkout Adrian Cockcroft presentations on their architecture which
>>>> describes how they use aws and CDns etc
>>>> 
>>>> Martin
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
> 


From mhuff at ox.com  Sun Dec 11 21:28:36 2011
From: mhuff at ox.com (Matthew Huff)
Date: Sun, 11 Dec 2011 22:28:36 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>
 <m2liqiboc3.wl%randy@psg.com> <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>
Message-ID: <FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>

I'm seeing the same thing from my home lan via fios. I've run a recursive dns server for years and can't reach the roots. Had to switch to using verizon's dns servers as forwarders. 

Sent from my iPad

On Dec 11, 2011, at 8:07 PM, "Brandon Kim" <brandon.kim at brandontek.com> wrote:

> 
> I too am now experiencing issues. I cannot get to www.cisco.com and various websites.
> Some websites work lightning quick, some take a long time to load, and some just don't load at all.....
> 
> 
> 
> 
>> Date: Mon, 12 Dec 2011 09:55:40 +0900
>> From: randy at psg.com
>> To: nanog at nanog.org
>> Subject: Re: Inaccessible network from Verizon, accessible elsewhere.
>> 
>> from home lan
>> 
>> % traceroute gw-li377.linode.com
>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets
>> 1  192.168.0.1 (192.168.0.1)  1.471 ms  0.725 ms  0.555 ms
>> 2  tokyo10-f03.flets.2iij.net (210.149.34.72)  7.241 ms  6.651 ms  6.939 ms
>> 3  tokyo10-ntteast0.flets.2iij.net (210.149.34.157)  5.573 ms  6.109 ms  5.346 ms
>> 4  tky001lip20.iij.net (210.149.34.97)  6.410 ms  7.471 ms  7.934 ms
>> 5  tky001bb10.iij.net (58.138.100.209)  6.670 ms  9.251 ms  5.866 ms
>> 6  tky009bf00.iij.net (58.138.80.17)  6.730 ms
>>    tky008bf02.iij.net (58.138.80.13)  7.021 ms
>>    tky009bf00.iij.net (58.138.80.17)  8.593 ms
>> 7  tky001ix05.iij.net (58.138.82.2)  9.767 ms
>>    tky001ix05.iij.net (58.138.82.6)  6.101 ms
>>    tky001ix01.iij.net (58.138.80.106)  8.420 ms
>> 8  203.181.102.61 (203.181.102.61)  19.514 ms
>>    203.181.102.21 (203.181.102.21)  6.054 ms
>>    203.181.102.61 (203.181.102.61)  11.478 ms
>> 9  otejbb203.kddnet.ad.jp (118.155.197.129)  7.457 ms
>>    otejbb203.kddnet.ad.jp (59.128.7.129)  7.835 ms
>>    otejbb204.kddnet.ad.jp (59.128.7.130)  7.824 ms
>> 10  cm-fcu203.kddnet.ad.jp (124.215.194.180)  15.860 ms  16.401 ms
>>    cm-fcu203.kddnet.ad.jp (124.215.194.164)  17.519 ms
>> 11  124.215.199.122 (124.215.199.122)  7.892 ms *  11.984 ms
>> 
>                         


From Valdis.Kletnieks at vt.edu  Sun Dec 11 21:42:48 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 11 Dec 2011 22:42:48 -0500
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: Your message of "Sun, 11 Dec 2011 19:21:49 PST."
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
Message-ID: <59487.1323661368@turing-police.cc.vt.edu>

On Sun, 11 Dec 2011 19:21:49 PST, Joel Jaeggli said:
> Netflix uses CDNs for content delivery and the platform runs in EC2. What
> would peering with them achieve?

I suspect Faisal's *real* question is "Who at Netflix do I talk to in order to discuss
mutually beneficial traffic engineering?"
-------------- 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/20111211/fc573c26/attachment.bin>

From faisal at snappydsl.net  Sun Dec 11 21:46:54 2011
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Sun, 11 Dec 2011 22:46:54 -0500
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
Message-ID: <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>

Simple, keep traffic off paid ip transit circuits....

Faisal

On Dec 11, 2011, at 10:21 PM, Joel Jaeggli <joelja at bogus.com> wrote:

> Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
> 
> Sent from my iPhone
> 
> On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal at snappydsl.net> wrote:
> 
>> Which leads to a question to be asked...
>> 
>> Is netflix willing to peer directly with ISP / NSP's ?
>> 
>> Regards.
>> 
>> Faisal Imtiaz
>> Snappy Internet&  Telecom
>> 
>> 
>> On 12/11/2011 7:29 PM, Dave Temkin wrote:
>>> Feel free to contact peering at netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
>>> 
>>> Regards,
>>> -Dave Temkin
>>> Netflix
>>> 
>>> On 12/7/11 8:57 AM, Blake Hudson wrote:
>>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
>>>> 
>>>> 
>>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
>>>>> Also checkout Adrian Cockcroft presentations on their architecture which
>>>>> describes how they use aws and CDns etc
>>>>> 
>>>>> Martin
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
> 


From morrowc.lists at gmail.com  Sun Dec 11 21:46:29 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 11 Dec 2011 22:46:29 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <421a1b73-817f-42d4-ab1e-9c5beaa96174@email.android.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CA+buB7fL9BuZX9WNu=zsqxSeiZSWZbusRZV_szcrv8hkCqTT3w@mail.gmail.com>
 <421a1b73-817f-42d4-ab1e-9c5beaa96174@email.android.com>
Message-ID: <CAL9jLaZv+=snU_iNhxBj9cy3y5h2Vr1BOjz0zEB+TUgQ5Ca97Q@mail.gmail.com>

On Sun, Dec 11, 2011 at 3:11 PM, Joseph Snyder <joseph.snyder at gmail.com> wrote:
> I believe 130.81 is blocked. Traceroute to your gateway address.

portions (at least) of that are 19262's loopback/ptp space, they
block/rate-limit toward that at their edge.


From morrowc.lists at gmail.com  Sun Dec 11 21:48:19 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 11 Dec 2011 22:48:19 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>
 <m2liqiboc3.wl%randy@psg.com>
 <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>
 <FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>
Message-ID: <CAL9jLabYkTpkFnzoaTcwaxgaRfSNPjy1xoe9PxPQLpd6uwHBrw@mail.gmail.com>

On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff <mhuff at ox.com> wrote:
> I'm seeing the same thing from my home lan via fios. I've run a recursive dns server for years and can't reach the roots. Had to switch to using verizon's dns servers as forwarders.
>

business or consumer fios?
 3  G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180)  6.662 ms
6.739 ms  6.788 ms
 4  so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56)  6.852 ms
15.384 ms  8.184 ms
 5  0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158)  12.857 ms  12.927 ms  13.004 ms
 6  dcp-brdr-03.inet.qwest.net (63.146.26.105)  12.429 ms  7.847 ms  6.464 ms
 7  lap-brdr-03.inet.qwest.net (67.14.22.78)  89.140 ms  88.929 ms  89.032 ms
 8  63.146.26.70 (63.146.26.70)  94.879 ms  94.580 ms  93.120 ms
 9  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.520 ms
58.330 ms  58.186 ms
10  144.232.25.193 (144.232.25.193)  49.950 ms
sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177)  49.962 ms
sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171)  47.687 ms
11  sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  84.416 ms
83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73)  84.667
ms
12  124.215.199.122 (124.215.199.122)  195.590 ms * *

all of this seems to point at some kddi.net rouer gobbling packets,
no? (since pretty much everyone's got the same terminating hop) - also
note that while some folks traverse L3, my route is via qwest...

it's interesting that 701 isn't picking their other peer (sprint) here
directly, no?

> Sent from my iPad
>
> On Dec 11, 2011, at 8:07 PM, "Brandon Kim" <brandon.kim at brandontek.com> wrote:
>
>>
>> I too am now experiencing issues. I cannot get to www.cisco.com and various websites.
>> Some websites work lightning quick, some take a long time to load, and some just don't load at all.....
>>
>>
>>
>>
>>> Date: Mon, 12 Dec 2011 09:55:40 +0900
>>> From: randy at psg.com
>>> To: nanog at nanog.org
>>> Subject: Re: Inaccessible network from Verizon, accessible elsewhere.
>>>
>>> from home lan
>>>
>>> % traceroute gw-li377.linode.com
>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets
>>> 1 ?192.168.0.1 (192.168.0.1) ?1.471 ms ?0.725 ms ?0.555 ms
>>> 2 ?tokyo10-f03.flets.2iij.net (210.149.34.72) ?7.241 ms ?6.651 ms ?6.939 ms
>>> 3 ?tokyo10-ntteast0.flets.2iij.net (210.149.34.157) ?5.573 ms ?6.109 ms ?5.346 ms
>>> 4 ?tky001lip20.iij.net (210.149.34.97) ?6.410 ms ?7.471 ms ?7.934 ms
>>> 5 ?tky001bb10.iij.net (58.138.100.209) ?6.670 ms ?9.251 ms ?5.866 ms
>>> 6 ?tky009bf00.iij.net (58.138.80.17) ?6.730 ms
>>> ? ?tky008bf02.iij.net (58.138.80.13) ?7.021 ms
>>> ? ?tky009bf00.iij.net (58.138.80.17) ?8.593 ms
>>> 7 ?tky001ix05.iij.net (58.138.82.2) ?9.767 ms
>>> ? ?tky001ix05.iij.net (58.138.82.6) ?6.101 ms
>>> ? ?tky001ix01.iij.net (58.138.80.106) ?8.420 ms
>>> 8 ?203.181.102.61 (203.181.102.61) ?19.514 ms
>>> ? ?203.181.102.21 (203.181.102.21) ?6.054 ms
>>> ? ?203.181.102.61 (203.181.102.61) ?11.478 ms
>>> 9 ?otejbb203.kddnet.ad.jp (118.155.197.129) ?7.457 ms
>>> ? ?otejbb203.kddnet.ad.jp (59.128.7.129) ?7.835 ms
>>> ? ?otejbb204.kddnet.ad.jp (59.128.7.130) ?7.824 ms
>>> 10 ?cm-fcu203.kddnet.ad.jp (124.215.194.180) ?15.860 ms ?16.401 ms
>>> ? ?cm-fcu203.kddnet.ad.jp (124.215.194.164) ?17.519 ms
>>> 11 ?124.215.199.122 (124.215.199.122) ?7.892 ms * ?11.984 ms
>>>
>>
>


From morrowc.lists at gmail.com  Sun Dec 11 21:49:03 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 11 Dec 2011 22:49:03 -0500
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
Message-ID: <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>

On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz <faisal at snappydsl.net> wrote:
> Simple, keep traffic off paid ip transit circuits....
>

(I think joel's point was: "peer with amazon, done-and-done")

> Faisal
>
> On Dec 11, 2011, at 10:21 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>
>> Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
>>
>> Sent from my iPhone
>>
>> On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal at snappydsl.net> wrote:
>>
>>> Which leads to a question to be asked...
>>>
>>> Is netflix willing to peer directly with ISP / NSP's ?
>>>
>>> Regards.
>>>
>>> Faisal Imtiaz
>>> Snappy Internet& ?Telecom
>>>
>>>
>>> On 12/11/2011 7:29 PM, Dave Temkin wrote:
>>>> Feel free to contact peering at netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
>>>>
>>>> Regards,
>>>> -Dave Temkin
>>>> Netflix
>>>>
>>>> On 12/7/11 8:57 AM, Blake Hudson wrote:
>>>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
>>>>>
>>>>>
>>>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
>>>>>> Also checkout Adrian Cockcroft presentations on their architecture which
>>>>>> describes how they use aws and CDns etc
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>


From mhuff at ox.com  Sun Dec 11 21:54:43 2011
From: mhuff at ox.com (Matthew Huff)
Date: Sun, 11 Dec 2011 22:54:43 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <CAL9jLabYkTpkFnzoaTcwaxgaRfSNPjy1xoe9PxPQLpd6uwHBrw@mail.gmail.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>
 <m2liqiboc3.wl%randy@psg.com> <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>
 <FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>
 <CAL9jLabYkTpkFnzoaTcwaxgaRfSNPjy1xoe9PxPQLpd6uwHBrw@mail.gmail.com>
Message-ID: <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>

Consumer fios. Verizon forums are full of posts about it. Too tired this evening to worry about it.

Sent from my iPad

On Dec 11, 2011, at 10:48 PM, "Christopher Morrow" <morrowc.lists at gmail.com> wrote:

> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff <mhuff at ox.com> wrote:
>> I'm seeing the same thing from my home lan via fios. I've run a recursive dns server for years and can't reach the roots. Had to switch to using verizon's dns servers as forwarders.
>> 
> 
> business or consumer fios?
> 3  G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180)  6.662 ms
> 6.739 ms  6.788 ms
> 4  so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56)  6.852 ms
> 15.384 ms  8.184 ms
> 5  0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158)  12.857 ms  12.927 ms  13.004 ms
> 6  dcp-brdr-03.inet.qwest.net (63.146.26.105)  12.429 ms  7.847 ms  6.464 ms
> 7  lap-brdr-03.inet.qwest.net (67.14.22.78)  89.140 ms  88.929 ms  89.032 ms
> 8  63.146.26.70 (63.146.26.70)  94.879 ms  94.580 ms  93.120 ms
> 9  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.520 ms
> 58.330 ms  58.186 ms
> 10  144.232.25.193 (144.232.25.193)  49.950 ms
> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177)  49.962 ms
> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171)  47.687 ms
> 11  sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  84.416 ms
> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73)  84.667
> ms
> 12  124.215.199.122 (124.215.199.122)  195.590 ms * *
> 
> all of this seems to point at some kddi.net rouer gobbling packets,
> no? (since pretty much everyone's got the same terminating hop) - also
> note that while some folks traverse L3, my route is via qwest...
> 
> it's interesting that 701 isn't picking their other peer (sprint) here
> directly, no?
> 
>> Sent from my iPad
>> 
>> On Dec 11, 2011, at 8:07 PM, "Brandon Kim" <brandon.kim at brandontek.com> wrote:
>> 
>>> 
>>> I too am now experiencing issues. I cannot get to www.cisco.com and various websites.
>>> Some websites work lightning quick, some take a long time to load, and some just don't load at all.....
>>> 
>>> 
>>> 
>>> 
>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900
>>>> From: randy at psg.com
>>>> To: nanog at nanog.org
>>>> Subject: Re: Inaccessible network from Verizon, accessible elsewhere.
>>>> 
>>>> from home lan
>>>> 
>>>> % traceroute gw-li377.linode.com
>>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets
>>>> 1  192.168.0.1 (192.168.0.1)  1.471 ms  0.725 ms  0.555 ms
>>>> 2  tokyo10-f03.flets.2iij.net (210.149.34.72)  7.241 ms  6.651 ms  6.939 ms
>>>> 3  tokyo10-ntteast0.flets.2iij.net (210.149.34.157)  5.573 ms  6.109 ms  5.346 ms
>>>> 4  tky001lip20.iij.net (210.149.34.97)  6.410 ms  7.471 ms  7.934 ms
>>>> 5  tky001bb10.iij.net (58.138.100.209)  6.670 ms  9.251 ms  5.866 ms
>>>> 6  tky009bf00.iij.net (58.138.80.17)  6.730 ms
>>>>    tky008bf02.iij.net (58.138.80.13)  7.021 ms
>>>>    tky009bf00.iij.net (58.138.80.17)  8.593 ms
>>>> 7  tky001ix05.iij.net (58.138.82.2)  9.767 ms
>>>>    tky001ix05.iij.net (58.138.82.6)  6.101 ms
>>>>    tky001ix01.iij.net (58.138.80.106)  8.420 ms
>>>> 8  203.181.102.61 (203.181.102.61)  19.514 ms
>>>>    203.181.102.21 (203.181.102.21)  6.054 ms
>>>>    203.181.102.61 (203.181.102.61)  11.478 ms
>>>> 9  otejbb203.kddnet.ad.jp (118.155.197.129)  7.457 ms
>>>>    otejbb203.kddnet.ad.jp (59.128.7.129)  7.835 ms
>>>>    otejbb204.kddnet.ad.jp (59.128.7.130)  7.824 ms
>>>> 10  cm-fcu203.kddnet.ad.jp (124.215.194.180)  15.860 ms  16.401 ms
>>>>    cm-fcu203.kddnet.ad.jp (124.215.194.164)  17.519 ms
>>>> 11  124.215.199.122 (124.215.199.122)  7.892 ms *  11.984 ms
>>>> 
>>> 
>> 


From faisal at snappydsl.net  Sun Dec 11 22:41:23 2011
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Sun, 11 Dec 2011 23:41:23 -0500
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
Message-ID: <9ECB39B8-43F2-481F-8F19-AAA44197D678@snappydsl.net>

Thanks for the explanation...did not consider that before...will investigate.., any tips that can be shared will be welcome.
:)

Faisal

On Dec 11, 2011, at 10:49 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote:

> On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz <faisal at snappydsl.net> wrote:
>> Simple, keep traffic off paid ip transit circuits....
>> 
> 
> (I think joel's point was: "peer with amazon, done-and-done")
> 
>> Faisal
>> 
>> On Dec 11, 2011, at 10:21 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>> 
>>> Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
>>> 
>>> Sent from my iPhone
>>> 
>>> On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal at snappydsl.net> wrote:
>>> 
>>>> Which leads to a question to be asked...
>>>> 
>>>> Is netflix willing to peer directly with ISP / NSP's ?
>>>> 
>>>> Regards.
>>>> 
>>>> Faisal Imtiaz
>>>> Snappy Internet&  Telecom
>>>> 
>>>> 
>>>> On 12/11/2011 7:29 PM, Dave Temkin wrote:
>>>>> Feel free to contact peering at netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
>>>>> 
>>>>> Regards,
>>>>> -Dave Temkin
>>>>> Netflix
>>>>> 
>>>>> On 12/7/11 8:57 AM, Blake Hudson wrote:
>>>>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
>>>>>> 
>>>>>> 
>>>>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
>>>>>>> Also checkout Adrian Cockcroft presentations on their architecture which
>>>>>>> describes how they use aws and CDns etc
>>>>>>> 
>>>>>>> Martin
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From joelja at bogus.com  Sun Dec 11 23:18:06 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Sun, 11 Dec 2011 21:18:06 -0800
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
Message-ID: <4EE58E8E.8000804@bogus.com>

On 12/11/11 19:49 , Christopher Morrow wrote:
> On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz <faisal at snappydsl.net> wrote:
>> Simple, keep traffic off paid ip transit circuits....
>> 
> (I think joel's point was: "peer with amazon, done-and-done")

also probably your relationships to akamai and level3

>> Faisal
>>
>> On Dec 11, 2011, at 10:21 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>>
>>> Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
>>>
>>> Sent from my iPhone
>>>
>>> On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal at snappydsl.net> wrote:
>>>
>>>> Which leads to a question to be asked...
>>>>
>>>> Is netflix willing to peer directly with ISP / NSP's ?
>>>>
>>>> Regards.
>>>>
>>>> Faisal Imtiaz
>>>> Snappy Internet&  Telecom
>>>>
>>>>
>>>> On 12/11/2011 7:29 PM, Dave Temkin wrote:
>>>>> Feel free to contact peering at netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
>>>>>
>>>>> Regards,
>>>>> -Dave Temkin
>>>>> Netflix
>>>>>
>>>>> On 12/7/11 8:57 AM, Blake Hudson wrote:
>>>>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
>>>>>>
>>>>>>
>>>>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
>>>>>>> Also checkout Adrian Cockcroft presentations on their architecture which
>>>>>>> describes how they use aws and CDns etc
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> 



From shaun at shaun.net  Sun Dec 11 23:35:52 2011
From: shaun at shaun.net (Shaun Ewing)
Date: Mon, 12 Dec 2011 16:35:52 +1100
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <4EE58E8E.8000804@bogus.com>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
 <4EE58E8E.8000804@bogus.com>
Message-ID: <BD0C0A49-1B8F-4982-9129-53FA31EA6617@shaun.net>

On 12/12/2011, at 4:18 PM, Joel jaeggli wrote:

> also probably your relationships to akamai and level3

Probably want to add Limelight to that list as well (do Netflix even use Akamai these days?)

-Shaun
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3626 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111212/206228da/attachment.bin>

From beckman at angryox.com  Sun Dec 11 23:37:55 2011
From: beckman at angryox.com (Peter Beckman)
Date: Mon, 12 Dec 2011 00:37:55 -0500
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net>
 <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1112120034080.14406@nog.angryox.com>

On Sun, 11 Dec 2011, Christopher Morrow wrote:

> On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz <faisal at snappydsl.net> wrote:
>> Simple, keep traffic off paid ip transit circuits....
>>
>
> (I think joel's point was: "peer with amazon, done-and-done")

  DirectConnect seems to be a good way to get a dedicated 1G or 10G link
  with AWS:

  http://aws.amazon.com/directconnect/

  It's not settlement-free peering, but it's an option if you can't
  negotiate something.  Maybe it will reduce costs in some use cases.

Beckman
---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                 http://www.angryox.com/
---------------------------------------------------------------------------


From morrowc.lists at gmail.com  Mon Dec 12 00:02:04 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 12 Dec 2011 01:02:04 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>
 <m2liqiboc3.wl%randy@psg.com>
 <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>
 <FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>
 <CAL9jLabYkTpkFnzoaTcwaxgaRfSNPjy1xoe9PxPQLpd6uwHBrw@mail.gmail.com>
 <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>
Message-ID: <CAL9jLabjBvW6Xgf+RvqV6SdULXANrGwND0W0yAATU0J2E=b4HQ@mail.gmail.com>

On Sun, Dec 11, 2011 at 10:54 PM, Matthew Huff <mhuff at ox.com> wrote:
> Consumer fios. Verizon forums are full of posts about it. Too tired this evening to worry about it.

:( I'll have to do some testing when I get near a consumer fios
then... So, they squash all DNS NOT to their complexes, that seems
rather dastardly of them... considering they deployed that hateful
paxfire/nominum garbage on their recursive servers :(

-chris

> On Dec 11, 2011, at 10:48 PM, "Christopher Morrow" <morrowc.lists at gmail.com> wrote:
>
>> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff <mhuff at ox.com> wrote:
>>> I'm seeing the same thing from my home lan via fios. I've run a recursive dns server for years and can't reach the roots. Had to switch to using verizon's dns servers as forwarders.
>>>
>>
>> business or consumer fios?
>> 3 ?G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180) ?6.662 ms
>> 6.739 ms ?6.788 ms
>> 4 ?so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56) ?6.852 ms
>> 15.384 ms ?8.184 ms
>> 5 ?0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158) ?12.857 ms ?12.927 ms ?13.004 ms
>> 6 ?dcp-brdr-03.inet.qwest.net (63.146.26.105) ?12.429 ms ?7.847 ms ?6.464 ms
>> 7 ?lap-brdr-03.inet.qwest.net (67.14.22.78) ?89.140 ms ?88.929 ms ?89.032 ms
>> 8 ?63.146.26.70 (63.146.26.70) ?94.879 ms ?94.580 ms ?93.120 ms
>> 9 ?sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) ?58.520 ms
>> 58.330 ms ?58.186 ms
>> 10 ?144.232.25.193 (144.232.25.193) ?49.950 ms
>> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177) ?49.962 ms
>> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171) ?47.687 ms
>> 11 ?sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) ?84.416 ms
>> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73) ?84.667
>> ms
>> 12 ?124.215.199.122 (124.215.199.122) ?195.590 ms * *
>>
>> all of this seems to point at some kddi.net rouer gobbling packets,
>> no? (since pretty much everyone's got the same terminating hop) - also
>> note that while some folks traverse L3, my route is via qwest...
>>
>> it's interesting that 701 isn't picking their other peer (sprint) here
>> directly, no?
>>
>>> Sent from my iPad
>>>
>>> On Dec 11, 2011, at 8:07 PM, "Brandon Kim" <brandon.kim at brandontek.com> wrote:
>>>
>>>>
>>>> I too am now experiencing issues. I cannot get to www.cisco.com and various websites.
>>>> Some websites work lightning quick, some take a long time to load, and some just don't load at all.....
>>>>
>>>>
>>>>
>>>>
>>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900
>>>>> From: randy at psg.com
>>>>> To: nanog at nanog.org
>>>>> Subject: Re: Inaccessible network from Verizon, accessible elsewhere.
>>>>>
>>>>> from home lan
>>>>>
>>>>> % traceroute gw-li377.linode.com
>>>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets
>>>>> 1 ?192.168.0.1 (192.168.0.1) ?1.471 ms ?0.725 ms ?0.555 ms
>>>>> 2 ?tokyo10-f03.flets.2iij.net (210.149.34.72) ?7.241 ms ?6.651 ms ?6.939 ms
>>>>> 3 ?tokyo10-ntteast0.flets.2iij.net (210.149.34.157) ?5.573 ms ?6.109 ms ?5.346 ms
>>>>> 4 ?tky001lip20.iij.net (210.149.34.97) ?6.410 ms ?7.471 ms ?7.934 ms
>>>>> 5 ?tky001bb10.iij.net (58.138.100.209) ?6.670 ms ?9.251 ms ?5.866 ms
>>>>> 6 ?tky009bf00.iij.net (58.138.80.17) ?6.730 ms
>>>>> ? ?tky008bf02.iij.net (58.138.80.13) ?7.021 ms
>>>>> ? ?tky009bf00.iij.net (58.138.80.17) ?8.593 ms
>>>>> 7 ?tky001ix05.iij.net (58.138.82.2) ?9.767 ms
>>>>> ? ?tky001ix05.iij.net (58.138.82.6) ?6.101 ms
>>>>> ? ?tky001ix01.iij.net (58.138.80.106) ?8.420 ms
>>>>> 8 ?203.181.102.61 (203.181.102.61) ?19.514 ms
>>>>> ? ?203.181.102.21 (203.181.102.21) ?6.054 ms
>>>>> ? ?203.181.102.61 (203.181.102.61) ?11.478 ms
>>>>> 9 ?otejbb203.kddnet.ad.jp (118.155.197.129) ?7.457 ms
>>>>> ? ?otejbb203.kddnet.ad.jp (59.128.7.129) ?7.835 ms
>>>>> ? ?otejbb204.kddnet.ad.jp (59.128.7.130) ?7.824 ms
>>>>> 10 ?cm-fcu203.kddnet.ad.jp (124.215.194.180) ?15.860 ms ?16.401 ms
>>>>> ? ?cm-fcu203.kddnet.ad.jp (124.215.194.164) ?17.519 ms
>>>>> 11 ?124.215.199.122 (124.215.199.122) ?7.892 ms * ?11.984 ms
>>>>>
>>>>
>>>


From maillist at webjogger.net  Mon Dec 12 00:26:41 2011
From: maillist at webjogger.net (Adam Greene)
Date: Mon, 12 Dec 2011 01:26:41 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <CAL9jLabjBvW6Xgf+RvqV6SdULXANrGwND0W0yAATU0J2E=b4HQ@mail.gmail.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>
 <m2liqiboc3.wl%randy@psg.com> <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>
 <FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>
 <CAL9jLabYkTpkFnzoaTcwaxgaRfSNPjy1xoe9PxPQLpd6uwHBrw@mail.gmail.com>
 <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>
 <CAL9jLabjBvW6Xgf+RvqV6SdULXANrGwND0W0yAATU0J2E=b4HQ@mail.gmail.com>
Message-ID: <4EE59EA1.6070400@webjogger.net>

We're having strange issues in NYC metropolitan area.

We can trace from Verizon FIOS to some IP addresses of our ASN 11579 
block. Others don't work. The IP's that don't work seem to die at 
130.81.107.228 on the Verizon network.

Something is rotten in Denmark. Or NY. You know what I mean.

On 12/12/2011 1:02 AM, Christopher Morrow wrote:
> On Sun, Dec 11, 2011 at 10:54 PM, Matthew Huff<mhuff at ox.com>  wrote:
>> Consumer fios. Verizon forums are full of posts about it. Too tired this evening to worry about it.
> :( I'll have to do some testing when I get near a consumer fios
> then... So, they squash all DNS NOT to their complexes, that seems
> rather dastardly of them... considering they deployed that hateful
> paxfire/nominum garbage on their recursive servers :(
>
> -chris
>
>> On Dec 11, 2011, at 10:48 PM, "Christopher Morrow"<morrowc.lists at gmail.com>  wrote:
>>
>>> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff<mhuff at ox.com>  wrote:
>>>> I'm seeing the same thing from my home lan via fios. I've run a recursive dns server for years and can't reach the roots. Had to switch to using verizon's dns servers as forwarders.
>>>>
>>> business or consumer fios?
>>> 3  G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180)  6.662 ms
>>> 6.739 ms  6.788 ms
>>> 4  so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56)  6.852 ms
>>> 15.384 ms  8.184 ms
>>> 5  0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158)  12.857 ms  12.927 ms  13.004 ms
>>> 6  dcp-brdr-03.inet.qwest.net (63.146.26.105)  12.429 ms  7.847 ms  6.464 ms
>>> 7  lap-brdr-03.inet.qwest.net (67.14.22.78)  89.140 ms  88.929 ms  89.032 ms
>>> 8  63.146.26.70 (63.146.26.70)  94.879 ms  94.580 ms  93.120 ms
>>> 9  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.520 ms
>>> 58.330 ms  58.186 ms
>>> 10  144.232.25.193 (144.232.25.193)  49.950 ms
>>> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177)  49.962 ms
>>> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171)  47.687 ms
>>> 11  sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  84.416 ms
>>> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73)  84.667
>>> ms
>>> 12  124.215.199.122 (124.215.199.122)  195.590 ms * *
>>>
>>> all of this seems to point at some kddi.net rouer gobbling packets,
>>> no? (since pretty much everyone's got the same terminating hop) - also
>>> note that while some folks traverse L3, my route is via qwest...
>>>
>>> it's interesting that 701 isn't picking their other peer (sprint) here
>>> directly, no?
>>>
>>>> Sent from my iPad
>>>>
>>>> On Dec 11, 2011, at 8:07 PM, "Brandon Kim"<brandon.kim at brandontek.com>  wrote:
>>>>
>>>>> I too am now experiencing issues. I cannot get to www.cisco.com and various websites.
>>>>> Some websites work lightning quick, some take a long time to load, and some just don't load at all.....
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900
>>>>>> From: randy at psg.com
>>>>>> To: nanog at nanog.org
>>>>>> Subject: Re: Inaccessible network from Verizon, accessible elsewhere.
>>>>>>
>>>>>> from home lan
>>>>>>
>>>>>> % traceroute gw-li377.linode.com
>>>>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets
>>>>>> 1  192.168.0.1 (192.168.0.1)  1.471 ms  0.725 ms  0.555 ms
>>>>>> 2  tokyo10-f03.flets.2iij.net (210.149.34.72)  7.241 ms  6.651 ms  6.939 ms
>>>>>> 3  tokyo10-ntteast0.flets.2iij.net (210.149.34.157)  5.573 ms  6.109 ms  5.346 ms
>>>>>> 4  tky001lip20.iij.net (210.149.34.97)  6.410 ms  7.471 ms  7.934 ms
>>>>>> 5  tky001bb10.iij.net (58.138.100.209)  6.670 ms  9.251 ms  5.866 ms
>>>>>> 6  tky009bf00.iij.net (58.138.80.17)  6.730 ms
>>>>>>     tky008bf02.iij.net (58.138.80.13)  7.021 ms
>>>>>>     tky009bf00.iij.net (58.138.80.17)  8.593 ms
>>>>>> 7  tky001ix05.iij.net (58.138.82.2)  9.767 ms
>>>>>>     tky001ix05.iij.net (58.138.82.6)  6.101 ms
>>>>>>     tky001ix01.iij.net (58.138.80.106)  8.420 ms
>>>>>> 8  203.181.102.61 (203.181.102.61)  19.514 ms
>>>>>>     203.181.102.21 (203.181.102.21)  6.054 ms
>>>>>>     203.181.102.61 (203.181.102.61)  11.478 ms
>>>>>> 9  otejbb203.kddnet.ad.jp (118.155.197.129)  7.457 ms
>>>>>>     otejbb203.kddnet.ad.jp (59.128.7.129)  7.835 ms
>>>>>>     otejbb204.kddnet.ad.jp (59.128.7.130)  7.824 ms
>>>>>> 10  cm-fcu203.kddnet.ad.jp (124.215.194.180)  15.860 ms  16.401 ms
>>>>>>     cm-fcu203.kddnet.ad.jp (124.215.194.164)  17.519 ms
>>>>>> 11  124.215.199.122 (124.215.199.122)  7.892 ms *  11.984 ms
>>>>>>
>
>


From morrowc.lists at gmail.com  Mon Dec 12 01:17:06 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 12 Dec 2011 02:17:06 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <4EE59EA1.6070400@webjogger.net>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>
 <m2liqiboc3.wl%randy@psg.com>
 <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>
 <FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>
 <CAL9jLabYkTpkFnzoaTcwaxgaRfSNPjy1xoe9PxPQLpd6uwHBrw@mail.gmail.com>
 <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>
 <CAL9jLabjBvW6Xgf+RvqV6SdULXANrGwND0W0yAATU0J2E=b4HQ@mail.gmail.com>
 <4EE59EA1.6070400@webjogger.net>
Message-ID: <CAL9jLaa46dAkZ4D50LmOG7kwY9FxqPnE4neanbnvUqR+fUeNyw@mail.gmail.com>

On Mon, Dec 12, 2011 at 1:26 AM, Adam Greene <maillist at webjogger.net> wrote:
> 130.81.107.228


hrm... LCR == lata-core-router... something fairly close to you, like
2 router-hops from your first L3 hop... sounds like someone ought to
call the vz customer service line and ask for a fix :)


From maillist at webjogger.net  Mon Dec 12 01:55:39 2011
From: maillist at webjogger.net (Adam Greene)
Date: Mon, 12 Dec 2011 02:55:39 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <CAL9jLaa46dAkZ4D50LmOG7kwY9FxqPnE4neanbnvUqR+fUeNyw@mail.gmail.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>	<CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>	<4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>	<c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>	<m2liqiboc3.wl%randy@psg.com>	<BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>	<FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>	<CAL9jLabYkTpkFnzoaTcwaxgaRfSNPjy1xoe9PxPQLpd6uwHBrw@mail.gmail.com>	<0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>	<CAL9jLabjBvW6Xgf+RvqV6SdULXANrGwND0W0yAATU0J2E=b4HQ@mail.gmail.com>	<4EE59EA1.6070400@webjogger.net>
 <CAL9jLaa46dAkZ4D50LmOG7kwY9FxqPnE4neanbnvUqR+fUeNyw@mail.gmail.com>
Message-ID: <4EE5B37B.70505@webjogger.net>

Yep, tried that. Connected with a lower level tech who would not escalate.

Anyone know a Verizon NOC direct contact #?

On 12/12/2011 2:17 AM, Christopher Morrow wrote:
> On Mon, Dec 12, 2011 at 1:26 AM, Adam Greene<maillist at webjogger.net>  wrote:
>> 130.81.107.228
>
> hrm... LCR == lata-core-router... something fairly close to you, like
> 2 router-hops from your first L3 hop... sounds like someone ought to
> call the vz customer service line and ask for a fix :)
>
>


From avitkovsky at emea.att.com  Mon Dec 12 03:17:08 2011
From: avitkovsky at emea.att.com (Vitkovsky, Adam)
Date: Mon, 12 Dec 2011 10:17:08 +0100
Subject: Sad IPv4 story?
In-Reply-To: <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
 <15282.1323576426@turing-police.cc.vt.edu>
 <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com>
Message-ID: <D51498F0B6E1EF408AC4D63440BFD6F8C3847EA07A@skbramsx02.emea.att.com>

> and models that doesn't take "we may not get IPv4 space" into account and have
> a contingency plan for that *deserves* to be soundly mocked and ridiculed in
> public.

That's right

However the original post was concerning a fresh new ISP that can't run their business the way they would like
Maybe they'd like to build an mpls core which right now is not possible with only ipv6 at hand
I'd like to see the business model to build an mpls network with all the features we're used to -but solely on ipv6 -I guess the plan would be let's wait a couple years till it gets implemented and mature enough




From leigh.porter at ukbroadband.com  Mon Dec 12 04:05:02 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 12 Dec 2011 10:05:02 +0000
Subject: Sad IPv4 story?
In-Reply-To: <D51498F0B6E1EF408AC4D63440BFD6F8C3847EA07A@skbramsx02.emea.att.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
 <15282.1323576426@turing-police.cc.vt.edu>
 <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com>
 <D51498F0B6E1EF408AC4D63440BFD6F8C3847EA07A@skbramsx02.emea.att.com>
Message-ID: <D181DDABABE57E4DB72FEE003314786445941F@EALPO1.ukbroadband.com>

> -----Original Message-----
> From: Vitkovsky, Adam [mailto:avitkovsky at emea.att.com]
> Sent: 12 December 2011 09:19
> To: Eric Parsonage; Valdis.Kletnieks at vt.edu
> Cc: nanog at nanog.org
> Subject: RE: Sad IPv4 story?
> 
> > and models that doesn't take "we may not get IPv4 space" into account
> and have
> > a contingency plan for that *deserves* to be soundly mocked and
> ridiculed in
> > public.
> 
> That's right
> 
> However the original post was concerning a fresh new ISP that can't run
> their business the way they would like
> Maybe they'd like to build an mpls core which right now is not possible
> with only ipv6 at hand
> I'd like to see the business model to build an mpls network with all
> the features we're used to -but solely on ipv6 -I guess the plan would
> be let's wait a couple years till it gets implemented and mature enough

Well really this is pretty much our fault. IPv6 has been on peoples 'back burner' for far too long. Additional vendor pressure and pressure at the IETF would have pushed things forward far faster had people actually been interested in doing so.

As per an earlier post, I am shocked at how I still have vendors coming to me with equipment that is nowhere near ready for commercial IPv6 deployment, it either just does not work, is half baked or is "on the roadmap".

So now we will reap the consequences and it will be at the cost of new market entrants (which I am sure will please some people) and perhaps cold hard cash for those who cannot expand their business or have to 'buy' address space.

I know a lot of people have been working hard to move IPv6 along both here, at NANOG and other events and with their vendors. It's because of those people, like Randy perhaps that we actually have what we do now else most people would still be stuck with their heads in the sand.

Well, I am sure it'll all be OK in the end...

--
Leigh



______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From mtinka at globaltransit.net  Mon Dec 12 06:02:14 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 12 Dec 2011 20:02:14 +0800
Subject: Sad IPv4 story?
In-Reply-To: <D51498F0B6E1EF408AC4D63440BFD6F8C3847EA07A@skbramsx02.emea.att.com>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com>
 <D51498F0B6E1EF408AC4D63440BFD6F8C3847EA07A@skbramsx02.emea.att.com>
Message-ID: <201112122002.18859.mtinka@globaltransit.net>

On Monday, December 12, 2011 05:17:08 PM Vitkovsky, Adam 
wrote:

> However the original post was concerning a fresh new ISP
> that can't run their business the way they would like
> Maybe they'd like to build an mpls core which right now
> is not possible with only ipv6 at hand I'd like to see
> the business model to build an mpls network with all the
> features we're used to -but solely on ipv6 -I guess the
> plan would be let's wait a couple years till it gets
> implemented and mature enough

I've been pushing Cisco and Juniper since 2007 for LDPv6 and 
RSVPv6 since 2007. I kept getting non-commital "end of this 
year, end of this year".

After catching up with Cisco during an update of the ASR9000 
a couple of weeks back, I'm meant to understand support will 
be coming around Q1'13 on this platform (which, by 
association, might mean other IOS XR platforms like the 
CRS). It's not clear about other Cisco systems, but I'll be 
pleasantly surprised if they maintain the time lines.

All this despite the fact that drafts have been out for 
years.

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/20111212/f3214ebf/attachment-0001.bin>

From mhuff at ox.com  Mon Dec 12 07:44:56 2011
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 12 Dec 2011 08:44:56 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <4EE59EA1.6070400@webjogger.net>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>
 <m2liqiboc3.wl%randy@psg.com> <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>
 <FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>
 <CAL9jLabYkTpkFnzoaTcwaxgaRfSNPjy1xoe9PxPQLpd6uwHBrw@mail.gmail.com>
 <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>
 <CAL9jLabjBvW6Xgf+RvqV6SdULXANrGwND0W0yAATU0J2E=b4HQ@mail.gmail.com>
 <4EE59EA1.6070400@webjogger.net>
Message-ID: <483E6B0272B0284BA86D7596C40D29F901212A80D599@PUR-EXCH07.ox.com>

DSLReports Verizon forum reports routing issues in Westchester, Rockland and Nassau. I tried a few traceroutes this morning. Some went through fine, others died at the first hop within Verizon.

People are reporting mixed results calling Verizon. Some techs are saying it's a known issues, others are going through the standard script (reboot router, reboot ONT, check settings on browser, i.e. clueless, even to the point of saying that the person's router is bad and they would send them a new one).



----
Matthew Huff?            | 1 Manhattanville Rd
Director of Operations???| Purchase, NY 10577
OTA Management LLC       | Phone: 914-460-4039
aim: matthewbhuff?       | Fax:?? 914-460-4139

> -----Original Message-----
> From: Adam Greene [mailto:maillist at webjogger.net]
> Sent: Monday, December 12, 2011 1:27 AM
> To: nanog at nanog.org
> Subject: Re: Inaccessible network from Verizon, accessible elsewhere.
> 
> We're having strange issues in NYC metropolitan area.
> 
> We can trace from Verizon FIOS to some IP addresses of our ASN 11579
> block. Others don't work. The IP's that don't work seem to die at
> 130.81.107.228 on the Verizon network.
> 
> Something is rotten in Denmark. Or NY. You know what I mean.
> 
> On 12/12/2011 1:02 AM, Christopher Morrow wrote:
> > On Sun, Dec 11, 2011 at 10:54 PM, Matthew Huff<mhuff at ox.com>  wrote:
> >> Consumer fios. Verizon forums are full of posts about it. Too tired
> this evening to worry about it.
> > :( I'll have to do some testing when I get near a consumer fios
> > then... So, they squash all DNS NOT to their complexes, that seems
> > rather dastardly of them... considering they deployed that hateful
> > paxfire/nominum garbage on their recursive servers :(
> >
> > -chris
> >
> >> On Dec 11, 2011, at 10:48 PM, "Christopher
> Morrow"<morrowc.lists at gmail.com>  wrote:
> >>
> >>> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff<mhuff at ox.com>
> wrote:
> >>>> I'm seeing the same thing from my home lan via fios. I've run a
> recursive dns server for years and can't reach the roots. Had to switch
> to using verizon's dns servers as forwarders.
> >>>>
> >>> business or consumer fios?
> >>> 3  G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180)  6.662
> ms
> >>> 6.739 ms  6.788 ms
> >>> 4  so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56)  6.852 ms
> >>> 15.384 ms  8.184 ms
> >>> 5  0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158)  12.857 ms  12.927 ms
> >>> 13.004 ms
> >>> 6  dcp-brdr-03.inet.qwest.net (63.146.26.105)  12.429 ms  7.847 ms
> >>> 6.464 ms
> >>> 7  lap-brdr-03.inet.qwest.net (67.14.22.78)  89.140 ms  88.929 ms
> >>> 89.032 ms
> >>> 8  63.146.26.70 (63.146.26.70)  94.879 ms  94.580 ms  93.120 ms
> >>> 9  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.520 ms
> >>> 58.330 ms  58.186 ms
> >>> 10  144.232.25.193 (144.232.25.193)  49.950 ms
> >>> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177)  49.962 ms
> >>> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171)  47.687 ms
> >>> 11  sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  84.416 ms
> >>> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73)
> >>> 84.667 ms
> >>> 12  124.215.199.122 (124.215.199.122)  195.590 ms * *
> >>>
> >>> all of this seems to point at some kddi.net rouer gobbling packets,
> >>> no? (since pretty much everyone's got the same terminating hop) -
> >>> also note that while some folks traverse L3, my route is via
> qwest...
> >>>
> >>> it's interesting that 701 isn't picking their other peer (sprint)
> >>> here directly, no?
> >>>
> >>>> Sent from my iPad
> >>>>
> >>>> On Dec 11, 2011, at 8:07 PM, "Brandon
> Kim"<brandon.kim at brandontek.com>  wrote:
> >>>>
> >>>>> I too am now experiencing issues. I cannot get to www.cisco.com
> and various websites.
> >>>>> Some websites work lightning quick, some take a long time to
> load, and some just don't load at all.....
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900
> >>>>>> From: randy at psg.com
> >>>>>> To: nanog at nanog.org
> >>>>>> Subject: Re: Inaccessible network from Verizon, accessible
> elsewhere.
> >>>>>>
> >>>>>> from home lan
> >>>>>>
> >>>>>> % traceroute gw-li377.linode.com
> >>>>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max,
> 52
> >>>>>> byte packets
> >>>>>> 1  192.168.0.1 (192.168.0.1)  1.471 ms  0.725 ms  0.555 ms
> >>>>>> 2  tokyo10-f03.flets.2iij.net (210.149.34.72)  7.241 ms  6.651
> ms
> >>>>>> 6.939 ms
> >>>>>> 3  tokyo10-ntteast0.flets.2iij.net (210.149.34.157)  5.573 ms
> >>>>>> 6.109 ms  5.346 ms
> >>>>>> 4  tky001lip20.iij.net (210.149.34.97)  6.410 ms  7.471 ms
> 7.934
> >>>>>> ms
> >>>>>> 5  tky001bb10.iij.net (58.138.100.209)  6.670 ms  9.251 ms
> 5.866
> >>>>>> ms
> >>>>>> 6  tky009bf00.iij.net (58.138.80.17)  6.730 ms
> >>>>>>     tky008bf02.iij.net (58.138.80.13)  7.021 ms
> >>>>>>     tky009bf00.iij.net (58.138.80.17)  8.593 ms
> >>>>>> 7  tky001ix05.iij.net (58.138.82.2)  9.767 ms
> >>>>>>     tky001ix05.iij.net (58.138.82.6)  6.101 ms
> >>>>>>     tky001ix01.iij.net (58.138.80.106)  8.420 ms
> >>>>>> 8  203.181.102.61 (203.181.102.61)  19.514 ms
> >>>>>>     203.181.102.21 (203.181.102.21)  6.054 ms
> >>>>>>     203.181.102.61 (203.181.102.61)  11.478 ms
> >>>>>> 9  otejbb203.kddnet.ad.jp (118.155.197.129)  7.457 ms
> >>>>>>     otejbb203.kddnet.ad.jp (59.128.7.129)  7.835 ms
> >>>>>>     otejbb204.kddnet.ad.jp (59.128.7.130)  7.824 ms
> >>>>>> 10  cm-fcu203.kddnet.ad.jp (124.215.194.180)  15.860 ms  16.401
> ms
> >>>>>>     cm-fcu203.kddnet.ad.jp (124.215.194.164)  17.519 ms
> >>>>>> 11  124.215.199.122 (124.215.199.122)  7.892 ms *  11.984 ms
> >>>>>>
> >
> >



From tknchris at gmail.com  Mon Dec 12 08:57:29 2011
From: tknchris at gmail.com (chris)
Date: Mon, 12 Dec 2011 09:57:29 -0500
Subject: Verizon 3G/4G Mobile Internet Sales Contact?
Message-ID: <CAKnNFz-Ym4+e=Mk38Hx7p4c1N+6dMbDGjM09Q6kEjR+FftawAQ@mail.gmail.com>

Hello,

If anyone has any contact info for the correct department within Verizon
which handles getting a mobile internet service via 3G/4G, that would be a
huge help. I am trying to avoid the usual Verizon runaround of being
transferred from dept to dept because no one has any idea what I'm talking
about. I also would preferably like a static IP if possible. Tried
contacting Verizon Wireless and they are trying to sell me a MiFi and have
no idea what a static IP is :)

Thanks,
chris

From paul4004 at gmail.com  Mon Dec 12 09:10:28 2011
From: paul4004 at gmail.com (PC)
Date: Mon, 12 Dec 2011 10:10:28 -0500
Subject: Verizon 3G/4G Mobile Internet Sales Contact?
In-Reply-To: <CAKnNFz-Ym4+e=Mk38Hx7p4c1N+6dMbDGjM09Q6kEjR+FftawAQ@mail.gmail.com>
References: <CAKnNFz-Ym4+e=Mk38Hx7p4c1N+6dMbDGjM09Q6kEjR+FftawAQ@mail.gmail.com>
Message-ID: <CAJAdsDmB50t40wvwYR61mXoqvoT0SBxKZ=M-aAH3ksXgU6Ps9g@mail.gmail.com>

>From my experience:

IPV4 Static IPs nor private IP service are currently available on the 4g
service (I asked).

Even the routable IPV6 Static IPs can not receive remote traffic (at least
they failed to get ESP traffic when I tried to build a VPN with them
because the ipv4 address provided was carrier-grade natted).  This, they
seem too clueless to provide any further input on after many attempts (they
don't know IPV6) even after calling Tier 2 support from a customer account
with 2,000+ telemetry data lines.  Their IPV6 clue is very low.  The reps
cared, they just couldn't find anyone who knew the product and gave up.

For the IPV4 3g, the tech support should be able to sell you one, but it
has a $500 setup fee or something similarly absurd, making it very
uneconomical for a single unit.

On Mon, Dec 12, 2011 at 9:57 AM, chris <tknchris at gmail.com> wrote:

> Hello,
>
> If anyone has any contact info for the correct department within Verizon
> which handles getting a mobile internet service via 3G/4G, that would be a
> huge help. I am trying to avoid the usual Verizon runaround of being
> transferred from dept to dept because no one has any idea what I'm talking
> about. I also would preferably like a static IP if possible. Tried
> contacting Verizon Wireless and they are trying to sell me a MiFi and have
> no idea what a static IP is :)
>
> Thanks,
> chris
>

From tknchris at gmail.com  Mon Dec 12 09:43:40 2011
From: tknchris at gmail.com (chris)
Date: Mon, 12 Dec 2011 10:43:40 -0500
Subject: Verizon 3G/4G Mobile Internet Sales Contact?
In-Reply-To: <CAJAdsDmB50t40wvwYR61mXoqvoT0SBxKZ=M-aAH3ksXgU6Ps9g@mail.gmail.com>
References: <CAKnNFz-Ym4+e=Mk38Hx7p4c1N+6dMbDGjM09Q6kEjR+FftawAQ@mail.gmail.com>
 <CAJAdsDmB50t40wvwYR61mXoqvoT0SBxKZ=M-aAH3ksXgU6Ps9g@mail.gmail.com>
Message-ID: <CAKnNFz8F==YzHJNmGNcn2FfhctBZ7vidtZS2MkgkC2F3V2mQtQ@mail.gmail.com>

On that note, any other carriers who do have static IP offerings at a
reasonable price? Just looking for OOB really, unlimited data would be nice
too so it doesnt have to be worried about

On Mon, Dec 12, 2011 at 10:10 AM, PC <paul4004 at gmail.com> wrote:

> From my experience:
>
> IPV4 Static IPs nor private IP service are currently available on the 4g
> service (I asked).
>
> Even the routable IPV6 Static IPs can not receive remote traffic (at least
> they failed to get ESP traffic when I tried to build a VPN with them
> because the ipv4 address provided was carrier-grade natted).  This, they
> seem too clueless to provide any further input on after many attempts (they
> don't know IPV6) even after calling Tier 2 support from a customer account
> with 2,000+ telemetry data lines.  Their IPV6 clue is very low.  The reps
> cared, they just couldn't find anyone who knew the product and gave up.
>
> For the IPV4 3g, the tech support should be able to sell you one, but it
> has a $500 setup fee or something similarly absurd, making it very
> uneconomical for a single unit.
>
> On Mon, Dec 12, 2011 at 9:57 AM, chris <tknchris at gmail.com> wrote:
>
>> Hello,
>>
>> If anyone has any contact info for the correct department within Verizon
>> which handles getting a mobile internet service via 3G/4G, that would be a
>> huge help. I am trying to avoid the usual Verizon runaround of being
>> transferred from dept to dept because no one has any idea what I'm talking
>> about. I also would preferably like a static IP if possible. Tried
>> contacting Verizon Wireless and they are trying to sell me a MiFi and have
>> no idea what a static IP is :)
>>
>> Thanks,
>> chris
>>
>
>

From rfinnesey at gmail.com  Mon Dec 12 09:46:16 2011
From: rfinnesey at gmail.com (Ryan Finnesey)
Date: Mon, 12 Dec 2011 10:46:16 -0500
Subject: Verizon 3G/4G Mobile Internet Sales Contact?
In-Reply-To: <CAJAdsDmB50t40wvwYR61mXoqvoT0SBxKZ=M-aAH3ksXgU6Ps9g@mail.gmail.com>
References: <CAKnNFz-Ym4+e=Mk38Hx7p4c1N+6dMbDGjM09Q6kEjR+FftawAQ@mail.gmail.com>
 <CAJAdsDmB50t40wvwYR61mXoqvoT0SBxKZ=M-aAH3ksXgU6Ps9g@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAJgbNg3cDXhJlmF6c9X9NbLCTQcAEAAAAHrPafMv4jlJgbK8UNO0d+ABAAAAAA==@gmail.com>

I am using what is called Verizon Private Network on 4G witch gives me
private Static IPs.

Cheers
Ryan


-----Original Message-----
From: PC [mailto:paul4004 at gmail.com] 
Sent: Monday, December 12, 2011 10:10 AM
To: chris
Cc: NANOG list
Subject: Re: Verizon 3G/4G Mobile Internet Sales Contact?

>From my experience:

IPV4 Static IPs nor private IP service are currently available on the 4g
service (I asked).

Even the routable IPV6 Static IPs can not receive remote traffic (at least
they failed to get ESP traffic when I tried to build a VPN with them because
the ipv4 address provided was carrier-grade natted).  This, they seem too
clueless to provide any further input on after many attempts (they don't
know IPV6) even after calling Tier 2 support from a customer account with
2,000+ telemetry data lines.  Their IPV6 clue is very low.  The reps cared,
they just couldn't find anyone who knew the product and gave up.

For the IPV4 3g, the tech support should be able to sell you one, but it has
a $500 setup fee or something similarly absurd, making it very uneconomical
for a single unit.

On Mon, Dec 12, 2011 at 9:57 AM, chris <tknchris at gmail.com> wrote:

> Hello,
>
> If anyone has any contact info for the correct department within 
> Verizon which handles getting a mobile internet service via 3G/4G, 
> that would be a huge help. I am trying to avoid the usual Verizon 
> runaround of being transferred from dept to dept because no one has 
> any idea what I'm talking about. I also would preferably like a static 
> IP if possible. Tried contacting Verizon Wireless and they are trying 
> to sell me a MiFi and have no idea what a static IP is :)
>
> Thanks,
> chris
>



From rfinnesey at gmail.com  Mon Dec 12 09:50:13 2011
From: rfinnesey at gmail.com (Ryan Finnesey)
Date: Mon, 12 Dec 2011 10:50:13 -0500
Subject: Verizon 3G/4G Mobile Internet Sales Contact?
In-Reply-To: <CAKnNFz8F==YzHJNmGNcn2FfhctBZ7vidtZS2MkgkC2F3V2mQtQ@mail.gmail.com>
References: <CAKnNFz-Ym4+e=Mk38Hx7p4c1N+6dMbDGjM09Q6kEjR+FftawAQ@mail.gmail.com>
 <CAJAdsDmB50t40wvwYR61mXoqvoT0SBxKZ=M-aAH3ksXgU6Ps9g@mail.gmail.com>
 <CAKnNFz8F==YzHJNmGNcn2FfhctBZ7vidtZS2MkgkC2F3V2mQtQ@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAJgbNg3cDXhJlmF6c9X9NbLCTQcAEAAAACjCfBXsDD9LuJscZ3Xt+BIBAAAAAA==@gmail.com>

Both At&T and Sprint have a static offering as well.

Cheers
Ryan


-----Original Message-----
From: chris [mailto:tknchris at gmail.com] 
Sent: Monday, December 12, 2011 10:44 AM
To: PC
Cc: NANOG list
Subject: Re: Verizon 3G/4G Mobile Internet Sales Contact?

On that note, any other carriers who do have static IP offerings at a
reasonable price? Just looking for OOB really, unlimited data would be nice
too so it doesnt have to be worried about

On Mon, Dec 12, 2011 at 10:10 AM, PC <paul4004 at gmail.com> wrote:

> From my experience:
>
> IPV4 Static IPs nor private IP service are currently available on the 
> 4g service (I asked).
>
> Even the routable IPV6 Static IPs can not receive remote traffic (at 
> least they failed to get ESP traffic when I tried to build a VPN with 
> them because the ipv4 address provided was carrier-grade natted).  
> This, they seem too clueless to provide any further input on after 
> many attempts (they don't know IPV6) even after calling Tier 2 support 
> from a customer account with 2,000+ telemetry data lines.  Their IPV6 
> clue is very low.  The reps cared, they just couldn't find anyone who knew
the product and gave up.
>
> For the IPV4 3g, the tech support should be able to sell you one, but 
> it has a $500 setup fee or something similarly absurd, making it very 
> uneconomical for a single unit.
>
> On Mon, Dec 12, 2011 at 9:57 AM, chris <tknchris at gmail.com> wrote:
>
>> Hello,
>>
>> If anyone has any contact info for the correct department within 
>> Verizon which handles getting a mobile internet service via 3G/4G, 
>> that would be a huge help. I am trying to avoid the usual Verizon 
>> runaround of being transferred from dept to dept because no one has 
>> any idea what I'm talking about. I also would preferably like a 
>> static IP if possible. Tried contacting Verizon Wireless and they are 
>> trying to sell me a MiFi and have no idea what a static IP is :)
>>
>> Thanks,
>> chris
>>
>
>



From brandon.kim at brandontek.com  Mon Dec 12 10:02:25 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Mon, 12 Dec 2011 11:02:25 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901212A80D599@PUR-EXCH07.ox.com>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>,
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>,
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>,
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>,
 <m2liqiboc3.wl%randy@psg.com>
 <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>,
 <FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>,
 <CAL9jLabYkTpkFnzoaTcwaxgaRfSNPjy1xoe9PxPQLpd6uwHBrw@mail.gmail.com>,
 <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>,
 <CAL9jLabjBvW6Xgf+RvqV6SdULXANrGwND0W0yAATU0J2E=b4HQ@mail.gmail.com>,
 <4EE59EA1.6070400@webjogger.net>,
 <483E6B0272B0284BA86D7596C40D29F901212A80D599@PUR-EXCH07.ox.com>
Message-ID: <BLU158-W51E2B8BEC4A35956B4AF3EDCBC0@phx.gbl>


Yes I am in Rockland. I failed to mentioned that I was having issues with consumer FIOS.

Is anyone with Verizon on this list? This morning www.cisco.com and www.nfl.com works now.
They didn't last night.

There are still some websites that won't load or slow to load....





> From: mhuff at ox.com
> To: maillist at webjogger.net; nanog at nanog.org
> Date: Mon, 12 Dec 2011 08:44:56 -0500
> Subject: RE: Inaccessible network from Verizon, accessible elsewhere.
> 
> DSLReports Verizon forum reports routing issues in Westchester, Rockland and Nassau. I tried a few traceroutes this morning. Some went through fine, others died at the first hop within Verizon.
> 
> People are reporting mixed results calling Verizon. Some techs are saying it's a known issues, others are going through the standard script (reboot router, reboot ONT, check settings on browser, i.e. clueless, even to the point of saying that the person's router is bad and they would send them a new one).
> 
> 
> 
> ----
> Matthew Huff             | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC       | Phone: 914-460-4039
> aim: matthewbhuff        | Fax:   914-460-4139
> 
> > -----Original Message-----
> > From: Adam Greene [mailto:maillist at webjogger.net]
> > Sent: Monday, December 12, 2011 1:27 AM
> > To: nanog at nanog.org
> > Subject: Re: Inaccessible network from Verizon, accessible elsewhere.
> > 
> > We're having strange issues in NYC metropolitan area.
> > 
> > We can trace from Verizon FIOS to some IP addresses of our ASN 11579
> > block. Others don't work. The IP's that don't work seem to die at
> > 130.81.107.228 on the Verizon network.
> > 
> > Something is rotten in Denmark. Or NY. You know what I mean.
> > 
> > On 12/12/2011 1:02 AM, Christopher Morrow wrote:
> > > On Sun, Dec 11, 2011 at 10:54 PM, Matthew Huff<mhuff at ox.com>  wrote:
> > >> Consumer fios. Verizon forums are full of posts about it. Too tired
> > this evening to worry about it.
> > > :( I'll have to do some testing when I get near a consumer fios
> > > then... So, they squash all DNS NOT to their complexes, that seems
> > > rather dastardly of them... considering they deployed that hateful
> > > paxfire/nominum garbage on their recursive servers :(
> > >
> > > -chris
> > >
> > >> On Dec 11, 2011, at 10:48 PM, "Christopher
> > Morrow"<morrowc.lists at gmail.com>  wrote:
> > >>
> > >>> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff<mhuff at ox.com>
> > wrote:
> > >>>> I'm seeing the same thing from my home lan via fios. I've run a
> > recursive dns server for years and can't reach the roots. Had to switch
> > to using verizon's dns servers as forwarders.
> > >>>>
> > >>> business or consumer fios?
> > >>> 3  G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180)  6.662
> > ms
> > >>> 6.739 ms  6.788 ms
> > >>> 4  so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56)  6.852 ms
> > >>> 15.384 ms  8.184 ms
> > >>> 5  0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158)  12.857 ms  12.927 ms
> > >>> 13.004 ms
> > >>> 6  dcp-brdr-03.inet.qwest.net (63.146.26.105)  12.429 ms  7.847 ms
> > >>> 6.464 ms
> > >>> 7  lap-brdr-03.inet.qwest.net (67.14.22.78)  89.140 ms  88.929 ms
> > >>> 89.032 ms
> > >>> 8  63.146.26.70 (63.146.26.70)  94.879 ms  94.580 ms  93.120 ms
> > >>> 9  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.520 ms
> > >>> 58.330 ms  58.186 ms
> > >>> 10  144.232.25.193 (144.232.25.193)  49.950 ms
> > >>> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177)  49.962 ms
> > >>> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171)  47.687 ms
> > >>> 11  sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  84.416 ms
> > >>> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73)
> > >>> 84.667 ms
> > >>> 12  124.215.199.122 (124.215.199.122)  195.590 ms * *
> > >>>
> > >>> all of this seems to point at some kddi.net rouer gobbling packets,
> > >>> no? (since pretty much everyone's got the same terminating hop) -
> > >>> also note that while some folks traverse L3, my route is via
> > qwest...
> > >>>
> > >>> it's interesting that 701 isn't picking their other peer (sprint)
> > >>> here directly, no?
> > >>>
> > >>>> Sent from my iPad
> > >>>>
> > >>>> On Dec 11, 2011, at 8:07 PM, "Brandon
> > Kim"<brandon.kim at brandontek.com>  wrote:
> > >>>>
> > >>>>> I too am now experiencing issues. I cannot get to www.cisco.com
> > and various websites.
> > >>>>> Some websites work lightning quick, some take a long time to
> > load, and some just don't load at all.....
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900
> > >>>>>> From: randy at psg.com
> > >>>>>> To: nanog at nanog.org
> > >>>>>> Subject: Re: Inaccessible network from Verizon, accessible
> > elsewhere.
> > >>>>>>
> > >>>>>> from home lan
> > >>>>>>
> > >>>>>> % traceroute gw-li377.linode.com
> > >>>>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max,
> > 52
> > >>>>>> byte packets
> > >>>>>> 1  192.168.0.1 (192.168.0.1)  1.471 ms  0.725 ms  0.555 ms
> > >>>>>> 2  tokyo10-f03.flets.2iij.net (210.149.34.72)  7.241 ms  6.651
> > ms
> > >>>>>> 6.939 ms
> > >>>>>> 3  tokyo10-ntteast0.flets.2iij.net (210.149.34.157)  5.573 ms
> > >>>>>> 6.109 ms  5.346 ms
> > >>>>>> 4  tky001lip20.iij.net (210.149.34.97)  6.410 ms  7.471 ms
> > 7.934
> > >>>>>> ms
> > >>>>>> 5  tky001bb10.iij.net (58.138.100.209)  6.670 ms  9.251 ms
> > 5.866
> > >>>>>> ms
> > >>>>>> 6  tky009bf00.iij.net (58.138.80.17)  6.730 ms
> > >>>>>>     tky008bf02.iij.net (58.138.80.13)  7.021 ms
> > >>>>>>     tky009bf00.iij.net (58.138.80.17)  8.593 ms
> > >>>>>> 7  tky001ix05.iij.net (58.138.82.2)  9.767 ms
> > >>>>>>     tky001ix05.iij.net (58.138.82.6)  6.101 ms
> > >>>>>>     tky001ix01.iij.net (58.138.80.106)  8.420 ms
> > >>>>>> 8  203.181.102.61 (203.181.102.61)  19.514 ms
> > >>>>>>     203.181.102.21 (203.181.102.21)  6.054 ms
> > >>>>>>     203.181.102.61 (203.181.102.61)  11.478 ms
> > >>>>>> 9  otejbb203.kddnet.ad.jp (118.155.197.129)  7.457 ms
> > >>>>>>     otejbb203.kddnet.ad.jp (59.128.7.129)  7.835 ms
> > >>>>>>     otejbb204.kddnet.ad.jp (59.128.7.130)  7.824 ms
> > >>>>>> 10  cm-fcu203.kddnet.ad.jp (124.215.194.180)  15.860 ms  16.401
> > ms
> > >>>>>>     cm-fcu203.kddnet.ad.jp (124.215.194.164)  17.519 ms
> > >>>>>> 11  124.215.199.122 (124.215.199.122)  7.892 ms *  11.984 ms
> > >>>>>>
> > >
> > >
> 
> 
 		 	   		  

From esavage at digitalrage.org  Mon Dec 12 10:21:36 2011
From: esavage at digitalrage.org (Elijah Savage)
Date: Mon, 12 Dec 2011 11:21:36 -0500 (EST)
Subject: Verizon 3G/4G Mobile Internet Sales Contact?
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAJgbNg3cDXhJlmF6c9X9NbLCTQcAEAAAACjCfBXsDD9LuJscZ3Xt+BIBAAAAAA==@gmail.com>
Message-ID: <30150212.374.1323706896147.JavaMail.root@ubuntu.digitalrage.org>

I am using what you are looking for today with VPN connectivity and it has been discussed on this list previously. There are some things you should be aware of with static ip. Contact me offline and I may be able to put you in contact with someone.

----- Original Message -----
From: "Ryan Finnesey" <rfinnesey at gmail.com>
To: "chris" <tknchris at gmail.com>, "PC" <paul4004 at gmail.com>
Cc: "NANOG list" <nanog at nanog.org>
Sent: Monday, December 12, 2011 10:50:13 AM
Subject: RE: Verizon 3G/4G Mobile Internet Sales Contact?

Both At&T and Sprint have a static offering as well.

Cheers
Ryan


-----Original Message-----
From: chris [mailto:tknchris at gmail.com] 
Sent: Monday, December 12, 2011 10:44 AM
To: PC
Cc: NANOG list
Subject: Re: Verizon 3G/4G Mobile Internet Sales Contact?

On that note, any other carriers who do have static IP offerings at a
reasonable price? Just looking for OOB really, unlimited data would be nice
too so it doesnt have to be worried about

On Mon, Dec 12, 2011 at 10:10 AM, PC <paul4004 at gmail.com> wrote:

> From my experience:
>
> IPV4 Static IPs nor private IP service are currently available on the 
> 4g service (I asked).
>
> Even the routable IPV6 Static IPs can not receive remote traffic (at 
> least they failed to get ESP traffic when I tried to build a VPN with 
> them because the ipv4 address provided was carrier-grade natted).  
> This, they seem too clueless to provide any further input on after 
> many attempts (they don't know IPV6) even after calling Tier 2 support 
> from a customer account with 2,000+ telemetry data lines.  Their IPV6 
> clue is very low.  The reps cared, they just couldn't find anyone who knew
the product and gave up.
>
> For the IPV4 3g, the tech support should be able to sell you one, but 
> it has a $500 setup fee or something similarly absurd, making it very 
> uneconomical for a single unit.
>
> On Mon, Dec 12, 2011 at 9:57 AM, chris <tknchris at gmail.com> wrote:
>
>> Hello,
>>
>> If anyone has any contact info for the correct department within 
>> Verizon which handles getting a mobile internet service via 3G/4G, 
>> that would be a huge help. I am trying to avoid the usual Verizon 
>> runaround of being transferred from dept to dept because no one has 
>> any idea what I'm talking about. I also would preferably like a 
>> static IP if possible. Tried contacting Verizon Wireless and they are 
>> trying to sell me a MiFi and have no idea what a static IP is :)
>>
>> Thanks,
>> chris
>>
>
>




From wayne at dpctech.com  Mon Dec 12 10:24:38 2011
From: wayne at dpctech.com (Wayne )
Date: Mon, 12 Dec 2011 11:24:38 -0500
Subject: Inaccessible network from Verizon, accessible elsewhere.
In-Reply-To: <BLU158-W51E2B8BEC4A35956B4AF3EDCBC0@phx.gbl>
References: <CA+buB7d=+AtLc=PoKRCHVdwu-C8VuO3cs7qsyu8a2FTwXKY0fQ@mail.gmail.com>,
 <CAD8GWstTjDzRstH0-08oUGJkaW7zYwjA7bOhZhbg3d348F7v8g@mail.gmail.com>,
 <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>,
 <c9419ca6-fc25-40a2-b303-41ce82cef9cb@email.android.com>,
 <m2liqiboc3.wl%randy@psg.com> <BLU158-W11D8BE64C0C2B19749FDBFDCBC0@phx.gbl>,
 <FD34C823-6B58-449F-8FF1-52C2F487B650@ox.com>,
 <CAL9jLabYkTpkFnzoaTcwaxgaRfSNPjy1xoe9PxPQLpd6uwHBrw@mail.gmail.com>,
 <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>,
 <CAL9jLabjBvW6Xgf+RvqV6SdULXANrGwND0W0yAATU0J2E=b4HQ@mail.gmail.com>,
 <4EE59EA1.6070400@webjogger.net>,
 <483E6B0272B0284BA86D7596C40D29F901212A80D599@PUR-EXCH07.ox.com>
 <BLU158-W51E2B8BEC4A35956B4AF3EDCBC0@phx.gbl>
Message-ID: <009501ccb8ea$8f1a5f30$ad4f1d90$@dpctech.com>

Yes www.speedtest.net & www.gotomypc are also inaccessible or very slow
along with many other sites.  Experiencing these problems in Nassau and
Westchester County on consumer fios.


-----Original Message-----
From: Brandon Kim [mailto:brandon.kim at brandontek.com] 
Sent: Monday, December 12, 2011 11:02 AM
To: nanog group
Subject: RE: Inaccessible network from Verizon, accessible elsewhere.


Yes I am in Rockland. I failed to mentioned that I was having issues with
consumer FIOS.

Is anyone with Verizon on this list? This morning www.cisco.com and
www.nfl.com works now.
They didn't last night.

There are still some websites that won't load or slow to load....





> From: mhuff at ox.com
> To: maillist at webjogger.net; nanog at nanog.org
> Date: Mon, 12 Dec 2011 08:44:56 -0500
> Subject: RE: Inaccessible network from Verizon, accessible elsewhere.
> 
> DSLReports Verizon forum reports routing issues in Westchester, Rockland
and Nassau. I tried a few traceroutes this morning. Some went through fine,
others died at the first hop within Verizon.
> 
> People are reporting mixed results calling Verizon. Some techs are saying
it's a known issues, others are going through the standard script (reboot
router, reboot ONT, check settings on browser, i.e. clueless, even to the
point of saying that the person's router is bad and they would send them a
new one).
> 
> 
> 
> ----
> Matthew Huff             | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC       | Phone: 914-460-4039
> aim: matthewbhuff        | Fax:   914-460-4139
> 
> > -----Original Message-----
> > From: Adam Greene [mailto:maillist at webjogger.net]
> > Sent: Monday, December 12, 2011 1:27 AM
> > To: nanog at nanog.org
> > Subject: Re: Inaccessible network from Verizon, accessible elsewhere.
> > 
> > We're having strange issues in NYC metropolitan area.
> > 
> > We can trace from Verizon FIOS to some IP addresses of our ASN 11579 
> > block. Others don't work. The IP's that don't work seem to die at
> > 130.81.107.228 on the Verizon network.
> > 
> > Something is rotten in Denmark. Or NY. You know what I mean.
> > 
> > On 12/12/2011 1:02 AM, Christopher Morrow wrote:
> > > On Sun, Dec 11, 2011 at 10:54 PM, Matthew Huff<mhuff at ox.com>  wrote:
> > >> Consumer fios. Verizon forums are full of posts about it. Too 
> > >> tired
> > this evening to worry about it.
> > > :( I'll have to do some testing when I get near a consumer fios 
> > > then... So, they squash all DNS NOT to their complexes, that seems 
> > > rather dastardly of them... considering they deployed that hateful 
> > > paxfire/nominum garbage on their recursive servers :(
> > >
> > > -chris
> > >
> > >> On Dec 11, 2011, at 10:48 PM, "Christopher
> > Morrow"<morrowc.lists at gmail.com>  wrote:
> > >>
> > >>> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff<mhuff at ox.com>
> > wrote:
> > >>>> I'm seeing the same thing from my home lan via fios. I've run a
> > recursive dns server for years and can't reach the roots. Had to 
> > switch to using verizon's dns servers as forwarders.
> > >>>>
> > >>> business or consumer fios?
> > >>> 3  G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180)  
> > >>> 6.662
> > ms
> > >>> 6.739 ms  6.788 ms
> > >>> 4  so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56)  6.852 
> > >>> ms
> > >>> 15.384 ms  8.184 ms
> > >>> 5  0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158)  12.857 ms  12.927 
> > >>> ms
> > >>> 13.004 ms
> > >>> 6  dcp-brdr-03.inet.qwest.net (63.146.26.105)  12.429 ms  7.847 
> > >>> ms
> > >>> 6.464 ms
> > >>> 7  lap-brdr-03.inet.qwest.net (67.14.22.78)  89.140 ms  88.929 
> > >>> ms
> > >>> 89.032 ms
> > >>> 8  63.146.26.70 (63.146.26.70)  94.879 ms  94.580 ms  93.120 ms
> > >>> 9  sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112)  58.520 ms
> > >>> 58.330 ms  58.186 ms
> > >>> 10  144.232.25.193 (144.232.25.193)  49.950 ms 
> > >>> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177)  49.962 ms 
> > >>> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171)  47.687 ms
> > >>> 11  sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207)  84.416 
> > >>> ms
> > >>> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73)
> > >>> 84.667 ms
> > >>> 12  124.215.199.122 (124.215.199.122)  195.590 ms * *
> > >>>
> > >>> all of this seems to point at some kddi.net rouer gobbling 
> > >>> packets, no? (since pretty much everyone's got the same 
> > >>> terminating hop) - also note that while some folks traverse L3, 
> > >>> my route is via
> > qwest...
> > >>>
> > >>> it's interesting that 701 isn't picking their other peer 
> > >>> (sprint) here directly, no?
> > >>>
> > >>>> Sent from my iPad
> > >>>>
> > >>>> On Dec 11, 2011, at 8:07 PM, "Brandon
> > Kim"<brandon.kim at brandontek.com>  wrote:
> > >>>>
> > >>>>> I too am now experiencing issues. I cannot get to 
> > >>>>> www.cisco.com
> > and various websites.
> > >>>>> Some websites work lightning quick, some take a long time to
> > load, and some just don't load at all.....
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900
> > >>>>>> From: randy at psg.com
> > >>>>>> To: nanog at nanog.org
> > >>>>>> Subject: Re: Inaccessible network from Verizon, accessible
> > elsewhere.
> > >>>>>>
> > >>>>>> from home lan
> > >>>>>>
> > >>>>>> % traceroute gw-li377.linode.com traceroute to 
> > >>>>>> gw-li377.linode.com (106.187.34.1), 64 hops max,
> > 52
> > >>>>>> byte packets
> > >>>>>> 1  192.168.0.1 (192.168.0.1)  1.471 ms  0.725 ms  0.555 ms
> > >>>>>> 2  tokyo10-f03.flets.2iij.net (210.149.34.72)  7.241 ms  
> > >>>>>> 6.651
> > ms
> > >>>>>> 6.939 ms
> > >>>>>> 3  tokyo10-ntteast0.flets.2iij.net (210.149.34.157)  5.573 ms
> > >>>>>> 6.109 ms  5.346 ms
> > >>>>>> 4  tky001lip20.iij.net (210.149.34.97)  6.410 ms  7.471 ms
> > 7.934
> > >>>>>> ms
> > >>>>>> 5  tky001bb10.iij.net (58.138.100.209)  6.670 ms  9.251 ms
> > 5.866
> > >>>>>> ms
> > >>>>>> 6  tky009bf00.iij.net (58.138.80.17)  6.730 ms
> > >>>>>>     tky008bf02.iij.net (58.138.80.13)  7.021 ms
> > >>>>>>     tky009bf00.iij.net (58.138.80.17)  8.593 ms
> > >>>>>> 7  tky001ix05.iij.net (58.138.82.2)  9.767 ms
> > >>>>>>     tky001ix05.iij.net (58.138.82.6)  6.101 ms
> > >>>>>>     tky001ix01.iij.net (58.138.80.106)  8.420 ms
> > >>>>>> 8  203.181.102.61 (203.181.102.61)  19.514 ms
> > >>>>>>     203.181.102.21 (203.181.102.21)  6.054 ms
> > >>>>>>     203.181.102.61 (203.181.102.61)  11.478 ms
> > >>>>>> 9  otejbb203.kddnet.ad.jp (118.155.197.129)  7.457 ms
> > >>>>>>     otejbb203.kddnet.ad.jp (59.128.7.129)  7.835 ms
> > >>>>>>     otejbb204.kddnet.ad.jp (59.128.7.130)  7.824 ms
> > >>>>>> 10  cm-fcu203.kddnet.ad.jp (124.215.194.180)  15.860 ms  
> > >>>>>> 16.401
> > ms
> > >>>>>>     cm-fcu203.kddnet.ad.jp (124.215.194.164)  17.519 ms
> > >>>>>> 11  124.215.199.122 (124.215.199.122)  7.892 ms *  11.984 ms
> > >>>>>>
> > >
> > >
> 
> 
 		 	   		  



From tknchris at gmail.com  Mon Dec 12 11:03:01 2011
From: tknchris at gmail.com (chris)
Date: Mon, 12 Dec 2011 12:03:01 -0500
Subject: Verizon 3G/4G Mobile Internet Sales Contact?
In-Reply-To: <CAJAdsDmB50t40wvwYR61mXoqvoT0SBxKZ=M-aAH3ksXgU6Ps9g@mail.gmail.com>
References: <CAKnNFz-Ym4+e=Mk38Hx7p4c1N+6dMbDGjM09Q6kEjR+FftawAQ@mail.gmail.com>
 <CAJAdsDmB50t40wvwYR61mXoqvoT0SBxKZ=M-aAH3ksXgU6Ps9g@mail.gmail.com>
Message-ID: <CAKnNFz8gD7np0S3Jamx1nQs7gTX4V_aC7PYh5kS9zrS49gTsZw@mail.gmail.com>

Hello,

Someone contacted me offlist and got me direct contact info to someone at
VZ who know exactly what I was looking for and was very helpful. And the
pricing is quite fair :)

Thanks to everyone who sent me info.
chris

On Mon, Dec 12, 2011 at 10:10 AM, PC <paul4004 at gmail.com> wrote:

> From my experience:
>
> IPV4 Static IPs nor private IP service are currently available on the 4g
> service (I asked).
>
> Even the routable IPV6 Static IPs can not receive remote traffic (at least
> they failed to get ESP traffic when I tried to build a VPN with them
> because the ipv4 address provided was carrier-grade natted).  This, they
> seem too clueless to provide any further input on after many attempts (they
> don't know IPV6) even after calling Tier 2 support from a customer account
> with 2,000+ telemetry data lines.  Their IPV6 clue is very low.  The reps
> cared, they just couldn't find anyone who knew the product and gave up.
>
> For the IPV4 3g, the tech support should be able to sell you one, but it
> has a $500 setup fee or something similarly absurd, making it very
> uneconomical for a single unit.
>
> On Mon, Dec 12, 2011 at 9:57 AM, chris <tknchris at gmail.com> wrote:
>
>> Hello,
>>
>> If anyone has any contact info for the correct department within Verizon
>> which handles getting a mobile internet service via 3G/4G, that would be a
>> huge help. I am trying to avoid the usual Verizon runaround of being
>> transferred from dept to dept because no one has any idea what I'm talking
>> about. I also would preferably like a static IP if possible. Tried
>> contacting Verizon Wireless and they are trying to sell me a MiFi and have
>> no idea what a static IP is :)
>>
>> Thanks,
>> chris
>>
>
>

From brandon.kim at brandontek.com  Mon Dec 12 11:48:13 2011
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Mon, 12 Dec 2011 12:48:13 -0500
Subject: Verizon 3G/4G Mobile Internet Sales Contact?
In-Reply-To: <CAKnNFz8gD7np0S3Jamx1nQs7gTX4V_aC7PYh5kS9zrS49gTsZw@mail.gmail.com>
References: <CAKnNFz-Ym4+e=Mk38Hx7p4c1N+6dMbDGjM09Q6kEjR+FftawAQ@mail.gmail.com>,
 <CAJAdsDmB50t40wvwYR61mXoqvoT0SBxKZ=M-aAH3ksXgU6Ps9g@mail.gmail.com>,
 <CAKnNFz8gD7np0S3Jamx1nQs7gTX4V_aC7PYh5kS9zrS49gTsZw@mail.gmail.com>
Message-ID: <BLU158-W111A48A0BC1612B2C2D66DCBC0@phx.gbl>


How much was the pricing and is it unlimited BW?

I may be interested too depending on costs....




> Date: Mon, 12 Dec 2011 12:03:01 -0500
> Subject: Re: Verizon 3G/4G Mobile Internet Sales Contact?
> From: tknchris at gmail.com
> To: paul4004 at gmail.com
> CC: nanog at nanog.org
> 
> Hello,
> 
> Someone contacted me offlist and got me direct contact info to someone at
> VZ who know exactly what I was looking for and was very helpful. And the
> pricing is quite fair :)
> 
> Thanks to everyone who sent me info.
> chris
> 
> On Mon, Dec 12, 2011 at 10:10 AM, PC <paul4004 at gmail.com> wrote:
> 
> > From my experience:
> >
> > IPV4 Static IPs nor private IP service are currently available on the 4g
> > service (I asked).
> >
> > Even the routable IPV6 Static IPs can not receive remote traffic (at least
> > they failed to get ESP traffic when I tried to build a VPN with them
> > because the ipv4 address provided was carrier-grade natted).  This, they
> > seem too clueless to provide any further input on after many attempts (they
> > don't know IPV6) even after calling Tier 2 support from a customer account
> > with 2,000+ telemetry data lines.  Their IPV6 clue is very low.  The reps
> > cared, they just couldn't find anyone who knew the product and gave up.
> >
> > For the IPV4 3g, the tech support should be able to sell you one, but it
> > has a $500 setup fee or something similarly absurd, making it very
> > uneconomical for a single unit.
> >
> > On Mon, Dec 12, 2011 at 9:57 AM, chris <tknchris at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> If anyone has any contact info for the correct department within Verizon
> >> which handles getting a mobile internet service via 3G/4G, that would be a
> >> huge help. I am trying to avoid the usual Verizon runaround of being
> >> transferred from dept to dept because no one has any idea what I'm talking
> >> about. I also would preferably like a static IP if possible. Tried
> >> contacting Verizon Wireless and they are trying to sell me a MiFi and have
> >> no idea what a static IP is :)
> >>
> >> Thanks,
> >> chris
> >>
> >
> >
 		 	   		  

From cody at killsudo.info  Mon Dec 12 12:07:51 2011
From: cody at killsudo.info (cody at killsudo.info)
Date: Mon, 12 Dec 2011 12:07:51 -0600
Subject: Verizon[AS 19262] connectivity issues to AS7393
Message-ID: <0ec31061ff459f583f63d4b92d305289.squirrel@killsudo.info>

We have a client that is complaining of connectivity issues and his
trace-routes are stopping inside Verizon's network.

1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [192.168.1.1]
2 5 ms 4 ms 4 ms L100.NYCMNY-VFTTP-151.verizon-gni.net [98.116.13
4.1]
3 8 ms 7 ms 7 ms G11-0-0-1251.NYCMNY-LCR-12.verizon-gni.net [130.
81.139.32]
4 * * * Request timed out.
5 * * * Request timed out.

We have no issues reaching 98.116.134.1 from any of our providers. I asked
the client to contact Verizon and Verizon tech's are responding that the
issue is not Verizon.

Any chance someone from Verizon could contact me so we can find the real
problem?

Thanks

Cody



From cody at killsudo.info  Mon Dec 12 12:34:22 2011
From: cody at killsudo.info (cody at killsudo.info)
Date: Mon, 12 Dec 2011 12:34:22 -0600
Subject: Verizon[AS 19262] connectivity issues to AS7393
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901212A80D5A0@PUR-EXCH07.ox.com>
References: <0ec31061ff459f583f63d4b92d305289.squirrel@killsudo.info>
 <483E6B0272B0284BA86D7596C40D29F901212A80D5A0@PUR-EXCH07.ox.com>
Message-ID: <fba53cdd28876c3462c201fe97f33612.squirrel@killsudo.info>

The client just contacted us again to say that their issue has been
resolved. We are still waiting on a updated trace-route to see what has
changed.

Regards

Cody

> Not from Verizon, but Verizon's been having routing problems all weekend,
> getting much worse yesterday. The nexus may be in the Verizon / Level 3
> handoff, but it may be changing as Verizon routes around the issues.
>
>
> ----
> Matthew Huff?            | 1 Manhattanville Rd
> Director of Operations???| Purchase, NY 10577
> OTA Management LLC       | Phone: 914-460-4039
> aim: matthewbhuff?       | Fax:?? 914-460-4139
>
>
>> -----Original Message-----
>> From: cody at killsudo.info [mailto:cody at killsudo.info]
>> Sent: Monday, December 12, 2011 1:08 PM
>> To: nanog at nanog.org
>> Subject: Verizon[AS 19262] connectivity issues to AS7393
>>
>> We have a client that is complaining of connectivity issues and his
>> trace-routes are stopping inside Verizon's network.
>>
>> 1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [192.168.1.1]
>> 2 5 ms 4 ms 4 ms L100.NYCMNY-VFTTP-151.verizon-gni.net [98.116.13 4.1]
>> 3 8 ms 7 ms 7 ms G11-0-0-1251.NYCMNY-LCR-12.verizon-gni.net [130.
>> 81.139.32]
>> 4 * * * Request timed out.
>> 5 * * * Request timed out.
>>
>> We have no issues reaching 98.116.134.1 from any of our providers. I
>> asked the client to contact Verizon and Verizon tech's are responding
>> that the issue is not Verizon.
>>
>> Any chance someone from Verizon could contact me so we can find the
>> real problem?
>>
>> Thanks
>>
>> Cody
>>
>
>




From eesslinger at fpu-tn.com  Mon Dec 12 13:10:54 2011
From: eesslinger at fpu-tn.com (Eric J Esslinger)
Date: Mon, 12 Dec 2011 13:10:54 -0600
Subject: recommendations for external montioring services?
Message-ID: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>

I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings')
I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems  but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail).

__________________________
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 edward.dore at freethought-internet.co.uk  Mon Dec 12 13:18:07 2011
From: edward.dore at freethought-internet.co.uk (Edward Dore)
Date: Mon, 12 Dec 2011 19:18:07 +0000
Subject: recommendations for external montioring services?
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
Message-ID: <8963FB5F-E5AF-4967-A220-CD6420C7E729@freethought-internet.co.uk>

Take a look at Panopta - we use it to compliment our internal monitoring and find it great compared to some of the systems we've used in the past (Pingdom, Binary Canary).

The interface is easy to use and responsive, we don't get false positives and there are a good range of checks. There's an API as well if you want to integrate it.

I'd stay clear of the software agent though, we've had a few issues with that. For remote service checks we love it.

Edward Dore 
Freethought Internet 

On 12 Dec 2011, at 19:10, Eric J Esslinger wrote:

> I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings')
> I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems  but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail).
> 
> __________________________
> 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 patrick at ianai.net  Mon Dec 12 14:10:20 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 12 Dec 2011 15:10:20 -0500
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <4EE58E8E.8000804@bogus.com>
References: <20111203004732.GH13315@hijacked.us>
 <CAK80Fn+wRcjwC8kUPsO7Eh-zgdOQVcb29oTNC1JTRDj7U0sv+g@mail.gmail.com>
 <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
 <4EE58E8E.8000804@bogus.com>
Message-ID: <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net>

On Dec 12, 2011, at 12:18 AM, Joel jaeggli wrote:
> On 12/11/11 19:49 , Christopher Morrow wrote:
>> On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz <faisal at snappydsl.net> wrote:
>>> Simple, keep traffic off paid ip transit circuits....
>>> 
>> (I think joel's point was: "peer with amazon, done-and-done")
> 
> also probably your relationships to akamai and level3

Netflix's EC2 instances do not speak to end users AFAIK.  I believe Akamai, LLNW, & L3 are the only companies that stream movies for Netflix.  Peer with the CDNs to save your transit.

Happy to be educated otherwise if someone knows more than I do.

Netflix's client is also _very_ intelligent.  If a user cannot get high enough quality from CDN_1, it will switch to CDN_2 without interrupting the stream.  Which is nice if you have good connectivity to one but not the other CDN.  (Note I spoke of "good", not "inexpensive" connectivity.  The NF client doesn't know how much it costs you to show a video, only whether there is packet loss.)

-- 
TTFN,
patrick


>>> Faisal
>>> 
>>> On Dec 11, 2011, at 10:21 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>>> 
>>>> Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve?
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On Dec 11, 2011, at 18:06, Faisal Imtiaz <faisal at snappydsl.net> wrote:
>>>> 
>>>>> Which leads to a question to be asked...
>>>>> 
>>>>> Is netflix willing to peer directly with ISP / NSP's ?
>>>>> 
>>>>> Regards.
>>>>> 
>>>>> Faisal Imtiaz
>>>>> Snappy Internet&  Telecom
>>>>> 
>>>>> 
>>>>> On 12/11/2011 7:29 PM, Dave Temkin wrote:
>>>>>> Feel free to contact peering at netflix<dot>com - we're happy to provide you with delivery statistics for traffic terminating on your network.
>>>>>> 
>>>>>> Regards,
>>>>>> -Dave Temkin
>>>>>> Netflix
>>>>>> 
>>>>>> On 12/7/11 8:57 AM, Blake Hudson wrote:
>>>>>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services).
>>>>>>> 
>>>>>>> 
>>>>>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM:
>>>>>>>> Also checkout Adrian Cockcroft presentations on their architecture which
>>>>>>>> describes how they use aws and CDns etc
>>>>>>>> 
>>>>>>>> Martin
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
> 



From ryan at u13.net  Mon Dec 12 14:37:33 2011
From: ryan at u13.net (Ryan Rawdon)
Date: Mon, 12 Dec 2011 15:37:33 -0500
Subject: recommendations for external montioring services?
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
Message-ID: <32F5E894-B48D-4A79-A9D5-CEC85A9B2341@u13.net>


On Dec 12, 2011, at 2:10 PM, Eric J Esslinger wrote:

> I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings')
> I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems  but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail).
> 

I have been passively looking for external monitoring with similar requirements, though I'm curious about one more requirement if people chiming in can share it - whether or not said vendor supports IPv6 for both external service checks and potentially for agent communications as well.


> __________________________
> 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 weaselkeeper at gmail.com  Mon Dec 12 14:37:39 2011
From: weaselkeeper at gmail.com (Jim Richardson)
Date: Mon, 12 Dec 2011 12:37:39 -0800
Subject: recommendations for external montioring services?
In-Reply-To: <8963FB5F-E5AF-4967-A220-CD6420C7E729@freethought-internet.co.uk>
References: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
 <8963FB5F-E5AF-4967-A220-CD6420C7E729@freethought-internet.co.uk>
Message-ID: <CAORNjypZmeG_nObZOjRykbeGcW_jdKzapKgipFWza1gPyVUU6w@mail.gmail.com>

On Mon, Dec 12, 2011 at 11:18 AM, Edward Dore
<edward.dore at freethought-internet.co.uk> wrote:
> Take a look at Panopta - we use it to compliment our internal monitoring and find it great compared to some of the systems we've used in the past (Pingdom, Binary Canary).
>
> The interface is easy to use and responsive, we don't get false positives and there are a good range of checks. There's an API as well if you want to integrate it.
>
> I'd stay clear of the software agent though, we've had a few issues with that. For remote service checks we love it.
>
> Edward Dore
> Freethought Internet
>
> On 12 Dec 2011, at 19:10, Eric J Esslinger wrote:
>
>> I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings')
>> I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems ?but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail).
>>
>> _____


Nagios, or Zabbix are the ones I am most familiar with.  Zabbix is a
bit involved to set up, and may not be what you need in the scale of
things.  Nagios is a bit cumbersome to keep up with rapidly changing
systems of any size, but is good for small (and large) setups that are
more static.  Not without it's quirks mind, and takes a bit of work to
set up if you've never done it before.  But doesn't require a DB
backend, or any other stuff, just a server to put it on.  No agent
needed, as long as everything you want to check is "gettable" from the
server, like checking that a mail server is available for connections,
etc.  But can use agent checks, or pretty much any other checks.

-- 
http://neon-buddha.net


From nanog at lacutt.com  Mon Dec 12 14:47:01 2011
From: nanog at lacutt.com (Derrick H.)
Date: Mon, 12 Dec 2011 14:47:01 -0600
Subject: recommendations for external montioring services?
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
Message-ID: <20111212204701.GN19342@nm.lacutt>

On Mon, Dec 12, 2011 at 01:10:54PM -0600, Eric J Esslinger wrote:
> I'm not looking to monitor a massive infrastructure: 3 web sites, 2
> mail servers (pop,imap,submission port, https webmail), 4 dns servers
> (including lookups to ensure they're not listening but not talking),
> and one inbound mx. A few network points to ping to ensure
> connectivity throughout my system. Scheduled notification windows (for
> example, during work hours I don't want my phone pinged unless it's
> everything going offline. Off hours I do. Secondary notifications if
> problem persists to other users, or in the event of many triggers.
> That sort of thing). Sensitivity settings (If web server 1 shows down
> for 5 min, that's not a big deal. Another one if it doesn't respond to
> repeated queries within 1 minute is a big deal) A Weekly summary of
> issues would be nice. (especially the 'well it was down for a short
> bit but we didn't notify as per settings') I don't have a lot of money
> to throw at this. I DO have detailed internal monitoring of our
> systems  but sometimes that is not entirely useful, due to the fact
> that there are a few 'single points of failure' within our
> network/notification system, not to mention if the monitor itself goes
> offline it's not exactly going to be able to tell me about it. (and
> that happened once, right before the mail server decided to stop
> receiving mail).

You may want to check out http://www.panopta.com/ 
Works well for me with reasonable pricing.


Derrick

> 
> __________________________
> 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 simon at slimey.org  Mon Dec 12 14:56:59 2011
From: simon at slimey.org (Simon Lockhart)
Date: Mon, 12 Dec 2011 20:56:59 +0000
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net>
References: <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
 <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net>
Message-ID: <20111212205659.GA20184@virtual.bogons.net>

On Mon Dec 12, 2011 at 03:10:20PM -0500, Patrick W. Gilmore wrote:
> I believe Akamai,
> LLNW, & L3 are the only companies that stream movies for Netflix.  Peer with
> the CDNs to save your transit.

That would be good if more than one of those CDNs peered openly.

Simon


From raymond at prolocation.net  Mon Dec 12 15:11:54 2011
From: raymond at prolocation.net (Raymond Dijkxhoorn)
Date: Mon, 12 Dec 2011 22:11:54 +0100 (CET)
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <20111212205659.GA20184@virtual.bogons.net>
References: <20111203005847.GI13315@hijacked.us>
 <CAGDKorJ02XYJF-5sV8no7VKch8AVud85SLjWP4zcZO=+hcJ+Ag@mail.gmail.com>
 <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
 <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net>
 <20111212205659.GA20184@virtual.bogons.net>
Message-ID: <alpine.LFD.2.00.1112122210100.12219@noc.prolocation.net>

Hi!

>> I believe Akamai,
>> LLNW, & L3 are the only companies that stream movies for Netflix.  Peer with
>> the CDNs to save your transit.

> That would be good if more than one of those CDNs peered openly.

So what one doesnt?

Akamai will peer with you anywhere and i doubt LLNW will give you trouble.

L3, well, they run a superb network and even more superb pricing, so why 
would they peer with anyone ;)

I still think, old fashioned me, that a CDN doesnt do go without peering 
but some feel otherwise.

Bye,
Raymond.


From simon at slimey.org  Mon Dec 12 15:22:38 2011
From: simon at slimey.org (Simon Lockhart)
Date: Mon, 12 Dec 2011 21:22:38 +0000
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <alpine.LFD.2.00.1112122210100.12219@noc.prolocation.net>
References: <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
 <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net>
 <20111212205659.GA20184@virtual.bogons.net>
 <alpine.LFD.2.00.1112122210100.12219@noc.prolocation.net>
Message-ID: <20111212212238.GB20184@virtual.bogons.net>

On Mon Dec 12, 2011 at 10:11:54PM +0100, Raymond Dijkxhoorn wrote:
> Akamai will peer with you anywhere and i doubt LLNW will give you trouble.

LLNW are restictive on peering.
 
> L3, well, they run a superb network and even more superb pricing, so why 
> would they peer with anyone ;)

And as I use L3 for transit, they'd never peer with me. Not that they peer
with anyone outside the cabal anyway.
 
> I still think, old fashioned me, that a CDN doesnt do go without peering 
> but some feel otherwise.

Quite so. I don't get why CDNs don't all peer openly. I guess most (i.e. those
which aren't Akamai) are more concerned with making money than with delivering
a good service to the end user.

Simon


From jason at lixfeld.ca  Mon Dec 12 16:00:38 2011
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Mon, 12 Dec 2011 17:00:38 -0500
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <20111212212238.GB20184@virtual.bogons.net>
References: <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
 <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net>
 <20111212205659.GA20184@virtual.bogons.net>
 <alpine.LFD.2.00.1112122210100.12219@noc.prolocation.net>
 <20111212212238.GB20184@virtual.bogons.net>
Message-ID: <77F26F9D-F271-4C37-B017-3EC4C7AF8117@lixfeld.ca>


On 2011-12-12, at 4:22 PM, Simon Lockhart <simon at slimey.org> wrote:

> I guess most (i.e. those
> which aren't Akamai) are more concerned with making money than with delivering
> a good service to the end user.

Really?  I always thought that higher profits and buying transit were mutually exclusive relative to higher profits and openly peering.

So what you are saying is that one stands to make more by paying upstreams for bit swapping?  How's that work?

If the argument is that the opex required for maintaining peering relationships is too expensive relative to the direct and indirect cost of buying bandwidth, I love to be edumacated on how that math actually works because it makes absolutely no sense to me.

--

Sent from my mobile device

From patrick at ianai.net  Mon Dec 12 16:21:45 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 12 Dec 2011 17:21:45 -0500
Subject: Peering vs. Transit vs. Profit [was: Overall Netflix bandwidth usage
 numbers on a network?]
In-Reply-To: <77F26F9D-F271-4C37-B017-3EC4C7AF8117@lixfeld.ca>
References: <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
 <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net>
 <20111212205659.GA20184@virtual.bogons.net>
 <alpine.LFD.2.00.1112122210100.12219@noc.prolocation.net>
 <20111212212238.GB20184@virtual.bogons.net>
 <77F26F9D-F271-4C37-B017-3EC4C7AF8117@lixfeld.ca>
Message-ID: <3802FD53-27CF-417D-8AC0-EF1F25AE414D@ianai.net>

On Dec 12, 2011, at 5:00 PM, Jason Lixfeld wrote:
> On 2011-12-12, at 4:22 PM, Simon Lockhart <simon at slimey.org> wrote:
> 
>> I guess most (i.e. those
>> which aren't Akamai) are more concerned with making money than with delivering
>> a good service to the end user.
> 
> Really?  I always thought that higher profits and buying transit were mutually exclusive relative to higher profits and openly peering.
> 
> So what you are saying is that one stands to make more by paying upstreams for bit swapping?  How's that work?

You are assuming that peering with $ISP will lower someone's transit bill.  That is demonstrably false in the case of Level 3 who (to a first approximation - please do not argue corner cases) pays no one for transit.

It is also likely false over some set of $ISP_n for some peers.  As a trivial example, if $NETWORK peers with your transit, not only would it not save them money to peer with you, it may cost them money if peering with you endangers the peering with your upstream.  This can happen if $NETWORK does not have enough traffic to qualify for peering with your upstream when your traffic is removed from the link.

So peering does not always equal profit.  Would that life were so simple! =)


> If the argument is that the opex required for maintaining peering relationships is too expensive relative to the direct and indirect cost of buying bandwidth, I love to be edumacated on how that math actually works because it makes absolutely no sense to me.

Peering is not free.  I can easily see the cost of bringing up a port to someone with 10 Mbps costing more than it saves for some perfectly valid network topologies.  And that's just the most obvious example.  The one above is another obvious example.

There are reasons not to peer.  Assuming there are not is a bad way to enter a negotiation.  Put yourself in the place of the other network, figure out what their pain points are - performance, complexity, stability, cost, slot density, spare cycles (human and machine), etc., etc.  To be successful in a negotiation, I submit it is useful to help them eliminate one or more of those pain points, i.e. make it worth their while.

Remember, my company's peering policy (at public exchanges) is "YES".  Since I wrote the policy, you can probably guess my view on peering.  But if simply I assumed no one ever had a reason to say "no", I wouldn't get very far.

There are two sides to every story.  Sometimes the other side is confused, or even flat out wrong, but not always.  And even when the other side is wrong, it may not be useful to bash them over the head with the truth.

-- 
TTFN,
patrick

P.S. I also think "giving good service" is one vital component of "making more money".  But maybe I'm silly.



From mpetach at netflight.com  Mon Dec 12 19:43:48 2011
From: mpetach at netflight.com (Matthew Petach)
Date: Mon, 12 Dec 2011 17:43:48 -0800
Subject: Overall Netflix bandwidth usage numbers on a network?
In-Reply-To: <77F26F9D-F271-4C37-B017-3EC4C7AF8117@lixfeld.ca>
References: <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in>
 <4EE56198.40307@snappydsl.net>
 <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com>
 <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net>
 <CAL9jLaZpDjH4QTM3Fjx=6gz6s6_z-JArGzJGBa5nEOWtSRErXw@mail.gmail.com>
 <4EE58E8E.8000804@bogus.com>
 <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net>
 <20111212205659.GA20184@virtual.bogons.net>
 <alpine.LFD.2.00.1112122210100.12219@noc.prolocation.net>
 <20111212212238.GB20184@virtual.bogons.net>
 <77F26F9D-F271-4C37-B017-3EC4C7AF8117@lixfeld.ca>
Message-ID: <CAEmG1=phHx+EPG6rZyVSy7q9YywvLe9Yn96t_4pfEfhjCG2w9Q@mail.gmail.com>

On Mon, Dec 12, 2011 at 2:00 PM, Jason Lixfeld <jason at lixfeld.ca> wrote:
>
> On 2011-12-12, at 4:22 PM, Simon Lockhart <simon at slimey.org> wrote:
>
>> I guess most (i.e. those
>> which aren't Akamai) are more concerned with making money than with delivering
>> a good service to the end user.
>
> Really? ?I always thought that higher profits and buying transit were mutually exclusive relative to higher profits and openly peering.
>
> So what you are saying is that one stands to make more by paying upstreams for bit swapping? ?How's that work?
>
> If the argument is that the opex required for maintaining peering relationships is too expensive relative to the direct and indirect cost of buying bandwidth, I love to be edumacated on how that math actually works because it makes absolutely no sense to me.

I'm somewhat assuming you're trolling here.  :/

but just in case...

the lost revenue from peering with someone when you could be
charging them transit prices is the tradeoff being referred to
here; Level3 isn't in the business of paying upstreams for
bandwidth.  (well, other than comcast, but that's a different
thread entirely.  And yes, I suppose that would be me trolling.
Bad Matt!)

Matt


From mailinglists at expresswebsystems.com  Mon Dec 12 21:18:35 2011
From: mailinglists at expresswebsystems.com (Express Web Systems)
Date: Mon, 12 Dec 2011 21:18:35 -0600
Subject: recommendations for external montioring services?
In-Reply-To: <20111212204701.GN19342@nm.lacutt>
References: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
 <20111212204701.GN19342@nm.lacutt>
Message-ID: <016b01ccb945$e74236a0$b5c6a3e0$@com>

> 
> You may want to check out http://www.panopta.com/ Works well for me
> with reasonable pricing.
> 

+1 to Panopta. We have been using them for the past two years and they have
been very solid. We have even put in a few feature requests (voice
notifications was one we specifically requested) and they have had them
implemented and pushed out for beta testing in a couple of weeks.

I would highly recommend them.



From scott at sberkman.net  Mon Dec 12 22:06:22 2011
From: scott at sberkman.net (Scott Berkman)
Date: Mon, 12 Dec 2011 23:06:22 -0500
Subject: recommendations for external montioring services?
In-Reply-To: <016b01ccb945$e74236a0$b5c6a3e0$@com>
References: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
 <20111212204701.GN19342@nm.lacutt> <016b01ccb945$e74236a0$b5c6a3e0$@com>
Message-ID: <053901ccb94c$93ef5350$bbcdf9f0$@sberkman.net>

Two I know and have used are Alertra and SiteRecon.

-----Original Message-----
From: Express Web Systems [mailto:mailinglists at expresswebsystems.com] 
Sent: Monday, December 12, 2011 10:19 PM
To: 'Derrick H.'; nanog at nanog.org
Subject: RE: recommendations for external montioring services?

> 
> You may want to check out http://www.panopta.com/ Works well for me 
> with reasonable pricing.
> 

+1 to Panopta. We have been using them for the past two years and they 
+have
been very solid. We have even put in a few feature requests (voice
notifications was one we specifically requested) and they have had them
implemented and pushed out for beta testing in a couple of weeks.

I would highly recommend them.





From joelja at bogus.com  Mon Dec 12 23:51:14 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Mon, 12 Dec 2011 21:51:14 -0800
Subject: Sad IPv4 story?
In-Reply-To: <D181DDABABE57E4DB72FEE003314786445941F@EALPO1.ukbroadband.com>
References: <CB07955B.497B3%fmartin@linkedin.com> <m21usceu3t.wl%randy@psg.com>
 <AC286C37-3A8C-48CD-A446-17E8A53C5497@sungard.com>
 <20196.3069.632519.601259@world.std.com>
 <15282.1323576426@turing-police.cc.vt.edu>
 <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com>
 <D51498F0B6E1EF408AC4D63440BFD6F8C3847EA07A@skbramsx02.emea.att.com>
 <D181DDABABE57E4DB72FEE003314786445941F@EALPO1.ukbroadband.com>
Message-ID: <4EE6E7D2.8060306@bogus.com>

On 12/12/11 02:05 , Leigh Porter wrote:
>> -----Original Message----- From: Vitkovsky, Adam
>> [mailto:avitkovsky at emea.att.com] Sent: 12 December 2011 09:19 To:
>> Eric Parsonage; Valdis.Kletnieks at vt.edu Cc: nanog at nanog.org 
>> Subject: RE: Sad IPv4 story?
>> 
>>> and models that doesn't take "we may not get IPv4 space" into
>>> account
>> and have
>>> a contingency plan for that *deserves* to be soundly mocked and
>> ridiculed in
>>> public.
>> 
>> That's right
>> 
>> However the original post was concerning a fresh new ISP that can't
>> run their business the way they would like Maybe they'd like to
>> build an mpls core which right now is not possible with only ipv6
>> at hand I'd like to see the business model to build an mpls network
>> with all the features we're used to -but solely on ipv6 -I guess
>> the plan would be let's wait a couple years till it gets
>> implemented and mature enough
> 
> Well really this is pretty much our fault. IPv6 has been on peoples
> 'back burner' for far too long. Additional vendor pressure and
> pressure at the IETF would have pushed things forward far faster had
> people actually been interested in doing so.
> 
> As per an earlier post, I am shocked at how I still have vendors
> coming to me with equipment that is nowhere near ready for commercial
> IPv6 deployment, it either just does not work, is half baked or is
> "on the roadmap".
> 
> So now we will reap the consequences and it will be at the cost of
> new market entrants (which I am sure will please some people) and
> perhaps cold hard cash for those who cannot expand their business or
> have to 'buy' address space.

New market entrants are the customers of existing operators, so their
plight and the feasibility of being a new market entrant  impacts our
bottom lines.

> I know a lot of people have been working hard to move IPv6 along both
> here, at NANOG and other events and with their vendors. It's because
> of those people, like Randy perhaps that we actually have what we do
> now else most people would still be stuck with their heads in the
> sand.
> 
> Well, I am sure it'll all be OK in the end...
> 
> -- Leigh
> 
> 
> 
> ______________________________________________________________________
>
> 
This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com 
> ______________________________________________________________________
>
> 
> 



From mir at ripe.net  Tue Dec 13 02:10:18 2011
From: mir at ripe.net (Mirjam Kuehne)
Date: Tue, 13 Dec 2011 09:10:18 +0100
Subject: 128.0.0.0/16 as seen from RIPE Atlas
Message-ID: <4EE7086A.8050309@ripe.net>

Dear colleagues,

As a follow-up to the recent article "The Curious Case of 128.0/16", we 
now looked at 128.0/16 as seen from RIPE Atlas:

https://labs.ripe.net/Members/dfk/128.0-16-seen-by-atlas

Kind regards,
Mirjam Kuehne
RIPE NCC


From jared at puck.nether.net  Tue Dec 13 03:54:07 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 13 Dec 2011 04:54:07 -0500
Subject: Sad IPv4 story?
In-Reply-To: <F1612CA4-8B27-4509-BD4F-568F553744C6@corp.arin.net>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <F1612CA4-8B27-4509-BD4F-568F553744C6@corp.arin.net>
Message-ID: <4D3C4400-1327-41F4-B4C9-DBCBCBB60D3F@puck.nether.net>


On Dec 11, 2011, at 6:52 AM, John Curran wrote:

>  The sooner we get the content on IPv6 in addition to IPv4, the sooner 
>  that connecting new customers up via IPv6 without additional unique 
>  IPv4 address space becomes viable (and obviously if we had the vast
>  majority of content already on IPv6, then connecting new customers 
>  via IPv6 would be simple indeed.)

Google and other content providers will whitelist you if you coordinate
with them.  Some may not like the social-political implications of this
as it will create what some see as IPv6 islands that are overlays on the
global IPv6 network.

This is nothing new, there have always been private and policy based 
decisions that lead to reachability.

We have seen great success (IMHO) in IPv6 day.  We need to see this happen
again with a broader number of networks having IPv6 connectivity.  I look
forward to seeing the continued broadband deployment of IPv6 to make the
data far more interesting.  I'm glad to see the major carriers doing IPv6
work in this space.  It appears that the traditional/incumbent telcos in
the US are behind the curve, but I'm not entirely convinced their business
model is relevant in the future decades.

	- Jared


From michiel at klaver.it  Tue Dec 13 04:11:44 2011
From: michiel at klaver.it (Michiel Klaver)
Date: Tue, 13 Dec 2011 11:11:44 +0100
Subject: recommendations for external montioring services?
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
Message-ID: <4EE724E0.3060008@klaver.it>

At 22-07-2011 20:59, Eric J Esslinger wrote:
> I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings')
> I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems  but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail).
> 

Some external monitoring services I could recommend:

https://circonus.com/
http://mon.itor.us/
http://pingdom.com/


From dmiller at tiggee.com  Tue Dec 13 08:40:12 2011
From: dmiller at tiggee.com (David Miller)
Date: Tue, 13 Dec 2011 09:40:12 -0500
Subject: recommendations for external montioring services?
In-Reply-To: <4EE724E0.3060008@klaver.it>
References: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
 <4EE724E0.3060008@klaver.it>
Message-ID: <4EE763CC.3050805@tiggee.com>

On 12/13/2011 5:11 AM, Michiel Klaver wrote:
> At 22-07-2011 20:59, Eric J Esslinger wrote:
>> I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings')
>> I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems  but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail).
>>
> Some external monitoring services I could recommend:
>
> https://circonus.com/
> http://mon.itor.us/
> http://pingdom.com/
>

I'll throw another into the list:

http://www.watchmouse.com/

They have some nice features and monitoring over IPv4 and IPv6.

-DMM


From graham at g-rock.net  Tue Dec 13 10:49:55 2011
From: graham at g-rock.net (=?utf-8?B?Z3JhaGFtQGctcm9jay5uZXQ=?=)
Date: Tue, 13 Dec 2011 10:49:55 -0600
Subject: =?utf-8?B?Q29sb3MgaW4gTWVsYm91cm5lLCBGTC4g?=
Message-ID: <mailman.70.1323794989.1870.nanog@nanog.org>

For those with Colo space in Melbourne FL. Please reply to me offlist; looking to deploy a POP there. 
Thanks.  

Sent from my HTC on the Now Network from Sprint!

From robert at timetraveller.org  Tue Dec 13 19:10:05 2011
From: robert at timetraveller.org (Robert Brockway)
Date: Wed, 14 Dec 2011 11:10:05 +1000 (EST)
Subject: recommendations for external montioring services?
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
Message-ID: <alpine.DEB.2.00.1112141046010.8973@castor.opentrend.net>

On Mon, 12 Dec 2011, Eric J Esslinger wrote:

> I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail 
> servers (pop,imap,submission port, https webmail), 4 dns servers 
> (including lookups to ensure they're not listening but not talking), and 
> one inbound mx. A few network points to ping to ensure connectivity 
> throughout my system. Scheduled notification windows (for example, 
> during work hours I don't want my phone pinged unless it's everything 
> going offline. Off hours I do. Secondary notifications if problem 
> persists to other users, or in the event of many triggers. That sort of 
> thing). Sensitivity settings (If web server 1 shows down for 5 min, 
> that's not a big deal. Another one if it doesn't respond to repeated 
> queries within 1 minute is a big deal) A Weekly summary of issues would 
> be nice. (especially the 'well it was down for a short bit but we didn't 
> notify as per settings') I don't have a lot of money to throw at this. I

Hi Eric.  The feature set you are describing should be in any monitoring 
system worthy of the name.  I've used Nagios to good effect for the best 
part of the last 12 years or so.  Before that I used Big Brother, which 
sucked in various ways.

I did an evaluation on a wide variety of FOSS monitoring systems 2-3 years 
ago and Nagios won at the time (again).  Generally I found the 
alternatives had problems that I considered to be quite serious (such as 
being overly complicated or doing checks so frequently that they loaded 
the systems they were supposed to be monitoring[1]).

I'm currently trialing Icinga, a fork of Nagios.

Puppet can be set up to manage Nagios/Icinga config which cuts down on the 
admin overhead.

Nagios/Icinga can be hooked up to Collectd to provide performance data as 
well as alert monitoring.

One concern about external monitoring services is the level of visibility 
they need to have in to your network to adequately monitor them.

My recommendation is to do a proper risk assessment on the available 
options.

> DO have detailed internal monitoring of our systems but sometimes that 
> is not entirely useful, due to the fact that there are a few 'single 
> points of failure' within our network/notification system, not to 
> mention if the monitor itself goes offline it's not exactly going to be 
> able to tell me about it. (and that happened once, right before the mail 
> server decided to stop receiving mail).

There are a couple of ways to deal with this.  Some monitoring 
applications can fail-over to a standby server if the primary fails.  But 
this isn't even really necessary.  You will arguably gain higher 
reliability by running multiple _independent_ monitors and have them 
monitor each other[2].  I have often used this approach.

The principal aim here is to guarantee that you are alerted to any single 
failure (a production service, system or a monitor).  Multiple 
simultaneous failures could still produce a blackspot.  It is possible to 
design a system that will discover multiple simultaneous failures, but it 
takes more effort and resources.


[1] Sometimes I wonder if the people developing certain systems have any 
operational experience at all.

[2] A system designed to fail-over on certain conditions may fail to 
fail-over, ah, so to speak.

Cheers,

Rob

-- 
Email: robert at timetraveller.org		Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.practicalsysadmin.com
Director, Software in the Public Interest (http://spi-inc.org/)
Free & Open Source: The revolution that quietly changed the world
"One ought not to believe anything, save that which can be proven by nature and the force of reason" -- Frederick II (26 December 1194 ? 13 December 1250)

From MGauvin at dryden.ca  Tue Dec 13 19:43:35 2011
From: MGauvin at dryden.ca (Mark Gauvin)
Date: Tue, 13 Dec 2011 19:43:35 -0600
Subject: recommendations for external montioring services?
In-Reply-To: <alpine.DEB.2.00.1112141046010.8973@castor.opentrend.net>
References: <D2D37F15EBBD524693E9F3CB32D02080430C799D0E@exchange.corp.fpu-tn.com>
 <alpine.DEB.2.00.1112141046010.8973@castor.opentrend.net>
Message-ID: <85720F8A-86B8-4926-92D9-EBE2BD4006F4@dryden.ca>

Solar winds as you send in the specific mib required to monitor and a  
week later it's general release


Sent from my iPhone

On 2011-12-13, at 7:11 PM, "Robert Brockway"  
<robert at timetraveller.org> wrote:

> On Mon, 12 Dec 2011, Eric J Esslinger wrote:
>
>> I'm not looking to monitor a massive infrastructure: 3 web sites, 2  
>> mail
>> servers (pop,imap,submission port, https webmail), 4 dns servers
>> (including lookups to ensure they're not listening but not  
>> talking), and
>> one inbound mx. A few network points to ping to ensure connectivity
>> throughout my system. Scheduled notification windows (for example,
>> during work hours I don't want my phone pinged unless it's everything
>> going offline. Off hours I do. Secondary notifications if problem
>> persists to other users, or in the event of many triggers. That  
>> sort of
>> thing). Sensitivity settings (If web server 1 shows down for 5 min,
>> that's not a big deal. Another one if it doesn't respond to repeated
>> queries within 1 minute is a big deal) A Weekly summary of issues  
>> would
>> be nice. (especially the 'well it was down for a short bit but we  
>> didn't
>> notify as per settings') I don't have a lot of money to throw at  
>> this. I
>
> Hi Eric.  The feature set you are describing should be in any  
> monitoring
> system worthy of the name.  I've used Nagios to good effect for the  
> best
> part of the last 12 years or so.  Before that I used Big Brother,  
> which
> sucked in various ways.
>
> I did an evaluation on a wide variety of FOSS monitoring systems 2-3  
> years
> ago and Nagios won at the time (again).  Generally I found the
> alternatives had problems that I considered to be quite serious  
> (such as
> being overly complicated or doing checks so frequently that they  
> loaded
> the systems they were supposed to be monitoring[1]).
>
> I'm currently trialing Icinga, a fork of Nagios.
>
> Puppet can be set up to manage Nagios/Icinga config which cuts down  
> on the
> admin overhead.
>
> Nagios/Icinga can be hooked up to Collectd to provide performance  
> data as
> well as alert monitoring.
>
> One concern about external monitoring services is the level of  
> visibility
> they need to have in to your network to adequately monitor them.
>
> My recommendation is to do a proper risk assessment on the available
> options.
>
>> DO have detailed internal monitoring of our systems but sometimes  
>> that
>> is not entirely useful, due to the fact that there are a few 'single
>> points of failure' within our network/notification system, not to
>> mention if the monitor itself goes offline it's not exactly going  
>> to be
>> able to tell me about it. (and that happened once, right before the  
>> mail
>> server decided to stop receiving mail).
>
> There are a couple of ways to deal with this.  Some monitoring
> applications can fail-over to a standby server if the primary  
> fails.  But
> this isn't even really necessary.  You will arguably gain higher
> reliability by running multiple _independent_ monitors and have them
> monitor each other[2].  I have often used this approach.
>
> The principal aim here is to guarantee that you are alerted to any  
> single
> failure (a production service, system or a monitor).  Multiple
> simultaneous failures could still produce a blackspot.  It is  
> possible to
> design a system that will discover multiple simultaneous failures,  
> but it
> takes more effort and resources.
>
>
> [1] Sometimes I wonder if the people developing certain systems have  
> any
> operational experience at all.
>
> [2] A system designed to fail-over on certain conditions may fail to
> fail-over, ah, so to speak.
>
> Cheers,
>
> Rob
>
> -- 
> Email: robert at timetraveller.org        Linux counter ID #16440
> IRC: Solver (OFTC & Freenode)
> Web: http://www.practicalsysadmin.com
> Director, Software in the Public Interest (http://spi-inc.org/)
> Free & Open Source: The revolution that quietly changed the world
> "One ought not to believe anything, save that which can be proven by  
> nature and the force of reason" -- Frederick II (26 December 1194 ?  
> 13 December 1250)

From pde at eff.org  Tue Dec 13 20:12:34 2011
From: pde at eff.org (Peter Eckersley)
Date: Tue, 13 Dec 2011 18:12:34 -0800
Subject: EFF call for signatures from Internet engineers against censorship
Message-ID: <20111214021234.GA4101@xylophonic>

(Apologies for an slightly-OT posting)

Last year, EFF organized an open letter from network engineers against
Internet censorship legislation being considered by the US Senate
(https://eff.org/deeplinks/2010/09/open-letter).  Along with other activists'
efforts, we successfully delayed that proposal, but the letter needs to be
updated for two bills, SOPA and PIPA, that are close to passing through US
Congress now.

If you would like to sign, please email me at pde at eff.org, with a one-line
summary of what part of the Internet you helped to helped to design,
implement, debug or run.

We need signatures by 8am GMT on Thursday (midnight Wednesday US Pacific, 3am
US Eastern).  Also feel free to forward this to colleagues who played a role
in designing and building the network. 

The updated letter's text is below:

  We, the undersigned, have played various parts in building a network called
  the Internet. We wrote and debugged the software; we defined the standards
  and protocols that talk over that network. Many of us invented parts of it.
  We're just a little proud of the social and economic benefits that our
  project, the Internet, has brought with it.

  Last year, many of us wrote to you and your colleagues to warn about the
  proposed "COICA" copyright and censorship legislation.  Today, we are
  writing again to reiterate our concerns about the SOPA and PIPA derivatives
  of last year's bill, that are under consideration in the House and Senate.
  In many respects, these proposals are worse than the one we were alarmed to
  read last year.

  If enacted, either of these bills will create an environment of tremendous
  fear and uncertainty for technological innovation, and seriously harm the
  credibility of the United States in its role as a steward of key Internet
  infrastructure. Regardless of recent amendments to SOPA, both bills will
  risk fragmenting the Internet's global domain name system (DNS) and have
  other capricious technical consequences.  In exchange for this, such
  legislation would engender censorship that will simultaneously be
  circumvented by deliberate infringers while hampering innocent parties'
  right and ability to communicate and express themselves online.

  All censorship schemes impact speech beyond the category they were intended
  to restrict, but these bills are particularly egregious in that regard
  because they cause entire domains to vanish from the Web, not just
  infringing pages or files.  Worse, an incredible range of useful,
  law-abiding sites can be blacklisted under these proposals.  In fact, it
  seems that this has already begun to happen under the nascent DHS/ICE
  seizures program.  
  
  Censorship of Internet infrastructure will inevitably cause network errors
  and security problems.  This is true in China, Iran and other countries that
  censor the network today; it will be just as true of American censorship.
  It is also true regardless of whether censorship is implemented via the DNS,
  proxies, firewalls, or any other method.  Types of network errors and
  insecurity that we wrestle with today will become more widespread, and will
  affect sites other than those blacklisted by the American government.

  The current bills -- SOPA explicitly and PIPA implicitly -- also threaten
  engineers who build Internet systems or offer services that are not readily
  and automatically compliant with censorship actions by the U.S. government.
  When we designed the Internet the first time, our priorities were
  reliability, robustness and minimizing central points of failure or control.
  We are alarmed that Congress is so close to mandating censorship-compliance
  as a design requirement for new Internet innovations.  This can only damage
  the security of the network, and give authoritarian governments more power
  over what their citizens can read and publish.

  The US government has regularly claimed that it supports a free and open
  Internet, both domestically and abroad.  We cannot have a free and open
  Internet unless its naming and routing systems sit above the political
  concerns and objectives of any one government or industry. To date, the
  leading role the US has played in this infrastructure has been fairly
  uncontroversial because America is seen as a trustworthy arbiter and a
  neutral bastion of free expression. If the US begins to use its
  central in the network for censorship that advances its political and
  economic agenda, the consequences will be far-reaching and destructive.

  Senators, Congressmen, we believe the Internet is too important and too
  valuable to be endangered in this way, and implore you to put these bills
  aside.

-- 
Peter Eckersley                            pde at eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993


From ipv4brokers at gmail.com  Tue Dec 13 21:13:34 2011
From: ipv4brokers at gmail.com (IPv4 Brokers)
Date: Tue, 13 Dec 2011 22:13:34 -0500
Subject: Your Christmas Bonus Has Arrived
Message-ID: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>

Do you have subnets that are  not in use, or only used for specific
purposes?  If so, please contact us.

We are paying up-front (or escrow) for the use of networks that are not
used.  The networks are used for honeypots and other research.

You do not have to modify your BGP announcements, establish a GRE tunnel to
our network and forward packets over the tunnel.

The networks may be used for a month or longer, you are paid an agreed upon
price per each month of use.

Your confidentiality is absolutely guaranteed.  Only you will know that
you're making money on your un-used or single/special-use networks.

We do require a minimum of /24.

From matt at mt.au.com  Tue Dec 13 21:16:09 2011
From: matt at mt.au.com (Matt Taylor)
Date: Wed, 14 Dec 2011 14:16:09 +1100
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
Message-ID: <4EE814F9.8000409@mt.au.com>

On 14/12/2011 2:13 PM, IPv4 Brokers wrote:
> Do you have subnets that are  not in use, or only used for specific
> purposes?  If so, please contact us.
>
> We are paying up-front (or escrow) for the use of networks that are not
> used.  The networks are used for honeypots and other research.
>
> You do not have to modify your BGP announcements, establish a GRE tunnel to
> our network and forward packets over the tunnel.
>
> The networks may be used for a month or longer, you are paid an agreed upon
> price per each month of use.
>
> Your confidentiality is absolutely guaranteed.  Only you will know that
> you're making money on your un-used or single/special-use networks.
>
> We do require a minimum of /24.

... Heh

ipv4brokers at gmail.com

-.-

Matt.


From keegan.holley at sungard.com  Tue Dec 13 22:00:12 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Tue, 13 Dec 2011 23:00:12 -0500
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
Message-ID: <CABO8Q6ScRQ2FtQWGwRH6FMxMPvrkKwnXQhbvxFD9o7O5Y50D2A@mail.gmail.com>

Do the blocks have to come from a company I still work for?  If not I have
a boat load..


2011/12/13 IPv4 Brokers <ipv4brokers at gmail.com>

> Do you have subnets that are  not in use, or only used for specific
> purposes?  If so, please contact us.
>
> We are paying up-front (or escrow) for the use of networks that are not
> used.  The networks are used for honeypots and other research.
>
> You do not have to modify your BGP announcements, establish a GRE tunnel to
> our network and forward packets over the tunnel.
>
> The networks may be used for a month or longer, you are paid an agreed upon
> price per each month of use.
>
> Your confidentiality is absolutely guaranteed.  Only you will know that
> you're making money on your un-used or single/special-use networks.
>
> We do require a minimum of /24.
>
>

From keegan.holley at sungard.com  Tue Dec 13 22:03:16 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Tue, 13 Dec 2011 23:03:16 -0500
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: <4EE814F9.8000409@mt.au.com>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <4EE814F9.8000409@mt.au.com>
Message-ID: <CABO8Q6S2-8wLoP=iq1beGexUGjBXRGR3rRbjmjy8jMmP=2f4mw@mail.gmail.com>

... Heh

>
> ipv4brokers at gmail.com
>
> -.-
>
> If domain squatting and patent trolling are both legitimate sometimes
multi-million dollar businesses are you really surprised?

From streiner at cluebyfour.org  Tue Dec 13 22:56:19 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 13 Dec 2011 23:56:19 -0500 (EST)
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: <4EE814F9.8000409@mt.au.com>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <4EE814F9.8000409@mt.au.com>
Message-ID: <Pine.LNX.4.64.1112132354070.26211@whammy.cluebyfour.org>

On Wed, 14 Dec 2011, Matt Taylor wrote:

> On 14/12/2011 2:13 PM, IPv4 Brokers wrote:
>>  We are paying up-front (or escrow) for the use of networks that are not
>>  used.  The networks are used for honeypots and other research.
>>
>>  The networks may be used for a month or longer, you are paid an agreed
>>  upon price per each month of use.
>>
>>  We do require a minimum of /24.

Sounds like another middleman for 'bulletproof' hosting services for 
people who generally are up to no good.

As far as I'm concerned, they can have as much of 10/8 as they want.  My 
rate per /24 is very reasonable.

jms


From patrick at ianai.net  Tue Dec 13 23:40:16 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Wed, 14 Dec 2011 00:40:16 -0500
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: <Pine.LNX.4.64.1112132354070.26211@whammy.cluebyfour.org>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <4EE814F9.8000409@mt.au.com>
 <Pine.LNX.4.64.1112132354070.26211@whammy.cluebyfour.org>
Message-ID: <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net>

On Dec 13, 2011, at 11:56 PM, Justin M. Streiner wrote:
> On Wed, 14 Dec 2011, Matt Taylor wrote:
>> On 14/12/2011 2:13 PM, IPv4 Brokers wrote:
>>> We are paying up-front (or escrow) for the use of networks that are not
>>> used.  The networks are used for honeypots and other research.
>>> 
>>> The networks may be used for a month or longer, you are paid an agreed
>>> upon price per each month of use.
>>> 
>>> We do require a minimum of /24.
> 
> Sounds like another middleman for 'bulletproof' hosting services for people who generally are up to no good.

I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context).

Also, they may be using a GMail account because it is likely they crossed some line with people (perhaps even the NANOG mail admins) and need a disposable account.

Or maybe they really are running their business off *@gmail.com....

-- 
TTFN,
patrick



From Valdis.Kletnieks at vt.edu  Wed Dec 14 00:04:29 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 14 Dec 2011 01:04:29 -0500
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: Your message of "Tue, 13 Dec 2011 23:56:19 EST."
 <Pine.LNX.4.64.1112132354070.26211@whammy.cluebyfour.org>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <4EE814F9.8000409@mt.au.com>
 <Pine.LNX.4.64.1112132354070.26211@whammy.cluebyfour.org>
Message-ID: <8258.1323842669@turing-police.cc.vt.edu>

On Tue, 13 Dec 2011 23:56:19 EST, "Justin M. Streiner" said:

> As far as I'm concerned, they can have as much of 10/8 as they want.  My
> rate per /24 is very reasonable.

Oh, I don't think they'll fall for that, everbody knows 10/8 and 192.168/16 are
private networks.  However, I bet I can underbid Justin with some of the /24's
off the end of 172.16/12 - my HPC people aren't using anywhere near the
whole allocation and will never notice a bunch of /24's off the end. ;)
-------------- 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/20111214/cfe900e9/attachment.bin>

From chaim.rieger at gmail.com  Wed Dec 14 00:07:44 2011
From: chaim.rieger at gmail.com (Chaim Rieger)
Date: Tue, 13 Dec 2011 22:07:44 -0800
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
Message-ID: <1689b1b1-9c0c-4d7d-b1d4-4c533bfe5144@email.android.com>

What do you have for those that don't do the whole Jesus thing ?


From babak at farrokhi.net  Wed Dec 14 00:31:46 2011
From: babak at farrokhi.net (Babak Farrokhi)
Date: Wed, 14 Dec 2011 10:01:46 +0330
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <4EE814F9.8000409@mt.au.com>
 <Pine.LNX.4.64.1112132354070.26211@whammy.cluebyfour.org>
 <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net>
Message-ID: <D2E02E00-112F-4C80-B4A3-C8B9A0C6F25D@farrokhi.net>

Is there a comapny behind that gmail mailbox? And they could make a deal with MS & Borders using the same mailbox?

-- 
Babak Farrokhi

On Dec 14, 2011, at 9:10 AM, "Patrick W. Gilmore" <patrick at ianai.net> wrote:

> On Dec 13, 2011, at 11:56 PM, Justin M. Streiner wrote:
>> On Wed, 14 Dec 2011, Matt Taylor wrote:
>>> On 14/12/2011 2:13 PM, IPv4 Brokers wrote:
>>>> We are paying up-front (or escrow) for the use of networks that are not
>>>> used.  The networks are used for honeypots and other research.
>>>> 
>>>> The networks may be used for a month or longer, you are paid an agreed
>>>> upon price per each month of use.
>>>> 
>>>> We do require a minimum of /24.
>> 
>> Sounds like another middleman for 'bulletproof' hosting services for people who generally are up to no good.
> 
> I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context).
> 
> Also, they may be using a GMail account because it is likely they crossed some line with people (perhaps even the NANOG mail admins) and need a disposable account.
> 
> Or maybe they really are running their business off *@gmail.com....
> 
> -- 
> TTFN,
> patrick
> 
> 


From don at bowenvale.co.nz  Wed Dec 14 00:36:49 2011
From: don at bowenvale.co.nz (Don Gould)
Date: Wed, 14 Dec 2011 19:36:49 +1300
Subject: Sad IPv4 story?
In-Reply-To: <CB07955B.497B3%fmartin@linkedin.com>
References: <CB07955B.497B3%fmartin@linkedin.com>
Message-ID: <4EE84401.1030502@bowenvale.co.nz>

I really didn't follow to much of this thread, it's all a bit weird with 
some obvious industry under currents running that I don't follow.

What I will say is that I'm currently involved with exactly this issue 
and would have to say that it's all just getting sillier by the day.

I've been researching solutions with NAT and double NAT in mind because 
it's obvious that v4 space is going to become a growing problem.

It's interesting to see the things that break when you use double NAT.

What's also interesting is the growing competitive market place with 
incumbent providers, who have enough v4 space for their entire market, 
contracting their retail operations while their retail competitors are 
growing in size.

I've been working on some very basic projections for my country and 
expect over the next decade we will see at least 30%, or more, movement 
in our market.

So where is this going to leave v4 allocations?  Will the incumbents 
protect their retail operations by locking up their v4 space so that 
smaller competitors can't grow?

Will we all move to v6 to make the problem go away?  (Not likely, the 
level of edge understanding of v6 isn't there, and you lot already had a 
rant about CPE this week, so I won't go there!)

Will we develop smarter v4 technology and just NAT on NAT... and on NAT?

The only thing that is really clear is the lack of clarity.

D

On 10/12/2011 7:37 a.m., Franck Martin wrote:
> I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like?
>
> This is just a data point.
>

-- 
Don Gould
31 Acheson Ave
Mairehau
Christchurch, New Zealand
Ph: + 64 3 348 7235
Mobile: + 64 21 114 0699



From leigh.porter at ukbroadband.com  Wed Dec 14 01:20:56 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 14 Dec 2011 07:20:56 +0000
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: <1689b1b1-9c0c-4d7d-b1d4-4c533bfe5144@email.android.com>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <1689b1b1-9c0c-4d7d-b1d4-4c533bfe5144@email.android.com>
Message-ID: <D181DDABABE57E4DB72FEE003314786445B9B1@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Chaim Rieger [mailto:chaim.rieger at gmail.com]
> Sent: 14 December 2011 06:10
> To: IPv4 Brokers; nanog at nanog.org
> Subject: Re: Your Christmas Bonus Has Arrived
> 
> What do you have for those that don't do the whole Jesus thing ?
> 


That would be Hell..

--
Leigh


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

From hmurray at megapathdsl.net  Wed Dec 14 01:21:19 2011
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 13 Dec 2011 23:21:19 -0800
Subject: EFF call for signatures from Internet engineers against 
 censorship
Message-ID: <20111214072119.81F79800037@ip-64-139-1-69.sjc.megapath.net>


> but the letter needs to be updated for two bills, SOPA and PIPA, that are
> close to passing through US Congress now.

Stanford law school CIS (Center for Internet and Society) had a panel on SOPA 
a week ago.
  What's Wrong with SOPA?
  http://cyberlaw.stanford.edu/node/6770
  That's got a link to the talk on youtube: 2 hours.

I thought it was very good.  (I'm may be biased.  I live in Silicon Valley, 
not Hollywood.)

The handout also has a link to a white paper on the DNS issues.
  htp://bit.ly/sZBJbd

  Security and Other Technical Concerns Raised by the
    DNS Filtering Requirements in the PROTECT IP Bill
  Authors:
    Steve Crocker, Shinkuro, Inc.
    David Dagon, Georgia Tech
    Dan Kaminsky, DKH
    Danny McPherson, Verisign, Inc.
    Paul Vixie, Internet Systems Consortium

My opinions (US centric):

  Everybody agrees that Hollywood has problems with getting ripped off.

  The bill should be dumped rather than patched until it is good enough.  (If 
you are a cynic, you would propose that the really terrible parts of the bill 
were put there so that the good guys would focus on getting them removed and 
ignore the parts that were only bad.)

  Technically, it won't work.  (Spammer's have lots of practice creating 
domains faster than people can black list them and/or hiding in legitimate 
domains.)  See URL above.

  Technically, the unintended consequences are nasty.  (at least the ones we 
can see)  Our legal quirks are already hurting US based cloud servers.
  http://www.politico.com/news/stories/1111/69366.html

  Internationally, it's shooting ourselves in the foot.  Hillary Clinton is 
on record as saying the Internet should be open.  If China did something like 
this we would make fun of them.  If we block their domains, they can block 
Google and such.  (They are undoubtedly better at it than we are.  Google 
gets a lot of its income from offshore.)

  There is no due-process.  The AG could take down Google.  There is already 
a good example of the government taking down a legitimate domain without 
being willing to provide any justification:
  Breaking News: Feds Falsely Censor Popular Blog For Over A Year, Deny All 
Due Process, Hide All Details...
  http://j.mp/s1aS6z
  http://www.techdirt.com/articles/20111208/08225217010/
  breaking-news-feds-falsely-censor-popular-blog-over-year-deny-all-due-
  process-hide-all-details.shtml

  This whole mess is a wonderful example of why many citizens are cynical 
about Congress.  It looks like the MPAA/RIAA can buy whatever they want.




-- 
These are my opinions, not necessarily my employer's.  I hate spam.





From bortzmeyer at nic.fr  Wed Dec 14 02:07:33 2011
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed, 14 Dec 2011 09:07:33 +0100
Subject: EFF call for signatures from Internet engineers against censorship
In-Reply-To: <20111214021234.GA4101@xylophonic>
References: <20111214021234.GA4101@xylophonic>
Message-ID: <20111214080733.GB32110@nic.fr>

On Tue, Dec 13, 2011 at 06:12:34PM -0800,
 Peter Eckersley <pde at eff.org> wrote 
 a message of 86 lines which said:

>   To date, the leading role the US has played in this infrastructure
>   has been fairly uncontroversial [sic and re-sic] because America
>   is seen as a trustworthy arbiter and a neutral bastion of free
>   expression.

I am just a lurker on Nanog since I do not operate a network in North
America and therefore I hesitated to sign the letter but this sentence
is too much: it means you cannot sign unless you endorse this
ridiculous propaganda. It's bad to use the fight for freedom of speech
in this way :-(



From mohacsi at niif.hu  Wed Dec 14 02:11:37 2011
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Wed, 14 Dec 2011 09:11:37 +0100 (CET)
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1112140909330.99152@mignon.ki.iif.hu>



On Tue, 13 Dec 2011, IPv4 Brokers wrote:

> Do you have subnets that are  not in use, or only used for specific
> purposes?  If so, please contact us.
>
> We are paying up-front (or escrow) for the use of networks that are not
> used.  The networks are used for honeypots and other research.
>
> You do not have to modify your BGP announcements, establish a GRE tunnel to
> our network and forward packets over the tunnel.
>
> The networks may be used for a month or longer, you are paid an agreed upon
> price per each month of use.
>
> Your confidentiality is absolutely guaranteed.  Only you will know that
> you're making money on your un-used or single/special-use networks.
>
> We do require a minimum of /24.


And you remain responsible for malicious activity of IPv4 Brokers .....

Regards,
 	Janos Mohacsi


From mtinka at globaltransit.net  Wed Dec 14 03:06:06 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 14 Dec 2011 17:06:06 +0800
Subject: Sad IPv4 story?
In-Reply-To: <4EE84401.1030502@bowenvale.co.nz>
References: <CB07955B.497B3%fmartin@linkedin.com>
 <4EE84401.1030502@bowenvale.co.nz>
Message-ID: <201112141706.09852.mtinka@globaltransit.net>

On Wednesday, December 14, 2011 02:36:49 PM Don Gould wrote:

> I've been researching solutions with NAT and double NAT
> in mind because it's obvious that v4 space is going to
> become a growing problem.

We've started playing with Stateful NAT64 on a couple of 
Cisco ASR1006's. 

In general, it works okay, save for issues with applications 
that have no IPv6 support, e.g., Skype, e.t.c. We hope to 
find more issues as more customers sign up to be guinea 
pigs.

> The only thing that is really clear is the lack of 
> clarity.

Indeed. We're doing what we can to be part of the solution, 
by picking technologies we think will be useful for us and 
going out and testing them at scale, with a goal to start 
rolling out v6 in droves as well provide usable operator 
feedback re: our deployment to vendors and other operators 
alike.

As much as we'd like to see how the market unravels re: v4, 
e.t.c., the fact remains that v6 is the inevitable solution. 
So best to get cracking now with real deployments.

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/20111214/5d4b6c88/attachment-0001.bin>

From ops.lists at gmail.com  Wed Dec 14 04:12:51 2011
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 14 Dec 2011 15:42:51 +0530
Subject: EFF call for signatures from Internet engineers against censorship
In-Reply-To: <20111214072119.81F79800037@ip-64-139-1-69.sjc.megapath.net>
References: <20111214072119.81F79800037@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAArzuouqU2SivNgcE-3ipe-AwSq7v7N1H4wWqOxzxsP8hxYCOA@mail.gmail.com>

I would strongly suggest that operators work with their legal
departments to endorse this paper by Crocker and others.

If other ISP organizations (such as say MAAWG) come out with
something, other operators could sign on to that as well.

The EFF petition has way too much propaganda and far less content than
would be entirely productive in a policy discussion.

--srs


On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
>
> ?Security and Other Technical Concerns Raised by the
> ? ?DNS Filtering Requirements in the PROTECT IP Bill
> ?Authors:
> ? ?Steve Crocker, Shinkuro, Inc.
> ? ?David Dagon, Georgia Tech
> ? ?Dan Kaminsky, DKH
> ? ?Danny McPherson, Verisign, Inc.
> ? ?Paul Vixie, Internet Systems Consortium



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From Michael_OReirdan at Cable.Comcast.com  Wed Dec 14 05:36:59 2011
From: Michael_OReirdan at Cable.Comcast.com (O'Reirdan, Michael)
Date: Wed, 14 Dec 2011 11:36:59 +0000
Subject: EFF call for signatures from Internet engineers against censorship
In-Reply-To: <CAArzuouqU2SivNgcE-3ipe-AwSq7v7N1H4wWqOxzxsP8hxYCOA@mail.gmail.com>
References: <20111214072119.81F79800037@ip-64-139-1-69.sjc.megapath.net>,
 <CAArzuouqU2SivNgcE-3ipe-AwSq7v7N1H4wWqOxzxsP8hxYCOA@mail.gmail.com>
Message-ID: <B13238AB0CB1514B9509DEEE5F98F2E00DE39363@PACDCEXMB13.cable.comcast.com>

MAAWG has written voicing its concerns on SOPA and PIPA. 

http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf

Mike
________________________________________
From: Suresh Ramasubramanian [ops.lists at gmail.com]
Sent: 14 December 2011 05:12
To: Hal Murray
Cc: nanog at nanog.org
Subject: Re: EFF call for signatures from Internet engineers against censorship

I would strongly suggest that operators work with their legal
departments to endorse this paper by Crocker and others.

If other ISP organizations (such as say MAAWG) come out with
something, other operators could sign on to that as well.

The EFF petition has way too much propaganda and far less content than
would be entirely productive in a policy discussion.

--srs


On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
>
>  Security and Other Technical Concerns Raised by the
>    DNS Filtering Requirements in the PROTECT IP Bill
>  Authors:
>    Steve Crocker, Shinkuro, Inc.
>    David Dagon, Georgia Tech
>    Dan Kaminsky, DKH
>    Danny McPherson, Verisign, Inc.
>    Paul Vixie, Internet Systems Consortium



--
Suresh Ramasubramanian (ops.lists at gmail.com)



From jcurran at arin.net  Wed Dec 14 06:18:56 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 14 Dec 2011 12:18:56 +0000
Subject: Recognized Address Transfer Facilitators (was: Your Christmas Bonus
 Has Arrived)
In-Reply-To: <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <4EE814F9.8000409@mt.au.com>
 <Pine.LNX.4.64.1112132354070.26211@whammy.cluebyfour.org>
 <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net>
Message-ID: <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0@arin.net>

On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote:

> I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context).

I also do not know what "legit" means in this context, but will note
that we have added a public list of all recognized specified transfer 
facilitators to the ARIN web site:

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

Facilitators are aware of ARIN's address transfer policies and agree to 
comply with same.  Note that any qualifying parties may transfer space in 
compliance with policy, but folks may find it easier to work with one of 
these facilitators to find a matching party for transfer.  Facilitators may 
make use of information in the optional Specified Transfer Listing Service 
(which lists those who have space available or prequalify as a recipient) 
but not required to do so.  Similarly, parties which may have space available
for transfer or wish to prequalify in advance to receive address space via 
transfer may also register in the Specified Transfer Listing Service (STLS).  
More information is available on the ARIN web site <www.arin.net> under 
"IPv4 SPECIFIED TRANSFER OPTIONS" section.

FYI (and Happy Holidays :-)
/John

John Curran
President and CEO
ARIN


 

From leigh.porter at ukbroadband.com  Wed Dec 14 06:30:06 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 14 Dec 2011 12:30:06 +0000
Subject: Recognized Address Transfer Facilitators (was: Your Christmas
 Bonus Has Arrived)
In-Reply-To: <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0@arin.net>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <4EE814F9.8000409@mt.au.com>
 <Pine.LNX.4.64.1112132354070.26211@whammy.cluebyfour.org>
 <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net>,
 <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0@arin.net>
Message-ID: <8C3137B6-7690-4CF5-85B2-594E450CDB7B@ukbroadband.com>

I love the anti v6 stuff on some of their sites!

http://www.iptrading.com/news/news.htm


-- 
Leigh


On 14 Dec 2011, at 12:21, "John Curran" <jcurran at arin.net> wrote:

> On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote:
> 
>> I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context).
> 
> I also do not know what "legit" means in this context, but will note
> that we have added a public list of all recognized specified transfer 
> facilitators to the ARIN web site:
> 
> <https://www.arin.net/resources/transfer_listing/facilitator_list.html>
> 
> Facilitators are aware of ARIN's address transfer policies and agree to 
> comply with same.  Note that any qualifying parties may transfer space in 
> compliance with policy, but folks may find it easier to work with one of 
> these facilitators to find a matching party for transfer.  Facilitators may 
> make use of information in the optional Specified Transfer Listing Service 
> (which lists those who have space available or prequalify as a recipient) 
> but not required to do so.  Similarly, parties which may have space available
> for transfer or wish to prequalify in advance to receive address space via 
> transfer may also register in the Specified Transfer Listing Service (STLS).  
> More information is available on the ARIN web site <www.arin.net> under 
> "IPv4 SPECIFIED TRANSFER OPTIONS" section.
> 
> FYI (and Happy Holidays :-)
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From ops.lists at gmail.com  Wed Dec 14 06:31:06 2011
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 14 Dec 2011 18:01:06 +0530
Subject: EFF call for signatures from Internet engineers against censorship
In-Reply-To: <B13238AB0CB1514B9509DEEE5F98F2E00DE39363@PACDCEXMB13.cable.comcast.com>
References: <20111214072119.81F79800037@ip-64-139-1-69.sjc.megapath.net>
 <CAArzuouqU2SivNgcE-3ipe-AwSq7v7N1H4wWqOxzxsP8hxYCOA@mail.gmail.com>
 <B13238AB0CB1514B9509DEEE5F98F2E00DE39363@PACDCEXMB13.cable.comcast.com>
Message-ID: <CAArzuotafMx+1mRFT9dLqYyRvhyFBsPg=Cir48-Ez=QZxLLEPw@mail.gmail.com>

Wonderful.  I would urge SPs based stateside to strongly consider
endorsing the MAAWG comments.

thanks
suresh

On Wed, Dec 14, 2011 at 5:06 PM, O'Reirdan, Michael
<Michael_OReirdan at cable.comcast.com> wrote:
> MAAWG has written voicing its concerns on SOPA and PIPA.
>
> http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf
>
> Mike
> ________________________________________
> From: Suresh Ramasubramanian [ops.lists at gmail.com]
> Sent: 14 December 2011 05:12
> To: Hal Murray
> Cc: nanog at nanog.org
> Subject: Re: EFF call for signatures from Internet engineers against censorship
>
> I would strongly suggest that operators work with their legal
> departments to endorse this paper by Crocker and others.
>
> If other ISP organizations (such as say MAAWG) come out with
> something, other operators could sign on to that as well.
>
> The EFF petition has way too much propaganda and far less content than
> would be entirely productive in a policy discussion.
>
> --srs
>
>
> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
>>
>> ?Security and Other Technical Concerns Raised by the
>> ? ?DNS Filtering Requirements in the PROTECT IP Bill
>> ?Authors:
>> ? ?Steve Crocker, Shinkuro, Inc.
>> ? ?David Dagon, Georgia Tech
>> ? ?Dan Kaminsky, DKH
>> ? ?Danny McPherson, Verisign, Inc.
>> ? ?Paul Vixie, Internet Systems Consortium
>
>
>
> --
> Suresh Ramasubramanian (ops.lists at gmail.com)
>



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From bmanning at vacation.karoshi.com  Wed Dec 14 08:10:52 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 14 Dec 2011 14:10:52 +0000
Subject: Your Christmas Bonus Has Arrived
In-Reply-To: <1689b1b1-9c0c-4d7d-b1d4-4c533bfe5144@email.android.com>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <1689b1b1-9c0c-4d7d-b1d4-4c533bfe5144@email.android.com>
Message-ID: <20111214141052.GA7933@vacation.karoshi.com.>

On Tue, Dec 13, 2011 at 10:07:44PM -0800, Chaim Rieger wrote:
> What do you have for those that don't do the whole Jesus thing ?

babalyonian fertility icons?  (you -did- bring an evergreen tree into your
home, yes?)

/bill


From streiner at cluebyfour.org  Wed Dec 14 08:16:27 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 14 Dec 2011 09:16:27 -0500 (EST)
Subject: Recognized Address Transfer Facilitators (was: Your Christmas
 Bonus Has Arrived)
In-Reply-To: <8C3137B6-7690-4CF5-85B2-594E450CDB7B@ukbroadband.com>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <4EE814F9.8000409@mt.au.com>
 <Pine.LNX.4.64.1112132354070.26211@whammy.cluebyfour.org>
 <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net>,
 <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0@arin.net>
 <8C3137B6-7690-4CF5-85B2-594E450CDB7B@ukbroadband.com>
Message-ID: <Pine.LNX.4.64.1112140906460.30735@whammy.cluebyfour.org>

On Wed, 14 Dec 2011, Leigh Porter wrote:

> I love the anti v6 stuff on some of their sites!
>
> http://www.iptrading.com/news/news.htm

Some of which seems to float between fear-mongering, possibly 
mis-appropriated quotes, half-truths and information that is flat-out 
wrong.  I would not trust the judgment and opinions of someone who even 
admitted in one of their blog posts that they had "no hands-on Service 
Provider IPv6 experience."

While I can understand why IPv4 address brokers would take a decidedly 
anti-IPv6 stance (deploying IPv6 cuts into their potential business), that 
doesn't make it any less underhanded.

jms


From mtinka at globaltransit.net  Wed Dec 14 08:18:41 2011
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 14 Dec 2011 22:18:41 +0800
Subject: Recognized Address Transfer Facilitators (was: Your Christmas
 Bonus Has Arrived)
In-Reply-To: <8C3137B6-7690-4CF5-85B2-594E450CDB7B@ukbroadband.com>
References: <CAHSagfxnXGoRgRcs2YHuQQ3uE2=WgDR90ZHxGOzC=J-KJJYGgg@mail.gmail.com>
 <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0@arin.net>
 <8C3137B6-7690-4CF5-85B2-594E450CDB7B@ukbroadband.com>
Message-ID: <201112142218.42329.mtinka@globaltransit.net>

On Wednesday, December 14, 2011 08:30:06 PM Leigh Porter 
wrote:

> I love the anti v6 stuff on some of their sites!
> 
> http://www.iptrading.com/news/news.htm

I'd have been more impressed if they actually came up with 
the stories by themselves, as opposed to linking to existing 
stories that their link titles take out of context.

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/20111214/2168d8c3/attachment.bin>

From dholmes at mwdh2o.com  Wed Dec 14 13:07:04 2011
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Wed, 14 Dec 2011 11:07:04 -0800
Subject: Multiple ISP Load Balancing
Message-ID: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o>

>From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies.

Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks.

So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture.

David



  ________________________________
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 drew.weaver at thenap.com  Wed Dec 14 13:28:34 2011
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 14 Dec 2011 14:28:34 -0500
Subject: Multiple ISP Load Balancing
In-Reply-To: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o>
References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o>
Message-ID: <F3318834F1F89D46857972DD4B411D700527428411@exchange>

I've asked several times about this in the past; although I learned quickly to stop asking.

It seems that the consensus has generally been that the best way to handle traffic engineering in networks where you have multiple full-feed up-streams is to do it manually (i.e. set preference for your top N AS/prefix destinations) or don't do it at all (let BGP figure it out..?).

Suggesting that a "route optimization system" has any value generally makes people cranky.

Thanks,
-Drew

-----Original Message-----
From: Holmes,David A [mailto:dholmes at mwdh2o.com] 
Sent: Wednesday, December 14, 2011 2:07 PM
To: nanog at nanog.org
Subject: Multiple ISP Load Balancing

>From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies.

Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks.

So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture.

David



  ________________________________
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 morrowc.lists at gmail.com  Wed Dec 14 13:34:46 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 14 Dec 2011 14:34:46 -0500
Subject: Multiple ISP Load Balancing
In-Reply-To: <F3318834F1F89D46857972DD4B411D700527428411@exchange>
References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o>
 <F3318834F1F89D46857972DD4B411D700527428411@exchange>
Message-ID: <CAL9jLaYf13sWz=20JrufO=W+qfHXeFBEYoUesuhrONwzgdXcZQ@mail.gmail.com>

On Wed, Dec 14, 2011 at 2:28 PM, Drew Weaver <drew.weaver at thenap.com> wrote:
> I've asked several times about this in the past; although I learned quickly to stop asking.
>
> It seems that the consensus has generally been that the best way to handle traffic engineering in networks where you have multiple full-feed up-streams is to do it manually (i.e. set preference for your top N AS/prefix destinations) or don't do it at all (let BGP figure it out..?).
>

seems the feeling is that if you have multiple full feeds and need to
loadshare, you really don't want (in most cases) ispa=500mbps +
ispb=500mbps.

you really want destinationA to be reached across the 'best path'
(best ... in some form, distance? packetdrop%? jitter? cost?)  you'll
most likely have to tweak things in order to achieve what you want
since only distance is really used in the stock bgp calculation
(distance by as-hops, presuming you don't listen to closely to med
from your providers)

> Suggesting that a "route optimization system" has any value generally makes people cranky.
>

ha! :)

-chris

> Thanks,
> -Drew
>
> -----Original Message-----
> From: Holmes,David A [mailto:dholmes at mwdh2o.com]
> Sent: Wednesday, December 14, 2011 2:07 PM
> To: nanog at nanog.org
> Subject: Multiple ISP Load Balancing
>
> From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies.
>
> Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks.
>
> So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture.
>
> David
>
>
>
> ?________________________________
> 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 orothschild at gmail.com  Wed Dec 14 13:34:56 2011
From: orothschild at gmail.com (oliver rothschild)
Date: Wed, 14 Dec 2011 14:34:56 -0500
Subject: NANOG Digest, Vol 47, Issue 56
In-Reply-To: <mailman.16818.1323889637.1873.nanog@nanog.org>
References: <mailman.16818.1323889637.1873.nanog@nanog.org>
Message-ID: <CAED=9Eph1tvw9phpwSOVs9AsAuY58=GUg--6_WMp+N3XXreF3Q@mail.gmail.com>

This is my first e-mail to the list and I hope it is not entirely
inappropriate. We are attempting to use Juniper single-mode SFPs (LX
variety) across multi-mode fiber. Standard listed distance is always
for SFPs using the appropriate type of fiber. Does anyone out there
know how much distance we are likely to get? Thanks for your help in
advance.

On Wed, Dec 14, 2011 at 2:07 PM,  <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: EFF call for signatures from Internet engineers against
> ? ? ?censorship (Suresh Ramasubramanian)
> ? 2. RE: EFF call for signatures from Internet engineers against
> ? ? ?censorship (O'Reirdan, Michael)
> ? 3. Recognized Address Transfer Facilitators (was: Your Christmas
> ? ? ?Bonus Has Arrived) (John Curran)
> ? 4. Re: Recognized Address Transfer Facilitators (was: Your
> ? ? ?Christmas Bonus Has Arrived) (Leigh Porter)
> ? 5. Re: EFF call for signatures from Internet engineers against
> ? ? ?censorship (Suresh Ramasubramanian)
> ? 6. Re: Your Christmas Bonus Has Arrived
> ? ? ?(bmanning at vacation.karoshi.com)
> ? 7. Re: Recognized Address Transfer Facilitators (was: Your
> ? ? ?Christmas Bonus Has Arrived) (Justin M. Streiner)
> ? 8. Re: Recognized Address Transfer Facilitators (was: Your
> ? ? ?Christmas Bonus Has Arrived) (Mark Tinka)
> ? 9. Multiple ISP Load Balancing (Holmes,David A)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 14 Dec 2011 15:42:51 +0530
> From: Suresh Ramasubramanian <ops.lists at gmail.com>
> To: Hal Murray <hmurray at megapathdsl.net>
> Cc: nanog at nanog.org
> Subject: Re: EFF call for signatures from Internet engineers against
> ? ? ? ?censorship
> Message-ID:
> ? ? ? ?<CAArzuouqU2SivNgcE-3ipe-AwSq7v7N1H4wWqOxzxsP8hxYCOA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> I would strongly suggest that operators work with their legal
> departments to endorse this paper by Crocker and others.
>
> If other ISP organizations (such as say MAAWG) come out with
> something, other operators could sign on to that as well.
>
> The EFF petition has way too much propaganda and far less content than
> would be entirely productive in a policy discussion.
>
> --srs
>
>
> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
>>
>> ?Security and Other Technical Concerns Raised by the
>> ? ?DNS Filtering Requirements in the PROTECT IP Bill
>> ?Authors:
>> ? ?Steve Crocker, Shinkuro, Inc.
>> ? ?David Dagon, Georgia Tech
>> ? ?Dan Kaminsky, DKH
>> ? ?Danny McPherson, Verisign, Inc.
>> ? ?Paul Vixie, Internet Systems Consortium
>
>
>
> --
> Suresh Ramasubramanian (ops.lists at gmail.com)
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 14 Dec 2011 11:36:59 +0000
> From: "O'Reirdan, Michael" <Michael_OReirdan at Cable.Comcast.com>
> To: Suresh Ramasubramanian <ops.lists at gmail.com>, Hal Murray
> ? ? ? ?<hmurray at megapathdsl.net>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: RE: EFF call for signatures from Internet engineers against
> ? ? ? ?censorship
> Message-ID:
> ? ? ? ?<B13238AB0CB1514B9509DEEE5F98F2E00DE39363 at PACDCEXMB13.cable.comcast.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> MAAWG has written voicing its concerns on SOPA and PIPA.
>
> http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf
>
> Mike
> ________________________________________
> From: Suresh Ramasubramanian [ops.lists at gmail.com]
> Sent: 14 December 2011 05:12
> To: Hal Murray
> Cc: nanog at nanog.org
> Subject: Re: EFF call for signatures from Internet engineers against censorship
>
> I would strongly suggest that operators work with their legal
> departments to endorse this paper by Crocker and others.
>
> If other ISP organizations (such as say MAAWG) come out with
> something, other operators could sign on to that as well.
>
> The EFF petition has way too much propaganda and far less content than
> would be entirely productive in a policy discussion.
>
> --srs
>
>
> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
>>
>> ?Security and Other Technical Concerns Raised by the
>> ? ?DNS Filtering Requirements in the PROTECT IP Bill
>> ?Authors:
>> ? ?Steve Crocker, Shinkuro, Inc.
>> ? ?David Dagon, Georgia Tech
>> ? ?Dan Kaminsky, DKH
>> ? ?Danny McPherson, Verisign, Inc.
>> ? ?Paul Vixie, Internet Systems Consortium
>
>
>
> --
> Suresh Ramasubramanian (ops.lists at gmail.com)
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 14 Dec 2011 12:18:56 +0000
> From: John Curran <jcurran at arin.net>
> To: "Patrick W. Gilmore" <patrick at ianai.net>
> Cc: NANOG list <nanog at nanog.org>
> Subject: Recognized Address Transfer Facilitators (was: Your Christmas
> ? ? ? ?Bonus Has Arrived)
> Message-ID: <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0 at arin.net>
> Content-Type: text/plain; charset="us-ascii"
>
> On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote:
>
>> I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context).
>
> I also do not know what "legit" means in this context, but will note
> that we have added a public list of all recognized specified transfer
> facilitators to the ARIN web site:
>
> <https://www.arin.net/resources/transfer_listing/facilitator_list.html>
>
> Facilitators are aware of ARIN's address transfer policies and agree to
> comply with same. ?Note that any qualifying parties may transfer space in
> compliance with policy, but folks may find it easier to work with one of
> these facilitators to find a matching party for transfer. ?Facilitators may
> make use of information in the optional Specified Transfer Listing Service
> (which lists those who have space available or prequalify as a recipient)
> but not required to do so. ?Similarly, parties which may have space available
> for transfer or wish to prequalify in advance to receive address space via
> transfer may also register in the Specified Transfer Listing Service (STLS).
> More information is available on the ARIN web site <www.arin.net> under
> "IPv4 SPECIFIED TRANSFER OPTIONS" section.
>
> FYI (and Happy Holidays :-)
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 14 Dec 2011 12:30:06 +0000
> From: Leigh Porter <leigh.porter at ukbroadband.com>
> To: John Curran <jcurran at arin.net>
> Cc: NANOG list <nanog at nanog.org>
> Subject: Re: Recognized Address Transfer Facilitators (was: Your
> ? ? ? ?Christmas Bonus Has Arrived)
> Message-ID: <8C3137B6-7690-4CF5-85B2-594E450CDB7B at ukbroadband.com>
> Content-Type: text/plain; charset="us-ascii"
>
> I love the anti v6 stuff on some of their sites!
>
> http://www.iptrading.com/news/news.htm
>
>
> --
> Leigh
>
>
> On 14 Dec 2011, at 12:21, "John Curran" <jcurran at arin.net> wrote:
>
>> On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote:
>>
>>> I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context).
>>
>> I also do not know what "legit" means in this context, but will note
>> that we have added a public list of all recognized specified transfer
>> facilitators to the ARIN web site:
>>
>> <https://www.arin.net/resources/transfer_listing/facilitator_list.html>
>>
>> Facilitators are aware of ARIN's address transfer policies and agree to
>> comply with same. ?Note that any qualifying parties may transfer space in
>> compliance with policy, but folks may find it easier to work with one of
>> these facilitators to find a matching party for transfer. ?Facilitators may
>> make use of information in the optional Specified Transfer Listing Service
>> (which lists those who have space available or prequalify as a recipient)
>> but not required to do so. ?Similarly, parties which may have space available
>> for transfer or wish to prequalify in advance to receive address space via
>> transfer may also register in the Specified Transfer Listing Service (STLS).
>> More information is available on the ARIN web site <www.arin.net> under
>> "IPv4 SPECIFIED TRANSFER OPTIONS" section.
>>
>> FYI (and Happy Holidays :-)
>> /John
>>
>> John Curran
>> President and CEO
>> ARIN
>>
>>
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com
>> ______________________________________________________________________
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 14 Dec 2011 18:01:06 +0530
> From: Suresh Ramasubramanian <ops.lists at gmail.com>
> To: "O'Reirdan, Michael" <Michael_OReirdan at cable.comcast.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>, Hal Murray
> ? ? ? ?<hmurray at megapathdsl.net>
> Subject: Re: EFF call for signatures from Internet engineers against
> ? ? ? ?censorship
> Message-ID:
> ? ? ? ?<CAArzuotafMx+1mRFT9dLqYyRvhyFBsPg=Cir48-Ez=QZxLLEPw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Wonderful. ?I would urge SPs based stateside to strongly consider
> endorsing the MAAWG comments.
>
> thanks
> suresh
>
> On Wed, Dec 14, 2011 at 5:06 PM, O'Reirdan, Michael
> <Michael_OReirdan at cable.comcast.com> wrote:
>> MAAWG has written voicing its concerns on SOPA and PIPA.
>>
>> http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf
>>
>> Mike
>> ________________________________________
>> From: Suresh Ramasubramanian [ops.lists at gmail.com]
>> Sent: 14 December 2011 05:12
>> To: Hal Murray
>> Cc: nanog at nanog.org
>> Subject: Re: EFF call for signatures from Internet engineers against censorship
>>
>> I would strongly suggest that operators work with their legal
>> departments to endorse this paper by Crocker and others.
>>
>> If other ISP organizations (such as say MAAWG) come out with
>> something, other operators could sign on to that as well.
>>
>> The EFF petition has way too much propaganda and far less content than
>> would be entirely productive in a policy discussion.
>>
>> --srs
>>
>>
>> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
>>>
>>> ?Security and Other Technical Concerns Raised by the
>>> ? ?DNS Filtering Requirements in the PROTECT IP Bill
>>> ?Authors:
>>> ? ?Steve Crocker, Shinkuro, Inc.
>>> ? ?David Dagon, Georgia Tech
>>> ? ?Dan Kaminsky, DKH
>>> ? ?Danny McPherson, Verisign, Inc.
>>> ? ?Paul Vixie, Internet Systems Consortium
>>
>>
>>
>> --
>> Suresh Ramasubramanian (ops.lists at gmail.com)
>>
>
>
>
> --
> Suresh Ramasubramanian (ops.lists at gmail.com)
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 14 Dec 2011 14:10:52 +0000
> From: bmanning at vacation.karoshi.com
> To: Chaim Rieger <chaim.rieger at gmail.com>
> Cc: nanog at nanog.org
> Subject: Re: Your Christmas Bonus Has Arrived
> Message-ID: <20111214141052.GA7933 at vacation.karoshi.com.>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Dec 13, 2011 at 10:07:44PM -0800, Chaim Rieger wrote:
>> What do you have for those that don't do the whole Jesus thing ?
>
> babalyonian fertility icons? ?(you -did- bring an evergreen tree into your
> home, yes?)
>
> /bill
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 14 Dec 2011 09:16:27 -0500 (EST)
> From: "Justin M. Streiner" <streiner at cluebyfour.org>
> To: NANOG list <nanog at nanog.org>
> Subject: Re: Recognized Address Transfer Facilitators (was: Your
> ? ? ? ?Christmas Bonus Has Arrived)
> Message-ID: <Pine.LNX.4.64.1112140906460.30735 at whammy.cluebyfour.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Wed, 14 Dec 2011, Leigh Porter wrote:
>
>> I love the anti v6 stuff on some of their sites!
>>
>> http://www.iptrading.com/news/news.htm
>
> Some of which seems to float between fear-mongering, possibly
> mis-appropriated quotes, half-truths and information that is flat-out
> wrong. ?I would not trust the judgment and opinions of someone who even
> admitted in one of their blog posts that they had "no hands-on Service
> Provider IPv6 experience."
>
> While I can understand why IPv4 address brokers would take a decidedly
> anti-IPv6 stance (deploying IPv6 cuts into their potential business), that
> doesn't make it any less underhanded.
>
> jms
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 14 Dec 2011 22:18:41 +0800
> From: Mark Tinka <mtinka at globaltransit.net>
> To: nanog at nanog.org
> Cc: John Curran <jcurran at arin.net>
> Subject: Re: Recognized Address Transfer Facilitators (was: Your
> ? ? ? ?Christmas Bonus Has Arrived)
> Message-ID: <201112142218.42329.mtinka at globaltransit.net>
> Content-Type: text/plain; charset="us-ascii"
>
> On Wednesday, December 14, 2011 08:30:06 PM Leigh Porter
> wrote:
>
>> I love the anti v6 stuff on some of their sites!
>>
>> http://www.iptrading.com/news/news.htm
>
> I'd have been more impressed if they actually came up with
> the stories by themselves, as opposed to linking to existing
> stories that their link titles take out of context.
>
> 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/20111214/2168d8c3/attachment-0001.bin>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 14 Dec 2011 11:07:04 -0800
> From: "Holmes,David A" <dholmes at mwdh2o.com>
> To: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Multiple ISP Load Balancing
> Message-ID:
> ? ? ? ?<922ACC42D498884AA02B3565688AF9953402D4EF13 at USEXMBS01.mwd.h2o>
> Content-Type: text/plain; charset="us-ascii"
>
> >From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies.
>
> Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks.
>
> So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture.
>
> David
>
>
>
> ?________________________________
> 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.
>
>
> End of NANOG Digest, Vol 47, Issue 56
> *************************************


From jeff.tantsura at ericsson.com  Wed Dec 14 13:38:10 2011
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Wed, 14 Dec 2011 14:38:10 -0500
Subject: Multiple ISP Load Balancing
In-Reply-To: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o>
References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o>
Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C480943@EUSAACMS0701.eamcs.ericsson.se>

Hi David,

You might want to take a look at work happening in ALTO (http://tools.ietf.org/wg/alto/)

Regards,
Jeff
-----Original Message-----
From: Holmes,David A [mailto:dholmes at mwdh2o.com] 
Sent: Wednesday, December 14, 2011 11:07 AM
To: nanog at nanog.org
Subject: Multiple ISP Load Balancing

>From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies.

Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local