Alright, let's take a little tour of our Cisco modeling labs environment.
Now I have switched over to my production environment, the virtual machine I
spun up
as a demo.
I'm not going to use that because again I've already got labs built in my CML
environment,
I've got it licensed.
And so now we see that since I'm on the dashboard, I've got a lot of labs
already built.
I've done some CCIE labs in here and all kinds of things.
And it's wonderful as you build these out that it gives you a little preview.
For example, this practice lab here, we see a little bit of a layout as far as
which nodes
and even the colored squares.
If I click on this, it opens up and it shows me the full topology.
So it's pretty cool how it gives us a little bit of a preview for that.
What we want to do here, especially if your environment is blank, is to create
a lab that
we can play around with.
So up here we'll see add an import.
If at any point in the course we provide a CML file, you would just download it
and click
the import button and import it in that way.
For us right now, we're just going to click add here.
We're going to make a new lab.
I can come up here.
I can change the lab title.
Let's just call it SDWAN test, something like that.
I could add a description if we want to, but that's not required.
The main icon up here at the top we're going to use is this one right here for
adding nodes.
That's just the icon that they came up with.
It's a little plus icon and it's part of a little topology in there.
So I can click add nodes and I could add, for example, a catalyst 8000V,
something that
we might use at the edge of our SDWAN environment.
If I want to just practice some routing and switching, I could add an iOS V or
a CSR 1000V.
Either way, these would be devices that I can use in a routing environment.
Also note, as I hover over these nodes, it does give me the requirements.
For example, a CSR requires 3GB of RAM and 1V CPU, whereas a catalyst 8000
requires 4GB
of RAM, but still only 1V CPU.
Meanwhile, if I come down here to the SDWAN Vedge, it's 2GB and 2V CPU, but
again, that's
a Vedge specifically.
So, we've got to be careful to make sure we know which devices we're deploying.
For example, a catalyst SDWAN.
This is the one that I was talking about earlier.
It does require 5GB of RAM, which starts to eat away at our memory utilization.
So down here at the bottom, we will see some statistics as far as numbers, a
percentage
of CPU and memory and disk.
If these start to get too full, then we won't be able to boot up devices.
So especially pay attention to the CPU and memory, and recognize I've actually
got a
lab running, which is why my CPU and memory are already utilized here.
But at the start, we shouldn't see that those have a whole lot.
So I'm going to come up to add nodes, and I'm just going to drag out a catalyst
8000V
here, and I'll drag out, let's get a switch out here.
So I can come down, and I've got a number of options.
For example, I could just use an unmanaged switch to make a basic layer 2
domain.
It says it's basically a Linux bridge.
We could also put an iOS virtual layer 2 switch out there.
So we could do that.
I could also deploy a catalyst 9000 beta, so it says no support.
Notice how much RAM that requires.
So that would be a fully featured catalyst 9K.
So let's just go ahead and do an iOS V layer 2 switch.
That's a very basic iOS image.
It's not nearly as featured as a catalyst 9000 would be, but it does give us
some basic
switching.
Then, for example, I could also deploy, let's just grab another 8000V and
deploy it on this
side.
So I might want to make it so that these routers could communicate via the
switch.
So now I can right click on this and say add link, and say, hey, what do I want
to connect
to?
Let's connect it to the switch.
And now I can say on the 8000V which interface I want, we'll just do gig ether
net 1.
And on the iOS V layer 2 switch, we'll just do ethernet 0/0.
Same thing over here.
We'll just take the next available, which fortunately it does that here.
Just grabs the next available because it knows gig 00 is already consumed.
All right.
So now we can do a couple of things.
First of all, we could make it pretty as we saw before.
I've got some shapes in the background.
So I could make, for example, this part of one domain layers the square behind
it.
I could change the background color to be red or something like that.
So that's cool.
And then I could add another rectangle here.
So you can pretty these diagrams up and make it so that they're much more
readable.
Pick a blue color or something like that.
So there we go.
We can also click on this individual devices.
Notice that we haven't turned them on yet.
And so I can come over here to a couple of things.
So connectivity shows me what things are connected to, which is kind of nice
settings.
This node name does not get put into the configuration.
It's just how it appears here.
So I could say, I want to call this R1 for router one.
All right.
And boom, it shows up as R1 on the left there.
But again, the configuration hasn't changed.
So notice Cisco does give us a basic format for configuration.
So I could say, you know, instead of the host name called insert host name here
, I'm
going to call it host name R1.
This configuration will get applied to the device when it first turns on.
However, something to be aware of with CML is once it create, once we first
turn on a
device, it's going to create an actual virtual machine on the back end, not one
that shows
up in VMware, but just on the back end of this platform, it's going to have a
virtual
machine that represents R1.
That virtual machine is everything we'd expect to be persistent on a router.
For example, the configuration will be set.
So I can't change this basic configuration after I've first turned it on,
because this
is only for initial configuration.
It's going to grab this, paste it in.
And at that point, it's going to maintain its own configuration.
So if I hit let's just in fact demonstrate this.
So if I were to, for example, turn on this device, let's just call it actually,
let's
call it R2.
So now it's R2.
I'm going to right click on it.
I'm going to say start.
So I have just fired up R2.
It's going to consume some amount of memory and CPU as it gets going.
This green icon means that it's coming online.
So great.
Now let's say that I come on here and I say stop.
So oops, I didn't want to actually have that router running yet.
I wanted to create a configuration.
Notice the difference here.
R1 doesn't have any icon. R2 has this X. The X means that it has a, it has been
created.
There's a virtual machine essentially that is stored in my, on my disk that
represents
R2 and it's offline.
Meanwhile, R1 hasn't actually been instantiated yet.
So that's the difference between these.
So if I'm on R2 and I go to config, configuration is locked.
It's locked because I've already created this machine.
So if I want to change the configuration, I'm going to have to boot it up and
change the
configuration that way.
So what I could do is wipe the device.
If I wipe the device, it deletes the R2 image, the virtual machine that it spun
up using
the image.
And so at that point, I could change the basic configuration.
So I can right click on this and say wipe.
And again, this is going to delete the virtual machine associated with this
node.
It says it right there.
It's got a virtual machine that it has created on the back end and we're going
to wipe it
out.
Everything that it assigned to it, including the hardware IDs, the MAC
addresses and so
on and so forth.
And so I'm just going to confirm this and we'll notice that X disappears.
Now it's back to its pre-initialized state, just like R1 and this iOS switch.
And now I have access to the configuration once again.
So I could now say host name R2 and I can add anything else to this.
I could give interface gig one a basic configuration.
I could say, and by the way, I need to make sure that this will be accepted.
So I need to make sure I have no typos, but interface gig, actually that's gig
one there.
Pay attention to that.
So interface gig one and then I could add a description, say test description
and maybe
a no shut down, something like that.
Make sure I click save because it will not apply it if I haven't clicked save.
Let's see if I clicked.
Yeah, I see I haven't actually saved it on this side either.
So now that I've saved it, now I can turn on these devices.
So I'm going to start R1.
I'm going to start R2.
I could also come up to lab and just say start the whole lab.
That would have started all three devices, but let's come over here real quick.
We'll call this switch one.
Oops.
Check mark.
There we go.
Then configuration, I'm just going to call it switch one, click save and that
'll be do.
I can also start here.
We see lots of places that we could start these devices.
All right.
So that's great.
We've created a basic topology.
How do I go about configuring these?
And by the way, I can zoom up.
I can, we've got all kinds of tools up here.
You can play around with these if we want to shapes labels.
I could put a label out here, maybe with a subnet, something like that.
An IP address that belongs to this interface.
We've got all kinds of options for making this lab a little bit more readable
and a little
more usable in the future.
But either way, we've got some options up here.
So I'm going to, let's see here.
Oh yeah.
Let's click on R1 and I want to console into this.
So I can right click, say console and it opens up the console down here.
Now, I haven't connected to it yet.
But I need to click open console and what we'll find is as we try to console
into multiple
devices, we'll have multiple options down here.
So I'm going to expand this and we'll see that this router is booting.
So it's still in a booting state.
We haven't actually booted up yet.
Let's go ahead and go to switch one.
Let's see if that's booted.
So now we've got switch one tab, open the console.
And yeah, we are booted over here.
So notice, as I enable, that we've got a host name already associated with the
switch at
switch one because we added it to the initial configuration.
So I can now configure R1.
Oops, let's click on the tab here.
And it's still booting up and R2 is probably booting up as well.
You can just drag this around as needed.
Let's console into R2.
Yep, it's still booting up as well.
No problem.
But what we can do is-- oh, here we go.
All right, so we've got access to R1 now.
Switch one.
If I look at-- and I keep clicking the wrong thing.
Let's just go ahead and switch one.
Do a show, run, interface gig, 0/0, gig 0/1.
All right, so those should be on VLAN 1.
If I do a show spanning tree for VLAN 1, we should see that, yep, they're all
forwarding.
So this is just basically a layer to pass through switch at initial
configuration.
I could certainly assign some VLANs and create a larger topology.
I just want to make R1 and R2 ping each other.
So I'm going to get on to interface gig 1 and do a no-shot.
And then an IP address, we'll just do 10.0.0.1/24.
And then we'll go over to R2, which should be booted by now.
We'll click on it first.
There we go.
config T, let's do a show, run on interface gig 1.
And we do see that that description was put in place.
So that's great.
The initial configuration was successful.
I could have applied an IP address.
So we're going to do an IP address 10.0.0.2/24.
And let's just try to ping router 1.
And there we go.
It actually did work.
We'll do it again just for clarity's sake.
We see that router 1 and router 2 are able to ping 1 and other.
Perfect.
All right.
So that is how we can configure the devices.
Now I will be the first to admit that using the console inside of CML is--
I mean, I guess it's there for convenience.
It's really not the most optimal way to perform configurations.
I'm used to logging into a lab using Putty or Secure CRT.
Or I'm a Moba Term guy.
And so we've got our favorite terminal software packages
that we'd like to use.
And we can use that.
But we have to do a little bit of setup first.
And so we'll explore that in an upcoming video here
by leveraging the breakout tool.
So the last thing I want to cover here
is the concept of external connections.
A very important part of SD-WAN is managing the environment,
not via console, but via a web browser that connects to SD-WAN
manager.
So I need to be able to log in SD-WAN manager
as if it's on the same network that I am.
So we're going to need to leverage the concept
of an external connection in order to make that work.
Fortunately, CML is all about supporting that.
I come up to my no definitions.
I've got an external connector here.
So this external connector is truly--
let me zoom up here.
Imagine my PC is over here connecting into this cloud.
Now I'm going to connect this cloud into whatever environment
I want.
I could add it onto this switch and make
it participate in that same layer 2 network.
So we could certainly do that.
I could also just add it onto the side of router 1,
maybe put it into a management vRF.
But here's the thing about this.
When I click on this to configure it,
we do need to make a decision about what type of external
network to use.
If we're going to use NAT, that is
going to effectively deploy private IP addresses internally.
And it will allow everything to come outbound.
But inbound is going to be a whole lot trickier.
Basically, it's not going to be supported.
Because these are private IP addresses relative
to the outside world.
Instead, what we're going to do for SD-WAN is not use NAT,
which is, by the way, the default notice.
We're going to use system bridge.
This is going to bridge whatever network we have here.
It's going to bridge it out to the same subnet
that CML is connected to.
And so that's going to be very important for us
that we actually bring in the external connection
into some kind of management environment in here.
And then we can hang our SD-WAN manager and controller.
Well, we don't really need the controller.
But at least the manager can hang off
of this management network.
But for me, I spun up CML on the 192.168.17 subnet.
Well, that means that all of these devices
that I'm going to want to manage from my web browser on my PC
will need to be part of the same subnet, 192.168.17/24.
So keep that in mind.
But we do need to come in here and select bridge.
Because by default, it's set to NAT.
And once I turn it on, just like the other devices,
this becomes unchangeable.
I need to wipe it and change it at that point.
So that's how external connections end up working.
And then just one last quick note.
As we delve into CML, if we need to do any maintenance,
maybe spinning up additional network ports or doing upgrades,
if we go up to Tools, System Administration,
we'll see that this link down here
is what takes us to that cockpit service.
So I come over here and we see that it takes me to the cockpit.
It's a totally different interface
that allows me to perform basic-- oh, that's right.
It's sysadmin here.
I'm going to log in.
And now I can perform things such as, hey,
I could actually copy my rough plat over live
if I still want to upgrade the images that
are out there and those kinds of things.
But for the most part, we're just going to be hanging out here
in CML at the dashboard, adding in my topologies
and creating topologies using the image definitions.