Forum Discussion
CrystalSet
Nimbostratus
NimbostratusOID changes afte config changes.
Running 11.1.0 Build 2027.32
We did an SNMPwalk on the OID to find the OIDs for some real server status variables we want to monitor in PRTG. We found the OIDs and they return a text string "Pool member is available". The PRTG sensor looks in the returned string for the word "available".
We have two LTMs in a pair and the OID for the node was the same on both.
After making and unrelated change to the configuration of the F5 (adding an iRule to unrelated VIP) the sensor went down. Running another snmp walk showed that the OID had changed on the active LTM but not on the secondary.
So my questions are
1. Has anyone else seen this problem?
2. How do we stop the OID from changing if other configurations is changed?
3. How do we keep the OIDs in sync between the two LTMs in the cluster?
Not sure if this is a bug - I know Cisco interfaces can change OIDs after a reboot which is a similar problem, and that can be fixed with a configuration on the switch.
HamishCirrocumulus
Mm... The OID shouldn't change. And doesn't in 10.2.4 (As the index is poolname.ipv4.ipaddress.port).
But I'm not sure we're looking at the same thing. Obviously your OID's won't work on my system as the pools and poolmembers aren't the same. I've tested on 10.2.4 and 11.2.0 (Sorry, don't have an 11.1.0).
Can you try dumping the whole table from both. e.g. using snmpwalk and the OID
.1.3.6.1.4.1.3375.2.2.5.6.2.1.5
On 11.2 you'd get something like
F5-BIGIP-LOCAL-MIB::ltmPoolMbrStatusAvailState."/Common/wat__pool".18.47.67.111.109.109.111.110.47.109.101.109.98.101.114.116.101.115.116.444 = INTEGER: red(3)
F5-BIGIP-LOCAL-MIB::ltmPoolMbrStatusAvailState."/Common/wat__pool".19.47.67.111.109.109.111.110.47.49.48.46.50.48.46.52.49.46.49.52.80 = INTEGER: red(3)
F5-BIGIP-LOCAL-MIB::ltmPoolMbrStatusAvailState."/Common/hsl-log-01".25.47.67.111.109.109.111.110.47.99.97.99.116.105.46.110.101.116.46.108.99.104.46.99.111.109.514 = INTEGER: blue(4)
F5-BIGIP-LOCAL-MIB::ltmPoolMbrStatusAvailState."/Common/wat__aaa_srvr_pool".19.47.67.111.109.109.111.110.47.49.48.46.50.48.46.55.49.46.51.54.1812 = INTEGER: blue(4)
F5-BIGIP-LOCAL-MIB::ltmPoolMbrStatusAvailState."/Common/wat__aaa_srvr_pool".19.47.67.111.109.109.111.110.47.49.48.46.50.48.46.55.49.46.51.55.1812 = INTEGER: blue(4)
But the returned information doesn't match what you think it should either. Because that OID table returns the STATUS of the poolmember. Which is an integer where 1==green (UP), 3==red (DOWN), 4==blue (UNCHECKED) etc...
H- HamishNote that in v11 the index is STILL the pool and member (For a unique poolmember)... but the poolmember itself is represented as a NAME now. Not an IP address like in 10.x. So a poolmember that's displayed as 10.1.1.220:514 in a pool (From the GUI) wold manifest itself as '47.99.97.99.116.105.46.110.101.116.46.108.99.104.46.99.111.109.514' that being the ascii representation of 10.1.1.220:514 encoded as a string OID.
H 
CrystalSetThanks for the reply Hamish. Yes there is a status oid that returns a colour - red, green, blue etc. There is alos an OID that returns a text string like "Pool member is available" - you will see it if you do an snmp walk.
I would say the changing OID is a bug, Interestingly it also occurs on Coyote load balancers (One of F5s competitors)..
http://www.coyotepoint.com/forums/equalizer-8x-discussion/cluster-oid-changes
It appears that every time I make a change on one of my load balancers, the SNMP OIDs for each cluster are dynamically changed. This is a huge frustration because I have to go in and edit my monitoring every time I make a change on the load balancer. Is it possible for me to set static OIDs for each cluster or can that please be added as a feature in a new release? Or if there is a way for me to fix this manually, please let me know. Thanks!
nitassEmployee
what is .64.10?
[root@ve11a:Active:Changes Pending] config snmptranslate .1.3.6.1.4.1.3375.2.2.5.6.2.1.5.22.47.67.111.109.109.111.110.47.80.114.111.100.117.99.116.105.111.110.45.77.83.67.30.47.67.111.109.109.111.110.47.98.99.48.52.46.118.119.115.106.45.109.103.99.102.46.99.105.109.115.46.99.111.64.10.5060 F5-BIGIP-LOCAL-MIB::ltmPoolMbrStatusAvailState."/Common/Production-MSC"."/Common/bc04.vwsj-mgcf.cims.co".64.10.5060
this is mine.
[root@ve11a:Active:Changes Pending] config snmptranslate .1.3.6.1.4.1.3375.2.2.5.6.2.1.5.11.47.67.111.109.109.111.110.47.102.111.111.23.47.67.111.109.109.111.110.47.50.48.48.46.50.48.48.46.50.48.48.46.49.48.49.80 F5-BIGIP-LOCAL-MIB::ltmPoolMbrStatusAvailState."/Common/foo"."/Common/200.200.200.101".80- HamishFuzzy: I did do an SNMP walk... From the OID I posted above (.1.3.6.1.4.1.3375.2.2.5.6.2.1.5). I don't get anything that says 'Pool member is available' under the OID you sent... Can you post an snmpwalk (Just the section in it that shows this would be fine).
Perhaps you're looking at something else? Some other OID than the one you posted...
H - HamishOh... Just noticed as well. Your original text above also indicates the OID's were identical.. yet your example is querying DIFFERENT OID's on each unit...
H 
Security-ops_83Hello Fuzzy,
i would like to know if you manage to resolve you issue ... cause since 2 week i got exactly the same issue ...
i'm making graph on cacti about the current connection on a particular member of a pool. when i make an snmpwalk on the oid concerning my server i got this :
snmpwalk -c public -v 2c -On x.x.x.x .1.3.6.1.4.1.3375.2.2.5.4.3.1.11.30.47.80.97.114.116.105.116.105.111.110.45.97.112.112.108.105.99.97.116.105.111.110.115.47.115.117.109.109.105.116.64.269.30.47.80.97.114.116.105.116.105.111.110.45.97.112.112.108.105.99.97.116.105.111.110.115.47.99.109.120.105.54.49.64.269.38080
.1.3.6.1.4.1.3375.2.2.5.4.3.1.11.30.47.80.97.114.116.105.116.105.111.110.45.97.112.112.108.105.99.97.116.105.111.110.115.47.115.117.109.109.105.116.64.269.30.47.80.97.114.116.105.116.105.111.110.45.97.112.112.108.105.99.97.116.105.111.110.115.47.99.109.120.105.54.49.64.269.38080 = Counter64: 11
but each time a made a modification on my F5 (for exemple add a new node or a new pool), my server index (269 in my exemple) is modified ... i don't understand how it can be possible ...