Cisco IOS MPLS VPN Bug

[Joe Renwick]

Hello All,

A customer of our's has had two major outages due to a bug in Cisco's
software.  The network is an MPLS VPN environment.  The bug has occurred on
our 6500(s) with VS-S720-10G Supervisors running
s72033-adventerprisek9_wan-mz.122-33.SXH6.bin.   These routers
are configured as BGP route-reflectors.  The first time the bug
hit occurred when a new route-reflector client was added.  The second time
was due to a topology change on the network.  On both occasions the only fix
was removing the peer configurations on the RR and re-applying.  Niether
soft nor hard clears on the BGP neighbors worked, only the config removal.
 Once re-applied life was good.

The bug itself was with the BGP updates sent by the RR.  During the outage
these updates did not include the Route Target Extended Community required
by the route-reflector clients which identifies which VRF the route belongs
too.  Below is output on a client during the outage and after the config
yanking.  Notice the mysterious disappearance of the RT community.

Looking to see if anyone has seen this issue particularly with this version
of code.  TAC is trying to tell me that this was a bug in a previous version
but is fixed in the code I am running.  Huh?  Been running around in circles
with them for a month so this is my act of desperation.   Also if anyone is
running a similar environment without issue I would be very interested in
what version of code your using.

Thanks to all who took the time to read this email... Happy Friday.

*BAD:*

CLN-MWB-2811-01#sh ip bgp vpnv4 all 10.180.33.22

BGP routing table entry for 102:102:10.180.33.20/30, version 1763889

Paths: (2 available, best #2, no table)

  Advertised to update-groups:

1

  Local

10.180.20.1 (metric 9) from 10.180.20.3 (10.180.20.3)

  Origin incomplete, metric 0, localpref 100, valid, internal

  Extended Community: RT:102:102

  Originator: 10.180.20.1, Cluster list: 0.0.255.245

  mpls labels in/out nolabel/16

  Local

10.180.20.1 (metric 9) from *10.180.20.1* (10.180.20.1)

  Origin incomplete, metric 0, localpref 100, valid, internal, best

  mpls labels in/out nolabel/16

*GOOD:*

CLN-MWB-2811-01#sh ip bgp vpnv4 all 10.180.33.22

BGP routing table entry for 102:102:10.180.33.20/30, version 1765931

Paths: (2 available, best #1, table AMS)

  Advertised to update-groups:

1

  Local

10.180.20.1 (metric 9) from *10.180.20.1* (10.180.20.1)

  Origin incomplete, metric 0, localpref 100, valid, internal, best

  *Extended Community: RT:102:102*

  mpls labels in/out nolabel/16

  Local

10.180.20.1 (metric 9) from 10.180.20.3 (10.180.20.3)

  Origin incomplete, metric 0, localpref 100, valid, internal

  Extended Community: RT:102:102

  Originator: 10.180.20.1, Cluster list: 0.0.255.245

  mpls labels in/out nolabel/16

Cheers,

-- 
Joe Renwick
IP Network Consultant, CCIE #16465
GO NETFORWARD!
Direct: 619-800-2055, Emergency Support: 800-719-0504
Is your network moving you forward?

Re: estimation of number of DFZ IPv4 routes at peak in the future

[Joel Jaeggli]

I'm super-tired of the "but tcams are an expensive non-commodity part not 
subject to economies of scale". this has been repeated ad nauseam since the 
raws workshop if not before.

You don't have to build a lookup engine around a tcam and in fact you can use 
less power doing so even though you need more silicon to achieve increased 
parallelism.

RFC 4984 has a lot of useful insights in it but it was flat wrong about two 
things since 2007. The impact of rate of growth in the DFZ(for one thing churn 
failed to grow in lockstep), and the ability of the technology to keep up.

Not all the devices in your network need a 2 million route FIB, yet getting a 
device today that has one isn't that hard. and it'll be a lot easier in five 
years and it likely will do so without having a 144Mbit CAM ASIC.

I don't know  if we'll be using commercially viable MRAM implementations in 
place of SRAM cells in a decade or if we'll have more of the same only smaller 
and faster and much much wider, Or if the LISP religion will take over the 
world and we'll carry the state for diversely connected edges elsewhere in the 
stack. What I am confident of is that as an industry we'll be able to deliver 
something that works without jacking up the Internet routing system and 
replacing it, and without somehow altering the individual decision making 
processes in many tens of thousands of autonomous systems. I am also confident 
that the early adopters will pay more for the technology than the stragglers, 
that we will grumble about how much it costs and the inevitability of 
obsolescence, and that life will somehow go on.

Joel's widget number 2

On Mar 11, 2011, at 17:53, Owen DeLong  wrote:

> 
> On Mar 11, 2011, at 5:43 PM, William Herrin wrote:
> 
>> On Fri, Mar 11, 2011 at 6:39 PM, Justin Krejci  
>> wrote:
>>> On Wed, 2011-03-09 at 09:32 -0500, John Curran wrote:
 On Mar 9, 2011, at 12:43 AM, Majdi S. Abbas wrote:
>   I suspect that as we reach exhaustion, more people will be
> forced to break space out of their provider's v4 aggregates, and
> announce them, and an unfiltered DFZ may well approach the 'million'
> entries some vendors now claim to support.
 
 This matches my personal view (and could be viewed as
 "success" compared to the 5M estimate of Mr. Herrin...)
>>> 
>>> Are people going to be relying on using default-routing then in the
>>> future if they don't upgrade routers to handle large routing table
>>> growth? Or perhaps forgo dual-stack and have a separate physical IPv6
>>> BGP network from IPv4? Are there any other strategies?
>> 
>> 
>> Hi Justin,
>> 
>> IMHO, the most sensible strategy is to recognize that that cost of a
>> route has been dropping faster than the route count has been rising
>> for the past decade. Then recognize that with today's hardware,
>> building a route processor capable of keeping up with 10M routes
>> instead of 1M routes would cost maybe twice as much... 10M being
>> sufficient to handle the worst case estimates for the final size of
>> the IPv4 table in parallel with any reasonable estimate of the IPv6
>> table in the foreseeable future. Better CPU, more DRAM, bigger TCAM.
>> It could be built today.
>> 
> But the RP is the easy cheap part. It's the line cards and the
> TCAM/etc. that they use that gets pricey fast.
> 
>> Finally, get mad at your respective router manufacturers for
>> engineering obsolescence into their product line by declining to give
>> you the option.
>> 
> The option of $60,000 line cards instead of $30,000 or
> even $25,000 instead of $12,000 does not seem like one
> that most would have found appealing.
> 
>> But that's just my opinion...
>> 
> And the above is just mine.
> 
> Owen
> 
> 
> 

Re: Switching Email

[François Rousseau]

2011/3/11 Ryan Landry :
> there are handy gmail filters that can fix this for you...
>
> On Fri, Mar 11, 2011 at 6:46 PM, William Herrin  wrote:
>>
>>
>> I wonder if the "feature" has anything to do with the number of
>> increasing number of NANOG list messages that I have to fish out of my
>> gmail spam folder. Particularly annoying with the CIDR and BGP reports
>> that I've had to fish out every single week for months now.
>>
>> -Bill
>>
>>
>>
>> --
>> William D. Herrin  her...@dirtside.com  b...@herrin.us
>> 3005 Crane Dr. .. Web: 
>> Falls Church, VA 22042-3004
>>
>>
>

Well it's a mailman server so you could email nanog-requ...@nanog.org
with the subject: unsubscribe

Re: Switching Email

[Ryan Landry]

there are handy gmail filters that can fix this for you...

On Fri, Mar 11, 2011 at 6:46 PM, William Herrin  wrote:
>
>
> I wonder if the "feature" has anything to do with the number of
> increasing number of NANOG list messages that I have to fish out of my
> gmail spam folder. Particularly annoying with the CIDR and BGP reports
> that I've had to fish out every single week for months now.
>
> -Bill
>
>
>
> --
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
>
>

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Dobbins, Roland]

On Mar 12, 2011, at 11:14 AM, Jeff Wheeler wrote:

> Of course, I don't really mean to call Owen a liar, or foolish, or anything 
> else.  

Please don't; even though I disagree with him and agree with you very strongly 
on this set of issues, Owen is a smart and straightforward guy, and is simply 
speaking from his (selective on this particular set of topics, IMHO) own 
individual viewpoint.

;>

> and if the most popular fix becomes dependent on NDP inspection


If that comes to pass, then the fix will be useless, unfortunately, just as 
dynamic ARP inspection (DAI) is useless today; it self-DoSes the box.

Any form of 'inspection' will not scale for this problem, as it will be 
CPU-bound even on ASIC-based platforms.

All this ICMPv6 weirdness and outright brokenness is the Achilles' heel of 
IPv6, and I see no ready solution in sight for the set of problems it engenders.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Jeff Wheeler]

On Fri, Mar 11, 2011 at 6:33 PM, Owen DeLong  wrote:
> Yes, you can bring as much of the pain from IPv4 forward into IPv6
> as you like. You can also commit many other acts of masochism.

This is the problem with "Fundamentalists," such as yourself, Owen.
You think that "fixing" things which work fine (like reasonable-sized
VLSM LANs for content farms) is worth introducing a DDoS vulnerability
for which there is no current defense, and for which the only feasible
defense is either reversing your choice and renumbering the subnet
from /64 to /smaller, or waiting until your vendors supply you with
patched images for your routers and/or switches.

You need to move beyond this myopic view that /64 provides a benefit
that is worth this kind of operational sacrifice.  When vendors cough
up some more knobs, I'll be right there with you, configuring /64
subnets.  I've already allocated them!  It's pretty easy for me to
renumber my /120 subnets to /64, after all -- I don't have to update
any zone files for public-facing services, or modify significant
configuration for software -- I just have to reconfigure my router and
host interfaces from /120 to /64.  You, on the other hand, may have
addresses in use all over that /64, and condensing them into a smaller
subnet is guaranteed to be at least as hard as my work for growing my
subnet, and may be much more difficult -- every bit as difficult as
renumbering from one IPv4 block to another.

Given the current state of IPv6, your "Fundamentalist" way introduces
new problems *and* brings the old ones forward.  This makes no sense,
but Fundamentalists rarely do.

> Personally, I prefer to approach IPv6 as a way to reduce some of
> the more painful aspects of IPv4, such as undersized subnets,
> having to renumber or add prefixes for growth, limited aggregation,
> NAT, and more.

I look forward to that when it works.  As I've noticed, I have
prepared to take advantage of those things as soon as the NDP issue is
resolved.

>> None of that "standard IPv6 automatic stuff" works today, anyway.  The
>> state of IPv6 support on end-user CPE generally ranges from
> As someone using SLAAC in a number of environments, I'm confused
> by this statement. It seems to be working quite well in many places
> and end-user residential networks are certainly not the only places
> where it is useful.

Your definition of "working quite well in many places" is different
than mine.  I'll come around to your point of view when it is possible
to get working IPv6 connectivity from most major end-user ISPs, and
all (or close enough) the CPE being sold at Fry's and Best Buy works
right.  We are pretty far from that right now.

This is another thing the "IPv6 Fundamentalists" seem to ignore.  CPE
support is almost non-existent, ISP support is not there (some tier-1
transit networks still have no IPv6 product!), and the major IXPs
still have three orders of magnitude more IPv4 traffic than IPv6.
Cogent, Level3, and Hurricane Electric still can't decide that it's in
their mutual interest to exchange IPv6 traffic with each-other, and
their customers don't care enough to go to another service provider,
because IPv6 is largely unimportant to them.

None of this stuff "works" today.  You aren't seeing DDoS scenarios on
the v6 network today because the largest IPv4 DDoS attacks are larger
than the total volume of inter-domain IPv6 traffic.

> Most of the top-of-rack switches I'm aware of have no problem doing
> at least 64k NDP/ARP entries. Many won't do more than that, but,
> most will go at least that far.

Owen, this statement is either:
1) a gross misunderstanding on your part, because you can't or don't
read spec sheets, let alone test gear
2) you've never seen or used a top-of-rack switch or considered buying
one long enough to examine the specs
3) your racks are about 3 feet taller than everyone else's and you
blow 100k on switching for every few dozen servers
4) an outright lie, although not an atypical one for the "IPv6
Fundamentalist" crowd

I'd like you to clarify which of these is the case.  Please list some
switches which fit your definition of "top-of-rack switch" that
support 64k NDP entries.  Then list how many "top-of-rack" switches
you are currently aware of.  Don't bother listing the ones you know
don't support 64k, because I'll gladly provide a list of plenty more
of those, than the number of switches which you find to support 64k in
a ToR form-factor.

For those following along at home, how many ToR switches do indeed
support at least 64k NDP entries?  Unlike Owen, I know the answer to
this question: Zero.  There are no ToR switches that support >= 64k
NDP table entries.

Of course, I don't really mean to call Owen a liar, or foolish, or
anything else.  I do mean to point out that his "facts" are wrong and
his argument not based in the world of reality.  He is a
"Fundamentalist," and is part of the problem, not the solution.

> I find it interesting that you _KNOW_ that /64 LANs will cause

Re: Switching Email

[Jeff Kell]

On 3/11/2011 8:24 PM, Scott Weeks wrote:
> --- b...@herrin.us wrote:
> From: William Herrin 
>
> No, it isn't. Contrary to mailing list best practices, NANOG
> unsubscribe information is stubbornly stashed in the email headers
> --
>
> That's a feature.  Not a bug.  :-)

Actually, it's RFC 2369  :)

Jeff

Re: Switching Email

[William Herrin]

On Fri, Mar 11, 2011 at 8:54 PM, Brandon Butterworth
 wrote:
>> Mr. Shimonski could solve his problem by googling "unsubscribe nanog"
>> but he probably has no other way of figuring out how to get off of the
>> list.
>
> besides the monthly happy mailman day message reminding you how

We get what, 20, 30, 100 messages a day? How about as a prank I
subscribe you to the Justin Bieber mailing list at the same message
volume, only you can't get instructions about how to unsubscribe for
30 days and you have to read the mail in Microsoft Lookout,
interspersed with work-oriented messages from your boss and
colleagues. With Outlook popping new-message-notifications up on the
projector while you try to give a presentation during a meeting, each
containing the sender and message subject...

-Bill



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: estimation of number of DFZ IPv4 routes at peak in the future

[William Herrin]

On Fri, Mar 11, 2011 at 8:53 PM, Owen DeLong  wrote:
> On Mar 11, 2011, at 5:43 PM, William Herrin wrote:
>> Finally, get mad at your respective router manufacturers for
>> engineering obsolescence into their product line by declining to give
>> you the option.
>>
> The option of $60,000 line cards instead of $30,000 or
> even $25,000 instead of $12,000 does not seem like one
> that most would have found appealing.

Ever buy SAS drives instead of SATA even though they're twice as
expensive for the same disk space? Why?

You may be right, but it'd be nice to have the option.

-Bill



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: estimation of number of DFZ IPv4 routes at peak in the future

[Owen DeLong]

On Mar 11, 2011, at 5:43 PM, William Herrin wrote:

> On Fri, Mar 11, 2011 at 6:39 PM, Justin Krejci  wrote:
>> On Wed, 2011-03-09 at 09:32 -0500, John Curran wrote:
>>> On Mar 9, 2011, at 12:43 AM, Majdi S. Abbas wrote:
I suspect that as we reach exhaustion, more people will be
 forced to break space out of their provider's v4 aggregates, and
 announce them, and an unfiltered DFZ may well approach the 'million'
 entries some vendors now claim to support.
>>> 
>>> This matches my personal view (and could be viewed as
>>> "success" compared to the 5M estimate of Mr. Herrin...)
>> 
>> Are people going to be relying on using default-routing then in the
>> future if they don't upgrade routers to handle large routing table
>> growth? Or perhaps forgo dual-stack and have a separate physical IPv6
>> BGP network from IPv4? Are there any other strategies?
> 
> 
> Hi Justin,
> 
> IMHO, the most sensible strategy is to recognize that that cost of a
> route has been dropping faster than the route count has been rising
> for the past decade. Then recognize that with today's hardware,
> building a route processor capable of keeping up with 10M routes
> instead of 1M routes would cost maybe twice as much... 10M being
> sufficient to handle the worst case estimates for the final size of
> the IPv4 table in parallel with any reasonable estimate of the IPv6
> table in the foreseeable future. Better CPU, more DRAM, bigger TCAM.
> It could be built today.
> 
But the RP is the easy cheap part. It's the line cards and the
TCAM/etc. that they use that gets pricey fast.

> Finally, get mad at your respective router manufacturers for
> engineering obsolescence into their product line by declining to give
> you the option.
> 
The option of $60,000 line cards instead of $30,000 or
even $25,000 instead of $12,000 does not seem like one
that most would have found appealing.

> But that's just my opinion...
> 
And the above is just mine.

Owen

Re: Switching Email

[Brandon Butterworth]

> Mr. Shimonski could solve his problem by googling "unsubscribe nanog"
> but he probably has no other way of figuring out how to get off of the
> list.

besides the monthly happy mailman day message reminding you how

brandon

Re: so big earthquake in JP

[Marshall Eubanks]

On Mar 11, 2011, at 6:34 PM, Owen DeLong wrote:

> 
> On Mar 11, 2011, at 6:11 AM, Patrick W. Gilmore wrote:
> 
>> On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote:
>> 
>>> Are we aware of how much the infrastructure has been damaged yet? Are 
>>> aftershocks still going?
>> 
>> Subway & bus lines are still down.  Fire at the nuke plant has been put out, 
>> no radiation detected, but they still evacuated a couple thousand residents 
>> because the backup generator failed & the water pump is not pumping.
>> 
> I hear that there is now rising radiation levels outside the plant and US is 
> flying in some dampers
> in hopes to resolve the situation.

Here is what the IAEA has to say about the situation

http://www.iaea.org/press/?p=1133

Japanese officials have also reported that pressure is increasing inside the 
Unit 1 reactor’s containment, and the officials have decided to vent the 
containment to lower the pressure.  The controlled release will be filtered to 
retain radiation within the containment.

TEPCO has a lot more detail

http://www.tepco.co.jp/en/press/corp-com/release/11031203-e.html

http://www.tepco.co.jp/en/press/corp-com/release/11031209-e.html

Regards
Marshall




> 
> Owen
> 
> 
> 

Re: Switching Email

[William Herrin]

On Fri, Mar 11, 2011 at 8:24 PM, Scott Weeks  wrote:
>> No, it isn't. Contrary to mailing list best practices, NANOG
>> unsubscribe information is stubbornly stashed in the email headers
>
> That's a feature.  Not a bug.  :-)

I wonder if the "feature" has anything to do with the number of
increasing number of NANOG list messages that I have to fish out of my
gmail spam folder. Particularly annoying with the CIDR and BGP reports
that I've had to fish out every single week for months now.

-Bill



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: estimation of number of DFZ IPv4 routes at peak in the future

[William Herrin]

On Fri, Mar 11, 2011 at 6:39 PM, Justin Krejci  wrote:
> On Wed, 2011-03-09 at 09:32 -0500, John Curran wrote:
>> On Mar 9, 2011, at 12:43 AM, Majdi S. Abbas wrote:
>> >    I suspect that as we reach exhaustion, more people will be
>> > forced to break space out of their provider's v4 aggregates, and
>> > announce them, and an unfiltered DFZ may well approach the 'million'
>> > entries some vendors now claim to support.
>>
>> This matches my personal view (and could be viewed as
>> "success" compared to the 5M estimate of Mr. Herrin...)
>
> Are people going to be relying on using default-routing then in the
> future if they don't upgrade routers to handle large routing table
> growth? Or perhaps forgo dual-stack and have a separate physical IPv6
> BGP network from IPv4? Are there any other strategies?


Hi Justin,

IMHO, the most sensible strategy is to recognize that that cost of a
route has been dropping faster than the route count has been rising
for the past decade. Then recognize that with today's hardware,
building a route processor capable of keeping up with 10M routes
instead of 1M routes would cost maybe twice as much... 10M being
sufficient to handle the worst case estimates for the final size of
the IPv4 table in parallel with any reasonable estimate of the IPv6
table in the foreseeable future. Better CPU, more DRAM, bigger TCAM.
It could be built today.

Finally, get mad at your respective router manufacturers for
engineering obsolescence into their product line by declining to give
you the option.

But that's just my opinion...

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Switching Email

[Scott Weeks]

--- b...@herrin.us wrote:
From: William Herrin 

No, it isn't. Contrary to mailing list best practices, NANOG
unsubscribe information is stubbornly stashed in the email headers
--


That's a feature.  Not a bug.  :-)

scott

Re: Switching Email

[William Herrin]

On Fri, Mar 11, 2011 at 1:16 PM, Justin M. Streiner
 wrote:
> On Fri, 11 Mar 2011, Robert Shimonski wrote:
>> I would like to opt out of this news list.
>
> A link that includes mailing list management functions, including the
> ability to unsubscribe yourself from the list, is append to the end of every
> email that's posted to the list.

No, it isn't. Contrary to mailing list best practices, NANOG
unsubscribe information is stubbornly stashed in the email headers
where users of certain mail programs have no prayer of getting to it
and users of most other mail programs don't know how to look for it.

Mr. Shimonski could solve his problem by googling "unsubscribe nanog"
but he probably has no other way of figuring out how to get off of the
list.

-Bill


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Switching Email

[Justin M. Streiner]

On Fri, 11 Mar 2011, Robert Shimonski wrote:


I would like to opt out of this news list.


A link that includes mailing list management functions, including the 
ability to unsubscribe yourself from the list, is append to the end of 
every email that's posted to the list.  Using that link would be your best 
bet if you want to unsubscribe.


jms

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Leo Bicknell]

In a message written on Fri, Mar 11, 2011 at 04:13:13PM -0800, Owen DeLong 
wrote:
> On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote:
> > Well, I at least think an option should be a /80, using the 48 bits
> > of MAC directly.  This generates exactly the same collision potential
> > as today we have with a /64 and an EUI-64 constructed from an EUI-48
> > ethernet address.  The router is already sending RA's for SLAAC to
> > work, sending along one of a well-known set of masks would be a
> > relatively minor modification.
> > 
> How would you use that on a Firewire netowrk or FDDI or any of the
> other media that uses 64-bit MAC addresses?

It wouldn't.

I'm not proposing a solution for everything, just a useful case for
some things.  I don't want to change say, RIR policy that you can
allocate a /64, just allow operators to use /80's, or /96's in a
more useful way if they find that useful.

Basically I think the IETF and IPv6 propoents went a bit too far
down the "one size fits all" route.  It has nothing to do with how
many numbers may or may not be used, but everything to do with the
fact that you often have to fit inside what's been given to you.
If you're stuck with a monopoly provider who gives you a /64 to
your cable modem there should be easy options to split it up and
get some subnets.

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


pgpWiT2xsQGU0.pgp
Description: PGP signature

Re: so big earthquake in JP

[Jeffrey Lyon]

On Fri, Mar 11, 2011 at 6:53 PM, Junichi Shimagami  wrote:
> Hello all,
>
> The situation is still quite bad in north eastern area of Honshu
> island where Sendai resides.
> In Tokyo, we still have frequent aftershocks, but it's getting back to
> normal gradually.
>
> As of connectivity from Japan to overseas, IIJ is seeing several
> international circuits going down.
> Several cables, not only trans pacific but also intra Asian, seems to
> be affected by the earthquake offshore of Japan.
> You may encounter some congestion not only to Japan but also to Asia.
>
> Thanks for you support.
>
>
> Sincerely,
>
> Junichi Shimagami
> Internet Initiative Japan Inc.
> from Tokyo
>
>
> 2011/3/11 Dorian Kim :
>> On Fri, Mar 11, 2011 at 07:29:29AM -0700, Garret Picchioni wrote:
>>> Does anyone have any stats on route updates that might suggest the
>>> possibility of fiber on the ocean floor being damaged?
>>
>> There are some submarine cable outages but I don't believe exact
>> locations of damage has been isolated. I suspect that this may take
>> some time.
>>
>> -dorian
>>
>>
>
>

I don't have anything specific, but PCCW is reporting issues with
trans Pacific routes.

-- 
Jeffrey Lyon, Leadership Team
jeffrey.l...@blacklotus.net | http://www.blacklotus.net
Black Lotus Communications - AS32421
First and Leading in DDoS Protection Solutions

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Owen DeLong]

On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote:

> In a message written on Fri, Mar 11, 2011 at 01:07:15PM -0500, 
> valdis.kletni...@vt.edu wrote:
>> On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said:
>>> rfc3927 does not require 64 bits and works sufficiently well wherever it 
>>> is employed. SLAAC should be redesigned to be configurable to work with 
>>> however many bits are available to it and it should be a standard 
>>> feature to turn that knob all the way from on - off with 128 bit stops 
>>> in between.
>> 
>> Feel free to explain how SLAAC should work on a /96 with 32 bits of host 
>> address
>> (or any amount smaller than the 48 bits most MAC addresses provide).  
>> Remember
>> in your answer to deal with collisions.
> 
> Well, I at least think an option should be a /80, using the 48 bits
> of MAC directly.  This generates exactly the same collision potential
> as today we have with a /64 and an EUI-64 constructed from an EUI-48
> ethernet address.  The router is already sending RA's for SLAAC to
> work, sending along one of a well-known set of masks would be a
> relatively minor modification.
> 
How would you use that on a Firewire netowrk or FDDI or any of the
other media that uses 64-bit MAC addresses?

> That said, ND has built into it DAD - Duplicate Address Detection.
> There is already an expectation that there will be collisions, and
> the protocols to detect them are already in place.  I see little
> to no reason you couldn't use a different length subnet (like the
> /96 in your example), randomly select an address and do DAD to see
> if it is in use.  Indeed, this is pretty much how AppleTalk back
> in the day worked (with a 16 bit number space).
> 
Detect, yes. Mitigate, no. DAD on the link-local results in Interface
shutdown.

In an environment where there's a very low probability of collision,
that's an acceptable risk that is easily mitigated in most cases.
In an environment where you create a much higher risk of collision,
such as 1/2^32 or less, vs. 1/2^48 or more, I think that's a rather
ill advised approach.

> The probability of collision is pretty low, and the penalty/recovery
> (picking a new address and trying again) is rather quick and cheap.
> 
IPv6 does not try to pick a new address and try again in SLAAC, at
least not what it's supposed to do.

> If a service provider is going to end up giving me a /64 at home (I
> know, a whole different argument) I'd vastly prefer to use /80 or /96
> subnets with either of these methods, and still be able to subnet the
> space.  I suspect if /64's are given out one or both will come to be
> "standard".
> 
If a service provider attempts to give ma a /64 at home, I'd opt for
a new provider instead.

Owen

Re: so big earthquake in JP

[Junichi Shimagami]

Hello all,

The situation is still quite bad in north eastern area of Honshu
island where Sendai resides.
In Tokyo, we still have frequent aftershocks, but it's getting back to
normal gradually.

As of connectivity from Japan to overseas, IIJ is seeing several
international circuits going down.
Several cables, not only trans pacific but also intra Asian, seems to
be affected by the earthquake offshore of Japan.
You may encounter some congestion not only to Japan but also to Asia.

Thanks for you support.


Sincerely,

Junichi Shimagami
Internet Initiative Japan Inc.
from Tokyo


2011/3/11 Dorian Kim :
> On Fri, Mar 11, 2011 at 07:29:29AM -0700, Garret Picchioni wrote:
>> Does anyone have any stats on route updates that might suggest the
>> possibility of fiber on the ocean floor being damaged?
>
> There are some submarine cable outages but I don't believe exact
> locations of damage has been isolated. I suspect that this may take
> some time.
>
> -dorian
>
>

Re: Long Distance Dark Fiber

[Owen DeLong]

On Mar 11, 2011, at 7:50 AM, Joel Jaeggli wrote:

> On 3/11/11 7:16 AM, Jeff Wheeler wrote:
>> On Fri, Mar 11, 2011 at 9:25 AM, ML  wrote:
>>> Would it be too crazy to buy a spool of fiber and splice the end of one pair
>>> to the next pair and so on?  Won't be able to simulate 2200 miles of fiber
>>> but it'll be a long span.
>> 
>> This is by no means crazy.  If you visit a laboratory where gear is
>> tested, you'll find exactly that -- spools of fiber which can be
>> connected together (through whatever splicing or patching method is
>> desired for the simulation) to give the desired span length.  These
>> usually look nicer than big spools of cable, and are even available in
>> rack-mount enclosures with vendor logos. :)
> 
> one does not however do 2200 miles of terrestrial fiber simulation
> without simulating regeneration as well.
> 
> 
You can, but, it requires electronic retiming of the fiber signal
(fiber->ring buffer->configurable delay->fiber).

I guess technically that simulates one iteration of regeneration
to some extent, but, it certainly wouldn't represent a test of
2200 miles worth of analog regeneration of a digital signal.

Owen

Re: so big earthquake in JP

[Owen DeLong]

On Mar 11, 2011, at 6:11 AM, Patrick W. Gilmore wrote:

> On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote:
> 
>> Are we aware of how much the infrastructure has been damaged yet? Are 
>> aftershocks still going?
> 
> Subway & bus lines are still down.  Fire at the nuke plant has been put out, 
> no radiation detected, but they still evacuated a couple thousand residents 
> because the backup generator failed & the water pump is not pumping.
> 
I hear that there is now rising radiation levels outside the plant and US is 
flying in some dampers
in hopes to resolve the situation.

Owen

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Owen DeLong]

On Mar 11, 2011, at 5:53 AM, Jeff Wheeler wrote:

> On Thu, Mar 10, 2011 at 10:51 PM, George Bonser  wrote:
>> And I say making them /127s may not really make any difference.  Say you
>> make all of those /127s, at some point you *are* going to have a network
>> someplace that is a /64 that has hosts on it and that one is just as
>> subject to such an attack.  If you are a content provider, it doesn't
>> make any difference if they take down the links between your routers or
>> if they take down the link that your content farm is on.  The end result
>> is the same.  You have managed to re-arrange the deck chairs.  Have
>> another squeeze at that water balloon.
> 
> Again, this is the argument put forth by the "RFC wavers," that you
> can't solve the problem because you must want to configure /64s for
> ... what, exactly?  Oh, right, SLAAC.  More on that below.
> 
> If I'm a content provider, I don't have to configure a /64 for my
> content farm.  I can configure a /120 or whatever subnet size is
> practical for my environment.  I can also use link-local addressing on
> my content farm LANs and route subnets to my content boxes, if that is
> somehow more practical than using a smaller subnet.
> 
Yes, you can bring as much of the pain from IPv4 forward into IPv6
as you like. You can also commit many other acts of masochism.
Personally, I prefer to approach IPv6 as a way to reduce some of
the more painful aspects of IPv4, such as undersized subnets,
having to renumber or add prefixes for growth, limited aggregation,
NAT, and more.

>> If you are a service provider where practically all of your links are
>> point to points, sure.
> 
> No, you can avoid configuring /64s if you don't need SLAAC.  Who needs
> SLAAC?  I don't.  It has absolutely no place in any of my
> environments.  It seems to me that DHCPv6 will do everything which
> SLAAC does, and everything SLAAC forgot about.  The "complexity"
> argument is pretty much indefensible when the trade-off is configuring
> DHCPv6 vs turning a bunch of router knobs and hoping no one ever
> targets your LANs with an NDP DoS.
> 
SLAAC is a very useful and convenient way to deal with client
networks. I would agree it's of limited use in a content provider
scenario, but, there is utility to /64s beyond just SLAAC. Yes, they
are a hard requirement for SLAAC.

>> We didn't need much more host addressing, we needed more subnet
>> addressing.  I would have settled for 16 bits of host addressing and 112
>> bits of subnet addressing and I suppose nothing prevents me from doing
>> that except none of the standard IPv6 automatic stuff would work
>> anymore.
> 
> None of that "standard IPv6 automatic stuff" works today, anyway.  The
> state of IPv6 support on end-user CPE generally ranges from
> non-existent to untested to verified-to-be-broken.  This is the only
> place in your network where /64 can offer any value, and currently,
> CPE is just not there.  Even the latest Cisco/Linksys CPE does not
> support IPv6.  Sure, that'll change; but what won't change is the
> total lack of any basis for configuring /64 LANs for "content farms"
> or any similar non-end-user, non-dynamic segments.
> 
As someone using SLAAC in a number of environments, I'm confused
by this statement. It seems to be working quite well in many places
and end-user residential networks are certainly not the only places
where it is useful.

Yes, residential end-user CPE is rather limited and somewhat less
than ideal today. I would argue that there are probably at least as
many end-user hosts on non-residential networks that could
take advantage of SLAAC if the administrators wanted to.

> I don't want 16 bits of host addressing.  I want to choose an
> appropriate size for each subnet.  Why?  Because exactly zero of my
> access routers can handle 2**16 NDP entries, let alone 2**16 entries
> on multiple interfaces/VLANs.  I would like to see much larger ARP/NDP
> tables in layer-3 switches, and I think vendors will deliver on that,
> but I doubt we'll soon see even a 10x increase from typical table
> sizes of today.  VPS farms are already pushing the envelope with IPv4,
> where customers are already used to conserving addresses.  Guess what,
> customers may still have to conserve addresses with IPv6, not because
> the numbers themselves are precious, but because the number of ARP/NDP
> entries in the top-of-rack or distribution switch is finite.
> 
What do your access routers have to do with your content farm?
Sounds like you've got some pretty darn small access routers as well
if they can't handle 64k NDP entries. Yes, larger tables in switches
would be a good thing, but, I hardly think that's a reason to use
smaller netmasks.

Most of the top-of-rack switches I'm aware of have no problem doing
at least 64k NDP/ARP entries. Many won't do more than that, but,
most will go at least that far.

>> And again, are you talking about all the way down to the host subnet
>> level?  I suppose I could configure server fa

Re: estimation of number of DFZ IPv4 routes at peak in the future

[Justin Krejci]

On Wed, 2011-03-09 at 09:32 -0500, John Curran wrote:
> On Mar 9, 2011, at 12:43 AM, Majdi S. Abbas wrote:
> > On Wed, Mar 09, 2011 at 12:44:05PM +0900, Randy Bush wrote:
> >> i am more of a pessimist.  i suspect that there will be enough v4-only
> >> destinations out there that multi-homed enterprises fronting onto 
> >> dual-stack backbones will announce teenie bits of v4 so they can nat64.
> > 
> >I'll take this one a little further.
> > 
> >I suspect that as we reach exhaustion, more people will be
> > forced to break space out of their provider's v4 aggregates, and
> > announce them, and an unfiltered DFZ may well approach the 'million'
> > entries some vendors now claim to support.
> 
> This matches my personal view (and could be viewed as 
> "success" compared to the 5M estimate of Mr. Herrin...)
> 
> /John

Are people going to be relying on using default-routing then in the
future if they don't upgrade routers to handle large routing table
growth? Or perhaps forgo dual-stack and have a separate physical IPv6
BGP network from IPv4? Are there any other strategies?

The Cidr Report

[cidr-report]

This report has been generated at Fri Mar 11 21:11:52 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  PrefixesCIDR Agg
04-03-11350670  205614
05-03-11351328  205558
06-03-11351081  205642
07-03-11351367  205780
08-03-11351530  205762
09-03-11351488  205962
10-03-11351724  206002
11-03-11351885  205736


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

 --- 11Mar11 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 352175   205734   14644141.6%   All ASes

AS6389  3680  264 341692.8%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS4323  2575  407 216884.2%   TWTC - tw telecom holdings,
   inc.
AS19262 1830  282 154884.6%   VZGNI-TRANSIT - Verizon Online
   LLC
AS4766  2421  911 151062.4%   KIXS-AS-KR Korea Telecom
AS6478  1538  204 133486.7%   ATT-INTERNET3 - AT&T Services,
   Inc.
AS22773 1281   89 119293.1%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS10620 1384  208 117685.0%   Telmex Colombia S.A.
AS4755  1475  374 110174.6%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS1785  1795  764 103157.4%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS28573 1237  316  92174.5%   NET Servicos de Comunicao S.A.
AS18566 1524  613  91159.8%   COVAD - Covad Communications
   Co.
AS7545  1594  728  86654.3%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS24560 1120  281  83974.9%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS18101  935  154  78183.5%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS6503  1183  428  75563.8%   Axtel, S.A.B. de C.V.
AS4808  1050  323  72769.2%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS7303   919  195  72478.8%   Telecom Argentina S.A.
AS3356  1182  490  69258.5%   LEVEL3 Level 3 Communications
AS8151  1243  562  68154.8%   Uninet S.A. de C.V.
AS11492 1311  631  68051.9%   CABLEONE - CABLE ONE, INC.
AS17488  944  272  67271.2%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS4780   864  229  63573.5%   SEEDNET Digital United Inc.
AS17676  657   70  58789.3%   GIGAINFRA Softbank BB Corp.
AS855636   58  57890.9%   CANET-ASN-4 - Bell Aliant
   Regional Communications, Inc.
AS17908  623   67  55689.2%   TCISL Tata Communications
AS14420  644  104  54083.9%   CORPORACION NACIONAL DE
   TELECOMUNICACIONES - CNT EP
AS22561  861  325  53662.3%   DIGITAL-TELEPORT - Digital
   Teleport Inc.
AS3549   900  370  53058.9%   GBLX Global Crossing Ltd.
AS7552   620  101  51983.7%   VIETEL-AS-AP Vietel
   Corporation
AS9498   773  262  51166.1%   BBIL-AP BHARTI Airtel Ltd.

Total  38799100822871774.0%   Top 30 total


Possible Bogus Routes

1.5.0.0/16  

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 03-Mar-11 -to- 10-Mar-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS45595   23891  1.5%  66.2 -- PKTELECOM-AS-PK Pakistan 
Telecom Company Limited
 2 - AS23966   23516  1.5%  70.4 -- LDN-AS-PK LINKdotNET Telecom 
Limited
 3 - AS26210   23379  1.4% 135.9 -- AXS Bolivia S. A.
 4 - AS32528   17323  1.1%2165.4 -- ABBOTT Abbot Labs
 5 - AS671315863  1.0%  27.1 -- IAM-AS
 6 - AS982915212  0.9%  15.2 -- BSNL-NIB National Internet 
Backbone
 7 - AS35931   12715  0.8%2119.2 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 8 - AS24560   11343  0.7%  10.0 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
 9 - AS17974   11294  0.7%   7.9 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
10 - AS949811141  0.7%  14.3 -- BBIL-AP BHARTI Airtel Ltd.
11 - AS14420   10784  0.7%  16.7 -- CORPORACION NACIONAL DE 
TELECOMUNICACIONES - CNT EP
12 - AS840210706  0.7%   6.0 -- CORBINA-AS Corbina Telecom
13 - AS252209517  0.6% 732.1 -- GLOBALNOC-AS Averbo GmbH
14 - AS174888066  0.5%   8.5 -- HATHWAY-NET-AP Hathway IP Over 
Cable Internet
15 - AS7491 7756  0.5%  84.3 -- PI-PH-AS-AP PI-PHILIPINES
16 - AS8452 7575  0.5%   8.6 -- TE-AS TE-AS
17 - AS5800 7144  0.4%  30.8 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
18 - AS197437017  0.4%1002.4 -- 
19 - AS236966959  0.4% 869.9 -- FIRSTASIANET-AS-ID PT Asia 
Utama.
20 - AS210  6885  0.4%   5.1 -- WEST-NET-WEST - Utah Education 
Network


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS32528   17323  1.1%2165.4 -- ABBOTT Abbot Labs
 2 - AS35931   12715  0.8%2119.2 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 3 - AS178742013  0.1%2013.0 -- NPC-AS-KR National Pension 
Corporation
 4 - AS496001246  0.1%1246.0 -- LASEDA La Seda de Barcelona, S.A
 5 - AS197437017  0.4%1002.4 -- 
 6 - AS101981820  0.1% 910.0 -- CUP-AS-KR Catholic University 
of Pusan
 7 - AS236966959  0.4% 869.9 -- FIRSTASIANET-AS-ID PT Asia 
Utama.
 8 - AS35870 850  0.1% 850.0 -- PHI-CCR-BACKBONE - Public 
Health Institute California Cancer Registry
 9 - AS252209517  0.6% 732.1 -- GLOBALNOC-AS Averbo GmbH
10 - AS285192042  0.1% 680.7 -- Universidad Autonoma de 
Guadalajara, A.C.
11 - AS22288 538  0.0% 538.0 -- RFBKCORP - Republic First 
Bancorp, Inc.
12 - AS36591 371  0.0% 371.0 -- PRT - PixelRiver
13 - AS40607 364  0.0% 364.0 -- HCPL-7-ASN - HALL CAPITAL 
PARTNERS, LLC
14 - AS46167 361  0.0% 361.0 -- LANDSERVICESUSA - Land Services 
USA, Inc
15 - AS48377 322  0.0% 322.0 -- CEB-AS Credit Europe Bank 
Ukraine OOO
16 - AS42292 308  0.0% 308.0 -- CREDITWESTBANK CJSC "CREDITWEST 
BANK"
17 - AS38757 584  0.0% 292.0 -- ICONPLN-ID-AP PT. Indonesia 
Comnets Plus
18 - AS39348 584  0.0% 292.0 -- TYACHIV-AS Initiativa Ltd.
19 - AS522601668  0.1% 278.0 -- Télécommunications de Haití 
(Teleco)
20 - AS27771 541  0.0% 270.5 -- Instituto Venezolano de 
Investigaciones Cientificas


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 85.197.100.0/229504  0.6%   AS25220 -- GLOBALNOC-AS Averbo GmbH
 2 - 130.36.34.0/24 8658  0.5%   AS32528 -- ABBOTT Abbot Labs
 3 - 130.36.35.0/24 8658  0.5%   AS32528 -- ABBOTT Abbot Labs
 4 - 63.211.68.0/22 8316  0.5%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 5 - 202.92.235.0/247485  0.4%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 6 - 221.121.96.0/194999  0.3%   AS7491  -- PI-PH-AS-AP PI-PHILIPINES
 7 - 198.140.43.0/244095  0.2%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 8 - 203.192.205.0/24   3687  0.2%   AS17665 -- IN2CABLE-AP AS Number of 
In2cable.com (India) Ltd.
 AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 9 - 68.65.152.0/22 3443  0.2%   AS11915 -- TELWEST-NETWORK-SVCS-STATIC - 
TEL WEST COMMUNICATIONS LLC
10 - 206.184.16.0/243186  0.2%   AS174   -- COGENT Cogent/PSI
11 - 202.153.174.0/24   3017  0.2%   AS17408 -- ABOVE-AS-AP AboveNet 
Communications Taiwan
12 - 208.54.82.0/24 2421  0.1%   AS701   -- UUNET - MCI Communications 
Services, Inc. d/b/a Verizon Business
13 - 211.173.99.0/242013  0.1%   AS17874 -- NPC-AS-KR National Pension 
Corporation
14 - 204.154.140.0/24   1757  0.1%   AS5050  -- PSC-EXT - Pittsburgh 
Supercomputing Center

Re: ipv6 question

[Jason Bertoch]

On 2011/03/11 3:51 PM, ann kok wrote:

ping6 -I eth0 fe80::20c:29ff:fe3c:92a1
connect: Cannot assign requested address


Maybe duplicate address detection?  Are you statically assigning this 
address?  Have you checked your kernel log?


--
/Jason

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Pete Carah]

On 03/11/2011 04:05 PM, Joe Maimon wrote:
>
>
> Leo Bicknell wrote:
>
>> Three people have now mailed me privately saying that DAD does not
>> provide a way to select a second address if your first choice is not
>> in use.
>
> So fix that as well while we are at it, how bout it? Its code, not stone.
So it is simple, use privacy (3041) addresses scaled appropriately for
the appropriate
netmask...  remember the last D in DAD is detection; what you do about it is
in another protocol.

-- Pete

>
>
>
>

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Joe Maimon]

Leo Bicknell wrote:


Three people have now mailed me privately saying that DAD does not
provide a way to select a second address if your first choice is not
in use.


So fix that as well while we are at it, how bout it? Its code, not stone.

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Nick Hilliard]

On 11/03/2011 19:37, Mikael Abrahamsson wrote:

What problem are you trying to solve by not having every subnet being a
/64 ?


nd cache exhaustion?  Personally, I'm rather concerned about this, and you 
should be too, given the overlapping spheres of our interests. 
Particularly as there is no DAI equivalent for ipv6 on any switch vendor 
roadmap that i've seen.


Nick

Re: ipv6 question

[ann kok]

Hi Jason

Thank you. Can I know what is wrong?

ping6 -I eth0 fe80::20c:29ff:fe3c:92a1
connect: Cannot assign requested address

Thank you

--- On Fri, 3/11/11, Jason Bertoch  wrote:

> From: Jason Bertoch 
> Subject: Re: ipv6 question
> To: nanog@nanog.org
> Received: Friday, March 11, 2011, 3:41 PM
> On 2011/03/11 3:36 PM, ann kok
> wrote:
> > What is this meaning?
> >
> > ping6 -l eth0 fe80::20c:29ff:fe3c:92a1
> > ping: bad preload value, should be 1..65536
> 
> That was a capital "i" not a lower case "L". man ping6
> -- 
> /Jason
> 
> 

Re: ipv6 question

[Jason Bertoch]

On 2011/03/11 3:36 PM, ann kok wrote:

What is this meaning?

ping6 -l eth0 fe80::20c:29ff:fe3c:92a1
ping: bad preload value, should be 1..65536


That was a capital "i" not a lower case "L". man ping6
--
/Jason

Data request

[Ramdas Pophale]

Dear all,

I am looking for some data to do network analysis for a research project.
For a small network..

1. topology related data between different nodes of a network such as
obtained from traceroute probes
2. attack data for the same network, could be non-specific scanning or DDOS
and such
3. performance related data for the same network. Latency information may
be.

I would have liked to have the data for a couple of networks (~100 to ~1000
nodes) over a six month period. It's alright if the IP addresses are
anonymized.

Hopefully, this clarifies the requirements. I would have imagined that a
network administrator would have access to such data. If someone is willing
to share/sell it, that would be great. Any suggestions on the matter would
be appreciated.

Thanks for your time.

Regards,
Ramdas.

Re: ipv6 question

[ann kok]

Hi

What is this meaning?

ping6 -l eth0 fe80::20c:29ff:fe3c:92a1
ping: bad preload value, should be 1..65536

Thank you


--- On Fri, 3/11/11, Jason Bertoch  wrote:

> From: Jason Bertoch 
> Subject: Re: ipv6 question
> To: nanog@nanog.org
> Received: Friday, March 11, 2011, 3:31 PM
> On 2011/03/11 3:19 PM, ann kok
> wrote:
> > Thank you. I try your way.  the ipv6 address is
> on eth0 interface.
> >
> > I try to run ping6 the fe80::20c:29ff:fe3c:92a1%eth0
> >
> > lt is same problem!
> 
> Try ping6 -I eth0 fe80::20c:29ff:fe3c:92a1
> 
> -- 
> /Jason
> 
> 

Re: ipv6 question

[Jason Bertoch]

On 2011/03/11 3:19 PM, ann kok wrote:

Thank you. I try your way.  the ipv6 address is on eth0 interface.

I try to run ping6 the fe80::20c:29ff:fe3c:92a1%eth0

lt is same problem!


Try ping6 -I eth0 fe80::20c:29ff:fe3c:92a1

--
/Jason

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Richard A Steenbergen]

On Fri, Mar 11, 2011 at 12:55:33PM -0600, James Stahr wrote:
> link-local address.  Then I realized, why even assign a global in the 
> first place?  Traceroutes replies end up using the loopback. BGP will 
> use loopbacks.  So is there any obvious harm in this approach that I'm 
> missing?

Traceroute replies most assuredly do NOT use loopbacks on most networks, 
and it would make troubleshooting massively more difficult if this was 
the only option. Imagine any kind of complex network where there is more 
than one link between a pair of routers (and don't just picture your own 
internal network, but imagine customers connecting to their ISPs as 
well) , and now tell me how you plan on identifying a particular link 
with a traceroute. The two words that best sum this up would be "epic 
disaster".

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: ipv6 question

[ann kok]

Hi

Thank you. I try your way.  the ipv6 address is on eth0 interface.

I try to run ping6 the fe80::20c:29ff:fe3c:92a1%eth0

lt is same problem!

Any idea?

Thank you


2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:3c:92:a1 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.12/24 brd 192.168.1.255 scope global eth0
inet6 fe80::20c:29ff:fe3c:92a1/64 scope link tentative 
   valid_lft forever preferred_lft forever


# ping6  fe80::20c:29ff:fe3c:92a1
connect: Invalid argument
# ping6  fe80::20c:29ff:fe3c:92a1%eth0
connect: Invalid argument


--- On Fri, 3/11/11, valdis.kletni...@vt.edu  wrote:

> From: valdis.kletni...@vt.edu 
> Subject: Re: ipv6 question
> To: "ann kok" 
> Cc: nanog@nanog.org
> Received: Friday, March 11, 2011, 2:21 PM
> On Fri, 11 Mar 2011 11:15:36 PST, ann
> kok said:
> 
> > inet6 addr: fe80::20c:29ff:fe3c:92a1/64 Scope:Link
> 
> This is a link level address, only valid on one
> interface.  So you need to look
> at which interface it is attached to in the ifconfig
> output.
> 
> > ping6 fe80::20c:29ff:fe3c:92a1
> > connect: Invalid argument
> 
> ping6 wants the interface name for link-scope addresses,
> because on some
> hardware setups, the same MAC is used for all interfaces,
> which means that
> each interface has the same link-scope address.  So to
> disambiguate it,
> you have to feed it the interface name so it knows which
> link to use.
> 
> On my laptop, I currently have:
> 
> wlan0     Link encap:Ethernet 
> HWaddr 00:24:D6:53:C5:BA
>     inet6 addr: fe80::224:d6ff:fe53:c5ba/64
> Scope:Link
> 
> % ping  fe80::224:d6ff:fe53:c5ba%wlan0
>  ping6  fe80::224:d6ff:fe53:c5ba%wlan0
> PING
> fe80::224:d6ff:fe53:c5ba%wlan0(fe80::224:d6ff:fe53:c5ba) 56
> data bytes
> 64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=1 ttl=64
> time=0.072 ms
> 64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=2 ttl=255
> time=0.081 ms
> 64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=3 ttl=255
> time=0.090 ms
> ^C
> --- fe80::224:d6ff:fe53:c5ba%wlan0 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time
> 1999ms
> rtt min/avg/max/mdev = 0.072/0.081/0.090/0.007 ms
> 
> 

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Leo Bicknell]

In a message written on Fri, Mar 11, 2011 at 10:58:09AM -0800, Leo Bicknell 
wrote:
> That said, ND has built into it DAD - Duplicate Address Detection.
> There is already an expectation that there will be collisions, and
> the protocols to detect them are already in place.  I see little
> to no reason you couldn't use a different length subnet (like the
> /96 in your example), randomly select an address and do DAD to see
> if it is in use.  Indeed, this is pretty much how AppleTalk back
> in the day worked (with a 16 bit number space).

Three people have now mailed me privately saying that DAD does not
provide a way to select a second address if your first choice is not
in use.

What I am basically suggesting is to use the same method in RFC 3041 as
the default way to get an address.  That is the protocol is already
defined and deployed, it's just today it's used for a second (third,
fourth, ...) address.

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


pgpuPPP4r2YpL.pgp
Description: PGP signature

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Mikael Abrahamsson]

On Fri, 11 Mar 2011, Jeff Wheeler wrote:

I've got three feasible "fixes" to the NDP flooding problem.  One is 
dead simple: don't configure /64 LANs.  How hard is that?  It's a lot 
easier than the alternatives.


What problem are you trying to solve by not having every subnet being a 
/64 ?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Jeff Wheeler]

On Fri, Mar 11, 2011 at 1:07 PM,   wrote:
> Feel free to explain how SLAAC should work on a /96 with 32 bits of host 
> address
> (or any amount smaller than the 48 bits most MAC addresses provide).  Remember
> in your answer to deal with collisions.

Why should SLAAC dictate the size of *every subnet* on the IPv6
Internet?  This is what people who I label "IPv6 Fundamentalists" wish
to do.  They refuse to admit that their ideas were conceived in the
mid-90s, that technology has advanced a great deal since that time,
and ARP/NDP is a real limit now, while VLSM is no longer a tough
challenge (vendors have had a couple decades to make it work really
well!)

I think there are a lot of people who throw around the SLAAC argument
like it's actually good for something.  Do these people know what
SLAAC does?  For core networks, it doesn't do anything.  For
hosting/datacenter networks and cluster/VPS environments, again, it
doesn't do anything.  Zero benefit.  You probably don't configure
these things using DHCP today.  Wait, you do?  Oh, it's a good thing
we've got DHCPv6, which clearly can run alongside your DHCP for IPv4.

Is SLAAC for end-user access networks?  Not so much.  See recent
discussions on this list about things which are not included in SLAAC
that DHCPv6 does do today.  SLAAC can provide an advantage if you can
live without those things, but that advantage is limited to one thing:
the subnet doesn't need a DHCPv6 server (or proxy/forwarding of
packets to same.)  IPv4 has gotten along just fine for a long time
with both full-featured and light-weight DHCP servers, and statically
configured subnets.  Is SLAAC solving any problem?  Sure, for some
situations, like SOHO networks, it's a nice option, but it's just
that, an option.  It isn't needed.

Is SLAAC for fully peer-to-peer networks, with no central gateway?
No.  To function, SLAAC requires an RA message from something that
decides it is a router.  It isn't going to facilitate a headless,
ad-hoc network to support the next revolution with peer-to-peer cell
phones.

So what we know is that the sole arguments from "IPv6 Fundamentalists"
in favor of /64 LANs are
* VLSM is hard (it isn't; vendors are really good at it now, otherwise
IPv4 wouldn't work)
* SLAAC needs it to work (not all LANs need SLAAC)
* it's the standard (more on this below)

I believe everything except the "it's the standard" argument is fully
and completely debunked.  If anyone disagrees with me, feel free to
correct me, or argue your point until you are blue in the face.  I
have often been reminded that I should have been more vocal about this
matter 10+ years ago, but frankly, I thought vendors, large ISPs,
veterans with more public credibility than myself, or the standards
folks themselves, would have straightened this out a long time ago.

If you can decide for yourself that VLSM is easy and you trust your
vendor to do it right (if you don't, summarize to /64 towards your
core, or do one great thing IPv6 allows us to do, and summarize to
*even shorter* prefixes towards your core, and carry fewer routes in
core) then you are half-way there.

If you realize SLAAC isn't a tool for your VPS farm or on your
backbone link-nets, you're all the way there.

At this point, you can deploy your IPv6 without it being broken by
design.  The only thing broken here is the "Fundamentalists," who are
stuck in a mid-1990s mindset.  These guys need to get out of the way,
because they are impeding deployment (for those smart enough to
recognize this problem) and they are creating an almost certain need
for a future re-design (for those who aren't smart.)  This "future"
doesn't depend on anything except v6 actually getting deployed enough
to where DDoS happens over it at any appreciable scale.

In the current state of the Internet, it is certain that this problem
will happen.  No visible progress has been made on solving it, except
by guys like myself who are happy to cry "the sky is falling,"
configure our networks in a "non-standard" way, and tell the standards
folks they are wrong.  The Cisco knob is "progress" only in that Cisco
recognizes customers are concerned about this problem and allow them
to steer their failure mode.  If the DDoS happens before vendors
provide a real solution, or before standards are revised or thrown
out, you can thank those of us on the "sky is falling" side of this
argument for testing the work-around (by never having exposed
ourselves to the problem in the first place.)

> It's one thing to say "it should be redesigned". It's another matter entirely 
> to actually
> come up with a scheme that doesn't suck even harder than "screw it, it's a 
> /64".

This is true.  I think the price of energy is continuing to rise and
our future is very uncertain as a result.  I don't know how to fix it.
 Does that mean I should keep my opinion to myself?  Of course not.
Recognizing a problem is the first step on the path to a solution.

I imagine the same arguments taking place before

Re: ipv6 question

[Valdis . Kletnieks]

On Fri, 11 Mar 2011 11:15:36 PST, ann kok said:

> inet6 addr: fe80::20c:29ff:fe3c:92a1/64 Scope:Link

This is a link level address, only valid on one interface.  So you need to look
at which interface it is attached to in the ifconfig output.

> ping6 fe80::20c:29ff:fe3c:92a1
> connect: Invalid argument

ping6 wants the interface name for link-scope addresses, because on some
hardware setups, the same MAC is used for all interfaces, which means that
each interface has the same link-scope address.  So to disambiguate it,
you have to feed it the interface name so it knows which link to use.

On my laptop, I currently have:

wlan0 Link encap:Ethernet  HWaddr 00:24:D6:53:C5:BA
inet6 addr: fe80::224:d6ff:fe53:c5ba/64 Scope:Link

% ping  fe80::224:d6ff:fe53:c5ba%wlan0
 ping6  fe80::224:d6ff:fe53:c5ba%wlan0
PING fe80::224:d6ff:fe53:c5ba%wlan0(fe80::224:d6ff:fe53:c5ba) 56 data bytes
64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=1 ttl=64 time=0.072 ms
64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=2 ttl=255 time=0.081 ms
64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=3 ttl=255 time=0.090 ms
^C
--- fe80::224:d6ff:fe53:c5ba%wlan0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.072/0.081/0.090/0.007 ms



pgpkHDgW3pDcv.pgp
Description: PGP signature

Re: ipv6 question

[ann kok]

Hi

Then I won't use this ipv6 address 2001:db8:cafe:::12 for test

Acutually, I have one in eth0 when I run ifconfig -a

  inet6 addr: fe80::20c:29ff:fe3c:92a1/64 Scope:Link


but I also can't ping it

ping6 fe80::20c:29ff:fe3c:92a1
connect: Invalid argument



but ping6 ::1 is fine

ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=0 ttl=64 time=7.18 ms
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.050 ms



--- On Wed, 3/9/11, Karl Auer  wrote:

> From: Karl Auer 
> Subject: Re: ipv6 question
> To: nanog@nanog.org
> Received: Wednesday, March 9, 2011, 11:11 PM
> On Thu, 2011-03-10 at 11:43 +1100,
> Mark Andrews wrote:
> > In message <1299711449.2109.98.camel@karl>, Karl
> Auer writes:
> > > On Wed, 2011-03-09 at 09:01 -0600, imNet
> Administrator wrote:
> > > > Where are you pinging it from? also, the
> 2001:db8::/32 prefix is used
> > > > for "documentation purposes" and might be
> handled differently by the
> > > > TCP/IP stack.
> > > 
> > > Works fine in Linux - I've been using it (in an
> isolated training room
> > > setup) for years.
> > > 
> > > Regards, K.
> > 
> > It is not a good idea to use the documentation prefix
> for anything
> > other than documentation.  How hard is it to
> generate a ULA and use
> > it?
> 
> I suppose I took/take the view that it *is*, in a sense,
> being used for
> documentation.
> 
> The network is a training network, isolated from the
> Internet, and used
> for demonstration purposes. It's a good way to engrave the
> doco prefix
> in the students' minds. It also allows all the slides,
> exercises and
> other documentation to use the documentation prefix and yet
> directly
> match the demonstration network.
> 
> ULA prefixes have little internal logic and are hard to
> remember. Not a
> problem in production, but just another barrier in a
> training
> environment. "2001:db8::/32" is very easy to remember (I
> guess that's
> the point) and easy to add easy-to-use subnets into.
> 
> However, I do appreciate that it's a bit of an edge case.
> In my training
> I specifically draw the students' attention to this fact.
> 
> Thanks, K.
> 
> -- 
> ~~~
> Karl Auer (ka...@biplane.com.au) 
>              
>    +61-2-64957160 (h)
> http://www.biplane.com.au/kauer/     
>          
>    +61-428-957160 (mob)
> 
> GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED
> 5736 F687
> Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B
> CD97 0156
> 

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Tim Durack]

On Fri, Mar 11, 2011 at 1:55 PM, James Stahr  wrote:

> Is anyone else considering only using link local for their PtoP links?  I
> realized while deploying our IPv6 infrastructure that OSPFv3 uses the
> link-local address in the routing table and than the global address, so if I
> want to have a routing table which makes sense, I need to statically assign
> a global address AND the link-local address.  Then I realized, why even
> assign a global in the first place?  Traceroutes replies end up using the
> loopback. BGP will use loopbacks.  So is there any obvious harm in this
> approach that I'm missing?
>

For now I have allocated /64s per p-t-p, but I'm doing "ipv6 unnumbered
loopback0"

I quite like how the core route table looks. It also lets me avoid "The
Point to Point Wars" :-)

Maybe there will be a good reason to go back and slap globals on there, but
I've not been convinced yet.

-- 
Tim:>

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Leo Bicknell]

In a message written on Fri, Mar 11, 2011 at 01:07:15PM -0500, 
valdis.kletni...@vt.edu wrote:
> On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said:
> > rfc3927 does not require 64 bits and works sufficiently well wherever it 
> > is employed. SLAAC should be redesigned to be configurable to work with 
> > however many bits are available to it and it should be a standard 
> > feature to turn that knob all the way from on - off with 128 bit stops 
> > in between.
> 
> Feel free to explain how SLAAC should work on a /96 with 32 bits of host 
> address
> (or any amount smaller than the 48 bits most MAC addresses provide).  Remember
> in your answer to deal with collisions.

Well, I at least think an option should be a /80, using the 48 bits
of MAC directly.  This generates exactly the same collision potential
as today we have with a /64 and an EUI-64 constructed from an EUI-48
ethernet address.  The router is already sending RA's for SLAAC to
work, sending along one of a well-known set of masks would be a
relatively minor modification.

That said, ND has built into it DAD - Duplicate Address Detection.
There is already an expectation that there will be collisions, and
the protocols to detect them are already in place.  I see little
to no reason you couldn't use a different length subnet (like the
/96 in your example), randomly select an address and do DAD to see
if it is in use.  Indeed, this is pretty much how AppleTalk back
in the day worked (with a 16 bit number space).

The probability of collision is pretty low, and the penalty/recovery
(picking a new address and trying again) is rather quick and cheap.

If a service provider is going to end up giving me a /64 at home (I
know, a whole different argument) I'd vastly prefer to use /80 or /96
subnets with either of these methods, and still be able to subnet the
space.  I suspect if /64's are given out one or both will come to be
"standard".

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


pgp9s6W9xlusw.pgp
Description: PGP signature

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[James Stahr]

At 01:33 AM 3/11/2011, Owen DeLong wrote:


On Mar 10, 2011, at 11:22 PM, Dobbins, Roland wrote:

>
> On Mar 11, 2011, at 2:02 PM, Owen DeLong wrote:
>

>> Frankly, unless you have parallel links, there isn't a definite 
need to even number PtoP links for IPv6.
>> Every thing you need to do with an interface specific address on 
a PtoP link can be done with link local.

>
> Which is why IP unnumbered caught on so well in IPv4-land, heh?
>
There's a HUGE difference between IP unnumbered and link-local.

Frankly, absent parallel links, there was a lot to be said for IP unnumbered
and I think that if people had better understood the implications of where and
when it was a good vs. bad idea and tied it properly to loopbacks instead
of $RANDOM_INTERFACE, it might have caught on better.

Owen



Is anyone else considering only using link local for their PtoP 
links?  I realized while deploying our IPv6 infrastructure that 
OSPFv3 uses the link-local address in the routing table and than the 
global address, so if I want to have a routing table which makes 
sense, I need to statically assign a global address AND the 
link-local address.  Then I realized, why even assign a global in the 
first place?  Traceroutes replies end up using the loopback. BGP will 
use loopbacks.  So is there any obvious harm in this approach that I'm missing?


-James

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Joe Maimon]

valdis.kletni...@vt.edu wrote:

On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said:


rfc3927 does not require 64 bits and works sufficiently well wherever it
is employed. SLAAC should be redesigned to be configurable to work with
however many bits are available to it and it should be a standard
feature to turn that knob all the way from on - off with 128 bit stops
in between.


Feel free to explain how SLAAC should work on a /96 with 32 bits of host address
(or any amount smaller than the 48 bits most MAC addresses provide).  Remember
in your answer to deal with collisions.


Is there something fundamentally wrong with rfc3927?



It's one thing to say "it should be redesigned". It's another matter entirely 
to actually
come up with a scheme that doesn't suck even harder than "screw it, it's a /64".



I dont have to, its already been done. In ipv4.

Joe

Re: voip vs tdm fallout

[Daniel Belin]

On Fri, Mar 11, 2011 at 1:42 PM, Seth Mattinen  wrote:
>My question would be what communications methods are working *right now*
>in the inital stages? (I heard cellular was down.) Past that, what's
>seeing service restoration first?

>From what I've heard, most of the cellular networks and wireless
infrastructure is down. Thats what I heard recently, I don't know if
anything has come back up. On a related note, whats going on with JUSCN,
which has a landing in Shima? I heard there was damage, but I don't have
hard facts as of yet.

On Fri, Mar 11, 2011 at 1:42 PM, Seth Mattinen  wrote:

> On 3/11/2011 10:29, Michael Thomas wrote:
> >
> > Is it too soon to start to compare and contrast how voip
> > held up vs. tdm? Back in the old days circa mid to late
> > 90's, there was a lot of hand wringing about whether
> > voip would be up to the task of dealing with a massive
> > emergency. Well, we certainly have one now in Japan
> > on almost every front imaginable.
> >
> > Is voice such a small fraction of data that the larger
> > issues of cuts, electricity, etc make it moot, or has
> > there been some appreciable differences between the
> > two's ability to stay in usable service?
> >
>
> My question would be what communications methods are working *right now*
> in the inital stages? (I heard cellular was down.) Past that, what's
> seeing service restoration first?
>
> ~Seth
>
>


-- 
Sincerely,

Daniel F. Belin

Re: voip vs tdm fallout

[Seth Mattinen]

On 3/11/2011 10:29, Michael Thomas wrote:
> 
> Is it too soon to start to compare and contrast how voip
> held up vs. tdm? Back in the old days circa mid to late
> 90's, there was a lot of hand wringing about whether
> voip would be up to the task of dealing with a massive
> emergency. Well, we certainly have one now in Japan
> on almost every front imaginable.
> 
> Is voice such a small fraction of data that the larger
> issues of cuts, electricity, etc make it moot, or has
> there been some appreciable differences between the
> two's ability to stay in usable service?
> 

My question would be what communications methods are working *right now*
in the inital stages? (I heard cellular was down.) Past that, what's
seeing service restoration first?

~Seth

Weekly Routing Table Report

[Routing Analysis Role Account]

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-st...@lists.apnic.net

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

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 12 Mar, 2011

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

Analysis Summary


BGP routing table entries examined:  350049
Prefixes after maximum aggregation:  157788
Deaggregation factor:  2.22
Unique aggregates announced to Internet: 172931
Total ASes present in the Internet Routing Table: 36036
Prefixes per ASN:  9.71
Origin-only ASes present in the Internet Routing Table:   31061
Origin ASes announcing only one prefix:   14941
Transit ASes present in the Internet Routing Table:4975
Transit-only ASes present in the Internet Routing Table:124
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  31
Max AS path prepend of ASN (36992)   29
Prefixes from unregistered ASNs in the Routing Table:   392
Unregistered ASNs in the Routing Table: 178
Number of 32-bit ASNs allocated by the RIRs:   1191
Prefixes from 32-bit ASNs in the Routing Table:   2
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:252
Number of addresses announced to Internet:   2467281824
Equivalent to 147 /8s, 15 /16s and 187 /24s
Percentage of available address space announced:   66.6
Percentage of allocated address space announced:   66.6
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   89.1
Total number of prefixes smaller than registry allocations:  145075

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:87220
Total APNIC prefixes after maximum aggregation:   29669
APNIC Deaggregation factor:2.94
Prefixes being announced from the APNIC address blocks:   84042
Unique aggregates announced from the APNIC address blocks:36224
APNIC Region origin ASes present in the Internet Routing Table:4339
APNIC Prefixes per ASN:   19.37
APNIC Region origin ASes announcing only one prefix:   1194
APNIC Region transit ASes present in the Internet Routing Table:690
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 18
Number of APNIC addresses announced to Internet:  595474464
Equivalent to 35 /8s, 126 /16s and 56 /24s
Percentage of available APNIC address space announced: 75.5

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
   55296-56319, 131072-132095
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:140487
Total ARIN prefixes after maximum aggregation:71719
ARIN Deaggregation factor: 1.96
Prefixes being announced from the ARIN address blocks:   110994
Unique aggregates announced from the ARIN address blocks: 44983
ARIN Region origin ASes present in the Internet Routing Table:14247
ARIN Prefixes per ASN: 7.79
ARIN Region origin ASes announcing only one prefix:5417
ARIN Region transit ASes present in the Internet Routing Table:1472
Average ARIN Region AS path length visible: 4.0
Max ARIN Region AS path length visibl

Re: so big earthquake in JP

[George Herbert]

We're seeing damage in harbors on the west coast - live imagery of
Santa Cruz harbor with multiple piers broken up, boats loose, boats
sunk, from local geography focusing waves that were only 2-3 foot
surges (personal Ouch - I used to own a boat in that harbor).  Phone
reporting from Crescent City (northern california) indicating that the
latest surge up there is 8.1 feet just now - their harbor is
apparently pretty bad off.

I have no reports of fiber landings affected - along most coastal
beaches it's just an unusual wave surge height - but the surges are in
some locations getting to the point that they could do that.


-george


On Fri, Mar 11, 2011 at 10:19 AM, Scott Weeks  wrote:
>
>
> --- sur...@mauigateway.com wrote:
> --- t...@americafree.tv wrote:
>
> The tsunami was 1/2 meter in Kauai
> ---
>
> The road to the west side is still closed at Hanapepe.  No work today.  
> Yipeee! :-)
> ---
>
>
> Also, no real damage: 
> http://thegardenisland.com/news/local/article_6a515a9a-4bdb-11e0-a9b3-001cc4c03286.html
>
> "Doug Sears of the Grand Hyatt Kauai in Poipu told KHON around 3:30 a.m. that 
> there was "nothing exciting yet." He reported a "non-event" and said a minor 
> surge in the surf was observed.
>
> Reports around the island indicated only slight rises in water levels at 
> coastal areas.
>
> A 2.1-foot rise was recorded at Nawiliwli Harbor; 2.8 feet in Hanalei, 
> according to the National Weather Service. No damage was reported."
>
>
> scott
>
>



-- 
-george william herbert
george.herb...@gmail.com

voip vs tdm fallout

[Michael Thomas]

Is it too soon to start to compare and contrast how voip
held up vs. tdm? Back in the old days circa mid to late
90's, there was a lot of hand wringing about whether
voip would be up to the task of dealing with a massive
emergency. Well, we certainly have one now in Japan
on almost every front imaginable.

Is voice such a small fraction of data that the larger
issues of cuts, electricity, etc make it moot, or has
there been some appreciable differences between the
two's ability to stay in usable service?

Mike

Re: so big earthquake in JP

[Scott Weeks]

--- sur...@mauigateway.com wrote:
--- t...@americafree.tv wrote:

The tsunami was 1/2 meter in Kauai 
---

The road to the west side is still closed at Hanapepe.  No work today.  Yipeee! 
:-)
---


Also, no real damage: 
http://thegardenisland.com/news/local/article_6a515a9a-4bdb-11e0-a9b3-001cc4c03286.html

"Doug Sears of the Grand Hyatt Kauai in Poipu told KHON around 3:30 a.m. that 
there was "nothing exciting yet." He reported a "non-event" and said a minor 
surge in the surf was observed.

Reports around the island indicated only slight rises in water levels at 
coastal areas.

A 2.1-foot rise was recorded at Nawiliwli Harbor; 2.8 feet in Hanalei, 
according to the National Weather Service. No damage was reported."


scott

Re: so big earthquake in JP

[Scott Weeks]

--- t...@americafree.tv wrote:
From: Marshall Eubanks 

The tsunami was 1/2 meter in Kauai 
---



The road to the west side is still closed at Hanapepe.  No work today.  Yipeee! 
:-)

scott

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Valdis . Kletnieks]

On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said:

> rfc3927 does not require 64 bits and works sufficiently well wherever it 
> is employed. SLAAC should be redesigned to be configurable to work with 
> however many bits are available to it and it should be a standard 
> feature to turn that knob all the way from on - off with 128 bit stops 
> in between.

Feel free to explain how SLAAC should work on a /96 with 32 bits of host address
(or any amount smaller than the 48 bits most MAC addresses provide).  Remember
in your answer to deal with collisions.

It's one thing to say "it should be redesigned". It's another matter entirely 
to actually
come up with a scheme that doesn't suck even harder than "screw it, it's a /64".



pgpzoN07WarGf.pgp
Description: PGP signature

Re: so big earthquake in JP

[Shaun Bryant]

We can't bring up our satellite links that we use for point to point
classroom learning with another SciTech school in JP. Not sure if it is a
power issue on the other end or they are now out of alignment, but we can
normally bring up these camera's at will.  We have backup controls via 3G
and that is down as well and it has 12+ hours of power backup.

Shaun

*Shaun Bryant* * **I*  Director of Technology   * l  Denver School of
Science and Technology *







On Fri, Mar 11, 2011 at 7:43 AM, andrew.wallace <
andrew.wall...@rocketmail.com> wrote:

> Here is a forecast map of the Tsunami
>
> http://www.bbc.co.uk/news/world-asia-pacific-12715415
>
> Andrew
>
>
>
>
>

Re: Long Distance Dark Fiber

[Joel Jaeggli]

On 3/11/11 7:16 AM, Jeff Wheeler wrote:
> On Fri, Mar 11, 2011 at 9:25 AM, ML  wrote:
>> Would it be too crazy to buy a spool of fiber and splice the end of one pair
>> to the next pair and so on?  Won't be able to simulate 2200 miles of fiber
>> but it'll be a long span.
> 
> This is by no means crazy.  If you visit a laboratory where gear is
> tested, you'll find exactly that -- spools of fiber which can be
> connected together (through whatever splicing or patching method is
> desired for the simulation) to give the desired span length.  These
> usually look nicer than big spools of cable, and are even available in
> rack-mount enclosures with vendor logos. :)

one does not however do 2200 miles of terrestrial fiber simulation
without simulating regeneration as well.

Re: Long Distance Dark Fiber

[Jeff Wheeler]

On Fri, Mar 11, 2011 at 9:25 AM, ML  wrote:
> Would it be too crazy to buy a spool of fiber and splice the end of one pair
> to the next pair and so on?  Won't be able to simulate 2200 miles of fiber
> but it'll be a long span.

This is by no means crazy.  If you visit a laboratory where gear is
tested, you'll find exactly that -- spools of fiber which can be
connected together (through whatever splicing or patching method is
desired for the simulation) to give the desired span length.  These
usually look nicer than big spools of cable, and are even available in
rack-mount enclosures with vendor logos. :)

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Joe Maimon]

Jeff Wheeler wrote:


I'm glad SLAAC is an option, but that's all it is, an option.  /64
LANs must also be considered optional, and should be considered useful
only when SLAAC is desired.


That also could be optional, automatic host configuration does not 
actually require 64 bits, unless there is a naive assumption that DAD 
need not occur. Which it must always and for many reasons.


rfc3927 does not require 64 bits and works sufficiently well wherever it 
is employed. SLAAC should be redesigned to be configurable to work with 
however many bits are available to it and it should be a standard 
feature to turn that knob all the way from on - off with 128 bit stops 
in between.


And now DHCP-PD can start at any point in the connected hierarchy, 
working with whatever amount of space is available and not requiring 
complete upstream support.


I dont accept that IPv6 is set in stone. IPv4 wasnt/isnt set in stone 
and people were/are actually using it because they depend on it.


Joe

Re: so big earthquake in JP

[Dorian Kim]

On Fri, Mar 11, 2011 at 07:29:29AM -0700, Garret Picchioni wrote:
> Does anyone have any stats on route updates that might suggest the
> possibility of fiber on the ocean floor being damaged?

There are some submarine cable outages but I don't believe exact
locations of damage has been isolated. I suspect that this may take 
some time.

-dorian

Re: so big earthquake in JP

[Daniel Belin]

The BGP route between NLR and JGN and JGN2+ has been down for more than an
hour and a half.

On Fri, Mar 11, 2011 at 9:29 AM, Garret Picchioni wrote:

> Does anyone have any stats on route updates that might suggest the
> possibility of fiber on the ocean floor being damaged?
>
> On 3/11/11 7:19 AM, "Marshall Eubanks"  wrote:
>
> >
> >On Mar 11, 2011, at 9:08 AM, Marshall Eubanks wrote:
> >
> >>
> >> On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote:
> >>
> >>> Are we aware of how much the infrastructure has been damaged yet? Are
> >>>aftershocks still going?
> >>
> >>
> >> The tsunami was 1/2 meter in Kauai
> >>
> >> http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs
> >
> >This live feed from Honolulu indicates that Hawaii damage is minor so
> >far. The Tsunami is striking Hilo right now, and the Waikiki sea wall is
> >under water.
> >
> >http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1
> >
> >Regards
> >Marshall
> >
> >>
> >> ETA's for the West Coast are around 7:00 AM PST
> >>
> >>
> >>
> http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-
> >>arrival-times-for-canadas-west-coast/article1938243/
> >>
> >>>
> >>> ---
> >>>
> >>> Daniel Belin
> >>>
> >>> On Mar 11, 2011, at 3:50 AM, Jeroen van Aart  wrote:
> >>>
>  Michael Painter wrote:
> > Christopher LILJENSTOLPE wrote:
> >> Pacific tsunami warning centre has confirmed a deep ocean tsunami.
> >>Three dart bouys have detected > 2 ft wave fronts. Warnings
> >> up for entire pacific basin except for Alaska/canada/us west coast.
> >>
> >> Official warming
> >> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.133222
> >>
> >> The tsunami was 1.3 meters at Midway Is., 1/2 meter at Kauai
> >>
> >> http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs
> >>
> >> Here is a live feed - it is striking Waikiki (with no real damage
> >>IFAICT, but it is dark) right now
> >>
> http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1
> >>
> >> ETA's for the West Coast are around 7:00 AM PST
> >>
> >>
> >>
> http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-
> >>arrival-times-for-canadas-west-coast/article1938243/
> >>
> >> Regards
> >> Marshall
> >>
> >>
> >>
> >> Chris
> > Tsunami sirens just went off on Maui.
> 
>  You may get information by going to forecast.weather.gov and
> searching for a location. i.e.:
> 
> 
> 
> http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&sit
> e=MFR&textField1=43.3667&textField2=-124.217&e=0
> 
>  Then click the Tsunami Watch link:
> 
> 
> http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=OR
> C011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch
> 
>  Also see:
>  http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000
> 
>  --
>  http://goldmark.org/jeff/stupid-disclaimers/
>  http://linuxmafia.com/~rick/faq/plural-of-virus.html
> 
> >>>
> >>>
> >>
> >>
> >>
> >
> >
>
>
>


-- 
Sincerely,

Daniel F. Belin

Switching Email

[Robert Shimonski]

I would like to opt out of this news list. 
Thanks you
 
 
Rob Shimonski
Information Technology
CARCO Group, Inc.
5000 Corporate Court, Suite 203
Holtsville, NY 11742
Phone 631-862-9300 Ext 455

This electronic communication (including attachments) contains privileged and 
confidential information intended only for the use of the named recipient. If 
you are not the intended recipient, you are prohibited from disseminating, 
distributing or copying this communication. If you have received this 
communication in error, please immediately notify us by return message or by 
telephone and delete this communication from your system. Thank you.

Re: so big earthquake in JP

[Garret Picchioni]

Does anyone have any stats on route updates that might suggest the
possibility of fiber on the ocean floor being damaged?

On 3/11/11 7:19 AM, "Marshall Eubanks"  wrote:

>
>On Mar 11, 2011, at 9:08 AM, Marshall Eubanks wrote:
>
>> 
>> On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote:
>> 
>>> Are we aware of how much the infrastructure has been damaged yet? Are
>>>aftershocks still going?
>> 
>> 
>> The tsunami was 1/2 meter in Kauai
>> 
>> http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs
>
>This live feed from Honolulu indicates that Hawaii damage is minor so
>far. The Tsunami is striking Hilo right now, and the Waikiki sea wall is
>under water.
>
>http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1
>
>Regards
>Marshall
>
>> 
>> ETA's for the West Coast are around 7:00 AM PST
>> 
>> 
>>http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-
>>arrival-times-for-canadas-west-coast/article1938243/
>> 
>>> 
>>> ---
>>> 
>>> Daniel Belin
>>> 
>>> On Mar 11, 2011, at 3:50 AM, Jeroen van Aart  wrote:
>>> 
 Michael Painter wrote:
> Christopher LILJENSTOLPE wrote:
>> Pacific tsunami warning centre has confirmed a deep ocean tsunami.
>>Three dart bouys have detected > 2 ft wave fronts. Warnings
>> up for entire pacific basin except for Alaska/canada/us west coast.
>> 
>> Official warming
>> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.133222
>> 
>> The tsunami was 1.3 meters at Midway Is., 1/2 meter at Kauai
>> 
>> http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs
>> 
>> Here is a live feed - it is striking Waikiki (with no real damage
>>IFAICT, but it is dark) right now
>> http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1
>> 
>> ETA's for the West Coast are around 7:00 AM PST
>> 
>> 
>>http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-
>>arrival-times-for-canadas-west-coast/article1938243/
>> 
>> Regards
>> Marshall
>> 
>> 
>> 
>> Chris
> Tsunami sirens just went off on Maui.
 
 You may get information by going to forecast.weather.gov and
searching for a location. i.e.:
 
 
http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&sit
e=MFR&textField1=43.3667&textField2=-124.217&e=0
 
 Then click the Tsunami Watch link:
 
http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=OR
C011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch
 
 Also see:
 http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000
 
 -- 
 http://goldmark.org/jeff/stupid-disclaimers/
 http://linuxmafia.com/~rick/faq/plural-of-virus.html
 
>>> 
>>> 
>> 
>> 
>> 
>
>

Re: Long Distance Dark Fiber

[ML]

On 3/10/2011 12:15 AM, nanog wrote:

Good Evening all.  I got an odd and somewhat crazy request from our
development group for a long haul OC48 connection for testing (they
specifically said from their office in Utah to the east coast and back)
with minimal jitter.  They need to be able to run their own framing Sonet
and WDM - don't ask me why, it doesn't make sense to me.  It would seem to
me that the last requirement would require a dark fiber?

So I've got several questions.

One, is there any provider that would provide us such a beast for only one
month?  I realize that the fact this is long haul OC48 would make the cost
astronomically high, and then throwing on the one month would make it even
more expensive

Two, is there any good way to simulate such a long distance link?  I know
such equipment exists for smaller links, but I haven't yet found anything
that'll do OC48 fiber.  I'm sure the cost would be high for the equipment,
however I'm betting it is *much* lower than the long distance link.

Three, could we sanely encapsulate their framing into GRE (or some other
such technology) and send it over an IP link and get SLAs to minimize the
jitter?

Offlist responses would be greatly appreciated.



Would it be too crazy to buy a spool of fiber and splice the end of one 
pair to the next pair and so on?  Won't be able to simulate 2200 miles 
of fiber but it'll be a long span.

Re: so big earthquake in JP

[Marshall Eubanks]

On Mar 11, 2011, at 9:08 AM, Marshall Eubanks wrote:

> 
> On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote:
> 
>> Are we aware of how much the infrastructure has been damaged yet? Are 
>> aftershocks still going?
> 
> 
> The tsunami was 1/2 meter in Kauai 
> 
> http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs

This live feed from Honolulu indicates that Hawaii damage is minor so far. The 
Tsunami is striking Hilo right now, and the Waikiki sea wall is under water.

http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1

Regards
Marshall

> 
> ETA's for the West Coast are around 7:00 AM PST
> 
> http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-arrival-times-for-canadas-west-coast/article1938243/
> 
>> 
>> ---
>> 
>> Daniel Belin
>> 
>> On Mar 11, 2011, at 3:50 AM, Jeroen van Aart  wrote:
>> 
>>> Michael Painter wrote:
 Christopher LILJENSTOLPE wrote:
> Pacific tsunami warning centre has confirmed a deep ocean tsunami. Three 
> dart bouys have detected > 2 ft wave fronts. Warnings
> up for entire pacific basin except for Alaska/canada/us west coast.
> 
> Official warming
> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.133222
> 
> The tsunami was 1.3 meters at Midway Is., 1/2 meter at Kauai 
> 
> http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs
> 
> Here is a live feed - it is striking Waikiki (with no real damage IFAICT, but 
> it is dark) right now 
> http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1
> 
> ETA's for the West Coast are around 7:00 AM PST
> 
> http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-arrival-times-for-canadas-west-coast/article1938243/
> 
> Regards
> Marshall
> 
> 
> 
> Chris
 Tsunami sirens just went off on Maui.
>>> 
>>> You may get information by going to forecast.weather.gov and searching for 
>>> a location. i.e.:
>>> 
>>> http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&site=MFR&textField1=43.3667&textField2=-124.217&e=0
>>> 
>>> Then click the Tsunami Watch link:
>>> http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=ORC011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch
>>> 
>>> Also see:
>>> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000
>>> 
>>> -- 
>>> http://goldmark.org/jeff/stupid-disclaimers/
>>> http://linuxmafia.com/~rick/faq/plural-of-virus.html
>>> 
>> 
>> 
> 
> 
> 

Re: so big earthquake in JP

[Patrick W. Gilmore]

On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote:

> Are we aware of how much the infrastructure has been damaged yet? Are 
> aftershocks still going?

Subway & bus lines are still down.  Fire at the nuke plant has been put out, no 
radiation detected, but they still evacuated a couple thousand residents 
because the backup generator failed & the water pump is not pumping.

The Japanese gov't has sent troops into some areas, asked Washington to let the 
US service men in .jp (about 50K) help.  I don't know if D.C. has agreed, but I 
can't imagine Obama would say no.

A few hundred bodies have been found so far.

It is very bad.  But it could have been worse, the Japanese are very well 
prepared (building codes, emergency procedures, etc.).

-- 
TTFN,
patrick

Re: so big earthquake in JP

[Marshall Eubanks]

On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote:

> Are we aware of how much the infrastructure has been damaged yet? Are 
> aftershocks still going?


The tsunami was 1/2 meter in Kauai 

http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs

ETA's for the West Coast are around 7:00 AM PST

http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-arrival-times-for-canadas-west-coast/article1938243/

> 
> ---
> 
> Daniel Belin
> 
> On Mar 11, 2011, at 3:50 AM, Jeroen van Aart  wrote:
> 
>> Michael Painter wrote:
>>> Christopher LILJENSTOLPE wrote:
 Pacific tsunami warning centre has confirmed a deep ocean tsunami. Three 
 dart bouys have detected > 2 ft wave fronts. Warnings
 up for entire pacific basin except for Alaska/canada/us west coast.

Official warming
http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.133222

The tsunami was 1.3 meters at Midway Is., 1/2 meter at Kauai 

http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs

Here is a live feed - it is striking Waikiki (with no real damage IFAICT, but 
it is dark) right now 
http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1

ETA's for the West Coast are around 7:00 AM PST

http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-arrival-times-for-canadas-west-coast/article1938243/

Regards
Marshall


 
 Chris
>>> Tsunami sirens just went off on Maui.
>> 
>> You may get information by going to forecast.weather.gov and searching for a 
>> location. i.e.:
>> 
>> http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&site=MFR&textField1=43.3667&textField2=-124.217&e=0
>> 
>> Then click the Tsunami Watch link:
>> http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=ORC011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch
>> 
>> Also see:
>> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000
>> 
>> -- 
>> http://goldmark.org/jeff/stupid-disclaimers/
>> http://linuxmafia.com/~rick/faq/plural-of-virus.html
>> 
> 
> 

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Jeff Wheeler]

On Thu, Mar 10, 2011 at 10:51 PM, George Bonser  wrote:
> And I say making them /127s may not really make any difference.  Say you
> make all of those /127s, at some point you *are* going to have a network
> someplace that is a /64 that has hosts on it and that one is just as
> subject to such an attack.  If you are a content provider, it doesn't
> make any difference if they take down the links between your routers or
> if they take down the link that your content farm is on.  The end result
> is the same.  You have managed to re-arrange the deck chairs.  Have
> another squeeze at that water balloon.

Again, this is the argument put forth by the "RFC wavers," that you
can't solve the problem because you must want to configure /64s for
... what, exactly?  Oh, right, SLAAC.  More on that below.

If I'm a content provider, I don't have to configure a /64 for my
content farm.  I can configure a /120 or whatever subnet size is
practical for my environment.  I can also use link-local addressing on
my content farm LANs and route subnets to my content boxes, if that is
somehow more practical than using a smaller subnet.

> If you are a service provider where practically all of your links are
> point to points, sure.

No, you can avoid configuring /64s if you don't need SLAAC.  Who needs
SLAAC?  I don't.  It has absolutely no place in any of my
environments.  It seems to me that DHCPv6 will do everything which
SLAAC does, and everything SLAAC forgot about.  The "complexity"
argument is pretty much indefensible when the trade-off is configuring
DHCPv6 vs turning a bunch of router knobs and hoping no one ever
targets your LANs with an NDP DoS.

> We didn't need much more host addressing, we needed more subnet
> addressing.  I would have settled for 16 bits of host addressing and 112
> bits of subnet addressing and I suppose nothing prevents me from doing
> that except none of the standard IPv6 automatic stuff would work
> anymore.

None of that "standard IPv6 automatic stuff" works today, anyway.  The
state of IPv6 support on end-user CPE generally ranges from
non-existent to untested to verified-to-be-broken.  This is the only
place in your network where /64 can offer any value, and currently,
CPE is just not there.  Even the latest Cisco/Linksys CPE does not
support IPv6.  Sure, that'll change; but what won't change is the
total lack of any basis for configuring /64 LANs for "content farms"
or any similar non-end-user, non-dynamic segments.

I don't want 16 bits of host addressing.  I want to choose an
appropriate size for each subnet.  Why?  Because exactly zero of my
access routers can handle 2**16 NDP entries, let alone 2**16 entries
on multiple interfaces/VLANs.  I would like to see much larger ARP/NDP
tables in layer-3 switches, and I think vendors will deliver on that,
but I doubt we'll soon see even a 10x increase from typical table
sizes of today.  VPS farms are already pushing the envelope with IPv4,
where customers are already used to conserving addresses.  Guess what,
customers may still have to conserve addresses with IPv6, not because
the numbers themselves are precious, but because the number of ARP/NDP
entries in the top-of-rack or distribution switch is finite.

> And again, are you talking about all the way down to the host subnet
> level?  I suppose I could configure server farms in /112 or even /96
> (/96 has some appeal for other reasons mostly having to do with
> multicast) but then I would wonder how many bugs that would flush out of
> OS v6 stacks.

I'm not getting reports of problems with smaller-than-/64 subnets from
customers yet.  Am I confident that I never will?  No, absolutely not!
 Like almost everyone else, I have some customers who have configured
IPv6, but the amount of production traffic on it remains trivial.
That is why I allocate a /64 but provision a /120 (or similar
practical size.)  I can grow the subnet if I have to.  I do know that
/64 LANs will cause me DoS problems, so I choose to work around that
problem now.  If /120 LANs cause me OS headaches in the future, I have
the option to revise my choice with minimal effort (no services get
renumbered, only the subnet must grow.)

Why would you suggest /96 as being more practical than /64 from the
perspective of NDP DoS?  Again, this is an example of the "in-between"
folks in these arguments, who seem not to fully understand the
problem.  Your routers do not have room for 2**(128-96) NDP entries.
Typical access switches today have room for a few thousand to perhaps
16k, and typical "bigger" switches are specifying figures below 100k.
This doesn't approach the 4.3M addresses in a /96.  In short,
suggesting /96 is flat out stupid -- you get "the worst of both
worlds," potential for OS compatibility issues, AND guaranteed NDP DoS
vulnerability.

> passing traffic. That doesn't protect against rogue hosts but there
> might be ways around that, too, or at least limiting the damage a rogue
> host can cause.

How do you suggest we li

Re: so big earthquake in JP

[Daniel Belin]

Are we aware of how much the infrastructure has been damaged yet? Are 
aftershocks still going?

---

Daniel Belin

On Mar 11, 2011, at 3:50 AM, Jeroen van Aart  wrote:

> Michael Painter wrote:
>> Christopher LILJENSTOLPE wrote:
>>> Pacific tsunami warning centre has confirmed a deep ocean tsunami. Three 
>>> dart bouys have detected > 2 ft wave fronts. Warnings
>>> up for entire pacific basin except for Alaska/canada/us west coast.
>>> 
>>> Chris
>> Tsunami sirens just went off on Maui.
> 
> You may get information by going to forecast.weather.gov and searching for a 
> location. i.e.:
> 
> http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&site=MFR&textField1=43.3667&textField2=-124.217&e=0
> 
> Then click the Tsunami Watch link:
> http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=ORC011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch
> 
> Also see:
> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000
> 
> -- 
> http://goldmark.org/jeff/stupid-disclaimers/
> http://linuxmafia.com/~rick/faq/plural-of-virus.html
> 

Re: so big earthquake in JP

[Jeroen van Aart]

Michael Painter wrote:

Christopher LILJENSTOLPE wrote:
Pacific tsunami warning centre has confirmed a deep ocean tsunami. 
Three dart bouys have detected > 2 ft wave fronts. Warnings

up for entire pacific basin except for Alaska/canada/us west coast.

Chris


Tsunami sirens just went off on Maui.


You may get information by going to forecast.weather.gov and searching 
for a location. i.e.:


http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&site=MFR&textField1=43.3667&textField2=-124.217&e=0

Then click the Tsunami Watch link:
http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=ORC011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch

Also see:
http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000

--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html

Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations

[Dobbins, Roland]

On Mar 11, 2011, at 2:33 PM, Owen DeLong wrote:

> There's a HUGE difference between IP unnumbered and link-local.

In all honesty, at the macro level, I don't see it; if you wouldn't mind 
elaborating on this, I would certainly find it useful.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: so big earthquake in JP

[Michael Painter]

Christopher LILJENSTOLPE wrote:
Pacific tsunami warning centre has confirmed a deep ocean tsunami. Three dart bouys have detected > 2 ft wave fronts. 
Warnings

up for entire pacific basin except for Alaska/canada/us west coast.

Chris


Tsunami sirens just went off on Maui. 

Re: so big earthquake in JP

[Christopher LILJENSTOLPE]

Pacific tsunami warning centre has confirmed a deep ocean tsunami. Three dart 
bouys have detected > 2 ft wave fronts.  Warnings up for entire pacific basin 
except for Alaska/canada/us west coast.  

Chris

--
Pardon the typos - sent from a silly keyboard

On 10/03/2011, at 23:13, Khurram Khan  wrote:

> bbc reports 8.8 magnitude with a tsunami.
> 
> http://www.bbc.co.uk/news/world-asia-pacific-12709598
> 
> 
> 
> On Fri, Mar 11, 2011 at 12:08 AM, Bryan Irvine  wrote:
>> On Thu, Mar 10, 2011 at 10:19 PM, Tomoya Yoshida  wrote:
>>> Japan had so big terrible earthquake
>> 
>> How big?  I see reports of Tokyo, was Kyoto affected?
>> 
>> 
> 
>