Understanding multiple IPv6 interfaces under 8.0 (fwd)
Dennis Glatting
freebsd at penx.com
Mon Dec 14 23:36:10 UTC 2009
The nd6.c patch is currently compiling.
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-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