Here it is, the final video of the series, but we're not going to just phone it in.
There's some really good tips and tricks here.
So let's get right into it.
Want to start with our old favorites, ping and trace frame.
When we use your ping, it gives a Linux style of output
and will run until we stop it.
If you prefer the Cisco look at the rapid key word,
which sends five quick pings.
If we want Ping to ignore the routing table
and use a particular interface, we can add the bypass
routing keyboard
But here's the really awesome one.
Try using traceroute and monitor some time.
This will continually monitor the path to a destination,
making it very useful to track packet loss or high latency along the path.
If you press the
key, you can toggle different views
Do you know
is heavily based in FreeBSD in Linux and so other methods of logging.
If you've using Linux, you'll know about the logs in such a vast
flash log and in particular the messages log
the same existing Junos.
We can see the contents of any log using the show log command
to see the most recent entries pop this through the last command.
The boot process is also logged,
which we can see where the show system boot messages
Taking this a step further, we can use the monitor command.
This monitors files in real time and displays new additions to the screen.
That makes it a bit like using the Terminal Monitor command in iOS
or more accurately, like using tail dash if in Linux.
Use uses a bit in the final lap
Right now I'm removing a cable from an interface.
This event is logged to the messages file
and monitor displays it on the screen immediately.
If you're getting flooded by messages,
you can press escape queue to pause the output.
If you've been working at it for a while and you can't remember what you're
monitoring.
Use the monitor list command.
And when you're done, use monitor.
Stop to clean up after yourself.
And let's not forget
exporting logs to an external syslog server
or logging settings, whether local or remote,
are under system syslog hierarchy You can see, for example,
that messages and interactive commands are here by default.
Adding an external server is as simple as setting a host IP.
The facility and the logging level.
We can
also use settings here to send messages to the console port.
I would only recommend doing this during troubleshooting though.
If you take a look at the study notes that go along this video,
you can see how we can even redirect logs to another user's terminal session.
If you need it.
You can use the help syslog command.
This will give you extra information on log messages and what they mean.
Let's not forget our interfaces though.
We can monitor them to using the Monitor Interface Command.
This shows us real time statistics, which is useful to see
if the interface is being overused or if packets are being dropped.
An alternative is monitor interface traffic,
which is a real time summary of all interfaces by default.
This shows us a packet counter press be to switch to bandwidth.
If you want more, you have
monitor traffic interface, which is easily confused with the last command.
This is the same as tcpdump in Linux and captures exception traffic.
This cannot be used to capture transit traffic.
If this is giving you too much
Add the right file command to write to disk
instead of displaying the results on screen.
You can use monitor
traffic read file to check the results when you're done.
Next hour trace options which are very cool.
They are basically the same thing as debug in iOS,
except the output is written to disk rather than displayed on screen.
I think this makes them perform better.
Each feature in config can have trace options enabled
in this example where enabling trace options under interface is.
First, we set the file that it writes to.
This is assumed to be in slash var slash log.
If we wanted, we could even get off to send trace options output to as this
log server.
Then we set one or more flags.
Flags, all the events that we want to trace.
The flags will be different for each feature that is, the flags
we use on the interfaces will be different to the flags that we set on the system.
To keep it simple will just enable them all
We can see the logs we've collected
with the show log command
What if you want to monitor these in real time?
Easy.
Just monitor the file like we did earlier to make it even better.
We can pop the monitor command through match to filter the real time output.
Eventually the log file will reach a maximum size and it will rotate.
That means that a new file is started and the old file will be compressed
file size and the
number of files to keep are all configurable.
Of course, you can easily
find the most recent logs by piping through the last command.
There are a lot of system commands that we can use when troubleshooting.
I'm not even going to explain them all
as there are far too many and it would bores both to death.
However.
Here are a selection of chassis commands which will get you information
about your device hardware that includes things like temperature,
serial numbers, clusters, alarms, and things like this.
By the way, these will all be in the study notes for quick reference.
Here we have system commands which relate to June of itself.
This includes processes, logging alarms, disk usage, uptime, and more.
And finally, if you request commands,
these are used to perform system level tasks, including reboots, rescue,
config management, upgrades, formatting, storage, and things of that nature.
You might be wondering, though,
what's the difference between halt and power off?
This seems to depend on the platform as far as I can tell
that the same thing on each series switches on the platform.
No multiple shutdown or processes, but leave the box powered up.
This enables
you to boot it back up from the ceiling when you're ready to power off.
On the other hand, completely shut the system down and powers off the chassis
to finish off the series.
Let's talk about the next step you need to take.
If you need technical support for your Juniper switch router
or firewall, as with any vendor you can log support to get for assistance.
Juniper's tech support
team is called Jetpack or Juniper Technical Assistance Center.
After a ticket is
logged, you will need to collect some information about your device.
It will save time if you do this before they ask you.
So I'm going to show you how this is done.
The first command you need to run is request support information.
This script will take a while to run and it will generate lots of data.
It's basically a lot of show commands with the output
saved into the slash var log directory.
Once that's done, we want to archive everything
in the log directory with the file archive command.
I usually put them in the temp directory
that collects everything we just generated as well as any additional logs we have
and compresses them into an archive file.
Once that's done,
you can see the support on GZ file in this directory.
You just need to collect this file.
Perhaps with SAP or ftp have you want
and attach it to the data ticket.
This process will save you a lot of time.
We have made it to the final quiz of this series.
I hope these quizzes have provided some value for you.
Remember that you can review these concepts with flashcards
that are available from the members area of the website
and that's it.
You've made it all the way through the introduction to Juniper Series,
and I have to say it was pretty long for an introduction series
So what's next for you?
Perhaps the exam,
or maybe you're going to get a job working on Juniper routers and switches.
Let me know in the comments.
I'd love to hear from you.
Oh, and if you like this series, please subscribe.
You'll be the first to see whatever's coming next on this channel.