Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

MAC Filtering, Storm Control, and Port Mirroring Support in an EVPN-VXLAN Environment

We support MAC filtering, storm control, and port mirroring and analyzing in an Ethernet VPN-Virtual Extensible LAN (EVPN-VXLAN) overlay network.

We support each of these features using the enterprise style for interface configuration.

We also support these features using service provider (SP) style for interface configuration with some limitations:

  • We support port mirroring with a firewall filter in the input direction using the SP style interface configuration, but not in the output direction.

  • We support storm control only on a single logical interface in SP style physical interface configurations. You can’t configure storm control on multiple logical interfaces with SP style configurations.

    • Due to hardware limitations, storm control applied to a logical interface also applies to the underlying physical interface.

    • The logical interface with storm control configured logs the storm, but any logical interface on the physical interface can trigger storm control.

We support these features only in an EVPN-VXLAN edge-routed bridging (ERB) overlay, which is also called an EVPN-VXLAN topology with a collapsed IP fabric. This overlay network includes the following components:

  • A single layer of Juniper Networks switches—for example, QFX10002, QFX5120, or QFX5110 switches—each of which functions as both a Layer 3 spine device and a Layer 2 leaf device.

  • Customer edge (CE) devices that are single-homed or multihomed in active/active mode to the spine-leaf devices.

Note:

We support both local and remote port mirroring with EVPN-VXLAN on some platforms:

  • local—The packets are mirrored to a destination on the same device.

  • remote—The packets are mirrored to a destination on a remote device.

If you want to use remote port mirroring with EVPN-VXLAN, be sure to look at the Feature Explorer page for Remote port mirroring with VXLAN encapsulation to see the supported platforms and releases.

See Port Mirroring and Analyzers for more on local or remote port mirroring with EVPN-VXLAN.

This topic includes the following information:

Benefits of MAC Filtering, Storm Control, and Port Mirroring Support in an EVPN-VXLAN Environment

  • MAC filtering enables you to filter and accept packets from ingress CE-facing interfaces, thereby reducing the volume of associated MAC addresses in the Ethernet switching table and traffic in a VXLAN.

  • Storm control enables you to monitor traffic levels on EVPN-VXLAN interfaces, and if a specified traffic level is exceeded, drop broadcast, unknown unicast, and multicast (BUM) packets and on some Juniper Networks switches, disable the interface for a specified amount of time. This feature can prevent excessive traffic from degrading the network.

  • With port mirroring and analyzers, you can analyze traffic down to the packet level in an EVPN-VXLAN environment. You can use this feature to enforce policies related to network usage and file sharing and to identify problem sources by locating abnormal or heavy bandwidth usage by particular stations or applications.

MAC Filtering

MAC filtering enables you to filter MAC addresses and accept traffic. We support this feature only on ingress CE-facing interfaces, which are interfaces on which VXLAN encapsulation is typically not enabled. To use this feature, you must do the following:

  • Create a firewall filter in which you specify one or more of the supported match conditions in Table 1 and Table 2.

  • Apply the firewall filter to a Layer 2 interface configured in the [edit interfaces interface-name unit logical-unit-number family ethernet-switching filter] hierarchy.

Table 1: Match Conditions Supported on QFX5100 and QFX5110 Switches

Match Conditions

Interface Input Filter Support

Interface Output Filter Support

Source MAC address

X

X

Destination MAC address

X

X

User VLAN ID

X

X

Source port

X

Destination port

X

Ether-type

X

IP protocol

X

IP precedence

X

ICMP codes

X

TCP flags

X

IP address

X

Note:

In Junos OS Release 18.4R1, QFX5100 and QFX5110 switches support MAC filtering only on an interface. And, starting in Junos OS Release 18.4R2 and in later releases, QFX5100, QFX5110, QFX5120-48Y, and EX4650-48Y switches also support MAC filtering on a VXLAN-mapped VLAN. Junos OS Release 22.2 includes support Mac Filtering and Transit VNI Matching for pure IPv6 underlay on QFX10002, QFX10008, and QFX10016 devices.
Table 2: Match Conditions Supported on QFX10000 Switches

Match Conditions

Interface Input Filter Support

Interface Output Filter Support

Source MAC address

X

Destination MAC address

X

User VLAN ID

Source port

X

X

Destination port

X

X

Ether-type

X

X

IP protocol

X

IP precedence

X

X

ICMP codes

X

X

TCP flags

X

X

IP address

X

X
Note:

When configuring MAC filters on QFX10000 switches, keep the following in mind:

  • You can apply a filter to an interface only. You cannot apply a filter to a VXLAN-mapped VLAN.

  • We do not support a mix of Layer 2 match conditions and Layer 3/Layer 4 match conditions in the same firewall filter. For example, if you include source MAC address and source port match conditions in the same firewall filter on a QFX10002 switch, the firewall filter will not work.

  • We do not support the user VLAN ID match condition. Therefore, if you need to filter logical interfaces, each of which is mapped to a particular VLAN, you must use the service provider style of configuration when configuring the physical interface and associated logical interfaces. After creating a firewall filter, you must then apply the filter to each logical interface to achieve the effect of the user VLAN ID match condition.

  • With Junos OS Release 22.2, support is also implemented for VxLAN Network ID (VNI) matching on source/destination IP outer headers for transit traffic on a Layer-3 interface for QFX10002, QFX10008, and QFX10016 devices. VNI matches are made on outer headers only and on ingress traffic only. On transit devices that route tunnel packets, MAC filtering must support the matching of VNI in the outer header, along with outer header source and destination IPv6 addresses as match conditions. Use the VNI match filter under the vxlan match CLI option for the set firewall family inet6 filter term from the <vxlan [vni <vni-id>]> command. Use the show firewall filter command to display statistics.

Through the firewall filter, you specify MAC addresses associated with a VXLAN that are allowed on a particular interface.

Note:

After you apply the firewall filter to a Layer 2 interface, the interface resides under the default-switch instance.

The following sample configuration on a QFX5110 switch creates a firewall filter named DHCP-Discover-In that accepts and counts incoming traffic that meets multiple match conditions (source MAC address, destination MAC address, destination ports, and VLAN ID) on Layer 2 logical interface xe-0/0/6.0:

Storm Control

By default, storm control is enabled on QFX and EX switches for Layer 2 interfaces that are associated with VXLANs. The storm control level is set to 80 percent of the combined BUM traffic streams.

Note:

EVPN-VXLAN storm control works a bit differently on ACX series platforms. For details, see Storm Control on ACX Series Routers Overview.

In an EVPN-VXLAN environment, storm control is implemented and configured on Layer 2 interfaces that are associated with VXLANs the same as in a non-EVPN-VXLAN environment except for the following differences:

  • In an EVPN-VXLAN environment, the traffic types that storm control monitors are as follows:

    • Layer 2 BUM traffic that originates in a VXLAN and is forwarded to interfaces within the same VXLAN.

    • Layer 3 multicast traffic that is received by an integrated routing and bridging (IRB) interface in a VXLAN and is forwarded to interfaces in another VXLAN.

  • After creating a storm control profile, you must bind it to an ingress Layer 2 interface at the [edit interfaces interface-name unit logical-unit-number family ethernet-switching] hierarchy.

    Note:

    After you bind the profile to a Layer 2 interface, the interface resides within the default-switch instance.

  • If the traffic streams on an interface exceed the specified storm control level, the Juniper Networks switch drops the excess packets, which is known as rate limiting. In addition, QFX10000 switches in an EVPN-VXLAN environment support the disabling of the interface for a specified amount of time using the action-shutdown configuration statement at the [edit forwarding-options storm-control-profiles] hierarchy level and the recovery-timeout configuration statement at the [edit interfaces interface-name unit logical-unit-number family ethernet-switching] hierarchy level.

    Note:

    QFX5100 and QFX5110 switches in an EVPN-VXLAN environment do not support the disabling of the interface for a specified amount of time.

    Note:

    On QFX5110 switches, if you configure enhanced storm control and a native analyzer on an interface, and the native analyzer has the VxLAN VLAN as input, the shutdown action will not work for the VLAN on that interface. Rate limiting will work as expected.

The following configuration creates a profile named scp, which specifies that if the bandwidth used by the combined BUM traffic streams exceeds 5 percent on Layer 2 logical interface et-0/0/23.0, the interface drops the excess BUM traffic.

The following configuration creates a profile named scp, which specifies that if the bandwidth used by the multicast traffic stream (broadcast and unknown unicast traffic streams are excluded) exceeds 5 percent on Layer 2 logical interface et-0/0/23.0, the interface drops the excess multicast traffic.

The following configuration on a QFX10000 switch creates the same profile as in the previous configuration. However, instead of implicitly dropping multicast traffic if the traffic stream exceeds 5 percent, the following configuration explicitly disables the interface for 120 seconds and then brings the interface back up.

Port Mirroring and Analyzers

To analyze traffic in an EVPN-VXLAN environment, we support the following port mirroring and analyzer functionality:

  • Local mirroring

    • On an interface

    • On a VXLAN

  • Remote mirroring

    • On an interface

    • On a VXLAN

The following sections provide more information about the supported functionality and include sample configurations.

Local Mirroring

Note:

Local mirroring is comparable to Switched Port Analyzer (SPAN).
Table 3: Local Mirroring Support

Entity to Which Local Mirroring Is Applied

Traffic Direction

Filter-based Support

Analyzer-based Support

CE-facing interface

Ingress

Supported.

See Use Case 1: Sample Configuration.

Supported.

See Use Case 2: Sample Configuration.

CE-facing interface

Egress

Not supported.

Supported; however, egress mirrored traffic might carry incorrect VLAN tags that differ from the tags in the original traffic.

See Use Case 3: Sample Configuration.

IP fabric-facing interface

Ingress

Supported.

Supported.

See Use Case 4: Sample Configuration.

IP fabric-facing interface

Egress

Not supported.

Supported. However, the decision to mirror happens at ingress so the layer 2 header will not be the same as a switched or routed packet. Mirrored VXLAN-encapsulated packets will not include a VXLAN header.

See Use Case 5: Sample Configuration.

VXLAN-mapped VLAN

Ingress

Supported.

Supported only for traffic entering through a CE-facing interface.

See Use Case 6: Sample Configuration.

Configuring Local Mirroring

Use Case 1: Firewall filter-based

Through the use of a port mirroring instance named pm1 and a firewall filter, this configuration specifies that Layer 2 traffic that enters VXLAN100 through logical interface xe-0/0/8.0 is mirrored to an analyzer on logical interface xe-0/0/6.0 and then to port mirroring instance pm1.

Use Case 2: Analyzer-based

Through the use of the analyzer configuration statement at the [set forwarding-options] hierarchy level, this configuration specifies that Layer 2 traffic that enters logical interface xe-0/0/8.0 is mirrored to an analyzer on logical interface xe-0/0/6.0.

Use Case 3: Analyzer-based

Through the use of the analyzer configuration statement at the [set forwarding-options] hierarchy level, this configuration specifies that Layer 2 traffic that exits logical interface xe-0/0/8.0 is mirrored to an analyzer on logical interface xe-0/0/6.0.

Use Case 4: Analyzer-based

Through the use of the analyzer configuration statement at the [set forwarding-options] hierarchy level, this configuration specifies that Layer 2 traffic that enters logical interface xe-0/0/29.0 is mirrored to an analyzer on logical interface xe-0/0/6.0.

Use Case 5: Analyzer-based

Through the use of the analyzer configuration statement at the [set forwarding-options] hierarchy level, this configuration specifies that Layer 2 traffic that exits logical interface xe-0/0/29.0 is mirrored to an analyzer on logical interface xe-0/0/6.0.

Use Case 6: Analyzer-based

Through the use of the analyzer configuration statement at the [set forwarding-options] hierarchy level, this configuration specifies that Layer 2 traffic that enters the VLAN named VXLAN100 and is mirrored to an analyzer on logical interface xe-0/0/6.0.

Remote Mirroring

Remote port mirroring is used when the output destination is not on the same switch as the source. Remote mirroring delivers the mirrored traffic to one or more remote destination hosts. It is often used in the data center environment for troubleshooting or monitoring.

In an EVPN-VXLAN environment, the mirrored traffic flow at the source switch is encapsulated and tunneled through the underlay IP fabric to the destination host IP address. We support the following types of encapsulation:

  • Generic routing encapsulation (GRE) is used with remote mirroring to encapsulate the traffic between switches separated by a routing domain. In an EVPN-VXLAN overlay, GRE encapsulation enables mirroring between leaf devices over the IP fabric. Use remote mirroring with GRE when the mirroring destination hosts are connected to a switch that is part of the same fabric as the source switch. Remote mirroring with GRE encapsulation is comparable to encapsulated remote SPAN (ERSPAN).

    Note:

    On ACX7100-32C and ACX7100-48L platforms, the comparable version of ERSPAN is ERSPAN version 2 (ERSPAN v2).

  • VXLAN encapsulation supports remote mirroring for EVPN-VXLAN when the source and the output destinations are in separate VNI domains. You must configure a specific VXLAN for mirroring traffic for the output destination interfaces and mapped to a VNI. Remote mirroring with VXLAN encapsulation is comparable to remote SPAN (RSPAN).

Table 4: Remote Mirroring Support

Entity to Which Remote Mirroring Is Applied

Traffic Direction

Filter-based Support

Analyzer-based Support

CE-facing interface

Ingress

Supported.

Not supported on ACX7100.

Supported. See Use Case 1: Sample Configuration.

Supported on ACX7100. However, mirrored packets include a GRE header.

CE-facing interface

Egress

Not supported.

Supported. See Use Case 2: Sample Configuration.

Supported on ACX7100. However, mirrored packets include a GRE header.

IP fabric-facing interface

Ingress

Supported.

Not supported on ACX7100.

Supported. See Use Case 3: Sample Configuration.

Supported on ACX7100. However, mirrored VXLAN‐encapsulated packets include a VXLAN header and a GRE header.

IP fabric-facing interface

Egress

Not supported.

Supported. However, the decision to mirror happens at ingress so the Layer 2 header will not be the same as a switched or routed packet. See Use Case 4: Sample Configuration.

Note:

Mirrored traffic might include a bogus VLAN ID tag of 4094 on the native MAC frame.

Supported on ACX7100. However, mirrored packets include a GRE header but do not include a VXLAN header.

VXLAN-mapped VLAN

Ingress

Supported.

Not supported on ACX7100.

Supported only for traffic entering a CE-facing interface. See Use Case 5: Sample Configuration.

Not supported on ACX7100.

Configuring Remote Mirroring with GRE Encapsulation

The following sample configurations are for analyzer-based remote mirroring with GRE encapsulation.

Note:

For an example of configuring a remote analyzer with GRE encapsulation on ACX7100, see Example: Enable a Remote Analyzer Instance at an ESI-LAG Interface.

Use Case 1

Through the use of the analyzer configuration statement at the [set forwarding-options] hierarchy level, this configuration specifies that Layer 2 traffic that enters logical interface xe-0/0/8.0 is mirrored to a remote logical interface with an IP address of 10.9.9.2.

Use Case 2

Through the use of the analyzer configuration statement at the [set forwarding-options] hierarchy level, this configuration specifies that Layer 2 traffic that exits logical interface xe-0/0/8.0 is mirrored to a remote logical interface with an IP address of 10.9.9.2.

Use Case 3

Through the use of the analyzer configuration statement at the [set forwarding-options] hierarchy level, this configuration specifies that Layer 2 traffic that enters logical interface xe-0/0/29.0 is mirrored to a remote logical interface with an IP address of 10.9.9.2.

Use Case 4

Through the use of the analyzer configuration statement at the [set forwarding-options] hierarchy level, this configuration specifies that Layer 2 traffic that exits logical interface xe-0/0/29.0 is mirrored to a remote logical interface with an IP address of 10.9.9.2.

Use Case 5

Through the use of the analyzer configuration statement at the [set forwarding-options] hierarchy level, this configuration specifies that Layer 2 traffic that enters VXLAN100, which is mapped to logical interface xe-0/0/8.0, is mirrored to a remote logical interface with an IP address of 10.9.9.2.

Configuring Remote Mirroring with VXLAN Encapsulation

To find out what platforms support this feature as of which releases, see the Feature Explorer page for Remote port mirroring with VXLAN encapsulation.

Analyzer-based configuration

The following sample configuration is for analyzer-based remote mirroring with VXLAN encapsulation. Layer 2 traffic that enters VLAN100 is mirrored to remote output destination VLAN3555, which maps to VNI 1555.

This configuration uses a loopback interface on the destination VLAN to encapsulate the mirrored packets.

  • Destination interface xe-0/0/2 is externally connected to loopback interface xe-0/0/3.

  • Logical interfaces xe-0/0/2.0 and xe-0/0/3.0 are members of destination VLAN3555.
  • Interface xe-0/0/2.0 is configured in enterprise style without any VNI mapping, while interface xe-0/0/3.0 is configured in service provider style with the same vlan ID and with the VNI mapping. This is to prevent flooding or looping between these ports.
  • Mac-learning must be disabled on xe-0/0/2.0.
Note:

The ingress interface must configured in trunk mode, so the encapsulated packets are tagged. To decapsulate the tagged packets, configure the set protocols l2-learning decapsulate-accept-inner-vlan command at the decapsulation node.

To configure a logical loopback interface instead of using an external connection, use the following command:

set interfaces interface-name ether-options loopback

The sample configuration below uses a logical loopback on interface xe-0/0/2:

Firewall filter-based configuration

The following configuration applies a firewall filter, filter1, to ingress traffic at interface xe-0/0/34. Traffic ingressing on this interface is mirrored to the destination VLAN3555. The destination VLAN is defined using a port mirroring instance named pm1.

Remote Port Mirroring Using VNI Match Conditions

For QFX10002, QFX10008, and QFX10016 Series switches, you can use VXLAN network identifier (VNI) values as a match condition when filtering traffic for remote port mirroring. This is ability is often used in network planning and for analytics such as deep packet inspection (DPI).

The remote port mirroring feature acts to create a copy of targeted ingress packets, which are encapsulated in an outer IPv4 GRE header, and then forwarded to designated remote destination. Support for VNI match conditions means you can select packets to be mirrored on the basis of their VNI so that only those flows are directed to the remote mirror port. You can also configure a differentiated service code point (DSCP) value to prioritize the flow, for example, high priority or best-effort delivery. Integrated routing and bridging (IRB) interfaces are not supported as a destination mirror port.

At a high level, the procedure for remote port mirroring based on VNIs is to create a remote port mirroring instance, promote VNI in the firewall filter family to handle VNIs, create the necessary filter rules and actions, and then apply the firewall policy to an ingress interface. GRE tunneling should also be in place on the interface used to send the mirrored packets.

Remote Port Mirroring on the Basis of VNI Use Case: Sample Configuration

The code samples below highlight the key Junos CLI configurations you need to mirror packets according to VNI.

  1. Enable remote port mirroring, and also configure the traffic source and the destination to which you want to send the mirrored packets.
  2. Create a firewall filter (here, named bf_vni_st), and promote VNI in this filter to be the packet forwarding module (in other words, this command sets the entire filter to optimize VNI match conditions).
  3. Create an ingress firewall filter (bf_vni_st), that specifies a VNI match condition (6030 in this sample), and an action (count, in this sample).
  4. Apply the filter to ingress traffic at interface you want to mirror.

Related Documentation