Layer 2 services infrastructure
This chapter describes the components of Layer 2 services on SR Linux. It contains the following topics:
mac-vrf network-instance
The network-instance type mac-vrf functions as a broadcast domain. Each mac-vrf network-instance builds a bridge table composed of MAC addresses that can be learned via the data path on network-instance interfaces or via static configuration. You can configure the size of the bridge table for each mac-vrf network-instance, as well as the aging for dynamically learned MAC addresses and other parameters related to the bridge table.
The mac-vrf network-instance type features a MAC duplication mechanism that monitors MAC address moves across network-instance interfaces and across interfaces.
MAC selection
Each mac-vrf network-instance builds a bridge table to forward Layer 2 frames based on a MAC address lookup. The SR Linux selects the MAC addresses to be sent for installation to the line card (XDP), based on the following priority:
Local application MACs (for example, IRB interface MACs)
Local static MACs
EVPN static MACs
Local duplicate MACs
Learned / EVPN-learned MACs
MAC duplication detection and actions
MAC duplication is the mechanism used by SR Linux for loop prevention. MAC duplication monitors MAC addresses that move between subinterfaces. It consists of detection, actions, and process restart.
MAC duplication detection
Detection of duplicate MAC addresses is necessary when extending broadcast domains to multiple leaf nodes. SR Linux supports a MAC duplication mechanism that monitors MAC address moves across network-instance interfaces.
A MAC address is considered a duplicate when its number of detected moves is greater than a configured threshold within a configured time frame where the moves are observed. Upon exceeding the threshold, the system holds on to the prior local destination of the MAC and executes an action.
MAC duplication actions
The action taken upon detecting one or more MAC addresses as duplicate on a subinterface can be configured for the mac-vrf network-instance or for the subinterface. The following are the configurable actions:
oper-down – When one or more duplicate MAC addresses are detected on the subinterface, the subinterface is brought operationally down.
blackhole – Upon detecting a duplicate MAC on the subinterface, the MAC is blackholed.
stop learning – Upon detecting a duplicate MAC on the subinterface, the MAC address is not relearned anymore on this or any subinterface. This is the default action for a mac-vrf network-instance.
use-network-instance-action – (Available for subinterfaces only) Use the action specified for the mac-vrf network-instance. This is the default action for a subinterface.
MAC duplication process restarts
When at least one duplicate MAC address is detected, the duplicate MAC addresses are visible in the state datastore and can be displayed with the info from state mac-duplication duplicate-entries CLI command. See Displaying bridge table information.
Configurable hold-down-time
The info from state mac-duplication duplicate-entries command also displays the hold-down-time for each duplicate MAC address. After the hold-down-time expires for all of the duplicate MAC addresses for the subinterface, the oper-down or stop-learning action is cleared, and the subinterface is brought operationally up or starts learning again.
The hold-down-time is configurable from between 2 and 60 minutes. You can optionally specify indefinite for the hold-down-time, which prevents the oper-down or stop-learning action from being cleared after a duplicate MAC address is detected; in this case, you can manually clear the oper-down or stop-learning action by changing the mac-duplication configuration or using the tools network-instance bridge-table mac-duplication command.
Bridge table configuration
The bridge table, its MAC address limit, and maximum number of entries can be configured on a per mac-vrf or per-subinterface basis.
When the size of the bridge table exceeds its maximum number of entries, the MAC addresses are removed in reverse order of the priority listed in MAC selection.
You can also configure aging for dynamically learned MAC addresses and other parameters related to the bridge table.
Interface extensions for Layer 2 services
To accommodate the Layer 2 services infrastructure, SR Linux interfaces support the following features:
Traffic classification and ingress/egress mapping actions
Subinterfaces of type routed and bridged
Traffic classification and ingress/egress mapping actions
On mac-vrf network-instances, traffic can be classified based on VLAN tagging. Interfaces where VLAN tagging is set to false or true can be used with mac-vrf network-instances.
A default subinterface can be specified, which captures untagged and non-explicitly configured VLAN-tagged frames in tagged subinterfaces.
Within a tagged interface, a default subinterface (vlan-id value is set to any) and an untagged subinterface can be configured. This kind of configuration behaves as follows:
The vlan-id any subinterface captures untagged and non-explicitly configured VLAN-tagged frames.
The untagged subinterface captures untagged and packets with tag0 as outermost tag.
When vlan-id any and untagged subinterfaces are configured on the same tagged interface, packets for unconfigured VLANs go to the vlan-id any subinterface, and tag0/untagged packets go to the untagged subinterface.
Classification is based on the following:
All traffic for interfaces where VLAN tagging is set to false, regardless of existing VLAN tags.
Single outermost tag for tagged interfaces where VLAN tagging is set to true. Only Ethertype 0x8100 is considered for tags; other Ethertypes are treated as payload.
The following ingress and egress VLAN mapping actions are supported:
At ingress, pop the single outermost tag (tagged interfaces), or perform no user-visible action (untagged interfaces).
At egress, push a specified tag at the top of the stack (tagged interfaces) or perform no user-visible action (untagged interfaces).
If the vlan-id value is set to any or the subinterface uses an untagged configuration, no tag is popped at ingress or pushed at egress.
There is one exception: on a subinterface that uses an untagged configuration, if a received packet has tag0 as its outermost tag, the subinterface pops tag0.
Dot1p is not supported.
Routed and bridged subinterfaces
SR Linux subinterfaces can be specified as type routed or bridged:
Routed subinterfaces can be assigned to a network-instance of type mgmt, default, or ip-vrf.
Bridged subinterfaces can be assigned to a network-instance of type mac-vrf.
Routed subinterfaces allow for configuration of IPv4 and IPv6 settings, and bridged subinterfaces allow for configuration of bridge table and VLAN ingress/egress mapping.
Bridged subinterfaces do not have MTU checks other than the interface-level MTU (port MTU) or the value set with the l2-mtu command. The IP MTU is only configurable on routed subinterfaces.
IRB interfaces
Integrated routing and bridging (IRB) interfaces enable inter-subnet forwarding. Network-instances of type mac-vrf are associated with a network-instance of type ip-vrf via an IRB interface. See MAC-VRF, IRB interface, and IP-VRF for an illustration of the relationship between mac-vrf and ip-vrf network-instances.
On SR Linux, IRB interfaces are named irbN
, where
N is 0 to 255. Up to 4095 subinterfaces can be defined under an
IRB interface. An ip-vrf network-instance can have multiple IRB subinterfaces, while a
mac-vrf network-instance can reference only one IRB subinterface.
IRB subinterfaces are type routed. They cannot be configured as type bridged.
IRB subinterfaces operate in the same way as other routed subinterfaces, including support for the following:
IPv4 and IPv6 ACLs
DSCP based QoS (input and output classifiers and rewrite rules)
Static routes and BGP (IPv4 and IPv6 families)
IP MTU (with the same range of valid values as Ethernet subinterfaces)
All settings in the subinterface/ipv4 and subinterface/ipv6 containers. For IPv6, the IRB subinterface also gets an IPv6 link local address
BFD
Subinterface statistics
IRB interfaces do not support sFlow, VLAN tagging, or interface statistics.
Using ACLs with IRB interfaces and Layer 2 subinterfaces
Note the following when using Access Control Lists with an IRB interface or Layer 2 subinterface:
Input ACLs associated with Layer 2 subinterfaces match all the traffic entering the subinterface, including Layer 2 switched traffic or Layer 3 traffic forwarded to the IRB.
Input ACLs associated with IRB subinterfaces only match Layer 3 traffic; that is, traffic with a MAC destination address matching the IRB MAC address.
The same ACL can be attached to a Layer 2 subinterface and an IRB subinterface in the same service. In this case, there are two ACL instances, one for the IRB with higher priority and another one for the bridged traffic. Routed traffic matches the higher priority instance entries of the ACL.
The same ACL can be attached to IRB subinterfaces and Layer 2 subinterfaces if both belong to different services.
On 7220 IXR-D1, D2, and D3 systems, egress ACLs, unlike ingress ACLs, cannot match both routed and switched traffic when a Layer 2 IP ACL is attached.
Received traffic on a mac-vrf is automatically discarded if the MAC source address matches the IRB MAC address, unless the MAC is an anycast gateway MAC.
Packet capture filters show the Layer 2 subinterface for switched traffic and the IRB interface for routed traffic.
Layer 2 services configuration
The examples in this section show how to configure a mac-vrf network-instance, bridged interface, and IRB interface.
mac-vrf network-instance configuration example
The following example configures a mac-vrf network-instance and settings for the bridge table. The bridge table is set to a maximum of 500 entries. Learned MAC addresses are aged out of the bridge table after 600 seconds.
MAC duplication detection is configured so that a MAC address is considered a duplicate when its number of detected moves across network-instance interfaces is greater than 3 over a 5-minute interval. In this example, the MAC address is blackholed. After the hold-down-time of 3 minutes, the MAC address is flushed from the bridge table, and the monitoring process for the MAC address is restarted.
The example includes configuration for a static MAC address in the bridge table.
The mac-vrf network-instance is associated with a bridged interface and an IRB interface.
--{ candidate shared default }--[ ]--
network-instance mac-vrf-1 {
description "Sample mac-vrf network instance"
type mac-vrf
admin-state enable
interface ethernet-1/1.1 {
}
interface irb1.1 {
}
bridge-table {
mac-limit {
mac-limit 500
}
mac-learning {
admin-state enable
aging {
admin-state enable
age-time 600
}
}
mac-duplication {
admin-state enable
monitoring-window 5
num-moves 3
hold-down-time 3
action blackhole
static-mac {
address [mac1
}
}
}
}
}
Bridged subinterface configuration example
The following example configures the bridged subinterface that is associated with the mac-vrf in the previous example.
--{ candidate shared default }--[ ]--
interface ethernet-1/1 {
admin-state enable
subinterface 1 {
admin-state enable
type bridged
vlan {
encap {
single-tagged {
vlan-id 10
}
}
}
}
}
}
The vlan-id value can be configured as a specific valid number or with the keyword any, which means any frame that does not hit the vlan-id configured in other subinterfaces of the same interface is classified in this subinterface.
In the following example, the vlan encap untagged setting is enabled for subinterface 1. This setting allows untagged frames to be captured on tagged interfaces.
For subinterface 2, the vlan encap single-tagged vlan-id any setting allows non-configured VLAN IDs and untagged traffic to be classified to this subinterface.
With the vlan encap untagged setting on one subinterface, and the vlan encap single-tagged vlan-id any setting on the other subinterface, traffic enters the appropriate subinterface; that is, traffic for unconfigured VLANs goes to subinterface 2, and tag0/untagged traffic goes to subinterface 1.
--{ candidate shared default }--[ ]--
interface ethernet-1/2
vlan-tagging true
subinterface 1 {
type bridged
vlan {
encap {
untagged
}
}
subinterface 2 {
type bridged
vlan {
encap {
single-tagged {
vlan-id any
}
IRB interface configuration example
The following example configures an IRB interface. The IRB interface is operationally up when its admin-state is enabled, and its IRB subinterfaces are operationally up when associated with mac-vrf and ip-vrf network-instances. At least one IPv4 or IPv6 address must be configured for the IRB subinterface to be operationally up.
--{ candidate shared default }--[ ]--
interface irb1 {
description IRB_Interface
admin-state enable
subinterface 1 {
admin-state enable
ipv4 {
address 172.16.1.1/24 {
}
}
}
}
Displaying bridge table information
You can display information from the bridge table of a mac-vrf network-instance using show commands and the info from state command.
To display a summary of the bridge table contents for the mac-vrf network-instances configured on the system:
# show network-instance * bridge-table mac-table summary
-------------------------------------------------------------------
Network-Instance Bridge table summary
-------------------------------------------------------------------
-------------------------------------------------------------------
Name : mac-vrf-1
Irb mac : 1 Total 1 Active
Static macs : 19 Total 19 Active
Duplicate macs : 10 Total 10 Active
Learnt macs : 15 Total 14 Active
Total macs : 45 Total 44 Active
Maximum-Entries : 200
Warning Threshold Percentage : 95% (190)
Clear Warning : 90% (180)
-------------------------------------------------------------------
Name : mac-vrf-2
Irb mac : 1 Total 1 Active
Static macs : 1 Total 1 Active
Duplicate macs : 10 Total 10 Active
Learnt macs : 15 Total 14 Active
Total macs : 27 Total 26 Active
Maximum-Entries : 200
Warning Threshold Percentage : 95% (190)
Clear Warning : 90% (180)
-------------------------------------------------------------------
-------------------------------------------------------------------
Total Irb macs : 2 Total 2 Active
Total Static macs : 29 Total 29 Active
Total Duplicate macs : 20 Total 20 Active
Total Learnt macs : 30 Total 29 Active
Total Macs : 81 Total 80 Active
-------------------------------------------------------------------
To list the contents of the bridge table for a mac-vrf network-instance:
# show network-instance mac-vrf-1 bridge-table mac-table all
--------------------------------------------------------------------------------------
Mac-table of network instance mac-vrf-1
--------------------------------------------------------------------------------------
+------------------+--------------+----------+---------+------+-----+----------------+
| Mac |Destination |Dest-Index|Type |Active|Aging|Last-update |
+==================+==============+==========+=========+======+=====+================+
| 00:00:00:00:00:01|ethernet-1/1.1|65 |Learnt |True |256 |2020-2-3T3:37:26|
| 00:00:00:00:00:02| irb1.1| 0 |Irb |True |N/A |2019-2-1T3:37:26|
| 00:00:00:00:00:03| blackhole| 0 |Duplicate|True |N/A |2019-2-1T3:37:26|
| 00:00:00:00:00:04|ethernet-1/1.2|66 |Learnt |True |256 |2019-2-1T3:37:26|
--------------------------------------------------------------------------------------
Total Irb macs : 2 Total 2 Active
Total Static macs : 0 Total 0 Active
Total Duplicate macs : 1 Total 1 Active
Total Learnt macs : 3 Total 3 Active
Total Macs : 6 Total 6 Active
--------------------------------------------------------------------------------------
To display information about a specific MAC address in the bridge table:
# show network-instance * bridge-table mac-table mac 00:00:00:00:00:01
------------------------------------------------------------------------------------
Mac-table of network instance mac-vrf-1
------------------------------------------------------------------------------------
Mac : 00:00:00:00:00:01
Destination : ethernet-1/1.1
Destination Index : 65
Type : Learnt
Programming status : Success | Failed | Pending
Aging : 250 seconds
Last update : 2019-12-13T23:37:26.000
Duplicate Detect Time : N/A
Hold-down-time-remaining: N/A
------------------------------------------------------------------------------------
To display the duplicate MAC address entries in the bridge table:
# show network-instance * bridge-table mac-duplication duplicate-entries
------------------------------------------------------------------------------------------
Mac-duplication in network instance mac-vrf-1
------------------------------------------------------------------------------------------
Admin-state : Enabled
Monitoring window : 3 minutes
Number of moves allowed : 5
Hold-down-time : 10 seconds
Action : Stop Learning
------------------------------------------------------------------------------------------
Duplicate entries in network instance mac-vrf-1
------------------------------------------------------------------------------------------
+------------------+----------------+----------+------------------------+----------------+
| Duplicate mac | Destination |Dest-Index| Detect-Time | Hold down |
| | | | | time remaining |
+==================+================+==========+========================+=================
| 00:00:00:00:00:01|ethernet-1/1.1 |65 |2019-12-13T23:37:26.000 | 6
| 00:00:00:00:00:02|ethernet-1/1.1 |65 |2019-12-13T23:37:26.000 | 6
| 00:00:00:00:00:03|ethernet-1/1.1 |65 |2019-12-13T23:37:26.000 | 6
------------------------------------------------------------------------------------------
Total Duplicate macs : 3 Total 3 Active
------------------------------------------------------------------------------------------
You can display the duplicate/learned/static MAC address entries in the bridge table using info from state commands. For example, the following command displays the duplicate MAC entries:
# info from state network-instance * bridge-table mac-duplication duplicate-entries mac * | as
table
+--------------------+---------------------+---------+------------------------+---------------+
| Network-instance | Duplicate-mac | Dest-idx| Detect-time | Hold-down-time|
| | | | | remaining |
+====================+=====================+=========+========================+===============+
| red | 00:00:00:00:00:01 | 1 | 2019-12-13T23:37:26.000| 10 |
| red | 00:00:00:00:00:02 | 2 | 2019-12-13T23:37:26.000| 20 |
| red | 00:00:00:00:00:03 | 3 | 2019-12-13T23:37:26.000| 90 |
| blue | 00:00:00:00:00:04 | 4 | 2019-12-13T23:37:26.000| 90 |
| blue | 00:00:00:00:00:05 | 0 | 2019-12-13T23:37:26.000| 90 |
+--------------------+---------------------+---------+------------------------+---------------+
The following command displays the learned MAC entries in the table:
# info from state network-instance * bridge-table mac-learning learnt-entries mac * | as table
+------------------+------------------+--------------+---------+------------------------+
| Network-instance | Learnt-mac | Dest | Aging | Last-update |
+==================+==================+==============+=========+========================+
| red | 00:00:00:00:00:01|ethernet-1/1.1| 300 | 2019-12-13T23:37:26.000|
| red | 00:00:00:00:00:02|ethernet-1/1.1| 212 | 2019-12-13T23:37:26.000|
| red | 00:00:00:00:00:03|ethernet-1/1.2| 10 | 2019-12-13T23:37:26.000|
| blue | 00:00:00:00:00:04|ethernet-1/1.3| 10 | 2019-12-13T23:37:26.000|
| blue | 00:00:00:00:00:05|ethernet-1/1.4| 20 | 2019-12-13T23:37:26.000|
+------------------+------------------+--------------+---------+------------------------+
The following command displays the static MAC entries in the table:
# info from state network-instance * bridge-table static-mac mac * | as table
+------------------+------------------+--------------+
| Network-instance | Static-mac | Dest |
+==================+==================+==============+
| red | 00:00:00:00:00:01|ethernet-1/1.1|
| red | 00:00:00:00:00:02| irb1.1|
| red | 00:00:00:00:00:03| blackhole|
| blue | 00:00:00:00:00:04|ethernet-1/1.3|
| blue | 00:00:00:00:00:05|ethernet-1/1.4|
+------------------+------------------+--------------+
Deleting entries from the bridge table
The SR Linux features commands to delete duplicate or learned MAC entries from the bridge table. For a mac-vrf or subinterface, you can delete all MAC entries, MAC entries with a blackhole destination, or a specific MAC entry.
The following example clears MAC entries in the bridge table for a mac-vrf network-instance that have a blackhole destination:
--{ candidate shared default }--[ ]--
# tools network-instance mac-vrf-1 bridge-table mac-duplication delete-blackhole-macs
The following example deletes a specified learned MAC address from the bridge table for a mac-vrf network-instance:
--{ candidate shared default }--[ ]--
# tools network-instance mac-vrf-1 bridge-table mac-learning delete-mac 00:00:00:00:00:04
The following example clears all duplicate MAC entries in the bridge table for a subinterface:
--{ candidate shared default }--[ ]--
# tools interface ethernet-1/1.1 bridge-table mac-duplication delete-all-macs
Storm control on bridged subinterfaces
Storm control allows you to rate-limit BUM traffic on bridged subinterfaces. This feature measures the rate for the individual types of BUM traffic (broadcast, unknown-unicast, and multicast), and performs rate-limiting based on thresholds configured for each traffic type.
Storm control is configured as an interface-level policer. You set thresholds for each type of BUM traffic. You can configure the threshold as a percentage of interface bandwidth or as a rate in kbps.
If kbps is specified as the unit type, the rate can be configured as a multiple of 64; for example, 64, 128, 192, and so on. If the rate is configured as any value in the 1-127 kbps range, the effective rate is 64 kbps, which is shown as the operational-rate in info from state output. Similarly, if the rate is configured as any value in the 128-191 kbps range, the operational rate is 128 kbps, and so on.
The default threshold is 100% of the interface bandwidth for the three traffic types. Specifying a threshold of 0 for a traffic type blocks all traffic of that type on the interface. When a storm control policer is set to 0, the first packet of a flow affected by the policer is forwarded, but subsequent packets are dropped.
Storm control policers can be configured for Ethernet interfaces only. The Ethernet interfaces can be members of a LAG, but storm control must be configured on each interface individually; aggregate rate-limiting for the LAG is not supported.
Statistics are not collected for the storm-control policers. However, it is possible to check discarded packets at the subinterface level. For example, if storm-control for broadcast traffic is configured on interface ethernet-1/1 at a rate of 50%, and broadcast traffic on the ethernet-1/1.1 subinterface exceeds 50% of the port capacity, statistics for the ethernet-1/1.1 subinterface statistics show ingress drops.
Configuring storm control for an interface
To configure storm control, you set thresholds for each type of BUM traffic, either as a percentage of interface bandwidth or as a rate in kbps.
The following example configures storm control for an interface. The unit type is specified as kbps. Individual thresholds are set for each traffic type.
--{ * candidate shared default }--[ ]--
# info interface ethernet-1/1
interface ethernet-1/1 {
admin-state enable
ethernet {
storm-control {
units kbps
broadcast-rate 128
multicast-rate 192
unknown-unicast-rate 225
}
}
}
Displaying storm control information
You can display the configured rates for an interface using info from state and show interface commands.
--{ * candidate shared default }--[ ]--
# info from state interface ethernet-1/1 ethernet storm-control
interface ethernet-1/1 {
ethernet {
storm-control {
units kbps
broadcast-rate 128
multicast-rate 172
unknown-unicast-rate 225
operational broadcast-rate 128
operational multicast-rate 192
operational unknown-unicast-rate 192
}
}
}
--{ * candidate shared default }--[ ]--
# show interface ethernet-1/1 detail
========================================================================
Interface: ethernet-1/1
------------------------------------------------------------------------
Description : dut2_noxia_1
Oper state : up
Down reason : N/A
Last change : 9h21m16s ago, 1 flaps since last clear
Speed : 100G
Flow control : Rx is disabled, Tx is disabled
Loopback mode : false
MTU : 9232
VLAN tagging : true
Queues : 8 output queues supported, 0 used since the last clear
MAC address : 00:01:02:FF:00:0C
Last stats clear: never
-------------------------------------------------------------------------
Storm control for ethernet-1/1
-------------------------------------------------------------------------
Broadcast Rate (kbps) : 128
Multicast Rate (kbps) : 172
Unknown Unicast (kbps) : 225
Operational Broadcast Rate (kbps) : 128
Operational Multicast Rate (kbps) : 192
Operational Unknown Unicast Rate (kbps) : 192
L2CP transparency
Layer 2 Control Protocol (L2CP) transparency refers to the ability to control whether L2CP frames are tunneled across a carrier Ethernet network. Tunneling in this context means injecting the L2CP frames into the regular Layer 2 datapath, as opposed to trapping them to the CPU or discarding them.
By default, SR Linux handles L2CP frames according to the default transparency action listed in Default L2CP PDU actions for tagged and untagged frames.
Layer 2 control protocol | L2CP destination address | Protocol identifier | Default transparency action |
---|---|---|---|
LLDP |
01-80-c2-00-00-0e Only the above MAC address is identified as LLDP; other LLDP destination MAC addresses are not. |
Ethertype: 0x88cc |
Trap to CPU only if untagged, drop otherwise |
LACP |
01-80-c2-00-00-02 |
Ethertype: 0x8809 Subtype: 0x01 |
Trap to CPU only if untagged, drop otherwise |
xSTP (STP/RSTP/MSTP) |
01-80-c2-00-00-00 |
Ethertype: any |
Drop |
PAUSE |
01-80-c2-00-00-01 |
Ethertype: 0x8808 |
Drop |
Dot1X |
01-80-c2-00-00-03 |
Ethertype: 0x888e |
Drop |
PTP |
01-80-c2-00-00-0e |
Ethertype: 0x88f7 |
Drop |
E-LMI |
01-80-c2-00-00-07 |
Ethertype: 0x88ee |
Drop |
GARP/MRP |
01-80-c2-00-00-2x |
Ethertype: any |
Drop |
LACP Marker-Protocol/Link OAM 802.3ah/ESMC |
01-80-c2-00-00-02 |
Ethertype: 0x8809 All other unsupported subtypes |
Drop |
The L2CP transparency feature allows you to configure SR Linux to tunnel the following types of L2CP frames instead of performing the default transparency action, or you can configure SR Linux to tunnel all L2CP frames.
- LLDP
- LACP
- xSTP (STP/RSTP/MSTP)
- Dot1X
- PTP
When tunneling is enabled, the following takes place:
- Tagged and untagged L2CP frames are classified into a bridged subinterface based on their Dot1q tag VLAN-ID. If they are classified for forwarding into a MAC-VRF, they are flooded based on their MAC DA. If no bridged subinterface matches the incoming untagged or VLAN-ID tagged frames, they are discarded.
- L2CP transparency is supported on Ethernet interfaces only, with the processing/tunneling possible on bridged subinterfaces of a MAC-VRF. The system does not apply L2CP transparency rules to VXLAN tunnel interfaces, however it does apply them to Layer 3 subinterfaces in the default network-instance.
- When an L2CP PDU is tunneled, the source MAC is learned. When the PDU is dropped the source MAC is not learned.
To tunnel L2CP frames end-to-end between two EVPN-VXLAN leaf nodes, you must enable L2CP transparency on the ingress Layer 3 subinterfaces of the default network-instance on the egress leaf node. Otherwise, even if L2CP transparency for a protocol is configured on the bridged subinterfaces of the ingress leaf, the system discards the L2CP frames at the ingress VXLAN tunnel of the egress leaf.
L2CP transparency is not supported on interfaces configured in breakout mode. For LAG interfaces, you must configure L2CP transparency on all member interfaces.
Configuring L2CP transparency
You can enable tunneling for all L2CP protocol types listed in Default L2CP PDU actions for tagged and untagged frames, or you can enable tunneling individually for the following L2CP protocol types: LLDP, LACP xSTP (STP/RSTP/MSTP), Dot1X, and PTP.
The following example enables tunneling for all L2CP protocols:
--{ candidate shared default }--[ ]--
# info interface ethernet-1/1 ethernet l2cp-transparency
interface ethernet-1/1 {
ethernet {
l2cp-transparency {
tunnel-all-l2cp true
}
}
}
When tunnel-all-l2cp true is configured, all L2CP frames coming into the interface, identified by MAC DA = 01:80:c2:00:00:0x or MAC DA = 01:80:c2:00:00:2x, where x is any hex value, are tunneled.
The tunnel-all-l2cp command is not supported on interfaces where LLDP or LACP are enabled.
The following example disables tunneling for all L2CP protocols:
--{ candidate shared default }--[ ]--
# info interface ethernet-1/1 ethernet l2cp-transparency
interface ethernet-1/1 {
ethernet {
l2cp-transparency {
tunnel-all-l2cp false
}
}
}
When tunnel-all-l2cp false is configured, all L2CP frames not specifically enabled for tunneling are discarded.
You can enable tunneling individually for LLDP, LACP xSTP (STP/RSTP/MSTP), Dot1X, and PTP L2CP protocol types. These L2CP frames are identified by the destination MAC address, Ethertype and sometimes slow-protocol subtype; see Default L2CP PDU actions for tagged and untagged frames.
The following example enables tunneling for LLDP frames:
# info interface ethernet-1/1 ethernet l2cp-transparency
interface ethernet-1/1 {
ethernet {
l2cp-transparency {
lldp {
tunnel true
}
}
}
}
By default, all the tunnel commands are set to false, so all L2CP protocols are discarded, except for LLDP and LACP, for which a copy is trapped to the CPU (if untagged) and another copy is discarded.
Note that only LLDP frames with MAC 01-80-c2-00-00-0e are tunneled. LLDP frames with MAC DA = 01-80-c2-00-00-00 / 01-80-c2-00-00-03 are not tunneled or trapped to the CPU.
Tunneling for LLDP frames is not supported on an interface where LLDP is enabled.
Tunneling for LACP frames is not supported on an interface where
aggregate-id
is configured or the interface is member of a LAG
where LACP is enabled.
Displaying L2CP transparency information
Each of the L2CP protocols that can be tunneled is associated with an L2CP
transparency rule (oper-rule
) that indicates the state of the
actual rule installed in the datapath. This can be any of the following:
trap-to-cpu-untagged
This rule is used for LLDP and LACP frames if they are not configured to be tunneled. Untagged frames are trapped to the CPU; that is, a copy is trapped and sent to the CPM, while another copy is discarded. Tagged frames are discarded and not trapped.
drop-tagged-and-untagged
This rule is used for xSTP, Dot1x and PTP frames if they are not configured for tunneling.
tunnel-tagged-and-untagged
This rule is used for any of the five L2CP protocols when they are configured to be tunneled.
You can display the L2CP transparency configuration and oper-rule
for each L2CP protocol that can be tunneled.
Use the info from state command for an interface to display its
tunnelling configuration and oper-rule
for each protocol. For
example:
--{ candidate shared default }--[ ]--
# info from state interface ethernet-1/1 ethernet l2cp-transparency
interface ethernet-1/1 {
ethernet {
l2cp-transparency {
tunnel-all-l2cp false
lldp {
tunnel false
oper-rule trap-to-cpu-untagged
}
lacp {
tunnel false
oper-rule trap-to-cpu-untagged
}
xstp {
tunnel false
oper-rule drop-tagged-and-untagged
}
dot1x {
tunnel false
oper-rule drop-tagged-and-untagged
}
ptp {
tunnel false
oper-rule drop-tagged-and-untagged
}
}
}
}
Use the show interface detail command to display the L2CP transparency rule (oper-rule) for each protocol type; for example:
--{ candidate shared default }--[ ]--
# show interface ethernet-1/1 detail
=============================================================================
Interface: ethernet-1/1
-----------------------------------------------------------------------------
Description : <None>
Oper state : up
Down reason : N/A
Last change : 2d22h27m45s ago, 1 flaps since last clear
Speed : 10G
Flow control : Rx is disabled, Tx is disabled
MTU : 9232
VLAN tagging : false
Queues : 8 output queues supported, 2 used since the last clear
MAC address : 00:01:01:FF:00:01
Last stats clear: never
Breakout mode : false
-----------------------------------------------------------------------------
L2cp transparency rules for ethernet-1/1
-----------------------------------------------------------------------------
Lldp : trap-to-cpu-untagged
Lacp : trap-to-cpu-untagged
xStp : drop-tagged-and-untagged
Dot1x : drop-tagged-and-untagged
Ptp : tunnel-tagged-and-untagged
Non-specified L2cp : drop-tagged-and-untagged
-----------------------------------------------------------------------------
Displaying L2CP transparency statistics
To display L2CP transparency statistics, use the info from state command in candidate or running mode, or the info command in state mode.
Statistics are displayed for the following:
- Total number of L2CP packets of any L2CP protocol on all interfaces, as well as the total number of discarded and tunneled L2CP packets.
- Total number of ingress tunneled and trapped-to-CPU packets per L2CP protocol at
the system level. Individual statistics are displayed for LLDP, LACP, xSTP,
Dot1x, and PTP protocols if
tunnel-all-l2cp false
is configured.
--{ candidate shared default }--[ ]--
# info from state system l2cp-transparency l2cp-statistics
system {
l2cp-transparency {
l2cp-statistics {
total-in-packets 0
total-in-discarded-packets 0
total-in-tunneled-packets 0
total-in-trap-to-cpu-packets 0
last-clear "a day ago"
lldp {
in-tunneled-packets 0
in-trap-to-cpu-packets 0
}
lacp {
in-tunneled-packets 0
in-trap-to-cpu-packets 0
}
xstp {
in-tunneled-packets 0
in-trap-to-cpu-packets 0
}
dot1x {
in-tunneled-packets 0
in-trap-to-cpu-packets 0
}
ptp {
in-tunneled-packets 0
in-trap-to-cpu-packets 0
}
}
}
}
- Discarded L2CP frames are counted as
in-discarded-packets
in interface-level statistics. They are not counted in subinterface statistics. - Tunneled L2CP frames are counted in interface and subinterface statistics for outgoing interfaces in the appropriate counters.
- If tunnel-all-l2cp true is configured, all L2CP frames
(including LLDP, LACP, xSTP, Dot1x, and PTP) are counted only in
l2cp-statistics/total-in-tunneled-packets
regardless of protocol-specific configuration. In this case, the protocol-specific statistics are displayed as 0.
Clearing L2CP transparency statistics
You can use a tools command to clear the total counters and the per-protocol counters for L2CP transparency statistics.
To clear statistics counters for all L2CP protocols:
--{ running }--[ ]--
# tools system l2cp-transparency l2cp-total-statistics clear
To clear statistics counters for a specific L2CP protocol type:
--{ running }--[ ]--
# tools system l2cp-transparency ptp clear
Server aggregation configuration example
Server aggregation example shows an example of using MAC-VRF network-instances to aggregate servers into the same subnet.
In this example, Leaf-1 and Leaf-2 are configured with MAC-VRF instances that aggregate a group of servers. These servers are assigned IP addresses in the same subnet and are connected to the Leaf default network-instance by a single IRB subinterface. The servers use a PE-CE BGP session with the IRB IP address to exchange reachability.
Using the MAC-VRF with an IRB subinterface saves routed subinterfaces on the default network-instance; only one routed subinterface is needed, as opposed to one per server.
In this example:
TORs peer (eBGP) to 2 or 4 RIFs
MAC-VRF 20 is defined in TORs with an IRB interface with IPv4/IPv4 addresses. DHCP relay is supported on IRB subinterfaces.
The following Layer 2 features are implemented or loop and MAC duplication protection:
MAC duplication with oper-down or blackhole actions configured on the bridged subinterfaces
Storm control for BUM traffic on bridged subinterfaces
This example uses the following features:
MAC-VRF with bridge subinterfaces and IRB subinterfaces to the default network-instance
PE-CE BGP sessions for IPv4 and IPv6 address families
MAC duplication with oper-down or blackhole actions configured on the bridged subinterfaces
Storm control for BUM traffic on bridged subinterfaces
Configuration for server aggregation example
The following shows the configuration of Leaf-1 in Server aggregation example and its BGP session via IRB to server 1. Similar configuration is used for other servers and other TORs.
--{ [FACTORY] + candidate shared default }--[ interface * ]--
A:Leaf-1# info
interface ethernet-1/1 {
description tor1-server1
vlan-tagging true
subinterface 1 {
type bridged
vlan {
encap {
single-tagged {
vlan-id 100
}
}
}
}
}
// Configure an IRB interface and sub-interface that will connect
the MAC-VRF to the existing default network-instance.
--{ [FACTORY] + candidate shared default }--[ interface irb* ]--
A:Leaf-1# info
interface irb1 {
subinterface 1 {
ipv4 {
address 10.0.0.2/24 {
}
}
ipv6 {
address 2001:db8::2/64 {
}
}
}
}
// Configure the network-instance type mac-vrf
and associate the bridged and irb interfaces to it.
--{ [FACTORY] + candidate shared default }--[ network-instance MAC-VRF-1 ]--
A:Leaf-1# info
type mac-vrf
admin-state enable
interface ethernet-1/1.1 {
}
interface irb1.1 {
}
// Associate the same IRB interface to the network-
instance default and configure the BGP IPv4 and IPv6 neighbors to DUT1 and DUT3.
--{ [FACTORY] + candidate shared default }--[ network-instance default ]--
A:Leaf-1# info
type default
admin-state enable
router-id 2.2.2.2
interface irb1.1 {
}
protocols {
bgp {
admin-state enable
autonomous-system 64502
router-id 10.0.0.2
ebgp-default-policy {
import-reject-all false
}
failure-detection {
enable-bfd true
fast-failover true
}
group leaf {
admin-state enable
export-policy pass-all
ipv4-unicast {
admin-state enable
}
ipv6-unicast {
admin-state enable
}
local-as 64502 {
}
timers {
minimum-advertisement-interval 1
}
}
ipv4-unicast {
admin-state enable
}
ipv6-unicast {
admin-state enable
}
neighbor 10.0.0.1 {
peer-as 64501
peer-group leaf
transport {
local-address 10.0.0.2
}
}
neighbor 2001:db8::1 {
peer-as 64501
peer-group leaf
transport {
local-address 2001:db8::2
}
}
}
}