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
- 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
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
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
- used to send out keepalive requests and handle responses to the request
- 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
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
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 18.104.22.168 113 # FR mapping done statically
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 22.214.171.124
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
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