The patch works. Thanks.
On Mon, 14 Dec 2009, Li, Qing wrote:
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-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-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
