Can anyone help troubleshoot this Packet Tracer problem

So I just figured it out. I also figured out that I hate how limiting Packet Tracer can be sometimes, especially when basic commands like "show interface status" isn't available.

Anyways, why don't you tell me what you've worked out so far as possibilities and I'll help guide you in the right direction? Part of these exercises is to help you establish a troubleshooting methodology, which will help you immensely in the future.

jdballinger wrote: »

So I just figured it out. I also figured out that I hate how limiting Packet Tracer can be sometimes, especially when basic commands like "show interface status" isn't available.

Anyways, why don't you tell me what you've worked out so far as possibilities and I'll help guide you in the right direction? Part of these exercises is to help you establish a troubleshooting methodology, which will help you immensely in the future.

Sorry for the Sunday delay. Thanks for trying to help.

In the beginning, router South can't ping router West and North. It turns out router South has a wrong IP on one of the serial ports. 2nd Problem I fixed is that none of the PCs can get to the ISP. It turns out the NAT was not set up completely. I added "IP NAT inside lsit 1 pool XYZCORP". This allowed PC4, 5, 6 and 7 to reach ISP. But PC1, 2 and 3 can't even get to their own East router.
I guees that's the first I would like to solve. Afterwards hopefully it can get to ISP. So can you see why PC1, 2 and 3 can't get to router East? To log into East, use PC7 dos prompt, enter "telnet 10.1.0.2", used 'cisco' and 'class' for the passwords.

TIA.

I found out exactly why they can't get there.

Think logically about how the data travels. When you send a PING request, how does it actually work? Follow the data packet, considering how it is handled by each device that it moves through. Since you are limited in what you have visibility over in this exercise, it really requires pulling out the whiteboard to think things through.

Start at the beginning. If you run a tracert or ping request, what's the first thing that happens?

I really don't want to just give you the answer. I'd rather guide you in a specific direction of thought so that you better understand how I came to the answer.

jdballinger wrote: »

I found out exactly why they can't get there.

Think logically about how the data travels. When you send a PING request, how does it actually work? Follow the data packet, considering how it is handled by each device that it moves through. Since you are limited in what you have visibility over in this exercise, it really requires pulling out the whiteboard to think things through.

Start at the beginning. If you run a tracert or ping request, what's the first thing that happens?

I really don't want to just give you the answer. I'd rather guide you in a specific direction of thought so that you better understand how I came to the answer.

Again, thanks for helping. But I really can't get anywhere. The following is what I get when I do a tracert from PC7 to PC1. It reaches router East and stops there. The Router East configurations look all fine to me. Using "show cdp nei", I found a switch named ESW1 between router EAST and PC1, 2, 3. But I can't find a way to gain access to it to check VLANs configs and others.

So, maybe you can just share what you know?

PC>tracert 10.2.15.10

Tracing route to 10.2.15.10 over a maximum of 30 hops:

1 5 ms 9 ms 7 ms 10.5.1.1
2 15 ms 15 ms 15 ms 10.1.0.2
3 * *
Control-C
^C
PC>

Even if you get access to the switch, it won't give you any good information. They don't allow for many commands, including 'show interface status'.

Anyways, the switch isn't your problem. It's your routing that's the issue. Take a close look at the EAST router and tell me if you find the issue. You could even compare it to WEST and SOUTH if you don't see it at first glance.

jdballinger wrote: »

Even if you get access to the switch, it won't give you any good information. They don't allow for many commands, including 'show interface status'.

Anyways, the switch isn't your problem. It's your routing that's the issue. Take a close look at the EAST router and tell me if you find the issue. You could even compare it to WEST and SOUTH if you don't see it at first glance.

I compared the running of EAST to WEST. Under 'router rip' section, EAST did not have

passive-interface FastEthernet0/0
no auto-summary

I don't know if 'no auto-summary' does anything for this setup. But I added them anyway. It turns out they didn't do anything.

On serial0/0/0, I found EAST has a different subnet mask than the other routers. So I updated its IP to 10.1.0.2/255. Since I telneted from PC7, I Lost the connection to EAST and had to re-establish the telnet session. Anyhow that did not do anything for PC1, 2, 3's connection.

On the f0/0 sub-interfaces, EAST has ' encapsulation dot1Q XX'. That seems fine too. There really isn't any other difference I can spot. But PC1, 2 and 3 just can't can't ping router EAST.

How do you even get into the east router?

Heck I can't even get into enable mode on the west router...

bbarrick wrote: »

How do you even get into the east router?

Heck I can't even get into enable mode on the west router...

From PC5, 6, or 7, telnet to 10.1.0.2, which is the S0/0/0's IP address for router EAST, to gain access. The problem is host PC 1, 2 and 3 can't connect to it's own default geteway router EAST.

workfrom925 wrote: »

I compared the running of EAST to WEST. Under 'router rip' section, EAST did not have

passive-interface FastEthernet0/0
no auto-summary

I don't know if 'no auto-summary' does anything for this setup. But I added them anyway. It turns out they didn't do anything.

On serial0/0/0, I found EAST has a different subnet mask than the other routers. So I updated its IP to 10.1.0.2/255. Since I telneted from PC7, I Lost the connection to EAST and had to re-establish the telnet session. Anyhow that did not do anything for PC1, 2, 3's connection.

On the f0/0 sub-interfaces, EAST has ' encapsulation dot1Q XX'. That seems fine too. There really isn't any other difference I can spot. But PC1, 2 and 3 just can't can't ping router EAST.

What happens if you change all the routers to a /29 mask?

workfrom925 wrote: »

I compared the running of EAST to WEST. Under 'router rip' section, EAST did not have

passive-interface FastEthernet0/0
no auto-summary

I don't know if 'no auto-summary' does anything for this setup. But I added them anyway. It turns out they didn't do anything.

On serial0/0/0, I found EAST has a different subnet mask than the other routers. So I updated its IP to 10.1.0.2/255. Since I telneted from PC7, I Lost the connection to EAST and had to re-establish the telnet session. Anyhow that did not do anything for PC1, 2, 3's connection.

On the f0/0 sub-interfaces, EAST has ' encapsulation dot1Q XX'. That seems fine too. There really isn't any other difference I can spot. But PC1, 2 and 3 just can't can't ping router EAST.

I typed it wrong. I changed the IP to 10.1.0.2/24. Not /255.

Well, I'm at a loss. Which doesn't surprise me considering I haven't even gotten my first cert yet. But I did get some good time in on the CLI today playing with it. I don't really understand this type of layout though, why there isn't a switch configured with VTP between PC1/2/3 and the East router beats me.

Didn't realize there were 5 routers in that one area.

You are correct about EAST missing the 'no auto-summary' command. I added it and everything worked just fine for me.

jdballinger wrote: »

You are correct about EAST missing the 'no auto-summary' command. I added it and everything worked just fine for me.

Hmm weird. How come it's not working for me. Well, as long as that's the problem, I'll let it go. I've spent too much time on this one

Your call.

I think the important question though, is do you understand why having auto-summary turned on caused your routing to fail?

jdballinger wrote: »

Your call.

I think the important question though, is do you understand why having auto-summary turned on caused your routing to fail?

My understanding is, network 10.2.15.0, 10.2.25.0, and 10.2.35.0 use seperate subinterfaces, so they really can't be summarized and sent out of one interface.