Extending the Network into the WAN

Extending the Network into the WAN

WANs are most often charge-for-service networks, providing the means for users to access resources across a wide geographic area. Some services are considered Layer 2 connections between your remote locations, typically provided by a telephone company (telco) over its WAN switches. Some of these technologies include a serial point-to-point (leased line) connection and Frame Relay connections.

Other connections leverage the Internet infrastructure, a Layer 3 alternative, to interconnect the remote locations of an organization. To provide security across the public Internet, you can implement a virtual private network (VPN) solution.

This chapter introduces the components of a VPN solution for WAN connectivity, explains how to configure a PPP connection, and describes Frame Relay operation, configuration, and troubleshooting.

Establishing a Point-to-Point WAN Connection with PPP

Wide-area networking services are typically leased from a service provider. Some WAN services operate as Layer 2 connections between your remote locations and are typically provided by a telephone company (telco) provider over its WAN switches.

PPP emerged as an encapsulation protocol for transporting IP traffic over point-to-point (leased line) serial connections. This section describes the operation, configuration, and verification of PPP.

Understanding WAN Encapsulations

On each WAN connection, data is encapsulated into frames before it crosses the WAN link. To ensure that the correct protocol is used, you must configure the appropriate Layer 2 encapsulation type. The choice of Layer 2 protocol depends on the WAN technology and the communicating equipment. Figure 8-16 highlights some of the choices for connecting to the WAN.

Figure 8-16 WAN Choices

The following are typical WAN protocols:

• High-Level Data Link Control (HDLC): The Cisco default encapsulation type on point-to-point connections, dedicated links, and circuit-switched connections. You typically use HDLC when two Cisco devices are communicating across a point-topoint connection. HDLC is a bit-oriented synchronous data link layer protocol.
• PPP: Provides router-to-router and host-to-network connections over synchronous and asynchronous circuits. PPP was designed to work with several network layer protocols, including IP. PPP also has built-in security mechanisms, such as Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP).
• Frame Relay: A successor to X.25. This protocol is an industry-standard, switched data link layer protocol that handles multiple virtual circuits (VC). Frame Relay is streamlined to eliminate some of the time-consuming processes, such as error correction and flow control, that were employed in X.25 to compensate for older, less reliable communication links.
• ATM: This protocol is the international standard for cell relay in which multiple service types, such as voice, video, and data, are conveyed in fixed-length (53-byte) cells. ATM, a cell-switched technology, uses fixed-length cells, which allow processing to occur in hardware, thereby reducing transit delays. ATM is designed to take advantage of high-speed transmission media such as T3, E3, and SONET.
• Broadband: Broadband in data communications typically refers to data transmission where multiple pieces of data are sent simultaneously to increase the effective rate of transmission, regardless of the actual data rate. In network engineering, this term refers to transmission methods where two or more signals share a medium, such as the following technologies:
  • DSL-PPP over Ethernet (PPPoE) and PPP over ATM (PPPoA): A family of technologies that provide digital data transmission over the wires of a local telephone network. Typically, the download speed of consumer DSL services ranges from 256 to 24,000 kbps, depending on DSL technology, line conditions, and the service level that has been implemented. DSL implementations often use PPPoE or PPPoA. Both implementations offer standard PPP features such as authentication, encryption, and compression. PPPoE is a network protocol for encapsulating PPP frames in Ethernet frames. PPPoA is a network protocol for encapsulating PPP frames in ATM adaptation layer 5 (AAL5).
  • Cable-Ethernet: A cable modem is a type of modem that provides access to a data signal sent over the cable television infrastructure. Cable modems are primarily used to deliver broadband Internet access, taking advantage of unused bandwidth on a cable television network. The bandwidth of business cable modem services typically ranges from 3 Mbps up to 30 Mbps or more. Current cable modem systems use the Ethernet frame format for data transmission over upstream and downstream data channels. Each of the downstream data channels and the associated upstream data channels on a cable network form an extended Ethernet WAN.
• Metro Ethernet: The emergence of Metro Ethernet as a viable method of providing both point-to-point and multipoint services has been driven by an abundance of new fiber deployment to business areas. Enterprise customers with years of Ethernet experience in the campus have developed such a comfort level and confidence with Ethernet that they are now asking their service providers for Ethernet as an access option. Ethernet might be the most scalable transport technology ever developed.

Starting at 10 Mbps, it has now evolved to 10 Gbps, with plans for 40 Gbps. Several prominent methods exist for transporting Ethernet over Metro networks, including these key solution approaches:

• Delivering Ethernet services over dark fiber
• Delivering Ethernet services over SONET/Synchronous Digital Hierarchy (SDH) networks
• Delivering Ethernet services that use Resilient Packet Ring (RPR) technology

Overview of PPP

Developers designed PPP to make the connection for point-to-point links. PPP, described in RFC 1661, encapsulates network layer protocol information over point-to-point links. RFC 1661 is updated by RFC 2153, “PPP Vendor Extensions.”
You can configure PPP on the following types of physical interfaces:

• Asynchronous serial: Plain old telephone service (POTS) dialup
• Synchronous serial: ISDN or point-to-point leased lines

The Link Control Protocol (LCP) portion of PPP is used to negotiate and set up control options on the WAN data link. PPP offers a rich set of services. These services are options in LCP and are primarily used for negotiation and checking frames to implement the pointto-point controls that an administrator specifies for a connection.

With its higher-level functions, PPP can carry packets from several network layer protocols by using network control protocols (NCP) . The NCPs include functional fields that contain standardized codes to indicate the network layer protocol type that is encapsulated in the PPP frame.

Figure 8-17 shows how NCP and LCP provide these functions for PPP.

Figure 8-17 PPP Components

Three phases of a PPP session establishment are described in the following list:

1. Link establishment phase In this phase, each PPP device sends LCP packets to configure and test the data link.
   LCP packets contain a configuration option field that allows devices to negotiate the use of options, such as the maximum receive unit, compression of certain PPP fields, and the link authentication protocol. If a configuration option is not included in an LCP packet, the default value for that configuration option is assumed.
2. Authentication phase (optional)
   After the link has been established and the authentication protocol has been decided on, the peer goes through the authentication phase. Authentication, if used, takes place before the network layer protocol phase is begun.
   PPP supports two authentication protocols: PAP and CHAP. Both of these protocols are discussed in RFC 1334, “PPP Authentication Protocols.” However, RFC 1994, “PPP Challenge Handshake Authentication Protocol (CHAP),” renders RFC 1334 obsolete.
3. Network layer protocol phase In this phase, the PPP devices send NCP packets to choose and configure one or more network layer protocols, such as IP. After each of the chosen network layer protocols is configured, datagrams from each network layer protocol can be sent over the link. PAP is a two-way handshake that provides a simple method for a remote node to establish its identity. PAP is performed only upon initial link establishment. After the PPP link establishment phase is complete, the remote node repeatedly sends a username and password pair to the router until authentication is acknowledged or the connection is terminated. Figure 8-18 shows an example of a PAP authentication.

Figure 8-18 PAP Authentication

PAP is not a strong authentication protocol. Passwords are sent across the link in plain text, which can be fine in environments that use token-type passwords that change with each authentication, but are not secure in most environments. Also there is no protection from playback or repeated trial-and-error attacks; the remote node is in control of the frequency and timing of the login attempts.

CHAP, which uses a three-way handshake, occurs at the startup of a link and periodically thereafter to verify the identity of the remote node using a three-way handshake.

After the PPP link establishment phase is complete, the local router sends a challenge message to the remote node. The remote node responds with a value that is calculated using a one-way hash function, typically message digest algorithm 5 (MD5), based on the password and challenge message. The local router checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged. Otherwise, the connection is terminated immediately. Figure 8-19 provides an example of CHAP authentication.

Figure 8-19 CHAP Authentication

CHAP provides protection against playback attack using a variable challenge value that is unique and unpredictable. Because the challenge is unique and random, the resulting hash value will also be unique and random. The use of repeated challenges is intended to limit exposure to any single attack. The local router or a third-party authentication server is in control of the frequency and timing of the challenges.

Configuring and Verifying PPP

To enable PPP encapsulation with PAP or CHAP authentication on an interface, complete the following checklist:

• Enable PPP encapsulation as the Layer 2 protocol of an interface.
• (Optional) Enable PPP authentication by performing these steps:

Step 1 Configure the router host name to identify itself.
Step 2 Configure the username and password to authenticate the PPP peer.
Step 3 Choose the authentication technique to use on the PPP link: PAP or CHAP.
To enable PPP encapsulation, use the encapsulation ppp command in interface configuration mode.
To configure PPP authentication, the interface must be configured for PPP encapsulation.
Follow these steps to enable PAP or CHAP authentication.
Step 1 Verify that each router has a host name assigned to it. To assign a host name, enter the hostname name command in global configuration mode. This name must match the username that is expected by the authenticating router at the other end of the link.
Step 2 On each router, define the username and password to expect from the remote router with the username name password password global configuration command.
Table 8-1 describes the username command parameters.

Table 8-1 username Parameters

Add a username entry for each remote system that the local router communicates with and that requires authentication. Note that the remote device must have a corresponding username entry for the local router with a matching password.
Step 3 Configure PPP authentication with the ppp authentication { chap | chap pap | pap chap | pap} interface configuration command.
If you configure ppp authentication chap on an interface, all incoming PPP sessions on that interface are authenticated using CHAP. Likewise, if you configure ppp authentication pap, all incoming PPP sessions on that interface are authenticated using PAP.

If you configure ppp authentication chap pap, the router attempts to authenticate all incoming PPP sessions using CHAP. If the remote device does not support CHAP, the router tries to authenticate the PPP session using PAP. If the remote device does not support either CHAP or PAP, the authentication fails, and the PPP session is dropped.

If you configure ppp authentication pap chap, the router attempts to authenticate all incoming PPP sessions using PAP. If the remote device does not support PAP, the router tries to authenticate the PPP session using CHAP. If the remote device does not support either protocol, the authentication fails and the PPP session is dropped.

NOTE If you enable both methods, the first method that you specify is requested during link negotiation. If the peer suggests using the second method or refuses the first method, the second method is tried.

Example: PPP and CHAP Configuration

Figure 8-20 shows an example of CHAP configuration on two routers. In this example, a two-way challenge occurs. The hostname on one router must match the username that the other router has configured. The passwords must also match.

Figure 8-20 PPP & CHAP Configuration Example

Example: Verifying PPP Encapsulation Configuration

Use the show interface command to verify proper configuration. Example 8-1 shows that PPP encapsulation has been configured and LCP has established a connection, as indicated by “LCP Open” in the command output.

Example 8-1 Verifying PPP Encapsulation with the show interface Command

RouterX# show interface s0
Serial0 is up, line protocol is up
 Hardware is HD64570
 Internet address is 10.140.1.2/24
 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
 Encapsulation PPP, loopback not set, keepalive set (10 sec)
 LCP Open
 Open: IPCP, CDPCP
 Last input 00:00:05, output 00:00:05, output hang never
 Last clearing of “show interface” counters never
 Queueing strategy: fifo
 Output queue 0/40, 0 drops; input queue 0/75, 0 drops
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 38021 packets input, 5656110 bytes, 0 no buffer
 Received 23488 broadcasts, 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
 38097 packets output, 2135697 bytes, 0 underruns
 0 output errors, 0 collisions, 6045 interface resets
0 output buffer failures, 0 output buffers swapped out
 482 carrier transitions
 DCD=up DSR=up DTR=up RTS=up CTS=up

Example: Verifying PPP Authentication

Example 8-2 illustrates the router output that occurs during CHAP authentication. Because two-way authentication is configured, that is, each router authenticates the other, messages appear that reflect both the authenticating process and the process of being authenticated.
Use the debug ppp authentication command to display the exchange sequence as it occurs.

Example 8-2 Verifying Authentication with the debug ppp authentication Command

RouterX# debug ppp authentication
4d20h: %LINK-3-UPDOWN: Interface Serial0, changed state to up
4d20h: Se0 PPP: Treating connection as a dedicated line
4d20h: Se0 PPP: Phase is AUTHENTICATING, by both
4d20h: Se0 CHAP: O CHALLENGE id 2 len 28 from “left”
4d20h: Se0 CHAP: I CHALLENGE id 3 len 28 from “right”
4d20h: Se0 CHAP: O RESPONSE id 3 len 28 from “left”
4d20h: Se0 CHAP: I RESPONSE id 2 len 28 from “right”
4d20h: Se0 CHAP: O SUCCESS id 2 len 4
4d20h: Se0 CHAP: I SUCCESS id 3 len 4
4d20h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed

To determine whether the router is performing one-way or two-way CHAP authentication, look for the following message in the debug ppp authentication output, which indicates that the routers are performing two-way authentication:
Se0 PPP: Phase is AUTHENTICATING, by both Either one of the following messages indicates that the routers are performing one-way authentication:

Se0 PPP: Phase is AUTHENTICATING, by the peer
Se0 PPP: Phase is AUTHENTICATING, by this end

The following output highlights output for a two-way PAP authentication:

! Two way authentication:
Se0 PPP: Phase is AUTHENTICATING, by both
! Outgoing authentication request:
Se0 PAP: O AUTH-REQ id 4 len 18 from “RouterX”
! Incoming authentication request:
Se0 PAP: I AUTH-REQ id 1 len 18 from “RouterY”
! Authenticating incoming:
Se0 PAP: Authenticating peer RouterY
! Outgoing acknowledgement:
Se0 PAP: O AUTH-ACK id 1 len 5
! Incoming acknowledgement:
Se0 PAP: I AUTH-ACK id 4 len 5

To determine whether the router is performing CHAP or PAP authentication, look for the following lines in the debug ppp authentication command output:

• Look for CHAP in the AUTHENTICATING phase, as shown in this example:

  *Mar 7 21:16:29.468: BR0:1 PPP: Phase is AUTHENTICATING, by this end
  *Mar 7 21:16:29.468: BR0:1 CHAP: O CHALLENGE id 5 len 33 from “maui-soho-03”

• Look for PAP in the AUTHENTICATING phase, as shown in this example:

  *Mar 7 21:24:11.980: BR0:1 PPP: Phase is AUTHENTICATING, by both
  *Mar 7 21:24:12.084: BR0:1 PAP: I AUTH-REQ id 1 len 23 from “maui-soho-01”

  The most common output from the debug ppp negotiation command is described as follows:

• Timestamp: Millisecond timestamps are useful.
• Interface and Interface number: This field is useful when debugging multiple connections or when the connection transitions through several interfaces.
• Type of PPP message: This field indicates whether the line is a general PPP, LCP, CHAP, PAP, or IP Control Protocol (IPCP) message.
• Direction of the message: An “I” indicates an incoming packet, and an “O” indicates an outgoing packet. This field can be used to determine whether the message was generated or received by the router.
• Message: This field includes the particular transaction under negotiation.
• ID: This field is used to match and coordinate request messages to the appropriate response messages. You can use the ID field to associate a response with an incoming message.
• Length: The length field defines the length of the information field. This field is not important for general troubleshooting. The last four fields might not appear in all the PPP messages, depending on the purpose of the message.

Establishing a WAN Connection with Frame Relay

Frame Relay is a high-performance WAN protocol that was standardized by the ITU-T and is widely used in the United States. This section describes Frame Relay operation, configuration, and troubleshooting.

Understanding Frame Relay

Frame Relay is a connection-oriented data-link technology that is streamlined to provide high performance and efficiency. For error protection, it relies on upper-layer protocols and dependable fiber and digital networks.

Frame Relay defines the interconnection process between the router and the local access switching equipment of the service provider. It does not define how the data is transmitted within the Frame Relay service provider cloud. Figure 8-21 shows that Frame Relay operates between the router and the frame relay switch.

Figure 8-21 Frame Relay

Devices attached to a Frame Relay WAN fall into the following two categories:

• Data terminal equipment (DTE): Generally considered to be the terminating equipment for a specific network. DTE devices are typically located on the customer premises and can be owned by the customer. Examples of DTE devices are Frame Relay Access Devices (FRAD), routers, and bridges.
• Data communications equipment (DCE): Carrier-owned internetworking devices. The purpose of DCE devices is to provide clocking and switching services in a network and to transmit data through the WAN. In most cases, the switches in a WAN are Frame Relay switches.

Frame Relay provides a means for statistically multiplexing many logical data conversations, referred to as virtual circuits (VC), over a single physical transmission link by assigning connection identifiers to each pair of DTE devices. The service provider switching equipment constructs a switching table that maps the connection identifier to outbound ports. When a frame is received, the switching device analyzes the connection identifier and delivers the frame to the associated outbound port. The complete path to the destination is established prior to the transmission of the first frame. Figure 8-22 illustrates a Frame Relay connection and identifies the many components within Frame Relay.

Figure 8-22 Frame Relay Components

The following terms are used frequently in Frame Relay discussions and can be the same or slightly different from the terms your Frame Relay service provider uses:

• Local access rate: Clock speed (port speed) of the connection (local loop) to the Frame Relay cloud. The local access rate is the rate at which data travels into or out of the network, regardless of other settings.
• Virtual circuit (VC): Logical circuit, uniquely identified by a data-link connection identifier (DLCI), that is created to ensure bidirectional communication from one DTE device to another. A number of VCs can be multiplexed into a single physical circuit for transmission across the network. This capability can often reduce the complexity of the equipment and network that are required to connect multiple DTE devices. A VC can pass through any number of intermediate DCE devices (Frame Relay switches). A VC can be either a permanent virtual circuit (PVC) or a switched virtual circuit (SVC).
• Permanent virtual circuit (PVC): Provides permanently established connections that are used for frequent and consistent data transfers between DTE devices across the Frame Relay network. Communication across a PVC does not require the call setup and call teardown that is used with an SVC.
• Switched virtual circuit (SVC): Provides temporary connections that are used in situations that require only sporadic data transfer between DTE devices across the Frame Relay network. SVCs are dynamically established on demand and are torn down when transmission is complete.

NOTE With ANSI T1.617 and ITU-T Q.933 (Layer 3) and Q.922 (Layer 2), Frame Relay now supports SVCs. Cisco IOS Release 11.2 or later supports Frame Relay SVCs. This book does not cover information on configuring Frame Relay SVCs.

• Data-link connection identifier (DLCI): Contains a 10-bit number in the address field of the Frame Relay frame header that identifies the VC. DLCIs have local significance because the identifier references the point between the local router and the local Frame Relay switch to which the DLCI is connected. Therefore, devices at opposite ends of a connection can use different DLCI values to refer to the same virtual connection.
• Committed information rate (CIR): Specifies the maximum average data rate that the network undertakes to deliver under normal conditions. When subscribing to a Frame Relay service, you specify the local access rate, for example, 56 kbps or T1. Typically, you are also asked to specify a CIR for each DLCI. If you send information faster than the CIR on a given DLCI, the network flags some frames with a discard eligible (DE) bit. The network does its best to deliver all packets but discards any DE packets first if congestion occurs. Many inexpensive Frame Relay services are based on a CIR of 0. A CIR of 0 means that every frame is a DE frame, and the network throws any frame away when it needs to. The DE bit is within the address field of the Frame Relay frame header.
• Inverse Address Resolution Protocol (ARP): A method of dynamically associating the network layer address of the remote router with a local DLCI. Inverse ARP allows a router to automatically discover the network address of the remote DTE device that is associated with a VC.
• Local Management Interface (LMI): A signaling standard between the router (DTE device) and the local Frame Relay switch (DCE device) that is responsible for managing the connection and maintaining status between the router and the Frame Relay switch.
• Forward explicit congestion notification (FECN): A bit in the address field of the Frame Relay frame header. The FECN mechanism is initiated when a DTE device sends Frame Relay frames into the network. If the network is congested, DCE devices (Frame Relay switches) set the FECN bit value of the frames to 1. When these frames reach the destination DTE device, the address field with the FECN bit set indicates that these frames experienced congestion in the path from source to destination. The DTE device can relay this information to a higher-layer protocol for processing. Depending on the implementation, flow control might be initiated or the indication might be ignored.
• Backward explicit congestion notification (BECN): A bit in the address field of the Frame Relay frame header. DCE devices set the value of the BECN bit to 1 in frames that travel in the opposite direction of frames that have their FECN bit set. Setting BECN bits to 1 informs the receiving DTE device that a particular path through the network is congested. The DTE device can then relay this information to a higher-layer protocol for processing. Depending on the implementation, flow control might be initiated or the indication might be ignored.

Example: Frame Relay Terminology—DLCI

As shown in Figure 8-22, Router A has two virtual circuits that are configured on one physical interface. A DLCI of 100 identifies the VC that connects to Router B. A DLCI of 400 identifies the VC that connects to Router C. At the other end, a different DLCI number can be used to identify the VC. Frame Relay allows you to interconnect your remote sites in a variety of topologies. Figure 8-23 illustrates these topologies.

Figure 8-23 Frame Relay Topologies

Each topology is further described as follows:

• Partial-mesh topology: Not all sites have direct access to all other sites. Dependingon the traffic patterns in your network, you might want to have additional PVCs connect to remote sites that have large data traffic requirements.
• Full-mesh topology: All routers have VCs to all other destinations. Full-mesh topology, although costly, provides direct connections from each site to all other sites and allows redundancy. When one link goes down, a router can reroute traffic through another site. As the number of nodes in this topology increases, a full-mesh topology can become very expensive. Use the n (n – 1) / 2 formula to calculate the total number of links that are required to implement a full-mesh topology, where n is the number of nodes. For example, to fully mesh a network of 10 nodes, 45 links are required—10 (10 – 1) / 2.
• Star topology: Remote sites are connected to a central site that generally provides a service or an application. The star topology, also known as a hub-and-spoke configuration, is the most popular Frame Relay network topology. This is the least expensive topology because it requires the least number of PVCs. In the figure, the central router provides a multipoint connection because it typically uses a single interface to interconnect multiple PVCs.

By default, a Frame Relay network provides nonbroadcast multiaccess (NBMA) connectivity between remote sites. An NBMA environment is treated like other broadcast media environments, such as Ethernet, where all the routers are on the same subnet.

However, to reduce cost, NBMA clouds are usually built in a hub-and-spoke topology. With a hub-and-spoke topology, the physical topology does not provide the multiaccess capabilities that Ethernet does, so each router might not have separate PVCs to reach the other remote routers on the same subnet. Split horizon is one of the main issues you encounter when Frame Relay is running multiple PVCs over a single interface.

In any Frame Relay topology, when a single interface must be used to interconnect multiple sites, you can have reachability issues because of the NBMA nature of Frame Relay. The Frame Relay NBMA topology can cause the following two problems:

• Routing update reachability: Split horizon updates reduce routing loops by preventing a routing update that is received on an interface from being forwarded out the same interface. In a scenario using a hub-and-spoke Frame Relay topology, a remote router (a spoke router) sends an update to the headquarters router (the hub router) that is connecting multiple PVCs over a single physical interface. The headquarters router then receives the broadcast on its physical interface but cannot forward that routing update through the same interface to other remote (spoke) routers. Split horizon is not a problem if a single PVC exists on a physical interface because this type of connection would be more of a point-to-point connection type.
• Broadcast replication: With routers that support multipoint connections over a single interface that terminate many PVCs, the router must replicate broadcast packets, such as routing update broadcasts, on each PVC to the remote routers. These replicated broadcast packets consume bandwidth and cause significant latency variations in user traffic.

The following methods exist to solve the routing update reachability issue:

• To solve the reachability issues brought on by split horizon, turn off split horizon. However, two problems exist with this solution. First, although most network layer protocols, such as IP, do allow you to disable split horizon, not all network layer protocols allow you to do this. Second, disabling split horizon increases the chances of routing loops in your network.
• Use a fully meshed topology; however, this topology increases the cost.
• Use subinterfaces. To enable the forwarding of broadcast routing updates in a hub-andspoke Frame Relay topology, you can configure the hub router with logically assigned interfaces called subinterfaces, which are logical subdivisions of a physical interface. In split horizon routing environments, routing updates that are received on one subinterface can be sent out another subinterface. In subinterface configuration, each VC can be configured as a point-to-point connection, which allows each subinterface to act like a leased line. When you use a Frame Relay point-to-point subinterface, each subinterface is on its own subnet.
  Figure 8-24 shows how to resolve the issues using subinterfaces.

Figure 8-24 Using Subinterfaces with Frame Relay

A Frame Relay connection requires that, on a VC, the local DLCI be mapped to a destination network layer address, such as an IP address. Routers can automatically discover their local DLCI from the local Frame Relay switch using the LMI protocol.

On Cisco routers, the local DLCI can be dynamically mapped to the remote router network layer addresses with Inverse ARP. Inverse ARP associates a given DLCI to the next-hop protocol address for a specific connection. Inverse ARP is described in RFC 1293.

Example: Frame Relay Address Mapping

As shown in Figure 8-25, using Inverse ARP, the router on the left can automatically discover the remote router IP address and then map it to the local DLCI. In this case, the local DLCI of 500 is mapped to the 10.1.1.1 IP address. Therefore, when the router must send data to 10.1.1.1, it uses DLCI 500.

Figure 8-25 Frame Relay Address Mapping

Instead of using Inverse ARP to automatically map the local DLCIs to the remote router network layer addresses, you can manually configure a static Frame Relay map in the map table.
Frame Relay signaling is required between the router and the Frame Relay switch.
Figure 8-26 shows how the signaling is used to get information about the different DLCIs.

Figure 8-26 Frame Relay Signaling

The LMI is a signaling standard between the router and the Frame Relay switch. The LMI is responsible for managing the connection and maintaining the status between the devices. Although the LMI is configurable, beginning in Cisco IOS Release 11.2, the Cisco router tries to autosense which LMI type the Frame Relay switch is using. The router sends one or more full LMI status requests to the Frame Relay switch. The Frame Relay switch responds with one or more LMI types, and the router configures itself with the last LMI type received. Cisco routers support the following three LMI types:

• Cisco: LMI type defined jointly by Cisco, StrataCom, Northern Telecom (Nortel), and Digital Equipment Corporation
• ANSI: ANSI T1.617 Annex D
• Q.933A: ITU-T Q.933 Annex AYou can also manually configure the appropriate LMI type from the three supported types to ensure proper Frame Relay operation.
  When the router receives LMI information, it updates its VC status to one of the following three states:

• Active: Indicates that the VC connection is active and that routers can exchange data over the Frame Relay network.
• Inactive: Indicates that the local connection to the Frame Relay switch is working, but the remote router connection to the remote Frame Relay switch is not working.
• Deleted: Indicates that either no LMI is being received from the Frame Relay switch or that no service exists between the router and local Frame Relay switch.

The following is a summary of how Inverse ARP and LMI signaling work with a Frame Relay connection:

1. Each router connects to the Frame Relay switch through a channel service unit/data service unit (CSU/DSU).
2. When Frame Relay is configured on an interface, the router sends an LMI status inquiry message to the Frame Relay switch. The message notifies the switch of the router status and asks the switch for the connection status of the router VCs.
3. When the Frame Relay switch receives the request, it responds with an LMI status message that includes the local DLCIs of the PVCs to the remote routers to which the local router can send data.
4. For each active DLCI, each router sends an Inverse ARP packet to introduce itself.
   Figure 8-27 illustrates the first four steps of this process.
   Figure 8-27 Stages of Inverse ARP and LMI Operation
   
5. When a router receives an Inverse ARP message, it creates a map entry in its Frame Relay map table that includes the local DLCI and the remote router network layer address. Note that the router DLCI is the local DLCI, not the DLCI that the remote router is using. Any of the three connection states can appear in the Frame Relay map table.
   NOTE If Inverse ARP is not working or the remote router does not support Inverse ARP, you must manually configure static Frame Relay maps, which map the local DLCIs to the remote network layer addresses.
6. Every 60 seconds, routers send Inverse ARP messages on all active DLCIs. Every 10 seconds, the router exchanges LMI information with the switch (keepalives).
7. The router changes the status of each DLCI to active, inactive, or deleted, based on the LMI response from the Frame Relay switch.

Figure 8-28 illustrates Steps 5–7 of this process.

Figure 8-28 Stages of Inverse ARP and LMI Operation Continued

Configuring Frame Relay

A basic Frame Relay configuration assumes that you want to configure Frame Relay on one or more physical interfaces and that the routers support LMI and Inverse ARP. The following steps are used to configure basic Frame Relay:
Step 1 Select the interface needed for Frame Relay. Use the interface configuration mode.

RouterX(config)# interface serial1

After the interface configuration is entered, the command-line interface (CLI)
prompt changes from (config)# to (config-if)#.

Step 2 Configure a network layer address, for example, an IP address.

RouterX(config-if)# ip address 1 0. 1 6. 0. 1 255. 255. 255. 0

Step 3 Select the Frame Relay encapsulation type that is used to encapsulate end-to-end data traffic. Use the encapsulation frame-relay interface configuration command.

RouterX(config-if)# encapsulation frame-relay [ cisco | ietf]

The option cisco means that Cisco encapsulation is being used. Use this option if you are connecting to another Cisco router. You do not need to enter the keyword cisco because it is the default encapsulation. The option ietf sets the encapsulation method to comply with the Internet Engineering Task Force (IETF) standard (RFC 2427). Select this option if you are connecting to a router from another vendor.

Step 4 Establish LMI connection using the frame-relay lmi-type interface configuration command.

RouterX(config-if)# frame-relay lmi-type {ansi | cisco | q933a}

This command is needed only if you are using Cisco IOS Software Release 11.1 or earlier. With Cisco IOS Software Release 11.2 or later, the LMI type is autosensed and no configuration is needed. The option cisco is the default. The LMI type is set on a per-interface basis and is shown in the output of the show interfaces EXEC command.

Step 5 Configure the bandwidth for the link using the bandwidth [kilobits]
interface configuration command. For example:

RouterX(config-if)# bandwidth 64

This command affects routing operations performed by protocols such as Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest Path First (OSPF), as well as other calculations.
Step 6 Enable Inverse ARP if it was disabled on the router. Use the frame-relay inverse-arp [protocol] [dlci] interface configuration command.

The protocol parameter indicates the protocol in use. Supported protocols include IP, Internetwork Packet Exchange (IPX), AppleTalk, DECnet, Banyan Virtual Integrated Network Service (VINES), and Xerox Network Services (XNS). The dlci parameter indicates the DLCI on the local interface with which you want to exchange Inverse ARP messages. Inverse ARP is on by default and does not appear in the configuration output.
Consider the following configuration, where IP is the protocol, and the DLCI is 16:

RouterX(config-if)# frame-relay inverse-arp ip 16

When the remote router does not support Inverse ARP, the Frame Relay peers have different Frame Relay encapsulation types. Or when you want to control broadcast and multicast traffic over the PVC, you must statically map the local DLCI to the remote router network layer address. These static Frame Relay map entries are referred to as static maps.

Use the following command to statically map the remote network layer address to the local DLCI:

RouterX(config-if)# frame- relay map protocol protocol-address dlci [ broadcast]
[ ietf | cisco | payload- compress packet- by- packet]

Table 8-2 details the parameters for this command.

Table 8-2 frame-relay map Command Parameters

You can configure subinterfaces in one of the following two modes:

• Point-to-point: A single point-to-point subinterface is used to establish one PVC connection to another physical interface or subinterface on a remote router. In this case, each pair of the point-to-point routers is on its own subnet, and each point-to-point subinterface has a single DLCI. In a point-to-point environment, because each subinterface acts like a point-to-point interface, update traffic is not subject to the split horizon rule.
• Multipoint: A single multipoint subinterface is used to establish multiple PVC connections to multiple physical interfaces or subinterfaces on remote routers. In this case, all the participating interfaces are in the same subnet. In this environment, because the subinterface acts like a regular NBMA Frame Relay interface, update traffic is subject to the split horizon rule.

Example: Configuring Frame Relay Point-to-Point Subinterfaces

In Figure 8-29, Router A has two point-to-point subinterfaces. The s0.110 subinterface connects to Router B, and the s0.120 subinterface connects to Router C. Each subinterface is on a different subnet.

Figure 8-29 Point-to-Point Subinterfaces

Follow these steps to configure subinterfaces on a physical interface:
Step 1 Select the interface upon which you want to create subinterfaces and enter interface configuration mode.
Step 2 Remove any network layer address that is assigned to the physical interface and assign the network layer address to the subinterface.
Step 3 Configure Frame Relay encapsulation.
Step 4 Use the following command to select the subinterface you want to configure and to designate it as a point-to-point subinterface:

RouterX(config-if)# interface serial number. subinterface-number point- to-point}

Table 8-3 describes the options for this command.

Table 8-3 interface serial Command Parameters

Step 5 If you configured the subinterface as the point-to-point subinterface, you must configure the local DLCI for the subinterface to distinguish it from the physical interface. The command to configure the local DLCI on the subinterface follows:

RouterX(config-subif)# frame-relay interface-dlci dlci-number

The dlci-number parameter defines the local DLCI number that is being linked to the subinterface. No other methods exist to link an LMI-derived DLCI to a subinterface because the LMI does not know about subinterfaces. Do not use the frame-relay interface-dlci command on physical interfaces.

NOTE If you defined a subinterface for point-to-point communication, you cannot reassign the same subinterface number to use for multipoint communication without first rebooting the router. Instead, use a different subinterface number.

Example: Configuring Frame Relay Multipoint Subinterfaces

In Figure 8-30, all the routers are on the 10.17.0.0/24 subnet. Router A is configured with a multipoint subinterface with three PVCs. The PVC with DLCI 120 is used to connect to Router B, the PVC with DLCI 130 is used to connect to Router C, and the PVC with DLCI 140 is used to connect to Router D.

Figure 8-30 Frame Relay Multipoint Subinterface

Split horizon is disabled by default on Frame Relay multipoint main interfaces and enabled by default on Frame Relay multipoint subinterfaces. In the figure, which uses a multipoint subinterface, split horizon must be manually disabled at Router A to overcome the split horizon issue.
Follow these steps to configure subinterfaces on a physical interface:
Step 1 Select the interface upon which you want to create subinterfaces and enter interface configuration mode.
Step 2 Remove any network layer address, like the IP address, assigned to the physical interface and assign the network layer address to the subinterface.
Step 3 Configure Frame Relay encapsulation.
Step 4 Use the following command to select the subinterface you want to configure and to designate it as a multipoint subinterface:

RouterX(config-if)# interface serial number. subinterface-number multipoint

Table 8-4 describes the options for this command.

Table 8-4 interface serial Command Parameters

You are required to enter either the multipoint or point-to-point parameter; no default is available.
Step 5 If you have configured the subinterface as multipoint and Inverse ARP is enabled, you must configure the local DLCI for the subinterface to distinguish it from the physical interface. This configuration is not required for multipoint subinterfaces that are configured with static route maps. The command to configure the local DLCI on the subinterface follows:

RouterX(config-subif)# frame-relay interface-dlci dlci-number

The dlci-number parameter defines the local DLCI number that is being linked to the subinterface. No other methods exist to link an LMI-derived DLCI to a subinterface because the LMI does not know about subinterfaces. Do not use the frame-relay interface-dlci command on physical interfaces.

NOTE If you defined a subinterface for point-to-point communication, you cannot reassign the same subinterface number to use for multipoint communication without first rebooting the router. Instead, use a different subinterface number.

Verifying Frame Relay

The show interfaces command displays information regarding the encapsulation and Layer 1 and Layer 2 status. Verify that the encapsulation is set to Frame Relay.
The command also displays information about the LMI type and the LMI DLCI. The LMI DLCI is not the DLCI that identifies the PVC across which data is passed. That DLCI is shown in the show frame-relay pvc command.

The output also displays the Frame Relay DTE or DCE type. Normally, the router will be the DTE. However, a Cisco router can be configured as the Frame Relay switch; in this case, the type will be DCE. Example 8-3 shows the output from this command.

Example 8-3 Verify Frame Relay Information with the show interfaces Command

RouterX# show interfaces s0
Serial0 is up, line protocol is up
 Hardware is HD64570
 Internet address is 10.140.1.2/24
 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
 LMI enq sent 19, LMI stat recvd 20, LMI upd recvd 0, DTE LMI up
 LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
 LMI DLCI 1023 LMI type is CISCO frame relay DTE
 FR SVC disabled, LAPF state down
 Broadcast queue 0/64, broadcasts sent/dropped 8/0, interface broadcasts 5
 Last input 00:00:02, output 00:00:02, output hang never
 Last clearing of “show interface” counters never
 Queueing strategy: fifo
 Output queue 0/40, 0 drops; input queue 0/75, 0 drops
 <Output omitted>

Use the show frame-relay lmi command to display LMI traffic statistics. For example, this command shows the number of status messages exchanged between the local router and the local Frame Relay switch. Example 8-4 shows the output of this command.

Example 8-4 Displaying LMI Traffic Statistics with the show frame-relay lmi Command

RouterX# show frame- relay lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO
 Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
 Invalid Status Message 0 Invalid Lock Shift 0
 Invalid Information ID 0 Invalid Report IE Len 0
 Invalid Report Request 0 Invalid Keep IE Len 0
 Num Status Enq. Sent 113100 Num Status msgs Rcvd

Table 8-5 describes a few of the fields in the show frame-relay lmi display.

Table 8-5 show frame-relay lmi Fields

Use the debug frame-relay lmi command to determine whether the router and the Frame Relay switch are sending and receiving LMI packets properly. Example 8-5 shows the output associated with this command.

Example 8-5 Confirming LMI Packet Traffic Delivery/Receipt with the debug frame-relay lmi Command

RouterX# debug frame- relay lmi
Frame Relay LMI debugging is on
Displaying all Frame Relay LMI data
RouterX#
1w2d: Serial0(out): StEnq, myseq 140, yourseen 139, DTE up
1w2d: datagramstart = 0xE008EC, datagramsize = 13
1w2d: FR encap = 0xFCF10309
1w2d: 00 75 01 01 01 03 02 8C 8B
1w2d:
1w2d: Serial0(in): Status, myseq 140
1w2d: RT IE 1, length 1, type 1
1w2d: KA IE 3, length 2, yourseq 140, myseq 140
1w2d: Serial0(out): StEnq, myseq 141, yourseen 140, DTE up
1w2d: datagramstart = 0xE008EC, datagramsize = 13
1w2d: FR encap = 0xFCF10309
1w2d: 00 75 01 01 01 03 02 8D 8C
1w2d:
1w2d: Serial0(in): Status, myseq 142
1w2d: RT IE 1, length 1, type 0
1w2d: KA IE 3, length 2, yourseq 142, myseq 142
1w2d: PVC IE 0x7 , length 0x6 , dlci 100, status 0x2 , bw 0

The first four lines describe an LMI exchange. The first line describes the LMI request that the router has sent to the Frame Relay switch. The second line describes the LMI reply that the router has received from the Frame Relay switch. The third and fourth lines describe the response to this request from the switch. This LMI exchange is followed by two similar LMI exchanges. The last six lines consist of a full LMI status message that includes a description of the two PVCs of the router.

Table 8-6 describes the significant fields shown in Example 8-5.

The “(out)” output is an LMI status message that is sent by the router. The “(in)” output is a message that is received from the Frame Relay switch.
The “type 0” output indicates a full LMI status message. The “type 1” output indicates an LMI exchange. The “dlci 100, status 0x2” output means that the status of DLCI 100 is active. The common values of the DLCI status field are as follows:

• 0x0: “Added” and “inactive” mean that the switch has this DLCI programmed, but for some reason—for example, the other end of this PVC is down—it is not usable.
• 0x2: “Added” and “active” mean that the Frame Relay switch has the DLCI, and everything is operational. You can start sending traffic with this DLCI in the header.
• 0x4: “Deleted” means that the Frame Relay switch does not have this DLCI programmed for the router but that it was programmed at some point in the past. This status could also happen because the DLCIs are reversed on the router or because the PVC was deleted by the service provider in the Frame Relay cloud.

Use the show frame-relay pvc [interface interface] [dlci] command to display the status of each configured PVC as well as traffic statistics. Example 8-6 shows the output of this command.

Example 8-6 Displaying PVC Status and Traffic Statistics with the show frame-relay pvc Command

RouterX# show frame- relay pvc 1 00
PVC Statistics for interface Serial0 (Frame Relay DTE)
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
 input pkts 28 output pkts 10 in bytes 8398
 out bytes 1198 dropped pkts 0 in FECN pkts 0
 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
 in DE pkts 0 out DE pkts 0
 out bcast pkts 10 out bcast bytes 1198
 pvc create time 00:03:46, last time pvc status changed 00:03:47

Table 8-7 describes the fields of the show frame-relay pvc command display.

Table 8-7 show frame-relay pvc Output Fields

Use the show frame-relay map command to display the current map entries and information about the connections. Example 8-7 shows the output of this command.

Example 8-7 Displaying Frame Relay Map Entries and Connection Information with the show

frame-relay map Command
RouterX# show frame- relay map
Serial0 (up): ip 10.140.1.1 dlci 100(0x64,0x1840), dynamic,
 broadcast,, status defined, active
RouterX# clear frame- relay- inarp
RouterX# show frame map
RouterX#

The following information explains the show frame-relay map output that appears in the example:

• The “100” output is the local DLCI number in decimal.
• The “0x64” output is the hex conversion of the DLCI number (0x64 = 100 decimal).
• The “0x1840” output is the value as it would appear “on the wire” because of the way the DLCI bits are spread out in the address field of the Frame Relay frame.
• The “10.140.1.1” output is the remote router IP address (a dynamic entry that is learned through the Inverse ARP process).
• Broadcast and multicast are enabled on the PVC because broadcast is stated in the third line.
• The PVC status is active.

To clear dynamically created Frame Relay maps, which are created using Inverse ARP, use the clear frame-relay-inarp privileged EXEC command.

Troubleshooting Frame Relay WANs

A Frame Relay network offers a few additional benefits that a leased-line implementation does not offer. But with these benefits comes a bit more complexity. The addition of concepts such as nonbroadcast multiaccess (NBMA), Local Management Interface (LMI), Inverse Address Resolution Protocol (ARP), and Frame Relay maps requires that an administrator have a fundamental knowledge of these concepts to better troubleshoot connectivity issues that can arise.

Components of Troubleshooting Frame Relay

Troubleshooting Frame Relay requires a step-by-step approach that identifies and tests each of the major components. Figure 8-31 outlines this approach in a flowchart. The major components of Frame Relay troubleshooting are described as follows:

• Troubleshooting a Frame Relay link that is down, which could be a Layer 1 or Layer 2 issue
• Troubleshooting Frame Relay remote router connectivity, which is the connectivity between the Frame Relay peer routers
• Troubleshooting Frame Relay end-to-end connectivity, which is the connectivity between workstations across a Frame Relay network

Figure 8-31 Flowchart for Troubleshooting Frame Relay

Troubleshooting Frame Relay Connectivity Issues

The first step in troubleshooting Frame Relay connectivity issues is to check the status of the Frame Relay interface. Figure 8-32 gives a flowchart for troubleshooting these issues.

Figure 8-32 Troubleshooting Connectivity Issues

Use the show interface serial number[/number] command to check the status of the Frame
Relay interface.

If the output of the show interface serial command displays a status of “interface down/ line protocol down,” this typically indicates a problem at Layer 1, the physical layer. This output means that you have a problem with the cable, CSU/DSU, or the serial line. First, use the show controllers serial [slot/port] command to verify that the cable is present and recognized by the router.

Next, you might need to troubleshoot the problem with a loopback test. Follow these steps to perform a loopback test:
Step 1 Set the serial line encapsulation to High-Level Data Link Control (HDLC) and keepalive to 10 seconds. To do this, use the encapsulation hdlc and keepalive 10 commands in the interface configuration mode of the interface you are troubleshooting.
Step 2 Place the CSU/DSU or modem in local-loop mode. Check the device documentation to determine how to do this. If the line protocol comes up when the CSU/DSU or modem is in local-loop mode, indicated by a “line protocol is up (looped)” message, this suggests that the problem is occurring beyond the local CSU/DSU. If the status line does not change status, a problem could be in the router, connecting cable, CSU/DSU, or modem. In most cases, the problem is with the CSU/DSU or modem.
Step 3 Execute a ping command to the IP address of the interface you are troubleshooting while the CSU/DSU or modem is in local-loop mode.
No misses should occur. An extended ping that uses a data pattern of 0x0000 is helpful in resolving line problems because a T1 or E1 connection derives clock speed from the data and requires a transition every 8 bits. A data pattern with many 0s helps to determine whether the transitions are appropriately forced on the trunk. A pattern with many 1s is used to appropriately simulate a high 0 load in case a pair of data
inverters is in the path. The alternating pattern (0x5555) represents a “typical” data pattern. If your pings fail or if you get cyclic redundancy
check (CRC) errors, a bit error rate tester (BERT) with an appropriate analyzer from the telephone company (telco) is needed.
Step 4 When you are finished testing, ensure that you return the encapsulation of the interface to Frame Relay.

An incorrect statically defined DLCI on a subinterface can also cause the status of the subinterface to appear as “down/down,” and the PVC status might appear as “deleted.” To verify that the correct DLCI number has been configured, use the show frame-relay pvc command, as demonstrated in Example 8-8.

Example 8-8 Verifying DLCI Configuration

RouterX# show frame- relay pvc
PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)
 Active Inactive Deleted Static
 Local 0 0 1 0
 Switched 0 0 0 0
 Unused 0 0 0 0
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/0/0
 input pkts 9 output pkts 8 in bytes 879
 out bytes 1024 dropped pkts 0 in pkts dropped 0
 out pkts dropped 0 out bytes dropped 0
 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
 out BECN pkts 0 in DE pkts 0 out DE pkts 0
 out bcast pkts 2 out bcast bytes 138
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:00:27, last time pvc status changed 00:00:27

In the output, the DLCI number shows “100” and reports a status of “deleted.” This might indicate that the DLCI you configured was incorrect.

If the output of a show interface serial command displays a status of “interface up/line protocol down,” this typically indicates a problem at Layer 2, the data link layer. If this is the case, the serial interface might not be receiving the LMI keepalives from the Frame Relay service provider. To verify that LMI messages are being sent and received and to verify that the router LMI type matches the LMI type of the provider, use the show framerelay lmi command, as demonstrated in Example 8-9.

Example 8-9 Verifying LMI Traffic Delivery/Receipt and LMI Type Matches Between Router and Provider

RouterX# show frame- relay lmi
LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = CISCO
 Invalid Unnumbered info 0 Invalid Prot Disc 0
 Invalid dummy Call Ref 0 Invalid Msg Type 0
 Invalid Status Message 0 Invalid Lock Shift 0
 Invalid Information ID 0 Invalid Report IE Len 0
 Invalid Report Request 0 Invalid Keep IE Len 0
 Num Status Enq. Sent 236 Num Status msgs Rcvd 31
 Num Update Status Rcvd 0 Num Status Timeouts 206
Last Full Status Req 00:00:38 Last Full Status Rcvd 00:00:38

The output shows that 236 LMI status inquiry messages have been sent (Num Status Enq. Sent), 31 LMI status messages have been received (Num Status msgs Rcvd), and the LMI type is set to “Cisco.”
For a Frame Relay router to reach a peer router across the Frame Relay network, it must map the IP address of the peer router with the local DLCI it uses to reach that IP address. Figure 8-33 shows the steps involved in troubleshooting remote router connectivity issues.

Figure 8-33 Troubleshooting Remote Router Connectivity with Frame Relay

As demonstrated in Example 8-10, the show frame-relay map command shows the IP address–to–DLCI mappings and indicates whether the mapping was statically entered or dynamically learned using Inverse ARP.

Example 8-10 Verifying IP Address–to–DLCI Mappings and Static or Dynamic Configuration

RouterX# show frame- relay map
Serial0/0/0 (up): ip 10.140.1.1 dlci 100(0x64,0x1840), dynamic,
 broadcast, CISCO, status defined, active

If you have recently changed the address on the remote Frame Relay router interface, you might need to use the clear frame-relay-inarp command to clear the Frame Relay map of the local router. This will cause Inverse ARP to dynamically remap the new address with the DLCI.

If the IP address of the peer router does not appear in the Frame Relay mapping table, the remote router might not support Inverse ARP. Try adding the IP address–to–DLCI mapping statically by using the frame-relay map protocol protocol-address dlci [broadcast] command.
Additionally, access control lists (ACL) might be applied to the Frame Relay interfaces that affect connectivity. To verify whether an ACL is applied to an interface, use the show ip interface command.

To temporarily remove an ACL from an interface to verify whether it is affecting connectivity, use the no ip access-group acl_num { in | out} command in interface configuration mode.

For end-to-end connectivity to exist between two workstations across an active Frame Relay network, general routing requirements must be met. Figure 8-34 shows the troubleshooting steps for verifying end-to-end connectivity.

If you are experiencing end-to-end connectivity problems in your Frame Relay network, check the routing tables to see whether the routers have a route to the destination with which you are having connectivity problems. To check the routing table, use the show ip route command, as demonstrated in Example 8-11.

Figure 8-34 Troubleshooting End-to-End Connectivity with Frame Relay

If only directly connected routes appear in the routing table, the problem might be that the Frame Relay network is preventing the routing protocol updates from being advertised across it. Because of the NBMA nature of Frame Relay, you must configure

the router to pass routing protocol broadcasts or multicasts across the Frame Relay network. With the use of Inverse ARP, this capability is in effect automatically. With a static Frame Relay map, you must explicitly configure the support for broadcast traffic. The show frame-relay map command displays whether the broadcast capability is in effect, allowing routing updates to be passed across the Frame Relay network, as demonstrated in Example 8-12.

More Resources

• Interconnecting Cisco Network Devices (ICND2)
• CCNP Switch Exam Certification Guide