Bad routes update

Masaki Hirabaru masaki@merit.edu
Fri, 23 Jul 1999 06:33:14 -0400


>> > I don't think that most of the flapping on 6bone comes from
>> > interface up/down. And, pTLA routes are flapping, so we can not
>> > diminish them by aggregation.
>> 
>> My guess it's a result of having to use tunnels over Ipv4.  Some of the Ipv4
>> network is unstable IMHO, and this could be reflected into the 6bone.  I don't
>> think this is coincidental as I suspect that a significant body of users
>> deploying IPv6 are doing so because of their own perceived instability of IPv4
>> services.  We for one experience this

You mean that IPv4 networks even among pTLAs are unstable. There
was a case that an unstable IPv4 connection caused an excessive
BGP updates on 6bone.  If your connection is too unstable to keep
the BGP/TCP connection (for example, it closes by error every few
minutes), I'm afraid that it may affect 6bone backbone routing.

If you are not a pTLA, aggregation will eliminate flapping. If
you are a pTLA, have mesh connections with other pTLAs, and act
as a transit as requested, your unstable connection will affect
other 6bone people as well as you. Among pTLAs on 6bone, we have
mesh connections regardless of the IPv4 physical topology, so
IPv6 traffic even within US could travel through Japan, Europe,
or your country where pTLA exists.

Masaki

>> From: Peter Tattam <peter@jazz-1.trumpet.com.au>
>> Subject: Re: Bad routes update
>> Date: Thu, 22 Jul 1999 15:22:17 +1000 (EST)
>> Message-ID: <Pine.BSF.3.96.990722150914.28466H-100000@jazz-1.trumpet.com.au>
>>
>> On Wed, 21 Jul 1999, Masaki Hirabaru wrote:
>> 
>> > >> ->2) There are a lot of route flapping even within the valid pTLA
>> > >> ->space.  A long time ago, I tried to figure out the origins, but I
>> > >> ->gave up to continue it for all the occasions. It keeps happening.
>> > >> 
>> > >> If we aggregate, I think we will see this diminish. many routes that flap
>> > >> come from statics that point to interfaces that go down, etc... If we
>> > >> aggregate, we won't see the affects of these, except in the case of yoru
>> > >> IBGP, where you will want your own specifics.
>> > 
>> > I don't think that most of the flapping on 6bone comes from
>> > interface up/down. And, pTLA routes are flapping, so we can not
>> > diminish them by aggregation.
>> 
>> My guess it's a result of having to use tunnels over Ipv4.  Some of the Ipv4
>> network is unstable IMHO, and this could be reflected into the 6bone.  I don't
>> think this is coincidental as I suspect that a significant body of users
>> deploying IPv6 are doing so because of their own perceived instability of IPv4
>> services.  We for one experience this - our backbone provider won't give us an
>> honest answer as to what the problem is, and is indicative of the way things
>> really are.  For some regions, choice of backbone provider is limited too, so
>> letting the market decide is not a complete answer.
>> 
>> Peter
>> 
>> > 
>> > >> ->3) There are a couple of strange routes outside the 6bone pTLA
>> > >> ->space drafting over the 6bone. We could get it covered by
>> > >> ->imposing the routing policy rather than solving the real problem.
>> > >> 
>> > >> Filter them. That way, they will be gone. If you look closely enough, you
>> > >> can see 10/8 v4 space around. You just have to filter it at your edges to
>> > >> make sure it doesn't affect anyone. While I would personally like for these
>> > >> people to fix the problem, in this case, you can only control your own
>> > >> routing domain, thus going around them with a filter would be just as
>> > >> handy, and effectively the same thing.
>> > 
>> > Let me explain how they are strange. They have a strange as path
>> > and are flapping. It would indicate something wrong on 6bone.
>> > 
>> > If the routing policy intends to solve the current 6bone routing
>> > issues, it would not work.  It will just decrease the size of
>> > routing table but may introduce another complexity that may make
>> > it harder to catch the real problems.
>> > 
>> > Masaki
>> > 
>> 
>> --
>> Peter R. Tattam                            peter@trumpet.com
>> Managing Director,    Trumpet Software International Pty Ltd
>> Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210