*** W32/SQLSlammer - why RTD-1-ADDR_FLAP on uplinks? ***

[schm196]

Yes, we got hit really hard. Troubleshooting drove me insane for the following reason: I have 3548 and a 3550-48 for server connectivity, connected via fiber GBICs to two 3508G distribution switches, which then connect to multiple 4809G-L3 running HSRP. When the call from operations came that "the network is down" (that's my usual starting point for troubleshooting - I don't have the luxury of being handed over extensive sniffer reports) I checked my Cisco Works 2000 syslog summary and found that the gigabit links between both access switches and the distribution switches begun showing RTD-1-ADDR_FLAP messages at exactly the same time the virus hit.

We've had trouble with spanning tree and HSRP stuff before due to a bug in an earlier 3550 IOS release, so obviously I went all out again testing my configurations and IOS release notes - for nothing, as I found out after a night of work later. Any ideas out here why Cisco IOS shows this symtom under load? "sh proc cpu | ex 0.00" indicated about 50% switch utilization (on all related access and distribution switches), which is way more than normal but still shouldn't cause trouble.

Any thoughts appreciated.

[beth-martin]

The message that you are receiving is an Runtime Diagnostic (RTD) error message.

Normally, MAC addresses are learned once on a port. Occasionally, when a switched network reconfigures, due to either manual or STP reconfiguration, addresses learned on one port are relearned on a different port. However, if there is a port anywhere in the switched domain that is looped back to itself, addresses will jump back and forth between the real port and the port that is in the path to the looped back port. In this message, [chars] is the interface, and [dec] is the number of addresses being learnt.

What you would need to do is:

Determine the real path (port) to the MAC address. Use debug ethernet-controller addr to see the alternate path-port on which the address is being learned. Go to the switch attached to that port. Note that show cdp neighbors is useful in determining the next switch. Repeat this procedure until the port is found that is receiving what it is transmitting, and remove that port from the network.

[schm196]

Thanks for the detailed error analysis... it is helpful in troubleshooting the symptom. Part of my question, however, was to understand if there's a correlation between high load on the switch and this error message. I would think this address flap error should appear without regard to the load on the switch... but in this case, the switch has no trouble at all until the load goes way up. Any thoughts on this? Thanks again for your time.