Skip to Content

Frame Relay for the R&S CCIE Candidate - Session Notes

Attended the Frame Relay Session for R&S CCIE Candidates Wednesday morning. The instructor, Johnny Bass, is fast becoming one of my favorite teachers of CCIE material. His no-BS straight to the point style is great for covering CCIE material. Like yesterday’s IPv6 session, I jotted some notes and wanted to share them here.

Key points about LMI
Three types of LMI –
Gang of four, then ANSI (T1.617 Annex D, and then ITU (Q.933 Annex A)
LMI type needs to match Frame relay switch

Virtual Circuits
    Switched Virtual Circuits (SVC) – temporary, like a phone call. Setup then torn down
    Permanent Virtual Circuits (PVC) – nailed up, appears like a permananent connection

Layer 3 to layer 2 mapping

  • In Ethernet, we have ARP (IPv4)
  • In Frame Relay, we have Inverse ARP or static mappings (IPv4)
  • In IPv6, we have static mappings

Configuring Frame Relay with IPv4

Physical interface

Interface Serial0/0/0 
encapsulation frame-relay 
ip address 1.1.5.1 255.255.255.0 
no shutdown

Multi-point sub-interfaces

Interface Serial0/0/0.123 multipoint 
ip address 1.1.1.1 255.255.255.0 
frame-relay map ip 1.1.1.2 102 broadcast 
frame-relay map ip 1.1.1.3 103 broadcast

Point-to-point sub-interfaces

Interface Serial0/0/0.14 point-to-point 
ip address 1.1.4.1 255.255.255.0 frame-relay 
interface-dlci 104

Frame Relay for IPv6
In the lab, they might tell you what the Link Local address may be, OR they may tell you it has to be EUI-64. If they don’t tell you, then statically assign easy to use addresses (Interface Address is ::1 or ::2) – Sample Configs below:

Physical interface

Interface Serial0/0/0 encapsulation frame-relay 
ipv6 address 2005:5:dead:beef::1/64 
ipv6 address fe80::1 link-local frame-relay map 
ipv6 2005:0:dead:beef::2 102 frame-relay map 
ipv6 fe80::2 102 broadcast

Multi-point sub-interfaces

Interface Serial0/0/0.123 multipoint 
ipv6 address 2005:123:dead:beef::1/64 
ipv6 address fe80::1 link-local frame-relay map 
ipv6 2005:123:dead:beef::2 102 frame-relay map 
ipv6 fe80::2 102 broadcast frame-relay map 
ipv6 2005:123:dead:beef::3 103 frame-relay map 
ipv6 fe80::3 103 broadcast

Point-to-point sub-interfaces

Interface Serial0/0/0.14 point-to-point 
ipv6 address 2005:14:dead:beef::1/64 
frame-relay interface-dlci 104


Note: In the test, they aren’t looking for configurations, they’re looking for end results. If they say “no dynamic maps” and you use dynamic maps, you just lost points.


Broadcast across Frame Relay

For IPv6, only one of the frame relay mappings need the broadcast keyword. You can put it on more than one, but it just duplicates the amount of needed traffic. Also, it doesn’t matter if it’s on the link local address mapping or not, it can be on any of them.

Note: One frame map needs the broadcast keyword per protocol, per pvc

Example:

Interface Serial0/0/0.123 multipoint 
ip address 172.16.123.2 255.255.255.0 
frame-relay map ip 172.16.123.1 201 broadcast 
frame-relay map ip 172.16.123.3 201 
frame-relay map ip 172.16.123.2 201


Frame Relay advanced topics (CCIE twists)

Example of how complex it can get, you have to reconfigure an HDLC T1 to be back to back frame relay (no LMI), then you need to run PPP with CHAP authentication on top of that. Some additional examples are:

  • To Control Inverse ARP, use:
    • no frame-relay inverse-arp [protocol] [dlci | vc-bundle vc-bundle-name]
  • Hub & spoke considerations
    • Spoke to spoke reachability
    • Local reachability
  • Frame relay traffic shaping
    • Map classes
    • MQC
  • Discard Eligible Lists
  • PVC Bundling
  • Multilink frame relay
  • Frame relay fragmentation and compression


Back to Back Frame Relay Configuration Example

Just turn off keepalives
    

Interfacee Serial0/0/1
ip address 172.16.45.4 255.255.255.0
encapsulation frame-relay
no keepalive
clock rate 2000000
frame-relay map ip 17R24.16.45.4 45 S0/0/1
frame-relay map ip 172.16.45.5 45 broadcast



PPP Over Frame Relay Configuration Example

interface Serial0/0/0.123
ip address 172.16.123.1 255.255.255.0
encapsulation frame-relay
frame-relay map ip 172.16.123.1 102
frame-relay map ip 172.16.123.2 102 broadcast
frame-relay interface-dlci 103 ppp Virtual-Template1
interface Virtual-Template1
ip unnumbered Serial0/0/0.123


Note
: There is no “encapsulation ppp” command under a virtual-template interface because it’s always ppp. If you type in the command, it wont show up.


PPP Over Frame Relay with Fragmentation Example

interface Serial0/0/0.123 
ip address 172.16.123.1 255.255.255.0 
encapsulation frame-relay 
frame-relay map ip 172.16.123.1 102 
frame-relay map ip 172.16.123.2 102 broadcast 
frame-relay interface-dlci 103 ppp Virtual-Template1
interface Virtual-Template1 bandwidth 128 ip unnumbered Serial0/0/0.123 ppp multilink ppp multilink fragment delay 10


Frame Relay Traffic Shaping

If you get a section on that lab that states: "CIR is X", you have to configure Traffic Shaping

  • Should you use FRTS or MQC?
    • Look for key words
      • No map classes = use MQC
      • No policy maps = use FRTS
      • Set DSCP/IP Precedence bits along with CIR = use MQC


Multi-link Frame Relay Configuration Example

interface  MFR1     
ip  address 172.16.45.4 255.255.255.0     
frame-­relay interface­dlci 405   
!   
interface  Serial0/0/0     
 no  ip  address     
 encapsulation frame­relay MFR1
interface  Serial0/0/1     
 no  ip  address     
 encapsulation  frame-­relay MFR1


Frame Relay Troubleshooting Commands

  • Troubleshoot Frame Relay issues from the local router
    • Check that PVC status is Active - Show frame-relay pvc
    • Check LMI messages - Show frame-relay lmi or show interface
    • Check for encapsulation issues - Debug frame-relay packets
  • Troubleshoot same-subnet connectivity over Frame Relay
    • Make sure PVCs are associated with the correct interface - Show frame-relay pvc
    • Check for address to unicast mappings - Show frame-relay map
  • Troubleshoot routing protocol operation over Frame Relay
    • Pay close attention to issues related to hub-and-spoke topologies

 

Your rating: None Average: 4.8 (5 votes)

Comments

Cisco Geek's picture

Isn't is about time for Frame-Relay to pass away

It's real place nowadays is within the history pages...

I agree, this is a dying

I agree, this is a dying technology however it is still widely deployed. It will be around for some time. With the need for low latency for VoIP and Video frame relay just doesnt cut it. But if you think about the people not running these platforms in their environment there is no need to spend the extra money on a MPLS solution.

Adam's picture

Agreed, but it's on the

Agreed, but it's on the blueprint, so we still gotta know it.



blog | by Dr. Radut