Re: Routing doesn't work all the time

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?

[..]
> Other routing entries are 
> fe80::/64 dev eth0  metric 256  mtu 1500 advmss 1440
> fe80::/64 dev eth3  metric 256  mtu 1500 advmss 1440
> fe80::/64 dev eth2  metric 256  mtu 1500 advmss 1440
> fe80::/64 dev eth1  metric 256  mtu 1500 advmss 1440
> ff00::/8 dev eth0  metric 256  mtu 1500 advmss 1440
> ff00::/8 dev eth3  metric 256  mtu 1500 advmss 1440
> ff00::/8 dev eth2  metric 256  mtu 1500 advmss 1440
> ff00::/8 dev eth1  metric 256  mtu 1500 advmss 1440
> 
> (I don't know why these are usefull?)

The first four are to point the link-locals in the correct direction.
Try 'ping6 -I eth0 ff02::1' to see all the hosts on the eth0 link.
The ff00::/8 is for multicast. (See
http://www.iana.org/assignments/ipv6-address-space )

> 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.

BTW, why use Unique Local Unicast addresses anyway?

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBEExvpKaooUjM+fCMRAlMpAKCQJjktWHL1BodlTvil1P/G9rjfAQCglN6c
/sT94a/aMKkUb0jt5XaKZ7I=
=u+hU
-----END PGP SIGNATURE-----