[ LiB ]

Frame Relay Configuration Tasks

The actual configuration of Frame Relay when you use IOS is fairly simple. Frame Relay requires that you configure only two items, assuming that Inverse ARP is used, to establish a connection and start passing traffic. The tasks described in the following sections are required for Frame Relay to function.

Enabling Frame Relay Encapsulation

The first step in configuring Frame Relay on your FRAD is to enable Frame Relay encapsulation on the interface that you will use for the connection.

You can configure Frame Relay to support encapsulation of all protocols that conform to RFC 1490 to create interoperability between multiple vendors. You can use the Internet Engineering Task Force (IETF) form of Frame Relay encapsulation if your FRAD is connected to another vendor's equipment across a Frame Relay network. You can use IETF encapsulation on the interface level or on a per-VC basis.

One optional item often overlooked is the fact that you must shut down the interface before changing encapsulation types. By doing this, you ensure that the interface is reset and is using the new encapsulation type.

DLCI

You use the DLCI to differentiate the Frame Relay VCs from each other. The DLCI value is usually assigned by the service provider of your Frame Relay circuit.

Frame Relay DLCIs have only local significance to the DTE/DCE pair that they are configured on, which means that their values need only be unique in the LAN. Because of this, any Frame Relay DLCIs may be reused throughout the WAN.

Figure 9-3 illustrates how two different DTE devices can be assigned the same DLCI value within one Frame Relay WAN.

Frame Relay Signaling

Frame Relay was not designed to include a built-in mechanism to address network outages. Instead, the Local Management Interface (LMI) signaling protocol was developed to exchange keepalives and to pass administrative information, such as the addition, deletion, or failure of PVCs. These messages are exchanged only between the DTE/DCE pair and are never transmitted across the network in-band of the PVC.

Within IOS, you can assign the LMI type by using a static assignment or a feature called LMI autosense. A statically defined LMI type comes in three different standards:

• ansi The Annex D standard defined by the ANSI standard T1.617.

• q.933 The ITU-T Q.933 Annex A standard.

• cisco The original LMI type defined by the Gang of Four: Cisco, Digital Equipment Corporation, Northern Telecom, and StrataCom. cisco is the default LMI type on a Cisco router.

The term LMI refers to a specific signaling protocol, but all three of the definable LMI types available in IOS are generally referred to as LMI. Be careful when deciding which type you will use. Even though all the LMI types are designed to support the same basic functionality, there are enough differences between them that the interfaces on your DTE/DCE pair must run the same LMI type, or you will experience unpredictable results.

By default, the FRAD sends LMI status messages to the WAN every 10 seconds. A full status request is sent as every sixth LMI status query. The WAN responds with a long status message, including any new events that have occurred since the last long status message.

You can use the following command to set the LMI type that your interface will use to communicate with the Frame Relay switch:

R4(config-if)#frame-relay lmi-type [cisco | ansi | q933a]

LMI Autosense

Cisco FRADs running Cisco IOS Release 11.2 and above support the LMI autosense feature. LMI autosense lets you "sense" the LMI sent by one device that has the LMI type configured, usually on your service provider's WAN equipment, preventing possible misconfiguration.

LMI autosense is automatically enabled in the following situations:

• The router is powered up or the interface changes state to up.

• The line protocol is down, but the line is up.

• The interface is a Frame Relay DTE.

• The LMI type is not explicitly configured on the interface.

When LMI autosense is active, the FRAD sends a full status request in all three LMI message formats to the WAN equipment. It starts with ANSI, and then uses ITU, and finally Cisco in rapid succession. LMI information is passed on DLCI 0 for both the Cisco LMI and Q.933a LMI types. LMI information is passed on DLCI 1023 for the ANSI LMI type. LMI autosense works because the Frame Relay code in IOS can listen to both DLCI 1023 and 0 at the same time.

When the three messages reach the switch, one or more of them elicit a reply, sent back in the form of a status message. Your FRAD then decodes the reply's format to configure the interface's LMI type automatically. Accommodating intelligent switches that can support multiple LMI types and send more than one reply is handled by the FRAD, which configures itself using the last LMI type received. Now, if you look back at the sequence in which the LMI messages are sent, the order should make more sense to you.

If LMI autosense fails to detect the correct LMI type, a retry interval is initiated. For every N391 time interval, which has a 60-second default, LMI autosense retries its automatic LMI configuration sequence.

[ LiB ]