CCNPTraining Kit

78700914.
book Page 18 Thursday, August 23, 2001 3:15 PM
18 Chapter 2: Selecting Cisco Products for Remote Connections
NOTE Remote access networks connect sites. Connection requirements vary, depending on user
requirements and costs.
This chapter discusses the various WAN technologies that are available.
Defining WAN Connection Types

The variety of WAN connection types offered by service providers can be grouped into the
following categories:
• Dedicated connectivity (leased lines)
• Circuit-switched networks
• Packet-switched networks
Dedicated Connections
A point-to-point dedicated link, as shown in Figure 2-1, provides a single, pre-established WAN
communications path from the customer premises, straight through a carrier network (the
telephone company), and to a remote network. Dedicated lines are also known as leased lines.
The established path is permanent and fixed for each remote network that is reached through
the carrier facilities. Point-to-point links are reserved full-time by the carrier company for the
private use of the customer. Point-to-point links are available full-time in all Cisco products.
Figure 2-1 Links Are Always Available with Dedicated Connections
EIA/TIA-232, EIA/TIA-449
V.35, X.21, EIA-530
CSU/DSU CSU/DSU
CSU/DSU CSU/DSU
78700914.book Page 19 Thursday, August 23, 2001 3:15 PM
Defining WAN Connection Types 19
The private nature of a dedicated leased-line connection allows a corporation to maximize its
control over the WAN connection. Leased lines also offer high speeds up to T3/E3 levels. They
are ideal for high-volume environments with steady-rate traffic patterns. However, because the
line is not shared, they tend to be more costly.
As a general rule, leased-line connections are most cost-effective when the following situations
occur:
• Long connect times
• Shorter distances
Pricing Strategies of WAN Services

Some WAN services, such as T1, provide a fixed fee for local loop access for both locations,
and then provide a distance fee for linking those two locations.
Dedicated leased lines typically require synchronous serial connections. The dedicated
connections are made by using the router’s synchronous serial ports with the bandwidth use of
up to 34 Mbps on an E3 and 45 Mbps on a T3, available through the use of a channel service
unit/data service unit (CSU/DSU). Different encapsulation methods at the data link layer
provide flexibility and reliability for user traffic. Typical connections on a dedicated network
employ 56 Kbps, 64 Kbps, T1, E1, T3, and E3 technologies.
The synchronous serial standards that are supported on Cisco routers are as follows (EIA/TIA
stands for Electronic Industries Association/Telecommunications Industry Association):
• EIA/TIA-232
• EIA/TIA-449
• V.35
• X.21
• EIA-530
A CSU/DSU is a digital interface device (or sometimes two separate digital devices) that adapts
the physical interface on a data terminal equipment (DTE) device (such as a terminal) to the
interface of a data circuit-terminating equipment (DCE) device (such as a switch) in a switched
carrier network. The CSU/DSU also provides signal timing for communication between these
devices. The graphic shows the placement of the CSU/DSU.
Different encapsulation methods at the Data Link layer provide flexibility and reliability for
user traffic.
Circuit-Switched Connections
Circuit switching is a WAN-switching method, in which a dedicated physical circuit through a
carrier network is established, maintained, and terminated for each communication session.
Initial signaling at the setup stage determines the endpoints and the connection between the two
endpoints.
NOTE Circuit switching requires call setup and call teardown. Circuit switching is used in the
telephone company networks and works like a telephone call.
Typical circuit-switched connections are as follows:

• Asynchronous serial
• Integrated Service Digital Network (ISDN), Basic Rate Interface (BRI), and ISDN
Primary Rate Interface (PRI)
Asynchronous Serial Connections

Asynchronous serial connections, as seen in Figure 2-2, require minimal cost and use the
existing telephone network. It is easy for users to access a Central site from anywhere that has
a telephone connection into the telephone network.
Figure 2-2 Connections Are Made Only When Traffic Dictates a Need
Modem
EIA/TIA-232 Telephone
company
network EIA/TIA-232
Modem
Modem
The nature of asynchronous serial circuit-switched connections allows you to configure your
connection to be enabled only when you need the service by using dial-on-demand routing
(DDR). DDR is ideal when you need only short-term access.
Enable DDR on your asynchronous interface under the following circumstances:
• Traffic patterns are low-volume or periodic—calls are placed and connections are
established only when the router detects traffic marked as “interesting.” Periodic
broadcasts, such as routing protocol updates, should be prevented from triggering a call.
Defining WAN Connection Types 21
• When you need a backup connection for redundancy or load sharing, DDR can be used to
provide backup load sharing and interface failure backup.
A router acts as an access server, which is a concentration point for dial-in and dial-out calls.
Mobile users, for example, can call into an access server at a Central site to access their e-mail
messages.
Asynchronous connections are useful in the following situations:
• A backup connection is required
• A small site
• Short-term on-demand access
Asynchronous serial connections require modems at each end of the connection to convert
digital data signals to analog signals that can be transported over the telephone network.
Modem speeds typically vary from 28 Kbps to 56 Kbps. The slower bandwidth speeds limit the
amount of traffic that you may want to send over an asynchronous line. To place or receive an
asynchronous serial call, a Cisco router should have an asynchronous serial interface. The serial
standard to attach to an external modem is the EIA/TIA-232 standard. The interface to the
telephone company varies by country. In the United States, a standard RJ-11 adapter connects
the modem to the telephone outlet.
ISDN Connections
ISDN connections are typically circuit-switched connections that (like asynchronous
connections) provide WAN access when needed, rather than requiring a dedicated link. ISDN
offers increased bandwidth over a typical dial-up connection; it is intended to carry data, voice,
and other traffic across a telephone network. ISDN comprises Basic Rate Interface (BRI) and
Primary Rate Interface (PRI), which are illustrated in Figure 2-3.
Figure 2-3 Circuit-Switched Connection with ISDN
BRI
NT1
ISDN
Switch service
PRI provider
CSU/DSU
Link Access Procedure on the D channel (LAPD) is the ISDN data link layer protocol for the
D channel. It was designed primarily to satisfy the signaling requirements of ISDN basic
access.
To place an ISDN BRI call, your router should be equipped with a BRI interface. You will also
need an ISDN terminal adapter, which is a device used to connect ISDN BRI connections to
other interfaces, such as EIA/TIA-232. A terminal adapter is essentially an ISDN modem. You
should also consult your telephone company for information specific to your connection.
NOTE In Europe, the service provider generally supplies the NT1. In North America, the customer
supplies it.
ISDN PRI is generally configured over connections such as T1 and E1 technologies. To place
an ISDN call, your router should be equipped with either connection. TI is used in the United
States and E1 is common in Europe.
As with asynchronous connections, you can also configure DDR to control access for specific
periods of time.
Packet-Switched Connections
Packet switching is a WAN-switching method, in which network devices share a single point-
to-point link to transport packets from a source to a destination across a carrier network. Packet-
switched networks use virtual circuits (VCs) that provide end-to-end connectivity, as shown
in Figure 2-4. Physical connections are accomplished by statistically programmed switching
devices. Packet headers generally identify the destination.
Figure 2-4 VCs—Interconnect Sites
Synchronous
serial Synchronous
CSU/DSU VC serial
CSU/DSU
CSU/DSU
Packet-switched networks can be either privately or publicly managed. The underlying

switching fabric is transparent to the user, and the switches are only responsible for the internal
delivery of data.
Packet-switched networks offer an administrator less control than a point-to-point connection,
and the bandwidth is shared. However, the cost is generally less than a leased line. With WAN
speeds comparable to those of leased lines, packet-switched networks are generally suitable
links between two large sites that require high link utilization.
Like dedicated lines, packet-switched networks are also typically employed over synchronous
serial connections. The connection standards that are supported on Cisco routers are listed in
Figure 2-1.
Defining WAN Encapsulation Protocols 23
As a general rule, packet-switched connections are most cost-effective when the following
situations occur:
• Long connect times
• Large geographic differences
NOTE Packet-switched networks generally share bandwidth, but the cost is cheaper than a leased line.
Defining WAN Encapsulation Protocols

Each WAN connection uses an encapsulation protocol to encapsulate traffic while it is crossing
the WAN link. To ensure that the correct encapsulation protocol is used, you need to configure
the Layer 2 encapsulation type to use. The choice of encapsulation protocol depends on the
WAN technology and the communicating equipment. Typical WAN protocols include the
following:
• Point-to-Point Protocol (PPP)
• Serial Line Internet Protocol (SLIP)—SLIP is a standard protocol for point-to-point serial
connections using a variation of TCP/IP. SLIP is the predecessor of PPP.
• High-Level Data Link Control (HDLC)—HDLC is the default encapsulation type on
point-to-point, dedicated links. It is used typically when communicating between two
Cisco devices. It is a bit-oriented synchronous data link layer protocol. HDLC specifies a
data-encapsulation method on synchronous serial links using frame characters and
checksums. If communicating with a non-Cisco device, synchronous PPP is a more viable
option.
• X.25/Link Access Procedure, Balanced (LAPB)
• Frame Relay
• Asynchronous Transfer Mode (ATM)—ATM is the international standard for cell relay,
in which multiple service types (such as voice, video, or data) are conveyed in fixed-length
(53-byte) cells. Fixed-length cells allow processing to occur in hardware, thereby
reducing transit delays. ATM is designed to take advantage of high-speed transmission
media such as E3, Synchronous Optical Network (SONET), and T3.
NOTE SLIP, HDLC, and ATM are not covered in the BCRAN course, and thus are not discussed
further in this book.
PPP Encapsulation
PPP is an international standard encapsulation used for the following types of connections:
• Asynchronous serial
• ISDN
• Synchronous serial
Because it is standardized, PPP supports vendor interoperability. PPP uses its Network Control
Protocol (NCP) component to encapsulate multiple protocols, as shown in Figure 2-5. This use
of NCPs surpasses the limits of SLIP, the predecessor of PPP, which could only set up transport
for IP packets.
Figure 2-5 Overview of PPP Components
Multiple protocol
encapsulations using NCPs
in PPP
TCP/IP
PPP
IPX
encapsulation
Appletalk
Link setup and control

using LCP in PPP
PPP uses another of its major components, the Link Control Protocol (LCP), to negotiate and
set up control options on the WAN data link. Some of the PPP LCP features covered in this
course follow:
• Authentication
• Compression
• Multilink
X.25 and Frame Encapsulations

X.25 encapsulation is typically seen in a packet-switched environment. In X.25 packet-
switched networks, the LAPB protocol is the Data Link layer, Layer 2 protocol used to
encapsulate X.25 packets. X.25 evolved in the days of analog circuits when error rates were
much higher than today, so reliability was built into the X.25 framework.
Like X.25, Frame Relay is an industry-standard Data Link layer protocol that is commonly used
in packet-switched networks. Frame Relay supports technological advances such as fiber-optic
cabling and digital transmission. Frame Relay can eliminate time-consuming processes (such
Selecting WAN Configuration Types 25
as error correction and flow control) that are necessary when using older, less reliable WAN
media and protocols.
Because you are using a public network, you must consult with your service provider and obtain
information specific to your link.
Determining the WAN Type to Use

When you design internetworks, you need to make several key decisions concerning
connectivity between different users or groups of users in your WAN environment.
When selecting a WAN connection, you should also consider the following:
• Availability Each method of connectivity has characteristics inherent in its design,
usage, and implementation. For example, Frame Relay is not available in all geographic
regions.
• Bandwidth WAN bandwidth is expensive, and organizations cannot afford to pay for
more bandwidth than they need. Determining usage over the WAN is a necessary step
toward evaluating the most cost-effective WAN services for your needs.
• Cost WAN usage costs are typically 80 percent of the entire Information Services
budget. When different WAN services and different service providers are evaluated, cost
is a major consideration. If, for example, you use the line for only one hour a day, you may
want to select a dial-on-demand connection, such as an asynchronous or ISDN
connection.
• Ease of management Network designers are often concerned about the degree of
difficulty associated with managing connections. Connection management includes both
the configuration at initial startup and the outgoing configuration tasks of normal
operation. Traffic management is the connection’s capability to adjust to different rates of
traffic, regardless of whether the traffic is steady-state or bursty in nature. Dedicated lines
are often easier to manage than shared lines.
• Application traffic The application traffic may be many small packets, such as during
a terminal session; or very large packets, such as during file transfer.
• Quality of service and reliability How critical is the traffic intended to travel over the
link? A backup connection may be necessary.
• Access control A dedicated connection may help control access, but electric commerce
cannot occur on a wide scale unless consumers access some portion of your network.
Selecting WAN Configuration Types

Figure 2-6 illustrates bandwidth and time-selection considerations (which increase cost) when
determining the best WAN technology to use. (The source of the figure is a 1995 study done by
the Forrester Research firm.) The network administrator must determine the best WAN
technology to implement, based on the amount of bandwidth and the time a user requires on the
network. As the time of use increases, WAN services associated with a variable cost, such as
dial-up, tend to be less advantageous. Likewise, as time of use decreases, WAN services
associated with a fixed cost become more advantageous.
Figure 2-6 Selection Considerations: Bandwidth and Connection Duration
Delay-
sensitive ISDN, VoFR, VoATM
voice/video
File
transfer
Analog Frame
Increasing ISDN
dialup Relay
bandwidth
Client/
requirements
server
E-mail
Analog dialup
Terminal
emulation 0 1 2 3+
Hours/Day
WAN Connections—Speed Comparison

Figure 2-7 illustrates the WAN speeds for typical technologies. This helps a network
administrator select a WAN option, based on the amount of required bandwidth.
Figure 2-7 Typical WAN Speeds

WAN Connection
Leased line, Frame Relay
ISDN—PRI
X.25, ISDN—BRI
Asynchronous
Dialup
9.6k 56/64 kbps 128 kbps E1/T1 E3/T3
Theoretical maximum WAN speeds
The speeds, costs, and availability vary internationally. For example, in North America, high-
bandwidth speeds such as T1 are easily available at reasonable prices. Europe offers
comparable speeds like E1, but the prices tend to be higher.
Identifying Site Requirements 27
WAN Connections Summary

Each WAN connection has advantages and disadvantages. For example, setting up a dial-up
asynchronous connection offers only limited bandwidth, but a user can call into the office from
anywhere over the existing telephone network. Table 2-1 compares considerations for various
types of WAN connections.
Table 2-1 Summarized Comparison of WAN Connections
Connection Type Applications
Leased lines High control, full bandwidth, high-cost enterprise networks, and
last-mile access
Frame Relay Medium control, shared bandwidth, medium-cost enterprise
backbones; branch sites
ISDN Low control, shared bandwidth, more bandwidth than dial-up
Asynchronous dial-up Low control, shared bandwidth, variably cost-effective; for
limited use connections like DDR
X.25 Low control, shared bandwidth, variably cost-effective; for
limited use connections, high reliability
Identifying Site Requirements

Considerations vary, depending on the requirements of various company sites. This section
discusses the WAN considerations that a network administrator must evaluate for a Central site,
a branch office, and a telecommuter site.
A company may have multiple sites that vary in size, as shown in Figure 2-8. A remote network
is necessary to connect the various locations in a company. Typical site locations include the
following:
• Central site The Central site is a large company site that is often the corporate
headquarters or a major office. This is the site that most other regional offices and
telecommuters connect into for data and information. Because users may access this site
via multiple WAN technologies, it is important that your Central site be designed to
accommodate many different types of WAN connections coming in from remote
locations. The Central site is often termed headquarters, the enterprise, or corporate.
• Remote site (branch office) The remote site is a smaller office that generally houses
employees who have a compelling reason to be located in a specific region. A remote site
is generally established to give a company local regional presence. A typical employee at
a remote site may be a regional salesperson. Remote site users must be able to connect to
the company site to access company information. Remote sites are sometimes termed
branch offices, remote office/branch offices (ROBOs), or sales offices.
Identifying Site Requirements 29
The technologies and features that are used to connect company campuses over a WAN are
developed to optimize the WAN bandwidth, minimize the cost, and maximize the effective
service to the end users. You should choose the WAN architecture that provides the most cost-
effective bandwidth and a technology that optimizes service to end users. With that in mind,
Central site considerations include the following:
• Multiple access connections Multiple users connect to the Central site by using
different media. So, Central site considerations must include multiple media options and
simultaneous access from multiple users.
• Cost Keep the costs low while maintaining an adequate level of service. For example,
because some WAN charges are based on usage, such as ISDN, it is important that
companies have a solution that can implement features that will optimize bandwidth and
minimize WAN costs. Features such as DDR and compression ensure that WAN costs are
kept to a minimum. In another example, because leased lines are generally charged on a
fixed basis, you may want to consider this service only if the line can sustain a certain link-
utilization level.
• Access control Company information must be restricted, allowing users access only to
areas in the network that they are authorized to access. For example, access-lists can filter
out unauthorized data flow between offices and PPP network links, whereas Password
Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol
(CHAP) can identify the remote entity to prevent unauthorized network connection.
• Quality of service It is important to prioritize traffic over the link and manage traffic
flow so that bursty traffic does not slow mission-critical traffic.
• Redundancy and backup Because a link may fail or high link utilization may occur at
certain peak usage times during the day, it is important to back up the connection to the
central office. Avoid backing up links using the same service provider.
• Scalability Build a network that will grow with the company.
NOTE The primary considerations for the Central site are to provide access to multiple users and
control the network costs.
Branch Office Considerations

A remote site is a small-site connection to a campus over a WAN. Remote is characterized by
having fewer users than the Central site, so it needs a smaller-size WAN connection.
Remote sites connect to the Central site and to some other remote site offices. Telecommuters
may also require access to the remote site. A remote site can use the same or different media.
Remote site traffic can vary, but it is typically sporadic. The network designer must determine
whether it is more cost-effective to offer a permanent or dial-up solution.
The remote site must have a mix of equipment, but not as much as the Central site requires.
Typical WAN solutions that a remote site uses to connect to the Central site are as follows:
• Leased line
• Frame Relay
• X.25
• ISDN
Typical considerations for a remote site WAN connection follow:
• Multiple access connections Multiple users connect to the Central site by using
different media. Therefore, Central site considerations must include multiple media
options and simultaneous access from multiple users.
• Cost Keep the costs low while maintaining an adequate level of service. For example,
because some WAN charges are based on usage, such as ISDN, it is important that
companies have a solution that can implement features that will optimize bandwidth and
minimize WAN costs. Features such as DDR and compression ensure that WAN costs are
kept to a minimum. In another example, because leased lines are generally charged on a
fixed basis, you may want to consider this service only if the line can sustain a certain link
utilization level.
• Access control Company information must be restricted, allowing users access only to
areas in the network that they are authorized to access. For example, access-lists can filter
out unauthorized data flow between offices and PPP network links, whereas Password
Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol
(CHAP) can identify the remote entity to prevent unauthorized network connection.
• Quality of service It is important to prioritize traffic over the link and manage traffic
flow so that bursty traffic does not slow mission-critical traffic.
• Redundancy and backup Because a link may fail or high link utilization may occur at
certain peak usage times during the day, it is important to back up the connection to the
central office. Avoid backing up links by using the same service provider.
• Authentication The remote site must be able to authenticate itself to the Central site.
• Availability Service providers may not offer certain WAN services in some regions.
This consideration generally becomes more critical as sites are set up in more remote
locations
NOTE The primary consideration for the branch office is that it be able to access the Central site.
Figure 2-9 Cisco Access Servers and the Sites for Which They Are Suited
7200
Series
AS5000
Series
4000
Series
3600
Series
2600
Series
2500
Series
1700
Series Central site solutions
1600
Series
1000
Series
800
Series
700
Series Branch office solutions
Small office solutions

Residential telecommuter site solutions
The Cisco 700 series, designed for telecommuters, is a low-cost, easy-to-manage, multiprotocol
ISDN router. The 700 router has been optimized for interoperability with Cisco core networks,
although these routers can connect to any network that supports the relevant standards for ISDN
and IP/Internetwork Packet Exchange (IPX) routing.
The Cisco 800 series routers are Cisco’s lowest-priced routers that are based on Cisco IOS
software. The 800 series ISDN access routers provide big-business networking benefits to small
offices and corporate telecommuters. The Cisco 800 series offers secure, manageable, high-
performance solutions for Internet and corporate LAN access.
The Cisco 1000 series router is intended for remote office networking where Cisco IOS
software, higher performance, and WAN options beyond ISDN are important.
The Cisco 1600 series routers are similar to the Cisco 1000 series routers, but they have a slot
that accepts a WAN interface card. These cards are shared with the 1700, 2600, and 3600 series,
and will be shared in future modular branch office-type products.
The Cisco 1720 access router delivers optimized security, integration, and flexibility in a
desktop form factor for small- and medium-sized businesses, and for small branch offices that
want to deploy Internet/intranet access or Virtual Private Networks (VPNs). The Cisco 1720
access router features two modular WAN slots that support 1600, 2600, and 3600 data WAN
interface cards; and an autosensing 10/100-Mbps Fast Ethernet LAN port to provide investment
protection and flexibility for growth.
The Cisco 2500 series routers provide a variety of models that are designed for branch office
and remote site environments. These routers are typically fixed configuration, with at least two
of the following interfaces: Ethernet, Token Ring, synchronous serial, asynchronous serial,
ISDN BRI, and a hub.
Selecting Cisco Remote Access Solutions 33
The Cisco 2600 series features single or dual fixed LAN interfaces. A network module slot and
two WAN interface card slots are available for WAN connections.
The 3600 series multiservice access servers/routers also offer a modular solution for dial-up and
permanent connectivity over asynchronous, synchronous, and ISDN lines. Up to four network
module slots are available for LAN and WAN requirements.
The Cisco 4500 and 4700 series access routers are high-performance modular Central site
routers with support for a wide range of LAN and WAN technologies. The 4500 and 4700 are
intended for large regional offices that do not require the density of the 7200 series. Their
modular design allows easy reconfiguration as needs change.
The Cisco AS5000 series is Cisco’s line of universal integrated access servers. The AS5000
series is extremely popular because it integrates the functions of standalone CSUs, channel
banks, modems, communication servers, switches, and routers in a single chassis. The AS5000
series contains synchronous serial, digital ISDN, and asynchronous modem access server
functionality, which are ideal for the mixed-media requirements that are becoming more
prevalent every day.
The Cisco 7200 routers are also very high-performance, modular Central site routers that
support a variety of LAN and WAN technologies. The 7200 is targeted for large regional offices
that require high-density solutions.
Table 2-2 highlights some of the features and WAN options for each series of routers.
Table 2-2 Remote Access Options for Each Series of Router
Router
Platform Remote Access Options
700 series ISDN BRI, basic telephone service ports
800 series ISDN BRI, basic telephone service ports, entry-level Cisco IOS software
1000 series ISDN BRI, serial (1005 router)
1600 series ISDN BRI, 1 WAN interface card slot
1700 series Two WAN interface card slots
2500 series Family of routers that offers various ISDN BRI, serial, and WAN interfaces
2600 series Various fixed LAN interface configurations, one network module slot, two WAN
interface card slots
3600 series Two and four network module slots on the 3620 and 3640, respectively
4000 series T1/E1 ISDN PRI
AS5000 series Access server with multiple T1/E1 ISDN PRI and modem capabilities
7200 series Supports a wide range of WAN services, with the required high port density
necessary for a scalable enterprise WAN
Selecting Products with Cisco Product-Selection Tools 35
in Figure 2-11. Although modular routers require more equipment than the physical router, they
are more scalable as your network grows and your needs change.
Figure 2-11 Modular Configuration Router
Vacant chassis slot
Slot 3 Slot 2
Slot 1 Slot 0
2E
2W W1 WO
10BaseT AUI port

LEDs port
STP
ACT
ACT
LNK
LNK
AUI
EN
ETHERNET 1 ETHERNET 0
WAN interface cards 10BaseT LEDs

slide into network modules port Network modules slide into Enable
vacant chassis slots LED
Selecting Products with Cisco Product-Selection Tools

To assist you with product selection, Cisco has extensive documentation and product-specific
information on its Web site at www.cisco.com. You will also find product selection and
configuration tools. These tools are designed to help you determine and configure the router that
best suits your requirements.
One such tool that you will see on the Cisco Web site is a product selection tool, which is shown
in Figure 2-12. The product selection tool allows you to identify your requirements. From the
specifications that you highlight, the product selection tool will identify the routers available to
suit the requirements.
40 Chapter 3: Assembling and Cabling the WAN Components
such as ISDN BRI to the Central site router. You will also learn how to configure a mobile user
with a PC and a modem to allow an asynchronous connection to a company site router.
Network Overview
To build the network, you must select equipment for various company sites. Equipment needs
vary by site. Typical site router considerations and their needs follow.
The Central site router must have the following interfaces:
• PRI interface for ISDN PRI and asynchronous calls Service Unit (CSU/DSU)
• Modem for asynchronous calls
• Serial interface for Frame Relay connections
• Ethernet connection to connect to the Authentication, Authorization, and Accounting
(AAA) server
NOTE If you are in North America, you typically provide the Channel Service Unit/Data. Service
providers also offer rentals.
The branch office router must have the following interface:

• Serial interface for Frame Relay connections
NOTE If you are in North America, you must provide the network termination 1 (NT1).
The telecommuter site must have the following interfaces:

• PC and modem for asynchronous dial-up calls
• BRI interface for ISDN BRI
You also need to work with your service provider to make the proper connections into the
provider’s network. Your lab will connect to equipment that will simulate a service provider’s
network.
Identifying Company Site Equipment

This section will show you router assembly examples for the various company sites.
Identifying Company Site Equipment 41
Central Site Router Equipment

Choose the router that supports the WAN protocols that you will use. The 3600 series router
and network modules will support the interfaces in the network topology illustrated in the
“Network Overview” section.
When selecting a Central site router, typical Cisco solutions include the following:
• Cisco 3600 series
• Cisco AS5x00 series
Cisco 3600 series

The Cisco 3600 series is a multifunction platform that combines dial access, routing, and LAN-
to-LAN services and multiservice integration of voice, video, and data in the same device. The
Cisco 3600 series includes the Cisco 3640 and Cisco 3620 access servers/routers.
Cisco 4000 series

The Cisco 4000 series models provide a configurable modular router platform by using network
processor modules—individual removable cards used for external network connections.
Because the router's modules support many variations of protocols, line speeds, and
transmission media, the Cisco 4000 series can accommodate all types of network-computing
environments.
Cisco AS5x00 series

The Cisco AS5X00 family of access servers provides carrier class scalability, and multiprotocol
capabilities for both Internet Service Providers and enterprises. The Cisco AS5X00 product
series supports universal dial access by providing both analog modem and Integrated Services
Digital Network (ISDN) support over the same bearer line, and world wide dial access by
providing multiple trunk-line signaling protocols.
Cisco 7000 series

The Cisco 7000 series routers combine proven software technology with reliability, availability,
serviceability, and exceptional performance features. With Cisco 7000 series, Port and Service
adapters provide connection to external networks. The 7200 series supports any combination of
Ethernet, Fast Ethernet, Token Ring, FDDI, ATM, serial, ISDN, and HSSI interfaces.
Branch Office Router Equipment

Choose the router that supports the WAN protocols and interfaces you will use. For example,
the 1600 series router and the respective WAN interface card is an example of a branch office
router that will support the interfaces required in the network topology illustrated in the
“Network Overview” section.
When selecting a branch office router, typical Cisco solutions include the following:
Cisco 1600 Series

The Cisco 1600 series routers connect small offices with Ethernet LANs to the public Internet,
and to a company's internal intranet or corporate LAN through several WAN connections such
as ISDN, asynchronous serial, and synchronous serial. All Cisco 1600 series models include
one or two Ethernet ports, and one WAN interface card expansion slot for additional
connectivity and flexibility.
Cisco 1700 Series

The Cisco 1700 router is a small, modular desktop router that links small- to medium-size
remote Ethernet and FastEthernet LANs over one to four WAN connections to regional and
central offices.
Cisco 2500 Series

The Cisco 2500 series routers provide a variety of models that are designed for branch office
and remote site environments. These routers are typically fixed-configuration with at least two
of the following interfaces: Ethernet, Token Ring, synchronous serial, ISDN BRI, and Hub.
Cisco 2600 Series

The Cisco 2600 series is a family of modular access routers that offers network managers and
service providers an attractively priced remote branch office solution, providing the versatility
needed to adapt to changes in network technology as new services and applications become
available. With full support of the Cisco IOS software, the Cisco 2600 series modular
architecture provides the power to support the advanced Quality of Service (QoS), security, and
network-integration features that are required in today's evolving enterprise and service
provider networks.
Assembling and Cabling the Network 43
Telecommuter Site Router Equipment

Choose the router that supports the WAN protocols and interfaces that you will use. When
selecting a branch office router, typical Cisco solutions include the following:
• Cisco 700 series (760 or 770)
Cisco 700 Series (760 or 770)

The Cisco 700M family products are low-cost, easy-to-manage multiprotocol ISDN access
routers. These devices provide small professional offices, home offices, and telecommuters
with high-speed remote access to enterprise networks and the Internet.
Cisco 800 Series

The Cisco 800 Series router is the entry-level platform that contains Cisco IOS technology.
Ideal for use as customer premises equipment (CPE), service providers can lease or sell Cisco
800 series routers to small offices with Ethernet LANs for Internet access using Integrated
Services Digital Network (ISDN) connections.
Cisco 1000 Series

The Cisco 1000 series LAN extenders and routers are easy-to-install, inexpensive,
multiprotocol access products, designed for small offices and other remote sites.
Assembling and Cabling the Network

Figure 3-2 illustrates the cable connections available for the various WAN types.
Verifying Network Installation 45
• Frame Relay (5)—If you must establish a Frame Relay serial connection, Cisco routers
support the following signaling standards: EIA/TIA-232, EIA/TIA-449, V.35, X.21, and
EIA-530. Cisco supplies a DB-60 shielded serial transition cable that has the appropriate
connector for the standard you specify. The router end of the shielded serial transition
cable has a DB-60 connector, which connects to the DB-60 port on the router’s serial
interface.
The other end of the serial transition cable is available with the connector that is appropriate for
the standard you specify. For specific cabling information, refer to the installation and
configuration guide that came with your router. For information regarding cable pinouts, refer
to the cable specification documentation. It is available on the Cisco Web site, and in the
installation and configuration guide that came with your router.
Verifying Network Installation

This section contains information about how you can use the LEDs on your Cisco equipment
to verify proper installation.
Verifying Central Site Installation

Each Central site router has LED displays that allow you to verify that the router components
are installed and functioning properly.
NOTE For LED information that is specific to your router, refer to the installation and configuration
guide that accompanied your router.
On the Cisco 3600 router, the LEDs on the front of the router enable you to determine router
performance and operation, as shown in Figure 3-3. The ready LED indicates that a functional
module has been installed in the indicated slot. If the LED is off, the slot is empty or the module
is not functional. The active LED blinks to indicate network activity on the module installed in
the indicated slot.
Figure 3-3 Cisco 3600 Router LEDs
All network modules have an enable (EN) LED. The enable LED indicates that the module has
passed its self-tests and is available to the router.
Figure 3-6 Digital Modem Network Module
DIGITAL MODEMS
• MICA • • MICA • • MICA • • MICA • • MICA •

BANK 0 BANK 1 BANK 2 BANK 3 BANK 4 EN
EN
Each port on the serial network module has the additional LEDs, as shown in Figure 3-7.
Descriptions of the LEDs follow:
• CN/LP Connect when green; loopback when Yellow
• RXC Receive clock
• RXD Receive activity
• TXC Transmit clock
• TXD Transmit activity
Figure 3-7 Serial WAN Interface Card
SERIAL
A/S
CN/LP RXC RXD TXC TXD CN/LP RXC RXD TXC TXD CN/LP RXC RXD TXC TXD CN/LP RXC RXD TXC TXD
3 2 1 0 EN
Verifying Branch Office Installation

Each branch office router has LED displays that allow you to verify that the router components
are installed and functioning properly.
On the 1603 or 1604, you can use the LEDs on the front of the router to determine router
performance and operation, as shown in Figure 3-8.
Figure 3-8 Cisco 1600 LEDs
BRI 0 WIC
B1 CD
SYSTEM LAN
PWR COL
OK ACT
B2 ACT
The LEDs and their descriptions follow:

• SYSTEM PWR The green system power LED indicates that the router is turned on and
DC power is being supplied.
• SYSTEM OK The green system OK LED indicates that the router has successfully
booted. It blinks while in the boot cycle.
• BRI 0 B1 The green B1 LED indicates an ISDN connection on B channel 1.
• BRI 0 B2 The green B2 LED indicates an ISDN connection on B channel 2.
• WIC CD The green WAN interface card connection LED indicates an active connection
on the WAN interface card serial port.
• WIC ACT The green WAN interface card activity LED indicates an active connection
on the WAN interface card serial port.
• LAN ACT The green LAN activity LED indicates that data is being sent to or received
from the local Ethernet LAN.
• LAN COL A flashing yellow LAN collision LED indicates frame collisions on the local
Ethernet LAN.
NOTE For a Cisco 1600, the system power and OK LEDs indicate that the router is on and has
successfully booted.
The one-port serial WAN interface card has one LED (CONN), indicating that data is being sent
over the WAN interface card serial port, as shown in Figure 3-9.
Figure 3-9 Cisco 1600—Serial WAN Interface Card
Serial CONN LED
CONN SERIAL
Verifying Telecommuter Site Installation

Each telecommuter site router has LED displays that allow you to verify that the router
components are installed and functioning properly.
On the 766 router, you can use the LEDs on the front of the router to determine router
performance and operation, as shown in Figure 3-10.
Figure 3-10 Cisco 700 LEDs
LAN RXD TXD CH1 RXD TXD CH2 RXD TXD

RD NT1 LINE PH1 PH2
The 700 series LEDs and their descriptions are as follows:

• RD The ready LED indicates the router operating status. This LED is on when power is
supplied to the router, the router passes the self-test, and it is operating normally.
• NT1 On 700 series routers that have an internal NT1, the on LED indicates that the NT1
and ISDN switch have synchronized over the ISDN line. When blinking five blinks per
second, the internal NT1 is attempting to synchronize with the telephone switch. When
blinking one blink per second, the internal NT1 is attempting to synchronize with the
ISDN terminal devices.
• LINE An online LED indicates synchronization between the NT1 S interface and the
ISDN terminal device(s). It also indicates framing between the router and the ISDN
switch.
• LAN An on LAN LED indicates that frames have been sent to or received from the
Ethernet within the last minute.
• LAN RXD The receive LAN LED blinks when frames are received from the Ethernet.
• LAN TXD The transmit LAN LED blinks when frames are sent to the Ethernet.
• CH1 The channel 1 LED blinks when a call is connected on the first ISDN B channel.
After the call is established, the LED remains on.
• CH1 RXD The channel 1 received LED blinks when packets are received from the first
ISDN B channel.
• CH1 TXD The channel 1 transmitted LED blinks when packets are sent on the first
ISDN B channel.
• CH2 The channel 2 LED blinks when a call is connected on the second ISDN B channel.
After the call is established, the LED remains on.
• CH2 RXD The channel 2 received LED blinks when packets are received from the
second ISDN B channel.
• CH2 TXD The channel 2 transmitted LED blinks when packets are sent on the second
ISDN B channel.
• PH1, PH2 Plain Old Telephone System (POTS) ports are on when a telephone, fax, or
modem is in use.
58 Chapter 4: Configuring Asynchronous Connections with Modems
Figure 4-3 The DTE-DCE Interface
EIA/TIA-232
EIA/TIA-232
or X.21
or X.21
DTE DCE DCE DTE
• DTE = Data terminal equipment

• DCE = Data communications equipment
The EIA/TIA-232 standard defines the interface between DTE and DCE. TIA stands for
Telecommunications Industries Association.
The end-to-end communication path between two DTEs consists of three segments (as
illustrated in Figure 4-3): DTE-DCE, DCE-DCE, and DCE-DTE. You must administer a
set of cabling and configuration elements for each segment.
NOTE The EIA/TIA-232-C (formerly known as RS-232-C) standard is the most commonly used
asynchronous interface for data communications in North America. The RS-232 standard was
first issued in 1962, and its third revision, RS-232-C, was issued in August 1969. Although the
ubiquitous D-shaped 25-pin connector (DB-25) has become the market norm for EIA/TIA-232-
C interfaces, it was not specified in the original RS-232-C standard. Many EIA/TIA-232-C
devices use other connectors, such as the DB-9 or RJ-11/RJ-45 modular connectors. X.21 is
a European standard that defines the DCE-DTE interface. For more information on these and
other standards, refer to Cisco Connection Online (CCO) or another data communications
reference text.
Modem Signaling and Cabling

A number of different standards define the signaling over a serial cable, including EIA/TIA-
232, X.21, V.35, EIA/TIA-449, EIA-530, and EIA-613 HSSI. Each standard defines the signals
on the cable and specifies the connector at the end of the cable.
With the 25-pin connector of EIA/TIA-232 standard, only eight pins are actually used for
connecting a DTE (such as an access server) to a DCE (such as a modem). The other 17 signals
are not interesting and are ignored. The eight interesting signals (pins) can be grouped into three
categories by their functionality:
Modem Signaling and Cabling 59
• Data transfer group

• Hardware flow control group
• Modem control group
Figure 4-4 illustrates these three groups.
Data Transfer Group

The data transfer group signals and pin designation, also known as pinout, for the EIA/TIA-232
specification in Figure 4-4 are explained in Table 4-1.
Figure 4-4 Data, Flow Control, and Modem Signaling
DTE
DCE
Data TxD 2 2 TxD

transfer RxD 3 3 RxD
Ground GRD 7 7 GRD
Hardware
RTS 4 4 RTS
flow
CTS 5 5 CTS
control
Modem DTR 20 20 DTR

control CD 8 8 CD
DSR 6 6 DSR
DB-25 pins
Table 4-1 Data Transfer Group
Signal Description
TxD Transmit Data. The DTE transmits data to the DCE.
RxD Receive Data. The DTE receives data from the DCE.
GRD Ground (pin 7). Provides the ground reference for voltage measurements.
Flow Control Group

Pins 4 and 5 form the hardware flow control group, as shown in Figure 4-4. These signals are
activated between the DCE and the DTE when the equipment is ready to accept data.
Table 4-2 explains the different flow control signals.
Table 4-2 Flow Control Group

Signal Description
RTS Request To Send. The DTE has buffers available to receive from the DCE. Originally
intended for the DTE to request to send data during a half duplex operation (in which
data can only be sent in one direction at
a time), this signal is now used for full duplex communication to indicate to the DCE
that the DTE is ready to receive data. This is a signal from the computer or router
telling the modem when to send data.
CTS Clear To Send. The DCE has buffers that are available to take data from the DTE.
Initially used by the DCE to indicate that the DTE could transmit in half duplex
mode in response to RTS. It is still used to indicate that the DTE may transmit for
hardware flow control under full duplex operation. This signal is used by the modem
to tell the computer when to send data.
Modem Control Group

Finally, the remaining interesting signals between a DTE device and a DCE form the modem
control group, covered in Table 4-3. These signals are used between the DTE and DCE to
initiate, terminate, and monitor the status of the connection.
Table 4-3 Modem Control Group
Signal Description
DTR Data terminal ready. This signal is controlled by the DTE. The DTE indicates to the
DCE that the equipment (computer or router) is connected and available to receive data.
CD Carrier Detect. This signal is controlled by the DCE, and it indicates that it has
established an acceptable carrier signal with a remote DCE (there is a DCE-to-DCE
connection).
DSR Data Set Ready (pin 6). The DCE is ready for use. This pin is not used on modem
connections. The DSR is active as soon as a modem is turned on.
TIP In the teletype days, flow control was done with inband signaling using Xon/Xoff. With higher
DTE speeds and faster workstations, modems and computers were not always able to exchange
this inband signaling in a timely fashion. Therefore, a set of electrical signals was developed to
manage the flow control and the modem control.
Communication Termination
Either the DTE device or the DCE device may signal for the connection to be terminated. The
signals that are used for this function are DTR from the DTE or the modem recognizing the loss
of the CD signal. Therefore, a modem connection can be terminated in two ways:
Modem Signaling and Cabling 61
• DTE initiated—The access server or computer can drop the DTR signal. The modem
must be programmed to terminate the connection on loss of DTR and restore to saved
settings in its NVRAM.
• DCE initiated—The access server detects Carrier Detect low and terminates the
connection. The modem must be programmed so that the CD reflects the state of the
carrier.
When modem control is not configured properly, the following symptoms might occur:
• The modem does not hang up when you quit your session. This means the DTR is not
dropped or recognized, so the modem is not aware that it should break the connection.
• You end up in someone else’s session, which means that the CD is not dropped or
recognized. This scenario happens when Caller A terminates its dial-up session, and the
modem does not pass the true state of the CD to the DTE. The access server is not aware
that Caller A terminated its session, so it maintains the line for Caller A. When a new
caller, Caller B, comes in by the same line (interface), the access server continues with the
session previously initiated by Caller A, instead of starting a new one. Thus, Caller B ends
up in Caller A’s session without having to authenticate. It is, therefore, very important that
the true state of CD be always passed back to the DTE, so the access server terminates
sessions when callers hang up.
Modem Operation
Modems perform their basic operations as follows (in one direction) and as seen in Figure 4-5:
1 Outgoing data from an originating DTE comes into the sending modem via the TxD pin.
2 If the sending modem’s buffer is nearly full, the modem can control flow (via hardware)
by lowering the CTS signal, thus instructing the DTE to not use TxD.
3 The data is compressed by using a proper algorithm (MNP 5 or V.42bis) that is mutually
agreed upon between the two communicating modems.
4 The data is then packetized, where windowing, checksum, error control (using MNP 4 or
LAP-M), and retransmission are performed.
NOTE Here, the term packetized is not referring to an IP packet or layer-3 PDU. Rather, it refers to the
preparation of the data by the modem.
5 The digital data is modulated into analog signals and sent out through the telephone
network.
type and protocol negotiations will take place for different types of devices attached to the
access server.
The remote host must specify a particular TCP port on the router to connect with individual
lines or to a rotary group. For example, if you wish to configure a modem connected to the
interface Asycn 7, you will make a reverse Telnet connection using port address 2007. Note
that TCP port number 2007 specifies a Telnet protocol connection (TCP port 2000) to line 7.
The individual line number is added to the end of the port number type.
Asynchronous Interfaces—Line Numbering

Refer to your Router’s manual to see how the lines are counted on that specific platform. As an
example, the Cisco 3640 that is represented in the following table has four slots and each of
those has preassigned line numbers, as follows:
97-128 65-96
33-64 1-32
The interface number of a port in a Cisco 3600 is determined by using the following formula:
Interface number = (32 × slot number) + unit number + 1
For example, asynchronous port 12 in slot 1 corresponds to interface number 45 ((32 × 1) + 12
+ 1 = 45). This is also the line number for the port. Port 12 in slot 1 is always assigned interface
number 45, regardless of whether the module in slot 0 is a 16-port asynchronous module, a
32-port asynchronous module, or some other type of module entirely; or even whether there is
a network module in slot 0 at all. If you move the module in slot 1 to a different slot, however,
its interface numbers change.
Table 4-5 shows the services provided, and the TCP port numbers for individual lines and rotary
groups.
Table 4-5 Services and Port Numbers for Lines and Rotary Groups101
Base TCP Port for Base TCP Port for
Services Provided Individual Lines Rotary Groups
Telnet protocol 2000 3000
Raw TCP protocol (no Telnet) 4000 5000
Telnet protocol, binary mode 6000 7000
Xremote protocol 9000 10000
Configuration for Asynchronous Connections 71
Use the transport input protocol command to specify which protocol to use when connecting
to a line using reverse Telnet. For example, transport input all allows all of the following
protocols to be used for the connection: lat, mop, nasi, none, pad, rlogin, Telnet, and v120. Each
of these protocols can be specified individually as a command option.
Reverse Telnet—Minimum Configuration

To successfully reverse Telnet to the modem attached to your router, the line interface must have
been configured with the transport input all and modem inout commands.
EXEC Connection Commands

Use the EXEC commands in this section to initiate and control a reverse Telnet terminal session
to a modem.
To make a connection with Telnet protocol:
Router>Telnet host [port] [/debug]
To disconnect the specified session or all sessions:

Router>disconnect [session-number]
To suspend a session:
Router>ctrl-shift-6 x
EXEC Command Description
Telnet host [port] [/debug] Makes a Telnet connection to a host (and optionally to a certain port). The
target host can be specified, either by a host name or an IP address. The
optional debug switch provides useful information about the connection by
displaying the informational level of logging messages. Additionally, you can
simply type the name of the host to which you wish to make the connection; by
default, an attempt to establish a Telnet session is started. The interface
through which the connection is made provides the source IP address for that
connection.
disconnect [session-number] Disconnects the specified connection, or disconnects the most recent
connection if not specified.
ctrl-shift-6 x To suspend the current session, simultaneously press the Ctrl, Shift, and 6
keys, followed by the x key.
Line Types and Numbering

Cisco devices have the following four types of lines:
• CON: Console line—Typically used to log in to the router for configuration purposes.
This line is also referred to as CTY.
• AUX: Auxiliary line—RS-232 DTE port used as a backup asynchronous port (TTY).
Cannot be used as a second console port.
• TTY: Asynchronous line—Same as asynchronous interface. Available on access server
models only (Cisco 2509, 10, 11, 12, AS5100, and Cisco 1001). Used typically for
remote-node, dial-in sessions that use such protocols as SLIP, PPP, and XRemote.
• VTY: Virtual terminal line—Used for incoming Telnet, LAT, X.25 PAD, and protocol-
translation connections into synchronous ports (such as Ethernet and serial interfaces) on
the router.
Different routers have different numbers of these line types. Figure 4-12 shows the Cisco line-
numbering rules, where n represents the first physical line after the Console line, and m refers
to the number of the vty line. For example, the vty 4 line corresponds to line 14 on a router with
eight TTY ports. Because line 0 is for the Console, lines 1 to 8 are the TTY lines, line 9 is for
the Auxiliary port, and lines 10 to 14 are for VTY 0 to 4.
Figure 4-12 Cisco Line Numbering
con line = 0
tty n line = n
aux line = last_tty + 1
vty n line = last_tty + 2 + m
TTY lines correspond to asynchronous interfaces on a one-to-one basis, and vty lines are virtual
lines that are dynamically assigned to the synchronous interfaces. Usually, you would associate
vty lines with incoming Telnet sessions.
NOTE Enter the interface line tty ? command to view the maximum number of TTY lines supported.
Connections to an individual line are most useful when a dial-out modem, parallel printer, or
serial printer is attached to that access server line. To connect to an individual line, the remote
Configuration for Asynchronous Connections 73
host or terminal must specify a particular Transmission Control Protocol (TCP) port on the
access server. If the Telnet protocol is used, that port is 2000 plus the line number. For example:
Router#Telnet 131.108.30.40 2001
This command indicates a Telnet connection to line 1 (2000 + 1).
Line Numbering On Cisco 1600

Some routers don’t have AUX ports, and the Cisco 1600 is one of them. The following shows
the way the relative and absolute line numbers are presented with the show line command:
Router#show line
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns
* 0 CTY - - - - - 0 1 0/0
2 VTY - - - - - 0 0 0/0
3 VTY - - - - - 0 0 0/0
4 VTY - - - - - 0 0 0/0
5 VTY - - - - - 0 0 0/0
6 VTY - - - - - 0 0 0/0
Line(s) not in async mode -or- with no hardware support: 1
The CTY port is the Console. As shown in Figure 4-12, the AUX port receives the number
TTY + 1. Because this Cisco 1600 router has no Async interface (no TTY), the AUX port, if
present, would have received 1 line number 1. The VTY lines are always as follows: Last_TTY
+ 2. Using the formula shown on Figure 4-12 to find the first VTY line number, calculate 0 TTY
+ 2 = 2, which is the starting number of VTY lines. By default, the router provides five virtual
connections; in this case, these are numbered 2, 3, 4, 5, and 6.
You can use the show line command to display all types of lines and the status of each line,
as exhibited in Figure 4-13. It also provides useful information about modem control and
asynchronous port configuration. The show line line-number command displays more detailed
information on the specified line, which includes some useful data such as baud rate, modem
state (idle or ready), and modem hardware state (CTS, DSR, DTR, and RTS for hardware flow
control and session control). Table 4-6 explains the output fields displayed in Figure 4-13.
Figure 4-13 emphasizes concepts previously discussed in this book, with the exception of
Access Class.
Filtering Traffic on VTY Lines—Access Class

If you wish to restrict incoming and outgoing connections between a particular virtual terminal
line (into a Cisco device), you can use the access-class command on a line. The access-class
command makes a standard access-list decide whether it should accept or reject a connection.
Basic Async Configuration—Modem Preparation 77
Command Description
password password Sets the password to be used when logging in to this line.
flowcontrol hardware Uses RTS/CTS for flow control.
speed 115200 Sets the maximum speed (in bits-per-second) between the modem and the
access server. The speed command sets both the transmit and receive speed.
transport input all Allows all protocols to be passed to the access server through this line.
stopbits 1 Sets the number of stop bits transmitted per byte.
modem inout Uses the modem for both incoming and outgoing calls.
modem dialin For incoming calls only. This is the default.
WARNING Software flow control (xon and xoff characters) is not recommended with modems and Cisco
routers.
Basic Async Configuration—Modem Preparation

A modem can be configured in many different ways to work with a router.
Figure 4-14 shows that you can manually configure a modem by sending AT commands. You
may want to have the router automatically discover and configure the modem, or you may wish
to specify to the router which configuration commands to send to the modem.
Figure 4-14 Modem Configuration Can Be Done Manually or Automatically

Modem configuration
Manual Automatic
(Reverse
Telnet)
Modemcap Autodiscovery
database by the router
Using a pre-defined Editing a pre-defined

configuration configuration
All these configuration methods are explored in greater detail in the following sections.
Manual Configuration of Modems

You can elect to manually configure the modem instead of having the router force a
configuration on it.
Standard Commands
On the modem side, you can use the standard configuration commands to do the following:
• Perform hardware flow control.
• Lock DTE speed to ensure that the modem will always communicate with the access
server at the specified speed. As an example, when you use an async interface, you lock
the speed to its theoretical maximum of 115.2 kbps. The router speed command sets both
transmit and receive speeds.
• Hang up when you quit a session.
• Have the Carrier Detect signal truthfully reflect the carrier state.
To manually configure your modem, you most likely reverse Telnet to your modem and apply
some AT commands. AT stands for attention commands for the modem. In general, each
modem vendor has its own modem command set that differs from other vendors’ command
sets. However, the following modem commands are common among most vendors:
Command Description
AT&F Loads the factory default settings (read-only).
ATS0=1 Sets the modem to automatically answer all incoming calls on the first ring.
(Recommended to be set to 2 for lines with caller ID.)1
AT&C1&D3 Sets up modem control (CD and DTR).
ATS2=255 Ignore the +++ command. The +++ characters set the modem to command
mode. You might need to configure the far-end modem to ignore +++
because the +++ command issued to the near-end modem will be
transmitted to the far-end modem. The far-end modem might interpret it
and cause the connection to hang. This is a bug in the far-end modem.
Many modems might operate this way.
ATE0 When echo off is set, the modem will not echo keystrokes.
ATM0 Turns off the external audio output from the modem.
1. Warning: Because the Caller ID function activates on the second ring, hackers typically target modems that
answer on the first ring. If a modem takes more than one ring to answer, many hackers don’t pursue the matter.
You are therefore advised to set your modem to at least ATS0=2, thus pretending that your line subscribes to
Caller ID.
Also, for a list of AT commands for various modem types and their specific initializing strings,
refer to Appendix D, "AT Commands for Modems and Chat-Scripts."
Automatic Configuration of Modems

Modem autoconfiguration facilitates the configuration of modems on access servers. To set
up a modem using modem autoconfiguration, connect the phone line and power cable to the
modem, and use the modem autoconfigure command on the line with the modem. No other
setup function is required for most modems.
To better understand modem autoconfiguration, this section contains the following topics:
• Modem capability database (modemcap file in the Cisco IOS software)—Modemcap is a
database of modems and their modem configuration command strings.
• Modem autodiscovery—You can configure a line to automatically attempt to discover the
type of modem on the line and to use that modem configuration.
• Modem autoconfiguration—You can configure a line to use a specified modem type.
Modem Capability Database

The modem capability database (modemcap) is a list of modems with a known set of AT
configuration commands for setting each modem type’s attributes. For example, many
modems use the string AT&F to reset the modem to its factory default attributes.
Modem attributes have a full name and a two- or three-letter abbreviation.
Factory default, for example, is also referred to as FD. For normal operation, you need not know
these abbreviations. If you are familiar with the modem abbreviations, you can add entries to
the modemcap database.
The modemcap database contains entries for supported modems. You can do the following tasks
to manage a modemcap database entry:
• View modem entries in the modemcap database with the show modemcap command.
• View the contents of a modem’s modemcap entry.
• Modify a modem’s modemcap entry.
• Create a modem database entry.
The show modemcap command displays the modems in the modemcap database, as follows:
Router#show modemcap
default
codex_3260
usr_courier
usr_sportster
hayes_optima
global_village
viva
telebit_t3000
microcom_hdms
microcom_server
nec_v34
nec_v11
nec_piafs
cisco_v110
mica
In addition, with the modem type specified, it shows a complete list of the specified modem’s
modemcap entry that includes the following fields:
• Command description
• Command abbreviation (with colon separator)
• Command string
The command show modemcap codex_3260 shows the AT command string attributes and their
values for the Codex 3260 modem, as shown in the following:
Router#show modemcap codex_3260
Modemcap values for codex_3260
Factory Defaults (FD): &F
Autoanswer (AA): S0=1
Carrier detect (CD): &C1
Drop with DTR (DTR): &D2
Hardware Flowcontrol (HFL): *FL3
Lock DTE speed (SPD): *SC1
Best Error Control (BER): *SM3
Best Compression (BCP): *DC1
No Error Control (NER): *SM1
No Compression (NCP): *DC0
No Echo (NEC): E0
No Result Codes (NRS): Q1
Software Flowcontrol (SFL): [not set]
Caller ID (CID): &S1
Miscellaneous (MSC): [not set]
Template entry (TPL): default
The default modem type has modemcap values for a few of the most common attributes. It does
not contain strings for attributes that vary widely by modem type, such as locking speeds,
setting hardware flow control, or dealing with compression and error correction.
You can use the modemcap entry modem_name command or the show modemcap
modem_name command to see the contents of a modem’s modemcap entry. The modemcap
entry modem_name command displays modemcap values in a truncated form.
As you will see later in this section, you can also create variant modemcap entries to add new
modems or to extend a modem’s functionality in the modemcap database.
Modem Autodiscovery
If no modem is specified for a particular line and you have provided the modem autoconfigure
discovery command, the access server attempts to autodiscover the type of modem to which it
is attached. The access server determines the type of modem by sending AT commands to the
modem and evaluating the response. The Cisco IOS software initially tries the first of the
modemcap strings to see if the modem initializes properly. If not, the Cisco IOS software cycles
to the next string and repeats the process until the appropriate string is found. Usually, if none
of the strings properly initializes the modem, you must manually configure the modem.
NOTE Sometimes, the router fails to recognize a modem, even though it might be part of the
modemcap list. Therefore, if you know that your modem can be configured by using an
initialization string from one of these scripts, you can issue the modem autoconfigure type
type command, as explained in the next section.
The following is an example of the modem autoconfigure discovery command:

Router(config)#line 1 16
Router(config-line)#modem autoconfigure discovery
This command instructs the access server to do the following on lines 1 though 16:
• Send the AT string at various baud rates until it receives an OK.
• Send a variety of AT commands that attempt to receive a complete identification of the
modem identified in the access server’s modem capabilities database.
The specific modemcap entries found on a particular system are determined by the hardware
and Cisco IOS software version that are installed.
NOTE Whenever possible, configure the modem to eliminate the overhead of modem autodiscovery.
If you list a specific modem type, initialization proceeds more quickly.
If the access server cannot determine the modem type, the default modem entry is used. Any
modems that are not currently supported in the list can be manually added to the list to be
autodiscovered in future communication, as you will see later in the section, "Fine-tuning
Modem Autoconfiguration."
Figure 4-16 Viewing a Variant Modemcap Entry
Router#show modemcap usr_new

Modemcap values for usr_new
Factory Defaults (FD) : &F
Autoanswer (AA) : S0=1
Carrier detect (CD) : &C1
Drop with DTR (DTR) : &D2
Hardware Flowcontrol (HFL) : &H1&R2
2 Lock DTE speed (SPD) : &B1
Best Error Control (BER) : &M4
Best Compression (BCP) : &K1
No Error Control (NER) : &M0
No Compression (NCP) : &K0
No Echo (NEC) : E0
No Result Codes (NRS) : Q1
Software Flowcontrol (SFL) : [not set]
1 Caller ID (CID) : *U1
Miscellaneous (MSC) : [not set]
3 Template entry (TPL) : usr_courier
The numbers in the Figure 4-16 output correspond to the numbers in Figure 4-15 that show each
modemcap edit command from the example.
Specifically, the usr_new modemcap shown in Figure 4-16 is identical to the usr_courier entry,
with the following exceptions:
• The DTE speed lock
• The caller ID field
• The template
If you use the show running-config command, the usr_new information for the configuration
on the previous page appears as follows:
usr_new SPD=&B1:CID=*U1:TPL=usr_courier
Chat-Scripts for Async Lines

Because asynchronous modems are not standard, you must write custom chat-scripts to perform
certain tasks. Chat-scripts are used for the following tasks:
• Modem configuration
• Dialing and remote login commands
• Failure detection
A chat-script is a string of text that defines the handshaking that occurs between two DTE
devices, or between a DTE and its directly attached. It consists of expect-send pairs that define
the string that the local system expects to see from the remote device and which reply the local
system should send:
(config)#chat-script script-name expect-string send-string
For example, you can configure chat-scripts for the following tasks:
• Initializing the directly attached modem
• Instructing the modem to dial out
• Logging in to a remote system
The following is a sample chat-script command and a table that describes it:
(config)#chat-script Reno ABORT ERROR ABORT BUSY "" "ATZ" OK "ATDT \T" TIMEOUT 30
➥CONNECT \c
chat-script Command Description

Reno Defines the name of this chat-script as dial.
ABORT ERROR Stops the chat-script if an error is encountered.
"ATZ" Without expecting an input string, sends the AT command to the
modem to reset it by using the stored profile.
OK "ATDT \T" When the input string OK is seen, sends the AT command to instruct
the modem to dial the telephone number in the dialer string or start-
chat command.
TIMEOUT 30 CONNECT Waits up to 30 seconds for the input string CONNECT.
\c Suppresses a new line at the end of the send string. It is an escape
sequence. Indicates the end of the chat-script.
For more information on chat-scripts, please refer to Appendix D, “AT Commands for Modems
and Chat-Scripts."
Modem-script versus System-script

Chat-scripts are used as modem-scripts or system-scripts. Modem-scripts are used between
DTE to DCE, where system-scripts are sent DTE to DTE.
In the following example, the script called Niagara is used between the router and the modem
to successfully handshake with the destination. The Gambling script is used for logging
between the router and an end-system at the destination; ! script called Niagara is used for
dialing a modem:
chat-script Niagara ABORT ERROR "" "AT Z" OK "ATDT \T" TIMEOUT 30 CONNECT \c
!
! Script for logging into a system called Gambling and starting up slip session:
chat-script Gambling ABORT invalid TIMEOUT 15 name: billw word: wewpass ">" "slip
➥default"
!
Interface async 5
dialer map ip 172.16.12.17 modem-script Niagara system-script Gambling
➥918005551212
You can manually start a chat-script on any asynchronous line that is not currently active by
using the start-chat command. Or, you can configure chat-scripts so they are executed for
specific events, such as the following:
• Line activation—Triggered by incoming traffic (Carrier Detect signal going up)
• Connection—Triggered by outgoing traffic (for example, reverse Telnet)
• Line reset—Triggered by async line reset
• Startup—Triggered by access server startup
• Dialer—Triggered by dial-on-demand routing (DDR)
Start-chat: Manual Start of Chat-script

If you wish to manually start a chat-script on a line, you can use the start-chat privileged EXEC
command.
Router#start-chat regexp [line-number [dialer-string]]
This command provides modem dialing commands for a chat-script that you want to apply
immediately to a line. If you do not specify a line, the script runs on the current line. If the
specified line is already in use, the script is not activated, and an error message appears.
The argument regexp is used to specify the name of the modem script that is to be executed. The
first script that matches the argument in this command and the dialer map command will be
used.
Verifying and Debugging Modem Autoconfiguration

The debug confmodem command displays the modem configuration process, as shown in
Example 4-1. Example 4-1 shows an access server modem configuration process on line 97
with a USR Sportster modem attached.
Example 4-1 Modem Configuration Process—debug confmodem
Router#debug confmodem
TTY97: detection speed (115200) response ---OK---
TTY97: Modem command: --AT--
TTY97: Modem configuration succeeded
TTY97: Detected modem speed 115200
Solution to Case Study 4-1—Configuring Asynchronous Connections with Modems 93
Task 2 Solution—Configuring the Serial Interface and Line

Step 1 Configure the serial interface to which the external modem is connected and
the corresponding line by using the following commands. In this case study,
assume that a four-port synchronous/asynchronous network module is
located in the fourth slot of a Cisco 3640, and that you are taking the first
interface of that card for asynchrounous communications.
NOTE The modem is connected to the first port on this card, thus configuring interface serial 3/0. In
ICRC and CRLS, you learn that Cisco starts counting at 0. Therefore the fourth slot is called
slot 3 and the first port is called port 0—thus 3/0.
Command Description
interface serial 3/0 Enters the interface configuration mode of the first interface of
the fourth slot of the Cisco 3640.
physical-layer async Configures the serial interface as an async interface (adds line
97 to the configuration).
line 97 Configures the line for the following physical layer parameters.
login Allows login and challenge for a password.
password cisco Sets the login password to cisco.
modem inout Allows incoming and outgoing modem connections.
transport input all Allows any transport protocol.
speed 115200 Sets speed between router and modem.
stopbits 1 One stop bit per byte.
flowcontrol hardware Uses CTS/RTS flow control.
Step 2 From global configuration mode, configure a hostname to allow reverse

Telnet to the attached modem:
Command Description
ip host modem 2097 10.115.0.110 Int E 0/0—IP address picked in Task 1. This command allows a
reverse Telnet connection to line 97. The name can be anything
you choose (we chose modem). As learned previously in this
chapter, a reverse Telnet connection is performed by using an
IP address of a valid interface—in this case, interface E 0/0.
104 Chapter 5: Configuring Point-to-Point Protocol and Controlling Network Access
Point-to-point links between LANs, hosts, terminals, and routers can provide sufficient physical
connectivity in many application environments. Many regional and commercial network
services provide access to the Internet, and point-to-point links provide an efficient way to
access the service provider locally.
The Internet community adopted two schemes for the transmission of IP datagrams over serial
point-to-point lines:
• Serial Line Internet Protocol (SLIP)—SLIP is a standard protocol for point-to-point serial
connections, using a variation of TCP/IP. SLIP was a predecessor of PPP.
• Point-to-Point Protocol (PPP)—PPP provides router-to-router and host-to-network
connections over synchronous and asynchronous circuits.
NOTE PPP and SLIP are data-link layer protocols (Layer 2 of the OSI model).
Although both SLIP and PPP were designed with IP in mind, SLIP is pretty much limited for
use with IP, whereas PPP can be used for other network-layer protocols.
Multilink is especially useful with ISDN when both B channels can be used to achieve 128
Kbps throughput.
NOTE ARAP and SLIP are not used very frequently in current network configurations, so they are not
covered in the course. For additional configuration information, refer to the Cisco IOS
documentation CD-ROM or Cisco Connection Online (CCO) at www.cisco.com.
PPP Architecture
PPP is a standard encapsulation protocol for the transport of different network-layer protocols
(including, but not limited to, IP) across serial, point-to-point links.
PPP Mechanisms
PPP also describes mechanisms for the following:
• Network-protocol multiplexing
• Link configuration
• Link-quality testing
PPP Architecture 105
• Authentication
• Header compression
• Error detection
• Link-option negotiation
PPP Functional Components

PPP has the following three main functional components:
• It has a method for encapsulating datagrams over serial links, based on the ISO HDLC
protocol (this is not Cisco HDLC), as shown in Figure 5-2.
• Link Control Protocol (LCP) establishes, configures, authenticates, and tests the data-link
connection.
• Network Control Protocols (NCPs) establish and configure different network-layer
protocols (such as IP, IPX, and AppleTalk). For example, Internet Protocol Control
Protocol (IPCP) is the NCP for IP.
Figure 5-2 PPP and the OSI Model
OSI layer
3 Upper-layer protocols
(such as IP, IPX, AppleTalk)
Network Control Protocol (NCP)

(specific to each network-layer protocol)
2
Link Control Protocol (LCP)
High-Level Data Link Control (HDLC)
Physical Layer
1 (such as EIA/TIA-232, V.24, V.35, ISDN)
HDLC is the basis of PPP frame format. Figure 5-3 shows the difference between the two frame
formats. RFC 1662 describes PPP in HDLC framing in detail.
Figure 5-3 PPP and HDLC Frame Format
Flag Address Control Data (Payload) FCS Flag
1 byte 1 byte 1 or 2 bytes 1500 bytes 2 (or 4) bytes 1 byte
HDLC ISO frame
Flag Address Control Protocol LCP FCS Flag
1 byte 1 byte 1 byte 1 or 2 bytes Up to1500 bytes 2 (or 4) bytes 1 byte
BC510503.eps
PPP frame
Related RFCs
The following is a partial list of RFCs of interest for access products (for a complete listing of
RFCs related to material in this book, consult Appendix E, “RFC List”):
• RFC 1055—Nonstandard for transmission of IP datagrams over serial lines: SLIP
• RFC 1144—Compressing TCP/IP headers for low-speed serial links
• RFC 1220—Point-to-Point Protocol extensions for bridging
• RFC 1334—PPP authentication protocols
• RFC 1378—PPP AppleTalk Control Protocol (ATCP)
• RFC 1492—Access control protocol, sometimes called TACACS
• RFC 1549—PPP in HDLC Framing
• RFC 1552—PPP Internetworking Packet Exchange Control Protocol (IPXCP)
• RFC 1570—PPP LCP Extensions
• RFC 1661—Point-to-Point Protocol (PPP)
• RFC 1662—PPP in HDLC-like Framing (obsoletes RFC 1549)
• RFC 1717—PPP Multilink Protocol (MP)
• RFC 1990—PPP Multilink Protocol (MP) (obsoletes RFC 1717)
Configuring Cisco Access Servers

You can configure a Cisco access server to allow a PPP, SLIP, or ARAP session to start
automatically or to provide the router’s user prompt to your callers, as shown in Figure 5-4.
Configuring Cisco Access Servers 107
Figure 5-4 The Autoselect Process on Cisco Access Servers
Yes
User Autoselect Parse start sequence for each
dials in on? enabled protocol
No
CR PPP SLIP ARAP
frame frame frame
Start EXEC
(or dedicated mode)
Start Start Start

PPP SLIP ARAP
(Start as if run from EXEC)
This autosensing feature can be accomplished by using the autoselect command issued in the
line configuration mode:
Router(config)#line line-number
Router(config-line)#autoselect {arap | ppp | slip | during-login}
The autoselect command permits the access server to allow an appropriate process to start
automatically when a starting character is received. The access server detects either a Return
character, which is the start character for an EXEC session, or the start character for one of the
three protocols specified (ARAP, PPP, or SLIP). For example, PPP frames always start with a
flag character having the value 7E in hexadecimal (or 01111110 in binary) format.
Protocol Flag Values

The following are frame flag hexidecimal values for different protocols:
carriage return 0d
SLIP c0
ARAP 10
PPP 7E
The during-login option of the autoselect command causes the username and/or password
prompt to display without the need to press the Return key. This option is configured in the
remote Windows 95 PC modem configuration by enabling a terminal window to be brought up
after dialing. Autoselect starts when the line is active, but the system provides a username and
password prompt. Example 5-1 shows a caller's session on an access server configured with the
autoselect during-login command.
Example 5-1 A Windows 95 Client Is Dialing to an ISP, which Provides PPP Autoselect Login to its Customers
Welcome to Communications
Your Access Ramp to the Internet
User Access Verification

Username: cpaquet
Password:
service>who
Line User Host(s) Idle Location
<text omitted>
8 tty 8 pieriv Async interface 00:01:03
* 9 tty 9 cpaquet idle 00:00:00
10 tty 10 h20wins Async interface 00:01:18
<omitted>
Se1:19 debris Sync PPP 00:00:10
service>
service>ppp
Entering PPP routing mode.
Async interface address is unnumbered (Ethernet0)
Your IP address is 192.1.1.145. MTU is 1500 bytes
Header compression will match your system.
~ }#À!}!Î} }4}"}&} }*} } }%}&£òP◊}'}"}(}"Uä~~ }#À!}!Ï} }4}
no exec Command
If you don’t want users to be presented with a user prompt, type no exec at the line configuration
mode. This command determines whether or not the terminal server starts an EXEC process on
the line. By default, the terminal server starts EXECs on all lines. When a user tries to Telnet to
a line with the no exec command configured, the user gets no response when pressing the
Return key at the login screen.
Enabling PPP
To enable PPP on your router, type the following interface command:
Router(config-if)#encapsulation ppp
For SLIP use:

router(config-if)#encapsulation slip
Configuring Dedicated or Interactive PPP (and SLIP) Sessions

You can configure one or more asynchronous interfaces on your access server to be in dedicated
network interface mode. In dedicated mode, an interface is automatically configured for SLIP
or PPP connections. There is no user prompt or EXEC level, and no end-user commands are
required to initiate remote-node connections.
Configuring Cisco Access Servers 109
To ensure that the dial-in user must run either SLIP or PPP on the specified line, use the async
mode dedicated command:
Router(config-if)# async mode dedicated
Dedicated Mode
When the interface is configured for dedicated mode, the end user cannot change the
encapsulation method, address, or other parameters.
In interactive mode, a line can be used to make any type of connection, depending on the EXEC
command entered by the user. For example, depending on its configuration, the line can be used
for Telnet connections, or for SLIP or PPP encapsulation. The user is prompted for an EXEC
command before a connection is initiated.
To allow the dial-in user to run SLIP, PPP, or EXEC on the specified line, configure the async
mode interactive command:
Router(config-if)# async mode interactive
By default, no async mode is configured. In this state, the line is not available for inbound
networking because the SLIP and PPP connections are disabled.
Commands Input Sequence

If you try to configure the line with autoselect ppp prior to configuring the async mode
interactive command, you see the following error message:
%Autoselect w/o the interface command 'Async mode interactive' is useless
Configuring the Interface Addressing Method for Local Devices

The local address is set by using the ip address or ip unnumbered command.
• ip address command—To assign an IP address to a network interface, configure the
following command at the interface configuration mode:
Router(config-if)#ip address address mask
• ip unnumbered command—To conserve network addresses, configure the asynchronous

interfaces as “unnumbered.” An unnumbered interface does not have an address. When the
unnumbered interface generates a packet, it uses the address of the specified interface as
the source address of the IP packet, and can be thought of as a referenced IP address. IP
unnumbered can be used only in point-to-point connections. The command is as follows:
Router(config-if)#ip unnumbered
NOTE A loopback interface is a virtual interface that never goes down; therefore, it is an ideal line to
use as the reference when using the ip unnumbered command.
Configuring the Interface-Addressing Method for Remote Devices

You can control whether addressing is dynamic (the user specifies the address at the EXEC level
when making the connection), or whether default addressing is used (the address is forced by
the system). If you specify dynamic addressing, the router must be in interactive mode and the
user enters the address at the EXEC level.
It is common to configure an asynchronous interface to have a default address and to allow
dynamic addressing. With this configuration, the choice between the default address or dynamic
addressing is made by the users when they enter the slip or ppp EXEC level command. If the
user enters an address, it is used; if the user enters the default keyword, the default address is
used.
You can therefore configure the router to do one of the following:
• Assign a default async address
or
• Allow an async address to be assigned dynamically by the caller
Assigning a Default Async Address

To assign a predefined default IP address to the remote client node that dials in to the
corresponding asynchronous line, use the peer default ip address command. Additionally, the
pool and dhcp arguments allow address allocation from a local pool of addresses or a DHCP
server. The new command, as of Cisco IOS Release 11.0 and later, is the async interface
command (for example, async default ip address address).
Router(config-if)#peer default ip address{ip-address | dhcp | pool poolname}
Additionally, the pool and dhcp options to the peer default ip address command require a
global command to create the pool of addresses. For example, the ip local pool pool-name
starting-address end-address.
DHCP Consideration
If the peer default ip dhcp option is chosen, you have to also configure ip helper address and
ip dhcp-server.
PPP Link Control Protocol Options 111
Allowing an Async Address to Be Assigned Dynamically

The async dynamic address allows the remote dial-in client to enter its own IP address, if it has
one:
Router(config-ig)#async dynamic address
NOTE When a line is configured for dynamic assignment of asynchronous addresses, the user enters
the slip or ppp EXEC command, and is prompted for an address or logical host name.
Assigning asynchronous addresses dynamically is also useful when you want to assign set
addresses to users. For example, an application on a personal computer that automatically dials
in using SLIP and polls for electronic mail messages can be set up to dial in periodically, and
then enter the required IP address and password.
Supplement 5-1 at the end of this chapter provides a summary analysis of the address
negotiation between a Windows 95 dial-up workstation and a Cisco IOS router, depending on
different configuration scenarios.
PPP Link Control Protocol Options

Earlier in the chapter, you learned about the PPP architecture and how the LCP is used for
establishing, configuring, authenticating, and testing the data-link connection. This section
presents configuration features that are negotiated through the LCP.
Authentication, using either PAP or CHAP, is used as a security measure with PPP and PPP
callback. Authentication allows the dial-up target to identify that any given dial-up client is a
valid client with a preassigned username and password.
Callback is a PPP option used to provide call and dial-up billing consolidation. PPP callback
was first supported in Cisco IOS Release 11.0(3).
Compression is used to improve throughput across existing lines. PPP compression was first
supported in Cisco IOS Release 10.3. As you will see later, Cisco routers support Stacker,
Predictor, and MPPC.
Multilink PPP takes advantage of multiple bearer channels to improve throughput. Datagrams
are split, sequenced, transmitted across multiple links, and then recombined at the destination.
The multiple links together are called a bundle. Multilink is especially useful with ISDN, in
which both B channels can be used to achieve 128 Kbps throughput. Multilink PPP was first
supported in Cisco IOS Release 11.0(3).
The following sections provide you with detailed explanations of LCP options.
PAP and CHAP Authentication

With PPP, callers can be authenticated with PAP or CHAP. You may also elect not to carry any
authentication. Figure 5-5 shows the PPP authentication process.
Figure 5-5 Incoming PPP Session—Authentication Process
Check
local Pass
database
Local
Determine Continue with the

Incoming PPP Fail Disconnect
authentication PPP negotiation
negotiation
method
Security
Query
server
security
No server Pass
authentication database
BC510506.eps
The flowchart presented in Figure 5-5 shows the following PPP authentication process steps:
1 When a user enters the ppp command, the system determines the type of authentication
configured. If no authentication is configured, the PPP process starts immediately.
Otherwise, the system goes to the next step.
2 The system determines the authentication method to be used and does one of the
following:
It checks the local database (established with the username password commands) to see
whether the given username/password pair matches the pair in the local database (CHAP
or PAP).
or
It sends an authentication request to the security server (TACACS+ or RADIUS).
3 The system checks the authentication response sent back from the security server or local
database. If it is a positive response, the access server starts the PPP process. If the result
is negative, the access server rejects the user immediately.
With either PAP or CHAP authentication, you have a two-way process, in which an
Id/Password pair is repeatedly sent by the peer to the authenticator until the authentication
is acknowledged or the connection is terminated. For PAP, this process provides an insecure
PAP and CHAP Authentication 113
authentication method. If you put a protocol analyzer on the line, you can see the password
in clear text.
With PAP, there is no protection from playback (if you have a sniffer connected to the line and
you capture the packet for later use, you can use the packet to authenticate your way directly
into the network by playing back the captured packet).
If you are interested in more secure access control, you should use CHAP rather than PAP as
the authentication method. You should use PAP only if it is the only method of authentication
that the remote station supports.
NOTE CHAP passwords are encrypted when they cross the network, whereas PAP passwords are
cleartext when they cross the network.
PAP is a one-way authentication when it is between a host and an access server, as shown in
Figure 5-6; it is a two-way authentication when it is between routers.
Figure 5-6 One-Way PAP Authentication between a Host and an Access Server
Remote user Access server

John Cisco1
Run PPP
Local user
Inputs name and Use PAP
database
password when “john, urbiz”
prompted username john
Accept or reject password urbiz
Configuring PAP Authentication

From a configuration perspective, there are two routers in Figure 5-7. Left and Right, connected
across an ISDN cloud, are configured for the PAP authentication method.
Figure 5-7 Example of Access Routers Configured for a Two-Way PAP
Left Right
PSTN/ISDN
router router
hostname left hostname right

int async 0 int async 0
encapsulation ppp encapsulation ppp
ppp authentication PAP ppp authentication PAP
ip add 10.0.0.1 255.255.255.0 ip add 10.0.0.2 255.255.255.0
dialer-map ip 10.0.0.2 dialer-map ip 10.0.0.1
name right 555-2345 name left 555-4321
ppp pap sent-username left ppp pap sent-username right
password left1 password right1
Perform the following steps to configure PAP authentication:

1 On the interface, specify encapsulation ppp.
2 Enable the use of PAP authentication with the ppp authentication PAP command. This
entry is made because router Left, during the LCP negotiation, asks router Right to use
PAP authentication during the negotiation to identify itself.
3 Configure the addresses, usernames, and passwords. Passwords must be identical at both
ends and must be entered on both systems, if PAP is used between routers (two-way
authentication). The router name and password are case-sensitive.
4 To ensure that both systems can communicate properly, configure the dialer-map
command lines for each router. By configuring each router with a dialer-map statement,
each system knows what to do with authentication issues because the systems have prior
knowledge of each other. The dialer-map command also contains the telephone number
to dial to reach the specified router.
NOTE The Authentication method specified under the interface is for INCOMING CALLS
authentication. It is not the authentication method that the router uses when asked to
authenticate. It is the “answering” router prerogative to specify what authentication it entertains
from a caller. The caller must comply with the authentication method asked by the answering
router. If not, the negotiation fails and the access server disconnects the call.
Configuring CHAP Authentication

When using CHAP authentication, the access server sends a challenge message to the remote
node after the PPP link is established, as shown in Figure 5-8. The remote node responds with
a value calculated by using a one-way hash function (typically MD5). The access server checks
the response against its own calculation of the expected hash value. If the values match, the
authentication is acknowledged. Otherwise, the connection is immediately terminated.
Figure 5-8 One-Way CHAP Authentication between a User and a Cisco Access Server
Remote user Access server

John Cisco1
Run PPP
Local user
Use CHAP database
Name: john Challenge
Password: urbiz
Response username john
Accept or reject password urbiz
CHAP provides protection against playback attack through the use of a variable challenge value
that is unique and unpredictable. The use of repeated challenges every two minutes during any
CHAP session is intended to limit the time of exposure to any single attack. The access server
(or authentication server, such as TACACS+) controls the frequency and timing of the
challenges. A major advantage of the constantly changing challenge string is that the
line cannot be sniffed and played back later to gain unauthorized access to the network.
The six following figures show the series of events that occur during a CHAP authentication
between two routers.
Placing the Call

Figure 5-9 represents the following three steps:
1 The call comes in to 3640-1. The incoming interface is configured with the ppp
authentication chap command.
2 LCP negotiates CHAP and MD5.
3 A CHAP challenge from 3640-1 to the calling router is required on this call.
Figure 5-9 User Placing a Call to a Cisco Access Server
User dials in
766-1
3640-1
Sending a Challenge
Figure 5-10 illustrates the following steps in the CHAP authentication between the two routers:
1 A CHAP challenge packet is built with the following characteristics:
01 Challenge packet type identifier
id Sequential number that identifies the challenge
random A reasonably random number
3640-1 The authentication name of the challenger
2 The id and random values are kept on the access server.
3 The challenge packet is sent to the caller.
Figure 5-10 The Challenge Is Sent to the Calling Router
User dials in
766-1
3640-1
01 id random 3640-1
The answering router maintains a list of outstanding challenges.
Processing the Challenge

Figure 5-11 illustrates the receipt and MD5 processing of the challenge packet from the server.
Figure 5-11 The Challenge Is Received and Processed by the Calling Router
User dials in
766-1
3640-1
user pass
01 id random 3640-1
3640-1 pc1
MD5
hash
The calling router processes the CHAP challenge packet in the following manner:
1 The id value is fed into the MD5 hash generator.
2 The random value is fed into the MD5 hash generator.
3 The name 3640-1 is used to look up the password.
4 The password is fed into the MD5 hash generator.
The result is the one-way MD5-hashed CHAP challenge that will be sent back in the CHAP
response.
NOTE As mentioned in RFC 1334, no matter what number you process through the MD5 algorithm,
the result is always 128 bits long!
Answering the Challenge

Figure 5-12 illustrates the building of the CHAP response packet that will be sent to the access
server:
1 The response packet is assembled from the following components:
02 CHAP response packet type identifier
id Copied from the challenge packet
hash The output from the MD5 hash generator (the hashed information from
the challenge packet)
766-1 The authentication name of this caller
2 The response packet is then sent to the challenger.
Figure 5-12 Caller Sends the Response to the Answering Cisco Access Server
User dials in
766-1
3640-1
user pass
01 id random 3640-1
3640-1 pc1
02 id hash 766-1
MD5
hash
The Verification
Figure 5-13 shows the response-packet processing that occurs on the challenger.
Figure 5-13 The Answering Access Server Verifies the Answer
User dials in
766-1
3640-1
user pass user pass

01 id random 3640-1
3640-1 pc1 766-1 pc1
02 id hash 766-1
MD5 MD5
hash hash
=?
The CHAP response packet is processed in the following manner:

1 The id is used to find the original challenge packet.
2 The id is fed into the MD5 hash generator.
3 The original challenge random value is fed into the MD5 hash generator.
4 The name 766-1 is used to look up the password from one of the following sources:
• Local database
• RADIUS server
• TACACS server
(Note that with Cisco IOS Release 11.1 and earlier, TACACS is used for the password
check only. With Cisco IOS Release 11.2 and later, TACACS is used to verify the hash
value.)
5 The password is fed into the MD5 hash generator.
6 The hash value received in the response packet is then compared to the calculated MD5-
hashed value.
CHAP authentication succeeds if the calculated and the received hash values are equal.
The Result
Figure 5-14 illustrates the success message being sent to the calling router.
Figure 5-14 The Answering Router Sends the Pass Result to the Calling Router.
User dials in
766-1
3640-1
user pass user pass

01 id random 3640-1
3640-1 pc1 766-1 pc1
02 id hash 766-1
MD5 MD5
hash hash
03 id “Welcome in”
If authentication was successful, a CHAP success packet is built from the following
components:
03 CHAP success message type
id Copied from the response packet
Welcome in is simply a text message of some kind, meant to be a user-readable
explanation.
If authentication failed, a CHAP failure packet is built from the following components:
04 CHAP failure message type
id Copied from the response packet
Authentication failure or a similar text message is meant to be a user-readable
explanation.
The success or failure packet is then sent to the caller.
Refer to the section “Verifying and Troubleshooting PPP,” later in this chapter, for a look at the
complete process with the debug ppp negotiation command.
Supplement 5-2, at the end of the chapter, provides a summary of the authentication successes
and failures between a Windows 95 workstation and a Cisco IOS router, depending on different
scenarios.
Interface Commands for CHAP Authentication

Configuring CHAP is straightforward. As with PAP, you have two routers shown in Figure
5-15: Left and Right, connected across the cloud. Use the following steps as a guide to
configuring CHAP authentication:
1 On the interface, specify encapsulation ppp.
2 Enable the use of CHAP authentication with the ppp authentication chap command.
This entry is made because router Left asks router Right to use CHAP authentication to
identify itself during the LCP negotiation.
3 Configure the usernames and passwords.
PPP Callback 121
Figure 5-15 These Routers are Configured for a Two-Way CHAP Authentication
Left Right
PSTN/ISDN
router router
hostname left hostname right

username right password username left password
sameone sameone
int async 0 int async 0
encapsulation ppp encapsulation ppp
ppp authentication CHAP ppp authentication CHAP
Passwords must be identical at both ends. The router name and password are case-sensitive.
Enabling PAP and CHAP Authentication

You can enable both PAP and CHAP authentication on an interface. The first method specified
is requested during link negotiation. If the caller refuses the first method, the second method is
tried. The commands are as follows:
Router(config-if)#ppp authentication pap chap
or
router(config-if)#ppp authentication chap pap
PPP Callback
PPP callback provides a client-server relationship between the end points of a point-to-point
connection. PPP callback allows a router to request that a dial-up peer router call back. The
callback feature can be used to control access and toll costs between the routers.
When PPP callback is configured on the participating routers, the calling router (the callback
client) passes authentication information to the remote router (the callback server), which uses
the host name and dial string authentication information to determine whether to place a return
call. If the authentication is successful, the callback server disconnects, and then places a return
call. The remote username of the return call is used to associate it with the initial call, so that
the packets can be transmitted.
Both routers on a point-to-point link must be configured for PPP callback; one must function
as a callback client, and one must be configured as a callback server. The callback client must
be configured to initiate PPP callback requests, and the callback server must be configured to
accept PPP callback requests and place return calls.
Return calls are made through the same dialer rotary group, but not necessarily the same line as
the initial call. The preceding information can be found on the Cisco Web site at
www.cisco.com.
NOTE If the return call fails (because the line is not answered or the line is busy), no retry occurs. If
the callback server has no interface available when attempting the return call, it does not retry.
When the client router dials the initial call, the router’s hold-queue timer is started if the
command dialer hold-queue is configured on the dialing out interface. No calls to the same
destination will be made again until the hold-queue timer expires. The timer is stopped if PPP
NCP negotiation is successful or if the call fails. The complete command syntax is as follows:
dialer hold-queue number of packets timeout seconds
NOTE For rotary groups that include ISDN, the return call never occurs if the enable time is long and
another user dials into the last interface before the enable timer expires. For rotary groups that
include ISDN, if an interesting packet arrives at the server during the enable time, the dialer
may use the last interface for the interesting packet, and the return call is never made.
When planning to implement PPP callback, consider the following:

• Authentication is required for callback to be successful.
• The time between the disconnect of the initial call and dialing the return call is determined
by the dialer enable timeout. This interval must be long enough to guarantee that the initial
call is completely disconnected.
• The dialer hold-queue timeout determines how long to wait before the client can make
another call to the same destination. The server must make the return call before the client
hold-queue timer expires, to prevent the client from trying again and possibly preventing
the return call from being connected.
• The hold timer on the callback client should be approximately four times larger than the
server’s hold-queue timer.
Callback: How Does it work?

The asynchronous callback feature supports EXEC, PPP, and ARAP sessions. The main
motivation for callback is for telephone bill consolidation and dial-up cost savings. It is
not positioned as a security feature; however, if the callback number is assigned in the
PPP Callback 123
authentication database, security is enforced because callbacks are made only to assigned
telephone numbers. The incoming calls go through the normal login process and must
pass authentication before callback can occur, as shown in Figure 5-16.
Figure 5-16 Flowchart of Callback Operations

Call
Autoselect No
CHAP Authentication Disconnect
protocol
OK
Yes
Hangup Callback
Callback
Requested
The callback feature employs a two-pass process:

1 On the first pass, the callback engine determines which target line to use for callback to
the remote user and hangs up on the incoming line. Then, the callback engine dials back
to the remote user through the target line by using the dial string provided.
2 On the second pass, the callback engine proceeds normally, as if there were no callback.
To make callback work properly, you must make sure that callback is configured for each
autoselect protocol that is defined for any given remote user. Otherwise, the remote dial-in
autoselect process may work, but no callback occurs.
The PPP callback operation consists of the following events:
1 The callback client initiates the call. The client requests callback by using the callback
option during the PPP LCP negotiation phase.
2 The callback server acknowledges the callback request and checks its configuration to
verify that callback is enabled.
3 The callback client and server authenticate by using either CHAP or PAP authentication.
The username is used to identify the dial string for the return call.
4 After successful initial authentication, the callback server router identifies the callback
dial string. The callback server compares the username of the authentication to the host
name in a dialer map table. The dial string can be identified by a mapping table or by the
Callback Option Message field during PPP’s LCP negotiations. The Callback Option
Message field is defined in RFC 1570.
PPP Callback 125
Router(config-if)#ppp callback accept

Router(config-if)#ppp callback initiate
Router(config)#line line-number
Router(config-line)#callback forced-wait seconds
Router(config-line)#script callback script-name
Command Description
ppp callback accept This interface command allows the specified interface to
accept a callback request initiated from a remote node (per
RFC 1570).
ppp callback initiate This interface command allows the router to initiate a
callback to a remote node when the remote node is capable
of putting itself in an “answer mode” for callback.
callback forced-wait seconds This line option allows an additional wait (in seconds) before
the callback chat script is applied to the outgoing target line.
This option accommodates modems that require a longer
resting period before any input to it can be accepted again.
script callback script-name This line command specifies a chat script to issue AT
commands to the modem during a callback attempt made to
the target async line. This command is used for EXEC and
PPP callbacks.
Configuring the Callback Server

A router can call back PPP clients that dial in. As shown in Figure 5-17, configure PPP callback
for a server, perform the following steps (the following step numbers correspond to the numbers
in Figure 5-17):
1 Configure IP on the dial-in line.
2 Use the dialer callback-secure command to disconnect calls that are not properly
configured for callback. A callback server with dialer callback-secure configured
disconnects any unconfigured dial-in users.
3 Set up dialer map with the dialer map and dialer-group commands.
4 Use the ppp callback accept command to enable callback.

5 Define the ppp authentication method with the ppp authentication chap command.
6 Configure dialer callback-server username in a dialer map-class to identify the name in

the dialer map as a valid callback client. When callback client router dials in and is
authenticated, the call is disconnected. For example, in Figure 5-17, a return call is made
to 555-5678, as configured by the dialer map command. The dialer map command
identifies the map-class to be used for this connection.
PPP Compression 127
Configuring the Callback Client

You can set up a Cisco router to initiate a PPP callback request. As shown in Figure 5-18,
configure client PPP callback so that all calls over this interface request callback (the following
step numbers correspond to the numbers in Figure 5-18):
1 Configure PPP on the serial or ISDN interface.
2 Set up a dialer map with the dialer map and dialer-group commands. Be sure that the
dialer map command has a name field with the correct name of the server; in Figure 5-
17, the name is Plano.
3 Configure the router interface as the callback client with the ppp callback initiate
command.
4 Set the authentication to CHAP with the ppp authentication command.
Figure 5-18 Example of a PPP Callback Client

Callback server
Callback client
Dallas 10.1.1.8 5555678 Plano 10.1.1.7 5551234
Dallas(config)#interface s0
Dallas(config-if)#ip address 10.1.1.8 255.255.255.0
1 Dallas(config-if)#encapsulation ppp
2 Dallas(config-if)#dialer map ip 10.1.1.7 name Plano 5551234
Dallas(config-if)#dialer-group1
3 Dallas(config-if)#ppp callback request
4 Dallas(config-if)#ppp authentication chap
Note that you can use the optional dialer hold-queue timeout command to specify the number
of seconds that the callback client waits for a return call from the callback server.
PPP Compression
Cisco routers can also maximize performance by using data compression, which enables higher
data throughput across the link.
Compression is a negotiated option. So, if you want to use compression but the party you are
calling is not configured for compression, no compression will take place.
The Cisco compression schemes are as follows:

• Predictor—Determines whether the data is already compressed. If so, the data is just
sent—no time is wasted trying to compress already compressed data.
• Stacker—A Lempel-Ziv (LZ)-based compression algorithm looks at the data, and only
sends each data type once with information about where the type occurs within the data
stream. The receiving side uses this information to reassemble the data stream. (Stacker is
the only supported algorithm in the Cisco 700 series.)
• MPPC—Microsoft Point-to-Point Compression (MPPC) Protocol (RFC 2118) allows
Cisco routers to exchange compressed data with Microsoft clients. MPPC uses an LZ-
based compression algorithm.
• TCP header compression—Used to compress the TCP headers.
The highest compression ratio is usually reached with highly compressible text files. Already
compressed files such as JPEG graphics or MPEG files, or files that were compressed with
software such as PKZIP or StuffIt, are only compressed 1:1 or even less.
If you frequently transfer already compressed data, such as graphics and video, you need to
consider whether you want to globally set up compression. Trying to compress already
compressed data can take longer than transferring the data without any compression at all.
Ideally, you can attain 2:1 or 3:1 compression for information that was not previously
compressed. Expect an average of 1.6:1 compression for mixed compressed and uncompressed
source data.
Compressing data can cause performance degradation because it is software, not hardware
compression. Compression can be CPU- or memory-intensive.
Configuring Compression
Configuring for compression is simple: from the interface, issue the compress predictor,
compress stac, compress mppc, or ip tcp header-compression command on both sides
of the link.
Compression Algorithm
Predictor is more memory-intensive and less CPU-intensive. Stacker and MPPC are more CPU-
intensive and less memory-intensive. Memory-intensive means that an extra memory
allowance is required.
You need to consider this memory usage when implementing compression on any specific
router. If you use a Cisco 2500 series or better, it should be acceptable to use either of these
methods if you have sufficient memory in the router. Use caution with smaller systems that have
less memory and slower CPUs, and ensure that you are not overloading the router. The interface
command to enable compression is:
Router(config-if)#compress [predictor|stac|mppc]
PPP Multilink 129
TCP Header Compression

The TCP header compression technique is fully described in RFC 1144. It is supported on serial
lines by using HDLC, PPP, and SLIP encapsulation. You must enable the compression on
both ends of the connections for TCP header-compression to work. Only TCP headers are
compressed—UDP headers are not affected. The following is the interface command used to
activate TCP header compression:
Router(config-int)#ip tcp header-compression
The ip tcp header-compression passive command specifies that TCP header compression is
not required, but if the router receives compressed headers from a destination, then use header
compression for that destination.
PPP Multilink
Multilink over PPP provides load balancing over dialer interfaces—including ISDN,
synchronous, and asynchronous interfaces. Multilink PPP (MP) can improve throughput and
reduce latency between systems by splitting packets and sending the fragments over parallel
circuits, as shown in Figure 5-19. Prior to MP, two or more ISDN B channels could not be used
in a standardized way while ensuring sequencing. MP is most effective when used with ISDN.
Figure 5-19 Multilink PPP Logically Bundles Together Links to Provide a Larger Bandwidth to a Destination
Bundle Brand
Cisco
access X
server Not Cisco
Bundle Cisco
access
server
MP solves several problems related to load balancing across multiple WAN links, including the
following:
• Multivendor interoperability, as specified by RFC 1990, which replaces RFC 1717

• Packet fragmentation, improving latency of each packet (supports RFC 1990
fragmentation and packet-sequencing specifications)
• Packet sequence and load calculation
Multilink PPP Fragments

Multilink fragments are called packets (per RFC 1990, section 3, page 7, which states
“individual fragments, which are the 'packets' in the Multilink Protocol.”).
This feature negotiates the Maximum Received Reconstructed Unit (MRRU) option during the
PPP LCP negotiation to indicate to its peer that it can combine multiple physical links into a
bundle.
Prior to the adoption of RFC 1990, there was no standardized way to use both of the B channels
and ensure proper sequencing.
MP is interoperable between Cisco routers running Cisco IOS software and Cisco 700 series
routers, and with most routers that conform to RFC 1990.
Use Multilink PPP with applications in which bandwidth requirements are dynamic, such as
remote LAN access applications for telecommuters or small office, home office (SOHO)
environments.
Multilink Operation and Configuration

Multilink PPP is controlled by the addition of a two-, four-, or eight-byte sequencing header in
the PPP frame that indicates sequencing for the fragments.
MP Packet Header
RFC 1990 provides for only four-byte headers. The first fragment of a multilink packet in PPP
has two headers, one for the fragment and followed by the header for the packet itself.
During PPP negotiation, some hardware platforms could use different header lengths for PPP
Multilink, causing potential problems. Please check with the specific platform documentation
if you have problems with Multilink PPP.
Transmission channels in the bundle need not be the same types. Asynchronous and
synchronous links, for example, can be used to simultaneously transmit fragments of one
datagram.
Verifying and Troubleshooting PPP 131
During PPP’s LCP option negotiation, a system indicates to its peer that it is willing to multilink
by sending the MRRU option as part of the initial LCP option negotiation. Multilink systems
must be able to do the following:
• Combine multiple physical links into one logical link (bundle)
• Receive and reassemble upper-layer protocol data units (PDUs)
• Receive PDUs of a negotiated size
After the LCP negotiation is complete, the remote destination must be authenticated and a
dialer map with the remote system name must be configured.
The authenticated username, or caller ID, is used to determine to which bundle the link is added.
The ppp multilink command activates multilink on an interface. This command and related
commands will be explored in greater detail in Chapter 7, “Using ISDN and DDR to Enhance
Remote Connectivity.”
Router(config-if)#ppp multilink
The following shows an example of the show ppp multilink command. At the bottom of the
output, you can see the exact number of channels participating in the bundle:
Router#show ppp multilink
Bundle rudder, 3 members, first link is BRI0: B-channel 1
0 lost fragments, 8 reordered, 0 unassigned, sequence 0x1E/0x1E rcvd/sent
Verifying and Troubleshooting PPP

This section introduces tools for verifying and troubleshooting a PPP session.
One way to determine whether PAP or CHAP authentication was passed is to use the show
dialer command. This command must be used to view the progress of asynchronous dial-up
connections.
If show dialer displays the name of the remote router, it means that you passed PAP or CHAP
authentication, as shown in Example 5-2.
Example 5-2 show dialer Command Example
LA#show dialer int bri0
BRI0 - dialer type = ISDN
Dial String Successes Failures Last called Last status

2002 7 0 00:00:05 successful
0 incoming call(s) have been screened.
BRI0:1 - dialer type = ISDN

Idle timer (121 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
continues
Example 5-2 show dialer Command Example (Continued)

Dial reason: ip (s=10.130.0.1, d=192.168.2.1)
Time until disconnect 117 secs
Connected to 2002 (Boise)
BRI0:2 - dialer type = ISDN

Dialer state is idle
You can check the show dialer command on both routers to verify that the name of the other
router is displayed. If it is, then you know that PAP or CHAP authentication is working.
If you do not see the name of the other host, you know that something was misconfigured
because the authentication failed in at least one direction.
The debug ppp negotiation command is a great tool for troubleshooting the PPP Link Control
protocol activities such as authentication, compression, and multilink. Once the LCP is in
OPEN state, the NCP negotiation takes place. In the following output, you can observe that for
PPP to work, LCP options must be negotiated before any NCP activities take place. You
therefore see the following negotiations: CHAP Authentication; CCP (Compression Control
Protocol); and finally the NCP protocols IP, IPX, and CDP:
Router#debug ppp negotiation
BR0:1 PPP: Treating connection as a callin
BR0:1 PPP: Phase is ESTABLISHING, Passive Open
BR0:1 LCP: State is Listen
BR0:1 LCP: I CONFREQ [Listen] id 116 len 30
BR0:1 LCP: AuthProto CHAP (0x0305C22305)
BR0:1 LCP: MagicNumber 0x1109DB3A (0x05061109DB3A)
BR0:1 LCP: MRRU 1524 (0x110405F4)
BR0:1 LCP: EndpointDisc 1 Local (0x130B0143656E7472616C42)
BR0:1 LCP: O CONFREQ [Listen] id 68 len 15
BR0:1 LCP: MagicNumber 0x156A31E0 (0x0506156A31E0)
BR0:1 LCP: O CONFREJ [Listen] id 116 len 19
BR0:1 LCP: MRRU 1524 (0x110405F4)
BR0:1 LCP: EndpointDisc 1 Local (0x130B0143656E7472616C42)
BR0:1 LCP: I CONFACK [REQsent] id 68 len 15
BR0:1 LCP: MagicNumber 0x156A31E0 (0x0506156A31E0)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 117 len 15
BR0:1 LCP: O CONFACK [ACKrcvd] id 117 len 15
BR0:1 LCP: State is Open
BR0:1 PPP: Phase is AUTHENTICATING, by both
BR0:1 CHAP: O CHALLENGE id 61 len 28 from "BranchB"
BR0:1 CHAP: I CHALLENGE id 56 len 29 from "CentralB"
BR0:1 CHAP: Waiting for peer to authenticate first
CHAPTER
7
Using ISDN and DDR
Technologies to Enhance Remote
Connectivity
ISDN Overview
Prior to the 1960s, the world’s communication network was relying mainly on analog
facilities. Communication networks have been evolving for the past 40 years toward digital
transmission. In 1968, ITU-T convened a meeting to discuss the integration of transmission
and switching. Part of the discussions revolved around Integrated Services Digital Network
(ISDN).
ISDN developers envisioned that this new technology would provide a digital pipeline,
offering integrated access to the broadest range of services. These services were to include
voice, networking, packet switching, telemetry, and cable television.
ISDN versus Asynchronous

As its name implies, ISDN uses digital technology. As shown in Figure 7-1, ISDN replaces
the traditional analog basic telephone service equipment and wiring scheme with a new
higher-speed digital equipment that provides a host of new services.
ISDN Overview 167
The primary difference between the basic or analog telephone call process and the ISDN call
process is the use of digital signaling and data transmission from end-to-end.
NOTE ISDN is an access technology that provides a digital local loop. Therefore, ISDN transmissions
are digital from end-to-end. With asynchronous connections, the local loop is analog and
requires PCM, thus introducing delay in the transmission.
SDN Services and Channelized E1 and T1

The access interface is the physical connection between the user and the provider. Two different
access interfaces are currently defined by the ISDN recommendations from the ITU-T. They are
called Basic Rate Interface (BRI ) and Primary Rate Interface (PRI ), as shown in Figure 7-2.
Figure 7-2 Differences between BRI and PRI for Channelized E1 and T1
56/64 Kbps
2B 56/64 Kbps
BRI 144 Kbps
D 16 Kbps
23B (T1) or 64 Kbps T1 1.544 Mbps

30B (E1) each or
PRI
E1 2.048 Mbps
D 64 Kbps
(includes sync)
31 64 Kbps 2.048 Mbps

channels EI (includes sync)
24 1.544 Mbps
DSOs TI (includes sync)
The ISDN bearer service channel—B channel—carries voice or data, usually in frame format.
The D channel is the ISDN out-of-band signaling channel, which carries the user-network
messages, such as call setup and teardown.
ISDN-BRI specifies the following:
• Two 64 Kbps bearer channels and one 16 Kbps data channel service. BRI connects to an
NT1 for four-wire connection.
• Framing and synchronization at 48 Kbps.
168 Chapter 7: Using ISDN and DDR Technologies to Enhance Remote Connectivity
• Total speed is two B channels at 64 Kbps each (128), one D channel at 16 Kbps, plus
framing and synchronization at 48 Kbps. The total comes to (128+16+48=192)—192
Kbps.
• It is intended to be used at small concentration points.
• It is referred to as a digital signal level zero (DS0) interface.
ISDN-PRI specifies the following:
• 23 or 30 B channels, at 64 Kbps each
• One D channel, at 64 Kbps
• Framing and synchronization use 8 Kbps (North America T1) or 64 Kbps (European E1)
• Total speed 1.544 Mbps (T1) or 2.048 Mbps (E1)
NOTE In an E1 PRI, there are actually 32 channels: 30 B channels, one D channel, and one
synchronization channel. Also, in Europe, the D channel is carried in timeslot 16; in the United
States, it is in timeslot 24.
Table 7-1 displays the relationship between the digital signal level, speed, T designation, and
number of channels.
Table 7-1 Digital Signal Levels—Characteristics
Digital Signal Level Speed T Designation Channels or DS0s
DS0 64 Kbps 1
DS1 1.544 Mbps T1 24
DS2 6.312 Mbps T2 96
DS3 44.736 Mbps T3 672
DS4 274.176 Mbps T4 4032
NOTE In some cases, a DS0 can carry only 56 Kbps, usually due to legacy telco equipment or a
signaling method called robbed-bit signaling (RBS). RBS and other signaling methods will be
discussed later in this chapter in the “ISDN Primary Rate Interface” section.
In Europe, the equivalent of a T1 facility is an E1. E1 has 32 64-Kbps channels for a total of
2.048 Mbps.
ISDN Overview 169
Other hierarchies of voice and data channels are the Synchronous Optical Network (SONET)
and Synchronous Digital Hierarchy (SDH). SONET is a North American telco standard; SDH
is used elsewhere. These standards were developed to provide standards for Fiber Optics
Transmission Systems (FOTS). Table 7-2 compares SONET and SDH channels.
Table 7-2 A Comparison between SONET and SDH Levels
SONET Signal Level Speed SDH Equivalent
STS-1/OC-1 51.84 Mbps STM-0
STS-1/OC-48 2488.32 Mbps STM-16
STS-1/OC-192 9953.28 Mbps STM-64
NOTE Channelized T1 has 24 B channels at 64 Kbps each and one D channel at 64 Kbps.
Channelized E1 has 30 B channels at 64 Kbps each and one D channel at 64 Kbps.
BRI Call Processing

Figure 7-3 shows the sequence of events that occur during the establishment of a BRI call.
Figure 7-3 BRI D Channel Performing Call Process
1 4 3
2
SS7
B Channel
D Channel/SS7
1 When the call is initiated, the D channel comes up. The called number is sent to the local
ISDN switch.
2 The local switch uses the SS7 signaling protocols to set up a path and pass the called
number to the terminating ISDN switch.
3 The far end switch brings up the D channel to the destination. The D channel is used for
call setup, signaling, and call termination, which are the call control functions.
4 When the terminating end answers, the B channel is connected end-to-end. A B channel
carries the conversation or data. Both B channels can be used simultaneously to the same
or different destinations.
The maximum length of most ISDN local loops in North America is about 18,000 feet (5.5 km),
using standard POTS wiring.
NOTE ISDN is a local-loop technology. Once the ISDN switch processes the call, the communication
uses the SS7 infrastructure to reach its destination.
BRI Functional Groups and Reference Points

ISDN technology involves many functional devices, also known as functional groups. The
ISDN reference points define the communication protocols of these devices.
Each functional group has identical elements, but one group includes the NT2 CPE; the other
does not. The following functional groups are illustrated in Figure 7-4:
ISDN Overview 171
Figure 7-4 ISDN Functions and Reference Points
V
LT ET
S T U
TE1 NT2 NT1 LE
Customer Network ISDN local

premises termination exchange
switching
R equipment
U.S. demarcation
TE2 TA
Non-ISDN Terminal Non-U.S. demarcations

terminal adapter
equipment
• Terminal equipment 1 (TE1) designates a device that is compatible with the ISDN
network. A TE1 connects to a Network Termination of either Type 1 or Type 2, such as a
digital telephone, a router with ISDN interface, or digital facsimile equipment.
• Terminal equipment 2 (TE2) designates a device that is not compatible with ISDN and
requires a terminal adapter, such as terminals with X.21, EIA/TIA-232, or X.25 interfaces
or a router without ISDN interface (AGS+ and so on).
• Terminal adapter (TA) converts standard electrical signals into the form used by ISDN,
so that non-ISDN devices can connect to the ISDN network. For example, converting V.35
or EIA/TIA-232 to ISDN or a router without ISDN interface (AGS+ and so on).
• Network termination type 1 (NT1) connects four-wire ISDN subscriber wiring to the
conventional two-wire local loop facility. The NT1 is part of the CPE in the United States
and it is part of the local exchange in Europe.
• Network termination type 2 (NT2) directs traffic to and from different subscriber
devices and the NT1. The NT2 is an intelligent device that performs switching and
concentrating. Often, a PBX is the NT2 device.
• Line termination (LT) (located at the exchange side) functions are identical to those of
an NT1.
• Exchange termination (ET). Subscriber line cards in the ISDN exchange LT and ET are
sometimes referred to as the LE (local exchange), which is the ISDN switch for which we
must configure.
Reference points are architectural definitions that may or may not have a physical realization
as an interface. ISDN reference points are as follows:
• U reference point (User reference point)—This reference point is located between
NT1 and LT (it corresponds with a subscriber line). There are no ITU-T standards for
the U interface. This is the American National Standards Institute (ANSI) standard for the
United States.
• T reference point (Terminal reference point)—This reference point is located between
NT1 and NT2 (or between the NT1 and TE1 or TA, if there is no NT2 device). The T
interface uses the same characteristics as the S interface.
• S reference point (System reference point)—This reference point is located between NT2
and TE1 or TA. It connects the terminals to the ISDN network. This is the most important
interface for the users. The S interface uses the same characteristics as the T interface.
• R reference point (Rate reference point)—This reference point is located between TA
and TE2 (non-ISDN interface). The TE2 connects to the TA via a standard physical-layer
interface. These standards include EIA/TIA-232-C (formerly RS-232-C), V.24, X.21, and
V.35.
NOTE The S/T interface is governed by the ITU I.430 standard. The ANSI T1.601 or ITU I.431
standards govern the U interface, depending on the country.
Some manufacturers define a V reference point in Local Exchanges (LE) between Local
Termination (LT) and Exchange Termination (ET). This reference point identifies the network
node interface and is transparent to users.
Given all the ISDN abbreviations such as T, S, U, S/T, and so on, what do all of these
components and reference points look like in the real world?
As shown in Figure 7-5, a connection is made from the wall jack with a standard two-wire cable
to the NT1, and then out of the NT1 with a four-wire connection to your ISDN phone, terminal
adapter, Cisco ISDN router, or maybe to an ISDN fax. The S/T interface is implemented using
an eight-wire connector to allow for powering the NT and TE capabilities.
ISDN Overview 173
Figure 7-5 Physical Layout of an ISDN Installation

ISDN phone
(TE1)
To ISDN
service
S/T U
NT1
4-wire 2-wire
ISDN router
(TE1) Wall jack
R
TA
Non-ISDN
fax (TE2)
Because all of these connectors look fairly similar (such as RJ-11, RJ-45s and so on), you must
be careful about what you plug in and where.
The S/T reference point is a four-wire interface (TX and RX). It is point-to-point and multipoint
(passive bus), as shown in Figure 7-5. It uses the ITU I.430 specification. The S/T interface
defines the interface between a TE1 or TA, and an NT.
The U interface defines the two-wire interface between the NT and the ISDN cloud.
The R interface defines the interface between the TA and an attached non-ISDN device (TE2).
An NT1 and NT2 combination device is sometimes referred to as an NTU.
ISDN Protocols
The ITU-T groups and organizes the ISDN protocols according to general topics:
E-series—Telephone Network, for example E.164—International ISDN addressing
I-series—Concepts and interfaces, for example I.430—BRI interface
Q-series—Switching and signaling, for example q.921—LAPD (Link Access Procedures for
D channel)
PRI—Reference Points
PRI technology is a bit simpler than BRI. The wiring is not multipoint, and there is only the
straight connection between the CSU/DSU and the PRI interface (see Figure 7-6).
ISDN Protocol Layers 175
Figure 7-7 ISDN Protocols and the OSI Reference Model

D Channel B Channel
Layer 3 DSS1 (Q.931) IP/IPX
HDLC/PPP/FR/
Layer 2 LAPD (Q.921)
LAPB
Layer 1 I.430/I.431/ANSI T1.601
LAPD is the framing protocol used for D channel data. The Digital Subscriber Signaling
System No. 1 (DSS1) is the Layer 3 protocol for the D channel. Specifically, only Q.931 is
used here, not the entire DSS1 protocol suite.
The D channel is governed by DDR, which is the mechanism for building connections over
either an analog or ISDN connection. The B channel is governed by IP or IPX protocols for data
transmission.
Figure 7-8 shows what the I.430 BRI frames between the TE and the NT look like.
Figure 7-8 I.430 Framing (BRI Layer 1)

NT TE Frame
1 1 8 1 1 1 1 1 8 1 1 1 8 1 1 1 8 1 1 1
F L B1 L D L F L B2 L D L B1 L D L B2 L D L
TE NT Frame
1 1 8 1 1 1 1 1 8 1 1 1 8 1 1 1 8 1 1 1
F L B1 E D A F F B2 E D S B1 E D S B2 E D S
An interesting note is that the format of the frames is different, depending on which direction
they are going. Also note that time-division multiplexing is occurring between the D channel
and the two B channels. The frame can have 16 bits from each of the B channels and four bits
from the D channel. The framing always occurs, even if no data is being transmitted across the
B channels. The NT1 constantly provides clocking and framing out to the local exchange.
B channels have the following characteristics:
• ISDN BRI bit rate is 192 Kbps.
• ISDN user bandwidth is 144 Kbps, 2×B channels plus 1 D channel ((2×64) + 16).
• ISDN signaling requirement is 48 Kbps.
The TE and ISDN switch are constantly communicating. That is, there is a constant stream of
ones and zeros exchanged between the router and the ISDN switch located at the central office.
The stream of data exchanged must follow a specific sequence, such as the one shown in Figure
7-8. Such a sequence, in which each bit has a specific function, is referred to as framing. The
I.430 standard defines the BRI framing bit field key as follows:
• B1 bit—Bit within the B channel 1
• B2 bit—Bit within the B channel 2
• D bit—D channel bit
• F bit—Framing bit used for synchronization
• L bit—DC balancing bit adjust average bit value
• E bit—Echo of previous D bit
• A bit—Activation bit
• S bit—Spare bit
ISDN Layer 2
With ISDN, all of the hardware addressing occurs in Layer 2, just like a traditional LAN
environment. As shown in Figure 7-9, it is possible to have up to eight ISDN terminals on an
S/T bus. TEs are therefore differentiated from each through terminal endpoint identifiers (TEIs)
and service access point identifiers (SAPIs).
Figure 7-9 ISDN Can Accommodate Multiple Devices on the S/T Bus
TEI/SAPI Daisy chain

S/T
bus
ISDN
LE
NT1
TEI/SAPI
The TEI is a dynamic assignment to that device. In the United States, when you boot up a router,
you make some type of request to the switch for a TEI. The switch assigns you a TEI, and you
ISDN Protocol Layers 177
will communicate over the switch using the signaling that uses a SAPI. This is the same concept
as is used in the 802.2 frames, in which you need to differentiate between the different processes
that are running. You need some special identifiers to provide this discrimination between
frames. Some of the messages sent over the ISDN network are for call setup or call teardown,
and others are data. The SAPI is a way of prioritizing the calls or giving access to the network
first.
Q.920 is the functional specification for ISDN. The actual communication takes place over the
network and is specified in Q.921.
WARNING Cisco 4000 can’t share the S-bus.
NOTE Examples of SAPI values are 0 for Call control procedure and 63 for Layer 2 management
function.
TEI groups assignments are 0–63 for non-automatic TEI assignment; 64–126 for automatic TEI
assignment; and 127 for group assignment, or broadcast.
ISDN Layer 3—Channel Q.931

ITU Q.931 is specified as the protocol for Layer 3 of the D channel. The protocol messages and
its rules for exchange are derived from the DSS1 protocol suite.
The I series specifications define support of the end terminal (end equipment) protocol as it is
applied to the Cisco routers. The Q series specifications define the equipment from the network
point of view, as supported by the central switch.
These data link layer protocols are not implemented in the NT equipment. They are only
implemented in the end equipment, and are used to communicate with the local switch. They
are not supported in the NT1 equipment.
ISDN Call Setup

There are a number of ways to place an ISDN call. In an ISDN call, the called party requests a
call setup, as shown in Figure 7-10. Before the actual connect and call proceeding, you might
see several different messages, such as progress, which indicate how your call is proceeding.
This progress message is optional.
The same is true for the alerting message, which is typical of telephone messages, but is not
required. Alerting messages are not typical with data transmissions. Most of the time, you see
connection messages with data calls. You may not see the Connect acknowledge, but it is valid.
The messages depend on how successful the call and completion acknowledgments are
implemented.
Figure 7-10 Call Setup—Q.931 Activities
Calling party
Called party
Time
Setup
Setup Setup
acknowledge Call proceeding
Call ISDN
service Alerting
proceeding
provider Connect
Alerting
Connect ISDN ISDN
Connect switch switch
acknowledge Connect
acknowledge
NOTE Different ISDN switches use different call setup and teardown procedures. Depending on the
switch type, you may or may not get all the steps shown in Figure 7-10. At a minimum, Call
proceeding, Alerting, and Connect should be exchanged.
ISDN Call Teardown

Similar to call setup, the call teardown request is not an end-to-end function, but instead is
processed by the switch. The release procedures are based on a three-message approach:
• Release
• Released
• Release complete
The Release message is transmitted through the network as quickly as possible. Figure 7-11
assumes that the called party is generating the release. The process is triggered by a Disconnect
message on the D channel, between the calling and called parties. After receipt of this message,
the exchange immediately starts the release of the switch path that supports the B channel
circuit, and sends a Release message to the succeeding exchange at the same time. The message
is passed through the network from all intermediate exchanges to the terminating exchange.
ISDN BRI and DDR Overview 179
Figure 7-11 Q.931 Steps During a Call Teardown
Calling party Called party

Time Disconnect
Disconnect
ISDN Release
Released service Released
provider
Release complete
ISDN ISDN
Release complete
switch switch
In Figure 7-11, all of the exchanges are characterized as the telco network box. The Release
message is intended to inform the exchanges involved in the call as quickly as possible that the
call-related circuit connections are to be released. As the involved exchanges release the call, a
Released message is eventually transmitted to the terminating exchange, and this transmission
causes the following actions:
• It issues a Disconnect message to the calling party.
• It starts a timer T12 to ensure receipt of a Released message.
• It connects the switched path.
• When a Released message is received from the preceding exchange, it returns a Release
complete message to the preceding exchange.
The T timers are used through the exchanges to ensure that the exchange will repeat the Release
message if a Release complete message is not received within the timer period. If not
acknowledged, a Reset circuit occurs.
ISDN BRI and DDR Overview

Cisco implements Dial on Demand Routing (DDR) from the perspective of the incoming data
to the router.
With DDR, all incoming traffic is classified as either interesting or uninteresting. As shown
in Figure 7-12, if the traffic is interesting, the packet is passed to the router. The router connects
to the remote router if it is not currently connected using access-lists and dialer-lists. If the
traffic is uninteresting and there is no connection, it does not dial the remote router, thus saving
costs.
Figure 7-12 Dial-On Demand Routing Uses Conditions to Classify the Packets as Either Interesting or Uninteresting
No
Incoming packet Interesting
?
Yes No
Connected
?
Yes No
Connected Yes
?
Interface No
Available?
Reset
Idle Yes
Timer
No
Phone #
?
Yes
Dial
Send
The idle timer is used to reset the connection if no traffic for the destination arrives within the
configured timer interval.
WARNING Once a connection is made, all traffic goes through, unless an access-list is applied to the
interface. For example, if you configured your DDR link to deny Telnet traffic but allow ping
traffic, a user can send a ping to bring up the connection, and then start a Telnet session on the
open DDR interface.
Access routers use DDR to connect to remote routers. The access router calls the remote router
only when interesting traffic arrives. Dialer-lists specify interesting traffic. The BRI interface is
placed in a dial group that is linked to a dialer-list that specifies interesting traffic. You can use
multiple dialer-list settings to designate interesting traffic that is mapped for other DDR
destination routers.
Access-lists can also be used to produce more granularity in defining interesting packets that
initiate DDR calls. For this periodic-use environment, specify static routes so that routing
updates will not initiate ISDN calls to remote routers that run up service charges from the ISDN
service provider.
7000 family routers and AS5200 series access servers with T1/E1 controllers are covered at the
end of this chapter, in the “ISDN Primary Rate Interface” section.
The interface ISDN addressing tasks include assigning the IP address, dialer group, and ISDN
service profile statements. The task also includes adding the dialer map command that
associates a statically mapped destination to a destination IP address, hostname, and ISDN dial
number.
Optional features to set for ISDN are covered in more detail in the “Optional Configuration”
section at the end of the chapter (these include isdn caller number, isdn rate adaptation, and
dialer map speed). Other options are described in the Cisco Documentation CD-ROM.
Step 1—Selecting the ISDN Switch Type

You must specify the type of ISDN switch used by the service providers at the CO.
Selecting the ISDN Switch Type

Some ISDN service providers use one switch, but emulate the software of another switch.
Therefore, the switch type that needs to be configured is the one that has been emulated by the
switch, and not the actual brand name of the switch installed at the CO.
When you use the isdn switch-type command in global mode, all ISDN interfaces on the router
are configured for the same switch type. If you use the command in the interface configuration
mode, only the interface for which you are configuring assumes that switch type.
Following are the global or interface commands that let you specify the ISDN switch located at
the CO to which your router will connect:
Router(config)#isdn switch-type switch type
Router(config-if)#isdn switch-type switch type
For BRI ISDN service, the switch type can be one of those listed in Table 7-3.
Table 7-3 ISDN BRI Switch Types
Switch Type Description
basic-5ess AT&T basic rate switches (United States)
basic-dms100 NT DMS-100 (North America)
basic-ni1 National ISDN-1 (North America)
basic-ni2 National ISDN-2 (North America)
basic-1tr6 German 1TR6 ISDN switches
basic-nwnet3 Norwegian Net3 switches
Configuring an ISDN BRI 183
Table 7-3 ISDN BRI Switch Types (Continued)

Switch Type Description
basic-nznet3 New Zealand Net3 switches
basic-ts013 Australian TS013 and TS014 switches
basic-net3 Switch type for NET3 in United Kingdom and Europe
ntt NTT ISDN switch (Japan)
Depending on the version of Cisco IOS software that you use, you might see different switch
types available.
WARNING If you need to change the specified switch type, you must reboot the router before the different
switch-type setting takes effect on the router. To disable the switch on the ISDN interface,
specify isdn switch-type.
You can apply an ISDN switch type on a per-interface basis, thus extending the existing global
isdn switch-type command to the interface level. This allows Basic Rate Interfaces (BRIs) and
Primary Rate Interfaces (PRIs) to run simultaneously on platforms that support both interface
types.
Sequence of Commands for Specifying the ISDN Switch Type

To specify a switch type under your serial interface, you must have configured the E1/T1
controller. But in order to configure the E1/T1 controller, you must have configured the global
isdn switch-type! Once the E1/T1 controller is configured—following the configuration of the
isdn switch-type—you can introduce the switch command at the interface level. If you wish
to, you can also remove it from the global level. The interface isdn switch-type command, if
specified, overwrites the isdn switch-type specified at the global level.
Step 2—Configuring the Interface

The interface bri interface-number command designates the interface used for ISDN on a
router acting as a TE1.
If the router does not have a native BRI (it is a TE2 device), it must use an external ISDN
terminal adapter. On a TE2 router, use the interface serial interface-number command.
Step 3—Setting the Service Profile Identifiers (SPID), If Necessary

Some service providers use service profile identifiers (SPIDs) to define the services subscribed
to by the ISDN device that is accessing the ISDN service provider. The service provider assigns
one or more SPIDs to the ISDN device when you first subscribe to the service. If you use a
service provider that requires SPIDs, your ISDN device cannot place or receive calls until it
sends a valid assigned SPID to the service provider when accessing the switch to initialize the
connection.
Purpose of SPIDs
Service providers use SPIDs to define the services you are paying for. Common extra features
include call waiting, call holding, multiple subscriber number, caller ID, call transfer, call
forwarding, call deflection, and so on.
Currently, only the DMS-100 and NI1 switch types require SPIDs. The AT&T 5ESS-switch
type may support a SPID, but it is recommended that you set up that ISDN service without
SPIDs. SPIDs have significance at the local access ISDN interface only. Remote routers are
never sent SPIDs.
How Are SPID Numbers Chosen?

To keep SPID numbers simple (an oxymoron, it seems), most telcos use part of the ISDN phone
number in the SPID nomenclature. Therefore, SPIDs are often the ISDN phone number with
some optional numbers. For example, the SPID for the phone number (888)555-1212 could be
888555121200.
A local directory number (LDN) might also be necessary if the router is to answer calls made
to the second directory number.
The commands to set SPIDs and LDN on both B channels are as follows:
Router(config-if)#isdn spid1 spid-number [ldn]
Router(config-if)#isdn spid2 spid-number [ldn]
Commands Description
isdn spid1 and isdn spid2 These commands are used to define, at the router, the
SPID number that has been assigned by the ISDN service
provider for the respective B channel.
Configuring Dial-on-Demand Routing (DDR) 185
Commands Description
spid-number This is the number that identifies the service to which you
have subscribed. The ISDN service provider assigns this
value.
ldn This local dial number (optional) must match the called-
party information coming in from the ISDN switch in
order to use both B channels on most switches. It may be
required by the ISDN service provider.
SPIDs Can “Byte”

Using ISDN, I recently configured two Cisco 2520s for DDR for a client wishing to set up a
MAN. During the week of the installation, the metropolitan region was split into two different
area codes. For the purpose of this story, suppose that the area code 111 was split between
111 and 999. Anything on the central metropolitan area remained 111, and the peripheral area
became 999. The telco provided me with the suburban router’s ISDN phone numbers—
9995551212 and 9995551213—but no SPID numbers. Knowing the telco modus operandi for
SPID creation and the switch type, I figured the SPID numbers for the router located in the new
area code region to be 999555121200 and 999555121300. Once the router was configured, it
indicated, via the show isdn status, that the SPIDs were invalid. By contacting the telco, I
found out that, although the phone numbers were using the new area code of 999, the SPIDs
configured on the switch were not updated to reflect the area code change. So, the phone
numbers were 9995551212 and 9995551213, but the SPIDs were 111555121200 and
111555121300—still using the old area code.
Step 4—Setting the Encapsulation Protocol

The following encapsulation ppp command can be used if you want PPP encapsulation for
your ISDN interface. This is the case if you want any of the LCP options that PPP offers (for
example, CHAP authentication). You must use PPP, PAP, or CHAP if you receive calls from
more than one dial-up source. To revert from PPP encapsulation to the default, use the
encapsulation hdlc command.
Router(config-if)#encapsulation [ppp | hdlc]
Router(config-if)#ppp authentication [chap | pap]
Configuring Dial-on-Demand Routing (DDR)

Connections initiated by remote offices or telecommuters are brought up on an as-needed basis,
which results in substantial cost savings for the company. In dial-on-demand routing scenarios,
users are not connected for long periods of time. The number of remote nodes requiring access
is relatively low, and the completion time for the dial-in task is short.
Following are the steps involved in configuring a spoke router for DDR. A spoke router is the
link between a stub network and the WAN. A stub network has only a single connection to a
router.
1 Define what constitutes interesting traffic by using the dialer-list command.
2 Assign this traffic definition to an interface by using the dialer-group command.
3 Define the destination address, hostname, telephone number to dial, and optional call
parameters by using the dialer map command.
4 Define call parameters by using commands such as dialer idle-timeout, dialer fast-idle,
and dialer load-threshold.
Step 1—Defining what Constitutes Interesting Traffic

The dialer-list command is used to configure dial-on-demand calls that will initiate a
connection. The simpler form of the command specifies whether a whole protocol suite, such
as IP or IPX, will be permitted or denied to trigger a call. The more complex form references
an access-list, which allows finer control of the definition of interesting traffic.
The command syntax to define a DDR dialer-list to control dialing by protocol is as follows:
Router(config)#dialer-list dialer-group-number
protocol protocol-name {permit | deny}
Command Description
dialer-list dialer-group-number protocol protocol- This command defines a DDR dialer-list to
name {permit | deny | list access-list-number | control dialing by protocol, or by a
access-group} combination of protocol and access-list.
dialer-group-number This is the number of a dialer access group
identified in any dialer-group interface
configuration command.
protocol-name This is one of the following protocol
keywords: appletalk, bridge, clns, clns_es,
clns_is, decnet, decnet_router-L1,
decnet_router-L2, decnet_node, ip, ipx,
vines, or xns.
You can also specify an access-list for more refined control over the DDR process. Standard or
extended access-lists can be used for DDR, and then applied to dialer groups and interfaces. An
extended access-list gives you control over the protocol, source address, and destination address
in determining interesting packets.
Configuring Dial-on-Demand Routing (DDR) 187
The access-list command specifies interesting traffic that initiates a DDR call. The dialer-list
command is used in conjunction with the access-list. This command associates the access-list
with the dialer access group:
Router(config)#access-list access-list-number [permit | deny]
{protocol | protocol-keyword}{source source-wildcard | any}
{destination destination-wildcard | any}
[protocol-specific-options] [log]
Router(config)#dialer-list dialer-group list access-list-number
Step 2—Assigning the Dialer-List to an Interface

Once the dialer-list is created, it needs to be assigned to the interface responsible for initiating
the call. This associating command is as follows:
Router(config-if)#dialer-group group-number
Command Description
dialer-group This command configures an interface to belong to a specific dialing
group. The dialer group points to a dialer-list.
group-number This is the number of the dialer access group to which the specific
interface belongs. This access group is defined with the dialer-list
command, which specifies interesting traffic that initiates a DDR call.
Acceptable values are nonzero, positive integers from 1 to 10.
NOTE For a given protocol and a given dialer group, only one access-list can be specified in the
dialer-list command.
Step 3—Defining Destination Parameters

Once you define what constitutes interesting traffic, you must provide the interface responsible
for initiating the call with all the parameters necessary to reach the destination. The dialer map
command identifies destination router information, such as the phone number to dial:
Router(config-if)#dialer map protocol next-hop-address
[name hostname] [broadcast] dial-string
Command Description
dialer map protocol next-hop- This command configures a serial interface or ISDN
address [name hostname] interface to call one or multiple sites. The name refers to the
broadcast] dial-string name of the remote system, and broadcast indicates that
broadcasts should be forwarded to this address. The dial-
string is the number to dial to reach the destination.
The dialer map command has many other optional parameters available to it. For a complete
description of the command and its parameters, refer to the documentation CD-ROM or CCO.
Mapping What?
Cisco commands often contain the word “map,” which is used to map statically Layer 2
addresses to Layer 3 addresses. For example, the command frame-relay map is used to define
a Layer 3 next-hop-address to its Layer 2 address—in this case, a DLCI number. With a
dialer-map statement, you bundle a Layer 3 address (IP in this chapter) to a dial-up Layer 2
address (which, in this case, is a phone number).
Step 4—Defining Optional Call Parameters

The following additional call parameters can be added to the interface:
Router(config-if)#dialer idle-timeout seconds
Router(config-if)#dialer fast-idle seconds
Router(config-if)#dialer load-threshold load [outbound | inbound | either]
Command Description
dialer idle-timeout seconds This command specifies the time that the line can remain idle
before it is disconnected. The default time is 120 seconds.
dialer fast-idle seconds This command specifies the time that a line can remain idle before
the current call is disconnected to allow another call that is waiting
to use the line. The default time is 20 seconds.
dialer load-threshold load This command specifies the interface load at which the dialer
[outbound | inbound | either] initiates another call to the destination.
Load This is a number from 1 to 255 (255 is equal to 100% load and 128
is equal to 50% load).
Outbound This command calculates the load on outbound data only (the
default).
Inbound This command calculates the load on inbound data only.
Either This command calculates the load on the maximum of the
outbound or inbound data.
Idle-Timeout versus Fast-Idle

Combining the dialer idle-timeout and dialer fast-idle commands allows you to configure
lines to stay up for a longer period of time when there is no contention, but they can also be
reused more quickly when there are not enough lines for the current demand.
Static and Default Routing 189
Also, if you intend to nail the line, set a high timeout value on the receiving router because these
commands apply to inbound and outbound calls.
Static and Default Routing

The use of static and default routes eliminates the need to send routing updates over expensive
leased lines or to trigger a DDR call.
If you configure as a leaf node, sometimes also called a stub network (a remote site with no
routes behind it), you probably will configure a default or static route for the leaf node to go to
just one location, as shown in Figure 7-13. By default, it sends all of its traffic to the cloud or
the Central site location.
Figure 7-13 Static and Default Routes Usage
TCP/IP
Static route is toward

the remote site
Default route is
toward cloud
Static Route
At the Central site, you can enter the static route and point it at a specific address, as follows:
Router(config)#ip route 172.108.0.0 255.255.0.0 192.254.35.2
In order to point to your interface instead of the next hop address, you can also use the
following:
ip route 172.108.0.0 255.255.0.0 BRI 0
Provided that you are using a dialer-string command, if you use a dialer-map command, DDR
does not kick in if the static route is pointing at your interface.
Setting Route Redistribution 191
Figure 7-14 This Router Advertises Static Routes to Other Routers
172.108.00
10.0.0.1
Router (config) #router igrp 109
Router (config-router) #network 172.108.0.0
Router (config-router) #redistribute static
Router (config) #ip route 192.150.42.0
255.255.255.0 10.0.0.2
10.0.0.2
192.150.42.0
Deactivating Routing Updates

Because we use static routes or default routing on our remote networks, we need not pass IGRP
routing updates to the rest of the network from the remote sites. As shown in Figure 7-15, to
block this traffic, we declare the BRI interface on the corporate side to be passive, which
prevents any routing updates from being passed to the remote node.
Figure 7-15 Blocking Routing Updates by Using the passive-interface Command
Router (config) #router igrp 100

Router (config-router) #passive-interface bri0
BRI 0
Configuring a Router for Initiating an ISDN Call

Some basic configuration is necessary on a router to provide for dial-on-demand routing. In the
following section, you will read about the necessary commands for successful DDR
connectivity.
Figure 7-16 shows the topology of router-to-router DDR. Example 7-1 shows how you can
combine commands to set up ISDN and DDR. DDR is configured to connect Cisco-a to
Cisco-b by using legacy DDR, which uses dialer map statements. Cisco-b configuration is
shown in Example 7-2.
Figure 7-16 Topology of a Simple Network Using DDR

10.170.0.1
Cisco-a 10.170.0.2
NT1
Cisco-b
NT1
ISDN
E0 BRI 0
5105551234
4085554000 BRI 0 E0
192.168.2.1
192.168.1.1
Example 7-1 Router-A Configuration, Using a Simple dialer-list Statement

hostname Cisco-a
isdn switch-type basic-5ess
username Cisco-b password samepass
interface bri 0
ip address 10.170.0.1 255.255.0.0
encapsulation ppp
dialer idle-timeout 300
dialer map ip 10.170.0.2 name Cisco-b 4085554000
dialer-group 1
ppp authentication chap
!
ip route 192.168.1.0 255.255.255.0 10.170.0.2
dialer-list 1 protocol ip permit
Table 7-4 describes the commands used in the configuration in Example 7-1.
Table 7-4 ISDN Basic Configuration
Command Description
isdn switch-type This command selects the AT&T 5ESS switch as the CO
ISDN switch type for this interface.
username Cisco-b password This command sets up a CHAP username and password
samepass for the remote router.
interface bri 0 This command enters BRI 0 configuration mode.
ip address 10.170.0.1 255.255.0.0 This command specifies the BRI 0 IP address and net
mask.
encapsulation ppp This command sets up PPP encapsulation for BRI 0.
Configuring a Router for Initiating an ISDN Call 193
Table 7-4 ISDN Basic Configuration (Continued)

Command Description
dialer idle-timeout 300 This is the number of seconds of idle time before the
router drops the ISDN call.
dialer map This command establishes how to call the next hop router.
ip This is the name of the protocol used by this map.
10.170.0.2 This is the IP address for the next-hop router’s BRI
interface.
Cisco-b This is the CHAP identification name for the remote
router.
4085554000 This is the telephone number used to reach the BRI
interface on the remote router for this DDR destination.
dialer-group 1 This command associates the BRI 0 interface with dialer-
list 1.
ppp authentication chap This command sets up CHAP PPP authentication for BRI
0.
ip route This command configures a static route to the subnet on
the remote router.
dialer-list 1 protocol ip permit This command associates permitted IP traffic with dialer-
group 1. The router only starts an ISDN call for IP traffic.
In Example 7-1 and Figure 7-16, the network between the serial interfaces of the two routers
uses eight bits of subnetting. Static route statements define the IP route to the Cisco-b LAN
interfaces over 192.168.1.0. Interesting traffic is defined as any IP traffic that initiates a DDR
call to Cisco-b.
The number dialed is for the remote ISDN device. The service provider offering the ISDN
service provides this number. Traffic is routed to the LAN shown on the right of Figure 7-16.
Before a connection can be made, static routes of how to reach those networks must be in place.
NOTE When Cisco documentation mentions legacy DDR, it refers to configurations that use dialer-
map statements.
Example 7-2 displays the configuration for Cisco-b from Figure 7-16.
Example 7-2 Cisco-b Configuration, Using a Simple dialer-list Statement
hostname Cisco-b
isdn switch-type basic-5ess
username Cisco-a password samepass
interface bri 0
continues
Optional Configurations 197
Cisco Proprietary BOD

The Cisco proprietary BOD is triggered by outgoing traffic levels only. When the traffic level
reaches a configured level, the access router assigns the other B channel to share the traffic.
If you have an access server that is connected to an ISDN BRI (2B+D) with BOD configured,
only one B channel is usually used for communications. If you transfer a large file, the BOD
feature senses the additional traffic and allocates a second B channel. The router load balances
the traffic between the two B channels. When you finish transferring the file, the second B
channel goes idle, which saves you connect time.
The dialer initiates another call to the destination if a packet is transmitted on a dialer interface
and the transmission load on the interface exceeds the specified load threshold. The dialer then
makes additional calls, as needed, to expand the bandwidth.
The dialer load-threshold command is used to configure (Cisco proprietary) bandwidth-on-
demand by setting the maximum load before the dialer places another call to a destination. The
following is an example of BOD configuration:
Router(config)#int bri 0
Router(config-if)#dialer load-threshold load
The load value is a number from 1 to 255 that is directly related to the bandwidth of the link,
which can be specified by the bandwidth command. The lowest value, 1, brings up the second
link instantaneously. Any value greater than 1 specifies how much bandwidth on the first B
channel must be used before the second B channel is used for BOD. The bandwidth is defined
as a ratio of 255, where 128 is 50 percent and 255 is 100 percent of the available bandwidth.
Load Average Calculation

Although the load-interval interface configuration command is often used for dial backup
purposes to increase or decrease the likelihood of a backup interface being implemented, it can
be used on any interface. The load-interval command allows you to change the default interval
of five minutes to a shorter or longer period of time. If you change it to a shorter period of time,
the input and output statistics that display when you use the show interface command will be
more current and based on more instantaneous data, instead of reflecting a more average load
over a longer period of time. The default is 300 seconds (five minutes). The new value has to be
a multiple of 30, between 30 and 600 seconds.
Using BOD, the load calculation takes into consideration the outbound traffic exclusively. If
you wish both inbound and outbound traffic to be used in the load calculation, use MP.
Multilink PPP
Cisco further enhanced bandwidth-on-demand by basing its implementation on industry-
standard Multilink PPP (MP).
NOTE Some Cisco documentations abbreviate Multilink PPP as MLP. Per RFC 1717 and 1990, the
official abbreviation for Multilink PPP is MP.
The MP feature provides load balancing over multiple WAN links, while providing multivendor
interoperability, packet fragmentation, proper sequencing, and load calculation on both
inbound and outbound traffic. As shown in Figure 7-19, Cisco’s implementation of MP supports
the fragmentation and packet sequencing specified in RFC 1990, which replaces RFC 1717.
Figure 7-19 Multilink PPP Fragmenting and Sequencing
Data In Data Out

B1 A1 ISDN
B A B1 A1
service provider B A
B2 A2
B2 A2
Sequencing and Sequencing and

fragmentation reassembly
PPP Multilink Terminology

Even though PPP is a Layer 2 protocol and therefore should use the term frame, RFC 1990
defines individual fragments as packets for a multilink protocol.
MP-based bandwidth-on-demand is available in Cisco IOS Release 11.0 and later, and it is
available in Cisco 700 series routers with Release 3.2 and later.
Multilink PPP allows packets to be fragmented and the fragments to be sent at the same time
over multiple point-to-point links to the same remote address. The multiple links come up in
response to a dialer load threshold that you define. The load can be calculated on inbound
traffic, outbound traffic, or either, as needed for the traffic between the specific sites. MP
provides bandwidth-on-demand and reduces transmission latency across WAN links.
Use the dialer load-threshold load command, which has the keywords inbound, outbound,
or either for MP-based bandwidth-on-demand. For remote users, configure the load threshold
outbound. Then, configure ppp multilink, which allows you to turn MP on or off. This
command is placed either on the physical interface or in a dialer interface, depending on the
bring up the second link simultaneously. They thus get a busy signal from the other end. This
is improbable with ISDN because the call setup is very low. It can, though, be a problem with
slower call setup technologies, such as asynchronous links.
In small offices, use the either option for load threshold to ensure that the maximum of the
inbound and outbound traffic is calculated as the load threshold. As shown in Example 7-5, if
multiple rotary groups on a router are configured for multilink, one large bundle is created
between the two routers, based on the authentication name (provided that the rotary group dials
the same destination).
Example 7-5 Rotary Group Interface Configured for Multilink PPP
Router(config)#interface dialer1
Router(config-if)#ip address 10.10.10.7 255.255.255.0
Router(config-if)#encapsulation ppp
Router(config-if)#dialer idle-timeout 30
Router(config-if)#dialer map ip 10.10.10.8 name Router 81012345678901
Router(config-if)#dialer load-threshold 128 either
Router(config-if)#dialer-group 1
Router(config-if)#ppp authentication chap
Router(config-if)#ppp multilink
PPP authentication plays a part in Multilink PPP. The bundle decision is based on the
authentication name of the remote router independently on each side of the link. Each router
should use a unique hostname for authentication, with a shared password. If authentication is
not configured correctly, Multilink PPP will not work correctly.
When single Multilink BRIs or a rotary group with multiple BRIs are calling a PRI, do not
put a dialer load-threshold on the PRI or multiple BRI rotary group. Use the dialer load-
threshold command on the single BRI interface to prevent attempts to bring up a third B
channel to a single BRI destination.
ISDN Caller Identification

Calling-line identification screens incoming ISDN calls. The called number supplied in the call
message setup request is verified against a table of allowed numbers. This feature prevents
charges for calls from unauthorized numbers. In some situations, there are charges for call setup
attempts. So, even if the call does not pass caller ID screening, there is a charge for the attempt.
NOTE Caller ID is available only from providers and switches that supply called number values during
the call setup phase.
Optional Configurations 201
As shown in Figure 7-20, call acceptance does not occur until the router verifies the calling
number.
Figure 7-20 Caller Identification Process

Compare with
Call setup message allowed numbers
with local ISDN ISDN
numbers Router
number
5551234 A 551234
ISDN
Router A Router B
Accept call
NOTE Caller ID screening requires a local switch that is capable of delivering the caller ID to the
router or access server. If you enable caller ID screening, but do not have such a switch, no calls
are allowed in. In addition, caller ID screening records the number exactly as it was sent, with
or without an area code prefix.
The isdn caller command can be used to configure ISDN caller ID screening. The number is a
telephone number, up to 25 characters in length. As part of this number, enter an x or X in any
position in the number where you can accept any number as a match (a so-called wildcard or
don’t-care digit). You can specify up to 64 numbers per interface.
Called-Party Number Answering

Multiple devices can be physically connected at your site, as previously seen in Figure 7-9. You
can ensure that only a single device answers an incoming call by verifying the number or
subaddress in the incoming call against the device's configured number, subaddress, or both.
ISDN: SAPI and TEI

The SAPI and the TEI taken together create a unique identifier for a specific logical link, which,
in turn, represents a specific TE. The TEI is a seven-bit number carried in the address field of
the LAPD frame. Although the TEI seven-bit code allows up to 127 devices on an S-bus, there
are limits to the number that you can attach: up to eight devices with the 5ess and NI-1 switches,
and up to two devices for the DMS-100. Configuring multiple devices on an ISDN line is
referred to as ISDN Multipoint.
Monitoring the ISDN Interface 205
Example 7-7 The show interface bri 0 1 2 Command Displays Information On Both B Channels (Continued)
Last input 00:20:07, output 00:19:19, output hang never
Last clearing of “show interface” counters never
Queueing strategy: fifo
Output queue 40/40, 51 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
1113092 packets input, 55047875 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
61 input errors, 4 CRC, 0 frame, 0 overrun, 0 ignored, 57 abort
1093367 packets output, 37971979 bytes, 0 underruns
0 output errors, 0 collisions, 7 interface resets
0 output buffer failures, 0 output buffers swapped out
19 carrier transitions
The show isdn status Command

The show isdn status command displays information about memory, Layer 2 and Layer 3
timers, and the status of PRI channels, as shown in Example 7-8.
Author’s Note
Example 7-8 is the actual screen output of a MAN router connected to a basic-NI1 switch. The
ISDN switch, located at the CO, has allocated an individual TEI number for each B channel.
Example 7-8 This example Shows the B1 Channel as Established and the B2 Channel in an Initiating Mode
Router#show isdn status
The current ISDN Switchtype = basic-ni1
ISDN BRI0 interface
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 109, State = MULTIPLE_FRAME_ESTABLISHED
TEI = 111, State = MULTIPLE_FRAME_ESTABLISHED
Spid Status:
TEI 109, ces = 1, state = 8(established)
spid1 configured, no LDN, spid1 sent, spid1 valid
Endpoint ID Info: epsf = 0, usid = 70, tid = 0
TEI 111, ces = 2, state = 5(init)
spid2 configured, no LDN, spid2 sent, spid2 valid
Endpoint ID Info: epsf = 0, usid = 71, tid = 0
Layer 3 Status:
1 Active Layer 3 Call(s)
Activated dsl 0 CCBs = 1
CCB:callid=9800, sapi=0, ces=1, B-chan=1
Total Allocated ISDN CCBs = 1
Monitoring the ISDN Interface 209
• The debug isdn events command also displays information that is useful for monitoring
and troubleshooting Multilink PPP.
ISDN debug Commands

The following are debug commands that are helpful when troubleshooting ISDN. Two other
ISDN debug commands are debug isdn q921 and debug isdn q931.
ISDN Q921
As shown in Example 7-12, you may use the debug isdn q921 EXEC command to display data
link layer (Layer 2) access procedures that are taking place at the access router on the D channel
(LAPD) of its ISDN interface. This command is useful when you want to observe signaling
events between the access router and the ISDN switch. The ISDN data link layer interface,
provided by the access router, conforms to the user interface specification defined by ITU-T
recommendation Q.921.
Example 7-12 Debugging the ISDN Q921 Message On a Calling Router
SouthShore#debug isdn q921
ISDN BR0: RX <- SETUP pd = 8 callref = 0x41
Bearer Capability i = 0x8890
Channel ID i = 0x8A
Signal i = 0x40 - Alerting on - pattern 0
Calling Party Number i = 0x0083, '8885551212'
Called Party Number i = 0xC1, '5551213'
Locking Shift to Codeset 5
Codeset 5 IE 0x2A i = 0x808D0E, 0x8001068B0A, '8885551212’
➥0x80010A800114800114
ISDN BR0: TX -> RELEASE_COMP pd = 8 callref = 0xC1
Cause i = 0x80A2 - No channel available
ISDN BR0: RX <- SETUP pd = 8 callref = 0x41
Bearer Capability i = 0x8890
Channel ID i = 0x8A
Signal i = 0x40 - Alerting on - pattern 0
Calling Party Number i = 0x0083, '8885551212'
Called Party Number i = 0xC1, '5551213'
Locking Shift to Codeset 5
Codeset 5 IE 0x2A i = 0x808D0E, 0x8001068B0A, '8885551212'
0x80010A800114800114
ISDN BR0: TX -> RELEASE_COMP pd = 8 callref = 0xC1
Cause i = 0x80A2 - No channel available
SouthShore#
The debug isdn q921 command output is limited to the commands and responses exchanged
during peer-to-peer communication carried over the D channel. This debug information does
not include data transmitted over the B channels that are also part of the router’s ISDN interface.
The peers (data link layer entities and layer management entities on the routers) communicate
with each other via an ISDN switch over the D channel.
This command can be used with the debug isdn event and the debug isdn q931 commands at
the same time. The displays will be intermingled.
ISDN Q931
You may use the debug isdn q931 EXEC command to display information about call setup and
teardown of ISDN network connections (Layer 3) between the local router (user side) and the
network. The ISDN network layer interface provided by the access router conforms to the user
interface specification defined by ITU-T recommendation Q.931, which is supplemented by
other specifications, such as those for switch types VN2 and VN3. The router tracks only
activities that occur on the user side (not the network side) of the network connection.
The display information of the debug isdn q931 command output is limited to the commands
and responses exchanged during peer-to-peer communication carried over the D channel. This
debug information does not include data transmitted over the B channels. The peers (network
layers) communicate with each other via an ISDN switch over the D channel.
You may also use this command with the debug isdn event and the debug isdn q921
commands at the same time, but the display will be intermingled.
Other ISDN debugging commands available are debug isdn active (to show active calls) and
debug isdn history (to see previous activities).
Table 7-7 presents a graphical representation of the different debug commands and their
relation to the OSI model.
Table 7-7 ISDN and DDR Debugging
OSI Layer ISDN Dialer
3 debug isdn q931 debug dialer
debug ip packet
2 debug isdn events debug ppp negotiation
debug isdn active debug ppp authentication
debug isdn history
debug isdn q921
ISDN Primary Rate Interface

As mentioned at the beginning of this chapter, T1 and E1 provide two-way service over
telephone-switching networks. This section describes the tasks that are required to get ISDN
PRI up and running.
controller Command Description

t1 The controller interface for North American and
Japanese facility interfaces.
e1 The controller interface for European facilities
and facilities that are used in much of the rest of
the world.
slot/port or unit number Specifies the physical slot/port location or unit
number of the controller.
Configuring the Framing, Linecoding, and Clocking of the Controller

The framing controller configuration command is used to select the frame type used by the PRI
service provider:
Router(config-controller)#framing {sf | esf | crc4 | no-crc4}
framing Command Description

sf This is the super frame that is used for some
older T1 configurations.
esf This is the extended super frame that is used for
T1 PRI configurations.
crc4 or no-crc4 This is the cyclic redundancy check 4 that is
used for E1 PRI configurations.
Use the linecode command to identify the physical-layer signaling method to satisfy the ones
density requirement on the provider’s digital facility. Without a sufficient number of ones in the
digital bitstream, the switches and multiplexers in a WAN can lose their synchronization for
transmitting signals.
Router(config-controller)#linecode {ami | b8zs| hdb3}
linecode Command Description

ami This is the alternate mark inversion that is used
for T1 configurations.
b8zs This is the binary 8-zero substitution that is used
for T1 PRI configurations.
hdb3 This is the High-Density Bipolar 3 that is used
for E1 PRI configurations.
Binary 8-zero substitution (b8zs) accommodates the ones density requirements for T1 carrier
facilities, using special bipolar signals encoded over the digital transmission link. It allows 64
Kbps (clear channel) for ISDN channels.
ISDN Primary Rate Interface 213
Settings for these two Cisco IOS software controller commands on the router must match the
framing and linecode types used at the T1/E1 WAN provider’s CO switch.
Use the clock source command line and internal options to configure the T1 clock source for
the Cisco 7000 family, and the Cisco 3600 and Cisco 4000 series modules. The AS5000 series
uses the line primary and secondary version of the command to select either the primary or
secondary TDM as the clock source. With two controllers in an AS5000 series access server,
one will be primary and one will be secondary. With four controllers, one will still be primary
with multiple secondaries.
Router(config-controller)#clock source {line [primary | secondary] | internal}
The following are the usual configurations:

For T1 framing esf and linecode b8zs
For E1 framing crc4 and linecode hdb3
NOTE One instance in which you would use clock source internal is when two routers are connected
back-to-back in a test environment.
Additional ISDN PRI Configuration Parameters

Additional ISDN PRI configuration parameters include the following:
• pri-group command
• D channel selection
• Accepting analog calls
The pri-group Command

The pri-group command configures the specified interface for PRI operation and how many
fixed timeslots are allocated on the provider’s digital facility.
Router(config-controller)#pri-group [timeslots range]
Command Description
pri-group [timeslots range] This is the number of timeslots allocated to this PRI. For T1, use
values in the range of 1 to 24; for E1, use values from 1 to 31.
The speed of the PRI is the aggregate of the channels assigned
D Channel Selection
The interface serial command specifies an interface for PRI D channel operation. The interface
is a serial interface to a T1/E1 on the router or access server:
Router(config)#interface serial { slot/port: | unit:}{23 | 15}
interface serial
Command Description
slot/port This is the slot/port on the Cisco 7000 family or 3600 series router of the
channelized controller, for which this interface represents the D channel.
unit This is the unit number on the Cisco 4000 or AS5000 series of the
channelized controller, for which this interface represents the D channel.
23 This is a T1 interface that designates channelized DS0s 0 to 22 as the B
channels and DS0 23 as the D channel.
15 This is an E1 interface that designates 30 B channels and timeslot 16 as
the D channel.
WARNING Within an E1 or T1 facility, the channels start numbering at 1 (1 to 31 for E1 and 1 to 24 for
T1). Serial interfaces in the Cisco router start numbering at 0. Therefore, channel 16, the E1
signaling channel, is serial port subinterface 15. Channel 24, the T1 signaling channel, becomes
serial subinterface 23.
Accepting Analog Calls

The isdn incoming-voice modem command allows incoming analog calls to be switched to
internal modems that are installed on a digital network module. Software examines the bearer
capability fields of the D channel data, and determines whether a call is a normal ISDN call or
an analog call being carried on an ISDN B channel. If it is an analog call, it is switched to
internal modems. This command is available only for those access servers with the capability
for internal modems:
Router(config-if)#isdn incoming-voice modem
Digital Modems for Analog Calls

Digital modem network modules do not provide network interfaces of their own; they handle
analog calls passing through other router interfaces instead. In addition to the digital modem
module, the router must contain a PRI network module to connect to the ISDN channel; and
must contain another module, such as Ethernet, to provide connectivity to the LAN. The PRI
module concurrently handles digital ISDN data connections and remote voice-channel (analog)
modem connections, allowing a dynamic mix of digital and modem connections. The digital
CHAPTER
8
Optimizing the Use of DDR
Interface—Dialer Profiles and
Rotary Groups
In the previous chapter, you learned how to configure dial-on-demand routing on an access
server. In this chapter, you are introduced to the configuration of dialer profiles and rotary
groups, which helps you build more flexibility in your network design by introducing a
modular approach.
As seen in Chapter 7, “Using ISDN and DDR to Enhance Remote Connectivity,” dialer-
map statements are convenient when one physical interface is responsible for calling one
destination.
The dialer-map command can also be used if your router calls multiple destinations that
all use the same communication parameters. As an example, if your router performs DDR
to three different destinations; and for every call the encapsulation is PPP, the authentication
method is CHAP, and the idle-timeout is 300 seconds; you can configure one physical
interface with all the parameters and provide it with three separate dialer-map statements.
On the other hand, what if your router is responsible for reaching three separate locations
that use different communication parameters? Suppose that one location requires PAP
authentication when another is doing CHAP authentication. One location might require an
ISDN speed of 56 Kbps, whereas the other destinations communicate at 64 Kbps. If this is
the case, specific call parameters are defined under three separate physical interfaces, each
of them connected to a separate line.
The previous scenario might result in a waste of resources and money. You would have to
procure a router with three WAN interfaces, and you would have to pay for three lines that
might be used for only a few minutes daily.
You need a mechanism in which physical interfaces are not locked with permanent
configurations, but assumes call parameters on an as-needed basis. Once the call is finished,
the same interface is freed of the previous configuration and is ready to service another
calling destination.
This mechanism is called dialer interface. The dialer interface is not a physical interface;
it is an entity that allows you to propagate an interface configuration to multiple interfaces.
When a physical interface is being used for dialing, it inherits the parameters configured for
the dialer interface.
234 Chapter 8: Optimizing the Use of DDR Interface—Dialer Profiles and Rotary Groups
After an interface configuration is propagated to a set of physical interfaces, those interfaces

can be used to place calls by using standard DDR criteria. Using the dialer interface allows you
to specify one set of dialer maps that can apply to multiple physical lines.
Dialer interfaces provide flexibility through rotary groups and dialer profiles. The following
sections explain the differences between these two configurations.
Dialer Rotary Overview

Dialer rotary groups simplify the configuration of physical interfaces by allowing you to
apply a single logical interface configuration to a set of physical interfaces. The single logical
interface is a dialer rotary group, which is defined by specifying a dialer interface. Physical
interfaces are assigned to the dialer rotary group and inherit all of the dialer interface
configuration parameters. When many destinations are configured, any of the physical
interfaces in a rotary group can be used for outgoing calls.
Creating and Configuring a Rotary Group

To configure a rotary group, you place each BRI interface in a rotary group. In Figure 8-1, all
of the BRIs are assigned to dialer rotary-group 1. All of these BRI lines are also set in a hunt
group. A hunt group is a series of telephone lines that are programmed so that as incoming
calls arrive, if the first line is busy, the second line is tried, and then the third line is tried, and
so on until a free line is found. This way, an incoming call should not end up with a busy signal.
Figure 8-1 Creating a Hunt Group with Multiple BRIs

interface bri 0
dialer rotary-group 1
interface bri 1
interface bri 2
Single phone
number
interface bri 3
interface dialer 1 Rotary-group 1
NOTE You may still have to perform some of the configuration on the physical interface rather than at
the dialer rotary interface. For example, if you connect to a switch that requires SPIDs, you have
to enter each of the SPIDs separately at each of the physical BRI interfaces.
The rest of the interface configuration is done on the interface dialer 1, the new rotary you
created.
Dialer Rotary Overview 235
NOTE If you install multiple BRIs or PRIs to service remote users, request one phone number from
the service provider. You then assign all of the interfaces to one rotary group, or hunt group, so
that you only need to dial one number for either configuration. Using one number requires only
one set of dialer map statements on the remote routers instead of multiple statements, which
also makes debugging much easier and less complicated.
The interface dialer command in global configuration mode creates a dialer rotary group:
Router(config)#interface dialer group-number
Then, you use the dialer rotary-group command in interface (BRI, Async, and so on)
configuration mode to include that interface in the specified rotary group, as shown in the
syntax that follows. You have to use this command on each interface that you wish to include
in the rotary group.
Router(config-if)#dialer rotary-group rotary-number
The syntaxes for the interface dialer and dialer rotary-group commands are explained in the
following table.
Command Description
interface dialer group-number Defines a dialer rotary group. The group number
ranges from 0 through 255.
dialer rotary-group group-number Includes an interface in a dialer rotary group.
Configuring the Interface Dialer

In the previous chapter, you saw how to configure call parameters under a physical interface.
The following are some commands required for setting up rotary groups.
The command dialer string is used to specify the phone number to dial when placing a call
from an interface to a specific destination. A modem chat-script must be defined and used to
implement dialing on asynchronous interfaces. The syntax is as follows:
Router(config-if)#dialer string dial-string
dialer string and dialer group Commands

If a dialer string command is specified without a dialer group command with access lists
defined, dialing is never initiated. If the debug dialer command is enabled, an error message
displays and indicates that dialing never will occur.
Dealing with Dialer Timers 237
tone. On asynchronous interfaces, this command sets the total time allowed for the chat-script
to run. The default time is 30 seconds. For asynchronous lines, it is better to increase the value
of this parameter to 60 seconds to compensate for the possible delay in the telephone network.
Router(config-if)#dialer wait-for-carrier-time seconds
As you saw in the previous chapter, some configurations are required on only some category of
interfaces. An example of this is the SPID configuration, required only for ISDN BRI interfaces.
Similarly, specific configuration is required when performing DDR with async interfaces.
The dialer in-band command enables DDR and V.25bis dialing on the dialer or async interface.
V.25bis is an ITU-T standard for in-band signaling to bit synchronous DCE devices. A variety
of devices support V.25bis, ranging from analog V.32 modems to ISDN terminal adapters to
inverse multiplexers.
The syntax for the dialer in-band command is as follows:
Router(config-if)#dialer in-band
Other examples of peculiar commands are isdn incoming-voice modem and interface group-
async.
The isdn incoming-voice modem command is used to configure the D channel to switch
incoming analog calls to the internal modems. The syntax for the isdn incoming-voice modem
command is as follows:
Router(config)#interface serial 1/0:23
Router(config-if)#isdn incoming-voice modem
The interface group-async command is used to create an asynchronous group interface, which
can be associated with other asynchronous interfaces. This association allows you to configure
the group interface and all of its members’ interfaces with a single command entered at the
asynchronous group interface command line. Although you can have more than one group
interface on a router, a member interface can be associated with only one group. The syntaxes
of commands for creating a group-async, interface group-async; and to associate members,
group-range, are as follows:
Router(config)#interface group-async 1
Router(config-if)#group-range 65 70
In-Band Signaling
DDR over serial lines requires the use of dialing devices that support V.25bis. V.25bis is an
International Telecommunication Union Telecommunication (ITU-T) Standardization Sector
standard for in-band signaling to bit synchronous data communications equipment (DCE)
devices. A variety of devices support V.25bis, including analog V.32 modems, ISDN terminal
adapters, and inverse multiplexers. This is according to the Cisco Web site at
www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs002.htm.
If you are using a TE2 (non-native ISDN router), your TA will require the dialer in-band
command.
Dialer Profile Overview 239
• Limited dial backup—When a Basic Rate Interface (BRI) or Primary Rate Interface
(PRI) is used to back up an interface, all the B channels are down and the whole interface
is idle. In addition, the one-to-one relationship between interfaces and backup interfaces
does not scale well to a packet-switching environment, in which many virtual circuits
might need to be backed up individually and floating static routes are not desirable.
Dialer profiles let you create different configurations for B channels on an ISDN PRI interface.
Using dialer profiles, you can do the following:
• Configure B channels of an ISDN interface with different IP subnets or IPX networks.
• Use different encapsulations of B channels of an ISDN interface. However, only Point-to-
Point Protocol (PPP) and High-Level Data Link Control (HDLC) encapsulation are now
supported.
• Set different DDR parameters for B channels of an ISDN interface.
• Eliminate the waste of ISDN B channels by letting ISDN BRI interfaces belong to
multiple dialer pools.
NOTE The main difference between a rotary group and a dialer profile is that a physical interface
participates in only one rotary group. With a dialer profile, a physical interface can belong
to many different pools.
Components of Dialer Profile

As illustrated in Figure 8-3, a dialer profile consists of the following elements:
• Dialer interface
• Dialer map-class (optional)
• Dialer pool
• Physical interfaces
Figure 8-3 Elements of a Dialer Profile

Map-Class
Dialer Interface (optional)
Interface
dialer Eng
1
Dialer Pool
Dialer pool 0
BRI0 BRI1 BRI2

Physical Interfaces
Dialer Interface
A dialer interface is a logical entity that uses a per-destination dialer profile.
All configuration settings specific to the destination go into the dialer interface configuration.
Multiple dialer maps can be specified for the same dialer interface. A dialer map can be
associated with different per-call parameters, defined with each dialer map-class.
The dialer interface is configured with the following characteristics:
• IP address of destination network
• Encapsulation type
• PPP authentication type
• Dialer remote name (for PPP CHAP)
• Dialer string or dialer map
• Dialer pool number
• Dialer group number
• Dialer list number
• Multilink PPP
• The optional dialer idle timeout and dialer in-band
The configuration commands that create the relationships between the elements of a dialer
profile are shown in Figure 8-4. The commands and the configuration mode in which they are
used are described in the table that follows the figure.
Figure 8-4 Representation of Dialer Profile Configuration Concepts and Commands
dialer string…class Map-

Dialer
class
interface dialer pool (optional)
dialer pool-member
BRI2
Physical interface Dialer pool
Command Description
dialer string number class A dialer interface command that specifies the phone number of the
map-class-name destination. The use of the optional keyword class followed by the
map-class-name is to point to a specific map-class and use the
configuration commands of that map-class in the call.
dialer pool number A dialer interface command that specifies the pool of physical
interfaces available to reach the destination subnetwork. A number
between 1 and 255 identifies the pool.
dialer pool-member number An interface configuration command that associates and places a
physical interface in a specifically numbered pool.
To configure a dialer profile like any other DDR interface, perform the following tasks:
1 Configure one or more dialer interfaces.
2 Configure a dialer string and (optionally) a dialer map-class to specify different
characteristics on a per-call basis.
3 Configure the physical interfaces and attach them to a dialer pool. You can configure any
number of dialer interfaces for a router. Each dialer interface is the complete configuration
for a destination. The interface dialer global command creates a dialer interface and
enters interface configuration mode.
A dialer profile has the command listed in Example 8-1. The command is explained in the table
that follows the example.
Example 8-1 Command Used with Dialer Profiles
interface dialer1
ip address 10.1.1.1
255.255.255.0
encapsulation ppp
dialer remote-name Smalluser
dialer string 5554540
dialer pool 3
continues
Example 8-1 Command Used with Dialer Profiles (Continued)

dialer-group 1
ppp authentication chap
ppp multilink
!
interface dialer2
ip address 10.2.2.2
255.255.255.0
encapsulation ppp
dialer remote-name Mediumuser
dialer string 5551234 class Eng
dialer load-threshold 50 either
dialer pool 1
dialer-group 2
ppp multilink
interface dialer3
ip address 10.3.3.3 255.255.255.0
encapsulation ppp
dialer remote-name Poweruser
dialer string 4155551234 class Eng
dialer hold-queue 10
dialer idle-timer 9999
dialer pool 2
dialer-group 2
ppp multilink
!
map-class dialer Eng
dialer isdn speed 56
dialer fast-idle 30
dialer hold-queue 75
Command Description
ip address address mask Specifies the IP address and mask of the destination network.
dialer remote-name name Specifies the remote router name, which is passed for CHAP
authentication.
dialer string string class Defines the destination router’s phone number and supports optional
map-class-name map classes. See the following paragraphs for more information on
dialer map classes.
Command Description
dialer load-threshold load Specifies at what traffic load additional links will
[outbound|inbound|either]be brought up for Multilink PPP.
Valid values are 1 to 255. Optionally, you may specify which
direction of traffic is used to calculate the actual load. If you
want the links to remain in a Multilink PPP bundle
indefinitely, use a very high dialer idle-timeout value (9999,
for example) instead of a dialer load-threshold.
dialer hold-queue number–of-packets Specifies the length of the queue for packets waiting for the
line to come up. Valid values are from 0 to 100.
dialer pool number Binds a dialer interface to a dialer pool configured with the
dialer remote-name command, which gives the CHAP
username for a remote user. Valid values are from 1 to 255.
dialer-group group-number Specifies a dialer list that defines interesting packets to
trigger a call for DDR. The dialer-list command can
reference access lists to more specifically define interesting
packets. Valid values are from 1 to 10.
ppp multilink Specifies that this dialer interface uses Multilink PPP. This
command is placed on the physical interface for incoming
calls, in the dialer profile for outgoing calls, and on both the
interface and dialer profile when incoming and outgoing
calls are expected.
Dialer Map Class

The dialer map class is an optional element that defines specific characteristics for a call to a
specified dial string.
For example, the map class for one destination might specify an ISDN speed of 56 Kbps,
whereas a map class for a different destination might specify an ISDN semipermanent
connection. The dialer map class can also contain optional dialer-timing parameters, including
dialer fast-idle, dialer idle-timeout, and dialer wait-for-carrier-time. A map class is an optional
element of a dialer profile and can be used by (or referenced from) multiple dialer interfaces.
Map classes are optional. They are used to specify different characteristics for different types
of calls on a per-destination basis.
Figure 8-5 shows the usefulness of map class. Calls to three different destinations require
many parameters that are the same from one destination to another. Instead of re-entering these
commands under each of the concerned dialer interfaces, it is being told to refer itself to the
map class for further configuration parameters. As you can see, the same map class can be used
for multiple dialer interfaces. The configuration parameters of a map class are specific to one
or more destinations.
After the interface is configured, an optional dialer map class can be defined. In Figure 8-5,
the dialer interface dialer3 is associated with map-class Eng. Any dialer associated with this
map-class sets the ISDN line speed to 56 Kbps.
Figure 8-5 One Map Class Has Configuration Parameters that Are Applicable to Three Different Dialer Profiles
Map-classes
(optional)
Dialer interfaces Map-class Branch Offices
dialer fast-idle 40
Interface dialer idle-timeout 300
dialer dialer hold-queue 80
1 isdn speed 56
Interface
dialer
2
Interface
dialer
3
You can use the map-class dialer class-name command to specify a map class and enter the
map-class configuration mode.
In this example, the dialer isdn speed 56 command specifies an ISDN bit rate of 56 Kbps for
use in the map class. You can set the speed to 56; 64 is the default value.
Additionally, the other map class commands listed in the following table are available in map-
class configuration mode.
Command Description
dialer isdn [speed 56|spc] Specifies the ISDN line speed of 56 kbps (64 kbps is the default;
this parameter is only used with 56 kbps line speed). Note that 64
is not a valid option. [spc] is used for ISDN only, specifying that
an ISDN semipermanent connection is to be used for calls
associated with this map.
dialer idle-timeout seconds Specifies the idle timer values to use for the call. This timer
disconnects the call if there has been no interesting data for the
specified time. Defaults to 120 seconds.
dialer fast-idle seconds Specifies the fast idle timer value to use for a call. This timer
specifies a quick disconnect time if there is another call waiting for
the same interface, and the interface is idle. The waiting call does
not have to wait for the idle timer to expire. Defaults to 20
seconds.
CHAPTER
9
Configuring a Cisco 700 Series
Router
In the previous chapter, you learned how to configure Cisco access servers for ISDN and
how to optimize the connections. In this chapter, you will learn how to provide connectivity
to the Central site for a small office/home office (SOHO) that is equipped with a Cisco 700
Series Router, as shown in Figure 9-1.
Figure 9-1 SOHO Connecting to a Central Site
Async Central site

Cisco 3640
Cisco 700
Multilink PPP, CHAP, DDR, PAT, DHCP
AAA server
AN dialup
nc
g host-L
sy
BRI Analo
,A
AT
PRI
Frame Relay
,N
DR
ISDN/Analog
D
Async
P,
Modem
HA
Windows 95 PC
,C
Frame Relay
PP
Small office service

kP
ilin
BRI
ult
M
Frame Relay
Cisco 1600
Branch Office
Cisco 700 Series Overview

All the routers in the Cisco 700 series product family offer maximum flexibility for remote
access. The product family now includes the Cisco 761M, 762M, 765M, 766M, 771M,
772M, 775M, and 776M routers. These products offer two optional analog telephone
interfaces to allow devices such as standard telephones, facsimile machines, and modems
to share an ISDN BRI line, eliminating the need for multiple telephone lines or expensive
ISDN telephones, as shown in Figure 9-2. Four of the Cisco 700 models offer support for
258 Chapter 9: Configuring a Cisco 700 Series Router
two basic telephone service lines, as well as support for supplemental telephone services over
ISDN. These telephone services include call waiting, cancel call waiting, call hold, call retrieve,
three-way call conferencing, and call transfer.
Figure 9-2 Cisco 700 Used by Telecommuters, Home Offices, and Small Offices
Workstation
Host
AS5200
Cisco 766M
Digital PSTN
BRI PRI
ISDN Access
Router Router
Server
NOTE Earlier models of the 700 series had model numbers without the M suffix. The M suffix
indicates that the routers have 1.5 MB of system RAM.
The Cisco 700 series routers all support IP and IPX routing, transparent bridging, Simple
Network Management Protocol (SNMP) management, and multilevel authentication. All Cisco
700 series routers support the Multilink Point-to-Point Protocol (MP), providing up to 128
Kbps (precompressed) of ISDN bandwidth.
All models in this family also feature ClickStart software, which allows users to configure
Cisco 700 series routers by using a standard World Wide Web browser, such as Netscape
Navigator. ClickStart is a graphical, user-friendly configuration interface that breaks the
installation process into simple steps by prompting the user for the required information, thus
enabling the user to set up a new router in just a few minutes.
The integrated packaging, documentation, user-friendly software, and match-the-colors cabling
design of Cisco Fast Step allows users with no technical experience to have a Cisco 700 series
router set up, tested, and connected to the Internet/intranet in less than 30 minutes. Cisco Fast
Step software is a free, easy-to-use Microsoft Windows 95 or NT version 4-based tool that
simplifies the setup and monitoring of Cisco routers for small offices and home offices. Once
setup is completed, the monitor facility of Fast Step provides instant router status and ISDN
connection information.
Cisco 700 Series Features 259
Cisco 800 Series Routers

Cisco has another SOHO router. It is the Cisco 800. The new Cisco 800 Series of Integrated
Services Digital Network (ISDN) access routers provides big-business networking benefits to
small offices and corporate telecommuters. With Cisco IOS software technology, the Cisco 800
Series offers secure, manageable, high-performance solutions for Internet and corporate LAN
access. You can find more information on the Cisco 800 series router at www.cisco.com.
Cisco 700 Series Features

The Cisco 700 series is fully interoperable with Cisco IOS-based routers such as the Cisco
1600, Cisco 1700, Cisco 2500, Cisco 3600, Cisco 4000, and Cisco 7000 series using Multilink
PPP for IP or IPX routing.
The Cisco 700 series is designed to minimize the complexity of configuring and operating
multiprotocol routers. All Cisco 700 series routers come with the Cisco Fast Step software.
ClickStart, a Web-based application, simplifies initial configuration. Flash memory and TFTP
downloading eliminate the expense of recalling units or sending a person to the remote site to
perform software upgrades.
Personal network profiles make the process of connecting and disconnecting multiple sites
transparent to the user. They enable Cisco 700 users to create customized sets of configuration
parameters, such as filters, demand thresholds, network addresses, calling phone numbers, and
passwords for each remote site that is dialed. Personal network profiles allow on-demand calls
to be made to different telephone numbers, based on demand filters that are tailored for each
remote site.
Because the Cisco 700 series supports remote management using SNMP and Telnet, a network
management team at the Central site can perform all common monitoring functions.
NOTE With version 4.1 of the Cisco IOS-700, Combinet Proprietary Protocol (CPP) is no longer
available, and PPP is the default.
Networking Features
The Cisco 700 series has industry-standard networking features designed to enhance
interoperability, starting with PPP protocol support. Multilevel authentication using Challenge
Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP) is
supported. PPP dial-back security is available to control router access.
B-channel aggregation is supported with industry-standard Multilink PPP. All Cisco 700 series
routers support Multilink PPP, which aggregates both B channels, providing up to 128 Kbps of
ISDN bandwidth.
Cisco 700 series routers also support data compression that is compatible with the Cisco IOS,
with a compression ratio of up to 4:1. When Multilink PPP is combined with a 4:1 compression
ratio, an aggregate throughput of up to 512 Kbps is possible. The Cisco 700 series does not
include data compression; this capability can be added via software at a very low cost by
ordering the Standard Feature Set.
Access-lists provide packet filtering for bridging and routing.
Cisco 700 series routers can function as a Dynamic Host Configuration Protocol (DHCP) relay
agent or DHCP server. When configured, Cisco 700 series routers will relay DHCP requests and
responses between DHCP clients and a specified DHCP server. In addition, port and address
translation (PAT) enables local hosts on a private IP network to communicate over a public
network such as the Internet.
Routing and WAN Features

The Cisco 700 series offers the benefits of IP and IPX routing in a modem-sized package. When
connecting to other Cisco routers, concurrent bridging is also supported.
The Cisco 700 series supports Routing Information Protocol (RIPv1 and RIPv2) for IP routing
updates, with extensions to support demand circuits. IPX routing support includes Novell IPX
Router Specification, Revision A, 9/2/92, with support for IPX spoofing. Cisco’s snapshot
routing is also supported.
DDR ensures that connections will not be inadvertently kept up when they are not in use, which
keeps ISDN charges to a minimum. DDR allows ISDN connections to occur only when the
router senses traffic that has been defined as “interesting” by the user or network administrator.
Access-lists prevent broadcast traffic on the LAN from bringing up the ISDN connection
unnecessarily.
With two ISDN BRI B channels, the Cisco 700 series can support simultaneous sessions with
two sites or share network traffic between the channels. For example, as bandwidth needs
increase, such as when a large file transfer is initiated, the second B channel is brought up
automatically to carry the additional traffic.
This bandwidth-on-demand is supported with industry-standard Multilink PPP, which is also
used for standards-based B-channel aggregation. Support for bandwidth-on-demand using
Multilink PPP and 4:1 data compression enable cost-efficient WAN connections.
Cisco IOS-700 Release 4.x—Summary of Features 261
ISDN and Telephony Features

The Cisco 760 series routers are designed for both North American and international
applications. They support all major ISDN central office switches in use worldwide. The 765
router is especially designed for international use because it has been homologated (certified)
for use in more than 25 countries. It generates local tone (425 Hz) for international basic
(analog) telephone service support. Cisco 760 series routers have met U.S. and international
regulatory approvals, such as UL 1459, FCC part 15 class B, and FCC part 68 certification.
The Cisco 765 and 766 models also provide support for supplemental telephone services over
ISDN, the first such products to offer this feature. Supplemental telephone services supported
include call waiting, cancel call waiting, call hold, and call retrieve. These supplemental
services for ISDN may not be available from certain central office switches; carriers; and Post,
Telephone, and Telegraphs (PTTs).
The Cisco 762, 764, and 766 routers include a built-in NT1 device to provide an all-in-one
solution for ISDN users in North America. In addition to the integrated NT1, the routers also
provide an external S/T port to support additional ISDN devices such as ISDN telephones.
The Cisco 765 and Cisco 766 routers are similar to the Cisco 761 and 762 routers. However,
they support two RJ-11 interfaces for sharing the ISDN BRI line with up to two analog devices
(such as standard telephones, fax machines, and modems), which eliminate the need for
multiple telephone lines or expensive ISDN telephones. Using Cisco’s call-priority feature, the
Cisco 765 and 766 can drop one or both ISDN BRI B channels that are being used for data to
accept or initiate analog calls.
The personal network profiles enable Cisco 760 users to assign multiple ISDN phone numbers
to each profile for flexibility in reaching the destination router.
Initial configuration options for the Cisco 765 and 766 routers can be entered by using a
standard touch-tone telephone.
The Cisco 700 series supports ISDN BRI via a built-in RJ-45 connector.
The Cisco 700 series is compatible with international central office switch-types, which include
I-CTR3 (also known as NET3 or Euro-ISDN for most of Europe), INS HSD64 and 128 (Japan),
VN3 (France), 1TR6 (Germany), and TPH (Australia).
North American switch support includes AT&T 5ESS, Northern Telecom DMS 100, and NI-1
ISDN standards.
Cisco IOS-700 Release 4.x—Summary of Features

Cisco IOS-700 Release 4.0 includes many new features to ease configuration and
administration:
• SAP helper address for NetWare networks
• Stacker compression with IOS routers
• IPX ping and IPX default route

• Automated callback initiated by the D channel
• Second number fail-over
• RIP snapshot routing
• DHCP relay agent and server
• Port and address translation
In addition to the preceding features, the Cisco IOS-700 offers the following key benefits:
• DHCP relay agent Forwards DHCP requests and responses between DHCP clients and
a specified DHCP server. DHCP automates TCP/IP addressing, which saves
administration time and reduces the number of IP addresses that a site may require.
• DHCP server The Cisco 700 series can assign and manage IP addresses from a
specified address pool to DHCP clients.
• Port and address translation (PAT) Allows the remote LAN to be configured by using
private network addresses that are invisible to the outside world. All data from the remote
LAN appears to be coming from the Cisco 700 series router itself. A Cisco 700 series user
needs only a single IP node address, regardless of the number of remote workstations,
which provides significant potential savings when connecting to an Internet service
provider (ISP), and greatly relieves the network management burden for both ISPs and
corporate network managers.
DHCP is a client/server protocol that allows local hosts (called DHCP clients) to request and
receive IP configuration parameters from a DHCP server. These parameters include the IP
address, subnet mask, default gateway, and WINS and DNS server. DHCP is specified in RFC
2132 (obsoletes RFC 1541).
Cisco 700 series routers with Release 4.0 software support PAT. PAT enables local hosts on a
private IP network to communicate over a public network such as the Internet. All traffic
designated to an external address has its source IP address translated before the packet is
forwarded over the public network. IP packets returning to the private network will have their
IP addresses translated back to a private IP address.
Profile Overview
There are two modes in which you can set parameters: the system mode and the profile mode,
as explained in Annex A of the Cisco 700 documentation. System-mode parameters affect the
configuration on a global level. Profiles are individual parameters that are maintained in
configuration sets. Profile-mode parameters affect the way the router handles the connection to
a device.
Profile Overview 263
You do not have to reconfigure the router every time that you connect to a different device.
Instead of using one set of configuration parameters for all devices, you can use different
profiles to communicate with a variety of devices.
For example, you can create a user-defined profile, called 2500, which contains the parameters
to be used when communicating with a Cisco 2500 series router over the WAN. You can
customize your Cisco 700 series router to maintain up to 17 user-defined profiles. Profiles are
saved in the Cisco 700 series router nonvolatile RAM (NVRAM).
NOTE A profile is a set of configurations, customized for and associated with a specific remote device.
After being defined by the user, profiles are saved and stored in a Cisco 700 series router’s
nonvolatile random access memory (NVRAM), which is the memory used to store the router's
configurations. When the router is turned on, the profiles are loaded.
In addition to user-defined profiles, there are three permanent profiles on the Cisco 700, as
shown in Figure 9-3. The following profiles can be modified, but not deleted:
• LAN Determines how data is passed from the router to the LAN. It is used for routing
and with the Ethernet connection.
• Internal Determines how data is passed between the bridge engine and the IP/IPX
router engine. Used when routing is enabled on LAN or USER profiles. It stores the
parameters used to communicate between the LAN and WAN ports on the Cisco 700
series router.
• Standard Used for incoming ISDN connections that do not have a profile. If
authentication is not required and the destination device that you are connecting to does
not have a user-defined profile, the router uses the Standard profile.
Figure 9-3 Cisco 700 Series—Profiles
ISP
IPX Routing engine IPX Routing engine profile
ISDN Connection
LAN Internal Vancouver
profile profile profile
Ethernet
Standard
profile
Bridge engine
NOTE The Standard profile does not support routing, as shown in Figure 9-4. This profile should be
used to provide the appropriate configuration and security measures for unknown callers.
Profile Overview 265
Figure 9-4 Profiles—Manufacturer Defaults
IPX Routing engine IP Routing engine
5
fic
traf
IP
ISDN Connection
LAN Internal
profile profile
4 10.1.1.1
Ethernet
3
2
Standard
IP
tra profile
ffi
c
IP traffic
Bridge engine
1
NOTE Traffic flows from profile to profile through engines—a routing engine or a bridging engine.
Profiles enable users to create customized sets of configuration parameters, such as filters,
demand thresholds, and passwords for each remote site that is dialed. Profiles allow on-demand
calls to be made to different telephone numbers, based on demand filters that are tailored for
each remote site.
Up to 20 profiles (16 user, LAN, standard, system, and internal) can be configured on Cisco 700
series routers.
System parameters are independent of profiles and affect the router as a system. System
parameters can be changed only at the system-level prompt, shown as follows:
Router_name>
As an example of profiles, Figure 9-3 shows three possible connections for the WAN side of the
router: two connections are to and from a known caller, and one connection is from an unknown
caller.
Profile template characteristics are as follows:
• The profile template consists of all the profile parameters, as seen at the system level. All
profiles are based on the profile template by inheriting these values. The profile template
is modified by configuring the profile parameters at the system level.
• Any profile that has a specific profile parameter redefined within the profile is not affected
by a change to the profile template configuration.
• After you configure the profile template, you can customize individual profiles by entering
profile mode for that specific profile and redefining the profile’s parameters.
• Profiles are either active or inactive:
— An active profile immediately creates a virtual connection to that profile’s
associated remote device. After a virtual connection is created, a demand call
can be made to that profile’s associated remote device.
— Inactive profiles have no connection associated with them. No demand calls can
be made with a profile that is configured as inactive.
— Activity status is configured with the set profile command. To display these
settings for an individual profile, use the show profile command while in profile
mode for the profile.
Profile guidelines are as follows:
• LAN and Internal profiles provide the same basic function.
• Any protocol routed in the LAN profile must be routed in the User profile in order to allow
that protocol to be forwarded.
• Any protocol routed in the Internal profile may be routed or bridged in the User profile.
• If IP routing is for the Internal profile, the router is a pingable device.
• For IP to be bridged, the Internal profile must be enabled instead of IP routing.
Profile parameters are parameters that can be configured on a per-profile basis, and therefore
apply only to the connection with the remote router. After creating a new profile, these
parameters can be reconfigured within that profile. Any configuration changes to profile
parameters while in profile mode apply only to that profile. The following are some common
user profile parameters set on a Cisco 700:
• Demand Parameters
• Called Number
• Subnet Mask
• PPP Authentication
Configuring the Cisco 700 Series 267
• Default Gateway
• Passwords
• CHAP Host Secret
• PAP Host Password
• IP Parameters
Cisco 700 User Interface

The user interface has a UNIX-like directory structure, as shown in Figure 9-5. Commands are
set by entering set commands on the command-line interface. Also, to navigate from one profile
to another, the cd (change directory) command is used.
Figure 9-5 Cisco 700 Uses a UNIX-like Directory Structure for USER Profiles
System level
Standard Internal LAN userjane userbob userjoe
The set commands are automatically saved in NVRAM, and reset commands remove
commands from NVRAM. To initialize the system, enter set default. The set default command
is the same as the erase start command, followed by the reload command in the Cisco IOS
software.
The show command displays information and parameters.
You can save set commands in a text file off-line, and copy and paste them at the command-line
prompt to configure the router.
Configuring the Cisco 700 Series

You must specify system level, LAN profile, and user profile parameters to prepare the Cisco
700 router for operation in an ISDN environment.
• System level configuration Select the switch that matches the ISDN provider’s switch
at the CO. This requirement is necessary because, despite standards, signaling specifics
differ regionally and nationally. Set destination details, such as the directory numbers, and
enter Service Profile Identifiers (SPIDs), if required. System-level configuration also
includes assigning a system name and setting Multilink PPP off if you are connecting to
a Cisco IOS router running Release 11.0(3) or earlier.
• LAN profile configuration Specify an IP address and subnet mask for the Ethernet
interface. Specify the types of packets to be routed. In this case, turn IP routing on and set
IP RIP update to periodic.
• User profile configurations Specify the characteristics of each user that you plan to
dial. In our application, there is only one user—the ISP on the other end of the ISDN
connection. Assign the user a name, set IP routing on, set the framing type, set the ISDN
phone number you will dial, set the encapsulation type, and set the static route.
Once these profiles are created, you can define optional features, including caller ID,
authentication type, and timeout value for the ISDN connection.
System Level Configuration

Use the set switch global command to specify the CO switch to which the router connects. For
BRI ISDN service, the switch type can be one of those listed in Table 9-1.
Table 9-1 Cisco 700 ISDN Switch Commands
Command Description
set switch switch-type Defines the type of switch you are using
5ess AT&T basic rate switches (U.S.)
dms NT DMS-100 (North America)
ni-1 National ISDN-1 (North America)
1tr6 German 1TR6 ISDN switches
net3 Switch type for NET3 in United Kingdom and Europe
perm64 Dedicated line service--B channel 1 runs at 64 Kbps; channel
2 not used
perm128 Dedicated line service--both B channels combined to give
128 Kbps
NOTE Auto-detect of ISDN switch type is available in later versions of the IOS-700. Separate IOS-
700 images may require country-specific switches. The default if no switch is specified is basic-
5ess.
Several ISDN providers use ISDN switches that operate on dial-in numbers called SPIDs. The
SPIDs are used to authenticate that call requests are within contract specifications. These
switches include National ISDN-1 and DMS-100 ISDN switches, as well as the AT&T 5ESS
switch. The set 1 spid and set 2 spid commands are used on some switches and are
replacements for subaddresses. The local SPID number is supplied by the service provider.
activated on the LAN profile and IP routing is not turned on the standard profile, as shown in
Figure 9-6, the IP traffic will pass from the standard profile to the bridge engine (1), pass to the
LAN profile (2), and come out on the Ethernet interface/LAN profile (3). The difficulty arises
with the return-trip packets (4). The return traffic is routed from the LAN profile to the IP
Routing Engine (5). Having no access to the standard profile, the return traffic gets caught and
stops in the routing engine. The following is a typical misconfiguration:
cd lan
set bridging on
set ip routing on
set ip address 10.1.1.1
cd internal
set bridging on
cd standard
set bridging on
Figure 9-6 Problem with LAN Profile Routing and Internal Profile Bridging
5
fic
traf
IP
LAN Internal ISDN Connection

profile profile
4 10.1.1.1
Ethernet
3
2
Standard
IP
tra profile
ffi
c
IP traffic
Bridge engine
1
The solution is to turn off routing on the LAN interface and apply Layer 3 configuration to the
internal profile.
Configuring the Cisco 700 Series 273
Figure 9-8 The Solution with User Profile—LAN Profile Bridging And Internal Profile Routing
9
1
2 10
ISDN Connection
LAN Internal
profile profile user Chicago
10.1.1.1 profile
6
Ethernet
192.168.1.1
4 8
3
7
Standard
profile
Bridge internal
If you change an IP address of a profile, the IP routing is suspended, even if it still appears under
the same profile when performing the upload command. To reactivate the IP routing process,
you have to either reload the Cisco 700 or type under the profile set ip routing on.
User Profile Configuration

Use the set encapsulation ppp command if you want PPP encapsulation for your ISDN
interface and if you want any of the LCP options that PPP offers (for example, CHAP
authentication). You must use PPP PAP or CHAP if you will receive calls from more than one
dial-up source. This command must be entered if you are connecting to a Cisco IOS router.
In addition to these commands, each user profile must include the username (set user
username), ip address (set ip address ip address), and subnet mask (set ip netmask netmask)
of the user. You must also turn on IP routing using the set ip routing on command.
Additional Interface Configuration 279
• Implement Multilink PPP for better bandwidth use.

• Cisco 700 routers implement Multilink PPP by default.
NOTE You must manually turn off the multilink capability if your router is connecting to a Cisco IOS
router running Release 11.0(3) or earlier.
Caller ID
Different commands are used on the Cisco 700 series router and the Cisco IOS router to
configure caller ID. The commands for the Cisco 700 series router are issued at the system
prompt level. The commands for the Cisco IOS router are issued at the BRI 0 interface level.
Figure 9-11 and the command descriptions in Tables 9-3 and 9-4 provide examples of caller ID.
Figure 9-11 Caller ID Scenario

ISDN phone number ISDN phone number
14085551234 14085554321
IOS ISO-700
ISDN
Router Router
Table 9-3 Cisco 700 Caller ID Commands

Cisco IOS-700 Commands Description
set caller id on Enables caller ID on the ISDN interface.
set callidreceive 14085551234 Allows calls to be authorized, if received from the
14085551234 telephone number.
Table 9-4 Cisco IOS Caller ID commands

Cisco IOS Commands Description
interface bri0 Specifies the ISDN interface on which you want caller
ID authentication.
isdn caller 14085554321 Allows ISDN calls to be authorized on this interface if
they are received from the 14085554321 telephone
number.
Figure 9-16 Cisco 700 Configured as a DHCP Server
192.168.1.10
192.168.1.11
192.168.1.12
DHCP server
192.168.1.10
As a DHCP relay agent, the Cisco 700 series router will relay DHCP requests and responses
between DHCP clients on the local Ethernet segment and a remote DHCP server across the
WAN segment, as shown in Figure 9-17.
Figure 9-17 Cisco 700 Configured as a DHCP Relay Agent
192.168.1.10
192.168.1.11
192.168.1.12
192.168.1.10
DHCP server
DHCP relay agent
Using the Cisco 700 as a relay agent eliminates the need to have a DHCP server on every
segment.
The relay agent fills in the IP address in the gateway field of the DHCP request, so the server
can set the scope (what range of addresses) from which the client will be assigned an address.
In an IOS router, DHCP relay is enabled by the use of the ip helper interface command.
DHCP Server Configuration

Example 9-14 shows the required commands to configure a Cisco 700 as a DHCP server, as
shown in Figure 9-18.
Example 9-14 Cisco 700 Series Router DHCP Server Configuration
>SEt SYStem LA766
LA766>SEt DHcp SERver
LA766>SEt DHcp ADdress 192.168.200.2 252
LA766>SEt DHcp NETmask 255.255.255.0
LA766>SEt DHcp GAteway PRImary 192.168.200.1
LA766>SEt DHcp DNS PRImary 192.168.1.1
LA766>SEt DHcp WINS PRImary 192.168.1.1
LA766>SEt DHcp Domain WayNet
Cisco 700 Series and DHCP 293
Figure 9-18 DHCP Server Configuration
DHCP server
WINS/DNS
server
DHCP server
IP address pool
192.168.200.2 - 254
192.168.200.???
192.168.1.1
ISDN
7xx
192.168.200.1
Table 9-12 contains command descriptions for the configuration in Example 9-14.
Table 9-12 Cisco 700 Series Router DHCP Commands
Command Description
SEt DHcp SERver Enables DHCP server functionality on the Cisco 700.
SEt DHcp ADdress 192.168.200.2 252 Specifies the starting address of the pool and the
number of addresses in the pool. In this case, the
assigned addresses can range from 192.168.200.2 to
192.168.200.254.
SEt DHcp NETmask 255.255.255.0 Specifies the subnet mask that DHCP clients will use.
SEt DHcp GAteway PRImary Specifies the 700 as the default gateway. Note that this
192.168.200.1 address should match the IP address configured on the
LAN profile.
SEt DHcp DNS PRImary 192.168.1.1 Specifies the DNS address for DHCP clients.
SEt DHcp WINS PRImary 192.168.1.1 Specifies the WINS server for DHCP clients.
Set DHcp Domain WayNet Specifies the NT domain of the DHCP server.
Some points to remember when configuring the DHCP server are as follows:
• When the DHCP server is initialized, default addresses are used if no existing LAN or
Internal addresses exist. If a manually configured LAN or Internal address exists, the
router defines the default gateway, netmask, and DHCP address pool based on this
address. If neither exists, it uses the default settings of 10.0.0.1 as the LAN IP address,
255.0.0.0 as the subnet mask, 10.0.0.2 as the starting DHCP client address, and 10.0.0.1
(the LAN interface address) as the primary gateway address.
• Unlike DHCP relay, DHCP server and IPCP will not automatically initiate a call, even if
AUTO is OFF.
• In order for the DHCP server parameters to be automatically generated and used based on
the LAN or Internal IP address, each DHCP parameter must be set to 0 or to none.
• To reset the DHCP server configuration, each value must be reset by using the reset
command.
DHCP Relay Agent Configuration

Configuring a DHCP relay agent on a Cisco 700 series router is easy. At the system level, you
only need to add one command:
SEt DHcp RElay ip address of DHCP server
To view DHCP configuration, enter the following:

SHow DHcp Config
Example 9-15 is a configuration example of a Cisco 700 relay agent, as seen in Figure 9-19.
Example 9-15 Cisco 700 Series DHCP Relay Agent
>SEt SYStem LA766
LA766>SEt SWitch 5ESS
LA766>SEt ENCapsulation PPp
LA766>SEt PPp Authentication INcoming CHap
LA766>SEt PPp Authentication OUtgoing CHap
LA766>SEt PPp SEcret Client
LA766>SEt DHcp RElay 192.168.1.1
Figure 9-19 Cisco 700 DHCP Relay Agent Example
DHCP client
DHCP relay
agent
ISDN
192.168.1.1
DHCP server
Solution to Case Study—Configuring a Cisco 700 Series Router 299
Task 4—Placing a Manual ISDN Call from the Cisco 700

To test the capability of the two routers to communicate, have the Cisco 700 place a call to the
Central site router.
Task 5—Configuring the Cisco 700 to Receive Incoming Calls from the
Central Site
Finish the configuration on the home office router so it can receive incoming calls from the
Central site and authenticate with CHAP.
NOTE One of the default commands with a Cisco 700 series is set ppp authentication incoming chap
pap. This command configures your Cisco 700 series router to accept and respond to incoming
authentication requests, whether the request is for CHAP or PAP authentication.
That is the reason you were not asked in this case study to provide a command that would
specify what kind of authentication request your router would entertain.
Step 1 Provide the configuration for your Cisco 700 series router that will ensure a
two-way authentication using CHAP.
Step 2 Provide a command to specify that the password used by the Central site
when authenticating will be cisco.
Step 3 Look at your Cisco 700 series router’s configuration to confirm that all the
required commands are configured.
Step 4 Look at the Central site router to confirm proper configuration.
Solution to Case Study—Configuring a Cisco 700 Series

Router
The following is a step-by-step discussion of the case study solution.
Task 1 Solution—Resetting the Cisco 700 to Default Settings

Step 1 To reset a Cisco 700 to its default, enter the command set default.
Step 2 To display the configuration of a Cisco 700, enter the command upload.
CHAPTER
10
Using X.25 for Remote Access

With Part V of this book, we embark on the study of permanent wide area network
connections. This chapter focuses on X.25 technology. It covers how X.25 works, how to
implement it, and how it can provide permanent connectivity between two offices, as shown
in Figure 10-1.
Figure 10-1 Branch Office and Central Office, Permanently Connected Using X.25
Async
Central site
BRI AAA server

ISDN/analog
PRI
Async
Windows 95 PC Modem
Small office
BRI X.25
service
X.25
Branch office
X.25 Overview
X.25 is a standard that defines the connection between a terminal and a packet-switching
network. X.25 offers the closest approach to worldwide data communication available, and
virtually every nation uses some X.25-addressable network.
X.25 originated in the early 1970s. The networking industry commonly uses the term X.25
to refer to the entire suite of X.25 protocols.
314 Chapter 10: Using X.25 for Remote Access
Engineers designed X.25 to transmit and receive data between alphanumeric “dumb” terminals
through analog telephone lines. X.25 enabled dumb terminals to remotely access applications
on mainframes or minicomputers.
Because modern desktop applications need LAN-to-WAN-to-LAN data communication,
engineers designed newer forms of wide-area technology: Integrated Services Digital Network
(ISDN) and Frame Relay. In many situations, these newer WANs complement or extend X.25,
rather than replace it.
Many different network-layer protocols can be transmitted across X.25 virtual circuits (VCs),
which results in tunneling that has datagrams or other Layer 3 packets within the X.25 Layer 3
packets. This setup is shown in Figure 10-2. Each Layer 3 packet keeps addressing legal for its
respective protocol, whereas the X.25 VC transports the packet across the WAN.
Figure 10-2 X.25 Uses Virtual Circuits to Carry Datagrams
X.25 cloud
LAN LAN
protocol protocol
X.25 X.25
Virtual
circuit
• IP • DECnet
• AppleTalk • ISO-CLNS
• Novell IPX • Compressed TCP
• Banyan VINES • Bridging
• XNS
X.25 Protocol Stack

The X.25 packet-switching protocol suite compares to the lower three layers of the Open
System Interconnection (OSI) model, as shown in Figure 10-3.
X.25 Overview 315
Figure 10-3 X.25 and the OSI Model

OSI Reference Model X.25 Protocol
7 Application •
6 Presentation •
5 Session •
4 Transport •
3 Network X.25 3
2 Data Link LAPB 2
1 Physical Physical 1
In general, X.25 is used as an overengineered data link in the internetworking world. Both X.25
at Layer 3 and Link Access Procedure, Balanced (LAPB) at Layer 2 provide reliability and
sliding windows. Layers 3 and 2 were designed with strong flowcontrol and error checking to
reduce the requirement for these functions external to X.25.
X.25 evolved in the days of analog circuits, when error rates were much higher than today. For
analog circuit technology at Layer 1, it is more efficient to build more reliability into the
network at the hardware level. With digital or fiber-optic technologies, the error rates have
dropped dramatically. Newer technologies, such as Frame Relay, have taken advantage of drops
in error rates by providing a stripped-down, “unreliable” data link.
X.25 was designed in the days of alphanumeric terminals and computing on central
time-sharing computers. Demands on the packet switch were lower than today. Today’s
complex applications on desktop workstations demand more bandwidth and speed. Newer
technologies such as ISDN and X.25 over Frame Relay add packet-switching capability.
X.25 DTE and DCE

Data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for X.25
identify the responsibilities of the two stations on an X.25 attachment. The X.25 protocol
implements virtual circuits between the X.25 DTE and X.25 DCE.
Although the terms DTE and DCE occur at all three layers associated with the X.25 stack, the
use shown in the figure identifies responsibilities that are independent of the Physical layer
DTE/DCE. The terms DTE/DCE are independent of the typical plug-gender and clock-source
definitions used at the Physical layer.
The X.25 DTE is typically a router or a packet assembler/disassembler (PAD).
The X.25 packet-level DCE typically acts as a boundary function to the public data network
(PDN) within a switch or concentrator. The X.25 switch at the carrier site may also be called
data switching equipment (DSE). X.25’s use of DTE/DCE terminology differs from the usual
Physical layer interpretation.
The way X.25 traffic is carried within the carrier cloud depends on the implementation. In some
cases, X.25 is also used within the cloud.
NOTE X.25 DTE is usually a subscriber's router or PAD.

X.25 DCE is usually a PDN's switch or concentrator.
The Packet Assembler/Deassembler (PAD)

The PAD is a device that collects data from a group of asynchronous terminals and periodically
outputs the data in X.25 packets, as represented in Figure 10-4. A PAD also takes data packets
from a host and turns them into a character stream that can be transmitted to the terminals. The
operation of the terminal-PAD interface, the services offered by a PAD, and the PAD-host
control interaction are defined by the International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) recommendations.
Figure 10-4 The PAD Collects Data and Outputs It into X.25 Packets
Public data network (PDN)
PAD
X.25 X.25
DCE DCE
DTE DTE host
Asynchronous
terminals
ITU-T Recommendations for PAD Services

Some ITU-T recommendations defining the PAD are as follows:
• X.3—Specifies the parameters for terminal-handling functions (such as baud rate,
flowcontrol, character echoing, and other functions) for a connection to an X.25 host.
The X.3 parameters are similar in function to Telnet options or the AT command set for
modems.
• X.28—Specifies the user interface for locally controlling a PAD. X.28 identifies the
keystrokes that you would enter at a terminal to set up the PAD, similar to the AT
command set for modems.
X.25 Overview 317
• X.29—Specifies a protocol for setting the X.3 parameters via a network connection.
When a connection is established, the destination host can request that the PAD or
terminal change its parameters by using the X.29 protocol. A PAD cannot tell the
destination host to change its X.3 parameters, but it can communicate that its own
parameters were changed.
• X.75—Specifies the gateway between the clouds. It defines the signaling system between
two PDNs. X.75 is essentially an NNI.
X.121—The X.25 Addressing Standard

The format of X.25 addresses is defined by the ITU-T X.121 standard:
• The first four digits specify the Data Network Identification Code (DNIC). The first three
digits specify the country code. The fourth digit is the provider number assigned by the
ITU-T. Countries that require more than ten provider numbers are assigned multiple
country codes. The U.S., for example, is assigned country codes 310 through 316 to
represent the country code, and the fourth digit is assigned by the ITU-T.
• The remaining 8 to 10 or 11 digits specify the network terminal number (NTN) that is
assigned by the packet-switched network (PSN) provider.
NOTE For your specific DNIC code, consult your service provider. For a listing of ITU-T country code
assignments, refer to the ITU-T Recommendation X.121. The ITU-T Web site is www.itu.org.
A sample of the DNIC country codes is listed in Table 10-1.

Table 10-1 X.121 DNIC Country codes
Region X.121 Country Code Range
Zone 1 Oceans for ImmarSAT 100s
Zone 2 (predominantly Europe) 200s
United Kingdom 234–237
Germany 262–265
France 208–209
Austria 232
Belgium 206
Zone 3 (predominantly North America) 300s
United States 310–316
continues
Table 10-1 X.121 DNIC Country codes (Continued)

Region X.121 Country Code Range
Canada 302–303
Jamaica 338
Zone 4 (predominantly Asia) 400s
Japan 440–443
Zone 5 (predominantly Australia, New Zealand, and 500s
Pacific islands)
Australia 505
New Zealand 530
Zone 6 (predominantly Africa) 600s
South Africa 655
Morocco 604
Zone 7 (predominantly South America) 700s
Brazil 724
Argentina 722
For different network protocols to connect across X.25, statements are entered on the router to
map the next-hop Network layer address to an X.121 address. For example, an IP Network layer
address is mapped to an X.121 address to identify the next-hop host on the other side of the
X.25 network.
These statements are logically equivalent to the LAN Address Resolution Protocol (ARP) that
dynamically maps a Network layer address to a data-link media access control (MAC) address.
Maps are required for each protocol because ARP is not supported in an X.25 network.
Mapping statements are a manual configuration step required when setting up X.25 on the
router.
Unlike the ARP that dynamically maps a Network layer address, static X.25 map statements
must be configured manually.
X.25 Encapsulation
Movement of Network layer data through the internetwork usually involves encapsulation of
datagrams inside media-specific frames. As each media frame arrives at the router and is
discarded, the router analyzes the datagram and places it inside a new frame as it is forwarded.
X.25 Virtual Circuits 319
The X.25 specification maps to Layers 1 through 3 of the OSI reference model. Layer 3 X.25
describes packet formats and packet-exchange procedures between peer Layer 3 entities. Layer
2 X.25 is implemented by Link Access Procedure, Balanced (LAPB).
The same layer of the OSI reference model occurs twice. As shown in Figure 10-5, Layer 3
occurs twice: once for the IP datagram and once for X.25. When the system forwards a
datagram to an X.25 interface, the maps are consulted to determine the X.25 destination.
Figure 10-5 Protocol Datagrams Are Reliably Carried Inside LAPB Frames and X.25 Packets
IP Network IP Network
X.25
Data-link
X.25
frame IP datagram (Layer 3)
header (Layer 3)
(LAPB) (Layer 2)
Similarly, in an X.25 environment, the LAPB frame arrives at the router, which extracts the
datagram from the packet or packets. The router discards the encapsulating frame and analyzes
the datagram to identify the format and next-hop. Based on the route determination, the router
re-encapsulates the datagram in framing suitable for the outgoing media as it forwards the
traffic.
X.25 Virtual Circuits

VCs are used interchangeably with the terms virtual circuit number (VCN), logical channel
number (LCN), and virtual channel identifier (VCI).
A VC can be a permanent virtual circuit (PVC) or, more commonly, a switched virtual circuit
(SVC). An SVC exists only for the duration of the session.
Three phases are associated with SVCs:
• Call setup
• Information transfer
• Call clear
A PVC is similar to a leased line. Both the network provider and the attached X.25 subscriber
must provision the virtual circuit. PVCs use no call setup or call clear that is apparent to the
Configuring X.25 321
X.25 Encapsulation
Two methods are available to encapsulate traffic in X.25: Cisco's long-available encapsulation
method and the IETF's standard method (defined in RFC 1356). The latter allows hosts to
exchange several protocols over a single virtual circuit. Cisco's encapsulation method is the
default (for backward compatibility), unless the interface configuration command specifies
IETF.
Configuring X.25
When you select X.25 as a WAN protocol, you must set appropriate interface parameters.
Interface tasks are as follows:
• Define the X.25 encapsulation (DTE is the default).
• Assign the X.121 address (usually supplied by the PDN service provider).
• Define map statements to associate X.121 addresses with higher-level protocol addresses.
Other configuration tasks can be performed to control data throughput and to ensure
compatibility with the X.25 network service provider. Commonly used parameters include the
number of VCs allowed and packet size negotiation.
X.25 is a flow controlled protocol. The default flow control parameters must match on both
sides of a link. Mismatches because of inconsistent configurations can cause severe
internetworking problems.
NOTE Before configuring X.25 parameters, you must enter interface configuration mode and assign a
higher layer address, such as an IP address to the interface.
Configuring the X.121 address

The x25 address command defines the local router’s X.121 address (one address per interface).
The value specified must match the address designated by the X.25 PDN:
Router(config-if)#x25 address x.121-address
The x25 map command provides a static conversion of higher-level addresses to X.25
addresses. The command correlates the network-layer addresses of the peer host to the peer
host’s X.121 address:
Router(config-if)#x25 map protocol address x.121-address [options]
The following table describes the x25 map command.

Table 10-2 Description of the x25 map Command

x25 map Command Description
protocol Selects the protocol type. Supported protocols are ip, xns, decnet, ipx,
appletalk, vines, apollo, bridge, clns, and compressed tcp.
address Specifies the protocol address (not specified for bridged or CLNS
connections).
x.121-address Specifies the X.121 address. Both the protocol address and the X.121
addresses are required to specify the complete network protocol-to-
X.121 mapping.
options Used to customize the connection (optional). One commonly used option
is broadcast. The broadcast option causes the Cisco IOS software to
direct any broadcasts sent through this interface to the specified X.121
address.
If you try to communicate with a host that understands multiple protocols over a single VC, use
the following x25 map command:
Router(config-if)#x25 map protocol address
[protocol2 address2]* x.121-address [options]
This communication requires the multiprotocol encapsulations defined by RFC 1356. In the
preceding x25 map command, the * means that a maximum of nine network protocol addresses
may be associated with one host destination in a single configuration command.
NOTE Bridging is not supported with the x25 map command. To bridge a protocol over X.25, use the
x25 map bridge command.
Configuring X.25 SVCs

To activate X.25 on an interface, you must enter the encapsulation x25 command to specify
the encapsulation style to be used on the serial interface:
Router(config-if)#encapsulation x25 [dte | dce]
The router can be an X.25 DTE device, which is typically used when the X.25 PDN is used to
transport various protocols. The router can also be configured as an X.25 DCE device, which is
typically used when the router acts as an X.25 switch.
NOTE If you change the interface configuration from an X.25 DCE to X.25 DTE or vice versa, the
interface configuration will change to the default interface settings.
Configuring X.25 SVC Examples

Figure 10-6 shows a sample network to be configured for X.25.
Figure 10-6 Typical X.25 Network to Be Configured
Central site Branch office

S1 S0
Token
Ring X.25
IP address: 10.60.8.1 IP address: 10.60.8.2

X.121 address: 311082194567 X.121 address: 311082191234
Example 10-1 shows the Central site SVC configuration for the network in Figure 10-6.
Example 10-1 Central Site X.25 Configuration
Central(config)#interface serial 1
Central(config-if)#encapsulation x25
Central(config-if)#x25 address 311082194567
Central(config-if)#ip address 10.60.8.1 255.255.248.0
Central(config-if)#x25 map ip 10.60.8.2 311082191234 broadcast
Example 10-2 shows the branch office SVC configuration for the network in Figure 10-6.
Example 10-2 Branch Office X.25 Configuration
Branch(config)#interface serial 0
Branch(config-if)#encapsulation x25
Branch(config-if)#x25 address 311082191234
Branch(config-if)#ip address 10.60.8.2 255.255.248.0
Branch(config-if)#x25 map ip 10.60.8.1 311082194567 broadcast
Table 10-3 describes the commands that are used in this example.
Table 10-3 Basic X.25 Configuration Commands
Command Description
encapsulation x25 Sets the encapsulation style on interface serial 1 to X.25 type.
x25 address 311082194567 Establishes the X.121 address of serial 1.
x25 map To set up the LAN protocols-to-remote host mapping for X.25 WAN
protocol.
ip A Layer 3 protocol specified for address association.
10.60.8.2 IP address of serial 0 that is mapped.
311082191234 The X.121 address of the host that defines the IP address.
IP routing on Cisco A forwards datagrams destined for subnet 10.60.8.0 to interface serial 1.
The interface map identifies the destination to the X.25 cloud. In this typical configuration,
Cisco A tries to establish an SVC to Cisco B using its X.121 source address and a destination
X.121 address of 311082191234 when it sends packets to 10.60.8.2.
Upon receipt of the setup request, Cisco B identifies the remote IP address from the source
X.121 address and accepts the connection. Once the SVC is connected, each router uses it as a
point-to-point data link for the identified destination.
The two X.25 attachments need complementary map configurations to establish the VC that
will encapsulate IP datagrams.
NOTE This example illustrates the use of the broadcast option on the x25 map command. It is not
typically used in cases when you do not want the link to continually come up to send broadcasts.
The sample network in Figure 10-7 illustrates an X.25 network if multiple circuits are
established from the Central site router. In Example 10-3, the separate x25 map statements are
configured to create separate links to each branch office. In this case, the same network layer
protocol, IP, is used.
Figure 10-7 Multiple SVC Mapped at the Central Site

S1 S0
Token
Ring X.25

Branch office
S0
IP address: 10.60.8.3
X.121 address: 311082198901
Example 10-3 Central Site X.25 Configuration to Multiple Destinations

Configuring X.25 PVCs

As you did when configuring X.25 SVCs, use the encapsulation x25 command to specify the
encapsulation style to be used on the serial interface:
Router(config-if)#encapsulation x25 [dte | dce]
As you did when configuring X.25 SVCs, use the x25 address command to define the local
router’s X.121 address (one address per interface). The value specified must match the address
designated by the X.25 PDN:
Router(config-if)#x25 address x.121-address
Instead of establishing an1414 SVC with the x25 map command, you can establish a
permanent virtual circuit (PVC). PVCs are the X.25 equivalent of leased lines; they are never
disconnected. You do not need to configure an address map before defining a PVC; an
encapsulation PVC implicitly defines a map. To establish an encapsulation PVC, enter the x25
pvc command in interface configuration mode. Command syntax follows:
Router(config-if)#x25 pvc circuit protocol address
[protocol2 address2]* x.121-address [options]
The following table describes the x25 pvc command.

Table 10-4 Description of the x25 pvc Command
x25 pvc Command Description
circuit Virtual circuit channel number, which must be less than the virtual circuits
assigned to the SVCs.
protocol Protocol type entered by keyword. Supported protocols are appletalk,
bridge, clns, compressedtcp, decnet, ip, ipx, qllc, vines, and xns. As many
as nine protocol and address pairs can be specified in one command line.
address Protocol address of the host at the other end of the PVC.
x121-address X.121 address.
options Used to customize the connection (optional). One commonly used option
is broadcast. The broadcast option causes the Cisco IOS software to direct
any broadcasts sent through this interface to the specified X.121 address.
Multiple protocols can be routed on the same PVC. Multiple circuits can also be established on
an interface by creating another PVC.
NOTE Before configuring X.25 parameters, you must enter interface configuration mode and assign a
higher layer address, such as an IP address to the interface.
Configuring X.25 PVC Examples

The example in Figure 10-8 demonstrates how to use the PVC to exchange IP traffic between
the Central site and branch office router.
Figure 10-8 X.25 PVCs Link the Branch Office with the Central Site

S1 S0
Token
Ring X.25
PVC 3 PVC 4
In this example, the public network has established a PVC through its network, connecting PVC
number three to PVC number four. On the Central site router, a connection is established
between the Central site router and the branch office IP address, 10.60.8.2. On the branch office
router, a connection is established between the branch office and Central site IP address,
10.60.8.1.
Example 10-4 shows the Central site PVC configuration for the network shown in Figure 10-8.
Example 10-4 Central Site X.25 PVC Configuration
Central(config-if)#x25 pvc 4 ip 10.60.8.2 311082191234 broadcast
Example 10-5 shows the branch office PVC configuration for the network shown in Figure 10-8.
Example 10-5 Branch Office X.25 PVC configuration
Branch(config)#interface serial 0
Branch(config-if)#encapsulation x25
Branch(config-if)#x25 address 311082191234
Branch(config-if)#ip address 10.60.8.2 255.255.248.0
Branch(config-if)#x25 pvc 3 ip 10.60.8.1 311082194567 broadcast
Additional X.25 Configuration Tasks

It may be necessary to perform additional configuration steps so that the router will work
correctly with the service provider network. Crucial X.25 parameters are as follows:
• Virtual circuit (VC) range—Incoming, two-way, and outgoing
• Default packet sizes—Input and output
• Default window sizes
• Window modulus
Additional X.25 Configuration Tasks 327
Configuring X.25 VC Ranges

Table 10-5 summarizes additional configuration tasks for VC assignment. The complete range
of VCs is allocated to PVCs or SVCs, depending on your requirements. SVCs are commonly
used.
Table 10-5 X.25 VC Ranges
VC Use Range Default Command
PVC 1–4095 No default, but the x25 pvc circuit
number must be greater
than zero.
SVC 1–4095 0 x25 lic circuit
Incoming only 1–4095 0 x25 hic circuit
SVC 1–4095 1 x25 ltc circuit
Two-Ways 1–4095 1024 x25 htc circuit
SVC 1–4095 0 x25 loc circuit
Outgoing Only 1–4095 0 x25 hoc circuit
NOTE Decode the abbreviations used in the command column of Table 10-5, as follows:
i incoming
t two-way
o outgoing
l low
h high
c circuit
The circuit numbers must be assigned so that an incoming range comes before a two-way range,
both of which come before an outgoing range. Any PVCs must take a circuit number that comes
before any SVC range. The following numbering scheme lists the proper order for these VC
assignment commands:
1 ≤ PVCs < (lic ≤ hic) < (ltc ≤ htc) < (loc ≤ hoc) ≤ 4095
(Where lic is a low incoming circuit number, hic is a high incoming circuit number, ltc is a low
two-way circuit number, htc is a high two-way circuit number, loc is a low outgoing circuit
number, and hoc is a high outgoing circuit number.)
If both limits of a range are zero, the range is unused.
X.25 ignores any events on a VC number that are not in an assigned VC range; it considers the
out-of-range VC as a protocol error. The network administrator specifies the VC ranges for an
X.25 attachment. For correct operation, the X.25 DTE and DCE devices must have identically
configured ranges. Numbers configured for any PVCs must also agree on both sides of an
attachment (not necessarily end-to-end).
The following example may help you understand why you would configure VC ranges. If you
acquire 10 circuits from your SVC provider and use all 10 on a given situation, incoming calls
cannot get through. You can partition the 10 circuits to be dedicated to different calling
situations—incoming, outgoing, or either:
1 Incoming
2 Incoming
3 Incoming
4 Either
5 Either
6 Either
7 Either
8 Outgoing
9 Outgoing
10 Outgoing
If many incoming calls are coming in, some circuits are still available for outgoing calls.
Configuring X.25 Packet Sizes

The x25 ips and x25 ops commands set the default maximum input/output packet size:
To set the incoming packet size, use the x25 ips command:
Router(config-if)#x25 ips bytes
To set the outgoing packet size, use the x25 ops command:
Router(config-if)#x25 ops bytes
Table 10-6 describes the x25 ips and x25 ops command.
Table 10-6 Description of x25 ips and x25 ops Commands

x25 ips and x25 ops Commands Description
bytes Maximum packet size assumed for VCs that do not negotiate a
size. Supported values are 16, 32, 64, 128, 256, 512, 1024,
2048, and 4096. Default is 128 bytes.
Additional X.25 Configuration Tasks 329
The input and output values should match unless the network supports asymmetric
transmissions. If the stations of an X.25 attachment conflict on the VC’s maximum packet size,
the VC is unlikely to work.
Fragmentation is a feature of X.25. The PAD will reassemble the IP packet at the destination.
NOTE Before configuring the maximum packet size on your X.25 WAN connection, ask your service
provider what is the maximum packet size your provider supports.
Configuring Window Parameters

Use the x25 win and x25 wout commands to set the default window size. The window size
specifies the number of packets that can be received or sent without receiving or sending an
acknowledgment. Both ends of an X.25 link must use the same default window size.
Therefore, to specify default unacknowledged packet limits, use the following commands:
Router(config-if)#x25 win packets
Router(config-if)#x25 wout packets
Table 10-7 describes the x25 win and x25 wout commands.
Table 10-7 Description of the x25 win and x25 wout Commands
x25 win and x25 wout Commands Description
packets Packet window size, assumed for VCs that do not negotiate
a size. Range is one to one less than the modulus. The
default is two packets.
The x25 modulo command specifies the packet-numbering modulus. It affects the maximum
number of window sizes. Modulo 8 is widely used and allows VC sizes up to seven packets.
Modulo 128 is rare, but it allows VC window sizes up to 127 packets.
The command to define packet-level window counter limits is as follows:
Router(config-if)#x25 modulo modulus
Table 10-8 describes the x25 modulo command.

Table 10-8 Description of the x25 modulo Command
x25 modulo Command Description
modulus Either 8 or 128.
Both ends of an X.25 link must use the same modulo.

340 Chapter 11: Frame Relay Connection and Traffic Flow Control
Frame Relay Overview

Frame Relay is an International Telecommunication Union Telecommunication
Standardization Sector (ITU-T; formerly the Consultative Committee for International
Telegraph and Telephone [CCITT]) and American National Standards Institute (ANSI)
standard that defines the process for sending data over a public data network (PDN). It is a
connection-oriented, data-link technology that is streamlined to provide high performance and
efficiency, as shown in Figure 11-2. It relies on upper-layer protocols for error correction, and
today’s more dependable fiber and digital networks. It uses the services of many different
Physical layer facilities at speeds that typically range from 56 Kbps up to 2 Mbps.
Figure 11-2 Frame Relay Uses Connection-Oriented Virtual Circuits
DCE or Frame
Relay switches
DTE or
CPE CSU/DSU
routers
Frame Relay works here

Token
Ring
NOTE The Frame Relay forum can be found at www.frforum.com.
Note that Frame Relay defines the interconnection process between your customer premises
equipment (CPE—also known as data terminal equipment [DTE]) such as a router, and the
service provider’s local access-switching equipment (known as data communications
equipment [DCE]). It does not define the way the data is transmitted within the service
provider’s Frame Relay cloud.
Frame Relay differs significantly from X.25 in its functionality and format. In particular, Frame
Relay is a more streamlined protocol. It does not have the windowing and retransmission
strategies of X.25. This simplicity facilitates higher performance and greater efficiency that is
appropriate for use over faster, less error-prone networks. As a result, Frame Relay is
appropriate for uses that require high throughput, such as LAN interconnection. Frame Relay
is a purely Layer 2 protocol.
The network providing the Frame Relay service can be either a carrier-provided public network
or a network of privately owned equipment serving a single enterprise.
Frame Relay Overview 341
NOTE Frame Relay over switched virtual circuits (SVCs) is not discussed in this chapter or this course
because it is not widely supported by service providers at this time. The service provider must
also support SVCs in order for Frame Relay to operate over SVCs.
Frame Relay Operation

Frame Relay provides a means for statistically multiplexing many logical data conversations
(referred to as virtual circuits) over a single physical transmission link by assigning connection
identifiers to each pair of DTE devices. The service provider’s switching equipment constructs
a table that maps connection identifiers to outbound ports. When a frame is received, the
switching device analyzes the connection identifier and delivers the frame to the pre-established
associated outbound port.
The virtual circuits can be either permanent virtual circuits (PVCs) or switched virtual circuits
(SVCs). PVCs are permanently established connections that are used when there is frequent and
consistent data transfer between DTE devices across a Frame Relay network.
With ANSI T1.617, ITU-T Q.933 (Layer 3), and Q.922 (Layer 2), Frame Relay now supports
SVCs. SVCs are temporary connections, used when there is only sporadic data transfer between
DTE devices across the Frame Relay network. Because they are temporary, SVC connections
require call setup and termination for each connection. Cisco IOS Release 11.2 or later supports
Frame Relay SVCs. You will need to determine whether your carrier supports SVCs before
implementing them.
A data-link connection identifier (DLCI) identifies the logical virtual circuit between the CPE
and the Frame Relay (FR) switch. The Frame Relay switch maps the DLCIs between each pair
of routers to create a PVC. DLCIs have local significance in that the identifier references the
point between the local router and the Frame Relay switch to which it is connected. Your Frame
Relay provider sets up the DLCI numbers to be used by the routers for establishing PVCs.
Local Significance
DLCIs have local significance; that is, the end devices at two different ends of a connection may
use a different DLCI to refer to that same connection. Figure 11-5 provides an example of one
VC identified at each end by two different DLCI numbers.
Because the DLCIs have only local significance, the only real restriction on the use of DLCIs
is that they are not used for more than one destination from the same port.
You configure an available DLCI number to map this provided Frame Relay number to a
network address. For example, an administrator might map to an IP address of the interface on
Frame Relay Overview 343
DLCI Numbering Scheme

The Frame Relay service provider will assign the DLCI numbers for your WAN. Usually,
DLCIs 0 to 15 and 1008 to 1023 are reserved for special purposes. Therefore, service providers
are typically assigned DLCIs in the range of 16 to 1007.
Multicasts can use DLCI 1019 through 1020. Cisco LMI uses DLCI 1023 and ANSI/ITU-T
uses DLCI 0 (there is a discussion on LMI in the following section).
Frame Relay Signaling

Local Management Interface (LMI) is a signaling standard between the CPE device and the FR
switch that is responsible for managing the connection and maintaining status between the
devices. As shown in Figure 11-4, LMIs include support for the following:
• A keepalive mechanism, which verifies that data is flowing
• A multicast mechanism, which provides the network server with its local DLCI
• The multicast addressing, which gives DLCIs global rather than local significance in
Frame Relay networks
• A status mechanism, which provides an ongoing status on the DLCIs known to the switch
Figure 11-4 The Connection Between the Router and the Frame Relay Switch Is Managed by the LMI Signaling
Standard
LMI keepalive
500=Active 172.16.11.3
400=Inactive
DLCI=500 PVC
CSU/DSU
DLCI=400
PVC
Although the LMI is configurable, beginning in Release 11.2, the Cisco router tries to autosense
which LMI type the Frame Relay switch is using by sending one or more full status requests to
the Frame Relay switch. The Frame Relay switch responds with one or more LMI types. The
router configures itself with the last LMI type received. Three types of LMIs are supported:
• cisco LMI type, defined jointly by Cisco, StrataCom, Northern Telecom, and Digital
Equipment Corporation, nicknamed “the gang of four”
• ansi Annex D of the ANSI standard T1.617
• q933a ITU-T Q.933 Annex A
Additional Frame Relay Standards

Other key ANSI standards are T1.606, which defines the Frame Relay architecture; and T1.618,
which describes data transfer. The International Telecommunication Union Telecommunication
Standardization sector specifications include I.122, which defines ITU-T Frame Relay
architecture; and Q.922, which standardizes data transfer. Use of these LMI standards is
especially widespread in Europe.
Regarding the Cisco LMI, Compaq acquired Digital and Cisco acquired StrataCom. We could
call it “the gang of three”: Cisco, Compaq, and Nortel. Resistance being futile, most Frame
Relay switching equipment supports the Cisco LMI.
An administrator setting up a connection to a Frame Relay network must choose the appropriate
LMI from the three supported types to ensure proper Frame Relay operation.
Frame Relay Extensions

In addition to the basic Frame Relay protocol functions for transferring data, the “gang of four”
promoted the following extensions:
Virtual circuit status messages (common) These messages provide communication and
synchronization between the network and the user device. They periodically report the
existence of new PVCs and the deletion of already existing PVCs, and generally provide
information about PVC integrity. Virtual circuit status messages prevent the sending of data into
black holes, that is, over PVCs that no longer exist.
Multicasting (optional) Multicasting allows a sender to transmit a single frame, but have it
delivered by the network to multiple recipients. Thus, multicasting supports the efficient
conveyance of routing protocol messages and address-resolution procedures that typically must
be sent to many destinations simultaneously.
Global addressing (optional) Global addressing gives connection identifiers global rather
than local significance, which allows them to be used to identify a specific interface to the
Frame Relay network. Global addressing makes the Frame Relay network resemble a local area
network (LAN) in terms of addressing; address resolution protocols therefore perform over
Frame Relay exactly as they do over a LAN.
Simple flow control (optional) This provides for an XON/XOFF flow-control mechanism
that applies to the entire Frame Relay interface. It is intended for those devices whose higher
layers cannot use the congestion notification bits and that need some level of flow control.
The source for this information is www.cisco.com.
Configuring Frame Relay 345
When an inverse ARP request is made, the router updates its map table with three possible LMI
connection states, as follows:
• Active state Indicates that the connection is active and that routers can exchange data.
• Inactive state Indicates that the local connection to the Frame Relay switch is working,
but the remote router’s connection to the Frame Relay switch is not working.
• Deleted state Indicates that no LMI is being received from the Frame Relay switch, or
that there is no service between the CPE router and Frame Relay switch.
Configuring Frame Relay

A basic Frame Relay configuration assumes that you want to configure Frame Relay on one or
more physical interfaces. Perform the following steps to enable Frame Relay:
1 Select the interface and enter interface configuration mode.
2 Configure a network layer address, for example, an IP address.
3 Select the encapsulation type used to encapsulate data traffic end-to-end:

router(config-if)#encapsulation frame-relay [cisco | ietf]
cisco is the default. Use it if connecting to another Cisco router. Select ietf if connecting
to a non-Cisco router.
4 If using Cisco IOS Release 11.1 or earlier, specify the LMI-type used by the FR switch:
router(config-if)#frame-relay lmi-type {ansi | cisco | q933i}
cisco is the default.

With IOS Release 11.2 or later, the LMI type is autosensed, so no configuration is needed.
Frame Relay Keepalives

If you configure under the serial interface no keepalive, the LMI will stop. (You can find more
information on Frame Relay on Cisco Connection Online.) For example, according to CCO,
“Keepalives (messages sent through a connection to ensure that both sides will continue to
regard the connection as active) and PVC status messages are examples of these messages, and
are the common LMI features that are expected to be a part of every implementation that
conforms to the consortium specification.”
5 Configure addressing mapping. Figure 11-3 provides a visual representation of address

mapping.
Use the frame-relay map command to configure static address mapping. In Figure 11-5, the
headquarters router is configured with a static map to the branch router. The syntax for the
command is as follows:
Router(config-ig)#frame-relay map protocol protocol-address dlci [broadcast]
➥[ietf | cisco]
frame-relay map Command Description

protocol Selects the protocol type. Supported protocols are appletalk, clns,
decnet, ip, xns, and vines.
protocol-address Specifies the protocol address (not specified for bridged or CLNS
connections).
dlci DLCI number used to connect to the specified protocol address
on the interface.
broadcast (Optional) Broadcasts should be forwarded when multicast is not
enabled.
ietf (Optional) Enables the Internet Engineering Task Force (IETF)
encapsulation.
cisco (Optional) Enables the Cisco encapsulation. This is the default.
Figure 11-5 Basic Frame Relay Configuration with a Map Command
Branch office
Central site
DLCI=100
DLCI=110 VC
IP address=10.16.0.2/24
IP address=10.16.0.1/24
Router(config)#interface Serial1
Router(config-if)#encapsulation frame-relay
Router(config-if)#bandwidth 56
Router(config-if)#frame-relay map ip 10.16.0.2 110 broadcast CISCO
Configuring Frame Relay 347
Frame Relay Encapsulation and Mapping

There are two possible encapsulations of frame in Frame Relay. Cisco's own frame
encapsulation has a four-byte header, with two bytes for the DLCI and two bytes to identify the
packet type. The IETF standard is in accordance with RFCs 1294 and 1490, and it uses a two-
byte header, as shown in Figure 11-6. Configure IETF based on map entries and protocol for
more flexibility. Use this method of configuration for backward compatibility and
interoperability. [source: www.cisco.com]
On the subject of Frame Relay Inverse and mapping, some administrators let Inverse ARP
discover the DLCIs, and then do the hard-coding entry of mapping Layer 3 addresses to DLCI
numbers with the frame-relay map command. This strategy makes it easier for your support
staff to gain information on the Frame Relay network.
Earlier, you had to configure the encapsulation on the serial interface with the frame-relay
encapsulation command.
In this example, the default encapsulation, which is Cisco, is applied to all the VCs available on
that serial interface. This is fine if the destinations’ routers are all Cisco. If the equipment at the
destinations were non-Cisco, you would have to configure with frame-relay encapsulation
ietf. So, every frame leaving your router would be encapsulated in an IETF format.
What if most destinations use the Cisco encapsulation, but one destination requires the IETF?
In such a case, you would specify, under the interface, the general encapsulation to be used by
most destinations. Because the default encapsulation is Cisco, you would not have to mention
it in part of the encapsulation frame-relay, as shown in the following example. You would
specify the exception using the frame-relay map command:
router(config-if)#encapsulation frame-relay
router(config-if)#frame-relay map ip 192.1.1.7 73 IETF
Figure 11-6 Frame Relay Format
Field length, 1 2 Variable 2 1

in bytes
Flags Address Data FCS Flags
On Cisco routers, address mapping can be either configured manually with static address
mapping, or dynamic address mapping can be used.
If you use dynamic address mapping, Frame Relay Inverse ARP provides a given DLCI and
requests next-hop protocol addresses for a specific connection. The router then updates its
mapping table and uses the information in the table to route outgoing traffic. Dynamic address
mapping is enabled by default for all protocols enabled on a physical interface. No additional
commands are necessary.
Verifying Frame Relay Configuration and Operations 349
Example 11-1 The show interface serial Command Provides Information on Frame Relay Configuration
Router#show interface serial 0
Serial0 is up, line protocol is up
Hardware is CD2430 in sync mode
MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
LMI enq sent 112971, LMI stat recvd 112971, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
FR SVC disabled, LAPF state down
Broadcast queue 0/64, broadcasts sent/dropped 32776/0, interface broadcasts 14
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
<Output Omitted>
Local Loop Identifier—Circuit Number

A typical Frame Relay WAN is composed of numerous sites that are connected to the central
office via a local loop. The Telco identifies these individual local loops with a circuit number,
such as: 05QHDQ101545–080TCOM-002. Telco technicians typically leave a label on the
CSU/DSU with the circuit number. When you call the telco for help with troubleshooting your
Frame Relay WAN, you will be required to provide the circuit number.
To simplify the management of your WAN, use the description command at the interface level
to record the circuit number:
Halifax(config)#interface serial 0
Halifax(config-if)#description Cicuit-05QHDQ101545-080TCOM-002
Halifax(config-if)#^z
Halifax#show interface serial 0
Serial 0 is up, line protocol is up Hardware is MCI Serial
Description Cicuit-05QHDQ101545-080TCOM-002
Internet address is 150.136.190.203, subnet mask 255.255.255.0
show frame-relay pvc Command

The show frame-relay pvc command displays the status of each configured connection, as well
as traffic statistics. This command is also useful for viewing the number of BECN and FECN
packets received by the router, as shown in Example 11-2.
Example 11-2 The show frame-relay pvc Command Provides Information on PVCs
Router#show frame-relay pvc 110
PVC Statistics for interface Serial0 (Frame Relay DTE)
DLCI = 110, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
continues
Example 11-2 The show frame-relay pvc Command Provides Information on PVCs (Continued)
input pkts 14055 output pkts 32795 in bytes 1096228

out bytes 6216155 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 32795 out bcast bytes 6216155
show frame-relay map Command

The show frame-relay map command displays the current map entries and information about
the connections, as shown in Example 11-3.
Example 11-3 The show frame-relay map Command Provides Information on Layer 2 and Layer 3 Addresses
Router#show frame-relay map
Serial2 (up): IP 131.108.122.2 dlci 20(0x14,0x0440), dynamic
CISCO, BW= 56000, status defined, active
show frame-relay lmi Command

The show frame-relay lmi command displays LMI traffic statistics, as seen in Example 11-4.
For example, it shows the number of status messages exchanged between the local router and
the Frame Relay switch.
Example 11-4 The show frame-relay lmi Command Provides Statistics on the Frame Relay Connection
Router#show frame-relay lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 113100 Num Status msgs Rcvd 113100
Num Update Status Rcvd 0 Num Status Timeouts 0
Frame Relay Topologies

Frame Relay allows you to interconnect your remote sites in a variety of ways; by default,
interfaces that support Frame Relay are multipoint connection types. Example topologies, as
shown in Figure 11-7, include the following:
• A star topology, also known as a hub-and-spoke configuration, is the most popular Frame
Relay network topology. In this topology, remote sites are connected to a Central site that
generally provides a service or application.
Frame Relay Topologies 351
• This is the least expensive topology because it requires the fewest PVCs. In this scenario,
the Central router provides a multipoint connection because it is typically using a single
interface to interconnect multiple PVCs.
• In a full-mesh topology, all routers have virtual circuits to all other destinations. This
method, although costly, provides direct connections from each site to all other sites, and
allows for redundancy. When one link goes down, a router at site A can reroute traffic
through site C, for example. As the number of nodes in the full-mesh topology increases,
the topology becomes increasingly more expensive.
• In a partial-mesh topology, not all sites have direct access to a Central site.
NOTE The formula to calculate the total number of VCs with a fully-meshed WAN is (n(n–1))/2.
Figure 11-7 Frame Relay Topologies
Full Mesh
Partial Mesh
Star (Hub and Spoke)
By default, interfaces that support Frame Relay are multipoint connection types. This type of
connection is not a problem when only one PVC is supported by a single interface. However, it
is a problem when multiple PVCs are supported by a single interface. In this situation, routing
updates received by the Central router cannot be broadcast to the other remote sites.
Depending on the traffic patterns in your network, you may want to have additional PVCs
connect to remote sites that require heavy data traffic. In any of these cases, when a single
interface must be used to interconnect multiple sites, you may have reachability issues because
of the nonbroadcast multiaccess (NBMA) nature of Frame Relay. With Frame Relay running
multiple PVCs over a single interface, the primary issue is with split horizon.
Reachability Issues with Routing Updates

By default, a Frame Relay network provides NBMA connectivity between remote sites. NBMA
connectivity means that although all locations can reach each other, depending on the topology,
routing update broadcasts received by one router cannot be forwarded to all locations because
Frame Relay networks use split horizon to reduce the number of routing loops.
Non-Broadcast Multiaccess (NBMA)

NBMA networks are those networks that support many (more than two) routers, but have no
broadcast capability, such as Frame Relay.
Split horizon reduces the number of routing loops by not allowing a routing update received
on one interface to be forwarded through the same interface. As shown in Figure 11-8, Central
router’s interface S0 receives a routing update from router BranchA. Central router is
connecting three PVCs over a single interface. Split horizon forbids the Central router to send
out updates via the same interface that it used to receive them. Therefore, BranchB and BranchC
routers will never receive the update.
Split Horizon—an Explanation

Split horizon says that you cannot advertise a route out of the same interface through which you
learned the route. This means that BranchB and BranchC will still receive an update from A.
However, the update will not contain any information that is learned through that interface. The
information from another interface on A will go to both BranchB and BranchC. Split horizon
is actually not an issue if you do not want BranchB and BranchC to know about each other's
local networks. [source: Karen Bagwell, CCIE and CCSI]
Figure 11-8 Split Horizon at Work In a Partially Meshed Network without Subinterfaces
Branch A
Rou
t
upd ing
DLC ate
Branch B I 51
Central
int
DLCI 52 s0
Branch C
I 53
DLC Split horizon
There are two inherent problems with multiple PVCs terminating in one interface: split horizon
and the support for broadcast traffic.
Broadcasts are not a problem if there is only a single PVC on a physical interface because this
would be more of a point-to-point connection type.
Another issue with routers that support multipoint connections over a single interface is that
when many DLCIs terminate in a single router, that router must replicate routing updates and
service advertising updates on each DLCI to the remote routers. The updates can consume
access-link bandwidth and cause significant latency variations in user traffic. The updates can
also consume interface buffers and lead to higher packet-rate loss for both user data and routing
updates.
The amount of broadcast traffic and the number of virtual circuits terminating at each router
should be evaluated during the design phase of a Frame Relay network. Overhead traffic, such
as routing updates, can affect the delivery of critical user data, especially when the delivery path
contains low-bandwidth (56 Kbps) links.
One common solution to split horizon is subinterfaces, which are covered in the upcoming
section.
Solution for Split Horizon Issues—Subinterfaces

The simplest answer to resolving the reachability issues brought on by split horizon might seem
to be to simply turn off split horizon. However, two problems exist with this solution. First, only
IP allows you to disable split horizon; IPX and AppleTalk do not. Second, disabling split
horizon increases the chances of routing loops in your network.
To enable the forwarding of broadcast routing updates in a Frame Relay network, you can
configure the router with logically assigned interfaces called subinterfaces. Subinterfaces are
logical subdivisions of a physical interface. In split-horizon routing environments, routing
updates received on one subinterface can be sent out another subinterface. In subinterface
configuration, each virtual circuit can be configured as a point-to-point connection, which

allows the subinterface to act similar to a leased line.
NOTE A key reason for using subinterfaces is to allow distance-vector routing protocols to perform
properly in an environment in which split horizon is activated.
Subinterfaces themselves do not enable the forwarding of broadcasts. Instead, each destination
is perceived to be on its own interface. Therefore, the router receiving a broadcast on
subinterface S0.1, for example, is capable of reforwarding the same routing information out of
its interfaces S0.2 and S0.3.
In Figure 11-9, reconsider the situation in which BranchA sends a routing update to Central.
With subinterfaces, Central receives the update on its interface S 0.1 and is therefore able to
pass to BranchB and BranchC the same update, sending it out through interfaces S0.2 and S0.3.
Figure 11-9 Partially Meshed Frame Relay Network Using Subinterfaces

Branch A
Rou
ti
upd ng
ate
DLC
I 51
Branch B Central
Routing
update
s0.1=51
s0.2-52
DLCI 52
s0.3=53
ting
Branch C Rou
te
upda
I 53
DLC
Configuring Frame Relay Subinterfaces

You can configure subinterfaces to support the following connection types:
• Point-to-point A single subinterface is used to establish one PVC connection to another
physical or subinterface on a remote router. In this case, the interfaces would be in the
same subnet, and each interface would have a single DLCI. Each point-to-point
connection is its own subnet. In this environment, broadcasts are not a problem because
the routers are point-to-point and act like a leased line.
• Multipoint A single subinterface is used to establish multiple PVC connections to

multiple physical interfaces or subinterfaces on remote routers. In this case, all the
participating interfaces would be in the same subnet, and each interface would have its
own local DLCI. In this environment, because the subinterface is acting like a regular
NBMA Frame Relay network, broadcast traffic is subject to the split horizon rule.
Figure 11-10 provides the visual representation for this example of subinterface configuration:
Router(config)#<Output Omitted>
Router(config-if)#interface Serial0
Router(config-if)#no ip address
Router(config)#interface Serial0.2 point-to-point

Router(config-if)#frame-relay interface-dlci 110
!
Router(config)#interface Serial0.3 point-to-point
Router(config-if)#frame-relay interface-dlci 120
!
<output omitted>
Figure 11-10 Configuring Subinterfaces

Central
site s0.2-DLCI=110 s0.1
s0.3-DLCI=120 s0.3
Branch
office
s0.2
s0.1
Branch office
To configure subinterfaces on a physical interface, perform the following steps:

1 Select the interface that you want to create subinterfaces on, and enter the interface
configuration mode.
2 Remove any network layer address that is assigned to the physical interface. If the
physical interface has an address, frames will not be received by the local subinterfaces.
3 Configure Frame Relay encapsulation, as discussed in the “Configuring Basic Frame

Relay” section.
4 Select the subinterface you want to configure:
Router(config-if)#interface serial number subinterface-number
{multipoint | point-to-point}
interface serial Command Description

number The physical interface number, such as interface serial
0.
subinterface-number Subinterface number in the range 1 to 4294967293. The
interface number that precedes the period (.) must
match the interface number to which this subinterface
belongs. The number of subinterfaces that is possible on
one interface is dependent on the interface descriptor
block (IDB). The IDB is a set of data structures that
provide a hardware and software view of network
interfaces.
multipoint Select this if you want the router to forward broadcasts
and routing updates that it receives. Select this if you’re
routing IP and you want all routers to be in the same
subnet.
point-to-point Select this if you do not want the router to forward
broadcasts or routing updates, and if you want each pair
of point-to-point routers to have its own subnet.
5 Configure a network layer address on the subinterface. If the subinterface is point-to-point

and you are using IP, you can use the ip unnumbered command:
Router(config-if)#ip unnumbered interface
If you use this command, it is recommended that the interface be the loopback interface.
This is because the Frame Relay link will not work if this command is pointing to an
interface that is not fully operational, and a loopback interface is less likely to fail. When
using ip unnumbered, it should have two ends on the same major network.
6 If you configured the subinterface as multipoint or point-to-point, you must configure the
local DLCI for the subinterface to distinguish it from the physical interface:
Router(config-if)#frame-relay interface-dlci dlci-number
Traffic Shaping and Flow Terminology

The traffic shaping over Frame Relay feature applies to Frame Relay PVCs and SVCs.
You should be familiar with some terminology related to Frame Relay traffic flow. Common
Frame Relay terms related to traffic flow follow:
• Local access rate The clock speed (port speed) of the connection (local loop) to the
Frame Relay cloud. It is the rate at which data travels into or out of the network, regardless
of other settings.
• Committed Information Rate (CIR) The rate, in bits per second, that the Frame Relay
switch agrees to transfer data. The rate is usually averaged over a period of time, referred
to as the committed rate measurement interval (Tc). In general, the duration of Tc is
proportional to the "burstiness" of the traffic.
• Oversubscribe and oversubscription Oversubscription is when the sum of the CIRs
on all the VCs coming in to a device exceeds the access line speed. Oversubscription can
occur when the access line can support the sum of CIRs purchased, but not of the CIRs
plus the bursting capacities of the VCs. If oversubscription occurs, packets are dropped.
• Committed Burst (Bc) The maximum number of bits that the switch agrees to transfer
during any committed rate measurement interval (Tc). The higher the Bc-to-CIR ratio is,
the longer the switch can handle a sustained burst. For example, if the Tc is two seconds
and the CIR is 32 Kbps, the Bc is 64 Kbps. The Tc calculation is Tc = Bc/CIR.
NOTE Tc is not a recurrent time interval. It is used strictly to measure inbound data, during which it
acts like a sliding window. Inbound data triggers the Tc interval.
• Excess Burst (Be) The maximum number of uncommitted bits that the Frame Relay
switch attempts to transfer beyond the CIR. Excess Burst is dependent on the service
offerings available from your vendor, but it is typically limited to the port speed of the
local access loop.
• Forward Explicit Congestion Notification (FECN) When a Frame Relay switch
recognizes congestion in the network, it sends an FECN packet to the destination device,
indicating that congestion has occurred, as shown in Figure 11-11.
• Backward Explicit Congestion Notification (BECN) When a Frame Relay switch
recognizes congestion in the network, it sends a BECN packet to the source router,
instructing the router to reduce the rate at which it is sending packets, as shown in Figure
11-11. With Cisco IOS Release 11.2 or later, Cisco routers can respond to BECN
notifications. This topic is discussed later in this chapter.
Configuring Frame Relay Traffic Shaping

To enable Frame Relay traffic shaping, perform the following steps.
1 Specify a map class. Specify a map class to be defined with the map-class frame-relay
command:
Router(config)#map-class frame-relay map-class-name
2 Define the map class. When you define a map class for Frame Relay, you can do the
following:
— Define the average and peak rates (in bits per second) that are allowed on virtual
circuits associated with the map class.
— Specify that the router dynamically fluctuates the rate at which it sends packets,
depending on the BECNs it receives.
— Specify either a custom queue-list or a priority queue-group to use on virtual
circuits associated with the map class.
Once in map class configuration mode, you can define the average and peak rates, specify
that the router dynamically fluctuate the rate at which it sends packets—depending on the
BECNs it receives, or specify either a custom queue-list or a priority queue-group to use
on virtual circuits associated with the map class. See the following section, "Ways to
Define a Map Class," for different ways to define a map class for traffic shaping.
3 Enable Frame Relay on an interface. Once you have defined a map class with queuing
and traffic-shaping parameters, enter interface configuration mode and enable Frame
Relay encapsulation on an interface with the encapsulation frame-relay command,
discussed earlier in this chapter in the "Configuring Frame Relay" section.
4 Enable Frame Relay traffic shaping on an interface with the frame-relay traffic-
shaping command. Enabling Frame Relay traffic shaping on an interface enables both
traffic shaping and per-virtual circuit queuing on all the PVCs and SVCs on the interface.
Traffic shaping enables the router to control the circuit’s output rate and react to
congestion notification information if also configured:
Router(config-if)#frame-relay traffic-shaping
5 Map the map class to virtual circuits on the interface. ap a map class to all virtual
circuits on the interface with the frame-relay class map-class-name command. The map-
class-name argument must match the map-class-name of the map class you configured:
Router(config-if)#frame-relay class map-class-name
NOTE The map class can be mapped to the interface or to a specific subinterface on the interface.
Configuring Frame Relay Traffic Shaping 363
Ways to Define a Map Class

This section shows the different ways to define a map class for traffic shaping.
Traffic Shaping through Rate Enforcement

Define the average and peak rates if the data is being sent faster than the speed at which the
destination is receiving. If you define the average and peak rates (in bits per second) that are
allowed on virtual circuits associated with the map class, use the frame-relay traffic-rate
average [peak] command.
Router(config-map-class)#frame-relay traffic-rate average [ peak]
frame-relay traffic-rate Command Description

average Average rate in bits per second; it is equivalent to
specifying the contracted CIR.
peak (Optional) Peak rate, in bits per second. Peak = CIR + Be/Tc
= CIR(1 + Be/Bc) = CIR + EIR.
Traffic Shaping through Dynamic Enforcement

Specify that the router dynamically fluctuate the rate at which it sends packets, depending on
the BECNs that it receives if you want the sending router to adjust its transmission rate based
on the BECNs received. To select BECN as the mechanism to which traffic shaping will adapt,
use the frame-relay adaptive-shaping becn command.
NOTE The frame-relay adaptive-shaping command replaces the frame-relay becn-response-

enable command.
Traffic Shaping through Queuing

Specify either a custom queue-list or a priority queue-group to use on virtual circuits associated
with the map class if you want to use Cisco queuing mechanisms to control traffic flow.
NOTE Queuing is covered in Chapter 13, "Managing Network Performance with Queuing and
Compression."
To specify a custom queue-list, use the frame-relay custom-queue-list number command.

CHAPTER
12
Enabling Backup to a Permanent
Connection
In the two previous chapters, you learned how to enable permanent connections between a
Central site and a branch office by using X.25 or Frame Relay. How can you provide
connectivity between the two sites if the permanent connection goes down?
This chapter describes the need and circumstances for using the Cisco dial-backup
functionality.
You will learn how to configure a backup connection for a primary link, such as a Frame
Relay serial connection, if the link goes down or is overutilized.
Dial Backup Overview

A backup interface is an interface that stays idle until certain circumstances occur, and
then it is activated. The backup interface can be a physical interface or an assigned backup
interface to be used in a dialer pool. Backup interface examples for a primary line can be
an Integrated Services Digital Network (ISDN), an asynchronous interface, a dialer pool,
or another serial interface.
NOTE The backup interface is referred to often in Cisco documentation as the secondary link.
A backup interface can be configured to activate when the following situations occur:
• The primary line goes down
• The primary line reaches a certain load threshold
Configuring Dial Backup

Backup interfaces are beneficial for redundancy, in case primary lines fail. The example in
Figure 12-1 illustrates an ISDN backup for a Frame Relay network.
380 Chapter 12: Enabling Backup to a Permanent Connection
Figure 12-1 When the Primary Link Fails, the Backup (Secondary) Link Takes Over by Establishing a Connection to
the Destination
Frame Relay
Primary
Network
ISDN
Network
Secondary
To configure backup if a primary line goes down, perform the following steps:
1 Select the primary interface, and configure it as needed (for dial-on-demand routing,
Frame Relay interfaces and subinterfaces, X.25, and so on):
Router(config)#interface serial 0
2 Use the following command on the primary interface to specify the interface or dialer
interface to use for backup. (Interface number specifications vary from router to router.
For example, some routers require you to just specify the port number; others require you
to specify the slot and port.)
Router(config-if)#backup interface interface-type number
3 Define the period of time to wait before enabling the backup link after the primary link
goes down with the following command syntax, which is explained in the table that
follows:
Router(config-if)#backup delay {enable-delay | never} {disable-delay | never}
backup delay Command Description

enable-delay Number of seconds that elapse after the primary line goes down
before the Cisco IOS software activates the secondary line.
disable-delay Number of seconds that elapse after the primary line comes up,
before the Cisco IOS software deactivates the secondary line.
never Prevents the secondary line from being activated or deactivated.
Example of Dial Backup for Link Failure

In Figure 12-2, interface serial 0 (S0) is the primary interface. You can see from the
configuration displayed in the figure that if the primary interface is down for 40 seconds, the
Configuring Dial Backup 381
backup interface (BRI0) will be activated. The secondary line will deactivate 20 seconds after
the primary line is re-enabled.
NOTE The example in Figure 12-2 illustrates only the commands to enable a backup. The interface
must also be configured as needed (for DDR, Frame Relay, X.25, and so on).
Figure 12-2 Dial Backup Configuration for a Link Failure

Primary
Frame Relay
Branch Office Network Central Site
S0 S0
Bri0
Bri0
ISDN
Network
Secondary
Router(config)#interface serial 0 Terminate the

secondary 20
Router(config-if)#backup interface bri 0
seconds after
Router(config-if)#backup delay 40 20 the primary link
is reactivated.
Use for backing up Enable backup 40

link failures. seconds after the
primary line failure.
Floating Static Route

An alternative to dial backup for link failure is a floating static route. Floating static routes are
static routes that have an administrative distance greater than the administrative distance of
dynamic routes. Administrative distances can be configured on a static route, so that the static
route is less desirable than a dynamic route. In this manner, the static route is not used when the
dynamic route is available. If the dynamic route is lost, however, the static route can take over,
and traffic can be sent through this alternative route. When this alternative route is provided by
a DDR interface, DDR is used as a backup mechanism.
Activating a Dial Backup to Support Primary Line Traffic

You can configure a backup to activate the secondary line, based on the traffic load on the
primary line. The software monitors the traffic load and computes a five-minute moving
average. If this average exceeds the value you set for the line (as shown in Figure 12-3), the
secondary line is activated. Depending on how the line is configured, some or all of the traffic
will flow onto the secondary dial-up line.
Figure 12-3 When the Primary Link Load Exceeds a Threshold, the Backup Link Comes to the Rescue by Establishing
a Second Connection to the Destination
The Primary line is at 80

percent capacity. Enable
the secondary link.
Primary
Frame Relay
Network
ISDN
Secondary Network
To configure backup if a primary line reaches or exceeds a certain threshold, perform the
following steps:
1 Select the primary interface and configure it as needed (for dial-on-demand routing,
Frame Relay interfaces, X.25, and so on):
Router(config)#interface serial 0
NOTE The backup load command can’t be configured for Frame Relay subinterfaces.
2 Use the following command on the primary interface to specify the backup to be used if
a dial backup is needed:
Router(config-if)#backup interface interface-type number
3 To set the traffic load threshold for dial backup service, use the following command
syntax, which is explained in the table that follows:
Router(config-if)#backup load {enable-threshold | never}
{disable-threshold | never}
Activating a Dial Backup to Support Primary Line Traffic 383
backup load Command Description

enable-threshold Percentage of the primary line’s available bandwidth that the
traffic load must exceed to enable dial backup.
disable-load Percentage of the primary line’s available bandwidth that the
traffic load must be less than to disable dial backup.
never Prevents the secondary line from being activated or deactivated.
Example of Dial Backup for Excessive Traffic Load

In Figure 12-4, interface serial 0 is the primary interface. From the configuration in the figure,
you can tell that if the primary interface is down for 40 seconds, the backup interface (BRI 0)
will be activated. The secondary line will deactivate 20 seconds after the primary line is
re-enabled.
NOTE The example in Figure 12-4 illustrates only the commands to enable a backup. The interface
must also be configured as needed (for DDR, Frame Relay, X.25, and so on).
Figure 12-4 Dial Backup Configuration for an Excess Load on the Primary Link
Primary
Frame Relay
Branch Office Network Central Site
S0 S0
Bri0
Bri0
ISDN
Network
Secondary
Router(config) #interface serial 0 Backup interface

disabled when the
Router(config-if) #backup interface bri 0
aggregate load falls to
Router(config-if) #backup load 60 5 within 5 percent of the
primary line’s bandwidth.
Use for backing up The BRI backup is

traffic overloads. enabled if the primary
line threshold exceeds
60 percent.
Dialer Profiles as Backup Interfaces 385
however. If Branch Office A places the physical BRI link in standby mode, it is deactivated and
does not activate until the primary line fails or reaches a specified threshold. Thus, the BRI link
cannot be used to connect to Branch Office B.
Figure 12-6 A Physical Interface Cannot Be Active and a Backup at the Same Time
Branch Office A Frame Relay

Primary Central Site
Network
S0 S0
Bri0 Secondary Bri0

ISDN
Network
DD
R
Branch Office B
Dialer Profiles as Backup Interfaces

With dialer profiles, the BRI connection in Figure 12-6 can be used to back up the primary
Frame Relay link between the Central site and branch office. At the same time, it can be
configured for DDR between Branch Office A and Branch Office B (as shown in Figure 12-7).
Configure one dialer profile to act as the backup line. This profile is in standby mode until
engaged. Configure another dialer profile for Legacy DDR between the Branch Office A and
Branch Office B sites. Make the physical BRI interface a member of both dialer pools.
Figure 12-7 Dialer Interface Can Be Used as the Backup without Deactivating the Physical Interface
Dialer Interface 1 Dialer Interface 2
Use this interface Use this interface

as the backup for another
interface. connection.
Specify this physical interface as

the interface to use in both events
by making it a member of both pools.
Physical Interface
NOTE The cost mentioned in the preceding paragraph refers to the value assigned to a link in OSPF.
This metric is based on the speed of the media.
OSPF does not support load balancing between the primary link and the backup connection. If
load balancing is to occur in this environment, each connection must be able to support
comparable bandwidth environments (a 56 Kbps serial backs up a 56 Kbps serial connection).
Load Backup with IGRP and EIGRP

If the routing protocol used is IGRP or EIGRP, or if you have a static route configured, the load
backup feature will load share between the primary and backup links after the backup link is
activated. The metric assigned to the primary link and the backup link must be the same if both
links are to be utilized, however. If one link has a lower metric than the other, all routing occurs
over the link with the lower metric, even if both lines are up. If load balancing is to occur in this
environment, each connection must be able to support comparable bandwidth environments (a
56 Kbps serial backs up a 56 Kbps serial connection).
Instead of relying on equal metrics to load share and load balance, the variance router
configuration command can also be used to control load balancing in an IGRP/EIGRP
environment. Use the variance multiplier command to configure unequal-cost load balancing
by defining the difference between the best metric and the worst acceptable metric.
Figure 12-8 shows a sample network and the configuration to create load balancing between
primary and backup lines. The table that follows covers the variance command.
CHAPTER
13
Managing Network Performance
with Queuing and Compression
This chapter covers why you may need to implement queuing technologies on your WAN
connection. It also describes how to implement the queuing technologies available from
Cisco IOS software so that you can prioritize traffic over your WAN connection. It then
explains how you can use compression to optimize WAN utilization.
Queuing Overview
A protocol-dependent switching process handles traffic that arrives at a router interface.
The switching process includes the delivery of traffic to an outgoing interface buffer. First-
in, first-out (FIFO) queuing is the classic algorithm for packet transmission. With FIFO,
transmission occurs in the same order as messages are received. Until recently, FIFO
queuing was the default for all router interfaces. If user needs require traffic to be reordered,
the department or company must establish a queuing policy, other than FIFO queuing,
which ensures that sensitive traffic goes out first (see Figure 13-1).
Figure 13-1 Reordering the Packets So Time-Sensitive Traffic is Processed First
IP
IPX IP SNA
SNA
IPX
Cisco IOS software offers three queuing options as alternatives to FIFO queuing:
• Weighted fair queuing (WFQ) prioritizes interactive traffic over file transfers to
ensure satisfactory response time for common user applications.
• Priority queuing ensures the timely delivery of a specific protocol or type of traffic
because that traffic is transmitted before all others.
• Custom queuing establishes bandwidth allocations for each different type of traffic.
Table 13-2 in the “Queuing Comparison” section, later in this chapter, offers a helpful
comparison of all of the queuing methods.
400 Chapter 13: Managing Network Performance with Queuing and Compression
The Need for Traffic Prioritization

The need to prioritize packets arises from the diverse mixture of protocols and their associated
behaviors found in today’s data networks. Different types of traffic that share a data path
through the network can affect each other.
Depending on the application and overall bandwidth, users may or may not perceive any real
performance degradation. For instance, delay-sensitive, interactive, transaction-based
applications may require a higher priority than, say, a file transfer to satisfy users. Desktop
video conferencing requires a specified amount of bandwidth to perform acceptably. If your
network is designed so that multiple protocols share a single data path between routers,
prioritization may be a requirement.
Prioritization is most effective on WAN links in which the combination of bursty traffic and
relatively lower data rates can cause temporary congestion. Depending on the average packet
size, prioritization is most effective when applied to links at T1/E1 bandwidth speeds or lower.
If there is no congestion on the WAN link, there is no reason to implement traffic prioritization.
NOTE Prioritization is most effective on bursty WAN links (T1/E1 or below) that experience
temporary congestion.
If a WAN link is constantly congested, traffic prioritization may not resolve the problem.
Adding bandwidth might be the appropriate solution.
Establishing a Queuing Policy

A queuing policy helps network managers to meet two challenges: to provide an appropriate
level of service for all users and to control expensive WAN costs.
Typically, the corporate goal is to deploy and maintain a single enterprise network, even though
the network supports disparate applications, organizations, technologies, and user expectations.
Consequently, network managers are concerned about providing all users with an appropriate
level of service, while continuing to support mission-critical applications and having the ability
to integrate new technologies at the same time.
Because the major cost of running a network is also related to WAN circuit charges, network
managers must strike the appropriate balance between the capacity and cost of these WAN
circuits, and the level of service provided to their users.
To meet these challenges, queuing allows network managers to prioritize, reserve, and manage
network resources—and to ensure the seamless integration and migration of disparate
technologies without unnecessary costs.
Queuing Overview 401
Choosing a Cisco IOS Queuing Option

Determining the best Cisco IOS queuing option for your traffic needs involves the following
general guidelines (as represented in Figure 13-2):
1 Determine whether the WAN is congested.
If traffic does not back up, there is no need to sort the traffic—it is serviced as it arrives.
However, if the offered load exceeds the transmission capacity for periods of time, then
there is an opportunity to sort the traffic with one of the Cisco IOS-queuing options.
2 Decide whether strict control over traffic prioritization is necessary and whether automatic
configuration is acceptable.
Proper queuing configuration is a nontrivial task. To effectively perform this task, the
network manager must study the types of traffic using the interface, determine how to
distinguish them, and decide their relative priority. This done, the manager must install the
filters and test their effect on the traffic. Traffic patterns change over time, so the analysis
must be repeated periodically.
3 Establish a queuing policy.
A queuing policy results from the analysis of traffic patterns and the determination of the
relative traffic priorities discussed in Step 2.
4 Determine whether any of the traffic types you identified in your traffic pattern analysis
can tolerate a delay.
Figure 13-2 Flow Chart of Queuing Options
Step 1 Step 2 Step 3 Step 4
Yes Strict Yes Yes Yes

WAN Queuing Custom
control Delay OK?
congested? policy? queuing
needed?
No No No No
No need for Determine

queuing traffic
priorities
Use weighted fair Use priority
queuing queuing
Queuing: Return Policy

For queuing to be pertinent, you should have a matching return policy; the answering router
should handle packets comparably.
First In, First Out Queuing Overview

When FIFO queuing is in effect, traffic is transmitted in the order received, without regard for
the bandwidth consumption or the associated delays (as shown in Figure 13-3). As a result, file
transfers and other high-volume network applications often generate series of packets of
associated data. These related packets are known as packet trains.
Figure 13-3 FIFO Queuing
FIFO queuing
High-volume traffic
High-volume traffic
Low-volume traffic
Low-volume traffic
Packet trains are groups of packets that tend to move together through the network, as shown
in Figure 13-3. These packet trains can consume all available bandwidth and starve out other
traffic.
Weighted Fair Queuing Overview

Weighted fair queuing is an automated method that provides fair bandwidth allocation to all
network traffic. Weighted fair queuing provides traffic-priority management that dynamically
sorts traffic into messages that make up a conversation. Weighted fair queuing then breaks up
the “train” of packets within each conversation to ensure that the bandwidth is shared fairly
between individual conversations.
Weighted Fair Queuing Overview 403
Weighted fair queuing overcomes an important limitation of FIFO queuing. Weighted fair
queuing breaks up packet trains to ensure that low-volume traffic is transferred in a timely
fashion. Weighted fair queuing gives low-volume traffic, such as Telnet sessions, priority over
high-volume traffic, such as File Transfer Protocol (FTP) sessions. Weighted fair queuing gives
concurrent file transfers balanced use of link capacity.
Fair queuing is enabled by default for physical interfaces whose bandwidth is less than or
equal to 2.048 Mbps; and that do not use Link Access Procedure, Balanced (LAPB), X.25,
compressed Point-to-Point Protocol (PPP), or Synchronous DataLink Control (SDLC)
encapsulations. Fair queuing is not an option for these protocols.
The weighted fair queuing algorithm arranges traffic into conversations. The discrimination of
traffic into conversations is based on packet header addressing.
Common conversation discriminators are the following:
• Source/destination network address
• Source/destination MAC address
• Source/destination port or socket numbers
• Frame Relay data-link connection identifier (DLCI) value
• Quality of service/type of service (QoS/ToS) value
In Figure 13-4, the weighted fair queuing algorithm has identified three conversations.
Figure 13-4 Messages Are Sorted in Conversations
Packets fair queued
High-volume traffic
Fair queue
6 4 1
3
1
E0 2
E1 4
5 2
5
E2 6
Low-volume traffic
The weighted fair queuing algorithm places packets of the various conversations in the fair
queue before transmission. The order of removal from the fair queue is determined by the
virtual delivery time of the last bit of each arriving packet. Small, low-volume packets are
given priority over large, high-volume conversation packets.
After low-volume conversations are serviced, high-volume conversations share the remaining
link capacity fairly, and interleave or alternate transmission Timeslots. In this figure, high-
volume conversation packets are queued in order of arrival after the low-volume packet.
The queuing algorithm ensures the proper amount of bandwidth for each message. With
weighted fair queuing, two equal-size file transfers get equal bandwidth, rather than the first
file transfer using most of the link’s capacity.
In Figure 13-4, packet 3 is queued before packets 1 or 2 because packet 3 is a small packet in a
low-volume conversation.
The result of the queuing order and the transmission order is that short messages, which do not
require much bandwidth, are given priority and the short messages arrive at the other end of the
link first.
As a result, packet 3 is transmitted before packets 1 or 2.
Configuring Weighted Fair Queuing

The fair-queue command enables fair queuing on an interface
Router(config-if)#fair-queue {congestive-discard-threshold}
where the congestive-discard-threshold number is the number of messages creating a

congestion threshold, after which messages for high-volume traffic will no longer be queued;
the maximum packets in a conversation held in a queue before they are discarded. Valid values
are 1 to 512, inclusive. The default is 64 messages. The fair-queue 128 command sets the
congestive discard threshold number to 128.
The congestive discard policy applies only to high-volume conversations that have more
than one message in the queue. The discard policy tries to control conversations that would
monopolize the link. If an individual conversation queue contains more messages than the
congestive discard threshold, that conversation will not have any new messages queued until
that queue’s content drops below one-fourth of the congestive-discard value.
NOTE Weighted fair queuing is used by default on serial interfaces at E1 speeds (2.048 Mbps) and
below. Weighted fair queuing is disabled on serial interfaces that use X.25 or compressed PPP.
LAN interfaces and serial lines, operating at E3 or T3 speeds, are not available for weighted fair
queuing.
Priority Queuing Overview 405
The fair-queue command enables fair queuing on an interface. In Figure 13-5, interface serial
1 is attached to a Frame Relay network and is configured to operate at a 56 Kbps link speed.
The fair-queue 128 command sets the congestive discard threshold number to 128.
Figure 13-5 Weighted Fair Queuing Example
Frame Relay
network
S1
Router (config) #interface Serial 1

Router (config-if) #encapsulation frame-relay
Router (config-if) #fair-queue 128
Router (config-if) #bandwidth 56
Appears in output
only if congestive
discard threshold
is modified.
Because conversations may not have any new messages queued until that queue’s content drops
below one-fourth of the congestive-discard value, a queue must contain fewer than 32 entries
(1/4 of 128).
Priority Queuing Overview

Priority output queuing provides a mechanism to use strict priority in selecting which packets
to send first on an interface. This technique is useful in environments in which traffic has a
hierarchy of importance, and more important traffic should not be delayed by less important
traffic.
Priority queuing categorizes and prioritizes datagrams that travel on an interface. Traffic can be
assigned to the various queues, according to protocol or Transmission Control Protocol (TCP)
port number. Priority queuing controls time-sensitive traffic (such as Digital Equipment
Corporation local-area transport) or mission-critical traffic (such as transaction processing) on
low-bandwidth serial links.
With priority queuing, the high-priority queue is always emptied before the medium-priority
queue, and so on (as shown in Figure 13-6). As a result, traffic in lower-priority queues might
not get forwarded in a timely manner or get forwarded at all. For this reason, priority queuing
provides the network administrator the most control over deciding which traffic gets forwarded.
NOTE Weighted fair queuing automatically prioritizes traffic to ensure that all traffic is given fair
access to bandwidth. Use priority queuing when you must guarantee that certain types of traffic
receive as much of the available bandwidth as needed.
An incoming packet is compared with the priority list to select a queue. If there is room, the
packet is buffered in memory and waits to be dispatched after the queue is selected. If the queue
is full, the packet is dropped. For this reason, controlling queue size is an important
configuration task.
Figure 13-6 Priority Queuing Operation
Incoming
packet HIGH No
packet?
Select Yes MEDIUM No

queue packet?
Yes NORMAL No
packet?
Queue No Place in
full? queue
Yes LOW No
packet?
Yes
Yes
Dispatch More?
packet
to WAN
Queue selection Queue service

NOTE Compare Priority Queuing to class levels on the Titanic. The first-class passengers had a much
greater chance of escaping than the passengers in steerage did. Similarly, packets in the high
queue escape the router, and the low-priority packets drown.
The queuing process empties the high-priority queue before the queuing software services
the medium-priority queue. The dispatching algorithm controls the queuing process. The
dispatching algorithm checks a queue for a packet and then dispatches it. Therefore, the high
queue must be empty before the medium queue will get any service. As a result, mission-critical
traffic in the high queue is always transmitted before traffic in other queues.
NOTE You must configure a default queue for traffic that is not identified by the priority list.
Be careful when you define the packets that belong in the high queue because these packets are
always processed first. If the high queue is always filled, packets in other queues do not have a
chance to be transmitted.
Configuring Priority Queuing

To configure priority queuing, perform the following tasks:
1 Create an output priority queuing list.
A priority list is a set of rules that describe the way packets should be assigned to priority
queues. You can establish queuing priorities based on the protocol type or on packets
entering from a specific interface. All Cisco-supported protocols are allowed.
2 Assign a default queue.
You must explicitly assign a queue for packets that were not specified in the priority list.
3 Specify the queue sizes (optional).
You can specify the maximum number of allowable packets in each queue. In general, it
is not recommended that the default queue sizes be changed.
4 Assign the priority list number to an interface.
Only one list can be assigned per interface. Once assigned, the priority list rules are
applied to all traffic that passes through the interface.
Step 1—Create an Output Priority Queuing List

You can set a priority queue, either by protocol type or by incoming interface type.
Create an output priority queuing list with the priority-list protocol command:
Router(config)#priority-list list-number protocol protocol-name
{high | medium | normal | low} queue-keyword keyword-value
priority-list protocol Command Description

list-number User-specified number from 1 to 16 that
identifies the priority list. In Cisco IOS releases
prior to 11.2, only 10 priority lists were
supported.
protocol-name Can be aarp, arp, apollo, appletalk, bridge
(transparent), clns, clns_es, clns_is,
compressedtcp, cmns, decnet, decnet_node,
decnet_router-l1, decnet_router-l2, ip, ipx, pad,
rsrb, stun, vines, xns, or x25.
queue-keyword and keyword-values represent some of the following arguments:
byte-count Can be: gt (greater than), lt (less than).

list Specifies an access-list for IP, AppleTalk, IPX,
VINES, XNS, or bridging.
tcp/udp port For IP only; can be the port number or port
name.
fragments IP packets whose fragment offset field is
nonzero are matched by this command. Note that
packets with a nonzero fragment offset do not
contain TCP or UDP headers, so other instances
of this command that use the tcp or udp keyword
will always fail to match such packets.
You can also create an output priority queuing list with the priority-list interface command.
Use this command to set queuing priorities for all traffic arriving on an incoming interface:
Router(config)#priority-list list-number interface interface-type
interface-number {high | medium | normal | low}
priority-list interface Command Description

identifies the priority list.
interface-type Specifies the name of the interface with
incoming packets.
interface-number Number of the specified interface.
WARNING Queuing is a process. Be aware that any new line is added at the bottom of the queue list.
Step 2—Assign a Default Queue

The default queue is normal. Use the priority-list default command to assign packets to a
queue if no other priority list conditions are met:
Router(config)#priority-list list-number default
{high | medium | normal | low}
Step 3—Specify the Queue Sizes (optional)

Use the optional priority-list queue-limit command to change the default maximum number
of packets in each queue:
Router(config)#priority-list list-number queue-limit
high-limit medium-limit normal-limit low-limit
priority-list queue-limit Command Description

identifies the priority list.
queue-limit Default number of datagrams.
high-limit Default of 20 datagrams.
medium-limit Default of 40 datagrams.
normal-limit Default of 60 datagrams.
low-limit Default of 80 datagrams.
Step 4—Assign the Priority List Number to an Interface

Once you define the priority list, enter interface configuration mode, and enter the priority-
group command to link a priority list to an interface:
Router(config-if)#priority-group list
Priority-group Command Description

list Arbitrary number from 1 to 16 that identifies the
priority list selected by the user.
In the configuration shown in Figure 13-7, priority-list 2 specifies the following:

• Telnet (TCP port 23) traffic is assigned to the high-priority queue.
• Traffic from source network 131.108.0.0 is assigned to the high-priority queue, as
specified by access-list 1. The list 1 argument in the second line of the configuration
specifies that access-list 1 be used to sort packets for placement in the high-priority queue.
• All traffic arriving from Ethernet interface 0 is assigned to the medium-priority queue.
• All other IP traffic is assigned to the normal-priority queue.
• All other traffic not specified in priority-list 2 is assigned to the low-priority queue.
• Queue-size limits have been changed from the default values to the following:
— 15 datagrams for the high queue
— 20 datagrams for the medium queue
— 20 datagrams for the normal queue
— 30 datagrams for the low queue
WARNING Figure 13-7 shows an example of priority queuing. It might not be the best policy for your
environment.
Figure 13-7 Priority Queuing Example
Router (config) #priority-list 2 protocol ip high tcp 23

Router (config) #priority-list 2 ip high list 1
Router (config) #priority-list 2 interface ethernet 0 medium
Router (config) #priority-list 2 protocol ip normal
Router (config) #priority-list 2 default low N
Router (config) #priority-list 2 queue-limit 15 20 20 30
!
Router (config) #access-list 1 permit 131.108.0.0.0.0.255.255
!
Router (config) #interface serial 0
Router (config-if) #priority-group 2
E0 S0
E1
Custom Queuing Overview 411
NOTE Priority list 2 is linked to interface serial 0 by the priority-group 2 command.
Custom Queuing Overview

Custom queuing lets you guarantee bandwidth for traffic by assigning queue space to each
protocol. Custom queuing eliminates a potential priority-queuing problem. When priority
queuing is used, it is possible that packets from higher-priority queues could consume all the
available interface bandwidth. As a result, packets in the lower-priority queues might not get
forwarded in a timely manner, or at all.
Custom queuing eliminates this problem. With custom queuing, you reserve a certain
percentage of bandwidth for each specified class of traffic. You can use custom queuing
to allocate bandwidth, based on a protocol or source interface.
Using custom queuing, you can use filters to assign types of traffic to one of 16 possible queues.
The router services each queue sequentially, transmitting a configurable quantity of traffic from
each queue before servicing the next queue.
As a result, one type of traffic never monopolizes the entire bandwidth. You can control the
percentage of the interface’s bandwidth that a queue consumes by configuring the number of
bytes transmitted from a queue at one time.
Custom queuing is particularly important for time-sensitive protocols, such as Systems
Network Architecture (SNA), which require predictable response time.
NOTE Queue 0 is a system queue that handles system packets such as keepalives.
Queue 0 is emptied before the other custom queues.
Custom Queuing Operation

As shown in Figure 13-8, custom queuing has two components:
• Traffic filtering—The forwarding application—such as IP, IPX, or AppleTalk—applies a
set of filters or access-list entries to each message that it forwards. The messages are
placed in queues, based on the filtering.
• Queued message forwarding—Custom queuing uses a round-robin dispatching
algorithm to forward traffic. Each queue continues to transmit packets until the configured
byte limit is reached. When this queue’s threshold is reached or the queue is empty, the
queuing software services the next queue in sequence.
Step 2—Assign a Default Custom Queue

Use the queue-list default command to assign packets to a queue if no other queue list
conditions are met:
Router(config)#queue-list list-number default queue-number
queue-list default Command Description

list-number Number of the queue list, from 1 to 16.
queue-number Number of the queue, from 1 to 16.
WARNING If no default queue is specified, default traffic is queued to queue 1.
Step 3—Use the optional queue-list queue limit Command

To limit the length of a particular queue, use the optional queue-list queue limit command:
Router(config)# queue-list list-number queue queue-number
limit limit-number
queue-list queue limit Command Description

limit-number Maximum number of packets in a queue at any
time. Range is 0 to 32,767 entries; default is 20.
Step 4—Configure the Service Threshold Per Queue

Use the queue-list queue byte-count command to set the minimum byte count transferred
from a given queue at a time. This value is specified on a per-queue basis:
Router(config)#queue-list list-number queue queue-number
byte-count byte-count-number
queue-list queue byte-count Command Description

byte-count-number Specifies the minimum number of bytes that the
system allows to be delivered from a given queue
during a particular cycle. The default is 1500
bytes.
Custom Queuing Overview 415
NOTE Because the router will not split a packet for the purpose of queuing, if a queue threshold (the
maximum byte count) is reached during the transmission of a packet, the whole packet is still
allowed to go through.
For example, the default threshold of 1500 bytes is used on a given queue. The first packet
assigned to that queue is 1100 bytes, and the second packet is 300 bytes. The threshold has not
been reached yet because the byte count is currently at 1400 bytes. The next packet assigned to
the same queue is therefore processed, regardless of its size. If the third packet is 1000 bytes,
the whole packet is processed for a total byte count of 2400 bytes. The fourth packet will be put
on hold while the router services the subsequent queues.
Step 5—Assign the Custom Queue List to an Interface

Use the custom-queue-list command to link a queue list to an interface:
Router(config)#custom-queue-list list
custom-queue-list Command Description

list Number of the queue list (from 1 to 16) made
available to control the interface’s available
bandwidth.
Custom Queuing Example

Figure 13-9 illustrates the following important custom-queuing features:
• FTP traffic (TCP port 20) is assigned to queue 1. The queue-list 1 protocol ip 1 tcp 20
command designates FTP data traffic by identifying TCP port 20.
• Non-FTP IP traffic is assigned to queue 2.
• IPX traffic is assigned to queue 3.
• AppleTalk traffic is assigned to queue 4.
• All other traffic is assigned to queue 5.
• FTP traffic receives more bandwidth.
The queue-list 1 queue 1 byte-count 4500 command allocates 4500 bytes to queue 1. This
command increases the transfer capacity of queue 1 from the default of 1500 bytes to 4500
bytes. As a result, FTP traffic is allocated more bandwidth than any other type of traffic.
Queuing Comparison 417
In Example 13-1, there are two active conversations (117 and 155) on interface Serial 0.
You can also use the show interfaces command, displayed in Example 13-2, to display queuing
information for the router’s interfaces.
Use the show queuing custom command to display custom queue information, as shown in
Example 13-2.
Example 13-2 The show queueing custom Command Displays Information on the Queue
Router#show queueing custom
Current custom queue configuration:
List Queue Args
3 5 default
3 1 interface Serial 3
3 3 protocol ip
3 3 byte-count 1518
In Example 13-2, custom queue list 3 information is displayed. Table 13-1 explains this output.
Table 13-1 show queueing custom Command Output

Queue Arguments Description
5 default Defines the default queue. 1 interface Serial 3.
All traffic for interface Serial 3 is sent to queue 1.
3 protocol ip IP traffic is sent to queue 3.
3 byte-count 1518 Specifies the minimum number of bytes
delivered from queue 3 during a single cycle.
You can use the show queueing priority command to display priority queuing information.
You can use the show queueing fair command to display weighted fair queuing information.
Queuing Comparison
Table 13-2 provides a summary of the differences between WFQ, priority queuing, and custom
queuing.
Table 13-2 Comparison Between Different Queuing Methods
Weighted Fair Queuing Priority Queuing Custom Queuing
No queue lists 4 queues 16 queues
Low volume given priority High priority queue serviced Round-robin service
first
Conversation dispatching Packet dispatching Threshold dispatching
continues
Compression Overview 419
• Microsoft Point-to-Point Compression (MPPC)

• Other compression considerations mentioned in the following note.
Figure 13-10 Compression Allows More Efficient Use of Bandwidth
Payload
compression
PPP, HDLC,
X.25, Frame Data
IP/TCP header
Relay, or ATM
header
Header
compression
Link
compression
The default method of transmitting data across a serial link is the uncompressed format. This
allows headers to be used in the normal switching operation, but can consume more bandwidth
than desired.
NOTE Cisco 3600 series routers now support a compression port module that provides high-
performance, hardware-based data compression using simultaneous Stacker compression
algorithms. Independent, full-duplex compression and decompression capabilities are used on
Point-to-Point (PPP) encapsulated packets.
The data compression AIM provides hardware-based compression and decompression of
packet data transmitted and received on the serial network interfaces of the Cisco 2600 series
router without occupying the Port Module Slot, which might otherwise be used for additional
customer network ports. Supported are the industry standard Limpel Zif Stac (LZS) and
Microsoft point-to-point compression (MPPC) algorithms over Point-to-Point Protocol (PPP)
or Frame Relay. High-level Data Link Control (HDLC) is not supported. The Data
Compression AIM requires Cisco IOS Release 12.0(1)T or later.
The data compression AIM provides a cost-effective, hardware-based compression that yields
a higher level of performance than that available from the main chassis CPU running the Cisco
IOS compression feature. The data compression AIM series cards provide enhanced versatility,
network peripheral integration, and performance for the Cisco 2600 series routers. The data
compression AIM delivers higher levels of WAN bandwidth optimization by supporting
compression ratios of up to 4:1 with 8 Mbps throughput.
Configuring Data Compression

Use the compress [predictor|stac|mppc] command to configure point-to-point software
compression for a LAPB, PPP, or HDLC link. Data-compression schemes used in
internetworking devices are referred to as lossless compression algorithms. These schemes
reproduce the original bit streams exactly, with no degradation or loss, which is a feature
required by routers and other devices to transport data across the network:
Router(config-if)#compress [predictor|stac|mppc]
Use the frame-relay payload-compress command to enable STAC compression on a specified

Frame Relay point-to-point interface or subinterface:
Router(config-if)#frame-relay payload-compress
Use the x25 map compressdtcp command to map compressed TCP headers to an X.121
address for a given link.
Use the ip tcp header-compression command to enable TCP header compression. The passive
keyword compresses outgoing TCP packets, only if incoming TCP packets on the same
interface are compressed. If passive is not specified, the router will compress all traffic:
Router(config-if)#ip tcp header-compression [passive]
WARNING Never recompress data. Remember that compressed data does not compress; it expands.
Summary
In this chapter, you learned why queuing is necessary, how to identify alternative queuing
protocols, and how to determine the best queuing method that should be implemented.
You also learned how to configure weighted fair, priority, and custom queuing on your network
interfaces; and how to verify proper queuing configuration, troubleshoot incorrect
configurations, and enable data compression.
In the next chapter, you will embark in a new section of this book, which covers scaling and
troubleshooting your remote access network.
Case Study—Managing Network Performance with

Queuing and Compression
Complete the tasks of this case study, and then review the case study solution section that
follows to see how you did and where you might need to review the concepts presented in this
chapter.
In this case study, you have to solve a congestion problem by implementing queuing.
434 Chapter 14: Scaling IP Addresses with Network Address Translation
NOTE The inside local and inside global IP address schemes that are used in this chapter are reserved
and not to be used in the public network. The figures and examples in this chapter use a 10.0.0.0
network to illustrate inside local addresses and the 192.168.0.0 network to represent inside
global addresses.
NAT Overview and Terminology

IP address depletion is a key problem facing the public network. To maximize the use of your
registered IP addresses, Cisco IOS Release 11.2 software and subsequent releases implement
NAT. This feature, which is Cisco’s implementation of RFC 1631 (the IP Network Address
Translator), is a solution that provides a way to use the same IP addresses in multiple internal
subnetworks, thereby reducing the need for registered IP addresses.
The NAT functionality allows privately addressed networks to connect to public networks such
as the Internet. The privately addressed “inside” network sends a packet through the NAT
router; the addresses are converted to legal, registered IP addresses, which enables the packets
to be passed to the public networks, such as the Internet. These features were formerly available
only through pass-through firewall gateways. This functionality is now available in all Cisco
enterprise routers.
NAT terminology is defined in Table 14-1 and is represented in Figure 14-2.
Figure 14-2 NAT Terminology
Outside
Inside
B DA
DA
192.168.2.2 Host B
10.1.1.1 SA
172.20.7.3
10.1.1.2 192.168.2.2 C
Internet
SA
10.1.1.1 A
10.1.1.1
Simple NAT Table D
Inside Local Inside Global Outside Global

IP Address IP Address IP Address
A B C
10.1.1.2 192.168.2.3
10.1.1.1 192.168.2.2 172.20.7.3
NAT Overview and Terminology 435
Table 14-1 Cisco’s implementation of NAT uses the following terms related to NAT.
Term Definition
Inside local IP The IP address assigned to a host on the inside network. The address was
address globally unique but obsolete, allocated from RFC 1918, Address Allocation
for Private Internet Space, or randomly picked.
Inside global IP A legitimate IP address (assigned by the NIC or service provider) that
address represents one or more inside local IP addresses to the outside world. The
address was allocated from a globally unique address space, typically
provided by the Internet Service Provider (ISP).
Outside global IP The IP address that was assigned to a host on the outside network by its
address owner. The address was allocated from a globally routable address space.
Outside local IP The IP address of an outside host, as it appears to the inside network. The
address address was allocated from address space routable on the inside, or possibly
allocated from RFC 1918, for example.
Simple translation A translation entry that maps one IP address to another.
entry
Extended translation A translation entry that maps one IP address and port pair to another address
entry port pair.
NAT technology enables private IP internetworks that use nonregistered IP addresses to connect
to the public network, as shown in Figure 14-3. A NAT router is placed on the border of a stub
domain (inside network) and a public network (outside network), and translates the internal
local addresses into globally unique IP addresses before sending packets to the outside network.
NAT takes advantage of the fact that relatively few hosts in a stub domain communicate outside
of the domain at any given time. Therefore, only a subset of the IP addresses in a stub domain
must be translated into globally unique IP addresses for outside communication.
Figure 14-3 Network Using NAT to Connect to the Internet
Inside Outside
SA SA
10.1.1.1 192.168.2.2
10.1.1.1
Internet
NAT
border
router
10.1.1.2
If your internal addresses must change because you changed service providers or because two
intranets merged (two companies merged, for example), NAT can be used to translate the
appropriate addresses. NAT enables you to change the addresses incrementally, without
changing to hosts or routers except for those bordering stub domains. This eliminates duplicate
address ranges without readdressing host computers.
The translation performed by using NAT can be either static or dynamic. Static translation
occurs when you specifically configure addresses in a lookup table. A specific inside address
maps into a prespecified outside address. The inside and outside addresses are statically mapped
one-for-one. Dynamic translation occurs when the NAT border router is configured to
understand which inside addresses must be translated, and which pool of addresses may be used
for the outside addresses. There can be multiple pools of outside addresses. Multiple internal
hosts can also share a single outside IP address, which conserves address space. Address
sharing is accomplished by port multiplexing, or changing the source port on the outbound
packet so that replies can be directed back to the appropriate router.
For load sharing, you can map outside IP addresses to inside IP addresses by using the
Transmission Control Protocol (TCP) load distribution feature. Load distribution can also be
accomplished by using NAT where one external address maps to this address. Then, the round-
robin between inside machines occurs. In this case, incoming new connections are distributed
across several machines. Each connection may state information that a given connection must
remain on one server.
NOTE Use NAT if the following is true:

• You need to connect to the Internet and your hosts do not have globally unique IP
addresses.
• You change over to a new ISP that requires you to renumber your network.
• Two intranets with duplicate addresses merge.
• You want to support basic load sharing.
NAT Implementation Considerations

Before implementing NAT, you should evaluate the following considerations.
Typical NAT advantages are as follow:
• NAT conserves the legally registered addressing scheme by allowing the privatization of
intranets, yet it allows legal addressing scheme pools to be set up to gain access to the
Internet.
NAT Operation 437
• NAT also reduces the instances in which addressing schemes overlap. If a scheme was
originally set up within a private network, the network was connected to the public
network (which may use the same addressing scheme). Without address translation, the
potential for overlap exists globally.
• NAT increases the flexibility of connection to the public network. Multiple pools, backup
pools, and load sharing/balancing pools can be implemented to help ensure reliable public
network connections. Network design is also simplified because planners have more
flexibility when creating an address plan.
• Deprivatization of a network requires the renumbering of the existing network; the costs
can be associated with the number of hosts that require conversion to the new addressing
scheme. NAT allows the existing scheme to remain, and it still supports the new assigned
addressing scheme outside the private network.
Typical NAT disadvantages are as follows:
• NAT increases delay. Switching path delays, of course, are introduced because of the
translation of each IP address within the packet headers. Performance may be a
consideration because NAT is currently done by using process switching. The CPU must
look at every packet to decide whether it has to translate it, and then alter the IP header—
and possibly the TCP header. It is not likely that this process will be easily cacheable.
• One significant disadvantage, when implementing and using NAT, is the loss of end-to-
end IP traceability. It becomes much harder to trace packets that undergo numerous packet
address changes over multiple NAT hops. This scenario does, however, lead to more
secure links because hackers who want to determine a packet’s source will find it difficult,
if not impossible, to trace or obtain the origination source or destination address.
• NAT also forces some applications that use IP addressing to stop functioning because it
hides end-to-end IP addresses. Applications that use physical addresses instead of a
qualified domain name will not reach destinations that are translated across the NAT
router. Sometimes, this problem can be avoided by implementing static NAT mappings.
NAT Operation
NAT can be used to perform several functions. This section describes in detail the operation of
the following NAT functions:
• Translating inside local addresses—Establishes a mapping between inside local and
global addresses.
• Overloading inside global addresses—You can conserve addresses in the inside global
address pool by allowing source ports in TCP connections or User Datagram Protocol
(UDP) conversations to be translated. When different inside local addresses map to the
same inside global address, each inside host’s TCP or UDP port numbers are used to
distinguish between them.
• TCP load distribution—A dynamic form of destination translation can be configured for
some outside-to-inside traffic. When a mapping scheme is established, destination
addresses that match an access-list are replaced with an address from a rotary pool.
Allocation is done on a round-robin basis, and is done only when a new connection is
opened from the outside to the inside. All non-TCP traffic is passed untranslated (unless
other translations are in effect).
• Handling overlapping networks—NAT can be used to resolve addressing issues that
arise when inside addresses overlap with addresses in the outside network. This can occur
when two companies merge, both with duplicate addresses in the networks. It can also
occur if you switch ISPs and the address you were assigned by your old ISP is reassigned
to another client.
NOTE NAT functions:

• Translation Inside Local addresses
• Overloading Inside Global Addresses
• TCP Load Distribution

• Handling Overlapping Networks
Traffic Types Supported in Cisco IOS NAT

The following traffic types are supported by Cisco IOS NAT:
• Any TCP/UDP traffic that does not carry source and/or destination IP addresses in the
application data stream
• HTTP
• TFTP
• Telnet
• Archie
• finger
• NTP
• NFS
• rlogin, rsh, rcp
NAT Operation 439
Although the following traffic types carry IP addresses in the application data stream, they are
supported by Cisco IOS NAT:
• IMCP
• FTP (including PORT and PASV commands)
• NetBIOS over TCP/IP (datagram, name, and session services)
• Progressive Networks’ RealAudio
• White Pines’ CuSeeMe
• Xing Technologies’ Streamworks
• DNS “A” and “PTR” queries
• H.323/NetMeeting [12.0(1)/12.0(1)T and later]
• VDOLive [11.3(4)11.3(4)T and later]
• Vxtreme [11.3(4)11.3(4)T and later]
• IP Multicast [12.0(1)T] (source address translation only)
The following traffic types are not supported by Cisco IOS NAT:
• Routing table updates
• DNS zone transfers
• BOOTP
• talk, ntalk
• SNMP
• NetShow
The source for the Cisco NAT support information is the Cisco IOS Network Address
Translation (NAT) Packaging Update, found at www.cisco.com.
Translating Inside Local Addresses

Figure 14-4 illustrates NAT operation when it is used to translate addresses from inside your
network to destinations outside of your network.
NAT Operation 441
Overloading Inside Global Addresses

Figure 14-5 illustrates NAT operation when a single inside global address can be used to
represent multiple inside local addresses simultaneously. In this example, an extended
translation entry table is used. In the table, the combination of address and port makes each
global IP address unique. The use of ports to make an address unique is actually Port Address
Translation (PAT), which is a subset of NAT.
Figure 14-5 Overloading Addresses
Inside
4
DA
192.168.2.2 Host B
5 3 172.20.7.3
10.1.1.3
DA SA
10.1.1.1 192.168.2.2 4
Internet DA
192.168.2.2
10.1.1.2 1
SA Host C
172.21.7.3
10.1.1.1
2 NAT Table
10.1.1.1 Protocol Inside Local IP Inside Global IP Outside Global

10.1.1.1 Address: Port Address: Port IP Address: Port
TCP 10.1.1.3:1492 192.168.2.2:1492 172.21.7.3:23
TCP 10.1.1.2:1723 192.168.2.2:1723 172.21.7.3:23
TCP 10.1.1.1:1024 192.168.2.2:1024 172.20.7.3:23
The steps in the following list correspond to the numbered NAT operation steps in Figure 14-5:
1 User at Host 10.1.1.1 opens a connection to Host B.
2 The first packet that the router receives from 10.1.1.1 causes the router to check its NAT
table.
If no translation is found, the router determines that address 10.1.1.1 must
be translated. The router allocates a new address and sets up a translation of the inside
local address 10.1.1.1 to a legal global address. If overloading is enabled and another
translation is active, the router will reuse the global address from that translation and save
enough information to be able to distinguish it from the other translation entry. This type
of entry is called an extended entry.
3 The router replaces 10.1.1.1’s inside local IP address with the selected inside global
address, 192.168.2.2, and forwards the packet.
4 Outside Host B receives the packet and responds to that node using the inside global IP
address 192.168.2.2.
5 When the router receives the packet with the inside global IP address, the router performs
a NAT table lookup using the inside global address and port number, and the outside
address and port number as the references. The router then translates the address to
10.1.1.1’s inside local address and forwards the packet to 10.1.1.1. Host 10.1.1.1 receives
the packet and continues the conversation. For each packet, the router performs Step 2
through Step 5.
TCP Load Distribution

Figure 14-6 illustrates NAT operation when NAT is used to map one virtual host to several real
hosts.
Figure 14-6 TCP Load Distribution
Inside
3
DA
10.1.1.1 1
10.1.1.1 DA
4
5 10.1.1.127 Host B
Real SA 172.20.7.3
hosts SA
10.1.1.1
10.1.1.127
10.1.1.2 Internet
Host C
172.21.7.3
10.1.1.3 2 NAT Table
Protocol Inside Local IP Inside Global IP Outside Global

Virtual 10.1.1.1 Address: Port Address: Port IP Address: Port
hosts
TCP 10.1.1.1:80 10.1.1.127:80 172.20.7.3:3058
TCP 10.1.1.2:80 10.1.1.127:80 172.21.7.3:4371
10.1.1.127 TCP 10.1.1.3:80 10.1.1.127:80 172.20.7.3:3062
The steps in the following list correspond to the numbered NAT operation steps shown in
Figure 14-6:
1 User on Host B (172.20.7.3) opens a TCP connection to the virtual host at 10.1.1.127.
2 The router receives the connection request and creates a new translation allocating the
next real host (10.1.1.1) for the inside local IP address.
Dynamic NAT Configuration

To enable dynamic local IP address translation, perform the following steps:
1 At a minimum, IP routing and appropriate IP addresses must be configured on the router.
2 Define a standard IP access-list for the inside network by using the access-list access-list-
number {permit | deny} local-ip-address command.
3 Define an IP NAT pool for the inside network by using the ip nat pool pool-name start-
ip end-ip {netmask netmask | prefix-length prefix-length} [type rotary] command,
which is explained in Table 14-3.
Table 14-3 ip nat pool Command
ip nat pool Command Description
pool-name Name of the pool.
start-ip Starting IP address that defines the range of addresses in the
address pool.
end-ip Ending IP address that defines the range of addresses in the
address pool.
netmask netmask Network mask that indicates which address bits belong to the
network and subnetwork fields, and which bits belong to the
host field. Specify the netmask of the network to which the
pool address belongs.
prefix-length prefix-length Number that indicates how many bits of the netmask are
ones (how many bits of the address indicate the network).
Specify the netmask of the network to which the pool
addresses belong.
type rotary (Optional) Indicates that the range of addresses in the
address pool identifies real inside hosts, among which TCP
load distribution will occur.
1 Map the access-list to the IP NAT pool by using the ip nat inside source list access-list-
number pool name command.
2 Enable NAT on at least one inside and one outside interface with the ip nat {inside |
outside} command.
Only packets moving between inside and outside interfaces can be translated. For example, if
a packet is received on an inside interface but is not destined for an outside interface, it will not
be translated.
Example 14-2 shows a sample dynamic NAT configuration.
Verifying and Troubleshooting NAT 451
Example 14-5 NAT Configuration with Overlapping Addresses

ip nat pool net-2 192.2.2.1 192.2.2.254 prefix-length 24
ip nat pool net-10 10.0.1.1 10.0.1.254 prefix-length 24
ip nat outside source list 1 pool net-2
ip nat inside source list 1 pool net-10
!
interface Serial0
ip address 171.69.232.182 255.255.255.240
ip nat outside
!
interface Ethernet0
ip address 10.1.1.254 255.255.255.0
ip nat inside
!
access-list 1 permit 10.1.1.0 0.0.0.255
Verifying and Troubleshooting NAT

This section discusses NAT verification commands on a Cisco IOS router. You can display
translation information and clear address translation entries from the NAT translation with the
commands covered in this section.
Verifying NAT
The show ip nat translations command can be used to verify the active translations. The screen
output in Example 14-6 shows a basic translation.
Example 14-6 show ip nat translation Display
Router#show ip nat translation
Pro Inside global Inside local Outside local Outside global
--- 192.2.2.1 10.1.1.1 --- ---
--- 192.2.2.2 10.1.1.2 --- ---
Router#
Example 14-7 is a sample of NAT with overloading. Two different inside hosts appear on the
outside with a single IP address, both for a telnet session—destination TCP port 23. Unique
source TCP port numbers are used to distinguish between hosts.
Example 14-7 show ip nat translation Display with Address Overloading
Router#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
tcp 192.168.2.1:11003 10.1.1.1:11003 172.16.2.2:23 172.16.2.2:23
tcp 192.168.2.1:1067 10.1.1.1:1067 172.16.2.3:23 172.16.2.3:23
NOTE If NAT is properly configured but translations are not occurring, clear the NAT translations and
check if the translations occur.
Configuring and Troubleshooting PAT On the 700 Router

PAT, a subset of NAT, is the only address-translation feature in the Cisco 700 series routers. If
you wish to enable address translation on a 700 series router, use PAT.
Cisco 700 series routers with Release 4.0 software support PAT. PAT enables local hosts on a
private IP network to communicate over a public network such as the Internet. All traffic that is
designated to an external address will have its source IP address and source port number
translated before the packet is forwarded over the public network. IP packets returning to the
private network will have their IP addresses translated back to private IP addresses.
PAT conserves network address space by enabling a single IP address to be assigned to an entire
LAN. All WAN traffic is mapped to a single node—the Integrated Services Digital Network
(ISDN)-side IP address of the Cisco 700 series router, as shown in Figure 14-12.
Figure 14-12 PAT performed On a Cisco 700 series
Private network
10.1.1.1
10.1.1.1 192.168.2.2
Internet
192.168.2.2
10.1.1.2
All traffic on the public network appears to come from the Cisco 700, making the remote LAN
invisible to the outside world.
NOTE The advantage of using PAT on a Cisco 700 series router is that it enables hosts on private
networks to communicate over public networks and it conserves IP addresses.
Configuring and Troubleshooting PAT On the 700 Router 455
PAT Porthandler Operation

If users need to access a specific remote server on the private network, PAT allows packets with
a specific well-known port number to get through (for example, File Transfer Protocol (FTP) or
Telnet), as shown in Figure 14-13. Only one server of each type (FTP, Telnet, and so on) can be
on the remote LAN. Use a static address for the remote servers so they can be found. You can
set a static host route at the Central site to get to the remote server. On a Cisco 700 running PAT,
either a static or dynamic address can be used.
Figure 14-13 Only Packets Destined for the Server (By Type) Are Allowed Through
FTP server
Incom
ing FT
P
10.0.0.108
Telephone
company
Cisco 700 Access
router
Configuring PAT
Use this complete configuration on the remote Cisco 700 series router to enable IP unnumbered
across the WAN, Dynamic Host Configuration Protocol (DHCP) server functionality, and PAT
to a Cisco router. The Set IP PAT ON and SEt IP PAT POrt FTP 10.0.0.108 commands (bold
in Example 14-10) enable PAT and set up the porthandler functionality for the remote site
shown in Figure 14-14. This configuration works for Cisco 700 Release 4.1 or later.
Figure 14-14 PAT configured on the remote LAN
NT server
FTP server mydomain
DHCP server
192.168.2.2 192.168.2.1
10.0.0.108
ISDN
10.0.0.1
7xx
Cisco 1
DHCP client
10.0.0.2
Example 14-10 Cisco 700 PAT Porthandler Configuration

>cd Internal
Internal>SEt IP 10.0.0.1
>SEt SYStem 7xx
>7xx>SEt User Cisco1
>7xx:Cisco1>Set IP PAT ON (must be configured before the set ip pat port command)
7xx:Cisco1>cd
7xx>SEt PPp AUthentication CHAp
7xx>SEt PPp SEcret CLient
7xx>SEt DHcp SERver
7xx>SEt DHcp DNS PRImary 192.168.2.2
7xx>SEt DHcp WINS PRImary 198.168.2.2
7xx>SEt DHcp DOmain mydomain
7xx> SEt IP PAT POrt FTP 10.0.0.108 (set ip pat port default, allows all services)
7xx>SEt USer Cisco1
7xx:Cisco1> SEt BRidging OFf
7xx:Cisco1> SEt IP ROUTING ON
7xx:Cisco1> SEt IP ROUTE DEstination 0.0.0.0 GAteway 0.0.0.0
7xx:Cisco1>SEt Number 5558899
7xx:Cisco1>SEt PPp Secret Host
7xx:Cisco1>SEt Active
Cisco 700—PAT and DHCP Relay Agent

A configuration in which PAT is on and DHCP relay is enabled is not valid. DHCP relay
attempts to cross from a public to a private domain. PAT prevents access to the private domain.
DHCP relay fails because it must reference the router’s private address. Cisco 700 DHCP relay
is covered in Chapter 9, “Configuring a Cisco 700 Series Router.”
Monitoring PAT
Use the show ip pat command to display PAT statistics and the currently active translated
sessions. Notice, in the Example 14-11 screen output, that TCP port 21 for the FTP service is
being handled by the FTP server 10.0.0.108.
Example 14-11 The show ip nat Command on a Cisco 700
7xx:Cisco1>show ip pat
Dropped - icmp 0, udp 0, tcp 0, map 0, frag 0
Timeout - udp 5 minutes, tcp 30 minutes
Port handlers [no default]:
Port Handler Service
-------------------------------------
21 10.0.0.108 FTP
23 Router TELNET
67 Router DHCP Server
68 Router DHCP Client
69 Router TFTP
CHAPTER
15
Using AAA to Scale Access
Control in an Expanding Network
In the previous chapters, you learned how to configure your Cisco routers to provide remote
access to users. Controlling access is a major concern of remote access networks.
This chapter describes the access-control features of Cisco Secure and the operation of a
Cisco Secure server. It also describes how to configure a router to access a preconfigured
Cisco Secure server; and how to use authentication, authorization, and accounting (AAA),
as shown in Figure 15-1.
Figure 15-1 The AAA Server Authenticates Users
Async
Central site
Multilink PPP, CHAP, DDR, PAT, DHCP
LAN dial-up
BRI Analog host-
AAA server
nc
PRI Frame Relay

sy
,A
ISDN/analog
AT
Windows 95 PC Modem Async

N
r,
DD
P,
Small office
HA
C
P,
Frame Relay
PP
BRI
nk
service
tili
ul
M
Frame Relay
Branch office
Overview of Cisco Access Control Solutions

As shown in Figure 15-2, Cisco provides the following security solutions:
• Clients The dial clients can utilize CiscoRemote or token cards as a secure means
for dial-up. Token cards such as SDI, Enigma, and CryptoCards are supported.
464 Chapter 15: Using AAA to Scale Access Control in an Expanding Network
• Client protocols Cisco IOS software supports Point-to-Point Protocol (PPP), Challenge
Handshake Authentication Protocol (CHAP), Password Authentication Protocol (PAP),
and MS-CHAP protocols for dial-up security. We recommend using PPP with CHAP
authentication. If Remote Access Dial-In User Service (RADIUS) or token cards were
implemented, the requirement would be PAP.
• Access servers Cisco IOS software supports the following protocols to provide a secure
means for dial-up: dialer profiles, access control list, per-user access control lists, lock and
key, Layer 2 Forwarding Protocol (L2F), and Kerberos V.
• Central site protocols For security verification between the network access server and
the network security server, the network access server supports Terminal Access
Controller Access System plus (TACACS+), RADIUS, and Kerberos V protocols.
• Security servers Cisco Secure is the umbrella under which Cisco has a variety of
security server solutions. Cisco Secure UNIX and Cisco Secure NT provide your network
with AAA capabilities. Cisco offers both the PIX Firewall and the Centuri Firewall for the
Cisco Secure NT platform.
Figure 15-2 Overview of Cisco Security Solutions
Internet
Corporate/ Enterprise
resources PIX firewall
Security
server
GUI
admin
ISDN
PSTN
Access server Security server
Protocol(s) Protocol(s)
Client(s)
Protocol(s) Access server(s) Security server(s)

Client(s)
PPP Cisco IOSTM
Protocol(s) CiscoSecure (AAA)
Token cards
CHAP Dialer profiles TACACS+ Token card vendors
PAP ACL, NAT RADIUS Freeware
MS-CHAP Per-user ACL Kerberos V Accounting/billing
Lock and Key Firewalls
L2F, L2TP
Kerberos V
Understanding AAA 467
can log in to the Cisco Secure ACS database, change your password for the Cisco Secure ACS
database, and perform Cisco Secure ACS system administrator tasks, such as adding or deleting
user and group profiles, and assigning attributes and permissions.
The Cisco Secure ACS stores these profiles for each network user in its RDBMS, which
contains AAA information.
The GUI client for Cisco Secure must have Java and JavaScript enabled.
Understanding AAA
Configuring the Cisco Secure server is the first part of a two-part process to develop an
operational access-control system. The second involves configuring the network access server
so that it functions properly with the Cisco Secure server. These steps are critical and must be
completed with extreme precision. Failure to configure the network access server properly may
result in being locked out of the router.
The three parts of AAA are defined as follows:
• Authentication Authentication determines the identity of users and whether they
should be allowed access to the network. Authentication allows network managers to bar
intruders from their networks.
• Authorization Authorization allows network managers to limit the network services
available to each user. Authorization also helps to restrict the exposure of the internal
network to outside callers. Authorization allows mobile users to connect to the closest
local connection and still have the same access privileges, if they were directly connected
to their local networks. You can also use authorization to specify which commands a new
system administrator can issue on specific network devices.
• Accounting System administrators might need to bill departments or customers for
connection time or resources used on the network (for example, bytes transferred).
Accounting tracks this kind of information. You can also use the accounting syslog to
track suspicious connection attempts into the network and trace malicious activity.
Router Access Modes

Understanding router access modes is the key to understanding the AAA commands and how
they work to secure your network access server.
With the exception of the aaa accounting system command, all of the AAA commands apply
to either character mode or packet mode. Table 15-1 can help you decode the meaning of an
AAA command by associating the AAA command element with the connection mode to the
router.
Table 15-1 Router Access Modes
Modes Router ports AAA command element
Character mode (line mode tty, vty, aux, con login, exec, nasi connection, arap,
or interactive login) enable, command
Packet mode (interface mode async, group-async BRI, ppp, network, arap
or link protocol session) PRI, serial, dialer profiles,
dialer rotaries
Primary applications for the Cisco Secure ACS include securing dial-up access to a network and
securing the management of routers within a network. Both applications have unique
authentication, authorization, and accounting requirements. With the Cisco Secure ACS,
system administrators can select a variety of authentication methods to provide a set of
authorization privileges. These router ports need to be secured by using the Cisco IOS software
and a Cisco Secure server.
NOTE The AppleTalk Remote Access Protocol (ARAP) is an exception. ARAP behaves as both a
character mode and packet mode connection. For example, ARAP authentication takes place in
character mode, whereas ARAP access-lists apply to packet mode.
Configuring AAA
The first steps in configuring the network access server are to globally enable AAA, specify the
Cisco Secure server that will provide AAA services for the network access server, and configure
the encryption key that is used to encrypt the data transfer between the network access server
and the Cisco Secure server.
Enabling AAA and Identifying the Server

To activate TACACS+, use the tacacs-server key command:
Router(config)#aaa new-model
Router(config)#tacacs-server host 192.168.229.76 single-connection
Router(config)#tacacs-server key shared1
To activate RADIUS, use the radius-server key command:

Router(config)#aaa new-model
Router(config)#radius-server host 192.168.229.76
Router(config)#radius-server key shared1
Configuring AAA 469
Table 15-2 explains the elements of the preceding configurations.

Table 15-2 AAA Activation Commands
Command Description
aaa new-model Enables AAA on the router.
tacacs-server host ip address single- Indicates both the address of the Cisco Secure server and the
connection desire to use the TCP single-connection feature of Cisco
Secure. This feature improves performance by maintaining a
single TCP connection for the life of the session between the
network access server and the Cisco Secure server, rather
than opening and closing TCP connections for each session
(the default).
tacacs-server key key Establishes the shared secret encryption key between the
network access server and the Cisco Secure server.
radius-server host ip address Specifies a RADIUS AAA server.
radius-server key key Specifies an encryption key to be used with the RADIUS
AAA server.
AAA Authentication Commands

The aaa authentication command, in global configuration mode, is the basic command to
enable the AAA authentication process. Many precise authentication commands derive from
aaa authentication, such as the following:
• aaa authentication arap
• aaa authentication enable default
• aaa authentication local-override
• aaa authentication login
• aaa authentication nasi
• aaa authentication password-prompt
• aaa authentication ppp
• aaa authentication username-prompt
The following are some frequent command combinations used for authentication.
aaa authentication login Command

You can configure AAA authentication for users wishing to access the EXEC prompt. The aaa
authentication login global configuration command is used for AAA authentication in this
case (Table 15-3 covers this command):
Router(config)#aaa authentication login {default | list-name} method1

➥[...[method4]]
Table 15-3 aaa authentication login Command
Command Description
default Uses the listed authentication methods that follow this argument as the
default list of methods when a user logs in.
list-name Character string used to name the following list of authentication
methods that are activated when a user logs in.
method At least one (and up to four) of the keywords.
NOTE On the console, login will succeed without any authentication checks if default is not set.
To create a default list that is used if no list is assigned to a line, use the authentication login
command with the default argument, followed by the methods you want to use in default
situations.
The additional methods of authentication are used only if the previous method returns an error,
not if it fails. To ensure that the authentication succeeds, even if all methods return an error,
specify none as the final method in the command line.
If authentication is not specifically set for a line, the default is to deny access and no
authentication is performed. The keywords for the aaa authentication login methods are
covered in Table 15-4.
Table 15-4 aaa authentication login Methods
Keyword Description
enable Uses the enable password for authentication.
krb5 Uses Kerberos 5 for authentication.
line Uses the line password for authentication.
local Uses the local username database for authentication.
none Uses no authentication.
radius Uses RADIUS authentication.
tacacs+ Uses TACACS+ authentication.
krb5-telnet Uses Kerberos 5 Telnet authentication protocol when using Telnet to
connect to the router.
Configuring AAA 471
For example, the following creates an AAA authentication list called MIS-access. This
authentication first tries to contact a TACACS+ server. If no server is found, TACACS+ returns
an error and AAA tries to use the enable password. If this attempt also returns an error (because
no enable password is configured on the server), the user is allowed access with no
authentication:
Router(config)#aaa authentication login MIS-access tacacs+ enable none
aaa authentication enable default Command

You can configure AAA authentication to determine whether a user can access the privileged
command level. The aaa authentication enable default global configuration command is used
for AAA authentication in this case:
Router(config)#aaa authentication enable default method1 [...[method4]]
If a default authentication routine is not set for a function, the default is none and no
authentication is performed.
On the console, the enable password is used if it exists. If no password is set, the process will
succeed anyway. The keywords for the aaa authentication enable default methods are
covered in Table 15-5.
Table 15-5 aaa authentication enable default Methods
Keyword Description
if-needed Does not authenticate if user has already been authenticated on a TTY
line.
line Uses the line password for authentication.
none Uses no authentication.
radius Uses RADIUS authentication.
tacacs+ Uses TACACS+ authentication.
NOTE This command is used with TACACS+, but it cannot be used with TACACS or extended
TACACS.
For example, the following creates an authentication list that first tries to contact a TACACS+
server. If no server can be found, AAA tries to use the enable password. If this attempt also
returns an error (because no enable password is configured on the server), the user is allowed
access with no authentication.
Router(config)#aaa authentication enable default tacacs+ enable none
AAA Accounting Commands

Use the aaa accounting command in global configuration mode for auditing and billing
purposes, as follows:
Router(config)#aaa accounting
{command level | connection | exec | network | system}
{start-stop | stop-only | wait-start} {tacacs+ | radius}
Command Description
command level Audits all commands at the specified privilege level (0–15).
connection Audits all outbound connections, such as Telnet and rlogin.
exec Audits the EXEC process.
network Audits all network service requests, such as SLIP, PPP, and ARAP.
system Audits all system-level events, such as reload.
start-stop Sends a start accounting notice at the beginning of a process and a
stop accounting notice at the end of a process. The start accounting
record is sent in the background. The requested user process begins,
regardless of whether the start accounting notice was received by the
accounting server.
stop-only Sends a stop accounting notice at the end of the requested user
process.
wait-start As in start-stop, sends both a start and a stop accounting notice to the
accounting server. However, if you use the wait-start keyword, the
requested user service does not begin until the start accounting notice
is acknowledged. A stop accounting notice is also sent.
{tacacs+ | radius} Uses TACACS+ for accounting or enables RADIUS-style
accounting.
AAA Accounting Example

Completing the access control functionality, the Cisco Secure ACS serves as a central
repository for accounting information. Each session that is established can be fully accounted
for and stored on the server. This accounting information can be used for security audits,
capacity planning, or bill-back network usage.
Example 15-4 is an example of an AAA configuration for accounting.
Example 15-4 aaa accounting Configuration
Router(config)#aaa accounting network start-stop tacacs+
Router(config)#aaa accounting exec start-stop tacacs+
Router(config)#aaa accounting command 15 start-stop tacacs+
Router(config)#aaa accounting connection start-stop tacacs+
Router(config)#aaa accounting system wait-start tacacs+
z0930.book Page 4 Friday, August 3, 2001 12:54 PM
4 Chapter 1: Overview of a Campus Network
Campus Network Overview

This section contains an overview of the traditional campus networks and describes some
of the major issues and solutions that have changed the way networks operate. This section
also discusses how network traffic patterns are changing. This section covers the following
topics:
• The structure and characteristics of current campus networks
• Traditional network problems and the resulting solutions
• Existing and emerging traffic patterns
This section also deals with the demands on today’s organizations that have brought about
changes in the way campus networks are designed, as well as the components of a campus
network and the technologies driving these changes.
Traditional Campus Networks

A campus is a building or group of buildings connected into one enterprise network that
consists of many LANs. A campus is further defined as a company or a portion of a
company contained in a fixed geographic area.
The distinct characteristic of a campus environment is that the company that owns the
campus network usually owns the physical wires deployed in the campus. The campus
network topology is primarily a LAN technology connecting all the end systems within the
building or buildings. Campus networks generally use LAN technologies, such as Ethernet,
Token Ring, and Fiber Distributed Data Interface (FDDI). Figure 1-1 shows a sample
campus network.
Network designers generally deploy a campus design that is optimized for the fastest
functional architecture that runs on the existing physical wire. This coursebook discusses
the requirements of emerging applications and how higher-speed technologies, such as Fast
Ethernet, Fast EtherChannel, and Gigabit Ethernet, along with multilayer switching (MLS),
provide wire-speed data transfer to the desktop.
Regardless of the underlying technology, the main challenge facing network designers and
administrators today is to have their campus LAN run effectively and efficiently. In order
to achieve this goal, you must understand, implement, and manage the traffic flow
throughout your network.
Originally, campus networks consisted of a single LAN to which new users were added.
Because of distance limitations, campus networks usually were confined to a building or
several buildings in close proximity to each other. The LAN was a physical network that
connected the devices. In the case of Ethernet, all the devices shared the available half-
duplex 10 Mbps. Because of the carrier sense multiple access collision detect (CSMA/CD)
scheme used by the Ethernet, the whole LAN was considered a collision domain.
Campus Network Overview 5
Figure 1-1 A Traditional Campus Network
Token Token
Ring Ring
Few design considerations were needed to provide user access to the network backbone.
Because of the limitations of Ethernet, physically adjacent users were connected to a single
access device to minimize the number of taps into the backbone. Although hubs met this
requirement and became standard devices for multiple network access, increased user
demand quickly impacted the network’s performance.
Traditional Campus Issues

The major problems with traditional networks are availability and performance. These two
problems are impacted by the amount of bandwidth in the network.
In a single collision domain, frames are visible to all devices on the LAN and are free to
collide. Multiport bridges segment the LAN into discrete collision domains. and forward
Layer 2 data frames to only the segment that contains the destination address. Because
bridge ports separate the LAN into distinct physical segments, bridges also help resolve
Ethernet’s distance limitations. Bridges must, however, forward broadcasts, multicasts, and
unknown unicasts to all ports. Figure 1-2 shows that bridges terminate collision domains.
Figure 1-2 A Bridge on a Traditional Campus Network
Broadcast Domain
Collision Domain 1 Collision Domain 2
NOTE A collision domain consists of all the devices that can see or be involved in a collision. A
Layer 2 device such as a bridge or switch borders a collision domain. A collision domain is
different from a broadcast domain. A broadcast domain consists of all the devices that can
see the broadcast. A Layer 3 device such as a router borders a broadcast domain. By default,
traditional bridge ports create separate collision domains but participate in the same
broadcast domain.
Because bridges read only the Media Access Control (MAC) address in the frame, however,
frames containing the broadcast MAC address still flood the entire network. Also, a single
network device could malfunction and flood the network with indiscriminate jabber,
virtually disabling the network. Because routers operate at the network layer, these devices
can make intelligent decisions regarding the flow and type of information to and from a
network subnet.
Examples of broadcasts that ask questions are IP Address Resolution Protocol (ARP)
requests, NetBIOS name requests, and Internetwork Packet Exchange (IPX) Get Nearest
Server requests. These types of broadcasts typically flood the entire subnet and have the
target device respond directly to the broadcast. Figure 1-3 illustrates how multicasts,
broadcasts, and even unknown unicasts become global events in the bridged network
because each bridge processes the request for the MAC address for Server A.
Figure 1-3 The Request for Server A’s MAC Address Is Processed on Every Bridge in a Bridged Network
Request the
MAC Address
for Server A
ARP ARP ARP ARP
ARP ARP
ARP ARP ARP ARP
ARP ARP
ARP ARP ARP ARP ARP
ARP ARP ARP ARP
ARP ARP ARP ARP
ARP ARP ARP ARP ARP ARP
ARP ARP
ARP ARP ARP ARP
ARP ARP
ARP ARP ARP ARP
ARP ARP
ARP ARP ARP ARP
Server A
Examples of broadcasts that advertise are IPX Service Advertising Protocol (SAP) packets
and routing protocols such as the Routing Information Protocol (RIP) and Interior Gateway
Routing Protocol (IGRP).
Finally, multicast traffic can also consume bandwidth. Multicast traffic transmits to a
specific group; however, depending on the number of users in a group or the type of
application data contained in the multicast packet, this type of transmission can consume
most, if not all, of the network resources. Examples of multicast implementations are the
Cisco IPTV application using multicast packets to distribute multimedia data, and Novell
5 on IP using multicast packets to locate services.
As networks grow, so does broadcast traffic. Excessive broadcasts reduce the bandwidth
available to the end users. In worst-case scenarios, broadcast storms can effectively shut
down the network, because the broadcasts monopolize all the available bandwidth.
Also, in a bridge only network, all network-attached workstations and servers are forced to
decode all broadcast frames. This action generates additional CPU interrupts and degrades
application performance.
A Solution to Broadcast Domain Issues: Localize Traffic

There are two options for addressing the broadcast containment issue for large switched
LAN sites.
The first option is to use routers to create many subnets, logically segmenting the traffic.
LAN broadcasts do not pass through routers. Although this approach will filter broadcasts,
traditional routers process each packet and can create a bottleneck in the network. For
example, a Layer 2 bridge or switch can process millions of packets per second, while a
traditional router will process in the hundreds of thousands of packets per second. This
difference in packet processing speed can cause a bottleneck in the network if a large
amount of traffic has to cross the Layer 3 device.
The second option is to implement virtual LANs (VLANs) within the switched network.
For the purpose of this book, VLANs are defined as broadcast domains. A VLAN is a group
of end devices, on multiple physical LAN segments or switches, that communicates as if
these end devices were located on a single shared-media LAN segment. Devices on the
same VLAN need not be physically colocated in the same part of the building or campus;
however, Cisco recommends a one-to-one correspondence between VLANs and IP subnets.
Figure 1-4 shows the usage of VLANs to separate the network into individual broadcast
domains.
Figure 1-4 VLANs
VLAN1 VLAN2
VLAN3
One of the primary benefits of VLANs is that LAN switches can be used to effectively
contain broadcast traffic and separate traffic flows.
Because a VLAN is essentially a broadcast domain, the broadcast domain is now defined
by a particular set of ports on switches. None of the switches in the set will bridge any
frames between two VLANs. It is important to note that routers are required to move traffic
between broadcast domains.
Current Campus Networks

Most campus networks now consist of two components: LAN switches and routers. By
creating smaller Layer 2 broadcast domains and linking them using Layer 3 functionality,
network administrators can filter broadcast traffic, interconnect multiprotocol workgroups,

and offer a level of secure traffic.
Traffic in the Network

Devices and associated software applications running on the network all generate data
traffic. Your network probably has at least the typical applications, such as word processing,
file transfer, and electronic mail. These applications do not require much bandwidth, and
their traffic patterns are intuitive.
However, emerging campus LANs have and need much more than these basic applications.
Multifaceted applications, such as desktop publishing, videoconferencing, and WebTV
multicast programs, are all gaining popularity. The characteristics of these applications are
not always as easy to predict.
NOTE It is recommended that you maintain a snapshot of the traffic on your network using a
device such as a protocol analyzer or probe. Traffic patterns should be monitored on an
ongoing basis, because they will change over time. A good understanding of your network’s
traffic patterns and applications is essential for planning and managing the network, as well
as for future modifications such as quality of service (QoS).
The 80/20 Rule

Ideally, end users with common interests or work patterns are placed in the same logical
network as the servers they access most often. With the definition of logical networks, most
of the traffic within these workgroups is limited to the local segment. This simple task
minimizes the load on the network backbone.
The 80/20 rule states that in a properly designed network environment, 80 percent of the
traffic on a given network segment is local. Not more than 20 percent of the network traffic
should move across a backbone. Backbone congestion indicates that traffic patterns are not
meeting the 80/20 rule. In this case, rather than adding switches or upgrading hubs, network
administrators can improve network performance by doing one of the following:
• Moving resources such as applications, software programs, and files from one server
to another to contain traffic locally within a workgroup
• Moving users logically, if not physically, so that the workgroups more closely reflect
the actual traffic patterns
• Adding servers so that users can access them locally without having to cross the
backbone
The New 20/80 Rule

Traffic patterns are moving toward what is now referred to as the 20/80 model. In the 20/80
model, only 20 percent of traffic is local to the workgroup LAN, and 80 percent of the traffic
is required to go off the local network.
Two factors contribute to these changing traffic patterns:
• With Web-based computing, such as Internet applications, a PC can be both a
subscriber and a publisher of information. As a result, information can come from
anywhere in the network, creating massive amounts of traffic that must travel across
subnet boundaries. Users hop transparently between servers across the entire
enterprise by using hyperlinks, without the need to know where the data is located.
• The second factor leading to the loss of locality is the move toward server
consolidation. Enterprises are deploying centralized server farms because of the
reduced cost of ownership, security, and ease of management. All traffic from the
client subnets to these servers must travel across the campus backbone.
This change in traffic patterns means that 80 percent of the traffic now must cross a Layer
3 device. Because routing is a CPU-intensive process, the point where the Layer 3
processing takes place can lead to bottlenecks in the network. This change in traffic patterns
requires the network Layer 3 performance to match the Layer 2 performance.
The new 20/80 rule makes it difficult for network administrators to manage VLANs.
Network administrators do not want to spend their time tracking traffic patterns and
redesigning the network. Because VLANs are created on the premise that most traffic is
interworkgroup, end stations need to be in the same broadcast domain to take advantage of
the switched infrastructure.
With the new 20/80 rule, end devices need access to multiple VLANs. However, these end
devices still need to operate within their current VLANs.
With current and future traffic patterns moving away from the traditional 80/20 rule, more
traffic must flow between subnets (VLANs). Also, access to specific devices needs to be
controlled. To perform these functions, routing technology is required within the network.
All these factors together are redesigning the traditional networks into a new campus
model.
The Emerging Campus Network 11
The Emerging Campus Network

Customer requirements for the campus network are evolving. This section presents the
features and technologies that can be used to respond to these requirements.
The key requirements placing pressure on the emerging campus designs are as follows:
• Fast convergence—This requirement stipulates that the network must adapt quickly
to network topology changes. This requirement becomes critical as the campus
network grows in geographic scope.
• Deterministic paths—This requirement demands the desirability of a given path to a
destination for certain applications or user groups.
• Deterministic failover—This requirement specifies that a mechanism be in place to
ensure that the network is operational at all times.
• Scalable size and throughput—This requirement orders that as the network grows
and new applications are added, the infrastructure must handle the increased traffic
demands.
• Centralized applications—This requirement dictates that centralized applications be
available to support most or all users on the network.
• The new 20/80 rule—This requirement focuses on the shift in traditional traffic
patterns.
• Multiprotocol support—This requirement specifies that campus networks must now
support multiprotocol environments.
• Multicasting—This requirement demands that campus networks support IP multicast
traffic in addition to IP unicast traffic.
Emerging Campus Structure

User demands and complex applications force network designers to focus on the traffic
patterns in the network. No longer can networks be divided into subnetworks based only on
the number of users. The emergence of servers that run global applications also has a direct
effect on the load across the network. A higher traffic load across the entire network results
in the need for more efficient routing and switching techniques.
In the new campus model, traffic patterns dictate the placement of the services required by
the end user. Services can be separated into three separate categories:
• Local services
• Remote services
• Enterprise services
Switching Technologies 13
Figure 1-5 Sample Emerging Campus Network Structure
Remote Services
80% Non-Local
Trafic
Enterprise Services
Local Services
Switching Technologies
Due to the emerging 20/80 rule, network managers want to take advantage of the high
throughput benefits of switching technology while still retaining Layer 3 functionality in
the network. Therefore, a new model is required to support these requirements. This model
employs a concept of providing switching techniques for Layer 2, 3, and 4 functions.
Basic Layer Terminology

Most communication environments use a model that separates the communications
functions and applications processing into layers. Each layer serves a specific function.
This coursebook focuses on Layers 2, 3, and 4 of this model. Figure 1-6 shows the basic
layer terminology.
Figure 1-6 Basic Layer Terminology
Layer
Application
Presentation
Session
Segments Transport Logical Ports
Packets Network Routers
Frames Data Link Switches/Bridges
Physical
Each layer uses its own layer protocol to communicate with peer layers in another system.
Each layer protocol exchanges information, called protocol data units (PDUs), between
peer layers. A given layer can use a more specific name for its PDU. Table 1-1 gives
examples of specific PDUs for Layers 2, 3, and 4 and the device types that process those
PDUs.
Table 1-1 PDU and Device Types Relating to the OSI Layers
Model Layer PDU Type Device Type
Data Link (Layer 2) Frames Switches/bridges
Network (Layer 3) Packets Routers
Transport (Layer 4) TCP segments TCP ports
Each peer-layer protocol uses the services of the underlying layers. Thus, Transmission
Control Protocol (TCP) segments are encapsulated in Layer 3 packets, and Layer 3 packets
are encapsulated in Layer 2 frames. The layer-specific device processes only those PDU
headers for which the device is responsible.
Layer 2 Switching
Layer 2 switching is hardware-based bridging. In a switch, frame forwarding is handled by
specialized hardware called Application-Specific Integrated Circuits (ASICs). Because of
ASIC technology, switches also provide scalability to gigabit speeds and low latency at
costs significantly lower than Ethernet bridges.
NOTE An ASIC is an Application-Specific Integrated Circuit. This means that an application or

process has been implemented in hardware or an integrated circuit chip. ASICs are used in
everything from switches to wireless phones. For more information on specific ASICs in
Cisco switches, refer to Appendix B, “Switching Architectures and Functional
Descriptions.”
Layer 2 switches give network managers the ability to increase bandwidth without adding
unnecessary complexity to the network. Layer 2 data frames consist of both infrastructure
content, such as MAC addresses, and end-user content. At Layer 2, no modification is
required to the packet infrastructure content when going between like Layer 1 interfaces,
such as from Ethernet to Fast Ethernet. However, changes to infrastructure content might
occur when bridging between unlike media types such as FDDI and Ethernet or Token Ring
and Ethernet.
Workgroup connectivity and network segmentation are the two primary uses for Layer 2
switches. The high performance of a Layer 2 switch can produce network designs that
decrease the number of hosts per physical segment. Decreasing the hosts per segment leads
to a flatter network design with more segments in the campus.
However, for all its advantages, Layer 2 switching has all the same characteristics and
limitations as bridging, as shown in Figure 1-7. Broadcast domains built with Layer 2
switches still experience the same scaling and performance issues as the large bridged
networks of the past. The broadcast and multicast radius increases with the number of hosts,
and broadcasts still interrupt all the end stations. The Spanning-Tree Protocol limitations of
slow convergence and blocked links still apply.
Given the limitations of Layer 2 switching, there is still a need for Layer 3 functionality
within the network.
NOTE Although switches are much faster than the traditional bridge, Layer 2 switching and
bridging are logically equivalent and are used synonymously in this book.
These factors are moving data flows off local subnets and onto the routed network, where
the limitations of router performance can increasingly lead to bottlenecks.
Layer 3 Switching
Layer 3 switching is hardware-based routing. In particular, packet forwarding is handled by
specialized hardware ASICs. A Layer 3 switch does everything to a packet that a traditional
router does, such as the following:
• Determines the forwarding path based on Layer 3 information
• Validates the integrity of the Layer 3 header via checksum
• Verifies packet expiration and updates accordingly
• Processes and responds to any option information
• Updates forwarding statistics in the Management Information Base (MIB)
• Applies security controls if required
The primary difference between the packet-switching operation of a router and a Layer 3
switch is the physical implementation. In general-purpose routers, microprocessor-based
engines typically perform packet switching. A Layer 3 switch performs packet switching
with hardware.
NOTE A Layer 3 device, such as a router or switch, performs two basic functions. The first
function is to make a path determination based on the information found in the Layer 3
address. This is done through the use of routing protocols to build routing tables. The
routing tables are used to determine how a packet should move through the network. The
second function that a router must perform is called packet switching. Packet switching is
the process of rewriting the Layer 2 information, decrementing the Time To Live (TTL)
field, and moving the frame from one interface to the next. This process of packet switching
should not be confused with basic Layer 2 switching.
Cisco currently has two major implementations of Layer 3 switching for the Catalyst switch
product: multilayer switching and Cisco Express Forwarding. Multilayer switching is
covered in-depth in this book. Cisco Express Forwarding is covered in Appendix B.
High-performance packet-by-packet Layer 3 switching is achieved in different ways. For

example, the Cisco 12000 Gigabit Switch Router (GSR) achieves wire-speed Layer 3
switching with a crossbar switch matrix. The Catalyst family of multilayer switches
performs Layer 3 switching with special ASICs.
Because it is designed to handle high-performance LAN traffic, a Layer 3 switch can be
placed anywhere within the network, cost-effectively replacing the traditional router.
NOTE Layer 3 switching and routing are logically equivalent and are used synonymously in this
book.
Layer 4 Switching
Layer 4 switching refers to Layer 3 hardware-based routing that considers the application.
Information in packet headers typically includes Layer 2 and Layer 3 addressing and the
Layer 3 protocol type, plus more fields relevant to Layer 3 devices, such as TTL and
checksum. The packet also contains information relevant to the higher layers within the
communicating hosts, such as the protocol type and port number.
A simple definition of Layer 4 switching is the ability to make forwarding decisions based
on not just the MAC address or source/destination IP addresses but on these Layer 4
parameters. In TCP or User Datagram Protocol (UDP) flows, the application is encoded as
a port number in the segment header. Layer 4 switching is vendor-neutral and is beneficial
even when added to preexisting network environments.
Cisco routers can control traffic based on Layer 4 information. One method of controlling
Layer 4 traffic is by using standard or extended access lists. Another method is to provide
Layer 4 accounting of flows using NetFlow switching.
Finally, when performing Layer 4 functions, a switch reads the TCP and UDP fields to
determine what type of information the packet is carrying. The network manager can
program the switch to prioritize traffic by application. This function allows network
managers to define a quality of service (QoS) for end users. When being used for QoS
purposes, Layer 4 switching means that a videoconferencing application might be granted
more bandwidth than an e-mail message.
Layer 4 switching is necessary if your policy dictates granular control of traffic by
application, or if you require accounting of traffic by application.
However, it should be noted that switches performing Layer 4 switching need the ability to
identify and store large numbers of forwarding table entries. This is especially true if the
switch is within the core of an enterprise network. Many Layer 2 and Layer 3 switches have
forwarding tables that are sized in proportion to the number of network devices.
With Layer 4 switches, the number of network devices must be multiplied by the number
of different application protocols and conversations in use in the network. Thus, the size of
the forwarding table can quickly grow as the numbers of end devices and types of
applications increase. This large table capacity is essential to creating a high-performance
switch that supports wire-speed forwarding of traffic at Layer 4.
Multilayer Switching
Multilayer switching combines Layer 2 switching and Layer 3 routing functionality.
Multilayer switching moves campus traffic at wire speed while at the same time satisfying
Layer 3 routing requirements. This combination not only solves throughput problems but
also removes the conditions under which Layer 3 bottlenecks form. Multilayer switching is
based on the “route once, switch many” model.
Multilayer switching in the Catalyst family of switches can operate as a Layer 3 switch or
a Layer 4 switch. When operating as a Layer 3 switch, the Catalyst family of switches
caches flows based on IP addresses. When operating as a Layer 4 switch, the Catalyst
family of switches caches conversations based on source address, destination address,
source port, and destination port.
Because Layer 3 or Layer 4 switching is performed in hardware, there is no performance
difference between the two modes of operation.
Multilayer switching is discussed in more detail in Chapter 6, “Improving IP Routing
Performance with Multilayer Switching.”
The Hierarchical Model

Campus network designs have traditionally placed basic network-level intelligence and
services at the center of the network and shared bandwidth at the user level. Over the past
few years, distributed network services and switching have migrated to the user level, and
a distinct model has taken shape.
Figure 1-9 illustrates the hierarchical model and the devices within that model. The layers
are defined as follows:
• Access layer
• Distribution layer
• Core layer
This approach allows designers to define building blocks that interconnect users and
services. The building block encompasses both distributed network services and network
intelligence.
The best-managed campus networks are typically designed following the hierarchical
model. This model simplifies the management of the network and allows for controlled
growth. The following sections describe the components of the hierarchical model.
The Hierarchical Model 21
Figure 1-9 The Hierarchical Model
Access Layer
Distribution Layer
Core Layer
The Access Layer

The access layer of the network is the point at which end users are allowed into the network.
This layer can provide further tuning in terms of filtering or access lists; however, the key
function of this layer is to provide access for end users into the network. In the campus
environment, some of the functions represented by the access layer are as follows:
• Shared bandwidth
• Switched bandwidth
• Layer 2 services, such as VLAN membership and traffic filtering based on broadcast
or MAC addresses
The main criterion for access devices is to provide this functionality with low-cost, high-
port density devices.
The Distribution Layer

The distribution layer of the network marks the point between the access and core layers of
the network. The distribution layer also helps define and differentiate the core. This layer
provides a boundary definition and designates where potentially expensive packet
manipulations are handled. In the campus environment, the distribution layer can represent
a multitude of functions, some of which are as follows:
• VLAN aggregation
• Departmental or workgroup access
• Broadcast or multicast domain definition
• Inter-VLAN routing
• Media translations
• Security
The distribution layer can be summarized as the layer that provides policy-based
connectivity.
The Core Layer

The core layer is sometimes referred to as the backbone of a campus network. The primary
purpose of the core layer is to switch traffic as fast as possible. This layer of the network
should not be involved in expensive packet manipulation or any processing that slows down
traffic switching. Functions such as access lists and packet filtering should be avoided in the
core. The core layer is responsible for the following functions:
• Providing connectivity between switch blocks
• Providing access to other blocks, such as the WAN block
• Switching frames or packets as quickly as possible
Choosing a Cisco Product

Campus size is an important factor in network design. A large campus has several or many
colocated buildings. A medium campus has one or several colocated buildings, and a small
campus might have only one building.
The selection of Cisco products at a specific layer depends on the required functionality of
each device. The following sections discuss each layer and the appropriate devices. For
pictures and further explanation of the products explained in this section, see the Cisco
Connection Online (CCO) Web site’s product listings at http://www.cisco.com/public/
products_prod.shtml.
Access Layer Switches

The Catalyst 1900 or 2820 series switch is an effective access device in a small or medium
campus network, connecting individual desktops and 10BaseT hubs to distribution
switches with high-speed connections.
The Catalyst 2900 series switch is also effective in providing network access to server
clusters or end-user populations of less than 50 users that have high bandwidth
The Hierarchical Model 23
requirements. In these types of applications, such as in CAD/CAM and IC design

environments, the 2900 series switch provides up to 1000 Mbps throughput for client/server
applications and enterprise servers.
The Catalyst 4000 series provides an advanced high-performance enterprise switching
solution optimized for connecting up to 96 users and data center server environments that
require up to 36 Gigabit Ethernet ports. The Catalyst 4000 series leverages a multigigabit
architecture for 10/100/1000 Mbps Ethernet switching.
The Catalyst 5000 series is an effective access device in large campus networks that need
to provide network access for more than 100 end users. This switch supports 10/100/1000
Mbps Ethernet switching.
Distribution Layer Switches

Because the distribution layer switch is the aggregation point for multiple access switches,
it must be able to handle the total amount of traffic from these devices. The distribution
layer switch also must be able to participate in multilayer switching with a route processor.
Therefore, the most effective distribution switch devices are the Catalyst 5000 series and
2926G switches. For Layer 3 switching, the Catalyst 5000 series switches support an
internal route processor module, and the 2926G switch works with an external router, such
as the 4x00 and 7x00 series routers.
The Catalyst 6000 switches are effective at the distribution level, where users require very
high densities of Fast or Gigabit Ethernet—up to 384 10/100, 192 100FX, and 130 Gigabit
Ethernet ports.
NOTE When choosing a distribution layer switch, remember to consider the amount of aggregate
bandwidth to support the access layer devices and connectivity to the core layer. The
Catalyst 5000 is best used in small to medium networks where the primary connectivity is
10/100 Mb Ethernet. The Catalyst 5000 has a 3.6 Gbps switch fabric, which can be
oversubscribed if it supports many Gigabit Ethernet ports. The Catalyst 6000 is
recommended in medium to large network environments due to its ability to handle Gigabit
Ethernet better than the Catalyst 5000. The Catalyst 6000 has a 32 Gbps switch fabric,
which allows it to handle a larger number of Gigabit Ethernet connections. Refer to
Appendix B for a more detailed discussion of switch fabrics and oversubscription.
Core Layer Switches

For core backbone implementations, the Catalyst 6500 and 8500 series provide wire-speed
multicast forwarding and routing, as well as the Protocol-Independent Multicast (PIM)
protocol for scalable multicast routing.
Both of these switches provide the high bandwidth and performance that is required for a
campus backbone. They are ideal for aggregating multiprotocol traffic from multiple wiring
closets or from workgroup switches, such as the Catalyst 5000/6000.
The Building Block Approach

In an attempt to ease the design process of small to large campus networks, Cisco has
created a set of building blocks for the network. These building blocks allow a design to
scale as small or as large as is necessary.
Network building blocks can be any one of the following fundamental campus elements or
contributing variables.
Campus elements:
• Switch block
• Core block
Contributing variables:
• Server block
• WAN block
• Mainframe block
The fundamental campus elements are described in this section. Figure 1-10 shows the
campus elements as well as the contributing blocks, or variables, connected by the core
block.
NOTE For more information on the various components of the building blocks, refer to the
Campus Network Design Case Study white paper, located at the CCO Web site (http://
www.cisco.com).
The Building Block Approach 25
Figure 1-10 Campus Network Building Blocks
Building A Building B Building C
Switch
Block
Mainframe Block Core Block WAN Block
Token
Ring
Server Block
The Switch Block

The switch block contains a balanced implementation of scalable Layer 2 switching and
Layer 3 services. Although the current generation of LAN switches is replacing shared
media concentrators, LAN switches are not replacements for Layer 3 devices. Therefore,
the switch block consists of both switch and router functionality. The switch block shown
in Figure 1-11 prevents all broadcast traffic as well as network problems from traversing
the core block and from reaching other switch blocks.
Figure 1-11 The Switch Block
Switch Block 1 Switch Block 2 Local

Event
Access Layer Access Layer
Distribution Layer Distribution Layer
Layer 2 switches in the wiring closets connect users to the network at the access layer and
provide dedicated bandwidth to each port. The Catalyst 2900 and 2820/1900 series
switches provide cost-effective wiring closet connectivity.
The access devices merge into one or more distribution devices. The distribution device
provides Layer 2 connectivity between access switches and acts as a central connection
point for all of the switches in the wiring closets.
The distribution layer also provides Layer 3 functionality, which supports routing and
networking services. The distribution layer shields the switch block against failures in other
parts of the network.
The distribution device can be one of the following:
• A switch and external router combination
• A multilayer switch
These distribution layer devices are discussed in more detail in Chapter 5, “Inter-VLAN
Routing.”
If the switch block experiences a broadcast storm, the router prevents the storm from
propagating into the core and into the rest of the network. Each block is protected from the
other blocks when failures occur. However, the switch block, in which the broadcast storm
occurs, still experiences network problems until the device generating the broadcasts is
found and removed from the network.
NOTE Cisco has attempted to address the problem of broadcast storms by adding broadcast
thresholds to their switches. A broadcast threshold prevents the port from receiving
broadcasts until the number of broadcasts drops below a specific number of broadcasts per
second or a specific percentage of traffic. This prevents the broadcasts from overwhelming
the device, such as a workstation, on the other end of the port.
Switch Block Characteristics

Access layer switches may support one or more subnets. A subnet must reside within one
broadcast domain. This means that all stations residing in or ports configured on the same
VLAN are assigned network addresses within the same subnet. However, a single VLAN
can support multiple subnets.
The broadcast isolation feature of VLANs is the characteristic that allows VLANs to be
identified with subnets. For example, the IP Address Resolution Protocol (ARP) propagates
only within the VLAN of the originating request. All subnets terminate on Layer 3 devices,
such as a router or a Route Switch Module (RSM). To connect to devices in other VLANs,
the frame must traverse a router. In this model, VLANs should not extend beyond the
distribution switch.
Access layer switches have redundant connections, or uplinks, to the distribution switch to
maintain resiliency. The Spanning-Tree Protocol allows these redundant links to exist while
preventing undesirable loops in the switch block. The Spanning-Tree Protocol terminates
at the boundary of the switch block.
All switches in the network may be connected to a common management default subnet.
VLAN management domains are discussed in greater detail in Chapter 3, “Defining
Common Workgroups with VLANs.”
NOTE Cisco philosophy discourages trunking across the core unless discrete VLAN1 connections
are made between the distribution and core switches.
Sizing the Switch Block

Although the size of a switch block is flexible, certain factors limit the size of this block.
The number of switches that collapse into the distribution layer depends on several factors:
• Different types and patterns of traffic
• Amount of Layer 3 switching capacity at the distribution layer
• Number of users per access layer switch
• Extent to which subnets need to traverse geographical locations within the network
• Size to which the Spanning-Tree domains should be allowed to grow
There are two main factors in sizing the switch block:
• Traffic types and behavior
• Size and number of workgroups
NOTE This model is based on no more than 2000 users per switch block.
A switch block is too large if

• A traffic bottleneck occurs in the routers at the distribution layer due to intensive CPU
processing required by services such as access lists
• Broadcast or multicast traffic slows down the switches and routers
NOTE The decision to break up the block should be based on the traffic going across the network,
rather than the specific number of nodes in a building block. It is important to take periodic
snapshots of traffic flows in order to be able to determine when to break up the switch block.
The Core Block

A core is required when there are two or more switch blocks. The core block is responsible
for transferring cross-campus traffic without any processor-intensive operations, such as
routing. All the traffic going to and from the switch blocks, the server blocks, the Internet,
and the wide-area network passes through the core.
Traffic going from one switch block to another also must travel through the core. Because
of these traffic patterns, the core handles much more traffic than any other block. Therefore,
the core must be able to pass the traffic to and from the blocks as quickly as when there are
two or more switch blocks.
In Figure 1-12, the core block supports frame, packet, or cell-based technologies,
depending on your specific needs. This coursebook discusses and demonstrates an Ethernet
core. Because the distribution switch provides Layer 3 functionality, individual subnets will
connect all distribution and core devices.
Collapsed Core
The collapsed core exists when both the distribution and core layer functions are performed
in the same device. A collapsed core design is prevalent in small campus networks.
Although the functions of each layer are contained in the same device, the functionality
remains distinctly separate. Figure 1-13 shows a sample collapsed core.
Figure 1-13 A Collapsed Core
Switch Block 1 Switch Block 2

Access Layer Access Layer
Core Connectivity
Distribution/Core Layer Distribution/Core Layer
In a collapsed core design, each access layer switch has a redundant link to the distribution
layer switch. Each access layer switch may support more than one subnet; however, all
subnets terminate on Layer 3 ports on the distribution switch.
Redundant uplinks provide Layer 2 resiliency between the access and distribution switches.
Spanning Tree blocks the redundant links to prevent loops.
Redundancy is provided at Layer 3 by the dual distribution switches with the Hot Standby
Router Protocol (HSRP), providing transparent default gateway operations for IP. In the
event that the primary routing process fails, connectivity to the core is maintained. HSRP
is discussed in more detail in Chapter 7, “Configuring HSRP for Fault-Tolerant Routing.”
Dual Core
A dual-core configuration is necessary when two or more switch blocks exist and redundant
connections are required. Figure 1-14 shows a dual-core configuration in which the core
contains only Layer 2 switches for the backbone. The core devices are not linked to avoid
any bridging loops.
Figure 1-14 A Dual Core
Switch Block 1 Switch Block 2
Subnet A Subnet B
Core Block
A dual-core topology provides two equal-cost paths and twice the bandwidth. Each core
switch carries a symmetrical number of subnets to the Layer 3 function of the distribution
device. Each switch block is redundantly linked to both core switches, allowing for two
distinct and equal path links. If one core device fails, convergence is not an issue, because
the routing tables in the distribution devices already have an established route to the
remaining core device. The Layer 3 routing protocol provides the link determination across
the core, and HSRP provides quick failover determination. Spanning Tree is not needed in
the core, because there are no redundant links between the core switches.
Sizing the Core

Because Layer 3 devices isolate the core, routing protocols are used to maintain the current
state of the network. As the routing protocol sends these updates and changes to the routers
throughout the network, the network topology might also change. The more routers
connected to the network, the longer it takes these updates and changes to propagate
throughout the network and change the topology. Also, one or more of the routers might
connect to a WAN or the Internet, which adds more sources of routing updates and topology
changes.
The routing protocol used on the Layer 3 devices determines the number of distribution
devices that can be attached to the core. Table 1-2 gives examples of some widely used
Figure 1-16 Layer 3 Backbone Scaling
Fast Convergence
As you increase the number of switch blocks and servers, each distribution layer device
must be connected to the core. Because there is a limit to the number of switch blocks to a
dual Layer 2 core, increasing the number of connections means increasing the number of
core devices. To maintain redundancy, the core devices must be connected. After you
interconnect Layer 2 devices, bridging loops appear. To eliminate bridging loops in the
core, you must enable the Spanning-Tree Protocol. The Spanning-Tree Protocol might have
a convergence time of over 50 seconds. If there is a fault in the network’s core, Spanning-
Tree Protocol convergence can disable a network core for more than one minute.
With the implementation of Layer 3 devices in the core, the Spanning-Tree Protocol
becomes unnecessary. In this design, routing protocols are used to maintain the network
topology. Convergence for routing protocols takes anywhere from 5 to 10 seconds,
depending on the routing protocol.
Automatic Load Balancing

Load balancing tries to achieve a traffic distribution pattern that will best utilize the multiple
links that provide redundancy. With multiple, interconnected Layer 2 devices in the core,
you must selectively choose the root for utilizing more than one path. You then manually
configure the links to support specific VLAN traffic.
With Layer 3 devices in the core, the routing protocols can load balance over multiple
equal-cost paths.
Campus Network Availability Example 35
Eliminate Peering Problems

Another issue with the Layer 2 core in a very large network involves router peering. Router
peering ensures that the routing protocol running within a router maintains state and
reachability information about other neighboring routers. In this scenario, each distribution
device becomes a peer with every other distribution device in the network. Scalability
becomes an issue in the configuration, because each distribution device must maintain state
for all other distribution devices.
With the implementation of Layer 3 devices in the core, a hierarchy is created, and the
distribution device is not considered a peer with all other distribution devices. This type of
core might appear in very large campus networks in which the network supports more than
100 switch blocks.
Implementing Layer 3 devices in the core is expensive. As stated earlier, the main purpose
of the core is to move packets as quickly and efficiently as possible. Although Layer 3
devices can support the switching of some protocols, both performance and equipment cost
become an issue.
Campus Network Availability Example

The design shown in Figure 1-17 consists of two buildings: North and South. Each building
has 10 floors and 1000 users. Each floor is connected to an access switch in the wiring
closet. Each access switch is linked to a distribution layer switch.
If a link from a wiring closet switch to the distribution-layer switch is disconnected, 100
users on a floor could lose their connections to the backbone. To prevent this, each access
switch has a link to each distribution switch in the building. The Spanning-Tree Protocol
blocks the redundant link to prevent loops.
Load balancing across the core is achieved by intelligent Layer 3 routing protocols
implemented in the Cisco IOS software. In Figure 1-17, there are four equal-cost paths
between the two buildings. The four paths from the North building to the South building
are AXC, AYD, BXC, and BYD. These four Layer 2 paths are considered equal by Layer
3 routing protocols. Note that all paths from both buildings to the backbone are single,
logical hops.
Figure 1-17 A Campus Network Availability Example
North Building South Building
Switch M Switch P
M2 M1 P2 P1
Switch Switch Switch Switch

A B C D
Core Core
X Y
In this scenario, a user attached to access switch M wants to transfer data to a user attached
to switch P. The active router is multilayer switch B, and HSRP is enabled. As shown in
Figure 1-17, the logical path for the data from M to P is as follows:
• Access switch M switches the data over link M1 to multilayer switch B.
• Multilayer switch B routes the data out subnet BY to core Y.
• Core Y switches the information out link YD to multilayer switch D.
• Multilayer switch D switches the data over link P1 to access switch P.
If the M1 link fails, however, as shown in Figure 1-18, the redundant M2 link becomes the
primary link, and the data path from M to P is as follows:
• Access switch M switches the data over link M2 to multilayer switch A.
• Multilayer switch A switches the data to the active HSRP router, multilayer switch B.
• Multilayer switch B routes the data out subnet BY to core Y.
• Multilayer Switch D switches the data over link P1 to access switch P.
Campus Network Availability Example 37
Figure 1-18 Access Layer Switch Failure Causes Data to Fail Over to the Redundant Link
Switch M Switch P
M2 M1 P2 P1

A B C D
Core Core
X Y
A distribution layer switch represents a point of failure at the building level. One thousand
users in the North building could lose their connections to the backbone in the event of a
disabled route processor. To provide fault-tolerant access to each user, redundant links
connect access layer switches to a pair of Catalyst multilayer switches in the distribution
layer, as shown in Figure 1-19.
In Figure 1-19, the route processors in both distribution devices are connected, and HSRP
is configured. This configuration allows for fast failover at Layer 3 if one of the distribution
switches fails. In this scenario, the data path from M to P is as follows:
• Access switch M switches the data over link M2 to multilayer switch A.
• Because multilayer switch B is disabled, multilayer switch A becomes the active
HSRP router and routes the data out subnet AY to core Y.
• Multilayer switch D switches the data over link P1 to access switch P.
Figure 1-19 Redundancy in the Distribution Layer
Switch M Switch P
M2 M1 P2 P1

A B C D
Core Core
X Y
Redundancy in the backbone is achieved by installing two or more Catalyst switches in the
core. Each link from the distribution switch to the core is an equal-cost path. This topology
provides failover as well as load balancing from each distribution switch across the
backbone.
Load balancing across the core is achieved by intelligent Layer 3 routing protocols
implemented in the Cisco IOS software. Figure 1-20 shows an example.
If one switch in the core fails, the data path from M to P is as follows:
• Access switch M switches the data over link M2 to multilayer switch A. Link M1 is
still disabled.
• Because multilayer switch B is disabled, multilayer switch A becomes the active
HSRP router.
• Because core Y is disabled, the data is routed out subnet AX to core X.
• The path at the distribution layer depends on how the ports and VLANs on those
devices are configured. In this scenario, the data core X switches the information out
link XC to multilayer switch C.
Written Exercises: Overview of a Campus Network 41
Written Exercises: Overview of a Campus Network

These exercises help you identify the different switching technologies implemented at OSI
Layers 2, 3, and 4. The answers to each task can be found at the end of this chapter.
Task 1: Describing Layer 2, 3, and 4 and Multilayer Switching

Functions
For each network function listed in the following table, choose the switching technology
that most accurately supports each function, and place the letter of that switching
technology next to the function. Each function can have more than one correct answer, so
list all possible answers. The first answer is given as an example.
A. Layer 2 switching
B. Layer 3 switching
C. Layer 4 switching
D. Multilayer switching
B Hardware-based routing
Hardware-based bridging
Forwards packets based on application port numbers
Based on the principle of “route once, switch many”
Promotes flatter network designs with fewer subnets
Controls traffic using access lists based on port identifiers
Provides traffic flow accounting through NetFlow switching
Combines Layer 2 switching and Layer 3 routing functionality
Uses frames to communicate with peer layers in another system
Handles frame forwarding using specialized hardware called ASICs
Uses packets to communicate with peer layers in another system
Allows the switch to be programmed to prioritize traffic by application
Interrogates the initial packet in a flow, which is then forwarded to a cache
Allows the prioritization of traffic based on specific applications
Does not modify frame infrastructure when moving frames between like media
4 The Rataxes Toy Company needs to interconnect its four separate campus buildings
with a high-speed, high-bandwidth backbone. Each building supports a separate
department, and each department supports a different network protocol. The network
designer has already recommended a Catalyst 6000 series switch at the distribution
layer. What is the most appropriate device for the core layer?
A. Catalyst 8500 series switch
B. Catalyst 1900 series switch with 12 10BaseT ports
C. Catalyst 4000 series switch with a six-port Gigabit Ethernet module
D. Catalyst 5500 series switch with a 24-port group switched 100BaseT Ethernet
module
Task 1 Answers: Describing Layer 2, 3, and 4 and Multilayer

Switching Functions
The following table contains the correct answers for Task 1.
B Hardware-based routing
A Hardware-based bridging
B&C Forwards packets based on application port numbers
D Based on the principle of “route once, switch many”
A Promotes flatter network designs with fewer subnets
B&C Controls traffic using access lists based on port identifiers
B&C Provides traffic flow accounting through NetFlow switching
D Combines Layer 2 switching and Layer 3 routing functionality
A Uses frames to communicate with peer layers in another system
A Handles frame forwarding using specialized hardware called ASICs
B Uses packets to communicate with peer layers in another system
C Allows the switch to be programmed to prioritize traffic by application
D Interrogates the initial packet in a flow, which is then forwarded to a cache
C Allows the prioritization of traffic based on specific applications
A Does not modify frame infrastructure when moving frames between like media
C Reads the TCP or UDP field to determine what type of information the packet is carrying
Written Exercises: Overview of a Campus Network 45
A Repackages multiport bridging technology with significant performance improvements

and increased scalability
C Implements a level of security, interrogating traffic based on the source address,

destination addresses, and port number
Task 2 Answers: Identifying the Switch Layer Solution for a Given

Network Requirement
The following are the correct answers for Task 2.
1 This layer is responsible for routing traffic between VLANs.
B. Distribution layer
2 The primary objective of this layer is to switch traffic as fast as possible.
C. Core layer
3 This layer provides communication between switch blocks and to the enterprise
servers.
C. Core layer
4 The key function of this layer is to provide access for end users into the network.
A. Access layer
5 This layer provides segmentation and terminates collision and broadcast domains.
6 This layer blocks or forwards traffic into or out of the switch block, based on Layer 3
parameters.
7 Some of the functions represented by this layer are shared bandwidth, VLAN
membership, and traffic filtering, based on broadcast addresses.
A. Access layer
8 The main criterion for devices at this layer is to provide LAN segmentation with low-
cost, high-port density devices.
A. Access layer
Task 3 Answers: Given a Set of User Requirements, Identify the

Correct Cisco Product Solution
The following are the correct answers for Task 3.
1 The ABC Company is a small widget-distributing company that wants to interconnect
users on multiple floors in the same building. To date, the company has only 15
employees, but it plans to triple that number in the next two years. Because of the
nature of the business, users need to access large files on the workgroup servers. What
is the most appropriate device for the access layer?
C. Catalyst 1900 series switch with 10BaseT ports
2 The Acme Engineering Company has redesigned its campus network to support three
switch blocks containing 2000 end users in each block. The network administrator
wants to control broadcast domains to each individual switch block while still
allowing inter-VLAN routing within and between switch blocks. What is the most
appropriate device for the distribution layer?
C. Catalyst 5500 series switch with an internal RSM
3 The Tool & Die Manufacturing Company has experienced 300 percent growth over
the last year and has recently installed a new multimedia center for distributing
company information throughout the campus. The company has requirements for
gigabit-speed data transfer, high availability, and inter-VLAN routing between the
end users and the enterprise server farms. What is the most appropriate device for the
distribution layer?
D. Catalyst 6000 series switch with a 16-port Gigabit Ethernet module
4 The Rataxes Toy Company needs to interconnect its four separate campus buildings
with a high-speed, high-bandwidth backbone. Each building supports a separate
department, and each department supports a different network protocol. The network
designer has already recommended a Catalyst 6000 series switch at the distribution
layer. What is the most appropriate device for the core layer?
A. Catalyst 8500 series switch
50 Chapter 2: Connecting the Switch Block
Applications such as multimedia and real-time video are particularly demanding, as are
applications such as Web browsing. Future e-commerce transmissions require dedicated
connections to accommodate the high density of traffic they frequently generate. With more
and more users requiring faster access to large database systems, tolerance for sluggish
performance is waning.
The module design of the campus network topology allows for scaling bandwidth
appropriately at every level. This approach provides advantages in configuring and
managing any size of network.
Every network site is unique, and the performance of the network is a result of a number of
different factors. One of those factors is the type and layout of the underlying cables that
are used to interconnect the devices, and how the devices in the switch block are configured
for basic operations. This chapter covers cable media types, focusing specifically on
Ethernet, Fast Ethernet, and Gigabit Ethernet. Additionally, this chapter discusses cabling
devices in the switch block.
Cable Media Types

A variety of cable media types have been deployed for local-area networks (LANs),
including Ethernet, Token Ring, Arcnet, and FDDI, just to name a few. Most of these cable
media types deploy a shared media architecture, meaning that only one device can use the
cable segment at a time. As larger applications are added to the network, much work must
be put into increasing the bandwidth available to the user. There are two predominant
methods to increase the bandwidth to the user:
• Increase the overall bandwidth of the network.
• Decrease the number of devices on the same shared media cable segment.
In the past couple of years, Ethernet has become the most commonly implemented LAN
standard. This book focuses only on variations of Ethernet for that reason.
Ethernet
One solution to the bandwidth crunch is Ethernet switching, which dynamically allocates
dedicated 10 Mbps connections to each user on the network. Another option is full-duplex
switched Ethernet.
Finally, increasing the speed of the link also increases network performance. Whereas
Ethernet supports 10 megabits of data per second, Fast Ethernet supports 100 megabits of
data per second, and Gigabit supports up to 1000 megabits of data per second.
Within the switch block, network performance is enhanced at the access layer by reducing
the number of users per Ethernet segment. Segmentation provides each user, or a group of
Cable Media Types 51
users connected by a hub, with a dedicated, collision-free 10 Mbps connection to any other
node or LAN segment.
NOTE Ethernet is a LAN technology that offers increased bandwidth to desktop users at the access
layer. Ethernet transmits information between end-user devices at speeds of 10 million bits
per second.
The availability of powerful, affordable personal computers and workstations has driven the
requirement for speed and availability in the campus network. However, existing
applications and a new generation of multimedia, imaging, and database products can
easily overwhelm a network running at a traditional Ethernet speed of 10 Mbps. Table 2-1
describes the typical layers that utilize 10 Mbps Ethernet.
Table 2-1 Ethernet 10BaseT Media Deployment Strategy
Model Layer Positioning
Access layer Provides connectivity between the end-user device and the access switch.
Distribution layer Not typically used at this layer.
Core layer Not typically used at this layer.
Most cable installers recommend that the 100-meter rule be followed when installing
unshielded twisted-pair (UTP) cable connections. The 100-meter rule is broken down into
the following distances:
• Five meters from the switch to the patch panel
• Ninety meters from the patch panel to the office punch-down block
• Five meters from the punch-down block to the desktop connection
Short cables in a noisy wiring closet translate to less induced noise on the wire and less
crosstalk in large multiple-cable bundles. However, short cables might restrict switch
location in large wiring closets, so the 100-meter rule is often overlooked.
Fast Ethernet
For campuses with existing Ethernet installations, increasing the network speed from 10
Mbps to 100 Mbps is preferable to investing in a completely new LAN technology. This
requirement forced the networking industry to specify a higher-speed Ethernet that operates
at 100 Mbps and is known as Fast Ethernet.
Fast Ethernet technology can be used in a campus network in several different ways. Fast
Ethernet is used as the link between the access and distribution-layer devices, supporting
the aggregate traffic from each Ethernet segment on the access link.
Fast Ethernet links can also be used to provide the connection between the distribution layer
and the core. Because the campus network model supports dual links between each
distribution-layer router and core switch, the aggregated traffic from multiple access
switches can be load-balanced across the links.
Many client/server networks suffer from too many clients trying to access the same server,
creating a bottleneck where the server attaches to the LAN. To enhance client/server
performance across the campus network, enterprise servers are connected by Fast Ethernet
links to ensure the avoidance of bottlenecks at the server. Fast Ethernet, in combination with
switched Ethernet, creates an effective solution for avoiding slow networks. Table 2-2
describes the layers that typically deploy Fast Ethernet.
Table 2-2 Fast Ethernet Deployment Strategy
Access layer Gives high-performance PC and workstations 100 Mbps access to the
server.
Distribution layer Provides connectivity between access and distribution layers. Provides
connectivity from the distribution layer to the core layer. Provides
connectivity from the server block to the core layer.
Core layer Provides interswitch connectivity.
Fast Ethernet is based on carrier sense multiple access collision detect (CSMA/CD), the
Ethernet transmission protocol, and it can use existing UTP or fiber cabling. However, Fast
Ethernet reduces the duration of time each bit is transmitted by a factor of 10, allowing
packet speed to increase tenfold from 10 Mbps to 100 Mbps. Data can move from 10 Mbps
to 100 Mbps without protocol translation or changes to application and networking
software. Fast Ethernet also maintains the 10BaseT error control functions, as well as the
frame format and length.
Fast Ethernet can run over UTP and fiber. Table 2-3 shows the distance for each media type
defined by the Fast Ethernet specification.
Table 2-3 Distance Limitations for Fast Ethernet
Cable Length
Technology Wiring Category Switched Media
100BaseTX EIA/TIA Category 5 (UTP) 100 meters
Unshielded twisted pair
2 pair
Table 2-4 indicates, for example, that if both devices on the link can support both 10BaseT
and 100BaseTX, the autonegotiation process at both ends of the link will connect using
100BaseTX mode.
The autonegotiation definition also provides a parallel detection function that allows half-
and full-duplex 10BaseT, half- and full-duplex 100BaseTX, and 100BaseT4 physical layers
to be recognized, even if one of the connected devices does not offer autonegotiation
capabilities. The full-duplex mode of operation is given priority over half duplex, because the
full-duplex system can send more data than a half-duplex link operating at the same speed.
NOTE Although the autonegotiation protocol allows devices to automatically exchange

information about the link, the protocol is not well standardized. Autonegotiation can lead
to connectivity problems, so Cisco recommends that the appropriate values of speed and
duplex be configured in the switches.
Gigabit Ethernet
Gigabit Ethernet is effective in the switch block, the core block, and the server block.
In the switch block, Gigabit Ethernet is deployed for links that connect centrally located
aggregation switches with each access switch. Each access switch has a Gigabit Ethernet
uplink that connects to the distribution switch.
In the core block, Gigabit Ethernet links are used to connect distribution-layer switches in
each building with a central campus core. Table 2-5 describes the most common
deployment strategy of Gigabit Ethernet in the switch block.
Table 2-5 Gigabit Deployment Strategy
Access layer Not commonly used between the end-user device and the access switch,
although more end stations or nodes are beginning to support Gigabit
Ethernet uplinks.
Distribution layer Provides high-speed connections between the access and distribution-
layer devices.
Core layer Provides high-speed connectivity to the distribution layer and the server
block. Provides high-speed interconnectivity between core devices.
Gigabit Ethernet is also well-suited for connecting high-performance servers to the

network. A high-performance UNIX or video server can easily flood three to four Fast
Ethernet connections simultaneously. As servers are growing in power and throughput, and
with the trend for centralizing servers within the campus network, Gigabit Ethernet can
Cabling Switch Block Devices 61
Connecting to the Console Port on an IOS Command-Based Switch

To connect a management terminal to the 1900/2800 or 2900 XL switch through the serial
console, use the RJ-45-to-RJ-45 rollover cable supplied with the switch. Follow these steps
to cable the two devices:
Step 1 Connect one end of the supplied rollover cable to the console port. As
you can see in Figure 2-4, the 1900 and some 5000 series switches use
an RJ-45 console connection. Older 5000 series switches use a DB-25
connection.
Figure 2-4 Console Port Connection
Console Port
1900 Series Console Port
Console Port
5000 Series Console Port
S
LE
LO TCH
2 N
VE
BP
U M
ET
PS FA
AD
SO
AT TE
TI
0%
M
ES
I
S
SW
AC
ST YS
N
1%
0
10
R
10
S
K
1
N
PS
Supervisor Engine LI
IX
D
M
CAUTION Do not connect an actual telephone line, a live Integrated Services Digital Network (ISDN)
line, or an Ethernet cable to this console port. Damage to the switch can result. Make sure
you use the supplied RJ-45-to-RJ-45 rollover cable and adapters to connect the console port
to the management station or modem.
Step 2 Attach one of the following supplied adapters to a management station or

modem:
— RJ-45-to-DB-9 female data terminal equipment (DTE) adapter
(labeled Terminal) to connect a PC
— RJ-45-to-DB-25 female DTE adapter (labeled Terminal) to connect
a UNIX workstation
— RJ-45-to-DB-25 male data communications equipment (DCE)
adapter (labeled Modem) to connect a modem
Step 3 Connect the other end of the supplied rollover cable to the adapter.
Step 4 From your management station, start the terminal emulation program.
Connecting to the Console Port on a Catalyst 5000 Series Switch

To connect a management terminal to the Supervisor Engine III console port switch
through the console, use the RJ-45-to-RJ-45 rollover cable and the appropriate adapter,
both supplied with the switch. Follow these steps to cable the two devices:
Step 1 Connect one end of the supplied rollover cable to the console port.
Step 2 Attach one of the following supplied adapters to a management station or

modem:
— RJ-45-to-DB-9 female DTE adapter (labeled Terminal) to connect
a PC
— RJ-45-to-D-subminiature female adapter (labeled Terminal) to
connect a UNIX workstation
— RJ-45-to-D-subminiature male adapter (labeled Modem) to
connect a modem
Step 3 Connect the other end of the supplied rollover cable to the RJ-45 port.
Step 4 From your management station, start the terminal emulation program.
Neither this book nor the BCMSN course covers cabling to a Gigabit
Ethernet port.
Connecting to an Ethernet Port

On the Catalyst 1900 and 2800 series switches, the port types are fixed. All 10BaseT ports
(ports 1x through 12x or ports 1x through 24x) can be connected to any 10BaseT-
compatible device. The 100BaseTX ports (ports Ax and Bx) can be connected to any
100BaseTX-compatible device.
The Catalyst 5000 series switches have ports that can be configured for either 10BaseT or
100BaseT.
All UTP connections between the switch and the attached device(s) must be within 100
meters.
When connecting the switch to servers, workstations, and routers, ensure that you use a
straight-through cable. When connecting to other switches or repeaters, ensure that you use
a crossover cable. Figure 2-5 shows the RJ-45 ports on an Ethernet line module for a
Catalyst 5000 series switch.
Configuring Connectivity within the Switch Block 65
password is any set of alphanumeric characters. The password must be from four to eight
(inclusive) characters long.
NOTE Passwords on these switches are not case-sensitive.
Example 2-1 shows a Catalyst 1912 series switch that requires the word cisco as a login to
user EXEC level and the password san-fran as the privileged mode password.
Example 2-1 Catalyst 1912 Series Switch
Switch#show running-configuration
Building configuration...
Current configuration:
(text deleted)
!
enable password level 1 "CISCO"
enable password level 15 "SAN-FRAN"
To remove a password, enter the no enable password level number command.
Limiting Access on a Set Command-Based Switch

To set passwords on a set-based switch, enter the following commands in privileged mode:
Switch (enable) set password
Enter old password: old password
Enter new password: new password
Retype new password: new password
Password changed.
Switch (enable) set enablepass
Enter old password: old password
Enter new password: new password
Retype new password: new password
Password changed.
password is any set of alphanumeric characters.
NOTE Passwords on these switches are case-sensitive.

Example 2-2 shows the configuration of a Catalyst 5000 series switch that has both a
console login and enabled password set.
Example 2-2 Catalyst 5000 that Has a Console Login and Enabled Password Set
DSW111 (enable) show config
.....
..........
..........
.........
(text deleted)
begin
set password $1$9qGT$XSM6Mh//ygeee/g3t8NRV/
set enablepass $1$oI7d$01ZtlKtavKuXHycQ2wKsw/
Uniquely Defining the Switch

Every switch arrives from the factory with the same default prompt designation. In a large
campus network, it is crucial to distinguish one switch from another, especially because
most network administrators use Telnet to connect to many switches across the campus.
Setting a Host Name on a Cisco IOS Command-Based Switch

To set the host or system name on a 1900/2800 or 2900 XL series switch, enter the
following command in global configuration mode:
Switch(config)#hostname name
name can be from 1 to 255 alphanumeric characters.

As soon as you execute the hostname command, the system prompt assumes the host
name. To remove the system name, enter the no hostname command in global
configuration mode.
Setting a System Prompt on a Set Command-Based Switch

If your switch is set-based, the name you assign for the system name is used to define the
system prompt. However, you can assign a name to the CLI prompt that differs from the
system name. To assign a unique name to the CLI prompt, enter the following command in
privileged mode:
System(enable) set prompt name
name sets the CLI prompt.

Configuring Switch Remote Accessibility

Before you can Telnet to, ping, or globally manage the switch, you need to associate that
switch with the management virtual LAN (VLAN). Although LAN switches are essentially
Layer 2 devices, they do maintain an IP stack for administrative purposes. Assigning an IP
address to the switch associates that switch with the management VLAN, providing that the
subnet portion of the switch IP address matches the subnet number of the management
VLAN.
Configuring Remote Accessibility on a Cisco IOS Command-Based Switch

To assign an IP address on a 1900/2800 or 2900 XL series switch, enter the following
command in global configuration mode:
Switch(config)ip address ip address netmask
The show ip command displays the IP address and the subnet mask for the device. Example
2-3 shows that the management interface resides in VLAN1 and has a subnet mask of
255.255.0.0.
Example 2-3 Management Interface Resides in VLAN1 and Has a Subnet Mask of 255.255.0.0
Switch#show ip
IP Address: 172.16.1.87
Subnet Mask: 255.255.0.0
Default Gateway: 0.0.0.0
Management VLAN: 1
Domain name:
Name server 1: 0.0.0.0
Name server 2: 0.0.0.0
HTTP server : Enabled
HTTP port : 80
RIP : Enabled
To remove the IP address and subnet mask, enter the no ip address command in global
configuration mode.
Configuring Remote Accessibility on a Set Command-Based Switch

If your switch is set-based, you assign the IP address to the in-band logical interface. To
assign an IP address to this interface, enter the following command in privileged mode:
Switch(enable)set interface sc0 ip address netmask broadcast address
After you define the in-band management IP address, you assign the IP address to its
associated management VLAN. The number of the VLAN must match the subnet number
of the IP address. To associate the in-band logical interface to a specific VLAN, enter the
following command in privileged mode:
Switch(enable)set interface sc0 vlan
If you do not specify a VLAN, the system automatically defaults to VLAN1.

The show interface command displays the IP address and the subnet mask for the device.
Example 2-4 shows that the management interface resides in VLAN1 and has a subnet
mask of 255.255.0.0.
Example 2-4 The Management Interface Resides in VLAN1 and Has a Subnet Mask of 255.255.0.0
Switch(enable)show interface
sl0:flags=51<UP,POINTOPOINT,RUNNING>
slip 0.0.0.0 dest 0.0.0.0
sc0:flags=63<UP,BROADCAST,RUNNING>
vlan 1 inet 172.16.1.144 netmask 255.255.0.0 broadcast 172.16.255.255
Uniquely Identifying Ports

You can add a description to an interface or port to help you remember specific information
about that interface, such as what access- or distribution-layer device the interface services.
This description is meant solely as a comment to help identify how the interface is being
used. The description will appear in the output when you display the configuration
information.
Uniquely Identifying an Interface on a Cisco IOS Command-Based Switch

To add a unique comment to an interface on a 1900/2800 or 2900 XL series switch, enter
the following command in interface configuration mode:
Switch(config-if)#description description string
If you need to enter a description with spaces between characters, you must enclose the
string in quotation marks:
Switch(config-if)#description "PC TO ASW44 PORT"
To clear a description, enter the no description command in interface configuration mode.
Uniquely Identifying a Port on a Set Command-Based Switch

If your access switch is set-based, you assign a description to a port by entering the
following command in privileged mode:
Switch(enable) set port name module/number description
module specifies the target module on which the port resides.

number identifies the specific port.
description describes the specific text string.
The description must be less than 21 alphanumeric characters. Spaces can be entered in the
description without special consideration.
To clear a port name, enter the set port name module/number command, followed by a
carriage return in privileged mode. Because you don’t define a port name, the value for this
parameter is cleared.
Defining Link Speed

The speed of the ports is 10/100 Mbps on a Cisco IOS-based switch, and it cannot be
altered. The Catalyst 1900 series switch has a fixed configuration of 12 or 24 10BaseT and
one or two Fast Ethernet 100BaseTX ports. The Catalyst 2820 series switch has a fixed
configuration of 24 10BaseT ports and two module slots for Fast Ethernet.
Configuring the Port Speed on a Set Command-Based Switch

If your access switch is set-based, enter the following command in privileged mode to
configure the port speed on 10/100 Mbps Fast Ethernet modules:
Switch(enable) set port speed mod-num/port-num [10 | 100 | auto]
mod-num indicates the port’s module number.

port-num indicates the port number.
10, 100, and auto indicate the port’s speed. auto places the port in autonegotiate speed
mode.
NOTE If the port speed is set to auto on a 10/100 Mbps Fast Ethernet port, both speed and duplex
are autonegotiated.
Use the show port command to verify your configuration. Example 2-5 shows that the
10/100 Ethernet module 2 port 4 is connected and is operating at 100 Mbps.
Example 2-5 The 10/100 Ethernet Module 2 Port 4 Is Connected and Is Operating at 100 Mbps
Switch (enable)show port 2/4
Port Name Status Vlan Level Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- ------------
2/4 connected 1 normal full 100 10/100BaseTX
Maximizing Data Transmission

Full duplex is the simultaneous action of transmitting and receiving data by two devices.
This operation can be achieved only if both connected devices support full-duplex mode.
88 Chapter 3: Defining Common Workgroups with VLANs
switched network can even span several buildings. As the size of the Layer 2 switched
network increases, so does the number of packets that each station must process. This
becomes especially difficult if applications are sending large numbers of broadcasts.
Every station must process every broadcast as if it were intended for that station.
• Security—In a Layer 2 environment, there is no easy way to provide security. Users
have the ability to access all devices.
• Managing multiple paths to a destination—Layer 2 switches do not allow for
redundant paths to a destination and are not capable of intelligently load-balancing
traffic.
Switches use VLANs to solve many of the issues of a large Layer 2 environment. VLANs
connected by routers limit the broadcast to the domain of origin, as shown in Figure 3-1.
Figure 3-1 VLANs Establish Broadcast Domains
Broadcast Domain 2
Broadcast Domain 1
A VLAN has the following characteristics:

• All devices in a VLAN are members of the same broadcast domain. If a station
transmits a broadcast, all other members of the VLAN will receive the broadcast. The
broadcast is filtered from all ports or devices that are not members of the same VLAN.
Workgroup servers serve users who operate in a client/server model, and attempts are made
to keep users in the same VLAN as their server to maximize the performance of Layer 2
switching.
In the core, a router allows intersubnet communication. The network is engineered, based
on traffic flow patterns, to have 80 percent of the traffic within a VLAN and 20 percent
crossing the router to the enterprise servers and to the Internet and the WAN.
Local VLANs
As corporations have moved to centralize their resources, end-to-end VLANs have become
more difficult to maintain. Users might use many different resources, including many that
are no longer in their VLAN. Due to this shift in placement and usage of resources, VLANs
are more often created around geographic or local boundaries rather than commonality
boundaries. As you can see in Figure 3-3, local, or geographic, VLANs are limited to a
physical location.
Figure 3-3 Local or Geographic VLANs

VLANs 93
This geographic location can be as large as an entire building or as small as a single switch
inside a wiring closet. In a geographic VLAN structure, it is typical to find 80 percent of
the traffic remote to the user (server farms and so on) and 20 percent of the traffic local to
the user (local server, printers, and so on). Although this topology means that the user must
cross a Layer 3 device in order to reach 80 percent of the resources, this design allows the
network to provide for a deterministic, consistent method of getting to resources.
Geographic VLANs are also easier to manage and conceptualize than VLANs that span
different geographic areas.
Establishing VLAN Memberships

This section describes VLAN membership characteristics and shows you how to establish
VLAN membership. The two common approaches to assigning VLAN membership are as
follows:
• Static VLANs—This method is also called port-based membership. Static VLAN
assignments are created by assigning a port to a VLAN. As a device enters the
network, it automatically assumes the port’s VLAN. If the user changes ports and
needs access to the same VLAN, the network administrator must manually make a
port-to-VLAN assignment for the new connection.
• Dynamic VLANs—Dynamic VLANs are created through the use of CiscoWorks
2000 or CiscoWorks for Switched Internetworks (CWSI). Dynamic VLANs currently
allow for membership based on the device’s MAC address. As a device enters the
network, it queries a database for VLAN membership.
NOTE Dynamic VLANs are not covered as part of this course and book. Dynamic VLANs are
covered in the Managing Cisco Switched Internetworks (MCSI) course.
Membership by Ports
In port-based VLAN membership, the port is assigned to a specific VLAN independent of
the user or system attached to the port. The network administrator typically performs the
VLAN assignment. The port cannot be automatically changed to another VLAN without
manual intervention. As you can see in Figure 3-4, all users of the same port must be in the
same VLAN.
• Do not enter spaces between the port numbers. Doing so would generate an error
message from the system, because it interprets spaces as separators for arguments.
VLAN Identification
In a traditional Ethernet environment, an interface or cable segment could be a member of
only one subnet. Switches change this paradigm by allowing multiple VLANs to exist on
the same switch and by allowing those VLANs to span to other switches. Each connection
from switch to switch or switch to router must be able to carry traffic from different
VLANs. The traditional Ethernet frame did not allow for an identification of the VLAN or
subnet because it was assumed that this information would be carried in the Layer 3 portion
of the packet.
In a campus network, users can be assigned to VLAN groups that span multiple connected
switches. In this environment, a method by which switches identify frames belonging to a
specific VLAN can direct those frames to the appropriate port.
Frame identification (frame tagging) uniquely assigns a user-defined ID, sometimes
referred to as a VLAN ID or color, to each frame.
VLAN frame identification has been specifically developed for switched communications.
VLAN frame identification places a unique identifier in the header of each frame as it is
forwarded through the switch fabric on trunk links. Each switch examines this frame
identifier to determine the frame’s VLAN. Based on the VLAN identifier, the switch can
make the appropriate decision to broadcast or transmit to other ports in this VLAN.
This section covers the different link types available on a switch, as well as the methods of
identifying VLANs on physical links.
Link Types
There are two types of links in a switch environment: access and trunk. This section
examines the differences between the two link types and also discusses a special link state
called a hybrid link.
Access Links
An access link is a member of only one VLAN. This VLAN is called the port’s native
VLAN. The device that is attached to the port is completely unaware that a VLAN exists.
The device simply assumes that it is part of a network or subnet based on the Layer 3
information that is configured on the device. In order to ensure that it does not have to
understand that a VLAN exists, the switch is responsible for removing any VLAN
information from the frame before it is sent to the end device.
VLAN Identification 97
An access link is a port that belongs to one, and only one, VLAN. The port can’t receive
information from another VLAN unless the information has been routed. The port can’t
send information to another VLAN unless the port has access to a router.
Trunk Links
A trunk link can carry multiple VLANs. A trunk link gets its name from the trunks of the
telephone system, which can carry multiple telephone conversations. Trunk links are
typically used to connect switches to other switches, or switches to routers. Cisco supports
trunk lists on Fast Ethernet and Gigabit Ethernet ports.
The switch must have some way to identify which VLAN a frame belongs to when the
VLAN receives the frame on a trunk link. The identification techniques currently used are
as follows:
• Cisco Inter-Switch Link (ISL)
• IEEE 802.1Q standard
Both of these identification methods are covered later in this section.
A trunk link does not belong to a specific VLAN; rather, a trunk link transports VLANs
between devices. The trunk link can be configured to transport all VLANs, or it can be
limited to transporting a limited number of VLANs.
A trunk link can, however, have a native VLAN. The trunk’s native VLAN is the VLAN that
the trunk uses if the trunk link fails for any reason.
NOTE Trunking capabilities are hardware-dependent. For example, the Catalyst 4000 series
switch modules support only 802.1Q encapsulation. To determine whether your hardware
supports trunking, and to determine which trunking encapsulations are supported, see your
hardware documentation, or use the show port capabilities command.
Figure 3-5 shows that VLAN identification adds VLAN information to trunk links and
removes VLAN information from access links. In Figure 3-5, Port A and Port B have been
defined as access links on the same VLAN. By definition, they can belong to only this one
VLAN and cannot receive frames with a VLAN identifier. As Switch Y receives traffic from
Port A destined for Port B, Switch Y will not add an ISL encapsulation to the frame.
VLAN Frame Identification Methods

VLAN identification logically identifies which packets belong to which VLAN group.
Cisco supports multiple trunking methodologies:
• Inter-Switch Link (ISL)—A Cisco proprietary encapsulation protocol for
interconnecting multiple switches. This protocol is supported in Catalyst switches
and routers.
• IEEE 802.1Q—An IEEE standard method for identifying VLANs by inserting a
VLAN identifier into the frame header. This process is called frame tagging.
• LAN Emulation (LANE)—An IEEE standard method for transporting VLANs over
Asynchronous Transfer Mode (ATM) networks.
• 802.10—A Cisco proprietary method of transporting VLAN information inside the
standard 802.10 frame (Fiber Distributed Data Interface [FDDI]). The VLAN
information is written to the Security Association Identifier (SAID) portion of the
802.10 frame. This method is typically used to transport VLANs across FDDI
backbones.
NOTE This chapter discusses ISL and 802.1Q methods of VLAN identification only.
Table 3-1 summarizes frame tagging methods and encapsulation. The VLAN identification
options of ISL and 802.1Q are discussed in more detail in the following sections.
Table 3-1 Frame Tagging and Encapsulation Methods
Identification Tagging (Insertion
Method Encapsulation into Frame) Media
802.1Q No Yes Ethernet
ISL Yes No Ethernet
802.10 No No FDDI
LANE No No ATM
ISL
The ISL protocol is a way to multiplex VLANs over a trunk link through the use of an
encapsulation around the frame.
ISL is a Cisco proprietary protocol for interconnecting multiple switches and maintaining
VLAN information as traffic travels between switches on trunk links.
ISL is made up of three major components: a header, the original Ethernet frame, and a
frame check sequence (FCS) at the end. With ISL, an Ethernet frame is encapsulated with
a header that transports VLAN IDs between switches and routers. The 26-byte header
containing a 10-bit VLAN ID is added to each frame. In addition, a 4-byte tail is added to
the frame to perform a cyclic redundancy check (CRC). This CRC is in addition to any
frame checking that the Ethernet frame performs. Figure 3-6 shows the ISL frame.
Figure 3-6 The ISL Frame Identification Technique Adds 30 Bytes to the Standard Ethernet Frame
26-byte ISL Header 4-byte CRC
DA SA Ethertype/Length Data FCS
DA = Destination Address
SA = Source Address
FCS = Frame Cheric Sequence
A VLAN ID is added only if the frame is forwarded out a port configured as a trunk link.
If the frame is to be forwarded out a port configured as an access link, the ISL encapsulation
is removed.
Figure 3-6 shows the 30 additional bytes added to the Ethernet frame by the ISL
encapsulation. It is important to note that the Ethernet frame is not modified in any way.
The FCS at the end of the ISL encapsulation in Figure 3-7 is in addition to the original FCS
of the Ethernet frame.
Figure 3-7 ISL Frame Format—Shaded Areas Indicate ISL Tag Fields
40 4 4 48 16 24 24 15 1 16 16 Variable length 32
bits bits bits bits bits bits bits bits bit bits bits bits
DA TYPE USER SA LEN SNAP/ HSA VLAN BPDU/ INDX Reserved Encapsulated Frame FCS
LLC ID CDP (CRC)
The fields of ISL encapsulation in Figure 3-7 are explained as follows:

• Destination address (DA)—The address is a multicast address and is currently set for
01.00.0c.00.00. The first 40 bits of the destination address signal the receiver that this
is an ISL frame.
• Frame type (TYPE)—The TYPE field indicates the type of frame that is
encapsulated and can be used in the future to indicate different encapsulation types.
The following type codes have been defined:
— 0000—Ethernet
— 0001—Token Ring
— 0010—FDDI
— 0011—ATM
• Index (INDX)—The INDX field indicates the port index of the source of the packet
as it exits the switch. It is used for diagnostic purposes only and may be set to any
value by other devices. It is a 16-bit value and is ignored in received packets.
• Reserved for FDDI and Token Ring—The RES field is used when Token Ring or
FDDI packets are encapsulated with an ISL packet. In the case of Token Ring frames,
the address copied (AC) and frame copied (FC) fields are placed here. In the case of
FDDI, the FC field is placed in the least-significant byte of this field (for example, an
FC of 0x12 would have a RES field of 0x0012). For Ethernet packets, the RES field
should be set to all 0s.
• Encapsulated Frame—The ENCAP FRAME is the encapsulated frame, including
its own CRC value, completely unmodified. The internal frame must have a CRC
value that is valid after the ISL encapsulation fields are removed. The length of this
field can be from 1 to 24,575 bytes to accommodate Ethernet, Token Ring, and FDDI
frames. A receiving switch can strip off the ISL encapsulation fields and use this
ENCAP FRAME as the frame is received, associating the appropriate VLAN and
other values with the received frame for switching purposes.
• Frame Check Sequence (FCS)—The CRC is a standard 32-bit CRC value calculated
on the entire encapsulated frame from the DA field to the ENCAP FRAME field. The
receiving MAC checks this CRC and can discard packets that do not have a valid
CRC. Note that this CRC is in addition to the one at the end of the ENCAP FRAME
field.
NOTE The ISL frame encapsulation is 30 bytes, and the minimum FDDI packet is 17 bytes, so the
minimum ISL encapsulated packet is 47 bytes. The maximum Token Ring packet is 18,000
bytes, so the maximum ISL packet is 18,030 bytes.
If only Ethernet packets are encapsulated, the range of ISL frame sizes is from 94 to 1548
bytes.
IEEE 802.1Q
The official name of the IEEE 802.1Q protocol is Standard for Virtual Bridged Local-Area
Networks. This refers to the ability to carry the traffic of more than one subnet down a
single cable.
The IEEE 802.1Q frame-tagging format provides a standard method for identifying frames
that belong to particular VLANs. This format helps ensure interoperability of multiple
vendor VLAN implementations. The IEEE 802.1Q standard defines the following:
• An architecture for VLANs
• Services provided in VLANs
• Protocols and algorithms involved in the provision of those services
As Figure 3-8 indicates, frame identification with 802.1Q involves the addition of 4 bytes
to the standard Ethernet frame.
Figure 3-8 Frame Identification with 802.1Q
Initial MAC 2-Byte TPID

Initial Type/Data New CRC
Address 2-Byte TCI
This 4-byte tag header contains the following:

• 2-byte Tag Protocol Identifier (TPID)—Contains a fixed value of 0x8100. This
particular TPID value indicates that the frame carries the 802.1Q/802.1p tag
information.
• 2-byte Tag Control Information (TCI)—Contains the following elements:
— 3-bit user_priority—This field allows the tagged frame to carry
user_priority information across bridged LANs. The 3-bit value is
interpreted as a binary number that can represent eight priority levels,
0 through 7. This field is used primarily by the 802.1p standard.
— 1-bit Canonical Format Indicator (CFI)—A CFI value of 0 indicates
canonical format; a value of 1 indicates noncanonical format. It is used in
Token Ring/Source-Routed FDDI media access methods to signal the bit
order of address information carried in the encapsulated frame.
— 12-bit VLAN Identifier (VID)—This field uniquely identifies the VLAN
to which the frame belongs. VID can uniquely define 4096 VLANs.
However, VLANs 0 and 4095 are reserved. This field is used primarily by
the 802.1Q standard. The current Cisco default for VLANs supports less
than the maximum range of VLANs supported by 802.1Q.
Both ISL and IEEE 802.1Q tagging are explicit tagging, meaning that the frame is tagged
with VLAN information explicitly.
The tagging mechanisms are quite different, however. IEEE 802.1Q uses an internal
tagging process that modifies the existing Ethernet frame with the VLAN identification.
This allows the 802.1Q frame identification process to work on both access links and trunk
links as the frame appears to be a standard Ethernet frame.
ISL uses an external tagging process. With ISL external tagging, the original frame is not
altered but is encapsulated with a new 26-byte ISL header (tag), and a new, extra 4-byte
FCS is appended at the end of the frame. This means that only ISL-aware devices are
capable of interpreting the frame. It also means that the frame can violate normal Ethernet
conventions such as the maximum transmission unit size of 1518 bytes.
NOTE Original Ethernet frames cannot exceed 1518 bytes. If a frame of the maximum size is
tagged with 802.1Q, the resulting frame will be 1522 bytes. This frame is called a baby
giant frame. The switch processes this frame successfully, although the switch might record
it as an Ethernet error.
Trunk Negotiation
A trunk is a point-to-point link between two Catalyst switch ports, or between a Catalyst
switch and a router. Trunks carry the traffic of multiple VLANs and allow you to extend
VLANs from one Catalyst switch to another.
The Dynamic Trunking Protocol (DTP) manages trunk negotiation in Catalyst supervisor
engine software release 4.2 and later. DTP supports autonegotiation of both ISL and IEEE
802.1Q trunks.
In prior releases, trunk negotiation was managed by the Dynamic Inter-Switch Link (DISL)
protocol. DISL supports autonegotiation of ISL trunks only. In supervisor engine software
release 4.1, you must manually configure IEEE 802.1Q trunks on both ends of the link.
IEEE 802.1Q trunks were not supported prior to software release 4.1.
NOTE For trunking to be autonegotiated on Fast Ethernet and Gigabit Ethernet ports, the ports
must be in the same VTP domain. However, you can use on or nonegotiate mode to force a
port to become a trunk, even if it is in a different domain.
During trunk negotiation, the port doesn’t participate in Spanning-Tree Protocol.
NOTE DTP is a point-to-point protocol. However, some internetworking devices might forward
DTP frames improperly. To avoid this problem, ensure that trunking is turned off on ports
connected to nonswitch devices if you do not intend to trunk across those links. When
manually enabling a trunk on a link to a Cisco router, use the nonegotiate keyword of the
set trunk command. This command allows the link to become a trunk, but it does not
generate DTP frames. This keyword is discussed in the next section.
Configuring a Trunk Link

To create or configure a VLAN trunk, enter the set trunk command to configure the port
on each end of the link as a trunk port and to identify the VLANs that will be transported
on this trunk link. You can also enter the set trunk command to change a trunk’s mode.
The command syntax is as follows:
Switch (enable) set trunk mod_num/port_num [on | off | desirable | auto |
..nonegotiate] vlan_range [isl | dot1q | dot10 | lane | negotiate]
Fast Ethernet and Gigabit Ethernet trunking modes are as follows:

• on—Puts the port into permanent trunking. The port becomes a trunk port even if the
neighboring port does not agree to the change. The on state does not allow for the
negotiation of an encapsulation type. You must, therefore, specify the encapsulation
in the configuration.
• off—Puts the port into permanent nontrunking mode and negotiates to convert the link
into a nontrunk link. The port becomes a nontrunk port even if the neighboring port
does not agree to the change.
• desirable—Makes the port actively attempt to convert the link to a trunk link. The
port becomes a trunk port if the neighboring port is set to on, desirable, or auto mode.
• auto—Makes the port willing to convert the link to a trunk link. The port becomes a
trunk port if the neighboring port is set to on or desirable mode. This is the default
mode for Fast and Gigabit Ethernet ports. Notice that if the default setting is left on
both sides of the trunk link, it will never become a trunk. Neither side will be the first
to ask to convert to a trunk.
• nonegotiate—Puts the port into permanent trunking mode, but prevents the port from
generating DTP frames. You must configure the neighboring port manually as a trunk
port to establish a trunk link.
Clearing VLANs from a Trunk Link

By default, all VLANs are transported across a trunk link when you issue the set
trunk_command. However, there might be instances in which the trunk link should not
carry all VLANs, such as the following:
• Broadcast suppression—All broadcasts must be sent to every port in a VLAN.
A trunk link acts as a member port of the VLAN and, therefore, must pass all the
broadcasts. Bandwidth and processing time are wasted if there is no port at the other
end of the trunk link that is a member of that VLAN.
• Topology change—Changes that occur in the topology must also be propagated
across the trunk link. If the VLAN is not used on the other end of the trunk link, there
is no need for the overhead of a topology change.
NOTE More information about topology change characteristics can be found in Chapter 4.
In order to remove a VLAN from a trunk link, use the following command:
Switch (enable) clear trunk mod_num/port_num vlan_range
If you want to remove many VLANs from the trunk link, it might be easier to clear all
VLANs from the trunk link first, and then set just the VLANs that are supposed to be on
the link.
NOTE When you issue the set trunk command, VLANs 1 to 1000 are automatically transported,
even if you specify a VLAN range. In order to limit VLANs on the trunk link, you must
clear the VLANs from the link.
Verifying Trunk Link Configuration

Verify the trunking configuration by entering in privileged mode the show trunk
[mod_num/port_num] command.
Example 3-2 shows how to verify the trunk configuration on a Catalyst 5xxx switch.
This example assumes that the neighbor port is in auto mode.
Example 3-2 The show trunk Command Verifies Trunk Configuration on Catalyst 5000 Series Switches
switch (enable) show trunk 1/1
Port Mode Encapsulation Status Native vlan
-------- ----------- ------------- ------------ -----------
1/1 desirable isl trunking 1
Port Vlans allowed on trunk
-------- ------------------------------------------------------------------
1/1 1-100,250,500-1005
Port Vlans allowed and active in management domain
-------- ------------------------------------------------------------------
1/1 1,521-524
Port Vlans in spanning tree forwarding state and not pruned
-------- ------------------------------------------------------------------
1/1 1,521-524
VLAN Trunking Protocol

In order to manage all the VLANs across the campus network, Cisco created the VLAN
Trunking Protocol (VTP). VTP maintains VLAN configuration consistency throughout the
network. VTP is a messaging protocol that uses Layer 2 trunk frames in order to manage
the addition, deletion, and renaming of VLANs on a network-wide basis. VTP also allows
you to make centralized changes that are communicated to all other switches in the
network.
VLAN Trunking Protocol 107
VTP minimizes the possible configuration inconsistencies that arise when changes are
made. These inconsistencies result in security violations, because VLANs cross-connect
when duplicate names are used and could become internally disconnected when VLANs
are mapped from one LAN type to another (for example, Ethernet to ATM or FDDI).
VTP provides the following benefits:
• VLAN configuration consistency across the network
• Mapping scheme for going across mixed-media backbones to map Ethernet VLANs
to a high-speed backbone VLAN such as ATM LANE or FDDI, allowing a VLAN to
be trunked over mixed media
• Accurate tracking and monitoring of VLANs
• Dynamic reporting of added VLANs across the network
• “Plug-and-play” configuration when adding new VLANs
In order for VLANs to be created on a switch, you must first set up a VTP management
domain so that it can verify the current VLANs on the network. All switches in the same
management domain share their VLAN information, and a switch can participate in only
one VTP management domain. Switches in different domains do not share VTP
information.
Using VTP, each Catalyst family switch advertises the following on its trunk ports:
• Management domain
• Configuration revision number
• Known VLANs and their specific parameters
VTP Operation
A VTP domain is made up of one or more interconnected devices that share the same VTP
domain name. A switch can be configured to be in one VTP domain only. Global VLAN
information is propagated by way of connected switch trunk ports.
Switches can be configured not to accept VTP information. These switches will forward
VTP information on trunk ports in order to ensure that other switches receive the update,
but the switches will not modify their database, nor will they send out an update indicating
a change in VLAN status. This is called transparent mode.
By default, management domains are set to a nonsecure mode without a password. Adding
a password sets the management domain to secure mode. A password must be configured
on every switch in the management domain before secure mode can be used.
Detecting the addition of VLANs within the advertisements acts as a notification to the
switches (servers and clients) that they should be prepared to receive traffic on their trunk
ports with the newly defined VLAN IDs, emulated LAN names, and 802.10 SAIDs.
TIP The behavior of the configuration revision number in VTP appears to vary from release to
release of the set command-line interface. It is recommended that you test its behavior on
your switches in order to ensure that VTP does not cause problems on your network. Some
versions reset the configuration revision number on cold boot, but the latest versions appear
not to. Earlier releases did not reset the configuration revision number with the issuance of
a clear config all command, but the newest releases appear to do so. It appears that Cisco
is modifying the behavior of the configuration revision number in order to address issues
with its behavior.
VTP Modes of Operation

You can configure a Catalyst family switch to operate in any of the following VTP modes:
• Server—In VTP server mode, you can create, modify, and delete VLANs, as well as
specify other configuration parameters (such as VTP version and VTP pruning) for the
entire VTP domain. VTP servers advertise their VLAN configuration to other
switches in the same VTP domain and synchronize the VLAN configuration with
other switches based on advertisements received over trunk links. VTP server is the
default mode.
• Client—VTP clients behave the same way as VTP servers, but you cannot create,
change, or delete VLANs on a VTP client.
• Transparent—VTP transparent switches do not participate in VTP. A VTP
transparent switch does not advertise its VLAN configuration and does not
synchronize its VLAN configuration based on received advertisements. However,
in VTP version 2, transparent switches do forward received VTP advertisements
out their trunk ports.
Adding a Switch to an Existing Domain

Use caution when inserting a new switch into an existing domain. In order to prepare a
switch to enter an existing VTP domain, follow these steps:
Step 1 Issue a clear config all command to remove the existing configuration.
This will not clear the VTP configuration revision number.
Step 2 Power-cycle the switch to clear the VTP NVRAM. This will reset the
configuration revision number to 0, ensuring that the new switch will not
propagate the incorrect information.
Step 3 Determine the switch’s VTP mode of operation and include the mode
when setting the VTP domain information on the switch. The most
common default for switches is server mode. If you leave the switch in
to use. A higher configuration revision number means that the current database on the
switch will be overwritten with the database that has the highest configuration revision
number. This process does not care what kind of switch advertised the higher configuration
revision number. It could be a client device that advertises the higher number. This occurs
most frequently when a switch has been configured as a server outside of the production
network and then was inserted into the production network as a client. If it has a higher
configuration revision number than the current number of the VTP domain, the database of
the new client will overwrite the database of the existing servers and clients in the VTP
domain.
Also note that two databases with the same configuration number will not update each
other, because they assume that they both contain the same information.
VTP Configuration Tasks and Guidelines

Before you configure VTP and VLANs on your network, you must make several decisions.
This section discusses the guidelines for making those decisions and covers the
configuration commands to implement VTP.
The following list outlines the basic tasks that you must consider before you configure VTP
and VLANs on your network:
1 Determine the version number of VTP that will be running in your environment.
2 Decide if this switch is to be a member of an existing management domain or if a new
domain should be created. If a management domain does exist, determine its name
and password.
3 Choose a VTP mode for the switch.
Choosing a VTP Version

Two different versions of VTP can run in your management domain: VTP version 1 and
VTP version 2. These two versions are not interoperable. If you choose to configure a
switch in a domain for VTP version 2, you must configure all switches in the management
domain to be in VTP version 2. VTP version 1 is the default. You might need to implement
VTP version 2 if you need some of the specific features that VTP version 2 offers that are
not offered in VTP version 1. The most common feature that is needed is Token Ring VLAN
support.
Use the set vtp v2 enable command to change the VTP version number.
VTP version 2 supports the following features that are not supported in version 1:
• Token Ring support—VTP version 2 supports Token Ring LAN switching and
VLANs.
If this is the first Catalyst switch in your management domain, and you intend to add more
switches, set the mode to server. The additional switches will be able to learn VLAN
information from this switch. You should have at least one server.
If there are any other Catalyst switches in the management domain, set your switch mode
to client and power off the switch. This will prevent the new switch from accidentally
propagating the incorrect information to your existing network. If you would like this
switch to end up as a VTP server, change the switch’s mode to server after it has learned the
correct VLAN information from the network.
If the switch won’t share VLAN information with any other switch on the network, set the
switch to transparent mode. This will allow you to create, delete, and rename VLANs, but
the switch will not propagate changes to other switches. If many people are configuring
your environment, you run the risk of creating overlapping VLANs that have two different
meanings in the network but the same VLAN identification.
To set the correct mode of your switch, use the following command:
Switch (enable) set vtp domain domain-name mode [server | client | transparent]
NOTE The domain name used in this command is the same as the domain name and password that
you configured before. You can issue all the options in one command, such as set vtp
domain domain-name password password mode mode v2 enable.
It is generally recommended that there be at least two VTP servers and that the rest of the
switches be VTP clients. Be aware that if the client loses power, it must contact the server
to get VLAN information. If the server is not available due to power outages or a slow boot
process, the client might not receive VLAN information. This means that the client switch
will only know about VLAN 1, and all ports in VLANs other than VLAN 1 will be placed
in an inactive state.
Verifying VTP Configuration

The following is an example of the set vtp domain command to change the local VTP
mode to server:
switch (enable) set vtp domain bcmsn_block2 mode server
VTP domain bcmsn_block2 has been modified.
Example 3-3 shows a show vtp domain command example for the previous configuration.
Example 3-3 show vtp domain Command Example
switch (enable) show vtp domain
Domain Name Domain Index VTP Version Local Mode Password
-------------- ------------ ---------------- ----------- --------
bcmsn_block2 1 2 server -
Vlan-count Max-vlan-storage Config Revision Notifications
Example 3-3 show vtp domain Command Example (Continued)

---------- ---------------- --------------- -------------
33 1023 0 disabled
Last Updater V2 Mode Pruning PruneEligible on Vlans
--------------- -------- -------- -------------------------
172.20.52.124 disabled disabled 2-1000
NOTE The show vtp domain command is very useful for verifying the current configuration
revision number.
Another useful command for troubleshooting VTP is the show vtp statistics command.
This command shows a summary of VTP advertisement messages sent and received, as
well as configuration errors detected. Example 3-4 displays sample output from the show
vtp statistics command.
Example 3-4 The show vtp statistics Command Displays a Summary of VTP Advertisement Traffic and Detects
Configuration Errors
switch (enable) show vtp statistics
VTP statistics:
summary advts received 0
subset advts received 0
request advts received 0
summary advts transmitted 0
subset advts transmitted 0
request advts transmitted 10
No of config revision errors 0
No of config digest errors 0
To reset the values displayed with the show vtp statistics command, use the clear vtp
statistics command:
switch (enable) clear vtp statistics
vtp statistics cleared
VTP Pruning
By default, broadcasts for a VLAN are sent to every switch that has a trunk link that carries
that VLAN. This happens even if the switch has no ports in that VLAN. This process means
that trunk links will carry broadcast traffic that will ultimately be discarded by the switch.
VTP pruning enhances network bandwidth use by reducing unnecessary flooded traffic,
such as broadcast, multicast, unknown, and flooded unicast packets. VTP pruning increases
available bandwidth by restricting flooded traffic to those trunk links that the traffic must
use to access the appropriate network devices. This means that it restricts broadcasts,
CHAPTER
4
Managing Redundant Links

Businesses today increasingly rely on data networks to deliver services required for their
operations. Services such as inventory control, accounts receivable and payable, order
processing, and the many other aspects of running a business efficiently all rely on data
networks. The need for timely and accurate data is driving the demand for high network
availability and reliability.
This chapter discusses techniques and technologies within a campus network that are
targeted at increased network reliability. This chapter covers the operation, configuration,
and verification of the Spanning-Tree Protocol. In addition, this chapter presents
technologies associated with scaling the Spanning-Tree Protocol and campus redundancy.
This chapter covers the following:
• Overview of transparent bridging
• Introduction to the Spanning-Tree Protocol
• VLANs and Spanning Tree
• Scaling Spanning Tree in the campus network
Upon completion of this chapter, you will be able to perform the following tasks in a Layer
2 switch environment: Determine the default Spanning Tree in a network topology, improve
Spanning Tree convergence using the UplinkFast protocol, ensure timely host access to the
network in a Spanning Tree environment using the PortFast protocol, and distribute the
traffic load on parallel links with Fast EtherChannel.
Overview of Transparent Bridging

The basic functionality of a switch is identical to that of a transparent bridge. A switch
implements many of the same technologies as a transparent bridge, including the Spanning-
Tree Protocol. In order to understand the Spanning-Tree Protocol in a switch, you must first
look at the behavior of a transparent bridge without Spanning Tree.
132 Chapter 4: Managing Redundant Links
By definition, a transparent bridge must do the following:

• The bridge must not modify frames that it forwards.
• The bridge learns addresses by listening on a port for a device’s source MAC address.
If a source address comes in a specific port, it is learned that the source address can
be found at that port. The bridge then builds a table indicating that it can reach the
source by sending out the port it just learned. A bridge is always listening and
learning.
• A bridge must forward the broadcasts it receives out all ports except for the port that
initially received the broadcast.
• If a destination MAC address is unknown, sometimes called an unknown unicast, the
bridge forwards the frame out all ports except for the port that initially received the
frame.
• When a bridge receives a frame, it either filters it if the frame’s destination is out the
receiving port or forwards the frame if the destination is on a different port.
In Figure 4-1, the bridge learns the location of Station A and Station B by listening to the
source address of their respective frames. The bridge then builds a table with the source
MAC address and the port it learned for that MAC address. This table is called a CAM
(content-addressable memory) table in a Cisco switch. When Station A transmits to Station
B, the switch looks up the destination MAC address in its CAM table. It then forwards the
frame out the correct port.
Figure 4-1 A Transparent Bridge
Station A
Segment A
1/1
1/2
Segment B
Station B
Transparent bridging by definition should be transparent to the devices on the network. It

therefore should not make any modifications to the frame as it passes through the bridge.
Segment B. In addition, each switch sees another frame that needs to be

forwarded without realizing that it is looking at the same frame it just
transmitted.
Step 3 The packet is then forwarded again to Segment A, where the frame
originated. The network now sees the beginning of a loop. Because
neither switch is aware of the other, each switch continually forwards the
frame on the other port. This loop goes on forever. The loop manifests
itself as the ability to get to Station A and Station B some of the time.
Some of the time, the information the switch has learned is correct, and
the frame makes it to the destination. Other times, the switch is incorrect
about its frame’s destination, and it is sent in the completely wrong
direction.
Notice that if Station A originally sent a broadcast, this problem would actually be much
worse than just getting a bridging loop. The two behaviors of always retransmitting a
broadcast and never marking the frame mean that the bridges actually create broadcasts in
an exponential fashion when a bridge loop occurs. This process of creating new broadcasts
does not stop until the loop is shut down. Eventually, in a broadcast-intensive network, the
bridging loop effectively brings down the network through a broadcast storm.
NOTE Switches typically hit a processor utilization of 80 to 100 percent during a bridge loop.
Bridge loops also adversely affect routers, because these devices must also deal with the
broadcasts created during a bridge loop.
Introduction to the Spanning-Tree Protocol

The Spanning-Tree Protocol (STP) was created to overcome the problems of transparent
bridging in redundant networks. The purpose of STP is to avoid and eliminate loops in the
network by negotiating a loop-free path through a root bridge, as shown in Figure 4-3. It
does this by determining where there are loops in the network and blocking links that are
redundant. In this way, it ensures that there will be only one path to every destination, so a
bridging loop could never occur. In the case of a link failure, the root bridge would know
that a redundant link existed and would bring up the link it previously shut down.
This means that some ports will need to be disabled or put into a nonforwarding mode.
The ports remain aware of the network’s topology and can be enabled if the link that is
forwarding data ever fails.
Introduction to the Spanning-Tree Protocol 135
Figure 4-3 A Loop-Free Path Traced to the Root Bridge
Station A
Segment A Root Bridge

1/1 2/1
1/2 2/2
Segment B
Station B
The Spanning-Tree Protocol executes an algorithm called the Spanning-Tree Algorithm

(STA). In order to find the redundant links, the STA chooses a reference point, called a root
bridge, in the network and then determines the available paths to that reference point. If it
finds a redundant path, it chooses for the best path to forward and for all other redundant
paths to block. This effectively severs the redundant links within the network.
To provide path redundancy, STP defines a tree that spans all switches in a subnet. STP
forces certain redundant data paths into a standby (blocked) state (as indicated by the
blocked paths in Figure 4-3). If one of the network segments in the Spanning Tree becomes
unreachable, the Spanning-Tree Algorithm reconfigures the Spanning Tree topology and
reestablishes the link by activating a standby path.
Bridge Protocol Data Units

All switches in an extended LAN participating in STP gather information on other switches
in the network through an exchange of data messages. These messages are referred to as
Bridge Protocol Data Units (BPDUs). A BPDU is shown in Figure 4-4. The left column
indicates the number of bytes for each field, and the right column indicates the contents of
the field.
Figure 4-4 The BPDU Allows All Switches to Build the Spanning Tree
Number of Bytes Field Contents

2 Protocol ID
1 Version
1 Message Type
1 Flags (Including Topology Change)
2 Root Priority
6 Root ID
4 Path Cost
2 Bridge Priority
6 Bridge ID
1 Port Priority
1 Port ID
2 Message Age
2 Max Age
2 Hello Timer
2 Fwd Delay
BPDUs are sent out every two seconds on every port in order to ensure a stable, loop-free
topology.
The Spanning-Tree Protocol uses each of the BPDU’s fields. Each field will be discussed
more in depth as we discuss the behavior of Spanning Tree. The following is an overview
of the contents of the BPDU:
• Root information—The root information consists of a 2-byte root priority and a 6-
byte root ID. The combination of this information indicates the device that has been
elected to be the root bridge.
• Path cost—The path cost indicates how far from the root bridge this BPDU traveled.
The path cost is used to determine which ports will forward and which ports will
block.
• Bridge information—This is information on the bridge that sent the BPDU. It is used
to indicate the neighbor bridge that sent the BPDU as well as the designated bridge
that will be used to get to the root bridge. Bridge information consists of the bridge
priority and bridge ID.
• Port information—The port information is comprised of a 1-byte port priority and a
1-byte port ID. The port information indicates information about the port that
transmitted the BPDU. It is used to help determine which ports will forward and
which will block.
• Timers—Timers are used to indicate how long Spanning Tree takes to perform each
of its functions. These include message age, max age, hello, and fwd delay. Each of
these timers is discussed in greater detail later in this chapter.
This exchange of BPDU messages results in the following:
• The election of a root switch for the stable Spanning-Tree network topology
• The election of a designated switch for every switched segment
• The removal of loops in the switched network by placing redundant switch ports in a
backup state
Electing a Root Bridge

The first step in creating the loop-free Spanning Tree is to elect a root bridge. The root
bridge is the reference point that all switches use to determine whether there are loops in
the network.
At startup, the switch assumes that it is the root bridge and sets the bridge ID equal to the
root ID. The bridge ID consists of two components:
• A 2-byte priority—The switch sets this number. By default, it is the same for all
switches. The default priority on Cisco switches is 32,768 or 0x8000.
• A 6-byte MAC address—This is the MAC address of the switch or bridge.
The combination of these two numbers determines who will become the root bridge. The
lower the number, the more likely it is that this switch will become the root. If a switch sees
a root ID that is lower than its own, it begins to advertise that root ID in its BPDUs. By
exchanging BPDUs, the switches determine which is the root bridge.
The combination of the priority and the bridge ID might look like this:
80.00.00.00.0c.12.34.56
The first two bytes are the priority. The last six bytes are the switch’s MAC address.
Note that if all devices have the same priority, the bridge with the lowest MAC address
becomes the root bridge. The lower the priority, the more likely it is that the bridge will
become the root bridge.
Forming an Association with the Root Bridge

After the root bridge has been elected, each switch must form an association with the root
bridge. It does this by listening to BPDUs as they come in on all ports. Receiving BPDUs
on multiple ports indicates that it has a redundant path to the root bridge.
The result of the BPDU exchange is as follows:

• One switch is elected to be the root switch.
• The shortest distance to the root switch is calculated for each switch.
• A designated switch is selected. This is the switch closest to the root switch through
which frames will be forwarded to the root. A designated switch is sometimes called
a parent switch.
• A root port for each switch is selected. This is the port that provides the best path from
the switch to the root switch (usually the lowest-cost path).
• Ports that will not be forwarding are placed in a blocked state. These ports will
continue to send and receive BPDU information but will not be allowed to send or
receive data.
Now that the basic process of the Spanning-Tree Protocol has been explained, the next
section examines the various states through which the switch transitions as it builds a stable,
loop-free network.
Spanning-Tree Port States

In order to build a loop-free network, Spanning Tree forces each port to transition through
several different states:
• Blocked—All ports start in blocked mode in order to prevent the bridge from creating
a bridging loop. The port stays in a blocked state if Spanning Tree determines that
there is a better path to the root bridge.
• Listen—The port transitions from the blocked state to the listen state. It uses this time
to attempt to learn whether there are any other paths to the root bridge. During the
listen state, the port can listen to frames but cannot send or receive data. The port is
also not allowed to put any of the information it hears into its address table. The listen
state is really used to indicate that the port is getting ready to transmit but that it would
like to listen for just a little longer to make sure it does not create a loop. The switch
listens for a period of time called the fwd delay (forward delay).
• Learn—The learn state is very similar to the listen state, except that the port can add
information it has learned to its address table. It is still not allowed to send or receive
data. The switch learns for a period of time called the fwd delay.
• Forward—This state means that the port can send and receive data. A port is not
placed in a forwarding state unless there are no redundant links or it is determined that
it has the best path to the root.
• Disabled—The switch can disable a port for a variety of reasons. These include
problems such as hardware failure, the deletion of the port’s native VLAN, and being
administratively disabled.
NOTE In later versions of the Catalyst 5000 set command-line interface, there is a distinction
between “disable” and “disabled.” “Disable” means that the switch has disabled the port.
“Disabled” means that the port is administratively disabled.
If the VLAN that is assigned to a port is deleted, the port is disabled. The port is enabled if
it is assigned to a valid VLAN or if the VLAN that was deleted is recreated.
Spanning-Tree Timers
As BPDUs travel throughout the switched network, they might face propagation delays.
These delays occur for a variety of reasons. They happen due to packet length, switch
processing, bandwidth utilization, and other port-to-port delays encountered as a packet
traverses the network. As a result of propagation delays, topology changes can take place
at different times and at different places in a switched network. When a switch port
transitions directly from nonparticipation in the stable topology to the forwarding state, the
port can create temporary data loops if it doesn’t know all the information about the
network.
The Spanning-Tree Protocol implements timers to force the ports to wait for the correct
topology information. The timers are set by default on the switch. The default timers have
been calculated based on the assumption that the switch diameter is 7 and the hello timer is
2 seconds. Based on these assumptions, the network should always form a stable topology.
Defaults timer values are as follows:
• Hello time—2 seconds
• Maximum time (max age)—20 seconds
• Forward delay (fwd delay)—15 seconds
NOTE The diameter is measured from the root bridge, with the root bridge counting as the first
switch. Each switch out from the root bridge is added to come up with the diameter number.
The root bridge can be configured with a diameter from 2 switches to 7 switches. Modifying
the diameter changes the timer values that are advertised by the root to more accurately
reflect the true network diameter. For example, a diameter of 2 yields a max age of 10
seconds and a fwd delay of 7 seconds. It is recommended that you change the diameter to
correctly reflect your network rather than manually changing the timers.
NOTE It is recommended that you leave Spanning-Tree Protocol enabled on the switch. It is
particularly important that it be enabled on uplink ports where there is a chance that a
bridging loop could be created.
You can verify the current Spanning Tree configuration with the following command:
Switch (enable) show spantree vlan
The show spantree command shows VLAN 1 by default. You can specify the VLAN
number so that you can look at the Spanning Tree information for that VLAN. The ability
to have different Spanning Trees for different VLANs is called Per-VLAN Spanning Tree
(PVST) and is covered in the next section. Example 4-1 shows the output of the show
spantree command. This output includes information on the elected root bridge, including
its MAC address and priority. The final portion of the output gives information about this
bridge. In addition, the output indicates the cost to get to the root bridge and which port it
uses to get there. In this example, the cost to the root bridge is 0, indicating that this is in
fact the root bridge. Another indicator that this is the root bridge is that the bridge’s MAC
address is the same as the root bridge’s.
Example 4-1 Verifying the Spanning Tree Configuration
Switch> (enable) show spantree
VLAN 1
Spanning tree enabled
Spanning tree type ieee
Designated Root 00-50-bd-18-a8-00
Designated Root Priority 8192
Designated Root Cost 0
Designated Root Port 1/0
Root Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec
Bridge ID MAC ADDR 00-50-bd-18-a8-00
Bridge ID Priority 8192
Bridge Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec
Port Vlan Port-State Cost Priority Fast-Start Group-Method

--------- ---- ------------- ----- -------- ---------- ------------
2/1 1 forwarding 19 32 disabled
The following is a description of each of the fields in Example 4-1:

• Designated Root—The 6-byte MAC address for the current designated root bridge.
• Designated Root Priority—The 2-byte priority setting for the root bridge. The
priority in this example has been modified from the default of 32,768 to 8192.
• Designated Root Cost—This is the total cost to get to the root bridge through the
shortest path. A root cost of 0 indicates that this bridge is the root bridge.
• Designated Root Port—The port that is used to get to the root bridge.
• Root timers—The timer values of the root bridge. The bridge always accepts the
timers from the root bridge.
• Bridge ID MAC ADDR—The 6-byte address that this bridge is using for its bridge ID.
• Bridge ID Priority—The 2-byte priority of this bridge. Notice that the combination
of the Bridge ID Priority and Bridge ID MAC Address are identical to the Designated
Root. This is another indication that this is the root bridge.
• Bridge timers—The timer values for the bridge. These timers are not used in favor of
the root bridge’s timers.
• Ports in the Spanning Tree—Ports that are participating in this Spanning Tree are
listed with their current state. Note that all ports on a root bridge will be forwarding.
The 1900/2800 series switches use the same command to view the Spanning Tree, but the
output looks slightly different. Even though the output is different, the meaning of each of
the major fields is the same. Example 4-2 shows the output of the show spantree command.
Example 4-2 Verifying Spanning Tree on an IOS-Based Switch
Switch#show spantree
VLAN1 is executing the IEEE compatible Spanning Tree Protocol
Bridge Identifier has priority 32768, address 0090.866F.D000
Configured hello time 2, max age 20, forward delay 15
Current root has priority 32768, address 0050.BD18.A800
Root port is FastEthernet 0/26, cost of root path is 10
Topology change flag not set, detected flag not set
Topology changes 60, last topology change occurred 0d14h15m09s ago
Times: hold 1, topology change 8960
hello 2, max age 20, forward delay 15
Timers: hello 2, topology change 35, notification 2
Port Ethernet 0/5 of VLAN1 is Forwarding
Port path cost 100, Port priority 128
Designated root has priority 32768, address 0050.BD18.A800
Designated bridge has priority 32768, address 0090.866F.D000
Designated port is Ethernet 0/5, path cost 10
Timers: message age 20, forward delay 15, hold 1
Port Ethernet 0/25 of VLAN1 is Forwarding
Port path cost 100, Port priority 128
Designated root has priority 32768, address 0050.BD18.A800
Designated bridge has priority 32768, address 0090.866F.D000
Designated port is Ethernet 0/25, path cost 10
Timers: message age 20, forward delay 15, hold 1
(text deleted)
Virtual LANs and Spanning Tree 147
Virtual LANs and Spanning Tree

One of the major differences between switches and transparent bridges is the
implementation of VLANs on a switch. This section covers Spanning-Tree Protocol
behavior as it relates to VLANs in the campus network.
This section discusses the following topics:
• Defining a separate STP for each VLAN
• Defining a common STP for all VLANs in a network
• Combining these two methods into one implementation
Cisco and the IEEE 802.1Q committee approach the Spanning Tree and VLAN issue in
very different ways. Here are some of the major methods for reconciling STP and VLANs:
• Per-VLAN Spanning Tree (PVST)—PVST is a Cisco proprietary implementation.
It requires Cisco ISL encapsulation in order to work. PVST runs a separate instance
of the Spanning-Tree Protocol for every VLAN.
• Common Spanning Tree (CST)—CST is the IEEE 802.1Q solution to VLANs and
Spanning Tree. CST defines a single instance of Spanning Tree for all VLANs. BPDU
information runs on VLAN 1.
• Per-VLAN Spanning Tree Plus (PVST+)—PVST+ is a Cisco proprietary
implementation that allows CST information to be passed correctly into PVST.
Per-VLAN Spanning Tree

A solution to the scaling and stability problems associated with large Spanning Tree
networks is to create separate instances of Spanning Tree for each VLAN (referred to as
Per-VLAN Spanning Tree [PVST]).
When creating fault-tolerant internetworks, a loop-free path must exist between all nodes
in a network. The Spanning-Tree Algorithm calculates the best loop-free path throughout
the switched network.
Because each VLAN is a logical LAN segment, one instance of STP maintains a loop-free
topology in each VLAN. Although the Catalyst 2820 and Catalyst 1900 switches support a
maximum of 1005 VLANs, you can enable STP on a maximum of only 64 VLANs at a
time. If you configure more than 64 VLANs, you can still operate the other VLANs with
STP disabled. By default, STP is enabled on VLANs 1 through 64.
Each VLAN has a unique STP topology (root, port cost, path cost, and priority).
Figure 4-9 shows that PVST maintains a separate instance of Spanning Tree for
every VLAN, allowing for optimization of all VLANs.
Virtual LANs and Spanning Tree 149
Figure 4-10 Common or Mono Spanning Tree Can Result in Less-Than-Optimal Paths for Some Networks
Green
Users
H Red
Users
C
E I
Green
Users
Green A
J
Server
Green Red
Users Server
= Forwarding Path D F
Root
= Backup Link
Bridge Red
Users
G
CST advantages include the following:

• Fewer BPDUs consuming bandwidth
• Less processing overhead on the switch
CST disadvantages are as follows:
• Single root bridge, which might mean less-than-optimal paths for some devices.
• Spanning-Tree topology grows to encompass all ports in the switch fabric. This can
lead to longer convergence times and more frequent reconfiguration.
Per-VLAN Spanning Tree Plus

In order to support the IEEE 802.1Q standard, Cisco’s existing PVST protocol has been
extended to become the PVST+ protocol. PVST+ extends the PVST protocol by adding
support for links across IEEE 802.1Q’s Common Spanning Tree region. PVST+ is
compatible with both IEEE 802.1Q’s CST and the existing Cisco PVST protocols. In
addition, PVST+ adds checking mechanisms to ensure that there is no configuration
inconsistency with port trunking and VLAN_ID across switches. It is plug-and-play-
compatible with PVST, with no requirement of new CLI commands or configuration.
Scaling Spanning Tree in the Campus Network 151
Scaling the Spanning-Tree Protocol involves the following tasks:

• Providing for an optimal topology through the proper placement of the root bridge
• Providing for efficient workstation access through the use of the PortFast command
• Load-balance on redundant links through the use of technologies such as PortVlanPri
and Fast EtherChannel
• Improve the convergence time of Spanning Tree during a network reconfiguration
through the use of UplinkFast and BackboneFast
Establishing the Root Bridge

One of the most important decisions that must be made in the Spanning Tree network is the
location(s) of the root bridge. Proper placement of the root bridge optimizes the path that
is chosen by the Spanning-Tree Protocol. Proper placement also provides deterministic
paths for data. Deterministic paths make troubleshooting and configuring the network
easier.
You can manually configure the bridge that should be the root bridge, as well as the backup,
or secondary, root bridge. The job of the secondary root bridge is to take over if the primary
root bridge fails.
The Cisco switch software can be used to configure the STP operational parameters in a
network. Use the set spantree root command to set the primary root for specific VLANs
or for all the switch’s VLANs. The set spantree secondary command allows you to
configure a backup root bridge.
NOTE Give careful consideration to switching paths before changing the root bridge. The root of
your Spanning Tree should be close to the center of the network. For this reason, the root
bridge is typically a distribution layer switch and not an access layer switch.
To configure the STP root switch on a Catalyst 5xxx switch, enter the following command
in privileged mode:
Switch (enable) set spantree root vlan_list [dia network_diameter]
[hello hello_time]
Example 4-3 shows how to specify the primary root switch for VLANs 1 through 10.
Example 4-3 Specifying the Primary Root Switch for a Range of VLANs
Switch> (enable) set spantree root 1-10 dia 2
VLANs 1-10 bridge priority set to 8192
VLANs 1-10 bridge max aging time set to 10 seconds.
continues
Figure 4-13 Parallel Fast Ethernet Links
Fast Ethernet 1
A Fast EtherChannel Fast EtherChannel D
Fast Ethernet 2
B E
Fast Ethernet 3
Fast Ethernet 4
C F
Fast EtherChannel offers bandwidth scalability within the campus by providing full-duplex
bandwidth of 200 Mbps to 800 Mbps. The implementation of Fast EtherChannel
technology, in addition to providing high bandwidth, provides load sharing and
redundancy. This technology provides load balancing and management of each link by
distributing traffic across the multiple links in the channel. Unicast, multicast, and
broadcast traffic is distributed across the links in the channel. In addition, Fast
EtherChannel technology provides redundancy in the event of link failure. If a link is lost
in a Fast EtherChannel, traffic is rerouted on one of the other links in less than a few
milliseconds, and the convergence is transparent to the user.
Fast EtherChannel and Gigabit EtherChannel use a load distribution algorithm based on the
destination MAC address, as shown in Figure 4-14.
Figure 4-14 Fast EtherChannel and Gigabit EtherChannel Use Load Distribution to Share Links
D D Fast Ethernet 1 D D
A D D Fast Ethernet 2 D D D
D D
B E
Fast Ethernet 3
Fast EtherChannel Fast EtherChannel
Fast Ethernet 4
Flow Output Path Flow Output Path
C F
A —> D FE 1 D —> A FE 4
B —> D FE 2 D —> B FE 3
C —> D FE 3 D —> C FE 1
Etc. FE… Etc. FE…

Scaling Spanning Tree in the Campus Network 163
Creating a Channel Group with Fast EtherChannel

Create a channel on the desired ports by entering the following command:
Switch> (enable)set port channel mod_num/ports [on | off | auto | desirable]
You should see the following output after issuing the set port channel command:
Port(s) 1/1-2 channel mode set to on.
04/05/1999,17:09:32:PAGP-5:Port 1/1 left bridge port 1/1.
04/05/1999,17:09:32:PAGP-5:Port 1/2 left bridge port 1/2.
04/05/1999,17:09:33:PAGP-5:Port 1/1 joined bridge port 1/1-2.
04/05/1999,17:09:33:PAGP-5:Port 1/2 joined bridge port 1/1-2.
Console> (enable)
To enable an EtherChannel bundle on an IOS-based switch, enter the following command:

Switch(config)#port-channel mode [on | off | auto | desirable]
This command creates a virtual port channel interface on the switch.
CAUTION Before turning on port channeling for a group of ports, verify that all conditions for
channeling have been met. If they have not, the ports will automatically disable, bringing
the link down with them. If you are unsure whether all conditions have been met, remove
the configuration from the links, channel the links, and then reapply the configuration.
Verify the EtherChannel configuration on a set-based switch, as shown in Example 4-8.

Example 4-8 Verifying EtherChannel Configuration
Switch> (enable) show port channel 1
Port Status Channel Channel Neighbor Neighbor
mode status device port
------ ------- --------- -------- --------------- --------
1/1 connected on channel WS-C5000 012345678 5/5
1/2 connected on channel WS-C5000 012345678 5/6
----- --------- ------- -------- --------------------------
Switch> (enable)
Verify the EtherChannel configuration on an IOS-based switch by entering the following:

Switch#show interface port-channel port-channel_group_number
Implementing PortFast
The Spanning-Tree Protocol runs on all ports of a switch. Many ports of a switch might
connect to workstations or servers. These point-to-point connections are not part of the
switch fabric, yet they must run Spanning Tree. The Spanning-Tree Algorithm makes each
port wait up to 50 seconds before data is allowed to be sent on the port. This might cause
problems with some protocols and applications.
Follow these steps:

Step 1 On your PC’s desktop, form a connection with the distribution layer
switch, DSW141.
Step 2 In privileged mode, enter the set spantree root vlan dia 2 command,
where vlan is the first VLAN number.
Step 3 In privileged mode, enter the set spantree root secondary vlan dia 2
command, where vlan is the second VLAN number.
Step 4 Connect to your second distribution switch, DSW142.
Step 5 In privileged mode, enter the set spantree root vlan dia 2 command,
where vlan is the second VLAN number.
Step 6 In privileged mode, enter the set spantree root secondary vlan dia 2
command, where vlan is the first VLAN number.
Step 7 In privileged mode, verify that the STP parameters have changed for
both your VLANs and that the appropriate values of priority and root port
are indicated. Your display should resemble the output shown in Example
4-13.
Example 4-13 Verifying the STP Parameters
DSW142> (enable) show spantree 41
VLAN 41
Spanning tree type ieee
Designated Root 00-50-bd-18-a8-14

Bridge ID MAC ADDR 00-50-bd-18-ac-14

Port Vlan Port-State Cost Priority Fast-Start Group-Method

--------- ---- ------------- ----- -------- ---------- ------------
2/1 41 blocking 19 32 disabled
192 Chapter 5: Inter-VLAN Routing
Distribution Layer Topology

As covered in Chapter 1, “Overview of a Campus Network,” the distribution layer provides
a broadcast or multicast boundary definition and is where inter-VLAN routing occurs.
The distribution layer consists of a combination of high-end switches and route processors.
Because of its Layer 3 capabilities, the distribution layer becomes the demarcation between
networks in the access layer and networks in the core. Each wiring closet hub corresponds
to a logical network or subnet that homes to the route processor, allowing the route
processors in the distribution layer to provide broadcast control and segmentation as well
as terminating collision domains.
The switch/route processor model is straightforward to configure and maintain because of
modularity. Each route processor within the distribution layer is programmed with the same
features and functionality. Common configuration elements can be copied across the layer,
allowing for predictable behavior and easier troubleshooting.
External Route Processors

You can use your existing Cisco high-end routers in conjunction with the Netflow Feature
Card (NFFC) or NFFC II on a Catalyst 5000 family switch to implement multilayer
switching. The router must be directly attached to the Catalyst switch either by multiple
Ethernet connections (one per subnet) or by a Fast Ethernet connection using an ISL. Figure
5-5 shows that an external router can be used to communicate between VLAN 41 and
VLAN 42.
Figure 5-5 illustrates the external router configuration. In Figure 5-5, all the traffic traverses
the switches when traveling from clients on Switch A to clients on Switch B because the
clients on both switches belong to network 172.16.41.0. The data goes through the router
only when the traffic must cross over to another network. For example, if users on Switch
A belong to Network 172.16.41.0, and users on Switch C belong to Network 172.16.42.0,
communications between the end devices on Switch A and Switch C must go through the
router.
The Cisco high-end routers supporting multilayer switching include the Cisco 7500, 7200,
4500, and 4700 series routers. These routers must have the Multilayer Switch Protocol
(MLSP) software and Cisco IOS 11.3.4 or later software installed to provide the Layer 3
services to the switch.
Additional VLANs are toggled between the two channels as they are created. A VLAN can
be mapped to a specific channel to balance each channel’s load.
The MAC addresses available to the RSM are assigned as follows:
• VLAN 0 (channel 0) is assigned the MAC address of a programmable ROM (PROM)
on the RSM line communication processor (LCP). This MAC address is used for
diagnostics and to identify the RSM physical slot. VLAN 0 is inaccessible to the user.
• VLAN 1 and additional VLANs are assigned the base MAC address from a MAC
address PROM on the RSM that contains 512 MAC addresses. All routing interfaces
except VLAN 0 use the base MAC address.
Configuring Inter-VLAN Routing

The Catalyst 5000, 4000, 2926G, and 2926 series switches are multimodule systems. You
can see what modules are installed, as well as the MAC address ranges and version numbers
for each module. To display information about the installed modules, enter the following
command in privileged mode on the switch:
Switch(enable) show module mod_num
Entering the show module command without specifying a module number displays
information on all modules installed in the system. Specifying a particular module number
displays information on that module. Example 5-1 shows sample output from the show
module command.
Example 5-1 show module Sample Output
DSW142 (enable) show module
Mod Module-Name Ports Module-Type Model Serial-Num Status
--- ------------------- ----- --------------------- --------- --------- -------
1 0 Supervisor III WS-X5530 010827944 ok
2 24 10/100BaseTX Ethernet WS-X5225R 012152170 ok
3 1 Route Switch WS-X5302 007572460 ok
Mod MAC-Address(es) Hw Fw Sw
--- -------------------------------------- ------ ---------- -----------------
1 00-50-e2-80-54-00 to 00-50-e2-80-57-ff 2.0 3.1.2 4.3(1a)
2 00-10-7b-03-5d-58 to 00-10-7b-03-5d-6f 3.1 4.3(1) 4.3(1a)
3 00-e0-1e-91-dc-66 to 00-e0-1e-91-dc-67 5.0 20.14 11.3(6)WA4(9)
Mod Sub-Type Sub-Model Sub-Serial Sub-Hw

--- -------- --------- ---------- ------
1 NFFC WS-F5521 0010839900 1.1
Configuring Inter-VLAN Routing 197
NOTE The Catalyst 4912G, 2948G, 2926G, and 2926 series switches are fixed-configuration
switches but are logically modular. You must apply configuration commands to the
appropriate module. For example, on a Catalyst 2926G series switch, the 24 Fast Ethernet
ports belong logically to module 2. Refer to the Catalyst 2900 Series Configuration Guide
and Command Reference and Switch Software Documentation, Release 5.1 publications for
more information.
Loading and Accessing the Route Processor

You can eliminate the need to connect a terminal directly to the RSM console port by
accessing the RSM from the switch. To access the RSM from the switch prompt, enter the
following command:
Switch> session mod-num
mod-num is the module number of the RSM. The module number can be obtained by
issuing the show module command on the switch.
After the session command executes, the switch responds with the Enter Password prompt
for the RSM, if a password is configured. Once you enter the password for the RSM, you
are logged in to the route processor. At this point, you are in user EXEC command mode
on the route processor, and you have direct access only to the RSM with which you have
established a session.
To exit from the router command-line interface and go back to the switch CLI, enter the exit
command at the Router> prompt.
The following shows how to access the RSM from the switch CLI, and how to exit the
router CLI and return to the switch CLI:
Switch> session 3
Switch> Enter Password: cisco
Router> exit
One of the first tasks in configuring your route processor is to name it. Naming your router
helps you better manage your network by being able to uniquely identify each route
processor within the network. The name of the route processor is considered to be the host
name and is the name displayed at the system prompt. If no name is configured, the system
default router name is Router followed by an angle bracket (>) for EXEC mode or a pound
sign (#) for privileged EXEC mode.
To configure a host name, enter the following command in global configuration mode:
Router(config)#hostname name
name is the identifying system name between 1 and 255 in alphanumeric characters.
The output in Example 5-2 shows that the host name of the route processor is RSM143#.
Example 5-2 Output Displaying the Host Name
RSM143#show running-config
!
version 11.3
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname RSM143
-text deleted-
To clear the host name, enter the no hostname command in global configuration mode.
NOTE Do not expect case to be preserved. Uppercase and lowercase characters look the same to
many Internet software applications (often under the assumption that the application is
doing you a favor). It might seem appropriate to capitalize a name the same way you would
in English, but conventions dictate that computer names appear in all-lowercase. For more
information, refer to RFC 1178, “Choosing a Name for Your Computer.”
The name must also follow the rules for ARPANET host names. They must start with a
letter, end with a letter or digit, and contain only letters, digits, and hyphens. Names must
have 63 or fewer characters. For more information, refer to RFC 1035, “Domain Names—
Implementation and Specification.”
Enabling an IP Routing Protocol

All devices in a network communicate with each other over routes. A route is a path from
the sending device to the receiving device. If the destination device is on the same network
as the sending device, the sending device simply transmits the packet directly to the
destination. When a destination is not on the local network, a sending device forwards the
packet to a route processor.
Route processors can route in the following two basic ways:
• Use preprogrammed static routes
• Dynamically calculate routes using any one of a number of dynamic routing protocols
Routing protocols determine optimal paths through internetworks using routing algorithms,
and they transport information across these paths.
slot-number/port-number.subinterface-number identifies the physical and logical

interfaces.
NOTE The subinterface number that is used can be any number. It has no significance to the router.
The router does not look at this number in order to determine the VLAN number. It is,
however, standard practice to make the subinterface number the same as the VLAN in order
to make it easier to manage the router.
To define the VLAN encapsulation, enter the following command in interface configuration
mode:
Router(config-if)#encapsulation isl vlan-number
vlan-number identifies the VLAN for which the subinterface will carry traffic. A VLAN ID
is added to the frame anytime the frame is sent out the interface. Each VLAN frame carries
the VLAN ID within the packet header.
NOTE Encapsulation type can be either ISL or dot1q, depending on the encapsulation technique
used at the switch.
To assign the IP address to the interface, enter the following command in interface
configuration mode:
Router(config-if)#ip address ip-address subnet-mask
ip-address and subnet-mask are the 32-bit network address and mask of the specific
interface.
In Example 5-4, route processor Router144 has two subinterfaces configured on Fast
Ethernet interface 0/1. These two interfaces are identified as 0/1.1 and 0/1.2. Both interfaces
are encapsulated for ISL. Interface 0/1.1 is routing packets for VLAN 10, whereas interface
0/1.2 is routing packets for VLAN 20.
Example 5-4 Interface Configuration on an External Route Processor
RSM144#show running-config
!
!
hostname "Router144"
!
(text deleted)
Configuring Inter-VLAN Routing 203
Example 5-4 Interface Configuration on an External Route Processor (Continued)

interface fastethernet 0/1.1
encapsulation isl 10
ip address 172.16.10.3 255.255.255.0
interface fastethernet 0/1.2

encapsulation isl 20
ip address 172.16.20.3 255.255.255.0
Defining the Default Gateway

In order to forward a datagram, the sending device must first know which routers are
connected to the local network and which route processor maintains the shortest path to the
destination device. Because it is not the responsibility of the end-user device to create and
maintain routing tables, a default gateway is used to forward all nonlocal packets.
Defining a Default Gateway on a Cisco IOS Command-Based Switch

To define a gateway on a Cisco IOS-based series switch, enter the following command in
global configuration mode:
Switch (config) ip default-gateway ip-address
ip-address is the IP address of the default route processor.
Defining a Default Gateway on a Set Command-Based Switch

A switch acts like any other IP end station. It must have a default gateway configured so
that the switch can communicate with devices in other IP subnets. To do this, a default route
must be added that points to the gateway router in the same subnet/VLAN as the sc0
interface on the switch.
To configure a default route on a set command-based system, enter the following command
in privileged mode:
Switch (enable) set ip route destination gateway metric
Table 5-1 describes the variables in this command.

Table 5-1 set ip route Command Variables
Variable Description
destination IP address or IP alias of the network or specific host to be added. Use default as
the destination to set the new entry as the default route.
gateway IP address or IP alias of the router.
metric (Optional) Value used to indicate whether the destination network is local or
remote. Use 0 for local and 1 for remote.
Summary 205
The ping command will return one of the following responses:

• Success rate is 100 percent, or destination-ip-address is alive—This response
occurs in 1 to 10 seconds, depending on network traffic and the number of Internet
Control Message Protocol (ICMP) packets sent.
• Destination does not respond—No answer message is returned if the host does not
exist.
• Unknown host—This response occurs if the targeted host does not exist.
• Destination unreachable—This response occurs if the default gateway cannot reach
the specified network.
• Network or host unreachable—This response occurs if there is no entry in the route
table for the host or network.
NOTE You can also test the routes that packets will take from the route processor to a specific
destination. To track a router, enter the trace ip destination command in privileged mode,
where destination is the IP address of the target device. For more information on the trace
ip command, refer to the Cisco IOS Release 12.0 Command Summary publication.
Summary
VLANs are an important component of the campus network. In order for VLANs to
communicate with each other, inter-VLAN routing must be present. The following
summarizes the major characteristics of routing between VLANs:
• Inter-VLAN routing is a requirement to enable communication between devices in
separate VLANs.
• Most devices are configured with the IP address of a default router to which all
nonlocal network packets are sent.
• The Inter-Switch Link (ISL) protocol is used to facilitate multiple VLAN traffic over
a single link.
• The distribution layer routing processor can be an internal or external router/switch
topology.
CHAPTER
6
Improving IP Routing
Performance with Multilayer
Switching
Chapter 1 discussed the new 20/80 rule for designing campus networks. Based on this
general rule, 80 percent of your users’ traffic must cross a Layer 3 device. The speed at
which this device can transmit data is extremely important. Cisco has developed several
switching techniques in order to speed up the process of moving through a Layer 3 device.
The primary method deployed inside the campus network is called multilayer switching
(MLS). Multilayer switching is an important emerging technology that combines the best
of switching and routing, bringing new levels of performance and scalability to campus
networks. In light of changing traffic patterns and increasing loads being placed on the
networks to access centralized resources and server farms, it becomes imperative for the
platforms used in the campus design to provide appropriate Layer 3 performance.
This chapter discusses the following topics:
• Multilayer switching fundamentals
• Configuring the Multilayer Switching Route Processor
• Applying flow masks
• Configuring the multilayer switching switch engine
• MLS topology examples
• Other Layer 3 switching technologies
Upon completion of this chapter, you will be able to perform the following tasks: identify
the network devices required to run multilayer switch IP traffic between two end-user
devices, configure the distribution layer route processor to participate in multilayer
switching, configure the distribution layer switching engine to participate in multilayer
switching, verify existing flow entries in the MLS cache, and apply flow masks to determine
how MLS entries are created in the MLS cache.
Multilayer Switching Fundamentals

Multilayer switching is one of the techniques used to increase IP routing performance by
handling the Layer 3 packet switching and rewrite function in hardware. The Cisco Systems
implementation of MLS supports all the traditional routing protocols; however, the frame
Multilayer Switching Fundamentals 219
enter the switch, they are switched based on the information cached about the flow to the
correct port. A Layer 2 device can now handle traffic that traditionally had to always pass
to a Layer 3 device.
Hardware and Software Requirements

Multilayer switching can be implemented using a Layer 3 switch or an external router
topology. MLS requires the following software and hardware:
• Catalyst 5000 or 6000 series switch with Supervisor Engine software release 4.1(1)
or later
• Cisco IOS release 11.3(2)WA4(4) or later
• Supervisor Engine III or III F with the NFFC II, or Supervisor Engine II G or III G
• Route Switch Feature Card (RSFC)
You can also implement MLS with an external router/Catalyst switch combination. The
following equipment is necessary when implementing MLS with an external router/
Catalyst switch combination:
• Catalyst 5000 or 6000 series switch with Supervisor Engine software release 4.1(1)
or later
• Supervisor Engine III or III F with the NFFC II, or Supervisor Engine II G or III G
• Cisco high-end routers, such as Cisco 7500, 7200, 4500, 4700, or 8500 series
• Cisco IOS release 11.3(2)WA4(4) or later
NOTE The Catalyst 8540 does not currently support multilayer switching. It utilizes a Layer 3
switching mechanism called Cisco Express Forwarding.
The connection between the external router and the switch can be multiple Ethernet links
or Fast Ethernet with the Inter-Switch Link (ISL).
MLS Components
The Cisco multilayer switching implementation includes the following components:
• Multilayer Switching Switch Engine (MLS-SE)—The switching entity that handles
the function of moving and rewriting packets. The MLS-SE is a NetFlow Feature Card
residing on a Supervisor Engine III card in a Catalyst switch.
220 Chapter 6: Improving IP Routing Performance with Multilayer Switching
• Multilayer Switching Route Processor (MLS-RP)—A Route Switch Module or an

externally connected Cisco 7500, 7200, 4500, 4700, or 8500 series router with
software that supports multilayer switching. The MLS-RP sends MLS configuration
information and updates, such as the router MAC address and virtual LAN (VLAN)
number flow mask, and routing and access list changes.
• Multilayer Switching Protocol (MLSP)—This protocol operates between the MLS-SE
and MLS-RP to enable multilayer switching. The MLSP is the method in which the RSM
or router advertises routing changes and the VLANs or MAC addresses of the interfaces
that are participating in MLS.
Figure 6-1 shows the icons used throughout this book for MLS-RP and MLS-SE.
Figure 6-1 MLS Components—A Layer 3 Routing Component and a Layer 2 Switch Component
MLS-RP—Multilayer MLS-SE—Multilayer
Switching Route Processor Switching Switch Engine
How MLS Works

The preceding section discussed the components of MLS. This section discusses the
mechanics of MLS. This includes the communication between Layer 2 and Layer 3 devices,
caching Layer 3 information in the Layer 2 switch, and switching packets through a switch.
The following topics are discussed:
• MLS-RP advertisements
• MLSP hello messages
• Assigning XTAGs
• Establishing an MLS cache entry
• Switching frames in a flow
MLS-RP Advertisements
When an MLS-RP is activated in a campus network, the MLS-RP sends out a multicast
hello message every 15 seconds. This message is sent to all switches in the network, and it
contains the following:
• The MAC addresses used by the MLS-RP on its interfaces that are participating in
MLS
• Access list information
• Additions and deletions of routes
Multilayer Switching Fundamentals 221
MLSP uses the Cisco Group Management Protocol (CGMP) multicast address as the
destination address of the hello message. This address ensures interoperability with the
Cisco switches in the network. Although this address is the same as that used by CGMP, the
message contains a different protocol type so that the switch can distinguish these messages
from other multicast packets.
MLSP Hello Messages

Because all Cisco switches listen to the well-known multicast address, they all receive the
hello message. However, only switches that have Layer 3 capabilities process the hello
message. Switches without Layer 3 capabilities pass these frames to downstream switches.
When an MLS-SE receives the frame, the device extracts all the MAC addresses received
in the frame, along with the associated interface or VLAN ID for that address. The MLS-
SE records the addresses of the MLS-RPs in the MLS-SE content-addressable memory
(CAM) table.
Assigning XTAGs
If there are multiple MLS-RPs attached to a switch, the MLS-SE distinguishes the MAC
address entries of each MLS-RP by assigning an XTAG value to these addresses. The
XTAG value is a locally generated one-byte value that the MLS-SE attaches to all the MAC
addresses learned from the same MLS-RP via the MLSP frames.
The XTAG is also useful in deleting a specific set of Layer 3 entries from the Layer 3 table
when an MLS-RP fails or exits the network.
Establishing an MLS Cache Entry

Multilayer switching is based on individual flows. The MLS-SE maintains a cache for MLS
flows and stores statistics for each flow. All packets in a flow are compared to the cache.
NOTE MLS cache entries support unidirectional flows. The unidirectional nature of a flow means
that there is an MLS cache entry for the flow between Host A and Host B, and another MLS
cache entry for the flow between Host B and Host A.
If the MLS cache contains an entry that matches the packet in the flow, the MLS-SE layer
switches the packet, bypassing the router. If the MLS does not contain an entry that matches
the packet, the following steps outline the process in establishing an MLS cache entry for
a flow. Figures 6-2 though 6-4 include corresponding numbers that illustrate these steps.
Step 3 The switch rewrites the Layer 2 frame header, changing the destination
MAC address to the MAC address of Host B, and the source MAC
address to the MAC address of the MLS-RP. The Layer 3 IP addresses
remain the same, but the IP header Time To Live (TTL) is decremented
and the checksum is recomputed. The MLS-SE rewrites the switched
Layer 3 packets so that they appear to have been routed by a route
processor.
NOTE The switch rewrites the frame to look exactly as if the route processor processed the frame.
The final destination sees the frame exactly as if the router processed the frame.
Step 4 After the MLS-SE performs the packet rewrite, the switch forwards the
rewritten frame to the destination MAC address.
The state and identity of the flow are maintained while traffic is active; when traffic for a
flow ceases, the entry ages out. Partial, or candidate, entries remain in the cache for 5
seconds with no enabled entry before timing out. Cache entries that are complete—those in
which the switch captures both the candidate and the enabling packet—remain in the cache
as long as packets in that flow are detected.
Commands That Disable MLS

Some IP commands require that the routing processor must manipulate every packet in the
flow. Any command that requires each packet to be manipulated by the route processor
precludes the multilayer switching function. The following are some IP commands that
disable MLS on an interface:
• no ip routing—Purges all MLS cache entries and disables MLS on the MLS-RP.
• ip security (all forms of this command)—Disables MLS on the interface.
• ip tcp compression-connections—Disables MLS on the interface.
• ip tcp header-compression—Disables MLS on the interface.
• clear ip-route—Removes the MLS cache entries in all switches performing Layer 3
switching for this MLS-RP.
Configuring the Multilayer Switch Route Processor 227
Configuring the Multilayer Switch Route Processor

You can complete the configuration of the MLS-RP in a few simple steps:
Step 1 Globally enable MLS on the route processor for a specific routing
protocol.
Step 2 Assign an MLS VTP domain at the interface.
Step 3 Enable MLS on the route processor for a specific interface.
Step 4 Create a Null Domain.
Step 5 Specify an MLS management interface.
Step 6 (Optional) Assign a VLAN ID to an interface.
Globally Enabling MLS on the Route Processor

Before you can configure multilayer switching for a specific VLAN or interface, you must
globally enable the MLSP that operates between the route processor and the switch.
To enable MLSP on the route processor, enter the following command in global
configuration mode:
Router(config)#mls rp ip
The running configuration in Example 6-1 shows that the MLS-RP is configured to MLS
routed IP packets.
NOTE As of IOS release 12.0, MLS also routes Internetwork Packet Exchange (IPX) packets.
Example 6-1 Example of IOS MLS-RP IP Configuration

Router# show running-config
!
version 11.3
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router
!
!
mls rp ip
!
Configuring the Multilayer Switch Route Processor 229
To remove the MLS interface from a VTP domain, enter the no mls rp vtp-domain
domain-name command.
To view information about a specific VTP domain, enter the following command in
privileged EXEC mode:
Router# show mls rp vtp-domain vtp-domain-name
The display resulting from this command shows a subset of the show mls rp command
display. The following information is a result of issuing the show mls rp vtp-domain
command:
• The name of the VTP domain(s) in which the MLS-RP interfaces reside
• Statistical information for each VTP domain
• The number of management interfaces defined for the MLS-RP
• The number of VLANs in this domain configured for MLS
• The ID of each VLAN configured for this domain MAC address
• The number of MLS-SEs that the router or RSM has knowledge of in this domain
• The MAC address of each switch in this domain
Enabling MLS on an Interface

Putting an MLS interface into a VTP domain does not activate MLS on the interface. MLS
must be explicitly entered on the interface. Because of the one-to-one relationship between
VLANs and subnets, each interface that is to participate in Layer 3 switching must be
enabled for multilayer switching.
To enable an RSM interface for multilayer switching, enter the following command in
interface configuration mode:
Router (config-if)#mls rp ip
The running configuration in Example 6-3 shows that the VLAN41 interface of the
MLS-RP is enabled to participate in multilayer switching.
Example 6-3 Enabling MLS at the Interface
Router# show running-config
(text deleted)
mls rp ip
!
!
interface Vlan1
ip address 172.16.1.168 255.255.255.0
!
interface Vlan41
continues
Applying Flow Masks 233
Each MLSP-RP is identified to the switch by both the MLS ID and the MLS IP address of
the route processor. The MLS ID is the MAC address of the route processor. The MLS-RP
automatically selects the IP address of one of its interfaces and uses that IP address as its
MLS IP address.
The MLS-SE uses the MLS ID as a determining factor for establishing entries in the MLS
cache.
This MLS IP address is used in the following situations:
• By the MLS-RP and the MLS-SE when sending MLS statistics to a data collection
application
• In the included MLS route processor list on the switch
To verify the MLS configuration for a specific interface, enter the following command in
Router# show mls rp interface interface number
The display resulting from this command shows the following information:
• Whether multilayer switching is configured on the interface
• The VTP domain in which the VLAN ID resides
• Whether this interface is configured as the management interface for the MLS-RP
If the interface is not configured for multilayer switching, this show command displays a
message such as the following:
Router# show mls rp ip interface Vlan41
mls not configured on Vlan41
Applying Flow Masks

The MLS-SE uses flow mask modes to determine how packets are compared to MLS
entries in the MLS cache. The flow mask mode is based on the access lists configured on
the MLS router interfaces. The MLS-SE learns of the flow mask through MLSP messages
from each MLS-RP for which the MLS-SE is performing Layer 3 switching.
NOTE Most Cisco documentation explains flow masks as a way to determine how packets are
compared to entries in the MLS cache. This is inaccurate. Flow masks are actually used to
determine how much information about the packet is placed in the MLS cache. The flow
mask is not used to compare packets to existing entries in the MLS cache.
MLS-SE supports only one flow mask for all MLS-RPs that are serviced by the MLS-SE.
If the MLS-SE detects different flow masks from different MLS-RPs for which the MLS-
SE is performing Layer 3 switching, the MLS-SE changes its flow mask to the most specific
flow mask detected. However, if a more-specific flow mask is in effect, a less-specific flow
mask is applied.
The MLS-SE supports three flow mask modes:
• Destination-IP
• Source-Destination-IP
• IP-Flow
When the MLS-SE flow mask changes, the entire MLS cache is purged.
NOTE You can set a flow mask on the MLS-SE without applying an access list on the route
processor. You do this when you want to cache entries on a specific set of criteria to export
flow statistics but you don’t want to set an access list on an interface. To set the flow mask
on the MLS-SE without setting an access list on a route processor interface, enter the set
mls flow [destination | destination-source | full] command in privileged mode.
Destination-IP Flow Mask

The default flow mask is the Destination-IP mode. This mode represents the least-specific
flow mask. The MLS-SE maintains one MLS entry for each destination IP address. All
flows to a given destination IP address use this MLS entry. This mode is used if no access
lists are configured on any of the MLS router interfaces.
The following example shows an entry in the MLS cache for an IP flow. Notice that the
example has fields for all the Layer 3 and Layer 4 information, as well as the source IP
address. However, these fields are either blank or filled with zeros. The destination IP flow
indicates that MLS should cache only the information about the destination IP address.
When a packet enters the switch, it is compared to the destination IP address in the MLS
cache.
Destination IP Source IP Port DstPrt SrcPrt Destination Mac Vlan Port
172.16.22.57 0.0.0.0 - - 00-90-b1-33-70-00 45 2/9
Source-Destination-IP Flow Mask

The second type of flow mask is the Source-Destination-IP mode. The MLS-SE maintains
one MLS entry for each source and destination IP address pair. All flows between a given
source and destination use this MLS entry, regardless of the IP protocol ports. This mode
is used if there is a standard access list on any of the MLS interfaces.
The following example shows an MLS cache entry for a source-destination IP flow. The
only change is the addition of the source address in the MLS cache entry. When the switch
checks the MLS cache to see if it has an entry that matches the packet, it looks only at the
destination address for the match. The source address is not used in the comparison, even
though it is listed in the MLS cache entry.
172.16.22.57 172.16.10.123 - - - 00-90-b1-33-70-00 45 2/9
IP-Flow Mask
The final flow mask is the IP-Flow mode. This mode represents the most specific flow mask.
The MLS-SE creates and maintains a separate MLS cache entry for every IP flow. An IP-
Flow entry includes the source IP address, destination IP address, protocol, and protocol
ports. This mode is used if there is an extended access list on any MLS interface.
The following example shows an MLS cache entry when an IP flow mask has been applied.
An IP flow mask indicates that the cache entry should contain all Layer 4 information,
including protocol type as well as source and destination port number. This is in addition
to the destination and source IP addresses. When the switch checks the MLS cache to see
if it has an entry that matches the packet, it looks only at the destination address for the
match. It does not compare the packet against the source IP address, the protocol type, or
the source and destination ports.
172.16.22.57 172.16.10.123 UDP 1238 60224 00-90-b1-33-70-00 45 2/9
Output Access Lists and Flow Masks

In Figure 6-7, a flow is established between Hosts A and B, and packets in that flow are
switched by the MLS-SE.
If an extended access list is applied to the router interface, the MLS-RP tells the MLS-SE
to purge all cache entries in order to enforce the access list. Subsequent entries are relearned
by being sent first to the route processor as candidate packets and then being cached in the
MLS cache when they return from the route processor. If the packet is denied by the access
list, it never makes it back to the switch as an enable packet and therefore is never cached.
The extended access list indicates that the MLS cache should be maintained with an IP flow
mask. This means that the cache should contain all of the Layer 3 and Layer 4 information.
the MLS cache because the complete information of this packet is different than the
information that was contained inside the cache. The MLS cache entry now looks like this:
172.16.22.57 172.16.10.123 ICMP 7001 7004 00-90-b1-33-70-00 68 2/9
172.16.22.57 172.16.10.123 TCP 23 1180 00-90-b1-33-70-00 68 2/9
The MLS-SE switches a packet by comparing its destination address to what it has in cache.
After it has determined that it knows the destination, it switches the packet without ever
sending the packet to the MLS-RP.
This example shows that there could be a potential security hole with the use of access lists
and MLS. The information that is cached for MLS is useful for determining traffic patterns
and accounting. It is not, however, used to compare packets all the way through the Layer
4 information to ensure security. Cisco has solved this security problem in the Catalyst
6000/6500 Series switch with the creation of the Policy Feature Card (PFC). The PFC
allows for the creation of the VLAN access control lists (VACLs) that determine if the
switch should permit or deny a Layer 3 packet or a Layer 2 frame. You will find more
information on access control ist usage on the Catalyst 6000 Series switch at the following
URL: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_3/msfc/
acc_list.htm
New entries are placed in the MLS cache after the initial packet in the flow passes the test
conditions in the output access control list (ACL).
NOTE Using options such as log, reflexive, and established forces the router to examine every
packet before routing. Under MLS, the router does not examine every packet; therefore,
these options are not allowed.
Input Access Lists and Flow Masks

As with output access lists, placing an input access list on an MLS-enabled interface purges
the MLS cache of all existing flows for that interface.
However, because the default behavior for the input access list is to examine and route all
incoming packets, all subsequent packets in the flow between Hosts A and B are routed.
NOTE Most input access lists can be implemented as output access lists to achieve the same effect.
Routers configured with Cisco IOS Release 11.3 or later do not automatically support input
access lists on an interface configured for MLS. If an interface is configured with an input
access list, all packets for a flow that are destined for that interface go through the router.
Even if the router allows that flow, the flow is not Layer 3 switched.
Configuring the Multilayer Switch Switching Engine 239
Aging Out Cache Entries on the Switch

Because the MLS cache has a size limitation, MLS entries are deleted from the cache if
certain conditions are met. This deletion (or aging) process happens for the following
reasons:
• Candidate entries remain in the cache for 5 seconds with no enabled entry before
timing out. A candidate entry with no corresponding enable entry means that the
packet did not make it through the router. This could be because the destination was
unknown or because an access list denying the packet was applied to the router.
• An MLS entry is deleted from the cache if a flow for that entry has not been detected
for the specified aging time. The default aging time is 256 seconds.
Other events, such as applying access lists, routing changes, or disabling MLS on the
switch, can cause MLS entries to be purged.
Managing Short-Lived Flows

The amount of time an MLS entry remains in the cache can be modified by the user. To alter
the value of the aging time, enter the following command in privileged EXEC mode:
Switch(enable)#set mls agingtime agingtime
agingtime is the amount of time an entry remains in the cache before it is deleted. The range
of the aging time value is from 8 to 2032 seconds. The default value is 256 seconds.
The following running configuration example shows that entries in which no packets have
been detected for a period of 5 minutes will be deleted from the cache:
Switch(enable)show config
(text deleted)
#mls
set mls enable
set mls agingtime 304
NOTE agingtime values are entered in 8-second increments. Any agingtime value that is not a
multiple of 8 is adjusted to the closest multiple of 8. This means that a time interval of 300
seconds, or 5 minutes, would automatically be adjusted to 304.
Some MLS flows are sporadic or short-lived. An example of a sporadic or short-lived flow
is packets that are sent to or received from a Domain Name System (DNS) or Trivial File
Transfer Protocol (TFTP) server. Because the connection may be closed after one request
and one reply cycle, that MLS entry in the cache is used only once. However, that MLS
entry still consumes valuable cache space until the entry is aged out. Detecting and aging
out these entries quickly can save MLS entry space for real data traffic.
Verifying the Configuration

To display information about multilayer switching on an MLS-SE, enter the following
command in privileged EXEC mode:
Switch (enable) show mls
The display resulting from this command returns the information shown in Example 6-8.
Example 6-8 The Output of the show mls Command
Switch (enable) show mls
Multilayer switching enabled

Multilayer switching aging time = 304 seconds
Multilayer switching fast aging time = 64 seconds, packet threshold = 7
Full flow
Total packets switched = 101892
Active shortcuts = 2138
Netflow Data Export disabled
Netflow Data Export port/host is not configured.
Total packets exported = 0
MLS-RP IP MLS-RP ID XTAG MLS-RP MAC-Vlans

--------- ----------- ---- ------------------------
172.16.41.168 0010f6b3d000 28 00-10-f6-b3-d0-00 1,41-42
The show mls command gives you the following information:

• Whether multilayer switching is enabled on the switch.
• The aging time, in seconds, for an MLS cache entry.
• The fast aging time, in seconds, and the packet threshold for a flow.
• The flow mask.
• Total packets switched.
• The number of active MLS entries in the cache.
• Whether NetFlow data export is enabled and, if so, for which port and host.
• The MLS-RP IP address, MAC address, XTAG, and supported VLANs.
• To display information about a specific MLS-RP, enter the show mls rp command and
designate the IP address of the target MLS-RP.
NOTE Do not confuse the show mls rp command for the MLS-SE with the show mls rp command
entered on the MLS-RP. The MLS-SE command requires a specific MLS-RP IP address
and displays information used by the switch with regard to Layer 3 switching packets
destined for this MLS-RP.
260 Chapter 7: Configuring HSRP for Fault-Tolerant Routing
NOTE Additional information on HSRP can be found in RFC 2281.
The primary purpose of the campus network is to give end users access to their data and
applications. End users perceive the campus network as a total system and typically do not
care which routers and LAN switches are operational. By building various levels of
redundancy into the network, the network designer permits the network, as a total system,
to maintain connections and converge around failures.
Routing Issues in a Redundant Network

Workstations or host devices typically send information only to their own subnet or cable
segment. They rely on a router to find the best path for their data whenever they need to
send to a subnet other than their own. There are several different ways that hosts are told
about the router they are supposed to use:
• Default gateways
• Proxy ARP
• Routing protocol
Default Gateways
One of the most common ways of allowing the host to find a subnet is setting a default
gateway. The default gateway is used anytime the workstation attempts to send a packet that
it determines is not in its own subnet. Most operating systems, such as Windows 95/98,
allow only one default gateway to be used. The workstation sends an ARP request to find
this router’s MAC address, and that MAC address is used anytime the workstation sends
data to another device on a different subnet. If the router that is being used as the default
gateway fails, the workstation is unable to send packets anywhere else. This is true even if
another router on the subnet could be used to make it to the final destination.
The hierarchical campus model builds in redundancy at the switch block level. Primary and
secondary paths between the access layer and the distribution switch provide continual
access despite a link failure at the access layer. Primary and secondary paths between the
distribution router and the core provide continual operations should a link fail at the
distribution layer. The network infrastructure might be able to converge quickly, but the
host can’t.
In Figure 7-1, Router A is responsible for routing packets for Subnet A, and Router B is
responsible for handling packets on Subnet B. If Router A becomes unavailable to the PC,
fast converging routing protocols can respond within seconds. After convergence, Router B
is prepared to transfer packets that would otherwise have gone through Router A.
HSRP Overview 261
Figure 7-1 Default Gateway Example
Workstation A needs to get to

File Server A, but the default
gateway is down.
Router B can
route packets
Default Gateway to File Server A.
172.16.10.82
0010.f663.d000
Workstation A
Router A Router B
172.16.10.82 172.16.10.169
0010.f6b3.d000 0010.0b79.5800
Subnet A Subnet B
172.16.50.0 172.16.51.0
Core
File Server A
However, it is not the responsibility of the workstation, servers, and printers to exchange
dynamic routing information, nor is routing by such devices a good design. These devices
typically are configured with a single default gateway IP address. If the router that is the
default gateway fails, the device is limited to communicating only on the local IP network
segment and is effectively disconnected from the rest of the network. Even if a redundant
router exists that could serve as a default gateway, there is no dynamic method that these
devices can use to switch to a new default gateway IP address.
Proxy ARP
Figure 7-2 shows that a router can respond to ARP requests in proxy for the destination if
its routing table indicates that the subnet is can be reached.
HSRP Overview 263
To acquire the MAC address of the failover router, the source end station must either initiate
another ARP request or be rebooted. In either case, the source end station cannot
communicate with the destination for a significant period of time, even though the routing
protocol has converged. The interval during which the source cannot communicate with the
destination is calculated by the ARP protocol using the ARP update plus the ARP flush time
entry. This means that the PC’s ARP cache might not be timed out for hours.
Using RIP at the Host

Some IP hosts use the Routing Information Protocol (RIP) to discover routers. The end-user
station maintains a table of which routers have a path to the destination. The end-user
station uses the most expedient path.
The drawback of using RIP is that it is slow to adapt to changes in the topology. If the source
end station is configured to use RIP, a period of three times the update interval might elapse
before RIP makes another router available.
Solution to Routing Issues: Hot Standby Routing Protocol

Cisco routers can use HSRP, which allows end stations to continue communicating
throughout the network even when the default gateway becomes unavailable.
With HSRP, a set of routers works together to represent a single virtual standby router. The
standby group functions as a single router configured with a virtual IP and MAC address.
From the viewpoint of the end system, the virtual router is a single target router with its own
IP and MAC address, distinct from the physical routers in the network.
Because the routers in the standby group route packets sent to a virtual address, packets are
still routed through the network even when the router originally forwarding the packets
fails.
HSRP allows one router to automatically assume the function of another router if that router
fails. HSRP is particularly useful when the users on one subnet require continuous access
to resources in the network.
HSRP Group Members

The standby group is comprised of the following entities (see Figure 7-3):
• One active router
• One standby router
• One virtual router
• Other routers
Figure 7-3 HSRP Group Members
HSRP Group
Standby Virtual Active

Router Router Router
The function of the active router is to forward packets sent to the virtual router. Another
router in the group is elected as the standby router. The active router assumes and maintains
its active role through the transmission of hello messages.
The function of the standby router is to monitor the operational status of the HSRP group
and quickly assume packet-forwarding responsibility if the active router becomes
inoperable. The standby router also transmits hello messages to inform all other routers in
the group of the standby router role and status.
The function of the virtual router is to present a consistently available router to the end user.
The virtual router is assigned its own IP and MAC address, but it does not forward packets.
An HSRP standby group may contain other routers. These routers monitor the hello
messages but do not respond. These routers forward any packets addressed to their IP
addresses but do not forward packets that are addressed for the virtual router.
When the active router fails, the other HSRP routers stop receiving hello messages, and the
standby router assumes the role of the active router.
Because the new active router assumes both the IP and MAC addresses of the virtual router,
the end stations see little disruption in service. The end-user stations continue to send
packets to the virtual router MAC address, and the new active router delivers the packets to
the destination.
In the event that both the active and standby routers fail, all routers in the group contend for
the active and standby router roles. By default, the lowest MAC address becomes the active
router.
To facilitate load sharing, a single router can be a member of multiple HSRP standby
groups on a single segment. Each standby group emulates a single virtual router.
HSRP Operations 267
Figure 7-6 The Router with the Highest HSRP Priority Becomes the Active Router
Needs to get to
File Server A.
Use MAC address

0000.0c07.ac0a
Router A Virtual Router Router B

Priority 200 172.16.10.110 Priority 100
172.16.10.82 172.16.10.169
0010.f6b3.d000 0010.0b79.5800
0000.0c7.ac0a
Core
File Server A
172.16.3.127
Locating the Virtual Router MAC Address

ARP establishes correspondences between network addresses, such as between an IP
address and a hardware Ethernet address. Each router maintains a table of resolved
addresses. The router checks this ARP cache before attempting to contact a device to
determine if the address has already been resolved. The IP address and corresponding MAC
address of the virtual router are maintained in the ARP table of each router in an HSRP
standby group. Figure 7-7 shows the ARP cache and MAC address used by the virtual
router.
Figure 7-7 The MAC Address Is a Combination of Vendor Code, HSRP Code, and Group Number
Router#show ip arp
HSRP Group 47
172.16.10.82 172.16.10.169
172.16.10.110
Protocol Address Age (min) Hardware Addr Type Interface

Internet 172.16.10.82 – 0010.f6b3.d000 ARPA Vlan10
Internet 172.16.10.169 – 0010.0b79.5800 ARPA Vlan10
Internet 172.16.10.110 – 0000.0c07.ac2f ARPA Vlan10
Vender Code HSRP

Group Number
HSRP Well-Known
Virtual MAC Address
The MAC address used by the virtual router is made up of three components, as shown in
Figure 7-7:
• Vendor ID (Vendor code)—The vendor ID is the first three bytes of the MAC
address. In this case, the vendor ID of 0000.0c indicates that this is a Cisco device.
• HSRP code (HSRP well-known virtual MAC address)—The fact that the MAC
address is for an HSRP virtual router is indicated in the next two bytes of the address.
The HSRP code is always 07.ac.
• Group ID (HSRP group number)—The last byte of the MAC address is the group’s
identification number. For example, the group 47 would be translated to 2f in
hexadecimal and would make up the last byte of the address.
The complete MAC address of the virtual router is therefore 00.00.0c.07.ac.2f.
To display the ARP cache on a router in order to view the MAC address being used, enter
the following command in privileged EXEC mode:
Router# show ip arp
The resulting output from this command displays the information listed in Table 7-1.
HSRP Operations 269
Table 7-1 Information Contained in the ARP Cache

Field Description
Protocol Protocol for the network address in the Address field
Address The network address that corresponds to Hardware Addr
Age (min) Age, in minutes, of the cache entry
Hardware Addr MAC address that corresponds to the network address
Type Type of encapsulation: ARPA (Ethernet), SNAP (RFC 1042), or
SAP (IEEE 802.3)
Interface Interface to which this address mapping has been assigned
In Figure 7-7, the output displays an ARP cache for a Route Switch Module (RSM) that is
a member of HSRP standby group 47 in VLAN10. The virtual router for VLAN10 is
identified as 172.16.10.110. The well-known MAC address that corresponds to this IP
address is 0000.0c07.ac2f, where 2f is the HSRP group identifier for standby group 47.
HSRP Messages
All routers in a standby group send and/or receive HSRP messages. These messages are
used to determine and maintain the router roles within the group. HSRP messages are
encapsulated in the data portion of User Datagram Protocol (UDP) packets, and they use
port number 1985. These packets are addressed to an all-router multicast address of
224.0.0.2 with a Time-To-Live (TTL) of 1. Figure 7-8 shows the format of the HSRP
message.
Figure 7-8 HSRP Message Format
1 Octet 1 Octet 1 Octet 1 Octet
Version Op Code State HelloTime
HoldTime Priority Group Reserved
Authentication Data
Authentication Data
Virtual IP Address
The HSRP message contains the following information (as shown in Figure 7-8):
• The Version field indicates the version of the HSRP.
• The Op Code describes the type of message contained in this packet. Possible values
are as follows:
HSRP Operations 271
• Listen state
• Speak state
• Standby state
• Active state
Not all HSRP routers transition through all states. For example, a router that is not the
standby or active router does not enter the standby or active states.
Initial State
All routers begin in the initial state. This is the starting state, and it indicates that HSRP is
not running. This state is entered via a configuration change or when an interface first
comes up.
Learn State
In the learn state, the router is still waiting to hear from the active router. The router has not
yet seen a hello message from the active router, nor has it learned the IP address of the
virtual router.
Listen State
In the listen state, the router knows the virtual IP address but is neither the active router nor
the standby router. The router listens for hello messages from those routers. Routers other
than the active and standby router remain in listen state.
Speak State
In the speak state, the router sends periodic hello messages and actively participates in the
election of the active and/or standby router. A router cannot enter the speak state unless it
has the IP address of the virtual router.
Standby State
In the standby state, the router is a candidate to become the next active router, and it sends
periodic hello messages. There must be one, and only one, standby router in the HSRP
group.
Configuring HSRP 275
To remove the interface from preempt status, enter the no standby group preempt
command.
Configuring HSRP Over Trunk Links

Figure 7-9 shows the configuration for two HSRP-enabled routers participating in two
separate virtual LANs using Inter-Switch Link. Running HSRP over ISL allows users to
configure redundancy between multiple routers that are configured as front ends for VLAN
IP subnets. By configuring HSRP over ISLs, users can eliminate situations in which a single
point of failure causes traffic interruptions. This feature inherently provides some improve-
ment in overall networking resilience by providing load balancing and redundancy
capabilities between subnets and VLANs.
Figure 7-9 HSRP Can Be Configured Between Two Routers Connected Via Trunk Links
ISL link
carrying both
VLAN10 and 20
traffic
VLAN10 VLAN20 VLAN10 VLAN20
ISL link carrying ISL link carrying

both VLAN10 both VLAN10
and 20 traffic and 20 traffic
172.16.10.110 172.16.20.120
Router A Router B
Virtual Router for Virtual Router for
VLAN10 VLAN20
interface FastEthernet 1/1.10 interface FastEthernet 1/1.10

encapsulation isl 10 encapsulation isl 10
ip address 172.16.10.2 255.255.255.0 ip address 172.16.10.3 255.255.255.0
standby 1 ip 172.16.10.110 standby 1 ip 172.16.10.110
standby 1 priority 105 standby 1 priority 50
standby 1 preempt interface FastEthernet 1/1.20
interface FastEthernet 1/1.20 encapsulation isl 20
encapsulation isl 20 ip address 172.16.20.3 255.255.255.0
ip address 172.16.20.2 255.255.255.0 standby 2 ip 172.16.20.120
standby 2 ip 172.16.20.120 standby 2 priority 105
standby 2 priority 50 standby 2 preempt
To configure HSRP over an ISL link between VLANs, perform the following tasks:
• Define the encapsulation format
• Define the IP address
• Enable HSRP
The first two steps are discussed in Chapter 5, “Inter-VLAN Routing.” You enable HSRP
using the exact same steps discussed earlier.
Configuring Hello Message Timers

An HSRP-enabled router sends hello messages to indicate that the router is running and is
capable of becoming either the active or standby router. The hello message contains the
router’s priority, as well as a hellotime and holdtime value. The hellotime value indicates
the interval between the hello messages that the router sends. The holdtime value contains
the amount of time that the current hello message is considered valid.
If an active router sends a hello message, receiving routers consider that hello message to
be valid for one holdtime.
NOTE The holdtime should be at least three times the value of the hellotime.
Both the hellotime and holdtime parameters can be configured. To configure the time
between hellos and the time before other group routers declare the active or standby router
to be nonfunctioning, enter the following command in interface configuration mode:
Router(config-if)#standby group-number timers hellotime holdtime
group-number (optional) is the group number on the interface to which the timers apply.
The default is 0.
hellotime is the hello interval in seconds. This is an integer from 1 to 255. The default is 3
seconds.
holdtime is the time, in seconds, before the active or standby router is declared to be down.
This is an integer from 1 to 255. The default is 10 seconds.
To reinstate the default standby timer values, enter the no standby group timers command.
HSRP Interface Tracking

In some situations, the status of an interface directly affects which router needs to become
the active router. This is particularly true when each of the routers in an HSRP group has a
different path to resources within the campus network.
In Figure 7-10, Router A and Router B reside in a branch office. These two routers each
support a T1 link to headquarters. Router A has the higher priority and is the active
forwarding router for standby group 47. Router B is the standby router for that group.
Router A and Router B exchange hello messages through their E0 interfaces.
type indicates the interface type (combined with the interface number) that will be tracked.
number indicates the interface number (combined with the interface type) that will be
tracked.
interface-priority (optional) indicates the amount by which the router’s hot standby priority
is decremented when the interface becomes disabled. The router’s priority is incremented
by this amount when the interface becomes available. The default value is 10.
To disable interface tracking, enter the no standby group track command.
Displaying the Status of HSRP

To display the status of the HSRP router, enter the following command in privileged EXEC
mode:
Router#show standby type-number group brief
type-number (optional) indicates the target interface type and number for which output is
displayed.
group (optional) indicates a specific HSRP group on the interface for which output is
displayed.
brief (optional) displays a single line of output summarizing each standby group.
If these optional interface parameters are not indicated, the show standby command
displays HSRP information for all interfaces. Example 7-4 shows the sample output that
results when the type-number and group parameters are specified.
Example 7-4 Output of the show standby Command
Router#show standby Vlan10 47
Vlan11 - Group 47
Local state is Active, priority 150, may preempt
Hellotime 3 holdtime 10
Next hello sent in 00:00:02.944
Hot standby IP address is 172.16.10.1 configured
Active router is local
Standby router is 172.16.10.82 expires in 00:00:08
Standby virtual mac address is 0000.0c07.ac0b
Tracking interface states for 1 interface, 1 up:
Up Vlan51 Priority decrement: 40
Example 7-5 shows the sample output that results when the brief parameter is specified.
Example 7-5 Output of the show standby brief Command
Router#show standby brief
Interface Grp Prio P State Active addr Standby addr Group addr
Vl10 47 150 P Active local 172.16.10.82 172.16.11.1
Vl12 12 100 Standby 172.16.12.82 local 172.16.12.1
Configuring HSRP 279
NOTE When specifying a group, you must designate an interface.
The Cisco IOS implementation of HSRP supports the debug command. Enabling the debug
facility displays the HSRP state changes and debugging information regarding transmission
and receipt of HSRP packets. To enable HSRP debugging, enter the following command in
Router#debug standby
CAUTION Because debugging output is assigned high priority in the CPU process, this command can
render the system unusable. It should be used with extreme caution in a production
network.
Example 7-6 displays the debug standby command output as the router with IP address
172.16.10.82 initializes and negotiates for the role of the active router.
Example 7-6 The debug standby Command
Router#debug standby
3w1d : %STANDBY-6-STATECHANGE: Standby: 0: Vlan10 state Init -> Listen
3w1d : %STANDBY-6-STATECHANGE: Standby: 0: Vlan10 state Listen -> Speak
3w1d :SB0:Vlan10 Hello out 172.16.10.82 Speak pri 150 hel 3 hol 10 ip 172.16.10.1
3w1d : %STANDBY-6-STATECHANGE: Standby: 0: Vlan10 state Speak -> Standby
3w1d : %STANDBY-6-STATECHANGE: Standby: 0: Vlan10 state Standby -> Active
3w1d : SB: Vlan10 Adding 0000.0c07.ac00 to address filter
To disable the debugging feature, enter either the no debug standby or no debug all
command.
NOTE A shorthand version of the disable debug command is u all.

In order to complete this scenario, you must complete the following tasks:
• Configure HSRP on switch block devices to ensure continual inter-VLAN routing.
• Ensure the role of the active router by assigning a preempt status.
Command List
This case study uses the commands listed in Table 7-2.
Table 7-2 Distribution Route Processor Commands
Command Description
interface vlan number Enables interface configuration mode for the specified VLAN
interface.
show arp Displays the ARP table in the router.
shutdown Disables the interface.
show standby vlan vlan-number Displays HSRP information for the specified VLAN
interface.
standby group-number ip virtual-router-ip- Assigns a standby group number and virtual router IP address
address to an interface.
standby group-number preempt Gives the router the ability to take the active role from
another router for this interface.
standby group-number priority Manually assigns a standby priority to an interface.
priority-number
Task 1: Configure HSRP

Complete the following steps to accomplish this task.
Configure HSRP on RSM143

Follow these steps to complete the configuration of HSRP on the first RSM:
Step 1 In global configuration mode, enter the interface vlan vlan-number
command to enter interface configuration mode. The VLAN number
used in this case study is 41.
Step 2 In interface configuration mode, enter the standby group-number ip
virtual-router-ip address command. Use your VLAN number as the
HSRP group-number. The virtual router’s IP address is 172.16.41.145.
Remember that this address must be the same for all routers in the same
standby group, and it must be a valid IP address in the interface’s subnet.
288 Chapter 8: Multicast Overview
application increases as the application’s sophistication increases. Some applications, such

as stock market feeds, can produce up to 1000 packets per second. If not controlled, these
applications can easily overwhelm a network.
Multimedia traffic can work its way through the network using one of several methods:
• Unicast
• Broadcast
• Multicast
Each one of these transmission methods has a different effect on network bandwidth.
Unicast Traffic
With a unicast design, an application sends one copy of each packet to every client unicast
address. Unicast transmission has significant scaling restrictions. If the group is large, the
same information must be carried multiple times, even on shared links. Figure 8-1 shows
that unicast transmission requires that a separate transmission occur for every receiver.
Figure 8-1 Unicast Traffic
Video
Server
1.5 Mb × 3 = 4.5 Mb
1.5 Mb × 2 = 3 Mb 1.5 Mb × 1 = 1.5 Mb
1.5 Mb × 1 = 1.5 Mb
1.5 Mb × 1 = 1.5 Mb 1.5 Mb × 1 = 1.5 Mb
Receiver Receiver Receiver Not a

Receiver
With technology, it is possible to afford the cost of making a unicast connection with every
user who wants to see a specific Web page. However, a server sending audio and video
requires a huge amount of bandwidth when compared with Web applications.
Introduction to Multicasting 291
can use up most, if not all, of the allocated bandwidth for each device. For this reason, the
broadcast multimedia method is rarely implemented.
Multicast Traffic
The most efficient solution is one in which a multimedia server sends one copy of each
packet, addressing each packet to a special address. Unlike the unicast environment, a
multicast server sends out a single data stream to multiple clients. Unlike the broadcast
environment, the client device decides whether or not to listen to the multicast address.
Multicasting saves bandwidth and controls network traffic by forcing the network to
replicate packets only when necessary. By eliminating traffic redundancy, multicasting
reduces network and host processing.
In Figure 8-4, the video server transmits a single video stream for each multicast group. A
multicast (or host) group is defined as a set of host devices listening to a specific multicast
address. The video stream is then replicated as required by the multicast routers and
switches. This technique allows an arbitrary number of clients to subscribe to the multicast
address and receive the broadcast.
Figure 8-4 Multicast Traffic
Video
Server
1.5 Mb
1.5 Mb 1.5 Mb
1.5 Mb 1.5 Mb 1.5 Mb
Receiver Receiver Receiver Not a

Receiver
In the multicast scenario, only 1.5 Mbps of server-to-network bandwidth is utilized, leaving
the remaining bandwidth free for other uses. Within the network, the multicast transmission
Addressing in an IP Multicast Environment 293
IP Multicast Address Structure

The range of IP addresses is divided into classes based on the high-order bits of a 32-bit IP
address. IP multicasting uses Class D addresses. A Class D address consists of 1110 as the
higher-order bits in the first octet, followed by a 28-bit group address. Unlike Class A, B,
and C IP addresses, the last 28 bits of a Class D address are unstructured.
These remaining 28 bits of the IP address identify the multicast group ID. This multicast
group ID is a single address typically written as decimal numbers in the range 224.0.0.0
through 239.255.255.255. The high-order bits in the first octet identify this 224-base
address.
Multicast addresses can be dynamically or statically allocated. Dynamic multicast
addressing provides applications with a group address on demand. Because dynamic
multicast addresses have a specific lifetime, applications must request this type of address
only for as long as the address is needed.
Statically allocated addresses are reserved for specific protocols that require well-known
addresses. The Internet Assigned Numbers Authority (IANA) assigns these well-known
addresses. These addresses are called permanent host groups and are similar in concept to
the well-known TCP and UDP port numbers. Table 8-1 lists some of the well-known Class
D addresses.
Table 8-1 Well-Known Class D Addresses
Class D Address Purpose
224.0.0.1 All hosts on a subnet
224.0.0.2 All routers on a subnet
224.0.0.4 All Distance Vector Multicast Routing Protocol (DVMRP) routers
224.0.0.5 All Open Shortest Path First (OSPF) routers
224.0.0.6 All OSPF designated routers
224.0.0.9 All Routing Information Protocol version 2 (RIPv2) routers
224.0.0.13 All Protocol-Independent Multicast (PIM) routers
Address 224.0.0.1 identifies the all-hosts group. Every multicast-capable host must join this
group at the start. If a ping command is issued using this address, all multicast-capable
hosts on the network must answer the ping request.
Address 224.0.0.2 identifies the all-routers group. Multicast routers must join that group on
all multicast-capable interfaces.
Addresses ranging from 224.0.0.0 through 224.0.0.255 are reserved for local purposes,
such as administrative and maintenance tasks. Multicast routers do not forward datagrams
destined to this range of addresses.
Managing Multicast Traffic in a Campus Network 295
Because 32 multicast addresses can be mapped to a single Ethernet address, the address is
not unique. This correlation means that a host receiving multicasts needs to filter out
multicast packets destined to multicast groups with the same MAC layer multicast address.
Figure 8-6 illustrates how the multicast group address 224.138.8.5, or EA-8A-08-05
expressed in hex, is mapped into an IEEE-802 multicast address. In multicast addressing,
the high-order 9 bits of the IP address are not mapped into the MAC-layer multicast
address. In this example, the mapping places the low-order 23 bits of the IP multicast group
ID into the low-order 23 bits of the IEEE-802 multicast address.
Figure 8-6 224.10.8.5 Translates to a MAC Address of 01.00.5e.0a.08.05
Multicast Address:
224 10 8 5
1110 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 1
Ethernet Address:
01 00 5E 0A 08 05
0 000 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 1
Because the upper 5 bits of the IP Class D address are not used, the mapping can correlate
multiple IP groups into the same EEE-802 address. Therefore, there is a 32-to-1 ratio of IP
Class D addresses to valid MAC-layer multicast addresses.
The Class D addresses 224.10.8.5 and 225.138.8.5 map to the same IEEE-802 MAC-layer
multicast address (01-00-5E-0A-08-05).
The IP host group addresses 224.10.8.5 and 234.138.8.5 have the same MAC address of
01-00-5E-0A-8-5. However, the two groups remain separate because they have different
IP host group addresses.
There is a small chance of collisions should multiple groups happen to have Class D
addresses that map to the same MAC layer multicast address. Usually, higher-layer
protocols let hosts interpret which packets are for the application. It’s extremely unlikely
that two different groups would pick the same Class D address and the same set of UDP
ports.
Managing Multicast Traffic in a Campus Network

Multicasting on a single physical segment is simple. The sending process specifies a
destination address that is defined as a multicast address. The device driver in the sending
server converts this address to the corresponding Ethernet address and sends the package
IGMP messages are specified in the IP datagram with a protocol value of 2. Table 8-2
describes the fields of the IGMP message shown in Figure 8-7.
Table 8-2 IGMPv1 Message Format Fields
Field Name Value
Ver Indicates the IGMP version number.
Type There are two types of IGMP messages of concern to hosts:
1 = Host Membership Query
2 = Host Membership Report
Unused Unused field. Zeroed when sent; ignored when received.
Checksum The checksum is the 16-bit 1’s complement of the 1’s complement
sum of the eight-octet IGMP message. For computing the checksum,
the checksum field is zeroed.
Group Address In a host membership query message, the group address field is
zeroed when sent and ignored when received. In a host membership
report message, the group address field holds the IP host group
address of the group being reported.
IGMPv1: Joining a Group

Hosts joining a group do not have to wait for a query in order to join. When a host wants to
join a multicast group, the host sends a host membership report to the all-router group
address 224.0.0.2. This unsolicited request reduces join latency for the end system when no
other members of that group are present on that network segment.
IGMPv1: General Queries

Multicast routers send host membership query messages to discover which host groups
have members on their attached local networks. General queries go to the all-hosts
(224.0.0.1) multicast address and carry a TTL of 1. One member from each group on the
segment responds with a report. General queries are sent out periodically based on the
setting of the ip igmp query-interval command. (The default setting is 60 seconds.)
There is no formal IGMP query router election process within IGMPv1 itself. Instead, the
election process is left up to the multicast routing protocol, and different protocols use
different mechanisms. This often results in multiple queriers on a single network segment
supporting multiple multicast-enabled routers.
IGMPv2: Packet Format

Version 2 of IGMP made some enhancements to the previous version, including the
definition of a group-specific query. This type of message allows the router to transmit a
specific query to one particular group. IGMPv2 also defines a leave group message for the
hosts, which results in lower leave latency. Figure 8-8 shows the IGMPv2 packet format.
There are four types of IGMP messages of concern to the host-router interaction:
• Membership query
• Version 2 membership report
• Leave report
• Version 1 membership report
The version 1 membership report is used for backward compatibility with IGMPv1. New
message types can be used by newer versions of IGMP or by multicast routing protocols.
Any other message type or unrecognized message types are ignored.
Figure 8-8 IGMPv2 Frame Format
7 15 31
Type Max. Resp. Time Checksum
Group Address
Table 8-3 describes the IGMPv2 message fields shown in Figure 8-8.
Table 8-3 IGMPv2 Message Format Fields
Field Name Value
Type 0 x 11 = Membership query.
0 x 12 = Version 1 membership report.
0 x 17 = Leave report.
Max. Resp. 10 seconds = Default value. Meaningful only in a membership query. Specifies
Time the maximum allowed time before sending a responding report in units of 1/10
(Maximum second.
Response Time) 0 = All other messages.
Checksum Calculated the same as for the ICMP checksum.
Group Address 0 in a general query.
Group address queried in a group-specific query.
Multicast group address in a report.
NOTE Joining and leaving groups does not reflect the host’s joining and leaving a group. It more
accurately reflects a subnet joining and leaving a group. The host device indicates that it
needs to receive a multicast group address. The router is notified that someone on the subnet
needs the address. The subnet is then added to the router’s multicast routing table as long
as a single host is requesting the address.
IGMPv2: Querier Election

IGMPv2 defines a procedure for electing the multicast querier for each network segment.
In IGMPv2, the multicast router with the lowest IP address on the LAN segment is elected
the multicast querier.
Initially, every router on the segment believes itself to be the querier for every one of the
router’s interfaces that are multicast-enabled. When a router is first multicast-enabled, it
begins transmitting query messages. If the router subsequently detects a queried message
that is sourced from a numerically lower IP address, it ceases to act as a querier on that
interface.
The query-interval response time has been added to IGMPv2 to control the burstiness of
reports. This value is indicated in queries to convey to the membership the time interval in
which members must respond to a query with a report message.
A group-specific query also was added in IGMPv2 to allow the router to query membership
in only a single group instead of all groups. This is an optimized way to quickly find out if
any members are left in a group without asking all groups for a report.
The difference between the group-specific query and the general query is that a general
query is multicast to the all-hosts (224.0.0.1) address, while a group-specific query for
group G is multicast to the group G multicast address.
To locate and verify the elected querier, enter the following command in user or privileged
EXEC mode:
RTR141>show ip igmp interface type number
Example 8-1 shows the output of the show ip igmp interface type number command. This
command indicates whether IGMP is enabled for the interface, the version number that is
being used, and the current timers. The designated router is a different function and is listed
separately from Example 8-1. The concept of designated routers is discussed in more detail
in Chapter 9, “Configuring IP Multicast.”
Example 8-1 Locating the Designated Querier Router
RTR141>show ip igmp interface e0
Ethernet0 is up, line protocol is up
Internet address is 172.16.41.141, subnet mask is 255.255.255.0
IGMP is enabled on interface
Current IGMP version is 2
Routing Multicast Traffic 307
located on different subnets, there needs to be a way of determining how to get from the
source to the destinations. This is the function of the IP protocol.
Each host on the Internet has an address that identifies the physical location of the host. Part
of the address identifies the subnet on which the host resides, and part identifies the
individual host on that subnet. Routers periodically send routing update messages to
adjacent routers, conveying the state of the network as perceived by that particular router.
This data is recorded in routing tables that are then used to determine optimal transmission
paths for forwarding messages across the network.
Unicast transmission involves transmission from a single source to a single destination. The
transmission is directed toward a single physical location that is specified by the host
address. This routing procedure is relatively straightforward because of the binding of a
single address to a single host.
Routing multicast traffic is a more complex problem. A multicast address identifies a
particular transmission session rather than a specific physical destination. An individual
host can join an ongoing multicast session by using IGMP to communicate this desire to
the subnet router.
Because the number of receivers for a multicast session can potentially be quite large, the
source should not need to know all the relevant addresses. Instead, the network routers must
somehow be able to translate multicast addresses into host addresses. The basic principle
involved in multicast routing is that routers interact with each other to exchange
information about neighboring routers.
Distribution Trees
For efficient transmission, designated routers construct a tree that connects all members of
an IP multicast group. A distribution tree specifies a unique forwarding path between the
source’s subnet and each subnet containing members of the multicast group.
A distribution tree has just enough connectivity so that there is only one loop-free path
between every pair of routers. Because each router knows which of its lines belong to the
tree, the router can copy an incoming multicast datagram onto all the outgoing branches.
This action generates the minimum needed number of datagram copies. Because messages
are replicated only when the tree branches, the number of copies of the messages
transmitted through the network is minimized.
Because multicast groups are dynamic, with members joining or leaving a group at any
time, the distribution tree must be dynamically updated. Branches that contain new
members must be added. Branches in which no listeners exist must be discarded, or pruned.
Two basic tree-construction techniques exist: source-specific trees and shared, or center-
specific, trees.
Multicast Routing Protocols 313
Dense Mode Routing Protocols

The first approach is based on the assumption that the multicast group members are densely
distributed throughout the network and bandwidth is plentiful, meaning that almost all
hosts on the network belong to the group. These dense mode multicast routing protocols
rely on periodic flooding of the network with multicast traffic to set up and maintain the
distribution tree.
Dense mode routing protocols include the following:
• Distance Vector Multicast Routing Protocol (DVMRP)
• Multicast Open Shortest Path First (MOSPF)
• Protocol-Independent Multicast Dense Mode (PIM DM)
Dense mode operations assume that almost all routers in the network need to distribute
multicast traffic for each multicast group. Dense mode protocols are most appropriate in
environments with densely clustered receivers and the bandwidth to tolerate flooding. An
example of when a dense mode protocol can be used is when a CEO of a company wants
to broadcast a message to all employees within the headquarters campus network.
Distance Vector Multicast Routing Protocol

Distance Vector Multicast Routing Protocol (DVMRP) is described in RFC 1075. DVMRP
is widely used on the Internet multicast backbone (MBONE).
DVMRP uses reverse path flooding. When a router receives a packet, it floods the packet
out of all paths except the one that leads back to the packet source. This technique allows a
data stream to reach all LANs. If a router is attached to a set of LANs that do not want to
receive a particular multicast group, the router can send a prune message back up the
distribution tree to stop subsequent packets from traveling where there are no members.
DVMRP periodically floods packets in order to reach any new hosts that want to receive a
particular group. There is a direct relationship between the time it takes for a new receiver
to get the data stream and the frequency of flooding.
DVMRP implements its own unicast routing protocol in order to determine which interface
leads back to the source of the data stream. This unicast routing protocol is similar to RIP
and is based purely on hop counts. As a result, the path that the multicast traffic follows
might not be the same as the path that the unicast traffic follows.
NOTE Cisco routers run PIM. Cisco routers know enough about DVMRP to successfully forward
multicast packets to and receive packets from a DVMRP neighbor. Cisco routers can also
propagate DVMRP routes into and through a PIM cloud. However, only the PIM protocol
uses this information. Cisco routers do not implement DVMRP to forward multicast
packets.
Multicast Open Shortest Path First

Multicast Open Shortest Path First (MOSPF) is described in RFC 1584. MOSPF is
intended for use within a single routing domain, such as a network controlled by a single
organization. MOSPF is dependent on the use of OSPF as the accompanying unicast
routing protocol. In an OSPF/MOSPF network, each router maintains an up-to-date image
of the topology of the entire network. MOSPF works by including multicast information in
OSPF link-state advertisements. An MOSPF router learns which multicast groups are
active on which LANs.
This link-state information is used to construct multicast distribution trees. MOSPF builds
a distribution tree for each (source, group) pair and computes a tree for active sources
sending to the group. The tree state is cached, and trees must be recomputed when a link-
state change occurs or when the cache times out.
MOSPF is best suited for environments that have relatively few (source, group) pairs active
at any given time. This protocol doesn’t work as well in environments that have many active
sources or in environments that have unstable links.
NOTE Cisco routers do not support MOSPF.
Protocol-Independent Multicast Dense Mode

Protocol-Independent Multicast Dense Mode (PIM DM) is similar to DVMRP. This
protocol works best when numerous members belong to each multimedia group, as shown
in Figure 8-17. PIM floods the multimedia packet out to all routers in the network and then
prunes routers that do not support members of that particular multicast group.
328 Chapter 9: Configuring IP Multicast
Figure 9-1 Planning for Multicasting
Server Block Core Block Switch Block
Distribution Distribution
Video
Switch Switch
Servers Access Host
Switch
Core
IP Multicast IP Prototcol NIC Card IP Multicast IP Prototcol

Application Stack Supporting Application Stack Supporting
Multicast Multicast
The following requirements must be satisfied before you can enable IP multicasting:
• Server and client hosts must have an IP protocol stack that supports multicasting, as
specified in Internet RFC 1112. Full support of this RFC allows hosts to both send and
receive multicast data. TCP/IP stacks supporting Windows Sockets V1.1 and V2.0 are
multicast-enabled.
• Servers and clients must have applications—such as audio broadcast, video broadcast,
or videoconferencing—that support IP multicasting. These applications might have
special requirements for system resources, such as processor speed, memory size,
and, in some cases, recommended network interface cards (NICs) or graphics
accelerator cards.
• NICs on all receiving hosts must be configured to monitor multicast packets in
addition to the usual unicast and broadcast packets. Depending on the network
infrastructure, receiving hosts might also benefit from having intelligent NICs that can
filter out multicasts to unwanted groups, preventing unnecessary interruption to the
host CPU.
• The network must have a high-performance backbone with a Layer 2 or Layer 3
switched connection from the backbone to both the sender and receiver hosts, which
provides a highly scalable LAN infrastructure for multicasting. The switched
infrastructure is desirable because it can provide enough bandwidth to allow unicast
and multimedia applications to coexist within the subnet. With dedicated bandwidth
to each desktop, switching vastly reduces Ethernet collisions that can disrupt real-time
multimedia traffic. A shared media network might prove adequate for low-bandwidth
audio applications or limited pilot projects.
• The network must have switches that are appropriate for multicasting. The most
appropriate switches have a switch architecture that allows multicast traffic to be
forwarded to a large number of attached group members without unduly loading the
366 Chapter 10: Controlling Access to the Campus Network
An access policy might define some or all of the following:

• Management of network devices, including physical security and access control
• User access to the network through the use of mechanisms such as port security and
VLAN management
• Access to distributed and enterprise services
• The traffic that is allowed out of the switch block and onto the core block and
providing for traffic management
• Route filtering to determine the routes that should be seen by the core block and other
switch blocks
The access policy is designed to secure the campus network and to prevent unwanted or
unneeded traffic from getting to the most expensive (and sometimes slowest) areas of the
network. An access policy allows a network administrator to provide a level of service to
users based on a set of defined traffic standards. In addition, an access policy provides a
level of security to campus network devices.
Applying Policies in a Hierarchical Model

Each layer can have a different access policy, because each layer is responsible for a
different task. Some of the policies in the access policy, such as controlling physical access,
apply to all devices in the campus network. Other policies, however, should be defined at
specific layers. As shown in Figure 10-1, each block of the campus network should have an
access policy defined.
Access Layer
The access layer is the entry point to the network for the users. The access policy at this
layer should allow legitimate users into the network while keeping other users out.
Controlling access here should be done through the use of port security and passwords to
protect network devices.
Distribution Layer
The distribution layer is the primary handler of Layer 3 routing decisions for the network.
It should also be the home of most of your access policy. The access policy at this layer can
be as simple as saying that Engineering’s traffic is not allowed to be carried on XYZ
network or as complicated as defining the exact path that information should take. The
access policy at the distribution layer should be responsible for ensuring that only necessary
traffic makes it to the core or to another switch block. The distribution layer is also
responsible for advertising the correct routing and services information to the core.
Managing Network Devices

The policy to control access to network devices should be one of the first components of
the access policy. All devices at every layer of the campus network should have a plan to
provide for the following:
• Physical security
• Passwords
• Privilege levels to allow limited access to a network device
• Limiting virtual terminal or Telnet access
Physical Security
Given physical access to any device, be it a switch, router, server, or workstation, a person
knowledgeable about that device can gain complete control over it. Almost all devices have
a mechanism, or back door, for getting in without a password. A security policy is of little
use without physical security for network devices. A physical security policy should be
defined for every device in your network.
Physically secure your network by doing the following:
• Establish configurations for the access policies—This should be done for devices
at each layer of the hierarchical model. Have a security plan for each site that details
how the device and the links will be secured.
• Provide the proper physical environment—The physical environment should have
provisions for locking the room, proper ventilation and temperature controls, and
backup power.
• Control direct access to the device—Lock racks when possible, and apply
passwords to console and auxiliary ports. Disable ports such as the auxiliary port if
they are not being used.
• Secure access to network links—Provide the same type of security for the wiring
closets that you would provide for the physical equipment.
Assigning Passwords
There are several different ways to access every Cisco device. Every method of accessing
the device should have a password applied in order to prevent unauthorized access.
Out-of-band management options include the following:
• Console 0
• Auxiliary 0
Managing Network Devices 371
The default timeout is 10 minutes. To change the default timeout, enter the following
command:
Router(config-line)#exec-timeout minutes seconds
NOTE You can also prevent access to your terminal session while keeping the session open by
issuing the lock command. You will be prompted for a password. Reenter the password
when you return to your session.
Privilege Levels
The two default levels of access are user and privileged. User level allows the user to
perform certain commands but does not give him or her the ability to modify the
configuration or perform a debug. At the other end of the spectrum, privileged level allows
the user to issue all commands, including configuration and debug commands.
The Cisco IOS command set can provide users with additional levels of privilege with the
use of the privilege level command. This allows network administrators to provide a more
granular set of rights to Cisco network devices.
NOTE Privilege levels are particularly useful in large networks where there are many people who
might need access to a network device. A user can be given the ability to perform trouble-
shooting commands such as show line and show interface without being given the rights
to modify the entire device.
Sixteen different levels of privilege can be set, ranging from 0 to 15. Level 1 is the default
user EXEC privilege. The highest level, 15, allows the user to have all rights to the device.
Level 0 can be used to specify a more limited subset of commands for specific users or lines.
For example, you can allow user “guest” to use only the show users and exit commands.
NOTE Five commands are associated with privilege level 0: disable, enable, exit, help, and
logout. If you configure a centralized authorization server, such as AAA authorization, for
a privilege level greater than 0, these five commands will not be included.
At other privilege levels, you must specify the commands that are to be assigned to that
privilege level.
Figure 10-3 Access List Applied to vty Lines
172.16.1.3
172.16.1.4
Virtual ports (vty 0 through 4)
• Router(config)# access-list 1 permit 172.16.1.3

• router(config)# line vty 0 4
• router(config-line)# access-class 1 in
The line vty vty-number vty-range command takes you into the selected configuration
mode of the virtual terminal lines. The most common version of this command is
line vty 0 4. It indicates that you are modifying the first five virtual terminal lines.
The access-class in|out command applies the access list to the virtual terminal lines. The
access list is a standard access list that indicates which source addresses are either permitted
or denied. The in|out condition at the end of the access-class statement indicates whether
the source address should be allowed to establish a Telnet session with this device or
allowed to Telnet out of this device.
NOTE Access lists that are applied to interfaces (with the access-group command) do not affect
traffic that is originated from that device. For that reason, it is important to apply the virtual
terminal control both inbound and outbound on the virtual terminal lines. Inbound indicates
who can Telnet to this device. Outbound indicates where someone can Telnet to after he is
inside the network device. Use caution when implementing virtual terminal access lists.
You might inadvertently prevent yourself from getting to the device.
Controlling HTTP Access

Cisco IOS software now allows you to use a Web browser to issue Cisco IOS commands to
your network device. The HTTP server software required to do this is found in IOS releases
Table 10-2 ip http authentication Command Options (Continued)

Option Description
local Indicates that the local user database is used for authentication information.
tacacs Indicates that a TACACS server should be used for authentication.
Access Layer Policy

The access layer is the entry point for users to get onto the network. Cable connections are
generally pulled from an access layer switch to offices and cubicles in a company. For this
reason, the network devices of the access layer are the most physically vulnerable. Anyone
can plug a station into an access layer switch.
Several precautions should be taken at the access layer:
• Port security—Limit the MAC addresses that are allowed to use the switch to prevent
unauthorized users from gaining access to the network.
• VLAN management—VLAN 1 is the default VLAN of all ports. VLAN 1 is
traditionally the management VLAN. This means that users who enter the network on
ports that are not configured will be in the management VLAN of the switch block. It
is recommended that the management VLAN be moved to another VLAN in order to
prevent users from entering the network on VLAN 1 on a port that is unconfigured.
NOTE By default, all ports on a switch are enabled and in VLAN 1. Anyone who walks up to an
unused port will be enabled and in VLAN 1 by default. This would result in a security
problem if the switches were left in the default management VLAN. There are two different
philosophies on the handling of this issue. Some companies move the management VLAN
from VLAN 1 to some other VLAN. This allows users to come into the default VLAN but
keeps them from harming any of the network devices. Other companies leave the switches
in VLAN 1 but disable the ports that are not in use. Both methods have their advantages and
disadvantages. When all devices are placed in a VLAN other than VLAN 1, you run the risk
that the VLAN will be deleted, disabling the ports. When you leave the management VLAN
as VLAN 1 and disable all the ports, you have the added administration task of enabling the
ports any time the network changes. The solution is the classic answer to any network
problem: It depends.
Port Security
Port security is a feature of the Cisco Catalyst switches that allows the switch to block input
from a port when the MAC address of a station attempting to access the port is different
Distribution Layer Policy

This section discusses the methods for controlling access at the distribution layer.
Most of the access control policy is implemented at the distribution layer. This layer is also
responsible for ensuring that data stays in the switch block unless it is specifically permitted
outside the switch block. It is also responsible for sending the correct routing and service
information to the core.
A good policy at the distribution layer ensures that the core block or the WAN blocks are
not burdened with traffic that has not been explicitly permitted. It also protects the core and
the other switch blocks from receiving incorrect information, such as incorrect routes, that
might harm the rest of the network.
Access control at the distribution layer falls into several different categories. They can do
the following:
• Define which user traffic makes it between VLANs and thus ultimately to the core.
This can be done in the form of an access list applied to an interface to permit only
certain data to pass through.
• Define which routes are seen by the core block and ultimately by the switch block.
This can be done through the use of distribution lists to prevent routes from being
advertised to the core.
• Define which services the switch block will advertise to the rest of the network.
Service control could also be used to define how the network finds the server-
aggregation block in order to get services such as Dynamic Host Configuration
Protocol (DHCP) and Domain Name System (DNS).
Controlling Information with Filters

Many of the access control methods used at the distribution layer rely on the creation of an
access control list. There are two types of IP access lists:
• Standard
• Extended
Each type of access list is a series of permits and denies based on a set of test criteria. The
standard access list allows for a test criteria of only the source address. The extended access
list allows a greater degree of control by checking the source and destination addresses as
well as the protocol type and the port number or the packet’s application type. A standard
access list is easier for the router to process, but an extended access list provides a greater
degree of control.
Distribution Layer Policy 379
NOTE An access list is a way of defining traffic based on protocols, addressing, and port numbers.
It does nothing to the router until it is applied. Access lists can have many different
applications, including traffic filtering, defining interesting traffic, defining priority traffic,
and so on. The creation of the access list is always the same process. It is the application of
the access list that determines how it will be used.
An access list does nothing until it is applied. Access lists are created for a variety of
applications. They can be used to control access in the campus network by being applied in
different capacities. These include, but are not limited to, the following:
• Applying the access list to the interface for traffic management purposes through the
use of the protocol access-group command, where protocol is the Layer 3 protocol
that is being managed.
• Applying the access list to a line for security purposes through the use of the access-
class command. This determines the users of a specific line. This book focuses on the
virtual terminal lines.
• Managing routing update information through the use of the distribute-list
command. This determines which routes are learned by the router and which routes
are advertised out of the router.
• Managing services update information through the use of commands such as ipx
output-sap-filter in order to determine which services are advertised.
Standard Access Lists

IP standard access lists have the following characteristics:
• The test condition is based on the source address only.
• Numbered standard access lists are 1 to 99.
• The access list is processed top-down, line by line. As soon as a match is found, the
access list stops processing.
• There is an implicit deny of everything at the end of every access list. If no match is
found in the access list, it will ultimately match the implicit deny at the end of the list.
• The creation of the access list does nothing until the access list is applied.
Figure 10-5 shows that standard access lists check on the source address, either inbound or
outbound. This access list allows only the source address of 172.16.1.3. It denies everything
else.
Figure 10-6 Extended Access Lists Allow for a More Granular Check of the Packet
G0/0
access-list 104 permit tcp any 172.16.2.0 0.255.255.255

access-list 104 permit tcp any host 172.16.1.2 eq smtp
access-list 104 permit udp any eq domain any
access-list 104 permit icmp any any echo
access-list 104 permit icmp any any echo-reply
!
interface gigabit0/0
ip access-group 104 out
Filtering Routing Update Traffic

Controlling the core block’s routing table has several advantages:
• Reduces the size of the routing table at the core block, allowing it to process packets
faster
• Prevents users from getting to networks that have not been advertised unless they have
a static or default route to get there
• Prevents incorrect information from propagating through the core block
There are several ways to control the routing information that is sent to the core block:
• Route summarization—Depending on the routing protocol used, a summarized
entry of all the switch block’s available routes can be sent from the distribution layer
to the core.
Summary 385
In Figure 10-7, the options for the networks of 172.16.x.0 (except 172.16.2.0) include the
following:
• All other networks will be able to send and receive data in the switch block but will
not be allowed to get to any other switch block or get to the core block. In order for
this to work, a static or default route will have to be configured.
• No other networks will be seen by the core block and other switch blocks. A default
or static route will allow them to send data to and receive data from other switch
blocks, including the core.
Core Layer Policy

The core layer is responsible for moving data as quickly as possible. All the devices that are
designed to be core layer solutions are optimized to move data as quickly as possible. For
this reason, the core layer should have little to no policy.
The only policies that should be applied at the core layer are those that relate to quality of
service (QoS) commands for congestion management and congestion avoidance.
NOTE The implementation of QoS at the core layer varies greatly, depending on the Cisco device
deployed at the core and which version of IOS is running. Check the CCO Web site for
device-specific information.
Summary
This chapter covered the access policies that can be applied to each layer in the campus
switch model. Defining and documenting a corporate access policy is an important step in
maintaining a secure and predictable campus network. This chapter covered the following:
• Controlling physical devices at all layers with the use of passwords, logins, and
privilege levels to allow for a more granular set of rights for network administrators
• Preventing unauthorized access to your network through the use of port security
• Controlling access at the distribution layer using access lists in a variety of ways,
including route distribution, traffic management at the interface, and virtual terminal
management
092-2.book Page 8 Thursday, August 2, 2001 2:38 PM
8 Chapter 1: Troubleshooting Methodology
Figure 1-2 Most network troubleshooting takes place at Layers 2 and 3 of the seven-layer OSI reference model.
Network processes to
7 Application applications
6 Presentation Data representation
5 Session Interhost communication
4 Transport End-to-end connections
3 Network Addresses and best path
2 Data Link Framing and local addressing
1 Physical Binary transmission
As a result of these factors, today’s internetworks are complex. Internetworks have become a
mixture of protocols, technologies, media, and topologies. With this added complexity comes
the potential for difficult connectivity and performance problems. Difficult problems require a
systematic problem-solving model.
In this chapter we’ll examine how a problem-solving model can be the most effective way to
reduce the time required to troubleshoot the network.
The Problem-Solving Model

The complexity and crucial uptime requirements of modern networks intensify the pressures to
solve connectivity and performance problems. The best way to approach an internetworking
problem is to develop a standard troubleshooting methodology. The problem-solving model
presented in Figure 1-3 is one example of such a methodology. Using an ordered pattern of
thought when troubleshooting helps you solve any problems you encounter. It also helps you
and your organization improve overall expertise as your organization supports its internetwork.
The Problem-Solving Model 9
Figure 1-3 This reliable problem-solving model is only one of many, and is the one we work with in this book.
Start Define Problem Finished
Gather Facts Document Facts
Consider Possiblilities Problem Resolved
Create Action Plan
Y
Implement Action Plan
Do
Problem
Observe Results Symptoms
Stop?
N
Iterate Process
Figure 1-3 shows a sequence of steps. These steps can be grouped into a small number of
troubleshooting phases:
• Make sure you have a clear, sufficient definition of the problem.
• Gather all the relevant facts and consider the likely possibilities.
• Create and implement an action plan for the most likely possibility, and then observe the
results.
• If the symptoms do not stop, try another action plan (or gather additional facts).
• If the symptoms do stop, document how you resolved the problem.
NOTE This problem-solving model is one of many such models you can use. If you are already using
another model (based on an alternative model or learned through experience), you should
continue to use it. If in your past experience you have not approached problems systematically
and not considered using a problem-solving model, you should adopt a scheme such as the one
outlined in this chapter.
At this point, the aim is to consider possible causes. Subsequent steps in the methodology allow
you to ask questions (that is, gather facts) such as whether Host 3 and Host 4 are getting any
response from Host A and Host B, whether Host 1 can communicate with Host 2, whether the
WAN link is operational, and so on.
A systematic approach to troubleshooting consists of a sequence of steps. The first grouping of
these steps is to make sure you have a clear, sufficient definition of the problem, and then to
gather all the relevant facts. In this group of steps, you should use (and at the same time, be
skeptical of) the initial diagnosis made by the end users. What the end user reports is important;
however, the full definition of the problem may have a broader basis. If possible, proceed from
your own knowledge about your internetwork and try to see the problem for yourself.
As part of the systematic approach to troubleshooting, many support teams have developed a
set of primary questions and processes to use when getting problem report information from
end users. Among the primary questions are “How often has this problem happened?” and
“When did it start?” and “Can you readily reproduce the problem condition, and if so, how?”
The problem statements that you form must be with reference to the baselines that you have
established for your networks. You should know what your network indicators look like when
the network is performing as you expect it to. Also, you must have knowledge of the network
aspects that have changed since the last evidence of baseline performance.
To define the problem, identify the general symptoms and then ascertain what possible kinds of
problems (causes) could result in these symptoms.
The following might be possible causes of the communications problems at Host 1 and Host 2:
• Faulty interface cards installed in Host 1 and Host 2.
• Host 1 and Host 2 require a default gateway, and this has not been configured.
• Misconfigured subnet masks exist on Host 1 and Host 2 or in Router X.
• Network R has a faulty device attached to it that causes excessive collisions on the
Ethernet cable.
• Either Router X or Router Y has a misconfigured access list, causing traffic from the
affected hosts to be blocked.
• There is a problem with the WAN link.
• The routers are not configured with valid mapping statements for the protocol.
• Host A and Host B are not configured to recognize Host 1 and Host 2.
There might be several other possibilities, but first you should concentrate on those that could
be considered major contributors to the symptom.
Figure 1-5 You can rule out possible problems one at a time.
Network R Network S
Host A
Excess Collisions
Interface
Cards,
Default Host 1 X
Y Configuration
Gateway
Subnet WAN
Masks
Host 2 Host B
Token Access
Ring
Lists,
Mapping
Host 3 Statements
Network T
Host 4
• Faulty interface cards installed in Host 1 and Host 2.

You can eliminate this possible cause because Host 1 can communicate with Host 2.
• Host 1 and Host 2 require a default gateway, and this has not been configured.
You can eliminate this possible cause because Host 1 and Host 2 can
communicate with Host 3 and Host 4.
• Misconfigured subnet masks exist on Host 1 and Host 2 or in Router X.
You can eliminate this possible cause because Host 1 and Host 2 can
communicate with Host 3 and Host 4.
• Network R has a faulty device attached to it that causes excessive collisions on the
Ethernet cable.
You can eliminate this possible cause because Host 1 and Host 2 can communicate
with Host 3 and Host 4. Also, Host 1 can communicate with Host 2.
• Either Router X or Router Y has a misconfigured access list, causing traffic from the
affected hosts to be blocked.
This is still a possible cause. You cannot eliminate it based on any of the facts gathered.
• There is a problem with the WAN link.
You can eliminate this possible cause because Host 3 and Host 4 can communicate
with Host A and Host B.
why it is always important to have a backout plan to undo your changes and restore the network
to its previous state.
For the sample problem, having considered Router X first and finding that reconfiguring or
disabling the access list did not solve the problem, you must repeat the process loop.
You must now implement the next step of the action plan. Check to see if your work results in
a legal access list that accomplishes the intended traffic filtering. Make additional changes as
required.
A further iteration of the process to consider is the configuration of Router Y (see Figure 1-7).
Perhaps the access list on Router X is working but the problem is an inbound access list at the
other end of the internetwork. The loop must be repeated, making necessary configuration
changes to Router Y and again observing the results.
The iterations must continue until the problem is solved. Systematically eliminate each of the
possible causes until you isolate and confirm the cause or causes so you can fix the problem.
Figure 1-7 Now that Router X has been eliminated as the problem, you can telnet to Router Y. Notice that on
Router X you can restore the original configuration by reapplying the access list to the interface.
Network R Network S
Host A
Telnet Console
Host 1 X
WAN
Y
Host 2 Host B
Token
Ring ip access-list extended connect
permit icmp any any
Host 3 permit tcp any 172.16.0.0 0.0.255.255 eq telnet
Network T deny tcp any any
interface s 0
no ip access-group connect
Host 4 ip access-group connect
Preparing Yourself to Troubleshoot 19
Figure 1-8 Today’s networks are complex. Are you up to the challenge?
Inter-
Switch FDDI
Link IBM Mainframe
(ISL) with FEP
Token Token
Ring Ring
LAN Switch
Token T1/E1 Dial

IBM 3274 Ring
Backup
Point-to-Point
Load
SDLC SMDS, X.25, Dial Sharing
Frame Relay Backup
LAN
Switch
Protocol
VLANs Transfer
Dial-on-
Demand
LAT Host ASCII X Window
• Do you have an accurate physical and logical map of your internetwork? Does your
organization or department have an up-to-date internetwork map that outlines the physical
location of all the devices on the network and how they are connected, as well as a logical
map of network addresses, network numbers, subnetworks, and so on?
• Do you have a list of all network protocols implemented in your network? For each of the
protocols implemented, do you have a list of the network numbers, subnetworks, zones,
areas, and so on that are associated with them?
• Do you know which protocols are being routed? For each of these protocols do you have
a correct, up-to-date router configuration?
• Do you know which protocols are being bridged? Are there any filters configured in any
of these bridges, and do you have a copy of these configurations?
• Do you know all the points of contact to external networks, including any connections to
the Internet? For each external network connection, do you know which routing protocol
is being used?
26 Chapter 2: Protocol Characteristics Overview
A reliable protocol is a protocol that has error correction, flow control, and retransmission
functionality built into it. Unreliable protocols depend on higher-layer protocols to provide
reliability. An example of sending data reliably is sending a letter via certified mail with a return
receipt. Unreliable data delivery would simply be dropping the letter in the mail box and having
best-effort delivery.
Most connection-oriented protocols are reliable, and most connectionless protocols are
unreliable, but there are exceptions. For example, Frame Relay is a connection-oriented
protocol. It requires virtual circuit connectivity before data can be sent, but there are no
reliability mechanisms built into Frame Relay. Likewise, Open Shortest Path First (OSPF) is
connectionless. When OSPF sends out routing updates, it sends multicast packets (which are
by definition connectionless), yet it still expects to see acknowledgments from its neighbors.
All the connection-oriented protocols discussed in this section are reliable protocols.
An entity can transmit data to another entity in an unplanned fashion and without prior
coordination. This is known as connectionless data transfer, in which each packet stands alone.
The receiving software entity that is part of the Open System Interconnection (OSI) reference
model protocol stack sees that the packets received are complete, but a higher-layer application
must put them in the proper order, manage timeout counters, and request the retransmission of
missing packets.
Connection-Oriented Services
A connection-oriented data transfer is conceptually similar to a telephone call in which the
caller initiates the call, knows when the connection is made because a person is heard at the
other end of the line, and hangs up and terminates the call when the information exchange is
complete.
A connection-oriented protocol has some method for connection establishment, flow control,
error control, and session termination. TCP and Asynchronous Transfer Mode (ATM) are
examples of connection-oriented protocols.
A connection-oriented protocol ensures that packets are in order and manages timeout counters.
That connection-oriented protocol also requests retransmission of missing packets.
With connection-oriented data transfer, a logical association, or connection, is established
between protocol entities. As shown in Figure 2-1, this type of data transfer has a clearly
distinguishable lifetime, consisting of three distinct phases:
• Connection establishment
• Data transfer
• Connection termination
Basic Protocol Characteristics 27
Figure 2-1 The connection establishment phase (which occurs first in connection-oriented services) is often referred
to as a handshake.
Protocol Connection Request Protocol

Entity Entity
Connection Acknowledgment
Data and Acknowledgments
CT620201.eps
Terminate–Connection Request
Terminate–Connection Acknowledgement
Depending on the protocol, a specific protocol entity might always establish and terminate
the connection. However, in some protocols, either side can initiate these functions.
Connection-oriented data transfer is preferable to connectionless data transfer when stations
require a lengthy exchange of data or certain details of their protocol must be worked out
dynamically. TCP is an example of a connection-oriented protocol, and Asynchronous Transfer
Mode (ATM) is another.
When troubleshooting connection-oriented protocols, check whether there are multiple
retransmissions of segments of data. If there are, determine why the higher-layer protocol is
requesting them. Verify that sequence numbers, acknowledgments, window sizes, and other
parameters associated with this type of protocol are appropriate and are being incremented or
managed correctly.
NOTE Refer to the section “Detailed Protocol Characteristics” later in this chapter for more specific
examples of connection-oriented communications.
Connectionless Services
With connectionless services, there is no connection setup between the two communicating
protocol entities (see Figure 2-2). Each data unit is transmitted independently of previous and
subsequent data units. A connectionless data transfer is conceptually similar to a set of
postcards, each postcard handled separately. So, too, each packet stands alone. An entity can
transmit data to another entity in an unplanned fashion and without prior coordination.
At the network layer are two types of protocols. Routed protocols send user data between hosts.
Routing protocols communicate information between routers about the network paths to use.
The connection sequences that protocol suites use involve both of these types of protocols as
well as higher-layer protocols within the protocol suites. This chapter describes the following
concepts:
• TCP/IP using Address Resolution Protocol (ARP) and synchronization (SYN) packets
• Novell NetWare Core Protocol (NCP) using Routing Information Protocol (RIP), Service
Advertising Protocol (SAP), and Get Nearest Server (GNS) requests
• AppleTalk using several of the protocols in its protocol suite, including Routing Table
Maintenance Protocol (RTMP), Zone Information Protocol (ZIP), Name Binding Protocol
(NBP), and AppleTalk Transaction Protocol (ATP).
Let’s take a look at the different connection sequences that occur with TCP/IP, NetWare, and
AppleTalk. Each protocol set has a unique connection establishment routine.
The TCP Connection Sequence

TCP is an example of a connection-oriented protocol. The TCP connection establishment
sequence is often called a three-way handshake, as shown in Figure 2-3.
Figure 2-3 The three-way handshake must be completed successfully before data can be exchanged.
Host B
Host A WAN
X Y
TCP SYN
Three-
TCP SYN - ACK
Way
Handshake
TCP ACK
A three-way handshake consists of three stages:

• The host that wants to initiate the session sends a TCP synchronization (SYN) packet.
• The receiving host acknowledges the SYN and in the same packet sends its own SYN.
• The original host acknowledges the receipt of the SYN from the other host.
Figure 2-3 also shows Host A sending an ARP request and receiving a reply. The ARP frames
are not part of a TCP session establishment, but are necessary for Host A to reach Host B.
Until Host A receives an ARP reply, it only knows the IP address of Host B. A MAC address
must be determined in order to transmit data. Our example assumes that Host A’s software sends
ARP frames even when the destination is not local and the router responds to ARP frames for
hosts on the other side. (The router runs proxy ARP, which is the default for Cisco Systems
routers.)
A different, but correct, interpretation of the ARP frames shown in Figure 2-3 is that Host A is
configured with Router X as its default router and must send an ARP to learn the MAC address
of Router X.
ARP establishes correspondences between network addresses (an IP address, for example) and
LAN hardware addresses (Ethernet addresses). A record of each correspondence is kept in a
cache for a predetermined amount of time and then discarded.
When you are troubleshooting, use the show ip arp command to check for any anomalies (such
as duplicate routes) and to see whether the host(s) in question is appearing in the ARP table.
NOTE See the section “Detailed Protocol Characteristics” later in this chapter for more information on
the TCP/IP protocol suite.
The NetWare Connection Sequence

NetWare has two types of connection sequences: Sequenced Packet Exchange (SPX) and NCP
connections. NetWare uses SPX to provide transport-layer, connection-oriented services. In a
manner similar to TCP, an SPX client requests synchronization with a peer SPX device. An
acknowledgment reply completes SPX’s two-way handshake process. SPX ensures the
guaranteed delivery of data in order, just as TCP does.
Novell’s NCP is also a connection-oriented protocol used by file servers and clients. Before a
client can log in to an NCP file server and start requesting or sending data, the client first
broadcasts a SAP GNS request, as shown in Figure 2-4.
Figure 2-4 NetWare clients must perform service discovery before connecting to a server.
Server
Client WAN
X Y
RIP and SAP Broadcasts
GNS Request
GNS Reply
RIP Request
RIP Reply
NCP Request (with Sequence Number)
CT620204.eps
NCP Reply (with Sequence Number)
A router or server can respond to the request. Routers learn about services by listening to SAP
broadcasts from servers and other routers. After a client learns about a server, it sends a RIP
request to find a route to the server. Finally, the client can send NCP requests to log in and send
and retrieve data.
NCP requests and replies contain a sequence number field to ensure that packets arrive in order
and that no packets are missing.
NetWare versions 3.x and 4.x use IPX for Layer 3 connectivity, addressing, and routing.
Interconnecting NetWare clients on LANs running IPX face a variety of problems that can
impair connecting to a server over a routed Internet. These can include mismatched network
numbers and encapsulation types. It is important to proceed with a systematic troubleshooting
method to obtain facts to help you isolate the problem or problems. Among the several Cisco
Internetwork Operating System (IOS) tools to help you isolate problems is the show ipx
interface command. This command can be used to verify network and encapsulation
configurations as well as the status of the router interfaces. The show ipx traffic command can
be used for verifying the sending and receiving of packets from the protocols described
previously in this chapter.
The interfaces should indicate that the interface is up and that the protocol is up.
NOTE See the section “Detailed Protocol Characteristics” later in this chapter for more information on
the Novell NetWare protocol suite.
The AppleTalk Connection Sequence

ATP is a transport-layer, connection-oriented protocol that is used by both AppleTalk Filing
Protocol (AFP) and Printer Access Protocol (PAP). It provides reliable transport of data when
a client attaches to an AppleShare file server or printer.
Before a client can attach to a file server (or printer), it must locate the server through a process
called service discovery. A Macintosh computer sends a GetZoneList request to the local router
to fill the Chooser window with zone names. When the user clicks on a zone name and type of
service, the Macintosh sends an NBP broadcast request, as shown in Figure 2-5.
Figure 2-5 AppleTalk uses a combination of protocols to locate and connect to a service.
Server
Client WAN
X Y
RTMP Broadcasts and ZIP Queries and Replies
ZIP GetZoneList Request
ZIP GetZoneList Reply
NBP Broadcast Request NBP Forward Request NBP Lookup
NBP Lookup Reply

CT620205.eps
ATP Request
ATP Reply
Detailed Protocol Characteristics 33
The router looks in its zone information table to determine which networks are in the requested
zone. The router forwards the request to a router for each network in the zone. The receiving
router then sends an NBP lookup request onto its local network. All servers of the requested
service type respond to the original requesting Macintosh. (The address of the original
requesting Macintosh is carried inside the NBP frames.)
When the client Macintosh knows how to reach a file server, it sets up a connection using ATP
and AFP. It may also send an Echo frame in order to determine how much time it takes to reach
the server. This information can be used for setting ATP timeout values.
A variety of problems can block access to servers and services on an AppleTalk network. For
example, the Cisco IOS software command show appletalk traffic provides a good high-level
overview of the AppleTalk activity on the router.
Another source of troubleshooting information is to look for an AppleTalk configuration
mismatch. A mismatch occurs when the following rule of AppleTalk is violated: “All routers
on a given cable must agree on the configuration of that cable (meaning that all must have
matching network numbers, cable ranges, zone names, or zone lists).” The router declares a
port configuration mismatch in the output of the show appletalk interface command.
NOTE See the following section “Detailed Protocol Characteristics” for more information on the
AppleTalk protocol suite.
Detailed Protocol Characteristics

Although this section starts in quite general terms, it quickly delves into the complexities of the
protocol sets and operation of 802.3, 802.5, FDDI, Point-to-Point Protocol (PPP), Synchronous
Data Link Control (SDLC), Frame Relay, ISDN, TCP/IP, NetWare IPX/SPX, and AppleTalk
networks.
Let’s start this discussion with the infamous OSI reference model. When discussing
communication between or among computer systems, it is helpful to adopt a common set of
standards or conventions. The International Organization for Standardization (ISO) developed
the OSI reference model as a framework for defining standards for linking heterogeneous
computers.
The OSI reference model includes a vertical set of layers. Each layer performs the functions
required to communicate with the associated layer of another system. Each layer relies on the
next lower layer to provide a set of services and at the same time provides services to the next
higher layer. ISO finalized a reference model that has seven layers, and then defined each layer
and the services to be performed there. Figure 2-6 shows the seven layers of the OSI model.
Figure 2-6 The OSI model has seven layers.
7 Application
6 Presentation
5 Session
4 Transport
3 Network
CT620206.eps
2 Data Link
1 Physical
The OSI layers and their functions are as follows:

• Layer 7, the application layer, specifies the user interface and the application program
interface and is concerned with the meaning of data, job management, and data exchange.
• Layer 6, the presentation layer, accepts data from the application layer and negotiates data
syntax, representation, compression, and encryption with peer systems.
• Layer 5, the session layer, adds control mechanisms such as checkpoints, terminations,
and restarts to establish, maintain, and synchronize communication between applications.
• Layer 4, the transport layer, provides end-to-end accountability and ensures reliable data
delivery using acknowledgments, sequence numbers, and flow control mechanisms.
• Layer 3, the network layer, specifies network routing (using symbolic addressing) and
communication between network segments.
• Layer 2, the data link layer, is responsible for data transfer over a communication channel
by consolidating data into frames, detecting and recovering from transmission errors, and
defining physical device addresses.
• Layer 1, the physical layer, deals with the mechanical, electrical, functional, and
procedural interface between user equipment and the network communications system—
in other words, “getting bits onto the wire.”
The intent of the OSI model is that protocols be developed to perform the functions of each
layer to enable communication between corresponding (peer) entities at the same layer in two
different systems.
Regardless of the nature of the applications or entities attempting to exchange data, there is
usually a requirement that data be exchanged reliably; that is, all the data should arrive at the
destination process in the same order in which it was sent.
Connection-Oriented Versus Connectionless Protocols

In order for applications or entities in different systems to communicate with each other, some
form of protocol must define a set of rules (that is, the syntax and semantics) governing the
exchange of data between the two.
A fundamental aspect of any communications architecture is that one or more protocols operate
at each layer of the architecture, and that two peer protocols at the same layer but in different
systems cooperate to achieve the communication function.
A set of functions forms the basis of most protocols. These functions might be present in
protocols at the different conceptual layers. Although we are looking at the concept of protocols
within the seven-layer OSI model, some vendors’ protocols are proprietary. However, these
protocols can be viewed as fitting within one or more of the OSI model’s layers.
Protocol functions can be grouped into the following categories:
• Data segmentation and reassembly
• Data encapsulation
• Connection control
• Ordered delivery of data
• Flow control
• Error control
• Multiplexing
This section focuses on aspects of a protocol’s connection characteristics that cover connection
control, ordered delivery, flow control, and error control. Earlier in this chapter we talked about
two types of protocols—connection oriented and connectionless. The connection-oriented
protocols are likened to a telephone call, where we make certain there is a user at the other end
before sending data, whereas connectionless services are more like a postcard in the mail, with
no guarantee of delivery.
Connectionless Data Transfer

An entity can transmit data to another entity in an unplanned fashion and without prior
coordination. This is known as connectionless data transfer, in which each packet stands alone.
The receiving software entity that is part of the OSI protocol stack sees that the packets received
are complete, but a higher-layer application must put them in the proper order and request the
retransmission of missing packets. Although this mode can be useful, it is less common than
connection-oriented transfer.
With connectionless data transfer, no logical connection is established and each PDU is
transmitted independently of any previous or subsequent data unit. Figure 2-7 illustrates this
concept.
Figure 2-7 Connectionless data transfer has low overhead compared to connection-oriented services.
End Station End Station
Data transfer
Multiple
Exchanges
Data transfer
The stations make an a priori agreement with each other, but not with the lower-layer services,
about transmission of protocol data units (PDUs).
Because no connection is established, each data unit is transmitted with a single service access,
and this access must contain all the information necessary for the unit to be delivered to its
destination (destination address, services required, and so on). As a result of this single-service
access, no negotiation of parameters occurs. Also, because the PDUs are transported by the
service provider, which knows no relationship between current, previous, or subsequent data
units, they do not include ordered delivery, flow control, or error control.
The following are examples of connectionless protocols:
• IEEE 802.2 (often referred to as Logical Link Control [LLC]) offers three types of service,
two of which are connectionless: Type 1 provides unacknowledged connectionless
service, and Type 3 provides acknowledged connectionless service.
• OSI offers both a connectionless and connection-oriented network-layer service. The
connectionless service is described in ISO 8473 (usually referred to as Connectionless
Network Protocol [CLNP]).
• Internet Protocol (IP) is the network-layer connectionless protocol in the TCP/IP suite.
User Datagram Protocol (UDP) is the connectionless transport-layer protocol in the
TCP/IP suite.
• AppleTalk’s primary network-layer protocol is Datagram Delivery Protocol (DDP). DDP
provides connectionless service between network sockets.
• Novell’s IPX is a connectionless network-layer datagram protocol for NetWare networks
functioning on IPX/SPX. NetWare 5 can run directly over TCP/IP and replaces IPX
functionality with UDP in that case.
• DECnet uses CLNP and Connectionless Network Service (CLNS) for connectionless
service.
• Fast Sequenced Transport (FST) is a connectionless, sequenced transport protocol that
runs on top of IP. FST uses the IP header to implement sequencing without violating the
IP specification. FST transports remote source-route bridging (RSRB) packets to peers
without TCP or UDP header or processor overhead.
A logical connection also allows for the use of sequencing, which means that each PDU is
sequentially numbered. The end stations maintain a list of locally generated outgoing numbers
and incoming numbers. Sequencing allows for ordered delivery, flow control, and error control.
These concepts can be explained as follows:
• Ordered delivery—In a connection-oriented environment, because each PDU is identified
by a connection identifier and sequence number, correct ordering of PDUs can be
maintained. A unique sequential numbering scheme is determined during the connection
establishment phase. The receiving station can use the sequential numbering scheme to
easily reorder received PDUs, even if they arrive out of order.
• Flow control—With flow control, the transmitting station does not send data or
information faster than the receiving station or any intermediate device can handle it.
Again, with a connection-oriented protocol, the sequence numbers provide this function.
The fundamental approach used with most protocols is a windowing technique in which
the receiving station specifies how much buffer space is available for incoming PDUs. The
sender sends that amount of data in PDUs and then waits to receive acknowledgment from
the receiving station that it has received all or some of these PDUs and is ready to receive
more.
• Error control—An end station detects damaged PDUs by performing a calculation on the
bits received. If a PDU is damaged or lost, the end station requests retransmission of the
affected PDU based on its record of sequence numbers.
The final phase of a connection-oriented operation is the termination of the connection. This
can be initiated by any of the parties involved. Either of the end stations or the central authority,
if one is involved, can send a termination request.
The following are examples of connection-oriented protocols:
• IEEE 802.2 (LLC) offers three types of service, one of which, Type 2, is connection
oriented. LLC Type 2 (LLC2) is a connection-oriented OSI data link layer protocol that is
widely used in local-area network (LAN) environments, particularly among IBM
communication systems connected by Token Ring.
• ATM is a connection-oriented environment. All traffic to or from an ATM network is
prefaced with a virtual path identifier (VPI) and virtual channel identifier (VCI). A VPI/
VCI pair is considered a single virtual circuit (VC). Each VC is a private connection to
another node on the ATM network. Each ATM node must establish a separate connection
to every other node in the ATM network that it wants to communicate with.
Ethernet was developed by Xerox Corporation’s Palo Alto Research Center (PARC) in the
1970s. Digital Equipment Corporation, Intel Corporation, and Xerox Corporation jointly
developed and released an Ethernet specification (Version 2.0) that is substantially compatible
with IEEE 802.3. IEEE 802.3 was first approved by the Institute of Electrical and Electronic
Engineers (IEEE) board in 1983. Together, Ethernet and IEEE 802.3 currently maintain the
greatest market share of any LAN protocol. Today, the term Ethernet is often used to refer to
all carrier-sense multiple access collision detection (CSMA/CD) LANs that generally conform
to Ethernet specifications, including IEEE 802.3.
Ethernet was developed to fill the middle ground between long-distance, low-speed networks
and specialized computer-room networks carrying data at high speeds for very limited
distances. Ethernet is well suited to applications where a local communication medium must
carry bursty, occasionally heavy traffic at high peak data rates.
Ethernet and IEEE 802.3 specify similar technologies. Both are CSMA/CD LANs. Stations on
a CSMA/CD LAN can access the network at any time. Before sending data, CSMA/CD stations
listen to the network to see if it is already in use. If it is, the station that wants to transmit waits,
in a sort of “deferral process.” If the network is not in use, the station transmits. A collision
occurs when two stations listen for network traffic, hear none and transmit simultaneously. In
this case, both transmissions are damaged and the stations must retransmit later. A backoff
algorithm determines when the colliding stations retransmit. CSMA/CD stations can detect
collisions, so they know when they must retransmit.
Both Ethernet and IEEE 802.3 hubbed and repeated LANs are broadcast networks. In other
words, all stations see all frames, regardless of whether they represent an intended destination.
Each station must examine received frames to determine whether the station is a destination. If
it is, the frame is passed to a higher protocol layer for appropriate processing. Layer 2 bridges
and switches dynamically change this model by limiting unnecessary traffic propagation.
Differences between Ethernet and IEEE 802.3 LANs are subtle. Ethernet provides services
corresponding to Layers 1 and 2 of the OSI reference model, and IEEE 802.3 specifies the
physical layer (Layer 1) and only a portion of Layer 2. IEEE 802.2 specifies the remaining
portion of Layer 2 (the LLC portion). Both Ethernet and IEEE 802.3 are implemented in
hardware as either an interface card in a host computer or circuitry on a primary circuit board
within a host computer.
IEEE 802.3 specifies several different physical layers, whereas Ethernet defines only one. Each
IEEE 802.3 physical layer protocol has a name that summarizes its characteristics. The coded
components of an IEEE 802.3 physical layer name are shown in Figure 2-9.
Figure 2-9 The IEEE 802.3 physical layer name components describe its functionality.
Base = Baseband
Broad = Broadband
LAN Speed, in Mbps Maximum LAN Segment Length,

in 100-Meter Multiples
CT620209.eps
10Base5
Table 2-1 is a summary of Ethernet Version 2 and IEEE 802.3 characteristics.

Table 2-1 Ethernet Version 2 and IEEE 802.3 physical characteristics.
Ethernet
Characteristic Value 802.3 Values
10Base5 10Base2 1Base5 10BaseT 100BaseT 10Broad36
Data rate 10 10 10 1 10 100 10
(Mbps)
Signaling Baseband Baseband Baseband Baseband Baseband Baseband Broadband
method
Maximum 500 500 185 250 100 100 1800
segment length
(m)
Media 50-ohm 50-ohm 50-ohm Unshielded Unshielded Unshielded 75-ohm
coax (thick) coax (thick) coax (thin) twisted pair twisted pair twisted pair coax
Topology Bus Bus Bus Star Star Star Bus
Ethernet is most similar to IEEE 802.3 10Base5. Both protocols specify a bus-topology
network with a connecting cable between the end stations and the actual network medium. In
the case of Ethernet, that cable is called a transceiver cable. The transceiver cable connects to
a transceiver device attached to the physical network medium. The IEEE 802.3 configuration is
similar, except that the connecting cable is referred to as an attachment unit interface (AUI), and
the transceiver is called a medium attachment unit (MAU). In both cases, the connecting cable
attaches to an interface board (or interface circuitry) within the end station. Figure 2-10 shows
the Ethernet and IEEE 802.3 frame formats.
Figure 2-10 The type and length fields differentiate Ethernet_II and IEEE 802.3 frame formats.
Ethernet
7 1 6 6 2 46–1500 4
Preamble S Destination Source Type Data FCS

O Address Address
F
IEEE 802.3
7 1 6 6 2 46–1500 4
Preamble S Destination Source Length 802.2 Header FCS

O Address Address and Data
F
SOF = Start-of-Frame Delimiter

FCS = Frame Check Sequence
Both Ethernet and IEEE 802.3 frames begin with an alternating pattern of ones and zeros called
a preamble. The preamble tells receiving stations that a frame is coming.
The byte before the destination address in both an Ethernet and an IEEE 802.3 frame ends with
two consecutive 1 bits, which synchronize the frame reception portions of all stations on the
LAN. The IEEE 802.3 specification defines this as the start-of-frame delimiter (SFD),
following a 7-byte preamble, whereas the Ethernet specifications simply include this pattern
at the end of the 8-byte preamble.
The control field identifies the particular PDU and specifies various control functions. It is 1 or
2 bytes long, depending on the type of PDU. The PDU can be either a command or a response
and is either an information transfer, a supervisory, or an unnumbered information PDU.
The network-layer information field carries the upper-layer protocol data.
An extension to the LLC was defined by the Internet community in RFC 1042, primarily to
encapsulate IP datagrams and ARP requests and replies within IEEE 802.3, IEEE 802.4 (Token
Bus), IEEE 802.5 (Token Ring), and FDDI networks. Doing this allows IP datagrams, which
have historically been tied to Ethernet frames, to be transported across non-Ethernet networks
through a Subnetwork Access Protocol (SNAP) mechanism. Figure 2-12 shows the SNAP
frame format.
Figure 2-12 SAP AA fields indicate a SNAP frame.
7 1 6 6 2 46-1500 4
S 802.2
Preamble Destination Source Length FCS
O SNAP
Address Address
F Header and data
1 1 1 3 2
DSAP SSAP Control OUI Ether Network-Layer Information

AA (Hex) AA (Hex) Type
SNAP Header
The first 3 bytes of the 802.2 portion of the frame are the same as for the LLC frame. The DSAP
and SSAP fields have the special value AA (hex, indicating that this is a SNAP-format frame).
Following the control field is a 5-byte protocol identifier; the first 3 bytes represent the
organizational unit identifier (OUI), a unique value that is assigned to an organization by the
IEEE. The remaining 2 bytes contain information that is similar to the type field used in an
Ethernet frame.
For more information on Ethernet, IEEE 802.3, or other network types, refer to Appendix C,
“References and Recommended Reading.”
Token Ring/IEEE 802.5

Token Ring was originally developed by IBM in the early 1980s. It is still IBM’s primary LAN
technology, and is second only to Ethernet/IEEE 802.3 in general LAN popularity. The IEEE
802.5 specification is almost identical to IBM’s Token Ring network. In fact, the IEEE 802.5
specification was modeled after IBM Token Ring and continues to shadow IBM’s Token Ring
development. The term Token Ring is generally used to refer to both IBM’s Token Ring
networks and IEEE 802.5 networks.
Token Ring and IEEE 802.5 networks are compatible, although the specifications differ in
relatively minor ways. IBM’s Token Ring network specifies a star, with all end stations attached
to a device called a multistation access unit (MSAU), whereas IEEE 802.5 does not specify a
topology (although virtually all IEEE 802.5 implementations are also based on a star). There
are other differences, including media type (IEEE 802.5 does not specify a media type, and
IBM Token Ring networks primarily use twisted pair) and routing information field size. In
some cases, the specifications are identical. Both IBM Token Ring and IEEE 802.5 specify the
following:
• Baseband signaling
• Token passing
• Data rates of either 4 or 16 Mbps
Token Ring and IEEE 802.5 are the primary examples of token-passing networks. Token-
passing networks move a small frame, called a token, around the network. Possession of the
token grants the right to transmit. If a node receiving the token has no information to send, it
simply passes the token to the next end station. Each station has a limitation on the amount of
time that it can hold the token.
If a station that possesses the token has information to transmit, it alters 1 bit of the token (which
turns the token into a start-of-frame sequence), appends the information it wants to transmit,
performs a CRC calculation on the contents of the frame, and sends this information to the next
station on the ring. While the information frame is circling the ring, there is no token on the
network (unless the ring supports early token release), so other stations that want to transmit
must wait. Therefore, collisions cannot occur in Token Ring networks. If early token release is
supported, a new token can be released when frame transmission is completed. Although there
may be multiple frames on the ring, there can be only one token on the ring at any time.
The information frame circulates the ring until it reaches the intended destination station, which
copies the information for further processing. The information frame continues to circle the ring
and is finally removed when it reaches the sending station. The sending station can check the
returning frame to see whether the frame was seen and subsequently copied by the destination.
The sending station is responsible for stripping the frame off the ring once it has returned.
Token Ring networks use several mechanisms for detecting and compensating for network
faults. For example, one station in the Token Ring network is selected to be the active monitor.
This station, which can potentially be any station on the network, acts as a centralized source
of timing information for other ring stations and performs a variety of ring maintenance
functions. One of these functions is the removal of continuously circulating frames from the
ring. When a sending device fails, its frame might continue to circle the ring. This can prevent
other stations from transmitting their own frames and essentially lock up the network. The
active monitor can detect such frames, remove them from the ring, and generate a new token.
The Token Ring network’s star topology also contributes to overall network reliability. Because
all information in a Token Ring network is seen by active MSAUs, intelligent versions of these
devices can be programmed to check for problems and selectively remove stations from the ring
if necessary.
A Token Ring process called beaconing detects and tries to repair certain network faults.
Whenever a station detects a serious problem with the network (such as a cable break), it sends
a beacon frame. The beacon frame defines a fault domain, which includes the station reporting
the failure, its nearest active upstream neighbor (NAUN), and everything in between.
Beaconing initiates a process called autoreconfiguration, where nodes within the fault domain
automatically perform diagnostics in an attempt to reconfigure the network around the failed
areas. Physically, the MSAU can accomplish this through electrical reconfiguration.
Token Ring networks support a sophisticated priority system that permits high-priority
applications to use the network more frequently than lower-priority applications. Token Ring
frames have two fields that control priority: the priority field and the reservation field.
Only stations with a priority equal to or higher than the priority value contained in a token can
seize that token. After the token is seized and changed to an information frame, only stations
with a priority value higher than that of the transmitting station can reserve the token for the
next pass around the network. When the next token is generated, it includes the higher priority
of the reserving station. Stations that raise a token’s priority level must reinstate the previous
priority after their transmission is complete.
Token Ring networks define two frame types: tokens and data/command frames. Figure 2-14
shows both formats.
Figure 2-14 The IEEE 802.5 and IBM Token Ring frame formats are identical.
Data/Command Frame
1 1 1 6 6 Variable 1 1 1
Start Access Frame Destination Source Data FCS End Frame

Delimiter Control Control Address Address Delimiter Status
Token
Start Access End

Delimiter Control Delimiter
Tokens
A token is 3 bytes long and consists of a start delimiter, an access control byte, and an end
delimiter.
The start delimiter alerts each station that a token (or data/command frame) has arrived. This
field includes signals that distinguish the byte from the rest of the frame by violating the
encoding scheme used elsewhere in the frame.
The access control byte contains the priority and reservation fields (used to allow some devices
more frequent access to the token); a token bit (used to differentiate a token from a data/
command frame); and a monitor bit (used by the active monitor to determine whether a frame
is circling the ring endlessly).
Finally, the end delimiter signals the end of the token or data/command frame. It also contains
bits to indicate a damaged frame and a frame that is the last in a logical sequence.
Data/Command Frames
Data/command frames vary in size, depending on the size of the data (information) field. Data
frames carry information for upper-layer protocols; command frames contain control
information and have no data for upper-layer protocols.
In data/command frames, a frame control byte follows the access control byte. The frame
control byte indicates whether the frame contains data or control information. In control frames,
this byte specifies the type of control information.
Following the frame control byte are the two address fields that identify the destination and
source stations. As with IEEE 802.3, addresses are 6 bytes long.
The data field follows the address fields. The length of this field is limited by the token holding
timer, which defines the maximum time a station can hold the token.
Following the data field is the FCS field. This field is filled by the source station with a
calculated value dependent on the frame contents. The destination station recalculates the value
to determine whether the frame was damaged in transit. If it was damaged, the frame is
discarded.
As with the token, the end delimiter signifies the end of the data/command frame. However,
unlike the token, the frame status byte follows the end delimiter in a data/command frame. The
frame status field includes the address recognized and frame-copied indicators. The address
recognized indicator allows the destination station to indicate that it recognized the destination
address. The frame-copied indicator allows the destination station to indicate that it copied the
frame data.
For more information on Token Ring technology, refer to Appendix C, “References and
Recommended Reading.”
FDDI
The FDDI standard was produced by the ANSI X3T9.5 standards committee in the mid-1980s.
During this period, high-speed engineering workstations were beginning to tax the capabilities
of existing LANs (primarily Ethernet and Token Ring). A new LAN technology was needed that
could easily support these workstations and their new distributed applications. At the same
time, network reliability was becoming an increasingly important issue as system managers
began to migrate mission-critical applications from large computers to networks. FDDI was
developed to fill these needs.
After completing the FDDI specification, American National Standards Institute (ANSI)
submitted FDDI to the ISO. ISO has created an international version of FDDI that is completely
compatible with the ANSI standard version.
FDDI has gained a substantial following that continues to increase as the cost of FDDI
interfaces decreases. FDDI is frequently used as a backbone technology as well as a means to
connect high-speed computers in a local area.
FDDI specifies a 100-Mbps, token-passing, dual-ring LAN using a fiber-optic transmission
medium. It defines the physical layer and the media-access portion of the data link layer and is
roughly analogous to IEEE 802.3 and IEEE 802.5 in its relationship to the OSI reference model.
FDDI is similar to Token Ring, although it operates at faster speeds. The two networks share
many features, including topology (ring), media-access technique (token passing), and
reliability features (beaconing, for example).
One of FDDI’s most important characteristics is its use of optical fiber as a transmission
medium. Optical fiber offers several advantages over traditional copper wiring:
• Security—Fiber does not emit electrical signals that can be tapped.
• Reliability—Fiber is immune to electrical interference.
• Speed—Fiber has much higher throughput potential than copper cable.
FDDI defines the use of two types of fiber: single mode (sometimes called monomode) and
multimode. Modes can be thought of as bundles of light rays entering the fiber at a particular
angle. Single-mode fiber allows only one mode of light to propagate through the fiber, and
multimode fiber allows multiple modes of light to propagate through the fiber. Because multiple
modes of light propagating through the fiber might travel different distances (depending on the
entry angles), causing them to arrive at the destination at different times (a phenomenon called
modal dispersion), single-mode fiber is capable of higher bandwidth and greater cable run
distances than multimode fiber. Due to these characteristics, single-mode fiber is often used for
campus backbones, and multimode fiber is often used for workgroup connectivity. Multimode
fiber uses light-emitting diodes (LEDs) as the light-generating devices, and single-mode fiber
generally uses lasers.
FDDI is defined by four separate specifications (see Figure 2-15).
Figure 2-15 There are several FDDI standards for Layer 1 and 2 connectivity.
Logical Link Control
Media Access Control
Station FDDI
Physical-Layer Protocol Management Standards
CT620215.eps
Physical-Layer Medium
The following list explains these specifications in more detail:

• Physical-Layer Medium Dependent (PMD)—Defines the characteristics of the
transmission medium, including the fiber-optic link, power levels, bit error rates,
optical components, and connectors.
• Physical-Layer Protocol (PHY)—Defines data encoding/decoding procedures, clocking
requirements, framing, and other functions.
Each FDDI DAS has two ports designated A and B. These ports connect the station to the dual
FDDI ring. Therefore, each port provides a connection for both the primary and the secondary
ring, as Figure 2-17 shows.
Figure 2-17 FDDI DASs connect Port A to Port B.
Primary Primary
Port A Port B
Secondary Secondary
CT620217.eps
FDDI DAS
FDDI supports real-time allocation of network bandwidth, making it ideal for a variety of
application types. FDDI provides this support by defining two types of traffic: synchronous
and asynchronous. Synchronous traffic can consume a portion of the 100-Mbps total bandwidth
of an FDDI network, and asynchronous traffic can consume the rest. Synchronous bandwidth
is allocated to stations that require continuous transmission capability. This capability is useful
for transmitting voice and video information, for example. Other stations use the remaining
bandwidth asynchronously. FDDI’s SMT specification defines a distributed bidding scheme to
allocate FDDI bandwidth.
Asynchronous bandwidth is allocated using an eight-level priority scheme. Each application
can be assigned an asynchronous priority level. FDDI also permits extended dialogues, where
stations can temporarily use all asynchronous bandwidth by using a reserved token. FDDI’s
reserved token mechanism can essentially lock out stations that cannot use synchronous
bandwidth.
FDDI provides several fault-tolerant features. The primary fault-tolerant feature is the dual ring.
If a station on the dual ring fails or is powered down, or if the cable is damaged, the dual ring
is automatically “wrapped” (that is, doubled back onto itself) into a single ring, as shown in
Figure 2-18. In this figure, when Station 3 fails, the dual ring is automatically wrapped in
Stations 2 and 4, forming a single ring. Although Station 3 is no longer on the ring, network
operation continues for the remaining stations.
PPP
In the late 1980s, the Internet began to experience explosive growth in the number of hosts
supporting IP. The vast majority of these hosts were connected to LANs of various types,
Ethernet being the most common. Most of the other hosts were connected through wide-area
networks (WANs) such as X.25 public data networks (PDNs). Relatively few of these hosts
were connected with simple point-to-point (that is, serial) links. Yet point-to-point links are
among the oldest methods of data communications, and almost every host supports point-to-
point connections.
One reason for the small number of point-to-point IP links was the lack of a standard Internet
encapsulation protocol. PPP was designed to solve this problem. In addition to solving the
problem of standardized Internet encapsulation of IP over point-to-point links, PPP was also
designed to address other issues, including assignment and management of IP addresses,
asynchronous (start/stop) and bit-oriented synchronous encapsulation, network protocol
multiplexing, link configuration, link quality testing, error detection, and option negotiation
for such capabilities as network-layer address negotiation and data compression negotiation.
PPP addresses these issues by providing an extensible Link Control Protocol and a family of
Network Control Protocols to negotiate optional configuration parameters and facilities. Today,
PPP supports other protocols besides IP, including IPX and DECnet.
PPP provides a method for transmitting datagrams over serial point-to-point links. It has three
main components:
• A method for encapsulating datagrams over serial links—PPP uses HDLC as a basis for
encapsulating datagrams over point-to-point links.
• An extensible Link Control Protocol to establish, configure, and test the data-link
connection.
• A family of Network Control Protocols for establishing and configuring different
network-layer protocols. PPP is designed to allow the simultaneous use of multiple
network-layer protocols.
In order to establish communications over a point-to-point link, the originating PPP station
first sends LCP frames to configure and (optionally) test the data link. After the link has been
established and optional facilities have been negotiated as needed by the LCP, the originating
PPP sends Network Control Protocol frames to choose and configure one or more network-
layer protocols. When each of the chosen network-layer protocols has been configured, packets
from each network-layer protocol can be sent over the link. The link remains configured for
communications until explicit LCP or NCP frames close the link or until some external event
occurs (for example, an inactivity timer expires or a user intervenes).
PPP can operate across any data terminal equipment (DTE)/data circuit-terminating equipment
(DCE) interface (for example, EIA/TIA-232, EIA/TIA-422, EIA/TIA-423, or ITU-T V.35). The
only absolute requirement imposed by PPP is the provision of a duplex circuit, either dedicated
or switched, that can operate in either an asynchronous or synchronous bit-serial mode,
The PPP LCP provides a method of establishing, configuring, maintaining and terminating the
point-to-point connection. LCP goes through four distinct phases:
Step 1 Link establishment and configuration negotiation—Before any network-
layer datagrams (for example, IP) can be exchanged, LCP must first open
the connection and negotiate configuration parameters. This phase is
complete when a configuration acknowledgment frame has been both
sent and received.
Step 2 Link quality determination—LCP allows an optional link quality
determination phase following the link establishment and configuration
negotiation phase. In this phase, the link is tested to determine whether the
link quality is sufficient to bring up network-layer protocols. This phase is
optional. LCP can delay transmission of network-layer protocol information
until this phase is completed.
Step 3 Network-layer protocol configuration negotiation—When LCP has finished
the link quality determination phase, network-layer protocols can be
separately configured by the appropriate NCP and can be brought up and
taken down at any time. If LCP closes the link, it informs the network-layer
protocols so that they can take appropriate action.
Step 4 Link termination—LCP can terminate the link at any time. This is usually
done at the request of a user, but can happen because of a physical event such
as the loss of carrier or the expiration of an idle-period timer.
There are three classes of LCP frames:
• Link establishment frames—Used to establish and configure a link.
• Link termination frames—Used to terminate a link.
• Link maintenance frames—Used to manage and debug a link.
These frames are used to accomplish the work of each of the LCP phases.
For more information on PPP, refer to Appendix C, “References and Recommended Reading.”
SDLC and Derivatives

IBM developed the SDLC protocol in the mid-1970s for use in Systems Network Architecture
(SNA) environments. SDLC was the first of an important new type of link-layer protocols
based on synchronous, bit-oriented operation. Compared to synchronous character-oriented
(for example, Bisync from IBM) and synchronous byte-count-oriented protocols (for example,
Digital Data Communications Message Protocol [DDCMP] from Digital Equipment
Corporation), bit-oriented synchronous protocols are more efficient, more flexible, and often
faster.
After developing SDLC, IBM submitted it to various standards committees. The ISO modified
SDLC to create the HDLC protocol. The Consultative Committee for International Telegraph
and Telephone (CCITT), which is now the Telecommunication Standardization Sector of the
ITU (the ITU-T), subsequently modified HDLC to create Link Access Procedure (LAP) and
then Link Access Procedure, Balanced (LAPB). The IEEE modified HDLC to create IEEE
802.2. Each of these protocols has become important in its own domain. SDLC remains SNA’s
primary link-layer protocol for WAN links.
SDLC supports a variety of link types and topologies. It can be used with point-to-point and
multipoint links, half-duplex and full-duplex transmission facilities, and circuit-switched and
packet-switched networks.
SDLC identifies two types of network nodes:
• Primary—Controls the operation of other stations (called secondaries). The primary polls
the secondaries in a predetermined order. Secondaries can then transmit if they have
outgoing data. The primary also sets up and tears down links and manages the link while
it is operational.
• Secondary—Secondaries are controlled by a primary. Secondaries can only exchange
information with primary, but they cannot send unless the primary gives permission.
SDLC primaries and secondaries can be connected in four basic configurations:
• Point-to-point—Involves only two nodes, one primary and one secondary.
• Multipoint—Involves one primary and multiple secondaries.
• Loop—Involves a loop topology, with the primary connected to the first and last
secondaries. Intermediate secondaries pass messages through one another as they respond
to the primary’s requests.
• Hub go-ahead—Involves an inbound and an outbound channel. The primary uses the
outbound channel to communicate with the secondaries. The secondaries use the inbound
channel to communicate with the primary. The inbound channel is daisy-chained back to
the primary through each secondary.
Figure 2-23 shows the SDLC frame.
Although it omits several features used in SDLC, HDLC is generally considered to be a

compatible superset of SDLC. LAP is a subset of HDLC. LAPB was created to ensure ongoing
compatibility with HDLC, which was modified in the early 1980s. IEEE 802.2 is a modification
of HDLC for LAN environments. Qualified Logical Link Control (QLLC) is a link-layer
protocol defined by IBM that allows SNA data to be transported across X.25 networks.
HDLC
HDLC shares SDLC’s frame format, and HDLC fields have the same purpose as those in
SDLC. Also, like SDLC, HDLC supports synchronous, full-duplex operation.
HDLC differs from SDLC in several minor ways. First, HDLC has an option for a 4-byte
checksum. Also, unlike SDLC, HDLC does not support the loop or hub go-ahead configurations.
Also, HDLC has a 2-byte control field, allowing for a 7-bit window size (128 values) rather than
the 3-bit (8 values) that SDLC allows.
The major difference between HDLC and SDLC is that SDLC supports only one transfer mode,
and HDLC supports three. The three HDLC transfer modes are as follows:
• Normal response mode (NRM)—This transfer mode is used by both HDLC and SDLC.
In this mode, secondaries cannot communicate with a primary until the primary has given
permission.
• Asynchronous response mode (ARM)—This transfer mode is used by HDLC only and
allows secondaries to initiate communication with a primary without receiving permission.
• Asynchronous balanced mode (ABM)—ABM introduces the combined node. A
combined node can act as a primary or a secondary, depending on the situation. All ABM
communication is between multiple combined nodes. In ABM environments, any
combined station can initiate data transmission without permission from any other.
LAPB
LAPB is best known for its presence in the X.25 protocol stack. LAPB shares the same frame
format, frame types, and field functions as SDLC and HDLC. Unlike either of these, however,
LAPB is restricted to the ABM transfer mode, and so is appropriate only for combined stations.
Also, LAPB circuits can be established by either the DTE or the DCE. The station initiating the
call is determined to be the primary, and the responding station is the secondary. Finally, LAPB
use of the P/F bit is somewhat different from that of the other protocols.
IEEE 802.2
IEEE 802.2 is often referred to as LLC. It is extremely popular in LAN environments, where it
interoperates with protocols such as IEEE 802.3, IEEE 802.4, and IEEE 802.5. IEEE 802.2
Figure 2-26 An ATM network comprises ATM switches and endpoints.
Router
LAN Switch ATM Switch
Workstation
DSU/CSU
ATM Endpoints
ATM Network Interfaces

An ATM network consists of a set of ATM switches interconnected by point-to-point ATM links
or interfaces. ATM switches support two primary types of interfaces: User-Network Interface
(UNI) and Network-to-Network Interface (NNI). The UNI connects ATM end-systems (such as
hosts and routers) to an ATM switch. The NNI connects two ATM switches.
Depending on whether the switch is owned and located at the customer’s premises or publicly
owned and operated by the telephone company, UNI and NNI can be further subdivided into
public and private UNIs and NNIs. A private UNI connects an ATM endpoint and a private ATM
switch. Its public counterpart connects an ATM endpoint or private switch to a public switch.
A private NNI connects two ATM switches within the same private organization. A public one
connects two ATM switches within the same public organization.
Figure 2-27 illustrates the ATM interface specifications for private and public networks.
• Payload type (PT)—Indicates in the first bit whether the cell contains user data or control
data. If the cell contains user data, the second bit indicates congestion, and the third bit
indicates whether the cell is the last in a series of cells that represent a single AAL5 frame.
• Congestion loss priority (CLP)—Indicates whether the cell should be discarded if it
encounters extreme congestion as it moves through the network. If the CLP bit equals 1,
the cell should be discarded in preference to cells with the CLP bit equal to zero.
• Header error control (HEC)—Calculates checksum only on the header itself.
Figure 2-28 An ATM cell, ATM UNI cell, and ATM NNI cell header each contain 48 bytes of payload.
VPI VPI
GFC
Header VCI VCI
(5 bytes)
PT CLP PT CLP
HEC HEC
53
Bytes
Payload Payload Payload

(48 bytes) (48 bytes) (48 bytes)
8 Bits
ATM Cell ATM UNI Cell ATM NNI Cell
ATM Services
Three types of ATM services exist: permanent virtual circuits (PVCs), switched virtual circuits
(SVCs), and connectionless service (which is similar to Switched Multimegabit Data Service
[SMDS]).
A PVC allows direct connectivity between sites. In this way, a PVC is similar to a leased line.
Among its advantages, a PVC guarantees availability of a connection and does not require call
setup procedures between switches. Disadvantages of PVCs include static connectivity and
manual setup.
An SVC is created and released dynamically and remains in use only as long as data is being
transferred. In this sense, it is similar to a telephone call. Dynamic call control requires a
signaling protocol between the ATM endpoint and the ATM switch. The advantages of SVCs
include connection flexibility and call setup that can be handled automatically by a networking
device. Disadvantages include the extra time and overhead required to set up the connection.
ATM networks are fundamentally connection-oriented, which means that a virtual channel
must be set up across the ATM network prior to any data transfer. (A virtual channel is roughly
equivalent to a virtual circuit.)
Two types of ATM connections exist: virtual paths (VPs), which are identified by virtual path
identifiers, and virtual channels (VCs), which are identified by the combination of a VPI and a
VCI.
A virtual path is a bundle of virtual channels, all of which are switched transparently across the
ATM network on the basis of the common VPI. All VCIs and VPIs, however, have only local
significance across a particular link and are remapped, as appropriate, at each switch.
A transmission path is a bundle of VPs. Figure 2-29 illustrates how VCs concatenate to create
VPs, which, in turn, concatenate to create a transmission path.
Figure 2-29 Multiple VCs are bundled together to create VPs.
VC VP VP VC
CT620229.eps
Transmission Path
VC VP VP VC
ATM Switching Operation

The basic operation of an ATM switch is straightforward: The cell is received across a link on
a known VCI or VPI value. The switch looks up the connection value in a local translation table
to determine the outgoing port (or ports) of the connection and the new VPI/VCI value of the
connection on that link. The switch then retransmits the cell on that outgoing link with the
appropriate connection identifiers. Because all VCIs and VPIs have only local significance
across a particular link, these values are remapped, as necessary, at each switch.
The ATM Reference Model

The ATM architecture uses a logical model to describe the functionality it supports. ATM
functionality corresponds to the physical layer and part of the data link layer of the OSI
reference model.
The ATM physical layer has four functions: Bits are converted into cells; the transmission and
receipt of bits on the physical medium are controlled; ATM cell boundaries are tracked; and
cells are packaged into the appropriate type of frame for the physical medium.
AAL1, a connection-oriented service, is suitable for handling circuit-emulation applications,
such as voice and video conferencing. Circuit-emulation service also accommodates the
attachment of equipment currently using leased lines to an ATM backbone network. AAL1
requires timing synchronization between the source and destination. For this reason, AAL1
depends on a medium, such as SONET, that supports clocking.
AAL3/4 supports both connection-oriented and connectionless data. It was designed for
network service providers and is closely aligned with SMDS. AAL3/4 is used to transmit
SMDS packets over an ATM network.
AAL5 is the primary AAL for data and supports both connection-oriented and connectionless
data. It is used to transfer most non-SMDS data, such as classical IP over ATM and LAN
Emulation (LANE).
ATM Addressing
The ITU-T standard is based on the use of E.164 addresses (similar to telephone numbers) for
public ATM (BISDN) networks. The ATM Forum extended ATM addressing to include private
networks. ITU-T decided on the subnetwork or overlay model of addressing, in which the ATM
layer is responsible for mapping network-layer addresses to ATM addresses. This subnetwork
model is an alternative to using network-layer protocol addresses (such as IP and IPX) and
existing routing protocols (such as IGRP and RIP). The ATM Forum defined an address format
based on the structure of the OSI network service access point (NSAP) addresses.
The Subnetwork Model of Addressing The subnetwork model of addressing
decouples the ATM layer from any existing higher-layer protocols, such as IP or IPX. As such,
it requires an entirely new addressing scheme and routing protocol. All ATM systems must be
assigned an ATM address, in addition to any higher-layer protocol addresses. This requires an
ATM address resolution protocol (ATM_ARP) to map higher-layer addresses to their
corresponding ATM addresses.
NSAP-Format ATM Addresses The 20-byte NSAP-format ATM addresses are designed
for use within private ATM networks, whereas public networks typically use E.164 addresses,
which are formatted as defined by ITU-T. The ATM Forum did specify an NSAP encoding for
E.164 addresses, which will be used for encoding E.164 addresses within private networks, but
this address also can be used by some private networks.
Such private networks can base their own (NSAP format) addressing on the E.164 address
of the public UNI to which they are connected and can take the address prefix from the E.164
number, identifying local nodes by the lower-order bits.
ATM QOS
ATM supports quality of service (QOS) guarantees comprising traffic contract, traffic shaping,
and traffic policing.
A traffic contract specifies an envelope that describes the intended data flow. This envelope
specifies values for peak bandwidth, average sustained bandwidth, and burst size, among
others. When an ATM end system connects to an ATM network, it enters a “contract” with
the network based on QOS parameters.
Traffic shaping is the use of queues to constrain data bursts, limit peak data rate, and smooth
jitters so that traffic will fit within the promised envelope. ATM devices are responsible for
adhering to the contract by means of traffic shaping. ATM switches can use methods known
as traffic policing to enforce the contract. The switch can measure the actual traffic flow and
compare it against the agreed-upon traffic envelope. If the switch finds that traffic is outside the
agreed-upon parameters, it can set the cell-loss priority (CLP) bit of the offending cells. Setting
the CLP bit makes the cell “discard eligible,” which means that any switch handling the cell is
allowed to drop the cell during periods of congestion.
LANE
LANE is a standard defined by the ATM Forum that provides to stations attached via ATM the
same capabilities they normally obtain from legacy LANs, such as Ethernet and Token Ring.
As the name suggests, the function of the LANE protocol is to emulate a LAN on top of an ATM
network. Specifically, the LANE protocol defines mechanisms for emulating either an IEEE
802.3 Ethernet or an 802.5 Token Ring LAN. The current LANE protocol does not define a
separate encapsulation for FDDI. (FDDI packets must be mapped into either Ethernet or Token
Ring emulated LANs [ELANs] by using existing translational bridging techniques.) Fast
Ethernet (100BaseT) and IEEE 802.12 (100VG-AnyLAN) both can be mapped unchanged
because they use the same packet formats. Figure 2-32 compares a physical LAN and an ELAN.
The LANE protocol defines a service interface for higher-layer (that is, network-layer)
protocols that is identical to that of existing LANs. Data sent across the ATM network is
encapsulated in the appropriate LAN MAC packet format. Simply put, the LANE protocols
make an ATM network look and behave like an Ethernet or Token Ring LAN—albeit one
operating much faster than an actual Ethernet or Token Ring LAN network.
It is important to note that LANE does not attempt to emulate the actual MAC protocol of the
specific LAN concerned (that is, CSMA/CD for Ethernet or token passing for IEEE 802.5).
LANE requires no modifications to higher-layer protocols to enable their operation over an
ATM network. Because the LANE service presents the same service interface of existing MAC
protocols to network-layer drivers (such as an NDIS- or ODI-like driver interface), no changes
are required in those drivers.
Addressing fields in call setup packets provide source and destination DTE addresses.
These are used to establish the virtual circuits that constitute X.25 communication. ITU-T
Recommendation X.121 specifies the source and destination address formats. X.121 addresses
(also referred to as international data numbers, or IDNs) vary in length and can be up to 14
decimal digits long. Byte 4 in the call setup packet specifies the source DTE and destination
DTE address lengths. The first four digits of an IDN are called the data network identification
code (DNIC). The DNIC is divided into two parts: the first (three digits) specifying the country
and the last specifying the PSN itself. The remaining digits are called the national terminal
number (NTN) and are used to identify the specific DTE on the PSN. Figure 2-37 shows the
X.121 address format.
Figure 2-37 X.25 uses the X.121 address format.
DNIC NTN
4 Digits up to 10 Digits
4 Bits 4 Bits
Called DTE Calling DTE National

Address Address Country PSN Terminal
Length Length Number
International Data Number
The addressing fields that make up the X.121 address are necessary only when an SVC is used,
and then only during call setup. After the call is established, the PSN uses the LCI field of the
data packet header to specify the particular virtual circuit to the remote DTE.
Layer 3 X.25 uses three virtual circuit operational procedures:
• Call setup
• Data transfer
• Call clearing
Execution of these procedures depends on the virtual circuit type being used. For a PVC, Layer
3 X.25 is always in data transfer mode because the circuit has been permanently established. If
an SVC is used, all three procedures are used.
Data transfer is affected by data packets. Layer 3 X.25 segments and reassembles user messages
if they are too long for the circuit’s maximum packet size. Each data packet is given a sequence
number so error and flow control can occur across the DTE/DCE interface.
At the end of each DLCI byte is an extended address (EA) bit. If this bit is 1, the current byte
is the last DLCI byte. All implementations currently use a 2-byte DLCI, but the presence of the
EA bits means that longer DLCIs may be agreed upon and used in the future.
Three bits in the 2-byte DLCI are fields related to congestion control. The forward explicit
congestion notification (FECN) bit is set by the Frame Relay network in a frame to tell the DTE
receiving that frame that congestion was experienced in the path from source to destination. The
backward explicit congestion notification (BECN) bit is set by the Frame Relay network in
frames traveling in the opposite direction from frames encountering a congested path. The
notion behind both of these bits is that the FECN or BECN indication can be promoted to a
higher-level protocol that can take flow control action as appropriate. (FECN bits are useful to
higher-layer protocols that use receiver-controlled flow control, and BECN bits are significant
to those that depend on “emitter controlled” flow control.)
The discard eligibility (DE) bit is set by the DTE to tell the Frame Relay network that a frame
has lower importance than other frames and should be discarded before other frames if the
network becomes short of resources. Thus, it represents a very simple priority mechanism.
This bit is usually set only when the network is congested.
The previous section described the basic Frame Relay protocol format for carrying user data
frames. The consortium’s Frame Relay specification also includes the LMI procedures. LMI
messages are sent in frames distinguished by an LMI-specific DLCI (defined in the consortium
specification as DLCI = 1023). Figure 2-41 shows the LMI message format.
Figure 2-41 LMI messages are used for signaling between Frame Relay switches and end devices.
1 2 1 1 1 1 Variable 2 1
Unnumbered Protocol Call Message Information

Flag LMI DLCI Information Discriminator Reference Type FCS Flag
Elements
Indicator
In LMI messages, the basic protocol header is the same as in normal data frames. The actual
LMI message begins with four mandatory bytes, followed by a variable number of information
elements (IEs). The format and encoding of LMI messages is based on the ANSI T1S1 standard.
The first of the mandatory bytes (unnumbered information indicator) has the same format as the
LAPB unnumbered information (UI) frame indicator with the poll/final bit set to zero. The next
byte is referred to as the protocol discriminator, which is set to a value that indicates LMI. The
third mandatory byte (call reference) is always filled with zeros.
The final mandatory byte is the message type field. Two message types have been defined:
• Status-inquiry messages allow the user device to inquire about network status. Status
messages respond to status-inquiry messages.
• Keepalives (messages sent through a connection to ensure that both sides will continue to
regard the connection as active) and PVC status messages are examples of these messages
and are the common LMI features that are expected to be a part of every implementation
that conforms to the consortium specification.
Together, status and status-inquiry messages help verify the integrity of logical and physical
links. This information is critical in a routing environment because routing algorithms make
decisions based on link integrity.
Following the message type field is some number of IEs. Each IE consists of a single-byte IE
identifier, an IE length field, and one or more bytes containing actual data.
Frame Relay Global Addressing

In addition to the common LMI features, several optional LMI extensions are useful in an
internetworking environment. The first important optional LMI extension is global addressing.
As noted earlier, the basic (nonextended) Frame Relay specification supports only values of the
DLCI field that identify PVCs with local significance. In this case, there are no addresses that
identify network interfaces or nodes attached to these interfaces. Because these addresses do
not exist, they cannot be discovered by traditional address resolution and discovery techniques.
This means that with normal Frame Relay addressing, static maps must be created to tell routers
which DLCIs to use to find a remote device and its associated internetwork address.
The global addressing extension permits node identifiers. With this extension, the values
inserted in the DLCI field of a frame are globally significant addresses of individual end-user
devices (for example, routers). This is implemented as shown in Figure 2-42.
Figure 2-42 Globally significant DLCIs must be unique across the network.
San Jose Pittsburgh
DLCI = 12 DLCI = 13
Switch
WAN
DLCI = 14 DLCI = 15
Los Angeles Atlanta
In Figure 2-42, note that each interface has its own identifier. Suppose Pittsburgh must send a
frame to San Jose. San Jose’s identifier is 12, so Pittsburgh places the value 12 in the DLCI field
and sends the frame into the Frame Relay network. At the exit point, the DLCI field contents
are changed by the network to 13 to reflect the frame’s source node. As each router’s interface
has a distinct value as its node identifier, individual devices can be distinguished. This permits
adaptive routing in complex environments.
Global addressing provides significant benefits in a large, complex internetwork. The Frame
Relay network now appears to the routers on its periphery like a typical LAN. No changes to
higher-layer protocols are needed to take full advantage of higher-layer protocol capabilities.
Frame Relay Multicasting

Multicasting is another valuable optional LMI feature. Multicast groups are designated by a
series of four reserved DLCI values (1019 to 1022). Frames sent by a device using one of these
reserved DLCIs are replicated by the network and sent to all exit points in the designated set.
The multicasting extension also defines LMI messages that notify user devices of the addition,
deletion, and presence of multicast groups.
In networks that take advantage of dynamic routing, routing information must be exchanged
among many routers. Routing messages can be sent efficiently by using frames with a multicast
DLCI. This allows messages to be sent to specific groups of routers.
Frame Relay can be used as an interface to either a publicly available carrier-provided
service or to a network of privately owned equipment. A typical means of private network
implementation is to equip traditional T1 multiplexers with Frame Relay interfaces for data
devices, as well as non-Frame Relay interfaces for other applications such as voice and
videoteleconferencing. Figure 2-43 shows this configuration.
A public Frame Relay service is deployed by putting Frame Relay switching equipment in the
central offices of a telecommunications carrier. In this case, users can gain economic benefits
from traffic-sensitive charging rates and are relieved from the work necessary to administer and
maintain the network equipment and service.
In either type of network, the lines that connect user devices to the network equipment can
operate at a speed selected from a broad range of data rates. Speeds between 56 kbps and 2
Mbps are typical, although Frame Relay can support lower and higher speeds.
ISDN
ISDN refers to a set of communication protocols implemented by telephone companies to
permit telephone networks to carry digitized voice, data, text, graphics, music, and video to end
users over existing telephone systems. ISDN services are offered by many carriers under tariff.
ISDN is generally viewed as an alternative to Frame Relay and T1 wide-area telephone services
(WATS). In practical terms, ISDN has evolved into one of the leading technologies for
facilitating telecommuting arrangements and internetworking small, remote offices into
corporate campuses.
ISDN is addressed by a suite of ITU-T standards, spanning the physical, data link, and network
layers of the seven-layer OSI reference model.
Figure 2-43 Hybrid Frame Relay networks combine data, voice, and video services.
Token
Ring
Router
Frame Relay
Interface
Ethernet
WAN
T1 MUX
Non-Frame Relay
Interface
T1 MUX
Non-Frame Relay PBX

Frame Relay
Interface
Interface
Token
Ring Router
Video/Teleconference
Ethernet
The ISDN BRI service provides two bearer channels and one data channel. The BRI B-channel
service operates at 64 kbps and carries data, and the BRI D-channel service operates at 16 kbps
and usually carries control and signaling information. The total bit rate is 144 kbps.
The ISDN Primary Rate Interface (PRI) service delivers 23 B channels and one 64-kbps D
channel in North America and Japan for a total bit rate of up to 1.544 Mbps. In Europe,
Australia, and other parts of the world, ISDN provides 30 B channels and one 64-kbps D
channel, for a total bit rate of up to 2.048 Mbps.
There are three principal categories of ISDN network components:

• ISDN terminal equipment
• ISDN termination devices
• ISDN reference points
ISDN Terminal Equipment

ISDN specifies two basic terminal equipment types:
• Terminal Equipment Type 1 (TE1)—A TE1 is a specialized ISDN terminal, including
computer equipment or telephones. It is used to connect to ISDN through a four-wire,
twisted-pair digital link.
• Terminal Equipment Type 2 (TE2)—A TE2 is a non-ISDN terminal such as DTE that
predates the ISDN standards. A TE2 connects to ISDN through a terminal adapter (TA).
An ISDN TA can be either a standalone device or a board inside the TE2.
ISDN Network Termination Devices

ISDN specifies a type of intermediate equipment called a network termination (NT) device.
NTs connect the four-wire subscriber wiring to two-wire local loops. There are three supported
NT types:
• NT Type 1 (NT1) device—An NT1 device is treated as customer premises equipment
(CPE) in North America, but is provided by carriers elsewhere.
• NT Type 2 (NT2) device—An NT2 device is typically found in digital private branch
exchanges (PBXs). An NT2 performs Layer 2 and 3 protocol functions and concentration
services.
• NT Type 1/2 (NT1/2) device—An NT1/2 device provides combined functions of separate
NT1 and NT2 devices. An NT1/2 is compatible with NT1 and NT2 devices and is used to
replace separate NT1 and NT2 devices.
ISDN Reference Points

ISDN reference points define logical interfaces. Four reference points are defined in ISDN:
• R reference point—Defines the reference point between non-ISDN equipment and a TA.
• S reference point—Defines the reference point between user terminals and an NT2.
• T reference point—Defines the reference point between NT1 and NT2 devices.
• U reference point—Defines the reference point between NT1 devices and line-termination
equipment in a carrier network. (This is only in North America, where the NT1 function
is not provided by the carrier network.)
The data link layer of the ISDN signaling protocol is Link Access Procedure on the D channel
(LAPD). LAPD is similar to the HDLC and LAPB specifications. LAPD is used to ensure that
control and signaling information flows and is received properly. The LAPD frame format uses
supervisory, information, and unnumbered frames. Figure 2-44 illustrates the fields associated
with the ISDN data link-layer frame.
Figure 2-44 ISDN uses LAPD for data link-layer signaling.
1 2 1 Variable 1 1
Flag Address Control Data FCS Flag
SAPI C/R EA TEI EA
The LAPD flag, control, and FCS fields are identical to those of HDLC. The LAPD address
field can be either 1 or 2 bytes long. If the EA bit of the first byte is set, the address is 1 byte;
if it is not set, the address is 2 bytes. The first address field byte contains the service access point
identifier (SAPI), which is a 6-bit field that identifies the point at which LAPD services are
provided to Layer 3. The C/R bit indicates whether the frame contains a command or a
response. The terminal endpoint identifier (TEI) field identifies either a single terminal or
multiple terminals. A TEI of all ones indicates a broadcast.
For more information on ISDN, refer to Appendix C, “References and Recommended
Reading.”
Figure 2-45 The TCP/IP stack combines the upper three layers of the OSI reference model into one application layer.
OSI Reference Model The Internet Protocol Suite
7 Application NFS
FTP, Telnet,
6 Presentation SMTP, SNMP XDR
5 Session RPC
4 Transport TCP, UDP
Routing Protocols ICMP

3 Network IP
ARP, RARP
2 Data Link
Not Specified
1 Physical
Figure 2-46 The IP packet header includes the source and destination addresses required for routing IP packets.
32 Bits
Version IHL Type of Service Total Length
Fragment
Identification Flags
Offset
Time to Live Protocol Header Checksum
Source Address
Destination Address
Options (+Padding)
Data (Variable)
Table 2-2 IP protocol field values.

Decimal Keyword Description
1 ICMP Internet Control Message Protocol
2 IGMP Internet Group Management Protocol
6 TCP Transmission Control Protocol
8 EGP Exterior Gateway Protocol
9 IGRP Interior Gateway Routing Protocol
16 CHAOS Chaos
17 UDP User Datagram Protocol
22 XNS-IDP XNS Internetwork Datagram Protocol
29 ISO-TP4 ISO Transport Protocol Class 4
80 ISO-IP ISO Internet Protocol
83 VINES Virtual Integrated Network Service
The 16-bit header checksum field helps ensure IP header integrity.

The 32-bit source and destination address fields specify the IP address of sending and receiving
hosts.
The variable-length options field allows IP to support options such as security and record route.
The options field must end on a 32-bit boundary. Padding can be added to ensure this.
The data field contains upper-layer information.
TCP/IP Addressing
As with all network-layer protocols, IP’s addressing scheme is integral to the process of routing
IP datagrams through an internetwork. An IP address is 32 bits in length, divided into either
two or three parts. The first part designates the network address, the second part (if present)
designates the subnet address, and the final part designates the host address. Subnet addresses
are only present if the network administrator has decided that the network should be divided
into subnetworks. The lengths of the network, subnet, and host fields are all variable.
IP addressing supports five different network classes (the leftmost bits indicate the network
class):
• Class A networks are intended mainly for use with a few very large networks, because they
provide only 8 bits for the network address field.
• Class B networks allocate 16 bits for the network address field and 16 bits for the host
address field. This address class offers a good compromise between network and host
address space.
• Class C networks allocate 24 bits for the network address field. Class C networks provide
only 8 bits for the host field, however, so the number of hosts per network may be a
limiting factor.
• Class D addresses are reserved for multicast groups, as described formally in RFC 1112.
In Class D addresses, the 4 highest-order bits are set to 1, 1, 1, and 0.
• Class E addresses are also defined by IP but are reserved for future use. In Class E
addresses, the 4 highest-order bits are all set to 1.
IP addresses are written in dotted-decimal format—for example, 34.10.2.1. Figure 2-47 shows
the address formats for Class A, B, and C IP networks.
Figure 2-47 The leftmost bits of an IP address determine its class.
1 Byte 1 Byte 1 Byte 1 Byte
Class A 0
Network Host
Class B 1 0
Network Host
Class C 1 1 0
Network Host
IP networks can also be divided into smaller units, called subnets. Subnets provide extra
flexibility for network administrators. For example, assume that a network has been assigned a
Class B address and all the nodes on the network currently conform to a Class B address format.
Then, assume that the dotted-decimal representation of this network’s address is 128.10.0.0
(all zeros in the host field of an address specifies the entire network). Rather than change all the
addresses to some other basic network number, the administrator can subdivide the network by
using subnetting. This is done by borrowing bits from the host portion of the address and using
them as a subnet field, as shown in Figure 2-48.
The 16-bit operation field indicates the operation code for this message:
Value Description
1 ARP request
2 ARP reply
3 RARP request
4 RARP reply
The sender HA and target HA are the 48-bit (for Ethernet) hardware addresses, and the sender
PA and target PA are the 32-bit (for IP) protocol addresses.
TCP/IP Internet Routing

Routing devices in the Internet have traditionally been called gateways—an unfortunate term
because, elsewhere in the industry, the term applies to a device with somewhat different
functionality. Gateways (which we call routers from this point on) within the Internet are
organized hierarchically. Some routers are used to move information through one particular
group of networks under the same administrative authority and control. A group of networks
and routers under the same administrative control is called an autonomous system (AS). Routers
used for information exchange within autonomous systems are called interior routers, and they
use a variety of IGPs to accomplish this purpose. Routers that move information between
autonomous systems are called exterior routers, and they use an EGP for this purpose. Figure
2-51 shows the location of interior and exterior gateways.
Figure 2-51 Exterior gateways are for routing between autonomous systems.
Autonomous System Autonomous System
I I
E E
CT620251.eps
E = Exterior Gateway
I = Interior Gateway
Up to 25 occurrences of the address family identifier through metric fields are permitted to
occur in any single IP RIP packet. In other words, up to 25 destinations can be listed in any
single RIP packet. Multiple RIP packets are used to convey information from larger routing
tables.
Like other routing protocols, RIP uses certain timers to regulate its performance. The RIP
routing update timer is generally set to 30 seconds, ensuring that each router will send a
complete copy of its routing table to all neighbors every 30 seconds. The route invalid timer
determines how much time must expire without a router having heard about a particular route
before that route is considered invalid. When a route is marked invalid, neighbors are notified
of this fact. This notification must occur prior to expiration of the route flush timer, which
indicates when the route is removed from the routing table. Typical initial values for these
timers are 90 seconds for the route invalid timer and 270 seconds for the route flush timer.
RIP implementations can use several features to make operation more stable in the face of rapid
network topology changes. These include a hop-count limit, holddowns, triggered updates, split
horizon, and poison reverse updates.
RIP Hop-Count Limit RIP permits a maximum hop count of 15. Any destination greater
than 15 hops away is tagged as unreachable. RIP’s maximum hop count greatly restricts its use
in large internetworks but prevents a problem called count to infinity from causing endless
network routing loops.
In Figure 2-57, consider what will happen if the link from Router 1 to Network A fails. Router
1 will remove the entry for Network A from its routing table, but in the meantime, Router 2 will
advertise that it has a link to Network A. This will cause Router 1 to begin routing all traffic for
Network A through Router 2. This creates a routing loop, because Router 2 has in its table that
the next hop to Network A is Router 1, and Router 1 has in its table that the next hop to Network
A is Router 2. A frame destined for Network A would continue to loop indefinitely except that
the IP time-to-live field will finally decrement to 0, causing the frame to be stopped.
Figure 2-57 Even small networks can experience routing loops.
Network A
Router 1 Router 2
The looping frame is not the only problem. The other problem is that when Router 2 advertises
a one-hop link to Network A, Router 1 changes its own routing table to show that it has a two-
hop path to Network A. Router 1 advertises this path in its next update. This will cause Router
2 to advertise a three-hop path, and so on. This problem will continue indefinitely unless some
external boundary condition is imposed. That boundary condition is RIP’s hop-count
maximum. When the hop count exceeds 15, the route is marked unreachable. Over time, the
route is removed from the table.
RIP Holddowns and Triggered Updates Holddowns can be used to prevent regular
update messages from inappropriately reinstating a route that has gone bad. Holddowns tell
routers to hold down any changes that might affect recently removed routes for some period of
time. The hold-down period is usually calculated to be just greater than the period of time
necessary to update the entire network with a routing change. Holddowns prevent the count-to-
infinity problem.
When a route goes down, neighboring routers detect this. Triggered updates allow routers to
inform their neighbors of the route change immediately, without waiting for a regular update
period. Triggered updates cause a wave of routing updates that travel through the network.
Triggered updates do not instantly arrive at every network device. It is therefore possible that a
device that has yet to be informed of a network failure may send a regular update message
(indicating that a route that has just gone down is still good) to a device that has just been
notified of the network failure. In this case, the latter device now contains (and potentially
advertises) incorrect routing information. Holddowns prevent this.
RIP Split Horizon The split-horizon rule derives from the fact that it is usually not useful
to send information about a route back in the direction from which it came. For example,
consider Figure 2-58.
Figure 2-58 Split horizon prevents Router 2 from advertising Network A back to Router 1.
I can get to A
Split horizon
dictates that
router 2 cannot
advertise the
Router 1 Router 2 route to network A.
I can
Network A Network B get to
A also
Router 1 initially advertises that it has a route to Network A. There is no reason for Router 2
to include this route in its update back to Router 1, because Router 1 is closer to Network A.
The split-horizon rule says that Router 2 should strike this route from any updates it sends to
Router 1.
• Partial, bounded updates—Enhanced IGRP does not make periodic updates. Instead, it
sends partial updates only when the metric for a route changes. Propagation of partial
updates is automatically bounded so that only those routers that need the information are
updated. As a result of these two capabilities, Enhanced IGRP consumes significantly less
bandwidth than IGRP.
• Multiple network-layer support—Enhanced IGRP includes support for AppleTalk, IP, and
Novell NetWare. The AppleTalk implementation uses RTMP to redistribute routes. The IP
implementation can use OSPF, RIP, Intermediate System-to-Intermediate System (IS-IS),
EGP, or BGP to redistribute routes. The Novell implementation can use Novell RIP and
Service Advertising Protocol (SAP) to redistribute routes.
Enhanced IGRP provides compatibility and seamless interoperation with IGRP routers. An
automatic redistribution mechanism allows IGRP routes to be imported into Enhanced IGRP
and Enhanced IGRP routes to be imported into IGRP, so it is possible to add Enhanced IGRP
gradually into an existing IGRP network. Because the metrics for both protocols are directly
translatable, they are as easily comparable as if they were routes that originated in their own
ASs. In addition, Enhanced IGRP treats IGRP routes as external routes and provides a way
for the network administrator to customize them.
Enhanced IGRP consists of the following components:
• Neighbor discovery/recovery
• Reliable Transport Protocol (RTP)
• DUAL finite state machine
• Protocol-dependent modules
Neighbor discovery/recovery is the process that routers use to dynamically learn about other
routers on their directly attached networks. Routers must also discover when their neighbors
become unreachable or inoperative. This process is achieved with low overhead by periodically
sending small hello packets. As long as a router receives hello packets from a neighboring
router, it assumes that the neighbor is functioning and that they can exchange routing
information.
RTP is responsible for guaranteed, ordered delivery of Enhanced IGRP packets to all neighbors.
It supports intermixed transmission of multicast or unicast packets. For efficiency, only
certain Enhanced IGRP packets are transmitted reliably. For example, on a multiaccess
network that has multicast capabilities, such as Ethernet, it is not necessary to send hello
packets reliably to all neighbors individually. For that reason, Enhanced IGRP sends a single
multicast hello packet containing an indicator that informs the receivers that the packet need
not be acknowledged. Other types of packets, such as updates, indicate in the packet that
acknowledgment is required. RTP has a provision for sending multicast packets quickly when
unacknowledged packets are pending, which helps ensure that convergence time remains low
in the presence of varying speed links.
The DUAL finite state machine embodies the decision process for all route computations. It
tracks all routes advertised by all neighbors. DUAL uses distance information to select efficient,
loop-free paths and selects routes for insertion in a routing table based on feasible successors.
A feasible successor is a neighboring router used for packet forwarding that is a least-cost path
to a destination guaranteed not to be part of a routing loop. When a neighbor changes a metric
or when a topology change occurs, DUAL tests for feasible successors. If one is found, DUAL
uses it to avoid recomputing the route unnecessarily. When there are no feasible successors but
there are neighbors advertising the destination, a recomputation (also known as a diffusing
computation) must occur to determine a new successor. Although recomputation is not
processor intensive, it affects convergence time, so it is advantageous to avoid unnecessary
recomputations.
The protocol-dependent modules are responsible for network-layer, protocol-specific
requirements. For example, the IP Enhanced IGRP module is responsible for sending and
receiving Enhanced IGRP packets that are encapsulated in IP. IP Enhanced IGRP is also
responsible for parsing Enhanced IGRP packets and informing DUAL of the new information
that has been received. IP Enhanced IGRP asks DUAL to make routing decisions, the results of
which are stored in the IP routing table. IP Enhanced IGRP is responsible for redistributing
routes learned by other IP routing protocols.
Enhanced IGRP Packet Types Enhanced IGRP uses five packet types:
• Hello/acknowledgment
• Update
• Query
• Reply
• Request
Hello packets are multicast for neighbor discovery/recovery and do not require acknowledg-
ment. An acknowledgment packet is a hello packet that has no data. Acknowledgment packets
contain a nonzero acknowledgment number, and they are always sent using a unicast address.
Update packets are used to convey reachability of destinations. When a new neighbor is
discovered, unicast update packets are sent so the neighbor can build up its topology table. In
other cases, such as a link cost change, updates are multicast. Updates are always transmitted
reliably.
Query and reply packets are sent when a destination has no feasible successors. Query packets
are always multicast. Reply packets are sent in response to query packets to indicate to the
originator that the originator does not need to recompute the route because there are feasible
successors. Reply packets are unicast to the originator of the query. Both query and reply
packets are transmitted reliably.
Request packets are used to get specific information from one or more neighbors. Request
packets are used in route server applications and can be multicast or unicast. Request packets
are transmitted unreliably.
The 8-bit packet type field specifies the upper-layer protocol to receive the packet’s
information. Common values for this field are 0, which specifies unknown packet; 1, which
specifies RIP; 5, which specifies SPX; and 17, which specifies NCP.
The destination network, destination node, and destination socket fields specify destination
information. The source network, source node, and source socket fields specify source
information.
The network number is a 32-bit number assigned by the network administrator, and the node
number is a 48-bit number that identifies the LAN hardware address. The socket number is a
16-bit hexadecimal number that identifies the higher-layer process. Values are as follows:
Value Description
0451 NetWare Core Protocol
0452 Service Advertising Protocol
0453 Routing Information Protocol
0455 NetBIOS
0456 Diagnostics
0457 Serialization
4000–8000 Dynamic sockets
The upper-layer data field contains information for upper-layer processes.

NetWare Encapsulation Types Encapsulation is the process of packaging upper-layer
protocol information and data into a frame. Novell supports multiple encapsulation schemes on
Ethernet/802.3 networks. A Cisco router supports multiple encapsulation schemes on a single
router interface, provided that multiple network numbers are assigned.
NetWare supports the Ethernet/IEEE 802.3 encapsulation schemes listed in Table 2-5 and
Table 2-5 NetWare Ethernet encapsulation types.
Common Term Novell Term Cisco Term Characteristics
Ethernet V. 2 ETHERNET_II arpa Includes Ethertype
IEEE 802.3 ETHERNET_802.2 sap Includes 802.3 length and
802.2 SAPs
Novell 802.3 raw ETHERNET_802.3 novell-ether Includes 802.3 length with
no 802.2 SAPs
SNAP ETHERNET_SNAP snap Includes 802.2 SAPs and
SNAP header
Figure 2-67 There are four IPX encapsulation types for Ethernet LANs.
ETHERNET_II
Ethernet IPX
ETHERNET_802.2
802.3 802.2 LLC IPX
ETHERNET_802.3 (Cisco Default for IPX)
802.3 IPX
ETHERNET_SNAP
802.3 802.2 LLC SNAP IPX
To route packets in an internetwork, IPX uses the dynamic routing protocol RIP. IPX RIP is
similar but not identical to IP RIP. Figure 2-68 shows the IPX RIP packet format.
Figure 2-68 Novell RIP uses ticks and hops as routing metrics.
Operation Type
(2 Bytes)
Network Number
(4 Bytes)
Number of Hops
(2 Bytes)
Number of Ticks
(2 Bytes)
.
.
.
Default Maximum 50 Sets
of Network Information
The operation field specifies the packet operation, with value 1 indicating RIP request and 2
indicating RIP response.
The network number is the 32-bit address of the specified network.
The hops field indicates the number of routers that must be passed through to reach the specified
network.
152 Chapter 3: Cisco Routing and Switching Processes
Figure 3-1 The router exchanges routing updates with all its neighbors.
Routing Table of Router B

Destination Network Reachable Interface
101 101 FDDI 0/0
102 FDDI 0/0
103 Ethernet 1/0
104 ATM 2/0
A 105 ATM 2/0
106 ATM 2/0
102
FDDI
Update
Update Update
B ATM C
Update 104 Token

105 Update
103 Ring
D
106
Routing is more processing intensive and has higher latency than switching because it
determines path and next-hop by looking into each packet’s Layer 3 information. This process
also requires the router to strip off the old Media Access Control (MAC) header and build a new
one before sending the packet. Switching involves only a MAC address lookup, which is
considerably faster. The first packet routed requires a lookup in the routing table to determine
the route. The route cache is populated after the first packet is routed by the route-table lookup.
Subsequent traffic for the same destination is switched using the routing information stored in
the route cache.
A router sends routing updates out each of its interfaces that are configured for a particular
protocol, as shown in Figure 3-1. It also receives routing updates from other attached routers.
From these received updates and its knowledge of attached networks, the router builds a map
of the network topology for each configured protocol. Each table is independent of the others;
the independence of the routing tables is sometimes called ships in the night routing.
Switching 155
NOTE The type of switching performed (for example, silicon, autonomous, fast, or process) is
determined by the configuration applied to the destination interface and by the revision of the
Cisco IOS software. The switching mode used depends on the Cisco IOS version, network
protocol, interface processor, configuration, and packet encapsulation. There are numerous
combinations of these. To find out which protocols and configurations result in process
switching, contact your technical support representative for specific data or refer to the
information available at Cisco Connection Online (www.cisco.com) or on the Cisco
documentation CD-ROM.
Process Switching
In process switching, the first packet is copied to the system buffer. The router looks up
the Layer 3 network address in the routing table and initializes the fast-switching cache. The
frame is rewritten with the destination address and sent to the exit interface that services that
destination. Subsequent packets for that destination are sent by the same switching path.
The route processor computes the cyclic redundancy check (CRC), which performs an error-
checking mechanism on the contents of the packet. Process switching adds overhead by
requiring CPU interrupts to process packets.
The following are some values indicating packets processed per second across Cisco router
platforms based on a 64-byte IP packet:
Platform Performance
Cisco 7500/RSP4 18000 pps
Cisco 7500/RSP2 8000 pps
Cisco 7200-150 5000 pps
Cisco 4500 and 4700 3500 and 4600 pps
Cisco 3620 and 3640 2000 and 4000 pps
Cisco 7000/7010 with SSP 2500 pps
Cisco 7000/7010 with SP 2000 pps
AGS+/CSC4 2000 pps
Cisco 4000 1800 pps
Cisco 3000/2500 900 pps
162 Chapter 3: Cisco Routing and Switching Processes
Step 9 The RP builds the encapsulation based on that of the destination interface. When this
encapsulation has been built, the configuration for the particular destination interface
is checked.
Step 10 If the interface has been configured for silicon switching for the protocol being
considered, the encapsulation information is copied to the silicon-switching cache.
If the interface has been configured for autonomous switching for the protocol being
considered, the encapsulation information is copied to the autonomous-switching
cache. If the destination interface has not been configured for either silicon or
autonomous switching, the encapsulation information is copied to the fast-switching
cache, unless for any particular reason the interface must be process switched (for
example, it might have been configured for no <protocol> route-cache or for an
uncommon protocol encapsulation).
Step 11 The RP moves the packet across the system bus to a packet buffer on the SP.
Step 12 The packet is copied across the CxBus to a hardware buffer on an interface processor
(the FDDI Interface Processor).
Step 13 The packet is transmitted to the destination interface.
This initialization sequence is followed for the first packet of a particular protocol that is
destined for a particular destination interface. The sequence is also followed for any packet that
is to be process switched out of an interface.
Switching Features That Affect Performance

Router performance is affected by the switching mechanism you are using. Some Cisco IOS
features require special handling and cannot be switched until the additional processing they
require has been performed. This special handling is not processing that the interface processors
can do. Because these features require additional processing, they affect switching
performance. These features include
• Queuing
• Random early detection
• Compression
• Filtering (using access lists)
• Encryption
• Accounting
The following sections define each of these features.
174 Chapter 4: General Troubleshooting Tools
Cable testers (that is, scanners) can also be used to check physical connectivity. Cable testers
give users access to physical-layer information and are available for shielded twisted-pair
(STP), unshielded twisted-pair (UTP), 10BaseT, and coaxial and twinax cables. These testers
can test and report cable conditions including near-end crosstalk (NEXT), attenuation, and
noise. Some of them also have TDR (Time Domain Reflectometer), traffic monitoring, and wire
map functions. In addition, some handheld network testers display Media Access Control
(MAC) layer information about LAN traffic, provide statistics such as network utilization and
packet error rates, and perform limited protocol testing (for example, TCP/IP tests such as
ping).
Similar testing equipment is available for fiber-optic cable. Due to the relatively high cost of
fiber cable and its installation, it is recommended that fiber-optic cable be tested before
installation (that is, on-the-reel testing) and after installation. Continuity testing of the fiber
requires either a visible light source or a reflectometer. Light sources capable of providing light
at the three predominant wavelengths—850 nm, 1300 nm, and 1550 nm—are used with power
meters that can measure the same wavelengths and test attenuation and return loss in the fiber.
Figure 4-1 shows one of the cable scanners available from Microtest: the OMNI Scanner. The
OMNI Scanner has the functionality to test cables complying with current and upcoming
standards with an extremely wide dynamic range of 100 dB and the ability to support up to
300 MHz bandwidth. The OMNI Scanner can test all the way up to 300 MHz on Category 7
cables.
NOTE Microtest, Inc., is located at 4747 N. 22nd St., Phoenix, AZ 85016-4708, and can be reached at
602-952-6400.
Figure 4-1 Microtest’s OMNI Scanner handheld cable scanners can test a wide range of cable.
Protocol Analyzers 179
In capture mode, filters can be set to record only traffic that meets certain criteria; for example,
if a particular unit is suspected of inconsistent protocol behavior, then a filter can be configured
that captures all traffic to and from that unit. The analyzer should have the capability to
timestamp all the captured data. This can be extremely important when determining the effects
of peak traffic periods and when analyzing network performance—for example, determining
protocol response times by measuring the delta time between frames.
In display mode, an analyzer interprets the captured traffic, presenting the protocol layers in an
easily readable form. Filters can be set to allow only those captured frames that meet certain
criteria to be displayed.
It is also important that the analyzer be able to generate frames and transmit them onto the
network in order to perform capacity planning or load testing of specific devices such as servers,
bridges, routers, and switches. The analyzer should be able to send multiple captured frames in
succession, as well as allow network managers to tailor the frames by being able to edit the
frames prior to generation.
Figure 4-5 shows a packet that is decoded by the Sniffer Pro protocol analyzer. Sniffer Pro
analyzers include the Expert System that identifies fault symptoms and provides a diagnosis of
the network problems. Sniffer Pro provides decodes for more than 250 protocols.
NOTE For more information on Sniffer Pro, see the Network Associates Web site at www.nai.com.
Figure 4-5 The Sniffer Pro can decode frame and packet information.
DLC: ----- DLC Header -----

DLC:
DLC: Frame 1 arrived at 15:05:33.389; frame size is 62 (003E hex) bytes.
DLC: AC: Frame priority 0, Reservation priority 0, Monitor count 0
DLC: FC: LLC frame, PCF attention code: None
DLC: FS: Addr recognized indicators: 00, Frame copied indicators: 00
DLC: Destination = Station cisco A05903
DLC: Source = Station IBM 0AE59
DLC:
Summary Delta T DST SRC
LLC: ----- LLC Header ----- 1 DCE DTE HDLC SABM P/F=1
LLC:
LLC: DSAP = AA, SNAP = AA, C 2 0.0412 DTE DCE HDLC UA P/F=1
LLC:
3 0.0492 DCE DTE HDLC I NR=0 NS=0 P/F=0
SNAP: ----- SNAP Header ----- 4 0.0408 DTE DCE HDLC RR NR=1 P/F=0
SNAP:
SNAP: Type = 0800 (IP) 5 0.0438 DTE DCE HDLC I NR=1 NS=0 P/F=0
SNAP: 6 0.0287 DCE DTE HDLC RR NR=1 P/F=0
7 9.8700 DCE DTE HDLC I NR=1 NS=1 P/F=0
8 0.0379 DTE DCE HDLC RR NR=2 P/F=0
9 0.3000 DTE DCE HDLC I NR=2 NS=1 P/F=0
CHAPTER
5
Cisco Management and
Diagnostic Tools
This chapter introduces Cisco’s management tools and commands. It presents the output
of router diagnostic commands from real-world environments with network problems.
You will learn to recognize statistics that point to possible issues and concerns. Cisco
management tools covered in this chapter include CiscoWorks, CiscoView, TrafficDirector,
and VlanDirector.
This chapter also presents commands and functions such as core dumps that provide
information you can give to Cisco or third-party support personnel when troubleshooting
problems.
Cisco Management Tools

Cisco has developed a number of tools to manage and model network traffic flows. Each of
the Cisco management tools has a distinct purpose. The following sections examine each
of the following tools and their capabilities:
• CiscoWorks
• Netsys Network Management Suites
• TrafficDirector Remote Monitoring Software
• The VlanDirector Switch Management Application
• WAN Manager
Let’s begin with the large family of management tools called CiscoWorks.
CiscoWorks
CiscoWorks is Cisco’s flagship network management product line. It delivers device-level
monitoring, configuration, and fault-management tools. CiscoWorks network management
software lets you monitor complex internetworks that use Cisco routing devices and helps
you plan, troubleshoot, and analyze your network. CiscoWorks uses Simple Network
Management Protocol (SNMP) to monitor and control any SNMP device on the network.
Cisco Management Tools 189
• CiscoWorks Windows—An integrated PC-based network configuration and diagnostic

tools for small to medium-sized networks or remote workgroups that use 5 to 50 Cisco
devices.
• CiscoWorks Switched Internetwork Solutions (CWSI)—Delivers a management system
specifically designed for increasing switched internetworks.
• CiscoWorks2000—A new family of Web-based and management platform-independent
products for managing Cisco enterprise networks and devices.
CiscoWorks Windows creates a multilevel, hierarchical map that provides real-time status of
individual routers, switches, hubs, and access servers by using color-coded icons.
CiscoView is the graphical device-management technology that is the standard for managing
Cisco devices, providing back- and front-panel displays. These dynamic, color-coded
graphical displays simplify device-status monitoring, device-specific component diagnostics,
and application launching. CiscoView also provides additional applets that simplify the
management of Cisco devices. It is bundled with the CiscoWorks software and is also available
as a standalone product.
The CiscoView software graphically displays a physical view of Cisco devices, giving network
managers a complete view of Cisco products without physically checking each device at remote
sites. Additionally, this network management tool provides monitoring functions and offers
basic troubleshooting.
CiscoView and the other parts of CiscoWorks are complemented by Cisco Resource Manager
(CRM), a new suite of Web-based network management applications that enhance inventory
and software distribution capabilities. The CRM suite consists of a Web server and four key
management applications: Inventory Manager, Availability Manager, Syslog Analyzer, and
Software Image Manager.
Together, these applications speed Cisco Internetwork Operating System (IOS) software
deployment and provide network managers with a number of multi-device-management
capabilities, including views of network change status, the ability to track device availability,
and the ability to monitor, categorize, and analyze syslog messages. Cisco Resource Manager
dynamically tracks Cisco and SNMP MIB II device information as well as Cisco software
versions and Cisco device configuration information, automatically identifying changes.
CWSI can be integrated with popular SNMP management platforms, including the GUI
environments of SunNet Manager, HP OpenView, and NetView.
CWSI includes comprehensive SNMP manageability, Cisco Discovery Protocol (CDP) for
adjacent discovery, Virtual Trunk Protocol (VTP) for automated VLAN setup, and RMON
for traffic analysis.
CWSI is a suite of campus LAN management applications that include VlanDirector,
TrafficDirector, and CiscoView. These applications provide services such as topology mapping,
VLAN management, device configuration management, and performance management of
collected RMON traffic data.
190 Chapter 5: Cisco Management and Diagnostic Tools
Through an autodiscovery and topology mapping function, CWSI provides a campus view of
interconnected Cisco switches and routers that administrators can use to learn connection
relationships and to display logical VLAN topologies superimposed on the underlying physical
network.
The Netsys Network Management Suites

Cisco Netsys connectivity tools are a series of simulation-based planning and problem-solving
products for network managers, analysts, and designers. The Connectivity Tools assist network
planners with problem solving, design, and planning activities focusing on network
connectivity, route, and flow analysis.
The Netsys management suites are used to proactively check network designs to display, debug,
and validate your network configuration. Netsys allows you to test configurations and changes
offline before committing them to the live network.
There are two flavors of Netsys: Cisco Netsys Baseliner 4.0 for Windows NT and the Cisco
Netsys Service-Level Management (SLM) Suite.
Cisco Netsys Baseliner 4.0 for Windows NT

Cisco Netsys Baseliner 4.0 for Windows NT creates a model of your network and checks for
more than 100 common yet difficult-to-isolate configuration problems. You can graphically
view your network as it is configured, not as it is planned or discovered. Baseliner gives you the
big picture instantly, allowing you to visually navigate your network and gain a complete
understanding of how it works. You can proactively monitor configuration changes; when
problems occur, recent configuration changes are often to blame.
Building on the map created by the Connectivity Baseliner, planners can use the Connectivity
Solver’s analysis environment to study the impact of failed devices and links, varying access
list configurations and other configuration changes before implementation in the production
network.
Netsys collects actual Cisco router configuration files from the online network and processes
the Cisco IOS commands to create an accurate offline model of the network. Netsys then
analyzes the offline model for errors and generates graphical topology views and reports. At this
point the user can submit proposed configuration changes or corrections to the offline model for
reanalysis. This is often an iterative process as the user refines the network configuration. Users
safely apply only fully tested changes to the online network.
Most network management tools provide only a topology view based on information manually
entered or via an SNMP discovery process. Although these views are acceptable for some
applications, they lack depth and miss critical elements such as routing protocols. By using the
actual router configuration files, Baseliner can display all physical and logical relationships
network loading and protocol distributions. Managers can then “zoom in” on a specific
segment, ring, switch port, or trunk link and apply real-time analysis and diagnostic tools to
view hosts, conversations, and packet captures.
Distributed Polling and Threshold Monitoring

TrafficDirector also provides the powerful Resource Monitor tool, which, when used with a
SwitchProbe device with the Resource Monitor option, provides distributed polling and SNMP
threshold monitoring for remote sites and/or divisions within large enterprise networks. These
distributed management tools let users proactively monitor the status of any remote device via
a ping or by performing an SNMP Get to check any specified MIB object’s value against a
preset threshold.
Protocol Analysis
The TrafficDirector protocol analysis tool provides rapid, centralized troubleshooting for most
protocol-related network problems. These packets can also be saved to a file in Sniffer format
for additional analysis, by using an existing protocol analyzer, thus protecting and leveraging
existing investments in network management tools. The TrafficDirector software supports full
seven-layer decodes for the AppleTalk, DECnet, IP, ISO, Novell, SNA, Sun-NFS, Banyan
VINES, and XNS protocol suites.
Proactive Management
TrafficDirector threshold monitoring enables users to implement a proactive management
environment. First, thresholds for critical MIB variables are set within the RMON agent. When
these thresholds are exceeded, traps are sent to the appropriate management station to notify the
network administrator of an impending problem.
The VlanDirector Switch Management Application

VlanDirector is a graphically based, system-level VLAN management application for
configuring, managing, and monitoring interconnected Cisco switches and routers. Integral
components of VlanDirector include
• Graphical mapping utilities for viewing and configuring logically defined workgroups
• “Drag-and-drop” port-level configuration options for assigning users to VLANs
• Automated link assignment settings for managing VLANs campuswide
• Integration with common SNMP management platforms for consolidating system
resources and detailed reporting functions for maintaining audit trails
Cisco Diagnostic Commands 201
The software portion includes the messages being passed back and forth between the adjacent
devices. These messages can be keepalive messages that let the device on the other end know
that someone is still alive on the other end of the link.
The show interfaces Command

The show interfaces command displays statistics for the network interfaces, as shown in
Figure 5-2.
Figure 5-2 The show interfaces command displays the interface counters for Layer 2 troubleshooting.
Router> show interfaces s 1
Serial1 is up, line protocol is up
Hardware is cxBus Serial

Description: 56Kb Line San Jose - MP
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last clearing of “show interface” counters 2w4d
Five minute input rate 0 bits/sec, 0 packets/sec
Five minute output rate 0 bits/sec, 0 packets/sec
Received 13983 broadcasts, 0 runts, 0 giants
0 input packets with dribble condition detected
0 output errors, 0 collisions, 2 interface resets, 0 restarts
The resulting display on the Cisco 7000 series shows the interface processors in slot order.
If you use the show interfaces command on the Cisco 7000 series without the slot/port
arguments, information for all interface types is shown. For example, if you type show
interfaces ethernet, you will receive information for all Ethernet, serial, Token Ring, ATM,
and FDDI interfaces. Only by adding the type slot/port argument can you specify a particular
interface.
If you enter a show interfaces command for an interface type that has been removed from
the router, interface statistics are displayed, accompanied by the text “Hardware has been
removed.”
If you shut an interface, the keepalives that cause the message “line protocol is up” are not
received on the interface.
You will use the show interfaces command frequently while configuring and monitoring
routers. Current information is important in network troubleshooting. If you suspect an
Figure 5-8 You can use the show controllers token command to display management and error statistics
for an interface.
Router> show controllers token
TR Unit 0 is board 0 - ring 0
state 3, dev blk: 0x1D2EBC, mailbox: 0x2100010, sca: 0x2010000
current address: 0000.3080.6f40, burned in address: 000.3080.6f40
current TX ptr: 0xBA8, current RX ptr: 0x800
Last Ring Status: none
Stats: soft:0/0, hard:0/0, sig loss:0/0
tx beacon: 0/0, wire fault 0/0, recovery: 0/0
only station: 0/0, remote removal: 0/0
Bridge: local 3330, bnum 1, target 3583
max_hops 7, target idb: 0x0, not local
Interface failures: 0 -- Bkgnd Ints: 0
TX shorts 0, TX giants 0
Monitor state: (active)
flags 0xC0, state 0x0, test 0x0, code 0x0, reason 0x0
f/w ver: 1.0, chip f/w: ’000000.ME31100’, [bridge capable]
SMT versions: 1.01 kernel, 4.02 fastmac
ring mode: F00, internal enables: SRB REM RPS CRS/NetMgr
internal functional: 0000011A (0000011A), group: 00000000 (00000000)
if_state: 1, ints: 0/0, ghosts: 0/0, bad_states: 0/0
t2m fifo purges: 0/0
t2m fifo current: 0, t2m fifo max: 0/0, proto_errs: 0/0
ring: 3330, bridge num: 1, target: 3583, max hops: 7
Packet counts:
receive total: 298/6197, small: 298/6197, large 0/0
runts: 0/0, giants: 0/0
local: 298/6197, bridged: 0/0, promis: 0/0
bad rif: 0/0, multiframe: 0/0
ring num mismatch 0/0, spanning violations 0
transmit total: 1/25, small: 1/25, large 0/0
runts: 0/0, giants 0/0, errors 0/0
bad fs: 0/0, bad ac: 0
congested: 0/0, not present: 0/0
Unexpected interrupts: 0/0, last unexp. int: 0
Internal controller counts:
line errors: 0/0, internal errors: 0/0
burst errors: 0/0, ari/fci errors: 0/0
abort errors: 0/0, lost frame: 0/0
copy errors: 0/0, rcvr congestion: 0/0
token errors: 0/0, frequency errors: 0/0
dma bus errors: -/-, dma parity errors: -/-
Internal controller smt state:
Adapter MAC: 0000.3080.6f40, Physical drop: 00000000
NAUN Address: 0000.a6e0.11a6, NAUN drop: 00000000
Last source: 0000.a6e0.11a6, Last poll: 0000.3080.6f40
Last MVID: 0006, Last attn code: 0006
Txmit priotity: 0006, Auth Class: 7FFF
Monitor Error: 0000, Interface Errors: FFFF
Correlator: 0000, Soft Error Timer: 00C8
Local Ring: 0000, Ring Status: 0000
Beacon rcv type: 0000, Beacon txmit type: 0000
Beacon type: 0000, Beacon NAUN: 000.a6e0.11a6
The show processes Command

You use the show processes command to display information about the active processes, as
Figure 5-10 The 5-minute utilization level is the most important field in the output of the show processes command.
Router# show processes
CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0%
PID Q T PC Runtime(ms) Invoked uSecs Stacks TTY Process
1 M T 40FD4 1736 58 29931 910/1000 0 Check heaps
2 H E 9B49C 68 585 116 790/900 0 IP Input
3 M E AD4E6 0 737 0 662/1000 0 TCP Timer
4 L E AEBB2 0 2 0 896/1000 0 TCP Protocols
5 M E A2F9A 0 1 0 852/1000 0 BOOTP Server
6 L E 4D2A0 16 127 125 876/1000 0 ARP Input
7 L E 50C76 0 1 0 936/1000 0 Probe Input
8 M E 63DA0 0 7 0 888/1000 0 MOP Protocols
9 M E 86802 0 2 0 1468/1500 0 Timers
10 M E 7EBCC 692 64 10812 794/1000 0 Net Background
11 L E 83BSS 0 5 0 870/1000 0 Logger
12 M T 11C454 0 38 0 574/1000 0 BGP Open
13 H E 7F0E0 0 1 0 446/500 0 Net Input
14 M T 436EA 540 3435 157 737/1000 0 TTY Background
15 M E 11BA9C 0 1 0 960/1000 0 BGP I/O
16 M E 11553A 5100 1367 3730 1250/1500 0 IGRP Router
17 M E 11B76C 88 4200 20 1394/1500 0 BGP Router
18 L T 11BA64 152 14650 10 942/1000 0 BGP Scanner
19 M * 0 192 80 2400 1714/2000 0 Exec
The first line of output shows CPU utilization for the last 5 seconds, 1 minute, and 5 minutes.
The second part of the 5-second figure (0%/0%) is the percentage of the CPU used by interrupt
routines.
NOTE Because the router has a 4-millisecond clock resolution, run times are considered reliable only
after a large number of invocations or a reasonable, measured run time.
Take snapshots of this command, about 1 minute apart, and compare the output line-by-line to
see which processes are often invoked. The one that has been invoked the most is likely to be
responsible for the CPU load.
This potential risk being acknowledged, the debug tools can be very helpful when you use them
properly. As you will see in the next several pages, proper debug handling can mitigate (or
minimize) this impact.
When you interpret the information you need from the debug command and undo the debug
(and any other related configuration setting), the router can resume its faster switching. You can
resume your problem solving, create a better-targeted action plan, and be better able to take the
action that fixes the network problem.
For troubleshooting, Cisco engineers recommend that you use the Cisco IOS service
timestamps [type][time-format] command. This command puts a timestamp on a debug or log
message that can provide valuable information about when debug elements occurred and the
duration of time between events.
The timestamp type specifies the type of message (either debug or log). By default, the
command shows date and time format. Alternatively, you can specify the time-format argument
to show time in uptime since system boot (uptime keyword), milliseconds added to date and
time (msec keyword), and local time zone (localtime keyword).
Do not use the command debug all because it may generate so much output that it can severely
diminish the router’s performance, or even render the router unusable. Instead, add one or more
arguments to the command to narrow the focus of this powerful tool.
You can use the terminal monitor privileged EXEC command to copy debug command output
and system error messages to your current terminal display—as well as to the console terminal.
terminal monitor permits you to establish a Telnet connection to the router and view debug
command output remotely, without being connected through the console port.
Output formats vary with each debug command:
• Some generate a single line of output per packet; others generate multiple lines of output
per packet.
• Some generate large amounts of output; others generate only occasional output.
• Some generate lines of text; others generate information in field format.
You will see more about the output of specific debug commands for various Layer 2 and 3
protocols in the chapters that follow.
To list and briefly describe all the debugging command options, enter the command debug ? in
privileged EXEC mode on the command line.
Before invoking any debug commands, use the cpu optional keyword when invoking the show
processes command. This command displays the CPU utilization for each process. If the values
of CPU utilization are 50% or greater, consider debugging events, rather than debugging
packets.
Figure 5-16 IP ping uses ICMP echo messages to test connectivity and round-trip time.
Router> ping fred

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.31.7.27, timeout is 2 seconds:
!!!!!
Success rate is 100 percent, round-trip min/avg/max = 1/3/4 ms
Router> ping 192.45.3.1
.U.U.
Success rate is 0 percent (0/5)
For IP, the ping command sends ICMP echo messages. If a station receives an ICMP echo
message, it sends an ICMP echo reply message to the source of the ICMP echo message.
The user ping feature provides a basic ping facility for IP users who do not have system
privileges. This feature allows the router to perform the simple default ping functionality for
the IP protocol. Only the nonverbose form of the ping command is supported for user pings.
Figure 5-16 shows real output that was seen when the ping command was used to check the
reachability to host fred and host 192.45.3.1.
The simple ping sends 5 100-byte packets with a 2-second timeout:
Output Description
!!!!! Each exclamation point (!) indicates receipt of a reply. A period
(.) indicates that the router timed out while waiting for a reply.
Other characters may appear in the ping output display,
depending on the protocol type.
Success rate is100 percent Percentage of packets successfully echoed back to the router.
Anything less than 80% is usually considered problematic.
round-trip min/avg/max = 1/3/4 ms Round-trip travel time intervals for the protocol echo packets,
including minimum/average/maximum (in milliseconds).
In Figure 5-16 the first set of pings had a success rate of 100%. The second set of pings had a
success rate of 0%. The destination 192.45.3.1 is unreachable (U). The router timed out waiting
for the result of the first ping and displayed a period. On the second ping, the router received
an ICMP destination unreachable message.
The first ping often times out. If a receiving station or router needs to send an ARP frame before
replying, then too much time elapses, and the sending router times out.
Some routers, including Cisco routers, implement an ICMP throttle, which specifies that the
router should not send too many ICMP messages in a time period. This might explain the
timeout for the third and fifth pings in Figure 5-16.
If the system cannot map an address for a host name, it returns an “%Unrecognized host or
address” error message.
To terminate a ping session, type the escape sequence Ctrl-Shift-6 (this is done by
simultaneously pressing the Ctrl, Shift, and 6 keys), or Ctrl-C.
The test characters that are displayed in IP ping responses are as follows:
Character Description
! Each exclamation point indicates receipt of a reply.
. Each period indicates that the router timed out while waiting for a reply.
U Destination unreachable.
N Network unreachable.
P Protocol unreachable.
Q Source quench.
M Could not fragment.
? Unknown packet type.
Another useful command when using ping for IP is debug ip icmp. After you set up the debug
command, have the other side ping your local target and then observe the debug output.
A useful sequence of ping commands can help isolate possible reachability problem locations.
As you receive the characters that return from the ping, ask the question “What part of the
network is sending this message?”
The AppleTalk and IPX User ping Command

The ping appletalk command sends Apple Echo Protocol (AEP) datagrams to other AppleTalk
nodes to verify connectivity and measure round-trip times, as shown in Figure 5-17.
Figure 5-17 Cisco supports AppleTalk and IPX ping processes.

Router> ping appletalk 1024.128
Sending 5, 100-byte AppleTalk Echoes to 1024.128, timeout is 2 seconds:
!!!!!
Success rate is 100 percent, round-trip min/avg/max = 4/4/8 ms
Router> ping ipx 211.0000.0c01.f4cf

Sending 5, 100-byte Novell Echoes to 211.0000.0c01.f4cf, timeout is 2 seconds:
•••••
TCP/IP Router Diagnostic Tools 283
The show ip arp Command

The show ip arp command displays the entries in the ARP cache for the router. Sometimes you
can solve intermittent problems by clearing the ARP cache (using clear arp-cache). Figure
7-6 shows sample output from the show ip arp command.
Figure 7-6 The ARP table maps IP addresses to MAC addresses.

Router# show ip arp
Protocol Address Age(min) Hardware Addr Type Interface

Internet 171.69.233.22 9 0000.0c59.f892 ARPA Ethernet0/0
Internet 171.69.233.21 8 0000.0c07.ac00 ARPA Ethernet0/0
Internet 171.69.233.19 - 0000.0c63.1300 ARPA Ethernet0/0
Internet 171.69.233.30 9 0000.0c36.6965 ARPA Ethernet0/0
Internet 172.19.168.11 - 0000.0c63.1300 ARPA Ethernet0/0
Internet 172.19.168.25 9 0000.0c36.6965 ARPA Ethernet0/0
The following are the significant fields shown in Figure 7-6:
Field Description
Protocol Protocol for network address in the Address field.
Address The network address that corresponds to
Hardware Address.
Age (min) Age, in minutes, of the cache entry. A hyphen (-)
means the address is local.
Hardware Addr LAN hardware address that corresponds to a
network address.
Type Type of encapsulation:
• ARPA—Ethernet
• SNAP—RFC 1042
• SAP—IEEE 802.3
Interface Interface to which this address mapping has been
assigned.
The show ip interface Command

The show ip interface command displays the usability status of interfaces. Among other things,
this can help you make sure the router interface or subinterface is up and configured with the
correct address and subnet mask, to check for routes that may have been learned from the wrong
interface or protocol (for example, due to disabled split horizon on a LAN). Figure 7-7 shows
sample output from the show ip interface command.
284 Chapter 7: Troubleshooting TCP/IP Connectivity
Figure 7-7 The show ip interface command gives detailed information on each interface’s IP configuration.
Router# show ip interface

Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Secondary address 131.192.115.2, subnet mask 255.255.255.0
Directed broadcast forwarding is enabled
Multicast groups joined: 224.0.0.1 224.0.0.2
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP SSE switching is disabled
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
Probe proxy name replies are disabled
The following are the fields shown in Figure 7-7:
Field Description
Ethernet0 is up If the interface hardware is usable, the interface is
marked up. For an interface to be usable, both the
interface hardware and line protocol must be up.
line protocol is up If the interface can provide two-way
communication, the line protocol is marked up.
For an interface to be usable, both the interface
hardware and line protocol must be up.
Internet address and subnet mask IP Internet address and subnet mask of the
interface.
Broadcast address Shows the broadcast address.
Address determined by … Indicates how the IP address of the interface was
determined.
MTU Shows the MTU value set on the interface.
Helper address Shows a helper address, if one has been set.
The show ip ospf database Command

The show ip ospf database command displays detailed Open Shortest Path First (OSPF)
information depending on the optional keywords. For example, the router keyword displays
information about router link states. The network keyword displays information about network
link states. The asbr-summary keyword displays information about autonomous system
boundary router link states. The following are some of the most useful keyword variations:
show ip ospf [process-id area-id] database [asbr-summary] [link-state-id]
show ip ospf [process-id area-id] database [database-summary]
show ip ospf [process-id] database [external] [link-state-id]
show ip ospf [process-id area-id] database [network][link-state-id]
show ip ospf [process-id area-id] database [router] [link-state-id]
show ip ospf [process-id area-id] database [summary] [link-state-id]
Figure 7-8 shows sample output from the show ip ospf database command.
Figure 7-8 The show ip ospf database command is useful for verifying that link state updates are being received.
Router# show ip ospf database
OSPF Router with id(190.20.239.66) (Process ID 300)

Displaying Router Link States(Area 0.0.0.0)
Link ID ADV Router Age Seq# Checksum Link count
155.187.21.6 155.187.21.6 1731 0x80002CFB 0x69BC 8
155.187.21.5 155.187.21.5 1112 0x800009D2 0xA2B8 5
155.187.1.2 155.187.1.2 1662 0x80000A98 0x4CB6 9
155.187.1.1 155.187.1.1 1115 0x800009B6 0x5F2C 1
155.187.1.5 155.187.1.5 1691 0x80002BC 0x2A1A 5
155.187.65.6 155.187.65.6 1395 0x80001947 0xEEE1 4
155.187.241.5 155.187.241.5 1161 0x8000007C 0x7C70 1
155.187.27.6 155.187.27.6 1723 0x80000548 0x8641 4
155.187.70.6 155.187.70.6 1485 0x80000B97 0xEB84 6
Displaying Net Link States(Area 0.0.0.0)
Link ID ADV Router Age Seq# Checksum
155.187.1.3 192.20.239.66 1245 0x800000EC 0x82E
Displaying Summary Net Link States(Area 0.0.0.0)
155.187.240.0 155.187.241.5 1152 0x80000077 0x7A05
155.187.241.0 155.187.241.5 1152 0x80000070 0xAEB7
155.187.244.0 155.187.241.5 1152 0x80000071 0x95CB
Field Description
Ethernet0 is up If the interface hardware is usable, the interface is
marked up. For an interface to be usable, both the
interface hardware and line protocol must be up.
line protocol is up If the interface can provide two-way
communication, the line protocol is marked up.
For an interface to be usable, both the interface
hardware and line protocol must be up.
Field Description
IP output packet accounting Specifies whether IP accounting is enabled for
this interface and specifies the threshold
(maximum number of entries).
TCP/IP header compression Indicates whether compression is enabled or
disabled.
Probe proxy name Indicates whether HP probe proxy name replies
are generated.
The show ip ospf interface Command

The show ip ospf interface command displays summary OSPF interface information. Figure
7-9 shows sample output from the show ip ospf interface command.
Figure 7-9 Neighbor information should match on directly connected routers.
Router# show ip ospf interface ethernet 0
Ethernet 0 is up, line protocol is up

Internet Address 131.119.254.202, Mask 255.255.255.0, Area 0.0.0.0
AS 201, Router ID 192.77.99.1, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State OTHER, Priority 1
Designated Router id 131.119.254.10, Interface address 131.119.254.10
Backup Designated router id 131.119.254.28, Interface addr 131.119.254.28
Timer intervals configured, Hello 10, Dead 60, Wait 40, Retransmit 5
Hello due in 0:00:05
Neighbor Count is 8, Adjacent neighbor count is 2
Adjacent with neighbor 131.119.254.28 (Backup Designated Router)
Adjacent with neighbor 131.119.254.10 (Designated Router)
Field Description
Ethernet Status of physical link and operational status of
protocol.
Internet Address Interface IP address, subnet mask, and area
address.
AS Autonomous system number (OSPF process ID),
router ID, network type, and link state cost.
Transmit Delay Transmit delay, interface state, and router
priority.
Designated Router Designated router ID and respective interface IP
address.
Field Description
Backup Designated router Backup designated router ID and respective
interface IP address.
Timer intervals configured Configuration of timer intervals.
Hello Number of seconds until next hello packet is sent
out this interface.
Neighbor Count Count of network neighbors and list of adjacent
neighbors.
The show ip protocols Command

The show ip protocols command displays the parameters and current state of the active routing
protocol process. This command can help you debug problems with many IP protocols
(including Interior Gateway Routing Protocol [IGRP] and Enhanced IGRP), check on update
and administrative distance issues, determine whether access lists or routing redistribution is in
effect, and identify which routing information sources were used by the router. Figure 7-10
shows sample output from the show ip protocols command.
Figure 7-10 The show ip protocols command is useful for verifying routing protocol configuration.
Router# show ip protocols
Routing Protocol is “igrp 109”

Sending updates every 90 seconds, next due in 44 seconds
Invalid after 270 seconds, hold down 280, flushed after 630
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
IGRP maximum hopcount 100
IGRP maximum metric variance 1
Redistributing: igrp 109
Routing for Networks:
198.92.72.0
Routing Information Sources:
Gateway Distance Last Update
198.92.72.18 100 0:56:41
198.92.72.19 100 6d19
198.92.72.22 100 0:55:41
198.92.72.20 100 0:01:04
198.92.72.30 100 0:01:29
Distance: (default is 100)
continues
Field Description
Routing Specifies the networks for which the routing process is currently
injecting routes.
Routing Information Sources Lists all the routing sources the Cisco IOS software is using to
build its routing table. For each source, you see the following
displayed:
• IP address
• Administrative distance
• Time the last update was received from this source
The show ip route Command

The show ip route command displays the entries in the routing table. You can use this
command to determine whether routes appear in the routing table. This can help you determine
whether IP routing is running (and able to populate the routing table with entries) and whether
the routing protocol is misconfigured on one or several of the routers in the network. This might
be the cause of host access problems (for example, if you see the message “host or destination
unreachable”).
You can include the optional address keyword to limit the display to only information about
that address. You can include a protocol keyword (bgp, egp, eigrp, igrp, isis, ospf, rip, static,
or connected) to limit the display to information about only that routing protocol. To limit the
output, use the summary keyword, which displays counts of networks but not the whole table.
Figure 7-11 shows sample output from the show ip route command.
Figure 7-11 All known routes in the network should be listed in the routing table.
Router# show ip route
Codes: I - IGRP derived, R - RIP derived, O - OSPF derived

C - connected, S - static, E - EGP derived, B - BGP derived
* - candidate default route, IA - OSPF inter area route
E1 - OSPF external type 1 route, E2 - OSPF external type 2 route
Gateway of last resort is 131.119.254.240 to network 129.140.0.0
O E2 150.150.0.0 [160/5] via 131.119.254.6, 0:01:00, Ethernet2
E 192.67.131.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2
O E2 192.68.132.0 [160/5] via 131.119.254.6, 0:00:59, Ethernet2
O E2 130.130.0.0 [160/5] via 131.119.254.6, 0:00:59, Ethernet2
E 128.128.0.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2
E 129.129.0.0 [200/129] via 131.119.254.240, 0:02:22, Ethernet2
E 192.65.129.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2
E 131.131.0.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2
E 192.75.139.0 [200/129] via 131.119.254.240, 0:02:23, Ethernet2
E 192.16.208.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2
E 192.84.148.0 [200/129] via 131.119.254.240, 0:02:23, Ethernet2
E 192.31.223.0 [200/128] via 131.119.254.244, 0:02:22, Ethernet2
continues
The show ip traffic Command

The show ip traffic command displays the statistics that the router has gathered about its IP
protocol processes. This includes packets received and sent, and in some cases, the broadcasts
and error counts. Included in the error statistics that can help you with debugging are format
errors, bad hop count, failed encapsulations, and packets discarded due to no route.
Figure 7-12 shows sample output from the show ip traffic command.
Figure 7-12 The show ip traffic command provides a summary of IP overhead traffic on the router.
Router# show ip traffic
IP statistics:
Rcvd: 98 total, 98 local destination
0 format errors, 0 checksum errors, 0 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options
Frags: 0 reassembled, 0 timeouts, 0 too big
0 fragmented, 0 couldn’t fragment
Bcast: 38 received, 52 sent
Sent: 44 generated, 0 forwarded
0 encapsulation failed, 0 no route
ICMP statistics:
Rcvd: 0 format errors, 0 checksum errors, 0 redirects, 0 unreachable
0 echo, 0 echo reply, 0 mask requests, 0 mask replies, 0 quench
0 parameter, 0 timestamp, 0 info request, 0 other
Sent: 0 redirects, 3 unreachable, 0 echo, 0 echo reply
0 mask requests, 0 mask replies, 0 quench, 0 timestamp
0 info reply, 0 time exceeded, 0 parameter problem
UDP statistics:
Rcvd: 56 total, 0 checksum errors, 55 no port
Sent: 18 total, 0 forwarded broadcasts
TCP statistics:
Rcvd: 0 total, 0 checksum errors, 0 no port
Sent: 0 total
EGP statistics:
Rcvd: 0 total, 0 format errors, 0 checksum errors, 0 no listener
Sent: 0 total
IGRP statistics:
Rcvd: 73 total, 0 checksum errors
Sent: 26 total
HELLO statistics:
Rcvd: 0 total, 0 checksum errors
Sent: 0 total
ARP statistics:
Rcvd: 20 requests, 17 replies, 0 reverse, 0 other
Sent: 0 requests, 9 replies (0 proxy), 0 reverse
Probe statistics:
Rcvd: 6 address requests, 0 address replies
0 proxy name requests, 0 other
Sent: 0 address requests, 4 address replies (0 proxy)
0 proxy name replies
Figure 7-13 Routing updates are displayed in real-time.

Router# debug ip eigrp
IP-EIGRP: Processing incoming UPDATE packet

IP-EIGRP: Ext 192.168.3.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256000
104960
IP-EIGRP: Ext 192.168.0.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256000
104960
IP-EIGRP: Ext 192.168.3.0 255.255.255.0 M 386560 - 256000 130560 SM 360960 - 256000
104960
IP-EIGRP: 172.24.43.0 255.255.255.0, - do advertise out Ethernet0/1
IP-EIGRP: Ext 172.24.43.0 255.255.255.0 metric 371200 - 256000 115200
Field Description
IP-EIGRP: Indicates that this is an IP Enhanced IGRP packet.
Ext Indicates that the following address is an external destination rather than an
internal destination, which would be labeled as Int.
M Shows the computed metric, which includes SM and the cost between this
router and the neighbor. The first number is the composite metric. The next
two numbers are the inverse bandwidth and the delay, respectively.
SM Shows the metric as reported by the neighbor.
The debug ip icmp Command

The debug ip icmp command helps you determine whether the router is sending or receiving
ICMP messages, such as redirect or network unreachable messages. You can use this command
when you are troubleshooting an end-to-end connection problem. Figure 7-14 shows sample
output from the debug ip icmp command.
Field Description
from 10.95.192.4 Source address of the ICMP packet.
ICMP: Indicates that this message describes an ICMP packet.
src 10.5610.120.0.202 The address of the sender of the echo.
dst 172.16.16.1 The address of the receiving router.
echo reply Indication the router received an echo reply.
The debug ip igrp events Command

The debug ip igrp events command displays summary information about IGRP routing
messages, such as the source and destination of each update, and the number of routes in each
update. This command is useful when there are many networks in your routing table and the
router is very busy. To avoid flooding the console, use this command instead of the debug ip
igrp transactions command. Figure 7-15 shows sample output from the debug ip igrp
transactions command.
Figure 7-15 You can use the debug ip igrp transactions command to display routing update contents.
Router# debug ip igrp transactions
IGRP: received update from 160.89.80.240 on Ethernet
subnet 160.89.66.0, metric 1300 (neighbor 1200)
network 192.82.152.0, metric 158550 (neighbor 158450)
network 192.68.151.0, metric 1115511 (neighbor 1115411)
network 150.136.0.0, metric 16777215 (inaccessible)
exterior network 129.140.0.0, metric 9676 (neighbor 9576)
exterior network 140.222.0.0, metric 9676 (neighbor 9576)
IGRP: received update from 160.89.80.28 on Ethernet
subnet 160.89.15.0, metric 16777215 (inaccessible)
IGRP: sending update to 255.255.255.255 via Ethernet0 (160.89.64.31)
subnet 160.89.94.0, metric=847
IGRP: sending update to 255.255.255.255 via Serial1 (160.89.94.31)
subnet 160.89.80.0, metric=16777215
subnet 160.89.64.0, metric=1100
The output shows that the router being debugged has received updates from two other routers
on the network. The router at source address 160.89.80.240 sent information about 10
destinations in the update; the router at source address 160.89.80.28 sent information about 3
destinations in its update. The router being debugged also sent updates—in both cases to the
broadcast address 255.255.255.255 as the destination address. On the second line the first field
refers to the type of destination information: subnet (interior), network (system), or exterior
(exterior). The second field is the Internet address of the destination network. The third field
is the metric stored in the routing table and the metric advertised by the neighbor sending
the information. An inaccessible metric usually means that the neighbor router has put the
destination in holddown. The entries show that the router is sending updates that are similar,
except that the numbers in parentheses are the source addresses used in the IP header. A metric
of 16777215 is inaccessible.
The debug ip ospf events Command

The debug ip ospf events command displays information about OSPF-related events, such as
adjacencies, flooding information, designated router selection, and shortest path first (SPF)
calculations. If a router configured for OSPF routing is not seeing an OSPF neighbor on an
attached network, you can use this command to make sure this router’s OSPF hello and dead
intervals and its IP subnet mask match those configured for the neighbor. Figure 7-16 shows
sample output from the debug ip ospf events command.
Figure 7-16 Verifying hello packets being received is useful for solving neighbor problems with directly
connected routers.
Router# debug ip ospf events
OSPF:hello with invalid timers on interface Ethernet0

hello interval received 10 configured 10
net mask received 255.255.255.0 configured 255.255.255.0
dead interval received 40 configured 30
The debug ip packet Command

The debug ip packet command displays general IP debugging information and IP security
option transactions. You can use this command to analyze messages traveling between local
and remote hosts when troubleshooting an end-to-end connection problem. IP debugging
information includes packets received, generated, and forwarded. Fast-switched packets do
not generate messages. An optional access-list-number argument lets you limit the scope (and
resulting load on the router) caused by this debugging command. You can use this command
to analyze messages traveling between local and remote hosts when troubleshooting an end-to-
end connection problem. IP debugging information includes packets received, generated, and
forwarded. Fast-switched packets do not generate messages. Figure 7-17 shows sample output
from the debug ip packet command.
Figure 7-17 The output shows two types of messages that the debug ip packet command can produce.
Router# debug ip packet
IP: s=172.16.13.44 (Fddi0), d=10.125.254.1 (Serial2), g=172.16.16.2, forward

IP: s=172.16.1.57 (Ethernet4), d=10.36.125.2 (Serial2), g=172.16.16.2, forward
IP: s=172.16.1.6 (Ethernet4), d=255.255.255.255, rcvd 2
IP: s=172.16.1.55 (Ethernet4), d=172.16.2.42 (Fddi0), g=172.16.13.6, forward
continues
Figure 7-17 The output shows two types of messages that the debug ip packet command can produce. (Continued)
IP: s=172.16.89.33 (Ethernet2), d=10.130.2.156 (Serial2), g=172.16.16.2, forward
IP: s=172.16.20.32 (Ethernet2), d=255.255.255.255, rcvd 2
IP: s=172.16.1.57 (Ethernet4), d=10.36.125.2 (Serial2), g=172.16.16.2, access denied
The first line of output describes an IP packet that the router forwards, and the third line of
output describes a packet that is destined for the router. In the third line of output, rcvd 2
indicates that the router decided to receive the packet.
Field Description
IP: Indicates that this is an IP packet.
s = 172.16.13.44 (Fddi0) Indicates the source address of the packet and the name of
the interface that received the packet.
d = 10.125.254.1 (Serial2) Indicates the destination address of the packet and the
name of the interface (in this case, S2) through which the
packet is being sent out on the network.
g = 172.16.16.2 Indicates the address of the next-hop gateway.
forward Indicates that the router is forwarding the packet. If a filter
denies a packet, access denied replaces forward, as shown
in the last line of output.
The debug ip rip Command

The debug ip rip command displays information about Routing Information Protocol (RIP)
routing transactions, such as routing table updates sent and received on an interface. Figure
7-18 shows sample output from the debug ip rip command.
Figure 7-18 The debug ip rip command displays routing update contents sent and received by the router.
router# debug ip rip
RIP: received update from 160.89.80.28 on Ethernet0
160.89.95.0 in 1 hops
160.89.81.0 in 1 hops
160.89.66.0 in 2 hops
131.108.0.0 in 16 hops (inaccessible)
0.0.0.0 in 7 hop
RIP: sending update to 255.255.255.255 via Ethernet0 (160.89.64.31)
subnet 160.89.94.0, metric 1
RIP: sending update to 255.255.255.255 via Serial1 (160.89.94.31)
default 0.0.0.0, metric 8
The output shows that the router being debugged has received updates from one router at source
address 160.89.80.28. That router sent information about five destinations in the routing table
update. Notice that the fourth destination address in the update—131.108.0.0—is inaccessible
because it is more than 15 hops away from the router sending the update. The router being
debugged also sent updates, in both cases to broadcast address 255.255.255.255 as the
destination. The second line is an example of a routing table update. It shows how many hops
a given Internet address is from the router.
The debug arp Command

You use the debug arp command to check the flow of information on Address Resolution
Protocol (ARP) transactions. You use it for problems in which some nodes on a TCP/IP network
respond but other nodes do not respond. debug arp checks whether the router is sending and
receiving ARP requests and replies.
Figure 7-19 shows output from the debug arp command. Each line of output represents an ARP
packet that the router sent or received.
Figure 7-19 The fourth output line indicates a problem—the router received an ARP reply for its own address!
router# debug arp
IP ARP: sent req src 131.108.22.7 0000.0c01.e117, dst 131.108.22.96 0000.0000.0000
IP ARP: rcvd rep src 131.108.22.96 0800.2010.b908, dst 131.108.22.7
IP ARP: rcvd req src 131.108.6.10 0000.0c00.6fa2, dst 131.108.6.62
IP ARP: rep filtered src 131.108.22.7 080.5a36.a4 56, dst 255.255.255.255
ffff.ffff.ffff
The first line of the output indicates that the router at IP address 131.108.22.7 and MAC address
0000.0c01.e117 sent an ARP request for the MAC address of the host at 131.108.22.96. The
series of zeros (0000.0000.0000) following this address indicates that the router is currently
unaware of the MAC address.
The second line of the output indicates that the router at IP address 131.108.22.7 received a
reply from the host at 131.108.22.96, and the host’s MAC address is 0800.2010.b908.
The third line of output indicates that the router received an ARP request from the host at
131.108.6.10 requesting the MAC address for the host at 131.108.6.62.
The fourth line of the output indicates that another host on the network attempted to send the
router an ARP reply for the router’s address. The router filters meaningless replies. Usually,
meaningless replies are caused by a configuration problem. Another station might be
incorrectly configured with the router’s IP address. This can cause serious internetworking
problems and should be investigated.
From this output, you can tell that the router filters improper replies but displays them when the
debug arp command is issued. You can use the information displayed to troubleshoot.
Problem Isolation in TCP/IP Networks 303
— Use IP addresses, not names, to rule out problems with the DNS.
Step 3 When you discover a router that does not respond to pings:
— Examine the router’s configuration (by using show commands to

determine the router state)
— Examine the router’s routing table (by using show ip route to make
sure a path to the remote host is in the table)
— Examine ARP tables (by using show ip arp to make sure a node that
can reach the remote host is in the table)
— Examine the router’s fast-switching route cache (by using show ip
cache to look for anomalies)
— Check the router’s interfaces for any signs of LAN or WAN errors.
— Use protocol analyzers, time domain reflectometers (TDRs) and bit
error rate testers (BERTs) to isolate the cause of errors.
Step 4 Check the configuration of the remote host you are trying to reach. Check its
address, subnet mask, default gateway, and DNS name.
The following sections describe some real-life IP troubleshooting examples.
Symptom: Users Can Access Some Hosts but Not Others

Many problems in IP environments are caused by addressing and subnet mask problems. In this
example, as shown in Figure 7-21, the symptoms are that users can access some hosts but not
others. Also, the router and hosts cannot reach certain parts of their own networks.
Figure 7-21 The network experiences connectivity problems.
Host D
10.1.2.7
255.255.255.0
Subnet 2
Ethernet 1
10.1.2.1
255.255.255.0
Ethernet 0
10.1.1.1
255.255.255.0 Subnet 1
Host A Host B Host C

10.1.1.5 10.1.1.6 10.1.2.8
255.255.255.0 255.255.0.0 255.255.0.0
TCP/IP Problems and Action Plans 309
Table 7-3 Common TCP/IP symptoms and possible problems.

Symptom Possible Problem
Host cannot access offnet hosts through router. • No default gateway specified on local host
• Misconfigured subnet mask on local host
• Router between hosts is down
Host cannot access certain networks through router. • No default gateway specified on local host
• Misconfigured access list
• Discontiguous network due to poor design
or link failure
Users can access some hosts, but not others. • Misconfigured subnet mask or address on
hosts or router
• No default gateway specified on remote
host
Some services are available, but others are not. • Misconfigured extended access list
Users cannot connect when one redundant path is • Discontiguous network due to link failure
down. • Routing has not converged
• Misconfigured access list or other routing
filters
Router sees duplicate routing updates and packets. • Bridge or repeater in parallel with router
Certain protocols are being routed, but others are not. • Misconfigured access list
Router or host cannot reach certain parts of its own • Subnet mask configuration mismatch
network. between router and host
• No default gateway specified
Routing is not working when redistribution is used. • Missing redistribute or default-metric
command
• Problem with default administrative
distance
TCP/IP Problems and Action Plans

Table 7-4 provides a list of possible problems and some suggested action plans to help isolate
the sources of the problems.
Table 7-4 Suggested action plans. (Continued)

Problem Action Plan
Routing has not converged • Check for problems by using show ip
route.
Discontiguous network due to poor design or link • Check routes and how they are learned by
failure using show ip route.
• trace or ping to determine where traffic
stops.
• Fix topology or reassign addressing (assign
segments to same major network).
• If backup path exists, assign secondary
address.
• If discontiguous network due to link
failure, fix link.
Routing has not converged • Check for problems by using show ip
route.
To determine whether a default gateway is included in the routing table of a UNIX host, use
the netstat -rn UNIX command. Look at the output of this command for a default gateway
specification. If the default gateway specification is incorrect, or if it is not present, you can
change or add a default gateway by using the route add default address 1 command at the local
host. (address is the IP address of the default gateway; the value 1 indicates that the specified
node is one hop away.) You might need to reboot the host for this change to take effect.
To automate this as part of the boot process, specify the default IP address of the gateway in the
/etc/defaultrouter UNIX host file. This filename may be different for your particular version of
UNIX. If you are working with a PC or a Macintosh, consult the corresponding documentation
to determine how to set the default gateway.
When troubleshooting possible misconfigured access lists or other filters, use the show ip route
command to check routing tables. Use the appropriate debug commands or a protocol analyzer
to check protocol exchanges. Look for information concerning the network with which you are
unable to communicate. Check the use of access lists on the routers in the path and make sure
that a distribute-list or distance router configuration command does not filter out the route.
Temporarily remove ip access-group interface configuration commands to disable access lists,
and use the trace or ping command with the Record Route option to determine whether traffic
can get through when the access list is removed. After you have determined which access lists
are causing the problems, debug the access lists, reapply them, and test to make sure the
problems have been solved.
NOTE Much of the troubleshooting information in the rest of this chapter derives from procedures on
Microsoft’s Technical Support Web site. Refer to www.microsoft.com/support/ for updates and
other details.
When you cannot connect to a specified IP target on a network with Windows NT hosts, try to
isolate the problem with ping tests. Use the ipconfig /all DOS command on the other computer
to determine current IP address settings.
pinging Your Loopback and Local IP Addresses

The loopback ping test checks whether TCP/IP itself is working properly:
C:\>ping 127.0.0.1
An error at this point would indicate that TCP/IP is not properly installed.
If the loopback ping returns successful echoes, try pinging your own host address. Target the
local IP address you have obtained from the NT host control panel or ipconfig output. An error
at this point indicates a possible problem interfacing with the network adapter.
pinging Your Cisco Router

You need to determine whether you can reach a router. You can use a console connection or
Telnet to get the router IP interface addresses. Target the address of the Cisco router on the same
subnet as the NT host. Then to check routing, target a different IP address (for example, the IP
address on a different router interface).
pinging the DNS Server, Default Gateway, and WINS Server

To test whether you are able to communicate with the server, ping the DNS server’s address
that is listed as output from the ipconfig command. ipconfig also returns the default gateway
and the WINS server in use (if any). Check this information, and verify that the listed address
for each of these servers is correct.
If you cannot ping the address of your server or gateway, the server or gateway either does not
exist or has the wrong address entered.
If you cannot connect to a server by using the machine name, you might be having a problem
connecting to your WINS server to provide NetBIOS name resolution, or the WINS server may
not be resolving names. To determine whether you can communicate with the WINS server,
ping the server’s address.
To change or add a valid IP address, you can edit the TCP/IP properties in Network properties
as follows:
Step 1 In the Control Panel, double-click Network.
Step 2 On the Protocols tab, click the TCP/IP protocol, and then click Properties.
Step 3 Click the tab for the appropriate server.
Step 4 If you are adding a server or gateway, click Add. If you are editing an existing
server or gateway, click the appropriate server or gateway address, and then
click Edit.
Step 5 Type the new server or gateway IP address, and then click OK.
Step 6 Click OK again, and then click Close. You may need to reboot the computer
after this step.
Step 7 Retest connectivity to the IP address of the server or gateway by using ping.
pinging the Remote Target IP Address

You should try to ping the computer you are having trouble connecting to. If you cannot ping
the computer, the problem might be caused by an incorrect target address or subnet mask. You
might need to contact the target system’s network administrator or the owner of the computer
you are trying to connect to in order to obtain the correct IP address.
Similarly, you might need to verify that other appropriate services are running on the target
computer. For example, if you are attempting to Telnet to the remote computer, make sure that
the Telnet server service is running on the target computer. To do this, attempt to connect to the
remote computer from another host, preferably one on the same subnet as the target computer.
The tracert Tool

The tracert tool on an NT host reports each connection a TCP/IP packet crosses on its way to
a destination. The syntax for the tracert command is
tracert [-d] [-h maximum-hops] [-j host-list] [-w timeout] target-name
Its parameters are as follows:
Parameter Description
-d Specifies to not resolve addresses to host names.
-h maximum-hops Specifies the maximum number of hops to take in searching for the target.
Parameter Description
-j host-list Specifies a loose source route along the host list.
-w timeout Waits the number of milliseconds specified by timeout for each reply.
target-name The name or IP address of the target host.
Errors that may occur include the asterisk (*) and a message that the request timed out. This
message indicates a problem with the router (either the router the packet passed or the first one
to return a timeout) or elsewhere on the network.
Another common error is a report that a destination network is unreachable. This error might
indicate that there is a proxy or a firewall between your computer and the computer you are
targeting as your tracert destination.
Checking the Routing Table on a Windows NT System

To verify the routing table on a Windows NT system, type the route print command at a
command prompt. In this example, the local IP address is 192.1.1.3, and the default gateway is
192.1.1.254. The response should be similar to that shown in Table 7-5.
Table 7-5 A Windows NT routing table.
Network Gateway
Address Netmask Address Interface Metric
0.0.0.0 0.0.0.0 192.1.1.254 192.1.1.3 1
192.1.0.0 255.255.0.0 192.1.1.3 192.1.1.3 1
192.1.1.3 255.255.255.255 127.0.0.1 127.0.0.1 1
192.255.255.255 255.255.255.255 192.1.1.3 192.1.1.3 1
127.0.0.1 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 224.0.0.0 192.1.1.3 192.1.1.3 1
255.255.255.255 255.255.255.255 192.1.1.3 192.1.1.3 1
Starting from the top of Table 7-5, the entries are

• Default gateway
• Local network
• Local host
• Network broadcast
• Loopback
• Multicast address
• Limited broadcast
Note that the order of the entries in your routing table may vary. If you have TCP/IP bound to
more than one network card in your computer, you will have additional entries in your table.
Make sure that one of the table entries is not pointing to an incorrect gateway for the computer
you are attempting to target with your connection attempt. To remove an entry in the routing
table, type
route delete [destination-ip] mask [subnet-mask] [gateway]
where destination-ip is the IP address of the entry, subnet-mask is the subnet mask, and gateway
is the gateway.
Clearing the Windows NT System ARP Cache

You should try to fix an address problem by clearing the ARP cache. The ARP cache is a list
of recently resolved IP address-to-MAC address mappings. If an entry in the ARP cache is
incorrect, the TCP/IP packet is sent to the wrong computer. Figure 7-24 shows output from the
arp -a command, which displays the cache.
Figure 7-24 The arp –a command displays all entries from a Windows NT ARP cache.
C:\>arp -a
Interface: 192.1.1.3 on Interface 2
Internet Address Physical Address Type
192.1.1.1 08-00-02-06-ed-20 dynamic
192.1.1.2 08-00-02-0a-a3-10 dynamic
To remove entries, use the command arp -d [ip-address], where ip-address is the IP address of
the incorrect entry.
If you are using TCP/IP in your network and have verified that the IP settings are correct, the
sequence of how to resolve non-IP entities begins with NBT—NetBEUI over TCP/IP. This
approach includes checking DNS configuration as well as the HOSTS and LMHOSTS files.
DNS Configuration
If you can connect to the server by using the IP address only, you may be having trouble
with your DNS service. If you do not have a DNS server address configured, you cannot
communicate on the network via domain names. You need to contact your network
administrator to obtain a valid DNS server address. When you have a valid DNS address,
you need to update your TCP/IP settings or Dial-Up Networking phone book entry.
The HOSTS File

You should check the HOSTS file for an improper entry. The HOSTS file is usually located in
the Winnt\System32\Drivers\Etc folder. The HOSTS file is a text file that you can edit with any
text editor (such as Notepad).
Search the file for the host name you are attempting to connect to, and verify that any entries
are correct. Remove or correct any improper entries. Make sure that there is a carriage return
after the last entry. If not, it will be ignored.
The LMHOSTS File

The LMHOSTS file is usually located in the Winnt\System32\Drivers\Etc folder. The
LMHOSTS file is a text file that you can edit with any text editor (such as Notepad). Check
the LMHOSTS file for an improper entry. Search the file for the host name you are attempting
to connect to, and verify that any entries are correct.
Microsoft recommends that if there are any #include entries, you should temporarily remove
them; also, remove any #BEGIN_ALTERNATE to #END_ALTERNATE blocks.
If removing lines in the LMHOSTS file corrects the problem, add back one line at a time until
the problem recurs, and then search the appropriate LMHOSTS files pointed to by the line most
recently added. This process of elimination may provide a way to isolate the cause of the
problem.
Winsock Proxy Problems

The NT system might be configured to use a proxy agent for connections to remote hosts. This
use of a proxy can cause problems when the NT system tries to connect to hosts that should not
have to go through the proxy.
To determine a Winsock proxy setting, check for a WSP icon in Control Panel. If one exists, try
disabling it by clearing the Enable Winsock Proxy. Check the Client check box. After rebooting
the NT system, try connecting again.
If the check box was already cleared, click on it to select it. You might need to contact your
system administrator for the name of the proxy server or you may be able to examine a
computer that can connect and copy its WSP information.
Many Web browsers have built-in support for proxies. If you are attempting to connect with
HTTP to a remote Web site, you might need to disable or enable proxy support on the NT
system.
Check the documentation provided with your Web browser software for information
concerning proxies. For example, if you are using Netscape’s rather than Microsoft’s browser,
check the Web site home.netscape.com.
CHAPTER
8
Troubleshooting Novell
Connectivity
This chapter discusses troubleshooting tips and techniques specific to the Novell NetWare
protocol suite. The goal is to help you prepare for real-world troubleshooting on the job.
NOTE This chapter focuses specifically on Novell networks based on Internetwork Packet
Exchange (IPX)/Sequenced Packet Exchange (SPX) communications. If you are working
on a NetWare 5 network that supports Pure IP (that is, NetWare commands native over
Transmission Control Protocol/Internet Protocol [TCP/IP] instead of IPX), refer to Chapter
7, “Troubleshooting TCP/IP Connectivity.”
Novell NetWare Router Diagnostic Tools

Three diagnostic commands are primarily used to troubleshoot Novell networks:
• ping
• show
• debug
The following sections focus on the Novell-specific parameters that can be used with these
commands.
The IPX ping Command

The IPX ping command works only on Cisco routers running Cisco IOS 8.2 or later. By
default, the IPX ping command sends Cisco-proprietary pings. Novell IPX devices do not
respond to this command. To change to the new Novell ping, use the ping-default novell
command. Novell pings conform to the definition in the NetWare Link Services Protocol
(NLSP) specification. You do not need to run NLSP to use the Novell ping, however.
IPXPING.NLM is included in the IPXRTx upgrade for NetWare 3.x and 4.x servers. Figure
8-1 shows sample output from the Novell ping command.
324 Chapter 8: Troubleshooting Novell Connectivity
Figure 8-1 Novell pings are useful tools for Layer 3 testing.
Router# ping
Protocol [ip]: ipx
Target IPX address: 211.0000.0c01.f4cf
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Novell Standard Echo [n]:y
Sending 5 100-byte IPX echoes to 211.0000.0c01.f4cf, timeout is 2 seconds.
!!!!!
The IPX show Commands

Some of the most common show commands used when troubleshooting IPX networks on Cisco
routers are
• show ipx eigrp topology
• show ipx interface
• show ipx nlsp database
• show ipx route
• show ipx servers
• show ipx traffic
The show commands provide essential information about interface conditions, protocol status,
neighbor reachability, and traffic. You can use the commands described in the following
sections when troubleshooting IPX networks.
NOTE More details on these commands can be found in Cisco IOS Command Reference.
The show ipx eigrp topology Command

The show ipx eigrp topology command displays the IPX Enhanced Interior Gateway Routing
Protocol (Enhanced IGRP) topology table. A related command is show ipx eigrp neighbors,
which displays the neighbors discovered by Enhanced IGRP. Figure 8-2 shows sample output
from the show ipx eigrp topology command.
Field Description
successors Number of successors. This number corresponds to the number of next
hops in the IPX routing table.
FD Feasible distance. This value is used in the feasibility condition check. If
the neighbor’s reported distance (the metric after the slash) is less than
the feasible distance, the feasibility condition is met and that path is a
feasible successor. When the router determines that it has a feasible
successor, it does not have to send a query for that destination.
replies Number of replies that are still outstanding (that is, have not been
received) with respect to this destination. This information appears only
when the destination is in Active state.
state Exact Enhanced IGRP state that this destination is in. It can be the
number 0, 1, 2, or 3. This information appears only when the destination
is Active.
via IPX address of the peer who told the Cisco IOS software about this
destination. The first n of these entries, where n is the number of
successors, are the current successors. The remaining entries on the list
are feasible successors.
(345088/319488) The first number is the Enhanced IGRP metric that represents the cost to
the destination. The second number is the Enhanced IGRP metric that
this peer advertised.
Ethernet0 The interface from which this information was learned.
The show ipx interface Command

The show ipx interface command displays the configured parameters and status of IPX
interfaces. Figure 8-3 shows sample output from the show ipx interface command.
Figure 8-3 The show ipx interface command provides useful information for verifying and troubleshooting interface
configuration problems.
Router# show ipx interface ethernet 1

IPX address is C03.0000.0c05.6030, NOVELL-ETHER [up] line-up, RIPPQ: 0, SAPPQ : 0
Delay of this Novell network, in ticks is 1
IPXWAN processing not enabled on this interface.
IPX SAP update interval is 1 minute(s)
IPX type 20 propagation packet forwarding is disabled
Outgoing access list is not set
IPX Helper access list is not set
SAP Input filter list is not set
SAP Output filter list is not set
SAP Router filter list is not set
SAP GNS output filter list is not set
Novell NetWare Router Diagnostic Tools 329
Field Description
Router filter list Number of the router entry filter applied to the
interface with the ipx router-filter command.
Netbios Input host access list Name of the IPX NetBIOS input host filter
applied to the interface with the ipx netbios
input-access-filter host command.
Netbios Input bytes access list Name of the IPX NetBIOS input bytes filter
input-access-filter bytes command.
Netbios Output host access list Name of the IPX NetBIOS output host filter
input-access-filter host command.
Netbios Output bytes access list Name of the IPX NetBIOS output bytes filter
input-access-filter bytes command.
Update time How often the Cisco IOS software sends RIP
updates, as configured with the ipx update sap-
after-rip command.
Watchdog spoofing … Indicates whether watchdog spoofing is enabled
or disabled for this interface, as configured with
the ipx watchdog-spoof command. This
information is displayed only on serial interfaces.
IPX accounting Indicates whether IPX accounting has been
enabled with the ipx accounting command.
IPX SSE switching Indicates whether IPX SSE switching is enabled
for this interface, as configured with the ipx
route-cache sse command.
The show ipx nlsp database Command

The show ipx nlsp database command displays the entries in the link-state database. A related
command is show ipx nlsp neighbors, which shows the router’s NLSP neighbors and their
states. Figure 8-4 shows sample output from the show ipx nlsp database command.
Figure 8-4 You can use the show ipx nlsp database command to verify NLSP operation.
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
0000.0C00.3097.00-00* 0x00000042 0xC512 699 0/0/0
0000.0C00.3097.06-00* 0x00000027 0x0C27 698 0/0/0
0000.0C02.7471.00-00 0x0000003A 0x4A0F 702 0/0/0
0000.0C02.7471.08-00 0x00000027 0x0AF0 702 0/0/0
0000.0C02.747D.00-00 0x0000002E 0xC489 715 0/0/0
0000.0C02.747D.06-00 0x00000027 0xEEFE 716 0/0/0
continues
Figure 8-5 All known networks should be listed in the IPX routing table.
Router# show ipx route
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
8 Total IPX routes. Up to 1 parallel paths and 16 hops allowed.
No default route known.
L D40 is the internal network
C 100 (NOVELL-ETHER), Et1
C 7000 (TUNNEL), Tu1
S 200 via 7000.0000.0c05.6023, Tu1
R 300 [02/01] via 100.0260.8c8d.e748, 19s, Et1
S 2008 via 7000.0000.0c05.6023, Tu1
R CC0001 [02/01] via 100.0260.8c8d.e748, 19s, Et1
Field Description
Codes Codes defining how the route was learned:
L—Local Internal network number.
C—Connected primary Directly connected primary network.
network
c—connected secondary Directly connected secondary network.
network
S—Static Statically defined route via the ipx route
command.
R—RIP Route learned from a RIP update.
E—EIGRP Route learned from an Enhanced IGRP update.
W—IPXWAN Directly connected route determined via
IPXWAN.
8 Total IPX routes Number of routes in the IPX routing table.
No parallel paths Maximum number of parallel paths for which the Cisco IOS software has
allowed been configured with the ipx maximum-paths command.
Novell routing Indicates whether the Cisco IOS software is using the IPX-compliant routing
algorithm variant in algorithms (default).
use
Net 1 Network to which the route goes.
continues
Field Description
[3/2] Delay/Metric. Delay is the number of IBM clock ticks (each tick is 1/18
second) reported to the destination network. Metric is the number of hops
reported to the same network. Delay is used as the primary routing metric, and
the metric (hop count) is used as a tie-breaker.
via network.node Address of a router that is the next hop to the remote network.
Age Amount of time (in hours, minutes, and seconds) that has elapsed since
information about this network was last received.
Uses Number of times this network has been looked up in the route table. This field
is incremented when a packet is process-switched, even if the packet is
eventually filtered and not sent. As such, this field represents a fair estimate of
the number of times a route is used.
Ethernet0 Interface through which packets to the remote network will be sent.
(NOVELL-ETHER) Encapsulation (frame) type. This is shown only for directly connected
networks.
is directly connected Indicates that the network is directly connected to the router.
The show ipx servers Command

The show ipx servers command displays the IPX servers discovered through Service
Advertising Protocol (SAP) advertisements. Figure 8-6 shows sample output from the show ipx
servers command when NLSP is enabled.
Figure 8-6 All non-filtered SAPs should be listed in the SAP table.
Router# show ipx servers
Codes: S - Static, P - Periodic, E - EIGRP, N - NLSP, H - Holddown, + = detail

9 Total IPX Servers
Table ordering is based on routing and server info
TypeName Net Address Port Route Hops Itf
N+ 4 MERLIN1-VIA-E03 E03E03.0002.0004.0006:0451 4/03 4 Et0
N+ 4 merlin E03E03.0002.0004.0006:0451 4/03 3 Et0
N+ 4 merlin 123456789012345 E03E03.0002.0004.0006:0451 4/03 3 Et0
S 4 WIZARD1--VIA-E0 E0.0002.0004.0006:0451 none 2 Eto
N+ 4 dtp-15-AB E002.0002.0004.0006:0451 none 4 Et0
N+ 4 dtp-15-ABC E002.0002.0004.0006:0451 none 4 Et0
N+ 4 dtp-15-ABCD E002.0002.0004.0006:0451 none 4 Et0
N+ 4 merlin E03E03.0002.0004.0006:0451 4/03 3 Et0
N+ 4 dtp-15-ABC E002.0002.0004.0006:0451 none 4 Et0
Field Description
IPX Indication that this is an IPX packet.
src = 160.0260.8c4c.4f22 Source address of the IPX packet. The Novell
network number is 160. Its Media Access Control
(MAC) address is 0260.8c4c.4f22.
dst = 1.0000.0000.0001 Destination address for the IPX packet. The
address 0000.0000.0001 is an internal MAC
address, and the network number 1 is the internal
network number of a Novell 3.11 server.
packet received Indicates that the router received this packet from
a Novell station, possibly through an intermediate
router.
gw = 183.0000.0c01.5d85 Indicates that the router is sending the packet
over to the next hop router; its address of
183.0000.0c01.5d85 was learned from the IPX
routing table.
sending packet Indicates that the router is attempting to send this
packet.
The debug ipx routing Command

The debug ipx routing command displays information about IPX routing packets that the
router sends and receives. Figure 8-10 shows sample output from the debug ipx routing
command.
Figure 8-10 Routing updates are being sent and received every 60 seconds.
Router# debug ipx routing
IPXRIP: update from 9999.0260.8c6a.1733

110801 in 1 hops, delay 2
IPXRIP: sending update to 12FF02:ffff.ffff.ffff via Ethernet 1
network 555, metric 2, delay 3
network 1234, metric 3, delay 4
NetWare Problems and Action Plans 349
Table 8-2 Ethernet encapsulation types for IPX networks.

Cisco
Common Term Novell Term Term Characteristics
Ethernet V. 2 ETHERNET_II arpa Includes Ethertype
IEEE 802.3 ETHERNET_802.2 sap or iso1 Includes 802.3 length and 802.2 SAPs
Novell 802.3 raw ETHERNET_802.3 novell-ether Includes 802.3 length with no 802.2
SAPs
SNAP ETHERNET_SNAP snap Includes 802.2 SAPs and SNAP header
The ipx internal-network command establishes the number you specify as a primary network
number for the router. You must select a number for this entry that is unique across your
internetwork. NLSP and IPXWAN advertise and accept packets for this internal network
number out all the router interfaces. The NLSP process adds the host address 01. This means
that you can use the combined address network-number.01 as a ping target when
troubleshooting.
If you have selected NLSP as your routing protocol, you should enter the ipx router nlsp global
configuration command. Note that the routing protocol RIP also runs by default unless you
include the command no ipx router rip.
On each interface or subinterface, start the NLSP routing process by entering the ipx nlsp
enable interface configuration command.
NetWare Problems and Action Plans

Table 8-3 provides a list of problems and some suggested action plans to help isolate the source
of problems.
Table 8-3 NetWare problems and action plans.
Problem Suggested Action Plan
Client or server is not on network. • Attach a protocol analyzer to the network
to which the client and server are
connected. Look for the source addresses
of both.
• Look for an excessive number of collisions
or other lower-layer errors.
• Check NIC configuration parameters.
Client or router is not configured for correct frame • Check client configuration files.
encapsulation. • On the router, use the show running-
config command to check the IPX
encapsulation.
continues
358 Chapter 9: Troubleshooting AppleTalk Connectivity
The show appletalk access-lists Command

The show appletalk access-lists command displays the contents of all current AppleTalk
access lists. Figure 9-1 shows sample output from the show appletalk access-lists command.
Figure 9-1 Misconfigured access lists can be a cause of problems for AppleTalk networks.
Router> show appletalk access-lists
AppleTalk access list 601:
permit zone ZoneA
permit zone ZoneB
deny additional-zones
permit network 55
permit network 500
permit cable-range 900-950
deny includes 970-990
permit within 991-995
deny other-access
The following are the fields shown in the output in Figure 9-1:
Field Description
AppleTalk access list 601: Number of AppleTalk access lists.
permit zone Indicates whether access to an AppleTalk zone
deny zone has been explicitly permitted or denied with the
access-list zone command.
permit additional-zones Indicates whether additional zones have been
deny additional-zones permitted or denied with the access-list
additional-zones command.
permit network Indicates whether access to an AppleTalk
deny network network has been explicitly permitted or denied
with the access-list network command.
permit cable-range Indicates the cable ranges to which access has
deny cable-range been permitted or denied with the access-list
cable-range command.
permit includes Indicates the cable ranges to which access has
deny includes been permitted or denied with the access-list
includes command.
permit within Indicates the additional cable ranges to which
deny within access has been permitted or denied with the
access-list within command.
permit other-access Indicates whether additional networks or cable
deny other-access ranges have been permitted or denied with the
access-list other-access command.
AppleTalk Router Diagnostic Commands 361
Field Description
Encap Encapsulation type. It can be one of the following:
• ARPA
• Ethernet-type encapsulation
• Subnetwork Access Protocol (SNAP)
• IEEE 802.3 encapsulation
Interface Type and number of the interface
The show appletalk globals Command

The show appletalk globals command displays information about settings and parameters for
the router’s AppleTalk configuration. Figure 9-4 shows sample output from the show appletalk
globals command.
Figure 9-4 The show appletalk globals command provides a summary of AppleTalk overhead traffic on the router.
Router# show appletalk globals
AppleTalk global information:
The router is a domain router.
Internet is compatible with older, AT Phase1, routers.
There are 67 routes in the internet.
There are 25 zones defined.
All significant events will be logged.
ZIP resends queries every 10 seconds.
RTMP updates are sent every 10 seconds.
RTMP entries are considered BAD after 20 seconds.
RTMP entries are discarded after 60 seconds.
AARP probe retransmit count: 10, interval: 200.
AARP request retransmit count: 5, interval: 1000.
DDP datagrams will be checksummed.
RTMP datagrams will be strictly checked.
RTMP routes may not be propagated without zones.
Alternate node address format will not be displayed.
Field Description
AppleTalk global information: Heading for the command output.
The router is a domain router. Indicates whether this router is a domain router.
Internet is compatible with older, AT Phase1 Indicates whether the AppleTalk internetwork
routers. meets the criteria for interoperation with Phase 1
routers.
There are 67 routes in the internet. Total number of routes in the AppleTalk
internetwork from which this router has heard in
routing updates.
continues
Field Description
RTMP routes may not be propagated without Indicates whether the appletalk require-route-
zones. zones configuration command is enabled. When
enabled, the Cisco IOS software does not
advertise a route to its neighboring routers until it
has obtained a network/zone association for that
route.
Alternate node address format will not be Indicates whether AppleTalk addresses will be
displayed. printed in numeric or name form. You configure
this with the appletalk lookup-type and
appletalk name-lookup-interval commands.
The show appletalk interface Command

The show appletalk interface command displays the status of the AppleTalk interfaces
configured in the router and the parameters configured on each interface. Figure 9-5 shows
sample output from the show appletalk interface command.
Figure 9-5 The show appletalk interface command is useful for debugging interface configuration errors.
Router# show appletalk interface fddi 0
Fddi0 is up, line protocol is up
AppleTalk cable range is 4199-4199
AppleTalk address is 4199.82, Valid
AppleTalk zone is “Low End SW Lab”
AppleTalk address gleaning is disabled
AppleTalk route cache is enabled
Interface will not perform pre-FDDITalk compatibility
NOTE The show appletalk interface command can show a node name in addition to the address,
depending on how the software has been configured with the appletalk lookup-type and
appletalk name-lookup-interval commands.
The following are the fields shown in the display as well as some fields not shown but that also
may be displayed:
Field Description
FDDI is… Type of interface and whether it is currently
active and inserted into the network (up) or
inactive and not inserted (down).
continues
Figure 9-6 The show appletalk name-cache command is useful for verifying NBP operations.
Router# show appletalk name-cache
AppleTalk Name Cache:
Net Adr Skt Name Type Zone
4160 19 8 gatekeeper SNMP Agent Underworld
4160 19 254 gatekeeper.Ether4 ciscoRouter Underworld
4160 86 8 bones SNMP Agent Underworld
4160 86 72 131.108.160.78 IPADDRESS Underworld
4160 86 254 bones.Ethernet0 IPGATEWAY Underworld
Field Description
Net AppleTalk network number or cable range.
Adr Node address.
Skt DDP socket number.
Name Name of the service.
Type Device type. The possible types vary, depending on the service. The
following are the Cisco server types:
• Cisco Router—Server is a Cisco router.
• SNMP Agent—Server is an SNMP agent.
• IPGATEWAY—Active MacIP server names.
• IPADDRESS—Active MacIP server addresses.
Zone Name of the AppleTalk zone to which this address belongs.
The show appletalk route Command

The show appletalk route command displays all entries or specified entries in the AppleTalk
routing table. Figure 9-7 shows sample output from the show appletalk route command.
Figure 9-7 All known networks should be displayed in the AppleTalk routing table.
Router# show appletalk route
Codes: R - RTMP derived, E - EIGRP derived, C - connected, A - AURP
P - proxy, S - static
5 routes in internet
E Net 10000 -10000 [1/G] via 300.199, 275 sec, Ethernet2, zone France
R Net 890 [2/G] via 4.129, 1 sec, Ethernet0, zone release lab
R Net 901 [2/G] via 4.129, 1 sec, Ethernet0, zone Dave’s House
C Net 999-999 directly connected, Serial3, zone Magnolia Estates
R Net 2003 [4/G] via 80.129, 6 sec, Ethernet4, zone Bldg-13
Figure 9-15 RTMP updates are sent and received every 10 seconds by the router.
Router# debug apple routing
AT: src=Ethernet0:4160.41, dst=4160-4160, size=19, 2 rtes, RTMP pkt sent
AT: src=Ethernet1:41069.25, dst=41069, size=427, 96 rtes, RTMP pkt sent
AT: Route ager starting (97 routes)
AT: Route ager finished (97 routes)
AT: RTMP from 4160.19 (new 0,old 94,bad 0,ign 0, dwn 0)
NOTE Because the debug apple routing command can generate a substantial number of messages,
you should use it only when router CPU utilization is less than 50%.
The following are the fields in the first line of the sample debug apple routing output:
Field Description
AT: Indicates that this is AppleTalk debugging output.
src = Ethernet0:4160.41 Indicates the source router interface and network
address for the RTMP update packet.
dst = 4160-4160 Indicates the destination network address for the
RTMP update packet.
size = 19 Shows the size of this RTMP packet (in bytes).
2 rtes Indicates that this RTMP update packet includes
information on two routes.
RTMP pkt sent Indicates that this type of message describes an
RTMP update packet that the router has sent
(rather than one that it has received).
The following two messages indicate that the ager has started and finished the aging process for
the routing table and that this table contains 97 entries:
AT: Route ager starting (97 routes)
AT: Route ager finished (97 routes)
The following are the fields in the following line of debug apple routing output:
400 Chapter 10: Diagnosing and Correcting Catalyst Problems
Figure 10-1 Catalyst switches are differentiated by slots, modularity, forwarding capabilities, and more.
Product Slots PS Mpps Modular Sups LS1010

Fixed PS (max.) interfaces RSM
1 N
2900 2 4 N 1
Y N
2 N
5002 2 4 Y 1
Y N
2 N
5000 5 15 Y 1
N Y
2 Y
5500/5505 13 36 Y 2
N Y
Legend
PS = Power supply
Mpps = Millions of packets per second forwarded across all switching modules
Sups = Number of supervisor modules
LS1010 = Integrated LightStream ATM; RSM = Integrated Route Switch Module (4500)
At the lower end, the Catalyst 2900 switch offers users a fixed-configuration Fast Ethernet
switch for 10/100BaseTX (Catalyst 2901) or 100BaseFX (Catalyst 2902).
At the high end, the Catalyst 5500 is a 13-slot modular switching platform that integrates
existing Catalyst 5000 and LightStream 1010 interface modules. The Catalyst 5500 allows the
enterprise to scale its LAN with Fast Ethernet, FDDI, or ATM switching and, in the future,
Gigabit switching.
This book focuses on the midlevels of the Catalyst switch series: the Catalyst 5002 and the
Catalyst 5000.
The Catalyst 5002 switch is a Catalyst 5000 in a compact chassis. The Catalyst 5002 is a
modular switch with two slots and is intended for the network periphery. The Catalyst 5002 can
be configured with any current or future Catalyst 5000 family modules.
The Catalyst 5000 modular switch is a larger chassis than the 5002 and offers five slots for
modules. The Catalyst 5000 is intended for board closet and data center applications.
The Catalyst 5000 series provides virtual LAN networking and optional multilayer switching
with Cisco IOS software functionality.
Catalyst 5000 Internal Architecture 403
Figure 10-3 The Catalyst 5000/5002 internal architecture supports buffering on the backbone module.
Backbone
CPU Module
Buffer BIGA
ASIC
Filter and SAGE

Forwarding Tables LCP
ASIC
EARL
1.2 Gbps Control Bus
Bus
Arbiter Mgt Bus
RMON
Statistics
LCP
Network Mgmt
NMP/MCP
192-KB SAINT 192-KB SAINT
Buffer ASIC Buffer ASIC
Port 8 Port 25 Ethernet

Module
Input/output buffering is done on the backbone module and on the 192-KB buffers associated
with each port. This architecture supports multiple levels of data prioritization, with each
interface separately user-configurable as high or low priority. The 192-KB buffer for each port
provides 160 KB for outbound traffic and 24 KB for inbound traffic. The ports are controlled
by ASICs that have fast table add and lookup algorithms. Each Ethernet port interface
comprises a custom ASIC, called the SAINT (Synergy Advanced Interface and Network
Termination), with an integrated 10/100 Ethernet Media Access Control (MAC) controller and
Direct Memory Access (DMA) engine that connects the 192-KB buffer to the data bus.
Other media ports make use of a second custom ASIC, called the SAGE (Synergy Advanced
Gate-Array Engine), an ASIC without an integrated Ethernet MAC.
Catalyst 5000 memory contains a central address table in DRAM that contains the filter and
forwarding tables. An ASIC called Enhanced Address Recognition Logic (EARL) works with
bus arbitration to govern access to the data switching bus and control the destination of packet
transfers.
The Network Management Processor/Master Control Processor (NMP/MCP) is the

aggregation point for management information about the switch and its role in the network.
This information includes data from Simple Network Management Protocol (SNMP) and
remote monitoring (RMON).
The NMP also contains information about spanning-tree configuration details, Cisco Discovery
Protocol (CDP) neighbors, and the VLAN Trunking Protocol (VTP). (These protocols are
covered later in this chapter.) The NMP uses the management bus that operates at 761 kbps.
The BIGA (built-in gate array) connects the NMP to the 1.2-Gbps bus. The LCP is the
line-module communication processor.
Self-diagnostics at startup occur during the power-up self-test, which checks the switch internal
hardware components.
Power-up self-test output should resemble that shown in Figure 10-4.
Figure 10-4 The power-up self-test checks LEDs, memory, and address recognition logic.
ROM Power Up Diagnostics of January 27, 1999
Init NVRAM Log
LED Test ................... done
ROM Checksum ............... passed
Dual Port RAM r/w Test ..... passed
ID PROM .................... passed
System DRAM Size (Mb) ....... 16
DRAM Data Bus Test ......... passed
DRAM Address Test .......... passed
DRAM Byte/Word Access Test .. passed
EARL Test .................. passed
BOOTROM, Dated January 27, 1999 11:46:24
NOTE While the Catalyst switch is running, you can get details about this (and other) information by
using the Catalyst commands show system and show test. These and other show commands are
covered in more detail later in this chapter.
Catalyst Switching Technology

First, it’s important to learn the difference between bridging and switching.
A bridge is a device that connects and passes packets between two network segments that use
the same communications protocol. Bridges operate at the data link layer (Layer 2) of the OSI
reference model. In general, a bridge filters, forwards, or floods an incoming frame based on
the MAC address of that frame.
Catalyst Switching Technology 405
A bridge uses a software-based process to set up and maintain a filtering database consisting of
static entries. Each static entry equates a MAC destination address with a port that can receive
frames with this MAC destination address and a set of ports on which the frames can be
transmitted.
To avoid loops, a bridge uses the spanning-tree algorithm with one spanning-tree instance per
physical port and a maximum of eight spanning trees on a microsegmented bridge, which
usually has up to 16 ports. The bridge usually addresses a LAN overload condition by
separating the LAN’s traffic into segments.
Although a switch essentially performs a bridging function (the Catalyst 5000 series uses
IEEE 802.1D Spanning-Tree Protocol), it is primarily hardware based, with ASICs and a
high-capacity switching bus. Switches are much faster than bridges.
There can be many spanning-tree instances per port, especially if the port acts as a trunk that
supports multiple VLANs. There should be one spanning tree for every VLAN, with up to 1,024
VLANs allowed on a Catalyst 5000.
Ports connect directly to end users and offer switched rather than shared Ethernet to provide
greater access to bandwidth. Switches also connect to other switches and use advanced
protocols to speed up configuration and convergence information flow across the network.
A Catalyst 5000 can have 100 or more ports, depending on the line cards used.
Despite greater functionality, speed, and capacity, switch problems are easier to debug than the
legacy bridges. Bridges were often meant to operate without much management, and problem
causes (not the problems themselves) were often invisible. By contrast, switch debugging can
use a full set of troubleshooting tools, including those covered in this chapter.
Table 10-1 provides a comparison between bridging and switching.
Table 10-1 Legacy bridging versus LAN switching.
Legacy Bridging LAN Switching
Software based (slow) Primarily hardware based (faster)
One to eight spanning trees on a segmented Supports as many spanning trees as there are
bridge VLANs
Connects overloaded LAN segments Connects directly to other switches or to end
users
Usually up to 16 ports 100 or more ports per switch
Spanning-Tree Review
The Spanning-Tree Protocol provides bridged networks with multiple link paths that ensure
connectivity between all bridged nodes and loop-free paths throughout the network:
• When loops occur, packets travel from the source toward the destination (if known) and
then loop around again and again.
• When the segment that contains the destination address is not yet learned, packets are sent
as broadcasts, or multicasts. These packets can travel around the loop in both directions
from a bridge again and again.
• When there are several bridges in the network, the bridges combine ports for many
possible paths with multiple loops. Packets can be replicated out all the ports of each
successive bridge’s ports and exponentially loop around again and again.
Figure 10-5, for example, shows a network that contains two loops. Without a network-layer
function, a bridged network lacks a Time To Live (TTL) mechanism. Without this decremental
scheme at Layer 2 to eventually put an end to looping packets, even temporary transition loops
are dangerous. Therefore, the main advantage of the Spanning-Tree Protocol is that it avoids
loops.
Figure 10-5 Network loops are often created when redundant paths are established.
Server
10.0.0.1
10.0.0.2 Loop 10.0.0.3
10.0.0.4 10.0.0.5 Loop 10.0.0.6
Workstation
Spanning-Tree Review 407
A broadcast storm of looping packets can quickly clog the network with unneeded traffic and
prevent needed packet switching. With failures in the spanning-tree mechanisms, you might see
a steady high switch load on the supervisor engine module LED, while the throughput you or
your users experience is extremely sluggish or stalled.
To avoid loops, bridges and switches build a spanning tree that contains loop detection and
avoidance mechanisms. These bridges and switches are designated points of continuity and
continuously multicast membership (peer) identity to each other. There are two bridge types:
• A root bridge, which is a unique point of reference for the spanning tree that can be elected
by tree members. A root bridge calculates the shortest-path distance from these other
members to itself. This process is performed by adding up the cost to each other member
and organizing the possible paths in order of lowest to highest cost. The root bridge
becomes the timer master for slaved members of the tree, and validates topology changes
on the tree.
• One or several designated bridges that elect the root bridge and then determine their
hierarchical-cost path(s) to the root based on a “cost” parameter. Cost is a function of the
bandwidth of each path, can be changed by a switch port, and is a summation value that
represents accumulated path costs to the root bridge.
The ports contained in these bridges can be in one of several states and can make the transition
through the states when they change from nonforwarding to forwarding. These port states are
• Blocking—The port is in a nonforwarding state because of a loop detection. These are
nondesignated ports.
• Listening—The port is in a preforwarding state, able to check for bridge protocol data
units (BPDUs) about the spanning tree.
• Learning—The port is in a preforwarding state, able to determine the topology details that
indicate a path to the root bridge.
• Forwarding—Allows for output packets, which are designated ports that receive and send
packets.
• Disabled—The port is not enabled for Spanning-Tree Protocol or has been
administratively disabled.
• Cisco special port-fast and uplink-fast modes—The port has no timing clock constraints
and is moved to a forwarding state more rapidly than a normal Spanning-Tree Protocol
transition. Port-fast is for LAN traffic such as Novell IPX; uplink-fast is for dialup traffic.
These faster modes are useful for user traffic that cannot tolerate the typical Spanning-Tree
Protocol transition, which could take 20 seconds from blocking to listening, plus 15 seconds
from listening to learning, plus 15 seconds from learning to forwarding.
Figure 10-6 shows a network that has had its loops resolved by the Spanning-Tree Protocol. By
blocking the redundant ports, two loops have been removed.
Figure 10-6 Ports are blocked to resolve loops.
B Blocked Port F Forwarding Port
Designated Port Root Port

F F
Root Bridge
F B
Designated Port
Root Port
F F
Designated
Bridge
F Designated Port B
TIP Each Catalyst 5000 VLAN has a unique bridge ID. A physical port that is a trunk may be part
of more than one spanning tree. Loops on one spanning tree may affect other spanning trees if
they share a topology.
To distribute the load on parallel VLAN Inter-Switch Links (ISLs), you can change the port
priority per VLAN. To increase the chances of being a root port, lower the bridge priority to
make the bridge ID numerically lower.
When you set up fast-mode devices, the setup processes bypass part of the spanning-tree
learning transitions. Make sure you do not introduce spanning-tree loops.
VLAN Frame Tagging with ISL

ISL is used over point-to-point connections to interconnect two VLAN-capable Cisco products,
such as the Catalyst 5000 and 3000 series switches, and the Cisco 4000 and 7000 series routers.
ISL is generally used on Fast Ethernet using full- or half-duplex 100-Mbps links; ISL can also
run on 10-Mbps links, but this is not as common. The ISL specification also allows for the ISL
frame to contain Token Ring frames, as well.
The 802.10 ISL protocol is a packet-tagging protocol that contains a standard Ethernet frame
and the VLAN information associated with that frame. Think of it as a virtual topology going
across a physical topology.
The ISL has three primary fields: the header, the original packet, and the frame check sequence
(FCS) at the end. The header is further divided into fields as shown in Figure 10-7.
Figure 10-7 The ISL frame encapsulation is added and removed by the VLAN switches at the start and end of the ISL
path.
Switching Module
Intraswitch:
Outbound non-trunk-port ASIC
removes fields
Ethernet
Switching Module
Interswitch:
Intraswitch: Inbound port ASIC
Inbound port ASIC adds three fields adds ISL header
1.2
VLAN Gbps
Port Ethernet FCS
ID
Interswitch:
Inbound port ASIC
removes ISL header
Switch
Bus
As a frame enters the switching module, it is stored in the port’s frame buffer. In Figure 10-7,
the SAINT ASICs on each port perform an encapsulation or de-encapsulation on the frame.
If a Catalyst port is on a switch trunk, the port will handle interswitch traffic between switches.
An ASIC on the switching module that receives frames from the trunk de-encapsulates ISL
frames.
The ASIC removes the 30 bytes of information used by ISL: 26 bytes of header information and
a 4-byte FCS. This FCS is checked at the port receiving the frame from the trunk.
On the outgoing switching module, the ASIC adds ISL encapsulation before the module sends
the frame to the trunk.
Inter-Switch Trunk Links carry the packets for one or more VLANs. Network administrators
need a VLAN mapping function to maintain VLAN configuration consistency throughout the
switch fabric of the network.
In the switch fabric shown in Figure 10-9, VLAN information about VLAN 1 must traverse
several ISL trunks using Fast Ethernet and FDDI.
Figure 10-9 VTP is used to propagate VLAN information more efficiently.
Switch Fabric
VLAN 1
ISL FDDI
802.10
ISL
ISL VLAN 1
VLAN 2
VLAN 3
VLAN 3
VLAN 1 VLAN 2 VLAN 3 VLAN 2
VTP
VTP is a Layer 2 multicast messaging protocol that allows VLAN classification done once at
the ingress to the trunk to traverse the entire management domain, rather than requiring VLAN
classifications on a hop-by-hop basis. This tremendously reduces latency, allowing
intermediate switches to work at nearly wire speed.
VLANs across multiple LAN types are mapped by VTP to provide unique names and internal
index associations. Trunk ports can forward all VLAN traffic within the domain.
VTP manages the addition, deletion, and renaming of VLANs at the system level without
requiring manual intervention at each switch, which greatly reduces the device-level
administration required and the potential for inconsistent names.
VTP keeps track of VLAN changes and multicasts periodic advertisements to communicate
with other switches in the network. VTP provides globally consistent VLAN configuration
information for the VTP domain.
A VTP domain comprises a group of one or more interconnected devices that share the same
VTP domain name. A switch may be configured to be in only one VTP domain.
When you configure the VTP domain name, make sure the name is consistent throughout the
network management domain. Use the command set vtp domain admin-1.
In Figure 10-10, VTP advertisements occur on a reserved VLAN trunk port across the ISL.
Figure 10-10 The VTP server and client exchange VTP advertisements.
VTP Advertisements
VTP
VTP
Server VLAN 1 VLAN 2 VLAN 3
Client
VLAN 1 VLAN 1
ISL Trunk Link
VLAN 2
VLAN 3
VLAN 2
VLAN 3
Switch Fabric
A VTP-capable switch can be configured in three modes: as a VTP server, as a VTP client, or
in VTP transparent mode.
Servers and clients maintain the full list of all VLANs within the VTP domain (which defines
the boundary of the defined VLANs). They also transmit and receive advertisements of known
VLAN information.
A VTP server maintains its VLAN information in a nonvolatile store or TFTP device. You can
modify the global VLAN information in a VTP server through the Catalyst command-line
interface (CLI) using the VTP Management Information Base (MIB).
When a client or server detects the addition of a VLAN, it prepares to receive traffic with the
newly defined VLAN ID on its trunk ports.
Another mode of operation, called transparent mode, is for switches that do not wish to
participate in the automatic trunk configuration of VTP-created VLANs. However, transparent
mode switches continue to forward VTP advertisements that they receive on one trunk port to
other trunk ports.
VTP advertisements (called adverts) take place on a reserved VLAN on a trunk port. The
VLAN number for VPT is set up automatically and varies depending on the media type of the
trunk. The reserved VLAN for VTP cannot be deleted or changed.
Clients check advertisements for a configuration revision number. This number increments for
successive VLAN change updates. When a client is presented with several advertisements, the
advertisement with the highest revision number prevails as the source of VLAN information.
The last updater is a record of the IP address of the last switch (a VTP client or server) that sent
a VLAN advertisement.
Troubleshooting VTP
There are some basic rules for troubleshooting VTP:
• Configure switches for transparent mode if they do not need to use VTP. If the proper
operation of the switch can occur with a hard-coded setup of VLANs and has no
productive use for advertisements about VLAN additions, deletions, and changes,
transparent mode offers the simplest approach and easiest troubleshooting.
• A VLAN set up for a transparent-mode switch has local significance only. However,
switches in transparent mode continue to relay VTP adverts from other switches
configured as VTP servers or clients.
• If you will be using VTP clients and servers, the easiest topology to troubleshoot is one in
which you have centralized VTP servers with the spanning-tree root bridge.
• The VTP server is the preferred mode for Catalyst switches. You need at least one VTP
server in the VTP management domain.
• Do not configure VTP servers offline. When you configure a VTP server offline and then
connect it to the network, you run the risk of an inconsistency when the server presents a
VTP advert revision that does not accurately reflect the domain. Other switches that come
online may use the inaccurate VTP information, and VLANs on the network may
disappear.
• Configure other wiring closet switches as VTP clients, which can reduce the number of
switches to consider as you troubleshoot VTP configuration problems because the client
cannot create global VLANs.
• The VPT client role is best suited for devices that do not have sufficient nonvolatile
memory to store the information about the global VLANs that a server learns through VTP
adverts.
• Clients do not preserve the information about global VLANs when they restart, but instead
depend on an update of VLAN information from VPT adverts that they get from servers.
• VTP does not work if there is no trunk port or no VLAN1. When troubleshooting, make
sure that these essential requirements for VTP have been configured properly.
• For CiscoWorks for Switched Internetworks (CWSI) network management, VTP is
required. If you will be using a network management application such as VlanDirector,
there must be a VTP server.
To troubleshoot ISL, the first facts to check are that the interswitch physical characteristics—
port speed, port duplex, and for optical links, fiber type—match.
In the core of your network make sure you hard-code trunks to be on. If you find that trunks are
not on, you can correct the problem with the following command:
set trunk [slot/port] on
Make sure that the switch’s VTP domain name is consistent for the ISL devices. To check VTP
domain name, use the following command:
show vtp domain
Make sure your VLANs match on both sides of a trunk. To check that VLANs match, use one
of the following commands on both switches on a link:
show trunk
or
show vlan
If you are unable to identify the cause of the ISL problem, you may need to apply additional
tools to your troubleshooting efforts. For instance, use a Fast Ethernet analyzer (for example,
SwitchProbe) if it is necessary to see frames decoded.
Catalyst 5000 Troubleshooting Tools

Catalyst 5000 troubleshooting begins with the supervisor engine module. The Catalyst 5000
and 5002 switches require a supervisor engine module in the top slot of the chassis. The other
slots are for interface modules (for example, the remaining four slots of the Catalyst 5000
switch).
NOTE Three supervisor engines are available (I, II, and III). Supervisor Engines I and II support fixed
Fast Ethernet ports (either 100BaseTx or 100BaseFx). Supervisor Engine III is available with
modular or fixed uplink ports and includes advanced functionality such as EARL. Refer to
www.cisco.com for more configuration descriptions.
Remote (out-of-band) management through SNMP sets or Telnet (client)

connection occurs on any switched or ATM interface.
Local (in-band) management occurs on the Console port (female DCE EIA/TIA-
232) for console terminal or modem connection. The Catalyst 5000 and 5002
switch supervisor engine module includes the following:
— A 25-MHz 68EC040 network management processor with 8-MB DRAM,
4-MB Flash EPROM for downloadable microcode and software upgrades, and
256-KB NVRAM; the supervisor engine is connected to a high-performance,
low-latency, 1.2-Gbps switching backplane.
— Two Fast Ethernet interfaces (full- or half-duplex), which can be ISL trunks.
Users can choose dual 100BaseTX (Category 5 UTP), dual multimode
100BaseFX, or dual single-mode 100BaseFX uplinks. Further, with Cisco’s
Fast EtherChannel technology, the two ports can be configured as a single,
400-Mbps, full-duplex fault-tolerant connection.
If CWSI autodiscovery terminates, check the supervisor engine module LEDs
System Status light and Power Supplies indicators. With CWSI Release 1.2, a
redundant power supply not turned on may terminate the autodiscovery process.
The supervisor engine module LEDs that show switch load are important
indicators of normal and abnormal switch backplane activity. If the load
indicators indicate a high load (80% to 100% steady), chances are good that a
broadcast storm may be in progress. Use this LED indicator to check into
possible causes for this condition.
• Line card modules
Check the power-up LED sequence on the line card switching modules. LEDs
flash during startup and turn green when a successful initialization is completed.
A red LED indicates a failure. An orange LED can also indicate a problem on
some modules.
If the switch is running, check for normal LED status in all the installed modules.
A line card that is not fully inserted can appear to be a hardware failure. Check
the position of the extractor levers. A red status LED is an indication that the
module is not in the slot.
The autosensing for a switching module port indicates the speed in operation on
the port. If the 100-Mbps LED is off, that port is either not in use or is being used
at 10 Mbps. Is this what you expect for the port? If not, troubleshoot further:
— Check whether a 10/100-Mbps connection is connected at 10 Mbps instead of
100 Mbps.
— Severe bends in a Category 5 cable can cause a 10/100-Mbps interface to run at
10 Mbps.
The following are some questions to ask related to end-user device connections:
• Is the network adapter card/interface port at the user end functioning properly?
• Is the device connected to the correct port? Is the port active?
One way to test installed cabling is to replace the entire cable run with an external cable. If you
have a known good segment of Category 5 cable, run the cable between the two devices to test
connectivity. This test will eliminate any uncertainties about plant cables or punchdown
connections.
The following test equipment can be used to troubleshoot a wide variety of network and
network cabling problems:
• TDR—Measure cable length and impedance by sending a signal down the cable and
examining the reflection.
• Protocol analyzers—Capture and display protocol information by tapping into the
network and decoding protocol information into a readable format.
• Cable testers—Scanners for STP, UTP, or fiber.
• Network monitors—Continuously monitor network traffic through SNMP agents.
Catalyst 5000 Switch Diagnostic Tools: ping

One of the most useful and important troubleshooting aids is the ping command, which
provides a simple echo test. If you ping a destination device, do you get a response? If ping
does not respond, ask the following questions:
• Is there a cable problem?
• Can the testing terminal (or workstation) communicate with any other devices?
• Can any other devices communicate with the switch?
• Are there port errors on the switch? (Check with the show port command.)
• Is there normal port traffic? (Check with the show mac command.)
• Are the port and interface sc0 in the same VLAN? (Check with the show port and show
interface commands.)
CDP
CDP is a media- and protocol-independent device discovery protocol that runs on all Cisco
manufactured equipment (routers, bridges, communication servers, and switches).
Cisco devices discover each other in a protocol-/media-independent way so that a network
administrator or network management applications can dynamically discover Cisco devices
that are neighbors of already-known devices.
Catalyst Commands 425
If you use SPAN on a trunk port, keep in mind that a trunk port must be designated as either a
source port or as a destination port. If a destination port is a trunk port, all outgoing packets
through SPAN carry an ISL header.
The SPAN command syntax shown in Figure 10-15 indicates the arguments you need to specify
what you want to monitor, and where you want the SPAN port to be.
You can span a selected port or you can span a VLAN, as long as the source and destination
ports are the same VLAN type.
Following is an example of the command to use for setting up SPAN to enable monitoring of
VLAN 1 transmit/receive traffic by port 3/12. If SPAN is enabled to monitor VLAN traffic, you
cannot select a trunk port as a monitored port:
Console> (enable) set span 1 3/12 both
Console> (enable) show span
Source Destination Direction Status
------ ------------ -------------- --------
VLAN 1 Port 3/10 transmit/receive enabled
Following is a second example of a command to use for setting up SPAN. The example enables
monitoring of port 2/8 transmit/receive traffic by port 3/12:
Console> (enable) set span 2/8 3/12 both
Console> (enable) show span
Source Destination Direction Status
------ ------------ -------------- --------
Port 2/8 Port 3/12 transmit/receive enabled
NOTE Automated procedures in TrafficDirector Version 4.1.3 and later simplify the setup, data
capture, and analysis of SPAN traffic in Catalyst switches.
After you designate a port as a port that you want SPAN to monitor, the ASIC for that port tags
packets for SPAN before they reach the switching bus and both the destination port and the
mirrored SPAN port.
At the SPAN port, the mirrored packet capture is available for interpretation by a CWSI
application or by some other protocol analyzer with a suitable decode capability.
Catalyst Commands
The four most useful commands for Catalyst switching are
• set—Establish switch parameters.
• clear set—Erase switch parameters or overwrite switch parameters.
• show—Check or verify parameters.

• syslog—Generate log messages.
The show commands are the focus of this section.
NOTE A useful technique to help you identify the argument usages for a given Catalyst command is
the enabled-mode help command, which uses the command followed by the argument,
followed by the word help (alternatively you can use a ?). The example that follows uses this
technique to see the arguments for the set span command group:
Console> (enable) set span help
Usage: set span enable
set span disable
set span <src_mod/src_port> <dest_mod/dest_port> [rx tx both]
set span <src_vlan> <dest_mod/dest_port> [rx tx both]
The show commands provide essential information about the Catalyst system settings,
interfaces, and counters.
show Commands for System Settings

You use the following show commands for system settings:
• show system
• show test
• show interface
• show log
• show mac
• show module
• show port
These commands are described in more detail in the following sections.
show system
You use the show system command to display Catalyst system information, including the
following:
• Status that corresponds to system LED status: power supplies (ok, fan failed, faulty, or
none), fan (ok, faulty, or other), temperature alarm (off or on), and system status (ok or
faulty).
show log
You use the show log command to display the error log for the system or a specific module.
Information includes
• The active NPM log, including reset count, resets, bootup history, and failure counts
• NVRAM logs
• Module logs, including any resets that have occurred
show mac
You use the show mac command to display MAC information, including
• Module and port identifier and the frame traffic for the port
• The total transmit frames aborted due to excessive deferral or when MTU size was
exceeded
• The number of incoming frames discarded because the frame did not need to be switched
• The number of content-addressable memory entries discarded due to page full in EARL
• The number of incoming or outgoing frames lost before being forwarded (due to
insufficient buffer space)
• Token Ring and FDDI values
• Date and time of the last clear counters command
show module
You use the show module command to display module status and information. If you do not
specify a module number, the command outputs information for all modules. This information
includes
• The module number and name of the module, the number of ports on the module, its
module type (such as 10BaseT Ethernet), model number, and serial number
• The status of the module (possible status strings are ok, disable, faulty, other, standby, or
error)
• Any MAC address or MAC address range for the module
• The module’s hardware version, firmware version, and software version
• Token Ring and FDDI values
Sometimes the show module command indicates that the status LED of an Ethernet module is
green, even if some module ports fail the PMD loopback test during power up; the status LED
of an Ethernet module is orange or red only when all the module ports fail the PMD loopback
test.
To correct this error, use the show test command to view PMD loopback test results for a
module and then reset the module by using the reset mod_num command; if the failure persists,
replace the module.
show port
You use the show port command to display port status and counters. You have the option of
specifying a specific module and port number. Information output from this command includes
• The module and port number, and any name (if configured) of the port
• The status of the port (connected, not connected, connecting, standby, faulty, inactive,
shutdown, disabled, or monitor)
• Any VLAN(s) to which the port belongs
• Any level setting for the port (normal or high)
• Any duplex setting for the port (auto, full, half, a-half, or a-full), and port speed setting
(auto, 10, 100, 155, a-10, or a-100)
• The port type (10BaseT, 10BaseFL MM, 100BaseTX, 100BaseT4, 100BaseFX MM,
100BaseFX SM, 10/100BaseTX, FDDI, CDDI, MLT3 CDDI, SDDI, SMF-FDDI, PreStd
CDDI, SCF FDDI, OC3 MMF ATM, OC3 SMF ATM, OC3 UTP ATM, or Route Switch)
• Security enabled or disabled (if enabled, the secure MAC address for the security enabled
port) and whether the port was shut down because of security
• The source MAC address of the last packet received by the port
• Whether the port trap is enabled or disabled
• Broadcast information, including the broadcast threshold configured for the port and the
number of broadcast/multicast packets dropped because the broadcast limit for the port
was exceeded
• Port errors, including the number of frames with alignment errors (frames that do not end
with an even number of octets and have a bad CRC1) received on the port, the number of
FCS errors that occurred on the port, the number of transmit or receive errors that occurred
on the port (indicating that the internal transmit or receive buffer is full), the number of
frames received that are less than 64 octets long (but are otherwise well formed)
• Collision information, including how many times one collision occurred before the port
successfully transmitted a frame to the media, how many times multiple collisions
occurred before the port successfully transmitted a frame to the media, the number of late
collisions (collisions outside the collision domain), and the number of excessive collisions
that occurred on the port (indicating that a frame encountered 16 collisions and was
discarded)
• Any runts (frames that are smaller than the minimum IEEE 802.3 frame size) or giants
(frames that exceed the maximum IEEE 802.3 frame size) received on the port
• The connection entity status and connection state of the port, as follows:
— Disabled—The port has no line module, or it has been disabled by the user.
— Connecting—The port is attempting to connect or is disabled.
— Standby—The connection is withheld or is the inactive port of a dual homing
concentrator.
— Active—The port has made connection.
— Other—The concentrator is unable to determine the connection state.
• Link error rate (LER) conditions, including an estimated LER, the LER-alarm threshold,
and LER-cutoff value (the LER at which a link connection is flagged as faulty)
• Link error monitor (LEM) conditions, including the number of LEM errors received on
the port and the number of times a connection was rejected because of excessive LEM
errors
• The last time the port counters were cleared
show Commands for Switch Configuration

You use the following show commands to provide information about the Catalyst configuration,
network entities such as VLANs, and neighbors:
• show config
• show span
• show trunk
• show flash
• show spantree
• show vtp domain
• show cdp neighbor
These commands are described in more detail in the following sections.
show config
You use the show config command to display the current system configuration. This command
is comparable to the Cisco IOS show running config command. The command output includes
• Catalyst password, system, and contact information
• SNMP settings, TCP/IP addressing, and DNS server details
• Any TACACS+ configurations

• Bridging, VTP, Spanning-Tree Protocol, and syslog settings
• Information about switch modules and the ports
show span
You use the show span command to display information about the Catalyst 5000 series
switched port analyzer function setting. Information includes
• Whether SPAN is enabled or disabled, and if SPAN is enabled, the source port or VLAN
for SPAN to monitor and the destination port to direct mirrored SPAN information
• Whether transmit, receive, or transmit/receive information is monitored
show trunk
You use the show trunk command to display trunking information for the switch. You have the
option of specifying a module and port number. Information output from this command
includes
• The module and port number(s), administrative status of the port (on, off, auto, or
desirable), and port status (trunking or not-trunking)
• VLAN information, including the range of VLANs allowed to go on the trunk (default is
1 to 1000), the VLANs allowed and active in the management domain within the allowed
range, if the VLANS are in spanning-tree forwarding state and not pruned, the range of
VLANs that actually go on the trunk with Spanning-Tree Protocol forwarding state
Figure 10-16 shows an example of using the show trunk command for troubleshooting
information and action planning.
Figure 10-16 The show trunk command displays active VLANs on this trunk.
show trunk 1/1
Port Mode Status
1/1 auto not-trunking
Port Vlans allowed
1/1 1-2,10-15,200,254
Port Vlans active
1/1 1
For the port 1/1 shown as nontrunking, try setting the trunk mode to on with the following
command:
set trunk 1/1 on
All the VLANs for the trunk must show up as an entry for the show trunk command in order
for the VLAN to be active. All working VLANs or VLANs added by VTP will show up as
entries.
Make sure that at least one VLAN is configured for this trunk. To configure a VLAN for the
trunk, use the following command:
set trunk 1/1 [vlans]
One important troubleshooting check is to make sure that both sides of the link agree on the
VLANs that can use the trunk. If you need to remove a VAN from the trunk, use the following
command:
clear trunk 1/1 [vlans]
NOTE When you use the commands shown, replace the port number 1/1 with the correct port number
for your switch.
NOTE By default, the switch sends the output from debug commands and system error messages to
the console terminal. Use the show log command to display the error log for the system or a
specific module. These messages can also be redirected to other destinations.
Syslog error and event logging generate SNMP log messages that show configuration
parameters and protocol activity. When enabled, system logging messages are typically sent to
a UNIX host or other network management server that acts as a syslog server.
You can set up syslog as part of your preparation for switch management and troubleshooting
so that the syslogd daemon will capture and save log messages that you can analyze later.
show flash
You use the show flash command to list Flash information, including file code names, version
numbers, and sizes.
show spantree [vlan]

You use the show spantree [vlan] command to display spanning-tree information for a VLAN.
You have the option of specifying the number of the VLAN (the default is VLAN1) and the
number of the module and port on the module to narrow the display. Information from this
command includes the following:
• The VLAN for which spanning-tree information is shown; whether Spanning-Tree
Protocol is enabled or disabled, and if enabled, the MAC address of the designated
spanning-tree root bridge; the priority of the designated root bridge; the total path cost to
reach the root; the port through which the root bridge can be reached (shown only on
nonroot bridges)
• BPDU information, including the amount of time a BPDU packet should be considered
valid, how often the root-bridge sends BPDUs, and how much time the port should spend
in listening or learning mode
• Bridge information, including the bridge MAC address, priority, maximum age, Hello
time, and forward delay
• The port number and VLAN to which the port belongs
• The spanning-tree port state (disabled, inactive, not-connected, blocking, listening,
learning, forwarding, bridging)
• The cost and priority associated with the port
• Whether the port is configured to use the fast-start feature
show spantree statistics

You use the show spantree statistics command to decode and interpret the Spanning-Tree
Protocol BPDU communications, as shown in Figure 10-17.
Figure 10-17 You can view BPDU communications with show spantree statistics.
show spantree statistics
Designated Root 00-60-47-8f-9a-00

Bridge ID MAC ADDR 00-60-83-4e-d6-00

Port Vlan Port-State Cost Priority Fast-Start

-------- ---- ------------- ----- -------- ----------
You can either specify a VLAN as in Figure 10-17, or you can get output about all the VLANs
known to the switch. Spanning tree is enabled by default.
Problem Isolation in Catalyst Networks 437
show cdp neighbors

You use the show cdp neighbors command to display CDP information about all Cisco
products connected to the switch. Information includes neighbor device ID and addressing,
capabilities, software version, hardware platform, module and port identifier on the neighbor
device, and devices on this side of the data link.
Problem Isolation in Catalyst Networks

Typically, a general approach for troubleshooting problems like the approach shown in
Figure 10-19 can systematically isolate a problem with a Catalyst switch network.
Figure 10-19 You can use this Catalyst problem isolation flowchart to streamline troubleshooting procedures.
LEDs
Y Switch Y Physical link Y
(or network manage-
configuration connection
ment equivalents)
okay? okay?
okay?
N N N
Fix any problems Fix any problems Check with CDP, fix
with switch hardware with config statements any cabling problems
L2
VLAN Y path between
configuration switches
okay? okay?
N N
Fix any VLAN, spanning-tree, Fix any switch trunking or

or intermediate router ISL configuration
problems problems
You proceed in the following order:

1 Check the physical indications of LEDs or their equivalents.
2 Work outward from a single switch configuration.
3 Check the Layer 1 link to another switch.
4 Check the Layer 2 link to the other switch.
5 Troubleshoot the VLAN that contains several switches.

444 Chapter 11: Troubleshooting VLANs on Routers and Switches
Routers contribute to switched architectures configured as VLANs because they provide the
communication between logically defined workgroups (that is, VLANs). Remember that a
VLAN is a virtual network. The traditional role of a router is to connect networks together.
Therefore, we use routers to connect VLANs together, enabling some traffic to cross VLAN
boundaries.
Routers also provide VLAN access to shared resources such as servers and hosts, and they
connect to other parts of the network that are either logically segmented with the more
traditional subnet approach or require access to remote sites across wide-area links.
Cisco IOS VLAN services provide a powerful combination of multiprotocol routed and
switched VLAN opportunities to improve performance.
Routers help with integration across Cisco’s switching product family/partner products, and
they bring scalability and flexibility to VLAN networks. In this chapter you will learn how
VLANs are implemented on Cisco routers and what precautions you should take when
configuring VLANs that work on routers together with switches.
VLANs on Routed and Switched Networks

Figure 11-1 shows a network that supports VLANs at the router and switches. The router
connects the Group 1 and Group 2 VLANs.
Figure 11-1 Multiple VLANs use packet tagging and Inter-Switch Link (ISL) for router and switch.
Inter- VLAN Routing

Router connects
Group 1 VLAN Switching Group 2 VLAN Switching among VLANs
ISL ISL
Catalyst
ISL switches
ISL
support
ISL ISL separate
VLANs
ISL
ISL
21101.eps
For a typical switched VLAN, traffic is only switched between LAN interfaces that belong to
the same VLAN. Typically, the criterion for VLAN membership is departmental function. Users
could, however, be grouped into VLANs based on a common protocol or subnet address. Your
VLAN memberships should depend on a solid understanding of your data flow and resource
usage.
VLAN Switching, Translation, and Routing 445
Cisco offers ISL on Cisco 4000 and 7000 series routers and on Catalyst 5000 LAN series
switches.
The ISL trunk protocol identifies traffic as belonging to a particular VLAN by using frame
tagging as packets are switched onto the shared backbone network.
Receiving switches use ISL to make intelligent forwarding decisions and switch the packets to
only those interfaces that are members of the same VLAN.
When combining LANs into a VLAN, a Spanning-Tree Protocol algorithm is used to eliminate
the possibility of loops and to determine the best path through the network. Each VLAN in the
switch has a unique bridge ID, and the Spanning-Tree Protocol algorithm runs separately for
each VLAN. Each VLAN operates autonomously; its data flow need not be interrupted by
physical changes or spanning-tree recomputations that go on elsewhere in the network
topology.
Also, supporting a separate spanning tree for each VLAN enables optimal path determination
for each VLAN and extends the diameter of the network. A physical port on a router or switch
may be part of more than one spanning tree if it is a trunk. A trunk is a point-to-point link that
transmits and receives traffic between switches or between switches and routers.
For routing or switching of inter-VLAN traffic, the router aggregates inter-VLAN routing for
multiple VLAN switches. Traffic between VLANs can be switched autonomously on-card or
between cards rather than via the central Route Switch Processor (RSP) on a Cisco 7000 series
router.
Routers offer additional functionality such as access lists. Access lists enable a network
administrator to implement the permit and deny policy of the organization.
VLAN Switching, Translation, and Routing

A Cisco router can bridge ISL and IEEE 802.10 VLANs (that is, where the VLAN
encapsulating header is preserved) on the main/first interface.
In a Layer 2 VLAN switch, the Cisco IOS software runs an IEEE 802.1 spanning tree for each
Layer 2 VLAN to enhance scalability and prevent topology changes in one switched VLAN
domain from affecting a different VLAN.
A switched VLAN domain corresponds to a routed subnet/network number and is represented
in the Cisco IOS software by a VLAN subinterface.
Layer 2 VLAN translation is the ability of the Cisco IOS software to "interpret" between
different VLANs (which use the same or different VLAN protocols), or between VLAN and
non-VLAN encapsulating interfaces at Layer 2.
Figure 11-2 depicts the differences between VLAN switching, translation, and routing.
Figure 11-2 There are differences between VLAN switching, translation, and routing.
Layer 2 VLAN Switching
Data MAC Address VLAN 2 Data MAC Address VLAN 2
Layer 2 VLAN Translation
Data MAC Address 802.1Q
Data MAC Address VLAN ID or
Data MAC Address 802.10
Layer 3 VLAN Routing
Data MAC Address VLAN 3
Data MAC Address VLAN 2 or
Data WAN Address
VLAN translation functionality is typically used for selective inter-VLAN switching of

nonroutable protocols such as Maintenance Operation Protocol (MOP) and local-area transport
(LAT) and to extend a single VLAN topology across hybrid (mixed 802.1Q and 802.10
networks) switching environments. VLAN translation was introduced in Cisco IOS Release
11.1 and is fast switched (route cache is used to expedite packet switching through a router).
The router can also perform Layer 3 routing between VLANs, which provides connectivity
between different VLANs, and between VLANs and non-VLAN network interfaces, such as
those that connect to WAN services or to the Internet.
As the router provides Layer 3 VLAN services, the router continues providing standard routing
attributes such as network advertisements, secondary addresses, and helper addresses. VLAN
routing is fast switched.
Another feature of routers is Hot Standby Router Protocol (HSRP), which provides automatic
router backup by establishing a virtual router. HSRP allows two or more HSRP-configured
routers to use the MAC address and IP network address of a virtual router. The virtual router
does not physically exist; instead, it represents the common target for routers that are configured
to provide backup to each other.
Cisco IOS Fast Ethernet Troubleshooting 447
HSRP allows Cisco IOS routers to monitor each other’s operational status and very quickly
assume packet-forwarding responsibility if the current forwarder in the HSRP group fails or is
taken down for maintenance. This mechanism remains transparent to the attached hosts and can
be deployed on any LAN or VLAN type.
The Router’s Layer 2 Translation Function

By definition VLANs perform network partitioning and traffic separation at Layer 2.
Communication between different VLANs requires a Layer 3 routing or a Layer 2 translation
function.
The Cisco IOS software platform incorporates full support for routing and translation between
VLANs and between VLAN trunking and non-VLAN interfaces.
The integrated solution of high-speed, scalable VLAN switching of local traffic and efficient
routing and switching of inter-VLAN traffic is becoming increasingly attractive in large
networks.
Cisco routers address this requirement with their ability to address many different VLAN needs:
• ISL over Fast Ethernet.
• IEEE 802.1Q standards (especially for packet tagging as a common VLAN exchange
mechanism between switches, routers, and server devices).
• IEEE 802.10 (especially for FDDI backbones). With IEEE 802.10–based VLANs, it is
also possible to use High-Level Data Link Control (HDLC) serial links as VLAN trunks
to extend a virtual topology beyond a LAN backbone.
• ATM LAN Emulation (LANE) VLANs.
The router also enables connectivity between VLANs and non-VLAN interfaces such as those
that connect the campus LANs to the WAN and to the Internet. Cisco routers address this
requirement with their ability to connect the following:
• WAN Layer 2 protocols such as HDLC, Point-to-Point Protocol (PPP), and Frame Relay
• Internet services, including those that use TCP/IP, Novell IPX, AppleTalk, DECnet,
Banyan VINES, and several other protocols
Cisco IOS Fast Ethernet Troubleshooting

To troubleshoot the operation of router Fast Ethernet connections to Catalyst switches, you
need to make sure that the Cisco IOS interface configuration is complete and correct:
• Do not configure an IP address on the main Fast Ethernet. Instead, configure an IP address
for each subinterface that you specify as a connection to a VLAN.
Cisco IOS Fast Ethernet Troubleshooting 449
Figure 11-3 shows the explicit configuration used to set up ISL VLANs on a router, along with
the comparable configuration on the router’s Catalyst 5000 neighbor.
ISL is available on the Catalyst 5000 line cards that offer 100Base media. ISL VLAN trunking
is defined only on 100BaseTX/FX Fast Ethernet interfaces on the 7000 and 4500 series
platforms. The design leverages the subinterface (or virtual interface) mechanism to view ISL
as an encapsulation type.
You can map a router Fast Ethernet subinterface to the particular VLAN color (that is, ISL
value) embedded within the VLAN header. This mapping determines which VLAN traffic is
routed/bridged outside its own VLAN domain and allows for full Cisco IOS functionality to be
applied on a subinterface basis. Also, in the VLAN routing paradigm, a switched VLAN
corresponds to a single routed subnet, and the Layer 3 address is assigned to the subinterface.
Routing between VLANs is currently permitted only to IP and Novell-Ethernet IPX
encapsulations on ISL. Integrated routing and bridging (IRB) enables routing and bridging
between VLANs and includes support for IPX with SNAP and SAP encapsulations as well as
for AppleTalk.
In the example shown in Figure 11-3, IP traffic is routed from ISL VLANs 2 and 3, as is the IPX
traffic. The Fast Ethernet subinterfaces 2/1.3 and 2/1.3 are both in bridge group 50, so all the
other nonrouted ISL traffic can be bridged between these two subinterfaces.
On the two switches, use the Catalyst 5000 set trunk command for the Fast Ethernet trunk that
connects to the router. When you set the trunk on and enable the range of VLANs 1 through
1000, any VLANs set up on the switched network can traverse the ISL on the router.
To exclude a VLAN from traversing the ISL trunk and router, use the Catalyst 5000 clear trunk
command for the Fast Ethernet trunk that connects to the router and specify the VLAN ID that
you do not want to use on the router’s ISL trunk.
NOTE IRB is a feature of Cisco IOS Release 11.2. IRB was designed to enhance concurrent routing
and bridging (CRB), a feature of Cisco IOS Release 11.0. In the past, Cisco routers could route
or bridge a protocol, but not both.
CRB enables a user to both route and bridge a protocol on separate interfaces within a single
router. However, the routed traffic is confined to the routed interfaces, and bridged traffic is
confined to the bridged interfaces; for any given protocol, the traffic may be either routed or
bridged on a given interface, but not both.
With IRB, a protocol can be routed either between both routed interfaces and bridged interfaces
or between different bridge groups internal to the router. Note that you can run either IRB or
CRB, but not both.
Refer to www.cisco.com/Mkt/cmc/cc/cisco/mkt/ios/rel/112/irb_dg.htm for a white paper titled
Using Integrated Routing and Bridging with Virtual LANs.
VLAN Troubleshooting Issues

This section focuses on the following VLAN troubleshooting aspects:
• VLAN design
• The router’s functionality in a switched network
• Cisco Discovery Protocol (CDP)
• Telnet
VLAN Design Issues

Several VLAN metrics are design considerations to set up, operate, and manage the extended
router/switch network:
• As a general rule, the network diameter should have a maximum hop count of seven
bridges (routers and switches). The network diameter influences the amount of temporary
loss of connectivity during spanning-tree recomputations. During the listening phase of
this period, data packets are discarded.
• A bridge protocol data unit (BPDU) age metric specifies how periodically the network
device expects to receive (or will drop) BPDU messages at the point when the change
occurred. This metric setting also influences the speed of convergence and the ensuing
flooding of BPDUs.
• The values for the BPDU age, BPDU hello time, and forward delay (for that VLAN) set
on the root bridge are imposed on all other switches in the root bridge’s VLAN topology.
Table 11-1 shows the ISL VLAN ID numbers used by default for the various media types. The
table also shows the 802.10 ID defaults for an 802.10 header packet outer header element called
the Security Association Identifier (SAID).
Table 11-1 Default ISL VLAN ID numbers.

ISL VLAN- 802.10
VLAN Name Type MTU id SAID
default ethernet 1500 0001 1
fddi-default fddi 4352 1002 101002
token-ring—default token-ring 2048 1003 101003
fddinet—default fddi-net 4352 1004 101004
trnet—default tr-net 2048 1005 101005
VLAN Troubleshooting Issues 451
For VLAN assignment, you can use VLAN numbers in the range of 1 through 1000. When you
configure for the router/switch extended network VLANs, make sure that
• The media type and maximum transmission unit (MTU) are consistent on both sides of
the link.
• If possible, the default Ethernet VLAN ID 1 should be used for management and
troubleshooting only. Use the other numbers in the range (2 through 1000) for VLANs that
will carry user traffic.
Router Functionality in a Switched Network

As you gather facts and consider possibilities for troubleshooting, remember several factors
about the role of a router working with VLANs and switches:
• If you are using the router to bridge between ISL subinterfaces, the spanning trees of the
associated VLANs will combine into a single spanning tree. This combination can make
the router the best point of connectivity, and the router could become the root bridge.
• Avoid turning on multiple subinterfaces if you do not want the Spanning-Tree Protocol to
merge the VLANs on each router subinterface bridged in a single tree.
• Check that the Spanning-Tree Protocol encapsulation set on the extended router/switch
network is consistent. In other words, use IEEE Spanning-Tree Protocol everywhere in the
network or use Digital Spanning-Tree Protocol everywhere in the network. Do not use
both IEEE and Digital bridging.
A case study later in this chapter describes the serious problems that occur with incompatible
Spanning-Tree Protocol domains. These problems include BPDUs and other packets dropped,
loops, and broadcast storms.
The following list guides you through Spanning-Tree Protocol network troubleshooting:
• For the most effective troubleshooting to proceed, you need to know the location of the
root bridge in your extended router/switch network. The show commands on both the
router and the switches can display root bridge information.
• The root bridge is where you can configure the timers that set parameters such as
forwarding delay and the maximum age for Spanning-Tree Protocol information. You also
have the option of hard-coding a device that you want to establish as the root bridge.
• If the extended router/switch network encounters a period of instability, you might want
to reduce the frequency of Spanning-Tree Protocol processes between devices because
those processes may make matters worse.
• If you want to reduce BPDU traffic, set the timers on the root bridge at their maximum
values. Specifically, set the forward delay parameter to the maximum of 30 seconds and
set the maximum age parameter to the maximum of 40 seconds. However, this increases
the amount of time it takes the network to converge, or learn about, network topology
changes.
Router VLAN debug Commands 457
Step 2 For each nonroot bridge, determine the direction, in terms of the relevant
interface and port, to the root bridge.
Step 3 Draw your map as you identify the links.
The following rules apply when you’re using spanning-tree information to create a network
map:
• When the MAC address of the designated bridge is the same as the MAC address of the
root bridge, the port or interface of the bridge being examined and the root bridge are
attached to the same network.
• When the MAC address of the designated bridge is different from the MAC address of the
bridge being examined, the designated bridge is in the path to the root bridge.
• When the MAC address of the designated bridge is the same as the bridge identifier of the
bridge being examined, the port or interface points away from the root bridge.
• The designated port value specified for a particular port belongs to the bridge associated
with the designated bridge shown in the port listing.
Router VLAN debug Commands

When you are troubleshooting a campus network that has both routers and switches, the two
commands debug vlan packet and debug span can help you get a close-to-real-time
perspective of VLAN problems and a status of the spanning tree from the router’s perspective.
Although these troubleshooting tools are readily available from the same command-line
interface as the one you use for your configuration tasks, these debug commands require that
you handle them properly, especially if you use debug on a production network that users
depend on for data flow.
Nonetheless, with the proper, selective, and temporary use of these tools, you can easily obtain
potentially useful information as you gather facts and consider possibilities.
NOTE Several of the precautions and issues for the proper use of debug are covered in Chapter 5,
“Cisco Management and Diagnostic Tools.”
The debug vlan packet Command

Use the debug vlan packet EXEC command to display general information on VLAN packets
that the router received, but is not configured to support.
Router VLAN debug Commands 459
After you get past the initial reaction of overload from the long string of characters, as shown
in Figure 11-8, this command is useful for tracking and verifying that the Spanning-Tree
Protocol is operating correctly.
Figure 11-8 The debug span command displays spanning-tree topology changes.
router# debug span
PST: Ether 0000000000000A080002A02D6700000000000A080002A02D6780010000140002000F00

A B C&D E F G H I J K L M O P
PST: Indication that this is a spanning-tree packet.

Ether Interface receiving the packet.
(A) 0000 Indication that this is an IEEE BPDU packet.
(B) 00 Version.
(C) 00 Command mode:
00 indicates Config BPDU.
80 indicates the Topology Change Notification (TCN) BPDU.
(D) 00 Topology change acknowledgment:
00 indicates no change.
80 indicates a change notification.
(E) 000A Root priority.
(F) 080002A02D67 Root ID.
(G) 00000000 Root path cost (0 means the sender of this BPDU packet is the root
bridge).
(H) 000A Bridge priority.
(I) 080002A02D67 Bridge ID.
(J) 80 Port priority.
(K) 01 Port No. 1.
(L) 0000 Message age in 256ths of a second (0 seconds, in this case).
(M) 1400 Maximum age in 256ths of a second (20 seconds, in this case).
(N) 0200 Hello time in 256ths of a second (2 seconds, in this case).
(O) 0F00 Forward delay in 256ths of a second (15 seconds, in this case).
You can see the router’s perspective in the spanning-tree packets that the router receives. By
counting out the digits and aligning the fields, you can get all the fields of data used for
Spanning-Tree Protocol.
You can combine this information with what is available from the Catalyst show span
command to get a close-to-real-time filtering of the Spanning-Tree Protocol BPDU messaging
process.
NOTE Figure 11-8 shows Spanning-Tree Protocol with IEEE encapsulation set. For Spanning-Tree
Protocol with Digital encapsulation, refer to www.cisco.com.
470 Chapter 12: Diagnosing and Correcting Frame Relay Problems
The Local Management Interface (LMI) type configured must match on the DTE and on the
data circuit-terminating equipment (DCE). For Frame Relay, the options are Cisco, ANSI, or
q933a (ITU-T). The router autosenses which LMI is in use (for Cisco IOS 11.2 and later
versions), and the LMI provides the keepalives that you can check when you troubleshoot. Use
the command frame-relay lmi-type {ansi | cisco | q933a} to change the LMI type if necessary.
A Frame Relay service provider specifies the data-link connection identifier (DLCI) to use, and
this identifier is significant locally only. As part of the configuration process, the DLCI maps to
the destination Layer 3 address for that PVC. Often, a useful troubleshooting test is to verify
the details and effects of this configuration process.
The framing fields for High-Level Data Link Control (HDLC) are streamlined for Frame Relay.
One key field is the DLCI, which is represented as a 6-bit high-order and a 4-bit low-order part
of the address octets, as shown in Figure 12-2. The 10-bit DLCI value is the heart of the Frame
Relay header. It identifies the logical connection that is multiplexed into the physical channel.
Figure 12-2 The most significant portion of the frame, the DLCI portion, determines the destination of the frame.
Frame
Information
Flag Relay FCS Flag
Field
Header
Byte 1 Byte 2
DLCI C/R EA DLCI FECN BECN DE EA
Bit 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
DCLI = Data-link connection identifier

C/R = Command/response field bit (application specific—not modified by network)
FECN = Forward explicit congestion notification
BECN = Backward explicit congestion notification
21202.eps
DE = Discard eligibility indicator

EA = Extension bit (allows indication of 3- or 4-byte header)
Troubleshooting Frame Relay 471
Frame Relay Frame Format

In the basic LMI addressing, DLCIs have local significance; that is, the end devices at two
different ends of a connection may use different DLCIs to refer to that same connection. LMI
is the connection status mechanism used by Frame Relay. There are three LMI specifications
offered by Cisco, as defined earlier in this chapter.
Use of different DLCIs can be a source of problems if either DTE misinterprets or misapplies
the DLCI number specified by the service provider. Typically, however, this problem is isolated
and resolved during the testing phase.
Congestion-related bit positions in the frame are
• FECN—Forward explicit congestion notification, set by a Frame Relay network to inform
the DTE receiving the frame that congestion was experienced in the path from source to
destination.
The Cisco router passes FECN along so that the DTE receiving frames with the
FECN bit set can request that higher-level protocols take flow-control action as
appropriate.
• BECN—Backward explicit congestion notification, set by a Frame Relay network in
frames traveling in the opposite direction of frames encountering a congested path.
Again, the router passes BECN along so that the DTE receiving frames with the
BECN bit set can request that higher-level protocols take flow-control action as
appropriate.
• DE—Discard eligibility, set by the DTE to tell the Frame Relay network that a frame has
lower importance than other frames and should be discarded before other frames if the
network becomes short of resources. Thus, it represents a simple priority mechanism.
You use the Cisco IOS show frame-relay pvc command and the debug frame-relay
commands (covered later in this chapter) to see the current values in these frame fields.
Problem Isolation in Frame Relay WANs

The flowchart shown in Figure 12-3 provides the basic steps for problem isolation in a Frame
Relay network. The tools available to check each element are covered in greater detail later in
this chapter.
Figure 12-3 You can use the Frame Relay problem isolation flowchart to troubleshoot more efficiently.
Y Y Layer 2 Y
Local physical Configuration for to Layer 3 map
link okay? PVCs okay? okay?
N N N
Fix any problems Fix any problems Fix any configuration

with cabling, with encapsulation, problems (e.g., address)
connectors, and LMI type, speed
interface
Remote side and

facilities okay?
21203.eps
Contact destination side or
service provider for remote tests
Let’s examine the typical symptoms and problems that may occur on a WAN. Table 12-1 lists
serial link problems, and Table 12-2 lists Frame Relay problems.
Table 12-1 Generic serial link symptoms and possible problems.
Symptom Possible Problems
Intermittent connectivity • Faulty router interface card or cable

• Faulty CSU/DSU
• Timing problem
• Congested/overutilized serial line
Connection fails as load increases • Dirty serial line

Connections fail at a particular time • Congested/overutilized serial line

of day
Connections fail after some period • Unshielded cable runs too close to EMI sources
of normal operation • Hardware in serial link failed
• Incorrect routing tables (flapping links)
• Buffer misses or other software problems
Connection has never worked • Serial facility not provisioned or has failed
Troubleshooting Frame Relay 473
Table 12-1 Generic serial link symptoms and possible problems. (Continued)
Faulty router interface card or cable • Use the show interfaces serial command to check for
errors and swap card or cable if necessary
• Use show controllers command to check microcode
level; upgrade if the version is old
Faulty CSU/DSU • Check for input errors with the show interfaces serial
command and replace CSU/DSU if necessary
Timing problem • Verify that serial clock transmit external (SCTE)

terminal timing is enabled on CSU/DSU
• Verify that the correct device is generating the system
clock
• Check cable length
• Lower the line speed
Congested/overutilized serial line • Reduce broadcast traffic

• Use protocol analyzer to check application behavior (for
example, very large file transfers during peak hours)
• Implement priority queuing
• Adjust hold queue and buffer sizes with help from a
technical support representative
• Add bandwidth, consider using dial backup
Dirty serial line • Look for increasing input errors by using show
interfaces serial
Unshielded cable runs too close to EMI • Look for increasing input errors by using show
sources interfaces serial
• Inspect cables and relocate or shield cables if necessary
Hardware in serial link failed • Confirm that link is down by using show interfaces
serial
• Use loopback tests and protocol analyzer to isolate
problem
Incorrect routing tables • Check routes by using the appropriate show protocol
route
• Look for source of bad routes by checking configuration
and using a protocol analyzer
Buffer misses or other software problems • Evaluate buffer status by using show buffers
• With help from a technical support representative,
modify buffers to prevent dropped connections
If you suspect that one or more of these problems is the cause of the line protocol being down,
appropriate actions to try include the following:
• Check the data link for Frame Relay—the DTE-to-DCE interface.
• Check the link from CSU to CSU to eliminate link and hardware problems.
• Perform loopback tests to determine which parts of Layer 2 (if any) are active and which
are not.
The show frame-relay lmi Command

The show frame-relay lmi command can help you troubleshoot by providing LMI statistics
that may indicate a problem.
To set a starting point for getting statistics, use the clear counters serial number command.
This command resets the interface counters that will be used with this show command and
others.
In Figure 12-7, one key element to check is what role and keepalive type are being used for the
Frame Relay interface. Here it is acting as a DTE on a User-Network Interface (UNI); it could
also act as a Network-to-Network Interface (NNI).
Figure 12-7 You can use the show frame-relay lmi command to check LMI statistics.
Router#show frame-relay lmi
LMI Statistics for interface Serial1 (Frame Relay DTE) LMI TYPE = ANSI
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 9 Num Status msgs Rcvd 0
Num Update Status Rcvd 0 Num Status Timeouts 9
You should look for nonzero invalid LMI items accumulated in the counters. The explicit
decodes of a protocol analyzer are required to see the information elements.
Also check Num Status Timeouts, which is the number of times the status message was not
received within the keepalive timer. Num Status Enq. Timeouts is the number of times the status
inquiry message was not received within the T392 DCE timer.
The show frame-relay map Command

You use the show frame-relay map command to troubleshoot the current DLCI to Layer 3 map
entries and to check information about the connections. Output includes end-to-end
information about the mapping of the locally significant DLCI to the far-end destination.
WAN and Frame Relay Diagnostic Tools 479
In Figure 12-8, the Frame Relay interface has been shut and has a PVC to the IP destination
shown. The DLCI to reach this interface is
• 177 decimal
• B1 hexadecimal
• 2C10, as it appears on the facility
An upper-layer protocol process uses a broadcast if it does not know about the DLCIs
configured on the interface.
Figure 12-8 The Frame Relay interface is shut and has a PVC to an IP destination.
Router#show frame-relay map
Serial 1 (administratively down): ip 131.108.177.177
dlci 177 (0xB1,0x2C10), static,
broadcast,
CISCO
TCP/IP Header Compression (inherited), passive (inherited)
Compression is inherited from the interface rather than from an explicit configuration
statement.
The show frame-relay pvc Command

This show frame-relay pvc command provides the LMI status of each DLCI, as shown in
Figure 12-9; or you can specify a given DLCI to check that PVC only.
Figure 12-9 You can use the show frame-relay pvc command to check PVCs.
Router#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DCE)
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE
pvc create time 0:03:03 last time pvc status changed 0:03:03
Num Pkts Switched 0
DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE

pvc create time 0:02:58 last time pvc status changed 0:02:58
Num Pkts Switched 0
DLCI usage can be local DTE or SWITCHED (meaning that the router is acting as a switch).
As DCE, the status refers to outgoing interfaces (up or down) and the status of the outgoing
PVC.
Figure 12-10 HDLC keepalive myseq numbers increment, but one mineseen keepalive sequence number does not
increment.
Router# debug serial interface
Serial1: HDLC myseq 636127, mineseen 636127, yourseen 515040, line up

Serial1: HDLC myseq 636133, mineseen 636130, yourseen 515046, line down
....
Illegal serial link type code xxx
The output of the debug serial interface command can vary, depending on the type of WAN
configured for an interface: Frame Relay or HDLC (other interfaces are HSSI, SMDS, and
X.25).
The output also can vary depending on the type of encapsulation configured for that interface.
The hardware platform also can affect the output of the debug serial interface command.
For troubleshooting a Frame Relay data link, many engineers temporarily set the encapsulation
to HDLC as shown in Figure 12-10 to see what keepalive traffic is present. They use this
approach because if the LMI is down for Frame Relay, the interface with Frame Relay
encapsulation will not be able to generate the keepalive values.
If the keepalive values are not incrementing in each subsequent line of output, there is a timing
or line problem at one end of the connection. The field values are
• mineseq—The keepalive sent by the local side
• yourseen—The keepalive sent by the other side
• mineseen—The local keepalive seen by the other side
Figure 12-10 shows that the remote router is not receiving all the keepalives that the local router
is sending. The DTE sends out a sequence number and expects the same sequence number back
on a valid packet from the remote end.
When the difference in the values in the myseq and mineseen fields exceeds the values of two
of six consecutive keepalive events (e.g., 636130 was the last mineseen but 636131 through
636133 were not seen), the line goes down and the interface is reset. The line protocol then goes
down and any Layer 3 protocol will not consider the line to be available. Frame Relay LMI
continues to try to reestablish a valid keepalive dialog. If the LMI gets three consecutive myseq/
mineseen indicators, it brings the line back up. The yourseen values that are sequenced from
the remote end (e.g., 515040 through 515046) are incrementing appropriately. Frame flow from
the remote side to the local side is working; the problem to check further is frame flow from this
side to the other side.
The illegal serial link message is displayed if the encapsulation is Frame Relay (or HDLC) and
the router attempts to send a packet containing an unknown packet type.
You will learn more on Frame Relay operations with the debug frame-relay events and debug
frame-relay packet commands later in this chapter.
The debug frame-relay lmi Command

You can check LMI exchanges by using the debug frame-relay lmi command. The first four
lines of output in Figure 12-11 describe an LMI exchange. The first line describes the LMI
request the router has sent to the switch. The second line describes the LMI reply the router has
received from the switch.
Figure 12-11 You can use the debug frame-relay lmi command to check LMI exchanges.
Router#debug frame-relay lmi
Serial 1 (out): StEnq, clock 20212760, myseq 206, mineseen 205, yourseen 136, DTE up
Serial 1 (in): Status, clock 20212764, myseq 206
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 138, myseq 206
....
Serial 1 (out): StEnq, clock 20252760, myseq 210, mineseen 209, yourseen 144, DTE up
Serial 1 (in): Status, clock 20252764, myseq 210
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 146, myseq 210
PVC IE 0x7, length 0x6, dlci 400, status 0, bw 56000
PVC IE 0x7, length 0x6, dlci 401, status 0, bw 56000
The (out) StEnq is an LMI status enquiry sent by the router and the (in) Status is the reply from
the Frame Relay switch. The mineseen is the number of the last keepalive accepted as good by
the switch.
The third and fourth lines describe the response to this request from the switch. The RT IE is a
report type information element for keepalives with seq and seen values numbering the
keepalives.
You use the clock to check elapsed milliseconds of system clock between messages or events.
The first four lines are an LMI exchange, the last six lines (after the ....) are a full LMI status
message with PVC information. PVC information elements include DLCI, status 0 (added/
inactive), and committed info rate (CIR) of 56 kbps.
Because the debug frame-relay lmi command does not generate much output, you can use it
at any time, even during periods of heavy traffic, without adversely affecting other users on the
system.
The debug frame-relay events Command

The debug frame-relay events command helps you analyze the packets that have been
received. However, because the debug frame-relay events command generates a lot of output,
you should only use it when traffic on the Frame Relay network is lighter than 25 packets per
second.
Output from the debug frame-relay events command can help you troubleshoot the inbound
traffic and determine which application is using a DLCI. In Figure 12-12, all the packets on
serial0 and serial1 are incoming (indicated by i).
Figure 12-12 You can use the debug frame-relay events command on a network with traffic lighter than 25 packets per
second due to the debug command’s processing and output generation costs.
router#debug frame-relay events
Serial0(i): dlci 500(0x7C41), pkt type 0x800, datagramsize 24
Serial1(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13
Serial1(i): dlci 1023(0xFCF1), pkt type 0x309, datagramsize 13
As highlighted in Figure 12-12, the Frame Relay packets received on serial 0 DLCI 500 are type
IP on 10-Mbps nets with 24-byte datagram size. Also highlighted in Figure 12-12, you can see
that the Frame Relay packets received on serial 1 DLCI 1023 are ANSI LMI messages with
13-byte size. There are many other packet type codes. Cisco routers may also use the Ethernet
type coded in the pkt type field.
Possible packet type values for signaling are
• 0x308—Signaling message; valid only with a DLCI of 0
• 0x309—LMI message; valid only with a DLCI of 1023
Possible Ethernet-type codes include the following:
• 0x0201—IP on 3-MB network
• 0xCC—RFC 1294 (only for IP)
• 0x0800—IP on 10-MB network
• 0x0806—IP ARP
• 0x0808—Frame Relay ARP
• 0x8035—RARP
• 0x8038—Digital spanning tree
• 0x809b—Apple EtherTalk
• 0x80f3—AppleTalk ARP
• 0x8137—IPX
• 0x9000—Ethernet loopback packet IP pkt type
490 Chapter 13: Diagnosing and Correcting ISDN BRI Problems
Figure 13-1 You can use this ISDN troubleshooting flowchart to streamline your problem resolution process.
Physical link Y Layer 2 Y Layer 3 Y

activation (Q.921/LAPD or PPP) (Q.931 or LCP)
okay? okay? okay?
N N N
Fix any problems Fix any problems with TEI, Fix any configuration
with cabling, connectors, call setup, or negotiation problems (e.g., SPIDs)
and facility
Dialer (DDR) Y CHAP or PAP

configuration configuration
okay? okay?
N N
Fix problems with call Fix problems with authentication
t621301
trigger, route, or destination number type, encapsulation, password, or
identifier
Table 13-1 lists generic serial problems and their symptoms. Table 13-2 lists problems specific
to ISDN BRI links, and Table 13-3 lists possible solutions to ISDN BRI problems.
Table 13-1 Generic serial symptoms and possible problems.
Intermittent connectivity • Faulty router interface card or cable
• Faulty NT1 or facility
• Timing problem
Connection fails as load • Dirty serial line
increases • Congested/overutilized serial line
Connection fails at a particular • Congested/overutilized serial line
time of day
Problem Isolation in ISDN BRI Networks 491
Table 13-1 Generic serial symptoms and possible problems. (Continued)

Connection fails after some • Unshielded cable runs too close to EMI sources
period of normal operation • Hardware in the serial link failed
• Incorrect routing tables (flapping links)
• Buffer misses or other software problems
Connection has never worked • Serial facility not provisioned or has failed
Faulty router interface card or • Use the show interfaces serial command to check for errors and
cable swap card or cable if necessary.
• Use the show controllers command to check cable used and
physically check that cable is properly installed.
Faulty NT1 or facility • Check for input errors by using the show interfaces serial
command and replace NT1 if necessary; contact service provider.
Timing problem • Verify that the correct device is generating the system clock.
• Check the cable length.
• Lower the line speed.
Congested/overutilized serial • Reduce broadcast traffic.
line • Use protocol analyzer to check application behavior (for example,
very large file transfers during peak hours).
• Implement priority queuing.
• Adjust hold queue and buffers sizes with help from a technical
support representative.
• Add bandwidth and consider using a dial backup.
Table 13-2 ISDN BRI symptoms and possible problems.

ISDN router does not dial. • No ISDN switch specified or no route exists
• Bad service profile identifier (SPID) or calling or called number
• Incorrect dial-on-demand routing (DDR) statement (e.g., dialer-
list, dialer-group, dialer map, or dialer string)
Users cannot connect. • Faulty router interface card or cable.
• Switch is misconfigured.
• Router is misconfigured.
continues
You can use the following commands to isolate ISDN problems:

• clear interface bri number—Resets the hardware logic on a BRI interface where number
is the port number (or slot/port number). Use this command to reset the counters to zero
if you want to restart the counters you are checking.
• show interfaces bri number—Displays information about the BRI D channel for the
interface selected by the number argument.
• show interfaces bri number 1 2—For the interface selected by the number argument,
displays the information about the BRI B channels 1 and 2.
• show controllers bri—Displays information about the BRI controller, including
activation status for Layer 1.
• show isdn status—Displays information about which ISDN switch is used and the status
of Layers 1, 2, and 3 for BRI calls.
• show dialer interface bri number—Displays information about the DDR dial string, call
status, and timer settings.
• show ppp multilink—Displays information about bundles of BRI B channels using an
extended variation of Point-to-Point Protocol (PPP) encapsulation.
NOTE For WAN troubleshooting, Cisco engineers recommend that you use the Cisco IOS service
timestamps command. This command puts a timestamp on a debug or log message and can
provide valuable information about when debug elements occurred and the duration of time
between events. You can specify that the time measure be for debug type or log message type
events. You can request that the display refer to uptime (that is, how long after the system was
rebooted) or datetime (that is, a date and time indicator). And you can request that Cisco IOS
software include millisecond or local time zone elements in the timestamp.
The following are other examples of this command:
• service timestamps debug uptime—Logs time with debug output by using the system
clock, which may be external, such as Network Time Protocol (NTP).
• service timestamps log datetime msec—Logs with datetime and in msec.
Output and interpretation of some of the key content of the output of these commands appears
in the following sections.
The show interfaces bri Command

BRI offers 144 kbps for use at small data concentration points. The interface creates the
channels. Each BRI interface delivers two 64-kbps data channels (B channels) and one 16-kbps
signaling channel (D channel), as shown in Figure 13-3. The BRI service is commonly referred
to as 2B+D.
ISDN BRI Diagnostic Tools 495
Figure 13-3 The ISDN B channel is 64 kbps, and the D channel is 16 kbps.
64 kbps B Channel
64 kbps B Channel BRI
16 kbps D Channel
Pipe size defines the maximum amount of data that can be transmitted at one time. In many
cases, the pipe size is less crucial than how the user application fills the pipe (for example,
bursty traffic compared to a more consistent flow of data). The combined B channels do not
necessarily provide the same capacity as one 128-kbps channel because the transfer rate is
not proportional for packets sent.
When you are troubleshooting, you can focus on these specific components of BRI services as
well as the 48 kbps of overhead bits that are also sent in the 48-bit BRI frame.
In Figure 13-4, which depicts the output from the show interfaces bri command, the message
“Line protocol is up (spoofing)” is D channel information that the interface alleges to be up.
Figure 13-4 “Line protocol is up (spoofing)”is D channel information.

router# show interface bri 0
BRI0 is up, line protocol is up (spoofing)
Hardware is BRI
Encapsulation PPP, loopback not set
Last input never, output 0:00:09, output hang never
0 output errors, 0 collisions, 33 interface resets, 0 restarts
Spoofing does not necessarily mean that the D channel is up. In fact, there may be no line
on the interface. What spoofing does is “lie” to Layer 3 DDR so that a routing entry will be
maintained in the router. Having this routing entry enables DDR to wake up and trigger a
call to the ISDN network when user traffic requires the connection.
The router in the example just came up. For a router that has been operational for a long period,
use the clear interface bri 0 command to reset the counters for the interface. This clear counter
condition allows you to set the starting time for many of the output fields in the show interfaces
command.
The show interfaces bri number 1 2 Command

When you use the variation of the show interfaces bri command that specifies the channel
number, you can see output about one or both B channels on the BRI, as shown in Figure 13-5.
Figure 13-5 The command argument 1 refers to BRI channel B1.

router# show int bri 0 1
BRI0: B-Channel 1 is down, line protocol is down
Hardware is BRI
Encapsulation PPP, loopback not set, keepalive set (10 sec)
Last input never, output never, output hang never
0 output errors, 0 collisions, 39 interface resets, 0 restart
Possible causes for channel down include

• The protocol is down.
• The interface is not active.
• The cabling is incorrect.
• There is a telephone company problem (line down or not connected to switch).
• There is a hardware failure (e.g., router port/card).
The show controllers bri and show isdn status Commands

The show controllers bri and show isdn status commands provide troubleshooting
information about the Layer 1 startup activation process of an ISDN line.
First, let’s examine Layer 1 elements and functionality.
Standard ISDN BRI Roles and Interface Reference Points

You should focus your ISDN network troubleshooting efforts on the local loop. The ISDN
central office (CO) is considered the network side of the ISDN local loop. The line termination/
exchange termination (LT/ET) handles termination of the local loop and switching functions.
Figure 13-6 shows all these elements.
Figure 13-6 The ISDN local loop is the key focus for troubleshooting.
LT ET
Remote
Key Troubleshooting Focus ISDN Terminations
Terminal
Endpoint
LT
int bri n Local Loop to
S/T Central Office
U
TE1 NT1
Network
Termination
int s n
TE2 R TA
Terminal
Adapter
At the customer site, the ISDN local loop is terminated using a network termination type 1
(NT1). The NT1’s responsibilities include line performance monitoring, timing, physical
signaling protocol conversion, power transfer, and multiplexing of the B and D channels.
There are two other notable ISDN devices: terminal equipment (TE) and terminal adapters
(TAs). TE refers to end-user devices such as digital telephones or workstations:
• Native ISDN terminals are referred to as terminal equipment type 1 (TE1). TE1s connect
to the ISDN network through a four-wire, twisted-pair digital link.
• Non-ISDN terminals such as DTE that predate the ISDN standards are referred to as
terminal equipment type 2 (TE2). TE2s connect to the ISDN network through terminal
adapters. The ISDN TA can either be a standalone device or a board inside the TE2.
If the TE2 is implemented as a standalone device, it connects to the TA via a
standard physical-layer interface. Examples include EIA/TIA-232-C, V.24, and
V.35. The TA performs the necessary protocol conversion to allow non-ISDN
(TE2) equipment to access the ISDN network.
Reference points provide for a common term usage when troubleshooting a component of the
local loop part of the network. Vendors and providers of ISDN use the reference points R, S, T,
and U, as shown in Figure 13-6:
• R reference point—The interface between non-ISDN terminal equipment (TE2) and a TA.
The TA allows the TE2 to appear to the network as an ISDN device. There is no standard
for the R reference point. Vendors can choose a variety of different physical connections
and communication schemes.
• S reference point—The interface between ISDN user equipment, either the TE1 or TA and
the NT2 or NT1.
• T reference point—The interface between the customer site switching equipment (NT2)
and the local loop termination (NT1).
The International Telecommunications Union (ITU; formerly International
Telegraph and Telephone Consultative Committee [CCITT]) specifically
addresses protocols for the S and T reference points.
In the absence of NT2 equipment, the User-Network Interface (UNI) is usually
called the S/T reference point. The S/T interface is a key focus of the
troubleshooting efforts covered in this chapter.
Normally, the S/T interface is a four-wire facility that reuses the existing wire
plant. This facility uses a transmit pair and a receive pair of pins.
• U reference point—The interface where transmission between the NT1 and the LE occurs.
Normally, the U interface is a two-wire facility to reduce wiring costs. This
facility uses a frequency division multiplexing technique and echo cancellation
for a ping-pong operation of fast half duplex that simulates full duplex.
Both the S/T and the U interfaces achieve full-duplex communications.
Troubleshooting the Layer 1 S/T Interface

As shown in Figure 13-7, the four-wire service at the S/T interface uses an RJ-45 cable and
connector.
Figure 13-7 ISDN uses RJ-45 connectors (ISO 8877).
Terminal End- Network

8 Point (TE) Termination (NT)
Pin Pin Function
1
1 Power Source 3 (+) Power Sink 3 (+)
2 Power Source 3 (-) Power Sink 3 (-)
3 Transmit (+) Receive (+)
4 Receive (+) Transmit (+)
5 Receive (-) Transmit (-)
6 Transmit (-) Receive (-)
7 Power Sink 2 (-) Power Source 2 (-)
8 Power Sink 2 (+) Power Source 2 (+)
The mechanical specifications for the ISDN connector are specified by the ISO 8877 standard.
Pins 3, 4, 5, and 6 are the key pins used for ISDN. When you troubleshoot, make sure that your
cable and connector are correct for BRI. Also look for visible evidence of broken casing or
wires.
ISDN uses the electrical specification for alternate mark inversion (AMI) line coding. The
polarity indications in the table for transmit and receive circuits are the polarity of the framing
pulses.
BRI Line Framing on the S/T Interface

From the local loop perspective, ISDN carries digital signals between two points. ISDN
physical-layer (Layer 1) frame formats differ depending on whether the frame is outbound
(from terminal to network) or inbound (from network to terminal), as shown in Figure 13-8. The
frames are 48 bits long, and 36 bits of them represent data. The TE that will start sending frames
has a 2-bit offset compared to the frames it receives from the NT.
At this point, Layer 1 is up. As soon as no valid pair of line code violations is detected in either
direction in two successive ISDN Layer 1 frames, synchronization is lost.
Checking Activation with the show controllers bri and

show isdn status Commands
Figure 13-10 shows the output of the show controllers bri command. This shows the BRI D
channel information and many other internal controller values.
Figure 13-10 You can use the show controllers bri command to view D channel information.
router#show controller bri
BRI unit 0
D Chan Info:
Layer 1 is ACTIVATED
idb 0x9F6E8, ds 0xA56F8, reset_mask 0x8
buffer size 1524
RX ring with 2 entries at 0x2101600 : Rxhead 0
00 pak=0x0AB0A4 ds=0x40CE70 status=D000 pak_size=0
(...)
Figure 13-11 shows the output of the show isdn status command. This shows a very useful
status summary of each of the three ISDN layers. Engineers frequently use this command
during troubleshooting to get the quickest snapshot of the switch type and interface status.
Figure 13-11 You can use the show isdn status command to get a summary of information about Layers 1–3.
router#show isdn status
The current ISDN Switchtype = basic-net3
ISDN BRI0 interface
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
Layer 2 NOT Activated
Layer 3 Status:
No Active Layer 3 Call(s)
Activated dsl 0 CCBs are 0, Allocated = 0
The show dialer Command

The trigger for an ISDN call is DDR. As shown in Figure 13-12, the command show dialer
bri n provides information on the process whereby a Cisco router automatically initiates (and
later closes) a circuit-switched session as transmitting stations demand.
Figure 13-12 For an indication of remote failure, you can use the show dialer command to make sure the remote router
is properly configured.
router#show dialer
Dial String Successes Failures Last called Last status
4155551212 1 0 00:00:00 successful
4155551213 1 0 00:00:00 successful
0 incoming call(s) have been screened.
BRI0: B-Channel 1
BRI0: B-Channel 2
The router spoofs keepalives so that end stations treat the session as active. DDR permits
routing over ISDN or telephone lines using an external ISDN terminal adapter or modem
beyond the BRI interface that you specify.
For an indication of errors in the dialer configuration, check the router configuration,
specifically checking the following configuration commands:
• dialer-list command
• dialer-group command
• dialer map/dialer string command
The show ppp multilink Command

When you troubleshoot BRIs that use Multilink PPP (MLP) or Multilink Multichassis PPP
(MMP), begin with the same command: show ppp multilink. The output contains summary
and configuration information about the bundle or stack groups that have been set up.
BRI channels can aggregate into an MLP bundle for inverse multiplexing, as shown in Figure
13-13. MLP is designed to work over single or multiple interfaces that are configured to support
both dial-on-demand rotary groups and PPP encapsulation.
The Cisco IOS software debug commands featured in this chapter are
• debug bri—Displays information about whether the ISDN code is enabling and disabling
the B channels when you attempt an outgoing call. This command may show intensive
Layer 1 information.
• debug isdn q921—Displays data link layer (Layer 2) access procedures that are taking
place at the router on the D channel (Link Access Procedure on the D channel, or LAPD)
of its interface.
• debug ppp negotiation—Shows information on traffic and exchanges in an internetwork
implementing PPP by displaying fields from packets transmitted during startup, where
PPP options are negotiated.
• debug isdn q931—Displays information about call setup and teardown of ISDN network
connections (Layer 3) between the local router (that is, the user side) and the network.
• debug ppp authentication—Causes the debug ppp command to display authentication
protocol messages, including Challenge Handshake Authentication Protocol (CHAP)
packet exchanges and Password Authentication Protocol (PAP) exchanges.
Output and interpretation of some of the key content of the output of these commands appears
in the following sections.
The debug bri Command

As shown in Figure 13-16, the debug bri command generates a significant amount of output
and should be used only if the router is having trouble communicating with the ISDN switch or
if traffic on the IP network is low, so other activity on the system is not adversely affected.
Figure 13-16 The debug bri command can have lots of data in the output, so use it sparingly.
router# debug bri
BRI: write_sid: wrote 20 for subunit 0, slot 1.
BRI: Starting Power Up timer for unit = 0.
BRI: Starting T3 timer after expiry of PUP timeout for unit = 0, current state is
F4.
BRI: write_sid: wrote FF for subunit 0, slot 1.
BRI: Activation for unit = 0, current state is F7.
BRI: enable channel B1
%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up
%LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to up.!!!
BRI: disable channel B1
%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to down
%LINK-5-CHANGED: Interface BRI0: B-Channel 1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0: B-Channel 1, changed
state to down
The service access point identifier (SAPI) is another key field in the LAPD address. The SAPI
defines the message type. Key SAPIs to look for while troubleshooting are
• SAPI 63—Layer 2 management used for processes including TEI assignment
• SAPI 64—Used for call control
• SAPI 0—Indication that the message type is Layer 3 signaling (from Q.931, covered later
in this chapter)
For Cisco routers, the troubleshooting view of Layer 2 comes primarily from the debug isdn
q921 command.
The LAPD frame format is very similar to that of HDLC. Like HDLC, LAPD uses supervisory,
information, and unnumbered frames. In the frame, the control field indicates which type of
LAPD (HDLC) message is in use. You can associate one or more of these message types with
an ISDN process as you troubleshoot:
• A TEI process uses an unnumbered information frame (UI shown as 0x03) with SAPI 63
and TEI 127 (all ones).
• When a terminal has a TEI, it proceeds to call setup with set asynchronous balanced mode
extended (SABME) that gets an unnumbered acknowledge (UA) if successful or a
disconnect mode (DM) if unsuccessful.
• In user data transfer mode, look for information (INFO) with receiver ready (RR) or reject
(REJ) or receiver not ready (RNR) as key troubleshooting message types to check when
necessary.
The debug isdn q921 Command

Figure 13-19 shows TEI assignment messages from the debug isdn q921 command. TEI 64 is
assigned by the switch when the router powers up.
Figure 13-19 You can use the debug isdn q921 command to view TEI assignment information.
router# debug isdn-q921
2656.612 TX -> IDREQ ri = 14613 ai = 127
2656.648 RX <- IDASSN ri = 14613 ai = 64
....
2424.920 TX -> IDREQ ri = 63529 ai = 127
2426.924 TX -> IDREQ ri = 31418 ai = 127
2428.928 TX -> IDREQ ri = 9819 ai = 127
In the first two lines of the output, the TE sends ID REQ, and the switch answers with ASSN
ID (AI). An IDREQ indicates the identity request message type sent from the local router to
the network during the automatic TEI assignment procedure. This message is sent in an
unnumbered information command frame. AI = 127 asks for any TEI; AI = 64 means TEI 64
is assigned.
After a DISC, the TE and ET must go through the activation and Layer 2 reestablishment
procedures again.
The debug ppp negotiation Command

For B channels on an interface, the BRI interface supports HDLC, PPP, X.25, and Frame Relay
encapsulations. Unless there is a need for a particular encapsulation, PPP encapsulation is
recommended, with CHAP authentication for added security.
The protocol field indicates the upper layer carried in the information field. Examples of
protocol field values are
• 0021—IP
• 0029—AT
• 002B—IPX
• 003D—multilink
• 0201—802.1d hellos
• 0203—SRB BPDU
• 8021—IPCP
• 8029—ATCP
• 802B—IPXCP
• C021—LCP
• C023—PAP
• C025—LQR (link quality report)
• C223—CHAP
The LCP establishes and maintains the B-channel data links and provides a mechanism for
negotiating PPP options. The number types and options that can be negotiated are
• Maximum Receive Unit (MRU)—The MTU size (default 1500 bytes). Not used by Cisco.
• Async Control Character Map—The control and escape characters on async links.
• Authentication Protocol—PAP (0xC023) or CHAP (0xC223) with the default on routers
being no authentication.
• Quality Protocol—The process for data-link monitoring.
• Magic-Number—The technique used for detection of loopback links.
• Reserved (not currently used).
• Protocol Field Compression—The compression of the PPP protocol field.
• Address and Control Field Compression—The compression of the PPP address and
control field.
Figure 13-24 You can use the debug ppp chap authentication command to view call setup procedures. (Continued)
BRI0: B-Channel 1: PPP AUTH CHAP input code = 3 id = 10 len = 4
BRI0: B-Channel 1: Passed CHAP authentication with remote
...
BRI0: B-Channel 1: Unable to authenticate. No name received from peer
BRI0: B-Channel 1: Unable to validate CHAP response. USERNAME bomartin not found.
BRI0: B-Channel 1: Unable to validate CHAP response. No password defined for
USERNAME bomartin
BRI0: B-Channel 1: Failed CHAP authentication with remote.
Remote message is Unknown name
BRI0: B-Channel 1: remote passed CHAP authentication.
BRI0: B-Channel 1: Passed CHAP authentication with remote.
BRI0: B-Channel 1: CHAP input code = 4 id = 3 len = 48
Authenticating an ISDN call can be a key part of Layer 2 B-channel setup for you to
troubleshoot. CHAP is the preferred selection because it provides superior authentication to the
alternative, PAP. CHAP uses a three-way handshake:
1 The local TE station sends a challenge message to the remote peer TE (code 1, challenge).
2 The remote CHAP peer replies with a value using the one-way hash function (code 2,
response).
3 If this value matches the local station’s own calculation, authentication is given a code of
3 (success). If there is no match, the authentication is given a code of 4 (failure).
When you troubleshoot you must make sure that
• The passwords configured on both the local and remote TEs are identical.
• The router name of the remote TE that you configure on the local router is identical to the
remote TE name.
The debug isdn q931 Command

You use the debug isdn q931 command to troubleshoot ISDN Layer 3 Q.931.
First, let’s examine Layer 3 elements. Two Layer 3 specifications are used for ISDN signaling
between the TE and the ET:
• ITU-T I.450 (also known as ITU-T Q.930)
• ITU-T I.451 (also known as ITU-T Q.931)
Together, these protocols support user-to-user, circuit-switched, and packet-switched
connections for the local link’s D channel, as shown in Figure 13-25. These protocols are not
for B channels and do not operate end-to-end.
Summary 525
The dialer map specifies where DDR should dial (for example, an IP address on the called
router that can be reached using a dial string). In Figure 13-37, the access list test permitted
DDR to trigger a call, but the BRI 0 interface cannot perform the dialing operation because
there is no dialer string defined.
Figure 13-37 You can use debug dialer to check configuration for the DDR statements (for example, the dialer string).
router#debug dialer
BRI0: Dialing cause: BRI0: ip PERMIT
BRI0: No dialer string defined. Dialing cannot occur..
Often a configuration has more than one map per destination or several destinations. You should
troubleshoot to make sure that a string is defined and accurately refers to the ISDN destination.
Summary
This chapter focused on how to check the physical connection and line activation and how to
verify that DDR is triggering an ISDN call. This chapter also depicted how to use clear, show,
and debug commands.
You have learned to check the D channel Q.921 and the B channel’s PPP at Layer 2. You have
learned to check the D channel Q.931 and verify the information elements at Layer 3. You also
know that misconfigured SPIDs can prevent call setup.
BSCN.book Page 5 Wednesday, August 1, 2001 1:33 PM
CHAPTER
1
Routing Principles
This chapter covers the principles of routing. Classful and classless routing are reviewed,
as are the differences between distance vector and link-state routing protocol behavior.
Convergence issues surrounding the most commonly used interior routing protocols for the
Internet Protocol (IP) are also presented.
After reading this chapter, you will be able to list the key information routers need to route
data, describe classful and classless routing protocols, compare distance vector and link-
state protocol operation, and describe the use of the fields in a routing table. Finally, given
a preconfigured network, you should be able to discover the topology, analyze the routing
table, and test connectivity using accepted troubleshooting techniques.
Routing Fundamentals
This section reviews routing in general, the requirements for routing, and how routing
decisions are made, including the use of administrative distance and metrics.
Routing Defined
Routing is a relay process in which items are forwarded from one location to another. In
computer networks, user-generated traffic—such as electronic mail or graphic and text
documents—is forwarded from a logical source to a logical destination. Each device in the
network has a logical address so that it can be reached individually; in some cases, devices
can also be reached as part of a larger group of devices.
For a router to act as an effective relay device, it must have knowledge of the logical
topology of the network and be capable of communicating with its neighboring devices. A
router can be configured to recognize several different logical addressing schemes and to
regularly exchange topology information with other devices in the network.
The mechanism of learning and maintaining awareness of the network topology is
considered to be the routing function. The actual movement of transient traffic through the
router, from an inbound interface to an outbound interface, is a separate function and is
considered to be the switching function. A routing device must perform both the routing and
the switching functions to be an effective relay device.
6 Chapter 1: Routing Principles
NOTE Appendix E, “Open System Interconnection (OSI) Reference Model,” contains a review of
the Open System Interconnection (OSI) reference model. Under this reference model, a
router is an OSI Layer 3 device that has an understanding of the logical topology of the
network. The routing and switching functions described here refer to the forwarding of a
Layer 3 protocol data unit (PDU), also referred to as a packet (or datagram). A packet
contains a logical source and a logical destination address that the routing device interprets
during the packet forwarding process.
Routing Requirements
A router must know three items in order to route:
• The router must determine whether it has the protocol suite active.
• The router must know the destination network.
• The router must know which outbound interface is the best path to the destination.
For a routing device to make a routing decision, it must first understand the logical
destination address. For this to happen, the protocol suite that uses that logical addressing
scheme must be enabled and currently active on the router. Some examples of common
protocol suites are Transmission Control Protocol/Internet Protocol (TCP/IP), Internetwork
Packet Exchange (IPX), and Digital Equipment Corporation’s DECnet.
After the router can understand the addressing scheme, the second decision is to determine
whether the destination logical network is a valid destination within the current routing
table. If the destination logical network does not exist in the routing table, routing devices
might be programmed to discard the packet and to generate an error message (for example,
an IP Internet Control Message Protocol [ICMP] message) to notify the sender of the event.
Some network managers have successfully reduced the size of their network’s routing
tables by including only a few destination networks and then specifying a default route
entry. If specified, a default route will be followed if the destination logical network is not
included as part of the device’s routing table.
The final decision that the routing device must make if the destination network is in the
routing table is to determine through which outbound interface the packet will be
forwarded. The routing table will contain only the best path (or paths) to any given
destination logical network. The best path to a destination network will be associated with
a particular outbound interface by the routing protocol process. Routing protocols use a
metric to determine the best path to a destination. A smaller metric indicates a preferred
path; if two or more paths have an equal lowest metric, then all those paths will be equally
shared. Sharing packet traffic across multiple paths is referred to as load balancing to the
destination. When the outbound interface is known, the router must also have an
encapsulation method (in other words, a Layer 2 frame type) to use when forwarding the
packet to the next-hop logical device in the relay path.
Routing Fundamentals 7
Routing Information
The information required to perform the routing operation is included in the router’s routing
table and is generated by one or more routing protocol processes. The routing table is
composed of multiple entries, each of which indicates the following:
• The mechanism by which the route was learned. Learning methods can be either
dynamic or manual.
• The logical destination, either a major network or a subnetwork (also called a subnet)
of a major network. In isolated cases, host addresses may be contained in the routing
table.
• The administrative distance, which is a measure of the trustworthiness of the learning
mechanism. Administrative distance is discussed further in the next section,
“Administrative Distance.”
• The metric, which is a measure of the aggregate path “cost,” as defined by the routing
protocol. Routing metrics are discussed further in the section “Routing Metric,” later
in this chapter.
• The address of the next-hop relay device (router) in the path to the destination.
• How current the information about the route is. This field indicates the amount of time
the information has been in the routing table since the last update. Depending on the
routing protocol in use, route entry information may be refreshed periodically to
ensure that it is current.
• The interface associated with reaching the destination network. This is the port
through which the packet will leave the router and be forwarded to the next-hop relay
device.
Example 1-1 shows a sample line in an IP routing table on a router. Table 1-1 shows how
the information in the shaded sample line in Example 1-1 is interpreted.
Example 1-1 A Routing Table Shows the Metric and the Next-Hop Router for Each Network
RouterA#show ip route
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
T - traffic engineered route
Gateway of last resort is not set
172.16.0.0/16 is subnetted, 2 subnets

I 172.16.8.0 [100/118654] via 172.16.7.9, 00:00:23, Serial0
<output omitted>
Table 1-1 Interpretation of Routing Table Components in Example 1-1

Routing Table Entry
Component Description
I How the route was learned—in this case, by the Interior Gateway
Routing Protocol (IGRP).
The other codes possible for this component are shown in the
“Codes” legend in Example 1-1.
172.16.8.0 Destination logical network/subnet.
[100 Administrative distance (trustworthiness factor) of IGRP.
/118654] Metric value (reachability); by default for IGRP, this is a combination
of the bandwidth and delay.
via 172.16.7.9 Next-hop logical address (the next router).
00:00:23 Age of entry (in hours: minutes: seconds) since the last update.
Serial0 Interface through which the route was learned and through which
packets for the destination will leave.
Administrative Distance
The routing process is responsible for selecting the best path to any destination network.
Because more than one learning mechanism can exist on a router at any given time, a
method to choose between routes is needed when the same route is learned from multiple
sources. For IP within a Cisco router, the concept of an administrative distance is used as
a selection method for IP routing protocols.
Administrative distance is used as a measure of the trustworthiness of the source of the IP
routing information. It is important only when a router learns about a destination route from
more than one source.
Lower values of administrative distance are preferred over higher values. In general, default
administrative distances have been assigned with a preference for manual entries over
dynamically learned entries, and routing protocols with more sophisticated metrics over
routing protocols with simple metrics. A comparison chart of the default administrative
distances is presented in Table 1-2.
Table 1-2 Default Administrative Distances of Sources of Routes
Route Source Default Administrative Distance
Connected interface 0
Static route out an interface 0
Static route to a next hop 1
EIGRP summary route 5
Table 1-2 Default Administrative Distances of Sources of Routes (Continued)

Route Source Default Administrative Distance
External BGP 20
Internal EIGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP (v1 and v2) 120
EGP 140
External EIGRP 170
Internal BGP 200
Unknown 255
EIGRP Summary Routes

Enhanced Interior Gateway Routing Protocol (EIGRP) summary routes with an
administrative distance of 5 exist, but they are not visible in the routing table except on the
router that configured the summary address. These routes can be viewed using the show ip
route network command for the specific summarized network. EIGRP is discussed in detail
in Chapter 5, “Configuring EIGRP.”
Routing Metric
In a routed network, the routing process relies on the routing protocol to maintain a loop-
free topology and to locate the best path to every destination network.
The definition of what is the best path to any destination is one feature that distinguishes
different routing protocols. Each routing protocol uses a different measurement for what is
best. Routers advertise the path to a network in terms of a metric value. Some common
examples of metrics are hop count (how many routers to pass through), cost (based on
bandwidth), and a composite value (using several parameters in the calculation). If the
destination network is not local to a router, then the path is represented by the sum of the
metric values defined for all the links that must be traversed from the router to reach that
network.
When the routing process knows the metric values associated with the different paths
(assuming that multiple paths exist), then the routing decision can be made. The routing
process will select the path that has the smallest metric value. In Cisco routers, if multiple
lowest equal metric paths exist in an IP environment, then load sharing (also known as load
balancing) will be in effect across the multiple paths. For IP, Cisco supports by default four
equal metric paths to a common destination network. A maximum of six equal metric paths
can be configured in the Cisco Internetwork Operating System (IOS) by using the
maximum-paths router configuration command.
The next two sections review the Routing Information Protocol (RIP) and IGRP routing
metrics.
RIP Routing Metrics

RIP is a commonly used routing protocol in small- to medium-sized TCP/IP networks. RIP
uses hop count as a metric, equal to the number of neighboring routers that must be passed
through to reach the destination. In the topology shown in Figure 1-1, traditional RIP
implementations would cause Router A to arbitrarily choose one path to reach network
192.168.10.0, and only the selected path would be displayed in the routing table.
Figure 1-1 An Example Network Using the RIP Routing Protocol
192.168.5.0
.2
Router A
.1 Token
.3 Ring
192.168.4.0
192.168.10.0
FDDI
.4
C 192.168.5.0 dir conn Eth0

C 192.168.4.0 dir conn Ser0
R 192.168.10.0 [120/4] via 192.168.5.2, Eth0
via 192.168.5.3, Eth0
via 192.168.5.4, Eth0
However, in Cisco routers, the RIP implementation is such that multiple equal hop paths
can be shared because load balancing is on by default. In Figure 1-1, notice that Router A
can reach network 192.168.10.0 using three different paths that have an equal hop count.
As a result of the equal metric, all three paths will be displayed in the routing table as the
lowest metric path. Remember that even though the three paths in Figure 1-1 are of different
bandwidths, RIP does not consider bandwidth in its best path decision.
NOTE The example topologies in this book are for demonstration purposes only and do not
necessarily represent optimal network design.
IGRP Routing Metrics

Cisco’s IGRP is a commonly used routing protocol in medium- to large-sized TCP/IP
networks. IGRP uses a composite metric, based upon bandwidth, delay, reliability, load,
and maximum transmission unit (MTU). In the IGRP standard algorithm computation, only
the bandwidth and delay values are enabled by default. (Refer to the “IGRP Metric
Calculation” sidebar later in this section for a description of the IGRP metric calculation.)
The IGRP composite metric can distinguish subtle differences in link characteristics, and
therefore will select the highest-bandwidth (fastest) path to the destination network. In
Figure 1-2, Router A selects only one path to network 192.168.10.0; this is the Fiber
Distributed Data Interface (FDDI) path because the 100 megabits per second (Mbps)
bandwidth is higher than the other available paths. If equal-metric (at least, equal within 1
percent) paths exist, load balancing will be in effect.
Figure 1-2 An Example Network Using the IGRP Routing Protocol
192.168.5.0
.2
Router A
.1 Token
.3 Ring
192.168.4.0
192.168.10.0
FDDI
.4
C 192.168.5.0 dir conn Eth0

C 192.168.4.0 dir conn Ser0
I 192.168.10.0 [100/327684] via 192.168.5.4, Eth0
IGRP is also capable of load balancing across unequal-cost paths, within a specified
variance. This capability is also part of the EIGRP protocol and is discussed further in
Chapter 5.
IGRP Metric Calculation

IGRP calculates the metric by adding weighted values of different characteristics of the link
to a destination network. The formula used is as follows:
Metric = (K1 × bandwidth) + [(K2 × bandwidth) ÷ (256 – load)] + (K3 × delay)
If K5 does not equal 0, then an additional operation is done:
Metric = Metric × (K5 ÷ [reliability + K4])
The K values in these formulas are constants that can be defined using the metric weights
router configuration command. The weights are attributed to the variables as follows: K1 =
bandwidth, K2 = load, K3 = delay, K4 = reliability, and K5 = MTU. (Load is the worst load
on the link between source and destination and is expressed in bits per second.) The default
constant values are K1 = K3 = 1 and K2 = K4 = K5 = 0, so by default the formula is:
Metric = bandwidth + delay
To determine the bandwidth that is used in this calculation, find the smallest of all the
bandwidths from the outgoing interfaces along the path to the destination, in kilobits per
second (kbps), and divide 10,000,000 by that number. Note that bandwidth given in the
Cisco IOS show interfaces command is in kilobits per second.
To determine the delay that is used in this calculation, add all the delays from the outgoing
interfaces along the path to the destination, in microseconds, and divide this number by 10.
Note that the delay given in the Cisco IOS show interfaces command is in microseconds.
Figure 1-3 presents a sample network to illustrate the IGRP metric calculation.
Figure 1-3 Network for IGRP Metric Calculation Example
10.2.2.0/24 10.1.1.0/24
.1 .1
.2 .2
S0 S2
S0 S0
Router A Router B Router C
128 kbps, 1544 kbps,

20000 microseconds 20000 microseconds
In Figure 1-3, Router B advertises network 10.1.1.0 to Router A. The metric that Router B
advertises for 10.1.1.0 is calculated as follows:
Bandwidth = 10,000,000 ÷ 1544 = 6476
Delay = 20,000 ÷ 10 = 2000
Metric = Bandwidth + Delay = 8476
Router A will calculate the metric that it puts in its routing table for 10.1.1.0 as follows:
Bandwidth = 10,000,000 ÷ 128 = 78,125 (using the minimum bandwidth in the path—
in this case, 128 kbps)
Delay = (20,000 + 20,000) ÷ 10 = 4000
Metric = Bandwidth + Delay = 82,125
(This information was adapted from www.cisco.com/warp/public/103/3.html.)
Neighbor Relationships
The concept of routing is based upon a relay system. Traffic is relayed from one routing
device to the next until the destination is reached. The next-hop logical address required for
delivery is shown in the routing table (as the via address). This information is discovered
when a neighboring router advertises the route. This section discusses how routers
communicate with their neighboring routers.
Immediately after a router starts up, it attempts to establish a routing relationship with
neighboring routing devices. The purpose of this initial communication is to identify the
neighboring devices and to begin communicating and learning the network topology. The
method of establishing neighbor relationships and the initial learning of the topology vary
among different routing protocols. Often broadcast frames are used to send to the
neighboring devices, especially until the Layer 2 addresses of the adjacent devices (for
example, the addresses of the network interface cards [NICs]) are learned.
The routing process within the routing protocol establishes a peer relationship with the
neighboring routers at the software (upper) layers of the OSI reference model. Different
routing protocols exist at different upper layers of the OSI reference model (Layers 4
through 7). The routing protocol exchanges either periodic hello messages or periodic
routing updates to maintain the ongoing communication between the neighbors.
When the network topology is understood and the routing table contains the best path to
known destination networks, traffic forwarding to those destinations can begin. As
discussed earlier, the function of forwarding transient packets by the router is referred to as
switching.
Figure 1-4 summarizes the switching operation performed by the router.
The switching function is all about moving data through the router. The switching function
relies on Layer 2 (ARP or equivalent information) and Layer 3 (routing information)
lookup tables. If these tables have the necessary information, then traffic forwarding can be
accomplished in an efficient manner. Incomplete tables will cause delays or will result in
an incapability to forward traffic to the next-hop device.
The switching function needs the end result of the routing function, which is a routing table
entry that points to the destination logical network. The switching function has four basic
steps, as indicated in Figure 1-4:
1 A packet transiting the router will be accepted into the router if the frame header (of
the frame in which the packet resides) contains the Layer 2 address of one of the
router’s interfaces, or the broadcast address, or multicast address that the router is
configured to accept. If properly addressed, when the framing is checked, the frame
content (the packet) will be buffered pending further processing. The buffering occurs
in main memory or some other specialized memory location.
Figure 1-4 A Router Performs Basic Switching Functions
Check framing and

1
buffer packet = Inbound
interface
Associate destination logical

address with next-hop Routing Maintained by
2 logical device and = table routing protocol*
outbound interface
Associate next-hop logical ARP Map Maintained by

3 device with physical address
to create frame header
= cache
(LAN)
table ARP or Inverse
(WAN) ARP process*
Encapsulate packet Outbound

4
and forward frame = interface
*Manual entries available
2 The router checks the destination logical network portion of the packet header against
the network and subnetwork entries in the routing table. If there is a match, the
destination network is associated with a next-hop logical device and an outbound
interface.
3 After the next-hop logical device address is known, a lookup is performed to locate a
physical address (the Layer 2 address) of the next-hop device. The lookup is
performed in an Address Resolution Protocol (ARP) table for local-area network
(LAN) interfaces, or a map table for wide-area network (WAN) interfaces. The
contents of these tables can be created either dynamically or manually.
4 After the physical address of the next-hop device is known, the appropriate frame
header is created in the router memory. (For IP packets, the router will also modify
the IP header by decrementing the Time To Live [TTL] field and updating the IP
header checksum.) After the frame header is created, the frame is moved to the
outbound interface for transmission onto the media. As the frame is placed on the
media, the outbound interface adds the cyclic redundancy check (CRC) character and
ending delimiters to the frame. These characters will be validated at the arriving
interface on the next-hop relay device.
Routing Protocols 15
Time To Live Field in IP Packets

The TTL field of the IP header is defined to be a timer limiting the lifetime of an IP packet.
It is an 8-bit field, and the units are seconds. Each router that handles a packet must
decrement the TTL by at least 1, even if the elapsed time was much less than a second.
Because this is very often the case, the TTL is effectively a hop count limit on how far a
packet can propagate through a network.
When a router forwards a packet, it must reduce the TTL by at least 1. If it holds a packet
for more than 1 second, it may decrement the TTL by 1 for each second.
If the TTL is reduced to zero (or less), the packet must be discarded, and if the destination
is not a multicast address, the router must send an ICMP Time Exceeded message, Code 0
(TTL Exceeded in Transit) message to the source. Note that a router must not discard an IP
unicast or broadcast packet with a nonzero TTL merely because it can predict that another
router on the path to the packet’s final destination will decrement the TTL to zero. However,
a router may do so for IP multicasts.
Thus, you can see that the IP TTL is used as both a hop count limit and a time limit. Its hop
count function is critical to ensuring that routing problems won’t cause packets to loop
infinitely in the network. The time limit function is used by transport protocols such as TCP
to ensure reliable data transfer. Many current implementations treat TTL as a pure hop
count, and in parts of the Internet community, there is a strong sentiment that the time limit
function should instead be performed by the transport protocols that need it.
The RFC 1812 specification allows the time limit function to be optional. Most router
vendors argued that implementation of the time limit function is difficult enough that it is
currently not generally done.
(This information was adapted from RFC 1812, available at www.cis.ohio-state.edu/htbin/
rfc/rfc1812.html.)
Routing Protocols
There are many ways to categorize routing protocols. The following sections discuss two
such categories—classful versus classless, and distance vector versus link-state. Each of
these terms is defined, and examples are provided. Note that some routing protocols have
characteristics that cross over category boundaries.
Classful Routing Overview

Routing protocols that do not send subnet mask information along with each network
address are known as classful routing protocols; RIP version 1 (RIPv1) and IGRP are
classful routing protocols.
When using a classful routing protocol, all subnets of the same major (Class A, B, or C)
network number must use the same subnet mask. Upon receiving a routing update packet,
a router running a classful routing protocol does one of the following to determine the
network portion of the route:
• If the routing update information is about the same major network number
as configured on the receiving interface, the router applies the subnet mask that is
configured on the receiving interface.
• If the routing update information is about a different major network as configured on
the receiving interface, the router will apply the default (by address class) subnet
mask.
NOTE You may see the term routing mask used instead of subnet mask. A routing mask refers to
the mask that defines the network portion of an IP address. A routing mask encompasses
both natural (default) masks and subnet masks. The terms routing mask and subnet mask
are interchangeable in this book.
Classful Routes
Classful routing protocols, such as RIPv1 and IGRP, exchange routes to subnetworks
within the same major (Class A, B, or C) network. This is possible because all the
subnetworks in the major network should have the same subnet mask; the network
administrators must enforce the use of consistent masks.
When routes are exchanged with foreign networks (in other words, with different major
networks), receiving routers will not know the subnet mask in use because subnet masks
are not included in the routing updates. As a result, the subnetwork information from each
major network must be summarized to a classful boundary, using the default classful mask,
before inclusion in the routing update. Thus, only routers configured to participate in the
major network to which the subnets belong exchange subnet routes; routers that participate
in different major networks exchange classful summary routes. The creation of a classful
summary route at major network boundaries is handled automatically by classful routing
protocols. Summarization at other bit positions within the major network address is not
allowed by classful routing protocols.
This automatic summarization is illustrated in Figure 1-5. As shown in Figure 1-5, devices
within the same major network share subnetwork routes, while only classful summary
routes are exchanged between foreign networks. The classful summary routes are
automatically created at Class A, B, and C network boundaries by routers running a classful
routing protocol.
Figure 1-5 An Example Network Showing the Routing Tables of Routers Running a Classful Routing Protocol
10.1.0.0 10.2.0.0 172.16.2.0 172.16.1.0
Routing table Routing table Routing table

10.1.0.0 10.1.0.0 10.0.0.0
10.2.0.0 10.2.0.0 172.16.1.0
172.16.0.0 172.16.1.0 172.16.2.0
172.16.2.0
Another example is shown in Figure 1-6. In Figure 1-6, the routers are running RIPv1.
Router B is attached to network 172.16.1.0/24 on its left interface. Therefore, if Router B
learns about any network on this interface that is also a subnet of the 172.16.0.0 network,
it will apply the subnet mask configured on its receiving interface (/24) to that learned
network. Router B summarizes the routing information about the 172.16.0.0 network when
sending it to Router C because it is sent over an interface in a different major network
(the 192.168.5.16/28 network). Notice how Router C, which is attached to Router B via
the 192.168.5.16/28 network, handles routing information about network 172.16.0.0.
Rather than using the subnet mask that Router B knows about (/24), Router C applies the
default (classful) subnet mask for a Class B address (/16) when it receives information
about 172.16.0.0.
Figure 1-6 An Example Network Showing That Routers Running RIPv1 Do Not Pass Subnet Mask Information
to Their Neighbors
RIPv1 network
172.16.2.0/24 172.16.1.0/24 192.168.5.16/28
172.16.2.0 172.16.0.0
Routing table
172.16.0.0/16
Routing table Routing table 192.168.5.16/28
172.16.1.0/24 172.16.1.0/24
172.16.2.0/24 172.16.2.0/24
192.168.5.0/24 192.168.5.16/28
Classful Subnetting Requirements

When performing subnetting in conjunction with a classful routing protocol, care must be
taken to assign the same subnet mask to all router interfaces on all routers in the same major
network within the classful routing domain. This consistency is a requirement for
subnetwork routes to be advertised correctly.
This requirement has a potential downside from the standpoint of efficient address
allocation. For example, as shown in Figure 1-7, while a 27-bit mask allocates the proper
number of host addresses (30 addresses) for each Ethernet segment, not all of the 30
addresses can be utilized on the point-to-point serial link.
Figure 1-7 Routers Running a Classful Routing Protocol Must Use the Same Mask on All Interfaces
192.168.5.129/27
A requirement for only
two host addresses— E0
forced to allocate 30
host addresses
S1
192.168.5.98/27
S0
192.168.5.97/27
192.168.5.33/27 E0 E1 192.168.5.65/27
The next section describes classless routing, which overcomes some of the classful protocol
restrictions.
Classless Routing Overview

Classless routing protocols can be considered as second-generation protocols because they
are designed to deal with some of the limitations of the earlier classful protocols. Classless
routing protocols include Open Shortest Path First (OSPF), EIGRP, RIP version 2 (RIPv2),
Intermediate System-to-Intermediate System (IS-IS), and the Border Gateway Protocol
version 4 (BGP-4).
One of the most serious limitations in a classful network environment is that the subnet
mask is not exchanged during the routing update process. This approach requires the same
mask to be used on all subnetworks of a major network. The classless approach advertises
the subnet mask for each route, so a more precise (sophisticated) lookup can be performed
in the routing table.
Classless routing protocols also address another limitation of classful routing protocols: the
automatic summarization to a classful network with a default classful subnet mask at major
network boundaries. In the classless environment, the summarization process is manually
controlled and can usually be invoked at any bit position within the network. (As you will
see in Chapter 4, “Interconnecting Multiple OSPF Areas,” hierarchical designs using OSPF
allow summarization at any bit position but restrict configuring summarization to specific
routers in the network.) Because subnet routes are propagated throughout the routing
domain, summarization is often required to keep the routing tables at a manageable size.
In the OSPF network in Figure 1-8, Router B passes the subnet and subnet mask
information to Router C; Router C puts the subnet details into its routing table. Router C
does not have to use any default masks for the received routing information.
Figure 1-8 An Example Network Showing That Routers Running OSPF Pass Subnet Mask Information to Their
Neighbors
OSPF network
Routing table Routing table Routing table

172.16.2.0/24 172.16.2.0/24 172.16.2.0/24
172.16.1.0/24 172.16.1.0/24 172.16.1.0/24
192.168.5.16/28 192.168.5.16/28 192.168.5.16/28

172.16.2.0/24 172.16.1.0/24 192.168.5.16/28
172.16.2.0/24 172.16.2.0/24
172.16.1.0/24
Classless Subnetting Requirement

Recall that another limitation of classful routing protocols is the requirement for a
consistent mask to be applied to all router interfaces within the major network. This strict
classful approach results in inefficient utilization of host addresses.
Classless routing protocols understand that different routes within a major network can
have different masks. The use of different masks within a major network is referred to as
variable-length subnet masking (VLSM). Classless routing protocols support VLSM, and
that, in turn, leads to more efficient allocation of subnet masks to meet different host
requirements on different subnetworks, resulting in better utilization of host addresses. In
Figure 1-9, the serial link has been configured with a subnet mask that properly supports
the link requirement for only two host addresses (a mask of 255.255.255.252, which
corresponds to a prefix length of 30). The Ethernet links can use a mask appropriate for the
number of hosts attached—in this case, 255.255.255.224 (which corresponds to a prefix
length of 27).
Figure 1-9 Routers Running a Classless Routing Protocol May Use Different IP Address Masks
192.168.5.129/27
A requirement for only
two host addresses— E0
VLSM support
accommodates this
S1
192.168.5.209/30
S0
192.168.5.210/30
192.168.5.33/27 E0 E1 192.168.5.65/27
The next two sections describe another way to categorize routing protocols—distance
vector versus link-state. The following sections also discuss differences between distance
vector and link-state protocols and how they relate to the classful and classless categories.
Distance Vector Operation

The periodic, routine routing updates generated by most distance vector routing protocols
go only to directly connected routing devices. The addressing most commonly used by
devices sending updates is a logical broadcast, although in some cases, unicast updates can
be specified.
In a pure distance vector environment, the routing update includes a complete routing table,
as shown in Figure 1-10. By receiving a neighbor’s full table, a router can verify all the
known routes and then make changes to the local table based upon the received updated
information; this process is easy to understand. A router’s understanding of the network is
based upon the neighbor’s perspective of the network topology; thus, the distance vector
approach to routing is sometimes referred to as “routing by rumor.”
Figure 1-10 Pure Distance Vector Routing Protocols Send Their Entire Routing Table
Routing table
All
routes
The Cisco IOS supports several distance vector routing protocols, including RIPv1, RIPv2,
and IGRP. Cisco routers also support EIGRP, an advanced distance vector protocol, which
is discussed in detail in Chapter 5.
Traditionally, distance vector protocols were also classful protocols. RIPv2 and EIGRP are
examples of more advanced distance vector protocols that exhibit classless behavior.
EIGRP also exhibits some link-state characteristics, as discussed in the next section.
Routing protocols are commonly associated with the network layer of a protocol suite.
However, routing protocols use the network layer delivery mechanism to exchange routing
information, but the routing protocol process itself does not exist at the network layer.
Figure 1-11 shows the location of the IP distance vector routing protocols within the OSI
reference model.
Figure 1-11 Distance Vector Routing Traffic Is Carried Within IP Packets
520 - RIP
9 - IGRP 69 - TFTP
6 - TCP 53 - DNS
17 - UDP 161 - SNMP
Frame payload
Packet payload C
Frame
IP Protocol R
header UDP Port Segment
header number C
header no. payload
As shown in Figure 1-11, IGRP resides at the transport layer, as protocol 9. Some other
recognizable protocol numbers are 6 and 17, for TCP and the User Datagram Protocol
(UDP), respectively. RIP resides at the application layer and has a UDP port number of 520.
Some other well-known UDP port numbers are port 53 for Domain Name Server (DNS),
port 69 for Trivial File Transfer Protocol (TFTP), and port 161 for Simple Network
Management Protocol (SNMP).
Table 1-3 compares the characteristics of the different distance vector routing protocols
supported on Cisco routers. Most distance vector routing protocols use the Bellman-Ford
algorithm for route calculation. EIGRP is an advanced distance vector protocol and uses the
Diffusing Update Algorithm (DUAL).
Table 1-3 Comparison of Cisco’s IP Distance Vector Routing Protocols

Characteristic RIPv1 RIPv2 IGRP EIGRP
Count to infinity X X X
Split horizon X X X X
Holddown timer X X X
Triggered updates with X X X X
route poisoning
Load balancing—equal X X X X
paths
Load balancing—unequal X X
paths
VLSM support X X
Routing algorithm Bellman-Ford Bellman-Ford Bellman-Ford DUAL
Metric Hops Hops Composite Composite
Hop count limit 15 15 100 100
Scalability Small Small Medium Large
NOTE Some routing protocol features, such as split horizon, holddown time, and hop-count limit,
are configurable for some routing protocols.
The hop-count limit for IGRP and EIGRP defaults to 100 but is configurable up to a
maximum of 255 hops.
Link-State Operation
Link-state routing protocols generate routing updates only when there is a change in the
topology. When a link changes state, the device that detects the change creates a link-state
advertisement (LSA) concerning that link (route); the LSA is then propagated to all
neighboring devices using a special multicast address. Each routing device takes a copy of the
LSA, forwards the LSA to all neighboring devices (this process is called flooding), and then
updates its topological database (a table containing all the link-state information for the
network). This flooding of the LSA is required to ensure that all routing devices learn about
the change so that they can update their databases and create an updated routing table that
reflects the new topology.
Most link-state routing protocols require a hierarchical design. The hierarchical approach,
such as creating multiple logical areas for OSPF, reduces the need to flood an LSA to all
devices in the routing domain because the use of areas restricts the flooding to the logical
boundary of the area rather than to all devices in the OSPF domain. In other words, a change
in one area should cause routing table recalculation only in that area, not in the entire
domain.
Table 1-4 compares some of the characteristics exhibited by link-state routing protocols.
Note that EIGRP is technically an advanced distance vector protocol, but it demonstrates
some link-state features. Also, IS-IS is shown for comparison purposes only and is not
covered further in this book.
Table 1-4 Comparison of Cisco’s IP Link-State Routing Protocols
Characteristic OSPF IS-IS EIGRP
Hierarchical topology— X X
required
Retains knowledge of all X X X
possible routes
Route summarization—manual X X X
Route summarization— X
automatic
Event-triggered announcements X X X
Load balancing—equal paths X X X
Load balancing—unequal paths X
VLSM support X X X
Routing algorithm Dijkstra IS-IS DUAL
Metric Cost Cost Composite
Hop-count limit Unlimited 1024 100
Scalability Large Very large Large
NOTE OSPF uses the Dijkstra algorithm, also called the shortest path first (SPF) algorithm.
EIGRP uses the DUAL algorithm in its route calculations. OSPF is covered in detail in
Chapter 3, “Configuring OSPF in a Single Area,” and Chapter 4. EIGRP is covered in detail
in Chapter 5.
IS-IS is the routing algorithm used by the International Organization for Standardization
(ISO) protocol suite, which includes Connectionless Network Service (CLNS). The IS-IS
protocol is not covered further in this book; introductory and configuration information is
available at the following URLs:
• www.cisco.com/cpress/cc/td/cpress/fund/ith2nd/it2441.htm
• www.cisco.com/univercd/cc/td/doc/product/software/ios100/rpcg/
66010.htm#xtocid2841339
Convergence
This section describes how different routing protocols converge after a change in network
topology. In a routed network, the routing process in each router must maintain a loop-free,
single path to each possible destination logical network. When all the routing tables are
synchronized and each contains a usable route to each destination network, the network is
converged. Convergence is the activity associated with making the routing tables synch-
ronized after a topology change occurs, such as new routes being added or existing routes
changing state. Convergence efforts are different within different routing protocols, and the
default timers used within the same routing protocol can vary by vendor implementation.
Convergence time is the time it takes for all routers in a network to agree on the current
topology. Convergence time can be affected by the size of the network, the routing protocol
in use, and numerous configurable timers.
One critical piece of information when measuring convergence time is how the link change
was detected. Using the OSI reference model as a guideline, there are at least two different
detection methods:
• When the physical or data link layer (for example, a NIC on a LAN) fails to receive
some number (typically three) of consecutive keepalive messages, the link is
considered to be down.
• When the routing protocol fails to receive some number (typically three) of
consecutive hello messages or routing updates (or similar messages), the link is
considered to be down.
After the detection method is understood, factors associated with routing protocol
operation come into play. Most routing protocols have timers that prevent topological loops
from forming during periods of link transition. For example, when a distance vector route
is suspect, it is placed in holddown, and no new routing information about that route will
be accepted until the holddown timer expires (unless the new routing information has a
metric that is better than the original metric). This approach gives the network topology an
opportunity to stabilize before new route calculations are performed. Unfortunately, a
network cannot converge more rapidly than the duration of the holddown timer. In another
example, a router running OSPF has a built-in delay, an amount of time it will wait before
recalculating the routing table after it learns of a change. This delay exists so that multiple
changes can be recalculated at the same time. This feature helps reduce the CPU overhead
of performing multiple SPF recalculations within a short period of time, which can be
caused by a flapping route (a route that is going down and up quickly).
In addition to timer values, other factors such as the size of the network, the efficiency of
the routing algorithm, and how the failure information is radiated all affect convergence
time. The following sections show how an example network would converge when running
different routing protocols.
Figure 1-12 shows the network used in all the following convergence examples.
Figure 1-12 Network Used to Show How Different Routing Protocols Converge After a Link Failure
Router B
S0: S1:
1.3.0.1 1.2.0.2
S0:
1.2.0.1
S1:
Router E Router D 1.3.0.2 Router C Router A
E0:
E0: E0: S1: E0: 1.1.0.2
1.4.0.2 S0:
1.5.0.2 1.5.0.1 1.4.0.1 1.1.0.1
All S1 are DCE; clockrate = 64000
RIP Convergence
The sequence of events for RIP convergence when Router C in Figure 1-12 detects the
failure of network 1.1.0.0 is as follows:
1 Router C detects the link failure on the Ethernet between Routers A and C. Router C
sends a flash update (an update that is sent when a change occurs rather than at the
normal periodic interval), including a poisoned route (a route with an unreachable
metric—in RIP’s case, a hop count of 16), to Routers B and D. Router D creates a new
flash update and sends it to Router E. Router C purges the entry for the directly
connected down link in its routing table and also removes all routes associated with
that link from its routing table.
2 Router C sends a query to its neighbors, using the broadcast address
(255.255.255.255) for RIPv1 or a multicast address (224.0.0.9) for RIPv2, looking for
an alternate path to network 1.1.0.0.
3 Router D responds with a poisoned route to network 1.1.0.0 (this is the poison reverse
feature operating), and Router B responds with a route to network 1.1.0.0 with a
weaker metric. Router C immediately installs the route from Router B in the routing
table. Note that Router C does not go into holddown because the entry was already
purged from its routing table.
NOTE Because of the split horizon rule, Router D normally will not send routing updates about
network 1.1.0.0 to Router C. However, poison reverse updates override the split horizon
rule.
4 Router D goes into holddown for the failed route. When Router C makes its periodic
advertisement that the route is available with a weaker metric, Router D ignores the
route because it is in holddown. (During holddown, routes with the same metric or a
worse metric than a router originally had for a network are ignored.) Router D
continues to send a poisoned route to Router C in Router D’s updates.
5 As Routers D and E come out of holddown, the new route announced by Router C
causes their routing table entries to be updated.
NOTE The default update time for RIP is 30 seconds, and the default holddown time for RIP is
180 seconds.
From Router E’s perspective, the convergence time is the total of detection time, plus the
holddown time, plus one update time (Router D to Router E), plus one partial or full update
time. The actual time to converge at Router E could exceed 210 seconds (3 1/2 minutes).
RIP Convergence Testing Details

During testing of RIP convergence, some other interesting characteristics were observed,
including these:
— Routers add the metric (the hop count) for the link to the metric in their table
before sending out the update. For example, Router D sends updates about
network 1.3.0.0 to Router E with a hop count of 2, not 1. The metric that
Router D sends to Router E has itself included as a hop already.
— Flash updates are full routing tables, not just what has changed.
— Replies to queries are also full routing tables.
IGRP Convergence
The sequence of events for IGRP convergence when Router C in Figure 1-12 detects the
sends a flash update with a poisoned route to Routers B and D. For IGRP, a poisoned
route has an unreachable metric of 4,294,967,295. Router D creates a new flash
update and sends it to Router E. Router C purges the entry for the directly connected
down link from its routing table and also removes all routes associated with that link
from its routing table.
2 Router C sends a query to its neighbors using the broadcast address
(255.255.255.255), looking for an alternate path to network 1.1.0.0. (Note that Router
C tries to send this query out all its interfaces, including the one that is down.) Router
D responds with a poisoned route (this is the poison reverse feature operating), and
Router C sends (out all interfaces) a flash update without the failed link entry.
NOTE Because of the split horizon rule, Router D normally will not send routing updates about
network 1.1.0.0 to Router C. Poison reverse updates, however, override the split horizon
rule.
3 Router B responds with a route to network 1.1.0.0 with a weaker metric. The route
from Router B is immediately installed in Router C’s routing table. Router C does not
go into holddown because the entry was already purged. Router C sends a flash update
with the new route information out all interfaces.
4 Router D is in holddown for the failed route. When Router C makes its flash
advertisement that the route is available with a weaker metric, Router D ignores the
route because it is in holddown. (During holddown, routes with the same metric or a
worse metric than a router originally had for a network are ignored.) Router D
continues to send a poisoned route to Router C in Router D’s updates.
5 As Routers D and E come out of holddown, the new route announced by Router C
causes their routing table entries to be updated.
NOTE The default update time for IGRP is 90 seconds, and the default holddown time for IGRP
is 280 seconds.
From Router E’s perspective, convergence time is the total of detection time, plus holddown
time, plus one update time (Router D to Router E), plus one partial or full update time. The
actual time to converge at Router E could exceed 400 seconds (almost 7 minutes).
IGRP Convergence Testing Details

During testing of IGRP convergence, the debug ip routing and debug ip igrp transactions
command outputs shown in Example 1-3 was obtained from routers C and D in Figure 1-
12. Note that comment lines (starting with a ! character) have been added to the output in
Example 1-3 and that some of the debug output has been omitted. The shaded lines in
Example 1-3 highlight some of the more important events and information for
understanding how IGRP converges.
Example 1-3 Example Debug Output on Routers C and D in Figure 1-12 When Running IGRP
C#
!this is output from Router C
20:43:09: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state
to down
20:43:09: IGRP: edition is now 3
!this is a flash update
20:43:09: IGRP: sending update to 255.255.255.255 via Serial0 (1.4.0.1)
!metric = 4294967295 = unreachable
20:43:09: subnet 1.1.0.0, metric=4294967295
20:43:09: subnet 1.3.0.0, metric=8476
20:43:09: subnet 1.2.0.0, metric=4294967295
20:43:10: IGRP: sending update to 255.255.255.255 via Serial1 (1.3.0.2)
20:43:10: subnet 1.1.0.0, metric=4294967295
20:43:10: subnet 1.2.0.0, metric=4294967295
20:43:10: subnet 1.5.0.0, metric=8576
20:43:10: subnet 1.4.0.0, metric=8476
20:43:10: RT: interface Ethernet0 removed from routing table
20:43:10: RT: del 1.1.0.0/16 via 0.0.0.0, connected metric [0/0]
20:43:10: RT: delete subnet route to 1.1.0.0/16
20:43:10: RT: delete route to 1.2.0.0 via 1.1.0.2, Ethernet0
20:43:10: RT: no routes to 1.2.0.0
!interesting that a request was sent on Ethernet 0, even though it is down!

20:43:10: IGRP: broadcasting request on Ethernet0
20:43:10: IGRP: broadcasting request on Serial0
20:43:10: IGRP: broadcasting request on Serial1
20:43:10: IGRP: received update from 1.4.0.2 on Serial0
20:43:10: subnet 1.1.0.0, metric 4294967295 (inaccessible)
20:43:10: subnet 1.2.0.0, metric 4294967295 (inaccessible)
20:43:10: subnet 1.5.0.0, metric 8576 (neighbor 1100)
20:43:10: IGRP: edition is now 4
!another flash update, note that 1.1.0.0 not in update anymore

The sequence of events for EIGRP convergence when Router C in Figure 1-12 detects the
1 Router C detects the link failure on the Ethernet between Routers A and C, checks the
topology table for a feasible successor, doesn’t find a qualifying alternate route, and
enters the active state (indicating that it must actively look for a new route).
2 Router C sends a query out all interfaces looking for alternate routes to the failed link
(the EIGRP multicast address 224.0.0.10 is used for the queries). The neighboring
routers acknowledge the query.
3 The reply from Router D indicates no other route to the network 1.1.0.0.
4 Router B’s reply contains a route to the failed link, although it has a higher feasible
distance.
5 Router C accepts the new path and metric information, places it in the topology table,
and creates an entry in its routing table.
6 Router C sends an update about the new route out all interfaces. All neighbors
acknowledge the update and send updates of their own (which are acknowledged)
back to the sender. These bidirectional updates are necessary to ensure that the routing
tables are synchronized and to validate the neighbor’s awareness of the new topology.
From Router E’s perspective, convergence time is the total of detection time, plus query and
reply times, plus update times. The actual time to converge at Router E is very rapid,
approximately 2 seconds.
EIGRP Convergence Testing Details

During testing of EIGRP convergence, the debug ip routing, debug ip eigrp neighbors,
debug ip eigrp summary, debug ip eigrp, debug ip eigrp notification, and show ip route
command outputs shown in Example 1-4 was obtained from Router C in Figure 1-12. Note
that comment lines (starting with a ! character) have been added to the output in Example
1-4 and that some of the debug output has been omitted. The shaded lines in Example 1-4
highlight some of the more important events and information for understanding how
EIGRP converges.
NOTE For the EIGRP metric, 4294967295 = hex FFFFFFFF. This is the maximum metric; in other
words, it indicates that the route is unreachable.
From the documentation on the debug ip eigrp command, the SM and M values in the
output of this command have the following meanings:
— SM—Shows the metric as reported by the neighbor.
Example 1-4 Example Debug Output on Router C in Figure 1-12 When Running EIGRP (Continued)
!tell serial 0 (Router D) about new metric to 1.1.0.0
02:27:52: IP-EIGRP: Int 1.1.0.0/16 metric 2707456 - 1657856 1049600
02:27:52: EIGRP: Sending UPDATE on Serial0 nbr 1.4.0.2
!tell serial 1 (Router B) about new metric to 1.1.0.0
02:27:52: IP-EIGRP: Int 1.1.0.0/16 metric 2707456 - 1657856 1049600
02:27:52: EIGRP: Sending UPDATE on Serial1 nbr 1.3.0.1
C#show ip route
!output omitted
D 1.1.0.0 [90/2707456] via 1.3.0.1, 00:00:39, Serial1
C 1.3.0.0 is directly connected, Serial1
D 1.2.0.0 [90/2681856] via 1.3.0.1, 00:00:40, Serial1
D 1.5.0.0 [90/2195456] via 1.4.0.2, 00:02:40, Serial0
OSPF Convergence
OSPF is discussed in detail in Chapters 3 and 4. The convergence steps for OSPF are
presented here for comparison with other protocols. The following are some of the terms
used in this section:
• Designated router (DR)—A router elected on each LAN to send updates about the
LAN.
• Link-state advertisement (LSA)—State information about a link or network.
• Hello packets—Small packets sent periodically out each interface of a router that is
participating in OSPF, to indicate that the router is still alive.
• Dead interval—The time that a router waits to hear from a neighbor before declaring
that the neighbor router is down.
A router running OSPF uses a multicast address to propagate LSAs.
The sequence of events for OSPF convergence when Router C in Figure 1-12 detects the
tries to perform a designated router election process on the Ethernet interface but fails
to reach any neighbors. Router C deletes the route to network 1.1.0.0 from the routing
table, builds a router LSA, and sends it out all other interfaces.
2 Upon receipt of the LSA, Routers B and D copy the advertisement and forward (flood)
the LSA packet out all interfaces other than the one upon which it arrived.
3 All routers, including Router C, wait for the built-in delay time (which defaults to 5
seconds) after receiving the LSA and then run the SPF algorithm. After running this
algorithm, Router C adds the new route to 1.2.0.0 to the routing table, and Routers D
and E update the metric to 1.2.0.0 in their routing tables.
4 After a period of time, Router A sends an LSA. This is the result of Router A not
receiving hello packets from Router C over the Ethernet within the dead interval,
which defaults to 40 seconds. (The approximately 24 seconds seen in the debug output
in Example 1-5 is the last 24 seconds of the 40-second dead interval.) Router C was
originally the DR for the Ethernet; Router A now becomes the DR and sends out an
LSA about the Ethernet network, 1.1.0.0. This LSA from Router A is flooded
throughout the network; when it gets to Router C, Router C immediately passes it on
to Router D, and so on. After 5 seconds, all routers run the SPF algorithm again. As a
result of running the SPF algorithm, Router C updates its routing table for 1.1.0.0, to
go via Router B.
From Router E’s perspective, convergence time is the total of detection time, plus LSA
flooding time, plus 5 seconds. The time to converge at Router E is approximately 6 seconds
before Router A’s LSA is accounted for (and this could be longer, depending on the size of
the topology table). When Router A’s LSA about network 1.1.0.0 (as a result of the dead
interval to Router C expiring) is considered in Router E’s convergence time, up to another
40 seconds is added before the network is considered converged.
OSPF Convergence Testing Details

During testing of OSPF convergence, the debug ip routing, debug ip ospf adj, debug ip
ospf events, debug ip ospf lsa-generation, debug ip ospf packet, debug ip ospf spf, and
show ip route command outputs shown in Example 1-5 was obtained from Router C in
Figure 1-12. Note that comment lines (starting with a ! character) have been added to the
output in Example 1-5 and that some of the debug output has been omitted. The shaded
lines in Example 1-5 highlight some of the more important events and information for
understanding how OSPF converges.
Example 1-5 Example Debug Output on Router C in Figure 1-12 When Running OSPF
C#
03:49:53: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state
to down
03:49:53: OSPF: Interface Ethernet0 going Down
03:49:53: OSPF: 1.4.0.1 address 1.1.0.1 on Ethernet0 is dead, state DOWN
03:49:53: OSPF: Neighbor change Event on interface Ethernet0
!strange to have an election on an interface that just went down!

03:49:53: OSPF: DR/BDR election on Ethernet0
Figure 1-13 Routing Updates Are Sent Differently by Distance Vector and Link-State Protocols
Routing Distance vector Full

table table
approach
Routing Link-state
table Single entry
approach
Traditional distance vector protocols use a routine, periodic announcement that contains the
entire contents of the routing table. These announcements are usually broadcasts and are
propagated only to directly connected devices. The downside of this approach is that
considerable bandwidth is consumed at regular intervals on each link, even if there are no
topology changes to report.
Link-state protocols use a triggered-update type of announcement. These announcements
are generated only when there is a topology change within the network. The link-state
announcements contain only information about the link that changed (such as a single
route) and are propagated to all devices in the network. Link-state announcements are sent
as multicast packets. The flooding of the announcement is required because link-state
devices make their route calculations independently; however, those calculations are based
upon a common understanding of the network topology. This approach saves bandwidth on
each link because the announcements contain less information than a full routing table and
are sent only when there is a topology change. In some link-state protocols, a periodic
announcement (every 30 minutes, for OSPF) is required to ensure that the topology
database is synchronized among all routing devices.
The routing process must maintain a single, loop-free path to each destination network. If
equal, lowest-metric paths exist to a destination, then all paths (up to a maximum of six, for
IP) will be listed in the routing table. The IP routing process will attempt to load share traffic
across equal-metric paths.
An IP routing table display can be requested with the Cisco IOS EXEC command show ip
route. If you think that the information that is displayed has changed, you can delete the
current routes in the routing table and force an update from the neighboring devices by
using the privileged EXEC clear ip route command. An optional parameter, either an
individual network or subnetwork route, or the * (wildcard for all) character, can be used
to further identify the routes to be refreshed.
Routing Table Analysis 39
Example 1-6 shows a sample IP routing table on a router. OSPF is the routing protocol used
in this network, and it has knowledge of both internal and external routes. The last line
represents a default network. The * indicates that this route is the default path, and this is
reflected by its selection as the gateway of last resort (as shown in the upper portion of the
routing table display).
Example 1-6 A Sample IP Routing Table
Backbone_r1#show ip route

D - EIGRP, EX - EIGRP external, O- OSPF, IA - OSPF inter area

C 172.16.10.0 is directly connected, Loopback100
C 172.16.11.0 is directly connected, Loopback101
O E2 172.22.0.0/16 [110/20] via 10.3.3.3, 01:03:01, Serial1/2
[110/20] via 10.4.4.4, 01:03:01, Serial1/3
[110/20] via 10.5.5.5, 01:03:01, Serial1/4
O E2 192.168.4.0/24 [110/20] via 10.4.4.4, 01:03:01, Serial1/3
O E2 192.168.5.0/24 [110/20] via 10.5.5.5, 01:03:01, Serial1/4
C 10.5.5.0 is directly connected, Serial1/4
O E2 192.168.3.0/24 [110/20] via 10.3.3.3, 01:03:02, Serial1/2
S* 0.0.0.0/0 [1/0] via 10.5.5.5
NOTE The content of the routing table is limited to the best route to all destinations. If multiple
equal-metric paths exist, all paths will be listed in the table, as is the case for the
172.22.0.0/16 network in Example 1-6. Additional detail about a specific route in the table
can be displayed by using the show ip route network command, indicating the specific
network.
The entries in a routing table represent each possible logical destination network that is
known to the router. The order of the entries may at times look like a random pattern, but
the router optimizes the order to facilitate the lookup process based upon length of subnet
mask.
Introduction to the Case Study

Throughout the rest of this book we use a case study of JKL Corporation, as shown in
Figure 1-14, to discuss various aspects of scalable routing. The case study sections are used
to review key concepts, to discuss critical issues surrounding network operation, and to
provide a focus for the configuration exercises.
Figure 1-14 JKL Corporation Is Used in Case Study Sections Throughout the Book
Internet
Acquisition A Acquisition C
1 Class A—Private 1 Class B—Public
2 Class C—Public OSPF Area 0—All
IGRP AS 350, RIP Multivendor equipment
OSPF Area 0—Small JKL Corporation No summarization
1 Class B—Public
Recently redesigned, optimal
OSPF Area 0—Small, Redundant
Acquisition B OSPF Multiarea, Hierarchical Acquisition D
VLSM with Route Summarization
3 Class C—Public 1 Class B—Public
IP RIP Only 1 Class C—Private
500 Devices, out of addresses EIGRP AS 400
6 Hops Discontiguous subnets
JKL’s Problem: How to integrate Acquisitions A-D?
JKL is an enterprise that will be making four acquisitions—A, B, C, and D. JKL’s ultimate
goal is to integrate the acquisitioned networks with its own network.
JKL has recently redesigned its network and now has a robust design using OSPF, VLSM,
and route summarization. JKL has a Class B public address. As we introduce details on
various topics throughout the rest of the book, you will see the problems that JKL must
overcome as it integrates the networks of the acquisitions with its own OSPF network.
Acquisition A is using a mixture of routing protocols—RIP, IGRP, and OSPF. It has two
Class C public addresses and uses a Class A private address.
Acquisition B is using three Class C public addresses and is using only IP RIP as the routing
protocol. It has 500 devices and has run out of IP addresses.
Acquisition C has a multivendor environment and is using OSPF and one Class B public
address. It is not using route summarization.
Acquisition D has one Class B public address and one Class C private address and
discontiguous subnets. It is using EIGRP as the routing protocol.
CHAPTER
2
Extending IP Addresses
After reading this chapter, you will be able to use variable-length subnet masks to extend
the use of the IP addresses when given an IP address range, explain whether route
summarization is possible when given a network plan that includes IP addressing, and
configure an IP helper address to manage broadcasts.
Current Challenges in IP Addressing

IP addressing was first defined in 1981. An IP address consists of a 32-bit number with two
components: a network address and a node (host) address. Classes of addresses are also
defined—originally, only Classes A, B, and C were defined, and later Classes D and E were
added. Since then, the growth of the Internet has been incredible. Two addressing
challenges have resulted from this explosion:
• IP address exhaustion—This has largely been due to the random allocation of IP
addresses by the Network Information Center (NIC). Address exhaustion also has
occurred because subnetting with one subnet mask may not be suitable for a typical
network topology, as you will see in the “Variable-Length Subnet Masks” section later
in this chapter.
• Routing table growth and manageability—One source indicates that in 1990, only
about 5000 routes were tracked to use the Internet. This number had grown to more
than 70,000 routes by the end of 1999. In addition to the exponential growth of the
Internet, the random assignment of IP addresses throughout the world has contributed
to the exponential growth of routing tables.
Next-generation IP (IP version 6) tries to respond to these problems by introducing a
128-bit address. In the meantime, Internet Requests For Comments (RFCs) have been
introduced to enable the current IP addressing scheme to continue to be useful.
IP Addressing Solutions
Since the 1980s, solutions have been developed to slow the depletion of IP addresses and
to reduce the number of Internet route table entries by enabling more hierarchical layers in
an IP address. These solutions include the following:
66 Chapter 2: Extending IP Addresses
• Subnet masking—Covered by RFCs 950 (1985) and 1812 (1995). Developed to add
another level of hierarchy to an IP address. This additional level allows for extending
the number of network addresses derived from a single IP address. (Subnet masking
is reviewed in the “IP Addressing and Subnetting” section in this chapter and in
Appendix A, “Job Aids and Supplements”; this subject also is discussed in detail in
the Cisco Press Interconnecting Cisco Network Devices coursebook and Cisco ICND
course.)
NOTE RFC 1812 also contains a lot of information on how IP routing protocols should work.
• Address allocation for private internets—Covered by RFC 1918 (1996). Developed

for organizations that do not need much access to the Internet. The only reason to have
a NIC-assigned IP address is to interconnect to the Internet. Any and all companies
can use the privately assigned IP addresses within their organization rather than using
a NIC-assigned IP address unnecessarily. The private addresses are 10.0.0.0 through
10.255.255.255, 172.16.0.0 through 172.31.255.255, and 192.168.0.0 through
192.168.255.255. (Private addresses are discussed in the Cisco Press Building Cisco
Remote Access Networks coursebook and in the Cisco BCRAN course.)
• Network address translation (NAT)—Covered by RFC 1631 (1994). Developed for
those companies that use private addressing or use IP addresses not assigned by NIC.
This strategy enables an organization to access the Internet with a NIC-assigned
address, without having to reassign the private addresses (sometimes called illegal
addresses) that are already in place. (NAT is discussed in the Cisco Press Building
Cisco Remote Access Networks coursebook and in the Cisco BCRAN course.)
• Hierarchical addressing—Applying a structure to addressing so that multiple
addresses share the same left-most bits. Hierarchical addressing is discussed in this
chapter in the section “Hierarchical Addressing.”
• Variable-length subnet masks (VLSMs)—Covered by RFC 1812 (1995).
Developed to allow multiple levels of subnetworked IP addresses within a single
network. This strategy can be used only when it is supported by the routing protocol
in use, such as the Open Shortest Path First (OSPF) protocol and the Enhanced
Interior Gateway Routing Protocol (EIGRP). VLSMs are discussed later in this
chapter in the section “Variable-Length Subnet Masks.”
• Route summarization—Covered by RFC 1518 (1993). A way of having a single IP
address represent a collection of IP addresses when you employ a hierarchical
addressing plan. Route summarization is discussed later in this chapter in the section
“Route Summarization.”
IP Addressing Solutions 67
• Classless Interdomain Routing (CIDR)—Covered by RFCs 1518 (1993), 1519

(1993), and 2050 (1996). Developed for Internet service providers (ISPs). This
strategy suggests that the remaining IP addresses be allocated to ISPs in contiguous
blocks, with geography being a consideration. CIDR is discussed later in this chapter
in the section “Classless Interdomain Routing.”
IP Addressing and Subnetting

This section is an overview of IP subnetting and addresses. Appendix A includes a more
detailed review of these topics.
When contiguous ones are added to the default mask, making the all-ones field in the mask
longer, the definition of the network part of an IP address is extended to include subnets.
Adding bits to the network part of an address decreases the number of bits in the host part.
Thus, creating additional networks (subnets) is done at the expense of the number of host
devices that can occupy each network segment.
The number of bits added to a default routing mask creates a counting range for counting
subnets. Each subnet is a unique binary pattern.
The number of subnetworks created is calculated by the formula 2n, where n is the number
of bits by which the default mask was extended. Subnet 0 (where all the subnet bits are 0)
must be explicitly allowed using the ip subnet-zero global configuration command in
Cisco IOS releases prior to 12.0. In Cisco IOS Release 12.0 and later, subnet zero is enabled
by default.
NOTE This book describes the formula for obtaining the number of subnets differently than
previous Cisco courses and books. Previously, the same formula that was used to count
hosts, 2n – 2, was used to count subnets. Now 2n subnets and 2n – 2 hosts are available. The
2n rule for subnets has been adopted because the all-ones subnet has always been a legal
subnet according to the RFC, and subnet zero can be enabled by configuration commands
on the Cisco routers (and, in fact, is on by default in Cisco IOS Release 12.0 and later).
Note, however, that not all vendor equipment supports the use of subnet zero.
The remaining bits in the routing mask form a counting range for hosts. Host addresses are
selected from these remaining bits and must be numerically unique from all other hosts on
the subnetwork.
The number of hosts created is calculated by the formula 2n – 2 where n is the number of
bits available in the host portion. In the host counting range, the all 0s bit pattern is reserved
as the subnet identifier (sometimes called the wire), and the all 1s bit pattern is reserved as
a broadcast address, to reach all hosts on that subnet.
Both the IP address and the associated mask contain 32 bits. Routers are similar to
computers in that both use the binary numbering scheme to represent addresses. Network
administrators, however, typically do not use binary numbers on a daily basis and therefore
have adopted other formats to represent 32-bit IP addresses. Some common formats include
decimal (base 10) and hexadecimal (base 16) notations.
The generally accepted method of representing IP addresses and masks is to break the
32-bit field into four groups of 8 bits (octets) and to represent those 8-bit fields in a decimal
format, separated by decimal points. This is known as 32-bit dotted decimal notation.
NOTE Although the dotted decimal notation is commonly accepted, this notation means nothing
to the routing device because the device internally uses the 32-bit binary string. All routing
decisions are based on the 32-bit binary string.
IP addresses belong to classes, defined by the decimal value represented in the first octet.
The class definition is referred to as the First Octet Rule. As shown in Table 2-1, Classes A
through E are defined. Of the five available addressing spaces, Classes A, B, and C are the
best known and most commonly used because they are used to identify devices connected
to the Internet.
Table 2-1 Determining IP Address Class by the First Octet Rule
First Octet of Address (Decimal) Address Class
1 to 126 Class A
128 to 191 Class B
192 to 223 Class C
224 to 239 Class D
240 to 255 Class E
NOTE The first octet for Class A ranges from 1 (not 0) to 126 (not 127). The 0 address is a reserved
address, meaning this network, and can be used only as a source address. The 127 address
is reserved for the local loopback address.
Hierarchical Addressing 69
Class D addresses are not as widely used. Class D addresses are multicast addresses; some
Class D multicast addresses used by routing protocols are as follows:
• OSPF—224.0.0.5 and 224.0.0.6
• Routing Information Protocol version 2 (RIPv2)—224.0.0.9
• EIGRP—224.0.0.10
Videoconferencing and other applications use other Class D multicast addresses. In
videoconferencing applications, users subscribe to a group service and are issued a special
group address that allows them access to the data created for that special event. This
approach enables many users to subscribe and unsubscribe to a service as their needs and
schedules permit.
Class E addresses are used for experimental purposes.
Hierarchical Addressing
This section discusses hierarchical addressing and the benefits of using it. The following
topics are covered:
• Planning an IP address hierarchy
• Benefits of hierarchical addressing
Planning an IP Address Hierarchy

Perhaps the best-known addressing hierarchy is the telephone network. The telephone
network uses a hierarchical numbering scheme that includes country codes, area codes, and
local exchange numbers. For example, if you are in San Jose, California, and call someone
else in San Jose, you dial the San Jose local exchange number, 528, and the person’s
telephone number—for example, 7777. Upon seeing the number 528, the central office
recognizes that the destination telephone is within its area, so it looks for number 7777 and
transfers the call.
In another example, as shown in Figure 2-1, to call Aunt Judy in Alexandria, Virginia, from
San Jose, you dial 1, then the area code 703, then the Alexandria prefix 555, and then Aunt
Judy’s local number, 1212. The central office first sees the number 1, indicating a remote
call, and then looks up the number 703. The central office immediately routes the call to a
central office in Alexandria. The San Jose central office does not know exactly where 555-
1212 is in Alexandria, nor does it have to. It needs to know only the area codes, which
summarize the local telephone numbers within an area.
Figure 2-1 The Telephone Network Uses an Addressing Hierarchy
Long (remote) Long distance

distance Virginia
Path to 1 Path to 703 Path to 555

(A number indicates Local (An area code summarizes Local office (A prefix summarizes
that destination is remote) office an area in Virginia) Alexandria a smaller area in Virginia)
Path to 1212
(Number)
San Jose, California Aunt Judy
If there were no hierarchical structure, every central office would need to have every
telephone number worldwide in its locator table. Instead, the central offices have summary
numbers, such as area codes and country codes. A summary number (address) represents a
group of numbers. For example, an area code such as 408 is a summary number for the San
Jose area. That is, if you dial 1-408 from anywhere in the United States, followed by a
seven-digit telephone number, the central office will route the call to a San Jose central
office. This is the type of addressing strategy that the Internet gurus are trying to work
toward and that you as a network administrator should implement in your own
internetwork.
Benefits of Hierarchical Addressing

Imagine if the telephone network did not use a hierarchy—each central office would need
to keep track of all the phone numbers in the phone network. This would obviously be
unacceptable. Instead, the telephone network uses the area code and prefix to represent a
collection of phone numbers—that is, they summarize the phone numbers within an area.
Similarly, a routed network can employ a hierarchical addressing scheme to take advantage
of those same benefits.
The benefits of hierarchical addressing include these:
• Reduced number of routing table entries—Whether it is with your Internet routers
or your internal routers, you should try to keep your routing tables as small as possible
by using route summarization. Route summarization is a way of having a single IP
addressing plan. By summarizing routes, you can keep your routing table entries
manageable, which offers the following benefits:
— More efficient routing
— Reduced number of CPU cycles when recalculating a routing table or
sorting through the routing table entries to find a match
Variable-Length Subnet Masks 71
— Reduced router memory requirements

— Faster convergence after a change in the network
— Easier troubleshooting
• Efficient allocation of addresses—Hierarchical addressing enables you to take
advantage of all possible addresses because you group them contiguously. With
random address assignment, you may end up wasting groups of addresses because of
addressing conflicts. For example, recall that classful routing protocols automatically
create summary routes at a network boundary. Therefore, these protocols do not
support discontiguous addressing (as you will see later in this chapter in the section
“Summarizing Routes in a Discontiguous Network”), so some addresses would be
unusable if not assigned contiguously.
Variable-Length Subnet Masks

This section introduces VLSMs, gives some examples, and discusses VLSM use with
classless routing protocols. The section covers the following:
• VLSM overview
• Calculating VLSMs
• A working VLSM example
VLSM Overview
VLSMs provide the capability to include more than one subnet mask within a major
network and the capability to subnet an already subnetted network address. The benefits of
VLSMs include these:
• Even more efficient use of IP addresses—Without the use of VLSMs, companies are
locked into implementing a single subnet mask within an entire Class A, B, or C
network number.
For example, consider the 172.16.0.0/16 network address divided into
subnets using /24 masking, and one of the subnetworks in this range,
172.16.14.0/24, further divided into smaller subnets with the /27 masking, as
shown in Figure 2-2. These smaller subnets range from 172.16.14.0/27 to
172.16.14.224/27. In Figure 2-2, one of these smaller subnets,
172.16.14.128, is further divided with the /30 prefix, creating subnets with
only two hosts, to be used on the WAN links. (The details of the subnets used
are shown following Figure 2-2.)
• Greater capability to use route summarization—VLSMs allow for more

hierarchical levels within your addressing plan and thus allow for better route
summarization within routing tables. For example, in Figure 2-2, address
172.16.14.0/24 could summarize all the subnets that are further subnets of
172.16.14.0, including those from subnet 172.16.14.0/27 and from 172.16.14.128/30.
Figure 2-2 VLSMs Allow More Than One Subnet Mask Within a Major Network
172.16.14.32/27 172
.16.
A 14.1
32/3
0 172.16.1.0/24
172.16.14.136/30
172.16.14.64/27 HQ
B
0/30
6.1 4.14 172.16.2.0/24
172.1
172.16.14.96/27
C
172.16.0.0/16
In Figure 2-2, the subnets available are as follows:
From 172.16.0.0/24: 172.16.0.0/24 (not used in this example)

172.16.1.0/24
172.16.2.0/24
and so on
172.16.14.0/24 (not used, was further subnetted
to 172.16.14.0/27)
172.16.14.32/27
172.16.14.64/27
172.16.14.96/27
and so on
172.16.14.128/27 (not used, but was further
subnetted to 172.16.14.128/30)
172.16.14.132/30
172.16.14.136/30
172.16.14.140/30
and so on
Variable-Length Subnet Masks 73
Calculating VLSMs
With VLSMs, you can subnet an already subnetted address. Consider, for example, that you
have a subnet address 172.16.32.0/20, and you need to assign addresses to a network that
has ten hosts. With this subnet address, however, you have 212 – 2 = 4094 host addresses,
so you would be wasting more than 4000 IP addresses. With VLSMs, you can further subnet
the address 172.16.32.0/20 to give you more subnetwork addresses and fewer hosts per
network, which would work better in this network topology. For example, if you subnet
172.16.32.0/20 to 172.16.32.0/26, you gain 64 (26) subnets, each of which could support
62 (26 – 2) hosts.
NOTE The “Decimal-to-Binary Conversion Chart” in Appendix A may be helpful when you are
calculating VLSMs.
To further subnet 172.16.32.0/20 to 172.16.32.0/26, do the following, as illustrated in

Figure 2-3:
Step 1 Write 172.16.32.0 in binary form.
Step 2 Draw a vertical line between the 20th and 21st bits, as shown in
Figure 2-3.
Step 3 Draw a vertical line between the 26th and 27th bits, as shown in
Figure 2-3.
Step 4 Calculate the 64 subnet addresses using the bits between the two vertical
lines, from lowest to highest in value. Figure 2-3 shows the first five
subnets available. If necessary, refer to the “Decimal-to-Binary
Conversion Chart,” in Appendix A.
Figure 2-3 An Example of Further Subnetting a Subnetted Address
Subnetted Address: 172.16.32.O/2O

In Binary 1O1O11OO.OOO1OOOO.OO1OOOOO.OOOOOOOO
VLSM Address: 172.16.32.O/26

In Binary 1O1O11OO.OOO1OOOO.OO1OOOOO.OOOOOOOO
1st subnet: 1O1O11OO . OOO1OOOO .OO1O OOOO.OO OOOOOO=172.16.32.O/26

2nd subnet: 172 . 16 .OO1O OOOO.O1 OOOOOO=172.16.32.64/26
3rd subnet: 172 . 16 .OO1O OOOO.1O OOOOOO=172.16.32.128/26
4th subnet: 172 . 16 .OO1O OOOO.11 OOOOOO=172.16.32.192/26
5th subnet: 172 . 16 .OO1O OOO1.OO OOOOOO=172.16.33.O/26
Network Subnet VLSM Host
subnet
NOTE VLSM calculators are available on the Web. The following URL is for the one offered by
Cisco: www.cisco.com/techtools/ip_addr.html. (Note that you need to have an account to
use this calculator; you can see it but cannot use it without logging in.)
A Working VLSM Example

VLSMs are commonly used to maximize the number of possible addresses available for a
network. For example, because point-to-point serial lines require only two host addresses,
you can use a subnetted address that has only two host addresses and therefore will not
waste scarce subnet numbers.
In Figure 2-4, the addresses used on the local-area networks (LANs) are those generated in
the previous section, “Calculating VLSMs.”
Figure 2-4 A Working VLSM Example Using Ethernet and Point-to-Point WAN Links
Derived from the 172.16.32.0/20 subnet
172.16.32.0/26
172.16.33.0/30
172.16.33.4/30 172.16.32.64/26
172.16.33.8/30
172.16.32.128/26
172.16.33.12/30
Derived from the 172.16.32.192/26

172.16.33.0/26 subnet
30-bit mask 26-bit mask

(2 hosts) (62 hosts)
Figure 2-4 illustrates where the addresses can be applied, depending on the number of hosts
anticipated at each layer. For example, the wide-area network (WAN) links use addresses
with a prefix of /30 (corresponding to a subnet mask of 255.255.255.252). This prefix
allows for only two hosts—just enough hosts for a point-to-point connection between a pair
of routers. To calculate the addresses used on the WAN links, further subnet one of the
unused subnets. In this case, you can further subnet 172.16.33.0/26 with a prefix of /30.
This provides 4 more subnet bits and therefore 24 = 16 subnets for the WANs.
Route Summarization 75
The WAN addresses derived from the 172.16.33.0/26 subnet are as follows:
• 172.16.33.00000000 = 172.16.33.0/30
• 172.16.33.00000100 = 172.16.33.4/30
• 172.16.33.00001000 = 172.16.33.8/30
• 172.16.33.00001100 = 172.16.33.12/30
NOTE It is important to remember that only subnets that are unused can be further subnetted. In
other words, if you use any addresses from a subnet, that subnet cannot be further
subnetted. In the example in Figure 2-4, four subnet numbers are used on the LANs.
Another, as yet unused subnet, 172.16.33.0/26, is further subnetted for use on the WANs.
Route Summarization
This section describes and gives examples of route summarization, including
implementation considerations. This section covers the following topics:
• Route summarization overview
• Summarizing within an Octet
• Summarizing addresses in a VLSM-designed network
• Route summarization implementation
• Route summarization operation in Cisco routers
• Summarizing routes in a discontiguous network
• Route summarization summary
Route Summarization Overview

In large internetworks, hundreds or even thousands of networks can exist. In these
environments, it is often not desirable for routers to maintain all these routes in their routing
table. Route summarization (also called route aggregation or supernetting) can reduce the
number of routes that a router must maintain because it is a method of representing a series
of network numbers in a single summary address. For example, in Figure 2-5, Router A
either can send three routing update entries or can summarize the three addresses into a
single network number.
Figure 2-5 Routers Can Summarize to Reduce the Number of Routes
172.16.25.0/24 Router A can route to the

172.16.0.0/16 network
172.16.26.0/24
Router A Router B
Routing table Routing table

172.16.25.0/24 172.16.0.0/16
172.16.27.0/24 172.16.26.0/24
172.16.27.0/24
NOTE Router A in Figure 2-5 is advertising that it can route to the network 172.16.0.0/16,
including all subnets of that network. However, if there were other subnets of 172.16.0.0
elsewhere in the network (for example, if 172.16.0.0 were discontiguous), summarizing in
this way might not be valid. Discontiguous networks and summarization are discussed in
the “Summarizing Routes in a Discontiguous Network” section, later in this chapter.
Another advantage to using route summarization in a large, complex network is that it can
isolate topology changes from other routers. That is, if a specific link in the 172.16.27.0/24
domain were flapping (going down and up rapidly), the summary route would not change,
so no router external to the domain would need to keep modifying its routing table due to
this flapping activity.
NOTE A summary route will be announced by the summarizing router as long as at least one
specific route matches the summary route in its routing table.
Route summarization is most effective and possible only when a proper addressing plan is
in place. Route summarization is most effective within a subnetted environment when the
network addresses are in contiguous blocks in powers of two. For example, 4, 16, or 512
addresses can be represented by a single routing entry because summary masks are binary
masks—just like subnet masks—so summarization must take place on binary boundaries
(powers of two). If the number of network addresses is not contiguous or a power of two,
you can divide the addresses into groups and try to summarize the groups separately.
Routing protocols summarize or aggregate routes based on shared network numbers within
the network. Classless routing protocols—such as OSPF, and EIGRP—support route
summarization based on subnet addresses, including VLSM addressing. Classful routing
protocols—RIPv1 and IGRP—automatically summarize routes on the classful network
boundary and do not support summarization on any other bit boundaries. Classless routing
protocols support summarization on any bit boundary.
Summarization is described in RFC 1518, “An Architecture for IP Address Allocation with
CIDR.”
Summarizing Within an Octet

Figure 2-5 illustrated a summary route based on a full octet—172.16.25.0/24, 172.16.26.0/
24, and 172.16.27.0/24 could be summarized into 172.16.0.0/16. However, this is not
always the case.
A router could receive updates for the following routes:
• 172.16.168.0/24
• 172.16.169.0/24
• 172.16.170.0/24
• 172.16.171.0/24
• 172.16.172.0/24
• 172.16.173.0/24
• 172.16.174.0/24
• 172.16.175.0/24
In this case, to determine the summary route, the router determines the number of highest-
order (left-most) bits that match in all the addresses. As shown in Figure 2-6, the left-most
21 bits match in all these addresses. Therefore, the best summary route is 172.16.168.0/21
(or 172.16.168.0 255.255.248.0).
To allow the router to aggregate the most IP addresses into a single route summary, your IP
addressing plan should be hierarchical in nature. This approach is particularly important
when using VLSMs, as illustrated in the next section.
Figure 2-6 An Example of Summarizing Within an Octet
172.16.168.0/24 = 10101100. 00010000 . 10101 000 . 00000000

172.16.169.0/24 = 172 . 16 . 10101 001 . 0
172.16.170.0/24 = 172 . 16 . 10101 010 . 0
172.16.171.0/24 = 172 . 16 . 10101 011 . 0
172.16.172.0/24 = 172 . 16 . 10101 100 . 0
172.16.173.0/24 = 172 . 16 . 10101 101 . 0
172.16.174.0/24 = 172 . 16 . 10101 110 . 0
172.16.175.0/24 = 172 . 16 . 10101 111 . 0
Number of common bits = 21 Number of
Summary: 172.16.168.0/21 noncommon
bits = 11
Summarizing Addresses in a VLSM-Designed Network

A VLSM design allows for maximum use of IP addresses as well as more efficient routing
update communication when using hierarchical IP addressing. In Figure 2-7 for example,
route summarization occurs at two levels:
• Router C summarizes two routing updates from networks 172.16.32.64/26 and
172.16.32.128/26 into a single update, 172.16.32.0/24.
• Router A receives three different routing updates but summarizes them into a single
routing update before propagating it to the corporate network.
Route Summarization Implementation

Route summarization reduces memory use on routers and routing protocol network traffic,
due to less entries in the routing table. For summarization in a network to work correctly,
the following requirements must be met:
• Multiple IP addresses must share the same high-order bits.
• Routing protocols must base their routing decisions on a 32-bit IP address and a prefix
length that can be up to 32 bits.
• Routing updates must carry the prefix length (the subnet mask) along with the 32-bit
IP address.
Figure 2-7 An Example of Summarizing in a Network Using VLSM
Router B
172.16.128.0/20
17
2.1
6.1
28
.0/
20
172.16.32.64/26
Router A
172.16.32.0/24 Corporate
network
Router C 172.16.0.0/16
172.16.32.128/26
20
0/
64.
1 6.
2.
17
172.16.64.0/20
Router D
Route Summarization Operation in Cisco Routers

This section discusses generalities of how Cisco routers handle route summarization.
Details about how route summarization operates with a specific protocol are discussed in
the specific protocol chapter of this book. For example, route summarization for OSPF is
discussed in Chapter 4, “Interconnecting Multiple OSPF Areas.”
Cisco routers manage route summarization in two ways:
• Sending route summaries—Routing information advertised out an interface is
automatically summarized at major (classful) network address boundaries by RIP,
IGRP, and EIGRP. Specifically, this automatic summarization occurs for those routes
whose classful network address differs from the major network address of the
interface to which the advertisement is being sent. For OSPF, you must configure
summarization.
Route summarization is not always a solution. You would not want to use
route summarization if you needed to advertise all networks across a
boundary, such as when you have discontiguous networks (discussed in the
next section). When using EIGRP and RIPv2, you can disable this automatic
summarization.
• Selecting routes from route summaries—If more than one entry in the routing table
matches a particular destination, the longest prefix match in the routing table is used.
Several routes might match one destination, but the longest matching prefix is used.
For example, if a routing table has the paths shown in Figure 2-8, packets addressed
to destination 172.16.5.99 would be routed through the 172.16.5.0/24 path because
that address has the longest match with the destination address.
Figure 2-8 Routers Will Use the Longest Match When Selecting a Route
172.16.5.33 /32 Host

172.16.5.32 /27 Subnet
172.16.5.0 /24 Network
172.16.0.0 /16 Block of networks
0.0.0.0 /0 Default
NOTE When running classful protocols (RIPv1 and IGRP), you must enable ip classless if you
want the router to select a default route when it must route to an unknown subnet of a
network for which it knows some subnets. For example, consider a router’s routing table
that has entries for subnets 10.5.0.0/16 and 10.6.0.0/16, and a default route of 0.0.0.0. If a
packet arrives for a destination on the 10.7.0.0/16 subnet, and if ip classless is not enabled,
then the packet will be dropped. Classful protocols assume that if they know some of the
subnets of network 10.0.0.0, then they must know all the existing subnets of that network.
Enabling ip classless indicates to the router that it should follow the best supernet route or
the default route for unknown subnets of known networks, as well as for unknown
networks.
Note that ip classless is enabled by default in Release 12.0 of the Cisco IOS software; in
previous releases, it is disabled by default.
Summarizing Routes in a Discontiguous Network

Discontiguous subnets are subnets of the same major network that are separated by a
different major network.
Recall that RIP, IGRP, and EIGRP summarize automatically at network boundaries. This
behavior, which cannot be changed with RIPv1 and IGRP, has important results:
• Subnets are not advertised to a different major network.
• Discontiguous subnets are not visible to each other.
In the example shown in Figure 2-9, Routers A and B do not advertise the 172.16.5.0
255.255.255.0 and 172.16.6.0 255.255.255.0 subnets because RIPv1 cannot advertise
subnets across a different major network; both Router A and Router B advertise 172.16.0.0.
This leads to confusion when routing across network 192.168.14.0. For example, Router C
receives routes about 172.16.0.0 from two different directions; therefore, it might not make
a correct routing decision.
Figure 2-9 Classful Routing Protocols Do Not Support Discontiguous Subnets
172.16.5.0 192.128.14.16 172.16.6.0

255.255.255.0 255.255.255.240 255.255.255.0
Router C
Router A Router B
RIPv1 will advertise

network 172.16.0.0 RIPv1 will advertise
network 172.16.0.0
This situation can be resolved by using RIPv2, OSPF, or EIGRP and not using
summarization because the subnet routes would be advertised with their actual subnet
masks. Advertisements are configurable when using OSPF and EIGRP, but not RIPv2.
The Cisco IOS software also provides an IP unnumbered feature that permits
noncontiguous subnets to be separated by an unnumbered link; this feature is discussed in
the section “Using IP Unnumbered Serial Interfaces,” later in this chapter.
Route Summarization Cautions in Discontiguous Networks

Be careful when using route summarization in a network that has discontiguous subnets, or
if not all the summarized subnets are reachable via the advertising router. If a summarized
route indicates that certain subnets are reachable via a router, when those subnets actually
are discontiguous or are not reachable via that router, the network may have problems
similar to those shown in Figure 2-9 for a RIPv1 network. For example, in Figure 2-10,
EIGRP is being used, and both Router A and Router B are advertising a summarized route
to 172.16.0.0/16. Therefore, Router C receives two routes to 172.16.0.0/16 and has no
knowledge of which subnets are attached to which router.
Figure 2-10 Care Is Also Needed When Summarizing with Classless Routing Protocols
192.128.14.16
255.255.255.240
172.16.5.0/24 172.16.6.0/24
172.16.7.0/24 Router C 172.16.9.0/24

Router A Router B
EIGRP advertises
172.16.0.0/16 EIGRP advertises
172.16.0.0/16
This problem can be resolved if you are using a classless routing protocol because
automatic summarization can be turned off (if it is on by default). Because routers running
classless routing protocols use the longest prefix match when selecting a route from the
routing table, if one of the routers advertised without summarizing, other routers would see
subnet routes as well as the summary route. The other routers could then select the longest
prefix match and follow the correct path. For example, in Figure 2-10, if Router A continues
to summarize to 172.16.0.0/16, and Router B was configured to not summarize, then Router
C would receive explicit routes for 172.16.6.0/24 and 172.16.9.0/24 along with the
summarized route to 172.16.0.0/16. All traffic for Router B’s subnets would then be sent to
Router B, while all other traffic for the 172.16.0.0 network would be sent to Router A. This
would be true for any other classless protocol.
Route Summarization Summary

Table 2-2 provides a summary of the route summarization support available in the various
IP routing protocols discussed.
Table 2-2 Routing Protocol Route Summarization Support
Capability to
Automatic Summarize at
Summarization at Capability to Turn Other Than
Classful Network Off Automatic Classful Network
Protocol Boundary? Summarization? Boundary?
RIPv1 Yes No No
RIPv2 Yes Yes No
IGRP Yes No No
EIGRP Yes Yes Yes
OSPF No — Yes
Classless Interdomain Routing 83
Classless Interdomain Routing

CIDR is a mechanism developed to help alleviate the problem of exhaustion of IP addresses
and growth of routing tables. The idea behind CIDR is that blocks of multiple Class C
addresses can be combined, or aggregated, to create a larger classless set of IP addresses
(that is, with more hosts allowed). Blocks of Class C network numbers are allocated to each
network service provider. Organizations using the network service provider for Internet
connectivity are allocated subsets of the service provider’s address space as required.
These multiple Class C addresses can then be summarized in routing tables, resulting in
fewer route advertisements.
CIDR is described further in RFCs 1518 and 1519. RFC 2050, “Internet Registry IP
Allocation Guidelines,” specifies guidelines for the allocation of IP addresses.
CIDR Example
Figure 2-11 shows an example of CIDR and route summarization. The Class C network
addresses 192.168.8.0/24 through 192.168.15.0/24 are being used and are being advertised
to the ISP router. When the ISP router advertises the networks available, it can summarize
these into one route instead of separately advertising the eight Class C networks. By
advertising 192.168.8.0/21, the ISP router indicates that it can get to all destination
addresses that have the first 21 bits the same as the first 21 bits of the address 192.168.8.0.
Figure 2-11 CIDR Allows a Router to Summarize Multiple Class C Addresses
Router A
192.168.8.0/24 192
.168
.8.0
/24
Router B
192.168.9.0/24 192.168.8.0/21
192.168.9.0/24 ISP
• •
• •
• • 4
0/2
8.15.
.16
192.168.15.0/24 192
Router H
NOTE The mechanism used to calculate the summary route to advertise is the same as shown in
the “Route Summarization” section, earlier in this chapter. The Class C network addresses
192.168.8.0/24 through 192.168.15.0/24 are being used and are being advertised to the ISP
router. To summarize these addresses, find the common bits as shown here:
192.168.8.0 192.168.00001000.00000000
192.168.9.0 192.168.00001001.00000000
192.168.10.0 192.168.00001010.00000000
...
192.168.14.0 192.168.00001110.00000000
192.168.15.0 192.168.00001111.00000000
The route 192.168.00001xxx.xxxxxxxx or 192.168.8.0/21 (also written as 192.168.8.0
255.255.248.0) summarizes these eight routes.
Using IP Unnumbered Serial Interfaces

To enable IP processing on a serial interface without assigning an explicit IP address to the
interface, use the ip unnumbered type number interface configuration command. In the
command, type number indicates the type and number of another interface on which the
router has an assigned IP address. It cannot be another unnumbered interface. To disable
the IP processing on the interface, use the no form of this command.
Whenever the unnumbered interface generates a packet (for example, for a routing update),
it uses the address of the specified interface as the source address of the IP packet. The
router also uses the address of the specified interface in determining which routing
processes are sending updates over the unnumbered interface. (For example, if the network
command configured for the RIP routing protocol indicates that network 10.0.0.0 is running
RIP, then all interfaces with an address in network 10.0.0.0 will be running RIP, as will all
unnumbered interfaces that specify an interface that has an address in network 10.0.0.0.)
Restrictions on unnumbered interfaces include the following:
• Serial interfaces using High-Level Data Link Control (HDLC); Point-to-Point
Protocol (PPP); Link Access Procedure, Balanced (LAPB); and Frame Relay
encapsulations, as well as Serial Line Internet Protocol (SLIP) and tunnel interfaces
can be unnumbered. It is not possible to use this interface configuration command
with X.25 or Switched Multimegabit Data Service (SMDS) interfaces.
• You cannot use the ping EXEC command to determine whether the interface is up
because the interface has no address. Simple Network Management Protocol (SNMP)
can be used to remotely monitor the interface status.
Using IP Unnumbered Serial Interfaces 85
The interface you specify (by the type and number parameters) must be enabled; in other
words, it must be listed as up in the show interfaces command display.
NOTE Using an unnumbered serial line between different major networks requires special care. If
at each end of the link different major networks are assigned to the interfaces you specified
as unnumbered, then any routing protocol running across the serial line must not advertise
subnet information. (For example, Router A and Router B are connected via an unnumbered
serial line. Router A has all its interfaces in network 172.16.0.0, and therefore the serial line
specifies an interface in network 172.16.0.0. Router B has all its interfaces in network
172.17.0.0, so the serial line specifies an interface in network 172.17.0.0. If OSPF is
configured to run on the unnumbered serial line, it must be configured to summarize the
subnet information and not send it across the link.)
In the example network in Figure 2-12, interface Serial 0 uses Ethernet 0’s address. The
configuration for the router in this figure is provided in Example 2-1.
Figure 2-12 An Example of Using the ip unnumbered Command
S0
E0
10.1.1.1
Router A
Example 2-1 Configuration of the Router in Figure 2-12

interface Ethernet0
ip address 10.1.1.1 255.255.255.0
!
interface Serial0
ip unnumbered Ethernet0
A loopback interface is often used as the interface from which unnumbered interfaces get
their IP address. Loopback interfaces are virtual interfaces, so after they are defined, they
are always active and cannot go down like a real interface.
Using Helper Addresses

This section covers the use of helper addresses to forward selected broadcasts beyond a
router. Routers do not forward broadcasts by default. By doing this, routers prevent
broadcast storms—a situation in which a single broadcast triggers an onslaught of other
broadcasts, ultimately leading to a disruption in network services. Large, flat networks are
notorious for their bouts of broadcast storms.
However, a client might need to reach a server and might not know the server’s address. In
this situation, the client broadcasts to find the server. If there is a router between the client
and server, the broadcast will not get through, by default. Helper addresses facilitate
connectivity by forwarding these broadcasts directly to the target server.
Client hosts interact with a variety of network-support servers such as a Domain Name
System (DNS) server, a Bootstrap protocol (BOOTP)/Dynamic Host Configuration
Protocol (DHCP) server, or a Trivial File Transfer Protocol (TFTP) server. At startup time,
the clients often do not know the IP address of the server, so they send broadcast packets to
find it. Sometimes the clients do not know their own IP address, so they use BOOTP or
DHCP to obtain it. If the client and server are on the same network, the server will respond
to the client’s broadcast request. From these replies, the client can glean the IP address of
the server and use it in subsequent communication.
However, the server might not be on the same physical medium as the client, as shown in
Figure 2-13. Remember that a destination IP address of 255.255.255.255 is sent in a link-
layer broadcast (FFFFFFFFFFFF). By default, routers will never forward such broadcasts,
and you would not want them to. A primary reason for implementing routers is to localize
broadcast traffic. However, you do want clients to be capable of reaching the appropriate
servers. Use helper addresses for this purpose.
Figure 2-13 Routers Do Not Forward Broadcasts by Default
Looking for
boot server
Diskless BOOTP
workstation server
Broadcast Unicast
Broadcast
Using Helper Addresses 87
Helper address commands change destination broadcasts addresses to a unicast address (or
a directed broadcast—a local broadcast within a particular subnet) so that the broadcast
message can be routed to a specific destination rather than everywhere. It is important to
note that every broadcast (with the default port numbers, or with the port numbers that you
specify) gets sent to all helper addresses, regardless of whether the server will actually be
capable of helping for a certain port.
NOTE Helper addresses assist devices in locating necessary services within the network. It is more
efficient administratively to allow a client device to broadcast for a service than to hard-
code (in the client machines) the IP addresses for devices that may not always be online and
available.
Server Location
It is important to consider how you want to get the broadcast, in a controlled way, to the
appropriate servers. Such considerations depend on the location of the servers. In practice,
server location is implemented in several ways, as shown in Figure 2-14:
• A single server on a single remote medium—Such a medium may be directly
connected to the router that blocks the broadcast, or it might be several routing hops
away. In any case, the all-ones broadcast needs to be handled at the first router it
encounters and then sent to the server.
• Multiple servers on a single remote medium, sometimes called a server farm—
Different kinds of servers (for example, DNS and TFTP servers used in the automatic
install process [AutoInstall] for Cisco routers), could exist on the same medium. Or,
perhaps redundant servers of the same type are installed on the same medium. In
either case, a directed broadcast can be sent on the server farm subnet so that the
multiple devices can see it.
• Multiple servers on multiple remote media—In this case, for example, a secondary
DNS server could exist on one subnet and the primary DNS server could exist on
another subnet. For fault tolerance, client requests need to reach both servers.
NOTE In Cisco IOS Release 12.0 and later, the no ip directed-broadcast command is on by
default, which means that all received IP directed broadcasts are dropped. To enable the
translation of directed broadcasts to physical broadcasts, use the ip directed broadcast
interface configuration command.
Figure 2-14 Servers May Be in Many Locations
Host Server Host Server Server
Single server, remote medium Multiple servers, remote medium
Host Server
Server
Multiple servers, remote media
IP Helper Address Configuration

Use the ip helper-address address interface configuration command to configure an
interface on which broadcasts are expected or can be received. In the command, address
indicates the destination address to be used when forwarding User Datagram Protocol
(UDP) broadcasts. The specified address can be the unicast address of a remote server or a
directed broadcast address.
If an ip helper-address command is defined, forwarding for eight default UDP ports is
enabled automatically. The default ports are TFTP (port 69), DNS (port 53), Time (port 37),
Network Basic Input/Output System (NetBIOS) name service (port 137), NetBIOS
datagram service (port 138), BOOTP server (port 67), BOOTP client (port 68), and
Terminal Access Controller Access Control System (TACACS) (port 49).
These same eight UDP ports are automatically forwarded if you define an ip helper-
address and the ip forward-protocol udp command with the same ports specified.
Use the ip forward-protocol {udp [port] | nd | sdns} global configuration command to

specify which type of broadcast packets are forwarded, as described in Table 2-3.
Table 2-3 ip forward-protocol Command Description
ip forward-protocol Command Description
udp UDP—the transport layer protocol
port (Optional) When udp is specified, UDP
destination port numbers or port names may be
specified
nd Network disk; an older protocol used by
diskless Sun workstations
sdns Network Security Protocol
To forward only one UDP port (whether a default-forwarded port, another UDP port, or a
custom port), you must use ip forward-protocol udp port command for the ports that you
want to forward, and then specify no ip forward-protocol udp port for the default ports
that you do not want forwarded.
NOTE There is no easy way to forward all UDP broadcasts; you would need to specify all the UDP
ports in the ip forward-protocol command.
DHCP and BOOTP use the same port—port 68—but it is always referred to as the BOOTP
port.
IP Helper Address Examples

In the example shown in Figure 2-15, a single server is on a single remote medium. A helper
address allows the router to perform the desired function of forwarding a client request to
a server.
Figure 2-15 IP Helper Address with a Single Server on a Remote Medium
Diskless Boot
workstation server
E0 172.16.2.2
IP broadcast
172.16.1.100
The configuration for the router in this example is shown in Example 2-2.
interface ethernet 0
ip address 172.16.1.100 255.255.255.0
ip helper-address 172.16.2.2
!
ip forward-protocol udp 3000
no ip forward-protocol udp tftp
The ip helper-address command must be placed on the router interface that receives the
original client broadcast. It causes the router to convert the 255.255.255.255 (all-ones)
broadcast to a unicast or a directed broadcast. In Example 2-2, the ip helper-address
command placed on interface Ethernet 0 would cause the default eight UDP broadcasts sent
by all hosts to be converted into unicasts with a destination address of the boot server,
172.16.2.2. These unicasts would then be forwarded to the boot server.
You may not want to forward all default UDP broadcasts to the server, but only those of a
protocol type supported on that server. To do this, use the ip forward-protocol command
followed by the keyword udp and a port number or protocol name for those UDP
broadcasts that are not automatically forwarded. Turn off any automatically forwarded
ports with the no ip forward-protocol udp port or port name command. In Example 2-2,
in addition to the default UDP broadcasts, the configuration has enabled the forwarding of
a custom application using UDP port 3000. Because the server does not support TFTP
requests, the automatic forwarding of TFTP, port 69, is disabled.
NOTE Additional helper addresses are not required on any routers in the middle of a series of
routers in the path from the client to the server. This is because the first router has modified
the destination address. The modification of the destination address from broadcast to
unicast or directed broadcast allows the packet to be routed—over several hops, if
necessary—to its final destination.
To handle forwarding broadcasts to multiple servers on the same remote medium, you can
use a directed broadcast into the subnet instead of using several unicast helper addresses.
The most general case is where multiple servers are located on different remote media. This
case can be handled by a combination of multiple helper statements, some with a unicast
and some with a directed-broadcast address. An example of this case is shown in Figure
2-16; the configuration for the router in this figure is shown in Example 2-3.
Figure 2-16 IP Helper Address With Multiple Servers on a Remote Medium
TFTP server
Unicast 172.16.3.2
DNS server BOOTP server
172.16.2.1 172.16.2.2
E0
Broadcast
Directed broadcast
to 172.16.2.255
172.16.1.100

interface ethernet 0
ip address 172.16.1.100 255.255.255.0
As Example 2-3 illustrates, a combination of helper addresses can be used on the same
interface. Broadcasts arriving on Ethernet 0 will be forwarded to all servers on the
172.16.2.0 subnet and to the designated server (172.16.3.2) on the 172.16.3.0 subnet.
NOTE All broadcast traffic for the specified UDP ports (the default ports in Example 2-3) will be
forwarded to both the 172.16.2.0 subnet and the 172.16.3.2 server. This will occur even for
traffic that cannot be handled by the servers on that subnet. For example, DNS requests will
be sent to the 172.16.3.2 TFTP server. Assuming that the DNS service is not enabled on the
172.16.3.2 device, this DNS request will be ignored and an ICMP “port unreachable”
message will be generated. This sequence consumes bandwidth on the network.
Summary
In this chapter, you learned about IP addressing issues—address exhaustion and routing
table growth—and solutions to these problems.
Hierarchical addressing can result in smaller routing tables and efficient allocation of
addresses.
Using VLSMs can result in even more efficient use of IP addresses by allowing the use of
multiple subnet masks within the same major network. VLSM addresses can then be
summarized to reduce the routing table size.
Route summarization is a method of representing a series of network numbers in a single
summary address. Summarizing of discontiguous subnets—subnets of the same major
network that are separated by a different major network—requires care. Classful routing
protocols do not support discontiguous subnets. Classless routing protocols do support
discontiguous subnets.
CIDR is a solution developed to allow multiple Class C addresses to be combined into a
larger classless set of IP addresses.
The use of an unnumbered interface in IP allows IP processing on a serial interface without
using an explicit IP address.
Helper addresses facilitate connectivity on networks by forwarding selected broadcasts to
specified servers.
The next section of this book is Part II, “Scalable Routing Protocols.” Part II discusses
details of the OSPF, EIGRP, and BGP routing protocols.
CHAPTER
3
Configuring OSPF in a Single
Area
This chapter covers the use, operation, configuration, and verification of OSPF in a single
area. After you complete this chapter, you will be able to enumerate the main features of
OSPF using the proper related terminology. You will also be able to describe the different
modes of operation for both LAN and WAN environments. Finally, you will be able to
configure and verify OSPF operations within a single area.
NOTE OSPF was written for large and growing networks. It enables you to segregate the
internetwork into smaller areas. This chapter discusses how OSPF operates within an area.
Chapter 4, “Interconnecting Multiple OSPF Areas,” discusses how the areas interoperate
with each other.
OSPF Overview
OSPF is a link-state technology, as opposed to a distance vector technology such as Routing
Information Protocol (RIP). The OSPF protocol performs the two primary functions of
every routing protocol algorithm: path selection and path switching. The Internet
Engineering Task Force (IETF) developed OSPF in 1988. The most recent version, known
as OSPF version 2, is described in RFC 2328. OSPF is an Interior Gateway Protocol (IGP),
which means that it distributes routing information between routers belonging to the same
autonomous system. OSPF was written to address the needs of large, scalable internetworks
that RIP could not. OSPF addresses the following issues:
• Speed of convergence—In large networks, RIP convergence can take several minutes
as the routing algorithm goes through a holddown and route-aging period. With OSPF,
convergence is faster than with RIP because routing changes are flooded immediately
and are computed in parallel.
• Support for variable-length subnet masks (VLSMs)—OSPF supports subnet
masking and VLSMs, as opposed to RIPv1, which supports only fixed-length subnet
masking (FLSM). (Note that RIPv2 does support VLSMs.)
100 Chapter 3: Configuring OSPF in a Single Area
• Network reachability—A RIP network that spans more than 15 hops (15 routers) is
considered unreachable. OSPF has virtually no reachability limitations.
• Use of bandwidth—RIP broadcasts complete routing tables to all neighbors every 30
seconds. This operation is especially problematic over slower WAN links. OSPF
multicasts link-state updates and sends these updates only when there is a change in
the network. (Note that OSPF sends updates every 30 minutes to ensure that all routers
are synchronized.)
• Method for path selection—RIP has no concept of network delays (interface delays)
and link costs. With RIP, routing decisions are based purely on hop count, which could
lead to suboptimal path selection so that a longer path (in terms of hop count) might
have a higher aggregate link bandwidth and shorter delays. OSPF uses a cost value,
which for Cisco routers is based on the speed of the connection. As with RIP and
IGRP, OSPF also provides support for equal-cost multipaths.
Note that although OSPF was written for large networks, implementing it requires proper
design and planning. This is especially important if your network has more than 50 routers.
OSPF information is carried inside IP packets, using protocol number 89 (decimal), as
Figure 3-1 OSPF in an IP Packet
89 - OSPF
6 - TCP
17 - UDP
Frame payload C
Frame
IP Protocol R
header Packet payload
header number C
OSPF Terminology 101
OSPF Terminology
You will want to be familiar with the following terms related to link-state technology and
OSPF before proceeding with the rest of the chapter. These terms are represented in
Figure 3-2:
• Interface—The connection between the router and one of its attached networks. An
interface is sometimes referred to as a link in OSPF literature.
• Link state—The status of a link between two routers—that is, a router’s interface and
its relationship to its neighboring routers. The link states are advertised to other
routers in special packets called link-state advertisements (LSAs).
• Cost—The value assigned to a link. Rather than hops, link-state protocols assign a
cost to a link; for OSPF on Cisco routers, the cost is based on the speed of the media.
A cost is associated with the output side of each router interface, referred to as
interface output cost.
• Autonomous system—A group of routers exchanging routing information using a
common routing protocol.
• Area—A collection of networks and routers that have the same area identification.
Each router within an area has the same link-state information. A router within an area
is an internal router.
• Neighbors—Two routers that have interfaces on a common network. A neighbor
relationship is usually discovered and maintained by the Hello protocol.
• Hello—Protocol used by OSPF to establish and maintain neighbor relationships.
• Neighborship database—A listing of all the neighbors to which a router has
established bidirectional communication.
• Link-state database (also known as a topology database)—A list of link-state
entries of all other routers in the network. It shows the network topology. All routers
within an area have identical link-state databases. The link-state database is pieced
together from LSAs generated by routers.
• Routing table (also known as the forwarding database)—Generated when the
shortest path first (SPF) algorithm (also known as the Dijkstra algorithm) is run on the
link-state database. The content of each OSPF routing table is unique.
Figure 3-2 Link-State and OSPF Components
Autonomous system
Neighbors
Interfaces
DR
Area 1 Cost=10
Area 0
Token
Ring Cost=6
Cost=1785
BDR
Neighborship Topology Routing

database database table
Lists neighbors Lists all routes Lists best routes
OSPF can run over broadcast networks or over nonbroadcast networks. The topology of a
network has an impact on how neighborship is created. Figure 3-3 illustrates the following
topologies found in OSPF:
• Broadcast multiaccess topologies—Networks supporting more than two routers
attached together, with the capability of addressing a single physical message (a
broadcast) to all the attached routers. An Ethernet segment is an example of a
broadcast multiaccess network.
• Point-to-point topologies—A network that joins a single pair of routers. A T1
dedicated serial line is an example of a point-to-point network.
• Nonbroadcast multiaccess (NBMA) topologies—Networks supporting many (more
than two) routers, but having no broadcast capability. Frame Relay and X.25 are
examples of nonbroadcast multiaccess networks.
OSPF Operation in a Broadcast Multiaccess Topology 103
Figure 3-3 OSPF Topologies
Broadcast
multiaccess
Point-to-point
NBMA X.25
Frame Relay
OSPF Operation in a Broadcast Multiaccess Topology

This section covers OSPF behavior with a broadcast multiaccess topology. The other
topologies are covered later in this chapter.
Because OSPF routing is dependent on the status of a link between two routers, neighbor
routers must recognize each other on the network before they can share information. This
process is done using the Hello protocol. The Hello protocol is responsible for establishing
and maintaining neighbor relationships. It ensures that the communication between
neighbors is bidirectional—a router sees itself listed in the hello packet that it receives from
a neighbor.
Hello packets are sent out periodically from each interface participating in OSPF using IP
multicast address 224.0.0.5, which is also known as the AllSPFRouter address.
OSPF Multicast and MAC Addresses

OSPF sends all advertisements using multicast addressing. Except for Token Ring, the
multicast IP addresses are mapped to MAC-level multicast addresses. The MAC address
used for 224.0.0.5 is 010005E 0000005, and the MAC address for 244.0.0.6 is 010005E
0000006. Cisco maps Token Ring multicast IP addressses to MAC-level broadcast
addresses.
The information contained in a hello packet, shown in Figure 3-4, is as follows:

• Router ID—This 32-bit number uniquely identifies the router within an autonomous
system. The highest IP address on an active interface is chosen by default. For
example, IP address 172.16.12.1 would be chosen over 172.16.1.1. This identification
is important in establishing neighbor relationships and coordinating messages
between copies of the SPF algorithm running in the network. Also, the router ID is
used to break ties during the designated router (DR) and backup designated router
(BDR) election process if the priority values are equal. (DR and BDR are discussed
later in this chapter.)
• Hello and dead intervals—The hello interval specifies the frequency in seconds that
a router sends hellos (10 seconds is the default on multiaccess networks). The dead
interval is the time in seconds that a router waits to hear from a neighbor before
declaring the neighbor router down (this is four times the hello interval, by default).
These timers must be the same on neighboring routers.
• Neighbors—These are the neighbors with which a bidirectional communication has
been established. Bidirectional communication is indicated when the router sees itself
listed in the neighbor’s hello packet. A neighbor might have multiple neighbors while
connecting to broadcast and NBMA topologies.
• Area-ID—To communicate, two routers must share a common segment. Also, their
interfaces must belong to the same area on that segment (they must also share the
same subnet number and mask). These routers will all have the same link-state
information.
• Router priority—This 8-bit number indicates the priority of this router when
selecting a DR and a BDR. The higher the router priority, the greater the chances are
that it will be elected the DR or the BDR. Because each multiaccess link has its own
election process, a router priority for that link is set at the interface configuration
mode.
• DR and BDR IP addresses—These are the IP addresses of the DR and BDR for the
specific network, if known (covered in the next section).
• Authentication password—If authentication is enabled, two routers must exchange

the same password. Authentication does not have to be set, but if it is set, all peer
routers must have the same password.
• Stub area flag—A stub area is a special area that is discussed in Chapter 4. Two
routers must agree on the stub area flag in the hello packets.
Figure 3-4 Contents of an OSPF Hello Packet
D E
Hello
B A C Router ID
afadjfjorqpoeru Hello/dead intervals*
39547439070713
Neighbors
Area-ID*
Hello Router priority
DR IP address
BDR IP address
Authentication password*
Stub area flag*
* Entry must match on neighboring routers
OSPF Packet Header

The following descriptions summarize the header fields of an OSPF packet, as illustrated
in Figure 3-5.
• Version number—Identifies the OSPF version used.
• Type—Identifies the OSPF packet type as one of the following:
— Hello: Establishes and maintains neighbor relationships.
— Database description: Describes the contents of the topological database.
These messages are exchanged when an adjacency is initialized.
(Adjacency is discussed in the following section.)
— Link-state request: Requests portions of the topological database from

neighbor routers. These messages are exchanged after a router discovers
(by examining database description packets) that parts of its topological
database are out-of-date.
— Link-state update: Responds to a link-state request packet. These messages
are also used for the regular dispersal of LSAs. Several LSAs can be
included within a single link-state update packet.
— Link-state acknowledgment: Acknowledges link-state update packets.
• Packet length—Identifies the packet length, including the OSPF header, in bytes.
• Router ID—Identifies the source of the packet.
• Area ID—Identifies the area to which the packet belongs. All OSPF packets are
associated with a single area.
• Checksum—Checks the entire packet contents for any damage suffered in transit.
• Authentication type—Contains the authentication type. All OSPF protocol
exchanges are authenticated. The authentication type is configurable on a per-area
basis. Type 0 indicates no authentication. Type 1 indicates a clear-text authentication.
Type 2 indicates an MD5 authentication.
• Authentication—Contains authentication information.
• Data—Contains encapsulated upper-layer information (actual routing information).
Figure 3-5 OSPF Header Format
Field length,
in bytes 1 1 2 4 4 2 2 8 Variable
Authen-
Version Packet
Type Router ID Area ID Checksum tication Authentication Data
number length
type
Designated Router and Backup Designated Router

The routers on a multiaccess environment, such as an Ethernet segment, must elect a DR
and a BDR to represent the network. The BDR does not perform any DR functions when
the DR is operating. Instead, it receives all information but allows the DR to perform the
forwarding and synchronization tasks. The BDR performs DR tasks only if the DR fails.
The DR and BDR add value to the network in the following ways:
• Reducing routing update traffic—The DR and BDR act as a central point of contact
for link-state information exchange on a given multiaccess network. Therefore, each
router must establish an adjacency with the DR and BDR. Instead of each router
exchanging link-state information with every other router on the segment, each router
sends the link-state information to the DR and the BDR. The DR represents the
multiaccess network in the sense that it sends each router’s link-state information to
all other routers in the multiaccess network. This flooding process significantly
reduces the router-related traffic on a segment.
• Managing link-state synchronization—The DR and BDR assure that the other
routers on the network have the same link-state information about the internetwork.
In this way, the number of routing errors is reduced.
An adjacency is the relationship that exists between a router and its DR and BDR. Adjacent
routers will have synchronized link-state databases (as described later in this section).
Adjacency is based upon the use of a common media segment, such as two routers
connected on the same Ethernet segment. When routers first come up on a network, they
perform the hello process (as discussed later in this section) and elect the DR and BDR. The
routers then attempt to form adjacencies with the DR and BDR.
NOTE After a DR and a BDR are elected, any router added to the network will establish
adjacencies only with the DR and the BDR.
To elect a DR and a BDR, the routers view each other’s priority value during the hello
packet exchange process, as shown in Figure 3-6. They then use the following conditions
to determine which is elected:
• The router with the highest priority value is the DR.
• The router with the second-highest priority value is the BDR.
• The default for the interface OSPF priority is 1. In case of a tie, the router ID is used.
The router with the highest router ID then becomes the DR, and the router with the
second-highest router ID then becomes the BDR. (Note that the highest IP address on
an active interface is normally used as the router ID, but this can be overridden by
configuring an IP address on a loopback interface.)
• A router with a priority set to 0 is ineligible to become a DR or a BDR. A router that
is not the DR or the BDR is also referred to as a “Drother.”
• If a router with a higher priority value gets added to the network, the DR and BDR do
not change. A DR or BDR changes only if one goes down. If the DR goes down, the
BDR takes over as the DR, and a new BDR is elected. If the BDR goes down, a new
BDR is elected. To determine whether the DR is down, the BDR sets a timer. This is
a reliability feature. If the BDR does not hear the DR forwarding LSAs before the
timer expires, then the BDR assumes that the DR is out of service.
Figure 3-6 Election of DR and BDR
Priority=3 Priority=2
DR BDR
Hello
Priority=1 Priority=1 Priority=0
In a multiaccess environment, each network segment will have its own DR and BDR.
Therefore, a router that is connected to multiple networks can be a DR on one segment and
a regular router on another segment. How neighbors are perceived in other network
topologies is discussed later in this chapter in the sections “OSPF Operation in an NBMA
Topology” and “OSPF Operation in a Point-to-Point Topology.”
Example 3-1 provides sample debug output of the DR/BDR election process performed on
an Ethernet segment.
Example 3-1 Broadcast Multiaccess Adjacency Sample debug Output
Router#debug ip ospf adj
Ethernet interface coming up: Election
OSPF: 2 Way Communication to 192.168.0.10 on Ethernet0, state 2WAY
OSPF: end of Wait on interface Ethernet0
OSPF: DR/BDR election on Ethernet0
OSPF: Elect BDR 192.168.0.12
OSPF: Elect DR 192.168.0.12
DR: 192.168.0.12 (Id) BDR: 192.168.0.12 (Id)
OSPF: Send DBD to 192.168.0.12 on Ethernet0 seq 0x546 opt 0x2 flag 0x7 len 32
<...>
DR: 192.168.0.12 (Id) BDR: 192.168.0.11 (Id)
OSPF Startup
This section covers the steps involved when routers running OSPF come up on a network.
Exchange Process
In the first step of OSPF startup, the exchange process takes place using the Hello protocol,
as shown in Figure 3-7. The following explains the exchange process, when all routers are
coming up on the network at the same time:
Step 1 Router A is enabled on the LAN and is in a down state because it has not
exchanged information with any other router. It begins by sending a hello
packet through each of its interfaces participating in OSPF, even though
it does not know the identity of any routers, including the DR. The hello
packet is sent out using multicast address 224.0.0.5.
Step 2 All routers running OSPF receive the hello packet from Router A and add
Router A to their list of neighbors. This is the init state.
Step 3 All routers that received the packet send a unicast reply hello packet to
Router A with their corresponding information, as listed in Step 1. The
neighbor field includes all other neighboring routers, including Router A.
Step 4 When Router A receives these packets, it adds all the routers that had its
router ID in their hello packet to its own neighborship database. This is
referred to as the two-way state. At this point, all routers that have each
other in their own list of neighbors have established bidirectional
communication.
Step 5 The routers determine who the DR and BDR will be, using the process
described earlier. This process must occur before routers can begin
exchanging link-state information.
Step 6 Periodically (every 10 seconds, by default) the routers within a network
exchange hello packets to ensure that communication is still working.
The hello updates include the DR, the BDR, and the list of routers whose
hello packets have been received by the router. Remember that received
means that the receiving router saw its own router ID as one of the entries
in the received hello packet.
NOTE No election will be declared if a new router with a better router ID value joins the
multiaccess network.
Figure 3-7 OSPF Exchange Process
172.16.5.1/24 172.16.5.2/24
E0 E1
Router A Router B
Down state
I am router ID 172.16.5.1, and I see no one.
Init state
Router B
neighbors list
172.16.5.1/24, int E1
I am router ID 172.16.5.2, and I see 172.16.5.1.
Router A
neighbors list
172.16.5.2/24, int E0
Two-way state
Discovering Routes
When the DR and BDR have been elected, the routers are considered to be in the exstart
state and are ready to discover the link-state information about the internetwork and create
their link-state databases. The process used to discover the network routes is called the
exchange protocol and is performed to get the routers to a full state of communication. The
first step in this protocol is for the DR and the BDR to establish adjacencies with each of
the other routers. When adjacent routers are in a full state, they do not redo the exchange
protocol unless the full state changes.
The exchange protocol, as illustrated in Figure 3-8, operates as follows:
Step 1 In the exstart state, the DR and the BDR establish adjacencies with each
router in the network. During this process, a master-slave relationship is
created between each router and its adjacent DR and BDR. The router
that has the higher router ID acts as the master.
Note that link-state information is exchanged and synchronized only
between the DR and BDR and the routers to which they have established
adjacencies because having the DR represent the network in this capacity
reduces the amount of routing update traffic.
Step 2 The master and slave routers exchange one or more database description
packets (DBDs, sometimes referred to as DDPs). The routers are in the
exchange state.
A DBD includes the LSA headers (summary) information of the LSA
entries that appear in the master router’s link-state database. The entries
can be about a link or about a network (there are different types of LSAs;
these are discussed in Chapter 4). Each LSA header includes such things
as a link-state type, the address of the advertising router, and the LSA
sequence number. The LSA sequence number is the way a router
determines the newness of the received link-state information. The DBD
also includes a DBD sequence number to ensure that all the DBDs are
received in the database synchronization process. The master defines the
DBD sequence numbers.
Step 3 When the slave router receives the DBD, it does the following:
— Acknowledges the receipt of the DBD by echoing the DBD

sequence numbers in a link-state acknowledgment (LSAck) packet.
— Compares the information it received with the information it has by
checking the LSA sequence number in the LSA header. If the DBD
has a more up-to-date link-state entry, the slave router sends a link-
state request (LSR) to the master router.
— The master router responds with the complete information about
the requested entry in a link-state update (LSU) packet. Again, the
slave router sends an LSAck when the LSU is received. The process
of sending LSRs is referred to as the loading state.
Step 4 All routers add the new link-state entries into their link-state database.
Step 5 When all LSRs have been satisfied for a given router, the adjacent routers
are considered synchronized and in a full state. The routers must be in a
full state before they can route traffic. At this point, the routers should all
have identical link-state databases.
Choosing Routes
When a router has a complete link-state database, it is ready to create its routing table so
that it can route traffic, as shown in Figure 3-9. Recall that distance vector protocols such
as RIP select the best route to a destination based on a hop-count metric using the Bellman-
Ford algorithm. However, link-state protocols use a cost metric to determine the best path
to a destination.
Figure 3-8 Discovering Routes with OSPF
DR
E0 E0
172.16.5.1 172.16.5.3
Exstart state
I will start exchange because I have router ID 172.16.5.1.

Hello
No, I will start exchange because I have a higher router ID.

Hello
Exchange state
Here is a summary of my link-state database.

DBD
Here is a summary of my link-state database.

DBD
Thanks for the information!

LSAck LSAck
Loading state
I need the complete entry for network 172.16.6.0/24.

LSR
Here is the entry for network 172.16.6.0/24.

LSU
Thanks for the information!

LSAck
Full state
Figure 3-9 Choosing the Best Route to be Inserted in the Routing Table
A 10.1.1.0/24 B 10.2.2.0/24 C 10.3.3.0/24

Token
Ring FDDI
Cost=6
Cost=10
Cost=1
Cost=10
10.4.4.0/24
Topology Table
Net Cost Out Interface
10.2.2.0 7 To0
10.3.3.0 17 To0 This is the best route to 10.3.3.0.
10.3.3.0 20 E0
On Cisco routers, the default cost metric is based on media bandwidth. For example,
10-Mbps Ethernet has a lower cost than a 56-kbps line because it is faster.
To calculate the lowest cost to a destination, link-state protocols such as OSPF use the
Dijkstra algorithm. Using its link-state database as input, a router runs the Dijkstra
algorithm, thus building its routing table step-by-step. In simple terms, the algorithm adds
up the total costs between the local router (the root) and each destination network. If there
are multiple paths to a destination, the lowest-cost path is preferred. Note that OSPF keeps
up to six equal-cost route entries in the routing table for load balancing.
OSPF and Load Balancing

By default, four equally good routes to the same destination are kept in the routing table for
load balancing. However, with the maximum-paths router configuration command, this
value can be increased to up to six equally good routes to the same destination.
Sometimes a link, such as a serial line, will go up and down rapidly (called flapping), or a
link-state change may affect another series of links. In these situations, a series of LSUs
could be generated, which would cause routers to repeatedly recompute a new routing table.
This flapping could be so serious that the routers would never converge. To minimize this
problem, each time an LSU is received, the router waits for a period of time before
recalculating its routing table. The default for this time is 5 seconds. The timers spf spf-
delay spf-holdtime router configuration command in the Cisco IOS software allows this
value and the minimum time between two consecutive SPF calculations (which has a
default of 10 seconds) to be configured.
Refer to the OSPF version 2 RFC 2328 for a detailed description of the Dijkstra algorithm.
Maintaining Routing Information

In a link-state routing environment, it is very important for all routers’ topological
databases to stay synchronized. When there is a change in a link state, the routers use a
flooding process to notify the other routers in the network of the change, as shown in Figure
3-10. Link-state update packets provide the mechanism for flooding LSAs.
Figure 3-10 Link-State Updates Inform Routers of Topology Changes
2
Link-state change
LSU
DR
I need to update
4
my routing table.
1
LSU
3
Router B
Router A LSU
– Router A tells all OSPF DRs on 224.0.0.6

– DR tells others on 224.0.0.5
NOTE Although not shown in Figure 3-10, all LSUs are acknowledged.
The flooding process on a multiaccess link is as follows:

Step 1 A router notices a change in a link state and multicasts an LSU packet
that includes the updated LSA entry to 224.0.0.6, which is the address of
all OSPF DRs and BDRs. An LSU packet may contain several distinct
LSAs.
Step 2 The DR acknowledges the receipt of the change and floods the LSU to
others on the network using the OSPF multicast address 224.0.0.5. To
make the flooding procedure reliable, each LSA must be acknowledged
separately. After receiving the LSU, each router responds to the DR with
an LSAck.
Step 3 If a router is connected to another network, it floods the LSU to other
networks by forwarding the LSU to the DR of the multiaccess network,
or to the adjacent router if in a point-to-point network. In turn, the DR
multicasts the LSU to the other routers in the network.
Step 4 When a router receives the LSU that includes the changed LSA, the
router updates its link-state database. It then computes the SPF algorithm
with the new database to generate a new routing table. After a short delay,
it switches over to the new routing table. Remember, as mentioned
earlier, each time an LSU is received, the router waits for a period of time
before recalculating its routing table to reduce the effects of flapping
routes.
OSPF simplifies the synchronization issue by requiring only adjacent routers to remain
synchronized.
NOTE In a Cisco router, if a route already exists, the routing table is used at the same time the SPF
is calculating. However, if the SPF is calculating a new route, the use of the routing table
occurs after the SPF calculation is complete.
Each LSA entry has its own aging timer, carried in the LS age field. The default timer value
is 30 minutes (it is expressed in seconds in the LS age field). After an LSA entry ages, the
router that originated the entry sends an LSU about the network to verify that the link is still
active. This validation method saves on bandwidth compared to distance vector routers,
which send their entire routing table to their neighbors.
Figure 3-11 illustrates the following analysis done by a router upon receiving an LSU:
• If the entry does not already exist, the router adds the entry to its link-state database,
sends an LSAck to the DR, floods the information to other routers, and updates its
routing table.
• If the entry already exists and the received LSU has the same information, the router
ignores the LSA entry.
• If the entry already exists but the LSU includes new information, the router adds the
entry to its link-state database, sends an LSAck to the DR, floods the information to
other routers, and updates its routing table.
• If the entry already exists but the LSU includes older information, the router sends an
LSU to the sender with its newer information.
Figure 3-11 Analyzing an LSU
LSU Is entry in Is sequence

LSA link-state number Ignore LSA
database? Yes Yes
the same?
No No
Yes
Add to database
Is sequence
Send LSAck number
to DR higher?
No
Flood LSA
Send LSU
with newer
Run SPF to calculate information to
new routing table source
End End
NOTE Many different types of LSAs exist. This chapter covers the router link LSA, which is
an LSA about a link and its status, and the network LSA, which the DR sends out. The
network LSA describes all the routers attached to a multiaccess segment. Chapter 4
discusses other LSA types.
OSPF Operation in a Point-to-Point Topology

A point-to-point network joins a single pair of routers. A T1 serial line is an example of a
point-to-point network.
On point-to-point networks, the router dynamically detects its neighboring routers by
sending its hello packets to the multicast address AllSPFRouters, 224.0.0.0.5. On physical
point-to-point networks, neighboring routers become adjacent whenever they can
OSPF Operation in an NBMA Topology 117
communicate directly. No election is performed, and there is no concept of DR or BDR, as

shown in Example 3-2.
Example 3-2 Point-to-Point Topology—Adjacency Election
Router#debug ip ospf adj
Point-to-point interfaces coming up: No election
OSPF: Interface Serial1 going Up
OSPF: Rcv Hello from 192.168.0.11 area 0 from Serial1 10.1.1.2
OSPF: End of Hello processing
OSPF: Build router LSA for area 0, router ID 192.168.0.10
OSPF: Rcv DBD from 192.168.0.11 on Serial1 seq 0x20C4 opt 0x2 flag 0x7 len 32 state
INIT
OSPF: 2 Way Communication to 192.168.0.11 on Serial1, state 2WAY
OSPF: Send DBD to 192.168.0.11 on Serial1 seq 0x167F opt 0x2 flag 0x7 len 32
OSPF: NBR Negotiation Done. We are the SLAVE
OSPF: Send DBD to 192.168.0.11 on Serial1 seq 0x20C4 opt 0x2 flag 0x2 len 72
Usually, the IP source address of an OSPF packet is set to its outgoing interface address. It
is possible to use IP unnumbered interfaces with OSPF. On these interfaces, the IP source
address will be set to the IP addresses of another interface of the router. (IP unnumbered is
discussed in Chapter 2, “Extending IP Addresses.”)
The default OSPF hello and dead intervals on point-to-point topologies are 10 seconds and
40 seconds, respectively.
OSPF over Dialup Links—BRI/PRI and Asynchronous

For BRI/PRI connectivity, you should use the dialer map command in addition to the
normal OSPF configuration commands.
For asynchronous links, you should use the async default routing command in addition to
the normal OSPF configuration commands on the asynchronous interface. This command
enables the router to pass routing updates to other routers over the asynchronous interface.
In both cases, when using the dialer map command, use the broadcast keyword to indicate
that broadcasts should be forwarded to the protocol address.
OSPF Operation in an NBMA Topology

NBMA networks are those networks that support many (more than two) routers but have
no broadcast capability. When a single interface is used to interconnect multiple sites over
an NBMA network, you may have reachability issues because of the nonbroadcast nature
of the network. Frame Relay, ATM, and X.25 are examples of NBMA networks. Partially
meshed or point-to-multipoint NBMA topologies don’t guarantee that routers will receive
multicasts or broadcasts from other routers. Also, to provide broadcast capability, the
broadcast option must be enabled on VCs. For the purpose of this NBMA discussion, Frame
Relay examples are covered.
The default OSPF hello and dead intervals on NBMA topologies are 30 seconds and 120
seconds, respectively.
Default Hello and Dead Intervals

The following table contains the default hello and dead intervals for the various OSPF
environments.
OSPF Environment Hello Interval Dead Interval

Broadcast 10 seconds 40 seconds
Point-to-point 10 seconds 40 seconds
NBMA 30 seconds 120 seconds
With Frame Relay you can interconnect your remote sites in a variety of ways, as shown in
Figure 3-12.
Example topologies, as shown in Figure 3-12, include the following:
— A star topology, also known as a hub-and-spoke configuration, is the most
popular Frame Relay network topology. In this environment, remote sites
are connected to a central site, which generally provides a service or
application. This is the least expensive topology because it requires the least
number of permanent virtual circuits. In this scenario, the central router
provides a multipoint connection because it typically uses a single interface
to interconnect multiple permanent virtual circuits.
— In a full-mesh topology, all routers have virtual circuits to all other
destinations. This method, although costly, provides direct connections from
each site to all other sites and allows for redundancy. For example, when a
link to site B goes down, a router at site A can reroute traffic transiting
through site B to use site C. As the number of nodes in the full-mesh
topology increases, the topology becomes increasingly more expensive.
PVC Requirements Formula

The formula to calculate the number of PVCs required for a fully meshed topology is
(n(n – 1)) ÷ 2, where n is the number of sites. Therefore, a fully meshed WAN of 40 sites
would require 780 PVCs.
— In a partial-mesh topology, not all sites have direct access to a central site.
Figure 3-12 NBMA Topologies
Full mesh
Partial mesh
Star (hub and spoke)
By default, a Frame Relay network provides NBMA connectivity between remote sites.
Therefore, routing updates must be replicated by the routers and then distributed to each
virtual circuit.
OSPF considers the NBMA environment like any other broadcast media, such as Ethernet.
However, NBMA clouds are usually built in a hub-and-spoke topology, where permanent
virtual circuits (PVCs) or switched virtual circuits (SVCs) are laid out in a partial mesh. In
these cases, the physical topology does not provide the multiaccess that OSPF believes is
out there.
The selection of the DR becomes an issue in NBMA topologies because the DR and the
BDR need to have full physical connectivity with all routers in the NBMA network. The
DR and the BDR also need to have a list of all these other routers so that adjacencies can
be established.
OSPF over NBMA Topology—Modes of Operation

As described in RFC 2328, OSPF runs in one of two official modes in NBMA topologies:
• Nonbroadcast multiaccess (NBMA)—Emulates the operation of OSPF in a
broadcast network. That is, routers exchange update traffic to identify their neighbors
and elect a DR and a BDR. This configuration is usually seen in a fully meshed
network. Some configuration, such as defining OSPF neighbors, is necessary on the
router for this mode to work properly; this is covered in the section “Configuring
OSPF in NBMA Mode,” later in this chapter.
To implement broadcasting, the router replicates the packets to be broadcast
and individually sends them to all destinations. This process is CPU- and
bandwidth-intensive.
• Point-to-multipoint—Treats the nonbroadcast network as a collection of point-to-
point links. In this environment, the routers identify their neighbors but do not elect a
DR and a BDR. This configuration is used typically with partially meshed networks.
The choice between NBMA mode and point-to-multipoint mode determines the way that
the Hello protocol and flooding work over the nonbroadcast network, as discussed in the
sections “NBMA Mode Neighborship” and “Point-to-Multipoint Mode Neighborship,”
later in this chapter.
Additional modes defined by Cisco are point-to-multipoint nonbroadcast (an extension of
the RFC mode), broadcast, and point-to-point. These modes are discussed later in this
section.
Subinterfaces
When configuring routers in an NBMA topology, subinterfaces are typically used. A
physical interface can be split into multiple logical interfaces, called subinterfaces, with
each subinterface being defined as a point-to-point or point-to-multipoint interface.
Subinterfaces originally were created to better handle issues caused by split horizon over
NBMA and distance vector-based routing protocols. A point-to-point subinterface has the
same properties as any physical point-to-point interface.
Subinterfaces are created with the following command:
Router(config)#interface serial number.subinterface-number {multipoint | point-to-
point}
Table 3-1 explains the interface serial command.

Table 3-1 The interface serial Command

interface serial Command Description
number.subinterface-number Interface number and subinterface number. The subinterface
number is in the range 1 to 4294967293. The interface number
that precedes the period (.) must match the interface number to
which this subinterface belongs.
multipoint On multipoint subinterface routing IP, all routers are in the
same subnet.
point-to-point On point-to-point subinterface routing IP, each pair of point-
to-point routers is on its own subnet.
The default OSPF mode on a point-to-point subinterface is point-to-point mode; the default
OSPF mode on a point-to-multipoint subinterface is nonbroadcast multiaccess mode.
NBMA Mode Neighborship

In NBMA mode, OSPF emulates operation over a broadcast network. A DR and a BDR are
elected for the NBMA network, and the DR originates an LSA for the network. Note that
in this environment, the routers are usually fully meshed for adjacencies to be established
among them. (If they are not fully meshed, the DR and the BDR must be selected manually
and must have full connectivity to all other routers.) Neighbors must be statically defined
to start the DR election process. When using NBMA mode, all routers are on one subnet.
When flooding out a nonbroadcast interface in NBMA mode, the LSA update or LSAck
packet is replicated to be sent to each NBMA neighbor listed in the neighborship table.
Assuming that there are not a lot of neighbors in the network, NBMA mode is the most
efficient way to run OSPF over nonbroadcast multiaccess networks, both in terms of link-
state database size and in terms of the amount of routing protocol traffic. However, consider
the following before using this mode:
• Full mesh and direct communication—In this mode, all routers attached to the
NBMA network are usually fully meshed (or the DR and the BDR selected are
capable of communicating directly with all other routers).
• Stability of the network—Link-state routing protocols require that, for a multiaccess
environment, neighbor adjacencies have been defined for routing updates to be
exchanged. In OSPF, the DR and the BDR assure that all the routers on the same
segment have the same link-state information regarding the internetwork. If the
network is not stable, for example, any time a connection goes down, routers noticing
the link-state change multicast an update to the DR and the BDR. The DR
acknowledges the update and floods it to other routers. This traffic goes across the
NBMA network. Furthermore, any changes made to the link-state database require
the forwarding database to be recalculated, thus burdening the router CPU.
Note that if you are using a single PVC on an interface and that PVC goes down,
the interface goes down because no keepalives will be received on this interface.
This means that a link failure would be recognized. If you are running OSPF over
subinterfaces, however, and a subinterface goes down, the physical interface
remains up, so the router does not reflect that the link has gone down and that a
connectivity problem exists. When a subinterface fails, keepalives will still be
arriving from other subinterface, so the main interface will still report that the
interface is up and that the line protocol is up.
One DR and one BDR are elected per segment. The intent is to prevent the segment from
being overwhelmed with broadcast updates from all the devices on that same segment.
However, this does not mean that broadcasts are limited to those devices. When a change
occurs, the DR and the BDR handle the change for that segment. The change is then flooded
out into the area, which you will see in Chapter 4. It is possible for the Frame Relay cloud
to be its own area, therefore isolating its link-state changes from the rest of the network.
This is not a rule, however, and it depends on the customer’s network and provider.
On nonbroadcast networks where not all routers can communicate directly, you can break
the nonbroadcast network into logical subnets using subinterfaces, with the routers on each
subnet being capable of communicating directly. Then each separate subnet can be run as
an NBMA network or a point-to-point network if each virtual circuit is defined as a separate
logical subnet. However, this setting requires quite a bit of administrative overhead and is
prone to misconfiguration. It is probably better to run such a nonbroadcast network in point-
to-multipoint mode, as described next.
Point-to-Multipoint Mode Neighborship

Networks in point-to-multipoint mode are designed to work with partial mesh or star
topologies. In point-to-multipoint mode, OSPF treats all router-to-router connections over
the nonbroadcast network as if they were point-to-point links—that is, no DR or BDR is
elected, nor is an LSA generated for the network.
OSPF point-to-multipoint works by exchanging additional link-state updates that contain a
number of information elements that describe connectivity to the neighboring routers.
In large networks, using point-to-multipoint mode reduces the number of PVCs necessary
for complete connectivity because you are not required to have a fully meshed topology. In
addition, not having a fully meshed topology also reduces the number of neighbor entries
in your neighbor table.
Point-to-multipoint mode has the following properties:

• Does not require a fully meshed network—This environment allows for routing
between two routers that are not directly connected but that are connected through a
router that has virtual circuits to each of the two routers. The router that interconnects
the nonadjacent neighbors is the one configured for point-to-multipoint mode. The
other routers, assuming that they have connections to only the target router, could be
configured for point-to-point mode. (However, if a spoke router was interconnected to
the hub router and another spoke router, it would be configured as point-to-multipoint
as well.)
• Does not require static neighbor configuration—In a broadcast network, a
multicasted OSPF hello packet is used to identify the router’s neighbors. In NBMA
mode, neighbors are required to be statically defined to start the DR election process
and allow routing updates to be exchanged. However, because the point-to-multipoint
mode treats the network as a collection of point-to-point links, multicast hello packets
discover neighbors dynamically, and statically configuring neighbors is not required.
Neighbors—and the cost to each neighbor—can be defined, if desired.
• Uses one IP subnet—As in NBMA mode, when using point-to-multipoint mode, all
routers are on one IP subnet.
• Duplicates LSA packets—Also as in NBMA mode, when flooding out a
nonbroadcast interface in point-to-multipoint mode, the LSA update or LSAck packet
is replicated to be sent to each of the interfaces’ neighbors, as defined in the
neighborship table.
Additional Cisco Neighborship Modes

As mentioned, Cisco has defined additional modes for OSPF neighborship. These are
discussed in the following sections.
Point-to-Multipoint Nonbroadcast Mode

Point-to-multipoint nonbroadcast mode is a Cisco extension of the RFC-compliant
point-to-multipoint mode. With this mode, you must statically define neighbors and can
modify, if necessary, the cost of the link to the neighbor to reflect the different bandwidths
of each link. The RFC point-to-multipoint mode was developed to support underlying
point-to-multipoint virtual circuits (VCs) that support multicast and broadcast functions,
and, therefore, to allow dynamic neighbor discovery. However, some point-to-multipoint
networks use nonbroadcast media (such as classic IP over ATM, or Frame Relay SVCs) and
cannot use the RFC mode because the routers cannot dynamically discover their neighbors.
Broadcast Mode
The broadcast mode is a workaround preventing the static listing of all existing neighbors.
The interface will be logically set to broadcast and will behave as if the router were
connected to a LAN. DR and BDR election will still be performed, so special care should
be taken to assure either a full-mesh topology or a static selection of the DR based on the
interface OSPF priority.
Point-to-Point Mode
The point-to-point mode is used when only two nodes exist on the NBMA network. This
mode is typically used only with point-to-point subinterfaces. Each point-to-point
connection is one IP subnet. An adjacency is formed over the point-to-point network with
no DR or BDR election, as explained earlier in the section “OSPF Operation in a Point-to-
Point Topology.”
Table 3-2 provides a concise comparison of the different modes of operation for OSPF over
NBMA topologies.
Table 3-2 OSPF over NBMA Topology Summary
Preferred Subnet RFC- or Cisco-
Mode Topology Address Adjacency defined
NBMA Fully meshed Neighbors must Manual RFC
belong to the Configuration
same subnet DR/BDR elected
number
Broadcast Fully meshed Neighbors must Automatic Cisco
belong to the DR/BDR elected
same subnet
number
Point-to- Partially meshed Neighbors must Automatic RFC
multipoint or star belong to the No DR/BDR
same subnet
number
Point-to- Partially meshed Neighbors must Manual Cisco
multipoint or star belong to the configuration
nonbroadcast same subnet No DR/BDR
number
Point-to-point Partially meshed Different subnets Automatic Cisco
or star, using for each No DR/BDR
subinterface subinterface
Configuring OSPF in a Single Area 125
Configuring OSPF in a Single Area

In this section, you will learn the actual commands required on Cisco routers to enable the
OSPF process in a certain area. To configure OSPF, you must perform the following steps:
Step 1 Enable OSPF on the router using the router ospf process-id
configuration command. In this command, process-id is an internally
used number to identify whether you have multiple OSPF processes
running within a single router. The process-id need not match process-ids
on other routers. Running multiple OSPF processes on the same router is
not recommended because it creates multiple database instances that add
extra overhead.
Step 2 Identify which IP networks on the router are part of the OSPF network
using the network area router configuration command. For each
network, you must identify to which area the networks belong. The
network value can vary in that it can be either the network address
supported by the router or the specific interface addresses configured.
The router knows how to interpret the address by comparing the address
to the wildcard mask. Table 3-3 explains the network area command.
router(config-router)#network address wildcard-mask area area-id
Table 3-3 network area Command

network area Command Description
address Can be the network address, the subnet, or the address of
the interface. Instructs the router to know which links to
advertise to, which links to use to listen to advertisements, and
what networks to advertise.
wildcard-mask An inverse mask used to determine how to read the address.
The mask has wildcard bits, where 0 is a match and 1 is “don’t
care.” For example, 0.0.255.255 indicates a match in the first 2
bytes. If specifying the interface address, use the mask 0.0.0.0.
area area-id Specifies the area to be associated with the address. It can be a
decimal number or similar to an IP address, A.B.C.D.
Example 3-3 provides the configuration on OSPF internal Routers A and B in Figure 3-13.
Example 3-3 Configuration on Router A and Router B from Figure 3-13
<Output Omitted>
RouterA(config)#interface Ethernet0
RouterA(config-if)#ip address 10.64.0.1 255.255.255.0
!
<Output Omitted>
continues
Example 3-3 Configuration on Router A and Router B from Figure 3-13 (Continued)
RouterA(config)#router ospf 1
RouterA(config-router)#network 10.0.0.0 0.255.255.255 area 0
. . .
<Output Omitted>
RouterB(config)#interface Ethernet0
RouterB(config-if)#ip address 10.64.0.2 255.255.255.0
!
RouterB(config)#interface Serial0
<Output Omitted>
RouterB(config)#router ospf 50
RouterB(config-router)#network 10.2.1.2 0.0.0.0 area 0
Figure 3-13 Configuring OSPF on Internal Routers
Broadcast network Point-to-point network
E0 10.64.0.2 S0
10.2.1.1
10.64.0.1 E0 10.2.1.2
S1
Optional OSPF Configuration Commands

This section covers commands that can be used to modify OSPF behavior, such as
influencing the election process or how OSPF chooses the router ID, and amending the
metric calculation.
Router ID
The highest IP address on an active interface is normally used as the OSPF router ID. This
can be overriden by configuring an IP address on a loopback interface. In this case, the
highest such loopback IP address becomes the OSPF router ID.
Modifying the OSPF router ID to a loopback address first involves defining a loopback
interface:
router(config)#interface loopback number
NOTE The OSPF router ID of a router will usually change if the interface with that IP address goes
down. During testing it was noted, however, that with IOS release 12.0(8), this was no
longer the case; the router ID remained as the IP address of the down interface.
OSPF is more reliable if a loopback interface is configured because the interface is always
active and cannot go down like a real interface. For this reason, it is recommended that you
use the loopback address on key routers. If you plan to publish your loopback address with
the network area command, you might consider using a private IP address to save on your
registered IP addresses. Note that a loopback address requires a different subnet for each
router, unless the host address itself is advertised.
Pros and cons exist in using an address that will not be advertised. Using an unadvertised
address saves on real IP addresses, but the address does not appear in the OSPF table, so it
cannot be pinged. This decision represents a trade-off between the ease of debugging the
network and conservation of address space.
To determine the router ID of a router, enter the show ip ospf interface command.
Router Priority
You may want to affect which router becomes the DR or BDR, for example if you have a
higher end, more powerful router you may want to make it the DR irregardless of it’s
assigned IP address. This can be done by changing the router priority. Modifying router
priority involves changing the OSPF priority on an interface by using the following
interface command:
router(config-if)#ip ospf priority number
In this command, number is a number between 0 and 255. The default is 1. A priority value
of 0 indicates that an interface cannot be elected as a DR or a BDR. The router with the
highest priority value is the DR. The router with the second-highest priority value becomes
the BDR.
Election and Router Priority

If a router with a higher priority value gets added to the network, the DR and the BDR do not
change. A DR and a BDR change only if one goes down. If the DR goes down, the BDR takes
over as the DR and a new BDR is elected. If the BDR goes down, a new BDR is elected.
Link Cost
Modifying the link cost requires overriding the default cost value assigned to an OSPF
interface using the ip ospf cost cost command. In this command, cost is a number from 1
to 65535 that indicates the metric assigned to the interface. The path cost is the total of the
costs assigned to all interfaces that forward traffic along the path to the destination.
Cisco’s OSPF default cost assignment is based on the bandwidth of the link. Other vendors
might use a different mechanism to assign OSPF cost to a link, so you may have to change
the default cost because all interfaces connected to the same link must agree on the link’s
cost.
In general, the path cost in Cisco routers is calculated using the formula: 108 ÷ bandwidth
(in bps). Using this formula, the following are some example default costs:
• 56-kbps serial link—Default cost is 1785
• T1 (1.544-Mbps serial link)—Default cost is 64
• Ethernet—Default cost is 10
• 16-Mbps Token Ring—Default cost is 6
On serial lines, the default bandwidth is 1.544 Mbps. If the line is a slower speed, use the
bandwidth command to specify the real link speed. The cost of the link will then change
to correspond to the bandwidth that you configured.
Cost Modification
To control how OSPF calculates default metrics (cost) for the interface, use the auto-cost
reference-bandwidth router configuration command to change the numerator of the OSPF
cost formula.
As mentioned earlier, the OSPF metric is calculated as reference bandwidth divided by
bandwidth, with the reference bandwidth equal to 100 Mbps or, if you prefer, 108 bps. The
bandwidth is determined by the bandwidth command. For example, a 64-kbps link will get
a metric of 1562 because the formula is: 108 ÷ 64,000. A T1 link will have a metric of 64.
The calculation gives FDDI a metric of 1.
If you have multiple links with high bandwidth (such as FDDI or ATM), you might want to
use a larger number to differentiate the cost on those links. As an example, you may want
to use the auto-cost reference-bandwidth command when dealing with a very high-speed
link, such as with Sonet OC-12, which runs at 622 Mbps. The standard metric formula
would be 108 ÷ 622,000,000 bps, which would produce a cost of 0.16.
NOTE Changing the bandwidth on interfaces or the reference bandwidth under router ospf will
cause SPF calculations on all routers.
In the following command, reference-bandwidth is a number in Mbps. The range is 1 to

4294967; the default is 100 Mbps (108 bps).
router(config-router)#auto-cost reference-bandwidth reference-bandwidth
Any change using this command must be done on all routers in the AS so that they are all
using the same formula to calculate cost. The value set by the ip ospf cost command
overrides the calculated cost resulting from the auto-cost command.
NOTE In the Cisco IOS documentation, the auto-cost command is documented as ospf auto-cost.
However, auto-cost is the actual command in the Cisco IOS, as tested with IOS 12.0.
Configuring OSPF over NBMA Topology

In the section “OSPF Operation in an NBMA Topology,” earlier in this chapter, you saw
that OSPF over NBMA topologies can be configured in different modes, as follows:
• RFC-compliant modes:
— NBMA mode
— Point-to-multipoint mode
• Cisco-defined modes:
— Point-to-multipoint nonbroadcast mode
— Broadcast mode
— Point-to-point mode
The ip ospf network command, typed under the interface configuration mode, is used to
specify the OSPF network mode configuration (note that this is not necessarily the physical
interface configuration). The possible modes are listed in Table 3-4.
Table 3-4 ip ospf network Command Modes
Mode Description
nonbroadcast Sets the network mode to nonbroadcast multiaccess
mode (also known as the NBMA mode). This is the
default mode for NBMA interfaces and point-to-
multipoint subinterfaces.
point-to-multipoint Sets the network mode to point-to-multipoint.
point-to-multipoint nonbroadcast Sets the network mode to point-to-multipoint
nonbroadcast.
broadcast Sets the network mode to broadcast. This is the default
mode for broadcast multiaccess networks, such as
Ethernet.
point-to-point Sets the network mode to point-to-point. This is the
default mode for point-to-point interfaces and
subinterfaces.
Configuring OSPF in NBMA Mode

In NBMA mode, the selection of the DR is an issue because the DR and BDR need to have
full physical connectivity with all routers connected to the cloud. Also, because of the lack
of broadcast capabilities, the DR and the BDR need to have a static list of all other routers
attached to the cloud—that is, a list of their OSPF neighbors. This is achieved with the use
of the neighbor command.
NOTE The neighbor command became somewhat obsolete with the introduction of the capability
to configure other network modes for the interface, regardless of the underlying physical
topology.
The neighbor command, as follows, is used to configure OSPF routers interconnecting to

nonbroadcast networks. The different options used with the neighbor command are
explained in Table 3-5.
Router(config-router)#neighbor ip-address [priority number]
[poll-interval sec] [cost number]
Table 3-5 neighbor Command

Command Description
ip-address Interface IP address of the neighbor
priority number (Optional) An 8-bit number indicating the router priority value of
the nonbroadcast neighbor associated with the IP address specified.
The default is 0. This keyword does not apply to point-to-multipoint
mode interfaces.
poll-interval sec (Optional) Unsigned integer value reflecting the poll interval. RFC
1247 recommends that this value be much larger than the hello
interval. The default is 120 seconds. This keyword does not apply to
point-to-multipoint mode interfaces.
If a neighboring router has become inactive (hello packets have not
been seen for the router dead interval period), it may still be
necessary to send hello packets to the dead neighbor. These hello
packets will be sent at a reduced rate called a poll interval.
cost number (Optional) A cost assigned to the neighbor, in the form of an integer
from 1 to 65535. Neighbors with no specific cost configured will
assume the cost of the interface, based on the bandwidth or the ip
ospf cost command. On point-to-multipoint mode interfaces, this is
the only keyword and argument that make sense. This keyword does
not apply to NBMA mode networks.
Example 3-4 shows the use of the neighbor command.

Example 3-4 Configuring OSPF in NBMA Mode Using the neighbor Command
R1(config)#interface Serial0
R1(config-if)#ip address 10.1.1.1 255.255.255.0
R1(config-if)#encapsulation frame-relay
R1(config-if)#ip ospf network non-broadcast
R1(config)#router ospf 1
R1(config-router)#network 10.1.1.0 0.0.0.255 area 0
R1(config-router)#neighbor 10.1.1.2
NOTE NBMA mode is used by default, so there is no need for the ip ospf network non-broadcast
command. However, neighbor statements are necessary.
Configuring OSPF in Point-to-Multipoint Mode

An OSPF point-to-multipoint interface is seen as one or more numbered point-to-point
interfaces. The WAN cloud is configured as one subnet.
Example 3-5 provides a sample of the configuration necessary when using the OSPF in
point-to-multipoint mode (point-to-multipoint broadcast mode because the keyword non-
broadcast is not specified).
Example 3-5 OSPF in Point-to-Multipoint Mode Configuration
R1(config-if)#ip ospf network point-to-multipoint
NOTE The point-to-multipoint non-broadcast keyword is a new feature related to point-to-

multipoint networks with Cisco IOS Release 11.3a. You can find more information on the
subject by searching CCO (cisco.com) with these keywords: OSPF point-to-multipoint
network with separate costs per neighbor.
Without the non-broadcast keyword, the point-to-multipoint network is considered to be
a broadcast network, and the mode is compliant with the RFC. There is no need to specify
neighbors. However, you can specify neighbors with the neighbor command, in which case
you should specify a cost to each neighbor.
With the non-broadcast keyword, the point-to-multipoint network is considered to be a

nonbroadcast network, and the mode is a Cisco extension. The neighbor command is
required to identify neighbors. Assigning a cost to a neighbor is optional.
Configuring OSPF in Broadcast Mode

Configuring broadcast mode is a workaround for using the neighbor command, where the
administrator must hard code all existing neighbors. This broadcast mode works best with
a fully meshed network. Example 3-6 shows a typical configuration of OSPF in broadcast
mode.
Example 3-6 Configuration Example of OSPF in Broadcast Mode
R1(config-if)#ip ospf network broadcast
Configuring OSPF in Point-to-Point Mode

In point-to-point mode, OSPF considers each subinterface as a physical point-to-point
network, so the adjacency is automatic.
The following steps explain how to configure OSPF point-to-point mode on subinterfaces,
as shown in Example 3-7:
Step 1 Go into the interface configuration mode of the interface on which you
will create subinterface.
Step 2 It is recommended that you remove any network layer address assigned
to the physical interface, and assign the network layer address to the
subinterface.
Step 3 Configure Frame Relay encapsulation.
Step 4 Configure the subinterfaces as discussed earlier in the “OSPF over

NBMA Topology—Modes of Operation” section.
Step 5 Configure network layer addresses and Frame Relay data-link
connection identifier (DLCI) numbers on the subinterface.
Step 6 Point-to-point mode is the default OSPF mode for point-to-point
subinterfaces, so no further configuration is required.
Verifying OSPF Operation 133
Example 3-7 Example of a Configuration of OSPF in Point-to-Point Mode

R1(config-if)#no ip address
R1(config)#interface Serial0.1 point-to-point
R1(config-subif)#ip address 10.1.1.1 255.255.255.0
R1(config-subif)#frame-relay interface-dlci 51
R1(config)#interface Serial0.2 point-to-point
R1(config-subif)#ip address 10.1.2.1 255.255.255.0
R1(config-subif)#frame-relay interface-dlci 52
Verifying OSPF Operation

The commands covered in this section can be used to verify OSPF operation and statistics.
The show ip protocols command, shown in Example 3-8, displays parameters about
timers, filters, metrics, networks, and other information for the entire router.
Example 3-8 show ip protocols Command Output
Router#show ip protocols
Routing Protocol is “ospf 200“
Sending updates every 0 seconds
Invalid after 0 seconds, hold down 0, flushed after 0
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: ospf 200
Routing for Networks:
192.168.1.0
Routing Information Sources:
Gateway Distance Last Update
192.168.1.66 110 00:09:40
192.168.1.49 110 00:09:13
172.16.11.100 110 00:09:50
Distance: (default is 110)
The show ip route command, shown in Example 3-9, displays the routes known to the
router and how they were learned. This is one of the best ways to determine connectivity
between the local router and the rest of the internetwork.
Example 3-9 show ip route Command Output
p1r1#show ip route
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
U - per-user static route, o - ODR
continues
Example 3-9 show ip route Command Output (Continued)

T - traffic engineered route

O 192.168.1.64 [110/1572] via 192.168.1.50, 00:06:28, Serial2
[110/1572] via 192.168.1.34, 00:06:28, Serial1
[110/1572] via 192.168.1.18, 00:06:28, Serial0
The show ip route ospf command, shown in Example 3-10, displays strictly OSPF routes.
Example 3-10 show ip route ospf Command Output
p1r1#show ip route ospf
O 192.168.1.64 [110/1572] via 192.168.1.50, 00:06:33, Serial2
[110/1572] via 192.168.1.34, 00:06:33, Serial1
[110/1572] via 192.168.1.18, 00:06:33, Serial0
The show ip ospf interface command verifies that interfaces have been configured in the
intended areas. If no loopback address is specified, the interface with the highest address is
taken as the router ID. It also gives the timer intervals, including the hello interval, and
shows the neighbor adjacencies. The show ip ospf interface [type number] command
displays OSPF-related interface information, as shown in Example 3-11. In this command,
type is an option to set the interface type, and number is an option to set the interface
number.
Example 3-11 show ip ospf interface Command Output
R2#show ip ospf interface e0
Internet Address 192.168.0.12/24, Area 0
Process ID 1, Router ID 192.168.0.12, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DROTHER, Priority 1
Designated Router (ID) 192.168.0.11, Interface address 192.168.0.11
Backup Designated router (ID) 192.168.0.13, Interface address 192.168.0.13
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:04
Neighbor Count is 3, Adjacent neighbor count is 2
Adjacent with neighbor 192.168.0.13 (Backup Designated Router)
Adjacent with neighbor 192.168.0.11 (Designated Router)
Suppress Hello for 0 neighbor(s)
The show ip ospf command, shown in Example 3-12, displays the number of times the SPF
algorithm has been executed.
Example 3-12 show ip ospf Command Output

p1r3#show ip ospf
Routing Process “ospf 200” with ID 172.26.1.49
Supports only single TOS(TOS0) routes
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
Number of external LSA 0. Checksum Sum 0x0
Number of DCbitless external LSA 0
Number of DoNotAge external LSA 0
Number of areas in this router is 1. 0 normal 1 stub 0 nssa
Area 1
Number of interfaces in this area is 2
It is a stub area
Area has no authentication
SPF algorithm executed 6 times
Area ranges are
Number of LSA 7. Checksum Sum 0x25804
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
The show ip ospf neighbor command displays OSPF neighbor information on a per-
interface basis.
Router>show ip ospf neighbor [type number] [neighbor-id] [detail]
Table 3-6 explains this command.

Table 3-6 show ip ospf neighbor Command
show ip ospf neighbor Command Description
type (Optional) Interface type
number (Optional) Interface number
neighbor-id (Optional) Neighbor’s ID
detail (Optional) Display of all neighbors in detail (lists all
neighbors)
Example 3-13 provides an output of this command in an Ethernet environment, where a DR

and a BDR are elected. Other routers which are just neighbors (not DR or BDR) are referred
to as 2WAY/DROTHER.
In Example 3-13, OSPF over Ethernet, a state of 2WAY/DROTHER indicates that this
router has reached the two-way state with its neighbor. We can also observe that the router
with router ID 192.168.0.12 is the DR for this Ethernet segment.
Example 3-13 show ip ospf neighbor Command in an Ethernet Topology

Router>show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.0.13 1 2WAY/DROTHER 00:00:31 192.168.0.13 Ethernet0
192.168.0.14 1 FULL/BDR 00:00:38 192.168.0.14 Ethernet0
192.168.0.11 1 2WAY/DROTHER 00:00:36 192.168.0.11 Ethernet0
192.168.0.12 1 FULL/DR 00:00:38 192.168.0.12 Ethernet0
Example 3-14 provides an output of the show ip ospf neighbor command for OSPF over
a point-to-point network. A state of FULL/ – indicates that this router has reached the full
state with its neighbor, and that there is no DR on this segment (because it is a point-to-
point network).
Example 3-14 show ip ospf neighbor Command in a Point-to-Point Network
192.168.0.11 1 FULL/ - 00:00:39 10.1.1.2 Serial1
In Example 3-15, using NBMA mode, although not visible, the neighbor statement was
used under the router ospf command so that adjacencies could be established. Example
3-15 provides an output of the show ip ospf neighbor command. The router that this
example was taken from is the DR; its neighbor with ID 192.168.0.11 is the BDR.
Example 3-15 show ip ospf neighbor Command in an NBMA Mode Using the Neighbor Statements
192.168.0.12 1 FULL/DROTHER 0:01:56 10.1.1.2 Serial0
192.168.0.11 1 FULL/BDR 0:01:56 10.1.1.1 Serial0
In Example 3-16, OSPF broadcast mode was configured in a fully meshed network. This
example was performed on the BDR; the neighbor with ID 192.168.0.14 is the DR.
Example 3-16 show ip ospf neighbor Command on a Frame Relay Network Configured for Broadcast Mode
192.168.0.14 1 FULL/DR 00:00:30 10.1.1.4 Serial0
The show ip ospf neighbor detail command, shown in Example 3-17, displays a detailed
list of neighbors, their priorities, and their state (for example, INIT, EXSTART, or FULL).
Example 3-17 show ip ospf neighbor detail Command Output

Router#show ip ospf neighbor detail
Neighbor 160.89.96.54, interface address 160.89.96.54

In the area 0.0.0.3 via interface Ethernet0
Neighbor priority is 1, State is FULL
Options 2
Dead timer due in 0:00:38
Neighbor 160.89.103.52, interface address 160.89.103.52
In the area 0.0.0.0 via interface Serial0
Neighbor priority is 1, State is FULL
Options 2
Dead timer due in 0:00:31
The show ip ospf database command displays the contents of the topological database.
The command also shows the router ID and the OSPF process ID. When entered with the
optional keywords router, network, summary, asb-summary, and external, different
displays result. The show ip ospf database command can be used when you wish to
confirm that your router is aware of all segments in your area.
In Example 3-18, you see the router advertising the links (the ADV router) and the link
count. The link count shown for the router link states in Area 0 indicates the number of links
that each of the routers has in that area. (Note that, in some cases, the link count may be
larger than the number of physical interfaces in the area because some interface types—
such as point-to-point interfaces—generate two links in the OSPF database.)
Example 3-18 show ip ospf database Command
R2#show ip ospf database
OSPF Router with ID (192.168.0.12) (Process ID 1)
Router Link States (Area 0)

192.168.0.10 192.168.0.10 817 0x80000003 0xFF56 1
192.168.0.11 192.168.0.11 817 0x80000003 0xFD55 1
192.168.0.12 192.168.0.12 816 0x80000003 0xFB54 1
192.168.0.13 192.168.0.13 816 0x80000003 0xF953 1
192.168.0.14 192.168.0.14 817 0x80000003 0xD990 1
Net Link States (Area 0)
192.168.0.14 192.168.0.14 812 0x80000002 0x4AC8
NOTE Cisco has an OSPF Design Guide document that includes, in its Appendix A, a detailed
example of interpreting the OSPF database. This document can be found by searching
www.cisco.com with the keywords “OSPF Design Guide”.
The remaining commands in this section and their associated options can be used when
troubleshooting OSPF.
The clear ip route command is used to reset the IP routing table. The available options are
displayed in the following output:
p2r2#clear ip route ?
* Delete all routes
A.B.C.D Destination network route to delete
Note that performing a clear ip route * causes the router to clear and then recalculate its
entire routing table, but it does not affect the neighborship database or the topology
database.
The debug ip ospf command is used to debug a variety of OSPF operations. The following
debug options are available:
p2r2#debug ip ospf ?
adj OSPF adjacency events
events OSPF events
flood OSPF flooding
lsa-generation OSPF lsa generation
packet OSPF packets
retransmission OSPF retransmission events
spf OSPF spf
tree OSPF database tree
The debug ip ospf adj command can be used when you wish to monitor the election of the
DR and BDR, as shown in Example 3-19.
NOTE The last parameter in this command is really adj, not adjacency.
Example 3-19 debug ip ospf adj Example

192.168.0.14 on Ethernet0, state 2WAY
OSPF: end of Wait on interface Ethernet0
DR: 192.168.0.14 (Id) BDR: 192.168.0.14 (Id)
OSPF: Send DBD to 192.168.0.14 on Ethernet0 seq 0x11DB opt 0x2 flag 0x7 len 32
OSPF: Neighbor change Event on interface Ethernet0
OSPF: Rcv DBD from 192.168.0.14 on Ethernet0 seq 0x1598 opt 0x2 flag 0x7 len 32
state EXSTART
OSPF: NBR Negotiation Done. We are the SLAVE
OSPF: Send DBD to 192.168.0.14 on Ethernet0 seq 0x1598 opt 0x2 flag 0x2 len 52
OSPF: Rcv DBD from 192.168.0.14 on Ethernet0 seq 0x1599 opt 0x2 flag 0x3 len 92
state EXCHANGE
OSPF: Exchange Done with 192.168.0.14 on Ethernet0
Case Study: OSPF in a Single Area 139
Example 3-19 debug ip ospf adj Example (Continued)

OSPF: Send DBD to 192.168.0.14 on Ethernet0 seq 0x159A opt 0x2 flag 0x0 len 32
OSPF: Synchronized with 192.168.0.14 on Ethernet0, state FULL
OSPF: Neighbor change Event on interface Ethernet0
DR: 192.168.0.14 (Id) BDR: 192.168.0.13 (Id)
Case Study: OSPF in a Single Area

Refer to Chapter 1, “Routing Principles,” for introductory information on the running case
study.
Link-state routing protocols such as OSPF are commonly deployed in medium- to large-
scale networks. Implementation of OSPF usually begins with the creation of Area 0, the
core of the network. In Figure 3-14, which shows JKL’s acquisition C, OSPF was selected
because different vendor’s equipment is in use and a nonproprietary routing protocol is
required. There are fewer than 20 routers in the network, and all routers are part of Area 0
core.
NOTE If a network has only one area, it does not have to be configured as Area 0.
While looking at Figure 3-14, analyze the following:

• Topology considerations
• Metric limitations
• Routing update traffic
• Convergence time
• Ease of configuration and management
Figure 3-14 Case Study Topology—OSPF Single Area
Class B
JKL’s Acquisition C
Public Address
Area 0
High-speed
core
DR BDR
FDDI
Token
Ring
Gigabit Ethernet
Fast Ethernet
Ethernet
Serial
Case Study Solution

Acquisition C’s network has been in place for a number of years, and the infrastructure
reflects different technologies that were selected because they offered the highest available
bandwidth at the time of their inception. The management of Acquisition C always had
speed as a primary concern and, as a result, selected a link-state routing protocol (OSPF)
because of its rapid convergence. In an attempt to control costs while deploying the most
current technology, management has purchased equipment from many different vendors.
The use of multivendor equipment and high-speed links may require the OSPF interface
costs to be adjusted.
Summary 141
The growth of C’s single-campus network has been done in an ad hoc fashion rather than
by design. This random growth might have caused subnet addresses to be arbitrarily
distributed throughout the network. Therefore, due to the noncontiguous subnet address
space of this network, route summarization might be impossible. Moreover, because all
routers are in Area 0 (and therefore, no hierarchy exists), there are no area border routers
(ABRs) at which to configure summarization.
The lack of route summarization means that the routing tables are larger than necessary.
The random growth has also precluded any thought of creating a hierarchical topology with
routers deployed based upon functionality.
The failure of any link causes a disruption of traffic in all parts of the network and could
consume a significant portion of the bandwidth. Attempts to increase reliability by creating
redundant paths through the network have been only partially successful. The speed of the
alternate paths is dramatically different than the primary links, and this means that link-
state advertisements can arrive out of order.
Also, this network might be more difficult than necessary to manage because of its
multivendor environment and the lack of hierarchy.
Summary
In this chapter, you have learned why OSPF, a link-state routing protocol, is better than RIP,
a distance vector routing protocol, in a large internetwork. You saw how OSPF discovers its
neighbors using the Hello protocol. You also saw how OSPF builds a topology database, on
which it applies the SPF algorithm to choose the best routes and build its routing table. You
also learned how OSPF maintains routes when a topological change happens on the
network.
Also in this chapter, you learned how to configure Cisco routers to operate in a single-area
OSPF network, whether in a broadcast or a nonbroadcast environment. Finally, you learned
how to verify OSPF operation in a single area.
Configuration Exercise #1: Configuring OSPF for a

Single Area
Configuration Exercises
In this book, Configuration Exercises are used to provide practice in configuring routers
with the commands presented. If you have access to real hardware, you can try these
exercises on your routers; refer to Appendix H, “Configuration Exercise Equipment
Requirements and Backbone Configurations,” for a list of recommended equipment and
configuration commands for the backbone routers. However, even if you don’t have access
to any routers, you can go through the exercises and keep a log of your own “running
configurations” on separate sheets of paper. Commands used and answers to the
Configuration Exercises are provided at the end of the exercise.
In these exercises, you are in control of a pod of three routers; there are assumed to be 12
pods in the network. The pods are interconnected to a backbone. In most of the exercises,
there is only one router in the backbone; in some cases, another router is added to the
backbone. Each of the Configuration Exercises in this book assumes that you have
completed the previous exercises on your pod.
Complete the following exercise to configure OSPF for a single area.
Objectives
In this Configuration Exercise, you will practice how to configure routers to be in OSPF
Area 0, verify the connectivity within your pod, and verify the connectivity to external
routes sourced from the backbone_r1 router. You will also use show and debug commands
to verify OSPF operations.
Visual Objective
Figure 3-15 illustrates the topology used for this single-area OSPF Configuration Exercise.
Configuration Exercise #1: Configuring OSPF for a Single Area 143
Figure 3-15 Topology for Configuring OSPF for a Single Area
172.16.10.100/24
172.16.11.100/24
backbone_r1 loopback
S1/0 S2/3
10.1.1.100/24 10.12.12.100/24
Pods 2 to 11
10.1.1.1/24 . . . . . . . . . . . 10.12.12.12/24
S3 OSPF Area 0 S3
S0 p1r1 S0 p12r1
192.168.1.17/28 S2 192.168.12.17/28 S2
S1 192.168.1.49/28 S1 192.168.12.49/28
192.168.1.33/28 192.168.12.33/28
Pod 1 Pod 12
192.168.1.18/28 192.168.1.50/28 192.168.12.18/28 192.168.12.50/28

S0 S1192.168.1.34/28 S0 S0 S1 S0
192.168.12.34/28
P1r2 E0 E0 p1r3 p12r2 E0 E0 P12r3

192.168.1.65/28 192.168.1.66/28 192.168.12.65/28 192.168.12.66/28
Command List
In this Configuration Exercise, you will use the commands listed in Table 3-7. Refer to this
list if you need configuration command assistance during this exercise.
Table 3-7 Commands Used in Configuration Exercise #1
Command Description
no router igrp 200 Disables IGRP.
router ospf 200 Enables OSPF with a process ID of 200.
network 10.0.0.0 0.255.255.255 area 0 Specifies interfaces on which to run OSPF, and
specifies their areas.
show ip ospf Displays general information about the OSPF
routing process.
show ip ospf neighbor Displays information about OSPF neighbors.
show ip ospf database Displays the entries in the OSPF link-state database.
continues
Table 3-7 Commands Used in Configuration Exercise #1 (Continued)

Command Description
show ip ospf interface Displays OSPF-specific information about an
interface.
debug ip ospf adj Shows the events involved in the building or
breaking of an OSPF adjacency.
Task 1: Enabling OSPF Within Your Pod

Complete the following steps:
Step 1 Shut the pxr1 S3 interface that connects to the backbone_r1 router. What
command do you type to shut down this interface?
Type the command to disable IGRP on all the routers within your
assigned pod.
Which routing protocol has a better administrative distance: IGRP or
OSPF?
Step 2 Enable OSPF with process ID 200 on all the routers within your pod.
What command do you use to do this?
Step 3 Enable all the interfaces within your pod to run OSPF, and set their area
to Area 0. Can you use a mask of 0.0.0.255 on the OSPF network
command to accomplish this task?
Step 4 Display the routing table and verify that you have full connectivity within
your pod. What command is used to display the routing table? Make sure
that you can successfully ping all the other routers within your pod.
Step 5 Examine the pxr1 routing table, and answer the following:
Does OSPF load balance by default? What is the OSPF routing metric
based on? What is the default administrative distance of OSPF?
Step 6 What is the OSPF router ID of pxr2?
What is the OSPF router ID of pxr3?

From the pxr3 router, issue the command to show the OSPF neighbor
state.
Is the neighbor state of pxr2 and pxr1 in the full state?
Which router is the DR on the Ethernet connection between pxr2 and
pxr3? Why?
Configuration Exercise #1: Configuring OSPF for a Single Area 145
Is there a DR/BDR on a serial interface with HDLC encapsulation? What

is the default OSPF router priority?
Shut the E0 interface at pxr2 and pxr3.
At the router that was the BDR, change its E0 interface OSPF router
priority to 2, and then no shut the E0 interface at router pxr2 and pxr3.
Which router is the DR now?
Step 7 From the pxr2 router, issue the debug ip ospf adj command.
Shut and no shut the pxr2 E0 interface, and observe the OSPF adjacency
debug messages.
What command can be typed to disable the debug?
Step 8 From any router in your pod, issue the command to display the OSPF
database.
What are the two types of link-state advertisements that you see in the
OSPF database?
For the router link states, why is the link count 5 for router pxr2, 6 for
router pxr1, and 3 for router pxr3?
Step 9 From the pxr2 or pxr3 router, issue the command to display OSPF
information about the interfaces.
What is the OSPF network type on the Ethernet interface?
What is the OSPF network type on the serial interface?
What is the OSPF hello interval on the Ethernet and serial (HDLC)
interface?
Step 10 Save the current configurations of all the routers within your pod to
NVRAM.
Task 2: Enabling OSPF Connectivity to the backbone_r1 Router

Step 1 From the pxr1 router, no shut the S3 interface that connects to the
backbone_r1 router.
Step 2 Enable the pxr1 S3 interface to run OSPF, and set its area to Area 0. Can
you use a mask of 0.255.255.255 on the OSPF network command to
accomplish this task? Display the routing table. Do you see the
backbone’s loopback interface subnet addresses in your routing table?
(Note that you may also see routes from other pods.)
When you were running IGRP, did you see the backbone’s loopback
interface subnet addresses (or subnets from other pods) in your routing
table? Explain your answer.
NVRAM.
Bonus Task
Step 1 From the pxr3 and pxr2 router, shut the E0 interface.
Step 2 Change pxr3 E0 interface from Area 0 to Area 99. The pxr2 E0 interface
remains in Area 0.
NOTE The OSPF network statements are matched from top to bottom. Therefore, the most specific
statements should be at the top, and the least specific statements should be at the bottom.
Step 3 No shut the pxr3 E0 interface.
Step 4 Enter the debug command to display the OSPF adjacency information at
pxr2. What would this command be?
Step 5 No shut the pxr2 E0 interface.
Are there error messages on the console regarding mismatch area ID?
Step 6 Disable the debug.
What is the neighbor status between pxr2 and pxr3?

Step 7 Change the pxr3 E0 interface back to Area 0.
Completion Criteria
You have successfully completed this Configuration Exercise if you correctly supplied the
commands required to configure and to verify a single-area OSPF network, and if you were
able to correctly answer the questions in the Configuration Exercise. At the end of this
exercise, all routers will be running the OSPF protocol in Area 0. The answers to this
Configuration Exercise can be found later in this chapter.
Configuration Exercise #2: Configuring OSPF for a Single Area in an NBMA Environment 147
Configuration Exercise #2: Configuring OSPF for a

Single Area in an NBMA Environment
Complete the following exercise to configure OSPF over Frame Relay.
Objectives
In this Configuration Exercise, you will configure the pxr1 router as the Frame Relay switch
for the pxr2 and pxr3 routers. You will then configure the pxr2 and pxr3 router serial
interface (S0) with Frame Relay encapsulation. When you have verified connectivity
between pxr2 and pxr3, you will be asked to configure OSPF over NBMA using the main
interface and then using a point-to-point subinterface. You will use the show commands to
verify OSPF operations.
In this Configuration Exercise, your pxr1 router will act as the Frame Relay switch between
your pxr2 and pxr3 routers.
Visual Objective
Figure 3-16 and Figure 3-17 provide the topologies used in this Configuration Exercise.
Figure 3-16 Configuring OSPF for a Single Area in NBMA Environment Using Main Interface
pxr1 - FR Switch
S0 S2
OSPF AREA 0 OSPF AREA 0
S0 - DLCI 203 S0 - DLCI 302

192.168.x.129/28 192.168.x.130/28
pxr2 pxr3
Figure 3-17 Configuring OSPF for a Single Area in NBMA Environment Using Point-to-Point Subinterface
px r1 - FR Switch
S0 S2
OSPF AREA 0 OSPF AREA 0
S0.1 - DLCI 203 S0.1 - DLCI 302

192.168.x.129/28 192.168.x.130/28
pxr2 pxr3
Command List
In this Configuration Exercise, you will use the commands listed in Table 3-8 in logical
order. Refer to this list if you need configuration command assistance during the
Configuration Exercise.
Table 3-8 Commands Used in Configuring OSPF for a Single Area in an NBMA Environment
Command Description
router ospf 200 Enables OSPF with a process ID of 200.
network 192.168.x.129 0.0.0.0 area 0 Specifies interfaces on which to run OSPF, and
specifies their areas.
neighbor 192.168.x.129 Manually informs a router of its neighbor on a
nonbroadcast network.
ip ospf priority 0 Sets the router priority of an interface for use in the
DR/BDR election process.
show ip ospf Displays general information about the OSPF
routing process.
show ip ospf neighbor Displays information about OSPF neighbors.
show ip ospf database Displays the entries in the OSPF link-state database.
show ip ospf Interface Displays OSPF-specific information about an
interface.
encapsulation frame-relay Enables Frame Relay frames on an interface.
show frame-relay map Displays a mapping between DLCI and IP
addresses, and shows traffic forwarding
characteristics.
Setup
To set up, do the following:
Step 1 On pxr1, shut down the Serial 1 and Serial 3 interfaces. Turn off OSPF.
Step 2 On pxr2, shut down the Ethernet 0, Serial 0, and Serial 1 interfaces.
Reconfigure the Serial 0 IP address to 192.168.x.129/28.
Step 3 On pxr3, shut down the Ethernet 0 and Serial 0 interfaces. Reconfigure
the Serial 0 IP address to 192.168.x.130/28.
Task 1: Creating the Frame Relay Switch

Step 1 Enable your pxr1 router. Provide the commands necessary for turning a
router into a Frame Relay switch. Interface Serial 0, a DCE interface, will
switch frames to Serial 2 interface (from Serial 0 DLCI 203 to Serial 2
DLCI 302). Interface Serial 2, also a DCE interface, will switch frames
to Serial 0 interface (from Serial 2 DLCI 302 to Serial 0 DLCI 203).
Step 2 Enable Frame Relay encapsulation on the S0 interface of your pxr2 and
pxr3 routers, and verify that your pxr2 and pxr3 routers’ S0 IP addresses
are as follows from setup:
Router S0 IP Address
pxr2 192.168.x.129/28
pxr3 192.168.x.130/28
Enable the Serial 0 interfaces on pxr2 and pxr3.

From pxr2, ping the pxr3 Serial 0 interface to ensure connectivity. What
command would you use to achieve this?
Task 2: Enabling OSPF over NBMA Network Using Main Interface

Step 1 Verify that your pxr2 and pxr3 router S0 interfaces are configured for
OSPF (in Area 0).
Step 2 From pxr2, enter the show ip ospf interface command.
What is the network type of S0?

What are the hello and dead intervals of S0?
Step 3 From pxr2, enter the show ip ospf neighbor command.
Do you see pxr3 as the neighbor? Why or why not?

Step 4 At the pxr2 router, set the OSPF router priority to 0 on the S0 interface.
Step 5 At the pxr3 router, use the neighbor statement to manually create a
neighbor relationship with the pxr2 router.
NOTE Although you are putting a neighbor statement on only one of the routers in this
Configuration Exercise, it is good practice to put a neighbor statement on both routers.
Step 6 Verify that the neighbor status between your pxr2 and pxr3 routers is now
in the full state.
Which router is the DR, and why?
Bonus Task
Step 1 Remove the neighbor statement from the pxr3 router, and remove the
ip ospf priority 0 statement from the pxr2 router. Shut down the pxr2
S0 interface; leave it down for more than 2 minutes, and then bring it
back up.
Step 2 Use the ip ospf network point-to-multipoint command on the S0
interface of the pxr2 and pxr3 routers.
Step 3 What is the OSPF neighbor status between your pxr2 and pxr3 routers
now?
Is there a DR/BDR election using the point-to-multipoint OSPF network
type?
NVRAM.
Task 3: Enabling OSPF over NBMA Network Using Point-to-Point

Subinterface
Step 1 On the pxr2 and pxr3 router S0 interfaces, remove the IP address.
Step 2 Create a point-to-point subinterface (S0.1), and assign an IP address and

a DLCI to the subinterface. The IP addresses are as follows; use the
frame-relay interface-dlci dlci command to assign the DLCI:
Router S0.1 IP Address S0.1 DLCI

pxr2 192.168.x.129/28 203
pxr3 192.168.x.130/28 302
Step 3 From pxr2, ping the pxr3 S0.1 interface to ensure connectivity.
Step 4 Remove the neighbor statement, the ip ospf priority 0 statement, and
the ip ospf network point-to-multipoint statement from the respective
pxr2 and pxr3 routers (if they are in your configuration from the previous
task).
Step 5 At the pxr2 router, enter the command show ip ospf interface S0.1.
What is the network type of S0.1?

What are the hello and dead intervals of S0.1?
Step 6 What is the OSPF neighbor status between your pxr2 and pxr3 routers?
Is there a DR/BDR election over the point-to-point subinterface?

NVRAM.
Step 8 (Bonus question)
What is the main advantage of using a point-to-point subinterface when
configuring OSPF over Frame Relay?
Completion Criteria
commands required to configure and to verify a single-area OSPF network over an NBMA
environment using both the main interface and the point-to-point subinterface, and if you
were able to correctly answer the questions in the exercises. At the end of this exercise, your
pxr2 and pxr3 routers will be running OSPF in a single area over Frame Relay. The answers
to this Configuration Exercise can be found in the next section of this chapter.
CHAPTER
4
Interconnecting Multiple OSPF
Areas
This chapter introduces readers to the use, operation, configuration, and verification of
Open Shortest Path First (OSPF) in multiple areas. After completing this chapter, you will
be able to describe issues related to interconnecting multiple areas. You will see the
differences among the possible types of areas and how OSPF supports the use of VLSM.
At the end of this chapter, you should be able to explain how OSPF supports the use of
route summarization in multiple areas and how it operates in a multiple-area NBMA
environment.
NOTE This chapter covers OSPF capabilities. OSPF design is covered in the Cisco Press book
OSPF Network Design Solutions (ISBN 1-57870-046-9).
Multiple OSPF Areas

In the previous chapter, you learned how OSPF operates within a single area. Now it is time
to consider what would happen if this single area ballooned into, say, 400 networks. The
following issues, at a minimum, need to be addressed to understand OSPF in multiple areas:
• Frequent calculations of the shortest path first (SPF) algorithm—With such a
large number of segments, network changes are inevitable. The routers would have to
spend many more CPU cycles recalculating the routing tables because they would
receive every update generated within the area.
• Large routing table—Each router would need to maintain at least one entry for every
network—in this previous example, that would be at least 400 networks. Assuming
that alternative paths would exist for 25 percent of these 400 networks, routing tables
would have an additional 100 entries.
• Large link-state table—Because the link-state table includes the complete topology
of the network, each router would need to maintain an entry for every network in the
area, even if routes are not selected for the routing table.
In light of these issues, OSPF was designed to allow large areas to be separated into smaller,
more manageable areas that can still exchange routing information.
176 Chapter 4: Interconnecting Multiple OSPF Areas
OSPF’s capability to separate a large internetwork into multiple areas is also referred to as
hierarchical routing. Hierarchical routing enables you to separate a large internetwork
(autonomous system) into smaller internetworks that are called areas, as shown in Figure
4-1. With this technique, routing still occurs between the areas (called interarea routing),
but many of the internal routing operations, such as recalculating the database, are kept
within an area. In Figure 4-1, for example, if Area 1 is having problems with a link going
up and down, routers in other areas need not continually run their SPF calculation because
they are isolated from the Area 1 problem.
Figure 4-1 OSPF Hierarchical Routing
Area 0
Area 1 Area 2
Autonomous system
The hierarchical topology of OSPF has the following advantages:

• Reduced frequency of SPF calculations—Because detailed route information is
kept within each area, it is not necessary to flood all link-state changes to every area.
Thus, not all routers need to run the SPF calculation when a topological change
happens. Only those affected by the change will need to recompute routes.
• Smaller routing tables—When using multiple areas, detailed route entries for
interarea networks are kept within the area. Instead of advertising these explicit routes
outside the area, these routes can be summarized into one or more summary
addresses. Advertising these summaries reduces the number of link-state
advertisements (LSAs) propagated between areas, while keeping all networks
reachable.
• Reduced link-state update (LSU) overhead—LSUs can contain a variety of LSA
types, including link-state information and summary information. Rather than
sending an LSU about each network within an area, you can advertise a single or a
few summarized routes between areas, thus reducing the overhead associated with
link-state updates passed to other areas.
Multiple OSPF Areas 177
Hierarchical routing enables efficient routing because it enables you to control the types of
routing information that you allow in and out of an area. OSPF enables different types of
routing updates by assigning characteristics to each area and the routers connecting the
areas. Area and router characteristics govern how they process routing information,
including what types of LSUs a router can create, receive, and send. This section provides
an overview of the following OSPF multiarea components, and their usage and
configuration:
• Types of routers
• Types of LSAs
• Types of areas
OSPF Design Guidelines

Studies and real-world implementations have led to the following OSPF design guidelines,
as documented in OSPF Network Design Solutions:
Routers in a Domain Minimum 20 Mean 510 Maximum 1000

Routers per Single Area Minimum 20 Mean 160 Maximum 350
Areas per Domain Minimum 1 Mean 23 Maximum 60
Types of Routers
Different types of OSPF routers, shown in Figure 4-2, control differently how traffic is
passed to and from areas. The router types are as follows:
• Internal router—Routers that have all interfaces in the same area are internal routers.
Internal routers within the same area have identical link-state databases.
• Backbone router—Routers that sit in the backbone area. They have at least one
interface connected to Area 0. These routers maintain OSPF routing information using
the same procedures and algorithms as internal routers. Area 0 serves as the transit
area between other OSPF areas.
• Area Border Router (ABR)—Routers that have interfaces attached to multiple
areas. These routers maintain separate link-state databases for each area to which they
are connected, and route traffic destined for or arriving from other areas. ABRs are
exit points for the area, which means that routing information destined for another
area can get there only via the local area’s ABR. ABRs may summarize information
from their link-state databases of their attached areas and distribute the information
into the backbone area. The backbone ABRs then forward the information to all other
connected areas. An area can have one or more ABRs.
• Autonomous System Boundary Router (ASBR)—Routers that have at least one

interface into an external internetwork (another autonomous system), such as a non-
OSPF network and another interface within OSPF. These routers can import (referred
to as redistribution) non-OSPF network information to the OSPF network, and vice
versa.
Figure 4-2 Types of Routers
Area 1 Backbone Area 0 Area 2

ABR and
backbone Backbone/
router internal
routers
Internal
routers
Internal
routers
ABR and
backbone
ASBR and
router
backbone
router
External AS
A router can be more than one router type. For example, if a router connects to Area 0 and
Area 1, as well as to a non-OSPF network, it would be considered an ABR, an ASBR, and
a backbone router.
A router has a separate link-state database for each area it is connected to. Therefore, an
ABR would have a link-state database for Area 0 and another link-state database for the
other area it participates in. Two routers belonging to the same area have, for that one area,
identical area link-state databases.
Remember that a link-state database is synchronized between pairs of adjacent routers,
meaning that it is synchronized between a router and its designated router (DR) and backup
designated router (BDR).
Types of Link-State Advertisements

Table 4-1 shows the types of LSAs included in an LSU. The Name column in Table 4-1
provides the official name of the LSA. Contained in the first set of parentheses is the
nomenclature used in the routing table for that specific LSA. The second set of parentheses
shows how the LSA type is indicated in the OSPF database. Example 4-1 provides a sample
OSPF database.
Table 4-1 Types of LSAs
LSA Type Name Description
1 Router link entry (record) Generated by each router for each area it
(O—OSPF) belongs to. Describes the states of the router’s
link to the area. These are flooded only within a
(Router Link States) particular area. The link status and cost are two
of the descriptors provided.
2 Network link entry Generated by DRs in multiaccess networks.
(O—OSPF) Describes the set of routers attached to a
particular network. These are flooded within the
(Net Link States) area that contains the network only.
3 or 4 Summary link entry Originated by ABRs. Describes the links
(IA—OSPF interarea) between the ABR and the internal routers of a
local area. These entries are flooded throughout
(Summary Net Link States and the backbone area to the other ABRs. Type 3
Summary ASB Link States) LSAs describe routes to networks within the
local area and are sent to the backbone area.
Type 4 LSAs describe reachability to ASBRs.
These link entries are not flooded through
totally stubby areas.
5 Autonomous system external Originated by the ASBR. Describes routes to
link entry destinations external to the autonomous system.
(E1—OSPF external type 1) They are flooded throughout an OSPF
autonomous system except for stub, totally
(E2—OSPF external type 2) stubby, and not-so-stubby areas.
(AS External Link States)
7 Not-so-stubby area (NSSA) Originated by the ASBR in an NSSA. These
autonomous system external LSAs are similar to type 5 LSAs, except that
link entry they are flooded only within the NSSA. At the
(N1—OSPF NSSA external area border router, selected type 7 LSAs are
type 1) translated into type 5 LSAs and are flooded into
the backbone. See Appendix A, “Job Aids and
(N2—OSPF NSSA external Supplements,” for further information on
type 2) NSSAs.
NOTE Type 3 and 4 LSAs are summary LSAs; they may or may not be summarized.
LSAs type 6 do not appear in Table 4-1 because they are not supported by Cisco Routers.
NOTE All LSA types, except the autonomous system external link entry LSAs (type 5), are
flooded throughout a single area only.
NOTE Only LSA types 1 through 5 are covered in this chapter. Types 6 and 7 LSAs are beyond
the scope of this chapter. Type 7 LSAs are discussed in Appendix A. Type 6 LSAs are
covered in RFC 1584.
Example 4-1 OSPF Database Output

p1r3#show ip ospf database
OSPF Router with ID (10.64.0.1) (Process ID 1)
Router Link States (Area 1)

10.1.2.1 10.1.2.1 651 0x80000005 0xD482 4
Net Link States (Area 1)

10.64.0.1 10.64.0.1 538 0x80000002 0xAD9A
Summary Net Link States (Area 1)

10.2.1.0 10.2.1.2 439 0x80000002 0xE6F8
Figure 4-3 provides a representation of the different types of LSAs flooded in an OSPF
network. The router link states are type 1 LSAs, the network link states are type 2 LSAs,
and the summary link states are type 3 LSAs. The external link states are type 5 LSAs.
Figure 4-3 Examples of LSAs Flooded in a Network
Area 1 DR Area 0
Network External
ABR ASBR External AS

Router
Summary
Cost Associated with Summary Routes

The cost of a summary route is the smallest cost of a given interarea route that appears in
the summary, plus the cost of the ABR link to the backbone. For example, if the cost of the
ABR link to the backbone were 50, and if the ABR had an interarea route of 49, the total
cost associated with the summary route would be 99. This calculation is done automatically
for each summary route.
Calculating the Cost of External Routes

The cost of an external route differs depending on the external type configured on the
ASBR. You configure the router to generate one of the following external packet types:
• Type 1 (E1)—If a packet is an E1, then the metric is calculated by adding the external
cost to the internal cost of each link that the packet crosses. Use this packet type when
you have multiple ASBRs advertising a route to the same autonomous system.
• Type 2 (E2)—This is the default type. If a packet is an E2, then it will always have
only the external cost assigned, no matter where in the area it crosses. Use this packet
type if only one router is advertising a route to the external autonomous system. Type
2 routes are preferred over type 1 routes unless two same-cost routes exist to the
destination.
NOTE The process of different routing protocols exchanging routing information is referred to as
redistribution. Redistribution is discussed in Chapter 8, “Optimizing Routing Update
Operation.”
Figure 4-4 provides a graphical example of how type 1 external routes are calculated.
Types of Areas
The characteristics that you assign an area control the type of route information that it
receives. The possible area types include the following:
• Standard area—An area that operates as discussed in Chapter 3, “Configuring OSPF
in a Single Area.” This area can accept (intra-area) link updates, (interarea) route
summaries, and external routes.
• Backbone area (transit area)—When interconnecting multiple areas, the backbone
area is the central entity to which all other areas connect. The backbone area is always
labeled Area 0. All other areas must connect to this area to exchange and route
information. The OSPF backbone has all the properties of a standard OSPF area.
Figure 4-4 External Routes Calculations
Area 1 Area 0
E1 E1
R5 Cost = 10 R4 Cost = 10 R3 Cost = 10 R1
Cost = 1785
E1
Cost = 1785
AS1
R5’s cost to: R3’s cost to:
AS1 (E1) via R1 = 1815 AS1 (E1) via R1 = 1795
AS1 (E1) via R3 = 1805 AS1 (E1) via R3 = 1785
• Stub area—This refers to an area that does not accept information about routes
external to the autonomous system (that is, the OSPF internetwork), such as routes
from non-OSPF sources. If routers need to route to networks outside the autonomous
system, they use a default route. A stub area will accept summary routes from other
areas internal to the autonomous system. A default route is noted as 0.0.0.0.
• Totally stubby area—This is an area that does not accept external autonomous
system (AS) routes or summary routes from other areas internal to the autonomous
system. Instead, if the router needs to send a packet to a network external to the area,
it sends it using a default route. Totally stubby areas are Cisco proprietary.
• Not-so-stubby-area—A not-so-stubby area imports a limited number of external
routes. The number of routes is limited to only those required to provide connectivity
between areas. NSSAs are discussed in Appendix A.
Routing Table Results with Different Areas

Example 4-2, Example 4-3, and Example 4-4 provide a comparison of routing tables that
result when using summarization, stub areas, and totally stubby areas, respectively.
Example 4-2 IP Routing Table Without Any Special OSPF Capabilities: Route Summaries Without Route
Summarization
p1r3#show ip route
<Output Omitted>
O IA 10.3.1.0 [110/148] via 10.64.0.2, 00:03:12, Ethernet0
O IA 10.2.1.0 [110/74] via 10.64.0.2, 00:31:46, Ethernet0
Example 4-2 IP Routing Table Without Any Special OSPF Capabilities: Route Summaries Without Route
Summarization (Continued)
O IA 10.3.3.0 [110/148] via 10.64.0.2, 00:03:12, Ethernet0
O IA 10.2.2.0 [110/138] via 10.64.0.2, 00:31:46, Ethernet0
O 10.1.1.0 [110/128] via 10.1.3.1, 00:31:46, Serial0
[110/128] via 10.1.2.1, 00:31:46, Serial
O IA 10.3.2.0 [110/212] via 10.64.0.2, 00:03:12, Ethernet0
O IA 10.2.3.0 [110/74] via 10.64.0.2, 00:31:46, Ethernet0
O IA 10.4.2.0 [110/286] via 10.64.0.2, 00:02:50, Ethernet0
O IA 10.4.3.0 [110/222] via 10.64.0.2, 00:02:50, Ethernet0
O IA 10.4.1.0 [110/222] via 10.64.0.2, 00:02:50, Ethernet0
O IA 10.66.0.0 [110/158] via 10.64.0.2, 00:02:51, Ethernet0
C 10.64.0.0 is directly connected, Ethernet0
O IA 10.65.0.0 [110/84] via 10.64.0.2, 00:03:19, Ethernet0
p1r3#
Example 4-3 IP Routing Table with Route Summarization and Stub Capabilities Enabled
p1r3#show ip route
<Output Omitted>
10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
0 IA 10.2.0.0/16 [110/74] via 10.64.0.2, 00:11:11, Ethernet0
C 10.1.3.0/24 is directly connected, Serial0
0 IA 10.3.0.0/16 [110/148] via 10.64.0.2, 00:07:59, Ethernet0
C 10.1.2.0/24 is directly connected, Serial1
O 10.1.1.0/24 [110/128] via 10.1.3.1, 00:16:51, Serial0
[110/128] via 10.1.2.1, 00:16:51, Serial1
0 IA 10.4.0.0/16 [110/222] via 10.64.0.2, 00:09:13, Ethernet0
O IA 10.66.0.0/24 [110/158] via 10.64.0.2, 00:16:51, Ethernet0
C 10.64.0.0/24 is directly connected, Ethernet0
O IA 10.65.0.0/24 [110/84] via 10.64.0.2, 00:16:51, Ethernet0
0*IA 0.0.0.0/0 [110/11] via 10.64.0.2, 00:16:51, Ethernet0
p1r3#
Example 4-4 IP Routing Table with Route Summarization and Totally Stub Capabilities Enabled
p4r2#show ip route
O 10.4.2.0 [110/128] via 10.4.3.2, 00:20:43, Serial1
[110/128] via 10.4.1.1, 00:20:43, Serial0
0*IA 0.0.0.0/0 [110/11] via 10.66.0.1, 00:20:43, Ethernet0
NOTE Example 4-4 was taken from a different router than Examples 4-2 and 4-3.
OSPF Operation Across Multiple Areas

This section summarizes how routers generate link information, flood information, and
build their routing tables when operating within a multiarea environment.
NOTE OSPF router operation is complex and accounts for numerous possible scenarios based on
the nature of the network. This section provides a basic overview; refer to the OSPF version
2 RFC for more detailed information.
Before reviewing how ABRs and other router types process route information, you should
know how a packet makes its way across multiple areas. In general, the path a packet must
take is as follows:
• If the packet is destined for a network within an area, then it is forwarded from the
internal router, through the area to the destination internal router.
• If the packet is destined for a network outside the area, it must go through the
following path:
— The packet goes from the source network to an ABR.
— The ABR sends the packet through the backbone area to the ABR of the
destination network.
— The destination ABR then forwards the packet through the area to the
destination network.
Flooding LSUs in Multiple Areas

ABRs are responsible for generating routing information about each area to which they are
connected and flooding the information through the backbone area to the other areas to
which they are connected. Figure 4-5 provides a graphical representation of the different
LSA types exchanged in a multiple-area environment. The general process for flooding is
as follows:
Step 1 The intra-area routing process occurs, as discussed in Chapter 3. Note
that the entire intra-area must be synchronized before the ABR can begin
sending summary LSAs.
Step 2 The ABR reviews the resulting link-state database and generates
summary LSAs.
By default, the ABR sends summary LSAs for each network that it knows
about. To reduce the number of summary LSA entries, you can configure
route summarization so that a single IP address can represent multiple
OSPF Operation Across Multiple Areas 185
networks. To use route summarization, your areas must use contiguous

IP addressing, as discussed in Chapter 2, “Extending IP Addresses.” A
good IP address plan will lower the number of summary LSA entries that
an ABR needs to advertise.
Step 3 The summary LSAs (types 3 and 4) are placed in an LSU and are
distributed through all ABR interfaces that are not in the local area, with
the following exceptions:
— If the interface is connected to a neighboring router that is in a state
below the exchange state, then the summary LSA is not forwarded.
— If the interface is connected to a totally stubby area, then the
summary LSA is not forwarded.
— If the summary LSA includes a type 5 (external) route and the
interface is connected to a stubby or totally stubby area, then the
LSA is not sent to that area.
Step 4 When an ABR or ASBR receives summary LSAs, it adds them to its link-
state database and floods them to its local area. The internal routers then
assimilate the information into their databases.
Note that to reduce the number of route entries maintained by internal
routers, you may define the area as a form of stub area.
Figure 4-5 Flooding LSUs to Multiple Areas
RIP
Area 1 Area 0 Area 50 Stub
Internal ABR1 ABR2 Internal
BBone
Type 1 Type 3 Type 3
Ty
pe
Type 5 5
Default
After all router types receive the routing updates, they must add them to their link-state
databases and recalculate their routing tables. The order in which paths are calculated is as
follows:
Step 1 All routers first calculate the paths to destinations within their area and
add these entries into the routing table. These are the type 1 and type 2
LSAs.
Step 2 All routers, unless they are in a totally stubby area, then calculate the
paths to the other areas within the internetwork. These paths are the
interarea route entries, or type 3 and type 4 LSAs. If a router has an
interarea route to a destination and an intra-area route to the same
destination, the intra-area route is kept.
Step 3 All routers, except those that are in a form of stub area, then calculate the
paths to the AS external (type 5) destinations.
At this point, a router can get to any network within or outside the OSPF autonomous
system.
NOTE According to RFC 2328, the order of preference for OSPF routes is as follows:
Intra-area routes, O
Interarea routes, O IA
External routes type 1, O E1
External routes type 2, O E2
Virtual Links Overview

OSPF has certain restrictions when multiple areas are configured. One area must be defined
as Area 0, the backbone area. It is called the backbone area because all communication must
go through it—that is, all areas should be physically connected to Area 0 so that the routing
information injected into Area 0 can be disseminated to other areas.
In some situations, however, a new area is added after the OSPF internetwork has been
designed and configured, and it is not possible to provide that new area with direct access
to the backbone. In these cases, a virtual link can be defined to provide the needed
connectivity to the backbone area, as shown in Figure 4-6. The virtual link provides the
disconnected area with a logical path to the backbone. The virtual link has two
requirements, as follows:
• It must be established between two ABRs that share a common area.
• One of these two ABRs must be connected to the backbone area.
OSPF Operation Across Multiple Areas 187
Figure 4-6 Backbone Area Requirement Met Through Virtual Links
Area 0
(Backbone)
Virtual link
Area 1 Area 2
Transit area
Area 3
When virtual links are used, they require special processing during the SPF calculation.
That is, the true next-hop router must be determined so that the true cost to get to a
destination across the backbone can be calculated.
Virtual links serve the following purposes:
• Linking an area that does not have a physical connection to the backbone, as shown
in Figure 4-6. This linking could occur when two organizations merge, for example.
• Patching the backbone in case discontinuity of Area 0 occurs.
Figure 4-7 illustrates the second purpose. Discontinuity of the backbone might occur, for
example, if two companies, each running OSPF, are trying to merge the two separate
networks into one with a common Area 0. The alternative would be to redesign the entire
OSPF network and create a unified backbone.
Figure 4-7 Discontiguous Area 0
Area 1 Transit area Area 2
Area 0 Area 0
Area 3
Another reason for creating a virtual link would be to provide redundancy in cases where a
router failure causes the backbone to be split into two portions.
In Figure 4-7, the disconnected Area 0s are linked via a virtual link through the common
Area 3. If a common area does not already exist, one can be created to become the transit
area.
For adjacency purposes, OSPF treats two routers joined by a virtual link as an unnumbered
point-to-point backbone network because they don’t share a physical connection and,
therefore, the IP address of their connecting interfaces is not on the same IP subnet.
TIP When an unnumbered interface is configured, it references another interface on the router.
When enabling OSPF on the unnumbered interface with the network command, use an
address wildcard-mask pair that refers to the interface to which the unnumbered interface
is pointing.
Using and Configuring OSPF Multiarea Components

No special commands exist to activate the ABR or ASBR functionality on a router. The
router takes on this role by virtue of the areas to which it is connected. As a reminder, the
basic OSPF configuration steps are as follows:
Step 1 Enable OSPF on the router.
router(config)#router ospf process-id
Step 2 Identify which IP networks on the router are part of the OSPF network.
For each network, you must identify what area the network belongs to.
When configuring multiple OSPF areas, make sure to associate the
correct network addresses with the desired area ID, as shown in
Figure 4-8 and Example 4-5.
router(config-router)#network address wildcard-mask area area-id
Step 3 (Optional) If the router has at least one interface connected into a non-
OSPF network, perform the proper configuration steps. At this point,
the router will be acting as an ASBR. How the router exchanges
(redistributes) non-OSPF route information with the other OSPF routers
is discussed in Chapter 8.
NOTE Refer to Chapter 3 for details about basic OSPF configuration commands.
Example 4-5 provides the configuration for an internal router (Router A) and for an ABR
(Router B), as shown in Figure 4-8.
Example 4-5 Configuring an OSPF Interarea Router and Area Border Router
<Output Omitted>
RouterA(config)#interface Ethernet0
Using and Configuring OSPF Multiarea Components 189
Example 4-5 Configuring an OSPF Interarea Router and Area Border Router (Continued)
RouterA(config-if)#ip address 10.64.0.1 255.255.255.0
!
<Output Omitted>
RouterA(config)#router ospf 77
RouterA(config-router)#network 10.0.0.0 0.255.255.255 area 0
<Output Omitted>
RouterB(config)#interface Ethernet0
!
RouterB(config)#interface Serial0
<Output Omitted>
RouterB(config)#router ospf 50
Figure 4-8 Configuring Interarea Routers and ABRs
Area 0 ABR Area 1

E0 10.64.0.2 S0
10.2.1.2 10.2.1.1
A 10.64.0.1 E0 B S1 C
Using Stub and Totally Stubby Areas

RFCs provide for OSPF stub and OSPF NSSA configuration. NSSA is discussed in
Appendix A. Totally stubby area is a Cisco proprietary standard. This section is concerned
with stub areas and totally stubby areas.
Configuring a stub area reduces the size of the link-state database inside that area, thus
reducing the memory requirements on routers. External networks (type 5 LSAs), such as
those redistributed from other protocols into OSPF, are not allowed to be flooded into a stub
area, as shown in Figure 4-9. Routing from these areas to the outside world is based on a
default route (0.0.0.0). ABRs inject the default route (0.0.0.0) into the stub area. Having a
default route means that if a packet is addressed to a network that is not in an internal
router’s route table, the router will automatically forward the packet to the ABR that sent a
0.0.0.0 LSA. This allows routers within the stub to reduce the size of their routing tables
because a single default route replaces the many external routes.
A stub area is typically created when you have a hub-and-spoke topology, with the spoke
being the stub area, such as a branch office. In this case, the branch office does not need to
know about every network at the headquarters site; instead, it can use a default route to get
there.
Figure 4-9 Flooding LSAs to a Stub Area
RIP
Area 50—Stub Area 0
Internal ABR1 ASBR BBone

Non-Cisco
router
Summary Summary
Default External
To further reduce the number of routes in a table, you can create a totally stubby area, which
is a Cisco-specific feature. A totally stubby area is a stub area that blocks external type 5
LSAs and summary (type 3 and type 4) LSAs (interarea routes) from going into the area,
as shown in Figure 4-10. This way, intra-area routes and the default of 0.0.0.0 are the only
routes known to the stub area. ABRs inject the default summary link 0.0.0.0 into the totally
stubby area. Each router picks the closest ABR as a gateway to everything outside the area.
Totally stubby areas further minimize routing information (as compared to stub areas) and
increase stability and scalability of OSPF internetworks. This is typically a better solution
than creating stub areas, unless the target area uses a mix of Cisco and non-Cisco routers.
An area could be qualified as a stub or totally stubby when it meets the following criteria:
• There is a single exit point from that area, or, if multiple exits (ABRs) exist, routing
to outside the area does not have to take an optimal path. If the area has multiple exits,
one or more ABRs will inject a default route into the stub area. In this situation,
routing to other areas or autonomous systems could take a suboptimal path in reaching
the destination by going out of the area via an exit point that is farther from the
destination than other exit points.
• All OSPF routers inside the stub area (ABRs and internal routers) are configured as
stub routers so that they will become neighbors and exchange routing information.
The configuration commands for creating stub networks are covered in the next
section.
• The area is not needed as a transit area for virtual links.
Figure 4-10 Flooding LSAs to a Totally Stubby Area
RIP
Area 0 Area 1—Totally stubby
ASBR BBone ABR2 Internal
Summary Default
External Default
• No ASBR is internal to the stub area.

• The area is not the backbone area (not Area 0).
These restrictions are necessary because a stub or a totally stubby area is mainly configured
to carry internal routes and can’t have external links injected in that area.
Configuring Stub and Totally Stubby Areas

To configure an area as stub or totally stubby, do the following:
Step 1 Configure OSPF, as described earlier in this chapter.
Step 2 Define an area as stub or totally stubby by adding the area stub
command to all routers within the area, as explained in Table 4-2:
router (config-router)#area area-id stub [no-summary]
Table 4-2 area stub Command for Configuring Stub and Totally Stubby Areas
area stub
Command Description
area-id Serves as an identifier for the stub or totally stubby area. The identifier can
be either a decimal value or an IP address.
no-summary (Only for ABRs connected to totally stubby areas.) Prevents an ABR from
sending summary link advertisements into the stub area. Use this option for
creating a totally stubby area.
NOTE Remember that the stub flag contained in the hello packet must be set on all routers within
a stubby area.
NOTE The no-summary keyword can be put on non-ABR routers, but it has no effect.
Step 3 (Optional, for ABRs only.) Define the cost of the default route that is
injected in the stub or totally stubby area, using the area default-cost
command, as explained in Table 4-3.
router (config-router)#area area-id default-cost cost
Table 4-3 Changing the OSPF Cost
area default-cost
Command Description
area-id Identifier for the stub area. The identifier can be either a decimal
value or an IP address.
cost Cost for the default summary route used for a stub or totally stubby
area. The cost value is a 24-bit number. The default cost is 1.
Stub Area Configuration Example

In Example 4-6, Area 2 is defined as the stub area, as shown in Figure 4-11. No external
routes from the external autonomous system will be forwarded into the stub area.
Example 4-6 Configuring a Stub Area
R3#
interface Ethernet 0
ip address 192.168.14.1 255.255.255.0
interface Serial 0
ip address 192.168.15.1 255.255.255.252
router ospf 100

network 192.168.14.0 0.0.0.255 area 0
network 192.168.15.0 0.0.0.255 area 2
area 2 stub
R4#
interface Serial 0
ip address 192.168.15.2 255.255.255.252
Example 4-6 Configuring a Stub Area (Continued)

router ospf 15
network 192.168.15.0 0.0.0.255 area 2
area 2 stub
The last line in the configuration of each router in Example 4-6, area 2 stub, defines the
stub area. The area stub default cost has not been configured on R3, so this router advertises
0.0.0.0 (the default route) with a default cost metric of 1 plus any internal costs.
Each router in the stub area must be configured with the area stub command.
Figure 4-11 Stub Area Topology
Stub Area 2
External 192.168.14.1 S0 192.168.15.1

AS E0 R3 192.168.15.2
Area 0 S0
R4
The only routes that will appear in R4’s routing table are intra-area routes (designated with
an O in the routing table), the default route, and interarea routes (both designated with an
IA in the routing table; the default route will also be denoted with an asterisk).
NOTE The area stub command determines whether the routers in the stub become neighbors. This
command must be included in all routers in the stub if they are to exchange routing
information.
Totally Stubby Area Configuration Example

In Example 4-7, the keyword no-summary has been added to the area stub command on
R3 (the ABR). This keyword causes summary routes (interarea) to also be blocked from the
stub area. Each router in the stub area picks the closest ABR as a gateway to everything
outside the area, as shown in Figure 4-12.
Example 4-7 Totally Stubby Configuration Example
R3#showrun
<output omitted>
router ospf 100
network 192.168.14.0 0.0.0.255 area 0
network 192.168.15.0 0.0.0.255 area 2
Example 4-7 Totally Stubby Configuration Example (Continued)

area 2 stub no-summary
R4#showrun
<output omitted>
router ospf 15
network 192.168.15.0 0.0.0.255 area 2
area 2 stub
Figure 4-12 Totally Stubby Area
Totally stubby
Area 2
External 192.168.14.1 S0 192.168.15.1

AS E0 R3 192.168.15.2
Area 0 S0
R4
In Example 4-7, the only routes that will appear in R4’s routing table are intra-area routes
(designated with an O in the routing table) and the default route. No interarea routes
(designated with an IA in the routing table) will be included.
Remember that to further reduce the number of link-state advertisements sent into a stub
area, you can configure no-summary on the ABR (R3) to prevent it from sending summary
link advertisements (link-state advertisements type 3) into the stub area—thus, R4 has only
intra-area routes.
NOTE As shown in Example 4-7, the difference in configuring a stub area and a totally stubby area
is the keyword no-summary applied on the ABR
How Does OSPF Generate Default Routes?

The way that OSPF generates default routes (0.0.0.0) varies depending on the type of area
into which the default route is being injected— normal areas, stub and totally stubby areas,
and NSSAs.
By default, in normal areas, routers don’t generate default routes. To have an OSPF router
generate a default route, use the default-information originate [always] [metric metric-
value] [metric-type type-value] [route-map map-name] router configuration command.
This generates an external type 2 link (by default) with link-state ID 0.0.0.0 and network
mask 0.0.0.0, which makes the router an Autonomous System Boundary Router (ASBR).
There are two ways to inject a default route into a normal area. If the ASBR already has the
default route, you can advertise 0.0.0.0 into the area. If the ASBR doesn’t have the route,
you can add the keyword always to the default-information originate command, which
will then advertise 0.0.0.0.
For stub and totally stubby areas, the ABR to the stub area generates a summary LSA with
the link-state ID 0.0.0.0. This is true even if the ABR doesn’t have a default route. In this
scenario, you don’t need to use the default-information originate command.
The ABR for the NSSA generates the default route, but not by default. To force the ABR to
generate the default route, use the area area-id nssa default-information-originate
command. The ABR generates a type 7 LSA with the link-state ID 0.0.0.0. If you want to
import routes only into the normal areas, but not into the NSSA area, you can use the no-
redistribution option on the NSSA ABR.
Multiple-Area NBMA Environment

Multiple areas can be used within nonbroadcast multiaccess (NBMA) OSPF environments.
In Figure 4-13, the networks located at the corporate headquarters are in Area 0, while the
fully meshed Frame Relay network and each of the regional site networks are assigned to
Area 1. Area 1 is a stub area. One benefit of this design is that it eliminates the flooding of
external LSAs into the Frame Relay network because OSPF does not flood external LSAs
into stub areas—in this case, Area 1. Router R1 functions as an ABR, which keeps topology
changes in Area 0 from causing a topological recalculation in Area 1. With this topology,
the remote LAN segments must participate in Area 1, or virtual links would need to be
configured so the LAN segment’s areas would connect to the backbone area.
Another possible OSPF area configuration involves putting all the Frame Relay interfaces
in Area 0, as shown in Figure 4-14. This permits the location of stub or transit areas at each
remote site and at the headquarters, but it causes summary LSAs to be flooded throughout
the Frame Relay network and results in a larger number of routers performing recalculation
if any topology change takes place in Area 0.
Supporting Route Summarization

Route summarization is the consolidation of multiple routes into a single advertisement.
The operation and benefits of route summarization are discussed in Chapter 2 . At this point,
however, you should realize the importance of proper summarization in a network. Route
summarization directly affects the amount of bandwidth, CPU, and memory resources
consumed by the OSPF process.
If summarization is not used, every specific-link LSA will be propagated into the OSPF
backbone and beyond, causing unnecessary network traffic and router overhead. Whenever
an LSA is sent, all affected OSPF routers will have to recompute their LSA databases and
routes using the SPF algorithm.
With summarization, only summarized routes will propagate into the backbone (Area 0).
This process is very important because it prevents every router from having to rerun the SPF
algorithm, increases the network’s stability, and reduces unnecessary traffic. Also with
summarization, if a network link fails, the topology change will not be propagated into the
backbone (and other areas by way of the backbone). As such, flooding outside the area will
not occur.
Figure 4-13 Multiple OSPF Area with Frame Relay
Area 0
R1
Frame relay
Area 1 (stub area)
NOTE Be careful with the terminology: summary LSAs (type 3 and type 4) may or may not
contain summarized routes.
Figure 4-14 Multiple OSPF Area in Frame Relay with a Centralized Area 0
Area 1
R1
Area 0
Frame relay
Area 2 Area 4
Area 3
Two types of summarization exist, as follows:

• Interarea route summarization—Interarea route summarization is done on ABRs
and applies to routes from within each area. It does not apply to external routes
injected into OSPF via redistribution. To take advantage of summarization, network
numbers within areas should be assigned in a contiguous way to be capable of
consolidating these addresses into one range.
• External route summarization—External route summarization is specific to
external routes that are injected into OSPF via redistribution. Here again, it is
important to ensure that the external address ranges that are being summarized are
contiguous. Summarizing overlapping ranges from two different routers could cause
packets to be sent to the wrong destination. Usually only ASBRs summarize external
routes, but ABRs can also do this.
Variable-Length Subnet Masking

Variable-length subnet masking (VLSM) is discussed in Chapter 2.
OSPF carries subnet mask information and therefore supports multiple subnet masks for
the same major network. Discontiguous subnets are also supported by OSPF because
subnet masks are part of the link-state database. However, other protocols such as Routing
Information Protocol version 1 (RIPv1) and Interior Gateway Routing Protocol (IGRP) do
not support VLSM or discontiguous subnets. If the same major network crosses the
boundaries of an OSPF and RIP or IGRP domain, VLSM information redistributed into RIP
or IGRP will be lost and static routes will have to be configured in the RIP or IGRP
domains.
Because OSPF supports VLSM, it is possible to develop a true hierarchical addressing
scheme. This hierarchical addressing results in very efficient summarization of routes
throughout the network.
Using Route Summarization

To take advantage of summarization, as discussed in Chapter 2, network numbers in areas
should be assigned in a contiguous way, thus enabling the grouping of addresses into one
range, as shown in Figure 4-15.
In Figure 4-15, the list of six networks in Router B’s routing table can be summarized into
two summary address advertisements.
Figure 4-15 Summarization Between Two Areas
Area 1 ABR Area 0
A B C
Summarization
Routing table for B

LSAs sent to router C
O 172.16.8.0 255.255.252.0
IA 172.16.8.0 255.255.248.0
O 172.16.12.0 255.255.252.0
O 172.16.16.0 255.255.252.0
O 172.16.20.0 255.255.252.0
IA 172.16.16.0 255.255.240.0
O 172.16.24.0 255.255.252.0
O 172.16.28.0 255.255.252.0
– Interarea (IA) summary link carries mask

– One entry can represent several subnets
The third octet of each address is shown in binary in Table 4-4, to illustrate which addresses
can be summarized.
Table 4-4 Binary Calculation of the Summarization on Router B
Decimal
Value of
Bit Value 128 64 32 16 8 4 2 1 Octet
The first two 0 0 0 0 1 0 0 0 8
addresses can be
summarized using
a /21 prefix
0 0 0 0 1 1 0 0 12
The last four 0 0 0 1 0 0 0 0 16
addresses can be
summarized using
a /20 prefix
0 0 0 1 0 1 0 0 20
0 0 0 1 1 0 0 0 24
0 0 0 1 1 1 0 0 28
Actual mask is /22 (255.255.252.0)
Configuring Route Summarization

In OSPF, summarization is off by default. To configure route summarization on the ABR,
do the following:
Step 1 Configure OSPF, as discussed earlier in this section.
Step 2 Instruct the ABR to summarize routes for a specific area before injecting
them into a different area, using the following area range command.
This command is defined in Table 4-5.
router(config-router)#area area-id range address mask
Table 4-5 area range Command
area range Command Description
area-id Identifier of the area about which routes are to be summarized
address Summary address designated for a range of addresses
mask IP subnet mask used for the summary route
To configure route summarization on an ASBR to summarize external routes, do the

following:
Step 1 Configure OSPF, as discussed earlier in this section.
Step 2 Instruct the ASBR to summarize external routes before injecting them
into the OSPF domain, using the summary-address command,
explained in Table 4-6.
router(config-router)#summary-address address mask [prefix mask][not-
advertise] [tag tag]
Table 4-6 summary-address Command
summary-address
Command Description
address Summary address designated for a range of addresses
prefix IP route prefix for the destination
not-advertise (Optional) Used to suppress routes that match the prefix/mask
pair
tag (Optional) Tag value that can be used as a match value for
controlling redistribution via route maps, or other routing
protocols such as EIGRP and BGP
NOTE The OSPF summary-address command summarizes only external routes. This command
is usually used on the ASBR that is injecting the external routes into OSPF, but may also
be used on an ABR. Use the area range command for summarization of routes between
OSPF areas (in other words, for summarization of IA routes).
Figure 4-16 provides the graphical representation of Example 4-8, where route
summarization can occur in both directions.
Figure 4-16 Summarization on Multiple Areas
Interface addresses Area 0 Interface addresses

(255.255.255.0 mask) (255.255.255.0 mask)
172.16.96.0 - 172.16.127.0
255.255.255.0
172.16.96.1 172.16.127.1
172.16.32.1 R1 R2 172.16.64.1
172.16.32.0 - 172.16.63.0 172.16.64.0 - 172.16.95.0

255.255.255.0 255.255.255.0
Area 1 Area 2
Example 4-8 Summarization Configuration on ABRs

R1#
router ospf 100
network 172.16.32.1 0.0.0.0 area 1
network 172.16.96.1 0.0.0.0 area 0
area 0 range 172.16.96.0 255.255.224.0
area 1 range 172.16.32.0 255.255.224.0
R2#
router ospf 100
network 172.16.64.1 0.0.0.0 area 2
network 172.16.127.1 0.0.0.0 area 0
area 0 range 172.16.96.0 255.255.224.0
area 2 range 172.16.64.0 255.255.224.0
In the configuration on router R1, the following is true:

• area 0 range 172.16.96.0 255.255.224.0—Identifies Area 0 as the area containing the
range of networks to be summarized into Area 1. The ABR R1 is summarizing the
range of subnets from 172.16.96.0 to 172.16.127.0 into one range: 172.16.96.0
255.255.224.0. This summarization is achieved by masking the first 3 left-most bits
of subnet 96 using the mask 255.255.224.0.
• area 1 range 172.16.32.0 255.255.224.0—Identifies Area 1 as the area containing the
range of networks to be summarized into Area 0. The ABR R1 is summarizing the
range of subnets from 172.16.32.0 to 172.16.63.0 into one range: 172.16.32.0
255.255.224.0.
The configuration on router R2 works exactly the same way.
NOTE Depending on your network topology, you may not want to summarize Area 0 networks.
For example, if you have more than one ABR between an area and the backbone area,
sending a summary LSA with the explicit network information will ensure that the shortest
path is selected. If you summarize the addresses, a suboptimal path selection may occur.
Configuring Virtual Links

To configure a virtual link, do the following:
Step 1 Configure OSPF, as described earlier in this section.
Step 2 On each router that will make the virtual link, create the virtual link using
the area virtual-link command, as explained in Table 4-7. The routers that
make the links are the ABR that connects the remote area to the transit area
and the ABR that connects the transit area to the backbone area.
router(config-router)#area area-id virtual-link router-id
Table 4-7 area virtual-link Configuration Command
area virtual-link
Command Description
area-id Area ID assigned to the transit area for the virtual link (decimal or
dotted decimal format). There is no default.
router-id Router ID of the virtual link neighbor.
If you do not know the neighbor’s router ID, you can Telnet to it and enter the show ip ospf
interface command, as displayed in Example 4-9.
Example 4-9 show ip ospf interface Command Output
remoterouter#show ip ospf interface ethernet 0
Internet Address 10.64.0.2/24, Area 0
Process ID 1, Router ID 10.64.0.2, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 10.64.0.2, Interface address 10.64.0.2
Backup Designated router (ID) 10.64.0.1, Interface address 10.64.0.1
In Figure 4-17, Area 3 does not have a direct physical connection to the backbone (Area 0),
which is an OSPF requirement because the backbone is a collection point for LSAs. ABRs
forward summary LSAs to the backbone, which in turn forwards the traffic to all areas. All
interarea traffic transits the backbone.
Figure 4-17 Need for a Virtual Link
Router ID
10.3.10.5
Area 1 Area 0
Token
R1 Ring
Router ID
10.7.20.123
R2
Area 3
To provide connectivity to the backbone, a virtual link must be configured between R2 and
R1. Area 1 will be the transit area, and R1 will be the entry point into Area 0. R2 will have
a logical connection to the backbone through the transit area.
In Figure 4-17, both sides of the virtual link must be configured. Example 4-10 shows the
configuration of R1 and R2; in these configurations:
• R2 has the command area 1 virtual-link 10.3.10.5. With this command, Area 1 is
defined to be the transit area, and the router ID of the other side of the virtual link is
configured.
• R1 has the command area 1 virtual-link 10.7.20.123. With this command, Area 1 is
defined to be the transit area, and the router ID of the other side of the virtual link is
configured.
Example 4-10 Virtual Link Configuration on Routers R1 and R2
R1#showrun
<output omitted>
router ospf 100
network 10.2.3.0 0.0.0.255 area 0
network 10.3.2.0 0.0.0.255 area 1
area 1 virtual-link 10.7.20.123
R2#showrun
<output omitted>
router ospf 63
network 10.3.0.0 0.0.0.255 area 1
network 10.7.0.0 0.0.0.255 area 3
area 1 virtual-link 10.3.10.5
Verifying OSPF Operation

The same show commands listed in Chapter 3 can be used to verify OSPF operation in
multiple areas. Some additional commands include the following:
• show ip ospf border-routers—Displays the internal OSPF routing table entries to
ABRs and ASBRs.
• show ip ospf virtual-links—Displays parameters about the current state of OSPF
virtual links.
• show ip ospf process-id—Displays information about each area to which the router
is connected, and indicates whether the router is an ABR, an ASBR, or both.
• show ip ospf [process-id area-id] database [keyword]—Displays the contents of the
topological database maintained by the router. Several keywords can be used with this
command to get specific information about links:
— network—Displays network link-state information.
— summary—Displays summary information about router link states.
— asbr-summary—Displays information about ASBR link states.
— external—Displays information about autonomous system external link
states.
— database-summary—Displays database summary information and totals.
Case Study: OSPF Multiarea

study.
This section provides an overview of JKL’s recently redesigned corporate network, as
shown in Figure 4-18. This topology embodies many of the characteristics that a properly
addressed hierarchical network should exhibit.
Case Study: OSPF Multiarea 205
Figure 4-18 JKL’s Enterprise Redesigned Network
JKL’s Enterprise Class B Public Address
Area 0
Frame Relay
network
FDDI
Area 3
Area 16
Area 11
Fast Ethernet
Ethernet
Serial
Following are some issues to consider when analyzing Figure 4-18:

• Requirements for a hierarchical topology
• Address allocation with route summarization
• Limits for routing update traffic
• Elements that affect convergence time
• Effects of an NBMA topology
Case Study Solution

Over the past few years, JKL Corporation had experienced continuous growth in all
of its business sectors. In some areas, the growth was very rapid and business needs
overshadowed good design principles. These growth spikes caused the address space to
become fragmented and caused the size of the topology tables and routing tables to increase
dramatically. Management was alerted to the fact that the network was no longer easily
scalable and that continued growth would only compound the problems. Rather than wait
for the scaling issues to dramatically affect their ability to do business, management
ordered a complete overhaul and upgrade of the network. For more than a year, portions of
the network were readdressed and reconfigured to form a hierarchical topology that
emphasized proper address allocation, summary routes, and ease of troubleshooting.
Proper design allowed Area 0 to be small, redundant, and free of host devices. Thanks to
proper address allocation, individual areas pass summary routes into Area 0 that enable
traffic between areas to be forwarded efficiently (because of the small number of entries in
the Area 0 routing tables) through the backbone. Area 0 design employed redundant links
to assist in rapid convergence in case of a link failure in the core of the network.
Although the backbone area must be numbered as zero, the numbers for the other areas can
be chosen arbitrarily. In Figure 4-18, three areas are shown, although more areas exist in
the actual network. These three areas were selected because they demonstrate different
technologies and topologies that OSPF supports. This multiarea topology demonstrates
the different router types (internal router, backbone router, Area Border Router, and
Autonomous System Border Router). This topology also offers an opportunity to reinforce
where the different types of LSAs (router, summary, default, and so on) are used.
Area 3 demonstrates a purely LAN-based topology. Therefore, the neighbor relationships
will be done automatically following DR/BDR elections.
Area 11 shows a partial-mesh (hub-and-spoke) switched network topology. In this area, the
neighbor either will be acquired dynamically or will be, preferably, manually configured.
Also, you must remember to use the broadcast keyword on the frame-relay map
commands to allow routing updates to pass through the switched portion of the network.
Area 16 is an example of a WAN-based, point-to-point topology. In this area, no DRs/DBRs
are elected and the neighborship is automatic. This area offers a favorable topology in
which an effective use of VLSM would help with address allocation.
A hierarchical topology in this case offers several benefits:
• Route summarization is available
• Area 0 routing table is small and efficient
• Link-state changes are localized to one area
• Convergence within an area is rapid
Configuration Exercise: Configuring a Multiarea OSPF Network 207
This case study gives you a chance to confirm that proper network design, especially of
large networks, provides numerous advantages when it comes to controlling the types and
frequency of routing information allowed in and out of areas.
Summary
After reading this chapter, you should be able to describe the issues with interconnecting
multiple areas, understand how OSPF addresses each of these issues, and explain the
differences among the possible types of areas, routers, and LSAs. You should also be able
to show how OSPF supports the use of VLSM, how it applies route summarization in
multiple areas, and how it operates in a multiple-area NBMA environment.
Finally, you should be able to configure a multiarea OSPF network and verify OSPF
operations in multiple areas.
Configuration Exercise: Configuring a Multiarea OSPF

Network
Complete the following exercise to configure OSPF with multiple areas.
Objectives
In this Configuration Exercise, you will configure the pxr1 router serial interface S3 to be
in OSPF Area 0. Then you will configure all other router serial interfaces to be part of a
specific OSPF area, other than 0. You will then verify connectivity to the backbone_r1
router, summarize the subnets in your OSPF area, and check again for connectivity to
backbone_r1 router.
When the previous tasks will have been completed, you will reconfigure your OSPF area to
be a stub area and then a totally stubby area, and verify connectivity to the backbone_r1
router.
As an additional exercise, you may want to reconfigure your OSPF area to be a not-so-
stubby area (NSSA) and verify connectivity to the backbone_r1 router. You will use
loopback interfaces to simulate type 7 external routes into your NSSA. You will then
summarize the simulated type 7 external routes into Area 0.
Also as an optional practice, you can configure an OSPF virtual link to support an OSPF
area not directly connected to Area 0.
You will use the show and debug commands to verify OSPF operations of all these
exercises.
Visual Objective
Figure 4-19 illustrates the topology used for this multiarea OSPF Configuration Exercise.
Figure 4-19 Configuration of Multiarea OSPF Network
backbone_r1 172.16.10.100/24
loopback 172.16.11.100/24
S1/0 S2/3
10.1.1.100/24 10.12.12.100/24
10.1.1.1/24 HDLC 10.12.12.12/24

S3 Pods 2 to 11 S3
OSPF Area 0
S0 p1r1 S2 S0 p12r1 S2
192.168.1.17/28 192.168.1.49/28 192.168.12.17/28 192.168.12.49/28
S1 S1
192.168.12.33/28
OSPF Area 1 OSPF Area 12
192.168.1.18/28 192.168.1.50/28 192.168.12.50/28
S0 S0 S0 S1 192.168.12.34/28 S0
S1 192.168.1.34/28
192.168.1.66/28 192.168.12.65/28
p1r2 E0 E0 p1r3 p12r2 E0 E0 p12r3
loopback 192.168.1.65/24 loopback loopback 192.168.12.66/28 loopback
192.168.101.101/28 172.26.1.17/28 192.168.112.112/24 172.26.12.17/28
OSPF AREA 101 172.26.1.33/28 OSPF AREA 112 172.26.12.33/28
172.26.1.49/28 172.26.12.49/28
Command List
In this Configuration Exercise, you will use the commands listed in Table 4-8 in logical
order. Refer to this list if you need configuration command assistance during the
Configuration Exercise.
Table 4-8 Commands Used in the Configuration Exercise
Command Description
router ospf 200 Enables OSPF with a process ID of 200
network 10.x.x.x 0.0.0.0 area 0 Specifies the interfaces on which to run OSPF, and their areas
area x range 192.168.x.0 Summarizes addresses
255.255.255.0
area x stub [no-summary] Configures an area as a stub or totally stubby area
area x virtual-link Creates an OSPF virtual link
192.168.x.49
area x nssa Configures an area as a not-so-stubby-area (NSSA)
summary-address 172.16.0.0 Summarizes external addresses into OSPF
255.255.0.0
show ip ospf Displays general information about the OSPF routing process
show ip ospf neighbor Displays information about OSPF neighbors
show ip ospf database Displays the entries in the OSPF link-state database
show ip ospf interface Displays OSPF-specific information about an interface
show ip ospf virtual-links Displays the status of the OSPF virtual links
debug ip ospf adj Shows the events involved in the building or breaking of an
OSPF adjacency
Setup
Setup is as follows:
Step 1 On pxr1, disable Frame Relay switching.
Reconfigure the pxr1 serial interfaces (S0, S1, S2, and S3) to be running
HDLC encapsulation. Change the pxr1 serial interface S0, S1, S2, and S3
to the correct IP address configuration:
pxr1 S0 192.168.x.17/28
pxr1 S1 192.168.x.33/28
pxr1 S2 192.168.x.49/28
pxr1 S3 10.x.x.x/24
Apply the no shut command to Serial 1 and Serial 3 interfaces on your

pxr1 router.
Step 2 On pxr2, remove the S0.1 subinterface.
p1r2(config)#no interface s0.1 point-to-point
Change the pxr2 S0 interface encapsulation back to HDLC. Reconfigure

the IP address on your pxr2 S0 to 192.168.x.18/28. Apply the no shut
command to Ethernet 0 and Serial 1 interfaces on pxr2.
Step 3 On pxr3, remove the S0.1 subinterface.
p1r3(config)#no interface s0.1 point-to-point
Change the pxr3 S0 interface encapsulation back to HDLC. Reconfigure

the IP address on your pxr3 S0 to 192.168.x.50/28. Apply the no shut
command to Ethernet 0 and interface on pxr3.
Step 4 On your pxr2 router, create a loopback interface (loopback 10) with the
following IP address:
Pod pxr2 Loopback10 Interface IP Address

1 192.168.101.101/24
2 192.168.102.102/24
3 192.168.103.103/24
4 192.168.104.104/24
5 192.168.105.105/24
6 192.168.106.106/24
7 192.168.107.107/24
8 192.168.108.108/24
9 192.168.109.109/24
10 192.168.110.110/24
11 192.168.111.111/24
12 192.168.112.112/24
Create three loopback interfaces on your pxr3 router using the following
IP addresses:
Router Int Loopback11 Int Loopback12 Int Loopback13

p1r3 172.26.1.17/28 172.26.1.33/28 172.26.1.49/28
p2r3 172.26.2.17/28 172.26.2.33/28 172.26.2.49/28
p3r3 172.26.3.17/28 172.26.3.33/28 172.26.3.49/28
Router Int Loopback11 Int Loopback12 Int Loopback13

p4r3 172.26.4.17/28 172.26.4.33/28 172.26.4.49/28
p5r3 172.26.5.17/28 172.26.5.33/28 172.26.5.49/28
p6r3 172.26.6.17/28 172.26.6.33/28 172.26.6.49/28
p7r3 172.26.7.17/28 172.26.7.33/28 172.26.7.49/28
p8r3 172.26.8.17/28 172.26.8.33/28 172.26.8.49/28
p9r3 172.26.9.17/28 172.26.9.33/28 172.26.9.49/28
p10r3 172.26.10.17/28 172.26.10.33/28 172.26.10.49/28
p11r3 172.26.11.17/28 172.26.11.33/28 172.26.11.49/28
p12r3 172.26.12.17/28 172.26.12.33/28 172.26.12.49/28
Task 1: Enabling OSPF with Multiple Areas and Area Summarization

Step 1 Type in the command to configure the pxr1 router to run OSPF, with the
S3 interface as the only interface within your pod to be in Area 0.
Step 2 What commands would you type to configure all the 192.168.x.y/28
interfaces on all routers in your pod to be in area x, where x = your pod
number?
Pod OSPF Area Number

1 Area 1
2 Area 2
3 Area 3
4 Area 4
5 Area 5
6 Area 6
7 Area 7
8 Area 8
9 Area 9
10 Area 10
11 Area 11
12 Area 12
Step 3 Verify you have full connectivity within your pod.
Step 4 Telnet to the backbone_r1 router; the password is cisco. Display its
routing table. Do you see your pod’s subnets as O IA routes in the
backbone_r1 routing table? What type of routes are O IA routes?
Exit the Telnet to the backbone_r1 router.
Step 5 Display the pxr1 routing table. Which types of OSPF routes are in the
routing table? (If there is another pod configured for OSPF, you should
see three types; otherwise, you should see two types.)
Display the pxr2 routing table. Which three types of OSPF routes are in
the routing table?
Which router within your pod is the Area Border Router (ABR)?
At the ABR, summarize all the 192.168.x.y/28 subnets in your area (area
x) into a single summarized route of 192.168.x.0/24.
Telnet to the backbone_r1 router; the password is cisco. Display the
backbone_r1 router’s routing table to verify that your subnets are
summarized properly. Exit the Telnet to the backbone_r1 router.
NVRAM.
Task 2: Enabling OSPF Stub Area

Step 1 Configure your pod’s OSPF area (area x) into a stub area. For this step,
on which router(s) do you need to configure?
Step 2 Do you still see the O IA routes in the pxr2 and pxr3 routing table?
Do you still see the O E2 route in the pxr2 and pxr3 routing table?
Explain your answer.
Do you see any additional routes in the pxr2 and pxr3 routing table that
were not there before?
Step 3 Use the show ip ospf command to verify that your OSPF area x is a stub
area.
Step 4 Verify you have full connectivity within your pod and to the backbone_r1
router loopback interfaces (you may also see routes to the other pods).
NVRAM.
Task 3: Enabling OSPF Totally Stubby Area

Step 1 Configure your pod’s OSPF area into a totally stubby area. For this step,
on which router(s) do you need to configure?
Do you still see the O IA routes in the pxr2 and pxr3 routing table? Please
explain your answer.
Step 2 Verify that you have full connectivity within your pod and to the
backbone_r1 router loopback interfaces (you may also see routes to the
other pods).
NVRAM.
Task 4: Enabling OSPF Not-So-Stubby Area (Optional)

Step 1 Remove the totally stubby area configuration commands and then
reconfigure your pod’s OSPF area into an NSSA area. For this step,
which router(s) do you need to configure? (On the pxr1 router, use the
default-information-originate option when configuring NSSA.)
NOTE On pxr1, you must remove the totally stubby area configuration command and then remove
the stub area configuration command to completely remove any stub characteristics before
configuring NSSA.
Step 2 Do you see any O IA routes in the pxr2 and pxr3 routing table?
Do you see any O*N2 route in the pxr2 and pxr3 routing table?
What type of route is the O*N2 route?
Step 3 Verify that you have full connectivity within your pod and to the
backbone_r1 router (you may also see routes to the other pods).
NVRAM.
Step 5 The loopback interfaces that you created on pxr3 in setup are used to
simulate type 7 external routes into your NSSA. Use the redistribute
command at your pxr3 routers to redistribute only the loopback interfaces
into your NSSA. Route redistribution will be discussed in Chapter 8. For

now, just enter the following commands to perform the redistribution at
the pxr3 router:
router ospf 200
redistribute connected metric-type 1 subnets route-map passlb
route-map passlb
match ip address 1
access-list 1 permit 172.26.x.0 0.0.0.255
x is your pod number.

Step 6 Do you see any O N1 routes in the routing table of pxr1? What type of
routes are those?
Telnet to the backbone_r1 router. Do you see your 172.26.x.0 routes in
the backbone_r1 routing table? What type of routes are those? Exit the
Telnet session to the backbone_r1 router when you’re done.
Step 7 At your pxr1 router, summarize the three external loopback interface
addresses into a single summarized route of 172.26.x.0 255.255.255.0,
where x = your pod number.
Telnet to the backbone_r1 router; the password is cisco. Display the
backbone_r1 router’s routing table to verify that your external routes are
summarized properly. Exit the Telnet session to the backbone_r1 router.
NVRAM.
Step 9 (Bonus step) Currently, your pod’s external summarized route shows up
as O E1 type route at the backbone_r1 router and at any other pods that
are configured. Change it so that it shows up as O E2 type route at the
backbone_r1 router and any other pods.
Bonus Questions
How is the OSPF cost metric calculated on Cisco routers?
Which type of external OSPF route will have its metric incremented as it
is distributed into the OSPF domain, type 1 or type 2?
Summarize the following subnet address range into the minimum
number of routes: 172.25.168.0/24 to 172.25.175.0/24
Task 5: Enabling OSPF Virtual Link to Support an OSPF Area Not

Connected to Area 0 (Optional)
Step 1 In this task, you will be setting up virtual links. Virtual links do not
support stub areas, so before you can perform the next task, you need to
remove the stub area commands.
Do not remove the loopback interfaces on any of your routers. You will
need to use them again in the later Configuration Exercises.
At your pxr1 router, remove any area stub or area nssa commands. Save
the current configuration of pxr1 to NVRAM. Note: if you have
configured NSSA, you must remove the area x nssa default-
information-originate command and then remove the area x nssa
command to completely remove any NSSA characteristics. Otherwise,
you must remove the totally stubby area configuration command and
then remove the stub area configuration command to completely remove
any stub characteristics.
At your pxr2 router, remove any area stub or area nssa commands from
your pxr2 router. Save the current configuration of pxr2 to NVRAM.
At your pxr3 router, remove any area stub or area nssa commands. Save
the current configuration of pxr3 to NVRAM.
Step 2 At your pxr2 router, place that loopback interface you created in setup
into the following assigned OSPF area:
Pod pxr2 loopback10 Interface IP Address OSPF Area

1 192.168.101.101/24 101
2 192.168.102.102/24 102
3 192.168.103.103/24 103
4 192.168.104.104/24 104
5 192.168.105.105/24 105
6 192.168.106.106/24 106
7 192.168.107.107/24 107
8 192.168.108.108/24 108
9 192.168.109.109/24 109
10 192.168.110.110/24 110
11 192.168.111.111/24 111
12 192.168.112.112/24 112
CHAPTER
5
Configuring EIGRP
After completing this chapter, you will be able to describe Enhanced Interior Gateway
Routing Protocol (EIGRP) features and operation; explain how EIGRP discovers, chooses,
and maintains routes; explain how EIGRP supports the use of variable-length subnet mask
(VLSM); explain how EIGRP operates in an NBMA environment; explain how EIGRP
supports the use of route summarization; and describe how EIGRP supports large networks.
You will also be able to configure EIGRP, verify EIGRP operation, and, given a set of
network requirements, configure an EIGRP environment and verify proper operation
(within described guidelines) of your routers. Also, given a set of network requirements,
you will be able to configure EIGRP in an NBMA environment and verify proper operation
(within described guidelines) of your routers.
EIGRP Overview
EIGRP is a Cisco proprietary protocol that combines the advantages of link-state and
distance vector routing protocols. This hybrid protocol provides the following features:
• Rapid convergence—EIGRP uses the Diffusing Update Algorithm (DUAL) to
achieve rapid convergence. A router running EIGRP stores backup routes, when
available, for destinations so that it can quickly adapt to alternate routes. If no
appropriate route or backup route exists in the local routing table, EIGRP queries its
neighbors to discover an alternative route. These queries are propagated until an
alternate route is found.
• Reduced bandwidth usage—EIGRP does not send periodic updates. Instead, it uses
partial updates when the path or the metric to a destination changes. When the route
information changes, DUAL sends an update about only that link rather than the entire
routing table. In addition, the information is passed only to routers that require it, in
contrast to link-state protocol operation, which sends a change update to all routers
within an area.
• Multiple network layer support—EIGRP supports AppleTalk, IP, and Novell
NetWare using protocol-dependent modules (PDMs).
248 Chapter 5: Configuring EIGRP
NOTE Only TCP/IP implementations of EIGRP will be thoroughly covered in this chapter.
AppleTalk and EIGRP, and IPX and EIGRP are covered in Appendix A, “Job Aids and
Supplements.”
EIGRP has its roots as a distance vector routing. Like its predecessor IGRP, EIGRP is easy
to configure and is adaptable to a wide variety of network topologies. What makes EIGRP
an advanced distance vector protocol is its addition of several link-state features, such as
dynamic neighbor discovery.
Although EIGRP is compatible with IGRP, it offers superior performance thanks to a rapid
convergence and the guarantee of a loop-free topology at all times. Partial routing updates
are generated only upon topology changes. Distribution of partial updates is bounded so
that only routers that need the information are updated. As a classless routing protocol,
EIGRP advertises a routing mask for each destination network. This feature enables support
of discontiguous subnetworks and VLSM.
An additional feature of EIGRP is its capability to support IPX and AppleTalk protocols as
well as IP. The EIGRP rapid convergence and sophisticated metric offer superior
performance and stability when implemented in IPX and AppleTalk networks.
To summarize, the following are the key features of EIGRP:
• Rapid convergence
• Reduced bandwidth usage
• Support for multiple network layer protocols
• Advanced distance vector capabilities
• 100% loop-free
• Easy configuration
• Incremental updates
• Support for VLSM, discontiguous networks, and classless routing
• Compatibility with IGRP
Advantages of EIGRP
EIGRP offers many advantages over traditional distance vector routing protocols. One of
the most significant advantages is in the area of bandwidth utilization. With EIGRP,
operational traffic is primarily multicast rather than broadcast. As a result, end stations are
unaffected by routing updates or queries.
EIGRP uses the IGRP algorithm for metric calculation, although the value is represented in
32-bit format, providing an additional granularity for route selection. The EIGRP metric is
EIGRP Overview 249
the IGRP metric multiplied by 256. A significant advantage of EIGRP is its support for
unequal metric load balancing that allows administrators to better distribute traffic flow in
their networks.
Some of the EIGRP operational characteristics are borrowed from link-state protocols. For
example, EIGRP allows administrators to create summary routes at any bit position within
the network rather than the traditional distance vector approach of performing classful
summarization at major network number boundaries. EIGRP also supports route
redistribution from other routing protocols.
Like all TCP/IP routing protocols, EIGRP relies on IP packets to deliver routing
information. The EIGRP routing process is a transport layer function of the OSI model. IP
packets carrying EIGRP information use protocol number 88 in their IP header. Figure 5-1
shows the format of an IP packet and values used to designate the packet payload.
Figure 5-1 Frame and IP Packet
88 - IGRP
6 - TCP
17 - UDP
Frame payload
C
Frame
IP Protocol R
header Packet payload
header number C
EIGRP was designed to operate in both LAN and WAN environments. In multiaccess
topologies, such as Ethernet and Token Ring, neighbor relationships are formed and
maintained using reliable multicasting. EIGRP supports all WAN topologies: dedicated
links, point-to-point links, and nonbroadcast multiaccess (NBMA) topology.
EIGRP supports both hierarchical and nonhierarchical IP addressing. EIGRP also supports
VLSM, thus promoting efficient allocation of IP addresses. Secondary addresses can be
applied to interfaces to solve particular addressing issues, although all routing overhead
traffic will be generated through the primary interface address.
By default, EIGRP performs route summarization at major network boundaries, as shown
in Figure 5-2. Also, administrators can configure manual summarization on arbitrary bit
boundaries to shrink the size of the routing table. EIGRP supports the creation of supernets
or aggregated blocks of addresses (networks).
Figure 5-2 Route Summarization Example
172.16.2.0/24
172.16.1.0/24 192.168.42.128/27
172.16.3.0/24
192.168.42.192/27 192.168.42.64/27
172.16.0.0/16 172.16.0.0/16
192.168.42.0/24
EIGRP Terminology
This section introduces terms related to EIGRP:
• Neighbor table—Each EIGRP router maintains a neighbor table that lists adjacent
routers. This table is comparable to the neighborship (adjacency) database used by
OSPF. It serves the same purpose, to ensure bidirectional communication between
each of the directly connected neighbors. EIGRP keeps a neighbor table for each
network protocol supported, such as an IP neighbor table, an IPX neighbor table, and
an AppleTalk neighbor table.
• Topology table—An EIGRP router maintains a topology table for each network
protocol configured: IP, IPX, and AppleTalk. All learned routes to a destination are
maintained in the topology table.
• Routing table—EIGRP chooses the best routes to a destination from the topology table
and places these routes in the routing table. The router maintains one routing table for
each network protocol.
• Successor—This is the primary route used to reach a destination. Successors are
kept in the routing table.
• Feasible successor—This is a neighbor that is downstream with respect to the
destination, but it is not the least-cost path and thus is not used for forwarding data. In
other words, this is a backup route to the destination. These routes are selected at the
same time as successors, but are kept in the topology table. The topology table can
maintain multiple feasible successors for a destination.
EIGRP Operation 251
EIGRP Operation
This section discusses elements of EIGRP operations:
• EIGRP packets
• EIGRP neighbor relationship
EIGRP Packets
EIGRP uses the following five types of packets:
• Hello—Hello packets are used for neighbor discovery. They are sent as multicasts and
carry a 0 acknowledgment number.
• Update—An update is sent to communicate the routes that a particular router has
used to converge. These updates are sent as multicasts when a new route is discovered
and when convergence is completed (when the route becomes passive). To
synchronize topology tables, updates are sent as unicasts to neighbors during their
EIGRP startup sequence. Updates are sent reliably.
• Queries—When a router is performing route computation and can’t find a feasible
successor, it sends a query packet to its neighbors asking if they have a feasible successor
to the destination. Queries are always multicast and are sent reliably.
• Replies—A reply packet is sent in response to a query packet. Replies are unicasts to
the originator of the query and are sent reliably.
• ACK—The ACK is used for acknowledging updates, queries, and replies. ACKs are
hello packets sent as unicasts and contain a nonzero acknowledgment number.
EIGRP Reliability
EIGRP’s reliability mechanism ensures delivery of critical route information to
neighboring routers. This information is required to allow EIGRP to maintain a loop-free
topology. All packets carrying routing information (update, query, and reply) are sent
reliably. Assigning a sequence number to each reliable packet, and requiring an explicit
acknowledgment for that sequence number, provides reliability.
The Reliable Transport Protocol (RTP) is responsible for guaranteed, ordered delivery
of EIGRP packets to all neighbors. It supports intermixed transmission of multicast or
unicast packets. For efficiency, only certain EIGRP packets are transmitted reliably. On
a multiaccess network that has multicast capabilities, such as Ethernet, it is not
necessary to send hello packets reliably to all neighbors individually. For that reason,
EIGRP sends a single multicast hello packet containing an indicator that informs the
receivers that the packet need not be acknowledged. Other types of packets, such as
updates, indicate in the packet that acknowledgment is required. RTP contains a
provision for sending multicast packets quickly when unacknowledged packets are
pending, which helps ensure that convergence time remains low in the presence of
varying speed links.
RTP ensures that ongoing communication is maintained between neighboring routers. As
such, a retransmission list is maintained for each neighbor. This list indicates packets not
yet acknowledged by a neighbor. Unacknowledged reliable packets are retransmitted up to
16 times or up to the hold time, whichever is longer.
Hold Time
The length of time, in seconds, that the router will wait to hear from the peer before
declaring it down is the hold time. The default hold time is set to three times the hello
interval. The hold time value can be seen with the show ip eigrp neighbors command.
The use of reliable multicast packets is efficient. A potential delay exists on multiaccess
media where multiple neighbors reside. The next reliable multicast packet cannot be
transmitted until all peers have acknowledged the previous multicast. If one or more peers
are slow to respond, this adversely affects all peers by delaying the next transmission. RTP
is designed to handle such exceptions. Neighbors that are slow to respond to multicasts
have the unacknowledged multicast packets retransmitted as unicasts. This allows the
reliable multicast operation to proceed without delaying communication with other peers.
EIGRP Neighbor Relationship

The router sends hello packets out of interfaces configured for EIGRP. The EIGRP
multicast address used is 224.0.0.10. When an EIGRP router receives a hello packet from
a router belonging to the same autonomous system, it establishes a neighbor relationship
(adjacency).
The time interval of Hello packets varies depending on the media. Hello packets are
released every 5 seconds on a LAN link such as Ethernet, Token Ring, and FDDI. The
default interval is also set to 5 seconds for point-to-point links such as Point-to-Point
Protocol (PPP), High-Level Data Link Control (HDLC), point-to-point Frame Relay, ATM
subinterfaces, and for multipoint circuits with bandwidth greater than T1, including ISDN
Primary Rate Interface (PRI), Switched Multimegabit Data Service (SMDS), and Frame
Relay. Hello packets are sent out less frequently on lower-speed links, such as multipoint
serial interfaces and ISDN Basic Rate Interfaces (BRI). Hellos are generated at 60-second
intervals on these types of interfaces.
EIGRP Operation 253
Through the Hello protocol, an EIGRP router dynamically discovers other routers directly
connected to it. Information learned about neighbors, such as address and interface used by
neighbors, is maintained in the neighbor table. The neighbor table also maintains the hold
time. The hold time is the amount of time a router considers a neighbor up, without
receiving a hello or some other EIGRP packet from that neighbor. Hello packets report the
hold time value.
If a packet is not received before the expiration of the hold time, then a topology change is
detected. The neighbor adjacency is deleted, and all topology table entries learned from that
neighbor are removed, as if the neighbor had sent an update stating that all the routes are
unreachable. This enables the routes to quickly reconverge if an alternate feasible route is
available. A route is considered passive when the router is not performing recomputation
on that route. The route is active when it is undergoing recomputation.
The rate at which hello packets are sent, called the hello interval, can be adjusted per
interface with the ip eigrp hello-interval command. The hold time interval is set by default
to three times the hello interval. Therefore, the default hold time value is 15 seconds on
LAN and fast WAN interfaces, and 180 seconds on slower WAN interfaces. The hold time
can also be adjusted with the ip eigrp hold-time command.
NOTE If you change the hello interval, you must manually adjust the hold time to reflect the
configured hello interval.
It is possible for two routers to become EIGRP neighbors even though the hello and hold
time values do not match; this means that the hello interval and hold time values can be set
independently on different routers.
EIGRP will not build peer relationships over secondary addresses because all EIGRP traffic
uses the primary address of the interface. In addition, peer relationships will not be formed
if the neighbor resides in a different autonomous system or if the metric-calculation
mechanism constants (the K-values) are misaligned on that link. K-values are discussed
later in this section.
Neighbor Table
Like OSPF, EIGRP routers multicast hello packets to discover neighbors and to exchange
route updates. In Chapter 3, “Configuring OSPF in a Single Area,” you learned that only
adjacent routers will exchange routing information. Each router builds a neighbor table
from hello packets that it receives from adjacent EIGRP routers running the same network
layer protocol. The IP neighbor table can be looked at with the show ip eigrp neighbors
command, as shown in Example 5-1.
Example 5-1 Output of the show ip eigrp neighbors command
p2r2#show ip eigrp neighbors
IP-EIGRP neighbors for process 400
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 172.68.2.2 To0 13 02:15:30 8 200 0 9
0 172.68.16.2 Se1 10 02:38:29 29 200 0 6
EIGRP maintains a neighbor table for each configured network layer protocol. The table
includes the following key elements:
• H (handle)—A number used internally by the Cisco IOS to track a neighbor.
• Neighbor address—The network layer address of the neighbor.
• Interface—The interface on this router by which the neighbor can be reached.
• HoldTime—The maximum time to wait without receiving anything from a neighbor
before considering the link unavailable. Originally, the expected packet was a hello
packet, but in current Cisco IOS software releases, any EIGRP packets received after
the first hello from that neighbor will reset the timer.
• Uptime—Elapsed time, in hours, minutes, and seconds, since the local router first
heard from this neighbor.
• Smooth Round Trip Timer (SRTT)—The number of milliseconds it takes for an
EIGRP packet to be sent to this neighbor and for the local router to receive an
acknowledgment of that packet. This timer is used to determine the retransmit
interval, also known as the retransmit timeout (RTO).
• RTO—The amount of time, in milliseconds, that the software waits before
retransmitting a packet from the retransmission queue to a neighbor.
• Queue count—The number of packets waiting in queue to be sent out. If this value is
constantly higher than 0, there may be a congestion problem.
• Seq Num—Sequence number of the last update, query, or reply packet that was
received from this neighbor.
Topology Table
When the router dynamically discovers a new neighbor, it sends an update about the routes
that it knows to its new neighbor and receives the same from the new neighbor. These updates
populate what is known as the topology table. The topology table contains all destinations
advertised by neighboring routers. The show ip eigrp topology all-links command displays
all the IP entries in the topology table. The show ip eigrp topology command displays only
the successor and feasible successor for IP routes. It is important to note that if a neighbor is
EIGRP Operation 255
advertising a destination, then it must be using that route to forward packets. This rule must
be strictly followed by all distance vector protocols.
The topology table also maintains the metric that the neighbors advertise for each
destination and the metric that this router uses to reach the destination. The metric used by
this router is the sum of the best-advertised metric from all neighbors, plus the cost of this
router to reach the best neighbor. The topology table is also updated when a directly
connected route or interface changes, or when a neighboring router reports a change to a
route.
Initial Route Discovery

EIGRP combines in one step the process of discovering neighbors and learning routes.
Figure 5-3 illustrates the initial route discovery process.
Figure 5-3 Initial Route Discovery
Router A Router B
1 I am router A, who is on the link?

Hello
Here is my complete routing information. 2

Update
4
Topology Thanks for the information.
table 3 Ack
5 Here is my complete route information.

Update
Thanks for the information.

Ack 6
The following is a description of the initial route discovery process:

1 A new router (Router A) comes up on the link and sends out a hello packet through
all its interfaces.
2 Routers receiving the hello on one interface (Router B, in Figure 5-3) reply with
update packets that contain all the routes that they have in their routing table, except
those learned through that interface (split horizon). Unlike OSPF operation, Router
B does not send a hello packet back to Router A. Instead, the update packet
establishes a neighbor relationship between the communicating devices. As such,
these update packets have the Init bit set, indicating that this is the initialization
process. An update packet contains information about the routes that a neighbor is
aware of, including the metric that the neighbor is advertising for each destination.
3 Router A replies to each neighbor with an ACK packet, indicating that it received the
update information.
4 Router A inserts update packet information in its topology table. The topology table
includes all destinations advertised by neighboring (adjacent) routers. It is organized
so that each destination is listed, along with all the neighbors that can get to the
destination and their associated metric.
5 Router A then exchanges update packets with each of its neighbors.
6 Upon receiving the update packets, each router sends an ACK packet to Router A.
When all updates are received, the router is ready to choose the primary and backup
routes to keep in the topology table.
Split Horizon
Split horizon controls the sending of IP EIGRP update and query packets. When split
horizon is enabled on an interface, these packets are not sent for destinations for which this
interface is the next hop. This reduces the possibility of routing loops. By default, split
horizon is enabled on all interfaces.
Split horizon blocks information about routes from being advertised by a router out any
interface from which that information originated. This behavior usually optimizes
communications among multiple routers, particularly when links are broken.
Route Selection
EIGRP route selection process works differently than other routing protocols. EIGRP’s
route selection key characteristics are as follows:
• EIGRP selects primary and backup routes and injects those into the topology table (up
to six per destination). The primary routes are then moved to the routing table.
Similarly to OSPF, EIGRP supports several types of routes: internal, external
(that is, non-EIGRP), and summary routes. Internal routes are routes that
originate within the EIGRP AS. External routes are learned from another
routing protocol or from another EIGRP AS. Summary routes are routes
encompassing multiple subnets.
• The EIGRP metric is the IGRP metric multiplied by 256. The metric calculation can
use the following five variables:
— Bandwidth—The smallest bandwidth between the source and destination
EIGRP Operation 257
— Delay—Cumulative interface delay along the path

The following criteria, although available, are not commonly used because
they typically result in frequent recalculation of the topology table:
— Reliability—Worst reliability between source and destination based on
keepalives
— Loading—Worst load on a link between source and destination based on
bits per second
— Maximum transmission unit (MTU)—Smallest MTU in path
• EIGRP uses DUAL to calculate the best route to a destination. DUAL selects routes
based on the composite metric and assures that the selected routes are loop-free.
EIGRP calculates the metric by adding together weighted values of different variables of
the link to the network in question. The default constant values are K1 = K3 = 1, and K2 =
K4 = K5 = 0, where weights are attributed to the variables: K1 = bandwidth, K2 = load,
K3 = delay, K4 = reliability, and K5 = MTU.
In EIGRP metric calculations when KS is equal to 0, variables (bandwidth, bandwidth
divided by load, and delay) are weighted with the constants K1, K2, and K3. The following
is the formula used:
Metric = (K1 × bandwidth) + [(K2 × bandwidth) ÷ (256 – load)] + K3 × delay
If these K-values are equal to their defaults, the formula becomes:
Metric = 1 × bandwidth + [(0 × bandwidth) ÷ (256 – load)] + 1 × delay
Metric = bandwidth + [0] + delay
Metric = bandwidth + delay
If K5 is not equal to 0, an additional operation is performed:
Metric = Metric × [K5 ÷ (reliability + K4)]
K-values are carried in hello packets. Mismatched K-values can cause a neighbor to be
reset. (Only K1 and K3 are used, by default, in metric compilation). These K-values should
be modified only after careful planning. Changing these values can prevent your network
from converging.
NOTE The format of the delay and bandwidth values is different than those displayed by the show
interfaces command. The EIGRP delay value is the sum of the delays in the path, in tens
of microseconds, multiplied by 256. The show interfaces command displays delay in
microseconds.
The bandwidth is calculated using the minimum bandwidth link along the path, represented
in kilobits per second. This value is divided into 107 and then multiplied by 256.
EIGRP represents its metrics in a 32-bit format instead of the 24-bit representation used by
IGRP. This representation allows a more granular decision to be made when calculating
successor and feasible successor. When integrating IGRP routes into an EIGRP domain,
multiply the IGRP metric by 256 to get the EIGRP-equivalent metric.
Routing Table and the EIGRP Diffusing Update Algorithm (DUAL)

DUAL is the finite-state machine that selects which information will be stored in the
topology table. As such, DUAL embodies the decision process for all route computations.
It tracks all routes advertised by all neighbors. DUAL uses the distance information, known
as a metric, to select an efficient, loop-free path to each destination and inserts that choice
in the routing table. The lowest-cost route is calculated by adding the cost between the next-
hop router and the destination (referred to as the advertised distance [AD]) to the cost
between the local router and the next-hop router. (The total is referred to as the feasible
distance [FD].) A successor is a neighboring router used for packet forwarding that has a
least-cost path to a destination that is guaranteed not to be part of a routing loop. Multiple
successors can exist if they have the same feasible distance. All successors are added to the
routing table. The routing table is essentially a subset of the topology table. The topology
table contains more detailed information about each route, backup routes, and information
used exclusively by DUAL.
The next-hop router(s) for the backup path is referred to as the feasible successor (FS).
When the router loses a route, it looks at the topology table for an FS. If one is available,
the route will not go into an active state; rather, the best feasible successor will be promoted
as the successor and will be installed in the routing table. When there are not feasible
successors, a route will go into active state, and route computation occurs.
To qualify as a feasible successor, a next-hop router must have an advertised distance less
than the feasible distance of the current successor route. More than one feasible successor
can be kept at one time.
When there are no feasible successors but neighbors are advertising the destination, a
recompilation must occur. Through this process, a new successor is determined. The
amount of time that it takes to recalculate the route affects the convergence time.
DUAL Example
In the following example, you will examine partial entries (for Network [a]) of the topology
tables for Router C, Router D, and Router E to get a better understanding of EIGRP
behavior. The partial topology tables shown in Figure 5-4 indicate the following:
• FD or fd (feasible distance)—Equal to the sum of the costs of the links to reach
Network (a).
EIGRP Operation 259
• AD (advertised distance )—The link cost of the path to Network (a) as advertised by
neighboring routers.
• Successor—Forwarding path to Network (a); path cost equal to fd.
• fs (feasible successor)—An alternate path.
The sample network is stable and converged.
Figure 5-4 DUAL Example Step 1
Network
(a)
C EIGRP FD AD Topology
(a) 3 (fd)
via B 3 1 (Successor)
via D 4 2 (fs)
via E 4 3
Router A
(1)
D EIGRP FD AD Topology
(1) (a) 2 (fd)
via C 5 3
Router B (2) Router D
(2) (1)
E EIGRP FD AD Topology
(1) (a) 3 (fd)
via D 3 2 (Successor)
via C 4 3
Router C Router E
NOTE EIGRP implements the split-horizon technique. For example, Router E will not pass its
route for Network (a) to Router D because Router E uses Router D as its next hop to
Network (a).
In Figure 5-5, Routers B and D detect the link failure. Upon notification of the link failure,
DUAL performs the following step in Figure 5-5:
• At Router D: Marks the path to Network (a) through Router B as unusable.
Network
(a)
(a) 3 (fd)
via D 4 2 (fs)
via E 4 3
Router A
(1)
(1) (a) 2 (fd)
via C 5 3
(2) (1)
(1) (a) 3 (fd)
via C 4 3
Router C Router E
The following steps occur in Figure 5-6:

• At Router D: Has no feasible successor to Network (a) because the AD via C (3) is
greater than the FD via B (2).
— Sets the metric to Network (a) as unreachable (–1 is unreachable).
— Goes active on Network (a).
— Sends a query to Routers C and E for an alternate path.
— Marks Routers C and E as having a query pending (q).
• At Router E: Marks the path to Network (a) through Router D as unusable.
• At Router D: Receives reply from Router C; no change to path to Network (a).
— Removes query flag from Router C.
— Stays active on Network (a), awaiting reply from Router E (q).
• At Router E: Has no feasible successor to Network (a) because the AD from Router
C (3) is not less than the original FD (also 3).
— Generates a query to Router C.
— Marks Router C as query pending (q).
EIGRP Operation 261
Network
(a)
(a) 3 (fd)
via D
via E 4 3
Router A
(1)
(a) **ACTIVE** –1 (fd)
via E (q)
via C 5 3 (q)
Router B Router D
(2) Q
(2) (1)
Q
(1) (a) 3 (fd)
via C 4 3
Router C Router E
Network
(a)
(a) 3 (fd)
via D
via E
Router A
(1)
via E (q)
via C 5 3
Router B (2) R Router D
(2) (1)
(1) (a) **ACTIVE** –1 (fd)
Q via D
via C 4 3 (q)
Router C Router E

• At Router D: Stays active on Network (a), awaiting reply from Router E (q).
• At Router E: Receives reply from Router C indicating no change.
— Removes query flag from Router C.
— Calculates new FD and installs new successor route in table.
Network
(a)
(a) 3 (fd)
via D
via E
Router A
(1)
via E (q)
via C 5 3
(2) (1)
(1) (a) 4 (fd)
R via C 4 3 (Successor)
via D
Router C Router E

• At Router D: Receives reply from Router E.
— Removes query flag from Router E.
— Calculates new FD.
— Installs new successor routes in table. Two routes match the FD, and both
are marked as successors.
EIGRP Operation 263
Network
(a)
(a) 3 (fd)
via D
via E
Router A
(1)
(a) 5 (fd)
via C 5 3 (Successor)
R Router D via E 5 4 (Successor)
Router B (2)
(2) (1)
(1) (a) 4 (fd)
via D
Router C Router E

• At Router D: Two successor routes in the topology table for Network (a). Both
successor routes should be listed in the routing table, and equal-cost load balancing
should be in effect.
The network is stable and converged.
In Figure 5-4, the original topology (before the link failure) shows traffic from Router E
passing through Routers D and B. In Figure 5-10, the new topology shows traffic from
Routers D and E going through Routers C and B.
NOTE When DUAL decides that a packet needs to be transmitted to a neighbor, the packets are
not actually generated until the moment of transmission. The transmit queues instead
contain small, fixed-size structures that indicate which parts of the topology table to
include in the packet when it is finally transmitted. This means that the queues will not
consume large amounts of memory. It also means that only the latest information will be
transmitted in each packet. If a route changes state several times, only the last state will
be transmitted in the packet, thus reducing link utilization.
Network
(a)
(a) 3 (fd)
via D
via E
Router A
(1)
(a) 5 (fd)
via E 5 4 (Successor)
(2) (1)
(1) (a) 4 (fd)
via D
Router C Router E
Configuring EIGRP
This section covers the following topics:
• Steps for configuring EIGRP
• Route summarization
• EIGRP load balancing
• EIGRP and WAN links
• Using EIGRP in a scalable internetwork
• Verifying EIGRP operation
Steps for Configuring EIGRP

Perform the following steps to configure EIGRP for IP:
Step 1 Enable EIGRP, and define the autonomous system.
router(config)#router eigrp autonomous-system-number
autonomous-system-number is the number that identifies the

autonomous system. It is used to indicate all routers that belong within
the internetwork. This value must match on all routers within the
internetwork.
Configuring EIGRP 265
Step 2 Indicate which networks are parts of the EIGRP autonomous system.
router(config-router)#network network-number
network-number entries determine which interfaces of the router are

participating in EIGRP and to which networks the router advertises.
Step 3 If using serial links, especially for Frame Relay or SMDS, define the
bandwidth of a link for the purposes of sending routing update traffic on
the link. If you do not change the bandwidth value for these interfaces,
EIGRP assumes that the bandwidth on the link is of T1 speed. If the link
is slower, the router may not be capable of converging, or routing updates
might become lost.
router(config-if)#bandwidth kilobits
kilobits indicates the intended bandwidth in kilobits per second. With

point-to-point topology, such as PPP or HDLC, set the bandwidth to
match the line speed. For Frame Relay point-to-point interfaces, set the
bandwidth to the committed information rate (CIR). For multipoint
connections, set it to the sum of all CIRs.
Route Summarization
Some EIGRP features have distance vector characteristics, such as summarizing routes at
a major network boundary—this is an example of traditional distance vector behavior.
Traditional distance vector protocols, which are classful routing protocols, cannot presume
the mask for networks that are not directly connected because masks are not exchanged by
the routing updates.
Summarizing routes at major boundaries (classful) creates smaller routing tables. Smaller
routing tables, in turn, make the routing update process less bandwidth-intensive. Cisco
distance vector routing protocols have autosummarization enabled by default. As
mentioned earlier, EIGRP has its roots in IGRP and, therefore, summarizes at the network
boundary by default. EIGRP does autosummarization by default, but it can be turned off.
The inability to create summary routes at arbitrary boundaries with a major network has
been a drawback of distance vector protocols since their inception. EIGRP has the added
functionality to allow administrators to turn off autosummarization and to create one or
more summary routes within a network.
When summarization is configured on an interface, a summary route is added to the routing
table with a reference to Null0, a directly connected, software-only interface. The use of the
Null0 interface prevents the router from trying to forward traffic to other routers in search
of a more precise match.
For effective summarization, blocks of contiguous addresses (subnets) should funnel
back to a common router so that a single summary route can be created and then
advertised. The number of subnets that can be represented by a summary route is directly
related to the number of bits by which the subnet mask has been pulled back toward the
major network (natural) mask. The formula of 2n, where n equals the number of bits by
which the subnet mask has been reduced, indicates how many subnets can be represented
by a single summary route. For example, if the summary mask contains 3 fewer bits than
the subnet mask, then eight subnets can be aggregated into one advertisement (23 = 8 ).
When creating summary routes, the administrator needs to specify only the IP address of
the summary route and the routing mask. The Cisco IOS handles the details surrounding
proper implementation, such as metrics, loop prevention, and removal of the route from the
routing table when the summary route is no longer valid.
Configuring Summarization
EIGRP automatically summarizes routes at the classful boundary, but in some cases, you
may want to turn off this feature, such as if you have discontiguous subnets. This scenario
is discussed in Example 5-2. However, an EIGRP router will not perform an automatic
summarization of networks in which it does not participate.
To turn off automatic summarization, initiate the following command:
router(config-router)#no auto-summary
Use the following interface command to manually create a summary route at an arbitrary
network boundary or for networks in which your router does not participate:
router(config-if)#ip summary-address eigrp as-number address mask
Table 5-1 summarizes this command.

Table 5-1 ip summary-address eigrp Command
ip summary-address eigrp
Command Description
as-number EIGRP autonomous system number.
address The IP address being advertised as the summary
address. This address does not need to be aligned on
Class A, B, or C boundaries.
mask The IP mask being used to create the summary
address.
Figure 5-11 shows a discontiguous network 172.16.0.0. By default, both Routers A and B
summarize routes at the classful boundary. In this example, Router C will have two equally
good routes to network 172.16.0.0 and will perform load balancing between Router A and
Router B.
Figure 5-11 Summarizing EIGRP Routes
Router A
172.16.1.0
Router C
10.0.0.0
S0 World
172.16.2.0 192.168.4.2
Router B
As shown on Example 5-2, you can disable this feature to eliminate route summarization
so that Router C knows precisely that 172.16.1.0 is reached via Router A and that
172.16.2.0 is reached only via Router B.
Example 5-2 Turning Off EIGRP Autosummarization on Router A and Router B
router eigrp 1
network 10.0.0.0
network 172.16.0.0
no auto-summary
An EIGRP router autosummarizes routes for only networks to which it is attached. If a

network was not autosummarized at the major network boundary (as in Router A and
Router B because autosummary was turned off), then all the subnet routes will be carried
into the routing table of Router C. In turn, Router C will be sending routing information
about 172.16.1.0 subnet and 172.16.2.0 subnet out to the WAN.
Forcing a summary route out of Router C’s interface s0, as shown in Example 5-3, will help
reduce route advertisements about network 172.16.0.0 to the world.
The following are the steps for forcing summarization:
Step 1 Select the interface that will propagate the route summary.
Step 2 Specify the format of the route summary and the autonomous system of
the routes being summarized.
Example 5-3 Forcing Summarization
router eigrp 1
network 10.0.0.0
network 192.168.4.0
!
int s0
ip address 192.168.4.2 255.255.255.0
ip summary-address eigrp 1 172.16.0.0 255.255.0.0
NOTE For manual summarization, the summary is advertised only if a component (an entry that
is represented in the summary) of the summary is present in the routing table. Also, IP
EIGRP summary routes are given an administrative distance value of 5. Standard EIGRP
routes receive an administrative distance of 90, and external EIGRP routes receive an
administrative distance of 170.
You will notice the EIGRP summary route with an administrative distance of 5 only on the
local router performing the summarization with the summary-address command. You can
see this administrative distance on the router doing the summarization using the show ip
route network command, where the network is the specified summarized route.
EIGRP Load Balancing

Load balancing is the capability of a router to distribute traffic over all its network ports that
are the same distance from the destination address. Good load-balancing algorithms use
both line speed and reliability information. Load balancing increases the utilization of
network segments, thus increasing effective network bandwidth.
By default, the Cisco IOS will balance between a maximum of four equal-cost paths. Using
the router configuration command maximum-paths, you can request that up to six equally
good routes be kept in the routing table. When a packet is process switched, load balancing
over equal-cost paths occurs on a per-packet basis. When packets are fast switched, load
balancing over equal-cost paths is on a per-destination basis.
EIGRP can balance traffic across multiple routes that have different metrics. The amount
of load balancing that is performed can be controlled by the variance router configuration
command.
The multiplier is a variance value, between 1 and 128, used for load balancing. The default
is 1, which means equal-cost load balancing. The multiplier defines the range of metric
values that will be accepted for load balancing. In Figure 5-12, the variance is 2 and the
range of the metric values (the feasible distances) for Router E to get to Network Z is 20
through 45. This range of values is used in the procedure for determining the feasibility of
a potential route. A route is feasible if the next router in the path is closer to the destination
than the current router and if the metric for the entire path is within the variance. Only paths
that are feasible can be used for load balancing. The two feasibility conditions are listed
here:
• The local best metric (the current feasible distance) must be greater than the next
router best metric (the advertised distance) learned from the next router.
• The variance × the local best metric (the current feasible distance) must be greater
than the metric (the advertised distance) through the next router.
If both of these conditions are met, the route is called feasible and can be added to the
routing table.
Figure 5-12 EIGRP Load Balancing with a Variance of 2
20 10
Router B
10 10
Network Z
(config-router)# Router E Router C Router A

variance 2
20 25
Router D
Traffic Sharing
To control how traffic is distributed among routes when there are multiple routes for
the same destination network that have different costs, use the traffic-share router
configuration command. With the keyword balanced, the router distributes traffic
proportionately to the ratios of the metrics associated with the different routes. With
the keyword min, the router uses routes that have minimum costs.
Example of EIGRP Load Balancing

In Figure 5-12, Router E will use Router C as the successor because its feasible distance is
lowest (20). With the variance command applied to Router E, the path through Router B
meets the criteria for load balancing. In this case, the feasible distance through Router B is
less than twice the feasible distance for the successor (Router C). Router D will not be
considered for load balancing because the feasible distance through Router D is greater
than twice the feasible distance for the successor (Router C). Also, because Router D’s AD
of 25 is greater than Router E’s FD of 20, Router D is not considered closer to the
destination than Router E.
Example 5-4 is another example of unequal load balancing where four different paths to a
destination have different metric.
Example 5-4 Unequal Load-Balancing Example
Path 1: 1100
Path 2: 1100
Path 3: 2000
Path 4: 4000
By default, the router will route to the destination using both paths 1 and 2. To load-balance
over paths 1, 2, and 3, you would use the variance 2 command because 1100 × 2 = 2200,
which is greater than the metric through path 3. Similarly, to also include path 4, you would
issue the variance 4 command under the routing protocol configuration mode.
EIGRP and WAN Links

EIGRP is scalable on both point-to-point links and NBMA multipoint and point-to-point
links. Because of the inherent differences in operational characteristics of links, default
configuration of WAN connections may not be optimal. A solid understanding of EIGRP
operation coupled with knowledge of link speeds can yield an efficient, reliable, and
scalable router configuration.
EIGRP Link Utilization

By default, EIGRP will use up to 50 percent of the bandwidth declared on an interface or
subinterface. This percentage can be adjusted on an interface or subinterface with the
following interface command:
Router(config-if)#ip bandwidth-percent eigrp as-number percent
The percent parameter can be set to a value greater than 100. This is useful if the bandwidth
is configured artificially low for routing policy reasons. Example 5-5 shows a configuration
that allows EIGRP to use 40 kbps (200 percent of the configured bandwidth) on the
interface. It is essential to make sure that the line is provisioned to handle the configured
capacity.
Example 5-5 Adjusting the EIGRP Link Utilization
interface serial0
bandwidth 20
ip bandwidth-percent eigrp 1 200
The Cisco IOS treats point-to-point Frame Relay subinterfaces in the same manner as any
serial interface when it comes to bandwidth. The IOS presumes that those serial interfaces
and subinterfaces are operating at full T1 link speed. In many implementations, however,
only fractional T1 speeds are available. Therefore, when configuring these types of
interfaces, set the bandwidth to match the contracted CIR.
When configuring multipoint interfaces (especially for Frame Relay) remember that the
bandwidth is shared equally by all neighbors. That is, EIGRP uses the bandwidth
statement of the physical interface divided by the number of Frame Relay neighbors
connected on that physical interface to get the bandwidth attributed to each neighbor.
EIGRP configuration should reflect the correct percentage of the actual available
bandwidth on the line.
Each installation has a unique topology, and with that comes unique configurations.
Differing CIR values often require a hybrid configuration that blends the characteristics of
point-to-point circuits with multipoint circuits. When configuring multipoint interfaces,
configure the bandwidth to represent the minimum CIR times the number of circuits. This
approach may not fully utilize the higher-speed circuits, but it ensures that the circuits with
the lowest CIR will not be overdriven. If the topology has a small number of very low-speed
circuits, these interfaces should be defined as point-to-point so that their bandwidth can be
set to match the provisioned CIR.
In Figure 5-13, the interface has been configured for a bandwidth of 224 kbps. In a pure
multipoint topology, each circuit will be allocated one-quarter of the configured bandwidth
on the interface, and this 56 kbps allocation matches the provisioned CIR of each circuit.
Figure 5-13 Frame-Relay Multipoint in Which All VCs Share the Bandwidth Evenly
S0 Router C
T1
CIR 56 CIR 56
Frame
Relay
CIR 56 CIR 56
Router E Router H
Router F Router G
• All VCs share bandwidth evenly: 4 x 56 = 224
Example 5-6 shows the configuration for the interface Serial 0 of Router C:
Example 5-6 Adjusting the bandwidth command on an interface
interface serial 0
encapsulation frame-relay
bandwidth 224
In Figure 5-14, one of the circuits has been provisioned for a 56-kbps CIR, while the other
circuits have a higher CIR. This interface has been configured for a bandwidth that
represents the lowest CIR multiplied by the number of circuits being supported (56 × 4 =
224). This configuration protects against overwhelming the slowest speed circuit in the
topology.
Figure 5-14 Frame-Relay Multipoint in Which VCs Have Different CIRs
S0 Router C
T1
CIR 256 CIR 56
BW 224 BW 56
Frame
Relay
CIR 256 CIR 256
BW 224 BW 224
Router E Router H
Router F Router G
• Lowest CIR x # of VC: 56 x 4 = 224
In Figure 5-15, a hybrid solution is presented. There is only one low-speed circuit and other
VCs are provisioned for a higher CIR.
Figure 5-15 Frame-Relay Multipoint and Point-to-Point
S0 Router C
T1
CIR 256 S0.1

S0.2
BW 256
Frame CIR 56
Relay BW 56
CIR 256 CIR 256
BW 256 BW 256
Router E Router H
Router F Router G
Example 5-7 shows the configuration applied to Router C in Figure 5-15.

Example 5-7 Adjusting the Bandwidth for a Frame-Relay Subinterface
interface serial 0.1 multipoint
bandwidth 768
interface serial 0.2 point-to-point

bandwidth 56
Example 5-7 shows the low-speed circuit configured as point-to-point. The remaining
circuits are designated as multipoint, and their respective CIRs are added up to set the
bandwidth for the interface.
Figure 5-16 illustrates a common hub-and-spoke oversubscribed topology with ten virtual
circuits out to the remotes.
Figure 5-16 Frame Relay Hub-and-Spoke Topology
S0 Router C
Hub and spoke
with 10 VCs
256
CIR 56
CIR 56
BW 25
BW 25
Frame
Relay
CIR 56 CIR 56
BW 25 BW 25
Router E Router H
Router F Router G
• Configure each VC as point-to-point, specify BW = 1/10 of link capacity

• Increase EIGRP utilization to 50% of actual VC capacity
The circuits are provisioned as 56-kbps links, though there is not sufficient bandwidth at
the interface to support the allocation. In a point-to-point topology, all VCs are treated
equally and are configured for exactly one tenth (25 kbps) of the available link speed.
By default, EIGRP utilizes 50 percent of the configured bandwidth on a circuit. In an
attempt to ensure that EIGRP packets are delivered through the Frame Relay network in
Figure 5-16, each subinterface has the EIGRP allocation percentage raised to 110 percent
of the specified bandwidth. This adjustment results in EIGRP packets receiving

approximately 28 kbps of the provisioned 56 kbps on each circuit. This extra configuration
restores the 50-50 ratio that was tampered with when the bandwidth was set to an artificially
low value.
Example 5-8 shows the configuration used on Router C and Router G of Figure 5-16.
Example 5-8 EIGRP WAN Configuration—Point-to-Point Links
RouterC(config)#interface serial 0.1 point-to-point
RouterC(config-subif)#bandwidth 25
RouterC(config-subif)#ip bandwidth-percent eigrp 63 110
<output omitted>
RouterC(config)#interface serial 0.10 point-to-point
RouterC(config-subif)#bandwidth 25
RouterC(config-subif)#ip bandwidth-percent eigrp 63 110
RouterG(config)#interface serial 0
RouterG(config-if)#bandwidth 25
RouterG(config-if)#ip bandwidth-percent eigrp 63 110
NOTE Suppressing ACKs also saves bandwidth. An ACK will not be sent if a unicast data packet
is ready for transmission. The ACK field in any reliable unicast packet (RTP packet) is
sufficient to acknowledge the neighbor’s packet, so the ACK packet is suppressed to save
bandwidth. This is a significant feature for point-to-point links and NBMA networks
because on those media, all data packets are sent as unicasts and thus are capable of
carrying an acknowledgment themselves. In that instance, there is no need for another
packet known as an ACK packet.
Using EIGRP in a Scalable Internetwork

The following are some of the many variables that impact network scalability:
• The amount of information exchanged between neighbors—Too much
information exchanged between EIGRP neighbors causes unnecessary compilation
work during routing startup and topology changes.
• A topology change—When a topology change occurs, the amount of resources
consumed by EIGRP will be directly related to the number of routers that must be
involved in the change.
• The depth of the topology—The depth of the topology can impact the convergence
time. Depth refers to the number of hops that information must travel to reach all
routers.
• The number of alternative paths through the network—A network should

provide alternative paths to avoid single points of failure. At the same time,
however, too many alternative paths can create problems with EIGRP convergence.
As an advanced distance vector routing protocol, EIGRP relies on its neighbors to provide
routing information. If a route is lost and no feasible successor is available, EIGRP will
query its neighbors regarding the lost route.
When a router loses a route and does not have a feasible successor in its topology table, it
looks for an alternative path to the destination. This is known as going active on a route. (A
route is considered passive when a router is not performing recompilation on that route.)
Recompilation of a route involves sending query packets to all neighbors on interfaces other
than the one used to reach the previous successor (split horizon), inquiring whether they
have a route to the given destination. If a router has an alternate route, it will answer the
query and not propagate it further. If a neighbor does not have an alternative route, it will
query each of its own neighbors for an alternative path. The queries will then propagate out
through the network, thus creating an expanding tree of queries. When a router answers to
a query, it will stop the spread of the query through that branch of the network.
Because of the reliable multicast approach used by EIGRP when searching for an alternate
to a lost route, it is imperative that a reply be received for each query generated in the
network. In other words, when a route goes active and queries are initiated, the only way
that this route can come out of the active state is by receiving a reply for every generated
query. Therefore, a route will transition from active state to passive state when the router
receives a reply for every generated query.
If the router does not receive a reply to all the outstanding queries within 3 minutes, the
route goes to the stuck in active (SIA) state. The router then resets the neighbors that fail to
reply by going active on all routes known through that neighbor, and it readvertises all
routes to that neighbor. Limiting the scope of query propagation through the network (the
query range), also known as query scoping, helps reduce incidences of SIA.
NOTE The active-state time limit can be changed from it’s default of 3 minutes using the timers
active-time [time-limit | disabled] router configuration command. The time-limit is in
minutes.
NOTE Use the eigrp log-neighbor-changes command to enable the logging of neighbor
adjacency changes to monitor the stability of the routing system and to help detect problems
related to SIA.
Many networks have been implemented using multiple EIGRP autonomous systems to
somewhat simulate OSPF areas with mutual redistribution between the different
autonomous systems. Although this approach does change the way the network behaves, it
does not always achieve the results intended.
One erroneous approach for decreasing the chances of a stuck-in-active route is to use
multiple EIGRP autonomous systems, thus bounding the query range. If a query reaches
the edge of the AS (where routes are redistributed into another AS), the original query will
be answered. Then a new query will be initiated in the other AS by the edge router.
However, the query process has not been stopped because the querying continues in the
other AS, where the route can potentially go in SIA.
NOTE Stuck in active mode lasts for a maximum of 3 minutes by default, at which point DUAL
resets the neighbor relationship with the neighbor that failed to respond to the query.
The best solution to control queries is to reduce their reach in the internetwork. This is done
by summarization. However, the query range is not a common reason for stuck-in-active
routes being reported. The most common reasons for this are as follows:
• The router is too busy—The router is too busy to answer the query (generally
because of high CPU utilization).
• The router is having memory problems—The router cannot allocate the memory to
process the query or build the reply packet.
• Packets are lost between the routers because of circuit problems—Enough
packets are getting through to keep the neighbor relationship up, but some queries or
replies are not getting through.
• The router is using unidirectional links—This is a link on which traffic can flow in
only one direction due to failure.
Remote routers rarely need to know all the routes advertised in an entire network.
Therefore, it is the network manager’s responsibility to look at what information is
necessary to properly route user traffic, and maybe consider the use of a default route.
Examples of mechanisms used to limit what information is provided to other routers
include filters on routing updates and the ip summary-address command on the router’s
outbound interfaces.
In Figure 5-17, Router B notices the loss of network 10.1.8.0 and sends a query to Routers
A, C, D, and E. In turn, these routers send queries to their neighbors requesting a feasible
successor for 10.1.8.0. When the query process starts, each path receives duplicate queries
due to the topology. Therefore, not only are the remote routers required to respond to
queries from the head office, but they also continue the search by reflecting the queries back
toward the head office’s other router. This significantly complicates the convergence
process on the network.
Figure 5-17 Effect of the EIGRP Update and Query Process
Remote sites
Head office
10.1.8.0/24
Router C
Queries
Replies
Router B
Router D
Router A
Router E
In Figure 5-17, the architect provided redundancy with dual links from the head office to
remote sites. The architect did not mean for the traffic to go from the head office to the
remote office and back to the head office, but unfortunately this is the situation. The design
of the network in Figure 5-17 is sound, but because of EIGRP behavior, remote routers are
involved in the convergence process.
The ip summary-address command judiciously placed on Router A and Router B will
prevent some route components from being forwarded to remote routers, as shown in
Figure 5-18, thus reducing queries back to the head office.
Figure 5-18 Limiting Updates and Queries Using Summarization
Remote sites
Head office
10.1.8.0/24
Router C
Queries
Replies
Router B
Router D
Router A
ip summary-address eigrp 1 10.0.0.0 255.0.0.0 on

Router E
all outbound interfaces to remotes
Another approach would be to install route filters to limit advertisements to the remote
routers. Having proper filtering would cause the remote routers to reply to the head
office routers that the head office LANs are unreachable. A combination of
summarization and filtering could be used for best results.
EIGRP Scalability Rules

EIGRP has many features that allow for the creation of very large internetworks. Solid
design principles are the foundation upon which the network infrastructure rests.
Route summarization is most effective with a sound address allocation. Having a two- or
three-layer hierarchy, with routers positioned by function rather than by geography, greatly
assists traffic flow and route distribution.
Figure 5-19 shows the topology of a nonscalable internetwork in which addresses (subnets)
are randomly assigned. In this example, multiple subnets from different major networks are
located in each cloud, requiring many subnet routes to be injected into the core. In addition,
because of the random assignment of addresses, query traffic cannot be localized to any
portion of the network, thus increasing convergence time.
Figure 5-19 Example of a Nonscalable Internetwork
Core
1.1.1.0 2.2.1.0
1.1.2.0 3.3.2.0
2.2.3.0 3.3.3.0
3.3.4.0 1.1.4.0
3.3.1.0
2.2.2.0
1.1.1.0 1.1.3.0 2.2.1.0
3.3.4.0 1.1.4.0
Token 3.3.1.0 Token Token

Token Ring Ring Ring
Ring Token
2.2.3.0 1.1.3.0 Ring 3.3.4.0
1.1.2.0
3.3.3.0
Token
Ring
2.2.2.0
Figure 5-20 illustrates a better-designed network. Subnet addresses from individual major
networks are localized within each cloud. This allows for summary routes to be injected
into the core. As an added benefit, the summary routes act as a boundary for the queries
generated by a topology change.
Figure 5-20 Example of a Scalable Internetwork
Core
1.0.0.0 3.0.0.0
2.0.0.0
1.1.1.0 3.3.1.0
1.1.4.0 3.3.4.0
Token 2.2.1.0 Token Token

Token Ring Ring Ring
Ring Token
1.1.3.0 2.2.3.0 Ring 3.3.4.0
1.1.2.0
Token 3.3.3.0
Ring
2.2.2.0
Tiered Network Design

A tiered network model, as shown in Figure 5-21, provides benefits at all layers of the
hierarchical model:
• At the core—Summarized routes reduce the size of the routing table held by core
routers. These smaller tables make for efficient lookups, thus providing a fast-
switching core.
• At the regional head office—Summarized routes at the regional head office help in
the selection of the most efficient path by reducing the number of entries to be
checked.
• At the remote office—Proper allocation of blocks of addresses to remote offices

enables local traffic to remain local and not to unnecessarily burden other portions of
the network.
Figure 5-21 Tiered Network Topology
Summarized routes Summarized routes
Other Other
regions regions
Core
Other
regions
Other
regions
Regional head office
Remote office
Some common design principles should be followed for proper operation of EIGRP.
Routers located at convergence points within the network need sufficient memory to buffer
a large number of packets and to support numerous processes related to routing large
volumes of traffic.
On WAN links, and especially with the hub-and-spoke topology, enough bandwidth should
be provided to prevent router overhead traffic from interfering with normal user-generated
traffic. In this respect, the impact of EIGRP packets being lost because of contention for
bandwidth might be greater than application delays experienced by some users.
Multiple autonomous systems can share route information through the redistribution
process discussed in Chapter 8, “Optimizing Routing Update Operation.” Proper
implementation of redistribution requires route filters to prevent feedback loops. It is
strongly recommended that you implement route filters when redistributing between
routing protocols or multiple autonomous systems.
Verifying EIGRP Operation

This section discusses commands to use for verifying EIGRP operation.
Table 5-2 describes commands used to verify EIGRP operation.
Table 5-2 Verifying EIGRP Operation Commands
Command Description
show ip eigrp neighbors Displays neighbors discovered by EIGRP.
show ip eigrp topology Displays the EIGRP topology table. This
command shows the topology table, the active
or passive state of routes, the number of
successors, and the feasible distance to the
destination.
show ip route eigrp Displays the current EIGRP entries in the
routing table.
show ip protocols Displays the parameters and current state of the
active routing protocol process. This command
shows the EIGRP autonomous system number.
It also displays filtering and redistribution
numbers, as well as neighbors and distance
information.
show ip eigrp traffic Displays the number of EIGRP packets sent
and received. This command displays statistics
on hello packets, updates, queries, replies, and
acknowledgments.
Table 5-3 shows debug commands used to verify EIGRP operation.

Table 5-3 debug eigrp Commands
Command Description
debug eigrp packets Displays the types of EIGRP packets sent and
received. A maximum of 11 packet types can be
selected for individual or group display.
debug eigrp neighbors Displays neighbors discovered by EIGRP and
the contents of the hello packets.
Case Study: EIGRP 283
Table 5-3 debug eigrp Commands (Continued)

Command Description
debug ip eigrp Displays packets that are sent and received on
an interface. Because the debug ip eigrp
command generates large amounts of output,
use it only when traffic on the network is light.
debug ip eigrp summary Displays a summarized version of EIGRP
activity. It also displays filtering and
redistribution numbers, as well as neighbors
and distance information.
Case Study: EIGRP

study.
Link-state routing protocols, such as EIGRP, are commonly deployed in medium- to large-
scale networks. In Figure 5-22, EIGRP was selected by Acquisition D because of its ease
of implementation and management. There are fewer than 20 routers in the network, and
all WAN routers participate in the partially meshed Frame Relay network.
While looking at Figure 5-22, analyze how the following points are treated advantageously
by EIGRP over other routing protocols:
• Support for VLSM and discontiguous subnets
• Automatic route summarization at major network boundaries
• Manual route summarization at arbitrary network boundaries
• Support for various WAN topologies, including NBMA
• Efficient bandwidth utilization for overhead routing operations
• Support for hierarchical designs
• Route information exchanged by only routers within the same AS
Figure 5-22 EIGRP Case Study—JKL’s Topology
1 Class B - Public
1 Class C - Private
JKL’s acquisition D
Remote
offices
Autonomous
System 400
HQ
Rest of A
Frame Relay U
Core
Network
B G
Redundant V
PVCs to each Class C
Class B
Fast Ethernet
Ethernet
Serial
Case Study Solution

Acquisition D’s network is reasonably new and represents a redundant approach to support
the company’s business units at different remote locations. Although some communication
is required between the business units, each remote office primarily sends sales orders to
headquarters via the Frame Relay network.
Network designers applied a hierarchical design to assist in proper address allocation of D’s
public registered Class B address space. VLSM conserves addresses to allow for future
growth. The network administrators have already researched the possibility of using ip
unnumbered on the serial links to free up additional addresses if necessary.
Summary 285
One of the business units required a large number of users at its location, and a private
Class C address was deployed to provide the necessary support. Fortunately, some
default distance vector characteristicsof EIGRP (such as, automatic route summarization
and no discontiguous subnets) could be handled by additional router configuration
commands. Routers U and V have a no eigrp auto-summary command applied. This
command allows the subnets of U and V (discontiguous subnets) to pass through the Class
C network and to be advertised with the rest of the Class B subnets that make up AS400.
To honor their registered network advertisement to the Internet, a route filter is required on
the HQ routers to block the private Class C address from being advertised. With EIGRP,
manual summary routes can be applied at selected locations within the network as needed.
One of the reasons that Router D’s administrators selected EIGRP as the routing protocol
is for its rapid convergence. With a redundant NBMA topology like this one, convergence
could be slowed while waiting for query replies from all remote routers. Network
administrators have solved the convergence issue by applying a manual summary route
about the core network on the interface of the two HQ routers (on the left side of the
graphic) touching the Frame Relay cloud. The summarized route restricts the queries from
being propagated to all remote routers during the convergence process. This is an example
of query scoping, the mechanism by which the scope of the query packets is restricted to
encourage rapid convergence.
Remember that a migration to EIGRP will require all routers to be Cisco devices.
Summary
In this chapter, you learned about Cisco’s own EIGRP, an advanced routing protocol that
uses the DUAL algorithm to make decisions.
You learned about how EIGRP differs from OSPF, such as how EIGRP combines in one
step the discovering of neighbors and route learning process. Other features of EIGRP that
you learned about include its supports for VLSM and its autosummarization feature. You
saw that EIGRP is well suited for both LAN and WAN traffic, including an NBMA
environment.
Configuration Exercise #1: Configuring EIGRP
Complete the following Configuration Exercise to configure EIGRP.
Objectives
In the following Configuration Exercise, you will practice how to configure the routers
with EIGRP. You will also practice disabling EIGRP autosummarization and enabling
manual EIGRP route summarization. In addition, you will see the commands used to
verify EIGRP operations.
Assuming that the routers in your pod are properly cabled, your task is to do the following:
• Enable EIGRP on all routers within your assigned pods.
• Verify connectivity within your pod.
• Verify connectivity to the other pods.
Visual Objective
Figure 5-23 illustrates the topology used for this EIGRP Configuration Exercise.
Configuration Exercise #1: Configuring EIGRP 287
Figure 5-23 EIGRP Configuration Exercise Topology
172.16.10.100/24
172.16.11.100/24
backbone_r1 loopback
S1/0 S2/3
10.1.1.100/24 10.12.12.100/24
Pods 2 to 11
10.1.1.1/24 . . . . . . . . . . . 10.12.12.12/24
S3 EIGRP AS 200 S3
S0 p1r1 S0 p12r1
192.168.1.17/28 S2 192.168.12.17/28 S2
S1 192.168.1.49/28 S1 192.168.12.49/28
192.168.1.33/28 192.168.12.33/28
Pod 1 Pod 12
192.168.1.18/28 192.168.1.50/28 192.168.12.18/28 192.168.12.50/28

S0 S1192.168.1.34/28 S0 S0 S1 S0
192.168.12.34/28
p1r2 E0 E0 p1r3 p12r2 E0 E0 p12r3

192.168.1.65/28 192.168.1.66/28 192.168.12.65/28 192.168.12.66/28
Command List
list if you need configuration command assistance during this exercise.
Command Description
router eigrp 200 Enables EIGRP with an AS number of 200
network 10.0.0.0 Specifies interfaces on which to run EIGRP
show ip eigrp neighbors Displays information about EIGRP neighbors
show ip eigrp topology Displays the entries in the EIGRP topology
table
no auto-summary Disables EIGRP autosummarization
ip summary-address eigrp 200 192.168.x.0 Performs manual route summarization
255.255.255.128
debug eigrp packets Debugs EIGRP packets
Setup
To prepare your equipment prior to starting this Configuration Exercise, you will need to
perform the following steps:
Step 1 Shut the pxr1 S3 interface.
Step 2 Disable OSPF on all the routers within your pod.
Task 1: Enabling EIGRP Within Your Pod

Now enter commands that will activate EIGRP within your pod. Use the following steps to
guide you in this task.
Step 1 Enable EIGRP on all interfaces in the 192.168.x.0 network on all routers
within your pod. The AS number is 200.
Step 2 Verify that you have full connectivity within your pod.
Step 3 Examine the routing tables of pxr1, pxr2, and pxr3.
What is the administrative distance for EIGRP?

How is the EIGRP metric different than the IGRP metric?
Does EIGRP support load balancing by default?
Step 4 From the pxr1 router, issue the command to display information about
the EIGRP neighbors. What would that command be?
How many entries do you see in the pxr1 EIGRP neighbors table?
Step 5 From the pxr1 router, what would be the command to display the EIGRP
topology table?
How many successor routes are available from pxr1 to subnet
192.168.x.64/28?
What is the FD from pxr1 to subnet 192.168.x.64/28?
What is the AD to subnet 192.168.x.64/28 via S0?
Step 6 Which command would save the current configurations of all the routers
within your pod to NVRAM?
Configuration Exercise #1: Configuring EIGRP 289
Task 2: Enabling EIGRP Connectivity to the backbone_r1 Router

Complete the following steps.
Step 1 Which command would you type to reactivate the pxr1 S3 interface?
Step 2 Which command would you use to enable EIGRP on the S3 interface of
your pxr1 router?
Step 3 What command would you type to verify that you have full connectivity
to the backbone router loopback interfaces?
Step 4 Examine the routing table of pxr1.
Do you see the external EIGRP routes sourced from the backbone_r1
router?
What is the administrative distance of the external EIGRP routes?
From your pxr3 router, ping 172.16.10.100 and 172.16.11.100.
Were the pings successful?
Step 5 Telnet to the backbone_r1 router; the password is cisco. Do you see an
entry for your pod’s 192.168.x.0 network?
Does EIGRP perform autosummarization across the network boundary
by default?
Step 6 Exit the Telnet to the backbone_r1 router.
Step 7 At your pxr1 router, disable autosummarization. Which command is used

to achieve this?
Step 8 Telnet to the backbone_r1 router; the password is cisco. Do you see an
entry for each of your pod’s 192.168.x.0 subnets?
From your pxr3 router, ping 172.16.10.100 and 172.16.11.100.
Step 9 At your pxr1 router, create a manual summarization statement to
summarize all the subnets in your pod to a single summarized route of
192.168.x.0/25 (where x = your pod number). What is the command that
you used?
Step 10 Telnet to the backbone_r1 router; the password is cisco. Do you see your
summarized route?
Step 11 Exit the Telnet to the backbone_r1 router.
Step 12 From your pxr3 router, ping 172.16.10.100 and 172.16.11.100.

Step 13 Enter the debug eigrp packets command at one of the routers within
your pod.
How often are the EIGRP hello packets sent out on the serial interfaces?
Note You may want to put the service timestamps debug datetime
configuration command on the router so that debug messages
will be timestamped.
Step 14 Turn off debug on your router.
NVRAM.
Completion Criteria
commands required to configure and to verify EIGRP on your pod routers, and if you were
able to correctly answer the questions in the exercises. At the end of this Configuration
Exercise, all the routers should have full connectivity to each other running EIGRP,
including connectivity to the backbone router. The answers to this Configuration Exercise
can be found later in this chapter.
Configuration Exercise #2: Configuring EIGRP in an

NBMA Environment
Complete the following exercise to configure EIGRP over Frame Relay.
Objectives
In the following Configuration Exercise, you will configure the pxr1 router as the Frame
Relay switch for the pxr2 and pxr3 routers. You also will be required to configure the pxr2
and pxr3 routers’ serial interface (S0) with Frame Relay encapsulation. When you have
verified the connectivity between pxr2 and pxr3, you will configure EIGRP over NBMA
using the main interface. Using the show commands, you will verify EIGRP operations.
In this exercise, your pxr1 router will act as the Frame Relay switch between your pxr2 and
pxr3 routers.
Configuration Exercise #2: Configuring EIGRP in an NBMA Environment 291
Visual Objective
Figure 5-24 provides the topology used for this EIGRP in NBMA Configuration Exercise.
Figure 5-24 Configuring EIGRP in an NBMA Environment Using Main Interface
px r1 - FR Switch
S0 S2
EIGRP 200 EIGRP 200
S0 - DLCI 203 S0 - DLCI 302

192.168.x.129/28 192.168.x.130/28
pxr2 pxr3
loopback loopback
192.168.101.101/24 172.26.1.17/28
172.26.1.33/28
172.26.1.49/28
Command List
list if you need configuration command assistance during the Configuration Exercise.
Command Description
encapsulation frame-relay Enables Frame Relay frames on an interface.
router eigrp 200 Enables EIGRP with an AS number of 200.
network 10.0.0.0 Specifies the interfaces on which to run EIGRP.
show ip eigrp neighbors Displays information about OSPF neighbors.
show frame-relay map Displays a mapping between DLCI and IP
addresses, and shows traffic forwarding
characteristics.
ip bandwidth-percent eigrp Specifies the maximum percentage of the
bandwidth that EIGRP will use.
Setup
Step 1 On your pxr1 router, shut down the Serial 1 and Serial 3 interfaces.
Disable EIGRP 200 on your pxr1 router.
Step 2 On your pxr2 router, shut down the Ethernet 0, Serial 0, and Serial 1
interfaces. Reconfigure your pxr2 Serial 0 IP address to be
192.168.x.129/28.
Step 3 On your pxr3 router, shut down the Ethernet 0 and Serial 0 interfaces.
Reconfigure your pxr3 Serial 0 IP address to be 192.168.x.130/28.
Task 1: Creating a Frame Relay Switch

Step 1 Enable your pxr1 router as the Frame Relay switch.
Which command do you use to activate the Frame Relay switch?
Which command do you use to set your router as a Frame Relay DCE
device?
Which command do you type on pxr1, S0 interface, to perform switching
from pxr2 to pxr3?
Which command do you use on pxr1, S2 interface, to perform switching
from pxr3 to pxr2?
Step 2 Enable Frame Relay encapsulation on the S0 interface of your pxr2 and
pxr3 router.
Verify that your pxr2 and pxr3 router S0 IP addresses are as follows:
— Router pxr2: S0 IP address 192.168.x.129/28
— Router pxr3: S0 IP address 192.168.x.130/28
Enable the Serial 0 interfaces on pxr2 and pxr3. What command is used
to achieve this?
Step 3 From pxr2, ping the pxr3 Serial 0 interface to ensure connectivity.
Task 2: Enabling EIGRP over NBMA Network Using Main Interface

Step 1 Which command would you use to verify that the pxr2 and pxr3 Serial 0
interfaces are running EIGRP in AS 200?
Answers to Configuration Exercise #1: Configuring EIGRP 293
Step 2 On pxr2, type in the command to start advertising the loopback 10

network in EIGRP.
Step 3 On pxr3, ping the pxr2 loopback address to verify connectivity. (Note: it
may take a while for the ping to work)
Step 4 On pxr2, enter the show ip eigrp neighbors command. Do you see your
neighbor pxr3 router?
Step 5 EIGRP sends hello packets to establish a neighbor relationship using the
multicast address of 224.0.0.10. Is your Frame Relay interface enabled to
send broadcast (which includes multicast) traffic?
Step 6 Enter the command to enable EIGRP to use only 20 percent of your
Frame Relay interface bandwidth on your pxr2 router.
NVRAM.
Step 8 Bonus Question: What is the EIGRP interface configuration command to
disable IP split horizon on an NBMA interface? (Use AS number 200.)
Completion Criteria
You have successfully completed this Configuration Exercise if you correctly supplied
the commands required to configure and to verify an EIGRP network over an NBMA
environment using a main interface, and if you were able to correctly answer the questions
in the exercises. At the end of this exercise, your pxr2 and pxr3 routers will be running
EIGRP over Frame Relay.
Answers to Configuration Exercise #1: Configuring

EIGRP
This section provides the answers to the questions in Configuration Exercise #1.
The answers are in bold.
Answers to Setup
Step 1 Shut the pxr1 S3 interface.
p1r1(config)#interface s3
p1r1(config-if)#shutdown
02:50:31: %LINK-5-CHANGED: Interface Serial3, changed state to administratively down
02:50:32: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3, changed state to
down
CHAPTER
6
Configuring Basic Border
Gateway Protocol
When you finish this chapter, you will be able to describe BGP features and operation, BGP
communities and peer groups, BGP synchronization, and how to connect to another
autonomous system (AS) using an alternative to BGP—static routes. You will be able to
explain how BGP policy-based routing functions within an AS, and how BGP peering
functions. You will be able to describe and configure external and internal BGPs. Given a
set of network requirements, you will be able to configure a BGP environment and verify
proper operation (within described guidelines) of your routers.
BGP Overview
This section provides an overview of BGP. Understanding BGP first requires an
understanding of autonomous systems.
Autonomous Systems
One way to categorize routing protocols is by whether they are interior or exterior. Two
types of routing protocols are as follows:
• Interior Gateway Protocol (IGP)—Routing protocol used to exchange routing
information within an autonomous system. The Routing Information Protocol (RIP),
Interior Gateway Routing Protocol (IGRP), Open Shortest Path First (OSPF), and
Enhanced Interior Gateway Routing Protocol (EIGRP) are examples of IGPs.
• Exterior Gateway Protocol (EGP)—Routing protocol used to connect between
autonomous systems. The Border Gateway Protocol (BGP) is an example of an EGP.
This concept is illustrated in Figure 6-1.
312 Chapter 6: Configuring Basic Border Gateway Protocol
Figure 6-1 IGPs Operate Within an Autonomous System, and EGPs Operate Between Autonomous Systems
IGPs: RIP, IGRP, OSPF, EIGRP
EGPs: BGP
Autonomous system 65000 Autonomous system 65500
BGP is an interdomain routing protocol, which is also known as an EGP. All the routing
protocols you have seen so far in this book are interior routing protocols, also known as
IGPs.
BGP version 4, BGP-4, is the latest version of BGP and is defined in Requests For
Comments (RFC) 1771. As noted in this RFC, the classic definition of an autonomous
system is “a set of routers under a single technical administration, using an Interior Gateway
Protocol and common metrics to route packets within the AS, and using an Exterior
Gateway Protocol to route packets to other [autonomous systems].”
Today, autonomous systems may use more than one IGP, with potentially several sets of
metrics. The important characteristic of an AS from the BGP point of view is that the AS
appears to other autonomous systems to have a single coherent interior routing plan and
presents a consistent picture of which destinations are reachable through it. All parts of the
AS must be connected to each other.
The Internet Assigned Numbers Authority (IANA) is the umbrella organization responsible
for allocating autonomous system numbers. Specifically, the American Registry for
Internet Numbers (ARIN) has the jurisdiction for assigning numbers for the Americas, the
Caribbean, and Africa. Reseaux IP Europeennes-Network Information Center (RIPE-NIC)
administers the numbers for Europe, and the Asia Pacific-NIC (AP-NIC) administers the
autonomous system numbers for the Asia-Pacific region.
This autonomous system designator is a 16-bit number, with a range of 1 to 65535. RFC
1930 provides guidelines for the use of AS numbers. A range of AS numbers, 64512
through 65535, is reserved for private use, much like the private Internet Protocol (IP)
addresses. All the examples and exercises in this book use private AS numbers.
BGP Overview 313
NOTE Using the IANA-assigned autonomous system number rather than some other number is
needed only if your organization plans to use an EGP such as BGP to connect to the
Internet.
BGP Use
BGP is used between autonomous systems, as illustrated in Figure 6-2. The main goal of
BGP is to provide an interdomain routing system that guarantees the loop-free exchange of
routing information between autonomous systems. BGP routers exchange information
about paths to destination networks.
Figure 6-2 BGP-4 Is Used Between Autonomous Systems on the Internet
AS
B 65000 C
BGP
AS AS
64520 BGP 65500
A F
BGP
AS
D 65250 E
BGP is a successor to EGP, the Exterior Gateway Protocol. (Note the dual use of the EGP
acronym). The EGP protocol was developed to isolate networks from each other at the early
stages of the Internet.
The use of the term autonomous system in connection with BGP stresses the fact that the
administration of an autonomous system appears to other autonomous systems to have a
single coherent interior routing plan, and presents a consistent picture of those networks
that are reachable through it. There is also a distinction between an ordinary autonomous
system and one that has been configured with BGP for implementing a transit policy; the
latter is called an Internet service provider (ISP), or simply a service provider.
Many RFCs relate to BGP-4, including those listed in Table 6-1.
Table 6-1 RFCs Relating to BGP-4

RFC Number RFC Title
RFC 1771 A Border Gateway Protocol 4 (BGP-4)
RFC 1772 An Application of BGP in the Internet
RFC 1773 Experience with the BGP-4 Protocol
RFC 1774 BGP-4 Protocol Analysis
RFC 1863 A BGP/IDRP (Interdomain Routing Protocol)
Route Server Alternative to a Full-Mesh
Routing
RFC 1930 Guidelines for Creation, Selection, and
Registration of an Autonomous System (AS)
RFC 1965 AS Confederations for BGP
RFC 1966 BGP Route Reflection—An Alternative to Full-
Mesh IBGP
RFC 1997 BGP Communities Attribute
RFC 1998 Application of the BGP Community Attribute
in Multihome Routing
RFC 2042 Registering New BGP Attribute Types
RFC 2283 Multiprotocol Extensions for BGP-4
RFC 2385 Protection of BGP Sessions via TCP MD5
Signature Option
RFC 2439 BGP Route Flap Damping
NOTE For BGP technical tips, see the following URL on Cisco’s web site: www.cisco.com/warp/
customer/459/18.html#I00. (Access to this information requires you to have an account on
Cisco’s web site.)
BGP-4 has many enhancements over earlier protocols. It is used extensively in the Internet
today to connect ISPs and to interconnect enterprises to ISPs.
When to Use BGP 315
Comparison with Other Scalable Routing Protocols

Table 6-2 compares some of the key characteristics of BGP to the other scalable routing
protocols discussed in this book.
Table 6-2 Comparison of Scalable Routing Protocols
Distance
Interior or Vector or Link- Hierarchy
Protocol Exterior State Required Metric
OSPF Interior Link-state Yes Cost
EIGRP Interior Advanced No Composite
distance vector
BGP Exterior Advanced No Path vectors or
distance vector attributes
As shown in Table 6-2, OSPF and EIGRP are interior protocols, whereas BGP is an exterior
protocol.
Chapter 1, “Routing Principles,” discusses the characteristics of distance vector and link-
state routing protocols. OSPF is a link-state protocol, whereas EIGRP is an advanced
distance vector protocol. BGP is also a distance vector protocol, with many enhancements.
Most link-state routing protocols, including OSPF, require a hierarchical design, especially
to support proper address summarization. OSPF enables you to separate a large
internetwork into smaller internetworks that are called areas. EIGRP and BGP do not
require a hierarchical topology.
OSPF uses cost, which on Cisco routers is based on bandwidth, as its metric. EIGRP uses
a composite metric, similar to the IGRP metric. Routers running BGP exchange network
reachability information, called path vectors or attributes, that include a list of the full path
(of BGP AS numbers) that a route should take to reach a destination network.
When to Use BGP

BGP use in an AS is most appropriate when the effects of BGP are well understood and at
least one of the following conditions exist:
• The AS allows packets to transit through it to reach other autonomous systems (for
example, a service provider).
• The AS has multiple connections to other autonomous systems.
• The flow of traffic entering and leaving the AS must be manipulated.
A policy decision that must differentiate between traffic from an AS and its ISP means that
the AS will have to connect to its ISP with BGP (rather than with a static route).
BGP was designed to allow ISPs to communicate and exchange packets. These ISPs have
multiple connections to one another and have agreements to exchange updates. BGP is the
protocol that is used to implement these agreements between two or more autonomous
systems.
If BGP is not properly controlled and filtered, it has the potential to allow an outside AS to
affect your routing decisions. This chapter and the next focus on how BGP operates and
how to configure it properly so that you can prevent this from happening.
How Big Is the Internet?

To give you an idea of the size of tables that a BGP router in an ISP must deal with consider
that a BGP router in the Internet may have the following knowledge:
• A routing table that uses more than 30 megabytes (MB) and has knowledge of more
than 70,000 routes.
• That routing table also has knowledge of more than 6,500 AS numbers.
These numbers represent a snapshot of the size of the Internet. Note that because the
Internet is constantly growing, these numbers are constantly changing (increasing).
When Not to Use BGP

This section discusses when BGP is not appropriate for use in a network and covers the use
of the alternative, static routes.
BGP is not always the appropriate solution to interconnect autonomous systems. For
example, if only one path exists, a default or static route would be appropriate; using BGP
would not accomplish anything except to use router CPU resources and memory. If the
routing policy that will be implemented in an AS is consistent with the policy implemented
in the ISP AS, it is not necessary or even desirable to configure BGP in that AS. The only
time it would be required is when the local policy differs from the ISP policy.
Do not use BGP if you have one or more of the following conditions:
• A single connection to the Internet or another AS
• No concern for routing policy and route selection
• Lack of memory or processor power on routers to handle constant BGP updates
• A limited understanding of route filtering and BGP path selection process
• Low bandwidth between autonomous systems
In these cases, use static routes instead.
The use of static routes to connect to another AS is reviewed in the following section.
When Not to Use BGP 317
Static Routes
Use the ip route prefix mask {address | interface} [distance] global configuration command
to define a static route entry in the IP routing table, as described in Table 6-3.
Table 6-3 ip route Command Description
ip route Command Description
prefix mask IP route prefix and mask for the destination to be
entered into the IP routing table
address IP address of the next-hop router to be used to reach
the destination network
interface The local router outbound interface to be used to
reach the destination network
distance (Optional) Administrative distance
As discussed in Chapter 1, if there is more than one route to a destination, the administrative
distance determines which one will be put in the routing table, with the lower administrative
distance preferred. By default, the administrative distance of a static route specified with
the next-hop address parameter is set to 1. The default administrative distance of a static
route specified with the interface parameter is set to 0.
You can establish a floating static route by using an administrative distance that is larger
than the default administrative distance of the dynamic routing protocol in use in your
network. A floating static route is a statically configured route that can be overridden by
dynamically learned routing information. Thus, a floating static route can be used to create
a path of last resort that is used only when no dynamic information is available.
ip route Command Parameters

The ip route command has two configuration options: specifying the destination by
adjacent router IP address or specifying the destination by the local router interface name.
There are a few differences in these two methods for configuring a static route. As
mentioned, in the case of the IP address parameter, the default administrative distance is 1;
in the case of the interface format, the default administrative distance is 0. The distinction
is that using the next-hop address parameter makes the route look like a standard statically
defined route, but under certain conditions, using the interface parameter treats the link as
if it is locally attached to the router.
You must use the next-hop address in the ip route command if using multiaccess media (for
example, on local-area networks [LANs], Frame Relay, X.25, Integrated Services Digital
Network [ISDN], and so on) so that the router knows exactly where to go to reach the
destination, not just which interface to go out of. (An exception to this is when using a dial-
on-demand interface, such as ISDN, and using a dialer string command on the interface,
so that the interface only knows how to get to one place.) You can use the interface syntax
if the adjacent router interface is part of a serial unnumbered link and therefore has no IP
address (unnumbered interfaces are discussed in Chapter 2, “Extending IP Addresses”).
The interface syntax is also a very quick way to establish connectivity when trying to
recover from routing problems in a network because you do not have to know the IP
addresses on the link that you want to traverse.
Static Route Examples

The sample network in Figure 6-3 illustrates a network running RIP and using a default
static route. The configuration for Router A in Figure 6-3 is provided in Example 6-1.
Figure 6-3 An Example of Using RIP and a Default Static Route
10.1.1.0
RIP S0 ISP
172.16.0.0 A 10.1.1.1 AS 65000
10.1.1.2
Service provider
running BGP
Example 6-1 Configuration of Router A in Figure 6-3

ip route 0.0.0.0 0.0.0.0 S0
!
router rip
network 172.16.0.0
The route 0.0.0.0 is a default route that will be included in the IP routing table of Router A.
If there is no matching route for the destination IP address in the routing table, then the
0.0.0.0 matches the address and causes the packet to be routed out interface serial 0. The
default route will be automatically propagated into the RIP domain.
A Caution About Default Routes

The default route 0.0.0.0 matches only networks that the router knows nothing about. When
using classful routing protocols such as RIP or IGRP, use the ip classless command if you
want it to also match unknown subnets of known networks. Note that ip classless is on by
default in Cisco IOS Release 12.0 and later (it is off by default in earlier releases).
BGP Terminology and Concepts 319
The sample network in Figure 6-4 illustrates a network running OSPF and using a default
static route. The configuration for Router A in Figure 6-4 is provided in Example 6-2.
Figure 6-4 An Example of Using OSPF and a Default Static Route
10.1.1.0
OSPF S0 ISP
172.16.0.0 A 10.1.1.1 AS 65000
10.1.1.2
Service provider
running BGP

ip route 0.0.0.0 0.0.0.0 S0
!
router ospf 111
network 172.16.0.0 0.0.255.255 area 0
default-information originate always
The default-information originate always command in OSPF propagates a default route

into the OSPF routing domain. The configuration in this example has an effect similar to
the RIP example. The always keyword causes the default route to always be advertised,
whether or not the router has a default route. This ensures that the default route will get
advertised into OSPF, even if the path to the default route (in this case, interface serial 0)
goes down.
BGP Terminology and Concepts

BGP has many concepts that become clearer if you understand the terminology. This
section discusses BGP characteristics, concepts of BGP neighbors, internal and external
BGP, policy-based routing, and BGP attributes.
BGP Characteristics
What type of protocol is BGP? Chapter 1 covers the characteristics of distance vector and
link-state routing protocols. BGP is a distance vector protocol, but it has many differences
from the likes of RIP.
NOTE The distance vector for BGP is more a path vector. Many attributes describing a path are
sent with the network information; these attributes are discussed in the “BGP Attributes”
section later in this chapter.
BGP uses the Transmission Control Protocol (TCP) as its transport protocol, which
provides connection-oriented reliable delivery. In this way, BGP assumes that its
communication is reliable and therefore doesn’t have to implement any retransmission or
error-recovery mechanisms. BGP uses TCP port 179. Two routers speaking BGP establish
a TCP connection with one another and exchange messages to open and confirm the
connection parameters. These two routers are called peer routers, or neighbors.
When the connection is made, full routing tables are exchanged. However, because the
connection is reliable, BGP routers need send only changes (incremental updates) after
that. Periodic routing updates are also not required on a reliable link, so triggered updates
are used. BGP sends keepalive messages, similar to the hello messages sent by OSPF and
EIGRP.
BGP routers exchange network reachability information, called path vectors, made up of
path attributes, including a list of the full path (of BGP AS numbers) that a route should
take to reach a destination network. This path information is used in constructing a graph
of autonomous systems that is loop-free. The path is loop-free because a router running
BGP will not accept a routing update that already includes its AS number in the path list;
this would mean that the update has already passed through its AS, and accepting it again
would result in a routing loop. Routing policies can also be applied to the path of BGP AS
numbers to enforce some restrictions on the routing behavior.
BGP is designed to scale to huge internetworks—the Internet, for example.
BGP Inside IP Packets

BGP information is carried inside TCP segments using protocol number 179; these
segments are carried inside IP packets. Figure 6-5 illustrates this concept.
BGP Tables
As shown in Figure 6-6, a router running BGP keeps its own table for storing BGP
information received from and sent to other routers. This table is separate from the IP
routing table in the router. The router can be configured to share information between the
two tables.
Figure 6-5 BGP Is Carried Inside TCP Segments, Which Are Inside IP Packets
179 - BGP
6 - TCP 23 - Telnet
17 - UDP 25 - SMTP
Frame payload
Packet payload C
Frame
IP Protocol R
header TCP Port Segment
header number C
header no. payload
Figure 6-6 A Router Running BGP Keeps a BGP Table, Separate from the IP Routing Table
IGP BGP
routing routing
protocol IP BGP protocol
BGP Peers or Neighbors

Any two routers that have formed a TCP connection to exchange BGP routing
information—in other words, that have formed a BGP connection—are called peers or
neighbors. BGP peers can be either internal to the AS or external to the AS.
When BGP is running between routers within one AS, this is called internal BGP (IBGP).
IBGP is run within an AS to exchange BGP information within the AS so that it can be
passed to other autonomous systems. Routers running IBGP do not have to be directly
connected to each other, as long as they can reach each other (for example, when an IGP is
running within the AS).
When BGP is running between routers in different autonomous systems, this is called
external BGP (EBGP). Routers running EBGP are usually directly connected to each other.
IBGP and EBGP neighbors are illustrated in Figure 6-7.
Figure 6-7 Routers That Have Formed a BGP Connection Are BGP Peers or Neighbors, Either External or
Internal
IBGP neighbors
AS 65500 C
EBGP neighbors
A
AS 65000
Policy-Based Routing
BGP allows policy decisions at the AS level to be enforced. This setting of policies or rules
for routing is known as policy-based routing.
BGP allows policies to be defined for how data will flow through the AS. These policies are
based on the attributes carried in the routing information and configured on the routers.
BGP specifies that a BGP router can advertise to its peers in neighboring autonomous
systems only those routes that it itself uses. This rule reflects the hop-by-hop routing
paradigm generally used throughout the current Internet.
Some policies cannot be supported by the hop-by-hop routing paradigm and thus require
techniques such as source routing to enforce. For example, BGP does not allow one AS to
send traffic to a neighboring AS, intending that the traffic take a different route from that
taken by traffic originating in that neighboring AS. However, BGP can support any policy
conforming to the hop-by-hop routing paradigm. In other words, you cannot influence how
the neighbor AS will route your traffic, but you can influence how your traffic gets to a
neighbor AS.
Because the current Internet uses only the hop-by-hop routing paradigm, and because BGP
can support any policy that conforms to that paradigm, BGP is highly applicable as an inter-
AS routing protocol for the current Internet.
BGP Attributes
Routers send BGP update messages about destination networks. These update messages
include information about BGP metrics, which are called path attributes. Following are
some terms defining how these attributes are implemented:
• An attribute is either well-known or optional, mandatory or discretionary, and
transitive or nontransitive. An attribute may also be partial.
• Not all combinations of these characteristics are valid. In fact, path attributes fall into
four separate categories:
— Well-known, mandatory
— Well-known, discretionary
— Optional, transitive
— Optional, nontransitive
• Only optional transitive attributes may be marked as partial.
These characteristics are described in the following sections.
BGP Update Message Contents

A BGP update message includes a variable-length sequence of path attributes describing
the route. A path attribute is of variable length and consists of three fields, as follows:
• Attribute type, which consists of a 1-byte attribute flags field and a 1-byte attribute
type code field
• Attribute length
• Attribute value
The first bit of the attribute flags field indicates whether the attribute is optional or well-
known. The second bit indicates whether an optional attribute is transitive or nontransitive.
The third bit indicates whether a transitive attribute is partial or complete. The fourth bit
indicates whether the attribute length field is 1 or 2 bytes. The rest of the flag bits are unused
and are set to 0.
Well-Known Attributes
A well-known attribute is one that all BGP implementations must recognize. These
attributes are propagated to BGP neighbors.
A well-known mandatory attribute must appear in the description of a route. A well-known
discretionary attribute does not need to appear in a route description.
Optional Attributes
An optional attribute need not be supported by all BGP implementations; it could be a
private attribute. If it is supported, it may be propagated to BGP neighbors.
An optional transitive attribute that is not implemented in a router should be passed to other
BGP routers untouched. In this case, the attribute is marked as partial.
An optional nontransitive attribute must be deleted by a router that has not implemented the
attribute.
Defined BGP Attributes

The attributes defined by BGP include the following:
• Well-known, mandatory attributes:
— AS-path
— Next-hop
— Origin
• Well-known, discretionary attributes:
— Local preference
— Atomic aggregate
• Optional, transitive attributes:
— Aggregator
— Community
• Optional, nontransitive attribute:
— Multi-exit-discriminator (MED)
In addition, Cisco has defined a weight attribute for BGP.
The AS-path, next-hop, local preference, MED, origin, community, and weight attributes
are expanded upon in the following sections. The other attributes are explained in later
sections in this chapter or in the following chapter.
BGP Attribute Type Codes

Attribute type codes used by Cisco are these:
• Origin, type code 1
• AS-path, type code 2
• Next-hop, type code 3
• MED, type code 4
• Local-preference, type code 5

• Atomic-aggregate, type code 6
• Aggregator, type code 7
• Community, type code 8 (Cisco-defined)
• Originator-ID, type code 9 (Cisco-defined)
• Cluster list, type code 10 (Cisco-defined)
AS-Path Attribute
The AS-path attribute is a well-known mandatory attribute. Whenever a route update passes
through an AS, the AS number is prepended to that update (in other words, it is put at the
beginning of the list). The AS-path attribute is actually the list of AS numbers that a route
has traversed to reach a destination, with the AS number of the AS that originated the route
at the end of the list.
In Figure 6-8, network 192.168.1.0 is advertised by Router A in AS 64520. When that route
traverses AS 65500, Router C prepends its own AS number to it. When 192.168.1.0 reaches
Router B, it has two AS numbers attached to it. From Router B’s perspective, the path to
reach 192.168.1.0 is (65500, 64520).
Figure 6-8 Router C Prepends Its Own AS Number as It Passes Routes from Router A to Router B
AS 64520
192.168.1.0
AS 65000
A 192.168.2.0
Path to 192.168.1.0
AS 65500 is (65500, 64520)
192.168.3.0 C
The same applies for 192.168.2.0 and 192.168.3.0. Router A’s path to 192.168.2.0 will be
(65500, 65000)—traverse AS 65500 and then AS 65000. Router C will have to traverse path
(65000) to reach 192.168.2.0 and path (64520) to reach 192.168.1.0.
The AS-path attribute is used by BGP routers to ensure a loop-free environment. If a BGP
router receives a route in which its own AS is part of the AS-path attribute, it will not accept
the route.
AS numbers are prepended only by routers advertising routes to EBGP neighbors. Routers
advertising routes to IBGP neighbors do not change the AS-path attribute.
Next-Hop Attribute
The BGP next-hop attribute is a well-known mandatory attribute that indicates the next-hop
IP address that is to be used to reach a destination.
For EBGP, the next hop is the IP address of the neighbor that sent the update. In Figure
6-9, Router A will advertise 172.16.0.0 to Router B, with a next hop of 10.10.10.3, and
Router B will advertise 172.20.0.0 to Router A, with a next hop of 10.10.10.1. Therefore,
Router A uses 10.10.10.1 as the next-hop attribute to get to 172.20.0.0, and Router B uses
10.10.10.3 as the next-hop attribute to get to 172.16.0.0.
Figure 6-9 The BGP Next-Hop Attribute
AS 65000
172.20.0.0
172.20.10.1
B 172.20.10.2 C
10.10.10.1
10.10.10.3
172.16.0.0
A
AS 64520
For IBGP, the protocol states that the next hop advertised by EBGP should be carried into
IBGP. Because of that rule, Router B will advertise 172.16.0.0 to its IBGP peer Router C,
with a next hop of 10.10.10.3 (Router A’s address). Therefore, Router C knows that the next
hop to reach 172.16.0.0 is 10.10.10.3, not 172.20.10.1, as you might expect.
It is very important, therefore, that Router C knows how to reach the 10.10.10.0 subnet,
either via an IGP or a static route; otherwise, it will drop packets destined to 172.16.0.0
because it will not be capable of getting to the next-hop address for that network.
When running BGP over a multiaccess network such as Ethernet, a BGP router will use the
appropriate address as the next-hop address (by changing the next-hop attribute), to avoid
inserting additional hops into the network. This feature is sometimes called a third-party
next hop.
For example, in Figure 6-10, assume that Routers B and C in AS 65000 are running an IGP.
Router B can reach network 172.30.0.0 via 10.10.10.2. Router B is running BGP with
Router A. When Router B sends a BGP update to Router A regarding 172.30.0.0, it will use
10.10.10.2 as the next hop, not its own IP address (10.10.10.1). This is because the network
among the three routers is a multiaccess network, and it makes more sense for Router A
to use Router C as a next hop to reach 172.30.0.0 rather than making an extra hop via
Router B.
Figure 6-10 Multiaccess Network—Router A Has 10.10.10.2 as the Next-Hop Attribute to Reach 172.30.0.0
AS 65000
172.30.0.0
172.20.0.0
10.10.10.2
B C
10.10.10.1
EBGP
10.10.10.3
AS 64520
A
172.16.0.0
However, if the common media between routers is a nonbroadcast multiaccess (NBMA)

media, complications may occur.
For example, in Figure 6-11, the last example was changed so that the three routers are
connected by Frame Relay. Router B can still reach network 172.30.0.0 via 10.10.10.2.
When Router B sends a BGP update to Router A regarding 172.30.0.0, it will use
10.10.10.2 as the next hop, not its own IP address (10.10.10.1). A problem will arise if
Router A and Router C do not know how to communicate directly—in other words, if
Routers A and C do not have a map to each other. Router A will not know how to reach the
next-hop address on Router C.
Figure 6-11 Nonbroadcast Multiaccess (NBMA) Media—Router A Has 10.10.10.2 as the Next-Hop Attribute to
Reach 172.30.0.0, But It May Be Unreachable
AS 65000
172.20.0.0 172.30.0.0
10.10.10.2
B C
10.10.10.1
EBGP
FR
10.10.10.3
172.16.0.0
A AS 64520
This behavior can be overridden in Router B by configuring it to advertise itself as the next-
hop address for routes sent to Router A.
Local Preference Attribute

Local preference is a well-known discretionary attribute that provides an indication to
routers in the AS about which path is preferred to exit the AS. A path with a higher local
preference is preferred.
The local preference is an attribute that is configured on a router and exchanged only among
routers within the same AS. The default value for local preference on a Cisco router is 100.
NOTE The term local refers to inside the AS. The local preference attribute is sent only to internal
BGP neighbors; it is not passed to EBGP peers.
For example, in Figure 6-12, AS 64520 is receiving updates about network 172.16.0.0
from two directions. Assume that the local preference on Router A for network 172.16.0.0
is set to 200 and that the local preference on Router B for network 172.16.0.0 is set to 150.
Because the local preference information is exchanged within AS 64520, all traffic in AS
64520 addressed to network 172.16.0.0 will be sent to Router A as an exit point from AS
64520.
Figure 6-12 Local Preference Attribute—Router A Is the Preferred Router to Get to 172.16.0.0
AS 65350
172.16.0.0 AS 65250 AS 65000
AS 64520
A
Local pref = 200
Needs to go to AS 65350
AS 65500
B
Local pref = 150
NOTE Configuring the BGP local preference is discussed in the “Multihoming” section in Chapter
7, “Implementing BGP in Scalable Networks.”
MED Attribute
The Multi-exit-discriminator (MED) attribute, also called the metric, is an optional
nontransitive attribute. The MED was known as the inter-AS attribute in BGP-3.
NOTE In show command outputs the MED attribute is called the metric.
The MED is an indication to external neighbors about the preferred path into an AS. This
is a dynamic way for an AS to try to influence another AS on which way it should choose
to reach a certain route, if there are multiple entry points into an AS.
A lower value of a metric is preferred.
NOTE By using the MED attribute, BGP is the only protocol that can try to affect how routes are
sent into an AS.
Unlike local preference, the MED is exchanged between autonomous systems. The MED
is carried into an AS and is used there, but is not passed on to the next AS. When the same
update is passed on to another AS, the metric will be set back to the default of 0.
By default, a router will compare the MED attribute only for paths from neighbors in the
same AS.
For example, in Figure 6-13, Router B has set the MED attribute to 150, and Router C has
set the MED attribute to 200. When Router A receives updates from Routers B and C, it
picks Router B as the best next hop to get to AS 65500 because 150 is less than 200.
Figure 6-13 MED Attribute—Router B Is the Best Next Hop to Get to AS 65500
AS 65500
172.20.0.0
B C
MED = 150 MED = 200
172.16.0.0
A
AS 65000
NOTE By default, the MED comparison is done only if the neighboring autonomous system is the
same for all routes considered. For the router to compare metrics from neighbors coming
from different autonomous systems, the bgp always-compare-med command must be
configured on the router.
Origin Attribute
The origin is a well-known mandatory attribute that defines the origin of the path
information. The origin attribute can be one of three values, as follows:
• IGP—The route is interior to the originating AS. This normally happens when the
network command (discussed later in this chapter) is used to advertise the route via
BGP. An origin of IGP is indicated with an “i” in the BGP table.
• EGP—The route is learned via the Exterior Gateway Protocol. This is indicated with
an “e” in the BGP table.
• Incomplete—The origin of the route is unknown or is learned via some other means.
This usually occurs when a route is redistributed into BGP (redistribution is discussed
in Chapter 7 and Chapter 8, “Optimizing Routing Update Operation”). An incomplete
origin is indicated with a “?” in the BGP table.
Community Attribute
BGP communities are one way to filter incoming or outgoing routes. BGP communities
allow routers to tag routes with an indicator (the community) and allow other routers to
make decisions based upon that tag. Any BGP router can tag routes in incoming and
outgoing routing updates, or when doing redistribution. Any BGP router can filter routes in
incoming or outgoing updates or can select preferred routes, based on communities (the
tag).
BGP communities are used for destinations (routes) that share some common properties
and therefore share common policies; routers thus act on the community rather than on
individual routes. Communities are not restricted to one network or one AS, and they have
no physical boundaries.
Communities are optional transitive attributes. If a router does not understand the concept
of communities, it will defer to the next router. However, if the router does understand the
concept, then it must be configured to propagate the community; otherwise, communities
are dropped by default.
NOTE BGP community configuration is detailed in Appendix A, “Job Aids and Supplements.”
Weight Attribute (Cisco Only)

The weight attribute is a Cisco-defined attribute used for the path selection process. The
weight is configured locally to a router, on a per-neighbor basis. The weight attribute
provides local routing policy only and is not propagated to any BGP neighbors.
The weight can have a value from 0 to 65535. Paths that the router originates have a weight
of 32768 by default, and other paths have a weight of 0 by default.
Routes with a higher weight are preferred when multiple routes exist to the same
destination.
In Figure 6-14, Routers B and C learn about network 172.20.0.0 from AS 65250 and will
propagate the update to Router A. Router A has two ways to reach 172.20.0.0 and must
decide which way to go. In the example, Router A sets the weight of updates coming from
Router B to 200, and the weight of those coming from Router C to 150. Because the weight
for Router B is higher than the weight for Router C, Router A is forced to use Router B as
a next hop to reach 172.20.0.0.
Figure 6-14 Weight Attribute—Router A Will Use Router B as the Next Hop to Reach 172.20.0.0
AS 65000 AS 65250 AS 65500

172.20.0.0
B D C
A
Weight = 200 Weight = 150
AS 64520
BGP Synchronization
The BGP synchronization rule states that a BGP router should not use or advertise to an
external neighbor a route learned by IBGP, unless that route is local or is learned from the
IGP. If your autonomous system is passing traffic from one AS to another AS, BGP should
not advertise a route before all routers in your AS have learned about the route via IGP.
A router learning a route via IBGP will wait until the IGP has propagated the route within
the AS and then will advertise it to external peers. This is done so that all routers in the AS
are synchronized and will be capable of routing traffic that the AS advertises to other
autonomous systems that it is capable of routing. The BGP synchronization rule also
ensures consistency of information throughout the AS and avoids black holes (for example,
advertising a destination to an external neighbor when all routers within the AS cannot
reach the destination) within the AS.
BGP synchronization is on by default in current IOS releases. Only if all routers in the
transit path in the AS (in other words, in the path between the BGP border routers) are
running BGP is it safe to turn synchronization off. (Indications are that in future IOS
releases, BGP synchronization will be off by default, because most ISPs run BGP on all
routers.)
In the example in Figure 6-15, Routers A, B, C, and D are all running BGP with each other
(full mesh IBGP). There are no matching IGP routers for the BGP routes.
Figure 6-15 A BGP Synchronization Example
All routers in AS 65500 are running BGP; there are no matching IGP is routes
AS 64520
AS 65500
EBGP
C A E
IBGP
AS 65000
172.16.0.0
D B EBGP F
If synchronization is on (the default) in AS 65500 in Figure 6-15, then the following would
happen:
• Router B would advertise the route to 172.16.0.0 to the other routers in AS 65500
using IBGP.
• Router B would use the route to 172.16.0.0 and install it in its routing table.
• Routers A, C, and D would not use or advertise the route to 172.16.0.0 until they
received the matching route via an IGP. Because there is no IGP running, these routers
would never use or advertise the route.
• Router E would not hear about 172.16.0.0. If Router E received traffic destined for
network 172.16.0.0, it would not have a route for that network and would not be
capable of forwarding the traffic.
If synchronization is turned off in AS 65500 in Figure 6-15, then the following would
happen:
• Routers A, C, and D would use and advertise the route to 172.16.0.0 that they receive
via IBGP, and would install it in their routing tables (assuming, of course, that Routers
A, C, and D can reach the next-hop address for 172.16.0.0).
• Router E would hear about 172.16.0.0. Router E would have a route to 172.16.0.0 and
could send traffic destined for that network.
• If Router E sends traffic for 172.16.0.0, Routers A, C, and D would route the packets
correctly to Router B. Router E would send the packets to Router A, and Router A
would forward them to Router C. Router C has learned a route to 172.16.0.0 via IBGP
and therefore would forward the packets to Router D. Router D would forward the
packets to Router B. Router B would forward the packets to Router F for network
172.16.0.0.
BGP Operation
This section describes the operation of the BGP protocol. The following topics are covered:
• BGP message types
• Route selection decision process
• CIDR and aggregate addresses
BGP Message Types

BGP defines the following message types:
• Open
• Keepalive
• Update
• Notification
After a TCP connection is established, the first message sent by each side is an open
message. If the open message is acceptable, a keepalive message confirming the open is
sent back. When the open is confirmed, the BGP connection is established, and update,
keepalive, and notification messages may be exchanged.
BGP peers will initially exchange their full BGP routing tables. From then on, incremental
updates are sent as the routing table changes. Keepalive packets are sent to ensure that the
connection is alive between the BGP peers, and notification packets are sent in response to
errors or special conditions.
An open message includes the following information:
• Version—This 8-bit field indicates the BGP protocol version number of the message.
The current BGP version number is 4.
• My Autonomous System—This 16-bit field indicates the autonomous system
number of the sender.
• Hold time—This 16-bit field indicates the maximum number of seconds that may
elapse between the receipt of successive keepalive or update messages by the sender.
Upon receipt of an open message, the router calculates the value of the hold timer to
use by using the smaller of its configured hold time and the hold time received in the
open message.
BGP Operation 335
• BGP identifier (router ID)—This 32-bit field indicates the BGP identifier of the
sender. The BGP identifier is an IP address assigned to that router and is determined
on startup. The BGP router ID is chosen the same way that the OSPF router ID is
chosen—it is the highest active IP address on the router, unless a loopback interface
with an IP address exists, in which case it is the highest such loopback IP address.
• Optional parameters—A length field indicates the total length of the optional
parameters field in octets. The optional parameters field may contain a list of optional
parameters (currently, only authentication is defined).
BGP does not use any transport protocol-based keepalive mechanism to determine whether
peers are reachable. Instead, keepalive messages are exchanged between peers often
enough to not cause the hold timer to expire. If the negotiated hold time interval is zero,
then periodic keepalive messages will not be sent.
An update message has information on one path only; multiple paths require multiple
messages. All the attributes in the message refer to that path, and the networks are those that
can be reached through it. An update message may include the following fields:
• Withdrawn routes—A list of IP address prefixes for routes that are being withdrawn
from service, if any.
• Path attributes—These path attributes are the AS-path, origin, local preference, and
the like, discussed earlier in this chapter in the section “BGP Attributes.” Each path
attribute includes the attribute type, attribute length, and attribute value. The attribute
type consists of the attribute flags, followed by the attribute type code.
• Network layer reachability information—This field contains a list of IP address
prefixes that can be reached by this path.
A notification message is sent when an error condition is detected. The BGP connection is
closed immediately after this is sent. Notification messages include an error code, an error
subcode, and data related to the error.
BGP Neighbor States

The BGP protocol is a state machine, which takes a router through the following states with
its neighbors:
• Idle
• Connect
• Active
• OpenSent
• OpenConfirm
• Established
Only when the connection is in the Established state are update, keepalive, and notification
messages exchanged.
NOTE Keepalive messages consist of only a message header and have a length of 19 bytes; they
are sent every 60 seconds by default. Other messages may be between 19 bytes and 4096
bytes long. The default hold time is 180 seconds.
Route Selection Decision Process

After BGP receives updates about different destinations from different autonomous
systems, the protocol decides which path to choose to reach a specific destination. BGP
chooses only a single path to reach a specific destination.
The decision process is based on the attributes discussed earlier in this chapter in the section
“BGP Attributes.” When faced with multiple routes to the same destination, BGP chooses
the best route for routing traffic toward the destination. The following process summarizes
how BGP on a Cisco router chooses the best route:
Step 1 If the path is internal, synchronization is on, and the route is not
synchronized (in other words, the route is not in the IGP routing table),
do not consider it.
Step 2 If the next-hop address of a route is not reachable, do not consider it.
Step 3 Prefer the route with the highest weight. (Recall that the weight is Cisco-
proprietary and is local to the router only.)
Step 4 If multiple routes have the same weight, prefer the route with the highest
local preference. (Recall that the local preference is used within an AS.)
Step 5 If multiple routes have the same local preference, prefer the route that
was originated by the local router.
Step 6 If multiple routes have the same local preference, or if no route was
originated by the local router, prefer the route with the shortest AS-path.
Step 7 If the AS-path length is the same, prefer the lowest origin code (IGP <
EGP < incomplete).
Step 8 If all origin codes are the same, prefer the path with the lowest MED.
(Recall that the MED is sent from other autonomous systems.)
The MED comparison is done only if the neighboring autonomous
system is the same for all routes considered, unless the bgp always-
compare-med command is enabled.
BGP Operation 337
Note The most recent Internet Engineering Task Force (IETF)

decision regarding BGP MED assigns a value of infinity to a
missing MED, making a route lacking the MED variable the
least preferred. The default behavior of BGP routers running
Cisco IOS software is to treat routes without the MED
attribute as having a MED of 0, making a route lacking the
MED variable the most preferred. To configure the router to
conform to the IETF standard, use the bgp bestpath missing-
as-worst command.
Step 9 If the routes have the same MED, prefer external paths (EBGP) over
internal paths (IBGP).
Step 10 If synchronization is disabled and only internal paths remain, prefer the
path through the closest IGP neighbor. This means that the router will
prefer the shortest internal path within the AS to reach the destination
(the shortest path to the BGP next hop).
Step 11 For EBGP paths, select the oldest route, to minimize the effect of routes
going up and down (flapping).
Step 12 Prefer the route with the lowest neighbor BGP router ID value.
Step 13 If the BGP router IDs are the same, prefer the route with the lowest
neighbor IP address.
The path is put in the routing table and is propagated to the router’s BGP neighbors.
NOTE The route selection decision process summarized here does not cover all cases, but it is
sufficient for a basic understanding of how BGP selects routes.
Step 11 in the decision process, to prefer the oldest route for EBGP paths, is not found in
any of the BGP documentation; it came from Cisco’s Technical Assistance Center (TAC).
You will be able to see this if you perform the multihomed BGP Configuration Exercise in
the next chapter with more than one pod. You will see that the backbone routers chose the
best path based on whichever pod came up first; in other words, they will choose the oldest
route because all other parameters will be equal.
Multiple Path Selection

BGP chooses only a single path for each destination.
The maximum-paths router configuration command for BGP works if your router has two
parallel paths to two different routers in same remote AS. For example, consider three
routers: p1r1 is in AS 65201, and both p1r2 and p1r3 are in AS 65301. p1r1 is running
EBGP to p1r2 and p1r3. p1r2 and p1r3 are advertising network 10.0.0.0. Without the
maximum-paths command under the router bgp 65201 command on p1r1, there will not
be two paths in p1r1’s routing table. After the maximum-paths 2 command is added to the
p1r1 bgp configuration, both paths appear in the routing table, as shown in the output in
Example 6-3. However, as also shown in Example 6-3, there is still only one path selected
as the best in the BGP table (as indicated by the “>” symbol).
Example 6-3 Output from Testing of the maximum-paths Command for BGP
p1r1#show ip route bgp
B 10.0.0.0/8 [20/0] via 192.168.1.18, 00:00:41
[20/0] via 192.168.1.50, 00:00:41
p1r1#show ip bgp
BGP table version is 3, local router ID is 192.168.1.49
Status codes: s suppressed, d damped, h history, * valid, > best, i ->internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0 192.168.1.18 0 0 65301 i
* 192.168.1.50 0 0 65301 i
CIDR and Aggregate Addresses

As discussed in Chapter 2, classless interdomain routing (CIDR) is a mechanism developed
to help alleviate the problem of exhaustion of IP addresses and the growth of routing tables.
The idea behind CIDR is that blocks of multiple Class C addresses can be combined, or
aggregated, to create a larger classless set of IP addresses. These multiple Class C addresses
can then be summarized in routing tables, resulting in fewer route advertisements.
Earlier versions of BGP did not support CIDR; BGP-4 does. BGP-4 support includes the
following:
• The BGP update message includes both the prefix and the prefix length. Previous
versions included only the prefix; the length was assumed from the address class.
• Addresses can be aggregated when advertised by a BGP router.
• The AS-path attribute can include a combined unordered list of all autonomous
systems that all the aggregated routes have passed through. This combined list should
be considered to ensure that the route is loop-free.
BGP Operation 339
As an example, in Figure 6-16, Router C is advertising network 192.168.2.0/24, and Router

D is advertising network 192.168.1.0/24. Router A could pass those advertisements to
Router B; however, Router A could reduce the size of the routing tables by aggregating the
two routes into one, for example, 192.168.0.0/16.
Figure 6-16 An Example of Using CIDR with BGP
AS 65000 AS 65500 AS 65250

192.168.1.0/24 192.168.2.0/24
B D C
192.168.0.0/16
AS 64520
Two BGP attributes are related to aggregate addressing. The well-known discretionary
attribute atomic aggregate informs the neighbor AS that the originating router has
aggregated the routes. The optional transitive attribute aggregator specifies the BGP router
ID and AS number of the router that performed the route aggregation.
By default, the aggregate route will be advertised as coming from the autonomous system
that did the aggregation and will have the atomic aggregate attribute set to show that
information might be missing. The AS numbers from the nonaggregated routes are not
listed. The router can be configured to include the unordered list of all autonomous systems
contained in all paths that are being summarized.
NOTE Indications are that aggregate addresses are not used in the Internet as much as they could
be because autonomous systems that are multihomed (connected to more than one ISP)
want to make sure that their routes are advertised, without being aggregated into a
summarized route.
In Figure 6-16, by default, the aggregated route 192.168.0.0/16 would have an AS-path
attribute of (64520). If Router A was configured to include the combined unordered list, it
would include the set of {65250, 65500} as well as (64520) in the AS-path attribute.
NOTE In the example in Figure 6-16, the aggregate route that Router A is sending covers more
than the two routes from Routers C and D. The example assumes that Router A also has
jurisdiction over all the other routes covered by this aggregate route.
Configuring BGP
This section covers the commands used to configure some of the BGP features discussed in
this chapter. First, the concept of peer groups is described because peer groups appear in
many of the configuration commands.
Peer Groups
In BGP, many neighbors are often configured with the same update policies (for example,
they have the same filtering applied). On a Cisco router, neighbors with the same update
policies can be grouped into peer groups to simplify configuration and, more importantly,
to make updating more efficient. When you have many peers, this approach is highly
recommended.
A BGP peer group is a group of BGP neighbors of the router being configured that all have
the same update policies. Instead of separately defining the same policies for each neighbor,
a peer group can be defined with these policies assigned to the peer group. Individual
neighbors are then made members of the peer group. The policies of the peer group are
similar to a template; the template is then applied to the individual members of the peer
group.
Members of the peer group inherit all the configuration options of the peer group. The
router can also be configured to override these options for some members of the peer group
if these options do not affect outbound updates; in other words, only options that affect the
inbound updates can be overridden.
NOTE All EBGP neighbors in a peer group must be reachable over the same interface. This is
because the next-hop attribute would be different for EBGP neighbors accessible on
different interfaces. You can get around this restriction by configuring a loopback source
address for EBGP peers.
Peer groups are useful to simplify configurations when many neighbors have the same
policy. They are also more efficient because updates are generated only once per peer group
rather than once for each neighbor.
Configuring BGP 341
The peer group name is local only to the router it is configured on; it is not passed to any
other router.
NOTE BGP peer group configuration is detailed in Appendix A.
Basic BGP Commands

Basic BGP commands are covered in this section.
NOTE The syntax of basic BGP configuration commands is similar to the syntax of commands
used for configuring internal routing protocols. However, there are significant differences
in the way that an external protocol functions.
Use the router bgp autonomous-system global configuration command to activate the BGP
protocol and identify the local autonomous system. In the command, autonomous-system
identifies the local autonomous system.
Use the neighbor {ip-address | peer-group-name} remote-as autonomous-system router
configuration command to identify a peer router with which the local router will establish
a session, as described in Table 6-4.
Table 6-4 neighbor remote-as Command Description
neighbor remote-as Command Description
ip-address Identifies the peer router.
peer-group-name Gives the name of a BGP peer group.
autonomous-system Identifies the autonomous system of the peer
router.
The value placed in the autonomous system field of the neighbor remote-as command
determines whether the communication with the neighbor is an EBGP or an IBGP session.
If the autonomous system field configured in the router bgp command is identical to the
field in the neighbor remote-as command, then BGP will initiate an internal session. If the
field values are different, then BGP will initiate an external session.
Other BGP Commands

To disable an existing BGP neighbor or neighbor peer group, use the neighbor {ip-address
| peer-group-name} shutdown router configuration command. To enable a previously
existing neighbor or neighbor peer group that had been disabled using the neighbor
shutdown command, use the no neighbor {ip-address | peer-group-name} shutdown
router configuration command.
EBGP assumes a Time To Live (TTL) of 1. The neighbor {ip-address | peer-group-name}
ebgp-multihop [ttl] command must be used if the EBGP neighbors are not directly
connected. Whenever the EBGP neighbors are more than one hop away (which includes
connections to loopback interfaces), the neighbor ebgp-multihop command will by
default set the TTL to 255. This will allow BGP to create an inter-AS connection. Note that
IBGP already assumes a TTL of 255.
Using a loopback interface to define neighbors is commonly used with IBGP (rather than
EBGP). Normally the loopback interface is used to make sure that the IP address of the
neighbor stays up and is independent of hardware that might be flaky. If the IP address of a
loopback interface is used in the neighbor command, some extra configuration must be
done on the neighbor router. The neighbor router needs to tell BGP that it is using a
loopback interface rather than a physical interface to initiate the BGP neighbor TCP
connection. Use the neighbor {ip-address | peer-group-name} update-source loopback
interface-number command to cause the router to use its loopback interface for BGP
connections to its neighbors.
If you have multiple physical connections between EBGP neighbors, using a loopback
interface and static routes to the loopback interface allows you to load balance the traffic
between the multiple connections.
Use the network network-number [mask network-mask] router configuration command to

permit BGP to advertise a network if it is present in the IP routing table, as described in
Table 6-5.
Table 6-5 network Command Description
Network Command Description
network-number Identifies an IP network to be advertised by
BGP.
network-mask (Optional) Identifies the subnet mask to be
advertised by BGP. If the network mask is not
specified, the default mask will be the classful
mask.
The network command controls which networks are originated by this router. This is a
different concept from what you are used to when configuring IGPs. The network
Configuring BGP 343
command does not start up BGP on certain interfaces; rather, it indicates to BGP which
networks it should originate from this router. The mask parameter is used because BGP-4
can handle subnetting and supernetting. The list of network commands must include all
networks in your AS that you want to advertise, not just those locally connected to your
router.
The network command allows classless prefixes; the router can advertise individual
subnets, networks, or supernets. Note that the prefix must exactly match (address and mask)
an entry in the IP routing table. A static route to null 0 may be used to create a supernet
entry in the IP routing table; this is discussed in the “Redistribution with IGPs” section in
the next chapter.
Prior to Cisco IOS Release 12.0, there was a limit of 200 network commands per BGP
router; this limit has now been removed. The router’s resources, such as the configured
nonvolatile random-access memory (NVRAM) or random-access memory (RAM),
determine the maximum number of network commands that you can now use.
Basic BGP Commands Example

Figure 6-17 shows an example BGP network. Example 6-4 provides the configuration of
Router A in Figure 6-17, and Example 6-5 provides the configuration of Router B in
Figure 6-17.
Figure 6-17 An Example BGP Network
AS 64520 AS 65000
172.16.0.0 10.1.1.1
A 172.17.0.0
10.1.1.2 B

RtrA(config)#router bgp 64520
RtrA(config-router)# neighbor 10.1.1.1 remote-as 65000
RtrA(config-router)# network 172.16.0.0
Example 6-5 Configuration of Router B in Figure 6-17

RtrB(config)#router bgp 65000
RtrB(config-router)# neighbor 10.1.1.2 remote-as 64520
RtrB(config-router)# network 172.17.0.0
In this example, Routers A and B define each other as BGP neighbors and will start an
EBGP session. Router A will advertise the network 172.16.0.0/16, while Router B will
advertise the network 172.17.0.0/16.
Changing the Next-Hop Attribute

It is sometimes necessary—for example, in an NBMA environment—to override the
default behavior of a router and force it to advertise itself as the next-hop address for routes
sent to a neighbor.
The neighbor {ip-address | peer-group-name} next-hop-self router configuration
command is used to force BGP to use its own IP address as the next hop rather than letting
the protocol choose the next-hop address to use, as described in Table 6-6.
Table 6-6 neighbor next-hop-self Command Description
neighbor next-hop-self Command Description
ip-address Identifies the peer router to which
advertisements will be sent, with this router
identified as the next hop.
peer-group-name Gives the name of a BGP peer group to which
advertisements wil be sent, wtih this router
identified as the next hop.
NOTE This command is useful in NBMA environments, but it should be used only where there is
a single path to the peer AS, or else a suboptimal path to the AS may be chosen.
Disabling BGP Synchronization

In some cases you do not need BGP synchronization. If you will not be passing traffic from
a different autonomous system through your AS (in other words, if your AS is not a transit
AS), or if all routers in the BGP transit path in your AS will be running BGP, you can
disable synchronization. Disabling this feature can allow you to carry fewer routes in your
IGP and allow BGP to converge more quickly. Use synchronization if some routers in the
BGP transit path in the AS are not running BGP.
Synchronization is on by default; use the no synchronization router configuration
command to disable it. This command will allow a router to use and advertise to an external
BGP neighbor routes learned by IBGP before learning them in an IGP.
Creating a Summary Address in the BGP Table

The aggregate-address ip-address mask [summary-only] [as-set] router configuration
command is used to create an aggregate, or summary, entry in the BGP table, as described
in Table 6-7.
Configuring BGP 345
Table 6-7 aggregate-address Command Description

aggregate-address Command Description
ip-address Gives the aggregate address to be created.
mask Gives the mask of the aggregate address to be
created.
summary-only (Optional) Causes the router to advertise only
the aggregated route; the default is to advertise
both the aggregate and the more specific routes.
as-set (Optional) Generates AS path information with
the aggregate route to include all the AS
numbers listed in all the paths of the more
specific routes. The default for the aggregate
route is to list only the AS number of the router
that generated the aggregate route.
NOTE The aggregate-address command applies to networks already in the BGP table. This is
different from the requirement for advertising summaries with the BGP network
command. In that case, the network must exist in the IP routing table; in this case, the
networks being aggregated must exist in the BGP table.
When you use this command without the as-set keyword, the aggregate route will be
advertised as coming from your autonomous system and will have the atomic aggregate
attribute set to show that information might be missing. The atomic aggregate attribute is
set unless you specify the as-set keyword.
aggregate-address Command Keywords

Without the summary-only keyword, the router will still advertise the individual networks.
This can be useful for redundant ISP links. For example, if one ISP is advertising only
summaries, while the other is advertising a summary plus the more specific routes, then the
more specific routes will be followed. However, if the ISP advertising the more specific
routes becomes inaccessible, then the other ISP advertising only the summary will be
followed.
If you use only the summary-only keyword on the aggregate-address command, the
summary route is advertised and the path indicates only the AS that summarized (all other
path information is missing). If you use only the as-set keyword on the aggregate-address
command, the set of AS numbers is included in the path information (and the command
with the summary-only keyword is deleted if it existed). However, you may use both
keywords on one command; this will result in the summary address only being sent and all
the autonomous systems being listed in the path information.
Resetting BGP
Use the clear ip bgp {* | address} [soft [in | out]] privileged EXEC command to remove
entries from the BGP table and reset BGP sessions, as described in Table 6-8. Use this
command after every configuration change to ensure that the change is activated and that
peer routers are informed.
Table 6-8 clear ip bgp Command Description
clear ip bgp Command Description
* Resets all current BGP sessions.
address Identifies the address of a specific neighbor for
which the BGP sessions will be reset.
soft (Optional) Does a soft reconfiguration, as
explained in the following paragraph.
in | out (Optional) Triggers inbound or outbound soft
reconfiguration. If the in or out option is not
specified, both inbound and outbound soft
reconfigurations are triggered.
If you specify BGP soft reconfiguration by including the soft keyword, the BGP sessions
are not reset and the router sends all routing updates again. To generate new inbound
updates without resetting the BGP session, the local BGP speaker would have to store all
received updates without modification, regardless of whether it is accepted by the inbound
policy, using the neighbor soft-reconfiguration router configuration command. (After
configuring the neighbor soft-reconfiguration command for the first time, clear all current
BGP sessions so that all updates will be resent by all neighbors and can then be stored in
the local router.) This process is memory-intensive and should be avoided if possible.
Outbound BGP soft configuration does not have any memory overhead. You can trigger an
outbound reconfiguration on the other side of the BGP session to make the new inbound
policy take effect.
WARNING Clearing the BGP table and resetting BGP sessions will disrupt routing, so do not use this
command unless you have to.
Configuring BGP 347
NOTE The Cisco IOS documentation says that the clear ip bgp command can have {* | address |
peer-group-name} parameters. However, the command for peer groups is actually clear ip
bgp peer-group peer-group-name.
Another BGP Example

Figure 6-18 shows an example BGP network. Example 6-6 provides the configuration of
Router B in Figure 6-18.
Figure 6-18 A Sample Network for Using BGP Configuration Commands
AS 65000
172.16.10.0 172.16.20.0
192.168.1.49 192.168.1.50
B C
10.1.1.1
172.16.0.0/16
10.1.1.2 192.168.2.0
A
AS 64520
NOTE There is no IGP running in this example.
Example 6-6 Configuration of Router B in Figure 6-18

RtrB(config)#router bgp 65000
RtrB(config-router)# network 172.16.10.0 mask 255.255.255.0
RtrB(config-router)# network 192.168.1.0 mask 255.255.255.0
RtrB(config-router)# no synchronization
RtrB(config-router)# neighbor 192.168.1.50 next-hop-self
RtrB(config-router)# aggregate-address 172.16.0.0 255.255.0.0 summary-only
In Example 6-6, the first two commands under the router bgp 65000 command establish
that Router B has two BGP neighbors: Router A in AS 64520 and Router C in AS 65000.
The next two commands allow Router B to advertise networks 172.16.10.0 and 192.168.1.0
to its BGP neighbors.
Assuming that Router C is advertising 172.16.20.0 in BGP, Router B would receive that
route via IBGP but would not pass it to Router A until the no synchronization command
is added to both Routers B and C because there is no IGP running in this example. This
command can be used here because all the routers in the AS are running BGP. The clear ip
bgp * command would be required on Routers B and C to reset the BGP sessions after the
synchronization has been turned off.
By default, Router B will pass the BGP advertisement from Router A about network
192.168.2.0 to Router C, with the next-hop address left as 10.1.1.2. However, Router C
does not know how to get to 10.1.1.2, so it will not install the route. The neighbor
192.168.1.50 next-hop-self command will force Router B to send advertisements to Router
C with its own (Router B) address as the next-hop address. Router C will then be capable
of reaching 192.168.2.0.
By default, Router A would learn about both subnets 172.16.10.0 and 172.16.20.0.
However, when the aggregate-address 172.16.0.0 255.255.0.0 summary-only command
is added to Router B, Router B will summarize the subnets and send only the 172.16.0.0/
16 route to Router A.
Verifying BGP
Verifying BGP operation can be accomplished using the following show EXEC
commands:
• show ip bgp—Displays entries in the BGP routing table. Specify a network number
to get more specific information about a particular network.
• show ip bgp summary—Displays the status on all BGP connections.
• show ip bgp neighbors—Displays information about the TCP and BGP connections
to neighbors.
Other BGP show commands can be found in the BGP documentation on Cisco’s web site
(www.cisco.com) or on the Documentation CD-ROM. Use the show ip bgp ? command on
a router to see other BGP show commands.
Debug commands display events as they are happening on the router. For BGP, the debug
ip bgp privileged EXEC command has the following options:
• dampening—BGP dampening
• events—BGP events
Verifying BGP 349
• keepalives—BGP keepalives
• updates—BGP updates
show ip bgp Command Output Example

The example output of the show ip bgp command shown in Example 6-7 is taken from
Router A in the BGP example in Figure 6-18.
Example 6-7 show ip bgp Command Output from Router A in Figure 6-18
RTRA#show ip bgp
Status codes:s suppressed,d damped,h history,* valid,> best,i - internal

*> 172.16.0.0 10.1.1.1 0 65000 i
*> 192.168.1.0 10.1.1.1 0 0 65000 i
*> 192.168.2.0 0.0.0.0 0 32768 i
The status codes are shown at the beginning of each line of output, and the origin codes are
shown at the end of each line of output. From the example output, you can see that Router
A learned about two networks from 10.1.1.1: 172.16.0.0 and 192.168.1.0. The path Router
A will use to get to these networks is via AS 65000, and the routes have origin codes of IGP
(shown as “i” in the output). Note the aggregated route to 172.16.0.0 in this output.
An example of the additional information displayed when a network is specified in the
show ip bgp command is provided in Example 6-8. (Note that this example is not from the
network in Figure 6-18.)
Example 6-8 show ip bgp network Command Output
p1r1#show ip bgp 172.31.20.0/24
BGP routing table entry for 172.31.20.0/24, version 211
Paths: (1 available, best #1)
Advertised to non peer-group peers:
192.168.1.18 192.168.1.34 192.168.1.50
65200 65106 65201
10.1.1.100 from 10.1.1.100 (172.16.11.100)
Origin IGP, localpref 100, valid, external, best, ref 2
p1r1#exit
show ip bgp summary Command Output Example

The example output of the show ip bgp summary command shown in Example 6-9 is
taken from Router A in the BGP example in Figure 6-18.
Example 6-9 show ip bgp summary Output from Router A in Figure 6-18
RTRA#show ip bgp summary
BGP table version is 5, main routing table version 5
3 network entries and 3 paths using 363 bytes of memory
3 BGP path attribute entries using 372 bytes of memory
BGP activity 3/0 prefixes, 3/0 paths
0 prefixes revised.
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.1.1.1 4 65000 14 13 5 0 0 00:08:03 2
In this example output, you can see that Router A has one neighbor, 10.1.1.1. It speaks
BGP-4 with that neighbor, which is in AS 65000. Router A has received 14 messages from
and has sent 13 messages to 10.1.1.1. The TblVer is the last version of the BGP database
that was sent to that neighbor. There are no messages in either the input or the output queue.
The BGP session has been established for 8 minutes and 3 seconds. The State field is blank,
indicating that the state of the neighbor router is Established. Router A has received two
prefixes from neighbor 10.1.1.1.
NOTE If the state field of the show ip bgp summary command indicates Active, the router is
attempting to create a TCP connection to that neighbor.
show ip bgp neighbors Command Output Example

The example output of the show ip bgp neighbors command shown in Example 6-10 is
taken from Router A in the BGP example in Figure 6-18.
Example 6-10 show ip bgp neighbors Output from Router A in Figure 6-18
RTRA#show ip bgp neighbors
BGP neighbor is 10.1.1.1, remote AS 65000, external link
Index 1, Offset 0, Mask 0x2
BGP version 4, remote router ID 172.16.10.1
BGP state = Established, table version = 5, up for 00:10:47
Last read 00:00:48, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 16 messages, 0 notifications, 0 in queue
Sent 15 messages, 1 notifications, 0 in queue
Prefix advertised 1, suppressed 0, withdrawn 0
Connections established 1; dropped 0
Last reset 00:16:35, due to Peer closed the session
Verifying BGP 351
Example 6-10 show ip bgp neighbors Output from Router A in Figure 6-18 (Continued)
2 accepted prefixes consume 64 bytes
0 history paths consume 0 bytes
--More--
This command is used to display information about the BGP connections to neighbors. In
the example output, the BGP state is Established, which means that the neighbors have
established a TCP connection and that the two peers have agreed to speak BGP with each
other.
NOTE Refer to the Command Reference documentation on the Cisco Documentation CD-ROM
or in the technical documents section on Cisco’s web site (www.cisco.com) for a complete
description of the fields in the output of this command.
debug ip bgp updates Command Output Example

The example output of the debug ip bgp updates command shown in Example 6-11 is
taken from Router A in the BGP example in Figure 6-18. The clear ip bgp * command was
used to force Router A to reset all its BGP connections.
Example 6-11 debug ip bgp updates Output from Router A in Figure 6-18
RTRA#debug ip bgp updates
BGP updates debugging is on
RTRA#clear ip bgp *
3w5d: BGP: 10.1.1.1 computing updates, neighbor version 0, table
version 1, starting at 0.0.0.0
3w5d: BGP: 10.1.1.1 update run completed, ran for 0ms, neighbor
version 0, start version 1, throttled to 1, check point net 0.0.0.0
3w5d: BGP: 10.1.1.1 rcv UPDATE w/ attr: nexthop 10.1.1.1, origin i,
aggregated by 65000 172.16.10.1, path 65000
3w5d: BGP: 10.1.1.1 rcv UPDATE about 172.16.0.0/16
3w5d: BGP: nettable_walker 172.16.0.0/16 calling revise_route
3w5d: BGP: revise route installing 172.16.0.0/16 -> 10.1.1.1
3w5d: BGP: 10.1.1.1 rcv UPDATE w/ attr: nexthop 10.1.1.1, origin i,
metric 0, path 65000
3w5d: BGP: 10.1.1.1 rcv UPDATE about 192.168.1.0/24
3w5d: BGP: nettable_walker 192.168.1.0/24 calling revise_route
3w5d: BGP: revise route installing 192.168.1.0/24 -> 10.1.1.1
3w5d: BGP: 10.1.1.1 computing updates, neighbor version 1, table version 3,
starting at 0.0.0.0
3w5d: BGP: 10.1.1.1 update run completed, ran for 0ms, neighbor version 1,
start version 3, throttled to 3, check point net 0.0.0.0
3w5d: BGP: nettable_walker 192.168.2.0/24 route sourced locally
3w5d: BGP: 10.1.1.1 computing updates, neighbor version 3, table version 4,
starting at 0.0.0.0
continues
Example 6-11 debug ip bgp updates Output from Router A in Figure 6-18 (Continued)
3w5d: BGP: 10.1.1.1 send UPDATE 192.168.2.0/24, next 10.1.1.2, metric 0,
path 64520
3w5d: BGP: 10.1.1.1 1 updates enqueued (average=52, maximum=52)
3w5d: BGP: 10.1.1.1 update run completed, ran for 0ms, neighbor version 3,
start version 4, throttled to 4, check point net 0.0.0.0
The output in Example 6-11 shows update messages being received from and being sent to
neighbor 10.1.1.1.
NOTE Debugging uses router resources and therefore should be turned on only when necessary.
Summary
In this chapter, you learned the basics of the BGP protocol.
BGP is an exterior routing protocol used to route between autonomous systems. BGP-4 is
the latest version of BGP and is used throughout the Internet. BGP is an advanced distance
vector protocol that uses TCP as its transport protocol. The BGP metrics are path attributes
that indicate a variety of information about a route.
The BGP route selection decision process is to consider only (synchronized) routes with no
AS loops and a valid next hop, and then to prefer the following characteristics:
• Highest weight (local to router)
• Highest local preference (global within AS)
• Route originated by the local router
• Shortest AS-path
• Lowest origin code (IGP < EGP < incomplete)
• Lowest MED (from other AS)
• EBGP path over IBGP path
• Path through the closest IGP neighbor
• Oldest route for EBGP paths
• Path with the lowest neighbor BGP router ID
• Path with lowest neighbor IP address
The next chapter discusses problems that can result when scaling IBGP and gives various
solutions to those problems.
Configuration Exercise: Configuring BGP 353
Configuration Exercise: Configuring BGP
configuration exercises are provided at the end of the exercise.
In this exercise, you will configure IBGP within your pod and EBGP to the backbone_r1
router.
Objectives
In the following configuration exercise, you will do the following:
• Disable EIGRP on all the routers in your pod.
• Configure EBGP between your pxr1 router and the backbone_r1 router. (The
backbone_r1 router should be configured before you start the exercise; refer to
Appendix H for the backbone_r1 configuration.)
• Configure IBGP in your pod (full mesh between pxr1, pxr2, and pxr3).
• During the configuration of IBGP, you will configure:
— Next-hop-self
— Disabling synchronization
— Route aggregation
• Verify connectivity within your pod and to the backbone_r1 router.
• Use show and debug commands to verify BGP operations.
Visual Objective
Figure 6-19 illustrates the topology used in the network.
Figure 6-19 Configuration Exercise Topology
AS 65200
172.16.10.100/24 EBGP
172.16.11.100/24
backbone_r1 IBGP
loopback
S1/0 S2/3
10.1.1.100/24 10.12.12.100/24
Pods 2 to 11
. . . . . . . . . . .
10.1.1.1/24 10.12.12.12/24
S3 S3
S0 p1r1 S0 p12r1
192.168.1.17/28 S2 192.168.12.17/28 S2
S1 192.168.1.49/28 S1 192.168.12.49/28
192.168.1.33/28 192.168.12.33/28
Pod 1 Pod 12
192.168.1.18/28 192.168.1.50/28 192.168.12.18/28 192.168.12.50/28

S0 S1192.168.1.34/28 S0 S0 S1 S0
192.168.12.34/28
p1r2 E0 E0 p1r3 p12r2 E0 E0 p12r3

192.168.1.65/28 192.168.1.66/28 192.168.12.65/28 192.168.12.66/28
AS 65101 AS 65112
Command List
In this exercise, you will use commands in Table 6-9, listed in logical order. Refer to this
list if you need configuration command assistance during the exercise.
Table 6-9 Configuration Exercise Command List
Command Description
no router eigrp 200 Disables EIGRP.
router bgp 6510x Enables BGP with an AS number of 6510x.
network 192.168.x.0 [mask 255.255.255.0] Specifies the network to be advertised.
Configuration Exercise: Configuring BGP 355
Table 6-9 Configuration Exercise Command List (Continued)

Command Description
neighbor 192.168.x.18 remote-as 6510x Establishes a BGP neighbor relationship.
neighbor 192.168.x.18 next-hop-self Allows modification of the next-hop router to
itself.
aggregate-address 192.168.x.0 255.255.255.0 Allows only the summarized route to be
summary-only advertised.
no synchronization Turns off BGP synchronization.
clear ip bgp * Resets all BGP connections.
show ip bgp Shows BGP information.
show ip bgp summary Shows summary BGP neighbor status.
show ip bgp neighbors Shows detailed BGP neighbor status.
debug ip bgp updates Displays BGP updates.
Setup
Setup is as follows:
Step 1 On your pxr1 router, disable Frame Relay switching. Change the pxr1
Serial 0 and Serial 2 interfaces back to running HDLC encapsulation.
Ensure that the pxr1 serial interfaces S0, S1, S2, and S3 have the correct
IP address configuration, as follows:
pxr1 S0 192.168.x.17/28
pxr1 S1 192.168.x.33/28
pxr1 S2 192.168.x.49/28
pxr1 S3 10.x.x.x/24
No shut the Serial 1 and Serial 3 interfaces on your pxr1 router.

Step 2 On your pxr2 router, disable EIGRP. Shut down the Serial 0 interface on
your pxr2 router. Change the pxr2 Serial 0 interface encapsulation back
to HDLC. Reconfigure the IP address on your pxr2 Serial 0 to 192.168.x.
18/28.
No shut the Ethernet 0, Serial 0, and Serial 1 interfaces on your pxr2
router.
CHAPTER
7
Implementing BGP in Scalable
Networks
At the end of this chapter, you will be able to describe the scalability problems associated
with internal BGP, list methods to connect to multiple ISPs using BGP, and describe and
configure policy control in BGP using prefix lists. You will be able to explain and configure
BGP route reflectors and explain the use of redistribution between BGP and Interior
Gateway Protocols (IGPs). Given a set of network requirements, you will be able to
configure a multihomed BGP environment and verify proper operation (within described
guidelines) of your routers.
Scalability Problems with IBGP

This section discusses scalability problems with IBGP.
BGP Split Horizon

Chapter 6, “Configuring Basic Border Gateway Protocol,” discusses many BGP concepts,
including IBGP and external BGP (EBGP).
Another rule governing IBGP behavior is the BGP split horizon rule. This BGP rule
specifies that routes learned via IBGP are never propagated to other IBGP peers. BGP split
horizon is illustrated in Figure 7-1. In this figure, Router A learns routes from Router B via
IBGP but does not propagate these routes to Router C.
Figure 7-1 The BGP Split Horizon Rule Prevents Router A from Propagating Routes Learned from Router B to
Router C
AS 65000
B C
382 Chapter 7: Implementing BGP in Scalable Networks
Similar to the distance vector routing protocol split horizon rule, BGP split horizon is
necessary to ensure that routing loops are not started within the AS. The result is that a full
mesh of IBGP peers is required within an AS.
As Figure 7-2 illustrates, though, a full mesh of IBGP is not scalable. With only 13 routers,
78 IBGP sessions would need to be maintained. As the number of routers increases, so does
the number of sessions required, governed by the following formula, in which n is the
number of routers:
n(n – 1) ÷ 2
Figure 7-2 Full-Mesh IBGP Requires Many Sessions and Therefore Is Not Scalable
# IBGP sessions = n(n – 1) ÷ 2

1000 routers means nearly
half a million IBGP sessions
13 routers =>
78 IBGP sessions
In addition to the number of BGP TCP sessions that must be created and maintained, the
amount of routing traffic may also be a problem. Depending on the AS topology, traffic may
be replicated many times on some links as it travels to each IBGP peer. For example, if the
physical topology of a large AS includes some WAN links, the IBGP sessions running over
those links may be consuming a significant amount of bandwidth.
A solution to this problem is the use of route reflectors, discussed in the next section.
Route Reflectors 383
Route Reflectors
This section describes what a route reflector is, how it works, and how to configure it.
Route reflectors modify the BGP split horizon rule by allowing the router configured as the
route reflector to propagate routes learned by IBGP to other IBGP peers, as illustrated in
Figure 7-3.
Figure 7-3 When Router A Is a Route Reflector, It Can Propagate Routes Learned from Router B to Router C
Route reflector
AS 65000
B C
This saves on the number of BGP TCP sessions that must be maintained and also reduces
the BGP routing traffic.
Route Reflector Benefits

With a BGP route reflector configured, a full mesh of IBGP peers is no longer required. The
route reflector is allowed to propagate IBGP routes to other IBGP peers. Route reflectors
are used mainly by ISPs when the number of internal neighbor statements becomes
excessive. Route reflectors reduce the number of BGP neighbor relationships in an AS (thus
saving on TCP connections) by having key routers replicate updates to their route reflector
clients.
Route reflectors do not affect the paths that IP packets follow; only the path that routing
information is distributed on is affected. However, if route reflectors are configured
incorrectly, routing loops may result, as shown in the example later in this chapter, in the
“Route Reflector Migration Tips” section.
Within an AS there can be multiple route reflectors, both for redundancy and for grouping
to further reduce the number of IBGP sessions required.
Migrating to route reflectors involves a minimal configuration and does not have to be done
all at once because routers that are not route reflectors can coexist with route reflectors
within an AS.
Route Reflector Terminology

A route reflector is a router that is configured to be the router allowed to advertise (or
reflect) routes that it learned via IBGP to other IBGP peers. The route reflector will have a
partial IBGP peering with other routers, which are called clients. Peering between the
clients is not needed because the route reflector will pass advertisements between the
clients.
The combination of the route reflector and its clients is called a cluster.
Other IBGP peers of the route reflector that are not clients are called nonclients.
The originator ID is an optional, nontransitive BGP attribute that is created by the route
reflector. This attribute carries the router ID of the originator of the route in the local AS. If
the update comes back to the originator because of poor configuration, the originator
ignores it.
Usually a cluster has a single route reflector, in which case the cluster is identified by the
router ID of the route reflector. To increase redundancy and avoid single points of failure,
a cluster might have more than one route reflector. When this occurs, all the route reflectors
in the cluster need to be configured with a cluster ID. The cluster ID allows route reflectors
to recognize updates from other route reflectors in the same cluster.
Route Reflector Cluster List

A cluster list is a sequence of cluster IDs that the route has passed. When a route reflector
reflects a route from its clients to nonclients outside the cluster, it appends the local cluster
ID to the cluster list. If the update has an empty cluster list, the route reflector will create
one. Using this attribute, a route reflector can identify if the routing information is looped
back to the same cluster due to poor configuration. If the local cluster ID is found in the
cluster list of an advertisement, the advertisement will be ignored.
The originator ID, cluster ID, and cluster list help prevent routing loops in route reflector
configurations.
Route Reflector Design

When using route reflectors in an AS, the AS can be divided into multiple clusters, each
having at least one route reflector and a few clients. Multiple route reflectors can exist in
one cluster for redundancy.
The route reflectors must be fully meshed with IBGP to ensure that all routes learned will
be propagated throughout the AS.
An IGP is still used, just as it was before route reflectors were introduced, to carry local
routes and next-hop addresses.
NOTE Regular split horizon rules still apply between a route reflector and its clients. A route
reflector that receives a route from a client will not advertise that route back to that client.
NOTE There is no defined limit to the number of clients a route reflector may have; it is
constrained by the amount of router memory.
Route Reflector Design Example

Figure 7-4 provides an example of a BGP route reflector design.
Figure 7-4 An Example of a Route Reflector Design
AS 65000 A
B C
D F G H
IBGP connections
EBGP connections
NOTE The physical connections within AS 65000 are not shown in Figure 7-4.
In Figure 7-4, Routers B, D, E, and F form one cluster. Routers C, G, and H form another
cluster. Routers B and C are route reflectors. Routers A, B, and C are fully meshed with
IBGP. Note that the routers within a cluster are not fully meshed.
Route Reflector Operation

When a route reflector receives an update, it takes the following actions, depending on the
type of peer that sent the update:
• If the update is from a client peer, it sends the update to all nonclient peers and to all
client peers (except the originator of the route).
• If the update is from a nonclient peer, it sends the update to all clients in the cluster.
• If the update is from an EBGP peer, it sends the update to all nonclient peers and to
all client peers.
For example, in Figure 7-4, the following will happen:
• If Router C receives an update from Router H (a client), it will send it to Router G as
well as to routers A and B.
• If Router C receives an update from Router A (a nonclient), it will send it to routers
G and H.
• If Router C receives an update from Router X (via EBGP), it will send it to routers G
and H as well as to routers A and B.
NOTE Routers will also send updates to their EBGP neighbors, as appropriate.
Route Reflector Migration Tips

When migrating to using route reflectors, the first consideration is which routers should be
the reflectors and which should be the clients. Following the physical topology in this
design decision will ensure that the packet-forwarding paths will not be affected. Not
following the physical topology (for example, configuring route reflector clients that are not
physically connected to the route reflector) may result in routing loops.
Figure 7-5 can be used to demonstrate what can happen if route reflectors are configured
without following the physical topology. In this figure, the bottom router, Router E, is a
route reflector (RR) client for both route reflectors, routers C and D.
In this bad design, which does not follow the physical topology, the following will happen:
• Router B would know that the next hop to get to 10.0.0.0 is x (because it would have
learned this from its route reflector, Router C).
• Router A would know that the next hop to get to 10.0.0.0 is y (because it would have
learned this from its route reflector, Router D).
• For Router B to get to x, the best route may be through Router A, so Router B would
send a packet destined for 10.0.0.0 to Router A.
• For Router A to get to y, the best route may be through Router B, so Router A would
send a packet destined for 10.0.0.0 to Router B.
• This is a routing loop.
Figure 7-5 A Bad Route Reflector Design
loop
RR client of D RR client of C
A B
RR RR
C D
x y
RR client of C and D
IBGP E
Network 10.0.0.0/8
Figure 7-6 shows a better design because it follows the physical topology. Again, in this
figure, the bottom router, Router E, is a route reflector client for both route reflectors.
Figure 7-6 A Good Route Reflector Design
RR client of C RR client of D
A B
RR RR
C D
x y
RR client of C and D
E
IBGP
Network 10.0.0.0/8
In this good design, which does follow the physical topology, the following is true:
• Router B would know that the next hop to get to 10.0.0.0 is y (because it would have
learned this from its route reflector, Router D).
• Router A would know that the next hop to get to 10.0.0.0 is x (because it would have
learned this from its route reflector, Router C).
• For Router A to get to x, the best route would be through Router C, so Router A w
ould send a packet destined for 10.0.0.0 to Router C, and Router C would send it to
Router E.
• For Router B to get to y, the best route would be through Router D, so Router B
would send a packet destined for 10.0.0.0 to Router D, and Router D would send it to
Router E.
• There is not a routing loop.
When migrating to using route reflectors, configure one route reflector at a time, and then
delete the redundant IBGP sessions between the clients. It is recommended that you
configure one route reflector per cluster.
Route Reflector Configuration

The neighbor ip-address route-reflector-client router configuration command is used to
configure the router as a BGP route reflector and to configure the specified neighbor as its
client. This command is described in Table 7-1.
Table 7-1 neighbor route-reflector-client Command Description
neighbor route-reflector-client
Command Description
ip-address IP address of the BGP neighbor being identified as
a client
Configuring Cluster ID
To configure the cluster ID if the BGP cluster has more than one route reflector, use the bgp
cluster-id cluster-id router configuration command on all the route reflectors in a cluster.
You cannot change the cluster ID after the route reflector clients have been configured.
Route Reflector Restrictions

Route reflectors cause some restrictions on other commands, including the following:
• When used on route reflectors, the neighbor next-hop-self command will affect only
the next hop of EBGP learned routes because the next hop of reflected IBGP routes
should not be changed.
• Route reflector clients are not compatible with peer groups. This is because a router
configured with a peer group must send any update to all members of the peer group.
If a route reflector has all its clients in a peer group and then one of these clients sends
an update, the route reflector is responsible for sharing that update with all other
clients. The route reflector must not send the update to the originating client because
of the split horizon rule.
Route Reflector Example

The example network in Figure 7-7 illustrates a router configured as a route reflector in AS
65000. The configuration for Router A in this figure is provided in Example 7-1.
Figure 7-7 Router A Is a Route Reflector
Route reflector
A
AS 65500 AS 65000 AS 64520
172.16.12.1 C
B
172.16.17.2

RTRA(config)# router bgp 65000
RTRA(config-router)# neighbor 172.16.12.1 remote-as 65000
RTRA(config-router)# neighbor 172.16.12.1 route-reflector-client
RTRA(config-router)# neighbor 172.16.17.2 remote-as 65000
RTRA(config-router)# neighbor 172.16.17.2 route-reflector-client
The neighbor route-reflector-client commands are used to configure which neighbors will
be route reflector clients. In this example, both routers B and C will be route reflector clients
of Router A, the route reflector.
Verifying Route Reflectors

The show ip bgp neighbors command indicates that a particular neighbor is a route
reflector client. The example output of this command shown in Example 7-2 is from Router
A in the Figure 7-7 and shows that 172.16.12.1 (Router B) is a route reflector client of
Router A.
Example 7-2 show ip bgp neighbor Output from Router A in Figure 7-7
RTRA#show ip bgp neighbors
BGP neighbor is 172.16.12.1, remote AS 65000, internal link
Index 1, Offset 0, Mask 0x2
Route-Reflector Client
BGP version 4, remote router ID 192.168.101.101
BGP state = Established, table version = 1, up for 00:05:42
Last read 00:00:42, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 5 seconds
Received 14 messages, 0 notifications, 0 in queue
Sent 12 messages, 0 notifications, 0 in queue
Prefix advertised 0, suppressed 0, withdrawn 0
Connections established 2; dropped 1
Last reset 00:05:44, due to User reset
1 accepted prefixes consume 32 bytes
0 history paths consume 0 bytes
--More--
Policy Control and Prefix Lists

This section describes how a routing policy is applied to a BGP network using prefix lists.
If you want to restrict the routing information that the Cisco IOS software learns or
advertises, you can filter BGP routing updates to and from particular neighbors. To do this,
you can define either an access list or a prefix list and then apply it to the updates.
Distribute lists use access lists to specify what routing information is to be filtered.
Distribute lists for BGP have been obsoleted by prefix lists in the Cisco IOS.
Prefix lists are available in Cisco IOS Release 12.0 and later.
NOTE Distribute lists for BGP are detailed in Appendix A, “Job Aids and Supplements.”
Figure 7-8 shows an example where prefix lists may be used. In this figure, Router C is
advertising network 172.30.0.0 to Router A. If we wanted to stop those updates from
propagating to AS 65000 (to Router B), a prefix list could be applied on Router A to filter
those updates when Router A is talking to Router B.
Policy Control and Prefix Lists 391
Prefix List Characteristics

Distribute lists make use of access lists to do route filtering. However, access lists were
originally designed to do packet filtering.
Prefix lists, available in Cisco IOS Release 12.0 and later, can be used as an alternative to
access lists in many BGP route filtering commands. The advantages of using prefix lists
include the following:
• A significant performance improvement over access lists in loading and route lookup
of large lists.
• Support for incremental modifications. Compared to the normal access list in which
one no command will erase the whole access list, prefix list entries can be modified
incrementally.
Figure 7-8 An Example Where Prefix Lists May Be Used
192.168.2.0
172.30.0.0
AS 65000
B
10.10.10.2 AS 65500
10.10.20.2 C
172.30.0.0
172.30.0.0
10.10.20.1
10.10.10.1 A
192.168.1.0
AS 64520
• More user-friendly command-line interface. The command-line interface for using

extended access lists to filter BGP updates is difficult to understand and use.
• Greater flexibility.
Filtering with Prefix Lists

Filtering by prefix list involves matching the prefixes of routes with those listed in the prefix
list, similar to using access lists.
Whether a prefix is permitted or denied is based upon the following rules:
• An empty prefix list permits all prefixes.
• If a prefix is permitted, the route is used. If a prefix is denied, the route is not used.
• Prefix lists consist of statements with sequence numbers. The router begins the search
for a match at the top of the prefix list, which is the statement with the lowest sequence
number.
• When a match occurs, the router does not need to go through the rest of the prefix list.
For efficiency, you may want to put the most common matches (permits or denies)
near the top of the list by specifying a lower sequence number.
• An implicit deny is assumed if a given prefix does not match any entries of a prefix
list.
Configuring Prefix Lists
NOTE Most of the prefix-list commands are not documented in the Cisco IOS Command
Reference manuals for Release 12.0. The only published documentation is in the BGP
Configuration Guide for Release 12.0. However, all the prefix list commands that are in this
book have been tested and do work on Release 12.0. The commands are documented in the
Cisco IOS Command Reference manuals for Release 12.1.
The ip prefix-list list-name [seq seq-value] {deny | permit} network/len [ge ge-value] [le
le-value] global configuration command is used to create a prefix-list, as described in Table
7-2.
Table 7-2 ip prefix-list Command Description
ip prefix-list Command Description
list-name Name of the prefix list that will be created. (Note that the list
name is case sensitive.)
seq-value 32-bit sequence number of the prefix list statement, used to
determine the order in which the statements are processed when
filtering. Default sequence numbers are in increments of 5 (5,
10, 15, and so on).
deny | permit The action taken when a match is found.
network/len The prefix to be matched and the length of the prefix. The
network is a 32-bit address; the length is a decimal number.
ge-value The range of the prefix length to be matched for prefixes that are
more specific than network/len. The range is assumed to be from
ge-value to 32 if only the ge attribute is specified.
Table 7-2 ip prefix-list Command Description (Continued)

le-value The range of the prefix length to be matched for prefixes that are
more specific than network/len. The range is assumed to be from
len to le-value if only the le attribute is specified.
Both ge and le are optional. They can be used to specify the range of the prefix length to be
matched for prefixes that are more specific than network/len. The value range is:
len < ge-value < le-value < = 32
An exact match is assumed when neither ge nor le is specified.
Prefix list entries can be reconfigured incrementally—in other words, an entry can be
deleted or added individually.
The neighbor {ip-address | peer-group-name} prefix-list prefix-listname {in | out} router
configuration command is used to distribute BGP neighbor information as specified in a
prefix list, as described in Table 7-3.
Table 7-3 neighbor prefix-list Command Description
neighbor prefix-list
Command Description
ip-address IP address of the BGP neighbor for which routes will be filtered
peer-group-name Name of a BGP peer group
prefix-listname Name of the prefix list that will be used to filter the routes
in Indication that the prefix list is to be applied to incoming
advertisements from the neighbor
out Indication that the prefix list is to be applied to outgoing
advertisements to the neighbor
NOTE The neighbor prefix-list command can be used as an alternative to the neighbor
distribute-list command, but you cannot use both commands for configuring the same
BGP peer.
ip prefix-list Command Options

The use of the ge and le options in the ip prefix-list command can be confusing. The
following are results of some testing done to understand these keywords.
Three routers were used in this testing: Router B and Router A and its neighbor 10.1.1.1,
as illustrated in Figure 7-9.
Before configuring the prefix list, Router A learns the following routes (from Router B):
172.16.0.0 subnetted:
172.16.10.0/24
172.16.11.0/24
Five scenarios were tested, as follows:

Scenario 1—In this scenario, the following is configured on Router A:
router bgp 65000
aggregate-address 172.16.0.0 255.255.0.0
neighbor 10.1.1.1 prefix-list tenonly out
ip prefix-list tenonly permit 172.16.10.0/8 le 24
Figure 7-9 Network Used in Prefix List Option Testing
172.16.11.0
172.16.10.0
B
10.1.1.1
A
AS 65000
When the router’s configuration is viewed with the show run command, you see that the
router automatically changed the last line of this configuration to the following:
Neighbor 10.1.1.1 learned about 172.16.0.0/16, 172.16.10.0/24, and 172.16.11.0/24.

router bgp 65000
Neighbor 10.1.1.1 learned about only 172.16.0.0/16.

router bgp 65000
ip prefix-list tenonly permit 172.0.0.0/8 ge 17
Neighbor 10.1.1.1 learned about only 172.16.10.0/24 and 172.16.11.0/24. (In other words,
it ignores the /8 parameter and treats the command as if it had the parameters ge 17 le 32.)
router bgp 65000
ip prefix-list tenonly permit 172.0.0.0/8 ge 16 le 24
Neighbor 10.1.1.1 learned about 172.16.0.0/16, 172.16.10.0/24, and 172.16.11.0/24. (In

other words, it ignores the /8 parameter and treats the command as if it had the parameters
ge 16 le 24.)
router bgp 65000
ip prefix-list tenonly permit 172.0.0.0/8 ge 17 le 24
Neighbor 10.1.1.1 learned about 172.16.10.0/24 and 172.16.11.0/24. (In other words, it
ignores the /8 parameter and treats the command as if it had the parameters ge 17 le 24.)
The no ip prefix-list list-name global configuration command, where list-name is the name
of a prefix list, is used to delete a prefix list.
The [no] ip prefix-list list-name description text global configuration command can be
used to add or delete a text description for a prefix list.
Prefix List Sequence Numbers

Prefix list sequence numbers are generated automatically, unless you disable this automatic
generation. If you disable the automatic generation of sequence numbers, you must specify
the sequence number for each entry using the seq-value argument of the ip prefix-list
command.
A prefix list is an ordered list. The sequence number is significant when a given prefix is
matched by multiple entries of a prefix list, in which case the one with the smallest
sequence number is considered the real match.
Regardless of whether the default sequence numbers are used in configuring a prefix list, a
sequence number does not need to be specified when removing a configuration entry.
By default, the entries of a prefix list will have sequence values of 5, 10, 15, and so on. In
the absence of a specified sequence value, a new entry will be assigned with a sequence
number equal to the current maximum sequence number plus 5.
Prefix list show commands include the sequence numbers in their output.
The no ip prefix-list sequence-number global configuration command is used to disable
the automatic generation of sequence numbers of prefix list entries. Use the ip prefix-list
sequence-number global configuration command to re-enable the automatic generation of
sequence numbers.
Prefix List Example

The example network in Figure 7-10 illustrates the use of a prefix list. In this example, we
want Router A to send only the supernet 172.0.0.0/8 to AS 65000; the route to the network
172.30.0.0/16 should not be sent. The configuration for Router A in this figure is provided
in Example 7-3.
Figure 7-10 A Prefix List Example
172.30.0.0
AS 65000
B
10.10.10.2 AS 65500
10.10.20.2 C
172.0.0.0/8
172.30.0.0/16
10.10.20.1
10.10.10.1 A
192.168.1.0
AS 64520

RtrA(config)# ip prefix-list superonly permit 172.0.0.0/8
RtrA(config)# ip prefix-list superonly description only permit supernet
RtrA(config)# router bgp 64520
RtrA(config-router)# network 192.168.1.0
RtrA(config-router)# aggregate-address 172.0.0.0 255.0.0.0
RtrA(config-router)# neighbor 10.10.10.2 prefix-list superonly out
RtrA(config-router)# exit
In this example, Router A has two neighbors: Router B (10.10.10.2 in AS 65000) and
Router C (10.10.20.2 in AS 65500). When Router A sends updates to neighbor Router B,
the neighbor prefix-list statement specifies that it will use the prefix list called superonly
to determine which updates are to be sent.
The ip prefix-list superonly specifies that only the route 172.0.0.0/8 should be sent (it is
permitted in the prefix list). No other routes will be sent to Router B because prefix lists
have an implicit deny any at the end.
Verifying Prefix Lists

The EXEC commands related to prefix lists are described in Table 7-4. Use the show ip
prefix-list ? command to see all the show commands available for prefix lists.
Table 7-4 Commands Used to Verify Prefix Lists
Command Description
show ip prefix-list [detail | summary] Displays information on all prefix lists.
Specifying the detail keyword includes the
description and the hit count (the number of
times the entry has matched a route) in the
display.
show ip prefix-list [detail | summary] name Displays a table showing the entries in a
specific prefix list.
show ip prefix-list name [network/len] Displays the policy associated with a specific
prefix/len in a prefix list.
show ip prefix-list name [seq seq-num] Displays the prefix list entry with a given
sequence number.
show ip prefix-list name [network/len] longer Displays all entries of a prefix list that are more
specific than the given network and length.
show ip prefix-list name [network/len] first- Displays the entry of a prefix list that matches
match the given prefix (network and length of prefix).
clear ip prefix-list name [network/len] Resets the hit count shown on prefix list entries.
Verifying Prefix Lists Example

The example output of the show ip prefix-list detail command shown in Example 7-4 is
from Router A in Figure 7-10. Router A has a prefix list called superonly, with only one
entry (sequence number 5). The hit count of 0 means that no routes have matched this entry.
Example 7-4 show ip prefix-list detail Command Output from Router A in Figure 7-10
RtrA #show ip prefix-list detail
Prefix-list with the last deletion/insertion: superonly
ip prefix-list superonly:
Description: only permit supernet
count: 1, range entries: 0, sequences: 5 - 5, refcount: 1
seq 5 permit 172.0.0.0/8 (hit count: 0, refcount: 1)
Multihoming
This section describes multihoming and provides some examples of configuring it.
Multihoming is the term used to describe when an AS is connected to more than one ISP.
This is usually done for one of two reasons, as follows:
• To increase the reliability of the connection to the Internet so that if one connection
fails, another will still be available
• To increase the performance so that better paths can be used to certain destinations
Types of Multihoming
The configuration of the multiple connections to the ISPs can be classified according to the
routes that are provided to the AS from the ISPs. Three common ways of configuring the
connections are as follows:
• All ISPs pass only default routes to the AS.
• All ISPs pass default routes and selected specific routes (for example, from customers
with whom the AS exchanges a lot of traffic) to the AS.
• All ISPs pass all routes to the AS.
Each of these scenarios is examined in the following sections.
NOTE When multihoming, the ISPs you connect to should announce your prefixes to the Internet.
For example, if the prefixes assigned to you are part of only one of the ISP address ranges,
the other ISPs (which do not own your prefixes) should also advertise your specific prefixes
to the Internet.
Default Routes from All Providers

The first scenario is when all ISPs pass only default routes to the AS. This requires the
minimum resources (memory and CPU usage) within the routers in the AS because only
Multihoming 399
default routes will have to be processed. The AS will send all its routes to the ISPs, which
will process them and pass them on to other autonomous systems, as appropriate.
The ISP that a specific router within the AS uses to reach the Internet will be decided by the
Interior Gateway Protocol (IGP) metric used to reach the default route within the AS.
The route that inbound packets take to get to the AS will be decided outside of the AS
(within the ISPs and other autonomous systems).
In the example shown in Figure 7-11, AS 65000 and AS 65250 send default routes into AS
65500.
Figure 7-11 AS 65500 Is Receiving Default Routes from All Providers
AS 64520
172.16.0.0/16
ISP ISP
AS 65000 AS 65250
D E
0.0.0.0 0.0.0.0
A B
AS 65500
C chooses lowest
IGP metric to default
C
The ISP that a specific router within AS 65500 uses to reach any external address will be
decided by the IGP metric used to reach the default route within the AS. For example, if the
Routing Information Protocol (RIP) is used within AS 65500, Router C will select the route
with the lowest hop count to the default route (to either Router A or Router B) when it wants
to send packets to network 172.16.0.0. If Router C chooses the path through Router B,
packets will travel to 172.16.0.0 as indicated by the arrow in Figure 7-11.
Customer and Default Routes from All Providers

The second scenario is when all ISPs pass default routes and selected specific routes (for
example, from customers with whom the AS exchanges a lot of traffic) to the AS.
This requires more resources (memory and CPU usage) within the routers in the AS
because default routes and some external routes will have to be processed. The AS sends
all its routes to the ISPs, which process them and pass them on to other autonomous
systems, as appropriate.
The ISP that a specific router within the AS uses to reach the customer networks will
usually be the shortest AS path; however this can be overridden. The path to all other
external destinations will be decided by the IGP metric used to reach the default route
within the AS.
In the example shown in Figure 7-12, AS 65000 and AS 65250 send default routes as well
as specific routes to the customer’s (AS 64520) network 172.16.0.0, into AS 65500.
Figure 7-12 AS 65500 Is Receiving Customer and Default Routes from All Providers
Customer
AS 64520
172.16.0.0/16
ISP ISP
AS 65000 AS 65250
D E
A B
AS 65500
C chooses shortest
AS-path to customer
C
The ISP that a specific router within AS 65500 uses to reach the customer networks will
usually be the shortest AS path. The shortest AS path to AS 64520 is via AS 65000 (versus
via AS 65250, then AS 65000) through Router A. Router C will select this route when it
wants to send packets to network 172.16.0.0, as indicated by the arrow in Figure 7-12.
The routes to other external addresses that are not specifically advertised to AS 65500 will
be decided by the IGP metric used to reach the default route within the AS.
In the example shown in Figure 7-13, AS 65000 and AS 65250 send default routes as well
as specific routes to the customer’s (AS 64520) network 172.16.0.0, into AS 65500. The
ISP that a specific router within AS 65500 uses to reach the customer networks will usually
be the shortest AS path. However, Router B is configured to change the local preference of
Multihoming 401
routes to 172.16.0.0/16 to 800 from its default of 100. Therefore, Router C will take the path
through Router B to get to 172.16.0.0, as indicated by the arrow in Figure 7-13.
Figure 7-13 AS 65500 Is Receiving Customer and Default Routes from All Providers and Has Modified the Local
Preference
Customer
AS 64520
172.16.0.0/16
ISP ISP
AS 65000 AS 65250
D E
Local preference = 800

A B for 172.16.0.0/16
AS 65500
C chooses highest
local preference
C
Configuration of Router B
The configuration of Router B in Figure 7-13 includes the commands shown in
Example 7-5.
The use of route maps for BGP is explained in Appendix A.
Example 7-5 Part of Configuration of Router B in Figure 7-13
router bgp 65500
neighbor <Router E ip address> route-map toright in
ip prefix-list customer permit 172.16.0.0/16
route-map toright permit 10

match ip address prefix-list customer
set local-preference 800
The routes to other external addresses that are not specifically advertised to AS 65500 will
be decided by the IGP metric used to reach the default route within the AS.
Full Routes from All Providers

The third scenario is when all ISPs pass all routes to the AS.
This scenario requires a lot of resources (memory and CPU usage) within the routers in the
AS because all external routes will have to be processed. The AS sends all its routes to the
ISPs, which process them and pass them on to other autonomous systems, as appropriate.
The ISP that a specific router within the AS uses to reach the external networks will usually
be the shortest AS path; however, this can be overridden.
In the example shown in Figure 7-14, AS 65000 and AS 65250 send all routes into AS
65500.
Figure 7-14 AS 65500 Is Receiving Full Routes from All Providers
AS 64520 AS 65510
ISP ISP
AS 65000 AS 65250
D E
A B
AS 65500
C chooses shortest AS-path

C
The ISP that a specific router within AS 65500 uses to reach the external networks will
usually be the shortest AS path. For example, in Figure 7-14, Router C chooses the path
through AS 65000 to get to AS 64520, and it chooses the path through AS 65250 to get to
AS 65510, as indicated by the arrows in the figure. However, the routers in AS 65500 could
be configured to influence the path that routes to certain networks take. For example, the
local preference of certain routes or the weight of a neighbor connection could be changed.
Multihoming 403
Configuring Weight and Local Preference

These are some of the commands that can be used to influence the path taken to external
routes.
The neighbor {ip-address | peer-group-name} weight weight router configuration
command is used to assign a weight to a neighbor connection, as described in Table 7-5.
Table 7-5 neighbor weight Command Description
neighbor weight Command Description
ip-address IP address of the BGP neighbor.
peer-group-name Name of a BGP peer group.
weight Weight to assign. Acceptable values are 0 to 65535. The
default is 32768 for local routes (routes that the router
originates); other routes have a weight of 0 by default.
The bgp default local-preference value router configuration command is used to change
the default local preference value, as described in Table 7-6. The default local preference is
100. This command is used to change the local preference on all routes.
Table 7-6 bgp default local-preference Command Description
bgp default local-preference
Command Description
value Local preference value from 0 to 4294967295. A higher
value is preferred.
NOTE Recall that the term local in local preference means that it is local to the AS. Local
preference is used to select routes with equal weights because the weight attribute is looked
at first. Only when all weights are equal is the local preference attribute examined. The
weight attribute influences only the local router, whereas the local preference attribute
influences other routers within the AS.
The local preference is stripped in outgoing EBGP updates.
There are also other commands to change BGP attributes. (Most of these commands use
route maps. The concept of route maps is covered in the next chapter.)
NOTE To force new parameters with a neighbor to take effect, a new session must be established
with the neighbor using the clear ip bgp command. This is due to the incremental update
nature of BGP and the fact that the attribute modifiers are applied on input or output
updates, not on entries that already exist on the router.
Multihoming Examples
In the example shown in Figure 7-15, AS 64520 is connected to two ISPs: AS 65000 and
AS 65250. Both ISPs are sending full routes to AS 64520.
Figure 7-15 AS 64520 Is Multihomed
172.25.0.0
AS 65500
ISP
172.20.0.0
AS 65000 ISP
B
172.30.0.0
10.10.10.2 AS 65250
10.10.20.1
C
10.10.20.2
10.10.10.1
A
AS 64520
Multihoming 405
Multihoming Example with No Special Tuning

In the first example configuration shown in Example 7-6, Router A is configured with two
EBGP neighbors: Router B (10.10.10.2) and Router C (10.10.20.1). No special tuning is
done to influence the way that AS 64520 gets to the other autonomous systems.
Example 7-6 Configuration of Router A in Figure 7-15, with No Special Tuning
RtrA(config-router)# network 10.10.10.0 mask 255.255.255.0
Example 7-7 provides the show ip bgp command output on Router A in the network in
Figure 7-15. In this example, Router A selects the route via 10.10.10.2 (Router B) to get to
172.20.0.0 and the route via 10.10.20.1 (Router C) to get to 172.30.0.0 because these paths
have the shortest AS path length (of one AS). (Recall that the selected route is indicated
with the > symbol in the left-most column of the show ip bgp output.)
Example 7-7 show Output from Router A in Figure 7-15, with No Special Tuning
RtrA#show ip bgp
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

*> 10.10.10.0/24 0.0.0.0 0 32768 i
*> 10.10.20.0/24 0.0.0.0 0 32768 i
* 172.20.0.0 10.10.20.1 0 65250 65000 i
*> 10.10.10.2 0 0 65000 i
*> 172.25.0.0 10.10.10.2 0 65000 65500 i
* 10.10.20.1 0 65250 65500 i
* 172.30.0.0 10.10.10.2 0 65000 65250 i
*> 10.10.20.1 0 0 65250 i
Router A has two paths to 172.25.0.0, and they both have the same AS path length (there
are two autonomous systems in each path). In this case, with all other attributes being equal,
Router A will select the oldest path. If we ignore this oldest path criteria for now (because
we can’t determine which router will send the path to Router A first), Router A will select
the path that has the lowest BGP router ID value.
Unfortunately, the BGP router ID values of Routers B and C are not displayed in the output
of the show ip bgp command. The show ip bgp neighbors command or the show ip bgp
172.25.0.0 command could be used to provide these values. Using these commands, the
router ID for Router B was found to be 172.20.0.1, and the router ID for Router C was
found to be 172.30.0.1. Router A will select the lowest of these router IDs; Router A
therefore chooses the path through Router B (172.20.0.1) to get to 172.25.0.0.
Multihoming Example with Weight Attributes Changed

In the example configuration for Router A in Figure 7-15 shown in Example 7-8, Router A
is configured with two EBGP neighbors: Router B (10.10.10.2) and Router C (10.10.20.1).
The weights used for routes from each neighbor have been changed from their default of
zero. Routes received from 10.10.10.2 (Router B) will have a weight of 100, and routes
received from 10.10.20.1 (Router C) will have a weight of 150.
Example 7-8 Configuration of Router A in Figure 7-15, with Weights Changed
RtrA(config-router)# neighbor 10.10.10.2 weight 100
RtrA(config-router)# neighbor 10.10.20.1 weight 150
Example 7-9 provides the show ip bgp command output on Router A in the network in
Figure 7-15, with the weights changed. In this example, because the weight for Router C is
higher than the weight for Router B, Router A is forced to use Router C as a next hop to
reach all external routes. Recall that the weight attribute is looked at before the AS path
length, so the AS path length will be ignored in this case.
Example 7-9 show Output from Router A in Figure 7-15, with Weights Changed
RtrA#show ip bgp
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

*> 10.10.10.0/24 0.0.0.0 0 32768 i
*> 10.10.20.0/24 0.0.0.0 0 32768 i
*> 172.20.0.0 10.10.20.1 150 65250 65000 i
* 10.10.10.2 0 100 65000 i
*> 172.25.0.0 10.10.20.1 150 65250 65500 i
* 10.10.10.2 100 65000 65500 i
*> 172.30.0.0 10.10.20.1 0 150 65250 i
* 10.10.10.2 100 65000 65250 i
Redistribution with IGPs 407
Redistribution with IGPs

Chapter 8, “Optimizing Routing Update Operation,” discusses route redistribution and how
it is configured. Here we examine specifics of when redistribution between BGP and IGPs
is appropriate.
As noted earlier, and as shown in Figure 7-16, a router running BGP keeps a table of BGP
information, separate from the IP routing table. Information in the tables can be exchanged
between the BGP protocol and the IGP protocol running in the routers.
Figure 7-16 A Router Running BGP Keeps Its Own Table, Separate from the IP Routing Table
IGP routing BGP routing

protocol IP BGP protocol
Advertising Networks into BGP

Route information is sent from an autonomous system into BGP in one of the following
three ways:
• Using the network command. As already discussed, the network command allows
BGP to advertise a network that is already in the IP table. The list of network
commands must include all the networks in the AS that you want to advertise.
• Redistributing static routes to null 0 into BGP. Redistribution occurs when a router
running different protocols advertises routing information received between the
protocols. Static routes in this case are considered to be a protocol, and static
information is advertised to BGP. (The use of the null 0 interface is discussed in the
following section.)
• Redistributing dynamic IGP routes into BGP. This solution is not recommended
because it may cause instability.
The following two sections examine the last two points in more detail.
Redistributing Static Routes into BGP

Redistribution of static routes configured to the null 0 interface into BGP is done to
advertise aggregate routes rather than specific routes from the IP table. An example
configuration is shown in Example 7-10.
Example 7-10 A Static Route to Null 0 Is Redistributed to Advertise Aggregate Routes
router bgp 64520
redistribute static
!
ip route 192.168.0.0 255.255.0.0 null 0
Any route redistributed into BGP must already be known in the IP table. Using the static
route to null 0 is a way of fooling the process into believing that a route actually exists for
the aggregate. A static route to null 0 is not necessary if you are using a network command
with a nonaggregated network—in other words, a network that exists in the IP table.
The use of null 0 may seem strange because a static route to null 0 means to discard any
information for this network. This will usually not be a problem because the router doing
the redistribution has a more specific route to the destination networks, and these will be
used to route any traffic that comes into the router. A problem with using this method of
aggregation is that if the router loses access to the more specific routes, it will still be
advertising the static aggregate, thus creating a black hole.
The preferred method of advertising a summary route is to use the aggregate-address
command. With this command, as long as a more specific route exists in the BGP table, the
aggregate gets sent. If the aggregating router loses all its specific connections to the
networks being aggregated, then the aggregate route will disappear from the BGP table and
the BGP aggregate will not get sent. For example, consider a router that has knowledge of
subnets 172.16.1.0/24 and 172.16.2.0/24, and that advertises the aggregate route
172.16.0.0/16. If the router loses knowledge of only one of these subnets, it will still
advertise the aggregate, 172.16.0.0/16. However, if it loses knowledge of both subnets, then
it will no longer advertise the aggregate 172.16.0.0/16 because it can no longer get to any
part of that network.
Redistributing Dynamic IGP Routes into BGP

Redistributing from an IGP into BGP is not recommended because any change in the IGP
routes—for example, if a link goes down—may cause a BGP update. This method could
result in unstable BGP tables.
If redistribution is used, care must be taken that only local routes are redistributed. For
example, routes learned from other autonomous systems (that were learned by redistri-
buting BGP into the IGP) must not be sent out again from the IGP, or routing loops could
result. Configuring this filtering can be complex.
Redistribution with IGPs 409
NOTE Using a redistribute command into BGP will result in an incomplete origin attribute for the
route; an incomplete origin is indicated with a ? in the show ip bgp command output.
Advertising from BGP into an IGP

Route information may be sent from BGP into an autonomous system by redistribution of
the BGP routes into the IGP.
Because BGP is an external routing protocol, care must be taken when exchanging
information with internal protocols because of the amount of information in BGP tables.
For ISP autonomous systems, redistributing from BGP is not normally required. Other
autonomous systems may use redistribution, but the number of routes will mean that
filtering will normally be required.
Each of these situations is examined in the following sections.
ISP—No Redistribution from BGP into IGP Required

An ISP typically has all routers in the AS (or at least all routers in the transit path within
the AS) running BGP. Of course, this would be a full-mesh IBGP environment, and IBGP
would be used to carry the EBGP routes across the AS. All the BGP routers in the AS would
be configured with the no synchronization command because synchronization between
IGP and BGP is not required. The BGP information then would not need to be redistributed
into the IGP. The IGP would need to route only information local to the AS and routes to
the next-hop addresses of the BGP routes.
One advantage of this approach is that the IGP protocol does not have to be concerned with
all the BGP routes; BGP will take care of them. BGP will also converge faster in this
environment because it does not have to wait for the IGP to advertise the routes.
Non-ISP—Redistribution from BGP into IGP May Be Required

A non-ISP AS typically would not have all routers in the AS running BGP, and it may not
have a full-mesh IBGP environment. If this is the case, and if knowledge of external routes
is required inside the AS, then redistribution of BGP into the IGP would be necessary.
However, because of the number of routes that would be in the BGP tables, filtering will
normally be required.
As discussed earlier in this chapter in the “Multihoming” section, an alternative to receiving
full routes from BGP is that the ISP could send only default routes, or default routes and
some external routes, to the AS.
NOTE An example of when redistribution into an IGP may be necessary is in an AS that is running
BGP only on its border routers and that has other routers in the AS that do not run BGP, but
that require knowledge of external routes.
Redistribution between routing protocols is discussed in detail in Chapter 8.
Case Study: Multihomed BGP

Refer to Chapter 1, “Routing Principles,” for introductory information on the JKL case
study.
Recall that throughout this book we have been using a case study of JKL Corporation to
discuss various aspects of scalable routing. The case studies are used to review key concepts
and to discuss critical issues surrounding network operation.
In this case study, you will look at how JKL will connect to the Internet. As shown in Figure
7-17, JKL is AS 65106 and has two ISP connections, to AS 65505 and AS 64573. As you
recall, JKL runs the Open Shortest Path First (OSPF) protocol as its IGP. JKL must consider
methods to select which ISP handles the bulk of its network traffic at different times of the
day.
• Which topology requirements will determine which routers will run BGP
• Whether synchronization will be required between BGP and the IGP
• The issues associated with redistribution between an IGP and BGP
• The route advertisement method for routes sent to and received from the Internet
Case Study Solution

JKL needs full-time connectivity to the Internet to conduct e-commerce. Two separate
routers (located in the core of the corporate network) provide the physical connectivity to
the Internet. Each of the routers maintains a connection to a different ISP, and this creates
a multihomed BGP topology.
The routers marked A and B run BGP. Routers A and B belong to a registered autonomous
system and maintain an EBGP relationship with their respective ISPs.
Case Study: Multihomed BGP 411
Figure 7-17 Multihomed BGP Case Study Topology
Internet
Autonomous Autonomous
system 65505 IBGP IBGP system 64573
Autonomous
system 65521
Full-mesh
serial
topology
EBGP EBGP
ISP #1 ISP #2
A B
Enterprise—Corporation JKL
Autonomous
system 65106
Ethernet
Serial
Routers A and B would need to have an IBGP relationship with each other only if the AS
was providing a transit path for other autonomous systems. Most likely this would not be
the case because then either all the routers in the AS in the path between Routers A and B
would need to run BGP or BGP would need to be redistributed into the AS. JKL requested
that only default routes be provided from both ISPs.
Routers A and B have been configured with loopback interfaces to provide stability for
session establishment with peer routers. As members of JKL’s OSPF core, routers A and B
must also be configured to run an IGP—in this case, OSPF. The OSPF core uses default
routes to direct internal traffic toward the Internet. The strategy of using default routes for
outbound traffic means that redistribution of BGP information into OSPF is not a
requirement. To reach the Internet, outbound traffic only needs to follow the path already
defined by the default route.
It is important to understand some of the issues associated with redistribution between an
IGP and BGP. If routers A and B were running IBGP and the BGP routes learned by Router
A from ISP 1 were redistributed into the IGP (OSPF, in this case), they would be passed
through the AS to Router B. If those routes (and other interior routes) were redistributed
from the IGP at Router B into BGP, serious problems could result, including the presence
of more than 70,000 routes in the routing table and the loss of AS path and other BGP
attributes when those routes enter the IGP.
Routers A and B advertise AS 65106 to both ISPs, which process them and pass them on to
other autonomous systems as appropriate. The route that inbound packets take to get to JKL
is decided outside of JKL, within the ISPs and other autonomous systems. For the topology
shown in Figure 7-17, return traffic would come into JKL through one of the ISPs,
determined by the AS path length, if all other parameters were equal. Setting the MED
parameter on routers A and B to try to affect the return path in this case would not have an
effect. This is because the routers are connected to different ISPs, and the MED attribute is
not passed on along with the updates; it would be set back to its default of 0 when updates
are passed on.
Some highlights of this case study include these:
• Routers A and B will form an EBGP session with their respective ISPs.
• If a default route policy is used within the JKL core to forward traffic to the ISPs, route
redistribution between BGP and OSPF is unnecessary.
• BGP’s route selection algorithm checks several criteria, including the following:
— Highest Cisco weight
— Highest local preference
— Locally originated by this router
— Shortest AS path
— Lowest origin code
— Lowest MED value
— EBGP better than IBGP
— Shortest internal path inside AS to reach destination
— Oldest EBGP route
— Lowest BGP router ID
• The network command in BGP operates differently than the network command
in IGPs.
Configuration Exercise #1: Configuring BGP Route Reflectors and Prefix List Filtering 413
Summary
In this chapter, you learned about problems that can occur when scaling IBGP, and you
learned about solutions to these problems, including route reflectors and prefix lists. You
also learned about three common ways of multihoming connections to the Internet.
Redistribution between BGP and an IGP was analyzed as well.
The next chapter discusses route redistribution in detail, including how information
between protocols can be controlled. Route maps are also discussed in the next chapter.
Configuration Exercise #1: Configuring BGP Route

Reflectors and Prefix List Filtering
completed the previous chapter’s exercises on your pod.
In this exercise, you will configure your pxr1 router as a router reflector and enable prefix
list filtering.
Objectives
In this exercise, you will complete the following tasks:
• Disable the Ethernet link between the pxr2 and pxr3 routers.
• Disable IBGP between pxr2 and pxr3.
• Enable pxr1 to be the route reflector for pxr2 and pxr3.
• Enable prefix list filtering on pxr1 to have an inbound prefix list to filter traffic from
the backbone_r1 router.
• Verify BGP connectivity.
Visual Objective
Figure 7-18 Configuring BGP Route Reflectors and Prefix List Filtering Configuration Exercise Visual Objective
EBGP
IBGP
AS 65200
backbone_r1 172.16.10.100/24
loopback 172.16.11.100/24
S1/0 S2/3
10.1.1.100/24 10.12.12.100/24
10.1.1.1/24 10.12.12.12/24
S3
....... S3
RR RR
S0 p1r1 S2 S0 p12r1 S2
192.168.1.17/28 S1 192.168.1.49/28 192.168.12.17/28 S1 192.168.12.49/28
192.168.1.33/28 192.168.12.33/28
Pod 1 192.168.12.18/28
Pod 12 192.168.12.50/28
192.168.1.18/28
S0 S1 192.168.1.50/28 S0 S0 S1 192.168.12.34/28 S0
192.168.1.34/28
p1r2 p1r3 p12r2 p12r3
loopback 192.168.101.101/24 loopback loopback loopback
172.26.1.17/28 192.168.112.112/24 172.26.12.17/28
172.26.1.33/28 172.26.12.33/28
172.26.1.49/28 172.26.12.49/28
AS 65101 AS 65112
Command List
In this exercise, you will use the commands in Table 7-7 listed in logical order. Refer to this
Table 7-7 Configuring BGP Route Reflectors and Prefix-List Filtering Configuration Exercise Command List
Command Description
no neighbor 192.168.x.65 remote-as 6510x Removes a BGP neighbor relationship
network 172.26.x.16 mask 255.255.255.240 Advertises pxr3 loopback interfaces
network 192.168.10x.0 mask 255.255.255.240 Advertises pxr2 loopback interfaces
neighbor 192.168.x.18 route-reflector-client Enables a route reflector
neighbor 10.x.x.100 prefix-list test in Enables prefix list filtering on incoming
updates from the BGP neighbor
ip prefix-list test permit 172.16.10.0/24 Permits routes with the prefix 172.16.10.0/24
clear ip bgp * Resets all BGP neighbors
show ip bgp Shows BGP information
Setup
To set up, do the following:
Step 1 At your pxr2 router, shut down the Ethernet 0 interface and remove the
IBGP neighbor statement to pxr3.
Step 2 At your pxr3 router, shut down the Ethernet 0 interface and remove the
IBGP neighbor statement to pxr2.
Task 1: Enabling pxr1 to Be the Route Reflector

Step 1 At your pxr3 router, enter the network statements to allow the
advertisement of the following loopback addresses that you created
during the OSPF exercise:
— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
(x is your pod number.)
At your pxr2 router, enter the network statement to allow the

advertisement of the following loopback address that you created during
the OSPF exercise:
— 192.168.10x.0/24
(x is your pod number.)
Step 2 From the pxr1 router, enter the show ip bgp command. Do you see the
following subnets displayed?
— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
— 192.168.10x.0/24
Examine the pxr1 IP routing table. Do you see the following subnets
displayed?
— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
— 192.168.10x.0/24
— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
— 192.168.10x.0/24
displayed?
— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
— 192.168.10x.0/24
— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
— 192.168.10x.0/24
displayed?
— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
— 192.168.10x.0/24
Step 5 From Steps 2, 3, and 4, you should be able to determine that because
there is no IBGP neighbor relationship between pxr2 and pxr3, pxr1 will
not by default propagate the IBGP routes learned from pxr2 to pxr3 or
from pxr3 to pxr2.
Configure the pxr1 router to allow the pxr1 router to be a router reflector
for pxr2 and pxr3.
Step 6 From the pxr2 router, enter the show ip bgp command.
Do you see the following subnets displayed?

— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
— 192.168.10x.0/24
displayed?
— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
— 192.168.10x.0/24
(Note that it may take a minute or so for the routes to appear.)
— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
— 192.168.10x.0/24
displayed?
— 172.26.x.16/28
— 172.26.x.32/28
— 172.26.x.48/28
— 192.168.10x.0/24
Step 8 From the pxr3 router, ping 192.168.10x.10x. From the pxr2 router, ping
172.26.x.17, 172.26.x.33, and 172.26.x.49.
Step 9 Telnet to the backbone_r1 router, using the password cisco. Ping
192.168.10x.10x, 172.26.x.17, 172.26.x.33, and 172.26.x.49.
NVRAM.
Task 2: Enabling an Inbound Prefix List

Step 1 At your pxr1 router, make sure that you can see both the 172.16.10.0 and
172.16.11.0 BGP routes from the backbone_r1 router.
Step 2 At your pxr1 router, configure an inbound prefix-list filter to only permit
prefix 172.16.10.0/24 to come in from the backbone_r1 router.
Step 3 Issue the clear ip bgp * command at your pxr1 router.
Step 4 Display the routing table of your pxr1 router to verify that your prefix list
is working.
Step 5 Remove the prefix list configuration.
Configuration Exercise #2: Configuring Multihomed BGP 419
Step 6 Issue the clear ip bgp * command on your pxr1 router.
NVRAM.
Completion Criteria
You have successfully completed this exercise if you correctly supplied the commands
required to configure your pxr1 router to act as the route reflector for your pxr2 and pxr3
routers, and to configure an inbound prefix list, and if you were able to correctly answer the
questions in the exercises. At the end of this exercise, all the routers should have full
connectivity to each other; each pod will be running IBGP internally with pxr1 as the route
reflector and will have EBGP connectivity to the backbone_r1 router.
Configuration Exercise #2: Configuring Multihomed

BGP
Complete the following exercise to configure multihomed BGP.
Objectives
In this exercise, you will complete the following steps:
• Configure an EBGP connection from your pxr3 router to the backbone_r2 router
(AS65201).
• Verify connectivity from your pod to AS 65201.
Visual Objective
NOTE Only one pod is shown in Figure 7-19 because of space restrictions.
Figure 7-19 Configuring Multihomed BGP Configuration Exercise Visual Objective
EBGP
IBGP
AS 65200
172.16.10.100/24
backbone_r1 loopback 172.16.11.100/24
S1/0
10.1.1.100/24
10.1.1.1/24
S3
.......
RR ...................
S0 p1r1 S2
192.168.1.17/28 S1 192.168.1.49/28 backbone_r2
.......
192.168.12.33/28
Pod 1 AS 65201
192.168.1.18/28
S0 S0 172.22.1.100/24
S1 192.168.1.50/28
192.168.1.34/28 S1/0
S1 loopback
p1r2 p1r3
172.22.1.1/24 172.31.20.100/24
loopback 192.168.101.101/24 loopback 172.31.21.100/24
172.26.1.17/28
172.26.1.33/28
172.26.1.49/28
AS 65101
Command List
In this exercise, you will use the commands listed in Table 7-8 in logical order. Refer to this
Table 7-8 Configuring Multihomed BGP Configuration Exercise Command List
Command Description
neighbor 172.22.x.100 remote-as 65201 Establishes BGP neighbor relationship
neighbor 192.168.x.49 next-hop-self Changes the next hop to be the router itself
show ip bgp Shows BGP information
show ip bgp neighbors Shows detailed BGP neighbor status
show ip bgp summary Shows BGP neighbor status
clear ip bgp * Resets all BGP neighbors
Task: Enabling a Second EBGP Connection

Step 1 At the pxr3 router, no shut the S1 interface that connects to the
backbone_r2 router.
Set the pxr3 S1 IP address to 172.22.x.x/24, where x is your pod number,
as shown in the following table.
Pod pxr3 S1 IP Address

1 172.22.1.1/24
2 172.22.2.2/24
3 172.22.3.3/24
4 172.22.4.4/24
5 172.22.5.5/24
6 172.22.6.6/24
7 172.22.7.7/24
8 172.22.8.8/24
9 172.22.9.9/24
10 172.22.10.10/24
11 172.22.11.11/24
12 172.22.12.12/24
From your pxr3 router, ping 172.22.x.100 to verify connectivity to the

backbone_r2 router.
Step 2 At the pxr3 router, use the neighbor statement to establish the
backbone_r2 router as an EBGP neighbor. (The backbone_r2 router is in
AS 65201.)
Step 3 At the pxr3 router, enter the show ip bgp summary and the show ip bgp
neighbors commands.
Wait until the neighbor state indicates established.
What is the BGP state of the backbone_r2 router?
How many prefixes have been learned from the backbone_r2 router?
Step 4 At your pxr3 router, enter the show ip bgp command.
Do you see a route to 172.31.20.0/24 and 172.31.21.0/24? Write down

the following information:
— Network
— Next hop
— Metric
— LocPrf
— Weight
— Path
Step 5 At your pxr3 router, ping 172.31.20.100 and 172.31.21.100.

Step 6 At your pxr1 router, enter the show ip bgp command. Do you see a route
to 172.31.20.0/24 and 172.31.21.0/24 (in AS 65201) directly from your
AS?
What is the next hop to get to 172.31.20.0/24 and 172.31.21.0/24 directly
to AS 65201 from your AS?
Examine your pxr1 IP routing table. Do you see a route to 172.31.20.0/
24 and 172.31.21.0/24 (in AS 65201) directly from your AS?
Step 7 Enable the next-hop-self options. At your pxr3 router, enter the BGP
configuration command to cause pxr3 to announce itself as the next-hop
router to pxr1.
Issue the clear ip bgp * command at pxr3 to reset the BGP sessions.
Step 8 At your pxr1 router, enter the show ip bgp command again. Do you see
a route to 172.31.20.0/24 and 172.31.21.0/24 (in AS 65201) directly
from your AS?
What is the next hop to get to 172.31.20.0/24 and 172.31.21.0/24 directly
from your AS?
Examine your pxr1 IP routing table. Do you see a route to 172.31.20.0/
24 and 172.31.21.0/24 (in AS 65201) directly from your AS?
From pxr1, ping 172.31.20.100 and 172.31.21.100.
Step 9 Examine your pxr2 IP routing table. Do you see a route to 172.31.20.0/
24 and 172.31.21.0/24 directly to AS 65201 from your AS?
From pxr2, ping 172.31.20.100 and 172.31.21.100.
Step 10 From pxr3, Telnet to the backbone_r2 router, using the password cisco.
Enter the show ip bgp command.
How many paths are available to subnet 172.16.10.0 and 172.16.11.0?
Which path is selected as the best path? (Note: You should see multiple
paths if more than one pod is configured properly.)
Display the IP routing table of the backbone_r2 router. In the routing
table, do you see only the best path to 172.16.10.0 and 172.16.11.0
published?
Exit the Telnet to the backbone_r2 router.
Step 11 If your pxr3 router connection to the backbone_r2 router fails, your pod
should still be capable of reaching AS 65201 by going through AS 65200
and AS 6510x (of another pod) if another pod is configured properly. Try
shutting down your S1 interface on your pxr3 router, and then try a trace
to 172.31.20.100. Which path are the trace probes taking from pxr3 to the
backbone_r2 router now?
No shut the S1 interface on your pxr3 router when you are finished.
NVRAM.
Bonus question: What is the order BGP will use to evaluate the following
BGP route attributes?
— MED
— Weight
— Shortest AS path
— Local preference
Completion Criteria
You have successfully completed this exercise if you correctly supplied the commands
required to configure EBGP connectivity from your pxr3 router to the backbone_r2 router,
and if you were able to correctly answer the questions in the exercises. At the end of this
exercise, all of the routers should have full connectivity to each other; each pod will be
running IBGP internally with pxr1 as the route reflector and will have EBGP connectivity
to both of the backbone routers.
PART
III
Controlling Scalable
Internetworks
Chapter 8 Optimizing Routing Update Operation
Chapter 9 Implementing Scalability Features in Your Internetwork

This chapter discusses different ways to control routing update information. It includes the
following sections:
• Redistribution Among Multiple Routing Protocols
• Configuring Redistribution
• Controlling Routing Update Traffic
• Verifying Redistribution Operation
• Policy-Based Routing Using Route Maps
• Verifying Policy-Based Routing
• Case Study: Redistribution
• Summary
• Configuration Exercise #1: Configuring Policy-Based Routing
• Configuration Exercise #2: Configuring Route Redistribution Between OSPF and
EIGRP
• Configuration Exercise #1 Answers: Configuring Policy-Based Routing
• Configuration Exercise #2 Answers: Configuring Route Redistribution Between
OSPF and EIGRP
• Review Questions
CHAPTER
8
Optimizing Routing Update
Operation
This chapter covers how to use route redistribution to interconnect networks that use
multiple routing protocols. After completing this chapter, you will be able to select and
configure different ways to control route update traffic, configure route redistribution in
networks that do and do not have redundant paths, resolve path selection problems, and
verify route redistribution. You will also be able to elaborate on policy-based routing using
route maps. Given a set of network requirements, you will be able to configure
redistribution between different routing domains, configure policy-based routing, and
verify proper operation (within described guidelines) of your routers.
Redistribution Among Multiple Routing Protocols

Thus far in this book, you have seen networks that use a single routing protocol. Sometimes,
however, you will need to use multiple routing protocols. The following are possible
reasons why you may need multiple protocols:
• You are migrating from an older Interior Gateway Protocol (IGP) to a new IGP.
Multiple redistribution boundaries may exist until the new protocol has displaced the
old protocol completely.
• You want to use another protocol but need to keep the old protocol because of the
needs of host systems.
• Different departments might not want to upgrade their routers, or they might not
implement a sufficiently strict filtering policy. In these cases, you can protect yourself
by terminating the other routing protocol on one of your routers.
• If you have a mixed-router vendor environment, you can use a Cisco-specific protocol
in the Cisco portion of the network, and then use a common protocol to communicate
with non-Cisco devices.
What Is Redistribution?
When any of the previous situations arise, Cisco routers allow internetworks using different
routing protocols (referred to as autonomous systems) to exchange routing information
through a feature called route redistribution. Redistribution is defined as the capability for
454 Chapter 8: Optimizing Routing Update Operation
boundary routers connecting different autonomous systems to exchange and advertise

routing information received from one autonomous system to the other autonomous
system.
NOTE The term autonomous system as used here denotes internetworks using different routing
protocols. These routing protocols may be IGPs and/or Exterior Gateway Protocol (EGPs).
This is a different use of the term autonomous system than when discussing the Border
Gateway Protocol (BGP).
Within each autonomous system, the internal routers have complete knowledge about their
network. The router interconnecting autonomous systems is called a boundary router.
In Figure 8-1, AS 200 is running the Interior Gateway Routing Protocol (IGRP), and AS
300 is running the Enhanced Interior Gateway Routing Protocol (EIGRP). The internal
routers within each autonomous system have complete knowledge about their networks.
Router A is the boundary router. Router A has both IGRP and EIGRP processes active, and
is responsible for advertising routes learned from one autonomous system into the other
autonomous system.
Router A learns about network 192.168.5.0 from Router B via the EIGRP protocol running
on its S0 interface. It passes (redistributes) that information to Router C on its S1 interface
via IGRP. Routing information is also passed (redistributed) the other way, from IGRP into
EIGRP.
Figure 8-1 Redistribution Between an IGRP AS and an EIGRP AS
Boundary
router
AS 200 AS 300
IGRP S1 S0 EIGRP
172.16.0.0 C B 192.168.5.0
A
IP routing table S1 advertises routes from IP routing table

EIGRP to IGRP
I 192.168.5.0 D EX 172.16.0.0
I 172.16.1.0 D 192.168.5.8
I 172.16.2.0 S0 advertises routes from D 192.168.5.16
I 172.16.3.0 IGRP to EIGRP D 192.168.5.24
Router B’s routing table shows that it has learned about network 172.16.0.0 via EIGRP (as
indicated by the “D” in the routing table) and that the route is external to this autonomous
Redistribution Among Multiple Routing Protocols 455
system (as indicated by the “EX” in the routing table). Router C’s routing table shows that
it has learned about network 192.168.5.0 via IGRP (as indicated by the “I” in the routing
table). Note that, unlike EIGRP, there is no indication in IGRP of whether the route is
external or internal to the autonomous system.
Note that, in this case, the routes that are exchanged are summarized on the network class
boundary. Recall from the route summarization discussion in Chapter 1, “Routing
Principles,” and Chapter 2, “Extending IP Addresses,” that EIGRP and IGRP automatically
summarize routes on the network class boundary.
Redistribution Considerations
Redistribution, although powerful, increases the complexity and potential for routing
confusion, so it should be used only when absolutely necessary. The key issues that arise
when using redistribution are as follows:
• Routing feedback (loops)—Depending on how you employ redistribution—for
example, if more than one boundary router is performing route redistribution—
routers can send routing information received from one autonomous system back into
that same autonomous system. The feedback is similar to the routing loop problem
that occurs in distance vector technologies.
• Incompatible routing information—Because each routing protocol uses different
metrics to determine the best path—for example, the Routing Information Protocol
(RIP) uses hops, and Open Shortest Path First (OSPF) uses cost—path selection using
the redistributed route information may not be optimal. Because the metric
information about a route cannot be translated exactly into a different protocol, the
path that a router chooses may not be the best.
• Inconsistent convergence time—Different routing protocols converge at different
rates. For example, RIP converges more slowly than EIGRP, so if a link goes down,
the EIGRP network will learn about it before the RIP network.
To understand why some of these problems may occur, you must first understand how Cisco
routers select the best path when more than one routing protocol is running, and how they
convert the metrics used when importing routes from one autonomous system into another.
These topics are discussed in the following sections.
Selecting the Best Route

Most routing protocols have metric structures and algorithms that are not compatible with
other protocols. In a network in which multiple routing protocols are present, the exchange
of route information and the capability to select the best path across the multiple protocols
is critical. For routers to select the best path when they learn two or more routes to the same
destination from different routing protocols, Cisco uses the following two parameters:
• Administrative distance—As covered in Chapter 1, administrative distance is used

to rate the believability of a routing protocol. Each routing protocol is prioritized
in order of most to least believable (or reliable or trustworthy) using a value called
administrative distance. This criterion is the first that a router uses to determine which
routing protocol to believe if more than one protocol provides route information for
the same destination.
• Routing metric—The metric is a value representing the path between the local router
and the destination network. The metric is usually a hop or cost value, depending on
the protocol being used.
Administrative Distance
Table 8-1 lists the default believability (administrative distance) of protocols supported by
Cisco. For example, if a router received a route to network 10.0.0.0 from IGRP and then
received a route to the same network from OSPF, the router would use the administrative
distance to determine that IGRP is more believable and would add the IGRP version of the
route to the routing table.
Table 8-1 Default Administrative Distances of Routing Protocols
Routing Protocols Administrative Distance Value
Connected interface 0
Static route out an interface 0
Static route to a next hop 1
EIGRP summary route 5
External BGP 20
Internal EIGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP version 1, version 2 120
EGP 140
External EIGRP 170
Internal BGP 200
Unknown 255
When using route redistribution, you may occasionally need to modify the administrative
distance of a protocol so that it will be preferred. For example, if you want the router to
select RIP-learned routers rather than IGRP-learned routes to the same destination, you
Redistribution Among Multiple Routing Protocols 457
must increase the administrative distance for IGRP or decrease the administrative distance
for RIP.
Modifying the administrative distance is discussed in the section “Controlling Routing
Update Traffic,” later in this chapter.
Seed Metric
After the most believable protocol is determined for each destination and the routes are
added to the routing table, a router may advertise the routing information to other protocols,
if configured to do so. If the router was advertising a link directly connected to one of its
interfaces, the initial or seed metric used would be derived from the characteristics of that
interface, and the metric would increment as the routing information passed to other
routers.
However, redistributed routes are not physically connected to a router, they are learned
from other protocols. If a boundary router wants to redistribute information between
routing protocols, it must be capable of translating the metric of the received route from the
source routing protocol into the other routing protocol. For example, if a boundary router
receives a RIP route, the route will have hop count as a metric. To redistribute the route into
OSPF, the router must translate the hop count into a cost metric that will be understood by
other OSPF routers. This cost metric, referred to as the seed or default metric, is defined
during configuration.
When the seed metric for a redistributed route is established, the metric will increment
normally within the autonomous system. (The exception to this is OSPF E2 routes, as
discussed in Chapter 4, “Interconnecting Multiple OSPF Areas,” which hold their default
metric regardless of how far they are propagated across an autonomous system.)
When configuring a default metric for redistributed routes, the metric should be set to a
value larger than the largest metric within the receiving autonomous system to help prevent
routing loops.
Configuring default metrics is discussed in the section “Controlling Routing Update
Traffic,” later in this chapter.
Protocol Support for Redistribution

All protocols are supported by redistribution. Before implementing redistribution, consider
the following points:
• You can redistribute only protocols that support the same routed protocol stack. For
example, you can redistribute between IP RIP and OSPF because they both support
the TCP/IP stack. However, you cannot redistribute between Internetwork Packet
Exchange (IPX) RIP and OSPF because IPX RIP supports the IPX/Sequenced Packet
Exchange (SPX) stack and OSPF does not.
• How you configure redistribution varies among protocols and among combinations of
protocols. For example, redistribution occurs automatically between IGRP and
EIGRP when they have the same autonomous system number, but it must be
configured between EIGRP and RIP.
Because EIGRP supports multiple routing protocols, it can be used to redistribute with IP,
IPX, and AppleTalk routing protocols (within the same routed protocol stack). Consider the
following when redistributing EIGRP with these protocols:
• In the IP environment, IGRP and EIGRP have a similar metric structure, so
redistribution is straightforward. For migration purposes, when IGRP and EIGRP are
both running in the same autonomous system, redistribution is automatic. When
redistributing between different autonomous systems, redistribution must be
configured for EIGRP, just as it is required for IGRP.
• All other IP routing protocols, both internal and external, require that redistribution
be configured to communicate with EIGRP.
• By design, EIGRP automatically redistributes route information with Novell RIP.
Beginning with Cisco IOS Release 11.1, EIGRP can be configured to redistribute
route information with the NetWare Link Services Protocol (NLSP).
• By design, EIGRP also automatically redistributes route information with AppleTalk
RTMP.
Configuring Redistribution
Configuring route redistribution can be very simple or very complex, depending on the mix
of protocols that you want to redistribute. The commands used to enable redistribution and
assign metrics vary slightly depending on the protocols being redistributed. The following
steps are generic enough to apply to virtually all protocol combinations. However, the
commands used to implement the steps may vary. It is highly recommended that you review
the Cisco IOS documentation for the configuration commands that apply to the specific
protocols that you want to redistribute.
NOTE In this section, the terms core and edge are generic terms used to simplify the discussion
about redistribution.
Step 1 Locate the boundary router(s) on which redistribution needs to be

configured.
Step 2 Determine which routing protocol is the core or backbone protocol.
Usually this is OSPF or EIGRP.
Configuring Redistribution 459
Step 3 Determine which routing protocol is the edge or short-term (if you are
migrating) protocol.
Step 4 Access the routing process into which you want routes redistributed.
Typically, you start with the backbone routing process. For example, to
access OSPF, do the following:
router(config)#router ospf process-id
Step 5 Configure the router to redistribute routing updates from the edge
protocol into the backbone protocol. This command varies, depending on
the protocols.
Redistributing into OSPF

The following command, explained in Table 8-2, is used for redistributing updates into
OSPF:
router(config-router)#redistribute protocol [process-id] [metric metric-value]
[metric-type type-value] [route-map map-tag] [subnets] [tag tag-value]
Table 8-2 redistribute Command Options for OSPF
Command Description
protocol Source protocol from which routes are being redistributed. It can be
one of the following keywords: connected, bgp, eigrp, egp, igrp, isis,
iso-igrp, mobile, odr, ospf, static, or rip.
process-id For BGP, EGP, EIGRP, or IGRP, this is an autonomous system
number. For OSPF, this is an OSPF process ID.
metric-value Optional parameter used to specify the metric used for the
redistributed route. When redistributing into OSPF, the default metric
is 20. Use a value consistent with the destination protocol—in this
case, the OSPF cost.
type-value Optional OSPF parameter that specifies the external link type
associated with the default route advertised into the OSPF routing
domain. This value can be 1 for type 1 external routes, or 2 for type 2
external routes. The default is 2.
map-tag Optional identifier of a configured route map to be interrogated to
filter the importation of routes from this source routing protocol to the
current routing protocol. Route maps are covered later in this chapter
in the section “Policy-Based Routing Using Route Maps.”
subnets Optional OSPF parameter that specifies that subnetted routes should
also be redistributed. Only routes that are not subnetted are
redistributed if the subnets keyword is not specified.
tag-value Optional 32-bit decimal value attached to each external route. This is
not used by the OSPF protocol itself. It may be used to communicate
information between autonomous system boundary routers.
Redistributing into EIGRP

The following command, explained in Table 8-3, is used for redistributing updates into
EIGRP:
router(config-router)#redistribute protocol [process-id]
[match {internal | external 1 | external 2}]
[metric metric-value] [route-map map-tag]
Table 8-3 Redistribute Command Options for EIGRP
Command Description
protocol Source protocol from which routes are being redistributed. It can be
one of the following keywords: connected, bgp, eigrp, egp, igrp, isis,
iso-igrp, mobile, odr, ospf, static, or rip.
process-id For BGP, EGP, EIGRP or IGRP, this is an autonomous system number.
For OSPF, this is an OSPF process ID.
match For OSPF, the optional criteria by which OSPF routes are redistributed
into other routing domains. It can be one of the following:
internal: Redistribute routes that are internal to a specific autonomous
system.
external 1: Redistribute routes that are external to the autonomous
system but that are imported into OSPF as a type 1 external route.
external 2: Redistribute routes that are external to the autonomous
system but that are imported into OSPF as a type 2 external route.
metric-value Optional parameter used to specify the metric used for the
redistributed route. When redistributing into protocols other than
OSPF (including this case into EIGRP), if this value is not specified
and no value is specified using the default-metric router configuration
command, the default metric is 0 and routes may not be redistributed.
Use a value consistent with the destination protocol (see the
description of the default metric command in this section for a
description of the EIGRP metric).
map-tag Optional identifier of a configured route map to be interrogated to filter
the importation of routes from this source routing protocol to the
current routing protocol. Route maps are covered later in this chapter
in the section “Policy-Based Routing Using Route Maps.”
Defining the Default Metric

You can affect how routes are redistributed by changing the default metric associated with
a protocol. Perform the following steps to change the default metric:
Step 1 Define the default seed metric that the router uses when redistributing
routes into a routing protocol.
When redistributing into IGRP or EIGRP, use the following command,

explained in Table 8-4, to set the seed metric:
Router(config-router)#default-metric bandwidth delay reliability
loading mtu
NOTE You can specify the default metric with the default-metric command, or use the metric
parameters in the redistribute command.
If you use the default-metric command, the default metric that you specified will apply to
all protocols being redistributed in.
If you use the default-metric parameters in the redistribute command, you can set a
different default metric for each protocol being redistributed in.
Table 8-4 default-metric Command for IGRP and EIGRP

Command Description
bandwidth Minimum bandwidth of the route, in kilobits per second (kbps).
delay Route delay, in tens of microseconds.
reliability Likelihood of successful packet transmission expressed in a number
from 0 to 255, where 255 means that the route is 100-percent reliable.
loading Effective loading of the route expressed in a number from 1 to 255,
where 255 means that the route is 100-percent loaded.
mtu Maximum transmission unit (MTU). The maximum packet size along
the route in bytes; an integer greater than or equal to 1.
When redistributing into OSPF, RIP, EGP, and BGP, use the following
command for setting the seed metric, as explained in Table 8-5.
Router(config-router)#default-metric number
Table 8-5 default-metric Command for OSPF, RIP, EGP, and BGP
Command Description
number The value of the metric, such as the number of hops for RIP
Step 2 Exit the routing process.

Cofiguring Redistribution into Edge Protocol

Step 1 Enter configuration mode for the other routing process, usually the edge
or short-term process.
Step 2 Depending on your network, this configuration will vary because you
want to employ some techniques to reduce routing loops. For example,
you may do any of the following:
— Redistribute a default route about the core autonomous system into
the edge autonomous system.
— Redistribute multiple static routes about the core autonomous
system into the edge autonomous system.
— Redistribute all routes from the core autonomous system into the
edge autonomous system, and then assign a distribution filter to
filter out inappropriate routes.
— Redistribute all routes from the core autonomous system into the
edge autonomous system, and then modify the administrative
distance associated with the received routes so that they are not the
selected routes when multiple routes exist for the same destination.
In some cases, the route learned by the native protocol is better but
may have a less believable administrative distance. Refer to the
section “Redistribution Example Using the distance Command,”
later in this chapter, for an example of this scenario.
Redistribution of static and default information is discussed in the following sections.
Filtering and changing the administrative distance are discussed in the section “Controlling
Routing Update Traffic,” later in this chapter.
The passive-interface Command

The passive-interface command can be used in conjunction with redistribution. It prevents
all routing updates for a given routing protocol from being sent into a network, but it does
not prevent the specified interface from receiving updates.
When using the passive-interface command in a network using a link-state routing
protocol or EIGRP, the command prevents the router from establishing a neighbor
adjacency with other routers connected to the same link as the one specified in the
command. An adjacency cannot be established because the Hello protocol is used to verify
bidirectional communication between routers. If a router is configured to not send updates,
it cannot participate in bidirectional communication.
NOTE During testing with debug commands, it was found that OSPF does send Hello and DBD
packets on passive interfaces, but does not send LSUs. EIGRP does not send anything on
passive interfaces.
To configure a passive interface, regardless of the routing protocol, do the following:

Step 1 Select the router and routing protocol that requires the passive interface.
Step 2 Determine which interfaces you do not want routing update traffic to be
sent through.
Step 3 Configure using the passive-interface command, as shown in Table 8-6.
router(config-router)#passive-interface type number
Table 8-6 passive-interface Command
Command Description
type number Type of interface and interface number that will not send
routing updates
NOTE This capability is typically used in conjunction with other capabilities, as you will see later
in this chapter.
Static and Default Routes

Static routes are routes that you can manually configure on the router. Static routes are used
most often to do the following:
• Define specific routes to use when two autonomous systems must exchange routing
information, rather than having entire routing tables exchanged
• Define routes to destinations over a WAN link to eliminate the need for a dynamic
routing protocol—that is, when you do not want routing updates to enable or cross the
link
The commands to configure static routes for IP and their use are discussed in the following
steps:
Step 1 Determine which networks you want defined as static. For example, if
you are configuring static routes on a WAN router that is connecting to a
branch office, you probably want to select the networks at the branch
office.
Step 2 Determine the next-hop router to the destination networks, or the local
router’s interface that connects to the remote router.
Step 3 Configure the static route on each router. For IP, use the ip route
router(config)#ip route prefix mask {address|interface} [distance ]
[tag tag] [permanent]
Table 8-7 ip route Command to Configure Static Routes
Command Description
prefix The route prefix for the destination.
mask The prefix mask for the destination.
address The IP address of the next-hop router that can be used to reach that
network.
interface The network interface to use to get to the destination network.
distance Optional administrative distance to assign to this route. (Recall that
administrative distance refers to how believable the routing protocol is.)
tag Optional value that can be used as a match value in route maps.
permanent Specification that the route will not be removed even if the interface
associated with the route goes down.
NOTE Static routes pointing to an interface should be used only on point-to-point interfaces
because on other interfaces the router will not know the specific address to which to send
the information. On point-to-point interfaces, the information will be sent to the only other
device on the network.
Example 8-1 demonstrates a static route configured on Router p1r2, shown in Figure 8-2.
Router p1r2 will use its interface serial 1 to get to network 172.16.0.0/16. As shown in the
routing table for Router p1r2 of Example 8-1, static routes pointing to an interface are
treated as directly connected networks.
Figure 8-2 Redistribution Scenario
10.1.0.0
p1r2
p2r2
172.16.0.0
Example 8-1 Static Route Configuration on plr2 in Figure 8-2

router rip
passive-interface Serial1
network 10.0.0.0
!
ip route 172.16.0.0 255.255.0.0 Serial1
p1r2#sh ip route
<Output Omitted>
10.0.0.0 255.255.255.0 is subnetted, 2 subnets

S 172.16.0.0 is directly connected, Serial1
<Output Omitted>
When configuring static routes, keep in mind the following considerations:

• When using static routes instead of dynamic routing updates, all participating routers
must have static routes defined so that they can advertise their remote networks. Static
route entries must be defined for all routes for which a router is responsible. To reduce
the number of static route entries, you can define a default static route—for example,
ip route 0.0.0.0 0.0.0.0 s1. When using RIP, default static routes (0.0.0.0 0.0.0.0) are
advertised (redistributed) automatically.
• If you want a router to advertise a static route in a routing protocol, you may need to
redistribute it.
Cisco lets you configure default routes for protocols. For example, when you create a
default route on a router running RIP, the router advertises an address of 0.0.0.0. When a
router receives this default route, it will forward any packets destined for a destination that
does not appear in its routing table to the default route you configured.
You can also configure a default route by using the ip default-network command,
explained in Table 8-8. An example of the use of the default-network command on a router
running RIP is shown in Figure 8-3 and in Examples 8-2 and 8-3. With the ip default-
network command, you designate an actual network currently available in the routing table
as the default path to use.
Figure 8-3 Using the default-network Command
10.64.0.2/24
172.31.0.0/24
10.1.0.0/24
p1r3 p2r2
10.64.0.1/24
In Examples 8-2 and 8-3, the p2r2 router has a directly connected interface onto the
network specified in the ip default-network network-number command. RIP will generate
(or source) a default route, which will appear as a 0.0.0.0 0.0.0.0 route to its RIP neighbor
routers.
Example 8-2 Configuration on Router p2r2
router rip
network 10.0.0.0
network 172.31.0.0
!
ip classless
ip default-network 10.0.0.0
Example 8-3 Routing Table of p1r3

<Output Omitted>
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
<Output Omitted>
R 10.2.3.0/24 [120/1] via 10.64.0.2, 00:00:05, Ethernet0
C 10.64.0.0/24 is directly connected, Ethernet0
R 172.31.0.0/16 [120/1] via 10.64.0.2, 00:00:16, Ethernet0
R* 0.0.0.0/0 [120/1] via 10.64.0.2, 00:00:05, Ethernet0
Table 8-8 ip default-network Command

Command Description
network-number The number of the destination network
NOTE The ip default-network command is used as a method of distributing default route

information to other routers. This command provides no functionality for the router on
which it is configured.
Other protocols behave differently than RIP with the ip route 0.0.0.0 0.0.0.0 and ip
default-network commands. For example, EIGRP will not redistribute the 0.0.0.0 0.0.0.0
default route by default. However, if the network 0.0.0.0 command is added to the EIGRP
configuration, it will redistribute a default route as the result of the ip route 0.0.0.0 0.0.0.0
command, but not as the result of the ip default-network command. Refer to the Cisco IOS
documentation for further information.
ip default-network Usage
The ip default-network command is used when routers do not know how to get to the
outside world. This command is configured at the router that connects to the outside world,
and this router goes through a different major network to reach the outside world. If your
environment is all one major network address, you would probably not want to use the
default-network command, but rather a static route to 0.0.0.0 via a border router.
The ip route 0.0.0.0 command is used on routers with IP routing enabled that point to the
outside world for Internet connectivity. This route is advertised as “gateway of last resort”
if running RIP. The router that is directly connected to the border of the outside world would
be the preferred router with the static route pointing to 0.0.0.0.
The ip default-gateway command is used on routers or communication servers that have
IP routing turned off. The router or communication server acts just like a host on the
network.
The following is an example of how you can redistribute in one direction and use a default
route in the other direction instead of redistributing in both directions.
Figure 8-4 illustrates an internetwork that uses three autonomous systems. In this case,
OSPF is the core protocol and RIP is the edge protocol. This section illustrates how to do
the following:
• Allow the OSPF backbone to know all the routes in each autonomous system. This is
done by configuring redistribution on the boundary routers so that all RIP routes are
redistributed into OSPF.
• Allow the RIP autonomous systems to know only about their internal routes, and use
a default route to the external networks. This is done by configuring a default route on
the boundary routers. The boundary routers will advertise the default route into the
RIP. The boundary routers are running both RIP and OSPF, and are redistributing RIP
routes into OSPF. They will have all the RIP and OSPF routes in their routing table.
NOTE This redistribution example shows one way to configure redistribution. Many other ways
exist, so you must understand your network topology and requirements to choose the best
solution.
Figure 8-4 OSPF as the Core Routing Protocol and RIP as the Edge
S1:10.1.1.1/24
P1R1
S0:10.1.2.1/24 S1:10.1.2.2/24
S0:10.1.1.2/24
E0:172.16.31.5/24
P1R2 P1R3
S1:10.1.3.1/24
S0:10.1.3.2/24 S1:10.2.1.1/24
RIP
OSPF P2R1
S0:10.2.2.1/24
S1:10.2.2.2/24
S0:10.2.1.2/24
E0:172.16.31.6/24
P2R2 P2R3
S1:10.2.3.1/24 S0:10.2.3.2/24
RIP
Example 8-4 and Example 8-5 illustrate the configurations of a RIP internal router and of
a boundary router, as shown in Figure 8-4. Points about each configuration are as follows:
• Internal RIP router (p1r1), Example 8-4—No redistribution configuration is
necessary because this router is only running the RIP protocol. The intent is not to
have this router learn about external routes.
The ip classless command is required on all RIP/IGRP routers that must use
a default route to get to other subnets of network 10.0.0.0 (for example, for
p1r1 to get to the 10.2.x.0 subnets). This command allows the IOS to forward
packets that are destined for unrecognized subnets of directly connected
networks to the best supernet route, which may be the default route. When
this feature is disabled, the software discards the packets if the router
receives packets for a subnet that numerically falls within its subnetwork
addressing scheme, but there is no such subnet number in the routing table.
Example 8-4 Configuration of Internal Router p1r1
interface Serial0
ip address 10.1.2.1 255.255.255.0
bandwidth 64
!
interface Serial1
ip address 10.1.1.1 255.255.255.0
clockrate 56000
!
<Output Omitted>
!
router rip
network 10.0.0.0
!
ip classless
<Output Omitted>
NOTE The ip classless command is on by default in Cisco IOS Release 12.0; it is off by default in
earlier releases.
• Boundary router (p1r3), Example 8-5—When redistributing into OSPF, you need
the subnets keyword so that subnetted networks (along with nonsubnetted networks)
will be redistributed into OSPF.
Define the default network to be advertised to the edge protocols.
The ip classless command is not needed on the boundary router because it is
running OSPF. The command is shown in the configuration because it is on
by default in Cisco IOS Release 12.0
Example 8-5 Configuration of Boundary Router p1r3

<Output Omitted>
!
router ospf 200
redistribute rip metric 30 subnets
network 172.6.31.5 0.0.0.0 area 0
!
router rip
network 10.0.0.0
!
ip classless
ip default-network 10.0.0.0
!
<Output Omitted>
For comparison’s sake, Example 8-6 shows the routing table of the p1r3 boundary router
before redistribution.
Example 8-6 Routing Table of Boundary Router Before Redistribution
P1R3#show ip route
<Output Omitted>

R 10.1.1.0 [120/1] via 10.1.3.1, 00:00:16, Serial0
[120/1] via 10.1.2.1, 00:00:28, Serial1
Notice that in this routing table output, the 10.2.x.0/24 subnetworks do not appear. They
appear after redistribution is configured on p2r2 (the other boundary router).
Example 8-7 illustrates p1r3 after redistribution was enabled on both boundary routers.
Example 8-7 Routing Table of Boundary Router After Redistribution
P1R3#show ip route
* 10.0.0.0/24 is subnetted, 6 subnets

O E2 10.2.1.0 [110/30] via 172.6.31.6, 00:44:56, Ethernet0
R 10.1.1.0 [120/1] via 10.1.3.1, 00:00:05, Serial0
[120/1] via 10.1.2.1, 00:00:17, Serial1
O E2 10.2.2.0 [110/30] via 172.16.31.6, 00:44:56, Ethernet0
O E2 10.2.3.0 [110/30] via 172.16.31.6, 00:44:56, Ethernet0
Controlling Routing Update Traffic 471
Example 8-8 illustrates one of the internal routing tables after the default route was
configured on the boundary router using the ip default-network command.
Example 8-8 Routing Table of Internal Router After Redistribution
P1R1#show ip route
<Output Omitted>

R 10.1.3.0 [120/1] via 10.1.1.2, 00:00:24, Serial1
[120/1] via 10.1.2.2, 00:00:10, Serial0
R* 0.0.0.0/0 [120/1] via 10.1.2.2, 00:00:10, Serial0
Using the default route shown in Example 8-8, p1r1 can successfully ping any network in
the other RIP autonomous system, as shown in Example 8-9.
Example 8-9 Internal Router Pinging a Destination in Another Autonomous System
P1R1#ping 10.2.2.1

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
P1R1#
Controlling Routing Update Traffic

At a high level, Cisco recommends that you consider employing the following guidelines
when using redistribution:
• Be familiar with your network and your network traffic—This is the overriding
recommendation. There are many ways to implement redistribution, so knowing your
network will enable you to make the best decision.
• Do not overlap routing protocols—Do not run two different protocols in the same
internetwork. Instead, have distinct boundaries between networks that use different
protocols.
• One-way redistribution—To avoid routing loops and problems with varying
convergence time, allow routes to be exchanged in only one direction, not both
directions. In the other direction, you should consider using a default route.
• Two-way redistribution—If you must allow two-way redistribution, enable a
mechanism to reduce the chances of routing loops. Examples of mechanisms covered
in this chapter are default routes, route filters, and modification of the metrics
advertised. With these types of mechanisms, you can reduce the chances of routes
imported from one autonomous system being reinjected into the same autonomous
system as new route information if more than one boundary router is performing two-
way redistribution.
Thus far, you have seen a variety of routing protocols and how they propagate routing
information throughout an internetwork. Sometimes, however, you do not want routing
information propagated, for example:
• When using an on-demand WAN link—You may want to minimize, or stop entirely,
the exchange of routing update information across this type of link. Otherwise, the
link will remain up constantly.
• When you want to prevent routing loops—Many companies have large enough
networks that redundant paths are prominent. In some cases, for example, when a path
to the same destination is learned from two different routing protocols, you may want
to filter the propagation of one of the paths.
This section discusses two ways that you can control or prevent routing update exchange
and propagation, as follows:
• Route update filtering—Use access lists to filter route update traffic about specific
networks.
• Changing administrative distance—Change the administrative distance to affect
which protocol the router believes.
Other methods of controlling traffic were presented earlier:
• Passive interface—Prevents all routing updates from being sent through an interface.
• Default routes—Instructs the router that if it does not have a route for a given
destination, it should send the packet to the default route.
• Static routes—Serves as a route to a destination that you configured in the router.
Using Route Filters

The Cisco IOS software can filter incoming and outgoing routing updates by using access
lists, as demonstrated in Figure 8-5. In general, the process used by the router is as follows:
Step 1 The router receives a routing update or is getting ready to send an update
about one or more networks.
Step 2 The router looks at the interface involved in the process. For example, if
it is an incoming update, then the interface on which it arrived is checked.
If it is an update that must be advertised, the interface out of which it
should be advertised is checked.
Step 3 The router determines whether a filter is associated with the interface.
Step 4 If a route filter is associated with the interface, the router views the access
list to learn whether there is a match for the given routing update.
If a route filter is not associated with the interface, the routing update
packet is processed as normal.
Step 5 If there is a match, the route entry is processed as configured (either
permitted or denied).
Step 6 If no match is found in the access list, the implicit deny any at the end of
the access list will cause the update to be dropped.
Figure 8-5 Data Flow of Routing Updates When Using Route Filters
Routing
update
Determine
Is there a Is there an Process entry
interface Yes Yes
filter for this entry for this according to filter
interface? address? configuration
No No
Process packet Drop packet End

normally
End
NOTE Filtering routing updates is also discussed in Chapter 7, “Implementing BGP in Scalable
Networks,” for the Border Gateway Protocol (BGP). The ideas here are the same, although
the commands used are different than those used for BGP.
You can filter routing update traffic for any protocol by defining an access list and applying
it to a specific routing protocol. To configure a filter, do the following:
Step 1 Identify the network addresses that you want to filter, and create an
access list.
Step 2 Determine whether you want to filter them on an incoming or outgoing
interface.
Step 3 To assign the access list to filter outgoing routing updates, use the
distribute-list out command, as detailed in Table 8-9.
router(config-router)#distribute-list {access-list-number | name } out
[interface-name | routing-process [autonomous-system-number]
Table 8-9 distribute-list out Command
Command Description
access-list-number | name Gives the standard access list number or name.
out Applies the access list to outgoing routing updates.
interface-name Gives the optional interface name out which updates will
be filtered.
routing-process Gives the optional name of the routing process, or the
keywords static or connected, from which updates will
be filtered.
autonomous-system-number Gives the optional autonomous system number of the
routing process.
NOTE OSPF outgoing updates cannot be filtered out of an interface.
To assign the access list to filter incoming routing updates, use the distribute-list in
router(config-router)#distribute-list {access-list-number | name }
in [type number]
Table 8-10 distribute-list in Command
Command Description
access-list-number | name Gives the standard access list number or name.
in Applies the access list to incoming routing updates.
type number Gives the optional interface type and number from which
updates will be filtered.
IP Route Filtering Configuration Example

Figure 8-6 provides the topology of a WAN in which network 10.0.0.0 must be hidden from
network 192.168.5.0.
Figure 8-6 Network 10.0.0.0 Needs to Be Hidden from Network 192.168.5.0
S0 192.168.5.0
B
172.16.0.0
A
10.0.0.0
Example 8-10 shows that the distribute-list out command applies access list 7 to outbound
packets. The access list allows only routing information about network 172.16.0.0 to be
distributed out the S0 interface of Router B. As a result, network 10.0.0.0 is hidden.
Example 8-10 Filtering Out Network 10.0.0.0 on Router B in Figure 8-6
router eigrp 1
network 172.16.0.0
network 192.168.5.0
distribute-list 7 out s0
!
NOTE Another way of achieving the filtering out of network 10.0.0.0 would have been by denying
network 10.0.0.0 and permitting any other networks. This method would have been
particularly efficient if the routing information contained multiple networks, but only
network 10.0.0.0 needed filtering out.
Table 8-11 describes some of the commands shown in Example 8-10.

Table 8-11 Redistribution Commands
Command Description
distribute-list 7 out s0 Applies access list 7 as a route redistribution filter on EIGRP
routing updates sent on interface serial 0.
access list 7 Gives the access list number.
permit Enables routes matching the parameters to be forwarded.
172.16.0.0 0.0.255.255 Gives the network number and wildcard mask used to qualify source
addresses. The first two address octets must match, and the rest are
masked.
IP Static Route Filtering Configuration Example

Figure 8-7 provides the topology used to demonstrate IP static route filtering in
Example 8-11.
Figure 8-7 IP Static Route Filtering
192.168.7.4 192.168.7.8
172.16.0.0 S0 S0 10.0.0.0
A B C
192.168.7.12 192.168.7.16
passive-interface s0 passive-interface s0
D E
Example 8-11 shows a static route being redistributed and filtered into EIGRP. The 10.0.0.0
route is passed to Routers D and E. The static route to 172.16.0.0 is filtered (denied by the
implicit deny at the end of the access list). In Figure 8-7, network 192.168.7.0 is subnetted
with 30 bits (255.255.255.252)—subnets 192.168.7.16, 192.168.7.12, 192.168.7.8, and
192.168.7.4. Also, Router A and Router C have their serial interfaces set as passive
interfaces, so no dynamic routing updates are sent out. Therefore Router B will use its static
routes to reach networks 10.0.0.0 and 172.16.0.0.
Example 8-11 Configuration of Router B
ip route 10.0.0.0 255.0.0.0 192.168.7.9
ip route 172.16.0.0 255.255.0.0 192.168.7.5
!
router eigrp 1
network 192.168.7.0
default-metric 10000 100 255 1 1500
redistribute static
distribute-list 3 out static
!

Table 8-12 Commands Used in Example 8-11
Command Description
ip route 10.0.0.0 255.0.0.0 192.168.7.9
10.0.0.0 255.0.0.0 Defines the IP address and subnet mask of the destination
network.
Table 8-12 Commands Used in Example 8-11 (Continued)

Command Description
192.168.7.9 Defines the next-hop address to use to reach the destination (in
this case, Router C’s S0 interface).
redistribute static Assigns routes learned from static entries in the routing table to be
redistributed into EIGRP.
distribute-list 3 out Filters routes learned from static entries by using access list 3,
static before those routes are passed to the EIGRP process.
access-list 3 Shows that the access list is list number 3.
permit Enables routes that match the parameters to be advertised.
10.0.0.0 0.255.255.255 Enables packets about IP addresses that match the first octet of
10.0.0.0 to be forwarded.
NOTE Configure static route redistribution on one router only to eliminate the possibility of
routing loops created by static route redistribution on routers with parallel routes between
networks.
Modifying Administrative Distance

In some cases, you will find that a router will select a suboptimal path because it believes
that a routing protocol has a poorer route, even though it has a better administrative
distance. One way to make sure that routes from the desired routing protocol are selected
is to give the undesired route(s) from a routing protocol a larger administrative distance.
For all protocols except EIGRP and BGP, use the distance command, as explained in Table
8-13, to change the default administrative distances:
router(config-router)#distance weight [address mask
[access-list-number | name ]] [ ip ]
Table 8-13 Administrative Distance Command (Except for EIGRP and BGP)
Command Description
weight Administrative distance, an integer from 10 to 255. (The values 0
to 9 are reserved for internal use.)
address Optional IP address. Allows filtering of networks according to the
IP address of the router supplying the routing information.
continues
Table 8-13 Administrative Distance Command (Except for EIGRP and BGP) (Continued)
Command Description
mask Optional wildcard mask for IP address. A bit set to 1 in the mask
argument instructs the software to ignore the corresponding bit in
the address value.
access-list-number | name Optional number or name of standard access list to be applied to
the incoming routing updates. Allows filtering of the networks
being advertised.
ip Optional; specification of IP-derived routes for Intermediate
System-to-Intermediate System (IS-IS).
For EIGRP, use the following command, as explained in Table 8-14:

router(config-router)#distance eigrp internal-distance external-distance
Table 8-14 EIGRP Administrative Distance Command
Command Description
internal-distance Administrative distance for EIGRP internal routes. Internal
routes are those that are learned from another entity within the
same autonomous system.
external-distance Administrative distance for EIGRP external routes. External
routes are those for which the best path is learned from a
neighbor external to the autonomous system.
Modifying BGP Administrative Distance

For BGP, use the distance bgp command to change the administrative distances:
router(config-router)#distance bgp external-distance
internal-distance local-distance
Command Description
external-distance Administrative distance for BGP external routes. External routes
are routes for which the best path is learned from a neighbor
external to the autonomous system. Acceptable values are from 1
to 255. The default is 20. Routes with a distance of 255 are not
installed in the routing table.
internal-distance Administrative distance for BGP internal routes. Internal routes
are those routes that are learned from another BGP entity within
the same autonomous system. Acceptable values are from 1 to
255. The default is 200. Routes with a distance of 255 are not
installed in the routing table.
Command Description
local-distance Administrative distance for BGP local routes. Local routes are
those networks listed with a network router configuration
command, often as back doors, for that router or for networks
that are being redistributed from another process. Acceptable
values are from 1 to 255. The default is 200. Routes with a
distance of 255 are not installed in the routing table.
Redistribution Example Using the distance Command

The following example uses RIP and IGRP to illustrate how a router can make a poor path
selection because of the default administrative distance values given to RIP and IGRP in
a redundant network. The example also illustrates one possible way of correcting the
problem.
Figure 8-8 illustrates the network before using multiple routing protocols. The R200 and
Cen routers are the primary focus of this example, as are networks 172.16.6.0, 172.16.9.0,
and 172.16.10.0. The configuration output and routing tables appear on the following
pages.
Figure 8-8 Single Routing Protocol Network
172.16.12.1
172.16.3.2 Trans 172.16.2.2
172.16.2.1
172.16.3.1 T1
172.16.1.1 172.16.1.2 Cen

R200 172.16.4.1
172.16.5.1 S0.2
172.16.7.2
S0.1
T1
Frame Relay 172.16.4.2
64 kbps
Rem
172.16.7.1 172.16.5.2 172.16.11.1
64 kbps
172.16.6.1
R300 172.16.6.2 R100
172.16.9.1 172.16.10.1
NOTE This example uses RIP and IGRP for simplicity. These and other protocol combinations can
have the same problems occur, depending on the network topology. This is one reason why
Cisco highly recommends that you study your network topology before implementing
redistribution and that you monitor it after it is enabled.
NOTE There are a number of ways to correct path selection problems in a redistribution
environment. The purpose of this example is to show how a problem can occur, where it
appears, and one possible way of resolving it.
First, you have only IGRP running in all the routers in the network. Example 8-12 shows
the complete IP routing table for the Cen router.
Example 8-12 Routing Table of Cen When IGRP Is the Only Routing Protocol
Cen#show ip route
<Output Omitted>

I 172.16.12.0 [100/1188] via 172.16.2.2, 00:00:02, TokenRing0
I 172.16.9.0 [100/158813] via 172.16.1.1, 00:00:02, TokenRing1
I 172.16.10.0 [100/8976] via 172.16.5.2, 00:00:02, Serial0.1
I 172.16.11.0 [100/8976] via 172.16.4.2, 00:00:02, Serial0.2
C 172.16.4.0 is directly connected, Serial0.2
I 172.16.6.0 [100/160250] via 172.16.5.2, 00:00:02, Serial0.1
I 172.16.7.0 [100/158313] via 172.16.1.1, 00:00:02, TokenRing1
C 172.16.1.0 is directly connected, TokenRing1
C 172.16.2.0 is directly connected, TokenRing0
I 172.16.3.0 [100/8539] via 172.16.2.2, 00:00:02, TokenRing0
[100/8539] via 172.16.1.1, 00:00:03, TokenRing1
Note the administrative distance and the composite metrics for each learned link.
Administrative distance refers to how believable the routing protocol is, and the composite
metric is the value assigned to the link.
Now consider that you want to split the network into two autonomous systems—IGRP and
RIP, as shown in Figure 8-9. Note that IGRP is more believable than RIP because it has an
administrative distance of 100 and RIP has an administrative distance of 120.
Figure 8-9 Running RIP and IGRP in One Network
172.16.12.1
172.16.3.2 Trans 172.16.2.2
172.16.2.1
172.16.3.1 T1
172.16.1.1 172.16.1.2
IGRP R200 Cen 172.16.4.1
RIP 172.16.5.1 S0.2
172.16.7.2
S0.1
T1
64 kbps Frame relay 172.16.4.2
Rem
172.16.11.1
172.16.7.1 172.16.5.2
64 kbps
172.16.6.1
R300 172.16.6.2 R100
172.16.9.1 172.16.10.1
The configuration for Router Cen is shown in Example 8-13.

Example 8-13 Router Cen Is Configured for Both RIP and IGRP
router rip
redistribute igrp 1
passive-interface Serial0.2
passive-interface TokenRing0
network 172.16.0.0
default-metric 3
!
router igrp 1
redistribute rip
passive-interface Serial0.1
network 172.16.0.0
default-metric 10 100 255 1 1500
The configuration for Router R200 is shown in Example 8-14.

Example 8-14 Router R200 Is Configured for Both RIP and IGRP
router rip
redistribute igrp 1
continues
Example 8-14 Router R200 Is Configured for Both RIP and IGRP (Continued)
network 172.16.0.0
default-metric 3
!
router igrp 1
redistribute rip
network 172.16.0.0
The passive interface commands are used to prevent routes from a particular routing
protocol from being forwarded needlessly on links when the remote router cannot
understand or is not using that protocol.
Note in these configurations that RIP is being redistributed into IGRP, and IGRP is being
redistributed into RIP on both routers.
The table shown in Example 8-15 lists the routes that are relevant to the discussion in this
section. Notice that the Cen router learned RIP and IGRP routes. You can use Figure 8-9 to
trace some of the routes.
Example 8-15 Router Cen’s Resulting Routing Table when Running RIP and IGRP
Cen#show ip route
<Output Omitted>

R 172.16.9.0 [120/2] via 172.16.5.2, 00:00:01, Serial0.1
R 172.16.10.0 [120/1] via 172.16.5.2, 00:00:02, Serial0.1
I 172.16.11.0 [100/8976] via 172.16.4.2, 00:00:02, Serial0.2
R 172.16.6.0 [120/1] via 172.16.5.2, 00:00:02, Serial0.1
I 172.16.3.0 [100/8539] via 172.16.2.2, 00:00:02, TokenRing0
[100/8539] via 172.16.1.1, 00:00:02, TokenRing1
Example 8-16 shows the resulting routing table on the R200 router. The routing table lists
the routes that are relevant to the discussion in this section. Notice that all the routes are
learned from IGRP, even though Router R200 is also connected to a RIP network. Notice,
too, that if you trace some of the routes, such as to network 172.16.9.0, the router uses the
long way, via Router Cen rather than via Router R300.
Example 8-16 Router R200’s Resulting Routing Table when Running RIP and IGRP
R200#show ip route
<Output Omitted>

I 172.16.9.0 [100/1000163] via 172.16.1.2, 00:00:37, TokenRing0
Example 8-16 Router R200’s Resulting Routing Table when Running RIP and IGRP (Continued)
I 172.16.10.0 [100/1000163] via 172.16.1.2, 00:00:37, TokenRing0
I 172.16.11.0 [100/9039] via 172.16.1.2, 00:00:37, TokenRing0
I 172.16.4.0 [100/8539] via 172.16.1.2, 00:00:37, TokenRing0
I 172.16.5.0 [100/8539] via 172.16.1.2, 00:00:37, TokenRing0
I 172.16.6.0 [100/1000163] via 172.16.1.2, 00:00:37, TokenRing0
As shown in the routing table of Example 8-16, Router R200 selected the poor paths
because IGRP has a better administrative distance than RIP. To make sure that Router
R200 selects the RIP routes, you can change the administrative distance, as shown in
Example 8-17.
Example 8-17 Redistribution Example Using the distance Command
Router Cen
router rip
redistribute igrp 1
<Output Omitted>
network 172.16.0.0
default-metric 3
!
router igrp 1
redistribute rip
<Output Omitted>
network 172.16.0.0
distance 130 0.0.0.0 255.255.255.255 1
!
access-list 1 permit 172.16.9.0
Router R200
router rip
redistribute igrp 1
<Output Omitted>
network 172.16.0.0
default-metric 3
!
router igrp 1
redistribute rip
<Output Omitted>
network 172.16.0.0
distance 130 0.0.0.0 255.255.255.255 1
!

Table 8-15 distance Command Used in Example 8-17
Command Description
distance 130 0.0.0.0 255.255.255.255 1
130 Defines the administrative distance that specified routes will
be assigned.
0.0.0.0 255.255.255.255 Defines the source address of the router supplying the routing
information—in this case, any router.
1 Defines the access list to be used to filter incoming routing
updates to determine which will have their administrative
distance changed.
1 Gives the access list number.
permit Allows all networks that match the address to be permitted—
in this case, to have their administrative distance changed.
172.16.9.0 Shows a network to be permitted—in this case to have its
administrative distance changed.
Router R200, for example, is configured to assign an administrative distance of 130 to

IGRP routes to networks 172.16.9.0, 172.16.10.0, and 172.16.6.0. In this way, when the
router learns about these networks from RIP, the RIP-learned routes (with a lower
administrative distance of 120) will be selected and put in the routing table. Note that the
distance command is for IGRP-learned routes because it is part of the IGRP routing
process configuration.
The output in Example 8-18 shows that Router R200 now has retained the better (more
optimal) route to some of the networks by using the RIP routes.
Example 8-18 Router R200 Learns Some RIP Routes After the distance Command Is Added
R200#show ip route
<Output Omitted>

R 172.16.9.0 [120/1] via 172.16.7.1, 00:00:19, Serial1
R 172.16.10.0 [120/2] via 172.16.7.1, 00:00:19, Serial1
I 172.16.11.0 [100/9039] via 172.16.1.2, 00:00:49, TokenRing0
I 172.16.4.0 [100/8539] via 172.16.1.2, 00:00:49, TokenRing0
I 172.16.5.0 [100/8539] via 172.16.1.2, 00:00:49, TokenRing0
R 172.16.6.0 [120/1] via 172.16.7.1, 00:00:19, Serial1
Verifying Redistribution Operation 485
With this configuration, given the actual bandwidths involved, the IGRP path would have
been better for the 172.16.10.0 network, so it may have made sense to not include
172.16.10.0 in the access list.
This example illustrates the importance of not only knowing your network before
implementing redistribution, but also demonstrates that you should view which routes the
routers are selecting after redistribution is enabled. You should pay particular attention to
routers that can select from a number of possible redundant paths to a network because they
are more likely to select suboptimal paths.
Verifying Redistribution Operation

The best way to verify redistribution operation is to do the following:
• Know your network topology, particularly where redundant routes exist.
• Show the routing table of the appropriate routing protocol on a variety of routers in
the internetwork. For example, check the routing table on the boundary router, as well
as some of the internal routers in each autonomous system using the following
command:
router#show ip route [ip-address]
• Perform a traceroute on some of the routes that go across the autonomous systems to
verify that the shortest path is being used for routing. Make sure that you especially
run traces to networks for which redundant routes exist using the following command:
router#traceroute [ip-address]
NOTE The traceroute command appears in the Cisco IOS documentation as trace; on the routers,
however traceroute is the full command.
• If you do encounter routing problems, use the traceroute and debug commands to
observe the routing update traffic on the boundary routers and on the internal routers.
NOTE Running debug requires extra processing by the router, so if the router is already
overloaded, initiating debug is not recommended.
Policy-Based Routing Using Route Maps

Route maps are complex access lists that allow some conditions to be tested against a
packet or route in question using match commands. If the conditions match, some actions
can be taken to modify attributes of the packet or route. These actions are specified by set
commands.
A collection of route map statements that have the same route map name are considered one
route map. Within a route map, each route map statement is numbered and therefore can be
edited individually.
The statements in a route map correspond to the lines of an access list. Specifying the match
conditions in a route map is similar to specifying the source and destination addresses and
masks in an access list.
One big difference between route maps and access lists is that route maps can modify the
route by using set commands.
The route-map command can be used to define the conditions for policy routing. The
following command is explained in detail in Table 8-16:
router(config)#route-map map-tag [permit | deny] [sequence-number]
Table 8-16 route-map Command
Command Description
map-tag Name of the route map
permit | deny The action to be taken if the route map match conditions are met
sequence-number Sequence number that indicates the position that a new route map
statement will have in the list of route map statements already
configured with the same name
Route Map Sequence Numbering

The default for the route-map command is permit, with a sequence number of 10. If you
leave out the sequence number when configuring all statements for the same route map
name, the router will assume that you are editing and adding to the first statement, sequence
number 10. Route map sequence numbers do not automatically increment!
A route map may be made up of multiple route map statements. The statements are
processed top-down, similar to an access list. The first match found for a route is applied.
The sequence number is used for inserting or deleting specific route map statements in a
specific place in the route map.
Policy-Based Routing Using Route Maps 487
The match route map configuration commands are used to define the conditions to be
checked. The set route map configuration commands are used to define the actions to be
followed if there is a match.
router(config-route-map)#match {condition}
router(config-route-map)#set {condition}
A single match statement may contain multiple conditions. At least one condition in the
match statement must be true for that match statement to be considered a match. A route
map statement may contain multiple match statements. All match statements in the route map
statement must be considered true for the route map statement to be considered matched.
NOTE Only one match condition listed on the same line must match for the entire line to be
considered a match.
The sequence-number specifies the order in which conditions are checked. For example, if
there are two statements in a route map named MYMAP, one with sequence 10 and the
other with sequence 20, sequence 10 will be checked first. If the match conditions in
sequence 10 are not met, then sequence 20 will be checked.
Like an access list, there is an implicit deny any at the end of a route map. The consequences
of this deny depend on how the route map is being used. The specifics for policy-based
routing are discussed later in this section.
Another way to explain how a route map works is to use a simple example and see how a
router would interpret it. Example 8-19 provides example syntax of a route map. (Note that
on a router, all the conditions and actions shown would be replaced with specific conditions
and actions, depending on the exact match and set commands used.)
Example 8-19 Route Map Demonstration—Simple Example
route-map demo permit 10
match x y z
match a
set b
set c
match q
set r
The route map named demo is interpreted as follows:

If {(x or y or z) and a match} then {set b and c}
Else
If q matches then set r
Else
Set nothing
In today’s high-performance internetworks, organizations need the freedom to implement
packet forwarding and routing according to their own defined policies in a way that goes
beyond traditional routing protocol concerns. By using policy-based routing, introduced in
Cisco IOS Release 11.0, policies that selectively cause packets to take different paths can
be implemented.
Policy-based routing also provides a mechanism to mark packets with different types of
service (TOS). This feature can be used in conjunction with Cisco IOS queuing techniques
so that certain kinds of traffic can receive preferential service.
The benefits that can be achieved by implementing policy-based routing in networks
include the following:
• Source-based transit provider selection—Internet service providers and other
organizations can use policy-based routing to route traffic originating from different
sets of users through different Internet connections, across policy routers.
• Quality of service (QoS)—Organizations can provide QoS to differentiated traffic by
setting the precedence or TOS values in the IP packet headers in routers at the
periphery of the network and leveraging queuing mechanisms to prioritize traffic in
the core or backbone of the network. This setup improves network performance by
eliminating the need to classify the traffic explicitly at each WAN interface in the core
or backbone of the network.
• Cost savings—An organization can direct the bulk traffic associated with a specific
activity to use a higher-bandwidth, high-cost link for a short time and to continue
basic connectivity over a lower-bandwidth, low-cost link for interactive traffic. For
example, a dial-on-demand ISDN line could be brought up in response to traffic to a
finance server for file transfers selected by policy routing.
• Load sharing—In addition to the dynamic load-sharing capabilities offered by
destination-based routing that the Cisco IOS software has always supported, network
managers can now implement policies to distribute traffic among multiple paths based
on the traffic characteristics.
Policy-based routing is applied to incoming packets. All packets received on an interface
with policy-based routing enabled are considered for policy-based routing. The router
passes the packets through a route map. Based on the criteria defined in the route map,
packets are forwarded to the appropriate next hop.
Routers normally forward packets to the destination addresses based on information in their
routing tables. Instead of routing by the destination address, policy-based routing allows
network administrators to determine and implement routing policies to allow or deny paths
based on the following:
• The identity of a source system
• The application being run
• The protocol in use
• The size of packets
The route map statements used for policy-based routing can be marked as permit or deny.
If the statement is marked as deny, a packet meeting the match criteria is sent through the
normal forwarding channels (in other words, destination-based routing is performed). Only
if the statement is marked as permit and the packet meets all the match criteria are the set
commands applied. If no match is found in the route map, then the packet is forwarded
through the normal routing channel. If it is desired not to revert to normal forwarding and
to drop a packet that does not match the specified criteria, then a set statement to route the
packets to interface null 0 should be specified as the last entry in the route map.
Configuring Policy-Based Routing

IP standard or extended access lists can be used to establish policy-based routing match
criteria using the match ip address command explained in Table 8-17. A standard IP access
list can be used to specify match criteria for the source address of a packet; extended access
lists can be used to specify match criteria based on source and destination addresses,
application, protocol type, TOS, and precedence.
router(config-route-map)#match ip address {access-list-number | name}
[...access-list-number | name]
Table 8-17 match ip address Command
match ip address Command Description
access-list-number | name Number or name of a standard or extended access list to be
used to test incoming packets. If multiple access lists are
specified, matching any one will result in a match.
The match length command, explained in Table 8-18, can be used to establish criteria
based on the packet length between specified minimum and maximum values. For example,
a network administrator could use the match length as the criterion that distinguishes
between interactive and file transfer traffic because file transfer traffic usually has larger
packet sizes.
router(config-route-map)#match length min max

Table 8-18 match length Command
match length Command Description
min Minimum Layer 3 length of the packet, inclusive, allowed
for a match
max Maximum Layer 3 length of the packet, inclusive, allowed
for a match
If the match statements are satisfied, one or more of the following set statements can be
used to specify the criteria for forwarding packets through the router:
• The set ip next-hop command provides a list of IP addresses used to specify the
adjacent next-hop router in the path toward the destination to which the packets
should be forwarded. If more than one IP address is specified, the first IP address
associated with a currently up connected interface will be used to route the packets.
The set ip next-hop command is explained in Table 8-19.
router(config-route-map)#set ip next-hop ip-address [...ip-address]
NOTE This set command affects all packet types and is always used if configured.
Table 8-19 set ip next-hop Command

Command Description
ip-address IP address of the next hop to which packets are output. It must be
the address of an adjacent router.
• The set interface command provides a list of interfaces through which the packets can
be routed. If more than one interface is specified, the first interface that is found to be
up will be used for forwarding the packets. The following command is explained in
Table 8-20:
router(config-route-map)#set interface type number [...type number]
NOTE If there is no explicit route for the destination address of the packet in the routing table (for
example, if the packet is a broadcast or is destined to an unknown address), the set interface
command has no effect and is ignored.
Table 8-20 set interface Command

Command Description
type number Interface type and number to which packets are output
The set ip default next-hop command provides a list of default next-hop IP addresses. If
more than one IP address is specified, the first next hop specified that appears to be adjacent
to the router is used. The optional specified IP addresses are tried in turn. Table 8-21
provides information on the set ip default next-hop command.
router(config-route-map)#set ip default next-hop ip-address [...ip-address]
NOTE A packet is routed to the next hop specified by this set command only if there is no explicit
route for the packet’s destination address in the routing table.
Table 8-21 set ip default next-hop Command

Command Description
ip-address IP address of the next hop to which packets are output.
It must be the address of an adjacent router.
The set default interface command provides a list of default interfaces. If there is no
explicit route available to the destination address of the packet being considered for policy
routing, it will be routed to the first up interface in the list of specified default interfaces.
Table 8-22 provides information about the set default interface command.
router(config-route-map)#set default interface type number [...type number]
NOTE A packet is routed to the next hop specified by this set command only if there is no explicit
route for the packet’s destination address in the routing table.
Table 8-22 set default interface Command

Command Description
type number Interface type and number, to which packets are output
Using the set Commands

The router evaluates the first four set commands for policy-based routing, shown here in
the order they are presented. When a destination address or interface has been chosen, other
set commands for changing the destination address or interface are ignored. Note, however,
that some of these commands affect only packets for which there is an explicit route in the
routing table, while others affect only packets for which there is no explicit route in the
routing table. A packet that is not affected by any of the set commands in a route map
statement that it has matched will not be policy routed and will be forwarded normally (in
other words, destination-based routing will be performed).
The set ip tos command is used to set the IP TOS value in the IP packets. The TOS field is
8 bits long in the IP header, with 5 bits for setting the Class of Service (COS) and 3 bits for
the IP precedence. The set ip tos command is used to set the 5 COS bits.
The 5 COS bits are for setting the delay, throughput, reliability, and cost, with 1 of the bits
reserved. Table 8-23 provides information on the set ip tos command.
router(config-route-map)#set ip tos [number | name ]
Table 8-23 set ip tos Command
Variable: number or name Description
0-15 Type of service value
max-reliability Set max reliable TOS (2)
max-throughput Set max throughput TOS (4)
min-delay Set min delay TOS (8)
min-monetary-cost Set min-monetary-cost TOS (1)
normal Set normal TOS (0)
The set ip precedence command is used to set the IP precedence bits in the IP packets. With
3 bits, there are eight possible values for the IP precedence. This command is used when
implementing quality of service (QoS) and can be used by other QoS services such as
weighted fair queuing (WFQ) and weighted random early detection (WRED). Table 8-24
provides information on the set ip precedence command.
router(config-route-map)#set ip precedence [number | name ]
Table 8-24 set ip precedence Command
0-7 Precedence value
critical Set critical precedence (5)
Table 8-24 set ip precedence Command (Continued)

flash Set flash precedence (3)
flash-override Set flash override precedence (4)
immediate Set immediate precedence (2)
Internet Set internetwork control precedence (6)
network Set network control precedence (7)
priority Set priority precedence (1)
routine Set routine precedence (0)
The set commands can be used in conjunction with each other.

To identify a route map to use for policy routing on an interface, use the ip policy route-
map interface configuration command, explained in Table 8-25.
router(config-if)#ip policy route-map map-tag
Table 8-25 ip policy route-map Command
Command Description
map-tag Name of the route map to use for policy routing. Must match a
map tag specified by a route-map command.
NOTE Policy-based routing is specified on the interface that receives the packets, not on the
interface from which the packets are sent.
Since Cisco IOS Release 11.2F, IP policy routing can now be fast-switched. Prior to this
feature, policy routing could be only process-switched, which meant that on most
platforms, the switching rate was approximately 1,000 to 10,000 packets per second. This
was not fast enough for many applications. Users who need policy routing to occur at faster
speeds can now implement policy routing without slowing down the router.
Policy routing must be configured before you configure fast-switched policy routing. Fast
switching of policy routing is disabled by default. To have policy routing be fast-switched,
use the ip route-cache policy command in interface configuration mode.
router(config-if)#ip route-cache policy
Fast-switched policy routing supports all the match commands and most of the set
commands, except for the following restrictions:
• The set ip default command is not supported.
• The set interface command is supported only over point-to-point links, unless a
route-cache entry exists using the same interface specified in the set interface
command in the route map. Also, at the process level, the routing table is consulted to
determine whether the interface is on a reasonable path to the destination. During fast
switching, the software does not make this check. Instead, if the packet matches, the
software blindly forwards the packet to the specified interface.
Policy-Based Routing Example

In Figure 8-10, Router A has a policy that packets from 192.168.2.1 should go out to Router
C’s interface serial 1. All other packets should be routed according to their destination
address. The configuration for Router A is shown in Example 8-20.
Figure 8-10 Router A Has a Policy That Packets from 192.168.2.1 Go to Router C’s Interface S1
192.168.1.0
192.168.2.0
C S1:172.17.1.2
S0:10.1.1.100
B
S0:172.16.1.1
S1:172.17.1.1
S3:10.1.1.1
A S2:172.16.1.2
Router A’s serial 2 interface, where packets from 192.168.2.1 go into Router A, is
configured to do policy routing with the ip policy route-map command. The route map test
is used for this policy routing. It tests the IP addresses in packets against access list 1 to
determine which packets will be policy-routed.
Example 8-20 Router A’s Configuration
RouterA(config)# interface Serial2
RouterA(config-if)# ip address 172.16.1.2 255.255.255.0
RouterA(config-if)# ip policy route-map test
RouterA(config)#route-map test permit 10
RouterA(config-route-map)#match ip address 1
RouterA(config-route-map)#set ip next-hop 172.17.1.2
RouterA(config-route-map)#exit
RouterA(config)#access-list 1 permit 192.168.2.1 0.0.0.0
Access list 1 specifies that packets with a source address of 192.168.2.1 will be policy-
routed. Packets that match access list 1 will be sent to the next-hop address 172.17.1.2,
which is Router C’s serial 1 interface. All other packets will be forwarded normally,
Verifying Policy-Based Routing 495
according to their destination address. (Recall that access lists have an implicit deny any at
the end, so no other packets will be permitted by access list 1.)
Verifying Policy-Based Routing

To display the route maps used for policy routing on the router’s interfaces, use the show
ip policy EXEC command.
To display configured route maps, use the show route-map EXEC command, as shown in
Table 8-26.
router#show route-map [map-name]
Table 8-26 show route-map Command
Command Description
map-name Optional name of a specific route map
Use the debug ip policy EXEC command to display IP policy routing packet activity. This
command helps you determine what policy routing is doing. It displays information about
whether a packet matches the criteria and, if so, the resulting routing information for the
packet.
Because the debug ip policy command generates a significant amount of output, use it only
when traffic on the IP network is low so that other activity on the system is not adversely
affected.
To discover the routes that the packets follow when traveling to their destination from the
router, use the traceroute privileged EXEC command. To change the default parameters
and invoke an extended traceroute test, enter the command without a destination argument.
You will be stepped through a dialog to select the desired parameters.
To check host reachability and network connectivity, use the ping (IP packet Internet groper
function) privileged EXEC command. You can use the extended command mode of the
ping command to specify the supported header options by entering the command without
any arguments.
The output shown in Examples 8-21, 8-22, and 8-23 are from Router A in Example 8-20.
Example 8-21 provides an example of the show ip policy command. It indicates that the
route map called test is used for policy routing on the router’s interface serial 2.
Example 8-21 show ip policy Output
RouterA#show ip policy
Interface Route map
Serial2 test
The show route-map command, shown in Example 8-22, indicates that three packets have
matched sequence 10 of the test route map.
Example 8-22 show route-map Output
RouterA#show route-map
route-map test, permit, sequence 10
Match clauses:
ip address (access-lists): 1
Set clauses:
ip next-hop 172.17.1.2
Policy routing matches: 3 packets, 168 bytes
Example 8-23 provides an example of the output of the debug ip policy command. The
output indicates that a packet from 172.16.1.1 destined for 192.168.1.1 was received on
interface serial 2 and that it was rejected by the policy on that interface. The packet is routed
normally (by destination).
Another packet, from 192.168.2.1 destined for 192.168.1.1, was later received on the same
interface serial 2. This packet matched the policy on that interface and was therefore policy-
routed and sent out interface Serial 1 to 172.17.1.2.
Example 8-23 Example of debug ip policy
RouterA#debug ip policy
Policy routing debugging is on
...
11:50:51: IP: s=172.16.1.1 (Serial2), d=192.168.1.1 (Serial3), len 100,
policy rejected -- normal forwarding
...
11:51:25: IP: s=192.168.2.1 (Serial2), d=192.168.1.1, len 100, policy match
11:51:25: IP: route map test, item 10, permit
11:51:25: IP: s=192.168.2.1 (Serial2), d=192.168.1.1 (Serial1), len 100,
policyrouted
11:51:25: IP: Serial2 to Serial1 172.17.1.2
Case Study: Redistribution

Refer to Chapter 1 for introductory information on the running case study.
Recall that throughout this book we have been using a case study of JKL Corporation to
discuss various aspects of scalable routing. The case studies are used to review key concepts
and to discuss critical issues surrounding network operation.
In this case study, you will look at how JKL’s Acquisition A will implement its routing
protocols. Recall that Acquisition A is running a mixture of protocols: IGRP, RIP, and
OSPF. It has two Class C public addresses and uses a Class A private address. As shown in
Figure 8-11, each of the three protocol domains is connected to the other two.
Case Study: Redistribution 497
Figure 8-11 Topology of JKL After the Acquisition of A
A’s new acquisition

JKL’s acquisition A
RIP Domain, Metric = Hops
IGRP domain, Metric = Composite 1 public Class C supports
1 private Class A supports Unix W/S, servers
regional campus topology
E B
T-3 D
A
To JKL
C
OSPF domain, Metric = Cost

1 public Class C supports
acquisition policy
Private address space
Network 10.0.0.0
Fast Ethernet
Ethernet
Serial

• Limitations on the size of a routing domain
• Use of administrative distance as a learning mechanism
• Possibilities for suboptimal routes in the routing table
• Protection against feedback loops, especially those caused by topology changes
• Requirement for appropriate seed metrics when passing routes between different
protocols
Case Study Solution

Acquisitions A’s network was originally a RIP implementation until it grew too large. IGRP
and private addressing were selected to handle the largest portion of the network because
IGRP has a maximum default hop count of 100 and the number of nodes far exceeded the
available Class C addressing space. The IGRP domain is a hierarchical regional campus
network with route summarization in effect at routers D and G.
The RIP domain at the upper right of Figure 8-11 represents a concentration of UNIX
workstations and servers that are not under A’s administrative control. The Class C address
space from the RIP domain is summarized to a classful boundary at Router G and at
Router H.
The OSPF domain was also originally a RIP domain, but it has been converted to OSPF in
anticipation of the consolidation into JKL’s enterprise network. The Internet connection is
currently through Router A, although Router A will eventually link the entire network to JKL.
The administrative distances for IGRP, OSPF, and RIP are 100, 110, and 120, respectively.
If two-way redistribution for each domain occurred at Routers D, G, and H, suboptimal
paths could be propagated because the administrative distance for IGRP is lowest. In a
potentially looping topology, such as shown in Figure 8-11, care must be taken to apply
route filters to prevent the feedback of routes learned via redistribution. Routes learned via
redistribution start with a seed metric specified by the redistribute command. Suboptimal
routes might have a bad metric (indicating a less than desirable route) but are still the
preferred path because the route was learned by a routing protocol with a superior
administrative distance.
As you remember from previous discussions, there is a significant difference between the
administrative distance value, which is a preference factor about how routes are learned,
and the metric value, which is a preference factor for selecting routes to forward traffic.
Alternatives to potentially dangerous redistribution can be a combination of static routes,
default routes, and passive interface statements. In lieu of full redistribution for the RIP
domain, consider using a static route to network 10.0.0.0, and default routes in each router
pointing toward the OSPF domain (via router H) as a jump-off point to the Internet.
Some points to remember when considering redistribution include the following:
• Redistribution is required when routes having different metric structures need to be
exchanged.
• Proper configuration for redistributing routes requires a default-metric statement to
establish a seed metric.
• Redundant topologies can create feedback loops that lead to suboptimal paths being
propagated.
• Route filtering is one way to control feedback loops.
• Full, two-way redistribution is not the only way to establish connectivity between
dissimilar routing domains.
• Administrative distance indicates the router’s preference for how a route is learned,
whereas the metric value is a measure of a route’s reachability.
Configuration Exercise #1: Configuring Policy-Based Routing 499
This case study gave you a chance to reexamine concepts learned in the chapter regarding
redistribution and ways to control looping by using route filtering or adjusting the
administrative distance of routing protocols.
Summary
In this chapter, you have learned how to select and configure the different ways to control
route update traffic and how to apply judicious route redistribution between dissimilar
routing processes. You have also learned how to resolve path selection problems that result
in a redistributed network and how to confirm the proper route redistribution.
In the last section of this chapter, you learned how to configure policy-based routing using
route maps.
Configuration Exercise #1: Configuring Policy-Based

Routing
Complete the following exercise to configure policy-based routing.
Objectives
In this Configuration Exercise, you will configure pxr1 to policy-route the packets coming
in from pxr3.
Visual Objective
Figure 8-12 illustrates the topology used for this policy-routing Configuration Exercise.
Figure 8-12 Policy Routing on pxr1
Traffic from 172.26.x.17 goes out on interface S0

Traffic from 172.26.x.33 goes out on interface S1
All other traffic not affected by policy routing
S0 pxr1 S2
192.168.x.17/28 192.168.x.49/28
S1
192.168.x.33/28
EIGRP AS 200
192.168.x.18/28 192.168.x.50/28
S0 192.168.x.34/28 S0
S1
loopback pxr2 E0 E0 pxr3 loopback

192.168.10x.10x/24 shut shut
172.26.x.17/28
172.26.x.33/28
172.26.x.49/28
Command List
In this Configuration Exercise, you will use the commands listed in Table 8-27. Refer to
this list if you need configuration command assistance during this exercise.
Command Description
ip policy route-map mapname Enables IP policy routing on an interface using route map.
route-map mapname permit 10 Creates a route map.
match IP address 1 Matches IP address in access list 1.
set interface S0 Sets outgoing interface to S0.
show IP policy Shows IP policy routing-enabled interfaces.
show route-map Shows your route map configuration.
debug IP policy Debugs IP policy routing events.
trace Performs an extended trace so that you can set the source IP
address.
Configuration Exercise #1: Configuring Policy-Based Routing 501
Table 8-27 Commands Used in Configuration Exercise #1 (Continued)

Command Description
ping Performs an extended ping so that you can set the source IP
address.
show logging Shows buffered console error and debug messages.
Setup
Perform the following steps:
Step 1 At pxr1, shut the Serial 3 interface, and disable BGP.
Step 2 At pxr2, shut the Ethernet 0 interface and disable BGP.

Step 3 At pxr3, shut the Serial 1 and Ethernet 0 interfaces and disable BGP.
Task: Enable IP Policy-Based Routing at pxr1

Step 1 Enable EIGRP in AS 200 on pxr1, pxr2, and pxr3, including on the
loopback interfaces of pxr2 and pxr3. What commands will you use to
achieve this?
Step 2 From pxr3, ensure that you can ping the pxr2 loopback interface
(192.168.10x.10x).
From pxr2, ensure that you can ping the pxr3 loopback interfaces
(172.26.x.17, 172.26.x.33, and 172.26.x.49).
Step 3 Examine the routing table of pxr1.
You should see two paths to 192.168.10x.10x. If not, verify that you have
identical bandwidth set on the S0 and S1 interfaces and that you have not
disabled load balancing (with the maximum-paths 1 command).
Step 4 Configure IP policy-based routing at pxr1 as follows:
All IP traffic sourced from 172.26.x.17 should be forwarded out on the

pxr1 S0 interface. Which commands should you type to create this
policy?
All IP traffic sourced from 172.26.x.33 should be forwarded out on the
pxr1 S1 interface. Which commands should you type to create this
policy?
All other traffic should not be policy-routed.
Issue the show ip policy command at pxr1 to verify that the route map is
associated with the correct interface.
What command could you issue at pxr1 to verify that the route map is
configured correctly?
What command could you issue at pxr1 to confirm that your access lists
are configured correctly?
Step 5 Clear all logging on pxr1. Enable debugging of IP policy-based routing
at pxr1. What commands would you type to achieve this?
From pxr3, use the extended trace command to perform a trace to
192.168.10x.10x, using a source address of 172.26.x.17 (loopback
address of pxr3).
Which command would show you the buffered debug output on pxr1?
Which path did the packets use at pxr1, S0 or S1?
What command could you use to see the matches on the route map that
you created?
Step 6 Clear the logging on pxr1. From pxr3, use the extended trace command
to perform a trace to 192.168.10x.10x, using a source address of
172.26.x.33.
On pxr1, what command will you type to show the buffered debug
output?
What command could you use to see the matches on the route map that
you created?
Step 7 Enter the clear logging command on pxr1. From pxr3, use the extended
trace command to perform a trace to 192.168.10x.10x, using a source
address of 172.26.x.49.
On pxr1, show the buffered debug output with the show logging
command.
Which command could you type to see a summary of the policy matches
for policy routing?
Step 8 From pxr3, use the extended ping command to perform a ping to
192.168.10x.10x, using a source address of 172.26.x.17 with a count of
100.
Configuration Exercise #2: Configuring Route Redistribution Between OSPF and EIGRP 503
At pxr1, look at the debug output.

Is the ping packet from 172.26.x.17 being policy-routed correctly?
100.
Is the ping packet from 172.26.x.33 being policy-routed correctly?
100.
Is the ping packet from 172.26.x.49 being policy-routed?
Step 11 Type in the command to save the current configurations of all the routers
within your pod to NVRAM.
Completion Criteria
commands required to configure policy-based routing at pxr1 according to the given
requirements, if you were able to see the correct results in the debug output, and if you were
able to correctly answer the questions in the Configuration Exercises. At the end of this
Configuration Exercise, all the routers in your pod will have EIGRP connectivity to each
other, with policy routing configured on pxr1.
Configuration Exercise #2: Configuring Route

Redistribution Between OSPF and EIGRP
Complete the following exercise to configure route redistribution at the pxr1 router, which
is the ASBR.
Objectives
In the Configuration Exercise, you will do the following:
• Configure OSPF between your pxr1 and pxr2 routers.
• Configure EIGRP between your pxr1 and pxr3 routers.
• Configure route redistribution at your pxr1 router.
• Configure route redistribution at your pxr1 router with filtering.

• Verify connectivity within your pod.
Visual Objective
Figure 8-13 illustrates the topology used for this redistribution exercise.
Figure 8-13 Configuring Route Redistribution
ASBR
S0 pxr1 S2
192.168.x.17/28 192.168.x.49/28
S1
OSPF 192.168.x.33/28
EIGRP AS 200
Area 0
192.168.x.18/28 192.168.x.50/28
S0 192.168.x.18/28 S0
S1
loopback pxr2 E0 E0 pxr3 loopback

192.168.10x.10x/24 shut shut
172.26.x.17/28
172.26.x.33/28
172.26.x.49/28
Command List
In this Configuration Exercise, you will use the commands listed in Table 8-28. Refer to
this list if you need configuration command assistance during the Configuration Exercise.
You should already be familiar with the EIGRP and OSPF configuration commands from
the OSPF and EIGRP Configuration Exercises.
Table 8-28 Commands Used for Route Redistribution
Command Description
redistribute eigrp 200 subnets metric Redistributes EIGRP into OSPF.
1700
redistribute ospf 200 metric 64 100 255 1 Redistributes OSPF into EIGRP.
1500
distribute-list 10 out eigrp 200 Enables filtering when redistributing from EIGRP.
access-list 10 permit 172.26.x.16 Standard access list to only permit route
172.26.x.16.
Setup
Perform these steps:
Step 1 At pxr1, disable EIGRP.
Step 2 At pxr2, disable EIGRP.
Task 1: Enable OSPF Between pxr1 (S0 and S1) and pxr2 (S0 and S1)
Step 1 What commands would you use to enable OSPF process ID 200 (area 0)
between the S0 and S1 interfaces of pxr1 and pxr2?
Step 2 What command would you type to place your loopback interface
(192.168.10x.10x/28) of pxr2 into OSPF area 0?
Step 3 From pxr1, ping the pxr2 loopback interface to verify OSPF connectivity.
Task 2: Enable EIGRP Between pxr1 (S2) and pxr3 (S0)

Step 1 What commands would you use to enable EIGRP AS 200 between the S2
interface of pxr1 and the S0 interface of pxr3? (Ensure that EIGRP is
running only between pxr1 and pxr3.)
Step 2 On pxr3, which command could you type to verify that EIGRP is enabled
on your loopback interfaces (172.26.x.17/28, 172.26.x.33/28, and
172.26.x.49/28)?
Step 3 From pxr1, ping the pxr3 loopback interfaces to verify EIGRP
connectivity.
Step 4 From pxr3, would a ping to the loopback interface on pxr2 be successful?
Why or why not?

Step 5 What command would you type to save the current configurations of all
the routers within your pod to NVRAM?
Task 3: Enable Route Redistribution Between OSPF and EIGRP

Step 1 Which router within your pod is the ASBR?
Step 2 At your ASBR, what command would you type to redistribute from
OSPF into EIGRP?
Step 3 At your ASBR, what command would you type to redistribute from
EIGRP into OSPF?
Step 4 What command would you type to examine the routing tables of pxr2 and
pxr3?
Do you see the external EIGRP route at the pxr3 router?
Do you see the external OSPF route at the pxr2 router? What is the metric
type?
Step 5 From pxr2, ping the loopback interfaces on pxr3.
From pxr3, ping the loopback interface on pxr2.

Step 6 Why is your pxr2 router seeing only the 172.26.0.0 summarized route
and not the 172.26.x.16/28, 172.26.x.32/28, and 172.26.x.48/32 subnets
in its routing table?
Step 7 At your pxr3 router, what command would you enter to disable EIGRP
autosummarization?
Step 8 Re-examine the pxr2 routing table; do you see the 172.26.x.16/28,
172.26.x.32/28, and 172.26.x.48/28 subnets now?
Do not proceed to the next task if you don’t see these subnets in your pxr2
routing table. If you don’t see the subnets, confirm that the no auto-
summary command is configured, and be patient because the change
will not be instantaneous.
NVRAM.
Task 4: Enable Route Redistribution from EIGRP to OSPF with

Filtering
Step 1 Reconfigure your redistribution from EIGRP into OSPF to only allow the
172.26.x.16/28 and the 192.168.x.48/28 subnets to be redistributed from
EIGRP into OSPF. Using the distribute-list command to perform this
task, list all the commands used.
What command would you use on pxr1 to clear the routing table?
Step 2 Examine the pxr2 routing table. Are the 172.26.x.32/28 and 172.26.x.48/
28 external routes filtered out?
Bonus question: What will happen if we allow only the 172.26.x.16/28
subnet and not the 192.168.x.48/28 subnet? Will the ping from pxr3 to
pxr2 fail? Why or why not?
Step 3 Type the command to remove the distribute list filtering after it is
working correctly. Clear the IP routing table on pxr1, and then look at the
pxr2 routing table once more. Which commands would accomplish all
this?
NVRAM.
Bonus Task
Step 1 Which commands would you use to repeat Task 4 using a route map
instead of a distribute list?
Step 2 Remove the route map filtering and clear the IP routing table on pxr1.
Completion Criteria
commands required to configure your pxr1 router, the ASBR, to redistribute OSPF routes
into EIGRP AS 200 and redistribute a particular EIGRP route into OSPF, and if you were
able to correctly answer the questions in the Configuration Exercises. At the end of this
Configuration Exercise, the routers in your pod should have full connectivity to each other,
with the exception of the routes that were filtered out.
CHAPTER
9
Implementing Scalability
Features in Your Internetwork
At the end of this chapter, when given a set of network requirements, you will be able to
configure many of the features discussed in this book and verify proper operation (within
described guidelines) of your routers.
Routing Principles
This section reviews the principles of routing. The following subjects are covered:
• Routing defined
• Classful routing
• Classless routing
Routing Defined
Routing is a relay process in which items are forwarded from one location to another. Each
device in the network has a logical address so that it can be reached individually; in some
cases, devices can also be reached as part of a larger group of devices.
For a router to act as an effective relay device, it must have knowledge of the logical
topology of the network and must be capable of communicating with its neighboring
devices. A router can be configured to recognize several different logical addressing
schemes and to regularly exchange topology information with other devices in the network.
The mechanism of learning and maintaining awareness of the network topology is
considered to be the routing function. The actual movement of transient traffic through the
router, from an inbound interface to an outbound interface, is a separate function and is
considered to be the switching function. A routing device must perform both the routing and
the switching function to be an effective relay device.
Classful Routing
One way that Internet Protocol (IP) routing protocols can be classified is whether they are
classful or classless.
532 Chapter 9: Implementing Scalability Features in Your Internetwork
Classful routing is the result of subnet masks not being included in the routing
advertisements generated by most distance vector routing protocols.
When using a classful routing protocol, all subnets of the same major (Class A, B, or C)
network number must use the same subnet mask. Upon receiving a routing update packet,
a router running a classful routing protocol does one of the following to determine the
network portion of the route:
• If the routing update information is about the same major network number as
configured on the receiving interface, the router applies the subnet mask that is
configured on the receiving interface.
• If the routing update information is about a different major network as configured on
the receiving interface, the router will apply the default (by address class) subnet
mask.
Classful routing protocols, such as the Routing Information Protocol version 1 (RIPv1) and
the Interior Gateway Routing Protocol (IGRP), exchange routes to all subnetworks within
the same classful network. This is possible because all the subnetworks in the major
network should have the same subnet mask.
When routes are exchanged with foreign networks (in other words, with different major
network numbers), receiving routers will not know the subnet mask in use because subnet
masks are not included in the routing updates. As a result, the subnetwork information from
each major network must be summarized to a classful boundary, using the default classful
mask, before they are included in the routing update. Thus, only routers configured to
participate in the major network to which the subnets belong exchange subnet routes;
routers that participate in different major networks exchange classful summary routes. The
creation of a classful summary route at major network boundaries is handled automatically
by classful routing protocols. Summarization at other bit positions within the major
network address is not allowed by classful routing protocols.
Classless Routing
Classless routing protocols can be considered second-generation protocols because they are
designed to deal with some of the limitations of the earlier classful protocols. Classless
routing protocols include Open Shortest Path First (OSPF), Enhanced Interior Gateway
Routing Protocol (EIGRP), RIP version 2 (RIPv2), Intermediate System-to-Intermediate
System (IS-IS), and the Border Gateway Protocol version 4 (BGP-4).
One of the most serious limitations in a classful network environment is that the subnet
mask is not exchanged during the routing update process. This approach requires the same
mask to be used on all subnetworks of a major network. The classless approach advertises
the subnet mask for each route, so a more precise lookup can be performed in the routing
table.
Extending IP Addressing Space 533
Classless routing protocols also address another limitation of classful routing protocols: the
automatic summarization to a classful network with a default classful subnet mask at major
network boundaries. In the classless environment, the summarization process is manually
controlled and can usually be invoked at any bit position within the network. Because
subnet routes are propagated throughout the routing domain, summarization is often
required to keep the size of the routing tables at a manageable size.
Extending IP Addressing Space

This section reviews some of the features available to extend the IP addressing space.
The following subjects are covered:
• IP addressing solutions
• VLSM overview
• Route summarization overview
• CIDR overview
IP Addressing Solutions
Since the 1980s, solutions have been developed to slow the depletion of IP addresses and
to reduce the number of Internet route table entries by enabling a hierarchy in an IP address.
These solutions include the following:
• Subnet masking—Covered by RFCs 950 (1985) and 1812 (1995). Developed to add
another level of hierarchy to an IP address. This additional level allows for extending
the number of network addresses derived from a single IP address.
• Address allocation for private internets—Covered by RFC 1918 (1996). Developed
for organizations that do not need much access to the Internet. The only reason to have
an IP address assigned by the Network Information Center (NIC) is to interconnect to
the Internet. Any and all companies can use the privately assigned IP addresses within
their organization rather than using a NIC-assigned IP address unnecessarily.
• Network address translation (NAT)—Covered by RFC 1631 (1994). Developed for
those companies that use private addressing or use IP addresses not assigned by NIC.
This strategy enables an organization to access the Internet with a NIC-assigned
address without having to reassign the private addresses (sometimes called illegal
addresses) that are already in place.
• Hierarchical addressing—The process of applying a structure to addressing so that
multiple addresses share the same left-most bits.
• Variable-length subnet masks (VLSMs)—Covered by RFC 1812 (1995).

Developed to allow multiple levels of subnetworked IP addresses within a single
network. This strategy can be used only when it is supported by the routing protocol
in use, such as the classless routing protocols OSPF protocol and EIGRP.
• Route summarization—Covered by RFC 1518 (1993). A way of having a single IP
addressing plan.
• Classless interdomain routing (CIDR)—Covered by RFCs 1518 (1993), 1519
(1993), and 2050 (1996). Developed for Internet service providers (ISPs). This
strategy suggests that the remaining IP addresses be allocated to ISPs in contiguous
blocks, with geography being a consideration. CIDR allows ISPs to represent a block
of Class C addresses by a single supernet or summarized route.
VLSM Overview
VLSMs provide the capability to include more than one subnet mask within a major
network and the capability to subnet an already subnetted network address. The benefits of
VLSMs include these:
• Even more efficient use of IP addresses—Without the use of VLSMs, companies are
locked into implementing a single subnet mask within an entire Class A, B, or C
network number.
For example, consider the 172.16.0.0/16 network address divided into subnets using
/24 masking, and one of the subnetworks in this range, 172.16.14.0/24, further divided
into smaller subnets with the /27 masking, as shown in Figure 9-1. These smaller
subnets range from 172.16.14.0/27 to 172.16.14.224/27. In Figure 9-1, one of these
smaller subnets, 172.16.14.128, is further divided with the /30 prefix, creating subnets
with only two hosts, to be used on the WAN links.
• Greater capability to use route summarization—VLSMs allow for more
hierarchical levels within your addressing plan, and thus allow for better route
summarization within routing tables. For example, in Figure 9-1, address 172.16.14.0/
24 could summarize all the subnets that are further subnets of 172.16.14.0, including
those from subnets 172.16.14.0/27 and 172.16.14.128/30.
Extending IP Addressing Space 535
Figure 9-1 VLSMs Allow More Than One Subnet Mask Within a Major Network
172.16.14.32/27 17
A 2.1
6.1
4.1
32 172.16.1.0/24
/30
172.16.14.64/27 172.16.14.136/30
B
HQ
/30
.1 40 172.16.2.0/24
6 .14
172.16.14.96/27 2.1
C 17
172.16.0.0/16
Route Summarization Overview

In large internetworks, hundreds or even thousands of networks can exist. In these
environments, it is often not desirable for routers to maintain all these routes in their routing
table. Route summarization (also called route aggregation or supernetting) can reduce the
number of routes that a router must maintain because it is a method of representing a series
of network numbers in a single summary address. For example, in Figure 9-2, Router A
either can send three routing update entries or can summarize the three addresses into a
single network number.
NOTE Router A in Figure 9-2 is advertising that it can route to the network 172.16.0.0/16,
including all subnets of that network. However, if there were other subnets of 172.16.0.0
elsewhere in the network (for example, if 172.16.0.0 were discontiguous), summarizing in
this way might not be valid.
Figure 9-2 Routers Can Summarize to Reduce the Number of Routes
172.16.25.0/24 Router A can route to the

172.16.0.0/16 network.
172.16.26.0/24
A B
Routing table
172.16.0.0/16
172.16.27.0/24
Routing table
172.16.25.0/24
172.16.26.0/24
172.16.27.0/24
CIDR Overview
CIDR is a mechanism developed to help alleviate the problem of exhaustion of IP addresses
and growth of routing tables. The idea behind CIDR is that blocks of multiple Class C
addresses can be combined, or aggregated, to create a larger classless set of IP addresses
(that is, with more hosts allowed). Blocks of Class C network numbers are allocated to each
network service provider. Organizations using the network service provider for Internet
connectivity are allocated subsets of the service provider’s address space as required.
These multiple Class C addresses can then be summarized in routing tables, resulting in
fewer route advertisements.
CIDR is described further in RFCs 1518 and 1519. RFC 2050, “Internet Registry IP
Allocation Guidelines,” specifies guidelines for the allocation of IP addresses.
Figure 9-3 shows an example of CIDR and route summarization. The Class C network
addresses 192.168.8.0/24 through 192.168.15.0/24 are being used and are being advertised
to the ISP router. When the ISP router advertises the networks available, it can summarize
them into one route instead of separately advertising the eight Class C networks. By
advertising 192.168.8.0/21, the ISP router is indicating that it can get to all destination
addresses that have the first 21 bits the same as the first 21 bits of the address 192.168.8.0.
Connecting to ISPs 537
Figure 9-3 CIDR Allows a Router to Summarize Multiple Class C Addresses
192.168.8.0/24
A 19
2.1
68
.8.
0/2
4
192.168.9.0/24
B
192.168.8.0/21
. 192.168.9.0/24 ISP
. .
. . 24
5.0/
. 6 8.1
2.1
19
192.168.15.0/24
H
Connecting to ISPs
This section reviews autonomous systems and the Border Gateway Protocol (BGP) as they
relate to connecting to Internet service providers. The following subjects are covered:
• Autonomous systems
• BGP characteristics
• BGP route selection decision process
• BGP multihoming
Autonomous Systems
One way to categorize routing protocols is by whether they are interior or exterior. Two
types of routing protocols are as follows:
• Interior Gateway Protocol (IGP)—A routing protocol used to exchange routing
information within an autonomous system. RIP, IGRP, OSPF, and EIGRP are
examples of IGPs.
• Exterior Gateway Protocol (EGP)—A routing protocol used to connect between
autonomous systems. BGP is an example of an EGP.
This concept is illustrated in Figure 9-4.
Figure 9-4 IGPs Operate Within an Autonomous System, and EGPs Operate Between Autonomous Systems
IGPs: RIP, IGRP,

OSPF, EIGRP
EGPs: BGP
Autonomous system 65000 Autonomous system 65500
BGP version 4 (BGP-4) is the latest version of BGP and is defined in RFC 1771. As noted
in this RFC, the classic definition of an autonomous system is “a set of routers under a single
technical administration, using an Interior Gateway Protocol and common metrics to route
packets within the AS, and using an Exterior Gateway Protocol to route packets to other”
autonomous systems.
Today, autonomous systems may use more than one IGP, with potentially several sets of
metrics. The important characteristic of an AS from the BGP point of view is that the AS
appears to other autonomous systems to have a single, coherent interior routing plan and
presents a consistent picture of what destinations are reachable through it. All parts of the
AS must be connected to each other.
BGP Characteristics
BGP is a distance vector protocol, though it has many differences from the likes of RIP.
BGP uses the transmission control protocol (TCP) as its transport protocol, which provides
connection-oriented reliable delivery. In this way, BGP assumes that its communication is
reliable; therefore, it doesn’t have to implement any retransmission or error-recovery
mechanisms. BGP uses TCP port 179. Two routers speaking BGP form a TCP connection
with one another and exchange messages to open and confirm the connection parameters.
These two routers are called peer routers or neighbors.
After the connection is made, full routing tables are exchanged. However, because the
connection is reliable, BGP routers need send only changes (incremental updates) after
that. Periodic routing updates are also not required on a reliable link, so triggered updates
Connecting to ISPs 539
are used. BGP sends keepalive messages, similar to the hello messages sent by OSPF and
EIGRP.
BGP routers exchange network reachability information, called path vectors, made up of
path attributes, including a list of the full path (of BGP AS numbers) that a route should
take to reach a destination network. This path information is used in constructing a graph
of autonomous systems that is loop-free. The path is loop-free because a router running
BGP will not accept a routing update that already includes its AS number in the path list—
this would mean that the update has already passed through its AS, and accepting it again
would result in a routing loop. Routing policies can also be applied to the path of BGP AS
numbers to enforce some restrictions on the routing behavior.
BGP Route Selection Decision Process

After BGP receives updates about different destinations from different autonomous
systems, the protocol decides which path to choose to reach a specific destination. BGP
chooses only a single path to reach a specific destination.
The decision process is based on the BGP attributes. When faced with multiple routes to
the same destination, BGP chooses the best route for routing traffic toward the destination.
The following process summarizes how BGP on a Cisco router chooses the best route:
Step 1 If the path is internal, synchronization is on, and the route is not
synchronized (in other words, the route is not in the IGP routing table),
do not consider it.
Step 2 If the next-hop address of a route is not reachable, do not consider it.
Step 3 Prefer the route with the highest weight. (Recall that the weight is Cisco
proprietary and is local to the router only.)
Step 4 If multiple routes have the same weight, prefer the route with the highest
local preference. (Recall that the local preference is used within an AS.)
Step 5 If multiple routes have the same local preference, prefer the route that
was originated by the local router.
Step 6 If multiple routes have the same local preference, or if no route was
originated by the local router, prefer the route with the shortest AS path.
Step 7 If the AS path length is the same, prefer the lowest origin code (IGP <
EGP < incomplete).
Step 8 If all origin codes are the same, prefer the path with the lowest MED.
(Recall that the MED is sent from other autonomous systems.)
The MED comparison is done only if the neighboring autonomous

system is the same for all routes considered, unless the bgp always-
compare-med command is enabled.
NOTE The most recent Internet Engineering Task Force (IETF) decision
regarding BGP MED assigns a value of infinity to the missing MED,
making the route lacking the MED variable as the least preferred. The
default behavior of BGP routers running Cisco IOS software is to treat
routes without the MED attribute as having a MED of 0, making the
route lacking the MED variable the most preferred. To configure the
router to conform to the IETF standard, use the bgp bestpath missing-
as-worst command.
Step 9 If the routes have the same MED, prefer external paths (EBGP) over
internal paths (IBGP).
Step 10 If synchronization is disabled and only internal paths remain, prefer the
path through the closest IGP neighbor. This means that the router will
prefer the shortest internal path within the AS to reach the destination
(the shortest path to the BGP next hop).
Step 11 For EBGP paths, select the oldest route, to minimize the effect of routes
going up and down (flapping).
Step 12 Prefer the route with the lowest neighbor BGP router ID value.
Step 13 Prefer the route with the lowest neighbor IP address.
NOTE Remember that for some attributes, the highest value is preferred (for example, the weight
attribute); for others, the lowest value is preferred (for example, the MED attribute).
The path is put in the routing table and is propagated to the router’s BGP neighbors.
BGP Multihoming
In the example shown in Figure 9-5, AS 64520 is connected to two ISPs, AS 65000 and AS
65250, using BGP. AS 64520 is said to have a multihomed connection to the Internet and
will choose the path that it takes to various destinations as detailed in the decision process
in the previous section, “BGP Route Selection Decision Process.”
Controlling Routing Updates and Policies 541
Figure 9-5 AS 64520 Is Multihomed
172.25.0.0
E
BGP BGP
AS 65500
ISP
172.20.0.0 ISP
AS 65000 BGP 172.30.0.0

B AS 65250
10.10.10.2
C
10.10.20.1
BGP
BGP
10.10.20.2
10.10.10.1
A
AS 64520
Controlling Routing Updates and Policies

This section reviews some of the features available to control routing updates and policies.
The following subjects are covered:
• Route filters with distribute lists
• Route maps
• Policy-based routing
• BGP policy control
Route Filters with Distribute Lists

The Cisco IOS software can filter incoming and outgoing routing updates by using
distribute lists that use access lists. In general, the process the router uses is as follows:
Step 1 The router receives a routing update or is getting ready to send an update
about one or more networks.
Step 2 The router looks at the interface involved with the action.
For example, if it is an incoming update, then the interface on which it

arrived is checked. If it is an update that must be advertised, the interface
out of which it should be advertised is checked.
Step 3 The router determines whether a filter is associated with the interface.
Step 4 If a filter is associated with the interface, the router views the access list
to learn if there is a match for the given routing update.
If a filter is not associated with the interface, the packet is processed as
normal.
Step 5 If there is a match, the route entry is processed as configured.
If no match is found in the access list, the implicit deny any at the end of
the access list will cause the update to be dropped.
This process is illustrated in Figure 9-6.
Figure 9-6 Incoming and Outgoing Routing Updates Can Be Filtered Using Distribute Lists
Routing
update
Determine
Is there a Is there an Process entry
interface Yes Yes
filter for this entry for this according to filter
interface? address? configuration
No No
Process packet Drop packet End

normally
End
Route Maps
A route map is a method used to control and modify routing information. This is done by
defining conditions for redistributing routes from one routing protocol to another, or by
controlling routing information when injected in and out of BGP.
Route Redistribution 543
Route maps are complex access lists that allow some conditions to be tested against the
route in question. If the conditions match, some actions can be taken to modify the route.
These actions are specified by set commands.
In today’s high-performance internetworks, organizations need the freedom to implement
packet forwarding and routing according to their own defined policies in a way that goes
beyond traditional routing protocol concerns. By using policy-based routing, introduced in
Cisco IOS Release 11.0, policies that selectively cause packets to take different paths can
be implemented.
Policy-based routing also provides a mechanism to mark packets with different types of
service (ToS). This feature can be used in conjunction with Cisco IOS queuing techniques
so that certain kinds of traffic can receive preferential service.
Policy-based routing is applied to incoming packets. All packets received on an interface
with policy-based routing enabled are considered for policy-based routing. The router
passes the packets through a route map. Based on the criteria defined in a route map,
packets are forwarded to the appropriate next hop.
BGP Policy Control

BGP has additional features for controlling update traffic. If you want to restrict the BGP
routing information that the Cisco IOS software learns or advertises, you can filter BGP
routing updates to and from particular neighbors. To do this, you can define either an access
list or a prefix list, and apply it to the updates. Distribute lists use access lists to specify what
routing information is to be filtered. Distribute lists for BGP have been obsoleted by prefix
lists in the Cisco IOS; prefix lists are available only in Cisco IOS Release 12.0 and later.
Route Redistribution
This section reviews route redistribution. The following subjects are covered:
• When to use multiple routing protocols
• Redistribution overview
• Redistribution implementation guidelines
When to Use Multiple Routing Protocols

Sometimes you may need to use multiple routing protocols. Some reasons you may need
multiple routing protocols are as follows:
• When you are migrating from an older IGP to a new IGP, multiple redistribution
boundaries may exist until the new protocol has displaced the old protocol completely.
Dual existence of protocols during migration is effectively the same as long-term
coexistence of the protocols.
• You want to use another protocol but need to keep the old protocol due to the needs
of host systems.
• Different departments might not want to upgrade their routers, or they might not
implement a sufficiently strict filtering policy. In these cases, you can protect yourself
by terminating the other routing protocol on one of your routers.
• If you have a mixed-router vendor environment, you can use a Cisco-specific protocol
in the Cisco portion of the network, and then use a common protocol to communicate
with non-Cisco devices.
Redistribution Overview
When any of the situations mentioned in the previous section arises, Cisco routers allow
internetworks using different routing protocols (referred to as autonomous systems) to
exchange routing information through a feature called route redistribution. Redistribution
is defined as the capability of boundary routers connecting different autonomous systems
to exchange and advertise routing information received from one autonomous system to the
other autonomous system.
NOTE The term autonomous system as used here denotes internetworks using different routing
protocols. These routing protocols may be IGPs and/or EGPs. This is a different use of the
term autonomous system than used when discussing BGP.
Within each autonomous system, the internal routers have complete knowledge about their
network. The router interconnecting autonomous systems is called a boundary router.
In the example shown in Figure 9-7, AS 200 is running IGRP and AS 300 is running EIGRP.
The internal routers within each autonomous system have complete knowledge about their
networks. Router A is the boundary router; it has both IGRP and EIGRP processes active
and is responsible for advertising routes learned from one autonomous system into the other
autonomous system.
Route Redistribution 545
Figure 9-7 Router A Is Redistributing Between IGRP 200 and EIGRP 300
Boundary
router
AS 200 AS 300
IGRP S0 EIGRP
S1
172.16.0.0 C B 192.168.5.0
A
IP routing table S1 advertises routes from IP routing table

EIGRP to IGRP
I 192.168.5.0 D EX 172.16.0.0
I 172.16.1.0 D 192.168.5.8
I 172.16.2.0 S0 advertises routes from D 192.168.5.16
I 172.16.3.0 IGRP to EIGRP D 192.168.5.24
In this example, Router A learns about network 192.168.5.0 from Router B via the EIGRP
protocol running on its S0 interface. It passes that information to Router C on its S1
interface via IGRP. Routing information is also passed the other way, from IGRP into
EIGRP.
Router B’s routing table shows that it has learned about network 172.16.0.0 via EIGRP (as
indicated by the “D” in the routing table), and that the route is external to this autonomous
system (as indicated by the “EX” in the routing table). Router C’s routing table shows that
it has learned about network 192.168.5.0 via IGRP (as indicated by the “I” in the routing
table). Note that there is no indication in IGRP of whether the route is external to the
autonomous system.
Redistribution Implementation Guidelines

At a high level, Cisco recommends that you consider employing the following guidelines
when using redistribution, as illustrated in Figure 9-8:
• Be familiar with your network and your network traffic—This is the overriding
recommendation. There are many ways to implement redistribution, so knowing your
network will enable you to make the best decision.
• Do not overlap routing protocols—Do not run two different protocols in the same
internetwork. Instead, have distinct boundaries between networks that use different
protocols.
• One-way redistribution—To avoid routing loops and problems with varying
convergence time, allow routes to be exchanged in only one direction, not both
directions. In the other direction, you should consider using a default or static route.
• Two-way redistribution—If you must allow two-way redistribution, enable a

mechanism to reduce the chances of routing loops. Examples of mechanisms are
default routes, route filters, modification of the metrics advertised, and modification
of the administrative distance of one of the protocols. With these types of
mechanisms, you can reduce the chances of routes imported from one autonomous
system being reinjected into the same autonomous system as new route information.
Figure 9-8 Guidelines for Redistributing Between Autonomous Systems
IGRP/OSPF
IGRP Redistribute
OSPF
Default or static
Redistribute
IGRP
OSPF
Redistribute and filter or change

administrative distance
Case Study: Summary

Refer to Chapter 1, “Routing Principles,” for introductory information on the JKL case
study.
This case study acts as a summary of all the topics covered in earlier chapters. It reinforces
the quantity of the information that has been discussed earlier.
Throughout this book, we have been using a case study of JKL Corporation, as illustrated
in Figure 9-9, to discuss various aspects of scalable routing. The case study was used to
review key concepts, discuss critical issues surrounding network operation, and provide a
focus for the configuration exercises.
Case Study: Summary 547
Figure 9-9 JKL Corporation Used in Case Study Sections Throughout the Book
Internet
Acquisition A Acquisition C
1 Class A—Private 1 Class B—Public
2 Class C—Public OSPF Area 0—All
IGRP AS 350, RIP JKL Corporation Multivendor equipment
OSPF Area 0—Small 1 Class B—Public No summarization
Recently redesigned, optimal
OSPF area 0—Small, redundant
Acquisition B OSPF multiarea, hierarchical
Acquisition D
VLSM with route summarization
3 Class C—Public 1 Class B—Public
IP RIP only 1 Class C—Private
500 Devices, out of address EIGRP AS 400
6 Hops Discontiguous subnets
JKL’s problem: How to integrate acquisitions A–D?
JKL is an enterprise that is making four acquisitions: A, B, C, and D. JKL’s ultimate goal
is to integrate the acquired networks with its own network.
You have seen the multiarea OSPF design used within JKL, including VLSM and route
summarization. JKL has a Class B public address. Recall that JKL has two ISP connections.
You have seen that Acquisition A is using a mixture of routing protocols: RIP, IGRP, and
OSPF. It has two Class C public addresses and uses a Class A private address. We have
discussed how Acquisition A will redistribute routing information between the three
routing domains.
You have seen that Acquisition B is using three Class C public addresses and is using only
IP RIP as its routing protocol. It has run out of IP addresses.
Recall that Acquisition C has a multivendor environment and is using OSPF and one Class
B public address. It is not using summarization.
You have also seen that Acquisition D is using EIGRP, has one Class B public and one Class
C private address, and has discontiguous subnets.
In this last case study, you will look at what would be the most appropriate way for JKL to
integrate these acquisitions into its own network. Analyze the following topics with respect
to Figure 9-9:
• Routing domains, including scaling issues:
— Are there any parts of the acquisition’s networks that do not scale? How
should these be incorporated into JKL’s network?
— Should the routing protocols in any of the acquisitions be changed to

another protocol? What issues would be involved in selecting those that
should be changed?
— Where in JKL’s network should the other networks be integrated? Should
they be part of Area 0, or should new areas be added in some cases?
• Redistribution between different routing protocols:
— If the resulting JKL network has more than one routing protocol, how will
redistribution be handled?
— What issues may arise when configuring redistribution in this network?
— Will any filtering be necessary?
• Addressing:
— How will all the current addresses be incorporated into the integrated
network?
— If private addresses are kept, what will be required to access the Internet?
• Internet access:
— In the integrated network, where will access to the Internet be
implemented?
— Will BGP be used for the Internet connections?
Case Study Solution

The answers to this chapter’s case study questions are as follows.
Routing domains, including scaling issues:
• Are there any parts of the acquisition’s networks that do not scale?
Yes, Acquisition B is out of addresses. Acquisition C could grow to a degree that
it could have more than 50 routers, and it would then be advisable to create
separate areas for that network.
• How should these be incorporated into JKL’s network?
Allocate one or more Class C private addresses for Acquisition B, and use NAT
to translate the private addresses to one of its public address spaces. Acquisition
C should join the JKL OSPF backbone as a separate area and be reorganized to
control its growth.
• Should the routing protocols in any of the acquisitions be changed to another
protocol? What issues would be involved in selecting those that should be changed?
Case Study: Summary 549
Acquisition B is the only candidate, although this is not a requirement. One

possibility is to convert part of the network to OSPF and redistribute the RIP
networks into it. If this step is accomplished, Acquisition B could join the JKL
OSPF backbone as another area.
Some issues to be considered include these:
— The ease of converting a portion of the network
— The effect that the new routing protocol would have on any current
network problems
— The effect that the conversion would have on the size of the routing
table
• Where in JKL’s network should the other networks be integrated? Should they be part
of Area 0, or should new areas be added in some cases?
Acquisition A—Convert its Area 0 number to another number, and add it to JKL
as another area attached to the backbone.
Acquisition B—Inject the three Class C addresses into JKL via an ASBR in Area
0. Alternately, if part of the Acquisition B network is converted to OSPF, that
area could be attached to the JKL backbone and the three Class C addresses
would be routed normally.
Acquisition C—The Acquisition C Area 0 should be converted to another area
number (or separated into multiple areas), and that area could be attached to the
JKL backbone and the Class B address would be routed normally.
Acquisition D—Inject the Class B address into JKL via an ASBR in Area 0.
Redistribution between different routing protocols:
• If the resulting JKL network has more than one routing protocol, how will
redistribution be handled?
Acquisition A is already handling redistribution into its local area; this would not
change if it joined JKL’s backbone.
Acquisitions B and D would be separate autonomous systems to JKL, and
redistribution would be handled at the ASBR in the backbone. Alternately, if
part of the Acquisition B network is converted to OSPF, redistribution will take
place local to Acquisition B.
• What issues may arise when configuring redistribution in this network?
Very few issues would be anticipated, but Acquisition D could be a problem due
to the lower administrative distance of its EIGRP protocol versus OSPF.
• Will any filtering be necessary?
Route feedback filters should already be present in Acquisition A, but no

additional filters should be required. If part of the Acquisition B network is
converted to OSPF, then filtering may be necessary for the redistribution within
Acquisition B.
Addressing:
• How will all the current addresses be incorporated into the integrated network?
The acquisitions all had some registered public addresses before the planned
integration began; as such, those addresses will be retained. For acquisitions B
and D, the addresses will be automatically summarized to the classful boundary
before entering the JKL backbone (unless Acquisition B is also converted to
OSPF). Acquisitions A and C (and possibly B) will require manual
summarization at the ABR because their addresses are sourced by OSPF.
• If private addresses are kept, what will be required to access the Internet?
NAT will be required at key locations within the acquisitions to simplify the
integration into the JKL network. NAT was already in place within Acquisition
A because there was an existing Internet connection via the OSPF Class C public
network. In addition, NAT is already in place within Acquisition D because of the
remote office usage of a private Class C address space.
Internet access:
• In the integrated network, where will access to the Internet be implemented?
Existing connections from the acquisitions to ISPs will be terminated. For the
new integrated network, Internet access will be through the JKL backbone.
• Will BGP be used for the Internet connections?
Yes, the only change will be the addition of the seven networks (the public
networks owned by the acquisitions) that JKL will advertise to its ISPs.
Summary
This chapter reviewed a lot of the material that you learned in previous chapters.
You learned that routers perform two major functions: routing and switching.
There are many ways to categorize routing protocols; one way is whether they are classful
or classless. Classful routing protocols do not carry subnet masks and automatically
summarize routes at major network boundaries. Classless routing protocols do carry subnet
masks and can usually summarize routes at any bit boundary.
VLSMs provide the capability to include more than one subnet mask within a network, and
the capability to subnet an already subnetted network address.
Configuration Exercise: Super Lab, Part I 551
Route summarization is a method of representing a series of network numbers in a single

summary address.
With CIDR, blocks of multiple Class C addresses can be combined, or aggregated, to create
a larger classless set of IP addresses.
An autonomous system is a collection of networks under a single technical administration.
BGP is used between autonomous systems. BGP uses TCP port 179 and has a complex
decision process to determine the best path.
Route maps are complex access lists. Some conditions are tested against the route in
question; if the conditions match, some actions can be taken to modify the route. These
actions are specified by set commands.
Policy-based routing is applied to incoming packets.
BGP policy control can be done with distribute lists (using access lists) or with prefix lists.
Prefix lists are available only in Cisco IOS Release 12.0 and later.
Route redistribution allows routes discovered by one routing process to be advertised in the
updates of another process.
Configuration Exercise: Super Lab, Part I
This is the first of two parts of a summary Configuration Exercise.

Objectives
In this Configuration Exercise, you will configure EIGRP within your pod, OSPF to the
backbone_r1 router, and redistribution between the two routing protocols. You will also
perform route filtering and route summarization, and verify that your configuration works.
Visual Objective
Figure 9-10 illustrates the visual objective of this configuration exercise.
Figure 9-10 Super Lab, Part I, Configuration Exercise Topology
172.16.10.100/24
172.16.11.100/24
loopback
backbone_r1 10.12.12.100/24
OSPF
10.1.1.100/24
Area 0
10.1.1.1/24 10.12.12.12/24
EIGRP EIGRP EIGRP EIGRP

101 102 103
. . . . . 112
Pod 1 Pod 2 Pod 3 Pod 12
Command List
You must determine which commands are necessary to complete this Configuration
Exercise.
Setup
Do an erase start and reload on the pxr1, pxr2, and pxr3 routers within your pod.
Configuration Exercise: Super Lab, Part I 553
Task: Super Lab, Part I, Configuration

Determine the necessary tasks to perform to complete the following steps:
Step 1 Use a clock rate of 64000 on your serial interfaces. Set the bandwidth of
your serial interfaces to 64 Kbps. Set the passwords on all routers to the
following:
Secret: cisco
Enable: sanfran
Vty: cisco
Step 2 Use the same IP address scheme as in the previous Configuration
Exercises to configure your pod. The addresses are provided in the
following table.
Router Interface IP Address Subnet Mask

pxr1 S0 192.168.x.17 255.255.255.240
pxr1 S1 192.168.x.33 255.255.255.240
pxr1 S2 192.168.x.49 255.255.255.240
pxr1 S3 10.x.x.x 255.255.255.0
pxr2 S0 192.168.x.18 255.255.255.240
pxr2 S1 192.168.x.34 255.255.255.240
pxr2 E0 192.168.x.65 255.255.255.240
pxr3 S0 192.168.x.50 255.255.255.240
pxr3 E0 192.168.x.66 255.255.255.240
Step 3 Configure EIGRP within your pod (use AS number 10x, where x is your
pod number).
Step 4 Configure OSPF connectivity from your pxr1 router to the backbone_r1
router.
Step 5 Perform the route redistribution between OSPF and EIGRP at your pxr1
router.
Step 6 Perform route filtering to only block the 172.16.11.0/24 network from
being redistributed from OSPF into EIGRP.
Step 7 At your pxr1 router, enable OSPF to announce only a summarized route
of 192.168.x.0/24 to the other pods (where x is your pod number).
Step 8 Verify connectivity. Your pxr2 and pxr3 routers should have the capability
to ping the 172.16.10.100 loopback interface, but not the 172.16.11.100
loopback interface, of the backbone_r1 router. You may also ping the
interfaces on the routers of other pods, if other pods are configured. Your
pxr2 and pxr3 routers should have the capability to ping the 10.x.x.0
network.
Completion Criteria
You have completed Part I of the Super Lab Configuration Exercise if all the routers within
your pod can ping the 172.16.10.100 loopback interface, but not the 172.16.11.100
loopback interface, of the backbone_r1 router. Your pxr2 and pxr3 routers should also be
able to ping 10.x.x.100 on the backbone_r1 router.
Configuration Exercise: Super Lab, Part II

This is the second of two parts of a summary Configuration Exercise.
Objectives
In this Configuration Exercise, you will establish EBGP connectivity from your pxr3 router
to the backbone_r2 router.
Visual Objective
Figure 9-11 illustrates the visual objective of this Configuration Exercise.
Configuration Exercise: Super Lab, Part II 555
Figure 9-11 Super Lab, Part II, Configuration Exercise Topology
172.16.10.100/24
172.16.11.100/24
loopback
backbone_r1 10.12.12.100/24
OSPF
10.1.1.100/24
Area 0
10.1.1.1/24 10.12.12.12/24
EIGRP EIGRP EIGRP EIGRP

101 102 103 . . . . . 112
Pod 1 Pod 2 Pod 3 Pod 12 BGP 65112
172.221.1 172.22.12.12
BGP 65101
EBGP EBGP
172.22.12.100
172.22.1.100
172.31.20.100/24
loopback
172.31.21.100/24
backbone_r2
BGP
AS 65201
Command List
You must determine which commands are necessary to complete this Configuration
Exercise.
Setup
Ensure that Part I of the Super Lab is working properly before proceeding with this part.
Task: Super Lab, Part II, Configuration

Determine the necessary tasks to perform to complete the following steps:
Step 1 Enable EBGP connectivity between your pxr3 router and the
backbone_r2 router (in AS 65201) using the IP addresses and AS
numbers shown in the following table.
AS Corresponding Backbone_r2
Pod Number Your pxr3 S1 IP Address Serial Interface IP Address
1 65101 172.22.1.1/24 172.22.1.100/24
2 65102 172.22.2.2/24 172.22.2.100/24
3 65103 172.22.3.3/24 172.22.3.100/24
4 65104 172.22.4.4/24 172.22.4.100/24
5 65105 172.22.5.5/24 172.22.5.100/24
6 65106 172.22.6.6/24 172.22.6.100/24
7 65107 172.22.7.7/24 172.22.7.100/24
8 65108 172.22.8.8/24 172.22.8.100/24
9 65109 172.22.9.9/24 172.22.9.100/24
10 65110 172.22.10.10/24 172.22.10.100/24
11 65111 172.22.11.11/24 172.22.11.100/24
12 65112 172.22.12.12/24 172.22.12.100/24
Step 2 Only advertise your 192.168.x.0/24 and your 10.x.x.0/24 networks, and
the 172.16.0.0/16 network, to the backbone_r2 router via your EBGP
connection.
NOTE Do not redistribute BGP into EIGRP.
Step 3 Your pxr2 and pxr1 routers within your pod should use a default route to
access the loopback interfaces of the backbone_r2 router. Configure your
pxr3 router so that it will advertise a default route to your pxr1 and pxr2
routers. The default route should point toward the backbone_r2 router.
Configuration Exercise: Super Lab, Part II 557
(Hint: Use the ip route 0.0.0.0 0.0.0.0 S1 command and don’t forget to
add a network 0.0.0.0 statement under EIGRP to allow advertisement of
the default route.)
Step 4 You should be able to ping from any router within your pod to
172.31.20.100 (one of the loopback addresses on the backbone_r2
router).
NOTE You will not be able to ping from the backbone_r1 router to 172.31.20.100 because the
backbone_r1 router has no route to network 172.31.20.0/24. Perform the bonus step in this
section to enable connectivity from the backbone_r1 router to the backbone_r2 router.
Step 5 Bonus step (This step should only be performed on one pod at one time.)
Telnet to the backbone_r1 router. Add a default route in the backbone_r1

router, pointing the default route to your pxr1 router. (The backbone_r1
router will use the default route to reach 172.31.20.100.)
You should now be able to ping from the backbone_r1 router to
172.31.20.100.
Trace from the backbone_r1 router to 172.31.20.100. Ensure that the
path taken is through your pod.
Telnet to the backbone_r2 router, and display the routing table of the
backbone_r2 router. Which is the preferred path from the backbone_r2
router to network 172.16.0.0/16 (the loopback address on the
backbone_r1 router)? At the backbone_r2 router, set the weight attribute
in the BGP neighbor statement to your pxr3 router so that the
backbone_r2 router will prefer your pxr3 route to the others.
Clear all the BGP sessions from the backbone_r2 router.
You should be able to ping from the backbone_r2 router to
172.16.10.100.
Trace from the backbone_r2 router to 172.16.10.100. Ensure that the
path taken is through your pod.
Remove your default route from the backbone_r1 router and the weight
configuration at the backbone_r2 router when you are done.
Completion Criteria
You have completed Part II of the Super Lab Configuration Exercise if all your routers
within your pod can ping the loopback interface of the backbone_r2 router. If you
performed the bonus step, the backbone_r1 router should also have the capability to ping
the loopback interface of the backbone_r2 router.
Answers to Configuration Exercise: Super Lab, Part I

This section provides the answers to the questions in the first Super Lab Configuration
Exercise. The answers are in bold.
Answers to Setup
The following example shows how to erase and reload the p1r1 router.
p1r1#erase start
Erasing the nvram filesystem will remove all files! Continue? [confirm]
[OK]
Erase of nvram: complete
p1r1#reload
Proceed with reload? [confirm]
System Bootstrap, Version 11.0(10c), SOFTWARE

Copyright 1986-1996 by cisco Systems
Answers to Task: Super Lab, Part I, Configuration

The answers are provided for the routers in pod 1. Pod 2 is also configured to
allow some interesting aspects of the Configuration Exercise to be viewed.
NOTE In some cases, the answers for multiple steps are combined; the answers appear after the
steps to be answered are shown.
Step 1 Use a clock rate of 64000 on your serial interfaces. Set the bandwidth of
your serial interfaces to 64 Kbps. Set the passwords on all routers to the
following:
• Secret: cisco
• Enable: sanfran
• Vty: cisco

CCNPTraining Kit

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CCNPTraining Kit

Загружено:

Авторское право:

Доступные форматы

78700914.

book Page 18 Thursday, August 23, 2001 3:15 PM

18 Chapter 2: Selecting Cisco Products for Remote Connections

Defining WAN Connection Types

Figure 2-1 Links Are Always Available with Dedicated Connections

Defining WAN Connection Types 19

Pricing Strategies of WAN Services

20 Chapter 2: Selecting Cisco Products for Remote Connections

Typical circuit-switched connections are as follows:

Asynchronous Serial Connections

Defining WAN Connection Types 21

Figure 2-3 Circuit-Switched Connection with ISDN

22 Chapter 2: Selecting Cisco Products for Remote Connections

Figure 2-4 VCs—Interconnect Sites

Packet-switched networks can be either privately or publicly managed. The underlying

Defining WAN Encapsulation Protocols 23

Defining WAN Encapsulation Protocols

24 Chapter 2: Selecting Cisco Products for Remote Connections

Figure 2-5 Overview of PPP Components

Link setup and control

X.25 and Frame Encapsulations

Selecting WAN Configuration Types 25

Determining the WAN Type to Use

Selecting WAN Configuration Types

26 Chapter 2: Selecting Cisco Products for Remote Connections

Figure 2-6 Selection Considerations: Bandwidth and Connection Duration

WAN Connections—Speed Comparison

Figure 2-7 Typical WAN Speeds

Leased line, Frame Relay

9.6k 56/64 kbps 128 kbps E1/T1 E3/T3

Theoretical maximum WAN speeds

Identifying Site Requirements 27

WAN Connections Summary

Identifying Site Requirements

Identifying Site Requirements 29

Branch Office Considerations

30 Chapter 2: Selecting Cisco Products for Remote Connections

32 Chapter 2: Selecting Cisco Products for Remote Connections

Small office solutions

Selecting Cisco Remote Access Solutions 33

Selecting Products with Cisco Product-Selection Tools 35

Figure 2-11 Modular Configuration Router

Vacant chassis slot

10BaseT AUI port

WAN interface cards 10BaseT LEDs

Selecting Products with Cisco Product-Selection Tools

40 Chapter 3: Assembling and Cabling the WAN Components

The branch office router must have the following interface:

The telecommuter site must have the following interfaces:

Identifying Company Site Equipment

Identifying Company Site Equipment 41

Central Site Router Equipment

Cisco 3600 series

Cisco 4000 series

Cisco AS5x00 series

Cisco 7000 series

42 Chapter 3: Assembling and Cabling the WAN Components

Branch Office Router Equipment

Cisco 1600 Series

Cisco 1700 Series

Cisco 2500 Series

Cisco 2600 Series