Did you ever find an answer to this problem?
I'm having the exact same issue to the same provider using a 7604/RSP720 - 12.2(33)SRE4
Can I ask if you are also using Orion as transport to get to Cogent?
All my outputs are identical to yours. One additional thing to note is that debugging and the
'show ipv6 traffic int gi1/1' displays encapsulation errors, which leads me to believe an issue with the neighbor cache.
GigabitEthernet1/1 IPv6 statistics:
Rcvd: 19872 total, 19872 local destination
0 source-routed, 0 truncated
0 format errors, 0 hop count exceeded
0 bad header, 0 unknown option, 0 bad source
0 unknown protocol, 0 not a router
0 fragments, 0 total reassembled
0 reassembly timeouts, 0 reassembly failures
Sent: 53631 generated, 0 forwarded
0 fragmented into 0 fragments, 0 failed
3747 encapsulation failed, 0 no route, 0 too big
0 RPF drops, 0 RPF suppressed drops
Mcast: 19872 received, 9849 sent
I have tried entering a static neighbor cache entry for Cogent's IP but am still unable to ping their interface.
Internally I can ping our interface and externally I can ping theirs, but between the two IPs on the link I am unable to ping them and they can't ping me. Like you, no firewalls or ACLs.
I am also unable to ping using link-local addresses.
I don't have any issues with the other IPv6 links/providers. This link differs in only 3 ways:
1) it's a /112 network
2) It uses Orion as L2 transport to Cogent
3) It's with Cogent
I don't think #1 is the problem, and I have to assume #3 isn't. I'm investigating #2 now.
Hello - This problem persisted right up until today/yesterday, a day after sbourque contacted me. He runs a similar cfg with the same vendors and has the same problem. When he contacted me I had the same hardware and cfg and the same problem as when I posted this in April.
We have had an ASR waiting to replace this 7201 and had the opportunity to replace it last night.
I copied the cfg line for line from the 7201 to the ASR 1002 with only some interface name changes and it functions as expected on the ASR.
The IPv6 on both sub interfaces now functions as desired, neighbour discovery worked, and the IPv6 protocol came up.
As soon as we figure out why/how I'll share it here. 7201 was running a 12.4.(4) and the ASR is running a 15.1 version.
OK, here is the core part of the trace:
Apr 14 10:52:42.675: ICMPv6-ND: Sending NS for 2001:550:2:8::2:1 on GigabitEthernet0/3.552
Apr 14 10:52:42.675: IPV6: source FE80::227:DFF:FE9A:A917 (local)
Apr 14 10:52:42.675: dest 2001:550:2:8::2:1 (GigabitEthernet0/3.552)
Apr 14 10:52:42.675: traffic class 224, flow 0x0, len 72+8, prot 58, hops 255, originating
Apr 14 10:52:42.675: IPv6: Sending on GigabitEthernet0/3.552
Apr 14 10:52:42.767: IPV6: source 2001:550:2:8::2:1 (GigabitEthernet0/3.552)
Apr 14 10:52:42.767: dest FF02::1:FF02:2
Apr 14 10:52:42.767: traffic class 224, flow 0x0, len 72+14, prot 58, hops 255, forward to ulp
Apr 14 10:52:42.767: ICMPv6: Received ICMPv6 packet from 2001:550:2:8::2:1, type 135
Apr 14 10:52:42.767: ICMPv6-ND: Received NS for 2001:550:2:8::2:2 on GigabitEthernet0/3.552 from 2001:550:2:8::2:1
Apr 14 10:52:42.767: ICMPv6-ND: Sending NA for 2001:550:2:8::2:2 on GigabitEthernet0/3.552
Apr 14 10:52:42.767: IPV6: source 2001:550:2:8::2:2 (local)
Apr 14 10:52:42.767: dest 2001:550:2:8::2:1 (GigabitEthernet0/3.552)
Apr 14 10:52:42.767: traffic class 224, flow 0x0, len 72+8, prot 58, hops 255, originating
Apr 14 10:52:42.767: IPv6: Sending on GigabitEthernet0/3.552
Apr 14 10:52:43.675: ICMPv6-ND: PROBE deleted: 2001:550:2:8::2:1
Apr 14 10:52:43.675: ICMPv6-ND: PROBE -> DELETE: 2001:550:2:8::2:1
We see the NS form the neighor and answer with an NA, however, the NS we send is never answered (or never received by the far end)
If it works with 15.1, it seems like there may have been a software bug someplace. The only thing changing was the software version (and hardware), all configs the same? Does each subinterface have a unique link-local address?
That's identical to what we are seeing ; from my end/perspective:
We are receiving RA from Cogent
We are sending RA to Cogent
We receive NS requests from Cogent
We respond to Cogents NS with NA
We send NS requests to Cogent
* We never receive a NA from Cogent *
I'm unsure if cogent receives our NA
We setup a test dual-stack link with/through Orion to a remote router to simulate Cogent. Using various IPs everything worked fine. When we switched to using the actual /112 network assigned from cogent the same symptoms occurred.
I then setup the scenerio in my lab using the same IP's as the Orion test [Cogent assigned].
I used a Cisco 4948 as the ::E:1/112 address directly connected to the Cisco 7604/RSP720 as the ::E:2/112 network.
The 7604 is the actual 7604 that connects to cogent just using a different interface.
We upgraded the 7604 from 12.2(33)SRE4 to 12.2(33)SRE5 with no differences.
The 4948 is running 12.2(25)SG
Everything worked as expected between the 7604 and 4948. So far, I can only duplicate this through the Orion network.
If it was a software bug on the 7604 I'd expect the problem to exist with the 4948 connection.
The only differences our site has to the original posters [scbenoit] is we are not using sub-interfaces [using routed interfaces] and we are using a 7604 w/ RSP not a 7201. -and obviously software version and IP addresses.
So you have NO subinterfaces in use - you have this experience on a straight ethernet connection?
"encapsulation failed" is the expected error when trying to transmit a packet that has no entry in the ARP/neighbor cache.
No firewall in between? No access lists? In some cases, access lists inadvertently block NA or ND packets.
Can you put a test device running a later IOS version (e.g.: 15.1) on the link to Cogent?
You may want to open a case with the TAC on this one.