Date: Tue, 15 Dec 2009 17:58:31 -0500 From: Tom Pusateri <pusateri@bangj.com> To: "Li, Qing" <qing.li@bluecoat.com> Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation Message-ID: <A3A5FFE6-9632-4A47-952C-C9745CF6AD24@bangj.com> In-Reply-To: <B583FBF374231F4A89607B4D08578A430619B8F3@bcs-mail03.internal.cacheflow.com> References: <alpine.BSF.2.00.0912131456440.83238@Elmer.dco.penx.com><9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr><alpine.BSF.2.00.0912141451480.16515@Elmer.dco.penx.com><B583FBF374231F4A89607B4D08578A4304673758@bcs-mail03.internal.cacheflow.com><B583FBF374231F4A89607B4D08578A430619B543@bcs-mail03.internal.cacheflow.com><5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> <B583FBF374231F4A89607B4D08578A430619B8C5@bcs-mail03.internal.cacheflow.com> <B583FBF374231F4A89607B4D08578A430619B8F3@bcs-mail03.internal.cacheflow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-stable@freebsd.org [mailto:owner-freebsd- >> stable@freebsd.org] On Behalf Of Li, Qing >> Sent: Tuesday, December 15, 2009 1:46 PM >> To: Tom Pusateri >> Cc: freebsd-net@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:pusateri@bangj.com] >>> Sent: Tuesday, December 15, 2009 1:28 PM >>> To: Li, Qing >>> Cc: freebsd-net@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-net@freebsd.org [mailto:owner-freebsd- >>>>> net@freebsd.org] On Behalf Of Li, Qing >>>>> Sent: Monday, December 14, 2009 3:00 PM >>>>> To: Dennis Glatting; JASSAL Aman >>>>> Cc: freebsd-net@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-net@freebsd.org on behalf of Dennis Glatting >>>>> Sent: Mon 12/14/2009 2:03 PM >>>>> To: JASSAL Aman >>>>> Cc: freebsd-net@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 >>>>>>> UGS bce0 >>>>>>> ::1 ::1 >> UH >>>>>>> lo0 ::ffff:0.0.0.0/96 ::1 >>>>> UGRS >>>>>>> lo0 fd7c:3f2b:e791:1::/64 link#1 >>>>> U >>>>>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 >>>>> UHS >>>>>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 >>>>> UHS >>>>>>> lo0 fe80::/10 ::1 >>>>> UGRS >>>>>>> lo0 fe80::%bce0/64 link#1 >>>>> U >>>>>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 >>>>> UHS >>>>>>> lo0 fe80::%bce1/64 link#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 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 host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 >>>>> >>>>> Elmer# netstat -rn >>>>> (snip) >>>>> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 >> UHS >>>>> bce1 >>>>> >>>>> I don't think that is what I want. WHat I think I just said is >> "host >>>> X" >>>>> is >>>>> out that door, rather than route net. If, however, I say Docs is >> out >>>>> that >>>>> door, I get: >>>>> >>>>> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 >>>>> add host docs.dco.penx.com: gateway bce1 >>>>> >>>>> Elmer# ping6 >>>>> docs.penx.com >>>>> PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> >>>>> fd7c:3f2b:e791:1::ac13:a15 >>>>> ping6: sendmsg: Operation not permitted >>>>> ping6: wrote docs.dco.penx.com 16 chars, ret=-1 >>>>> >>>>> >>>>>>> >>>>>>> Elmer's rc.config: >>>>>>> >>>>>>> >>>>>>> ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" >>>>>>> ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 >> prefixlen >>>>> 64" >>>>>>> ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 >> prefixlen >>>> 64 >>>>> mtu >>>>>>> 8192" >>>>>>> ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" >>>>>>> >>>>>> >>>>>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've >>> never >>>>> used >>>>>> this myself so I can't really comment, and I can't say if there >>>>> aren't any >>>>>> sort of "interferences" with what you're trying to do. >>>>>> >>>>> >>>>> I hope what I am specifying is to use the 32 bit IPv4 address as >> the >>>>> last >>>>> 32 bits of the IPv6 address, at least that is how it works out >>>>> numerically. My numbering scheme for fixed assets is the last 32 >>> bits >>>>> of >>>>> the 128 bit IPv6 address is the same as its IPv4 address. >>>>> >>>>> >>>>>>> >>>>>>> >>>>>>> The router (cisco): >>>>>>> >>>>>>> >>>>>>> interface GigabitEthernet0/0 ipv6 address > FD7C:3F2B:E791:1::1/64 >>>>> ipv6 >>>>>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >>>>>>> >>>>>> >>>>>> Just a side-note, I'm not sure if it will be really useful to > you, >>>>> but you >>>>>> could give it a try if you want to. Have you tried using your >> Cisco >>>>> router >>>>>> as a Router Advertisement Daemon ? That way, addresses would be >>>> built >>>>>> automatically and you could see how both interfaces react to > such >>>>>> advertisements. >>>>>> >>>>>> I hope this helps. >>>>>> >>>>>> ------------ >>>>>> Aman Jassal >>>>>> >>>>>> Wisdom comes from experience. >>>>>> Experience comes from a lack of wisdom. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to "freebsd-net- >>> unsubscribe@freebsd.org" >>>>> >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to "freebsd-net- >>> unsubscribe@freebsd.org" >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable- >>> unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable- >> unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A3A5FFE6-9632-4A47-952C-C9745CF6AD24>