Frame Relay Address Mapping


Before a Cisco router is able to transmit data over Frame Relay, it needs to know which local DLCI maps to the Layer 3 address of the remote destination. 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.
Inverse ARP
The Inverse Address Resolution Protocol (ARP) obtains Layer 3 addresses of other stations from Layer 2 addresses, such as the DLCI in Frame Relay networks. It is primarily used in Frame Relay and ATM networks, where Layer 2 addresses of VCs are sometimes obtained from Layer 2 signaling, and the corresponding Layer 3 addresses must be available before these VCs can be used. Whereas ARP translates Layer 3 addresses to Layer 2 addresses, Inverse ARP does the opposite.
Dynamic Mapping
Dynamic address mapping relies on Inverse ARP to resolve a next hop network protocol address to a local DLCI value. The Frame Relay router sends out Inverse ARP requests on its PVC to discover the protocol address of the remote device connected to the Frame Relay network. The router uses the responses to populate an address-to-DLCI mapping table on the Frame Relay router or access server. The router builds and maintains this mapping table, which contains all resolved Inverse ARP requests, including both dynamic and static mapping entries.
On Cisco routers, Inverse ARP is enabled by default for all protocols enabled on the physical interface. Inverse ARP packets are not sent out for protocols that are not enabled on the interface.
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. You cannot use Inverse ARP and a map statement for the same DLCI and protocol.
An example of using static address mapping is a situation in which 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.
Another example is on a hub-and-spoke Frame Relay network. Use static address mapping 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.
Configuring Static Mapping
Establishing static mapping depends on your network needs. Here are the various commands to use:
To map between a next hop protocol address and DLCI destination address, use this command: frame-relay map protocol protocol-address dlci [broadcast] [ietf] [cisco].
Use the keyword ietf when connecting to a non-Cisco router.
You can greatly simplify the configuration for the Open Shortest Path First (OSPF) protocol by adding the optional broadcast keyword when doing this task.
In this example, static address mapping is performed on interface serial 0/0/0, and the Frame Relay encapsulation used on DLCI 102 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. Static mapping configuration is discussed in more detail in the next section.
Local Management Interface (LMI)
A review of networking history will help you to understand the role played by the Local Management Interface (LMI). The Frame Relay design provides packet-switched data transfer with minimum end-to-end delays. The original design omits anything that might contribute to delay.
When vendors implemented Frame Relay as a separate technology rather than as one component of ISDN, they decided that there was a need for DTEs to dynamically acquire information about the status of the network. However, the original design did not include this feature. A consortium of Cisco, Digital Equipment Corporation (DEC), Northern Telecom, and StrataCom extended the Frame Relay protocol to provide additional capabilities for complex internetworking environments. These extensions are referred to collectively as the LMI.
Basically, the LMI is a keepalive mechanism that provides status information about Frame Relay connections between the router (DTE) and the Frame Relay switch (DCE). Every 10 seconds or so, the end device polls the network, either requesting a dumb sequenced response or channel status information. If the network does not respond with the requested information, the user device may consider the connection to be down. When the network responds with a FULL STATUS response, it includes status information about DLCIs that are allocated to that line. The end device can use this information to determine whether the logical connections are able to pass data.
It is easy to confuse the LMI and encapsulation. The LMI is a definition of the messages used between the DTE (R1) and the DCE (the Frame Relay switch owned by the service provider). Encapsulation defines the headers used by a DTE to communicate information to the DTE at the other end of a VC. The switch and its connected router care about using the same LMI. The switch does not care about the encapsulation. The endpoint routers (DTEs) do care about the encapsulation.
LMI Extensions
In addition to the Frame Relay protocol functions for transferring data, the Frame Relay specification includes optional LMI extensions that are extremely useful in an internetworking environment. Some of the extensions include:
VC status messages - Provide information about PVC integrity by communicating and synchronizing between devices, periodically reporting the existence of new PVCs and the deletion of already existing PVCs. VC status messages prevent data from being sent into black holes (PVCs that no longer exist).
Multicasting - Allows a sender to transmit a single frame that is delivered to multiple recipients. Multicasting supports the efficient delivery of routing protocol messages and address resolution procedures that are typically sent to many destinations simultaneously.
Global addressing - Gives connection identifiers global rather than local significance, allowing them to be used to identify a specific interface to the Frame Relay network. Global addressing makes the Frame Relay network resemble a LAN in terms of addressing, and ARPs perform exactly as they do over a LAN.
Simple flow control - Provides for an XON/XOFF flow control mechanism that applies to the entire Frame Relay interface. It is intended for those devices whose higher layers cannot use the congestion notification bits and need some level of flow control.
The 10-bit DLCI field supports 1,024 VC identifiers: 0 through 1023. The LMI extensions reserve some of these identifiers, thereby reducing the number of permitted VCs. LMI messages are exchanged between the DTE and DCE using these reserved DLCIs.
There are several LMI types, each of which is incompatible with the others. The LMI type configured on the router must match the type used by the service provider. Three types of LMIs are supported by Cisco routers:
Cisco - Original LMI extension
Ansi - Corresponding to the ANSI standard T1.617 Annex D
q933a - Corresponding to the ITU standard Q933 Annex A
Starting with Cisco IOS software release 11.2, the default LMI autosense feature detects the LMI type supported by the directly connected Frame Relay switch. Based on the LMI status messages it receives from the Frame Relay switch, the router automatically configures its interface with the supported LMI type acknowledged by the Frame Relay switch.
If it is necessary to set the LMI type, use the frame-relay lmi-type [cisco | ansi | q933a] interface configuration command. Configuring the LMI type, disables the autosense feature.
When manually setting up the LMI type, you must configure the keepalive interval on the Frame Relay interface to prevent status exchanges between the router and the switch from timing out. The LMI status exchange messages determine the status of the PVC connection. For example, a large mismatch in the keepalive interval on the router and the switch can cause the switch to declare the router dead.
By default, the keepalive time interval is 10 seconds on Cisco serial interfaces. You can change the keepalive interval with the keepalive interface configuration command.
Setting the LMI type and configuring the keepalive are practiced in a following activity.
LMI Frame Format
LMI messages are carried in a variant of LAPF frames. The address field carries one of the reserved DLCIs. Following the DLCI field are the control, protocol discriminator, and call reference fields that do not change. The fourth field indicates the LMI message type.
Status messages help verify the integrity of logical and physical links. This information is critical in a routing environment because routing protocols make decisions based on link integrity.
Using LMI and Inverse ARP to Map Addresses
LMI status messages combined with Inverse ARP messages allow a router to associate network layer and data link layer addresses.
Periodically, the router repeats the status inquiry, but subsequent responses include only status changes. After a set number of these abbreviated responses, the network sends a full status message.
If the router needs to map the VCs to network layer addresses, it sends an Inverse ARP message on each VC. The Inverse ARP message includes the network layer address of the router, so the remote DTE, or router, can also perform the mapping. The Inverse ARP reply allows the router to make the necessary mapping entries in its address-to-DLCI map table. If several network layer protocols are supported on the link, Inverse ARP messages are sent for each one.

0 comments:

Post a Comment

 

NBA Live Streaming. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com | Distributed by Blogger Templates Blog