Welcome to part two of the Introduction to Jennifer series.
In part two, we're focusing on device configuration at a deeper level.
We're kicking off in this video by looking at the active
and candidate configurations.
Juniper has an active config,
which is the configuration that is running right now.
When we run the show configuration from operational mode,
the active config is what we see.
Let's make a quick change to this config
by adding a VLAN
when we enter configuration mode.
Geno's creates the candidate configuration
to start with.
This is a copy of the active configuration.
This means that the changes we just made were in the candidate,
not in the active config.
While we we're in configuration mode We can use the show command
to see the candidate configuration e we see the changes that we've just made.
If we were to look
at the config from operational mode using the run command,
we would be looking at the active config so we won't see our changes.
If we were to run a command, the candidate configuration
would override the active configuration.
The config files are stored in the slash avast run db directory.
The candidate file is named juniper dot data.
This is not a file that you can simply open in a text editor.
Here's a fantastic tip that you should definitely know
if you want to see the changes between the active
and candidate configurations pipeline to show command through.
Compare anything with a plus symbol has been added with the set command.
Anything with a minor symbol has been removed
I'm going to put some bad config in now.
Its config won't work as this interface
already has an Ethernet family unit and we're adding an iiNet family unit.
We can't mix these two types on a single interface
You'll notice that this is not rejected by the CLP.
After all, our syntax is correct.
And perhaps we're going to fix up our config before committing anyway.
At this point we can run the command check command.
This will test the candidate to see if it's valid.
It won't actually commit the config though.
Of course, we'll see that fails
if we now remove the faulty
config in check again.
We see that there's still an error.
Why might this be happening?
Look at the candidate config for interface
g 007
Notice that the extra unit is still there.
We remove the IPv4 address but of the whole unit.
This is still invalid, so we'll remove that to
when we run committe check again.
We see that it's all fine
while we're on the topic of committing configurations.
Here are a few more tricks.
We can add comments while committing, which is helpful
if we want to track changes that we're making.
It's especially helpful if we want to rollback changes,
which we'll see in the next video.
We can also schedule a commit which enables us
to pre-provision changes that we want applied at a later time.
We will have a closer look at this in the lab
on the website if you want to check that out.
Commit and Quit is a great one.
It commits changes and drops us straight back to the operational mode.
And finally, commit repair can speed up our commits in some cases.
We look at that in the lab. If you want to see more
what would happen if we were working on a large router
where it's likely
that several other administrators are configuring at the same time.
In a case like this, there is only one candidate configuration file.
That means that we can override each other's changes.
This is certainly not an ideal scenario.
What can we do in this situation?
The best practice here is not to use the regular configured command.
Instead, we use configure private.
When we do this we're giving ourselves
a private copy of the candidate configuration.
If all administrators are doing this, no one will override each other.
Keep in mind, though, that a commit will not override
the other person's private candidate file.
As soon as we enter private configuration mode, we are presented with a warning.
Any changes that we don't commit will be lost when we go back to operational mode.
Now, as I said,
one user committing will not update the candidates of any other user.
We need to do this ourselves with the update command.
If we don't, we will not be allowed to commit.
What happens if we have conflicting changes?
Perhaps two users both try to change the hostname.
So in this case, the first will commit and that will work.
And then the next one will fail.
The second user does have an option to force the changes if needed.
There is a small caveat to be aware of
if you've moved to another part of the hierarchy with the edit command
you will get an error when you try to commit.
When we have a private candidate file, we need to be at the very top
of the hierarchy to commit.
The simplest way to do this is to use the top command.
What if you're making
critical changes and you can't afford to have your config overridden?
That's where you'd use Configure exclusive
In this mode, we're the only ones who get a copy of the candidate.
No other uses are permitted to make any changes.
The lock on the candidate file is released
only after we exit configuration mode.
It's always a good idea to back up your configs.
To do this, we can configure a feature called Configuration Archival
This takes a config file and automatically copies it
to a remote FTP or server.
For this we can figure an archive site
The one shown here is an FTP server.
Notice that the username is in the FTB path
and the password is listed at the end of the command.
The password will be encrypted before stored in config.
We also
need to configure when the backups happen.
The first option is a transfer interval
which runs a backup on a regular basis.
The alternative, which I prefer, is transfer on commit,
which backs up the config.
Every time we run, I commit
the config backup is created in the slash
our transfer slash config directory and uses
a particular naming convention as shown here.
The file is then moved to the archive site
and a syslog entry is generated
as an extra level of protection.
We can configure more than one site These additional sites
are only used if the first one is unavailable.
I hope all of that is thinking in well.
Of course,
if you have questions,
you can put them in the comment section here or over on the website.
I'm sure you'll agree that
the active candidate commit model is one of the best reasons to use Juniper
with the video shown here, and we'll start looking at
how to roll back our configuration to previous versions.