ZABBIX Forums  

Go Back   ZABBIX Forums > Zabbix Discussions and Feedback > Zabbix Cookbook

Reply
 
Thread Tools Display Modes
  #21  
Old 06-03-2014, 14:24
mrafi mrafi is offline
Junior Member
 
Join Date: Feb 2014
Posts: 10
Default

Quote:
Originally Posted by mrafi View Post
I will try your script as well, but if it is same as the expouser one then it will not work for me because I tried that before...
yep I tried your scrip now it is working, I cannot see any difference in the output except that now I understand they key format you pasted earlier is working for your script because you defined the variable in different order.
Reply With Quote
  #22  
Old 01-12-2015, 09:12
zied.bouazizi zied.bouazizi is offline
Junior Member
 
Join Date: Nov 2015
Posts: 1
Default

Quote:
Originally Posted by mrafi View Post
yep I tried your scrip now it is working, I cannot see any difference in the output except that now I understand they key format you pasted earlier is working for your script because you defined the variable in different order.
Hi All,

I would like to thank you first for your precious advices and shared experiences with zabbix.
I ran the last script and it looks working by retrieving data and bandwidth statistics. However, the resulted graph is discontinuous so we can't get a good idea about the ipsec tunnel bandwidth evolution.

Could you please help me to find what would be the issue?

Kind Regards,
Attached Images
 
Reply With Quote
  #23  
Old 25-05-2016, 16:31
Linwood Linwood is offline
Senior Member
 
Join Date: Dec 2013
Location: Cape Coral, FL, USA
Posts: 257
Default

I don't know if this topic is too old but let's see...

I started trying to monitor ASA's and ended up somewhere near this. I started with Rancid however, scanning the cisco configs for defined tunnels, so I would have a list of what I expected and could detect tunnels that were never coming active, and matching this up against the data similar to what's in the script here.

However, in validating that it matches what I see in CLI, I find I am confused by the meaning of some of the tables.

This script from above sees to scan the Phase 1 list (cikeTunRemoteValue) and also the Phase 2 list (cipSecTunIkeTunnelIndex).

But the MIB has this thing in the middle called a cikePeerCorrTable, which is described as having one entry for each active tunnel and linking the phase 1 and phase 2 together. I don't see that the above scripts refer to that.

The reason I ask is that I'm finding two situations which are distinguished by that table, and am not quite sure how to interpret them.

1) The Correlation table may have only 1 tunnel, but there will be two with the same local/remote IP's in the Phase 2 table (i.e. anything with cipSec*). What is the meaning of the unreferenced extra entry? Is it prior data from a recent index change and so should be ignored?

2) The Correlation table may have multiple entries for one local/remote pair, and so similarly the cipSec* values also have multiple entries. I THINK, from just observation, this relates to separate ACL's which are going to represent separate end points, and what should be done with these is add them together to report relative to one Local/Remote IP pair (or conversely if you wanted to do separate endpoint subnet reporting, separate them out, but I do not).

Is this the correct interpretation? How have people using this dealt with the correlation table and reconciling the (otherwise) redundancies in the cipSec* fields?

I THINK the scripts in this thread just add them together all the time, but I'm curious if that's correct for cases when the tunnel in the cipSec* does not appear in the correlation table?

Finally - any else tried reconciling these against Rancid scripts, to find dead tunnels (but obviously ones with redundant routing or you would already know)? It's tedious and my syntax checking so far is very inadequate for the range of setups you can have (notably it does not handle multiple output IP's very well), so was wondering if this wheel has already been invented somewhere?
Reply With Quote
  #24  
Old 26-05-2016, 04:18
Linwood Linwood is offline
Senior Member
 
Join Date: Dec 2013
Location: Cape Coral, FL, USA
Posts: 257
Default

I thought perhaps an example will make these comments a bit more clear.

The script below appears to use portions of this table to find the peers (I've obvious redacted some stuff).

Code:
# snmpwalk -v2c -cSomeSecret QQQQQQQQQQ  CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1413120 = STRING: 38. XXX.YYY.18
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1466368 = STRING: 50. XXX.YYY.77
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1531904 = STRING: 71. XXX.YYY.146
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1548288 = STRING: 50. XXX.YYY.37
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1556480 = STRING: 50. XXX.YYY.197
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1564672 = STRING: 69. XXX.YYY.86
Notice it shows 6 tunnels. That's phase 1.

Here's the actual data for outbound. Notice 7 tunnels.

Code:
# snmpwalk -v2c -cSomeSecret QQQQQQQQQQ  CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.352 = Counter64: 5866936627
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.353 = Counter64: 262710686
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.354 = Counter64: 27563120
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.367 = Counter64: 23461309
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.383 = Counter64: 19718614
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.387 = Counter64: 1752756
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.389 = Counter64: 2119089
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.391 = Counter64: 86627
The actual indexes for the above tunnel data comes from here, the correlation table. Notice it has 7 entries, and the flagged lines show where there are two for one peer pair. That pair has two endpoint subnets, which is why I think it comes out like this:

Code:
# snmpwalk -v2c -cSomeSecret QQQQQQQQQQ  CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrTable
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."50.XXX.YYY.77".500.367 = INTEGER: 367
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."50.XXX.YYY.37".500.387 = INTEGER: 387
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."69.XXX.YYY.86".500.391 = INTEGER: 391
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."38.XXX.YYY.18".500.352 = INTEGER: 352  <<<< 
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."38.XXX.YYY.18".500.354 = INTEGER: 354  <<<<
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."71.XXX.YYY.146".500.383 = INTEGER: 383
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."50.XXX.YYY.197".500.389 = INTEGER: 389
Right at this moment I can't find any cases where there are entries in the cipSec* data that are not in the peer correlation table, but I thought I saw some. Maybe I caught it right on a tunnel creation or something.

So my question is one of interpretation -- what I'm doing it using the peer correlation table to find the appropriate indexes (e.g. 352, 354 for the flagged lines) and query those into the cipSec* tables, and add them together. And if any data is at indexes not in the peer correlation table, ignore it.
Reply With Quote
  #25  
Old 04-12-2017, 20:21
mdiorio mdiorio is offline
Junior Member
 
Join Date: Mar 2016
Posts: 19
Default

Dredging up this old thread. This is exactly what I was looking for and works perfectly.

Just a few things to note:

You may need to install the Perl Module Switch as it's deprecated in the core.

The shebang in the script needs to end with -X because Switch is deprecated, it will return an error message with the value and mess everything up. The -X ignores the deprecation warning and only returns the value.

Thanks very much for this script!
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 09:38.