SixXS::Sunset 2017-06-06

local ipv6 network (lan) sometimes works, sometimes not...
[de] Shadow Hawkins on Wednesday, 25 February 2004 23:15:43
Hi, I have some problems with mit local ipv6 setup. The tunnel and the subnet works perfectly (if I route it NOT in my lan ;-P) I have a tunnel and an extra /48 subnet. I routed a /64 out of this /48 in my lan. But the problem that I have is not a routing problem, because that works fine. The problem is my local ipv6 setup. I have added the first ip out of the /64 to the router and the second ip out of the /64 to the client (both Debian Unstable machines). My problem is with the ipv6 connectivity between these hosts in my lan. It could be important, that is not a classical lan which connects these both hosts. I use two wireles lan accesspoints in my local lan and so both machines are bridged over the wireless lan. Sometime ipv6 in my lan works, sometimes not... I noticed that the problem seems to be wrose from the router to the client. The other way is better (but not perfect). My Setup is: Router: 2001:6f8:9f7::1/64 Client: 2001:6f8:9f7::2/64 I added these IPs to the ethernet devices on both machine by the command: ip -6 add addr 2001:6f8:9f7::xxxx/64 dev eth0 (no extra routing for this subnet) I can't ping from the router to the client... the router always shows: PING 2001:6f8:9f7::2 56 data bytes From ::1 icmp_seq=1 Destination unreachable: Address unreachable From ::1 icmp_seq=2 Destination unreachable: Address unreachable From ::1 icmp_seq=3 Destination unreachable: Address unreachable with tcpdump on the router I only see this: 22:37:52.529789 2001:6f8:9f7::1 > ff02::1:ff00:2: icmp6: neighbor sol: who has 2001:6f8:9f7::2 22:37:53.529801 2001:6f8:9f7::1 > ff02::1:ff00:2: icmp6: neighbor sol: who has 2001:6f8:9f7::2 22:37:54.530096 2001:6f8:9f7::1 > ff02::1:ff00:2: icmp6: neighbor sol: who has 2001:6f8:9f7::2 but on the client side I see nothing! That's not normal. So here seems to be the problem?!? If I try the ping test the other way (from the client to the router), it seems to be better: PING 2001:6f8:9f7::1 56 data bytes 64 bytes from 2001:6f8:9f7::1: icmp_seq=17 ttl=64 time=2003 ms 64 bytes from 2001:6f8:9f7::1: icmp_seq=18 ttl=64 time=1004 ms 64 bytes from 2001:6f8:9f7::1: icmp_seq=19 ttl=64 time=3.51 ms 64 bytes from 2001:6f8:9f7::1: icmp_seq=20 ttl=64 time=3.25 ms tcpdump shows that (captured on the router): 22:38:49.154535 2001:6f8:9f7::2 > 2001:6f8:9f7::1: icmp6: echo request 22:38:50.150983 2001:6f8:9f7::1 > ff02::1:ff00:2: icmp6: neighbor sol: who has 2001:6f8:9f7::2 22:38:50.154600 2001:6f8:9f7::2 > ff02::1:ff00:1: icmp6: neighbor sol: who has 2001:6f8:9f7::1 22:38:50.154676 2001:6f8:9f7::1 > 2001:6f8:9f7::2: icmp6: echo reply 22:38:50.154684 2001:6f8:9f7::1 > 2001:6f8:9f7::2: icmp6: echo reply 22:38:50.154698 2001:6f8:9f7::1 > 2001:6f8:9f7::2: icmp6: neighbor adv: tgt is 2001:6f8:9f7::1 22:38:50.161773 2001:6f8:9f7::2 > 2001:6f8:9f7::1: icmp6: echo request 22:38:50.161872 2001:6f8:9f7::1 > 2001:6f8:9f7::2: icmp6: echo reply 22:38:51.155222 2001:6f8:9f7::2 > 2001:6f8:9f7::1: icmp6: echo request As you can see, it works, but it takes 16 pings to get the first successful ping reply and after some pings the pings are failing again... So I have about 20-30% successfull pings only. If I ping the router from the client there are suprisingly some of the lost "neighbor sol" packets from the router reaching the client. I think after that each client knows the arp of the other side, so it works until the router forgets the arp from the client again. The problem is only that it takes sometime to get the arp from the client again (the client must contiuue pinging (making traffic). If only the router makes ipv6 traffic there will never be one successfull ping. ip neigh show on the router (if the ping fails): 2001:6f8:9f7::2 dev eth0 nud failed ip neigh show on the client (even if the ping fails): 2001:6f8:9f7::1 dev eth0 lladdr 00:20:ed:36:6d:7d router nud stale So, because I can't see any arp requests on the client side and the arp of the client is missing in the routers arp neighbour table, it seems to be a arp/mac problem?!? The problem could be the wireless lan accesspoints I am using. The client and the router are connected over this wireless lan link. On ipv4 I have no problems, so I don't understand the arp problems with ipv6. I think the wireless lan accesspoints are acting like simple ethernet-bridges... They only care about arp and not on the layer above that (ipv4 or ipv6)... But maybe I am wrong on this... But even then, why the problem seems to exist only in one direction? Anyone have solved a problem like this before? Anyone have expierence with wireless lan routers? Should I upgrade the firmware? Any tips? Btw. I read an older thread in this forum, where someone had problems like mine. There were a tip about setting the ethernet devices to multicast and promisc mode... I tried this here, but that doesn't help anything. Oh, and I have radvd running, even If I think that my setup is so simple that I don't need a tool like that. So that is not the problem too. I will add the arp of the client permanently to the router, so I think I can solve my problem this way (not tried it yes). But this is not a good solution for the whole lan, because there are a quite a lot of computers and some changing mobile users with their notebook. It would be horrible adding each arp by myself each time. Thx for any help & ideas, --Ralph

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker