Hello and welcome to this edition of Wired Assurance. My name is Rohan Chadha, and today I’ll be talking about building an EVPN/VXLAN Campus Fabric in just four steps. Today, we’re going to talk about the deployment of EVPN multihoming topology. I’ll walk you through the different steps that are required, and I can promise you, none of those require any CLI configuration. Everything will be done through the UI, and it’ll be as simple as you can expect it to be. So, let’s just jump right into it and talk about EVPN multihoming.
Before we jump into building the EVPN multihoming topology, let’s understand the building blocks of it from a device perspective. Today, as you can see, we’re going to be using two core devices and two access devices. The EVPN multihoming topology can support up to four core devices, a minimum of two and a maximum of four, and as many access devices as you’d like, but for the purposes of this video, we’ll be using two core devices and two access devices.
To begin with, we click on Organization, and under the Wired tab, we see Campus Fabric. As we click on Campus Fabric, we can see that we are inside the site EVPN Campus Primary1, and there is no Campus Fabric configured at this time. That’s exactly where we’ll begin. Click on Configure Campus Fabric, and we see that there are three topologies that are presented to us. EVPN multihoming, which is collapsed core with ESI LAG; Campus Fabric Core Distribution, which is EVPN core distribution with ESI LAG; and Campus Fabric IP Clos.
What you see on the left side of each of these three names is a small diagram that basically depicts the topology that this entails. You basically have above the line that you see, the horizontal line in the diagram on each of these topologies, above the line is where your EVPN/VXLAN construct exists. What I mean by that is that’s where those devices are, the devices that run EVPN/VXLAN configuration. Anything below the horizontal line are just pure access devices layer to… They have to be non-EVPN/VXLAN-capable devices.
Once you’ve selected the EVPN multihoming, we see that it’s a collapsed core, and what that means is that two or three layers of EVPN configuration is collapsed into just one layer. We’ll jump right in there by giving it a topology name. I’m going to go ahead and call it EVPN-MH. There are two settings that you have to provide on the initial page, and that’s for the overlay and the underlay settings. For overlay, we use IBGP today, and for underlay, we use EBGP. The default values will be presented to you. There is no reason to change it if there isn’t a purpose behind it. 65,000 is the local layers, and 65,001 is the AS Base to begin with for the underlay EBGP, and then we increment sequentially on a device basis starting at 65,001.
The loopback prefix, as you can see, is the prefix that’s used to assign to all the interfaces, all the loopback interfaces on all the devices. These interfaces are used to peer with every other vTap in the Campus Fabric. And then last is the subnet, which is again a default value provided that can be changed by the user. This subnet is used to connect the underlying physical interfaces between the Campus Fabric.
Let’s jump right into the next step and click on Continue. At this step, we’ll be selecting the Campus Fabric nodes in this Campus Fabric configuration. We’ll be selecting two campus cores, and I’ll select Core 1 and Core 3 for this demo. As you can see in this nice dropdown, you have all the information provided to you, and that includes the model as well as the MAC address, so you don’t have to go back and forth between different pages of the UI. Every information is provided right here. For the access devices, I’ll be picking Switch 1 and Switch 2. My core devices are EX4650-48Ys that are EVPN capable. My access devices are EX2300 and 4300 that do not understand EVPN. Hence, I am putting these in an access layer. The platform support on a topology basis is on the website, and we’ve listed every platform that’s supported on a per-layer basis.
Once you’ve selected this topology, we know that there are two core devices, two access devices. I can click on these core devices, and I can see the basic information about Core 1. I see there is a router ID assigned. This router ID is assigned as needed for the loopback interface. As I mentioned earlier, it’s used for peering between the two core devices in case of a collapsed core. The two core devices will act as the two vTaps that basically… they will be forming a VXLAN tunnel between each other. The access switches, on the other hand, do not necessarily need a router ID, but we’ve provided them for consistency’s sake. They do not need it, but let’s go ahead with that.
Step three is basically configuring networks. So, networks are basically VLANs. We’ll go ahead and start creating some new networks here. I’m going to be assigning some generic names here, and I’ll call it MH-VLAN10, and I’ll assign VLAN ID 10, and I’ll give it the subnet 192.168.10.0/24. And I’ll give it a virtual gateway for 192.168.10.1. Now, providing this subnet is the only… I would say this is the second step wherein you’ll be providing us a subnet. The IP addressing for the IRB/SVI interfaces or any IP addressing in the underlying physical interfaces in our fabric is taken care by Mist Wired Assurance Campus Fabric. As a user and administrator, you don’t have to worry about it. So once you’ve provided as a subnet, we’ll take care of all of it.
This virtual gateway will essentially be used as a common address between the two core devices. So, any underlying device, for example, an access switch or any device connected to the access switch, will have its gateway as 192.168.10.1, which will be advertised via EVPN. And that’s why we come in here and manually define it. As you can see, I created a VLAN, VLAN10, and voila, we see two IP addresses that have already been chosen to be assigned for the corresponding IRB/SVI interfaces that will be assigned to Core 1 and Core 3 for VLAN10.
Let’s go ahead and create another one, and we’ll call it MH-VLAN20. But in this case, I’m not going to assign a subnet or virtual gateway, because for this particular VLAN, I want to route on the firewall of the Campus Fabric, so the two core devices that I have will be connected dual-home to a firewall, and I want the routing to happen for this particular VLAN on the firewall. So, I’m going to skip this, and this is basically a bridged overlay design wherein we’ll assign the VNI to the corresponding VLAN20, but we will not be configuring a subnet or a gateway on the two core devices.
This is one way of creating a VLAN. The other way of adding a VLAN to the Campus Fabric is if you have existing network on the site already. So, we’ll click on Existing Network, and what we see is that there is a common VLAN that we already created earlier before we started this demo on an entire site. Using the site configuration here, I created a VLAN called sitewide-vlan with a VLAN ID of 100, and that’s it. What that did was all the devices in that site inherited the sitewide-vlan. I’m going to take sitewide-vlan, and I’m going to add that. Now, I’m told that there is a virtual gateway that is required. Okay. There is a virtual gateway required, so we’ll go ahead and add the virtual gateway. The subnet basically was inherited from the site configuration where I had created VLAN100. I’m being told that the provided gateway is already used.
Okay. So, here we have three VLANs, and as we already see that for two of them, the static IP addresses have already been defined. For VLAN10, there are two IP addresses, code one and code three. Similarly, for sitewide VLAN100, we have two IP addresses, one each for Core 1 and Core 3. And as we already know, VLAN20 doesn’t have a virtual gateway on the collapsed core, so we do not have a gateway for that.
Now, let’s jump into VRF, and understand, this is virtual routing and forwarding, wherein you can create separate routing instances. You can basically increase the security in your network by segregating the VLANs in different routing instances. A different routing instance basically means that there is a different routing table on a per-VLAN basis, or however many VLANs you would like in that particular VRF. We’ll go and assign this name VRF1, and then we’ll add MH-VLAN10 to VRF1. If there is a need, I can always add extra routes within the VRF as well, and that is an option as well. We’ll go ahead and add another VRF called VRF2, and I’ll use sitewide-vlan for this particular VRF2.
The last step on this page is to basically configure the core access port configuration. This is the port configuration towards the access switches from the collapse core. If you read the description, it says this is the ESI LAG configuration, so let’s just assign it a name, and let’s call it ESI LAG. Any name would work, but ESI LAG is what I’ve assigned. We presume that all the VLANs and networks that you’ve defined here are going to be a part of the ESI LAG configuration, and so we automatically add them to the trunk networks. You can come in here and manually change any settings that you would like. If you would like a smaller MTU, or if you would like to manipulate the MTU size here to your environment needs, you can do that. You can enable storm control. You can also enable PoE if that’s a requirement, change the speed, duplex, add native VLAN. All of that is an option that we’ve provided.
This is the last and final step, and what we see here is there are different port panels. These port panels are on a platform basis. For the purposes of this video, we are using EX4650 and two other platforms. We’ll show you the appropriate port panels as needed whenever any platform other than these are used. So, let’s jump right into it, and I’ll go ahead and I’ll configure these interfaces quickly.
What I’ve done at this point is I’ve connected all the… two collapsed core devices with the other two access devices. Basically, the requirement is that there should be two interfaces connected to each other between the two core devices. EVPN multihoming has a requirement for redundancy. And then, Core 1 needs to connect to both access switch 1 and access switch 2. Similarly, Core 3 needs to connect to both access switch 1 and access switch 2. Once those interfaces have been connected here, you’ve told the Mist UI that these are the interfaces, we can proceed, and we can click on continue.
This is the last step, wherein you confirm that the topology changes that you want are there, and if we click on Core 1, we can see that on the right, we see a lot of information about everything that we have done so far. We see the model, we see the router ID, we see the VLANs that we wanted in the Campus Fabric. Along with the VLANs, we also see the IP addresses. I see that there are two IP addresses and three VLANs. One of them doesn’t have an IP address, and that is basically a bridge overlay design, as I mentioned earlier. We also see the connections, by the way. I can see and I can verify here the connections. Connections to collapsed core, Core 3 and access switch 1 and access switch 2.
At any point in this entire step. If you’d like to access the remote shell, we’ve provided you that option as well. So, before you hit Apply Changes, if you’d like to log into your device, you can do that here. You can click on Remote Shell and a popup window will open for you. At this point, you can look at your configuration, you can look at how your devices are connected. I see here that my devices are connected. Core 1 connects to two Core 3 interfaces, and Core 1 has a connection to switch 2 and switch 1 as well. So, a little handy tool here where you can verify by logging into the device. Let’s click Apply Changes and Confirm.
At this time, what has happened is that the configuration that we decided to push to the devices is being pushed and is being committed to the Juniper devices. Right after that’s committed, BGP underlay as well as overlay will be provisioned. Once BGP underlay is provisioned, overlay and the VXLAN tunnels will come up. The VXLAN tunnel will be two-way between collapsed core 1 and collapsed core 2.
Let’s jump right into the switches. While this configuration is happening, we’ll look at what’s the scenario and the switches and the configuration that we pushed under the hood. Remember, everything that we did so far was based on UI. We did not touch the CLI. We did not make any CLI changes manually. You did not have to define the EVPN configuration or the BGP configuration or the underlying physical connectivity. This is the value of Mist Wired Assurance Campus Fabric.
Let’s click on Utilities and click on Download Junos Config. We see that configuration file has been downloaded. This is a handy tool. What this does is it enables us to verify the configuration. All of us have been used to configuring things via the CLI, and so it is very important that we verify that if you’re doing this for the first time, that everything that you want in the configuration should be there. You could be a greenfield environment or a brownfield environment. You should be able to verify your configuration. Let’s dive right into it. Let’s look at this. As we can see, the first thing I see is I see some BGP configuration here. That’s very important. We see the underlay BGP configuration here between the two core devices. There are two peers here on two interfaces. We see the overlay configuration here. Since there’s only one peer for Core 1, and that is Core 3, there is only one neighbor.
We see some EVPN configuration here. We also see the ESI LAG configuration here that was pushed by Campus Fabric. None of that required us to push anything through CLI. We see two LAG interfaces, A0 and A1. A0 is towards switch 1, and A3 is towards switch 2. We see the IRB configuration. As we discussed earlier, IRB10 is the first VLAN that we defined with a gateway, and IRB100 is the third one that was inherited from the sitewide template.
We also see the VRF configuration here. As we can see, there’s VRF1 configuration that has one VLAN, IRB.10. We also have type 5 routes as a part of it. We also see VRF2 configuration. In this VRF2 configuration, what we see is IRB100. The second… I’m sorry, the third VLAN that we chose is also there. And then, if we look at the configuration here, we see all three VLANs, even the VLAN that we made bridged overlay is a part of the configuration, has a VNI. So, we can go ahead and we can assign the gateway for this particular VLAN on either the router of the Campus Fabric or the firewall, based on your environment.
Now that we’ve looked at the configuration, let’s look at how our EVPN Campus Fabric is doing, and what do the EVPN insights tell us? The EVPN insights, it’s basically a pretty layer on top of the campus fabric that tells you about a few green and red links. Those green and red links are not just the interface status. They tell you some good information about your peering in the network. We look that there are a few green links. We see that the status is up, but we see these triangles, and these triangles do not look great.
When I hover over this topology, I am being told that the selected port is not connected to the correct switch port in the Campus Fabric topology. What that basically means is that the backend of the Campus Fabric knows that the Core 1 to Core 3 port that I’ve selected is not the right port, and instead it is something else. It is smart enough to understand that there was another port that should have been connected, but I have connected the wrong port, and that is absolutely right. So, I’m going to jump right into the campus fabric and change that quickly for you guys. I’ll click on Edit Configuration and go right to the last step, and I’ll change the zero to one. We’ll hit Continue, and we’ll apply changes and save them. While the provisioning takes a while, I’ll be right back in a minute.
We’re back. So, as we can see, our pretty green lines are back, and what that means is that we’ve corrected the interface that was not connected the right way. Campus Fabric was smart enough to let us know that the interfaces that were connected between Core 1 and Core 3 were not right. As you can see, I had 0/0/0 earlier, and I switched that over to 0/0/1. After doing that, my BGP neighborship came back. And then, here we can see, if I click on any device, the statistics between the two devices. We can also see, as I mentioned earlier, the VLANs and the IP addresses.
Thank you. This concludes our Campus Fabric demo today. I’ll summarize all the things that we did today in this last 20-25 minute session. We built a Campus Fabric using the Mist UI. None of those steps included anything to do on the CLI. We built a Campus Fabric in four steps, wherein as a step one, we selected the two kind of topology that the user would want. As a second step, we chose the Campus Fabric nodes that will participate in the Campus Fabric. The third step was to provide us the networks that will be participating in the Campus Fabric. And the last and final step was the connectivity of the devices itself. It’s as simple as that.