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