Netdisco attempts SNMP arpnip on all Pseudo devices which slows down job queue #561
Comments
|
Very sorry, cannot reproduce this! Note that you do have a misunderstanding: "arpwalk seems to queue arpnip for pseudo devices" This is correct! A pseudo device is needed for sshcollector targets if the target cannot run an SNMP discover. |
|
background: we use pseudodevs to mock up a topology over parts of our network where we can't acccess all data (managed mpls, private cellular for example). now, i did find an easy way to reproduce the issue: i add a pseudo device throught the webui. i gave it ip 169.254.33.33 & 3 ports, did not create any manual topo or did anything else than add the device.
then run a
important titbits fror our config (and some other devices & networks, but those don't matter here) we have no device_auth stanzas specifically for these devices, and only 1 stanza for ssh collecting (i"ll show that one, uses pubkey authentication) running arpnip manually shows netdisco tries to connect to the pseudodevice via snmp: there are a few solutions i can think of, from easiest to hardest:
version used: 2.042007, snmp::info 3.68 |
|
Thanks - this makes sense. Can you elaborate on why "remove 169.254.0.0/16 from devices_only" will be a solution? I don't follow... |
|
Also what is the output of |
|
Netdisco is trying SNMP because (I suspect) it thinks it has valid SNMP credentials... so the behaviour is, in some way, exactly according to design. How could it tell the credentials are not to be used? Perhaps as you suggest, an assumption could be made for pseudo devices never to do SNMP. This needs more thought. |
|
Hang on, is something fishy? Why is this happening: Netdisco gives higher priority to CLI worker than SNMP worker, so even with creds for both, CLI should succeed and then the job is done. Why is CLI skipped and then Netdisco moves to SNMP? |
|
As I read this, the device_auth does not apply so SNMP arpnip will be run. What worker is run is now purely based on layers also for pseudo devices, right? So if @inphobia your goal is to have no job run, setting the layers attribute to all zeros should do it I assume. |
well, there's really no need to run anything on 169.254.0.0/16 atm, it was left over from some previous tests.
since we don't have any cli creds for these devices. we have cli options for others. point i was trying to make is that we have a cli config, but not for these devices. could have been more clear.
correct; but new pseudo devs are always created with l3 & old ones were converted to include l3 a few updates ago (which was a great idea btw). perhaps i should get started on more more speudodev editing options, so you can customize them a bit more (like enabling/disabling l3 support). been thinking about that for a while now. being able to do so from device details would be nice but all of that depends on snmp write atm, extending the admin page -> pseudo devices would be a logical place but could get cluttered real quick. |
|
Oh okay! Now I understand what your issue is (I think!). On pseudo devices where you don't have/want/need CLI baed ARP collection, Netdisco needlessly attempts SNMP connect because default/applicable credentials exist, and this is bogging the backend and the queue? I'll have a think about it. (arguably better in another ticket as this is not the same as the original issue) |
|
adding them to devices_no is the easiest fix ofcourse, either by address or perhaps just with perhaps vendor:netdisco might even be a good default. if you're at the stage where you do cli collection on pseudo devices i guess you are at a level where changing that parameter won't be hard. on the other hand, devices_no is a common setting, so if we want to go this route imo it's best to add it to config & deployment.yml (else you might overwrite it without knowing). |
ollyg
changed the title
|
i've been thinking about pseudo devices (in the context of a more generic device override system) lately. perhaps the "model" field could be a way out here. currently pseudos have vendor "netdisco" but no model filled out. perhaps we could define a model type for pseudo devices that should arpnip and another for plain static devices. like:
when time permits i'm thinking & working on a more generic device type override for netdisco. we don't always have or even want write access to devices, but would like to change certain parameters, location is a big one. so i'm trying to build some kind of shadow version of certain dev tables where overrides can live. kinda like manual topology but on steroids. big dreams, now i just need to skill, time & talent to make them happen :) |
this patch resets all pseudo devices to have no layer3 support but adds a feature to the pseudo devices admin panel to enable layer3 support. it also changes arpnip and arpwalk behaviour to always permit the action if layer3 is available (ignoring the vendor). documentation will need updating to tell users to create pseudo devices with layer3 support when they want to arpnip an unsupported platform. arpnip with ssh/cli against a supported platform (one that can be discovered) will continue to work normally. Squashed commit of the following: commit 9dad5be Author: Oliver Gorwits <oliver@cpan.org> Date: Tue Sep 3 09:03:53 2019 +0100 allow pseudo with layer 3 to run arpnip commit 7d97943 Author: Oliver Gorwits <oliver@cpan.org> Date: Tue Sep 3 08:59:10 2019 +0100 allow pseudo devices with layer 2/3 capability commit d1fdf57 Author: Oliver Gorwits <oliver@cpan.org> Date: Tue Sep 3 08:55:41 2019 +0100 move pseudo and layer checks to is_able from is_able_now commit e0f72ef Author: Oliver Gorwits <oliver@cpan.org> Date: Tue Sep 3 08:51:42 2019 +0100 ports defaults to one commit 86ba012 Author: Oliver Gorwits <oliver@cpan.org> Date: Tue Sep 3 08:50:45 2019 +0100 add tooltip for arpnip toggle commit cdd2470 Author: Oliver Gorwits <oliver@cpan.org> Date: Tue Sep 3 08:34:46 2019 +0100 simplify template commit 46236d6 Author: Oliver Gorwits <oliver@cpan.org> Date: Sun Sep 1 23:53:56 2019 +0100 a fix up for pseudo devices which need layer 3 commit 016d249 Author: Oliver Gorwits <oliver@cpan.org> Date: Sun Sep 1 20:37:11 2019 +0100 do not wrap buttons commit 1ec1402 Author: Oliver Gorwits <oliver@cpan.org> Date: Sun Sep 1 20:33:03 2019 +0100 implement user settable layer-three service for pseudo devices commit a267efa Author: Oliver Gorwits <oliver@cpan.org> Date: Sun Sep 1 18:39:22 2019 +0100 only set layer if successful action commit b108be5 Author: Oliver Gorwits <oliver@cpan.org> Date: Sun Sep 1 18:32:19 2019 +0100 should defer SNMP against pseudo devices commit 897ba3a Merge: e0ddbaa a734890 Author: Oliver Gorwits <oliver@cpan.org> Date: Sun Sep 1 14:54:36 2019 +0100 Merge branch 'master' into og-pseudo-vs-cli-arpnip commit e0ddbaa Author: Oliver Gorwits <oliver@cpan.org> Date: Mon Aug 26 11:35:13 2019 +0100 as last commit, for discover commit 61f9c89 Author: Oliver Gorwits <oliver@cpan.org> Date: Sun Aug 25 23:55:38 2019 +0100 move pseudo and layer checks into is_*able functions commit 8b010d4 Author: Oliver Gorwits <oliver@cpan.org> Date: Sun Aug 25 18:38:11 2019 +0100 any device completing macsuck/arpnip must have that layer commit a11bce7 Author: Oliver Gorwits <oliver@cpan.org> Date: Sun Aug 25 18:33:27 2019 +0100 clean up device layers commit d2661bf Author: Oliver Gorwits <oliver@cpan.org> Date: Sun Aug 25 18:18:02 2019 +0100 first make arpnip behave like other jobs towards pseudo devices
arpnip is run & remains queued for pseudo devices, most likely due to 4ef5691 .
iirc the reasoning was that devices that don't do snmp at all can still run sshcollector, but for real pseudo devices (created via the web interface but not accessible) this will cause arpnip to be queued for them.
Expected Behavior
don't run any workers on pseudo devices.
Current Behavior
arpwalk seems to queue arpnip for pseudo devices.
Possible Solution
workaround is to assign add these devices to the "devices_no" setting.
Steps to Reproduce (for bugs)
(tested will arpwalk in webinterface, netdisco-do arpwalk & netdisco-do arpnip --enqueue)
Context
we use pseudo devices to mock up topology for a mpls network.
Your Environment
The text was updated successfully, but these errors were encountered: