1 Reply Latest reply on Mar 27, 2018 1:56 PM by rschroeder

    How can I create a report that shows the actual total throughput of a switch, router, or firewall?

    bmallon

      I'm looking to create a report (or even a widget) that will show my how much actual throughput (bandwidth) a device is sending through it. I'm looking for the report to be able to look at switches, routers, and firewalls. We need to be able to measure how much data is passing through any given device.

      Again, to be clear, I don't need to know how much it's capable of sending through it, but how much is ACTUALLY going through it. This means we would have to add the throughput of all ports together, both transmit and receive, instead of looking at just one interface at a time.

       

      A report would be nice, but a widget with maybe a gauge or something showing the current throughput at any given time would be super cool.

       

      Anyone ever done this, or know how to set this up? Any help here would be greatly appreciated.

       

      I have the following:

      Orion 2017.3.4 SP4

      NPM 12.2

      NCM 7.7

      IPAM 4.6.0

      VMAN 8.1.0

      NetPath 1.1.2

      UDT 3.3.0

      DPAIM 11.1.0

      QoE 2.4

      CloudMonitoring 1.1.0

      SAM 6.5.0

        • Re: How can I create a report that shows the actual total throughput of a switch, router, or firewall?
          rschroeder

          If you're using firewalls, routers, and Layer 3 switches that support NetFlow, there's a Resource to add to any view that is called Total Transferred Packets.  Once added, you should be able to open it up far enough to see your specific L3 device and determine how many packets pass through it per time period.  You should also be able to add this to every NPM view for those types of devices, so that it shows up each time you open that node in NPM.  Better still, you can drill deeper in and see which devices' conversations are comprising that total data, if you wish.

           

          Your challenge grows if you are looking at strictly Layer 2 switches, and your ability to know the details of their internal East-West data declines dramatically.  The exception is newer switches like Cisco's 4510 Version 8 chassis, which can perform NetFlow natively on all 392 switchports without requiring the data to pass through a Layer 3 gateway.

           

          For the Layer 2 Only devices, you need something that takes a snapshot in time of all ports' total ingress and egress data.  It needs some extra features to be useful:

          1. It must either:
            1. Clear all counters regularly, or at least on command, so you have a zero-point from which to start, or
            2. It must be smart enough to log historical data in a Data Warehouse, reference it to see what the counters' numbers were at previously, then subtract that count from when you begin your new poll.  Otherwise you'd only have a cumulative / growing number, and you'd have to do the math manually every time you wanted to see what the total throughput of all ports was for the last five minutes or hour or day.
          2. It must also:
            1. Access the interface ingress and egress counts for every switchport and summarize their throughput count data and display it as an aggregate for the entire device at a specified instant in time.
            2. Give you some option for setting a time frame.  Maybe you want this on demand, maybe you want it for every hour, or every minute.  If on demand, there must be an ability to zero the counts before starting, or it must compare to previous counts. 

           

           

          There's a Widget called "Total Bytes Transferred" that can be added to Node's page.  You'll likely have to adjust it to enable it to cover all interfaces, since by default it's probably smaller, like 40 or less.  I added it to a switch's page in NPM, set the ports to 392 (a stack of 3850's can have 468 ports).  It's a real resource-buster, counting all the ingress and egress bytes across ALL ports, and it REALLY slows down the load time for the NPM page.  I mean by several minutes before you can see the Widget displayed.  Depending on how busy and big your network is, it may hang your NPM completely (once you add the Widget to a node's view, it goes into all similar views).

           

          Check it out if you can afford the wait time for the page, but I recommend you do it in a Test NPM environment first to see if it's what you want, and if it slows your page loading more than you can tolerate.