The problem here is that the Layer 2 technology being used (Frame Relay) is not capable of allowing Spoke 1 to find Spoke 2. Layer 3 is working well. EIGRP (or RIP, or OSPF) is running on the hub and the spokes, routes are being learned correctly, and all three routers have correct routes to reach each other. The split-horizon rule has been dealt with, so the hub is able to advertise the routes it has learned from Spoke 1 to Spoke 2 and visa versa. The problem is at layer 2.
So let’s imagine that Spoke 2 wants to send data to Spoke 1. The encapsulation process occurs, placing the TCP or UDP segment into an IP packet. The IP packet header is populated with a source address of 192.168.123.3 and a destination IP of 192.168.123.2. Next, the IP packet must be encapsulated into a Layer 2 frame.
Now if this was Ethernet, we would either look in the ARP table to find the MAC address that corresponds to 192.168.123.2, or send out an ARP request for that information. Once we get it, we encapsulate, and send it on its way.
But this is Frame Relay, and we can learn the DLCIs that correspond to the destination IP address in one of several ways. Either Inverse ARP, or using a manual entry of a frame-relay map, telling each router what Layer 2 address (DLCI in this case) corresponds to the IP address. If this does not exist, then the encapsulation process cannot occur and the packet is dropped even before it is sent. By doing a show frame-relay-map, we’ll be able to determine if those DLCI entries are there or not.
Once we verify that they are there, then encapsulation can occur, and the Layer 2 PDU can be placed on the wire and sent to its destination.
I have just read EIGRP over Frame-Relay multi-point version and for the prefix 2.2.2.0/24 R3 has next hop the router 192.168.123.1 (hub router) . So i believe that was a typing error . I think that happens on a DMVPN topology with NHRP .
Thanks again about your detail explanation.
R3#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2809856] via 192.168.123.1, 00:00:22, Serial0/0
In the EIGRP over Frame-Relay lesson, we don’t have any frame relay map entries other than those created by Inverse ARP. This means that in that topology, the hub (or R1 as it is labeled) has frame relay map entries for both R2 and R3 (the spokes) but each of R2 and R3 have only frame relay mappings for the hub (R1). This means that the only option for routing here is via the hub, and this is why you see a next hop IP address of the hub.
In the example in this lesson, we have two statically assigned frame relay mappings in each spoke, including the broadcast keyword, so that direct access at Layer 2 between the two spokes is possible, and the next hop IP address can be that of the spoke router itself.
If you do a search using your favourite search engine, you will also find a multitude of images describing these headers in detail.
Remember that communication between EIGRP and OSPF routers takes place at Layer 3, and this is control plane traffic, which means that the source and destination of these packets are always the routers themselves (as opposed to traffic generated by hosts communicating to each other which is on the data plane). This means that communication as viewed on the OSI model will only go up to L3 of the OSI stack.
BGP on the other hand also functions in the Transport layer as some of its operations include what are known as TCP Connection Based Events. So you will see communication going up to Layer 4 of the OSI stack for some BGP operations. The following lesson describes some of these operations that use TCP as well:
On an active serial interface, it is expected that split horizon will be disabled. This is intentional behavior by Cisco IOS and is designed to make Frame Relay work properly in the most common deployment scenario of a hub-and-spoke topology.
As you probably already know, split horizon is a loop-prevention mechanism for distance-vector routing protocols (RIP, EIGRP) that states: “Don’t advertise a route back out the same interface you learned it from.”
When you configure encapsulation frame-relay on a physical serial interface, Cisco IOS treats it as a multipoint NBMA (Non-Broadcast Multi-Access) interface by default. In this scenario, split horizon is automatically disabled when the interface becomes active.
Now why is that already configured by default? It could be that you’re using a newer version of IOS than was used for the lesson, and it’s “smarter” and it sets he correct split horizion configs for that particular type of link. In the lesson, it is assumed that this is not done automatically.
Now there’s an important distinction in how RIP and EIGRP deal with this. For RIP, it uses the generic split horizion setting on the interface, and you can see that setting with the show ip interface command. However, EIGRP has its own separate split horizon control via ip split-horizon eigrp <asn>. So you may see RIP’s split horizon disabled automatically while EIGRP’s split horizon may still be enabled unless explicitly disabled. This is a common point of confusion when troubleshooting EIGRP over Frame Relay.