Apples and Oranges – One Junos OS Across All Platforms?

One of Juniper’s long term marketing messages has been the concept of “One OS” across all platforms – i.e. whether you log into an SRX, EX or MX (for example), it’s still the Junos you know and love. Checking the Juniper website, I found that this claim is still made:

Junos is one system, designed to completely rethink the way the network works.

– One operating system: Reduces time and effort to plan, deploy, and operate network infrastructure.

I’m not so sure that’s true any more, so let me explain why.

I Blame My EX

With the EX series, Juniper went after the Enterprise Switching market for the first time in a big way. Before that, Juniper were largely known primarily as a routing vendor, beloved of many service providers for sure, but with limited enterprise penetration. So the EX was a very important step for a company keen to grow out of the somewhat limited market in which it had been established. But this presented a problem I guess – how to configure the switching functionality?

A Road Well Travelled

Interestingly Cisco IOS users have been through a similar situation over the years where Cisco made a move to offer switching functionality through the IOS interface, where before their Ethernet switches had been menu driven, or ran CatOS. Predictably perhaps it was a bit of a bumpy ride, but ultimately things settled down and we got used to using “Native IOS” on Catalyst switches. However, if you’ve ever had to configure bridging on a classic IOS router, for example, you’ll know that it’s a very different experience than it is to configuring switching on a Catalyst 6500. There’s a difference between a router with switching commands rather clumsily bolted on top, and a switch with IP bolted on top.

Pobody’s Nerfect

So this is where Juniper’s “One OS” claim goes somewhere hot in a handbasket. There are effectively multiple Junos trains depending on your platform of choice. In my case I’m interested in what I’m working with, which are:

– EX: Focused on Ethernet switching
– MX: Routers with strong switching capability
– SRX: Routers with strong switching capability and firewall capabilities

As a result, the Junos configurations start to smell an awful lot like classic IOS versus a switching IOS. Configuring and monitoring layer 2 on a EX is different to doing so on the MX and SRX. I’m going to casually put aside the firewall part of the SRX, and just look at configuring VLANs, Layer 3 virtual VLAN interfaces and similar. Comparing EX with MX/SRX:

unit 0 {
 family ethernet-switching {
  port-mode trunk;
  vlan {
   members [ vlan-10 vlan-11 ];
  }
 }
}

unit 0 {
 family bridge {
  interface-mode trunk;
  vlan-id-list [ 10 11 ];
 }
}

How about looking at the vlan membership?

show vlans 101
or
show vlans vlan-101

show bridge domain vlan-101

Note that on the EX you can use either the vlan number or its name, where on the MX/SRX you can only use the name, though thankfully it is not case sensitive (the bridge domain in this case could be named VLAN-101 and it still matches). To me if you’re using MX/SRX this makes a strong case for a consistent naming convention rather than using more helpful names like “finance” and similar, unless your’e really good at remembering which name maps to which number.

Then let’s take a look at the bridging table:

show ethernet-switching table vlan vlan-101
or
show ethernet-switching table vlan 101

show bridge mac-table vlan-id 101
or
show bridge mac-table bridge-domain VLAN-101

The EX allows a name or vlan tag. This time the MX/SRX will accept either, so long as you use different keywords, and this time the vlan name is case sensitive, so while “vlan-101” might work to view the bridge domain VLAN-101, it would show nothing when you view the mac-table.

Bonus points for Junos here: no error messages are generated when you specify a non-existent vlan name or number on the MX/SRX, for either command above.

These commands were checked on MX/SRX running 11.4R7.5, and EX running 12.2R2.4.

Pain In My SRX

I know; it seems unreasonable to be so demanding as to point out the totally different configuration styles, but the inconsistency drives me mad. I’m in an environment where we have a mixture of MX, EX and SRX hardware. I hate that I have to think about what kind of hardware I just logged into before I can type certain commands; it just makes things unnecessarily difficult. I’m sure that there’s a great underlying reason for it too, but I can’t help feeling it would be worth making the change to a single configuration style across all three platforms if possible. You know, “One OS”. Jumping between these platforms is, as the title suggests, like comparing apples with oranges.

Am I out of line to be annoyed by this? Am I the only one that is driven crazy?

John Says

Fix it! Could we possibly have one configuration style across these popular platforms? This makes support a freaking nightmare, let alone when you have inconsistencies with case-sensitivity and a lack of error messages added to the fun. Junos in general is great, and they’ve managed to keep much of the configuration consistent between platforms, but things like this make Junos seem very fragmented, and that’s a bad thing in my opinion.

In other news, supporting a mixture of IOS and NXOS is equally frustrating. Weather is next.

Addendum:

The video below is absolutely hilarious; it’s from 2009 and if I had to take a guess, I would suspect that its creation was funded by a large competitor whose name may rhyme with Schmisco; but that’s pure speculation of course.

Despite the apparent bias, it does rather drill the point home doesn’t it?