End-to-End DSL Architectures

This chapter is from the book

End-to-End DSL Architectures

Learn More Buy

This chapter is from the book

This chapter is from the book 

End-to-End DSL Architectures

Learn More Buy

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-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.

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 192.168.2.1 255.255.255.0
   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 10.0.0.0 and 172.17.0.0. The Enhanced IGRP autonomous system number is assigned as 100:

Config#router eigrp 100
Config-router#network 10.0.0.0
Config-router#network 172.17.0.0

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:192.168.2.8
!
  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
!
bundle-enable
!
dial-peer voice 1 pots
   destination-pattern 1001
   port 1

dial-peer voice 10 voip
   destination-pattern 2...
!
   session target ipv4:192.168.2.8
!
   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 192.168.1.2 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

gateway

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 192.168.1.2 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-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 
bundle-enable
 bridge-group 1
 hold-queue 224 in
!
interface BVI1
   ip address 172.16.0.1 255.255.0.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 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:172.16.0.3
!

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 192.168.2.1 255.255.255.0

   pvc 1/35
     protocol ip 192.168.2.2 broadcast


     vbr-rt 424 424 5
     encapsulation aal5snap
!

interface ATM0.2 point-to-point


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

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


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


session target ipv4:192.168.2.8

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 192.168.2.1, with a subnet mask of 255.255.255.0.

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