-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
F5 LTM and APM CLI ARP support #152
Comments
Got the interface names with this (from validate arp): |
Got this sorted out with:
And later during the ARP entries parsing: |
Another approach would be to get information about vlans and IPs the F5 has on that vlan in the CLI/F5.pm I'm working on, and populate from there the vlan interfaces with proper network and ips (selfip in f5), something f5 should expose on their SNMP but seems to not do. Then load the arp entries to the appropriate interface, and at the same time get rid of differences (if they exists) between git 1.0.7 and my production 1.0.7. |
Still wondering why my production netdot get different information about f5 interfaces.
Whereas in my dev machine it looks like:
That kind of number values are causing various errors, and are maybe the root cause that vlan interface are not added on dev machine. Argument "3.48.46.57" isn't numeric in sort at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 5583. But i can't find where that number is changed, or why it is not changed on my dev machine. In my F5.pm i'm trying to add code to populate vlan interfaces, but I think it'll be better to fix the numbering, and maybe interfaces will be created. |
I was checking things, when I run an update on my production machine it sees the same information as the dev one. At least that is consistent with relevant code being the same. Argument "3.48.46.57" isn't numeric in sort at /opt/netdot/netdot/prod/netdot-1.0.7/lib/Netdot/Model/Device.pm line 5643. So i suspect that if I delete the device, and rediscover it, i'll see exactly the same information as on my dev machine, 3 interfaces with not-numeric numbers. Now i wonder where did that change from numeric numbering and vlan added as interface to actual state and why. The database on production machine is really old. I guess it is due to SNMP::Info version changes (or maybe some other dependencies). |
Could not find a tarball with 3.01 version, but with 3.31 the behaviour is the same. Also with 3.35 which contains bugfixes for F5 module. |
Figured out what changed, the vlan interfaces are still there at 1.3.6.1.2.1.2.2.1 (ifEntry) and with nice numeric numbering. It is the addition of F5 support to snmp-info what makes it look for interfaces at 1.3.6.1.4.1.3375.2.1.2.4.1.2.1 (F5-BIGIP-SYSTEM-MIB.sysInterfaceEntry) where only physical interfaces are retrieved (and with the weird numbering). |
Got it working. However it needs you to don't be using SNMP::Info::Layer3::F5.pm. So either you can use an SNMP::Info version prior to 3.01, or (this is what I did), use latest and comment out the lines that load F5 module, in file Info.pm, at lines 1690 and 1746 (in my system (debian 10) it is located at /usr/local/share/perl/5.28.1/SNMP/Info.pm). In the meantime, and in absent of SNMP::Info::Layer3::F5, SNMP::Info::Layer3 takes care of adding the vlan interfaces and my script loads the ip information it finds for each vlan. If a vlan is not created i also creates it. But I don't know if you want me do a pull request for this while the snmp-info part is not fixed. Anyway with the SNMP-Info version the netdot installation recommends, that shouldn't be a problem, as it is prior to 3.01. But I wonder if an older system like that might be missing the f5bigip pb file that the underlying CLI libraries uses (located at /usr/local/share/perl/5.28.1/auto/share/dist/Net-CLI-Interact/phrasebook/f5/f5bigip in my system). Here's the code: In the absent of a pull request, if anyone is interested, besides copying the file to lib/Netdot/Model/Device/CLI/ and renaming it from F5.txt to F5.pm, there's only a few "manual" changes you need few changes to make this work. In a nutshell: And now some pics of how it looks. Best regards |
Hello,
I'm working on the code to get ARP tables from F5 LTM (load balancer) and APM (proxy).
First, I notice there is a difference on how this devices are treated from my production netdot version and the last git version.
On production, on the interface tab i see the physical interface and one entry for each vlan configured with the name "/Common/VLAN_XX" (that Common represents a F5 partition, Common is like "default" where vlans have to be created).
On last git, same device has only the entries for physical interfaces (2 and management on my LTM subject), and on each physical interface a combobox with all the VLANs.
Screenshots attached.
Production "old" 1.0.7
Latest GIT 1.0.7
Another thing, is that physical interfaces in my subject case are in reality members of an LACP, but f5 presents them as separate physical ports (with the same vlans in the combobox as they share configuration), anyway that's an f5 thing, not Netdot.
When I get the ARP from the device (command is "show net arp/show net ndp").
It is presented with relation to VLANs, not physical interfaces, so if I load $iname with the "/Common/VLAN_XX" value, validate_arp will not find a matching interface.
Sample ARP line:
10.1.2.3%4 10.1.2.3%4 00:11:22:33:44:56 /Common/VLAN_15 19 resolved
Any tip on how to map that /Common/VLAN_15 to the interfaces Netdot knows (talking about latest git version)?. The (physical interface are there (interface table) and the VLANs associated to that interfaces exists in the table interfacevlan, but I guess there must be a better approach than directly accessing the database from the CLI F5.pm.
If you notice an ARP tab in the latest git screenshot, that's becouse I cheated and set $iname to '0.9' to see if it load (and IGNORE_IPS_FROM_ARP_NOT_WITHIN_SUBNET => 0 as F5 have nothing in the "IP info" tab). Again, this has to do with how F5 presents information via SNMP, the IP the F5 has on a given vlan, is not presented as another devices do, it can be located on selfip oids, but i guess a fix to this should be addressed on SNMP::Info::Layer3::F5 (if there's something to be fixed, i don't feel qualified to decide on that)).
Thanks
The text was updated successfully, but these errors were encountered: