lab guides are written based on one of
two assumptions.
The first assumption will be that you, as the customer,
have access to the same equipment as the lab developer.
Other lab guides will not make that assumption.
They will say, hey look, here's a lab I developed in GNS3,
or here's a lab I developed on my home rack,
but it will be up to you to recreate that somewhere else.
You will need to find or build your
own topology to match that of the
lab guide. My personal advice - and it's not just because I work
for INE, I am a little influenced
that way - but my personal advice
is that if you decide to use a pre-designed lab guide,
select one that allows you access
to the same equipment as that used
by the lab designer.
Why? Well, there's a lot of reasons for that.
If you're using a lab guide that
was built by someone and you don't
have access to the exact same hardware as they do,
for example, say they built something in GNS3.
You might not have access
to the exact same IOS images
that they used in their GNS setup.
Or let's say they built something
on their own home rack.
You don't have access to their home rack,
so what's that going to mean?
Well, that might translate to you
might not have access to the same
quantity of interfaces as they do.
Maybe in the lab they designed,
they have got seven serial interfaces
and the best you could come up with is five.
That's going to be a problem.
You might not have access to the
same types of interfaces as they do.
We'll take serial interfaces, once again, as an example.
Some serial interfaces are slow speed.
Some serial interfaces are high speed interfaces.
They built their lab using high
speed serial but all you've got
access to is low speed serial. That's going to be a problem,
because now your OSPF cost,
your EIGRP bandwidth is going to
be different than what they came
up with when they developed the lab.
If they supply any preconfigs for
the lab, those preconfigs will not
copy and paste into what you are using,
so you'll have to spend a lot of
tedious time editing what they've
given you. Maybe their preconfig,
say, paste into your switch,
each interface says, Gigabit 001, 002, 003,
but on your switch it's FastEthernet 01,
FastEthernet 02 well now you have
to edit all that in a text editor.
You might experience bugs that were not present in their lab.
They designed it in GNS using
a certain flavor of IOS that you
don't have access to.
The version of IOS that you are using
might have bugs that they didn't have,
and now you got to deal with that.
And then lastly, you might not have
access to all the commands and
features that were present in the lab designer's IOS.
Maybe the IOS they used has a certain keyword,
or the output of show command is a
certain way that's not matching
up with what you have.
That's the risk that you run if you're
using a lab guide that somebody
else built and you don't have
access to the same rack or the same
equipment that they do.
That's the risk that you're running.
So some time management techniques
- what's our objective here?
We want to avoid idle time.
Every single minute in that rack
is costing you a nickle or a dime
or something, and that can add up after 5,
10, 15 minutes of not using that rack, so we want to avoid that.
Here's things you should do.
Read through the lab guide prior to renting any time on the rack.
Ensure that you understand the objective:
what is this task really
trying to get me to do?
What's the ultimate endgame of this task?
What am I supposed to learn from it?
Ensure that you understand the instructions.
If they're badly written, if the grammar is bad,
you might say, Forget this lab.
I can't even understand what this
guy's trying to tell me to do.
So make sure you can understand everything in there.
Ensure that it's readable.
You might be going through a lab guide and it looks good,
but all of a sudden, on page 5,
there's a bunch of weird characters
in there - some editing mishap
happened and a particular paragraph
or a series, you can't even
understand it because certain things
have been garbled.
That will influence it.
Ideally, if you can, estimate the
amount of time you will need for
each task. For example, you might
read through a task that's really long.
You've got to scroll through
lots of HTML to get from the top
to the bottom, and you say to yourself,
I think if I do this task,
it's probably going to take me about an hour.
Okay, do you have an hour right now to do it?
Are you on your lunch break?
Do you have a full hour?
Do you have a conference call to
do in about 45 minutes from now,
or maybe you've already rented some rack time,
you've only got 45 minutes left of your rack time.
Do you have time to accomplish this?
Or on the flip side, if you say, Well, I think I can do these two
or three tasks in probably a couple of hours,
knowing that advance will prevent
you from plopping down a bunch
of money and pre-reserving six hours of rack time.
Why spend money and reserve six
hours when you're really only going
to need about two hours?
So that's good to know how much
time you're going to need for each task.
If you're not given the IOS
command to accomplish a task,
look it up and write it down.
This will save you a lot of time as well.
You don't want to be going through
the config guides and the IOS
command references and stuff while
that time is counting down on
your remote rack and consuming money.
Print multiple copies of the topology drawings.
You want to have hard copies of
those topology drawings so you can
write on there, okay, here is what my OSPF area is.
Here is who they want me to make the designated router.
Here's the IP addresses of everything
because they didn't give it to me.
So make sure you've got all that stuff upfront,
before you click the start button, or the access button,
or whatever it is, on your remote rack.
Now, once you start working on the remote rack,
ignore any timers.
You don't want to be
sidetracked by constantly looking
up in the corner there, and saying, Okay,
I got 15 minutes left.
I got 12 and a half minutes left.
I got 9 minutes left.
It's going to cause you unnecessary stress.
You want to be focused 100%, on what you're doing right now.
Don't worry about how much time is left on the rack
once you started out.
When you feel the urge to experiment, do so.
I reckon now, one little caveat here.
If you're getting through a task, and maybe the task says,
Okay, issue the show command and take a look.
And you say, You know what?
I wonder what would happen if I went
back and I typed in that previous
command but I added this keyword to it.
Well, you can do that but here's the thing.
Before you go off track and you start
doing things off the lab guide,
save your configs.
In the router switch, issue the command terminal monitor 0 -
term mon 0. Type show run.
And by doing term mon 0, that means
it'll just scroll through the
show run from beginning to end.
It won't pause and say more, more, more.
Term mon 0 means start and just
keep going until you reach the end
of the command.
Do show run, capture it all to a text file,
and now do your experimentation.
Play around because that way if you mess something up,
write erase, reload, copy and paste your config back in,
and you're right back where you
were before you start experimenting,
before you went off track.
When you have an aha moment, write it down.
You say, Oh cool, look at this.
I was messing around with the load on a particular interface,
but no matter how I mess around with the load,
when I do my show IP EIGRP topology,
it never changes in there.
Apparently, the actual load of
the interface is not affecting my topology.
Aha, I didn't know that.
Write that down so you don't forget that.
If lab tasks are independent, not cumulative.
So what I mean by here is,
there's some lab guides where they're
written in such a way that you can
go right to lab task number 9,
skipping the previous eight tasks,
or right to lab task number 17,
and download an initial configuration
and it starts you right there.
It's not forcing you to go from 1 to 2 to 3 to 4 to 5.
That's what I'm talking about. If they're
independent and not cumulative,
try to recreate some of the previous
tasks from memory and add
to your current task.
Here's an example.
Maybe you're doing a switching lab,
and in task number one it had you create
some VLANs - gave you the commands
for that - some VLAN verification.
Okay, now on task number two, when you
download the initial configuration
or you copy and paste it, it's already
got those VLANs in there from
task number one.
Well remember, what's your objective here?
Your objective is to memorize these commands.
So maybe it's a better idea to,
instead of downloading that initial configuration,
type it in yourself.
Even though the lab task number
two assumes the VLANs are already there,
why don't you recreate them a second time,
a third time, a fourth time,
because that's what's really going to
help to reinforce these commands
and get them in your head. And save
your configs often to local.txt files, to text files.
You'll never know, you're using
somebody else's rack, their data center
could have a power outage and all
of a sudden, you're in the middle
of your stuff and you lose everything.
Or a particular router or switch you're on could crash and die.
Nothing more frustrating than you
spent the last hour and a half
creating this really complex convoluted configuration
and you didn't save it.
You never issued write memory,
and now the thing crashes and dies.
So, frequently save your configs to
text files so you can recopy and
paste them if you have a need to do so.
[music]