Re: Neighbour discovery issues on sub-interface - Page 2

scbenoit · ‎04-14-2011

Good day

We have a 7201 running IOS 12.4(4) with 2 ISPs connected, IPv4 conenctivity is working as is IPv4 BGP. To this router we've added IPv6 and have been able to establish a neighbour relationship as well as a IPv6 BGP session with one of the ISPs

On the router

- the internal interface use sub-interfaces and has IPv4 and IPv6 addresses bound to the same sub-interface, Gi0/2.50

- the external interface (Gi0/3) uses sub-interfaces as well, and both ISPs are on the same physical i/f but different sub-interfaces.

- Gi0/3.252 sub-interface is for ISP A and has IPv4 bound to it

- Gi0/3.752 sub-interface is for ISP A and has IPv6 bound to it

- Gi0/3.552 sub-interface is for ISP B and has both IPv6 and IPv4 bound to it

The connection to ISP A works fine for both IPv4 and IPv6. In IPv6 we can see the neighbour, ping it, setup BGP session and route IPv6 traffic

The connection to ISP B works fine for IPv4 but fails under IPv6.

If I watch the IPv6 neighbor table with repetitive "sho ipv6 nei" commands I see neighbour status change from PROBE, to DELAY, to INCMP, to not being in the table.

IPv6 Address                              Age Link-layer Addr State Interface
FE80::226:51FF:FECA:A4D3                    0 0026.51ca.a4d3 REACH Gi0/3.752
2001:550:2:8::2:1                           0 001d.e511.6000 DELAY Gi0/3.552              <------ sample entry in table
2607:FD78:302:1::1                          0 0026.51ca.a4d3 REACH Gi0/3.752
FE80::250:56FF:FE80:3506                    0 0050.5680.3506 STALE Gi0/2.50
2620:DD::250:56FF:FE80:3506                 0 0050.5680.3506 REACH Gi0/2.50

While observing this I noted that the Gi0/3.552 sub interface never appears to have a link local adders. The staus then changes to PROBE, then INCMP, and then does not appear in the table.

The atatched IPv6 debug snippet refelcts this behaviour.

Any thoughts on why this is happening and how to correct? Shouldn't I see an local address in the neighbour table for the Gi0/3.552 sub-interface ?

Thanks

Steve

Steven Bourque · ‎11-29-2011

Hello Steve,

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.

--

Steven Bourque

scbenoit · ‎12-02-2011

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.

Steve

Phillip Remaker · ‎12-06-2011

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?

Steven Bourque · ‎12-07-2011

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.

--

Steven

Phillip Remaker · ‎12-07-2011

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.