Home > Articles > Network Technology > General Networking > Cisco Frame Relay Configurations

Cisco Frame Relay Configurations

Chapter Description

Jonathan Chin dicussess basic Frame Relay operations on Cisco routers in a router-based Frame Relay network. He also explains how to configure a basic frame relay network involving Cisco equipment and how to perform basic monitoring and troubleshooting using relevant Cisco IOS show and debug commands.

Configuring Static and Dynamic DLCI to Network Layer Address Mapping

Before a Frame Relay router or access server can transmit frames on its outgoing virtual circuit to a remote destination, it needs a vital piece of information. The router needs to understand the relationship between the specified next hop protocol address of the remote destination and the specific DLCI of a local outgoing virtual circuit. In other words, before a Cisco router is able to transmit data to a remote destination over Frame Relay, it needs to know which DLCI to use. Cisco routers support all network layer protocols over Frame Relay, such as IP, IPX, and AppleTalk. This address-to-DLCI mapping can be accomplished either by static or dynamic mapping. Dynamic and static mapping of the next hop protocol address to a specific local DLCI value is explained in this section.

Dynamic Mapping

Dynamic address mapping relies on the Frame Relay Inverse Address Resolution Protocol (Inverse ARP), defined by RFC 1293, to resolve a next hop network protocol address to a local DLCI value. The Frame Relay router sends out Inverse ARP requests on its Frame Relay PVC to discover the protocol address of the remote device connected to the Frame Relay network. The responses to the Inverse ARP requests are used to populate an address-to-DLCI mapping table on the Frame Relay router or access server. The router builds and maintains this address-to-DLCI mapping table, which contains all resolved Inverse ARP requests, including both dynamic and static mapping entries.

When data needs to be transmitted to a remote destination address, the router performs a lookup on its routing table to determine whether a route to that destination address exists and the next hop address or directly connected interface to use in order to reach that destination. Subsequently, the router consults its address-to-DLCI mapping table for the local DLCI that corresponds to the next hop address. Finally, the router places the frames targeted to the remote destination on its identified outgoing local DLCI.

On Cisco routers, dynamic Inverse ARP is enabled by default for all network layer protocols enabled on the physical interface. Packets are not sent out for network layer protocols that are not enabled on the physical interface. For example, no dynamic Inverse ARP resolution is performed for IPX if ipx routing is not enabled globally and there is no active IPX address assigned to the interface. Because dynamic Inverse ARP is enabled by default, no additional Cisco IOS command is required to enable it on an interface.

Example 4-16 shows the output of the show frame-relay map privileged EXEC mode command. The address-to-DLCI mapping table displays useful information. The output of the command shows that the next hop address 172.16.1.2 is dynamically mapped to the local DLCI 102, broadcast is enabled on the interface, and the interface's status is currently active.

NOTE

After enabling Frame Relay on the interface, the Cisco router does not perform Inverse ARP until IP routing is enabled on the router. By default, IP routing is enabled on a Cisco router. If IP routing has been turned off, enable IP routing with the ip routing command in the global configuration mode. After IP routing is enabled, the router performs Inverse ARP and begins populating the address-to-DLCI mapping table with resolved entries.

Example 4-16 Example of Dynamic Mapping

R1#show frame-relay map
Serial4/2 (up): ip 172.16.1.2 dlci 102(0x64,0x1840), dynamic,
       broadcast,, status defined, active

Inverse ARP can be disabled explicitly for a specific protocol and DLCI pair on the interface. Inverse ARP should be disabled for a specific protocol when it is known that the protocol is not supported on the remote end of the connection. Inverse ARP is disabled using the no form of the frame-relay inverse-arp interface configuration command. Example 4-17 shows how the no frame-relay inverse-arp configuration command is performed to disable dynamic Inverse ARP on the serial interface 4/2 on Router R1.

Example 4-17 Disabling Inverse ARP on an Interface

R1(config)#interface serial4/2
R1(config-if)#no frame-relay inverse-arp ?
 <cr>
 apollo   Apollo Domain
 appletalk AppleTalk
 bridge   Bridging
 decnet   DECnet
 interval  Set inarp time interval on an interface
 ip     IP
 ipx    Novell IPX
 pppoe   PPP over Ethernet
 qllc    qllc protocol
 vines   Banyan VINES
 xns    Xerox Network Services

R1(config-if)#no frame-relay inverse-arp ip ?
 <16-1007> Set DLCI for inverse ARP

R1(config-if)#no frame-relay inverse-arp ip 102

To enable Frame Relay Inverse ARP on a specified interface or subinterface if Inverse ARP has been previously disabled, use the frame-relay inverse-arp interface configuration command on the specified interface.

Suppose that the conditions of the network change, resulting in reassignment of DLCI or protocol layer addresses. The clear frame-relay inarp privileged EXEC mode command can be used to clear the address-to-DLCI mapping table of obsolete entries. This clear command flushes the dynamic mapping entries in the table and forces the router to resend dynamic Inverse ARP requests to its neighbors. The clear frame-relay inarp command clears all dynamic Inverse ARP entries on the router. Optionally, the granular clear frame-relay inarp interface command can be used to clear a group of dynamic mapping entries based on the interface number. The clear frame-relay inarp interface type/num dlci dlci_number clears the dynamic mapping entries associated with a specific DLCI.

Cisco routers also allow users to populate the Frame Relay map table with manually defined Inverse ARP entries. User-created Inverse ARP mapping is also known as static mapping. Static mapping is explained in the next section.

NOTE

The clear frame-relay inarp command flushes dynamic Inverse ARP mappings. It does not, however, flush static mapping entries in the table manually created by the user.

Static Mapping

With static mapping, the user can choose to override dynamic Inverse ARP mapping by supplying a manual static mapping for the next hop protocol address to a local DLCI. A static map works similarly to dynamic Inverse ARP by associating a specified next hop protocol address to a local Frame Relay DLCI.

For example, static address mapping should be used in situations when the router at the other side of the Frame Relay network does not support dynamic Inverse ARP for a specific network protocol. To provide accessibility, a static mapping is required to complete the remote network layer address to local DLCI resolution.

On a hub-and-spoke Frame Relay network, static address mapping should also be used on the spoke routers to provide spoke-to-spoke reachability. Because the spoke routers do not have direct connectivity with each other, dynamic Inverse ARP would not work between them. Dynamic Inverse ARP relies on the presence of a direct point-to-point connection between two ends. In this case, dynamic Inverse ARP only works between hub and spoke, and the spokes require static mapping to provide reachability to each other.

NOTE

When static mapping is configured on an interface for a protocol and a specific DLCI, the router automatically disables dynamic Inverse ARP for the protocol and the specific DLCI on the interface.

The frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco] configuration command in the interface or multipoint subinterface configuration mode is used to supply a static mapping of the specified next hop protocol address to a specified local DLCI.

Physical interface:

Multipoint subinterface:

The no form of the frame-relay map command removes the static mapping for the specific next hop protocol address and the specific local DLCI. Table 4-2 lists the supported protocols and the corresponding keywords for protocol in the frame-relay map command.

Table 4-2 Supported Protocols and Keywords for frame-relay map Command

Supported Protocols for frame-relay map Command

Keyword for protocol

IP

ip

DECnet

decent

AppleTalk

appletalk

XNS

xns

Novell IPX

ipx

VINES

vines

ISO CLNS

clns


NOTE

A Frame Relay point-to-point subinterface is connected to an end-to-end virtual circuit provisioned between two locations. Therefore, a point-to-point subinterface can only accept one DLCI and the next hop protocol address is automatically linked to the sole outgoing local DLCI. Hence, the frame-relay map command is applicable only to multipoint subinterfaces and physical interfaces (physical interfaces are multipoint interfaces by default).

To configure a static mapping of the next hop protocol address to a specified DLCI on a physical interface or a multipoint subinterface, follow the configuration steps listed below:

Step 1

Go into the interface or subinterface configuration mode of the interface on which you want to configuring static mapping.

Step 2

Configure the Frame Relay static mapping for the specified next hop protocol address and the specified local DLCI.

Step 3

(optional) Enter the broadcast keyword to allow the specified DLCI to forward broadcast and multicast packets. This can reduce the complexity of running dynamic routing protocols such as OSPF (which uses multicast updates) over Frame Relay.

Step 4

(optional) Use the cisco or ietf keyword to specify the Frame Relay encapsulation to be used on the specified DLCI. Frame Relay encapsulation can be configured on a per-DLCI basis.


Example 4-18 shows a sample configuration of static mapping configured on the physical serial interface 3/0 of Router R2.

Example 4-18 Configuring Static Mapping

R2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#interface serial3/0
R2(config-if)#frame-relay map ip 172.16.1.1 201 broadcast cisco

R2#show running-config
<output omitted>

interface Serial3/0
 ip address 172.16.1.2 255.255.255.0
 encapsulation frame-relay
frame-relay map ip 172.16.1.1 201 broadcast cisco

<output omitted>

R2#show frame-relay map
Serial3/0 (up): ip 172.16.1.1 dlci 201(0xC8,0x3080), static,
       broadcast,
       CISCO, status defined, active

Referring to Example 4-18, the contents of the show output on router R2 indicate that the static address mapping is performed on interface serial 3/0 and the Frame Relay encapsulation used on the DLCI 200 is CISCO. As seen in the configuration steps, static mapping of the address using the frame-relay map command allows users to select the type of Frame Relay encapsulation used on a per-VC basis.

It was mentioned in an earlier section that static mapping using the frame-relay map command is important on partially meshed networks. The partially meshed Frame Relay network shown in Figure 4-2 is used to demonstrate when static mapping is required. In Figure 4-2, the spoke routers, R1 and R2, are using dynamic Inverse ARP between themselves and the hub router R3. Static mapping is used between a spoke router and its remote spoke router.

For example, the spoke router R1 uses static mapping to reach router R2 at 172.16.1.2 because there is no direct connectivity between them on the partially meshed network to use dynamic Inverse ARP. Because R1 and R3 are directly connected by a VC, they can rely on dynamic mapping to resolve the next hop protocol address via dynamic Inverse ARP. The same applies between router R2 and hub router R3. On router R1 and R2, static mapping needs to be used to instruct R1 to reach R2 via its local DLCI 103 and for R2 to reach R1 via its local DLCI 203.

Figure 2Figure 4-2 Using Static Mappings on a Partially Meshed Network

The configuration file and the show frame-relay map command output of router R2 are shown in Example 4-19. After the static and dynamic mappings are resolved in the show frame-relay map table, R2 has complete connectivity to both the hub router and the remote spoke router. The configurations and the show frame-relay map output of router R1 will be similar to that of router R2.

Example 4-19 Static and Dynamic Mapping Under the Same Interface

R2#show running-config
Building configuration...
<output omitted>

interface Serial3/0
 ip address 172.16.1.2 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 172.16.1.1 203 broadcast

<output omitted>

R2#show frame-relay map
Serial3/0 (up): ip 172.16.1.3 dlci 203(0x64,0x1840), dynamic,
       broadcast,, status defined, active
Serial3/0 (up): ip 172.16.1.1 dlci 203(0x64,0x1840), static,
       broadcast,
CISCO, status defined, active

R2#ping 172.16.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
R2#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/114/120 ms
R2#

Although using a combination of both static mapping and dynamic Inverse ARP on a spoke router resolves the spoke-to-spoke reachability problem inherent in a hub-and-spoke Frame Relay network, another issue is presented. Recall that when static mapping is enabled for a particular network layer protocol on a specific DLCI, dynamic Inverse ARP for that network layer protocol on the same DLCI is automatically disabled on the interface. On router R2 in Figure 4-2, both static mapping and dynamic Inverse ARP are configured for IP on DLCI 200. This works fine if static mapping is added after dynamic Inverse ARP resolution has been completed. However, when router R2 is rebooted with the saved configurations, dynamic Inverse ARP will be turned off on interface serial3/0. In this case, router R2 will no longer be able to reach the hub router R3. A workable solution to this issue is to use static mapping instead for all remote destinations.

5. Configuring Frame Relay Subinterfaces | Next Section Previous Section

Search Related Safari Books

Safari Books