Understanding multiple IPv6 interfaces under 8.0 (fwd)
Li, Qing
qing.li at bluecoat.com
Mon Dec 14 23:00:43 UTC 2009
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 at freebsd.org on behalf of Dennis Glatting
Sent: Mon 12/14/2009 2:03 PM
To: JASSAL Aman
Cc: freebsd-net at 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 at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
More information about the freebsd-net
mailing list