Prev: repost - RFC [Patch] Remove "please try 'cgroup_disable=memory' option if you don't want memory cgroups" printk at boot time.
Next: Staging: batman-adv: fix checkpath.pl issues
From: Sam Cannell on 20 Apr 2010 21:10
Sorry, just realised I forgot to note that this behaviour occurs in
2.6.33.

On Wed, 2010-04-21 at 12:52 +1200, Sam Cannell wrote:
> Hi,
>
> I've been having some trouble with ip6 duplicate address detection in a
> Linux VM (under XVM on OpenSolaris). It seems that the ethernet bridge
> in XVM sends a host's own multicast packets back to it, which the
> duplicate address detection code in linux decide that another host on
> the network is using the same address.
>
> For instance, running:
>
> router4:~ # ip addr add fe80::216:36ff:fe4e:461c/64 dev eth0
>
>
> I get the following output in tcpdump:
>
> router4:~ # tcpdump -nevpi eth0 ip6
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
> bytes
> 12:33:03.755897 00:16:36:4e:46:1c > 33:33:00:00:00:16, ethertype IPv6
> (0x86dd), length 90: (hlim 1, next-header Options (0) payload length:
> 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] ICMP6,
> multicast listener report v2, length 28, 1 group record(s) [gaddr
> ff02::1:ff4e:461c to_ex, 0 source(s)]
> 12:33:04.551772 00:16:36:4e:46:1c > 33:33:ff:4e:46:1c, ethertype IPv6
> (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length:
> 24) :: > ff02::1:ff4e:461c: [icmp6 sum ok] ICMP6, neighbor solicitation,
> length 24, who has fe80::216:36ff:fe4e:461c
> 12:33:04.551998 00:16:36:4e:46:1c > 33:33:ff:4e:46:1c, ethertype IPv6
> (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length:
> 24) :: > ff02::1:ff4e:461c: [icmp6 sum ok] ICMP6, neighbor solicitation,
> length 24, who has fe80::216:36ff:fe4e:461c
> ^C
> 3 packets captured
> 3 packets received by filter
> 0 packets dropped by kernel
>
>
> And dmesg says:
>
> router4:~ # dmesg
> [ 371.024287] eth0: IPv6 duplicate address fe80::216:36ff:fe4e:461c
> detected!
>
>
> And the address sits in 'tentative' mode:
>
> router4:~ # ip addr show dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> link/ether 00:16:36:4e:46:1c brd ff:ff:ff:ff:ff:ff
> inet 192.168.2.128/24 brd 192.168.2.255 scope global eth0
> inet6 fe80::216:36ff:fe4e:461c/64 scope link tentative flags 08
> valid_lft forever preferred_lft forever
>
>
> This happens for link-local and global scope address, both when they try
> to auto-configure and when set by hand:
>
> [ 463.500328] eth0: IPv6 duplicate address
> 2404:130:0:1000:216:36ff:fe4e:461c detected!
> [ 732.428312] eth0: IPv6 duplicate address
> 2404:130:0:1000:216:36ff:fe4e:461c detected!
> [ 883.812328] eth0: IPv6 duplicate address 2404:130::3:2:1 detected!
>
>
> I'd happily put this down to a failing in XVM, however the stateless
> autoconfiguration RFC (4862) states that the stack shouldn't decide an
> address is duplicate based on receipt of a neighbor solicitation message
> that it sent itself:
>
> 5.4.3. Receiving Neighbor Solicitation Messages
> [...]
> If the source address of the Neighbor Solicitation is the unspecified
> address, the solicitation is from a node performing Duplicate Address
> Detection. If the solicitation is from another node, the tentative
> address is a duplicate and should not be used (by either node). If
> the solicitation is from the node itself (because the node loops back
> multicast packets), the solicitation does not indicate the presence
> of a duplicate address.
>
>
> Assuming my understanding of the RFC is correct, this suggests to me that duplicate address detection in Linux is being a little too hasty to mark the address as invalid. Thoughts?
>
>
> Thanks,
>
> Sam Cannell
>
>

 | 
Pages: 1
Prev: repost - RFC [Patch] Remove "please try 'cgroup_disable=memory' option if you don't want memory cgroups" printk at boot time.
Next: Staging: batman-adv: fix checkpath.pl issues