The Local Management Interface

The Local Management Interface, or LMI, provides signaling on Frame Relay connections. This process is responsible for the keepalive function, in addition to information about the PVC status.

There are three versions of LMI that designers should be familiar with:

•  Frame Relay Forum LMI (Cisco)

•  ITU-T Q.933 Annex A

•  ANSI T1.617 Annex D

Cisco routers default to the Frame Relay Forum LMI specification, and many designers use that default. A number of vendors recommend Annex D because of its improved congestion handling. For reference, the LMI frame format is illustrated in Figure 8.2.

FIGURE 8.2  The LMI frame format

	Cisco added an auto-sense function in IOS 11.2, which automatically detects the version of LMI in use. Administrators may manually set the LMI type with the frame-relay lmi-type {ansi | cisco | q933a} command.

The Frame Relay/Cisco LMI specification operates over DLCI 1023, whereas Annex A and Annex D use DLCI 0. Both of these DLCIs are reserved and cannot be used for non-management data.

The Frame Relay Standard—RFC 1490

The use of standards-based protocols and technology is recommended whenever vendor operability is a concern. Standards-based systems also tend to garner better diagnostic support, including documentation.

Frame Relay is described in RFC 1490, which documents its support for both bridged and routed traffic. The RFC also documents the Inverse ARP function. Inverse ARP provides a mechanism for dynamically mapping upper-layer protocols to the appropriate lower-layer address. This function is enabled by default and can greatly simplify router configuration.

Frame Relay Address Mapping

As with other Layer 3 protocols, Frame Relay requires a mechanism for associating the network address with the data link address. This appears in the form of an address mapping.

Many network designers manually enter the mapping statements into the router, which can facilitate troubleshooting. The commands, which are entered on an interface level, note the protocol, the remote address, the DLCI, and, in these examples, the broadcast keyword.

Note that each Layer 3 protocol is mapped separately to a DLCI.

Nonbroadcast Multiaccess

One of the more advanced concepts in WAN design involves the concept of nonbroadcast multiaccess (NBMA) technologies. Unlike LAN protocols, WAN installations were originally designed around simple point-to-point connections. Addressing was unnecessary, and in the most basic installations, a connection required only one device to be DTE and the other DCE. Such connections are often used to link to routers together without the benefit of a DSU/CSU (data service unit/channel service unit).

Nonbroadcast multiaccess networks acknowledge the limitations of most WANs in comparison to local area networks. The typical wide area network does not lend itself well to broadcasts. This reflects the nonbroadcast portion of NBMA. The multiaccess portion acknowledges that some WAN technologies provide more than one destination—recall that the first WAN links were simple point-to-point configurations.

Frame Relay significantly changes this model, as the protocol becomes most efficient when a single port services multiple destinations. This reduces hardware costs and provides for efficient oversubscription of the network. However, this configuration is not without limitations. When a Frame Relay network is configured as a single subnet over multiple PVCs, the route processor must copy each broadcast and transmit it over each link. This adds a substantial amount of overhead to the router.

NBMA designs also impact the routing protocol, which leads to a recommendation that the network always be configured in a full mesh. However, this is not necessarily required. Split-horizon, or the configuration of a router such that an update never repeats back on the learned interface, can keep portions of the WAN from learning about the remainder of the network. This is shown in Figure 8.3, where subnet 192.168.1.0 will not learn of subnet 192.168.2.0, and vice versa. This is because split-horizon blocks the update about each network from transmitting out of the router on the left side of the diagram.

FIGURE 8.3  An NBMA partial-mesh configuration

The two remote networks, 192.168.1.0 and 192.168.2.0, send routing updates about their Ethernet segments, but split-horizon prevents propagation out of the incoming interface. As a result, neither remote router learns of the other network. Clearly, this problem could be addressed by disabling split-horizon, or with static routes and other techniques. However, these solutions are not without shortcomings. Remember that split-horizon was designed to prevent routing loops; disabling this function will again subject the network to this possibility. The other solutions require a substantial amount of manual intervention and administration—steps that are unnecessary. The next section describes yet another alternative—a means to keep split-horizon enabled and provide full routing in a partial-mesh configuration.

Frame Relay with Point-to-Point Subinterfaces

The preferred method for designing large Frame Relay networks is to use point-to-point subinterfaces. This overcomes the limitations in split-horizon routing that cause problems in NBMA designs. However, each PVC becomes a separate subnet, which can require larger routing tables. Good Frame Relay designs will take advantage of VLSM and route summarization when deploying subinterface configurations.

Subinterface configurations can use either a full-mesh topology or a partial-mesh design. Most partial-mesh installations are designed around a hub-and-spoke topology.

Most administrators consider the number of PVCs, subnets, and hops required for their chosen topology. The formula for calculating the number of PVCs in a full-mesh design is N*(N–1)/2, where N is equal to the number of nodes. Clearly, a partial-mesh point-to-point installation requires the fewest PVCs, yet it adds a hop in each spoke-to-spoke connection. Point-to-point designs also require the greatest number of subnets, which may be a concern in some networks.

	Full-mesh designs are not recommended for OSPF (Open Shortest Path First). Hub-and-spoke topologies are not recommended for EIGRP (Enhanced Interior Gateway Routing Protocol), discussed in Chapter 4. These guidelines are based on the characteristics of each protocol.

Redundancy through Dial-on-Demand Routing

As with most WAN installations, network designers attempt to maintain connectivity options under all circumstances with remote locations. This serves two scenarios—the first is basic connectivity for the remote users, many of whom require access to corporate data in order to be productive. The second goal is one of support; many remote locations lack the technical staff to provide troubleshooting and other diagnostic services.