I thought so too, except that we have < 3% CPU usage; we have other 3550s with 30+ VSI interfaces moving considerably more traffic without issue. The anecdotes I've read say that # of routes is what makes them fall over, and we're not even close.
1- u mentioned u transferred the affected VLANs to another distribution > switch , what is the active number of VLANs on this switch ? 2- as i got > from ur description , the switch always drops the traffic of only 2 > VLANs randomly . get the output of show vlan and show spanning tree during > the problem time > 3- u mentioned that the problem solved when u cleared ARP table , can u > get show arp | in incomplete to see which entries are incomplete before and > after the clearing and which VLAN it belongs to . > 1. The alternate switch has the exact same # of VLANs as these particular two switches see just about everything on our network. The alternate happens to run c3550-i5q3l2-mz.121-22.EA5 though. Total # of VLANs on both is 86. 2. I immediately checked show vlan & show spanning-tree vlan XYZ to make sure that we didn't lose the VLANs from the trunks -- they're still there. The VSI stays up as well, which lets OSPF keep the route in place. 3. I wish I could give you one from when things were broken; as of right now (with the ?broken? g0/4 unused) I have zero incompletes. We had a problem that might be similar to this with our 3550 CPEs some time > ago. All our affected SVIs were configured with VRF Lite. > We are not using VRF lite anywhere; only place we use VRF (exactly one instance) is on our core 6509s. Are you using route authentication? > Nope. I do appreciate the input, this one me stuck. Hopefully the existing bypass of g0/4 will let me get some sleep and not make me tear my hair out tomorrow morning between 9 & 10am :) Cheers, Randal _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
