CSS Error Message

[jdanrich]

Anyone know what this means?

Could not process IMM Message... "FEB 3 12:24:36 5/1 3399

SYSSOFT-4: IMM message not deliverable, message queue full, ce = 0x20202700,

message type = 0x370000, message queue id = 0x857d6430"

TIA!

[pknoops]

This error message is referring to a queue getting overrun. To this message queue we send all non-IP traffic (Spanning Tree), ICMP, ARPs, UDP fragments and expired TTLs. Under load, especially lots of UDP fragments or different Denial of Service (DOS) attacks it would be expected that this queue would fill up and we might drop some packets.

Usually we see this type of log entry when the CS-800 is receiving a high volume of extraneous traffic. Because we act as both a router and a bridge, we must examine each packet. This particular queue handles all non-specific and non-IP traffic, including Spanning Tree BPDU, non-IP bridgeable traffic, ICMP, ARP, UDP fragments, and packets with expired TTL. Under situations where the CS-800 receives a high number of these packets, such as during a DOS attack or where other network anomalies exist, there may be occasional drops in this queue. This should not have any impact on user TCP traffic, as TCP is sent to a different queue.

If this error appears in the log occasionally, then check the "show dos" commands to make sure the site is not under attack. Also, check the network topology to make sure the routing is solid. If the log is filling rapidly with these errors, then a packet capture may be helpful in isolating the cause.

Regards

Pete Knoops

Cisco Systems

[dcayer]

We also occasionnaly encounter this message.

At one point, it was actually repeating very agressively and causing our logs to grow very big! We found that the error message seems to go away for a little while when we reboot the CSS. We haven't got to throwing a Sniffer on there yet.

Daniel Cayer

EDS Canada

[Gilles Dufour]

Daniel,

I had a similar issue recently.

We could not use a sniffer, so I suggested to do some ip accounting somewhere else in the network.

We found out that a device was sending lot of traffic to the CSS with IP porotocol 255 (unknown) causing the CSS to show the error you have seen.

The solution was to first filter this traffic before it got to the CSS and then identify the source of the traffic.

The conclusion is that it is important to know the traffic that gets to the CSS in order to solve such an issue.

Gilles.

[dcayer]

Thanks Gilles.

Is there any way to easily determine the ingress port for such packets (i.e.: packets with an unknown protocol number)? We have 16 different VLANs/Interfaces and it would be nice to where to start sniffing!

PS: We are still getting these errors "SYSSOFT-4: IMM message not deliverable, message queue full, ce = 0x20202700", but I've change the logging level to 3 to prevent our log from filling up (logging subsystem syssoft level error-3).