Command Line Interface and Configuration Files on various routers, switches, etc. Juniper JUNOS and others

Somehow I got the impression with some equipment that the configuration file was nothing more than a direct copy in plain text of command line commands.  This seemed logical and useful.  Then those commands are automatically run at boot time.  Then other commands can be added during run time and made permanent (or not).

(I don't appreciate those configuration files that are somehow encrypted and can't be read at all except by loading them into the device.)

I'm working with a Juniper SRX lately.  The configuration files are readable so that's good.  They are also editable via the J-Web GUI and that's good.  And there's a CLI interface built within the GUI yet serious players seem to favor  PuTTY.

It suddenly it occurs to me:
There is a configuration file that is readable that fits some "structured" format BUT while the structured format can be edited like code, its relationship to the CLI commands is rather obscure.  Is that a reasonable way of looking at it?
That is, the CLI commands get "compiled or interpreted" into the configuration structure (?).

Did I miss reading some critical high-level description that talks about this?
I note that the CLI interface gives lots of help in structuring commands such as:
set security ?
will tell you what choices come next.
But that's not exactly the same as learning the CLI command set.
And doing that seems to imply learning the configuration file structure as well??

And why the departure from a serious GUI (with respect to the SSG line)?  By serious I mean that it's complete and correct within reason and that most serious things can be done within it.  Have the 'nix heads taken over?
LVL 27
Fred MarshallPrincipalAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

QlemoBatchelor, Developer and EE Topic AdvisorCommented:
IIRC, the ScreenOS part was bought some (long) time ago by Juniper (hence the name of NetScreen for many old devices running ScreenOS). It is a completely different department, not genuine Juniper. Juniper didn't have security features (firewall and VPN) pre ScreenOS, and that is why they took NetScreen over. Meanwhile JunOS incoporated many of the features, and Juniper isn't that much interested in keeping ScreenOS (EOL is scheduled) - sadly. I don't like JunOS.

And now to the internal storage structure of config files. It is not documented at all how the config actually is stored, only the readable representation is. I take it that the config is stored in a compiled format, but very similar to to the CLI commands, because on firmware downgrade it is possible to maintain the "invalid" config commands. The binary (or internal) format is used only in real time.

But the question is - why is that a question? It doesn't matter at all for handling the device ;-).
Fred MarshallPrincipalAuthor Commented:
Perhaps I wasn't being very clear.  No surprise because I'm trying to learn something and obviously don't know all that much yet....

I don't really give a rip how the code is stored at run time.
I *am* trying to handle the device.
At the moment I'm dealing with a debugging issue and am getting pointers and help from JTAC.  So, the emphasis is on the CLI interface.
What I'm doing right now is preparing debug "code" for when I want to instrument the problem.  The problem doesn't happen all the time so I need to be ready.
I've had the experience of doing one thing only to find that I needed to do something else or something different.  In this case I needed to learn how to *turn off* the debug stuff when I was done.
etc. etc.

As part of the reading and learning, I suddenly realized that there are two sets of notation for the SRX:
- there are the CLI commands
- there is the configuration

What I've been used to seeing in the past with other machines is that the "configuration" was just a list of CLI commands.  My assumption was that the machine just ran those internally at boot time in order to become "configured".  (Well, that's a simple-minded version.)

In the case of the SRX, there appears to be no text sequence of CLI commands that represents the configuration.  Well, one could construct one from start to finish I guess.  Instead, it appears that the configuration "is what it is" and however the CLI commands were used to get there is, well really, unimportant in some sense.

So, I was looking for confirmation that this is the case... that I had the right idea.

In the mean time, I've been reading and working away at this.
I've developed some of my own approaches to configuring the machine.
I'm using the J-Web GUI for most things.
Then, if that's too hard or not really suitable, I use the GUI CLI Tools / CLI Editor (which is really a *Configuration* editor) to do things like copy and paste long lists of web filter categories, etc.
I find that bouncing back and forth between the two is useful.
For example, if I don't know where or how to put something in the Configuration then I might put it in with the GUI interface, see how it looks in the Configuration, and then edit the Configuration from there.

How do others deal with it?
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
I can't tell that much for JunOS, but with ScreenOS I work similar. WebUI for the quick check, simple change, some overview etc., but more complex stuff is made via CLI scripts. E.g. building a new VPN tunnel is much easier if you have the set of commands ready, only needing to replace individual parameters.
I certainly would do the same with JunOS. When I tried to use the J-Web GUI (on an EX switch) it was painfully slow, however.
The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

For juniper, it is good to know:

1. At least basic programming in C or similar languages.

"Junos as a Second Language" is pretty good.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
DarinTCHSenior CyberSecurity EngineerCommented:
To answer a few questions
The cli and the config have no direct relationship
The cli is one of many ways you can read the config and 'make changes' to Junos
As a matter of fact you can perform 1000+ cli commands and have 0 impact on the config
You do not actually have the config - you have a candidate config
A copy of the config
Which allows you to query and add/remove as you want without actually interacting with the Active config
Also allows deep inspection 'trace options' or debugging without crashing box
2-the GUI is another way to interact with Junos and 'see' the config
It is actually just as powerful as the screenOs GUI and perhaps even a little more capable
The downside is the extreme slowness....
as of rev 10 it is 2-3 times faster......but still real slow
I would venture that > 90% of network and security admins use the cli over the GUI
That's based on my own weekly query of network folks
Again one of the key reasons net screen was popular was the GUI which allowed says admins and non-cli folks a tool to easily interact with a firewall
Lastly one of the strengths of Junos is the structure Unix style BSD and then object oriented Very comfortable for many programmers and finally the standard display 'not display set'
Makes for reading the hierarchical config much easier for those new to networking
Or who like things 'logically' organized
To those of us switching from vendor x it may take a bit to change our mindset tho
Fred MarshallPrincipalAuthor Commented:
The "Junos as a Second Language" session is quite good for getting context - which is what I was looking for.

It's clear that the hierarchical configuration is more structured and logical than a random list of CLI statements.

Thanks for the insights!
Fred MarshallPrincipalAuthor Commented:
Thanks for the insights!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking Hardware-Other

From novice to tech pro — start learning today.