Howdy fellow networking of us,
I am presently making an attempt to construct a small monitoring resolution for multicasts. In our lab we’ve a Nexus9000 C93108TC-EX operating model 7.0. I need to begin with this gadget and perhaps later proceed supporting others. The objective is to see for every interface: “Which multicasts are coming into and that are leaving.”
Sflow appears to be a viable resolution for this downside because it “simply” samples an outlined subset of all of the packets passing by the monitored interfaces. For every sampled packets Sflow supplies some further info. For me the Supply ID index and the Enter interface worth are most fascinating. I’m sticking to the sector descriptions offered by Wireshark since completely different sources consult with them in another way.
When a packets arrives from outdoors the change on one monitored interface, all the things works flawlessly. I can evaluate the 2 values to the values within the MIB-II interface description. Each values match as they need to.
When a packets is leaving the change the story goes in another way. The Enter interface worth is right so I can nonetheless see, on which bodily interface a packet entered the change. Supply ID index at all times shows hex 0x80000000. It ought to present the interface I’m monitoring proper now, the interface from wich the packet was sampled.
If the state of affairs stays like that I can solely correctly monitor incoming multicasts however I can not monitor by which interfaces packets go away the change.
In my view the Cisco documentation just isn’t actually clear if this habits is predicted or not. For NX-OS 10.5 I discovered
sFlow does not assist egress sampling for multicast, broadcast, or unknown unicast packets.
However the NX-OS 7 documentation states:
Egress sFlow of multicast visitors requires {hardware} multicast global-tx-span configuration.
which I attempted. The opposite sentence in there drove me completely nuts:
For an ingress sFlow pattern of multicast packets, the out port is reported as a number of ports with the precise variety of egress ports. This isn’t supported on Cisco Nexus 9300-EX and -FX/P platform switches.
Like, what does this even imply? I’d interpret it as: “You may see what number of interfaces an incoming packet will go to, however not in your gadget”. However that ought to not have an effect on what I can see on the sampled egress packet, proper?
I assume that both I’m not sensible sufficient to learn the documentation appropriately or the documentation just isn’t coherent. So my query is: Is it potential to appropriately pattern the knowledge for egress multicast visitors with my change and in that case, what must be accomplished.
If it’s not potential I’m how properly different distributors assist sflow monitoring of multicast packet (particularly Arista). Is it solely Cisco implementing it weirdly or is there an even bigger purpose for this.
I am additionally fascinated about potential options for my implementation and should you assume they may very well be potential:
- Mix the snooping and group report with the enter knowledge (present ip igmp snooping teams). This may be potential however isn’t any true monitoring. I would not know when the change doesn’t go a packet.
- Cycle the sflow monitoring port. If I monitor just one port at a time I at all times know the place a one multicast enters and the place it leaves
- I have a look at another interface knowledge (counters or one thing comparable) if there are any correlations I can use to match output multicasts to interfaces not directly.
When you’ve got any concepts I might recognize your assist.