not the answer you want, but something went wrong in the steps then
can you run
do you get the current number then?
any errors in /var/log/ltm when you restarted the SNMP daemon?
I found this OID :
apmGlobalConnectivityStatCurConns ou 22.214.171.124.4.1.33126.96.36.199.5.3.0
By requesting this OID, I have the number of CCU licenses consumed. With this value, I see the CCU licenses consumed therefore the number of VPN connection on the plateform. Right or not ?
unfortunately not, if you compare that value against the output of
tmsh show apm license
it is different.
i tried a totally bad
but that doesnt get me any errors.
can you share the content of your custom_mib.tcl
Hello, I found my error in .tcl. It' working now. When I try the snmpwalk command, I have this result :
bigipTrafficMgmt.100.1.0 = Gauge32: 37
But I would like to understand. If I see the dashboard, I see the same number about Active Access Session than the command and I have also 5 open about Network Access Connection (as you can see in the screenshot). What is the différence ? The number about Network Access Connection is not only the number of VPN connected on the system via the EdgeClient ? And the 37 active access session is only the number of session open on the system to reach our Sharepoint Web portal (without tunnel access) ?
I'm sorry if my question is stupid...
great the SNMP works.
the result is interesting, can you also show the tmsh output to be sure. in principle that SNMP shows the connectivity license usage which is network access but also some other things.
see what counts as CCU and not: https://support.f5.com/csp/article/K13267
Find a new screenshots where we see 36 active access sessions and 4 Network Access Connections. I attached also the result of several commands :
1/ snmpwalk -Os -c public -v 2c localhost .188.8.131.52.4.1.33184.108.40.206 where the result is 36 as the number of active access session we seen in the screenshot dashboard
2/ The result of tmsh show apm license where we see the information about licenses
3/ config # snmpwalk -Os -c public -v 2c localhost 220.127.116.11.4.1.3318.104.22.168.5.3.0 where normally whit this OID, we see the number of CCU licenses consumed and the number (4) is the same number than the number of Network Access Connections in the dashboard screenshot..
I added also a screenshot to see active sessions in the F5. We see 36 connections but for me this number include the portal access (without tunnel resource) AND the number of VPN connections. So for me, the result of the first command is the number of total connections on the system, not only the number of VPN connections.
For me, the CCU is the licenses used when in your policy, you define a tunnel resource and access session is only for access without tunnel or rewriting policy
thanks, i might not understand what you are now exactly asking.
to repeat my understanding: CCU is not equal to VPN access
22.214.171.124.4.1.33126.96.36.199.5.3.0 seems to show network access connection, which is nice information but that is not the only thing that counts towards CCU
188.8.131.52.4.1.33184.108.40.206 truly shows CCU and is important for your license limit
Hello Jerome, I believe that is correct. If you look here you can see what OIDs are available. You also have ones such as apmAccessStatCurrentActiveSessions and apmAccessStatTotalSessions:
When I execute locally on the BIG-IP the command "snmpwalk -Os -c public -v 2c localhost .220.127.116.11.4.1.3318.104.22.168", it's working. But when I tried to launch this command from remote server with snmpwalk -Os -c public -v 2c IP_of_BIGIP .22.214.171.124.4.1.33126.96.36.199, the command failed. And if I try the same command but with another OID (188.8.131.52.4.1.33184.108.40.206.5.3.0 for example), it's working.. Do you know why ?
No. I have juste add in SNMP/Agent/Configuration, the IP address of my monitoring tool and in SNMP/Agent/Agent (V1, V2c), the name of my community (not the public) and in source, the IP address of my monitoring tool...
IPv4 devcentral : default Read Only
something like that? no value at OID right?
that just works for me locally and remote. i would do a packet capture to make sure your remote server sends the correct OID and it reaches the big-ip.