On 3/20/23 09:43, Mike Hammett wrote:
But then I'm storing and processing twice as much data as I need.




I would say somewhere between 0 - 100% overhead.  Depending upon traffic. 

Recall that a flow is packet delivery in one direction only.  An end to end flow is an ingress interface with various l2 decorations along with an egress interface with its various l2 decorations (which many flavours of sflow will report).  So you need to record flows in both directions - from point of entry to point of exit.  In Cisco when I have the ability to turn on ingress and/or egress.  I turn on both so I can record this detail.

To fully record traffic, you need this in both directions.  And recall, multihome means that traffic delivery may be asymmetrical across interfaces.  So diagnostics will require this full flow info in both directions.

And as the disparaged marketing material indicating that a 1G interface carries 2G worth of traffic, it isn't a lie.

All this to say that no, you aren't processing twice as much data as you need.  You need all that, in both directions, to properly generate additional detail reports.



From: "Raymond Burkholder" <ray@oneunified.net>
To: nanog@nanog.org
Sent: Monday, March 20, 2023 10:16:37 AM
Subject: Re: Cisco Nexus Odd sFlow Implementation


On 3/20/23 08:55, Mike Hammett wrote:
Cisco is sending the in and out packets in their sFlow implementation on their Nexus switches. Obviously, this double counts the information.

Are there solutions that process those flows and remove one of those directions?

Wouldn't you just do that in your reporting?  The report engine usually has options for interface, ingress/egress, prefix range, protocol, ....

Then when you need to aggregate for a specific interface for additional troubleshooting, you have all the information for when you need it.

Yes, your aggregate numbers for total packets transiting is double, but I generally have specific reports for specific traffic patterns I focus on anyway.

Raymond Burkholder
One Unified Net Limited