Re: Routing doesn't work all the time

On Sun, 2006-03-12 at 11:15 +0100, Steven LatrŽe wrote:
> Jeroen Massar schreef: 
> > On Sat, 2006-03-11 at 16:07 +0100, Steven LatrŽe wrote:
[..]
> > Which Debian? Or more to the point which exact kernel version?
> > 
> > [..]
> >   
> 
> I'm using kernel version 2.4.31

There have been a *lot* of fixes in 2.6.15, copied back from the USAGI
project, which most likely are not ported to 2.4.x series. I have no
experience with 2.4.x hosts doing IPv6. It should work, but there might
be oddities.

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

Check all the routing tables again for faults. Then start doing things
like 'ping6 -I ethX ff02::1' to find all hosts and 'ping6 -I ethX
ff02::2' to find routers on that subnet (hosts with forwarding enabled).

Otherwise tcpdump or tethereal are your friend and then you will need to
debug it out, you should see a Neighbour Discovery on the link when
trying to reach that host and of course a response where it is. Dumping
on both ends makes this of course easier to do.

Also check 'ip -6 nei sho' to see if the neighbours can be found by the
kernel and not only seen by tcpdump.

Which networkcards do you use? Some network cards have problems with
multicast, try setting the MULTICAST flag (ifconfig ethX multicast) to
force them to grab multicast packets from the wire. Some other cards
require PROMISC to be set for this. But this is only the case with some
very bad networking cards anyway.

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

With 'link' you mean an internet link or simply something in your own
network?

If it is a internet link you will end up in NAT at one point or the
other as the ULA's can't be used on the internet (unless you pay folks
enough to announce and transit them for you ;)

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

ULA's are indeed meant for 'private' networks, aka ones that are not
connected to the internet but might want to connect to other networks.
The ULA is (mostly) unique so it should not cause a clash with other
networks easily, interconnecting thus because easy in that case.

> Is there any reason why I shouldn't use those addresses?

Nope, just wondering why you don't use any global address space.

Greets,
 Jeroen

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

iD8DBQBEFByeKaooUjM+fCMRAkcbAKCuM/9F1G0xyh3kaoTo3Xq8y8UM0gCgn4fk
lXlT9wX1hnnHVvnjRu5LXes=
=sDvE
-----END PGP SIGNATURE-----