In the last video, we started configuring a small switch from the ground up.
Now we're going to finish off the config and include
a few tricks that you can use
We're getting back into it by getting the basic config underway.
This stuff is pretty common, so I'll try to move through it
fairly quickly to get to the more interesting bits sooner
First, the management types.
These can be in band or out of band.
In this config, I'm configuring the dedicated out-of-band
management interface ma0 with an IP address
for management to work correctly.
We would normally need to configure a route as well.
We're not going to do that right now as that's something special
that we're going to cover in detail in video. 14.
We can have an in band management IP as well.
This would generally be configured on a villain or IAB interface.
Nothing here should be really surprising to you
at this point.
Let's not forget our DNS servers,
which should be one of the easiest things in the world to do.
If I can talk the command correctly,
when I commit this, we get an error.
To be honest, I forgot that this would happen.
We get a warning that DHP is incompatible
with the zero interface configuration.
If we take a look at the zero interface, we can see that
it has configuration for DHCP as well as a static IP.
The DHCP config is there by default, and I added the static IP
just a few moments ago.
They can't coexist
So we have to remove one or the other.
I'm going to remove the dhcp config
the commit process works again now.
Setting the date is a bit different as it's done
with the set date command in operational mode.
We can't confirm the current time with show system uptime.
This also includes stats around when the device booted
but that's too manual.
I'd rather use end.
Once again, this is simple.
If we set more than one, we can add the preferred keyword
to select the one we'd rather use.
In this example, this fails.
DNS is not working because I don't have a default route to the internet
as I said before.
I'll fix that in another video.
So what else do we need to configure?
Let's not forget some basic SNMP config for management.
I'm not going to go into detail into how S&P works
as that's a topic of its own, which you probably know anyway.
On Junos, you just set a community
and optionally configure traps to be sent to a server.
You can do these commands for yourself if you want to
Let's work on management access next.
There are two main ways to manage a Juniper device.
The web console called J Web and the C CLP for CLP access.
We need to enable Sage.
I should need to tell you why we're using Sage, not Telnet.
J Web is just as easy to enable.
Just turn on web management https
and then tell Junos to generate a certificate locally.
Self-signed certificates are ideal but they'll be fine.
For example, if you want to, you can add some more config
to limit the interface that j web runs on set.
Custom ports and so on.
But I'll leave that for you to try out yourselves.
When we commit
Junos generates that self-signed certificate
I generally prefer the seal,
i force which and router management, but you can have your own preference.
Either SEAL I or web is fine.
You don't have to be a tough guy who thinks that you only can use
the C a lot because that's what real network engineers do.
If we log on to the web, we get a nice look at the device
and which interfaces are up where you can look at the back to.
As I move through the tabs, you can see the different types of things we can do
a job like configuration monitoring and maintenance and troubleshooting.
It's quite a useful web portal.
I'll leave it up to you to explore the web further.
You might remember that a few videos ago
I was talking about config files which are stored in slash config.
Well, in addition to that, there's a special config
backup called the Rescue Configuration The plan is to get our devices
into a good state and then create this rescue configuration file.
Junos will put this config into Rescue,
De-conflict, GZ and place it in config.
When a device boots it looks for unified dconf
gz, which is our normal config file.
If we're missing for any reason, perhaps due to corruptions,
the switch will load the rescue config instead.
If there's no rescue config,
Juno's will look for the previous version of the config.
Anyway, the idea is that the rescue config
is a known good state that we can recover our switch into if needed.
It's not just for automatic recovery either.
If we need to roll back to a good config in a hurry,
the rescue config may be our fastest option.
It can get you up and running while you figure out your next plan.
We can create it with the command shown here
at a minimum You should have the root password set
and you should have basic network configuration done
so you can reach the device after rollback.
You can even take a look at the rescue configuration if you want.
Much like you would look at the active config
let's demonstrate the rescue config.
First, I'll make some changes that I'm not happy with
and committed
Now we simply use the rollback command,
but instead of using a backup number, we use the rescue keyword
This rolls the candidate config back.
If we're happy, we still need to commit it.
Apparently some large routers have a physical button on them
that lets you automatically roll back to the rescue config.
I've never seen one of these myself though.
Maybe one day
Congratulations to us.
Our switch now has basic configuration.
Before we finish up, I suggest that we back up this config
so we can use it as a template another time.
We can't just use show run and copy to notepad
like we might do on a Cisco switch.
Do you know config is stored in a hierarchy, but we generally apply
config reset commands so we can't just paste this into configuration mode.
So we have two options.
The first is to back up the config either
by copying it to an FTP server by using SAP
or even just using show configuration and copying the output to notepad.
This is
structured data so we can't just copy this interview configuration mode.
Instead we can type load merge terminal.
This tells you not to expect structured config data
We then paste in our config and press control D
when we're done.
This is now
part of the candidate config which can be committed.
Merge means we're merging the new config into the existing config.
We could use load merge override to completely replace the config
if we wanted to.
There are a few other options you can use with this,
which I'll put in the study notes if you want to take a look.
Our second option is to export our config in a different format
when showing the configuration Pop it through display set.
This shows us the config as set commands rather than structured data.
You can easily copy and paste this directly into configuration mode,
just like you would on a Cisco device.
If you don't like copying to notepad,
you can pop through the save command to save the output
to a file on disk.
If you want to check out the config in a file is okay.
Use the test configuration command.
It's easier than loading the config and running a command check.
I'm interested to know what you think about using web config on a rather
a switch.
I generally prefer to see a life around
as an switches, but web config for firewalls.
Let me know what you prefer in the comments.
We've now completed part two of the series.
Click the video shown here to begin part three where we start
looking in-depth at Juno's hardware and software architecture.