Frame-Relay
Multiprotocol Interconnect over Frame-Relay is defined in RFC 2427.
PPP over Frame Relay is defined in RFC 1973.
FECN/BECN
- FECN (Forward Explicit Congestion Notification)
- If set to 1, it indicates that congestion was experienced in the direction of the frame transmission, so the destination is informed of that congestion.
- BECN (Backwards Explicit Congestion Notification)
- If set to 1, it indicates that congestion was experienced in the direction opposite of the frame transmission, so the source is informed of that congestion.
DE
If set to 1 by a DTE device, it indicates that the frame has lower importance than other frames, so when the network becomes congested, DCE devices can discard this frame before discarding other frames that do not have the DE bit set.
LMI
LMI VC status messages provide communication and synchronization between Frame Relay DTE and DCE devices, aka reporting on the status of PVCs.
It's enabled by default in all Frame-Relay interfaces and it's type (Cisco, ANSI, Q933a) is automatically detected.
Use keepalives to track PVC status end-to-end if multiple frame-relay providers are in between end-points.
IOS
interface Serial2/0
encapsulation frame-relay
frame-relay interface-dlci 100
class FR-MAPCLASS
!
map-class frame-relay FR-MAPCLASS
frame-relay end-to-end keepalive mode bidirectional
CRC
Frame Relay uses cyclic redundancy check (CRC) as an error-checking mechanism. No error correction takes place.
Frame-Relay Switching
Routers can be configured as Frame Relay switches (frames from a PVC arriving on an incoming interface are switched to another PVC on an outgoing interface, so the incoming DLCI in the arriving frames is replaced by an outgoing DLCI). It applies only to physical interfaces.
IOS
frame-relay switching
!
interface Serial2/0
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
frame-relay route 200 interface Serial2/1 201
!
interface Serial2/1
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
frame-relay route 201 interface Serial2/0 200
Don't forget to always define one interface (the one providing the clock) of each link as DCE and set the clock rate.
"frame-relay switching" might also be required in case of AToM. You should get AToM working without frame-relay switching, but after you reload the router you may get a message "Must enable frame-relay switching to configure DCE/NNI" while the bootloader is running.
"no keepalive" must be configured in real networks, GNS3 can work without it.
Address Resolution
- IPv4
- Inverse ARP
- Static mapping
- IPv6
- Static mapping
Inverse ARP
- "no frame-relay inverse-arp" disables only the request, replies are always sent
- IPv6 does not use inverse ARP
- point-to-point sub-interfaces do not use inverse ARP
- only directly connected devices can be resolved with inverse ARP (hub-n-spoke is an issue)
- if there is a static map for a protocol for a PVC, inverse ARP is disabled for that PVC
- dynamic mappings created by inverse ARP are overwritten by static mappings
- use "clear frame-relay inarp" to clear the dynamic mappings (sometimes shut/no-shut or a reload might be needed)
Inverse ARP should be avoided when told to:
- not use dynamic maps
- not use unnecessary PVCs
- not use undefined PVCs
- use only specific PVCs
map vs interface-dlci
- Frame-Relay "map" command is used on
- multipoint subinterfaces
- physical interfaces without inverse-arp
- physical interfaces with IPv6
- Frame-Relay "interface-dlci" command is used on
- point-to-point subinterfaces
- multipoint subinterfaces with inverse-arp
- ppp over frame-relay
- interfaces with map-class required
Most IPv6 routing protocols use Link Local addresses for next hop and neighboring, so these need to be mapped too, like the Global Unicast addresses. Always define manually the IPv6 Link Local Address on each interface if you plan to use it in a map statement.
In case of hub-n-spoke scenarios, OSPF adjacencies cannot be established between spokes due to TTL=1.
When a multipoint subinterface is created on a physical interface, all the DLCIs are always assigned to the physical interface, until they are specifically assigned to the subinterfaces.
Always prefer to use point-to-point subinterfaces.
Configurations (IOS)
Physical Interface (IPv4)
interface Se0/0
encapsulation frame-relay
ip address 10.10.10.10 255.255.255.0
frame-relay map ip 10.10.10.11 100 broadcast
"frame-relay map" is need if DLCIs aren't provided by a frame-relay switch.
Physical Interface (IPv6)
interface Se0/0
encapsulation frame-relay
ipv6 address 2001::10:10:10:1/64
ipv6 address fe80::1 link-local
frame-relay map ipv6 2001::10:10:10:2/64 100 broadcast
frame-relay map ipv6 fe80::2 100 broadcast
Mapping is required for both LLAs and GUAs in IPv6.
Point-to-Point Subinterface (IPv4)
interface Se0/0.1 point-to-point
ip address 10.10.10.1 255.255.255.0
frame-relay interface-dlci 101
Point-to-Point Subinterface (IPv6)
interface Se0/0.1 point-to-point
ipv6 address 2001::10:10:10:1/64
frame-relay interface-dlci 101
Multi-point Subinterface (IPv4)
interface Se0/0.1 multipoint
ip address 10.10.10.1 255.255.255.0
frame-relay map ip 10.10.10.2 102 broadcast
frame-relay map ip 10.10.10.3 103 broadcast
Multi-point Subinterface (IPv6)
interface Se0/0.1 multipoint
ipv6 address 2001::10:10:10:1/64
ipv6 address fe80::1 link-local
frame-relay map ipv6 2001::10:10:10:2/64 102 broadcast
frame-relay map ipv6 fe80::2 102 broadcast
frame-relay map ipv6 2001::10:10:10:3/64 103 broadcast
frame-relay map ipv6 fe80::3 103 broadcast
Configuration Examples
point-to-point on one side
IOS
interface POS2/0
encapsulation frame-relay
!
interface POS2/0.1 point-to-point
ip address 1.1.1.1 255.255.255.0
ipv6 address fe80::1 link-local
ipv6 address 2001:1:1:1::1/64
frame-relay interface-dlci 22
IOS-XR
interface POS2/0
encapsulation frame-relay
!
interface POS2/0.1 point-to-point
ipv4 address 1.1.1.1/24
ipv6 address fe80::1 link-local
ipv6 address 2001:1:1:1::1/64
pvc 22
physical interface on the other side
IOS
interface POS2/0
encapsulation frame-relay
ip address 1.1.2.2 255.255.255.0
ipv6 address 2001:1:1:1::2/64
frame-relay map ipv6 fe80::1 22 broadcast
frame-relay map ipv6 2001:1:1:1::1 22 broadcast
frame-relay map ip 1.1.1.1 22 broadcast
frame-relay intf-type dce
IOS-XR
not supported
PPP over Frame-Relay
Use this when you have frame-relay and you require authentication or other PPP specific characteristics.
DCE Router (IOS)
interface Serial2/0
encapsulation frame-relay
clock rate 64000
frame-relay interface-dlci 100 ppp Virtual-Template1
frame-relay intf-type dce
!
interface Virtual-Template1
ip address 1.1.1.1 255.255.255.0
DTE Router (IOS)
interface Serial0/0
encapsulation frame-relay
frame-relay interface-dlci 100 ppp Virtual-Template2
!
interface Virtual-Template2
ip address 1.1.1.2 255.255.255.0
Under the virtual-template you can configure whatever parameters are applicable to ppp in general.
You might have issues with POS interfaces and PPPoFR in GNS3. Try to use Serial interfaces instead.
Multilink Frame-Relay
R1 (IOS)
interface Serial2/0
encapsulation frame-relay MFR1
clock rate 64000
!
interface MFR1
ip address 12.12.12.2 255.255.255.0
frame-relay map ip 12.12.12.8 100 broadcast
frame-relay intf-type dce
R2 (IOS)
interface Serial0/0
encapsulation frame-relay MFR1
!
interface MFR1
ip address 12.12.12.8 255.255.255.0
frame-relay map ip 12.12.12.2 100 broadcast
IOS
R1#sh frame-relay multilink
Bundle: MFR1, State = up, class = A, fragmentation disabled
BID = MFR1
Bundle links:
Serial2/0, HW state = up, link state = Up, LID = Serial2/0
Frame-relay configuration is the usual one. You can also use MFR subinterfaces.
Hints
If you need somehow to differentiate traffic in a Serial/POS interfaces, then using frame-relay encapsulation on it, you can define subinterfaces based on DLCIs. Another (maybe more complex) solution would be to use multiple ppp virtual-templates.
No comments:
Post a Comment