enabling IPv6 on Cisco 6500 breaks IPv4 Internet connectivity.

[Eric Vyncke (evyncke)]

By any chance, can you check whether the 'broken' router receives a lot
of IPv6 traffic already? Or if there are some 'multicast' storm between
this 'broken' router and another device?

 

From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de
[mailto:ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de] On Behalf
Of Jim Trotz
Sent: vendredi 1 juin 2012 02:47
To: ipv6-ops at lists.cluenet.de
Subject: enabling IPv6 on Cisco 6500 breaks IPv4 Internet connectivity.

 

We have a pair of Cat6500s with sup720XL supervisors running
12.2(33)SXJ1 IOS that are configured as enterprise Edge routers. These
routers have a VRF for Internet "outside" connections and the global
table is used for "Inside" connections. The outside VRF has full BGP
routing tables with 406K V4 routes. 

Cisco ASAs are connected on ports associated each routing table. Named
mode EIGRP is used for IGP both inside and in the external VRF to
communicate with our 2 Internet Hub routers (also 6500s, dual stacked,
working fine).

The problem we have is that when we try to configure IPV6 on the edge
routers we loose the ability to pass IPv4 traffic as soon as the "ipv6
unicast routing" command is entered - no IPV6 addresses have been
applied at that point, no interfaces enabled for IPv6 and no ipv6
routing configured either.

Cisco TAC seems to be stumped. The logs don't show anything, Eigrp & BGP
neighbors stay up and the CPU rises to 99% utilization.

The odd thing is that when we apply the "ipv6 unicast routing" command
to the other router it works fine. The only thing we could think of
thats different between the two is the "broken" router's ASA firewall is
in active state and the "good" router's ASA is in standby. We plan to
fail them over to see if thats really the difference.

I have tried duplicating the problem in the lab without luck so far.

Has anyone had a similar problem or have any suggestions? 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20120601/214720e4/attachment.htm>