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:
Spoke1:
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:
-
inverse arpis enabled and we have enough command
frame-relay interface-dlci 102
-
inverse arpis turned off and we need at least two teams:
frame-relay interface-dlci 102frame-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
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 2.2.2.0/24 that appears in the routing table of the Spoke 2 router is indeed 192.168.123.2. 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 2.2.2.0/ 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!
Laz
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