Junos versus Cisco IOS: Explicit versus Implicit

My first Junos labbing project was an IPv6 backbone; I wanted to create a simple single-area IS-IS/BGP-free backbone running LDP and MPLS, and using 6PE for IPv6 connectivity. Needless to say, even though I read the excellent Day One books (highly recommended: Exploring IPv6, Advanced IPv6 configuration and Deploying MPLS), I stumbled on almost every step.

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.

Adding family ISO to the physical interfaces

interfaces {
ge-0/0/1 {
unit 0 {
description "Link to RR";
family iso;
}
}
ge-0/0/4 {
unit 0 {
description "Link to PE-A";
family iso;
}
}
ge-0/0/5 {
unit 0 {
description "Link to PE-C";
family iso;
}
}
}

Listing physical interfaces in the IS-IS process

protocols {
isis {
interface ge-0/0/1.0;
interface ge-0/0/4.0;
interface ge-0/0/5.0;
}
}

LDP configuration is no different – you have to list interfaces within the [protocols isis] section and enable family mpls 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.

Disclosure

Access to Junosphere environment was kindly provided by Juniper (thanks to @abnerg) ... but I was never asked to write about Junos or Junisphere.

19 comments:

  1. There are two sensible ways to ease the fun.

    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.
  2. 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...
  3. wish i have Junosphere to play with, tried few example on olive.
    I kind like this cli layout, i think even ios-xr is copy junos in many aspect.
  4. Thank you! Will definitely try the apply-groups. I discovered "interface all" but that's applicable primarily on core routers; if you have two groups of interfaces (PE-CE and PE-P), it doesn't help.
  5. It's also very easy to copy or move configuration from one interface to another.
  6. 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).

    So you're not really configuring anything twice here. The interface config specifies ethertypes to accept, the protocol config specifies what interfaces to run LDP on. Mutually exclusive.

    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.

    If you need any help feel free to reach out.
  7. Interesting about your take on EX. Are you not a fan of interface-range?
  8. > 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

    set protocols ldp interface all
    set protocols ldp interface ge-0/0/0.0 disable

    I think it was a design decision to allow some "non-valid" configs and allow the user to define their own rules and not let the parser get in the way although a warning I guess would not hurt.
  9. 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.
  10. 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.
  11. I actually find CoS to be much easier on Junos. The IOS way is just kludgy, especially on something like the 6500.

    I don't agree with eliminating the family statements. They make a lot of sense, especially when you look at an interface configuration that has multiple families on it.
  12. As far as QoS/CoS on IOS. What platform are we talking about :) Since the configuration different on about every switch in existence.

    Junos may be more verbose in the configuration but I wouldn't say clumsy.
  13. Ivan,

    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 ;)

    Just trying to add some additional perspective ;)
  14. @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 ;)
  15. 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
  16. One must love both "replace pattern" and "rename" commands!

    -- @miketomato
  17. 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.
  18. 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 ;-)
  19. 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.
Add comment
Sidebar