The sFlow standard consists of an sFlow agent that resides anywhere within the path of the packet and an sFlow collector that resides on a central server. This release is compliant with sFlow Version 5.
The sFlow agent combines the flow samples and interface counters into sFlow datagrams and forwards them to the sFlow Collector at regular intervals. The datagrams consist of information on, but not limited to, packet header, ingress interfaces, sampling parameters, and interface counters. Packet sampling is typically performed by the ASIC. The sFlow collector analyzes the sFlow datagrams received from different devices and produces a network-wide view of traffic flows. You can configure up to five collectors, using both IPv4 and IPv6 addresses.
The sFlow datagram provides information about the sFlow version, its originating agent's IP address, a sequence number, one or more flow samples or counter samples or both, and protocol information.
sFlow can be port based or ACL based.
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.
Access-list (ACL) based sFlow ensures that sampling is done per flow instead of per port. ACL based sFlow uses global sampling rate .
The following applications does flow based sFLow.
Note
When User ACL based sFlow is enabled along with port based sFlow, two samples are generated, one for port based and the other one for User ACL based sFlow. The difference between these two samples are not visible on the collector. However, the difference is visible in the show sflow all command output (sflow interface/ACL/VxLan Visibility statistics).Port-based and flow-based sFlow are supported on physical ethernet ports only.
Note
sFlow counter samples will be generated for all the sflow enabled interfaces even if the interface is down.Note
On SLX 9740, Port based sFlow is supported on port-channel interfaces and their member ports.
On all devices, except SLX 9740, Port based sFlow is not supported on port-channel interfaces. However, you can configure sFlow on the individual member ports of the port-channel and VE interfaces.
The sFlow packet processing support for the sflow BGP AS path forwarding works when the BGP is up and it advertises routes. sFlow samples with destination IP (DIP) address and source IP (SIP) address that match the route in BGP routing table, collected and sent to the collector are appended with the BGP AS-path information also known as the extended gateway header. In case of samples with DIPs and SIPs that do not have route in BGP routing table and sent to sFlow Collector are not appended with AS-path. However, this does not impact the sFlow operation. This attribute identifies autonomous systems (ASs) through which update message has passed. The last AS traversed by prefix is placed at the beginning of list. You can configure a maximum number of 300 ASs.
Note
A BGP community is used for traffic engineering and dynamic routing policies. It can be added to the route and advertised to all neighbors. The community attribute values are encoded with an Autonomous System (AS) number in the first two octets, with the remaining two octets defined by the AS. A prefix can have more than one community attribute. A BGP speaker that sees multiple community attributes in a prefix can act based on one, some or all the attributes. A router has the option to add or modify a community attribute before the router passes the attribute on to other peers. In sFlow, based on the standard, the community routing policies can be predicted for prefixes belonging to same community. An AS-path exists in an sFlow sample where a DIP matches the BGP route table but presence of community attribute is optional.