How to Set Up Frame Relay on Cisco Routers: Configuration and Troubleshooting Guide

Frame Relay doesn’t show up much in greenfield deployments anymore — MPLS and internet-based VPNs have largely replaced it — but I still cover it thoroughly with anyone studying for CCNA/CCNP-level certifications, and I still run into it occasionally in legacy WANs that just haven’t been migrated yet. Understanding it deeply also makes every other WAN technology you’ll touch (MPLS, ATM, even VXLAN’s underlying concepts of virtual circuits) click into place faster. So even though it’s a “legacy” protocol, it’s far from a wasted topic.

This guide covers Frame Relay concepts, full hub-and-spoke configuration, sub-interfaces, inverse ARP, and the troubleshooting steps that resolve 90% of real-world Frame Relay issues.

What Frame Relay Is

Frame Relay is a Layer 2 WAN protocol that provides virtual circuits over a shared provider network, historically a cost-effective alternative to leased lines. Instead of a dedicated physical circuit per site, multiple customers share provider infrastructure, with logical circuits called Data-Link Connection Identifiers (DLCIs) identifying each virtual path.

Key concepts:

• DLCI (Data-Link Connection Identifier) — a locally significant identifier for a virtual circuit, similar in spirit to a VLAN ID but scoped to Frame Relay
• PVC (Permanent Virtual Circuit) — a provider-provisioned logical path between two endpoints, functionally always “up” once configured
• LMI (Local Management Interface) — the signaling protocol between router and Frame Relay switch that reports DLCI status (active, inactive, deleted)
• Inverse ARP — dynamically maps a DLCI to a remote IP address, avoiding manual static mapping
• CIR (Committed Information Rate) — the guaranteed throughput a provider commits to for a given PVC

Hub-and-Spoke Topology for This Guide

• Hub: R1 (headquarters)
• Spokes: R2 (Branch A), R3 (Branch B)
• DLCI 102 on R1 pointing to R2, DLCI 103 on R1 pointing to R3
• DLCI 201 on R2 pointing to R1
• DLCI 301 on R3 pointing to R1

        R2 (Branch A)
       /
R1 (Hub)
       \
        R3 (Branch B)

Step 1: Enable Frame Relay Encapsulation on the Physical Interface

On R1’s Frame Relay-facing serial interface:

R1(config)# interface Serial0/0/0
R1(config-if)# encapsulation frame-relay
R1(config-if)# frame-relay lmi-type cisco

Modern IOS auto-detects LMI type in most cases, but explicitly setting it (cisco, ansi, or q933a) avoids ambiguity, especially with non-Cisco Frame Relay switches at the provider edge.

Step 2: Choose Sub-Interfaces vs. Physical Interface (Design Decision)

Physical interface (single IP, multiple DLCIs) works but creates split-horizon issues with distance-vector routing protocols in hub-and-spoke topologies, since a hub can’t forward a route learned from one spoke back out the same physical interface toward another spoke.

Sub-interfaces solve this cleanly by giving each virtual circuit its own logical interface, each with its own IP subnet (point-to-point sub-interfaces) or shared subnet (multipoint sub-interfaces). Point-to-point sub-interfaces are the modern best practice for hub-and-spoke Frame Relay.

Step 3: Configure Point-to-Point Sub-Interfaces on the Hub (R1)

R1(config)# interface Serial0/0/0.102 point-to-point
R1(config-subif)# ip address 10.0.12.1 255.255.255.252
R1(config-subif)# frame-relay interface-dlci 102

R1(config)# interface Serial0/0/0.103 point-to-point
R1(config-subif)# ip address 10.0.13.1 255.255.255.252
R1(config-subif)# frame-relay interface-dlci 103

Each sub-interface gets its own subnet and its own DLCI mapping — this is the key structural difference from a single multipoint interface.

Step 4: Configure the Spoke Routers

On R2 (Branch A):

R2(config)# interface Serial0/0/0
R2(config-if)# encapsulation frame-relay
R2(config-if)# frame-relay lmi-type cisco

R2(config)# interface Serial0/0/0.201 point-to-point
R2(config-subif)# ip address 10.0.12.2 255.255.255.252
R2(config-subif)# frame-relay interface-dlci 201

On R3 (Branch B):

R3(config)# interface Serial0/0/0
R3(config-if)# encapsulation frame-relay
R3(config-if)# frame-relay lmi-type cisco

R3(config)# interface Serial0/0/0.301 point-to-point
R3(config-subif)# ip address 10.0.13.2 255.255.255.252
R3(config-subif)# frame-relay interface-dlci 301

Step 5: Multipoint Sub-Interface Alternative (If Preferred)

If you’d rather keep all spokes on one shared subnet (multipoint design), configure a single sub-interface with static or Inverse-ARP-based DLCI-to-IP mappings:

R1(config)# interface Serial0/0/0.100 multipoint
R1(config-subif)# ip address 10.0.100.1 255.255.255.0
R1(config-subif)# frame-relay map ip 10.0.100.2 102 broadcast
R1(config-subif)# frame-relay map ip 10.0.100.3 103 broadcast

The broadcast keyword is essential here — it allows routing protocol multicast/broadcast hellos (OSPF, EIGRP) to traverse the PVC, since Frame Relay PVCs are inherently non-broadcast by nature.

Step 6: Verification

Check interface and DLCI status:

R1# show frame-relay pvc
PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0.102

  input pkts 245       output pkts 238       in bytes 21032
  out bytes 20544       dropped pkts 0        in FECN pkts 0
  in BECN pkts 0        out FECN pkts 0       out BECN pkts 0
  in DE pkts 0          out DE pkts 0
  out bcast pkts 12     out bcast bytes 1224
  pvc create time 00:45:12, last time pvc status changed 00:44:58

PVC STATUS = ACTIVE confirms the circuit is fully operational end-to-end. INACTIVE typically means the local router sees LMI signaling but the far end isn’t responding; DELETED means the provider hasn’t provisioned that DLCI at all.

Check LMI status:

R1# show frame-relay lmi
LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = CISCO
  Invalid Unnumbered info 0             Invalid Prot Disc 0
  Invalid dummy Call Ref 0              Invalid Msg Type 0
  Invalid Status Message 0              Invalid Lock Shift 0
  Invalid Information ID 0              Invalid Report IE Len 0
  Invalid Report Request 0              Invalid Keep IE Len  0
  Num Status Enq. Sent 245              Num Status msgs Rcvd 245
  Num Update Status Rcvd 0              Num Status Timeouts 0

Check DLCI-to-IP mapping table (relevant especially with Inverse ARP or static maps):

R1# show frame-relay map
Serial0/0/0.102 (up): point-to-point dlci, dlci 102, broadcast
  status defined, active

Confirm end-to-end reachability:

R1# ping 10.0.12.2
R1# ping 10.0.13.2

Real-World Enterprise Scenario: Legacy WAN Coexisting with MPLS Migration

It’s common to encounter Frame Relay still running at a handful of remote branch offices during a phased MPLS migration, where headquarters and most branches have already cut over but one or two remote sites are waiting on new circuit installation. In that scenario, the hub router often runs both an MPLS-facing interface and a legacy Frame Relay sub-interface simultaneously, with routing protocols (typically EIGRP or OSPF) advertising routes consistently across both transport types so end users see no difference in reachability during the transition period. Careful attention to split-horizon behavior and sub-interface design (point-to-point vs. multipoint) is critical here, since getting it wrong silently breaks spoke-to-spoke or hub-to-spoke reachability without any obvious link-down symptom.

Security Best Practices

• Frame Relay itself has no built-in encryption or authentication — treat it as an untrusted transport and layer IPsec on top for any traffic requiring confidentiality
• Restrict DLCI mapping tables to known, expected values; unexpected DLCIs appearing via Inverse ARP can indicate a misconfigured or unauthorized provider circuit
• Apply standard WAN edge protections (ACLs, control-plane policing) on Frame Relay-facing interfaces just as you would on any other WAN transport

Common Configuration Mistakes

• Using a single physical (non-sub) interface for hub-and-spoke, then wondering why spoke-to-spoke routes never propagate (classic split-horizon issue with distance-vector protocols)
• Forgetting the broadcast keyword on multipoint frame-relay map statements, silently breaking dynamic routing protocol adjacency over that PVC
• Mismatched LMI type between router and provider Frame Relay switch, though auto-sense usually catches this on modern IOS
• Assuming a PVC showing ACTIVE on the local router means the full end-to-end path is healthy — always verify from both ends
• Confusing point-to-point and multipoint sub-interface behavior, especially around addressing (separate subnets vs. shared subnet)

Troubleshooting Checklist

1. show frame-relay pvc — confirm PVC status is ACTIVE, not INACTIVE or DELETED
2. show frame-relay lmi — confirm LMI exchanges are happening without errors/timeouts
3. show frame-relay map — confirm DLCI-to-IP mappings are correct (especially with Inverse ARP)
4. show interfaces serial0/0/0 — confirm physical layer and line protocol are up
5. Ping between endpoints, then check routing tables (show ip route) if reachability fails despite an active PVC

Performance Tuning

• Monitor FECN/BECN counters in show frame-relay pvc output — sustained congestion notifications indicate the PVC is exceeding its committed rate and may need a CIR increase from the provider
• Use traffic shaping (frame-relay traffic-shaping plus a defined map-class) to smooth bursts and avoid excessive discard-eligible (DE) marking by the provider
• For latency-sensitive traffic (voice, in legacy deployments), configure Frame Relay fragmentation (FRF.12) alongside traffic shaping to avoid large data frames delaying smaller voice frames

FAQs

Is Frame Relay still used in modern networks? Rarely for new deployments — most providers have migrated to MPLS or Ethernet-based services — but it still appears in legacy environments and remains a core certification topic.

What’s the difference between a PVC and an SVC in Frame Relay? A PVC (Permanent Virtual Circuit) is provider-provisioned and always available; an SVC (Switched Virtual Circuit) is established on-demand, similar to a phone call, though SVCs saw far less real-world deployment.

Why do I need sub-interfaces instead of just using the physical interface? Sub-interfaces avoid split-horizon issues in hub-and-spoke topologies with distance-vector routing protocols, since each sub-interface is treated as a distinct interface for routing purposes.

What does Inverse ARP do in Frame Relay? It dynamically resolves the remote IP address associated with a given DLCI, eliminating the need for manual frame-relay map statements in straightforward deployments.

Summary

Frame Relay’s core ideas — DLCIs, PVCs, LMI signaling, and Inverse ARP — are worth understanding thoroughly even though the technology itself is fading from new deployments. The most important design decision is sub-interface type: point-to-point sub-interfaces cleanly solve hub-and-spoke split-horizon problems and remain the recommended approach for any multi-spoke Frame Relay topology. When troubleshooting, always check both PVC status and LMI health, and remember that an “active” PVC locally doesn’t guarantee the far end is equally healthy.

References

• Cisco: Frame Relay Configuration Guide
• Cisco IOS Wide-Area Networking Configuration Guide