#NXTWORK2016 Highlights

Having finally got over the jet lag from attending Junipers second #NXTWORK event I thought I would write down a few thoughts.

So this is the second year of the #NXTWORK customer summit and they have learned so much from last year. The amount of attendees has increased, not overly so, which has given the event a new dynamic and a new feel. It still feels intimate but there is a great buzz going around.

The Marriott in Santa Clara was again the venue for this great event and there has been some fantastic additions. No longer is the attendee eating area at the back of the main event room making you feel a bit squeezed! It has now been moved out to a giant marquee just outside the main event area which now gives the event additional space for those great networking chats but also allows for more sponsor stands (more on those below).

Breakout sessions

The breakout sessions were again fantastic and kudos to Juniper for leaving out the Marketing fluff from them. Some of the sessions I found were slightly too high level but generally well received. Especially when you can harass the speaking directly afterwards to find out any information that has not been readily forthcoming before!

The main breakout highlights for me were exploring EVPN and how it is maturing and gaining additional features. As a Network Engineer from an ISP this technology will allow us to provide additional services and resiliency into our products which the likes of VPLS haven’t been able to give us.

Sponsor stands

I have to say my favourite sponsor stand was that of OneConfig with 2 separate products.  One which was their tie in with Juniper Networks in the guise of Project Buffalo and the other was their cloud based MTFW (Multi Tennant Firewall)front end.

For MSP’s, Project Buffalo is a no brainer.  Put an SRX into a potential customer site.  Add a bit of config to connect to OneConfig and a week later they provide you with a traffic analysis report highlighting any potential threats.  The best part about this is that Juniper are covering the cost of this!(apart from the SRX and licenses you will need on box)

The MTFW could be a real game changer for some MSP who use a large shared firewall for customers.  This allows junior security/network engineers and customers to login on and make amendments to their part of the firewall without interfering with others customers rules and policies.


Keynote Highlights


As always, Rami’s keynote leaves you feeling positive with the knowledge that Juniper are on a great trajectory and embracing the change to becoming a software company rather than a hardware company.

Kireeti Kompella’s take on SDN (Self Driving Network) shows why he is considered a thought leader in his field (and why i feel as clever as a cheese sandwich when listening to him)!

The main keynote which blew me away was Jonthathon Davidson’s presentation in which they had admitted that Juniper has previously got it wrong in the security space but they are working hard to correct this (see some of the latest Gartner reports on NGFW).  It’s not like Juniper to have to play catch up as in my eyes have lead from the from in the R&S space for some time and it must lead to some awkward conversations internally in how they not only catch up but then get ahead of the competition.

This catching up was also evident when myself and other Juniper Ambassadors got to sit down and grill the security team (read vent!) at a private lunch.  The conversation was frank and somewhat heated on a few of our bugbears but the Security team acknowledged them and advised that for pretty much all of our points, they are already being addressed.


I am currently a Juniper Ambassador and Juniper paid for my flights and accommodation for the NXTWORK event.


My 3 year Workiversary!

So LinkedIn told me it was my 3 year workiversary the other day.  3 whole years since starting with Fluency Communications and building out their National Next Gen Network.

When I first joined the company, the network was ran on 3 Vyatta boxes and a few 100M circuits.  From there we started the upgrade process to Juniper MX5 routers and some 1G links.

What made the MX platform stand out for us was the following:-

  • Stability of Junos OS
  • Rich feature set
  • Built in scripting tools (Netconf/SLAX)
  • Scalability

We required to have a box that would scale not only in performance but features. The MX5 can be easily unlocked from a 20G line rate box up to an MX10 giving 40G line rate performance with a simple license install (and further if you want).  For us, EVPN is looking like a no brainer upgrade from VPLS with its control plane learning and mac learning/filtering with the use of policies.  Sometimes it seems the possibilities are endless!

We have now outgrown the MX5/10 as our core router and we are now in receipt of some shiny MX480 routers (see below picture).  We have also taken the decision to go single vendor, which up until the last year or so I always had an inherent distrust of but seeing the flexibility of the MX platform has removed that mental stumbling block and we are now using the MX104 at our access edge for customer connections rather than our previous vendor.

This allows us to look at things like Junos Space,Network Director and Connectivity Services Director to allow us to build service templates that will allow us to provision complex customer solutions and the click of a button rather than jumping onto several boxes and sitting at the cli for 20-30mins.  This frees up my time to start looking at the next core network upgrade!

Have a great Christmas and a fantastic New Year!

P.S. Here’s a pic of our little MX evolution. From bottom to top – MX5, MX10, MX104 and an MX480!



Why oh why?

So i have been using Juniper MX routers for some years now (mainly MX80’s) and have configured CoS in reasonably basic forms to suit $dayjob’s needs (mainly 4 queues).

It turns out that even though the MX routers support 8 queues in the basic line cards, by default it starts with 4 :s

Would it not be easier to enable all 8 to start with?


MTR style traceroute on Juniper

Having used MTR on my mac and on Linux system I was always frustrated with the lack of this option from the Junos CLI.  You have always been able to start a shell and run MTR as below:-

nick@ScoobyDoo> start shell
% mtr

Although it’s super handy, the inconvenience of starting the shell can be a PITA.

I thought i would have to live with this until I found the following:-

nick@ScoobyDoo> traceroute monitor

Who knew!!!!