Remote Access with Digital Subscriber Line Summary and Exam Essentials

Summary
In this blog, you learned that digital subscriber line (DSL) technology was developed to add
functionality to the large existing copper cable plant installed for the analog phone system. The
service is built around ATM technology and provides a wide variety of flavors to offer different
data rates and service distances. DSL variants range in bandwidth from 144Kbps to over 50Mbps.
Unlike other WAN technologies, many DSL flavors are asymmetric; that is, they provide different
bandwidths in upstream and downstream directions.
We described the configuration and troubleshooting elements of DSL, while noting that from
the transport point-of-view, DSL is examined the same as ATM. We also noted that DSL sometimes
uses complex bridging and routing solutions to simplify larger deployments. DSL is a consumer
service in many installations, and with over 28 million installations (as of late 2003),
simple, repeatable deployments are crucial. To that end, we described the primary feature of
G.lite, or splitterless DSL.
Exam Essentials
Understand how DSL can fit into your remote access solutions. DSL is well suited to
remote workers and small branch offices for remote connectivity. It offers many of the same
bandwidths as T-1 at lower prices, and, in some cases, its asymmetric offerings are perfect
for high-demand users.
Know the differences in the various flavors of DSL. The DSL service offerings are best
considered in terms of bandwidth and analog voice support. G.lite is a splitterless offering
that provides for analog voice without a splitter in the line. HDSL and SDSL provide symmetric
bandwidth.
Be able to compare DSL to other remote access technologies. HDSL and SDSL both provide
bandwidths comparable to T-1 services. This can be very important for the administrator—for
example, T-1 might not be available but HDSL is, and, ironically, HDSL might be cheaper.
Other xDSL services can be replacements for Frame Relay or other access methods.
Understand the configuration of DSL services. The key to configuring DSL services is to
understand their relationship to ATM in the networking model. DSL commonly uses the same
PVC configuration and other logical constructs.

Troubleshooting DSL

DSL is an ATM technology at its core, so troubleshooting DSL connections requires an understanding
of ATM in addition to generic troubleshooting. Generic troubleshooting includes
examination of the various layers, including physical connectivity, data-link connectivity, and
protocol configuration.
In the following example, the DSL interface has received 1,714 frames with CRC errors,
while the interface itself has reset three times. The IP address is confirmed to be correct, and the
load does not appear to be problematic. Although the problem could be the ATM PVC configuration
under different circumstances, in this case there is likely a line problem or an issue with
the physical interface at the transmission end. Remember that ATM is a cell-based technology,
and although beyond our scope here, each cell is 53 bytes long. Of this, with ATM adaptation
layer 5, 48 bytes are for user data and 5 bytes of each cell are used for header information. A
CRC error could occur if any one of the cells that made up a particular frame were damaged.
With an average frame size of just over 100 bytes (159,780 bytes in 1,512 frames), it’s apparent
that the average frame is sent via three cells:

Router#show int atm0
ATM0 is up, line protocol is up
Hardware is PQUICC_SAR (with Alcatel ADSL Module)
Internet address is 10.1.1.1/24
MTU 1500 bytes, sub MTU 1500, BW 640 Kbit, DLY 80 usec,
reliability 40/255, txload 2/255, rxload 2/255
Encapsulation ATM, loopback not set
Keepalive not supported
Encapsulation(s):AAL5, PVC mode
10 maximum active VCs, 1 current VCCs
VC idle disconnect time:300 seconds
Last input 00:16:39, output 00:16:39, output hang never
Last clearing of "show interface" counters never
Input queue:0/75/0 (size/max/drops); Total output drops:0
Queueing strategy:Per VC Queueing
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1512 packets input, 159780 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 1714 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1426 packets output, 146282 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 output buffer failures, 0 output buffers swapped out