[f-nsp] Problem with IPv6 anycast
Dana
dana at zeroloops.com
Fri Sep 3 04:46:44 EDT 2010
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.com
+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.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
>>>>
>>>
> _______________________________________________
> 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