Our final presentation of Network Field Day 5 came from Juniper.  A long-time contributor to Network Field Day, Juniper has been making noise as of late in the software defined networking (SDN) space with some of their ideas.  We arrived on site for a nice hardy breakfast before settling in to hear what Juniper is bringing to the greater software networking space and how I later learned that it might be best to start phasing out the human element in the network.

First up was Jeremy Schulman (@nwkautomaniac) talking to us about Puppet integration into Junos.  Jeremy opened with a talk about his involvement in automating things.  Customers have been using infrastructure automation tools like Puppet and Chef for a while to provision servers.  This allows you to spin up a new piece of hardware and have it quickly setup with basic configuration as soon as it boots up.  Jeremy told us that reinventing the wheel when it comes to automation was unnecessary when you could just put a Puppet agent in Junos.  So that’s what he did.  As a side note here, Jeremy brings up a very good point about the future of networking.  If you don’t know how to program in a real programming language, I suggest you start now.  Most of the interfaces that I’ve seen in the last 6-9 months have a high degree of familiarity based on the old CLI interface conventions.  But these interfaces only really exist to make us old school networking guys feel safe.  Very soon, all the interfaces to these devices will be only be accessible via API – which means programming.  If you don’t know how to write something in Python or Perl or even Java, you need to begin picking it up.  For something like Python, you might consider Codecademy.  It’s free and easy to pick up and follow whenever you want.  Just a thought.

Demo time!  There’s also a great overview of Puppet on Junos over on Packet Pushers written by none other than Anthony Burke (@pandom_).  The basic idea is that you write the pertinent configuration snippets into a task that can be transformed into a workflow rather than being a CLI jockey that just spends time typing the command blindly into a Telnet or SSH session.  Because you can also parse these tasks before they are sent out via the Puppet master, you can be sure your configs are sanitized and being sent to the appropriate device(s).  That means that there are no humans in the middle of the process to type in the wrong address or type the right commands on the wrong device.  Puppet is doing its part to remove the possibility of mistakes from your base configurations.  Sure, it seems like a lot of work today to get Puppet up and running for the advantage of deploying a few switches.  But when you look at the reduction of work down the road for the ability to boot up a bare metal box and have it be configured in a matter of minutes I think the investment is worth it.  I spend a lot of time preconfiguring devices that get shipped to remote places.  If I could have that box shipped the the remote location first and then just use Puppet to bring it online, I’d have a lot more time to devote to fine tuning the process.  Which leads to greater efficiency.  Which leads to more time (and so on and so on).

Next up, we got a sneak peek at Juniper’s next generation programmable core switch.  While I didn’t catch the name at the time, it turns out that it was the new EX9200 that has been making some waves as of late.  This switch is based on custom silicon, the Juniper One ASIC, rather than the merchant silicon in QFabric.  Other than the standard speeds and feeds that you see from a core switch of this type, you can see that Juniper is going to support the kitchen sink of SDN with the EX9200.  In addition to supporting OpenFlow and Puppet automation, it will also support VXLAN and NVGRE overlays as well as other interesting things like OpenStack and VMWare plugins in the future.  Make no mistake – this platform is Juniper’s stalking horse for the future.  There’s been a lot written about the longevity of the previous platforms compared to the new MX-based EX9200.  I think that Juniper is really standing behind the idea that the future of networking lies in SDN and that a platform with support for the majority of the popular methods used to reach high levels of programmability and interoperability is critical going forward.  Where that leaves other switching platforms is the realm of speculation.  Just ask yourself this question: Are you planning on buying a non-SDN capable switch in the next refresh?  Is regular packet forward fine for you for the next 3-5 years?  That is the critical question being asked in strategy meetings and purchasing departments all over the place right now.

Parantap Lahiri stepped up next to present on the Contrail acquisition.  Those of you interested in the greater SDN picture would do well to watch the whole video.  Especially if you are curious about things like VMware’s new NSX strategy, as the Contrail idea is very similar, if not a bit more advanced.  The three use cases outlined in the video are great for those not familiar with what SDN is trying to accomplish right now.  In fact, commit this diagram to memory.  You are going to see it again (I promise):

Note that further in the video, Parantap goes over one of the features of Contrail that is going to get many people excited.  Via use of GRE tunnels, this solution can create a hybrid cloud solution to burst your traffic from the private data center into a public provider like AWS or Rackspace as needed.  That, if nothing else, is the message that you need to consider with the “traditional” vendors that are supporting SDN.  Cisco and Juniper and even VMware don’t want you to start buying whitebox servers and turning them into switches.  They don’t want a “roll your own” strategy.  What Juniper wants if for you to buy a whole bunch of EX9200s and then build a Contrail overlay system to manage it all.  Then, when the workloads get to be too great for your own little slice of private cloud you can use Contrail to tunnel into the public cloud and move those workloads until the traffic spike subsides.  Maybe you even want to keep some of those migrated workloads in the cloud permanently in order to take advantage of cheap compute and ease overall usage in your private data center.  The key is flexibility, and that’s what Contrail gives you.  That’s where the development is going to be for the time being.

The last presentation came from the Juniper Webapp Secure team.  You may recognize this product by its former moniker – Mykonos.  In fact, you may recognize this presentation from its former delivery at NFD4.  In fact, I said as much during the demo:

There’s a market for a security tool like this for lots of websites.  It gets the bad guys without really affecting the good guys.  I’m sure that Juniper is going to sell the living daylights out of it.  They’re trying their best right now based on the number of people that I’ve seen talking about it on Twitter.  The demo is engaging because it highlights the capabilities as well as injecting a bit of humor and trollishness.  However, based on what I’ve seen at NFD4 and NFD5 and what people have told me they saw when they were presented, I think the Webapp Secure demo is very scripted and fairly canned.  The above video is almost identical to the one from NFD4.  Compare:

Guys, you need to create a new Generic company and give us some more goodies in the demo.  Having a self-aware web firewall that doesn’t need human intervention to stop the attackers is a big deal.  Don’t use Stock Demo Footage to tell us about it every time.

Tom’s Take

What does the Juniper strategy look like?  The hint is in the title of this post.  Juniper is developing automation to reduce the amount of people in the network making critical decisions without good information or tools to execute.  As those people begin to be replaced by automated systems, the overall intelligence in the network increases while at the same time reducing the amount of time that it takes to take action to bring new nodes online and reconfigure on the fly to support things we thought might have been impossible even three years ago.  Through device deployment orchestration, flexible platforms supporting new protocols with programmability built in and even to new technology like overlay networking and automated security response for critical systems, Juniper is doing their best to carve out a section of the SDN landscape just for themselves.  It’s a strategy that should pay off in the long run provided there is significant investment that stays the course.

Tech Field Day Disclaimer

Juniper was a sponsor of Network Field Day 5.  As such, they were responsible for covering a portion of my travel and lodging expenses while attending Network Field Day 5.  In addition, they also provided breakfast for the delegates.  Juniper also gave the delegates a copy of Juniper Warrior, a mobile phone charger, emergency battery pack, and a battery-powered pocket speaker.  At no time did they ask for, nor where they promised any kind of consideration in the writing of this review.  The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone.