This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

How to create a report displaying the Last Time Data was Transmitted or Received on a Switch Port

First off, there's a great thread with XML language that creates a new Report for this that can be imported into your SW here:  How to find ports which have not been used for a long time ?

Also, check this search out for other threads containing "Last  & Transmitted":  https://thwack.solarwinds.com/search.jspa?q=last+transmitted

I built this process my team's use, since the above XML report provided information for too many kinds of ports and systems.  The method I use allows you to focus on a specific switch, and it filters out ports that I know will always be out of scope for discovering patched copper ports for reuse (like fiber uplink ports and port-channels or local Fa0 ports).

Start off in Settings, Admin > Alerts & Reports, Create New Report

pastedImage_1.png

Click the small blue "Edit" just to the right of Datasource 1 and make it look like this:

pastedImage_3.png

Adjust the items above to match your specific needs and then click Add to Layout.

What the filtered options mean:

  • The first entry (Caption contains "Insert Switch Name") lets you focus solely on a specific switch.  You don't have to include this if you don't want, and you could change it to identify a switch by whatever method you prefer--or drop it entirely.
  • Solarwinds NPM may discover Cisco interfaces that are "Controlled" and "Uncontrolled" for security options (depending on IOS release and hardware platform); since these interfaces are duplicates to the physical interfaces, I don't want them included in the report, so I had it filter any interface with "ontrol" in its name.
  • I'm not interested in Port-channels, therefore they're filtered out.
  • I don't want any port whose status is "Up" since I'm only looking for ports not in use.
  • It must be a Physical Interface, not a virtual or logical one.
  • Don't report on Ten Gig interfaces ("Interface Name does not start with Te") because we don't let users plug into those sports. 
  • Don't report on interfaces ending in 49-52--those are uplink fiber links on my switches, and I'm not looking for information about those in this report.  I only want to know about copper ports that can be unpatched & reused.
  • Don't report on the Fa0 port if one is present

Click Edit Table

pastedImage_0.png

Adjust these items per your specific needs and click Submit

I put a note it to remind my Team to change the switch name inside the report:

pastedImage_13.png

Click Next

pastedImage_1.png

Put helpful information in the Report Description, Click Next.

Schedule if it needed.  We run this report on demand instead of at regular intervals.

pastedImage_15.png

Click Next

Review the setup and make any changes required:

pastedImage_2.png

Click Submit.

Now select the report, edit it to report on the specific switch, save it and run it. You'll get a report that sorts from the ports longest down to those most recently down, looking like this:

pastedImage_0.png

I export this to .PDF and send it to my Network Technicians for unpatching of ports on switches they're concerned with.

Enjoy!

(Reviewed and updated 20200207.  This process still works in Platform 2019.4 HF3 Rick Schroeder)

  • This process still works with the current versions of Orion modules we're using (Rick Schroeder, 9/5/2016).

  • Nice how to.  Very useful for back checking that an un-used port is unpatched and VLAN bit-bucket.

  • Great walkthrough, very detailed thanks.

    I do have a problem where I've been unable to locate 'Physical Interface' which is a bit of an issue for sorting.

    Any thoughts?

  • I think you need to be monitoring all the physical ports on a switch before you can generate this report and get useful information.  For example, some folks don't buy licenses large enough to cover all their ports--they only manage/monitor uplink ports off of access switches.  This prevents you from being able to get the data necessary to properly support users of switch ports proactively.

    First, select all ports on a switch to be managed by NPM.  Then you should be able to filter them with the settings below:

    pastedImage_0.png

    If this doesn't address what you need, please send some screen shots showing the goal and the challenge.

  • Thanks for the rapid response rschroeder​ however my issues seems to be the fact that the 'Physical Interface' option to choose when adding a column isn't in my list of choices, either under 'Interface' or under 'Node'.

    Am i looking in the wrong place?

    pastedImage_0.png

  • Hi steve.cabot​,

    I think you're close to the right area, just not zeroed in.

    You've set your Orion Object dropdown to "Interface", but it needs to be "Node":

    pastedImage_0.png

    Setting it to Node and then searching for "Physical" should give you "Physical Interface" as one of your options:

    pastedImage_1.png

    Swift Packets!

    Rick Schroeder

  • rschroeder

    I like this report, but I am still kind of perplexed on why such a report is offered in Kiwi CatTools and is not integrated with Orion NCM or NPM. I believe your report requires me to monitor every switch interface, which we do not have licensed.

    Kiwi Cat Tools has a great report called Report.X-Ref.Port MAC ARP. This report combines two separate jobs: Report.mac address-table and Report.arp table, and then creates a combined spread sheet that tells me what device/IP Address/MAC is plugged into a switch and its port. I use this report at least twice a week to help troubleshoot ports, MAC addresses, IP locations, etc....

    I created an idea for it last week to see if we can get it included in NCM.

    I'd like your thoughts on if it is possible to create such a report in NCM/NPM. Thanks.

  • In my case, we don't own Kiwi Cat Tools.  Hence my request to include this within a product we already own.

    Sadly, this same functionality used to be included with NCM, back in 7.2.  SW told me it was intentionally removed, and they planned for it to be included in UDT--which I don't have.  So I built this report and process--which is only a kluge, and too manual for my preferences.  But it serves a good purpose for me, and we do manage/monitor all switch ports.

    We needed to monitor every port to ensure we can proactively assist users who may be experiencing simple problems like speed/duplex mismatches, or other conditions that may cause high number of discards or errors.

    It took four pollers and four NPM Unlimited licenses, but it's the right fit for a hospital environment.

    Monitoring every port doesn't come for free, but it DOES give us a list of the ports with the highest number of errors & discards in real time, which I post to the front page of our NPM instance.  And that provides a great to-do list of ways to clean up the worst L1 problems first.

  • I have the same issue when trying to create this report. no physical interface and I'm monitoring all the interface on the switch.

    NPM 12.1

    pastedImage_0.png

  • I'm not sure why your options don't offer the ability to add a column for the Physical Interface.  Perhaps it's because I created this with a slightly older version of NPM, but I doubt it.  I trust SW to not remove that functionality.

    Instead, let's double-check your process from Step 1 of building a new Report.  If you inadvertently deviated from my process above, you might have selected something other than adding a Custom Table to the Report.  If so, that might limit your options.

    When you clicked Add Report to build a new NPM Report, did you add a Custom Chart instead of a Custom Table?  The Custom Table is required; the Custom Chart won't do the trick.

    pastedImage_0.png

    Hopefully that was the spot that sent you down the path where there's no option for adding a Physical Interface column, and that the difference between my report and your is NOT caused by you running a newer version of NPM.