Hi All

This time we will be looking at EVPN, its configuration on JunOS and how it is different from VPLS.

Currently if service provider has to join customer’s multiple sites via Layer 2, only option is VPLS. VPLS can be LDP based or BGP based.

BGP based VPLS has advantages that you can use RRs to scale however VPLS as a whole has a disadvantages that:

• We can’t do active-active multihoming with both links from CE to PE.
• Control plane MAC-Learning is not possible.
• L2 Loop detection is not possible.
• VPLS consumes less in control plane however more MPLS labels (because MAC learning relies on a different label for each remote site) than EVPN.

EVPN is immune to all the above problems and it’s only based upon BGP so we don’t have to fight between LDP vs BGP advantages.

Underlying EVPN can be used with VXLAN or MPLS however solution which I am going to discuss is based upon MPLS.

Look at the diagram below. We have 3 sites basically 3 VMs all part of same IP Network and they are connected to same EVPN instances on 3 different Juniper routers via switch in their path.

Let’s see config on Manchester Juniper PE router.

You can see its fairly straightforward config with same parameters as L3VPNs except instance-type is evpn and we need to use protocols evpn to define parameters to limit the mac and ip if we want.

write@re1.Manchester > show configuration routing-instances evpn-1
instance-type evpn;
vlan-id 1200;
interface xe-1/0/0:0.1200;
route-distinguisher 10.198.206.41:1200;
vrf-target target:2856:1200;
protocols {
 evpn {
 interface-mac-limit {
 1000;
 packet-action drop;
 }
 interface-mac-ip-limit {
 1000;
 }
 interface xe-1/0/0:0.1200;
 label-allocation per-instance;
 }
}

From RR point of view, we need to add family evpn under BGP on all PEs and RR.

write@re1.Manchester > show configuration protocols bgp
path-selection external-router-id;
advertise-from-main-vpn-tables;
log-updown;
drop-path-attributes 128;
authentication-algorithm md5;
vpn-apply-export;
tcp-mss 4096;
group LAB-RR {
 type internal;
 local-address 10.198.206.41;
 family inet-vpn {
 unicast;
 family l2vpn {
 signaling;
 }
 family evpn {
 signaling;
 }
 neighbor 10.198.206.46;
}

We will be doing the same configs on rest 2 PEs.

write@re1.Manchester > show evpn instance evpn-1 extensive
Instance: evpn-1
 Route Distinguisher: 10.198.206.41:1200
 VLAN ID: 1200
 Per-instance MAC route label: 119
 Per-instance multicast route label: 120
 Duplicate MAC detection threshold: 5
 Duplicate MAC detection window: 180
 MAC database status Local Remote
 MAC advertisements: 1 2
 MAC+IP advertisements: 1 2
 Default gateway MAC advertisements: 0 0
 Number of local interfaces: 3 (3 up)
 Interface name ESI Mode Status AC-Role
 et-1/1/0.1200 00:00:00:00:00:00:00:00:00:00 single-homed Up Root
 xe-1/0/0:0.1200 00:00:00:00:00:00:00:00:00:00 single-homed Up Root
 xe-1/0/0:0.1210 00:00:00:00:00:00:00:00:00:00 single-homed Up Root
 Number of IRB interfaces: 0 (0 up)
 Number of protect interfaces: 0
 Number of bridge domains: 1
 VLAN Domain ID Intfs / up IRB intf Mode MAC sync IM route label SG sync IM core nexthop
 1200 3 3 Extended Enabled 120 Enabled
 Number of neighbors: 4
 Address MAC MAC+IP AD IM ES Leaf-label
 10.198.206.42 0 0 0 1 0
 10.198.206.43 1 1 0 1 0
 10.198.206.44 0 0 0 1 0
 10.198.206.45 1 1 0 1 0
 Number of ethernet segments: 0

Some key take away from above is that due to config “label-allocation per-instance” we are seeing one MPLS Label for the whole EVPN routing instance.

write@re1.Manchester > show route table mpls.0 label 119
mpls.0: 45 destinations, 45 routes (45 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

119 *[EVPN/7] 3d 20:05:21, routing-instance evpn-1, route-type Ingress-MAC, vlan-id 1200
 to table evpn-1.evpn-mac.0

ESI (Ethernet Segment Identifier) is all zeros for PE which is single homed to CE. In active-active multihoming, an Ethernet segment appears as a LAG to the CE device.

Let’s check the mac-table on PE. So you can see   00:0c:29:34:04:26 is learned dynamically by Manc PE over xe-1/0/0:0/1200 interface. This is still Data Plane learning and with EVPN there is no difference. However look at MAC Flags for other 2 MAC addresses. DC corresponds to Dynamic Control MAC means they are learned via Control Plane (using BGP)

write@re1.Manchester > show evpn mac-table instance evpn-1
MAC flags       (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC, P -Pinned MAC)
Routing instance : evpn-1
Bridging domain : __evpn-1__, VLAN : 1200
MAC                         MAC      Logical          NH     MAC         active
address                    flags    interface        Index  property    source
00:0c:29:34:04:26   D        xe-1/0/0:0.1200
00:0c:29:37:55:3d   DC                        1048585            10.198.206.43
00:0c:29:55:5a:45   DC                        1048584            10.198.206.45

Evpn has also learned the IP Address and added in arp-table so you can see MAC/IP Association.

write@re1.Manchester > show evpn arp-table instance evpn-1
INET MAC Logical Routing Bridging
address address interface instance domain
10.10.10.3 00:0c:29:34:04:26 xe-1/0/0:0.1200 evpn-1 __evpn-1__
10.10.10.4 00:0c:29:37:55:3d evpn-1 __evpn-1__
10.10.10.2 00:0c:29:55:5a:45 evpn-1 __evpn-1__

Same thing you can see in routing table as well.

There are several types of routes in EVPN, Type 1, 2, 3, 5, 6 etc.. Type 2 is MAC and IP Route which shows relationship between them however Junos shows that also in 2 ways. Type 2 route as pure MAC and type 2 route as MAC/IP.

Type 3 routes are required for Broadcast, Unknown Unicast and Multicast (BUM) traffic delivery across EVPN networks. Type 3 advertisements provide information about P-tunnels that should be used to send BUM traffic. Without Type 3 advertisements, ingress router would not know how to deliver BUM traffic to other PE devices that comprise given EVPN instance.

write@re1.Manchester > show route table evpn-1
evpn-1.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2:10.198.206.41:1200::1200::00:0c:29:34:04:26/304 MAC/IP
 *[EVPN/170] 3d 19:18:39
 Indirect
2:10.198.206.43:1200::1200::00:0c:29:37:55:3d/304 MAC/IP
 *[BGP/170] 1d 02:03:17, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.2 via xe-0/0/0:1.0
2:10.198.206.45:1200::1200::00:0c:29:55:5a:45/304 MAC/IP
 *[BGP/170] 03:13:24, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.14 via et-0/1/0.0, Push 945
2:10.198.206.41:1200::1200::00:0c:29:34:04:26::10.10.10.3/304 MAC/IP
 *[EVPN/170] 3d 19:18:34
 Indirect
2:10.198.206.43:1200::1200::00:0c:29:37:55:3d::10.10.10.4/304 MAC/IP
 *[BGP/170] 01:53:03, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.2 via xe-0/0/0:1.0
2:10.198.206.45:1200::1200::00:0c:29:55:5a:45::10.10.10.2/304 MAC/IP
 *[BGP/170] 03:13:24, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.14 via et-0/1/0.0, Push 945
3:10.198.206.41:1200::1200::10.198.206.41/248 IM
 *[EVPN/170] 6d 22:17:38
 Indirect
3:10.198.206.42:1200::1200::10.198.206.42/248 IM
 *[BGP/170] 03:13:24, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.14 via et-0/1/0.0
3:10.198.206.43:1200::1200::10.198.206.43/248 IM
 *[BGP/170] 1d 02:03:17, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.2 via xe-0/0/0:1.0
3:10.198.206.44:1200::1200::10.198.206.44/248 IM
 *[BGP/170] 1d 02:03:17, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.6 via xe-0/0/0:2.0
3:10.198.206.45:1200::1200::10.198.206.45/248 IM
 *[BGP/170] 03:13:24, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.14 via et-0/1/0.0, Push 945

 

Let’s do a ping test from VM (10.10.10.4) connected to London to VM (10.10.10.3) connected to Manchester PE via EVPN Network.

For completeness, I have shown the arp-table for London EVPN-1.

write@re0.London > show evpn arp-table instance evpn-1
INET MAC Logical Routing Bridging
address address interface instance domain
10.10.10.3 00:0c:29:34:04:26 evpn-1 __evpn-1__
10.10.10.4 00:0c:29:37:55:3d xe-0/2/0.1200 evpn-1 __evpn-1__
10.10.10.2 00:0c:29:55:5a:45 evpn-1 __evpn-1__

You can see Ping works without any loss.

So that’s all for EVPN. Let me know if you have any queries and I hope to show you more in next blogs about EVPN.

BBye 🙂

Mohit