Frame-Relay + Ping = WTF?!?!?

Bl8ckr0uter

kryolla wrote: »

so its like this

DaytonR2 --- DaytonR1 ----Frame Cloud ---- CincyR1

---

CincyR2

You have 1 segment Dayton R2 to DaytonR1
You have 1 segment Dayton R1 to CincyR1
You have 1 segment CincyR1 to CincyR2

All 3 of these segment needs to be on different subnets

Dayton2 routing table will have eigrp routes from the frame cloud and Cincy segment
Dayton1 routing table will have eigrp routes from cincy1 to cincy2
cincy1 routing table will have eigrp routes from dayton2 to dayton1
cincy2 routing table will have eigrp routes from frame cloud and dayton segment

I will update my addressing scheme for the network and check and see if I can ping then. Should I use the same major network address (10.x.x.x) or should I use different ones (10.x.x.x 172.16.x.x, 192.168.1.x)? I used the no auto-summary command with eigrp so I could use discontigious subnets, you think that could cause an issue?

Bl8ckr0uter

networker050184 wrote: »

You are right, should have let us know there were four routers, makes a world of difference

sorry about that.

kryolla

knwminus wrote: »

I will update my addressing scheme for the network and check and see if I can ping then. Should I use the same major network address (10.x.x.x) or should I use different ones (10.x.x.x 172.16.x.x, 192.168.1.x)? I used the no auto-summary command with eigrp so I could use discontigious subnets, you think that could cause an issue?

it doesnt matter what your addressing scheme is as long as you keep each segment unique within your AS and until you know what auto summirization is then I would keep it off.

sandman748

like I said in my post before. turn off auto summary on eigrp 10 and change the mask on your two fa0/0 interfaces to 255.255.255.0 and your set. the serials are fine on both. I see youve got a 192. network in your eigrp but dont know how its set up on the other routers. That might need to be changed as well to make sure they are in different subnets.

Neeko

This thread has made me laugh, sandman was right all along. Silly CCNPs

sandman748 wrote: »

When you issue the ping from this router to 172.1.2.1 it looks in the route table and is seeing 172.1.0.0/16 is on the fa0/0 interface which is isnt. It needs to go through the serial link. This is because the advertisement sent from the cincy router is not being added to the route list as it already has the static route to the same network. I'm willing to bet if you change the subnet mask of both of your fa0/0 interfaces to 255.255.255.0, those routes are going to show up and allow you to ping.

Again, I think the auto summary on EIGRP 10 may end up causing an issue as well even after changing the subnet mask but maybe not.

A screenshot of the topology would help me out a lot. I'm having a hard time picturing this network.

Regarding changing the masks on the FE interfaces on both routers I agree but even so, he posted a ping from one router to the others serial interface and it failed. Everyone agrees the PVC should work fine but it didn't ping. Looks like there is two primary problems with 1. pinging from host to host and 2. pinging from router to router:

1. Duplicate subnets (no auto-summary wont make a blind bit of difference since they are the same classful network anyway)

2. Dodgey PVC that won't ping. Edit - I didn't realise the cloud had FR switch capabilities, if this has been configured and it still doesn't work then maybe it's a PT bug. Might helpful to see the cloud config too.

wbosher

There is something in Packet Tracer that acts as a FR switch, it just looks like a cloud. You need to go in and configure the DLCI's in here. I had exactly the same issue and found that playing around with this solved the problem. It's a bit tricky and takes a bit of trial and error but it does work.

Bl8ckr0uter

wbosher wrote: »

There is something in Packet Tracer that acts as a FR switch, it just looks like a cloud. You need to go in and configure the DLCI's in here. I had exactly the same issue and found that playing around with this solved the problem. It's a bit tricky and takes a bit of trial and error but it does work.

Yea, I know exactly what you are talking about and I did configure the dlcis inside of it, as well as enabling the correct encapsultation. I am going to work on this later tonight and update the thread. I would have done it sooner but I have been busy.