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.