Combining flowdata from 2 interfaces

[Koen]

I've made a simple drawing of one of the ~15 locations which we're monitoring using Netflow v5 and Scrutinizer.



A typical office location consists of a core of two Cisco 6500 switches, connected to the access switches. The core switches are also both with one gigabit interface connected to the provider router.

Our main target is monitoring the utilisation of the WAN line. Since the CPE is managed by our provider, I've configured Netflow on the core switches for the interfaces to the CPE. This results in Scrutinizer getting flowdata from two interfaces per location.

Coreswitch 1, CPE interface inbound/outbound
Coreswitch 2, CPE interface inbound/outbound
_______________________________________ +
Total CPE inbound/outbound traffic

Is there someway to combine this data in Scrutinizer? At the moment I have to look at both interfaces to get the WAN line utilisation?

[mpatters]

Hello, Yes you can do it. From the status tab, run the report you want for an interface. Then Use the Device/Interface filter. Select the device then interface and click add.

[Koen]

Hello, Yes you can do it. From the status tab, run the report you want for an interface. Then Use the Device/Interface filter. Select the device then interface and click add.

Great, I've been playing with Scrutinizer a lot but it never occured to me that I could add another device using the add filter option

Is it also somehow possible to draw the combined utilisation as a connection in a map?

[mpatters]

please contact me directly. I will add this as a feature request.

[mpatters]

See attached example

[RaulD]

Hello Koen,

There are a few different ways that you can do this. In this case, since you know exactly what you are looking for, we can use the Report Wizard to quickly create the report.

Let’s start from the Status tab.

While viewing the status tab, click on the wizards link from the Device Explorer section in the right hand column.

1. Click on the “Add New Filter” drop down and select “Device/Interface”

2. Choose your device (coreswitch1 from your example).

3. Choose the interface of the device (Coreswitch1) that connects to the CPE

4. Click on the Plus symbol to add the device/interface.

Now it’s time to add the second link. But this time you don’t have to start from the wizard – Just add to the current report.

Once again click on “Add New Filter” Just repeat the steps above to add the second Device/Interface that connects to your CPE and you’ve got your report.

Once you have your report, you probably want to save it right?

To save the report, just type in the name of your report in the “Report: “ field, and click on the floppy disk symbol up on top to save your report.

Does this give you what you need?

Thanks,
Raul

[Koen]

Hello Koen,
<...>

Yes, a very clear addition to mpatters explanation. Ty

[Koen]

One addition though, say the mpls connection for a location is 34Mbit/s. I'm able to configure this limit static on the interface in Scrutinizer (manage exporters, choose exporter, edit custom bits in/out of specific interface). So now both interfaces to the CPE on the coreswitches are configured with 34Mb (instead of 1Gb port).

If I combine the flowdata as mentioned above, Scrutinizer will also combine the bits in/out (available bandwidth) of these interfaces (in this case it'll say available bandwidth is 68Mb). This makes viewing a graph with percentage (instead of bits/bytes/packets) useless, since he calculates the available bandwidth twice.

Configuring custom bits in/out at 17Mb on the interface is no option: both coreswitches have full access to the maximum available bandwidth (which is not 17Mb, but 34Mb). If I would configure this, this would result in Scrutinizer saying interfaces being utilised far over 100%.

[jghidoni]

If I combine the flowdata as mentioned above, Scrutinizer will also combine the bits in/out (available bandwidth) of these interfaces (in this case it'll say available bandwidth is 68Mb). This makes viewing a graph with percentage (instead of bits/bytes/packets) useless, since he calculates the available bandwidth twice.

That is not an issue, as Scrutinizer does not allow the reports to show in percent if multiple interfaces are selected. The percentage rate would be invalid, whether the bandwidths are identical or whether they are different per interface. The calculations would be far more intricate than just summing the total bandwidths/ sum of the total i/f utilizations.

You won't have the option of reporting by percent if you have selected more than one interface.

- Joanne

[Koen]

If I combine the flowdata as mentioned above, Scrutinizer will also combine the bits in/out (available bandwidth) of these interfaces (in this case it'll say available bandwidth is 68Mb). This makes viewing a graph with percentage (instead of bits/bytes/packets) useless, since he calculates the available bandwidth twice.

That is not an issue, as Scrutinizer does not allow the reports to show in percent if multiple interfaces are selected. The percentage rate would be invalid, whether the bandwidths are identical or whether they are different per interface. The calculations would be far more intricate than just summing the total bandwidths/ sum of the total i/f utilizations.

You won't have the option of reporting by percent if you have selected more than one interface.

- Joanne

Well actually I do

I agree it'll be a little intricate to analyse graphs with this result, however if you know what its about it's not ( ).

Look: as I've said we're generally interested in the utilisation of our WAN line. Utilisation is best presented in percentage, since we have different WAN lines and speeds. For the locations with a redundant core, I have two interfaces to look at to calculate the utilisation. This results in my wish to view traffic from two interfaces with a fixed bandwidth for the two of them by percentage.

[jghidoni]

Okay, my mistake. I didn't realize we were using the port speeds at all in multi-interface reports. I know now.

So here is what I learned:

The way it currently works is that if you select multiple interfaces for a report and all interfaces have a port speed defined, then Scrutinizer sums the port speeds and will display the total sum as the bandwidth available for that report.

If any of the interfaces does NOT have a port speed defined, then bandwidth will not be displayed for that report and the percent reporting option will not be available in the dropdown list.

So in your example, it looks like you have two interfaces of 34Mb/s each, for a total of 68Mb/s bandwidth available for this report.

You have peaks of 50% and 60% of the 68Mb/s, which is the aggregation of the 2 interfaces you have selected. The bandwidth used per interface is in no way weighted, it is just a simple summing of the values.

So now that we are agreed on that point, how is it that you would like to see it work? What bandwidth would you expect to see? An average, a sum, the minimum, or the maximum of the bandwidths per interface?

If you want the minimum, say, in this case 34Mb/s, and both interfaces were maxed out, then are you saying you would expect to see 200% utilization in the Scrutinizer graphs?

- Joanne

[Koen]

So in your example, it looks like you have two interfaces of 34Mb/s each, for a total of 68Mb/s bandwidth available for this report.

Yes, that is correct: two interfaces configured with 34Mb bandwidth, generating a report with the both of them displays 68Mb bandwidth.

You have peaks of 50% and 60% of the 68Mb/s, which is the aggregation of the 2 interfaces you have selected.

Well the peak of 60% utilisation (~41Mb/s) is not really there, since the WAN connection is 34 Mb/s. That you see this is probably the result of burst on the interface from the switch to the router.

The bandwidth used per interface is in no way weighted, it is just a simple summing of the values.

Correct

So now that we are agreed on that point, how is it that you would like to see it work? What bandwidth would you expect to see? An average, a sum, the minimum, or the maximum of the bandwidths per interface?

I don't think it's a question of what I would expect to see, since imo this is not really a bug. However for these two interface I would like to see a bandwidth of 34Mb/s, (even though both interfaces can reach 34Mb/s themselves).

If you want the minimum, say, in this case 34Mb/s, and both interfaces were maxed out, then are you saying you would expect to see 200% utilization in the Scrutinizer graphs?
- Joanne

Under heavy load you can indeed expect to see one or the two interfaces reach >100% utilisation for a short time because of a traffic burst on the interface (I don't think it'll hit 200% though).

Just to get it straight:
- WAN interface coreswitch 1 (X) can reach up to 34Mbit (if Y doesnt have any traffic)
- WAN interface coreswitch 2 (Y) can reach up to 34Mbit (if X doesnt have any traffic)
- Utilisation of X and Y (the sum) respresent all the traffic on the WAN line.
- Interfaces from the coreswitches to the CPE router (X and Y) is gigabit, the bottleneck is the actual WAN line on the router (34Mb). Coreswitch 1 and 2 have to share this capacity, both having the ability to use it for 100% if the other coreswitch isnt using any capacity.

So what I want is a report with the aggregation of X and Y, with a displayed bandwidth of 34Mbit, in percentage. This way I can generate a nice graph of the utilisation of the WAN line.

[pauld]

Hello Koen,

Have you asked your router provider if they can turn NetFlow on for the WAN interface on their router and send flows to your Scrutinizer server?

We have quite a few customers who do this and it would give you the exact report you're looking for.

Thanks,
Paul

[Koen]

Hello Koen,

Have you asked your router provider if they can turn NetFlow on for the WAN interface on their router and send flows to your Scrutinizer server?

We have quite a few customers who do this and it would give you the exact report you're looking for.

Thanks,
Paul

Hi Paul,

I'm aware of this possibility, and yes: this would get me what I'm looking for. However having our provider configuring this, taking it they would be willing to do so, would take extra time (you know: ITIL change management;)) and money.

[pauld]

Hi Koen,

I'm opening a feature request with development on this and I'll contact you directly to follow up.

Thanks,
Paul