netdisco
arpnip on Extreme VDX switches only gets IPv6 addresses
When I run the command "netdisco-do arpnip -d [IP OF DEVICE] -DIQ" it runs successfully but only displays IPv6 addresses from ARP, no IPv4 addresses. We run a dual stack environment.
Also, it collects IPv6 link-local addresses (and displays these on connected nodes in netdisco). I would expect it to exclude link-local addresses.
Expected Behavior
In addition to the Iv6 addresses, I would expect it to display IPv4 addresses as well
Current Behavior
Only IPv6 addresses from ARP are displayed
Steps to Reproduce (for bugs)
Setup dual stack Extreme VDX environment and run an arpnip.
Context
Connected nodes for switch ports displays MAC addresses and associated IPv6 addresses, but no IPv4 addresses or reverse lookup names for those IPv4 addresses.
Your Environment
- Netdisco version used: 2.39.31
- SNMP::Info version used: 3.61
I updated to Netdisco 2.39.33 and SNMP::Info 3.62 and issue is still present.
Thank you
Hi @nomisunrider
For collecting v4 addresses, the two methods at_paddr() and at_netaddr() are used. So, let's see what your device returns:
~/bin/netdisco-do show -d 1.2.3.4. -e at_paddr -DI
~/bin/netdisco-do show -d 1.2.3.4. -e at_netaddr -DI
If the output is empty, or addresses which Netdisco would skip, then that's the issue. If empty, you can see in the debug which SNMP table Netdisco is pulling and try to retrieve it yourself using snmpwalk. One common issue is the SNMP View restriction limiting get requests, in some way.
regards, Oliver.
Here is the output from the 2 commands.
` ~/bin/netdisco-do show -d 10.84.0.104 at_paddr -DI
[23268] 2019-05-24 21:13:30 info App::Netdisco version 2.039033 loaded.
[23268] 2019-05-24 21:13:31 info show: [10.84.0.104]/interfaces started at Fri May 24 16:13:31 2019
[23268] 2019-05-24 21:13:31 debug show: running with timeout 600s
[23268] 2019-05-24 21:13:31 debug => running workers for phase: check
[23268] 2019-05-24 21:13:31 debug -> run worker check/base/0
[23268] 2019-05-24 21:13:31 debug Show is able to run
[23268] 2019-05-24 21:13:31 debug => running workers for phase: main
[23268] 2019-05-24 21:13:31 debug -> run worker main/base/100
[23268] 2019-05-24 21:13:31 debug snmp reader cache warm: [10.84.0.104]
[23268] 2019-05-24 21:13:31 debug [10.84.0.104:161] try_connect with ver: 2, class: SNMP::Info::Layer3::Foundry, comm:
~/bin/netdisco-do show -d 10.84.0.104 at_netaddr -DI
[23279] 2019-05-24 21:13:38 info App::Netdisco version 2.039033 loaded.
[23279] 2019-05-24 21:13:38 info show: [10.84.0.104]/interfaces started at Fri May 24 16:13:38 2019
[23279] 2019-05-24 21:13:38 debug show: running with timeout 600s
[23279] 2019-05-24 21:13:38 debug => running workers for phase: check
[23279] 2019-05-24 21:13:38 debug -> run worker check/base/0
[23279] 2019-05-24 21:13:38 debug Show is able to run
[23279] 2019-05-24 21:13:38 debug => running workers for phase: main
[23279] 2019-05-24 21:13:38 debug -> run worker main/base/100
[23279] 2019-05-24 21:13:38 debug snmp reader cache warm: [10.84.0.104]
[23279] 2019-05-24 21:13:38 debug [10.84.0.104:161] try_connect with ver: 2, class: SNMP::Info::Layer3::Foundry, comm:
it seems you missed the -e parameter just before at_paddr & at_netaddr, so netdisco-do defaulted to showing interfaces instead of of addresses. i guess we should at least warn if parameters are not used...
can you run the commands again, but make sure to copy the as @ollyg showed?
Oops, thanks for catching that mistake. Here are the proper commands:
`~/bin/netdisco-do show -d 10.84.0.104 -e at_paddr -DI
[20879] 2019-05-26 01:27:57 info App::Netdisco version 2.039033 loaded.
[20879] 2019-05-26 01:27:57 info show: [10.84.0.104]/at_paddr started at Sat May 25 20:27:57 2019
[20879] 2019-05-26 01:27:57 debug show: running with timeout 600s
[20879] 2019-05-26 01:27:57 debug => running workers for phase: check
[20879] 2019-05-26 01:27:57 debug -> run worker check/base/0
[20879] 2019-05-26 01:27:57 debug Show is able to run
[20879] 2019-05-26 01:27:57 debug => running workers for phase: main
[20879] 2019-05-26 01:27:57 debug -> run worker main/base/100
[20879] 2019-05-26 01:27:57 debug snmp reader cache warm: [10.84.0.104]
[20879] 2019-05-26 01:27:57 debug [10.84.0.104:161] try_connect with ver: 2, class: SNMP::Info::Layer3::Foundry, comm:
~/bin/netdisco-do show -d 10.84.0.104 -e at_netaddr -DI
[20854] 2019-05-26 01:27:41 info App::Netdisco version 2.039033 loaded.
[20854] 2019-05-26 01:27:41 info show: [10.84.0.104]/at_netaddr started at Sat May 25 20:27:41 2019
[20854] 2019-05-26 01:27:41 debug show: running with timeout 600s
[20854] 2019-05-26 01:27:41 debug => running workers for phase: check
[20854] 2019-05-26 01:27:41 debug -> run worker check/base/0
[20854] 2019-05-26 01:27:41 debug Show is able to run
[20854] 2019-05-26 01:27:41 debug => running workers for phase: main
[20854] 2019-05-26 01:27:41 debug -> run worker main/base/100
[20854] 2019-05-26 01:27:41 debug snmp reader cache warm: [10.84.0.104]
[20854] 2019-05-26 01:27:41 debug [10.84.0.104:161] try_connect with ver: 2, class: SNMP::Info::Layer3::Foundry, comm:
`
I should also clarify, this is a layer 2 switch and these are the MAC addresses that actually show on the ports.
16 0014.4ff8.2d0f Dynamic Remote Te 4/0/4 16 0014.4ff8.45ca Dynamic Remote Te 4/0/4 16 0014.4ffa.1297 Dynamic Remote Te 4/0/4 16 0014.4ffa.a52b Dynamic Remote Te 4/0/3 16 0014.4ffa.a71b Dynamic Remote Te 4/0/11 16 0014.4ffa.b00b Dynamic Remote Te 4/0/11 16 0014.4ffa.de35 Dynamic Remote Te 4/0/3 16 0014.4ffa.f6ea Dynamic Remote Te 4/0/13 16 0014.4ffb.432c Dynamic Remote Te 4/0/13 16 0014.4ffb.463b Dynamic Remote Te 4/0/3 16 001e.6751.d404 Dynamic Remote Te 4/0/48 16 001e.6751.d405 Dynamic Remote Te 4/0/47 16 001e.6751.d409 Dynamic Remote Te 4/0/45 16 90e2.ba50.eba0 Dynamic Remote Te 4/0/46 80 0090.fa7e.98c4 Dynamic Remote Te 4/0/15
Also, when I run this on the router, it says unable to resolve method:
~/bin/netdisco-do show -d 10.84.0.2 -e net_paddr -DI
[21302] 2019-05-26 01:33:02 info App::Netdisco version 2.039033 loaded.
[21302] 2019-05-26 01:33:02 info show: [10.84.0.2]/net_paddr started at Sat May 25 20:33:02 2019
[21302] 2019-05-26 01:33:02 debug show: running with timeout 600s
[21302] 2019-05-26 01:33:02 debug => running workers for phase: check
[21302] 2019-05-26 01:33:02 debug -> run worker check/base/0
[21302] 2019-05-26 01:33:02 debug Show is able to run
[21302] 2019-05-26 01:33:02 debug => running workers for phase: main
[21302] 2019-05-26 01:33:02 debug -> run worker main/base/100
[21302] 2019-05-26 01:33:02 debug snmp reader cache warm: [10.84.0.2]
[21302] 2019-05-26 01:33:02 debug [10.84.0.2:161] try_connect with ver: 2, class: SNMP::Info::Layer3::Foundry, comm:
ahha, this gets us further.
first of: layer2 devices can return a the mac<->ip mappings they know, but for the full list you'll need to poll the gateway (10.84.0.2 in your case). while i'm not 100% sure why it does give you ipv6 addresses my guess is that because the way hardware address resolving works in ipv6 compared to ipv4 it has that info cached.
now, for your gateway it seems you used a wrong -e option: net_paddr
try at_paddr & at_netaddr instead
~/bin/netdisco-do show -d 10.84.0.2 -e at_paddr -DI
[28529] 2019-05-26 03:04:07 info App::Netdisco version 2.039033 loaded.
[28529] 2019-05-26 03:04:07 info show: [10.84.0.2]/at_paddr started at Sat May 25 22:04:07 2019
[28529] 2019-05-26 03:04:07 debug show: running with timeout 600s
[28529] 2019-05-26 03:04:07 debug => running workers for phase: check
[28529] 2019-05-26 03:04:07 debug -> run worker check/base/0
[28529] 2019-05-26 03:04:07 debug Show is able to run
[28529] 2019-05-26 03:04:07 debug => running workers for phase: main
[28529] 2019-05-26 03:04:07 debug -> run worker main/base/100
[28529] 2019-05-26 03:04:07 debug snmp reader cache warm: [10.84.0.2]
[28529] 2019-05-26 03:04:08 debug [10.84.0.2:161] try_connect with ver: 2, class: SNMP::Info::Layer3::Foundry, comm:
~/bin/netdisco-do show -d 10.84.0.2 -e at_netaddr -DI
[28537] 2019-05-26 03:04:12 info App::Netdisco version 2.039033 loaded.
[28537] 2019-05-26 03:04:13 info show: [10.84.0.2]/at_netaddr started at Sat May 25 22:04:13 2019
[28537] 2019-05-26 03:04:13 debug show: running with timeout 600s
[28537] 2019-05-26 03:04:13 debug => running workers for phase: check
[28537] 2019-05-26 03:04:13 debug -> run worker check/base/0
[28537] 2019-05-26 03:04:13 debug Show is able to run
[28537] 2019-05-26 03:04:13 debug => running workers for phase: main
[28537] 2019-05-26 03:04:13 debug -> run worker main/base/100
[28537] 2019-05-26 03:04:13 debug snmp reader cache warm: [10.84.0.2]
[28537] 2019-05-26 03:04:13 debug [10.84.0.2:161] try_connect with ver: 2, class: SNMP::Info::Layer3::Foundry, comm:
hm, why are all your addresses in the 127.0.0.0/8 range? those are designed to be device local, so netdisco tries it's best not to store them...
Those are not the client ipv4 addresses, all the clients are using class A 10.X.X.X addresses. I think the 127.X.X.X are likely local addresses the switch uses to reference its interfaces. The MAC addresses are also the MAC addresses of the interfaces, not the device connected to the ports.
that's quite strange, most likely foundry/brocade/ruckus is hiding those entries in some other mib leaf.
at this point our option are kinda running out. either we need to write an ssh arp collector for that device type (we alrdy have a few of them: https://github.com/netdisco/netdisco/tree/master/lib/App/Netdisco/SSHCollector/Platform) or we need a full snmp dump of the device to find out where the info is hiding: https://github.com/netdisco/snmp-info/wiki/Simulating-Agents#21-snmpsim--snmprec-version
the snmpdump would help us most but do be aware that this will dump the complete information base, so perhaps set up a private github repo if you don't want to share it with everyone.
kinda late reply, i'm backed up atm.
snmpwalk is useful, but i found the snmpsim method much more reliable way to troubleshoot subtle issues (it's a lot better at capturing returned data at verbatim, which is quite relevant for diagnosing). perhaps we should try & make a docker image for this purpose, that's what all the cool ppl seem to be migrating too 😝
this seems is a suspect, while i (still) don't have enough ipv6 rolled out to test this myself, the note in this part of the code seems to imply neighbors will be shows as either ipv4 or 6, but not as both. https://github.com/netdisco/netdisco/blob/0f1c264e410c1ee4de7c44a8f7550356c09225dd/lib/App/Netdisco/Worker/Plugin/Discover/Neighbors.pm#L130-L140
the whole topology thing in both snmp::info and netdisco could use some love. (see #340 & netdisco/netdisco#608) regretfully i work with first in / first out queues based on personal priorities. so it's on my radar, but low in the overal prio list for the time being.
just as a reminder: if you want to try and give a go at looking into this yourself we're more than willing to provide support via irc ( irc://irc.freenode.org/#netdisco ) or the mailing list.
side note:
Also, it collects IPv6 link-local addresses (and displays these on connected nodes in netdisco). I would expect it to exclude link-local addresses.
did you change this setting to true or is it still the default false
https://github.com/netdisco/netdisco/wiki/Configuration#ignore_private_nets
(note: this settting currently doesn't do anything for nodes or ipv6 yet, but can be relevant for device ports)
Hello, I am a coworker of nomisunrider. I have collected an snmp dump using snmpsim and uploaded it to a private repo. I will add you as a collaborator.
Not sure where to find the ignore_private_nets setting. Is that something that needs to be added to deployment.yml?
Hello, I am a coworker of nomisunrider. I have collected an snmp dump using snmpsim and uploaded it to a private repo. I will add you as a collaborator.
got it and it loaded succesfully. so the snmprec you gave is for the vdx6740? is this functioning only as a layer2 device? if so, i'd also need to snmprec from the device that's acting as the router for this lan segment.
if i have sensitive questions or need more details i'll send a mail or open an issue on the private repo, your choice.
Not sure where to find the ignore_private_nets setting. Is that something that needs to be added to deployment.yml?
the default deployment.yml contains all the config items you really should change or at least verify to get netdisco to run, but many more are available. we also have https://github.com/netdisco/netdisco/blob/master/share/config.yml which contains most options and their defaults, but for the most complete list of options (including their defaults, examples & such) see here: https://github.com/netdisco/netdisco/wiki/Configuration
That device is only using layer2, correct. I have uploaded the snmprec of the router to the private repo.
got it and can reproduce the problem. now i'll try & see if i can actually fix it :)
just to make it easier on me, could you give me 2 ip+mac addresses of actual clients, else kinda a lot of data to sift through :)
thx
10.80.89.188 - 00:90:FA:7E:98:C4 10.84.22.236 - 90:E2:BA:50:EB:A0
Both of those are connected to the layer2 switch.
Hello. It's been a while, but curious if you are able to still replicate this? Do you need fresh info for it?
Thanks
regretfully i've not been able to do much work on netdisco the past 12 months. i will be having some more spare time soon, so this issue is not forgotten.
Forgive my hijacking, but this might help...
most likely foundry/brocade/ruckus is hiding those entries in some other mib leaf [...] find out where the info is hiding
I have it at netdisco-do show -d 10.1.111.51 -DI -e ipNetToPhysicalPhysAddress
This command outputs the data I'd love to see in netdisco's database. I will follow up with the SSH collectors for now though.
