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. Re: Switches with empty os_ver fields (Oliver Gorwits)
2. Re: Switches with empty os_ver fields (Andy Ruhl)
3. Re: IP address confusion when discovering Arista switch
(Mark Boolootian)
4. Re: Can netdisco auto-discover to plot whole network?
(Hans Erasmus)
--- Begin Message ---
Hi Andy
I believe we have just updated Netdisco's MIB bundle for the G8264.
Please run netdisco-deploy and try a discover on the devices, and let us
know how it goes.
regards,
oliver.
On 2017-07-12 16:24, Andy Ruhl wrote:
Ok. All are this class:
SNMP::Info::Layer3::IBMGbTor
I'm not 100% sure if that's correct, the non working 2 have MIBs that
have specific names:
GbTOR-G8264.mib
GbTOR-G8052.mib
These come with the firmware download for the switches.
Here's some data:
(G8124, good)
$ netdisco-do show -d x.x.x.19 -DI -e Layer3::IBMGbTor::os_ver
[3259] 2017-07-12 14:47:15 info show: started at Wed Jul 12 14:47:15
2017
[3259] 2017-07-12 14:47:15 debug [x.x.x.19] try_connect with ver: 2,
class: SNMP::Info::Layer3::IBMGbTor, comm: <hidden>
SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
.1.3.6.1.2.1.1.3.0
SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 :
.1.3.6.1.2.1.1.7.0
SNMP::Info::_global agSoftwareVersion :
IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
.1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
"7.11.10" <------------- BINGO
[3259] 2017-07-12 14:47:16 info show: finished at Wed Jul 12 14:47:16
2017
[3259] 2017-07-12 14:47:16 info show: status done: Showed os_ver
response from x.x.x.19.
(G8264, bad)
$ netdisco-do show -d x.x.x.18 -DI -e Layer3::IBMGbTor::os_ver
[3441] 2017-07-12 14:47:26 info show: started at Wed Jul 12 14:47:26
2017
[3441] 2017-07-12 14:47:26 debug [x.x.x.18] try_connect with ver: 2,
class: SNMP::Info::Layer3::IBMGbTor, comm: <hidden>
SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
.1.3.6.1.2.1.1.3.0
SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 :
.1.3.6.1.2.1.1.7.0
SNMP::Info::_global agSoftwareVersion :
IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
.1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
SNMP::Info::_validate_autoload_method(CARP_TRACE) Unable to resolve
method.
SNMP::Info::_global(agSoftwareVersion) NOSUCHOBJECT at
/home/netdisco/bin/netdisco-do line 142.
[3441] 2017-07-12 14:47:27 info show: finished at Wed Jul 12 14:47:27
2017
[3441] 2017-07-12 14:47:27 info show: status error: error running
job: When calling p() without prototypes, please pass arguments as
references at /home/netdisco/bin/netdisco-do line 142.
(G8052, bad)
$ netdisco-do show -d x.x.x.17 -DI -e Layer3::IBMGbTor::os_ver
[4825] 2017-07-12 15:18:45 info show: started at Wed Jul 12 15:18:45
2017
[4825] 2017-07-12 15:18:45 debug [x.x.x.17] try_connect with ver: 2,
class: SNMP::Info::Layer3::IBMGbTor, comm: <hidden>
SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
.1.3.6.1.2.1.1.3.0
SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 :
.1.3.6.1.2.1.1.7.0
SNMP::Info::_global agSoftwareVersion :
IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
.1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
SNMP::Info::_validate_autoload_method(CARP_TRACE) Unable to resolve
method.
SNMP::Info::_global(agSoftwareVersion) NOSUCHOBJECT at
/home/netdisco/bin/netdisco-do line 142.
[4825] 2017-07-12 15:18:45 info show: finished at Wed Jul 12 15:18:45
2017
[4825] 2017-07-12 15:18:45 info show: status error: error running
job: When calling p() without prototypes, please pass arguments as
references at /home/netdisco/bin/netdisco-do line 142.
I can keep working on this as long as I can figure it out.
Andy
On Wed, Jul 12, 2017 at 7:34 AM, Oliver Gorwits <[email protected]>
wrote:
Hi Andy,
On 2017-07-12 15:09, Andy Ruhl wrote:
Thanks for your help yesterday Oliver.
:-)
I have 2 switches that have always had blank os_ver fields.
Based on yesterday's troubleshooting, I tried the same stuff but I'm
not getting anywhere.
I would start with the one which is working, and find the Device Class
which
SNMP::Info is using: either from the device table in the database or
the
Device Class field shown in Device -> Details tab in the web.
Find the source file for that online somewhere here:
https://metacpan.org/release/SNMP-Info
Look for an os_ver() subroutine, and see what it's doing. Perhaps it
pulls
agSoftwareVersion which works for that model.
The other thing to do is check which Device Class the *not working*
devices
are being assigned. Hopefully the same as the working device.
If not, then it may be a case of updating the rules in SNMP/Info.pm
which
assign the Device Classes. You can force a device class for testing
(we
strip SNMP::Info from the front of the classname):
~netdisco/bin/netdisco-do show -d 1.2.3.4 -e Layer3::HP::os_ver
If the device class is correct for the not-working devices, then it'll
probably be related to which SNMP leaf to get. As in the JUNOS
software
version example you had before, sometimes we need to fetch a couple of
leaves and try them in turn.
regards,
oliver.
Here is some psql info:
model | vendor | os_ver
--------------+---------+---------------
G8052 | ibm |
G8264, Stack | ibm |
G8124-E | ibm | 7.11.10
The G8124-E is the only switch that has ever had a populated os_ver
field, it never worked for the others.
So I did discover with -DISQ and I don't see a version string
anywhere
in the output that looks like "7.11.10".
I did notice this for 8052 and 8264 devices:
SNMP::Info::_global(agSoftwareVersion) NOSUCHOBJECT at
/home/netdisco/perl5/lib/perl5/App/Netdisco/Core/Discover.pm line
186.
Any hints on how to continue for this one?
Thanks.
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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 updated Netdisco, did netdisco-deploy, and restarted.
No change unfortunately.
The class for the G8264 is still this:
SNMP::Info::Layer3::IBMGbTor
I can get whatever info you need.
Thanks.
Andy
On Mon, Aug 14, 2017 at 8:17 AM, Oliver Gorwits <[email protected]> wrote:
> Hi Andy
>
> I believe we have just updated Netdisco's MIB bundle for the G8264.
>
> Please run netdisco-deploy and try a discover on the devices, and let us
> know how it goes.
>
> regards,
> oliver.
>
>
> On 2017-07-12 16:24, Andy Ruhl wrote:
>>
>> Ok. All are this class:
>>
>> SNMP::Info::Layer3::IBMGbTor
>>
>> I'm not 100% sure if that's correct, the non working 2 have MIBs that
>> have specific names:
>>
>> GbTOR-G8264.mib
>> GbTOR-G8052.mib
>>
>> These come with the firmware download for the switches.
>>
>> Here's some data:
>>
>> (G8124, good)
>> $ netdisco-do show -d x.x.x.19 -DI -e Layer3::IBMGbTor::os_ver
>> [3259] 2017-07-12 14:47:15 info show: started at Wed Jul 12 14:47:15 2017
>> [3259] 2017-07-12 14:47:15 debug [x.x.x.19] try_connect with ver: 2,
>> class: SNMP::Info::Layer3::IBMGbTor, comm: <hidden>
>> SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
>> .1.3.6.1.2.1.1.3.0
>> SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 :
>> .1.3.6.1.2.1.1.7.0
>> SNMP::Info::_global agSoftwareVersion :
>> IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
>> .1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
>> "7.11.10" <------------- BINGO
>> [3259] 2017-07-12 14:47:16 info show: finished at Wed Jul 12 14:47:16
>> 2017
>> [3259] 2017-07-12 14:47:16 info show: status done: Showed os_ver
>> response from x.x.x.19.
>>
>> (G8264, bad)
>> $ netdisco-do show -d x.x.x.18 -DI -e Layer3::IBMGbTor::os_ver
>> [3441] 2017-07-12 14:47:26 info show: started at Wed Jul 12 14:47:26 2017
>> [3441] 2017-07-12 14:47:26 debug [x.x.x.18] try_connect with ver: 2,
>> class: SNMP::Info::Layer3::IBMGbTor, comm: <hidden>
>> SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
>> .1.3.6.1.2.1.1.3.0
>> SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 :
>> .1.3.6.1.2.1.1.7.0
>> SNMP::Info::_global agSoftwareVersion :
>> IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
>> .1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
>> SNMP::Info::_validate_autoload_method(CARP_TRACE) Unable to resolve
>> method.
>> SNMP::Info::_global(agSoftwareVersion) NOSUCHOBJECT at
>> /home/netdisco/bin/netdisco-do line 142.
>> [3441] 2017-07-12 14:47:27 info show: finished at Wed Jul 12 14:47:27
>> 2017
>> [3441] 2017-07-12 14:47:27 info show: status error: error running
>> job: When calling p() without prototypes, please pass arguments as
>> references at /home/netdisco/bin/netdisco-do line 142.
>>
>> (G8052, bad)
>> $ netdisco-do show -d x.x.x.17 -DI -e Layer3::IBMGbTor::os_ver
>> [4825] 2017-07-12 15:18:45 info show: started at Wed Jul 12 15:18:45 2017
>> [4825] 2017-07-12 15:18:45 debug [x.x.x.17] try_connect with ver: 2,
>> class: SNMP::Info::Layer3::IBMGbTor, comm: <hidden>
>> SNMP::Info::_global uptime : DISMAN-EVENT-MIB::sysUpTimeInstance :
>> .1.3.6.1.2.1.1.3.0
>> SNMP::Info::_global layers : SNMPv2-MIB::sysServices.0 :
>> .1.3.6.1.2.1.1.7.0
>> SNMP::Info::_global agSoftwareVersion :
>> IBM-GbTOR-10G-L2L3-MIB::agSoftwareVersion.0 :
>> .1.3.6.1.4.1.26543.2.7.4.1.1.1.10.0
>> SNMP::Info::_validate_autoload_method(CARP_TRACE) Unable to resolve
>> method.
>> SNMP::Info::_global(agSoftwareVersion) NOSUCHOBJECT at
>> /home/netdisco/bin/netdisco-do line 142.
>> [4825] 2017-07-12 15:18:45 info show: finished at Wed Jul 12 15:18:45
>> 2017
>> [4825] 2017-07-12 15:18:45 info show: status error: error running
>> job: When calling p() without prototypes, please pass arguments as
>> references at /home/netdisco/bin/netdisco-do line 142.
>>
>> I can keep working on this as long as I can figure it out.
>>
>> Andy
>>
>> On Wed, Jul 12, 2017 at 7:34 AM, Oliver Gorwits <[email protected]> wrote:
>>>
>>> Hi Andy,
>>>
>>> On 2017-07-12 15:09, Andy Ruhl wrote:
>>>>
>>>>
>>>> Thanks for your help yesterday Oliver.
>>>
>>>
>>>
>>> :-)
>>>
>>>> I have 2 switches that have always had blank os_ver fields.
>>>>
>>>> Based on yesterday's troubleshooting, I tried the same stuff but I'm
>>>> not getting anywhere.
>>>
>>>
>>>
>>> I would start with the one which is working, and find the Device Class
>>> which
>>> SNMP::Info is using: either from the device table in the database or the
>>> Device Class field shown in Device -> Details tab in the web.
>>>
>>> Find the source file for that online somewhere here:
>>> https://metacpan.org/release/SNMP-Info
>>>
>>> Look for an os_ver() subroutine, and see what it's doing. Perhaps it
>>> pulls
>>> agSoftwareVersion which works for that model.
>>>
>>> The other thing to do is check which Device Class the *not working*
>>> devices
>>> are being assigned. Hopefully the same as the working device.
>>>
>>> If not, then it may be a case of updating the rules in SNMP/Info.pm which
>>> assign the Device Classes. You can force a device class for testing (we
>>> strip SNMP::Info from the front of the classname):
>>>
>>> ~netdisco/bin/netdisco-do show -d 1.2.3.4 -e Layer3::HP::os_ver
>>>
>>> If the device class is correct for the not-working devices, then it'll
>>> probably be related to which SNMP leaf to get. As in the JUNOS software
>>> version example you had before, sometimes we need to fetch a couple of
>>> leaves and try them in turn.
>>>
>>> regards,
>>> oliver.
>>>
>>>
>>>
>>>> Here is some psql info:
>>>>
>>>> model | vendor | os_ver
>>>> --------------+---------+---------------
>>>> G8052 | ibm |
>>>> G8264, Stack | ibm |
>>>> G8124-E | ibm | 7.11.10
>>>>
>>>> The G8124-E is the only switch that has ever had a populated os_ver
>>>> field, it never worked for the others.
>>>>
>>>> So I did discover with -DISQ and I don't see a version string anywhere
>>>> in the output that looks like "7.11.10".
>>>>
>>>> I did notice this for 8052 and 8264 devices:
>>>>
>>>> SNMP::Info::_global(agSoftwareVersion) NOSUCHOBJECT at
>>>> /home/netdisco/perl5/lib/perl5/App/Netdisco/Core/Discover.pm line 186.
>>>>
>>>> Any hints on how to continue for this one?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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 ---
> I wonder whether reverse_sysname is taking the sysname of the device,
> looking that up in the DNS to get an IP, and using that for the device, but
> although the IP works, it somehow isn't a real L3 management IP on the box.
The odd thing is that we have a pair of these Arista switches in
the core of the data center and they feed all the top of rack
and middle of row switches. Only one of the core switches
is afflicted. How it assumes the IP address of a host sitting
out one of the top of row switches seems mysterious.
> If you delete the device and discover it again using the IP you want, does
> that work and does it "stick" ? If you set reverse_sysname to false, does
> the issue go away ?
Deleting and discovering always produced the same result.
However, setting reverse_sysname to false and deleting and
discovering fixed the issue. Does that offer any hints about
what might be causing this?
mark
--- End Message ---
--- Begin Message ---
Upon further investigation, it seems the above command is only valid for
DGS-3420-series(SC/TC/PC). On the DGS-3620-* , DES-3526, DES-3528 and
DGS-3426PC you cannot issue just the enable command, you have to specify
the IP address.
Also note, the IP address is not allowed to be the Loopback of said device,
it must be one of the other interfaces (System, crosslinks etc).
So an example which may feature in your docs?
Switches (only uplinks):
conf lldp po 25-26 mgt_addr ipv4 1.1.1.2 en
Routers (all ports)
conf lldp po 1-28 mgt_addr ipv4 1.1.1.1 en
Regards
Hans
On Mon, 14 Aug 2017 at 17:13 Oliver Gorwits <[email protected]> wrote:
>
> Thanks Hans, I have added a note to the Manual::Vendors page about this,
> for the next Netdisco release.
>
> regards,
> oliver.
>
> On 2017-08-14 15:16, Hans Erasmus wrote:
> > Hi guys
> >
> > New info:
> > Dlink has a funny way of displaying LLDP neigbours. For example:
> >
> > DGS-3420-28SC:admin#show lldp remote_ports 3
> > Command: show lldp remote_ports 3
> >
> > Port ID : 3
> >
> -------------------------------------------------------------------------------
> > Remote Entities Count : 1
> > Entity 1
> > Chassis ID Subtype : MAC
> > Address
> > Chassis ID :
> > 3C-1E-04-C2-D0-00
> > Port ID Subtype : MAC
> > Address
> > Port ID :
> > 3C-1E-04-C2-D1-18
> > Port Description : D-Link
> > DGS-3420-28TC R1.50.018
> >
> > Port 25 on Unit 1
> > System Name :
> > G23A Farmasie SW3
> > System Description : Gigabit
> > Ethernet Switch
> > System Capabilities :
> > Repeater, Bridge
> > Management Address Count : 0
> > Port PVID : 0
> > PPVID Entries Count : 0
> > VLAN Name Entries Count : 0
> > Protocol ID Entries Count : 0
> > MAC/PHY Configuration/Status : (See Detail)
> > Power Via MDI :
> > (None)
> > Link Aggregation : (See
> > Detail)
> > Maximum Frame Size : 1536
> > Unknown TLVs Count : 0
> >
> >
> > Note the difference in MAC addresses between Chassis ID and Port ID. I
> > have always known this to be funny, but up until the point where it
> > actually interfered with what I wanted to accomplish, I never bothered
> > to try and fix it. So, basically netdisco discovers a MAC address that
> > it has no ARP entry for, and stops the discovery process.
> >
> > The fix?
> >
> > Running the following command on a DGS-3420-28-SC Router:
> > config lldp ports 1-28 mgt_addr ipv4 enable
> >
> > And running the following command on the downlink switch connected to
> > the router:
> > config lldp ports 25-28 mgt_addr ipv4 enable
> >
> > Now, netdisco is able to discover the switch after discovery of the
> > router, and the same with crosslinks to other routers as well.
> >
> > If you run the show command again (on a port which has been fixed) you
> > get this:
> >
> > DGS-3420-28SC:admin#show lldp remote_ports 1
> > Command: show lldp remote_ports 1
> >
> > Port ID : 1
> >
> -------------------------------------------------------------------------------
> > Remote Entities Count : 1
> > Entity 1
> > Chassis ID Subtype : MAC
> > Address
> > Chassis ID :
> > 3C-1E-04-BF-2A-00
> > Port ID Subtype : MAC
> > Address
> > Port ID :
> > 3C-1E-04-BF-2B-18
> > Port Description : D-Link
> > DGS-3420-28TC R1.50.018
> >
> > Port 25 on Unit 1
> > System Name :
> > G23A Farmasie SW1
> > System Description : Gigabit
> > Ethernet Switch
> > System Capabilities :
> > Repeater, Bridge
> > Management Address Count : 1
> > Port PVID : 0
> > PPVID Entries Count : 0
> > VLAN Name Entries Count : 0
> > Protocol ID Entries Count : 0
> > MAC/PHY Configuration/Status : (See Detail)
> > Power Via MDI :
> > (None)
> > Link Aggregation : (See
> > Detail)
> > Maximum Frame Size : 1536
> > Unknown TLVs Count : 0
> >
> >
> > Note the Management Address count. This returns an ipv4 address
> > through discovery processes and netdisco is able to dynamically
> > discover switches through routers and "plot" the network as expected.
> >
> > I will report back with other devices as soon as I can.
> >
> > Regards
> > Hans
> >
> > On Mon, 14 Aug 2017 at 12:35 Hans Erasmus <[email protected]>
> > wrote:
> >
> >> Hi Oliver
> >>
> >> Again, thanks for the very quick response. It seems that the
> >> auto-discovery only works on some of the devices, and I need to
> >> investigate further, but preliminary findings show it may be down
> >> to only specific routers on specific FW version. Is this possible?
> >> For instance, I know for a fact that I have enable LLDP on the
> >> uplink port of the switches which connect to the router, so in my
> >> mind netdisco should discover the router, find the switch IP, and
> >> because LLDP is enabled, query the switch as well. Is this
> >> assumption correct? It is only after querying the switch that it
> >> should stop, as there are only nodes connected to it.
> >>
> >> I will report back if this is Firmware related or not. Thanks again
> >> for the trouble!
> >>
> >> Hans
> >>
> >> On Mon, 14 Aug 2017 at 11:59 Oliver Gorwits <[email protected]> wrote:
> >>
> >>> Hi Hans,
> >>>
> >>> On 2017-08-14 07:40, Hans Erasmus wrote:
> >>>> I am now quering these Dlinks, some are routers and some only
> >>>> switches. But it seems like I have to manually input every
> >>> single
> >>>> device to be discovered manually? Let me try and make it
> >>> clearer:
> >>>
> >>> The first thing to read and understand is this FAQ here:
> >>>
> >>>
> >>
> >
> https://metacpan.org/pod/distribution/App-Netdisco/lib/App/Netdisco/Manual/Troubleshooting.pod#Understanding-Nodes-and-Devices
> >>> [1]
> >>>
> >>> To automatically discover a network, Netdisco relies on "layer 2
> >>> discovery protocols" running between devices (LLDP, CDP, etc). It
> >>> looks
> >>> like Layer3::DLink already supports LLDP, so once the protocol is
> >>> enabled on your devices things should work.
> >>>
> >>> However that is layer 2 only. For WAN links there is currently no
> >>> auto
> >>> discovery (although it is being discussed). In the meantime, if
> >>> your
> >>> devices all have management IPs in a known IP prefix or subnet,
> >>> then you
> >>> can enter that on your Netdisco Web homepage and Netdisco will
> >>> scan all
> >>> IPs for devices.
> >>>
> >>> I hope these points help,
> >>>
> >>> regards,
> >>> oliver.
> >>>
> >>>> Topology:
> >>>>
> >>>
> >>>>
> >>>
> >>>> USR-Backbone1 <----------------------->USR-Backbone2
> >>>>
> >>>
> >>>>
> >>>
> >>>> Uplink1 |
> >>>
> >>>> | Uplink 2
> >>>>
> >>>
> >>>>
> >>>
> >>>> ------------------> Router A
> >>> <---------------
> >>>>
> >>>
> >>>>
> >>>
> >>>> | |
> >>>
> >>>> | |
> >>>>
> >>>
> >>>>
> >>>
> >>>> Switch 1 Switch 2 Switch X
> >>> Switch
> >>>> Y
> >>>>
> >>>> So atm I am able to enter the IP of Router A, and it will
> >>> discover
> >>>> that it is connected to at least one of the USR-Backbones.
> >>> Then, when
> >>>> I drill down in the device details and click on the "ports"
> >>> tab, I am
> >>>> able to then again click on port 1 and see what the IP of the
> >>> device
> >>>> is connected to it. And this is great, but I was wondering if
> >>> it is
> >>>> possible for netdisco to do this automatically? So basically,
> >>> if you
> >>>> take the topology above, I want to be able to get all details
> >>> of all
> >>>> devices from the USR-backbones right down to the switch feeding
> >>> the
> >>>> end user, and all this dynamically/automatically. These devices
> >>> should
> >>>> all be added to the inventory list automatically as well. Is
> >>> this
> >>>> possible, and am I doing something wrong that this is not
> >>> happening
> >>>> when I invoke "discover all" from the web interface?
> >>>>
> >>>> Sorry for the confusing post!
> >>>>
> >>>> Regards
> >>>> Hans
> >>>>
> >>>
> >>
> >
> ------------------------------------------------------------------------------
> >>>> Check out the vibrant tech community on one of the world's most
> >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot [2]
> >>>>
> >>>> _______________________________________________
> >>>> Netdisco mailing list
> >>>> [email protected]
> >>>> https://lists.sourceforge.net/lists/listinfo/netdisco-users [3]
> >>>
> >>>
> >>
> >
> ------------------------------------------------------------------------------
> >>> Check out the vibrant tech community on one of the world's most
> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot [2]
> >>> _______________________________________________
> >>> Netdisco mailing list
> >>> [email protected]
> >>> https://lists.sourceforge.net/lists/listinfo/netdisco-users [3]
> >
> >
> > Links:
> > ------
> > [1]
> >
> https://metacpan.org/pod/distribution/App-Netdisco/lib/App/Netdisco/Manual/Troubleshooting.pod#Understanding-Nodes-and-Devices
> > [2] http://sdm.link/slashdot
> > [3] 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 ---
------------------------------------------------------------------------------
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
