Have a problem on my Frame Relay topology with RIPv2 routing

Im gonna add the relevant file here for you. But before that, i must say that i didn't configure subinterfaces. Just went with IARP then static mapping. Routers see each other. However, when i add hosts to each router and ping other routers from that host, packet can't get back! "request timed out" shows up. I wanna be sure that this is because split horizon! Cos, even routers see each other and ping successfully, i can not see anything rather than"directly connected" on the routing table. Site won't add my .pkt file. So, i need to upload it somewhere else. 2shared - file upload

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

boredgamelad

The file link that you requested is not valid. Please contact link publisher or try to make a search.

Shanman

Just a quick thing to check is your firewall. If you are on windows try disabling it and then ping. You can check your arp table on the host as well.

Roguetadhg

Shanman wrote: »

Just a quick thing to check is your firewall. If you are on windows try disabling it and then ping. You can check your arp table on the host as well.

I think he's using packet tracer.

4_lom

What type of topology are you using for frame-relay? Hub and spoke or full mesh?

MAC_Addy

Roguetadhg wrote: »

I think he's using packet tracer.

He is. And when he solves the problem he'll open a new thread so no one can keep track of his posts.

thedrama

Hub and spokes. They are on the same subnet. Ethernet networks behind them. Solved the issue but not sure by disabling split horizon on the hub oradvertising all networks including the one all routers know.

aldous

thedrama wrote: »

Hub and spokes. They are on the same subnet. Ethernet networks behind them. Solved the issue but not sure by disabling split horizon on the hub oradvertising all networks including the one all routers know.

rip (and eigrp) use split horizon as loop prevention. This means they won't send the route back out the interface it was learned (the logic here being you sent it to me why should i send it back) because of the way FR works in hub and spoke it wasn't sending the updates out as they were coming in on the same interface

thedrama

aldous wrote: »

rip (and eigrp) use split horizon as loop prevention. This means they won't send the route back out the interface it was learned (the logic here being you sent it to me why should i send it back) because of the way FR works in hub and spoke it wasn't sending the updates out as they were coming in on the same interface

sorry, not to insult you but EIGRP is not a distance vector protocol. You probably were gonna say IGRP, rather. However, in my case, i am suspicous about why i should advertise the network known by all routers already!

zrockstar

thedrama wrote: »

sorry, not to insult you but EIGRP is not a distance vector protocol. You probably were gonna say IGRP, rather. However, in my case, i am suspicous about why i should advertise the network known by all routers already!

Actually EIGRP is a distance vector routing protocol.

NetworkVeteran

thedrama wrote: »

sorry, not to insult you but EIGRP is not a distance vector protocol.

Sorry, not to insult you, but EIGRP is indeed a distance vector routing protocol.

From Cisco's website:

"EIGRP is an enhanced distance vector protocol, relying on the Diffused Update Algorithm (DUAL) to calculate the shortest path to a destination within a network."

NetworkVeteran

thedrama wrote: »

However, in my case, i am suspicous about why i should advertise the network known by all routers already!

In a typical frame-relay hub-and-spoke topology, the spokes form adjacencies with the Hub, but not with one another. If you add network 192.168.32.0 to SpokeA, it will tell the Hub; it won't tell SpokeB. Therefore, for dynamic and full network connectivity, we need the Hub to relay routes between spokes. It needs to tell SpokeB about the new network. It won't do this--assuming SpokeA and SpokeB are both reached via the same Hub interface--without configuring a form of 'no ip split-horizon' on that interface.