I have only used it routing trough the hub router. I mean, all the spokes routers had routes to all the other spokes routers pointing to the ip address of the subinterface in the hub router, and the hub router, routed the packets between them. Nevertheless, I saw a document where Cisco explains how to configure static mapping between spokes routers on a partially meshed network. I have not tested it yet, but here you have the link:

Hi Martin, I though exactly the same you are telling here, I have even worked with this scenario in real live with a network (Hub and Spoke) in my last job, but after I read the doc from ciscopress that I mentioned (http://www.ciscopress.com/articles/article.asp?p=170741&seqNum=4) I have my doubts about it, because if I have understood this doc, it is possible to map spoke routers directly even if there is not a VC between them. I don´t know how could it work, maybe I have misunderstood that doc. Please, it would be great if you comment that document, when it says:

“For example, the spoke router R1 uses static mapping to reach router R2 at 172.16.1.2 because there is no direct connectivity between them on the partially meshed network to use dynamic Inverse ARP. Because R1 and R3 are directly connected by a VC, they can rely on dynamic mapping to resolve the next hop protocol address via dynamic Inverse ARP. The same applies between router R2 and hub router R3. On router R1 and R2, static mapping needs to be used to instruct R1 to reach R2 via its local DLCI 103 and for R2 to reach R1 via its local DLCI 203.”

Frame Relay Inverse ARP or Static Mappings perform the same function as ARP does for Ethernet. In Ethernet you need to find the MAC address for an IP address. In Frame Relay you need to find the DLCI address for an IP address.

What that paragraph is saying is that R1 and R2 only have a connection / PVC / DLCI to the hub (R3). This means that traffic from R1 to R2 has to go to R3 first. The problem though is that R1 can't send an Inverse ARP request to R2, because they don't have a connection. This is fixed by putting a static mapping. This would be like doing a static ARP entry on an Ethernet interface. It doesn't change the fact that traffic from R1 to R2 has to go to R3 first, it just changes how the router figures out how to build the layer 2 Frame Relay header.

Thank you Brian for clarifying this topic. Please, could you tell me what´s the advantage between doing the static map in Frame Relay spoke-to-spoke with just letting those spokes routers learn a route to each other through the Hub router. Even with a static default ip route it should work just fine.

Hi Martin, we agree that we are talking about two different layers here (IP and FR), and I assuming the objective of this static FR mapping is to let both spokes routers communicate directly through their 172.16.1.0/24 addresses without having a directly connection. If this is ok, I assume that R3, at FR level, is able to “route” the frames received from the spokes to the respective PVC without using its IP layer (but he needs to take the destination IP address from somewhere because he needs to know where to send those frames and all of them arrives with the local dlci). That’s what I can’t imagine how is happening.

The alternative I was mentioning is, if we could just add routes (L3 IP) to the hub router, and let him take care of the routing to R2 networks. For example, suppose we have correctly configure the FR PVC between R1-R3 , and R2-R3, and suppose the network behind R1 is 1.1.1.0/24 and the network behind R2 is 2.2.2.0/24. Now, we add static routes (to make it simple) in this way:

Route in R1

ip route 2.2.2.0 255.255.255.0 172.16.1.3

Route in R2

ip route 1.1.1.0 255.255.255.0 172.16.1.3

Routes in R3

ip route 1.1.1.0 255.255.255.0 172.16.1.1

ip route 2.2.2.0 255.255.255.0 172.16.1.2

Of course, R3 and R2 never communicate directly, and a ping from 172.16.1.1 to 172.16.1.2 won´t work. But the communication of their respective networks will.

I’m sorry if something here is trivial, but I´ve never used FR in this way.

As far as I can tell you, you should use the broadcast parameter in physical interfaces and point-to-multipoint subinterfaces when you use static mapping (by default it disables the broadcast), in order to allow broadcast and multicast packet go over those PVC. It is useful for routing protocols implementations like OSPF that requires extra configuration parameters if this is not allowed. As a reference you could read this: