Saturday, October 10, 2009

Cisco ICMP6 strange behavior on neighbor solicitations.

I noticed some strange behavior while I was playing with IPv6 on my Cisco lab. I have a Debian server hanging off one of the router interfaces acting as a name server. I found that I could ping and resolve against the name server from the router that is directly attached. However, if I try to ping or resolve from a router further away I get no luck. After I corrected the prefix length on the name servers route to the lab network (off by one bit) I still had no luck; even though I could ping another Debian box on the same subnet without a problem. A little investigation with tcpdump yielded this:

11:23:19.360378 IP6 fe80::215:63ff:fe56:cf1d > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:4978:34a::1, length 32
11:23:22.315487 IP6 2001:4978:34a::ff > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:4978:34a::1, length 32
11:23:22.315645 IP6 2001:4978:34a::1 > 2001:4978:34a::ff: ICMP6, neighbor advertisement, tgt is 2001:4978:34a::1, length 32

What we have here are two NDP Neighbor Solicitation messages. Both messages come from the edge router on the Cisco lab. The first message was sent when I pinged from inside the lab network; the second was sent when I pinged from the edge router directly. The difference is that when the edge router needed the name server MAC address for the routed packet it used its link local address. When it needed it for its own packet it used the global unicast packet on the interface. Why does this make a difference? Because the default INPUT policy on the name server ip6tables is DROP, and I had not thought to explicitly allow the link local subnet, causing the first neighbor solicitation to be dropped.

Repeating the experiment, this time pinging from the edge router first, both routers' pings succeed, since by the time the inside routers packets come through there is already a neighbor/ARP entry.

I'm not sure why Cisco would do things this way, maybe there is a logical reason. Maybe it is a bug and no one does goofy things like I do so it has gone unnoticed. Maybe it has been corrected in a more recent version of firmware (the edge router runs 1841 Software (C1841-ADVIPSERVICESK9-M), Version 12.4(12)).

No comments:

Post a Comment