Frame relay is;

  • High Performance WAN protocol
  • Layer 2
  • Originally designed for use in ISDN links but now for a variety of others
  • Packet Switched

Types of Frame Relay

Point-to-point;

  • L2-L3 mapping not required as only one DLCI is allowed on P2P interface
  • Broadcast capability is automatically enabled
  • interface serial0/0.1 point-to-point

Physical or Multipoint

Authentication

username R2 password 0 cisco123 interface se0/0.1 frame-relay interface-dlci 101 ppp virtual-template 1 interface virtual-template 1 ip addr 10.1.1.1 255.255.255.0 ppp authentication chap callin ppp chap hostname R1 ppp pap sent-username R1 password 0 cisco123 ppp auth pap callin

 

debug ppp authentication

FREEK

Routers depend on LMI to maintain the status of active connections

  • intermediate switches in the cloud may not support NNI LMI’s
  • FREEK can be used to provide the local router with the status
  • keepalives run on the data DLCI (16 – 997) and not the LMI DLCI
  • FREEK maintains two internal keepalives
  1. used to send out keepalive requests and handle responses to the request
  2. handle the rely to the requests; this is considered the receive side

map-class frame-relay FREEK frame-relay end-to-end keepalive mode [bidirectional|request|reply] frame-relay end-to-end keepalive [send|receive] error-threshold frame-relay end-to-end keepalive [send|receive] success-events frame-relay end-to-end keepalive event-window interface se0/0.1 frame interface-dlci 101 class FREEK

 

show frame-relay end-to-end keepalive interface se0/0.1

 

debug frame-relay end-to-end keepalive event

interface multilink 12 ip addr 10.1.1.1 255.255.255.0 ppp multilink links max 2 ppp multilink links min 1 ppp multilink group 1 interface virtual-template 1 ppp multilink group 1

Two options exist;

interface se0/0 frame-relay traffic-shaping interface se0/0.1 multipoint frame-relay interface-dlci 102 ppp virtual-template 1 frame-relay interface-dlci 103 ppp virtual-template 1

OR

interface se0/0 frame-relay traffic-shaping frame-relay interface-dlci 201 ppp virtual-template 1 interface se0/1 frame-relay interface-dlci 203 ppp virtual-template 1

show ppp multilink

Back-to-Back

interface se0/0 ip addr 10.1.1.1 255.255.255.0 no keepalive #disables LMI’s clock rate 64000 # on DCE side (use ‘sh controller s0/0’ to find end) frame-map ip 20.1.1.1 113 # FR mapping done statically

Challenges

Ensure routers in hub & spoke have full reachability with each other without configuring ‘frame-relay map’?

Configure PPP on the DLCI as when PPP is configured a host route is injected into the routing table thus providing NLRI to the next hop.

!Router 1 interface se0/0 frame-relay interface-dlci 101 ppp virtual-template 1 frame-relay interface-dlci 102 ppp virtual-template 1 interface virtual-template 1 ip addr 10.1.1.1 255.255.255.0 !Router 2 interface se0/0 frame-relay interface-dlci 201 ppp virtual-template 3 interface virtual-template 3 ip addr 10.1.1.2 25.255.255.0

The host route is injected by IPCP due to the routers PPP communication.

  • next hop via the virtual-template
  • as VC configured as P2P (because of PPP) any packet the local router puts on the virtual-template is received by one and ONLY one router on the other side of the DCLI

Challenge 2

How do you ensure full reachability but NOT use ‘frame-relay map’ or static/dynamic routing?

In challenge 1 with PPP IPCP craetes a host route however this behaviour can be disabled with;

no peer neighbour-route

Due to this behaviour in PPP the hub should still have connectivity to every spoke.

!Router 1 interface se0/0 frame-relay interface-dlci 101 ppp virtual-template 1 frame-relay interface-dlci 102 ppp virtual-template 1 interface virtual-template 1 ip unnumbered l0 no peer neighbour-rate !Router 2 interface se0/0 frame-relay interface-dlci 201 ppp virtual-template 2 interface virtual-template 2 ip unnumbered l0 no peer neighbour-rate

ip local policy route-map ROB route-map ROB permit 10 set ip next-hop 10.1.1.1 route-map ROB permit 90

debug ip policy