Hello, guys. Welcome back. My name is David,
and today we are going to troubleshoot the
Symposium Cisco network. So what I mean is I
have one computer and one router.
This router was configured to pass the
traffic to translate this traffic into a
public IP so the computer can serve the
Internet. Now, what I did, I broke the
configuration in several places, and we
are going to start from the beginning to the
end. We'll find all the problems and try
to fix them. Stay with me.
[Music].
Okay. Let's start. This is my computer.
This computer is supposed to have the IP
address and DNS IP address, right? And the
gateway, of course. Then traffic comes
here on the Cisco router, and then from
the router, it goes to the Internet.
But here, we need to do NAT, right? Network Address
Translation. So let's start and find all
the problems I caused in the configuration.
So, in order for the traffic to leave the
computer, the computer is supposed to have
the IP address. Let's make sure the computer
has the IP address.
And when we say, “Let’s make sure the computer
has the IP address,”
let's test the actual status of the IP
address, not the configuration. And what I
mean by that is
you can go into a configuration and make
sure the configuration is there by
clicking this button,
but that's not the way I want you to test it.
I want to test
the actual status of the configuration.
That means you can either click here,
“Details,” or in the CLI.
Now, what's the difference, you might say?
The difference is that sometimes, when
you configure the IP address, Windows is
not taking this IP address for some reason.
There can be many, many reasons, but the
configuration doesn't always work. So
when you check the configuration on the
IP address, it's not necessarily the case that the
computer is using that IP address. So what we're
going to do, we want to check the actual
status of this configuration. Okay. So
let's see what we have. We have the IP
address here, as you can see,
and we have the gateway. So we know the
IP address is there, and probably the
IP address works. We can ping the IP address itself,
and yes, well, the IP stack, the TCP/IP stack, works on the computer.
That's good. So now let's test
the gateway and make sure the gateway works.
Here's the gateway,
and we want to ping that gateway to make
sure the gateway is on the network.
Now, you might already see that the gateway
is .1 on the topology, so the
gateway is wrong, but let's try and ping it.
Ping 192.168.1.254,
and the gateway is not pingable. And how
do--let's say we don't know if the
gateway is correct or not,
or we know the gateway is correct, but we
are not sure why we can't ping it. Ping
could be closed. Nobody closed ICMP
on the gateway, but let's say it's closed.
You want to make sure the gateway is on
the network, and for that, we can check the ARP.
Let's go ahead on the Windows
machine and type arp -a,
and this will show you the ARP cache and, you
know, the IP address mapped to the MAC address.
So let's see if we have 254 here in the
ARP cache--and we don't have it.
But we have .1,
and let's try and ping it--.1.
It's not pingable. That's weird. But, well,
at least we know it's .1, but let's
go ahead and change that one.
You know what? We have the Cisco router,
and we have the interface G3--Gigabit Ethernet 3--and
let's see what's the IP address on the interface.
Show
run--not sure--show interface G3--
address.
And as you can see, this is the IP
address
of the Cisco router. So yes, the computer
is supposed to have .1 as a gateway, not 254.
So let's go ahead and fix that on the computer.
We are one step closer to fixing the problem.
And let's do .1.
Now
remember, .1 wasn't pingable from
the computer,
and we want to find out why we cannot
ping it. Should it be pingable? Should it not?
Let's go ahead and check if there's
any access list on the Cisco router
on the inside interface. Show run
inside interface Gigabit 3/3, and | include for
the inbound. And sure, there is an access list.
Let's check what's inside.
Okay, we have permit ip 192.168.3.
Okay.
And /24.
So the access list is not permitting our
traffic coming from the computer because,
remember, our IP address or subnet on
the computer is 192.168.1.--
not 3, but 1--on the third octet. And the
access list on the Cisco router is not having this .1.
So let's go ahead and fix that.
We need to go into the access list--
extended--
inside inbound. And, you know, we know
for sure that there is not
supposed to be the 3
network on this LAN, right? So it's okay
to remove this IP address and fix that.
Node 20, and then permit ip 192.168.1.0 0.0.0.255 any.
Okay.
Now it looks great.
Let's see if we can ping the router.
Okay. We can ping the router.
Great. Now let's check--do we have the Internet?
And no, we don't. Okay.
Let's see
what else we are missing here. Do we have
the route?
No. Actually, let's make sure the Cisco
router has the Internet. Ping 8.8.8.8.
Cisco router
doesn't have the Internet. Let's fix that.
So what do you need on the router to
have the Internet? You need the IP
address, you need the next hop, which is
that .1, and you need a connection between
ISP and the router.
Let's check what is the interface on the
Gigabit1,
and what is the IP address here?
Okay,
that's great. Now, what's the gateway? Show
ip route.
And our gateway is .3.
But remember,
our ISP has .1, not .3. So
let's go ahead and fix that too.
Here's my route, which I need to remove
and add the new one.
Now remember, if you just add the route,
you'll have two routes. It's not going to
replace--even though it has the same destination.
It's not going to replace. So
you want to remove the old route and add the new one.
Okay. Now we have the route in the
routing table--proper route. Now let's see if we
can ping Google. Ping Google
from the Cisco router.
Okay.
Cisco router has the Internet. Now let's
come back to the computer and see
if the computer also has the Internet.
Well, no. Computer doesn't have the Internet. Okay.
Let's think. What do we need to do?
What do we need to have on the Cisco router
to allow Internet access from
the computer
so the computer can serve Internet
sites--websites? Okay? So first,
the computer has the private IP address. You
see? And the Cisco router external
interface is the public IP address. So we
want to translate our private IP subnet
into a public IP address of the router. And for
that, we need to do the NAT.
And let's make sure we have the NAT
translations on the Cisco router. So
let's go ahead and try to ping--
actually, it does not--
let's ping and come back here and see
if we have NAT translations.
And we have some NAT translations,
which are not our Google IP addresses.
So let's clear up:
clear ip nat translation *
dynamic I believe here.
No. Just everything.
Okay. Show ip nat translations.
We don't have new translations. That
means the Cisco router is not translating
our traffic from the private subnet into the public IP.
And let's troubleshoot that. We need to
have the configuration for that, right? So
let's go ahead and do this: show
run interface Gigabit3. And does it
have the NAT configuration on the Gigabit3?
It does. And it has no IP NAT inside.
That's great. Now, the
inside interface is supposed to have IP
NAT inside. The outside interface, though, is
supposed to have IP NAT outside.
Let's check that.
Oh, the outside interface doesn't have IP NAT
outside at all. So let's go ahead and
configure that--
IP NAT outside.
And now
we've fixed NAT, well, at least partially, on
the Cisco router. Now we know that the
inside interface and outside interface--
they both have NAT configuration on them.
Let's go ahead and check IP NAT translation again.
Alright. We have some traffic here.
This is our IP address,
right? Right?
And this is what we are trying to ping.
And this is the ICMP protocol, and this
is the IP address we are translated into.
So if we check this IP address on the
interface, that's our IP address. We know
that the Cisco router translates the packet into a public IP.
Now what we need to do is--we know
traffic comes here on the router, it's
translated, and we need to make sure
traffic can leave the interface. Now, how
do we check that?
Well, usually, if you have the route and there
is no restriction on the interface,
traffic leaves the interface. So let's go
ahead and check that. Do we have any access list?
We don't.
But do we want to put the access list to
make sure traffic leaves the interface?
You know, you can use, probably, packet
capture--if you know how to do that. But
if not, what you can do is do a quick
configuration--show IP access list
extended, for example,
and match our traffic. In our case,
let's say outside
ISP is going to be--no--untold.
Outside outbound--
that's the access list name. And permit
our traffic. What is our traffic?
IP host 192.168.0.10.1
into
Google DNS.
And we want it to be ICMP--but IP will
work as well--but let's do ICMP only.
And now
we want to assign this access list on
the public interface. But remember,
right now the interface doesn't have the
access, which means once you assign this
access list, you'll permit only the
things you have in the access list. And
in our case, that's only the ICMP packet
coming from our computer going to
Google. But for the rest of the users,
we're going to break the Internet--well, if
they have it already. So what we want to do
is add permit any any at the end of
the access list,
which means if we assign this access
list on the outbound interface
for the outbound traffic,
we'll get the match here,
and hit count will increase if the
packet leaves the router. And for the
rest of the traffic--to not block them--
here's the permit ip any any. So let's
go ahead and do: interface GigabitEthernet1,
ip access-group outside-outbound out.
And now--now you see there's a match
on IP and ENA--
probably some kind of, you know,
different traffic coming from the
computer, checking the updates or
something like that. Our traffic
doesn't have the match. Let's generate
the traffic on the computer.
This is our traffic.
One,
two.
Okay.
And now let's check if we have the match
on the access list.
We don't.
That's weird.
Isn't our IP address--
oh, oh, I'm sorry. Guys,
this is ridiculous. Remember, we translated
traffic into a public IP, so there's no way
to match the 192.168.1.10
on the egress interface. So we want
to do something else.
Let's go ahead and, you know, fix that.
We want to remove
line 10 and add the new--new line:
ip access-list extended ..., permit icmp host
[our public IP address] host 8.8.8.8. What’s the public IP address of the
router? It is 100.100, I believe. This is the IP address.
And then we are going to ping Google DNS.
Here's the access list. Now--
now we need to
renumber this because it's incorrect.
We want to have permit any any at the end. So:
remove 20, permit ip any any.
And now it's correct. Okay. Now let's ping and
see if the packet leaves the router.
We still don't have the match
on the interface. Okay. Here's the match.
I was like, what's going on?
So we have a match,
and that confirms two things--
not two, actually several:
We have the working gateway for the
Cisco router, so traffic can leave the interface.
Because the match is for the public
IP address, we also know that the traffic
is being translated--so even if you
didn’t check the IP NAT translation, this
confirms that there was a translation
and the private IP address is translated into a
public IP address. And third, the
packet leaves the router.
Okay, now
that's good--it leaves the router. But is it
coming back?
No. It might be coming back, or it might
not be coming back--depends on the problems on the Internet.
So since this video is about
troubleshooting, let's make sure the
traffic is coming back.
And for that, we again can capture the
traffic, or we can assign a similar
access list on the inbound traffic.
Extended--and that would be outside-inbound.
And now what do we want to match here?
We want to match Google DNS as a source
because, remember,
the answer is coming from Google now.
And we want to set the
destination to be our IP
address on the public interface--on the outside interface.
And the protocol is ICMP.
Also, you can use
echo-reply if you want--
not necessary for this purpose, but you can.
Like, if you are troubleshooting with
someone else on the other side and they
are pinging your IP address as well, you
might want to add echo-reply to make
sure this is your reply and not their ping.
But Google is not going to ping us, so
it's okay to not put the echo-reply.
Any ICMP we match here--we know it's our reply from Google DNS.
And now let's permit ip any any because we
don't want to block any other traffic on the interface.
Because right now there's
no access--again, there's no access
list--and if we assign the access list,
we'll block everything that is not
permitted on the access list.
So let's go ahead and configure the
Ethernet--GigabitEthernet1:
ip access-group [access list name]
and
here we use inbound.
Okay. In.
Now
let's check what match we have on the
interface for inbound traffic.
Is there any reply from Google?
And there is a reply.
So we know now that the traffic not only
leaves the router, but it's also coming
back from Google. So the Internet in between--
Google DNS and our ISP--is okay. We
received the traffic, but the
computer still cannot ping that.
How come?
We need the ping on the computer.
So what else is left?
When traffic comes back
to the router--
let me try to draw it here.
When traffic
leaves, okay, we have this traffic.
It left the router,
went to the ISP--not ISP, Google DNS--
and came back. And it comes here. We
have this match on this interface. Now
what's supposed to happen? Well, NAT will
catch the traffic, will check the port
translations, and will figure out--okay,
that's the returning traffic for this
ping. The guy's pinging from the
Windows 7 machine. And now this packet--sorry--
now this packet is supposed to leave this
interface,
okay, to be delivered to the computer.
And let's make sure that is happening.
For that,
what we are going to do is...
we are--
for that, we are going to check if the
traffic leaves the Cisco router.
Again, this is the same as we did on the
outside interface. You can capture
traffic if you know how to capture. If
not, you can assign the interface on the
address. Let's first make sure there is
no access list on the router.
And let's do out.
There is an access list. Okay.
Now, let's check what this access list has in it.
Does it have any match?
It doesn't. But look at this--
this subnet is not what we are expecting
to have because, remember, our subnet is
192.168.0.1,
and here we see 2. So again, the subnet
on the access list is wrong.
Let's try and fix that.
Now it's correct.
So remember, the traffic leaves the router.
So the source here is gonna be any--in
our case, it's Google DNS--and the destination
is our computer. So the access list order,
like from any to subnet, is correct.
And let's see if we can finally ping it.
We still cannot ping it.
Wow.
Let's see what's going on.
Is it leaving the interface?
It is--actually, my bad.
I did 2 again.
Okay, this is wrong.
This is what happens when you rush.
And
actually--10.
And then we need to do 1.
Yeah. Once you remove all lines from
the access list, that access list doesn't work
anymore. So there's no deny any any at the
end if there's no line in the access list.
So as soon as we removed 10, we started
pinging. And then we added the
correct line here,
and we can still ping it.
And we have hit counts.
So this is how you troubleshoot a simple, basic Cisco network.
Not only Cisco networks--pretty much any
network. You need to know what you're
troubleshooting. You need to know how traffic goes,
what gateway you're supposed to have on
the computer. You need to know all the
things to troubleshoot, and
after several months or years, you'll
have enough experience to skip some
of the steps. For example, you might know
the gateway
on the router is correct because you
connected to the router remotely and
from the Internet, so the router most
likely has the default gateway. Or you
might know that
the access list is not supposed to be checked
on the inside device because the user told
you that they can ping the IP address of the gateway.
So many, many things can be skipped based
on your experience. But this is from
starting to the end. You check from the
beginning where you have the problem. You
don't check at the end if the Cisco has
the Internet. First, you make sure you
have everything you need to leave the
area--to leave the subnet. Now, let's see
if we can ping Google--the actual Google website--
directly using DNS.
And we can ping. So if I go
on a browser here, it'll try to open the Google website.
I should be able to open it.
And sure enough,
I can open it. And it works. Perfect.
I hope this was useful for you guys, and
at some point, you'll use it.
That's it.
So guys, if you like these videos, please
like the video and hit the subscribe
button if you want to see more videos
like this. Also, I'm looking for ideas on
what kind of videos to create. So if you
have any idea and you're looking for
some kind of configuration on the Cisco
or similar network, you can put in the
comments what you want to see in the
next video. Thanks for watching, and have a good one.