cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
548
Views
0
Helpful
2
Replies

IDS-4230: iprb0 problem

I have a NetRanger 4230 where iprb0 is the interface of control and command, spwr0 for sniffing.

So configured, when I ping the iprb0 (or from) I lose many packets, and I am unable to telnet the sensor.

I note only these errors on the sensor:

from errors.packetd

04/02/2002 08:34:56UTC E fastethernet interface link status is down.

04/02/2002 08:35:01UTC E fastethernet interface link status is back up.

04/02/2002 08:37:21UTC E fastethernet interface link status is down.

04/02/2002 08:37:26UTC E fastethernet interface link status is back up.

from errors.postofficed

04/02/2002 08:47:15UTC E Message received has bad checksum

04/02/2002 08:47:15UTC E NrV1NetMessage::checkChecksum: bad match 62253 64301

04/02/2002 08:47:33UTC E Message received has bad checksum

04/02/2002 08:47:33UTC E NrV1NetMessage::checkChecksum: bad match 9627 11675

04/02/2002 08:47:35UTC E Message received has bad checksum

04/02/2002 08:47:35UTC E NrV1NetMessage::checkChecksum: bad match 33433 35481

04/02/2002 08:47:43UTC E Message received has bad checksum

04/02/2002 08:47:43UTC E NrV1NetMessage::checkChecksum: bad match 55173 57221

...

Switching the interfaces on the sensor

(iprb0<->spwr0) all seems function correctly without

any errors.

NIC problems or other?

Thanks for any suggestion.

2 Replies 2

jamesand
Cisco Employee
Cisco Employee

We have never seen the postoffice bad checksum error message. This means that the incoming message passed the UDP checksum but failed the postoffice checksum. Your NIC may be bad. Here a few questions:

- is there anything in your iprb config file (/kernel/drv/iprb.conf) ?

- when you switch the interfaces does packetd generate alarms (if NIC is bad then packetd should be getting bad packets after you switch interfaces)?

Jim Anderson

jawelsh
Level 1
Level 1

is there a lot of multicast traffic on your lan that you are sniffing? there is an issue (not resolved yet) where the iprb0 interface cannot correctly identify certain multicast traffic. The workaround is to swap the interfaces which you have already done. CSCdv47513