[ofa-general] Re: [openib-general] Fw: [PATCH] enable IPoIB only if broadcast join finish

Jason Gunthorpe jgunthorpe at obsidianresearch.com
Tue Mar 6 17:02:08 PST 2007


On Tue, Mar 06, 2007 at 04:22:45PM -0800, Shirley Ma wrote:

> So we could have same IPv6 addresses even without IPoIB if the NS doesn't
> respond on time for any reason, right?

Right. An example would be if you connect two ethernet networks
together that had duplicate addresses. The startup DAD mechanism does
not protect from that.

> Then DAD is broken in current code already. In IPoIB case, we allow
> duplicated IPv6 addresses after the interface up and running but not
> before if any reason the multicast join successfully much later,
> probably after several tries? That doesn't make any sense to me.

IPoIB has no control over DAD, it is all done in the core IPv6. It
also has no impact on the up/running state:

Ex:

$ ping6 -I eth0 fe80::c2   
PING fe80::c2(fe80::c2) from fe80::20e:cff:fe71:2858 eth0: 56 data bytes
64 bytes from fe80::c2: icmp_seq=1 ttl=64 time=1.28 ms

$ ip addr add fe80::c2/64 dev eth0; ip addr
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0e:0c:71:28:58 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c2/64 scope link tentative 
       valid_lft forever preferred_lft forever
    inet6 fe80::20e:cff:fe71:2858/64 scope link 
       valid_lft forever preferred_lft forever
$ dmesg
eth0: duplicate address detected!
$ ip addr
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    inet6 fe80::c2/64 scope link tentative 
       valid_lft forever preferred_lft forever

Note that the *address* still has the tentative flag (this disables
the address) and the interface is still up/running.

If you look on tcpdump you see that the instant I did the 'ip addr
add' the kernel spat out:

17:49:01.034403 fe80::20e:cff:fe71:2858 > ff02::16: HBH icmp6: type-#143 [hlim 1]
        0x0000:  6000 0000 0038 0001 fe80 0000 0000 0000  `....8..........
        0x0010:  020e 0cff fe71 2858 ff02 0000 0000 0000  .....q(X........
        0x0020:  0000 0000 0000 0016 3a00 0502 0000 0100  ........:.......
        0x0030:  8f00 0f8d 0000 0002 0400 0000 ff02 0000  ................
        0x0040:  0000 0000 0000 0001 ff00 00c2 0400 0000  ................
        0x0050:  ff02                                     ..
17:49:01.642183 :: > ff02::1:ff00:c2: icmp6: neighbor sol: who has fe80::c2
        0x0000:  6000 0000 0018 3aff 0000 0000 0000 0000  `.....:.........
        0x0010:  0000 0000 0000 0000 ff02 0000 0000 0000  ................
        0x0020:  0000 0001 ff00 00c2 8700 7aa3 0000 0000  ..........z.....
        0x0030:  fe80 0000 0000 0000 0000 0000 0000 00c2  ................

The first is IGMPv6 to join the new solicited node multicast
group and the last is the DAD probe.

So, yes, currently, IPoIB is broken in that DAD for new addresses is
not synchronized to the SM join. But, DAD for startup addresses is
OK due to the trick that is played with carrier. Your patch breaks
both equally :>

Regards,
Jason




More information about the general mailing list