Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

sFlow Support on Switches

sFlow technology on the switches samples only raw packet headers. A raw Ethernet packet is the complete Layer 2 network frame.

An sFlow monitoring system consists of an sFlow agent embedded in the device (switch) and up to four external collectors. The sFlow agent's two main activities are random sampling and statistics gathering. The sFlow agent performs packet sampling and gathers interface statistics, and then combines the information into UDP datagrams that are sent to the sFlow collectors. An sFlow collector can be connected to the switch through the management network or data network. The software forwarding infrastructure daemon (SFID) on the switch looks up the next-hop address for the specified collector IP address to determine whether the collector is reachable by way of the management network or data network.

Each datagram contains the following information:

  • The IP address of the sFlow agent

  • The number of samples

  • The interface through which the packets entered the agent

  • The interface through which the packets exited the agent

  • The source and destination interface for the packets

  • The source and destination VLAN for the packets

You can view the Extended router data and Extended switch data headers on collector as part of sFlow records.

The Extended switch data contains information of Flow data length (byte), Incoming 802.1Q VLAN, Incoming 802.1p priority, Outgoing 802.1Q VLAN, and Outgoing 802.1p priority fields

The Extended router data contains information of Flow data length (byte), Next hop, Next hop source mask, and Next hop destination mask fields.

EX Series switches adopt the distributed sFlow architecture. The sFlow agent has two separate sampling entities that are associated with each Packet Forwarding Engine. These sampling entities are known as subagents. Each subagent has a unique ID that is used by the collector to identify the data source. A subagent has its own independent state and forwards its own sample packets to the sFlow agent. The sFlow agent is responsible for packaging the samples into datagrams and sending them to the sFlow collector. Because sampling is distributed across subagents, the protocol overhead associated with sFlow technology is significantly reduced at the collector.

For the EX9200 switch and MX Series routers, we recommend that you configure the same sample rate for all the ports in a line card. If you configure different sample rates, the lowest value is used for all ports on the line card.

In case of dual VLANs, all fields may not be reported.

If the primary-role assignment changes in a Virtual Chassis setup, sFlow technology continues to function.

sFlow for IP-over-IP Tunnels

Starting in Junos OS Release 20.4R1, you can use sFlow technology to sample IP-over-IP traffic at a physical port on QFX5100 and QFX5200 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. #id-overview-of-sflow-technology__table-sflow-qfx 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

On QFX10000 Series switches 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

#id-overview-of-sflow-technology__extended-router-metadata 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

sFlow Limitations on Switches

On switches, limitations of sFlow traffic sampling include the following:

  • The EX3400, EX4100, EX4300, EX4400, and QFX5K series switches use pseudo-egress sampling for egress sampling. Packets are not true egress samples. They are unmodified copies as they appear in the ingress pipeline of the sflow instance device that is using egress sampling.

  • On QFX5130-32CD and QFX5700 devices, 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 devices show the IP addresses of the VXLAN endpoints from the preceding VXLAN tunnel. The command show interfaces vtep extensive displays that the sampled packets are routed through the VXLAN VTEP interface. This is not true egress sampling.

  • On EX9200 switches, true OIF (outgoing interface) is not supported with sFlow.

EX9200 switches support configuration of only one sampling rate (inclusive of ingress and egress rates) on an FPC (or line card). To support compatibility with the sFlow configuration of other Juniper Networks products, EX9200 switches still accept multiple rate configuration on different interfaces of the same FPC. However, the switch programs 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 is still supported on EX9200 switches.