The most problematic aspect of Junos (from the perspective of an old IOS grump) is the total disconnect between interface configuration and protocol configuration. You have to configure everything twice – under [interface name] and under [protocols name]. For example, if you want to configure IS-IS, you have to list the interfaces within [protocols isis] and enable family iso on every interface.

To add insult to injury, Junos never tells you there’s something wrong with your configuration – you can add interfaces to LDP or IS-IS protocol (and commit the configuration) without enabling required address families on the interfaces. When you try to troubleshoot the lack of connectivity (or adjacencies), you don’t even get an error message. When you list IS-IS or LDP interfaces, the interfaces you added to LDP or IS-IS protocol are simply not there ... yet again, with no error message.

Seriously, while I understand why Junos does things the way it does, Juniper could add a few error messages along the lines of “interface configured but lacks address family”.

After a few days of grumbling, it finally hit me: Cisco IOS configurations include a lot of implicit assumptions while Junos wants you to configure everything explicitly.

For example, when you configure mpls ip on an interface, Cisco IOS automatically starts LDP. Junos wants you to configure the LDP protocol and the interface address family (which really specifies the ethertypes you can receive or send through that interface) ... but you only have to configure the interface once. When you add RSVP, BGP or other label distribution mechanisms, you don’t change the Junos interface configuration.

Arguing the merits and pitfalls of the two configuration approaches makes no sense; just remember that Junos wants you to be very explicit and configure exactly what you want – and that’s what you’ll get, no less, no more. And, as my lovely wife likes to say, it’s a fact of life – the sooner you get over it, the easier your life will be.

Related posts by categories

19 comments:

First, you can create an apply-group that sets family iso, family mpls and family ipv6 (and bumps the MTU as well for that matter) so you only have to set an IPv4 address and the rest comes along for the ride. Other things work as well, like firewall filters. I use this on the EX platforms to make it easy to group non-contiguous ports hosting VM clusters to ensure they all get the same VLAN's. This could be applied per-interface (eg, have BACKBONE & ACCESS, each applying different policy) or globally at a higher level.

Second, under protocols there's a trick that works for mpls (at least, never cared to try it anywhere else), just set "interface all", and (on the bigger boxes) "interface fxp0 disable" (to cover the management interface).

If you've got friends at large Juniper-using carriers see if you can have them show off their configs, it's the automation inside JunOS that makes many of these networks scale without full global config automation.

Well the other side is that you can include configuration statements (say for a future line card) and you could build all "fake" interface configurations and syntax-check you configuration with "Commit check".

Now when you plan a maintenance-window you can install the line card, and now commit the configuration you just made and everything will be up and running.

I do agree with you that *some* warnings would be nice. I recently uploaded a configuration to a JUNOS device and it had the wrong name for the management interface (me0 instead of fxp0) and that means that after applying the configuration i had no access to the device...

I'm almost surprised it doesn't warn at all if you have specified, for example, ge-0/0/0 under protocols ldp, that ge-0/0/0 doesnt have family mpls on it. Especially because, for example, with switching if you have an interface configured under the VLAN, it will warn you (and not commit) if you don't have family ethernet-switching on the interface.

You will notice as you do more and more work with Junos how logical everything is. Cisco's way of doing things is just throwing configs wherever. With Junos you have interface config under interfaces{} and protocol config under protocols {} and vlan configuration under vlan{}.

Configuring anything to do with ldp under an interface makes no sense because it's not an interface-related parameter. Specifying what interfaces to run ldp on under the protocols ldp{} hierarchy is very logical.

It may seem odd that you have to configure the interface for family mpls, but you have to look at it this way: you're not configuring mpls or ldp on that interface, you're just specifying the ethertype accepted (which is logically an interface-related configuration).

Like I mentioned on Twitter, learning Junos really requires you to take a step back and kind of forget everything you learned about IOS and all the IOS-like clones on the market. It's a whole new world, and you'll drive yourself crazy trying to make direct comparisons between the two philosophies. I know you don't feel this is useful advice, but once you accept it you will understand. I used to drink the Cisco kool-aid too, after all.

> Seriously, while I understand why Junos does things the way it does, Juniper could add a few error messages along the lines of “interface configured but lacks address family”.

You can define your own warning or errors at commit via commit scripts. It would be an easy script to check isis defined interfaces and make sure iso is configured (or warn on iso family'ed interfaces that are lacking isis config)

If you do 'set protocols isis interface all' it will only apply to interfaces that have iso enabled.

Same goes for mpls and ldp. If you don't want to run ldp to a customer there are a couple of points. Unless you are doing Carrier-supporting-carrier you don't need MPLS on a customer facing port. If you are dong CSC and don't want to run ldp on a interface on an interface with 'family mpls' enabled on it you can do the follwoing

Yea I recommend you also look at the interface-range object under the interfaces heirarchy. It allows you to create a single config for a group of like interfaces. This comes in handy especially with aggregation configuration. Why configure 6 interfaces when you can configure just a single one. Makes you config much more tidy as well.

I think that JUNOS should eliminate all the "family ..." statements from configurations and leave them just for the purpose of setting addresses (IPv4, IPv6, iso).Does it make any sense to have interfaces that by default accept only IPv4 packets ? I do not see any reason (or at least any more reason). Why should I enable an interface for instance to accept MPLS or IPv6 or ISO packets ? Ethertypes (or PPP protocol types) are not enough ?Anyway, comparing IOS and JUNOS is not an esay task. I have been working with both of them for a long time and believe me, there are good things in both of them. For instance, I like much more JUNOS configuration style for routing protocols, BGP and MPLS related stuff. But, have you ever tried to configure QoS in JUNOS ? Or NAT ? Very clumsy !!! Much easier and neater in IOS.

Also keep in mind that unless you put SOMETHING on an interface, it's not even active.

Eg if you have nothing under interfaces ge-0/0/0, then ge-0/0/0 doesn't even show up in your config.

So no matter what, you'd have to do something under the interface, so it's one line whether you add family mpls or not. just like in Cisco where you have to do a "no shut". Its one additional command in either OS ;)

@Brandonrbennett that's my thought. On the routers, it's not bad. On most switches, it's awful.

Junos may have more pieces to the puzzle, but honestly I didn't fully understand what I was doing with QoS/CoS until I did it on Juniper. You really need to understand how your queues and schedulers work. I guess that could be considered a shortfall, requiring the engineer to know what they're doing ;)

It also helps when you need multiple ranges for various purposes. Eg a range called "VLAN_100_PORTS" made up of ge-0/0/0 - 24, and then a range called "DOT1X_PORTS" made up of ge-0/0/5 thru ge-0/0/10. Just an example of the flexibility.

apply-groups have their place, but definitely not a replacement for interface-range

I was referring to IOS MQC, that in my opinion is much easier and well organized, based on the simple concept of decoupling classification from QoS policies.Obvously, this is a very subjective opinion !Concerning "family ..." statements, as many people, for historical reasons, before working with JUNOS I have worked on IOS, where interfaces can implicitly accept any type of packet, without specifying any address family, and to telll truth I never realized the need to have a command of the type "family ..." as in JUNOS.Anyway, as a global opinion, I prefer to work with JUNOS, more rational and neat.

It's quite straighforward...IOS is the general purpose with intelligent defaults of the network operating systems world. It works OK for quite a lot of folks, a bit like a popular desktop operating system I could mention. Junos otoh is a *nix of network operating systems, you've got to understand what you're trying to achieve, and understand the the underlying standards and semantics. Both have their place and are useful, but I prefer the latter ;-)

Guys, I have started working on Junos ecently and noticed that it has lot of configuration statements which are not required and could make life easy if removed from the CLI. I noticed that Juniper has one of the most complex VLAN tagging implementation. For example, looking at "encapsulation flexible ethernet service" propmted me to think of some kind of tunnel protocol like GRE or VXLAN etc. but in reality it only enables L2 and L3 services on the same interface. In cisco you don't have to do this "enacpsulation dot1q" or service instance takes care of the issue. I also noticed that Junos QOS is more confusing and complicated than cisco IOS-XR specially, the rewire rules which override everything that you have identified using classifier. On top of all this , Juniper documentation is extremely poor and very limited.

The author

Ivan Pepelnjak (CCIE#1354 Emeritus), Independent Network Architect at ipSpace.net, has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced internetworking technologies since 1990.