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?
-
AConfigure a separate subinterface for each PVC with a unique DLCI and subnet assigned to the subinterface.
-
BConfigure each Frame Relay circuit as a point-to-point line to support multicast and broadcast traffic.
-
CConfigure many subinterfaces in the same subnet.
-
DConfigure a single subinterface to establish multiple PVC connections to multiple remote router interfaces.
-
EUse inverse ARP suppression on the hub to bypass split horizon.
Answer
Correct Answer: Configure a separate subinterface for each PVC with a unique DLCI and subnet assigned to the subinterface.
Explanation
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:
Under Serial interface, create subinterfaces: interface s0/0.1 point-to-point, s0/0.2 point-to-point, etc.Bind each subinterface to a single DLCI with frame-relay interface-dlciVerification / 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.