Networking Extras PDF

Basic WAN Concepts v1.
15 – Aaron Balchunas 1
- Basic WAN Concepts -

What is a WAN?
There are two prevailing definitions of a Wide Area Network (WAN). The
book definition of a WAN is a network that spans large geographical
locations, usually to interconnect multiple Local Area Networks (LANs).
The practical definition of a WAN is a network that traverses a public
network or commercial carrier, using one of several WAN technologies.
Consider the following example.

A connection between two
buildings using Ethernet as a
medium would generally be
considered a LAN. However,
this is because of the technology
used, and not the zombie-
infested distance between the
two buildings.
A connection between the

same two buildings, using a
dedicated T1 line as a
medium, would generally be
considered a WAN.
Remember, the difference is the

technology used. A variety of
WAN technologies exist, each
operating at both the Physical and
Data-link layers of the OSI
models. Higher-layer protocols
such as IP are encapsulated when
sent across the WAN link.
***
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Basic WAN Concepts v1.15 – Aaron Balchunas 2
WAN Connection Types

WANs are generally grouped into three separate connection types:
• Point-to-Point technologies
• Circuit-switched technologies
• Packet-switched technologies
Point-to-Point technologies (often called dedicated or leased lines) are
usually the most expensive form of WAN technology. Point-to-Point
technologies are leased from a service provider, and provide guaranteed
bandwidth from location to another (hence point-to-point). Cost is
determined by the distance of the connection, and the amount of bandwidth
allocated.
Generally, point-to-point links require no call-setup, and the connection is
usually always on. Examples of point-to-point technologies include:
• T1 lines
• T3 lines
Circuit-Switched technologies require call-setup to occur before
information can be transferred. The session is usually torn down once data
transfer is complete (this is identified as an On-Demand Circuit). Circuit-
switched lines are generally low-speed compared to point-to-point lines.
Examples of circuit-switched technologies include:
• Dial-up
• ISDN
Packet-Switched technologies share a common infrastructure between all
the provider’s subscribers. Thus, bandwidth is not guaranteed, but is instead
allocated on a best effort basis. Packet-switched technologies are ill-suited
for applications that require consistent bandwidth, but are considerably less
expensive than dedicated point-to-point lines.
Examples of packet-switched technologies include:
• Frame-Relay
• X25
(Reference: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/introwan.htm
http://www.ciscopress.com/content/images/chap01_1587051486/elementLinks/1587051486content.pdf)
***
Common WAN Terms

A wide variety of hardware is used with WANs. Equipment that is housed at
the subscriber is referred to as Customer Premise Equipment (CPE).
The above example demonstrates the basic equipment required for a T1 line.
A CSU/DSU (Channelized Service Unit/Data Service Unit) provides the
clocking and channelization for T1 or T3 technology. The CSU/DSU
converts the signal for use on an Ethernet (or other LAN technology)
network. If a WAN technology other than a T1 line is used, a different
device will be required. Examples include (but are no limited to):
• ISDN – a terminal adapter
• Dialup – a modem
The Demarc (short for demarcation) refers to the point of last responsibility
for the service provider. All equipment on the Customer Premises side of the
Demarc is the customer’s responsibility to maintain. The Demarc is not
always physically labeled or identifiable. Occasionally, a two-port or four-
port patch-panel will be used as a physical Demarc.
The Smart Jack physically terminates the T1 line. If there is a connectivity
issue, the provider will perform a ping test to the smart jack. If
communication to the smart jack is successful, the provider will assume the
issue resides on the customer’s side of responsibility. The smart jack is often
locked in a glass enclosure, and labeled with the T1’s circuit number.
The Local Loop (or Last Mile) refers to the physical line connecting from
the Customer Premises to the provider’s nearest Central Office (CO).
***
WAN Encapsulation
Recall that WAN technologies operate at both Physical and Data-link
layers of the OSI models, and that higher-layer protocols such as IP are
encapsulated when sent across the WAN link.
A WAN is usually terminated on a Cisco device’s serial interface. Serial
interfaces support a wide variety of WAN encapsulation types, which must
be manually specified.
By default, a serial interface will utilize HDLC for encapsulation. Other
supported encapsulation types include:
• SDLC
• PPP
• LAPB
• Frame-Relay
• X.25
• ATM
Regardless of the WAN encapsulation used, it must identical on both sides
of a point-to-point link.
Each encapsulation type is described in detail in separate guides.
***
NAT v1.22 – Aaron Balchunas 1
- Network Address Translation -

NAT (Network Address Translation)
The rapid growth of the Internet resulted in a shortage of available IPv4
addresses. In response, a specific subset of the IPv4 address space was
designated as private, to temporarily alleviate this problem.
A public address can be routed on the Internet. Thus, devices that must be
Internet-accessible must be configured with (or reachable by) public
addresses. Allocation of public addresses is governed by the Internet
Assigned Numbers Authority (IANA).
A private address is intended for internal use within a home or
organization, and can be freely used by anyone. However, private addresses
can never be routed on the Internet. In fact, Internet routers are configured to
immediately drop traffic with private addresses.
Three private address ranges were defined in RFC 1918, one for each IPv4
class:
• Class A - 10.x.x.x /8
• Class B - 172.16.x.x /12
• Class C - 192.168.x.x /24
It is possible to translate between private and public addresses, using
Network Address Translation (NAT). NAT allows a host configured with
a private address to be stamped with a public address, thus allowing that host
to communicate across the Internet. It is also possible to translate multiple
privately-addressed hosts to a single public address, which conserves the
public address space.
NAT provides an additional benefit – hiding the specific addresses and
addressing structure of the internal (or private) network.
Note: NAT is not restricted to private-to-public address translation, though
that is the most common application. NAT can also perform public-to-public
address translation, as well as private-to-private address translation.
NAT is only a temporarily solution to the address shortage problem. IPv4
will eventually be replaced with IPv6, which supports a vast address space.
Both Cisco IOS devices and PIX/ASA firewalls support NAT.
***
Types of NAT
NAT can be implemented using one of three methods:
Static NAT – performs a static one-to-one translation between two
addresses, or between a port on one address to a port on another address.
Static NAT is most often used to assign a public address to a device behind a
NAT-enabled firewall/router.
Dynamic NAT – utilizes a pool of global addresses to dynamically translate
the outbound traffic of clients behind a NAT-enabled device.
NAT Overload or Port Address Translation (PAT) – translates the
outbound traffic of clients to unique port numbers off of a single global
address. PAT is necessary when the number of internal clients exceeds the
available global addresses.
NAT Terminology
Specific terms are used to identify the various NAT addresses:
• Inside Local – the specific IP address assigned to an inside host
behind a NAT-enabled device (usually a private address).
• Inside Global – the address that identifies an inside host to the
outside world (usually a public address). Essentially, this is the
dynamically or statically-assigned public address assigned to a private
host.
• Outside Global – the address assigned to an outside host (usually a
public address).
• Outside Local – the address that identifies an outside host to the
inside network. Often, this is the same address as the Outside Global.
However, it is occasionally necessary to translate an outside (usually
public) address to an inside (usually private) address.
For simplicity sake, it is generally acceptable to associate global addresses
with public addresses, and local addresses with private addresses.
However, remember that public-to-public and private-to-private translation
is still possible. Inside hosts are within the local network, while outside
hosts are external to the local network.
***
NAT Terminology Example
Consider the above example. For a connection from HostA to HostB, the
NAT addresses are identified as follows:
• Inside Local Address - 10.1.1.10
• Inside Global Address - 55.1.1.1
• Outside Global Address – 99.1.1.2
• Outside Local Address – 99.1.1.2
HostA’s configured address is 10.1.1.10, and is identified as its Inside Local
address. When HostA communicates with the Internet, it is stamped with
RouterA’s public address, using PAT. Thus, HostA’s Inside Global address
will become 55.1.1.1.
When HostA communicates with HostB, it will access HostB’s Outside
Global address of 99.1.1.2. In this instance, the Outside Local address is also
99.1.1.2. HostA is never aware of HostB’s configured address.
It is possible to map an address from the local network (such as 10.1.1.5) to
the global address of the remote device (in this case, 99.1.1.2). This may be
required if a legacy device exists that will only communicate with the local
subnet. In this instance, the Outside Local address would be 10.1.1.5.
Static NAT Translation
99.1.1.2 = 192.168.1.5
10.1.1.1 55.1.1.1 99.1.1.1 192.168.1.1

Internet
RouterA RouterA
HostA NAT-Enabled NAT-Enabled HostB
10.1.1.10 192.168.1.5
SRC Address = 10.1.1.10 SRC Address = 55.1.1.1:31092 SRC Address = 55.1.1.1:31092

DST Address = 99.1.1.2 DST Address = 99.1.1.2 DST Address = 192.168.1.5
The above example demonstrates how the source (SRC) and destination
(DST) IP addresses within the Network-Layer header are translated by NAT.
(Reference: http://www.cisco.com/warp/public/556/8.html)
***
Configuring Static NAT

The first step to configure Static NAT is to identify the inside (usually
private) and outside (usually public) interfaces:
Router(config)# int e0/0 Router(config)# int s0/0
Router(config-if)# ip nat inside Router(config-if)# ip nat outside
To statically map a public address to a private address, the syntax is as

follows:
Router(config)# ip nat inside source static 172.16.1.1 158.80.1.40
This command performs a static translation of the source address 172.16.1.1

(located on the inside of the network), to the outside address of 158.80.1.40.
Configuring Dynamic NAT

When configuring Dynamic NAT, the inside and outside interfaces must
first be identified:
Router(config)# int e0/0 Router(config)# int s0/0
Router(config-if)# ip nat inside Router(config-if)# ip nat outside
Next, a pool of global addresses must be specified. Inside hosts will

dynamically choose the next available address in this pool, when
communicating outside the local network:
Router(config)# ip nat pool POOLNAME 158.80.1.1 158.80.1.50 netmask
255.255.255.0
The above command specifies that the pool named POOLNAME contains a
range of public addresses from 158.80.1.1 through 158.80.1.50.
Finally, a list of private addresses that are allowed to be dynamically
translated must be specified:
Router(config)# ip nat inside source list 10 pool POOLNAME
Router(config)# access-list 10 permit 172.16.1.0 0.0.0.255
The first command states that any inside host with a source that matches
access-list 10 can be translated to any address in the pool named
POOLNAME.
The access-list specifies any host on the 172.16.1.0 network.
***
Configuring NAT Overload (or PAT)

Recall that NAT Overload (or PAT) is necessary when the number of
internal clients exceeds the available global addresses. Each internal host is
translated to a unique port number off of a single global address.
Configuring NAT overload is relatively simple:
Router(config)# int e0/0
Router(config-if)# ip nat inside
Router(config)# int s0/0
Router(config-if)# ip nat outside
Router(config)# ip nat inside source list 10 interface Serial0/0 overload
Any inside host with a source that matches access-list 10 will be translated
with overload to the IP address configured on the Serial0/0 interface.
Troubleshooting NAT
To view all current static and dynamic translations:
Router# show ip nat translations
To view whether an interface is configure as an inside or outside NAT

interface, and to display statistical information regarding active NAT
translations:
Router# show ip nat statistics
To view NAT translations in real-time:

Router# debug ip nat
To clear all dynamic NAT entries from the translation table:

Router# clear ip nat translation
***
PPP v.1.12 – Aaron Balchunas 1
- Point-to-Point Protocol -
WAN Encapsulation
Recall that WAN technologies operate at both Physical and Data-link
layers of the OSI models, and that higher-layer protocols such as IP are
encapsulated when sent across the WAN link.
A WAN is usually terminated on a Cisco device’s serial interface. Serial
interfaces support a wide variety of WAN encapsulation types, which must
be manually specified.
By default, a serial interface will utilize HDLC for encapsulation. Other
supported encapsulation types include:
• SDLC
• PPP
• LAPB
• Frame-Relay
• X.25
• ATM
Regardless of the WAN encapsulation used, it must identical on both sides
of a point-to-point link.
HDLC Encapsulation
High-Level Data-link Control (HDLC) is a WAN encapsulation protocol
used on dedicated point-to-point serial lines.
Though HDLC is technically an ISO standard protocol, Cisco’s
implementation of HDLC is proprietary, and will not work with other
routers.
HDLC is also Cisco’s default encapsulation type for serial point-to-point
links. HDLC provides no authentication mechanism.
***
PPP Encapsulation
Point-to-Point Protocol (PPP) is a standardized WAN encapsulation protocol
that can be used on a wide variety of WAN technologies, including:
• Dedicated point-to-point serial lines
• Asynchronous dial-up links
• ISDN
PPP has four components:
• Physical – standard for physical serial communication (such as
EIA/TIA-232-C, V.35, ISDN, etc.).
• HDLC – for encapsulating packets into frames over serial lines.
• LCP – for establishing, maintaining, and terminating point-to-point
links.
• NCP – allows multiple Layer-3 protocols (such as IP and IPX) to be
encapsulated into frames.
PPP supports several features that standalone HDLC does not:

• Authentication – secures the communication by forcing the
sending/receiving devices to identify themselves with a username and
password. PPP supports two forms of authentication – PAP and
CHAP.
• Compression – improves efficiency on slow links. PPP supports two
forms of compression: Stac and Predictor.
• Multilink – allows multiple channels to be bundled or trunked
together to combine the bandwidth. The bundled channels are treated
as one logical channel.
• Callback – provides security and billing services. Allows a client to
first dial a PPP server, disconnect, and then have the PPP server call
the client back.
• Error Control
***
Configuring Basic PPP

To configure a serial interface for PPP encapsulation:
Router(config-if)# encapsulation ppp
Recall that PPP supports two methods of authentication, PAP and CHAP.
PAP (Password Authentication Protocol) sends passwords in clear text,
and thus does not provide much security. CHAP (Challenge Handshake
Authentication Protocol) uses MD5 to apply an irreversible hash.
To configure PPP authentication:
Router(config)# hostname Router1
Router(config)# username Router2 password PASSWORD
Router(config-if)# ppp authentication chap
The first line sets the hostname of the router. The second line sets the
username and password used for PPP authentication. The username must be
the hostname of the remote router, and the password must be the same on
both routers.
The above configuration sets the authentication to chap. To instead
configure pap authentication:
Router(config-if)# ppp authentication pap
To view the encapsulation configured on the interface:

Router# show interface s0/0
To troubleshoot PPP authentication between two routers:

Router# debug ppp authentication
More advanced PPP configuration is discussed in the ISDN guide.
***
ISDN v1.11 – Aaron Balchunas 1
- Integrated Services Digital Network -

ISDN (Integrated Services Digital Network)
ISDN is a circuit-switched digital service that can transmits voice and data
over existing phone lines. It has faster call setup and bandwidth rates than
dial-up connections, and is often utilized as a backup line to a more
expensive dedicated leased line.
Like Frame-Relay, ISDN has layer-2 “switches” that control traffic inside
the ISDN cloud. There are multiple ISDN switch-types.
The cost of ISDN is based on the number of calls made, and the duration of
those calls. Thus, it is not advantageous to have the ISDN connection always
active, nor do you want ISDN calls made every few seconds.
There are two types of ISDN:
• Basic Rate Interface (BRI) - contains two “B” channels, and one
“D” channel. The two B channels carry 64K of bandwidth each, and
are dedicated for data or voice traffic. The single D channel carries
16K of bandwidth, and is dedicated for signaling and call-setup. The
total bandwidth for ISDN BRI is 144K (64K+64K+16K).
• Primary Rate Interface (PRI) - contains twenty-three “B” channels,
and one “D” channel. The twenty-three B channels carry 64K of
bandwidth each, and are dedicated for data or voice traffic. The single
D channel carries 64K of bandwidth, and is dedicated for signaling
and call-setup. The total bandwidth for ISDN PRI is 1.544Mbs
(23x64K+64K).
***
ISDN BRI Fundamentals

BRI is (by far) the most common installation of ISDN. As mentioned
previously, ISDN BRI contains two B channels and one D channel. Each B
channel carries 64K of bandwidth, and can be utilized for either voice or
data. The D channel carries 16K of bandwidth is used for signaling and call-
setup.
The equipment necessary for ISDN is identified with several terms, as is the
“connection” between each device:
A TE2 (Terminal Endpoint 2) identifies a non-ISDN native device

(essentially, a device without an ISDN BRI port). This could be a router or
workstation that does not support ISDN natively.
To connect a TE2 device to an ISDN network, we need a TA (Terminal
Adapter). This is often referred to as the ISDN modem, though it does not
technically modulate or demodulate a signal. The purpose of a TA is to
provide the BRI interface for a non-ISDN device.
The NT1 (Network Termination 1) terminates the local loop from the
ISDN Central Office (CO).
ISDN-native devices have the TA integrated (built-in BRI port). An ISDN
native device is identified as a TE1 (Terminal Endpoint 1):
***
ISDN BRI Layers
ISDN employees three layers to its communication process.

Layer 1 is concerned with the physical ISDN connection. The ISDN BRI
connection eventually connects to an ISDN Switch at the CO. There are
several types of ISDN switches used in the United States, including:
• Basic-5ess
• Basic-dms100
• Basic-ni1
Various alternate switch types exist in other countries. Your ISDN provider
will identify which switch type is being used.
Layer 2 utilizes two protocols on the D Channel, Q.920 and Q.921, to
provide the physical layer addressing for ISDN. TE1’s (or TE2’s + TA’s)
are physically identified using a TEI (Terminal Endpoint Identifier):
• Static TEI’s are numbered 0 – 63
• Dynamically assigned TEI’s are numbered 64-126
The connection is then logically identified using SAPI’s (Service Access
Point Identifiers).
SPIDs (Service Profile Identifiers) are also a component of Layer 2 (only
BRI uses SPIDs, PRI does not). SPIDs identify two things:
• The phone number of each B channel
• The ISDN services you are entitled to.
Not all ISDN switch types require the use of SPIDs.
On the B channels, one of several Layer 2 encapsulations can be used,
including HDLC, PPP, and Frame-Relay.
Layer 3 utilizes just one protocol on the D Channel, Q.931, which controls
call setup and teardown.
***
Configuring Basic ISDN BRI
Cisco routers that support ISDN will have BRI interfaces, or utilize serial
interfaces for PRI connections. This guide will cover only the configuration
of ISDN BRI.
The first thing that must be configured for ISDN is the switch-type, which
can be configured either on the interface or in Global Configuration mode.
The ISDN provider will indicate which ISDN switch-type is used:
Router(config)# isdn switch-type basic-ni
Other basic configuration is completed on the BRI interface:

Router(config)# int bri0/0
Router(config-if)# ip address 172.16.1.1 255.255.0.0
Router(config-if)# isdn spid1 055512120100 5551212
Router(config-if)# isdn spid2 055512130100 5551213
Router(config-if)# dialer string 5552222
Router(config-if)# no shut
PPP is the most common encapsulation for ISDN.

The isdn spid1 and isdn spid2 commands identify the two B channels to the
ISDN switch, and are assigned by the ISDN provider. SPIDs identify the
phone number and expected services for each B Channel. Not all ISDN
switch-types require SPID numbers.
The dialer string command contains the phone number of the remote router.
This is the number that is “dialed” when the router is activating the ISDN
connection.
***
ISDN Dial-on-Demand Routing (DDR)

DDR allows routers to only dial the ISDN connection when it is needed.
This is accomplished by specifying “interesting” traffic, which is the only
traffic that can activate the ISDN link.
To specify interesting traffic, a dialer-list must be create, and then applied to
the BRI interface. A dialer-list is similar to an access list:
Router(config)# dialer-list 1 protocol ip permit
Router(config-if)# dialer-group 1
The dialer-list command is specifying that all IP traffic is interesting, and

thus can bring up the ISDN link. The dialer-group command applies the
dialer-list to the BRI interface. Only one dialer-group command is allowed
on a BRI interface.
A dialer-list can also point to an access-list:
Router(config)# dialer-list 1 protocol ip list 150
Router(config)# access-list 150 permit ip 172.16.0.0 0.0.255.255 any
Router(config)# access-list 150 permit tcp any host 172.17.1.10 eq 80
Router(config-if)# dialer-group 1
Notice that the dialer-list points to extended access-list “150.” The first line
of the access-list specifies that any traffic originating from the 172.16.x.x
network is interesting. The second line of the access-list specifies that any
traffic destined to the HTTP port on host 172.17.1.10 is interesting. Any
traffic matching this criteria will be allowed to activate the ISDN link.
Always remember to apply the dialer-list with the dialer-group command.
***
ISDN Authentication
For additional dialing security, the dialer map command can be used, instead
of the dialer-string command:
Router(config-if)# dialer map ip 172.16.1.2 name RouterB 5552222
When the router dials RouterB (SPID# 5552222), the remote router’s IP
address and hostname must match with the dialer map statements, otherwise
the call will not be successful.
If PPP is used for the ISDN encapsulation, additional authentication can be
configured. Two forms of authentication exist for PPP:
• PAP (Password Authentication Protocol)
• CHAP (Challenge Handshake Authentication Protocol).
PAP sends username and password information in clear-text. CHAP hashes
the information using MD5, and thus is the far more secure authentication
method.
To configure PAP:
RouterA(config)# username RouterB password PASSWORD
RouterA(config)# int bri0/0
RouterA(config-if)# encapsulation ppp
RouterA(config-if)# ppp authentication pap
RouterA(config-if)# ppp pap sent-username RouterA password PASSWORD
The username command specifies the remote routers hostname. The ppp
papsent-username allows us to specify the hostname the remote router
should authenticate to. This is a required command with PAP.
To configure CHAP:
RouterA(config)# username RouterB password PASSWORD
RouterA(config-if)# encapsulation ppp
RouterA(config-if)# ppp authentication chap
RouterA(config-if)# ppp chap hostname RouterA
***
Misc. ISDN Commands

Router(config-if)# dialer load-threshold 128 either
Router(config-if)# dialer idle-timeout 60
Router(config-if)# ppp multilink
The dialer load-threshold command tells the router when to bring up the
second “B” channel. This “load threshold” is a percentage based out of 255.
The above example tells the router to bring up the second B channel when
the first B channel is at 50% utilization.
The either argument specifies that the traffic can be either inbound or
outbound. Otherwise, inbound or outbound can be specified.
The dialer idle-timeout command tells the router how long to wait (in
seconds) after the last interesting traffic has been sent before disconnecting
the ISDN link.
The ppp multilink command binds both B channels into one logical channel.
This command can be coupled with the dialer load-threshold command, and
the logical channel will only become active when the threshold is reached.
To always force both channels to be active when using ppp multilink:
Router(config-if)# ppp multilink links minimum 2
To dictate a delay period before activating or deactivating the second B

channel, once the load-threshold has been reached:
Router(config-if)# ppp timeout multilink link add 30
Router(config-if)# ppp timeout multilink link remove 45
To enable PPP compression on an ISDN BRI interface:

Router(config-if)# compress stac
Router(config-if)# compress predictor
Stac (or Stacker) compression usually yields the best ratio, though it places a
greater tax on the router’s CPU.
***
PPP Callback
PPP Callback is a security feature for ISDN, preventing unauthorized routers
or devices from initiating the ISDN connection.
Callback is implemented as a client/server model. The client requests a
callback, and the server will only accept this request if the client’s
authentication information is correct.
To configure the Callback server:
RouterA(config-if)# ppp callback accept
RouterA(config-if)# dialer map ip 10.1.1.1 name RouterB class MYCLASS 2221112
RouterA(config)# map-class dialer MYCLASS
RouterA(config-map-class)# dialer callback-server username
To configure the Callback client:

RouterB(config)# int bri0/0
RouterB(config-if)# ppp callback request
RouterB(config-if)# dialer map ip 10.1.121 name RouterA 2221111
***
ISDN Backup Methods (Backup Interface)

The ISDN BRI interface can be used purely as a backup link. The interface
will remain in standby mode, and only activate when a monitored interface
goes into a down state.
Router(config)# interface serial0/0
Router(config-if)# backup interface bri0/0
Router(config-if)# backup delay 100 300
The bri0/0 interface is a backup to the serial0/0 interface. Once the serial0/0
interface enters a down state, the bri0/0 interface will activate after a delay
of 100 seconds. Once the serial0/0 interface comes back up, the bri0/0
interface will enter a standby state after 300 seconds.
Manually shutting down the serial0/0 interface will not bring the bri0/0
interface out of standby mode. The serial0/0 interface must be in a down
state, not an administratively shutdown state.
Also, the bri0/0 interface will never make a connection while in standby.
Once taken out of standby, it will not connect until interesting traffic is sent
across the link.
ISDN Backup Methods (Dialer Watch)

Instead of monitoring an interface, a watch-list can be configured to
monitor a route. If the monitored route is removed from the routing table,
the ISDN link will be automatically activated.
Router(config)# dialer watch-list 1 ip 10.1.0.0 255.255.0.0
Router(config)# dialer watch-list 1 delay connect 10
Router(config)# dialer watch-list 1 delay disconnect 30
Router(config)# dialer watch-list 1 delay route-check initial 25
Router(config)# interface bri0/0
Router(config-if)# dialer idle-timeout 180
Router(config-if)# dialer watch-group 1
If the 10.1.0.0/16 network is removed from the routing table, the router will
connect the ISDN link after 10 seconds. Dialer watch will continue checking
the routing table at intervals equal to the dialer idle-timeout. Once the route
is back in the table, the router will disconnect the link after 30 seconds.
***
ISDN and Routing Protocols

ISDN is a pay-per-usage technology, and thus should only be active when
necessary. Routing protocols, however, are prone to activate the link
unnecessarily. For example, OSPF periodically sends Hello packets to
maintain neighbor adjacencies. Various mechanisms exist to allow ISDN
and routing protocols to coexist.
OSPF and ISDN can coexist by configuring a demand-circuit:
Router(config-if)# ip ospf demand-circuit
This prevents OSPF from sending out periodic Hellos across the ISDN link,
while still maintaining neighbor relationships. This also eliminates the
periodic OSPF link-state table refresh (default every 30 minutes).
The ospf demand-circuit only needs to be configured on one side of the link.
After applying this command, only changes to the OSPF topology database
will trigger the link.
Snapshot routing is used with Distance Vector routing protocols. Snapshot
routing essentially “freezes” the routing table, preventing updates.
Periodically, the routing table is “unfrozen” to allow updates to occur, and
then frozen again.
When using snapshot routing, one router takes on the role of a “client,” the
other takes on the role of a “server.” The client will initiate a connection
with the server after a specific period of time, to allow routing updates to
occur:
RouterA(config-if)# snapshot server 3 dialer
RouterA(config-if)# dialer map snapshot 1 name RouterB 5552222
RouterB(config)# int bri0/0
RouterB(config-if)# snapshot client 3 300 dialer
RouterB(config-if)# dialer map snapshot 1 name RouterA 5551111
RouterB will dial RouterA after 300 minutes have passed. There will be a 3
minute period for both routers to exchange updates before the link is brought
back down.
***
Configuring Dialer Interfaces

Instead of applying ISDN configuration directly to the BRI interface, a
virtual interface can created called a dialer interface.
This is useful when multiple BRI interfaces exist on the same router. These
physical interfaces can be combined into a single logical interface using
dialer pools or rotary-groups.
Example of a dialer pool configuration:
Router(config)# int bri0/0 Router(config)# dialer-list 1 permit icmp any any
Router(config-if)# isdn spid1 333121201 3331212 Router(config)# int dialer0
Router(config-if)# dialer pool-member 1 Router(config-if)# encapsulation ppp
Router(config-if)# dialer pool 1
Router(config)# int bri0/1 Router(config-if)# ip address 10.1.1.1 255.255.0.0
Router(config-if)# encapsulation ppp Router(config-if)# dialer string 7770101
Router(config-if)# isdn spid1 555111101 5551111 Router(config-if)# ppp authentication chap
Router(config-if)# dialer pool-member 1 Router(config-if)# dialer-group 1
Example of a rotary-group configuration:

Router(config)# int bri0/0 Router(config)# dialer-list 1 permit icmp any any
Router(config-if)# isdn spid1 333121201 3331212 Router(config)# int dialer3
Router(config-if)# dialer rotary-group 3 Router(config-if)# encapsulation ppp
Router(config)# int bri0/1 Router(config-if)# dialer string 7770101
Router(config-if)# encapsulation ppp Router(config-if)# ppp authentication chap
Router(config-if)# isdn spid1 555111101 5551111 Router(config-if)# dialer-group 1
Router(config-if)# dialer rotary-group 3
Notice that that the interface dialer number matched the rotary-group
number.
There is one key difference between dialer pools and rotary groups. Dialer
pools support map-classes, which can apply specific parameters to each
destination called. Rotary groups do not support map-classes.
***
Testing ISDN
To initiate a test call on an ISDN BRI interface:
Router# isdn test call interface bri0/0 5552222
To disconnect this test call:

Router# isdn test disconnect interface bri0/0 all
Troubleshooting ISDN
The show isdn active command displays whether a call is connected, and the
number dialed.
The show isdn status command will display information on the status
between the router and ISDN switch, including whether the SPIDs are
configured correctly. This is the most useful command for troubleshooting
Layer 1, 2, or 3 ISDN connectivity problems.
The show dialer interface bri command will also display if a call is
connected, and will display previous dialing attempts and whether they were
successful or not.
The debug isdn q921 command troubleshoots communication between the
router and ISDN switch.
The debug isdn q931 command troubleshoots ISDN call setup.
The debug dialer events and debug dialer packets commands are used to
troubleshoot dial setup, and whether the proper interesting traffic is
activating the ISDN link.
The isdn disconnect interface bri command allows a currently active call to
be disconnected.
***
Frame-Relay v1.11 – Aaron Balchunas 1
- Frame-Relay -
Frame-Relay
Frame-Relay is a packet-switched technology, which shares bandwidth

between users on the switched network. Frame-relay service providers
assume that all clients will not need the full capacity of their bandwidth at all
times. Thus, in general, frame-relay is less expensive than dedicated WAN
lines, but customers are not guaranteed bandwidth.
All locations plug into the frame relay “cloud,” which is a conglomeration of
dozens or hundreds of Frame-Relay switches and routers. The cloud is the
Frame provider’s network, and the customer has no control (or even
knowledge) of what occurs inside that infrastructure.
For communication to occur between locations, virtual circuits (VC) must
be created. A VC is a one-way path through the Frame-Relay cloud.
In the above example, in order to establish full communication between
Detroit and Houston, we would need to create two virtual circuits:
• A virtual circuit between Detroit and Houston
• A separate virtual circuit between Houston and Detroit
Frame-relay circuits can either be permanent (PVC), or switched (SVC). A
permanent virtual circuit is always kept active, and is the most common
virtual circuit. A switched virtual circuit is created only when traffic needs to
be sent, and is torn down when communication is complete.
Virtual circuits are identified with Data Link Connection Identifiers
(DLCIs). Frame-Relay switches make decisions based on DLCIs, whereas
Ethernet switches make decisions based on MAC addresses.
***
Frame-Relay Global vs Local DLCI
The difference between a globally or locally significant DLCI is all based on

perspective. Remember that a DLCI identifies a one-way virtual circuit. For
example, the connection between Detroit and Chicago would be considered
one virtual circuit, and Chicago to Detroit would be a separate virtual circuit.
To get this to work, we need to map a DLCI to an IP address. For example,
on router Detroit, we’re going to create a virtual circuit to router Chicago.
We’ll assign it a DLCI of “102,” and point it to Chicago’s IP address.
We call this locally significant, because it only affects the interface on the
Detroit router. We could, on the Chicago router, set a DLCI of “102” and
point it to the IP address of the Detroit router. Because the DLCI is set on a
different router (and interface), there will be no conflict.
When we set a globally significant DLCI, it is really only an administrative
feature. It means that an administrator has consciously decided that all
virtual circuits going to Chicago will be set to DLCI 102 (or whatever DLCI
number you choose), whether it is from Detroit or Houston.
In essence, you are symbolically assigning the DLCI of 102 to the Chicago
location. Keep in mind that you are still technically assigning the DLCI to
the virtual circuits connecting to Chicago.
Virtual circuits pointing to other locations will be configured with different
DLCIs (Detroit could be 101; Houston could be 103, etc.). The advantage to
this is that it is now easy to determine the destination of a packet, based on
its DLCI.
***
Frame-Relay CIR
Bandwidth is provided on a best effort basis in Frame-Relay.
The Frame provider and customer agree on a Committed Information Rate
(CIR), which is not always a guarantee of bandwidth. The provider will give
a best effort to meet the CIR, which is measured in bits per second:
• 256000 bps
• 512000 bps
• 1544000 bps
The above are examples of possible CIR settings, though technically the CIR
can be set to anything. At times, bandwidth speeds can burst (Be) above the
CIR. However, speeds above the CIR are certainly not guaranteed, and if the
Frame Network becomes congested, any data exceeding the CIR becomes
Discard Eligible, and is at risk of being dropped.
Frame-Relay Encapsulation Types

On Cisco routers, two possible Frame encapsulations can be configured on
the router’s serial ports.
• Cisco – the default, and proprietary, Frame-Relay encapsulation
• IETF – the standardized Frame-Relay encapsulation.
Frame-Relay Local Management Interface (LMI)

LMI is the type of signaling used between your router and your provider’s
Frame-Relay switch. LMI provides status updates of Virtual Circuits
between the Frame switch and the router.
There are three LMI-types:
• Cisco – default and proprietary (naturally)
• ANSI
• Q.933a
LMI type is auto-sensed on Cisco routers, but can be manually set if desired.
***
Frame-Relay Point-to-Point Configuration Example
Point-to-Point is the simplest form of Frame-Relay configuration.

Remember that PVCs are only one-way circuits, and thus we need to create
two PVCs in order for full communication to occur.
Configuration on the Detroit and Chicago routers would be as follows:
Detroit Router: Chicago Router:
Router(config)# int s0/0 Router(config)# int s0/0

Router(config-if)# ip address 172.16.1.1 255.255.0.0 Router(config-if)# ip address 172.16.1.2 255.255.0.0
Router(config-if)# encapsulation frame-relay Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay lmi-type q933a Router(config-if)# frame-relay lmi-type q933a
Router(config-if)# frame-relay interface-dlci 102 Router(config-if)# frame-relay interface-dlci 201
Router(config-if)# no shut Router(config-if)# no shut
Notice that both routers are in the same IP subnet.

The encapsulation frame-relay command sets the frame encapsulation type
to the default of cisco. The encapsulation must be the same on both routers.
To change the default encapsulation type, simply append the ietf keyword to
the encapsulation frame-relay command:
Router(config-if)# encapsulation frame-relay ietf
The frame-relay lmi-type command sets the signaling type. The Frame-
Relay provider dictates which LMI-type to use. Remember that cisco is the
default LMI-type, and that LMI is usually auto-sensed.
***
Frame-Relay Point-to-Point Configuration Example (continued)

Router(config-if)# frame-relay lmi-type q933a Router(config-if)# frame-relay lmi-type q933a
Router(config-if)# frame-relay interface-dlci 102 Router(config-if)# frame-relay interface-dlci 201
The frame-relay interface-dlci command identifies the one-way PVC. The

connection between Detroit and Chicago has been assigned DLCI 102. The
connection between Chicago and Detroit has been assigned DLCI 201.
The Frame-Relay provider usually dictates which DLCI numbers to use, as
the provider’s Frame switch is configured with the appropriate DLCI
information.
The router can actually receive all PVC and DLCI information directly from
the Frame-Relay switch via LMI, using Inverse-ARP. Inverse-ARP is
enabled by default on Cisco routers.
Thus, if the Frame-Relay switch is configured correctly, the frame-relay
interface-dlci command could theoretically be removed, and the frame-relay
connection will still work.
There are circumstances when DLCIs should be manually assigned. Inverse-
ARP can be disabled on an interface with the following command:
Router(config-if)# no frame-relay inverse-arp
***
Frame-Relay Full Mesh Configuration Example
Consider the above example, a full mesh between three locations. All routers
can still belong to the same IP subnet; however, DLCI’s must now be
mapped to IP addresses, as multiple PVCs are necessary on each interface.
This can be dynamically configured via Inverse-Arp, which is enabled by
default (as stated earlier). Otherwise, the DLCI-to-IP mapping can be
performed manually. Looking at the Detroit and Chicago router’s
configuration:

Router(config-if)# encapsulation frame-relay ietf Router(config-if)# encapsulation frame-relay ietf
Router(config-if)# no frame-relay inverse-arp Router(config-if)# no frame-relay inverse-arp
Router(config-if)# frame-relay lmi-type ansi Router(config-if)# frame-relay lmi-type ansi
Router(config-if)# frame-relay map ip 172.16.1.2 102 broadcast Router(config-if)# frame-relay map ip 172.16.1.1 201 broadcast
Router(config-if)# frame-relay map ip 172.16.1.3 103 broadcast Router(config-if)# frame-relay map ip 172.16.1.3 203 broadcast
Inverse-ARP was disabled using the no frame-relay inverse-arp command.

The frame-relay map command maps the remote router’s IP address to a
DLCI. On the Detroit router, a map was created to Chicago’s IP
(172.16.1.2), and that PVC was assigned a DLCI of 102. The broadcast
option allows broadcasts and multicasts to be forwarded to that address, so
that routing protocols such as OSPF can form neighbor relationships.
***
Frame-Relay Partial Mesh Configuration Example
Full-mesh Frame-Relay environments can get quite expensive. Partial-mesh

environments are often more cost-effective. A partial-mesh is essentially a
hub-and-spoke design, with one central or hub location that all other
locations must connect through.
In the above example, the Detroit router serves as the hub router. In a
partial-mesh environment, each spoke must be on a different IP subnet,
which presents a special problem.
If both spokes terminate on the Detroit router’s physical serial interface,
split-horizon will prevent Chicago’s routing updates from ever reaching
Houston, and vice versa. Recall that split-horizon dictates that updates
received on an interface cannot be sent back out the same interface.
Thus, on router Detroit, sub-interfaces must be created off of the serial
interface. Sub-interfaces are virtual interfaces that the router treats as
separate physical interfaces, providing a workaround for the split-horizon
problem.
The network type must be specified when creating a sub-interface. A point-
to-point sub-interface has only a single Virtual Circuit to another router. A
multipoint sub-interface can have multiple Virtual Circuits to multiple
locations.
***
Frame-Relay Partial Mesh Configuration Example (continued)
Configuration of the Detroit and Chicago routers would be as follows:

Router(config-if)# frame-relay lmi-type ansi Router(config-if)# frame-relay lmi-type ansi
Router(config)# int s0/0.102 point-to-point

Router(config-subif)# no frame-relay inverse-arp Router(config)# int s0/0.201 point-to-point
Router(config-subif)# ip address 172.16.1.1 255.255.0.0 Router(config-subif)# no frame-relay inverse-arp
Router(config-subif)# frame-relay interface-dlci 102 Router(config-subif)# ip address 172.16.1.2 255.255.0.0
Router(config-subif)# no shut Router(config-subif)# frame-relay interface-dlci 201
Router(config-subif)# no shut
Router(config)# int s0/0.103 point-to-point
Router(config-subif)# no frame-relay inverse-arp
Router(config-subif)# ip address 172.17.1.1 255.255.0.0
Router(config-subif)# frame-relay interface-dlci 103
Router(config-subif)# no shut
Notice first that the Detroit router, serving as the hub, has two sub-interfaces
configured pointing to Chicago and Houston. The Chicago router only has
one sub-interface pointing to Detroit.
On the Detroit router, the int s0/0.102 command creates a sub-interface
numbered 102 on the Serial0/0 interface. Using the DLCI number for the
sub-interface number is an arbitrary choice, useful for documentation
purposes. On the Detroit router, each sub-interface contains only one virtual
circuit, thus the interface’s network type was set to point-to-point.
Notice also that encapsulation and LMI-type information is set on the
physical interface, but IP address and DLCI information is set on the sub-
interface.
***
Frame-Relay Traffic Shaping (FRTS)

Frame-Relay’s method of QoS is called traffic-shaping, which controls the
amount of traffic sent out an interface, and dictates congestion control
mechanisms.
Frame-Relay Traffic-Shaping (FRTS) is used for two purposes:
• Adhering to the Frame provider’s traffic rates.
• Preventing an oversubscription of the line between hub and spoke
routers.
Several terms must be understood before configuring traffic-shaping:
• Committed Information Rate (CIR) – the “average” traffic rate
provided on a best-effort basis. By default, the CIR on a serial
interface configured for traffic shaping is 56000 bits per second.
• Available Rate (AR) – the maximum traffic rate, dictated either by
the speed of the physical interface (using the clock rate command), or
the restrictions of the Frame Provider.
• Minimum CIR (MinCIR) – the minimum traffic rate the router will
“throttle” down to if congestion occurs on the Frame-Relay network
(i.e., a BECN is received). This is usually the provider’s guaranteed
traffic rate. By default, the MinCIR is half that of the CIR.
• Discard Eligible (DE) – a bit that is set for all traffic sent above the
MinCIR. Essentially, traffic that is sent above the Frame Provider’s
guaranteed rate can or will be dropped when congestion occurs.
• Committed Burst (Bc) – the amount of bits sent during a specific
interval, measured as Time Committed (Tc). Tc is measured in
milliseconds (default is 125ms, or 8 intervals a second), and
determines the number of intervals per second. The CIR is derived
from the Bc and Tc using the following formula:
CIR = Bc X 1000/Tc
• Excess Burst (Be) – the amount of bits that can be sent exceeding the
Bc (or CIR). Any bits sent at this rate will be marked as DE.
***
Configuring Frame-Relay (FRTS)

To configure FRTS, a map-class must be created:
Router(config)# map-class frame-relay MYCLASS
Router(config-map-class)# frame-relay cir 64000
Router(config-map-class)# frame-relay bc 8000
Router(config-map-class)# frame-relay be 0
Router(config-map-class)# frame-relay mincir 32000
Router(config-map-class)# frame-relay adaptive-shaping becn
A map-class was created for frame-relay called MYCLASS. The first three
commands configure the CIR, Bc, and Be respectively.
The final commands must be used in conjunction with each other. The
adaptive-shaping feature has been specified, indicating that the router will
throttle back to the mincir if a becn is received. The router does not throttle
down to the mincir immediately, but rather will lower the rate by 25% until
either the congestion stops, or the mincir is reached.
A map-class applied to an interface affects all PVCs on that interface.
Additionally, map classes can be applied to a specific PVC, providing more
granular control of FRTS.
To apply a map class to an interface:
Router(config)# interface s0/0
Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay traffic-shaping
Router(config-if)# frame-relay class MYCLASS
To apply a map class to a specific PVC:

Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay traffic-shaping
Router(config-if)# frame-relay interface-dlci 101 class MYCLASS
Do not forget the frame-relay traffic-shaping command. Once this command

is configured, all PVCs are configured with the default CIR of 56,000 bps.
***
EIGRP and Frame-Relay
Chicago
Frame-Relay Cloud
Detroit
Houston
Observe the above Frame-Relay network. Two possible configuration

options exist for the Detroit router:
• Configure frame-relay map statements on the physical interface
• Create separate sub-interfaces for each link, treating them as separate
point-to-points.
If choosing the latter, EIGRP will treat each sub-interface as a separate link,
and routing will occur with no issue.
If choosing the former, EIGRP will be faced with a split-horizon issue.
Updates from Houston will not be forwarded to Chicago, and visa versa, as
split horizon prevents an update from being sent out the link it was received
on.
It is possible to disable split horizon for EIGRP:
Detroit(config)# interface s0/0
Detroit(config-router)# no ip split-horizon eigrp 10
Using sub-interfaces is Cisco’s preferred method of circumventing the split-

horizon issue, however.
***
Troubleshooting Frame-Relay
To view information concerning each PVC:
Router# show frame-relay pvc
The above command includes the following information:

• DLCI numbers
• Status of PVCs (active, inactive, deleted)
• Congestion information
• Traffic counters
To list Frame-Relay DLCI-mappings, whether manually created using the
frame-relay map command, or created dynamically using Inverse ARP:
Router# show frame-relay map
To display the LMI-type configured on each interface, and LMI traffic

statistics:
Router# show frame-relay lmi
To troubleshoot communication problems between the router and Frame-

Relay switch:
Router# debug frame-relay lmi
To display information on packets received on a Frame-Relay interface:

Router# debug frame-relay
To display information on packets sent on a Frame-Relay interface:

Router# debug frame-relay packet
***
MPLS v1.01 – Aaron Balchunas 1
- Multiprotocol Label Switching -

Multiprotocol Label Switching
Multiprotocol Label Switching (MPLS) is a Layer-2 switching
technology. MPLS-enabled routers apply numerical labels to packets, and
can make forwarding decisions based on these labels. The MPLS
architecture is detailed in RFC 3031.
MPLS reduces CPU-usage on routers, by allowing routers to make
forwarding decisions solely on the attached label, as opposed to parsing the
full routing table.
Labels can based on a variety of parameters:
• Destination IP network
• Source IP address
• QoS parameters
• VPN destination
• Outgoing interface
• Layer-2 circuit
MPLS is not restricted to IP, or any specific Layer-2 technology, and thus is
essentially protocol-independent.
Labels are applied to and removed from packets on edge Label Switch
Routers (edge LSRs). Only edge routers perform a route-table lookup on
packets. All core routers (identified simply as LSRs) in the MPLS network
forward solely based on the label.
As a packet traverses the core MPLS network, core routers will swap the
label on hop-by-hop basis.
MPLS is completely dependent on Cisco Express Forwarding (CEF) to
determine the next hop.
(Reference: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/mpls_tsw.htm;
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_q_and_a_item09186a00800949e5.shtml)
***
Cisco Express Forwarding (CEF)

Multilayer switches contain both a switching and routing engine. A packet
must first be “routed,” allowing the switching engine to cache the IP traffic
flow. After this cache is created, subsequent packets destined for that flow
can be “switched” as opposed to “routed,” reducing latency.
This concept is often referred to as route once, switch many. Cisco refers to
this type of Multilayer switching as NetFlow switching or route cache
switching.
As is their habit, Cisco replaced NetFlow multilayer switching with a more
advanced method called Cisco Express Forwarding (CEF). CEF is
enabled by default on all Catalyst multi-layer switches (at least, those that
support CEF). CEF cannot even be disabled on the Catalyst 3550, 4500 and
6500.
CEF contains two basic components:
• Layer 3 Engine – Builds the routing table and then “routes” data
• Layer 3 Forwarding Engine – “Switches” data based on the FIB.
The Layer 3 Engine builds its routing table using either static routes, or
routes dynamically learned through a routing protocol (such as RIP or
OSPF).
The routing table is then reorganized into a more efficient table called the
Forward Information Base (FIB). The most specific routes are placed at
the top of the FIB. The Layer 3 Forwarding Engine utilizes the FIB to then
“switch” data in hardware, as opposed to “routing” it through the Layer 3
Engine’s routing table.
The FIB contains the following information:
• Destination networks
• Destination masks
• Next-hop addresses
• The MAC addresses of each next hop (called the Adjacency Table)
To view the CEF FIB table:
Switch# show ip cef
***
The MPLS Label

Two forms of MPLS exist:
• Frame Mode MPLS – utilizes a 32-bit label that is injected between
the Layer-2 and Layer-3 headers.
• Cell Mode MPLS – used with ATM, and utilizes the VPI/VCI fields
ATM header as the label.
This guide will concentrate on Frame Mode MPLS. The 32-bit label has the
following format:
Label Experimental Bottom-of-Stack TTL

20 bits 3 bits 1 bit 8 bits
• Label (20 bits) –
• Experimental (3 bits) – This field is officially undefined, but is used

by Cisco as an IP precedence value.
• Bottom-of-Stack (1 bit) – This field indicates the last label, as

multiple labels are supported in the same packet. A value of 1
identifies the last label in the stack.
• TTL (8 bits) – This field indicates the number of router this label can
‘live’ through.
An Ethernet header is modified to indicate the presence of an MPLS label.

• 0x8847 – indicates a labeled unicast IP packet
• 0x8848 – indicates a labeled multicast IP packet
(Reference: http://www.iec.org/online/tutorials/mpls/topic03.html; http://www.rfc-editor.org/rfc/rfc3032.txt)
***
The MPLS Components

MPLS router designations include:
• LSR (Label Switch Router) – responsible for forwarding packets
through the provider core based on the packet’s label. Cisco refers to
this as a P (provider) router.
• Edge LSR (Label Edge Router) – responsible for adding or
removing labels from packets. Cisco refers to this as a PE (provider
edge) router.
• Non-Label Routers – Cisco refers to this as C (customer) routers
LSRs perform the following functions:

• Control Plane - exchanges routing and label information
• Data Plane - forwards actual packets based on label information
The Control Plane, in charge of information exchange, builds and maintains
the following tables:
• Routing Table – routing information is exchanged between LSRs
using a routing protocol, such as IGRP, EIGRP, IS-IS, OSPF, or BGP.
• Label Information Base (LIB) – label information is exchanged
between LSRs using a label protocol, such as LDP (Label
Distribution Protocol) or TDP (Tag Distribution Protocol)
LDP is now default on Cisco devices, and uses TCP port 646. TDP is a
Cisco-proprietary label protocol, and uses TCP port 711.
Label convergence will occur after routing convergence is completed. Label
protocols require the underlying routing infrastructure in order to function.
The Data Plane, in charge of information forwarding, maintains the
following tables:
• The CEF Forwarding Information Base (FIB) –for forwarding
unlabeled packets. Contains destination IP networks, and the Layer-2
address of the next-hop router.
• Label Forwarding Information Base (LFIB) – for forwarding
labeled packets.
***
The MPLS Process

There are four scenarios detailing how LSRs forward packets:
1. An unlabeled IP packet is received, and is routed unlabeled to the
next hop.
2. An unlabeled IP packet is received, a label is inserted in the header,
and is switched to the next hop.
3. A labeled IP packet is received, the label is swapped, and is switched
to the next hop.
4. A labeled IP packet is received, the label is stripped off, and is routed
to the next hop or destination.
Frame-mode MPLS performs as follows:

1. An edge LSR receives a packet.
2. The edge LSR performs a routing table lookup to determine the next
hop (or exit interface).
3. If destined for the MPLS network, the edge router inserts the label
between the Layer-2 and Layer-3 headers.
4. The edge LSR forwards the labeled packet to the core LSR.
5. Core LSRs will route solely based on the label, and will not perform a
routing table lookup.
***
Configuring Basic MPLS

The first step in configuring MPLS is enabling CEF switching, which can be
accomplished globally (for all interfaces), or on a per interface basis:
Router(config)# ip cef
Router(config-if)# ip route-cache cef
To view CEF information:

Router(config)# show ip cef
Next, MPLS must be enabled on the interface:

Router(config-if)# mpls ip
The desired label protocol can then be specified (either ldp, tdp, or both):
Router(config-if)# mpls label protocol ldp
Router(config-if)# mpls label protocol tdp
Router(config-if)# mpls label protocol both
If a label protocol is not specified, Cisco devices will default to ldp (as of the
IOS version 12.4).
Because the MPLS label increases the size of the frame by 32 bits (4 bytes),
the mtu for mpls packets should be adjusted to accommodate this:
Router(config-if)# mpls mtu 1504
MPLS VPNs require two labels, thus the mtu should be adjusted
accordingly:
Router(config-if)# mpls mtu 1508
(Reference: http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a008045543c.html)
***
MPLS VPNs
Cisco identifies two key categories of VPNs:

• Overlay – connections are set up and maintained by the service
provider. However, the provider has no knowledge of, and does not
participate in, the customer’s routing infrastructure.
• Peer-to-Peer – the provider directly participates in routing the
customer’s infrastructure. Routes from multiple customers are not
kept separate. This may require customers to readdress their networks.
MPLS VPNs provide the best of both words. Advantages of MPLS VPNs
include:
• The provider directly participates in routing the customer
infrastructure.
• Peer-to-peer peering is not required, leading to a scalable
infrastructure.
• Customer networks do not need to be readdressed
• Routes from multiple customers are kept separate.
MPLS VPNs use two labels.

MPLS separates customer routes by assigning each a unique Virtual
Routing Instance (VRI), stored in a Virtual Routing and Forwarding
(VRF) table.
If the addressing structure of multiple clients overlaps, each network is
assigned a unique 64-bit route distinguisher (RD). The IP network and RD
combination is called a VPNv4 address.
Route targets are BGP attributes that designate MPLS VPN membership of
routes.
***
ATM v1.03 – Aaron Balchunas 1
- Asynchronous Transfer Mode -

Asynchronous Transfer Mode (ATM)
Asynchronous Transfer Mode (ATM) is a high-speed, non-broadcast
Layer 2 technology, similar in many respects to Frame Relay.
In addition to supporting higher bandwidths, ATM integrates QoS
mechanisms directly into the technology. ATM is thus a very flexible
technology, supporting data, voice and video traffic.
Other Layer 2 technologies, such as Ethernet or Token Ring, support
variable-sized packets. For example, Ethernet packets are 1514 bytes by
default, but the MTU can be changed. ATM utilizes fixed-sized packets
called cells. Each cell is exactly 53 bytes. Because the cell size is always
consistent, traffic can be routed or switched far more efficiently.
Two ATM interface types exist:
• User-Network Interface (UNI) – connects an ATM end-user device
to an ATM switch or router
• Network-Network Interface (NNI) – connects an ATM switch to
another ATM switch
ATM, like Frame Relay, builds Virtual Channels (or Circuits) between
ATM devices. These virtual channels can be permanent (PVC) or switched
(SVC), and are one-way.
Each virtual channel is identified by a Virtual Channel Identifier (VCI),
the equivalent of a Frame-Relay DLCI. The VCI is only locally significant
to the router/switch.
Multiple virtual channels can then be bundled together into a Virtual Path,
which is identified by a Virtual Path Identifier (VPI). Like VCI’s, a VPI is
only locally significant. A VPI essentially identifies a “route” between two
ATM devices.
***
ATM Layers
ATM is comprised of an ATM Adaptation Layer (AAL), which dictates
how upper layer information (IP addresses, TCP ports, etc) gets “packaged”
into an ATM cell.
There are various AAL “types,” each dictating a different class of service for
specific traffic:
• AAL-1 – Intended for voice and video traffic, and other such delay-
sensitive traffic. Utilizes Constant Bit Rate (CBR) to provide
“consistent” bandwidth and timing.
• AAL-2 – Also intended for voice and video traffic. Supports a
Variable Bit Rate (VBR), instead of a “constant” bit rate. Thus
traffic rates and bandwidth will vary. VBR can either be Real Time
(VBR-RT) or Non-Real Time (VBR-NRT).
• AAL-3/4 – Legacy layer intended for Switched MultiMegabit Data
Service (SMDS) traffic.
• AAL-5 – Intended for data traffic. Utilizes Unspecified Bit Rate
(UBR) and Available Bit Rate (ABR), where bandwidth and traffic
rate are never guaranteed. Essentially a “best-effort” form of service.
However, AAL-5 can also support CBR and VBR, if necessary.
The order of priority for ATM’s classes of service (from highest to lowest):
• CBR
• VBR-RT
• VBR-NRT
• ABR
• UBR and UBR+
ATM Encapsulations
This guide will concentrate on the AAL-5 implementation of ATM. Several
AAL-5 encapsulation types exist, including:
• aal5snap – The default encapsulation type for an ATM interface.
Supports multiplexing two or more Layer 3 protocols over the same
PVC.
• aal5mux – Used to dedicate the PVC to a single Layer 3 protocol.
***
Basic ATM PVC Configuration
Basic configuration of an ATM interface is not difficult:

RouterA(config)# interface atm0
RouterA(config-if)# ip address 172.16.1.1 255.255.0.0
Next, the PVC must be identified with a VPI/VCI combination, and the
encapsulation type must be defined. This information is often supplied by
the ATM provider:
RouterA(config-if)# pvc 0/200
RouterA(config-if-vc)# encapsulation aal5mux ip
The pvc command creates a Permanent Virtual Channel with a VPI of 0 and
a VCI of 200. Recall that the VPI identifies the path, and that multiple
channels (VCIs) can exist in this path.
The encapsulation type was configured as aal5mux. Remember that
aal5mux dedicates the virtual channel to a single Layer 3 protocol, thus the
ip protocol was also specified.
Finally, much like Frame Relay, the virtual circuit must be mapped to a
Layer 3 address in order to communicate with the remote router:
RouterA(config-if-vc)# protocol ip 172.16.1.2 broadcast
RouterA(config-if-vc)# protocol ip 172.16.1.1
The mapped protocol is ip, pointing to the remote router’s IP address of

172.16.1.2. Because ATM is a non-broadcast multi-access (NMBA)
medium, the broadcast parameter must be specified to direct broadcasts to
the remote router’s IP. Otherwise, routing protocols like OSPF and EIGRP
will be unable to form neighbor relationships.
The final protocol ip command points to the IP of the local ATM interface,
allowing the router to ping itself.
***
Configuring Multipoint ATM PVCs
Recall that multiple VCI’s can be configured on an interface. Configuration

is not difficult:
RouterA(config-if)# no shut
A unique VCI must be used for each destination. For simplicity, each PVC
can be assigned a descriptive name:
RouterA(config-if)# pvc TOROUTERB 0/200
RouterA(config-if)# pvc TOROUTERC 0/201
Using Inverse-Arp for ATM PVCs

The previous examples demonstrated the static configuration of PVC-to-
Layer 3 mappings. This information can be dynamically discovered using
Inverse-Arp:
RouterA(config-if-vc)# inarp 15
Inverse-ARP is automatically enabled by default, but will be disabled if a

static mapping is configured.
***
Configuring ATM SVCs
An ATM PVC is a permanent circuit, as its name would indicate. An ATM

SVC is created and torn down as needed. In order for an SVC to be
established, two system PVCs must be configured:
RouterA(config-if)# pvc 0/5 qsaal
RouterA(config-if)# pvc 0/16 ilmi
The qsaal and ilmi PVCs are used for signaling and management between
the ATM switch and router. ILMI (or Integrated Local Management
Interface) serves the same function as Frame Relay’s LMI. QSAAL is used
for call setup.
The above VPI/VCI values are the defaults for QSAAL and ILMI. The ATM
provider should provide the values for any customized signaling channels.
Please note: ATM can use ILMI to automatically discover PVCs too, using
the following command:
RouterA(config-if)# atm ilmi-pvc-discovery
The router’s ATM address must be specified. ATM utilizes the standard OSI
NSAP (Network Service Access Point) address (an addressing standard
used by other technologies as well, such as IS-IS). The ATM NSAP is
comprised of three parts:
• The 13-byte Switch Prefix, assigned by the ATM provider, which
identifies the ATM switch or “domain”
• The 6-byte MAC address of the local ATM interface, also known as
the End System Identifier (ESI)
• The 1-byte NSAP Selector field
***
Configuring ATM SVCs (continued)
If the ILMI PVC is not configured, then the entire NSAP address must be
manually specified:
RouterA(config-if)# atm nsap-address AB.1111.22.CDEF33.AB12.AF12.BF3C.1111.2222.3333.00
Rather long, yes? The AB.1111.22.CDEF33.AB12.AF12.BF3C portion of

the nsap-address identifies the switch prefix. The 1111.2222.333 portion
identifies the ESI (or MAC address). The 00 identifies the NSAP Selector
field.
However, if the ILMI PVC is configured, the ATM switch will provide the
switch prefix automatically. Thus, only the ESI and NSAP Selector must be
manually specified:
RouterA(config-if)# atm esi-address 111122223333.00
Notice that no periods separate the MAC address in this syntax.

The atm nsap-address and atm esi-address commands cannot be used
together. One will override the other.
Finally, the SVC must be created, and pointed to a destination NSAP
address:
RouterA(config-if)# svc MYSVC CC.2222.33.CDEF33.AB12.AF12.BF3C.4444.5555.6666.00
Notice that the name MYSVC was assigned to the svc.
***
Configuring ATM QoS

The first step in configuring QoS for ATM is to create a vc-class that
contains the appropriate QoS parameters:
Router(config)# vc-class atm MYCLASS
Router(config-vc-class)# encapsulation aal5snap
Router(config-vc-class)# ubr 1000
Router(config-vc-class)# ubr+ 2000 256
Router(config-vc-class)# abr 2000 256
The vc-class command creates an atm QoS policy called MYCLASS.

The ATM encapsulation is configured as aal5snap.
Traffic marked for ubr is given a Peak Cell Rate (PCR) of 1000 Kbps. PCR
is essentially a “best effort” rate of bandwidth.
Traffic marked for ubr+ is given both a PCR (2000) and Minimum Cell
Rate (MCR) of 256 Kbps. Traffic marked for abr is also given both a PCR
and MCR.
The vc-class must then be applied to an interface:
Router(config)# interface atm0
Router(config-if)# class-int MYCLASS
Or, the vc-class can be directly applied to a PVC:

Router(config)# interface atm0
Router(config-if)# pvc 0/200
Router(config-if-vc)# class-vc MYCLASS
***
PPP over ATM

To configure PPP encapsulation over an ATM connection:
RouterA(config)# username NAME password PASSWORD
RouterA(config)# interface atm0/0.111
RouterA(config-if)# protocol ppp Virtual-Template1
RouterA(config)# interface Virtual-Template1
RouterA(config-if)# ppp authentication chap
RouterA(config-if)# ppp chap hostname RouterA
Troubleshooting ATM
To view the status of all configured ATM PVCs:
Router# show atm pvc
To view the status of all configured ATM SVCs:

Router# show atm svc
To view the Layer 3 maps to remote ATM hosts:

Router# show atm map
***
Asynchronous Technologies v1.11 – Aaron Balchunas 1
- Asynchronous Technologies -
Synchronous vs. Asynchronous Communication
Serial communication sends information sequentially, one bit at a time.
This can be accomplished with as few as three wires (or pins): one to
transmit data, one to receive data, and a common ground wire. Parallel
communication, in contrast, sends a group of bits at a time over multiple
pins.
Serial communication requires some form of synchronization, so that
devices are always aware when data is, or is not, being sent.
Synchronous communication forces two devices to continuously stay
synchronized, even when no data is being sent. This is accomplished by
sending Idle bits when no Data bits are being exchanged.
In contrast, two devices engaging in asynchronous communication are not
synchronized with each other. As a result, the sending device must inform
the receiving device when it is starting a data stream, and when it is stopping
a data stream.
This is accomplished using Start and Stop bits. Asynchronous serial
communication usually sends seven or eight data bits between start and stop
bits. The sending and receiving devices must agree on the number of data
bits. An optional parity bit allows a basic level of error-checking.
Asynchronous communication introduces additional overhead (due to the
start/stop bits), and is less efficient than synchronous communication.
Asynchronous communication defines two types of devices:
• DTE (Data Terminal Equipment) – end devices, such as a router or
workstation.
• DCE (Data Communication Equipment) – provides the clocking,
such as a modem.
The defined physical standard for connecting DTE and DCE equipment is
EIA/TIA-232 (previously known as RS-232).
(Reference: http://www.certiguide.com/aplush/cg_aph_AsynchronousVersusSynchronous.htm;
http://www.inetdaemon.com/tutorials/theory/concepts/asynchronous_vs_synchronous.shtml;
http://www-scm.tees.ac.uk/users/u0000408/Async/async.htm)
***
EIA/TIA-232 Pins
Each pin in an EIA/TIA-232 cable has a designated purpose:
DB25 DB9
Pin 1 Ground Pin 1 CD – Carrier Detect

Pin 2 TD – Transmit Data Pin 2 RD – Receive Data
Pin 3 RD – Receive Data Pin 3 TD – Transmit Data
Pin 4 RTS – Request to Send Pin 4 DTR – Data Terminal Ready
Pin 5 CTS – Clear to Send Pin 5 Signal Ground
Pin 6 DSR – Data Set Read Pin 6 DSR – Data Set Read
Pin 7 Signal Ground Pin 7 RTS – Request to Send
Pin 8 CD – Carrier Detect Pin 8 CTS – Clear to Send
Pin 20 DTR – Data Terminal Ready Pin 9 RI – Ring Indicator
Pin 22 RI – Ring Indicator
The required pins for data transfer are TD (Transmit Data), RD (Receive
Data), and Signal Ground.
The RTS (Request to Send) pin is used by the DTE to tell the DCE it is
ready to receive data. The CTS (Clear to Send) is used by the DCE to tell
the DTE it is ready to receive data.
The DTR (Data Terminal Ready) pin informs the DCE that the DTE is
powered on and functional. The DSR (Data Set Ready) pin informs the
DTE that the DCE is powered on and functional.
The CD (Carrier Detect) pin indicates that a connection has been made
with a remote modem, or that a dial tone is present.
The RI (Ring Indicator) pin will indicate that an incoming call is occurring.
A null modem cable will flip the TD and RD pins, the RTS and CTS pins,
and the DTR and DSR pins - to connect DTE devices back-to-back.
(Reference: http://www.taltech.com/TALtech_web/resources/intro-sc.html;
http://www.zytrax.com/tech/layer_1/cables/tech_rs232.htm
CCNP BCRAN Exam Certification Guide, Second Edition. Page 88-89. Cisco Press ISBN: 1587200848)
***
Modems
As its name implies, a modem (modulator/demodulator) will modulate a
digital signal onto an analog signal when sending data across the wire. When
receiving, the modem will then demodulate the analog signal back to digital.
The terms bit rate and baud rate are often mistakenly used interchangeably
when discussing modem speeds. Bit rate refers specifically to the amount of
bits sent over a period of time, usually measured in bps (bits-per-second).
Baud rate, in contrast, refers to the number of symbols sent over a period of
time. A symbol can be comprised of multiple bits.
Thus, the bit rate of a modem may be larger than the baud rate of a modem.
Modems may use either in-band or out-of-band signaling. In-band signaling
sends control information on the same ‘channel’ as the data is being sent. A
dialup modem uses in-band signaling.
Out-of-band signaling dedicates a separate channel for control information.
ISDN BRI contains data (Bearer or “B”) channels and one control (Delta or
“D”) channel, and is thus an example of out-of-band signaling.
Modems must perform call setup (called handshaking), before data can be
transferred. This often takes several seconds.
Various modem standards include (by no means a comprehensive list):
• V.32 – max speed of 9,600 (newer revisions capable of 19,200 bps)
• V.34 – max speed of 28,000 bps
• V.90 – max speed of 56,000 bps
• V.92 – max speed of 56,000 bps (with quicker handshake than V.90)
A win-modem (sometimes referred to as a soft-modem) offloads functions
normally controlled by hardware into software.
(Reference: http://www.webopedia.com/quick_ref/dialup_modem_standards.asp;
http://en.wikipedia.org/wiki/Modem)
***
Modem AT Commands
Modems can be controlled using the command line, or via an initialization
string. These commands are usually based on the Hayes modem command
set, though some modems use proprietary command strings.
The AT (attention) string informs the modem that a command will follow.
Common (standard) AT commands include:
ATA0 Answers incoming call
ATDxxx… Dials the specified number
ATD9Wxxx… Dials 9, waits for a second dial tone, then dials the
specified number
ATE0 Disables local echo
ATH0 Hangs up
ATLx Adjusts the volume, where x can be a value of 0 - 3
ATM0 Disables the speaker
ATZ Resets the modem
Additional AT modem commands are available in the extended command

set, referenced with an ampersand (&). An example would include:
AT&F Reverts modem to factory defaults
To configure a modem connected to an asynchronous interface on a Cisco

device, reverse telnet must be used. Instead of connecting to a remote
device, reverse telnet connects to a local interface, referenced by port
number.
Reverse telnet can only be used if an asynchronous interface exists, and an
IP address is configured on at least one interface:
Router(config)# interface loopback 0
Router(config-if)# ip address 10.10.10.10
To connect to a modem off of the first asynchronous interface:

Router(config)# telnet 10.10.10.10 2001
The port numbers for character-mode access to asynchronous interfaces will

range from 2000-2999.
(Reference: http://docs.kde.org/stable/en/kdenetwork/kppp/appendix-hayes-commands.html)
***
Configuring Asynchronous Connections on a Router

Cisco Routers can have three types of serial interfaces:
• Synchronous interfaces
• Asynchronous/synchronous (A/S) interfaces
• Asynchronous interfaces
An asynchronous/synchronous (A/S) interface operates synchronously by
default. To force the interface to operate asynchronously:
Router(config-if)# physical-layer async
Other asynchronous interface commands include:

Router(config)# ip local pool MYPOOL 10.1.1.100 10.1.1.124
Router(config)# int serial0/4
Router(config-if)# ip unnumbered fastethernet0/0
Router(config-if)# async mode interactive
Router(config-if)# peer default ip address pool MYPOOL
The ip unnumbered command allows the serial0/4 interface to use the

configured IP address on fastethernet0/0.
Hosts connecting into this asynchronous interface will receive an ip address
from the range specified in the pool named MYPOOL.
The async mode interactive command provides EXEC mode access to any
host that establishes a connection.
(Reference: CCNP BCRAN Exam Certification Guide, Second Edition. Page 96. Cisco Press ISBN: 1587200848)
***
Configuring Asynchronous Connections on a Router (continued)

Physical-layer configuration is completed on the line, and not the interface:
Router(config)# line 4
Router(config-line)# login local
Router(config-line)# autoselect during-login
Router(config-line)# autoselect ppp
Router(config-line)# modem inout
Router(config-line)# modem autoconfigure type use_sportster
Router(config-line)# stopbits 1
Router(config-line)# txspeed 56000
Router(config-line)# rxspeed 56000
Router(config-line)# flowcontrol hardware
Router(config-line)# transport input all
The login local command will force the router to examine its local username
and password database to authenticate users accessing this asynchronous
line.
The autoselect during-login and autoselect ppp commands automatically
start the PPP process and prompt the connecting host for login credentials.
The modem inout command enables incoming and outgoing communication.
The modem autoconfigure command specifies the appropriate initialization
parameters for the modem, based on the modemcap database. To view
entries in the modemcap database:
Router# show modemcap
The router can attempt to auto-discover the modem type:

Router(config)# line 4
Router(config-line)# modem autoconfigure discovery
Transmit and receive speeds are set using the txspeed and rxspeed
commands. The speed command will set both simultaneously.
The flowcontrol hardware command indicates that the RTS and CTS pins
will be utilized for flow control.
The transport input command specifies the protocols that can gain
interactive access to the Cisco device (SSH, Telnet, etc.).
(Reference: CCNP BCRAN Exam Certification Guide, Second Edition. Page 98. Cisco Press ISBN: 1587200848)
***
T-Carrier Technologies v1.01 – Aaron Balchunas 1
- T-Carrier Technologies -
T-Carrier Fundamentals
T-Carrier systems provide digitized communication for voice or data traffic
across a telephone provider’s network. The T-Carrier specification defines
the Layer-1 aspects of the multiplexed communication. The two most
prevalent T-Carrier systems are T1 and T3 circuits.
The Digital Signal (DS) refers to the signaling rate and framing of the T-
Carrier. The basic unit is the DS0, referred to as a channel or timeslot. The
DS0 channel was designed to support one voice call, with a throughput of 64
kbps.
It is possible to multiplex multiple DS0’s to form a higher-capacity link:
• A T1 circuit consists of 24 DS0 channels, for a total throughput of
1.544 Mbps.
• A T3 circuit consists of 672 DS0 channels, or 28 T1 circuits, for a
total throughput of 44.736 Mbps.
It is also possible to utilize only a subset of channels on a T1, referred to as a
fractional T1 (or frac T1).
The terms T1 and DS-1 are often (incorrectly) used interchangeably to refer
to a 24-channel multiplexed line. Remember: the term T1 refers to the
hardware aspect of the technology, whereas DS1 refers to the framing.
A T1 line can operate over as few as two copper pairs (4 wires). One pair is
used to transmit data, and the other pair is used to receive data.
In European and Asian countries, an E-carrier system is used instead of T-
carrier. An E1 consists of 30 channels of 64 Kbps, for a total throughput of
2.048 Mbps.
This guide will concentrate solely on the theory and configuration of T1
circuits. T3 and E1 circuits go beyond the scope of this guide.
(Reference: CCNP BCRAN Exam Certification Guide, Second Edition. Pages 195-196. Cisco Press ISBN: 1587200848)
***
T-Carrier Sampling and Framing

Recall that T-Carriers provide purely digitized communication, for both
voice and data. It was originally developed for voice communication,
however.
A voice call requires a 4 kHz (4000 Hz) channel. To convert analog voice
into a digital format, samples of the frequency and amplitude of the analog
wave must be made. Sampling, in this instance, refers to representing a
snapshot of the signal as a sequence of binary digits (usually 8 bits).
The Nyquist sampling theorem dictates that analog wave should be
sampled at a rate of twice the channel’s frequency range:
fs = 2(freq. range)
Thus, assuming a range of 4000 Hz, this requires a rate of 8000 samples per
second. Each sample is represented using 8 bits of data. Each sample is
assigned an 8-bit value to represent the amplitude height at the time of
sampling.
The first bit of the 8-bit value designates whether the wave’s height is
positive (1) or negative (0). The remaining seven bits allow for a height
range of -127 to 127, for a total of 256 representations of the wave’s
sampled amplitude.
The throughput of a DS0 channel can thus be calculated as such:
8000 samples per second x 8 bits per sample = 64,000 bps (or 64 Kbps)
A DS-1 utilizes a CSU (Channel Service Unit) to format data into frames.
The size of a single frame is exactly 193 bits. Each channel attaches 8 bits of
data per frame, and then one framing bit is attached. Thus, during each
sampling period:
24 channels x 8 bits of data per channel + 1 framing bit = 193 bits per frame
Assuming a sampling rate of 8,000 frames per second, the total throughput
of a DS1 will be:
8000 frames per second x 193 bits per frame = 1.544 Mbps
(Reference: Broadband Telecommunications Handbook. Pages 432-444. Regis J. Bates. McGraw Hill. ISBN: 0071346481)
***
T-Carrier Framing Protocols

T-Carrier systems utilize framing protocols to maintain synchronization
and for error control. The two most common framing protocols include:
• D4 SF (SuperFrame)
• ESF (Extended SuperFrame)
D4 SF utilizes the single framing bit in 12 consecutive frames to apply a
repeating pattern of 100011011100. The twelve frames are collectively
known as a superframe (hence SF). The continuous pattern allows the
sending and receiving devices to stay synchronized.
ESF, as its name implies, expands the superframe to 24 consecutive frames.
In addition to using the framing bits for synchronization, ESF also employs
error control and maintenance services. Specifically:
• 6 bits of each superframe are used for synchronization
• 6 bits of each superframe are used for CRC error control
• 12 bits of each superframe are used for maintenance services, such as
performance statistics
(Reference: http://www.techfest.com/networking/wan/t1.htm)
***
T-Carrier Line Coding

The two most commonly used types of line coding include:
• AMI (Alternate Mark Inversion)
• B8ZS (Bipolar 8 Zero Substitution)
Binary data is represented on a T1 circuit using a pulse. A pulse represents a
binary 1; the absence of a pulse represents a binary 0.
If a long set of consecutive zeros are transmitted, devices may lose
synchronization due to the lack of pulses. Thus, the ones density rule was
implemented, which states that at least 12.5% (in other words, 1 out of 8) of
all transmitted bits must be set to 1. Otherwise continuous strings of zeros
may cause timing to be lost.
If a CSU receives a string of eight zeroes, it will change the last bit to a
binary 1 (known as pulse stuffing). One out of every eight bits has
essentially been rendered unreliable, reducing the throughput of the channel
by 1/8th (down to 56,000 bps).
This above is the basics of how AMI line coding works. AMI is no longer
widely implemented, and has been largely replaced with the more advanced
B8ZS standard.
B8ZS also adheres to the ones density rule, but utilizes a specific pattern
(0001 1011) to replace eight consecutive zeros. The receiving CSU
recognizes that this pattern represents all zeroes, and will revert the bits to
their original value.
B8ZS is thus more efficient than AMI, and does not lose 1/8th of the
throughput of a channel.
(Reference: Broadband Telecommunications Handbook. Pages 432-444. Regis J. Bates. McGraw Hill. ISBN: 0071346481;
http://www.techfest.com/networking/wan/tcarrier.htm)
***
Configuring T1 Controllers
Configuration of T1 parameters is accomplished on the T1 controller:
Router(config)# controller t1 0/1
Router(config-controller)# framing esf
Router(config-controller)# linecode b8zs
Router(config-controller)# clock source line primary
ESF is the default framing, and b8zs is the default linecode for T1
controllers.
The clock source command specifies which clock to use for synchronization.
Specifying line primary will use the received data stream to stay
synchronized. The clock source can be set to internal as well, but this is not
usually recommended.
Troubleshooting T1 Circuits
To view framing and line code information:
Router# show controllers t1
T1 0/1 is up.
No alarms detected.
Framing is ESF, Line Code is B8ZS, Clock Source is line
Data in current interval (14 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations 0 Slip
Secs, 0 Fr Loss Secs,
0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0
Bursty Err Secs,
0 Severely Err Secs, 0 Unavail Secs
Total Data (last 79 15 minute intervals):
0 Line Code Violations, 0 Path Code Violations, 0 Slip
Secs, 0 Fr Loss Secs,
0 Line Err Secs, 0 Degraded Mins, 0 Errored Secs, 0
Bursty Err Secs,
0 Severely Err Secs, 0 Unavail Secs
(Reference: http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017d023.html#wp1141533)
***
Troubleshooting T1 Circuits (continued)

If a large number of framing errors are occurring, possible causes can
include:
• Too much noise on the link
• Defective cable
• Incorrectly configured CSU line clock
• One of the clocks is configured for internal clocking
• Ones density problem on the T1 circuit
(Reference: http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1915.htm)
Optical Carriers
If throughput beyond the speed of T-carriers or E-carriers is necessary, an
Optical Carrier (OC) can be used. OC circuits utilize a SONET fiber
network to transmit digital signals.
The specifics of OC technology go beyond the scope of this guide. However,
the following chart details the speeds for common OC configurations (please
note: this is not a comprehensive list):
OC-1 51.84 Mbps

OC-3 155.52 Mbps
OC-12 622.08 Mbps
OC-24 1.244 Gbps
OC-48 2.488 Gbps
OC-192 9.953 Gbps
(Reference: http://www.zytrax.com/tech/data_rates.htm#ocx)
***
Cable & DSL Technologies v1.02 – Aaron Balchunas 1
- Cable and DSL Technologies -

Cable Technologies
Traditional Cable Television (CATV) provided a unidirectional transport of
video channels to home consumers. Competition from satellite TV providers
forced the development of a full-duplex data infrastructure, across a Hybrid
Fiber/Coaxial (HFC) network.
Open-standard specifications for data communication across this Broadband
Cable network are defined by the Data Over Cable Service Interface
Specification (DOCSIS). DOCSIS was developed by the Multimedia
Cable Network System (MCNS) Partners (now CableLabs), and defines
the Layer-1 and Layer-2 specifications for cable communication.
There are three current implementations of this specification:
• DOCSIS v1.0
• DOCSIS v1.1
• DOCSIS v2.0
While DOCSIS v2.0 is the newest specification, the most widespread
implementation (currently) is still v1.1. (DOCSIS v3.0 is under
development, presently). DOCSIS defines two key devices necessary for
broadband cable communication:
• Cable Modem Termination System (CMTS) – Usually located at
the central office (or headend), modulates and demodulates signals to
and from the Cable Modem. A single CMTS can accommodate
thousands of cable modems, and provides the connection point to the
Internet backbone.
• Cable Modem (CM) – Usually located at the customer premises,
terminates the cable line, and modulates/demodulates signals to and
from the CMTS.
Data flowing from the CMTS to the Cable Modem is deemed downstream
traffic. Data from the Cable Modem to the CMTS is upstream traffic.
A DOCIS binary configuration file provides the appropriate ISP parameters
for cable modems to connect to the network.
(Reference: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/cable.pdf; http://www.cablemodem.com/)
***
Cable Modulation
Recall that downstream traffic refers to data flowing from the CMTS to the
cable modem. The actual physical signal sent across the HFC network is in
the form of Radio Frequency (RF) waves, which constitute a segment of
the electromagnetic spectrum.
Electromagnetic signals are measured by the frequency of their waves, or
the number of cycles completed per a given time period. The standard
frequency measurement unit is the hertz (Hz), or one cycle per second.
Wavelength refers to the physical length of a frequency cycle. Frequency
and wavelength are inversely related to each other. The higher the frequency,
the shorter the wavelength will be.
Voltage
Wavelength
Time
1 second
Frequency = 2 Hz
Modulation is the method of altering a signal (usually by varying its

amplitude, frequency, or phase), to convey a message or data stream:
(Reference: http://www-scm.tees.ac.uk/users/u0000408/Async/async.htm)
***
Cable Modulation (continued)

IP traffic across the cable infrastructure is typically encapsulated as MPEG
(Moving Picture Experts Group) frames. CMTS devices and Cable
Modems modulate MPEG frames onto an RF signal, using QAM
(Quadrature Amplitude Modulation).
QAM implementations typically used for downstream traffic include:
• 64-QAM (6 bits per symbol - amount of data sent at a given interval)
• 256-QAM (8 bits per symbol)
Upstream traffic refers to data from the Cable Modem to the CMTS, and
typically utilizes QPSK (Quadrature Phase Shift Keying) modulation, or
16-QAM.
(Reference: http://www.indiana.edu/~emusic/acoustics/frequency.htm; http://en.wikipedia.org/wiki/Quadrature_amplitude_modulation)
Cable Standards
Three cable standards are used heavily worldwide:
• NTSC (National Television Standards Committee) – cable standard
used in the United States.
• SECAM (Système Electronic Couleur avec Mèmoire) – cable
standard used in France and other European countries.
• PAL (Phase-Alternating Line) – cable standard used in most other
countries.
The NTSC standard allocates 6 megahertz (MHz) for each TV channel.
Thus, when “flipping” through TV channels, one is actually scanning up or
down RF frequencies.
Downstream data traffic is also assigned a 6 MHz channel. Upstream data
traffic can utilize as small as a 2 MHz channel.
Traffic is generally assigned the following frequencies:
• 5 MHz to 42 MHz – allocated for upstream traffic
• 50 MHz to 860 MHz – allocated for downstream traffic.
(Reference: http://www.cisco.com/univercd/cc/td/doc/product/cable/cab_rout/cr72hig/ub72fqcy.htm)
***
Components of a Cable Modem

Most standard cable-modems are comprised of several key parts:
• Tuner
• Demodulator
• Modulator
• MAC
• CPU
• Local interface (Ethernet or USB)
The tuner physically terminates the coaxial cable, and utilizes a diplexer to
simultaneously manage both upstream and downstream frequencies.
The demodulator provides several functions for downstream traffic:
• Demodulates the QAM encoding from the signal.
• Provides an analog-to-digital conversion.
• Performs error correction on the converted digital signal.
• Synchronizes the MPEG frames to ensure data is delivered in the
correct order.
The modulator performs the encoding necessary to send upstream traffic.
(Reference: http://www.cable-modems.org/tutorial/; http://computer.howstuffworks.com/cable-modem.htm)
***
Cable Modem Initiation

When a cable modem is powered on, it communicates with the CMTS and
performs the following provisioning process:
1. Scans for a downstream channel and establishes synchronization with
the CMTS.
2. Obtains upstream parameters from the CMTS.
3. Performs ranging and automatic adjustments, including the required
power levels (usually between 40 – 50 dBmV). Layer-1 and Layer-2
connectivity is established at this stage.
4. Establishes IP connectivity using DHCP.
5. Establishes Time of Day (ToD).
6. Acquires the DOCSIS parameter file via TFTP.
7. Registers with the CMTS.
8. Initializes baseline privacy.
Services such as TFTP, DHCP, and ToD must be made available at the
provider’s headend for the provisioning process to complete successfully.
Once the process is complete, the customer equipment (such as a router or
workstation) can request network layer information from the cable provider,
including:
• An IP address (usually public)
• A subnet mask
• A default gateway
(Reference: http://www.cisco.com/warp/public/109/initialization_pdf_wallchart.pdf)
***
DSL Technologies
DSL (Digital Subscriber Line) technologies utilize unused (and higher)
frequencies on existing telephone lines for data communication. Both voice
and data services can be used simultaneously on the same copper wire. DSL
is a Layer-1 technology only.
DSL service requires the use of a DSL modem at the customer premises.
The DSL modem connects across the POTS network to a DSL access
multiplexer (DSLAM) at the provider’s Central Office (CO). A single
DSLAM can service a large number of DSL modems.
Data flowing from the DSLAM to the DSL modem is deemed downstream
traffic. Data from the DSL modem to the DSLAM is upstream traffic.
A filter is often used on lines connecting to a phone or fax to prevent the
data signal (intended for the DSL modem) from interfering with analog
voice communication.
There are two fundamental types of DSL:
• ADSL (Asymmetric DSL) – downstream rate is higher than upstream
rate. ASDL is the most common DSL implementation.
• SDSL (Symmetric DSL) – downstream/upstream rates are identical
DSL is subject to distance limitations – usually a maximum of 18,000 feet.
Additionally, the further the distance a customer is from the provider’s CO,
the slower the service.
Factors that can affect DSL service:
• Signal attenuation – the signal becomes progressively weaker as the
distance increased from the CO.
• Bridge Taps
• Load Coils
• Wire Gauge – thicker wire is required for higher DSL speeds.
• Impedance mismatch
• Crosstalk – refers to noise introduced onto a wire from another
closely bundled wire.
• RF Interference
***
Flavors of DSL Technologies

Recall that the two fundamental types of DSL are ADSL and SDSL. Each
implementation of DSL supports multiple flavors, referred to collectively as
xDSL. Flavors of ADSL include:
• Standard ADSL – provides a faster downstream rate (usually up to 8
Mbps) than upstream rate (usually up to 1 Mbps). Supports
simultaneous use of voice and data on a wire.
• RADSL (Rate-Adaptive DSL) – dynamically adjusts the data rate
depending on the current condition of the local loop. Supports
• VDSL (Very-High-Rate DSL) – provides very high speed service
(up to 52 Mbps downstream, and 16 Mbps upstream) over much
shorter distances (less than 5,000 feet). The Cisco Long Reach
Ethernet (LRE) standard is based on VDSL. Supports simultaneous
use of voice and data on a wire.
Flavors of SDSL include:
• SDSL – generic term referring to any xDSL that offers equal upstream
and downstream data rates.
• HDSL (High-Data-Rate DSL) – delivers between 1.5 and 2.3 Mbps
of symmetrical upstream and downstream speeds. Does not support
• IDSL (ISDN DSL) – operates over ISDN BRI technology, with a
maximum of 144 Kbps (2B channels + 1D channel). Unlike ISDN,
IDSL does not require call setup. However, IDSL does not support
Flavor Type Data Rate (down/up) Voice & Data? Distance

ADSL Asymmetric 8 Mbps / 1 Mbps Yes 18,000 feet
RADSL Asymmetric Variable Yes 18,000 feet
VDSL Asym./Sym. 52 Mbps / 16 Mbps Yes ~ 4,500 feet
HDSL Symmetric 2.3 Mbps / 2.3 Mbps No 12,000 feet
IDSL Symmetric 144 Kbps / 144 Kbps No > 20,000 feet
(Reference: http://electronics.howstuffworks.com/vdsl.htm)
***
DSL Modulation
The three most common ADSL modulation types are as follows:
• CAP (Carrierless Amplitude Phase)
• DMT (Discrete MultiTone)
• G.Lite DMT (or Splitterless DMT)
CAP modulation separates the signal into three single-channel bands.
Notice that a buffer has been built in-between each band, to reduce possible
interference:
• 0 kHz to 4 kHz – allocated for POTS (voice) services.
• 25 kHz to 160 kHz – allocated for upstream data traffic.
• 240 kHz to 1.5 MHz – allocated for downstream data traffic.
DMT (ANSI T1.413 or ITU G992.1) has mostly replaced CAP as the
predominant ADSL modulation standard. As with CAP, DMT modulation
separates the signal three separate bands:
• 0 kHz to 4 kHz – allocated for POTS (telephony) services
• 20 kHz to 130 kHz – allocated for upstream data traffic.
• 140 kHz to 1 MHz – allocated for downstream data traffic.
However, DMT additionally segments all three bands into 256 equal
subchannels of 4 kHz, as opposed to CAP’s single-channel implementation.
If the quality of a particular subchannel is impaired due to noise, DMT will
dynamically shift traffic to a different channel.
G.Lite DMT (ITU G992.2) is mostly used in home consumer markets, and
allows the use of simultaneous voice/data without splitters. G.Lite supports
only 128 channels, and thus cannot attain the same speeds as standard DMT.
Layer-2 DSL Protocols

The DSL standard is a Layer-1 technology. The most common Layer-2
protocols used over DSL include:
• RFC 1483 Bridging
• Point-to-Point Protocol over Ethernet (PPPoE)
• Point-to-Point Protocol over ATM (PPPoA)
RFC 1483 Bridging is not widely implemented due to scalability and
security limitations. This guide will concentrate on PPPoE and PPPoA.
***
PPPoE
PPPoE combines the advantages of PPP (authentication and link-control)
with Ethernet (robust bridging). The PPP frame is encapsulated within an
Ethernet frame.
PPPoE utilizes the following PPP components:
• HDLC – for encapsulating packets into frames over serial lines.
• LCP – for establishing, maintaining, and terminating the link.
• NCP – allows multiple Layer-3 protocols (such as IP and IPX) to be
encapsulated into frames.
The PPPoE session is initiated by a PPPoE-enabled client (usually a
workstation or router) at the customer premises. The PPPoE client must
authenticate with the PPPoE server (usually the DSLAM), before the session
can be fully established.
The PPPoE connection process progresses through the following steps:
• The PPPoE client broadcasts out a PPPoE Active Discovery Initiation
(PADI) packet, and specifies the type of service it requires.
• The PPPoE server responds with a unicast PPPoE Active Discovery
Offer (PADO) packet.
• The PPPoE client then unicasts a PPPoE Active Discovery Request
(PADR) packet.
• The PPPoE server then responds with a unicast PPPoE Active
Discovery Session-Confirmation (PADS) packet.
After the PPPoE session has been established, PPP will perform its LCP and
NCP tasks as normal.
To end the PPPoE session, either the client or server can send a PPPoE
Active Discovery Terminate (PADT) packet.
The PPPoE MTU size must not be set higher than 1492 bytes. A typical
ethernet frame is 1500 bytes, but the PPPoE and PPP Protocol ID
information require 8 bytes:
Ethernet Header PPPoE Header (6 bytes) PPP Protocol ID (2 bytes) Data
1500 bytes
(Reference: http://www.cisco.com/en/US/tech/tk175/tk819/tsd_technology_support_protocol_home.html; http://www.cisco.com/warp/public/794/pppoe_arch.html)
***
Configuring PPPoE
A Cisco IOS device can function as a PPPoE client. First, Virtual Private
Dialup Network (VPDN) must enabled for PPPoE:
Router(config)# vpdn enable
Router(config)# vpdn-group pppoe
Router(config-vpdn)# request-dialin
Router(config-vpdn-acc-in)# protocol pppoe
Next, the ethernet or ATM interface connecting to the ADSL modem must
have PPPoE enabled:
Router(config)# interface ethernet 0/0
Router(config-if)# no ip address
Router(config-if)# pppoe enable
Router(config-if)# pppoe-client dial-pool-number 1
Router(config)# interface atm 0/0
Router(config-if-vc)# pppoe-client dial-pool-number 1
The VPI/VCI must match the provider’s. Next, a virtual DSL dialer interface
must be created and configured:
Router(config)# interface dialer 1
Router(config-if)# ip mtu 1492
Router(config-if)# ppp chap hostname MYNAME
Router(config-if)# ppp chap password MYPASSWORD
Unlike ISDN, a dialer-list is not required for DSL, as the connection is

always on. Notice that the mtu has been reduced to 1492.
The provider’s DSL modulation type is auto-detected by default, but can be
manually specified on ATM interfaces:
Router(config-if)# dsl operating-mode auto
Router(config-if)# dsl operating-mode ansi-dmt
Router(config-if)# dsl operating-mode itu-dmt
Router(config-if)# dsl operating-mode splitterless
(http://www.cisco.com/en/US/tech/tk175/tk15/technologies_configuration_example09186a0080126dc0.shtml)
***
Additional PPPoE Configuration

NAT Overload is often configured on the client PPPoE router:
Router(config)# interface ethernet 0/1
Router(config-if)# ip nat inside
Router(config-if)# ip nat outside
Router(config)# access-list 10 permit ip 192.168.123.0 0.0.0.255
Router(config)# ip nat inside source list 10 interface ethernet0/0 overload
DHCP can be configured to provide IP addressing to clients behind the

router:
Router(config)# ip dhcp pool MYPOOL
Router(dhcp-config)# network 192.168.123.0 255.255.255.0
Router(dhcp-config)# default-router 192.168.123.1
Router(dhcp-config)# import all
The import all parameter allows DNS information pulled from the provider
to be passed to internal clients.
Finally, traffic must be directed out the dialer interface using a default route:
Router(config)# ip route 0.0.0.0 0.0.0.0 dialer1
***
PPPoA
Unlike PPPoE (and RFC 1483 Bridging), which are both bridging
technologies, PPPoA routes traffic from the PPPoA-enabled client (again,
usually a workstation or router), to the provider’s aggregating router.
All other PPP-related functions are identical between PPPoE and PPPoA.
Configuring PPPoA
A Cisco IOS device can function as a PPPoA client. First, Virtual Private
Dialup Network (VPDN) must enabled for PPPoA:
Router(config)# vpdn enable
Router(config)# vpdn-group pppoa
Router(config-vpdn)# request-dialin
Router(config-vpdn-acc-in)# protocol pppoa
Next, the ATM interface connecting to the ADSL modem must have PPPoA
enabled:
Router(config-if)# dsl operating-mode auto
Router(config-if-vc)# encapsulation aal5mus ppp dialer
Router(config-if-vc)# dialer pool-member 1
The VPI/VCI must match the provider’s. Next, a virtual DSL dialer interface
must be created and configured:
Router(config-if)# ppp chap hostname MYNAME
Router(config-if)# ppp chap password MYPASSWORD
Notice that reducing the mtu to 1492 is not required for PPPoA.
***
Troubleshooting PPPoE and PPPoA Connections

To view the current status of PPPoE sessions:
Router# show pppoe session
To view the establishment and termination of PPPoE sessions in real-time:

Router# debug pppoe events
To debug PAP or CHAP authentication issues:

Router# debug ppp authentication
To troubleshoot Layer-1 information, including whether the local router is

communicated with the DSLAM:
Router# show dsl interface atm 0/0
***
Basic Voice over IP v1.01 – Aaron Balchunas 1
- Basic Voice over IP -

Voice over IP (VoIP)
Voice over IP (VoIP) is a digital form of transport for voice transmissions,
replacing analog phone systems.
The benefits of VoIP are considerable:
• Better use of bandwidth - Traditional voice requires a dedicated 64-
Kbps circuit for each voice call, while VoIP calls can use considerably
less. Additionally, no bandwidth is consumed when no call is being
made.
• Single form of cabling – Reduces implementation and maintenance
costs by having a standardized and consolidated cabling and
equipment infrastructure.
• Cost savings from integration into the data network – Toll charges
for inter-office voice communication can be avoided by routing voice
traffic across existing data lines.
• Integration into devices beyond telephones
Basic VoIP components can include:

• Phones – including both analog and IP phones.
• Gateways – allows a non-VoIP (analog) device to communicate with
the VoIP network, or a VoIP device to communicate with an analog
network.
• Application Servers – provides required applications to VoIP
phones.
• Gatekeepers – maps phone numbers to IP addresses, and grants
permission for call setup
• Call Agents – handles call routing and setup.
Digital Signal Processors (DSP’s) are used by devices to perform analog-

to-digital and digital-to-analog conversions. Both VoIP phones and gateways
utilize DSP technology.
***
VoIP Packetization
Voice traffic must be packetized as it traverses the IP network. Sound is
first captured using a microphone on the headset. A voice call requires a 4
kHz (4000 Hz) channel. To convert analog voice to a digital format,
samples of the frequency and amplitude of the analog wave are made. Thus,
sampling merely takes a snapshot of the signal at a given point in time.
The amplitude height of each snapshot is assigned a numeric value, through
a process called quantization. This numeric value is then represented as a
sequence of binary digits (usually 8) through a process called encoding.
The Nyquist sampling theorem dictates that the analog wave should be
sampled at a rate of twice the channel’s frequency range:
fs = 2(freq. range)
Thus, assuming a range of 4000 Hz, this requires a rate of 8000 samples per
second. Remember that each sample is assigned an 8-bit value to represent
the amplitude height at the time of sampling. Thus, a dedicated 64,000-bit
channel (8-bits x 8000 samples per second) was traditionally required for a
voice call (hence a DS0 being 64Kbps).
The process of encoding an analog signal into digital format is handled by a
codec (coder-decoder). The codec usually provides a level of compression.
The efficiency of the compression varies with the codec used; however,
more compression generally degrades sound quality. Various codecs
include:
• G.711 – uses 64 Kbps for a voice call
• G.726 – uses 32, 24, or 16 Kbps for a voice call
Generally, the analog sound is chopped into groups of 10ms, and then
sampled and encoded. Each group (or often two groups, for a total of 20ms
of analog sound) is encapsulated within an IP packet. At the transport layer,
Real-Time Protocol (RTP) is used instead of TCP. RTP operates on top of
UDP.
When the voice packet arrives at a digital-to-analog gateway, the headers are
stripped off, and the sound is reassembled as an analog stream.
***
Cisco VoIP Integration

Cisco devices operating as VoIP gateways can contain a variety of analog
interfaces, including:
• Foreign Exchange Station (FXS) interface – connects to an analog
device, providing the appropriate voltage and dial tone.
• Foreign Exchange Office (FXO) interface – connects to a PBX
(Private Branch Exchange) or PSTN (Public Switched Telephone
network).
• E&M interface – can also be used to connect to a PBX, or is used for
PBX-to-PBX connections.
Additionally, Cisco gateways can connect to provider PBX’s and networks

using digital interfaces, including:
• ISDN BRI and PRI
• T1/E1 CCS (Common Channel Signaling) – employs a dedicated
channel for signaling.
• T1/E1 CAS (Channel Associated Signaling) – a portion of each
channel is utilized for signaling.
***
VoIP Signaling Protocols

VoIP protocols are responsible for the three key stages of a voice call:
• Call setup
• Call maintenance
• Call teardown
The most common VoIP protocols are as follows:
• H.323 – an ITU standard
• Session Initiation Protocol (SIP) – an IETF standard
• Media Gateway Control Protocol (MGCP) – an IETF standard
• Skinny Client Control Protocol (SCCP) – Cisco proprietary
***
Cisco VoIP CallManager Configuration – Voice Trunk Ports

Traditionally, Cisco IP phones contain a switch with two interfaces. The first
interface connects the IP phone to the wall jack. The second interface
connects the user’s workstation to the IP phone. This allows a single cable to
handle the user’s voice and data needs.
To keep the voice/data traffic segregated, the IP phone forms a trunk link
with the remote switch. Data traffic is tagged as a different VLAN than the
voice traffic. Configuration on the remote switch (or the call-manager
functioning as the switch) is simple:
VoIP-Switch(config)# interface FastEthernet0/1/4
VoIP-Switch(config-if)# switchport access vlan 50
VoIP-Switch(config-if)# switchport trunk native vlan 50
VoIP-Switch(config-if)# switchport mode trunk
VoIP-Switch(config-if)# switchport voice vlan 60
In the above example, data traffic will be tagged as VLAN 50, while voice
traffic will be tagged as VLAN 60.
***
Cisco VoIP CallManager Configuration – Dial Peers

Dial Peers provide call-routing, and serve two key functions:
• VoIP dial-peers - used to connect Cisco call-managers, gateways,
or gatekeepers to other such VoIP devices. For example, two call-
managers at separate branches would point to each other using
VoIP dial-peer commands.
• POTS dial-peers – used to connect Cisco VoIP devices to an
analog device or network. A dial-string is mapped to a local analog
port on the VoIP gateway or call-manager.
Thus, the function of a Dial Peer is to match an incoming call with a
destination pattern, which points to either a remote device or local interface.
To configure a VoIP dial-peer:
CallManager(config)# dial-peer voice 1 voip
CallManager(config-dial-peer)# session procotol sipv2
CallManager(config-dial-peer)# session target ipv4:10.1.5.50
CallManager(config-dial-peer)# destination-pattern 15865551212
CallManager(config-dial-peer)# codec g711ulaw
The above configuration maps a sip connection to a remote VoIP peer at

address 10.1.5.50 for phone number 15865551212. The g711 codec is being
employed.
To configure a POTS dial-peer:
CallManager(config)# dial-peer voice 2 pots
CallManager(config-dial-peer)# destination-pattern 1212
CallManager(config-dial-peer)# port 0/2/0
The above configuration maps an extension or phone number of 1212 to the

analog voice port 0/2/0.
(Reference: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/int_c/dpeer_c/dp_ovrvw.htm)
***
Cisco VoIP CallManager Configuration – Telephony Service

Telephony-Service configuration provides a wide variety of global
configuration options for a Cisco CallManger:
CallManager(config)# telephony-service
CallManager(config-telephony-service)#
The configuration files for specific models of IP phones are stored in flash,
with a .bin extension. To load these configuration files:
CallManager(config-telephony-service)# load 7914 S00105000200
CallManager(config-telephony-service)# load 7920 7920.4.0-02-00
CallManager(config-telephony-service)# load 7960-7940 P00308000400
To specify the maximum number of phones that can register with the Call-
Manager (dependent on the hardware/software platform):
CallManager(config-telephony-service)# max-ephones 12
To specify the maximum number of directory numbers (DNs) the Call-

Manager will support (also dependent on the hardware/software platform):
CallManager(config-telephony-service)# max-dn 48
To specify the IP address of the Call-Manager on the voice VLAN:

CallManager(config-telephony-service)# ip source-address 10.5.5.1 port 2000
To specify the extension for voicemail:

CallManager(config-telephony-service)# voicemail 2000
To specify the audio file for music-on-hold:

CallManager(config-telephony-service)# moh music-on-hold.au
To configure a username and password for the Call Manager’s web

interface, and to enable configuration of DN’s through that interface:
CallManager(config-telephony-service)# web admin system name AARON password CISCO
CallManager(config-telephony-service)# dn-webedit
To access the web-interface, use the following URL:

http://IPADDRESS/telephony_service.html
***
Cisco VoIP CallManager Configuration – Telephony Service (continued)

To allow the transferring of calls to an outside line, using a specific dial-
pattern (such as dialing 9 first, and then a seven-digit number):
CallManager(config-telephony-service)# transfer-pattern 9 . . . . . . .
To configure the auto-attendant for night-service:

CallManager(config-telephony-service)# night-service code *11
CallManager(config-telephony-service)# night-service day Mon 18:00 06:00
CallManager(config-telephony-service)# night-service day Tue 18:00 06:00
CallManager(config-telephony-service)# night-service day Wed 18:00 06:00
CallManager(config-telephony-service)# night-service day Thu 18:00 06:00
CallManager(config-telephony-service)# night-service day Fri 18:00 06:00
To configure a directory of extensions:

CallManager(config-telephony-service)# directory entry 1 3000 name Aaron
CallManager(config-telephony-service)# directory entry 1 3001 name Petey
CallManager(config-telephony-service)# directory entry 1 3002 name Team Awesome
CallManager(config-telephony-service)# directory entry 1 3003 name Team Tiger
CallManager(config-telephony-service)# directory entry 1 3003 name Jack Nicholson
CallManager(config-telephony-service)# directory entry 1 3004 name Nick Cage
To define the URL’s for ephones:

CallManager(config-telephony-service)# url directories http://10.5.5.1/localdirectory
CallManager(config-telephony-service)# url services http://10.5.5.1/menu.php
CallManager(config-telephony-service)# url authentication http://10.5.5.1/auth.php
Some configuration changes require a reset of the phone(s). To reset all

phones connected to the Call Manager:
CallManager(config-telephony-service)# reset all
(Reference: http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_example09186a00800ffdcc.shtml)
***
Cisco VoIP CallManager Configuration – DN’s and Extensions

Directory Numbers (DNs) are assigned to phones for identification and to
allow call-routing. Call Managers usually support a finite number of DNs,
depending on the hardware/software/licensing platform.
Extensions are then mapped to these DNs. The Call Manager identifies the
phone using a DN, but users call a phone using the extension number. To
configure a DN:
CallManager(config)# ephone-dn 5 dual-line
CallManager(config-ephone-dn)# number 3001
CallManager(config-ephone-dn)# description Call at your own risk
CallManager(config-ephone-dn)# name Petey
In the above example, dn 5 is configured as a dual-line, which allows for

call transfer, conferencing, and call waiting. DNs/extensions that serve
solely as a voicemail box can leave off the dual-line parameter.
An extension number of 3001 has been assigned to this DN.
(Reference: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122z/122zj15/cme30cr/icr30am.htm#wp1008071)
Cisco VoIP CallManager Configuration – Phones

To configure the actual VoIP phone:
CallManager(config)# ephone 7
CallManager(config-ephone)# mac-address 0011.2233.4455
CallManager(config-ephone)# type 7920
CallManager(config-ephone)# button 1:5
CallManager(config-ephone)# pin 12345
CallManager(config-ephone)# speed-dial 1 3002 label “Team Awesome”
In the above example, ephone 7 has been identified as having a mac-address

of 0011.2233.4455, and a model number of 7920.
The button command maps the first button (or extension on the phone –
Cisco phones support multiple extensions) with DN number 5 (per our
previous configuration, this maps to extension 3001).
Finally, the phone’s pin number for voice mail has been set to 12345, and a
speed-dial entry has been added for extension 3002.
(Feference: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122z/122zj15/cme30cr/icr30am.htm#wp1014674)
***
Introduction to QoS v1.21 – Aaron Balchunas 1
- Introduction to QoS -
Obstacles to Network Communication
Modern networks support traffic beyond the traditional data types, such as
email, file sharing, or web traffic. Increasingly, data networks share a
common medium with more sensitive forms of traffic, like voice and video.
These sensitive traffic types often require guaranteed or regulated service,
as such traffic is more susceptible to the various obstacles of network
communication, including:
Lack of Bandwidth – Describes the simple lack of sufficient throughput,
which can severely impact sensitive traffic. Increasing bandwidth is
generally considered the best method of improving network communication,
though often expensive and time-consuming.
Bandwidth is generally measured in bits-per-second (bps), and can be
offered at a fixed-rate (as Ethernet usually is), or at a variable-rate (as
Frame-Relay often is). Various mechanisms, such as compression, can be
used to pseudo-increase the capacity of a link.
Delay – Defines the latency that occurs when traffic is sent end-to-end
across a network. Delay will occur at various points on a network, and will
be discussed in greater detail shortly.
Jitter – Describes the fragmentation that occurs when traffic arrives at
irregular times or in the wrong order. Jitter is thus a varying amount of
delay. Voice communication is especially susceptible to jitter. Jitter can be
somewhat mitigated using a de-jitter buffer.
Data Loss – Defines the packet loss that occurs due to link congestion. A
full queue will drop newly-arriving packets - an effect known as tail drop.
All of above factors adversely affect network communication. Voice over IP
(VoIP) traffic, for example, begins to degrade when delay is higher than 150
ms, and when data loss is greater than 1%.
Quality of Service (QoS) tools have been developed as an alternative to
merely increasing bandwidth. These QoS mechanisms are designed to
provide specific applications with guaranteed or consistent service in the
absence of optimal bandwidth conditions.
***
Types of Delay
Delay can occur at many points on a network. Collectively, this is known as
end-to-end delay. The various types of delay include:
• Serialization Delay – refers to the time necessary for an interface to
encode bits of data onto a physical medium. Calculating serialization
delay can be accomplished using a simple formula:
________# of bits________
bits per second (bps)
Thus, the serialization delay to encode 128,000 bits on a 64,000 bps

link would be 2 seconds.
• Propagation Delay – refers to the time necessary for a single bit to
travel end-to-end on a physical wire. For the incredibly anal geeks, the
rough formula to estimate propagation delay on a copper wire:
____Length of the Physical Wire (in meters)___
2.1 x 108 meters/second
• Forwarding (or Processing) Delay – refers to the time necessary for

a router or switch to move a packet between an ingress (input) queue
and an egress (output) queue. Forwarding delay is affected by a
variety of factors, such as the routing or switching method used, the
speed of the device’s CPU, or the size of the routing table.
• Queuing Delay – refers to the time spent in an egress queue, waiting
for previously-queued packets to be serialized onto the wire. Queues
that are too small can become congested, and start dropping newly
arriving packets (tail drop). This forces a higher-layer protocol (such
as TCP) to resend data. Queues that are too large can actually queue
too many packets, causing long queuing delays.
• Network (Provider) Delay – refers to the time spent in a WAN
provider’s cloud. Network delay can be very difficult to quantify, as it
is often impossible to determine the structure of the cloud.
• Shaping Delay – refers to the delay initiated by shaping mechanisms
intended to slow down traffic to prevent dropped packet due to
congestion.
***
QoS Methodologies
There are three key methodologies for implementing QoS:
• Best-Effort
• Integrated Services (IntServ)
• Differentiated Services (DiffServ)
Best-Effort QoS is essentially no QoS. Traffic is routed on a first-come,
first-served basis. Sensitive traffic is treated no differently than normal
traffic. Best-Effort is the default behavior of routers and switches, and as
such is easy to implement and very scalable. The Internet forwards traffic on
a Best-Effort basis.
Integrated Services (IntServ) QoS is also known as end-to-end or hard
QoS. IntServ QoS requires an application to signal that it requires a specific
level of service. An Admission Control protocol responds to this request by
allocating or reserving resources end-to-end for the application. If resources
cannot be allocated for a particular request, then it is denied.
Every device end-to-end must support the IntServ QoS protocol(s). IntServ
QoS is not considered a scalable solution for two reasons:
• There is only a finite amount of bandwidth available to reserved.
• IntServ QoS protocols add significant overhead on devices end-to-
end, as each traffic flow must be statefully maintained.
The Resource Reservation Protocol (RSVP) is an example IntServ QoS
protocol.
Differentiated Services (DiffServ) QoS was designed to be a scalable QoS
solution. Traffic types are organized into specific classes, and then marked
to identify their classification. Policies are then created on a per-hop basis to
provide a specific level of service, depending on the traffic’s classification.
DiffServ QoS is popular because of its scalability and flexibility in
enterprise environments. However, DiffServ QoS is considered soft QoS, as
it does not absolutely guarantee service, like IntServ QoS. DiffServ QoS
does not employ signaling, and does not enforce end-to-end reservations.
***
QoS Tools
Various tools have been developed to enforce QoS. Many of these tools are
used in tandem as part of a complete QoS policy:
• Classification and Marking
• Queuing
• Queue Congestion Avoidance
Classification is a method of identifying and then organizing traffic based
on service requirements. This traffic is then marked or tagged based on its
classification, so that the traffic can be differentiated. Classification and
marking are covered in great detail in another guide.
Queuing mechanisms are used to service higher priority traffic before
lower priority traffic, based on classification. A variety of queuing methods
are available:
• First-In First-Out (FIFO)
• Priority Queuing (PQ)
• Custom Queuing (CQ)
• Weighted Fair Queuing (WFQ)
• Class-Based Weighted Fair Queuing (CBWFQ)
• Low-Latency Queuing (LLQ)
Each will be covered in detail in a separate guide.
Queue Congestion Avoidance mechanisms are used to regulate queue
usage so that saturation (and thus, tail drop) does not occur. Random Early
Detection (RED) and Weighted RED (WRED) are two methods of
congestion avoidance, and are both covered in a separate guide.
***
Configuring QoS on IOS Devices

There are four basic methods of implementing QoS on Cisco IOS devices:
• Legacy QoS CLI
• Modular QoS CLI
• AutoQoS
• Security Device Manager (SDM) QoS Wizard
Legacy QoS CLI is a limited and deprecated method of implementing QoS
via the IOS command-line. Legacy CLI combined the classification of
traffic with the enforcement of QoS policies. All configuration occurs on a
per-interface basis.
Modular QoS CLI (MQC) is an improved command-line implementation
of QoS. MQC is considered modular because it separates classification
(using class-maps to match traffic) from policy configuration (using policy-
maps to apply a specific level of service per classification). Policy-maps are
then applied to an interface using a service-policy.
AutoQoS is an automated method of generating QoS configurations on IOS
devices. AutoQoS, originally developed for VoIP traffic, can run a discovery
process to analyze and classify a variety of traffic types. AutoQoS can then
create QoS policies based on those classifications. Afterwards, MQC can be
used to fine-tune AutoQoS’s generated configuration.
The Cisco Security Device Manager (SDM) is a web-based management
GUI for Cisco IOS devices. The SDM QoS Wizard provides a graphical
method of configuring and monitoring QoS. The Wizard separates traffic
into three categories:
• Real-Time – for VoIP and signaling traffic.
• Business-Critical – for transactional, network management, and
routing traffic.
• Best Effort – for all other traffic.
A percentage of the interface bandwidth can then be allocated for each
traffic category.
MQC and AutoQoS will be covered in greater detail in separate guides.
***
QoS Classification and Marking v1.32 – Aaron Balchunas 1
- QoS Classification and Marking -

Classifying and Marking Traffic
Conceptually, DiffServ QoS involves three steps:
• Traffic must be identified and then classified into groups.
• Traffic must be marked on trust boundaries.
• Policies must be created to describe the per-hop behavior for
classified traffic.
DiffServ QoS relies on the classification of traffic, to provide differentiated
levels of service on a per-hop basis. Traffic can be classified based on a wide
variety of criteria called traffic descriptors, which include:
• Type of application
• Source or destination IP address
• Incoming interface
• Class of Service (CoS) value in an Ethernet header
• Type of Service (ToS) value in an IP header (IP Precedence or DSCP)
• MPLS EXP value in a MPLS header
Access-lists can be used to identify traffic for classification, based on
address or port. However, a more robust solution is Cisco’s Network-Based
Application Recognition (NBAR), which will dynamically recognize
standard or custom applications, and can classify based on payload.
Once classification has occurred, traffic should be marked, to indicate the
required level of QoS service for that traffic. Marking can occur within
either the Layer-2 header or the Layer-3 header.
The point on the network where traffic is classified and marked is known as
the trust boundary. QoS marks originating from outside this boundary
should be considered untrusted, and removed or changed. As a general rule,
traffic should be marked as close to the source as possible. In VoIP
environments, this is often accomplished on the VoIP phone itself. Traffic
classification should not occur in the network core.
Configuring DiffServ QoS on IOS devices requires three steps:
• Classify traffic using a class-map.
• Define a QoS policy using a policy-map.
• Apply the policy to an interface, using the service-policy command.
***
Layer-2 Marking
Layer-2 marking can be accomplished for a variety of frame types:
• Ethernet – using the 802.1p Class of Service (CoS) field.
• Frame Relay – using the Discard Eligible (DE) bit.
• ATM - using the Cell Loss Priority (CLP) bit.
• MPLS - using the EXP field.
Marking Ethernet frames is accomplished using the 3-bit 802.1p Class of
Service (CoS) field. The CoS field is part of the 4-byte 802.1Q field in an
Ethernet header, and thus is only available when 802.1Q VLAN frame
tagging is employed. The CoS field provides 8 priority values:
Type Decimal Binary General Application
Routine 0 000 Best effort forwarding

Priority 1 001 Medium priority forwarding
Immediate 2 010 High priority forwarding
Flash 3 011 VoIP call signaling forwarding
Flash-Override 4 100 Video conferencing forwarding
Critical 5 101 VoIP forwarding
Internet 6 110 Inter-network control (Reserved)
Network Control 7 111 Network control (Reserved)
Frame Relay and ATM frames provide a less robust marking mechanism,
compared to the Ethernet CoS field. Both Frame Relay and ATM frames
reserve a 1-bit field, to prioritize which traffic should be dropped during
periods of congestion.
Frame Relay identifies this bit as the Discard Eligible (DE) field, while
ATM refers to this bit as the Cell Loss Priority (CLP) field. A value of 0
indicates a lower likelihood to get dropped, while a value of 1 indicates a
higher likelihood to get dropped.
MPLS employs a 3-bit EXP (Experimental) field within the 4-byte MPLS
header. The EXP field provides similar QoS functionality to the Ethernet
CoS field.
***
Layer-3 Marking
Layer-3 marking is accomplished using the 8-bit Type of Service (ToS)
field, part of the IP header. A mark in this field will remain unchanged as it
travels from hop-to-hop, unless a Layer-3 device is explicitly configured to
overwrite this field.
There are two marking methods that use the ToS field:
• IP Precedence - uses the first three bits of the ToS field.
• Differentiated Service Code Point (DSCP) – uses the first six bits of
the ToS field. When using DSCP, the ToS field is often referred to as
the Differentiated Services (DS) field.
These values determine the per-hop behavior (PHB) received by each
classification of traffic.
IP Precedence
IP Precedence utilizes the first three bits (for a total of eight values) of the
ToS field to identify the priority of a packet. Packets with a higher IP
Precedence value should be provided with a better level of service. IP
Precedence values are comparable to Ethernet CoS values:
Type Decimal Binary General Application
Routine 0 000 Best effort forwarding

Priority 1 001 Medium priority forwarding
Immediate 2 010 High priority forwarding
Flash 3 011 VoIP call signaling forwarding
Flash-Override 4 100 Video conferencing forwarding
Critical 5 101 VoIP forwarding
Internet 6 110 Inter-network control (Reserved)
Network Control 7 111 Network control (Reserved)
By default, all traffic has an IP Precedence of 000 (Routine), and is

forwarded on a best-effort basis.
Normal network traffic should not (and in most cases, cannot) be set to 110
(Inter-Network Control) or 111 (Network Control), as it could interfere with
critical network operations, such as STP calculations or routing updates.
***
Differentiated Service Code Point (DSCP)

DSCP utilizes the first six bits of the ToS header to identify the priority of a
packet. The first three bits identify the Class Selector of the packet, and is
backwards compatible with IP Precedence. The following three bits identify
the Drop Precedence of the packet.
Class Name Binary Class Selector Drop Precedence
Default 000 000 0

AF11 001 010 Low
AF12 001 100 1 Medium
AF13 001 110 High
AF21 010 010 Low
AF22 010 100 2 Medium
AF23 010 110 High
AF31 011 010 Low
AF32 011 100 3 Medium
AF33 011 110 High
AF41 100 010 Low
AF42 100 100 4 Medium
AF43 100 110 High
EF 101 110 5
DSCP identifies six Class Selectors for traffic (numbered 0 - 5). Class 0 is
default, and indicates best-effort forwarding. Packets with a higher Class
value should be provided with a better level of service. Class 5 is the highest
DSCP value, and should be reserved for the most sensitive traffic.
Within each Class Selector, traffic is also assigned a Drop Precedence.
Packets with a higher Drop Precedence are more likely to be dropped
during congestion than packets with a lower Drop Precedence. Remember
that this is applied only within the same Class Selector.
The Class Name provides a simple way of identifying the DSCP value. AF
is short for Assured Forwarding, and is the type of service applied to
Classes 1 – 4. If a packet is marked AF23, then the Class Selector is 2 (the 2
in 23) and its Drop Precedence is High (the 3 in 23).
Packets marked as Class 0 (Default) or Class 5 (Expedited Forwarding or
EF) do not have a Drop Precedence.
***
Modular QoS CLI (MQC)

The Modular QoS CLI (MQC) is an improved command-line
implementation of QoS that replaced legacy CLI commands on IOS devices.
MQC is considered modular because it separates classification from policy
configurations.
There are three steps to configuring QoS using MQC:
• Classify traffic using a class-map.
• Define a QoS policy using a policy-map.
• Apply the policy to an interface, using the service-policy command.
Classifying and Marking Traffic using MQC

Traffic is classified using one or more of the traffic descriptors listed
earlier in this guide. This is accomplished using the class-map command:
Router(config)# access-list 101 permit tcp any 10.1.5.0 0.0.0.255 eq www
Router(config)# class-map match-any LOWCLASS
Router(config-cmap)# match access-group 101
The access-list matches all http traffic destined for 10.1.5.0/24.

The class-map command creates a new classification named LOWCLASS.
The match-any parameter dictates that traffic can match any of the traffic
descriptors within the class-map. Alternatively, specifying match-all dictates
that traffic must match all of the descriptors within the class-map.
Within the class-map, match statements are used to identify specific traffic
descriptors. The above example (match access-group) references an access-
list. To match other traffic descriptors:
Router(config)# class-map match-any HICLASS
Router(config-cmap)# match input-interface fastethernet0/0
Router(config-cmap)# match ip precedence 4
Router(config-cmap)# match ip dscp af21
Router(config-cmap)# match any
The above is not a comprehensive list of descriptors that can be matched.

Reference the link below for a more complete list.
(Reference: http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfmcli2.html)
***
Network-Based Application Recognition (NBAR)

Cisco’s Network-Based Application Recognition (NBAR) provides an
alternative to using static access-lists to identify protocol traffic for
classification. NBAR introduces three key features:
• Dynamic protocol discovery
• Statistics collection
• Automatic traffic classification
NBAR provides classification abilities beyond that of access-lists, including:
• Ability to classify services that use dynamic port numbers. This is
accomplished using the stateful inspection of traffic flows.
• Ability to classify services based on sub-protocol information. For
example, NBAR can classify HTTP traffic based on payload, such as
the host, URL, or MIME type.
NBAR employs a Protocol Discovery process to determine the application
traffic types traversing the network. The Protocol Discovery process will
then maintain statistics on these traffic types.
NBAR recognizes applications using NBAR Packet Description Language
Modules (PDLMs), which are stored in flash on IOS devices. Updated
PDLMs are provided by Cisco so that IOS devices can recognize newer
application types.
NBAR has specific requirements and limitations:
• NBAR requires that Cisco Express Forwarding (CEF) be enabled.
• NBAR does not support Fast EtherChannel interfaces.
• NBAR supports only 24 concurrent host, URL, or MIME types.
• NBAR can only analyze the first 400 bytes of a packet. Note: This
restriction is only for IOS versions previous to 12.3(7), which
removed this restriction.
• NBAR cannot read sub-protocol information in secure (encrypted)
traffic types, such as HTTPS.
• NBAR does not support fragmented packets.
(Reference Reference: CCNP ONT Official Exam Certification Guide. Amir Ranjbar. Pages 110-112:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ps6612/ps6653/prod_qas09186a00800a3ded.pdf)
***
Configuring NBAR
To enable NBAR Protocol Discovery on an interface:
Router(config)# interface fa0/0
Router(config-if)# ip nbar protocol-discovery
To view statistics for NBAR-discovered protocol traffic:

Router# show ip nbar protocol-discovery
FastEthernet0/0
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
30sec Bit Rate 30sec Bit Rate
30sec Max Bit Rate 30sec Max Bit Rate
----------------------- ---------------------- ------------------
http 15648 15648
154861743 154861743
123654 123654
654123 654123
ftp 4907 4907
954604255 954604255
406588 406588
1085994 1085994
NBAR classification occurs within a MQC class-map, using the match

protocol command:
Router(config)# class-map match-any LOWCLASS
Router(config-cmap)# match protocol http
Router(config-cmap)# match protocol ftp
Matching traffic based on sub-protocol information supports wildcards:

Router(config)# class-map match-any HICLASS
Router(config-cmap)# match protocol http host *routeralley.com*
Router(config-cmap)# match protocol http mime “*pdf”
Custom protocol types can be manually added to the NBAR database:

Router(config)# ip nbar port-map MYPROTOCOL tcp 1982
Updated PDLMs can be downloaded into flash and then referenced for
NBAR:
Router(config)# ip nbar pdlm flash://unrealtournament.pdlm
(Reference: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/dtnbarad.pdf)
***
Creating and Applying a QoS Policy using MQC

After traffic has been appropriately classified, policy-maps are used to
dictate how that traffic should be treated (the per-hop behavior).
Router(config)# policy-map THEPOLICY
Router(config-pmap)# class LOWCLASS
Router(config-pmap-c)# set ip precedence 1
Router(config-pmap)# class HICLASS
Router(config-pmap-c)# set ip dscp af41
The policy-map command creates a policy named THEPOLICY. The class

commands associate the LOWCLASS and HICLASS class-maps created
earlier to this policy-map.
Within the policy-map class sub-configuration mode, set statements are used
to specify the desired actions for the classified traffic. In the above example,
specific ip precedence or ip dscp values have been marked on their
respective traffic classes.
A wide variety of policy actions are available:
Router(config)# policy-map LOWPOLICY
Router(config-pmap)# class LOWCLASS
Router(config-pmap-c)# bandwidth 64
Router(config-pmap-c)# queue-limit 40
Router(config-pmap-c)# random-detect
The above is by no means a comprehensive list of policy actions. Reference

the link below for a more complete list. Policy actions such as queuing and
congestion avoidance will be covered in great detail in other guides.
Once the appropriate class-map(s) and policy are created, the policy must be
applied directionally to an interface. An interface can have up to two QoS
policies, one each for inbound and outbound traffic.
Router(config)# int fa0/0
Router(config-if)# service-policy input THEPOLICY
Any traffic matching the criteria of class-maps LOWCLASS and HICLASS,

coming inbound on interface fa0/0, will have the actions specified in the
policy-map THEPOLICY applied.
(Reference: http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfmcli2.html)
***
Troubleshooting MQC QoS

To view all configured class-maps:
Router# show class-map
Class Map LOWCLASS
Match access-group 101
Class Map HICLASS

Match protocol http host *routeralley.com*
Match protocol http mime “*pdf”
To view all configured policy-maps:

Router# show policy-map
Policy Map THEPOLICY
Class LOWCLASS
set ip precedence 1
Class HIGHCLASS
set ip dscp af41
To view the statistics of a policy-map on a specific interface:

Router# show policy-map interface fastethernet0/1
FastEthernet0/0
Service-policy input: THEPOLICY
Class-map: LOWCLASS (match-all)

15648 packets, 154861743 bytes
1 minute offered rate 512000 bps, drop rate 0 bps
Match: access-group 101
QoS Set
ip precedence 1
Packets marked 15648
***
QoS and Queuing v1.31 – Aaron Balchunas 1
- QoS and Queuing -

Queuing Overview
A queue is used to store traffic until it can be processed or serialized. Both
switch and router interfaces have ingress (inbound) queues and egress
(outbound) queues.
An ingress queue stores packets until the switch or router CPU can forward
the data to the appropriate interface. An egress queue stores packets until the
switch or router can serialize the data onto the physical wire.
Switch ports and router interfaces contain both hardware and software
queues. Both will be explained in detail later in this guide.
Queue Congestion
Switch (and router) queues are susceptible to congestion. Congestion occurs
when the rate of ingress traffic is greater than can be successfully processed
and serialized on an egress interface. Common causes for congestion
include:
• The speed of an ingress interface is higher than the egress interface.
• The combined traffic of multiple ingress interfaces exceeds the
capacity of a single egress interface.
• The switch/router CPU is insufficient to handle the size of the
forwarding table.
By default, if an interface’s queue buffer fills to capacity, new packets will
be dropped. This condition is referred to as tail drop, and operates on a first-
come, first-served basis. If a standard queue fills to capacity, any new
packets are indiscriminately dropped, regardless of the packet’s
classification or marking.
QoS provides switches and routers with a mechanism to queue and service
higher priority traffic before lower priority traffic. This guide covers various
queuing methods in detail.
QoS also provides a mechanism to drop lower priority traffic before higher
priority traffic, during periods of congestion. This is known as Weighted
Random Early Detection (WRED), and is covered in detail in another guide.
***
Types of Queues
Recall that interfaces have both ingress (inbound) queues and egress
(outbound) queues. Each interface has one or more hardware queues (also
known as transmit (TxQ) queues). Traffic is placed into egress hardware
queues to be serialized onto the wire.
There are two types of hardware queues. By default, traffic is placed in a
standard queue, where all traffic is regarded equally. However, interfaces
can also support strict priority queues, dedicated for higher-priority traffic.
DiffServ QoS can dictate that traffic with a higher DSCP or IP Precedence
value be placed in strict priority queues, to be serviced first. Traffic in a
strict priority queue is never dropped due to congestion.
A Catalyst switch interface may support multiple standard or strict priority
queues, depending on the switch model. Cisco notates strict priority queues
with a “p”, standard queues with a “q”, and WRED thresholds per queue
(explained in a separate guide) with a “t”.
If a switch interface supports one strict priority queue, two standard queues,
and two WRED thresholds, Cisco would notate this as:
1p2q2t
To view the supported number of hardware queues on a given Catalyst
switch interface:
Switch# show interface fa0/12 capabilities
The strict priority egress queue must be explicitly enabled on an interface:

Switch(config)# interface fa0/12
Switch(config-if)# priority-queue out
To view the size of the hardware queue of a router serial interface:

Router# show controller serial
The size of the interface hardware queue can modified on some Cisco
models, using the following command:
Router(config)# interface serial 0/0
Router(config-if)# tx-ring-limit 3
(Reference: http://www.cisco.com/en/US/tech/tk389/tk813/technologies_tech_note09186a00801558cb.shtml)
***
Forms of Queuing
The default form of queuing on nearly all interfaces is First-In First-Out
(FIFO). This form of queuing requires no configuration, and simply
processes and forwards packets in the order that they arrive. If the queue
becomes saturated, new packets will be dropped (tail drop).
This form of queuing may be insufficient for real-time applications,
especially during times of congestion. FIFO will never discriminate or give
preference to higher-priority packets. Thus, applications such as VoIP can be
starved out during periods of congestion.
Hardware queues always process packets using the FIFO method of
queuing. In order to provide a preferred level of service for high-priority
traffic, some form of software queuing must be used. Software queuing
techniques can include:
• First-In First-Out (FIFO) (default)
• Priority Queuing (PQ)
• Custom Queuing (CQ)
• Weighted Fair Queuing (WFQ)
• Low-Latency Queuing (LLQ)
Each of the above software queuing techniques will be covered separately in
this guide.
Software queuing usually employs multiple queues, and each is assigned a
specific priority. Traffic can then be assigned to these queues, using access-
lists or based on classification. Traffic from a higher-priority queue is
serviced before the traffic from a lower-priority queue.
Please note: traffic within a single software queue (sometimes referred to as
sub-queuing) is always processed using FIFO.
Note also: if the hardware queue is not congested, software queues are
ignored. Remember, software-based queuing is only used when the
hardware queue is congested. Software queues serve as an intermediary,
deciding which traffic types should be placed in the hardware queue first and
how often, during periods of congestion.
***
Priority Queuing (PQ)

Priority Queuing (PQ) employs four separate queues:
• High
• Medium
• Normal (default)
• Low
Traffic must be assigned to these queues, usually using access-lists. Packets
from the High queue are always processed before packets from the Medium
queue. Likewise, packets from the Medium queue are always processed
before packets in the Normal queue, etc. Remember that traffic within a
queue is processed using FIFO.
As long as there are packets in the High queue, no packets from any other
queues are processed. Once the High queue is empty, then packets in the
Medium queue are processed… but only if no new packets arrive in the High
queue. This is referred to as a strict form of queuing.
The obvious advantage of PQ is that higher-priority traffic is always
processed first. The nasty disadvantage to PQ is that the lower-priority
queues can often receive no service at all. A constant stream of High-
priority traffic can starve out the lower-priority queues.
To configure PQ, traffic can first be identified using access-lists:
Router(config)# access-list 100 permit tcp any 10.1.1.0 0.0.0.255 eq www
Then, the traffic should be placed in the appropriate queues:

Router(config)# priority-list 1 protocol ip high list 2
Router(config)# priority-list 1 protocol ip medium list 100
Router(config)# priority-list 1 protocol ip normal
Router(config)# priority-list 1 protocol ipx low
Router(config)# priority-list 1 default normal
The size of each queue (measured in packets) can be specified:

Router(config)# priority-list 1 queue-limit 30 40 50 60
Finally, the priority-list must be applied to an interface:

Router(config)# interface serial0
Router(config-if)# priority-group 1
***
Custom Queuing (CQ)

A less strict form of queuing is Custom Queuing (CQ), which employs a
weighed round-robin queuing methodology.
Each queue is processed in order, but each queue can have a different weight
or size (measured either in bytes, or the number of packets). Each queue
processes its entire contents during its turn. CQ supports a maximum of 16
queues.
To configure CQ, traffic must first be identified by protocol or with an
access-list, and then placed in a custom queue:
Router(config)# access-list 101 permit tcp 172.16.0.0 0.0.255.255 any eq 1982
Router(config)# queue-list 1 protocol ip 1 list 101
Router(config)# queue-list 1 protocol ip 1 tcp smtp
Router(config)# queue-list 1 protocol ip 2 tcp domain
Router(config)# queue-list 1 protocol ip 2 udp domain
Router(config)# queue-list 1 protocol ip 3 tcp www
Router(config)# queue-list 1 protocol cdp 4
Router(config)# queue-list 1 protocol ip 5 lt 1000
Router(config)# queue-list 1 protocol ip 5 gt 800
Each custom queue is identified with a number (1, 2, 3 etc.). Once traffic has
been assigned to custom queues, then each queue’s parameters must be
specified. Parameters can include:
• A limit – size of the queue, measured in number of packets.
• A byte-count – size of the queue, measured in number of bytes.
Configuration of queue parameters is straight-forward:
Router(config)# queue-list 1 queue 1 limit 15
Router(config)# queue-list 1 queue 2 byte-count 2000
Router(config)# queue-list 1 queue 4 byte-count 1024
Finally, the custom queue must be applied to an interface:

Router(config-if)# custom-queue-list 1
(Reference: http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qccq.html)
***
Weighted Fair Queuing (WFQ)

Weighted Fair Queuing (WFQ) dynamically creates queues based on
traffic flows. Traffic flows are identified with a hash value generated from
the following header fields:
• Source and Destination IP address
• Source and Destination TCP (or UDP) port
• IP Protocol number
• Type of Service value (IP Precedence or DSCP)
Traffics of the same flow are placed in the same flow queue. By default, a
maximum of 256 queues can exist, though this can be increased to 4096.
If the priority (based on the ToS field) of all packets are the same, bandwidth
is divided equally among all queues. This results in low-traffic flows
incurring a minimal amount of delay, while high-traffic flows may
experience latency.
Packets with a higher priority are scheduled before lower-priority packets
arriving at the same time. This is accomplished by assigning a sequence
number to each arriving packet, which is calculated from the last sequence
number multiplied by an inverse weight (based on the ToS field). In other
words a higher ToS value results in a lower sequence number, and the
higher-priority packet will be serviced first.
WFQ is actually the default on slow serial links (2.048 Mbps or slower).
To explicitly enable WFQ on an interface:
Router(config-if)# fair-queue
The following are optional WFQ parameters:

Router(config-if)# fair-queue 128 1024
The 128 value increases the maximum size of a queue, measured in packets
(64 is the default). The 1024 value increases the maximum number of
queues from its default of 256.
The following queuing methods are based on WFQ:
• Low Latency Queuing (LLQ)
***
Class-Based WFQ (CBWFQ)

WFQ suffers from several key disadvantages:
• Traffic cannot be queued based on user-defined classes.
• WFQ cannot provide specific bandwidth guarantees to a traffic flow.
• WFQ is only supported on slower links (2.048 Mbps or less).
These limitations were corrected with Class-Based WFQ (CBWFQ).
CBWFQ provides up to 64 user-defined queues. Traffic within each queue is
processed using FIFO. Each queue is provided with a configurable minimum
bandwidth guarantee, which can be represented one of three ways:
• As a fixed amount (using the bandwidth command).
• As a percentage of the total interface bandwidth (using the bandwidth
percent command).
• As a percentage of the remaining unallocated bandwidth (using the
bandwidth remaining percent command).
Note: the above three commands must be used exclusively from each other –
it is no possible to use the fixed bandwidth command on one class, and
bandwidth percent command on another class within the same policy.
CBWFQ queues are only held to their minimum bandwidth guarantee during
periods of congestion, and can thus exceed this minimum when the
bandwidth is available.
By default, only 75% of an interface’s total bandwidth can be reserved. This
can be changed using the following command:
Router(config-if)# max-reserved-bandwidth 90
The key disadvantage with CBWFQ is that no mechanism exists to provide a

strict-priority queue for real-time traffic, such as VoIP, to alleviate latency.
Low Latency Queuing (LLQ) addresses this disadvantage, and will be
discussed in detail shortly.
***
Configuring CBWFQ
CBWFQ is implemented using the Modular Command-Line (MQC)
interface. Specifically, a class-map is used to identify the traffic, a policy-
map is used to enforce each queue’s bandwidth, and a service-policy is used
to apply the policy-map to an interface.
Router(config)# access-list 101 permit tcp 10.1.5.0 0.0.0.255 any eq http
Router(config)# access-list 102 permit tcp 10.1.5.0 0.0.0.255 any eq ftp
Router(config)# class-map HTTP
Router(config)# class-map FTP

Router(config-pmap)# class HTTP
Router(config-pmap)# class FTP
Router(config-if)# service-policy output THEPOLICY
The above example utilizes the bandwidth command to assign a fixed

minimum bandwidth guarantee for each class. Alternatively, a percentage of
the interface bandwidth (75% of the total bandwidth, by default) can be
guaranteed using the bandwidth percent command:
Router(config-pmap-c)# bandwidth percent 40
The minimum guarantee can also be based as a percentage of the remaining

unallocated bandwidth, using the bandwidth remaining percent command.
Router(config-pmap-c)# bandwidth remaining percent 20
Router(config-pmap-c)# bandwidth remaining percent 20
Remember, the bandwidth, bandwidth percent, and bandwidth remaining

percent commands must be used exclusively, not in tandem, with each other.
***
Low Latency Queuing (LLQ)

Low-Latency Queuing (LLQ) is an improved version of CBWFQ that
includes one or more strict-priority queues, to alleviate latency issues for
real-time applications. Strict-priority queues are always serviced before
standard class-based queues.
The key difference between LLQ and PQ (which also has a strict priority
queue), is that the LLQ strict-priority queue will not starve all other queues.
The LLQ strict-priority queue is policed, either by bandwidth or a
percentage of the bandwidth.
As with CBWFQ, configuration of LLQ is accomplished using MQC:
Router(config)# access-list 101 permit tcp 10.1.5.0 0.0.0.255 any eq http
Router(config)# access-list 102 permit tcp 10.1.5.0 0.0.0.255 any eq ftp
Router(config)# access-list 103 permit tcp 10.1.5.0 0.0.0.255 any eq 666
Router(config)# class-map FTP
Router(config)# class-map SECRETAPP

Router(config-pmap)# class SECRETAPP
Router(config-pmap-c)# priority percent 50
Router(config)# int serial0/1
Note that the SECRETAPP has been assigned to a strict-priority queue, using
the priority percent command.
(Reference: http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/pqcbwfq.html)
***
Troubleshooting Queuing
To view the configured queuing mechanism and traffic statistics on an
interface:
Router# show interface serial 0/0
Serial 0/0 is up, line protocol is up
Hardware is MCI Serial
Internet address is 192.168.150.1, subnet mask is 255.255.255.0
MTU 1500 bytes, BW 1544Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 1/1 (allocated/max allocated)
To view the packets currently stored in a queue:

Router# show queue s0/0
To view policy-map statistics on an interface:

Router# show policy-map interface s0/0
Serial0/0
Service-policy input: THEPOLICY
Class-map: SECRETAPP (match-all)

123 packets, 44125 bytes
1 minute offered rate 1544000 bps, drop rate 0 bps
Match: access-group 103
Weighted Fair Queuing
Strict Priority
Output Queue: Conversation 264
Bandwidth 772 (Kbps)
(pkts matched/bytes matched) 123/44125
***
QoS and Congestion Avoidance v1.41 – Aaron Balchunas 1
- QoS and Congestion Avoidance -

Queue Congestion
Switch (and router) queues are susceptible to congestion. Congestion occurs
when the rate of ingress traffic is greater than can be successfully processed
and serialized on an egress interface. Common causes for congestion
include:
• The speed of an ingress interface is higher than the egress interface.
• The combined traffic of multiple ingress interfaces exceeds the
capacity of a single egress interface.
• The switch/router CPU is insufficient to handle the size of the
forwarding table.
By default, if an interface’s queue buffer fills to capacity, new packets will
be dropped. This condition is referred to as tail drop, and operates on a first-
come, first-served basis. If a standard queue fills to capacity, any new
packets are indiscriminately dropped, regardless of the packet’s
classification or marking.
QoS provides switches and routers with a mechanism to queue and service
higher priority traffic before lower priority traffic. Queuing is covered in
detail in a separate guide.
QoS also provides a mechanism to drop lower priority traffic before higher
priority traffic, during periods of congestion. This is known as Weighted
Random Early Detection (WRED), and is covered in detail in this guide.
***
Random Early Detection (RED) and Weighted RED (WRED)

Tail drop proved to be an inefficient method of congestion control. A more
robust method was developed called Random Early Detection (RED).
RED prevents the queue from filling to capacity, by randomly dropping
packets in the queue. RED essentially takes advantage of TCP’s ability to
resend dropped packets.
RED helps alleviate two TCP issues caused by tail drop:
• TCP Global Synchronization – occurs when a large number of TCP
packets are dropped simultaneously. Hosts will reduce TCP traffic
(referred to as slow start) in response, and then ramp up again…
simultaneously. This results in cyclical periods of extreme congestion,
followed by periods of under-utilization of the link.
• TCP Starvation – occurs when TCP flows are stalled during times of
congestion (as detailed above), allowing non-TCP traffic to saturate a
queue (and thus starving out the TCP traffic).
RED will randomly drop queued packets based on configurable thresholds.
By dropping only some of the traffic before the queue is saturated, instead of
all newly-arriving traffic (tail drop), RED limits the impact of TCP global
synchronization.
RED will drop packets using one of three methods:
• No drop – used when there is no congestion.
• Random drop – used to prevent a queue from becoming saturated,
based on thresholds.
• Tail drop – used when a queue does become saturated.
RED indiscriminately drops random packets. It has no mechanism to
differentiate between traffic flows. Thus, RED is mostly deprecated.
Weighted Random Early Detection (WRED) provides more granular
control – packets with a lower IP Precedence or DCSP value can be dropped
more frequently than higher priority packets.
This guide will concentrate on the functionality and configuration of WRED.
***
WRED Fundamentals
There are two methods to configuring WRED. Basic WRED configuration
is accomplished by configuring minimum and maximum packet thresholds
for each IP Precedence or DSCP value.
• The minimum threshold indicates the minimum number of packets
that must be queued, before packets of a specific IP Precedence or
DSCP value will be randomly dropped.
• The maximum threshold indicates the number of packets that must
be queued, before all new packets of a specific IP Precedence or
DSCP value are dropped. When the maximum threshold is reached,
WRED essentially mimics the tail drop method of congestion control.
• The mark probability denominator (MPD) determines the number
of packets that will be dropped, when the size of the queue is in
between the minimum and maximum thresholds. This is measured as
a fraction, specifically 1/MPD. For example, if the MPD is set to 5,
one out of every 5 packets will be dropped. In other words, the chance
of each packet being dropped is 20%.
Observe the following table:
Precedence Minimum Threshold Maximum Threshold MPD
0 10 25 5
1 12 25 5
2 14 25 5
3 16 25 5
If the WRED configuration matched the above, packets with a precedence of
0 would be randomly dropped once 10 packets were queued. Packets with a
precedence of 2 would similarly be dropped once 14 packets were queued.
The maximum queue size is 25, thus all new packets of any precedence
would be dropped once 25 packets were queued.
Advanced WRED configuration involves tuning WRED maximum and
minimum thresholds on a per-queue basis, rather than to specific IP
Precedence or DSCP values. In this instance, the min and max thresholds are
based on percentages, instead of a specific number of packets. This is only
supported on higher model Catalyst switches.
WRED only affects standard queues. Traffic from strict priority queues is
never dropped by WRED.
***
Configuring Basic WRED

WRED configuration can be based on either IP Precedence or a DSCP
value. To configure WRED thresholds using IP Precedence:
Router(config-if)# random-detect
Router(config-if)# random-detect precedence 0 10 25 5
The first random-detect command enables WRED on the interface. The

subsequent random-detect commands apply a minimum threshold,
maximum threshold, and MPD value, for each specified IP Precedence level.
To configure WRED thresholds using DSCP values:
Router(config-if)# random-detect
Router(config-if)# random-detect dscp-based af11 14 25 5
To view the WRED status and configuration on all interfaces:

Router# show interface random-detect
Router# show queuing
WRED is not compatible with Custom Queuing (CQ), Priority Queuing

(PQ) or Weighted Fair Queuing (WFQ), and thus cannot be enabled on
interfaces using one of those queuing methods.
(Reference: http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcwred.html)
***
Configuring Advanced WRED with WRR

On higher-end Catalyst models, WRED can be handled on a per-queue basis,
and is configured in conjunction with a feature called Weighted Round
Robin (WRR).
Recall that interfaces have both ingress (inbound) queues and egress
(outbound) queues. Each interface has one or more hardware queues (also
known as transmit (TxQ) queues). Traffic is placed into egress hardware
queues to be serialized onto the wire.
There are two types of hardware queues. By default, traffic is placed in a
standard queue, where all traffic is regarded equally. However, interfaces
can also support strict priority queues, dedicated for higher-priority traffic.
DiffServ QoS can dictate that traffic with a higher DSCP or IP Precedence
value be placed in strict priority queues, to be serviced first. Traffic in a
strict priority queue is never dropped due to congestion.
A Catalyst switch interface may support multiple standard or strict priority
queues, depending on the switch model. Cisco notates strict priority queues
with a “p”, standard queues with a “q”, and WRED thresholds per queue
(explained in a separate guide) with a “t”.
If a switch interface supports one strict priority queue, two standard queues,
and two WRED thresholds, Cisco would notate this as:
1p2q2t
To view the supported number of hardware queues on a given Catalyst
switch interface:
Switch# show interface fa0/12 capabilities
The strict priority egress queue must be explicitly enabled on an interface:

Switch(config)# interface fa0/12
Switch(config-if)# priority-queue out
***
Configuring Advanced WRED with WRR(continued)

Standard egress queues can be assigned weights, which dictate the
proportion of traffic sent across each queue:
Switch(config-if)# wrr-queue bandwidth 127 255
The above command would be used if a particular port has two standard
egress queues (remember, the number of queues depends on the Catalyst
model). The two numbers are the weights for Queue 1 and Queue 2,
respectively. The weight is a number between 1 and 255, and serves as a
ratio for sending traffic.
In the above example, Queue 2 would be allowed to transmit twice as much
traffic as Queue 1 every cycle (255 is roughly twice that of 127). This way,
the higher-priority traffic should always be serviced first, and more often.
Next, WRED/WRR can be enabled for a particular queue. Cisco’s
documentation on this is inconsistent on whether it is enabled by default, or
not. To manually enable WRED/WRR on Queue 1:
Switch(config-if)# wrr-queue random-detect 1
To disable WRED/WRR and revert to tail-drop congestion control:

Switch(config-if)# no wrr-queue random-detect 1
Next, the WRED/WRR minimum and maximum thresholds must be tuned.

Again, this is accomplished per standard queue, and based on a percentage
of the capacity of the queue.
Recall that each switch port has a specific set of queues (for example,
1p2q2t). The 2t indicates that two WRED/WRR thresholds can exist per
standard queue.
Switch(config-if)# wrr-queue random-detect min-threshold 1 5 10
Switch(config-if)# wrr-queue random-detect max-threshold 1 40 100
The first command sets two separate min-thresholds for Queue 1,

specifically 5 percent and 10 percent.
The second command sets two separate max-thresholds for Queue 1,
specifically 40 percent and 100 percent.
***
Configuring Advanced WRED with WRR (continued)

Why two separate minimum and maximum thresholds per queue? Because
packets of a specific CoS value can be mapped to a specific threshold of a
specific queue.
Observe:
Switch(config-if)# wrr-queue cos-map 1 1 0 1
Switch(config-if)# wrr-queue cos-map 1 2 2 3
The first command creates a map, associating queue 1, threshold 1 with CoS
values of 0 and 1.
The second command creates a map, associating queue 1, threshold 2 with
CoS values of 2 and 3.
All traffic marked with CoS value 0 or 1 will have a minimum threshold of 5
percent, and a maximum threshold of 40 percent (per the earlier commands).
All traffic marked with CoS value 2 or 3 will have a minimum threshold of
10 percent, and a maximum threshold of 100 percent.
The above wrr-queue commands are actually the default settings on higher-
end Catalyst switches.
To view the QoS settings on a Catalyst interface:
Switch# show mls qos interface fa0/10
To view the queuing information for a Catalyst interface:

Switch# show mls qos interface fa0/10 queuing
To view QoS mapping configurations:

Switch# show mls qos maps
***
Configuring Class-Based WRED (CBWRED)

The functionality of Class-Based Weighted Fair Queuing (CBWFQ) can be
combined with WRED to form Class-Based WRED (CBWRED). CBWFQ
is covered in detail in a separate guide.
CBWRED is implemented within a policy-map:
Router(config)# class-map HIGH
Router(config-cmap)# match ip precedence 5
Router(config)# class-map LOW
Router(config-cmap)# match ip precedence 0 1 2

Router(config-pmap)# class HIGH
Router(config-pmap-c)# random-detect precedence 5 30 50 5
Router(config-pmap)# class LOW

Router(config)# int fa0/1
DSCP values can be used in place of IP Precedence:

Router(config)# class-map HIGH
Router(config-cmap)# match ip dscp af31 af41

Router(config-pmap)# class HIGH
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp af31 28 50 5
Router(config-pmap-c)# random-detect dscp af41 30 50 5
To view CBWRED statistics:

Router# show policy-map
***
Traffic Shaping, Policing, and Link Efficiency v1.01 – Aaron Balchunas 1
- Traffic Shaping, Policing, and Link Efficiency -

Traffic Shaping vs. Policing
There are two methods for managing traffic that exceeds a specified rate:
• Traffic shaping
• Traffic policing
These methods are often necessary on the edge separating a customer’s
network from a provider’s network. Providers often force the customer to
adhere to a specific policy of service (or committed rate).
This policy is referred to as the Service Level Agreement (SLA) between
the customer and provider. Shaping and policing mechanisms differ in how
each handles violations of the SLA.
Shaping is usually implemented on the customer side, and will buffer
traffic that exceeds the provider’s committed rate. Thus, shaping can slow
the traffic rate and siphon out traffic in compliance with the provider’s SLA.
Buffering traffic will often create delay and jitter, which can negatively
impact sensitive traffic types. Shaping also requires sufficient memory to
queue buffered traffic. Shaping provides no mechanism to re-mark traffic
that exceeds the committed rate.
Policing is usually implemented on the provider side, and will either drop
or re-mark traffic that exceeds the provider’s committed rate. TCP traffic
that is dropped will be forced to resend, which may result in TCP global
synchronization or starvation issues.
Policing can be implemented for both inbound and outbound traffic on an
interface. Shaping can only occur on outbound traffic on an interface.
(Reference: http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml)
***
Transfer Rate – The Token Bucket System

Cisco describes the regulation of a transfer rate as a token bucket system,
which is comprised of three parts:
• Committed Information Rate (CIR) – specifies the traffic rate
dictated by the SLA, measured in bits per second (bps).
• Burst Rate (Bc) – specifies the amount of traffic to be sent within a
given time interval, measured in bits.
• Time Interval (Tc) – identifies the time interval for each burst,
measured in seconds or sometimes milliseconds.
The CIR is calculated using the formula:
CIR (bps) = Bc (bits) / Tc (seconds)
With a token bucket system, the bucket is filled with tokens, and each token
represents one byte. Thus, to transmit a 50-byte packet, the bucket must
contain a minimum of 50 tokens. Tokens are consumed as traffic is
transferred, and the bucket is refilled with tokens at the speed of the CIR. If
the bucket is full, then excess tokens will spill out and are wasted. The
capacity of the bucket is defined by the burst rate.
If the data (in bytes) to be transmitted is less than the number of tokens
currently in the bucket, then the traffic is conforming to the policy and is
(usually) forwarded.
If the data (in bytes) to be transmitted is more than the number of tokens
currently in the bucket, then the traffic is exceeding the policy. This excess
traffic can be shaped (buffered) or policed (dropped or re-marked),
depending on the configured policy.
The above describes a One Token Bucket system. Some SLA policies
allow for bursts that are higher than the normal burst rate (Bc), during
periods of non-congestion. This is referred to as the excess burst (Be) rate.
The excess burst rate is an optional configuration option, and is defined as a
Two Token Bucket system. Excess tokens are not wasted, but are instead
placed in an excess bucket. The capacity of this bucket is defined by the
excess burst rate. Traffic that exceeds the normal token bucket can borrow
tokens from the excess bucket – but will usually be dropped first during
congestion. Traffic that exceeds the excess bucket is violating the policy.
(Reference: http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfpolsh.html)
***
Configuring Traffic Shaping

Shaping is usually implemented on the customer side, and will buffer
traffic that exceeds the provider’s committed rate. Shaping will thus slow the
traffic rate and siphon out traffic in compliance with the provider’s SLA.
Cisco IOS devices support multiple methods of traffic shaping:
• Generic Traffic Shaping (GTS) – implements shaping on a per-
interface basis using the traffic-shape command.
• Class-Based Shaping – implements shaping on a per-class basis
using the shape command within a MQC policy-map.
• Distributed Traffic Shaping (DTS) – offloads traffic shaping from
the router processor to Versatile Interface Processors (VIPs). DTS is
only available on high-end Cisco platforms.
• Frame Relay Traffic Shaping (FRTS) – implements Frame-Relay
specific shaping mechanisms, such as BECN or FECN. FRTS is only
available on a Frame-Relay interface or subinterface, and is covered
extensively in the Frame-Relay guide.
To configure basic Generic Traffic Shaping (GTS):
Router(config-if)# traffic-shape rate 256000 64000 64000
The traffic-shape rate command is followed by three values, representing:

• The committed information rate (CIR)
• The normal burst rate (Bc)
• The excess burst rate (Be)
If the normal burst (Bc) and excess burst (Be) values are equal, then excess
burst is not allowed. Specific traffic can be shaped using an access-list:
Router(config)# access-list 101 permit tcp any any eq 80
Router(config-if)# traffic-shape group 101 256000 64000 64000
Class-Based Shaping is accomplished within a policy-map:

Router(config)# policy-map MYPOLICY
Router(config-pmap)# class MYMAP
Router(config-pmap-c)# shape 256000 64000 64000
(Reference: http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfgts.html;
http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfcbshp.html)
***
Configuring Traffic Policing

Policing is usually implemented on the provider side, and will either drop
or re-mark traffic that exceeds the provider’s committed rate.
Traffic policing can be implemented directly on an interface using the rate-
limit command (part of the Committed Access Rate (CAR) IOS feature).
However, MQC policy-maps are the preferred method for policing traffic:
Router(config)# class-map MYMAP
Router(config-pmap-c)# police 256000 64000 128000 conform-action transmit
exceed-action set-dscp-transmit af13 violate-action drop
Router(config-if)# service-policy input MYPOLICY
The police command is followed by three values, representing in order:

• The committed information rate (CIR)
• The normal burst rate (Bc)
• The excess burst rate (Be) (optional)
The above three values are then followed by each condition, and its
corresponding action. The three conditions are as follows:
• conform-action – indicates traffic that is sent at less than the CIR.
• exceed-action – indicates traffic that exceeds the normal burst rate.
• violate-action – (optional) indicates traffic that exceeds the excess
burst rate.
The available policing actions for each condition include the following:
• transmit
• drop
• set-prec-transmit (sets the IP precedence value)
• set-dscp-transmit (sets the DSCP value)
• set-qos-transmit (sets the QoS group value)
To view traffic policing statistics:
Router# show policy-map interface
(Reference: http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfpoli.pdf)
***
Compression Overview
Compression increases the bandwidth available on a link, by reducing the
size of data. Compression algorithms shrink data by exploiting blank spaces
and repeating patterns within headers and payloads. Compression efficiency
depends on the algorithm used.
All forms of compression introduce latency on the devices performing the
compression or decompression. However, end-to-end latency is usually
reduced overall, as smaller packets result in shorter serialization delays.
Environments that are not experiencing congestion should not implement
compression, as it will add overhead with little or no benefit.
Compression can be controlled by either hardware or software. Hardware-
controlled compression is more efficient, as software-based compression
requires CPU interrupts, thus introduces more latency than hardware-based
compression.
There are three general categories of compression:
• Payload compression
• Link compression
• Header compression
Payload compression will compress the payload and all headers, except for
the Layer-2 header. It is enabled on a per-link basis, and is supported by
most serial technologies. Cisco devices support three algorithms for Layer-2
payload compression:
• Stacker
• Predictor
• Microsoft Point-to-Point Compression (MPPC)
Link compression will compress the payload and all headers, including the
Layer-2 header. This is only supported on point-to-point serial technologies
like PPP or HDLC. Multi-access technologies like Frame-Relay or ATM
require an uncompressed Layer-2 header to make forwarding decisions.
To enable compression on an interface:
Router(config-if)# compress predictor
(Reference: http://www.cisco.com/en/US/tech/tk713/tk802/technologies_tech_note09186a00801b3b86.shtml)
***
Header Compression
Header compression will not compress the payload, and thus is less
hardware intensive than payload compression. Instead, the Layer-3 and
Layer-4 headers of a packet will be compressed. This is most efficient for
traffic that has a small payload, such as VoIP. The ratio of header to payload
size is very large with such traffic, thus introducing considerable overhead.
The two most common types of header compression are as follows:
• TCP Header Compression
• RTP Header Compression (cRTP)
To enable outgoing TCP Header compression on an interface:
Router(config-if)# ip tcp header-compression
To enable outgoing TCP Header compression only if incoming TCP traffic

on that interface is also compressed:
Router(config-if)# ip tcp header-compression passive
RTP header compression (cRTP) compresses the RTP, UDP, and IP headers
of a packet. cRTP can reduce the collective header size from 40 bytes to 2
bytes.
Both TCP and RTP header compression can be configured directly on an
interface, or within a MQC policy-map for a specific class:
Router(config)# class-map VOICE
Router(config-cmap)# match protocol rtp audio

Router(config-pmap)# class VOICE
Router(config-pmap-c)# compression header ip rtp
Router(config-pmap-c)# compression header ip tcp

Router(config-if)# service-policy output MYPOLICY
(Reference: http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/fthdrcmp.html)
***
Link Fragmentation and Interleaving (LFI)

Link fragmentation and interleaving (LFI) prevents large packets from
causing excessive queuing and serialization delays for smaller packets, such
as VoIP packets. If a large packet is queued first, the smaller packet(s) must
wait until the large packet is serialized in its entirety.
Fragmentation and interleaving operate in conjunction with each other, and
provide no benefit if implemented separately. Large packets are fragmented,
or split into smaller packets, and assigned sequence numbers for reassembly
on the receiving end. This allows smaller packets, such as VoIP traffic, to be
interleaved within the fragmented larger packets. This reduces latency, as
the sensitive traffic is no longer forced to wait until the larger packets are
transmitted in their entirety.
LFI is supported on Multi-link PPP (MLP), Frame-Relay, and ATM links.
To configure LFI for Multi-link PPP:
Router(config-if)# multilink-group 1

Router(config)# interface Multilink1

Router(config-if)# ppp multilink interleave
Router(config-if)# ppp multilink fragment-delay 20
The ppp multilink interleave command enables LFI.

The ppp multilink fragment-delay command is used to specify the maximum
desired delay for traffic, measured in milliseconds. LFI will attempt to
fragment packets accordingly to meet this delay requirement.
(Reference: http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcflem.html)
***
QoS for VPNs (qos pre-classify)

Tunnels encapsulate the original IP headers with new headers. By default,
Cisco IOS devices will copy the ToS field from the original header into the
tunnel header. Thus, if QoS is applied based on ToS values, such as IP
Precedence or DSCP, no additional QoS configuration is required for
tunneled links.
If QoS is applied based on other parameters within the IP header, such as
port or address, then the Cisco QoS for VPNs feature is required. This
feature is supported for the following tunnel types:
• Generic Routing Encapsulation (GRE)
• IP in IP (IPIP)
• Layer 2 Tunneling Protocol (L2TP)
• Layer 2 Forwarding (L2F)
• Point to Point Tunneling Protocol (PPTP)
• Internet Protocol Security (IPSec)
The QoS for VPNs feature utilizes the qos pre-classify command. This
command forces the IOS to create a copy of the original IP packet, including
the original headers. QoS policies are then applied based on the headers of
the copied original packet, instead of the encapsulated (tunneled) packet.
The following describes how to apply the MQC service-policy command in
conjunction with qos pre-classify:
• Applying the service-policy to a tunnel interface without the qos pre-
classify command will classify based on the pre-tunnel header.
• Applying the service-policy to a physical interface with the qos pre-
classify command will classify based on the pre-tunnel header.
• Applying the service-policy to a physical interface without the qos
pre-classify command will classify based on the post-tunnel header.
Applying a service-policy to a physical interface will affect all tunnels off of
that interface.
(Reference: http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ftqosvpn.html;
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml)
***
Configuring QoS for VPNs (qos pre-classify)

For GRE tunnels, the qos pre-classify command is configured on the tunnel
interface:
Router(config)# interface tunnel1
Router(config-if)# qos pre-classify
For IPSec tunnels, the qos pre-classify command is configured on the crypto
map:
Router(config)# crypto map MYTUNNEL 10 ipsec-isakmp
Router(config-crypto-map)# set peer 172.16.5.1
Router(config-crypto-map)# set transform-set MYTRANSFORM
Router(config-crypto-map)# match ip address 101
Router(config-crypto-map)# qos pre-classify
If a GRE tunnel is being used with IPSec, the qos pre-classify command
must be configured on both the tunnel interface and the crypto map.
Control Plane Policing (CoPP)

Control Plane Policing (CoPP) is a mechanism to protect the control plane
of Cisco IOS switches and routers from Denial of Service (DoS) attacks. A
concerted stream of management traffic sent to a switch/router processor can
keep CPU utilization at 100%. This may result in slow response times,
missed routing updates, and queue saturation.
CoPP is managed using MQC. Instead of applying the service-policy to an
interface, it is applied to the control-plane, which is treated as its own entity.
Router(config)# class-map MYMAP

Router(config-pmap-c)# police 80000 conform transmit exceed drop
Router(config)# control-plane
Router(config-cp)# service-policy input MYPOLICY
(Reference: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html)
***
AutoQoS v1.01 – Aaron Balchunas 1
- AutoQoS -
AutoQoS
AutoQoS is a Cisco feature that was originally developed to automate QoS
deployment for VoIP. Subsequently, Cisco released an updated version
called AutoQoS Enterprise, which added support for video and other data
types. AutoQoS Enterprise is only supported on Cisco routers, not switches.
Deploying AutoQoS Enterprise requires two steps:
• Using NBAR to automatically discover and classify traffic types.
• Generating and implementing QoS policies.
AutoQoS’s generated configuration can be modified using the Modular QoS
CLI (MQC). Note that the original AutoQoS did not support a discovery
phase, and only supported the automatic generation of MQC policies.
AutoQoS Enterprise can be enabled on the following interface types:
• Serial interfaces, with PPP or HDLC encapsulation.
• Frame-Relay point-to-point subinterfaces.
• ATM point-to-point subinterfaces.
• Frame Relay-to-ATM links.
AutoQoS Enterprise can enable the following features on router interfaces:
• Low Latency Queuing (LLQ)
• RTP header compression (cRTP)
• Link fragmentation and interleaving (LFI)
AutoQoS can also enable monitoring and reporting using of SNMP traps, via
an SNMP community of AutoQoS.
AutoQoS Enterprise has specific requirements and restrictions:
• CEF must be enabled on each interface where AutoQoS is
implemented, as NBAR is dependent on CEF.
• A QoS service-policy cannot already be applied to the interface.
• A map-class cannot already be applied for a Frame Relay DLCI.
• An accurate bandwidth command must be enabled on interfaces and
sub-interfaces.
• Slow interfaces (768kbps or less) must be configured with an IP
address.
(Reference: http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/autoqos_enterprise.pdf)
***
Configuring AutoQoS
To enable AutoQoS Enterprise discovery on a specific interface:
Router(config-if)# auto discovery qos
AutoQoS discovery provides more accurate traffic statistics and

classification the longer it is permitted to run on an interface. By default,
discovery will run for three days.
To allow the AutoQoS discovery process to utilize or trust QoS markings
already present in traffic:
Router(config-if)# auto discovery qos trust
Once the discovery process has finished, AutoQoS Enterprise can generate
MQC policies, based on the gathered traffic statistics:
Router(config)# interface Serial0/0
Router(config-if)# auto qos
As described above, the generated policies can be configured to trust QoS

markings already present in traffic:
Router(config)# interface Serial0/0
Router(config-if)# auto qos trust
Cisco Catalyst switches do not support AutoQoS Enterprise, only the

original AutoQoS VoIP implementation:
Switch(config)# interface FastEthernet0/0
Switch(config-if)# auto qos voip
If a Cisco VoIP phone is connected to a switch interface, the switch can be

configured to trust the QoS markings from the VoIP phone:
Switch(config)# interface FastEthernet0/0
Switch(config-if)# auto qos voip cisco-phone
This requires that CDPv2 is enabled between the switch and the phone.
(Reference: http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/autoqos_enterprise.pdf)
***
Troubleshooting AutoQoS
AutoQoS’s generated configuration can be modified using the Modular QoS
CLI (MQC). This can become necessary if AutoQoS generated too many
traffic classes, or if the policies do not fit the business requirements.
Also, AutoQoS does not dynamically adapt to changing network conditions.
Changes to the network environment may require manual changes to the
generated policy. Otherwise, AutoQoS must be disabled, and the discovery
process and policy generation must be completed again in its entirety.
The show auto discovery qos command will display statistics on all
discovered traffic types. It will additionally display the suggested QoS
policy, based on the statistics gathered up to that point:
Router# show auto discovery qos
Serial0/0
AutoQoS Discovery enabled for applications
Discovery up time: 12 hours, 42 minutes
AutoQoS Class information:
Class Voice
Recommended Minimum Bandwidth40 Kbps/31% (PeakRate)
Detected applications and data:
Application/ AverageRate PeakRate Total
Protocol (kbps/%) (kbps/%) (bytes)
----------- ----------- -------- -----------
rtp audio 14/<1 199/12 124563
Class Interactive Video
No data found.
<remaining output snipped for brevity>
Once a policy has been generated, the show auto qos command will display
the AutoQoS-generated class-maps, policy-maps, access-lists, SNMP traps,
and interface configurations:
Router# show auto qos
policy-map AutoQoS-Policy-Se0/0
class AutoQoS-Voice-Se0/0
priority percent 50
set dscp ef
!
class-map match-any AutoQoS-Voice-Se0/0
match protocol rtp audio
<remaining output snipped for brevity>
***

Networking Extras PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Networking Extras PDF

Transféré par

Droits d'auteur :

Formats disponibles

Basic WAN Concepts v1.

- Basic WAN Concepts -

Consider the following example.

A connection between the

Remember, the difference is the

WAN Connection Types

Common WAN Terms

- Network Address Translation -

NAT Terminology Example

10.1.1.1 55.1.1.1 99.1.1.1 192.168.1.1

SRC Address = 10.1.1.10 SRC Address = 55.1.1.1:31092 SRC Address = 55.1.1.1:31092

Configuring Static NAT

To statically map a public address to a private address, the syntax is as

This command performs a static translation of the source address 172.16.1.1

Configuring Dynamic NAT

Next, a pool of global addresses must be specified. Inside hosts will

Configuring NAT Overload (or PAT)

To view whether an interface is configure as an inside or outside NAT

To view NAT translations in real-time:

To clear all dynamic NAT entries from the translation table:

PPP supports several features that standalone HDLC does not:

Configuring Basic PPP

To view the encapsulation configured on the interface:

To troubleshoot PPP authentication between two routers:

More advanced PPP configuration is discussed in the ISDN guide.

- Integrated Services Digital Network -

ISDN BRI Fundamentals

A TE2 (Terminal Endpoint 2) identifies a non-ISDN native device

ISDN BRI Layers

ISDN employees three layers to its communication process.

Configuring Basic ISDN BRI

Other basic configuration is completed on the BRI interface:

PPP is the most common encapsulation for ISDN.

ISDN Dial-on-Demand Routing (DDR)

The dialer-list command is specifying that all IP traffic is interesting, and

Misc. ISDN Commands

To dictate a delay period before activating or deactivating the second B

To enable PPP compression on an ISDN BRI interface:

To configure the Callback client:

ISDN Backup Methods (Backup Interface)

ISDN Backup Methods (Dialer Watch)

ISDN and Routing Protocols

Configuring Dialer Interfaces

Example of a rotary-group configuration:

To disconnect this test call:

Frame-Relay is a packet-switched technology, which shares bandwidth

Frame-Relay Global vs Local DLCI

The difference between a globally or locally significant DLCI is all based on

Frame-Relay Encapsulation Types

Frame-Relay Local Management Interface (LMI)

Frame-Relay Point-to-Point Configuration Example

Point-to-Point is the simplest form of Frame-Relay configuration.

Router(config)# int s0/0 Router(config)# int s0/0

Notice that both routers are in the same IP subnet.

Frame-Relay Point-to-Point Configuration Example (continued)

Detroit Router: Chicago Router:

Router(config)# int s0/0 Router(config)# int s0/0

The frame-relay interface-dlci command identifies the one-way PVC. The

Frame-Relay Full Mesh Configuration Example

Detroit Router: Chicago Router:

Router(config)# int s0/0 Router(config)# int s0/0

Inverse-ARP was disabled using the no frame-relay inverse-arp command.

Frame-Relay Partial Mesh Configuration Example