[music]
So now we're going to go into the last section of today's
presentation. You decide that you want to design and create your
own labs. And what I mean by that is you're using somebody else's
topology like INE's or somebody else but you're going to create your
own topologies, your own protocols, and you're going to play with
their equipment.
So what's the best way to do that?
And by the way, when I'm done with all of this somebody asked me
earlier - I don't remember who it was - if I could just real quickly
do a demonstration on how to get into INE's racks and how to rent
time and stuff.
I'll show you how to do that.
So for those of you who are not familiar with that we will go into
that as soon as I'm done with this session right here.
Okay, so I talked about the pros and cons previously of using
a workbook. What are the pros and cons of not using a workbook,
doing everything from your own brain?
Well, you can custom tailor your lab based on your available resources.
That's nice. You can custom-tailor your lab based on your own interest.
You're not dependent on the interest of the lab developer.
You can do whatever features and protocols,
whatever IOS commands you want to do.
You have now opportunity to go into much greater depth on a topic
than is typically found in a pre-designed lab guide.
That's true. And this is probably the single biggest advantage.
Trying something and failing is a great learning opportunity.
For example, I have probably personally learned the most when I sat
down with a piece of paper and I said, okay,
here's what I want to do.
I've got two routers with two paths to each other and I want to try
to influence load-balancing, maybe influence my EIGRP load-balancing
based off of the load variable.
I don't care about bandwidth or delay.
I want to see if I can influence the load on a particular link to
get EIGRP to flip over to a link that has less load.
Let's just say this is actually something I tried recently.
I drew it all out.
I pre-configured it with IP addresses and stuff.
I discovered that I couldn't.
There's no way for me to get that to work.
Well that's not a failure in my mind.
Even though I couldn't get to get it to work,
that was an incredible learning opportunity.
I learned how to get EIGRP to factor load into the calculation.
I learned how to increase the load on an interface.
I learned all kinds of stuff.
So even though I wasn't able to meet my objective,
by failing, I learned a whole bunch of stuff I didn't know before.
You're not going to get that experience when you're following a lab
guide, right? A lab guide is typically built so that if you follow
the steps, you will succeed.
If you follow the steps, you will succeed in configuring
or doing whatever the lab developer wanted you to do.
They're not typically-- you're going to design something into a lab
guide to intentionally have you fail, sometimes but usually not.
And in my personal opinion understanding why something doesn't
work can be just as valuable as understanding why it does work.
I tell people all the time, look, when you're first learning about
EIGRP what are some of the first things they want you to know?
EIGRP neighbor relationships.
What's required to make the neighbor relationship?
The K values have to be the same.
The autonomous system values have to be the same,
so they give you four or five things.
But they don't really tell you about well,
what are you going to see if some of those things don't match up?
That's very valuable information.
I love going into a lab and saying, okay,
what if my K values don't match?
What if my autonomous system number doesn't match?
Can I see something in a debug?
Can I see something in a sys log that will clue me off to that?
Because that's going to help you in the long run with troubleshooting
stuff. Just getting it to work, and getting it to work,
and getting it to work, that's not really going to help you if you
ever need to troubleshoot this stuff.
Now what are some cons to designing your own labs?
Well, you might end up spending valuable time on troubleshooting
problems. Now there's a silver lining to this cloud but some people
could say, hey look, I rented three hours on this rack and before
I even pressed the start button I came up with this nice lab I want
to do based on private VLANs here, which go into DHCP snooping here,
which feed into EIGRP here, but I only got into the private VLAN
section - the very first part of my lab - and I started getting error
messages and it wasn't working right, and I consumed my entire three
hours just troubleshooting private VLANs.
Well, you can look at that one of two ways,
right? That could be a con that you weren't able to complete within
your allotted time what you wanted to complete,
but the pro is you learned a heck of a lot about private VLANs during
all that troubleshooting, right?
So there is a silver lining to that.
You may miss critical features and protocols,
right? You are designing your lab based on what you think is in the
certification exam and you did that probably based on the blueprint,
you looked at the route or the switch or the CCIE blueprint,
and you're doing your labs based on that but blueprints don't always
give you the full picture.
A lot of times there's features and protocols that these exams expect
you to know that they don't put into the blueprint.
Personally, I think that's kind of nasty that they do that but that
does happen and so, if you're just making your labs up yourself,
how are you going to know what you missed?
That might be a problem.
You might accidentally design a lab that's unsupported by your available
hardware and feature set.
It happens, right?
I mean, when you're going back to building the home lab,
chances are you're not going to be able to think of 100% of everything
you're ever going to want to do on your home lab.
There's going to be something you're going to miss.
Same thing here.
If you're using a remote rack, you know in advance what the topology
that remote rack looks like.
You know in advance what hardware and software is in there.
So maybe you think to yourself, okay.
based on this topology right here, I want to create IPv6 tunnels.
I want to do some ISATAP between these two routers right here.
And you spend a bunch of time writing up your lab,
drawing it up.
And then you press a start button, only to discover ISATAP is not
an option. I'm doing tunnel mode and I don't see ISATAP in there
because this feature set on this switch or router doesn't support
it. That kind of stinks because now the time is counting down,
and the lab you developed, you can't even do.
So you'll run into that sometimes as well.
And you might leave yourself down a rat hole.
What I mean by this is you might start out by developing a lab on
I don't know, DHCP snooping or something like that.
You got all built out, you drew your Cloud,
your IP address and everything, press the start button on your remote
rack and now your two hours that you reserved starts counting down.
And you get a little into it and you say,
oh here's a cool keyword, I've never seen that before,
I wonder what that does?
Oh, let me try this, let me try this, and all of a sudden two hours
has gone by and you've just been stuck on this one command trying
out various keywords, doing a little bit of research right here,
and your time is up and you never even got 20% into the lab you wanted
to get into because you got stuck in this rathole.
Once again, pros and cons.
The pro of that is, well, you learned something still,
it was a learning experience.
The con is, you just spent money on two hours and you did not meet
your objective of the lab that you developed that you wanted to do.
So those are some cons.
Okay, so what are some approaches to designing your own labs?
Two approaches.
Approach number one, you can find an available topology first and
design your labs around your resources.
So for example, you say, okay.
I've looked at six different vendors who offer me remote racks and
I'm going to go with INE, of course.
I'm looking at this topology diagram here.
INE has given me three switches and four routers,
a couple of backbone routers I can't really touch,
so I can't factor those in.
So I really got four routers and three switches available to me.
Based on that, I'm going to build my lab on that.
I'm going to say, well, with that, I could have a couple of autonomous
systems. I could do some filtering here.
Blah, blah, blah.
So that's one approach.
Approach number two is start by building your lab on paper.
Saying to yourself, okay
Here's what I want to do.
I want to do eBGP between three different autonomous systems.
Within this autonomous system, I want to have iBGP with five routers
so I can practice route reflection and local preference and blah, blah, blah
okay, so this is what I want, and now you got out and you start
looking at some vendors and say, okay does this vendor offer a rack
where I can implement this thing I've developed.
That's the second approach.
Personally, I find approach number one to be more effective.
I think it's better to know what your constraints are first,
pick some remote equipment, some remote rack,
whether it be the Cisco learning labs, whether it be INE,
whatever, and then build your topology based around the hardware
and the connections that you have available to you.
As I said, you're going to find it very difficult to find racks that
meet a predesigned topology.
All right, finding the equipment.
So you say, okay, well how do I choose?
There's the Cisco learning labs, there's INE,
there's this, that, and the other thing,
there's lots of companies out there that are providing access
to their equipment.
How do I select one?
Here's some key things to look for.
Price, clearly.
Right? That's a factor.
I don't think I have to talk too much about that.
The availability of both routers and switches in a single topology.
So you're ideally going to want to look for topology that has a combination
of routers and switches in it which will give you more flexibility.
If some vendor out there says here's our switching lab and they got
five switches.
Here's our routing lab with five routers.
Well now, you're kind of limited in what you can do if you can only
choose one or the other.
Is it real equipment or emulated equipment?
This is a big one right here.
Now for routing labs, emulated equipment typically is fine.
For example, if you're using GNS or the Cisco Learning Labs or something
which use IOU, you can pretty much do everything you want to do with
routing with that.
Switching though, we've already talked about that.
When it comes to the more advanced switching topics and features,
you're going to need access to real equipment.
An emulated or a simulated switch is just not going to cut it.
You're going to find yourself getting very frustrated over a lack
of commands, a lack of features and protocols you'd have available
in a real physical switch.
So you should know that.
This venue right here, this guy wants to rent me his stuff for $1
an hour. Wow, that sounds really good.
Oh, but what am I doing?
I'm actually getting into a server that's running VMware and I'm
getting access to some virtual routers and switches.
Hm, it's cheap but I'm going to be kind of limited on what I can
do there. You want to select a topology that's flexible.
What do I mean by that?
Well, you want to find a topology that has a lot of link redundancy,
a topology that's got, you know, between your switches.
If you've got a topology of switches and there's just a single link
between then, how are you going to do ether channel with that?
How are you going to do topologies where a link fails and has to
back up to another link?
You're not going to be able to do that.
What about router topologies?
If you got a topology where a router just has a single serial interface
to another router and that's it, once again you're kind of limited.
Ideally you want to find a topology that's got multiple links
to multiple paths through the topology,
so you can have all sorts of designs that you can come up with.
Scheduling availability, another thing here.
Most remote systems has some sort of scheduling tool,
and most of them, certainly INE's, would let you see in advance what
the availability is.
So this is also something to look for.
Check it out. If you go onto some vendor's website and you say,
oh, that's an awesome topology, pretty decent price.
But you look at the schedule, and most of the time it's in use,
and it's just like little tiny snippets of time here and there where
it's free, probably don't want to plop your money down with
that vendor because you're going to be frustrated,
you're not going to have access to that rack when you want it.
That's something to look at.
Doesn't require you to download any special front-end software.
Now, INE does not require this, but some other vendors require you
to download some Java software or some other stuff in advance.
And you're using their special GUI, their special application to
get in to the routers to type in the terminals and stuff.
Are you okay with that?
How do you know you're not downloading a virus?
How do you know it's not going to mess up your laptop or something?
So that's also something to consider.
Are there pre-loaded configurations available?
Now, if you're going to be developing your own labs from your head,
a pre-loaded configuration is probably not going to really do much
for you, so that's not really a benefit.
One other thing on here that is not really listed is that you do
not want to spend any money on a vendor's remote rack until you can
see the topology diagram first.
Makes kind of common sense, but it's pretty important.
You've got to know what you're getting into first before you spend
money with them.
Make sure you can see-- okay, if I get into this rack,
how many devices are in there?
How many connections do they have?
Is it pretty clear to me in their instructions how to move around
between the different devices?
So you should know all that stuff upfront.
What I call creative labs, these are labs that you're designing yourself
from your head.
I typically recommend that they're used as a supplement alongside
reading, or watching videos, or something.
So the way I typically do this is I might be watching a video,
for example, and some instructor is teaching me how to do MPLS VPNs.
And here she is going through the steps.
And I pause it for a second.
I say, based on what I've just learned here,
I think I'd like to try that.
I pause the VLAN and I write on my piece paper,
basically what I've learned I think if I have four routers here,
and I have them configured with this.
I put these IP addresses on and then I resume the video.
So, it's used as a supplement.
Or if I'm reading a book and I'm reading about,
okay, here's the requirements for an OSPF adjacency.
It says, here's the various stages of OSPF,
init, 2A, start, exchange, loading full.
I say, oh, I'd like to see that.
I'd like to try and build a relationship and do a debug and see if
I can see what's happening right there.
I'll stop reading and I'll design a lab.
I'll say, okay, let me put these two routers together and this is
the IP addressing scheme I'm going to use.
I just want to do a debug to see OSPF adjacency.
So, as I'm getting ideas as I'm watching videos or reading things,
I'm writing down those ideas and I'm coming up with labs I want to
do, to try to flush out those ideas and make them real.
So as inspiration strikes you, pause your reading,
your VOD watching.
Write down what you like to do.
I always say, try to come up with ways to intentionally break it.
That's just as valuable as making it work.
And draw the minimum topology that would enable you to accomplish
your objective.
So let's do an example of this.
Let's say that I had just read about BGP AS-path prepending.
I thought, I'd like to try that.
I want to do that.
So I think to myself, Okay.
What is the minimum requirements I would need to create a lab that
would do BGP AS-path prepending?
Well, I know that from what I learned, AS-path prepending is done
between autonomous systems, right?
It's an external BGP thing.
When one company wants to influence another company,
I say to myself, okay, I know at minimum I'm going to need to develop
a topology that has two autonomous systems,
let's say. I ask myself.
I say, could I do this with just two routers?
Is it possible?
With BGP AS-PATH prepending, the idea is a single router has learned
from a different company - a different AS - the same route but from
two different locations.
This router says, okay, I've learned about the 90 network via this
guy up here and via this guy up here.
They're trying to influence me by using AS-PATH prepend.
I think, okay, let's see here.
This router now needs to learn about one route from two different
locations. Can't really do that with just two routers.
At a minimum, I'm going to need three routers to accomplish this.
I say, all right, I'll do this.
Now how these guys are connected, I don't care.
I don't care if it's Fast Ethernet, I don't care if it's serial.
That's irrelevant to me, so I'll just draw some lines.
Okay. Now let's say, all right, this is going to be AS 100,
just to make up some numbers here.
AS 200, put some numbers on these routers so I can identify them.
Great. Now I say, okay, well, I'm going to need to come up with some--
let's see, what else do I need here?
These Router 1 and Router 2 are going to need to advertise the exact
same network to Router 3.
Let's see, what's the minimum I could do to accomplish that?
Minimum hardware, I'll just create the same loopback in both of them.
Loopback0 20.20.20.0/24.
This way I don't need an additional cable,
I don't need an additional interface for these routers to advertise
the exact same route to each other.
Okay, great.
So now I've just developed the minimal topology I will need to do
AS Path prepending with just three routers and two interfaces,
I could practice this feature.
You're going to want to do something like this.
Think about what you want to practice, draw it out,
minimal possible, and then replicate that on your rack.
Now you compare your drawing against your available lab topology.
Here's where you take that drawing you came up with and you go to
the INE rack you decide to use or the Cisco learning lab rack you
decide to use.
You say, okay, how am I going to incorporate this into the equipment
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]