Layer 2 services infrastructure

Each MAC-VRF network instance builds a bridge table to forward Layer 2 frames based on a MAC address lookup. SR Linux selects the MAC addresses to be sent for installation to the line card (XDP), based on the following priority:

1. local application MACs (for example, IRB interface MACs)

2. local static MACs

3. EVPN static MACs

4. local duplicate MACs

5. learned and EVPN-learned MACs

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.

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.

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 (where the vlan-id value is set to optional) and an untagged subinterface can be configured. This type of configuration behaves as follows:

• the vlan-id optional subinterface captures untagged and non-explicitly configured VLAN-tagged frames

• the untagged subinterface captures untagged and packets with tag 0 as the outermost tag

When vlan-id optional and untagged subinterfaces are configured on the same tagged interface, packets for unconfigured VLANs go to the vlan-id optional subinterface and tag 0 or 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. By default, only Ethertype 0x8100 is considered for tags; other Ethertypes are treated as payload. The default Ethertype used for classification can be modified by the command tpid [TPID_0X8100|TPID_0X88A8|TPID_0X9100|TPID_0X9200|TPID_ANY].

The following ingress and egress VLAN mapping actions are supported by default:

• 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 optional 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 tag 0 as its outermost tag, the subinterface pops tag 0.

For more information on subinterface VLAN configuration, Dot1q tagged bridged subinterfaces, and QinQ bridged subinterfaces, see the Interfaces guide.

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

The following items apply when using access control lists (ACLs) 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 (DA) 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 subinterface types 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 (SA) 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.

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 three 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 }--[  ]--
# info network-instance mac-vrf-1
    network-instance mac-vrf-1 {
        type mac-vrf
        admin-state enable
        description "Sample mac-vrf network instance"
        interface ethernet-1/1.1 {
        }
        interface irb1.1 {
        }
        bridge-table {
            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
            }
            mac-limit {
                maximum-entries 500
            }
            static-mac {
                mac 00:00:5E:00:53:FF {
                }
            }
        }
    }

The following example configures the bridged subinterface that is associated with the MAC-VRF in the previous example.

--{ candidate shared default }--[  ]--
# info interface ethernet-1/1
    interface ethernet-1/1 {
        admin-state enable
        subinterface 1 {
            type bridged
            admin-state enable
            vlan {
                encap {
                    single-tagged {
                        vlan-id 10
                    }
                }
            }
        }
    }

The vlan-id value can be configured as a specific valid number or with the keyword optional, 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 optional 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 optional setting on the other subinterface, traffic enters the appropriate subinterface; that is, traffic for unconfigured VLANs goes to subinterface 2, and tag0 or untagged traffic goes to subinterface 1.

--{ candidate shared default }--[  ]--
# info interface ethernet-1/2
    interface ethernet-1/2 {
        vlan-tagging true
        subinterface 1 {
            type bridged
            vlan {
                encap {
                    untagged {
                    }
                }
            }
        }
        subinterface 2 {
            type bridged
            vlan {
                encap {
                    single-tagged {
                        vlan-id optional
                    }
                }
            }
        }
    }

--{ * candidate shared default }--[  ]--
A:srl1# info interface ethernet-1/2
    interface ethernet-1/2 {
        vlan-tagging true
        subinterface 1 {
            type bridged
            vlan {
                encap {
                    untagged {
                    }
                }
            }
        }
        subinterface 2 {
            type bridged
            vlan {
                encap {
                    single-tagged {
                        vlan-id optional
                    }
                }
            }
        }
        subinterface 3 {
            type bridged
            vlan {
                encap {
                    double-tagged {
                        inner-vlan-id 10
                        outer-vlan-id 30
                    }
                }
            }
        }
    }

For more information on subinterface VLAN configuration, see the Interfaces guide.

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 }--[  ]--
# info interface irb1
    interface irb1 {
        description IRB_Interface
        admin-state enable
        subinterface 1 {
            admin-state enable
            ipv4 {
                admin-state enable
                address 192.168.1.1/24 {
                }
            }
        }
    }

The following example illustrates the use of SHGs.

Interfaces ethernet-1/1.2 and ethernet-1/1.3 cannot forward traffic between each other, but can send traffic to the other interfaces and EVPN destinations.

Interfaces ethernet-1/2.1 and ethernet-1/2.2 cannot forward traffic between each other, but can send traffic to the other interfaces and EVPN destinations.

Interface ethernet-1/2.3 can forward traffic normally to any other interface or EVPN destination.

--{ * candidate shared default }--[ network-instance * ]--
A:leaf1# info
    network-instance MAC-VRF-2 {
        interface ethernet-1/1.2 {
            bridge-table {
                split-horizon-group SHG-1
            }
        }
        interface ethernet-1/1.3 {
            bridge-table {
                split-horizon-group SHG-1
            }
        }
        interface ethernet-1/2.1 {
            bridge-table {
                split-horizon-group SHG-2
            }
        }
        interface ethernet-1/2.2 {
            bridge-table {
                split-horizon-group SHG-2
            }
        }
        interface ethernet-1/2.3 {
        }
        vxlan-interface vxlan0.1 {
        }
        protocols {
            bgp-evpn {
                bgp-instance 1 {
                    admin-state enable
                    encapsulation-type vxlan
                    vxlan-interface vxlan0.1
                    evi 2
                }
            }
            bgp-vpn {
                bgp-instance 1 {
                }
            }
        }
        bridge-table {
            split-horizon-group SHG-1 {
            }
            split-horizon-group SHG-2 {
            }
        }
    }

SHGs are supported on 7730 SXR, 7220 IXR-Dx, and 7215 IXS-A1 platforms.

The following limitations apply depending on the platform.

MAC-VRF network instances support seamless integration of pseudowires, interfaces, and EVPN-MPLS destinations by configuring manual split-horizon-group objects.

--{ candidate shared default }--[ network-instance mac-vrf-5 ]--
A:srl-pe4# info
    type mac-vrf
    interface ethernet-1/1.5 {
    }
    protocols {
        bgp-evpn {
            bgp-instance 1 {
                encapsulation-type mpls
                evi 5
                mpls {
                    bridge-table {
                        split-horizon-group shg-1
                    }
                    next-hop-resolution {
                        allowed-tunnel-types [
                            bgp
                            ldp
                            sr-isis
                        ]
                    }
                }
            }
        }
        bgp-vpn {
            bgp-instance 1 {
            }
        }
    }
    bridge-table {
        split-horizon-group shg-1 {
        }
    }
    connection-point A {
        bridge-table {
            split-horizon-group shg-1
        }
        pseudowire pw-to-3 {
            admin-state enable
            pw-tunnel to-pe3
            signaling {
                virtual-circuit-identifier 5
                tldp {
                }
            }
        }
    }
    connection-point B {
        bridge-table {
            split-horizon-group shg-1
        }
        pseudowire pw-to-1 {
            admin-state enable
            pw-tunnel to-pe1
            signaling {
                virtual-circuit-identifier 5
                tldp {
                }
            }
        }
    }
    connection-point C {
        bridge-table {
            split-horizon-group shg-1
        }
        pseudowire pw-to-2 {
            admin-state enable
            pw-tunnel to-pe2
            signaling {
                virtual-circuit-identifier 5
                tldp {
                }
            }
        }
    }

By configuring all connection points and BGP-EVPN with the same split-horizon-group, traffic from a pseudowire is not forwarded to EVPN, and vice versa. Also, MACs learned over one of those pseudowires will not be advertised in EVPN to avoid duplication. A pseudowire is brought down if its remote system IP matches a received IMET route's next hop, to avoid BUM duplication between hybrid PEs.

Virtual Private Wire Service (VPWS) is a type of network instance used for Layer 2 point-to-point connectivity. VPWS network instances support two connection points, where each connection point contains a single object.

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 {
                admin-state enable
                address 10.0.0.2/24 {
                }
            }
            ipv6 {
                admin-state enable
                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
            afi-safi ipv4-unicast {
                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
                afi-safi ipv4-unicast {
                    admin-state enable
                }
                afi-safi ipv6-unicast {
                    admin-state enable
                }
                local-as as-number 64502 {
                }
                timers {
                    minimum-advertisement-interval 1
                }
            }
            afi-safi ipv4-unicast {
                admin-state enable
            }
            afi-safi 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
                }
            }
          
        }
    }