How to configure Frame-Relay Point-to-Multipoint

Hi Palani,

You might want to check if no split horizon is the default on your router. Try a show run all | include split to see what the default setting is.

Rene

Hi
Why I cant ping from spoke 1 to spoke 2 .
How to do that

Thanks

Hello Sims.

Can you be a bit more specific about your problem?

Thanks!

Laz

Hi,
I Was trying to ping from spoke1 to spoke2 router , before onfiguring routing protocol.
The question is , at this point why i can’t ping
Thanks

Hello Sims

Are you using the same configs that @ReneMolenaar used in his lab? Have you checked to see that your IP address and DLCI configurations are correct?

Laz

Hi,

Here is my configuration

**R2-spoke2**
-----
interface Serial2/2
ip address 192.168.123.2 255.255.255.0
encapsulation frame-relay
serial restart-delay 0

**R1-hub**

interface Serial2/1
 ip address 192.168.123.1 255.255.255.0
 encapsulation frame-relay
 serial restart-delay 0

---

**R3-SPOKE2**

interface Serial2/3
 ip address 192.168.123.3 255.255.255.0
 encapsulation frame-relay
 serial restart-delay 0
!

**FR-switch**
-----
interface Serial2/1
description R1
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay intf-type dce
frame-relay route 102 interface Serial2/2 201
frame-relay route 103 interface Serial2/3 301
!
interface Serial2/2
description R3
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay intf-type dce
frame-relay route 201 interface Serial2/1 102
!
interface Serial2/3
description r3
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay intf-type dce
frame-relay route 301 interface Serial2/1 103

i can ping from R3 to R1 and R2 to R1 , but not from R2- to R3

Thanks

**strong text**

Hi,
This is exactly the same configurations

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.

Rene

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.

thanks

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 192.168.123.0/24 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 2.2.2.2 on the hub router then it will be able to ping 2.2.2.2.

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!

Hello,

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!

Laz

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:

Hub:
hub

Spoke1:
spoke1

Spoke2:
spoke2

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?

Rene

HI!
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!

Laz

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 192.168.123.2 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!

Laz

1 Like

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

Thanks