Streamline EVPN Configuration with Virtual-Switches

Juniper offers three main methods of mapping EVPNs and VLANs. The typical routing-instance per VLAN model is popular but comes with a couple downsides: hardware tunnel limit scale and tedious configuration. Another option to consider is using virtual-switches.

Figure 1: VLAN-Based Service

Figure 2: VLAN Bundle Service

Figure 3: VLAN-Aware Bundle Service

Here is the topology we will be using today

The three EVPN service modeling techniques are pictured above. Lets take a look at VLAN-based service models.

EVPN-316 {
    instance-type evpn;
    protocols {
        evpn {
            mac-table-size {
                300;
            }
            interface-mac-limit {
                300;
            }
            mac-statistics;
        }
    }
    interface ge-0/0/8.316;
    route-distinguisher 10.255.255.103:316;
    vrf-target target:65000:316;
}
EVPN-317 {
    instance-type evpn;
    protocols {
        evpn {
            mac-table-size {
                300;
            }
            interface-mac-limit {
                300;
            }
            mac-statistics;
        }
    }
    interface ge-0/0/8.317;
    route-distinguisher 10.255.255.103:317;
    vrf-target target:65000:317;
}

In an environment where we have dozens or hundreds of EVPNs, creating a routing-instance per VLAN is arduous. Option 2 is to use VLAN-bundled services, but do we really want to share mac-learning domains? Instead, lets hop to option 3; VLAN-aware bundled services.

#interfaces
ge-0/0/5 {
    flexible-vlan-tagging;
    encapsulation flexible-ethernet-services;
    unit 0 {
        family bridge {
            interface-mode trunk;
            vlan-id-list 100-101;
        }
    }
}

#routing-instances
EVPN-NET {
    instance-type virtual-switch;
    interface ge-0/0/5.0;
    bridge-domains {
        VLAN100 {
            domain-type bridge;
            vlan-id 100;
            routing-interface irb.100;
            bridge-options {
                interface ge-0/0/5.0;
            }
        }
        VLAN101 {
            domain-type bridge;
            vlan-id 101;
            routing-interface irb.101;
            bridge-options {
                interface ge-0/0/5.0;
            }
        }
    }
    route-distinguisher 10.255.255.103:100;
    vrf-target target:65000:100;
}

Very neat! Now we can have a single routing-instance and simply add VLANs to the instance and interfaces as needed. But.. something about this seems scary to me. Do we really want to put the entire EVPN service model in a single routing-instance? It's probably fine, but I think we can compromise and group VLANs together based on their intent.

#interfaces
ge-0/0/5 {
    flexible-vlan-tagging;
    encapsulation flexible-ethernet-services;
    unit 0 {
        family bridge {
            interface-mode trunk;
            vlan-id-list 316-317;
        }
    }
    unit 1 {
        family bridge {
            interface-mode trunk;
            vlan-id-list 100-101;
        }
    }
}

#routing-instances
EVPN-INET {
    instance-type virtual-switch;
    protocols {
        evpn {
            extended-vlan-list 316-317;
        }
    }
    interface ge-0/0/5.0;
    bridge-domains {
        V316 {
            domain-type bridge;
            vlan-id 316;
        }
        V317 {
            domain-type bridge;
            vlan-id 317;
        }
    }
    route-distinguisher 10.255.255.101:1000;
    vrf-target target:65000:1000;
}
EVPN-MGMT {
    instance-type virtual-switch;
    protocols {
        evpn {
            extended-vlan-list 100-101;
        }
    }
    interface ge-0/0/5.1;
    bridge-domains {
        V100 {
            domain-type bridge;
            vlan-id 100;
        }
        V101 {
            domain-type bridge;
            vlan-id 101;
        }
    }
    route-distinguisher 10.255.255.101:2000;
    vrf-target target:65000:2000;
}

Whoa– a single interface with two sub-interfaces each in a different virtual-switch routing-instance acting as ethernet trunks, very neat. By using this method, you can reduce the tedious task of creating 1-1 EVPNs, gain the benefits of the VLAN aware model, and still feel good about not putting all your eggs in one basket.