VLAN over EVPN-VXLAN Configuration

Deliver end-to-end VLAN connectivity between Juniper QFX5100 devices leveraging EVPN with VXLAN encapsulation.

Complete configuration repository on GitHub:

https://github.com/bgphelp/blueprints/tree/master/evpn/vlan-evpn-vxlan-qfx5100

 

Physical Topology

Physical Topology is depicted below. It is comprised of three QFX5100 devices running JunOS version 17.1. Two EX switches simulate customer CE devices.

VLAN over EVPN-VXLAN
VLAN over EVPN-VXLAN Physical Topology

Configuration

Loopback Reachability via IGP

VXLAN encapsulates Layer 2 Ethernet frames into IP before carrying them across the network.

The means that end-to-end IP reachability needs to be established between all Virtual Tunnel Endpoints (VTEP). In our scenario, QFX1, QFX2 and QFX3 will serve as VTEPs, so we’ll start with establishing Loopback IPs are reachable.

You can choose any IGP protocol of your choice, in our example we will be using IS-IS to provide loopback reachability:

 

protocols {
isis {
        level 1 disable;
        level 2 wide-metrics-only;
        interface xe-0/0/46.0 {
            point-to-point;
        }
        interface et-0/0/53.0 {
            point-to-point;
        }
        interface lo0.0;
    } 
}

 

Validate Loopback reachability:

root@qfx2> show route 10.0.0.2

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

10.0.0.2/32        *[Direct/0] 03:10:39
                    > via lo0.0


root@qfx2> show route 10.0.0.3

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

10.0.0.3/32        *[IS-IS/18] 01:29:08, metric 10
                    > to 10.0.1.1 via et-0/0/53.0

 

EVPN IBGP Configuration

EVPN relies on BGP to exchange MAC and IP Reachability information. We will configre IBGP between our QFX devices and activate address-family EVPN.

QFX1:

root@qfx1> show configuration routing-options
router-id 10.0.0.1;
autonomous-system 100;

root@qfx1> show configuration protocols
bgp {
    group IBGP {
        type internal;
        local-address 10.0.0.1;
        family evpn {
            signaling;
        }
        neighbor 10.0.0.3;
        neighbor 10.0.0.2;
    }
}

EVPN Generic Configuration

Now that Loopbacks are reachable and IBGP sessions are established, we will configure remaining EVPN and Switching Option items:

QFX1:

protocols {
    evpn {
        encapsulation vxlan;                  
        multicast-mode ingress-replication;
        extended-vni-list all;
    }
}

switch-options {
    vtep-source-interface lo0.0;
    route-distinguisher 10.0.0.1:100;   
    vrf-target target:100:100;        
}

Interface and VXLAN Configuration

With EVPN fully configured, we can apply VLAN-specific configuration to physical ports.

Depending on port connectivity scenario (single-homed vs multi-homed CE), there will be a slight difference in the configuration.

QFX1 (Single-Homed Site)

Single-Homed CE only requires basic interface configuration.

interfaces {
    ge-0/0/0 {
        flexible-vlan-tagging;
        encapsulation extended-vlan-bridge;
        unit 100 {
            vlan-id 100;
        }
    }

vlans {
    VLAN100 {
        interface ge-0/0/0.100;
        vxlan {
            vni 100;
            ingress-node-replication;
        }
    }
}

QFX2 and QFX3 (Multi-Homed Site):

Multi-homed site requires Ethernet Segment Identifier (ESI) configuration that should be unique per site. This ESI value should be unique for each site.

We are also configuring Aggregate Ethernet interface. Although we could have placed ESI configuration on the physical ge-0/0/0 interface, AE will be useful in the future if you decided to augment the capacity and add more links to customer’s site. Creating AE bundles with a single link is a common practice employed by many service providers.

ge-0/0/0 {
    ether-options {
        802.3ad ae0;
    }
}

ae0 {
    flexible-vlan-tagging;
    encapsulation extended-vlan-bridge;
    esi {
        00:00:00:00:00:00:00:00:01:00;
        all-active;
    }
    unit 100 {
        vlan-id 100;
    }
}

vlans {
    VLAN100 {
        interface ae0.100;
        vxlan {
            vni 100;
            ingress-node-replication;
        }
    }
}

Service Validation

In order to validate the service and make sure that Ethernet Switching tables are populated, we will run End-to-End ping test between CE Devices.

Assuming that Ping was successful, you can check EVPN-related information on your QFX devices.

Validate Ethernet Switching Table

In our topology, we have four distinct MAC address learning scenarios:

  • Locally-learned MAC on physical Ethernet interface (EX2’s MAC on QFX1)
  • Locally-learned MAC on aggregate Ethernet interface (EX1’s MAC on QFX2 and QFX3)
  • Remote MAC for single-homed CE (EX2’s MAC on QFX2 and QFX3). Juniper uses logical VTEP interface in this scenario.
  • Remote MAC for dual-homed CE (EX1’s MAC on QFX1). Juniper uses virtual Ethernet Segment Identifier (ESI) interface in this scenario.
root@qfx1> show ethernet-switching table

 
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static

           SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)


Ethernet switching table : 2 entries, 2 learned
Routing instance : default-switch
   Vlan                MAC                 MAC      Logical                Active

   name                address             flags    interface              source

   VLAN100             f4:b5:2f:53:2b:03   DR       esi.1732               00:00:00:00:00:00:00:00:01:00

   VLAN100             f4:b5:2f:53:2b:06   D        ge-0/0/0.100

 

 

root@qfx2> show ethernet-switching table
...


Ethernet switching table : 2 entries, 2 learned
Routing instance : default-switch
   Vlan                MAC                 MAC      Logical                Active
   name                address             flags    interface              source

   VLAN100             f4:b5:2f:53:2b:03   DR       ae0.100

   VLAN100             f4:b5:2f:53:2b:06   D        vtep.32770             10.0.0.1

Validate EVPN Table and Routes Advertised / Received via IBGP

Use the following commands to validate local routing table and advertised/received routes:

show route table BD100.evpn.0

show route advertising-protocol bgp 10.0.0.2 extensive

show route receive-protocol bgp 10.0.0.2 extensive

show route table bgp.evpn.0

You should observe Type 1, Type 2, Type 3 and Type 4 routes as shown below.

Type 1 (Ethernet Auto-Discovery routes)

bgp.evpn.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

* 1:10.0.0.2:0::0100::FFFF:FFFF/304 AD/ESI (1 entry, 0 announced)
     Import Accepted
     Route Distinguisher: 10.0.0.2:0
     Route Label: 1
     Nexthop: 10.0.0.2
     Localpref: 100
     AS path: I
     Communities: target:100:100 encapsulation:vxlan(0x8) esi-label:all-active (label 0)

* 1:10.0.0.2:100::0100::0/304 AD/EVI (1 entry, 0 announced)
     Import Accepted
     Route Distinguisher: 10.0.0.2:100
     Nexthop: 10.0.0.2
     Localpref: 100
     AS path: I
     Communities: target:100:100 encapsulation:vxlan(0x8)

Type 2 – MAC/IP Advertisement routes

Single-homed site advertisement as signified by ESI = 0.

 

* 2:10.0.0.1:100::100::f4:b5:2f:53:2b:06/304 MAC/IP 
 BGP group IBGP type Internal
     Route Distinguisher: 10.0.0.1:100
     Route Label: 100
     ESI: 00:00:00:00:00:00:00:00:00:00
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] I
     Communities: target:100:100 encapsulation:vxlan(0x8)

Type 3 – Inclusive Multicast Ethernet Tag route

* 3:10.0.0.1:100::100::10.0.0.1/304 IM (1 entry, 1 announced)
 BGP group IBGP type Internal
     Route Distinguisher: 10.0.0.1:100
     Route Label: 100
     PMSI: Flags 0x0: Label 100: Type INGRESS-REPLICATION 10.0.0.1
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] I
     Communities: target:100:100 encapsulation:vxlan(0x8)
     PMSI: Flags 0x0: Label 6: Type INGRESS-REPLICATION 10.0.0.1

Type 4 – Ethernet Segment route

4:10.0.0.3:0::0100:10.0.0.3/304 ES
                   *[BGP/170] 00:46:04, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 10.0.1.1 via et-0/0/53.0

Complete configuration repository on GitHub:

https://github.com/bgphelp/blueprints/tree/master/evpn/vlan-evpn-vxlan-qfx5100

For more information on EVPN, please refer to our other articles on this topic:

http://www.bgphelp.com/tag/evpn/

Leave a Reply

Your email address will not be published. Required fields are marked *