Rich Martin • 00:06

Hello, everyone, and welcome to a joint demonstration on how you can automate the deployment and provisioning of a Juniper Cloud Native Router using the Itential Automation and Orchestration Platform. My name is Rich Martin, Director of Technical Marketing at Itential, and I’m joined by a special guest for this demonstration, Vivek. Vivek, please introduce yourself.

Vivek Ravichandran • 00:29

Thank you, Rich. My name is Vivek Ravichandran, and I’m a Chief Architect, part of the global go-to-market team at Juniper Networks. So what is the problem we are trying to solve? So, given your role as a network architect for a communication service provider, it is crucial to ensure that the management and the operation of the different network types are consistently smooth, whether dealing with physical, virtual, or cloud-native network functions, and regardless of their location, be it be an edge data center, a larger central data center, or the X-Haul WAN network itself, reliable configuration changes for new services are essential, no matter where you are. the form factor of the network function. To address these pain points, the mantra adopted by Juniper across its product portfolio and solutions is what we call an experience-first networking approach, which in the case of JCNR is achieved through the rich automation and telemetry features it provides to northbound automation management systems, such as Itential. With that said, Rich, I would like to get your perspective and learn more about what Itential brings to the table to tackle these challenges.

Rich Martin • 01:46

Sure thing, Vivek. When you look at our customers, they’re really focused on delivering network and infrastructure services faster than they ever have before. And to do that, they really need to automate infrastructure changes at scale. And this is across a variety of vendors, cloud platforms, and internal systems like Teams and ServiceNow. So Itential’s solution helps to meet our customers really where they’re at by integrating into everything in their environment, including any kind of automation tools they may already have, and then enabling teams to build visual low-code workflows that can orchestrate processes that include network changes, data gathering, ticket management, and even documentation, as well as pre-checks and post-checks before and after you make a change. So by orchestrating the entire processes in our platform, we can enable that entire team to participate and drive more efficiency and to do more work in less time with fewer errors in order to deliver services faster at scale.

Vivek Ravichandran • 02:42

Okay, that was great, Rich. Thank you. So with that, let me jump on to the next slide. And here we can see the demo topology that we are going to use to illustrate the use case that will be part of this demo. So as you can see on the slide, so we are kind of simulating a 5G edge cloud here. So as you see in this picture, so we have a edge cloud. So, I mean, we don’t have the real workloads in this case, but we are kind of doing more of emulation. So we have a server, and when we start the Kubernetes or the cloud platform, the cloud software platform is already pre-installed, right?

Vivek Ravichandran • 03:36

So that is going to be our starting point. So typically in the case of a real network, this will be done by operators end-to-end domain orchestration system that you can see here at the top. In addition to that, we also have the Itential Automation Gateway that is also running as part of this topology, which talks to Itential Cloud from where we are going to run the day one and day two workflows that Rich is going to show in a while, right? So, and so as a first step, we are actually going to launch JCNR using the Helm charts-based day zero automation. And the, you know, the edge server is actually connected to the mid-haul network. So we have a few routers that forms the mid-haul, and the mid-haul actually is, it’s running SRMPLS as the, you know, the protocol to provide that end-to-end connectivity. So we are going to launch JCNR and we also have a small script that will automatically register this JCNR to the Itential gateway. So we are actually not going to do any manual steps here, so everything is automated. And following that, then that’s where Itential comes in and we are going to use the Itential Cloud, you know, the workflows to demonstrate the day one and day two workflows. And following that, we are going to launch few application pods, as well as we have a VM or we can think this like a simulated RU that is also connected to this edge server. And we are going to test connectivity from both of these workloads, the Kubernetes pod as well as the bare-metal server towards the already pre-deployed endpoint or we can think this like a remote 5G core or a CU network function that is running in the regional cloud. And that will actually conclude our demo.

Vivek Ravichandran • 05:50

So with that, let me jump on to. My setup. So here we have the the edge server that I showed in the slide. So as a first step we are going to verify that the Kubernetes is already deployed on the server and there there are no other parts including JCNR. That is that is running. So as we can see here, so all the Kubernetes pods are running and their status seems to be okay. So JCNR or the application pod is not deployed at this point. So as a first step, what we are going to do is we are going to deploy JCNR using the Helm charts. So all the charts are already configured. So we are not going to show that in this demo. The demo is more focused around the automation of the JCNR through Idential. So the Juniper documentation provides extensive details on how to actually install JCNR on a bare metal server from scratch. So let me go ahead and install JCNR on the server. While that’s happening, I also want to show the configuration on the Idential gateway. As we can see here, so the site to VCSR, so this is the remote node, the 2222 IP address, you know, the JCNR that is connected to that, the remote data center. So this is already pre-provisioned. So we are not going to do much with this.

Vivek Ravichandran • 07:28

So the JCNR or the, you know, the VCSR in question. So that is actually called as site one VCSR. And we will see that once JCNR is deployed on the server, we will automatically see the creation of the site one VCSR on the Idential gateway. And I’m going to show that in a while. So the Helm chart is deployed and seems to be running fine. So we are again going to check the status of all the pods. So, as we can see on the screen, the JCNR parts are deployed as we see here, there are two namespaces. There is a control namespace and the JCNR namespace. And this is where the, you know, the front JCNR parts, including the control plane and the forwarding plane related containers are launched. In addition to this, there is also a Kubernetes job that was spawned.

Vivek Ravichandran • 08:32

And what this does is that it will automatically register this JCNR instance with the Itential automation gateway using the REST APIs. And following this, if we refresh the screen on the Itential automation gateway, we can see that the JCNR, the VCSR, site one VCSR is also added to the Itential automation gateway. And we can also parallelly test the Kubernetes. So, as we can see on the screen, the Site1 VCSR is successfully added to the Itential Automation Gateway and with that we can also test the connectivity to make sure that the Itential Automation Gateway can successfully connect to the JCNR instance and that seems to be working fine. So as we can see here, so there is no configurations related to any protocol or the or the physical interfaces on this server. So this is the factory default configuration of JCNR. So from this point onwards, all the configurations we are going to do will be through Itential.

Vivek Ravichandran • 09:50

And Rich, do you want to take it over from here?

Rich Martin • 09:53

Sure thing, Vivek. So now that Vivek has instantiated this new virtual router, what we can do is get into the automation platform and take a look at the automation gateway. So the ITENTIAL AUTOMATION GATEWAY holds an inventory of devices. These devices can be physical devices, virtual devices, or even cloud services. We create a federated inventory based off of what’s on your network. And so what Vivek has just done is he’s instantiated this and registered it into the automation gateway. So now, within, once it’s within the automation gateway, we can now start to automate and orchestrate these kind of devices as part of a workflow.

Rich Martin • 10:34

So the workflow portion of our product is in the automation platform. So this is the ITENTIAL AUTOMATION PLATFORM. This is where you can build workflows that can automate network changes, in this case, pushing day one configuration changes to the virtual router. But in a workflow, we’ll take a look at the components of a workflow in a moment. But when you publish a workflow after it’s built, you can make it available in a self-service way. In this case, we’ve attached a form to this workflow. So what Vivek is showing us here is that from an area called Operations Manager, we publish workflows and now we attach forms to make it super simple for entire teams to utilize this workflow.

Rich Martin • 11:19

In this case, this workflow is to push the day one configuration to a new router that’s been instantiated. So, this form is built in a visual way and we make it super easy to input whatever fields are necessary so that whoever’s building and developing the workflow doesn’t necessarily can be a different team from the operators of the workflow itself. So in this case, Vivec is filling out all the required fields in order to push a configuration. And this configuration is going to be built into a template which gets pushed into the new virtual router that was instantiated and registered into the system. So when he clicks Run Manually here after filling this form out, you’re going to see where it’s going to actually execute the workflow. This is called a job and we’re taking a look at the job now. So when you build a workflow, you can kind of see this here, it’s essentially a series of tasks.

Rich Martin • 12:11

Each one of these boxes is a task. These tasks perform specific steps and they can do things like pre-checks, post-checks, integrate with different systems. So in this case, you’re running things manually in order to get information from that form, but it could very easily have come from another system, a source of truth, a database, an inventory system. Here, we’re using something called a template to validate that the template we’ve created using the form data is correct. And so it gives us an opportunity to manually stop a workflow so that we can put human eyes on it. And when you click Provision here, it’s going to continue with the workflow. So this gives you a pre-check.

Rich Martin • 12:51

If you felt comfortable with this pre-check, you could have that step completely automated and not manual. Now we’re doing a little bit of a delay here to enable the template. the push to the configuration to come up. Obviously, that has to save and doing some things on the background. Then now, we need to do some post-check processes. This is where we are going to take a look at the child job. Child job is just simply running another workflow.

Rich Martin • 13:19

In this case, you can run a workflow within another workflow. It’s almost like a subroutine, and you can make modular workflows this way. Now, we’re doing a post-check. We did a pre-check, we push the configuration. Now, we do a post-check. This post-check is using another feature in our platform called a template. This template allows us to extract operational data from a running device, router, it could even be a service, and determine based off a pass or fail criteria whether or not each one of these steps is successful.

Rich Martin • 13:49

So in this case, it looks like everything we were looking for is passed. So again, this gives us the ability to even stop a workflow, put eyes on it, this is useful in testing, and determine if this was a pass or a fail. So in this case, it’s showing us all pass. This could be checked programmatically. So in this case, we’ll click success, and the workflow will continue. And the final step of the workflow, and to help illustrate how orchestration is more than just pushing changes to a configuration, but orchestration is tying into all the different systems that may be part of an end-to-end process, and automating them within a workflow in our platform. This can actually push information over to notification and messaging system, like MS Teams.

Rich Martin • 14:32

So here, this very last step, is we can push details of this configuration change and the whole process over to MS Teams, and we’ll take a look at that as well. So here in this window you can see what the Teams display looks like. We can actually extract the information from any of our workflow tasks, modify them, and then format them so that they can be displayed in Teams. We can even add links. We’re not doing that here, but we can add links in the Teams so you can click a link and go directly into our platform or any other platform to take a look at anything else in more detail. So now let’s take a look at the day two workflow that we can run. So Vivek has now gone back to Operations Manager. This is a portion of our application and system where, again, you can publish a workflow and allow other teams or entire, like an operation team to run it versus somebody who’s just building a workflow that would build and test. So this is where you actually publish it.

Rich Martin • 15:33

The form here is a different form, but again, it’s a visual form. You create these visually as well as creating workflows visually in our platform. And so now Vivek is filling out the information that’s the day two information that will configure the overlay. And day one, we configured the underlay. Here we’re configuring the overlay. So this is more of the customer’s specific service information here. And so once he configures everything by filling out the form, he can click Run Manually at the bottom, and that will kick off the workflow.

Rich Martin • 16:05

So and once we get to that point, then the job is executed. And we’ll be able to take a look at the job running in real time, just like before. It starts off with some steps to input the information or to get the information from the form so that we can start to use it. And now we’re going to do a series of prechecks. In this very particular precheck, we’re executing a child job. A child job, once again, is running another workflow. So you can build workflows manually or modularly and use those as child jobs in a larger workflow.

Rich Martin • 16:36

This allows you to break certain tasks down. Like in this case, maybe you could have a series of prechecks and then pick and choose the prechecks you want and run them individually for a particular process. So when we take a look at this, we’re actually running a template that allows us to take a look at the operational state of the network. So here, before we make a change, the precheck is essentially saying is the underlying network good or is it in the right state so that we can now push a service configuration or a day two configuration onto this particular device. And so we can visually take a look at this through a series of pass or fail events. And we can see this was a success. We passed, so we clicked success.

Rich Martin • 17:20

So the precheck process will continue. In this case, we make it super simple to do things that should be done all the time, like backing up a config before you make changes to it. You’ll find a lot of tools like this as well as access to all your modular workflows. Now, before we push the configuration to the device, we can actually have a manual step here that Vivek is showing us that allows us to take a look at the proposed configuration changes that are to be made. And again, any of these manual stages that we’re looking at, could be, and should be, and eventually ought to be automated. But it’s really nice to be able to build this either for demonstration or for testing so that you know that these workflows are working correctly as you would expect them.

Rich Martin • 18:06

You’ll also notice here we see a few more arrows, where you can build in logic into a workflow, so you can test whether or not a push was correct. If it was, great, you can continue down the workflow, and if not, then you probably need some sort of rollback or backout procedure that can also be built into a workflow. We try to keep it pretty straightforward here. So now we’re doing a series of post checks. The push has been made. It was successful. And now we take a look at another template that gives us some information about the operational state of this particular device. So now, what are the things we expect to see now that the configuration changes have been made?

Rich Martin • 18:43

And so these become several rules that we can check. And in this case, we see all of these rules are successful. And any network engineer can build these kind of rules to check in a template, so very, very simply. So we want to build these tools so network engineers can really understand how to build these using native experience and knowledge that they have. And so finally, Vivek, I’ll give it over to you to talk us through the rest of the demonstration.

Vivek Ravichandran • 19:12

Thank you, Rich. That was great, and it was so quick. So as a last step, we are going to run some verification commands on the JCNR just to make sure that we can verify the state of the protocols and the connectivity from the JCNR node itself. And finally, we are going to launch the application pod and test connectivity from that application pod as well as the attached BMS server towards the remote destination that is 2222. So, as we see, the IS-IS adjacency is fine. So we also have the multi-protocol BGP, which is also up and running. And we also have the BGP that is configured towards the C that we saw in the day two workflow in the post-check verification command template output. And finally, we can see the VPN routing table, right?

Vivek Ravichandran • 20:16

So we also have all the required routes present there. So as a last step in the verification, I’m going to launch a few application part. I’m going to launch application pod on this node. So for that we are going to create a network attachment definition which will attach the application part to the JCNR and finally the pod itself is launched. So that looks OK. And as a last step, let us check the connectivity from the application part towards the remote destination. So as we can see, the pod can successfully connect towards 2222. So let’s check the same thing on the attached BMS server as well. So, we see that even here the connectivity is working fine. So that kind of concludes all the steps we wanted to achieve in this demo as well as the verification of the configurations that we have pushed. With that, I would hand it over to Rich for concluding remarks.

Rich Martin • 22:01

Awesome work, Vivek. Thank you for taking us home and I appreciate working with you on this demonstration. Thank you to the audience for tuning in and if you have any further questions on how you can use either ITENTIAL or Juniper together in a scenario like this or other type of automation and orchestration use case, feel free to reach out to us on our respective websites and we will be happy to assist you. And thank you. Thank you, Rich. That was great.