Hey guys, i need help about one of my topologies

I wanted to make a simple topology which includes internal routing protocols here EIGRP, synchronous serial link, switches with inter-VLAN communication, trunks via router. There is a problem i couldn't solve.

Now, i share it.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

thedrama

here it is : http://rapidshare.com/files/451059619/Ozgunornek.pkt

The problem is that i can not ping Comp5 and Comp6 from Comp4 and Comp3
or from remote network which Comp1 and Comp2 reside.

I can reach from Comp1 and Comp2 to Comp3 and Comp4
I can reach from Comp3 to Comp4 and opposite.
I can reach Comp3 and Comp4 to Comp1 and Comp2

However, no connectivity to and from Comp5 and Comp6 under on the rightest switch of the topology. Can't find why. Please help me!

IRONMONKUS

thedrama wrote: »

The problem is that i can not ping Comp5 and Comp6 from Comp4 and Comp3
or from remote network which Comp1 and Comp2 reside.

I loaded your .pkt file and at first I was unable to ping to or from comp 5 and 6. I logged into R2 (I found out how to bypass enable passwords in Packet Tracer) and checked EIGRP and ran a ping to comp 5 and 6 of which both were successful.

I saw that router rip was on, so I disabled that and pings started working to and from comp 5 and 6.

I enabled rip again and the pings still worked.

I haven't gotten into EIGRP yet, so I don't know anything about it, but maybe it needed to sit for a bit to get routing updates working -- I don't know.

It's all pinging for me now. /shrug

thedrama

IRONMONKUS wrote: »

I loaded your .pkt file and at first I was unable to ping to or from comp 5 and 6. I logged into R2 (I found out how to bypass enable passwords in Packet Tracer) and checked EIGRP and ran a ping to comp 5 and 6 of which both were successful.

I saw that router rip was on, so I disabled that and pings started working to and from comp 5 and 6.

I enabled rip again and the pings still worked.

I haven't gotten into EIGRP yet, so I don't know anything about it, but maybe it needed to sit for a bit to get routing updates working -- I don't know.

It's all pinging for me now. /shrug

Thank you for caring. But situation appears weird. RIP config. shouldn't prevent EIGRP routing. Since, EIGRP has lower AD than RIP thats why
EIGRP will work. I checked trunking, subinterfaces, inter-VLAN communication many times. Nothing recovered.

In my opinion regarding diagnostics, if inter-VLAN communcation had an
issue, that time Comp3 would "unable" to ping Comp 4 too. But no
problem occurred concerned with these two.

Still confused.

Monkerz

This works just fine for me. I am using PT v5.3

thedrama

Monkerz wrote: »

This works just fine for me. I am using PT v5.3

uuuuh! I tried just an hour ago. Nothing changed in the application. [Packet tracer Version 5.1]

Did you change anything? When i advertised networks 192.168.3.0, 192.168.4.0 ,192.168.20.0 and 192.168.21.0 at r2, first of all i entered networks under eigrp commands with wildcard mask but then, tried with both no auto-summary and without it. Nothing changed.

on the global config. mode of r2

Like this : router eigrp 100
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
network 192.168.20.0 0.0.0.255
network 192.168.21.0 0.0.0.255
network 172.16.50.0 0.0.0.255
* no auto-summary

i didn't need to add "no auto-summary" under the config because i have already typed wildcard mask.

Made same things on r1(the router on the left side) like this :

router eigrp 100
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 172.16.50.0 0.0.0.255
*no auto-summary

gosh1976

I'll ask some of the same questions I asked on certforums.

Did you design that topology and do the configs yourself?

Are you just using the simple pdu to ping or are you actually going into a command prompt on the pc and pinging from there? Are you watching in simulation mode to see where the packets drop? If you are using the simple pdu are you pressing the little red button so they run more than once?

Did you do a show ip route and see if all the networks/vlans are there? I can ping every pc from every pc and the routing tables look fine to me with a quick glance. I didn't bother looking at anything on the switches or the configs on the routers since I can ping everything.

Monkerz

This is probably just a bug in v5.1. I came across a bug with v5.1 and spanning tree. Go download the updated version from Cisco.

thedrama

gosh1976 wrote: »

I'll ask some of the same questions I asked on certforums.

Did you design that topology and do the configs yourself?

Are you just using the simple pdu to ping or are you actually going into a command prompt on the pc and pinging from there? Are you watching in simulation mode to see where the packets drop? If you are using the simple pdu are you pressing the little red button so they run more than once?

Did you do a show ip route and see if all the networks/vlans are there? I can ping every pc from every pc and the routing tables look fine to me with a quick glance. I didn't bother looking at anything on the switches or the configs on the routers since I can ping everything.

Yeah i used both command prompt of PCs and PDU in simulation mode. I see that packets drop while coming back from r2 going through sw1 but not exiting to other switch weirdly(sw2).

Configs belong to me.

mikej412

Monkerz wrote: »

This works just fine for me. I am using PT v5.3

Ditto.

Was able to ping from 3 to 4, 5, and 6
Was able to ping from 4 to 3, 5, and 6
Was able to ping from 4 to 3, 4, and 6
Got bored, so I pinged from 6 to 6, and then to 3, 4, and 5, and then called it a night.

Welcome to the wonderful world of software simulators and software bugs. With real hardware you might have at least gotten some experience finding and recognizing an IOS bug, with is a useful Cisco Job Skill.

What's really fun is when someone who's only worked with a simulator thinks something is supposed to work that way because it "worked" in their simulator because of a software bug -- and then claims the hardware in the lab test (on a job interview) is broken.

(They were shown the correct working configuration, and then the door -- they didn't get the job)

thedrama

mikej412 wrote: »

Ditto.

Was able to ping from 3 to 4, 5, and 6
Was able to ping from 4 to 3, 5, and 6
Was able to ping from 4 to 3, 4, and 6
Got bored, so I pinged from 6 to 6, and then to 3, 4, and 5, and then called it a night.

Welcome to the wonderful world of software simulators and software bugs. With real hardware you might have at least gotten some experience finding and recognizing an IOS bug, with is a useful Cisco Job Skill.

What's really fun is when someone who's only worked with a simulator thinks something is supposed to work that way because it "worked" in their simulator because of a software bug -- and then claims the hardware in the lab test (on a job interview) is broken. (They were shown the correct working configuration, and then the door -- they didn't get the job)

Thanks for the advice. However, if you can not catch the opportunity of getting a job enough in order to work on e real hardware, your only chance
remains such these applications and your reliable resource(!)

thedrama

For all of you,

Did you catch any misconfigured interfaces or any other wrong things?
If you did, please share with me.

Monkerz

thedrama wrote: »

For all of you,

Did you catch any misconfigured interfaces or any other wrong things?
If you did, please share with me.

We just told you that the version of Packet Tracer you are using is buggy. There is no misconfiguration...

thedrama

Monkerz wrote: »

We just told you that the version of Packet Tracer you are using is buggy. There is no misconfiguration...

Thank you