sFlow Support on Switches

sFlow for IP-over-IP Tunnels

You can use sFlow technology to sample IP-over-IP traffic at a physical port on devices. This feature is supported for IP-over-IP tunnels with an IPv4 outer header that carry IPv4 or IPv6 traffic. Use sFlow monitoring technology to randomly sample network packets from IP-over-IP tunnels and send the samples to a destination collector for monitoring. Devices that act as a IP-over-IP tunnel entry point, transit device, or tunnel endpoint support sFlow sampling. Table 1 shows the fields that are reported when a packet is sampled at the ingress or egress interface of a device that acts as an IP-over-IP tunnel entry point, transit device, or tunnel endpoint.

Table 1: Supported Metadata

sFlow Field	Tunnel Entry Point	Transit Device	Tunnel Endpoint
Raw packet header	Includes payload only	Includes payload and tunnel header	Egress: Includes payload only Ingress: Includes payload and tunnel header
Input interface	Incoming IFD SNMP index	Incoming IFD SNMP index	Incoming IFD SNMP index
Output interface	Outgoing IFD SNMP index	Outgoing IFD SNMP index	Outgoing IFD SNMP index

sFLow for QFabric System

On a QFabric system, sFlow technology monitors the interfaces on each Node device as a group, and implements the binary backoff algorithm based on the traffic on that group of interfaces.

On the QFabric system, the following default values are used if the optional parameters are not configured:

• Agent ID is the management IP address of the default partition.

• Source IP is the management IP address of the default partition.

In addition, the QFabric system subagent ID (which is included in the sFlow datagrams) is the ID of the Node group from which the datagram is sent to the collector.

On a QFabric system, the sFlow technology architecture is distributed. The global sFlow technology configuration defined on the QFabric system Director device is distributed to Node groups that have sFlow sampling configured on their interfaces. The sFlow agent has a separate sampling entity, known as a subagent, running on each Node device. Each subagent has its own independent state and forwards its own sample information (datagrams) directly to the sFlow collectors.

On the QFabric system, an sFlow collector must be reachable through the data network. Because each Node device has all routes stored in the default routing instance, the collector IP address should be included in the default routing instance to ensure the collector’s reachability from the Node device.

Regardless of the rate of traffic or the configured sampling interval, a datagram is sent whenever its size reaches the maximum Ethernet transmission unit (MTU) of 1500 bytes, or whenever a 250-ms timer expires, whichever occurs first. The timer ensures that a collector receives regularly sampled data.

Packet-based sampling in sFlow is implemented in the hardware. If traffic levels are unusually high, the hardware generates more samples than it can handle, and the extra samples are dropped, producing inaccurate results. Enabling the disable-sw-rate-limiter statement disables the software rate-limiting algorithm and allows the hardware sampling rate to stay within the maximum sampling rate.

sFlow for EVPN-VXLAN

You can use sFlow technology to sample known multicast traffic carried over EVPN-VXLAN. Sampling of known multicast traffic is supported for traffic that enters the switch over EVPN-VXLAN or in other words core facing interface and egresses the switch out of customer-facing ports. Also, known multicast traffic sampling is supported only in the egress direction. To enable egress sFlow sampling of known multicast traffic on a customer facing port, you need to enable sFlow on the interface in the egress direction as it is done for the standard unicast traffic sampling scenario. In addition, you need to include the egress-multicast enable option at the [edit forwarding options sflow] hierarchy level. The maximum replication rate for multicast traffic samples can be configured using the eggress-multicast max-replication-rate rate option at the [edit forwarding options sflow eggress-multicast] hierarchy level.

When a set of sFlow egress sampling enabled interfaces are subscribed to a given multicast group and egress sFlow multicast sampling option is enabled, all the interfaces will be sampled at the same rate. The minimum of the configured sFlow rate, or in other words, the most aggressive sampling rate among this set of interfaces is used for sampling across all the interfaces in the set. A single port will generate samples at different rates if it is part of multiple multicast groups, as multicast sampling for a specific group depends on the most aggressive sampling rate among the ports of that particular group.

On EVPN-VXLAN, the centrally-routed bridging (CRB) and Edge-routed bridging (ERB) architecture are supported with sFlow. EVPN-VXLAN supports only IPv4 address.

Table 2: Supported Metadata

Incoming Interface and Encapsulation	Outgoing Interface and Encapsulation	Required Sampled Content	Forwarding Scenario	Metadata
Access port Layer 2 traffic	Network port	Incoming Layer 2 header + Layer 2 payload	Packets are encapsulated with VXLAN header and forwarded.	Incoming Interface Index or Identifier. Outgoing Interface Index or Identifier
Network port Layer 3 traffic	Access port	Incoming Layer 3 header + VXLAN header + Inner payload	Packets are de-capsulated and forwarded.	Incoming Virtual Tunnel End Point (VTEP) Interface Index or Identifier. Outgoing Interface Index or Identifier
Access port Layer 2 traffic	Network port	Incoming Layer 2 Header + Layer 2 payload	Packets are encapsulated with VXLAN header and forwarded.	Incoming Interface Index or Identifier. Outgoing Interface Index or Identifier
Network port Layer 3 traffic	Access port	Inner payload	Packets are de-capsulated and forwarded.	Incoming VTEP Interface Index or Identifier. Outgoing Interface Index or Identifier

Table 3 provides Metadata information for extended switch data and extended routing data.

Table 3: Supported Metadata for Extended Switch Data and Extended Routing Data

EVPN-VXLAN	Scenario	Traffic Type	sFlow Interface Side	VXLAN Tunnel Type	Extended Switch Data				Extended Routing Data
					IIF VLAN	IIF VLAN Priority	OIF VLAN	OIF VLAN Priority	NH IP	NH SMASK	NH DMASK
CRB	Layer 2 GW Leaf	Layer 2	Ingress	Encap	Yes	Yes	No	No	Yes	Yes	Yes
				Decap	No	No	Yes	No	No	No	No
			Egress	Encap	Yes	No	No	No	Yes	Yes	Yes
				Decap	No	No	Yes	No	No	No	No
	Layer 3 GW Spine	Layer 2	Ingress	No	No	No	No	No	No	No	No
				No	No	No	No	No	No	No	No
				Transit	No	No	No	No	Yes	Yes	Yes
			Egress	No	No	No	No	No	No	No	No
				No	No	No	No	No	No	No	No
				Transit	No	No	No	No	Yes	Yes	Yes
		Layer 3 Traffic (Inter Vlan Case)	Ingress	Encap	No	No	No	No	Yes	Yes	Yes
				Decap	No	No	No	No	Yes	Yes	Yes
				Transit	No	No	No	No	Yes	Yes	Yes
			Egress	Encap	No	No	No	No	Yes	Yes	Yes
				Decap	No	No	No	No	Yes	Yes	Yes
				Transit	No	No	No	No	Yes	Yes	Yes
ERB	Layer 2+Layer 3	Layer 2	Ingress	Encap	Yes	Yes	No	No	Yes	Yes	Yes
				Decap	No	No	Yes	No	No	No	No
			Egress	Encap	Yes	No	No	No	Yes	No	Yes
				Decap	No	No	Yes	No	No	No	No
		Layer 3 Traffic (Inter VLAN Case)	Ingress	Encap	Yes	Yes	No	No	Yes	Yes	Yes
				Decap	No	No	Yes	No	No	No	No
			Egress	Encap	Yes	No	No	No	Yes	Yes	Yes
				Decap	No	No	Yes	No	No	No	No

Platform-Specific sFlow Behavior

Use Feature Explorer to confirm platform and release support for specific features.

Use the following table to review platform-specific behaviors for your platform.

Platform	Difference
EX Series	EX Series switches that support sFlow utilize the distributed sFlow architecture. EX Series switches that support sFlow have the following limitations: The EX3400, EX4100, EX4300, and EX4400 Series switches use pseudo-egress sampling, which captures packets as they appear in the ingress pipeline, rather than true egress samples. EX9200 line of switches do not support true OIF (outgoing interface) with sFlow. EX9200 line of switches support the configuration of only one sampling rate (inclusive of ingress and egress rates) on an FPC (or line card). To maintain compatibility with the sFlow configuration of other Juniper Networks products, the switches still accept multiple rate configurations on different interfaces of the same FPC. However, the switches program the lowest rate as the sampling rate for all the interfaces of that FPC. The (show sflow interfaces) command displays the configured rate and the actual (effective) rate. However, different rates on different FPCs are still supported on EX9200 switches. EX9200 line of switches with the EX9200-15C line card do not support sFlow configuration.
QFX Series	QFX Series switches that support sFlow have the following limitations: On QFX5130-32CD and QFX5700 switches, the egress sFlow uses the ingress pipeline packet, unlike other QFX series devices that use original source and destination IP addresses. The sampled packets at the egress interface show the VXLAN header with the ingress VXLAN’s source and destination IP addresses. The egress sampled packets for the QFX5130-32CD and QFX5700 switches show the IP addresses of the VXLAN endpoints from the preceding VXLAN tunnel. The show interfaces vtep extensive command displays that the sampled packets are routed through the VXLAN VTEP interface. This is not true egress sampling. QFX5100, QFX5110, QFX5120, QFX5130, QFX5200, QFX5210, QFX5220, QFX5240, and QFX5700 Series switches use pseudo-egress sampling, which captures packets as they appear in the ingress pipeline, rather than true egress samples. On QFX10000 line of switches, sFlow technology works at the physical interface level. Enabling sFlow on one logical interface automatically enables it for all logical interfaces associated with that physical interface. On QFX10000 line of switches, you can configure sFlow only on an active logical interface. Use the show interfaces terse command to display the status information of interfaces. If both operational and admin state of an interface is up, then it is an active interface. On QFX10000 line of switches, sFlow fails to generate samples as expected when ingress or egress interfaces are part of the routing instance, especially in ECMP scenarios. However, egress Sflow generates expected samples for IPIP packets between different routing instances, even in ECMP scenarios.