Busy, busy, busy

It’s been awhile since I’ve posted any articles.  I’ve been very busy with life.  Part of the busyness stems from studying other non-Cisco solutions (Juniper and Citrix).  I’ve been able to add several letters after my credentials from these vendors, including the JNCIA-ER, JNCIA-EX, JNCIA-WX, JNCIS-ER, JNCIS-ES and CCA NetScaler 9.  I’ve worked on keeping my focus within the R/S and data center (SLB, WAF, WAN optimization, etc.) specialties.

Based on the number of Juniper certs above, it’s understandable when I say that I’ve grown quite fond of JUNOS.  This does not mean that I’ve jumped the Cisco IOS/NX-OS ship, however I’ve added JUNOS to the list of network OSs that I really like.  Many things are still more comfortable for me within IOS, although I’m getting duly comfortable in both platforms.  This is a good feeling — it’s nice to have some options in terms of not being locked into just one solution.  I don’t anticipate Cisco going anywhere, however being just as comfortable with another large vendor is nice.  Since the majority of network environments today rely on Cisco and/or Juniper for their routing and switching infrastructure, having a solid skillset in both platforms gives confidence that the majority of environments I see won’t pose any surprises.

JUNOS is based on a BSD kernel, which I like.  There are a number of industry-leading systems which are also based on a BSD kernel (I’m noticing a trend here): Apple OSX, McAfee Firewall Enterprise (SideWinder), Citrix NetScaler, etc.  *nix-based systems have proved their worth/stability for decades.  I use Linux frequently and love the stability (yes, Linux can be unstable, but if configured properly, can run for near eons without significant issues).

Since JUNOS is based on a BSD kernel (*nix), it was almost love at first sight!  I say almost, as JUNOS configuration is a little different from IOS (and many other vendors).  A JUNOS configuration, if just looking at the raw output is very lengthy.  JUNOS is very hierarchical — every configuration component has a definite hierarchical location.  IOS has some hierarchy, however it is almost seen as an afterthought.  New features often provide a new hierarchy, however much of the IOS configuration occurs within global configuration mode (no real hierarchy).

Because of this hierarchy, it results in a lot of extra “filler” hierarchy statements.  Of course, if you look at the config with the | no-more | set parameters, it outputs the actual set commands (which can be easy to paste into the device terminal).  This also results in much fewer lines being shown for the configuration (although each line can be rather long at times).

There are some things on JUNOS which seem backwards to me.  Quality of Service (QoS) is one of these areas.  I’m very familiar with QoS on IOS-based platforms (routers, switches, etc.), that it feels like second nature.  QoS on JUNOS platforms really differ between platforms (J-series, M-series, etc.) — this shouldn’t bother me, as QoS on Cisco platforms can be a maze (differing support on different router platforms, nearly every switching platform is different, etc.).  The way in which QoS is configured on JUNOS seems backwards to me, but I’m sure the MQC seems awkward to those not familiar with IOS QoS (not to mention CQ with the awkward calculations that have to be made to properly configure it).

I hope to continue the series on multicast, which will not only provide an introduction, but design principles of how to design a resilient multicast infrastructure.

In closing, expect to see the integration of both IOS and JUNOS into future articles.

Leave a Reply

Your email address will not be published.

HTML tags are not allowed.

WordPress Themes