A lot of us who have been doing this for a while
are pretty quick to jump onto a CLI
in order to start doing troubleshooting.
But the reality is that Cisco has given us some very powerful tools
in the graphical user interface.
And when we really think about what we're doing with CLI anyways,
it's really just drilling deep into issues that are on a single device.
It doesn't have the global view of what's happening
throughout the entire architecture.
Yet, if I'm logging into a manager
and I'm using its troubleshooting tools,
then I can see what's happening potentially between two edges
or among multiple edges.
In fact, we took a look earlier using application-aware routing
when we were configuring it,
and we could run some tests.
And we'll take a look at that again here.
But we were able to simulate flows.
And so now it's not just this edge or that edge.
It's saying, hey, what happens if I get a packet?
What does the network do with this packet?
And I was able to confirm that it's using the path that I wanted to
back when we were doing application-aware routing.
So there are some really good, strong troubleshooting tools
that even experienced engineers who are good at the CLI,
we should still be looking at the graphical user interface.
So where are these troubleshooting tools?
Well, we might expect to come down to tools,
and there are some things in here as well.
But for the most part, we're going to stay on the Monitor tab here,
and we're going to go to Devices.
This is where we can access some troubleshooting tools.
Now, at first glance, it's just a list of devices.
I mean, that's where we went was Monitor Devices.
And by the way, as always, we could just tap the tab here.
I probably should have said that too.
But I can also come down to this Action area,
and under the validator, for example,
I can do some pinging and trace route,
which is good to make sure if my validator is unreachable
or can't see a particular edge device,
I might just want to run a ping test.
That would be if I am more comfortable with the user interface
rather than logging into the CLI.
But when we look at an edge here, so here's Edge 11,
and I click these and I go to my –
Other Tools takes me to this section,
this screen that we looked at earlier in the course,
where we all of a sudden see quite a few options here.
For example, I do see pinging and trace routing,
and I can do that, and that's very helpful.
I can click Ping here. I can pick my interface.
Let's say I want to pick something in, I don't know, VPN 10 here.
So I can look at VPN 10, Interface, Gig 3,
and maybe run a ping test to, let's say, Site 12, 12.12.
And so we'll do a quick ping test from 11.11 to 12.12.
And that takes a little bit, but here we go.
All right, actually, we're seeing 100% loss.
Yeah, I don't remember what state the lab is in right now,
but that tells me that there's something up here.
Maybe I could get at least to the Ubuntu host that's sitting over at Site 11.
If so, then I'm going to need at some point to go in
and check out my current lab state and figure out why that's happening.
Okay, so it looks like things are just down right now, and this is what it is.
But we see that packets transmitted are five, packets received are zero.
And so this is a good indicator that, hey, something is going on here in VPN 10,
and I should probably go try to figure out what it is.
But, yeah, so that's clicking on Edge 11.
But if I go back to this troubleshooting area, we see that we can do pings,
we can see we can do trace routes, device bring up.
This is actually a really cool troubleshooting tool
if we're having problems getting our devices online.
I love this because we still do see sometimes Cisco using these classic vManage,
vSmart, and vBond icons, as well as the vEdge icon, which is just a router icon.
But either way, these icons, Cisco has been trying to deprecate these.
They still show up in the UI every now and again.
Frankly, I'm not sure why they wanted to deprecate them
because they're actually pretty good icons for what they represent.
But either way, now I can see maybe there's a problem with, you know,
I can't get authenticated or authorized by the vBond or whatever the situation is.
So I can go back to troubleshooting here.
Over on the right here, the traffic side, this is where things get really cool.
So I can take a look at tunnel health.
I can look, for example, at my MPLS.
Let's just do Edge 12.
So remember, I clicked on Edge 11, so everything here is from the perspective of Edge 11.
So I'm looking at my MPLS circuit.
I'm looking at pointing to Edge 12 and the MPLS circuit on the other side.
So I can choose a local color and a remote color,
which is important if I do have different color to different color types of tunnels.
And then I can look at the tunnel.
And so I can see that there's, you know, the loss here is looking pretty good.
It looks like we did have maybe some packet loss there,
so at least this tunnel is looking like it's in good shape.
And then we can also come back here and we can do app route visualization,
which is a similar concept, but let's say Edge 11 to Edge 12.
And then I can say go here, and we can look not only at loss
but also transmit and receive for specific application flows.
Now, I don't have any application flows configured,
so we're really just looking at edge-to-edge traffic.
But this is, again, a very powerful visualization tool
once we have a production network in place.
The one last one to talk about here is the simulate flows.
Simulate flows is very powerful in that we were able to do this earlier.
For example, I can choose, like, VPN 10
and let's say a source IP of, like, my Ubuntu host.
This doesn't have to be from a router.
We're not doing actual traffic.
We're not sending real data traffic.
Instead, we're simulating it.
It's a simulation that says, hey, what if I got a packet in
that has this source IP address, an IP address of, let's say,
something at site 13.13.50.
It doesn't matter what application, although I could do, like, RTP.
We'll just say RTP in general.
And then I can click simulate.
And this is great.
So it says that this packet arrives on my edge.
And what's it going to do?
It's going to send it out these four in load-balanced fashion.
Now, what we did earlier with application-aware routing,
much earlier in the course, was we saw or we first of all configured
that our voice traffic, however we wanted to identify that,
would only go out the MPLS circuit to start with,
and then it would use the biz internet as backup.
And so when we ran that, when it identified voice traffic,
it only showed the MPLS circuit.
And so the simulated traffic flow verified for us that our configuration
was correct and that it was only going to use MPLS,
even though we don't have real voice traffic on the network.
We could just use simulating the traffic flow to confirm that.
And in this case, because I don't have anything special configured,
I just said traffic from host A going to host B at a different site,
we see that, yeah, we've got two different paths to site 13
and we have two different circuits that we can use in either case.
So, yeah, load-balanced across all four links.
This is a great way for us as network engineers, again,
to come in here and verify that, you know,
the traffic is flowing the way we think it is.
Because if I think it's only using biz internet and I come in here
and I simulate it and I see it might be using MPLS as well,
or in this case it's getting load-balanced between the two,
then the traffic flow is not happening like I think,
and I need to be kind of rethinking things.
So all this troubleshooting, again, accessible by going to monitor
and then devices or, again, clicking the devices tab.
And if I click on validator, again, I only get, like,
pinging and trace routing.
But on the edge under the troubleshooting section,
I see I got a lot of options.
And, again, ping and trace route and such, if I click other tools,
then I'm going to see most of them listed here.