Re: patch: bad ipv6 neighbor solicitation
I didn't think this routing patch was related to the bad neighbor solicitation messages as suggested in the subject field but I tried it anyway. It does not fix my IPv6 problem. I still get bad neighbor solicitation messages and freebsd 8 doesn't respond to 4/5 IPv6 pings. Thanks, Tom On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Li, Qing Sent: Monday, December 14, 2009 3:00 PM To: Dennis Glatting; JASSAL Aman Cc: freebsd-...@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-...@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 = default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with route add *your parameters* or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same fabric, one can ship packets out and the other can't. I was wondering about the route however I haven't figured out the trick to get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1:
RE: patch: bad ipv6 neighbor solicitation
Thanks for reporting back. I asked you for a routing table dump in my previous email, would you mind emailing it to me privately? -- Qing -Original Message- From: Tom Pusateri [mailto:pusat...@bangj.com] Sent: Tuesday, December 15, 2009 1:28 PM To: Li, Qing Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation I didn't think this routing patch was related to the bad neighbor solicitation messages as suggested in the subject field but I tried it anyway. It does not fix my IPv6 problem. I still get bad neighbor solicitation messages and freebsd 8 doesn't respond to 4/5 IPv6 pings. Thanks, Tom On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Li, Qing Sent: Monday, December 14, 2009 3:00 PM To: Dennis Glatting; JASSAL Aman Cc: freebsd-...@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-...@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 = default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with route add *your parameters* or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same
RE: patch: bad ipv6 neighbor solicitation
Thanks for sending me the routing table output. Actually I believe both your problems are indeed related to the prefix route. I was able to reproduce Dennis Glatting's problem, which was due to one of the prefix entry being off-link. In your case the prefix route for 2610:28:1800:4001:20e:cff:fe9f:faad disappeared and is not in the routing table. If you add the route by hand the problem should go away. I guess the question is what triggered the prefix route deletion. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Li, Qing Sent: Tuesday, December 15, 2009 1:46 PM To: Tom Pusateri Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org Subject: RE: patch: bad ipv6 neighbor solicitation Thanks for reporting back. I asked you for a routing table dump in my previous email, would you mind emailing it to me privately? -- Qing -Original Message- From: Tom Pusateri [mailto:pusat...@bangj.com] Sent: Tuesday, December 15, 2009 1:28 PM To: Li, Qing Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation I didn't think this routing patch was related to the bad neighbor solicitation messages as suggested in the subject field but I tried it anyway. It does not fix my IPv6 problem. I still get bad neighbor solicitation messages and freebsd 8 doesn't respond to 4/5 IPv6 pings. Thanks, Tom On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Li, Qing Sent: Monday, December 14, 2009 3:00 PM To: Dennis Glatting; JASSAL Aman Cc: freebsd-...@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-...@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 = default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64
Re: patch: bad ipv6 neighbor solicitation
You are correct. I added the route and it works fine. route add -inet6 2610:28:1800:4001::/64 -iface em0 Thanks, Tom On Dec 15, 2009, at 5:00 PM, Li, Qing wrote: Thanks for sending me the routing table output. Actually I believe both your problems are indeed related to the prefix route. I was able to reproduce Dennis Glatting's problem, which was due to one of the prefix entry being off-link. In your case the prefix route for 2610:28:1800:4001:20e:cff:fe9f:faad disappeared and is not in the routing table. If you add the route by hand the problem should go away. I guess the question is what triggered the prefix route deletion. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Li, Qing Sent: Tuesday, December 15, 2009 1:46 PM To: Tom Pusateri Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org Subject: RE: patch: bad ipv6 neighbor solicitation Thanks for reporting back. I asked you for a routing table dump in my previous email, would you mind emailing it to me privately? -- Qing -Original Message- From: Tom Pusateri [mailto:pusat...@bangj.com] Sent: Tuesday, December 15, 2009 1:28 PM To: Li, Qing Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation I didn't think this routing patch was related to the bad neighbor solicitation messages as suggested in the subject field but I tried it anyway. It does not fix my IPv6 problem. I still get bad neighbor solicitation messages and freebsd 8 doesn't respond to 4/5 IPv6 pings. Thanks, Tom On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Li, Qing Sent: Monday, December 14, 2009 3:00 PM To: Dennis Glatting; JASSAL Aman Cc: freebsd-...@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-...@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 = default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0
Re: patch: bad ipv6 neighbor solicitation
This patch works for me. On Mon, 14 Dec 2009, Li, Qing wrote: Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Li, Qing Sent: Monday, December 14, 2009 3:00 PM To: Dennis Glatting; JASSAL Aman Cc: freebsd-...@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-...@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 = default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with route add *your parameters* or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same fabric, one can ship packets out and the other can't. I was wondering about the route however I haven't figured out the trick to get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table I did delete the lo0 route before I exected the above command. Also, I haven't been able to specify a higher metric (e.g., -metric 2). That is rejected too. However, I can say: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 add
patch: bad ipv6 neighbor solicitation
Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem. Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however, due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- n...@freebsd.org] On Behalf Of Li, Qing Sent: Monday, December 14, 2009 3:00 PM To: Dennis Glatting; JASSAL Aman Cc: freebsd-...@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) You don't need to perform all that route-foo. I believe the root cause of this issue may be due to a bit of regression in the IPv6 prefix management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the same prefix. When ND6 NS arrives for bce1, due to the interface mismatch of the prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack at http://people.freebsd.org/~qingli/nd6-ns.diff until I commit a permanent patch. The problem was easily reproducible and I have verified with limited unit testing the patch works. -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-...@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 = default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with route add *your parameters* or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same fabric, one can ship packets out and the other can't. I was wondering about the route however I haven't figured out the trick to get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table I did delete the lo0 route before I exected the above command. Also, I haven't been able to specify a higher metric (e.g., -metric 2). That is rejected too. However, I can say: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route
