This chapter covers the following topics that you will need to master as a CCNA:

•

This section covers basic operation and terminology

used with point-to-point leased lines. Configuration and debugging of PPP, HDLC,

and LAPB are shown as well.

•

Frame Relay is one of the most popular WAN services

today. The concepts and terminology used with Frame Relay are discussed in detail,

including the use of Frame Relay DLCIs.

•

Several variations for Frame Relay configuration

exist. This section covers the default style of configuration and then discusses the

various options. The text also details design choices of how to assign IP subnet and

IPX network numbers.

•

As with Frame Relay, ISDN has its own set of

concepts, terms, and acronyms. This section covers the protocol basics.

•

Dial-on-demand routing

(DDR) is the name for the IOS features that relate to dialing other routers to add new

links for routing packets. This section covers DDR concepts and configuration, with

ISDN configuration information interspersed.

•

This section gives a brief summary of the WAN

options covered in this chapter.

CCNAs deal with both permanent and dialed WAN connections on routers on a regular

basis. In fact, with the pervasiveness of LAN switches in modern buildings, more

frequently the issues relating to router installation and troubleshooting are about WAN

connections.

This chapter is rather long; if you plan to read the entire chapter, you might want to treat it

as three separate sections. These three major sections are outlined in Table 8-1. The first of

these topical areas discusses point-to-point leased lines. The second covers Frame Relay,

and the last details DDR and ISDN.

Cisco expects CCNAs to be able to configure, verify, and troubleshoot WAN connections.

The conceptual material in this chapter is important, but it is Cisco’s desire that the exam

serve as proof that you are able to make this stuff work. Focusing on the command

examples and scenarios will help.

By taking the following steps, you can make better use of your study time:

•

Keep your notes and the answers for all your work with this book in one place, for

easy reference.

•

Take the “Do I Know This Already?” quiz, and write down your answers. Studies

show that retention is significantly increased through writing down facts and

concepts, even if you never look at the information again.

•

Use the diagram in Figure 8-1 to guide you to the next step.

Chapter 8: WAN Protocols and Design

The purpose of the “Do I Know This Already?” quiz is to help you decide what parts of this

chapter to use. If you already intend to read the entire chapter, you do not necessarily need to

answer these questions now.

This 12-question quiz helps you choose how to spend your limited study time. The quiz is

sectioned into three smaller four-question “quizlets,” which correspond to the three major

headings in the chapter. Figure 8-1 outlines suggestions on how to spend your time in this

chapter. Use Table 8-1 to record your score.

1 Point-to-Point Leased Lines 1 to 4

2 Frame Relay Protocols

Frame Relay Configuration

5 to 8

3 ISDN Protocols and Design

Dial-on-Demand Routing and ISDN

Configuration

9 to 12

All questions 1 to 12

“Do I Know This Already?” Quiz

Can PPP perform dynamic assignment of IP addresses? If so, is the feature always

enabled?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Create a configuration to enable PPP on serial 0 for IP and IPX. Make up IP and IPX

Layer 3 addresses as needed.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

CHAP configuration uses names and passwords. Given Routers A and B, describe what

names and passwords must match in the respective CHAP configurations.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

What field has Cisco added to the HDLC header, making it proprietary?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Explain the purpose of Inverse ARP. Explain how Inverse ARP uses Frame Relay

broadcasts.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Would a Frame Relay switch connected to a router behave differently if the IETF option

were deleted from the encapsulation

command on that attached router?

Would a router on the other end of the VC behave any differently if the same change were

made?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Chapter 8: WAN Protocols and Design

What

command will tell you the time that a PVC became active? How does the

router know what time the PVC came active?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

What

options will show Inverse ARP messages?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

What does the acronym LAPD stand for? Is it used as the Layer 2 protocol on dialed ISDN

bearer channels? If not, what is used?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Define the term

. List two examples of reference points.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Describe the decision process performed by the IOS to attempt to dial a connection using

legacy DDR.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

If packets from 10.1.1.0/24 were “interesting” in relation to DDR configuration such that

packets from 10.1.1.0/24 would cause a DDR connection out an interface BRI0, list the

configuration commands that would make the IOS think that those packets were

interesting on BRI0.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

“Do I Know This Already?” Quiz

The answers to the quiz are found in Appendix A, “Answers to the ‘Do I Know This Already?’

Quizzes and Q&A Sections,” on page 768. The suggested choices for your next step are as

follows:

•

—Read the entire chapter. This includes the “Foundation Topics”

and “Foundation Summary” sections, the Q&A section, and the scenarios at the end of the

chapter.

•

—Review the subsection(s) of the “Foundation Topics” part of

this chapter, based on the following list. Then move into the “Foundation Summary”

section, the quiz, and the scenarios at the end of the chapter.

•

—Begin with the “Foundation Summary” section, and then go to

the Q&A section and the scenarios at the end of the chapter.

•

—If you want more review on these topics, skip to the

“Foundation Summary” section and then go to the Q&A section and the scenarios at the

end of the chapter. Otherwise, move to the next chapter.

Chapter 8: WAN Protocols and Design

WAN protocols used on point-to-point serial links provide the basic function of delivery of data

across that one link. As a CCNA, you will be required to understand and configure a variety of

protocols used on point-to-point links, including Link Access Procedure Balanced (LAPB),

High-Level Data Link Control (HDLC), and Point-to-Point Protocol (PPP). Each of these WAN

protocols has the following functions in common:

•

LAPB, HDLC, and PPP provide for delivery of data across a single point-to-point serial

link.

•

LAPB, HDLC, and PPP deliver data on synchronous serial links. (PPP supports

asynchronous functions as well.)

Framing is one core feature of any synchronous serial data link protocol. Each of these

protocols defines framing so that receiving stations know where the beginning of the frame is,

what address is in the header, and the point at which the packet begins. By doing so, the router

receiving data can distinguish between idle frames and data frames. Synchronous links, rather

than asynchronous links, are typically used between routers.

simply means that there is an imposed time ordering at the sending and receiving

ends of the link. Essentially, the sides agree to a certain speed, but because it is very expensive

to build devices that can truly operate at exactly the same speed, the devices adjust their rates

to match a clock source. The process works almost like the scenes in spy novels, when the spies

synchronize their watches; in this case, the watches or clocks are synchronized automatically

multiple times per minute. Unlike asynchronous links, in which no bits are sent during idle

times, synchronous data links define idle frames. These frames do nothing more than provide

plenty of signal transitions so that clocks can be adjusted on the receiving end, consequently

maintaining synchronization.

Before describing the features of these data link protocols, a brief reference to some popularly

used WAN terminology is useful. Table 8-2 lists the terms.

Synchronous The imposition of time ordering on a bit stream. More

practically speaking, a device will try to use the same speed

as another on the other end of a serial link. However, by

examining transitions between voltage states on the link, the

device can notice slight variations in the speed on each end so

that it can adjust its speed.

Point-to-Point Leased Lines

Three key attributes help to differentiate among these synchronous serial data link protocols

(LAPB, HDLC, and PPP):

•

Whether the protocol supports synchronous communications, asynchronous

communications, or both.

•

Whether the protocol provides error recovery. (The LAPB, HDLC, and PPP protocols all

provide error detection.)

Asynchronous The lack of an imposed time ordering on a bit stream. More

practically speaking, both sides agree to the same speed, but

there is no check or adjustment of the rates if they are slightly

different. However, because only 1 byte per transfer is sent,

slight differences in clock speed are not an issue. A start bit is

used to signal the beginning of a byte.

Clock source The device to which the other devices on the link adjust their

speed when using synchronous links.

DSU/CSU Data Services Unit and Channel Services Unit. This is used on

digital links as an interface to the telephone company in the

United States. Routers typically use a short cable from a serial

interface to a DSU/CSU, which is attached to the line from the

telco with a similar configuration at the other router on the

other end of the link. The routers use their attached DSU/CSU

as the clock source.

Telco Telephone company.

4-wire circuit A line from the telco with four wires, comprised of two

twisted-pair wires. Each pair is used to send in one direction,

so a 4-wire circuit allows full-duplex communication.

2-wire circuit A line from the telco with two wires, comprised of one

twisted-pair wire. The pair is used to send in only one direction

at a time, so a 2-wire circuit allows only half-duplex

communication.

T/1 A line from the telco that allows transmission of data at

1.544Mbps. This can be used with a T/1 multiplexor.

T/1 mux A multiplexor that separates the T/1 into 24 different 64kbps

channels. In the United States, one of every 8 bits in each

channel can be used by the telco so that the channels are

effectively 56kbps channels.

E/1 Like a T/1, but in Europe. It uses a rate of 2.048Mbps and 32

64kbps channels.

Chapter 8: WAN Protocols and Design

•

Whether an architected Protocol Type field exists. In other words, the protocol

specifications define a field in the header that identifies the type of packet contained in the

data portion of the frame.

First, a few words about the criteria used to compare these WAN protocols might prove helpful.

Synchronous protocols allow more throughput over a serial link than asynchronous protocols

do. However, asynchronous protocols require less expensive hardware because there is no need

to watch transitions and adjust the clock rate. For links between routers, synchronous links are

typically desired and used. All the protocols covered in this section support synchronous links.

Another comparison criteria is error recovery. Error recovery is covered in detail in Chapter 3,

“OSI Reference Model & Layered Communication,” but a brief review is in order here. All the

data link protocols described here use a field in the trailer, usually called the frame check

sequence (FCS), that is used to verify whether bit errors occurred during transmission of the

frame. If so, the frame is discarded. Error recovery is the process that causes retransmission of

the lost frame(s); error recovery may be performed by the data link protocol or a higher-layer

protocol, or error recovery may not be performed at all. Regardless, all WAN data link protocols

perform error detection, which involves noticing the error and discarding the frame.

Finally, the definition and use of an architected Protocol Type field is the final criteria for

comparison. As described in more detail in Chapter 3, each data link protocol that supports

multiple network layer protocols needs a method of defining the type of packet encapsulated

inside the WAN data link frame. If such a field is part of the protocol specification, it is

considered “architected”—in other words, specified in the protocol. If Cisco must add some

other header information to create a Protocol Type field, then that type field is not considered

to be architected.

Table 8-3 lists these point-to-point data link protocols and their attributes. (For a review of the

Protocol Type field, refer to Chapter 3.)

Synchronous Data

Link Control

(SDLC)

Yes None SDLC supports multipoint links; it

assumes that the SNA header occurs

after the SDLC header.

Link Access

Procedure

Balanced (LAPB)

Yes None Spec assumes a single configurable

protocol after LAPB. LAPB is used

mainly with X.25. Cisco uses a

proprietary type field to support

multiprotocol traffic.

Link Access

Procedure on the D

channel (LAPD)

No No LAPD is not used between routers,

but is used on the D channel from

router to ISDN switch for signaling.

Point-to-Point Leased Lines

Be careful not to confuse LAPB and LAPD. The D can help remind you that it is for an ISDN D channel, but

don’t let that make you think that the B is for an ISDN B channel.

One common task for CCNAs is to enable an appropriate point-to-point data link protocol.

The configuration is straightforward, with LAPB being the exception. (Be sure to configure

the same WAN data link protocol on each end of the serial link. Otherwise, the routers will

misinterpret the incoming frames, and the link will not work.) Tables 8-4 and 8-5 summarize

the configuration commands and the

and

commands used for HDLC and PPP

configuration.

High-Level Data

Link Control

(HDLC)

No No HDLC serves as Cisco’s default on

serial links. Cisco uses a proprietary

type field to support multiprotocol

traffic.

Point-to-Point

Protocol (PPP)

Enables the user to

choose whether

error correction is

performed;

correction uses

LAPB

Yes PPP was meant for multiprotocol

interoperability from its inception,

unlike all the others. PPP also

supports asynchronous

communication.

{

|

|

} Interface subcommand

[

|

|

[

]]

Interface subcommand

Lists statistics and details of interface configuration,

including the encapsulation type.

Lists compression ratios.

Lists processor and task utilization. Is useful in watching

for increased utilization due to compression.

Chapter 8: WAN Protocols and Design

Example 8-1 lists configuration for HDLC, followed by the changed configuration for a

migration to PPP. Assume that Router A and Router B have a serial link attached to their serial

0 ports, respectively.

Changing serial encapsulations in configuration mode is tricky compared to some other

configuration commands in a Cisco router. In Example 8-1, converting back to HDLC (the

default) is done with the

command, not by using a command such as

. Additionally, any other interface subcommands that are pertinent only to

PPP are also removed when the

PPP provides several other features in addition to synchronization and framing. The features

fall into two categories: those needed regardless of the Layer 3 protocol sent across the link, and

those particular to each Layer 3 protocol.

The PPP Link Control Protocol (LCP) provides the base features needed regardless of the Layer

3 protocol sent across the link. A series of PPP control protocols, such as IP Control Protocol

(IPCP), provide features for a particular Layer 3 protocol to function well across the link. For

example, IPCP provides for IP address assignment; this feature is used extensively with Internet

dialup connections today.

Only one LCP is needed per link, but multiple control protocols are needed. If a router is

configured for IPX, AppleTalk, and IP on a PPP serial link, the router configured for PPP

encapsulation automatically tries to bring up the appropriate control protocols for each Layer 3

protocol. Table 8-6 summarizes the features of LCP, which performs functions not specific to a

particular Layer 3 protocol.

Router A Router B

Interface serial 0 Interface serial 0

encapsulation ppp encapsulation ppp

. .

. later, changed to... . later, changed to...

. .

interface serial 0 interface serial 0

encapsulation hdlc encapsulation hdlc

Error detection Link Quality

Monitoring (LQM)

PPP can take down a link based on the percentage of

errors on the link. LQM exchanges statistics about lost

packets versus sent packets in each direction; when

compared to packets and bytes sent, this yields a

percentage of errored traffic. The percentage of loss that

causes a link to be taken down is enabled and defined

by a configuration setting.

Error Detection and Looped Link Detection

Error detection and looped link detection are two key features of PPP. Looped link detection

allows for faster convergence when a link fails because it is looped. (Links are typically looped

for testing purposes.) When this occurs, a router continues to receive the looped Cisco

proprietary keepalive messages, so the router might not think that the link has failed. For

instance, the absence of routing updates from a neighbor for a certain length of time is used to

drive convergence. Waiting on such an event when the link is looped increases convergence

time.

router sends PPP messages instead of keepalives; these messages include a magic number,

which is different on each router. If a line is looped, the router receives a message with its own

magic number instead of getting a message with the magic number identifying the router on the

other end of the link. A router receiving its own magic number knows that the frame it sent has

been looped back. If configured to do so, the router can take down the interface, which speeds

convergence.

correctly received packets and bytes. This is compared to the number of packets and bytes sent

to calculate a percentage loss. The router can be configured to take down the link after a

configured error rate has been exceeded so that future packets are sent over a longer—but

hopefully better—path.

Looped link

detection

Magic number Using a magic number, routers send messages to each

other with a different magic number. If you ever receive

your own magic number, the link is looped. A

configuration setting determines whether the link

should be taken down when looped.

Authentication PAP and CHAP Mostly used on dial links, PAP and CHAP can be used

to authenticate the device on the other end of the link.

Compression STAC and Predictor This is software compression.

Multilink support Multilink PPP Fragments of packets are load-balanced across multiple

links. This feature is more often used with dial. The

section “Multilink PPP,” later in the chapter, covers this

concept in greater detail.

Compression

Compression can be performed on LAPB, HDLC, and PPP point-to-point serial links. The goal

of compression is to reduce the number of bytes sent across the link. However, there is a price

to pay for compression—CPU cycles and possibly increased latency for the packets. The

following list summarizes the trade-offs when considering whether to use compression:

compression.

the output queue due to link congestion. With the compressed frames, however, the queue

is shorter.

So, in cases in which the leased lines are expensive or a faster line cannot be justified, then

compression can be desirable. However, care must be taken to avoid excessive CPU utilization.

Cisco recommends avoiding sustained CPU utilization exceeding between 40 and 65 percent,

depending on the platform.

Compression can be performed in software or in hardware. Any IOS router can perform LAPB,

HDLC, and PPP link compression in software; when software compression is used, CPU

utilization is impacted. For hardware compression, either a VIP2 card or a Compression Service

Adapter (CSA) on a 72xx or 75xx series router is required. When hardware compression is

performed, the CPU is not affected.

Several compression algorithms are available in the IOS to perform PPP compression: the

the algorithms are beyond the scope of the CCNA exam. However, the MPPC algorithm and

protocols can be used between a router and a PC on a dial connection when compression is

desired.

HDLC supports compression only with the STAC algorithm. LAPB supports STAC and

Predictor algorithms. Only PPP supports the MPPC algorithm. Table 8-7 summarizes the

support for each type.

PPP STAC, Predictor, MPPC

LAPB STAC, Predictor

HDLC STAC

Configuration for PPP and HDLC compression is very straightforward. Consider Figure 8-2

and Example 8-2. A pair of routers is using a serial link and is configured for PPP STAC

compression.

The configuration in Example 8-2, compared to a scenario without using compression, simply

requires that the interfaces on each end of the link have the same compression algorithm

have any particularly interesting numbers, mainly because of the lack of traffic in the network.

The 1-, 5-, and 10-minute averages are the transmit and receive compression ratios, which are

particularly useful for discovering whether the compression is effective. In fact, if most of the

! Seville’s Pertinent configuration:

!

interface Serial1

ip address 10.1.11.253 255.255.255.0

encapsulation ppp

compress stac

! Mars’s Pertinent configuration:

!

interface Serial1

ip address 10.1.11.1 255.255.255.0

encapsulation ppp

compress stac

!

Serial1

Software compression enabled

uncompressed bytes xmt/rcv 10710562/11376835

1 min avg ratio xmt/rcv 2.773/2.474

5 min avg ratio xmt/rcv 4.084/3.793

10 min avg ratio xmt/rcv 4.125/3.873

no bufs xmt 0 no bufs rcv 0

resets 0

CPU utilization for five seconds: 15%/15%; one minute: 27%; five minutes: 26%

PID QTy PC Runtime (ms) Invoked uSecs Stacks TTY Process

1 Csp 31C084C 4024 13359 301 720/1000 0 Load Meter

traffic being sent has been compressed already, then the compression ratios probably will be

low; Cisco recommends not using compression if this is the case.

Seville router for a few minutes to create the output. No true user traffic was generated for

Example 8-2. Watching for compression driving the CPU utilization too high will be important.

Cisco expects CCNAs to have an understanding of the cabling options for LAN and WAN

interfaces. For any of the point-to-point serial links or Frame Relay links in this chapter, all that

is needed on the router is a synchronous serial interface. Traditionally, this interface is a 60-pin

D-shell connector. This interface must then be cabled to a DSU/CSU, which in turn is connected

to the cable supplied by the service provider. Figure 8-3 shows a typical connection, with the

serial cabling options listed.

Table 8-8 summarizes the variety of standards that define the types of connectors and physical

signaling protocols used on WAN interfaces.

These cables provide connectivity to the external DSU/CSU, as seen in Figure 8-3. The

interface to the service provider is dependent on the type of connection; the connector could be

RJ-11, RJ-48, RJ-45, or possibly coax.

Some serial interfaces have an integrated DSU/CSU and do not require a cable of the types

shown in the figure. Depending on the expected type of line, a variety of physical interfaces are

used. These interfaces are the same as those used for external CSU/DSU devices.

The TIA is accredited by ANSI for development of telecommunications standards. Also, the

TIA works with the ITU on international standards. For more information on these standards

bodies, and for the opportunity to spend money to get copies of the standards, you can refer to

the Web sites www.tiaonline.org or www.itu.int.

Frame Relay provides delivery of variable-sized data frames to multiple WAN-connected sites.

Other than point-to-point links, Frame Relay is the WAN protocol most typically seen by

CCNAs. This section reviews the details of how Frame Relay accomplishes its goal of delivery

of frames to multiple WAN-connected sites.

Frame Relay is a well-chosen name for reminding you that it most closely relates to OSI

OSI Layer 2 equivalent header. For example, an Ethernet frame includes the Ethernet header/

trailer. Frame Relay uses addresses, but that addressing does not attempt to create a logical

address structure that could be used over a variety of media; therefore, Frame Relay addressing

is closer to OSI Layer 2 addressing standards and is considered to be a Layer 2 protocol. (Refer

to Chapter 3 for a review of OSI layers.)

The remainder of this section summarizes the Frame Relay protocol details expected to be on

the exam.

EIA/TIA 232 Telecommunications Industry Association 25

EIA/TIA 449 Telecommunications Industry Association 37

EIA/TIA 530 Telecommunications Industry Association 25

V.35 International Telecommunications Union 34

X.21 International Telecommunications Union 15

Frame Relay is a multiaccess network, which actually means that more than two devices can

attach to the medium. Multiaccess is the first and most obvious difference between Frame Relay

and leased lines. However, leased lines are used as the access link component of Frame Relay

networks. Consider Figure 8-4, which is a valuable resource for reviewing Frame Relay

concepts.

The access link between the router and the Frame Relay switch is a leased line. Both sites

represented in Figure 8-4 are connected to some nearby switch via a leased line. The service

provider interconnects their switches to provide connectivity.

Table 8-9 lists the components in Figure 8-4 and some associated terms.

Virtual circuit (VC) A VC is a logical concept that represents the path that frames travel

between DTEs. VCs are particularly useful when comparing Frame

Relay to leased physical circuits.

Permanent virtual circuit (PVC) A PVC is a VC that is predefined. A PVC can be equated to a

leased line in concept.

Switched virtual circuit (SVC) An SVC is a VC that is set up dynamically. An SVC can be equated

to a dial connection in concept.

Data terminal equipment (DTE) DTEs are also known as data-circuit termination equipment. For

example, routers are DTEs when connected to a Frame Relay

service from a telecommunication company.

Data communications equipment

(DCE)

Frame Relay switches are DCE devices.

Access link The access link is the leased line between DTE and DCE.

Access rate (AR) The access rate is the speed at which the access link is clocked.

This choice affects the price of the connection.

Committed information rate

(CIR)

The CIR is the rate at which the DTE can send data for an

individual VC, for which the provider commits to deliver that

amount of data. The provider will send any data in excess of this

rate for this VC if its network has capacity at the time. This choice

typically affects the price of each VC.

Burst rate The burst rate is the rate and length of time for which, for a

particular VC, the DTE can send faster than the CIR, and the

provider agrees to forward the data. This choice typically affects

the price of each VC.

Data link connection identifier

(DLCI)

A DLCI is a Frame Relay address and is used in Frame Relay

headers to identify the virtual circuit.

Forward explicit congestion

notification (FECN)

The FECN is the bit in the Frame Relay header that signals to

anyone receiving the frame (switches and DTEs) that congestion is

occurring in the same direction as the frame. Switches and DTEs

can react by slowing the rate by which data is sent in that direction.

Backward explicit congestion

notification (BECN)

The BECN is the bit in the Frame Relay header that signals to

anyone receiving the frame (switches and DTEs) that congestion is

occurring in the opposite (backward) direction as the frame.

Switches and DTEs can react by slowing the rate by which data is

sent in that direction.

Discard eligibility (DE) The DE is the bit in the Frame Relay header that signals to a switch

to, if frames must be discarded, please choose this frame to discard

instead of another frame without the DE bit set.

Nonbroadcast multiaccess

(NBMA)

NBMA refers to a network in which broadcasts are not supported,

but more than two devices can be connected.

Local Management Interface

(LMI)

LMI is the protocol used between a DCE and DTE to manage the

connection. Signaling messages for SVCs, PVC status messages,

and keepalives are all LMI messages.

Link access procedure—frame

mode bearer services (LAPF)

LAPF is the basic Frame Relay header and trailer; it includes

DLCI, FECN, BECN, and DE bits.

The definitions for Frame Relay are contained in documents from the ITU and from ANSI. The

Frame Relay Forum, a vendor consortium, also defines several Frame Relay specifications,

many of which have been added to the standards body’s documents. Table 8-10 lists the most

important of these specifications.

When first learning about Frame Relay, it’s often easy to confuse the LMI and encapsulation

used with Frame Relay; Cisco expects CCNAs to master the differences. The LMI is a

definition of the messages used between the DTE (for example, a router) and the DCE (for

example, the Frame Relay switch owned by the service provider). The encapsulation defines the

headers used, in addition to the basic Frame Relay header, for transporting the frame from DTE

to DTE. The switch and its connected router care about using the same LMI; the switch does

not care about the encapsulation.

The three LMI protocols available in the IOS are defined by Cisco, the ITU, and ANSI, and each

is slightly different and therefore not compatible with the other two. For instance, the Cisco and

ANSI Q.933-A LMIs call for use of DLCI 1023 for LMI messages, whereas T1.617-D calls for

DLCI 0. Some of the messages have different fields in their information elements. The DTE

simply needs to know which of the two (DLCI 1023 or DLCI 0) to use; it must match the one

used by the switch.

Using the same LMI type on a DTE and its connected DCE is required. LMI autosense is

supported by the IOS in version 11.2, so there is no need to code the LMI type. If desired, the

LMI type can be configured, but this disables the autosense feature. One LMI type exists per

serial interface because the LMI controls the single physical access link, which is connected to

a single switch.

message, which signals whether a PVC is up or down. Even though each PVC is predefined, its

status can change. As with all LMI messages, status enquiry messages flow between the switch

(DCE) and the DTE. For instance, a routing protocol reacts when a PVC is down, signaling that

routes over that PVC are lost.

Data link specifications, including

LAPF header/trailer

Q.922 Annex A T1.618

PVC management, LMI Q.933 Annex A T1.617 Annex D

SVC signaling Q.933 T1.617

Multiprotocol encapsulation

(originated in RFC 1490/2427)

Q.933 Annex E T1.617 Annex F

As with other data link protocols, Frame Relay defines a header and a trailer, with fields in each

that allow the switches and DTEs to successfully deliver the frame across the network.

Encapsulation refers to the process of using such headers and trailers to contain data supplied

by a higher layer. (Refer to Chapter 3 for additional concepts about encapsulation.)

Frame Relay uses a link access procedure—frame bearer services (LAPF) header, defined by

Q.922-A. The sparse LAPF framing provides error detection with an FCS in the trailer, as well

as the DLCI, DE, FECN, and BECN fields. Figure 8-5 diagrams the frame.

Cisco Proprietary cisco

ANSI T1.617 Annex D ansi

ITU Q.933 Annex A q933a

field in the header must define the type of header that begins the Information field. If Frame

Relay is using only the LAPF header, then DTEs (including routers) cannot support multiprotocol

traffic because there is no way to identify the type of protocol in the Information field.

(For more information about the concept of a Protocol Type field in data link headers, refer to

Chapter 3.)

Two solutions were created to compensate for the lack of a Protocol Type field. Cisco and three

other companies created an additional header, which comes first in the Information field shown

in Figure 8-5. It includes a 2-byte-long Protocol Type field, with values matching the same field

used for HDLC by Cisco. The second solution was defined in RFC 1490, “Multiprotocol

Interconnect over Frame Relay,” which was written to ensure multivendor interoperability

between Frame Relay DTEs. This solution includes use of a Protocol Type field and adds many

options, including support for bridged frames. ITU and ANSI later incorporated RFC 1490

headers into specs Q.933 Annex E and T.617 Annex F, respectively.

numbers, particularly the older 1490 because it is referred to often in documentation from Cisco

and other vendors.

VC can use a different encapsulation.

The data link connection identifier (DLCI) is the Frame Relay address. DLCIs, not DTEs, are

used to address virtual circuits. The logic and use of these addresses is very different from the

addresses seen for other protocols covered in this book. This difference is mainly due to the use

DLCIs are used to address the virtual circuit (VC); the logic behind the way routers use DLCI

values is subtle. For example, in Figure 8-7, Router A has a VC to both Router B and Router C;

Router A will need to use a different DLCI for each VC. The Frame Relay switches swap the

DLCI in transit. For example, Router A sends a frame with DLCI 41, expecting that it will be

delivered to Router B. Likewise, Router A sends frames with DLCI 42 when it wants the frame

to be delivered to Router C.

Frame Relay DLCIs are locally significant; this means that the addresses need to be unique only

on the local access link. A popular analogy that explains local addressing is that there can be

only a single street address of 2000 Pennsylvania Avenue, Washington, D.C., but there can be

a 2000 Pennsylvania Avenue in every town in the United States. Likewise, DLCIs must be

unique on each access link.

In Figure 8-7, as frames traverse Router A’s access link, they have either DLCI 41 or 42 in the

header, which meets the requirement that the addresses be unique on that access link. Likewise,

for all VCs terminating at Router B, unique DLCI values must be used for each one. Because

there is only one VC to Router B in Figure 8-7, there is no possibility of an overlap.

DLCIs are usually changed as the frames traverse the Frame Relay network. Consider the

revised network of Figure 8-8, in which DLCI 41 and 42 are still used by Router A on the access

link. Before the frames are forwarded on the access links to Router B and Router C, the Frame

Relay switches convert the DLCI to a value of 40 in each case. The DLCI values are chosen by

the service provider; the only requirement of local addressing can be summarized as follows:

With the convention shown in Figure 8-8, the DLCI values are different on each end of the VC.

However, the values shown in Figure 8-7 are also valid. In practice, the style shown in Figure

8-8 is the typical choice, but it seems to be a bit more confusing. But why? The answer lies in

The concept of global addressing is the reason that typical Frame Relay networks use a different

DLCI value on each end of the VC. Global addressing allows you to think of the Frame Relay

network like a LAN in terms of addressing concepts. Consider Figure 8-9, with the DLCI values

shown. In this figure, think of the DLCI values as an address for the DTE, which is similar to

how a unicast MAC address represents a LAN card.

On a LAN, if Host B wants to send a frame to Host A, Host B sends a frame with Host A’s MAC

address as the destination. Similarly, if Router B wants to send a frame to Router A, then Router

B (by the convention of global addressing) sends a frame with Router A’s global DLCI value in

the header. Likewise, Router C sends frames with DLCI 40 to reach Router A, by convention.

Router A sends frames with DLCI 41 to reach Router B, and with DLCI 42 to reach Router C,

again, by the convention of global addressing. Figure 8-9 shows the DLCIs used for global

addressing and the actual values placed into the Frame Relay headers for correct delivery across

the network. Table 8-12 summarizes the DLCIs used in the figure.

Figure 8-9 shows a frame being sent from Router A to Router B in one case, and to Router C in

the other case. As Router A sends a frame with DLCI 41, the Frame Relay switches send the

frame toward Router B. Before being sent on the access link to Router B, the final switch

changes the DLCI to 40 so that Router B knows who sent the frame. Similarly, Router A sends

a frame with DLCI 42, and it is received by Router C with DLCI 40.

In fact, the DLCIs used match the sample network with local addressing of Figure 8-8. In

essence:

convention of global addressing, planning is easier because the addressing appears similar

to LAN addressing.

DTE use its global address on their local access links.

A 41 B 40

A 42 C 40

B 40 A 41

C 40 A 42

One particularly convenient benefit of global addressing is that new sites can be added with

more convenience. Examine Figure 8-10, with Routers D and E added. The service provider

simply states that global DLCI 43 and 44 will be used for these two routers. If these two routers

also have only one PVC to Router A, all the DLCI planning is complete. You know that Router

D and Router E will use DLCI 40 to reach Router A, and that Router A will use DLCI 43 to

reach Router D and DLCI 44 to reach Router E.

The remaining samples in this chapter use global addressing in any planning diagrams, unless

otherwise stated. One practical way to determine whether the diagram lists the local DLCIs or

the global DLCI convention is this: If two VCs terminate at a DTE and a single DLCI is shown,

then it probably represents the global DLCI convention. If one DLCI is shown per VC, then it

is depicting local DLCI addressing.

As a CCNA, you will need to concern yourself with three key issues relating to Layer 3 flows

over Frame Relay:

The sections that follow cover these issues in depth.

Layer 3 Addressing

This section examines three cases of Layer 3 addressing when using Frame Relay. Figure 8-11

starts the first case with an illustration of a fully meshed Frame Relay network. In a full mesh,

each router has a direct connection to every other router, allowing the Frame Relay cloud to be

treated as one Layer 3 network. Figure 8-11 also shows IPX and IP addresses. The IPX and IP

addresses would be configured as subcommands on the serial interface. Table 8-13 summarizes

the addresses used in Figure 8-11.

The second case is a partially meshed Frame Relay network (see Figure 8-12). Because all four

routers do not have VCs to each other, each VC uses a different set of Layer 3 groups. Table

8-14 shows the IPX and IP addresses for the partially meshed Frame Relay network illustrated

in Figure 8-12. The addresses would be configured as subcommands on the serial interface.

255.255.255.0.)

Mayberry 199.1.1.1 199 199.0200.aaaa.aaaa

Mount Pilot 199.1.1.2 199 199.0200.bbbb.bbbb

Raleigh 199.1.1.3 199 199.0200.cccc.cccc

Subinterfaces allow the Atlanta router to have three IP addresses and three IPX addresses

associated with its serial 0 interface. Subinterfaces can treat each VC as though it were a pointto-

point serial link. Each of the three subinterfaces of serial 0 on Atlanta would be assigned a

different IP address and IPX address from the list in Table 8-14. Example configurations follow

in the next section of this chapter.

The third case of Layer 3 addressing is a hybrid between the first two illustrated in Figure 8-11

and Figure 8-12. Consider Figure 8-13, which shows a trio of routers with VCs between each

of them, as well as two other VCs to remote sites.

Atlanta 140.1.1.0/24 140.1.1.1 1 1.0200.aaaa.aaaa

Charlotte 140.1.1.0/24 140.1.1.2 1 1.0200.bbbb.bbbb

Atlanta 140.1.2.0/24 140.1.2.1 2 2.0200.aaaa.aaaa

Nashville 140.1.2.0/24 140.1.2.3 2 2.0200.cccc.cccc

Atlanta 140.1.3.0/24 140.1.3.1 3 3.0200.aaaa.aaaa

Boston 140.1.3.0/24 140.1.3.4 3 3.0200.dddd.dddd

Two options exist for Layer 3 addressing in this case. The first is to treat each VC as a separate

Layer 3 group; five subnets and five IPX networks would be needed for the Frame Relay

network. However, if Routers A, B, and C are considered alone, they meet the criteria that each

can send packets directly to each other, like a full mesh. This would allow Routers A, B, and C

to use one subnet and IPX network. The other two VCs—between A and D, and between A and

E—are treated as two separate Layer 3 groups. The result is a total of three subnets and three

IPX network numbers.

To accomplish either style of Layer 3 addressing in this third and final case, subinterfaces are

used. Point-to-point subinterfaces are used when a single VC is considered to be all that is in

the group. Multipoint subinterfaces are used among Routers A, B, and C in Figure 8-13. The

section “Frame Relay Configuration,” later in the chapter, provides full configurations for all

three cases illustrated in Figure 8-11, Figure 8-12, and Figure 8-13. Table 8-15 summarizes the

addresses and subinterfaces used.

A 140.1.1.0/24 140.1.1.1 1 1.0200.aaaa.aaaa Multipoint

B 140.1.1.0/24 140.1.1.2 1 1.0200.bbbb.bbbb Multipoint

C 140.1.1.0/24 140.1.1.3 1 1.0200.cccc.cccc Multipoint

A 140.1.2.0/24 140.1.2.1 2 2.0200.aaaa.aaaa Point-to-point

D 140.1.2.0/24 140.1.2.4 2 2.0200.dddd.dddd Point-to-point

A 140.1.3.0/24 140.1.3.1 3 3.0200.aaaa.aaaa Point-to-point

E 140.1.3.0/24 140.1.3.5 3 3.0200.eeee.eeee Point-to-point

Broadcast Handling

Broadcasts are not supported over a Frame Relay network. In other words, no capability exists

for a DTE to send a frame that is replicated and delivered across more than one VC. However,

routers need to send broadcasts for several features to work. In particular, routing protocol

updates and SAP updates are broadcasts.

The solution to the broadcast dilemma for Frame Relay has two parts. First, the IOS sends

copies of the broadcasts across each VC that you instruct it to. Of course, if there are only a few

VCs, this is not a big problem. However, if hundreds of VCs terminate in one router, then for

each broadcast, hundreds of copies could be sent. The IOS can be configured to limit the

amount of bandwidth that is used for these replicated broadcasts.

As the second part of the solution, the router tries to minimize the impact of the first part of the

solution. The router places these broadcasts into a different queue than user traffic so that the

user does not experience a large spike in delay each time some broadcast is replicated and sent

over each VC.

overhead, a short example can show the significance of this overhead. For example, if a router

knows 1000 routes, uses RIP, and has 50 VCs, then 1.072MB of RIP updates are sent every 30

seconds. That averages to 285kbps. (Math: 536-byte RIP packets, with 25 routes in each packet,

Knowing how to tell the router to forward these broadcasts out to each VC will be important on

the CCNA exam and is covered in the “Frame Relay Configuration” section later in this chapter.

The issues that relate to dealing with the volume of these updates is more likely a topic for the

CCNP and CCIE exams.

Split Horizon

Split horizon is useful for preventing routing loops by preventing a router from advertising a

route onto the same interface in which the route was learned. (Refer to Chapter 6, “Routing

Protocols,” for a full explanation.) However, split horizon could cause some problems with

Frame Relay. Thankfully, several configuration options help you deal with this issue. But first,

refer back to Figure 8-12. If split horizon was enabled on Atlanta, then Atlanta would learn

about 140.1.12.0/24 from Charlotte but would not advertise the route to 140.1.12.0/24 in its

updates to Nashville or Boston.

Split horizon logic applies to subinterfaces if they are configured. In other words, Atlanta uses

a different subinterface for each VC to the three remote sites. Split horizon is enabled on each

subinterface. However, because the routing updates from Charlotte are considered to enter

Atlanta via one subinterface, and because routing updates to Nashville and Boston exit two

other subinterfaces, then advertising 140.1.12.0/24 to Nashville and Boston is allowed.

Split horizon would be a problem in Figure 8-11, however. When all three VCs are up, no

problem exists. However, if the VC from Mount Pilot to Raleigh went down, then split horizon

on Mayberry would be harmful. Mount Pilot will advertise routes to 199.1.11.0, and Mayberry

will receive that information in a routing update. However, because no subinterfaces are used,

Mayberry would not advertise 199.1.11.0 to Raleigh with split horizon enabled.

The multipoint subinterfaces in Figure 8-13 would experience the same problems for the same

reasons described for Figure 8-11.

The solution to the problem is to disable split horizon when not using subinterfaces or when

using multipoint subinterfaces. The IOS defaults to disable split horizon on Frame Relay

interfaces in all cases except for point-to-point subinterfaces. Table 8-16 summarizes these

settings and shows that the current default settings work around the split horizon issues

described in the last few paragraphs.

interface configuration command disables split horizon on that interface.

Frame Relay mapping is a topic you could ignore and still make Frame Relay work in a Cisco

router. However, Cisco requires that CCNAs understand Frame Relay address mapping, for two

main reasons. First, static mapping is just the kind of nasty question that is likely to crop up on

the exam. Second, understanding mapping offers a good opportunity to review the concepts

behind routing. As with most features implemented dynamically and by default, you can ignore

mapping most of the time.

Mapping is required when using some other data links, but not all. For example, with IP, the

ARP process dynamically builds a mapping between an IP address and a LAN address. This

section discusses the basics behind why mapping is needed for LAN connections and Frame

Relay, with a focus on Frame Relay.

Consider Figure 8-14 and the routing table that follows (Table 8-17).

No subinterfaces Disabled

Point-to-point subinterfaces Enabled

Multipoint subinterfaces Disabled

The core routing logic must be considered to fully appreciate mapping. Router A receives an

Ethernet frame from some host and strips the Ethernet header (and trailer). The destination IP

address of the packet is compared to the IP routing table, and an entry is matched. The matched

routing table entry tells the router to route the packet out serial 0 to 10.1.2.2 next (Router B’s

S1 IP address). Router A builds the HDLC header/trailer and sends the frame.

The fact that Router B’s IP address on the common serial link is 10.1.2.2 has nothing to do with

the contents of the HDLC header and trailer; Router B’s IP address is immaterial in this case.

If Router A can get the frame across the link, there is only one possible recipient—Router B.

So, no mapping is needed between the Layer 3 address and the HDLC address on a point-topoint

link.

Now consider a diagram with Ethernet between the routers (see Figure 8-15) and the routing

table that follows (see Table 8-18).

10.1.3.0 serial 0 10.1.2.2

Again consider the core routing logic. Router A receives an Ethernet frame from some host and

strips the Ethernet header (and trailer). Router A decides to route the packet out Ethernet 0 to

the next router, 10.1.2.2 (Router B’s E1 IP address). Router A builds the new Ethernet header/

trailer and sends the frame.

Router A builds the Ethernet header based on the next-hop router’s IP address—namely,

10.1.2.2 (Router B’s E1 IP address). The destination Ethernet address in the header built by

Router A is Router B’s E1 address. Router A learns this information dynamically using the

IP ARP protocol. Similarly, with IPX routing, the next-hop router’s IPX address has the

corresponding LAN address embedded in the IPX address. (With other Layer 3 protocols, there

are other processes on LANs for learning the corresponding LAN address.) The information

learned by IP ARP in this case is the information that maps the next-hop IP address to the LAN

10.1.3.0 Ethernet 0 10.1.2.2

Now consider the Frame Relay network in Figure 8-16, along with the routing table in

Table 8-19.

Again consider the core routing logic. Router A receives an Ethernet frame from some host and

strips the Ethernet header (and trailer). It decides to route the packet out serial 0 to the next

router, 10.1.2.2 (Router B’s S0 IP address). Router A builds the Frame Relay header/trailer and

sends the frame.

Although Router A knows the serial interfaces out which to forward the frame, Router A does

not know the correct DLCI yet. A mapping is needed in Router A to correlate 10.1.2.2 (Router

B) and the DLCI Router A used to reach Router B. However, the same IP ARP used on LANs

10.1.3.0 Serial 0 10.1.2.2

will not work on Frame Relay because there is no support for broadcasts. Therefore, ARP

cannot be used to discover that DLCI.

Two solutions exist by which Router A can learn the mapping between Router B’s IP address

and DLCI. One uses a statically configured mapping, and the other uses a dynamic process

Table 8-20 lists the IP and IPX addresses of the three routers in Figure 8-16.

Example 8-3 lists the static Frame Relay map for the three routers in Figure 8-16. The DLCIs

in Table 8-20 are the same as those used in Figure 8-16.

command for Router A referencing 10.1.2.2 would be used for packets originating from Gary

and going to Brice. Conversely, a packet sent back from Brice to Gary would cause Router B

to use its map statement referring to Router A’s IP address of 10.1.2.1. Mapping is needed for

A 40 10.1.2.1 2.0200.aaaa.aaaa

B 41 10.1.2.2 2.0200.bbbb.bbbb

C 42 10.1.2.3 2.0200.cccc.cccc

Router A:

interface serial 0

frame-relay map ip 10.1.2.2 41 broadcast

frame-relay map ipx 2.0200.bbbb.bbbb 41 broadcast

frame-relay map ip 10.1.2.3 42 broadcast

frame-relay map ipx 2.0200.cccc.cccc 42 broadcast

Router B:

interface serial 0

frame-relay map ip 10.1.2.1 40 broadcast

frame-relay map ipx 2.0200.aaaa.aaaa 40 broadcast

frame-relay map ip 10.1.2.3 42 broadcast

frame-relay map ipx 2.0200.cccc.cccc 42 broadcast

Router C:

interface serial 0

frame-relay map ip 10.1.2.1 40 broadcast

frame-relay map ipx 2.0200.aaaa.aaaa 40 broadcast

frame-relay map ip 10.1.2.2 41 broadcast

frame-relay map ipx 2.0200.bbbb.bbbb 41 broadcast

each next-hop Layer 3 address for each Layer 3 protocol being routed. Even with a network this

small, the configuration process can be laborious. A better solution is a dynamic protocol called

Inverse ARP.

Inverse ARP acquires mapping information in a manner opposite of IP ARP, but the information

that maps the Layer 3 and Layer 2 addresses is still found. Inverse ARP is basic; after the VC

is up, each DTE announces its network layer address to the DTE on the other end of the VC.

(Inverse ARP is enabled by default at IOS 11.2 and beyond, unless point-to-point subinterfaces

are used.) Table 8-21 summarizes what would occur in the network in Figure 8-16.

commands are needed. All the necessary mapping information is learned dynamically.

Inverse ARP is enabled by default if no subinterfaces are in use. Inverse ARP is also on by

default for multipoint subinterfaces. However, Inverse ARP is not enabled on point-to-point

subinterfaces because point-to-point subinterfaces behave like a true point-to-point line in

regard to routing; if the packet needs to be sent out a point-to-point subinterface, then there is

only one possible next router and only one DLCI in use. So, Inverse ARP is not needed with

point-to-point subinterfaces.

A 41 B 40 I am 10.1.2.1.

A 41 B 40 I am 2.0200.aaaa.aaaa.

A 42 C 40 I am 10.1.2.1.

A 42 C 40 I am 2.0200.aaaa.aaaa.

B 40 A 41 I am 10.1.2.2.

B 40 A 41 I am 2.0200.bbbb.bbbb.

B 42 C 41 I am 10.1.2.2.

B 42 C 41 I am 2.0200.bbbb.bbbb.

C 40 A 42 I am 10.1.2.3.

C 40 A 42 I am 2.0200.cccc.cccc.

C 41 B 42 I am 10.1.2.3.

C 41 B 42 I am 2.0200.cccc.cccc.

Now that the text has covered all the pertinent concepts, it’s time to review the basic

initialization process on a Frame Relay network. First, the LMI sends a status enquiry notifying

the DTE when the VC is up. After this process, Inverse ARP frames are sent by the routers in

each direction for each Layer 3 protocol configured for the VC. Packets can be forwarded at this

point. Of course, routing protocols will send their initial updates, routes will be learned, and

only then will end-user traffic be able to flow. Figure 8-17 outlines the process.

LMI status messages inform the routers when the PVC first comes up. Because Inverse ARP

frames could not be delivered until the VC was up but can be delivered now, the Inverse ARP

announcements declare the Layer 3 addresses. Unless keepalives have been turned off, both the

switch and the router expect to send and receive periodic status and status enquiry messages,

respectively.

Compression can be performed on frames sent out a Frame Relay interface. Two general types

of compression are allowed: payload compression and TCP header compression. With TCP

header compression, only the TCP header is compressed; all other headers and data remain

uncompressed. As its name suggests, payload compression compresses the payload of the

Frame Relay frame.

Regardless of which type of compression is used, the Frame Relay header itself cannot be

compressed. If the Frame Relay header were compressed, the intermediate Frame Relay

switches would not be capable of forwarding the frames.

Payload Compression

Figure 8-18 provides the basic concept behind payload compression and shows what is

compressed:

If payload compression was used on the VC between Albuquerque and Yosemite, the Frame

Relay header would remain intact, but the packet (the payload) would be compressed before

transmission and uncompressed upon reception.

Two types of payload compression are available. The first historically used the STAC algorithm,

which predicts the values that follow the earlier bytes in the compressed payload. The algorithm

did not follow any standard. That process works fine, but it can run only in software—no

support for this algorithm exists for Frame Relay on the Versatile Interface Processor (VIP) or

the Compression Service Adapter (CSA).

The second payload compression option is to use the Frame Relay Forum standard compression.

The FRF.9 Implementation Agreement (IA) defines the details and is available free

from the Frame Relay Forum if you would like to see more details (http://www.frforum.com).

The FRF.9 document calls for the use of the STAC algorithm as well, but with some details that

differ from the original Cisco protocol. Cisco has added support for the FRF.9 payload

compression into the CSA and the VIP2. Even if compressing in software, Cisco recommends

using the FRF.9 payload compression over the original Cisco implementation of STAC.

TCP Header Compression

TCP header compression is seemingly unnecessary, given that payload compression is

available. Why bother just compressing the TCP header? Well, compression algorithms can be

optimized if the data to be compressed has a known format and a tendency toward using

particular values. The 40-byte TCP header can be reduced to an average of 10 bytes. One of the

biggest reasons that TCP header compression can be beneficial is that it takes little processing

because of the efficient compression algorithm. Also, if a large amount of traffic is made up of

small IP packets with TCP, then the compression ratio can be more than 2-to-1. For instance, in

the “old” days when Telnet was used on a frequent basis by end users, many IP packets were

sent with the IP header, the TCP header, and just a few bytes of data typed by the user. So,

efficient compression with the possibility of more than 2-to-1 compression ratio is a very

reasonable option. If most of the IP packets using TCP in a network are large, then the

compression ratio will not be very high, making TCP header compression a less-attractive

option.

Configuration of Frame Relay in a Cisco router is relatively straightforward if all the defaults

are taken. Cisco expects CCNAs to know several of the optional parameters that are shown in

this section as well.

Hands-on experience is the best way to fully learn the details of configuration. In lieu of that,

this section lists commands, provides examples, and points out tricky features. Table 8-22 and

Table 8-23 summarize the more popular commands used for Frame Relay configuration and

verification. Two configuration samples follow. The Cisco IOS documentation is an excellent

version of the class.

Interface Defines Frame Relay

encapsulation that is used rather

than HDLC, PPP, and so on.

Interface Defines the type of LMI

messages sent to the switch.

of the interface. Bandwidth is

used by some routing protocols

to influence the metric.

Determining when and how to use subinterfaces for Frame Relay configuration is the most

difficult part of the configuration. Subinterfaces are never required; subinterfaces can be used

in any Frame Relay configuration, and most sites tend to use them. Some general guidelines

when using subinterfaces include the following:

horizon issues by treating each subinterface as a separate interface.

the number of network-layer groups (for example, IP subnets) that are used.

Interface Statically defines a mapping

between a network layer address

and a DLCI.

LMI status enquiry messages

are sent and expected.

Global Creates a subinterface, or

references a previously created

subinterface.

Interface Defines a DLCI used for a VC to

another DTE.

Interface subcommand Defines payload compression on

point-to-point subinterfaces.

Shows PVC status, mapping (dynamic and static), and LMI status.

typically chosen to maintain consistency with other Frame Relay networks elsewhere in

the network that are not fully meshed. This choice requires a larger number of IP subnets

to be used.

VCs between each other but the other 10 do not), a multipoint subinterface can be used

for the fully meshed portion and point-to-point subinterfaces can be used for the rest.

VCs between each other but the other 10 do not), using only point-to-point subinterfaces

is another option. This requires more IP subnets and IPX networks than when using a

multipoint subinterface for the fully meshed portion of the network.

consistency.

Correlating the DLCI(s) to their subinterfaces is required when using either type of

subinterface. LMI enquiry messages notify the router that PVCs are active; the router then

needs to know which subinterface uses the DLCI. An individual DLCI is used by only one

subinterface. For a point-to-point subinterface, only one DLCI is used; for multipoint, many

DLCIs are used.

Three samples of Layer 3 addressing were used earlier in the chapter, with the networks

diagrammed in Figure 8-11, Figure 8-12, and Figure 8-13. The configurations matching those

networks and addresses are shown next.

The first sample network (based on the environment depicted in Figure 8-11) does not use

subinterfaces. Example 8-4, Example 8-5, and Example 8-6 show the configuration for this

network.

ipx routing 0200.aaaa.aaaa

!

interface serial0

encapsulation frame-relay

ip address 199.1.1.1 255.255.255.0

ipx network 199

!

interface ethernet 0

ip address 199.1.10.1 255.255.255.0

ipx network 1

!

router igrp 1

network 199.1.1.0

network 199.1.10.0

The configuration is simple in comparison with the protocol concepts. All default settings (IOS

version 12.0) were used and are as follows:

that the VCs are up has been received.

In some cases, the default values will not be appropriate. For instance, if one router was not a

Cisco router and did not support Cisco encapsulation, then IETF encapsulation would be

required. For the purpose of showing an alternate configuration, suppose that the following

requirements were added:

ipx routing 0200.bbbb.bbbb

!

interface serial0

encapsulation frame-relay

ip address 199.1.1.2 255.255.255.0

ipx network 199

!

interface ethernet 0

ip address 199.1.11.2 255.255.255.0

ipx network 2

!

router igrp 1

network 199.1.1.0

network 199.1.11.0

ipx routing 0200.cccc.cccc

!

interface serial0

encapsulation frame-relay

ip address 199.1.1.3 255.255.255.0

ipx network 199

!

interface ethernet 0

ip address 199.1.12.3 255.255.255.0

ipx network 3

!

router igrp 1

network 199.1.1.0

network 199.1.12.0

Example 8-7 and Example 8-8 show the changes that would be made to Mayberry and Raleigh.

The encapsulation was changed in two different ways. Raleigh changed its encapsulation for

change because only one of the two VCs to Mayberry was directed to use IETF encapsulation.

of cisco.

The LMI configuration in Mayberry would have been fine without any changes because

Mayberry is forced to use ANSI because this command disables autonegotiation of the LMI

type.

Mayberry’s for the VC from Mount Pilot to Raleigh so that VC will use IETF encapsulation.

This change is not shown in an example.

The second sample network (based on the environment depicted in Figure 8-12) uses point-topoint

subinterfaces. Example 8-9, Example 8-10, Example 8-11, and Example 8-12 show the

configuration for this network.

ipx routing 0200.aaaa.aaaa

!

interface serial0

encapsulation frame-relay

frame-relay lmi-type ansi

frame-relay interface-dlci 42 ietf

ip address 199.1.1.1 255.255.255.0

ipx network 199

! rest of configuration unchanged from Example 8-4.

ipx routing 0200.cccc.cccc

!

interface serial0

encapsulation frame-relay ietf

ip address 199.1.1.3 255.255.255.0

ipx network 199

!

! rest of configuration unchanged from example 8-6.

ipx routing 0200.aaaa.aaaa

!

interface serial0

encapsulation frame-relay

!

interface serial 0.1 point-to-point

ip address 140.1.1.1 255.255.255.0

ipx network 1

frame-relay interface-dlci 52

!

interface serial 0.2 point-to-point

ip address 140.1.2.1 255.255.255.0

ipx network 2

frame-relay interface-dlci 53

!

interface serial 0.3 point-to-point

ip address 140.1.3.1 255.255.255.0

ipx network 3

frame-relay interface-dlci 54

!

interface ethernet 0

ip address 140.1.11.1 255.255.255.0

ipx network 11

ipx routing 0200.bbbb.bbbb

!

interface serial0

encapsulation frame-relay

!

interface serial 0.1 point-to-point

ip address 140.1.1.2 255.255.255.0

ipx network 1

frame-relay interface-dlci 51

!

interface ethernet 0

ip address 140.1.12.2 255.255.255.0

ipx network 12

ipx routing 0200.cccc.cccc

!

interface serial0

encapsulation frame-relay

!

interface serial 0.2 point-to-point

ip address 140.1.2.3 255.255.255.0

ipx network 2

frame-relay interface-dlci 51

!

Point-to-point subinterfaces were used in this configuration because the network is not fully

because the status messages come into the physical interface stating that a VC with a particular

DLCI is up; the IOS then needs to associate that VC with a subinterface.

The subinterface numbers in the example configuration happen to match on either end of the

VCs. For example, subinterface 2 was used in Atlanta for the PVC to Nashville; Nashville also

uses subinterface 2. There is no requirement that the subinterface numbers be the same.

Example 8-13 shows the output from the most popular IOS Frame Relay EXEC commands for

monitoring Frame Relay, as issued on router Atlanta.

interface ethernet 0

ip address 140.1.13.3 255.255.255.0

ipx network 13

ipx routing 0200.dddd.dddd

!

interface serial0

encapsulation frame-relay

!

interface serial 0.3 point-to-point

ip address 140.1.3.4 255.255.255.0

ipx network 3

frame-relay interface-dlci 51

!

interface ethernet 0

ip address 140.1.14.4 255.255.255.0

ipx network 14

PVC Statistics for interface Serial0 (Frame Relay DTE)

DLCI = 52, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

input pkts 843 output pkts 876 in bytes 122723

out bytes 134431 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 876 out bcast bytes 134431

pvc create time 05:20:10, last time pvc status changed 05:19:31

--More--

DLCI = 53, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.2

input pkts 0 output pkts 875 in bytes 0

out bytes 142417 dropped pkts 0 in FECN pkts 0

The counters for each VC, including increments in the FECN and BECN counters, can be

particularly useful. Likewise, comparing the packets/bytes sent versus what is received on the

other end of the VC is also quite useful because it reflects the number of packets/bytes lost

inside the Frame Relay cloud. Also, seeing a PVC as active means that it is usable (as opposed

to inactive), which is a great place to start when troubleshooting. All this information can be

better gathered by an SNMP manager.

mapping. A DLCI is listed in each entry, but no mention of corresponding Layer 3 addresses

is made. However, because the subinterfaces are point-to-point, this omission by IOS is

intended—the subinterface acts like a point-to-point link, with two participants. Mapping is

needed only when more than two devices are attached to the link. (See the section “How

Address Mapping Works,” earlier in this chapter, for more information.)

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 875 out bcast bytes 142417

pvc create time 05:19:51, last time pvc status changed 04:55:41

--More--

DLCI = 54, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.3

input pkts 10 output pkts 877 in bytes 1274

out bytes 142069 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 877 out bcast bytes 142069

pvc create time 05:19:52, last time pvc status changed 05:17:42

Serial0.3 (up): point-to-point dlci, dlci 54(0x36,0xC60), broadcast

status defined, active

Serial0.2 (up): point-to-point dlci, dlci 53(0x35,0xC50), broadcast

status defined, active

Serial0.1 (up): point-to-point dlci, dlci 52(0x34,0xC40), broadcast

status defined, active

Frame Relay LMI debugging is on

Displaying all Frame Relay LMI data

Serial0(out): StEnq, myseq 163, yourseen 161, DTE up

datagramstart = 0x45AED8, datagramsize = 13

FR encap = 0xFCF10309

00 75 01 01 01 03 02 A3 A1

Serial0(in): Status, myseq 163

RT IE 1, length 1, type 1

KA IE 3, length 2, yourseq 162, myseq 163

enquiries. The status message is sent by the switch, whereas the status enquiry is sent by the

rather it causes the router to send LMI messages to the switch. It also causes the router to expect

LMI messages from the switch.

The Frame Relay networks built by CCNAs most likely will include both point-to-point and

multipoint subinterfaces. This last sample network (based on the environment depicted in

Figure 8-13) uses both types of subinterfaces. Example 8-14, Example 8-15, Example 8-16,

Example 8-17, and Example 8-18 show the configuration for this network.

hostname RouterA

!

ipx routing 0200.aaaa.aaaa

!

interface serial0

encapsulation frame-relay

!

interface serial 0.1 multipoint

ip address 140.1.1.1 255.255.255.0

ipx network 1

frame-relay interface-dlci 502

frame-relay interface-dlci 503

!

interface serial 0.2 point-to-point

ip address 140.1.2.1 255.255.255.0

ipx network 2

frame-relay interface-dlci 504

!

interface serial 0.3 point-to-point

ip address 140.1.3.1 255.255.255.0

ipx network 3

frame-relay interface-dlci 505

!

interface ethernet 0

ip address 140.1.11.1 255.255.255.0

ipx network 11

hostname RouterB

!

ipx routing 0200.bbbb.bbbb

!

interface serial0

encapsulation frame-relay

!

interface serial 0.1 multipoint

ip address 140.1.1.2 255.255.255.0

ipx network 1

frame-relay interface-dlci 501

frame-relay interface-dlci 503

!

interface ethernet 0

ip address 140.1.12.2 255.255.255.0

ipx network 12

hostname RouterC

!

ipx routing 0200.cccc.cccc

!

interface serial0

encapsulation frame-relay

!

interface serial 0.1 multipoint

ip address 140.1.1.3 255.255.255.0

ipx network 1

frame-relay interface-dlci 501

frame-relay interface-dlci 502

!

interface ethernet 0

ip address 140.1.13.3 255.255.255.0

ipx network 13

hostname RouterD

!

ipx routing 0200.dddd.dddd

!

interface serial0

encapsulation frame-relay

!

interface serial 0.1 point-to-point

ip address 140.1.2.4 255.255.255.0

ipx network 2

frame-relay interface-dlci 501

!

interface ethernet 0

ip address 140.1.14.4 255.255.255.0

ipx network 14

No mapping statements were required for the configuration in Example 8-14 through Example

8-18 because Inverse ARP is enabled on the multipoint subinterfaces by default. The point-topoint

subinterfaces do not require mapping statements because after the outgoing subinterface

is identified, there is only one possible router to which to forward the frame.

Router A is the only router using both multipoint and point-to-point subinterfaces. On Router

A’s serial 0.1 interface, multipoint is in use, with DLCIs for Router B and Router C listed. On

Router A’s other two subinterfaces, which are point-to-point, only a single DLCI needs to be

subinterface because only one VC is allowed. Otherwise, the configurations between the two

types are similar.

insight into Inverse ARP operation.

hostname RouterE

!

ipx routing 0200.eeee.eeee

!

interface serial0

encapsulation frame-relay

!

interface serial 0.1 point-to-point

ip address 140.1.3.5 255.255.255.0

ipx network 3

frame-relay interface-dlci 501

!

interface ethernet 0

ip address 140.1.15.5 255.255.255.0

ipx network 15

Serial0.10 (up): ip 140.1.1.1 dlci 501(0x1F5,0x7C50), dynamic,

broadcast,, status defined, active

Serial0.10 (up): ip 140.1.1.2 dlci 502(0x1F6,0x7C60), dynamic,

broadcast,, status defined, active

Serial0.10 (up): ipx 1.0200.aaaa.aaaa dlci 501(0x1F5,0x7C50), dynamic,

broadcast,, status defined, active

Serial0.10 (up): ipx 1.0200.bbbb.bbbb dlci 502(0x1F6,0x7C60), dynamic,

broadcast,, status defined, active

Frame Relay events debugging is on

Enter configuration commands, one per line. End with Ctrl-Z.

routers’ IP and IPX addresses correlate to the DLCIs. This is possible because the Inverse ARP

messages flow over a VC; the Inverse ARP contains a Layer 3 protocol type and address. The

DLCI correlates to a subinterface based on configuration.

One easy exercise is to search for the hex version of the IP and IPX addresses in the output.

These addresses have been highlighted in Example 8-19. For example, the first 3 bytes of

140.1.1.0 are 8C 01 01 in hexadecimal; this field happens to start on the left side of the output,

so it is easy to recognize visually. The IPX address should be much easier to recognize because

it is already in hexadecimal format in the configuration.

RouterC#

Serial0.1: FR ARP input

Serial0.1: FR ARP input

Serial0.1: FR ARP input

datagramstart = 0xE42E58, datagramsize = 30

FR encap = 0x7C510300

80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00

8C 01 01 01 7C 51 8C 01 01 03

datagramstart = 0xE427A0, datagramsize = 46

FR encap = 0x7C510300

80 00 00 00 08 06 00 0F 81 37 02 0A 00 09 00 00

00 00 00 01 02 00 AA AA AA AA 7C 51 00 00 00 01

02 00 CC CC CC CC 1B 99 D0 CC

datagramstart = 0xE420E8, datagramsize = 30

FR encap = 0x7C610300

80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00

8C 01 01 02 7C 61 8C 01 01 03

Serial0.1: FR ARP input

datagramstart = 0xE47188, datagramsize = 46

FR encap = 0x7C610300

80 00 00 00 08 06 00 0F 81 37 02 0A 00 09 00 00

00 00 00 01 02 00 BB BB BB BB 7C 61 00 00 00 01

02 00 CC CC CC CC 1B 99 D0 CC

processing is required and how many messages are generated, it is possible to significantly

degrade performance and possibly crash the router. This is a result of memory and processing

used to look for the requested information and to process the messages. You might want to first

statements would have been required on Router A (see Example 8-20). Similar commands

would have been required on Routers B and C.

The configuration of the two styles of Frame Relay payload compression are very similar. The

details of the configuration are different, however, when using a point-to-point subinterface as

opposed to a multipoint subinterface. Examine the configuration on the Albuquerque and

Yosemite routers, which each use a point-to-point subinterface for the PVC between the two.

Figure 8-19 and Examples 8-21 and 8-22 display the network and the configuration.

frame-relay map ip 140.1.1.2 502 broadcast

frame-relay map ip 140.1.1.3 503 broadcast

frame-relay map ipx 1.0200.bbbb.bbbb 502 broadcast

frame-relay map ipx 1.0200.cccc.cccc 503 broadcast

hostname Albuquerque

!

no ip domain-lookup

ipx routing 0200.aaaa.aaaa

!

interface Serial0

no ip address

encapsulation frame-relay IETF

frame-relay lmi-type cisco

!

interface Serial0.1 point-to-point

ip address 10.1.4.251 255.255.255.0

no ip directed-broadcast

ipx network 4

frame-relay interface-dlci 902 IETF

frame-relay payload-compression packet-by-packet

!

interface Serial0.2 point-to-point

ip address 10.1.6.251 255.255.255.0

no ip directed-broadcast

ipx network 6

frame-relay interface-dlci 903

!

interface Serial1

no ip address

no ip directed-broadcast

shutdown

!

interface Ethernet0

ip address 10.1.1.251 255.255.255.0

ipx network 1

!

router igrp 5

network 10.0.0.0

hostname Yosemite

!

no ip domain-lookup

ipx routing 0200.bbbb.bbbb

!

interface Serial0

no ip address

encapsulation frame-relay IETF

frame-relay lmi-type cisco

!

interface Serial0.1 point-to-point

ip address 10.1.4.252 255.255.255.0

no ip directed-broadcast

ipx network 4

frame-relay interface-dlci 901 IETF

All that is necessary on the point-to-point subinterfaces to enable the Cisco STAC payload

subcommand on the subinterface on each end of the VC. Payload compression is enabled on a

per-VC basis, but because the subinterface is a point-to-point subinterface, only one VC is

allowed on the interface—that VC is implied as the one on which to perform compression.

seem to imply that other options besides stac are available, but there are no other options. In

to the FRF.9 standard.

addresses. Examples 8-23 and 8-24 show a similar configuration for the network in Figure

8-20, except that the routers are now using multipoint subinterfaces. (Some unrelated

configuration details are not shown in these examples.)

frame-relay payload-compression packet-by-packet

!

interface Serial0.2 point-to-point

ip address 10.1.5.252 255.255.255.0

ipx network 5

frame-relay interface-dlci 903

!

interface Serial1

no ip address

shutdown

!

interface Ethernet0

ip address 10.1.2.252 255.255.255.0

ipx network 2

!

router igrp 5

network 10.0.0.0

hostname Albuquerque

!

interface Serial0

no ip address

encapsulation frame-relay IETF

frame-relay lmi-type cisco

!

interface Serial0.1 multipoint

ip address 10.1.7.251 255.255.255.0

no ip directed-broadcast

ipx network 7

frame-relay interface-dlci 902 IETF

frame-relay interface-dlci 903 IETF

frame-relay map ip 10.1.7.252 902 payload-compress frf9 stac

hostname Yosemite

!

interface Serial0

no ip address

encapsulation frame-relay IETF

frame-relay lmi-type cisco

!

interface Serial0.1 multipoint

ip address 10.1.7.252 255.255.255.0

no ip directed-broadcast

ipx network 7

frame-relay interface-dlci 901 IETF

frame-relay interface-dlci 903 IETF

frame-relay map ip 10.1.7.251 901 payload-compress frf9 stac

All that is necessary on the multipoint subinterfaces on Yosemite to enable FRF.9 compression

on just the VC to Albuquerque is one interface subcommand on each of the two routers. The

Yosemite tells the IOS for IP packets header out DLCI 901 to enable payload compression

and use the FRF.9 style of configuration. A similar command is used on Albuquerque—if

compression is disabled on only one end of the VC, or if a different type of compression is

enabled, then no packets will flow across the link.

The goal of this section is to summarize the details and to clarify complex features of ISDN and

related IOS functions. The CCNA exam focuses on Basic Rate Interface (BRI) functions, and

the CCNP and CCIE cover all of ISDN, including PRI.

Two types of ISDN interfaces are focused on in IOS documentation: Basic Rate Interface (BRI)

and Primary Rate Interface (PRI). Both BRI and PRI provide multiple digital bearer channels

over which temporary connections can be made and data can be sent. The result is digital dial

access to multiple sites concurrently. Table 8-24 summarizes the features of BRI and PRI.

Bearer channels (B channels) are used to transport data. B channels are called bearer channels

because they bear the burden of transporting the data. B channels operate at up to 64kbps,

although the speed might be lower depending on the service provider. The section “ISDN

Configuration,” later in the chapter, discusses how to configure the correct speed for the bearer

channels. D channels are used for signaling.

BRI 2 1 (16kbps)

PRI (T/1) 23 1 (64kbps)

PRI (E/1) 30 1 (64kbps)

Coverage of ISDN protocols and their specifications on the CCNA exam poses a particularly

difficult problem for the CCNA candidate. The International Telecommunications Union (ITU)

defines the most well-known specifications for ISDN, but there are far more specifications than

anyone would want to try to memorize. The problem is choosing what to memorize and what

to ignore. My personal philosophy is that standards information is best kept in a book rather

than in my own memory. With Cisco’s emphasis on proving your hands-on skills using the

CCNA and CCNP exams, hopefully a de-emphasis on memorizing standards will be a

convenient side effect. However, these standards are fair game for the exam.

The characterizations of several key protocols made by the Cisco ICND course are important

for the exam. Table 8-25 is directly quoted from the ICND course. Take care to learn the

information in the Issue column—knowing what each series of specifications is about will be

useful.

The OSI layers correlating to the different ISDN specifications are also mentioned in both the

ITM and the ICND CCNA prerequisite courses. Memorizing the specifications in Table 8-26

and the OSI layer each specification matches is also useful.

Telephone network and ISDN E-series E.163: international telephone

numbering plan

E.164: international ISDN addressing

ISDN concepts, aspects, and

interfaces

I-series I.100 series: concepts, structures,

terminology

I.400 series: User-Network Interfaces

(UNI)

Switching and signaling Q-series Q.921: LAPD

Q.931: ISDN network layer

1 ITU-T I.430

ITU-T I.431

Defines connectors, encoding, framing,

and reference points

2 ITU-T I.440

ITU-T I.4411

ITU-T Q.920

ITU-T Q.921

Defines the LAPD protocol used on the

D channel to encapsulate signaling

requests

A tool to help you remember the specifications and layers is that the second digit in the Q-series

matches the OSI layer. For example, in ITU-T Q.920, the second digit, 2, corresponds to OSI

Layer 2. In the I-series, the second digit of the specification numbers is two more than the

corresponding OSI layer. For example, I.430, with the second digit of value 3, defines OSI

Layer 1 equivalent functions.

LAPD is used to deliver signaling messages to the ISDN switch—for example, a call setup

message. Figure 8-21 shows the use of LAPD versus PPP on B channels.

3 ITU-T I.450

ITU-T I.451

ITU-T Q.930

ITU-T Q.931

Defines signaling messages—for

example, call setup and takedown

messages

The call is established through the service provider network; PPP is used as the data link

protocol on the B channel from end to end. LAPD is used between the router and the ISDN

switch at each local central office (CO) and remains up so that new signaling messages can be

sent and received. Because the signals are sent outside the channel used for data, this is called

The BRI encodes bits at 192 kbps, with most of the bandwidth (144 kbps) being used for the

two B channels and the D channel. The additional bits are used for framing.

1-57870-102-3.)

The service profile identifier (SPID) used in signaling is important to the configuration of ISDN

and is likely to be mentioned on the exam. The SPID works like an ISDN phone number—in

SPIDs. If a router wants to call another router, a SPID is used for call setup.

key reason for the confusion is that only some function groups—and therefore some reference

points—are used in a single topology. Cisco expects CCNAs to be familiar with all function

groups and reference points. In an effort to clear up these two topics, consider the following

inexact but more familiar definitions of the two:

details.

Most people understand concepts better if they can visualize a network or actually implement

the network. However, for a good understanding of function groups and reference points, keep

the following facts in mind:

used in a particular part of the world.

groups and reference points.

people ignore these details.

A cabling diagram is helpful for examining the reference points and the function groups. Figure

8-22 shows the cabling diagram for several examples.

Router A was ordered with an ISDN BRI U reference point, referring to the I.430 reference

point defining the interface between the customer premise and the telco in North America.

Router B was bought with an ISDN BRI S/T interface, implying that it must be cabled to a

function group NT1 device in North America. An NT1 function group device must be

connected to the telco line through a U reference point in North America; the S/T interface

defines the connection to Router B. Router B is called a TE1 (Terminal Equipment 1) function

group device. Finally, non-ISDN equipment is called a TE2 (Terminal Equipment 2) device and

is attached using the R reference point to a terminal adapter (TA) function group device.

Alternately, a TE1 can connect using an S reference point to an NT2 function group, as shown

in case D of Figure 8-15.

Table 8-27 summarizes the types from Figure 8-22. Table 8-28 and Table 8-29 provide a

summary of formal definitions.

A TE1, NT1 U

B TE1 S/T (combined S and T)

C TE2 R

D TE1 S

Jargon definitely confuses the issue with home ISDN services. Figure 8-23 outlines the

problem.

TE1 Terminal Equipment 1 ISDN-capable four-wire cable. Understands

signaling, 2B+D. Uses S reference point.

TE2 Terminal Equipment 2 Equipment that does not understand ISDN

protocols and specifications (no ISDN

awareness). Uses R reference point, typically

an RS-232 or V.35 cable, to connect to a TA.

TA Terminal adapter Equipment that uses R and S reference points.

Can be thought of as the TE1 function group on

behalf of a TE2.

NT1 Network Termination

Type 1

CPE equipment in North America. Connects

with U reference point (two-wire) to telco.

Connects with T or S reference points to other

customer premise equipment.

NT2 Network Termination

Type 2

Equipment that uses a T reference point to the

telco outside North America, or to an NT1

inside North America. Uses an S reference

point to connect to other customer premise

equipment.

NT1/NT2 A combined NT1 and NT2 in the same device.

This is relatively common in North America.

R TE2 and TA.

S TE1 or TA and NT2.

T NT2 and NT1.

U NT1 and telco.

S/T TE1 or TA, connected to an NT1, when no NT2 is used. Alternately, the

connection from a TE1 or TA to a combined NT1/NT2.

Popularly used, ISDN terminology for home-based consumers sometimes muddles the

terminology from the ISDN specifications. The home user orders the service, and the telco

offers to sell the user one of several “ISDN modems.” What is actually received is a TA and NT1

in one device. A PC uses a serial port to connect to the TA, which uses reference point R.

However, the terms reference point, TA, and NT1 are almost never used by providers, hence the

confusion.

One other detail of the ISDN protocols that might be on the exam is the ISDN SBus. The ISDN

SBus allows multiple devices to share the same BRI by sharing the S reference point. SBus is

a great idea, but it has not been deployed extensively. SBus takes the S reference point and

allows multiple TE1s to connect to the same NT1. This enables multiple TE1s to use the same

BRI. If all the TE1s were data devices, then instead of using an SBus, a better solution would

be to place all TE1s on a LAN and use an ISDN-capable router. To support ISDN phones, fax,

video, and data TE1 devices, however, the SBus can be used. Figure 8-24 shows a basic SBus

topology.

ISDN signaling can be created by the TE1s and responded to by TE1s. However, because the

BRI is shared among the TE1s, the SPID received in a call setup request no longer uniquely

the SBus uses a different subaddress. The service provider connected to this NT1 and to any

other NT1 from which calls are set up must support subaddressing before the user can use SBus.

ISDN typically is used for temporary dial connections. Attractive pricing has also caused some

companies to use permanently dialed (“nailed-up”) ISDN connections instead of leased lines.

ISDN lines can provide access at 128kbps, using both B channels. Compression can increase

throughput, potentially getting 500kbps of throughput through the line. xDSL technology is an

emerging competitor to ISDN for dial-in ISPs.

Temporary connections between routers are another typical use of ISDN, both for backup and

for occasional connection. Backup is self-explanatory. Occasional connections would include

traffic for sites that do not use online applications or video conferencing, and cases in which

additional bandwidth between sites is desired. Most of the configuration needed for these

covered in a later section of this chapter. Figure 8-25 shows some of the typical network

topologies when using ISDN.

The scenarios in Figure 8-25 can be described as follows:

when the traffic that needs to get to another site is sent by the user.

established between the same two routers.

to replace a Frame Relay access link or a failed VC.

network, replacing a failed VC or access link with a VC running over an ISDN connection

to the Frame Relay switch.

PPP and HDLC can be used on B channels, but PPP provides several features that make it the

preferred choice in a dial environment. HDLC and PPP overhead per-data frame is identical;

however, PPP provides LQM, as well as CHAP and PAP authentication and Layer 3 address

assignment through several of the control protocols. Each of these features is particularly

important in a dial environment.

Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol

(CHAP) are used to authenticate (verify) that the endpoints on a dial connection are allowed to

connect. CHAP is the preferred method today because the identifying codes flowing over the

link are created using a Message Digest 5 (MD5) one-way hash, which is more secure than the

clear-text passwords sent by PAP.

Both PAP and CHAP require the exchange of messages between devices. The dialed-to router

expects to receive a user name and password from the dialing router with both PAP and CHAP.

With PAP, the user name and password are sent by the dialing router. With CHAP, the dialedto

router sends a message (called a challenge) that asks the dialing router to send its user name

and password. The challenge includes a random number, which is part of the input into the MD5

hash algorithm. The dialing router replies with the MD5 hash value, which is a function of its

ID (host name), its password, and the random number supplied in the challenge. The dialed-to

router repeats the same hash algorithm; if the received value matches the computed value, the

CHAP authentication is passed. Figure 8-26 illustrates the message flow in PAP and CHAP

environments. Example 8-25 shows the CHAP configuration for Figure 8-26.

Notice that each router refers to the other router’s host name; each router uses its own host name

in CHAP flows, unless overridden by configuration. Each codes the same password. When

Router Barney receives a challenge from Router Fred, Router Barney sends an encrypted value,

which is the value Fred should compute given the name Barney, the password Bedrock, and the

original random number. CHAP authentication is completed if the two values match.

Router Fred Router Barney

username Barney password Bedrock username Fred password Bedrock

! !

Interface serial 0 Interface serial 0

encapsulation ppp encapsulation ppp

ppp authentication chap ppp authentication chap

. .

Multilink PPP is a function that allows multiple links between a router and some other device

over which traffic is balanced. The need for this function is straightforward; some other

considerations about when to use it are subtle. Figure 8-27 illustrates the most obvious need for

Multilink PPP.

Figure 8-27 shows two dotted lines between the PC and the access server, signifying that two

B channels are in use between the devices. Multilink PPP breaks a packet into fragments, sends

some fragments across each of the two links, and reassembles them at the other end of the link.

The net result is that the links are utilized approximately the same amount.

Multilink PPP is also useful between routers. For example, in Figure 8-28, videoconferencing

between Atlanta and Nashville uses six B channels between two routers.

In this example, if multilink PPP is used, the links have almost identical utilization. The

negative is that the routers must fragment and reassemble every packet. However, the 384Kb

needed for the video conference is available.

Now consider the alternative—without multilink PPP, but simply with PPP on each of the six

links. Six routes to subnet 10.2.2.0/24 would exist in Router A’s routing table. With any of the

faster internal switching methods in a Cisco router (fast switching, optimum switching,

but the balancing is unpredictable. More importantly, all packets to the videoconference

system’s single IP address in Nashville will use the same link, effectively limiting the

videoconference to 64 kbps. An alternative is to disable the faster switching methods in the

router so that multiple routes to the same subnet are used in a round-robin fashion. However,

that is not recommended because it significantly slows the internal processing on the router. For

that reason, multilink PPP is a better choice in this case.

Example 8-26 shows a sample multilink PPP configuration. The Atlanta and Nashville routers

will use two B channels of the same BRI.

channel if the utilization average on the currently used links is more than 25 percent for either

inbound or outbound utilization.

As a CCNA, you’ll need to understand both ISDN configuration and the related DDR

configuration that causes the IOS to use the BRI interface. Dial-on-demand routing (DDR)

configuration and concepts must be understood before the ISDN configuration topics will make

complete sense. In fact, ISDN configuration can be very brief, whereas DDR can become quite

involved. In this section, DDR is explained first, with ISDN configuration included later.

DDR defines the logic behind when a router chooses to dial another site, whether ISDN,

synchronous serial, or asynchronous serial interfaces are used. In this chapter, the examples

reflect ISDN; the DDR logic is the same for any of the three types of dial interfaces. DDR

includes several variations; the variation called DDR legacy is covered in this chapter. Those of

you who want to pursue CCNP and CCIE certification should expand your knowledge of DDR

concerning DDR dialer profiles in particular.

Little additional ISDN configuration is required in addition to the core DDR configuration. In

fact, one detail that is covered deeply in the earlier ISDN concepts section is the use of certain

reference points by Cisco’s products; there is no need to configure the IOS to know which

interface is used. Cisco’s BRI implementation includes a choice of an S/T interface or a U

interface. In either case, BRI configuration in the router is identical.

Hands-on experience is the best way to fully learn the details of configuration. In lieu of that,

this section lists commands, provides examples, and points out tricky features. Table 8-30 and

username Nashville password Robert

interface bri 0

ip addr 10.3.3.1 255.255.255.0

encapsulation ppp

dialer idle-timeout 300

dialer load-threshold 25 either

dialer map 10.3.3.2 name Nashville 16155551234

dialer-group 1

ppp authentication chap

ppp multilink

Table 8-31 summarize the more popular commands used for ISDN configuration and

verification. The Cisco IOS documentation is an excellent reference for additional IP

reference, particularly if you are not able to attend the instructor-led version of the class.

switch to which the ISDN line is

connected at the central office.

calls when using call screening.

Interface Specifies the ISDN number or

subaddress that must be used on

incoming calls for this router to

answer.

Interface Specifies a second ISDN number or

subaddress that must be used on

incoming calls for this router to

answer.

Global Defines types of traffic considered

interesting.

interface. This command is used only

for serial lines that connect to a TA,

not for native ISDN interfaces that use

the out-of-band D channel.

only one site.

Interface Is the dial string to reach the next hop.

when dialing more than one site. This

also is the name used for authentication.

Broadcast ensures that copies

of broadcasts go to this next-hop

address.

Two ways exist by which to configure DDR. The two styles of DDR configuration are called

associates dial details with a physical interface, but DDR dialer profiles-style configuration

disassociates the dial configuration from a physical interface, allowing a great deal of flexibility.

The concepts behind legacy DDR apply to DDR dialer profiles as well, but DDR legacy is a

little less detailed. Although not overly stated in the course, the DDR coverage in the ICND

class is for DDR legacy.

DDR can be used to cause the router to dial or to receive a dial on asynchronous serial

interfaces, synchronous serial interfaces, and ISDN BRI and PRI interfaces. All examples in

this chapter use ISDN BRI.

The following list identifies the four key concepts behind DDR configuration. The first two

concepts are not actually related to the dial process, but relate to the process of choosing when

to dial and when not to dial. The other two concepts relate to dialing, or signaling. The term

process

Includes reference to the access lists enabled on the interface.

Shows various ISDN status information.

Displays interface information about the D channel or the B

channel(s).

Lists DDR parameters on the BRI interface. Shows whether currently

dialed by indicating current status. Also shows previous attempts to

dial and whether they were successful.

Lists information when a packet is directed out a dial interface, telling

whether the packet is interesting.

Each of these is addressed in succession, followed by a discussion of DDR legacy

configuration. After learning about the basic DDR concepts and configuration procedures, you

will learn about ISDN-specific configuration. Finally, this section concludes with a complete

DDR and ISDN example.

DDR Step 1: Routing Packets out the Interface to Be Dialed

Figure 8-29 provides the backdrop for these discussions. In these discussions, the SanFrancisco

router will be dialing into the main site in LosAngeles.

The router must choose when to dial. The first step in this process relates to the following fact:

The router needs to route packets so that they are queued to go out the dial interface. Cisco’s

design for DDR defines that the router receives some user-generated traffic and, through normal

routing processes, decides to route the traffic out the interface to be dialed. The router

(SanFrancisco) can receive a packet that must be routed out BRI0; routing the packet out BRI0

triggers the IOS, causing the dial to occur.

Of course, routes are not learned over a dial link while the dial link is down. In Figure 8-29, for

instance, SanFrancisco will have no routes to 172.16.3.0/24 learned via a routing protocol.

Therefore, static routes are configured on SanFrancisco. This can be done for any protocol that

is supported by DDR for the purpose of triggering the dial. All routable protocols can be

configured to trigger the dial; IP will be used in the upcoming examples. Any traffic that could

be routed or bridged across a leased link is supported after the link is up.

To begin the process of building a DDR configuration, IP routes are added to the configuration

so that packets can be directed out BRI0 on SanFrancisco:

! SanFrancisco Static routes.

ip route 172.16.3.0 255.255.255.0 172.16.2.1

DDR Step 2: Determining the Subset of The Packets That Trigger the Dialing Process

Together, Steps 1 and 2 of legacy DDR logic determine when the dial is attempted. These

interface to be dialed, but that packet alone does not necessarily cause the dial to occur. The IOS

allows the second step to define a subset of the packets routed in Step 1 to actually cause the

route to dial. The logic flow works as shown in Figure 8-30.

The choice in Step 2 is simply put like this: “Is this packet, which is being routed out this dial

interface, worthy of causing the dial to occur?” The packets that are worthy of causing the

that are not worthy of causing the dial; in effect, they are “boring.” The capability to exactly

determine the interesting packets grants the router administrator control over when the dial is

made. This is particularly important if the dialed connection is incrementally charged by the

minute.

as all packets of one or more Layer 3 protocols (for example, all IP packets). In that case, any

user in SanFrancisco can send a packet to any host in 172.16.3.0/24 and trigger the dial

connection. That might be exactly what is desired, or it might not be. The second method is that

permits the packet, it is considered interesting.

Example 8-27 shows additional configuration on SanFrancisco, in two cases. One shows all IP

packets being considered as interesting, and the other shows all packets to the Web server Lois

(refer to Figure 8-29) considered as interesting.

It refers to a dialer list, which can refer either to an entire protocol suite or to an access list, as

shown. (After the link is up, packets are not filtered using list 101—the logic is used just for

determining what is interesting and what is boring.)

DDR Step 3: Dialing (Signaling)

The dialing router needs additional information before the dial can occur. First, for non-ISDN

interfaces, it is necessary to communicate the dial string to the external dialing device. In-band

This is not necessary on a BRI interface because it uses the out-of-band D channel for signaling.

Table 8-32 summarizes what the command implies on different interfaces.

The second piece of information needed before dialing is the phone number. With the network

with Figure 8-29 that allows the dial to occur.

ip route 172.16.3.0 255.255.255.0 172.16.2.1

access-list 101 permit tcp any host 172.16.3.1 eq 80

dialer-list 1 protocol ip permit

dialer-list 2 protocol ip list 101

interface bri 0

encapsulation ppp

ip address 172.16.2.2 255.255.255.0

!Use this one if all IP is considered interesting ...

dialer-group 1

! OR Use next statement to trigger for Web to Server Lois

dialer-group 2

Async AT command set (in-band)

Sync V.25 bis (in-band)

ISDN ISDN D channel with Q.921/Q.931 (out-of-band)

is to be used for signaling a connection. The signaling occurs on the D channel of the BRI.

When more than one site is dialed from the same interface, several dial strings are needed.

For example, Figure 8-31 adds a third site, GothamCity, to the network. The client’s FTP

connections to the FTP server running on Commissioner will be considered interesting traffic

for causing dial connections to GothamCity.

ip route 172.16.3.0 255.255.255.0 172.16.2.1

!

access-list 101 permit tcp any host 172.16.3.1 eq 80

!

dialer-list 2 protocol ip list 101

!

interface bri 0

ip address 172.16.2.2 255.255.255.0

encapsulation ppp

dialer string 14045551234

dialer-group 2

The dilemma for SanFrancisco will now be how to determine which ISDN telephone number

there are unique ISDN telephone numbers for both LosAngeles and GothamCity. Because the

static routes will direct the router to send the packet to either 172.16.2.1 or 172.16.2.3, all that

is needed is a mapping between these next-hop addresses and their respective ISDN telephone

complete configuration.

dial to LosAngeles would occur. Conversely, if the interesting packet were routed to 172.16.2.3,

to the FTP server in GothamCity.

Two other important configuration elements are included in Example 8-28. First, CHAP

authentication was configured. PAP or CHAP is required if dialing to more than one site with

ISDN—and PAP and CHAP require PPP. The user name expected from the other router is

Broadcast handling is the final configuration element that must be addressed. Just as with any

other point-to-point serial link, there is no true data link broadcast. If a broadcast must be sent

to forward the packet across the link.

ip route 172.16.3.0 255.255.255.0 172.16.2.1

ip route 172.16.4.0 255.255.255.0 172.16.2.3

! Added usernames for CHAP support!

username LosAngeles password Clark

username GothamCity password Bruce

access-list 101 permit tcp any host 172.16.3.1 eq 80

! Added next statement to make The Client’s FTP connection interesting!

access-list 101 permit tcp any host 172.16.4.1 eq 21

!

dialer-list 2 protocol ip list 101

!

interface bri 0

ip address 172.16.2.2 255.255.255.0

encapsulation ppp

ppp authentication chap

dialer map ip 172.16.2.1 broadcast name LosAngeles 14045551234

dialer map ip 172.16.2.3 broadcast name GothamCity 1999999999901

dialer-group 2

!

router igrp 6

network 172.16.0.0

DDR Step 4: Determining When the Connection Is Terminated

The dialed link acts just like a leased line while it is up. If a particular Layer 3 protocol is

enabled on the link, it can be routed across the link. Transparent (encapsulated) bridging can be

used just like any other point-to-point link. Routing updates, IPX SAPs, AppleTalk ZIP, and

any access list used to define which packets are interesting does not filter the traffic on the

interface. If packet filters are desired, an access list must be enabled on the interface.

Additional parallel links can be dialed if more capacity is desired. To do so, dialer profiles must

utilization that must be exceeded for another link to be dialed.

The decision to take the link down is the most intriguing part about what happens while the link

is up. Although any type of packets can be routed across the link, only interesting packets are

considered worthy of keeping the link up. An idle timer counts the time since the last interesting

packet went across the link. If that time expires, the link is brought down.

previously described is set. If interesting traffic that needs to flow to another dial site is

command enables you to configure a typically lower number than the idle timer so that when

other sites need to be dialed, the link that is currently up but can be brought down earlier in the

ISDN Configuration

Example 8-30 and Example 8-31 show the DDR configuration for the network in Figure 8-31.

ISDN configuration details have been added; the text following these two examples describes

the ISDN commands shown.

ip route 172.16.3.0 255.255.255.0 172.16.2.1

ip route 172.16.4.0 255.255.255.0 172.16.2.3

! Added usernames for CHAP support!

username LosAngeles password Clark

username GothamCity password Bruce

!

access-list 101 permit tcp any host 172.16.3.1 eq 80

access-list 101 permit tcp any host 172.16.4.1 eq 21

!

dialer-list 2 protocol ip list 101

!

interface bri 0

encapsulation ppp

ppp authentication chap

isdn spid1 555555111101

isdn spid2 555555222202

dialer idle-timeout 300

The ISDN configuration commands are delineated in the examples via highlighted text; those

commands are described in the upcoming text. For example, the switch types are a required

parameter for connection to DMS-100 or National ISDN switches; ask your service provider

for the type of switch at each site. The LosAngeles BRI is attached to a National ISDN switch

be used as a global command, or with an interface subcommand if the router is connected to

multiple different types of ISDN switches. The SPIDs might not be required; they are used

as a form of authentication by the switch. The SPIDs are configured with BRI interface

subcommands on SanFrancisco. Also, hidden in part of the DDR configuration, the speed of the

B channel from SanFrancisco to GothamCity will be 56kbps, according to the speed parameter

PAP or CHAP authentication is required for ISDN BRI dial connections. PAP and CHAP

configuration is covered earlier in this chapter, in the section “PAP and CHAP.”

As seen in Example 8-32, a DDR dial connection over BRI0 has occurred from SanFrancisco

to LosAngeles:

dialer fast-idle 120

dialer map ip 172.16.2.1 broadcast name LosAngeles 14045551234

dialer map ip 172.16.2.3 broadcast speed 56 name GothamCity 1999999999901

dialer-group 2

!

router igrp 6

network 172.16.0.0

username SanFrancisco password Clark

!

interface bri 0

encapsulation ppp

ppp authentication chap

isdn switch-type basic-ni1

!

router igrp 6

network 172.16.0.0

BRI0:1 is down, line protocol is down

Hardware is BRI

MTU 1500 bytes, BW 64 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

Input queue: 0/75/0 (size/max/drops); Total output drops: 0

Queuing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/1/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

44 packets input, 1986 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

49 packets output, 2359 bytes, 0 underruns

0 output errors, 0 collisions, 7 interface resets

0 output buffer failures, 0 output buffers swapped out

11 carrier transitions

DCD=up DSR=up DTR=up RTS=up CTS=up

BRI0 - dialer type = ISDN

Dial String Successes Failures Last called Last status

0 incoming call(s) have been screened.

BRI0: B-Channel 1

Idle timer (300 secs), Fast idle timer (120 secs)

Wait for carrier (30 secs), Re-enable (15 secs)

Dialer state is data link layer up

Dial reason: ip (s=172.16.1.1, d=172.16.3.1)

Time until disconnect 18 secs

Current call connected 00:14:00

Connected to 14045551234 (LosAngeles)

BRI0: B-Channel 2

Idle timer (300 secs), Fast idle timer (120 secs)

Wait for carrier (30 secs), Re-enable (15 secs)

Dialer state is idle

-------------------------------------------------------------------------------

ISDN ACTIVE CALLS

-------------------------------------------------------------------------------

History Table MaxLength = 320 entries

History Retain Timer = 15 Minutes

-------------------------------------------------------------------------------

Call Calling Called Duration Remote Time until Recorded Charges

The current timer values and call setup reason are listed by the first command in Example 8-32,

command lists the fact that a single active call exists to LosAngeles, with now only 11 seconds

that one call is active, which leaves one inactive B channel.

Remembering the general idea behind the debug command output is also useful for CCNAs so

Type Number Number Seconds Name Disconnect Units/Currency

-------------------------------------------------------------------------------

Out 14045551234 Active(847) LosAngeles 11 u

-------------------------------------------------------------------------------

The current ISDN Switchtype = ntt

ISDN BRI0 interface

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 64, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

1 Active Layer 3 Call(s)

Activated dsl 0 CCBs = 1

CCB:callid=8003, callref=0, sapi=0, ces=1, B-chan=1

Number of active calls = 1

Number of available B-channels = 1

Total Allocated ISDN CCBs = 1

ISDN q931 protocol debugging is on

TX -> SETUP pd = 8 callref = 0x04

Bearer Capability i = 0x8890

Channel ID i = 0x83

Called Party Number i = 0x80, `14045551234’

All possible debugging has been turned off

Dialer event debugging is on

Dialing cause: BRI0: ip (s=172.16.1.1, d=172.16.3.1)

All possible debugging has been turned off

Dialer packet debugging is on

BRI0: ip (s=172.16.1.1, d=172.16.3.1) 444 bytes, interesting (ip PERMIT)

command lists output for call setup and disconnect; the output in the example shows output

is a candidate for causing the dial to occur—in other words, when a packet is routed out the dial

interface.

Networking professionals need to know about many WAN options when designing networks.

Certainly, Cisco requires CCNAs to have a solid foundation of the WAN technologies in this

chapter. Cisco also expects CCNAs to be able to compare and contrast these different WAN

technologies. This section summarizes many of the concepts found earlier in this chapter, with

a focus on comparison.

The permanent WAN connectivity options can be categorized into two main groups:

synchronous serial leased lines and packet switching services. PPP, HDLC, and LAPB are

the three data link protocols most typical on leased lines, with Frame Relay being the most

service to imply that the protocol is a Layer 2 protocol, but when talking similar services as a

switching category.

X.25 and ATM are not discussed in this exam guide in any depth. (For more information, refer

to the documents referenced in Appendix B, “Decimal to Hexadecimal and Binary Conversion

Table.”) X.25 is very similar to Frame Relay because it uses VCs and has error-recovery built

in to each link and each end-to-end VC. ATM is similar in its use of virtual connections, which

are conceptually equivalent to VCs. However, ATM includes the concept of segmentation and

reassembly (SAR), in which the device at the edge of the ATM network breaks the frames to be

sent into smaller cells (53 bytes) that are reassembled at the other end of the VC. The details of

how each of these three packet-switching protocols are implemented is different; however, each

creates a multiaccess network, with direct packet forwarding allowed only between pairs of

devices that have a VC between them.

Table 8-33 summarizes these types of permanent connections and lists some of the strengths

and weaknesses.

The product selection phase on any design project can and should necessarily include key

individuals from the organization that will be purchasing or leasing the hardware, Cisco (or the

reseller), and any contracted service companies participating in the future deployment of the

new equipment. (Some of you probably fall into each of those categories, and possibly into

several.) When choosing products, having the vendor or reseller involved can help avoid the

problem of trying to be aware of all possible products and options, particularly for new or

impending products.

To combat some of the challenges of choosing products from a widely varied product line,

Cisco developed the use of three key words to describe the type of product deployed in a typical

enterprise network: Core, Distribution, and Access. Figure 8-32 provides a basic network, and

Table 8-34 summarizes the meaning behind these three categorizations.

Leased Delivers pervasive availability. Can be expensive for long

circuits. Is more expensive for providers to engineer than are

packet services.

PPP Can improve speed of routing protocol convergence. Allows

multivendor interoperability. Has available error recovery

option.

HDLC Is the IOS default. Requires Cisco router on each end.

LAPB Provides error recovery, but this also can result in throttling

(slowing) the data rate.

Packet-switched Allows addition of new sites to be made quickly. Typically

involves a lower cost.

Frame Relay Allows bursting past CIR, giving perception of “free”

capacity. Is pervasive in the United States.

ATM As a WAN technology, is not as pervasively available as

Frame Relay. Has an attractive built-in Quality of Service

feature.

X.25 Is available pervasively in some parts of the world. Offers

beneficial error-recovery features when links have higher

error rates. Typically is the third choice of these three if all

are available to all connected sites.

Cisco expects CCNAs to understand the needs of each of these layers in a typical network.

Conveniently, if router product numbers are listed from low numbers to high, the products that

tend to be listed first are access routers, then distribution, and then core, for the most part. For

instance, Figure 8-33 comes directly from the ICND course, which is one of the two suggested

prerequisites for the CCNA exam. The figure lists the main product families.

Core Fast transport, often at the topological

center of the network. Packet

manipulation is not performed here.

Highest forwarding speed

Distribution Aggregation of access points. Any

media translation or security (for

instance, access lists) is performed

here.

High interface density, high processing

capacity per interface for packet

manipulation

Access Entry point for end-user devices, both

LAN and dial.

High variety of interface types, less

processing capacity required (versus

distribution)

Many of the lower-end routers have both BRI interfaces and asynchronous support (1700, 2600,

and 3600), so these would make excellent access routers. The 3600 and 4000 series have more

port density than the smaller routers and have RISC processors for better performance on packet

manipulation. Finally, the 7000 series, which includes the 7200 and 7500 routers, and the

Gigabit Switch Router (GSR) provide the highest forwarding capacity.

All these routers support synchronous serial interface, which can be configured for PPP, HDLC,

LAPB, Frame Relay, and X.25. ATM requires a specific interface due to the SAR function. For

instance, the 3600 series supports ATM support at OC-3 speeds and higher; some slower ATM

interfaces are supported on access routers.

The Foundation Summary is a collection of tables and figures that provide a convenient review

of many of the key concepts in this chapter. For those of you already comfortable with the topics

in this chapter, this summary could help you recall a few details. For those of you who just read

this chapter, this review should help solidify some key facts. For any of you doing your final

prep before the exam, these tables and figures will hopefully be a convenient way to review the

day before the exam.

Table 8-35 summarizes the configuration commands used for HDLC and PPP configuration:

Table 8-36 summarizes the more popular commands used for Frame Relay configuration.

Interface Defines Frame Relay encapsulation; is used

rather than HDLC, PPP, and so on.

Interface Defines the type of LMI messages sent to the

switch.

Bandwidth is used by some routing protocols to

influence the metric.

Interface Statically defines a mapping between a network

layer address and a DLCI.

enquiry messages are sent and expected.

Global Creates a subinterface, or references a

previously created subinterface.

Table 8-37 summarizes the more popular commands used for ISDN configuration and

verification.

Interface Defines a DLCI used for a VC to another DTE.

Interface

subcommand

Defines payload compression on point-to-point

subinterfaces.

switch to which the ISDN line is

connected at the central office.

calls when using call screening.

Interface Specifies the ISDN number or

subaddress that must be used on

incoming calls for this router to

answer.

Interface Specifies a second ISDN number or

subaddress that must be used on

incoming calls for this router to

answer.

Global Defines types of traffic considered

interesting.

interface. This command is used only

for serial lines that connect to a TA,

not for native ISDN interfaces that use

the out-of-band D channel.

one site.

Interface Is a dial string to reach the next hop.

when dialing more than one site. This

also is the name used for authentication.

Broadcast ensures that copies

of broadcasts go to this next-hop

address.

the encapsulation type.

increased utilization due to compression.

Shows PVC status, mapping (dynamic and static), and LMI

status.

Includes a reference to the access lists enabled on the interface.

Shows various ISDN status information.

Displays interface information about the D channel or the B

channel(s).

currently dialed, by indicating current status. Also shows

previous attempts to dial and tells whether they were successful.

telling if the packet is interesting.

Table 8-39 lists a brief reference to some popularly used WAN terminology.

option lists inverse ARP information. Other options include

Uses the following most important options for CCNAs:

negotiation, which shows the control protocol initialization, and

authentication, which shows PAP and CHAP flows.

Synchronous The imposition of time ordering on a bit stream. More practically speaking, a

device will try to use the same speed as another on the other end of a serial

link. However, by examining transitions between voltage states on the link,

the device can notice slight variations in the speed on each end so that it can

adjust its speed.

Asynchronous The lack of an imposed time ordering on a bit stream. More practically

speaking, both sides agree to the same speed, but there is no check or

adjustment of the rates if they are slightly different. However, because only 1

byte per transfer is sent, slight differences in clock speed are not an issue.

A start bit is used to signal the beginning of a byte.

Clock source The device to which the other devices on the link adjust their speed when

using synchronous links.

DSU/CSU Data Services Unit and Channel Services Unit. This is used on digital links

as an interface to the telephone company in the United States. Routers

typically use a short cable from a serial interface to a DSU/CSU, which is

attached to the line from the telco with a similar configuration at the other

router on the other end of the link. The routers use their attached DSU/CSU

as the clock source.

Telco Telephone company.

4-wire circuit A line from the telco with four wires, comprised of two twisted-pair wires.

Each pair is used to send in one direction, so a 4-wire circuit allows fullduplex

communication.

2-wire circuit A line from the telco with two wires, comprised of one twisted-pair wire. The

pair is used to send in only one direction at a time, so a 2-wire circuit allows

only half-duplex communication.

Table 8-40 lists the point-to-point data link protocols and their attributes.

don’t let that make you think that the B is for an ISDN B channel.

T/1 A line from the telco that allows transmission of data at 1.544Mbps. This can

be used with a T/1 multiplexor.

T/1 mux A multiplexor that separates the T/1 into 24 different 64kbps channels. In the

United States, one of every 8 bits in each channel can be used by the telco so

that the channels are effectively 56kbps channels.

E/1 Like a T/1, but in Europe. It uses a rate of 2.048Mbps and 32 64kbps

channels.

Synchronous Data

Link Control (SDLC)

Yes None SDLC supports multipoint links;

it assumes that an SNA header

occurs after the SDLC header.

Link Access

Procedure Balanced

(LAPB)

Yes None Spec assumes a single

configurable protocol after

LAPB. This is used mainly with

X.25. Cisco uses a proprietary

type field to support

multiprotocol traffic.

Link Access

Procedure on the D

channel (LAPD)

No No LAPD is not used between

routers. It is used on a D channel

from the router to the ISDN

switch for signaling.

High-Level Data Link

Control (HDLC)

No No HDLC is Cisco’s default on serial

links. Cisco uses a proprietary

type field to support

multiprotocol traffic.

Point-to-Point

Protocol (PPP)

Allows user to choose

whether error

correction is

performed; correction

uses LAPB

Yes PPP was meant for multiprotocol

interoperability from its

inception, unlike all the others.

PPP also supports asynchronous

communication.

A variety of standards define the types of connectors and physical signaling protocols used on

the interfaces. Table 8-41 summarizes these standards:

Table 8-42 lists a variety of terms associated with Frame Relay.

EIA/TIA 232 Telecommunications Industry Association 25

EIA/TIA 449 Telecommunications Industry Association 37

EIA/TIA 530 Telecommunications Industry Association 25

V.35 International Telecommunications Union 34

X.21 International Telecommunications Union 15

Virtual circuit (VC) A VC is a logical concept that represents the path that frames travel

between DTEs. VCs are particularly useful when comparing Frame

Relay to leased physical circuits.

Permanent virtual circuit (PVC) A PVC is a VC that is predefined. A PVC can be equated to a leased

line in concept.

Switched virtual circuit (SVC) An SVC is a VC that is set up dynamically. An SVC can be equated

to a dial connection in concept.

Data terminal equipment (DTE) DTEs are also known as data-circuit termination equipment. For

example, routers are DTEs when connected to a Frame Relay

service from a telecommunication company.

Data communications

equipment (DCE)

Frame Relay switches are DCE devices.

Access link The access link is the leased line between DTE and DCE.

Access rate (AR) The access rate is the speed at which the access link is clocked. This

choice affects the price of the connection.

Committed information rate

(CIR)

The CIR is the rate at which the DTE can send data for an

individual VC, for which the provider commits to deliver that

amount of data. The provider will send any data in excess of this

rate for this VC if its network has capacity at the time. This choice

typically affects the price of each VC.

Burst rate The burst rate is the rate and length of time for which, for a

particular VC, the DTE can send faster than the CIR, and the

provider agrees to forward the data. This choice affects the price of

each VC typically.

Table 8-43 outlines the three Frame Relay LMI types, their origin, and the keyword used in the

Figure 8-34 shows several examples of ISDN BRI topology, with function groups and reference

points.

Data link connection identifier

(DLCI)

A DLCI is a Frame Relay address and is used in Frame Relay

headers to identify the virtual circuit.

Forward explicit congestion

notification (FECN)

The FECN is the bit in the Frame Relay header that signals to

anyone receiving the frame (switches and DTEs) that congestion is

occurring in the same direction as the frame. Switches and DTEs

can react by slowing the rate by which data is sent in that direction.

Backward explicit congestion

notification (BECN)

The BECN is the bit in the Frame Relay header that signals to

anyone receiving the frame (switches and DTEs) that congestion is

occurring in the opposite (backward) direction as the frame.

Switches and DTEs can react by slowing the rate by which data is

sent in that direction.

Discard eligibility (DE) The DE is the bit in the Frame Relay header that signals to a switch

that, if frames must be discarded, please choose this frame to

discard instead of another frame without the DE bit set.

Nonbroadcast multiaccess

(NBMA)

NBMA refers to a network in which broadcasts are not supported

but more than two devices can be connected.

Local Management Interface

(LMI)

LMI is the protocol used between a DCE and a DTE to manage the

connection. Signaling messages for SVCs, PVC status messages,

and keepalives are all LMI messages.

Link access procedure—frame

mode bearer services (LAPF)

LAPF is the basic Frame Relay header and trailer, which includes

DLCI, FECN, BECN, and DE bits.

Cisco Proprietary cisco

ANSI T1.617 Annex D ansi

ITU Q.933 Annex A q933a

Table 8-44 lists the function groups and reference points shown in Figure 8-34.

Table 8-45 summarizes these types of permanent connections and lists some of the strengths

and weaknesses.

A TE1, NT1 U

B TE1 S/T (combined S and T)

C TE2 R

D TE1 S

Leased Offers pervasive availability. Can be expensive for long

circuits. Is more expensive for providers to engineer than are

packet services.

PPP Can improve speed of routing protocol convergence. Allows

multivendor interoperability. Offers error recovery option.

Figure 8-35 outlines the process of Frame Relay initialization.

HDLC Is the IOS default. Requires a Cisco router on each end.

LAPB Provides error recovery, but this also can result in throttling

(slowing) the data rate.

Packet Switched Allows addition of new sites to be made quickly. Typically

involves a lower cost.

Frame Relay Allows bursting past CIR, giving perception of free capacity.

Is pervasive in the United States.

ATM As a WAN technology, is not as pervasively available as

Frame Relay. Offers built-in Quality of Service as its most

attractive feature.

X.25 Is available pervasively in some parts of the world. Error

recovery features are beneficial when links have higher error

rates. Typically is the third choice of these three if all are

available to all connected sites.

Figure 8-36 lists the main Cisco router product families.

Figure 8-37 provides a conceptual diagram of the two forms of Frame Relay encapsulation.

However, each VC can use a different encapsulation.

As mentioned in Chapter 1, “All About the Cisco Certified Network Associate Certification,”

the questions and scenarios in this book are more difficult than what you should experience on

the actual exam. The questions do not attempt to cover more breadth or depth than the exam;

however, they are designed to make sure that you know the answer. Rather than allowing you

to derive the answer from clues hidden inside the question itself, the questions challenge your

understanding and recall of the subject. Questions from the “Do I Know This Already?” quiz

from the beginning of the chapter are repeated here to ensure that you have mastered the

chapter’s topic areas. Hopefully, these questions will help limit the number of exam questions

on which you narrow your choices to two options and then guess.

The answers to these questions can be found in Appendix A, on page 768.

which is used to define the type of header that follows the WAN data link header.

addresses of the interface to other devices attached to the WAN.

bearer channels? If not, what is used?

10, 11, or 12 bits.” Which parts of this statement do you agree with? Which parts do you

disagree with? Why?

broadcasts.

Would a router on the other end of the VC behave any differently if the same change were

made?

Frame Relay networks?

serial link.

routing updates to flow over each VC?

subinterfaces?

partial mesh?

enabled?

3 addresses as needed.

(DLCIs 202 and 203, respectively) for Frame Relay on Router1’s serial 1 interface. Use

any IP and IPX addresses you like. Assume that the network is not fully meshed.

router know what time the PVC became active?

will the information displayed include the Layer 3 addresses of other routers?

further Cisco proprietary keepalive messages to be sent to the Frame Relay switch.

3 protocol address mapping on the same configuration command.

a PRI in Europe?

2, and 3. Defend your answer.

correlate to an OSI layer?

layer?

be in use?

North America? What about in Europe?

names and passwords must match in the respective CHAP configurations.

that it uses only one SPID of 404555121201, and that you want to screen calls so that only

calls from 404555999901 are accepted.

Frame Relay subinterface.

legacy DDR.

packets from 10.1.1.0/24 caused a DDR connection out an interface BRI0, list the

configuration commands that would make the IOS think that those packets were

interesting on BRI0.

Use Example 8-33, Example 8-34, and Example 8-35 when completing the exercises and

answering the questions that follow.

Interface IP-Address OK? Method Status Protocol

Serial0 199.1.1.129 YES NVRAM up up

Serial1 199.1.1.193 YES NVRAM up up

Ethernet0 199.1.1.33 YES NVRAM up up

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

199.1.1.0/24 is variably subnetted, 7 subnets, 2 masks

C 199.1.1.192/27 is directly connected, Serial1

C 199.1.1.130/32 is directly connected, Serial0

C 199.1.1.128/27 is directly connected, Serial0

I 199.1.1.160/27 [100/10476] via 199.1.1.130, 00:00:01, Serial0

[100/10476] via 199.1.1.194, 00:00:54, Serial1

I 199.1.1.64/27 [100/8539] via 199.1.1.130, 00:00:01, Serial0

I 199.1.1.96/27 [100/8539] via 199.1.1.194, 00:00:54, Serial1

C 199.1.1.32/27 is directly connected, Ethernet0

Codes: C - Connected primary network, c - Connected secondary network

S - Static, F - Floating static, L - Local (internal), W - IPXWAN

R - RIP, E - EIGRP, N - NLSP, X - External, A - Aggregate

s - seconds, u - uses

6 Total IPX routes. Up to 1 parallel paths and 16 hops allowed.

No default route known.

C 1001 (SAP), E0

C 2001 (PPP), Se0

C 2003 (HDLC), Se1

R 1002 [07/01] via 2001.0200.bbbb.bbbb, 50s, Se0

R 1003 [07/01] via 2003.0200.cccc.cccc, 57s, Se1

R 2002 [07/01] via 2001.0200.bbbb.bbbb, 51s, Se0

PPP protocol negotiation debugging is on

%LINK-3-UPDOWN: Interface Serial0, changed state to up

Se0 PPP: Treating connection as a dedicated line

Se0 PPP: Phase is ESTABLISHING, Active Open

Se0 LCP: O CONFREQ [Closed] id 15 len 10

Se0 LCP: MagicNumber 0x003C2A1F (0x0506003C2A1F)

Se0 LCP: I CONFREQ [REQsent] id 34 len 10

Se0 LCP: MagicNumber 0x0648CFD3 (0x05060648CFD3)

Se0 LCP: O CONFACK [REQsent] id 34 len 10

Se0 LCP: MagicNumber 0x0648CFD3 (0x05060648CFD3)

Se0 LCP: TIMEout: Time = 0xBA0E0 State = ACKsent

Se0 LCP: O CONFREQ [ACKsent] id 16 len 10

Se0 LCP: MagicNumber 0x003C2A1F (0x0506003C2A1F)

Se0 LCP: I CONFACK [ACKsent] id 16 len 10

Se0 LCP: MagicNumber 0x003C2A1F (0x0506003C2A1F)

Se0 LCP: State is Open

Se0 PPP: Phase is UP

Se0 IPCP: O CONFREQ [Closed] id 3 len 10

Se0 IPCP: Address 199.1.1.129 (0x0306C7010181)

Se0 CDPCP: O CONFREQ [Closed] id 3 len 4

Se0 LLC2CP: O CONFREQ [Closed] id 3 len 4

Se0 IPXCP: O CONFREQ [Closed] id 3 len 18

Se0 IPXCP: Network 0x00002001 (0x010600002001)

Se0 IPXCP: Node 0200.aaaa.aaaa (0x02080200AAAAAAAA)

Se0 IPCP: I CONFREQ [REQsent] id 4 len 10

Se0 IPCP: Address 199.1.1.130 (0x0306C7010182)

Se0 IPCP: O CONFACK [REQsent] id 4 len 10

Se0 IPCP: Address 199.1.1.130 (0x0306C7010182)

Se0 CDPCP: I CONFREQ [REQsent] id 6 len 4

Se0 CDPCP: O CONFACK [REQsent] id 6 len 4

Se0 LLC2CP: I CONFREQ [REQsent] id 6 len 4

Se0 LLC2CP: O CONFACK [REQsent] id 6 len 4

Se0 IPXCP: I CONFREQ [REQsent] id 4 len 18

Se0 IPXCP: Network 0x00002001 (0x010600002001)

Se0 IPXCP: Node 0200.bbbb.bbbb (0x02080200BBBBBBBB)

Se0 IPXCP: O CONFACK [REQsent] id 4 len 18

Se0 IPXCP: Network 0x00002001 (0x010600002001)

Se0 IPXCP: Node 0200.bbbb.bbbb (0x02080200BBBBBBBB)

Interface IPX Network Encapsulation Status IPX State

Serial0 2001 PPP up [up]

Serial1 2002 LAPB up [up]

Ethernet0 1002 SAP up [up]

Codes: C - Connected primary network, c - Connected secondary network

S - Static, F - Floating static, L - Local (internal), W - IPXWAN

R - RIP, E - EIGRP, N - NLSP, X - External, A - Aggregate

s - seconds, u - uses

6 Total IPX routes. Up to 1 parallel paths and 16 hops allowed.

No default route known.

C 1002 (SAP), E0

C 2001 (PPP), Se0

C 2002 (LAPB), Se1

R 1001 [07/01] via 2001.0200.aaaa.aaaa, 46s, Se0

R 1003 [13/02] via 2001.0200.aaaa.aaaa, 47s, Se0

R 2003 [07/01] via 2001.0200.aaaa.aaaa, 47s, Se0

Serial1

Protocol Pkts In Chars In Pkts Out Chars Out

IP 37 2798 41 3106

Type escape sequence to abort.

Sending 5, 100-byte IPX Cisco Echoes to 2002.0200.cccc.cccc, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 199.1.1.162, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

Type escape sequence to abort.

Sending 5, 100-byte IPX Cisco Echoes to 1003.0000.30ac.70ef, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

199.1.1.0/27 is subnetted, 6 subnets

C 199.1.1.192 is directly connected, Serial0

I 199.1.1.128 [100/10476] via 199.1.1.161, 00:00:36, Serial1

[100/10476] via 199.1.1.193, 00:01:09, Serial0

C 199.1.1.160 is directly connected, Serial1

I 199.1.1.64 [100/8539] via 199.1.1.161, 00:00:36, Serial1

C 199.1.1.96 is directly connected, Ethernet0

I 199.1.1.32 [100/8539] via 199.1.1.193, 00:01:09, Serial0

Codes: C - Connected primary network, c - Connected secondary network

S - Static, F - Floating static, L - Local (internal), W - IPXWAN

R - RIP, E - EIGRP, N - NLSP, X - External, A - Aggregate

s - seconds, u - uses

6 Total IPX routes. Up to 1 parallel paths and 16 hops allowed.

No default route known.

C 1003 (SAP), E0

C 2002 (LAPB), Se1

C 2003 (HDLC), Se0

R 1001 [07/01] via 2003.0200.aaaa.aaaa, 2s, Se0

R 1002 [13/02] via 2003.0200.aaaa.aaaa, 2s, Se0

R 2001 [07/01] via 2003.0200.aaaa.aaaa, 2s, Se0

Serial0

Protocol Pkts In Chars In Pkts Out Chars Out

IP 44 3482 40 3512

IPX 46 3478 44 2710

CDP 21 6531 26 7694

LAPB link debugging is on

%LINK-3-UPDOWN: Interface Serial1, changed state to up

Serial1: LAPB O SABMSENT (2) SABM P

Serial1: LAPB I SABMSENT (2) UA F

Serial1: LAPB I CONNECT (104) IFRAME 0 0

Serial1: LAPB O CONNECT (76) IFRAME 0 1Serial1: LAPB I CONNECT (76) IFRAME 1 1

Serial1: LAPB O CONNECT (2) RR (R) 2

Seville#

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 199.1.1.161, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms

Seville#

Assuming the details established in Example 8-33 through Example 8-35 for Scenario 8-1,

complete or answer the following:

Use Example 8-36, Example 8-37, Example 8-38, and Example 8-39 when completing the

exercises and answering the questions that follow.

Serial1: LAPB O CONNECT (102) IFRAME 1 3

Serial1: LAPB I CONNECT (102) IFRAME 3 2

Serial1: LAPB O CONNECT (2) RR (R) 4

Serial1: LAPB O CONNECT (102) IFRAME 2 4

Serial1: LAPB I CONNECT (102) IFRAME 4 3

Serial1: LAPB O CONNECT (2) RR (R) 5

Serial1: LAPB O CONNECT (102) IFRAME 3 5

Serial1: LAPB I CONNECT (2) RR (R) 4

Serial1: LAPB I CONNECT (102) IFRAME 5 4

Serial1: LAPB O CONNECT (2) RR (R) 6

Serial1: LAPB O CONNECT (102) IFRAME 4 6

Serial1: LAPB I CONNECT (102) IFRAME 6 5

Serial1: LAPB O CONNECT (2) RR (R) 7

Serial1: LAPB O CONNECT (102) IFRAME 5 7

Serial1: LAPB I CONNECT (102) IFRAME 7 6

Serial1: LAPB O CONNECT (2) RR (R) 0

Albuquerque s0

Albuquerque s1

Yosemite s0

Yosemite s1

Seville s0

Seville s1

Serial0 is up, line protocol is up

Hardware is HD64570

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 32, LMI stat recvd 32, 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

Broadcast queue 0/64, broadcasts sent/dropped 75/0, interface broadcasts 59

Last input 00:00:00, output 00:00:07, output hang never

Last clearing of “show interface” counters never

Queuing 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

74 packets input, 5697 bytes, 0 no buffer

Received 32 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

110 packets output, 9438 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up DSR=up DTR=up RTS=up CTS=up

Serial0.1 is up, line protocol is up

Hardware is HD64570

Internet address is 168.10.202.1/24

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation FRAME-RELAY