[f-nsp] Problem with IPv6 anycast

Philipp Geschke foundry-nsp at pgmail.net
Fri Sep 3 04:01:07 EDT 2010


Hi,

Thank you for your reply!

On Thu, 2 Sep 2010 14:20:35 -0400, harbor235 <harbor235 at gmail.com> wrote:
> On Thu, Sep 2, 2010 at 2:16 PM, harbor235 <harbor235 at gmail.com> wrote:
> 
>> I have a couple questions too;
>>
>> 1) Can you allocate additional anycast addresses out of the unicast
space
>> other than the 127-n bits identified? (n bits = subnet prefix)
>>

If I get you correct (sorry if not, I am not a native speaker ;-)), then
"ipv6 address 2001:db8:f1:c:1:2:3:fe/64 anycast" qualifies for this test?
The result is pretty much the same, with the interesting fact, that the
MLX announces it Link-Local address now:

09:55:10.233664 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32)
2001:db8:f1:c::160 > ff02::1:ff03:fe: [icmp6 sum ok] ICMP6, neighbor
solicitation, length 32, who has 2001:db8:f1:c:1:2:3:fe
          source link-address option (1), length 8 (1): 00:16:3e:19:16:a9
            0x0000:  0016 3e19 16a9
09:55:10.233664 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload
length: 32) fe80::20c:dbff:fee1:2f00 > 2001:db8:f1:c::160: [icmp6 sum ok]
ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:dbff:fee1:2f00,
Flags [router, solicited, override]
          destination link-address option (2), length 8 (1):
00:0c:db:e1:2f:00
            0x0000:  000c dbe1 2f00

>> 2) how does your client machine behave when a reservered anycast
address
>> is
>> used?
>>
>        all bits of the interface identifier are set to ones except the
last
> 7 bits which range in
>        value from 0-125 (126 and 127 are reserverd or assigned)
>

Using "ipv6 address 2001:db8:f1:c:ffff:ffff:ffff:ff7a/64 anycast", which,
I think, qualifies for this test?

09:17:09.939237 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32)
2001:db8:f1:c::160 > ff02::1:ffff:ff7a: [icmp6 sum ok] ICMP6, neighbor
solicitation, length 32, who has 2001:db8:f1:c:ffff:ffff:ffff:ff7a
          source link-address option (1), length 8 (1): 00:16:3e:19:16:a9
            0x0000:  0016 3e19 16a9
09:17:09.939237 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload
length: 32) fe80::20c:dbff:fee1:2f00 > 2001:db8:f1:c::160: [icmp6 sum ok]
ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:dbff:fee1:2f00,
Flags [router, solicited, override]
          destination link-address option (2), length 8 (1):
00:0c:db:e1:2f:00
            0x0000:  000c dbe1 2f00

 
>    3) What OS was the original client machine?

Everything used in my tests is either NI MLX with IronWare 05000b or plain
Debian GNU/Linux Lenny:

# uname -r
2.6.26-2-amd64


Thanks for your help!

Regards,
Philipp

> 
> 
> harbor235 ;}
> 
>>
>>
>>
>> On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke
>> <foundry-nsp at pgmail.net>wrote:
>>
>>> Hello,
>>>
>>> I seem to have issues understanding IPv6 anycast on NI MLX/XMR.
>>> My understanding is, that any router that does have an IPv6 address in
a
>>> subnet should be listening on the Subnet-Router anycast address
(RFC3513
>>> section 2.6.1).
>>>
>>> When I configure an IPv6 unicast address on a MLX VE it shows that it
>>> joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]):
>>>
>>> Interface VE 200 is up, line protocol is up
>>>  [...]
>>>  IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00
>>> [Preferred]
>>>  Global unicast address(es):
>>>    2001:db8:f1:c::2 [Preferred],  subnet is 2001:db8:f1:c::/64
>>>    2001:db8:f1:c:: [Anycast],  subnet is 2001:db8:f1:c::/64
>>>    2001:db8:f1:c::1 [Anycast],  subnet is 2001:db8:f1:c::/64
>>>    2001:db8:f1:c:: [Anycast],  subnet is 2001:db8:f1:c::/64
>>>  Joined group address(es):
>>>    ff02::1:ff00:1
>>>    ff02::1:ff00:0
>>>    ff02::1:ff00:2
>>>    ff02::1:ffe1:2f00
>>>    ff02::2
>>>    ff02::1
>>>  [...]
>>>
>>> Now when I try to ping that address from a client within the network
>>> 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX
>>> announcing
>>> it's UNIcast address:
>>>
>>> 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
>>> 32)
>>> 2001:db8:f1:c::160 > ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor
>>> solicitation, length 32, who has 2001:db8:f1:c::
>>>          source link-address option (1), length 8 (1):
00:16:3e:19:16:a9
>>>            0x0000:  0016 3e19 16a9
>>> 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58)
>>> payload
>>> length: 32) 2001:db8:f1:c::2 > 2001:db8:f1:c::160: [icmp6 sum ok]
ICMP6,
>>> neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags
>>> [router,
>>> solicited]
>>>          destination link-address option (2), length 8 (1):
>>> 00:0c:db:e1:2f:00
>>>            0x0000:  000c dbe1 2f00
>>>
>>> This causes the asking client to create an entry in its neighbour
cache
>>> for the routers unicast address, but not realising, that this was the
>>> answer to its question, hence it keeps on sending solicitation
messages
>>> for
>>> the anycast address.
>>> In my understanding the neighbour advertisement should have the
unicast
>>> address as source, but should announce the anycast address.
>>>
>>> If I take a Linux box and enable ip6 forwarding in the kernel, it also
>>> joins that very same anycast group. If I do the same test again, you
can
>>> see,
>>> that the Linux box answers with its unicast address, announcing the
>>> anycast address:
>>>
>>> 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
>>> 32)
>>> 2001:db8:f1:c::160 > 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor
>>> advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router,
>>> solicited]
>>>          destination link-address option (2), length 8 (1):
>>> 00:16:3e:19:16:a9
>>>            0x0000:  0016 3e19 16a9
>>>
>>> This works and the client creates an entry in its neighbour cache for
>>> the
>>> anycast address and can now communicate with the address.
>>>
>>> Same goes for the explicitly configured anycast address
2001:db8:f1:c::1
>>> you can see in the output of the interface.
>>>
>>> If it matters, I do have ipv6 nd suppress-ra active on that VE.
>>>
>>>
>>> So what does this mean, is it
>>>
>>> a) Me not understanding the concept of the anycast address (basicaly I
>>> want to use it as a default gateway)?
>>> b) A problem with my configuration (which is pretty plain for v6 right
>>> now)?
>>> c) A bug?
>>> d) ??
>>>
>>> Does anyone have experience with that they are able to share?
>>>
>>>
>>> Thanks for any hints,
>>> Philipp
>>>
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp at puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>
>>


More information about the foundry-nsp mailing list