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 seemsto> 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 ::1UGRS> >> 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::/32fd7c: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/32fd7c: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. Iwas> > 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 2physical> > 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 thetrick> 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). Thatis> 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 "hostX"> 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 prefixlen64> 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 bebuilt> > 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"
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"
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-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-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >