I have available to me?
Here's where you're going to add port numbers and interface numbers
to my drawing to match the lab topology.
I say, okay, let's go back.
This is what I'm going to build and this is the rack available to
me. Right now, I'm just looking at my LAN connections.
I know I need three routers.
Why don't I just use Routers 1, 2, and 3 expand this a little bit
here so you can see this better.
Here we go. So routers 1, 2, and 3.
And according to my diagram right here,
3 is sort of a hub-and-spoke design, so 3 needs to connect to 1 and
2. Well, if I look at this, 3 does have two interfaces,
so FastEthernet0/0 and FastEthernet0/1.
Okay, so I'll draw that on here.
So we'll just say this is FastEthernet0/0,
this is FastEthernet0/1.
Okay, I got my interface there.
Now, to connect 3 to 1, how am I going to do that with my available
topology? Well, see here, I could go through switch 2 and do that.
So I'll just draw that into my topology diagram.
I'll say, okay, I'm going to have switch 2 right here,
switch 2, and that's going to be 0/3 on one side and 0/2 on another
You just start adding this in.
This can be 0/3 over here and let's say 0/ - I'm going to Router
2 - so 0/1-- okay, Router 1 0/2.
That ultimately leads me to fastethernet 0/1.
This is what you're doing.
You're taking what you conceptually developed and you're adding the
real logistics to this of what your actual topology supports.
I would do the same thing.
I'm not going to fill it in here but I'd say,
okay, for 3 to use his other interface fastethernet 0/1 to get to
Router 2, I would probably add in two switches and type in my interface
numbers. Eventually, I'd come up with a real drawing of the port
numbers and interface names and numbers I'm going to use to connect
this altogether.
Now you can devise your IP addressing scheme and any other prerequisite
configurations.
So I take a look at what I'm drawing right here.
And remember, we're doing all this before I actually rent any time,
and my money is actually counting down at all.
And I say, you'll see see here, in order to do my IP addressing--
let's just put in some addresses here.
Let's just say this is 3.2.3.3, let's say this is 3.2.3.2.
And so now, I come up with my-- let's just do this one over here,
since I've already done my interface numbers.
This one up here, 3.1.3.1/24.
At this point, this is where I start coming off of my pre-config,
so I can just copy and paste something into my router without wasting
valuable rack rental time.
So I say, this is going to be R3 enable config T hostname R3,
interface FastEthernet0/0, and let's put all my stuff in here.
I'm not going to complete this, but you just get the idea.
IP address 3.1.3.3 no shut.
And so by the time I'm done with this, I will have a configuration,
for R3 has got my IP addresses, it has my BGP configuration with
AS 200. And so once I hit the start button on my rack rental,
I can just copy and paste this in without wasting time of coming up
with it beforehand.
And then lastly, devise a rough time estimate for how long I think
it's going to take for me to complete my objective.
So I might think to myself, well, after I'm all said and done
here, this is actually a pretty small lab.
I think it's probably only going to take me about 15 or 20 minutes
to complete this but when I look at this company's website,
the minimum time I have to rent time on the rack is one hour.
I don't want to rent one hour and then just spend 20 minutes doing
my lab and then I'm done because that's wasted time,
so now that I know that in advance, let me see if I can come up with
some other objectives that will fill up that time so I will effectively
use that one hour slot that I'm renting because,
remember, my objective here is I don't want to waste money.
So, don't log into the remote equipment until you have enough objectives
to fill up your scheduled time slot.
When you're using a vendor's remote rack system for the first time,
you're not going to be familiar with it.
You're not going to be familiar with the menu system,
with how to move around in it, with how to start it,
with how to load configs, so be aware of that up front and just know,
just think to yourself, okay I'm really going to have to budget probably
a minimum of 5 or 10 minutes up front, maybe 15 minutes,
just to get familiar with the system but you only have to do that
once. So that will be a-- you might consider that money wasted,
but it'll only be once and then you'll be familiar with it.
But just be familiar with that.
Start with a clean slate.
Delete any existing configurations.
Now, when you get into their system, what this is talking about is,
ideally, when you log in to the vendor's rack,
it'll start out with nothing.
Right? No IP addresses, no host names, and you can just do all that
from scratch. But if for some reason you select a vendor's equipment--
for example, let's see you go with the Cisco Learning Labs and you
say, well, there's really no learning lab that says default.
So you say, let's see here.
I want to practice BGP.
I want to do AS path prepending.
And looking at the learning labs here, they've got a learning lab
that's on OSPF.
I don't care about that, but looking at the topology,
I think I could do my BGP lab here.
So in that particular case, when you log into that lab,
it's probably going to be preconfigured with some IP addresses and
OSPF stuff. What I'm saying here is wipe all that out.
Don't add your configuration to it because,
now, you might be introducing a whole bunch of problems that you
don't want to have to troubleshoot.
Just clean it all out.
Yes, it'll take maybe three or four minutes of time to clean it all
out, write, erase, and reload, but then start with a clean slate.
And after implementing your own initial config,
save them again to text files if any changes were made.
As I was making my pre-config there in my Notepad or whatever,
it's inevitable that I'm going to make mistakes.
I might forget to put the AS number after my router BGP statement.
I might forget to put the update source loopback0 after my neighbor
statement. There might be little things like that here and there
which as I copy and paste, I will realize and say unsupported command
or incomplete command or something like that.
Well, as I change that, change it in my pre-config.
So now, if I ever want to go back and redo that lab,
I fixed my text file.
It's perfect. I can now copy and paste it.
ready to go. You're probably going to want to play around debugs.
Debugs are fun, right?
Debugs show you all kinds of stuff.
It is a good thing to know what debug do I need to turn on to see
what I want to see.
What debug will show me what I'm looking for?
But as it says here, debugs can be hazardous to your health.
Keep in mind that when you turn on a debug,
what are you asking that router or switch really to do?
You're telling the CPU, hey CPU, even though you can do billions of instructions
per second, I want you to slow down and everything you think about,
I want you to send it to the console so I can see it.
If a debug is really chatty like let's say you do some sort of spanning-tree
debug and spanning-tree can be very chatty-- if you've got lots of
interfaces running spanning-tree and lots of VLANs,
you can turn on debug within a couple of seconds and [boom?],
all kinds of stuff is going on there.
Ultimately, you can end up crashing a system by doing that.
The CPU can just be so overwhelmed spitting out all that output to
the console that just freezes up or dies.
So here's a suggestion.
Number one, don't log it to the console.
You don't really need to see it in real time.
You don't want to have a situation where your inner remote rack,
you paid money to be there, and then you crashed it.
You don't want to deal with that.
So no logging console debug, which is basically saying,
look, when I turn on a debug, don't show me the results in the console.
Instead, take those results and send them to a memory buffer,
logging buffer debug.
And then I can just see the output of that when I want to.
So for example I can say, Clear log, start my debug,
like in this case I'm using an EIGRP debug.
Let it run for a few seconds, stop it with un all,
that's short for undebug all, and then look at the log.
Show log, and there will be all the output right there.
And I don't risk crashing the router or crashing the switch by doing
that, because there's nothing worse than crashing a device in
your rack and then having to sit back and wait potentially hours
or days for some technician to get to that rack and fix it again.
All right, so that brings me to the end of this.
Now I did promise you that before I finished I would show you how to
access INE's racks and sort of how to move around within them.
But before I do that, let me just see if there's any unanswered questions.
Are there any questions from anyone?
Nathaniel, you've got a good question here.
So Nathaniel says sometimes he has a hard time understanding what
the INE lab is asking him to do.
I assume you're talking about like instructions within an INE workbook,
I think. Are the Cisco labs written in a similar verbiage?
I always recommend to people, and this is why I say read through a
lab workbook in advance before you actually start your timer on your
remote equipment.
If you read through a workbook or a pre-designed lab guide and something
in there is unclear, that's your opportunity to contact the company.
Send a message to-- for example, you might not know who within INE
developed a workbook but you can always send a-- within INE's website,
there is a contact link and you can always send us a general e-mail
saying I've got a question about task number
5 in the route workbook.
Can you please have someone get back to me on that?
Send an e-mail to sales or support at INE.com or something like that.
That's your opportunity to ask for clarification.
Yeah, you want to get that clarification.
The Cisco labs, I don't know.
If you're talking about labs written on Cisco's website,
I have not looked at those so I don't know if they are well-written
or if they are not.
Imran asks, is there any way that we can use network monitoring
software like CiscoWorks, Cisco Prime, or SolarWinds to work alongside
your devices? I assume you're talking about a home lab,
not a remote lab.
If you're using a home lab, certainly.
If you have access to CiscoWorks or SolarWinds or something like
that, you can always install that and use that.
If you were accessing a remote lab, probably not.
You're going to be limited to whatever hardware or whatever servers
they have available in the remote rack.
[music]