Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: foundry

Problem with IPv6 anycast

 

 

nsp foundry RSS feed   Index | Next | Previous | View Threaded


foundry-nsp at pgmail

Sep 2, 2010, 4:53 AM

Post #1 of 13 (3204 views)
Permalink
Problem with IPv6 anycast

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
http://puck.nether.net/mailman/listinfo/foundry-nsp


harbor235 at gmail

Sep 2, 2010, 11:16 AM

Post #2 of 13 (3151 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Good question, RFC2526 hs more meat concerning anycast reserver addresses, 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?

2) how does your client machine behave when a reservered anycast address is
used?



On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke <foundry-nsp [at] pgmail>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
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>


harbor235 at gmail

Sep 2, 2010, 11:20 AM

Post #3 of 13 (3135 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

There is more .......

On Thu, Sep 2, 2010 at 2:16 PM, harbor235 <harbor235 [at] gmail> wrote:

> Good question, RFC2526 hs more meat concerning anycast reserver addresses,
> 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)
>
> 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)

3) What OS was the original client machine?


harbor235 ;}

>
>
>
> On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke <foundry-nsp [at] pgmail>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
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>


foundry-nsp at pgmail

Sep 3, 2010, 1:01 AM

Post #4 of 13 (3190 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Hi,

Thank you for your reply!

On Thu, 2 Sep 2010 14:20:35 -0400, harbor235 <harbor235 [at] gmail> wrote:
> On Thu, Sep 2, 2010 at 2:16 PM, harbor235 <harbor235 [at] gmail> 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>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
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>
>>
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


dana at zeroloops

Sep 3, 2010, 1:46 AM

Post #5 of 13 (3118 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Hello,

Let me share this information (from Brocade TAC).

"""""
Code 5.1 will have support for vrrp-e and vrrpv3 for IPv6.
Current schedule for the code is by end of September.
"""""

However, Brocade will support vrrpv3 + vrrp-e for IPv6 only in the
Netiron models for now (code 5.1). Unfortunately, for any other models,
they do not have any plans yet whether they are going to support this.
On the other hand, I need this support for our BigIron RXes, but I get
the following reply:

"""""
I just got words from the developers where it is mentioned that
Engineering is planning very limited enhancements in RX code; therefore,
no plans to support this feature on RX platform. This is a case where
customer may submit a feature request for this protocol to be included
in a future code release.

For a workaround, they were no sure how could be done, if there is no
way to test reliable.

Let you know
"""""


Another reply was:


"""""
First.
To submit a Feature Request, please talk to our account team in your
area, I think you have that information available about who are those
persons.

They will then communicate with our developers to see the course of action.

I agree with you tha IPv6 is being used more and more by our customer
specially in Europe. Not having support for VRRP and IPv6 make this
system somehow limited for redundancy.

I did a brain storming with our team here, and no solution possible to
make redundancy like VRRP
"""""


Dana





Dana


ZeroLoops - Webhosting Provider
http://www.zeroloops.com
dana [at] zeroloops
+31 62 692 5403


On 9/3/2010 10:01 AM, Philipp Geschke wrote:
> Hi,
>
> Thank you for your reply!
>
> On Thu, 2 Sep 2010 14:20:35 -0400, harbor235<harbor235 [at] gmail> wrote:
>> On Thu, Sep 2, 2010 at 2:16 PM, harbor235<harbor235 [at] gmail> 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>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
>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>
>>>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


foundry-nsp at pgmail

Sep 3, 2010, 7:52 AM

Post #6 of 13 (3103 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Hi,

On Fri, 03 Sep 2010 10:46:44 +0200, Dana <dana [at] zeroloops> wrote:
> """""
> Code 5.1 will have support for vrrp-e and vrrpv3 for IPv6.
> Current schedule for the code is by end of September.
> """""

Thanks for sharing this information. The lack of VRRP support for v6 was
the reason why I turned to the subnet router anycast address in the first
place.
If 5.1 will support VRRPv3 then I will most likely just wait for that. But
still this does not explain to me, why the MLX has such a strange behaviour
on the subnet router anycast address.


If no one else has an idea, I will propably open a bug report.


Thanks,
Philipp

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


wido at widodh

Nov 30, 2010, 5:15 AM

Post #7 of 13 (2917 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Hi,

I've found this great mailinglist in my quest to get a redundant IPv6
setup.

I found this thread:
https://puck.nether.net/pipermail/foundry-nsp/2010-September/002637.html

We recently (3 months ago) purchased two brand new RX-8's from Brocade
and had to find out that VRRPv3 with IPv6 is not supported.

One of our network administrators found out that anycast might be a
solution, well, it partially is. A Windows machine does work, but a
Linux machine won't accept the anycast address as a gateway (Or even
ping it.)

After some searching I found this thread, hoping for a solution.

Right now we are looking into using RA's with a low lifetime, but that's
imho not the thing I want, since I want some static configurations on my
machines.

Has anybody made any progress with using anycast as a gateway for a
Linux machine? Kernel tweaks / settings which make it work?

With kind regards,

Wido den Hollander

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


foundry-nsp at pgmail

Nov 30, 2010, 5:49 AM

Post #8 of 13 (2913 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Hi,

On Tue, 30 Nov 2010 14:15:20 +0100, Wido den Hollander <wido [at] widodh>
wrote:
> One of our network administrators found out that anycast might be a
> solution, well, it partially is. A Windows machine does work, but a
> Linux machine won't accept the anycast address as a gateway (Or even
> ping it.)

A current Linux should accept the anycast address without any issues. Did
you have a look at the ICMP packets that get exchanged during Neighbour
Solicitation?
All Brocade devices I have under my administration do not handle IPv6
Neighbour Discorvery correctly (sad...), so maybe the RX8 is also buggy.

> Has anybody made any progress with using anycast as a gateway for a
> Linux machine? Kernel tweaks / settings which make it work?

If you have a gateway that handles ND correctly Linux accepts that just
fine, so I don't think that you need any Kernel tweaks.


Regards,
Philipp

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


wido at widodh

Nov 30, 2010, 6:36 AM

Post #9 of 13 (2983 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Hi Philipp,

Well, In my setup it is not working.

I have a /64, where ::1 is my first router, ::2 my second and ::3 a
anycast address.

I'm trying to use ::3 as my default gateway, so that when one of the
RX-8's goes down, my Linux machines (2.6.32 kernel) still have
connectivity.

When analyzing the traffic with Wireshark I see that the RX-8 responds
to the ND with it's unicast address, the ::2 in this case.

In the original thread I saw the same behaviour:

https://puck.nether.net/pipermail/foundry-nsp/2010-September/002637.html

Quote:
"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:"

"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."

That's the issue I'm seeing here too.

Strange thing is, a Windows 2k3 machine works fine with the anycast address as it's default gateway.

Regards,

Wido den Hollander

On Tue, 2010-11-30 at 14:49 +0100, Philipp Geschke wrote:
> Hi,
>
> On Tue, 30 Nov 2010 14:15:20 +0100, Wido den Hollander <wido [at] widodh>
> wrote:
> > One of our network administrators found out that anycast might be a
> > solution, well, it partially is. A Windows machine does work, but a
> > Linux machine won't accept the anycast address as a gateway (Or even
> > ping it.)
>
> A current Linux should accept the anycast address without any issues. Did
> you have a look at the ICMP packets that get exchanged during Neighbour
> Solicitation?
> All Brocade devices I have under my administration do not handle IPv6
> Neighbour Discorvery correctly (sad...), so maybe the RX8 is also buggy.
>
> > Has anybody made any progress with using anycast as a gateway for a
> > Linux machine? Kernel tweaks / settings which make it work?
>
> If you have a gateway that handles ND correctly Linux accepts that just
> fine, so I don't think that you need any Kernel tweaks.
>
>
> Regards,
> Philipp
>

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


foundry-nsp at pgmail

Nov 30, 2010, 9:24 AM

Post #10 of 13 (2916 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Hello,

On Tue, 30 Nov 2010 15:36:20 +0100, Wido den Hollander <wido [at] widodh>
wrote:
> When analyzing the traffic with Wireshark I see that the RX-8 responds
> to the ND with it's unicast address, the ::2 in this case.

Depending on what you mean this is a wrong behaviour.
The router MUST respond with it's UNIcast address as source address (as
anycast addresses must not be the source address of an IPv6 packet, see
RFC
3513 section 2.6) but the Target field of the ICMP message MUST be the
Target field of the Neighbor solicitation that prompted the advertisement
(See RFC2461 Section 4.4). If you specified the anycast address as the
gateway this should be the anycast address.

So a correct Neighbor Solicitation for an IPv6 anycast address with a
Linux client that has ::10 would basically look like this:

Client: Source ::10, Target field ::3
Router: Source ::2, Target field ::3

This would work with Linux, at least tested with Debian.

What NI MLX does is:

Client: Source ::10, Target field ::3
Router: Source ::2, Target field ::2

This will not work and is a bug. I have opened a bug report with Brocade
and it's a confirmed defect.

If you want, send me a pcap or tcpdump output of your Neighbor
Solicitation and I will tell you what the RX does wrong.

> Strange thing is, a Windows 2k3 machine works fine with the anycast
> address as it's default gateway.

I have no working knowledge of IPv6 behaviour of Windows, so I really
can't tell you why it is working. :(


Regards,
Philipp



_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


wido at widodh

Nov 30, 2010, 10:01 AM

Post #11 of 13 (2937 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Hi Philipp,

Attached is my pcap from Wireshark.

My subnet is: 2a00:f10:10a:5::/64

RX-8 #1: 2a00:f10:010a:5::1
RX-8 #2: 2a00:f10:010a:5::2
Anycast: 2a00:f10:010a:5::3

My client: 2a00:f10:010a:5:0:1337:6:79

If you check the pcap file, it seems that the RX is responding
incorrect, isn't it?

As you can see, the ::3 address is working fine on the internet (You can
ping it), but not in the local network.

Is this a bug in RX-8?

Regards,

Wido

On Tue, 2010-11-30 at 18:24 +0100, Philipp Geschke wrote:
> Hello,
>
> On Tue, 30 Nov 2010 15:36:20 +0100, Wido den Hollander <wido [at] widodh>
> wrote:
> > When analyzing the traffic with Wireshark I see that the RX-8 responds
> > to the ND with it's unicast address, the ::2 in this case.
>
> Depending on what you mean this is a wrong behaviour.
> The router MUST respond with it's UNIcast address as source address (as
> anycast addresses must not be the source address of an IPv6 packet, see
> RFC
> 3513 section 2.6) but the Target field of the ICMP message MUST be the
> Target field of the Neighbor solicitation that prompted the advertisement
> (See RFC2461 Section 4.4). If you specified the anycast address as the
> gateway this should be the anycast address.
>
> So a correct Neighbor Solicitation for an IPv6 anycast address with a
> Linux client that has ::10 would basically look like this:
>
> Client: Source ::10, Target field ::3
> Router: Source ::2, Target field ::3
>
> This would work with Linux, at least tested with Debian.
>
> What NI MLX does is:
>
> Client: Source ::10, Target field ::3
> Router: Source ::2, Target field ::2
>
> This will not work and is a bug. I have opened a bug report with Brocade
> and it's a confirmed defect.
>
> If you want, send me a pcap or tcpdump output of your Neighbor
> Solicitation and I will tell you what the RX does wrong.
>
> > Strange thing is, a Windows 2k3 machine works fine with the anycast
> > address as it's default gateway.
>
> I have no working knowledge of IPv6 behaviour of Windows, so I really
> can't tell you why it is working. :(
>
>
> Regards,
> Philipp
>
>
>
Attachments: bond0.pcap (22.7 KB)


foundry-nsp at pgmail

Nov 30, 2010, 10:52 AM

Post #12 of 13 (2921 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Hi Wido,

Yes, the combination of responding with Target: 2a00:f10:10a:5::2
(2a00:f10:10a:5::2) and setting the solicited bit to 1 is a violation of
RFC2461 Section 4.4.

I suggest you contact whoever you have a support contract for the RX with
and ask them about it. Expect resistance, because unfortunately only few
contractors have a good knowledge of IPv6.
It is the same behaviour Netiron MLX/XMR shows.


Regards,
Philipp

On Tue, 30 Nov 2010 19:01:57 +0100, Wido den Hollander <wido [at] widodh>
wrote:
> Hi Philipp,
>
> Attached is my pcap from Wireshark.
>
> My subnet is: 2a00:f10:10a:5::/64
>
> RX-8 #1: 2a00:f10:010a:5::1
> RX-8 #2: 2a00:f10:010a:5::2
> Anycast: 2a00:f10:010a:5::3
>
> My client: 2a00:f10:010a:5:0:1337:6:79
>
> If you check the pcap file, it seems that the RX is responding
> incorrect, isn't it?
>
> As you can see, the ::3 address is working fine on the internet (You can
> ping it), but not in the local network.
>
> Is this a bug in RX-8?
>
> Regards,
>
> Wido
>
> On Tue, 2010-11-30 at 18:24 +0100, Philipp Geschke wrote:
>> Hello,
>>
>> On Tue, 30 Nov 2010 15:36:20 +0100, Wido den Hollander <wido [at] widodh>
>> wrote:
>> > When analyzing the traffic with Wireshark I see that the RX-8
responds
>> > to the ND with it's unicast address, the ::2 in this case.
>>
>> Depending on what you mean this is a wrong behaviour.
>> The router MUST respond with it's UNIcast address as source address (as
>> anycast addresses must not be the source address of an IPv6 packet, see
>> RFC
>> 3513 section 2.6) but the Target field of the ICMP message MUST be the
>> Target field of the Neighbor solicitation that prompted the
advertisement
>> (See RFC2461 Section 4.4). If you specified the anycast address as the
>> gateway this should be the anycast address.
>>
>> So a correct Neighbor Solicitation for an IPv6 anycast address with a
>> Linux client that has ::10 would basically look like this:
>>
>> Client: Source ::10, Target field ::3
>> Router: Source ::2, Target field ::3
>>
>> This would work with Linux, at least tested with Debian.
>>
>> What NI MLX does is:
>>
>> Client: Source ::10, Target field ::3
>> Router: Source ::2, Target field ::2
>>
>> This will not work and is a bug. I have opened a bug report with
Brocade
>> and it's a confirmed defect.
>>
>> If you want, send me a pcap or tcpdump output of your Neighbor
>> Solicitation and I will tell you what the RX does wrong.
>>
>> > Strange thing is, a Windows 2k3 machine works fine with the anycast
>> > address as it's default gateway.
>>
>> I have no working knowledge of IPv6 behaviour of Windows, so I really
>> can't tell you why it is working. :(
>>
>>
>> Regards,
>> Philipp
>>
>>
>>
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


wido at widodh

Dec 1, 2010, 2:57 AM

Post #13 of 13 (2911 views)
Permalink
Re: Problem with IPv6 anycast [In reply to]

Hi Philipp,

Thank you! I'll get in touch with Brocade and address this issue.

Regards,

Wido

On Tue, 2010-11-30 at 19:52 +0100, Philipp Geschke wrote:
> Hi Wido,
>
> Yes, the combination of responding with Target: 2a00:f10:10a:5::2
> (2a00:f10:10a:5::2) and setting the solicited bit to 1 is a violation of
> RFC2461 Section 4.4.
>
> I suggest you contact whoever you have a support contract for the RX with
> and ask them about it. Expect resistance, because unfortunately only few
> contractors have a good knowledge of IPv6.
> It is the same behaviour Netiron MLX/XMR shows.
>
>
> Regards,
> Philipp
>
> On Tue, 30 Nov 2010 19:01:57 +0100, Wido den Hollander <wido [at] widodh>
> wrote:
> > Hi Philipp,
> >
> > Attached is my pcap from Wireshark.
> >
> > My subnet is: 2a00:f10:10a:5::/64
> >
> > RX-8 #1: 2a00:f10:010a:5::1
> > RX-8 #2: 2a00:f10:010a:5::2
> > Anycast: 2a00:f10:010a:5::3
> >
> > My client: 2a00:f10:010a:5:0:1337:6:79
> >
> > If you check the pcap file, it seems that the RX is responding
> > incorrect, isn't it?
> >
> > As you can see, the ::3 address is working fine on the internet (You can
> > ping it), but not in the local network.
> >
> > Is this a bug in RX-8?
> >
> > Regards,
> >
> > Wido
> >
> > On Tue, 2010-11-30 at 18:24 +0100, Philipp Geschke wrote:
> >> Hello,
> >>
> >> On Tue, 30 Nov 2010 15:36:20 +0100, Wido den Hollander <wido [at] widodh>
> >> wrote:
> >> > When analyzing the traffic with Wireshark I see that the RX-8
> responds
> >> > to the ND with it's unicast address, the ::2 in this case.
> >>
> >> Depending on what you mean this is a wrong behaviour.
> >> The router MUST respond with it's UNIcast address as source address (as
> >> anycast addresses must not be the source address of an IPv6 packet, see
> >> RFC
> >> 3513 section 2.6) but the Target field of the ICMP message MUST be the
> >> Target field of the Neighbor solicitation that prompted the
> advertisement
> >> (See RFC2461 Section 4.4). If you specified the anycast address as the
> >> gateway this should be the anycast address.
> >>
> >> So a correct Neighbor Solicitation for an IPv6 anycast address with a
> >> Linux client that has ::10 would basically look like this:
> >>
> >> Client: Source ::10, Target field ::3
> >> Router: Source ::2, Target field ::3
> >>
> >> This would work with Linux, at least tested with Debian.
> >>
> >> What NI MLX does is:
> >>
> >> Client: Source ::10, Target field ::3
> >> Router: Source ::2, Target field ::2
> >>
> >> This will not work and is a bug. I have opened a bug report with
> Brocade
> >> and it's a confirmed defect.
> >>
> >> If you want, send me a pcap or tcpdump output of your Neighbor
> >> Solicitation and I will tell you what the RX does wrong.
> >>
> >> > Strange thing is, a Windows 2k3 machine works fine with the anycast
> >> > address as it's default gateway.
> >>
> >> I have no working knowledge of IPv6 behaviour of Windows, so I really
> >> can't tell you why it is working. :(
> >>
> >>
> >> Regards,
> >> Philipp
> >>
> >>
> >>

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

nsp foundry RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.