Highlighted
Regular Contributor.
Regular Contributor.
944 views

Custom poller polling on wrong OID

Jump to solution

I'm trying to poll a clock to get error codes out of it, so we can be alerted if the hands are in the wrong location.

The complete OID is .1.3.6.1.4.1.25281.3.5 and if I make a snmpwalk I get the integer 120 (meaning multiple errors) as an answer from this OID. So I know the clock is responding with the correct error code. 

 

Checked the MIB provided by the manufacturer, and they had written it like this:

-----------------------------------
NurError OBJECT-TYPE
-----------------------------------
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "ErrorIndex"
::= { nur 5 }

-----------------------------------
NurErrorZ OBJECT-TYPE
-----------------------------------
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "ErrorIndex"
::= { NurError 0 }

However, when the custom poller is trying to fetch the data, and polls on .1.3.6.1.4.1.25281.3.5.0 and gets no answer. Turn out it's not a valid OID for the device, the clock won't answer on this OID.

Tried removing NurErrorZ so it's not in the MIB, and updating the custom poller to reflect this change. The MIB expression now points to the end point .5

However, NNM keeps polling on .5.0 and so gets no answer. Why? Where does this .0 come from? Any ideas on how to correct this?

0 Likes
1 Solution

Accepted Solutions
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: Custom poller polling on wrong OID

Jump to solution

Hi, Jonas
Obviously clock makers have very limited knowledge about SNMP. NNMi CP expects that SNMP agent is made according to the standards, what is not in you case. As far as I understood - agent presents data incorrectly, as a result MIB instance discoverty fails and CP can't do it's job. See more explanations in the attached file.
If Westerstrand support can't update SNMP agent promptly, I'd suggest you to look into SNMP traps what are available in the MIBs (there are 26 trap definitions). It could be an alternative monitoriong solution, I guess,

Another option - create a script read NurError with snmpwalk/get, apply some logic to generate SNMP traps if NurError value in not normal.

my 2 cents,
Gedas

View solution in original post

0 Likes
12 Replies
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: Custom poller polling on wrong OID

Jump to solution

This will require a support case to determine where the problem with your Westerstrand clock resides: SNMP agent or the SNMP MIB.

Have a nice day 🙂

Andy Kemp
I've lasted longer in the technology industry than most certifications.
0 Likes
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: Custom poller polling on wrong OID

Jump to solution

Hi, Jonas

how output of "nnmsnnmpwalk.ovpl  <node>  .1.3.6.1.4.1.25281.3.5"  looks like?
".0" at the end  indicates that it is scalar object: exist only one per system. 

regards,
Gedas

0 Likes
Highlighted
Regular Contributor.
Regular Contributor.

Re: Custom poller polling on wrong OID

Jump to solution

Thanks for your reply. 
This is what it looks like:

 # nnmsnmpwalk.ovpl ur22szd .1.3.6.1.4.1.25281.3.5

No MIB objects contained under subtree.

 

# nnmsnmpget.ovpl ur22szd .1.3.6.1.4.1.25281.3.5   

NurError : INTEGER: 120

 

And one level up. 
# nnmsnmpwalk.ovpl ur22szd .1.3.6.1.4.1.25281.3

NurTimeToTimeout : INTEGER: 719
NurError : INTEGER: 120
lastError : INTEGER: 123
lastInfo : INTEGER: 249
errorMask : Unsigned32: 536985601
100.alarmTextsZ : OCTET STRING- (ascii): B_Hour B_Min B_Sec
101.alarmNumbersZ : OCTET STRING- (ascii): 134 135 136 

 

# nnmsnmpwalk.ovpl -T ur22szd .1.3.6.1.4.1.25281.3

.1.3.6.1.4.1.25281.3.2 : INTEGER: 718
.1.3.6.1.4.1.25281.3.5 : INTEGER: 120
.1.3.6.1.4.1.25281.3.6 : INTEGER: 123
.1.3.6.1.4.1.25281.3.7 : INTEGER: 249
.1.3.6.1.4.1.25281.3.9 : Unsigned32: 536985601
.1.3.6.1.4.1.25281.3.100.0 : OCTET STRING- (ascii): B_Hour B_Min B_Sec
.1.3.6.1.4.1.25281.3.101.0 : OCTET STRING- (ascii): 134 135 136

Regards,
Jonas

0 Likes
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: Custom poller polling on wrong OID

Jump to solution

Hi, Jonas

it looks like SNMP agent issue. Can you provide MIB file and output of "/opt/OV/support/nnmsnmpwalk.ovpl  -T ur22szd ".  I'll have some spare time at the end of week, so  try to simulate the node and look closer.


regards,
Gedas

0 Likes
Highlighted
Regular Contributor.
Regular Contributor.

Re: Custom poller polling on wrong OID

Jump to solution

Sorry for late reply, been busy! I much appreciate any help I can get.

The MIB looks like in the original post above:
Originally from the manufacturer:

-----------------------------------
NurError OBJECT-TYPE
-----------------------------------
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "ErrorIndex"
::= { nur 5 }

-----------------------------------
NurErrorZ OBJECT-TYPE
-----------------------------------
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "ErrorIndex"
::= { NurError 0 }

I've modified it by removing NurErrorZ so that it matches the output.

 

The output from /opt/OV/support # ./nnmsnmpwalk -T ur22szd (IPs removed for policy reasons)

.1.3.6.1.2.1.1.1.0 : OCTET STRING- (ascii):     ur22szd - 600mm enkel med sekund
.1.3.6.1.2.1.1.2.0 : OBJECT IDENTIFIER: .1.3.6.1.4.1.25281.3
.1.3.6.1.2.1.1.3.0 : Timeticks: (1400242980) 162 days, 1:33:49.80
.1.3.6.1.2.1.1.4.0 : OCTET STRING- (ascii):
.1.3.6.1.2.1.1.5.0 : OCTET STRING- (ascii):     NUR-B160 (Nov 01 2016 14:25:51)
.1.3.6.1.2.1.1.6.0 : OCTET STRING- (ascii):     Sodra samtrafiktavlan vid Hertig Carls vag
.1.3.6.1.2.1.2.1.0 : INTEGER: 1
.1.3.6.1.2.1.2.2.1.1.1 : INTEGER: 1
.1.3.6.1.2.1.2.2.1.2.1 : OCTET STRING- (ascii): Ethernet
.1.3.6.1.2.1.2.2.1.3.1 : INTEGER: 6
.1.3.6.1.2.1.2.2.1.5.1 : Unsigned32: 10000000
.1.3.6.1.2.1.2.2.1.6.1 : OCTET STRING-   (hex): length = 6

     0:  00 90 c2 f3 1a 00 -- -- -- -- -- -- -- -- -- --     ................

.1.3.6.1.2.1.2.2.1.7.1 : INTEGER: 1
.1.3.6.1.2.1.2.2.1.8.1 : INTEGER: 1
.1.3.6.1.2.1.4.1.0 : INTEGER: 2
.1.3.6.1.2.1.4.20.1.1.10.113.8.28 : IpAddress:  x.x.x.x (Clock IP)
.1.3.6.1.2.1.4.20.1.2.10.113.8.28 : INTEGER: 1
.1.3.6.1.2.1.4.20.1.3.10.113.8.28 : IpAddress:  255.255.255.0
.1.3.6.1.2.1.31.1.1.1.1 : OCTET STRING- (ascii):         
.1.3.6.1.4.1.25281.3.2 : INTEGER: 710
.1.3.6.1.4.1.25281.3.5 : INTEGER: 120
.1.3.6.1.4.1.25281.3.6 : INTEGER: 123
.1.3.6.1.4.1.25281.3.7 : INTEGER: 249
.1.3.6.1.4.1.25281.3.9 : Unsigned32: 536985601
.1.3.6.1.4.1.25281.3.100.0 : OCTET STRING- (ascii):     B_Hour B_Min B_Sec
.1.3.6.1.4.1.25281.3.101.0 : OCTET STRING- (ascii):     134 135 136
.1.3.6.1.4.1.25281.1001 : INTEGER: 3
.1.3.6.1.4.1.25281.1002 : IpAddress:    x.x.x.x (Clock IP)
.1.3.6.1.4.1.25281.1003 : IpAddress:    x.x.x.x (Clock IP fallback)
.1.3.6.1.4.1.25281.1004 : IpAddress:    x.x.x.x (NTP server)
.1.3.6.1.4.1.25281.1006 : IpAddress:    x.x.x.x (SNMP server)
.1.3.6.1.4.1.25281.1007 : OCTET STRING- (ascii):        10.0.1.80
.1.3.6.1.4.1.25281.1012 : OCTET STRING- (ascii):        CET
.1.3.6.1.4.1.25281.1020 : OCTET STRING- (ascii):         1/2Minute Double-sided HMS-pointers
.1.3.6.1.4.1.25281.1021 : OCTET STRING- (ascii):        1766ssvv.pdf, ss=language, vv=version
.1.3.6.1.4.1.25281.1023 : INTEGER: 900

End of MIB View.

 

Hope this is of any help.

0 Likes
Highlighted
Regular Contributor.
Regular Contributor.

Re: Custom poller polling on wrong OID

Jump to solution

In addition to the above, we've done a TCP-dump.

And here comes the part we don't understand. It looks like the the NNMi Custom Poller is querying .3.5.0
This happens regardless of wether NurErrorZ is present in the MIB or not. 
See attached screendumps (again IPs masked, .21 is NNM and .28 is the clock).

0 Likes
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: Custom poller polling on wrong OID

Jump to solution

Hi, Jonas
could you attache entire MIB file. 16 lines are not enough...

regards,
Gedas

 

0 Likes
Highlighted
Regular Contributor.
Regular Contributor.

Re: Custom poller polling on wrong OID

Jump to solution

Yes, of course. Here it is.

RABBIT defines NUR.
westnur contains the objects we're interested in.

Had to zip, the dorum wouldn't let me upload otherwise.

0 Likes
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: Custom poller polling on wrong OID

Jump to solution

Hi, Jonas
Obviously clock makers have very limited knowledge about SNMP. NNMi CP expects that SNMP agent is made according to the standards, what is not in you case. As far as I understood - agent presents data incorrectly, as a result MIB instance discoverty fails and CP can't do it's job. See more explanations in the attached file.
If Westerstrand support can't update SNMP agent promptly, I'd suggest you to look into SNMP traps what are available in the MIBs (there are 26 trap definitions). It could be an alternative monitoriong solution, I guess,

Another option - create a script read NurError with snmpwalk/get, apply some logic to generate SNMP traps if NurError value in not normal.

my 2 cents,
Gedas

View solution in original post

0 Likes
Highlighted
Regular Contributor.
Regular Contributor.

Re: Custom poller polling on wrong OID

Jump to solution

I must confess I am somwhat of a beginner in this field, but if I understand you correctly:

- NurError is a scalar object.
- This means NNM custom poller is expecting, or demanding, an answer from an OID that ends in .0.
- The clock doesn't answer at .0, because the SNMP agent programming is flawed.
- If the SNMP agent weren't flawed, the MIB would define NurError as .3.5 but the clock would respond on .3.5.0 which would look like NurError.0 in an SNMPwalk.
- It's up to the manufaturer of the clock ro remedy this.

Have I understood it correctly?

0 Likes
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: Custom poller polling on wrong OID

Jump to solution

Riktig, Jonas

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.