ZenPacks : F5 BIG-IP : Comments

RE: F5 BIG-IP

community@zenoss.org — Mon, 22 Aug 2011 18:55:41 GMT

Hi!

Thanks for developing this! I'm giving it a go and while I can see global graphs for my devices, I don't see a Components menu item or Virtual Server specific information. What can I look at to help figure it out?

BigIP LTM 3900; 10.2.1.297

Thanks!

Marc

RE: F5 BIG-IP

community@zenoss.org — Mon, 22 Aug 2011 19:29:42 GMT

From the CLI, as the zenoss user, can you run

zenmodeler run -d {DeviceName} -v 10

where {DeviceName} is the name of your LTM as its been added in Zenoss. If there is nothing obvious in there, could you paste the output into an attachment and I can take a look?

RE: F5 BIG-IP

community@zenoss.org — Mon, 22 Aug 2011 19:39:48 GMT

Hi!

I didn't see anything unsual in the zencommand run... It clearly sees my virtual servers. Perhaps it's the null filter?

You should have access to the shared file. If not, let me know!

Thanks again for your time!

RE: F5 BIG-IP

community@zenoss.org — Mon, 22 Aug 2011 19:49:16 GMT

The null filter "fails open" so if there is no filter, its assumed all virtual servers should be included (or least that was the intent). Looking at the code again, it still looks like that should be the case. We could answer that for sure by settinga filter of ".*"

Is it accurately filling in model information on the device overview page?

RE: F5 BIG-IP

community@zenoss.org — Mon, 22 Aug 2011 20:01:19 GMT

RE: Model information - All except Hardware Model --

Hardware ManufacturerEdit:

F5 Labs, Inc.

Hardware ModelEdit:

BIG-IP deprecated

OS ManufacturerEdit:

F5 Labs, Inc.

OS ModelEdit:

BIG-IP 10.2.1 297.0 Final

I set the filter to .*, remodeled and even restarted zenoss and remodeled, no change in behavior.

RE: F5 BIG-IP

community@zenoss.org — Mon, 22 Aug 2011 20:08:39 GMT

Hmm Interesting... I compared the output from my VIPPRION and 8900 and it looks pretty much like yours, so I'm not entirely sure whats going on.

1) Was this device added "fresh" after the zenpack was installed, or was it already present in Zenoss and you just moved into the new device class after installation?

2) Can you run the following from zendmd <run zendmd as zenoss user>

dev = dmd.Devices.findDevice('YourDeviceName')
print dev.LtmVs()

RE: F5 BIG-IP

community@zenoss.org — Mon, 22 Aug 2011 21:07:06 GMT

(1) Effectively added fresh... I have the same physical device in another tree, with a different name/hostname using my own monitoring templates as p-bna-bigip01.int. I added this one as bigip01.int; there exists a DNS entry pointing to the same IP as the other.

(2) feels like progress --

>>> dev = dmd.Devices.findDevice('bigip01.int')

>>> print dev.LtmVs()

Traceback (most recent call last):

File "<console>", line 1, in <module>

AttributeError: LtmVs

>>>

I saw that you had some commented out debuging at the end of BipLTMVirtualServerMap.py to print out the resulting relationship map... That looked ok to me and was populated so the filter isn't affecting it. Here's an example entry --

<ObjectMap {'VsStatusAvailState': 'Green - available in some capacity',

'VsStatusDetailReason': 'The virtual server is available',

'VsStatusEnabledState': 'Enabled',

'classname': '',

'compname': '',

'id': 'CACHE_HTTP',

'ltmVirtualServAddr': '\n\x01(\x18',

'ltmVirtualServName': 'CACHE_HTTP',

'ltmVirtualServPort': 80,

'ltmVsStatusAvailState': 1,

'ltmVsStatusDetailReason': 'The virtual server is available',

'ltmVsStatusEnabledState': 1,

'ltmVsStatusName': 'CACHE_HTTP',

'modname': 'ZenPacks.community.f5.BigipVirtualServer',

'snmpindex': '10.67.65.67.72.69.95.72.84.84.80',

'status': 'Up',

'vsIP': '10.1.40.24'}>

RE: F5 BIG-IP

community@zenoss.org — Mon, 22 Aug 2011 22:01:28 GMT

And this turned out to be the problem --

It seems that Zenoss is smarter than I wanted and it was making an internal assocation via the IP, not just name/hostname. Once I removed the original device and added it 'new' under the class, it works as expected. Sorry for all the noise; I learned a new bit of Zenoss internals today...

Thanks again for all your help.

RE: F5 BIG-IP

community@zenoss.org — Mon, 22 Aug 2011 22:03:23 GMT

Ha! You bet me to it. I was just in the middle of a long winded set of dmd commands to run to narrow this down, but the missing LtmVs keyed me that it was pulling the wrong device.

I'm glad its working, and thanks a ton for taking a look and providing feedback

RE: F5 BIG-IP

community@zenoss.org — Tue, 23 Aug 2011 16:13:08 GMT

Hi again!

Now that I have some graph data, I'm seeing interesting behavior. The graphs are blocky, as if the cycle time were set to 30 minutes, but I know that's not the case. After investigation, the consolidation function for your datapoints in the graph definitions is set to 'Max', when what I believe you intended was 'Average'. Average gives graph results that match your example above.

For example --

sysGlobalTmmStatClientBytesIn_sysGlobalTmmStatClientBytesIn

</property>

MAX

</property>

should be

sysGlobalTmmStatClientBytesIn_sysGlobalTmmStatClientBytesIn

</property>

AVERAGE

</property>

No action necessary on my part, but I thought you might want to update the ZenPack.

RE: F5 BIG-IP

community@zenoss.org — Tue, 23 Aug 2011 16:43:48 GMT

Thanks for the feedback. I had AVERAGE originally (as its the default) and when I was comparing graphs with what is presented in the 10.x GUI the MAX version looked to be a closer fit. The examples graphs above are actually using the MAX. I'm not opposed to the changing them back to AVERAGE if they work better.

Could you attach a screen shot of the blocky graph? I'm curious what that looks like vs what I'm getting.

RE: F5 BIG-IP

community@zenoss.org — Tue, 23 Aug 2011 17:04:59 GMT

To cut to the chase, I'm sure now that this is a result of the Default RRD Create Command. Perhaps mine or yours is not the default (it may be mine; I didn't install Zenoss originally). In mine, I do not have a MAX RRA with the same high resolution as AVERAGE --

RRA:AVERAGE:0.5:1:600

RRA:AVERAGE:0.5:6:600

RRA:AVERAGE:0.5:24:600

RRA:AVERAGE:0.5:288:600

RRA:MAX:0.5:6:600

RRA:MAX:0.5:24:600

RRA:MAX:0.5:288:600

For the short term graphs, the values should be nearly equivalent but for the longer term views, they'll begin to diverge. In my mind, it's a tossup which is better; seeing the average traffic over the period or seeing the what is essentially the spikes in traffic... I'm used to seeing average and doing the mental math on the longer term graphs so I'll probably stick with that as the default view.

What I expect I'll do is modify the default create command to include the higher res RRA, blow away my existing files then choose to graph one or the other as needed in the future (or add additional graphs).

Thanks again!

RE: F5 BIG-IP

community@zenoss.org — Tue, 23 Aug 2011 17:16:50 GMT

That makes a ton of sense. Ours has been altered to the following:

RRA:AVERAGE:0.5:1:106560

RRA:AVERAGE:0.5:3:71040

RRA:AVERAGE:0.5:12:26640

RRA:AVERAGE:0.5:288:1850

RRA:MAX:0.5:1:106560

RRA:MAX:0.5:3:71040

RRA:MAX:0.5:12:26640

RRA:MAX:0.5:288:1850

RE: F5 BIG-IP

community@zenoss.org — Wed, 19 Oct 2011 21:10:57 GMT

Hi,

I've installed the ZenPack and I can't get the BigIpVirtualServer under component to work. It doesn't even appear.

I've BiG IP LTM running 10.x.

Any help apreciated.

Thanks.

RE: F5 BIG-IP

community@zenoss.org — Wed, 19 Oct 2011 21:48:05 GMT

Have you gone through any of the troubleshootng steps mentioned in the posts above? Without a lilte information its going to be tricky to assist. A few questions

1) Was this deviced added fresh after ZenPack installation, or was it already present in the system and you dragged into the F5 device class after ZenPack installation?

2) Have you re-modeled the device?

3) Can you pass along the output of the zenmodeler command listed in the second post above?

RE: F5 BIG-IP

community@zenoss.org — Thu, 20 Oct 2011 15:57:21 GMT

Hi,

thanks, it works better now. I've deleted it and readded it and now I have the virtualservers..

thanks.

RE: F5 BIG-IP

community@zenoss.org — Thu, 20 Oct 2011 18:37:31 GMT

I'm also having problems getting the virtual servers to show up in the components. I've gone through the troubleshooting steps with no success. I can see a bunch of different things returned when I run zenmodeler -d <devicename> -v 10 but no components show up.

I see the following in zendmd:

>>> dev = dmd.Devices.findDevice('myDevice')

>>> print dev.LtmVs()

Traceback (most recent call last):

File "<console>", line 1, in <module>

AttributeError: LtmVs

>>>

The device was added new/fresh after the zenpack installation. I've bounced all the zenoss daemons.

Have any advice? Below is the device info from your Zenpack.

Hardware Manufactureredit:

F5 Labs, Inc.

Hardware Modeledit:

BIG-IP deprecated

OS Manufactureredit:

F5 Labs, Inc.

OS Modeledit:

BIG-IP 10.2.2 763.3 Final

RE: F5 BIG-IP

community@zenoss.org — Thu, 20 Oct 2011 23:14:56 GMT

johnnynoc, any chance you could drop me the full output from the manual modeler run? This is the first case I've seen of it not working after adding the device fresh, but I'm happy to work through what could be wrong.

And just to confirm, you've added the device in the /Network/f5 Device Class correct? This device class didnt exist prior to installing this pack did it?

If you can't get the output to me, I'll try to see if there any dmd commands we can run to narrow it down

On an unrelated note, what model device is this? Your the second occurence of "BIG-IP deprecated" and I'm starting to wonder if I need to add some logic to check some other OID to get a better hit ratio on that.

RE: F5 BIG-IP

community@zenoss.org — Fri, 21 Oct 2011 13:21:40 GMT

We're using Big-IP 1600s. When I came into the office I decided I'd bounce Zenoss and see what happened when I added our others LBs. And well, everything looks good now.

I just need to confirm the perf graphs work and stuff now.

Thanks for your offer to help but fortunately it wasn't necessary.

RE: F5 BIG-IP

community@zenoss.org — Mon, 21 Nov 2011 15:57:02 GMT

Hi,

I've just installed your new version in orfer to get pool and member info, but I don't see such thing. Only the virtiual servers?

Any idea?

Thanks.

RE: F5 BIG-IP

community@zenoss.org — Mon, 21 Nov 2011 16:18:18 GMT

Can you check which modeler plugins are applied to /Network/f5. As well as which ones are applied directly to the device in question? BigipLtmPoolMap and BigipLtmNodeMap are the two new modeler plugins that need to be applied. That should happen automatically when you install the pack, but perhaps something didnt work right there.

RE: F5 BIG-IP

community@zenoss.org — Mon, 21 Nov 2011 16:58:27 GMT

Hi David!

I am seeing this too but made some progress on it. Updated the plugin; zopectl restart; model devices. The devices had the new modeler plugins associated with them but they weren't being run (or even listed) by zenmodeler. After a full zenoss restart, zenmodeler now runs the plugins and they see the objects but I don't have the menu items under Components to view them --

2011-11-21 10:51:14,058 DEBUG zen.ZenModeler: <RelationshipMap [<ObjectMap {'classname': '',

'compname': '',

'id': 'HTTPS_APP_TEST_pool',

'ltmPoolActiveMemberCnt': 1,

'ltmPoolMemberCnt': 1,

'ltmPoolName': 'HTTPS_APP_TEST_pool',

'modname': 'ZenPacks.community.f5.BigipLtmPool',

'snmpindex': '19.72.84.84.80.83.95.65.80.80.95.84.69.83.84.95.112.111.111.108'}>,

<ObjectMap {'classname': '',

'compname': '',

'id': 'PRODTRACK_HTTP',

'ltmPoolActiveMemberCnt': 4,

'ltmPoolMemberCnt': 4,

'ltmPoolName': 'PRODTRACK_HTTP',

'modname': 'ZenPacks.community.f5.BigipLtmPool',

'snmpindex': '14.80.82.79.68.84.82.65.67.75.95.72.84.84.80'}>,

...

and

2011-11-21 10:51:14,077 DEBUG zen.ZenModeler: <RelationshipMap [<ObjectMap {'classname': '',

'compname': '',

'id': '10.1.41.77',

'ltmNodeAddrAddr': '10.1.41.77',

'ltmNodeAddrScreenName': 'p-prodtrack02.int',

'modname': 'ZenPacks.community.f5.BigipLtmNode',

'snmpindex': '1.4.10.1.41.77'}>,

<ObjectMap {'classname': '',

'compname': '',

'id': '10.1.41.167',

'ltmNodeAddrAddr': '10.1.41.167',

'ltmNodeAddrScreenName': 'p-app05.int',

'modname': 'ZenPacks.community.f5.BigipLtmNode',

'snmpindex': '1.4.10.1.41.167'}>,

<ObjectMap {'classname': '',

'compname': '',

'id': '10.1.41.58',

'ltmNodeAddrAddr': '10.1.41.58',

'ltmNodeAddrScreenName': 'p-prodtrack01.int',

'modname': 'ZenPacks.community.f5.BigipLtmNode',

'snmpindex': '1.4.10.1.41.58'}>,

RE: F5 BIG-IP

community@zenoss.org — Mon, 21 Nov 2011 17:05:15 GMT

hmmm... This was my first crack adding any of the custom javascript stuff, so very possible I did something wrong to affect the presence of the Menu items.

You still have the Virtual Server menu item that was part of the previous version?

As far as the full restart that makes sense and I should update the installation notes. I'm 95% sure that a new modeler plugin is only detected after a restart of zenhub. (At least thats what my limited exposure has shown to be the case).

Can you check the file on disk: ZenPacks/community/f5/browser/resources/js/Pool.js and see how it compares to https://github.com/dpetzel/ZenPacks.community.f5/blob/master/ZenPacks/community/f5/browser/resources/js/Pool.js

I don't know a whole lot about this menu stuff yet, so I may need to ask a few dumb questions before we make progress... sorry.

RE: F5 BIG-IP

community@zenoss.org — Mon, 21 Nov 2011 17:42:58 GMT

dpetzel wrote:

You still have the Virtual Server menu item that was part of the previous version?

Yes

Can you check the file on disk: ZenPacks/community/f5/browser/resources/js/Pool.js and see how it compares to https://github.com/dpetzel/ZenPacks.community.f5/blob/master/ZenPacks/community/f5/browser/resources/js/Pool.js

diff shows them to be identical.

I don't know a whole lot about this menu stuff yet, so I may need to ask a few dumb questions before we make progress... sorry.

No worries. It's new to me as well.

RE: F5 BIG-IP

community@zenoss.org — Mon, 21 Nov 2011 18:11:47 GMT

I'm curious if this isnt just stale javascript? Can you flush browser cache and/or start a new browser session?

Also on the Virtual Server item, what is the text that is listed? In the new Version it says "Virtual Servers" the old version listed it as "BigipVirtualServer"

RE: F5 BIG-IP

community@zenoss.org — Mon, 21 Nov 2011 23:51:00 GMT

Tried in FF and Safari, cleared cache on both, no go. It does say 'Virtual Servers' so at the least, that one is being used correctly.

RE: F5 BIG-IP

community@zenoss.org — Tue, 22 Nov 2011 00:03:17 GMT

One other bit - Node.js and Pool.js are being loaded (at least by Safari). I can seem them via view source and also Safari Develop > Show Error Console -> Resources. No errors are being thrown though that I can tell.

RE: F5 BIG-IP

community@zenoss.org — Tue, 22 Nov 2011 03:46:25 GMT

I don't pretend that this is a solution, but I found out a little info...

I setup a fresh test instance with the older pack, added the device, then upgraded the pack.

I was getting pretty much the same results as you, including the modeler output that was seeing the components.

I then deleted the device and re-added it. Everthing showed up after that.....

Again.. not a solution.... but might get it modeling for you... I'm still going to try and figure out why existing devices might bahave this way.

RE: F5 BIG-IP

community@zenoss.org — Tue, 22 Nov 2011 04:15:34 GMT

I have a 'slightly better' answer, which I think I can incorporate into the pack installer so this is not required in the next version. From zendmd do the following:

dev=dmd.Devices.findDevice("YourDevice")
dev.buildRelations()
commit()

If you've got a bunch the following should work as well

for dev in dmd.Devices.Network.f5.devices():
dev.buildRelations()
commit()

I should be able to do something akin to the loop above in the install method of the pack

RE: F5 BIG-IP

community@zenoss.org — Tue, 22 Nov 2011 14:29:40 GMT

OK, I think I have this fixed now. New egg available here: https://github.com/downloads/dpetzel/ZenPacks.community.f5/ZenPacks.community.f5-1.3-py2.6.egg

This rebuilds the relationships on /network/f5 devices at install time, which seems to be the fix for the missing components.

I also realized that node component template is missing from the egg, so those will model but not graph. Pools should graph. I should have some time tonight to fix the missing node component template and cut another egg.

RE: F5 BIG-IP

community@zenoss.org — Tue, 22 Nov 2011 18:20:49 GMT

The buildRelations() trick didn't work for me, even after zenoss restart, but deleting and re-adding one of my devices did work.

>>> dev=dmd.Devices.findDevice("p-bna-bigip01.int")

>>> dev.buildRelations()

>>> commit()

I still have one device left to test with. Because I still need to edit your package to fix graph definitions (MAX -> AVERAGE; disable stack on two graphs), I think I'll wait until you release the final updates before applying it to see if that works differently.

Thanks for your help!

RE: F5 BIG-IP

community@zenoss.org — Tue, 22 Nov 2011 18:24:21 GMT

I neglected to mention a remodel after fixing relationships. I think that would have done the trick. The 1.3 egg should resolve that, all its missing is the component template for nodes which I should get added tonight

On a related note. Are you changing the graphs based on personal preference or is there an issue? If its the latter, I'd like to fix.

RE: F5 BIG-IP

community@zenoss.org — Tue, 22 Nov 2011 19:54:47 GMT

Indeed it did. The other device had an automagic remodel about 30 minutes ago and the components are there now =)

As to the mods I make, most of them are because you have an unusually high resolution MAX DS for your graphs which I don't have so I convert those to AVERAGE (see our prior conversation about this). The specific changes I make are --

edit graph points to change from MAX to Average -

Bigip template -

Tmm Memory Utilization

Host Memory Utilization

Global Client Throughput + disable STACK to get proper graph colors/look

Global Client Connections

Global Server Throughput + disable STACK ''

Global Server Connections

Tmm Utilization Ratio

BiIPVirtualServer template -

Requests Per Second

Current Connections

Client Bytes

Connections Per Second

Marc

RE: F5 BIG-IP

community@zenoss.org — Tue, 22 Nov 2011 20:06:10 GMT

I do remember the earlier thread, but I think I missed the part about the unusually high resolution. I know on the server I was using at the time of that thread, we had the defaults jacked all the way up. On my latest go around I had thought I was testing with the default settings as they come in a 3.2.1 installation (I'll have to doublecheck that again to be sure).

I'm interested in knowing if other folks are applying the same customizations. If I'm the oddball (which happens more than I care to admit ) I'm happy to go with your settings if they look better.

If anyone else is actually using this, could you let me know how your graphs look and what customizations (if any) you've made.

Alternatively.... You've got me wondering.... I'm curious if I can dump your settings pre-install, upgrade, and then re-apply to save you from having to update that every time the pack updates.... Food for thought...

RE: F5 BIG-IP

community@zenoss.org — Tue, 22 Nov 2011 21:00:09 GMT

Hi,

I've installed your new version of the plugin and it worked. I have now the pool and the members.

Thanks.

RE: F5 BIG-IP

community@zenoss.org — Thu, 24 Nov 2011 01:15:41 GMT

OK, I've got an updated egg ready: https://github.com/downloads/dpetzel/ZenPacks.community.f5/ZenPacks.community.f5-1.5-py2.6.egg.

This should include the previuosly missing component templates.

Additionally I did some more testing based on your graph feedback and on a new fresh install I was seeing the same choppy graphs you described. This egg includes versions of the templates that use AVERAGE instead of MAX, and I also dropped the stack option on the two graphs you mentioned. Looks better on my fresh test install.

Let me know if you hit any issues.

Thanks

RE: F5 BIG-IP

community@zenoss.org — Sat, 26 Nov 2011 00:58:06 GMT

FYI... I updated this new version to https://github.com/zenoss/ZenPacks.community.f5/

I also got the tags to be more correct.

Thanks for making your ZenPack an example of how to do this right!

-Nick

RE: F5 BIG-IP

community@zenoss.org — Mon, 28 Nov 2011 18:32:53 GMT

Looks great! No problems that I can tell =)

RE: F5 BIG-IP

community@zenoss.org — Fri, 02 Dec 2011 21:46:34 GMT

We are using F5s with route-domains. F5 supports this by "sort-of" using IPv6 addresses internall, so there are a couple places where your scripts are bombing out. Particularly the BigipLtmNodeMap.py and PigipLtmVirtualServerMap.py scripts, when they try to use the socket.inet_ntoa call to convert the hex table indices to dotted decimal. It over-flows because when a route-domain is used, the address is 64 bits, (8 octets, not just 4). I looks a couple octets before the IP are differant as well. Here is an snmpwalk from out F5.

SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.2.1.4.3.64.74.80 = Hex-STRING: 03 40 4A 50

SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.2.3.8.3.64.64.75.0.0.0.2 = Hex-STRING: 03 40 40 4B 00 00 00 02

SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.2.3.8.3.64.64.76.0.0.0.2 = Hex-STRING: 03 40 40 4C 00 00 00 02

SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.2.3.8.3.64.64.77.0.0.0.2 = Hex-STRING: 03 40 40 4D 00 00 00 02

SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.2.3.8.3.64.64.78.0.0.0.2 = Hex-STRING: 03 40 40 4E 00 00 00 02

The first entry is a test entry which doesn't use a route-domain. The other four entries all use route-domain 2 ("%2" in F5 speak). (We have many other route-domains, but I left them off for brevity).

Here is the output of the unchanged values from the snmpwalk

'ltmNodeAddrAddr': '\x03@@\xca\x00\x00\x00\x03',

'ltmNodeAddrScreenName': 'alEVbempVMp03e',

'modname': 'ZenPacks.community.f5.BigipLtmNode',

'ltmNodeAddrAddr': '\x03@JP',

'ltmNodeAddrScreenName': 'testing',

'modname': 'ZenPacks.community.f5.BigipLtmNode',

The second node, which I created for testing, is the one that does not use a route-domain, The one above it uses route-domain 2.

Any help anyone could offer on how to convert the ltmNodeAddrAddr to the correct dotted-decimal format would be greatly appreciated.

RE: F5 BIG-IP

community@zenoss.org — Fri, 02 Dec 2011 21:57:04 GMT

I think I can update it to work. Looking at the python docs, I think I can use

socket.inet_ntop (as well as some better exception handling).

I dont jack about route-domains, and my hands-on with IPV6 is minimal, so I'll see what I can do, but I might need some assistance in testing once I get an update available.

RE: F5 BIG-IP

community@zenoss.org — Sat, 03 Dec 2011 05:11:30 GMT

OK, so I think I have a little better understand of the SNMP output when route-domains are involved after reading through some of the F5 documentation, but If you confirm a few things for me I'd appreciated it. Lets focuse on this one line for the sake of clarity:

SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.2.3.8.3.64.64.75.0.0.0.2 = Hex-STRING: 03 40 40 4B 00 00 00 02

So if I understnad this correctly this line stats. This nodes IP address is "3.64.64.75" and it belongs to route domain 2 aka "%2"?

For whatever reason on first reading your post I got the impression this was an IPv6 address which I could unpack with ntop. After more digging that seems to not be the case. Instead the output is 4 octets for the nodes IPv4 address, followed by 4 octets representing the nodes route domain.

03 40 40 4B - represents the nodes IPv4 address (3.64.64.75)

00 00 00 02 - represents the nodes route domain (2)

So if I understand it correctly, for the sake of determine the IP I think I can just ignore the last 4 octets. Does that sound resonable, or am I severly misunderstanding this route domain stuff, which is very possible

If this is accurate this should be a pretty easy fix

RE: F5 BIG-IP

community@zenoss.org — Mon, 05 Dec 2011 14:08:25 GMT

Sorry for not getting back to you sooner.

You are correct. F5 uses IPv6 addresses internally, but for this issue, they seem to be using only the last half of the ipv6 address. The format is very simiarl to how they map an ipv4 address to an ipv6 address, they just chopped off the first half of it. I tried writting my own function to convert, but am running into a little problem with type casting.

You can't just ignore the last four octets however, because they get added to the end of each table OID, not just the dotted decimal part of the ip address. So when you are trying to determine each table entry index, you can't just use the converted IP address (from hex to dotted decimal), you have to convert all 8 octets and use that as the table index.

BTW, here is the function I tried to get to work to replace the socket.inet_ntoa call. Which didn't work or course.

def hextodec(hexinput):

iplist = list(hexinput)

address = iplist[0] + iplist[1]

for i in range(2,len(hexinput)-1,2):

address = address + "." + iplist[i] + iplist[i+1]

return address

I realized I was trying to convert a string type representing a hex number, so I went back and looked again, but that was when I realized it doesn't look like the value retured by the OID isn't just a simple hex number.

I commented out the call the socket.inet_ntoa in your original script, then from the output screen when I tried to modle the F5 I saw the following.
ltmNodeAddrAddr': '\x03@@N\x00\x00\x00\x02'

For some reason it is showing the 2, 3, and 4th octets as the ascii equivalent for some reason. (@=0x40, N=0x4E)

Derek Small
CCIE 5832, CCSP, InfoSec
dwsmall@fatkid.com

RE: F5 BIG-IP

community@zenoss.org — Mon, 05 Dec 2011 14:24:17 GMT

Sorry, I believe I grabbed a differant line of output from the one were were focusing on. The entry that was being processed was 3.64.64.78.0.0.0.2, so @@N would be the correct ascii mappings of 64 64 78. However I still don't know why it's mapping those octets to char type.

Derek

RE: F5 BIG-IP

community@zenoss.org — Mon, 05 Dec 2011 14:28:11 GMT

I think the mapping to ascii might be a byproduct of the print/logging statements (unconfirmed). That aside. I wanted to clarify this statement:

You can't just ignore the last four octets however, because they get added to the end of each table OID, not just the dotted decimal part of the ip addressSo when you are trying to determine each table entry index, you can't just use the converted IP address (from hex to dotted decimal), you have to convert all 8 octets and use that as the table index.

What I'm proposing is simply ignoring when populating "ltmNodeAddrAddr". This is what is used in the UI to display the IPV4 address. the table index is actually stored two lines lower and is stored as the unaltered OID.

RE: F5 BIG-IP

community@zenoss.org — Mon, 05 Dec 2011 15:23:09 GMT

Sorry, I'm probably just confusing the issue. I thought you were polling the ltmNodeAddrAddr table, because you needed to add the dotted decimal translation of that result to end of each OID to get the corresponding values for other OIDs in the ltmNodeAddrTable. So if you are trying to get the availability for each node (OID 1.3.6.1.4.1.3375.2.2.4.1.2.1.13) then you would do an snmpget for OID 1.3.6.1.4.1.3375.2.2.4.1.2.1.13.3.64.64.75.0.0.0.2 where 3.64.64.75.0.0.0.2 is the translated return from the ltmNodeAddrAddr query. However, it looks like F5 sticks a couple extra numbers inbetween the first part of the OID and the table index.

SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.13.1.4.3.64.74.80 = INTEGER: 0

SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.13.3.8.3.64.64.75.0.0.0.2 = INTEGER: 0

SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.13.3.8.3.64.64.76.0.0.0.2 = INTEGER: 0

So the OID "SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.13" represents the OID for the Availability of a particular node (three in the case above). with addresses, 3.64.74.80, 3.64.64.75%2, and 3.64.64.76%2 respectively. (The first one doesn't use a route-domain). But the bytes in-between seem to indicate what type of entry it is (non-route domain for "1.4", and "3.8" for route-domain nodes).

If I'm really confussing you it's because I'm sure you know this stuff better than me. I'm a network guy trying to figure out what's going on in scripting language I've never used before..... So maybe it's best to just ignore me.....

RE: F5 BIG-IP

community@zenoss.org — Mon, 05 Dec 2011 15:33:42 GMT

Not going to ignore Sadly I'm neither a network guy or programmer, just someone who knows enough about both to be dangerous

Lets try something simple and see how it pans out. Can you replace:

om.ltmNodeAddrAddr = socket.inet_ntoa(om.ltmNodeAddrAddr)

with

om.ltmNodeAddrAddr = socket.inet_ntoa(om.ltmNodeAddrAddr[:4])

And see if it:

1) Works.

2) Produces any stack traces or useful information.

RE: F5 BIG-IP

community@zenoss.org — Mon, 05 Dec 2011 16:14:05 GMT

I was doing a little digging on this statement as well:

So the OID "SNMPv2-SMI::enterprises.3375.2.2.4.1.2.1.13" represents the OID for the Availability of a particular node (three in the case above). with addresses, 3.64.74.80, 3.64.64.75%2, and 3.64.64.76%2 respectively. (The first one doesn't use a route-domain). But the bytes in-between seem to indicate what type of entry it is (non-route domain for "1.4", and "3.8" for route-domain nodes).

and from what I can gather, the 1.4 and 3.8 are actually part of the SNMP standard: http://www.net-snmp.org/docs/mibs/INET-ADDRESS-MIB.txt. In a nutshell it the first number says what TYPE of address it is. The second value tells us how long.

So 1.4 is an ipv4 with a SIZE of 4

while 3.8 is ipv4z with a SIZE of 8.

I'de never heard of ipv4z but the description lines up with my limited understanding of route domains:

A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z
textual convention.

So with that a little better understood, I think (a little bit more) that the above slice might just do the trick.

RE: F5 BIG-IP

community@zenoss.org — Mon, 05 Dec 2011 17:19:51 GMT

Well, the BigipLtmNodeMap.py and BigipLtmVirtualServerMap.py scripts no longer generate errors, but the Nodes, pools and VIP aren't being added under my monitored components either. I can post the part of the output relevant to this issue. Or if you would rather, I can email it to you. You can email me at derek.small@ge.com, and I can reply if you don't want to post your email address.

Btw, where does the output of the modeler get written? I looked in /var/log/ and /opt/zenoss/log, but can't find it. I also enabled debugging for the modeler in Zenoss. Right now I'm just capturing the text from the output screen after a model a device.

RE: F5 BIG-IP

community@zenoss.org — Tue, 21 Feb 2012 01:10:00 GMT

Hi dpetzel, the download link was broken and I like to test. If possible I would also like trying to fix the VS status at model time issue. Can you please fix the link?

RE: F5 BIG-IP

community@zenoss.org — Tue, 21 Feb 2012 01:28:15 GMT

Done.

RE: F5 BIG-IP

community@zenoss.org — Fri, 23 Mar 2012 10:50:33 GMT

Hi,

i just tried the zenpack and it works very well - good job. but i have two things:

i took a look into the source and saw the mibs are inside, but my zenoss doesn't display the snmp traps from my F5 correctly, just the OID and not the text message.

example: "snmp trap enterprises.3375.2.4.0.1", which is also in the provided mibs F5-BIGIP-COMMON-MIB (f5.bigipTrafficMgmt.bigipNotification.bigipNotifications.bigipAgentStart)

what can i do that zenoss will display the correct msg instead of the OID?

second - is it possible to update the mibs? they are from version 10.1 (released 2009), right now 11.1 is the actual version.

thanks,

eric

RE: F5 BIG-IP

community@zenoss.org — Fri, 23 Mar 2012 11:37:32 GMT

I can't remember why but the MIBs are not actually installed, they are just 'there'. Rather than install the ones there, what you'll want to do is download the mibs from your 11.1 one device.

Once you have the new MIBS in hand, look around the admin guide, and the forums for zenmib This is the utility that will take the mibs and actually load them into Zenoss, which should be what your after.

RE: F5 BIG-IP

community@zenoss.org — Mon, 29 Oct 2012 16:44:21 GMT

Does anyone know if this zenpack triggers an alert\event when a goes node down, or a failover event occurs?

Thanks!

RE: F5 BIG-IP

community@zenoss.org — Mon, 29 Oct 2012 18:12:30 GMT

It won't. The way to accomplish that would be configure the Zenoss server as the SNMP trap destination. Then the F5 device will send an SNMP trap to the Zenoss Server. Assuming you have the latest MIBs installed (Download from your Device UI), the events should get created.

RE: F5 BIG-IP

community@zenoss.org — Mon, 29 Oct 2012 19:35:47 GMT

Thanks! I’ll check into using traps.

RE: F5 BIG-IP

community@zenoss.org — Wed, 31 Oct 2012 19:45:25 GMT

Hey there,

I have a main hub with 3 remote collectos (Zenoss 3.2.1). I deployed the collector everywhere. None of the F5 monitored instances are showing the Components (Pools, Nodes and Virtual Servers). Graphs are shoing data, though.

What am I doing wrong?

RE: F5 BIG-IP

community@zenoss.org — Wed, 31 Oct 2012 19:50:36 GMT

I don't think your doing anything wrong, this seems to be a fairly common issue on a fresh installation (I am not sure why).

Here are the steps (albeit perhaps overkill), that seems to have somewhat consistent results:

You need to restart more than just zopectl, I'd suggest a full stack restart if you can afford it, but zenhub seems to need a nudge at the very least.

Also make sure the VS, POOL, and NODE *modeler plugins* are applied to the device class

Additionally (this is going to sound wierd), it seems that after the restarting, deleting and readding the devices does something magical.... I can't explain it, but I have witnessed this myself. I was getting none of that information, but deleting and re-adding did the trick

Side note, there is no reason to bind anything but the Bigip template. The other 3 are component templates and should not be bound directly to the device or device class (they get bound automatically based on the modeler results)

RE: F5 BIG-IP

community@zenoss.org — Wed, 31 Oct 2012 20:02:22 GMT

Thanks, I will give it a try and report back.

RE: F5 BIG-IP

community@zenoss.org — Mon, 05 Nov 2012 23:10:43 GMT

Hi dpetzel,

I deleted and re-added the devices, and it did not make a difference.

Can I ask you what you mean by "Also make sure the VS, POOL, and NODE *modeler plugins* are applied to the device class"? Please advise, or describe procedure. I went under Advanced -> Monitoring Templates -> Group by Temaplte. I have the following:

Is there anything else I need to check?

RE: F5 BIG-IP

community@zenoss.org — Tue, 06 Nov 2012 03:34:12 GMT

If you navigate to the device in question, you should see modeler plugins as one of the navigation bar entries on the left hand side. There will be two columns, one for available, and one for applied, make usre those are in the applied column.

Would it be possible for you to run `zenperfsnmp -d <yourdevice> -v 10` and make that output available somewhere?

Also did you update the remote collectors after installing this pack?