Frame Relay is a topic that is widely discussed inside the Cisco certifications, as you encounter it in both the CCNA and CCNP topics. Outside of that, however, I still have to see the first real-world Frame Relay circuit still in use, as MPLS is a more commonly used WAN technology these days.
As a full mesh, Frame Relay works quite similar to a normal Ethernet broadcast domain at layer 2 and layer 3. The complexity arises when Frame Relay is deployed in a partial mesh. I struggled a long time with the concepts of Frame Relay, so to help understand others the oddities of a partial mesh, I will explain things by the following topology:
In this topology router R1 is the main site that has a Frame Relay PVC to all other sites. The branch sites, R2, R3, R4 and R5, each have one PVC back to R1. They don’t have PVCs to each other. This is a hub and spoke setup: R1 is the hub, the others are spokes. The routers use the 10.0.0.0/24 subnet, which each router an IP equal to it’s number, e.g. R1 has 10.0.0.1, R2 has 10.0.0.2. After configuring the Frame Relay switch, the initial setup for the routers is fairly simple:
Router(config)#interface Serial0/0
Router(config-if)#encapsulation frame-relay
Router(config-if)#ip address 10.0.0.x 255.255.255.0
Router(config-if)#no shutdown
Router(config-if)#exit
Since Cisco routers have the command ‘frame-relay reverse-arp’ activated by default, all routers find out the layer 3 address (IP) on each PVC (layer 2). R1 can ping every router, the others can ping R1 but not each other.
So far so good, now we configure EIGRP on all routers. We also configure a loopback interface that will be advertised: 10.0.1.1/24 on R1, 10.0.2.1/24 on R2, and so on.
Router(config)#interface Loopback 0
Router(config-if)#ip address 10.0.x.1 255.255.255.0
Router(config-if)#exit
Router(config)#router eigrp 1
Router(config-router)#network 10.0.0.0 0.0.255.255
Router(config-router)#end
Adjacencies from quickly, and R1 can see all routes now. But the four spoke routers can’t see each others routes. No problem, just disable the split-horizon rule of EIGRP on the hub router, so that received updates will be send out of the serial interface again to the others.
Router(config)#interface Serial0/0
Router(config-if)#no ip split-horizon eigrp 1
Router(config-if)#exit
After a graceful EIGRP restart, all spoke routers can see all routes. But despite this, a spoke router still can’t reach another spoke router’s loopback. Why not? Well, because the spoke routers have no idea how to get there. The frame-relay reverse-arp mentioned earlier finds out what’s at the other side of a PVC link, but it does not go further than that. Unable to gather the correct ARP information, packets will be dropped. To make it possible, you will need to add static mappings to the spoke routers. The PVC used is of course the only PVC possible on a spoke router.
Router(config)#interface Serial0/0
Router(config-if)#frame-relay map ip 10.0.0.x <pvc>
Router(config-if)#exit
Since the next hop defined in the routering protocol is now reachable, the spoke routers can ping each other’s loopbacks. Packets will be send to the hub router first, who will then relay these packets back out of the serial interface to another PVC. The single point of failure is the central hub, since everything depends on it.
In OSPF it’s the same: you will need to add these static mappings to make the actual forwarding work. The configuration of OSPF itself is different, as OSPF has no concept of split-horizon (that’s for distance vector protocols, not link-state). I personally prefer configuring the serial interface as broadcast, allowing for automatic neighbor discovery, and set the hub router as DR (router-id, and configured as first).
Router(config)#interface Serial0/0
Router(config-if)#ip ospf network broadcast
Router(config-if)#exit
The layer 2 topology now reflects the DR situation: a spoke router will send a link-state advertisement to the hub router (the only PVC), and the hub router send out a multicast to all spoke with the necessary information.
I hope that this is an informative post to those who want to better understand Frame Relay partial mesh.
Reggle 
hi reggle……..i just tried your sugessions. it worked……..
still cannot understand why do i need to use static routing to ping from spoke router to spoke router???
sorry, my bad!! when i said “static routing”…….i mean “static mapping”
my point is “as each spoke can see all other spoke(because of dynamic routing protocol)……………packet should be automatically routed……..right???
Hi Hasan,
But the spokes can’t see each other by default, that’s the problem. I mention ‘R1 can ping every router, the others can ping R1 but not each other.’ There is no static routing involved, but static mappings. These are more like static ARP mappings, they map the IPs of the other spoke routers to the PVC of the hub router. The hub router will forward any packet it receives to the right router, as it has a PVC to all of them. It’s only after these static mappings are defined that the spoke routers can see each other.
To refer to the OSI model: all routers receive routes from the hub router with as next-hop a spoke router. That makes that the correct layer 3 information is present. But the layer 2 information (which PVC to use to reach a router) is missing without the static mappings.
Greetings!