Multicast/Broadcast packets details missing

[Giovanni Pipitò]

Hi everybody,

I recently installed sFlowTrend (free version) and find it quite interesting for my company needs.

However I do not understand why multicast/broadcast frames details are not reported in the GUI.

Example:

Here is my Thresholds page reporting Critical Values for Multicast and Broadcast frames on a specific interface:

If I drill-down data in Root Cause page I am not able to see anything:

The same applies with broadcast frames.

Of course everything is working fine with Unicasts.

Is that normal behaviour or am I missing something?

Regards

[sgjohnston]

Hi Giovanni,

My guess is that on the root cause page, all of the possible entries are small and so not showing up because of the minimum weight setting (ie all possible entries are less than 5%). Can you try reducing the minimum weight setting (eg to the minimum, 1%) and see if anything shows up?

It's also worth noting that the threshold may be tripping just because it is set too low, not because you have an issue with multicasts - the initial settings for the thresholds are not necessarily relevant to any particular network.

regards,

Stuart

[Giovanni Pipitò]

Hi Stuart,

thanks for your suggestions.

I set the weight to 1% but it does not change much. I also realized that even with 5% set and after a very long wait, multicast data eventually show up. The problem is that the behaviour is quite inconsistent so I am neither able to replicate it properly.

Another thing that I'm confused about is the Top N section reporting only ingress traffic:

or reporting only egress traffic from interfaces that are not sflow enabled:

[sgjohnston]

Hi Giovanni,

It's probably best to understand what's happening with the basic charts first, then once that makes sense look at the root cause/thresholds. Your first chart, where you say it is only showing ingress traffic, the chart is actually showing all traffic. This is because you have all interfaces selected (ie all of the switch's traffic). In this case it doesn't really make sense to talk about ingress and egress, because virtually all of the traffic will transit the switch - whatever is ingress on one interface will be egress on another. So, when viewing all interfaces, sFlowTrend will just present overall traffic.

For interfaces that do not have sFlow enabled, what can be displayed depends on the capabilities of the switch - primarily, when the switch takes a sample on interfaces that are enabled - on ingress traffic, egress traffic, or both - and whether the switch is able to include both the ingress and egress interface on traffic. The ingress vs egress sampling is sometimes configurable in the switch, with other switches it can't be changed. With the chart you are seeing, I suspect that the switch is only doing ingress sampling, and it is able to provide the egress interface on these samples. So you see traffic egressing these non-monitored interfaces, but not in the other direction.

I would strongly recommend that you enable sFlow on all of the interfaces on the switch. This allows sFlowTrend to build a more complete view of all of the traffic. It will likely also help with multicast traffic.

regards,

Stuart

[Giovanni Pipitò]

Hi Stuart,

thanks again for your reply.

Actually the graphs reporting only ingress or egress traffic also applies to the interfaces that are sflow enabled:

and that happens despite the fact the interface counters are reporting both ingress and egress traffic as expected:

I also don't understand why Counters and Top N are reporting different values (800M vs 500M ingress traffic).

I checked sflow config on my switches and there is no way to set ingress or egress specifically.

About your suggestion to enable all interfaces: shouldn't that cause traffic to be reported twice?

[Giovanni Pipitò]

Correction:

Actually SLX-OS Documentation says packets are only sampled once:

In port based sFlow, the sampling entity performs sampling on all flows originating from or destined to a specific port. Each packet is considered only once for sampling, irrespective of the number of ports it is forwarded to. Port based sFlow uses the port level sampling rate, if it is configured. Otherwise, it uses the global sampling rate. When port level sampling rate is unconfigured with 'no' option, it will revert back to using the global sampling rate.

Extreme SLX-OS Monitoring Configuration Guide, 20.1.1 (extremenetworks.com)

So I'll definitely enable sflow on all ports.

[sgjohnston]

Hi Giovanni,

The counters will report both ingress and egress, since they are collected and generated differently - they basically reflect SNMP counters. The flows should be close to the same values, although there will potentially be a little difference because of sampling error.

Let's assume your switch is doing egress sampling. It will be able to report data for all egress interfaces which have sFlow enabled, and this should be accurate. However, ingress packets on each interface will never be sampled (by definition); instead, we rely on egress samples on all other interfaces, each of which also report the ingress interface, to build up the ingress traffic. If all ports are not enabled, then this will be an incomplete picture.

sFlowTrend will de-duplicate data, so it shouldn't be double counted.

Thinking more about your root cause problem with thresholds - thresholds are tripped only from counters, so if multicast counters are over the threshold then it will trip. The root cause, however, is generated from the flow data. This may be incomplete for two reasons: the above discussion on all ports being enabled, and secondly the nature of multicast traffic, which is not always sampled very well by switches, in particularly reporting which interfaces the traffic will flow on. You may find the missing multicast traffic on the switch in the "unknown" interface. Unfortunately, the root cause analysis will not work in this case, but you can still view the traffic in top-n.

regards,

Stuart