Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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 the configuration of each of these features using the Enterprise style of configuration.

We support these features only in an EVPN-VXLAN edge-routed bridging overlay (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 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.

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 allows 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.

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.

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 Layer 2 interfaces that are associated with VXLANs. The storm control level is set to 80 percent of the combined BUM traffic streams.

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 filter] 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.

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 also known as 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).

  • 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.

Supported.

See Use Case 1: Sample Configuration.

CE-facing interface

Egress

Not supported.

Supported.

See Use Case 2: Sample Configuration.

IP fabric-facing interface

Ingress

Supported.

Supported.

See Use Case 3: 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.

Note:

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

See Use Case 4: Sample Configuration.

VXLAN-mapped VLAN

Ingress

Supported.

Supported only for traffic entering a CE-facing interface.

See Use Case 5: Sample Configuration.

Configuring Remote Mirroring with GRE Encapsulation

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

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

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.