EIGRP over Frame-Relay

@Forrest That’s right, in that example I only solved the problem for the ping from R3 to R2 by adding a frame-relay map on R2. For the other way around, you should add a map on R3 as well.

The underlying problem here is that EIGRP expects the network to be multi-access, this means that all devices should be able to reach each other directly. In reality, only the hub can reach the spokes directly. You won’t be able to estalish an EIGRP adjacency between R2/R3 directly with only PVCs to the hub.

It’s better to use frame-relay point-to-point everywhere instead. You won’t have issues with split horizon and spoke-to-spoke connectivity.

Trying OSPF instead of EIGRP is also an option. Take a look at this example:

https://networklessons.com/ospf/ospf-next-hop-ip-address-with-different-network-types/

Depending on the OSPF network type, OSPF will use different IP addresses for the next hop which solves the missing frame-relay maps problem.

In the hub and spoke topology, the hub is always a single point of failure. You could solve this by adding a second hub. Two hubs routers on your main network, all spoke routers connected to both hubs. It’s similar to the DMVPN topology with two hubs:

https://networklessons.com/security/dmvpn-dual-hub-single-cloud/

@Nirosh you will need a routing protocol (like EIGRP) to advertise any networks BEHIND the hub or spoke routers. If there is no connectivity between two (spoke) routers, you will have to add some additional frame-relay maps.

Rene

1 Like