At the Mist user interface, we are looking at the various switches that will be part of the campus fabric build. As we mentioned earlier, we’ve got a couple of access switches, couple of core switches, couple distribution switches, their their current version of code, the model of switch of course and other information that we can add. We can actually Add all kinds of information to this particular setup through just a real easy drop down menu here.
One thing I want to mention is that although these devices are connected, they don’t have to be connected to build the fabric. So they do have to be part of the organizational unit. So they have to be claimed or or adopted into the org unit and that’s that’s in this process. Once they are claimed or adopted, then we can build a fabric irrespective of whether whether they’re connected or not. So let’s go and look at access points. We’ve got an access point connected to access one.
And that is currently disconnected, which makes a lot of sense because that’s which is in idle mode right now waiting for the network to be built. So let’s go jump into the build. So we hit the organizational option and campus fabric. OK, so a couple items here. We’ve been able to build a campus fabric at a site level since the inception of wire insurance. But what we’re going to do is we’re going to focus at the organizational level because this aligns with some of the larger enterprises.
Large universities, healthcare systems where they want to have a multi pod approach and they want to connect those pods through a lot through a a core, you know core layer if you will and then that core layer offshoots to the Internet or maybe you build a services block on top of that core layer for external connectivity requirements. So let’s, let’s start with the campus fabric build here. So since we talked about and we are going to demonstrate group based policy.
This requires the campus fabric Ivy Clause type of architecture, which means that we’re extending the X land down to the axis layer. And we talked about that VX land header earlier. That’s where the scalable group tag. The 16 bit header for GB P is is associated. We’re going to push the layer 3 edge all the way down to the axis layer. We can put it at axis layer at distribution, it doesn’t matter for GB P either one works fine.
And then we’ve got a topology settings here that are relatively straightforward. We use EBGP for underlay and overlay. We support equal cost multipath for underlay and overlay. And so these this setting right here is is relatively straightforward. Customers don’t really change it to policy settings at all. We don’t recommend they change them, but if they want to they can. So it’s certainly customizable. And then the the subnet clarification here is these are the point to point subnets between.
The adjacent layer, so access layer to distribution, distribution to core and that those are the the the particular subnet addresses. All right. Next option is to select the devices that we are going to add to our complete campus fabric build. So we’re going to start start with the core, you’ll notice a core is a more option. So for a mid tier smaller deployments I would expect this would be used and this would be where.
The customer is okay with terminating the outside world directly to the core. So they might have a firewall cluster, maybe a couple of routers that they pull directly into the core and and that’s a that’s a clean approach for them. The cores of order option just provides the the VX land awareness, the encapsulation, the encapsulation of VX land to V land and so forth at the core. However, customers that are might be a little bit larger or that want to keep a lean core.
Where the core is just a very high speed router. Pack it in, pack it out as fast as possible. They can deselect this option and actually build a single or a pair which is recommended of switches to handle that border node piece, that border Gateway piece and and that would be where a customer would once again connect the Internet, their Wan Edge devices, their firewalls, maybe critical infrastructure, DHV radio servers, you know, those those devices that really they want to offshoot into their own own own pod if you will.
But we’re going to, we’re going to go ahead and keep this selected here for the sake of our demo, we’re going to name the pod Santa Clara Hilton because that’s where we are located. And then we’ll add both 5120 distributor switches and we were going to add 1 access switch, which is access one will come back later and add access to real simple stuff here, right. So we click on connect, continue and then this is really where Miss begins to.
Provide quite a bit of value. So we have a preconfigured template that we add or import into the fabric so our Vlans are created with our IP addresses. This this would be the address default gateway pushed down to the access layer. When I add access to it’s actually going to use the same addressing scheme, so same Vlans, same IP addressing. We’re using anycast in this particular deployment model. Real easy to configure. Single IP address, single Mac and tree. Once again all hidden using the mist.
UI customers once they see the simplicity of how they build verse, they go ahead and just knock themselves out with that. So we going to build a guest and a Corp or guest Wi-Fi and a Corp IT verse, both desktops are going to be placed into Corp IT as as they were part of kind of, if you want to consider that the same routing, it’s the same verse, same administrative domain. These are devices that can communicate amongst themselves without having to traverse through a third party device like a router or firewall.
So we’ll build that there and then we’re going to build guest Wi-Fi and we’re going to add that particular VLAN which is where that a P remember the AP is just disconnected. The one we showed that showed earlier that’s off that particular particular broadcast domain. So real simple. I mean we we added our, we imported a template which had preconfigured layer two, layer three that was automatically assigned to the access layer at because that’s what we’re doing our layer 3 boundary for default gateway capabilities.
And then we added a couple verse with the proper networks. Last bit of information is where we actually interconnect the the layers. So the core is going to communicate with both distribution switches only and we do that here. And so core one and Core 2 connect to distribution one and two and we see here that we’ve got five and six ports for both this one and this two now as we build this out.
The the the fabric itself is using LDP from a telemetry perspective to validate that the endpoint devices that we are communicating with once these ports go live, that the name matches what we expected to see on the other end right on the on the config. So if I happen to misconfigure and select the wrong ports, then this system will absolutely tell me and I can easily go back in and make that change. So let’s go here and let’s just select the proper ports.
We that we expect that will be the case here six and five of this two and then we’ve got, we want to connect to our downstream access switch and that’ll be done here on Port 37 and then we go to this one, we do the same thing. So we’re going to connect to five and four for core one and Core 2. And what’s really cool about this is once we’re done with the build we then we’ll be able to download a connection table and the connection table could be handed to.
The folks that are actually plugging the devices in, if there is a separate group of engineers or maybe other resources that you know, maybe, maybe this is being shipped to another site. Remember we can build this without the devices being online. They just had to be on boarded to the org. So we’ve got this built now. I can click on connect, continue apply my changes and we should see this get pushed down relatively quickly. So I’m going to jump really quickly into this.
And I want to go down to my my access layer first device. And what I want to do is poke around a little bit. You notice I can access device through a remote show which is pretty cool. So I like that. I’m just, I’m just the guy who who likes to be able to you know, poke around and make sure CLI is is because that’s my what I believe is is truly the case. CLI is always going to tell the truth.
So we’ve got our BGP session set up right here. That looks good. So I’ve got BGP underlay and overlay. Let’s go and take a look at my Ethan switching table. And what we have here is we’ve got our our, our AP device right there. You see that local? So I’m going to come up here to my desktops and what I’m going to do is I’m going to start to ping my local device for desktop one, which is 1099 or my local gateway 109999.1. So I I’m able to ping that. It’s pretty cool.
Come over here and hit this again. I see the local desktop show up. Now I I shouldn’t see anything across the network, and I really don’t. I see the other devices I’ve got the excellent tunnels to, but remember we have not yet onboarded access switch to. So here 108888.1 is my local gate. We have desktop two, and let’s take a look at my configuration of desktop two and that is here. So I’m not able to ping that device, and it shouldn’t be, but I’m going to keep that pain going.
Because we’re going to add the switch in just a second here, all right? So I’m able to ping there and I’ve got Internet connectivity from the desktop through the cloud. And the reason I know it’s through the cloud is because I could do a trace route and I can see that the my next hop is 109999.1, which is access one. That’s a good thing. So I’m actually going all the way through the firewall at the top end part of my network to access the Internet so that that was a relatively quick.
Turn around with respect to BGP and signaling and actually pushing the configuration down to the devices, that happens within seconds. Now what takes a little bit longer is just the telemetry piece of the what you see here, the actual campus fabric EVP and Insights option which is going to turn green once everything gets collaborated and and corresponded back to the cloud.
At the Mist user interface, we are looking at the various switches that will be part of the campus fabric build. As we mentioned earlier, we’ve got a couple of access switches, couple of core switches, couple distribution switches, their their current version of code, the model of switch of course and other information that we can add. We can actually Add all kinds of information to this particular setup through just a real easy drop down menu here.