Send netdisco-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. A few issues with a new install (Maciej Leja)
2. Re: A few issues with a new install (Maciej Leja)
3. Re: A few issues with a new install (Oliver Gorwits)
4. Re: Listing ports with connected nodes never finishes (Andy Ruhl)
5. Re: Listing ports with connected nodes never finishes
(Christian Ramseyer)
--- Begin Message ---
Hello!
Replaced our 1.x installation with a new clean install of 2.x. Loving the
new changes but running into a few problems that I hope you all can help
with!
- I was hoping LLDP would discover all the switches in our environment but
it doesn't seem to have done so. Found about ~300 out of the 600 or so. I
wanted to add the rest manually in a batch but was wondering is there a
mechanism to do this or easiest is to run a quick script to loop through
"netdisco-do discover -d $switch_name" ?
- if the above is the case, I installed Netdisco into a separate dir
/opt/netdisco and I thought I got it installed properly as the app works
right - discovers and processes the information correctly. But for some
reason the netdisco-do command is using a default environments file (i'm
running it as netdisco). I was able to get it temporarily to work with a
symbolic link from /opt/netdisco/environments/deployments.yml (the proper
one) to
/opt/netdisco/perl5/lib/perl5/auto/share/dist/App-Netdisco/environments/deployment.yml.
That allowed me to move past the DBI Connect failed but now I get a bunch
of "Cannot find module (xxx)" so I think it's still looking for netdisco
files in the wrong location when running the netdisco-do command. I've
went through the steps to ensure I followed all the parts about installing
netdisco to another directory besides /home/netdisco/* so not sure what I
missed.
- on certain Juniper L3 switches with multiple interfaces, I will search
for the device by it's dns name that resolves to for example 192.168.1.3
(the loop back interface) but when it goes through the discover process it
ends up adding it using the fxp0 interface 10.0.0.4. So now it shows up as
10.0.0.4 with no DNS name. Any fix for this? Did I screw any part of this
up?
Thanks a bunch for any help in advance!
--- End Message ---
--- Begin Message ---
I see the following tip for juniper ex devices if information is incorrect:
lldp {
management-address 10.0.0.1;
port-id-subtype interface-name;
interface all;
}
I think this might help resolve my 3rd issue.
If so, all that's left is the first two issues - thanks!
On Tue, May 9, 2017 at 10:44 PM, Maciej Leja <[email protected]> wrote:
> Hello!
>
> Replaced our 1.x installation with a new clean install of 2.x. Loving the
> new changes but running into a few problems that I hope you all can help
> with!
>
> - I was hoping LLDP would discover all the switches in our environment but
> it doesn't seem to have done so. Found about ~300 out of the 600 or so. I
> wanted to add the rest manually in a batch but was wondering is there a
> mechanism to do this or easiest is to run a quick script to loop through
> "netdisco-do discover -d $switch_name" ?
>
> - if the above is the case, I installed Netdisco into a separate dir
> /opt/netdisco and I thought I got it installed properly as the app works
> right - discovers and processes the information correctly. But for some
> reason the netdisco-do command is using a default environments file (i'm
> running it as netdisco). I was able to get it temporarily to work with a
> symbolic link from /opt/netdisco/environments/deployments.yml (the proper
> one) to
> /opt/netdisco/perl5/lib/perl5/auto/share/dist/App-Netdisco/environments/deployment.yml.
> That allowed me to move past the DBI Connect failed but now I get a bunch
> of "Cannot find module (xxx)" so I think it's still looking for netdisco
> files in the wrong location when running the netdisco-do command. I've
> went through the steps to ensure I followed all the parts about installing
> netdisco to another directory besides /home/netdisco/* so not sure what I
> missed.
>
> - on certain Juniper L3 switches with multiple interfaces, I will search
> for the device by it's dns name that resolves to for example 192.168.1.3
> (the loop back interface) but when it goes through the discover process it
> ends up adding it using the fxp0 interface 10.0.0.4. So now it shows up as
> 10.0.0.4 with no DNS name. Any fix for this? Did I screw any part of this
> up?
>
> Thanks a bunch for any help in advance!
>
>
--- End Message ---
--- Begin Message ---
Hi Maciej,
You can queue an IP prefix (subnet) for discovery by entering that to
the web homepage or to netdisco-do discover. It does the same thing.
Running the script to loop through will do it in real-time rather than
via the job queue.
Did you set the NETDISCO_HOME environment variable before starting
Netdisco? And/or is /opt/netdisco the home directory of the user? Note
that you should not install Netdisco as root user.
regards,
oliver.
On 2017-05-10 04:44, Maciej Leja wrote:
Hello!
Replaced our 1.x installation with a new clean install of 2.x.
Loving the new changes but running into a few problems that I hope you
all can help with!
- I was hoping LLDP would discover all the switches in our environment
but it doesn't seem to have done so. Found about ~300 out of the 600
or so. I wanted to add the rest manually in a batch but was
wondering is there a mechanism to do this or easiest is to run a quick
script to loop through "netdisco-do discover -d $switch_name" ?
- if the above is the case, I installed Netdisco into a separate dir
/opt/netdisco and I thought I got it installed properly as the app
works right - discovers and processes the information correctly. But
for some reason the netdisco-do command is using a default
environments file (i'm running it as netdisco). I was able to get it
temporarily to work with a symbolic link from
/opt/netdisco/environments/deployments.yml (the proper one) to
/opt/netdisco/perl5/lib/perl5/auto/share/dist/App-Netdisco/environments/deployment.yml.
That allowed me to move past the DBI Connect failed but now I get a
bunch of "Cannot find module (xxx)" so I think it's still looking for
netdisco files in the wrong location when running the netdisco-do
command. I've went through the steps to ensure I followed all the
parts about installing netdisco to another directory besides
/home/netdisco/* so not sure what I missed.
- on certain Juniper L3 switches with multiple interfaces, I will
search for the device by it's dns name that resolves to for example
192.168.1.3 (the loop back interface) but when it goes through the
discover process it ends up adding it using the fxp0 interface
10.0.0.4. So now it shows up as 10.0.0.4 with no DNS name. Any fix
for this? Did I screw any part of this up?
Thanks a bunch for any help in advance!
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
I did a simple test. I counted rows in device_port and
device_port_vlan on the current production server, and I loaded a
backup of the database from a year ago. The numbers are not very
different, which is expected from my perspective.
This might not be a problem with those tables. Or at least, not a
problem with size.
I'm considering moving the current database to another name, creating
a new one, and re-discovering all devices. There are about 620 or so.
Andy
On Sat, May 6, 2017 at 9:00 AM, Oliver Gorwits <[email protected]> wrote:
> Hi Andy
>
> On large switches with many ports and many VLANs, the current Netdisco
> SQL query is definitely slow (and even broken in your case) as it tries
> to retrieve so much data in one go from the database.
>
> We could do with someone with good SQL chops taking a look at that -
> maybe some correlated subqueries or common table expressions need
> adding. Also we don't do paging in the UI so it gets all results and
> sends them to the client in one go.
>
> You could take a look at the number of rows in your device_port and
> device_port_vlan tables to see if they look "about right" or if
> something's gone wrong. Perhaps all 4095 VLANs have appeared on every
> port (and could be filtered with discover_no_vlan), or something
> similarly odd.
>
> Filtering some of the stored data via config might work, but is not
> ideal. Other than that, not a lot I can suggest, sorry. This is not seen
> (or reported) enough for us to understand the root cause, as yet.
>
> regards,
> oliver.
>
> On 2017-05-05 18:39, Andy Ruhl wrote:
>> I searched a bit and didn't find anything, hopefully this is a known
>> issue.
>>
>> On my larger switches (Cisco 6509, Juniper EX8208), if I click on the
>> "Ports" tab and I have connected devices and connected nodes checked,
>> the list never populates. I've let it sit for hours.
>>
>> On a smaller 1U switch, I get a list back not that quickly, but it
>> eventually populates.
>>
>> Where do I start troubleshooting?
>>
>> Things I've done:
>>
>> Use pgtune to tune the postgresql database
>>
>> Delete and re-discover the device
>>
>> vacuum the database
>>
>> None of these have worked.
>>
>> Andy
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Netdisco mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/netdisco-users
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Netdisco mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
On 06/05/17 18:00, Oliver Gorwits wrote:
> We could do with someone with good SQL chops taking a look at that -
> maybe some correlated subqueries or common table expressions need
> adding. Also we don't do paging in the UI so it gets all results and
> sends them to the client in one go.
>
Hi Oliver & Andy
I think this is the same issue we already talked about a while ago here:
https://sourceforge.net/p/netdisco/mailman/message/34714207/
Main problem seemed to not be the SQL, but that the whole result is
fetched from the database and this creates an astronomical amount of
DBIx::Class objects for big switches.
Steven Xu mentioned a private patch (presumably adding pagination) that
he "just needed to clean up a bit", but unfortunately that probably
didn't happen. Maybe we could get him to just release a diff.
Christian
--- End Message ---
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
