Frame Relay

CCIE Sep 24, 2011

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

- Requires L2-L3 mapping, either inverseArp or static mapping
interface serial0/0.1 multipoint frame relay interf-dlci
### Hub-and-spoke

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

Tags

Rob Edwards

Northern (UK) chap focusing on platforms, automation, cloud and cloud native applications. Recovering network engineer, although it turns out networking is as important, if not more, now than before!

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.