Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member


I've deployed a new IDS 4250 in an ISP environment. I often find huge amount of such messages in /usr/nr/var/errors.packetd.<pid>

E SWEEP.PORT.UDP - Udp Header has bad Dport 0

E SWEEP.PORT.UDP - Udp Header has bad Dport 0

E SWEEP.PORT.UDP - Udp Header has bad Dport 0

E SWEEP.PORT.UDP - Udp Header has bad Dport 0

Can anyone tell me why such error does appear?

This signature is configured as the file /usr/nr/etc/SigUser.conf shows:

Engine SWEEP.PORT.UDP AlarmThrottle FireAll ChokeThreshold 100 portsInclude 1,2,3,19,37,53,111,123,177,513,514,2049,2050,32767,33000,33500 ResetAfterIdle 20 SIGID 4001 ThrottleInterval 30 Unique 5

I tried to add the port 0 while tuning this signature (SIGID 4001), but the error still appears in the log file errors.packetd.<pid>

Thank you,

Cisco Employee

Re: errors.packetd.<pid>

Here is my guess at what the problem might be:

UDP packets are all passed to the SWEEP.PORT.UDP engine to see if the packet should be counted toward a sweep. When the Engine looks a the destination port in the UDP Packet itself it seeing a destination port of "0" for the UDP Packet. UDP Packets should not have a destination port of "0" so it is creating this error (i.e. a service can't open a UDP port of 0 so the packet is not valid).

I would suggest using a sniffer and trying to determine if there are perhaps UDP packets on your network whose destination port is set to 0. If you do find some then can you determine what is generating the invalid UDP packets?

If you can not find any with a sniffer then you will likely need to contact the TAC and request engineering assistance. You will need to gather some information for engineering to analyze what the problem might be.

Execute the following steps to get the data that the engineers will need.

1) Stop the sensor

2) Remove the packetd error log

3) Start the sensor, as well as a network sniffer that will log all UDP packets

4) Watch the error log of packetd

5) When the error pops up in the log, stop the sniffer.

6) Have the sniffer log and error log ready when you contact the TAC.