As an analogy, DLCIs are like shipping docks. If you work for a shipping company,

you might have several ships attached to docks that are each going to a different destination.

When you have a package to ship, you just need to take it to the ship headed

for the destination. It is the captain’s job to know how to reach the destination.

DLCIs are like these docks. They are significant only on your side. You send

your packet out the relevant DLCI, and the provider’s job is to figure out how

to get that frame to its destination.

Behind-the-scenes is a little helper called the local management interface (LMI)

that works as a status enquiry and reporting message. LMI messages are sent

Chapter 7: Introduction to Wide-Area Networks

between your router and the Frame Relay provider’s equipment to verify and

report on the status of your PVC. The three possible states that your PVC can be

in are

Frame Relay provider, but there is a problem with the far-end connection.

The problem is most likely between the far-end router and its connection

to the Frame Relay provider. You should contact your provider

to troubleshoot the issue.

between your router and the Frame Relay provider’s equipment. You

should contact your provider to troubleshoot this issue.

Because of the frequency of LMI messages sent between your router and the Frame

Relay provider, LMI is also used as a keepalive mechanism. Should your router stop

hearing LMI messages it will know that there is a problem with your PVC.

There are three types of LMI. These can be manually configured (discussed

later in the configuration section) or, with IOS 11.2 and higher, can be autodetected.

The three types of LMI are

The committed information rate (CIR) is the guaranteed rate at which you are

allowed to pass data for a particular PVC. When ordering a PVC, you will

request a local access rate (the bandwidth of the physical connection) and the

CIR for a PVC. For example, you may order a T1, which has a local access rate

of 1.544Mb for the Sleepy router, and a CIR of 128K for the PVC to Bashful,

and a CIR of 512K for Grumpy.

Frame Relay is generous with its bandwidth. If there is no congestion on your

link, you are allowed to burst above the CIR rate. Any traffic sent above your

CIR is marked as being Discard Eligible (DE) and, in the event of congestion,

will be dropped.

When congestion does occur, congestion notification messages are sent out to

notify both the sending and the receiving routers that congestion has occurred

and that they should slow down their transmission rates. A Backward Explicit

Congestion Notification (BECN) is sent back to the sender and a Forward

Explicit Congestion Notification (FECN) is sent forward to the destination to

notify them of congestion.

 A BECN message is only sent back to the source when the destination sends a

frame back. Because the provider must wait for a message to return in order to

set the BECN bit in the frame header, the FECN bit is sent to the destination

to request some traffic to be sent back in the reverse direction. Without this, the

source might never know that congestion has occurred.

In the next figure, traffic is congested going from the Sleepy router to the Bashful

router. A FECN is sent to the Bashful router, and a BECN is sent back to the

Sleepy router.

Frame Relay needs a mechanism to map Layer 3 addresses with Layer 2 Frame

Relay DLCIs. This can be done through a static map command (shown later in

the configuration section) or through inverse-arp. Just like Ethernet ARP,

inverse-arp is used to map a Layer 3 address to a Layer 2 address. However,

Ethernet ARP maps an IP address to a MAC address and inverse-arp works to

map an IP address (or other protocol) to a DLCI.

In the next figure Sleepy will need a Layer 3 to Layer 2 map to connect to Bashful,

which has IP address 10.0.0.2. Using inverse-arp, Sleepy will automatically

create a map telling it to use DLCI 100 to get to IP address 10.0.0.2.

Frame Relay is a nonbroadcast multi-access (NBMA) medium, which means

that broadcast traffic is not allowed to traverse Frame Relay traffic. There are

ways, however, to circumvent the NBMA nature of Frame Relay to allow broadcasts

to cross the Frame Relay cloud. These are discussed in the configuration

section.

The split horizon rule (described in Chapter 10, “Basic Routing”) states that a

route learned on an interface should not be advertised back out that same interface.

This poses a problem in NBMA networks where multiple circuits can connect

to a single interface in a hub-and-spoke topology.

Hub-and-spoke topologies are commonly used to connect multiple branch

offices to a headquarters office. For example, in Figure 7.7, the Bashful and

Grumpy routers have circuits to the Sleepy router but not to each other. In this

example, Sleepy is operating as the headquarters office. When Grumpy advertises

its 13.0.0.0/8 network to the Sleepy router, it is sent into serial 0/0, but the

Sleepy router is not allowed to send it back out serial0/0. This causes a problem

because serial0/0 is also connected to the Bashful router. As a result, the Bashful

router will never know about the 13.0.0.0/8 network.

You have four options to get around the split horizon problem:

. Disable split horizon with the no ip split-horizon command. If you

. Have a fully meshed topology where every router has a PVC to every

. Use static routes instead of dynamic routing protocols. This is not a scalable

. Use subinterfaces. This is your best option.

A subinterface is a subset of an existing physical interface. As far as the router is

. point-to-point—This maps a single IP subnet to a single subinterface

. multipoint—This maps a single IP subnet to multiple DLCIs on a

 

 

. Changing the encapsulation for Frame Relay

. Configuring the LMI type (optional for IOS 11.2 or higher)

. Configuring the Frame Relay map (optional unless you are using

. Configuring subinterfaces (optional)

. If using a point-to-point subinterface, configuring your DLCI

 Chapter 7: Introduction to Wide-Area Networks

encapsulation frame-relay [ietf]

frame-relay lmi-type [cisco | ansi | q933a]

frame-relay map protocol address dlci [broadcast] [cisco | ietf]

Router(config-if)#frame-relay map ip 10.0.0.2 100

need to add the keyword broadcast to the end of this command. Routing protocols

Router(config)#interface serial0/0.1 point-to-point

To create a multipoint subinterface, enter multipoint instead:

Router(config)#interface serial0/0.1 multipoint

Router(config-subif)#ip address 10.0.0.2 255.0.0.0

frame-relay interface-dlci dlci

Now let’s put the entire configuration together. The following configuration will

configure Frame Relay for the Sleepy router using a point-to-point subinterface

to connect to the Bashful router and a multipoint subinterface to connect to the

Grumpy router. (A point-to-point could also have been used, but we’ll use

multipoint so you can see both methods.) The next figure shows the topology for the

configuration.

 

. show frame-relay lmi

. show frame-relay pvc

. show frame-relay map

show frame-relay lmi (displayed in the following) will show LMI statistics, including

show frame-relay map (displayed in the following) will show you any static

For troubleshooting, you can execute the debug frame-relay lmi command.