How to configure Frame-Relay Point-to-Multipoint

Hi Sims,

Do you have a frame-relay map on R2 and R3 (the spokes) for each others IP addresses? You probably have a frame-relay map for R1 (hub) but not for the other spoke.


Disregard. Thanks. I figured out what I did wrong.

1 Like

sir in your demonstration in frame-relay point-to-multipoint are u running some routing protocol in it b/w hub and spoke 1 and spoke 2. because i did the same thing it’s pinging when i configure rip or eigrp .
when u said
Next step is to configure a distance vector routing protocol so I can demonstrate how to deal with split-horizon. I’ll use RIP but you can also use EIGRP: ( Were u running some routing protocol before )

but I don’t see in the configuration in the hub or spoke 1 and spoke 2 in the first demonstration so my question is can frame-relay work when we use mapping without configuring any routing protocol running.


Hi Zeko,

In this example, I didn’t have any routing protocols configured before I configured RIP. This is why I can only ping using the subnet as the hub router and spoke routers don’t have anything else in their routing tables.

Technically, a frame-relay map for an IP address behind another router will work. For example, if you configure a frame-relay map for DLCI 102 to on the hub router then it will be able to ping

This is a nice hack but not the best way to approach this. The frame-relay map is supposed to be used to map L2 information (DLCI) to L3 information (IP address) so it’s best to have a single frame-relay map to map your L2 DLCI to the L3 IP address of the other side and then use routing to reach remote subnets. You can use a routing protocol or static routes.

Hope this helps!


I configured this in GNS3 using just the physical interfaces, no subinterfaces, and static frame-relay mappings between the hub and spokes, and between each spoke. However, when RIP is enabled, Spoke2 has Spoke1’s loopback in its routing table even though I haven’t disabled split-horizon on the Hub router. I don’t see any default ‘no ip split-horizon’ in the Hub router’s configuration. Is this normal? I would expect it not to be advertised to Spoke2 because of split-horizon.

Thank you for any help.

Hello Jeremy

This is expected behaviour. The split horizon rule says: No destination will be advertised out of the SAME (physical) interface that it has been learned from. Because you changed the physical topology and you connected each spoke to a DIFFERENT interface, the split horizon rule does not apply. If you had subinterfaces on the SAME physical interface, then the split horizon rule would kick in.

So in your topology, there is no need to disable the split horizon rule.

I hope this has been helpful!


Thank you Laz, but actually I just used one physical interface on the Hub router. I made it again on GNS3 and still Spoke2 learns Spoke1’s loopback through RIP even though I used a single physical interface on the Hub router and didn’t disable split-horizon.
Here are screenshots of the configuration of the interface used on each router:




From your explanation I think Spoke2 shouldn’t learn about Spoke1’s loopback interface via RIP unless I disable split-horizon, yet it does. Is there something I could be missing or misunderstanding?

Thank you so much for any help.

Hi Jeremy,

If you do a show run all | include split does it show anything?

Since you have a single physical interface on the hub, split horizon should prevent advertising a RIP route between the spokes. Which IOS version is this?


In the first part, the Frame-Relay is considered on the physical serial interface, but there is no “frame-relay interface-dlci 102” on interface command for example, just as hereinafter when considering the sub interface, this command also does not.
How does Frame-Relay switch understand where the correct DLCI is?
How true is this setting?

Hello Sergei

There are several ways to get a Frame Relay PVC working correctly. One is to use the frame-relay interface-dlci 102 command. However, this would not apply here as it is only used on subinterfaces. It is not common to use, although it does have its uses. When applied, it will assign a DLCI to the subinterface. When the subinterface already has a DLCI assigned and an IP address has been configured on it, Inverse-ARP requests can now be sent to acquire the IP addresses of the neighbor devices.

Alternatively, the command used on the subinterfaces in the example in the lesson is the frame-relay map ip command. This command actually disables Inverse ARP and statically corresponds the IP addresses with the DLCIs.

Without any of these settings, on the physical interface, it is necessary to apply the frame-relay map ip command. So yes indeed you are correct that this must be implemented, and it has not in the lesson. I will let Rene know to make the appropriate adjustments.

Thanks for pointing it out!


1 Like

Thx Laz! And on more question:
Did I understand correctly that:
On the physical interface it is necessary to execute the frame-relay map ip command regardless of whether inverse arp is on or off.
The frame-relay interface-dlci 102 command cannot be executed on physical interface.

And the setting will be:

`Hub(config)#interface serial 0/0`
`Hub(config-if)#encapsulation frame-relay`
`Hub(config-if)#frame-relay map ip 102`

And on sub interfaces there are two options:

  1. inverse arp is enabled and we have enough command
  • frame-relay interface-dlci 102
  1. inverse arp is turned off and we need at least two teams:
  • frame-relay interface-dlci 102
  • frame-relay map ip

Hello Sergei

Sorry Sergei, what I mentioned in the previous post was not entirely correct. Let me clarify:

When configuring point to point Frame Relay with subinterfaces, you can use the following command:

frame-relay interface-dlci XXX

This command configures the DLCI of the subinterface. It also keeps Inverse ARP active to be able to find the DLCI of the other end of the circuit, assuming the IP address has also been configured on the subinterface. Now this command is typically used for subinterfaces, but can also be applied to the main physical interfaces to enable routing protocols that are configured to use Inverse ARP. This however goes beyond the scope of CCNA/CCNP.

Now if you want to statically map DLCIs and not use Inverse ARP, then you can use the frame-relay map ip command. This command will disable Inverse ARP. You can also explicitly disable Inverse ARP before applying this command. Note here that the DLCI and IP address used in the map are those of the remote frame-relay router and not of the local router. This is why Inverse ARP becomes disabled, because it is no longer needed.

The settings that you have indicated in your post above are correct.

I hope this has been helpful!


1 Like

i have a question , what is the reason that does not change the next hop of the advertised subnet as usual, like happens in common network topologies ? Behaves likes seeing as next hop .


Geia sou Dionisis

If you resolve the issue with split horizon as was done in the lab, then the next hop IP address for the network that appears in the routing table of the Spoke 2 router is indeed This is normal behaviour because all three routers are in the same subnet.

Imagine that this was an Ethernet network, where the Hub, Spoke1 and Spoke2 were connected to an L2 switch. Then routing would still inform Spoke2 that to reach the network, your next hop IP would be the Spoke1 router. It would never go to the Hub first and then Spoke1 because all three routers are in the same subnet.

Now because we are using a point to multipoint topology over a non-multiaccess network technology, Spoke2 is unable to reach the IP address of Spoke1 (in an Ethernet topology, this address would be reachable). In order to solve this, we have to add some information on Layer 2 of the OSI model with frame relay mappings of the IP addresses and the DLCIs so that the Spokes can reach each other.

I hope this has been helpful!


kalispera Lazaros
it is enough good explanation but i still have some doubts . I am trying to find what is missing of this puzzle on my mind. What makes me difficult is that all three routers are configured with eigrp and the subnet is advertised from spoke 1 to the hub and from there to spoke 2 . What you explain It would make sense in my mind if there was no eigrp configurtion on the hub router and prefix has been advertised as a layer 2 packet from spoke 1 to the hub and from the hub to the spoke 2 .
thanks again for your response

Hello Dionisis

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 and a destination IP of 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, 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 hope this has been helpful!


Hello Laz ,

I have just read EIGRP over Frame-Relay multi-point version and for the prefix R3 has next hop the router (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 is subnetted, 1 subnets
D [90/2809856] via, 00:00:22, Serial0/0

Hello Dionisis

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.

I hope this has been helpful!


Hi sir,

I seeking to know about EIGRP,OSPF and BGP Header and which services they use and how that packets move in OSI layers.

Thank you.

Hello Akash

You can find out details about the headers of the packets exchanged using these routing protocols at their respective RFCs:

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:

I hope this has been helpful!