My post yesterday about Junos configuration inconsistencies generated some interesting responses.
I should note that I’m not hating on Juniper here, or saying that they’re the only vendor with problems; they just happen to be the one that’s in my face right now and hence at the front of my mind. Longer-term readers may recall that I wrote about a similar CLI annoyance from Cisco in the past too (see An Open Letter Regarding AS-Path Access-Lists), and the subtle differences between IOS versions drive me nuts too (e.g. “show mac address-table” vs “show mac-address-table”). And let’s not start me on trying to see the next hop for a specific destination using the “show route” command on the ASA platform.
My irritation isn’t Juniper specific, but Cisco are at least vaguely honest about the fact that they have approximately one million parallel IOS software trains whereas Juniper for years has used Cisco’s diabolical software policy as a crutch with which to beat them down.
So let’s take a quick look at a few of the responses:
The Good
Per Granath commented on my post:
“You will be happy to hear that the new Enhanced Layer 2 Software (ELS) is coming to unify the switching language on all products.”
And he’s right, I will! I see from the links he gave that this applies to QFX and EX, but I’m hoping this means it may extend to MX/SRX too (although I do quite like the “bridge domain” model).
My Bad
Allen Baylis (@allenbaylis) on Twitter responded:
“Bad comparison! Some commands are product specific. IOS and JUNOS can’t be mentioned in the same sentence.”
First I should make the obligatory “It’s Junos not JUNOS” comment (just to keep Chris Jones happy). More seriously though, I understand that not all products have the same feature set, so I completely expect different products to have different subsets of the features enabled simply because that’s what they support. But in an ideal world, configuring ethernet switching could, and should, be the same across all products claiming to run Junos. Hence my response:
“@allenbaylis @craigmatsumoto Yes, some are product-specific. Shame they aren’t technology-specific :-/”
The Ug^W^WChris Jones
I knew that Chris Jones (@IPv6Freely) would love this post, being a dedicated Juniper supporter. I mean that respectfully; I’m not saying he’s a blind fanboy (well, maybe a little) but I knew that if anybody would stand up for Juniper, Chris would be a good bet – and I was not disappointed. I’ll edit slightly, but for clarity rather than biased editorial purposes:
“nobody ever said the configs were the same. The point is that it’s all based on the same code base.”
I believe that; I understand that all the Junos versions do genuinely come from the same code base, but clearly there are many branches out there. My response to Chris indicates the issue I see with this argument:
“@IPv6Freely Hmm. That’s a bit like saying RedHat and Ubuntu are one because they’re both linux-based. Try convincing the sysadmins… :-/”
Chris continued:
“”One Junos” was never meant to mean the commands are exactly the same.”
“Its a concept. The syntax may be slightly different but the Junos config as a whole doesn’t change across platforms”
So I have to ask, at what point of divergence from a shared core do we determine that there’s a difference between end products? To me, the CLI and command structure are part of “Junos”. If different platforms do the same thing in different ways then, for that feature at least I believe that the platforms have diverged. If you talk to un*x admins, those in a multi-linux-OS environment often complain about jumping between the different flavors of OS because the commands, the file locations (and even names) can differ between those systems even though they’re all “linux”. It makes the administration slower and more difficult as a result.
Chris also pointed out that branch SRX is configured like EX – with VLANs instead of bridge domains. That’s even worse! That means that the high end SRX use a different syntax to the branch SRX even though they’re both Junos running on the SRX platform. This isn’t good!
Most interesting to me in the context of the difference – and I think this is a very good observation – Chris pointed out that:
“[…]family ethernet-switching is pretty limited and meant for enterprise. family bridge is MUCH more complex.”
“if they were going to do it in a consistent way, it would all be bridge domains – but then enterprise users would bitch.”
I haven’t dug deep enough to argue with this statement, but as an enterprise user I’m happy with bridge domains, but frustrated that if I use an EX switch connected to an SRX firewall in my enterprise I will have two different configurations. I can handle it; I’m positive other enterprise admins will deal as well. Is irb.xxx as clear as vlan.xxx? Perhaps not, but how long does it take to learn the new way? Of course, the comment I mentioned earlier that indicated that ELS may be made standard across the range suggests that family ethernet-switching may become the standard, which wouldn’t be my preference either, but I’d deal if it meant consistency.
Anyway, thanks Chris for your comments – they made me think hard about what I really wanted, and raised some good concerns that I’m sure Juniper are having to address.
The Video
To ensure that we’re clear, when I said in the previous post that the video I linked to was hilarious, I meant it – it was so incredibly biased that I couldn’t take it seriously. To have included ScreenOS (for example) to support the claim that Junos is fragmented is just ridiculous. Juniper don’t claim that ScreenOS is Junos, so it’s not even in the picture. But the point of the video stands – there’s something not quite a clean cut as “One” going on there. It may be a marketing issue, that the campaign (accidentally?) implies a level of consistency across products that was maybe true once, but is less so now.
Either way, the feedback has been fascinating and I hope to hear more of it!
Leave a Reply