All right, my nodes are online and so we want to connect to them using the
console.
Once again, we're going to use the breakout tool here in order to connect via a
putty
or whatever terminal software we want to use.
I'm just going to go ahead and go to the click the home icon here and hit
refresh.
Anytime new devices come online, unfortunately, we have to refresh the breakout
tool, which
cancels all very existing connections, but it's not too bad.
I'm just going to restart them all.
So I can click now in here.
I should see that edge 11 through 14 are online.
And you may notice also that if for example, manager had port 9001 before this,
that now
these edges because it takes things in alphabetical orders, best I've ever been
able to tell edge
11 now has 9001.
So let's go ahead and flip over to our terminal sessions.
And so this should be edge 11, just going to log in with that Cisco Cisco that
they
gave us.
Yep, edge 11.
I didn't have to configure this.
It applied the configuration from our CML config that we applied.
I'm going to now load up our other four edges.
So this should be edge 12 and it is load up the next one.
That didn't work.
Went a little too fast there.
No problem.
Cisco Cisco edge 13.
And lastly, we should see edge 14.
So got them a little bit color coded so we can tell when we change to a new
terminal session.
But either way, we've got again, edge 11 here to start with.
So a couple of things.
First of all, if we do a show version, we're going to find that this is running
Cisco
iOS XC.
This is what we used to call a sea edge.
Now we just call them SD WAN edges because there aren't any V edges anymore, at
least
not supported by Cisco.
And so those have all been entered into the end of sale.
They're approaching end of life or maybe they're already there, but either way,
we're primarily
running on iOS XC in modern SD WAN deployments.
As I space down here, we can also see that this is a Cisco C8000V indicating
that yes,
it is one of those Cisco virtual routers as part of the 8,000 series.
Now I can do a, you know, that was a show version.
I can do also do other iOS commands like show IP into brief.
We should confirm whether our gig one and gig two IP addresses were added.
It looks like they were successfully.
And so notice also we have a few other interesting configurations.
So I did not add any configuration for 11, 11, 11, 11 being this system
interface.
I come over here to edge 12 and do a show IP in brief.
Yeah, indeed.
We've got 12 dot 12 dot 12 dot 12 and probably this is going to be familiar or
similar if
we have look at edges 13 to 14.
So where did this come from?
Well, this is a pretty good indication that these devices are part of the SD W
AN framework
at this point.
They've connected to our control components, namely the controller, which is V
smart, manager,
V edge and the validator V bond, which is was the initial point of contact that
got us
connected to the other controllers.
So the reason why we suspect that it's part of that is because this is
configuration that
we applied to manager.
Remember, we got into manager and we provided system IP addresses.
I didn't do that in CML.
I did that in manager.
And so we have downloaded configuration from SD WAN manager and furthermore, we
see that
we have created a tunnel interface.
This tunnel interface shares an IP address with gig one, which isn't a
coincidence.
Big one is how we were connecting via VPN zero to the control components.
And so that tunnel interface is using an IP unnumbered concept, which basically
just shares
an IP address with the physical interface.
It's going out.
It doesn't cause any problems that way.
It just conserves IP addresses and makes it so we don't have to deploy a
dedicated subnet
onto the tunnel interface.
So pretty interesting there again, at this point, our focus is more on the fact
that
it's iOS XE and we can run a lot of iOS XE commands and we'll go take a look at
manager
after this, but it's pretty good indication that we are connected to our
controller or
control components.
So the big question is, can I do a config T?
The answer is no.
When we're in what's known as controller mode, which is not stand by our
standalone mode,
standalone mode would be outside of SD WAN.
Controller mode is running Cisco's SD WAN flavor of iOS XE.
And so it's not the full iOS XE configuration.
So at this point, could I change the IP address?
Let's say I messed up the IP address and I put two, five, three here, something
like
that.
How would I go about changing it without config T?
Well, here's what's kind of interesting.
I can do config dash and we have this config dash transaction.
So T doesn't stand for terminal.
It stands for transaction.
I can do a config dash T hit enter and lo and behold, we're in a configuration
prompt.
What just happened?
Well, Cisco is basically trying to remind us that this is not an iOS XE
traditional
configuration.
I'm not logging into this router and creating a configuration like I normally
would.
Config T interface gig one and third IP addresses on.
At least I'm not supposed to.
Can I do it?
Absolutely I can.
I'm just not going to do it with config T.
That's going to remind me when I try to do it via config T, which most of us
have is
muscle memory at this point that, hey, that's not what we do.
We shouldn't be logging into this router expecting to do any kind of important
configuration.
Most of the configuration should be done on our manager device.
That's going to leverage its own API calls with the devices.
It might send things through OMP, which is part of V smart or the controller.
However, it's going to respond.
It will take care of that configuration for us.
We should not be expected to be logging into these devices and doing
configuration once
we're online and operational.
Now, while we're trying to get it online and operational, it's a little more
fair game.
I need to be able to make sure I can give it the right IP address or configure
it for
something that maybe we weren't prepared for going into the install, whatever
that was.
So for example, once again, if I do a config -t, I can now get onto it.
To an interface like Gig 3, and actually we have to specify Gigabit Ethernet 3,
doesn't
like as many.
Well, let's try this again.
Okay.
So interface Gig 3, that should work.
All right.
So I forgot.
It's not the Gigabit Ethernet it's looking for.
It's actually looking for the space, just a small nuance there that it can't
handle running
the three together with the full interface name.
So Gig Space 3 should get us onto Gig 3 interface.
Scroll up a little bit and we can see that Gig 3 is an interface, even though
there's
no space there, but it's an unassigned IP address.
So I could assign an IP address, IP address, tab over.
We see that we've got that configuration 10001.
Question mark, I can hit enter or, well, really what it's asking me for here is
a Mac.
Mask.
There we go.
Like 255, 255, 255.0 and hit enter.
Now here's the interesting thing about this configuration, even though we're
doing iOS
XE configuration.
If I were to, for example, say like do show IP in brief, we're not going to be
able to
do that.
Do doesn't show up as an option here.
And so what if I hit exit?
Oh, this is interesting.
Uncommitted changes found.
What does that mean?
Well, iOS XE is taking after V edge configuration, which is taking after a lot
of other companies,
which says that, hey, just because I hit enter on a command doesn't necessarily
mean I'm
ready for it to take effect.
The idea here is I create configurations, but they don't take effect until I
commit
them until then they are uncommitted configurations.
So if I were to say, no, let's not commit them.
And I do a show IP in brief.
We notice that gig three doesn't have a configuration.
Meanwhile, if I do config dash T and then we do interface gig space three, oops
, once
again, we have to be careful capital gig space three, do that same IP address
10 0 0 1 with
a mask.
Now what I can do is say commit.
Oops, commit enter.
And now I can exit out and show IP in brief.
And now we see that IP address has taken effect.
So we have to commit our changes if we're going to make any changes while using
config
dash T.
So from here, there's a couple of other helpful tips about how we can manage
these edge devices.
First of all, I can do a show SD when run or running configuration, hit enter.
And we can see this system information.
Once again, system IP is 12 dot 12 dot 12 dot 12.
Where did that come from?
It didn't come from me directly, at least.
I did put it into manager, but this is coming from manager.
So is the domain ID?
So is the site ID?
All of this came from largely manager.
Now a couple of things like the V bond IP address and the organization name,
these were provided
as part of the bootstrap configuration in order to help authenticate the device
.
But now we're pulling all this information from manager.
So that's a good thing to keep in mind.
The other thing we can do is do some connectivity tests.
So I could ping, for example, my default gateway 192 dot 168 dot 255 dot one is
the gateway.
I have access there.
I could check the V bond IP address, probably can reach it given everything we
've seen.
And indeed I can.
We can ping out into the interwebs.
See if a public IP address like eight dot eight dot eight dot eight works and
given
that that's my DNS server and I can reach it.
Hopefully I can ping something like www.sisco.com.
And indeed I can after a brief resolution there, we were able to ping.
Lastly, and here's a big one.
Show SD when control connections.
This is going to tell us how many connections we have to different devices.
So this is once again where Cisco, we're in the middle of being very
inconsistent with
what we call devices.
We have largely tried to go, at least I have tried to call these devices by
their new names.
For years, we've called them V smarts and V bonds and V managers.
Now Cisco wants us to call them controllers and validators and managers.
And so be it, we will definitely try to call them that but they still show up
in configurations
as V smart V bond for that matter.
The system configuration, I didn't explicitly call it out, but our V bond
config is again
called V bond, not validator.
So we're going to see a lot of V bond, V smart and V manage and V and C edge
showing up in
our configurations.
But notice that we do have tunnel configurations to each one of these
controllers.
So we've got DTLS configurations, which is what we have configured in there.
We've got the system IP addresses.
This is, this will look a lot cleaner on your side probably because I'm very
zoomed in for
the sake of making it readable here in video.
And so this is all the information is kind of smashed together here, but we can
see the
system IP address.
We can see the IP address of the actual device that we use to connect the upt
ime and all kinds
of other parameters here.
So it's very important that we have all of our configurations online
connections online
for all of these different edges.
So let's go ahead and run show SD WAN control connections really quickly on
edge 11.
That looks good.
And then we'll come over here to edge 13, looking good there.
And then we come over here to 14.
This is the big one because it has slightly different configuration.
And so if there's any problems here, we'll want to troubleshoot it.
So it looks like we do have some problems.
We are only communicating with V bond at this point.
So let's go ahead and flip over to manager and kind of try to figure out what
might be
going on here.
So when we come over here, we do see our WAN edges, we've got three reachable,
zero unreachable.
So that's pretty good.
Let's go ahead and go over to configuration, go to devices, look at WAN edges.
We should see 11, 12, 13, 14.
We see that they are in sync.
This one is still not yet, are not quite there where we want it to be.
Reachability is down, but everything else is coming online.
So that's good.
So we'll do some very quick troubleshooting on our edge 14 here.
If we go back to monitor, overview, look at our reachable edges that takes us
here.
Yep.
And we can see that everything is coming up.
We've got our control connections online.
Our T locks to the control device is everything looks good.
But also we have not formed data plane connections because we haven't done a
configuration.
Furthermore, they are in a staging state.
So a couple of quick things to just make sure, well, it's first of all, go
ahead and flip
back.
Take a look at edge 14 here.
And we're going to actually, let's just run this one more time.
I do see a log message came through.
Okay.
So not quite there.
Let's try some pinging.
So we're going to make sure that we can ping out to the internet.
We're going to make sure that we can ping.
Now remember, actually, rather than doing Cisco.com, let's do device helper.s
isco.com,
which is really indicative of whether we can connect to the PMP portal.
So those are a couple of troubleshooting steps to take a look at.
And then let's do a show IP and brief and just make sure that we didn't mess up
the
IP addressing.
So let's see here, gig one, as we showed should be on the 254 gig to should be
on 255 given
that we've got the ability to reach several of these other devices, probably
good there.
Let's ping the validator.
Okay, got that.
We're going to ping manager.
Oh, can't ping manage.
Oh, yeah, there it is.
Okay.
So we got manager connectivity.
And we've got V smart connectivity.
Okay.
So if all of this is working, chances are there's something wrong with the
configuration with
as regards to accessing the SD-WAN environment.
So we're going to do that same command show SD-WAN run.
Let's see what we've got here.
I see.
So we notice that we don't actually have all of the same information that was
given to
the other devices.
That's because we're not fully connected in here.
But we do see that we have the right V-bond IP address, which is good, which is
probably
why we can connect to V-bond.
But something about the authentication process isn't working.
And that is probably what's going on here.
So let's go ahead and switch over to CML and take a quick look there.
So let's go ahead and click on edge 14.
Look at the configuration.
Again, it probably has, it's not going to have anything to do with the IP
addressing
because we can ping everything.
Let's scroll all the way up here and look at these sets of parameters.
As long as the UID and OTP are correct and you can double check that, it's
going to be
fine.
But I think I already see the problem.
It's right here.
The WAN interface, basically the interface we're going to use for tunnel
creation is defined
as gigabit ethernet one.
And so we don't want that.
Let's go ahead and fix this.
And this will be a good demonstration of how we go about fixing something like
this.
I'm going to go to settings, stop.
And let's go ahead and grab this whole configuration.
And I'm going to say wipe.
We're going to wipe it out.
Now notice there was that little black X icon there and now it's gone.
The black X meant that there was a virtual machine shut down.
Now there's not even a virtual machine behind it.
It is completely clean.
So I guess I didn't have to copy it.
All the configuration's still here.
I'm going to say gig ethernet two, click save, all the same identity points.
And now we're going to go boot it up.
So at this point, I'm going to pause the video, wait for it to come online and
make sure that
once it comes online this time that we are good to go.
OK, so now we're back online.
I'm going to do that show SD-WAN control connection connections.
There we go.
And we are looking much better.
We've got all three of them there.
So that was the problem was essentially by identifying the wrong interface, we
were telling
the edge device to build its control connections out the wrong interface.
And so yeah, I could reach the V-bond because it knew how to reach it.
But as soon as it was told by V-bond what the IP addresses were for the control
components,
it tried to go out the wrong interface in order to reach them.
So again, a good example as far as not only how to identify maybe what's going
on under
the hood here, but also to see how to maybe fix a configuration that we got
wrong on the
CML side.
So I guess we can go ahead and switch back over real quick to V-manage to
confirm.
And if we refresh this, we'll just go to overview, boom, right there, four
reachable
devices, I can click it.
I see that all four of them are reachable, things are looking good.
So that's exactly where we want to be at this point.
We want to make sure that all four edge devices are online from a control
perspective.
And basically from a non data plane perspective and moving forward, we'll be
able to start
to build out our SD-WAN Topology.