BellSouth is making major changes to the DSLAM/Edge router network for DSL. The new PPP termination devices use PPPoE exclusively. The updates and changes are ongoing and most customers are notified beforehand so it does not cause a disruption in service. You may be shipped a new modem based on the type of modem BellSouth initially provided.

Most customers are in one of two situations:

1. If you have an older modem that only does PPPoA (such as the Alcatel Stingray) you will need a completely new modem. If you did not receive a replacement modem contact BellSouth for a compatible modem/router.

2. If you have a modem that does both PPPoA/oE you will need to make sure it is configured to utilize PPPoE.

Important Note: PPPoE has additional overhead and you should adjust your MTU settings on your NIC(s) to 1492 or less. Click here for more information.

Andy Houtz

There are currently three types of FastAccess connection. The original Bridged/DHCP service is no longer being offered. So for new installs this leaves two: PPPoA or PPPoE.

PPPoA (PPP over ATM):
ADSL access via Point-to-Point Protocol (aka Dial-Up Networking). The "FastAccess ADSL" icon is located in the Dial-Up Networking folder. The user authenticates with userid and password, then connects. This is similar to dialup except no actual dialing takes place. Only available with the PCI or USB modems (or various unsupported alternative modems and routers).

PPPoE (PPP over Ethernet):
Another dial-up type connection method. PPPoE client software is from NTS (or various unsupported alternatives). The icon is typically located in a NTS EnterNet 300 folder. (As of EnterNet 1.34, integration with DUN is also possible.) Username, password and then connect as with PPPoA. Note that an additional layer of software is involved here.

Bridged/DHCP (RFC 1483):
Uses a standard DHCP network client which is native to every OS. DHCP should automatically negotiate an IP 'lease' on bootup. No special icons in any folders, no dialup type operations, no username and/or password required to connect, and no specialized software is required. This was the original type of service, but has been phased out in favor of PPPoE/A as of late spring/early summer 2000. This most closely resembles true 'always on'.

PPPoE/A Connectivity
All new installations are now PPP. This can be either PPPoE (PPP over Ethernet) or PPPoA (PPP over ATM), two similar yet different protocols. Both use a mechanism similar to a dialup style connection: username and password are required. The server passes a (dynamic) IP address, netmask and other networking details back to the client once authentication has been successful.

The main difference is that with PPPoA, most of the work is done at the hardware level. So a modem that supports PPPoA is required. The Efficient 3060 and 4060 modems both support PPPoA (the Alcatel 1000/STH does not). The appropriate driver then needs to be loaded. The default connection method is via Windows DUN. A separate client ala NTS EnterNet is not required. DSL runs over ATM from the DSLAM to the modem no matter what modem we use. So this would seem to be the 'cleanest' solution for PPP customers.

PPPoE works via the 1483 Bridged driver, and requires client software to manage the session. This means that PPPoE is the only choice for Alcatel 1000/STH modem owners, and also IFITL customers. In fact, PPPoE will work with any of the four modems being offered. The officially supported PPPoE client is NTS's EnterNet, though there are various alternatives. All of which are unsupported, by the way.

PPPoE, by requiring client software, also means there is more overhead due to the additional ethernet layer. And consequently more system resources are used to maintain the connection. This may not be significant depending on your hardware and horsepower.

IFITL users do not need to worry about the modem drivers, since they don't use a modem at all. But still they need the PPPoE client (NTS) software in order to connect.

One of the drawbacks of the current PPP implementations is occasional disconnects. Apparently, the protocols are sensitive to any hiccup in the connection. One consequence here is that your IP address will change each time the connection is re-established. This is not just a BellSouth problem, but seems to be an industry wide issue with PPPoX implementations.

So why PPP? Aren't we trying to get away from dialup type connections?

Well, the answer from any ISP on this is that PPP simplifies a number of things on their end. They can essentially use their same infrastructure as their already well established, and much larger, dialup base. Simpler, means easier, means less costly. In any case, it is here to stay.

Bridged/DHCP Connectivity
DHCP/Bridged service was the original FastAccess ADSL service. This is no longer being offered, as all new installs are now PPPoX.

DHCP (Dynamic Host Configuration Protocol) is a time-tested networking protocol for assigning IP addresses. It allows clients on a TCP/IP network to request and be assigned IP addresses dynamically from a centrally located server, and also to discover other necessary information about the network to which they are connected.

The DHCP server has a fixed pool of IPs, and assigns these when it receives a valid request. In our case, we are assigned 'sticky' IPs. Although these are dynamic (ie, not static), they tend to remain the same for long periods of time -- many months in some cases. The IP is 'leased' from the server's pool of available addresses, and eventually this lease must be renewed, or it will 'expire'.

The client's OS automatically requests a renewal after a predetermined period of time, and the server usually automatically complies. BellSouth.net is using a twelve hour lease. The server also provides other information to the client, such as nameservers, gateway, netmask, and broadcast address. All these are necessary in order to function on any TCP/IP network. The server also sets the maximum, allowed lease period. All this is handled fairly transparently and quietly by most operating systems. The initial request is broadcast during boot and special drivers are required.

The DHCP servers typically have names such as:

sun00sdf.sdf.bellsouth.net

This one happens to also double as the local FastAccess primary nameserver. There would also seem to be a secondary, backup server: 'sun01sdf.sdf.BellSouth.net'. Some cities may still be using names such as ns.rdu.BellSouth.net. These seem to also do double duty as nameserver and DHCP server.

How do they know who we are? There has to be method of authenticating the user as a valid customer.

We are recognized by the 'MAC' addresses of our network adaptor. This is a unique hardware address (looks something like: 00 50 04 A8 77 11) that is recorded in a BellSouth database. The 'adaptor' may either be the Network Card as is the case of the Alcatel external, ethernet modems, or in the case of the Efficient Networks USB and PCI modems, the modem itself.

If you buy your own modem, or router, this will likely have its own, unique MAC address. Which means that anytime the network device is changed, BellSouth will need to know about it, or you won't be able to connect. This can be done by calling the FastAccess HelpDesk so they can register your new MAC address.

Note:
A recent round of upgrades included a conversion from Cisco to Redback 'termination' routers. And implemented a Redback feature known as 'Secure ARP'. Secure ARP has eliminated the ARP and IP broadcasts that used to be all too common. Nice improvement. It has also taken away the ability to assign ourselves static IPs when the DHCP server was down.

Footnotes:
� PPPoE/A are fairly recent protocols. While it is increasingly popular with large ISPs like BellSouth, these are considered less reliable than former DHCP/Bridged set up by many. Occasional disconnects are the biggest complaint. This seems to be the nature of the beast.

� All the Efficient Networks modems supplied by BellSouth have built in diagnostics. Apparently true of the 3Com PCI as well. The Alcatel 1000/SpeedTouch ethernet modems have none unfortunately, and probably is one reason BSIS is reluctant to use these. (Alcatel USB???)

� If you are on Bridged/DHCP service, and you change your Network Card that is connected to the modem, you will have to re-register the new MAC address with tech support, or you won't be able to connect. They can walk you through this. Also true if you are using a PCI or USB modem and change to a different modem. PPPoX does NOT require MAC address registration. It is not used.

� For an alternative OS (Linux, *BSD, OS/2, BeOS, Solaris), your only real hope is the ethernet Alcatel. This connects via ethernet to a NIC, and will work with any OS. Another option is to buy your own modem or router outright. Just make sure it is compatible with BellSouth's DMT (Alcatel compatible) based DSL service. There are other possibilities, notably CAP based service that will not work! Be aware that while there are a number of modems, routers, etc that work just fine with BellSouth, the only ones actually supported are those as provided by BSIS.

� BellSouth does supply the Cayman 3220H router for Business ADSL. By all accounts, this is a good quality combo modem/router. Cost from BellSouth is about $300 (?). Works with PPPoA and Bridged mode, and is NAT ready.

� FastAccess ADSL is 'full rate' ADSL. BellSouth is not offering G.Lite at this time. Also, it is 'non-interleaved' or 'Fast' DMT. This is good for ping times.

One way to simplify the modem/driver/client mess, is to purchase a router. There are any number of models available. Some come with an integrated modem, and all handle the common protocols (DHCP, PPPoX). This takes all the burden off of your computer, since the router 'does it all'. Unfortunately, BSIS does not officially support any routers at this time. (The exception being the Cayman 3220 that is supported under the business plan.)

In most service areas you can freely switch between PPPoA and PPPoE. It is important to note that it may take the BellSouth gateway routers several minutes to properly detect the switch. Also note that in very rare instances, the routers may become "stuck" in PPPoE mode. In this case, it would be necessary to contact BellSouth Technical Support to switch back to PPPoA.

Switching the protocol from PPPoA to PPPoE or vice versa should have no effect on your BellSouth gateway router. In the past, it was not uncommon for the gateway router to become "stuck" in PPPOE mode. When that would happen, it was necessary for BellSouth to physically "reset" the router before it would recognize a switch to PPPoA. This problem was addressed in an update to the gateway router's firmware. Although the update apparently did not completely eliminate the problem, it is now extremely rare.

BellSouth no longer offers a bridged connection option to new customers. This service was originally offered by BellSouth but was replaced by PPPoA/PPPoE.

In order to reduce email spam and open relays, BellSouth filters Port 25 (SMTP - Mail) for almost all residential accounts. If you are unable to send or experience sporadic email sending and use an email domain other than "bellsouth.net" you may be blocked. If you have a secondary (non BellSouth) email check the BellSouth Port 25 FAQ for more info. Currently, BellSouth only filters Port 25. If you have ports blocked (other than 25) check the configuration settings on your equipment or software (modem, router, firewall, or PC applications, etc).

Andy Houtz DSL

There are two ways an ISP can allocate or assign an IP address to you for use on the internet; static and dynamic.

Static IP Address
A static IP address is assigned to your computer by your ISP and is permanent. Each time you connect to the internet, the same address is used. This address is never used by any other computer or device.

Dynamic IP Address
It would be simple if every computer that connects to the Internet could have its own static IP address, but when the Internet was first conceived, the architects didn't foresee the need for an unlimited number of IP addresses. Consequently, there are not enough IP addresses to go around. To get around that problem, many Internet service providers economize on the IP addresses they possess by temporarily assigning an IP address to each computer from a pool of IP addresses. The temporary IP address is called a dynamic IP address. As a result, the IP address may be different each time the computer connects to the Internet.

"Ping time" refers to the amount of time it takes for a small "packet" of data to travel over the internet from one computer to another computer and back to the first computer. It is usually reported in milliseconds (ms).

Latency is another term for "Ping Time".

In most cases no. Ping time is the inherent time it takes for packets to make it to their first hop and no tweaks can reduce that. However, customers that are on a noise profile are "Interleaved" and experience constant increased ping times starting on the first hop as compared to standard "FastPath" customers. Interleaving enables FEC (Forward Error Control) which is required on noisy lines to help the modem stay synched and reduce errors. More information is available here. To determine whether your DSL line is "Interleaved" or "FastPath" click here.

Important Note: High ping times on a router somewhere on the internet shown utilizing a simple ping test may not actually be a problem at all. Please click here for more information.

Andy Houtz

Maybe...depending on what hop(s) are experiencing loss.
•Packet loss on your first two hops is usually due to a physical issue in the local loop including noise, T1s, ISDN, bad wiring, long loops, bridged taps, etc. Here are some suggestions:

Switching to an "Interleaved" signal may reduce or eliminate packet loss. Set at the DSLAM by BellSouth.
Eliminate the physical problem on the local loop. This must be corrected by a BellSouth technician.
Isolate and eliminate the physical problem inside the house. Reference the NID Test FAQ and the Homerun FAQ.

Packet loss and high ping times on a router somewhere on the internet shown utilizing a simple ping test may not actually be a problem at all. Please click here for more information.

Additional Note:Tweaking your computer can not correct packet loss.

Andy Houtz DSL

There are 5 possible reasons why test speeds that greatly exceed the BellSouth DSL cap of 1472kbps downstream and 256kbps upstream may appear in the DSLReports Speed Test database:

• They may be IFITL and not ADSL customers. Because IFITL uses traffic shaping and not a hard coded provisioning some IFITL customers may downstream speeds in the 1800 - 2000kbps range.
  
  
• They may have been using an ISP proxy server. If that is the case, the speed test results are not accurate at all. When the speed test is run from a PC that is using an ISP proxy server, it is the speed between the test server and the proxy, not between the test server and the end user that is actually reported. Most proxy servers are on a very high speed backbone connection.
  
  
• The speed was tested using some other high speed access line (work, friends cable modem, etc). Speeds are logged to the ISP listed in your DSLReports member profile by default.
  
  
• They use a caching program that simulates faster speeds, but it is not a true speed.
  
  
• The results were faked. This is very possible and is one of the most common reasons for inflated speeds.

Ideally all devices on the local network should be the same. However, contrary to popular belief, lowering the MTU on a router is almost useless and may actually create more problems. Selecting the correct MTU size on the PC's NIC is the absolutely, positively, and with no shadow of any doubt the most important setting, because the NIC is where the packet is originally assembled. This is incredibly important to PPPoE connectivity since it requires an additional 8 byte header as compared to PPPoA. If the NIC produces a 1500 byte packet then it must be fragmented to get past the router that is set to 1492 (default router PPPoE setting)or lower. Many people mistakenly think that the NIC and the router will auto negotiate the MTU on the LAN side to 1492 but in fact most routers will pass a 1500 byte packet on the LAN side. The MTU setting set in the router is almost always exclusively for the WAN side connectivity, not the LAN. Therefore the MOST important MTU setting is on the NIC where the packet is originally made. If you have an MTU of 1492 (or lower) on the NIC you could run an MTU of 50,000,000,000,000,000 bytes on the router and the largest packet ever sent to the internet would still only be 1492. But the opposite is not true. If you have a router set at 1492 and a NIC at 1500 and the NIC sends out a 1500 byte packet then it must be fragmented and that's when the trouble starts. Fragmented packets are not always easy to detect and many people do not even realize that they are having a problem but they are. Set it to 1492 and be done with it.

Andy Houtz DSL

No. BellSouth does not release your IP after a predetermined time.
BellSouth uses IPCP (Internet Protocol Control Protocol) not DHCP to establish sessions and assign IP addresses to end users for PPP sessions. Ending the PPP session is the only way to release the IP once assigned. Additionally, BellSouth static IPs are not a true static IP in the classical sense. It is dynamically assigned through your username via PPP, however it is always the same IP. Customers must configure their routers, modems, or NICs to automatically obtain the IP address. Do not try to hard code your WAN IP!

There are several common ways to get a new IP:
You turn off or reset your PC/modem/router or simply end the session by disconnecting.
Your modem/router/PC is set to timeout after a certain time of inactivity.
A configuration is set improperly on your PC/modem/router.
Your modem/router is dying and dropping the session or losing connectivity.
You have a physical line problem that makes you lose synch.
BellSouth disconnects you due to maintenance or an outage.

Andy Houtz DSL

Doubling NATing happens when you install two independent routers in series on the same network. If both routers have NAT (Network Address Translation) enabled it may create connectivity, surfing, and application errors. One major concern is the first router assigns a non-routable IP to the WAN port of the second router. Some routers have trouble when assigned a non-routable IP on the WAN port. Additionally, the IP may not even be in the same IP range (i.e. one router uses 192.168.1.XXX and the other uses 10.0.0.xxx).

If you use two routers, you should configure one to be a simple bridge device and disable DHCP and NAT. It doesn't matter which router you choose to bridge (your personal preference), but one of the two must be bridged. Different router manufacturers have unique ways to bridge their equipment so consult the manual for your specific router for more information. If you have a BellSouth Westell click here for detailed procedures.

Andy Houtz DSL

Like the story of Goldilocks and the Three Bears, too small or too large of an RWIN just won't do.

Important Notes:
Use the following RWIN sizes for BellSouth FastAccess and be done with it. The rest of the FAQ is purely academic.
FastAccess Extreme 3.0Mbps and 6.0Mbps = 63888
FastAccess Ultra 1.5Mbps = 52272
FastAccess Lite 768Kbps = 52272
Although the Broadband Reports Tweak Test offers very good general information, it may give erroneous or misleading recommendations. It provides a range for your RWIN and is not an accurate, individualized analysis.
Don't rely on speed test sites to make small changes to your RWIN. They usually use a small file and can't accurately measure the true overall efficiency of your services.

What's happens if my RWIN is too small
A small RWIN creates more unnecessary traffic and delays. Remember you must stop inbound traffic while the acknowledgement is sent and received by transmitting end. These inefficiencies are not easily measured with standard speed test simply because they use such a small file, however the overall efficiency is greatly reduced.

What's happens if my RWIN is too big
An RWIN larger than 65535 is never recommended for FastAccess DSL for three major reasons:
1. Although a larger rwin is possible, anything above 65535 will automatically turn on Window Scaling which is not supported or implemented correctly on all networks and internet devices.

The TCP window field, however, is only 16 bits wide, allowing for a maximum window size of 64KB. The TCP designers must have thought that nobody would ever need a larger window than that. But 64KB is not even close to what is needed in many situations today. The solution to this problem is called "window scaling." It is not new; window scaling was codified in RFC 1323 back in 1992. It is also not complicated: a system wanting to use window scaling sets a TCP option containing an eight-bit scale factor. All window values used by that system thereafter should be left-shifted by that scale factor; a window scale of zero, thus, implies no scaling at all, while a scale factor of five implies that window sizes should be shifted five bits, or multiplied by 32. With this scheme, a 128KB window could be expressed by setting the scale factor to five and putting 4096 in the window field.

To keep from breaking TCP on systems which do not understand window scaling, the TCP option can only be provided in the initial SYN packet which initiates the connection, and scaling can only be used if the SYN+ACK packet sent in response also contains that option. The scale factor is thus set as part of the setup handshake, and cannot be changed thereafter.

The details are still being figured out, but it would appear that some routers on the net are rewriting the window scale TCP option on SYN packets as they pass through. In particular, they seem to be setting the scale factor to zero, but leaving the option in place. The receiving side sees the option, and responds with a window scale factor of its own. At this point, the initiating system believes that its scale factor has been accepted, and scales its windows accordingly. The other end, however, believes that the scale factor is zero. The result is a misunderstanding over the real size of the receive window, with the system behind the firewall believing it to be much smaller than it really is. If the expected scale factor (and thus the discrepancy) is large, the result is, at best, very slow communication. In many cases, the small window can cause no packets to be transmitted at all, breaking TCP between the two affected systems entirely.

2. DSL and the underlying ATM/Ethernet network is a low latency transmission topology. Extremely large rwins work best with high bandwidth/high latency networks such as satellite. Satellite service creates a large amount of latency for the packet acknowledgements which decreases full bandwidth utilization. Remember, inbound traffic stops while the acknowledgement is sent and received by transmitting end. Since DSL doesn't have these inherent problems, you should not use extremely high RWINs.

3. As bandwidth goes higher the relative stability of the connection goes down. Many people with 6.0 may be right at the service edge for signal to noise and attenuation. That increases the chances of errors and/or packet loss. If a TCP packet is lost with a large rwin it will actually take more time to retransmit the packet(s) compared to a smaller rwin.

Andy Houtz DSL

Traditionally, a DSL customer's synch rate was provisioned directly on the DSLAM and hard set to a specific profile. A customer with a 256/128Kbps service would synch at 256/128Kbps between the DSLAM and the modem, regardless of the overall attainable line rate possible. MaxSync introduces two important differences.
1. The synch rate is no longer provisioned on the DSLAM. The DSLAM and modem will synch at the highest rate possible (within certain criteria).
2. Service speed is controlled via a RADIUS profile.
So the customer mentioned above with 256/128 service could possibly see a 8128/512 synch rate if they were changed to a MaxSync profile depending on their individual line conditions yet only have 256/128 speeds to the Internet.

The good news
Changes can be done without reprovisioning the DSLAM and accomplished with a simple RADIUS change. MaxSync enables the possibility of offering bandwidth on demand services in the future. It also gives the customer and BellSouth the ability to gauge the overall condition/capability of the customer's loop. If a customer's line can only MaxSync at 3552/384 they obviously would not be a good candidate for the 6000/512 service. Conversely, a customer currently on 256/128 that MaxSyncs at 8128/512 shouldn't have any problems upgrading to 3000/384.

The bad news
Generally, higher sync rates and bandwidth lower the overall signal to noise margin and increases line attenuation. The MaxSync profile could create problems for a customer that were never an issue before. For example:

1472/256 service with traditional provisioning at the DSLAM
- Marginal line with attainable line rate of 3600/500
- Signal to noise margin of 10dB
- Line attenuation of 55dB
- Loop Capacity is about 41%
The customer has never had any problems even tough the line is marginal because of the low synch rate.

Same 1472/256 service set to MaxSync profile
- Marginal line attainable line rate of 3600/500
- MaxSynch rate of 3552/384 (possibly with interleaving)
- Signal to noise margin of 7dB
- Line attenuation of 60dB
- Loop Capacity is almost 100%
The customer may now experience connectivity issues and may have also be placed on interleaved profile. Although newer interleaving techniques have reduced the overall latency as compared to older methods, it still introduces some latency.

Important Information:
Due to differences in network topologies, MaxSync is not available to all FastAccess customers.

Additional Information:
How do I check modem statistics? What do the numbers mean and are my stats good?
What is Interleaving and Fastpath?

Andy Houtz DSL

Yes, but it only helps if you are troubleshooting an issue actually created by the auto-tuning. Viasta has a new feature called "Next-Generation TCP/IP Stack" that, by default, uses a dynamic auto-tuning to make changes to the RWIN. It's my opinion that it is another good idea that works in the lab but not the real world. Additionally, disabling it doesn't allow you to manually adjust the RWIN (at this time). Four basic reasons they are idiots:
1. Overall latency and network infrastructure rarely change so always checking and tuning for the "best" RWIN is pretty much useless.
2. It doesn't work well for different network topologies, black hole routers, many firewalls, and misconfigured servers. They even have a tech bulletin discussing it. »support.microsoft.com/kb/934430
3. Microsoft consistently auto-tunes the RWIN higher than 65535 which requires "window scaling". Please click here to find out why you should not rely on window scaling .
4. When was the last time you really trusted auto-tuning of any hardware/software program? Sure it's better than nothing at all...but it doesn't mean it is the "best".

Disabling Auto-tuning
Open the Command Prompt and type:
netsh interface tcp set global autotuning=disabled
and then hit Enter.

To verify that it is disabled type:
netsh interface tcp show global
and then hit Enter.

To set back to default auto-tuning type:
netsh interface tcp set global autotuningl=normal
and then hit Enter.

Additional Links:
»support.microsoft.com/kb/934430