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

Start with "show ip int b" if both are up/up look at "show frame pvc" to see if the DLCIs are up.

There are a couple of issues
you have redundant info here

frame-relay map ip 10.2.0.0 17 broadcast cisco
frame-relay interface-dlci 17

also your frame map config is wrong
Is packet tracer for school

networker050184 wrote: »

Start with "show ip int b" if both are up/up look at "show frame pvc" to see if the DLCIs are up.

I can tell you that both ints are up. Eigrp is working between all host.

The first router: Show ip int:

DaytonR1#show ip int b
Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 172.1.1.1 YES manual up up

FastEthernet0/1 unassigned YES manual up down

Serial1/0 10.1.0.0 YES manual up up

DaytonR1#

The first router: show frame pvc

PVC Statistics for interface Serial1/0 (Frame Relay DTE)
DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

input pkts 14055 output pkts 32795 in bytes 1096228
out bytes 6216155 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 32795 out bcast bytes 6216155

The second router: Show ip int b
CincyR1#show ip int b
interface IP-Address OK? Method Status Protocol

FastEthernet0/0 172.1.2.1 YES manual up up

FastEthernet0/1 unassigned YES manual administratively down down

Serial1/0 10.2.0.0 YES manual up up

The second router: Show frame pvc
PVC Statistics for interface Serial1/0 (Frame Relay DTE)
DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

input pkts 14055 output pkts 32795 in bytes 1096228
out bytes 6216155 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 32795 out bcast bytes 6216155

kryolla wrote: »

There are a couple of issues
you have redundant info here

also your frame map config is wrong
Is packet tracer for school

No. It is for practicing on my own. Not for school. This is not an assignment or anything...

if you have eigrp working between all hosts then what is the issue?

kryolla wrote: »

if you have eigrp working between all hosts then what is the issue?

I am trying to be able to ping between the frame-relay cloud...
I read an article that said frame relay being a NBMA network will not forward icmp broadcast UNLESS you set the connections to being a point to point connection. I guess I am setting them correctly.

Also you said my mapping was wrong, I think I mapped the same int on different routers. I will correct that issue in a moment.

I take that back your frame map statement looks right. I didnt look at the subnet mask and thought you map a network address and not a host. Your packet count from sh frame pvc looks like it is sending and receiving. What happens when you try to ping the other end. Broadcast will work with just 2 routers but try to put a third in a hub and spoke and you will notice that broacast will not travel beyond the hub. If you have eigrp and ospf adjacency across the frame link then you should be able to ping across it.

Everything looks good to me. Try a debug ip icmp and debug frame packets and try to ping the other side (can you debug on packet tracer?). Might just be a packet tracer bug though...

you have the same network on the ethernet interfaces on both routers. 172.1.0.0/16 is subnet for both routers. Each router is seeing the destination ip address as being directly connected and then dropping when none are connected to its local interface.

your routing table probably has the 172.1.0.0 network only directly connected as it is discarding the advertisement from the other router with a higher administrative distance. The auto summary on EIGRP 10 may also become an issue as well.

sandman748 wrote: »

you have the same network on the ethernet interfaces on both routers. 172.1.0.0/16 is subnet for both routers. Each router is seeing the destination ip address as being directly connected and then dropping when none are connected to its local interface.

your routing table probably has the 172.1.0.0 network only directly connected as it is discarding the advertisement from the other router with a higher administrative distance. The auto summary on EIGRP 10 may also become an issue as well.

Whats wrong with both routers ethernet interfaces being on the same subnet? I think you need to go back over the basics here.

There is nothing wrong with the config. I pasted it in my lab just as you have it set up and everything can ping fine. Probably just another simulator bug...

One thing though, you need a little work on your OSPF over frame-relay to get that to come up, but I'll let you research that part

networker050184 wrote: »

Whats wrong with both routers ethernet interfaces being on the same subnet? I think you need to go back over the basics here.

Now i'm confused. How is router 1 going to route over to the other ethernet network when it sees that same network directly connected to its own interface. Would it not match it to the directly connected route? What does the routing table look like? I didn't put this in PT but i'm pretty sure its only going to have one route to 172.1.0.0/16 and it'll be directly connected.

Or are we just trying to ping from router to router cause that should work. But not host on one side to a host on the other.

sandman748 wrote: »

Now i'm confused. How is router 1 going to route over to the other ethernet network when it sees that same network directly connected to its own interface. Would it not match it to the directly connected route? What does the routing table look like? I didn't put this in PT but i'm pretty sure its only going to have one route to 172.1.0.0/16 and it'll be directly connected.

Or are we just trying to ping from router to router cause that should work. But not host on one side to a host on the other.

You would be correct if these segments were not the same segment. The OP is running EIGRP over the ethernet link between the routers which is why they are on the same subnet.

its multiaccess which means the host will arp for the other host if it is in the same subnet. If the host needs to go to another subnet it will arp for their default gateway. You can have some hosts use R1 as their default gateway and R2 for other hosts. Maybe Im not understanding your question

R1
interface FastEthernet0/0
description connection to DaytonR2
ip address 172.1.1.1 255.255.0.0
duplex auto
speed auto

R2
interface FastEthernet0/0
description connection to the CincyR2 router
ip address 172.1.2.1 255.255.0.0
duplex auto
speed auto

wow. imma douche. didnt realize there were other routers involved. thought the fast ethernets were being used to connect the hosts on each router.

networker050184 wrote: »

Everything looks good to me. Try a debug ip icmp and debug frame packets and try to ping the other side (can you debug on packet tracer?). Might just be a packet tracer bug though...

Here is a debug from the DaytonR1 router while pinging the CincyR1 router:

DaytonR1#debug ip icmp
ICMP packet debugging is on
DaytonR1#ping 172.1.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.1.2.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Here is a debug from the CincyR1 router while pinging the DaytonR1 router:
incyR1#debug ip icmp
ICMP packet debugging is on
CincyR1#ping 10.1.0.0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.0, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Strange. I know this is going to sound sad but I can actually see the envelopes that depict icmp packets going back and forth to each router through the cloud so I thought this should be working...

sandman748 wrote: »

you have the same network on the ethernet interfaces on both routers. 172.1.0.0/16 is subnet for both routers. Each router is seeing the destination ip address as being directly connected and then dropping when none are connected to its local interface.

your routing table probably has the 172.1.0.0 network only directly connected as it is discarding the advertisement from the other router with a higher administrative distance. The auto summary on EIGRP 10 may also become an issue as well.

Here is a copy of the DaytonR1 routing table:

Gateway of last resort is not set

C 10.0.0.0/8 is directly connected, Serial1/0
C 172.1.0.0/16 is directly connected, FastEthernet0/0

Here is a copy of the CincyR1 routing table:

Gateway of last resort is not set

C 10.0.0.0/8 is directly connected, Serial1/0
C 172.1.0.0/16 is directly connected, FastEthernet0/0

Now here is what is strange. I know that the AD of EIGRP is higher than static routes, but shouldn't the Eigrp routes show up for the wan links? Also I think something is funky about the routing tables. I know that there is obviously something wrong but what I don't get is why Eigrp saying all is well. I am going to redo my configs and see what happens then.

you will only get eigrp routes in the routing table for remote networks and not directly connected networks

knwminus wrote: »

Here is a debug from the DaytonR1 router while pinging the CincyR1 router:

DaytonR1#debug ip icmp
ICMP packet debugging is on
DaytonR1#ping 172.1.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.1.2.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

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.

where are you getting 172.16

meant 172.1.0.0. edited

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.16.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.

Dude I think you are totally confused on what is going on here. The routing tables are fine. There are no EIGRP routes because like kryolla stated they are directly connected.

And yeah, where is 172.16.0.0/16? Not part of this lab at all.

sandman748 wrote: »

meant 172.1.0.0. edited

172.1.0.0 is connected to the interface. Are you even looking at the config?

To the OP I think you are just running into something with this being PT. Like I said earlier I copied and pasted your config and everything was pinging fine (besides the OSPF deal).

I don't think these are directly connected. The decription on the fa0/0 says:

"description connection to DaytonR2"

hes trying to route to a network on cincyR1 through the frame relay cloud attached to his serial link.

Look at the config and the routing table, it is directly connected to both routers. I think you are getting confused again. This is one ethernet segment connecting both routers. Like if you took a crossover cable and hooked them right into each other.

The descriptions are off though, so it could not be connected to the right place.

networker050184 wrote: »

Look at the config and the routing table, it is directly connected to both routers. I think you are getting confused again. This is one ethernet segment connecting both routers. Like if you took a crossover cable and hooked them right into each other.

The descriptions are off though, so it could not be connected to the right place.

Are you syaing that fa0/0 on DaytonR1 is connected to fa0/0 on cincyR1? I'm sure things would work if thats the case. I dont think it is though. It sounds like two Dayton routers connected via ethernet with one of them going to a cloud. Then two more cincy routers on the other side of the cloud. Why bother with the frame relay cloud to connect dayton and cincy if you have a direct connection via ethernet?

sandman748 wrote: »

Are you syaing that fa0/0 on DaytonR1 is connected to fa0/0 on cincyR1? I'm sure things would work if thats the case. I dont think it is though. It sounds like two Dayton routers connected via ethernet with one of them going to a cloud. Then two more cincy routers on the other side of the cloud. Why bother with the frame relay cloud to connect dayton and cincy if you have a direct connection via ethernet?

I think you are right, we definitely need a diagram. I was assuming these were on the same segment since they are on the same subnet. If they are not then you are right there is an issue there.

You would put an ethernet connection and frame-relay between two routers for many reasons, redundancy, testing path selection.....

Sorry guys I should have let you CCNPs know that there are 4 routers involved in this. DaytonR1, DaytonR2, CincyR1, CincyR2. DaytonR1 and CincyR1 are "Core" routers and are directly connected to the cloud. Dayton/CincyR2 are directly connected to Dayton/CincyR1.

Btw the level of a CCNP's knowledge is very inspiring. Makes me want to climb higher, after I get done with my ccna of course

networker050184 wrote: »

I think you are right, we definitely need a diagram. I was assuming these were on the same segment since they are on the same subnet. If they are not then you are right there is an issue there.

You would put an ethernet connection and frame-relay between two routers for many reasons, redundancy, testing path selection.....

DaytonR1

Frame Relay Cloud

CincyR1
10.x.x.x

10.x.x.x

DaytonR2

CincyR2
172.1.x.x

172.1.x.x

I added the lines so the spacing would even up. DaytonR2 and CincyR2 are NOT connected.

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