Junos: An Outsider’s Viewpoint

by Brian Lemm
Brian Lemm
Guest has not set their biography yet
User is currently offline
on Aug 17 in DeliverIT 0 Comment

My name is Brian Lemm, and I started working for SynerComm four weeks ago. Until then I knew that Juniper had a network line, but I came from eleven years at a large fortune 500 company that is a Cisco-exclusive shop. This is not going to be a Cisco versus Juniper entry – I just wanted to give a little info on my background (just saying I’ve been around the block a few times).

Switches switch and routers route. If a networking manufacturer didn’t do those two things well they wouldn’t still be in business… Even equipment that is off the retail shelf will do that. So personal preference plays a big role in deciding which vendor to chose. When I started at SynerComm, I hadn’t touched a Juniper device, so when I was given the opportunity to tag along to some installs I jumped at the opportunity. New technology? Sign me up!

To be honest, when I first saw the Juniper I had some doubts. Why would anyone want to use something that is based on Linux rather than an operating system that was built and designed for Juniper Switchnetworking? Then I thought, “duh, Linux is built for speed and function.” Doesn’t matter what that function is… Linux rules. That is why Macs switched to BSD to emulate it, and why you would be hard-pressed to find a datacenter without and least one linux server. But I digress.

The first feature that grabbed my attention was configuration control. I like the idea of a candidate configuration that does not take effect until it is committed. Being able to make the changes and schedule them to go into production off-hours is a nice concept. The need for configuration control is understandable, since when I first looked at a running config it looked quite daunting. However, when you start to understand the nesting features it makes sense. As you will read in any of Juniper’s documentation the config is quite a bit bigger than you would expect, but it is laid out so that you can easily understand exactly what each command is doing.

I found the idea of a “commit confirm” to be immensely helpful when working on a remote router. What the commit confirm command does is after the router/switch takes the candidate configuration and places it into running config, it will prompt you to enter the word “commit” within a specified amount of time (default is 10 minutes). The reason for this is that if you made a mistake and locked yourself out of the device, it will roll-back the config and let you back in. I can’t count the number of times I would change a setting on the WAN interface of a router, only to find myself locked-out and calling an on-site person to reboot the router.

Commit Confirm also does one other task that a regular commit doesn’t do. The command will actually check the syntax of your config to make sure there is nothing amiss. Make no mistake, if you enter something syntactically correct but logically wrong, you are going to be thankful for that confirm feature.

Have you ever logged into a router or switch to upgrade the OS (or just to reload it since it was acting up) and have it ask if you wanted to save the config? Who would make a change and not save it? Was that a mistake, or was it intentional so the change would be removed when the device was rebooted? Was the change made for testing purposes and now should be removed? Why do I have to deal with this… All I wanted to do was reload the device. Well, Juniper makes it easy to compare two configs to see what changes were made. Granted it won’t tell you why they were made, but at least you will have some information so you can make a logical decision.

Juniper keeps track of the last 49 configuration changes, and you can compare any two of them using the “compare” command. It takes all of the guessing out of what has occurred, and what changed that all-of-a-sudden broke the network. Better yet, since there is a config timestamp you can use it to prove that nothing on the network changed to cause the VP to lose their YouTube session.

I haven’t had the chance to look into auditing of configurations. For instance, when a candidate configuration is saved, is the editor’s name associated with it – so if I need to go back and ask a question, will I know who to speak with? Guess that will be next on my features to look at.

Tags: Untagged
Hits: 823

Trackbacks

Trackback URL for this blog entry

Comments

No comments made yet. Be the first to submit a comment

Leave your comment

Guest
Guest Friday, 18 May 2012