Home > Articles > Cisco Network Technology > General Networking > End-to-End DSL Architectures

End-to-End DSL Architectures

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Apr 4, 2003.


  1. Cisco 827 DSL Configurations
  2. Cisco 827 Configurations for Voice Service
  3. Central Office/Exchange Equipment
  4. Summary
  5. Review Questions

Chapter Description

Explore the configurations of the four basic TCP/IP architectures for DSL, including three architectures based on RFC 2684, Routed Bridge Encapsulation (RBE), and Point-to-Point Protocol over ATM (PPPoA). You will go through configurations for the Cisco 827 CPE router, the Cisco 6000 series of IP/DSL Switches, and the Cisco 6400 Universal Access Concentrator (UAC).

Cisco 827 Configurations for Voice Service

Figure 6-3 shows a theoretical network with VoIP configured on the 827-4V. The voice capability of the 827-4V starts with the same configurations as for the 827 without voice ports.

Figure 6-3Figure 6-3 Cisco 827-4V with Basic VoIP

As discussed earlier, setting up voice on the router actually includes two configurations—one for data and one for voice. This section leads you through the data configurations first and then the voice configurations. These consist of the following steps:

Step 1 Configure the data network:

  • Configure the class map, route map (optional), and policy map

  • Configure the Ethernet interface

  • Configure the ATM interface

  • Configure Enhanced IGRP

Step 2 Configure the voice network:

  • Configure the POTS (plain old telephone service, or basic telephone service) dial peers

  • Configure VoIP dial peers for H.323 signaling

The following sections discuss the details of each of these steps.

Configuring the Data Network

The data network depends on a specific traffic classification policy that allocates bandwidth and interface access by priority according to traffic type. Traffic types include digitized voice service, standard IP-type packets, and various traffic types whose priorities fall between high-priority voice traffic and standard-priority routine data traffic. Defining the traffic policy determines how many types of packets (number of classes) are to be differentiated from one another. Packets are matched to each other, forming classes based on protocols, access control lists, and input interfaces. These three are the usual match criteria. Before starting the configurations themselves, you must understand the class options.

To characterize a class, you can specify the queue limit for that class, which is the maximum number of packets allowed to accumulate in the class's queue. Packets belonging to a class are subject to the bandwidth and queue limits that characterize the class.

Queuing Considerations

After a queue has reached its configured queue limit, enqueuing additional packets to the traffic class causes either tail drop or weighted random early detection (WRED) drop to take effect, depending on how the service policy is configured.


Tail drop is a means of avoiding congestion that treats all traffic equally and does not differentiate between classes of service. Queues fill during periods of congestion. When the output queue is full and tail drop is in effect, packets are dropped until the congestion is eliminated and the queue is no longer full.

WRED drops packets selectively based on IP precedence. Packets with a higher IP precedence are less likely to be dropped than packets with a lower precedence. Thus, higher-priority traffic is delivered with a higher probability than lower-priority traffic in the default scenario. However, packets with a lower IP precedence are less likely to be dropped than packets with a higher IP precedence in certain WRED configurations.

Flow classification is standard weighted fair queuing (WFQ) treatment. That is, packets with the same source IP address, destination IP address, source TCP or User Datagram Protocol (UDP) port, or destination TCP or UDP port are classified as belonging to the same flow. WFQ allocates an equal share of bandwidth to each flow. Flow-based WFQ is also called fair queuing because all flows are equally weighted. WFQ can speed up handling for high-precedence traffic at congestion points.

There are two levels of queuing: ATM queues and IOS queues. Class-based weighted fair queuing (CBWFQ) is applied to IOS queues. It extends the standard WFQ functionality in support of user-defined traffic classes. For CBWFQ, you define traffic classes based on match criteria including protocols, access control lists (ACLs), and input interfaces. Packets satisfying the match criteria for a class constitute the traffic for that class.

Each class has a weight derived from the bandwidth you assigned to the class when you configured it. The weight specified for the class becomes the weight of each packet that meets the class's match criteria. Packets that arrive at the output interface are classified according to the match criteria filters you define, and then each one is assigned the appropriate weight.

After a packet's weight is assigned, the packet is enqueued in the appropriate class queue. CBWFQ uses the weights assigned to the queued packets to ensure that the class queue is serviced fairly.

Tail drop is used for CBWFQ traffic classes unless you explicitly configure a service policy to use WRED to drop packets as a means of avoiding congestion. Note that if you use WRED packet drop instead of tail drop for one or more traffic classes making up a service policy, you must ensure that WRED is not configured for the interface to which you attach that service policy.

If a default class is configured, all unclassified traffic is treated as belonging to the default class. If no default class is configured, by default the traffic that does not match any of the configured classes is flow-classified and given best-effort treatment. As soon as a packet is classified, all the standard mechanisms that can be used to differentiate service among the classes apply.

A first-in, first-out (FIFO) IOS queue is automatically created when a PVC is created. If you use CBWFQ to create classes and attach them to a PVC, a queue is created for each class.

CBWFQ ensures that queues have sufficient bandwidth and that traffic gets predictable service. Low-volume traffic streams are preferred; high-volume traffic streams share the remaining capacity, obtaining equal or proportional bandwidth. Bandwidth for the policy map may not exceed 75 percent of the total PVC bandwidth.

Resource Reservation Protocol (RSVP) can be used in conjunction with CBWFQ. When both RSVP and CBWFQ are configured for an interface, RSVP and CBWFQ act independently, exhibiting the same behavior that they would if each were running alone. RSVP continues to work as it does when CBWFQ is not present, even in regard to bandwidth availability assessment and allocation.

RSVP works well on PPP, HDLC, and similar serial-line interfaces. It does not work well on multiaccess LANs. RSVP can be equated to a dynamic access list for packet flows. You should configure RSVP to ensure QoS if the following conditions describe your network:

  • Small-scale voice network implementation

  • Links slower than 2 Mbps

  • Links with high utilization

  • You need the best possible voice quality

Configuring the Traffic Policy: Traffic Precedence, Class Maps, Policy Maps

After considering the queuing and prioritization techniques explained previously, you can begin designing the traffic policy configuration for the Cisco 827. Starting with the classification of traffic types, there are two principal aspects to configuring the traffic policy:

  • Class maps, which define the traffic classes

  • Policy maps, which associate the policies (traffic classes) with interfaces

Traffic Precedence

The first step in building the class map is to configure the access list, including setting an IP precedence, to associate with the class map. As per RFC 791, there are eight classes of service, although later RFCs provide more independence in proprietary precedence definitions. Cisco Systems endeavors to conform to RFC 791, meaning that you can partition traffic in up to six classes of service using IP precedence; two others are reserved for internal network use. The network queuing technologies then use this IP precedence definition to expedite traffic handling. The original, RFC 791-defined classes are as follows, in order from lowest priority to highest priority:

  • Traffic class (TC) = 0: Routine (uncharacterized traffic)—If otherwise undefined, these packets are assigned the lowest-priority value and are delivered based on the available bandwidth. Non-TCP/IP traffic is assigned to this traffic class. There is a very high possibility of packet drop in the event of congestion.

  • TC = 1: Priority—There is a high possibility of packet drop if congestion is encountered.

  • TC = 2: Immediate—There is a medium possibility of packet drop in the event of congestion.

  • TC = 3: Flash—There is a low possibility of packet drop in the event of congestion.

  • TC = 4: Flash-override—There is a very low possibility of packet drop compared to the lower-priority classes.

  • TC = 5: Critical—Cisco recommends this class for voice traffic.

  • TCs 6 and 7—For Internet and network traffic, respectively. Examples include signaling protocols.

IP precedence is not a queuing method, but it gives other queuing methods (WFQ, WRED) the capability to prioritize based on the packet's IP precedence. The network gives priority (or some type of expedited handling) to the marked traffic through the application of WFQ or WRED at points downstream in the network.

The mapping from keywords such as routine and priority to a precedence value is useful in only some instances. In other words, the use of the precedence bit is evolving. Bear in mind that IP precedences can be used to establish classes of service that do not necessarily correspond numerically to better or worse handling in the network.

The ip precedence command is used by the Cisco 827 router to differentiate voice traffic from data traffic and to assign voice packets a higher priority. Here is an example of this command applied on a Cisco 827 DSL router for voice service:

Router (config)#access-list 101 permit ip any any precedence 5

This command builds an extended access list numbered 101, which permits IP traffic from any source to any destination and then assigns this permitted traffic the IP precedence of 5 for voice packets. You can also use the plain-text priority designations themselves rather than the numbers:

Router (config)#access-list 101 permit ip any any precedence critical

Features such as policy-based routing and committed access rate (CAR) can be used to set precedence based on extended access lists.

Class Maps

The next step in building the voice configuration on the 827 is to configure the class map called voice. The command class-map voice defines a traffic class and the match criteria that are used to identify traffic as belonging to that class. match statements can include criteria such as an ACL, an IP precedence value, or a Differentiated Services Code Point (DSCP) value.

The DSCP is a designation by the Internet Engineering Task Force (IETF) of the 6 most significant bits of the 1-byte IP Type of Service (ToS) field. The match criteria are defined with one match statement entered in class-map configuration mode.

Here is an example of what might be in the class-map VOICE definition:

Router(config)#class-map VOICE
Router(config-cmap)#match ip rtp 16384 16383
Router(config-cmap)#match access-group 101

In the first command, IP Real-Time Protocol (RTP) ports 16384 and 16383 (possible values through 32767) are configured as the match criteria. In the second command, access list 101 is matched with the class map. That is, the class map is now associated with IP packets whose IP precedence is 5, the recommended voice packet precedence you defined earlier with the command access-list 101 permit ip any any precedence 5.

Policy Maps

Policy maps group one or more class maps, up to 64 different classes of service, for later association with a particular interface. The policy map thereby confers all its referenced class map values onto the interface. In the commands discussed in the preceding section, you first defined an access list and assigned permitted traffic the priority of 5. Then you referenced that access list, 101, in defining the class map called VOICE. The class map is also related to traffic only on ports 16383 and 16384. Because that is a relatively narrow definition, the policy map should also contain a class for other types of traffic, although this is more of a security consideration than a voice configuration consideration.

The commands in the following listing define the policy map named MYPOLICY, which associates the class maps VOICE and class-default (the default for unreferenced traffic). As an example of one option, the command Priority 176 guarantees 176 kbps of bandwidth for the priority traffic. Beyond the guaranteed bandwidth, the priority traffic is dropped in the event of congestion to ensure that the nonpriority traffic is not starved. Another option is to define the guaranteed bandwidth as a percentage of the overall interface bandwidth. A third option is to specify a maximum burst size in bytes to be tolerated before dropping traffic.

Policy-map MYPOLICY
   Class VOICE
     Priority 176
   Class class-default

You have finished configuring the class map and policy map, the first steps in configuring the data network, leading to final voice service configuration. Now you will adjust the interface configurations. You learned earlier about configuring the Ethernet interface for the TCP/IP architectures common to DSL. The ATM interface has some details beyond those earlier, basic ATM interface commands for the Cisco 827. These new ATM configuration commands provide for voice service and draw on the concepts already explained in this chapter, as well as some more specific details.

ATM Interface Configuration

The next step is to configure the ATM interface. Here are the commands to do so:

interface ATM0
   mtu 300
   ip address
   no atm ilmi-keepalive
   pvc 1/32
     service-policy out MYPOLICY
     vbr-rt 640 640 10
     encapsulation aal5snap

The first step in configuring the ATM interface is to adjust the size of the MTU. If you are configuring PPP, either PPPoA or PPPoE, you should decrease the ATM interface's MTU size so that large data packets are fragmented. It is recommended that you use 300 for the MTU size because it is larger than the size of the voice packets generated by the different codecs.

With multiclass multilink PPP interleaving, large packets can be multilink-encapsulated and fragmented into smaller packets to satisfy the delay requirements of real-time voice traffic. Small real-time packets, which are not multilink-encapsulated, are transmitted between fragments of the large packets. The interleaving feature also provides a special transmit queue for the smaller, delay-sensitive packets, enabling them to be transmitted earlier than other flows. Interleaving provides the delay bounds for delay-sensitive voice packets on a slow link that is used for other best-effort traffic.

Next, the policy map named MYPOLICY that you created earlier is associated with the PVC in the outbound direction.

You can then specify the PVC's service class. In this case, the command vbr-rt 640 640 10 defines Variable Bit Rate Real Time with a peak cell rate (PCR) of 640 kbps, a sustained cell rate (SCR) of 640 kbps, and a Maximum Burst Rate (MBR) of ten cells in a single burst. You should configure the SCR to be at least four times the particular codec's bandwidth when the four voice ports are used. For example, if you have a 640 kbps upstream PVC running codec G.729, you could configure the PVC with an SCR of 176.

Finally in configuring the ATM interface, this PVC is assigned the encapsulation of aal5snap.

Enhanced IGRP Configuration

Continuing with configuring the data aspects of the Cisco 827, you should enter router configuration mode and enable Enhanced IGRP. The autonomous-system number identifies the route to other Enhanced IGRP routers and is used to tag the Enhanced IGRP information.

Specify the network number for each directly connected network.

The following configuration shows the Enhanced IGRP routing protocol enabled in IP networks and The Enhanced IGRP autonomous system number is assigned as 100:

Config#router eigrp 100

You can now proceed to the voice-specific configurations.

Voice Network Configuration

Following is the voice-specific configuration:

!(lines omitted)
voice-port 1
   timing hookflash-in 0
voice-port 2
   timing hookflash-in 0
voice-port 3
   timing hookflash-in 0
voice-port 4
   timing hookflash-in 0
!(lines omitted)
scheduler max-task-time 5000

dial-peer voice 1 pots
  destination-pattern 1001
  port 1
dial-peer voice 10 voip
  destination-pattern 2...
  session target ipv4:
  codec g711ulaw (optional)

The commands voice-port X and timing hookflash-in 0 turn off any hookflash indications that the gateway could generate on an FXO interface. Currently the Cisco 827-4V does not support hookflash indications, although that support is probably pending, because it is already available on other Cisco platforms with H.323 Version 2 Phase 2. On an analog phone, hookflash means pressing the switchhook for a moment (about one-half second) to produce a special stutter dial tone. This engages supplemental services, such as call waiting.

The command scheduler max-task-time 5000 is not specific to the 827. It is how long, in milliseconds, a specific process is handled by the CPU before it reports debugging information—in this case, 5 seconds.

Dial Peer Configuration

Dial peers enable outgoing calls from a particular telephony device. All the voice technologies use dial peers to define the characteristics associated with a call leg. A call leg is a discrete segment of a call connection that lies between two points in the connection.

Bear in mind that these terms are defined from the router perspective. An inbound call leg means that an incoming call comes to the router. An outbound call leg means that an outgoing call is placed from the router.

Two kinds of dial peers can be configured for each voice port: POTS and VoIP:

  • POTS associates a physical voice port with a local telephone device. The destination-pattern command defines the telephone number associated with the POTS dial peer. The port command associates the POTS dial peer with a specific logical dial interface, normally the voice port connecting the 827-4V to the POTS network. You can expand an extension number into a particular destination pattern with the command num-exp. You can use the show num-exp command to verify that you have mapped the telephone numbers correctly.

  • The VoIP dial peer also associates a telephone number with an IP address. The key configuration commands are the same destination-pattern and session target commands that are used with the POTS dial peer. The former command is the same as with the POTS dial peer, defining a telephone number. The session target command specifies a destination IP address for the VoIP dial peer. This command must be used in conjunction with the destination-pattern command. Going further than the POTS dial peer, you can use VoIP dial peers to define characteristics such as IP precedence, QoS parameters, and codecs. For instance, you can optionally specify a different codec than the default codec of g.729.

For both POTS and VoIP, after you have configured dial peers and assigned destination patterns to them, you can use the show dialplan number command to see how a telephone number maps to a dial peer.

When a router receives a voice call, it selects an outbound dial peer by comparing the called number (the full E.164 telephone number) in the call information with the number configured as the destination pattern for the POTS peer. The router then strips the left-justified numbers corresponding to the destination pattern matching the called number. On POTS dial peers, the only digits that are sent to the other end are the ones specified with the wildcard character (.) with the command destination-pattern string. The POTS dial peer command prefix string can be used to include a dial-out prefix that the system enters automatically instead of having people dial it. If you have configured a prefix, it is put in front of the remaining numbers, creating a dial string, which the router then dials. If all the numbers in the destination pattern are stripped, the user receives (depending on the attached equipment) a dial tone.

For example, suppose there is a voice call whose E.164 called number is 1 (310) 555-2222. If you configure a destination pattern of 1310555 and a prefix of 9, the router strips 1310555 from the E.164 telephone number, leaving the extension number of 2222. It then appends the prefix 9 to the front of the remaining numbers so that the actual numbers dialed are 9, 2222. The comma in this example means that the router pauses for 1 second between dialing the 9 and dialing the first 2 to allow for a secondary dial tone.

Earlier, you defined a class called VOICE with the class-map command. You matched the access control list 101 with this class of service using the match access-group command. You also defined a policy map with the policy-map command. Those commands are shown here, along with some new options:

class-map VOICE
   match access-group 101
policy-map POLICY
   class VOICE
      priority 480

pvc 1/32
     service-policy out POLICY
     vbr-rt 640 640 10
     encapsulation aal5snap
dial-peer voice 1 pots
   destination-pattern 1001
   port 1

dial-peer voice 10 voip
   destination-pattern 2...
   session target ipv4:
   ip precedence 5
access-list 101 permit ip any any precedence critical

The command priority 480 defines the priority of the VOICE class in terms of guaranteed bandwidth. In this case, if there is congestion on the network, even this priority traffic is dropped when it exceeds 480 kbps. This ensures that the nonpriority traffic is not starved.

The command service-policy out POLICY attaches the policy map to this particular PVC, 1/32. The policy map could also be attached to an interface, either inbound or outbound.

The command vbr-rt 640 640 10 defines Variable Bit Rate Real Time (suitable for this voice traffic) with a PCR of 640 kbps, an SCR of 640 kbps, and an MBR of ten cells in a single burst.

This PVC's encapsulation type is aal5snap, suitable for either RFC 2684 bridging (IRB or RBE) or PPPoE.

The command bundle-enable creates ATM PVC bundles, about which you learned earlier. The command dial-peer voice 1 voip simply uses one of two options; this was explained earlier as well.

Two values at a minimum are required to configure a VoIP peer: the associated destination telephone number and a destination IP address. The command destination-pattern defines the destination telephone number. This specification is then associated with port 1. In this configuration example, the last digits in the VoIP dial peer's destination pattern are replaced with wildcards.

The ip precedence command defines precedence 5, preferred for voice.

Last, the access-list command clears the way through access list 101 for any IP traffic and sets that traffic's precedence as critical.

Returning to check the steps in configuring the 827-4V for data and voice, you are now ready for the last step, which completes the process by configuring the VoIP dial peers for H.323 signaling.

VoIP Dial Peers for H.323 Signaling

The H.323 signaling protocol was explained in Chapter 4, "Cisco DSL Products." Following is the configuration:

interface ATM0
   h323-gateway voip interface

h323-gateway voip id GATEKEEPER ipaddr 1719

h323-gateway voip h323-id GATEWAY
!(lines omitted: define telephone number, specify port number)
dial-peer voice 10 voip
 destination-pattern +.T
session target ras


The first H.323-related command in this configuration, h323-gateway voip interface, identifies the interface ATM0 as the gateway interface.

The command h323-gateway voip id GATEKEEPER ipaddr 1719 defines the name and location (IP address) of the gatekeeper for this gateway.

The next command, h323-gateway voip h323-id GATEWAY, defines the gateway's H.323 name, identifying this gateway to its associated gatekeeper.

The command destination-pattern +.T introduces a new value. The plus sign (+) indicates an E.164 standard number, and the T indicates the default route.

The command session target ras specifies the destination as having Registration, Admission, and Status (RAS) functionality, providing gateway-to-gatekeeper functionality.

Finally, the one-word command gateway defines this 827-4V as the H.323 gateway device.

Completing the 827-4V Configuration

You can now complete the configuration of the Cisco 827-4V. Figure 6-4 shows the use of the Cisco 827-4V configured for RFC 2684 bridging (IRB) and VoIP.

Figure 6-4Figure 6-4 Cisco 827-4V Using IRB for VoIP

When the Cisco 827 replaces existing bridged DSL modems, the IRB configuration is a typical starting point. Although the Cisco 827-4V supports voice service in all the other previously discussed architectures in which the network scheme would be different, IRB is shown here simply as an example. The new commands are explained after the configuration listing.

Here is the configuration required for the 827-4V in this legacy replacement scenario:

version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
hostname R1
bridge irb
interface Ethernet0
no ip mroute-cache
interface ATM0
no ip address
no atm ilmi-keepalive
   pvc 1/150
     encapsulation aal5snap 
 bridge-group 1
 hold-queue 224 in
interface BVI1
   ip address
ip classless
ip route BVI1
no ip http server
bridge 1 protocol ieee
   bridge 1 route ip

voice-port 1
   timing hookflash-in 0
voice-port 2
   timing hookflash-in 0
voice-port 3
   timing hookflash-in 0
voice-port 4
   timing hookflash-in 0
dial-peer voice 1 pots
   destination-pattern 2222
   port 1
dial-peer voice 2 voip
   destination-pattern 1111
   session target ipv4:

The command bridge irb enables RFC 2684 bridging (IRB) for the whole Cisco 827-4V router.

The command ip mroute-cache configures IP multicast fast switching. In this Cisco 827-4V, it is disabled on the Ethernet interface. When packets arrive on this Ethernet interface for a multicast routing table entry with mroute caching disabled, those packets are sent at process level for all interfaces in the outgoing interface list.

When packets leave via this Ethernet interface for a multicast routing table entry, the packet is process level-switched for this interface, but it may be fast-switched for other interfaces in the outgoing interface list.

The command bridge-group 1 specifies the bridge group to which the interface belongs.

The command BVI1 creates a BVI and assigns a corresponding bridge group number to that BVI, as discussed earlier in this chapter.

The command bridge 1 protocol ieee is an IOS standard specifying Spanning Tree Protocol for bridge group 1.

The command bridge 1 route ip lets the BVI accept and route routable packets received from its corresponding bridge group. You must enter this command for each routed protocol (such as IPX) that you want the BVI to route from its corresponding bridge group to other routed interfaces.

You are now done configuring the Cisco 827-4V for IRB and VoIP. Look again at Figure 6-3 and consider the more-complex explanation of the use of your new, complete configuration. This figure shows a voice scenario configuration using the Cisco 827-4V router in an H.323 signaling environment. Traffic is routed through the 827 router and then is switched onto the ATM interface. The 827 router is connected through the ATM interface through one PVC, and it is associated with a QoS policy called mypolicy. Data traffic coming from the Ethernet must have an IP precedence below 5 (critical) to distinguish it from voice traffic.

NAT (represented by the dashed line at the edge of the 827 routers) signifies two addressing domains and the inside source address. The source list defines how the packet travels through the network.

Now that you have configured the 827-4V as a voice-carrying router, you need to configure the PVC endpoint. An interesting option is to use multiple PVCs. Multiple PVCs, separating voice and data, create an easily expandable, easily traced configuration, although this is not required for minimal functionality. Here is that configuration:

!(lines omitted)

interface ATM0.1 point-to-point
   ip address

   pvc 1/35
     protocol ip broadcast

     vbr-rt 424 424 5
     encapsulation aal5snap

interface ATM0.2 point-to-point

   pvc 1/36 (data PVC)
        protocol ip broadcast
        encapsulation aal5snap

dial-peer voice 1 pots
destination-pattern 1001
port 1

dial-peer voice 10 voip
destination-pattern 2...

session target ipv4:

In this configuration, the first PVC is for voice service. It is configured on a point-to-point subinterface, ATM0.1. This IP PVC has a point-to-point IP address of, with a subnet mask of

Then the service class of Variable Bit Rate (VBR) is set, with parameters of PCR of 424 kbps, SCR of 424 kbps, and MBR of five cells in a single burst. This voice PVC's encapsulation is aal5snap.encapsulation aal5snap.

Troubleshooting the Cisco 827

The first thing you should do when troubleshooting the Cisco 827 is check the front panel CD LED. If the light is not on, no ADSL carrier is detected. Usually this is a physical problem, probably due to a bad cable or a problem with an ADSL line or WAN service. You can try replacing the cable, but you will probably have to contact the DSL provider.

Another simple solution to 827 problems might lie with the ATM interface. To verify its status, you can enter the command show interface ATM 0. If the status is up/down, the Cisco 827 sees the ADSL carrier but cannot train up with the central office (CO)/exchange IP-DSL Switch properly. In this case, check the cable itself. The Cisco 827 uses pins 3 and 4 of the ADSL cable. The ADSL cable must be 10BASE-T Category 5 unshielded twisted-pair (UTP) cable. Using regular telephone cable can introduce line errors. Contact your ADSL line or service provider to determine if there is a problem.

If the Cisco 827 does not establish a satisfactory DSL circuit to the CO/exchange ADSL port, you can observe the process of DSL synchronization as the 827 trains up to help isolate the problem. Following are the normal stages of the synchronization so that you can verify which steps are occurring correctly to aid your troubleshooting. To observe the training process, you can enter the command debug atm events and observe the outputs, shown in the following:

Normal activation state changes are

STOP In shutdown state

INIT Initialization

DLOAD_1 Initialized and downloading first image

DLOAD_2 Downloading second image

DO_OPEN Requesting activation with CO

In DO_OPEN state, look for the modem state for the progress information:

Modem state = 0x0 Modem down

Modem state = 0x8 Modem waiting to hear from CO

Modem state = 0x10 Modem heard from CO and now is training

Modem state = 0x20 Activation completed and link is up

SHOWTIME Activation succeeded

3. Central Office/Exchange Equipment | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020