In part 3, I’ll be setting up the multisite between site 1 and 2 (Site 2 has been pre-configured) using a route server (9K-9) seen in the diagram below.
For part 2, I will be setting up a L3 VNI to allow PC2 (Vlan 100) to communicate with PC3 (Vlan 200) within site 1. Using the same diagram as part 1 below:
Below is the diagram I’ll be working with. For this part, I’ll be setting up site 1 with a simple L2 vxlan allowing PC2 and 3 to communicate.
Disclaimer: This is by no means a complete guide to this setup, but serves only to remind myself of the steps needed for my purposes. If this helps you, great.
First I will bring up a couple simple ubuntu docker containers. I have already setup vlans 10 and 20 in my network within docker using macvlan, so here i’m just assigning them specific IP addresses to use. You’ll also have to use privileged mode on these or else you won’t be able to bring up the tunnels. You will not need to worry about this unless you are using docker containers like I am.
BRIDGE
The bridge network driver will allow containers using the bridge to communicate with each other and provide external connectivity using NAT. Below i create a local bridge, and then run 2 new containers using that bridge
My goal here was to make updating an ACL that is applied on multiple devices as easy as possible. Below is a portion of my vars.yml file just to give an idea of how updates are done:
Going with the same diagram i’ve been using. I’m going to configure an ansible playbook to push out new VNIs to my VXLAN lab
In the last blog post I setup a basic VXLAN config just allowing 2 hosts on separate leaf switches to communicate within their common subnet. In that configuration all of the hosts were learned by the VTEPs from BUM traffic flooded using multicast. Using BGP EVPN, hosts are learned by their own leaf switch and then advertised to the BGP speaking spine switches which reflect them back down to all other leafs. As soon as a leaf switch learns of a host (most likely from that host sending a GARP or some ARP request) it will advertise that host’s information to everyone else. Even when using BGP EVPN arp requests are still sent to all VTEPs using multicast even though the VTEPs have probably already learned about the remote host via BGP. That is where arp suppression comes into play. Arp suppression allows the VTEP to respond to arp requests if the VTEP already knows the remote hosts mac address. There is a bit of upfront work to get this setup though because some switches require you carve up the TCAM to make room for ether-arp.