In the networking world, rivalries get less ingrained than the Cisco crowd vs the Juniper gurus. Each company fills a specific Niche within the computer networking world, with Cisco being the most valued in Enterprise networking. Still, Juniper is very heavily sought after by internet service providers. But which one is better? Sure, we could take the easy way out by comparing their massive differences in market cap, or we could compare the laughable difference in their market shares. But are either of the mainline operating systems these vendors provide objectively better or worse than the other? That’s precisely what we hope to answer today. Today, we hope to answer the question of Juniper vs Cisco– which is king?
Table of contents
Basics
Cisco’s flagship operating system is Internetworking or iOS for short. This operating system utilizes a command line interface to allow users to input and output data. For most of its history, iOS has been its beast, operating directly on the device’s hardware. However, with the advent of iOS XE, iOS is now a specialized shell running within a Linux kernel. The commands are the same. The Linux kernel now allows you to add specialized tools to your devices. It can be challenging to describe the actual functionality of the iOS operating system. However, You’re not scripting or programming; you primarily use predetermined commands to change the device’s configuration.
If you’re looking for an analogy, imagine being picked up by your friend, and you both decide to go to dinner. Your friend might need to learn how to get to the restaurant, so you begin telling them when to turn left, when to turn right, and when to go straight. Your friend already knows how to drive their car. They need you to input the variables to get them to the restaurant. Similarly, iOS already knows how to move that router or switch. It just requires you to provide the information given the commands it already knows about Cisco vs Juniper.
Now, let’s compare this to the Juniper operating system. The Juniper operating system, or Junos for short, is also a specialized shell or CLI within a Linux kernel. However, older devices were based on a Unix kernel instead. So, from this standpoint, it looks like Cisco is beginning to copy Juniper architecture rather than the other way around, which is a nice change. Junos operates much more closely than a traditional terminal CLI on a Unix or Linux device. You tend to have greater control over the device and its operation than with Cisco iOS. Additionally, some juniper devices also contain a graphical user interface or GUI, which is access via a web browser and the https protocol. This Cisco vs Juniper can be a real asset for novice users who still need to get more comfortable with the CLI offered by the Juno operating system.
However, if you are working in a Juno shop, then you’re going to have to learn the CLI. Junos operates like a scripting engine. Like iOS, Junos already has all the instructions necessary to use the device. But it needs you to input where this information is need. However, rather than relying on several predetermined commands built into the operating system, Junos is configured by directly manipulating configuration files. To reuse our earlier analogy of you going to dinner with your friend, replace your friend with a self-driving car. The car has all of the necessary instructions for it to know when to turn left and turn right. It would help if you input a destination into the car’s GPS, and it will make those determinations by itself.
As stated earlier, Cisco configuration relies on several predetermined commands to change the device’s behavior. To provide examples, imagine we want to tell an interface to utilize the DHCP protocol to determine its IP address. We would first use the interface command to select what interface we want, then use the command IP address DHCP to tell it– use DHCP. This is probably the best time to talk about the Cisco command structure. Typically, Cisco commands have at least two parts– they will have a knowledge followed by a Cisco vs Juniper variable. Using our example from earlier, Let’s say that we want to configure our first gigabit Ethernet interface. We would use the command “interface gigabit ethernet 1/0/1”. ‘interface’ is the command, and ‘gigabit 1/0/1’ is the variable. Sometimes, a sub-command is also necessary to make a command work.
Juniper operates on a completely different principle. Remember how we said that Juniper already has all the instructions to perform its task; it just needs you to input the variables. It contains many trees, leaves, and other foliage-related terminology relevant to Juniper. Think of these Cisco vs Juniper as directories within a file system. Crud is an acronym for interacting with data- CREATE, READ, UPDATE, and DELETE. All of Juno’s configuration input relies on a crud verb. These cred verbs allow you to interact directly with specific lines within the configuration file. Let’s compare system input with the earlier example we used of Cisco.
Rather than needing two separate sets of commands like Cisco vs Juniper, one to select the interface and one to tell it what to do with IP addresses, Juniper can do all of this with a single control. In Juniper, the command would read as set interfaces gigabit Ethernet 101 unit 0 family inet address DHCP. Do not worry so much about what each of these words means as this is way Beyond the scope of our video, but to oversimplify it a bit, interfaces Gigabit Ethernet 101 and unit 0 are all subdirectories or directories within the configuration file family inet simply identifying that you want to make alterations to the Internet Protocol on that interface and address says you want to change the address, in this case, you select a DHCP. Hence, you want it to use the dynamic host configuration protocol to assign an IP address automatically.
Navigation
Let’s talk about navigating the Cisco vs Juniper operating systems. Both iOS and Junos have a lot of similarities. For instance, both use the show command to display configuration information about a particular device. If we want to see what the configuration currently looks like that is running on a Cisco device, we can use the command show running-config. It’s pretty simple. In Junos, this is a very similar process. It’s just a different name for the configuration file. In this case, in Junos, we type show configuration. Pretty easy.
For instance, if you want to alter a configuration on an interface, you need to check if a device has fast Ethernet or gigabit Ethernet interfaces. You can type the word interface on a Cisco device or interfaces. On a Juniper device. This will display information that is necessary for you to identify what is going on with interfaces and provide a list of the possible variables or sub-commands that you can input into these two areas. Both operating systems allow you to use the up and down arrows to recall previously entered commands. This is helpful if you’re doing tests that rely heavily on the same power repeatedly, just in different areas of the configuration file.
Both Cisco vs Juniper operating systems allow you to auto-complete commands but go about it differently. In iOS, you use the TAB key to autocomplete an order as long as there are no other commands that utilize those same starting letters. For example, if you do not want to have to type out the entire word interface, you can type int, at which point there are no other commands that start with those three letters. If you press the tab, it will auto-complete the word interface for you.
So, if you type enough letters into the command string that no other commands start with those same letters, the space bar will auto-complete that word. The Juniper equivalent to interface is interfaces. So if you type int and then hit the spacebar, it will auto-complete to interfaces for you. Now, this only works with predetermined areas of the configuration file, such as your different trees and leaves. However, this does not work with computer-generated input, such as the names of specific VLANs. If you want to auto-complete one, switch back to using the TAB key, just like with Cisco. Remembering the difference between a tab and a space bar is tricky.
Juniper does not allow you to shorten command strings. You have to type a Juniper command in its entirety. Having the ability to use a tab and spacebar helps you get that entire command string typed out. As we noticed from our earlier example of working with interfaces, commands in Juniper can get a bit wordy. On the other hand, Cisco could be pickier and will let you shorten specific commands as long as it’s clear. Let’s take an example of what the most common knowledge typed in Cisco iOS, which is copy running-config startup-config.
This is the same as saving. It saves your current configuration that is running to the startup location so that if your device ever has to reboot or loses power, then what is currently running will once again it will be back into the machine. Instead of typing the entire command copy running-config startup-config, you can shorten this down to cop RS. No other commands are going to start with those inputs. This drastically shortened command structure speeds things up for experienced iOS users. However, experienced Juniper administrators using the autocomplete features tend to work almost as quickly as Cisco administrators using the shorthand commands.
It’s standard that you’ll want to remove a configuration from a device’s configuration. In Cisco, this is as simple as typing the word no in front of whatever command you use. For instance, shutdown is have to on interfaces to power them down and turn them off. If we want to turn an interface back on for any reason, instead of saying turn on or something like that. We type the word no in front of the shutdown, which powers it back on. No shutdown is the exact opposite of shutdown. This works with almost all commands within iOS. In Junos, it is as simple as changing your credit. The Juniper equivalent of shutdown is disabled. Instead of using set disable, I’m cutting out all that middle to shorten things, and then you can change your cred verb from set to delete, which will be deleted or disabled.
The most significant difference when you’re working with these command line interfaces is that with Cisco when you hit enter on a command. That command is to the running configuration. If you’re dealing with more complicated Cisco vs Juniper processes that require multiple orders to be run. This means that your device is temporarily going to be running partial configurations. Which is going to tell you stuff’s going to break, and you’re going to start throwing a lot of error messages across your network. On the other hand, with Juniper, there is an additional step before your configuration changes are need, and this is to use the commit command.
Commits have two significant advantages working for them. First, there’s a configuration verification that happens when you commit.. The device will verify that whatever you have changed does not directly conflict with other configurations on that box. Cisco does not make these distinctions and assumes that you, as the administrator, have done your homework and know what not to do. This commitment verification can be frustrating for novice administrators. However, it is in your best interests to have such a feature to prevent you from breaking currently running things on your device.
The second significant advantage of having a commit is that you won’t have partial configurations just hanging out, throwing error messages across your network. You can completely stage a complicated process that requires multiple lines in your configuration file to be interacted with and then commit them all at once. No more partial configurations. This is also really helpful if you work at an organization that has specific configuration windows, Cisco vs Juniper. Which are periods when you’re allowed to make changes to network devices, usually outside of regular business hours. With Cisco, it’s a complicated process to make that work. With Juniper, it’s a simple process of logging in and typing commit and enter.
Permissions
Most operating systems have multiple levels of privilege where, depending on what your level of trust is, you’re permitted to perform different tasks on a device. Cisco iOS and Juniper Junos are no exceptions to this rule. iOS uses three different privileged modes, which is unusual. The lowest of these levels is called user exec mode, and it offers virtually no permission to do anything at all. If you’re in user exec mode, all you can do is see that this device is currently running and accepting input. User exec mode has to be found with a carrot prompt. To do anything virtually with this device, you must escalate your privilege into privilege exec mode.
However, suppose you want to make any changes to the actual configuration of the device. In that case, you must escalate your privilege to the highest level available on iOS devices again, called Global Configuration Mode. Global Configuration Mode is often referred to as conf t mode as the command to move from privileged exec into Global configuration is configure terminal. If you’re using Cisco shorthand, conf t will complete the job. Global configuration mode is where you’re able to alter the configuration and run many of those commands that are necessary to change how your device behaves. Most show commands are ready to run in privileged exec mode, and you cannot run select exec commands in global configuration mode. Do not fret; you will not force to constantly shift back and forth between privileged exec and Global config.
There is a way to force privileged exec mode commands to operate while you’re in global config mode. Type the word do before a select exec command while you’re in global config mode. And it will temporarily move you to privileged exec mode, run the power, and then move you back to where you were. This is a real time saver because you do not have to type exit conf t constantly. In Juniper, we have a more traditional two-level setup, which is familiar to most operating systems.
The lowest of these two levels, Cisco vs Juniper, is operational mode and is almost the equivalent of privilege exec mode. Actively, you can make specific changes to the device itself, such as restarting daemons or rebooting the device. You can also make extensive use of show commands, just like with privilege exec mode in Cisco. A nice thing to remember is that the lowest level on both Cisco and Juniper is ready with a carrot prompt. Even though the lowest level available in Juniper is still higher than the lowest level offered by Cisco.
However, just like with Cisco, you’re not allowed to change the configuration of your device from operational mode. You have to move into configuration mode to get this. In configuration mode, you have the same fundamental limitations as iOS. You cannot run operational mode commands in configuration mode. Except you can. You have to add the word run before your operational mode command. But you can execute operational mode commands in your configuration mode. Both do the same thing.
Config Files
Cisco devices contain two different configuration files. The first of these is called the running config, and this is the configuration file that is currently running on your device. Anytime you enter a new command into a Cisco device, it is automatically added to the running config. It operates within your random access memory, which means that as soon as the device loses power, the running config is wholly misplaced. So, we need something stored in non-volatile memory to have something to start up with. This is where our second configuration file comes in, and this is our startup-config file Cisco vs Juniper.
However, just because you type a command in Cisco does not necessarily mean that that configuration change is moved automatically to the startup of the config file. This is where the command copy running-config startup-config is so crucial because this is taking your running config and overwriting the start of the config file. It’s the equivalent of saving and selecting an existing file to serve as our destination.
Juniper handles configuration files in a very different way. The main configuration file is called the active configuration, and this is both what is used while it’s currently running and at startup. So, the functional configuration does not need to be manually copied over to a startup-config file like it does with Cisco. However, just because you enter commands into a Juniper device doesn’t necessarily mean they are being automatically added to the active config. Instead, we have to remember to type that commit power. When we change a device’s configuration, we alter a candidate configuration. It contains all of the planned changes to the active configuration.
Error Handling
What happens if something goes wrong? With Cisco, you’re SOL. There is no backup anywhere in the device of previous configuration files. However, with Juniper, it will keep up to 50 copies of earlier configurations. Every time you change the active configuration, it will create a newer revision. It will save a copy of the old modification in memory to recall some of these older versions if you do something with unintended side effects. By default, Juniper devices will store 50 versions of your active configuration. However, you can alter this number through the command line. Juniper devices also use an excellent tool called a rescue configuration; this is a disaster recovery methodology.
Suppose your active config becomes unreadable, and you need help getting into the device. In that case, you can load in a rescue configuration, usually from some method provided on the physical device itself. Whether that’s some LCD panel or whether it’s just a button that you have to use. These rescue configurations can give you everything you need to provide emergency access to that device, such as IP addressing and SSH credentials. Cisco devices do not have a rescue config, but you can manually create a file that does almost the same thing. An administrator will still have to break into your device to accomplish this manually, but Cisco generally does not contain a rescue configuration. Newer iOS XE devices have this mythical thing called backup and VRAM. However, Cisco is hush-hush on precisely what this does and how it operates.
Conclusion
So that wraps up our comparison between iOS and Junos, but which of these is better? It depends on your needs, your skill sets, and your experiences. Cisco has a drastically more straightforward command structure and utilizes much shorter command strings. Making it easier to memorize how to perform specific tasks, especially for users who have little experience with command-line interfaces. There is also a vast amount of training materials on the internet for Cisco devices. This is due to Cisco’s much more established training networks and certification pipelines. It’s also because in the Western world.
However, to users who have a decent level of knowledge of data serialization languages and scripting engines. And restful APIs, the Juniper command structure makes way more sense. While it might be longer and more challenging to type out, it’s easier to translate for your restful APIs if you are attempting to automate. Internet service companies typically favor Juniper. Therefore, you’re more likely to need to use Juniper regardless of your employer if you work for an ISP instead of any other kind of firm. There’s Cisco vs Juniper less training material than Juniper’s Network Academy, which is not as well established as Cisco. Still, Juniper does tend to post its training materials for free for anyone who wants it. Juniper’s much greater utilization of redundancy and backups for configurations means they have a lower risk factor than Cisco devices.
Ultimately, determining which is better will come down to the same usual factors. Which vendor will give you the most functionality for the lowest cost and provide the most support and training for your team, Cisco vs Juniper. Which will be easier to learn based on your team’s collective skill sets and experiences? I hope you got your answer.
