sponsored

The Why, What, and How of App Hosting on Cisco Routers

What if every time you wanted to roll out an app, you didn’t need to figure out what new computer/server you were going to put it on? What if I told you that there were computer resources built into your network? And what if I told you they even had access to serial ports for IoT devices? Shall we talk?

You may have seen Cisco’s announcements over the last few weeks about the new network. Intuitive. If not, here’s a little article by Jeff McLaughlin, that describes some of the new things you can do with the new network. In another article, Hank Preston discusses what may be the easiest way for a network engineer to get started.

Today I thought I would go into a little bit more detail about application hosting on Cisco network hardware. So if you are in any way associated with putting applications into branch offices or remote locations, I hope you will find this to be an interesting read. My personal opinion is that application hosting on Cisco hardware is one of the coolest things we’ve added since we added voice – and I think we all know that was a big deal that created big change. I’m willing to bet this is going to create big change as well.

Why host apps on a router?

Use Case #1

Imagine you want to run a small program at a branch office. What have you done in the past? I think what most folks have done is to install some sort of compute appliance. That network diagram would look something like this:

figure 1 developer.cisco.com

Figure 1 - Compute Devices at Branch Offices

The problem with this methodology is that you now have a compute appliance installed, which needs to be maintained. It consumes space and electricity. And you’ll have to, most likely, remotely manage it.

What if you could eliminate the device completely and get that same functionality out of the network router, which you need anyway?

Use Case #2

Another example of old school is this IoT implementation. In the not-too-distant past, it was common to use a terminal server to connect multiple serial devices to the network, and then push that traffic back to a centralized compute resource. We’ve seen this in action recently with a customer, right before we switched to the solution I’m going to show you below. The team that had inherited this old-school technology was frustrated by inadequate reliability and overloading on the centralized infrastructure. Below is a picture of what that would look like:

figure 2 developer.cisco.com

Figure 2 - Old School Terminal Server for IoT Connectivity

The problem with this method is that if the network is down, then the IoT Devices are not supported by compute. Also, this method transmits every byte that goes into and out of the IoT devices across the network. And finally, you have this terminal server that needs to be maintained.

What if you could eliminate the device completely and get that same functionality out of the network router, which you need anyway?

The new solution solves both use cases!

In the below diagram, you will notice that we have eliminated a fair bit of hardware and headache! Let’s talk about just a couple of the advantages of this method.

figure 3 developer.cisco.com

Figure 3 - Edge Compute in a Router

First, you have entirely eliminated a device at the edge of the network, reducing the time and effort of management at the edge. Second, you can run the code at the edge instead of in the middle of the network. What if the application was super simple, like a heat sensor on some machinery?

Here’s some pseudocode to make the point:

If read(IoT Device 1) > “180” then
{          
set(IoT Device 2) := “OFF”
       msg(“IoT Device 2 status [off],[heat]”, “central alarm app”)
        }

So what’s nice about this? How about the fact that the only time traffic goes over the network is when it actually needs to? And how about that reliability is dramatically increased because the compute resource is directly connected to the IoT Devices?

But wait, there’s more. What if you wanted to increase the reliability? For the price and effort we had before, we can add another router and increase the reliability of the whole setup at the edge as shown in the diagram below. And for the record, this is almost exactly what that customer is running in order to save lives using sensors, taking action based on those sensors and informing people of a dangerous situation.

figure 4 developer.cisco.com

Figure 4 - Edge Compute and Network Redundancy

Generally speaking, this new methodology increases reliability and decreases maintenance. Cisco has routers for both branch office applications, which have a ton of different “port type” capabilities. And, they also have ruggedized routers with wireless capabilities built in to handle the redundancy.

What does app hosting on a router look like?

Cisco has several different methods for putting an app on a router. For today, I’m going to talk about how it looks when you do it on IOS XE, since we just announced some new functionality in that area. This operating system makes it possible to run both virtual machines (KVM) and Linux Containers (LXC) in order to host applications right on the routers.

figure 5 developer.cisco.com

If you would like to learn about the details of what is working today and how this all works, you can visit the Cisco DevNet IOS XE page. We have a fair bit of information for you to get started. Another great place to learn about this from a slightly different perspective is our IOX page. In the meantime, I’ll provide a little bit more detail on the router configuration part – just to show you what it looks like from a Cisco IOS perspective. But I highly recommend hitting one of the links above to really get the best description and details.

How does this really work?

On a Cisco IOS XE router, there are five major steps to get an application running on the router using a KVM. Below is some sample code just to give you an idea of what it might look like.

NOTE: I am intentionally leaving out details to make this readable in a blog. You need to go here in order to get the details and exact commands.

figure 6 developer.cisco.com

Conclusion

In this blog, I wanted to provide a short introduction to running an application on a Cisco device running IOS XE. I hope that the “Why” section was compelling. Having seen what some of our customers are doing with IoT and this functionality, I hope you will explore it. The “What” section was strictly designed to cement the picture, “You can run containers right on the box!” And finally, in the “How” section, I showed you a sampling of the commands it would take to put a KVM package onto a router and get it running. Clearly, the “How” section is incomplete. But hopefully you get an idea that it’s not really all that hard. And I did leave out how to create the package. That would be too much detail for a blog. But you can get all the details you want if you simply go to Cisco DevNet’s IOS XE or the IOX page to learn more.