Inside this section
[ DSL vs. Dialup ] [ DSL vs. ISDN ] [ DSL vs. Cable ] [ DSL vs. T1 ] [ Additional Facts ]
xDSL Technology
Last modified:
April 22, 2002
Table of Contents
Introduction
Splitters
Wiring/Line Qualification
CO (Central Office) Locations
Sharing a modem/cable/xDSL connection between multiple computers
Sharing a DSL connection with Both Local and Remote Computers
Sharing data over the
Internet (VPN)
Security
Performance
xDSL Standards
US West DSL (MegaBit Services)
The Future
Resources
The information here is not a primer on xDSL. Rather, it is a quick and dirty
synopsis for the consumer who is thinking of using xDSL technology for
networking access and needs some practical information. The resources section at
the end contains links to many DSL resources. This tract concludes with some
discussion specific to the US West (now Qwest as of Oct, 2000) DSL
implementation.
However, to make use of DSL, it helps to understand the basis of the
technology. DSL is a technology for pushing a (relatively) large number of bits
through wiring that is typical for "last mile" telephone connections -- i.e.
small gage copper wire of lengths less than 18,000 feet. There are a number of
different protocols that fall under the DSL umbrella: ADSL, RADSL, HDSL -- and
even different subvariations (e.g. CAP encoding ADSL versus DMT encoding ADSL),
thus the acronym xDSL to represent the technology in total, without
regard to the specific protocol. It's a little like the 56k modem field before
the V.90 standard unified the two main contenders, X2 and KFlex.
xDSL is used to push high bit rates through copper wires that run from point
A to point B. For most people, point A will be their home and point B will be
the other end of the copper phone wire, that is the substation of the local
phone company.
Standard telecom modems (e.g. 56k, 28.8k, etc) establish a data stream
between two arbitrary points using the entire telecom system--that is, from the
sender's local loop, through the telephone switching system (mostly digital
switches now) and then to the receiver's local loop. Standard modem connections
can span continents, with one end being thousands of kilometers from the other
end.
DSL modems, on the other hand, establish a connection from one end of a
copper wire to the other end of that copper wire: the signal does not pass into
the telephone switching system. Consequently, DSL modems are not limited to
using only the voice frequencies passed by the standard telephone system
(typically 0-4kHz); DSL modems typically use more than 100kHhz.
To reiterate, one end of the DSL link will be at the consumer site,
the other end must be at the other end of the copper cable -- usually
this means your local telephone exchange. At your local phone company the local
loop first goes into a splitter that splits the data frequencies from the voice
frequencies. The voice frequencies are wired into a traditional POTS switch and
enter the normal telephone switching network. The data frequencies are wired
into a corresponding DSL modem at the CO end and the resulting high-speed
digital data stream coming from (or going to) the consumer is than handled as
normal data (not analog voice) and may be hooked into any number of networking
technologies for further connection to the data's destination. Thus, the data
never enters the standard telephone switching system.
Typically the data will be routed over a LAN/WAN connection (10Base-T
Ethernet, T1, T3, ATM, frame relay, whatever) to a business office. The business
may be an ISP (the ISP may or may not be the local phone company) which may then
route the data onto the Internet, thus providing you with Internet connectivity.
Or the business may be the company you work for and the connection provides
high-speed access from your home direct to your company's network. Note that if
the connection is made to an ISP, you are not connecting to the ISP over its
standard modem bank: you are coming in over some sort of LAN/WAN data connection
that the ISP has arranged with your local phone company. This is the only way an
ISP can provide DSL-connected ISP service for customers. Also note that DSL is
always "on:" the connection is always there, ready to pass bits up and down the
pipe: there is no calling a remote number and waiting for modems to train up.
Because the other end of your xDSL connection has to be at the local phone
company, the choice of which xDSL protocol your modem should support is made for
you: whatever the local phone company dictates. (See
Hardware/RBOC/CLEC
compatibility matrix for details of who is using what.) However, it would be
nice if there was one standard so that mass production and pricing of xDSL
modems would ensue. It would also let you take a modem from one local phone
company to another. Also, Compaq/Dell/etc. are not inclined to sell computers
with xDSL modems pre-installed unless there is a single standard. See the "Standards"
section below for information about efforts to standardize xDSL modem
technology. Also note that calling xDSL connection devices "modems" is a bit
misleading in that they are not like "standard" modems; however the terminology
seems to have stuck.
Because DSL technology uses a wide frequency range, it is possible to have
simultaneous voice and data use of a single copper connection. (Indeed, one of
the original design goals of DSL was to make it possible for one copper wire to
service multiple homes (e.g. a small subdivision with only 1 copper connection
to the local phone exchange) by multiplexing multiple 4kHz conversations onto
one copper pair.) The voice call will use the normal 0-4kHZ spectrum and the DSL
modem will use the higher frequencies to pass the data traffic. Of course, this
sharing of the copper is not without some potential problems. In particular,
many phones may pass onto the copper frequencies higher than 4kHz, interfering
with the DSL data stream. Also, the higher frequencies used by the DSL may be
picked up by the phone, causing static on the headset.
The original solution to the 4kHz interference problem was to use
"splitters:" a device called a splitter is attached to the phone line near where
it enters the customer premise. The splitter forks the phone line: one branch
hooks up to the original house telephone wiring and the other branch heads to
the DSL modem. See figure 1. Besides splitting the phone line, the splitter acts
as a low pass filter, allowing only 0-4kHz frequencies to pass to/from the phone
and thus eliminating the 4kHz interference between phones and DSL modems.
Figure 1
The problem with splitters is that it requires breaking and
remaking some telephone wiring connections and perhaps even installing new
wiring to the DSL modem. In many cases, this means a service call to the
customer premise. To avoid this, various alternatives have been proposed. The
Universal ADSL group is working on reduced speed DSL that is more immune to
frequency interference and that probably uses only frequencies beyond human
hearing. Rockwell has proposed something similar called CDSL (consumer DSL).
Another solution, used by Netspeed equipment is to use "micro filters." Netspeed
calls this "EZ-DSL." A micro filter is essentially a customer-installable
low-pass filter with an RJ-11 jack on either end: the customer plugs the phone
into one end and the plugs the other end into the wall jack. A micro filter is
placed between each telecom device and the wall jack it plugs into, except for
the DSL modem. See figure 2.
Figure 2
Note that the micro filter solution is essentially a customer-installable
(i.e. no wiring required) version of the splitter solution. Also note that it is
only necessary to ensure that there is a micro filter somewhere between
telephones and the DSL line. If the customer premise wiring makes it easy to do,
the setup in figure 2 can be replaced by the setup in figure 3 (the degenerate
case, in which the micro filter solution essentially becomes a splitter
solution). The figure 3 setup can potentially have less line degradations and
there have apparently been cases where a setup like figure 2 produces a line
that is too marginal to work with a DSL modem, but will work when wired as in
figure 3.
Figure 3
More splitter discussion:
http://telecoms-mag.com/issues/199810/tcs/cavanau.html
Wiring/Line Qualification
There have been some misconceptions about the wiring type required by DSL
modems. Cat 5 wire is not required for DSL modems. DSL modems can work over Cat
3 wiring or even worse. However, the better the wiring the less the signal
degradation and the longer the distance over which DSL modems will still work.
If you are re-wiring your house, I'd recommend Cat 5 wire or better. However,
whatever wiring is in your house is just a small fraction of the total wiring
between you and the telephone central office, most of which you have no control
over.
Not all telephone lines are capable of passing the high frequencies used by
DSL modems. There are also limits to the length of copper wire that DSL will
work on. Therefore, a telephone line must be "qualified" before DSL can be
installed on the line. The line qualification checks the length of the local
loop, for the prescence of loading coils, for the prescence of excessive bridge
taps, for local loops that are provisioned over DLC, and the general state of
the line.
If a line fails to qualify, there are limitations to the recourses available.
A good relationship with the linesmen/testers would help. You can try to get
load coils removed or bridge taps eliminated, but your telephone company's
standard policy may not condon this extra effort. You can try to get your
phone service moved to a different and perhaps cleaner line. It will probably
be a tough go. The International Engineering Consortium has a
tutorial on xDSL line testing. The
line testing tutorial may put some arrows of knowledge in your quiver and may
provide a few meager weapons useful to talking the teleco into the extra effort
needed to get a marginal line qualified.
Webproforum has an
excellent tutorial on the options for providing DSL service over a DLC-provisioned
phone line.
Because DSL technologies are limited to finite lengths of copper wire, it is
often interesting to know how far you are from your central office (the local
Telco wire center that houses the other end of your telephone local loop).
Finding this information is problematic. Perhaps you know of a Telecom
facility in your local neighborhood. Alternatively here are some other options:
Here are few lists of US West central office locations:
COs for
Seattle.
COs for
Portland.
Some CO
locations for GTE, Seattle eastside.
A more general solution, for US West territory, is available from the
US West iconn database
(InterCONNection database).
Mapquest.com has a locator tool (telephone area code search) where, given an
area code and the prefix, it will locate on a map the CO for the area code,
prefix combination. It's been accurate for the few tests I've performed, but
others have reported that it gives bogus results.
A database that covers the entire US is available at
www.telcoexchange.com, where there is
a Digital Line Pricing Tool. Fill out the form for this tool, specify DSL as
the desired connection type, and the tool will spit out the name of the CO for
the specified number. Beware, however, that the distance calculations provided
by the tool may be way off. [As of 11/21/98 the
www.telcoexchange.com site is no
longer providing CO names or V&H location coordinates. I'm not sure why.]
www.getspeed.com will also provide some
CO distance calculations.
The US West and the
www.telcoexpress.com databases express central office locations in V&H
(vertical and horizontal) coordinates, which is a coordinate system developed at
Bell Labs and used by most Telecom companies in North America to express CO
locations.
I've written a little code to convert from V&H coordinates to latitude and
longitude (and back again).
Click here to convert
between V&H and lat/lon. For many reasons, don't expect this process to be
exact. (I generally find the V&H locations from the US West database convert to
lat/lon coordinates that are within 10 blocks of the actual CO location.)
Once you know the lat/lon of your CO, you can locate it using something like
"Maps on Us":
This URL will take you to their page that allows you to "Show Latitude and
Longitude." Check this checkbox and then click the Set General Options button.
You will then be able to open a map location by specifing a latitude and
longitude.
Once you have your lat/lon location and the lat/lon of your CO, the Bali
Online site has a nice little utility to
compute distances between two points. Note that the "great circle"
calculation of the Bali Online site is good for long distances like "the
distance between Seoul and New York", but local surface irregularities can make
it fairly inaccurate for short distances (e.g. intra-city).
http://www.dsltester.com has software that runs a test to determine if the
phone line in question (the phone line used in the test) is likely to qualify
for DSL. There is a link to the actual test server from this page, as well as
some sample test results and other information about the test. They sell the
results to ILECs/CLECs and other service providers, but will provide a pass/fail
report for end users. Some people have reported good results with this test.
Anrew Kaufman of dsltester.com reports on how the test works:
Well, in short, we look a narrow band modem diagnostic information which is
collected by the modems. We then look at the spectral curves produced, and
compare them to a library of curves that we have developed and through
comparative analyses of curves from loops of approximately the same distance
as the one under test we are able to identify the signatures of the various
jeopardies to DSL, such as Loads, DLC's, Bridged Taps, and DAML. I hope this
high level overview gives some better idea of what is happening.
Anyone with more than 1 home computer and an Internet connection eventually
asks the question: "How do I share my Internet connection between my 2
(3,4,5...) computers?" Modem connections can be shared and it's even more
tempting to share cable/xDSL connections because of their "always on" nature and
the greater bandwidth available. The methods are generally the same for any of
the connection technologies and fall into three general categories:
- Obtain a separate IP address for each computer and make sure that you have
some sort of networking enabled to share the connection. One option is to
connect the cable modem to a hub and to connect your computers to the same
hub. Alternatively, with a bit more setup you may use a router and perform
routing on your local network
The advantage of this solution is that each computer has equal and full access
to the Internet. One disadvantage is that many ISPs charge separately for each
IP address. There are also security concerns: if you just connect your local
LAN direct to the Internet, you better make sure your hosts are each
individually secured. The other two solutions depend on a centralized approach
to the external connection, making it a logical extension to deploy a
centralized security solution (e.g. a firewall).
- Use NAT (network address translation) software to let multiple computers
share a single IP address. Sygate is an example of a product in this area.
Linux's IP masquerading is another. NAT1000 is another. Darren Mackay has a
great site with lots of information about
various NAT software.
Dan Kegel has worked adding NAT support to gaming software. He's got a
writeup of NAT and
gaming problems.
On a separate page I record some
USENET discussion
of NAT servers, and in particular the problems of trying to use NetMeeting
(or other H.323 protocol software) with a NAT server.
- Use proxy servers to proxy the particular service you want to share (e.g.
HTTP proxy server, ftp proxy server, etc.). Wingate is an example of a product
in this area.
dslreports.com has a nice set of
drawings that depict the different ways of wiring up a LAN to the Internet.
Tim Higgins has an
excellent web
site on sharing an Internet connection.
www.cablemodeminfo.com also has a
selection of links to articles about sharing a cable modem.
J Helmig's site is another site with
information about sharing a modem connection. The Helmig site also has a lot of
tech-support type information about Windows networking.
A more elaborate situation involves sharing a DSL connection with both your
local LAN and with a remote laptop when you hit the road.
Details are on a separate
page.
When I say "sharing data over the Internet" I mean using the Internet as a
"long cable" to connect two (or more) geographically separate hosts. In other
words, two separate hosts want to share files back and forth between each other.
There are a number of ways to do this, each with separate capabilities and
problems.
- OS-independent, bare bones: run an FTP server.
One host runs an FTP server and other hosts can, via an FTP client, get and
send files to the FTP server. This is a simple mechanism, is operating system
(OS) independent, and is a time-honored tradition on the Internet. However,
it's not real seamless and the capabilities are somewhat limited.
- Use standard Windows networking, with the Internet providing the
connnection.
Steve Jenkins has a
detailed writeup of how to do this. I also provide a short writeup of
windows networking and the
Internet. This is a nice extension of a local LAN over the Internet,
however the mechanism is not very secure. It opens the hosts at either end to
potential security attacks and, typically, the data passing over the Internet
(i.e. the contents of your files) is not encrypted. In other words, it is
open to people to read or even (with more work) modify, as the data moves over
the Internet.
- Use VPN.
VPN, or Virtual Private Networking, is a mechanism for establishing a secure
and private network on top of an open and insecure network. In effect, you
end up using the Internet as a pipe, and establish a secure and protected
connection between two separate LANs over this pipe. A VPN connection
typically provides all the capabilites of the "standard Windows networking"
connection, with much better security and data integrity. Windows provides
VPN services through a technology know as PPTP. Microsoft has several white
papers on the technology on their web site. The "Routing and Remote Access"
(also known as the multi-protocol router) patch for Windows NT provides both
PPTP client and server capabilities. I provide
VPN details are on a separate page.
An article I wrote for Information Security Magazine provides a basic
overview of security and a DSL connection to the Internet. The following
section provides a shorter re-hash of the article's content.
An excellent site for firewall reviews and other site security information is
http://www.firewallguide.com.
An xDSL (or cable modem) connection to the Internet has a greater security
risk than a plain old analog modem dialup connection. For one, the bandwidth is
greater, allowing the possibility of more cracking to be done in the same period
of time. More importantly, the connection is usually always on, which makes your
hosts a much easier (and potentially more lucrative) target to find. The
discussion in this section concentrates on examples of LANs connected via DSL to
the Internet, but the points can be applied to the single computer case just as
well. (The LAN case encompasses the single computer case.)
One mechanism for sharing a DSL modem is to connect it direct to your local
LAN hub and to use valid IP addresses for each of yours hosts:
Figure 4: Direct Hub Connection
While this is a conceptually simple method for sharing an DSL connection
(particularly with a bridging DSL modem and an ISP that is handing out IP
addresses as required via DHCP), it requires a fair amount of diligence if you
are concerned about the security of the local hosts. First, the only thing
preventing your local LAN traffic from zipping around your ISP's LAN is an
Ethernet learning bridge. While a bridge will not forward traffic destined to
local MAC addresses, it will forward multicasts and broadcasts. A malicious
cracker could make use of this information to target your systems. In addition,
if you are using more broadcast-chatty protocols on your local LAN, like
NetBEUI, you are passing even more information onto the ISP's system. A learning
bridge is not a security device, it is a traffic-limiting device, designed to
keep your local point-to-point LAN traffic from swampping the rest of the
network. Second, a configuration like this leaves every host equally open to
attacks from the outside. Each host has to be secured independently and equally
if you want to prevent a weak link in your system. Finally some security
techniques (such as firewalls and preventing your file and printer sharing
traffic from even being accessible) are not available in a configuration like
this. There is nothing inherently wrong with this configuration: it is a
perfectly valid configuration, depending on your security needs. Most companies
with a concern about the data on their local LAN would not use a configuration
like this. However, historically, many departments at educational institutions
would connect with mechanisms similar to Figure 4 (with a standard Ethernet
bridge, usually from DEC, rather than a DSL modem, but the concept is the same).
Other details of the direct hub connection: (under construction): possible
problems if only using TCP/IP transport (lack of connectivity, or connectivity
through ISP's gateway); using multiple IP addresses problematic if both DHCP and
static assignments are desired; using multiple transports and unbinding
file-printer sharing/netbios from TCP/IP.
Another option would place a dual-homed gateway between the ISP and your
local LAN. If the local LAN is using non-routed IP addresses and if the gateway
is only providing access through a proxy server or a NAT server, then the
security is improved:
Figure 5
The dual-homed host solution isolates your local LAN traffic from the ISP's
network. In addition, a NAT/proxy server on the dual-homed host provides some
protection to other hosts in the local LAN, which do not have to be
watched/secured as tightly. In a situation like this, an operating system with
security capabilities would be advisable. For Windows users, Windows NT, because
of its security capabilities, would make more sense on the dual-homed host
rather than Windows 95/98. Using NTFS, it is possible to lock down the OS files
for NT, helping to defeat cracking attempts from the outside. In addition, it is
possible, via the network control panel applet to disable the Workstation,
Server, and NetBios bindings from the network adaptor that is connected to the
DSL modem. This eliminates all Windows networking file access through the NIC
connected to the DSL: you won't have to worry about anyone making a network
neighborhood connection to shares on your gateway machine. Unbinding like this
does not eliminate file and printer sharing through the local LAN side of your
gateway machine, which is a great feature. In other words, you have file and
printer sharing capabilities on interfaces 192.168.0.1, .2, and .3, but don't
even expose file and printer sharing capabilities through interface
204.180.205.31.
The dual-homed approach, with a fairly small degree of inconvenience (as
compared to figure 4), provides the opportunity for improved security. To
summarize the dual-homed approach:
- Use a dual-homed machine to make your connection to the DSL modem.
- Run a NAT or proxy or firewall server on the gateway machine. Only run
those services that are necessary (e.g. if you don't need to run an ftp
server, don't.)
- Use an OS with security capabilities on the gateway machine. Disable the
guest account. Use reasonable passwords on all accounts. Lock down the OS
files. Unbind native file networking protrocols from the DSL-side NIC on the
gateway machine. For Windows NT users, consult the quick checklist for
securing Windows NT to
make sure your Windows NT installation is reasonably secure. Also, the
IIS
security checklist has lots of information about securing a Windows NT
machine that is connected to the Internet. If you want all the details on
locking down your NT machine, this is the place to look.
Securing a connection to the Internet is a large topic, much of the which is
beyond the scope of this tract. There are a number of sites that provide more
discussion. Johanne Ullrich's web site
has a simple introduction to security issues for the consumer connected to the
Internet. He also includes some step-by-step instructions for some common
precautions for Windows 95/98.
http://www.microsoft.com/windows95/community/mktbulletin/cable-security.asp
is Microsoft's quick and dirty "how to for dummies" page on cable modem security
for Windows 95. It basically talks about turning off File and Printer sharing or
using password protected shares.
http://support.microsoft.com/support/kb/articles/Q164/8/82.ASP is a more
complete knowledge base article about basic Windows NT security for Internet
connections. More complete information is available from Microsoft's security
pages:
http://www.microsoft.com/security
NSA has a popular set of white papers on
securing Windows 2000.
For a great tome on security and securing NT in particular, see
Sean Boran's site. The
Amoring NT site is good
and concise. The labmice.net site has
a good checklist
of items to attend to for securing Windows 2000. The hardening Win2k guide at
http://www.systemexperts.com/win2k/HardenWin2K.html is useful. The
NT security FAQ is not
concise, but it has lots of information and links. Finally, the
CERT site is a
good checklist and contains lots of pointers to other sites.
Port scanning sites
HackerWacker will do a port scan and
a few other probes of your host, testing for common security problems.
http://grc.com will do a port scan (look for
"Shields Up").
http://www.dslreports.com/r3/dsl/secureme
http://www.antionline.com/
Along with sharing and security, one of the first things a new DSL user wants
to know is "how fast is this baby, really?" So they surf off to some server
somewhere and try to download a big file. And they are subsequently pleased at
the speed or curious because the rate doesn't seem as fast as the modem is
rated. Here's a few quick points to keep in mind while measuring your
performance.
Know your modem's speed. Your modem is "trained up" to the
corresponding equipment at the other end of your local loop. DSL Modems, like
standard anlogue modems, can train up at different speeds, depending on the line
condition and configuration settings at the consumer end and Teleco end of the
connection. For example, with the Cisco 675 modem used by US West, the command
"ifconfig wan0", when given to the modem (using the serial port connection to
the modem's management port) will display something like:
nsos>ifconfig wan0
wan0 ADSL Physical Port
Line Trained
640 Kbps down; 272 Kbps up; 340 baud
Line Quality 34 dB
nsos>
In this case the modem is trained up for 640kbits/sec down and 272 kbits/sec
up: the very best you can expect in this case is a download transfer rate of
640kbits/sec.
Recognize that the Internet is not homogenous. Some servers
may be far away and connected over slow links. You will not get fast transfer
rates from these servers regardless of how fast your local connection is. You
are only as fast as the slowest link (or slowest server). In others words, the
best download test would be a connection to a fast server directly on your ISP's
network. This kind of test eliminates the most unknowns.
Know what you are measuring. When you get performance
numbers, where do you get them from? They may mean different things. For
example, while downloading a file in Internet Explorer, IE will report a
download speed. This is the speed that the actual file data is being copied.
(For example, a 200k file that takes 60 seconds to transfer is a download speed
of 3.3k/sec.) But the actual number of bytes passed over the DSL connection is
much higher because of the overhead of encapsulating the payload in the various
network layers. Add various Ack/nak packets or whatever other protocol overhead
there is, and you may be shoving a much greater number of bytes down the line.
To elaborate, here's one simple test I did. The numbers are just rough guides
and I didn't subject this test to great rigor. However they illustrate my point.
I downloaded a 5,595k file over a 640kbits/sec (down) DSL connection. The
download speed reported by IE (actual file bytes) was 45kBytes/sec, or
360kbits/sec. However, the actual number of bytes passing over my Ethernet
interface from the DSL modem was 56kBytes/sec (as reported by Windows NT's
Performance Monitor), or 448kbits/sec, which is getting pretty close to the
rated connection speed. (These numbers are averages over the entire transfer
time.) If I only used the first measurement (IE's reported download speed) I
might think I'm only getting 56% of the maximum connection speed. However the
second number shows that I was actually getting at least 70% of the rated
connection speed. For comparison, the highest I've seen off my US West DSL
connection is 93% of the rated connection speed, as measured off the Ethernet
interface.
It really matters what you measure.
All that said, how do you fine-tune a DSL connection? I find that Windows
NT's default configuration for its TCP/IP stack works just fine. It supports a
number TCP/IP dynamic performance adjustment algorithms that have been developed
over the years and these work just fine for me. Your mileage may vary. Other
people using Windows (especially Win95 and Win98) have reported considerable
performace gains by adjusting various configuration parameters.
Philip Philpov's Cable
Modem page provides some enduser-oriented discussion of cable modems,
including tips and tweaks for better speed. The discussion has almost equal
bearing for DSL connections.
http://home1.gte.net/awiner/ also discusses some registry tweaks for
improved DSL/Cable modem performance under Windows 95/98/NT 4.
Performance measuring tools:
There are numerous sites around the Internet that advertise "click here to
get a readout of your connection speed." (For example, see
www.2wire.com's bandwidth measurement
page.) These all work by downloading a bunch of data to PC and timing the
process. It is important to note that these tools are rough approximations at
best: if the pipeline between you and them is congested, they are are going to
tell you that your DSL link is slow. They are measuring a total path through the
Internet and not just the speed of your DSL link.
US West (Qwest)
has a performance site that lists a number of test download locations on
their network. If you are a uswest.com DSL subscriber, by selecting a site
close to you, you get a test that minimizes weak links on the general public
Internet.
Windows 95/98: try the Network Monitor Agent that Microsoft provides at
http://www.microsoft.com/windows95/downloads/. It works with the Win95
System Monitor. It shows realtime transfer rates off your ethernet card (in
other words, it includes most overhead layers).
Windows NT: try the Performance Monitor, which is great tool for monitoring
the state of a NT system. Much superior to the Win9x System Monitor. The
relevant object to measure is the Network Segment object: an interesting counter
of that object is the "Total bytes received/sec" counter. There are lots of
other interesting objects also. Note: the Network Segment object is only
visible in the Performance Monitor if the "Network Monitor Agent" service is
installed (goto "Control Panel, Network, Services" to check/correct this).
DU Meter (http://www.hagel.threadnet.com/dumeter/)
and Net.Medic (http://www.vitalsigns.com/netmedic/index.html)
are two other popular tools.
Sitka maintains a page with a number of
network monitoring tools. Of particular interest is the visual ping took, which
calculates the ping time and the available bandwidth from a from a sitka host
(Sitka is situated in Canada) to the a user-specified host. For example:
http://sitka.triumf.ca/cgi-bin/visual-ping?uswest.net
will calculate the data from sitka to uswest.net.
Substitute your site of interest for
uswest.net in the above URL.
Another intesting tool is available at
http://www.datametrics.com:81/ This
tool will perform a traceroute, and also plot the locations on world map.
Performance results:
Given all the variables in the Internet, it's quite difficult to do an
apples-to-apples, repeatable comparison of access speeds. Nonetheless, people
are always curious to compare speeds.
Bill Faust has a project going that has compiled a set of results of
download speeds. If you want to see what speeds others are getting, check it
out.
http://www.disisit.com/nettest.html also has some interesting numbers for
one specific case.
A number of ADSL standards have been proposed, many with the intent to
obviate the need for splitters and any service call to the customer premise.
These include Netspeed (Cisco) EZ-DSL, Rockwell's CDSL (consumer DSL), and the
ITU's G.Lite initiative.
As of June 1999 the ITU's G.Lite standard has been ratified. The consumer DSL
market appears ready to rally around this standard, but as of June 1999 there
are few (perhaps none besides tests) deployments of this standard. This standard
is known as G.Lite, DSL-Lite, and Universal DSL. It allows for splitter-less
installation (using micro-filters when necessary instead) and is limited to
1.5MBits/sec down.
The Universal ADSL group is an advocacy group working to rally the industry
around a common standard. They have focused on the ITU G.Lite initiative, which
passed into the standards phase in the fall of 1998.
The Universal ADSL Working Group (UAWG) is an alliance of PC industry giants
Compaq, Intel and Microsoft and telecommunications leaders Ameritech, Bell
Atlantic, BellSouth, GTE, SBC Communications, Sprint and U.S. West, supported by
networking and semiconductor leaders, including 3Com Corporation, Alcatel,
Analog Devices, Ariel Corporation, Aware, Cisco Systems, Copper Mountain
Networks, Covad Communications, DSC Communications, Ericsson, Globespan
Semiconductor, Lucent Technologies, MCI, Netspeed, Nortel (Northern Telecom),
Rockwell Semiconductor Systems, Siemens, Texas Instruments, Tut Systems and
Westell Technologies. The UAWG is working to deliver an open, interoperable
extension of the ANSI standard T1.413 ADSL to the International
Telecommunications Union for consideration in 1998. With the goal of providing
consumers with assurance that ADSL products and services will work together, the
UAWG's work will leverage currently planned equipment deployment for full-rate
ADSL and help to provide a seamless migration path from today's modems. In
addition, the group aims to maximize the economy, speed and efficiency of both
full-rate and Universal ADSL deployment. More information on the Universal ADSL
Working Group is available on the group's Web site at
http://www.uawg.org.
From the UAWG web site:
Q1. What is Universal ADSL? What
speeds are we talking about?
A1. Asymmetric Digital Subscriber
Line (ADSL) is a technology that allows telephone companies to use today’s
wiring to the home for high speed digital communications. ADSL enables
simultaneous transmission of voice, data and video over a single phone line.
We call our group the Universal ADSL Working Group because we are promoting
full-rate ADSL as well as a mass market, consumer oriented version of ADSL.
This mass market technology does not need a “splitter” box installed outside
the home or new wiring in the home. This simplifies installation greatly and
makes it much more a plug-and-play solution. The speeds we are targeting are
up to 1.5 Mbps downstream and 512Kbps upstream. (Full-rate ADSL enables
speeds up to 8 Mbps downstream and 1.5 Mbps upstream.) Unlike cable
technologies, this is a dedicated line so it has the benefits of maintaining
high speeds without being affected by other users in the neighborhood.
The information in this section is mostly specific to the deployment of DSL
by US West. US West calls their DSL offering
MegaBit Services.
MegaBit Services does not refer to a new technology, it is just the tradename US
West uses to refer to their rollout of RADSL service. The US West deployment is
using EZ-DSL, a micro filter design by Netspeed. (Netspeed was acquired by Cisco
in March, 1998) Customer (home) end equipment is either the
PCIRunner xDSL internal
modem card or the SpeedRunner 204
(which is now being called the Cisco 675) standalone (external) router (or
"modem" as I've been calling it). The PCIRunner is installed much like a regular
modem. It plugs into a PCI slot and has an RJ-11 jack for connection to the
phone line. It comes with Windows 95 and Windows NT drivers. It does not require
an Ethernet card.
The standard install is using the SpeedRunner 204 and comes with the
SpeedRunner 204, an Ethernet (3Com 3c905) card, a twisted pair Ethernet patch
cable (cross-over), and micro data filters made by Globespan. The SpeedRunner
204 has an RJ-11 jack for connection to the phone and an RJ-45 jack for an
Ethernet connection to the customer equipment (an Ethernet hub or a single PC
equipped with a 10-baseT Ethernet card). If the SpeedRunner is connected to a
hub, it should be connected with a straight-through patch cable rather than the
cross-over cable that comes the install kit. Connecting into a hub makes is
possible for all the computers on the customer LAN to access the Internet. (See
the
Sharing section.)
http://w3.one.net/~garyc/adsl/howtos.htm#lan has some information on how to
operate the Cisco 675, including upgrading the firmware and recovering from a
blown firmware upgrade.
US West is providing two different filter types: filters for wall-mount
phones and filters for phones connected to a wall jack. The filters only filter
on line 1, so if you have a two line phone setup and have the DSL modem on line
2, it will be necessary to somehow arrange to filter the 2nd phone line. There
are at least two possibilities: apparently the wall-mount filters come apart so
you can dissect them and switch the connections from the line 1 pins of an RJ-11
jack to the line 2 pins of an RJ-11 jack. Alternatively, at Radio Shack and
other "phone" stores you can buy little connectors take a single RJ-11 2-line
jack and splits it out into 2 RJ-11 jacks, both wired for line 1 (but one going
to the real line 1 and 1 going to the real line 2). Plug the micro filter into
the line 2 jack of this 2-line splitter. Then plug a single line phone into the
micro filter.
Software
There are no special software requirements to use a DSL connection. Quite
often the DSL connection device is package with an Ethernet interface for the
consumer side (e.g. the Cisco 675 supplied by US West). In this case, if your
computer speaks TCP/IP, and if it can interface to Ethernet (just about every
operating system meets these two requirements), then it can use a DSL
connection. uswest.net supplies a special CD-ROM package for Windows as part of
the US West installation package, but it's mainly just a browser (Netscape) with
some uswest.net configuration information pre-supplied. It's not necessary at
all.
A short rundown of the US West installation process:
- Install the Ethernet card in the PC (not necessary if connection to a
hub). Make sure the PC OS recognizes the Ethernet card and has the proper
drivers installed.
- Install microfilters on all phone lines, except the line connected to the
Cisco modem.
- Connect the Cisco modem to the phone line (using the Cisco's RJ-11 jack)
and to the Ethernet card (or hub) using the RJ-45 jack.
- Make sure the Cisco modem is configured for bridging mode, not classical
routing or PPP routing over ATM. (This actually depends on your ISP.
uswest.net is using bridging mode.)
- Configure your operating system with the correct TCP/IP configuration
information for your ISP. (Basically: IP address, netmask, default gateway,
and DNS server addresses. You may also have to configure email with the
correct server name and user id and password. You know the drill.)
The US West order process and support staff is notoriously SNAFUed, so it may
take some time and a number of people to get answers to simple questions.
Apparently, their process works like this: they have a sales staff that takes
orders and appear to work under commission. These sales people have access only
to a new order database. My sales staff operated out of an 888.641.4384 number.
After an order is taken, it can progress to a "stored order" database, which is
where orders sit if the destination central office is not yet DSL equipped. An
order stays in the "stored order" database until its due date arrives, at which
time it migrates to the work order database. The work order database is where an
actual work order is generated for the order and someone is scheduled to do the
installation. Each group at US West apparently has access to only one database
and you can get bounced around quite a bit until someone can actually find you
in the database. Clearly, the system is far from optimal: case in point: my
order was entered with a due date of 10/1/98, instead of 7/30/98, which is when
service is actually available for my area. My order was also "lost" numerous
times. Sound advice would dictate checking on the status of your order several
days after placing it.
Second-hand information indicates that for the initial Seattle rollout of
DSL, US West installed capacity for 64 ports per wire center (CO). Given that
Seattle has about 11 wire centers, this equates to capacity for 704 DSL
customers.
US West Megabit numbers:
Sales: General Megabit: 800.634.2879. My sales (for Washington?) number:
888.641.4384
Post-sales info: 888.333.0131
Work Order number (the people only track work orders and don't have access to
the "stored order" database): 888.234.9375
Tech Support: 888.234.8375
Megabit Installation Technical Support: 1-800-247-7285.
ISPs that support DSL access
ISPs that provide DSL access are worried about their Internet backbone
connection being swamped by these new high-speed links. For example, if an ISP
has only a T1 link to the Internet, it won't take many 256k DSL customers to put
a heavy strain on this T1. ISPs seem to be dealing with this issue in two ways:
limiting what the customer can do with his link (e.g. not allowing the customer
to run http servers), or by putting monthly quotas on how many bits the customer
can transfer over his link. The former, in my opinion, is a dumb idea, the
latter is perhaps a reasonable solution to a valid problem.
US West sells "MegaCentral" (an ATM connection to US West's data net)
connection services to ISPs that wish to service US West DSL customers. Assuming
a client who uses DSL to connect to the internet through an ISP, the mechanism
for a packet of data is as follows: the data passes from a client's computer,
through the Cisco 675 to the local CO and from there it passes onto US West's
ATM network and gets sent to the client's ISP. From there the ISP passes the
data onto the Internet for routing to its eventual destination.
There is a vast body of telecom law in the US that prevents the RBOCs
(Regional Bell Operating Companies, the baby bells, e.g. US West) from offering
long distance service (both voice and data) until their home territories are
open to competition. Speculation has it that this prevents US West from opening
up their ATM network to nation-wide ISP mega-central connections. In other
words, if you are an ISP and want to provide service to US West DSL customers in
Seattle, you have to connect to US West's ATM network in the Seattle LATA; a
Denver connection won't do because US West can't run long distance data over
their ATM network to your Denver ISP. From the end-user's point of view, this
means that you are limited to ISPs that have a connection to US West's ATM
network in your local LATA.
US West maintains a
list
of ISPs that are equipped to provide ISP service for US West Megabit customers.
Todd Boyle has a comparison
chart of ISP's providing DSL service in the Seattle area.
uswest.net does not track NIC MAC addresses. PacBell also does not track NIC
MAC addresses.
US West: Some Technical Details
US West provides some sparse technical details about their configuration in
their disclosure pages for the DSL tariff:
http://www.uswest.com/com/disclosures/netdisclosure403/index403.html for
disclosure page.
http://www.uswest.com/com/disclosures/netdisclosure403/news.html#ADDINFO for
other disclosure information.
With the Cisco 675 modem set to bridging mode (RFC 1483), the Cisco is doing
ethernet to ATM bridging. Data from the PC passes down through the TCP/IP stack
on the PC, gets packaged as Ethernet frames and is passed to the Cisco over the
Ethernet interface. The Cisco converts these Ethernet frames to ATM cells, which
get passed over US West's ATM cloud to the ISP's router, where they pass into
the ISP's system.
The alternative is to run the Cisco 675s in routing mode, in which case the
Cisco 675 acts as a mini router, receiving IP data from the PC (transported in
an Ethernet frame), which is then sent onward as an IP packet in a PPP link
running over ATM (PPP over ATM). There may be some advantage to this method for
some ISPs, since many are already set up to do authentication and billing using
PPP-based systems.
As of Spring, 1999, new US West installations are configuring the Cisco 675
to use PPP routing. In this mode, the Cisco 675 is using PPPoA. The 675 is
logically one endpoint of a PPP link. As such, it has an IP address and acts as
a router, not a bridge. Since the basic uswest.net PPPoA configuration supplies
only 1 IP address, which is used by the 675 as one endpoint of the PPP link, the
675 acts as a NAT server to effect the actual connection of any PCs to the
Ethernet interface on the 675. See
http://www.users.uswest.net/~scottz/Cisco675-NAT.html for information on the
Cisco NAT implementation.
US West Problems
USWest: Bad Cisco Modem or faulty modem power supply.
There have been numerous reports of Cisco modem failures with the US West DSL
service. Many of these appear to result from bad power supplies. To quote from
SimMike's posting:
I finally talked with someone at US West who confirms that my Cisco modem
has failed. The sure sign of modem failure is the LAN LNK light blinking on
and off. He also confirmed the rumor that US West had sent out a bunch of
faulty power transformers. From my understanding, the transformers slowly
start malfunctioning, overpowering the modem, until the modem finally fails.
It boggles my mind that they could send such a junky cheap transformer with
an sophisticated router like the Cisco 675. Stupid is the word that comes to
mind.
They promised to send me a whole new modem package. I will send back the old
one after the new one arrives. My service will be out 10 days. One final
piece of advice, be sure and call the Megabit Installation Technical Support
line at: 1-800-247-7285. These guys are the only ones who understand the DSL
hardware. Everybody else at US West will give you the run-a-round.
Read the message below for signs of modem failure.
SimMike wrote in message ...
>>>This morning, 10-30-98, I hit the mouse to bring my screen back to life.
There was an error message saying it could not connect to DCHP to retrieve
my addess (IP). I closed this box and tried my e-mail and web browser. No
luck. The WAN and LAN LNK lights were steady and on. There was even
intermittent activity on the ACT lights for both. Still no connection. I
rebooted my computer. Same problem. I unplugged the modem power, no luck. I
connected the Serial port Management cable to the modem and brought up
Hyperterminal. The familiar Netspeed banner flashed on the screen. Response
seemed somewhat sluggish, but I tried a few commands, like Stats. Next I got
this error message:
"Hello!
Operation fault at fefd55cc, subtype 01
Fault ecord is saved at 1013b540
fefd55cc : 90b03000 1000638c ld 0x1000638c, g6"
>Now the Cisco 675 banner will not come up. I'm afraid the modem is fried. I
tried one more thing. I unplugged the modem transformer and let it cool off
of half an hour. It always ran hot anyway, much hotter than other
transformer converters. When I plugged it back in, the only light that came
on was the Power light. No WAN light. No LAN light. Nothing except power.
If I leave it be, after about twenty minutes the LAN LNK light will start
weakly flashing every second or so. Slowly this flashing gets stronger. Next
the LAN LNK light starts flashing and alternating with the Alarm light.
Finally after about 10 more minutes, the LAN LNK light is steady, no Alarm
light, and the LAN ACT light even flashes occasionally. Still no WAN light.
Still no connection via the Management cable connection.
>I really think the Cisco 675 somehow failed. I read an earlier message
about possible problems with the transformer malfunctioning, overpowering
the modem, and eventually causing total failure. That sure looks like what
happened. If it was simply my DSL connection, the Serial port management
connection should still work.>
>
>Mike Reinholz
>PS -- my computer is running fine. I ran 3Com diagnostics on the network
>card and it passed all tests.
USWest.net: Problems connecting to another DSL-machine on the same local
subnet.
The problem occurs when two separate DSL-connected machines can successfully
access the Internet, but they can not successfully access (ping) each other. If
they are on the same US West local subnet, then the problem is known. A posting
to the uswest.dsl newsgroup at news.uswest.net (by Xiphiplastron
[xiphi@cyberdude.com]) describes the
problem and a work around:
In article <35D4FE08.94B66938@ibm.net>,
etkal@ibm.net says...
> It seems that systems on the same subnet using DSL cannot talk to each
> other. For example, a friend locally has a DSL line, and I cannot ping
> his system. Likewise, certain games, etc. will not work correctly,
> although they work to other users on different subnets. I can get to his
> web page from other outside locations, but I can't when I use DSL.
>
> USWest tech support says it is a known problem, but that they don't know
> when or if it will be fixed. Sounds like a routing problem, but can
> anyone post some technical detail as to what is going on here?
I haven't seen a response to this so I thought I'd put in my experience
with regard to this.
Not being able to ping others on the same subnet (not connected to your
LAN) is a "feature" of how they do things. Simply put, if you try to
ping someone on your subnet, it's going to assume it doesn't have to go
through a router and try to use the ARP protocol to connect. Since
you're only connected to the other user via a router, you need to set up
something in order to do this.
Assuming you're running Windows 95/98, you could open a DOS window and
execute instructions as follows:
If you're in subnet 123.123.123.xxx and your final octet is 100 and your
friend's is 101 and the router is (likely) 254 you'd do the following
command in your DOS window:
route add 123.123.123.101 mask 255.255.255.255 123.123.123.254 metric 1
Your friend would do the same except change the last octet in the first
IP address to yours. to findo out the router's IP address, type ROUTE
PRINT at the command line and you should be able to figure it out from
the list of IP addresses.
Although the commands listed are for Windows95/98, adept users of other
operating systems should be able to figure out specifics. I am curious,
however, if there's a way to do this on the Mac OS. I'd appreciate any
info in that regard.
USWest.com: Intermittent Line Problems.
Line problems are a function of the connection between the customer's modem
and the DSLAM at the CO. One thing to check is the signal quality. The Cisco
675 reports a db reading. This apparently needs to be greater than 17db to have
a hope of a quality DSL connection, even for slow speeds (256k). Levels above
25db give you a little more headroom. Another area to check is the amount of
errors recorded. Larry M posted the following in comp.dcom.xdsl:
>High CRC (Cyclical Redundance Check) errors usually point to
>a bad modem, either at the CO (the ATU-C) or at the remote
>(ATU-R). One thing you can do to test this is to unplug
>your modem and plug it back in (recycle it) a couple of
>times. Do a "stat wan0" check each time you recycle it.
>Each time you do that (theoretically) you should train up to
>a different modem in the CO (unless the DSLAM is full).
>Look for big differences in CRC errors. Which means you hit
>a bad modem in the CO. To test your remote modem you could
>ask US West to send a tech out with a modem and compare his
>error rates with yours.
>High RS (Reed Solomon) errors usually point to cable
>problems. Although high CRC errors can cause high RS errors
>also.
USWest.com: Intermittent Solid WAN activity light, lasting 15 minutes or so
(ARP Storms).
The following USENET article describes the ARP storm problem.
David Sandberg <mystic_fmSPAMJAM@excite.com>
wrote in message
news:378f6243.4672602@news.uswest.net...
> Every once in a while I have a problem with my US West DSL line, where
> the line will suddenly become unusable for half an hour or more.
> During these periods the WAN light on my Cisco router (in bridging
> mode) is solidly on, and the LAN light is blinking constantly.
> Running "netstat -e" (under Windows 95) tells me that the only
> activity being registered is about 10 non-unicast packets received per
> second. Nothing shows as outgoing, and the per-protocol statistics
> ("netstat -s") seem to indicate that no activity is happening at all.
> But during the periods of this activity I cannot access the Web, get
> mail or news, or anything else.
>
> This seems to occur once every couple of days, although sometimes I
> have had long periods without noticing the problem (like weeks). I'm
> not sharing any system resources that could be accessed from outside.
> I've inquired with US West about this, but they made no effort to
> suggest any reasons or to track down what might be happening.
>
> Has anyone else experienced this? Any ideas?
>
> --
> David Sandberg
I believe, from your description, that you are experiencing an ARP storm.
ARP storms are: 1) a known problem, 2) are experienced by others (the
problem is not limited to your experience/conditions), 3) there is nothing
you personally can do to address the problem, 4) are one of the main reasons
why US West is moving from bridging mode to PPP mode, and 5) there is
nothing you can ask US West to "fix" until your local pop is switched over
to PPP mode (that's the fix).
(Are you in bridging mode rather than PPP?)
I'm enclosing an explanation, previously posted by a US West engineer, of
ARP storms in a Cisco-DSLAM ATM environment. It's a good explanation and
since this topic comes up fairly frequently, I may have to add this to "US
West problems" area of
www.tuketu.com/dsl/xdsl.htm.
Randy Day-
--------start enclosure----------
Address Resolution Protocol - ARP is a function of how
a device finds the relation from a IP address to a physical network address
For instance, if your workstation has an ethernet address of
00:a0:24:5d:d8:ae
and an IP address of 215.216.16.6. In bridge mode the router at .net will
have a
table of IP address to mac addresses. There is also a bridge table that the
router keeps
that maps the ethernet address to the PVC over the atm network to that
workstation.
The ARP table need to be there so that the router knows how to talk to the
end
workstation at the ethernet layer.
What happens in these arp storms is the following:
Cisco has a feature/bug which say you cannot clear a single ARP entry from
the router.
You either clear the whole ARP table or nothing.
In Bridge mode the router has to have an ARP to talk to a remote IP device.
When it gets a arp it does not know what the ethernet address is, therefore
it also
does not know what the PVC is to send the arp request out. So it sends a
broadcast
to all PVC for every single ARP.
To make a long story short, When the whole ARP table is cleared, the router
has to rebuild the ARP table, so it sends a broadcast to every PVC for every
workstation
on the network. In other words if you have 1000 PVC with 10 PC's on each
DSL
connection the router send 1000*1000*10 ARPS, 10,000,000 ARP's get sent out
to rebuild the whole ARP table, and yes these ten million ARPs go out to
EVERY PVC.
The router CPU shoots up to 100% for up to 10-15 minutes just to rebuild the
ARP table.
Why is USWEST clearing the ARP table?? They are not, they are just
maintaining the
IP addresses for customers.
Remove a static IP and the router clears the arp table.
This is the main reason there is a push to get away from bridging!
Bridging in this environment is not a scalable solution.
--------end enclosure----------
Case Study: Running a Web Server off a DSL Connection
As an experiment in DSL robustness, I've been running the
www.tuketu.com webserver off a DSL
connection. The DSL connection is 640kbit/sec down, 272kbit/sec up. uswest.net
is the ISP and the IP configuration is determined by DHCP (the IP address is
assigned by DHCP and free to change at any lease renewal). tuketu.com is a low
volume server, getting about 500 users visits a day. The name service for the
tuketu.com domain was initially provided by granitecanyon.com. No software
help is used to manage the relationship between the IP address and the DNS
information. (i.e. nothing like dyndns.com or tzo.com)
tuketu.com had 5 major (longer than 2 hours) outages during fall 98 to late
summer of 99 period. It had a number of smaller outages during this time
period, the vast majority of the smaller outages being related to the
administrator (me) mucking around with the web server (rebooting, etc). Very few
of the smaller outages were related to DSL/ISP problems...and most of those were
largely the result of ARP storms.
The major outages can be diagnosed as follows:
Case 1: DNS resolution problems.
The DNS service for tuketu.com was provided by an external third party,
granitecanyon.com. Granitecanyon.com is a free public service provided by some
engineers with heart, but the robustness of their servers and the speed of their
change mechanism leaves something to be desired. For one particularly bad two
week period their name servers were out of sync, one providing bogus data while
the other provided correct data. This impeded the ability of some users to
connect to find tuketu.com.
Case 2: IP number changes, difficulties updating DNS information.
In this major outage, the ISP renumbered their IP network (probably to manage a
shortage of IP numbers rumored to exist at the time in their local POP). This
resulted in a new IP number being assigned by DHCP. (Even with a static IP
provided by the ISP, the renumbering could have resulted in an IP address
change.) Human monitoring noticed the new IP address in a relatively short
period of time (several hours), and the new address information was then
propagated to the DNS servers. However, it took about a week for the DNS servers
to pick up the new information. For this week, connections to tuketu.com were
problematic. Several hours of this outage are attributable to the dependence on
human inspection to notice IP address changes on the server. The remainder is
attributable to DNS service problems.
Case 3: DSL hardware error.
After about 6 months of use, my DSL connection experienced a hardware error. It
was eventually tracked down to a faulty modem in the DSLAM at the CO office. It
took uswest.com about 10 hours to respond to the problem report and to track
down the problem, but they did work past office hours to do so. The symptoms
were actually rather difficult to interpret (WAN link light was OK, traffic
could go upstream, but not down-stream), but uswest.com worked it out. IP
address assigned by DHCP server did not change after this outage. Everything
was up and ok after the hardware was replaced at the CO end.
Case 4: Webserver unplugged, IP number changes, difficulties updating DNS
information.
In this case, the IP number assigned by the DHCP server changed. The reason for
the IP address change is unknown, but it could have been the result of the
Webserver host being unplugged and down for longer than the DHCP lease period
(three hours). The problem in this case could not be diagnosed for several
weeks, since the system administrator (me) was out of the country and not able
to connect to the webserver for remote diagnostics. When the problem was
finally diagnosed, it was another week for the necessary changes to propagate to
the DNS servers for tuketu.com (see case 2 above).
Case 5: DSL hardware failure at the CO end.
In a classic case of Murphy's Law, about 3 hours before leaving on a vacation,
my DSL line went down. My Cisco 675 refused to sync up with the CO. I called
the problem in and got a trouble ticket, but US West failed to fix the problem
during the two+ weeks I was on vacation. The problem did not get fixed until I
returned and bugged US West every few hours for a day. After about 28 hours of
nagging, US West did something that fixed the problem. I never got a report
about what was wrong...my Cisco 675 just starting syncing again. Total
downtime: about 17 days.
Summary:
- There have been 2 DSL-related problems during this period. The first was
fixed in about 10 hours. I was quite pleased with the response at the time.
The second was fixed in about 2 weeks and 28 hours....US West dropped the ball
until I had time to nag them repeatedly to get the problem fixed. Both
DSL-related problems appear to have been equipment failure of some sort at the
CO end.
- Limited support. I'm the only administrator. If I'm gone no one else
fixes problems.
- DNS-problems. The first DNS provider for tuketu.com was often down or slow
to reflect DNS record changes. The second DNS provider (myinternet.com) has
proven to be a much more robust and trouble-free provider.
- IP address changes. Using a DHCP-assigned address, even without any
software support to coordinated IP address changes with my DNS server, has not
directly been a major problem. The number of IP address changes has been small
(2 in 7 months). Rather, the fallout from address changes has been great more
because of the difficulty in getting the new address information into the DNS
records for tuketu.com
The future will probably see the elimination of the POTS, particularly in the
local loop. The high-speed bit-pipe into the home will be harnessed to carry
both data and voice. One example of this is the Sprint ION effort.
Sprint ION
Sprint has introduced a service, Sprint
ION, that heralds things to come. The first markets are Seattle, Denver, and
Kansas City. The service has these interesting qualities:
Using VoDSL, Sprint's package is a complete replacement of the ILEC. Using a
physical DSL connection to carry both voice and data over ATM, Sprint provides a
dedicated high speed Internet connection (up to 8mbit down, 1 mbit up, depending
on line quality), 4 voice lines, and unlimited phone service, both domestic long
distance and local/local long distance (intra-LATA). (Well, at 750 minutes a
month, this is close to unlimited for most people). The charge is a flat
monthly fee of about what a typical family would spend for multiple phone lines,
long distance, and high-speed DSL. The flat charge replaces any fees for local
phone service, your long distance provider, and your high-speed Internet
access. The ILEC is effectively cut out of the picture...at last we see
competition in the local loop. The only revenue for the ILEC is whatever
co-location charges and local-loop charges the ILEC is able to wring out of
Sprint. Does this strike fear in the heart of US West?
It's still unclear how the service will shake out in terms of actual
performance and ISP capabilities. But it's clearly an interesting development.
Forbes commentary
on the Sprint ION network.
What follows is a fairly random collection of useful links that I've built up
over time.
