Networking Field Day 20 Recap – Juniper is Hedging Their Bets

During Networking Field Day 20 that just wrapped on February 15, 2019, there was a most unexpected presentation from Juniper around automation and some things they are doing to hedge their bets on where the industry is moving over the next several years.


Mike Bushong (@mbushong) took the stage first for the team and laid out Juniper’s vision of where the industry is headed and gave warning to some of us old guys, either evolve your skills and be ready to leave CLI behind or you will be left behind. Automation is not a buzzword in our industry any longer, it is the here and the now. If you are looking into automation, looking to understand or learn automation, or even just try to understand what automation means you are already behind. As Mike points out in his Networking Field Day 20 talk, Juniper has lead the way in automation for quite some time but we are now at a tipping point where CLIs are are going to be a thing of the past very soon. Mike also made something very clear during his intro that had a few of us in the room scratching our heads, the tools Juniper is putting out are open to the public, not all are Juniper specific and they are getting no monetary vlaue back from them it is for a greater cuase to us all. A fundamental shift in the industry the needs to take place. And I truly must agree with Mike on this, we as engineers have to start getting better at this or we will be left behind.

Next Raunak Tibrewal (@raunaktib) took the mic over and introduced us to Juniper’s new EngNet site and portal. EngNet is built around 3 bases that help an engineer to prepare for and learn automation, Learn, Build, Explore. One of the things I was impressed with is this was built with community in mind. Juniper has a dedicated Slack channel for community support as well as J-Net to make this a very collaborative and open learning experience. I connected to the EngNet site and was really pleasantly surprised with the content, how it was laid out and was really shocked at the amount of content available. Right up front you can signup for the Slack channel, but then as you continue down there is a nice roadmap to get you going on things no matter what you level might be. Obviously a lot of this content is around Junos OS, but there is some vendor agnostic lessons as well. I think two fo the coolest features are the Automation Exchange which have readily available Ansible playbooks, NAPALM scripts and other goodies which are all sotable and searchable by either Type, Market Segement, Network Role and Operational Process. The final piece that brings this all together is the Learn area in which you can followed Assisted Learning via different options or follow the Self-Learning track. Most everything within EngNet is free, but there are some items that you get a free trial for 60-Days or so and then will need to pay for. All-in-all this is a great place to start if you are looking to get into Junos OS or just to learn through some open labs and even just see what others have done for automation.

The final presentation came from Matt Oswalt (@mierdin) who unveiled the Juniper NRE Labs platform. Matt started by building off what we had already heard from Mike about sutomation today in our industry is not a production-side problem but a consumption-side problem. The tools are there, the technology is there, but the people are not consuming them. To try and help solve this consumption problem, Juniper has released their NRE Labs  which is a “Community Platform for learning and teaching automation and Network Reliability Engineering”. Basically they have put out a totally free (you do not even need to supply an email address), broswer-based platform to learn vendor-neutral automation using tools such as YAML, Python, REST APIs, Git, Linux and so on. It starts with fundamentals if you are just getting your feet wet in autmation or coding. Then there are tools availabel to try our like Salt or NAPALM or Ansible. All of this runs natively in the borwser with no need to download anything. The lessons are customizable based on your current strengths or weaknesses which then bases the tasks on your current knowledge level and provides a roadmap for learning with links. One of the collest things Matt and the team have done is to enable the use of Jupyter notebooks in the learning. Basically this enables you to have a Python interpreter running real-time so you can see the output in your browser window as you run the code. There is so much that has been done by the team on this. I would suggest to go check it out and see for yourself the greatness that is there.

What Juniper has been working on to enable the users to actually consume the tools and automation that is out in the industry is really amazing, especially the fact in the case of NRE Labs, they are not looking to monetize from it. This huge in my opinion and in the long-run could actually help Juniper based on their product set and strong autmation reliance on their products.


Check out the presentations from Networking Field Day 20 here.

Cisco Prime, What is it good for?

By now the majority of us have used some itinerant of Prime, NCS, or WCS for wireless management, placing APs on maps, template building, backups, etc. But what else can Prime really do?

I recently did a project where we needed to integrate a new prime instance with the standard CMX installs, which is a chore in and of itself (a post on that is coming), wireless management for the various buildings they have and some jobs to do back-ups of switch, router and ASA configs. There then a larger project to push QoS to a large number of switches, around 1,000 or so. APIC-EM was attempted but there was such a variety of switch models, chassis, IOS versions, QoS abilities to name a few. With these variances, only about half the switches were supported in APIC-EM. Since we had just stood up the new Prime, it was decided to use Prime to push these configs to the switches. Let’s be totally honest before we begin, Prime was not built as a wired network management suite. It was built form the old WCS and then pieces were added and we now have this. It is not horrible, but it is not the best for wired either.

Fun now ensues.

Initial thoughts were to just push Auto-QOS to all switches, however there was a requirement for more granularity. More fun begins. I start to set out writing config scripts in Prime for a couple of switch models to test on, 4506-E and 4500X. Should be simple right, take a QoS config, put it in the template, select the switch and go. To write a script in Prime you need some knowledge of Apache scripting commands which can be a little confusing in itself if you not done coding previously, like myself. I was lucky and had someone who could do these scripts and teach along the way.

Some of the pitfalls we had along the way included the need to build-in smarts to see what platform the switches were to use the proper commands, what version of code was on the switch, querying the switch to gather port types and line cards installed. To accomplish this you have to first begin with understanding the Prime database structure and how to call the appropriate variables for what you need. This excerpt from the Prime 3.1 user guide is a good place to start to understand the variable and how to call them from inside the CLI config templates. Also, see this Support Community Post which has some good info as well.

Now we have gotten our background info we are ready to start jumping in and breaking, I mean writing, some scripts. This was a lot of trial and error for me as we had to touch at least one version of each type of switch and verify we had the right CLI commands to enable QoS as it differs on platforms and even code trains within the same platforms.

After a couple of false starts with getting platforms commands, interface commands and settings just right we were able to get a working script for the first group of switches, the 4506-E,4500-X and a test Nexus 7K. The script ended up looking like this:

$Platform.contains(“Data Center Switches”))

The trick is we had to have the platform command and specifically the “Data Center Switches”. If a sh platform is run on the switches this is what is returned as the platform name. The reason we were looking at this command was it was easier and seemed more stable to call the platform type than the $Version.contains command to check IOS vs. IOS-X.

policy-map configs for IOS-X


This is where we specify non-IOS-X config elements




#foreach ($interfaceName in $InterfaceNameList)

#if ($interfaceName == (“GigabitEthernet0/0”))


int $interfaceName

service-policy output QOS-SHAPE

service-policy input QOS-MARK




These are the lines where the magic really happens. This code is going to the Prime DB and doing a querying for interfaces using the $InterfaceNameList and then we are checking if $InterfaceName == (“GigabitEthernet0/0”)) which is generally the management port on the switch. Of the port has that name we do not apply any Qos to it. If not any other $InterfaceName we apply the service-policy config to.

Gotcha 1 for me, make sure you account for all the #end statements you need. It becomes easy to lose track and it will frustrate you when you import to Prime and try to test it the first time.

With this basic config, you can now customize based on switch type.

The next step to deploy is we have to get this config into Prime, if you didn’t write it there, and make sure all our variables are working properly. After importing into Prime the Form View tab and Add Variable tabs will now be populated.

Our next post will cover Deployment of the newly created script to either 1 or 1,000 switches depending on the need.