So, adoption of a Brownfield Switch, extremely straightforward. We’ve done it many of times. You go into the inventory switches and click on adopt switches. You’ll be able to copy those lines of code, and then put it onto any switch on whatever is the minimum supported version. I’ll talk about the supported versions very, very soon as well. But you copy them and the switch should be able to show up in your inventory and you can assign it to a site. Now that’s nice marketing. You’ll be able to do it.
Let me take a step back. Let’s talk about adoption and claim. Let’s talk about those terminologies. Anything that is already existing, as in your customer has already configured their switches and it’s been there on as a Brownfield device for a while, you’re trying to bring that onto the network. That’s where you go through the adoption route. Now if you have a customer who is buying the ZTP, buying their switches as brand new, then you go the claim route because you have a claim code associated to it. So that’s the difference between adoption and claiming. So claiming is very, very similar to what you do on your APs. You just hit the claim code, the APs automatically connect to the cloud. Extremely similar concepts with the claim in here.
Now, once you adopt, let’s talk about the adoption and its problems. Once you adopt, let’s say you’re not able to see the device come onto the inventory and you’re not able to sign it, you don’t even see the device. What are the problems that you can see? The first point I would always look for is make sure you have an IP address on the IRB zero or whatever the IRB that they use.
Here I’m just talking about IRB zero. This is the example that I have on my switch. But please ensure you already have an IP assigned either via the DHCP or statically and you’d be able to see the IP come in. I have seen cases where your up link was not connected to the switch when the device was up already and you just plugged it in many hours later and the EX has given up on trying to DHCP anymore. So even if you connect your up link, it’s just not asking for an IP and ultimately turns out all you would have to do is just go do a restart on the DHCP service sometimes and that has helped. So please do remember if you don’t see an IP and you the device has been up for a while, it could be potentially an issue with the way EX does the DHCP in some of the versions. But just a point to note, you wouldn’t have to restart the entire switch for the sake of this. All you would do Is just start the DHCP service itself.
So once you have an IP, what’s next? You want to make sure you’re able to reach your gateway. You want make sure you’re able to get out to the internet, right? So ping whoever your gateway is, look at up your routes. Make sure you’re able to reach your gateway. I guess these are pretty simple, very straightforward. So let me go through them very quickly. I’ve put these together so that whoever’s going through for the completeness of the document. Now the next thing is you want to ensure you’re able to reach you. You’ve pinged your gateway. You now want to go reach out to the internet as well. You may have pings available for the internet or not. So maybe they’ve blocked 8.8.8. Key is to ask what is open and try to ping and ensure you’re able to ping outside of your gateway.
Now the most important piece is resolution of addresses. Are you able to resolve names once you have an IP, be it the DHCP, be it statically assigned. If you statically assign ensure you have a name server configured. If not, there is also when you’re doing it via DHCP, you would also need to ensure your name server is actually resolving to the address. We are reaching out to oc-term.mistsys.net. You will not respond, we will not respond to pings, but you will see that it resolved and it is trying to ping there. So you could also just ping google.com just for the sake of completeness in there. Now what one issue I have seen is I have seen the DNS server or the name server config disappear from the EX in a certain case scenario. I think I’ve had at least a couple of SCS reach out to me.
I personally have when I switched from static to DHCP or D DHCP to static, either one of these cases when you go into Shell and go into /fc/resolve.com, you just see no addresses anymore. But you still see the name server config in here. It is strange, it is buggy, but it is a cause that I have seen that all of a sudden the EX is off. Even after they get their IP address from a DHCP server, the DHCP server handed out DNS addresses, it still did not, for some reason the resolve.com is empty. So make sure if that is the case, go update the resolve, go update your name server configure again. It’ll repopulate the resolve.com and you’ll be able to go through the motions again. So some of these may not be ideal, it’s just maybe in some versions of Junos where it’s buggy. Again, what I’m trying to ensure is whenever there’s a client to, sorry, the switch to cloud connectivity in the steps, there are multiple different factors for it to be getting through. So I want to make sure I cover all bases and especially everything I have seen during multiple deployments. So resolve.com please ensure it’s up-to-date. It may take you off guard, but it is possible that can happen. Lastly, the most important piece is the firewall. Now the easiest piece for you to check if your firewall ports are open or not is from the switch. Ensure you are able to telnet on OC-term.mistsys.net on port 2200. Now what this does is all you’re looking for is the status quo connected here. You’ll see connected to, you’ll see nothing happen beyond that, but it’ll tell you that the connection is going through. If you are stuck at trying, you know that it is not a problem anywhere between your stack.
It is definitely at the firewall level. If you have passed through the previous four steps, you’re able to ping, you’re able to, your DNS is able to resolve and now you’re here. You want to ensure firewall is open, please talk to the security folks. That’s where you are looking that that’s exactly where the problem is at this point. So we’ve gone all the way from layer three out to higher levels. Now the last important piece that you want to check is if it is connected, if everything looks good, this is what you will see. You will see show system connections match 2200, which is a port we are making connection on this port. You will see it at the TCP connection is an established state. If you see it in any other state apart from established, I’ll talk about a couple more states in the next slide, you know for a fact that it is again something related to the firewall again.
So these are indicators as to where to look for. I have also seen certain cases, again, when you try to issue show system connections match 2200, you see nothing at all that is matching that port number and you go in and say, I want to check my configurations. You will see that set system services are on set, all looks great. It has the client ID has the exact outbound such client that we need to hit, but for some reason you will not see these for, you will not see the switch trying to make a connection which is an outbound as such connection to the cloud. Again, you can try two things. One, either deactivate system services are not SSH client missed and reactivated, or you could also delete the lines of config and re-add it either case. It is one of those quirks are seen where Juno doesn’t try to make a connection to the cloud. So please make sure if you do not see anything in here, you’ve passed the last five steps, but if you do not see anything appearing, please make sure you just deactivate and reactivate. Hopefully that helps. If not delete and then every time you copy, always copy the fresh config. So that will, that’ll ensure things work okay for you. And then you should be able to see after a few minutes you should be able to see the device and establish it.
There are, so this is where I said delete or deactivate, but there are states other than established where you will, this is established right here, but if you go in one of the state is SYN SENT, right? The TCP is being blocked. You’re, you’re sending SYN but there is no SENT etc or or any of that sort from the other end. And that definitely caught screams and tells you that there is a firewall in between that’s blocking the sin that was sent by the cloud by the switch to the cloud. So that is another good indicator apart from do you doing a telnet oc port 2200 and seeing connected. If it’s not, you can also see it is in a state that is not an established usually SYN SENT if the firewall is blocking. So these are different states for your brownfield switch not to come up. So you’ve gone through the entire gamut of process that you can think, at least I can think of.