Frame Relay split horizon solution In a hub-and-spoke Frame Relay network, how should the router be configured to avoid split horizon blocking of routing updates?

Introduction / Context:
Split horizon prevents a router from advertising a route back out the interface on which it was learned. In hub-and-spoke Frame Relay topologies using a single multipoint interface, split horizon can block spoke-to-spoke reachability for distance-vector protocols like RIP and EIGRP (when classic rules apply). The industry-standard fix is subinterfaces.

Given Data / Assumptions:

• Frame Relay hub-and-spoke with multiple PVCs.
• Distance-vector or DV-like behavior that honors split horizon.
• Goal: allow proper routing updates to all spokes.

Concept / Approach:

Configure point-to-point subinterfaces, one per PVC, each with its own unique subnet and DLCI. This design treats each PVC as a separate interface, disabling split horizon constraints across spokes and allowing clean summarization and access control. It also improves broadcast/multicast handling for routing protocols.

Step-by-Step Solution:

Verification / Alternative check:

Use show frame-relay pvc to verify PVCs, and confirm routing tables on spokes include all remote networks without manual split-horizon workarounds.

Why Other Options Are Wrong:

• Option B is conceptually similar but vague; the concrete, canonical method is distinct point-to-point subinterfaces per PVC with unique subnets.
• Option C places many subinterfaces in the same subnet, reintroducing ambiguity and split-horizon issues.
• Option D multipoint subinterface with many PVCs retains split-horizon concerns.
• Inverse ARP suppression does not solve split horizon.

Common Pitfalls:

• Leaving hub as multipoint with a single subnet; updates will not propagate between spokes.
• Forgetting to change from IETF to Cisco encapsulation as appropriate across vendors.

Final Answer:

Configure a separate subinterface for each PVC with a unique DLCI and subnet assigned to the subinterface.