Juniper switch port usage trending R2NNTG
R2NNTG My group supports several hundred switches across all of our buildings and locations, but we don't always receive reliable or timely information about events that change the local density of wired connectivity needed to support constituents and their various devices. This frequently results in a significant amount of wasted switch port capacity and wasted electricity when a specific location is vacated or its use changed and we are not told, leaving a 48-port switch where 24 ports or less would be sufficient for example (worst of all is the scenario where we purchase additional switch hardware to support growth or expansion in a location while under-utilized switch hardware needlessly burns power and annual maintenance $ elsewhere. The referenced datasource here is expected to help this situation. It is not a switch-by-switch, port-by-port uptime measurement, rather it shows the percentage of ports with link (ie in use) over a range of time. Its value is expected to come from providing a longer-term trend of ports in use for specific locations by highlighting those locations where switches can be removed due to persistent over-capacity, but it can certainly be effective tracking use-cases with shorter term periods as well. It is extremely well-suited to presentation on a dashboard. Note that this datasource was built for Juniper switches [and includes specific interface filtering so you will need to adjust that (along with Applies To and any thresholds) to meet your needs] but it is most likely not difficult to substitute other vendors' MIB/OID into it. Much thanks to Josh L on the pro-services team who did all the real development work. R2NNTG2Views0likes0CommentsJuniper Switch HW Info
Name: Name: Juniper Virtual Chassis_lmsupport Display Name: Displayed As: Juniper Virtual Chassis_HW Info Locator Code: YWWE74 I modified (actually, I had help from Support) the datasource Juniper Virtual Chassis- so that values that originally were displayed in the UI as only descriptive text on per-instance mouse-overs are now presented as properties. Juniper switches present difficulty to the datasource Device_Component_Inventory; this modification allows a single-step way to associate with stand alone switches and virtual chassis while getting inventory data on a per-member basis instead of on just whichever switch happens to be the virtual chassis routing-engine at the time of polling. And it comes with the huge bonus that using ILP as the instance grouping method produces a great presentation in the UI. It collects from jnxVirtualChassisMemberEntry (there are other values there that may be of interest to you, so walk it) for each member of a virtual chassis, but it does require that you enter any specific info you would like to see into the command <set...member n location [any desirable text value]>. We chose to enter building and room location along with asset tag number and it is stored by the property auto.vcmemberassetinfo Also, you will need to configure even standalone switches as a virtual chassis <set...member 0 location [any desired value]> The Descriptive text in the original datasource is not reportable, but properties are, and this lets us create a great report using the Device Inventory report. It gives us device name building, room number and asset tag for each individual switch in a virtual chassis serial number for each individual switch in a virtual chassis HW model info for each individual switch in a virtual chassis junos version for each individual switch in a virtual chassis Special thanks to Support Engineer Johnny Y for doing most of the heavy lifting (after recognizing that I was trying to pound a screw in with a hammer), all the other Support Engineers who patiently answered my questions in a series of cases, and to CSM Kyle for kickstarting me.9Views0likes3Comments
