In a Frame Relay hub-and-spoke network, split horizon can prevent routing updates from being sent between spokes. How should you configure the hub router so that split horizon does not block updates between spokes?

Introduction / Context:
In hub and spoke Frame Relay networks, a single hub router connects multiple spoke routers over individual Permanent Virtual Circuits. Distance vector and advanced distance vector routing protocols use the split horizon rule, which prevents a router from sending information about a route back out of the interface on which it was learned. On a hub router using a single multipoint Frame Relay interface, this can prevent routing updates learned from one spoke from being sent to other spokes. Cisco provides a configuration strategy using subinterfaces to overcome this limitation without disabling split horizon entirely.

Given Data / Assumptions:

• We have a Frame Relay hub and multiple spokes.
• The hub has multiple PVCs to different spokes over a single physical serial interface.
• Split horizon in the routing protocol is causing updates from one spoke to be blocked from reaching other spokes.
• We want a configuration that avoids split horizon issues while preserving good design practice.

Concept / Approach:
The usual solution is to configure a separate point to point subinterface on the hub for each Permanent Virtual Circuit. Each subinterface is treated by the router as a separate logical interface with its own subnet and Data Link Connection Identifier. Because split horizon applies per interface, routing updates received on one subinterface are not considered to be received on the same interface as another subinterface. Therefore, the hub can pass routes from one spoke to another without violating split horizon rules. This design also simplifies addressing and troubleshooting, because each spoke link has its own subnet.

Step-by-Step Solution:
1. Begin on the hub router, which currently may have a single multipoint Frame Relay interface with several Data Link Connection Identifiers. 2. Reconfigure the physical interface to use logical point to point subinterfaces, for example serial0/0.1, serial0/0.2, and so on. 3. On each subinterface, configure encapsulation frame-relay and assign one Permanent Virtual Circuit with a unique Data Link Connection Identifier and a unique IP subnet. 4. Configure the routing protocol on each subinterface so that routes from each spoke are learned independently. 5. Because each subinterface is treated as a separate interface by the routing protocol, split horizon no longer prevents routes learned from one spoke from being advertised to another.

Verification / Alternative check:
After the configuration change, you can use show ip route on the spokes to verify that they now learn routes to other spokes through the hub. You can also examine show frame-relay map and show interfaces to confirm that each subinterface is active with the correct Data Link Connection Identifier and IP addressing. If desired, you may compare behaviour with and without split horizon disabled, but the point-to-point subinterface method is considered cleaner and more scalable than disabling split horizon on a multipoint interface.

Why Other Options Are Wrong:
Combine multiple Frame Relay circuits into a single point-to-point line: This option is vague and does not address split horizon. Simply aggregating circuits does not change the fundamental issue that routes learned on one logical interface are not forwarded back out that interface.
Configure many subinterfaces that all share the same subnet: Using a shared subnet over multiple subinterfaces defeats the purpose of separating interfaces. Split horizon and addressing confusion may still be present.
Use a single physical interface to terminate all PVCs with no subinterfaces at all: This describes the problem scenario rather than the solution. Split horizon issues arise precisely when all spokes share one interface.
Disable routing protocols and use only static routes: While static routes avoid split horizon issues, they do not scale well in dynamic environments and are not the recommended design for hub and spoke Frame Relay networks using dynamic routing.

Common Pitfalls:
Learners sometimes respond by disabling split horizon on the main interface. Although this can work, it can mask other design issues and is not always recommended as best practice. The use of point to point subinterfaces leads to a cleaner design with clear logical separation, simpler addressing, and easier troubleshooting. Remember that each spoke should have its own subinterface and subnet on the hub, which naturally avoids split horizon problems while preserving the advantages of dynamic routing protocols.

Final Answer:
Configure a separate point-to-point subinterface for each PVC with a unique DLCI and subnet