3

With one of our network providers our Linux based router (Vyatta/Debian) can't talk to their Cisco router over IPv6. Their router seems to not reply to the ICMP6 neighbor solicitation requests that ours send. This is working fine between our two routers on this VLAN and between our routers and every other provider and peer we have; IPv4 on the same interface to the same provider is working fine, too.

The interface configuration on their router (IP addresses munged) is:

interface GigabitEthernet1/48.301
encapsulation dot1Q 301
ip address 10.0.0.1 255.255.255.248
no ip redirects
no ip proxy-arp
ip mtu 1500
ipv6 address 2078:abcd::5b::1/112
ipv6 mtu 1500
no ipv6 redirects
no cdp enable
end

Which all looks pretty default/standard to me. When I got them to ping our side of the interface, a ping in both directions immediately started working. (Our router replied to the ND request and I guess our router figured out their mac address from the ICMP6 ECHO request).

If we add an entry to the neighbor table manually, everything is working fine, but obviously that's a bit of a hacky solution.

Any ideas?

Ask Bjørn Hansen
  • 490
  • 1
  • 3
  • 11
  • Not saying that this is the issue, but more times than not I have had problems with the default MTU of 1500 when configuring ipv6. It may worth the effort to try with an ipv6 MTU of 1280. – jliendo Mar 19 '11 at 00:32
  • Hi jliendo - the ND discovery packets are only 32 or 64 bytes long, so I don't think that'd help. (And they're going through fine in the opposite direction; their asking, ours replying with their mac addresses). – Ask Bjørn Hansen Mar 19 '11 at 21:01
  • I know this isn't what you want to hear, but I had this problem with a cheap Cisco router and the only solution was to reboot it. Then it would start sending replies again. Seemed like a very bad software bug. – mpontillo Apr 12 '11 at 17:04

1 Answers1

1

It sounds like you've already done captures. If you've verified your address resolution requests are being sent, but you're not receiving replies, that sounds like either their router isn't responding or a layer 2 device in the path is dropping them - for whatever reason, be it bug or configuration. If they're willing to provide configurations, you might also ask about the actual physical interface configuration here (ge1/48) and any switch ports the VLAN is trunked through on their network.

If you're sure it's not your end (Are you direct to the provider from your router? Attempted other hardware?), then I'd say push for debugs at the Cisco and/or span/port mirroring on their ingress switch port to capture and confirm if they're seeing your requests inbound. If they confirm they are and they aren't replying, they're somewhat obligated to determine why from there.

Bryan Redd
  • 36
  • 1