Re: Routing doesn't work all the time

Jeroen Massar schreef:
> On Sat, 2006-03-11 at 16:07 +0100, Steven LatrŽe wrote:
>   
>> Hi all,
>>
>> First of all thanks for the answers on my previous question (subject:
>> Neighbour discovery and more than one NIC) that helped a lot but my
>> problem isn't completely solved. There've been some changes in my
>> set-up. Is still have some PC's chained together like this:
>> PCA (eth 2) <---> (eth1) PCB (eth1) <--> (eth2) PCC (eth1) 
>> This is a simple example but actually there are more pc's chained
>> together. The overall topology is some kind of tree-and-branch
>> topology.
>>
>> I'm not working with Neighbour discovery addresses any more (only for
>> one specific subnetwork but that's not important). I have some kind of
>> dhcp script that tries to discover the topology, assigns the right
>> unique local unicast addresses and sets the routing tables correct.
>>
>> Now the weird thing is the following: I can perfectly ping two pc's
>> that are neighbours (eg PCA en PCB). Now when I want to ping from PCA
>> to PCC it doesn't work UNTIL I have made a ping from PCB to PCC. From
>> that moment on pinging A and C is possible. The error I get before it
>> works is "Address unreachable" So after a while I have a pretty good
>> chance that I can ping all my pc's, but that waiting isn't right I
>> think.
>>
>>
>> Here is a short explanation of my routing tables (working on Debian
>> Linux)
>>     
>
> Which Debian? Or more to the point which exact kernel version?
>
> [..]
>   

I'm using kernel version 2.4.31
>> and
>> fd9f:187c:6e81:3e::1:fe dev eth3  metric 1  mtu 1500 advmss 1440
>> fd9f:187c:6e81:3e::/64 dev eth1  metric 256  mtu 1500 advmss 1440
>> fd9f:187c:6e81:3e::/64 via fd9f:187c:6e81:3e::1:fe dev eth3  metric
>> 1024  mtu 1500 advmss 1440
>>     
>
> The interresting question here: Why are you point the same /64 towards
> eth1 and to the eth3 via that nexthop?
>
> This will, with some luck, "load-balance" or better said, randomly send
> packets out over eth1 or eth3. Which causes the problem you explained.
>   
Thanks for pointing out that problem! That was indeed a mistake. 
Unfortunately it didn't solve my initial problem. I still get the same 
ping problems.

> BTW, why use Unique Local Unicast addresses anyway?
>   
I have two reasons (but I'm a newbie so they can be wrong):
- I'm developing a dynamic network that still works even if there's a 
link down. The network will reconfigure itself so that when a link is 
down two independent networks will be formed. It is important that 
although those networks can't communicate with eachother they still have 
different network id's. I read that the unique local unicast addresses 
must form a random network id and that was what I want.
- If I'm not mistaken the unique local unicast addresses are a 
"semi-alternative" for the private IPv4 addresses. And the network I'm 
developing is private.
Is there any reason why I shouldn't use those addresses?

Regards,
Steven
> Greets,
>  Jeroen
>
>