IPv6 on Cisco 877 and clients - strange intermittent connectivity

[jimb]

Since I can't see the whole config, I don't know what he has.  I think you need "ipv6 unicast routing" or something like that.

From the packet sniffs, it looks like he has some HP Procurve switches.  From glancing at the docs, it looks like they do multicast forwarding by default, but didn't give it a good read, just a glance.

@growse: you may want to take a gander at this: http://cdn.procurve.com/training/Manuals/2900-3500-5400-6200-8200-IPv6-Jan08-7-MLD.pdf

Not sure what's plugged into what though.  I presume the router has a built in switch?  If so, are the affected machines plugged into the built in?  Into another switch connected to it?  Are the switches on the right vlan (I imagine so since it sometimes works).  Anywayz, at this point it looks like a layer-2 problem, unless the router is actually receiving the mcast neighbor solicitations and ignoring them for some reason.

[cholzhauer]

I'm running a bunch of procurve switches here at work and they're working great with IPv6.  If you are indeed using Procurve switches, make sure you're running at least a 13.xx firmware, or better yet, the 14.xx

[chiel]

I fixed it for my situation. It was indeed the problem with the "Router Advertisement" like jimb pointed out. I opened a Wireshark on both my Windows laptop and on my Ubuntu laptop. I noticed that on every "Neighbor Solicitation" Ubuntu sent a "Router Advertisement" was returned by the Cisco router. This was not the case on the Windows laptop that did sent out Neighbor Solicitation but not always received a Router advertisement (just like you can see in the pcap from growse), it only received a Router advertisement once in like 2 minutes and then I could use IPv6 for a little wile.
I entered the following command on Vlan 1 of the Cisco router:

Code Select Expand

ipv6 nd ra interval 4

This will force the router to sent a Router advertisement every 4 seconds. For now it is (temporarily)fixed for me, but I keep finding it strange that this behavior does not occur on the Ubuntu system. The systems are connected directly to the Cisco router which has a four port switch, I also swapped the Ethernet cables.
growse can you tell if this also works for you?

Btw, is there a default for the Router Advertisement interval?

[jimb]

I fixed it for my situation. It was indeed the problem with the "Router Advertisement" like jimb pointed out. I opened a Wireshark on both my Windows laptop and on my Ubuntu laptop. I noticed that on every "Neighbor Solicitation" Ubuntu sent a "Router Advertisement" was returned by the Cisco router. This was not the case on the Windows laptop that did sent out Neighbor Solicitation but not always received a Router advertisement (just like you can see in the pcap from growse), it only received a Router advertisement once in like 2 minutes and then I could use IPv6 for a little wile.
I entered the following command on Vlan 1 of the Cisco router:

Code Select Expand

ipv6 nd ra interval 4

This will force the router to sent a Router advertisement every 4 seconds. For now it is (temporarily)fixed for me, but I keep finding it strange that this behavior does not occur on the Ubuntu system. The systems are connected directly to the Cisco router which has a four port switch, I also swapped the Ethernet cables.
growse can you tell if this also works for you?

Btw, is there a default for the Router Advertisement interval?

That's very odd.  Neighbor Solicitations should be answered by Neighbor Announcements.  Router Advertisements, as far as I understand, are just to announce the presence of a router on the link, and is also used for stateless autoconfig.

One test would be to swap ports on the ubuntu and windows systems.  If the ubuntu sys starts behaving like the windows system, it's probably the configuration of your ports/VLANs etc.  I'm wondering if the ports are all members of the VLAN which the router interface is on, although I don't know how it'd ever work if it wasn't.  It's almost as if the router isn't hearing the multicast neighbor solicitations, or the windows box isn't hearing the replies. 

You also may want to turn on ND debugging on the Cisco and see if you can see the solicitations when they are sent out by the windows box.  (debug ipv6 nd ... ND stuff should then show up on the console and in the log file).

For an example of what it should look like, here's some txt of ND/NA captures on my LAN:

Code Select Expand

No.     Time        Source                Destination           Protocol Info
      2 26.139155   2001:db8:1234:0:213:ceff:fe9b:2d70 ff02::1:ff6d:5aa4     ICMPv6   Neighbor solicitation

Frame 2 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: IntelCor_9b:2d:70 (00:13:ce:9b:2d:70), Dst: IPv6mcast_ff:6d:5a:a4 (33:33:ff:6d:5a:a4)
Internet Protocol Version 6
Internet Control Message Protocol v6
    Type: 135 (Neighbor solicitation)
    Code: 0
    Checksum: 0x77f6 [correct]
    Target: 2001:db8:1234:0:201:2ff:fe6d:5aa4 (2001:db8:1234:0:201:2ff:fe6d:5aa4)
    ICMPv6 Option (Source link-layer address)
        Type: Source link-layer address (1)
        Length: 8
        Link-layer address: 00:13:ce:9b:2d:70

No.     Time        Source                Destination           Protocol Info
      3 26.140036   2001:db8:1234:0:201:2ff:fe6d:5aa4 2001:db8:1234:0:213:ceff:fe9b:2d70 ICMPv6   Neighbor advertisement

Frame 3 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 3com_6d:5a:a4 (00:01:02:6d:5a:a4), Dst: IntelCor_9b:2d:70 (00:13:ce:9b:2d:70)
Internet Protocol Version 6
Internet Control Message Protocol v6
    Type: 136 (Neighbor advertisement)
    Code: 0
    Checksum: 0x0863 [correct]
    Flags: 0x60000000
    Target: 2001:db8:1234:0:201:2ff:fe6d:5aa4 (2001:db8:1234:0:201:2ff:fe6d:5aa4)
    ICMPv6 Option (Target link-layer address)
        Type: Target link-layer address (2)
        Length: 8
        Link-layer address: 00:01:02:6d:5a:a4

No.     Time        Source                Destination           Protocol Info
     10 31.140460   fe80::201:2ff:fe6d:5aa4 2001:db8:1234:0:213:ceff:fe9b:2d70 ICMPv6   Neighbor solicitation

Frame 10 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 3com_6d:5a:a4 (00:01:02:6d:5a:a4), Dst: IntelCor_9b:2d:70 (00:13:ce:9b:2d:70)
Internet Protocol Version 6
Internet Control Message Protocol v6
    Type: 135 (Neighbor solicitation)
    Code: 0
    Checksum: 0x7479 [correct]
    Target: 2001:db8:1234:0:213:ceff:fe9b:2d70 (2001:db8:1234:0:213:ceff:fe9b:2d70)
    ICMPv6 Option (Source link-layer address)
        Type: Source link-layer address (1)
        Length: 8
        Link-layer address: 00:01:02:6d:5a:a4

No.     Time        Source                Destination           Protocol Info
     11 31.140491   2001:db8:1234:0:213:ceff:fe9b:2d70 fe80::201:2ff:fe6d:5aa4 ICMPv6   Neighbor advertisement

Frame 11 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: IntelCor_9b:2d:70 (00:13:ce:9b:2d:70), Dst: 3com_6d:5a:a4 (00:01:02:6d:5a:a4)
Internet Protocol Version 6
Internet Control Message Protocol v6
    Type: 136 (Neighbor advertisement)
    Code: 0
    Checksum: 0x736c [correct]
    Flags: 0x60000000
    Target: 2001:db8:1234:0:213:ceff:fe9b:2d70 (2001:db8:1234:0:213:ceff:fe9b:2d70)
    ICMPv6 Option (Target link-layer address)
        Type: Target link-layer address (2)
        Length: 8
        Link-layer address: 00:13:ce:9b:2d:70

No.     Time        Source                Destination           Protocol Info
     12 71.851767   2001:db8:1234:0:213:ceff:fe9b:2d70 ff02::1:ff00:1        ICMPv6   Neighbor solicitation

Frame 12 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: IntelCor_9b:2d:70 (00:13:ce:9b:2d:70), Dst: IPv6mcast_ff:00:00:01 (33:33:ff:00:00:01)
Internet Protocol Version 6
Internet Control Message Protocol v6
    Type: 135 (Neighbor solicitation)
    Code: 0
    Checksum: 0x3118 [correct]
    Target: 2001:db8:1234::1 (2001:db8:1234::1)
    ICMPv6 Option (Source link-layer address)
        Type: Source link-layer address (1)
        Length: 8
        Link-layer address: 00:13:ce:9b:2d:70

No.     Time        Source                Destination           Protocol Info
     13 71.853007   2001:db8:1234::1      2001:db8:1234:0:213:ceff:fe9b:2d70 ICMPv6   Neighbor advertisement

Frame 13 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 3com_53:65:64 (00:50:da:53:65:64), Dst: IntelCor_9b:2d:70 (00:13:ce:9b:2d:70)
Internet Protocol Version 6
Internet Control Message Protocol v6
    Type: 136 (Neighbor advertisement)
    Code: 0
    Checksum: 0x618f [correct]
    Flags: 0xe0000000
    Target: 2001:db8:1234::1 (2001:db8:1234::1)
    ICMPv6 Option (Target link-layer address)
        Type: Target link-layer address (2)
        Length: 8
        Link-layer address: 00:50:da:53:65:64

No.     Time        Source                Destination           Protocol Info
     18 76.851330   fe80::250:daff:fe53:6564 2001:db8:1234:0:213:ceff:fe9b:2d70 ICMPv6   Neighbor solicitation

Frame 18 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 3com_53:65:64 (00:50:da:53:65:64), Dst: IntelCor_9b:2d:70 (00:13:ce:9b:2d:70)
Internet Protocol Version 6
Internet Control Message Protocol v6
    Type: 135 (Neighbor solicitation)
    Code: 0
    Checksum: 0xae8d [correct]
    Target: 2001:db8:1234:0:213:ceff:fe9b:2d70 (2001:db8:1234:0:213:ceff:fe9b:2d70)
    ICMPv6 Option (Source link-layer address)
        Type: Source link-layer address (1)
        Length: 8
        Link-layer address: 00:50:da:53:65:64

No.     Time        Source                Destination           Protocol Info
     19 76.851354   2001:db8:1234:0:213:ceff:fe9b:2d70 fe80::250:daff:fe53:6564 ICMPv6   Neighbor advertisement

Frame 19 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: IntelCor_9b:2d:70 (00:13:ce:9b:2d:70), Dst: 3com_53:65:64 (00:50:da:53:65:64)
Internet Protocol Version 6
Internet Control Message Protocol v6
    Type: 136 (Neighbor advertisement)
    Code: 0
    Checksum: 0x9076 [correct]
    Flags: 0x60000000
    Target: 2001:db8:1234:0:213:ceff:fe9b:2d70 (2001:db8:1234:0:213:ceff:fe9b:2d70)
    ICMPv6 Option (Target link-layer address)
        Type: Target link-layer address (2)
        Length: 8
        Link-layer address: 00:13:ce:9b:2d:70


- Jim

[chiel]

Hello,

I did some more testing today. I first remove the configured "ipv6 nd ra interval 4" command, because this was just a temporarily fix.

I start doing some test on Windows Vista using a Ethernet cable directly attached to the Cisco 871W router. I opened Wireshark I noticed the following behavior:

1. I opened a ping to Google: "ping ipv6.google.com".
2. Neighbor Solicitations are sent from the Vista host using the IPV6 Link-Local address to a IPv6 multicast. Messages are not seen by the router using "debug ipv6 nd".
3. No answer is received from the Neighbor Solicitation, resulting in a ping timeout.
4. Once in a while a Router Advertisement is sent from the Cisco 781W router and received by the Windows Vista host.

Code Select Expand


router#show ipv6 neighbors
IPv6 Address                              Age Link-layer Addr State Interface
FE80::3143:BC3F:CC37:84AD                   2 0023.ae16.5735  STALE Vl1
2001:470:1F15:14AB:4886:CA6A:F752:BEFC      2 0023.ae16.5735  STALE Vl1

router#
*Nov  6 2009 21:30:23 UTC: ICMPv6-ND: Request to send RA for FE80::21C:F6FF:FE8C:5632
*Nov  6 2009 21:30:23 UTC: ICMPv6-ND: Sending RA from FE80::21C:F6FF:FE8C:5632 to FF02::1 on Vlan1
*Nov  6 2009 21:30:23 UTC: ICMPv6-ND:     MTU = 1500
*Nov  6 2009 21:30:23 UTC: ICMPv6-ND:     prefix = 2001:470:1F15:14AB::/64 onlink autoconfig
*Nov  6 2009 21:30:23 UTC: ICMPv6-ND:        2592000/604800 (valid/preferred)

router#show ipv6 neighbors
IPv6 Address                              Age Link-layer Addr State Interface
FE80::3143:BC3F:CC37:84AD                   0 0023.ae16.5735  REACH Vl1
2001:470:1F15:14AB:4886:CA6A:F752:BEFC      0 0023.ae16.5735  REACH Vl1


5. The ping to ipv6.google.com starts working.
6. And Neighbor Solicitations and Neighbor Advertisement messages are transported. This time using a Link-Local addresses instead of Global and Mulicast as in step 2.
7. After a while I guess the Router Advertisement that was received in step 4 times out and we are back at step 1.

No traffic is blocked on the Windows Vista host, I checked it on the Ethernet wire using a hub with Wireshark.

I did the same with a Ubuntu 9.10 host using the same wire (and thus port/vlan etc).

1. I opened a ping to Google: "ping ipv6.google.com".
2. Router Solicitations are sent from the Ubuntu host. Messages are not seen by the router using "debug ipv6 nd".
3. No answer is received from the Router Solicitations, resulting in a ping timeout.
4. Once in a while a Router Advertisement is sent from the Cisco 781W router and received by the Ubuntu host.
5. The ping to ipv6.google.com start working.
6. Neighbor Solicitations are sent from the router using the Link-Local address to the Ubuntu host on the Link-Global address.
   Neighbor Advertisements are sent from the Ubuntu host using the Link-Global address to the router on the Link-Local address.
7. IPv6 keeps working, I guess that the Router Advertisement stays active and doesn't time out like it did on the Windows Vista host.


My questions:
- It seems that Neighbor Solicitations are only for a while being processed by the Cisco router after a Router Advertisement has been sent by the router itself. How to fix this?
- Why does Windows Vista sent Neighbor Solicitations and Ubuntu Router Solicitations. Which OS is doing it wrong?
- Must Ubuntu not time out the Router Advertisement that it received in step 7

Attached are the pcap of the Windows host and the Ubuntu hosts, also the router config is attached. Open the pcaps using Wireshark and put in "icmpv6" as display filter.

[jimb]

So the router is not seeing the ND packets, since you're not seeing them in the debug output.  Not sure why this is happening, but perhaps, as I mentioned before, it's some issue with the multicasts not making it to the router?

May want to try hooking one of the problem machines and the router interface to a difference switch, or a hub to see if it starts working.  If so then your switch isn't forwarding the mcast ND requests for whatever reason.

[mrtwrx]

Seems quite similar to my issue in

http://www.tunnelbroker.net/forums/index.php?topic=818.msg4182#new

[mrtwrx]

Interesting that your tuning of the router advertisement interval fixes it, the default lifetime value is 30 minutes!!

Windows must not be honoring this.

More later after ive checked further.

[chiel]

mrtwrx, did you manage to get more information regarding this problem? I know that once I once got "native" IPv6 connectivity to that Windows machine I removed/disabled all Teredo/ISATAP stuff that provided IPv6 tunnels, I only noticed the problems a few months after that. Maybe it has something to do with that and that Windows also disables some other critical components once you disable/remove Teredo/ISATAP stuff.

[jimb]

The more I see this stuff, the more I'm thinking this particular device or the IOS version people are using on them have some sort of bug in the ND area, or multicast processing area.

My theory is that shortening the RA period only masks the problems since the devices on the LAN learn the hardware address of the router via these RAs, while NA/ND is still failing.  If you make the RA interval short enough, that is, shorter than the expiry time on whatever hosts you are running IPv6 on, the MAC will stay in the neighbor table continually.

So this is just masking the real issue.

Now, if you can ping other devices on the same LAN without issue, it's definitely a problem with the router.  If you also have problems pinging other devices, then it points to some sort of layer 2 issue, or perhaps a problem with Windows itself.

Anyway, that's my additional $.02 on this issue.   :)

[cholzhauer]

Interesting.  You mean in this case, it might actually be a good thing that all my ASA's don't run IOS?

;)

[jimb]

Or at least that version of IOS on that hardware. 

I have no similar problems with a Cisco 7200 w/ IOS 12.4 ... OK.  I don't really have one.  It's dynamips.  But it works just fine.  :P

Also, I'd think that the possibility of failure would even be higher on this dynamips virtual cisco, seeing that it's essentially a VM, and it happens to be running under Windows XP (and using cygwin).  :P

Also, you guys may want to post up this question on somewhere with a wider audience, such as the IPv6-ops list, or maybe even NANOG.

[growse]

Hi guys,

Apologies for abandoning this slightly, I'll try to answer some of the points raised. It's good to see that others have raised this issue.

1) I've just enabled nd debugging. Will see what happens.

2) There is indeed a procurve in this network. I'll do my best to try and explain the topology: ADSL connection terminates on Cisco 877 running IOS12.4 with HE tunnel. HP Procurve 1800-8G is then plugged into one of the switchports on the router. Most other hosts are then plugged into this switch, two are LACP enabled (just in case that's throwing a wobbly in somewhere). HP firmware was previously PA02.09, just upgraded to PA03.09.

3) I just enabled ipv6 unicast-routing. Will see what happens.

4) I can always ping other hosts on the network. This is a router issue

5) I had this issue with IOS15 as well. This is what prompted me to figure that IOS15 was buggy, but I've got the same issue in 12.4

6) In the time that I've typed this, I've noticed I've received a lot of link-local RA debug messages. Is this normal? Here's a sample:

Code Select Expand

Mar 14 22:14:33 talkbot 7684: talkbot: 007680: *Dec 21 14:56:37.423 UTC: ICMPv6-ND: PROBE -> REACH: 2001:470:1F09:784:20C:29FF:FEA1:150B
Mar 14 22:14:36 talkbot 7685: talkbot: 007681: *Dec 21 14:56:39.855 UTC: ICMPv6-ND: Request to send RA for FE80::223:4FF:FE11:98BD
Mar 14 22:14:36 talkbot 7686: talkbot: 007682: *Dec 21 14:56:39.855 UTC: ICMPv6-ND: Sending RA from FE80::223:4FF:FE11:98BD to FF02::1 on Vlan1
Mar 14 22:14:36 talkbot 7687: talkbot: 007683: *Dec 21 14:56:39.855 UTC: ICMPv6-ND:     MTU = 1500
Mar 14 22:14:36 talkbot 7688: talkbot: 007684: *Dec 21 14:56:39.855 UTC: ICMPv6-ND:     prefix = 2001:470:1F09:784::/64 onlink autoconfig
Mar 14 22:14:36 talkbot 7689: talkbot: 007685: *Dec 21 14:56:39.855 UTC: ICMPv6-ND: #011     2592000/604800 (valid/preferred)
Mar 14 22:14:37 talkbot 7690: talkbot: 007686: *Dec 21 14:56:41.751 UTC: ICMPv6-ND: DELAY -> PROBE: FE80::20C:29FF:FEA1:150B
Mar 14 22:14:37 talkbot 7691: talkbot: 007687: *Dec 21 14:56:41.751 UTC: ICMPv6-ND: Sending NS for FE80::20C:29FF:FEA1:150B on Vlan1
Mar 14 22:14:37 talkbot 7692: talkbot: 007688: *Dec 21 14:56:41.755 UTC: ICMPv6-ND: Received NA for FE80::20C:29FF:FEA1:150B on Vlan1 from FE80::20C:29FF:FEA1:150B
Mar 14 22:14:37 talkbot 7693: talkbot: 007689: *Dec 21 14:56:41.755 UTC: ICMPv6-ND: PROBE -> REACH: FE80::20C:29FF:FEA1:150B
Mar 14 22:14:39 talkbot 7694: talkbot: 007690: *Dec 21 14:56:43.292 UTC: ICMPv6-ND: Request to send RA for FE80::223:4FF:FE11:98BD
Mar 14 22:14:39 talkbot 7695: talkbot: 007691: *Dec 21 14:56:43.292 UTC: ICMPv6-ND: Sending RA from FE80::223:4FF:FE11:98BD to FF02::1 on Vlan1
Mar 14 22:14:39 talkbot 7696: talkbot: 007692: *Dec 21 14:56:43.292 UTC: ICMPv6-ND:     MTU = 1500
Mar 14 22:14:39 talkbot 7697: talkbot: 007693: *Dec 21 14:56:43.292 UTC: ICMPv6-ND:     prefix = 2001:470:1F09:784::/64 onlink autoconfig
Mar 14 22:14:39 talkbot 7698: talkbot: 007694: *Dec 21 14:56:43.292 UTC: ICMPv6-ND: #011     2592000/604800 (valid/preferred)
Mar 14 22:14:39 talkbot 7699: talkbot: 007695: *Dec 21 14:56:43.420 UTC: ICMPv6-ND: STALE -> DELAY: 2001:470:1F09:784:94A9:11DE:AE:B2CF
Mar 14 22:14:42 talkbot 7700: talkbot: 007696: *Dec 21 14:56:46.340 UTC: %SEC-6-IPACCESSLOGDP: list INTERNET-IN denied icmp 74.55.143.114 -> 93.97.176.164 (0/0), 1 packet
Mar 14 22:14:43 talkbot 7701: talkbot: 007697: *Dec 21 14:56:47.328 UTC: ICMPv6-ND: Request to send RA for FE80::223:4FF:FE11:98BD
Mar 14 22:14:43 talkbot 7702: talkbot: 007698: *Dec 21 14:56:47.328 UTC: ICMPv6-ND: Sending RA from FE80::223:4FF:FE11:98BD to FF02::1 on Vlan1
Mar 14 22:14:43 talkbot 7703: talkbot: 007699: *Dec 21 14:56:47.328 UTC: ICMPv6-ND:     MTU = 1500
Mar 14 22:14:43 talkbot 7704: talkbot: 007700: *Dec 21 14:56:47.328 UTC: ICMPv6-ND:     prefix = 2001:470:1F09:784::/64 onlink autoconfig
Mar 14 22:14:43 talkbot 7705: talkbot: 007701: *Dec 21 14:56:47.328 UTC: ICMPv6-ND: #011     2592000/604800 (valid/preferred)
Mar 14 22:14:43 talkbot 7706: talkbot: 007702: *Dec 21 14:56:47.652 UTC: ICMPv6-ND: REACH -> STALE: 2001:470:1F09:784:20C:29FF:FE7F:19E5
Mar 14 22:14:43 talkbot 7707: talkbot: 007703: *Dec 21 14:56:48.212 UTC: ICMPv6-ND: Received NS for FE80::223:4FF:FE11:98BD on Vlan1 from FE80::F880:F7D2:A3DF:7BE6
Mar 14 22:14:44 talkbot 7708: talkbot: 007704: *Dec 21 14:56:48.212 UTC: ICMPv6-ND: Sending NA for FE80::223:4FF:FE11:98BD on Vlan1
Mar 14 22:14:44 talkbot 7709: talkbot: 007705: *Dec 21 14:56:48.216 UTC: ICMPv6-ND: STALE -> DELAY: FE80::F880:F7D2:A3DF:7BE6
Mar 14 22:14:44 talkbot 7710: talkbot: 007706: *Dec 21 14:56:48.420 UTC: ICMPv6-ND: DELAY -> PROBE: 2001:470:1F09:784:94A9:11DE:AE:B2CF
Mar 14 22:14:44 talkbot 7711: talkbot: 007707: *Dec 21 14:56:48.420 UTC: ICMPv6-ND: Sending NS for 2001:470:1F09:784:94A9:11DE:AE:B2CF on Vlan1
Mar 14 22:14:44 talkbot 7712: talkbot: 007708: *Dec 21 14:56:48.424 UTC: ICMPv6-ND: Received NA for 2001:470:1F09:784:94A9:11DE:AE:B2CF on Vlan1 from 2001:470:1F09:784:94A9:11DE:AE:B2CF
Mar 14 22:14:44 talkbot 7713: talkbot: 007709: *Dec 21 14:56:48.424 UTC: ICMPv6-ND: PROBE -> REACH: 2001:470:1F09:784:94A9:11DE:AE:B2CF
Mar 14 22:14:47 talkbot 7714: talkbot: 007710: *Dec 21 14:56:51.433 UTC: ICMPv6-ND: Request to send RA for FE80::223:4FF:FE11:98BD
Mar 14 22:14:47 talkbot 7715: talkbot: 007711: *Dec 21 14:56:51.433 UTC: ICMPv6-ND: Sending RA from FE80::223:4FF:FE11:98BD to FF02::1 on Vlan1
Mar 14 22:14:47 talkbot 7716: talkbot: 007712: *Dec 21 14:56:51.433 UTC: ICMPv6-ND:     MTU = 1500
Mar 14 22:14:47 talkbot 7717: talkbot: 007713: *Dec 21 14:56:51.433 UTC: ICMPv6-ND:     prefix = 2001:470:1F09:784::/64 onlink autoconfig
Mar 14 22:14:47 talkbot 7718: talkbot: 007714: *Dec 21 14:56:51.433 UTC: ICMPv6-ND: #011     2592000/604800 (valid/preferred)
Mar 14 22:14:47 talkbot 7719: talkbot: 007715: *Dec 21 14:56:52.145 UTC: ICMPv6-ND: REACH -> STALE: FE80::20C:29FF:FE7F:19E5
Mar 14 22:14:48 mailbot spamd[23942]: 190.120.128.47: connected (1/0)
Mar 14 22:14:49 talkbot 7720: talkbot: 007716: *Dec 21 14:56:53.217 UTC: ICMPv6-ND: DELAY -> PROBE: FE80::F880:F7D2:A3DF:7BE6
Mar 14 22:14:49 talkbot 7721: talkbot: 007717: *Dec 21 14:56:53.217 UTC: ICMPv6-ND: Sending NS for FE80::F880:F7D2:A3DF:7BE6 on Vlan1
Mar 14 22:14:49 talkbot 7722: talkbot: 007718: *Dec 21 14:56:53.233 UTC: ICMPv6-ND: Received NA for FE80::F880:F7D2:A3DF:7BE6 on Vlan1 from FE80::F880:F7D2:A3DF:7BE6


[jimb]

From looking at the logs, it looks like ND is actually working.  At least the router is sending NS requests and getting NA replies from at least one host on your global IPv6.

I'm not sure what's going on at this point.  May want to turn on more debugging.  It could just be a bug in multiple versions of IOS on that hardware.  May want to put a TAC call in to Cisco or something.

[growse]

Hmmm.

I know for certain it worked about 2 years ago at a different house. Same router. Now, the main things that would have been different then would be 1) IOS version (probably on 12.3 back then) and 2) client OS and network topology. I've got two theories. Either there's a bug in the router that manifests itself in 15 and 12.4. Or, there's a conflict between something new on the network and the router - obvious candidate is Windows 7.

I'll run it with the above changes for a while and then may roll back to either 12.2 or 12.3 and see if that resolves the issue.