Port count - misleading

Matt,

You are correct, there are some issues with the utilization based on the interface types we collect. In the next version, we will tighten this up a bit and make it easy to modify. In the meantime, here is some information that should help you.

• ethernetCsmacd(6),
• propPointToPointSerial(22),
• ppp(23),
• propVirtual(53),
• propMultiplexor(54),
• fibreChannel(56),
• fastEther(62),
• fastEtherFX(69),
• channel(70),
• gigabitEthernet(117),
• hdlc(118),
• l2vlan(135),
• l3ipvlan(136),
• pos(171)

Thanks Mav!

That works great on a newly added nodes after the modification.

Will I have to delete and re-add any exisiting devices for this to work or will it retrospectivly delete them? (probably not but just worth checking)

It is good to know we can fix this issue with a workaround solution. But we should able to remove not only interface types but any port/interface (VLAN, PortChannel, fa0/1 etc.) we want. Also even if we remove the interface we should see the ip addresses, mac adresses of that interface when we search for an IP or MAC address. I have used ManageEngine OpUtils. It has a similar feature. It is a bit time consuming to discard interfaces (VLANS, Port Channels etc.) but it definitely gives us the accurate port(user) capacity for the device. My suggestion is take a good look at OpUtils. It is one of the best. It's main disadvantage not as stable as SolarWinds products. That's why we decide to work with SolarWinds. Also ManageEngine developers are so quick with feature requests unlike SolarWinds developers.

Our licensing is based on monitored ports. If you are not monitoring a port, we will not show you information about what is connected to it (that would defeat the purpose of our licensing model).

I can say we will continue to iron out these few issue so that UDT behaves as you would expect. The items we have planned should have a big impact on these nuisances.

I would put SolarWinds developers against any other companies developers any day of the week. We have a large customer base and need to be careful about just shipping code that hasn't been reviewed and thoroughly tested. This is why our products are more stable. We can always do a better job, but I hope you agree the extra time is worth it. Also, SolarWinds maintains one of the highest release tempos of software development companies. We release often across a wide variety of product lines.

Thanks for the feedback!

Mav

Did this ever get resolved in the most recent version? It's 2014 and I am still seeing the same issues with 3.2

at some version It deletes existing ports & the associated data immediately when you modified the list. I'm not going to try that again because it immediately delets all the history.

What is it with solarwinds and deleting data from the database?

on Juniper switches the bridge data is associated with the virtual (unit) interfaces (type53), whereas on other manufacturers switches they are associated with the physical port (type 6)

So this isn't a viable solution in a mixed environment.

Agreed, we just built out a new Orion install and this issue still seems to exist.  VLANS are being counted in port usage.

nope - still behaves this way by default.  There should be a configuration setting in the admin interface (or anywhere else) where we can TELL UDT what to "count" as a port. VLANS SHOULD NEVER BE COUNTED AS A PORT IN UDT.. you cant plug a cable into a VLAN, you plug a cable into a PORT.