To it. And essentially all we talk about when we say activation code is the fact that whenever you order, whenever your purchase order is placed, alongside in the response to the PO you also get something called as an activation code. Let’s say you bought 300 switches and correspondingly 300 wire assurance subscriptions. All of this together tied together is a part of one activation code. It could also include let’s say 300 switches, 1000 APs and also 1000 wireless subscriptions. All of this together is all put into one activation code. It’s a combination of claim codes from all devices as well as your subscriptions all put into one place and that’s what is activation code.
Claim code on the other hand, is what is printed on every single device. So you can individually claim devices, you’ll also have to add your subscription separately if that is the case. But that’s the difference between what is an activation code and what is a claim code. Activation code is your one shot PO kind of DOD match or the terminology piece of it.
So how do you provision a device? You can either go into your inventory, you can neither do a claim code or an activation code and then assign them to a site. So either one of those, you guys are pretty familiar with this process as well, again. Now I wanted to put together, I think some of you may have seen this. What I did, I put together a video of how ZTP works. I want to go through this real quick so everybody’s on the same page before I actually go into some of the ways you can make ZTP work in even conditions that are not super conducive.
All right, let’s go through the process of how ZTP works. So what I have on my left hand side is your switch on which I will be looking at the show log messages and on my right hand side is where I will claim the switch. I will go through the entire process. What is most important is out of the box you will see that device is continuously trying to run phone to call home and you will see it’ll continuously say, my device probably is not provisioned. It goes to a redirect.jennifer.net. It’ll try. If redirect.jennifer.net has an entry of your particular Mac address and your serial number, then it’ll appropriately pass you on to your home, be it previously well Skype, be it CSO, be it missed. So now what we are doing on our right hand side is we’re going to go ahead and claim the switch.
Once you claim the switch, what the claim operation does is on the back end not only updates there is that this particular claim code and this particular serial number is corresponding to a particular device but also goes into redirect.jennifer.net, which is your jump server on which the device automatically reaches out to and then register itself saying, if you see this particular Mac or a serial, send it to ctp.mist.com. So that’s the most important piece. We’ll talk about Managed with MIS and monitor only in just a little bit. But that’s where you will talk about, that’s pretty much all you’re doing whenever you say that this is a claim code, when you hit claim, this is the backend operation that happens.
At this point once you hit claim, the next time around, the Phone Home servers, again, it’s constantly running. The PhD is a protocol. In fact, PhD is a open source. It’s over net con, so it’s an open IEPF draft and it’s not something that is proprietary. So you can see the complete logs in here. We will talk about how the protocol works as well. Once you say hit claim, you will see, you will stop seeing 4 0 4 not found and pro device not provisioned. Instead you will also see that now the phone home server is able to reach home.
So you’ll initially, once you claim, you will see that the device is disconnected, but you also have the advantage of configuring these switches even before they are ever connected. The switch does not have to be connected. Imagine a day zero scenario, you wouldn’t have to go through the process of configuring on the day of. Rather you can configure it well ahead in advance because you have now the ability of configuring the switch in a disconnected state. Now you will see you can go into schlock messages, you will start seeing Phone Homes starting to kick through. The Phone Home, once it kicks through, all it’ll do is now it’ll say redirect.jennifer.net, great, I know who your actual home is. Please go to ztp.mist.com and that will eventually push you to, as you can see, contacting URL zpt.mist.com and then it will understand the process that, oh, this is my home. I will send you the bootstrap config, blah blah blah. It goes through a few more processes.
Eventually, point being your Phone Home operation goes through and whatever config that you may have made right here on your right hand side will automatically get pushed at the point when the config goes through. That’s the advantage. If you haven’t configured anything, everything will be at defaults and it’ll just always be the same with everything being on the default VLAN and it’ll just communicate with the default VLAN. But in case you need configurations, you can always have that. The end state is you will see that Phone Home has succeeded. Notification you will see that Phone Home looks great and that’s pretty much all you will see from the Phone Home perspective. So there is no magic behind the switches doing CTP. It is the Phone Home service.
You’ll also see the most important piece, it’ll remove the configuration of redirect.jennifer.net because you wouldn’t want to continuously keep doing Phone Home once it’s completed Phone Home services. So you can see now that the Phone Home is complete on your right hand side, the device will go green.
Now the most important piece out of all of this is, as I said, there’s no magic in the ZTP process. It completely follows the Phone Home client on your switch talking to the Phone Home server that is sitting in the cloud. And as long as the communication is okay, again for this, if you see that the communication is failing, it is definitely going to be, you have to just go through the same route of what we did in the brown theory. Make sure you got an IP, make sure you’re able to reach to the internet, make sure your firewall is open. Otherwise, that’s pretty much all you would do during this process as well. Again, some of the things that I have utilized to instantiate for, especially for the SE community, you don’t have to do it in a fresh customer, but you have already a switch that has already been claimed or already has connected to the cloud once, but you want to show GTP one more time. How do you do that?
All you would do is you would go ahead and re-add the configuration of redirect.jennifer.net. Anything that is corresponding to our Phone Home, those two lines where you say RFC compliant and your Phone Home service is redirect.jennifer.net and then on your switch you can go into and say instead of, it is just a service, all you would say is restart Phone Home service. It’ll immediately start the process. So in case you want to show the full process over again, that’s what I did here. I restarted the Phone Home service, I just didn’t show you what I did because this is my home switch. It has been already claimed multiple times, but I wanted to show you the demo. I can show for the SE community, Phone Home service is just another service that sits on your switch. So once it goes through, it deletes those lines.
The http redirect.jennifer.net being your Phone Home server, just re-add it back again and restart Phone Home service. It’ll do the same thing over again so you can unclaim and restart it here so you can rinse and repeat as many times as you want, especially for demonstrations. ZTP, again, is not magical. I’ve shown you what the source behind ZTP is. So what happens when you go into a customer setup and say, “My ports on the UpLink are definitely not access ports and for sure are not definitely trunk ports. How do I make ZTP work on that?” Over the box the switches are not configured with anything. If the device is connecting to a trunk port, all you would want to do is just one of two things. One, that trunk port needs to have a native VLAN on which you can actually get a DHCP scope and get an IP address. That is only for the first instance when the device is coming up.
After that, you can actually configure the device for it to actually talk over a particular tag VLAN and also either set a static IP or get an IP from that new tag VLAN. But the most important piece is you would want to work with your customer to ensure that they have a native VLAN or VLAN1 in their scope where they’re providing IP addresses. That way we are not hitting a situation where you’re not getting any IP addresses. If it is a trunk port with own only four allowed VLANs and you plug your switch in and those four allowed VLANs are let’s say 10, 20 and 30 and 40, CTP will not work. Again, it’s not that missed is at fault or missed ZTP is at fault. It’s just that the process requires an IP address for you to communicate to the cloud and you’re not getting an IP and we need to fix the problem.
And how are you going to get an IP? One of two ways. The first important piece is if you have a trunk port, ensure it has a native VLAN on which you can actually communicate and also has a DHCP scope for that VLAN. Or you can also have VLAN1 and that could also provide if you’re tagging along. But once the first piece, once you get an IP address and it communicates to the cloud, you can actually configure your switch entirely to exactly, let’s say you had a ports 10 or VLANs 10, 20 and 30 and 40 and you wanted your switch to be managed with VLAN 10, absolutely, you can do that. You can point to when you’re configuring yourself.
So you now have the ability to actually configure even before, this is at the point where, let’s say your switch is absolutely disconnected. You don’t have your phone home running anything like that, but you can actually say, I’d want my device to get an IP address on VLAN 20. I want that to be a static VLAN for example, and a static IP address for example, on VLAN 20, great. It’ll work just fine through the entirety of the process because your trunk is already allowing for you to do that. But the key part is, in the initial onboarding process, the device does not have a VLAN defined to it and you have to have some way for it to communicate to the cloud and that’s important.
So hopefully this one makes it a lot more clearer in terms of why it needs something of a native VLAN or a VLAN1 on the UpLink configured so you can at least get an IP first up, but then subsequent management can completely be based on exactly the ports that you want to run with. And this is extremely similar to what you do with the APs as well. The APs also need a management VLAN. By default, it also works on the untagged port, so you have to have a native VLAN for the ports connecting to the AP. Same concepts run here as well.
Now there’s another situation saying, “Hey, my UpLink ports are aggregated ethernet, your craft doesn’t work here. How am I supposed to make this work?” We can make it work. We just have to be very cognizant and well aware before going into the POC. If you have an UpLink, let’s say you have an UpLink of 4,600 and you have xe-0/0/1 and xe-1/0/1 connecting to your 4,300, which is going to be your CTP candidate, and these are the two ports that are be going to be connected from 4,300 to 4,600. And if the 4,600 is already pre-configured for an aggregate ethernet, we don’t have to change anything just for the sake of ZTP. We do not have to. All we would need to do is to ensure either one of these two ports, xe-0/0/1 or xe-1/0/1, configure your option for sub to ensure in irrespective of whether the device on the other side has an LSEP or not, I would like for me to keep the port up.
The key part is only one of these two ports need to be configured with the Force-Up and the configuration should be on the 4,600. The 4,300, you have no config abilities. You still don’t have, it is not cloud managed yet, you have nothing, so it can come out of the box again. They can make the connections just the way it is. They want to have xe-0/0/1 and 1/0/1 connect to the corresponding ports on 4,600. Absolutely. Just have this force sub command on either one of these two interfaces, xe-0/0/1 or 1/0/ 1. Not on both. If you do it on both, then you end up a the loop. You don’t want to do that. But with Force-UP it worked great.
Again, one of the most important things I constantly harp upon is the fact that getting it right the very first time. You don’t want to go day three or day four for you to make this work. Let’s say the switch connected, life looks good, you connected the switch, it connected. You also saw the keyword ZTP completed in your switch insights. That’s great, but now after 10 minutes, the switch disconnected. You’re no more in contention. Something happened. We don’t know what. What is this 10 minute window? Why did you lose connection after 10 minutes? What happened? So during this process, let’s say your ZTP went through, because you have all of the above set in place. You have your native VLAN or your VLAN1 config, it caught an IP address in right IP addresses [inaudible].
All of this is pushed down to the switch. Now what is the connecting port to your UpLink? If that UpLink configuration is blank and you said I’d want my VLAN to be, or I want my IRB now to be on VLAN 20, which is my management VLAN, but you haven’t allowed that VLAN on your UpLink or your UpLink is fully unconfigured. There goes the problem that’s right there to say that you configured your UpLink wrong and now you are in a state where you wanted your UpLink to be this, you’re not able to connect to it now it’ll roll back and go to an older known config, which is where this config are not pushed. The way the config will manifest or this issue would manifest is that, “Hey, now the config are getting pushed every 10 minutes we just see disconnect and come back again. But at that point it has the old config, which is the default config. This is crap.”
The important piece that has happened there is the configs were pushed from the cloud to your, at this point now, you’re stuck in a state where your UpLink port configurations were not configured correctly. Your VLANs were not allowed for the VLANs that you wanted it to be, your IRB or your management VLAN, and now you’re stuck at a state where you’re not able to make configurations or at least continuously rolling back. Important thing to note here is your UpLink as well as your entire config should be correct in the first place, but UpLink takes special priority for you to make sure this is done right. So please ensure your UpLink connectivity is exactly in conjunction with what you want your IRBs to be. If you are allowing default, you make sure you allow your default freelance in your port.
If you want this camera VLAN 20, you want to make sure your UpLink is a trunk port where VLAN 20 is an allowed VLAN so you can actually go and get an IP address, all of that good stuff. So please ensure your configurations are correctly done before actually saying, “I want to do ZTP,” please. It’s switching 101 I know, but when you’re doing it from a cloud-based system, you think some things may be different or you may miss assigning ports, its corresponding profiles. It’ll manifest in a very unique way where you’re seeing rollbacks continuously happening but you don’t know why and that’s pretty much-
What is Zero Touch Provisioning or what can we do with it? We can actually configure and monitor an ex switch with it. It is really plug and play. You can configure the configuration or your can set up the configuration in your network on a global level that can then be inherited on a site level, modify a couple of things on site level that can then be inherited on switch level. You can modify there a couple of things and then the individual ports inherited configuration from the switch level. Further courses will explain that to you.
How do you know now that you have a plug and play cloud-ready switch? Well, there are some indications. There is one indication on the box itself where it says a little cloud with a check mark that this is available on the cloud and there are some additional stickers with claim codes and a QR code in the front of the switch that you can scan into our cloud and set up that automation process.
So once that switch is adopted via plug and play, we then can configure that switch as we said, but we can also start or we start monitoring that switch via netcom. We’re going to exchange information between the switch and our cloud. That is then going through our AI engine and our AI engine then publishes the service level expectations. In these service level expectations, there, as you will see later in the course, in these service level expectations, we start monitoring the switch in terms of the performance of the switch itself, CPU and memory. We are also going to see how clients or devices that are connected to that switch, how they’re going to behave in DHEP, how they’re going to behave in authentication. But we’re also going to monitor and give you insights in how are the interfaces behaving and how are applications, behaving.
Interfaces in terms of port negotiation. How is the cable, the quality of the cable? Is it broken? Is it not broken? MTU, spanning three loops, all these things we start monitoring and give you insights on that. Later in the course again, there will be more information. Adoption, as we said, adoption is maybe an existing switch that you just want to adopt that we can start monitoring this switch. So how do we do that adoption? It’s just about by, as we said, applying specific organization specific configuration to that switch, having it then adopted by our cloud. And once that is done the same as with the zero touch provisioning, we can start monitoring the service level expectations and we give you access to the virtual network assistance where via couple of questions you can ask the status of the switches and we enable you marvelous actions where you can actually see in one single pane of glass what needs to be done today on specific switches to keep your network running in terms of bad cables, MTU mismatch, spanning three, and so on and so forth.
There are a couple of firmware dependencies that we need to keep in mind. Number one, a cloud ready switch. That’s easy. It is shipped with the correct firmware on it. A switch that we going to adopt to our cloud has to have the right firmware to start with. So some switches maybe have already the correct firmware. It might as well be that some of your switches you need to upgrade to a specific version. Now, which version or version is recommended by JTAC you can find in this URL here.
For ZTP components, what we have is of course the ex switch, the EX device with the proper firmware. If this is cloud ready switch, it is already shipped with that right firmware. We need to have a redirect service. The redirect service, this is sort of like your call home where the device, the EX device will connect you to see if it is available for zero touch provisioning, yes or no. We have the zero touch provisioning service that actually has the correct information to get to our juniper missed cloud and then the OC termination service. This is the connection to our missed cloud where the device need to start to communicating with. And then besides this, there are some URLs that you need to be aware of. These URLs are specific from what site you are on. It could be US based URLs or it could be EU based URLs.
For the US based URLs, there are specific URLs for Amazon Web Services. So we have here redirect.juniper.net. That is the access to the redirect service on port 443. Then there is also the zpt.mist.com on port 443, and the oc-termination dot or term.mistsys.net on port 2200, which is an outgoing SSH to the OC term service.
For GCP. It’s pretty much the same. However, be aware that for ZTP and OC term, there is a GC, Google Cloud one that has to be added to it. The redirect service is a global service where we just have a database. These are cloud ready switches, and they could be redirected to the ZTP server [inaudible]. For EU, similar to GCP, in the EU we have an AWS service for GDPR reasons in our EU. Of course, there you have to have the redirect server.
As I said, that’s a global service. The ZTP is a EU specific ZTP, because now it’s becoming crucial for adoption, and that adoption is then pointing to the OC terminator in the European Union. Now be careful, between the US URL and the EU URL to our OC term, you see one in the US is mistsys.net and the European one is mist.com. So it’s not like a rule of term that everything is mistsys.net or mist.com. Just be a little bit aware of those.
GCP, we don’t have yet a Google Cloud platform in Europe as we speak. Another thing that is important to know is all firewall rules are only to be configured as outgoing ports, not incoming ports. It’s not by direction. Outgoing ports because it is the EX device that is going to establish the communication with the cloud. It’s not the other way around, for security reasons, so please keep that in mind.
Now, how is the ZTP process working? You have the EX device. As soon as you boot this up, this is going to send the MAC address, serial number, claim coat, and some other information to that redirect service. When that redirect service recognize that this is a switch that has the right credentials, has the right data to be adopted, it will be pointed out to the ZTP service. Then the ZTP service will then push the configuration, the initial configuration to the EX switch to establish a connection with the EOC termination. So once that connection is made, now we have a bidirectional communication, a secure bidirectional communication between the EX device and the OC termination service.
And in this bidirectional communication, we have a secure shell net config. So now we can push configuration and exchange information about the status of interfaces, the status of the switch itself, and so on and so on, to have the information to our AI engine and give you that service level expectation insights that give you better insights into your network.