E4_4 Frame Relay

Frame Relay

An alternative to dedicated, expensive, leased WAN lines is Frame Relay.

Frame Relay is a high-performance WAN protocol that operates at the physical and data link layers of the OSI reference model

Frame Relay

Unlike leased lines, Frame Relay requires only a single access circuit to the Frame Relay provider to communicate with other sites connected to the same provider. The capacity between any two sites can vary.

The Frame Relay network handles the transmission over a frequently changing path transparent to all end users.

Frame Relay

Eric Scace, an engineer at Sprint International, invented Frame Relay as a simpler version of the X.25 protocol to use across Integrated Services Digital Network (ISDN) interfaces.

Today, it is also used over a variety of other network interfaces. When Sprint first implemented Frame Relay in its public network, they used StrataCom switches. Cisco’s acquisition of StrataCom in 1996 marked their entry into the carrier market.

Dedicated Line Requirements

A dedicated line provides little practical opportunity for a one-to-many connection without getting more lines from the network provider.

Ej: almost all communication must flow through the corporate headquarters, simply to reduce the cost of additional lines.

The leased-line design also limits flexibility. Unless circuits are already installed, connecting new sites typically requires new circuit installations and takes considerable time to implement.

Cost Effectiveness and Flexibility of Frame Relay

SPAN’s Frame Relay network uses Permanent Virtual Circuits (PVCs),

A PVC is the logical path along an originating Frame Relay link, through the network, and along a terminating Frame Relay link to its ultimate destination.

In a network with Frame Relay access, a PVC uniquely defines the path between two endpoints.

Cost Effectiveness of Frame Relay

Frame Relay is a more cost-effective option for two reasons. First, with dedicated lines, customers pay for an end-to-end connection, which includes the local loop and the network link. With Frame Relay, customers only pay for the local loop, and for the bandwidth they purchase from the network provider. Distance between nodes is not important.

While in a dedicated-line model, customers use dedicated lines provided in increments of 64 kb/s, and Frame Relay customers can define their virtual circuit needs in far greater granularity, often in increments as small as 4 kb/s.

The Flexibility of Frame Relay

A virtual circuit provides considerable flexibility in network design. Examining the figure, you can see that SPAN’s offices all connect to the Frame Relay cloud over their respective local loops. What happens in the cloud is really of no concern at this time.

** All that matters is that when any SPAN office wants to communicate with any other SPAN office, all it needs to do is connect to a virtual circuit leading to the other office.

Virtual Circuits

The connection through a Frame Relay network between two DTEs is a VC. The circuits are virtual because there is no direct electrical connection from end to end.

The connection is logical, and data moves from end to end, without a direct electrical circuit. With VCs, Frame Relay shares the bandwidth among multiple users and any single site can communicate with any other single site without using multiple dedicated physical lines.

Virtual Circuits

Locally significant DLCIs have become the primary method of addressing, because the same address can be used in several different locations while still referring to different connections.

Local addressing prevents a customer from running out of DLCIs as the network grows.

Virtual Circuits

Ej: Frame Relay labels each VC with a DLCI. The DLCI is stored in the address field of every frame transmitted to tell the network how the frame should be routed.

The Frame Relay service provider assigns DLCI numbers. Usually, DLCIs 0 to 15 and 1,008 to 1,023 are reserved.

Therefore, service providers typically assign DLCIs in the range of 16 to 1,007.

Multiple Virtual Circuits

Frame Relay is statistically multiplexed, meaning that it transmits only one frame at a time, but that many logical connections can co-exist on a single physical line.

** The Frame Relay Access Device (FRAD), or router connected to the Frame Relay network, may have multiple VCs connecting it to various endpoints. Multiple VCs on a single physical line are distinguished because each VC has its own DLCI

Cost Benefits of Multiple VCs

With Frame Relay, customers pay for the bandwidth they use. In effect, they pay for a Frame Relay port.

When the customer increases the number of ports, as described above, they pay for more bandwidth, but they do not pay for more equipment because the ports are virtual. There is no change to the physical infrastructure. Compare this to purchasing more bandwidth using dedicated lines.

Frame Relay Encapsulation

First, Frame Relay accepts a packet from a network layer protocol, such as IPv4. It then wraps it with an address field that contains the DLCI and a checksum. Flag fields are added to indicate the beginning and end of the frame.

The flag fields mark the start and end of the frame and are always the same. The flags are represented either as the hexadecimal number 7E or as the binary number 01111110. After the packet is encapsulated, Frame Relay passes the frame to the physical layer for transport.

The header and trailer are defined by the Link Access Procedure for Frame Relay (LAPF) Bearer Services specification, ITU Q.922-A.

Frame Relay Encapsulation

* DLCI - The 10-bit DLCI is one of the most important fields in the Frame Relay header. This value represents the virtual connection between the DTE device and the switch. Each virtual connection that is multiplexed on to the physical channel is represented by a unique DLCI.

* C/R - The C/R bit is not currently defined.

Frame Relay Encapsulation

* Extended Address (EA) - If the value of the EA field is 1, the current byte is determined to be the last DLCI octet. Although current Frame Relay implementations all use a two-octet DLCI, this capability does allow longer DLCIs in the future. The eighth bit of each byte of the Address field indicates the EA.

* Congestion Control - Consists of three Frame Relay congestion-notification bits. These three bits are specifically referred to as the Forward Explicit Congestion Notification (FECN), Backward Explicit Congestion Notification (BECN), and Discard Eligible bits.

Frame Relay Encapsulation

** The physical layer is typically EIA/TIA-232, 449 or 530, V.35, or X.21. The Frame Relay frame is a subset of the HDLC frame type; therefore, it is delimited with flag fields. The 1-byte flag uses the bit pattern 01111110.

The FCS determines whether any errors in the Layer 2 address field occurred during transmission. The FCS is calculated prior to transmission by the sending node, and the result is inserted in the FCS field.

Frame Relay Topologies - Star Topology (Hub and Spoke)

Ej: Connections to each of the five remote sites act as spokes. In a star topology, the location of the hub is usually chosen by the lowest leased-line cost.

When implementing a star topology with Frame Relay, each remote site has an access link to the Frame Relay cloud with a single VC.

** Complete topologies for design, implementation, operation, and maintenance include overview maps, logical connection maps, functional maps, and address maps showing the detailed equipment and channel links.

Frame Relay Topologies - Star Topology (Hub and Spoke)

Ej: shows the star topology in the context of a Frame Relay cloud. The hub at Chicago has an access link with multiple VCs, one for each remote site. The lines going out from the cloud represent the connections from the Frame Relay service provider and terminate at the customer premises.

Because Frame Relay costs are not distance-related, the hub does not need to be in the geographical center of the network

Frame Relay Topologies - Full Mesh Topology

** A full mesh topology suits a situation in which the services to be accessed are geographically dispersed and highly reliable access to them is required. A full mesh topology connects every site to every other site.

Using leased-line interconnections, additional serial interfaces and lines add costs. In this example, 10 dedicated lines are required to interconnect each site in a full mesh topology.

Frame Relay Topologies - Full Mesh Topology

Using Frame Relay Mesh, a network designer can build multiple connections simply by configuring additional VCs on each existing link

Because VCs use statistical multiplexing, multiple VCs on an access link generally make better use of Frame Relay than single VCs.

Service providers will charge for the additional bandwidth, but this solution is usually more cost effective than using dedicated lines

Partial Mesh Topology

For large networks, a full mesh topology is seldom affordable because the number of links required increases exponentially.

** The issue is not with the cost of the hardware, but because there is a theoretical limit of less than 1,000 VCs per link. In practice, the limit is less than that.

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.

This address-to-DLCI mapping can be accomplished either by static or dynamic mapping.

Frame Relay Address Mapping

Inverse ARP

A primary tool of Frame Relay is Inverse Address Resolution Protocol (ARP).

** Whereas ARP translates Layer 3 IPv4 addresses to Layer 2 MAC addresses, Inverse ARP does the opposite. The corresponding Layer 3 IPv4 addresses must be available before VCs can be used.

Frame Relay Address Mapping

Dynamic Mapping

Dynamic address mapping relies on Inverse ARP to resolve a next-hop network layer IPv4 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.

Frame Relay Address Mapping

Static Frame Relay Mapping

The user can choose to override dynamic Inverse ARP mapping by supplying a manual static map 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.

Configuring Static Mapping

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.

** The configuration of Open Shortest Path First (OSPF) protocol can be greatly simplified by adding the optional "broadcast" keyword when doing this task. The broadcast keyword specifies that broadcast and multicast traffic is allowed over the VC. This configuration permits the use of dynamic routing protocols over the VC.

Configuring Static Mapping

Ej: shows the output of the show frame-relay map command. Notice that the interface is up and the destination IPv4 address is 10.1.1.2.

The DLCI identifies the logical connection being used to reach this interface. This value is displayed in decimal value (102), in hexadecimal value (0x66), and as its value as it would appear on the wire (0x1860). This is a static entry, not a dynamic entry. The link is using Cisco encapsulation as opposed to IETF encapsulation.

Local Management Interface (LMI)

Another important concept in Frame Relay is 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.

Local Management Interface (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.

Local Management Interface (LMI)

Ej: ? The output shows the LMI type used by the Frame Relay interface and the counters for the LMI status exchange sequence, including errors such as LMI timeouts.

** 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.

Frame Relay specification includes optional LMI extensions. 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).

Frame Relay specification includes optional LMI extensions. Some of the extensions include:

* Global addressing - Provides connection IDs with 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 are used as on a LAN.

LMI Extensions

LMI is used to manage Frame Relay links. Each LMI message is classified by a DLCI appearing in the LMI frame. The 10-bit DLCI field supports 1,024 VC IDs: 0 to 1,023,

The LMI extensions reserve some of these VC IDs, thereby reducing the number of permitted VCs. LMI messages are exchanged between the DTE and DCE using these reserved DLCIs.

LMI Extensions

** 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

LMI Extensions

Starting with the 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.

Using LMI and Inverse ARP to Map Addresses

Ej: when R1 connects to the Frame Relay network, it sends an LMI status inquiry message to the network. The network replies with an LMI status message containing details of every VC configured on the access link.

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.

Inverse ARP operation

When an interface supporting Inverse ARP becomes active, it initiates the Inverse ARP protocol and formats an Inverse ARP request for the active VC.

The Inverse ARP request includes the source hardware, source Layer 3 protocol address, and the known target hardware address. It then fills the target Layer 3 protocol address field with all zeroes. It encapsulates the packet for the specific network and sends it directly to the destination device using the VC.

Access Rate and Committed Information Rate

Service providers build Frame Relay networks using very large and very powerful switches, but devices only see the switch interface of the service provider.

Customers are usually not exposed to the inner workings of the network, which may be built on very high-speed technologies, such as SONET or SDH.

Frame Relay services -

a. Access rate refers to the port speed. From a customer’s point of view, the service provider provides a serial connection or access link to the Frame Relay network over a leased line.

The access rate is the rate at which your access circuits join the Frame Relay network. These may be 56 kb/s, T1 (1.544 Mb/s), or Fractional T1 (a multiple of 56 kb/s or 64 kb/s). Access rates are clocked on the Frame Relay switch. It is not possible to send data at higher than the access rate.

Frame Relay Example

1. Access rate - The cost of the access line from the DTE to the DCE (customer to service provider). This line is charged based on the port speed that has been negotiated and installed.

2. PVC - This cost component is based on the PVCs. After a PVC is established, the additional cost to increase CIR is typically small and can be done in small (4 kb/s) increments.

3. CIR - Customers normally choose a CIR lower than the access rate. This allows them to take advantage of bursts

Oversubscription

Service providers sometimes sell more capacity than they have on the assumption that not everyone will demand their entitled capacity all of the time.

This oversubscription is analogous to airlines selling more seats than they have in the expectation that some of the booked customers will not show up.

Bursting

A great advantage of Frame Relay is that any network capacity that is being unused is made available or shared with all customers, usually at no extra charge. This allows customers to burst over their CIR as a bonus.

** Ej: Bursting allows devices that temporarily need additional bandwidth to borrow it at no extra cost from other devices not using it. For example, if PVC 102 is transferring a large file, it could use any of the 16 kb/s not being used by PVC 103. A device can burst up to the access rate and still expect the data to get through. The duration of a burst transmission should be less than three or four seconds.

Bursting

Various terms are used to describe burst rates, including the Committed Burst Size (Bc) and Excess Burst Size (Be).

1. The Bc is a negotiated rate above the CIR that the customer can use to transmit for short burst, and represents the maximum allowed traffic under normal working conditions. It allows traffic to burst to higher speeds, as available network bandwidth permits

Bursting

Ej: DLCI 102 has a CIR of 32 kb/s with an additional Bc of 16 kb/s for a total of up to 48 kb/s. DLCI 103 has a CIR of 16 kb/s. However, DLCI 103 does not have a Bc negotiated; therefore, the Bc is set to 0 kb/s. Frames within the negotiated CIR are not eligible for discard (DE = 0).

Frames above the CIR have the DE bit set to 1, marking it as eligible to be discarded, should the network be congested. Frames submitted in the Bc level are marked as Discard Eligible (DE) in the frame header but will most likely be forwarded.

Frame Relay Flow Control

Frame Relay reduces network overhead by implementing simple congestion-notification mechanisms, rather than explicit, per-VC flow control. These congestion-notification mechanisms are the Forward Explicit Congestion Notification (FECN) and the Backward Explicit Congestion Notification (BECN).

Frame Relay Flow Control

FECN and BECN are each controlled by a single bit contained in the frame header. They let the router know that there is congestion and that the router should stop transmission until the condition is reversed.

** When the DCE sets the BECN bit to 1, it notifies devices in the direction of the source (upstream) that there is congestion on the network. When the DCE sets the FECN bit to 1, it notifies devices in the direction of the destination (downstream) that there is congestion on the network.

Frame Relay Configuration TASKS

Basic Frame Relay Configuration Commands

* Step 1. Set the IP Address on the Interface

* Step 2. Configure Encapsulation

encapsulation frame-relay [cisco | ietf]

ietf encapsulation type connecting to a non-Cisco router.

* Step 3. Set the BandwidthStep

* Step 4. Set the LMI Type (optional)

Configuring a Static Frame Relay Map

Ej: ? To map between a next hop protocol address and a DLCI destination address

Static mapping is manually configured on a router.

** Dynamic mapping is performed by the Inverse ARP feature. Because Inverse ARP is enabled by default, no additional command is required to configure dynamic mapping on an interface.

Configuring a Static Frame Relay Map

** Frame Relay, ATM, and X.25 are non-broadcast multiaccess (NBMA) networks.

NBMA networks allow only data transfer from one computer to another, over a VC, or across a switching device.

NBMA networks do not support multicast or broadcast traffic, so a single packet cannot reach all destinations. This requires you to replicate the packets manually to all destinations.

Configuring a Static Frame Relay Map

Ej: shows how to use the keywords when configuring static address maps. Notice that the first IPv6 Frame Relay map to a global unicast address does not include the broadcast keyword.

** However, the broadcast keyword is used in the mapping to the link-local address. IPv6 routing protocols use link-local addresses for multicast routing updates; therefore, only the link-local address map requires the broadcast keyword to forward multicast packets.

Verify a Static Frame Relay Map

Ej: ? To verify the Frame Relay mapping

Notice that there are three Frame Relay maps. There is one map for IPv4 and two for IPv6, one for each of the IPv6 addresses.

Reachability Issues

By default, most Frame Relay networks provide NBMA connectivity, using a hub-and-spoke topology, between remote sites.

** In an NBMA Frame Relay topology, when a single multipoint interface must be used to interconnect multiple sites, routing update reachability issues may result.

Reachability Issues - Split Horizon

The split horizon rule is a loop prevention mechanism for distance vector routing protocols such as EIGRP and RIP. It is not applicable to link-state routing protocols. Split horizon rule reduces routing loops by preventing a routing update that is received on an interface from being forwarded out the same interface.

Ej: which is a hub-and-spoke Frame Relay topology, a remote router R2 (a spoke router) sends an update to the headquarters router R1 (the hub router). R1 is connecting multiple PVCs over a single physical interface. R1 receives the multicast on its physical interface; however, split horizon cannot forward that routing update through the same interface to other remote (spoke) routers.

Reachability Issues - Split Horizon

Ej: displays a similar example using the reference topology used throughout this chapter. R2, a spoke router, sends a routing update to R1, a hub router. R1 has multiple PVCs on a single physical interface. The split horizon rule prevents R1 from forwarding that routing update through the same physical interface to the other remote spoke router (R3).

Note: Split horizon is not an issue if only one PVC (a single remote connection) is configured on a physical interface. This type of connection is point-to-point.

Reachability Issues - Multicast and Broadcast Replication

Ej: due to split horizon, when a router supports multipoint connections over a single interface, the router must replicate broadcast or multicast packets. In the case of routing updates, the updates must be replicated and sent on each PVC to the remote routers.

These replicated packets consume bandwidth and cause significant latency variations in user traffic. The amount of broadcast traffic and the number of VCs terminating at each router should be evaluated during the design phase of a Frame Relay network. Overhead traffic, such as routing updates, can affect the delivery of critical user data, especially when the delivery path contains low-bandwidth (56 kb/s) links.

Reachability Issues - Neighbor Discovery: DR and BDR

Link-state routing protocols, such as OSPF, does not use the split horizon rule for loop prevention. However, reachability issues can arise with the DR/BDR. OSPF over NBMA networks works in non-broadcast network mode, by default, and neighbors are not automatically discovered. Neighbors can be statically configured.

** However, ensure that the hub router becomes a DR,

Recall that a NBMA network behaves like Ethernet, and on Ethernet, a DR is needed to exchange routing information between all routers on a segment. Therefore, only the hub router can act as a DR, because it is the only router that has PVCs with all other routers.

Solving Reachability Issues

There are several ways to solve the routing reachability issue:

1. Disable split horizon - One method for solving the reachability issues that are produced by split horizon may be to turn off split horizon.

** However, disabling split horizon increases the chances of routing loops in your network. Additionally, only IP allows the ability to disable split horizon; IPX and AppleTalk do not.

Solving Reachability Issues

Frame Relay subinterfaces can be configured in either point-to-point or multipoint mode:

a. Point-to-point - A single point-to-point subinterface establishes 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, each subinterface is acting like a point-to-point interface. For each point-to-point VC, there is a separate subnet. Therefore, routing update traffic is not subject to the split horizon rule.

Solving Reachability Issues

Frame Relay subinterfaces can be configured in either point-to-point or multipoint mode:

b. Multipoint (Figure 3) - A single multipoint subinterface establishes multiple PVC connections to multiple physical interfaces or subinterfaces on remote routers. All the participating interfaces are in the same subnet.

** The subinterface acts like an NBMA Frame Relay interface, so routing update traffic is subject to the split horizon rule. All multipoint VCs belong to the same subnet.

Solving Reachability Issues

Using a subinterface configuration, each VC can be configured as a point-to-point connection. A partially meshed network can be divided into a number of smaller, fully meshed, point-to-point networks.

Each point-to-point subnetwork can be assigned a unique network address. This allows each subinterface to act similarly to a leased line. Using a Frame Relay point-to-point subinterface, each pair of the point-to-point routers is on its own subnet.

Configuring Point-to-Point Subinterfaces

Use the DLCI as the subinterface number.

** Note: Unfortunately, altering an existing Frame Relay subinterface configuration may fail to provide the expected result. In these situations, shut down the physical interface, make the appropriate changes to the subinterfaces and then re-enable the physical interface. If the corrected configuration produces unexpected results, then it may be necessary to save the configuration and reload the router.

Configuring Point-to-Point Subinterfaces

** If the subinterface is configured as point-to-point, the local DLCI for the subinterface must also be configured to distinguish it from the physical interface.

The DLCI is also required for multipoint subinterfaces for which Inverse ARP is enabled for IPv4. It is not required for multipoint subinterfaces configured with static route maps.

The Frame Relay service provider assigns the DLCI numbers. These numbers range from 16 to 992, and usually have only local significance. The range varies depending on the LMI used.

Configuring Point-to-Point Subinterfaces

Step 1. Remove any network layer address assigned to the physical interface. If the physical interface has an address, frames are not received by the local subinterfaces.

Step 2. Configure Frame Relay encapsulation on the physical interface using the encapsulation frame-relay command.

Verifying Frame Relay Operation: Frame Relay Interface

1. Verify Frame Relay Interfaces

Ej: ? verify that Frame Relay is operating correctly on that interface

A recommended best practice is to verify the configuration before problems appear.

A verification procedure to ensure everything is working correctly before a configuration is launched on a live network.

Verifying Frame Relay Operation: LMI Operations

Ej: ? to look at some LMI statistics

Toutput that shows the number of status messages exchanged between the local router and the local Frame Relay switch. Ensure that the counters between status messages being sent and received are incrementing. This validates that there is active communication between the DTE and the DCE.

Also look for any non-zero Invalid items. This helps isolate the problem of Frame Relay communications between the carrier’s switch and the client router.

Verifying Frame Relay Operation: PVC Status

Ej: ? to view PVC and traffic statistics, and displays the status of all the PVCs configured on the router

This command is also useful for viewing the number of BECN and FECN packets received by the router. The PVC status can be active, inactive, or deleted.

After the statistics are gathered, use the clear counters command to reset the statistics counters. Wait 5 or 10 minutes after clearing the counters before issuing the show commands again. Note any additional errors. If you need to contact the carrier, these statistics help in resolving the issues.

Verifying Frame Relay Operation: Inverse ARP

Ej: ? To clear dynamically created Frame Relay maps that are created using Inverse ARP

Inverse ARP is enabled by default for IPv4. Frame Relay for IPv6 uses Inverse Neighbor Discovery (IND) to obtain a Layer 3 IPv6 address from a Layer 2 DLCI.

Verifying Frame Relay Operation: Inverse ARP

Ej: ? to display the current map entries and information about the connections.

- 10.1.1.9 is the IPv4 address of the remote router, dynamically learned via the Inverse ARP process.

- 302 is the decimal value of the local DLCI number.

- 0x12E is the hex conversion of the DLCI number, 0x12E = 302 decimal.

Verifying Frame Relay Operation: Inverse ARP

Ej: ? to display the current map entries and information about the connections.

- 0x48E0 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.

- Broadcast/multicast is enabled on the PVC.

- LMI type is cisco.

- PVC status is active.

Verifying Frame Relay Operation: Inverse ARP

When an Inverse ARP request is made, the router updates its map table with three possible PVC connection states. These states are:

- ACTIVE - Indicates a successful end-to-end (DTE to DTE) circuit.

Troubleshooting Frame Relay Operation

Ej: ? to determine whether the router and the Frame Relay switch are sending and receiving LMI packets properly.

- out is an LMI status message sent by the router.

- in is a message received from the Frame Relay switch.

- A full LMI status message is a type 0.

- An LMI exchange is a type 1.

- dlci 102, status 0x2 means that the status of DLCI 102 is active.

Troubleshooting Frame Relay Operation

The possible values of the status field are as follows:

- 0x0 - The switch has this DLCI programmed, but for some reason it is not usable. The reason could possibly be the other end of the PVC is down.

- 0x2 - The Frame Relay switch has the DLCI and everything is operational.