My journey to CCIE RS — Frame relay
Hi friends. We are here again to continue the series of texts with my notes from years of study until the CCIE RS years ago. As I said, there are almost 400 pages of notes with information that I consider important when working with Routing and Switching. Today, the technology is no longer used, but I’ll post anyway: Frame Relay :)
I believe this information can help not only with certification exams, but the day-to-day life of others (like me) when dealing with Cisco infrastructure.
For those who have not read the first articles, follow the links for “Switching-1”, “Switching-2”, “PPP”. Below is the part about “Frame Relay”.
Feel free to comment and contact me on LinkedIn. If you liked the content, I encourage you to share it with others in yours groups. Don’t forget to follow TechRebels and me by clicking “follow” :)
Frame Relay
Frame Relay (or “frelay” to make it easier) is not common nowadays, because it has been replaced by faster technologies. Even ISPs that still offer frelay only deploy it at the customers edge, maintaining the core with MPLS VPN.
Broadcast Media
- Ethernet, Token-ring, FDDI
- Support native broadcast
- Facilitates L3-> L2 resolution
Non-Broadcast Multi Access Media
- Frame relay, ISDN, ATM, etc
- Source cannot address all connected destinations simultaneously.
- L2 Broadcast is send as replicated L2 unicast (known as “pseudo-broadcast”).
- It implies resolution problems L3-> L2.
L3-> L2 Resolution
Broadcast: L3 resolution is required to link remote L2 addresses to L3 addresses. (we know L3 but we don’t know L2)
Non-broadcast: The problem is the opposite of broadcast. L3 resolution is required to link remote or local L2 address with remote L3. (we know L2 but we don’t know L3)
Frelay needs to resolve remote L3 addresses to local L2 address. Inverse ARP (as opposed to ARP) performs this process only for directly connected devices. The other option is explicitly declared resolution (frelay map).
NOTE: Because only directly connected devices can be resolved, this implies additional partial mesh NBMA network resolution issues.
Multipoint Interface
- Can have multiple L2 addresses at the same time
- Therefore requires L3-> L2 resolution
- “Main interface” or “multipoint subinterface”
Point-to-Point Interface
- Can only have one L2 address
- So, no resolution needed
- In NBMA case, only P2P subinterfaces
Data Link Connection Identifier (DLCI) is the L2 address and is of local importance (between router and Frelay SW ) for directly connected neighbors.
Local Management Interface (LMI) is the signaling protocol used to report DTE status to the ISP network.
NOTE: LMI type is automatically detected when enabling Frelay. The Frelay interface only stays UP / UP if it receives LMI and agrees to the LMI type.
LMI tells you which circuits are bound to an interface and what the individual status of each circuit is end-to-end.
Status:
- Active — ok end-to-end (usually)
- Inactive — configuration ok, but there is some path failure
- Deleted — Router config is not compatible with SW Frelay config (usually wrongly configured DLCI on one side).
- Static — LMI is disabled (usually used for back-to-back Frelay).
NOTE: Inverse ARP does not support IPV6 (in fact IPV6 does not support InARP), so IPV6 over multipoint frelay interface needs to be explicitly mapped.
InARP request can be disabled per interface.
InARP reply cannot be disabled.
Static mapping overwrites dynamic mapping, disabling InARP for that specific circuit (InARP continues to operate for other circuits). Again, do not disable InARP replies.
Auto Install via Frelay
Auto-install is used to automatically load a config to a new router.
If no config is detected, the router detects the interface encapsulation and sends an addressing request.
Once this address is bound, the router attempts to load the config via TFTP.
LAN (DHCP), HDLC (SLARP), Frelay (BOOTP).
NOTE: If the Frelay address request fails, the router installs a mapping to 0.0.0.0 (NULL address). This mapping to 0.0.0.0 can cause major routing protocol failures, especially between routers that should not be in the same L2 domain. Failures may include leaks in the routing and multicast process. First thing to do in this situation is to save the config and restart (as there is config, auto-install will not occur).
Point-to-point interfaces are the ideal design for troubleshooting NBMA-related L3 problems (such as OSPF and Multicast over Frame relay).
NOTE: Because the interface type and resolution is only locally significant, any combination of frelay interfaces is supported.
Partial Mesh
This is when all devices don’t have a circuit for everyone else.
Design problems occur when the L3 network is not mapped exactly to the L2 network. Usually:
- Devices not directly connected cannot resolve through InARP.
- Some higher layer protocols do not understand Partial Mesh’s lack of connectivity (eg OSPF, PIM, etc.).
Ideal scenario in Frelay is to use P2P subinterfaces with separate IPV4 / IPV6 subnets for each.
In frelay, both the interface type and L3 -> L2 resolution are locally significant to the router.
Main interface DLCIs are moved to subinterfaces via the “frelay map” or “interface-dlci”. The difference between them is that interface-dlci does not perform L3 -> L2, it simply links the circuit to the interface. If the interface is multipoint, InARP requests are sent to each circuit.
InARP is enabled as soon as frelay encapsulation and IP address are configured. You need to disable InARP when there are unused DLCIs.
- <no inverse arp> configured on the physical interface is not passed to subinterfaces. Simultaneous use of interface and subinterface is not common but may occur (but it is very strange…).
To speed up, always set the Frelay interface to shut. If it is UP, InARP may take up to 1 minute to operate.
- NOTE: Another important point is that InARP can map the PVCs before we configure static mapping.
Obviously, the recommendation between static and dynamic is static, both in the lab (up to CCIE RS v4) and in real environment.
InARP is very unpredictable, so we should not mix dynamic with static mapping (especially in partial mesh environments).
InARP request can be disabled by interface or by circuit (InARP reply cannot be canceled). Another alternative is to move DLCIs to an interface without IP (can be any, usually a multipoint subinterface).
It is not very reliable to clear the mapping with <clear frelay inarp>. More certain is “shut / no shut”.
During lab, InARP should be the last choice:
- Point-to-point subinterfaces
- Multipoint Subinterfaces (gives you more control over DLCIs)
- Multipoint interface with static mapping
- Main interface with static mapping
- InARP (avoid as much as possible)
NOTE: If you set “frelay map” in an interface, “frelay dlci” will not make any difference.
NOTE: P2P interface mapping does not show IP (nor does it need to).
Ping your own IP address on a frelay mutipoint interface means nothing. To accomplish this, the router needs to have a mapping to the interface itself (interface circuit) and therefore the request and reply are sent through this circuit. The result when we ping our own address is that packets end up going to the neighbor twice and therefore takes twice as long. “If we can ping the peer, we can ping ourselves”
When sending Broadcast and Multicast packets on Frelay, the L3 address is not changed.
Each mapped circuit with <broadcast> parameter receives a copy of the broadcast / multicast. Therefore, <broadcast> is not configured in mapping to spokes to prevent the hub from receiving repeated traffic.
During pseudo-broadcast the router does not care about the IP address, only the <broadcast> parameter set in the circuits during the broadcast search (appears in the log).
NOTE: A trick is to configure a mapping with a nonexistent address with the broadcast parameter only.
If a mapping appears for 0.0.0.0 (bug, auto-install, etc.) this will cause problems. Ex: OSPF sends Hello broadcast and sets parity, but synchronization is unicast (0.0.0.0) and never complete; the adjacency timer expires… and starts all over…
- sh frame map = sh arp — show L2 bindings
Between spokes we can use:
- mapping L3 (spoke) — L2 (hub) — most common
- mapping L3 (spoke) — L3 (hub) — workaround with static route
- OSPF point-to-multipoint
NOTE: OSPF point-to-multipoint does not propagate the network itself, only /32.
Local Management Interface (LMI)
Frelay main interface remains UP / UP if it receives a LMI and agrees to the LMI type. (Can be automatically detected by enabling Frelay).
A P2P Frelay subinterface stays UP while receiving LMI and its DLCI is active. This is much better for routing protocols where there is no concept of adjacency such as RIP.
A Frelay multipoint subinterface stays UP while receiving LMI and any of its DLCI is active (caution).
NOTE: Frelay main interface always starts UP/UP and goes UP/DOWN when the keepalive interval (LMI timeout) expires.
NOTE: All packets originating from or intended for the router are processed in software (process switch) while all packets that cross the router are hardware switched (CEF switching). Therefore to use <debug ip packets> or <debug frelay packets> CEF must be disabled.
- debug frelay events — InARP process
- debug frelay packets — all IN and OUT packages
- — show useful information about the protocol stack
- — 0x8000 is the IP stack
- — 0x806 is InARP
NOTE: In Partial mesh, the frelay hub can generate an ICMP-redirect for each packet it receives because it believes the spokes are also directly connected (huge bandwidth loss).
NOTE: In frelay, always test unicast, broadcast and multicast se-pa-ra-te-ly.
Frame Relay Switching
- frelay switching
- (if) frelay inf-type -> enables LMI process
- (if) frelay route X int Y Z
- (if) frelay route Z int W X
OR
- connect R1_TO_R2 int X A int Y B
NOTE: obviously using “frelay route” and “connect” commands at the same time generates error.
Back-to-back Frame Relay
It can be used for direct serial connections instead of PPP or HDLC although there is no advantage on doing so.
In this scenario there is no SW frelay, so no LMI is generated and it is necessary to disable LMI (no keepalive) by making the circuit static.
If LMI is not disabled, the circuit remains DELETED because it sends a request but does not receive a reply and in this case the router understands that the value is incorrect..
NOTE: Basically the only difference in config is disabling LMI.
NOTE: Both interfaces must agree with PVC as it is “link significant”.
Frame Relay End-to-End Keepalive (EEK)
By default, end-to-end LMI is used to track circuit status. If one side is DOWN for any reason, the other remains INACTIVE.
Some scenarios break the operation of end-to-end LMI:
- when we use frame relay over MPLS L2VPN
- when transitioning between different ISPs, they usually do not change the LMI status
EEK operates directly between DTE devices because the goal is to no longer rely on LMI. Therefore it must be configured on both neighbors, or else the circuit remains DOWN.
EEK is set through “map-class” (not to be confused with “class-map”). Map-class is an old form of frelay configuration that allows you to configure EEK, frelay shapping, pattern compression, DE bit, etc.
It can be implemented in 2 ways:
- class applied on specific DLCI
- — <frame-relay interface-dlci X>
- — — <class CLASS>
- class applied on the interface, where all circuits inherit the config
- — NOTE: This method is bad when we want to change part of the circuits.
- <show frelay pvc> — show EEK status for all active circuits where EEK is applied.
Frelay supports L2 fragmentation, usually used for QoS. Ethernet does not support this and needs to do it in L3 (PPPoE).
NOTE: When the prompt returns to a higher prompt, it is because the command is in a higher mode and not the current mode. So beware, especially on classes in DLCIs, subinterfaces and main interfaces because you may change what you don’t want to.
DOC — Frame relay: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/wan_frly/configuration/15-mt/wan-frly-15-mt-book.html
What do you think about this content?
Did it miss any important points?
Tell me in the comment section.
If you like this content, please share. Don’t forget to follow me and TechRebels by clicking “follow” down below :)
About the author:
Giuliano Barros is Network Consultant & Founder of Control Plane — Network Services.
Gratuated in Computer Science, CCIE certified by Cisco Systems and work for 15 years with projects for medium and big size companies.