IPv6 on Cisco 877 and clients - strange intermittent connectivity

[jimb]

I have no issues with Win7 on my network.  Works fine, just like XP, Linux, FreeBSD.  I had no issue with a cisco 7200 emulator running 12.4 running under Dynamamips.

It does look like the router is receiving neighbor solicitations since I do see one in the logs.  Although maybe something funny is going on and the switches are filtering (or router ignoring) certain multicasts or something like that.

You may want to mirror the routers port and listen using wirehshark to see if the switches are properly delivering NS packets.  Do some pings from the boxes and that should generate NS packets.  If you see them, and especially if you don't see them in the debug output of the cisco, then the problem is definitely on the router.

If you don't see them on the switchport, then maybe you need to play with MLD snooping or other multicast features of the switches.  I vaguely remember from reading about MLD briefly that MLD snooping ignores multicast addresses in the range of neighbor solicitations, so it should always flood those anyway.  I'll have to revisit the docs on that though to be sure.  :P

EDIT: Yep.  I misremembered that.  MLD snooping would apply in the case of the solicited node multicasts used as destination addresses in neighbor solicitations.  So if it's goofing up or whatever, it could be preventing those packets from reaching the router.  I'd set up the wireshark snoop and see for sure if the router is receiving the NS multicasts.  A proper one (taken with tshark here) should look like this:

Frame 2 (86 bytes on wire, 86 bytes captured)
   Arrival Time: Mar 15, 2010 13:45:16.082192000
   [Time delta from previous captured frame: 68.048419000 seconds]
   [Time delta from previous displayed frame: 68.048419000 seconds]
   [Time since reference or first frame: 68.048419000 seconds]
   Frame Number: 2
   Frame Length: 86 bytes
   Capture Length: 86 bytes
   [Frame is marked: False]
   [Protocols in frame: eth:ipv6:icmpv6]
Ethernet II, Src: 3com_6d:5a:a4 (00:01:02:6d:5a:a4), Dst: IPv6mcast_ff:32:00:76 (33:33:ff:32:00:76)
   Destination: IPv6mcast_ff:32:00:76 (33:33:ff:32:00:76)
       Address: IPv6mcast_ff:32:00:76 (33:33:ff:32:00:76)
       .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
       .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
   Source: 3com_6d:5a:a4 (00:01:02:6d:5a:a4)
       Address: 3com_6d:5a:a4 (00:01:02:6d:5a:a4)
       .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
       .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
   Type: IPv6 (0x86dd)
Internet Protocol Version 6
   0110 .... = Version: 6
       [0110 .... = This field makes the filter "ip.version == 6" possible: 6]
   .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
   .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
   Payload length: 32
   Next header: ICMPv6 (0x3a)
   Hop limit: 255
   Source: 2001:db8:1234:0:201:2ff:fe6d:5aa4 (2001:db8:1234:0:201:2ff:fe6d:5aa4)
   Destination: ff02::1:ff32:76 (ff02::1:ff32:76)
Internet Control Message Protocol v6
   Type: 135 (Neighbor solicitation)
   Code: 0
   Checksum: 0x47d2 [correct]
   Target: 2001:db8:1234:0:211:25ff:fe32:76 (2001:db8:1234:0:211:25ff:fe32:76)
   ICMPv6 Option (Source link-layer address)
       Type: Source link-layer address (1)
       Length: 8
       Link-layer address: 00:01:02:6d:5a:a4


If you see packets like this arriving on the switchport the router is plugged into, then you know it's not a layer-2 problem, but a problem on the router.  Actually, you should see such packets on any port, unless MLD snooping is causing the solicited node address for the router to only be forwarded to the router (which would be proper behavior if you have the switches configured to not flood all mutlicast traffic and IGMP and/or MLD snooping is turned on).

[mrtwrx]

I don't have any switches in the way of my devices communicating.

The router works fine with all other O/S's except for Windows7. I have the same problem with with an 1841 and a 2821 that I borrowed from my lab.

How are you actually testing the dynamips instance providing reachability? Do you have another instance or two and are pinging a remote loopback?

I haven't gotten to the point of dumping packets using Wireshark, i'll have to set apart some time to compare timestamped debugs with wireshark outputs from both Windows7 and non windows7 hosts.

I actually get destination host unreachable from the ping attempts in the cmd prompt when its not working.
Funny how the neighbor discovery timeout on all other hosts/platforms is a lot longer then the 3 seconds it appears to be windows 7 and it completely ignores the default value of 30 minutes.

[jimb]

I'm doing things like pinging the dynamips 7200 and SSHing into it from windows boxes, including windows 7 boxes.

Note that it's not acting as a router, it's only running IPv6.  But the ND problems you're having should still apply.  I have also set parts of my /48 on loopbacks on the Cisco and have been able to ping those too.

Not sure what the deal is, but from the sounds of it now (I didn't understand that it was only Win7 having issues), it sounds like something on your win7 box.

BTW, are your win7 boxes standalone boxes or VMs.  'Cause a VM would complicate things.  Make sure the interface is in bridged mode if using a VM.

[growse]

Ok, I *think* I'm an idiot.

I was messing around with a completely different problem involving ipv6 routing, and I noticed on my router config that I had the following statement:

ipv6 route 2000::/3 2a01:348:18a:6::1

This is fairly obviously a carry over from when I used to have a Sixxs tunnel configured. It's bad because it's trying to route an entire chunk of the ipv6 address space over to an ip that probably isn't expecting it.

I've removed that line and added:

ipv6 route ::/0 Tunnel 0

So far, from inside the network, I can now ping the router ipv6 address perfectly. I'll do some more testing when I get home to make sure that connectivity to the outside world is as I expect it.

Lessons learned: Check, recheck, recheck, and then recheck your configs. If it's a choice between finding a bug in IOS and the config errors, it's a config error.

[jimb]

Ugh.  I should have asked for a complete config dump from the getgo.  But then that route wouldn't explain not being able to get to configured interfaces with more specific routes.  Even with a bad default route, pinging the routers interface should have still worked.

[cholzhauer]

Even with a bad default route, pinging the routers interface should have still worked.

That's what I thought too; I was going to post a response, but didn't know if there was some cisco trick that I was missing.

[growse]

It's weird, but I'm willing to put it down to "one of those things". I'm not completely confident it's problem-free, so if I see any similar issues, I'll post back.

Thanks all.

[jimb]

Maybe there's more left-over junk in the config. 

erase startup-config
reload

start over maybe?   ;D

[jporcutt]

@growse: Indeed it is "one of those things". This is a documented bug in the IOS 15 release notes. It was said to have been resolved in IOS 15.0(1)M2, but I'm still having this issue in 15.0(1)M2. It worked for a while after upgrading, but now today the symptom is back.

bummer  ::)

Bug reference number CSCte23299, IOS 15.0(1) release notes.
http://www.cisco.com/en/US/docs/ios/15_0/release/notes/150MCAVS.html

[chiel]

@jporcutt, thanks for that link. When I was looking at it I saw that the newest IOS is 15.1.1T(ED). I will give that a try next week.

[chiel]

Just to let you know, I upgraded to 15.1.1T(ED) and that finally fixed the problem for me! :)

[mrtwrx]

Just to let you know, I upgraded to 15.1.1T(ED) and that finally fixed the problem for me! :)

Hah!

Nice, i'll have to try this.