Contrail Integration with Bare Metal Devices via EVPN-VxLAN

In this blog we will discuss how to integrate Bare metal devices with Juniper Contrail (SDN Controller) by using EVPN-VXLAN.

My earlier blogs on Contrail can be viewed on links  Blog-1, Blog-2 ,

Reference Topology  

Problem statement “Gust VM spawned inside SDN environment needs to communicate with Bare Metal Device (same sub net or different sub net here we will discuss former use case only).

Solution “EVPN based control plane will be established between MX Router and Contrail Controller to exchange ARP entries between them,  VxLAN based forwarding plane will be configured for communication between Guest VMs and Bare Metal Devices”

Solution components:-

1. Contrail GUI
   • RED network 2.2.2.0/ is configured and VMs are spawned using open stack “Horizon” Web GUI (not covered in this article)
   • Configure VxLAN as 1st encapsulation method under “Encapsulation Priority Order” go to Configure then  Infrastructure  then Global Config and click edit button.
   • Select VxLAN Identifier Mode as “user configured”
   • Configure VxLAN ID & Route target community  for the desired network
     • Go to Configure  then Networking  then Networks, select the desired network and click edit
     • Add the VxLAN ID (in this example 2000 is used for RED subnet) under Advanced Option
     • Add the route target community which is 200:1 for the RED network
2. MX Router
   • A Routing Instance “instance type virtual switch” configured “RED-EVPN”
   • Protocol EVPN configured inside routing-instance.
   • Bridge domain 200 and VxLAN VNI ID 2000 under EVPN routing instances
   • Physical port connected with Bare metal devices configured as access port with domain member 200.
   • Route target community on  Virtual-Switch routing instance must match with route target community assigned to RED sub net in Contrail GUI
   • Forwarding plane functionality needs valid route pointing to compute nodes in inet.3 routing table of MX gateway. (If we recall VPN stuff in Junos, next-hop lookup for VRF is always in inet.3. )
   • There are two methods to achieve this  goal:-
     • Adding route in inet.3 RIB dynamically through GRE tunnel.
     • Adding route in inet.3 RIB statically.
   • I choose to go with both methods at same time for following reasons:-
     • Consider that we need to push external routes toward Contrail from MX gateway, in this case MPLS over GRE forwarding plane will be required which is dependent on dynamic GRE tunnel.
     • At same I need EVPN-VXLAN extension from Contrail to  MX gateway for integration of bare metal devices connected on MX router, for this use case I wanted to avoid GRE tunnel to be used in forwarding plane, so adding static route in inet.3 RIB helped me.

Configuration 

admin@ER> show configuration routing-instances RED-EVPN
vtep-source-interface lo0.101;
instance-type virtual-switch;
interface ge-1/1/9.0;                   ##interface connected with bare metal device##
route-distinguisher 192.168.240:1;
vrf-target target:200:1;
protocols {
evpn {
encapsulation vxlan;
extended-vni-list 2000;
multicast-mode ingress-replication;
}
}
bridge-domains {
vlan200 {
domain-type bridge;
vlan-id 200;
routing-interface irb.200;     ##Optional
vxlan {
vni 2000;
ingress-node-replication;
}
}
}

admin@ER> show configuration routing-instances RED

##VRF configuration is optional , this use case is already covered in my earlier bog 

instance-type vrf;
interface irb.200;
interface lo0.1;
route-distinguisher 200:1;
vrf-target target:200:1;       ##Route target is matching with virtual switch route target
vrf-table-label;

admin@ER> show configuration interfaces ge-1/1/9
unit 0 {
family bridge {
interface-mode access;
vlan-id 200;
}
}

admin@ER> show configuration routing-options dynamic-tunnels to-contrail
source-address 101.101.101.101;
gre;
destination-networks {
192.168.243.0/24;
}
admin@ER> show configuration routing-options rib inet.3
static {
route 192.168.243.0/24 receive;
}
admin@ER> show route table inet.3

inet.3: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
192.168.243.0/24 *[Static/5] 1d 02:04:03 ##static route added in inet.3 , will be used for EVPN-VXLAN
Receive
[Tunnel/300] 1d 02:02:07
Tunnel
192.168.243.50/32 *[Tunnel/300] 1d 02:02:07 ##Dynamic routes added in inet.3 , will be used for MPLS over GRE forwarding plane
> via gr-0/0/0.32770
192.168.243.51/32 *[Tunnel/300] 1d 02:02:07
> via gr-0/0/0.32769
192.168.243.52/32 *[Tunnel/300] 10:58:22