BLOG: Community Talk
News and updates to keep you informed about all things community
, Super Contributor
BLOG: Community Talk
Bridging Two Worlds
Apr 2, 2013

This blog is about network manageability – and the role of Junos technology to address the problems of today's networks in a way that is aligned with broader challenges facing IT Infrastructure Automation as a whole.  We all know that managing networks is complex, hard, costly, and requires highly trained engineers.  This blog is going to talk about managing networks in a whole new way.  The concepts in it will change your life.  It changed mine.


There is no doubt - something big is happening – our industry is going through a paradigm shift.   Everyone is excited about the idea of "programming" the network.   People want to build network solutions independently of hardware vendors; to use open APIs, open software, to collaborate, and to innovate.  But most importantly – they need to deliver a network focused on the needs of the consumer of the network.   A similar paradigm shift happened a while ago for the IT system administrators ("sysadmins") and DevOps - You know, the guys in the datacenter deploying all those servers or virtual machines driving the need for more networking.  As we look forward to how the networking industry may evolve let's take a quick look back at the history of the sysadmins.


At one point, sysadmins were manually deploying servers, configuring services, and managing the installation of applications - applications that ultimately drive their business.  These sysadmins may have had some simple "bash" or "Perl" based scripting tools they created themselves, but it was largely ad-hoc.  Fast forward to today and the sysadmins now use sophisticated configuration management products like “Puppet” and “Chef” to fully automate large scale datacenter deployments.  They write programs to "glue" together these tools with APIs from other vendors like VMware, Amazon, Google, or from other software they download from the open-source community.  These sysadmins who were not formally trained software engineers picked up new programming skills and began focusing on automation as a key business driver and as a personal asset.  They use open APIs and open software. They collaborate. They innovate.  They are driving the success of their business.  They can (and will) become key influencers in deciding which vendor is deployed in the network. 


We should talk to the sysadmins and DevOps, but why would they care?  They will care because Junos technology is the bridge between their world and the networking world:


  1. Junos products are built for programming automation.  Junos provides a standards based and secure XML API.   It has been in the OS “DNA” for almost a decade.  It is field proven is some of the largest service provider network
  2. Junos provides explicit and granular Role Based Access Control (RBAC) controls for "who can do what" both in terms of operations and changing the configuration.  This is key as you'll see shortly
  3. The Junos cross-compiler toolkit ("SDK") can be used to build and deploy standard software onto networking equipment

So let's consider how Junos technology can be applied to solve a considerable pain-point in the datacenter.


Sysadmins need to interact with the Networking team any time they need to do basic changes at the top-of-rack switch, such as port / VLAN assignment.  While these changes are simple enough, at large scale it becomes a "pinprick of death" problem.  The pain becomes especially acute when changes in the network need to be coordinated with changes with the servers/virtual machines – for example at the time of a new application rollout.  When they are not coordinated (or unusually delayed) applications that drive business don't get online, the business loses money, and the "network" is the problem.


The networking admins want to automate these simple tasks.  They envision, for example, a "self-service" user portal for the sysadmins.  These portals could leverage the Junos XML API and authenticate to the Junos devices using credentials that explicitly define what the portal can do (points 1 and 2 from above).  They are effectively saying, "We're OK handing over limited and scoped control of configuration changes" because Junos can guarantee at the OS level that the portal won't harm the network. 


While the "user-portal" is one approach, there are challenges for the Networking team.  Sometimes the networking team doesn't have the resources, time or skill to build these portals or automation system.  The needs of the sysadminuserportal.jpgsysadmins are again dependent on the networking team to update and maintain this user-portal.  So again there is opportunity for friction, delay, and blame. 

The sysadmins write automation programs, and they are used to writing code to open APIs, or using sophisticated tools to enable their business needs.  So on one occasion when I was talking with the networking team about how they could build a user-portal, they said I should talk with the sysadmins because the sysadmins would have to build the portal for the networking team.


As we were talking with the sysadmins, they asked me:  What if Juniper could put a tool we use, say "Puppet", as a native agent on Junos. Then when we roll out our server changes the network just rolls with it.  Our Puppet Master would treat it like any other managed Puppet node.  If we ever had to rollback our changes, the network would just rollback with it.  In our world, we call this Software Defined Infrastructure.


This is possible because the Junos SDK technology can be used to cross-compile and package the necessary software.  With the Junos SDK it is possible to create a runtime loadable package for a Puppet agent.


I then had an epiphany:  There are *TWO* customers for networking equipment at these "intersection" points in the network like ToR switches (or firewalls).  One is the sysadmins and one is the networking team.  We need tools for both, and these tools are very different.


The IT industry is very focused on automation.  The networking industry is waking up to this need, and Juniper Networks has products and technologies today that can be used to solve network management issues.   All you need to do is start developing your programming skill sets, like the sysadmins.  Are you ready to begin?  Have you started and need help?  Let us know – we're committed to driving innovation and working with our customers – both networking and sysadmins. 


Here are some resources to get you started:




Apr 4, 2013



Is there a "Getting started guide" on this?


Here's some enquiries:

1. EX4200/4500 or QFX3500, 12.2? 

2. Server or VM specs to install puppet master?

3. Useful Reference links: 





Apr 5, 2013



Thank you for your post and interest in Puppet for Junos.  Here are the answers to your inquiry:


Regarding a "Getting Started Guide" - Presently I would suggest reading the "Installation" section of the Admin Guide.  The Puppet Labs Solutions page noted in the blog is aslo a good starting point.  If you are brand-new to Puppet, I would recommend the book "Pro Puppet"


1. EX4200/4500 or QFX3500, 12.2? 


Puppet for Junos 1.0 is built for 12.3R.2 (EX) and the 12.3X50-D20.1 (QFX).  For further details, please see the Release Notes and Admin Guide.


2. Server or VM specs to install puppet master?


I would defer you to the Puppet Labs site for information on this topic.  Please see for available documentation


For further questions, please post on our J-Net Forum dedicated to Puppet for Junos.


Thank you again!
-- Jeremy



Apr 7, 2013

Thanks, Jeremy!