Deployment of Campus Fabric IPCLOS

Hello and welcome to this edition of Wired Assurance. My name is Rohan Chadha, and I’m a part of the product management team at Mist. Today, we’re going to talk about Deployment of Campus Fabric IP Clos with Wired Assurance. IP Clos is one of the three topologies supported by Juniper for campus environments. There are different benefits of using IP Clos, it depends on your network environment needs, and today, we are going to talk about how to deploy it in four steps. I assure you that none of these four steps will involve any CLI configuration, and we’ll do everything through the UI to quickly build this Campus Fabric in just four steps. So let’s jump right into it and see how to deploy Campus Fabric IP Clos.

So before I talk about the building blocks of Campus Fabric IP Clos, I want to give you a heads-up that if you are here and you do not know what IP Clos topology is, I recommend you go watch the other video by Rick Bartosik, in which he clearly explains the building blocks of IP Clos. Is IP Clos a suitable topology for your environment or should you go with something different like an EVPN Multihoming or a Campus Fabric Core Distribution? One of the benefits of IP Clos is that you can extend EVPN VXLAN configuration to the edge. And what that means is that, if you have devices that need EVPN VXLAN or if they’re supported, then you can tunnel your devices directly to the access layer. One other benefit, and a great one is GBP, you can use segmentation using tags on the access layer.

In this video, we are not going to talk about GBP, this is purely about the deployment of IP Clos using Wired Assurance. So let’s jump right into it and look at the devices we are going to use today for IP Clos. So I’m going to use two QFX10002s as my core devices, and I’m also going to use two QFX5120-48Y as distribution devices. And just for the purposes of this video, I’ll be using one access device, which is a virtual chassis. And virtual chassis is supported by the way for a few platforms like EX4400 in EVPN VXLAN. And so we are going to use that virtual chassis as an access switch. Let’s jump right into it. Let’s click on organization, and under the wired tab, I see Campus Fabrics, so I’ll go ahead and click on that.

As I see that in this particular topology, I do not have a Campus Fabric that’s configured for the site. There are two kinds of EVPN configurations that you can build. Two kinds of Campus Fabrics, basically. One is a site-based, the other one is an organization based topology. A site-based topology is where you use a handful of devices, but all of the devices are in a certain site. In an org based topology that you can come in and build here, you build topologies on an organization level. So you have one big topology that have different pods from multiple sites. Each pod represents a site and there are core devices that are common to the entire organization and they can be from any site. But, for the purposes of this video to keep things simple, my plan today is to just talk about IP Clos on a site-based level. So I’ll go back and I’ll help you configure a Campus Fabric IP Clos topology.

So let’s configure Campus Fabric as usual, and as you’ve seen before, a Campus Fabric IP Clos is option number three that’s presented. At the time of making this video, this topology is still in beta phase. So let’s give IP Clos topology a configuration name here. So I’ll just call it EVPN hyphen IP Clos, any name as is fine. There are two options that I have. Do I want to route a distribution or do I want to route at edge? Before I actually get into the details of routing, let’s talk about how an IP Clos topology looks like or how it could possibly look like for different customers. If you can see my cursor being hovered over this particular little diagram on the left side next to campus hub with IP Clos, you’ll see that there are three layers and a full mesh. What that represents is every core device is connected to every distribution device and every distribution device is connected to every access device.

And we are traditionally the L3s at the edge, and edge basically means the access device. However, there is also an option that you can route at distribution. And what that means is that your gateways, your IRB/SVI interfaces will reside on the distribution. By default, if you do not make any changes, your IRB/SVI interfaces will be on your access devices. There are different benefits, as I mentioned earlier, of using IP Clos. It’s primarily used for east west traffic, but as I said, if you want the details of what IP Clos really is, go and watch Rick’s video and he explains that in great detail and why you should use it. So, once you’ve selected the topology name and you’ve made ensured that you want to route at the edge, there are a few default settings like overlay and underlay.

These values that you see here are default and you do not have to change it if there isn’t a need. At the time of making this video. We are doing iBGP for overlay and eBGP for underlay. So 65,000 will be your AS for all the devices that are part of the fabric for overlay, and then 65,001 and an incremental sequence will have devices that will be given the AS number going forward. As a user, you do not have to configure any of these changes in the CLI. The Campus Fabric feature will take care of everything.

The next step is to ensure that this is the loop back prefix that you want. This is /24. This is basically the prefix that we assigned to the loopback interfaces for all the devices participating in IP Clos. This loopback interface is used to peer with every other device in the overlay. Essentially every device that is a VTEP for EVPN VXLAN has to pair with the other device for the control plane. And the next step that you see is the subnet that’s required for the underlay IP addressing. This is basically, if I have two core devices, two distribution and three IP Clos. As a user, you do not have to do any manual IP addressing, and that’s the best part about this feature. Campus Fabric will take care of all of the IP addressing, just provide us a subnet and we’ll take care of that.

So let’s click continue and move on to the next step. This next step includes selecting Campus Fabric Nodes. As you can see, the step one is selecting a Service Block Border. So what exactly is a Service Block? Well, if you are someone who wants to keep your spines, your core devices is lean spines, meaning you do not want your core devices to connect to the router, the firewall, or you do not want to use any services connected to the core such as DHCP, DNS, et cetera, you can have a separate Service Block. In that Service Block you can have one to two baud switches, and you can make all of that connectivity in the Service Block. However, this is not a requirement, this is an added feature wherein if you want to have a Service Block, you can do that. For the purposes of this video and to make things simple, I will be using the Core as a border device, meaning that any services or any sort of WAN of firewall connectivity will be on the core device.

So as you see, I get this validation error that says that at least one distribution switch is required. So what this means is that, having the core layer is not mandatory. And what that means is that you can have a smaller IP Clos design. If you’re someone who is interested in IP Clos because you want GBP or you want your access points or your other devices are VXLAN capable and you want to form a tunnel, but you want to keep the topology small, you can skip the core layer and have just distribution and access layer. But, if all of those requirements are there, but you still would want to have a bigger topology, have a core layer, click on the core devices and select a few switches. So I’m going to select Core-1 and Core-2 as I mentioned earlier for the core layer. For distribution, I’m going to be selecting Distribution-1 and Distribution-2.

As you can see with just a click of a button, I have this nice little popup that gives me the inventory of this site and also tells me which devices are suitable for every layer. The last step is just the access switches. I’m just going to be using just one access switch for the purposes of this video. Once you’ve ensured that you’ve selected these devices, you can always, before going onto the next step, you have to ensure that you’ve selected the Router ID and you’ve selected the access switches and ensure that they are connected. And one thing that I’d like to mention here is before we proceed is you can always come back and expand your topology horizontally. And what that means is that, as your network needs grow, you can always come in and add access switches and you can add distribution switches to expand your topology. So let’s hit continue and go to the next step.

At this step you’ll be configuring networks. Networks are basically your VLANs/bridge domains. You can either create a new network or you can add an existing network. I’ll go ahead and create a new network and in this case I will be calling the network EVPN-VLAN10, this is just a name. Give it a VLAN ID and I’ll go ahead and give it a subnet, along with a Virtual Gateway. You can always come and add an existing network as well, and what that means is that, if you have networks that you configured on a site level, under site switch configuration, so if you configure a VLAN/Network there, it’ll be propagated to all the devices on a certain site. So, if this particular site has other VLANs, you can always come in and inherit those. You do not have to manually configure a VLAN again, and that’s the best part about this.

So, I’ll go ahead and I’ll select these two VLANs. What you can also do is, you can import a few VLANs from a certain template. If you have a few templates that you’ve built in the past however, those templates are either not being used or even if they are being used, you can always inherit few VLANs from those particular templates. So I’ll go ahead and select this. There is only one VLAN that’s part of this particular template. I’ll go ahead and select that as well. And so I’m being told that VLAN 130 doesn’t have a subnet, so I’ll go ahead and assign a subnet.

So, at the time of making this video, we are doing a centrally routed and bridged topology, and what that means is that even though I’m routing at the access, we are still using a virtual gateway. There is also another way that I’m not going to talk about this video, but it is there, which is you can do any cast. And what that means is that, if you have multiple access switches, every VLAN will have the same IP address on all the devices. We can talk about that in another video, but to keep things simple, I’ll just do what what’s being shown here, and every VLAN will have a virtual gateway. This particular virtual gateway will reside on all the access switches. However, since we have only one access switch, in this case, that will be the case. So, the second step is to use VRF Configuration, which is basically, you can segregate your networks using VRFs.

What that means is that if you’re someone who wants more security between bridged domains, you want to keep the routing tables separate, you can use virtual routing and forwarding. You very simply use click on, add a VRF instance, give it a name and just assign a VLAN. To keep the configuration simple, I will use only one VLAN for VRF, and I’ll keep the rest in the default routing instance. However, there is no limit to how many VLANs you can add to a routing instance. Let’s click continue and let’s go to the last step. The last and final step is the selection of ports, wherein you’ll be telling us how these devices are connected to each other, and how we should be doing the mapping in the backend. So while I go ahead and do the connection for all these devices, sit tight and I’ll be fast forwarding this video and get back to you soon.

So I’ve selected all these port and I have told Campus Fabric how to connect core to distribution and then distribution to access. As you can see, this is a virtual chassis and it’s very well-supported. So now that we’ve selected it and all the requirements are complete and we see some green lights here, let’s go ahead and hit continue and just confirm that everything that you wanted to do is straightforward. So if I click on any device, I’ll see the VLANs and the corresponding names. I do not see any IP addresses here, of course, because the IP addresses exist at the access layer.

So I can see that VLAN 10 has this particular IP assigned to it, and similarly other VLANs as well. I can always verify my connections, the distribution as well add this layer. So, what I also see is I see a little blob here that says Remote Shell. Before hitting continue and applying changes, you can always click on the Remote Shell and you can always, rather than logging out of band or logging in out of band or having SSH connection, we provide you this option wherein you can verify anything that you like.

You want to verify that your connections are the way they look or if you’re running a Brownfield Environment, and what that means is, if you have an existing Campus Fabric before you hit apply changes, and you want to ensure that none of your configurations are overwritten. If you’re moving from an existing, manually CLI configured Campus Fabric to a Mist configured Campus Fabric, this is the place for you. Hit Remote Shell, ensure that this is everything that you wanted and then go and hit apply changes. So, I hit apply changes, I’m being asked if everything is okay and I hit confirm.

So at this point my EVPN IP Clos topology is complete. All the configurations will be pushed at this point. All of my devices that were a part of the EVPN configuration that I used in the Campus Fabric are being managed as I can see. And what that basically means is that as soon as I hit confirm on Campus Fabric, all of the configuration will be pushed right away. It probably takes a few seconds for Junos to commit and then a few seconds to a few minutes for BGP underlay and overlay to come up and form tunnels between all of these devices, from core to distribution and then to access.

So, you may ask, how do I know what configuration has been pushed? I want to ensure that everything that I wanted on the devices there, and we have an answer for you. So, you can always come in here, click on utilities and look at Download Junos Config. It basically downloads a file locally on your system and on this file you can see everything that has been pushed by Campus Fabric. As you can see, I have the BGP configuration underlay as well as overlay. I also have the interface configuration that was wanted.

I also see the policies that are defined, along with the switch options for EVPN configuration as well. Now this is the core device. The device of interest in an IP Clos is an access switch. So let’s look at the access switch. This is a virtual chassis as I mentioned earlier. Just click on utilities, download the Junos Config, and let’s look at what’s being pushed over here. So as I see I have the underlay and overlay configuration, I have the EVPN configuration, I also have all the gateways that I wanted. As we see the routing instances, the VRF configuration has been pushed as well along with the other VLANs that we wanted. There are a few other VLANs as well, and those VLANs were already a part of the device configured through the Mist UI as you can see here.

So all in all, what we noticed is that as a user, everything that you were supposed to do in a day or something that would take two to four days has been done automatically by Campus Fabric. All you had to do was provide just a few steps and given a few information about the networks, the connectivity between the devices and if you intend to use VRF or not. So now that we’ve defined how to build the Campus Fabric, we’ve also seen what the configuration looks like, we want to ensure and go back and see that how does it look from a monitoring standpoint. So, as we can see on this screen, I see the last configuration timer, everything seems updated. I know that there were no failures here between these devices.

My distribution devices look good and that tells me that the configuration has been pushed and has been reported back to the Clos. So click on organization, let’s go to Campus Fabric and let’s click on this topology that we just created. I have a topology ID, I have a name, and then I have a date and time that it was created at. Let’s click on it and see what we see here. So I see our two Core devices and then the distribution links these devices as well.

When I click on it, I see some green links. Now these green links are not just your link status if there is a BGP issue, and what I mean by that is, if there is a flap in your environment, you’re going to see some EVPN insights wherein you’ll be told that there is a [inaudible] change. Also, if you have connected the devices wrongly as in, if distribution was connected to access via G 0-0-0, and if you were to say G-0-0-1, you’ll be told about it right away. And I’ll try to give an example of that really soon here. So we know that everything looks good. Let’s click on switch insights and see if we see any events here. So as I can see, I see a BGP peer state change. This tells me that BGP went from OpenConfirm to established, even though I know looking at the green links, I just wanted to come in here and see that as one of the ways to verify that BGP indeed came up.

Okay. So now that we’ve built the topology, you’ve seen how the configuration looks like. Let’s talk about the day two of Campus Fabric. What happens when you build the topology? So I’m going to show you some Campus Fabric insights that we’ve built. This is not all encompassing, but this is what we support today and with a plan to support much more. So, this is a topology that we’ve built earlier. What I did earlier was, after I showed you the topology, I went in and I selected some ports that weren’t correct, meaning that from the link from Core to distribution was XE, but I selected that as GE, and similarly I selected a wrong port between a distribution and access.

And what that tells us that, the Campus Fabric is very smart. It will tell us that the selected port that I configured is not the right port, and it knows that through the LLDP neighbors, it can read it, and it tells you that I know that the Distribution-2 to Core-1 port is a different port, and what you’ve told me in your configuration when you selected the ports on step four is the wrong port, so please go ahead and fix it. And that’s exactly what it is. I see the same thing here, I see a BGP flap because BGP was working earlier, and now BGP went from established to idle. A similar scenario wherein the selected port is not the right port. This is one of the things within EVPN insights. One of the other things that I want to show you is the difference between the thick green links and the thin green links.

What that basically tells you is the traffic flow. If there is more traffic flowing between a core and two distribution devices, you’ll see thicker links there versus thinner links between Distribution-2 and Core-2 versus Distribution-2 and Core-1. Similarly, we can also look at the RX and the TX bytes here. If I look at the RX bytes in Distribution, I see that 75 gigs and 163 gigs versus Distribution. So I see that there’s more received, more traffic being received between on… So between distribution and access, there is more traffic that is being received on Distribution-1 versus Distribution-2. Well, for now, we know that the link is down because the link was up, we’ll know that the Distribution-1 is receiving more traffic than Distribution-2. So this concludes our session for EVPN IP Clos Topology.
Today we reviewed how to build a topology in four steps. We also reviewed the configuration of one or two devices, and I showed you how that a user does not have to manually configure anything. If you provide us the right topology type, if you tell us what nodes you’d like to be a part of the Campus Fabric. Also, if you give us some information about the VLAN IDs and if you would like VRFs, we configure the fabric for you. As a user, you do not have to configure the policy options. You do not have to configure the route target or the route distinguisher.

So this concludes our session. Thank you so much, and I hope you were able to take away some great things from this topic. Thank you.