How to see devices connected to a switch?

I've used various tools to accomplish this--but most likely only because I don't have UDT.  If you've got it, you're ahead of me.

Here's my tedious process for discovering the devices on a switch's ports, without UDT:

1. Use Ping Sweep ping all ranges of addresses on all VLAN's on the switch in question.

2. Use Switch Port Mapper to poll the L2 switch and its L3 interface (or the router for the subnets involved).

Item 1 produces a nice list of devices and network names for handy reference, but requires those devices to be registered in DNS for them to show up with network names here.

Item 2 produces a .csv or Excel spreadsheet that has a wealth of useful knowledge, including blade/port, port name, port status, device MAC address of whatever is attached to the ports, device IP address of the devices attached to a port, and more.

An example:

I'll be interested to see the equivalent output from UDT if someone can share it.

Swift Packets!

Rick s.

You are correct sir that UDT should be doing this for you.  If you look at a "Node Details" page, and go to "Port Details" for that node, it will show you a list of ports that are managed by UDT for that node.   Click on one of the ports, like Gi0/11, and it should bring up a "Device Tracker Port Details" page, with one column being "Port History", like below.  Note if you don't have IPAM, you won't get that part of it.

If you aren't getting this, the first question I would have would be are the ports managed with UDT, which it being in the "Port Details" section of the "Node Details" should answer that.  If you're just getting MAC addresses and not IP's, you will probably need to monitor the Layer-3 device controlling the LAN the device is on, that way it can read the ARP table and relate the MACs to IPs.

If not, you might check your "UDT Settings", make sure there are reasonable polling intervals for the various devices.     Maybe reset the polling intervals using the buttons in there.

Check the "UDT Job Status" and make sure its polling the device you're looking at.  It will tell you the last run and next run there.

Check the "Retention" settings, make sure your history retention is set long enough for what you want the history to show.

In "Advanced" settings make sure you have the right "Monitored  Port Types".    Definitely anything with "Ether" in it (fastEther, gigabitEthernet, ethernet-csmacd) and probably the l3ipvlan, propvirtual and l2vlan at least.  If you're not sure, just use the "reselect defaults" and that will probably give a decent selection.

You might also want to check on the devices themselves and make sure you don't have any "snmp-server view restricted" that would interfere with SNMP discovering the MAC addresses or arp tables.   Make sure the device is polling correctly for other statistics...

That's pretty much all I can think of right now, there are a LOT of moving parts in UDT and you need to make sure they're all working, notice I didn't even go in to AD integration, which without that you won't get the user that was logged on to the device!  Lots of stuff...

Thank you both for the reply!

Craig,

I went through your list and most things seem to be checking out. Quick question regarding snmp-server traps. We are using SNMP V3. Is there a mib family view that will catch all this required information? As I understand it, the default views will strip out ARP and IP routing tables because of the increased load and spikes that occur when monitoring those. Is this still the case with IOS 15 and on? Other than the specific mib view, I will check on AD integration, however, I am seeing users log into individual machines but there is no port history associated with those. More specifically, I don't see anything on the port except that it's either on or shutdown.

This is a port that has been monitored for a couple days, however, as you can see there is no additional information about the port.

I'll continue to tinker with it!

Well, just like you have have a restricted view in SNMP, you can also permit access to specific MIBS.   Now, I know this isn't perfect with SNMPv3, like if you want to get cbqos info in NTA you can't do it with SNMPv3 (at least AFAIK).  But the general format is:

snmp-server view <viewname> <oid-tree> (included|excluded)

You'd need to assign this view to your snmp-server group also.   Now what is the oid-tree to add?   I believe its the "internet", or more specificially the "ifTable" for MAC addresses (1.3.6.1.2.1.2.2) and the ipAddrTable for ARP on router (1.3.6.1.2.1.4.20).   I could be wrong on this, you can figure it out for sure by enabling SNMP debugs on the device when its doing the discovery, or maybe packet capturing.

With SNMPv3 you also have to add the context for each VLAN on a switch to allow it to work.   Something like this:

snmp-server group MyGroup v3 priv context Vlan-XX read myview

So, if you have 100 vlans, you'd have to put 100 of these statements in that switch!!

The Solarwinds Engineers Toolkit SNMP tools like the MIB browser would probably help quite a bit with figuring this out too.

Would love to know what your final results are, both for your configs and whether it works well!!

Craig, would you mind speaking to this point a little more?

If you aren't getting this, the first question I would have would be are the ports managed with UDT, which it being in the "Port Details" section of the "Node Details" should answer that.  If you're just getting MAC addresses and not IP's, you will probably need to monitor the Layer-3 device controlling the LAN the device is on, that way it can read the ARP table and relate the MACs to IPs.

Take the scenario of a network with one switch and one router, with some tagged vlans to separate clients.  The L3 device for the subnets attached to these vlans is the router, and the switch is just passing L2 stuff.  Are you saying you'd have to monitor both the ports on the switch with UDT, as well as monitoring the router with UDT?  It makes sense to me that the router would be the only device that would have the full arp table for all the devices in this scenario, I just wanted to confirm.

Correct, I was having that problem and inquired with Solarwinds and they confirmed that the router for any given VLAN has to be managed with UDT also. You don't have to manage any ports on the device, just the device itself (at least from my experience!!).  That way UDT gains access to the ARP table on that device.

You also don't need to monitor uplink ports if you don't want, that can actually confuse the output in UDT a bit when it registers that a user is not only on the port their on, but all the uplink ports leading to it.   Which actually makes sense, UDT is really just joining information it gets from multiple sources.  ie: the SNMP equivalents of the following commands I'm thinking -

show arp

show mac address-table

DNS lookups

Active Directory info.

Along with a bit more info on the ports and such (vlan, speed, duplex, etc)...

If you don't have the router included for ARP table lookups, you might only get MAC info for the port and nothing else, etc. etc...

Craig,

Thanks again for the comment! I recently got through a pile of other work and came back to this and was stumped. In the end, it was the VLAN context that made all the difference. Once I added the context for the correct VLANS to the SNMPv3 group, everything worked!

Quick question regarding uplink ports. In effect, this would be the same as distribution switches that only link fiber from other switches, correct? If so, there shouldn't be a need to monitor all the ports on switches that simply connect other switches in other buildings if my thinking is correct.

Thoughts?

Not unless you want to see that.   Some people might find it interesting that the user is seen on both g1/0/14 of and end-user switch and g1/0/10 of the distribution switch.  I personally don't, so I wouldn't monitor switches that were strictly for distribution.

On the other hand, if you wanted to conserve licensing for lets say and you have LOTS of end-user ports.  If just finding out what switch they're connected to is good enough, and not what exact port their on, you could only monitor the distribution switch and not the end user switch.    That way you'd see they were on g1/0/10, of which the port description says its connected to a specific switch and you'd know they were on that specific switch.   Of course if you had stacks of switches that were connected via uplinks this wouldn't be overly useful.

So, it really depends on what info you want as to how you do it.  But, I would agree with your thinking and only do the end-user switches myself!!