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: