IPv6 traffic drops intermittent between a ASA andASR.
client only process UDP traffic over IPv6 but it flows in both directions. Periodically the UDP from the ASA to the ASR stops flowing. ASR to ASA seems unaffected. There appear to be no errors in the logs of either device. Clearing the IPv6 neighbours and pinging from the ASA to ASR starts the traffic flow again.
I was not able to find anything related to this on the bug tool, anyone has experience on this behaviour?
ASA is on 9.5(2)ASR 3-13-02
any advice greatly appreciated
thanks for the response, this is what my client has done as a workaround. so I assume when it works ICMP should work (or do you mean once it stop working?)
I’ve implemented a “fix” and set a static ipv6 neighbour on the ASR and ASA which is looking like its fixed it. I’ve put an IP SLA in place to ping the ASA from the ASR every 10 seconds and it’s looking good. This points to the issue being with IPv6 ND on one or both of the devices.
I have check everywhere online, bugtool etc. I was not able to find anything. I doubt this is a configuration issue, as it works and all of a sudden it stops.
My take is, its either a hardware issue (not enough resources) or software failure (a bug)
I am not an expert in IPv6 to be honest.
with kind regards,
I have only seen this issue once before, and it was when the ASA was plugged in via a switch to the router, and it turned out the switch wasn't processing multicast traffic correctly, breaking the IPV6 neighbour discovery messages.
Is the ASA plugged directly into the ASR, or is it via a switch?
We are currently running 9.6(1) on our ASA, using IPv6, with no issues. We have been using IPv6 with our ASA for many many years, over a lot of software versions, and I don't ever recall having an issue with it.
We have had the same issue. In our case L2-Multicast (and IPv6 Neighbordiscovery which relies on it) doesn't works properly. One device sends a neighbor solicitation to the appropriate multicast group, but the ethernet frame doesn't reach all other hosts. The fix (for us) was disable "ipv6 mld snooping" on all affected switches.