On 28/Feb/15 19:38, Nick Hilliard wrote: > On 28/02/2015 13:17, Mark Tinka wrote: >> Once the IPv6 ACL is re-applied, subsequent ND exchanges and >> data plane IPv6 traffic works. If the switch reboots or the ND cache is >> cleared, the problem resurfaces. > I wonder is this a screwup with the implicit ND permit? Do your ipv6 ACLs > contain explicit denys at the end? If so, you'll need something like this > before the end: > > permit icmp any any nd-ns > permit icmp any any nd-na > > Easy to check if this fixes the problem. You might want to add a > destination address of fe80::/16 to the filter to make sure that you don't > open up a security hole.
This is the ACL: ipv6 access-list filter-outgoing6 deny ipv6 any 3FFE::/16 deny ipv6 any 2001:DB8::/32 deny ipv6 any FE00::/9 deny ipv6 any FF00::/8 sequence 65535 permit ipv6 any any Very, very simple. I have the exact same ACL on the the other Cisco platforms mentioned, and ND works perfectly. I was considering punching extra holes in this ACL for the ME3600X, but I'm curious why this hardware-software combination differs from other Cisco platforms. > is this box definitely running either 15.4(3)S1 or 15.3(3)S4 or later? > This is to rule out CSCuo31527, which I've been bitten with extensively. 15.4(3)S1 confirmed with "show version". Just for giggles, I'm going to re-run the software upgrade in case it did not commit "correctly" :-\. Mark. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
