Nokia SR Linux EVPN-VXLAN: Interface and Tunnel Setup

SR Linux models overlay and underlay differently from the IOS-style CLIs most engineers know: there is no "interface vxlan1" abstraction. Instead you build a network-instance of type mac-vrf, bind a subinterface to it, attach a VXLAN tunnel interface with a VNI, and let BGP EVPN carry the MAC and IP routes. Layer 3 services add a routed IRB subinterface in an ip-vrf. This article lays out the object model, shows the configuration for a single VTEP, and covers the verification commands that tell you whether the tunnel is actually up.

The SR Linux Object Model

• network-instance type ip-vrf — the VRF that holds routed subnets. Equivalent to a L3 VRF/BGP instance.
• network-instance type mac-vrf — the bridging domain. Equivalent to a bridge domain or EVI.
• tunnel-interface vxlan1 — the VXLAN encapsulation point, carrying the VNI list.
• irb subinterface — the anycast gateway address that lives on the mac-vrf but belongs to the ip-vrf.

The critical binding is vxlan-interface inside the subinterface: it is what associates a VLAN tag / VNI with the MAC-VRF. Get it wrong and the VNI exists but no MACs are learned over the tunnel.

Tunnel Interface

tunnel-interface vxlan1 {
    vxlan {
        interface ethernet-1/1.0
        vni 10010 {
            vlan 10
        }
    }
}

MAC-VRF with VXLAN Binding

network-instance VRF-TENANT-1 {
    type mac-vrf
    interface ethernet-1/2.10 {
        vlan-tagging true
    }
    vxlan-interface vxlan1.10010
    protocols {
        bgp-evpn {
            bgp-instance 1
            evi 10010
            vxlan-interface vxlan1.10010
        }
    }
}

Adding Layer 3 with an IRB

network-instance VRF-TENANT-1 {
    type mac-vrf
    interface irb0.10 {
        anycast-gw true
    }
}
network-instance IP-VRF-TENANT-1 {
    type ip-vrf
    interface irb0.10 {
        ipv4 {
            address 10.10.10.1/24
        }
    }
}

The anycast gateway address is configured identically on every leaf that hosts the subnet, which removes the need for a first-hop redundancy protocol in the fabric.

BGP EVPN Session

network-instance default {
    protocols {
        bgp {
            group EVPN-LEAFS {
                peer-as 65000
                family evpn {
                    signaling bgp-evpn
                }
                dynamic-neighbors {
                    accept {
                        prefix 0.0.0.0/0
                    }
                }
            }
        }
    }
}

Verification

show network-instance VRF-TENANT-1 protocols bgp-evpn vxlan-tunnel
show network-instance VRF-TENANT-1 bridge-table mac-table all
show tunnel-interface vxlan1 vxlan-tunnel
show network-instance VRF-TENANT-1 protocols bgp neighbor

The vxlan-tunnel output is where you confirm the local VTEP, the VNI, and the peer list. A VNI with a local VTEP but an empty remote list means the EVPN routes are being received but not imported — check the route-target / EVI match. Type-2 MAC routes appearing in the mac-table with a remote VTEP as next hop is the signal that end-to-end overlay learning works.

Cross-Vendor Notes

Because SR Linux expresses the same concepts through a different hierarchy, the useful translation is: mac-vrf ≈ bridge domain + EVI, ip-vrf ≈ VRF, subinterface ≈ SVI or EFP, tunnel-interface ≈ NVE/VTEP interface. If you are migrating configuration, map those four objects first; the rest is BGP EVPN policy, which is largely standard across vendors.

See Nokia SR Linux: CLI Basics and gNMI Configuration for the CLI and commit model, EVPN-VXLAN Data Center Fabric: Design Guide 2026 for the fabric design context, and SR-MPLS vs SRv6: Choosing a Segment Routing Data Plane if you are considering an SR-MPLS underlay instead of plain IP ECMP.

原文链接：https://documentation.nokia.com/srlinux/25-7/books/advanced-solutions/evpn-vxlan-layer-3.html