Detached processes

[Volker Halle]

Wim,

your trace (fragment) shows the VMS system sending a GetNext request and receiving 2 GetResponse messages from the hub. Both responses have the same RequestID FD21D502 and their contents is identical (except the IP Identifier has been incremented by 2 and so the HDR Checksum has also changed).

Does this kind of behaviour always occur on the same GetNext request ? Due to the intermittent nature of this problem, you should be able to capture a 'working' GetNext/GetResponse exchange for this data item. Does the outgoing SNMP message 'on the wire' (as sent by VMS and reported by TCPTRACE) look identical in the working/failing case ?

BTW, did you try the '-i' flag to ignore invalid responses ?

Volker.

[Wim Van den Wyngaert]

Volker,

-i is not compatible with -l (to loop thru the values).

The trace in case of a working snmp_request is different (that is why is posted the faulty one). It answers 1 times instead of 2.

Wim

[Volker Halle]

Wim,

sure, a working SNMP GetNext/GetResponse message exchange is a one-to-one relationship. There is a RequestID longword in the SNMP packet sent and it's matched with the same value in the GetResponse msg.

In the 18-JUN-2004 trace, I can identify those RequestID pairs, in today's trace, I can't !

In the XMT msg, the RequestID seems to start at offset 002F, in the RCV msg, it's at offset 002D. The RequestID is followed by a 02 and the Error status (01 00) and the Error index (02 01).

I've checked the position of the RequestID in the messages with running $ tcpdump -vv host x.x.x.x. tcpdump decodes the RequestID with R=decimal-number.

What I would like to see is a successful trace of your snmp_request and an unsuccessful one. Does it fail when querying the SAME object ?

The object number can be found in the message. It seems to start with a count byte, then 2B, followed by count-1 object no. bytes (excluding 1.3.).

Volker.

[Wim Van den Wyngaert]

Volker,

I can't give you any trace of a failed snmp except the you have.

Here is a short but complete UDP trace of a successful snmp dump.

But the main question remains : why did it send 2 answers ?

It is not always on the same object (UID).

Wim

[Volker Halle]

Wim,

maybe we should move the current SNMP-related discussion to your 'SNMP trace' thread...

In the 18-JUN trace, there seems to be a 110 ms pause between RCV packet 1399 and XMT packet 1400 - unusual. In your example from today, the packets are normally 10ms (or less) apart.

The SNMP data in the 'duplicate' packet (1399) is identical to packet 1398, yet the IP Identifier (and checksum) are different, which tells that some IP piece of sw/hw had handled that packet and put it on the 'wire' again 10 ms later.

Volker.

[Uwe Zessin]

Interesting, is the network properly working otherwise?

I would take a look at the system's interface counters and check for late collisions (only a guess, but it won't hurt):

LANCP> show device/counters

[Wim Van den Wyngaert]

Uwe,

Done in the other threads. Nothing to be seen.
But since the problem is solved by doing an upgrade on the switch ...

Wim