Deployment of Campus Fabric Core Distribution

Hello and welcome to this new edition of Wired Assurance.
My name is Rohan Chadha.
And I’m part of the MIST Product Management Team.
Today, we’ll be talking about deployment of campus fabric core distribution topology in Wired Assurance.
This particular EVPN topology is one of the three main topologies recommended by Juniper for EVPN-VXLAN in campus.
Today, we’ll be talking about how to deploy this using Wired Assurance.
And I assure you, none of this deployment will include any CLI configuration.
And we’ll use the UI throughout with just clicking a few buttons.
So let’s just jump right into it.
And I’ll walk you through the four steps to deploy this topology.
Before we begin, let’s talk about the building blocks of campus fabric core distribution.
What are the devices that we’re going to use today’
And what is essentially campus fabric core distribution’
So today, we’ll be using two core devices that are QFX10002.
We’ll be using two distribution devices that are QFX5120Y.
And we’ll be using one access switch for the purposes of this video.
And this particular device is an EX4400-24T, a copper switch.
In this case, it’s a virtual chassis.
You can use a standalone or you can use a virtual chassis for an access device in campus fabric core distribution.
Before we jump into building the topology in four steps, let’s talk about if campus fabric core distribution is right for you or your network environment.
I’d highly recommend you watch the other video by Rick Bartosik in which he explains why you should use campus fabric core distribution versus let’s say, an IP Clos or an EVPN multihoming topology.
So if you’re new to EVPN-VXLAN and you’re trying to explore this area, I’d highly recommend you go watch that video.
But if you’re sure that you want to use this topology and you want to learn how to build it, you’re in the right spot.
One of the things that I’d like to point out to you on this page is that all of these devices are not being managed by Wired Assurance at this moment.
And what does that mean’
That means that they’re only in monitoring mode.
As you can see the configuration is not being managed by MIST.
There is a reason why I’m demoing it a certain way and I’ll show you why.
So now these devices are being managed.
The configuration will not be pushed to the devices unless we explicitly ask the UI to do it.
So towards the end of the video, I’ll show you why we want it to be a certain way.
So let’s click on organization and under wired, we’ll click on Campus Fabric.
We will build a site based campus fabric.
There is also something called an Org Based Campus Fabric.
And what that means is you can build a campus fabric for an entire organization using pods from multiple sites.
But today for the purposes of this video, we’ll be building only a site based campus fabric, campus fabric core distribution as they call it.
So let’s click on configure campus fabric.
And as you can see that at the time of making of this video, campus fabric core distribution along with campus fabric IP Clos are in beta state.
So let’s talk about choosing a campus fabric topology.
As I mentioned earlier, if you’re sure that you want to build campus fabric core distribution, and this is the right place for you.
If you’re not, then go watch the other video.
But let’s talk about what campus fabric core distribution is.
It is essentially a two layer EVPN-VXLAN fabric, which involves a core layer and a distribution layer.
If you look at this diagram on the left side, you see a horizontal line.
This horizontal line basically differentiates what is a EVPN-VXLAN configured versus what is not.
As you can see, the top is a core layer and a distribution layer.
Below the horizontal line are access devices that are basically dual homed to the distribution boxes.
These access devices are your layer two dummy devices that can run LACP, but that’s not a requirement.
You can also directly connect servers or any other devices that you would like to single home directly to these distribution devices.
And that can come outside of the campus fabric or distribution workflow.
That is possible.
So let’s begin by configuring a topology name.
There are two kinds of topologies that we can build within campus fabric core distribution, CRB as well as ERB.
As you can see on the screen, it’s centrally routed and edge routed.
So centrally routed means routing on the core device.
An edge routed means routing on the edge, which in this case are edges distribution.
For the purposes of this video, we’ll be building a campus fabric core distribution that is CRB.
So let’s give it a name.
After you’ve given a topology name, we have some other default settings that do not need to be changed if there isn’t a reason.
These are basically the overlay and the underlay settings.
For this campus fabric core distribution, we do IBGP in the overlay, and we use EBGP in the underlay.
As you can see, we have 65,000, [Unclear], that will be assigned to all the devices in the overlay.
And we are 65,001 that will be sequentially incremented on any device that you use in this fabric, All of these settings will be taken care of by campus fabric.
As a user, you do not have to manually configure any of these settings on the device itself, as I mentioned earlier.
The loopback prefix is the prefix assigned to the loopback interfaces for every [Unclear] in campus fabric core distribution.
It’s slash 24, by default.
If you do not want to use this number, you can reduce it if your campus fabric or distribution is a smaller fabric, let’s say five to 10 devices, something like a slash 28 would work for you.
Subnet in this particular setting is basically the subnet that as a user, you will provide us or you can use this default subnet.
This will be used for the IP address allocation for the fabric links between the core and the distribution devices.
Again, all of this will be done and taken care of by campus fabric itself.
The second step is basically selecting the campus fabric nodes.
What node would you want to be a part of the core distribution and access layer.
There are a few requirements.
The first one that we see on the screen is Service Block Border.
Let me talk a little about what this is.
So if you’re someone who would want their network environment, core devices to be lean spine, and what that means is if you do not want the firewall or the wand, or DHCP, DNS, NTP services to be connected to the core devices, you can use something that’s called Service Block.
This service block basically connects to the core.
And you can connect all of your services including the connectivity to the cloud and your data centers in this particular Service Block.
For the purposes of this video, I’m going to keep it simple and we are going to be just building a fabric here and connecting, the service block will not be a part of this video.
So we’ll go ahead and select two devices that are a part of the core layer.
And that is as I mentioned, core one and core two, We will select two distribution devices distribution one and distribution two, As you can see in this little drop down, there is all the information provided to you at your fingertips, including the name of the model.
And for the access layer, we’ll be selecting a virtual chassis that has access switch three.
Once you’ve selected all the devices, you can verify by clicking on these, you also need to go to the router IDs here.
These outer IDs are used for loopback interfaces.
These back interfaces are used to appear with each other for building the VXLAN tournaments.
One more thing that I’d like to point out is that once you build the fabric, you can always come back and add more devices and you can scale as much as you’d like.
You can add more distribution devices, you can add more access devices based on your network environment needs.
So you do not have to connect all the devices in the same setting.
We understand that the network environment needs to grow and without any impact to other devices or the network operations itself, you can always come in and add more access devices later if there is a need.
The third step is basically to provide networks and If you’d like to do some segmentation between those networks, we have VRF settings as well for that.
For networks, you can either create a new network and go and create a new network here and we’ll call it EVPN CRB.
And I’ll do the VLAN ID 10.
And I’ll give it a VLAN subnet of 192, 168, and 10.1, 0/20.
And then I’ll assign it, a wired should get it but with this wired should get paid, but there will be used on your gateways depending on if you’ve chosen a CRB or NERP network.
Once you’ve created a network, you can see that two IP addresses have automatically been chosen for two core devices.
This is where the gateways will be set for this fabric.
And as you can see, since we chose CRB as a topology, core one and core two, we will have these two different IRB addresses on their devices.
And that will be 192, 168, 10.2 and 10, or three.
And we know that 10.1 will be the Woodford gateway, since we’ve manually assigned that.
We can go ahead and either create more networks or we can also add an existing network, and existing network is basically something that is being used in your existing site.
And in this case, this site called Bangalore Hyphen site has a bunch of devices.
So we’re going to go and choose one and two VLANs that are being used in other devices.
And we’ll try to inherit these, what this does is it reduces our work of configuring VLANs, manually, time and again, on every device.
So as we can see 4091 on the subnet and Virtual Gateway has been inherited, without me inputting anything, again.
So now we have three VLANs, that for which all of the gateways will reside on the core devices as we asked for.
But what if you do not want the gateways to reside on the core and instead, you would like the gateways to reside on outside the fabric, perhaps the firewall or the VAN itself, or perhaps your gateways and in the data center.
That is an option as well.
And that is something that’s called Bridge Overlay.
We can create a new network, let’s call it VLAN 100.
And we’ll assign the VLAN ID 100.
And we do not have to assign the subnet or the word should, what this does is VLAN 100 will be a part of the fabric of ENI will be assigned to it and it will be existing on all devices.
However, the gateway for VAN 100 will not exist on the fabric.
And the assumption here is that it’ll exist somewhere outside the fabric.
So it will be a layer to stretch from the access device all the way until where the gateway exists.
And it could be the firewall or the router, if that exists before.
So now that we’ve spoken about networks, let’s talk about how can you segment these networks using VRF.
I’ll go ahead and enable these instances for VRF.
And I’ll try and create some VRF server and I’ll try to keep CRB10 as a part of one VRF and then I’ll keep the other two VLANs as a part of VRF2 what this does is it segments the traffic between VRF one and VRF2.
If you would like more security and segmentation wherein you want to keep these networks separate and have different routing tables, this is an option for you.
You can also add extra routes if that is a requirement for your network.
The last step on this page is to assign a name to the distribution access configuration.
Once you build the fabric, there will be an ESL lag between your distribution and your access devices.
Your access device will be dual homed to your distribution devices.
So let’s give it a name and call it EBV – [Unclear].
We automatically taken all four networks that you assigned to the fabric and we added it to the trunk networks list assuming that all of them will be a part of the fabric and the ESI lag.
If for some reason you would not want to have any of the VLANs as a part of the ESL lag.
You can always come in and remove that head on.
There are other properties that you can change.
Most of them are default.
If you’d like to change the MTU or enable storm control.
Or if you’d like to set up a Mac limit that is an option as well for you.
The last and final step is to assign how these ports are connected to each other.
So far, we pick the devices, we’ve picked the VLANs and the VRF that we want.
But we haven’t really told Campus Fabric how to connect these devices.
So what I’m going to do is I’m going to go ahead and connect these devices.
And I’ll fast forward the video so you don’t have to go through each of the connections that I picked.
So as you can see, here, I’ve connected all these devices to each other.
I’ve connected two links from the core to the distribution, and then upwards as well from distribution to the core.
And then from distribution to access, I’ve connected to links as well.
As you can see, we support a virtual chassis in the access layer.
So you can very well use that as well here.
And if you’d like to change the A index number, that is an option as well, as long as it is within the AE index range.
So this was the last and final step, we’ll hit continue.
And this is a final step to verify, you’ve built the fabric at this point, ensure that you have selected the right VLANs.
Your IP addresses on a per device level that it’s selected here is as you’d like it to be.
Verify your connections are the core connecting to the right distribution devices.
And as we can see, and as an example, this is our bridge overlay design wherein VLAN 100 does not have an IP address, and that means that it exists somewhere outside the fabric.
Go ahead and hit Apply changes and click Confirm.
At this point, as I mentioned earlier, the devices are not being managed by Mist.
And let’s go to the Switches.
And let’s look at each device.
And let’s understand the configuration that is being pushed here.
So before I go through the UI and show you how the configuration is being displayed here in terms of VLANs and VRF.
Let’s talk about the configuration.
If you’re running a brownfield environment.
What that means is if you have an existing campus fabric and you are trying to convert to buy assurance based campus fabric, and you do not want to afford that downtime, you can come in, you can onboard your devices to the cloud but do not manage the devices.
Once you build the fabric, ensure that all the configurations are there.
We have a nice utility called download Juno’s config, without logging into the device, you can ensure that the configuration that you wanted to be on the device is there.
Now this configuration is the point of view of the Cloud as in Wired Assurance.
Wired Assurance.
Once you turn on Manage by Mist and you click Save, all the configuration to the CLI will be overwritten and part assurance will be the source of truth.
So if you look at this configuration, you will see that we have configured your underlay BGP, we have configured overlay BGP.
In your underlay BGP, we have two neighbors from core one to two distribution devices.
Similarly, we have to overlay between one and distribution one and distribution two, we have the appropriate EVPN configuration.
And similarly we have the gateways on the core devices with the appropriate Virtual Gateway.
As you can see, we have set appropriate jumbo MT use.
If there’s any configuration that you think does not match your requirements, you can always add or delete using the additional CLI commands.
So if let’s say, you would like to add an existing NTP configuration that is not supported by the UI, let’s say you can always come in and add it to the additional CLI command box.
So going back to the configuration, we see that we have the gateways defined, we have the routing instances defined as we did for your segregation of the networks.
So we can see that we have a particular network, that’s a part of it.
And similarly, VRF2 has two networks that are a part of it.
And then appropriate routing policies that are needed to talk between the four [Unclear] depths, that is there as well.
And similarly, all the VLANs that you want, as well.
It if there’s any configuration, as I mentioned, that can always be added by additional CLI commands.
So now let’s go ahead and enable Managed by Mist.
So as I mentioned earlier, let’s go ahead and enable Managed by Mist.
And we can do that for all devices in just a single click, we do not have to manually do that for all devices.
So I’ll click on this particular checkmark next to Status and click on More and enable Switch configuration.
As you can see, there is a warning here that says that, ‘If you have anything that is assigned via the CLI, please ensure that that will be overwritten. So please take care of that.’
So what this does is at this point, all of the configuration that we build through the fabric will be pushed to the devices.
Your responsibility as a Network Administrator is to ensure that the configuration that you’ve been managing through the CLI is the same as the configuration that you see in the downloaded configuration file.
And if you see that there is something that’s missing, then you need to rectify that or add through additional CLI commands, or perhaps go back to the Campus Fabric and edit the fields provided there.
So now that we’ve reviewed the configuration for Campus Fabric Core Distribution, let’s have a look at the topology itself.
And we assume that it’s been a while.
So BGP would have come up by now in the underlay and overlay and also the tunnel to be established between the core and the distribution devices.
So as you can see, I am in the EVPN-CRE topology that are named.
And I can see two core devices, two distributions and one axis.
As I can see, or if I click on the core device, all the properties that we saw earlier are available as well, you would see some green and red links.
And they are not just the status of that link, but they also depict the traffic flow.
So what I mean by that is if you see a tick link, that basically tells you that there’s more traffic between those two devices, versus if you look at distribution access.
So a good point of comparison would be if the link between color and distribution two is thicker than distribution and call two, you would know that there’s more traffic passing through the left link versus the right link.
And that’s a very useful way to understand how the traffic flow is working.
And if you know some sort of equal path load balancing is in play or not.
So now that we’ve reviewed the topology itself, we know that since we know we see all these green links, but what if you saw red links’
And what if you saw some BGP issues over there’
Or if you were seeing some errors, we can always click on a particular device and click on switch insights and see what’s happening on that box.
And we know for a fact that there are DDoS violations happening. DDoS violations aren’t a problem all the time.
But if something’s happening repetitively, then that is something that needs to be looked at, we look into, we see that there are a bunch of DDoS violations here.
But we also see that at the time when we build the topology, the last BGP peer state change was confirmed to be established.
Of course we know that looking at the green links that the neighbor ship is up, but if it was and you can always come here and look at the switching sites and see that your your BGP has gone through its regular steps of coming to an established state.
If for whatever reason, you’d also like to look at the device itself and log into the CLI if you’re used to operating a device a certain way, we also provide an option for you to click on the remote shell for any device.
And a pop up window will open right here on the screen, using which you can run any outputs as you’d like.
So let’s go ahead and check BGP summary as we saw earlier, as we can see, BGP has been up here for 42 minutes.
Let’s look at our EVPN database.
We see, we see a bunch of MAC addresses in the open database, we see some updated timestamps as well.
Let’s look at the Ethernet switching Mac table as well.
Of course, we know that all of these devices have been populated, or there are a bunch of devices that we have that are locally connected to this particular core device.
So now that we’ve looked at the topology itself, we’ve looked we know that the topology is up and running, what if what do you do on day two when your network environment requirements grow, right, you want to access more devices, you want to add more distribution devices, you can always edit the configuration and add more devices as your needs grow.
There is no limit to the number of devices you can add there is always a minimum requirement, there is no maximum limitation here.
What if you want to add more networks, you want to do some more segmentation.
Similar to what we showed you earlier, you can always come in to create new networks, or add existing networks, nothing changes really, from that point, you can always come in and modify the connectivity between these devices.
So this concludes our session for EVPN campus fabric or distribution.
I hope that there are some good takeaways for you from this video.
If there’s input for us, please send me an email at Orchard at Juniper dotnet.
Thank you.