My Juniper Story

I got inspired by Jeff McLaughlin’s post of his thoughts on Juniper, and I wanted to tell my personal Juniper story from a distant small country Finland. This is also my professional growth story and I feel Juniper has had a significant impact on it.

My first contact with Juniper was around 2008 when I started a new job at a broadcasting network operator company. I was tasked to design a new MPLS backbone for TV transmission. At that time, we were Cisco house, but Juniper came along because it supported P2MP LSPs and multicast-VPN which were good candidates for multicast-based broadcast transmission. Cisco had only already outdated 7200/7600 routers available, the same as we had already. Cisco ASR and IOS-XR only started to emerge at that time. Alcatel-Lucent joined to competition having modern hardware and the same kind of features as Juniper. I learned and tested Juniper M series routers and I was convinced. Even better, fully Ethernet-based MX routers came out and that was a perfect match. French group owned our company then and they heavily lobbied “domestic” ALU routers they had in use. I was determined and pushed my view through and luckily my bosses supported me. We selected Juniper and started to replace the old Cisco MPLS network about 2010. The main Juniper distributors in Finland were IBM, Ericsson, and Cygate. We chose IBM which gave us kind of more global perspective and expertise, but years later IBM changed to Cygate.

I liked Juniper routers, the over-arching capabilities of Trio chip, and very clever Junos operating system. Finnish broadcasting started to move over IP/MPLS-based transmission with Juniper. Our core was based on MX240 and PE routers were mostly smaller MX80s. We received the very first MX80 routers with serial number 51 or so. The first multicast services in the new network were Mobile TV using DVB-H standard and commercial radios. We started with basic Draft-Rosen MVPN with PIM core, but quickly moved to PIM-less core with NG-MVPN. That was really good service. IP-based TV headends were added to the data center. Headends were very complex and had weird multicast problems quite often. I think most of the problems were due to poor network stack implementation on broadcasting devices, not the network. We had minor, but interesting problems e.g. with P2MP LSPs overloading already chatty RSVP signaling and hitting the MX’s internal rate limiters. That caused vague losses in transports which were hard to find.

Our small team had extensive training on Juniper with great international trainers. We learned a lot of details about hardware and software, partly by experimenting and testing different designs and features. I read the famous MX, QFX, and MPLS O’Reilly books to understand more. I would say we knew the products and their inner workings well, but there was always something interesting new waiting behind the door. I certified to a professional level. We also renewed a country-wide OOB network with new ACX routers. They were a bit abnormal with limited features for many years. The first line of products was obviously designed for large service providers and their specific needs. We had also bought Junos Space for network management right from the start. I tried hard to get some value from it spending countless hours configuring and maintaining the platform, but it never provided any usefulness for us. Just for fun, I took part in a Lab Madness competition which was organized by Juniper’s social media team and showcased user’s lab environments.

Our first Juniper data center network was based on EX4550 and EX4200 switches and Virtual-Chassis stacks. Soon we upgraded to QFX5100 and started to build Virtual-Chassis Fabric with 40G core links. That was a mistake, but felt good at that time. At first, VCF worked quite well, but after scaling fabric to tens of switches problems started. At the same time Junos software quality clearly degraded and fatal bugs were more frequent. VCF ended up being very problematic to manage and upgrade, just like Qfabric. We had a four-hour total outage in the data center during the night which was a bit problem for real-time broadcasting services. VC was better and usually worked properly, but you had to know tricks to cope with it. VC and VCF saga helped me to realize that a centralized control plane is a very bad idea. Still, Juniper tried to push the same principles with Fusion technology for years repeating the same mistakes again and again.

In 2016 Juniper celebrated 20 years in Finland. The same year I left the company for new consulting work. There I had a rare opportunity to work with Qfabric which turned out to be a really weird beast. Surprisingly there was one MSP in Finland using it. The same IBM guys we had worked with had driven it in and left it finally unsupported. I tried to help that customer with a network upgrade but the result of all the tests was that the system couldn’t be upgraded without downtime. The customer was unhappy for a reason. In another case, I tried to apply BTI’s packet optical platform for a WDM-DCI solution to connect several data centers together. That solution was never sold to a customer.

Then I moved to work in a company that operates the Finnish NREN network Funet. Juniper had a long history there and the hardware upgrade cycle was going on. I met new generation MX204 and MX10K routers with 100G ports. Junos Fusion was also used for a while to expand MX routers with switches. Soon came the decision to drop it off. Funet had highly-developed configuration automation with Ansible, GitOps, and abstracted services. That was a great learning experience for me and my first touch to the classic telco-style network and operations. To experience something new, I tried Contrail Service Orchestration if it had some advancements for network monitoring using telemetry data collection. Like always, the Contrail was promising, but designed for big service providers in mind, meaning it was hard to deploy in practice.

Then I moved back to VAR and a consultancy job, where I witnessed the birth of Mist. Juniper used to be a service provider vendor, but now it moved clearly to the enterprise sector. The movement was also seen in the whole sales effort. The push was first in security, then Mist AI. I have been using Mist at home for a few years now after receiving a free access point and switch as a Mist training gift. I did many Juniper certs to fulfill vendor partner levels, and personally, it was mostly for fun and challenging myself. Juniper did a great job with free resources for certifications and offering vouchers for tests. Juniper documentation has been also good and easily available. The user community is active and information is easy to find. Living as an independent contributor with Juniper has been easy, and that’s a big thing for me. Unfortunately, I have never visited Juniper HQ in California or Amsterdam POC lab. I have been attending some international events only. During the years I have met great and helpful Juniper consulting engineers and trainers who have helped me to understand technology and products better.

In my current work, I haven’t much to deal with Juniper. Our core network is based on MX routers, like many other networks in Finland. Juniper has been growing and invading many enterprise networks over the years. I think Finnish engineers really like Juniper, as a product and as a company. Junos was a mindblowing experience for me and probably many other users. I still have to wonder how far-sighted the developers were almost 30 years ago. Of course, there have been necessary changes during the years, like migrating to 64-bit OS, virtualization and hypervisors, and Linux. But original Junos automation capabilities and manageability are like no other and make every engineer’s life more comfortable.

Juniper products have been both superb and crappy. It depends on the product. MX routers are the flagship, well-designed platform around the Trio chip, always serving every need of network engineers. The switching line has had its highs and lows. Management systems have been targeted to large providers and thus are mostly unsuitable for smaller providers. I have never used Netscreen or SRX as a firewall. Juniper’s security story has been always somewhat obscure and lacking the final touch. Maybe it’s the user perspective, maybe positioning mismatch, the same problem that management systems have. Juniper’s acquisitions used to be obsolete for the average company user, but the latest rounds with Mist, Apstra, and 128T are different because they are enterprise-class solutions. Mist is the clear crown jewel and for a reason. 128T has been a bit mystery for me and now I think it’s in danger in the hands of HPE. Apstra has its own segment among larger customers and is absolutely worth keeping.

Personally switching from Cisco to Juniper was one of the best decisions of my career. I left the safe and guaranteed Cisco camp and concentrated on something fundamentally new and better. It was also a brave and empowering move for me. I would say that Juniper moved my direction to a more exciting and versatile track where my curiosity and experimentation were better served. I think Juniper also drove me to expand my reach to international experts instead of relying on the limited local resources and knowledge here in Finland. I even applied to SE role in Juniper once.

What I think about HPE’s acquisition, is that usually this kind of large corporation destroys a smaller company’s products and operating culture. On the other hand, Aruba has been like Juniper inside HPE. I hope that Juniper’s character won’t disappear because Juniper has been the most pleasant and inspiring tech company I have worked with. It was a smaller and technologically advanced vendor, products were mostly a great match for the needs, and the organization was dedicated, customer-oriented, and easy to work with. Part of this greatness has faded over time and Juniper has grown into a regular vendor among others. I’ve seen the same struggles that Cisco had earlier. That’s natural. Same time Juniper has grown to serve enterprises and its userbase has grown and diversified significantly.

Juniper has great products and I hope core product lines remain independent and intact. Juniper has had a clear portfolio, but now HPE-Juniper has so many overlapping products that there should be major cutting and killing ahead. Integrations don’t make much sense if you can’t focus on core products. Let’s see what happens. For customers, there are not that many vendor choices left in this “Juniper” category.  Except Arista. I see Arista following Juniper’s footsteps for good and bad. There aren’t other clear new emerging vendors and that could mean whitebox, disaggregation, and open source will take more role in the future.