Page 5 of 63
By Krzysztof Zaleski, CCIE #24081. This Booklet is available for free and can be freely distributed in a form as is. Selling is prohibited.
Frame-Relay
LMI
Fragmentation
Status Enquiry: DTE->FR Switch; Status: FR Switch->DTE
Type-1 – keepalive (10 sec) 3 misses, LMI is down
Enabled by keepalive command on interface
Type-0 - Full Status, every 6th message
(IF) frame-relay lmi-type <type>
cisco: DLCI 16-1007 (LMI-1023)
ansi: Anex D, DLCI 16-991 (LMI-0)
q933a: ITU Anex A, DLCI 16-991 (LMI-0)
Header
LAPF header – Link Access Procedure for Frame-Relay
Encap.
encapsulation frame-relay ietf
(IF) frame-relay map dlci ... ietf
(IF) frame-relay interface-dlci <#> ietf
Any DLCI announced by LMI, not associated with subintf are assumed to be associated with physical intf
Legacy – requires shaping with
dual FIFO for interleaving
map-class frame-relay <name>
frame-relay fragment-size <#>
Must be added on both sides, as 2
bytes fragmentation header is added
Fragmentation configured directly on
interface with no FRTS (>12.2.13T)
frame-relay fragment <#>
IOS automaticaly creates dual FIFO
MLPPP required for FRF.8 FR-to-ATM interworking
show frame-relay fragment
Types
Point-to-point
Physical Or
Multipoint
L2-to-L3 mapping not required, as only one DLCI is allowed on p2p intf.
interface serial0/0.1 point-to-point
Broadcast capability is automaticaly enabled
interface serial0/0.1 multipoint
frame-relay interf-dlci <id>
Inverse-arp is enabled only on that DLCI
Requires L2-to-L3 mapping, either via inverse-arp or by static mapping
Hub-and-spoke
Spokes can talk to each other only via Hub. When static mapping is enabled on
spoke for hub and other spoke, only mapping for Hub needs broadcast keyword
When inarp is used, it can map DLCI-to-IP only from spokes to hub. InARP is not passed
through hub router, so for spokes to communicate separate static mapping is required
End-to-end
Keepalive
(EEK)
map-class frame-relay <name>
frame-relay end-to-end keepalive mode {reply | request | bidir}
frame-relay end-to-end keepalive timer {recv | send} <sec>
frame-relay end-to-end keepalive event-window {recv | send} <#>
frame-relay end-to-end keepalive error-threshold {recv | send} <#>
frame-relay end-to-end keepalive success-events {recv | send} <#>
PPPoFR
Virtual-access interface is created after virtual-template is bound to DLCI. As this interface
is p2p then no L2-to-L3 mapping is required even if used on physical multipoint interface
interface serial0/0
frame-relay interface-dlci <dlci> ppp virtual-template <id>
interface virtual-template <id>
ip address <ip> <mask> | ip unnumbered loopback0
Remote peer’s /32 IP is shown in routing table as connected (PPP behaviour)
Bridging
bridge <id> protocol ieee
interface <intf>
bridge-group <id>
frame-relay map bridge <dlci> broadcast
Static mapping is required on multipoint interfaces
InARP
LMI triggers InARP. If LMI is disabled, InARP will not work
clear frame-relay inarp
P2P interfaces ignore InARP messages as they only have one DLCI so they know L2 mapping
InARP flows only across VC, it is not forwarder by routers. IP is required on intf to send InARP
frame-relay map ip <remote-ip> <dlci> [broadcast]
You may also need mapping for local IP to be able to ping it (L2->L3 mapping is also required for own IP)
no frame-relay inverse-arp ip <dlci>
Not only stops sending mapping on that DLCI, but also ignores
InARP by default supports Broadcast capability and is generated only by physical interface
no frame-relay inverse-arp
InARP is disabled when subintf are created, so this command is not required on physical intf
frame-relay interface-dlci <dlci> - Re-enables InARP for that particular DLCI
Back2Back
Router A:
frame-relay map ip <ip> 102 (encapsulate)
frame-relay interface-dlci 201 (expect)
1) The same DLCI on both sides
Disable LMI (no keepalive)
2) If DLCIs are to be
different on both sides
Router B:
frame-relay map ip <ip> 201 (encapsulate)
frame-relay interface-dlci 102 (expect)
3) Frame-relay switching
Router A:
frame-relay switching
frame-relay intf-type dce
frame-relay map ip <ip> 102
frame-relay interface-dlci 201
If keepalive is rcvd within defined timers, success-event is logged. Otherwise, error-event is logged.
To bring up intf, 3 successes in a row must appear. To bring down, any 3 events within event-window
keepalive must be enabled on both sides
(IF) frame-relay lmi-n391dte <count> - full status (type 0) messages frequency (default every 6 cycles)
On multipoint interface each DLCI must be assigned to the same virtual-template interface because all
endpoints must be in the same subnet. Separate virtual-access interface will be created for each DLCI
interface multilink <ML-id>
ppp multilink
ppp multilink group <ML-id>
interface virtual-template <VT-id>
ppp multilink group <ML-id>
Fragment size = delay * BW
Router A and B:
frame-relay interface-dlci 101
DLCI – 10 bits (0-1023) – identifier local to each interface
EA – Extended address – up to 2 additional bytes of header
FECN – Forward Explicit Congestion Notification – set toward receiver
BECN – Backward Explicit Congestion Notification – set toward sender
DE – Discard Eligible – frame may be dropped by the FR switch
Default FR encapsulation is CISCO
Congestion control
Broadcast Queue
Managed independently of the normal interface queue
STP and BPDUs are not transmitted using the broadcast queue
(IF) frame-relay broadcast-queue <size> <Bps> <packet-rate>
DLCI C/R EA
12345678
DLCI FECN BECN DE EA
Can be used to emulate p2p link on multipoint interface or to enable LFI on FRF.8 links (FR to ATM interworking)
X X X
X X X
Event window
Intf goes up
Intf goes down
FR Autoinstall
Router being configured will send BOOTP request for IP address over FR
Staging router must have FR map configured
fram-relay map ip <remote IP> <DLCI> broadcast (NBMA)
frame-relay interface-dlci <dlci> protocol ip <ip> (P2P)
Helper-address on staging router is required if configured router needs to upload config
via TFTP. Router with TFTP server should have directed-broadcast enabled on Ethernet