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?

Improve this question
3
  • 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, 2011 at 0: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, 2011 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, 2011 at 17:04

1 Answer 1

Reset to default
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.

Improve this answer
1
  • It got fixed ages later when the other side had a maintenance window and did unspecified upgrades. Geez.
    – Ask Bjørn Hansen
    Mar 7, 2013 at 5:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .