Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

SNMP IP trace analysis needed

Wim Van den Wyngaert
Honored Contributor

SNMP IP trace analysis needed

I (still) have the problem of a sanswitch not properly reacting to snmp. Sometimes it works, sometimes it don't.

I captured an IP trace (enclosed).

Anyone able to make something of it ?
(why is the device responding twice ? when it is working, it doesn't do that)

If you want to simulate it :
mc tcpip$snmp_request IP public getnext -l 1.3.6.1.4.1
where IP is the address of the snmp agent
Wim
10 REPLIES
Wim Van den Wyngaert
Honored Contributor

Re: SNMP IP trace analysis needed

Forgot to mention : the message that I get is "unexpected reply".
Wim
John Eerenberg
Valued Contributor

Re: SNMP IP trace analysis needed

snmp sends IP packets using UDP. UDP packets are datagrams and have *no gauranteed* delivery.

My first take would be to look at the network and see if you have any packet loss, corruption, excessive collisions (collisions are okay, the excessive collisions are not), etc. as well as the machine processing the snmp packets received and its nic cards, etc.
It is better to STQ then LDQ
Wim Van den Wyngaert
Honored Contributor

Re: SNMP IP trace analysis needed

John,

I verified all sanswitch IP counters and settings. No problems.

This is a double sanswitch with identical software : 1 works fine and 1 has the problem.

They are in the same network.

Also, when I do the snmp dump interactively or, in general, outside its normal dcl procedure of 4000 lines, it works fine.

Now I "disabled" about 3000 lines of it and the problem is still there. The first execution of the snmp dump however works fine.

I tried it starting from another cluster : same problem but with different frequency.

It seems that something is influencing the program.
Wim
Wim Van den Wyngaert
Honored Contributor

Re: SNMP IP trace analysis needed

Did some further testing.

I run it at prio 5.

1 sanswitch gives the problem all the time. 5 others almost never.

when simply done in a 4 line dcl procedure : never a problem (never=batch, interactive, detached)

when done in a bigger environemnt : batch and detached have problems, interactive works fine.

Ran it on a GS160 instead of a 4100. At least 4 times less failures. But still failures.

WHY WHY WHY !!!
Wim
Wim Van den Wyngaert
Honored Contributor

Re: SNMP IP trace analysis needed

I finally powercycled the san switch. It is now working since 1 hour without problems.

Note that I rebooted the switch multiple times !

How this can be related to interactively working, detached not, etc ... I don't know.

Wim
Wim
labadie_1
Honored Contributor

Re: SNMP IP trace analysis needed

get ethereal from

http://www.ethereal.com/

and have a look at

How to run an IP trace using TCPIP Services for OpenVMS

http://h18000.www1.hp.com/support/askkcs/hpcg/1_0_2985185_2748042.html

while it does not apply strictly, it may help you analyze your trace.
Wim Van den Wyngaert
Honored Contributor

Re: SNMP IP trace analysis needed

I tried. The problem was that the SAN switch was answering twice. But how to explain that ?

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: SNMP IP trace analysis needed

Finally found a solution.

The SANSWITCHES almost daily refused to reply correctly to snmp dumps.

I discovered that if you restart it 10 minutes later it fails again. However, if you restart it immediately it works fine and the next time it fails again.

So, I now try it, if it says "no reply" I try again and when it says again "no reply" I give an alarm. No alarms yet so it is working.

Must be some kind of timeout bug.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: SNMP IP trace analysis needed

Still not good enough.

Reprogrammed it and now I do a loop of maximum 10 times. I continue until it works or until I reach the end.
Until know, the maximum number of retries is 2, meaning that I had to do sndmp_request 3 times before it worked.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: SNMP IP trace analysis needed

I think I have found the reason.

SNMP is UDP based. From time to time there seem to be duplicate answers, t.i. as if the switch received 2 packets and answerred 2 times. This causes the problem because snmp isn't expecting it.

Now I have to convince the network team that something is wrong ...

Wim
Wim